挙げてみたら結構あった。

Zone Apexをあちこちで使うのをやめた

以前はMUAの設定にまでZone Apexを使っていたが、サーバ切り替えの際に面倒だったので可能な限りホスト名を使うようにした。 ホスト名でのTLS証明書が新たに必要になったが、そこはLet’s Encryptのお世話に。

Google Authenticatorをやめた

二要素認証でリモートログインできるよう、Google AuthenticatorのPAMモジュールを入れていた。 いざという時に普段使いでない（秘密鍵を持っていない）端末からでもログインできるように、くらいのつもりだったが実際に役に立ったことはないし、今ではスマホにすら専用の秘密鍵を入れているので本当にメリットがなくなった。

Fail2banをやめた

SSHやWebへのアタックのログが目障りだったので入れていたが、ログの減量を除けば、悪者を釣り上げて悦に入る以上の実効性はなかったのでやめた。

SSHをwell-knownでないポートで運用するのをやめた

アタック避けに7022/tcpで運用していたが、捕捉されるまでの時間稼ぎくらいにしかならないことがわかったのでやめた。

Muninをやめた

直近1年間の稼働状況がグラフ化されているというのは便利だったし、ついでに監視にも使っていたが、正直めったに見なかったし必要性も薄かったのでやめた。 代わりにsysstatとMonitを使っているが、十分だと思う。

Gitwebをやめた

サーバ上のリポジトリの一部をWebで公開していたが、大したものはないのでやめた。 ところどころリンク切れを起こしているはずだけど、それは追って考える。

ClamAVをやめた

実はかなり前のことだけども、メール受信時にClamAVを通すのをやめていた。 物理メモリを固定で数百MB食うわりに、いろいろ試しても昨今のマルウェア相手では満足な検出率が得られず、コスパが悪かった。

パッケージの更新通知をやめた

Debianではapticronでパッケージ更新通知のメールを投げていた。 Gentooでもたとえばglsa-checkを使って同じような仕組みは作れるが、日頃のアップデート作業を習慣づけるために敢えてやめた。 GLSAは別途、フィードを購読している。

思い返せば2007年頃のサーバ移転以来、ずっとDebianのお世話になってきた。 当時から見ても情けないスペックの省スペースデスクトップマシンで自宅サーバ運用をしていたので、そういったしがらみは大いにあった気がする。 ただそんな事情を差し置いても、安定性や明快さの観点でDebianはサーバ用途に理想的なディストリビューションだと思っていた。

転機は、Debian 8 “Jessie”のリリースだった。 詳細を省いて煙に巻く言い方をすれば 宗教上の理由 で、systemdを忌避している。 このsystemdがJessieで標準のinitシステムとして採用されてしまって以来、じわじわと肩身が狭くなっていくのを感じてきた。 新しいメジャーバージョンがリリースされる度に余計な神経を使うようになり、SysVスタイルのinitスクリプトに不具合を見かけるようになった。 きっと、このままでは未来はない。

また別の観点では、ポイントリリースモデルに徐々に扱いづらさを感じ始めていた。 若い頃と違い、今ではサーバ管理作業そのものに対するモチベーションはすっかり下がってしまった。 数年おきとはいえ、リリースノートに目を通しつつ非互換の有無を精査しながらのアップデート作業は、可能なら避けたい部類の負担になっていた。 そして億劫になりLTSのお世話になりがちになるものの、それだって結局は先延ばしに過ぎない。

systemdからの逃避先として最初に浮かんだのはBSDだった。 しかし経験がほぼないに等しいBSDをぶっつけ本番で、とは考えられなかった。 Devuanという選択肢もあったけれど、どうも乗り気にはなれなかった。

考えた末に、Gentooで行くことにした。 昔デスクトップ環境として使っていたことがあるので多少の勘は残っていそうだし、ローリングリリースというのも好都合だった。

期待通り、セットアップ作業全体を通じて概ねトラブルはなかったのだけど、メモリに関しては大誤算をした。 VPSの物理メモリが1GBで、swapはまあ1GBも取っておけば大丈夫だろうなんて思っていたら、GCCのアップデートがメモリ不足でビルドできなかった。

Recent gcc versions have been known to take 1 GB to 1.5 GB of RAM per job.

MAKEOPTS - Gentoo Wiki

腹を括ってパーティションを切り直し、swapを4GB確保した上で再セットアップした。 平時の負荷なんて知れてるので、盛大にswap outしてでも乗り切れるならそれで良い、という割り切り。

本番運用に入ってみて、ディストリビューションを変えるなんて冒険をしたわりに意外と不安はないな、なんて思ったのだけど、考えてみればこの1年あまりずっと低レイヤーの保守作業はやってきたわけなので、当然と言えば当然だった。

新しいVPSインスタンスを契約してから早一年。 ようやく、ようやく対外的なサービスの引っ越しまで漕ぎ着けた。 このエントリが公開された時点で、88171.netのサービスに旧サーバは一切関与しない構成となっている。

メールサービスが生活上かなりクリティカルな上に、送信ドメイン認証やspam対策でかなり複雑な構成になっているので、とにかく腰が重かった。 なんとしてもこの盆のうちに、という強い意志だけで乗り切った。 ここで折れるとまた半年後とかになりそうだったので。

DNSサーバの移管は常々キレイにやりたいと思っているものの、いつも力業になってしまう。

今回のトラップはさくらのセカンダリだった。 ゾーンを維持したままプライマリを切り替えるという操作が上手くいかず、軽い気持ちでゾーンを削除したらチェックで弾かれて再追加ができなくなり、急いで上位のNSレコードからセカンダリを消すなどかなりバタバタしてしまった。

結果的には、不確実性のあるセカンダリはあらかじめ外しておいて、プライマリ間だけで移管を完了させてからゆっくりセカンダリを戻せば良かった。 次の機会にはそうしよう。