Category: aarch64

UTMでManjaro ARM

何とか動かしたいと思い，普通のアプローチではうまくいかないのでネット検索したら手順を詳細に紹介されている記事を見つけました．

この記事の表題にあるように，普通にManjaro ARMのGeneric-EFIイメージを使ってUTMで起動させると，初回の設定モードは動くのですが，設定を終えてリブートすると起動してくれないのです1．

最新のUTM2と最新のManjaro ARM Genericのイメージファイルで上記記事のとおりに手順を踏むと3，初回の設定ができて，リブートもできます．またLinux (Kernel)とLinux-api-headersをupdateから除外してupdateもかけられますが，筆者の場合そこでエラーが出てしまいました．

仮にこれでうまく動くようになってもKernelのupdateが通常のお手軽な手順ではできないのが残念です．

ということで，こちらでは投了です．

Apple SiliconのMac上でUTMを使ってKDE Plasma Desktopを動かしたいのであればDebian ARM64が一番いいと思います．

いちおう記念撮影．

たぶん，もう少しいじって消します．箱庭遊びなんで😓

  1. 筆者のケースではフリーズではなく，EFIのshellが起動する． ↩︎
  2. 4.7.5 ↩︎
  3. UTMの設定が一部前後します． ↩︎

Raspberry Pi 4しばらく登板 (3)

Raspberry Pi 4 Model B RAM 4GBでまる4日ほど運用しました．定量的なデータは何もありませんが，LAN内のクライアント1からのアクセスでは，レスポンスがSlackware ARM 32bit時よりも少し改善された感じはしました．

ただし，写真のupload時の処理時間に大差はないです2．

今回は，同じRaspberry Pi 4 Model Bですが，RAM 8GBのものに置き換えました．RAM 4GBだと定常的な運転状態でswap (ZRAM)が500MB前後になります3．8GB RAMではswapが実質的にゼロなので，差は出ると思います．

Redis Object Cacheの反応時間，最大のピークは90 ms

このRedis Object Cacheの反応時間のグラフの中央 (16:35) あたりの大きなピーク(90 ms)はハードウェア交換直後に複数のdaemonが起動したため反応時間が大きくなったと推測できます．このピークの前がRaspberry Pi 4 Model B RAM 4GB，後が同8GBです．反応時間の平均的な値は小さくなっているように見えます．

この状態でまたしばらく運用してからRaspberry Pi 5に戻します．

  1. M4 Mac mini, MacBook Air M4など． ↩︎
  2. Uploadした写真をWordPressのシステムがいくつかのサイズに作り直します．当然写真によりますがだいたい16秒前後処理時間がかかります． ↩︎
  3. ZRAMは1GBに設定しました． ↩︎

Raspberry Pi 4しばらく登板 (2)

Raspberry Pi 4 (RPi4)で運用し始めてまる2日経過しましたが，問題は特にないです．WordPressの反応もSlackware ARM (32bit)で運用していたときより速い感じがします．

Fail2Banも着実に排除するIPアドレスを増やしていってます．

また，GUIがそれなりに動くのはいいです．Firefoxが使えるので，記事を書いたり修正するのも楽です．

Slackware ARM (32bit)でもKDEが動くのですが，ちゃんと動くWebブラウザーがないのが残念なところでした．KDE自体も重かったです．

その点Raspberry Pi OSの標準であるPIXELは軽量でいいです．

RAMは4GBでちょうどいい感じです．しばらくLAN内で続けて動かしている旧サーバーはRAM 8GBで，これももったいないのでいずれ入れ替えようと思います．

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