2009年2月19日木曜日

NEXSM動かない原因

動かない原因がわからない……
デバッグのためログをとってみたが、正しくクエリが出ている。
phpは開発も保守もやってるので、お手のモノと思っていたが、
Java-Applet越しだとどうなってるかわからない。
「NO Gzip Format!」というエラーが出たんで、その線を探る。

phpスクリプト側が GZIPを使うのがだめだというのであれば、
止めてしまえばいいのかと思っていろいろいじったがダメ。
アプレット側がどうしてもGZIP'ed データがほしいというのだ。

 apacheがgzip圧縮に対応してないんかなと思っていろいろしてみるが
それでもない。

面倒だな~、Java側弄ってしまうかと思ってみたら、アンマリ弄りたくない
状態になっている(あちこち圧縮がらみの記述が多いから弄ると大騒ぎになる)
ので、これもできない。さて困った。

んー、PHPがGZIP圧縮できてないとか!?と思い立ったのはその時だった。

んで、portsで入れたんだから、 portsのphp5-extensionsみたら、全然入ってなかった・・・・・。orz..............

原因が分かった感じなので、さっさとコンパイルして、突っ込んだらちゃんと出るじゃない。
最後に一発エラーが出たけど、さほど重要じゃないポイントであったので構わないことにした。


んで、動かしてみたら、なんてことはない。 ただのネットワーク図が得意なJUNG派生アプレットじゃねえかこれ。 まあユーザインターフェイス的には面白いし、自由にレイアウト変えられるけれど・・・


結局、ネットワーク的なトポロジーを考えたようなデータを作ったりするわけじゃないじゃん!?

ということで、Nagiosいじりはまだまだつづくことになりそう。

NAGIOS & NEXSM

NAGIOS は 古くはNetSaintから発展した、かなりメジャーな統合監視システムである。

わが社では監視エージェントとして4つのシステムで100台前後を監視しているのであるが、やはりフリーソフトだからだろうか、幾分表現力に欠けるところがある。特にネットワーク図などの面倒なものについては、普通に使うとスター状のものしか書けない。 まあホストベースでの監視だから、スター状トポロジーで監視が成り立つのは普通なんだが、NRPEと複数のNAGIOS監視システム間で連合し、ネットワーク全体の監視システムに作り上げることも不可能ではないので、複雑なネットワーク形状を表現できてもいいのだが、やはり樹状図しか書けない。

そこで NEXSMを試すことにしたのだ。
前日の "JUNG"、java環境の構築はそのために行われたのである。

かなりてこずりながら、 必要とされる coltやら、common-collectionなどを揃えた。

私は、物事に取り組む際に最初からはさして判ってないが取り組むうちに、見えてくる人間だし、Javaは別に知らないでも怖くも、なんともなくてただただ動かせるようにするのが面倒なだけである。

今回のシステムの概要が見えてきたのは、必要なものを揃え終わってから、さあビルドすっかとえっちらみると、おやまantが要るんだ。 makeじゃないんだ、蟻んこが要るんだ…と、もう探す探す。

antが入ったら、common-collectionを作ろうとするがうまくいかん。 どうも野良ビルダには難しいので、jakarta-common-collectionから行こうかと動かしてみる。 まあこっちは、ちゃんと入った・・・っつか、javacが動く環境あればそんなに大変じゃない。

そんなこんなで、ようやく nexsmを ant でビルドができるぞ! とやると、今度はライブラリがないと騒ぐ。 いろいろ調べるとどうもライブラリの入る libsディレクトリに全部叩き込んでおかないとだめらしい。 しかも、バージョン依存だたりするので、common-collectionも3.2.1だけど、3.1に無理やり名前を変えて叩き込んだ。 jungはバージョン見てなかったのに気がついたが、あとから「組み込んじゃってるから要らない」的な記述発見! 何だよ~。

ビルドしてみたらあっけなくできてしまう。 java環境をこしらえるのと違ってなんてことはないのだ。

 んで、次にやることは・・・ INSTALL.TXTによれば、htmlというフォルダを 公開してどーちゃらこーちゃら。 phpが動かんとダメよん的な書き方をしていたので、もうすでにphpを入れたapache2.0が準備してあるわけで、まーこれでNAGIOS本体も動いているわけでね。

 公開フォルダにphpファイルの設定ファイルがあって、ちょっと手こずり。 これは書かれた通りにやれば何のことはないのだけれど、ちょっとしたミスが発覚。

 あとBASIC認証なんて気休め程度の保護を、手順通りに突破する方法が準備されてないらしく、大胆かつ屈辱的にURLにパスワードも入れておかなきゃならん状態。 ま、https使えって感じで、そもそも、うちもその辺見られても触られても良い(所詮NAGIOSで出来ることは知れてる)投げやりなので、別にいいんですけどね~。

ここまで来て、クライアントから見てみるとappletが立ち上がりました。 んーよく考えてみれば、ターゲットでしかJava動かさないんだよねこれ。Serveletですらない。PHPが動きゃいいんだ? ってなことにいまさら気がつくわけですよ。 ってことは~、わざわざ苦労してまでJava稼働環境をFreeBSDマシンにこしらえる必要なんかさらさらなかったわけでして・・・・・。

・・・・動かない。

2009年2月17日火曜日

JUNG

Javaな世界は避けていた。10 年くらい前に、痛い目に逢っているからだ。

とはいえ、避けるのは難しいな。

FreeBSDで、Java6を始めるにあたっては

/usr/ports/java/jdk16

から始めるのが最も楽だろう。まあ、make と打つと、ライセンスがらみでいろいろ言われるから、次のものを手で拾い集めてくること。

jdk-1.6.0.3p4_8
 jdk-6u3-fcs-bin-b05-jrl-24_sep_2007.jar
jdk-6u3-fcs-mozilla_headers-b05-unix-24_sep_2007.jar
jdk-6u3-fcs-src-b05-jrl-24_sep_2007.jar

上の奴は、簡単。 下のは手間がかかる。

jce_policy-6.zip
bsd-jdk16-patches-4.tar.bz2
tzupdater-1_3_11-2008i.zip


まあ、この辺を拾い集めてくれば jdk の 「材料」 はそろったが肝心のコードをコンパイルするための道具がないので、これも後から拾って来いと言われる。

diablo-caffe-freebsd7-i386-1.6.0_07-b02.tar.bz2

と、これらを集めると1時間かそこらでコンパイルは終わる。私のマシンは Athlon64/3500+(AM2+)でディスクもそれほど速くない機材。今2009年時点でも非力なもんだからもう少し早く片付く人の方が多いだろうね。


つことで、とりあえず 続きはまたあとで。

2009年2月6日金曜日

復活させるのにかかった時間・・・

先日ライブラリを消してしまっておかしくなったマシン。
/ を入れ換えただけで済み、 /usr /var は保全された。

しかし古いライブラリに依存するバイナリが多数残る。

make buildworld は当然だけれど、それ以前に perl すら動かない状況に頭を抱えることになる。

ldd * して、片っぱしからダメなバイナリをリストし、makeしなおした。
portupgrade/portmaster を計三回 forceオプションでやり直したら、
ようやく消えた。

その作業が完了するのに1日半くらいかかっている。
ライブラリがないので、当然動いていていいはずの基礎のツールが死ぬことで何度も portmasterが死んでしまうし、 rubyも死んでるので、 portupgradeもちゃんと動かなかった。
肝心のNAGIOSは、すでに別のマシンに移してしまっており、多少がガタガタしたが、今は問題もなく動いているので、慌てることはないのだが。

今回の目論見的には、サービス多重化が大きいかも。サービス多重化は将来的に落ちないシステムへ変わるだろう。

2009年2月4日水曜日

FreeBSDマシンをダメにし、復帰させる。

FreeBSD5.x時代から、連綿とアップグレードをかけ続けてようやく7.1p2迄更新をかけたマシンで、古いライブラリを消してしまったとたん破綻したお話。

古いライブラリを頼りに動いていたものばかりだったのだ。たぶん、7.0Relが動いていたもの。

buildworldして新しくなっていたはずなのに…。酷い目にあった。

そこで、レスキューを実施したが、バージョンが違うとレスキューがひっかけないし、何を間違えたか i386で構築したつもりで、amd64のマシンだったことに後から気が付き…。

壊しまくってしまいました。 まあ、/usr/local とか保全出来たのでよしとしよう。