2018年2月14日水曜日

systemdでbind9がchroot出来ないところから始まった泥沼

またsystemdに泣かされた。
ubuntu16.04なサーバーにbind9でスレーブDNS立てようと思ったのが始まり。
chrootは/var/bind/chroot。 まずこんなエラーが出てbindが起動できない。

error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:233:
error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:467:
error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:390:id=gost

これはあちこちに書かれているが/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engineもchroot下のツリーにコピーしてくればいいはず。しかし,エラーは変わらず。これで数時間。
systemd関係してるのかと思ってググるキーワードを変えてみたら,systemd環境ではchrootは出来ないという記事を見つけた。まあ,chrootはセキュリティ的にアレだってことになってますからね。
じゃあどうすんの?って調べた所systemd-nspawnを使ってコンテナ内で動かすのが王道であるとのこと。そこでコンテナ作って,環境をコピーして動かしてみた。named自体は立ち上がってやれやれと思ったら,名前解決してくれない。そこでnamed.logを調べてみたらこんなエラー。

zone domain.com/IN: loading from master file /var/bind/slave/internal-domain.com failed: permission denied

ファイルのオーナー/パーミッションを調べてみたが問題はない。apparmorじゃないのか?とひらめいたがコンテナ内ではapparmorは動いていない。ここから数時間試行錯誤したが上記エラーは全く変わらず。もうスッピンでインストールしようかしらと心が折れかけた。
ふとホスト側のapparmorが影響してんのか?と思って,コンテナ側の/etc/apparmor.d/usr.sbin.namedを/etc/apparmor.d/var.lib.machines.dns2.usr.sbin.namedとしてホスト側にコピーしてbind9を再起動してみた。するとログが変わった!

zone domain.com/IN: loading from master file /var/bind/slave/internal-domain.com failed: not implemented

結局ゾーンファイル読めてない。
更にググるとこんな記事 を見つけてnamed.confのゾーンファイル指定のところに"masterfile-format text"を付加せよとのこと。半信半疑でやってみたら無事エラーは消えた。名前解決も出来るようになり,ゾーン転送もOK。

しかしapparmorの件は本当にそれで正しいのか不明。


0 件のコメント: