昨日のことです。
突然、自分のホームページが見えなくなりました。(・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カードはすでに信用ならないと思ったほうが良いでしょう。
また幸いなことに、このサーバーを立ち上げた当時の日記の最後に、
そうそう、SDカードだっていつ壊れるかわかりません。 win32diskimager という Windowsアプリを使って、システム・イメージをバックアップしておきました。 |
と書いていた通り、古いながらもサーバーが起動できる状態のバックアップは取ってあったのですよ。(^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’)
[前の年(2021)へ] [一覧に戻る] [次の年(2023)へ]