UbuntuServer16.04->18.04のネットワーク設定と、Unbound on Dockerの話

Jun 18, 2018 - 1 minutes
はじめに systemd-resolvedとかnetplan.ioとかのネットワークの設定周りで新機軸が投入されまくった18.04ですが、 0からのセットアップならいろいろ罠は少ないので、既存のドキュメントでなんとかなると思います。 しかし、16.04から18.04のアップデートでネットワーク設定を安定させて、 なおかつ、ローカル用のDNSキャッシュサーバを運用するためには、 そこそこ手間がかかるのでここにメモしておきます。 UnboundとはDNSキャッシュサーバです。 なぜUnboundか、というのはWeb上の記事に書き散らされているのでここでは割愛。 netplan.ioの設定をちゃんとやる netplan.ioはyamlによるネットワーク設定の抽象レイヤです。 要するに、うまい具合にUbuntu全体のネットワーク構成をまとめてしてyamlに書けるようにしたもの……。 と言いたいのですが、NetworkManagerが絡んでくると、NetworkManagerに全部投げるという設定を書くだけの クソみたいなファイルに成り下がるので、現状UbuntuServerでしか利潤を享受できていないように見えます。 apt install netplan.ioで入ります。apt install netplanとか書くと謎のパッケージが入ってわけがわからないことになるので、注意してください。 とりあえず疎通が取れるようにするには、まずここから。 neplan.ioを使うならば、ifupdownはとっとと消し飛ばしたほうがいいです。 特に、sysmted-networkd systemd-resolvedの取扱に苦労しますので、潔く消し飛ばすことを推奨します。 /etc/netowrk/interface(.d/\*)?に該当する設定は、なんだかんだいってかなり書けます。 書き方は、 Examples | netplan.ioとかに転がっているので、 ほとんどの構成はこれで問題ないと思います。 ただし、設定ファイルの拡張子をyamlとしないと読み込まれませんし、 YAMLの文法ミスのデバッグはとても厄介なので、エディタのプラグインでうまい具合にすることを推奨します。 上記の2点に関して注意しないと、netplanのデバッグ出力を見て、キーと値の対応関係が壊れた設定や、 中身のない設定を読み込み続けているのに気づくまでに時間を溶かします。それだけ注意。 netplan.ioをここまでして推す理由はとても明快で、 # netplan tryで設定適用がタイムアウトによるロールバック付きでできるからです。 ifupdown時代のエラーが起きたら諦めるシェル芸を毎回せずに済むのは非常に良いことだと思います。 遠隔からのネットワーク設定適用はなるべくしたくないものですが、かなりハードルが下がりました。 resolvconfを消し、systemd-resolvedを動作させる systemd-resolvedを有効にしたあと、resolvconfを消します。 16.04からのアップデートだとこのパッケージが残っています。 消す順番を間違えると、名前解決ができなくなって、resolv.confに手を入れることになります。 場合によっては、各種設定の問題で正しくsystemd-resolvedが上がってこない場合があるので、ひたすらデバッグします。 /etc/systemd/resolv.confあたりのDNS=にお好みのDNSサーバを入力して、 systemd-resolvedを再起動すればだいたいなんとかなります。 UnboundをDockerで立てる この項の一番下にdocker-compose.ymlがあります。 今回用いるリポジトリはこれです。 mvance/unbound - Docker Hub まずネットワーキングについて。 有無を言わさずhostネットワークを使うのはダサいですが、 一つしか立っていないことを保証するには多分これが一番良い手だと思います。 次にポートについて。 systemd-resolvedがスタブリゾルバを立てて53番ポートを専有しているので退いてもらう必要がありますが、 先にこのスタブリゾルバを殺してしまうと、名前解決ができずにイメージを持ってこられません。 予めをpullしておくか、一度ポート専有で立ち上がらないと怒られる必要があります。 イメージを持ってこれたら、/etc/systemd/resolv.confでDNSStubListener=noとし、systemd-resolvedを再起動します。 加えて、ポートを空けてもらったはいいが、そのまま標準設定で立ち上げると、 digの結果に;; reply from unexpected source: 127.0.0.1#53, expected 127.0.0.53#53と出ます。 localhostにリゾルバが立つので、ループバックインタフェースを使って問い合わせたものの 応答するアドレスが期待と食い違うので応答を拒否する現象が発生しているわけです。

TFTP設定流し込みによる遠隔作業事故

May 7, 2018 - 1 minutes
TL;DR Gitで設定バージョン管理 実家から自宅のサーバへ接続 同セグメントのルータへTFTP設定流し込み 流し込みファイルを誤選択 設定保存コマンド入り 自宅接続断発生 今後の対策 死活監視 設定保存コマンドを確認するまで流さない 死亡時の復旧手法確立 設定を保存しない PDUによるリブート 最終生存時の設定から復旧するバッチ Raspberry Pi設置 LTE回線接続端末として利用 バッチ動作ノードとして利用 背景 自宅,実家,祖母宅の3拠点にRTX810を導入しており、各々設定ファイルを RTX810-(設置場所市名) で同じディレクトリに配置し、Gitでバージョン管理。 設定変更時は、設定ファイルを編集してコミットの後、Githubへプッシュ。tftpで転送して、問題なければルータにて設定保存していた。 事故内容 事故直前までの経緯 実家から実家と自宅、2拠点間のIPsec-VPNの設定を試みていた。 実家から自宅拠点のサーバServer-AへSSHでアクセスし、その環境にて自宅ルータRTX810-A, 実家ルータRTX810-Bの設定ファイルを編集。コミットを重ねていた。 tftpで設定を流し込む際、RTX810-AにはServer-Aを用いて、RTX810-Bには手元端末Client-Bを用い、設定ファイルの融通にはGithubを利用していた。 その際、同じディレクトリにRTX810-Aの設定とRTX810-Bの設定を配置した状態であった。 事故 Server-AからRTX810-Aへの設定流し込み時に、tftpのコマンドを間違え、RTX810-Bの設定をRTX810-Aへ流し込んでしまった。 復旧不可 RTX810-Aの設定ミスによる接続断は想定されており、RTX810-AのLTE回線からGoogleCloudPlatformへ張られたVPNを用いての復旧が想定されていた。 しかし、その設定も含めて書き換えられてしまったため、完全に遠隔からの復旧は不可能になってしまった。 今回は、自宅拠点に人が居なかったため影響しなかったが、転送した設定ファイルは保存コマンドが有効になっていた。 これは、オペレータでない第三者による電源操作を利用した復旧さえ不可能にしてしまう。 対策 そもそも死活監視をしていないので、死活監視を開始して、死亡時になんらかの処理をできるようにする。 復旧手法として、直前の設定を流し込む方式と、単純に設定転送時には保存コマンドを入れずに、PDUを用いて電源断を行う手法がある。 いずれも、意図しない設定の巻き戻りや、意図しない電源断を招く可能性があるので、死活判定時の死亡判定、復旧実行頻度をよく検討する必要がある。 1番簡単な手法として、各拠点にモバイル回線を用意したRaspberry Piを置くことだという指摘を頂いた。確かにそう。確かにそうだが。追加で月額800円(SIM追加2枚)を払うのは、上記に挙げた仕組みをラズパイで実現し維持するコストとどちらが安いのだろうか……。たしかに、仕組みの維持に1時間取られただけでパートタイム時給ですらペイできてしまう。うーむ。

DockerとOpen vSwtich、その後

Dec 1, 2017 - 1 minutes
読む前に この記事はkstmアドベントカレンダーの2日目です。 尚、下記の記事の続きのようなもので、内容は実質ポエムなので注意されたし。 仮想化以前に構築した自宅インフラをDockerとOpen vSwtichで何とかする話 - Qiita 何故続いたか 下記に上げる既存手法は、帯に短し襷になんちゃらということで、あがく、放置する、を繰り返し結果、1年経ったが結局救われていないことに気付いたので記事にすることにした。 現状、Hostアダプタとdocker-composeでの自動立ち上げで多少幸せになったが、ホストマシンのOSインストールが終わったら、自宅インフラを一発で復旧できるような状態には未だなっていない。 ovs-dockerの運用をやめてしまった要因として以下のものがある 1. 再起動耐性がない 2. あくまでシェルスクリプト 現状、Hostアダプタを運用していて発生してる問題としては以下のものがある 1. Rawソケットを使うデーモンをTagVlanで使えない 2. ホストの構成、IP変更に振り回される そして、一時期検討した、kubernetes等の基盤とかの問題点として以下のものがある 1. アカウンティング、テナンティング、クラスタリングしないので機能の8割が邪魔 2. L2でひっぱりだすのが大変(contivとかあるらしいけどまだ熟れていない) つまり、既存手法にはほぼ救いがない。 Dockerのネットワークドライバを実装しようとした話 Go言語でOVSDBを叩くDockerのネットワークドライバがあれば最高じゃないかと思って、libnetworkのドライバのコード・リーディングを進めているが、さっぱりわからん。 特に、OSのネットワーク周りに対応して秘匿し、互換性を持たせる機能も読み込まなければならず、早々簡単に読めるものではなかった。 手段として大きくなりすぎている気がするので、勉強としては多少読み続けるが、実装しようとは思わなくなった。 kea-dhcp on Dockerの話 Rawソケットを使うデーモン、それはkea-dhcpである。 kea-dhcpをホストアダプタのVlanなI/Fに割り当てると、見事にコケる。 理由はとても簡単、Rawソケットを使っているため、カーネルドライバであるVlanを認識しない。 つまりVlanなI/Fを仮想スイッチで「剥く」ことができるOpen vSwitchは非常に魅力的なのだ。 詳細はここに書かれている。 [Kea-users] (Can’t get KEA to work here - VLAN issues 他にも、HostアダプタでVlanなI/Fを掴んだ場合、Rawソケットを使っているデーモンは全て死亡することになる。 ovs-dockerに再起動耐性をつける話 ovs/ovs-docker at master · openvswitch/ovs この実装を読んでみたが、ovs-dockerの実装であるシェルスクリプトがステートレスなのが問題であって 手前味噌ではあるが、インターフェイスとDockerのコンテナIDあたりの整合性を保持するDBを持っていれば、 もしかしたらなんとかなるんじゃないかと思った。 シェルスクリプトではなくツールとして再実装したら美味しいのでは。 こんなポエムを書いている間に、上記のような着想を得たので、アドベントカレンダー期間内に実装し、 成果が出たら記事として公開しようと思った。 おわり。