覚え書きモード。
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 のマニュアル的には、バーチャルメールボックスドメインとして運用して、ローカルユーザへ転送する方法を推奨しているようです。
2010/05/09
BIND の設定あれこれ
一年近く放置していた File Server たち。
FreeBSD 7.2-RELEASE-p3 から、FreeBSD 8.0-RELEASE-p2 まで、一気に上げたのでした。
ちなみに、Gateway Server は、7.2-RELEASE-p2 だったりしたのでした （汗
さて。
昔から頭を悩ませてきた BIND の問題。
少し解決したので、そのことを。
■ 起動時に、
named[749]: the working directory is not writable
と叫ぶ。
□ 気にするこっちゃない！
named.conf で指定する directory のことですけれど。
普通は、/etc/namedb あたりが指定されていますよね。
このディレクトリの owner が root:wheel にされていて、bind が書けないから叫んでいるこの警告。
"programmer inflected useless warnings" （プログラマの屈折した役に立たない警告） だそうで、「書けなかったからって、それが何か？」 と言うスタンスでいいそうです。
＃ つまり、この警告は無視してよい
何回、手で owner を書き換えても root に戻されちゃうのは、BIND の起動時に、/etc/mtree/BIND.chroot.dist の指定で設定されるからです。
この機能を抑制するには、/etc/rc.conf に named_chroot_autoupdate="NO" を指定します。
んが。
セキュリティ上の理由でこの設定が採用されているので、こんなことはしない方がよいでしょう。
ましてや、/etc/mtree/BIND/chroot.dist を書き換えるなんて、以ての外です。
どーしても！ この警告を消したい方は、以下の対策をします。
１．working directory として、/etc/namedb/letskeepthisdirwritable を指定
２．/etc/namedb/letskeepthisdirwritable の owner を bind:bind にし、permission は 0755 に
３．named.conf の中のファイル指定を、全部相対パスに変更
ex) named.root -> ../named.root, master/empty.db -> ../master/empty.db
これで、この警告を消し去ることができます。
まぁ、面倒くさいので、この警告は無視した方がよいでしょうね。。。
■ Dynamic DNS を利用していると、
named[749]: dumping master file: master/tmp-hb9UYKWNAy: open: permission denied
などと叫ぶ。
□ Dynamic DNS の使い方が間違っている
間違っても、master/ ディレクトリの owner を変えたり、permission を変えたりしないように。
master/ ディレクトリの owner, permission は、やっぱり起動時に /etc/mtree/BIND.chroot.dist の指定で設定し直されます。
これも、やはりセキュリティ上の理由からです。
master server の設定は、外部から変更されないべきであるため、この設定となっています。
Dynamic DNS を使うときは、dynamic/ ディレクトリを使います。
つまり、こんな指定になります。
zone "example.org" {
type master;
allow-update {
key "exampleorgkey";
};
file "../dynamic/example.org";
};
■ Dynamic DNS を利用していると、
named[29217]: zone 'hogehoge' allows updates by IP address, which is insecure
などと叫ぶ。
□ なるべく TSIG (Transaction Signature) を使いましょうね
Dynamic DNS の update が可能な端末を IP Address だけで指定していると、こう言われます。
より secure に、TSIG を使って認証しなさい、と言う警告です。
TSIG が使えない環境の場合は、諦めるしかありませんねぇ。。。
クライアントが対応していないだけなら、DHCP server に DDNS 更新を依頼するといいかもしれません。
FreeBSD 7.2-RELEASE-p3 から、FreeBSD 8.0-RELEASE-p2 まで、一気に上げたのでした。
ちなみに、Gateway Server は、7.2-RELEASE-p2 だったりしたのでした （汗
さて。
昔から頭を悩ませてきた BIND の問題。
少し解決したので、そのことを。
■ 起動時に、
named[749]: the working directory is not writable
と叫ぶ。
□ 気にするこっちゃない！
named.conf で指定する directory のことですけれど。
普通は、/etc/namedb あたりが指定されていますよね。
このディレクトリの owner が root:wheel にされていて、bind が書けないから叫んでいるこの警告。
"programmer inflected useless warnings" （プログラマの屈折した役に立たない警告） だそうで、「書けなかったからって、それが何か？」 と言うスタンスでいいそうです。
＃ つまり、この警告は無視してよい
何回、手で owner を書き換えても root に戻されちゃうのは、BIND の起動時に、/etc/mtree/BIND.chroot.dist の指定で設定されるからです。
この機能を抑制するには、/etc/rc.conf に named_chroot_autoupdate="NO" を指定します。
んが。
セキュリティ上の理由でこの設定が採用されているので、こんなことはしない方がよいでしょう。
ましてや、/etc/mtree/BIND/chroot.dist を書き換えるなんて、以ての外です。
どーしても！ この警告を消したい方は、以下の対策をします。
１．working directory として、/etc/namedb/letskeepthisdirwritable を指定
２．/etc/namedb/letskeepthisdirwritable の owner を bind:bind にし、permission は 0755 に
３．named.conf の中のファイル指定を、全部相対パスに変更
ex) named.root -> ../named.root, master/empty.db -> ../master/empty.db
これで、この警告を消し去ることができます。
まぁ、面倒くさいので、この警告は無視した方がよいでしょうね。。。
■ Dynamic DNS を利用していると、
named[749]: dumping master file: master/tmp-hb9UYKWNAy: open: permission denied
などと叫ぶ。
□ Dynamic DNS の使い方が間違っている
間違っても、master/ ディレクトリの owner を変えたり、permission を変えたりしないように。
master/ ディレクトリの owner, permission は、やっぱり起動時に /etc/mtree/BIND.chroot.dist の指定で設定し直されます。
これも、やはりセキュリティ上の理由からです。
master server の設定は、外部から変更されないべきであるため、この設定となっています。
Dynamic DNS を使うときは、dynamic/ ディレクトリを使います。
つまり、こんな指定になります。
zone "example.org" {
type master;
allow-update {
key "exampleorgkey";
};
file "../dynamic/example.org";
};
■ Dynamic DNS を利用していると、
named[29217]: zone 'hogehoge' allows updates by IP address, which is insecure
などと叫ぶ。
□ なるべく TSIG (Transaction Signature) を使いましょうね
Dynamic DNS の update が可能な端末を IP Address だけで指定していると、こう言われます。
より secure に、TSIG を使って認証しなさい、と言う警告です。
TSIG が使えない環境の場合は、諦めるしかありませんねぇ。。。
クライアントが対応していないだけなら、DHCP server に DDNS 更新を依頼するといいかもしれません。
2010/02/10
WireShark on Mac OS X Snow Leopard
半年ほどサボっていました （＾＾；
ネタはあったんですけれども。
その間に、Mac mini を購入して、Mac ユーザになっていました。
さて、WireShark を入れたときにはまったので、記録。
WireShark のページや解説には、一通りの手順は載っています。
WireShark.app を適当なところ （たいていは、Applications フォルダ） に D&D します。
そして、Utilities フォルダの内容を、パスの通った場所にコピーします。
/user/local/bin とか、~/bin とか、/opt/wireshark/bin とか。
検索すると、みなさん /usr/local/bin に入れているみたいですが、Sun Microsystems の提唱に従って、/opt/wireshark/bin に入れてみました。
最後に、ChmodBPF フォルダを StartupItems にコピーしなきゃいけないんですが、ここで一つ躓きが。
再起動すると、「ChmodBPF のセキュリティ設定が不適切なため、起動しませんでした」 と表示されました。
どうやら、Leopard までならば、「セキュリティ設定を修正する」 という項目があるんですが、Snow Leopard には OK という項目があるのみ。
どうやって修正しましょうか、と悩みました。
他の項目などを見てみると、どうやら、owner を root:wheel にしないといけないようです。
chown してから再起動すると、問題なく起動しました。
Mac OS X の /Library/StartupItems/ の中身は、owner が root:wheel じゃないとだめらしい。
ということで。
ネタはあったんですけれども。
その間に、Mac mini を購入して、Mac ユーザになっていました。
さて、WireShark を入れたときにはまったので、記録。
WireShark のページや解説には、一通りの手順は載っています。
WireShark.app を適当なところ （たいていは、Applications フォルダ） に D&D します。
そして、Utilities フォルダの内容を、パスの通った場所にコピーします。
/user/local/bin とか、~/bin とか、/opt/wireshark/bin とか。
検索すると、みなさん /usr/local/bin に入れているみたいですが、Sun Microsystems の提唱に従って、/opt/wireshark/bin に入れてみました。
最後に、ChmodBPF フォルダを StartupItems にコピーしなきゃいけないんですが、ここで一つ躓きが。
再起動すると、「ChmodBPF のセキュリティ設定が不適切なため、起動しませんでした」 と表示されました。
どうやら、Leopard までならば、「セキュリティ設定を修正する」 という項目があるんですが、Snow Leopard には OK という項目があるのみ。
どうやって修正しましょうか、と悩みました。
他の項目などを見てみると、どうやら、owner を root:wheel にしないといけないようです。
chown してから再起動すると、問題なく起動しました。
Mac OS X の /Library/StartupItems/ の中身は、owner が root:wheel じゃないとだめらしい。
ということで。
登録:
投稿 (Atom)