DiCEだとときどきだめみたい

細かい原因調査はまだなのだが、DiCEで管理しているDynamicDNSの更新管理がときどきうまくいかない。幸い、value-domainで取得しているドメインだとGETのリクエストで更新することができるので、それを利用することにした。

管理画面からダイナミックDNSの管理画面に遷移して、取得済みドメインを選択すると、「ダイナミックDNS設定情報」というページが表示される。そのページにある「アクセス先の例」に記載されたURLの最後のIPアドレスの部分を削って自分の持っているドメインのリストとして保存したら、接続元IPアドレスを返してくれる自分用の「確認君」を設置して、以下のスクリプトをcronで回して代用する。

require 'nokogiri'
require 'open-uri'

ip_address = ''
src = open('http://maniac.s154.xrea.com/test.php').read
doc = Nokogiri::HTML(src)
doc.search('span').each do |node|
        ip_address = node.inner_html
end
File.open('./list.txt').each do |line|
        uri = line.strip + ip_address
        tmp = open(uri).read
        puts tmp
end if ip_address != ''

まあ動いているのでこれでよし。

Popularity: 1% [?]

CentOS 5.4でもprelinkはRuby-1.9.1のバイナリを破壊する、かも

CentOS 5.4上でRuby 1.9.1を使っているのだが、インストールしてしばらくするとこんな状態になってクラッシュしてしまっていた。

$ ruby -v
compile/should not be reached: compile.c:473

で、もう一回ruby-1.9.1をmake installすると何事もなくちゃんと動作する。ということは、rubyの実行ファイルが何かしらおかしなことになっているのではないか、と思って調べていたら、ちょっと前に「CentOS 4.7 では prelink が ruby 1.9.1 のバイナリを破壊する」というページをブックマークしていたのを思い出した。

というわけで、/etc/prelink.conf.d/ruby.conf というファイルを新たに作成し、

$ cat /etc/prelink.conf.d/ruby.conf
-b /usr/bin/ruby

という記述を加えて様子見中。

update: 2010-03-30 今のところいけてる。

Popularity: 2% [?]

findの小ネタ

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% [?]

Fedora 11 on hp mini(無線LANとWillcom)

ぜんぜん更新されない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: 2% [?]

ハードウェア変更

この数日、サーバの負荷が急に増えたのでハードウェアを変更しました。これまでのマシンをプロキシにして、バックエンドにもう少しスペックの高いマシンを置いてコンテンツをそちらに移設しています。

新しいマシンはHPのProliant ML115 G5、AMD Phenom IIプロセッサにメモリ8GB、HDDに至っては合計2.5TB、さらにSSDが32GBという構成にESXiで3つのOSが動作しています。これまでのHPのデスクトップ用Celeronマシンとはかなり違いますが、こちらも安定して動いてくれることを願います。

猫大好きです。今日も二人で過ごしています。

Popularity: 1% [?]

hp mini + mie + Willcom(NS001U)

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: 5% [?]

CentOS5でGearman

yumで入れるlibeventのバージョンが1.1a-3.2.1なのでGearmanのビルド中にエラーになる。

遠慮しないでlibeventをソースから入れて、ln -s /usr/local/lib/libevent.la /usr/lib/libevent.laした。

Popularity: 13% [?]

CentOS5でPHPのビルド中に出るエラー

「/usr/bin/ld: cannot find -lltdl」と出るときはyum install libtool-ldtl-devel。以上メモでした。

Popularity: 11% [?]

バッチ処理の集中管理

携帯端末向けサイトの管理者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: 2% [?]

ステルス・サーチエンジン

何をしているのかはわからないけど、ステルス検索というサービスをやっているらしい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: 2% [?]