Прошу совета. Прочитал почти все что нашёл в Google по настройкам ntpd, но странная проблема заставляет просить...
Описание ситуации:
Локальная сеть 192.168.*.* внутри сети никаких файрволов и пр.
Два сервера ntp в локальной сети: 192.168.1.2 и 192.168.1.9
Есть два сервера обеспечивающие работу некоего web-приложения 192.168.1.5, 192.168.1.6 с FreBSD 7.0 и еще один тестовый сервер на FreeBSD 6.3 192.168.1.96
Задача:
Синхронизировать время с использованием ntpd с серверами точного времени в локальной сети.
Настройки:
На всех трех серверах следующие настройки.
/etc/rc.conf:
Код: Выделить всё
ntpd_enable="YES"
ntpd_flags="-c /etc/ntp.conf -l /var/log/ntpd.log -p /var/run/ntpd.pid -f /var/db/ntp.drift"
ntpdate_enable="YES"
ntpdate_flags="-b 192.168.1.2 192.168.1.9"
Код: Выделить всё
server 192.168.1.9
server 192.168.1.2 prefer
restrict default ignore
restrict 127.0.0.1
Код: Выделить всё
13 Oct 09:26:34 ntpd[22751]: ntpd exiting on signal 15
13 Oct 09:26:37 ntpd[64531]: logging to file /var/log/ntpd.log
13 Oct 09:26:37 ntpd[64531]: ntpd 4.2.0-a Tue Jan 15 23:29:41 UTC 2008 (1)
13 Oct 09:26:37 ntpd[64531]: precision = 1.955 usec
13 Oct 09:26:37 ntpd[64531]: no IPv6 interfaces found
13 Oct 09:26:37 ntpd[64531]: kernel time sync status 2040
13 Oct 09:26:37 ntpd[64531]: frequency initialized 0.000 PPM from /var/db/ntp.drift
Дальше еще интереснее:
# ntpq -p
Код: Выделить всё
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.2 .INIT. 16 u - 1024 0 0.000 0.000 4000.00
192.168.1.9 .INIT. 16 u - 1024 0 0.000 0.000 4000.00
# ntpdate -q 192.168.1.2
Код: Выделить всё
server 192.168.1.2, stratum 3, offset -10.465441, delay 0.02583
14 Oct 12:37:14 ntpdate[69532]: step time server 192.168.1.2 offset -10.465441 sec
Код: Выделить всё
server 192.168.1.9, stratum 4, offset -10.475353, delay 0.04147
14 Oct 12:37:58 ntpdate[69533]: step time server 192.168.1.9 offset -10.475353 sec
P.S.: Я понимаю что можно через cron синхронизировать время принудительно... Но вариант не подходит ввиду критичности одинаковости времени на серверах и скачкообразного изменения времени в случае такой синхронизации.