最近、Nagios関連を再整備中。
GUIで簡単に設定できる"NagioSQL"とログを管理できる"ndoUtils"
FreeBSDで嵌ったところを書いておきます。
１ NagiSQL/portsで突っ込むときの注意（ツカ今の時点では出来ない）
perl5.8だと今のバージョンはちょっとダメなので、5.12にする。
今のports(2011/06/01頃)はpear/peclのインストールパッケージの
判断が変だから、ports使わない方が良いです。ダウンロードして、
野良で突っ込んでおいたほうがマシです。PHP5.3.6に対応してない
portsなのかもしれぬ。
2. ndoUtilsのユーザ関連について
Linuxの場合だとtar-ballから突っ込むパタンが多くて、個々の
流儀があるが、portsでは"nagios"一辺倒なので、他のユーザ名を
使ったりしないこと。スクリプトを全部自前で書き直す根性がある
場合に限り何をしても構わないけれど、nagiosがブローカに渡す時点で
齟齬をきたして
Broken Pipe
なんてしょーもないエラーで止まってしまう。ブローカっつのが
くっそ無愛想なのでたた殺したいがそれは仕事をしてもらう関係で
我慢我慢。
3. mysql について
postgresqlでも動くものもある(ndoutils)が、NagioSQLが対応しない
仕方ないので、mysqlを入れておく。mysql55をさっくりと入れられるのは
これまでの付き合いが０だったからいいのだが、やはりよく分からないので
phpMyAdminがあると便利だった
なんか堕落の一途をたどっている気がする。
以上
つかndoutilsを使って監視サーバをまとめるとかやってみないと
意味ないんだよね。
2011年6月5日日曜日
2011年5月26日木曜日
FreeBSD8.2への移行（2）
FreeBSD6.4環境が幾つもあり、更新が大量に発生したので
取り敢えず注意点を幾つか書くしかなくなる。
・6.4からの移行は7.3を経由すること。
8.2をコンパイルするために必要なライブラリが7.ｘからでないと作れない模様。
GCCコンパイラが切り替わっているのもあるし、インクルードファイルやらが足らないなど色々問題がある。6.4では8.2で必要とするものがマトモには作られないので、8.0の頃うまくコンパイル出来たと思ってたものは大抵ライブラリリンクが壊れてて動かない。8.2にもバージョンが上がるとその辺りのミスは排除されている。
・8.2環境に上がって古いライブラリをリンクするものが上手く動かないことがある。
4BSD->ULEスケジューラに変わったこともあり、バイナリ互換で動くようになっていても、常駐するスーパーデーモンやらデーモン系の動きがいつの間にか刺さって生きたふりで、実は死んでいることがあるので、すぐに再構築するほうがよい。
・make buildworld に成功しているようでしていない場合もある。
稀にそういうシステムもでる。 make.confに手をいれている場合は要注意。make.conf を更にしておいたほうが無難な場合もある。 ライブラリが正しく生成されない、必要なファイルが無いなどの現象で、8.2環境でのportsupgradeなどに支障をきたすことになる。現実に、ipsec-toolsなどはlibtoolが定義を正しく拾えないなどの問題が起きた。二度目のmake buildworld insatllworld により、環境が正しく設定された。
・portupgrade を 正しく動作させるには？
まず、databases/db4{1-8},databases/ruby-db,lang/ruby18 は再構築しておくこと。 oniguruma のライブラリが2.x系から、4や5にアップグレードされたことで、構築できない場合がある。rubyで日本語言語処理をするシステムを導入しないならば、onigurumaでの
国際言語対応正規表現は外しておくが無難。
cd /usr/ports/{$target} ; make clean all deinstall reinstall のワンライナーで、大抵入れ替えられる. 最後に、portsupgrade を更新し、
(nohup portsupgrade -ayfr --batch 2>&1 >/var/log/portupgrade.log & )
などとしておけば、更新できなかなった物はそのままに、コンパイル出来たものが
更新されているだろう。
・qmail-scanner 系などの portupgrade は問題。
これは上記の自動portupgrade 処理で引っ掛かるようである。当面、pkgtool.conf の IGNORE 節に加えておくのが良いと思う。perlライブラリが更新し終わった段階で、手動で更新するのが吉。
・古いライブラリの扱い。
消さないほうが無難だろう。古いファイル (cd /usr/src; make check-old-files ) で引っ掛かるものは、すべて消してよい。寧ろ消しておくべきだと思う。
・古いライブラリを参照するports の管理から外れているものなど。
portsは、6.xでほったらかしにしていると、もうすでにディスコンとなっているものも多々あるので、/var/db/pkg/honyarara のdirectory 丸ごと削除してしまう他ない場合も時折有る。pkgdb -F がささって死ぬようだったら、dbから作り直すしかない。
以上
取り敢えず注意点を幾つか書くしかなくなる。
・6.4からの移行は7.3を経由すること。
8.2をコンパイルするために必要なライブラリが7.ｘからでないと作れない模様。
GCCコンパイラが切り替わっているのもあるし、インクルードファイルやらが足らないなど色々問題がある。6.4では8.2で必要とするものがマトモには作られないので、8.0の頃うまくコンパイル出来たと思ってたものは大抵ライブラリリンクが壊れてて動かない。8.2にもバージョンが上がるとその辺りのミスは排除されている。
・8.2環境に上がって古いライブラリをリンクするものが上手く動かないことがある。
4BSD->ULEスケジューラに変わったこともあり、バイナリ互換で動くようになっていても、常駐するスーパーデーモンやらデーモン系の動きがいつの間にか刺さって生きたふりで、実は死んでいることがあるので、すぐに再構築するほうがよい。
・make buildworld に成功しているようでしていない場合もある。
稀にそういうシステムもでる。 make.confに手をいれている場合は要注意。make.conf を更にしておいたほうが無難な場合もある。 ライブラリが正しく生成されない、必要なファイルが無いなどの現象で、8.2環境でのportsupgradeなどに支障をきたすことになる。現実に、ipsec-toolsなどはlibtoolが定義を正しく拾えないなどの問題が起きた。二度目のmake buildworld insatllworld により、環境が正しく設定された。
・portupgrade を 正しく動作させるには？
まず、databases/db4{1-8},databases/ruby-db,lang/ruby18 は再構築しておくこと。 oniguruma のライブラリが2.x系から、4や5にアップグレードされたことで、構築できない場合がある。rubyで日本語言語処理をするシステムを導入しないならば、onigurumaでの
国際言語対応正規表現は外しておくが無難。
cd /usr/ports/{$target} ; make clean all deinstall reinstall のワンライナーで、大抵入れ替えられる. 最後に、portsupgrade を更新し、
(nohup portsupgrade -ayfr --batch 2>&1 >/var/log/portupgrade.log & )
などとしておけば、更新できなかなった物はそのままに、コンパイル出来たものが
更新されているだろう。
・qmail-scanner 系などの portupgrade は問題。
これは上記の自動portupgrade 処理で引っ掛かるようである。当面、pkgtool.conf の IGNORE 節に加えておくのが良いと思う。perlライブラリが更新し終わった段階で、手動で更新するのが吉。
・古いライブラリの扱い。
消さないほうが無難だろう。古いファイル (cd /usr/src; make check-old-files ) で引っ掛かるものは、すべて消してよい。寧ろ消しておくべきだと思う。
・古いライブラリを参照するports の管理から外れているものなど。
portsは、6.xでほったらかしにしていると、もうすでにディスコンとなっているものも多々あるので、/var/db/pkg/honyarara のdirectory 丸ごと削除してしまう他ない場合も時折有る。pkgdb -F がささって死ぬようだったら、dbから作り直すしかない。
以上
2011年5月3日火曜日
ESXi4.1 update 1 で FreeBSD8.2/amd64をインストールしてみる
結果を先に書きます。
ISOイメージをホスト側ストレージに放りこんでドライブイメージとして用意、
起動させようとして失敗しています。
原因が今のところ分かりません。 i386では問題がない。
困った困った。
追試というか検証用に手元のPCでVirtualBoxを立ち上げて同じイメージを
使って起動しようとするんですが、これもまた失敗。
うー、FreeBSD8.2/amd64のisoイメージのブートレコード、仮想環境に
使えないのかな？？ キチンとコンパイルしたものは動くのだけど。
仕方有りません 8.1-RELを試してみることにします。
ISOイメージをホスト側ストレージに放りこんでドライブイメージとして用意、
起動させようとして失敗しています。
原因が今のところ分かりません。 i386では問題がない。
困った困った。
追試というか検証用に手元のPCでVirtualBoxを立ち上げて同じイメージを
使って起動しようとするんですが、これもまた失敗。
うー、FreeBSD8.2/amd64のisoイメージのブートレコード、仮想環境に
使えないのかな？？ キチンとコンパイルしたものは動くのだけど。
仕方有りません 8.1-RELを試してみることにします。
2011年4月20日水曜日
FreeBSD8.2への移行
現時点で仕事をするにあたり、FreeBSD8.2が鉄板で非常に嬉しい。
7.3→8.2とか、ほとんど何事も無く進んでいる。奇跡だ思う。
まあ細かいところに問題があるかも知れないけどね。
今頭がいたい問題は2つ。
取り残されている6.x系の処分。
6.x→7.3がかなりの確率で上手くいかなくなってしまっている。
1月にトライした結果は散々だった。
多分7->8のために7.xが6.xとの互換性を無くしたんだろう。
旬のうちにバージョン更新をしていかないとえらい目に逢う。
もうひとつは、i386->amd64にしたい機材など。
別にしなくちゃいけない理由はなかったのだが、バイナリ互換でないと
困るものが出てきた（PostgreSQL9.0のレプリケーションとか）ので
ちょっと迷って、クロスビルドをやってみた。 で、今絶賛失敗中という。
楽勝のバージョン以降なんだけど、ハマることが時々ある。
7.3->8.2にするときの注意点はこんなところなのでメモ。
１．make はまとめてやるべし。
まとめてやらないと忘れてしまうことがある。
管理機材が多いから仕方ないとはいえ。
(cd /usr/src; nohup make buildworld buildkernel 2>&1 >/var/log/mkwk82rel.log & )
とかいっぺんに回して放置。
２ インストールするときもまとめてやるべし。
上に同じ。
３．インストールしたらログアウトするな！（絶対）
ログアウトした途端に 大変困ったことになる。
新しいヴァージョンでワールドが突っ込まれているのに
カーネルがどうにも対応できてないまま生きてるから、
ログイン出来なくなるはず。
”Could not determine audit " なんちゃらというメッセージが
コンソールに現れて一切ログイン出来なくなる。
一台、そーなった機材があったけど、コンソールにroot-shellが
たまたま残っていたので色々試した挙句、リブートすりゃいいって
気がついて再起動した。 再起動したつもりだったのだね。
最悪はマシンのあるところで、直接電源を落とせるようにしないとだめかも。
リモート・シリアルコンソール＋リモート電源コンソールなんてのがあれば別。
でも、インストールが終わったら四の五の言わずリブート一択。
だいたいこんなトコロですか。
．
7.3→8.2とか、ほとんど何事も無く進んでいる。奇跡だ思う。
まあ細かいところに問題があるかも知れないけどね。
今頭がいたい問題は2つ。
取り残されている6.x系の処分。
6.x→7.3がかなりの確率で上手くいかなくなってしまっている。
1月にトライした結果は散々だった。
多分7->8のために7.xが6.xとの互換性を無くしたんだろう。
旬のうちにバージョン更新をしていかないとえらい目に逢う。
もうひとつは、i386->amd64にしたい機材など。
別にしなくちゃいけない理由はなかったのだが、バイナリ互換でないと
困るものが出てきた（PostgreSQL9.0のレプリケーションとか）ので
ちょっと迷って、クロスビルドをやってみた。 で、今絶賛失敗中という。
楽勝のバージョン以降なんだけど、ハマることが時々ある。
7.3->8.2にするときの注意点はこんなところなのでメモ。
１．make はまとめてやるべし。
まとめてやらないと忘れてしまうことがある。
管理機材が多いから仕方ないとはいえ。
(cd /usr/src; nohup make buildworld buildkernel 2>&1 >/var/log/mkwk82rel.log & )
とかいっぺんに回して放置。
２ インストールするときもまとめてやるべし。
上に同じ。
３．インストールしたらログアウトするな！（絶対）
ログアウトした途端に 大変困ったことになる。
新しいヴァージョンでワールドが突っ込まれているのに
カーネルがどうにも対応できてないまま生きてるから、
ログイン出来なくなるはず。
”Could not determine audit " なんちゃらというメッセージが
コンソールに現れて一切ログイン出来なくなる。
一台、そーなった機材があったけど、コンソールにroot-shellが
たまたま残っていたので色々試した挙句、リブートすりゃいいって
気がついて再起動した。 再起動したつもりだったのだね。
最悪はマシンのあるところで、直接電源を落とせるようにしないとだめかも。
リモート・シリアルコンソール＋リモート電源コンソールなんてのがあれば別。
でも、インストールが終わったら四の五の言わずリブート一択。
だいたいこんなトコロですか。
．
2011年4月18日月曜日
OpenOffice daemon 化について
某処にて、OOOでフォーマット処理をしているサーバがあるとのことで、
取り敢えずソースからこしらえて、立ち上がるようには作ったけれど、
何故か、自動起動後OOOがデーモンになってもソケットを開かない。
使えないということで手動つかターミナル/shell経由でやると開く。
困ったので調べた。
http://community.nuxeo.com/5.3/books/nuxeo-book/html/admin-openoffice.html
ここから、oxtをダウンロードして来て入れてみたら動いている。
しかし謎な仕様だ。Javaだからバイナリ互換なんだろうか。
oxtがよくわかってないので調べたほうがいいですか？
取り敢えずソースからこしらえて、立ち上がるようには作ったけれど、
何故か、自動起動後OOOがデーモンになってもソケットを開かない。
使えないということで手動つかターミナル/shell経由でやると開く。
困ったので調べた。
http://community.nuxeo.com/5.3/books/nuxeo-book/html/admin-openoffice.html
ここから、oxtをダウンロードして来て入れてみたら動いている。
しかし謎な仕様だ。Javaだからバイナリ互換なんだろうか。
oxtがよくわかってないので調べたほうがいいですか？
2011年2月26日土曜日
引越しツール
何度かソフトウェアRAIDのメンバーディスクが壊れたり、RAIDのそのものの容量が足りないなんてことはサーバ管理では日常茶飯事なので、緊急修理が終わると安心して暫くは放ったらかされることもある。そうすると本当に引越しをしないでだらだら運用してしまうのでよろしく無い。思いついた頃にはまた再度ファイルシステムをコピーしなくてはならない。ツールがあった方が楽だ。
ツールを考えたので取り敢えず出してみる。これはファイルシステムの引越しを単純に行うだけのツール。すでにディスクの設定の殆どは終わっててアクセスできる状態になっていることが前提だ
１．/etc/migfstab
こんな形式のファイルを作る。移行先は何らかのファイルシステムにマウントする。
移行元物理パーティション 移行元ファイルシステム 移行先物理パーテーション 移行先ファイルシステム
例：
/dev/mirror/gm0s1a / /dev/mirror/gm1s1a /mnt
/dev/mirror/gm0s1d /tmp /dev/mirror/gm1s1d /mnt/tmp
/dev/mirror/gm0s1e /var /dev/mirror/gm1s1e /mnt/var
/dev/mirror/gm0s1f /usr /dev/mirror/gm1s1f /mnt/usr
２．migration.sh
#!/bin/zsh
while read i
do
echo $i | awk '/^\//{ print "/sbin/newfs -U " $3 }'
echo $i | awk '/^\//{ print "mount " $4 " " $3 }'
echo $i | awk '/^\//{ print "dump -L -0 -f- " $2 " | ( cd " $4 "; restore -r -v -f-)"}'
done < "/etc/migfstab"
使用法： いまんところ、サブシェルに喰わせるコマンドを吐き出すようにしているから、シェルコマンドラインにリダイレクトすればよい。
何が行われるか確認したい場合は、単にシェルスクリプトを起動すれば良い。
例： migration.sh | /bin/zsh
10分くらいで作ったけど、何回使うんだろうか。これから出番が増えそうなので（汗 事故が無いように願いたい。
ツールを考えたので取り敢えず出してみる。これはファイルシステムの引越しを単純に行うだけのツール。すでにディスクの設定の殆どは終わっててアクセスできる状態になっていることが前提だ
１．/etc/migfstab
こんな形式のファイルを作る。移行先は何らかのファイルシステムにマウントする。
移行元物理パーティション 移行元ファイルシステム 移行先物理パーテーション 移行先ファイルシステム
例：
/dev/mirror/gm0s1a / /dev/mirror/gm1s1a /mnt
/dev/mirror/gm0s1d /tmp /dev/mirror/gm1s1d /mnt/tmp
/dev/mirror/gm0s1e /var /dev/mirror/gm1s1e /mnt/var
/dev/mirror/gm0s1f /usr /dev/mirror/gm1s1f /mnt/usr
２．migration.sh
#!/bin/zsh
while read i
do
echo $i | awk '/^\//{ print "/sbin/newfs -U " $3 }'
echo $i | awk '/^\//{ print "mount " $4 " " $3 }'
echo $i | awk '/^\//{ print "dump -L -0 -f- " $2 " | ( cd " $4 "; restore -r -v -f-)"}'
done < "/etc/migfstab"
使用法： いまんところ、サブシェルに喰わせるコマンドを吐き出すようにしているから、シェルコマンドラインにリダイレクトすればよい。
何が行われるか確認したい場合は、単にシェルスクリプトを起動すれば良い。
例： migration.sh | /bin/zsh
10分くらいで作ったけど、何回使うんだろうか。これから出番が増えそうなので（汗 事故が無いように願いたい。
登録:
投稿 (Atom)