Linux（ext3）にNASでマウントした領域をfindで検索するとき、普通に実行しても再帰的に検索はしてくれないのね。
実際には2階層下にファイルがある：
$ ls -R nas_mnt_point a b c nas_mnt_point/a a.txt nas_mnt_point/b b.txt nas_mnt_point/ c.txt
でもfindでは：
$ find nas_mnt_point nas_mnt_point/a nas_mnt_point/b nas_mnt_point/c
で、symlinkと同じように-followオプションを付けると：
$ find nas_mnt_point -follow nas_mnt_point/a nas_mnt_point/a/a.txt nas_mnt_point/b nas_mnt_point/b/b.txt nas_mnt_point/c nas_mnt_point/c/c.txt
それだけ。
Popularity: 1% [?]
ぜんぜん更新されないhp miniのLinuxディストリビューション「MIE」に不安を覚えたのと、ネットブック風デスクトップやharbour-launcherが気に入らなかったので、Fedoraに戻ることにした。
インストールはいたって簡単で、liveusb-creatorを利用してUSBメモリにイメージを作成して、USBスロットに挿してからf9キーを押しながら起動、デスクトップに表示されるインストーラのアイコンから普通にインストール作業を進める。
ここまではいいのだが、それですべてというわけにはいかない。一番困ったのが、デフォルト状態では無線LANがうんともすんともいわないこと。
# lspci -v|grep Network 01:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 0
Broadcom社のBCM4312という製品を動作させる必要があるようだ。RPM Fusionにこれに対応したドライバがあるので以下の要領でyumで追加できるようにした。
# su -c 'rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \ http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm' # yum install broadcom-wl
ところが、インストール時のカーネル2.6.29だと問題なく動作するのに、yum updateでカーネルを更新してしまうと動作しなかった。いろいろ調べてみたが、結局ここで見つけた手順に従い/etc/modprobe.d以下の適当なところで
# yum install wl-kmod # echo "install ssb /sbin/modprobe wl;/sbin/modprobe --ignore-install ssb" >> /etc/modprobe.d/dist-oss.conf
として再起動したところ、無事に動作した。
それから、外出先でWillcomのUSBモデムNS001U(netIndex)を使いたかったのでこちらも設定したが、特に難しいこともなく、普通に「システム」→「管理」→「ネットワーク」から新しいハードウェアとして一般的なモデムを選択し、USBモデムが/dev/ttyACM0として認識されていたのでモデムデバイスとして指定、それからデバイスとしてプロバイダ情報にあれこれ書き込み、「Willcom」として保存すると、/etc/sysconfig/network-scripts以下にifcfg-willcomというファイルが出来上がっていて、/etc/ppp/peers/willcomもさっくり用意されるので、あとは
# ifup willcom
で接続できた。めでたしめでたし。
Popularity: 4% [?]
この数日、サーバの負荷が急に増えたのでハードウェアを変更しました。これまでのマシンをプロキシにして、バックエンドにもう少しスペックの高いマシンを置いてコンテンツをそちらに移設しています。
新しいマシンはHPのProliant ML115 G5、AMD Phenom IIプロセッサにメモリ8GB、HDDに至っては合計2.5TB、さらにSSDが32GBという構成にESXiで3つのOSが動作しています。これまでのHPのデスクトップ用Celeronマシンとはかなり違いますが、こちらも安定して動いてくれることを願います。
猫大好きです。今日も二人で過ごしています。
Popularity: 3% [?]
WillcomのUSBモデムNS001U(netIndex)がhp mini用UbuntuであるMIEで使えた。
本体にNS001Uを差し込んでdmesgを開くと、期待したようにttyUSB0ではなくttyACM0として認識されていた。
# dmesg | grep tty ..... [ 84.975909] cdc_acm 1-1:1.0: ttyACM0: USB ACM device ....
そこで、ダイアルアップ接続用の設定ファイルを作成する。
# cp -a /etc/ppp/peers/provider /etc/ppp/peers/willcom
で、このファイルの中身を下のように変更する。
# vi /etc/ppp/peers/willcom .... #connect "/usr/sbin/chat -v -f /etc/chatscripts/pap -T ********" connect "/usr/sbin/chat -v -f /etc/chatscripts/pap -T 0000000000##64" # Serial device to which the modem is connected. #/dev/modem /dev/ttyACM0 # Speed of the serial line. #115200 460800 user "your-willcom-user-name" ....
スピードの設定は何が最適なのかよくわからないので適当。「connect」はWillcomを利用するときの電話番号、「user」はユーザ名となる。そしたら
$ sudo pon willcom
これで接続に成功した。
Popularity: 21% [?]
「/usr/bin/ld: cannot find -lltdl」と出るときはyum install libtool-ldtl-devel。以上メモでした。
Popularity: 52% [?]
携帯端末向けサイトの管理者Aは悩んでいた。とある携帯キャリアの課金体系ときたらひどい仕様で、入会日から一か月後に入会状態の継続が確定するのだが、他のキャリアのように月初に〆日があるのと違って、特に月末になるといったいいつ継続確定すればいいのかまったくもって判断がつかない。2月28日の翌月って3月28日なのか？翌々月は？1月31日の翌月は？直感で解決できない仕様は悪い仕様である。開発者の悩みは尽きない。
しかし、管理者Aの悩んでいるのは、そんなことではなかった。仕様書を読めばわかる問題なら、散文には慣れている文学部出身のAにはたやすいことだ。過ちを恐れるあまり舌が凍りついたような文面に、ご丁寧にもコピープロテクトまでかかった小癪な仕様書も、彼の読解能力の前には交通安全の標語とさして違いはない。数日の内に、バッチ処理は仕様通りに動作するよう完璧に設計され、実装され、凄まじいテストにも完璧に耐え、crontabの美学に完璧にのっとってスケジューリングされた。開発チームは祝杯をあげ、バッチ処理はもう半年間ずっと問題なく動いている。
だが、問題は起こった。ある朝、彼の携帯電話がけたたましい音を鳴らして気だるい春の空気を切り裂いた。サーバから直接送信されるアラートだ。件名を見ただけで、彼の眠気は吹き飛んだ。完璧な上にも完璧な例のバッチ処理が動作していないのだ。ユーザ情報の集計処理は来るはずのデータを待ちながら悲鳴を上げている。そんな馬鹿な！完璧なことピンポン玉のごときあのバッチ処理が失敗するなんて！
会社のサーバに繋がる秘密の端末からキーを叩く彼は驚愕した。完璧なバッチは完璧なまでに詳細な実行ログを残すことになっている。しかし、ログは一切残っていない！どういうことだ！crontabは変更されていない。プログラムに手を加えられた形跡もない。
ふと、管理者Aは/var/log/cronを覗いてみたい誘惑に駆られた。そして、恐る恐るコマンドを叩き、犬にしか聞こえない周波数帯で悲鳴を上げた。
$ sudo grep "perfectBatch.sh" /var/log/cron | grep $USER \
awk '{print $1 " " $2 " " $3 " " substr($8, 2)}'
password:
.............
Mar 22 04:00:00 /usr/local/bin/perfectBatch.sh
Mar 23 04:00:00 /usr/local/bin/perfectBatch.sh
Mar 24 04:00:00 /usr/local/bin/perfectBatch.sh
Mar 26 04:00:00 /usr/local/bin/perfectBatch.sh
............
ない！ない！25日がない！
完璧なバッチは、完璧に作られ、完璧に設定されている。しかし、まさかcronに無視されるとは誰も思っていなかった。死すべき定めの人間の現実は、そんな思いを平気で踏みにじるのか。管理者Aは、ふと故郷の景色を思い出した。
と。
まあ、そんなわけで、割と負荷の高いサーバを運用した経験のある人なら、cronが実行されなかったのであわてたことがある人も結構いると思う。かくいう筆者も同じで、原因を調査してもこれといって手がかりもなく困り果てていた。1台や2台のサーバならなんとか確認して運用することもできるが、100台にもなるとそうはいかない。
そこで、cronはそもそもちゃんと動かないという前提で、確認の手間を省くことでなんとかならないかと考えることにした。思いついた方法は2つで、
(1) サーバ内に問題検知エージェントが稼働している
(2) 全てのバッチ処理は完了通知をリモートサーバに投げる
1の場合、エージェントの稼働を監視する方法がないので、結局同じことになる。2の場合、どこかに集中管理用サーバを用意して、いつどのサーバからどんな通知がこないといけないかをデータとして保持したアプリケーションが通知を受け付け、問題を検知する。この場合、集中管理サーバだけ確認しておけばいいので運用は簡単だ。バッチ処理の側に終了通知を投げる機能の追加が必要だが、これから作るものに適用していって、うまくいくようなら全部のマシンのバッチ処理に適用すればいい。
そんなわけで、バッチ処理の集中管理システムというものを作ってみたくなったのだが、そもそもこの手の問題にはみんなどうやって対応しているのだろうか。もっといい知恵があれば知りたいし、そんなのとっくにあるよという方がいれば教えてほしい。キモは、cronが無視するタスクの検知だ。
Popularity: 6% [?]
何をしているのかはわからないけど、ステルス検索というサービスをやっているらしいBlekkoという会社があるようだ。
dmesgに怪しげなログが残っていた。普通、DoS攻撃とかで残るようなログなので、それにしてはヌルい回数だからおかしいなとIPアドレスを調べてみたら、Blekkoという組織からのアクセスだった。
TCP: Treason uncloaked! Peer 38.108.180.137:31690/80 shrinks window 数字:ずらずら. Repaired.
Blekkoとは：
$ whois 38.108.180.133 [Querying whois.arin.net] [Redirected to rwhois.cogentco.com:4321] [Querying rwhois.cogentco.com] [rwhois.cogentco.com] %rwhois V-1.5:0010b0:00 rwhois.cogentco.com 38.108.180.133 network:ID:NET-266CB40018 network:Network-Name:NET-266CB40018 network:IP-Network:38.108.180.0/24 network:Postal-Code:94065 network:State:CA network:City:Redwood City network:Street-Address:100 Marine Parkway network:Org-Name:Blekko network:Tech-Contact:ZC108-ARIN network:Updated:2008-09-17 10:42:07 network:Updated-by:John Knowles %ok
ステルス・サーチというくらいだから、なるほどackを返さないとかやってるみたいだ。とりあえず実害はないので気にするのはやめる。
Popularity: 6% [?]
jsが入っているのにJavascriptのインタプリタ以外に使い道がないなあ、と思っていたらPeclにspidermonkeyというのが追加されていた。検索するともう記事が見つかったりして、楽しそうなのでさっそくインストール。PHP5.3beta0以上が必要なので、テスト環境のPHPもついでに更新。php.iniのextension_dirを
extension_dir=/usr/lib/php/exntesions/no-debug-non-zts-20090115
のように更新しておかないといけない。
で、pecl install spidermonkey-alphaを実行したら見事にこける。ヘッダファイルjsapi.hがないとのこと。でもそのファイルは/usr/include/直下にある。で、手動でspidermonkey拡張モジュールをダウンロードしてconfigureの中身を見ると、
for i in $PHP_SPIDERMONKEY /usr/local /usr; do
for j in js mozjs; do
test -f $i/include/$j/jsapi.h && SPIDERMONKEY_BASEDIR=$i
&& SPIDERMONKEY_INCDIR=$i/include/$j && SPIDERMONKEY_LIBNAME=$j
&& break
done
test -f $i/include/$j/jsapi.h && break
done
if test -z "$SPIDERMONKEY_INCDIR"; then
{ { echo "$as_me:$LINENO: error: jsapi.h not found. Please reinstall libjs." >&5
echo "$as_me: error: jsapi.h not found. Please reinstall libjs." >&2;}
{ (exit 1); exit 1; }; }
fi
こんな箇所があり、spidermonkeyのヘッダファイルは/usr/includeか/usr/local/include直下ではなくその下のjsかmozjsディレクトリでないといけないらしい。なんなんだ。以前spidermonkeyをインストールしたときの手順に問題があるんだろうか。
まあ、ヘッダファイルはみんなjs*.hという名前だったので、さくっと
# mkdir /usr/include/js && cd /usr/include/js # for i in `ls ../js*.h`; do ln -s $i `echo $i | sed "s/..\///"`; done # pecl install spidermonkey-alpha
適当なことをやって、ようやくインストール完了。ちなみにmozjsにするとやっぱりpeclからのインストールは出来なかった。なぜだ？
Popularity: 10% [?]
ここに書かれている通り。現行でもバージョンが同じだったのでメモ。
--- lib/ssl/c_src/Makefile.in 2008-03-27 13:43:04.000000000 +0300 +++ lib/ssl/c_src/Makefile.in 2008-03-27 14:03:27.000000000 +0300 @@ -38,7 +38,7 @@ CC = @CC@ LD = @LD@ SHELL = /bin/sh -LIBS = @LIBS@ +LIBS = @LIBS@ -lkeyutils -lselinux PLAIN_CFLAGS = @CFLAGS@
Popularity: 3% [?]
