Quais são as desvantagens de desativar o tinker panic 0 no NTP?

Às vezes, temos o problema de que os novos servidores estejam com a hora errada na bios; portanto, o tempo pode demorar um mês.

Quando você suspende uma VM no VMware e depois a suspende, o tempo também será desligado. Como o NTP não é sincronizado após um deslocamento máximo, estou pensando em usar o tinker panic 0 no /etc/ntp.conf.

Por que motivo existe um deslocamento máximo padrão de 1000 segundos que faz com que o NTP pare o tempo de sincronização? Estamos usando o Puppet para configurar o NTP, estou pensando em definir o tinker panic 0 no ntp.conf, para que o NTP seja sincronizado de qualquer maneira. Quais são as desvantagens de fazer isso?

A causa da não sincronização com um servidor cujo tempo é tão diferente está documentada aqui :

5.1.1.4 O que acontece se o tempo de referência mudar?

Idealmente, o tempo de referência é o mesmo em todo o mundo. Uma vez sincronizado, não deve haver alterações inesperadas entre o relógio do sistema operacional e o relógio de referência. Portanto, o NTP não possui métodos especiais para lidar com a situação.

Em vez disso, a reação do ntpd dependerá do deslocamento entre o relógio local e o tempo de referência. Para um pequeno deslocamento, o ntpd ajustará o relógio local como de costume; para compensações pequenas e maiores, o ntpd rejeitará o tempo de referência por um tempo. Neste último caso, o relógio do sistema operacional continuará com as últimas correções efetivas enquanto o novo tempo de referência estiver sendo rejeitado. Após algum tempo, pequenas compensações (significativamente menos de um segundo) serão reduzidas (ajustadas lentamente), enquanto compensações maiores farão com que o relógio seja acelerado (ajustado novamente). Grandes compensações são rejeitadas e o ntpd será encerrado, acreditando que algo muito estranho deve ter acontecido.

Na minha configuração atual do NTP, também controlada por puppet, forço a sincronização com o servidor, tanto no ntp.confarquivo, usando tinker paniccomo nas configurações do daemon ( /etc/sysconfig/ntpd), conforme descrito na página de ntpd(8)manual:

-g Normalmente, o ntpd sai com uma mensagem no log do sistema se o deslocamento exceder o limite de pânico, que é 1000 s por padrão. Esta opção permite que o tempo seja definido para qualquer valor sem restrição; no entanto, isso pode acontecer apenas uma vez. Se o limite for excedido depois disso, o ntpd será encerrado com uma mensagem no log do sistema. Esta opção pode ser usada com as opções -q e -x.

Faço isso porque posso confiar no servidor NTP ao qual estou me conectando.

A parte relevante do módulo que se aplica aos clientes é a seguinte:

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'],
  }

}

E o conteúdo dos arquivos referenciados são:

$ 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"

e:

$ 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

A hierapeça está faltando aqui, mas você entendeu.

O pior exemplo seria ataques ao seu receptor de GPS voltado para a LAN, isso já foi provado possível e é por isso que o NTP nesses casos "sai" do que quebra imediatamente qualquer coisa. Esse tipo de problema, ou erros repentinos de software, eram esperados no momento do design do NTP, e também ambos podem acontecer.

Um mecanismo de proteção no algoritmo é a detecção do que eles chamam de falseticker , mas isso só pode detectar alguns problemas, principalmente se um relógio upstream enviar um tempo para trás de repente.

Se for apenas sobre "relógio errado na hora de início":

• você pode usar / etc / ntp / step-tickers (no RHEL *, o Debian nunca entendeu a idéia). O arquivo step-tickers leva um ou mais servidores NTP para executar um ntpdate antes de iniciar o próprio ntpd.
• Como alternativa (ou além disso), existe a opção -g para o ntpd , que permite compensações feias, mas apenas quando são encontradas no início.