予定より少し早いけれど

というわけで、konata.netの使われてないサービスの停止を実施。
残した物はサブドメインで少しURLを短くした。
ついでに日記の個別エントリを見るとMySQLでエラー吐いてたのを修正。

らいつべバルーンのURLは少し考えたのだけれど、
特に良い物がなかったのでそのままにした。
提供するソフトがもうちょっとあるならサブドメイン振っても良かったけれど。

さて、なにか作りたいとは思うのだけれど、なにを作れば良いんだろう?

Web開発で食ってる訳では無いけれど、
OAuth辺りはそろそろ抑えておかないとマズい気がする。
数年前にインストールだけして、
合わないと思ったWordpressも世の時流にあわせるなら覚えなければいけないし。

と、とりとめないことだけ書いて終わる。

色々あったのだけれど、なんとか新しい環境で動き始めたkonata.netの鯖。

大きなミスはこのくらい。
・/var/log 配下のログをサルベージ忘れたのでログ喪失
・postfix でメールがやりとりできない。→SSL対応オプションつけてなかった
・MySQLとPostgreSQLのダンプデータ復旧に少し手間取る。
・Softupdateジャーナルが有効だとディスクのダンプが取れないっぽい。(未解決)

bhybe はAMDマシンなのでしばらくおあずけ。

鯖も新しくしたことだし、konata.netのサービスもそろそろ棚卸ししないとダメかもしれんね。
「らのべを語れ」とか「SvnRental」とか「Uploader」とか使われてない物が死屍累々。
これらは黒歴史として、今度の土日にでもいい感じに消してしまうか固めてしまうかしよう。
「臨時用2ch串」と「PeerBlockList」「らいつべバルーン」は残す方向で。
「FreeBSD構築」は記述が古いのを今風に直すのに結構な手間が掛かりそうなので、
ちょっと躊躇してしまう。とりあえずは保留で。

本当はスマホと何か連動させて今風な事をやりたいのだけれど、ちょっとアイデアがね……

話がずれてきたけれど、まぁ、時期が来たのでしょう。

というわけで、konata.netはスリム化します。

タイトル通り。

konata.netの自宅サーバで動かしているApacheとPHPは諸々の事情で野良ビルドなのだけれど、
FreeBSD10.0に環境を作ろうとしたら、phpのコマンドライン版はビルドできるのだけれど、
Apacheのモジュールが作成されない事態が発生した。

で、多分PHP側の不具合だろうなぁ……、と思いつつ、
ここ2~3日悩んでいたのだけれど、公式で検索をしたらあっさりと情報が見つかった。

https://bugs.php.net/bug.php?id=66007

要約すると、FreeBSD1.x用のコードの判定が甘く、FreeBSD10.xがFreeBSD1.xと誤読され、
モジュールを作れないと判定されていた。ということらしい。

幸いにも、patchも一緒に投稿されていたので修正も容易。
修正後、無事にモジュール版PHPが作成されたことを確認できた。

これで一歩前進かな。

リリースを待ちわびていたのだけれど、日本のニュースサイトで取り上げられたのはおおよそ21日。
でもって、モロ週の頭なわけでして……

メジャーバージョンアップの時には、ダウンロードも大量になるし、
もちろん、元々入っていたportsなんかは全部入れなおしなので、結構な時間がかかることになる。

なので、必然的に作業は一日ごとにコツコツと実施するしか無いわけでして。
別に週末にやればいいじゃない。と、思わないでもないのだけれど、
実は、ウチの鯖のHDDは去年の夏からご機嫌斜めで、この週末には入れ替え用のSSDに環境を作りたい。

いま、アップデートしようとしている環境は結果的には、週末に作る環境の参考用にしかならないので、
あまり、気合を入れて作る必要もなかったりする。

途中、pkg2ngの実行を忘れてハマったり、portsの作り直しの前にportsnapの実行を忘れていたりと、
しょっぱいミスがあったものの、起動できなくなる系のトラブルには遭遇せずに作業を完了。

libiconv がインストールできなくなっていたり、glibのmakeが通らなかったりと、
色々問題は残ってしまったのだけれど、まぁ、おいおい、問題は解決されるだろうと気楽に構えてみる。

ただ、libiconvは「iconvがベースに入ったからインストールできなくしました」
というのは判るのだけれど、portsには日本語環境用のパッチが入っていたわけで、
どう考えてもそのパッチは入ってなさそう。

ちなみに、libiconvはportsのMakefileを書き換えて無理やりインストールした。
今のままだと、libiconvを必要とするportsが結構あるので。
おいおい、外せるようにはなっていくと思うのだけれど、とりあえず今はまだ必要。

さて、クリーンインストールの環境構築にはどんな落とし穴があることやら。

いつ頃から始まったのかはもう覚えていないのだけれど、
うちの鯖のhttpdのアクセスログに、毎日のように嫌な感じのお客さんが記録されている。

具体的にはcgi版のphpの脆弱性を狙ったアクセスとか、
同じくCMSの脆弱性を狙ったアクセスとか。

一度や二度ならともかく、毎日似たようなホストから記録されてるので
いい加減うんざりしてきた。

というわけで、index.phpにちょろっとスクリプトを仕込む。

// evil host check
if( strpos($_SERVER[‘REQUEST_URI’],’/images/stories/’)!==false ||
 strpos($_SERVER[‘REQUEST_URI’],’option=com_jce’)!==false ||
 strpos($_SERVER[‘REQUEST_URI’],’/cgi-bin/php’)!==false ){
 error_log($_SERVER[‘REMOTE_ADDR’].”
“,3,’./evil_host.txt’);
}

これで、アクセスしてきたホストのIPを evil_host.txt に保存。
次に、cronで以下のスクリプトを回す。

#!/bin/sh

# http 経由の邪悪なアクセスリストをソートしてpfのリストを作成する。
/usr/bin/sort -u /opt/htdocs/http/nucleus/evil_host.txt &gt /etc/pf.evilhost
# PFをリロード
/sbin/pfctl -f /etc/pf.conf &gt /dev/null 2>&1;

あとは、pf.conf で pf.evilhost をテーブルとして定義して、全部弾いてやれば良い。
とりあえず、cronの感覚は一時間にしておいた。

少し放置して様子を見ることにする。