web-dev-qa-db-ja.com

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

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

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

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

redhatpuppetntprhel6
10
ujjain

時刻が非常に異なるサーバーと同期しない原因は文書化されています here ：

5.1.1.4。基準時間が変更されるとどうなりますか？

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

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

私の現在のNTP構成、これもpuppetによって制御される）では、_ntp.conf_ファイルで_tinker panic_を使用して、サーバーとの同期を強制します。 ntpd(8) マンページで説明されているように、デーモン設定（_/etc/sysconfig/ntpd_）で：

-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の部分はここにはありませんが、アイデアはわかります。

8
dawud

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

アルゴリズムの保護メカニズムの1つは、falsetickerと呼ばれるものの検出ですが、これは一部の問題のみを検出できます。突然の時間。

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

  • / etc/ntp/step-tickersを使用できます（RHEL *では、Debianはアイデアを思いつきませんでした）。ステップティッカーファイルは、ntpd自体を起動する前に、ntpdateを実行するために1つ以上のNTP=サーバーを必要とします。
  • 代わりに（またはさらに）-gオプションがntpdにあり、これは醜いオフセットを許可しますが、それらが最初に見つかった場合に限られます。
3
Florian Heigl