Tinker panik 0'ı NTP'de devre dışı bırakmanın dezavantajları nelerdir?

Bazen yeni sunucuların bios'ta yanlış zamana sahip olma sorunu yaşıyoruz, bu nedenle zaman bir ay kapalı olabilir.

VMware'de bir VM'yi askıya aldığınızda ve ardından askıya aldığınızda, zaman da kapanacaktır. NTP bir maksimum ofsetten sonra senkronize olmadığından, /etc/ntp.conf dosyasında tinker panik 0'ı kullanmayı düşünüyorum.

NTP'nin senkronizasyon süresini durdurmasına neden olan varsayılan maksimum 1000 saniye ofsetinin nedeni nedir? NTP'yi kurmak için Kukla kullanıyoruz, ntp.conf'da tinker panik 0'ı ayarlamayı düşünüyorum, bu yüzden NTP yine de senkronize edilecek. Bunu yapmanın dezavantajları nelerdir?

Zamanı çok farklı olan bir sunucuya senkronize olmamanın nedeni burada belgelenmiştir :

5.1.1.4. Referans Zamanı değişirse ne olur?

İdeal olarak referans süresi dünyanın her yerinde aynıdır. Senkronize edildikten sonra, işletim sisteminin saati ile referans saati arasında beklenmedik bir değişiklik olmamalıdır. Bu nedenle, NTP'nin durumu ele almak için özel bir yöntemi yoktur.

Bunun yerine, ntpd'nin reaksiyonu yerel saat ile referans süresi arasındaki ofsete bağlı olacaktır. Küçük bir ofset için ntpd yerel saati her zamanki gibi ayarlayacaktır; küçük ve büyük ofsetler için, ntpd bir süre referans süresini reddeder. İkinci durumda, işletim sisteminin saati, yeni referans süresi reddedilirken geçerli olan son düzeltmelerle devam edecektir. Bir süre sonra, küçük ofsetler (bir saniyeden önemli ölçüde daha az) döndürülür (yavaşça ayarlanır), daha büyük ofsetler saatin adımlanmasına (yeniden ayarlanmasına) neden olur. Büyük ofsetler reddedilir ve ntpd, çok garip bir şeyin olması gerektiğine inanarak kendisini feshedecektir.

Ayrıca, tarafından denetlenen geçerli NTP yapılandırmasında, puppetsunucuda eşitlemeyi hem ntp.confdosyada hem de kullanarak tinker panicve daemon ayarlarında ( /etc/sysconfig/ntpd), ntpd(8)manpage'de açıklandığı gibi zorla:

-g Normalde, ofset varsayılan olarak 1000 s olan panik eşiğini aşarsa, ntpd sistem günlüğüne bir mesajla çıkar. Bu seçenek, zamanın herhangi bir sınırlama olmaksızın herhangi bir değere ayarlanmasına izin verir; ancak bu sadece bir kez olabilir. Bundan sonra eşik aşılırsa, ntpd sistem günlüğüne bir mesajla çıkar. Bu seçenek -q ve -x seçenekleriyle kullanılabilir.

Bunu yapıyorum çünkü bağlandığım NTP sunucusuna güvenebiliyorum.

Modülün istemciler için geçerli olan ilgili kısmı aşağıdaki gibidir:

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

}

Ve başvurulan dosyaların içeriği:

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

ve:

$ 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

hieraBölümü burada eksik, ama fikir olsun.

En kötü örnek, LAN'a bakan GPS alıcınıza yapılan saldırılardır, bunun mümkün olduğu kanıtlanmıştır ve bu durumda NTP'nin bir şeyi hemen kırmak yerine "ayrılmasının" nedeni budur. NTP'nin tasarım zamanında bu tür bir sorun veya ani yazılım hataları bekleniyordu ve her ikisi de olabilir.

Algoritmadaki bir koruma mekanizması, bir falseticker olarak adlandırdıkları şeyin algılanmasıdır , ancak bu, yalnızca bir yukarı akış saati aniden bir geri zaman gönderirse, yalnızca bazı sorunları algılayabilir.

Yalnızca "başlangıç ​​zamanında yanlış saat" ile ilgili ise:

• Kullanabileceğiniz / etc / ntp / üvey Şeritler (RHEL * üzerine, Debian fikrim var asla). Step-tickers dosyası, ntpd'nin kendisini başlatmadan önce bir ntpdate çalıştırmak için bir veya daha fazla NTP sunucusu alır.
• alternatif olarak (veya ek olarak) ntpd için -g seçeneği vardır , bu da çirkin ofsetlere izin verir, ancak yalnızca başlangıçta bulunduklarında.