我已经尝试了几个关于如何在 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
在“客户”上：
# 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 服务器？我怎样才能降低轮询时间？看起来我的服务器快不同步了，所以我需要它们再次检索“正确”的时间......
“正确”时间是指所有服务器都相同的时间。它不一定需要是完全正确的世界时间（如果你这样称呼它）。
编辑：我已经尝试了建议的配置设置。据我了解，这就是我的服务器/客户端配置的样子。与此同时，我发现我的 .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 秒，然后状态再次变为“拒绝”！对ntpdate -s 192.168.178.20. 这很可能与 ntp 客户端拒绝服务器的时间有关。有没有办法强迫他们改变时间？
不要这样做。严重地。只是不要。人们不断提出这样的想法，即 NTP 旨在让一堆机器都拥有相同的时间。它不是。它的设计非常谨慎，允许许多机器都拥有最接近正确时间的东西，这不是一回事。
如果您可以访问一个窗口，您可以花大约 50 英镑建造一个半像样的第 1 层服务器，或者花 100 英镑建造一个不错的服务器。你会更好地构建类似的东西，然后将其他客户指向它。正确的时间戳比仅仅自洽的时间戳要好得多，尤其是对于取证而言。
但是如果你绝对必须做你正在做的事情，那么你需要意识到你在扭曲 ntpd，这将意味着理解你在做什么。
在服务器上
意思是“使用本地无纪律的时钟，就好像它是权威的一样”，这就是你想要的。不过，我不确定您为什么要强迫它进入第 10 层；考虑删除
stratum 10, 并让驱动程序提供其默认层 0。在客户端上完全没有意义。
fudge 127.127.x.y保留用于强制使用各种本地时钟驱动程序。给它任何其他地址是没有意义的。从客户端删除fudge线路，并将它们指向服务器。您还使用了封闭网络，因此请放弃所有安全性内容，直到您可以正常工作：如果这似乎仍然不起作用，我们需要在至少十分钟的不间断运行之后查看服务器和行为不良的客户端
ntpq -c as的输出。ntpq -c pe编辑：您在下面的评论中写道“我认为偏移/抖动非常高，因为失败的客户端会及时漂移”。
我想你可能是对的。 这个小伙子的博客表明他有同样的经历：客户端时钟非常糟糕，以至于它欺骗了本地人
ntpd认为服务器不可靠。他写了鉴于您的客户的时间过得最快而无法同步（将服务器标记为“拒绝”），我认为您会看到相同的效果。他的解决方案是使用
adjtimex手动调整内核时钟（调整tick值），直到系统时钟不那么任性，此时 ntpd 有机会识别服务器正常，并与之同步。您可能应该首先在最差的客户端上尝试一下，看看它是否有帮助。按照下面列出的步骤，我能够获得可接受的时间差异：
脚步
在您的两个设备中安装 chrony
让我们假设服务器 IP 地址 192.168.1.87 然后客户端配置（/etc/chrony/chrony.conf）如下：
server 192.168.1.87 iburstkeyfile /etc/chrony/chrony.keysdriftfile /var/lib/chrony/chrony.driftlog tracking measurements statisticslogdir /var/log/chrony服务器配置（/etc/chrony/chrony.conf），假设你的客户端IP是192.168.1.14
keyfile /etc/chrony/chrony.keysdriftfile /var/lib/chrony/chrony.driftlog tracking measurements statisticslogdir /var/log/chronylocal stratum 8manualallow 192.0.0.0/24allow 192.168.1.14在两台计算机中重新启动 chrony
sudo systemctl stop chronysudo systemctl start chrony5.1 在客户端检查，
sudo systemctl status chrony5.1
chronyc tracking输出：您可以完全放弃 NTP，在“服务器”上手动设置时间并发出以下命令：
循环遍历所有“客户端”IP，您就完成了！
说明：本地时间将通过 SSH “复制”到远程机器。