さくらのVPS、Ubuntu 20.04環境へのMastodon「再構築」の話

先日より長らく、分散型SNS「Mastodon」にて運営しております私専用のおひとり様サーバ「Telmina One」が停止しておりました。

　昨日・2022年11月19日、それを復旧、より正確には新規に構築してデータを移設致しました。

　後学と備忘のため、そのときの作業記録について、覚えている範囲でメモに残します。

　なお、今回は停止してしまったサーバのメディアやデータを新サーバに移設することが目的のため、最低限、旧サーバの下記の情報のバックアップを取得しているという前提です。

VPS新規契約

　今回の復旧作業にあたり、万が一のことを考えて、停止してしまった旧サーバについては作業終了まではそのままにしておきたかったため、新規に運用するためのVPSを新たに1台分契約しました。

　今回も、さくらのVPSの2Gプランを選択しました。

VPS初期設定

　当初、「Ubuntu 22.04 amd64」を選択するつもりでしたが、どういうわけか、これを選択すると、SSHの公開鍵と秘密鍵のペアが正しいにもかかわらず、SSHログイン時の鍵認証に失敗してしまいます。

　そこで、Mastodon公式のインストール方法でも推奨されている「Ubuntu 20.04」を選択しました。

　こちらであれば、鍵認証も問題なくできました。

　なお、今回は、さくらのVPSで提供されているスタートアップスクリプト「Setup and update」を適用致しました。

　もちろん、最低限のポートのみを開け、また、パスワード認証によるSSHログインやrootでのログインを禁止する措置を講じました。こちらにつきましてはネットを検索すればたくさん記事がヒットすると思いますので、ここでの説明は割愛させていただきます。

ドメインネームサーバの設定変更

　「Telmina One」のドメインは「one.telmina.com」です。こちらについても、旧サーバから新サーバに向き先を変更しました。

　また、今回はIPv6を有効化させることにしましたので、AAAAレコードの設定もおこないました（これまではおこなっていなかった）。

「Mastodon」および依存モジュール一式のクリーンインストール

　基本的には、公式ドキュメントを含む下記の2記事を参考とさせていただきました。

　しかし、2番目のほうの記事の方法でもうまくいかなかったところがありますので、そこを中心に自分が執った措置について記録したいと思います。

　公式ドキュメントの流れに沿ってみていきますが…

Pre-requisites

　こちらについては、基本的には記載のとおりにおこないました。

　ただし、「Installing Ruby」の箇所で、インストールするRubyのバージョンを、3.0.3から3.0.4に変更しています。

Setup

Setting up PostgreSQL

　基本的には記載のとおり。

　なお、データベース名については初期状態から変更しています（旧サーバに合わせるため）。

Setting up Mastodon

　こちらも記載通り。

　なお、記載通りの方法で、現行最新バージョンのv4.0.2が適用されました。

　「.env.production」については、いったんセットアップが終わったあとで編集することにしました（後述）。

Setting up nginx

　今回のセットアップ作業の鬼門でした。

　下記のところでつまずいてしまいました。

Then edit /etc/nginx/sites-available/mastodon to replace example.com with your own domain name, and make any other adjustments you might need.

Reload nginx for the changes to take effect:

　言われたとおりに、「/etc/nginx/sites-available/mastodon」内に4カ所ある「example.com」を自分のドメイン（one.telmina.com）に書き換えてnginxを再起動させようとしても、エラーが出てうまくゆかなかったのです。

# systemctl restart nginx.service 
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.

　言われたとおりに「systemctl status nginx.service」や「journalctl -xe」を実行してみても、さっぱりワケがわかりません。

　「sudo nginx -t」コマンドを打ってみたところ、こんなことを言われてしまいました。

# sudo nginx -t
nginx: [emerg] no "ssl_certificate" is defined for the "listen ... ssl" directive in /etc/nginx/sites-enabled/mastodon:25
nginx: configuration file /etc/nginx/nginx.conf test failed

　「いやそりゃ当たり前だろ。まだ『Acquiring a SSL certificate』実施手前だぞ」と思ったものの、ここで足踏みしていては永久に先に進めません。

　仕方なく、言われたとおりに、/etc/nginx/sites-enabled/mastodonの25行目から始まっているセクション内でコメントアウトされている「ssl_certificate」関連の行2行を有効化させましたが、今度は別のエラーが出てきてしまいました。

# sudo nginx -t
nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/one.telmina.com/fullchain.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/one.telmina.com/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)

　「だからそりゃ当たり前だろ。まだ『Acquiring a SSL certificate』実施手前だぞ」と思ったものの、そこで先ほど編集したばかりの行をコメントアウトすると延々とnginx再起動失敗地獄から抜けられません。

　そこで、とりあえずいったんエラーが出た状態のままnginxを再起動し、「Acquiring a SSL certificate」を片付けることにしました。

Acquiring a SSL certificate

　こちらについては、/etc/nginx/sites-enabled/mastodon内の「ssl_certificate」関連の行2行を有効化させた状態で実施しましたが、公式通りにコマンドを打っても成功しませんでした。

　自分の作業ログによると、下記のコマンドを打って認証に成功させたことになっているのですが、なぜこれを打ったのかは思い出せません（苦笑）。

certbot certonly --standalone -d <自分のドメイン>

　私の場合は

certbot certonly --standalone -d one.telmina.com

となります。

Setting up systemd services

　SSL周りの設定がやっと終わり、あとは最後の仕上げです。

　これで、公式ドキュメントの最後まで進めることができ、無事Mastodonの画面が起動したのですが、こちらの作業としてはまだ重大なものが残っています。

旧サーバの設定やメディア、データの書き戻し

　これらはやり方がわかっていればどうってことないのですが、とにかく時間が掛かります。

旧サーバの設定取り込み

　旧サーバから持ってきた/home/mastodon/live/.env.productionを参照しながら設定します（これを直接新サーバに持って行くわけではありません）。

　特に注意すべき項目として、下記を挙げることができます。

　そのほかの項目については、Mastodon初期設定の段階で設定している値を編集する必要はないと思います。

メディアの書き戻し

　事前に旧サーバから取得している、/home/mastodon/live/public/system/ディレクトリの内容をそのまま書き戻します。

　こちらについては説明を割愛します。

　なお、Favicon等については、旧サーバの/home/mastodon/live/public/から持ってきたものをそのまま新サーバの同じ場所に格納すればよいと思います。

テーマファイル一式の再設定

　今回はMastodon v4適用後初めてのリプレイスとなったのですが、v4とそれ以前でユーザインタフェイスが大きく変わっており、バックアップしたテーマファイルをそのまま適用というわけにはゆきそうにありません。

　これについては、編集すべきところをご自身で確認していただく必要があるため、個別の説明は無理です。自分はスタイルシートのカラー設定だけ変えたので、編集は楽でしたが…。

　もちろん、テーマをカスタマイズしておらず、標準テーマのみを使用している場合は、テーマファイルの書き戻しについては何も考える必要はありません。

データベースの書き戻し

　ここでしくじったらこれまでの苦労が水の泡です。

　幸い、自分は何とか無事に終わらせることができましたが。

　手順としては次のとおり。

　なお、データベースのバックアップを取得するときに「pg_dump」コマンドを用いているという前提で話を進めます。

　まず、事前に旧サーバから取得したデータベースのダンプファイルをサーバ内に配置します（これが結構時間かかる…）。

　次にユーザをrootに切り替えます。

$ su -

　念のため、Mastodonのプロセス一式を止めたほうがよいでしょう。

# systemctl stop masotodon-*

　postgresユーザに切り替えます。

# su - postgres

　下記のコマンドを打ち、データベースmastodonの所有者がmastodonになっていることを確認します。

$ psql -l

　確認できたら、データベースに入ります。

$ psql

　既存のデータベース「mastodon」の内容を削除します。

postgres=# drop database mastodon;

　その後即座に、下記のコマンドを発行して、既存のデータベース「mastodon」のプロセスがないことを確認します。

postgres=# SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'mastodon' AND pid <> pg_backend_pid();

　戻り値が0になっていれば先に進み、それ以外の場合は再度drop database mastodon;からやり直します。

　データベースを作り直します。

postgres=# create database mastodon OWNER mastodon;

　PostgreSQLから出ます。

postgres=# \q
$ psql -l
$ exit

　root権限に戻ったら、ユーザをmastodonに切り替えます。

# su - mastodon

　そして、データベースmastodonに、データを書き戻します。

$ psql mastodon < <バックアップしたデータベースのダンプファイル>

　書き戻したらrootに戻って、nginxとMastodonのサービスを再起動します。

$ exit
# systemctl restart nginx.service
# systemctl restart masotodon-web.service 
# systemctl restart mastodon-web.service sidekiq.service 
# systemctl restart mastodon-sidekiq.service treaming.service

　あとは必要に応じてcronの設定などをおこなえば、晴れてサーバ運営再開となります。

最後に

　今回は、事前作業まで含めるとまるまる一日がかりの作業となってしまいました。

　順調に行けばたいしたことはないと思うのですが、主に下記の点でつまずいてしまいました。

　なお、今回は次の3名の方よりアドバイスを頂戴しておりました（順不同）。厚く御礼申し上げます。

　特にhinketu氏には、SSL周りについて時間を割いて助けていただきました。

　多くの方のご協力によって何とか復旧できたマイお一人様サーバは、私自身の言論の自由の確保にとって、もはやなくてはならないツールです。

　今度は自分がほかの方や将来の自分自身のお役に立てるように、場数を踏んでおきたいところです。

　なお、来月に入ってからになりますが、マイお一人様サーバ「Telmina One」とは別に運営しているリベラル専用コミュニティ「LIBERA TOKYO」におきましても、恐らく今回と同様の作業をおこなう必要が生じると思います。そのときには、もしかしたら今回書き漏らしている重要な点もあるかも知れませんので、その辺りについてもキャッチアップできればと思います。

Telmina One

#2022年 #2022年11月 #2022年11月20日 #お知らせ #業務連絡 #Mastodon #マストドン #SNS #分散型SNS #Fediverse #復旧