web-dev-qa-db-ja.com

Nagios-check_ntp_time-不明なオフセット

私はローカルでNTPサーバーをサブネット上で実行して、他のサブネットノードを同期させて、すべてのノードが上流サーバーと同期しないようにします。しかし、Nagiosのcheck_ntp_timeプラグインを実装している間、苛立たしい問題に気づき、nagiosはローカルntpサーバーと同期するローカルノードの重大なエラーを報告し続けます。

これがローカルのntpサーバーのntp設定です。上流のserverエントリとrestrictエントリに注目してください。私の調査によると、これはノードをローカルノードであるntpサーバーとして認定しますに対して同期できます。

driftfile /var/lib/ntp/drift

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod limited nomodify notrap nopeer noquery
restrict -6 default kod limited nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
restrict -6 ::1

# Makes me able to answer requests from local nodes
restrict 10.0.0.0 mask 255.255.192.0 nomodify notrap

# My source
server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org
server 2.centos.pool.ntp.org

logfile /var/log/ntp/server.log

statistics loopstats
statsdir /var/log/ntp/
filegen peerstats file peers type day link enable
filegen loopstats file loops type day link enable

ローカルの非NTPサーバーノードでは、restrictエントリが削除され、serverエントリがローカルのntpサーバーのみを参照することを除いて、すべて同じです：server ntp.example.com iburst。

すべてのローカルノードはntp.example.comを解決できます。

私が抱えている問題は、nagiosサーバーから次のコマンドを実行したときです。

/usr/lib64/nagios/plugins/check_ntp_time -H node-a-1 -v

そして出力：

sending request to peer 0
response from peer 0: offset -0.002921819687
sending request to peer 0
response from peer 0: offset -0.0001939535141
sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
discarding peer 0: stratum=0
overall average offset: 0
NTP CRITICAL: Offset unknown|

これは、上流のサーバーを参照するローカルntpサーバーを除くすべてのノードで発生します。最初はIPTablesの問題だと思っていましたが、ポートはすべてのローカルntpノードに固定されています（nagiosが時間の差分を確認できるようにするため）。

ACCEPT     udp  --  eth0   *       10.0.0.0/18          0.0.0.0/0           multiport dports 123 /* 777 allow ntp access */ state NEW

バージョン：

nagios-plugins-ntp: 1.4.16
ntp: 4.2.6p5-1.el6.centos

サーバーの時刻を同期させることが優先事項1であることを知っているので、これが解決するまでnagiosの作業を提出することはできません。

-編集-

コメントごとに、さまざまなノードでのntpq -pの結果を次に示します。

# Actual NTP Server (10.0.0.2)
==============================================================================
+propjet.latt.ne 241.199.164.101  2 u  105  128  337   14.578   12.954   7.138
+x2la01.hostigat 63.145.169.2     3 u   21  128  377   16.037   13.546   4.090
*pacific.latt.ne 241.199.164.101  2 u   72  128  377   15.148   24.434   7.403

# Local node 1
==============================================================================
*service-a-1.sn1 204.2.134.163    3 u    9  128  377    0.228    5.217   1.296

# Local node 2
==============================================================================
*service-a-1.sn1 204.2.134.163    3 u   91  128  377    0.200    3.608   1.167
linuxcentosnagiosntp
6
Mike Purcell

ここで重要なのはこれです。

ピア0を破棄：stratum = 0

NTPサーバー自体がストラタム0として識別されると、仕様に違反します（これは原子時計などのために予約されています）。この問題は、何年か前に一部のBSDおよびMac OS Xホストで発生していました。結局、ソースから階層チェックをハッキングし、「問題のある」ホスト用のプラグインの個別のビルドを維持することになりました。

問題のある行は254〜257です （現在、とにかく）、それを取り除きたい場合。それはハックですが、私にとってはうまくいきます;-)

私は this thread をメーリングリストのアーカイブで見つけました。ストラタムチェックを無視するコマンドラインオプションを追加するよう提案した別の方法もあったと思いますが、それが少しも魅力的ではなかったと思います。

それについて バグレポート もありますが、私が知る限り、それは有用なものをもたらしていません。

8
Keith

NTPサーバー上のKOD（キスオブデス））機能を無効にすることで問題を取り除きました。

check_ntpは、統計的に健全な平均オフセットを計算するために、（少なくとも）4つの要求をすばやく連続して送信します。 3番目以降の要求は、サーバーによるサービス拒否攻撃と見なされ、KODメッセージ（無効な層、つまり0）で応答されます。実際、KODはクライアントによって適切に処理される必要があるため、この動作はcheck_ntpのバグと見なす必要があります。

0
KHL