連投になりますが。。。
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/
登録:
投稿 (Atom)