Chienomi

メインサーバーをConoHaから転出

Live With Linux::server

序

私のメインサーバーは2016年からConoHa VPSを採用してきた。 ServerMan@VPSからの移転であった。

また、現在のほとんどのウェブサイトはConoHa WINGでホストしており、これはChienomiも例外ではない。 メインサーバーにフォーカスすると、次のような経過である。

  • 自宅サーバー1 (2002〜2014)
  • ServerMan@VPS (2014〜2016)
  • ConoHa VPS2 (2016〜2022)

現行のChienomi3にフォーカスすると次の通りである。

  • ConoHa VPS (WordPress) (2016〜2019)
  • ConoHa WING (PureBuilder Simply) (2019〜2022)

サーバーの作り直しや新設はともかく、メインサーバーのプラットフォームを変更することは今まであまりしていないのだが、今回ConoHaから出ていくことを決めた。 これに伴って、ChienomiもVPSホストに変更し、この転出の影響を受けた。

経緯

事の発端は「ConoHaの登録メールアドレス宛にスパムメールが届く」というものであった。

私はメールサーバーを自前管理していることを利用して登録するメールアドレスをサービスごとに変える、ということをやっているため、スパムメールが届くとどこから漏洩したものかを判定できるようになっている。

ConoHaの登録メールアドレスはそこそこ複雑なもので、単語としての意味を持っているようなものではない。 このことから、次の問い合わせを行った。

お世話になっております。 9/19日よりConoHaに登録してあるメールアドレス(他では一切使用しておらず、掲載もしていないメールアドレス)宛にスパムメールが届くようになっております。 量は本日までに4通で、Amazonを装ったもの、および楽天を装ったものです。

漏洩がなかったがご確認いただけますでしょうか。

問い合わせを行ったのは深夜だが、翌日午前中に次の返信があった。

いつもご利用いただき、まことにありがとうございます。 ConoHa お客様センターです。

お問い合わせの件につきましてご案内致します。

推測とはなりますが、ご申告いただいたメールにつきましては 不特定多数に無作為に送信を行う手法である迷惑メールである かと存じます。

弊社ではお客様がご利用されている状況の詳細が分かりかねま すため、お客様にて懸念点などがあるようでございましたらブラック リストの登録などをご検討いただけますと幸いでございます。

何卒ご確認の程よろしくお願い致します。

ここで問題なのは、実際に漏洩があったかどうかではない。 それは確認のしようがないためだ。 漏洩に起因するのであれば他の経路によるところは考えられないが、どれほど複雑なメールアドレスであったとしても、「たまたま到達した」という可能性を否定することはできない。

だが、非常に疑わしい状況であることは確かで、サービス提供者としては確認を行うべきだ。 しかし、始業早々にこのメールが返されたことからしても、また調査状況に言及がないことを見ても、確認を行った形跡もない。

これだけでも重大な問題だが、実のところ今に始まった話でもない。

以前、Litespeedに関する問い合わせを行った際もデタラメな回答が返ってきている。 これも、技術部署に確認した形跡はない。 ウェブサイトの掲載内容が虚偽という問題なので、これもなかなか深刻だ。

このほかにも、ConoHa WINGのRuby問題もある。 採用されているRubyが重大な脆弱性を持ったバージョンであり、更新するよう呼びかけているのだが、全く応じられない。 というか、回答もしない無視である。

さらに、ConoHa自体の運営方針も不信感を募らせるようなものである。

以前はConoHaは技術的な色を打ち出しており、技術イベントも積極的に開催していた。 だが、現在は技術に関しては全く触れないようになっており、マスコットキャラクターである三雲このは(おそらく三代目)を担当している人も技術が全くわからない人になっている。 そして、VTuber活動など「萌え路線」を強く押し出しており、技術的な方向とは全く関係ない方向での活動が中心となり、かつては参加型技術イベントであったものも、今や集金色のあるファンイベントに変えられている。

さらに、ConoHaのPRは技術に関わるものがなくなった代わりにアフィリエイターを後押しするものが数多く出されるようになった。 その中には胡乱なものも少なくなく、健全性もなく、テクニカルな人間から見れば嫌悪感を感じるものである。

こうしたことからConoHaに対する信頼が最低水準を下回ったため、生命線とも言えるメインサーバーをConoHaに置いておくのが嫌になったのだ。

移転先の検討

要件とConoHa

だが、実際ConoHaから出ていくことを検討すると、意外なほど難しい。 ライバルとなるサービスは数多あると思っていただけに少し驚きであった。

WINGは特に難しい。 レンタルサーバー自体は珍しいものではないが、WINGは任意の数のサイトを立ち上げることができる。 これは、ドメインに依存するが、登録されたドメインのサブドメインで立ち上げることができるため、ドメインをひとつ持っていれば実質無制限で立ち上げられる。 サイトを立ち上げれば同ドメインのメールボックスも作られ、メールアドレスの数も無制限、容量は共有される。 GMO発行のSSLが無料でつく。

そして何より、WINGはSSHログインが可能で、Bashが取れるほか、Zshもあり、工夫次第でVPSに近い運用が可能。 cronもあるため、スケジューラーも使える。 SSHログインが可能なためPCやホームサーバーから機能拡張することもできる。 Gitがあるのも良い。gitでのデプロイが可能だからだ。 以前はrsyncがなかったが、現在はrsyncも備わっている。

VPSのほうも、「即時立てる」「即時消す」ができ、なおかつ1時間割りの課金であるため、短時間の利用が可能だ。 IaaSならそれなりに珍しくないが、任意のOSによるサーバーを立てることができ4、転送量制限もないというとクラウドでもなかなか見つけられない。

また、スイッチポート制限も可能なことと、使いやすいDNSサーバーがあるというのも大きい。 DNSの設定はものすごくめんどくさくて時間がかかるUIであることが多いのだが、ConoHaを使うとかなり楽になる。

XServer

ドメインのほうでお世話になっているXServerだが、最近VPSを始めた。

AMD EPYCとNVMe (PCIe?) SSDというマニアックな構成のノードだそうで、なかなか好きな人がやってそうな感じがする。

ただ、選択可能なOSはUbuntu, Debian, Rocky Linuxとかなり狭く、選択の余地に乏しい。 archlinuxを導入できないのは致命的だ。

というわけで問い合わせて見た。

他社VPSからの移行で検討しております。

サーバーをarchlinuxで構築したいのですが、カスタムイメージからの起動/インストールのサポートがされる予定はありますでしょうか。

よろしくお願いいたします。

翌日早々に次のような回答をもらい

お知らせの内容について、担当部署にて確認を行います。 確認結果が判明いたしましたら、改めてご連絡いたしますため、 恐れ入りますが、今しばらくお待ちくださいますようお願いいたします。

お昼に次の回答をもらった。

担当部署にて確認いたしましたところ、 今後取り扱うイメージの拡大は予定しておりますが、 現時点では未定としておりますため、 具体的なご案内ができかねますことご了承ください。

対応範囲の拡大などご案内可能な内容がございましたら、 当サービスのホームページ上などでもご案内を いたしますので、ご確認いただければ幸いでございます。

100点満点の対応ではあるのだが、archlinuxが使えないと候補にならないので、採用しなかった。

また、XServerはコンテンツに対する制限があるという点もメインサーバーとしては問題だ。 サーバーはなにもウェブだけのものではないから、ウェブサーバーを前提にした制限事項を掲げるのも変なのだが、それよりもコンテンツに制限をかける=サーバーの中身に対する注文をつけるということなので、それだとサーバーの機密性が保たれない。

サーバーに置かれるデータというのは重大な機密であり、内容にひっかかるかどうかに関係なく、コンテンツを制限してくるのは危険なのだ。

さくらインターネット

さくらのVPSはConoHaの直接のライバルになるが、違いは意外と大きい。

レンタルサーバーと違い、初期費用は発生しないが、申し込んでからサーバーが立つまではしばらくかかる。 また、費用も月または年単位の前払いであり、払い戻しもない。

ストレージはSSDで、1回費用を払うと恒久的に倍化できる。 これで1GBプランで100GB, 2GBプランで200GBのSSDが搭載できるのはなかなか魅力的。 そのかわり、ConoHaほどストレージプランは充実していない。

デフォルトで選べるOSは多くはないが、「OS再インストール」からはより多くのOS(archlinuxを含む)を選択できる。 また、SFTPでISOイメージをアップロードして起動することも可能。

スイッチFWもある。ConoHaと違い、コントロールパネルから設定可能で使いやすい。

DNSもあるが制限があり、ConoHaのように広く使えるようなものではない。

比較すると優れている部分もあるが、柔軟性がいまひとつだ。 クラウド的な感覚の強いConoHaと比べれば昔ながらのVPS感がある。

ABLENet

あまり有名ではないVPSサービス。 FX専用VPSとかあるらしい。

ページからはかなり技術の香りがする。

ハードウェア構成は非公表。 OSはかなり幅広く、DragonflyBSD, OpenIndianaも選択可能で、Archlinuxもある。

コントロールパネルの機能は限定的。

回線は200Mbps共有。 ディスクはSSD, HDDの記載があるが、これはorであり、SSDの容量が少ないのはかなりの難がある。 HDD追加オプションは10GBあたり550円/月と超強気。

利用制限が非常に厳しく、かなりサーバーの中身に踏み込むものであるため、選択しなかった。 ストレージの小ささも痛い。

カゴヤ

日割りの細かい料金体系が嬉しいVPS。

Archlinuxは選択できない。

DTI (ServerMan)

利用中最新イメージが　CentOS 5のままなかなか更新されず苦労したServerMan。 ページを見るとあまりケアされていないようで、スペック面も期待できそうにない。

Archlinuxは選択できない。

さくらのVPSの詳細

inxi -Fの結果は次のとおり

System:
  Host: nightphlox Kernel: 5.19.13-arch1-1 arch: x86_64 bits: 64 Console: pty pts/0
    Distro: Arch Linux
Machine:
  Type: Kvm System: Red Hat product: Linux KVM v: RHEL 7.0.0 PC (i440FX + PIIX, 1996)
    serial: <superuser required>
  Mobo: N/A model: N/A serial: N/A BIOS: SAKURA internet v: 0.5.1 date: 01/01/2011
CPU:
  Info: 3x 1-core model: Intel Xeon Gold 6212U bits: 64 type: SMP cache: L2: 3x 4 MiB (12 MiB)
  Speed (MHz): avg: 2400 min/max: N/A cores: 1: 2400 2: 2400 3: 2400
Graphics:
  Device-1: driver: bochs-drm v: N/A
  Display: server: No display server data found. Headless machine? tty: 190x44
  Message: Unable to show GL data. Required tool glxinfo missing.
Audio:
  Message: No device data found.
Network:
  Device-1: Intel 82371AB/EB/MB PIIX4 ACPI type: network bridge driver: piix4_smbus
  Device-2: Red Hat Virtio network driver: virtio-pci
  IF: ens3 state: up speed: -1 duplex: unknown mac: 9c:a3:ba:07:0e:76
  Device-3: Red Hat Virtio network driver: virtio-pci
  IF: ens4 state: down mac: 9c:a3:ba:08:95:16
  Device-4: Red Hat Virtio network driver: virtio-pci
  IF: ens5 state: down mac: 9c:a3:ba:0a:1b:b6
Drives:
  Local Storage: total: 200 GiB used: 3.94 GiB (2.0%)
  ID-1: /dev/vda model: N/A size: 200 GiB
Partition:
  ID-1: / size: 180.05 GiB used: 3.94 GiB (2.2%) fs: ext4 dev: /dev/vda2
Swap:
  ID-1: swap-1 type: partition size: 16 GiB used: 0 KiB (0.0%) dev: /dev/vda1
Sensors:
  Missing: Required tool sensors not installed. Check --recommends
Info:
  Processes: 91 Uptime: 1d 22h 40m Memory: 1.93 GiB used: 317.7 MiB (16.1%) Init: systemd
  Shell: Zsh inxi: 3.3.21

基盤OSはRHEL7で、プロセッサはXeon Gold 6212U。 ちなみに、ConoHa VPSの基盤はCentOS 7で、プロセッサはXeon E5-2660である。 Xeon E5-2660が2012 Q2の、Xeon Gold 6212Uが2019 Q2のプロセッサということもあり、両者の性能差はかなり大きく、さくらのVPSのほうが速い。

Xeon Gold 6212Uは24C48Tのサーバー向けプロセッサで、TDPは165W。 ベースクロックは2.4GHzで、アーキテクチャはCascade Lake。 第2世代のXeonスケーラブルプロセッサーファミリーで、計算力はほどほどだが処理数は多いクラウドプラットフォーム向けのサーバーに載っているタイプのものだ。

参考としてConoHa VPS

System:
  Host: meconopsis Kernel: 5.19.13-arch1-1 arch: x86_64 bits: 64 Console: pty pts/0
    Distro: Arch Linux
Machine:
  Type: Kvm System: Fedora Project product: OpenStack Nova v: 2014.2-2.el7.centos
    serial: <superuser required>
  Mobo: N/A model: N/A serial: N/A BIOS: Seabios v: 0.5.1 date: 01/01/2011
CPU:
  Info: 3x 1-core model: Intel Xeon E5-2660 v3 bits: 64 type: SMP cache: L2: 3x 4 MiB (12 MiB)
  Speed (MHz): avg: 2600 min/max: N/A cores: 1: 2600 2: 2600 3: 2600
Graphics:
  Device-1: driver: bochs-drm v: N/A
  Display: server: No display server data found. Headless machine? tty: 190x44
  Message: Unable to show GL data. Required tool glxinfo missing.
Audio:
  Message: No device data found.
Network:
  Device-1: Intel 82371AB/EB/MB PIIX4 ACPI type: network bridge driver: piix4_smbus
  Device-2: Red Hat Virtio network driver: virtio-pci
  IF: eth0 state: up speed: -1 duplex: unknown mac: 02:01:85:82:58:fa
  IF-ID-1: docker0 state: up speed: 10000 Mbps duplex: unknown mac: 02:42:f4:fc:67:48
  IF-ID-2: vethadc3e82 state: up speed: 10000 Mbps duplex: full mac: 6a:6a:c6:e7:d7:24
Drives:
  Local Storage: total: 100 GiB used: 21.23 GiB (21.2%)
  ID-1: /dev/vda model: N/A size: 100 GiB
Partition:
  ID-1: / size: 98.24 GiB used: 21.23 GiB (21.6%) fs: ext4 dev: /dev/vda2
Swap:
  ID-1: swap-1 type: file size: 1.91 GiB used: 0 KiB (0.0%) file: /var/spool/swap/swapfile
  ID-2: swap-2 type: file size: 8 GiB used: 14.8 MiB (0.2%) file: /var/swap8
Sensors:
  Src: /sys Message: No sensor data found in /sys/class/hwmon.
Info:
  Processes: 155 Uptime: 20h 25m Memory: 1.93 GiB used: 1.27 GiB (65.7%) Init: systemd Shell: Zsh
  inxi: 3.3.22

コンテナ側ではEFIではなくBIOS扱いになっている。 インストールを若干面倒にするポイントだが、仕方ないだろう。

NICは3つくっついてくる。

カスタムISOからの「OS再インストール」に関しては、特にディスクが初期化されるようなことはないため、繰り返し「OS再インストール」を選択してインストール作業中のリブートを行うことが可能。 通常は必要ないだろうが、archlinuxのインストールでは構成が特殊だと試行錯誤が必要なこともあるので、一発で決めなくて良いのはかなり助かる。 実際、/をBtrfsで切ってしまい、Limineを入れる段階で詰まったけど、しくってやり直すのが難しくなり、再起動するということをした。

新サーバーの基本構成

2GBメモリと200GB SSDのインスタンスを選択。 Discourseを含めた動作でおよそ問題のない規模であり、これはConoHa VPSと同等だ。 200GB SSDのおかげでスワップを大きく確保できるのは大きい。

OSは変わらずArchlinuxを採用した。

GPTディスクにswapと/の2パーティション構成で、ブートローダーにはLimineを採用した。 名前が蛍ちゃんぽくてかわいい5から……ではなくて、BIOSブートの場合Grubは大きすぎて配慮すべき事項が増える。 Limineを採用すると/がExt4に縛られるが、Limine自体はコンパクトにまとまっているので、今回の場合楽だからだ。

以前と比べbaseとbase-develが非常に絞られているので、archlinuxの構築は割と大変になった。

サーバーアプリケーションは基本的にConoHa VPSのものを踏襲した。 Postfix, Dovecot, OpenDKIM, Nginxといったものだ。 DeleGateで構成していた昔とは違い、かなり安牌である。

ConoHa VPS同様、OpenSSHとSystemdの力をフルに活用する。

Chienomi移行

実質「キレて一気に移行した」に近く、じっくり準備したわけではなかったため、Chienomiの移行はかなり困難を極めた。

簡単に言えば、ChienomiはWINGの都合に合わせて「簡単に」作られていたのである。

WINGはNginxの下にApacheが生えている構造で、.htaccessによる制御が可能だ。 Chienomiは長く運営されており、WordPressから移行したという事情もあり、やや複雑なリダイレクトを行っていたりするのだが、その制御を書いてあるほか、アクセス禁止ディレクトリの制御なんかもしている。

さらに、スクリプト内にがっつりハードコーディングしたCGIを3つ配置している (+1, コメント, 検索の3つ)。

NginxでCGIが動作しないし、書き換えようにもRackのCGIハンドラを使っているものと、CGIライブラリを使っているものとがあり、なかなか厄介だ。

そして、手を付けた時点で「何をすべきか」がハッキリしていなかったため、いきあたりばったりの対応になった。

  1. Chienomi用のbareリポジトリを作る
  2. サーブ用のリポジトリをcloneする
  3. Buildディレクトリのpush先にVPSを追加
  4. push
  5. Nginxのサーバー設定をHTTP分だけ追加して再起動
  6. Chienomiのネームサーバーを変更
  7. Let’s Encryptを設定
  8. Nginxのサーバー設定をHTTPS分も設定して再起動
  9. アプリケーションを作り直し
  10. アプリケーション用のSystemd Unitを作る
  11. アプリケーション用の設定を追加して再起動
  12. Chienomiのテンプレートを修正して再ビルド
  13. コミットしてpush
  14. リダイレクトマップを作って再起動

この作業をする前にメールサーバーの整備をして、さくら上でDNS設定も済ませた。

さらっと手順であるように書いているが、前述のとおり行き当たりばったりであったため、なかなか大変だった。 特に、洒落にならないのがアプリケーションの作り直しだ。

3つのプログラムはとても小さなものであり、それぞれインスタンスを立てるのはスッキリしない。 Rack仕様になっていればFastCGIに変更してRackupで起動してもよかったのだが、そうするのもちょっと面倒だ。

そこで、Sinatraを使うひとつのプログラムに書き換え、3つのアプリケーションはそれぞれライブラリに変更した。 さらに、それらのアプリケーションが読み込んでいるライブラリも書き換える必要があった。 WINGでがっつりGemを使うような構成は色々とトリックを使っているので、VPS上ではうまく動かないのだ。

ロジックこそそこまで変わらないが、もともと小さなプログラムなので、CGIからSinatraに書き換えるとなるとほとんど書き直しに近い。

なお、構成は

  • Nginx
  • Unix Domain Socket
  • Thin
  • Sinatra

である。割と情報の少ない構成だったりする。

ともかく、まずアプリケーションはCGIオブジェクトを作る代わりにrequestを受け取るように変更する。 また、随所でprintとかputsとかを呼んでいるので、フローを変更して最終的にレスポンス文字列を返すように変更する。

さらに、ステータスコードを含めた応答をしたい場合にはSinatraはいまいち合わない。 レスポンス周りがRackはいまいちなのでSinatraにしたのだが、何も改善しなかった。

そこで、ライブラリ化されたアプリケーションは200以外を返す場合、それ用に作られたレスポンスオブジェクトを返す形にした。 メソッドがレスポンスオブジェクトを返せば、Sinatraの形に合わせてブロックを終わらせるのである。

特にputsしてraiseしているようなフローだと、最終的に呼び出し元で値を受け取るわけではないのでフロー自体を変更しないといけない。

また、CGIオブジェクトをrequestに変更しても、機械的に置き換えられるわけではなくて意外とめんどい。

そのように変更した上で、辻褄を合わせる呼び出し/受け取りを行うSinatraのアプリケーションを書く。

夜中から始めて4時間ほどかかった。正直、とっても疲れた。 もっと具体的に言うと、22時ころからサーバー構築を始め、1時ころにアプリケーションに着手し、5時ころに終わった。 ネームサーバーを切り替えてしまうともう後戻りできないのだ。

今回の移行でChienomiの通常ページは40〜110%程度高速化した。 WINGはNginxのうしろにApacheを配置してサーブしている関係で静的ページのサーブはあんまり速くない。 場合によっては結構遅いこともある。 さくらのVPSでNginxを使った静的サーブはConoHa VPSよりも少し速いようだ。

また、メールも少し厄介な要素ではあった。 基本的に現状、(VPSのリソースを使わずにスパムフィルタを使いたいので)WINGに転送しているのだが、chienomiはドメイン自体がVPS側に向いたため、chienomiのアドレスに対して転送をかけることができない。 もちろん、転送先アドレスを用意すれば解決できるが、おとなしくvmailboxを使うようにした。 vmailboxを使うのは久しぶり。

まとめ

  • メインサーバーをConoHaからさくらインターネットに変更した
  • ConoHaの現体制は非常に不信感が募るもので、信用できない
  • ChienomiだけはConoHa WINGからさくらのVPSへの移転となった
  • 変わらず使えるようにするための労力は決して小さくはなかった
  • アプリケーションはそうしたフレキシビリティをもたせたものにしておいたほうが良かっただろう
  • サーバーの性能はConoHa VPSよりもさくらのVPSのほうが高い
  • こうしたこともありChienomiのサーブ能力は上がり、より快適に動作6するようになった
  • ConoHaはVPS, WINGともにフレキシビリティに長け、単純に代替することは難しい

おまけ: 私がしくったポイント

設定したり動かしてから「あっ」となった要素。 調査が必要だったものもある。

PostfixがMXレコードを引けず、リレーできない

ConoHa VPSだと自分のアドレスはDHCPで降ってくるので設定不要なんだけど、さくらではそうなってないのでstaticな設定が必要。

そのため、Systemd Networkdの設定をする……というのは、しなければネットがつながらないので忘れようがないんだけど、その状態で普通に名前が引けるのでSystemd Resolvedの設定を忘れてしまった。

nsswitchを使うソフトウェア(getaddrinfo(3)とかを使うやつ)は普通に名前が引けるけれど、/etc/resolved.confが空っぽなので、Postfixは名前を引けない。 Stubモードで動かすのが楽。

ln -sf /run/systemd/resolve/stub-resolve.conf /etc/resolv.conf

SPFがFAILになる

DKIMはディレクトリごとコピってくるならそのままレコードもコピればいいんだけど、SPFのほうはアドレスが含まれているので単純にコピっちゃうとFAILになる。

初歩的なミスだけど、ぼーっとした状態で機械的にやってミスった。

Discourseが更新できない

GitHub上のDiscourseのリポジトリのmasterがmainになってて、Refが取れなくなってたのが理由。

もっとも、最終的にはどうやっても更新できなくなってしまい、バックアップも取れなくてある程度諦めた。

いままで送受信できていたメールアカウントが使えない

virtualを使うようにすると頻繁にDovecotがPAMの認証上限にひっかかってしまうのが嫌で、systemを外したのだけど、システムアカウント経由でメール送るようになっていたやつがいた。

ちなみに、systemを使わないようにすると、システムユーザーのメールボックスにはIMAPアクセスもできないので、基本的にaliasesで転送することになる。 転送先はバーチャルアドレスである。

ちなみに、$myhostnameや$mydomainにプライマリドメインを活かしつつ、DovecotのPAM認証を行わず、プライマリドメインもバーチャルメールボックスに配信したい場合、Dovecotのpasswdファイルにプライマリドメインの分も書いて、aliasesに配信先を書く(Dovecotと一致するように)という方法がある。

4.7.1 Service unavailable - try again later (Postfix)

milterが落ちてる。

OpenDKIMはものすごく無口でなにひとつ出力してくれなくて苦労した。

原因は今回メールをシングルドメインからマルチドメインに変更したのだけど、OpenDKIMの設定に一部矛盾があり(シングルドメインのときのが残っていた)、うまく動作しなかったため。

554 5.7.1 <ADDR>: Recipient address rejected: Access denied (Postfix)

SMTPの認証を有効にし忘れている。

この問題の原因はかなり幅広くて、例えばlocalの問題や、SASLの問題、smtpd_*_rejectionの問題とかもここに繋がってくる。

そのためにサーバーの問題だと考えて結構時間を使った(今回一番時間かかった)のだが、実はクライアントの設定という単純な問題だった。

実はClaws Mail/Sylpheedはアカウント設定時にわざわざ「送信」タブに移動してSMTP AUTHを有効にしないとSMTP認証しないという仕様であるため、割とやりがち。 milterの問題も同時に発生していたことが解決を遅らせた。

Chienomiで検索ができないことがある

Nginxの設定でHTTP側にディレクティブを書き忘れていたため。

なお、とりあえずChienomiのHTTPを復活させたが、需要がなさそうならまたHTTPSのみに戻す。 ConoHa WINGはTLS 1.3を強制するため、ちょっと古い環境だとアクセスできなかったりする。 つまりChienomi、これまで古い環境には厳しかった7のだ。

メールがメールボックスに届かない

Dovecotのpasswdファイルで指定されているメールボックスが、コピった行のままになっていて、他のメールボックスを見ていたため。

つまり、「実際には届いているメールが、IMAPで届いてないように見える」という状態。

メールボックス置き場をls -lRすれば簡単に見つかるほか、Dovecotのpasswdファイルを眺めても発見できる。

メールの配送に失敗する

vmailboxの設定でMaildirに/をつけ忘れていたため。 正直、ものすごくよくやる。

エラーメッセージが明確なので発見・修正は容易。

メールアドレスがない扱いになる

postmap vmailboxし忘れ。

おまけ2: なんで複製しないの

システムの複製、別にできなくはない。 というか、Archwikiにちゃんと記事がある。

話をある程度簡単にするならば/bootも別に切っておくべきで、その上でインストール後に/を複製する。 これでブートの問題も解消できる。

これをするためには外部ディスクでシステムを起動できる必要があるから、複製可能なVPSというのはだいぶ限られる。 ただし、さくらのVPSはカスタムISO起動で簡単に実現可能で、イメージ起動ができるVPSなら基本的にできる。

確実に修正が必要なのは/etc/fstabで、おそらくブートローダーオプションの修正も必要になる。 今回のケースのように異なるブートローダーへ移行するような場合はさらに難しい。

また、構成によっては/etc/crypttabや/etc/mdadm.confなどはバックアップしておいて戻すのが楽かもしれない。 いくつかのファイル、例えば暗号化キーなどは退避が必要となる。

固定IPアドレス運用ならSystemd Networkdの設定の修正も必要かもしれない。 その他ハードウェアや元サーバーのIPアドレスに依存しているものがあるならば修正が必要だ。

という感じでできなくはないし、そこまで難しい話でもないのだけど、「複製は汚れ度合いを増加させる」という問題がある。

基本的に運用中、あるタイミングで必要になったものがやがて必要でなくなる、みたいなことはよくある。 あるいは、使っていたものを使わなくなることもある。 長く生きてるサーバーはどうしてもゴミは少しずつ増えていく。 ログやキャッシュも捨てられるかどうかを判断するのは難しいから、こうしたものもディスクを圧迫する。

また、Archlinux自体もローリングリリースであるが故に非常に長期に渡ってクリーンナップせずに運用することが可能だが、アップデートを繰り返していくとゴミパッケージやゴミファイルがどうしても残る。

サーバーの引っ越しというのはそんなに頻繁にするものでもないし、正直多少の手間は気にならない。 むしろ、数年おきに自分の腕試しとして、現在の知識で最適化した構成を作り上げることで、自分の成長を確認できるチャンスでもある。

今のサーバーもPostfixとDovecotはだいたいServerMan時代の遺物だし、Nginxに関しても2017年に採用してからまっさらにしたことはないので、正直汚いとは思うのだが、ServerMan時代は設定したのをまっさらにして書き直す自信がなく、恐る恐る運用していたのと比べれば、今は別に全部なくなっても1日か2日かあれば作り直せるから気も楽だし、やはり成長したと感じる。

それに、サーバー構築は時々やっておかないと、勘所を忘れる。 実働サーバーの構築8というのは機会はそれほど多くないものでもあるので、心機一転クリーンに仕上げてスッキリしたいのだ。