More from: ntpd

dovecotの自殺・・・

先週に引き続き昨日もpop3デーモン(dovecot)が死んでいた。
maillogには
”Time just moved backwards by xx seconds. This might cause a lot of problems, so I’ll just kill myself now.”
というのが残っていて、時刻が巻き戻ったために自殺したとのこと。
たしかにntpdで時刻合わせをやっているけど、こんなことで一々死なれていては実運用上困ってしまう。
時刻が巻き戻るとトラブルの元になるのは解からないでも無いけどさぁ・・・
解決策としてはntpdで時刻を一気に合わせるのではなく、徐々に合わせるようにするか、時刻が巻き戻った後で生死を確認してdovecotを再起動するスクリプトを組むかのどちらか。
時刻が巻き戻るのは今のところ日曜日の早朝で、アクセスしてくる人が殆どいない時間帯だから、この時間帯に再起動のスクリプトを動かせば良さそうだな。

それにしても昨年までは時刻が大きく(20-30秒も)巻き戻ることは無かったんだけど、年明けから急に巻き戻るようになったのは何故だろう???

←クリックしてくれると嬉しいです。

またまたntpでタイムサーバと同期できないサーバがあった

以前にもntpでタイムサーバと同期できないサーバが有り、なんとか同期を取れるように出来た。
今回久しぶりに触ることになったサーバも時刻同期が取られておらず、1時間近くも時計が狂っていた。
見るとntpデーモンは動作しているが、/usr/sbin/ntpdcで見るとタイムサーバ(ローカル)と同期が取れていない。
設定ファイル(/etc/ntp.conf)を見てもサーバの指定に特に間違いは無かったが、そのサーバ名が/etc/hostsに書かれておらず名前解決が出来ない状態だった(爆)。
「なーんだ、これが原因かぁ」
と思ってサーバ名とIPアドレスを書き加えてntpdを再起動したが相変わらず同期が取れない。
/usr/sbin/ntpdcで確認するとタイムサーバからの応答が来ないようで、”receive timestamp:”の部分がいつまで経ってもオール”0”のまま。
他のサーバからは問題無く指定したタイムサーバと同期が取れているので、タイムサーバ側の問題とも思えない。
不思議なことにntpdateコマンドでは同期できるので、123番ポートが塞がっているとか、パケットがフィルタリングされているとかでも無い。
/usr/sbin/ntpq -p タイムサーバ名
でもタイムサーバ側が親サーバと同期している状態が見える。
なので、プロトコルやネットワークの問題では無く、件のサーバのntpdの問題のように思われる。
ntp.confで指定するセキュリティがきついのかとも思ったが、/etc/ntp.conf内にはそもそも”restrict”で始まる行が無い(全ての接続を許可している状態)。
駄目元でntpのセキュリティ設定を他のサーバと同様に設定してみたがやはり同期できないorz
うーん、一体どうなっているんだろう?
とりあえず大きな狂いはntpdateで直したからもうしばらく悩んでみるかぁ(爆)

←クリックしてくれると嬉しいです。

Linuxでタイムゾーンの変更を行うには

職場のサーバの時刻が狂っていたので、タイムサーバーに同期させたところ、分と秒は合ったが時がおかしくなってしまった。
あれぇ?と思ってよく見ると、時刻表示の最後の部分が”JST”ではなく”CST”になっている。
このサーバを構築したのは自分では無いのでインストール時にどのような設定を行ったかは知らないが、タイムゾーンが日本では無く、合衆国中部標準時になっている。
これを日本標準時にするのに下記の手順を実行した(全てスーパーユーザーにて実行)。
#cd /usr/share/zoneinfo/Asia
#cp Tokyo /etc/.
#cd /etc
#mv localtime localtime.org(念のためバックアップを取った)
#cp(or mv) Tokyo localtime
要はタイムゾーン情報を合衆国中部標準時用のファイルから日本標準時用のファイルに入れ替えたということ。
なにも実体のファイルを入れ替えなくても、次のようにしてシンボリックリンクを張っても良いと思う。
#ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
というか、こっちのほうがスマートかも。

←クリックしてくれると嬉しいです。

タイムサーバに同期できないサーバがまだあった・・・・・

10/19付けの記事「NTPで時刻同期が出来ないサーバ」で書いたようなサーバがまだあった。
ファイルサーバにしているサーバの時刻が狂っていて、保存したファイルの更新時刻が未来の時刻になっていることに気付き、調べてみると前回と同様にタイムサーバに同期できない状態だった。
原因は前回と同じで自分自身のみしかアクセス出来ないようにしていたので、対処方法も前回と同じにしたところ、無事に同期動作が始まった。
うーん、普段問題なく動いていると監視が疎かになるなぁ、、、、、、

←クリックしてくれると嬉しいです。

NTPで時刻同期が出来ないサーバ

サーバの一台が不可思議なエラーでネットワークに接続できないので、そのサーバからHDDを抜き出し他のPCに入れて代わりのサーバとした。
ところがntpdは起動しているにもかかわらずいつまで経ってもタイムサーバとの時刻同期が取れない。
最初はタイムサーバ側で接続を拒否しているかと思ったが、クライアント(問題のサーバ)側からtelnetで123番ポートに接続を試すと一応「Connected to ”タイムサーバ名”」と出るのでタイムサーバ側は拒否していない。
反対にタイムサーバ側からクライアント側に同じ事をしてみると、「Unable to connect to remote host」と出たので、クライアント側は接続を拒否している。
ntpdateを使って手動で同期を取ることは出来るので、iptables等でブロックされているわけでも無い。

調べてみると案外単純なことで、/etc/ntp.conf内でのセキュリティ設定でntpdの接続をローカルホスト(自分自身)からのみ許可していて、外部へのアクセスを拒否するようになっていた。
これでは外部のタイムサーバと同期できるわけが無い。

具体的には/etc/ntp.confファイル内の
# restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap noquery
の部分が上記のようにデフォルトのままになっていて、外部へのアクセスを許可していなかった。
この部分を
restrict ”タイムサーバのIPアドレス” mask 255.255.255.255 nomodify notrap noquery
と書き換え、
/etc/rc.d/init.d/ntpd stop
/etc/rc.d/init.d/ntpd start
を実行してntpdを再起動したところ程無く時刻の同期が出来た。
同時にタイムサーバ側での認証が必要という設定になっていたので、
authenticate yes

authenticate no
に書き換え認証不要としておいた。

←クリックしてくれると嬉しいです。