munin-async

相変わらずの思い付き作業であるが、munin-asyncが動いたのでメモ。

この手のは毎回、どっちがサーバーでどっちがクライアントなのかわからなくなるので困る orz

remote machineがデータ収集される方(クライアント)で、serverがデータを収集する方です。

ローカルでデータをため込んで要求に対して返事をするんだからリモート側もサーバーと言えばサーバーなんだよな(ぶつぶつ

とりあえず。マシン名としてremoteとserverで。普通にmuninで収集できているものとします。

インストールはapt-get でばばそ。

remote# apt-get install munin-async
server# apt-get install munin-async

serverで。

server# vipw   <- ユーザーmuninのシェルを/bin/bashに変更
server# su - munin
server$ cd /var/lib/munin
server$ mkdir .ssh
server$ cd .ssh
server$ ssh-keygen -q -N "" -f /var/lib/munin/.ssh/id_rsa
remote# mkdir /var/lib/munin-async/.ssh
server$ scp /var/lib/munin/.ssh/id_rsa.pub root@remote:/var/lib/munin-async/.ssh/authorized_keys
server# chown -R munin.munin /var/lib/munin/.ssh
server$ ssh munin-async@remote

ごにょごにょ聞いてくるが一度ログインしてみる。
もう一度ログインしてみて、何も聞かれなければOK

server# chsh -s /bin/false munin

シェルを戻しておく。これって/usr/sbin/nologinの方がdebian的なのではないのだろうか・・・

あとはserverのmunin.confで

[async.remote]
address ssh://munin-async@remote:22 /usr/share/munin/munin-async --spooldir /var/lib/munin-async --spoolfetch
use_node_name yes

でおけ。
マニュアルには/var/lib/munin/spoolとか書いてあるけど実際には/var/lib/munin-async/ のようだ

あとはremoteで /etc/init.d/munin-node start で起動しておいて、データを収集させておき、server側で/etc/init.d/munin startで収集を行う。

/var/log/munin/munon-update.logとかを見て変なエラーが出てなければOK

今まで1分以上かかっていたのが10秒ぐらいに短縮された :D~

パッケージの再構築

なんかここしばらくbind9とかsquid3とか再パッケージのコンパイルに失敗するなーと思っていたらライブラリが壊れていたっぽい。

bind9のconfig.log見たらldがエラー吐いていたので気が付いた。

かつ、テスト用の別domU上だと成功したりするのでこれはファイル破損かなと。

何か壊れているのかなーとdevelのパッケージ一通り消したりしてごちゃごちゃやっていたのだが、どうも壊れていたのがlibm.soとlibcap.soだったらしく、libcapはともかくとして(?)、libm.soはlibc6-devパッケージだったりするのでこれはさすがに消さないからわからんよなー。

とりあえず apt-get –reinstall install libc6-dev libcap2で治ったようだ。

何かチェックツールなかったかなーと探してみたらdebsumsが既に入っていた。警告メールも来ていた(爆)

ldとかldconfigとかlibm-2.17.soとかlibglib-2.0.soとか(汗
関係ファイルを再インストールしてdebsums -csでエラー出なくなりました。

外からの改竄ではなくてファイル破損とかじゃないかなーと祈っておきます(汗

xenU カーネル

xenUのカーネルを最適化(最小化?)してみようと思いました。

この仮想マシンはサーバとして使っていて、いわゆるハードウェアに依存したコードは必要ないはずである、ということで単純にDevice Drivers の下をざっくり削除。

BusもPCIもISAもEISAもなし :p

Processor type and featuresはハード依存しまくりの部分だがここはどうしょうもないので設定。主に変更したのはサーバ用に関係ありそうな

Preemption Model (No Forced Preemption (Server))
Timer frequency (100 HZ)

だけ設定する。

これで試してみるといらないデバイスドライバをコンパイルしないので結構早い。

Device Driver全部カットしたらさすがに起動しなかったw

Loopback DeviceとRAID and LVMを有効にしないとroot filesystemが読めない
xenのfrontendドライバも必要。これがないとdom0から何ももらえない。

ATAも シリアルポートもUSBもVGAもカット。
ネットワークカードもXEN_NETDEV_FRONTENDがあれば後はいらないようだ。
マウスもキーボードも切りたかったけどさすがにそれはできなかったようだ。

しかしxenだと簡単にテストできていいね

 

 

debuild

前から何度もやりつつ諦めていたパッケージのrebuild

結局どうするのが正解なのかよくわからないまま。

ようするにcpu用に最適化できればそれでいいだけなんですが。

~/.config/dpkg/buildflags.conf
SET CFLAGS -march=native -O3
SET CXXFLAGS -march=native -O3

これで

# debuild -uc -us

でよさげです。

良く使っている気がする bind9, squid3, openldap あたりをrebuildしてみました。

$ apt-get source bind9
$ cd bind9-*
$ emacs debian/changelog
バージョン追加
$ debuild -uc -us
$ cd ..

できているような気がするけど確認する方法がないっつーかw

-O3は危険かもしれないと思いつつ。

i7 サーバー

半日かけてpen4のサーバをi7マシンに移殖。

旧サーバはhdd2つで、一つが起動用(贅沢だw)、1つがlvmで作ったxen domUで動くサーバ本体。

単純にこの2つを新マシンに入れ替えて再起動、で行けるはずだった。が。しかし。

xen hypervisor

i386のhypervisorでamd64のカーネルを動かそうとしていて動かなかった。これは当たり前。
そしてamd64のhypervisorでamd64のカーネルを動かしたら動かなかった。なぜに?
結局、amd64のhypervisorでi386のカーネルの組み合わせのみ起動できた。

title           Xen 4.1-amd64 / Debian GNU/Linux, kernel 3.2.0-4-686-pae
root            (hd0,0)
kernel          /boot/xen-4.1-amd64.gz
module          /boot/vmlinuz-3.2.0-4-686-pae root=UUID=hogehoge ro console=tty0
module          /boot/initrd.img-3.2.0-4-686-pae

使っているカーネルとかのバージョンは上記の設定を見て察してください(ぉ

実際にはupdate-grubで生成したものですので上下にいっぱい付いてますが省略。

書いてみるとこれだけなのなw半日かかったのに。

hypervisorぐらい再インストールしたかったのだが、単なるディスク移動だけで時間かかりすぎたので後回し。

/etc/xen/server はこんな感じ

bootloader ="/usr/lib/xen-default/bin/pygrub"
extra = "/boot/grub/menu.lst"

root="/dev/mapper/rio-root ro"
memory = 7168
name = "rio"
vif = [ 'mac=xx:xx:xx:xx:xx:xx' ]
disk = [ 'phy:sdc,xvda,w' ]
vcpus=8

メモリとディスク名、cpu数を変更した。/dev/sdcはディスク丸ごとlvmのpvになっている

domU

amd64カーネルに変えた。

apt-get install linux-image-3.2.0-4-amd64

domUはあっさりamd64カーネルで動いた。

カーネルの再コンパイルをしようとしたのだが、amd64カーネルが作れなかった。

make-kpkg --revision=1.0 --initrd kernel-image --arch=amd64

で行けるはずなのだが,

dpkg-architecture: warning: specified GNU system type x86_64-linux-gnu does not match gcc system type i486-linux-gnu, try setting a correct CC environment variable
make[2]: amd64-linux-gcc: Command not found

で動かなかった。amd64-linux-gccとかx86_64-linux-gnu-gccとか必要らしいがどこから入れるかわからない orz
これってもしかしてamd64でOSごと再インストールしないとダメとかって話?

今日は未解決のまま終了。