- ダウンロード
- apt install debootstrap systemd-container
- debootstrapで最小構成のubuntuのツリーを作成する
- debootstrap --arch amd64 xenial /var/lib/machines/ubuntu http://archive.ubuntu.com/ubuntu
- 中に入る
- systemd-nspawn -D /var/lib/machines/ubuntu
- 通常起動してみる(-bオプションを足すだけ) 終わらせるときはCtrl+] を3回連打
- systemd-nspawn -b -D /var/lib/machines/ubuntu
- コンテナ内にchroot環境構築
- http://gihyo.jp/admin/serial/01/ubuntu-recipe/0491?page=2
- http://d.hatena.ne.jp/grasso0210/20170526/1495802750
- 注意点：16.04ではsystemd-resolvedには対応していないらしく，設定しても反映されない。/etc/resolv.confに直接記述して対処した。
- 起動・停止・ログイン
- machinectl start dns2
- machinectl poweroff dns2
- machinectl login dns2 ctl+]を3回でコンソールを閉じる。
- ターミナルが白黒になるので.bashrcにexport TERM="xterm-256color"を設定。
2018年3月8日木曜日
systemd-nspawnのインストールメモ（簡易版）
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の件は本当にそれで正しいのか不明。
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の件は本当にそれで正しいのか不明。
登録:
投稿 (Atom)