VRRP (Virtual Router Redundancy Protocol) というルータ冗長化プロトコルがあり、YamahaのRTXシリーズも対応している。
先日、ひょんなことから我が家に二本目のWAN回線が開通した。 帯域が細いので実用にするつもりはないものの、このVRRPを利用すればメイン回線と冗長構成が取れる。
ロマンはある。 ただ裏を返せばロマン以外にさほど実利はなく大赤字なので、供養のためにポインタだけ残しておく。
ちなみに、VRRPの守備範囲ではないので、DHCPサーバの冗長性を確保することはできない。 LuaスクリプトでDHCPサーバの停止・起動くらいはできるかもしれないが、リース情報の引き継ぎまで考えるとたぶん厳しい。
古くて依存関係の多いPerlモジュール（具体的には昔懐かしいPlagger）をインストールしたい。 ただ、全てをg-cpanでインストールするのは気が進まないし絶対にハマるのでCartonで局所化したい。
まあそうすんなりとはインストールさせてくれないので、手探りで泥臭くどうにかした。 真似はしない方がいい。
g-cpan --install CartonするとManifestがないと怒られる。
ログを追うと、vなしのCarton-1.0.34.tar.gzをGETしようとして失敗している様子。
とりあえずebuildを保存させないと修正のしようもないので、overlayを設定する。
# mkdir /usr/local/portage
# chgrp portage /usr/local/portage
# chmod g+s /usr/local/portage
# vi /etc/portage/make.conf
[...]
PORTDIR_OVERLAY="/usr/local/portage ${PORTDIR_OVERLAY}"
# g-cpan --install Carton
ebuildのMODULE_VERSIONをvありに修正する。
# vi /usr/local/portage/perl-gcpan/Carton/Carton-1.0.34.ebuild
[...]
MODULE_VERSION="v1.0.34"
Manifestを作成する。
DISTのファイル名はvありにする。
チェックサムはb2sumとsha512sumで計算する。
# cat << __EOM__ > /usr/local/portage/perl-gcpan/Carton/Manifest
DIST Carton-v1.0.34.tar.gz 85808 BLAKE2B d627061ff260fbf0f12eec71c030a37cf9d90d3d40a316e67184f50b9ca6a330f8e0cc604093eeaa9a1b3d3cd9dab45106687e95bcf2a09570904e7690bff367 SHA512 6c34dd95f749a8fd91843a63c87b802f1bb967511e3737a58fa2d80360f36cb62db1d66f740921ec3d4d6c624872bd7aa9c146e5eccdb8ac58f6d0a300ddba9e
EBUILD Carton-1.0.34.ebuild 867 BLAKE2B 14215a3e910e78308cded33cf61043d0673c5bd9ce473099c9a608cf9218094b11eb2edc6f3122040f53f565ebdf766eb85c739ca55dd8377780124e0f75529b SHA512 0d7bb8945f9de709cc6ed1eb3022045c6771081ccd09e6d53692251b83a52245af79902a088a034fb46c083acc782ddcb15d44266cac22b52de2eaeff4f3a17d
__EOM__
これでたぶんインストールできる。
おまけ。
依存関係にあるperl-gcpan/Parse-PMFileのインストール時、ExtUtils::MakeMaker::CPANfileがmissingだと怒られる。
この期に及んで/usr/localには入れたくなかったので、アーカイブから持ってきて雑に対処した。
# cp CPANfile.pm /usr/lib64/perl5/5.30.3/ExtUtils/MakeMaker/
未来の自分にトラップを仕掛けた、かもしれない。
参考
現行サーバの移行先として、さくらのVPSで新しいインスタンスを一つ契約した。 v1からv5への大ジャンプ。
宗教上の理由(?)や移行作業のモチベーション上げのために、十数年ぶりにGentoo Linuxを使おうかと画策している。 昔はデスクトップ環境で使っていて結局いろいろ面倒になりやめてしまったが、サーバ環境だったらイケるんじゃないか、という期待。 多少は経験値も上がってるはずだし。
現行サーバの契約更新が年明けなので、デッドラインはそこになる。 過去の失態は繰り返さない、ようにしたい。
COVID-19のせいで、会社のMacBook Airを平日は毎日持ち歩いている。 万一の紛失や盗難に備えて、つい先日（今更）FileVaultを有効化してこのMBAのローカルストレージを暗号化した。 勢いで、私物のMacBook Proも暗号化した。
こうなると、次はXigmaNASで稼働している自宅のNASが気になる。 これにはTime Machineのバックアップが載っているが、Time Machineにはバックアップデータを暗号化する機能はない。 ローカルストレージは暗号化されているのにそのバックアップデータは平文という、この片手落ち感。
NASを暗号化、しよう。
XigmaNASのベースOSであるFreeBSDでは、現時点ではZFSのnative encryptionを利用できない。 なので、GELI (GEOM ELI) を使うというのが順当な選択肢になる。
FreeBSDに関してはnewbieなので正確性に欠けるかもしれないけれども、調べた限りではこういうことらしい。
つまりGELIとZFSはレイヤーが異なり、オペレーションも完全に独立している。 最初は何だか複雑で面倒な構成だと思っていたけれど、理解してしまうとこれはこれで明快に思える。
最終目標は、既存のzpoolの冗長性を確保したまま、すべてのデバイスをGELIデバイスに交換すること。
既存のzpoolに、以下のようなmirror vdevが一つある。 ここに新たにGELIデバイスをattachして、一時的に3-way mirrorの構成とする。 空きベイは少なくとも一つあるものとする（ないと辛い）。
# zpool status
[...]
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada0p1 ONLINE 0 0 0
ada1p1 ONLINE 0 0 0
[...]
新しいディスクにパーティションを整備する。 HDDの総セクタ数は、たとえ同じベンダー・同じモデルでも僅かに異なることがある（経験談）。 せっかく用意したHDDがその僅かな差のせいで使えない、というリスクは許容し難いので、余裕を残して使うことにしている。 ただし256MiBという数字に深い根拠はない。
# gpart create -s gpt ada2
# gpart add -t freebsd-zfs -a 4k -s <calculate_yourself> -i 1 ada2
# gpart show ada2
=> 34 5860533101 ada2 GPT (2.7T)
34 6 - free - (3.0K)
40 5860008800 1 freebsd-zfs (2.7T)
5860008840 524295 - free - (256M)
作成したパーティションをGELIで初期化してattachする。
# geli init -b -e AES-XTS -l 256 -s 4096 /dev/ada2p1
# geli attach /dev/ada2p1
# geli status
Name Status Components
ada2p1.eli ACTIVE ada2p1
GELIデバイスをvdevにattachし、resilverが完了するのを待つ。 無事3-way mirrorの状態になれば、既存のディスクを安全に（データの冗長性を確保したまま）detachすることができる。
# zpool attach tank ada1p1 ada2p1.eli
# zpool status
[...]
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada0p1 ONLINE 0 0 0
ada1p1 ONLINE 0 0 0
ada2p1.eli ONLINE 0 0 0
[...]
あとは、残りの未暗号化ディスクについて以下の手順を繰り返す。
GELIに関していくつか。
BOOTフラグに頼らず、OS起動後にリモートから手作業でattachする運用も考えはしたが、逆に手間がかかりそうなので諦めた。 KVMレスでは運用できなくなってしまうが、ストレージが整った状態でOSに引き渡す方が（特にXigmaNASのようなembeddedな環境では）無用なトラブルも避けられるだろう。
サイズを見比べるとGELIには4KiBのオーバーヘッドがあるように見える。 頭の片隅には置いておいた方が良いかもしれない。
# geli list
[...]
Providers:
1. Name: ada2p1.eli
Mediasize: 3000324501504 (2.7T)
Sectorsize: 4096
Mode: r0w0e0
Consumers:
1. Name: ada2p1
Mediasize: 3000324505600 (2.7T)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r1w1e1
GELIにはチェックサムによる整合性検証の機能もあるが、ZFSと組み合わせる場合はZFSに任せてしまうのが一般的らしい。 実際のところ、敢えてGELIにやらせても単にリソースの無駄遣いだろう。
参考文献
故あって、Feedlyとお別れすることにした。
Leoを試してみたくて軽い気持ちでPro+プランにアップグレードしたら、少なくとも自分にとっては期待したものではなく、Proに戻したらMute Filterが使えなくなっていた。 既得権の保護ということなのだろうけれど、どこにもわかる形で明示されていないのはいただけないし、やるのであればアカウント単位で制御してほしかった。
いずれにせよ、コストパフォーマンスが折り合わなくなってしまったし、細かい不具合が気にはなっていたので、お別れすることにした。 プランを変えて戻す間に余分に数千円支払ってしまった形だが、手切金ということで無理やり納得することにする。
あまり文句を言いたくはないけれど、どうしたって文句になってしまう。
後継はInoreaderに決めた。 いろいろと痒いところに手が届くようになって早くも満足し始めている。 有料プランのトライアル期間が用意してあるのもすごくいい。