88171.net

ZFS on GELI

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
[...]

あとは、残りの未暗号化ディスクについて以下の手順を繰り返す。

  1. vdevからdetachする
  2. （必要があれば）パーティションテーブルを調整する
  3. GELIで初期化しattachする
  4. GELIデバイスをvdevにattachする

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

故あって、Feedlyとお別れすることにした。

Leoを試してみたくて軽い気持ちでPro+プランにアップグレードしたら、少なくとも自分にとっては期待したものではなく、Proに戻したらMute Filterが使えなくなっていた。 既得権の保護ということなのだろうけれど、どこにもわかる形で明示されていないのはいただけないし、やるのであればアカウント単位で制御してほしかった。

いずれにせよ、コストパフォーマンスが折り合わなくなってしまったし、細かい不具合が気にはなっていたので、お別れすることにした。 プランを変えて戻す間に余分に数千円支払ってしまった形だが、手切金ということで無理やり納得することにする。

あまり文句を言いたくはないけれど、どうしたって文句になってしまう。

後継はInoreaderに決めた。 いろいろと痒いところに手が届くようになって早くも満足し始めている。 有料プランのトライアル期間が用意してあるのもすごくいい。

遺されたシステム

あるいは（俺が死んだらこのドメインとサーバはどうなる）

他界したとき、そしてドメイン名 - ここはちょっと見せられない というエントリにふと行き当たり、まさに自分の身にも当てはまる内容で考えさせられた。

このご時世、一個人が独自にドメイン名を登録してWebサイトやメールといった何らかのサービスを運用している、というケースは決して稀とは言えない。もしも、その唯一の管理者が突然この世を去り、もしも、遺族や関係者が必要な対処をできなかった場合、遺されたシステムは一体どうなるのか。管理者は存命中にどのようなリスクヘッジができるのか。そんなことを考えてみたい。

TL;DR

一般的な「遺産」の話

ささっと調べた程度の知識で恐縮ながら、重要なポイントなので、まずはこんな話から。

金融機関が契約者の死亡の事実を知るに至った場合、件の契約者の資産は「凍結」される、らしい。その時点から口座引き落としは止まり、早晩クレジットカードも決済不能になる。原則は遺族からの申告に基づいた手続きではあるらしいけれど、「資産は速やかに凍結されるもの」と考えておくべきだろう（「それじゃ隠し口座を作っておこう」というのは違うと思うぞ）。

これが意味するのは、平たく言えば「金の切れ目は縁（サービス）の切れ目」という世知辛い現実で、それに伴って発生するリスクにどう抗うかを考えていくことになる。

ドメイン名

ドメイン名は容赦なく期限切れになって、中古ドメイン名としてリセールされてしまうわけです。それは遺族が知らないままに。

他界したとき、そしてドメイン名 - ここはちょっと見せられない

ドメイン名には有効期限があるので、必要な手続きと料金の支払いを行わない限り、いずれ必ず期限が切れる。そうして売りに出された期限切れドメイン名が無関係の第三者によって取得（登録）されてしまうという事態は、どう足掻いても避けようがない。

ドメイン名を手放す時の一般的な懸念は、エロやアクセス乞食みたいな低俗なサイトになる恐れがあるよ、という程度かもしれない。しかし、それで済むならむしろ良心的と言ってもいい。故人に対する信用や心証にちょっと傷が付くかもしれないけれど、それ以上のことはない（たぶん）。

メールハイジャックのリスク

独自ドメインでメールサービスを運用していて、メールアドレスをインターネット上の様々なサービスに登録している場合、段違いのリスクと向き合う必要がある。

中古ドメイン名として手に入れた人は、きっとそこから、様々なメールを受取ります。そしていずれ様々なところにアカウントが作られてあり、権限があることにも気がつくでしょう。

他界したとき、そしてドメイン名 - ここはちょっと見せられない

ドメイン名をドロップキャッチした第三者がサーバを設置した場合、SMTPの通信状況を見れば「そのドメインで過去に使用されていたメールアドレスとその用途」が容易に推測でき、さらにその気になれば全てのメールを受信して内容を読むことができる。そもそも悪意を持った攻撃者であれば、はじめから全てのメールを受信するよう設定しているだろう。

こうしてメールを「ハイジャック」できれば、そのアドレスで登録されている様々なアカウントの権限を得る可能性があり、情報や資産の窃取はもとより、個人情報を悪用した詐欺行為などに遺族・関係者が巻き込まれる危険性すらある。

ちなみに「ハイジャック」という表現は便宜的なものであって、その行為自体の違法性を問えると言っているわけではない。あくまで合法的に登録したドメインに一方的に通信が来るわけだから、それらの通信に対する法的庇護は（現実はどうあれ）期待しない方が賢明だと思う。もちろん、知り得た情報を犯罪行為に悪用すれば然るべき罪に問われてほしいところだけれど。

考えられる対策

一度登録したドメイン名を「更新し続けること」を妨げる事由は存在しないはず（経済的事情や更新し忘れなど、利用者側の問題を除けば）なので、「将来に渡って可能な限り長い期間、期限切れの状態に陥らせないこと」がポイントになる。

ちなみに、「レジストラが利用者本人の死亡の事実をもし仮に知り得たとしても、それをもって期限満了前にドメイン名の登録を解除することはない（少なくとも現実問題としては）」と期待しているし、それを前提に考えている（実際どうなんだろう）。

可能な限り長期の登録を維持する

新規登録や更新の際に、可能な限り長い期間を指定することは一つの対策になると思う。たとえば10年間の登録が可能であれば、1年毎に更新を繰り返すよりもベターと言える。

またレジストラによっては、任意のタイミングで上限期間まで更新することが可能な場合がある。たとえば上限の10年間で新規登録した後、1年毎に更新手続きを行なえば、期限を常に向こう9年以上に維持することができる。現実的にはこの方法がベストと考えられるので、使えるのであれば是非使っておきたい。

自動更新を検討する

10年でもそれだけでは不安だったり、TLDによってはそもそも上限期間が1年間だったりする。そんな時は、レジストラが提供する「自動更新」や「更新予約」といった機能を活用できる、かもしれない。クレジットカードや口座引き落としでは意味がないので、事前入金やポイントのチャージといった前払い方式を選択できる必要があるけれど、「前払い分の残額が尽きるまで1年毎に更新し続ける」ことができる、かもしれない。

ただしこの方法にはざっと思い付いただけでも以下の懸念があるので、あくまで他に方法がない場合の保険程度といった割り切りが必要だと思う。

サーバとサービスの話

さて、取得したドメイン名でサービスを運用するには、何らかのサーバが必要になる。このご時世、一口に「サーバ」と言っても自宅サーバからIaaS・SaaS、有料・無料まで、様々な形態が考えられる。

結論から言えば、管理人亡き後にも継続稼働が期待できるケースは稀なので、「サービス継続は不可能」という前提に立つのが妥当だと思う。仮に運よく継続稼働できる条件を満たしたとしても、管理者不在のまま稼働し続けることを（セキュリティや責任の観点で）良しとするのか、という疑問は残る。

自宅サーバの場合

そこそこ生き残ってくれそうに思えるが、状況次第で呆気なく止まる。

まず遺品整理のタイミングなんかで、サーバやネットワーク機器そのものの電源を落とされる可能性はとても高い。普通の人が「ずっと点いている必要のある電化製品」と認識しているのは、たぶん冷蔵庫くらいだと思う。むしろ電源を落とされないと期待する方に無理がある。

他にも何らかのきっかけで、利用していたISPの契約内容を変更されたり解約される可能性もある。それに伴う固定グローバルIPアドレスの喪失やネットワーク機器の交換など、サーバへの到達性が損なわれるポイントはいくらでもある。

有料サービスの場合

契約期間の満了をもって止まる。

SaaSでもPaaSでもIaaSでも、月毎あるいは年毎に契約更新と支払いを重ねていくスタイルが一般的だが、支払いが滞るので、サービスは止まる。以上。

無料サービスの場合

「独自ドメインを持ち込めて無料」というサービスがあるのか知らないけれど、あるならたぶんしばらくは生き残る。ただし無償だからこそ将来の保証もないはずなので、実は最も読み辛いケースだと思う。

DNSのリスク

リスクと言うには比較的小さいかもしれないけれど、DNSについてもちょっと考えておきたい。

独自ドメイン名を使っているということは、何らかの形で必ずDNSサーバを運用している。レジストラやホスティング業者が提供しているDNSサービスかもしれないし、管理者自ら独自ドメインでDNSサーバを運用しているかもしれない。

ゾーンに載っているIPアドレスはISPやホスティング業者から（契約に基づいて）一時的に借りているものと言える。そのIPアドレスの契約が切れた後もDNSにゾーン情報が残ったままだとすると、そのIPアドレスが将来第三者に再割り当てされた場合、サーバをハイジャックされたのと等しい状況に陥るリスクがある。レジストラのDNSサービスを使っているケースが（ドメインを維持している限りゾーン情報が残るので）最もリスクが高い。独自ドメインにDNSサーバを置いている場合も、上位サーバのグルーレコードにIPアドレスが残ったままになるので同様のリスクがあるし、ゾーンのコントロールを奪われ得るのでより悪いとも言える。

狙って攻撃した場合の成功率は大部分が運に左右されるけれど、たまたまIPアドレスを再割り当てされた第三者が触れずにそっとしておいてくれるかはわからない。メールログに見慣れないアドレスが定期的に載ってたら、気持ち悪がって調べるよね、普通の管理者なら。

可能であればIPアドレスの貸主、つまりISPやホスティング業者が提供するDNSサービスを利用するのが比較的安心ではある（契約終了に伴ってIPアドレスと同時にゾーンも無効化されると期待できる）。ただ、そのサービスにNSレコードを向け続けることが将来に渡って安全という保証はないし、そもそも事情が許さないケースもある。こればかりは安心と思える方法を思いつかないので、どこかで割り切りが必要になると思う。

まとめ

そんなことを考えると、独自ドメイン名なんて恐ろしくて取得できないんじゃないでしょうか。いや、独自ドメイン名なんかで、重要なアカウントを作れない。未来永劫とは言わなくても、死後遺族に向けて保証されるなにかがなければ怖くて使えないですね。

他界したとき、そしてドメイン名 - ここはちょっと見せられない

いやほんと、そうなっちゃう。一方でこのご時世、メールアドレスの一つも持ってないと（割と冗談じゃなくて）生きていけないし、安定性や将来性なんかを考えるとGoogleとかYahoo!とか有名どころに頼るしかないし、そうすると（そうでなくても）プライバシーとか企業倫理とか気になってくるし、もう八方塞がり。

ドメイン名が買い切りモデルにでもなってくれたらそれだけでもだいぶ平穏なのだけど、ドメイン名の売買がビジネスとして確立してしまっている現状を見ると、将来的にも期待は全くできそうにない。インターネットは想像より遥かにビジネスで、ユーザの資産や権利の保護なんて無いに等しく、インフラと呼ぶにはあまりに頼りないギリギリのバランスで成り立っているように思えてくる。まあ現状をただ嘆いたって仕方がないし、自分としては独自ドメインを捨ててどこかに隠居しようともまだ思えないので、できる範囲で備えておくしかないかな、と。

最低限ドメイン名の更新とNSレコードの削除くらいは、遺言書（もしくはエンディングノート的なもの）で頼んでおけば誰かがケアしてくれるかもしれない。頼れる人がいないとか、人に知られたくないといったような事情があると厳しいけれど、そんな時は諦めてメールだけでも ProtonMail に移行しておくと少しは安心かもしれません（ステマではなく、マシな選択肢が本当にそれくらいしか思いつかない）。