序

割と最近、メインサーバーはConoHaから転出しさくらへ移転したのだが、さくらに満足しているわけではないため、より良いサーバーを探していた。

そして、Stellanautで使っているVultrが非常に高速で気に入ったため、メインサーバーとして使おうと考えた。

さくらが気に入らないのは、インスタンスの作成・破棄がかんたんにできず、事実上初期費用も必要で、月単位の課金になっているという旧態依然とした点や、インフルエンサー商売をしていることなどだ。 ConoHaと同様ではあるが、内部接続100Mbpsというのも気に入らないし、IPv4が1個だけ(IPv6はない)というのも古臭い。

こうしたことからさくらよりも良いサーバーがあれば移るつもりでいたし、Vultrが気に入ったので移ることにしたわけだ。 だが、いくつか障壁もあったため、紹介していく。

なお、今回もVultrでAMD High Performanceサーバーを借り、Archlinuxイメージでインストールを行った。

疎通不能 (ファイアウォール)

以前の記事でも書いたが、VultrのArchlinuxはデフォルトでufwが有効になっており、HTTPなども疎通しない。

デフォルトのufwのルールは特に(Vultrのファイアウォールを利用している場合は)有用ではないため、切ってしまっていいだろう。 個人的にはufwではなくiptablesを使ってきているので、その意味でもオフにした。

タイムゾーン

国内のVPSでは起きないことなので失念していたが、VultrのArchlinuxのデフォルトタイムゾーンはESTである。

JSTに合わせる場合

timedatectl set-timezone Asia/Tokyo

とする。

再起動は不要。

メールサーバーとOP25B

Vultrのファイアウォール設定にメール関連がないため、メールの設定はかなり面倒なのが、それ以上に問題なのが、VultrはデフォルトでOP25Bをかけているということだ。

これはサポートへの連絡が必要で、サポートから “Open Ticket” -> “SMTP Port Unblock” と進み、必要事項を入力してチケットを作成する。

ちなみに、事業者名等も必須である。 Personalなものだという選択肢はない(Individualという区分はある)。

向こうがESTと時差が大きいため、連絡はなかなか進まない。

ちなみに、最初の応答は向こうが営業時間になってすぐに返ってきたのだが、チケット作成時に聞かれた内容をまた聞かれる。 おそらくテンプレートだと思うのだが、これを聞くなら最初に入力させる理由はなんなのか。

Hello,

We have received your SMTP Unblock request. However before we can remove this block, we must verify additional information.

Please reply to this ticket with the following information:

1. The business name and organization URL(s) under which you offer services.
2. Describe, in as much detail as possible, the nature of the emails you intend to send.
3. The volume of email that you plan to deliver on a daily/monthly basis.
4. Please confirm if the emails that you will be sending will include marketing promotions, newsletters, coupons, account related notification, etcetera.

All accounts are asked to provide additional and detailed information when requesting this block be lifted. We appreciate your patience and understanding regarding this matter.

Please let us know if you have any questions.

商業利用ではなく個人的な利用であることを説明した。 daily/monthlyのメールの数に関しては、実績値として

journalctl --since 2023-02-01 --until 2023-02-02 -u postfix | grep sent | wc -l

のようにして1日分(2月1日の分)を、

journalctl --since 2023-02-01 --until 2023-03-01 -u postfix | grep sent | wc -l

のようにして1ヶ月分(2月の分)を算出して提示した。 なお、かなり数が多いが、

Email is only for my personal use to forward incoming mail to my email provider, or to reply to personal emails, or to contact customer support. It is not for business use.

と説明した。

JSTの翌日7時ころ

Hello,

Thank you for the information provided!

We have removed the default SMTP block on your account. Please re-start your instances via https://my.vultr.com, for the change to take effect (re-starting the server itself will_not work).

If you need further assistance, please do not hesitate to contact us. Our support staff is here and happy to assist you.

とのメッセージがあり、

OP25Bに最初気づかず、結構な数のメールがdeferredになってしまっていた。 気づいてaliasesを書き換えて、一時的に内部のメールボックスに配送するように書き換えたが、すでにメールキューにあるものは更新したaliasesは効かない。 とりあえず一旦、メールキューを確認

postqueue -p

退避させる。

postsuper -h ALL

無事にブロックが解除されたらaliasesを戻して反映、

postsuper -H ALL

としてキューに復元すれば良い。 即時キューを消化するには

postfix flush

SinatraとRack

Rubyウェブアプリケーションの話。

AURのRackは3.0に上がっているが、SinatraはRack 3.0に対応しておらず、AURのSinatraのバージョンが最新ではないため、 AURに頼らず

gem install --no-user-install sinatra

とする必要がある。

AURのRubyパッケージはやや微妙なことが多い気がする。

PTRレコード

試しにGmailにメール送ってみたら、IPv6アドレスはPTRがないとだめだと怒られたので、PTRレコードを追加する。 複数のドメインで1台のホストなので、どうしたものかという感じではあるけれども。

IPv6のPTRは出すのがかなり大変なので、ipv6calcを使った。

ipv6calc --in ipv6addr --out revnibbles.arpa 1111:1111:1111:1111:1111:1111:1111:1111

という感じでやれば良い。

しかし、設定したところで引きに来てはくれないので、意味がないのでは？ と気づいた。 IPv6は引けないが、IPv4のほうはVultrで引けるので、main.cfで

inet_protocols = ipv4

しておいた。

また、CloudFlareがインポートしたDNSレコードにセレクタつきのDKIMが含まれていなかったので、それも修正した。

サーバーはウェブだけじゃない

Vultrにはじまったことではないが、サーバーで提供するサービスがwebの前提となっており、非webのプロトコルが想定していないように感じられる。

だが、サーバーはウェブだけじゃないし、ウェブが目的であればVPSやIaaSである必要はまるでないのだ。

インターネット=ウェブという風潮はとても嫌いで、改善されるべきだと思っている。

また、既にeメールは大手プロバイダがプライベートなサーバーを拒否するようになっており、疎通の確実性がなく、大手プロバイダーが独占的に扱う特権メディアと化している。 eメールに代わる(プライバシーを守る)メディアがないにも関わらずだ！

こうした点も是正されるべきだと考えている。

なお、CloudFlareはメールに対するケアも手厚く、非常に好感が持てる。

AkkomaもVultrへ

つい先日ConoHa VPSで立てたAkkomaサーバーだが、ConoHaである必要性がなくなったため、Misskeyをホストしているサーバーに同居という形で移設した。

これは、性能的にメモリ容量を除けばMisskeyサーバーにかなり余裕があることから、同居させることでコストダウンを狙っているのだが、同時に常時リソースが激しく使われるような状態ではないことから、サーバー強化時に両方に恩恵が出るというメリットもある。

複数のアプリケーションをひとつのサーバーで稼働させることはそこまで特殊な話でもないが、1台にふたつのSNSを稼働させるのは稀だろう。 デメリットはもちろん、同じようなリソース要求をするものがふたつあることで、特定のリソースが逼迫しやすいという問題があるし、分散・スケールさせるべきものを複数同居させるというのは変な話にも思える。もちろん、冗長性も低下する。片方の障害が両方に影響するのだ。

だが、小規模なFediverseインスタンスの場合、ほとんどの時間は利用がわずかにすぎず、リソースは有り余った状態である。 異なるインスタンスではいくらかピーク時間がズレることもあり、単純にパワーがあるサーバーにしたほうが強いというケースが多い。 これは、限られたリソースでやりくりしなければならない小規模個人サーバーならではの事情だ。 また、小規模個人サーバーであれば一時的にダウンしたとしてもそこまで大した話ではないので、過剰な可用性は必要ない。

こうした要件に応じた対応ができる柔軟性は必要だ。

これでまたConoHa VPSの台数は0となり、コストダウンを実現したと同時に、同額をVultrに投入すれば性能を倍にすることができる。

ついでにもうひとつ

これに続いてもう1台、Vultrのサーバーを追加した。 同じくVultrのAMD High Performanceサーバーで、Tokyoリージョンである。

こちらは将来的にはConoHa WINGのメール機能を代替することが想定されているものだ。

ConoHa WINGはレンタルサーバーであり、ConoHa WING自体の機能としてはウェブとメールとなる。 ただ、ConoHa WINGそのものがrootレスVPSのような形で、ユーザーの権限は自身のホームディレクトリに限られているが、仮想のユーザー専用環境となっており、他のユーザーと干渉しない。 WING環境は完全に放置されているので、私はRuby 3.1を自前でインストールし、運用している。

Apacheのログをホームディレクトリ以下に吐くこともできるため、webサーバーとしてはかなり使える。

また、メールアドレスは特に制限がなく作ることができ、転送も可能。 迷惑メールフィルタリングもされる。

このため、レンタルサーバーとは思えない非常に強力なプラットフォームではあるのだが、あくまでレンタルサーバーとしては、に過ぎない。

ConoHa WINGは一見非常にパワフルなプラットフォームだが、実際はユーザーから見えるリソースに対してユーザーが使えるリソースは非常に限られており、さらにNginx+Apacheという実際あまり性能も出ていない。

メール機能も、メールエイリアスは作れずボックスが必要である上に、転送は書きづらく、迷惑メールフィルタの精度は悪く、コントロールもしづらい。 結局のところいくらか手間が省けるだけで、VPSのほうが良いことに変わりはないのだ。 もう、ConoHaにサーバーを残しておきたくない気持ちだし、VPSに移すことで活用できる幅も広がる。

また、ConoHa WINGはちゃんとメンテナンスされていないため、どのみち現環境を長く維持することはできない。

メインサーバーは要求に対して十分な余剰リソースを持っている。 多くのウェブをホストするのに十分なパワーだ。それはRailsアプリケーションであるDiscourseを含んでいる。 リソース的な問題だけから見れば、メインサーバーにすべてを集約することも可能だ。

だが、私の管理するウェブサイトはとても多く、かなり複雑だ。 その移行はかなり難しい要素を持ってはいる。

そもそもConoHa WINGに合わせているため、自動化やアプリケーションの適合作業が大変なのだ。 これはWINGから出たい理由のひとつでもあり、WING専用の作り込みを増やしたくないところだ。

PureBuilder Simplyは静的ファイルを生成するため、小さな多くのアプリケーションと組み合わせると良い結果になる。 そして、そのようなアプリケーションを作るにはCGIは適している。それを活かしてConoHa WINGをハードに活用していたのだが、移行するとなるとCGIをどういう環境で動かすかという課題もある。 もちろん、Chieomiがしたように非CGIのアプリケーションとして移植することも可能だが、CGIが動かせたほうがさっと作れて便利だ。 これは、Nginxの後ろに(ConoHaがApacheを動かしているように)もうひとつサーバーを置くのが早い。Lighttpd, Hiawatha, Mighttpd2あたりが有力候補だろうか。

そして、このような複雑なウェブページをホストするサーバーに、さらに複雑なメールサーバーをもたせるのはかなり筋が悪い。 私には1000を越えるメールアドレスがあり、それぞれ転送する側、転送される側など関係性も複雑だ。 そこで、メールサーバーを独立させるわけだ。コントロールしやすくすると同時に、メールサーバーはリレーの関係上止めるのが難しいため、他のサーバーと分けることで可用性の問題を低減している。

メインサーバーは2014年に新規に組み直してからは基本的に継ぎ足しでやってきたため、構築は結構時間がかかった。 特にメールまわりは今までVirtual対応, SPF対応, SSL対応, CRAM-MD5対応, DKIM対応, セキュリティの強化と順次進めてきたため、一気にやるとなかなか大変だった。

このサーバーの構築の詳しい話は、また機会があれば書こうと思う。