问题描述
我已经尝试了一些指南，以了解如何在ubuntu上设置本地ntp服务器，但是似乎都无法正常工作。我的服务器由于某种原因在时间上漂移很大，由于我运行需要这样做的数据库，因此我不得不将它们的时间保持紧密联系。
-
我有8个ubuntu 14.04 LTS服务器，它们都没有互联网访问权限
-
我想在一台服务器上运行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
在”clients”上：
# 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
注意：我已使用Multi-Tabbed 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服务器？以及如何减少轮询时间？看来我的服务器正在快速失去同步，因此我需要它们再次检索”correct”时间…
对于”correct”时间，我的意思是所有服务器的时间都相同。它不一定是确切正确的世界时间(如果您这样称呼)。
编辑：我尝试了建议的配置设置。据我了解，这就是我的服务器/客户端配置的样子。同时，我已经看到我的.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
类似输出的五倍(这些服务器随时间变化)：
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
对于两个(最有可能？)工作的客户：
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秒钟，然后状态再次变为”reject”！与ntpdate -s 192.168.178.20相同。这很可能与ntp客户端拒绝服务器时间有关。有办法强迫他们改变时间吗？
最佳办法
不要这样说真的只是不要。人们不断想到NTP被设计为允许一堆机器都具有相同的时间。不是。它经过精心设计，可以使许多机器在正确的时间拥有最接近的东西，而这并不是一回事。
如果您可以访问一个窗口，则可以以50英镑左右的价格建造half-decent stratum-1 server，或者以100英镑的价格建造一个好的half-decent stratum-1 server。您最好构建类似的东西，然后将其他客户指向它。正确的时间戳比仅self-consistent的时间戳要好得多，尤其是对于取证而言。
但是，如果您绝对必须做您正在做的事情，那么您需要意识到自己正在扭曲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
如果这仍然不起作用，则在至少十分钟不间断运行后，我们需要在服务器和badly-behaving客户端上都看到ntpq -c as和ntpq -c pe的输出。
编辑：您在下面的注释中写道：“我认为偏移/抖动确实很高，因为失败的客户端会随时间漂移”。
我认为你可能是对的。 This chap’s blog表示他有同样的经历：客户端时钟太糟糕了，以至于欺骗了本地ntpd以为服务器不可靠。他写了
the reason for the huge jitter finally seems clear! Our clock drifts so fast that the offset will go up by several seconds through our few measurements
鉴于是您的客户时间最短，他们无法同步(将服务器标记为”reject”)，所以我认为您会看到相同的效果。他的解决方案是使用adjtimex手动调整内核时钟(调整tick的值)，直到系统时钟变少为止，此时ntpd就有机会识别服务器为正常并同步到服务器。您可能应该首先尝试最差的客户端，看看是否有帮助。