Category: Raspberry Pi

Raspberry Pi 4しばらく登板

Raspberry Pi 5 (RPi5)による新サーバーの運用もだいたい目鼻がつきました．ここでいったんRPi5からRaspberry Pi 4 Model B (RPi4)にサーバー担当を交代しました．

実はこれが一番やりたかったことで，これまで，32bit OSのSlackware ARM 15.0をRPi4で動かしてきましたが，同じハードで64bit OSだとどれくらいパフォーマンスが違うのか，ということです．

ChatGPTによればArmv8では，64bit OS/アプリと32bit OS/アプリでそれほどパフォーマンスに目だった差はないとのことです．

Slackwareの頃のWordPressプラグインRedis Object Cacheのグラフを取っておけばよかったのですが，探したらありませんでした😓

これが，先ほどWordPressをRPi5からRPi4に切り替えたRedis Object Cacheの反応のグラフです．

Redis Object Cacheの反応時間．最大のピークは60 ms

最初の大きなピーク（60 ms）あたりがRPi4の起動したタイミングです．その前はRPi5ですから，両者の性能の差が顕著に出ています．たぶん，RPi4をSlackwareARMで動かしてきたときもこんなもんだったと思います😓

今回の件についてはChatGPTの言うことは正しかったようです．残念です．

早速不正アクセス

昨日の夜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のポートも開こうかななどと少し考えています．

pcmanfm-pi

Raspberry Pi 5 (RPi5)のGUIはほぼ直りました．完璧ではないです😓

Geminiも勝手なことを言っていたようで，後から振り返ると違う方に導かれていました．

最終的には自力で回復しました．Rapsberry Pi 4 Model B (RPi4)が余っているので，そちらにRaspberry Pi Imagerで最新OSを書き込んだSDカードを差し込んで起動し，動いているプロセスやインストールされているソフト，設定等を比較しました．

その結果見えてきたのは，pcmanfm-piというプログラムかスクリプトが，lwrespawnによって繰り返し起動されますが落ちているようで，systemctl statusやps aufxで確認するといつもsleep 1となっています1．

それで，RPi5のほうで探してみると，pcmanfm-piなどというプログラムやスクリプトはありません．RPi4で見ると，/usr/bin/にインストールしてあるスクリプトで，pcmanfmを起動するためのラッパー2であることが判明しました．

apt-fileというユーティリティーをインストールして検索すると，rpd-commonというパッケージに含まれていると解ります．

そこで，apt install rpd-commonとすると，LX何とかで始まるGUIの重要なパッケージをいくつも削除してしまい，またGUIが起動しなくなりました．

どうもRaspberry Pi OS独自のパッケージが依存性にかなり重大な問題を起こしているように思います．

しかたがないので，rpd-commonは削除して，apt install raspberrypi-ui-modsでGUIを復活させました．この状態ではpcmanfm-piはありませんから，比較用のRPi4からコピーしました．

これでほぼ元通りです．残念ながらメニューの小さいアイコンなどが一部失われています．まあ，なんとかほぼ操作できるのでよしとします．

  1. つまり，1秒間待ってまた起動を試みる． ↩︎
  2. 引数や環境変数を与えて本プログラムを起動する． ↩︎

好事魔多し

まあ，順調とは行かないまでも，なんとかWrodPressの立ち上げまで行き，mail関係とBIND9は前のサーバーとほぼ同じにできました．

そこでGnuPGのインストールもできて，一段落だったんですが，sshでリモートから繋いでgpg2コマンドを使うと，パスワードの入力にGUIの窓が立ち上がってリモートからは認証ができないということで，CUIの認証ができればなと考えました．

GUIの認証は，pinentry-gnome3というパッケージが行います．CUIはpinentry-cursesというパッケージです．それならと，

apt remove pinentry-gnome3

を実行したのです．なんか依存ファイルがたくさん表示されますが，何も考えずにYで進み，

apt autoremove

までかけてしまいました．実はpinentry-gnome3はいろいろな基本的なアプリの認証に使われているのです．ですから，依存のあるパッケージがたくさんあって当たり前で，それらを削除したらもはやGUIは動きません．

再起動したら，いつもの大きなRaspberry Piのマークの入ったウインドウは現れず，昔ながらのDebianの起動の順番にタスクを立ち上げていく画面が出ます．

いまさら，

apt install pinentry-gnome3

をしたところで修復できません．ここまで来て再インストールからするのは流石に厳しいです．

以降は完全にGeminiに頼って修復をしました．まあなんとかGUIで自動ログインするところまで来ましたが，最後の詰めというかデスクトップ画像がRaspberry Pi OS 12.xの鵜飼の写真1なのです．これをRaspberry Pi OS 13.xのsunrise.jpgにするのがなかなかうまく行かず，結局鵜飼のままです．

現状では，鵜飼の画像を表示するpcmanfmとsunrise.jpgを表示しようとするswaybgの両方が起動していて，pcmanfmのほうが勝っているようです．

その最後の詰めで随分時間をかけてGeminiとやり取りしながら設定を修正しましたが，解決しませんでした．

とりあえずはGUIが動くし，弊害もないのでこのまま行きます．なにか気がついたら設定を変えたり，Geminiに相談したりしてみます．

gpg2でpinentry-cursesを使う正解

今さらながら正解は，~/.gnupg/gpg-agent.confを編集します．最初の行にpinentryプログラムを指定していますが，ここを/usr/bin/pinentry-cursesにすれば良いだけです．それだけなんです😅

  1. fisherman.jpg ↩︎

WordPress移行は難航中

後からいろいろ出てくるだろうというのは，今日早速ありました．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での操作となり，忍耐が必要です．

また，まだいくつか旧サーバーがになっているサービスがあるので，それらも新サーバーに移行した後ということになります．ということで，気長で忍耐の要る作業ということになります．

  1. 2001〜2010年． ↩︎