メインサーバーのリプレイス

Live With Linux::server

TOP
Articles
Live With Linux
メインサーバーのリプレイス

序

メインサーバーをConoHaで新インスタンスに建て替えた。

主な目的はストレージ50GB時代のインスタンスだったので、100GBの新インスタンスに置き換えることと、従来1GBプランだったのを2GBプランにすること。

今のConoHaインスタンスはDTI時代から引き継いできた設定があったり、現在は使っていないアプリケーションのデータがあったりするため、マイグレーションではなく再構築した。そして、いくつかの思わぬ問題に遭遇した。

なお、今回もArch Linuxによるサーバーである。

また、メインサーバーはほとんどの人にとって今や意識するような存在ではない(このChienomiもConoHa WINGでホストされている)。 WINGでは難しいことをやるためにあるのがメインサーバーだが、ウェブやメールはWINGでやってしまいっているので、外側でメインサーバーを意識する人は少ない。もちろん、私自身はなくてはならないものだが。

hash作るの忘れないように

忘れちゃいけないと思っていたのにやらかした。

aliases (/etc/postfix/aliases)やvirtual (/etc/postfix/virtual バーチャルドメイン用のマップファイル)は作り直したのだが、aliasesに関してはnewaliasesしないといけないし、virtualのほうはpostmap virtualしないといけない。

で、これを忘れたわけだ。

なお、Postfixの設定は新旧のファイルを両方取得してMeldでマージするという方法をとった。 Meld、便利なのでおすすめ。

Dovecotの設定がない

Dovecotをインストールして/etc/dovecot自体が生成されないという事態になり、戸惑ってしまった。 Dovecot周りの設定は全体を移植することとなった。

PostfixがDNSを引けない

名前解決自体はできるのに、MXレコードが見つからないといって外部に転送できない。

原因は/etc/resolv.confが空であることにあった。

Arch Linuxの場合systemd-resolvedを使うようになっており、本来/etc/resolv.confはsystemd-resolvedが生成する (デスクトップの場合はNetwork Managerが/etc/resolv.confを生成し、systemd-resolvedはそれに従うのが一般的)。実際、従来のインスタンスも/etc/resolv.confはsystemd-resolvedによって生成されている。

失敗はしなかったけど、要注意だったところ

ユーザー周り

Dovecotやメール用のユーザー、サーバーの通常ログインしないユーザーなどはuid/gidが変わると事故の元なので、慎重に進める必要がある。

特にユーザーグループを使う場合、単純にuseradd -U -u 10000 fooとかやってもfooグループのgidは10000にならないので、groupadd -g 10000 fooと事前にした上でuseradd -N -u 10000 -g foo fooとする必要があり、このあたりに注意が必要。

Discourse

うちのメインサーバーは現時点で公開こそしてないものの、Discourseを使っている。

Discourse Dockerを使っている場合、元のほうで

./launcher enter app
discourse backup
exit
rsync -av /var/discourse/shared/standalone/backups/default/ foohost:/path/to/backup/dir/

とかやればバックアップできるんだけども、Discourseの構築のほうを忘れがち。基本的な準備は、公式の手順をかいつまむと

Dockerを起動
github.com/discourse/discourse_docker.git を /var/discourse にクローン

でlauncher(/var/discourse/launcher)が使えるようになるんだけども、

./launcher bootstrap app
./launcher start app
./launcher start app

でようやくセットアップされることに注意が必要。ここまでやって初めて/var/discourse/shared/standaloneが生成されるので、以下/backups/default/にファイルを配置して、

./launcher enter app
discourse enable_restore
discourse restore your-site-2020-10-23-150405-v20200101150405.tar.gz
discourse disable_restore
exit

って感じ。

そして、これをやる前にウェブサーバーの設定をしておく必要があったりする。 Dockerがフロントで待たない設定になっている場合(Unixドメインソケットで待ち合わせてるとか)、サーバーの設定の継承に注意しないといけないので慎重にやること。 Discourse側の設定はこの作業で復元されるから、ウェブサーバーを元と同じにすれば良い。

Systemd

/etc/systemd/system/とか~/.config/systemd/user/とかをコピーするのを忘れないように注意。 (あと/usr/local/とか~/.localも)

で、コピーして安心ではなく、例えばtimerユニットとかはtimers.target.wantsがコピーされていれば有効になっているはずなんだけど、なぜか有効になってなかったりするので、そこらへんを再確認する必要もあり。

おまけ

古い、 /journal のつくアドレスは今までリダイレクトしてこなかったんだけど(というか、以前はしてたけど、最近はしなくなってた)、未だに結構アクセスがあるみたいなので、Chienomiにリダイレクトするようにした。まぁ、アクセスしてるのはGoogle botなんだけどね。

もうひとこと

サーバーの構築、最近あんまりやってなかったので、ちょっと戸惑ってしまった。

特に、メインサーバーのほうは2017年に今のサーバーになって、それからいじってなかったし、2017年に構築するときはDTIから引き継いだ要素も多かったから。

もちろん、DTIはCentOSで、ConoHaはArch Linuxなのでまんま引き継いだわけではないし、ウェブ周りはDeleGateからNginxに変わったから全く引き継いでないんだけど、サーバー構築手順がDTIを再現するようなものになっていたから、ちゃんと考えてなかったんだよね。

そもそも2017年時点では今ほどLinuxに対して理解が深かったわけではないし、DTIを構築した2014年ならなおさら。サーバーの構築数だと2017-2019年にかけてかなり多かったんだけど、サーバーの構築自体は慣れたものでも、メインサーバーがどんな構成になっているか覚えてなかったし、割と手探りで、だいたい3時間ほどかかり、Postfixの名前解決の問題はそのうち1時間くらいを占めた。

ただ、この構築作業だけ見てもArch Linuxはほんとに楽。 CentOSとかUbuntu Serverだともっとずっと苦しい。