У меня есть сервер FreeIPA, работающий на Centos 6, и одна из его функций - обеспечивать синхронизацию времени с клиентскими хостами. NTP - это версия 4.2.6
Проблема в том, что собственная синхронизация NTP не работает должным образом, и я не понимаю, почему. Затем это влияет на функции Kerberos / аутентификации.
Сервер FreeIPA не может напрямую подключиться к Интернету, поэтому ему необходимо использовать другой сервер, который может видеть Интернет.
Вот список nptq с «главного» сервера времени с IP-адресом 10.20.1.23.
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*46.101.52.119 81.174.136.35 2 u 111 128 377 10.234 0.865 3.491
+51.141.4.8 85.199.214.102 2 u 121 128 377 14.806 -0.365 2.858
+178.62.16.103 195.66.241.3 2 u 117 128 377 10.677 0.816 1.931
+129.250.35.250 249.224.99.213 2 u 100 128 377 14.064 -1.678 1.525
Все довольно стандартно. 46.101.52.119 используется как ссылка
Вот вывод другого клиента, использующего этот сервер для синхронизации времени.
# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.20.1.23 46.101.52.119 3 u 230 256 377 0.439 1095.65 34.637
127.127.1.0 .LOCL. 5 l 49m 64 0 0.000 0.000 0.000
Это нормально, что 10.20.1.23 использует 46.101.52.119 в качестве ссылки
Но когда я иду на свой сервер FreeIPA, я получаю
# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.20.1.23 LOCAL(0) 6 u 97 128 377 32.193 92334.0 17.646
Refid отличается, и он говорит мне, что у нас есть примерно полторы минуты смещения. Фактически, я вручную установил часы с точностью до секунды, но теперь это работает с помощью ntpd.
Также см: Почему NTP синхронизируется с ЛОКАЛЬНЫМ, а не с удаленным сервером?
Кажется, что происходит то, что ваши локальные часы идут слишком быстро по отношению к источнику времени, с которым они пытаются синхронизироваться. В результате он удаляет источник синхронизации и использует то, что считает лучшим ответом, а именно собственный локальный источник времени ядра. Есть несколько вещей, которые вы можете сделать, чтобы облегчить это состояние и попытаться привести свои местные часы в лучшую форму.
Во-первых, чтобы решить эту проблему, вы можете установить локальные часы на более высокий уровень, чем ваши источники синхронизации. Пример в вашем ntp.conf файл будет:
server 127.0.0.1
fudge 127.0.0.1 stratum 16 ## or some value greater than it's synchronization peer
Это сделает его менее желательным источником, когда NTP начнет выбор одноранговых узлов для синхронизации.
Затем, если ваши местные часы действительно не в порядке, вы можете настроить их, используя adjtimex. БУДЬТЕ ОСТОРОЖНЫ, в этот момент вы играете с аппаратными часами. Пример мог бы выглядеть примерно так:
# adjtimex -p ## List out how the clock is currently running...
mode: 0
offset: 0
frequency: 0
maxerror: 0
esterror: 0
status: 64
time_constant: 4
precision: 1
tolerance: 32768000
tick: 9900
raw time: 1272299204s 17444us = 1272299204.017444
return value = 5
И отрегулируйте значение поля «галочка»:
adjtimex -t 9800
Перезапустите ntpd и посмотрите, как он себя ведет. Если это делает джиттер более приемлемым, оставьте его на этом уровне или при необходимости отрегулируйте снова. NTP может быть несколько неясным, и я надеюсь, что помог кое-чему, но если вам нужна дополнительная информация, я бы доверял источнику на http://support.ntp.org
Ссылки