在所有基于Linux的数据中心中检测时间漂移的策略是什么？ 这是一个比起初看起来更难的问题。 时间漂移可能会对某些应用程序造成严重的问题，而且即使安装了NTP，也可能出现以下（以及更多）原因： NTP未正确设置为在重新启动时自动重新启动。 服务器上的设置不正确，因此指向的时间服务器无法访问或不准确。 主时间服务器无法访问，所有服务器正与它同步，现在正在同步到一个不可靠的来源。 我想要一个方法来检测是否所有的个人服务器是正确的。 请记住，testing脚本/应用程序的服务器可能不正确。
在6.0.8 Debian服务器（HP ProLiant）的冷启动之后， ntpd对系统时间造成了严重的影响：相对于通常可靠的参考时间服务器而言，偏移量和抖动增长不受限制。 （请注意，一个双胞胎相同的服务器没有任何问题。）经过许多不成功的尝试解决ntpd方面的问题，我决定尝试重新启动，一切正常。 为了调查这个问题，我发现这个差异，这可以解释我的时钟问题： root@n1:~# zgrep Detected /var/log/dmesg* /var/log/dmesg:[ 0.004000] Detected 2400.110 MHz processor. /var/log/dmesg.0:[ 0.004000] Detected 2383.579 MHz processor. /var/log/dmesg.1.gz:[ 0.004000] Detected 2400.036 MHz processor. /var/log/dmesg.2.gz:[ 0.004000] Detected 2400.298 MHz processor. /var/log/dmesg.3.gz:[ 0.004000] Detected 2400.165 MHz processor. /var/log/dmesg.4.gz:[ 0.004000] Detected 2400.410 MHz processor. 请注意，在第二次启动（有问题的启动）中，检测到的CPU频率是明显的exception值。 没有exception值时，检测到的频率相对于标称值的误差和标准偏差为+ 0.15MHz±0.25MHz。 对于有问题的启动，我有一个-16.4 Mhz的错误，这比预期的大约100倍。 我的问题： 这种types的错误可以使ntp时间不稳定/不可用？ 这是我的时钟问题的原因？ 这种types的行为是硬件硬件的症状吗？ […]
我正在寻找build立非常典型networking的时间服务器的build议。 我支持偶尔访问互联网的许多封闭networking。 一个networking可以在几个小时内访问大部分的日子，但是经常会在1-3周内停止。 这个networking上的计算机/服务器大部分都是基于nix的，但并不完全一样。 整个networking是移动的，所以当它连接时，它将具有与互联网时间服务器非常不同的跳跃/延迟。 封闭networking上的服务器频繁关机（至less每天）。 现在，我的直觉告诉我使用NTP（因为我讨厌重新学习别人已经工作得很好的所有东西）。 但是我有几个问题，并且正在寻找有这种奇怪情况的经验的人。 我目前没有解决scheme，我只是让内部时钟漂移。 这在大多数networking中导致约600的错误。 我看到错配超过了10,000秒。 在这种情况下，有没有比NTP更好的东西？ 我知道NTP喜欢非常频繁，一致地访问服务器，给出几乎相同的答案。 我不会有这个 我应该configuration多less个内部NTP服务器，以便在互联网中断期间，我的内部时间在封闭networking中是一致的？ 没有人类进入。 无论多大的不匹配，服务器必须尝试自我纠正。 离散的步骤是非常糟糕的。 无论多大的不匹配，校正必须“摆动”，而不是“步进”。 我知道这可能需要很长时间才能纠正。
我已经注意到了这一段时间，这对我来说从来没有任何意义： 为什么ntpd需要在这么多地址上进行监听？ 例如，Debian机器： $ netstat 原始本地地址外地址程序名称 udp 0.0.0.0:123 0.0.0.0:* ntpd udp 127.0.0.1:123 0.0.0.0:* ntpd udp [LAN]：123 0.0.0.0:* ntpd udp [IPv4]：123 0.0.0.0:* ntpd udp6 ::: 123 ::: * ntpd udp6 :: 1：123 ::: * ntpd udp6 [link-local] ::: * ntpd udp6 [IPv6] ::: * ntpd 这个（模糊的） netstat清单显示了nptd监听IPv4和IPv6的广播，本地，局域网和全局地址。 为什么ntpd如此混杂？
难道客人不知何故inheritance了主机的系统时间？ 运行相同的守护进程以在同一台机器上多次获得相同的结果似乎毫无意义，但在阅读KVM或Xen文章时，我没有发现与时间有关的任何内容。 我的理解是，客人得到主机启动时间，但它可能会分开。 那是对的吗 ？
我想在本地networking上设置几个Stratum 2时间服务器。 与购买三个1U服务器相比，虚拟机肯定是一个更便宜的方法。 这样做会有什么限制？ 也就是说，精度会受到多大程度的影响？ 另外，我的直觉是，这些本地时间服务器应该驻留在不同的物理机器上，以减轻任何硬件违规。 这个直觉是正确的吗？ 编辑我应该说，“虚拟机”我并不特指 VMware 。 相反，我的意思是虚拟化实例的一般概念。
我注意到，在将Stack Overflow播客的第52集中列出的reg设置更改为pool.ntp.org之后 ，我的箱子不断从gordo.foofus.net请求时间。 托pipe在该框上的网站非常奇怪。 这是一个有效的时间服务器？
我们正在处理在同一台服务器上的NTPreflection/放大攻击 。 这个问题是专门针对NTPreflection攻击的，而不是针对DDoS的。 这是交通： 它在我们的路由器上搅动了一些CPU： 不幸的是，它不足以导致我们的上游供应商堵塞交通，这意味着它传递给我们。 我们使用以下规则来阻止源自端口123的NTPstream量： -p udp –sport 123 -j DROP 这是IPTables中的第一条规则。 我search了很多，我找不到很多有关如何使用IPTables来缓解NTPreflection攻击的信息。 而那里的一些信息似乎是不正确的。 这个IPTables规则是否正确？ 除了联系我们的上游networking提供商之外，还有什么可以补充或减轻NTPreflection/放大攻击？ 另外：因为这些攻击者必须使用networking 允许欺骗分组中的IP地址 没有打补丁，大约在2010年的NTP代码 有没有我们可以报告这些IP地址的全球票据交换所，以便他们得到修复，停止允许欺骗的数据包，并修补他们的NTP服务器？
我有ntpd在我的服务器上运行。 这是所有的默认设置，除了我评论说它是一个服务器到其他机器的能力： # restrict -4 default kod notrap nomodify nopeer noquery # restrict -6 default kod notrap nomodify nopeer noquery restrict default ignore 如果我运行ntpdate -q ntp.ubuntu.com ，我被告知我的机器时钟已经closures了7秒钟。 这是怎么回事？ 我怎样才能诊断发生了什么，有没有我可以打开的日志？ 更多信息＃1 # ntpq -np remote refid st t when poll reach delay offset jitter ============================================================================== 91.189.94.4 193.79.237.14 2 u 30 64 7 108.518 -0.136 0.361 更多信息＃2 […]
Debian Stable（5.0.3）服务器运行ntpd ，并连接到互联网。 但系统时钟仍然是5分钟左右的错误。 $ /etc/init.d/ntp status NTP server is running.. /etc/ntp.conf相关部分（我认为）： driftfile /var/lib/ntp/ntp.drift statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable server 0.europe.pool.ntp.org server 1.europe.pool.ntp.org server 2.europe.pool.ntp.org server 3.europe.pool.ntp.org 我知道NTP不一定能及时带来时钟。 但是，为了合理地期望NTP完成了它的工作并同步了时钟，还需要等待多less个小时或几天？ 我是否缺less一些其他configuration文件或选项，或者只是做错了什么？ 是ntp （而不是例如ntpdate ）这个正确的工具？ 有没有快速的方法来检查configuration是否正确以及所选的NTP服务器是否返回正确的时间？ 编辑 […]