老朽化した File Server の代わりに、NETGEAR 社の ReadyNAS Ultra 6 を購入してみました。
NETGEAR ReadyNAS Ultra 6
http://www.netgear.jp/products/details/RNDU6000.html
その辺で売られている、バッキャローや IO-DATA や Planex だののやつは、Windows で使用される SMB/CIFS 位にしか対応しておらず、かなりの割合でお話になりません。
対して、これは、SMB/CIFS だけではなく、AFP （Mac で使用されます） や NFS （Unix 系で使用されます） にも対応しているため、PC-UNIX である FreeBSD や、Mac OS X を使用しているわたしにとっては、ありがたい製品です （高いけど。。。）
で、セットアップしてみたところ、ユーザを追加しようとしたときに、FreeBSD で使用している UID (1000, 1001) が、組み込みのユーザと被ってしまって登録できなかったりなんかして。
Add-on として提供されている SSH ログインを使用して覗いてみると。。。
・・・samba, netatalk を組み込んである、ただの Linux Box だっ！（笑）
えーと。。。
ある意味、やりたい放題ですか？（汗
UNIX 系を使用している人にとっては、楽な製品かもしれませんね。。。
2011/06/04
syslog のお話
伝統的な syslogd を使用していると、リモートホストにログを取る場合は UDP で通信するしか手がないので、信頼性低いよね、と言う話があります。
そんな訳なので、syslogd を置き換えるのに、何かいいのはないかなぁ、と。
有名なのは syslog-ng ですよね。
だけど、syslogd とは config の書式に全く互換性がないのですよ。
そんなわけで、互換性のある書式のものをピックアップ。
msyslog
http://oss.coresecurity.com/projects/msyslog.html
TCP 通信できたり、MySQL や PostgreSQL とかに吐けたりする。
が、1.08g が最終バージョンの模様。
2003 年から更新されてないらしい。
rsyslog
http://www.rsyslog.com/
TCP 通信できたり、SSL だのにも対応しているらしい。（IPv6 ready）
圧縮通信とかもできるとか。
BSD-style のブロックが書けるけれど、一部非対応。
＃ #!prog, #+hostname, #-hostname と言った、旧 syslogd 互換書式は未対応
＃ !* や +* とかやっても、プログラムやホストはリセットされない （未実装）
開発が継続していて、現在の最新は v5.8.1。（v6 は開発中）
乗り換えるなら、rsyslog ですかね。。。
そんな訳なので、syslogd を置き換えるのに、何かいいのはないかなぁ、と。
有名なのは syslog-ng ですよね。
だけど、syslogd とは config の書式に全く互換性がないのですよ。
そんなわけで、互換性のある書式のものをピックアップ。
msyslog
http://oss.coresecurity.com/projects/msyslog.html
TCP 通信できたり、MySQL や PostgreSQL とかに吐けたりする。
が、1.08g が最終バージョンの模様。
2003 年から更新されてないらしい。
rsyslog
http://www.rsyslog.com/
TCP 通信できたり、SSL だのにも対応しているらしい。（IPv6 ready）
圧縮通信とかもできるとか。
BSD-style のブロックが書けるけれど、一部非対応。
＃ #!prog, #+hostname, #-hostname と言った、旧 syslogd 互換書式は未対応
＃ !* や +* とかやっても、プログラムやホストはリセットされない （未実装）
開発が継続していて、現在の最新は v5.8.1。（v6 は開発中）
乗り換えるなら、rsyslog ですかね。。。
2011/03/21
ディスク流用時のハマり点
Intel Mac (Mac OS X) 等にて使用した HDD を、FreeBSD に流用して使用するときは、ちょっとしたハマりポイントがある。
それは、パーティションテーブルが GPT (GUID Partition Table) になっており、旧来の MBR (Master Boot Record) ではない、と言うことだ。
FreeBSD の sysinstall では MBR しか扱えないため、GPT のディスクを繋ぐと、スライス操作が行えないという事態に陥る。
FreeBSD 8 系以降で GPT を扱うには、gpart コマンドを用いる。
（7 系では gpt コマンド）
ディスクを GPT から MBR にするのであれば、すべてのパーティションを削除して、GPT エントリを削除することになる。
そのためには、以下のように操作する。
（以下の操作に出てくる da0 は操作するデバイス。 /dev/ を付けてはいけない）
まず、GPT の情報を取得する。
# gpart show da0
=> 34 1953525101 da0 GPT (932G)
34 6 - free - (3.0K)
40 409600 1 efi (200M)
409640 1953115495 - free - (931G)
次に、存在するパーティションを削除する。
（ここでは、1 しかないので、これだけ削除する）
# gpart delete -i 1 da0
da0p1 deleted
必要であれば、もう一度 GPT の情報を取得する。
# gpart show da0
=> 34 1953525101 da0 GPT (932G)
34 1953525101 - free - (932G)
すべてのパーティションを削除したので、GPT エントリを削除する。
# gpart destroy da0
da0 destroyed
以上で GPT は削除できたので、あとは sysinstall でも fdisk ででもスライスを切ればよい。
もっとも、FreeBSD は 7 系より GPT にも対応している上、MBR では 2TiB までしか扱えないため、これを機に GPT に乗り換えてしまうというのも手ではある。
その場合は、gpart にてスライスを追加していくことになるため、サイズ指定をブロック数で行わざるを得ず、ちょっとわかりにくいかもしれない。
（1 ブロックは 512 バイトですので、割り算して求めて下さいな）
man gpart
and good luck!
それは、パーティションテーブルが GPT (GUID Partition Table) になっており、旧来の MBR (Master Boot Record) ではない、と言うことだ。
FreeBSD の sysinstall では MBR しか扱えないため、GPT のディスクを繋ぐと、スライス操作が行えないという事態に陥る。
FreeBSD 8 系以降で GPT を扱うには、gpart コマンドを用いる。
（7 系では gpt コマンド）
ディスクを GPT から MBR にするのであれば、すべてのパーティションを削除して、GPT エントリを削除することになる。
そのためには、以下のように操作する。
（以下の操作に出てくる da0 は操作するデバイス。 /dev/ を付けてはいけない）
まず、GPT の情報を取得する。
# gpart show da0
=> 34 1953525101 da0 GPT (932G)
34 6 - free - (3.0K)
40 409600 1 efi (200M)
409640 1953115495 - free - (931G)
次に、存在するパーティションを削除する。
（ここでは、1 しかないので、これだけ削除する）
# gpart delete -i 1 da0
da0p1 deleted
必要であれば、もう一度 GPT の情報を取得する。
# gpart show da0
=> 34 1953525101 da0 GPT (932G)
34 1953525101 - free - (932G)
すべてのパーティションを削除したので、GPT エントリを削除する。
# gpart destroy da0
da0 destroyed
以上で GPT は削除できたので、あとは sysinstall でも fdisk ででもスライスを切ればよい。
もっとも、FreeBSD は 7 系より GPT にも対応している上、MBR では 2TiB までしか扱えないため、これを機に GPT に乗り換えてしまうというのも手ではある。
その場合は、gpart にてスライスを追加していくことになるため、サイズ指定をブロック数で行わざるを得ず、ちょっとわかりにくいかもしれない。
（1 ブロックは 512 バイトですので、割り算して求めて下さいな）
man gpart
and good luck!
2010/11/10
NanoBSD
覚え書きモード。
Q： できれば FreeBSD ベースで、電源をいきなりブチッと切っても大丈夫な、組み込み向け （？） の BSD はないですか？
A： NanoBSD は如何でしょう？
さて、NanoBSD ですが。
FreeBSD の配布物に含まれている、組み込み向けにカスタムした FreeBSD イメージを作るためのスクリプト群、またはその成果物のことだそうで。
スクリプトは、/usr/src/tools/tools/nanobsd/nanobsd.sh にあります。
仕組みとしては、以下のようになっている模様。
・/ は、リードオンリーでマウント
・/etc と /var は md （メモリディスク） に作成
・不揮発設定は /cfg に保存 （/etc は、起動時に /cfg を一時的にリードオンリーでマウントして自動生成）
・システムパーティションは２つある
・/cfg も１パーティションになっている （当たり前）
システムの更新は、２つあるシステムパーティションのうち、現在非アクティブな方に新しいイメージを書き込み、そこから起動。
上手く動いたら、起動したパーティションをアクティブにマークして終了。
ダメだったら、とりあえず元々起動していたパーティションから起動し直してサービスを続行させておき、イメージの作り直しを行う。
つまり、ダウンタイムは再起動の手間だけとなる上、復旧も容易。
なお、この NanoBSD をベースに使用しているプロジェクトには、以下の物などがある。
・FreeNAS
・BSD Router Project
・pfSense
NanoBSD に関する資料は、以下などを参照。
Introduction to NanoBSD
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/nanobsd/index.html
NanoBSD HowTo
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/nanobsd/howto.html
FreeBSD Doc NanoBSD （上記２つの日本語訳）
http://www.seichan.org/wiki/index.php?FreeBSD-Doc-NanoBSD
documentation:technical_docs:nanobsd （BSD Router Project の NanoBSD 情報ページ）
http://bsdrp.net/documentation/technical_docs/nanobsd
Q： できれば FreeBSD ベースで、電源をいきなりブチッと切っても大丈夫な、組み込み向け （？） の BSD はないですか？
A： NanoBSD は如何でしょう？
さて、NanoBSD ですが。
FreeBSD の配布物に含まれている、組み込み向けにカスタムした FreeBSD イメージを作るためのスクリプト群、またはその成果物のことだそうで。
スクリプトは、/usr/src/tools/tools/nanobsd/nanobsd.sh にあります。
仕組みとしては、以下のようになっている模様。
・/ は、リードオンリーでマウント
・/etc と /var は md （メモリディスク） に作成
・不揮発設定は /cfg に保存 （/etc は、起動時に /cfg を一時的にリードオンリーでマウントして自動生成）
・システムパーティションは２つある
・/cfg も１パーティションになっている （当たり前）
システムの更新は、２つあるシステムパーティションのうち、現在非アクティブな方に新しいイメージを書き込み、そこから起動。
上手く動いたら、起動したパーティションをアクティブにマークして終了。
ダメだったら、とりあえず元々起動していたパーティションから起動し直してサービスを続行させておき、イメージの作り直しを行う。
つまり、ダウンタイムは再起動の手間だけとなる上、復旧も容易。
なお、この NanoBSD をベースに使用しているプロジェクトには、以下の物などがある。
・FreeNAS
・BSD Router Project
・pfSense
NanoBSD に関する資料は、以下などを参照。
Introduction to NanoBSD
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/nanobsd/index.html
NanoBSD HowTo
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/nanobsd/howto.html
FreeBSD Doc NanoBSD （上記２つの日本語訳）
http://www.seichan.org/wiki/index.php?FreeBSD-Doc-NanoBSD
documentation:technical_docs:nanobsd （BSD Router Project の NanoBSD 情報ページ）
http://bsdrp.net/documentation/technical_docs/nanobsd
2010/11/04
IPv6 Address とプライバシー
もう、遥かに前から言われていたことですが、IPv6 では、自動設定 (Auto Configuration) で付けられたアドレスにはプライバシー上の問題がありました。
その理由は、128bits ある IPv6 Address の下 64bits は EUI-64 Address の 7bits 目を反転して作成するのですが、EUI-64 Address は、MAC Address を 24bits づつに分けた間に 0xFFFE を挿入して作るため。
つまり、Address の下 64bits を監視していれば、上位 64bits が変わろうとも （どのネットワークの下にぶら下がろうとも）、個人を特定してトレースできてしまうということ。
そんなわけで、MAC Address がわからず、作り直し可能な Address を自動生成したいね、ということに。
そのための規格が、既に存在します。
プライバシー拡張、って奴です。
"Privacy Extensions for Stateless Address Autoconfiguration in IPv6" (RFC 4941: Obsolete 3041)
なんで Stateless かって、Stateful の場合は DHCPv6 でしょうから、Local Scope の Address （下 64bits の 7bits 目が 0 の Address） を振ればいいじゃない、と言う話ですね。
DHCPv6-PD の場合は、Stateless 扱いになるんじゃないかしら。
さて、このプライバシー拡張。
Windows は、標準で対応し、有効になっているらしいです。（XP 以降）
しかし、FreeBSD とか Mac OS X では、対応はしているけれど、デフォルト無効なのよね。
そんなわけで、有効にする方法をば。
FreeBSDの場合）
これらのために、以下の sysctl 値が定義されています。
net.inet6.ip6.use_tempaddr (default: 0)
プライバシー用一時アドレスを使用するか （1 で有効）
net.inet6.ip6.prefer_tempaddr (default: 0)
プライバシー用一時アドレスを送信元アドレスとするか （1 で有効）
net.inet6.ip6.temppltime (default: 86400)
プライバシー用一時アドレスの推奨有効時間 （秒単位で指定。デフォルト１日）
net.inet6.ip6.tempvltime (default: 604800)
プライバシー用一時アドレスの最大有効時間 （秒単位で指定。デフォルト１週間）
システムが起動してから設定するなら、
# sysctl net.inet6.ip6.use_tempaddr=1
# sysctl net.inet6.ip6.prefer_tempaddr=1
とでもしてください。
ただ、再起動すると消えてしまうので、常に有効にしたい場合は /etc/sysctl.conf に記述を追加してください。
net.inet6.ip6.use_tempaddr=1
net.inet6.ip6.prefer_tempaddr=1
Mac OS X の場合）
FreeBSD と、二点を除いて変わりません。
違う点は、net.inet6.ip6.prefer_tempaddr 変数がないところと sysctl の指定方法です。
Mac OS X では、net.inet6.ip6.use_tempaddr を 1 にすれば、発信元にプライバシー用一時アドレスを使うようになります。
システムが起動してからは、以下のように設定します。
sysctl -w net.inet6.ip6.use_tempaddr=1
-w オプションが必要になります。
FreeBSD では、このオプションは単に無視されるだけなので、付けてやっても動作は変わりません。
FreeBSD 同様、再起動すると設定が消えてしまうので、常に有効にするなら /etc/sysctl.conf に記述を追加してください。
その理由は、128bits ある IPv6 Address の下 64bits は EUI-64 Address の 7bits 目を反転して作成するのですが、EUI-64 Address は、MAC Address を 24bits づつに分けた間に 0xFFFE を挿入して作るため。
つまり、Address の下 64bits を監視していれば、上位 64bits が変わろうとも （どのネットワークの下にぶら下がろうとも）、個人を特定してトレースできてしまうということ。
そんなわけで、MAC Address がわからず、作り直し可能な Address を自動生成したいね、ということに。
そのための規格が、既に存在します。
プライバシー拡張、って奴です。
"Privacy Extensions for Stateless Address Autoconfiguration in IPv6" (RFC 4941: Obsolete 3041)
なんで Stateless かって、Stateful の場合は DHCPv6 でしょうから、Local Scope の Address （下 64bits の 7bits 目が 0 の Address） を振ればいいじゃない、と言う話ですね。
DHCPv6-PD の場合は、Stateless 扱いになるんじゃないかしら。
さて、このプライバシー拡張。
Windows は、標準で対応し、有効になっているらしいです。（XP 以降）
しかし、FreeBSD とか Mac OS X では、対応はしているけれど、デフォルト無効なのよね。
そんなわけで、有効にする方法をば。
FreeBSDの場合）
これらのために、以下の sysctl 値が定義されています。
net.inet6.ip6.use_tempaddr (default: 0)
プライバシー用一時アドレスを使用するか （1 で有効）
net.inet6.ip6.prefer_tempaddr (default: 0)
プライバシー用一時アドレスを送信元アドレスとするか （1 で有効）
net.inet6.ip6.temppltime (default: 86400)
プライバシー用一時アドレスの推奨有効時間 （秒単位で指定。デフォルト１日）
net.inet6.ip6.tempvltime (default: 604800)
プライバシー用一時アドレスの最大有効時間 （秒単位で指定。デフォルト１週間）
システムが起動してから設定するなら、
# sysctl net.inet6.ip6.use_tempaddr=1
# sysctl net.inet6.ip6.prefer_tempaddr=1
とでもしてください。
ただ、再起動すると消えてしまうので、常に有効にしたい場合は /etc/sysctl.conf に記述を追加してください。
net.inet6.ip6.use_tempaddr=1
net.inet6.ip6.prefer_tempaddr=1
Mac OS X の場合）
FreeBSD と、二点を除いて変わりません。
違う点は、net.inet6.ip6.prefer_tempaddr 変数がないところと sysctl の指定方法です。
Mac OS X では、net.inet6.ip6.use_tempaddr を 1 にすれば、発信元にプライバシー用一時アドレスを使うようになります。
システムが起動してからは、以下のように設定します。
sysctl -w net.inet6.ip6.use_tempaddr=1
-w オプションが必要になります。
FreeBSD では、このオプションは単に無視されるだけなので、付けてやっても動作は変わりません。
FreeBSD 同様、再起動すると設定が消えてしまうので、常に有効にするなら /etc/sysctl.conf に記述を追加してください。
2010/08/05
PPTP 覚え書き
今現在、VPN を張るのに OpenVPN を使用しているのだけれども。
当たり前のことながら市販機器では使用できないので、別のものを考える。
VPN 接続に使われる方式は、主に２つ。
・PPTP / MPPE (RC4)
・L2TP / IPSec
他にも GRE + IPSec で LAN 間接続とかいろいろあるけれど。
さて、使用する予定のクライアントは、Windows PC と iPhone とブロードバンドルータ。
そうすると、事実上 PPTP / MPPE (RC4) しかなくなってしまうという。。。
本当は、L2TP / IPSec でやりたいところなのだけれど、これに対応しているブロードバンドルータがない （正確には、ないわけではないが、３万弱以上のお値段が張る） し、FreeBSD で IPv4 で IPSec を使用する場合、kernel 再構築が必要になってしまい、freebsd-update が使えなくなってしまうと言う面倒くささがあるので、妥協してみる。
PPTP Server には MPD を使用してみようかと思っている。
さて。
PPTP 接続の MTU, MRU, MSS はどうなるのかな、と言うのが、今回のお題。
MTU (Maximum Transmission Unit) : 最大送信ユニット
MRU (Maximum Receive Unit) : 最大受信ユニット
MSS (Maximum Segment Size) : 最大セグメントサイズ (TCP Only)
またややこしいことに、うちのネット接続は、Flet's 網なんだよね。
Flet's の MTU 推奨値は 1,454 bytes です。
これは、Flet's 網の仕様によるものだそうで。
Flet's 網を利用する場合のパケット：
LAN:
IP Header (20 bytes) + Protocol Header + Data = (max) 1,500 bytes
MTU = 1,500
Router -> NTT:
PPPoE Header (6 bytes) + PPP Header (2 bytes) + LAN Packet = (max) 1,500 bytes
MTU = 1,500 - (6 + 2) = 1,492
NTT -> ISP (BAS):
IP Header (20 bytes) + UDP Header (8 bytes) + L2TP Header (16 bytes) + PPP Header (2 bytes) + LAN Packet = (max) 1,500 bytes
MTU = 1,500 - (20 + 8 + 16 + 2) = 1,454
そんなわけで、MTU = 1,454 になるわけです。
MRU も MTU と同じで問題ないでしょう。
MSS は、MTU - 40 (IP Header 20 bytes + TCP Header 20 bytes) になります。
で、この上で PPTP をかましたらどうなるか、ということ。
PPTP のパケットは、こんな構造になっています。
PPTP Packet:
IP Header (20 bytes) + (PPTP) GRE Header (16 bytes) + PPP Header (2 bytes) + LAN Packet = (max) 1,500 bytes
ところがどっこい、これがさらにカプセル化されるわけですよ。
つまり、一番悲惨な状態は、こうなっています。
PPTP Packet on NTT -> ISP (BAS):
IP Header + UDP Header + L2TP Header + PPP Header （以上 Flet's 網でのカプセル化）
+ IP Header + GRE Header + PPP Header + LAN Packet = (max) 1,500 bytes
つまり、MTU は、1,500 - (20 + 8 + 16 + 2) - (20 + 16 + 2) = 1,454 - 38 = 1,416 となります。
MSS は 1,416 - 40 = 1,376 ですね。
当たり前のことながら市販機器では使用できないので、別のものを考える。
VPN 接続に使われる方式は、主に２つ。
・PPTP / MPPE (RC4)
・L2TP / IPSec
他にも GRE + IPSec で LAN 間接続とかいろいろあるけれど。
さて、使用する予定のクライアントは、Windows PC と iPhone とブロードバンドルータ。
そうすると、事実上 PPTP / MPPE (RC4) しかなくなってしまうという。。。
本当は、L2TP / IPSec でやりたいところなのだけれど、これに対応しているブロードバンドルータがない （正確には、ないわけではないが、３万弱以上のお値段が張る） し、FreeBSD で IPv4 で IPSec を使用する場合、kernel 再構築が必要になってしまい、freebsd-update が使えなくなってしまうと言う面倒くささがあるので、妥協してみる。
PPTP Server には MPD を使用してみようかと思っている。
さて。
PPTP 接続の MTU, MRU, MSS はどうなるのかな、と言うのが、今回のお題。
MTU (Maximum Transmission Unit) : 最大送信ユニット
MRU (Maximum Receive Unit) : 最大受信ユニット
MSS (Maximum Segment Size) : 最大セグメントサイズ (TCP Only)
またややこしいことに、うちのネット接続は、Flet's 網なんだよね。
Flet's の MTU 推奨値は 1,454 bytes です。
これは、Flet's 網の仕様によるものだそうで。
Flet's 網を利用する場合のパケット：
LAN:
IP Header (20 bytes) + Protocol Header + Data = (max) 1,500 bytes
MTU = 1,500
Router -> NTT:
PPPoE Header (6 bytes) + PPP Header (2 bytes) + LAN Packet = (max) 1,500 bytes
MTU = 1,500 - (6 + 2) = 1,492
NTT -> ISP (BAS):
IP Header (20 bytes) + UDP Header (8 bytes) + L2TP Header (16 bytes) + PPP Header (2 bytes) + LAN Packet = (max) 1,500 bytes
MTU = 1,500 - (20 + 8 + 16 + 2) = 1,454
そんなわけで、MTU = 1,454 になるわけです。
MRU も MTU と同じで問題ないでしょう。
MSS は、MTU - 40 (IP Header 20 bytes + TCP Header 20 bytes) になります。
で、この上で PPTP をかましたらどうなるか、ということ。
PPTP のパケットは、こんな構造になっています。
PPTP Packet:
IP Header (20 bytes) + (PPTP) GRE Header (16 bytes) + PPP Header (2 bytes) + LAN Packet = (max) 1,500 bytes
ところがどっこい、これがさらにカプセル化されるわけですよ。
つまり、一番悲惨な状態は、こうなっています。
PPTP Packet on NTT -> ISP (BAS):
IP Header + UDP Header + L2TP Header + PPP Header （以上 Flet's 網でのカプセル化）
+ IP Header + GRE Header + PPP Header + LAN Packet = (max) 1,500 bytes
つまり、MTU は、1,500 - (20 + 8 + 16 + 2) - (20 + 16 + 2) = 1,454 - 38 = 1,416 となります。
MSS は 1,416 - 40 = 1,376 ですね。
2010/06/26
Postfix でバーチャルユーザを混在させる方法 （補足３）
直前のエントリの補足です。
実ドメイン運用して、fallback_transport = virtual したとします。
この設定をして、virtual ユーザにメールが送れないよー、となっちゃった方々へ。
まぁ、普通にやっただけだと、
550 User unknown in local recipient table
って言われちゃいますよねー。
＃ メールサーバにログインして、mail コマンドで送ったら大丈夫だったけれど
＃ 他の環境から送ったら、このエラーで送れなかったのです。。。
Postfix は、知らないローカル受信者宛のメールを自動で拒否してしまうのでした。
つまり、fallback_transport を指定している場合、これで処理されるユーザを教えてあげなければなりません。
その問題と解決策が、マニュアル文書に書いてあります。
Postfix で知らないローカルユーザを拒否する
http://www.postfix-jp.info/trans-2.3/jhtml/LOCAL_RECIPIENT_README.html
---
main.cf の local_recipient_maps 設定を変更する必要がある場合
問題: 非 UNIX アカウントにメールを配送するために Postfix local(8) 配送エージェントの mailbox_transport または fallback_transport 機能を使っています。
解決策: 非 UNIX ユーザをリストアップしたデータベースを追加する必要が あります:
/etc/postfix/main.cf
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps,
<the database with non-UNIX accounts>
テーブルの作り方に関する記述は、以下の "ローカル受信者テーブルのフォーマット" の セクションを参照してください。
---
というわけで、local_recipient_maps の設定が必要なわけです。
ここにデータベースを追加するわけですが、実ドメインのバーチャルメールボックスユーザは、virtual_mailbox_maps に指定したデータベースに書いていたわけです。
なので、このデータベースを指定すれば OK です。
main.cf:
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps, $virtual_mailbox_maps
この設定で、無事、バーチャルユーザが弾かれることなく、メールが届くようになります。
付属ドキュメントは、ちゃんと読みましょう・・・ ＞ σ(__;
■ バーチャルユーザ混在、まとめ （ただし、実ドメインとしての運用の場合のみ）
実ユーザとバーチャルユーザを混在させる場合、以下のような設定を行う。
実ドメインとして運用する場合、ローカルにユーザが存在しない場合、fallback_transport を使用し、virtual に fallback するように設定する。
ただし、550 User unknown in local recipient table のエラーで弾かれないように、local_recipient_maps にてバーチャルユーザデータベースを指定する。
あとは、virtual mailboxと同じように設定すればよい。
main.cf:
mydestination = example.net, ...
fallback_transport = virtual:
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps, $virtual_mailbox_maps
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
vmailbox:
vusr@example.net example.net/vusr/
実ドメイン運用して、fallback_transport = virtual したとします。
この設定をして、virtual ユーザにメールが送れないよー、となっちゃった方々へ。
まぁ、普通にやっただけだと、
550 User unknown in local recipient table
って言われちゃいますよねー。
＃ メールサーバにログインして、mail コマンドで送ったら大丈夫だったけれど
＃ 他の環境から送ったら、このエラーで送れなかったのです。。。
Postfix は、知らないローカル受信者宛のメールを自動で拒否してしまうのでした。
つまり、fallback_transport を指定している場合、これで処理されるユーザを教えてあげなければなりません。
その問題と解決策が、マニュアル文書に書いてあります。
Postfix で知らないローカルユーザを拒否する
http://www.postfix-jp.info/trans-2.3/jhtml/LOCAL_RECIPIENT_README.html
---
main.cf の local_recipient_maps 設定を変更する必要がある場合
問題: 非 UNIX アカウントにメールを配送するために Postfix local(8) 配送エージェントの mailbox_transport または fallback_transport 機能を使っています。
解決策: 非 UNIX ユーザをリストアップしたデータベースを追加する必要が あります:
/etc/postfix/main.cf
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps,
<the database with non-UNIX accounts>
テーブルの作り方に関する記述は、以下の "ローカル受信者テーブルのフォーマット" の セクションを参照してください。
---
というわけで、local_recipient_maps の設定が必要なわけです。
ここにデータベースを追加するわけですが、実ドメインのバーチャルメールボックスユーザは、virtual_mailbox_maps に指定したデータベースに書いていたわけです。
なので、このデータベースを指定すれば OK です。
main.cf:
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps, $virtual_mailbox_maps
この設定で、無事、バーチャルユーザが弾かれることなく、メールが届くようになります。
付属ドキュメントは、ちゃんと読みましょう・・・ ＞ σ(__;
■ バーチャルユーザ混在、まとめ （ただし、実ドメインとしての運用の場合のみ）
実ユーザとバーチャルユーザを混在させる場合、以下のような設定を行う。
実ドメインとして運用する場合、ローカルにユーザが存在しない場合、fallback_transport を使用し、virtual に fallback するように設定する。
ただし、550 User unknown in local recipient table のエラーで弾かれないように、local_recipient_maps にてバーチャルユーザデータベースを指定する。
あとは、virtual mailboxと同じように設定すればよい。
main.cf:
mydestination = example.net, ...
fallback_transport = virtual:
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps, $virtual_mailbox_maps
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
vmailbox:
vusr@example.net example.net/vusr/
2010/06/24
Postfix でバーチャルユーザを混在させる方法 （補足２）
直前のエントリの補足です。
結局、実ドメインとして運用するようにしてみました。
たぶん、この方が楽だと思うので。
実ドメインとして運用すると、当該ドメイン宛のメールの配送には、local(8) エージェントが使われます。
local(8) は、aliases データベースと UNIX パスワードデータベースを検索し、ローカルにユーザが存在する場合は、そのままローカル配送します。
肝になるのは、ローカルにユーザが存在しない場合です。
この場合、local(8) が頑張って探してもユーザが見つからなかった場合、fallback_transport_maps の指定、なければ、fallback_transport の指定に従って配送してくれます。
このパラメータを設定することにします。
今回は、バーチャルメールボックスユーザとするため、virtual(8) で配送してもらいます。
そのため、fallback_transport パラメータを設定しました。
main.cf:
fallback_transport = virtual:
これで、あとは、
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
この辺の指定に従って、配送してくれます。
バーチャルメールボックスドメインとして運用する場合は、たぶん、これと逆のことをやればいいはずです。
つまり、何よりも早く配送方法を指定できるように、transport_maps パラメータを設定し、ローカルユーザ宛の配送方法を決定すればいいでしょう。
main.cf:
transport_maps = hash:/usr/local/etc/postfix/transport
transport:
luser@example.net local:$myhostname
・・・
と言った形になります。
virtual(8) で配送させると、aliases データベースも検索してくれないし、.forward 等の処理もできないんだよなぁ。。。
利用したかったら、力業しかないのかなぁ。。。
結局、実ドメインとして運用するようにしてみました。
たぶん、この方が楽だと思うので。
実ドメインとして運用すると、当該ドメイン宛のメールの配送には、local(8) エージェントが使われます。
local(8) は、aliases データベースと UNIX パスワードデータベースを検索し、ローカルにユーザが存在する場合は、そのままローカル配送します。
肝になるのは、ローカルにユーザが存在しない場合です。
この場合、local(8) が頑張って探してもユーザが見つからなかった場合、fallback_transport_maps の指定、なければ、fallback_transport の指定に従って配送してくれます。
このパラメータを設定することにします。
今回は、バーチャルメールボックスユーザとするため、virtual(8) で配送してもらいます。
そのため、fallback_transport パラメータを設定しました。
main.cf:
fallback_transport = virtual:
これで、あとは、
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
この辺の指定に従って、配送してくれます。
バーチャルメールボックスドメインとして運用する場合は、たぶん、これと逆のことをやればいいはずです。
つまり、何よりも早く配送方法を指定できるように、transport_maps パラメータを設定し、ローカルユーザ宛の配送方法を決定すればいいでしょう。
main.cf:
transport_maps = hash:/usr/local/etc/postfix/transport
transport:
luser@example.net local:$myhostname
・・・
と言った形になります。
virtual(8) で配送させると、aliases データベースも検索してくれないし、.forward 等の処理もできないんだよなぁ。。。
利用したかったら、力業しかないのかなぁ。。。
Postfix でバーチャルユーザを混在させる方法 （補足）
直前のエントリの補足です。
■ ドメインを実ドメインとして運用する場合
転送用に指定するバーチャルメールボックスドメインは、名前解決できなければなりません。
ですので、DNS に登録するなど、工夫が必要となるでしょう。
■ ドメインをバーチャルメールボックスドメインとして運用する場合
main.cf にて指定している myorigin パラメータが、mydestination パラメータに指定されていることが要求されます。
しかしながら、myorigin = $mydomain として、virtual_mailbox_domains = $mydomain, ... としてしまった場合、ローカルユーザに配送するには、virtual_alias_maps で指定したファイルにて、以下のように指定します。
virtual:
luser@example.net luser@localhost
このように、強制的にローカルを指定して配送させます。
しかしながら。。。
この方法でローカルユーザにマップすると、ローカルのユーザに届くメールのヘッダには、
Delivered-To: luser@localhost.example.net
X-Original-To: luser@localhost.example.net
と記録されてしまって、とても哀しいことに。。。
対策を模索中です。
*_transport_maps の指定で、どうにかできそうな予感。。。
■ ドメインを実ドメインとして運用する場合
転送用に指定するバーチャルメールボックスドメインは、名前解決できなければなりません。
ですので、DNS に登録するなど、工夫が必要となるでしょう。
■ ドメインをバーチャルメールボックスドメインとして運用する場合
main.cf にて指定している myorigin パラメータが、mydestination パラメータに指定されていることが要求されます。
しかしながら、myorigin = $mydomain として、virtual_mailbox_domains = $mydomain, ... としてしまった場合、ローカルユーザに配送するには、virtual_alias_maps で指定したファイルにて、以下のように指定します。
virtual:
luser@example.net luser@localhost
このように、強制的にローカルを指定して配送させます。
しかしながら。。。
この方法でローカルユーザにマップすると、ローカルのユーザに届くメールのヘッダには、
Delivered-To: luser@localhost.example.net
X-Original-To: luser@localhost.example.net
と記録されてしまって、とても哀しいことに。。。
対策を模索中です。
*_transport_maps の指定で、どうにかできそうな予感。。。
2010/06/23
Postfix でバーチャルユーザを混在させる方法
タイトルだけだと、よくわからないかもしれませんね。。。
Postfix であるドメインを運用するときに、
一部のユーザは、システムにアカウントを持つ実ユーザ (UNIX アカウント持ちユーザ)
他のユーザは、システムアカウントを持たないユーザ (バーチャルユーザ)
とする方法です。
方法は、二つほどあるようです。
■ 実ドメインとして運用する場合
運用ドメインを、実ドメイン （基本的にローカルにユーザを作成してそこに配送させるドメイン） として運用する場合の方法です。
具体的な作戦は、以下の通りです。
・運用ドメインは、実ドメインとして設定
・バーチャルメールボックス用のドメインを用意
・バーチャルユーザとしたいメールアドレスは、バーチャルメールボックスドメインへ転送するように設定
main.cf にて、運用ドメインを、mydestination パラメータに設定します。
main.cf:
mydestination = example.net, ...
そして、バーチャルユーザ用に、バーチャル用ドメインをバーチャルメールボックスドメインとして設定します。
main.cf:
virtual_mailbox_domains = example.net.vmbox, ...
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
そして、バーチャルユーザは、バーチャルメールボックスドメインへ転送するように設定します。
virtual:
vusr@example.net vusr@example.net.vmbox
最後に、バーチャルメールボックス用の配送先を設定します。
vmailbox:
vusr@example.net.vmbox example.net.vmbox/vusr/
■ バーチャルメールボックスドメインとして運用する場合
運用ドメインを、バーチャルメールボックスドメイン （ローカルにはユーザを作らずバーチャルメールボックスに配送するドメイン） として運用する場合の方法です。
具体的な作戦は、以下の通りです。
・運用ドメインは、バーチャルメールボックスドメインとして設定
・ローカルユーザとしたいメールアドレスは、ローカルユーザに転送するように設定
main.cf にて、運用ドメインを、virtual_mailbox_domains パラメータに設定します。
main.cf:
virtual_mailbox_domains = example.net, ...
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
そして、ローカルユーザは、ローカルユーザに転送するように設定します。
virtual:
lusr@example.net lusr
Postfix のマニュアル的には、バーチャルメールボックスドメインとして運用して、ローカルユーザへ転送する方法を推奨しているようです。
Postfix であるドメインを運用するときに、
一部のユーザは、システムにアカウントを持つ実ユーザ (UNIX アカウント持ちユーザ)
他のユーザは、システムアカウントを持たないユーザ (バーチャルユーザ)
とする方法です。
方法は、二つほどあるようです。
■ 実ドメインとして運用する場合
運用ドメインを、実ドメイン （基本的にローカルにユーザを作成してそこに配送させるドメイン） として運用する場合の方法です。
具体的な作戦は、以下の通りです。
・運用ドメインは、実ドメインとして設定
・バーチャルメールボックス用のドメインを用意
・バーチャルユーザとしたいメールアドレスは、バーチャルメールボックスドメインへ転送するように設定
main.cf にて、運用ドメインを、mydestination パラメータに設定します。
main.cf:
mydestination = example.net, ...
そして、バーチャルユーザ用に、バーチャル用ドメインをバーチャルメールボックスドメインとして設定します。
main.cf:
virtual_mailbox_domains = example.net.vmbox, ...
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
そして、バーチャルユーザは、バーチャルメールボックスドメインへ転送するように設定します。
virtual:
vusr@example.net vusr@example.net.vmbox
最後に、バーチャルメールボックス用の配送先を設定します。
vmailbox:
vusr@example.net.vmbox example.net.vmbox/vusr/
■ バーチャルメールボックスドメインとして運用する場合
運用ドメインを、バーチャルメールボックスドメイン （ローカルにはユーザを作らずバーチャルメールボックスに配送するドメイン） として運用する場合の方法です。
具体的な作戦は、以下の通りです。
・運用ドメインは、バーチャルメールボックスドメインとして設定
・ローカルユーザとしたいメールアドレスは、ローカルユーザに転送するように設定
main.cf にて、運用ドメインを、virtual_mailbox_domains パラメータに設定します。
main.cf:
virtual_mailbox_domains = example.net, ...
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
そして、ローカルユーザは、ローカルユーザに転送するように設定します。
virtual:
lusr@example.net lusr
Postfix のマニュアル的には、バーチャルメールボックスドメインとして運用して、ローカルユーザへ転送する方法を推奨しているようです。
登録:
投稿 (Atom)