Apache2.4のmakeができたので、次は追加で入れているモジュールを作ろうとしたらエラーが出た。
mod_allowlist は自前のモジュールでSQLite3に登録しているIPを元にアクセス可否を行うのだけれど、
アクセス元のIPアドレスを利用している所でコケている。
という訳で、ここで初めてAPIの変更点を見てみる。
https://httpd.apache.org/docs/2.4/developer/new_api_2_4.html
プロクシを利用している場合とわけるために変数名が変わったと言うことらしい。
conn_rec->remote_ip は conn_rec->client_ip に、
conn_rec->remote_addr は conn_rec->client_addr を使うと良いようだ。
次、mod_limitipconn のエラーはこんな感じ
remote_ip はさっきと同じなのでサクッと修正。
ap_default_type は2.4で無くなっている事が判明したので、適当に”text/html”でmimeタイプを決め打ち。
ap_get_scoreboard_worker は、引数のタイプと数が変更になっていて ap_sb_handle_t のポインタを渡してやらなければならない。
が、どうも scoreboard.h の ap_sb_handle_t の定義が怪しく、 ap_sb_handle_t を使おうとすると怒られる。
さて、どうしたものか。と思いきや、 scoreboard.h に以前の使い方で動きそうなAPIを発見。
ap_get_scoreboard_worker を ap_get_scoreboard_worker_from_indexes に置き換えてmakeを通す。
subversion-1.7.3 の mod_dav_svn では、以下のエラー
これは、dav_error は無くなっていて、代わりに apr_status_t型の aprerr に項目が変わっている。
結局はintで持ってるっぽいので、単純に項目名を変えて対処。
mod_security2 は、2.6.3でconn_rec絡みの変更点が入っているので、最新版を取ってきてmakeでOK。
php-5.4.0 の libphp5.so は普通にmakeが通る。
これで、ひとまず自分の使っているモジュールは全部2.4対応となった。
ソースを弄ったのは確認してからでないと実運用は無理だけど。
konata.net の Webサーバは長いことApacheの2.2系列だったのだけれど、
Apache2.4 がリリースされて、 mod_lua とか mod_buffer mod_sed mod_ratelimit 辺りが気になる。
mod_lua と mod_sed は臨時用2ch串で使ってる mod_ext_filter(遅い) の置き換えが出来るかもしれないし、
mod_buffer は純粋に性能向上の具合を見たい。
mod_ratelimit はFreeBSDだとALTQあたりを使って帯域制御を実現していたのをカーネルビルドせずに代用出来るかもしれない。
まぁ、現状の konata.net だと帯域もCPUもメモリも空きまくってるのであんまり意味はないのだけれど。
という訳で、2.2系列の時に使っていた野良ビルド用自作スクリプトでまずはmakeしてみる。
が、物凄い勢いでmodules配下にモジュールが追加される。
今まで
2.4だと
という動作っぽい。
例によって面倒なので公式を確認したりはしない。
個人的には、標準以外のモジュールをmodules配下に置く方式がしっくりくるので、この変更はあんまり嬉しくない。
デフォルトで吐かれる httpd.conf に LoadModule ディレクティブがズラズラ並ぶのはなんか違う気がする。
要件に応じて LoadModule するだけで柔軟に対応できて楽な場面は確かにあるのだけれど、
使わないモジュールをダラダラ並べられてもなぁ……
という訳で、殆どのモジュールについて configure オプションに –disable くっつけて無効化。
それとは別に、
–enable-mods-static=”lua luajit” でスタティックリンクしようとすると、
make時に以下のエラーになる。
–enable-mods-shared=”lua luajit” でモジュールを作るようにしてやると問題なく通る。
なのでluaだけはモジュールで。
とりあえず、makeは通った。
次はモジュールだ。
現在のkonata.netの鯖はECCメモリを8GB積んでいるのだけれど、
特にECCにしたからといって何かあるわけでもなく。
なんとなくどんな感じで認識されているのか気になったので検索開始。
CPUのサポート命令や型番なんかは /var/run/dmesg.boot を見れば良いのだけれど、
メモリについては、容量くらいしか判らない。
で、検索したところ、sysinfo と dmidecode というコマンドを入れてやればいいらしい。
portsから検索して、sysinfoのコンフィグでdmidecodeを有効にしてインストール。
sysinfoを実行してみると、dmidecode -t memory で詳しい情報が見られるらしい。
というか、sysinfoは他の項目でも試してみたのだけれど、大抵はdmidecoede で詳しい情報を見てね。
と、dmidecodeがイチオシみたいなコマンドだ。
という訳で、素直にdmidecodeを実行する事にする。
manで見たところBIOSの設定情報を見ることが出来るらしい。
-t オプションで取得する項目を指定することが出来、番号と、特定の番号に対応したキーワードが使える。
項目とキーワードmanの情報だと以下を取得できる。
この辺は適宜manを見ればいいだろう。
Keyword Types
——————————
bios 0, 13
system 1, 12, 15, 23, 32
baseboard 2, 10, 41
chassis 3
processor 4
memory 5, 6, 16, 17
cache 7
connector 8
slot 9
-t memory だと、 -t 5, 6, 16, 17 と同じ意味になる。
試してみると、値の取れない(入ってない?)項目もあるようだ。
で、肝心のメモリ情報。
Handle 0x0014, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Single-bit ECC
Maximum Capacity: 8 GB
Error Information Handle: Not Provided
Number Of Devices: 2
Handle 0x0016, DMI type 17, 28 bytes
Memory Device
Array Handle: 0x0014
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 4096 MB
Form Factor: DIMM
Set: None
Locator: DIMM0
Bank Locator: BANK0
Type: Other
Type Detail: Synchronous
Speed: 1333 MHz
Manufacturer: Manufacturer00
Serial Number: SerNum00
Asset Tag: Not Specified
Part Number: ModulePartNumber00
Rank: Unknown
Handle 0x0018, DMI type 17, 28 bytes
Memory Device
Array Handle: 0x0014
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 4096 MB
Form Factor: DIMM
Set: None
Locator: DIMM1
Bank Locator: BANK1
Type: Other
Type Detail: Synchronous
Speed: 1333 MHz
Manufacturer: Manufacturer01
Serial Number: SerNum01
Asset Tag: Not Specified
Part Number: ModulePartNumber01
Rank: Unknown
とりあえず、ECCは効いているっぽいけど、OSへのエラー通知はされていない模様。
しかし、BIOSの設定条件のうち、どれを選択したのか?というのは判らないので、
やっぱりBIOS画面を見ないと、なんとなく悶々としたものが残る。
けど、鯖は今は机の上の本棚の上で電源とLANケーブルしか繋いでないんだよなぁ……
下まで下ろすのも面倒だし、液晶につなぐのもポートが空いてないので面倒だし、
リモートアクセスカードが付いていればこういう時楽チンなのだけれど、
その辺もケチったからなぁ……
さて、どうしたものか。
FreeBSDで、smartmontools というパッケージを入れると、
いわゆるsmartctlコマンドがインストールされて、smart値が読めるようになり、
/etc/periodic.conf に以下の記述をすることで、
FreeBSDから毎日送られてくる動作状況メールにSMARTの状態が追加されるようになる。
こんな感じ
が、デフォルトのままだと、USB外付けのHDDには対応していないので、
da?のデバイスの状態は出してくれない。
外付けのチップが対応している場合、smartctlコマンドに、-d デバイス名,[0-9] をつけて
デバイス名を指定してやれば、動くのだけれど。
なので、ちょいとスクリプトに手を入れてみる。
/usr/local/etc/periodic/daily/smart を編集
-d を入れてる所があるので、case文にちょろっと追加する。
複数のHDDケースを使っていて、チップが別々だとまた手を入れる必要があるけれど、
今のところ、外付けHDDケースは1つだけなのでこれで大丈夫。
試しに叩いてみて、動くことを確認する。
ちょっとHDDを整理しようと思って、適当に動画とかチラ見しつつ、
HDD内の古いファイル、使ってないツールなんかを削除したのだけれど、
削除した後、TeraTermでkonata.netの鯖に繋ごうとすると、鍵ファイルがありません。
と、怒られる。
間違って消してしまったらしい……
Recuvaを使って復旧を試みるも、
裏でisoイメージを落としていたので、HDDには常に新しいデータが書き込まれており、
面倒くさいので放置していたら、刻一刻と復旧の可能性は無くなっていた。
で、Recuvaでは、やっぱり復旧は無理でした。
主に、ツールを使う側の人間の影響で。
sshの鍵自体はkonata.netの鯖に入っている。
が、ログインしないとコピーして持ってこられない。
つまり、取り出せない。
あ~、ヤバいなぁ……と、思ったのだけれど。
よくよく考えてみると、konata.netの鯖は一週間に一度、
dumpでHDDのイメージをとっていたんだった。
バックアップは持ち運びが便利なように、Windows側からも見える位置に置いてある。
と言うことは、別のFreeBSDマシンがあれば、マウントしてssh鍵だけ取り出すことが出来る。
ちなみに、落としていたisoイメージは、FreeBSD9.0のi386とamd64。
これが、天の思し召しというやつか。
仮想マシンにいそいそとFreeBSD9.0を入れて、適当にパッケージ突っ込んだ辺りで
眠くなったのでその日は就寝。
翌日
仮想マシンにdumpデータを転送して、restoreコマンドでssh鍵を抽出。
無事にkonata.netにログイン出来るようになった。
教訓。ながら作業はよろしくない。