[Feb 5, 2022]

昨日のことです。

突然、自分のホームページが見えなくなりました。(・o・)

ははーん、我が家のRaspberry Piサーバーが落ちたんだな・・・

と一瞬思ったのですが、良く見てみるとTIMEOUTやREFUSED系のエラーではなくForbiddenで、リソースへのアクセス権限で怒られているんです。

セキュリティ的な用語で言うと、Identification→Authentication→Authorizationの3段階があったうちの一番最後で蹴られているので、サーバー自体は生きている訳ですね。

そこで、いろいろ試してみたところ、

はい、アクセスが出来ました。今回はなぜ開けているかお分かりになります？

上の画像では写っていませんが、実は clarte.iobb.net/howadebi/index.html まで入力すると開けるんですよ。

同じ要領で、当サーバー内の別サイトで試してみましょう。

「メンテナンスメモ2」のページも上記の記載ではNGですが、

のように index.html まで記載すると開けるんです。

これは、Apache2 の DirectoryIndex がなぜか効かなくなっているということ。

# URLをディレクトリ名まで指定したときに、別のファイルにリダイレクトしてくれる機能。index.htmlやindex.phpなどを指定することが多いと思います。

そこで試しに、apache2.confファイルの<VirutalHost>に直接、DirectoryIndex index.html と記載したところ、apacheの起動時にSyntax Errorが発生。(・_・)

.htaccessへの記載も試してみましたが、やはりディレクトリ指定ではホームページが開けません。

つまり、DirectoryIndex 機能を実現してくれている dirモジュール自体が無効になっている・・・ということでしょう。

しかし、落ち着いて考えてみると、手動でa2enmodが必要なrewriteのようなモジュールと異なり、dirはデフォルトでロードされるようになっているはずなのです。<(’o’;; そもそも、昨日まではディレクトリURLでアクセスできていたんだし・・・

そこで、/etc/apache2/mods-enableに移動して ls -al dir* [enter] してみたところ、../mods-available/dir.loadへのリンクが切れて × 表示になっているではありませんか。(@_@)

だったら追加し直してみようと a2enmod dir [enter] したところ、なんと Structure needs clearing. というメッセージが出ました。

それなら一回、強制的に消去してみるか・・・と、直接 sudo rm dir.* [enter] しても同様に Structure needs clearing のメッセージ表示。

要するに SDカードのファイルシステムがクラッシュして、dirモジュールが起動できない状態になっていることが判明しました。(@o@;;;; こ、こんな局所的な壊れ方って本当に起こっちゃうものなの〜!?!?

sudo shutdown 0 してSDカードを抜き、別の Linuxマシンを用意してマウントし、fsckしてみようかとも思いました。

ですが、こんな壊れ方をした以上、このSDカードはすでに信用ならないと思ったほうが良いでしょう。

また幸いなことに、このサーバーを立ち上げた当時の日記の最後に、

と書いていた通り、古いながらもサーバーが起動できる状態のバックアップは取ってあったのですよ。(^o^)

そのイメージを、新しいSDカードに焼き込んで復活させることにしましょう。

今回、イメージのバックアップが入ったドライブは D:、SDカードは E: にマウントされています。

ドライブ指定や、Read と Write の向きを間違えるとえらいことになるので、慎重に確認した上で Write を選択、[Yes] をクリックしましょう。

もとのSDカードは16GBを使っていたので、12分近く書き込みにかかります。

今さら気が付いたのですが、Win32 Disk Imagerのような全セクターをバックアップするツールを使う前提だとすると、バックアップイメージを焼く際には同容量以上のSDカードにしか引っ越せません。(’_’) 同じ16GBの製品を買っても、微妙に容量が小さい場合には書き出せないこともあります

Raspberry Pi で Webサーバーを構築する際、コンテンツは外付けUSB-HDDなどに置く前提であれば、SDカードは4GBなどの小さなものを使っておいた方が良かったんだなぁ・・・ということになりますね。

まぁ、それでも12分でシステムが再構築できちゃうなら十分です。

さっそくSDカードをRaspberry Piに差し込み、電源を入れ直してみました。

そして、ディレクトリ指定でホームページを開こうとすると・・・

あっ、SSLが上手く働いていません。

CERT_DATE_INVALID となっていることから、Let's Encryptの Certificationが期限切れになっているという訳ですね。(^o^) いやいや〜、うっかりしていました

私のサーバー設定の場合、/etc/cron.monthly にシェルスクリプトを置いて、月に1回、Certification の更新を仕掛けているのですが、もちろん、このまま1か月間も放っておく訳には行きません。

さっさと手動でシェルスクリプトをキックしましょう・・・というわけで実行してみたところ、

えぇっ!? (@o@)

なんと certbot-auto がサポートされなくなっちゃったようです。

案内のあった公式ページ(https://certbot.eff.org/)を見てみたところ、私の環境 ＝ apache2 / Debian 10.4 の場合には、snapd という新しいツールがサポートされているため、それを使いなさいとのこと。

# Linux Debianのバージョンは cat /etc/debian_version [enter] すると調べられます。

そこで、snapd を apt-get しようと思ったのですが、それ以前に apt-get update [enter] が上手く動きません。

これは Debian がバージョンアップされたためなので、apt-get update --allow-releaseinfo-change [enter] したところ update に成功。

さらに sudo apt-get install snapd [enter] してインストールには成功。

いよいよ、snap install core [enter] としてみたところ、

えーっ!! 私の使っている Rasperry Pi の CPU では snapd のサポート外のようです。(@o@;;; ど、どうするんじゃ〜

さらにいろいろ調べたところ、こちらに「どうしてもcertbot-autoが使いたい場合」という記事があり、https://raw.githubusercontent.com/certbot/certbot/v1.9.0/certbot-auto に動作する certbot-auto が公開されているという情報を見つけました。

そこで、ダウンロードして来た certbot-auto を、certbot-auto2 にリネームしつつ、/usr/share/certbot/ の下にコピーしてから、/etc/cron.monthlyに置いてあるシェルスクリプトの記述を、"/usr/share/certbot/certbot-auto2 renew --no-self-upgrade" に変更した上で実行してみたところ、

Installing Python packages... という表示が出たあと固まってしまったのです。(・_・;;

・・・が、これはとんでもなく時間がかかっているだけかもしれない、しばらく放っておこうと待ってみたところ、30分間ほど経過した頃でしょうか、

Pythonのインストールが完了し、certbot-autoが動作を開始。(@o@) おぉっ!!

そして無事、SSL の certification renewal に成功したのでした。"(ToT)" 困難な道のりでした〜

この時点で、いったんシステムを shutdown し、SDカードの内容を Win32 Disk Imagerでバックアップしておきましたよ。

でも、今の certbot-auto はいつ使えなくなってしまうか分かりません。恒久対策の準備をしておかなくてはですね。p(’o’)

このホームページについて - これまでの話題 -

トップページへ↓