web-dev-qa-db-ja.com

ntpdがまったく同期していないようです

私はこのチュートリアルをフォローしています2008年なので、アドバイスを慎重に使用しています。このマシンをマスターにし、他のすべてのマシンにそれを使用して時刻を同期させる必要があります。それらはすべて20-30秒までに同期していません...

デフォルトでは、confファイルには次のものがあります。

# Specify one or more NTP servers.

# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
server 0.ubuntu.pool.ntp.org
server 1.ubuntu.pool.ntp.org
server 2.ubuntu.pool.ntp.org
server 3.ubuntu.pool.ntp.org

# Use Ubuntu's ntp server as a fallback.
server ntp.ubuntu.com

少し変更を加えたところ、server 0.ubuntu.pool.ntp.org iburstになりました。

再起動し、ログを監視します

tail -f /var/log/syslog
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen and drop on 1 v6wildcard :: UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen normally on 2 lo 127.0.0.1 UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen normally on 3 eth0 134.74.77.21 UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen normally on 4 eth1 10.10.0.57 UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen normally on 5 eth1 fe80::5652:ff:fe5a:f89f UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen normally on 6 eth0 fe80::5652:ff:fe01:1aee UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listen normally on 7 lo ::1 UDP 123
Jun 14 16:17:12 ghive-ldap ntpd[16721]: peers refreshed
Jun 14 16:17:12 ghive-ldap ntpd[16721]: Listening on routing socket on fd #24 for interface updates

20分経ちましたが、何も表示されないようです。他のサーバーを追加しましたが、機能していないようです。

ping 0.ubuntu.pool.ntp.org
PING 0.ubuntu.pool.ntp.org (50.7.247.114) 56(84) bytes of data.
From 172.17.200.3 icmp_seq=1 Packet filtered
From 172.17.200.3 icmp_seq=6 Packet filtered

悪いですね。一番近いのはどうですか?私はニューヨークにいます、 このサーバーのリスト に基づいています

server nist1-ny.ustiming.org iburst

それをpingすると、パックされたフィルターも表示されます。

では、ここで何が起こっているのでしょうか。何か案が?ありがとう。

確認する必要がある場合の実際の設定は次のとおりです: http://dpaste.org/wDMxO/


root@ghive-ldap:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 nist1-ny.ustimi .INIT.          16 u    -   64    0    0.000    0.000   0.000
 name1.glorb.com 128.252.19.1     2 u    -   64    1   32.783   -7.453   0.000
 ns1.oninit.com  .INIT.          16 u    -   64    0    0.000    0.000   0.000
 ns1.your-site.c .INIT.          16 u    -   64    0    0.000    0.000   0.000
 triangle.kansas .INIT.          16 u    -   64    0    0.000    0.000   0.000
 europium.canoni .INIT.          16 u    -   64    0    0.000    0.000   0.000
2
CppLearner

Ntpサーバーへのアクセスを制限するネットワーク内にいるようです。指定した6つのタイムサーバーのうち、1つからしか時間が取得されていません。ただし、すべてが失われるわけではありません。

ローカルタイムソースを使用してみてください。信頼できるNTPソースが一般的です。ルーターとDNSサーバーが信頼できるタイムソースを提供することがよくあります。専用のntpサーバーが利用できる場合、それはしばしばntpまたはntp1と呼ばれます。 。ローカルドメインがexample.comの場合、ntp.example.comとして表示されます。

マスターサーバーの場合、そのクロックをタイムソースとして使用することを検討してください。設定は8〜12の範囲の階層であるため、便利なバックアップになりますが、実際のソースを上書きすることはありません。これは正確なタイムソースではない可能性がありますが、すべてのシステムに共通のフォールバックタイムソースとして使用できます。適切なタイムソースを取得できない場合でも、少なくともすべてのシステムを同じタイムソースに同期できます。

# ... and use the local system clock as a reference if all else fails
server  127.127.1.0
fudge   127.127.1.0 stratum 8

一部のGPSユニットを時間ソースとして使用することも可能です。私のタイムソースの1つは、そのタイムソースとしてgpsを主張しています。このアプローチを使用する必要がある場合は、 NTP Reference Clock sのドキュメントから始めることができます。

コマンドntpq -pまたはntpdc -c peersを使用して、タイムソースの信頼性を確認します。ピアが応答しないように構成されている場合でも、ホスト名を追加してピアにクエリを実行できます。

デバッグモードでntpdateを使用して、ローカルネットワークでntpサーバーをスキャンできます。ただし、非常に不正確なルージュサーバーが見つかる場合があります。 (1回のネットワークスキャンで、現在の日付から1日以上ずれているクロックを持つsrtatum 0サーバーが多数見つかりました。)正確な時刻で適度に低い階層(2〜4)を探します。 3を超える階層でサーバーのピアを確認すると、アクセス可能なタイムソースを見つけるのに役立つ場合があります。

1
BillThor

ntpdateは、より大きな番号のポートを使用してntpクエリを送信します。したがって、ポート123がブロックされると、ユーザーとntpサーバーの間の「インバウンド」でntpdは失敗しますが、ntpdateは機能します。

0
rajeev