APNICのIPv4 rangesは日々変更されているので、なんとか自動化したいなぁ〜と思っていたのですが、自動化するにはＪＰＮＩＣの管理しているＩＰアドレスを捨てないといけません。
（※ＡＰＮＩＣとＪＰＮＩＣで重複しているものを最後は目視で確認しないとＷａｒｎｉｎｇがでまくって大変なことになるからです。）
そこでＡＰＮＩＣとＪＰＮＩＣそれぞれが管理している日本のＩＰアドレスはどのくらいあるのかざっと見てみたところ、9割以上は重複していたので、この際だからＪＰＮＩＣは捨てよう！と決めたわけです。
最初に私が作成したipv4Jp.zipに同封されているclient_cidrはＡＰＮＩＣとＪＰＮＩＣをまとめたものなのですが、ＡＰＮＩＣのみで作成したものとの差があまり無かったのです。
東京大学のＩＰはＪＰＮＩＣのみでしか管理されていないようですが、client_cidrの定義はＲＥＪＥＣＴではなくＯＫなので仮に漏れたホストがあっても、逆引き設定等が正しく行われていれば無問題な訳で、且つ450で再送要求しているのでまぁ〜大丈夫なんじゃなかろうかという自宅サーバーならではの強気設定です(゜Д゜)
すでに導入して2週間経っているので大丈夫でしょう！・・・たぶん・・・(゜Д゜)
で、自動更新するにあたって、私は今までaccessテーブルを更新したら毎回Postfixをreloadしていたのですが、Postfix 検索テーブルの概要を読むと、reloadすべきなのかそうでないのかが、どうもはっきりしません。
で、試しに書いてあるとおり
> postmap access.in
> mv access.in.db access.db
を実行してみたらmaillogに大量のWarningがでましたよ！？(゜Д゜;)
（postmapのマニュアルより引用）
——————————————————————————
テーブルの更新中は、シグナル配送は遅延され、検索に来たプログラムを驚 か
せないために、排他的 Advisory ロックがテーブル全体にかけられます。
——————————————————————————
ということなので、cidr_tableの自動更新スクリプトはclient_cidrのバックアップをとってそのまま上書きしてpotmapを実行しています。
cidr_tableの自動更新をしてみたいという方は既にPostfixのスパムメール対策(排除率は99.975%だった)の方も更新しているので、一度読んでみてください。
« 閉じる