Які недоліки відключення Tinker panic 0 в NTP?

У нас іноді виникає проблема з тим, що нові сервери мають неправильний час в біографії, тому час може бути вимкнений за місяць.

Якщо ви призупинили VM у VMware і потім скасували його, час також буде вимкнено. Оскільки NTP не синхронізується після максимального зміщення, я розглядаю можливість використання панікера 0 в папці /etc/ntp.conf.

Яка причина того, що існує максимальне зміщення за замовчуванням 1000 секунд, через яке NTP припиняє синхронізувати час? Ми використовуємо Puppet для налаштування NTP, я розглядаю можливість встановити тинкер паніку 0 в ntp.conf, тому NTP буде синхронізуватися в будь-якому випадку. Які недоліки цього робити?

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

5.1.1.4. Що станеться, якщо довідковий час зміниться?

В ідеалі орієнтовний час однаковий скрізь у світі. Після синхронізації не повинно відбуватися жодних несподіваних змін між тактовою частотою операційної системи та базовим годинником. Тому НТП не має спеціальних методів вирішення ситуації.

Натомість реакція 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, а також може відбутися і те, і інше.

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

Якщо мова йде лише про "неправильний годинник в момент запуску":

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