Иногда у нас возникает проблема с тем, что у новых серверов неправильное время в BIOS, поэтому время может отсутствовать на месяц.
Когда вы приостанавливаете работу виртуальной машины в VMware, а затем отключаете ее, время тоже отключится. Поскольку NTP не синхронизируется после максимального смещения, я рассматриваю возможность использования tinker panic 0 в /etc/ntp.conf.
В чем причина того, что максимальное смещение по умолчанию в 1000 секунд заставляет NTP прекращать синхронизацию времени? Мы используем Puppet для настройки NTP, я планирую установить для него tinker panic 0 в ntp.conf, чтобы NTP все равно синхронизировался. Какие у этого недостатки?
Причина отсутствия синхронизации с сервером, время которого сильно отличается, задокументирована. Вот:
5.1.1.4. Что произойдет, если эталонное время изменится?
В идеале базисное время одинаково во всем мире. После синхронизации не должно быть никаких неожиданных изменений между часами операционной системы и эталонными часами. Следовательно, у NTP нет специальных методов для обработки ситуации.
Вместо этого реакция ntpd будет зависеть от смещения между местными часами и эталонным временем. Для небольшого смещения ntpd будет настраивать локальные часы как обычно; для малых и больших смещений ntpd на некоторое время отклонит эталонное время. В последнем случае часы операционной системы продолжат работу с последними действующими поправками, в то время как новое эталонное время отклоняется. Через некоторое время небольшие смещения (значительно меньше секунды) будут повернуты (медленно скорректированы), в то время как большие смещения приведут к пошаговому смещению часов (установлению заново). Огромные смещения отклоняются, и ntpd завершает свою работу, полагая, что произошло что-то очень странное.
В моей текущей конфигурации NTP, также контролируемой puppet, Я принудительно синхронизирую с сервером, как в ntp.conf файл, используя tinker panic, а в настройках демона (/etc/sysconfig/ntpd), как описано в ntpd(8) страница руководства:
-g Обычно ntpd завершает работу с сообщением в системный журнал, если смещение превышает порог паники, который по умолчанию равен 1000 с. Эта опция позволяет установить любое значение времени без ограничений; однако это может произойти только один раз. Если после этого порог будет превышен, ntpd выйдет с сообщением в системный журнал. Этот параметр можно использовать с параметрами -q и -x.
Я делаю это, потому что могу доверять NTP-серверу, к которому подключаюсь.
Соответствующая часть модуля, которая применяется к клиентам, выглядит следующим образом:
class ntp (
$foo
$bar
...
){
$my_files = {
'ntp.conf' => {
path => '/etc/ntp.conf',
content => template("ntp/ntp.conf.$template.erb"),
selrole => 'object_r',
seltype => 'net_conf_t',
require => Package['ntp'], },
'ntp-sysconfig' => {
path => '/etc/sysconfig/ntpd',
source => 'puppet:///modules/ntp/ntp-sysconfig',
require => Package['ntp'], },
...
}
$my_files_defaults = {
ensure => file,
owner => 'root',
group => 'root',
mode => '0644',
selrange => 's0',
selrole => 'object_r',
seltype => 'etc_t',
seluser => 'system_u',
}
create_resources(file, $my_files, $my_files_defaults)
exec { 'ntp initial clock set':
command => '/usr/sbin/ntpd -g -q -u ntp:ntp',
refreshonly => true,
timeout => '-1',
subscribe => File['/etc/ntp.conf'],
}
}
И содержимое указанных файлов:
$ cat devops/puppet/modules/ntp/files/ntp-sysconfig
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -g -a"
и:
$ cat devops/puppet/modules/ntp/templates/ntp.conf.RedHat.erb
# HEADER: This file was autogenerated by puppet.
# HEADER: While it can still be managed manually, it
# HEADER: is definitely not recommended.
tinker panic 0
<% server.each do |ntpserver| -%>
server <%= ntpserver %> autokey
<% end -%>
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
crypto pw hunter2
crypto randfile /dev/urandom
keysdir /etc/ntp
В hiera часть здесь отсутствует, но идею вы поняли.
Наихудшим примером могут быть атаки на ваш GPS-приемник, подключенный к локальной сети, это было доказано, и поэтому NTP в таких случаях скорее «уходит», чем сразу что-либо ломает. Такого рода проблемы или внезапные программные ошибки ожидались во время разработки NTP, и то и другое тоже может случиться.
Одним из механизмов защиты в алгоритме является обнаружение того, что они называют фальцет, но это может обнаружить только некоторые проблемы, в основном, если восходящие часы внезапно отправляют обратное время.
Если речь идет только о "неправильных часах при запуске":