MLへ投稿したメールが戻ってこないというクレームがあった。/var/mail/logを調べると投稿メールは受け付けているが、配送はしていなかった。別のMLではそのようなことはないので、当該MLだけの問題のようである。
fmlでは投稿用リストと配送用リストの2本立てとなっている。Linuxサーバーの環境をFreeBSDサーバーへ移す際に、配送用リストの引っ越しを忘れたために、試験用に使った小生のアドレスだけが記述されたリストに基づいて配送されていた。小生だけにはちゃんと配送されていたので指摘されるまで気がつかなかった。投稿用リストを配送用リストへコピーして一件落着と相成った。
FreeBSDサーバーではqmailを使っているが、/var/log/maillogをチェックしたところ、MLでの配送がかなり高速化されたことがわかった。配送メンバー40名のMLでsendmailの場合、受け付けから全てが配送されるまで約2分であるが、qmailの場合は20秒であった。
sendmailでは配送途中に相手側MTAが受け取れない場合、そこで何回か再トライしているが、qmailではそれらを後回しにして送れるものだけを送っている。上記のような配送方法がメルマガでqmailが使われる理由になっているのであろうか。
結局、httpd、ipfilter関係のsyslogはcronで強引に廻した。現在のログファイルのバックアップコピーをとり、元ファイルを空にするスクリプトを記述して実行ファイルとした。/etc/crontabに１週間に１度そのスクリプトファイルを実行する設定を記述した。
これで、一応FreeBSDサーバー関係の全ての設定が終了したので本格運用へ移行した。その前に、家族のユーザー設定をして、fmlによるメーリングリスト関係のファイルをLinuxサーバーからWinPC経由でftpで引っ張ってきた。
RT314ルーターのNAT設定をFreeBSDサーバーとして各メーリングリストへサーバー変更のメールを出した。less
/var/log/maillogでSHIFT+fとしてリアルタイムで監視すると確かにsendmailによる配送よりも速いようである。
息子からメールが出来ないとクレームがあった。各人のメーラーの設定も変更してこれで完了である。
FreeBSDはASUSのATタイプのM/Bを使ったPCで開発している。公開しているLinuxサーバーはこれまたATタイプであるがこちらはSOYOのM/Bを使っている。両者で使っているNICはメーカーは違うが同じチップセットのものである。
今回の実験はASUSで開発したFreeBSDが入ったHDDを公開しているサーバーへ装着したらどうなるかということである。装着して電源ONとするとブートが進みもう少しでloginプロンプトが出る寸前の
Recovering vi editor sessions:
というところで止まってしまうが、数分我慢すると無事loginプロンプトが現れてブート完了した。その後、WinPCからSSHで接続しようとするとloginプロンプトが出るまで数分かかるが、接続してしまえば通常の状況と何ら変わらない。Linuxではハードウェアをチェックするデーモンが走るので今回のような事をしてもかなりスムーズにブートできるが、FreeBSDではそこまで行かないようであるがブートできることは確認できた。
syslogであるが、ipfilterの結果を出力するipmonというデーモンのオプションが現在-Dとなっているが、syslog経由で出力するオプション-Sに変えてみたが、残念ながら廻らなかった。
最初、このオプションを間違えて小文字で-sとしたらブート中にipmonの起動で止まってしまった。起動用FDを用意してなかったので、ddでフルコピーしたHDDからブートし、現用HDDをマウントして/etc/rc.confを書き直した。その際もなかなかマウントできなくて強制オプションの-fを付加してようやくマウントできた。このままでは埒があかないので、やはりcronでお茶を濁すことになりそうである。
FreeBSDサーバーにおけるログ環境であるが、ipfilterとapache(httpd)関係はsyslogdを経由しないで出力されるようであり、newsyslog.confにローテーションを記述しても廻らなかった。Linuxサーバーのapacheではデフォルトで/var/logに出力されたログがローテーションされているが、FreeBSDではそのような設定になっていないようである。
ipfilterも/var/ipflogへ出力する設定になっているが、ログが廻らないのでかなり大きなファイルとなっている。ログ・ローテーションができないようであればcronで1週間毎にバックアップを取るような設定を考えるとしよう。
その後、Web検索でいくつかの情報がヒットした。/etc/newsyslog.confの記述ヒントがあり、それに従って書き換えてみたが、うまく廻っていない。また、こんなところでハマるのはイヤだが、やはりハマってしまうのだろうな。
syslogも解決したので、FreeBSDサーバーの試験運用を開始した。Linuxサーバーからwebのデータを一旦WinPCへftpでおとし、そのデータを今度はFreeBSDサーバーへアップした。wwwカウンターの値もセットし直したので、RT314ルーターのSUA(NAT)でポート80をLinuxサーバーのIPからFreeBSDサーバーのIPへ振り替えた。メール関係は家族のアドレスやMLの配送アドレスが未設定なのでLinuxサーバーのままである。もちろん、syslogもFreeBSDサーバーの方へ振り替えた。これで数日運用してログの貯まり具合やその他の不具合をチェックするつもりである。
ルーターからのsyslogを受け取らない状況であるが、syslogdの設定をいろいろと変えた結果、#syslogd
-a '*:*'と記述することによって解決した。-aオプションはLinuxのsyslogdの-rオプションに相当する外部からのlogを受け取るためのもので、-rよりもかなり詳細な設定が可能であるが、*:*とすることにより何でもOK状態となる。
ここまでは良かったのであるが、このオプションでsyslogdを起動するとどういうわけかルーターと加入しているプロバイダーのDNSでエンドレスにバケットがやりとりされてしまう。我が自宅サーバーは自前のDNSサーバーを持っていないので、正引きはプロバイダーのDNSサーバーをそのまま使っている。Linuxサーバーでは特に問題ないのでFreeBSDサーバー特有の問題らしい。syslogdをデフォルトの-sオブションで起動するとエンドレスでパケットのやりとりはしない。mansyslogdを読むと-nオプションがあるのがわかった。これはIPアドレスの逆引きをしないというもので早速設定したらエンドレスバケットはようやく止んだ。
現用Linuxサーバーから異音がしたので、停止して内部の清掃を行った。CPUクーラーがかなり汚れていたので、ヒートシンクからファンを外して清掃し組み立てた。しかし、異音は相変わらずなので、ファンではなくてハードディスクからの音なのかもしれない。このディスクは使い始めてから1年も経っていないが、ほぼ連続運転であるので普通のPCの場合の数倍の速さで劣化することになる。
念のためddによるコピーを実施した。FreeBSDの方も大方の設定が完了したので、こちらの方もddによるコピーをとった。Linuxと同じ10GBのハードディスクであるが、FreeBSDの方が約5割ほど余計な時間がかかるのは何故なのであろうか。マシンスペックもFreeBSDの方が若干ではあるが上である。
現用のLinuxマシンでは問題なくルーターからのsyslogを受け取っているので、tcdumpで観察してみた。usageは
#tcpdump ip host 192.168.0.1 and 192.168.0.10
でサーバー(192.168.0.10)とルーター(192.168.0.1)間のパケットを記録するわけである。結果は
08:33:45.980393 eth0 < .4096 > ns.n-mmra.net.syslog: udp 88
08:38:14.946510 eth0 < .4096 > ns.n-mmra.net.syslog: udp 82
08:38:56.931597 eth0 < .4096 > ns.n-mmra.net.syslog: udp 83
となっていた。どうやらRT314のsyslogは514/udpを使っていないのかもしれない。
FreeBSDサーバーのバックアップ用ハードディスクを用意するために20GBのハードディスクを購入した。別に20GBでなくても良いのだが、これが一番安かった。これをカミさんマシンにセットして現用の10GBから20GBへフルコピーした。これでFreeBSDサーバーで使用しているのと同じ10GBHDDが用意できたことになる。
この10GBHDDをサーバーマシンのセカンダリー・マスターとしてセットするとad2として認識したので、
dd if=/dev/ad0 of=/dev/ad2
としてOS+アプリの丸ごとコピーを作った。コピー先のHDDは特に事前フォーマットする必要はないが、コピー終了までにかなりの時間がかかる。コピー開始から２時間経過しても終了しないので、ctrl+cで強制終了したところ、70%終了して残り30%ほどであった。我慢できないとこのザマである。結局最初からやり直したがコピー・レートが0.9MB/秒なので3時間かかった。
ついでにsyslogの設定をした。ルーターからのlogを受けるためには/etc/syslog.confに
local1.* [TAB空白]/var/log/rt314
を記述する。
#touch /var/log/rt314
で空のログファイルを作っておく。これだけはダメで/etc/newsyslog.confにログ・ローテーションを記述する。今回は
/var/log/rt314 644 5 100 * Z
とした。これは100kBになると新しいログとして古いログは圧縮して5個で廻すことを意味している。
FreeBSD4以上ではsyslodはリモートからのログを受け取らないので、/etc/rc.confに
syslogd_flags="-a 192.168.0.0/24:*"
というオプションを記述する。ipfilterに穴を開ける必要があるのが、とりあえず/etc/rc.confでNOとしておいた。これでうまくログを受け取るはずなのだが・・・ハマってしまった。
ipfilterの設定をした。外部からはhttp、smtpのみを通し、LAN内部ではこれに加えてssh、ftp、popを使えるように設定した。設定は昨年実験したものと同じであるが、やはり、httpが通らなかった。いろいろと調べてany
to any port = httpのような記述にしたら通るようになった。以下は/etc/ipf.rulesの結果である。
ns# ipfstat -i
block in log quick from any to any with ipopt
block in log quick proto tcp from any to any with short
pass in on ed0 from any to any head 100
block in from 127.0.0.0/8 to any group 100
block in from 192.168.0.20/32 to any group 100
block in quick from 10.0.0.0/8 to any group 100
block in quick from 172.16.0.0/12 to any group 100
block in quick from 0.0.0.0/8 to any group 100
block in quick from 169.254.0.0/16 to any group 100
block in quick from 224.0.0.0/4 to any group 100
block in quick from 240.0.0.0/4 to any group 100
pass in quick proto tcp/udp from any to any port = http group 100
pass in quick proto tcp from any to 192.168.0.20/32 port = 25
flags S/SA group 100
pass in quick proto tcp from 192.168.0.0/24 to 192.168.0.20/32
port = 110 flags S/SA group 100
pass in quick proto tcp from 192.168.0.0/24 to 192.168.0.20/32
port = 22 flags S/SA group 100
pass in quick proto tcp from 192.168.0.0/24 to 192.168.0.20/32
port = 20 flags S/SA group 100
pass in quick proto tcp from 192.168.0.0/24 to 192.168.0.20/32
port = 21 flags S/SA group 100
block in log quick from any to any group 100
pass in quick on lo0 from any to any
ns# ipfstat -o
pass out on ed0 from any to any head 150
block out from 127.0.0.0/8 to any group 150
block out from any to 127.0.0.0/8 group 150
block out from any to 192.168.0.20/32 group 150
pass out quick proto tcp/udp from 192.168.0.20/32 to any keep
state group 150
block out quick from any to any group 150
pass out quick on lo0 from any to any
前回、fml3.0.1でインストールに成功したので、最新のバージョンであるfml4.0.3を再インストールしてみた。結果は全てOKであった。やはりユーザー「fml」でのインストールに問題があるようである。メール環境の設定はこれでOKとなったので、次はipfilter設定かな。
qmailでのfml設定であるが、少し趣向を変えてみた。一つはユーザーの設定である。fmlでは管理用のユーザーとして「fml」を登録し、それによるインストール、設定管理を勧めている。fmlをインストールしてMLを設定し、試験投稿するとハンドリングされたメールはユーザー「fml」へ配送されそこで止まってしい、メーリングリストへ登録したリストに基づく配送が出来なかった。そこで、普段使っているユーザー(これはwheelグループに属している)でfmlをインストールした。
もう一つはインストールしたfmlもバージョンダウンした。現用Linuxマシンで使用しているfml-3.0.1とした。これによりとりあえず一つのMLを設定し、試験したら問題なく配送された。マシンをリブートしても全く問題ない。現用マシンから配送リストである２つのファイルをFreeBSDマシンへコピーし、ルーターのポート25のNATをFreeBSDマシンへ変更して配送試験メールを出した。/var/log/maillogで配送状況を監視するとsendmailとはかなり違った動作をするが、sendmailよりは高速動作しているようである。
残り二つのMLも設定したがこれも全く問題なく動作した。このままで先に進むか、fml4.0で再トライするか思案のしどころである。
tcprulescheckの記述であるが、web検索の結果によると#tcprulescheck
tcp.smtp.cdb IPではチェックできないようである。とりあえず、チェックはあきらめてpopの設定に移った。
qmailはpopの認証に対応していないとのことで、別のソフトをインストールする必要がある。checkpasswordというソフトをインストールしてtcpseverからの起動設定としたが、認証ではねられてしまう。またまたハマりそうなのでとりあえず手慣れたinetdからの起動とした。
qmailの設定にハマっている。tcpserverから起動したいと思いソフトをインストールしtcp.smtp.cdbを設定した。これはinetdのhosts.allowファイルのようなものであり、この設定が正しいかどうかチェックするtcprulescheckというプログラムがある。これにハマってしまった。web検索によると
#tcprulescheck tcp.smtp.cdb IP
でチェックできるはずであるが、どんなIPを設定してもallowとなってしまう。英語サイトまで含めて再度web検索するといくつか情報がヒットした。調査したいIPアドレスを環境定数として設定する必要があるらしいことが分かったが、ここで残念ながら時間切れである。
qmail+fmlにハマっている。本日はnewmlで作るML名と同じユーザーを設定し、その/home上に.qmail*ファイルを配置する方法にトライした。残念ながらうまく動作しなかった。
あっという間に3連休も終わってしまう。本日もqmail+fmlに挑戦したが、ますます泥沼にハマるだけの結果となった。Web検索の結果ではqmail環境でfmlを使う方法はいくつかあることがわかった。一度は成功しているのでそれが再現できないのは悔しい限りである。
FreeBSDサーバーの設定を再開した。とりあえず、MTAとしてqmailの動作確認が終了したので、メーリングリスト・ソフトのfmlを導入した。最新のfml4.0.3をインストールして、Linuxサーバーで稼働中のメーリングリストの一つを設定し、メンバーとして自分用のアカウントを設定した。
しかし、投稿メールは受け付けるのだが、メンバーへの配信はしない。maillogを参照するとfmlで処理しているが、qmailによる配信へうまく渡せていないようである。web検索したらassignファイルについての情報がヒットしたので、assignファイルを書き換えたら配信できるようになった。気をよくして、別のMLを設定したら、また配信しなくなってしまった。どうやらハマってしまったようである。
qmailの設定にトライした。今回もtcpserverでつまずいてしまった。ソフト自体は問題なくインストールできるのだが、qmailをtcpserver経由で起動するためのusageを記述する際にsploggerオプションを設定したのだが、リダイレクトが不正と怒られてしまう。sploggerなしでは問題なく受け付けてくれるのだが、これも前回のトライでも同様であった。仕方ないのでinetd経由で起動させることとした。
サーバーのFreeBSDへの移行をこのお正月休みの間にやろうと思っていたが、何もしない内に半分すぎてしまった。これではと思い、今日はハードディスクを購入してきた。本当は年末に購入しておくつもりだったが、忙しくて今日になってしまった。一番安かったSEAGATEの20GBを買い、常用Winマシンに入っている10GBのものと入れ換えた。20GBを事前にシステム込みでフォーマットしておき、常用WinマシンのDドライブとして認識させた。常用Winマシンの仮想メモリを使用しない、隠しファイルを表示させるにした後、Cドライブを全て選択してDドライブにコピーした。20GBをマスターに接続しFDISKでアクティブドライブにして、再起動するとWinが立ち上がった。10GBのHDDをFreeBSDに転用するわけである。同じ型式の10GBがもう１台あるので、ddにによるOS込みの丸ごとコピーもこれで問題なくできることになる。ついでに、「qmailで作る快適メールサーバー」という解説本も買ってきた。
「安定稼働しているサーバーには手をつけるな」というのが鉄則らしいが、年末年始はFreeBSDへ移行しようかな。FreeBSDは3.2GBのHDDで実験しているが、これではいかにも心許ないのでもっと容量のあるHDDを購入することにしよう。
FreeBSDはhttpとsmtpについては構築ノウハウが得られた。しかし、qmailではうまくいかず、相変わらずのsendmailである。ipfilterも適用するとどういうわけかwwwがうまく通らない。
FreeBSDで遊んでいる。apacheをパッケージからインストールした後、wwwcountをportsから入れた。portsを使ったのは初めてである。Linuxサーバーのコンテンツをftpで移した。
「システム管理者虎の巻」というキャプションにひかれて「BSDmagazine」の9月号を買った。この雑誌は以前から本屋で立ち読みはしていたが、FreeBSDをまじめにやろうと思い買うことにした。12月発売の次号も「システム管理者虎の巻」の続きがあるようなのでちょうど良かったかもしれない。
秋葉原でFreeBSD関係の本を探したが、新刊は出ていなかった。それでも比較的新しい１年前に発刊された「FreeBSD・コマンド・スーパーリファレンス」を購入した。HDD購入はやめて、とりあえず手持ちの3.2GBにインストールした。終了後、ブートシーケンスが途中で「ad0デバイスが見つからない」とメッセージが出で止まってしまう。FAQを見たり、インストールテキストを読み返した結果、パソコンのIDEでプライマリーのスレーブに接続されていたCDROMをセカンダリーのマスターに接続替えしたら、無事ブートできるようになった。
インストールには昔購入した解説本が役立った。インストーラーは昔とあまり変わっていないようである。Xなしでインストールしたが、inetdはデフォルトで全てコメントアウトされていたので、セキュリティー的には問題ない。デーモンはsshとsendmailがデフォルトが動いていたので、LAN内のWinPCからsshで簡単にアクセスできた。
FreeBSD4.4Rの付録にひかれて、UNIXUSERの12月号を買った。FreeBSDでのサーバー構築の第一歩になるのであろうか。余っているHDDは3.2GBのものしかないので、20GB程度のものを買ってそれにインストールした方が良いのかもしれない。別のパーツの購入もしたいので、久しぶりに秋葉原へ出かけようと思っている。