logwatchについてるpostfixのスクリプトをちょっと直してみた

logwatchでpostfixのログをパースさせてたんですが、最近Unmatched Entriesが増えてきたので、
Unmatchedを減らすべく、既存のフィルタを改造してみました。

対象にしたのはこれ。

# rpm -q logwatch
logwatch-7.3-9.el5_6
オリジナルを直接触るのは気が引けるので、ローカル用にコピーします。
# cp -p /usr/share/logwatch/scripts/services/postfix /etc/logwatch/scripts/services/
# vi /etc/logwatch/scripts/services/postfix
というわけで、オリジナル版のフィルタとdiffを取ってみました。

# diff -u /usr/share/logwatch/scripts/services/postfix /etc/logwatch/scripts/services/postfix
--- /usr/share/logwatch/scripts/services/postfix     2011-03-31 06:57:37.000000000 +0900
+++ /etc/logwatch/scripts/services/postfix     2013-03-02 10:37:16.000000000 +0900
@@ -224,7 +224,7 @@
    } elsif (($User) = ($ThisLine =~ /^[a-zA-Z0-9]+: to=\<([^ ]*)>,(?: orig_to=\<(?:[^ ]*)>,)? .*, status=bounced .*: User unknown in virtual (alias|mailbox) table/)) {
       # another unknown user probably could combine with local unknown but again my perl is weak
       $UnknownUsers{$User}++;
-   } elsif (($Dest, $Relay, $Msg) = ($ThisLine =~ /^[a-zA-Z0-9]+: to=\<([^ ]*)>,(?: orig_to=\<(?:[^ ]*)>,)? relay=([^ ]*).*, delay=-?[0-9]+, status=bounced \(([^)]*)/ )) {
+   } elsif (($Dest, $Relay, $Msg) = ($ThisLine =~ /^[a-zA-Z0-9]+: to=\<([^ ]*)>,(?: orig_to=\<(?:[^ ]*)>,)? relay=([^ ]*).*, delay=[^ ]*,(?: delays=[^ ]*,)?(?: dsn=[^ ]*,)? status=bounced \(([^)]*)/ )) {
       # unknown user
       # $Msg = " hello "
       # print "bounce message from " . $Dest . " msg : " . $Relay . "\n";
@@ -394,6 +394,10 @@
       $UnknownWarnings{$Warn}++;
    } elsif (($Host,$Filter) = ($ThisLine =~ /RCPT from ([^ ]*\[[^ ]*\]): <[^ ]*\[[^ ]*\]>: Client host triggers FILTER (\S*)/)) {
       $HostTrigFilter{"$Host,$Filter"}++;
+   } elsif ( ($Server, $Helo) = ($ThisLine =~ /^NOQUEUE: reject: RCPT from ([^ ]*\[[^ ]*\]): 450 4.7.1 Client host rejected: cannot find your hostname, [^ ]*; from=<[^ ]*> to=<[^ ]*> proto=[^ ]* helo=<([^ ]*)>$/)) {
+      $InvalidClientHostName{"$Server"}++;
+   } elsif ( ($Server, $Helo) = ($ThisLine =~ /^NOQUEUE: reject: RCPT from ([^ ]*\[[^ ]*\]): 504 5.5.2 <[^ ]*>: Helo command rejected: need fully-qualified hostname; from=<[^ ]*> to=<[^ ]*> proto=[^ ]* helo=<([^ ]*)>$/)) {
+      $InvalidHeloName{"RCPT from $Server: HELO=$Helo"}++;
    } else {
       push @OtherList,$ThisLine;
    }
@@ -691,6 +695,40 @@
    }
 }

+if (keys %InvalidClientHostName) {
+   if($Detail >= 5) {
+      print "\n\nInvalid client hostname:\n";
+      foreach $Message (sort {$a cmp $b} keys %InvalidClientHostName) {
+         print "   $Message: $InvalidClientHostName{$Message} Time(s)\n";
+      }
+   }
+   else {
+      $n=0;
+      $mn=scalar(keys %InvalidClientHostName);
+      foreach $Message (keys %InvalidClientHostName) {
+         $n+=$InvalidClientHostName{$Message};
+      }
+      print "\n\nInvalid client hostname:\n: $mn Message(s), $n Time(s)";
+   }
+}
+
+if (keys %InvalidHeloName) {
+   if($Detail >= 5) {
+      print "\n\nInvalid HELO command:\n";
+      foreach $Message (sort {$a cmp $b} keys %InvalidHeloName) {
+         print "   $Message: $InvalidHeloName{$Message} Time(s)\n";
+      }
+   }
+   else {
+      $n=0;
+      $mn=scalar(keys %InvalidHeloName);
+      foreach $Message (keys %InvalidHeloName) {
+         $n+=$InvalidHeloName{$Message};
+      }
+      print "\n\nInvalid HELO command:\n: $mn Message(s), $n Time(s)";
+   }
+}
+
 if (keys %LocalBounce) {
    if ($Detail >= 5) {
       print "\n\nLocal Bounce:\n";
各chunkのコメントです。
1つめ
bounceした記録の書式が多少変わっていたので、オリジナルの機能を失わないように正規表現を書き足してみました。
2つめ
postfixで下記の設定をした時に出るエラーに対応してみました。
  smtpd_client_restrictions = reject_unknown_client
  smtpd_helo_restrictions = reject_non_fqdn_hostname
3つめ
2つめでマッチしたログの出力部分です。

/etc/logwatch配下に置いたスクリプトは標準のスクリプトに優先して使われるようで、
期待通りの動作となりました。

OpenLDAP2.4での設定スキームの移行

「そういえばdebianも6になったし、家のサーバも上げるか」という軽い気持ちで踏み出したdebian6。 ログをちゃんと確認しなかった自分が悪いんですが、後で見てみるとopenldapが2.3から2.4ベースに変わってる。 それよりも何よりもこのslapd.dディレクトリってなんじゃ？ってことになったので、軽く調べてみると.....。

OpenLDAP Software 2.4 Administorator's Guide: Configuring slapd

The older style slapd.conf(5) file is still supported, but its use is deprecated and support for it will be withdrawn in a future OpenLDAP release.

これまでのslapd.conf(5)形式のファイルは引き続きサポートされますが、この形式の利用は推奨されず、今後のOpenLDAPのリリースの中でいずれサポートされなくなる予定です。

がーん。slapd.conf使えなくなるんか。
これはslapd.confの保険があるうちにslapd-config(5)での設定変更方法を学んでおかなくちゃならんな。

上記ページのセクション5.1に設定用ツリーの概略が書いてあります。ってさらっと書いてあるけど、自分は実際の入っている状態を見てさわらないと理解できないおこちゃまなので、触ってみてはじめて意味が分かりました。
普段利用するdcである「dc=example,dc=com」の配下ではなく、これと独立した「cn=config」をトップとするツリーが生成・利用されるようです。

ここで疑問。「/etc/ldap/slapd.d配下にあるファイルは自分でインポートする用のテンプレートなのか？」
というわけでいろいろ試してみましたよ。

# ldapadd -x -W -D cn=admin,dc=example,dc=com -f cn\=config.ldif
Result: Insufficient access (50)

# ldapadd -x -W -D cn=config,cn=admin,dc=example,dc=com -f cn\=config.ldif

ldap_bind: Invalid credentials (49)
# ldapadd -x -W -D cn=config,cn=admin -f cn\=config.ldif

ldap_bind: Invalid credentials (49)
# ldapadd -x -W -D cn=config -f cn\=config.ldif

ldap_bind: Invalid credentials (49)

無理じゃん。どんなやったって入んないじゃん。
もう一度ドキュメントを読んでみるか。
slapd.d配下のファイルは手で直接いじるな....ですか。
ということは、net-snmpにおける/var/lib/net-snmp/snmpd.confと似たイメージで、メモリ上に保持されている各種設定の退避・保存先として使われるってことなのかな。
 もひとつ。-Fオプションと-fオプションについて。

1. -fオプションのみの場合、slapd.confを使って動作してくれる。
2. -Fオプションのみの場合、slapd.d配下の構成を使って動作してくれる。
3. -fオプションと-Fオプションを併用した場合、slapd.confを使って動作し、その状態をもとにしてslapd.d配下を構築してくれる。

お。3つめがいい感じ。debianだと、/etc/default/slapdのSLAPD_CONFを空にしておくと、初期値で/etc/ldap/slapd.confを使ってくれます。また、SLAPD_CONFを設定した場合、slapd.confを与えると勝手に-fオプションで、slapd.dを与えると勝手に-Fオプションで起動してくれるようです。
ただ、3つめをやるには、上記の「SLAPD_CONFが空の場合」のロジックに乗っかりつつ、SLAPD_OPTIONSで「-F /etc/ldap/slapd.d」とするのが良さそう。ひとまずは下記のような感じで起動してみましょう。

vi /etc/default/slapd

SLAPD_CONF=

SLAPD_OPTIONS="-F /etc/ldap/slapd.d"

ちゃんと起動したようです。

 4195 ?        Ssl    0:00 /usr/sbin/slapd -g openldap -u openldap -f /etc/ldap/slapd.conf -F /etc/ldap/slapd.d

この状態になったはいいけど.....まだslapd.confから離れられない。。。そもそもcn=configのツリーはどうやって見るんだ？？

で、いろいろ調べてみた結果、下記のpostが参考になりました。

http://serverfault.com/questions/272125/how-do-i-install-a-new-schema-for-openldap-on-debian-5-with-dynamic-config-cn-ba

「slapd.d/cn=config/olcDatabase{0}=config.ldif にolcRootPWを追加して起動しろ」って言ってますね。やってみました。

vi slapd.d/cn=config/olcDatabase{0}=config.ldif

olcRootPW: haraheriherihara

/etc/init.d/slapd restart

ちゃんと読めました！！！やっとconfigがいじれるようになりました！！！




で、この記事を書きながら当初のAdministrator's Guideを読み直していると、こんな記述が。。。。。

5.4. Converting old style slapd.conf(5) file to cn=config format

Before converting to the cn=config format you should make sure that the config backend is properly configured in your existing config file. While the config backend is always present inside slapd, by default it is only accessible by its rootDN, and there are no default credentials assigned so unless you explicitly configure a means to authenticate to it, it will be unusable.

cn=configフォーマットへの変換を行う前に、既存の適切な設定ファイルに対してconfigバックエンドの設定をする必要があります。configバックエンドはslapdの内部で常に存在していますが、初期設定ではrootDNでしかアクセスできず、初期クレデンシャルもないため、明示的に設定しない限り利用できません。

If you do not already have a database config section, add something like this to the end of slapd.conf
database config
rootpw VerySecret

利用中の設定ファイルにまだdatabase configセクションを追加していないなら、下記のような行をslapd.confの末尾に追加してみてください。
database config
rootpw VerySecret

な、なんだってー！ちゃんと移行方法が書いてあるじゃないか！
というわけで試してみました。
  
lennyで新規にslapdを導入すると、2.4ベースではあるものの、設定パターンは2.3を踏襲するため、slapd.confベースになっています。この状態から、適当にいくつかエントリを作成し、slapcatでも見えることを確認しておきます。エントリの作成にはphpLdapAdminを使いました。検証用のエントリなので手抜きも重要。

apt-get -y install slapd phpldapadmin

slapcat

つづいて、設定の移行をしてみます。slapd.dディレクトリ自体は作らないとダメなんですね。

/etc/init.d/slapd stop

mkdir /etc/ldap/slapd.d

chown openldap:openldap /etc/ldap/slapd.d

chmod 700 /etc/ldap/slapd.d

echo database config &gt;&gt;etc/ldap/slapd.conf

echo -n "rootpw " &gt;&gt;/etc/ldap/slapd.conf

slappasswd &gt;&gt;/etc/ldap/slapd.conf
New password:

Re-enter new password:

そして起動。ちゃんとslapd.d配下に設定が展開されているのが確認できます。

/etc/init.d/slapd start

この状態でldapsearchを実行。ちゃんと見えましたね。

ldapsearch -x -w haraheriherihara -D cn=config -b cn=config -s base

Enter LDAP Password:

ここまでくればしめたもんです。slapd.confからslapd.dへの完全移行の後始末をしましょう。

mv /etc/ldap/slapd.conf /etc/ldap/slapd.conf.old

vi /etc/default/slapd

SLAPD_CONF=/etc/ldap/slapd.d

SLAPD_OPTIONS=""

/etc/init.d/slapd restart

ちゃんと動きましたか？

PHPでpost_max_size以上のデータを投げても何とかハンドリングしたい

最近phpコードを書いているんですが、post_max_size以上のデータを受け取ると

PHP Warning: POST Content-Length of 9456137 bytes exceeds the limit of 8388608 bytes in Unknown on line 0

なんてエラーを吐いてくれてエラーチェックができないんです。
対策はいくつか考えたんですが、

apacheのLimitRequestBodyを使う

コンテンツを配置するたびにapacheの設定を書くのが面倒だし確実に忘れる。AllowOverrideも環境依存だし。。

javascriptで制御

所詮クライアントサイドの気休めでしかないので信頼性低い。

MAX_UPLOAD_SIZEをhiddenで埋め込む

これも気休め。

と、どれもイマイチ決定打に欠けます。

実際にpost_max_size以上のデータを受け取ったとき、$_POSTのデータが破壊されるのか変数として提供することをあきらめるのかはわかりませんが、$_POSTの中身が空になるので、これを検知しちゃえばいいんじゃね？
ということで、意図的にエラーを発生させて観察してみました。その結果、post_max_size以上のデータを受け取ると、$_POST、$_FILESの両方とも、isset()にかけるとtrueが返されますがcount()で見ると空っぽなんですね。
これを受けて、下記のようなコードで逃げてみました。

// max_post_size越えのデータを受信した場合の対策
if(count($_POST) == 0 && count($_FILES) == 0)
{
死に際のエラー処理
exit();
}

本来はPHP側が正しくハンドリングしてくれればいいんですが、どうもこの辺のチェックが甘いようで、逃げの手法だということは知りつつもこの方法で決定。期待した動作になりました。

ちなみに、cent5系でふつうにインストールされるrpmなphpです。

# php -v
PHP 5.1.6 (cli) (built: Mar 31 2010 02:44:37)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies


iTunesの"牛丼肉抜き"

(複数所有している)どのパソコンでもiPhoneは認識させたいけど、iTunesのデータは特定のマシンにしか入れていない方へ。
iTunesデータを持たせていないPCでiPhoneを充電したりすると、期待もしてないiTunesが上がってきたりしてジャマだったりしませんか？
人のiPhoneを挿したら同期が始まって慌てて止めてたりしませんか？

そんな時におススメなのが「iTunesの"牛丼肉抜き"」。
「ドライバやbonjourは入ってるけどiTunesは入ってない」状態を作ることで、iPhoneとして認識はするけどiTunesに反応しないPCにすることができます。
やりかたは簡単。
一度iTunesをインストールした後で、「iTunesだけをアンインストール」するんです。

iTunesをインストールすると、下記のものがまとめてインストールされます。
・Apple Application Support
・Apple Mobile Device Support
・Apple Software Update
・Bonjour
・iTunes
・QuickTime
なので、ここから「iTunes」だけをアンインストールすると、他のパッケージが残るというカラクリ。

Apple Mobile Device Supportは、iPhoneを使う時のWindows向けドライバを持っているので、本当に最小であればそれだけ残して後は削除、というのもありですが、自分のパソコンでは上記からiTunesを抜いただけになっています。

あ、共有パソコンだと肉抜きは難しいかもしれませんね。

Intel Active Management Technologyを使ってみた

kvmの実験用に購入したIntelのDQ45CBですが、搭載されているQ45チップセットがvProに対応しています。このvProを使用することで、外出先からパソコンの電源制御やBIOS操作ができるとあるので、試してみることにしました。
今回試すのは、Intel Management Engineを設定し、外部から電源制御を行えるようにすることです。


では、まずハードウェア側の準備から始めましょう。やることは下記の3つです。
(1)Management Engineを有効にする(現在の設定が無効になっている場合)
(2)パスワードの設定
初期パスワードが設定されていますが、初期パスワードはみんな書くのを遠慮しているので、自分で調べるか知っている人(最終的にはIntelの人？)に聞いてみて下さい。ちなみに、今回は自分自身で調べてみました。調べると出てくるものです。また、パスワードの強度についてですが、(1)英字/数字/記号を含む、(2)8文字以上であること、が条件なので、忘れないようにしましょうね！
(3)ネットワーク設定
DHCPのままでも後で見つけられるのですが、安定的な管理のためには固定IPにした方が良いでしょう。あと、外部から接続するときのためにゲートウェイは忘れずに! LAN内からしか繋がないのなら、少し歩いて自分で電源ボタン押しにいけばいいでしょ(ぉ
(4)その他の設定
ある場合とない場合があるので、都度説明します。

では具体的な手順についてです。

F2を押してBIOSに入り、メニューから「Intel(R) ME」を選択しましょう。
設定画面に入るときにパスワードを設定します。
パスワードの設定が終わると、メニューに入れるようになります。

続いて、「Intel(R) Active Management Technology Configuration」のメニューからネットワークを設定します。
追加の設定ですが、プロビジョニングの設定を行いましょう。
同じ階層に「Provisioning Configuration」というメニューがあります。
「Enterprise」となっているところを、「Small-Medium Business」に変えておきます。
この状態でBIOSを保存しましょう。

ここまでできたら、ハードウェア側の準備は完了です。
あとのお楽しみのために、一度電源を落としておきましょう。

続いて、Intel AMT Developer Tool Kitを以下のURLからダウンロードします。

Download the latest version of Manageability Developer Tool Kit
http://software.intel.com/en-us/articles/download-the-latest-version-of-manageability-developer-tool-kit

ダウンロードしたMSIをインストールすると、下記の3つのプログラムが入ります。
・Manageability Commader Tool
・Manageability Connector Tool
・Manageability Outpost Tool
ここでは、このうち"Manageability Commader Tool"というプログラムを利用します。

で、起動したのがこの画面。

さっき登録したIPアドレスとパスワードを利用して、このツールに登録します。
IPアドレスをDHCPで取得させる場合は接続先IPが分からないので、DHCPのスコープを入力してStartを押しましょう。
たぶん出てきます(笑)

追加が完了したら、左ペインに現れたマシンをクリックすると、右ペインが「Connect & Control」というウィンドウに変わります。
さっそく接続してみましょう。Connectボタンを押してみます。

つながったよ兄さん！！

さっそくツリーの中を見てみます。資産情報からハードウェア情報までちゃんと見えてます。

さて、今回のお目当て、リモート制御機能です。
タブを「Remote Control」に切り替えます。

そこに現れた「Take Control」というボタンを押すと、Serial Over LANで画面制御ができるようになります。
画面を良くみると、「IDE Redirect」という項目が表示されており、その脇にイメージファイルが指定されていることから、
うまく使えばリモートでのインストールだってできそうですね。

とりあえず立ち上げてみましょう。
「Remote Command」のメニューから「Remote Reboot to BIOS Setup」を選んでみます。
なぜ普通に起動しないかって？そりゃ一番分かりやすいからですよ(笑)
右上に表示されていた状態がSoft off(S5)からFull Power(S0)に変わり、しばらく待つとちゃんとBIOSの画面になりました。
Serial over LANなので、画面レンダリングが昔のパソコン通信を見ているようです。

外出先から自宅にVPNが張れれば、あとはほぼ思いのままです。

Thunderbirdがすごい。だけど.....

少し前にうちのメールをIMAP化し、昔使っていた別のメールクライアントのメールを取り込むべくインポートをやっていたわけなんですが、 Thunderbird、すごいですね。メールボックスをまたいでメッセージを移動できるし、移動元がPOPで移動先がIMAPだとアップロードまでしてくれます。これで、iPhoneからでも会社からでも自分の家でも全部同じメールが見られる～

と思っていたら、どうもメールの表示順序がおかしいのです。メールヘッダにあるタイムスタンプは確かに維持されているんだけど、表示順序が「Thunderbirdに取り込まれた順」になっている。昨日のメールよりも新しい位置にインポートしたメールがあるわけで、iPhoneで見るときに「最新の100通」を見るとインポートしたメールで埋まってる.....これでは使い物になりません。

で、調べてみると、IMAPサーバに保存されているメッセージのファイル名が「インポートしたときのUNIX秒」になっているっぽい.....これを直せばどうにかなるかな。

というわけで、こんなスクリプトを組みます。要は、各メッセージのファイル名に入っているUNIX秒を、Dateヘッダが示すUNIX秒に差し替えてリネームするわけです。


#!/bin/sh

cd ~
for dir in `find ~/Maildir -type d -name cur`; do
cd $dir
pwd
for file in `ls`; do
dater="`grep ^Date: $file | head -1 | sed -e 's/^Date://; s/ (JST)$//; s/Thr/Thu/'`"
dates=`date -d "$dater" +%s`
new=`echo $dates@$file | sed -e 's/@[1-9][0-9]*\././'`
echo -n "$file -> $new : "
if [ "$file" = "$new" ]; then
echo not renamed.
else
mv -i $file $new
echo renamed.
fi
done
done


コツをいくつか。
・Maildir形式での各メッセージは確実にユニークなファイル名を持つようになっているので、1ファイルずつ処理できます。ファイル名の命名規則については下記で解説されています。
http://cr.yp.to/proto/maildir.html
・head -1が入っているのは、マルチパートのメールとかだとDateヘッダが複数入っているので、一番最初のだけを持ってくる必要があるからです。他の言語を使えばオブジェクトで扱えるのですが、そこまでは要求していないのでこれで十分。
・ThrをThuに変えているのは、dateコマンドのフォーマットとして認識してくれないからです。メールソフトの中には、木曜日の短縮形をThuではなくThrで記述するものもあるみたいですね。

もちろんここにくるまでにちゃんとデバッグしてますよ。mvだけコメントアウトしておけば何度でもプレビューできるので便利です。ついでに、テスト実行時には標準出力「だけ」を捨てておくと、エラーの有無がわかりやすくて便利です。こういうとき、標準エラー出力って便利だな、と思います。

で、imapのサービスを止めて、いざ実行！

Thunderbirdを立ち上げてみると....お！うまくいってる！
しかしログにこんな記述が！
「△△△フォルダから0000通のメールを削除しました」....えええ！！！！

よく見ると、ローカルのメール(実質的なキャッシュ)をリモートフォルダ(つまりIMAP上のオリジナルメール)に合わせている挙動でした。リモートのメールが消されているものと勘違い(汗

改めてiPhoneから見てみたところ、期待したとおりに表示されているようです。

電話番号パターン認識

こんなモジュールがあるんだー。
http://perldoc.jp/docs/modules/Number-Phone-JP-0.03/JP.pod

rsyslogのタイムスタンプ

しばらく前にsyslogをrsyslogに置き換えて運用していたんですが、そのせいでawstatsがまともに動かなくなっていたようです。

普通のログだとタイムスタンプが

MMM DD hh:mm:ss

とかになってるんですが、rsyslogがタイムスタンプの標準(?)が

YYYY-MM-DDThh:mm:ss:uuuuuu[+-]zz:zz

になってるみたい。

解除するには、rsyslog.confの各ログの書式に「;RSYSLOG_TraditionalFormat」をつければ良いそうで。
サンプルをば。

mail.* /var/log/maillog

を

mail.* /var/log/maillog;RSYSLOG_TraditionarFormat

とする。

でも、高精度タイムスタンプが使えるんならその方がいいなぁ。
何とかしてawstatsに食わせるために、

sed -e 's/^\([0-9][0-9]*-[0-9][0-9]-[0-9][0-9]\)T\([0-2][0-9]:[0-5][0-9]:[0-5][0-9]\)\.[0-9]*[+-][0-9][0-9]:[0-9][0-9]/\1 \2/g'

なんて小賢しいフィルタも考えてみたんだけど、maillogconvert.plがうんともすんとも言わない。


さて、どうしたものか.....

携帯宛のメールが届かない？

友達から「MLに送ったメールが1通だけ届かない」なんてメールがきた。
ログを見てみると、確かにその時間帯に着信したメールがその友達「だけ」に送信されていない。
.....なんでだ？

とりあえず分からないので、postfixをいじってみた。

main.cfに追記

transport_maps = hash:/etc/postfix/transport


transportを作成、ハッシュ化

softbank.ne.jp smtp-softbank:
ezweb.ne.jp smtp-ezweb:
docomo.ne.jp smtp-docomo:


master.cfにカスタムトランスポートを追加

smtp-softbank unix - - n - 1 smtp
-o smtp_destination_concurrency_limit=1
smtp-ezweb unix - - n - 1 smtp
-o smtp_destination_concurrency_limit=1
smtp-docomo unix - - n - 1 smtp
-o smtp_destination_concurrency_limit=1


とりあえず様子を見てみましょ。

DNSサーバ、そしてお手軽セカンダリDNS

いままで会社のやつに滑り込ませていたので、ちょっと申し訳ない感じがありましたが、やっとDNSを自前運用にしました。
これでDNS/web/mailが全て自前運用になったので、やっと次のステップに進めそうです。

やったこと。
1.使っているサーバ)Centベース)にbindとbind-chrootを入れる
2./var/named/chroot/etc/named.confを編集
2-1.internalセクションの中は全部コメントアウト
2-2.keyセクションもコメントアウト(次の機会にでもいじる予定)
3.sampleディレクトリにあるnamed.*を/var/named/chroot/var/named/にコピー
4.ゾーンファイルを/var/named/chroot/var/namedに作成(命名はドメイン名.zone)
5./var/named/chroot/etc/named.confを編集
さっき作ったゾーンの設定を追記
6.起動！

ちなみに、利用しているお名前.comだと、セカンダリDNSサービスってのがあります。これはラクでいいですね。しかも、自分が利用しているサーバと全く管理形態が異なるので、同時に落ちる心配もほぼ皆無といっていいでしょうし。自分で2台もDNSサーバが用意できない方にオススメ。
ドメインNaviの手順に従って設定し、最後にネームサーバを変更して無事完了です。

というわけで、次は「完全手動ダイナミックDNS」を「ちゃんとしたダイナミックDNS」にしようと思います。