Blogのサイトマップ送信やらPing送信やらを実施すると、当然GoogleBotやらなんやらのアクセスがあるわけで、konata.netのApacheのログにもそういったアクセスがある。

けど、それらは日に何度もアクセスがある割りに、あーGoogleさんお仕事ご苦労様です。
という感想しか抱かないので別にログいらないなぁ……
と思うことしばし。

サイトのアクセスログみてどんな記事が読まれてるかをチェックしてるのでそういうログはないほうが見やすい。

というわけで、Botやクローラーのアクセスはさっくりとログ記録をしないようにした。

設定はこんな感じ。
# bot & crawler
SetEnvIf User-Agent Googlebot notlog
SetEnvIf User-Agent Feedfetcher-Google notlog
SetEnvIf User-Agent Mediapartners-Google notlog
SetEnvIf User-Agent “Yahoo! Slurp” notlog
SetEnvIf User-Agent msnbot notlog
SetEnvIf User-Agent Yeti notlog
SetEnvIf User-Agent Baiduspider notlog
SetEnvIf User-Agent “livedoor FeedFetcher” notlog
# RSS
SetEnvIf Request_URI xml-rss2.php notlog
SetEnvIf Request_URI atom.php notlog

#log
CustomLog logs/access_log combined env=!notlog

ついでにRSSのアクセスも記録しないように変更。
まぁ、Apacheのマニュアルページ見れば書いてある事なので取り立てて難しい事ではないのだけれど。

前回までのあらすじ。
認識は済み、速度にも満足したものの、省電力化で躓く。
できれば、アクセスしない時にはディスクの回転をとめたい。

USB周りでなんかないものかと / 配下を find . -name “*usb*” で検索。
いろいろ引っかかった中で、以下がなんとなく目に付いた。
・/usr/sbin/usbconfig
・/usr/ports/sysutils/usbutils
いかにもUSB周りを何とかしてくれそうな名前に期待が高まる。

で、さらに調査。
どうやら、usbutilsの方はUSBデバイスの情報をそのまま出力するだけのツールらしい。
なので、こっちは使えない。

usbconfig の方は、FreeBSDマニュアル検索でマニュアル見たものの今ひとつよくわからない。
usbconfigで検索をかけて見たところ、-u と -a でUSBデバイスを特定して、その後に続くコマンドでUSBデバイスを制御するらしい。
ちなみにそのまま打つと、USBデバイスを列挙する。

通常の出力はこんな感じ。
konata#usbconfig
ugen0.1: &ltUHCI root HUB Intel&gt at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen1.1: &ltUHCI root HUB Intel&gt at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen2.1: &ltUHCI root HUB Intel&gt at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen3.1: &ltUHCI root HUB Intel&gt at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen4.1: &ltEHCI root HUB Intel&gt at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
ugen4.2: &ltspeedzter2.5 vendor 0x07f7&gt at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
ugen4.3: &ltJM20336 SATA, USB Combo JMicron&gt at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON

たとえば、ugen4.3 のデバイスをいじりたいときは以下のようにする。
#usbconfig -u 4 -a 3 &ltcommand&gt

コマンドの一覧は -h オプションで取得可能。

で、コマンドを眺めてみた所、いかにも使えそうな以下のコマンドを発見。
suspend
resume
power_off
power_save
power_on
これは期待せざるを得ない。

ｗｋｔｋしながら、コマンド実行……
が、ちっとも停止する気配がない＼(^o^)／
ん～、やっぱ無理なのかなぁ……

というわけで、USB接続のHDDのサスペンド方法知ってる人がいたらコメントください。orz

先日買った、CENTURYのニコイチBOX。

製品の箱やWebサイトの情報だと対象はWindows＋Macという事なのだけれど、
ぶっちゃけ、普通のUSBストレージクラス対応の製品がFreeBSDで動かない道理はないわけで。

ドライバ回してケースを開けてHDD突っ込んでkonata.netの鯖に接続して電源ON。
あっさり認識したので、sysinstallからフォーマットする。
で、sambaで共有かけてるディレクトリ配下にマウント。

とりあえず、以下のコマンドでHDDの速度を確認。
diskinfo -t da1
遅い方でも25MB/Sec出ているので概ね問題なし。
というか、konata.netの100MbpsのLAN経由で使うので、クライアントからの実測では7～8MB/Secも速度が出れば御の字なのだ。

とりあえず、100GBほどデータを突っ込んでみる。
データ転送に5時間かかった……orz

認識した時の/var/log/messagesはこんな感じ。
WDの500GBを2つコンバインモードで認識させているので932GBの容量になった。
Dec 15 23:31:55 konata kernel: umass1: on uhub4
Dec 15 23:31:55 konata root: Unknown USB device: vendor 0x152d product 0x2336 bus uhub4
Dec 15 23:31:55 konata kernel: da1 at umass-sim1 bus 1 target 0 lun 0
Dec 15 23:31:55 konata kernel: da1: Fixed Direct Access SCSI-2 device
Dec 15 23:31:55 konata kernel: da1: 40.000MB/s transfers
Dec 15 23:31:55 konata kernel: da1: 953880MB (1953546336 512 byte sectors: 255H 63S/T 121602C)

ここまでは概ね満足。
が、人間欲が出るもので、このディスクは動画やら音楽やらを格納しているので、しばらくアクセスしない時には、ディスクの回転を止めて欲しかったりする。
いわゆる省電力モードという奴だ。
ATAとして認識しているディスクの場合は、portsのataidleが使えるのだけれど、SCSIデバイスとして認識しているこのディスクの場合はataidleが使えない。

で、しばし検索してsdparm というツールを見つけた。
portsにも入っているらしい。

さっそくインストールしてディスクの停止を試す。
sdparm –command=stop da1
止まらん。ディスクは快調に回り続けている。

camcontrol stop を試す。
konata#camcontrol stop da0 -v
Unit stopped successfully
やっぱり止まらん。

あきらめるしかないんかなぁ……

Webサーバのデータふっとばしからそれなりに時間がたってようやくひと段落ついたので、FreeBSD7.2から8.0へのアップグレードを実行。

freebsd-update upgrade -r 8.0-RELEASE
freebsd-update install
reboot
freebsd-update install
(各種パッケージの再ビルド)
freebsd-update install

と、作業を進める。
途中、パッケージの作り直し漏れが見つかったりしたものの何とか完了。

無事FreeBSD8.0になった。
新しいportsも確認。
INDEX-5からINDEX-8まであるって事は、FreeBSD5.xのころからこのマシン使ってたって事か。
結構長い事使ってるんだなぁ……
と感慨深げ。
が、それだけ長い事手を入れているマシンなので、もしHDDが飛んだら直すのは相当な時間がかかりそうだ。

仮想環境でもいいから、次期konata.net用のディスクイメージを作っておかないと……

ようやく、Blog以外のページも復旧がひと段落したので懸案事項だったWebサーバのデータバックアップスクリプトを作る事にした。

といってもそんなに大掛かりなものではない。
Webサーバのhtdocs配下のファイルをいったんtarで固めた後、gzipで圧縮。
バックアップディレクトリにコピーした後、バックアップファイルの数が一定数を超えていた場合、古いものから順に削除する。
と、大体こんな感じ。
50行程度のスクリプトに収まったのだけれど、やはり日頃作りなれていないので、この程度のスクリプトを作るのにも結構な時間がかかってしまった。

ついでに、Subversionれんたるの方も同じスクリプトのバックアップ元とファイル名のプリフィックスの変数定義だけ変えてバックアップを開始。

簡単なテストの後、cronに仕込む。
実行時間は朝の5時。
ファイルの更新とかぶると危険な予感がするけれども、さすがにこの時間ならほとんど問題にはならないだろう。

これで、konata.netの鯖は、WebデータとDBデータ、あとSubversionのデータはバックアップが取れるようになったのだけれど、実はこのマシン、替えが効かなかったりする。
というかFreeBSD5.xの時代から使い続けているので、正直どこに手を入れたのか自分でも把握しきれていないのだ……

やっぱり、ここは新しいマシンを用意して、記録をとりつつ同じ鯖を作り上げたいのだけれど、正直予算がない。

無給の出勤期間が終わってなんとか今月からは給料が出るのだけれど、独身とはいえ出世の遅いサラリーマンの給料は推して知るべし。
休職期間も長かったから、物欲に任せてホイホイ物を買えるほど余裕があるわけではないのだ。
あぁ、宝くじでも当たんないかなぁ……