可能な範囲で2013年から動かしていたBLOGの内容を移転しました．
多少の乱れやリンク先不明はご愛敬ということで😓
所有している(た)Mac miniとMacBook
TablePressの動作確認のため，古いBLOGからImportした表をupdateしました．
Mac mini
| 代目（台目） | 購入時期 | 仕様（概要） | メモ | 現在の（最終的）用途 |
|---|---|---|---|---|
| 1 (廃棄済み) | 2006年2月 | 最後のPowerPC機 | 後半生は家族用 | |
| 2 (廃棄済み) | 2006年11月 | 1.83 GHz Core Duo 1 GB | ||
| 3 (廃棄済み) | 2011年7月 | Core i7 2 core | 後にSSD 500GBとした． なお，2代目からの5年間は，MacOSX86でしのぐ | 後半生は家族用． 最期はファイルシステムを破壊する，致命的故障のため廃棄(2015年6月)． |
| 4 | 2012年11月 | Core i7 4 core 2.7 GHz (Ivy Bridge) （購入時から7代目購入までわが家最強のMac） | 後にSSD 960GBとして，快速に．2015年になり，突然のフリーズ，画面の乱れなどが頻発する． | シングルモニターで使用すれば安定なことが判明したため，家族用に転用．8代目購入で7代目を家族用に転用し本機は引退． |
| 5 (譲渡済み) | 2015年6月 | Core i5 2 core 1.5 GHz 4 GB | 3代目が故障のため，家族用として購入．遅くてしょうがないので，3代目のSSDを入れたら快速に． | 4代目を家族用にして，本機は次男に譲渡． |
| 6 | 2015年12月 | Core i5 2 core 2.6 GHz 16 GB | 4代目の後継．最初から4代目のSSDを入れるが，CPUのスペックダウンを感じる日々． | 筆者の元メインWS．故障して廃棄． |
| 7 | 2020年1月 | Core i7 6 core 3.2 GHz | デスクトップ用Core i7を搭載(CTO)した史上最強Intel Mac mini | 筆者の前メインWS．8代目購入で家族用に転用． |
| 8 | 2025年8月 | Apple M4 10 core | Intel Mac miniと比較して圧倒的に速い | 筆者の現メインWS． |
MacBook
Macのノート型パソコンは，長いこと個人では持っていませんでした．リタイヤする前年に初めて買いました．
| 代目（台目） | 購入時期 | 仕様（概要） | メモ | 現在の（最終的）用途 |
|---|---|---|---|---|
| 1 | 2019年2月 | 最後の無印MacBook． 史上最弱（または “名ばかり” ）Core i7搭載 | 使用には忍耐が必要 | 遊休状態 |
| 2 | 2025年12月 | MacBook Air M4 RAM 16 GB SSD 512 GB | Mac miniは不要と思うほどのパフォーマンス | サブWS |
Tableのインポート完了
海外サイトで見つけたティーテーブルが素敵だから個人輸入しました．という話ではありません．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のほうは記事数が多い（たぶん数千ページ）ので，同様の作業を重要な作業の前にはバックアップをし，慎重に行っていく予定です．
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からコピーしました．
これでほぼ元通りです．残念ながらメニューの小さいアイコンなどが一部失われています．まあ，なんとかほぼ操作できるのでよしとします．
好事魔多し
まあ，順調とは行かないまでも，なんとか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にすれば良いだけです．それだけなんです😅
- fisherman.jpg ↩︎