「BIND」と一致するもの

自宅サーバ更新(3)

前回の続き。

HBAというかRaidカードの部分ですが、型落ち(世代前の製品)が安く手に入るようになってきたので、ハードウェアRAIDカードを使う方針です。


色々検討はしたのですが、
  • HDDケースでRAID機能を搭載している製品を使う
  • ESXiのゲストOSにFreeNASを載せて、パススルーでHDDに直接アクセスさせる。その上で、ソフトウェアRAIDを組んでiSCSIまたはNFSでESXiにストレージを見せる方法
  • ハードウェアRAIDカードを搭載する方法
  • ゲストOSの中でRAIDを組む

さて、どれが良いのでしょうか。

bindのゾーン委任

明けましておめでとうございます。

年始早々くだらないことでハマってしまったので。

ラボ環境を作って内部だけのDNSゾーンを作ろうとしていたところ、bind9.10.3でゾーン委任がうまく動かない。

ラボ環境のDNSドメインをlab.localとして
委任する側のzoneファイル

$TTL 60
@ IN SOA local. root.local. (
1000 ; Serial
600 ; Refresh
120 ; Retry
600 ; Expire
60 ) ; Negative Cache TTL
;
@ IN NS ns.local.
@ IN A 10.0.1.1
ns IN A 10.0.1.1

lab.local. IN NS ns.lab.local.
ns.lab.local. IN A 10.1.1.1
委任される側のzoneファイル
$TTL 60
@ IN SOA lab.local root.ns.lab.local (
10 ; Serial
300 ; Refresh
300 ; Retry
300 ; Expire
60 ) ; Negative Cache TTL
;
@ IN NS ns.lab.local.
@ IN MX 10 ns.lab.local.
@ IN A 10.1.1.1
ns IN A 10.1.1.1

普通にサブドメインのゾーン委任しているだけなのに動かない・・・

と思ったのですが、委任する側のDNSサーバにクエリを投げると、上位側のDNSサーバがforwardersで指定したサーバに聞きに行っていることがわかりました。
サブドメインだから検索するときに先にforwardersで指定したサーバを見に行ってしまうことがアカンのかと思って、STUBゾーンにいてみたりしましたが意味なし。

zone "lab.local" {

type stub;
masters { 10.1.1.1; };
file "db.lab.local.stub";
};

結局、サブドメインのゾーンをforwardしない設定にしてあげると、ゾーンファイル側を見てくれるようになりました。

zone "lab.local" {

type stub;
masters { 10.1.1.1; };
file "db.lab.local.stub";
forwarders {};

};

結論:サブドメインをStubで定義して、forwarders {};を入れておく。

尤も、サブドメインを委任するということは通常その上位のドメインの権威あるサーバということですから、フォワードしないというか自身の持っているゾーン以外の問い合わせに応答させることはないはず。ですので特に問題にならないかと思うのですが、今回の場合あくまでラボ環境ですので外部へのクエリをフォワードする役割と、ゾーンを持っているサーバを兼務させていることが事の原因かと。

JuniperSRX DHCPサーバが動作しない

JuniperSRXのDHCPサーバがうまく動作しなくて、他にDHCPサーバを立てる事で逃げていたのですが、上手く動作させることが出来たようです。

  • Juniper SRX210H - Junos 11.4 R4.4で、ソースルートを書くと複雑になってしまうので、複数routing-instanceを立ててVlan毎にルーティングを別々に制御している。
  • SRXのデフォルトインスタンスにDHCP serverを動作させたが、クライアントからDHCPでIPアドレスを取得できない
ge-0/0/1インターフェースにTrustゾーンに属する192.168.100.0/24のネットワーク(routing-instanceはデフォルトインスタンスに属する)を作って、SRXをDHCPサーバをしたいので
SRX Getting Started - Configure DHCP Serverに書いてあるとおり、
user@host# set system services dhcp pool 192.168.100.0/24 address-range low 192.168.100.33
user@host# set system services dhcp pool 192.168.100.0/24 address-range high 192.168.100.64
user@host# set system services dhcp pool 192.168.100.0/24 domain-name example.net
user@host# set system services dhcp pool 192.168.100.0/24 name-server 192.168.100.2
user@host# set system services dhcp pool 192.168.100.0/24 router 192.168.100.1
user@host# set system services dhcp pool 192.168.100.0/24 default-lease-time 3600
user@host# set security zones security-zone trust interfaces ge-0/0/1.0 host-inbound-traffic system-services dhcp
user@host# set interfaces ge-0/0/1 unit 0 family inet address 192.168.100.1/24
user@host# commit and-quit
としたのですが、クライアントにIPアドレスは割り当てされなくて
user@host> show syster services dhcp binding
    (なにも表示されない)
user@host> 
という状態に・・・。色々調べたのですが、host-inbound-trafficを書けば良いというのが多くて、あまり役に立ちませんでした。
ただ、
user@host> show interfaces ge-0/0/1.0 extensive 
  Logical interface ge-0/0/1.0 (Index 72) (SNMP ifIndex 515) (Generation 137)
   (省略)
	Security: Zone: trust
    Allowed host-inbound traffic : dns igmp ospf pim router-discovery vrrp ident-reset ping ssh ntp
    Flow Statistics :  
   (省略)
Allowed host-inbound trafficの項目にdhcp、bootpが表示されていないことは気になったので、コンフィグを確認すると、ゾーンtrustにたいしてhost-inbound-trafficの設定が入っていてその項目が有効になっていて、上記のインターフェースに対するhost-inbound-trafficが効いていなそうという事が判りました。
で、バッサリ削除して、全部インターフェース側の設定にしました。
user@host# delete security zones security-zone trust host-inbound-traffic system-services ping
user@host# delete security zones security-zone trust host-inbound-traffic system-services ident-reset
user@host# delete security zones security-zone trust host-inbound-traffic system-services dns
user@host# delete security zones security-zone trust host-inbound-traffic system-services ntp
user@host# delete security zones security-zone trust host-inbound-traffic system-services ssh
user@host# delete security zones security-zone trust host-inbound-traffic protocols ospf
user@host# delete security zones security-zone trust host-inbound-traffic protocols vrrp
user@host# delete security zones security-zone trust host-inbound-traffic protocols pim
user@host# delete security zones security-zone trust host-inbound-traffic protocols router-discovery
user@host# delete security zones security-zone trust host-inbound-traffic protocols igmp
user@host# commit and-quit

結果として無事、show interface extensiveのAllowed host-inbound trafficの項目にdhcpが表示されるようになりました。
host-inbound-trafficeの設定はゾーン→インターフェースという形で単純に継承される訳では無さそうです。設定項目で考えるとゾーンにはdhcpは適用出来ないけど、インターフェースにはdhcpが適用出来るので、継承されてても良さそうなものですが。
ここまでやっても、まだDHCPが取得出来ませんでした。

切り分ける方法が無いのでSRXのコンソールでtcpdumpを取ってみると、クライアントからのDHCP Requestパケットが入ってきていない事が判りました。

そうなると、疑わしいのがネットワーク→SRXと入ってくるinboundトラフィックに掛かっているfirewallという事になります。
それらしい項目としては、上記のsecurity zones security-zone [zone] interfaces [インターフェース] host-inbound-trafficの設定と、firewallですが、show configuration firewallは何も設定していなかったので、何も入っていませんでした。

Juniperの資料に、[SRX] How to setup the DHCP server on SRX with the DHCP clients in a non-default routing instanceというのがあって、デフォルトインスタンスに属していないゾーン・インターフェースでDHCPを動作させると、DHCPDがデフォルトルーティング以外のルーティングインスタンスから入ってくるパケットはドロップするという表記があったのですが、これを読むとデフォルトインスタンスからのパケットはドロップしない・・・という風に取れると思います。

が、結論は違ってて、、、

user@host# set firewall family inet filter default-vr term skip-dhcp from port 68
user@host# set firewall family inet filter default-vr term skip-dhcp from port 67
user@host# set firewall family inet filter default-vr term skip-dhcp then count dhcp-packet
user@host# set firewall family inet filter default-vr term skip-dhcp then accept
という具合にAcceptのフィルターを記述して動作するようになりました。

最初に書いた通り最終的に動作するようにはなりましたが、ちょっと腑に落ちないです。

自宅サーバのESXi化

自宅サーバ(ATOM - Intel D510MO)にUbuntu Server の64ビット版をインストールして運用させてたのですが(自宅サーバ リプレース)、ESXiが5.0になって蟹を認識するようになったとのことで当初の計画通り仮想化(ESXi)する事にしました。

当初の計画としてはD510MOにESXi4.0をインストールして、それまでSolaris10の仮想化(コンテナ)で動作させていた仮想サーバ群をそのまま移行する事を考えていたのですが、D510MOに搭載しているNIC(蟹さん)がESXiで動作しない・・・無理矢理、蟹のドライバ(oem.tgz)を入れて動かすという荒技もあるようですがNICが安定動作しないという情報もあって頓挫・・・という事情もあって、Ubuntu Serverの64ビット版で全部のサービスを一気に動かすという無理な移行をしました。
動作させているサーバというと、
・内部DNSサーバ×3台(自宅内でVlan毎に別のDNSドメインにしているため)

・外部DNSサーバ×2台

・メールスプールサーバ(ごく普通のメールサーバです)

・メールリレーサーバ(Clamsmtpdでメールのウイルスチェックをさせています)

・Proxyサーバ(Havpでウイルスチェックさせています)

・ブログサーバ(・・・このブログです。唯一重いサーバです。)

と、元々仮想化していたサーバ群なので、負荷的には全然軽いサーバばかりです。
仮想化していたサーバを1台に無理矢理集約していたのでDNSサーバが面倒な構成になっていて、外部と内部向けのDNSが共存していることと、内部向けに個別のDNSドメインが存在しているからViewを使ってしまうとスレーブサーバのゾーン転送が難しくなることから、サーバ内に個別のBINDを立ち上げて運用させていました。そして、どうしてもNICが2枚は必要だったのでIntelのPCI NIC(82541PI)を増設していました。

前述のUbuntu server 10.10 自動起動に失敗するはrc.dから起動する話だが、dovecotについてはUpstartで直接起動する。

dovecotをeth0:1、eth0:2等のサブインターフェースを使い動作させているのだけど、自動起動に失敗していた。 インターフェースの初期化よりも先にdovecotが起動されるらしく、エラーログ(/var/log/mail.err)に次のようなエラーが記録されていた。
Mar 22 20:23:30 hostname dovecot: bind(192.168.110.1, 143) failed: Cannot assign requested address
この場合の対処は簡単でstart onの条件にサブインターフェースのインターフェースアップを記述する事で収まった。
start on filesystem and net-device-up IFACE=eth0:1
通常のSysVInitを採用するUNIXならば、例えばS01networkでNICの初期化、インターフェースのアップが行われているのであれば、S90dovecotとか01→90と記述する事で簡単に起動順序を変更する事が出来るのだが、Upstartを採用しているUbuntu10.10ではstart onの条件としてデーモン起動時に事前に必要になる項目を書く必要があるという事になる。
正直Upstartの方法はちょっと面倒臭いので、多分互換性維持の為に残されていると思われるrc.d(/etc/init/rcで起動される)に起動スクリプトを置いたほうが分かりやすいかも知れない。Ubuntu Desktop版のようにクライアント用途で、利用者が起動スクリプトを配置することが無いのであれば、起動時間の短縮やホットプラグデバイスの利用を考えてUpstartを採用した方が良いと思われるのだが。
正直、SystemV系UNIXの /etc/rc*.d/に/etc/init.d/*へのシンボリックリンクを張って自動起動を制御するとか、RedHat系のchkconfigで自動起動のOn/Offが簡単に行える環境、BSD系のrc.localとかにNAMED=ONとか書くだけの簡単なやりかたに馴れすぎていてSolaris10のsvcadmやUbuntuのUpstart、MacOSXのLaunchchtなんか面倒で仕方無いのだけれど。