実はiアプリのゲームを制作していたりします。
既にF900iとN900iが発売され、もうすぐP900iも発売されるということで、その自作iアプリを900i対応にしてみました。

…といっても900iは505iと画面解像度が一緒なので、ADFの設定でTargetDeviceに「all900」を追加しただけです。
一応ググってみたけど、このall900がFOMA900i全ての機種用という記述が見当たりませんでしたが、今までずっとallXXXだったので設定してみたら、どんぴしゃでした。

まあ、一応参考までにエントリしておきます。

現在我がWebサイトの文字コードはEUC-JPを使用しています。
普通にUNIX上に自前でMovableTypeを構築している人の殆どがEUC-JPだと思うのですが、それでも世間ではUTC-8(Unicode)を使うサイトが多くなってきました。

別にpingしている先(ping.bloggers.jpなど)が文字コードを判別してちゃんと登録されるのなら、別に今の文字コードでも問題ないのだけれど、やっぱりUTC-8にしておけばよかったな〜と最近思ったりしています。

幸いなことに、私はMTをPostgreSQLで動作させているので、以下の修正だけで簡単にEUCからUTC-8に変更ができます。本番環境では確認していませんが、テスト環境を作ってデータ移行が正常に行なえるのを確認しました。

• pg_dump db名 > master.dbでDBの内容をテキスト化
  
• nkf -w master.db > change.dbでUTF-8に変換
  
• psqlでmt_*で始まる全てのtableとsequenceを削除
  
• psql < change.dbで新しいファイルをDBに格納
  
• MTのディレクトリを違う名前にコピーしてバックアップ
  
• MTのディレクトリ配下を全てUTF-8のパッチを当てたMTに入れ替える
  
• 先ほどバックアップしたMT/mt.cfgを新しいMTディレクトリにコピー
  
• mt.cfg内のPublishCharsetをUTF-8に変更
  
• Styleseetの@charset を「"EUC-JP";」から「"UTF-8";」に変更
  
• mt.cgiをブラウザで表示し、全て再構築を行う
  

drop table mt_author;
drop table mt_blog;
drop table mt_category;
drop table mt_comment;
drop table mt_entry;
drop table mt_ipbanlist;
drop table mt_log;
drop table mt_notification;
drop table mt_permission;
drop table mt_placement;
drop table mt_plugindata;
drop table mt_tbping;
drop table mt_template;
drop table mt_templatemap;
drop table mt_trackback;
drop sequence mt_author_id;
drop sequence mt_blog_id;
drop sequence mt_category_id;
drop sequence mt_comment_id ;
drop sequence mt_entry_id;
drop sequence mt_ipbanlist_id;
drop sequence mt_log_id;
drop sequence mt_notification_id;
drop sequence mt_permission_id;
drop sequence mt_placement_id;
drop sequence mt_plugindata_id;
drop sequence mt_tbping_id;
drop sequence mt_template_id;
drop sequence mt_templatemap_id;
drop sequence mt_trackback_id;

前回修理に出したBIBLOだけれど、電源周りを直してもらったら別の場所を壊されていたことが発覚しました。
ご存知の通りMG13Dは背面に無線LANのON/OFFスイッチがあるのですが、そのスイッチがイカれててOFFにしたらそれっきりONに切り替わらなくなってしまった。

なんだか基板のスイッチにかみ合っていないみたい。前回修理の組み上げ時に確認ちゃんとしていないのね。

夜遅くに富士通に電話したんだけど、修理受付はしてもらったけど、重クレーム扱いの判断は夜担当の人間はできないみたいで、通常修理になってしまった。

押しが弱いか。まあ別にMacでも困らないしね。

【2/20追記】
午前中にヤマト運輸の人が集荷に来たんだけど、なんか梱包用の箱持参で来た。富士通にはこっちで梱包するって伝えたつもりだったのに。なんかアルバイト君みたいで、梱包しなくていいって言ったら困ってしまったみたいで、なんか事務所に電話とかして確認しているし。。。
結局そのまま持っていってくれたけどなんか、富士通とヤマト運輸の連携がうまくとれていない。前回も伝票持たずに集荷に来て手書き伝票では駄目だとかなんとかでスムースな引き取りがされなかったし。

２４時間対応は立派だけど、もっとしっかりしてください＞富士通さん（とヤマト運輸）

はじめに

リンクシスのBEFSR41C-JPというルータは安価なくせに高機能でSNMPを喋ることができます。今回はルータのログをsnmptrapを使ってFreeBSD側で受け取る設定を紹介します。

やり方として

• syslogに出力させる
• traphandleを使って自作ログに出力させる

の二種類を紹介します。traphandleを使うと簡単に目的のsnmptrapに対して別のプログラムが実行できるので色々活用できそうです。

ucd-snmpのインストール

既にucd-snmpは名前をnet-snmpと変えてVer5.xが出ていますが、今回はucd-snmp 4.xを使用します。理由はこちらのほうが現時点ではインターネット上で情報が豊富だからです。

さて、portsからサクっとインストールしましょう。

今回はsnmpエージェントは使用しないので、/usr/local/etc/rc.d/snmpd.shを起動不可にします。

一応インストール確認として、ルータの情報を軽く見てみましょう。(私の場合は192.168.0.1がルータのアドレスです)

ずらっと何か出たと思います。内容についてはsnmpを他サイトで勉強しましょう（笑）

BEFSR41C-JPの設定

ルータ設定画面からログのタブを選択し、ログを有効に。送信するIPアドレスに(一応)FreeBSDのアドレスを入力します。ただし、この値がデフォルトの255でもブロードキャストで全マシンに流れるので特に問題ありません。

syslogに出力する

まずはルータログをsyslogで取得してみましょう。

/usr/local/etc/rc.d/snmptrapd.shを以下のように作成します。

#!/bin/sh

if ! PREFIX=$(expr $0 : "\(/.*\)/etc/rc\.d/$(basename $0)\$"); then
    echo "$0: Cannot determine the PREFIX" >&2
    exit 1
fi

case "$1" in
start)
        [ -x ${PREFIX}/sbin/snmptrapd ] && ${PREFIX}/sbin/snmptrapd -s -l5
        echo -n ' snmptrapd'
        ;;
stop)
        killall snmptrapd && echo -n ' snmptrapd'
        ;;
*)
        echo "Usage: `basename $0` {start|stop}" >&2
        ;;
esac

exit 0

この例ではtrapを受けるsyslogのファシリティーはlocal5を使っています。

続いて/etc/syslog.confに以下の一行を追加します。

local5.*        /var/log/linksys.log

途中の空白はTABで入力してください。スペースだと駄目です。

ここまで準備ができたら、syslogdにHUPシグナルを送り、snmptrapdを起動します。

暫くネットを徘徊してから/var/log/linksys.logを見てみましょう。以下のようなログがたまっているはずです。

traphandleで取得する

次はtraphandleで取得してみましょう。前節で設定したsyslogのトラップ設定はそのまま残しても構いません。もし、syslogへの出力を止めてtraphandleだけでログを取得したい場合は、/usr/local/etc/rc.d/snmptrapd.sh内のsnmptrapdの引数「-s -l5」を削除してください。

さて、traphandleの設定は/usr/local/share/snmp/snmptrapd.confで行います。今回trap検知するルータのOIDは「.1.3.6.1.4.1.3955.2.2.1.0.1」です。この値について分からない人はSNMPの基礎を他サイトで勉強しましょう。私もよく分かっていません。

このOIDに対してtrapが発生した時に実行するプログラムも用意します。私はconfと同じ場所においたので、設定ファイルは以下の様になります。

続いてプログラム内の紹介ですが、traphandleで受けたプログラムは標準入力から情報を受け取ります。

linux.or.jpから引用します。

プログラムは trap の詳細を標準入力から受け取る。フォーマットは以下のようになっており、1 行につき 1 エントリである。

HOSTNAME

trap を送ってきた該当ホストの名前。ホスト名は gethostbyaddr() で決定されたものである。

IPADDRESS

trap を送ってきたホストの IP アドレス。

VARBINDS

トラップとその変数の記述を含む variable bindings のリスト。空白までの行の最初のトークンは OID で、行の残りの部分はその値である。 1 番目の OID は system.sysUpTime.0、 2 番目の OID は ...snmpTrap.snmpTrapOID.0 にすべきである。 OID の残りは trap に含まれる variable bindings である (ただし最後の OID はこの限りでないかもしれない)。 SNMPv1 trap では、一番最後の OID は ...snmpTrap.snmpTrapEnterprise とその値である。基本的に SNMPv1 trap は、 SNMPv1 と SNMPv2 の共存のためのドキュメントに書かれている方法で、 SNMPv2 trap の PDU タイプに変換されている。しかし RFC の番号を忘れてしまった。

今回はテスト用のログ出力プログラムを公開します。

#!/usr/bin/perl

while (<STDIN>) {
        $buf.=$_;
}

open(FILE,">>/tmp/out.txt");
print FILE $buf;
print FILE "-----\n";
close(FILE);

syslogよりも多い情報を取得できますが、こちらは単にログを収集するのではなく、ログの内容に対して何かしらのアクションを起こす仕組みを作りこむのがいいと思います。

例えばIPアドレスが変更になったら、即時DynamicDNSの更新を行う等ができます。

我が家では夫婦で一台ずつパソコンがあるので、楽しいWebサイトなどのURLを送るのに、IPメッセンジャーを活用しています。これは企業などでデファクトスタンダードと言って良いほど浸透しているソフトウェアで使い方を誤ると仕事に支障をきたすという優れもの(?)です。

ＦｒｅｅＢＳＤからもメッセージの送信ができると便利だな〜と思っていたら、ありました。紹介します。udpmsgです。作者の方のトップページはこちらです。

そのソフトは送信専用でコマンドラインから直接送信したいＩＰメッセンジャーが動作しているマシンのＩＰアドレスを指定します。

ビルド方法を簡単に以下に示します。

これで、rehashするか再ログインするとudpmsgが使えるようになります。

使い方は「echo メッセージ | udpmsg IPアドレス」の形式で実行します。

例として時間のかかるportsdb -Uuが実行を終わったときにクライアントにメッセージを流す方法を以下に示します。

この機能を利用して、次回はルータの接続時に連携する方法について書きたいと思います。色々と楽しく使えるのでLinuxユーザの方も多分いけると思うのでトライしてみてください。

本日修理にあずけていたBIBLOが帰ってきました。六日に預けて１１日に到着。結構早かった。よかった。
修理箇所はコネクタ基板の交換とACアダプタの交換です。電源周りがやばかったという事ね。
引き取りも発送も全てがスムースで非常に好感の持てる修理センターでした。
以前嫁さんが使っているデスクトップを修理に出したときは融通が全く利かずに一ヶ月くらい放置された思い出があるから今回ちょっと心配だったの。MVKは修理に時間がかかります。気をつけましょう。

ドメインとかDNSとか、今ひとつ理解がちゃんとしていないな？と思ったことはありませんか？
私も自分でドメインを取るまでなんとなく理解していたつもりだった、この辺の知識をちゃんと整理したいと思って、いろいろググってきました。

ページはとてもシンプルですが、以下は結構初心者向きでおすすめです。私も勉強になりました。

既に理解しているよっていう方もご覧になるとよろしいかも。
他にも良いページを見つけたらエントリは随時更新していきたいと思います。

今はApacheは1.3系を利用しているが、そろそろ・・・と思い2.0系の最新版をportsからインストールした。1.3とは共存できないので、サーバ停止時間をなるべく短くと思って作業を行ったが、思わぬところでつまずいてしまった。

SUEXECオプションを入れてコンパイルしてインストールしたのだが、今まで設定してたhttpd.conf内のUser,Group指定はなくなって、新たにSuexecUserGroupに実行したい権限ユーザ名とグループを指定するらしいのだが、なんとこれを指定すると、/home/*/public_html配下のCGIの実行がSuexecUserGroupで指定したユーザで実行されてしまうみたい。

つまりhttpd-suexec.logをみる限り「実行できません」と怒られる（実際動いていないし）。

これを指定しないと、public_html配下は実行できるけど、今度は通常のDocumentRoot配下のCGIが実行できない。

いろいろなサイトを覗くとみんな同じ問題を抱えていて、VirtualHostを巧みに使って誤摩化している人が結構いたけど、別にApache2にこだわりはないので（SUEXECにはこだわりがある）、Apache13に戻しちゃいました。

今後に期待ということで・・・。役に立たないエントリで申し訳ない。

【後日談】
configureオプションで--with-suexec-callerを普段使っているUIDにセットして、SuexecUserGroupの指定をhttpd.confから全て取り除いて試してみたら、今度はsuexecモードで動作してくれませんでした。
やっぱり、suexecを使うにはconfigureオプションの他にSuexecUserGroupを指定しないと駄目みたいです。一応パッチもあるみたいですが、オフィシャルなものではないのでちょっと使うのに躊躇しています。

【後日談2(2004/3/21)】
Apache 2.0.49がリリースされましたが、変更履歴を見る限り、本問題は対処されていないようです。思想的に不要と判断されたのでしょうか。なぜ不要な機能と判断されているのか真相が分かりません。英語力と技術力の不足からです。どなたか分かる人、教えてください。

【後日談3(2005/8/6)】
久しぶりにApache 2.0.54_2で試してみたら、ちゃんと動くようになりました。
ディレクティブにSuexecUserGroupの指定があっても、ちゃんと中のpublic_html配下はそのユーザの権限で動作します。

これで2.xに上げるのを躊躇する必要はなくなりました。よかったよかった。

実は半年ぐらい前からMG13Dの調子が悪かった。
具体的には本体側のACアダプタ接続部の接触が悪くてちょっと触るとアダプタが刺さっているにも関わらずバッテリーモードに移行してしまう。ちょっとコネクタを触るとまたAC駆動に戻るという状態。

まだ保証期間内なのでそろそろ修理依頼をすることにした。サポートに電話してみると今日引き取りに来てくれるらしい。修理期間はおよそ7〜10日。

その間はiBookを使うことにする。
Macも手の空いたときにちゃんとメンテしておいたので、あとはメール設定とsafariのブックマークを追加するだけでとりあえず通信環境は確保できた。

でも、普段からWindows使っているとMacは違和感があるなぁ。
でも、10.3.2にしてから「ことえり」が頭良くなった気がする。文章が快適に入力できます。

HDDの入れ替えをしようと思って、80GBのハードディスクを買ってきた。
うちのサーバは440LXの古いマザーボードなので実際は32GBしか認識しなかった。まあ仕方ないか。

で、今のOSの内容を丸ごとコピーしようと思ったら起動ディスクから異音が発生して立ち上がらなくなってしまった。元々３年以上頑張ったHDDなんだけど、新しいHDDをつなげるのに何度も電源のON/OFFを繰り返したのがいけなかったみたい。

幸いな事にデータの入ったディスクは無事っぽいので、新規インストールをすることにした。
手元にはFreeBSD4.7RのブートCDしかなかったのでそれでインストール。最低限のものをいれてなんとか起動するようになった。

/etc, /usr/local/etcは数週間前にバックアップとって置いたので復旧は楽だった。
壊れたHDDも叩いて無理やり認識させて、/var/logのコピーはできた。結構ログは重要なのです。

後はcvsupで最新のソース一式を取ってきてmake buildwordしながら、apache,postgresqlを優先的に設定して、１〜２時間でWebサイトの公開は行えるようにできた。

朝から始めて夜にはとりあえず基本的なアプリも入った。後は必要に応じてportsからmakeしていこう。

大変だったけど、portsパッケージもかなり古くなってきていたので、新しいものを入れるいい機会になったかも。

はじめに

本エントリは自分用の作業メモです。役に立つ部分ももしかしたらあるかも。。。では

現在我が家で動作しているFreeBSDマシンは、もうかれこれ３〜４年前から動作している。途中でCPUやマザーボードを交換したりしたが、HDDは当初からずっとそのまま使っている。

別に今は問題も出ていないし、ディスク容量も二台合わせて16Gあるので十分なのだが、もうそろそろいつHDDが壊れてもおかしくない年数が経ったので交換することにする。

基本方針はOSの再インストールは行わずに今の構成をそのまま新しいディスク一台にコピーすることである。

現在の物理構成

現在は物理的に以下の様にディスクが繋がっている。

WDCの方にOSが入っており、IBMはデータディスクになっている。

パーテション構成

OSのパーテション構成は以下の通り（CD系は省略)

新たなHDDの取り付けとパーテション切り

既に物理的な記憶装置は４台フルに繋げてしまったので、とりあえずCD-RW(セカンダリ：スレーブ）を外してそこに新しいHDDを繋げることにする。これで、デバイス名はad3になるはず。

続いて/stand/sysinstallの[Configure]-[Fdisk]でad3を選択。FreeBSD用空間を最大限に確保し、MBRの設定も行う。家のマシンは他のOSは入れていないのでStandardを選択する。

ここで一度再起動してから次のステップであるパーテション切りに入る。

再び/stand/sysinstallで[Configure]-[Label]でad3を選択、以下の様にパーテションを切る。newfsもこの場でやってもらう。

再び再起動するか、上のマウントポイントを手動でマウントする。

ファイルのコピー

多分ファイルのコピーはシングルユーザモードでやった方がいいと思います。それかLANケーブルを抜き、できるだけサービスを止めた状態で行ったほうがコピー中の不整合とかなくなっていいと思う。。

コピーはdump&restoreを使用する。以下のコマンドでできるとFreeBSD Q and Aに書いてあった。

コピーが完了したら、/mnt配下の各マウントポイント直下にあるrestoresymtableというファイルを削除する。

fstabの修正

コピーが終わったらコピー先のfstabを修正します。でないとこのディスクで起動しなくなってしまう。
HDD置換後は新しいディスクをプライマリ：マスタに接続するのでデバイス名はad0になるはずです。よって以下の様に修正する。

/dev/ad0s1b             none            swap    sw              0       0
/dev/ad0s1a             /               ufs     rw              1       1
/dev/ad0s1b             /tmp            mfs     rw              2       2
/dev/ad0s1e             /var            ufs     rw              2       2
/dev/ad0s1f             /usr            ufs     rw              2       2
/dev/ad0s1g             /home           ufs     rw              2       2
/dev/ad0s1h             /share          ufs     rw              2       2
/dev/acd0c              /cdrom          cd9660  ro,noauto       0       0
/dev/acd1c              /cdrw           cd9660  ro,noauto       0       0
proc                    /proc           procfs  rw              0       0

ディスク交換＆再起動

古いHDDを二つとも取り外し、新しいHDD(セカンダリ：スレーブ）をプライマリ：マスタに接続して、再起動するとOSが新しいディスクから立ち上がる（はず）。

おわりに

意外と簡単にシステムの移行ができたと思われる。

はじめに

Windowsの共有フォルダをFreeBSDマシンに「バックアップ」する方法について調査しました。

実際はBuffaloのHD-LAN120というNASの共有フォルダをSMBプロトコルを使ってFreeBSDのローカルディスクにバックアップを取ります。

HD-LANはLinux上でsambaが動作しており、コードページはSJISになっています。

結論

mount_smbfsではcpでもtarでもバックアップは取れるけど、書き戻すときに日本語のファイル・フォルダが正常に書き込まれず途中でエラーになってしまうケースが多々あります。

smbtarを使うと正常にバックアップ・リストアができました。

smbtar使用方法

以下の条件の共有フォルダをまとめてFreeBSD上の適当なディレクトリにtar形式で書き込みます。

実行コマンド形式は以下の通りです。

なんとなくパラメータは分かると思います。-vはつけなくても構いませんがこれがあると実行中の状況が画面表示されます。

逆に書き戻す時は以下の形式で実行します。例は\\mimi\degicame\restoreに書き戻す場合です。

(参考)mount_smbfs使用方法

mount_smbfsはWindowsの共有フォルダをFreeBSDのファイルシステムとしてマウントできる便利なコマンドです。

前項の共有フォルダを/backupにマウントする方法を以下に示します。/backupディレクトリは先に作成しておいてください。

-Nオプションはパスワードを聞いてこないようにするものです。パスワードがかかっている共有フォルダの場合はこのオプションを削って、コマンド実行後にパスワードを入力してください。

なお、mount_smbfsはiconvのコード変換ライブラリが組み込まれており、-E SHIFT-JIS:EUC-JPと指定すればFreeBSD上からも日本語のフォルダ・ファイル名が正しく表示されるはずなのですが、家の環境ではコアダンプしてしまいます。

どちらにしても、SJISの共有フォルダをマウントしてコピーしても正常にコピーできない場合があるので使えません。

利用用途しては、FreeBSDのファイルをtar形式でバックアップする時などに使えそうです。

おわりに

もしかしたら、カーネルオプションにLIBICONVが入っていないと、mount_smbfsで-Eオプションが正常に動作しないのかもしれません。また機会があればカーネルを作り直して試してみたいと思います。

はじめに

FreeBSD 4.9RにPostfixの最新版をportsからインストールするための手順について説明します。
本ページでは以下の機能を満たすような設定について紹介します。

• 複数ドメインのメールの送受信を行う
• 全てのメールをリレーではなくローカル配信を行う
• sendmailで言うvirtusertablesを使用した、メールアドレス単位に指定したユーザアカウントに対する配送制御を行う

mailwrapperのシンボリックリンクの確認

FreeBSDに最新のsendmailをportsとかではなく、本家等から落としてきてインストールした場合、/usr/bin/newaliasesがmailwrapperのシンボリックリンクではなくsendmailの実体にリンクされてしまいます。

もし、Postfixで使用するaliasファイルをsendmailと共有するのであれば上記のままで問題ありませんが、どちらにしてもPostfixの設定で変えられるので、FreeBSDのインストール時の状態に戻しておきます。

portsを最新にする

今回Postfixはportsからインストールします。現時点の最新版のソースを取得するために、/usr/ports配下を最新にしておきます。
以下のファイルを適当なディレクトリに作成し、cvsup filenameで更新作業を行います。cvsupがインストールされていない場合には先ずパッケージからcvsupパッケージをインストールしてください。この作業方法については割愛します。

私が落としてきた時は「postfix-2.0.16.20031223,2」でした。これをベースに説明しますが、これより新しくても基本的には同じ設定でいけると思います。

専用ユーザIDとグループの作成

portsからPostfixをインストールする前に専用のユーザIDとグループを作成しましょう。portsのinstall時に自動的にユーザを作成する事も出来ますが、UID,GIDが大きい番号(一般ユーザと同じ系列の番号)になってしまい、私は気に入らないので事前に作成しました。
ユーザIDはvipwで、グループIDは適当なエディタで作成します。

mailer.confの退避

これも、portsからPostfixをインストール時に/etc/mail/mailer.confを上書きする前にバックアップファイルを作成してくれますが、一応分かりやすい名前でsendmail用の設定を保存する意味でバックアップを取っておきます。

sendmailデーモンの停止

そろそろsendmailを停止しましょう。これから暫くはメールの送受信は行えないのでご注意を。
まずは現在動作中のsendmailを以下のコマンドで停止します。

続いて、/etc/rc.confのsendmail_enableの行を以下のように修正します

Postfixのビルド、インストール

/usr/ports/mail/postfix-currentに移動してmakeを実行します。

最初にコンパイルオプションで色々選択項目が出ますが、特に何も指定せずにOKで大丈夫です。

コンパイルが終了したらmake installでインストールします。
インストール時に/etc/mailer.confを設定するか聞いてきますが、これはYESでもNOでもいいです。後で説明します。

インストールディレクトリは以下のようになっています。

mailer.confの設定

/etc/mail/mailerconfを以下の様に設定します。

一応このファイルを/etc/mail/mailer.conf.postfixにもコピーしておきましょう。後々MTAをsendmailに戻すときに楽です。

postfixの基本設定(main.cf)

/usr/local/etc/postfix/main.cfの設定を行います。今回の設定例は以下の条件で行っています。

• 基本となるドメイン名はhijiki.net
• 本サーバでxxx@hijiki.netのメールを受け取る
• ローカルホスト用のDNSサーバは運用していない
• 他にyotan.homeunix.net宛のメールも受け取る
• docomo宛のメールはプロバイダのMTAにリレーする
• メールアドレス毎にローカル配送するアカウントを指定する(virtual機能)

以下にmain.cfの設定例を示します。設定内容がよく分かっていないものはコメントがありません汗

Postfixのvirtual設定(virtual)

複数ドメインを受信できるようにmain.cfを設定したので、それぞれのドメイン毎のメールアドレスをローカルアカウントのどれで受信するか振り分ける設定をします。

設定ファイルは/usr/local/etc/postfix/virtualです。書式は一行目が「ドメイン名 適当な文字列」となって、二行目以降にそのドメイン内のメールアドレスの一覧を「メールアドレス アカウント名」で指定します。次のドメインを設定する時には再び一行目に書いた記述から始めます。

上記の例ではローカルアカウントがuser1,user2とあり、それぞれにメールを割り振っています。

注意点として、以下の設定のように、基本ドメインのメールアドレスの@よりも前の部分と、ローカルアカウント名が同一だとうまく振り分けが行えません。これは一度virtualテーブルで変換した振り分け先のアドレスを更にvirtualテーブルを参照して(基本ドメイン名を付与した上で)更に振り分け処理を行うためと思われます。

上記設定で、yotan@yotan.homeunix.netにメールを送ると、yotanに届かずに、user1にメールが届きます。この点がsendmailと違うのでローカルアカウント名を追加して振り分け設定を行う際は注意してください。

さて、virtualファイルの作成が終わったら、main.cfでhash指定をしているので以下のコマンドでハッシュテーブルの作成を行います。

一応/usr/local/etc/postfix/virtual.dbが作成されているのを確認しましょう。

Postfixの転送設定(transport)

docomo.ne.jp宛のメールは有名どころのMTAからのメールしか受信できない場合があります。これはSPAMメール撲滅の為にDoCoMoがやっている処置です。

自前のMTAから直接docomo.ne.jpに送っても届かない事があるので、自分が加入しているプロバイダに一度転送して、そっちから送ってもらうとうまくいく場合が多いです。

main.cfでtransport設定をしたので、/usr/local/etc/postfix/transportファイルを以下の様に設定します。

ファイルの作成が済んだらpostmapを実行します

transport.dbが作成されるのを確認します。

Postfixのaliases設定(aliases)

main.cfでaliasesを/usr/local/etc/postfix/aliasesを使用するように指定した場合、既にsendmail時代に/etc/aliases(/etc/mail/aliases)で追加した行をコピーしてきます。

また、root宛のメールは普段自分が受信するアカウントに転送指定をしましょう。

もし、/etc/aliasesをそのまま使う際には以下の行を加えておきましょう。

aliasesのハッシュテーブルの作成はsendmailと同じでnewaliasesです。これはpostfixに入ってたものでも、sendmailのnewaliasesでも同じ処理を行います。

Postfixの起動

さて、いよいよ起動です。以下のコマンドで起動します。

無事起動したら色々メールの送受信を試して確認します。

main.cfを修正したり、各種ハッシュテーブルの更新を即時行いたいときには以下のコマンドでPostfixをリロードします。

起動スクリプトの作成

システム起動時に自動的にPostfixが起動するようにスクリプトを書きます。
スクリプトは/usr/local/etc/rc.d配下に実行属性をつけて保存します。

おわりに

簡単ですが、FreeBSDに特化したPostfixの設定例を示しました。
家庭内サーバを外部に公開している場合で複数ドメインを持っている方には有用な資料ではないかと思います。
インストールディレクトリや起動スクリプト等の部分を除けば、Linuxでも基本は同じですので参考になるかと思います。