連投になりますが。。。
NTP サーバのアクセス制御設定について、ちょっとハマったので記録など。
FreeBSD 11.0-RELEASE-p1 に、昔 (FreeBSD 8.4) 使用していた ntp.conf をそのまま使ったら、ntpq -p コマンドがタイムアウトしたのでした。。。
さて、なにがいけなかったんでしょうか、と言う話です。
まぁ、結論から言うと、IPv6 の設定をしていなかったから、と言うことだったりします。
普通に rc.conf で ntpd_enable="YES" すると IPv6 でも listen するようで、自ホストからの ntpq 等は 127.0.0.1 ではなく ::1 から問い合わせているようです。
IPv4 の設定しかされていない ntp.conf では ::1 のアクセス許可が無いためにアクセスできなかった、と、そういうわけだったようで。
そんなわけでちょっと調べると、いろいろと情報がありました。
いつの間にやら、色々と新しい機能が追加されていますね。
問題は、マニュアルページに反映されていない事だったりしますが。。。（´д｀；
FreeBSD 特有の話も含めてですが、昔とは変わったところをつらつらと。
・driftfile の指定は必要ない
/etc/defaults/rc.conf を見れば分かるが、ntpd_flags の指定の中で -f /var/db/ntpd.drift されている
・DNS ラウンドロビン等で複数の IP Address を持つサーバの指定には pool を使う
server の指定には FQDN を使用しなければならないため、複数のアドレスを持つサーバの指定は難しかった（同じものを３行書くとかの手法があった）が、最近の ntpd は pool 指定に変えれば大丈夫
・同期 NTP サーバの指定には "source" というディレクティブが使える
昔は、複数のアドレスを持つサーバへのアクセス制御等には、IP Address を全部並べる必要があったが、最近なら "source" と書けば良いため、非常に楽ちん
（マニュアルにはチラッとしか書かれていない）
・FQDN の記載で IPv6 を指定するには -6 を、IPv4 なら -4 を記述する
DNS での名前解決で IPv4/IPv6 を強制する必要がある場合に指定する模様
（昔のマニュアルページ読んだら、8.4-RELEASE でも対応してましたね (^^;）
と言うことで、最近だとこんな ntp.conf を書けば良いらしいです。
---
pool 0.freebsd.pool.ntp.org iburst preempt
pool 1.freebsd.pool.ntp.org iburst preempt
pool 2.freebsd.pool.ntp.org iburst preempt
pool 3.freebsd.pool.ntp.org iburst preempt
restrict default ignore
restrict source nomodify noquery notrap
restrict 127.0.0.1
restrict ::1
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
---
昔の人なので、IPv6 は忘れがち (^^;
2017/05/01
マシンが遅いと思ったら。。。
未だにお亡くなりになったサーバの再構築が終わりません。。。orz
さておき。
新しい PC を組んでセットアップしているわけですが、何故か死ぬほど遅かったわけです。
具体的には、数秒に１回くらいのプチフリーズ的なものが発生する感じでした。
元のマシンとは比べものにならないくらい遅かったわけですが、元のマシンが Atom 330 で、新しいマシンが Pentium J4205 なので、元より遅いとかそりゃないよ、ってなもんでした。
色々調べた結果分かった事は、UEFI の設定で、省電力機能が有効になっていた事が原因だったと言うことでした。（なんてこったい！）
CPU C States Support と言う項目で C6, C1, Disabled が選べるところ、デフォルトは C6 です。
（この項目が Disabled 以外になっていれば、C1E の有効／無効も別項目で選べます）
この設定が Disabled 以外で有る限り（C1E の有効／無効に関係なく）、激遅になっていたのでした。。。
そうですか、省電力設定はダメですか。。。
そんなわけで、CPU C States Support を Disabled にしたところ、見事にサクサク動くようになったのでした。
それまで起動に数分掛かっていたところが、わずか数秒で起動するスピード差ですよ、奥さん！（違いすぎだろ。。。）
教訓： 意味不明の遅さの時は、（UEFI も含めて）省電力設定を見直せ
さておき。
新しい PC を組んでセットアップしているわけですが、何故か死ぬほど遅かったわけです。
具体的には、数秒に１回くらいのプチフリーズ的なものが発生する感じでした。
元のマシンとは比べものにならないくらい遅かったわけですが、元のマシンが Atom 330 で、新しいマシンが Pentium J4205 なので、元より遅いとかそりゃないよ、ってなもんでした。
色々調べた結果分かった事は、UEFI の設定で、省電力機能が有効になっていた事が原因だったと言うことでした。（なんてこったい！）
CPU C States Support と言う項目で C6, C1, Disabled が選べるところ、デフォルトは C6 です。
（この項目が Disabled 以外になっていれば、C1E の有効／無効も別項目で選べます）
この設定が Disabled 以外で有る限り（C1E の有効／無効に関係なく）、激遅になっていたのでした。。。
そうですか、省電力設定はダメですか。。。
そんなわけで、CPU C States Support を Disabled にしたところ、見事にサクサク動くようになったのでした。
それまで起動に数分掛かっていたところが、わずか数秒で起動するスピード差ですよ、奥さん！（違いすぎだろ。。。）
教訓： 意味不明の遅さの時は、（UEFI も含めて）省電力設定を見直せ
2017/04/23
FreeBSD を SSD にインストールする
もう何年も更新をサボっておりました。。。orz
（６年近く経っとるやんけ）
さて、長年使っていた File Server がお亡くなりになりましたので、新しいマシンでも組んでみましょうかねぇ、と思ったのでありました。
そんなわけで、システムドライブを SSD にして FreeBSD 11.0-Release-p1 をインストールしてみました。
システムドライブに SSD を使用する場合、いくつか考慮が必要になります。
それは、以下の点です。
・SSD が TRIM コマンドをサポートしているなら、有効にすべき
・FreeBSD では TRIM コマンドは UFS でしかサポートされていない
・swap で TRIM を有効にしたいなら、UFS 上にファイルで作成すべき
・各パーティションは 1 MB 境界に整列しておいた方が無難
（128 KB 整列でもいいような気はしないでもない）
他に、現在では UEFI なシステムが普通だったりもするので、ここは素直に GPT (GUID Partition Table) を使用しましょうか、とか色々あるわけです。
実際に、どんな形を目指すのかというと、以下のような形にすることを考えます。
・Partition Scheme には GPT を使用
・BIOS のシステムに繋いでも大丈夫なように boot パーティションを作成
・UEFI のシステムから起動できるように efi (EFI System Partition) パーティションを作成
・swap は UFS 上のファイルとする為、swap パーティションは作成しない
・/tmp には tmpfs を使用する為、tmp パーティションは作成しない
・デバイス番号が変化しても問題ない様、GPT パーティションにはラベルを付加
・boot パーティション (freebsd-boot) は 40 Block (20 KB) から始まり、サイズは 512 KB
・efi パーティションは 1 MB (2048 Block) から始まり、サイズは 200 MB
・他の各パーティションは 1 MB 境界に整列する
・バックアップに dump -L を使用できるよう、Soft-Updates Journaling (SUJ) は使用しない
考慮するポイントが色々ある所為で、インストーラの Auto (UFS) や Manual でパーティショニングするのには無理があったりします。
そのため、Partitioning の項では Shell を選びます。
Shell を選んだ場合は、以下の点に注意が必要です。
・Shell を抜ける前に、作成したパーティションを /mnt 以下にマウントしておくこと
・新システム用の fstab の内容を /tmp/bsdinstall_etc/fstab に記入しておくこと
さて、パーティショニングしてみましょう。
使い回しの SSD を使用する場合は、各パーティションとスキームを削除して下さい。
認識されているディスクのパーティション情報を表示
# gpart show
各パーティションを削除
# gpart delete -i {partition#} {device id}
ex.) gpart delete -i 1 ada0
スキームを削除
# gpart destroy {device id}
ex.) gpart destroy ada0
以下のようにパーティショニングを実行します。
GPT を Scheme として使用する
# gpart create -s GPT {device id}
ex.) gpart create -s GPT ada0
以下、device id が ada0 だったものとして記述します。
boot パーティションを作成し、ブートコードを書き込む
# gpart add -t freebsd-boot -l gpboot -b 40 -s 512k ada0
# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0
（gpart add の -l オプションは、パーティションラベルの指定です）
（gpart bootcode の -b はディスクに書き込まれるブートコードです）
（gpart bootcode の -p はパーティションに書き込まれるブートコードです）
efi パーティションを作成し、起動用 EFI Application ファイルを格納する
# gpart add -t efi -l gpefiboot -b 1m -s 200m ada0
# newfs_msdos /dev/ada0p2
# mount -t msdosfs /dev/ada0p2 /mnt
# mkdir -p /mnt/EFI/BOOT
# cp -p /boot/boot1.efi /mnt/EFI/BOOT/BOOTx64.EFI
# umount /mnt
（efi パーティションは FAT/FAT32 でフォーマットされている必要があります）
（efi パーティションのサイズは 100MB 以上 1GB 以下である必要があります）
（起動用 EFI Application のデフォルトは /EFI/BOOT/BOOT{マシンタイプ}.EFI です）
（amd64 に対応するマシンタイプは x64 です）
（FreeBSD/i386 は現在非対応です（マシンタイプは IA32 です））
各パーティションを 1 MB 境界で作成し、Soft-Updates と TRIM を有効にする
# gpart add -t freebsd-ufs -l gprootfs -a 1m -s 40g ada0
# gpart add -t freebsd-ufs -l gpvarfs -a 1m -s 20g ada0
# gpart add -t freebsd-ufs -l gpusrfs -a 1m ada0
# newfs -U -t /dev/gpt/gprootfs
# newfs -U -t /dev/gpt/gpvarfs
# newfs -U -t /dev/gpt/gpusrfs
（SUJ には snapshot が取れない問題があり dump -L できないため無効とする）
（dump -L すると Snapshots are not yet supported when running with journaled soft updates: Operation not supported と言われる）
各パーティションをマウントし、swap ファイルを作成する
# mount /dev/gpt/gprootfs /mnt
# mkdir /mnt/swap /mnt/var /mnt/usr
# mount /dev/gpt/gpvarfs /mnt/var
# mount /dev/gpt/gpusrfs /mnt/usr
# dd if=/dev/zero of=/mnt/swap/swapfile bs=128k count=131072
（swap ファイルのサイズは 16 GB（メモリサイズ以上））
fstab を作成する
（echo で追記していますが、vi 等も使用可能です）
# echo "# Device Mountpoint FStype Options Dump Pass#" > /tmp/bsdinstall_etc/fstab
# echo "/dev/gpt/gprootfs / ufs rw 1 1" >> /tmp/bsdinstall_etc/fstab
# echo "md99 none swap sw,file=/swap/swapfile,late 0 0" >> /tmp/bsdinstall_etc/fstab
# echo "/dev/gpt/gpvarfs /var ufs rw 2 2" >> /tmp/bsdinstall_etc/fstab
# echo "tmpfs /tmp tmpfs rw,size=8g,mode=01777 0 0" >> /tmp/bsdinstall_etc/fstab
# echo "/dev/gpt/gpusrfs /usr ufs rw 2 2" >> /tmp/bsdinstall_etc/fstab
Shell を終了する
# exit
こんな感じです。
これで作成したパーティション情報を表示すると、以下のようになります。
# gpart show
=> 40 234441568 ada0 GPT (112G)
40 1024 1 freebsd-boot (512K)
1064 984 - free - (492K)
2048 409600 2 efi (200M)
411648 83886080 3 freebsd-ufs (40G)
84297728 41943040 4 freebsd-ufs (20G)
126240768 108199936 5 freebsd-ufs (52G)
234440704 904 - free - (452K)
# gpart show -l
=> 40 234441568 ada0 GPT (112G)
40 1024 1 gpboot (512K)
1064 984 - free - (492K)
2048 409600 2 gpefiboot (200M)
411648 83886080 3 gprootfs (40G)
84297728 41943040 4 gpvarfs (20G)
126240768 108199936 5 gpusrfs (52G)
234440704 904 - free - (452K)
freebsd-boot パーティションの後に 492 KB の free エリアができてしまいますが、そう言うものだと思って諦めて下さい。
今や最初のパーティションを 1 MB の位置から始めるのは普通になりました。
Windows では freebsd-boot パーティションがない分、1 MB 弱が空きになっていると思えば、まだ諦めが付くでしょうか。。。(^^;
まだ SSD をシステムドライブにするには若干面倒な感じがしますが、そのうちインストーラでも簡単にできるようになるでしょう。
それまでは、パーティショニングは Shell で行う必要がありますね。
（６年近く経っとるやんけ）
さて、長年使っていた File Server がお亡くなりになりましたので、新しいマシンでも組んでみましょうかねぇ、と思ったのでありました。
そんなわけで、システムドライブを SSD にして FreeBSD 11.0-Release-p1 をインストールしてみました。
システムドライブに SSD を使用する場合、いくつか考慮が必要になります。
それは、以下の点です。
・SSD が TRIM コマンドをサポートしているなら、有効にすべき
・FreeBSD では TRIM コマンドは UFS でしかサポートされていない
・swap で TRIM を有効にしたいなら、UFS 上にファイルで作成すべき
・各パーティションは 1 MB 境界に整列しておいた方が無難
（128 KB 整列でもいいような気はしないでもない）
他に、現在では UEFI なシステムが普通だったりもするので、ここは素直に GPT (GUID Partition Table) を使用しましょうか、とか色々あるわけです。
実際に、どんな形を目指すのかというと、以下のような形にすることを考えます。
・Partition Scheme には GPT を使用
・BIOS のシステムに繋いでも大丈夫なように boot パーティションを作成
・UEFI のシステムから起動できるように efi (EFI System Partition) パーティションを作成
・swap は UFS 上のファイルとする為、swap パーティションは作成しない
・/tmp には tmpfs を使用する為、tmp パーティションは作成しない
・デバイス番号が変化しても問題ない様、GPT パーティションにはラベルを付加
・boot パーティション (freebsd-boot) は 40 Block (20 KB) から始まり、サイズは 512 KB
・efi パーティションは 1 MB (2048 Block) から始まり、サイズは 200 MB
・他の各パーティションは 1 MB 境界に整列する
・バックアップに dump -L を使用できるよう、Soft-Updates Journaling (SUJ) は使用しない
考慮するポイントが色々ある所為で、インストーラの Auto (UFS) や Manual でパーティショニングするのには無理があったりします。
そのため、Partitioning の項では Shell を選びます。
Shell を選んだ場合は、以下の点に注意が必要です。
・Shell を抜ける前に、作成したパーティションを /mnt 以下にマウントしておくこと
・新システム用の fstab の内容を /tmp/bsdinstall_etc/fstab に記入しておくこと
さて、パーティショニングしてみましょう。
使い回しの SSD を使用する場合は、各パーティションとスキームを削除して下さい。
認識されているディスクのパーティション情報を表示
# gpart show
各パーティションを削除
# gpart delete -i {partition#} {device id}
ex.) gpart delete -i 1 ada0
スキームを削除
# gpart destroy {device id}
ex.) gpart destroy ada0
以下のようにパーティショニングを実行します。
GPT を Scheme として使用する
# gpart create -s GPT {device id}
ex.) gpart create -s GPT ada0
以下、device id が ada0 だったものとして記述します。
boot パーティションを作成し、ブートコードを書き込む
# gpart add -t freebsd-boot -l gpboot -b 40 -s 512k ada0
# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0
（gpart add の -l オプションは、パーティションラベルの指定です）
（gpart bootcode の -b はディスクに書き込まれるブートコードです）
（gpart bootcode の -p はパーティションに書き込まれるブートコードです）
efi パーティションを作成し、起動用 EFI Application ファイルを格納する
# gpart add -t efi -l gpefiboot -b 1m -s 200m ada0
# newfs_msdos /dev/ada0p2
# mount -t msdosfs /dev/ada0p2 /mnt
# mkdir -p /mnt/EFI/BOOT
# cp -p /boot/boot1.efi /mnt/EFI/BOOT/BOOTx64.EFI
# umount /mnt
（efi パーティションは FAT/FAT32 でフォーマットされている必要があります）
（efi パーティションのサイズは 100MB 以上 1GB 以下である必要があります）
（起動用 EFI Application のデフォルトは /EFI/BOOT/BOOT{マシンタイプ}.EFI です）
（amd64 に対応するマシンタイプは x64 です）
（FreeBSD/i386 は現在非対応です（マシンタイプは IA32 です））
各パーティションを 1 MB 境界で作成し、Soft-Updates と TRIM を有効にする
# gpart add -t freebsd-ufs -l gprootfs -a 1m -s 40g ada0
# gpart add -t freebsd-ufs -l gpvarfs -a 1m -s 20g ada0
# gpart add -t freebsd-ufs -l gpusrfs -a 1m ada0
# newfs -U -t /dev/gpt/gprootfs
# newfs -U -t /dev/gpt/gpvarfs
# newfs -U -t /dev/gpt/gpusrfs
（SUJ には snapshot が取れない問題があり dump -L できないため無効とする）
（dump -L すると Snapshots are not yet supported when running with journaled soft updates: Operation not supported と言われる）
各パーティションをマウントし、swap ファイルを作成する
# mount /dev/gpt/gprootfs /mnt
# mkdir /mnt/swap /mnt/var /mnt/usr
# mount /dev/gpt/gpvarfs /mnt/var
# mount /dev/gpt/gpusrfs /mnt/usr
# dd if=/dev/zero of=/mnt/swap/swapfile bs=128k count=131072
（swap ファイルのサイズは 16 GB（メモリサイズ以上））
fstab を作成する
（echo で追記していますが、vi 等も使用可能です）
# echo "# Device Mountpoint FStype Options Dump Pass#" > /tmp/bsdinstall_etc/fstab
# echo "/dev/gpt/gprootfs / ufs rw 1 1" >> /tmp/bsdinstall_etc/fstab
# echo "md99 none swap sw,file=/swap/swapfile,late 0 0" >> /tmp/bsdinstall_etc/fstab
# echo "/dev/gpt/gpvarfs /var ufs rw 2 2" >> /tmp/bsdinstall_etc/fstab
# echo "tmpfs /tmp tmpfs rw,size=8g,mode=01777 0 0" >> /tmp/bsdinstall_etc/fstab
# echo "/dev/gpt/gpusrfs /usr ufs rw 2 2" >> /tmp/bsdinstall_etc/fstab
Shell を終了する
# exit
こんな感じです。
これで作成したパーティション情報を表示すると、以下のようになります。
# gpart show
=> 40 234441568 ada0 GPT (112G)
40 1024 1 freebsd-boot (512K)
1064 984 - free - (492K)
2048 409600 2 efi (200M)
411648 83886080 3 freebsd-ufs (40G)
84297728 41943040 4 freebsd-ufs (20G)
126240768 108199936 5 freebsd-ufs (52G)
234440704 904 - free - (452K)
# gpart show -l
=> 40 234441568 ada0 GPT (112G)
40 1024 1 gpboot (512K)
1064 984 - free - (492K)
2048 409600 2 gpefiboot (200M)
411648 83886080 3 gprootfs (40G)
84297728 41943040 4 gpvarfs (20G)
126240768 108199936 5 gpusrfs (52G)
234440704 904 - free - (452K)
freebsd-boot パーティションの後に 492 KB の free エリアができてしまいますが、そう言うものだと思って諦めて下さい。
今や最初のパーティションを 1 MB の位置から始めるのは普通になりました。
Windows では freebsd-boot パーティションがない分、1 MB 弱が空きになっていると思えば、まだ諦めが付くでしょうか。。。(^^;
まだ SSD をシステムドライブにするには若干面倒な感じがしますが、そのうちインストーラでも簡単にできるようになるでしょう。
それまでは、パーティショニングは Shell で行う必要がありますね。
2011/10/30
ReadyNAS
老朽化した 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 系を使用している人にとっては、楽な製品かもしれませんね。。。
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 のマニュアル的には、バーチャルメールボックスドメインとして運用して、ローカルユーザへ転送する方法を推奨しているようです。
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 じゃないとだめらしい。
ということで。
2009/09/19
VPN してみよう （その１）
VPN をしてみようと思ったのです。
実家と自宅を VPN で結ぼうと。
実家にいるときに、自宅のファイルサーバのデータが欲しくなったりするんですよ。
自宅のメインマシンのデータとか。
ついでに、モバイル使用のノートからも VPN したいわけです。
FreeBSD で VPN というと、vtun がメジャーだったりします。
が、EuroBSDCon 2008 で、カナダのトロント大学で、OpenVPN で 3 万人に VPN を提供した、と言う発表があったようです。
ざっと探した限りでは、vtun か、OpenVPN か、地道に SSH か、と言う選択肢しか見つかりませんでした。
今回の目的は、自宅のネットワークと実家のネットワークを結び、ついでにモバイルからも接続できるようにする、です。
この目的にずばり答えてくれる選択肢を検討すると、
ネットワーク同士を結ぶ、と言う時点で SSH が消え、
ノートは Windows Vista と言う時点で vtun が消え、
結局 OpenVPN しかありませんでした。
＃ ネットワーク同士は vtun で結んで、ノートからは SSH しろ、とか言わないよーに （苦笑）
そんなわけで、導入です。
グローバルIP アドレス持ってる Gateway Server に OpenVPN をインストール。
インストールするのは、security/openvpn です。
security/openvpn-devel-2.1_r19 もあるのですが、まだ Release Candidate なので、採用を見送りました。
が、クライアントになるノートの方には、2.1RC を入れます。
理由は、2.1RC じゃないと、Windows Vista に対応していないからです。
2.1RC Client からも 2.0 Server には接続できるので、これで良し。
Windows 版は、プラムシステムズ （株） が日本語化しているので、以下の場所から落とします。
http://www.openvpn.jp/
なお、OpenVPN に関する日本語情報は、二箇所にあります。
http://freescitech.net/2/ OpenVPN の日本語情報
http://freescitech.net/2/wiki/ 上記の新しい Wiki
http://www.openvpn.jp/ プラムシステムズ （株）
ほぼ同じ情報が上がってます。
Server も Client も、インストールはお気軽です。
Server は portinstall openvpn するだけ。
Client は、zip 落としてきて、インストーラ実行するだけです。
さて、設定。
まず、サーバを仕込みます。
手順通りに作業します。（Server で作業）
最初は、Server/Client key pair に署名する認証局 (CA) を作ります。
手順書を見ると、/usr/local/share/doc/openvpn/easy-rsa/vars を編集しろ、と。
ここで、鍵を生成するようです。
ディレクトリが全然嬉しくない。。。
/usr/local/etc/openvpn/easy-rsa にしろよ。。。
さて、vars ファイルでは、設定しなければならない項目があります。
鍵に埋め込む Organization 情報です。
export KEY_COUNTRY=JP
export KEY_PROVINCE=TOKYO
export KEY_CITY=ADACHI-KU
export KEY_ORG="OpenVPN-NET"
export KEY_EMAIL="admin@example.com"
実家と自宅を VPN で結ぼうと。
実家にいるときに、自宅のファイルサーバのデータが欲しくなったりするんですよ。
自宅のメインマシンのデータとか。
ついでに、モバイル使用のノートからも VPN したいわけです。
FreeBSD で VPN というと、vtun がメジャーだったりします。
が、EuroBSDCon 2008 で、カナダのトロント大学で、OpenVPN で 3 万人に VPN を提供した、と言う発表があったようです。
ざっと探した限りでは、vtun か、OpenVPN か、地道に SSH か、と言う選択肢しか見つかりませんでした。
今回の目的は、自宅のネットワークと実家のネットワークを結び、ついでにモバイルからも接続できるようにする、です。
この目的にずばり答えてくれる選択肢を検討すると、
ネットワーク同士を結ぶ、と言う時点で SSH が消え、
ノートは Windows Vista と言う時点で vtun が消え、
結局 OpenVPN しかありませんでした。
＃ ネットワーク同士は vtun で結んで、ノートからは SSH しろ、とか言わないよーに （苦笑）
そんなわけで、導入です。
グローバルIP アドレス持ってる Gateway Server に OpenVPN をインストール。
インストールするのは、security/openvpn です。
security/openvpn-devel-2.1_r19 もあるのですが、まだ Release Candidate なので、採用を見送りました。
が、クライアントになるノートの方には、2.1RC を入れます。
理由は、2.1RC じゃないと、Windows Vista に対応していないからです。
2.1RC Client からも 2.0 Server には接続できるので、これで良し。
Windows 版は、プラムシステムズ （株） が日本語化しているので、以下の場所から落とします。
http://www.openvpn.jp/
なお、OpenVPN に関する日本語情報は、二箇所にあります。
http://freescitech.net/2/ OpenVPN の日本語情報
http://freescitech.net/2/wiki/ 上記の新しい Wiki
http://www.openvpn.jp/ プラムシステムズ （株）
ほぼ同じ情報が上がってます。
Server も Client も、インストールはお気軽です。
Server は portinstall openvpn するだけ。
Client は、zip 落としてきて、インストーラ実行するだけです。
さて、設定。
まず、サーバを仕込みます。
手順通りに作業します。（Server で作業）
最初は、Server/Client key pair に署名する認証局 (CA) を作ります。
手順書を見ると、/usr/local/share/doc/openvpn/easy-rsa/vars を編集しろ、と。
ここで、鍵を生成するようです。
ディレクトリが全然嬉しくない。。。
/usr/local/etc/openvpn/easy-rsa にしろよ。。。
さて、vars ファイルでは、設定しなければならない項目があります。
鍵に埋め込む Organization 情報です。
export KEY_COUNTRY=JP
export KEY_PROVINCE=TOKYO
export KEY_CITY=ADACHI-KU
export KEY_ORG="OpenVPN-NET"
export KEY_EMAIL="admin@example.com"
とかにしておきます。（実際には、ちゃんと入れてます）
書き換えたら、実行です。
手順書には、
. ./vars
./clean-all
./build-ca
ってやれ、って書いてあります。
・・・sh (Born Shell) ですね？
Linux が例に取られてるから bash だろうけど。
あたしゃ tcsh 使ってるのよー。
ついでに、clean-all にも build-ca にも実行ビットが立っていないので、仕方なく以下のように。
sh
. ./vars
sh ./clean-all
sh ./build-ca
. ./vars やると、clean-all やれ、って言われます。
./clean-all やっても何も言われないけど、./build-ca やるとガリガリ動いたあと、質問がいくつかなされます。
まぁ、属性設定項目を聞いてくるだけなんですが。
ほとんど ./vars で設定した内容がデフォルトで入っているので、そのまま Enter 押せばいいです。
が、一つだけ、設定しないといけない項目があります。
Common Name (eg, your name or your server's hostname) []:OpenVPN-CA
これだけは、適当に設定して下さい。
次に、Server の key pair を作ります。
sh ./build-key-server server
ここでも、Common Name は自分で設定しないといけません。
また、CA とも、あとから作成する Client とも、被ってはいけません。
まぁ、適当に server とかしておきます。
そして、次の二つの質問に yes と答えます。
Sign the certificate? [y/n] y
1 out of 1 certificate requests certified, commit? [y/n] y
これで Server の key pair 作成は完了です。
次に Client key pair を作成します。
今回は、2 つ （実家ネットワーク用とモバイルノート用） 作成します。
sh ./build-key jikka
sh ./build-key mobile
Common Name はユニークな物を付けて下さい。
まんま jikka, mobile と付けたことにします。
そして、Server と同じように、二つの質問に Yes と答えます。
これで鍵が出来ました。
鍵は全部、/usr/local/share/doc/openvpn/easy-rsa/ に出来てます。
公開鍵はともかく、秘密鍵が含まれますから、鍵は安全な方法でクライアントに持っていって下さい。
Client key は Client で作成して、CSR を提出して貰い、CA で署名して返す、と言う方法もあるのですが、めんどくさいのでしません。
というか、実家で鍵生成して、自宅に送って署名して持ってくる、って言うのがめんどくさいので。
次に、Diffie-Hellman パラメータを生成します。
sh ./build-dh
できたら、Server と Client に、それぞれコピーします。
Server には、
ca.crt
dh1024.pem
server.crt
server.key
を
実家には、
ca.crt
jikka.crt
jikka.key
を
ノートには、
ca.crt
mobile.crt
mobile.key
を
それぞれコピーします。
Server は、/usr/local/etc/openvpn/keys に置きました。
実家は同じ場所に。
ノートは、D:\Win32Apps\OpenVPN\keys に置きました。
これで、鍵の準備が整いました。
次に設定ファイルの編集です。
まずは Server から。
/usr/local/share/doc/openvpn/sample-config-files にサンプルがあるので、ここからコピーして編集します。
使うのは server.conf です。
まず Local IP Address の指定 （いっぱい IP Address が Alias してあるので）
local aaa.bbb.ccc.ddd
ポートは、デフォルトの 1194 のままです。
プロトコルも、デフォルトの udp にします。
＃ TCP も実装されているが、TCP-over-TCP 問題などがあり、UDP の方がよいとのこと
いろいろググったら、みんな Bridge モードで使ってるらしかったのだけれど、今回はネットワーク同士を繋ぐ必要があるので、ルーティングモードで使います。
なので、device は tun のままです。
そして、鍵の位置を指定します。
ca keys/ca.crt
cert keys/server.crt
key keys/server.key # This file should be kept secret
皆さんフルパスで書いているんですが、OpenVPN は、起動時にワークディレクトリの指定が出来るので、そこからの相対パスにしました。
Diffie-Hellman パラメータの位置も指定します。
dh keys/dh1024.pem
VPN の IP Address の設定は、デフォルトのままにしました。
server 10.8.0.0 255.255.255.0
この 10.8.0.0/24 というのは、Server 側 LAN の IP Address とも、Client の IP Address とも被らない設定にしないといけません。
192.168.0.0/16 あたりは、公衆サービスなどで使われている可能性があるので、要注意です。
マニュアルによれば、10.0.0.0/8 の真ん中あたりから取ってくれば、大丈夫じゃないかなぁ？ だそうです。
さて、今回はネットワーク同士を繋いで、シームレスに使えることを目的としているので、お互いのネットワークを広告して、ルーティングさせなきゃいけません。
なので、広告のために、次の設定をします。
push "route 自宅ネットワーク ネットマスク"
push "route 実家ネットワーク ネットマスク"
これで、広告されるそうです。
実家に繋がったら、ルーティングしないといけません。
実家から接続されたときに反応しないといけないので、client-config-dir を設定します。
client-config-dir ccd
ccd と言うディレクトリは、Server 実行時に存在しないといけません。
なので、/usr/local/etc/openvpn/ccd を作ります。
そして、ルーティングの設定を入れます。
route 実家ネットワーク ネットマスク
このほかに、実家から接続されたときの設定を ccd ディレクトリに作成します。
Client 名のファイルを作成し、ルート設定を入れます。
/usr/local/etc/openvpn/jikka:
iroute 実家ネットワーク ネットマスク
お互いにルーティングしないといけないので、冗長なようでも両方指定しろ、と書いてあります。
さて、server.conf の続き。
いるかどうか分からなかったのだけれど、一応 DNS と WINS を広告します。
push "dhcp-option DNS DNS-Server-IP-Address"
push "dhcp-option WINS WINS-Server-IP-Address"
そして、VPN の中で、他のクライアントマシンとも通信できるようにしたいので、以下の設定を入れます。
client-to-client
これを入れておかないと、各 Client は、Server しか見られません。
まぁ、これが必要なのは、モバイルノートから実家が見たい、とかの場合だけでしょうけれど。
あと、Server は FreeBSD なので、セキュリティのために以下の設定を有効にします。
user nobody
group nobody
こんなところで、Srver の設定は完了です。
Firewall に穴を開けて、Server を起動します。
とその前に、rc.conf に設定を。。。
#-- OpenVPN Settings --
openvpn_enable="YES"
openvpn_configfile="/usr/local/etc/openvpn/server.conf"
openvpn_dir="/usr/local/etc/openvpn"
これで、/usr/local/etc/rc.d/openvpn start すれば、動き出します。
Sat Sep 19 16:07:15 2009 OpenVPN 2.0.6 i386-portbld-freebsd7.2 [SSL] [LZO] built on Sep 19 2009
Sat Sep 19 16:07:15 2009 Diffie-Hellman initialized with 1024 bit key
Sat Sep 19 16:07:15 2009 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sat Sep 19 16:07:15 2009 TUN/TAP device /dev/tun0 opened
Sat Sep 19 16:07:15 2009 /sbin/ifconfig tun0 10.8.0.1 10.8.0.2 mtu 1500 netmask 255.255.255.255 up
Sat Sep 19 16:07:15 2009 /sbin/route add -net 10.8.0.0 10.8.0.2 255.255.255.0
add net 10.8.0.0: gateway 10.8.0.2
Sat Sep 19 16:07:15 2009 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Sat Sep 19 16:07:15 2009 GID set to nobody
Sat Sep 19 16:07:15 2009 UID set to nobody
Sat Sep 19 16:07:15 2009 UDPv4 link local (bound): 202.229.46.99:1194
Sat Sep 19 16:07:15 2009 UDPv4 link remote: [undef]
Sat Sep 19 16:07:15 2009 MULTI: multi_init called, r=256 v=256
Sat Sep 19 16:07:15 2009 IFCONFIG POOL: base=10.8.0.4 size=62
Sat Sep 19 16:07:15 2009 IFCONFIG POOL LIST
Sat Sep 19 16:07:15 2009 Initialization Sequence Completed
とかログが出れば成功です。
さて、次は Client です。
実家にはまだ帰っていないので、実家の設定は試せません （だから、その１なの）
というわけで、モバイルノートの設定をします。
sample-config-files の client.conf を下地にします。
というか、Windows 版なので、client.ovpn ファイルですね。
設定をいじるのは、remote 指定です。
ここで、OpenVPN Server を指定します。
remote Server-IP-Address 1194
1194 は、ポート番号です。
鍵の位置も指定しなきゃなりません。
ca d:\\win32apps\openvpn\\keys\\ca.crt
cert d:\\win32apps\openvpn\\keys\\mobile.crt
key d:\\win32apps\openvpn\\keys\\mobile.key
実行時ディレクトリを指定する方法が分からなかったので、フルパス指定です。。。orz
\ は、エスケープして書かないといけないそうです。
あとは、他の設定項目が Server と合っているかを確かめましょう。
ポート設定 (1194)、プロトコル (udp)、comp-lzo あたりを入念に。
これで設定は終わりです。
さっそく、繋いでみましょう。
Server の時と似たようなログが表示されれば、接続完了です。
Windows Vista だと、route 追加に失敗して、パラメータが間違っています、とか言うエラーが出ます。
結局、route.exe にお願いして、ルート設定しているようです。
心配なら netstat -r すること。
さて、最初、Samba に接続できなくて焦りました。
当たり前です。
Samba の設定を直さなきゃいけません。
今回の設定では、10.8.0.0/24 のネットワークから参照があるので、これを待ち受けないといけません。
hosts allow = 自宅ネットワーク 127.0.0.0/8 10.8.0.0/24
とかします。
これで、繋がるようになりました。
・・・\\Server-LAN-IP-Address\共有名 とかしないと繋がらないのはなんでだろう。
DNS 引けてるのに、\\サーバ名\共有名 じゃ、繋がらないんだよね。
まぁ、IP Address 指定すれば使えるからいいけど。
これは、先送りだなぁ。
さて、実家のネットワークと繋ぐことは出来るでしょうか。
楽しみ。
AntiVirus Scanner を導入
さて、予告通り、AntiVirus Scanner の導入です。
今回は、フリーの Clam AntiVirus Scanner (ClamAV) を採用しました。
Postfix との橋渡しには、AMaViS を使います。
AMaViS には、amavis, amavis-perl, amavisd-new, amavisd-ng と種類があるのですが、amavisd-new しかサポートもメンテもしてません、って書いてあるので、amavisd-new を使います。
と言って調べたら、FreeBSD の ports には amavisd-new しかないのでした。
でも、2004 年から更新止まってる感じね。
さて、そんなわけで、インストールするのは、
security/clamav
security/amavisd-new
です。
amavisd-new は、依存で山ほど port が入ります。
SpamAssassin も入るんだよね。。。orz
でも、使いません。
＃ 二重チェックしてもいいけど、バカっぽい
さて、まずは ClamAV の設定。
が、ほとんどデフォルトのままで問題ないです。
ログの設定をちょこっといじったくらい。
まぁ、ログは詳しく見たいし、時間も欲しいよね、ってことで。
LogFileMaxSize 2M
LogTime yes
LogVerbose yes
さて、次は AMaViS の設定です。
今回、オプションを指定しないでインストールしたので、vscan ユーザ／グループでインストールされちゃいました。
vscan は、McAfee VirusScan らしいです。
が、そんな物使いません。
今回使用するのは ClamAV なので、それを使うように設定します。
ClamAV のデーモンを使うためには、
AMaViS が ClamAV のユーザで動くか、
ClamAV が AMaViS のグループに属して、かつ、AllowSupplementaryGroups しないといけないみたいです。
どうせ ClamAV しか使わないので、AMaViS を ClamAV ユーザ／グループで動かします。
インストール時に作成された amavisd のディレクトリが、軒並み vscan:vscan なので、これを clamav:clamav に変更します。
変更の必要があったのは、
/var/amavis
/var/virusmails
もう一個くらいあった気がするけど、どれだっけ。。。
ちなみに amavisd-new のインストール時に
AMAVISUSER=clamav AMAVISGROUP=clamav
しておけば、良きに計らってくれたらしいです。
さて。
設定の変更点を挙げていきましょう。
今回は SpamAssassin を使った spam チェックはしないので、
@bypass_spam_checks_maps = (1); # controls running of anti-spam code
を有効にします。
ユーザの設定も変えておきます （オプション付きでインストールしたら要らないはず）
$daemon_user = 'clamav'; # (no default; customary: vscan or amavis), -u
$daemon_group = 'clamav'; # (no default; customary: vscan or amavis), -g
ドメイン設定を自ドメインに。
$mydomain = 'example.com'; # a convenient default for other settings
ネットワークの設定も変えましょう。
@mynetworks = qw( 127.0.0.0/8 [::1] [FE80::]/10 [FEC0::]/10
10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 );
チェックに引っ掛かった場合の動作もカスタムを。
$final_virus_destiny = D_DISCARD;
$final_banned_destiny = D_BOUNCE;
$final_spam_destiny = D_PASS;
$final_bad_header_destiny = D_PASS;
$bad_header_quarantine_method = undef;
ウィルスメールだったら、破棄 （VirusAlert 監視ユーザにコピーが行きます）
配送不可は送信元に送り返し。
spam は配送許可 （今回は作動しない）
壊れたヘッダを持つメールも配送許可。
にしてみました。
個人的には、ウィルスメールも配送させたいんですが、家族は訳も分からず exe とかクリックしちゃうと思うので、泣く泣く削除。
VirusAlert に飛んでくるメール見てニヤニヤすることにします。
$banned_filename_re = new_RE(
という項目を全部消さないと、添付ファイルが軒並み送れなくなります。
デフォルトだと、exe, dll, pif, scr, rpm, cpio, tar, application/x-msdownload, application/x-msdos-program, application/hta, vbs, bat, cmd, com, cpl あたりが送れません。
ウィルスだったら送らない、んじゃなくて、拡張子／suffix がそれだったら送らせない、と言う酷い設定。
全解除です。
そして、ClamAV との連携部分がコメントアウトされているので、これを有効にします。
# ### http://www.clamav.net/
['ClamAV-clamd',
\&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd.sock"],
qr/\bOK$/m, qr/\bFOUND$/m,
qr/^.*?: (?!Infected Archive)(.*) FOUND$/m ],
# # NOTE: run clamd under the same user as amavisd, or run it under its own
# # uid such as clamav, add user clamav to the amavis group, and then add
# # AllowSupplementaryGroups to clamd.conf;
# # NOTE: match socket name (LocalSocket) in clamav.conf to the socket name in
# # this entry; when running chrooted one may prefer socket "$MYHOME/clamd".
# ### http://www.clamav.net/ and CPAN (memory-hungry! clamd is preferred)
# # note that Mail::ClamAV requires perl to be build with threading!
# ['Mail::ClamAV', \&ask_clamav, "*", [0], [1], qr/^INFECTED: (.+)/m ],
ソケット部分は、デフォルトが /var/run/clamav/clamd になっているので、ClamAV の設定に合わせます。
/var/run/clamav/clamd.sock に修正。
これで完了です。
次に、Postfix の設定も変えます。
まず、main.cf.
content_filter = smtp-amavis:[127.0.0.1]:10024
を追加します。
これだけです。
次に、master.cf.
以下を追加します。
smtp-amavis unix - - n - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookup=yes
127.0.0.1:10025 inet n - n - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks_style=host
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
判定返りを待つ部分が、ガチガチの設定になってますが、こんなもんでしょう。
さて、rc.conf の設定です。
ClamAV を有効に。
#-- Clam AntiVirus Scanner Settings --
clamav_clamd_enable="YES"
clamav_freshclam_enable="YES"
clamav_freshclam というのは、ClamAV のデータベースを最新に保ってくれるデーモンです。
有効にしましょう。
さて、次に AMaViS の有効化。
#-- AMaViSd-new Settings --
amavisd_enable="YES"
出来たら、順次起動しましょう。
/usr/local/etc/rc.d/clamav_clamd start
/usr/local/etc/rc.d/clamav_freshclam start
/usr/local/etc/rc.d/amavisd start
/usr/local/etc/rc.d/postfix restart
これで完成です。
が。
AMaViS が、初回起動だけエラーを吐きました。
(!!)TROUBLE in child_init_hook: BDB no dbS: Lock table is out of available
locker entries, . at (eval 97) line 27.
(!)_DIE: Suicide in child_init_hook: BDB no dbS: Lock table is out of
available locker entries, . at (eval 97) line 27.
こんな感じ。
メールが一切送受信できなくなって焦りました。
一回全部止めて、起動し直したら問題なくなったんだよね。。。
BerkeleyDB のエラーらしいんだけど、何だったんだろう。。。
海外では、このエラーが報告されてて、BerkeleyDB をアップデートしろとか書いてあったんだよね。
なんか、これ謎みたいで、
$enable_db = 0;
にしたら起動した。
とか、そのあと $enable_db = 1; にしても問題なくなった、とか。
まぁ、動いてるから、気にしないことにしよう。
さて、なにかメールを送ってみましょう。
X-Virus-Scanned: amavisd-new at example.com
みたいなヘッダがあれば、OK です。
次に、実際にウィルスメールを送ってみましょう。
と言っても、1701 cascade くらいしか持っていないので。
ウィルスメールを送るサービスを利用します。
http://www.securesystems.co.jp/eicar.shtml
http://www.eicar.org/anti_virus_test_file.htm
これで、送ったアドレスにはメールが届かず、VirusAlert アカウントにメールのコピーが届けば完璧です。
無事動いたので、メールサーバの設定は終わりっ！
さて、タイムリーなことに、これを設定していたときに freebsd-stable ML に amavisd-new port の苦情が上がりました。
曰く、「port を upgrade したら、動かなくなった！ 調べてみたら、amavisd.conf をデフォルトに上書きされちゃってた！ バックアップしてたから実被害はなかったけど、ユーザがエディットしたコンフィグを消す port なんて見たことないから驚いた。 このバグ、どこに文句言えばいい？」
まぁ、「port maintainer に言え」 と言う至極真っ当な回答が返ってましたが。
なるほど、upgrade したら、設定ファイルを上書きされてしまうわけだな。
ちょっと覚えておかないといけませんね。
今回は、フリーの Clam AntiVirus Scanner (ClamAV) を採用しました。
Postfix との橋渡しには、AMaViS を使います。
AMaViS には、amavis, amavis-perl, amavisd-new, amavisd-ng と種類があるのですが、amavisd-new しかサポートもメンテもしてません、って書いてあるので、amavisd-new を使います。
と言って調べたら、FreeBSD の ports には amavisd-new しかないのでした。
でも、2004 年から更新止まってる感じね。
さて、そんなわけで、インストールするのは、
security/clamav
security/amavisd-new
です。
amavisd-new は、依存で山ほど port が入ります。
SpamAssassin も入るんだよね。。。orz
でも、使いません。
＃ 二重チェックしてもいいけど、バカっぽい
さて、まずは ClamAV の設定。
が、ほとんどデフォルトのままで問題ないです。
ログの設定をちょこっといじったくらい。
まぁ、ログは詳しく見たいし、時間も欲しいよね、ってことで。
LogFileMaxSize 2M
LogTime yes
LogVerbose yes
さて、次は AMaViS の設定です。
今回、オプションを指定しないでインストールしたので、vscan ユーザ／グループでインストールされちゃいました。
vscan は、McAfee VirusScan らしいです。
が、そんな物使いません。
今回使用するのは ClamAV なので、それを使うように設定します。
ClamAV のデーモンを使うためには、
AMaViS が ClamAV のユーザで動くか、
ClamAV が AMaViS のグループに属して、かつ、AllowSupplementaryGroups しないといけないみたいです。
どうせ ClamAV しか使わないので、AMaViS を ClamAV ユーザ／グループで動かします。
インストール時に作成された amavisd のディレクトリが、軒並み vscan:vscan なので、これを clamav:clamav に変更します。
変更の必要があったのは、
/var/amavis
/var/virusmails
もう一個くらいあった気がするけど、どれだっけ。。。
ちなみに amavisd-new のインストール時に
AMAVISUSER=clamav AMAVISGROUP=clamav
しておけば、良きに計らってくれたらしいです。
さて。
設定の変更点を挙げていきましょう。
今回は SpamAssassin を使った spam チェックはしないので、
@bypass_spam_checks_maps = (1); # controls running of anti-spam code
を有効にします。
ユーザの設定も変えておきます （オプション付きでインストールしたら要らないはず）
$daemon_user = 'clamav'; # (no default; customary: vscan or amavis), -u
$daemon_group = 'clamav'; # (no default; customary: vscan or amavis), -g
ドメイン設定を自ドメインに。
$mydomain = 'example.com'; # a convenient default for other settings
ネットワークの設定も変えましょう。
@mynetworks = qw( 127.0.0.0/8 [::1] [FE80::]/10 [FEC0::]/10
10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 );
チェックに引っ掛かった場合の動作もカスタムを。
$final_virus_destiny = D_DISCARD;
$final_banned_destiny = D_BOUNCE;
$final_spam_destiny = D_PASS;
$final_bad_header_destiny = D_PASS;
$bad_header_quarantine_method = undef;
ウィルスメールだったら、破棄 （VirusAlert 監視ユーザにコピーが行きます）
配送不可は送信元に送り返し。
spam は配送許可 （今回は作動しない）
壊れたヘッダを持つメールも配送許可。
にしてみました。
個人的には、ウィルスメールも配送させたいんですが、家族は訳も分からず exe とかクリックしちゃうと思うので、泣く泣く削除。
VirusAlert に飛んでくるメール見てニヤニヤすることにします。
$banned_filename_re = new_RE(
という項目を全部消さないと、添付ファイルが軒並み送れなくなります。
デフォルトだと、exe, dll, pif, scr, rpm, cpio, tar, application/x-msdownload, application/x-msdos-program, application/hta, vbs, bat, cmd, com, cpl あたりが送れません。
ウィルスだったら送らない、んじゃなくて、拡張子／suffix がそれだったら送らせない、と言う酷い設定。
全解除です。
そして、ClamAV との連携部分がコメントアウトされているので、これを有効にします。
# ### http://www.clamav.net/
['ClamAV-clamd',
\&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd.sock"],
qr/\bOK$/m, qr/\bFOUND$/m,
qr/^.*?: (?!Infected Archive)(.*) FOUND$/m ],
# # NOTE: run clamd under the same user as amavisd, or run it under its own
# # uid such as clamav, add user clamav to the amavis group, and then add
# # AllowSupplementaryGroups to clamd.conf;
# # NOTE: match socket name (LocalSocket) in clamav.conf to the socket name in
# # this entry; when running chrooted one may prefer socket "$MYHOME/clamd".
# ### http://www.clamav.net/ and CPAN (memory-hungry! clamd is preferred)
# # note that Mail::ClamAV requires perl to be build with threading!
# ['Mail::ClamAV', \&ask_clamav, "*", [0], [1], qr/^INFECTED: (.+)/m ],
ソケット部分は、デフォルトが /var/run/clamav/clamd になっているので、ClamAV の設定に合わせます。
/var/run/clamav/clamd.sock に修正。
これで完了です。
次に、Postfix の設定も変えます。
まず、main.cf.
content_filter = smtp-amavis:[127.0.0.1]:10024
を追加します。
これだけです。
次に、master.cf.
以下を追加します。
smtp-amavis unix - - n - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookup=yes
127.0.0.1:10025 inet n - n - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks_style=host
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
判定返りを待つ部分が、ガチガチの設定になってますが、こんなもんでしょう。
さて、rc.conf の設定です。
ClamAV を有効に。
#-- Clam AntiVirus Scanner Settings --
clamav_clamd_enable="YES"
clamav_freshclam_enable="YES"
clamav_freshclam というのは、ClamAV のデータベースを最新に保ってくれるデーモンです。
有効にしましょう。
さて、次に AMaViS の有効化。
#-- AMaViSd-new Settings --
amavisd_enable="YES"
出来たら、順次起動しましょう。
/usr/local/etc/rc.d/clamav_clamd start
/usr/local/etc/rc.d/clamav_freshclam start
/usr/local/etc/rc.d/amavisd start
/usr/local/etc/rc.d/postfix restart
これで完成です。
が。
AMaViS が、初回起動だけエラーを吐きました。
(!!)TROUBLE in child_init_hook: BDB no dbS: Lock table is out of available
locker entries, . at (eval 97) line 27.
(!)_DIE: Suicide in child_init_hook: BDB no dbS: Lock table is out of
available locker entries, . at (eval 97) line 27.
こんな感じ。
メールが一切送受信できなくなって焦りました。
BerkeleyDB のエラーらしいんだけど、何だったんだろう。。。
海外では、このエラーが報告されてて、BerkeleyDB をアップデートしろとか書いてあったんだよね。
なんか、これ謎みたいで、
$enable_db = 0;
にしたら起動した。
とか、そのあと $enable_db = 1; にしても問題なくなった、とか。
まぁ、動いてるから、気にしないことにしよう。
さて、なにかメールを送ってみましょう。
X-Virus-Scanned: amavisd-new at example.com
みたいなヘッダがあれば、OK です。
次に、実際にウィルスメールを送ってみましょう。
と言っても、1701 cascade くらいしか持っていないので。
ウィルスメールを送るサービスを利用します。
http://www.securesystems.co.jp/eicar.shtml
http://www.eicar.org/anti_virus_test_file.htm
これで、送ったアドレスにはメールが届かず、VirusAlert アカウントにメールのコピーが届けば完璧です。
無事動いたので、メールサーバの設定は終わりっ！
さて、タイムリーなことに、これを設定していたときに freebsd-stable ML に amavisd-new port の苦情が上がりました。
曰く、「port を upgrade したら、動かなくなった！ 調べてみたら、amavisd.conf をデフォルトに上書きされちゃってた！ バックアップしてたから実被害はなかったけど、ユーザがエディットしたコンフィグを消す port なんて見たことないから驚いた。 このバグ、どこに文句言えばいい？」
まぁ、「port maintainer に言え」 と言う至極真っ当な回答が返ってましたが。
なるほど、upgrade したら、設定ファイルを上書きされてしまうわけだな。
ちょっと覚えておかないといけませんね。
2009/09/17
bsfilter を仕込む
メールサーバが稼働したのですが、家族にも使わせるので、スパムフィルタを仕込もうと思ったのです。
スパムフィルタには様々ありますね。
POPFile
SpamAssassin
bogofilter
あたりがメジャーどころでしょうか。
＃ ベイジアンフィルタしかないやんけ、とか言わないように
色々調べてみた結果、bsfilter を使うことに決めました。
本当は、SpamAssassin を使おうかと思っていたのですけれど。
bogofilter も、C で書かれていて軽い、と言う点で魅力的だったのですけれど。
bsfilter は、独自に日本語に対応している、と言う点で日本人が使うならこれが良さそうだ、と判断しました。
ryby スクリプトなので、重さが気になるんですけどね。
＃ それを言ったら SpamAssassin は Perl じゃないか、とか言われそう
bsfilter 単体では、うまく日本語の文章から単語を切り出すことが出来ません。
なので、外部の形態素解析器を使います。
形態素解析器というのは、日本語の文章の中から、単語分けして切り出してくれるものだと思っといて下さい。
というか、bsfilter は、そう言う目的でしか使ってません。
使用できる形態素解析器は３つ。
和布蕪 （めかぶ）
茶筅 （ちゃせん）
案山子 （かかし）
今回は、和布蕪を使うことにしました。
本当は茶筅を使おうとしたのですけれど、調べたら和布蕪の方が良さそうだったので。
和布蕪は、茶筅がベースで、精度はほぼ同等、速度は倍以上、と言うことだそうです。
と言うわけで、追加インストールするのは、
mail/bsfilter: bsfilter 本体
japanese/ja-mecab: 和布蕪本体
japanese/ja-ruby-mecab: 和布蕪の Ruby バインディング
japanese/ja-mecab-ipadic: 和布蕪の辞書
となります。
bsfilter を ports からインストールすると、オプション選択で和布蕪と茶筅と案山子とを選ぶことが出来ます。
ここで和布蕪にチェックを入れておけば、和布蕪と Ruby バインディングは、依存で入ります。
ただし。
和布蕪の辞書は入れてくれないので、これだけは自分で入れる必要があります。
入れ忘れると、bsfilter 実行時に、「辞書がない！」 って怒られちゃいます。
さて。
bsfilter は、データディレクトリとして、$HOME/.bsfilter を使います。
設定も、ここに用意してやります。
内容はこんな感じ。
$HOME/.bsfilter/bsfilter.conf
jtokenizer mecab
insert-flag
insert-probability
auto-update
これで、
形態素解析器として和布蕪を指定
X-Spam-Flag: ヘッダを追加
X-Spam-Probability: ヘッダを追加
自動データベース更新
を指定したことになります。
あとは、データベースの用意です。
手元に、今まで受信した 7,000 通あまりの spam と、1,000 通あまりのメールがあるので、これを使います。
通常は、
bsfilter -c ~/Maildir/cur/*
bsfilter -s ~/Maildir/spam/cur/*
ってやって下さい、って言うところなんですが。。。
spam が 7,000 通あまりもあると、Argument too long! って言われちゃいまして （＾”＾；；；
仕方がないので、bsfilter に IMAP で読みに行ってもらいました。
bsfilter --imap --imap-server サーバ名 --imap-user ユーザ名 --imap-password パスワード -s inbox.spam
すんごく時間掛かりました。
どこにもログ更新などはされないので、思わず
tcpdump -i lo0 port imap
して見ちゃいました （笑）
クリーンメールもデータベースに突っ込んで。
で、データベース更新。
bsfilter -u
しばらく待っていれば、データベースができあがります。
あとは使うように設定するだけ。
一応、システム全体でこれを有効にするのは怖いので、各ユーザごとに使うようにしました。
ので、.forward で指定するわけだ。
んが、フィルタしてヘッダ付けて貰うだけ、って言うのをシンプルにやる方法が思いつかなかったので。
将来的に、自動振り分けも視野に入れて、procmail 使いました。
そんなわけで、.forward は、こんな感じ。
~/.forward
"| IFS=' ' && pmprog=/usr/local/bin/procmail && test -f $pmprog && exec $pmprog -Yf- .procmailrc.tamon || exit 75 #ユーザ名
レシピは、こんな感じ。
~/.procmailrc
PATH=$HOME/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/
LOGFILE=$HOME/log/procmail.log
LOCKFILE=$HOME/.lockmail
:0 fw
| bsfilter --pipe
スパムフィルタには様々ありますね。
POPFile
SpamAssassin
bogofilter
あたりがメジャーどころでしょうか。
＃ ベイジアンフィルタしかないやんけ、とか言わないように
色々調べてみた結果、bsfilter を使うことに決めました。
本当は、SpamAssassin を使おうかと思っていたのですけれど。
bogofilter も、C で書かれていて軽い、と言う点で魅力的だったのですけれど。
bsfilter は、独自に日本語に対応している、と言う点で日本人が使うならこれが良さそうだ、と判断しました。
ryby スクリプトなので、重さが気になるんですけどね。
＃ それを言ったら SpamAssassin は Perl じゃないか、とか言われそう
bsfilter 単体では、うまく日本語の文章から単語を切り出すことが出来ません。
なので、外部の形態素解析器を使います。
形態素解析器というのは、日本語の文章の中から、単語分けして切り出してくれるものだと思っといて下さい。
というか、bsfilter は、そう言う目的でしか使ってません。
使用できる形態素解析器は３つ。
和布蕪 （めかぶ）
茶筅 （ちゃせん）
案山子 （かかし）
今回は、和布蕪を使うことにしました。
本当は茶筅を使おうとしたのですけれど、調べたら和布蕪の方が良さそうだったので。
和布蕪は、茶筅がベースで、精度はほぼ同等、速度は倍以上、と言うことだそうです。
と言うわけで、追加インストールするのは、
mail/bsfilter: bsfilter 本体
japanese/ja-mecab: 和布蕪本体
japanese/ja-ruby-mecab: 和布蕪の Ruby バインディング
japanese/ja-mecab-ipadic: 和布蕪の辞書
となります。
bsfilter を ports からインストールすると、オプション選択で和布蕪と茶筅と案山子とを選ぶことが出来ます。
ここで和布蕪にチェックを入れておけば、和布蕪と Ruby バインディングは、依存で入ります。
ただし。
和布蕪の辞書は入れてくれないので、これだけは自分で入れる必要があります。
入れ忘れると、bsfilter 実行時に、「辞書がない！」 って怒られちゃいます。
さて。
bsfilter は、データディレクトリとして、$HOME/.bsfilter を使います。
設定も、ここに用意してやります。
内容はこんな感じ。
$HOME/.bsfilter/bsfilter.conf
jtokenizer mecab
insert-flag
insert-probability
auto-update
これで、
形態素解析器として和布蕪を指定
X-Spam-Flag: ヘッダを追加
X-Spam-Probability: ヘッダを追加
自動データベース更新
を指定したことになります。
あとは、データベースの用意です。
手元に、今まで受信した 7,000 通あまりの spam と、1,000 通あまりのメールがあるので、これを使います。
通常は、
bsfilter -c ~/Maildir/cur/*
bsfilter -s ~/Maildir/spam/cur/*
ってやって下さい、って言うところなんですが。。。
spam が 7,000 通あまりもあると、Argument too long! って言われちゃいまして （＾”＾；；；
仕方がないので、bsfilter に IMAP で読みに行ってもらいました。
bsfilter --imap --imap-server サーバ名 --imap-user ユーザ名 --imap-password パスワード -s inbox.spam
すんごく時間掛かりました。
どこにもログ更新などはされないので、思わず
tcpdump -i lo0 port imap
して見ちゃいました （笑）
クリーンメールもデータベースに突っ込んで。
で、データベース更新。
bsfilter -u
しばらく待っていれば、データベースができあがります。
あとは使うように設定するだけ。
一応、システム全体でこれを有効にするのは怖いので、各ユーザごとに使うようにしました。
ので、.forward で指定するわけだ。
んが、フィルタしてヘッダ付けて貰うだけ、って言うのをシンプルにやる方法が思いつかなかったので。
将来的に、自動振り分けも視野に入れて、procmail 使いました。
そんなわけで、.forward は、こんな感じ。
~/.forward
"| IFS=' ' && pmprog=/usr/local/bin/procmail && test -f $pmprog && exec $pmprog -Yf- .procmailrc.tamon || exit 75 #ユーザ名
レシピは、こんな感じ。
~/.procmailrc
PATH=$HOME/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/
LOGFILE=$HOME/log/procmail.log
LOCKFILE=$HOME/.lockmail
:0 fw
| bsfilter --pipe
まさに、フィルタ処理してるだけ （笑）
procmail にしてみれば、役不足でしょう。
フォルダ自動振り分けレシピを書く気力がないので、この辺 SeaMonkey に任せっぱなしです。
今のところ、全ユーザで有効にするので、全ユーザでこの処理をやります。
設定ファイルなんかはコピーですが、データベースだけは怖いので、正規の手順通りに。
bsfilter --export-clean > clean.list.txt
bsfilter --export-spam > spam.list.txt
して、各ユーザごとに
bsfilter --import-clean > clean.list.txt
bsfilter --import-spam > spam.list.txt
bsfilter -u
を実行。
今のところ、すり抜けはあっても誤認はないので、他のユーザの奴は、spam 判定されたら spam フォルダへ振り分けました。
レシピは、こんな感じ。
~/.procmailrc
PATH=$HOME/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/
LOGFILE=$HOME/log/procmail.log
LOCKFILE=$HOME/.lockmail
:0 fw
| bsfilter --pipe
:0 H
* ^X-Spam-Flag: Yes
$MAILDIR/.spam/
さて。
誤認されたら、再学習させなきゃいけません。
で、使用説明書には、
bsfilter -S -c -u clean_mail
bsfilter -C -s -u spam_mail
しなさい、とか書いてあるわけだ。
しょうがないので、メールの中身だけ転送すればいいように、拡張アドレスでちょこっとやりました。
＃ spam のヘッダなんか、偽装されてるかなんかで、まともな情報ないだろ、って言ういい加減な考え
~/.procmailrc.toclean
:0 fw
| bsfilter -S -c -u --pipe
:0
/dev/null
~/.procmailrc.tospam
:0 fw
| bsfilter -C -s -u --pipe
:0
/dev/null
何やってんだおまえ、って言われそうです （＾”＾；；；
まぁ、これで乗り切っていくことにしてみますよ。
次は、AntiVirus スキャナか・・・
2009/09/13
courier-imap をインストール
postfix を入れて、メールの配送が出来るようになったので、メールは読めなくっちゃね。
というわけで、courier-imap をインストール。
あ、postfix のローカル配送は、Maildir 形式ですよ、もちろん。
＃ じゃないと、courier-imap は使えない
設定は、/usr/local/etc/courier-imap/ の imapd と imapd-ssl を、ちょいといじるだけでほぼ完了。
ろくなマニュアルがないけど、設定ファイルのコメントに十分すぎるほど書いてあるので、問題にならないと思います。
メインの仕事は、/usr/local/etc/userdb をちまちま作って makeuserdb すること。
userdb には、home, mail の指定があるので、ここで mailbox をきちんと指定。
バーチャルホストにも対応できる。
パスワードは、CRAM-MD5 が hmac-md5, CRAM-SHA1 が hmac-sha1 らしい。
忘れがちなのが、/etc/syslog.conf と /etc/newsyslog.conf.
それぞれ、設定をしましょう。
/etc/syslog.conf: （追加分のみ）
!imapd
*.* /var/log/imapd
!imapd-ssl
*.* /var/log/imapd-ssl
/etc/newsyslog.conf: （追加分のみ）
/var/log/imapd 640 7 100 * JC
/var/log/imapd-ssl 640 7 100 * JC
これが出来れば、おしまい。
syslogd に HUP シグナル送って、courier-imap を起動するだけ。
これで問題なく動きました。
全然チェックしていなかった root のメールをチェックしたら、
crontab の書き方ミスって、コマンド実行ごとにエラーメール飛んでたり、
なんか凄いアタックログが飛んできてたりして、
かなりびっくりしました （＾＾；
やはり root のメールはチェックしないとダメですね。。。
というわけで、courier-imap をインストール。
あ、postfix のローカル配送は、Maildir 形式ですよ、もちろん。
＃ じゃないと、courier-imap は使えない
設定は、/usr/local/etc/courier-imap/ の imapd と imapd-ssl を、ちょいといじるだけでほぼ完了。
ろくなマニュアルがないけど、設定ファイルのコメントに十分すぎるほど書いてあるので、問題にならないと思います。
メインの仕事は、/usr/local/etc/userdb をちまちま作って makeuserdb すること。
userdb には、home, mail の指定があるので、ここで mailbox をきちんと指定。
バーチャルホストにも対応できる。
パスワードは、CRAM-MD5 が hmac-md5, CRAM-SHA1 が hmac-sha1 らしい。
忘れがちなのが、/etc/syslog.conf と /etc/newsyslog.conf.
それぞれ、設定をしましょう。
/etc/syslog.conf: （追加分のみ）
!imapd
*.* /var/log/imapd
!imapd-ssl
*.* /var/log/imapd-ssl
/etc/newsyslog.conf: （追加分のみ）
/var/log/imapd 640 7 100 * JC
/var/log/imapd-ssl 640 7 100 * JC
これが出来れば、おしまい。
syslogd に HUP シグナル送って、courier-imap を起動するだけ。
これで問題なく動きました。
全然チェックしていなかった root のメールをチェックしたら、
crontab の書き方ミスって、コマンド実行ごとにエラーメール飛んでたり、
なんか凄いアタックログが飛んできてたりして、
かなりびっくりしました （＾＾；
やはり root のメールはチェックしないとダメですね。。。
2009/09/12
postfix をインストール
やっと、メールサーバの設定が出来るようになったので、postfix を入れてみました。
うちのネットワーク構成
<The Internet> <-> Broadband Router <-> <DMZ Network> <-> Gateway <-> <LAN> <-> Server
つまり、postfix は、Gateway と Server に入れて、
Gateway では、The Internet からのメールを受信し Server へ転送と、内部からの送信メールの配送。
Server では、Gateway からのメールの受信／ローカル配送と、内部から送信されたメールを Gateway へ配送を依頼。
と言うことをさせるわけだ。
ついでに、Gateway では、
SMTP-AUTH で認証されたクライアントからは、外部宛のリレーの許可。
バーチャルドメイン２つのホスティング。
もやる。
もっとも、バーチャルドメイン宛のメールも、Server でローカル配送するわけで、Server にもバーチャルドメインの設定は必要。
色々設定例を探したけれど、一番役に立ったのは、postfix の
BASIC CONFIGURATION README
SASL README
STANDARD CONFIGURATION README
VIRTUAL README
でした。
付属ドキュメントは読みましょう ＞ σ（＿＿；
設定 Tips は、これが全てでした。
なお、例に従って、Gateway では、ローカル配送を禁止しました。
なので、root 宛に来る security report などは、Server に転送されてきます。
あ、Cyrus-SASL support を有効にしましたが、これの設定は、情報が錯綜していますが、
平文認証で、PAM などで認証するなら
/usr/local/lib/sasl2/smtpd.conf:
pwcheck_method: saslauthd
mech_list: plain login
などとし、Challenge/Response 認証をするなら
/usr/local/lib/sasl2/smtpd.conf:
これで一通りの設定終わり。
・・・smtp サーバが反応しませんでした。
・・・OP25B か！
色々探したら、ありました。
submission port での待ち受けには、問答無用で TLS 使うように設定されていたのでした。
問題なく動くようになりました。
うちのネットワーク構成
つまり、postfix は、Gateway と Server に入れて、
Gateway では、The Internet からのメールを受信し Server へ転送と、内部からの送信メールの配送。
Server では、Gateway からのメールの受信／ローカル配送と、内部から送信されたメールを Gateway へ配送を依頼。
と言うことをさせるわけだ。
ついでに、Gateway では、
SMTP-AUTH で認証されたクライアントからは、外部宛のリレーの許可。
バーチャルドメイン２つのホスティング。
もやる。
もっとも、バーチャルドメイン宛のメールも、Server でローカル配送するわけで、Server にもバーチャルドメインの設定は必要。
色々設定例を探したけれど、一番役に立ったのは、postfix の
BASIC CONFIGURATION README
SASL README
STANDARD CONFIGURATION README
VIRTUAL README
でした。
付属ドキュメントは読みましょう ＞ σ（＿＿；
設定 Tips は、これが全てでした。
なお、例に従って、Gateway では、ローカル配送を禁止しました。
なので、root 宛に来る security report などは、Server に転送されてきます。
あ、Cyrus-SASL support を有効にしましたが、これの設定は、情報が錯綜していますが、
平文認証で、PAM などで認証するなら
/usr/local/lib/sasl2/smtpd.conf:
pwcheck_method: saslauthd
mech_list: plain login
などとし、Challenge/Response 認証をするなら
/usr/local/lib/sasl2/smtpd.conf:
pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: cram-md5 digest-md5
などとやるべし。
これで一通りの設定終わり。
レジストラが提供している DNS をちょちょいといじって MX レコードを設定して、
外部からのメールがきちんとローカル配送できて、
内部からは、問題なくメールが配送できたので、
今度は、外部からのリレーチェック。
・・・smtp サーバが反応しませんでした。
おんやぁ？
色々試して、パケットフィルタログ見て、おかしくない。。。
パケットキャプチャしたら、接続が来ていませんでした。
・・・OP25B か！
submission ポートに切り替えて、再試行。
"STARTTLS を実行して下さい！"
TLS 設定してないけどな。。。
TLS 接続で再試行。
"STARTTLS は、サポートされません"
デスヨネー。
色々探したら、ありました。
master.cf:
submission inet n - n - - smtpd
> # -o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
submission port での待ち受けには、問答無用で TLS 使うように設定されていたのでした。
コメントアウトして。
問題なく動くようになりました。
登録:
投稿 (Atom)