メールサーバには送信側のプログラムと受信側のプログラムがあり、それぞれ
smtp および pop3 プロトコルを使用して通信する。この送信側のサーバプログラムが
Sendmail をはじめとするMTA(Mail Transfer Agent)で、受信側のサーバプログラムとなるのが今回紹介する
qpopper をはじめとするPOPサーバである。ちなみにPOP3とは
Post Office Protocol version3 の略称であり、MAILBOXへ配信されたメールを取得するためのプログラム群である。
(現在メール受信プロトコルにはPOPの他、IMAPなどがあるがこれについては別項に譲ることにする。)
■ qpopper
について
qpopper は現在多くのメールサーバで使われている標準的なPOPサーバである。POPプロトコルの仕様による本質的なセキュリティの弱さを別問題とすれば、qpopperの安定性と基本機能の信頼性は高く評価できるものである。
一方、qpopperはrpmで簡単にインストールできるアプリケーションではないため、利用にあたってはtarballの展開とオプションを指定してのコンパイル作業が必要となる。また、新しいバージョンではconfig志向(デーモン志向というべきか)が強まり、ユーザの設定範囲が大幅に広がったことから、経験の少ないユーザはかえってqpopperの利用を敬遠する傾向があるようだ。
しかし、qpopperによるpopサーバの構築は、手順通りに確認しながら行えば必ずしもむずかしいものではない。むしろ初学者にとっては、基本的なpopサーバの機能と構成を知るための格好の学習材料となるだろう。本稿ではRedHat Linux での利用を前提にインストレーションと設定の解説を行う。
■ ダウンロード
Eudoraのサイトhttp://www.eudora.com/qpopperから qpopper4.0.5.tar.gz を/usr/local/src等にダウンロードする。qpopperのアーカイブはそれほど大きなものではなく、むしろこの手のプログラムとしては小さなものに類するのでHDDの容量を気にすることはほとんどないはずである。
ランレベル5でブラウザを使えるサーバならホームページから取得してもよいが、そうでない場合はwget コマンドを使ってアーカイブを取得すればよい。 以下にwgetコマンドの基本的な使い方を示す。
[root@server root]# wget
http://core.ring.gr.jp/archives/net/mail/qpopper/qpopper4.0.5.tar.gz
--07:40:56--
http://core.ring.gr.jp/archives/net/mail/qpopper/qpopper4.0.5.tar.gz
=> `qpopper4.0.5.tar.gz' core.ring.gr.jp をDNSに問いあわせています... 完了しました。 core.ring.gr.jp[203.174.65.19]:80 に接続しています... 接続しました。 HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 2,281,284
[application/x-tar]
100%[====================================>]
2,281,284 680.66K/s ETA 00:00
07:41:00 (680.66 KB/s) -
`qpopper4.0.5.tar.gz' を保存しました
[2281284/2281284]
|
なおwgetコマンドは基本的にCURRENTディレクトリにファイルをダウンロードする。ローカルのディレクトリを指定してダウンロードしたい場合は-pオプションを使いwget -p
/usr/loca/src/ TARGET_URLの書式で指定すればよい。またプロキシを使っている環境やその他の設定を行いたい場合は/etc/wgetrcを編集する。以下にwgetrcよりプロキシ設定部分を示す。
…
#
You can set the default proxies for
Wget to use for http and ftp. # They
will override the value in the environment. http_proxy
= http://proxy.yoyodyne.com:18023/ ※コメント外し自環境のhttpプロキシを指定 ftp_proxy
= http://proxy.yoyodyne.com:18023/ ※コメント外し自環境のftpプロキシを指定
#
If you do not want to use proxy at all,
set this to off. use_proxy = on ※コメント外す
…
|
■ アーカイブの展開
本稿ではダウンロードしたアーカイブを/usr/local/src/以下に置くものとして論を進めるが、その他のディレクトリに置く場合は適宜読み替えること。アーカイブを適切なディレクトリに置いたらまずsuを実行し、rootユーザとしてオペレーションを行う。
アーカイブはqpopper4.0.5以下に展開されるので展開が終了したら、この作業ディレクトリに移動する。
■ コンパイルとインストール
コンパイルにあたっては当然Compilerとライブラリが必要である。システムインストール時にパッケージを選択していなかったら、追加インストールしておく。セキュリティ上の理由で実機上にCompilerを置きたくない場合、クローン機の上でコンパイルし、必要ファイルだけを配置することも可能である。 またコンパイルに当たっては必ずREADMEファイルを読み、要求されるライブラリやツールのバージョンを確認しておくこと。(それを満たさない場合は、まずライブラリ等の確保が先決となるので注意。まれにコンパイルできても正しく動作しないことがある。またコンパイル時はOSの環境変数をLANG=Cで英語にしておくこと。これも一般論だが、日本語環境では出力に2バイト文字が入るため、失敗することがある。)
Makefileの修正
Eudoraから提供されているqpopperのMakefileは、そのままではRedHatのディレクトリツリーと一致していないので、コンパイルオプションで実行ファイルのパスやマニュアルパスを以下のように指定しておく。
また、shadow passwordを使用している場合は --enable-specialauth の指定が必須なので注意すること。これを指定しないとパスワード認証で失敗する。
コンパイル
qpopperのコンパイルはごく簡単なオペレーションで済む。型通り make → make install へと進めばよい。
これらの作業で /usr/sbin にpopperがインストールされ、オンラインマニュアルが/usr/share/man/man8に配置される。なお、ゼロからやりなおしたい場合はmake realclean でmakefileをクリーンして元へ戻せるので、恐れずにやってみることが大切である。 (※make realcleanを実行した場合は、ふたたび
configure をやりなおす必要がある。以上念のため。)
■ デーモン定義ファイルの作成
qpopperは通常xinetd経由で起動するデーモンとして設定される。xinetd経由のデーモンとして稼動させるためには、以下のファイルが必要となる。
(pop3sを使う場合→
/etc/qpopper995.cfg)
■ /etc/xinetd.d/popper
の作成
xinetd環境で起動する場合はデーモン定義ファイルpopperを作成する。このファイルは./samples
に雛型があるので、新たに書き起こすよりもそれを使用するのが無難である。
設定自体はdisable=noにする以外、デフォルトのままでよい。ただし、後半部は pop3s のための設定なので、不要なら # をつけてコメント化する。
service pop3{
disable = no
flags = REUSE
NAMEINARGS
socket_type = stream
wait = no
user = root
server =
/usr/sbin/popper
server_args = popper
-f /etc/qpopper110.cfg -s
instances = 50
disable = no
port = 110
per_source = 10 }
■ /etc/qpopper110.cfg の作成
popper起動時のconfigファイルを作成する。これも./samplesの配下に雛型が用意されているので、コピーして使用できる。
qpopper.configでは設定がすべてコメント化されているので、必要な設定項目から # を外す必要があるが、このファイルにはroパーミッションがセットされているので、次のようにchmodしておく。
ro属性を変更したら次の2行から # を外して設定する。
set shy = true(デフォルトはfalse → バナー情報を隠蔽する) set log facility = local1(ログファシリティの設定:local1
が使用されている場合は local2-7 のどれかに割り付ける)
作業が終了したらファイルパーミッションを元に戻しておく。
※ pop3s が必要なら同様に雛型ファイルをコピーする。このときファイル名はpop3s用に変更する。
一般論ではあるが、popサーバに関しては通信にかかわるプライバシーを留意しつつ、ログの採取が必須である。ログ採取にあたっては/etc/xinetd.d/qpopper110.cfgにファシリティを指定すること、/etc/syslog.conf に以下の一行を追加すること、さらに/etc/logrotated.d/qpopperファイルの設定が必要である。また後述するが、ロギングは運用フェーズでの重要な設定事項となるため、必ず検証して動作確認が必要である。
■ syslog.conf へのログエントリ追加
qpopperは標準ではロギングが定義されていないため、syslog.confへログエントリを追加する。ファシリティの設定にあたっては既存のサービスと競合しないように注意したい。たとえばoracleがlocal0を使っていたり、ciscoがlocal7を使っていたりすることあるので、local2-5のような中間位置のファシリティを指定するとよい。いずれにせよファシリティのバッティングが生じるとあとあと面倒なので、必ず事前に調査するべきである。)
次に空のログファイルを touch しておく。これはsyslogdを再起動したとき/var/log/popper.logが存在しないとエラーになるためである。
■ syslog の再起動
ログの設定をsyslogdに通知する。これはsyslogを再起動すればよい。
※serviceのように通常/usr/sbinに格納されているコマンドは、フルパスで使うのが安全である。RedHatでは/usr/sbinにパスを持っているバージョンが多いが、システムによってはパスが通っていないことがある。
■ xinetdの再起動によるpopperの起動
xinetdを再起動してxinetd経由で起動するpopperの設定を読み込ませる。
ここでソケットを表示させ、110番がオープンしていることを確認しておくとよい。
■ mailコマンドによるテストメールの送信
自分自身のメールスプールにテストメールを送信して、popサーバのテスト準備をする。これはsendmailのようなMTAがデフォルトで動いていることが前提だが、通常のRedHatならば問題ないはずである。
■ telnet による接続確認
telnetで直接110番ポートを叩き、POPサーバへの接続を確認する。
以上のように出力されたらひとまずOKとする。
以上のようにサーバ名とバージョンが出力されたらNG。POPサーバの機能としてはなんら問題はないのだが、サーバ名およびバージョンが出力されてしまうのは感心できない。shyモードを設定するのはサーバセキュリティが目的なのでこのように出力されてしまう場合は/etc/xinetd.d/qpopper110.cfgを再確認すること。(#をはずしただけでset shy=falesのまま、ということがよくある。)
telnetによるメールボックスの確認
上記のテストに引き続き、次のPOPコマンドを投入して反応を見る。
※正常な反応が確認されたら、今度はわざと認証されないパスワードを入力してERRを発生させておく。これはsyslogへ[auth]ログが出力されることを確認するためで、これを実行したのち/var/log/mailに当該エラーに関する[auth]ログがあればOKとする。
設定後、動作確認が終わると一安心するのは人情だが、これはあくまで導入・構築に限った安心であることをお忘れなく。サーバを使う側にとって重要なのは運用・管理フェーズをいかに少ない障害で乗り切れるかにかかっている。万一障害が発生したり何らかのアタックが行われたような場合、ログの参照が必須であるため、仕様どおり確実に採取されているかどうか必ず検証しておかなければならない。
■ ログの確認
先に行った検証のタイムスタンプと通信内容が正しく記録されていたらOK。
■ ログのローテーション
/etc/logrotate.d以下にログローテーション用ファイル popperを作成する。
# cd /etc/logrotate.d # vi popper
/var/log/popper {
weekly
compress
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2>
/dev/null || true
endscript }
ここでは一週間ごとのローテーションでバックログは圧縮する設定とした。設定後はsyslog を再起動し、新しい設定ファイルを読み込ませておくこと。
参考: syslogd
を再起動させるのは、ログがローテーションされたとき syslogd
がそれまで書き込んでいたログファイルを見失ってしまうからである。このまま放置しておくとそれ以降ログの採取はされなくなってしまうため、syslogd
を再起動して新たなログファイルを認識させる必要がある。ログローテーションファイルに
postscript を書いておくのはこのためで、上記設定では
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2>
/dev/null || true の一行がそれに当たる。すなわち、/var/run以下の.pidファイルからsyslogd
のプロセスIDを調べ、HUP シグナルを送る処理を追記すればよい。
■ ローテーションの検証
設定ファイルが正しく記述されていても、設定直後はまだログファイルはローテーションされていない。当たり前のことだが、設定直後はまだローテーションの周期が来ていないからである。ログをローテートさせるためには前回ローテートした日付と現在の日付を比較してローテーション時期を判断する必要がある。Redhat
Linuxの場合、前回のローテーションは/var/lib/logrotate.statusに記録されている。新しい設定を検証するにはこのファイルを書換えてlogrotateにローテートする時期が来ていると誤認(?)させればよい。
ここでlogrotateは通常cron.dailyにセットして実行させるプログラムであり、デーモンではないことに留意すること。cronによって毎日決まった時刻に起動されるlogrotateは、まず前回ローテートした日付を記録したファイル/var/lib/logrotate.statusを読み込み、現在の日時と比較する。設定の期日が来ていなければ何もせず、過ぎていればログファイルのローテーションを実行し、logrotate.statusのタイムスタンプを更新する。 /var/lib/logrotate.statusは以下のようなフォーマットで保存されている。
logrotate state -- version 2"/var/log/messages"
2004-4-2"/var/log/secure" 2004-4-2"/var/log/maillog" 2004-4-2"/var/log/spooler" 2004-4-2"/var/log/boot.log" 2004-4-2"/var/log/cron" 2004-4-2"/var/log/xferlog" 2004-4-2"/var/log/wtmp" 2004-4-1"/var/log/rpmpkgs" …
このファイルの日付を『ローテーションの周期分以上』過去へ戻して上書きしておけば、起動したlogrotateをまんまとだますことができる。これを確認するには次のようにlogrotateをコンフィグファイル指定つきで起動する。
これによって/var/lib/logrotate.status
の変更した日付が現在の日付になっており、新しく
popper が入っていればlogrotateの動作はOKである。ただし、logrotateをだましてログファイルを出力させたとしても、それは初回のログが作られただけであることに注意されたい。本当にローテーションが実行されることを確認するためには/var/lib/logrotate.statusに新しく記述されたpopperの日付を再度過去に戻し、logrotateを実行する必要がある。
これによって /var/log 以下に新しい popper と popper.1.gz ができていたら今度こそ検証完了。
|