gami のすべての投稿

gcc オプション

今更ながらgccのオプションで謎だったことがなんとなく判明。

-march=native を付けた場合は-fPICも付けるのがお約束らしい。

結局、/etc/dpkg/buildflags.confに

set CFLAGS -march=native -fPIC -O3
set CXXFLAGS -march=native -fPIC -O3

でapt-build worldしようと思ったけど時間がかかりすぎるのでやめました(死

SSSD

ふとsssdの存在を知って入れてみたが、/etc/passwdにないユーザ(LDAPにのみ存在するユーザ)は扱えないらしい。
ので捨てw

できるのかもしれないけどとりあえずlibpam-sssでUser not known to the underlying authentication module が出るのでざっと調べたら/etc/passwdに無いユーザは対象外だそうで、そのうち使えるようになる or 警告無視で使えるのかもしれないけどとりあえず使用はパスする方向で。

ipsec

やっと3拠点のネットワーク接続ができた

NIC2枚差しにしたり余っているルーターを使いまわしたりあれこれやってみたが、結局中古のrtx1500をもう一台購入というオチになった

とりあえずNGNの折り返しのIPv6網上にipsecでv4通してripで回してなんとか接続。

ipv4グローバルアドレスで接続するとpingが18msぐらい。
ipv6グローバルアドレスで接続するとpingが4msぐらい。
ipv4プライべートアドレスで接続するとpingが5msぐらい。
ipv6プライベートアドレスで接続するとpingが5msぐらい。

拠点間全部が相互につながっているわけではないので一つはさむと10msになるが、これだけ速度でてりゃいいだろw

お店の防犯カメラもリアルタイムに見れて満足。

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でエラー出なくなりました。

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