当前位置: 首页>>技术教程>>正文


如何在ubuntu上设置没有互联网访问权限的本地ntp服务器?

, , , ,

问题描述

我已经尝试了一些指南,以了解如何在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 stopsudo 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 asntpq -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就有机会识别服务器为正常并同步到服务器。您可能应该首先尝试最差的客户端,看看是否有帮助。

参考资料

本文由Ubuntu问答整理, 博文地址: https://ubuntuqa.com/article/10692.html,未经允许,请勿转载。