PukiWikiの移転というか隔離

経緯

PukiWikiは,2004年にWikiWikiというサイト/仕組みを知り,今後はこの流れだろうと感じ導入しました.

と,簡単に書きましたが,当時は日本語が使えるWikiがなかなか見つかりませんでした.その後実際にWikiWikiの一種であるWikiPediaは隆盛を誇りました.その他のWikiはそんなに人々に知られることはありませんが,基本的な考え方はWordPress等多くのCMS系Webに受け継がれています.

2004年まではご多分にもれずhtmlで日記的なWebを書いていました.当時は当たり前だったのでそれほど不便に感じませんでしたが,WikiWikiの編集の手軽さと機能,特にオートリンク機能には魅了されました.htmlではけっこう面倒なサイト内のリンクを勝手にやってくれるわけです.

ということで,当時日本語をサポートしてWikiWikiらしいPukiWikiを見つけて飛びつき,個人的なBLOG的Webを移行したわけです.

それからもう21年も使っています.どうしてもボランティアベースのサポート体制は強力とは言えず,どんどん進化していくPHPに着いていけず,現在のPHPは8.4ですが,PukiWikiは8.1に対応したところです.8.1もサポート終了目前と思われます.

PukiWikiを使い始めて間もなくどうもBLOGにはむかないと感じ,BLOGらしいBLOGソフトを探したところ,ZopeというCMSで動くCOREBlogを見つけました.

2005年に外部公開向けのBLOG部分はPukiWikiからそのCOREBlogに移行しました.清水川さんというかたの開発で,便利に利用させていただき感謝しています.その後PloneベースのCOREBlog2に移行して2013年頃まで筆者の公開ブログとして運用してきました.

PukiWikiもBLOG以外の情報を書く,主に自分用のデータベースとして使い続けました.

2013年からWordPressの運用を始めました.COREBlog(2)はZopeやPloneのupgradeに伴い動かなくなってしまいましたが,PukiWikiは個人用データベースとして,今日まで途切れることなく動かし続けています

現役時代は,たまに国内外に出張することがあり,個人的な旅行もたまにしました.ごくまれにPukiWikiにため込んだデータが出先から必要になることもありましたが,現在は家庭内LANからアクセスできれば十分です.

WordPressは世界中の猛者たちがよってたかって開発・サポートを続けていますので,当然ながら最新のPHPに対応して,ユーザーに最新版のPHPの使用を勧めます.ということで,最新のPHPとPukiWikiをサポートする最新版のPHPの2本立てにする必要が出てきました.

Slackware ARMでPHP8.4のbuild

数か月前にもPHPの最新版のbuildをsbopkgで試みましたが,その時はbuildできず問題を先送りにしました.しかし,今回8.4を同じくsbopkgでbuildしたら,できてしまいました.それで先に進む必要が出たわけです.できたPHPは8.4.10です.ちなみに,PHP 8.1.xがもしbuildできればまだセキュリティーアップデートのサポート中で,PukiWikiも「動く」としているのですが,残念ながらSlackBuildsにはありません.

自力でbuildする手もないでもないですが,PukiWikiのPHP8.2以降のサポートより先に8.1セキュリティーアップデートが終了したら,現在と同じ状況になりますから今苦労することはあまり得策ではありません.

ということで当初の方針通りWordPressは最新のPHP系列で,PukiWikiは別の隔離したシステムで動かすことにします.

隔離システムの候補としてMacPorts

いくつか方法を考えました.PHPのサポート終了の7.4系列,もしくはPukiWikiがサポートしている最新の8.1系列をどこかで動かしてそこにPukiWikiを移転する.ざっと考えれば,

  1. 他にRaspbery Piなどのシステムを立ち上げる
  2. どこかのWSで仮想マシンを動かしてそこでPukiWikiを動かす

ChatGPTはVirtual Hostも選択肢に挙げましたが,うちの環境ではたぶん無理なので外しました.

1は簡単そうでそうでも無いのです.たとえばRaspberry PiにRaspberry Pi OSをインストールした場合,そこに古いPHPをインストールするのはそんなに簡単ではありません.一番簡単なのは,別マシンでSlackware ARM 15.0を動かすことですが,面白みに欠けます.

2も不可能ではないですが,WSをそのために24時間運用する必要があります.

そこで考えついたのが,表記のMacPortsで動かすことで,1と2の折衷案とも言えます.

メインWSのM4 Mac miniでMacPortsによりPukiWikiが動くPHPをインストールできれば,少なくともメインWSで作業しているときにPukiWiki内の個人データが必要になったらアクセスはたやすいです.また家の中の他所からのアクセスもメインWSが動いていれば大丈夫です.

自宅外からアクセスとなると一工夫必要になりますし,そもそも24時間WSを動かしておく必要もあります.ただし,現実的にはその必要性はほとんど無い〜皆無の間だと思います.

PukiWikiを1.5.4に

PHPを8.xにする前に,PukiWikiを最新版にupdateする必要があります.筆者の走らせていたのは1.5.3で,2022年にupdateしています.「動いているシステムをいじらない」という金科玉条を珍しく守っていました.

まずは,1.5.3のディレクトリーに何かの名前を付けて,cp -Rdvpでまんま複製します.ここには手を付けません.次に1.5.4のzipを展開し,中身をPukiWikiのディレクトリーに上書きコピーします.

すると,pukiwiki.ini.phpskin.php等がデフォルトに戻ってしまいますので,先に複製した保存用データを見比べて修正します.この辺の作業はブラウザでアクセスして確認しながらやることになります.ハッシュ化されたパスワードのコピーを忘れなければ後は気がついたらで大丈夫と思います.

後で気がついた主なものは,

  • autolink機能をonにする
  • chasen/kakasiの選択とpathの修正

くらいでしょうか.

MacPortsでPHP80がインストール可能

表題の通りです.案外簡単にインストールできました.が,それは結果から見ればそうなんですが,一日逡巡しました.

MacPortsで,

port install php80 +apache2

とかすると,簡単にphp8.0.30がインストールできるのですが,動いてくれないのです.httpd.confにphpという言葉が一つも見つかりませんし,libphpがどこにもできません.

port install php80-apache2handler
/opt/local/bin/apxs -a -e -n php mod_php80.so

の2つのコマンドが必要なようです

なぜ8.1でなく,8.0なのかは詳しくは忘れましたが,8.1で行き詰まったからです.後で余裕ができたら8.1を再度試してみます.

Chasenがインストールできない

MacPortsにChasenはありますが,インストールできませんでした.辞書の要らないKakasiは動きました.

今後の予定

現在,元のサイトでPukiWiki 1.5.4を動かして問題がないか確認しています.また,M4 Mac miniには時々rsyncでコピーして,こちらも確認しています.pukiwiki.ini.phpなどを毎回直すのは面倒なのでfilter機能で同期から除外しています.

PukiWikiの移行が済んだら,WordPressのPHPを8.4.xにupgradeします.

そのためWikiPediaをWikiと略す人が多数いますが,WikiPediaはWiki(Wiki)の考え方に沿ったひとつのWikiに過ぎません.
WordPressの運用を開始した2013年頃から,非公開の個人専用にしました.
執筆時点での最新版のPHPは8.4.11.
ハードウェアがあればAMD64版でもいいですが.
筆者はシステムのメンテはSlackware流儀,即ちroot権限で行います.

SARPi4 update

Slackware ARM for Raspberry Pi4 (SARPi4)のfirmwareとソフトのパッケージ(公式のものとSlackBuildのもの)のupdateを久しぶりにしました.Kernelは6.12.61になりました.

いまは,sbopkgでdosbox-xのbuildをしています.ずいぶん時間がかかります.使ってないのだからupdateの必要もなかったのにと後悔してます😓

RPi5のサポートはないかなとSARPiとSlackware ARMのサイトを見てみましたが,相変わらずSlackware-current用はありますが現行の最新版Slackware 15.0についてはないです.やはり15.1ないし16.0がリリースされるまで,正式リリースのSlackwareのAArch64対応の動きはないようです.

M4 Mac miniのプチフリーズを追う (1)

M4 Mac miniを購入後約3か月でプチフリーズが頻発して,高速なパソコンを買ったはずなのに使いにくい状態になりました.Appleのサポートに相談したりAIに聞いたり情報検索したりしながら自分でいろいろ試したところ,

  1. どういう条件でプチフリーズが起こるか
  2. プチフリーズが起きた時の他の症状
  3. 回避策

について解りました

使用環境は,M4 Mac mini RAM 24GB SSD 1TB,macOS 15.7.3 (Sequoia)です.

1はPagesで長時間大きめ(約500MB)の文書を開いていると,編集操作をしていなくても,Pagesおよびcorespotlightd,mds_stores,tccdなどがCPUを占有し~/Library/Metadata/CoreSpotlight/内のファイルのサイズが50GBを超え非常識に大きくなったときに起きます

ただし,同じ文書をPagesで開きっぱなしにしてもMacBook Air M4では同じことは起きず,~/Library/Metadata/CoreSpotlight/のサイズは300MB前後という常識的なものです.

ネット検索でもPagesとCoreSpotlightとプチフリーズの関係を指摘しているものがいくつか見つかり,PagesとCoreSpotlightが主犯であることはほぼ確実ですが,MacBook M4では起こっていないわけですから,他にも必要条件があるようです.

2については,プチフリーズということで,最初はSSDのハード的な故障を疑ってBlackmagic Disk Speed Testで測定したので解ったのですが,正常時には読み書きとも3000MB/s前後のスピードが出ますが,プチフリーズが起き出すと書き込み速度が2000MB/s以下,ひどいときは1000MB/s以下にまで低下します

したがって,プチフリーズか起き出すと,プチフリーズの継続時間を確認するとともに,Disk Speedを測定して客観データとしています.

3の回避策は,~/Library/Metadata/CoreSpotlight/の中のファイル・フォルダーを削除して,Macを再起動すればよいです.また時間がたつと~/Library/Metadata/CoreSpotlight/のサイズが増大して,プチフリーズが起きますが,数日は問題なく動きます.

Glossary

プチフリーズ

パソコンを操作しているとき,突然キーボードやマウスの操作に反応しなくなり数秒から数十秒その状態が続いた後回復する.プチフリーズ中にタイピングした文字が回復時に表示されることが多い.

今回筆者のMac miniで確認できたプチフリーズの継続時間は3〜16秒.

初期のSSDでは書き込み速度が著しく遅く,プチフリーズを引き起こした.ちなみに,英語では “micro freeze” である.

Blackmagic Disk Speed Test

Blackmagic Design社ディスクの速度計測アプリ

ただし,同時にそれらのプロセス全てがCPUを占有しているわけではない.
ただし,50GBを超えたら必ず起こるわけでもなく,必要条件です.
ネット検索で得た情報では,SpotlightがPagesのエントリーを延々と書き出し続けているらしいそうです.
Stress=5GB.
読み出しは3000MB/sを少し下回る程度です.
macOSの場合虹色の円板が回転する場合もあれば何も出ないこともある.

Manjaroがへそを曲げる

ここのところ,メインworkstation (WS) であるM4 Mac miniのプチフリーズの原因究明に時間を取られ,サブWSであるx86_64マシンはほとんど電源を入れませんでした.

久しぶりにManjaro AMD64を起動したら146個のupdateがあり,早速施したのはいいのですが,日本語入力ができなくなりました😅 しばらく見限っていたのでへそを曲げられました.

今の時代,日本語が入力できないとなんの役にも立たないですね.

さて,どうしたものか.少し前の状態を仮想マシン化してあるので,その仮想マシンのupgradeをして,日本語入力ができるかどうか確認したいと思います.それもできないとなると困ったことになります.

M4 Mac miniでプチフリーズ頻発 (18・終) 〜まとめ〜

所有しているM4 Mac mini (RAM 24GB, SSD 1TB)は,購入後2か月くらいしてプチフリーズが頻発するようになりました.

ネットで検索したり,AIやアップルのサポートに相談したり,自分でもいろいろ思いついたことを試したりしました.

まずはハードウエアやドライバーを疑い,USB機器(HDD,USB-Serial変換アダプター,USB-Audioアダプター,USB-HUB)やThunderbolt 3⇒2変換アダプターを介して接続しているThunderbolt 2 Dockやそれに接続している拡張モニター,HDD等の接続を外しました.特にTime Machine用のHDDはDockやHUBを介さず直結したほうが良いとの情報を得てMac miniに直結するケーブルも購入しました.またキーボードとマウス,トラックパッドはBluetooth接続のものを使用し,モニターはメイン・サブともUSB-C⇒HDMIの変換ケーブルでつなぐようにしました.

しかしそれでも症状は起きます.

結論的には,PagesとSpotlightのバグで,永遠にページインデックスをMetadataに記録し続けるのが原因と解りました

筆者の利用環境では~/Library/Metadata/CoreSpotlightの内容が50GBを超えたあたりで,プチフリーズが頻発するようになり,その時にSSDのアクセス速度を測定すると通常時に比べて大幅に低下します.

この状態にいたっても,テスト用のアカウントを作成してそちらにログインすると症状は出ませんし,OSのクリーンインストール後はプチフリーズはなくSSDのアクセス速度は改善します.

現在使用しているmacOSは Sequoia 15.7.3で,Pagesは14.4です.一時的にmacOS Tahoe 26.1にupgradeしました.利用期間は短い間でしたがその間はプチフリーズやSSDの速度低下は起きませんでした.

しかし,プチフリーズやSSDの速度低下が起こらなかったのはアカウントを切り替えたりTahoeを使ってからの使用期間が短かったためで,Sequoiaにおけるメインアカウント同様にPagesを長時間使っていたら同じ症状が起こると思います.

現在のところTahoeでもPagesのバージョンは変わりません.Spotlightに改善があればプチフリーズやSSDの速度低下は起こらない可能性はあります.

当面のワークアラウンドは,時々~/Library/Metadata/CoreSpotlightの内容を削除して再起動する,です.

Tahoe対応のPagesの新バージョンがリリースされたらTahoeにすることにして,もうしばらくは現状のままいきます.

メインWorkstationとして使用しています.
5〜16秒間,キーボードやマウスの操作に無応答になる.初期のSSDは書き込み速度が極端に遅く,このプチフリーズの原因となることが多かった.
参照した記事が見つかりませんが,
corespotlightd metadata endless loop

等で検索すると関連する情報が出てきます.

最短5日でプチフリーズが起きたので,3日おきくらい.あるいは気にしなければプチフリーズが起きた時点で.