以下の作業を実施． SoftetherとTLS-SNIなバーチャルホストを同居させる設定を行った． もっと丁寧な記事だったが，RAID1の/var/www/が私のミスで消し飛んだ上にこの記事はバックアップされていなかったのでこのようなものになった． 何卒ご了承いただきたい． # apt install libpcre3-dev libssl-dev zlib1g-dev libxml2-dev libxslt1-dev libgd-dev libgeoip-dev nginx #必要ライブラリのインストール # nginx -V #configureオプションを確認 # apt purge nginx && apt autoremove #用済み % ./configure --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-QTAlz1/nginx-1.14.0=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream --with-stream_ssl_preread_module --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module #--with_streamの=dynamicを削除, --with-stream_ssl_preread_moduleを追加 % make # make install # ln -s /usr/share/nginx/sbin/nginx /usr/sbin/nginx #デフォルトの場所にシンボリックリンクを置く # cat > /lib/systemd/system/nginx. Read more ...

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時間取られただけでパートタイム時給ですらペイできてしまう。うーむ。 Read more ...

読む前に この記事は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を持っていれば、 もしかしたらなんとかなるんじゃないかと思った。 シェルスクリプトではなくツールとして再実装したら美味しいのでは。 こんなポエムを書いている間に、上記のような着想を得たので、アドベントカレンダー期間内に実装し、 成果が出たら記事として公開しようと思った。 おわり。 Read more ...