信頼できないNTPピアを処理する方法は?

信頼できないNTPピアを処理する方法は?

私はlynis 1.5.6を実行しており、次のログメッセージを受け取りました。

Performing test ID TIME-3120 (Check unreliable NTP peers)
Test: Checking unreliable ntp peers
Result: Found one or more unreliable peers (marked with a minus or dash sign)
Unreliable peer: 50.7.96.4
Suggestion: Check ntpq peers output for unreliable ntp peers and correct/replace them [TIME-3120]

私は走った

解釈されたコマンドを提供する sudo ntpq -iここ。ただし、ピアを変更または交換する方法については説明しません。

提案された変更を適用しました。ここしかし、まだLynisの提案があります。 /var/log/ntpstatsを確認しましたが、そこには何もありません。私はisc.sans.eduによると、Abovenet Communicationsである信頼できないピアを50.7.0.147と指定しました。

Lenisのこの提案を無視できますか?

ベストアンサー1

この警告は無視してかまいません。正直なところ、これはピアステータスコードの正確な説明ではありません。マイナス記号は、サーバーが信頼できないという意味ではありません。これは、クラスタリングアルゴリズムによってピアが削除されたことを意味します。これはクロック選択アルゴリズムの一般的な副産物です。

もう一つの答えは、プールプロジェクトでサーバーを使用することを提案しました。プールプロジェクトはサーバーを監視し、失敗したサーバーを削除します。しかし、ピアステータスコードに負の記号が含まれているサーバーは削除されません。さらに、顧客はプール項目がランダムに割り当てられるサーバーを制御することはできません。まともなピアのリストが与えられると、サーバーはクラスタアルゴリズムによって拒否される可能性が高くなります。これは、遅延時間の急増や温度変化など、さまざまな理由が原因である可能性があります。これは起動したばかりのコンピュータのntpqqのビルボードです。私のローカルntpサーバー(Tier 1 GPS)、私に近い別のTier 1サーバー、プールプロジェクトでランダムに選択された4つのサーバーがあります。

 dfc@jumbo:~$ ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
 ==============================================================================
 *ronin.llamahaus .GPS.            1 u   58   64    7    0.187   -0.168   0.789
 +clock1.alb1.ino .CDMA.           1 u   59   64    7   37.231    6.703   3.304
 +pool-test.ntp.o 204.123.2.5      2 u   60   64    7   77.727    1.775   1.139
 -defiance.terran 209.118.204.201  3 u   59   64    7   50.638   10.097   1.630
 -ponderosa.piney 209.51.161.238   2 u   57   64    7   37.756    9.511   2.780
 +greenwix.netlob 216.218.254.202  2 u   56   64    7   87.031   -2.368   1.846

前にマイナス記号が付いた2つのサーバーがあり、それらはプールサーバーです。 ntpには時間を同期させるオプションはありません。アスタリスクのあるサーバーは同期しているピアであり、プラス記号を持つサーバーは別の候補です。

TLDR:Lynisの警告を無視してください。詳細については、ntp.orgでドキュメントを確認してください。ピアステータスコード。

おすすめ記事