リアルタイムクロックなしでグルグル回る

リアルタイムクロックなしでグルグル回る

小さな Linux ボックスを使用する際の紙切れに関する話があります。

私のサイトの 1 つは、アクセスするのに少し手間がかかる場所に古い Raspberry Pi がインストールされています。 数週間前、おかしくなり、リモートログインが許可されなくなりました。 私自身の単純な管理機能はまだ実行中であり、何かが間違っていることを報告していましたが、何が起こったのかを正確に知るには十分な詳細ではありませんでした。

SD カードに明らかに何か愚かなことが起こったために、そのファイルシステムで異常をきたしていることを知るために、コンソールをそれに接続する必要がありました。 なぜログインできないのか正確にはわかりません。昔は、キャッシュに十分な情報が残っている限り、完全にディスクが故障したマシンでも、inetd + telnetd + ログインでアクセスできました。 + シェル、または sshd + シェル、および (当然のことながら) それらが依存するすべてのライブラリ。 何かが起こって方程式の一部が欠けていたのだと思います。 私たちは xz 全体について学んできたので、最近はさらに多くの可動部分があります。 何でも。

それで私はそれを再起動し、仕事を始めました、そして、その時計が一日ずれていることに気づいたのはしばらくしてからでした。 chrony が実行中だったので、なんてことだろう? 実際、chronyは、情報源がないので、ただ悲しそうにそこに座っているだけだと言いました。

chrony が最も重要なものの 1 つであることを考えると、これは私にとってほとんど意味がありませんでした。
手がかりのある
プログラムは、同期にソースを使用することに満足できるまでソースの解決を試み続けます。 私の標準インストールの場合、それは 2.debian.pool.ntp.org を使用しようとしていたことを意味します。

私は箱でそれを自分で解決しようとしました。 うまくいきませんでした。 別のリゾルバー（別のボックス上）にクエリを実行したところ、正常に動作しました。 それでは、chrony が機能しないことに加えて、unbound も機能しなかったことは何でしょうか?

ここで少しコンテキストを説明します。このボックスは、他の理由により、ローカル ネットワークに対して独自の再帰的キャッシュ リゾルバーを実行するように、ある時点で再構成されました (*咳*)
TPリンク
*咳*) 去年私が抱えていた問題。 また、DNS 解決にそのローカルのアンバウンドを「のみ」使用するように構成されていました。

これにより、いくつかの点がつながり始めました。 chrony は、NTP プール内のホストを解決できなかったため、クロックを設定していませんでした。 unbound が機能していなかったため、ホストを解決できませんでした。 しかし、なぜ unbound が機能しなかったのでしょうか?

さて、ここに問題があります – それは *ほとんど* そうでした。 他のいくつかのドメインは問題なく解決できました。 ntp.org のことが起こっていなかっただけです。

(これが以前に起こったことがある場合は、ここから画面を指し始めます。)

それでは、時計が 1 日以上遅れているボックス上で、一部のドメインだけが解決されず、すべてが解決されないのはなぜでしょうか?

そうですね、それがまとまった頃ですね。 私は、彼らがそのゾーン (またはその一部) で DNSSEC を実行しているに違いなく、その一部の側面に「not-before」制約があるに違いないと考えました。 落ち込んでしまった
この道
以前は SSH 証明書を使用していましたが、なぜ DNS ではないのでしょうか?

resolv.conf に別のリゾルバーを追加すると、chrony が動作し始め、それにより時間が進み、unbound がプールの解決を開始し、その他はすべて正常に戻りました。

「その他すべて」とは、WireGuard のことも意味します。 マシンの同期が大幅にずれると、マシンも動作しなくなることをご存知ですか? どうやら暗号通貨に時間が含まれているとは知りませんでしたが、他にどのような説明があるのでしょうか?

話を戻して、何が起こったのか話しましょう。これはほとんど私に責任があるからです。

SDカードから古いPiを実行しています。 びっくりしました。 修復作業を開始できるよう、元の状態に到達するまでに約 1 日半かかりました。

この特定の Pi にはリアルタイム クロックがありません。 最新のもの (5B) は*可能*ですが、実際にバッテリーを購入して接続する必要があります。 デフォルトでは、これらは同じ状況にあります。 これは、彼らが現れると、しばらくの間、無意味な時間を過ごすことを意味します。 それが何なのか正確にはわかりませんが、なぜなら…

systemd は、あまりにも過去の値を検出したときに、時計を「現在」に近い場所に戻そうとする最近のことを実行します。 おそらくジャーナルを調べて、そこから最後のタイムスタンプを取得し、それを使用して実行しているだけだと思います。 コマンドによる再起動を実行しているだけの場合、その差は数秒であり、時刻同期機能によりその後すぐに残りの部分が修正されるため、これは通常非常に優れています。

ただし、マシンは 1 日以上にわたって「ディスク」 (SD カード) に書き込むことができずに放置されていたため、それが使用されたタイムスタンプであることを思い出してください。 もっと早く到着していれば、それほど遠くはなかったと思いますが、それは選択肢ではありませんでした。

時間が大幅にずれると、unbound は ntp.org プール サーバーを解決できなくなり、そのため chrony はクロックを更新できなくなりました…そのため、unbound はプール サーバーを解決できなくなりました…

DNS 解決をローカルホストのみに指定する私自身の構成選択は、残りを行いました。

ならどうしよう？ まず第一に、特定の DNS 異常が繰り返されないように、2 番目と 3 番目のリゾルバーを指定しました。 次に、外部へのリンクが何らかの理由でアップしていない場合でも、ピンチのときに助けてくれるかもしれない近くのホスト (残念ながら別の Pi) の「ピア」ソースを chrony に明示的に与えました。

これらの小さな箱を安いものと考えることには、ある種の問題があります。 彼らは…そうでなくなるまでは。 jwz からの回線をめちゃくちゃにするために、Raspberry Pi が安いのは、時間に価値がない場合のみです。

いつものように、この投稿は THE ONE に登場を求めるものではありません。 あなたが「THE ONE」であれば、間違いは犯しません。 私たちは知っています。 黙って立ち去れ。