カテゴリー: サーバー管理

FreeBSDのルーターの設定をやり直してから、MRTGでSNMPの情報が取得できなくなっていた。

net-snmpをインストールしてsnmpwalkをかけても返事が返ってこないことから、症状はSNMPのパケットがうまく出ていないらしい。

で、ipfwでSNMPのudpポートを開く設定に。ここで問題なのは、udpは本来一方的垂れ流しだが、SNMPのqueryはoutgoingで適当に選ばれたportから対象のport 161にqueryが飛ぶと、返事が対象のport 161からoutgoingで選ばれたportに帰ってくるということ。だから単純にport 161へのoutgoingを許可しただけだと、返事が入ってこないのでNo Responseになってしまう。

で、ふと思い出したのが、これってntpの場合と同じだな。

で、ipfwの設定で以下の設定を追加する。

ipfw add pass udp from ${iip} to any 161 keep-state

keep-stateって指定がいったい何の役に立つのかと思っていたが、ここで役に立つのね。keep-stateを指定しておくとoutgoingしたudpに対する返事が帰ってくることを想定してしばらくの間、firewallに穴を開けておいてくれるわけだ。

で、めでたくsnmpwalkでルーターの設定が取得できるようになった。

あとはMRTGの設定を書くだけか。

NWNのLinux用サーバーをFreeBSDで動かす。結論から言うと、普通に動く。

まず、BioWareからServer用パッケージの最新版を落とす。その中で必要なファイルは一つだけ。

linuxdedserver166.tar.gz

これ以外のファイルはWindows版の日本語NWNから持ってこないと、サーバーが日本語の言語Signatureにならないので、日本語Clientでプレーできない。

次にサーバーにNWNのデータを格納するフォルダーを作る。NWNのLinuxサーバーはユーザー権限で動かしても構わないので、どんなユーザーでどこに掘っても構わない。

そのフォルダに、Windows版のインストールディレクトリから以下のファイルおよびフォルダを転送する。転送前にWindows版のバージョンをLinuxサーバーのバージョンと合わせて置くこと。

chitin.key
data/*
database/*
dialog.tlk
dialogf.tlk
hak/
modules/
nwm/
nwplayer.ini (Windows版でマルチプレイヤーサーバーの設定をしておくとそのまま使える)
override/
patch.key

以上のファイルを転送したら、最後にこのフォルダにLinuxサーバーのアーカイブの中身を展開する。

次にアーカイブから展開されたfixinstallスクリプトを走らせる。Linux用なので、shellがbashになっているので、bashがインストールされてなければインストールすること。また、スクリプト内の実行shellの指定が/bin/bashになっているが、FreeBSDのportsでインストールすると/usr/local/bin/bashで入るので、これも変更してから実行する。

fixinstallで足りないフォルダ等を見つけると警告してくるので、その場合は適宜Windows版のフォルダから転送すればよい。

全てが終われば、ユーザー権限でnwserverを実行すればそれで終わり。

nwplayer.iniで指定してあるポートでincoming packetが通過するようにファイヤーウォールを設定することを忘れないこと。

このサーバーはstdin/outでコマンドでコントロール出来るので、出来ればconsoleにする端末を別に用意してモニターしてあげるとよい。コマンド解説はServer用パッケージに含まれるreadme.linuxserver.txtを参照のこと。-quietオプションで完全なサーバーになるが、この場合はautosaveしか働かなくなるので注意。

モジュールとハックはそれぞれmodules/とhak/に入れる。ハックはファイル名を変更しないこと。モジュールはファイル指定が面倒になるので、簡単なファイル名に変更した方がよい。

いつの間にか、GW中にCOREBlogがVer.1.2にアップデートされていることに今更気付く。

で、当然ながらUpdateされた内容を吟味してこのサーバーを1.11から1.2に変更するかどうか、を考えないといけないわけだが・・・。

Changelogがねえよ。作者のページでCOREBlog 1.2の変更点は詳しくはChangelogを見てね、って書いてるのにリンクも張ってないし、本家配布元でChangelogをクリックすると、今回のアップデートで同梱されたPloneとの親和性を高めるSkinの使い方について書いてあるだけ。わしゃPloneなんか使ってないから、それ以外で何が変更されたのか知りたいのに。

まあ、Zope家さんから見れば、ソースも見ないようなヘタレユーザーなんか知らん、ということなんだろうが、COREBlogはZope普及の起爆剤、とか言っておいて、まともなChangelogも提示しない様なものは決して普及しないと思うんだが。

ということで今回はアップデートは見送り。Zopeってのはなかなか面白いいいシステムだとは思うが、こういうところでいちいち「なんでよ？」って思っちゃうんだよなあ。まあ、それを言うならなんらかの手段でContributeしろ、って言われて堂々巡りなんだろうけど。ってそれってLinuxのタコ論争の繰り返しじゃん。

COREBlogを貸し出してるユーザーがCSS等をいじりたいといってきたので、Contentsタブを有効にするためのSecurity設定を模索。

まずManage ZCatalog Entriesを有効にする。これでContentsタブが見える様になる。

次に、ドキュメントの内容やCSSの内容をいじれるようにするためにChange DTML DocumentsとChange DTML Methodsを有効にする。これらを有効にしていないと、ContentsタブでファイルをクリックしてもViewするだけになってしまう。

他にもChangeを有効にした方がいいものもあるかもしれないが、CSSやページ構成をいじるだけならこの二つで十分だろう。

Mac OS XをTigerにアップデートして、結果としてSafariのバージョンが2.0になってから、某所で運用している掲示板の日本語コードの判別に失敗するようになった。

その掲示板は、ApacheのDefaultCharsetも有効にせず、CGIからのCharsetも日本語コードを特に指定していない。DefaultCharsetを有効にすると、他のコードを使うCGIで問題になるし、CGIから直接返すとなぜかApacheが書き換えようとしてうまくいかない。

で、仕方なく各ブラウザの日本語コードの判別能力に期待していたわけだが、これまでSafariも1.3までは自動できっちりと認識していたのに、2.0のなって判別しないでDefault設定のShiftJISだと思い込むようになった。ていうか、2.0から自動判別やめてない？

仕方ないので、CGIがHEADセクションでMETAタグのHTTP-EQUIVでContent-Typeを返すようにCGIを書き換えて対処。

CoreBlogで日本語の検索を可能にすることにした。

とりあえず、単語分割用のSplitterで日本語が通るものを入れないといけないのだが、無駄が多いのを承知で単純な単語分割をするejsplitterを入れることにする。

といっても、ソースを取ってきて、Productディレクトリ(/usr/local/www/Zope/Product)で展開。ZopeのコントロールパネルからZopeを再起動して終わり。

次に、既に日本語非対応のSplitterで作られている分割単語の辞書であるlexiconを入れ替える。

まずはCoreBlogのContentでlexiconを削除する。次に、ZCTextIndexをAddして、idをlexicon、titleは空にしておいて、Splitterでejsplitter UTF-8を選択する。最後に、EntryからRecatalogを押すと、単語分割がやり直される。

Contentからlexiconを選んでQueryタブを選ぶと、ちゃんと日本語が分割されたか見ることが出来る。さすがに、辞書を使わず分割してるので、非常に馬鹿っぽいが、簡易検索には十分だろう。

これをCoreBlogから利用できる用にする為には、Content/modulesのなかのindex_htmlを開いて、検索部分でコメントアウトされてる部分を有効にするだけでいい。

FreeBSDのportsでpython&zopeをインストールしただけでは日本語が化けてしまうので、JapaneseCodecとpykfをインストール。といっても、portsではJapaneseCodecはzope用にinstallされるpython2.3でなくてpython2.4を要求するし、pykf自体はそもそもない。というわけで、ソースサイトからソースを取ってくる。

どちらも、展開してからそのディレクトリに移動して以下のcommandを入れるだけでinstall完了。pythonが2.3と2.4の両方入っている場合はinstallするpythonを間違えないようにしないといけないかもしれない。

/usr/local/bin/python2.3 setup.py install

後はmoblog用のpop3アカウントを用意して読み込み用のURLを叩いてあげれば読み込まれる。

Blogタイトルはメールタイトルが使われる。パスワードはメール本文一行目に書く。その次の行は無視されるので、一行あけて本文を書く。カテゴリーはおそらくmoblogセッティングで設定したデフォルトカテゴリーが使われると思われ。

L2TPv3がらみのVPN設計をしているついでで、IPSecによるVPNにもちょこちょこ手を出しているんだけど・・・。

FreeBSDのカーネルをIPSec対応にするためのオプションの指定が、

options IPSEC
options IPSEC_ESP
options IPSEC_DEBUG

となっているドキュメントが検索でわらわら出てくるんだけど、最後のIPSEC_DEBUGって本当にいるのか？

ごく稀に上の二行しか書いていないドキュメントも出てくるし、どっかの誰かがわけもわからず三つとも入れたのを真に受けてみんなそれを馬鹿正直に書き写してるような気がしてならない。

CoreBlogでイメージを貼り付ける場合には、まずイメージをサーバーにアップロードする必要がある。

まず、manageページから自分のブログディレクトリー内のimagesフォルダーに移動する。ここでAddでImagesを選び、ID(ファイル名)とTitle(イメージの説明)を入力し、イメージのファイルを指定してアップロードする。これで準備は完了。

次に、Entry作製時にIMGタグで埋め込む。この時、相対パス指定で”image/filename”と指定するだけでよい。

これで、Entry内に写真等のイメージを埋め込む事が出来る。

とりあえず、テストの為にXR-410/TX2-L2をLAN内に2台設置してL2TPv3トンネルを張ってみた。というより、あまりの簡単さに拍子抜け。

最初はトンネルの向こう側のルーターの出口インターフェースのIPにPingが通らないのでトンネルが張れてないのかと焦ったけど、XR-410は組み込みLinuxベースなので、たんなるLinuxのインターフェースの制限だった。L2TPにカプセルされたパケットは相手側ルーターでデカプセルされたあと、自身宛かどうかを見ないで出口インターフェースに送ってるらしい。で、Linuxの基本中の基本で自身のインターフェース宛のパケットは自身で出して受け取ることは出来ない、の制限らしい。それ以外は、非常に問題なくトンネル経由で全てのパケットがブリッジされてる。

というわけで、自身のLAN側インターフェースを使ってトンネルの向こう側からのパケットを受け取れないので、XR-410/TX2-L2をトンネル兼インターネットへのゲートウェイとして利用する計画は、トンネルされた側から外に出れなくなるので断念。別にゲートウェイを導入して、XR-410/TX2-L2はトンネルに専念させる設計に変更。

あとの問題は、L2TPv3 over IPSecにすると、XR-410はIPSec暗号化をソフトウェアでやるので、スループットが6Mbpsぐらいまで落ちてしまうことだけど、これは新しい研究室は上位にファイアーウォールが入ってるので、暗号化する必要はなしという判断で、IP Spoofing防止の為にL2TPv3の認証をハッシュ化するのみにとどめることに決定。