Каковы недостатки отключения паники tinker 0 в NTP?

У нас иногда возникает проблема с тем, что на новых серверах неправильное время в BIOS, поэтому время может быть отключено на месяц.

Когда вы приостановите виртуальную машину в VMware, а затем отключите ее, время также будет выключено. Поскольку NTP не синхронизируется после максимального смещения, я рассматриваю использование паники tinker 0 в /etc/ntp.conf.

В чем причина того, что по умолчанию установлено максимальное смещение в 1000 секунд, из-за которого NTP прекращает синхронизацию? Мы используем Puppet для настройки NTP, я собираюсь установить для него настройку паники tinker 0 в ntp.conf, поэтому NTP все равно будет синхронизироваться. Каковы недостатки этого?

Причина отсутствия синхронизации с сервером, время которого отличается, задокументирована здесь :

5.1.1.4. Что произойдет, если эталонное время изменится?

В идеале эталонное время везде одинаково. После синхронизации не должно быть никаких неожиданных изменений между часами операционной системы и опорными часами. Поэтому NTP не имеет специальных методов для обработки ситуации.

Вместо этого реакция ntpd будет зависеть от смещения между местными часами и эталонным временем. Для небольшого смещения ntpd будет корректировать локальные часы как обычно; для малых и больших смещений, пЪрд отклонит отсчета времени на некоторое время. В последнем случае часы операционной системы будут продолжать работать с последними исправлениями, действующими, пока новое эталонное время будет отклонено. Через некоторое время небольшие смещения (значительно меньше секунды) будут поворачиваться (регулироваться медленно), тогда как большие смещения приводят к тому, что часы переключаются (устанавливаются заново). Огромные смещения отклоняются, и ntpd прекратит работу, полагая, что должно произойти что-то очень странное.

В моей текущей конфигурации NTP, также управляемой puppet, я принудительно синхронизирую с сервером, как в ntp.confфайле, используя tinker panic, так и в настройках демона ( /etc/sysconfig/ntpd), как описано в ntpd(8)man-странице:

-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, и оба они могут возникнуть.

Одним из механизмов защиты в алгоритме является обнаружение того, что они называют фальшивомонетчиком , но это может обнаружить только некоторые проблемы, в основном, если часы восходящего направления внезапно отправляют время назад.

Если речь идет только о «неправильных часах во время запуска»:

• Вы можете использовать / etc / ntp / step-tickers (на RHEL *, Debian никогда не понимал). Файл step-tickers использует один или несколько серверов NTP для запуска ntpdate до запуска самого ntpd.
• в качестве альтернативы (или в дополнение) есть опция -g для ntpd , которая допускает ужасные смещения, но только тогда, когда они обнаружены при запуске.