ubuntuでインターネットにアクセスせずにローカルNTPサーバーを設定するにはどうすればよいですか？

Question

私はubuntuでローカルNTPサーバーを設定する方法についていくつかのガイドを試しましたが、どれも正しく機能していないようです。私のサーバーは、何らかの理由で時間的に大幅にずれており、これを必要とするデータベースを実行しているため、サーバーの時間を互いに近づける必要があります。

8つのubuntu 14.04 LTSサーバーがありますが、どれもインターネットにアクセスできません
サーバーの1つ（またはそれ以上）でntpサーバーを実行し、他のすべてのサーバーをntpサーバーに接続して時間を設定したい

現在、私のサーバー（ip .24）はこの/etc/ntp.confを実行しています。

server 127.127.1.0 prefer fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift broadcastdelay 0.008 # Give localhost full access rights restrict 127.0.0.1 # Give machines on our network access to query us restrict 192.168.178.0 mask 255.255.255.0 nomodify notrap broadcast 192.168.178.0

そして「クライアント」：

# Point to our network's master time server server 192.168.178.24 iburst fudge 192.168.178.24 stratum 10 restrict default ignore restrict ::1 restrict 127.0.0.1 restrict 192.168.178.24 mask 255.255.255.255 nomodify notrap noquery driftfile /var/lib/ntp/drift minpoll 4 maxpoll 5

注：マルチタブPuTTYを使用して、次のコマンドをすべてのntpクライアントに同時に送信しました。サーバー以外のすべてのntpサービスを停止しました。Sudo ntpdate 192.168.178.24を使用して日付を取得し、後でntpサービスを再起動させます。これは成功した。コマンドが終了した直後、すべてのサーバーが同じ日付を示していました。ただし、約10分後、サーバーに次の時間が表示されます。

Fr 30. Sep 11:16:53 CEST 2016 Fr 30. Sep 11:15:33 CEST 2016 (server .24) Fr 30. Sep 11:16:50 CEST 2016 Fr 30. Sep 11:15:33 CEST 2016 Fr 30. Sep 11:17:05 CEST 2016 Fr 30. Sep 11:15:33 CEST 2016 Fr 30. Sep 11:15:33 CEST 2016 Fr 30. Sep 11:15:33 CEST 2016

それらをntpサーバーに正しく同期させるには？そして、どうすればポーリング時間を短縮できますか？私のサーバーは高速で同期が不足しているようですので、「正しい」時刻を再度取得するためにサーバーが必要です...

「正しい」時間とは、すべてのサーバーで同じ時間を意味します。正確に正しい世界時間である必要はありません（そのように呼ぶ場合）。

編集：推奨される構成設定を試しました。私が理解している限り、これは私のサーバー/クライアント構成がどのように見えるべきかです。その間、私の.24サーバーが実際にはより悪い時期に流れているのを見てきました。 .20サーバーは最も正確なサーバーであり、現在.20サーバーを使用してntpサーバーをホストしています。混乱してしまい申し訳ありません。

サーバー構成：

# Use the local clock server 127.127.1.0 prefer fudge 127.127.1.0 driftfile /var/lib/ntp/drift broadcastdelay 0.008 # Give localhost full access rights restrict default # Give machines on our network access to query us restrict 192.168.178.0 mask 255.255.255.0 nomodify notrap broadcast 192.168.178.0

クライアントの場合：

# Point to our network's master time server server 192.168.178.20 iburst restrict default driftfile /var/lib/ntp/drift minpoll 4 maxpoll 5

サーバー上のntpq -asおよびntpq -pe：

ntpq -c as ind assid status conf reach auth condition last_event cnt =========================================================== 1 41906 963a yes yes none sys.peer sys_peer 3 2 41907 8811 yes none none reject mobilize 1 ntpq -c pe remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 5 l 60 64 377 0.000 0.000 0.000 192.168.178.0 .BCST. 16 u - 64 0 0.000 0.000 0.000

次のような出力が5回類似しています（これらのサーバーは時間的にずれています）。

ntpq -c as ind assid status conf reach auth condition last_event cnt =========================================================== 1 62104 9024 yes yes none reject reachable 2 ntpq -c pe remote refid st t when poll reach delay offset jitter ============================================================================== hadoop20.xx LOCAL(0) 6 u 27 64 377 0.151 63591.8 33407.0

2つのクライアント（ほとんどの場合？）の場合：

ntpq -c as ind assid status conf reach auth condition last_event cnt =========================================================== 1 7757 963a yes yes none sys.peer sys_peer 3 ntpq -c pe remote refid st t when poll reach delay offset jitter ============================================================================== *hadoop20.xx LOCAL(0) 6 u 18 64 377 0.183 7.883 3.015

編集2：

私はSudo service ntp stop、Sudo ntpdate 192.168.178.20、ntpdateが終了するのを待つ、すべてのクライアントでSudo service ntp startを使用しました。成功しているクライアントは2つ、拒否しているクライアントは5つだけです。

拒否クライアントはこの出力を示します。 delay + offsetの値は、失敗したクライアントが時間内にドリフトするため、高く見えます。おそらく、遅延/オフセットが非常に高いため、サーバーが時刻を更新することを信頼していないのでしょうか？

ntpq -c as ind assid status conf reach auth condition last_event cnt =========================================================== 1 20981 905a yes yes none reject sys_peer 5 ntpq -c pe remote refid st t when poll reach delay offset jitter ============================================================================== hadoop20.xx LOCAL(0) 6 u 34 64 3 0.166 18665.9 16201.3

私もこれを使ってみました https://askubuntu.com/a/256004 回答、約30秒間機能し、その後状態が再び「拒否」に変わります！ ntpdate -s 192.168.178.20についても同様です。ほとんどの場合、サーバーの時間を拒否するntpクライアントに関連しています。彼らに時間を変えるよう強制する方法はありますか？

MadHatter · Accepted Answer

これを行わないでください。真剣に。しないでください。 NTPは多くのマシンがすべてsameの時間を持つことができるように設計されている）という考えを思いつき続けます。そうではありません。多くのマシンがcorrect時間にできる限り近いものをすべて持つことができるように、非常に慎重に設計されています。同じこと。

ウィンドウにアクセスできる場合は、約50ポンドでハーフディーセントstratum-1サーバーを構築するか、100ポンドで構築できます。あなたはそのようなものを構築し、他のクライアントに向ける方がはるかに良いでしょう。正しいタイムスタンプは、特にフォレンジックにとって、自己矛盾のないタイムスタンプよりもはるかに優れています。

しかし、あなたが絶対にあなたがしていることをしなければならないなら、あなたはあなたがntpdを倒錯していることを理解する必要があります、そしてこれはあなたがしていることを理解することを意味します。

サーバー上

server 127.127.1.0 prefer fudge 127.127.1.0 stratum 10

「権威があるかのようにローカルの規律のない時計を使用する」を意味し、これはあなたが望むものです。ただし、なぜそれを層10に強制するのかはわかりません。 stratum 10の削除を検討し、ドライバーにデフォルトのストラタム0を提供させる。

server 192.168.178.24 iburst fudge 192.168.178.24 stratum 10

まったく意味がありません。 fudge 127.127.x.yは、さまざまな種類のローカルクロックドライバーの使用を強制するために予約されています。他のアドレスを指定しても意味がありません。クライアントからfudge行を削除し、サーバーに向けるだけです。また、閉じたネットワークを使用しているので、これが機能するようになるまで、すべてのセキュリティ機能を削除してください。

restrict default

それでも機能しない場合は、少なくとも10分間中断せずに、サーバーと動作の悪いクライアントの両方でntpq -c asとntpq -c peの出力を確認する必要があります。ランニング。

編集：その下にコメントを書き込みます "失敗したクライアントがドリフトするため、オフセット/ジッターは本当に高いと思います時間"。

あなたは正しいと思う。この章のブログは、彼が同じ経験をしたことを示唆しています。クライアントのクロックが悪かったため、ローカルntpdをだまして、サーバーが信頼できないと考えました。彼が書きました

大きなジッターの理由がついに明らかになりました！私たちの時計は非常に速くドリフトするので、数回の測定でオフセットが数秒上がる

同期に失敗しているのは、クライアントの時間が最も早く切れている（サーバーを "拒否"としてマークしている）場合、同じ効果が得られると思います。彼の解決策は、adjtimexを使用してカーネルクロックを手動で調整（tick値を調整）して、システムクロックが遅くなり、ntpdがサーバーを正常であると認識する機会を得ることでした。、それに同期します。おそらく、まず最悪のクライアントで試してみて、それが役立つかどうかを確認する必要があります。