かなり突貫工事したログ。
複数の NIC を持ったインスタンス
NIC = IP と読み替えてもらっても結構です。 外部に疎通する NIC とバックエンドで通信する NIC を装備したインスタンスで postfix を動作させたのですが、バックエンド NIC を後から追加したので、疎通がうまく行かず四苦八苦してました。
main.cf の変更
postfix が LISTEN する IP は、デフォルトでは OS によって異なるようです。 これは inet_interface という値で指定します。
all であれば 0.0.0.0 が設定されるので問題なかったのですが、今回の postfix はユーザ認証無しで ローカル IP/24 からのみ接続できる設定でした。
また、 inet_interface が単一記述である場合、自動的に送信するためのルート ( smtp_bind_address の記述を省略できる )もその IP を利用するようです。
というわけでこうする。
inet_interface = {NIC1 の IP}, {NIC2 の IP}
smtp_bind_address = {NIC1 の IP}
NIC1 は今まで利用していた IP アドレス、 NIC2 がバックエンド通信用に追加したもの。
inet_interface が複数になることで、前述の通り postfix が取るべきルートがわからなくなっているので、 smtp_bind_address を設定してあげるのを忘れないこと。
syntax check
postfix check でコンフィグの syntax check が出来るので編集後は一度通しておくと、心の平穏が保てる。
編集したコンフィグの反映タイミング
そんなもん reload restart どっちかじゃろがい、と思っていたけどそうではないらしい。
へえっ、となったけど、ちょうど変更タイミングはメールサーバ利用していない状態だったので reload を実行して反映した。
LISTEN するポートが変更されない
よくよく考えれば当然なのだが、 reload でコンフィグは反映されたけども、プロセスが掴んでいる LISTEN の内容が変更されなく、追加したバックエンド通信用の NIC からのリクエストが connection refused になる始末。
telnet {NIC2 の IP} 25
など実施するも、当然つながるはずもなく。
一旦作業諦めた後に思い出して netstat -ant|grep -i LISTEN した所、 inet_interface に追加した IP が LISTEN されていないのを確認したので、諦めて /etc/init.d/postfix restart して、追加した IP が LISTEN されることを確認し作業終了。
ti-tomo-knowledge.hatenablog.com
どっと疲れてしまった。誰が作ったかもうワカラナイ状態のメールサーバ、運用中の変更なんてしたくないネ。
