NTPでtinker panic 0を無効にすることの欠点は何ですか？

10

新しいサーバーのBIOSの時刻が間違っているため、1か月ずれている可能性があるという問題があります。

VMwareでVMを一時停止してから一時停止を解除すると、時間もオフになります。NTPは最大オフセット後に同期しないため、/ etc / ntp.confでtinker panic 0を使用することを検討しています。

NTPが時間の同期を停止する原因となるデフォルトの最大オフセットが1000秒になっている理由は何ですか？Puppetを使用してNTPを設定しています。ntp.confでtinker panic 0を設定して、NTPがとにかく同期するようにすることを検討しています。これを行うことの欠点は何ですか？

— ウジャイン
ソース

2

VMwareはあなたが使うべきだとさえ言っているtinker panic 0

— Marki

8

時刻が非常に異なるサーバーと同期しない原因は、次のとおりです。

5.1.1.4。参照時間を変更するとどうなりますか？

理想的には、基準時間は世界中のどこでも同じです。同期が完了すると、オペレーティングシステムのクロックと基準クロックの間に予期しない変更が発生することはありません。したがって、NTPにはこの状況を処理する特別な方法はありません。

代わりに、ntpdの反応は、ローカルクロックと基準時間の間のオフセットに依存します。小さなオフセットの場合、ntpdは通常どおりローカルクロックを調整します。オフセットが小さい場合と大きい場合、ntpdはしばらく参照時間を拒否します。後者の場合、オペレーティングシステムのクロックは、新しい参照時間が拒否されている間、最後の修正が有効な状態で続行されます。しばらくすると、小さなオフセット（大幅に1秒未満）がスルーされます（ゆっくり調整されます）。一方、オフセットが大きくなると、クロックがステップ実行されます（新たに設定されます）。非常に奇妙なことが起こったはずであると信じて、巨大なオフセットは拒否され、ntpdはそれ自体を終了します。

マンページで説明されているように、現在のNTP構成では、これもによって制御さpuppetれていntp.confます。ファイルを使用してtinker panic、およびデーモン設定（/etc/sysconfig/ntpd）の両方でサーバーとの同期を強制しますntpd(8)。

-g通常、オフセットがパニックしきい値（デフォルトでは1000秒）を超えると、ntpdはシステムログへのメッセージとともに終了します。このオプションを使用すると、時間を制限なしに任意の値に設定できます。ただし、これは一度だけ起こります。その後しきい値を超えると、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部分はここにはありませんが、アイデアはわかります。

— ダウド
ソース

3

最悪の例はLANに面したGPS受信機への攻撃です。これは可能であることが証明されており、そのためNTPはすぐに何かを壊すのではなく、「脱退」するのです。この種の問題、または突然のソフトウェアバグは、NTPの設計時に予期されていましたが、両方が発生する可能性もあります。

アルゴリズムの保護メカニズムの1つは、それらがfalsetickerと呼ぶものの検出ですが、それは主にアップストリームクロックが突然逆方向の時間を送信する場合、いくつかの問題のみを検出できます。

それが「開始時の誤ったクロック」だけの場合：

/ etc / ntp / step-tickersを使用できます（RHEL *では、Debianはアイデアを思いつきませんでした）。step-tickersファイルは、ntpd自体を開始する前に、1つ以上のNTPサーバーに対してntpdateを実行します。
あるいは（またはさらに）ntpdに-gオプションがあり、これは醜いオフセットを許可しますが、それらが開始時に見つかった場合に限られます。

— フロリアン・ハイグル
ソース