まぁ、表題の通りなのだけれど、portsnapの中で使ってる
phttpgetがPROXYの古いキャッシュをみてしまうのが原因のようなのだけれど、
この辺で出てる通り、古くから直ってない問題なので、phttpgetをwgetに置き換えて安心安心。

と思っていたら、やっぱり失敗する。

具体的には、/var/db/portsnap/filelist の中身が古く、古いファイルを取りに行こうとして
HTTPの404を貰ってくるような動作をしている。
portsnapのスクリプトは古いファイルがあると思って処理を継続して、
いざ処理をする時にファイルが無くて失敗。

で、こういう時は　/var/db/portsnap/ 配下を全削除、 しかる後、portsnap を実行。
ということをしていたのだけど、毎回やるのはうざったく、元々遅いアクセス帯域で
毎回60MB超のファイルを落とすのは非効率。

portsnap事態はシェルスクリプトなのでソースを見ると、どうもphttpgetしてる箇所と、
fetchコマンドでファイルを取ってくる場所があり、fetch が悪さしてる模様。

マニュアル検索で、fetchのオプションをチェックしてみるも、
PROXYのキャッシュを許可しない設定はできない模様。

なので、portsnapを書き換えてしまうことにした。

を

こんな感じでfetchを使ってる箇所を置き換え。
${QUIETFLAG}の中身は -q でfetchとwgetで同じなので書き換える必要なし。
${QUIETREDIR} はどうせエラー出力なので気にしない。

一回試しで実行してみてとりあえず動くことを確認。
これで様子をみることにする。

Apache2.4.1のリリースが出てから、割りと後先考えずにApache2.4系に移行したのだけれど、
どうも、安定しない。
サーバから送られてくる毎日の状況メールでは、こんな感じで例外吐きまくっている。
signal 11 はメモリの例外アクセスなので割りと致命的。

加えて、再現条件はわからないのだけれど、httpdがメモリを食いつぶし、
サーバが応答不能になりかけることが数度発生。

昨日も発生していたのだけれど、httpdのプロセスが2つでモリモリメモリを消費して、
MySQLの接続に失敗し、Blogが閲覧できない状態にまでなっていた。

mpmをpreforkとworkerを試してみたのだけれど状況は変わらず。

かと言って、安定していたApache2.2系に戻るのは、
移行前の設定ファイル諸々なんかの手間が入るので出来ればやりたくない。

core吐いてくれればこちらでも対処のしようがあるのだけれど。
ひとまず、Apacheのhttpd.confにメモリ量の制限を入れて様子をみることにする。

「apache 2.4.1 “Segmentation fault” 2012」でググると、
mod_auth_digestのバグがあるらしい。
Digest認証のディレクティブを書いている所へアクセスをした記憶は無いのだけれど、
嫌な予感がするので手動でソースに手を入れて対処を取り込んでみる。

これで収まってくれると良いのだけれど。

WebサーバをApache2.4系に移行させた。

入れ替え前後はkonata.net内で色々遊んでいたので、臨時用2ch串のユーザさんなんかは
モロに影響を被ったかもしれない。
まぁ、個人でやってる鯖なので商用並みの安定運用を期待されても困るのだけれど。

そんな訳で、Apache2.4系に入れ替えるにあたって、httpd.confとか.htaccessとか、
臨時用2ch串のconfとかをあーでもないこーでもないやりながら書き換えた。

旧来のアクセス制御のお約束だった↓みたいのは、全部Requireディレクティブに置き換え。

こんな感じに

臨時用2ch串で使っていたhtml内のURL書き換えについても、
mod_ext_filterからmod_sedと<If>ディレクティブを使うように書き換え。
mod_ext_filterは使いやすくて、多機能ではあるのだけれど、
フィルタするコマンドをいちいちプロセス起こすのでむちゃくちゃ遅い。
2.4系からはApacheのモジュールで完結できるので、画面表示は随分早くなるはず。
書き込みはphpでhttpリクエスト作ってるので遅いけど。

ついでに、makeを通すだけだったmod_allowlistを、
エラーログにApache2.4からの[hogehoge:notice]みたいな[モジュール名:ログレベル]を
表示するように変更。
これについては、他の2.4のモジュールのソースを参考にした。

モジュール定義の以下を

こう変える、

が、AP_DECLARE_MODULE は ap_hook_access_checker を通してくれず、
ap_hook_check_access_ex を使う必要があって、パラメータも増えているので、
そこは適宜直す。

本当はphpも5.4.0にバージョンアップしてしまいたかったのだけれど、
Nucleusを使おうとすると、phpモジュールの中で落ちるのでphpはそのままで。
Nucleusの4.0が出たらもう一度試したい。

仮想マシンに実験用にNucleusを入れようと思ったのだけれど、インストールでコケる。

具体的にはDB作成に失敗する。
何度か試して「そんな馬鹿な！？」と思ってよくよく画面を見ると、
”TYPE=MyISAM”がよろしくないらしい。

MySQLのエンジン指定ってこんな感じじゃなかったっけか？
と、Google先生にお伺いすると、5.5系からは”ENGINE=MyISAM”を使わなければならないらしい。

エディタを開いて、置換して無事にインストール完了。

けど、TYPEをわざわざENGINEに変える理由って何なんだろ。
SQLの標準に合わせるとかそういう話なら判るのだけれど、MySQL独自の部分だし。

と、疑問に思い始めるのだけれど、実際、ENGINEで動くのだし、
別に理由を知った所でメリットはなさそうなので気にしないことにする。

このあたり、今リリースに向けて作業されてるNucleus4.0では治ってるらしいので
気楽に待つことにしませう。

Nucleus は コメント表示にユーザー情報（○○さん）とか出せるのだけれど、
いわゆる、スキン変数の<%realname%>で表示されるのは実際のユーザIDで、
ぶっちゃけると、これログインIDである。

当然、管理画面のディレクトリには .htaccess を置いて、IPベースのアクセス制限をかけてはいるけれども、
それはそれ、これはこれ。
ログインID垂れ流しは精神的によろしくない。

という訳で、Nucleusに手を入れることにした。
libs/COMMENTACTIONS.php のログインID設定してる所をニックネームに書き換える。

リロードして反映されていることを確認