Raspberry Pi 4 Model B (RPi4)とRaspberry Pi 5 (RPi5)のRedis Object Cacheの反応時間の比較です.


差は歴然としています.RPi4ではピークが39msで平均は目の子で23msくらいですが,RPi5ではピークは14ms,平均は5msくらいです.
ざっと5倍くらい速い,というこれまでもっていた印象があてはまります.
横断歩道手前の一時停止は善意でなく義務
Raspberry Pi 4 Model B (RPi4)とRaspberry Pi 5 (RPi5)のRedis Object Cacheの反応時間の比較です.


差は歴然としています.RPi4ではピークが39msで平均は目の子で23msくらいですが,RPi5ではピークは14ms,平均は5msくらいです.
ざっと5倍くらい速い,というこれまでもっていた印象があてはまります.
昨日の夜9時頃でしたか,何気なくサーバーのコンソールからtopコマンドを実行してみると,上から下までapache2のプロセスが並びました.これは尋常ではないことが起きていると,/var/log/apache2/access.logを見てみると,ものすごい勢いで/wp-login.phpにアクセスがかけられています.間違いなく辞書を使ったbrute-forceアタックです.
その時はIPアドレスをプロバイダーのルーターに登録して止めましたが,次に記すセキュリティーアプリのインストール中に,5万件のアクセスだったことが解りました.
そういう訳で今朝はGeminiにDebianでiptablesを使ったブロックの仕方を教わっているうちに,WordPressのデフォルトのログインを止めるpluginのインストールと,Fail2Banというソフトのインストールを勧められました.
WordPressのpluginはWPS Hide Loginというもので,ログインのURL内のパスを任意の文字列に設定できます.そこで迷うことなくUUIDにしました.それでwp-login.phpを指定してきたアクセスは404 not foundになります.これはこれでめでたしめでたしです.
次のFail2Banは,ログを解析して,怪しいアクセスをしてきたところからのIPを無視するように設定するソフトです.設定が複雑なので,Geminiと相談しながらやってみました.その過程で昨夜のログを分析させたら5万件もの “不正アクセス” が検知できたわけです.これは,以前のRaspberry Pi 4 Model B (RPi4)ではそこまで行かなかったと思います.RPi4より体感や簡単な計測で4〜8倍速いRaspberry Pi 5 (RPi5)ならではの被害です.
sendmailもこれを使って防御しつつIPv4のポートも開こうかななどと少し考えています.
海外サイトで見つけたティーテーブルが素敵だから個人輸入しました.という話ではありません.WordPressの移植のための確認・作業をその後も進めている話です.
既にメインサイトのほうでは,投稿したページの本文,写真の移転に成功しています.ページ数が高々百数十なので,手で直すような作業もそれほど非現実的ではありません.
この作業で最大の問題は,WordPressの「インストール時のホスト名に執着する」特性です.既にホスト名は新サーバーに譲り,ローカルな名前を付けていると管理画面にログインすることさえできません.
そこで講じた策は,LANケーブルを外して孤立させて,ホスト名を昔の名前にすることです.具体的には/etc/HOSTNAME1と/etc/hostsを編集します./etc/hostsについては,127.0.0.1と::1の定義を古い名前に戻すだけです.このへんSlackwareはNetworkManager等が上書きしたりしないので楽です.
そして,GUIを立ち上げてWebブラウザーFalkonを立ち上げて作業します.これでメインサイトとBLOGの投稿記事やコメントをexportすることができました.
しかし写真はついてきません.写真についてはWordPressのディレクトリー内のwp-contents/uploads/にありますので,tarして持ち出してから新サイトで展開しました.この方法だとWordPressのライブラリーには表示されない2 のですが,古い記事内にはちゃんと表示されます.
これでだいたい終わったかと思いましたが,TablePressで作った表があります.ところが,管理画面のTablePressでExportタブを押しても,存在するはずの表が表示されません.どうもFalkonではダメなようです.念のためKonquerorで試しましたが,エンジンが同じなので全く同じ症状でした.
そこで作業をやめて考えながら風呂に入ったら思いつきました.旧サーバーであるRaspberry Pi 4 Model B(RPi4)とまともなWebブラウザーが使えるパソコンを直結すれば良いではないかと.
今朝実行しました.昔と違ってパソコン同士の直結にはクロスケーブルもHUBも不要で手持ちのUTPのケーブルで直結すれば良いのです.この作業はMacBook Air M4に前の名ばかりCore i7搭載MacBookで使用していたCableCreation製のドックをつないで行いました.

RPi4側の設定は孤立させるときと同じです.
MacBook側の設定はWi-Fiを切り,有線LANポートにはIPアドレスを手動で与える設定にして,RPi4と同じサブネット内の適当なIPアドレスを与えます3.また,/etc/hostsに,
192.168.0.10 古いサーバーのホスト名 古いサーバーのFQDN
のように書き込む必要があります4.無事つながり,MacBookのFirefoxで旧サーバーの管理画面まで入れました.
そしてTablePressのExportを開くと正常に表示されますので全ての表を選んでExportしました.
Exportしたファイルを新しいサイトのWordPressのTablePressでインポートすることにより,文字コードの問題もなく全て読み込むことができました5.
現状ですが,メインサイトの移転作業は終了しました.BLOGのほうは記事数が多い(たぶん数千ページ)ので,同様の作業を重要な作業の前にはバックアップをし,慎重に行っていく予定です.
後からいろいろ出てくるだろうというのは,今日早速ありました.GnuPG(GNU Privacy Guard)です.某所のパスワードを解凍しようと,これまでやってきたように,sshでログインしてから,
gpg2 -v -d
でリターンしても,そもそもGnuPG2がインストールしてませんでした.そこでapt installでインストールしてから,データも旧サーバーのアカウントのものをrsyncで属性も何もかもコピーしたらそのまま動きました.
ただし,リモートのMacからsshでつなぐと,パスワードの要求が出ずにスタックしてしまいます.
いろいろやっているうちに解りましたが,パスワード要求はGUIでパスワード入力のダイアログが立つのです.ローカルのターミナルでやる分には何の問題もないのですが,リモートではGUIのダイアログが出ませんからそこから先に進まないということです.リモートで使う必要性も当然ありますから,GUIでなくCGIのオプションをあとで調べておくことにします.
さて,表題のWordPressの旧サイトからの移転ですが,これがなかなか難航しています.最大の問題は,新サーバーの準備・切り替え作業でも直面した,WordPressのインストール・起動後のホスト名・ドメイン名の変更に対してWordPressが頑ななところです.
GUIが使えない場合のメンテ用ツールとしてWP-CLIというのをGeminiが教えてくれました.やはり,筆者同様GUIが使えず困る人が多いようです.
しかし,そのWP-CLIを少し使って解ったのは,MySQLデータベースが一部壊れていて,WP-CLIではお手上げ状態(どんなコマンドでもエラーが出てしまう)ということです.
MySQLのデータベースは,少なくとも旧サーバーのWordPressが立ち上がった2013年には動いていました.推測ですが2000年代1の少なくとも中盤頃からアマチュア無線の交信データの保存用として使っていたと思います.
最初はx86のマシンで,後にRaspberry Pi 3 Model BからRPi4へと受け継いできました.その間,データベースをバイナリーのままコピーしてきたのが災いしたようです.
一次的に旧サーバーのホスト名・ドメイン名を古いものというか,公開サーバー用のものに置き換えて作業をするしかなさそうです.
この場合新サーバーと同じFQDNとなるわけですから,ネットワークから切り離さなければなりません.そうすると,旧サーバー上でGUIを立ち上げ,Webブラウザーを使わなければならず,レスポンスが非常に悪RPi4での操作となり,忍耐が必要です.
また,まだいくつか旧サーバーがになっているサービスがあるので,それらも新サーバーに移行した後ということになります.ということで,気長で忍耐の要る作業ということになります.
sendmailはOKだったのですが,GMailのサイトから送ったメールを受信してProcmailに渡したのに/var/mail/ユーザーに届かないのです.何度やっても同じ,というのが昨夜までの状況でした.
今日もテストしながら,Geminiに相談したら解決しました.Procmailのログをとる方法をGeminiに教えてもらい,確認するとたしかにメールは届いている.しかし,/var/mail/ユーザーは空である.
Geminiは,それは確かにメールが届いているが何らかの他のタスクがメールを別所に移しているのだろうといいました.
そこで気がついたのですが,それはDovecotに違いないです.そこでDovecotを止めて同じようにGMailからテストメールを送ると/var/mail/ユーザーにメールがありました.
ここまで来てさらに気がついたのは,Dovecotも正常動作をしていて,接続しているクライアントのThunderbirdがメッセージフィルター機能で直接当方のsendmail宛てに届いたメールは別のフォルダーに移すようにしていたのでした.
つまり,メール関係は全て正常動作だったのです.
残りの作業をupdateします.