Я пытаюсь настроить машину для работы в качестве сервера ntp, с которым другие локальные машины будут синхронизировать свое время. Это должно происходить независимо от того, подключен ли компьютер-сервер ntp к Интернету, то есть: не важно, чтобы время было правильным, просто машины синхронизированы друг с другом.
Мои файлы конфигурации следующие:
NTP-сервер /etc/ntp.conf
driftfile /var/lib/ntp/ntp.drift
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 127.127.1.0
fudge 127.127.1.0 stratum 10
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1
Клиент NTP /etc/ntp.conf
driftfile /var/lib/ntp/ntp.drift
server 192.168.1.146 iburst
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1
Я меняю время на сервере, а затем запускаю ntp-сервер с sudo /etc/init.d/ntp start И попробуйте проверить, что клиент может получить обновление ntp с sudo ntpdate 192.168.1.146
Это работает, но только при подключении к Интернету (даже если мастер имеет время, установленное моей командой, а не с внешнего сервера / с ntp).
Что-то не так в моих файлах конфигурации? Какой-нибудь шаг, который мне не хватает?
Некоторое время назад я дал подробный ответ о том, как мы делаем именно то, что вы собираетесь делать в наших центрах обработки данных. С тех пор, как я опубликовал этот пост, мало что изменилось.
Ссылка на пост:
Использование NTP для синхронизации группы серверов Linux с общим источником времени
Я предполагаю, что ваш сервер времени подключен к Интернету достаточно часто, чтобы NTP мог определить вашу частоту ошибок и дать хорошее предположение о том, как дисциплинировать часы ядра.
Прежде всего, я предлагаю удалить следующие две строки из файла /etc/ntp.conf. Они вызывают проблемы в долгосрочной перспективе и редко нужны. Пока NTP-серверу удалось синхронизировать и начать регулировать часы ядра, он все равно должен выдавать время, даже если Интернет на некоторое время отключен.
server 127.127.1.0
fudge 127.127.1.0 stratum 10
Во-вторых, запустите «ntpq -p» на своем сервере времени, чтобы выяснить, синхронизирован ли он с общедоступными серверами времени, прежде чем начинать тестирование клиентов. Ручная установка времени на сервере - просто плохая идея при тестировании. Не делай этого. Запустите свой сервер времени, затем дайте ему посидеть и синхронизироваться с вышестоящими серверами времени в течение 30 минут. Ваш внутренний сервер времени будет не раздайте время, пока оно не синхронизируется с общедоступными серверами времени (и я думаю, что PPM должно быть меньше 500). NTP не будет предоставлять клиентам то, что он считает «безумным» временем, и вам нужно дать ему 10-30 минут, чтобы решить, какие источники времени следует отслеживать.
Затем вы можете запустить "ntpq -p" на клиентах, чтобы увидеть, синхронизированы ли они и насколько они близки к вашему серверу времени.
В-третьих, вы можете захотеть перейти с (3) серверов в файле ntp.conf вашего сервера времени на (5) или (6). Прямо сейчас, если один из ваших троих сойдет с ума или станет недоступным, NTP не сможет сказать, какой из оставшихся двух предлагает лучший сигнал времени.
Есть несколько вещей, которые контролируют, насколько хорошо NTP будет поддерживать часы ядра в дисциплине, когда серверы времени недоступны. Один из них - PPM (см. «Ntpdc -c kerninfo»), который показывает, насколько далеко часы TSC, HPET или APIC от реальности (на основе общедоступных серверов времени). Другой - это колебания температуры и / или настройки управления питанием, которые изменяют частоту процессора. Кроме того, есть качество временных кристаллов, которое может быть хорошим, если вам повезет, или очень плохим.
И, возможно, вам нужно рассмотреть источник времени GPS или WWVB.