Ntpdでleapfile機能を使用していくつかのテストを行い、偽のうるう秒を送信して、Linuxプラットフォームが「バグ」に対して回復力があることを確認しています。 NTPラボは非常に単純です。leapfile機能を備えたntpdを実行するローカルクロックを備えた「マスター」サーバーと、「マスター」に接続する「クライアント」システムもあります。
CentOS-6ボックス(4.2.4p8-2を実行)では問題なくうるう秒フラグが「マスター」から「クライアント」に転送されることがわかりましたが、同じ構成ではDebianSqueezeでは機能しません。 (4.2.6.p2 + dfsg-1 + b1)。
Ntpdにクエリを実行すると、「leap_add_sec」フラグと「leap = 01」フラグが返され、tcpdumpを実行すると、これらのフラグも表示されますが、「クライアント」システムは、私が言うようにフラグを無視しています。thisアップストリームから4.2.6.p2を実行しているDebianでのみ発生し、4.2.4p8のCentOSでは発生しません。
CentOSマスターNTP config =正常に動作します
driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
server 127.127.1.0 iburst
fudge 127.127.1.0 stratum 10
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
keysdir /etc/ntp
crypto pw password
DebianマスターNTP config = leap-secondはマスターからクライアントに転送されません
leapfile "/etc/leap-seconds.list"
driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
server 127.127.1.1 iburst
fudge 127.127.1.1 stratum 10
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
CentOSとDebianの設定ファイルのユニークな違いはうるう秒の設定です ntpdのバージョンによって異なります 、残りの設定はマスターサーバーとクライアントサーバーの両方で同じです。
これは、クライアントのNTP構成です:
driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
server 10.204.3.2 iburst
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
Debian/4.2.6.p2システムでうるう秒の転送をブロックする理由は何でしょうか?
参考:バージョン固有の動作のようです。SqueezeのLenny(4.2.4p4 + dfsg-8lenny3)の「転送」ポートパッケージは期待どおりに機能します。うるう秒フィールドがクライアントに転送されます。 。