“Client IP Detector” is a bomb

旧サイトで長らく使用していたwidgetの一つ,”Client IP Detector plugin” ですが,現在のWordPressに入れると,WordPress自体が動作しなくなります.困ったものです.

WordPressのディレクトリー内の “wp-content” 内の “plugins” にプラグインに対応したディレクトリーがありますから,そのディレクトリーごと削除すれば復旧します.

気に入っていたwidgetだっただけに残念です.

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に設定しました. ↩︎

プチフリーズはたぶん解決してない (2)

プチフリーズというか,Core Spotlight daemonとPagesが連携してMetadataフォルダーを肥大化させる件について,今回Geminiに聞いてみました.

そうしたら,もう1人役者がいるそうで,それはiCloudです.iCloudがPagesのファイルの編集履歴を保存することとCore Spotlight daemonの連携にバグがあって無限にインデックスを作るようです.

iCloudにApple製アプリのファイルを保存するのは具合が良いのですが,この際他の場所に置いてみることにしました.

問題になっているM4 Mac miniのローカルSSDにおいても良いのですが,Google Driveに置いた方が他のMacから編集するのに楽なのでそうしました.

まだ数時間しか経っていないので,Metadataフォルダー内のCore Spotlightのフォルサイズは130MBと常識的な範囲内です.

前回のぬか喜びを反省して,1週間くらいはこのままで運用しようと思います.

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で,これももったいないのでいずれ入れ替えようと思います.

Orphan

以前経験したのに忘れてしまっていました.

サーバーをSlackware ARM 15.0からRaspberry Pi OS 13.3に切り替え,古いサーバーのデータなどを整理していたら,総容量が200GB程度まで減りました.

今まで1TBのSSDをつないでいましたが,半端な容量で使い道のない250GBのSSDがありこれに引っ越すことにしました.1TB SSDも空きます.

作業はManjaro AMD64 (x86_64)で行います.fdiskでGPTのパーティションを切り,mkfsでブート用のvfatとルートのext4をフォーマットします.

これが落とし穴で,Manjaroでフォーマットしたext4はSlackware 15.0では認識されないのです.

2回,コピーしてブートしてくれないので,インターフェースが悪いのかSSD自体が悪いのかなど悩みましたが,ManjaroでフォーマットしたボリュームはSlackwareでは読めないことを思い出しました.

このBLOGにもそれに関する記事があるはずですが今回見つけられませんでした😓

Geminiに聞いてみたら,古いKernelでは最新のmkfs.ext4のデフォルトでフォーマットしたボリュームはtoo newでマウントできないんだそうです.

回避策としては,

mkfs.ext4 -O ^orphan_file,^metadata_csum_seed /dev/sdXN

とします.あるいはSlackware上でフォーマットすればよいのです.

しかし,このような後方互換性のない新機能というのもちょっと困ったもんです.名前をext5にしてくれていればまだ分かりやすいものを.