間違ったシステムクロックからどのような結果/影響が生じますか？

システムクロックの設定が間違っていると、どのような問題が発生するのでしょうか。

主にサーバー、特にLinuxまたはUNIXのようなシステムに影響を与える潜在的な問題に関心があります。

そして、システム時間がどれだけオフになっているかに応じて、これらの結果はどのくらい深刻ですか？たとえば、5分、30分、1時間、1日です。

1つには、すべてのログのタイムスタンプがオフになり、他のサーバーと同期されなくなるため、状況がいつ発生したかを把握することが非常に困難になります。また、一部のセキュリティプロトコル（たとえば、ケルベロス）では、時刻の同期に依存しています。

だから私が言っていることは、ほとんどのことが正常に動作し続け、正確な時間に依存する一部のプロトコルまたはアプリケーションが壊れる可能性があり、管理者は一般的にそれについていくつかの頭痛を感じるでしょう。

pool.ntp.orgやNISTなどのプロバイダーに対してNTPを構成し、1日と呼びます。

ここにいくつかあります：

• MySQLレプリケーション
• 現在の日付/時刻にnow（）を使用したデータベースクエリ
• rsyncバックアップスクリプト
• その他のサーバー間通信

NTPは、時刻を正確に保つための最良の方法です。

フェイルオーバーモードで実行されている2つのISC DHCPサーバーは、時間が特定のしきい値だけ異なると失敗することを付け加えます。停止後、再起動を拒否します。

編集：構成方法によっては、スレーブもマスターからゾーンをダウンロードできず、キャッシュされたゾーンが最終的に期限切れになるため、DNSも失敗する可能性があります。

今日私が見つけた問題の潜在的な原因の1つは、時計が後戻りしない、つまり「未来からの」日時で名前が付けられたバックアップが存在しないという事実に依存するバックアップまたはスナップショットローテーションスクリプトにあります。これにより、それらの将来のバックアップ/スナップショットが削除される可能性があります（スクリプトの実装方法によって異なります）。

また、一部のバージョンのsudoは、クロックロールバックに対して脆弱であり、パスワード要件を持つsudoerがパスワードなしでrootを取得できるようにします。

認証のために時間に依存しているため、リモートデスクトップおよびその他のリモートアクセスツールは動作を停止する場合があります。これはトラブルシューティングを非常に苛立たせる可能性があります（問題を解決するためにリモートで接続しようとしますが、それもできません）。

どういうわけか、2011年ではなく8011年であると思っていたマシンでこれを使用しました。SSL証明書も期限切れでした。

私の最も厄介な問題は、SSL証明書の期限切れです。なぜ機能しないのかわからないときは非常に迷惑です。