さくらのVPS、Ubuntu 20.04環境へのMastodon「再構築」の話
先日より長らく、分散型SNS「Mastodon」にて運営しております私専用のおひとり様サーバ「Telmina One」が停止しておりました。
昨日・2022年11月19日、それを復旧、より正確には新規に構築してデータを移設致しました。
後学と備忘のため、そのときの作業記録について、覚えている範囲でメモに残します。
なお、今回は停止してしまったサーバのメディアやデータを新サーバに移設することが目的のため、最低限、旧サーバの下記の情報のバックアップを取得しているという前提です。
- データベース(PostgreSQL)のダンプ
- メディア一式(
/home/mastodon/live/public/system/
ディレクトリとその配下) - 設定ファイル(
/home/mastodon/live/.env.production
) - テーマファイル一式があればそれらについても
/home/mastodon/live/app/javascript/system/
配下に設置したカスタムテーマファイル類/home/mastodon/live/config/themes.yml
/home/mastodon/live/config/locales
においてカスタムテーマを設定したファイル
- Faviconやその他イメージがあればそれらについても
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 replaceexample.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
を参照しながら設定します(これを直接新サーバに持って行くわけではありません)。
特に注意すべき項目として、下記を挙げることができます。
SECRET_KEY_BASE
およびOTP_SECRET
- これらについては、必ず旧サーバの
/home/mastodon/live/.env.production
の同じ項目の内容に書き換えておくこと。
- これらについては、必ず旧サーバの
SMTP_*
- ご自身の環境に合わせて。私の場合、旧環境では「さくらのレンタルサーバ」のSMTPサーバを使う設定にしているため、新環境でも同じようにするために、
SMTP_*
の全項目を転記した。
- ご自身の環境に合わせて。私の場合、旧環境では「さくらのレンタルサーバ」のSMTPサーバを使う設定にしているため、新環境でも同じようにするために、
DEEPL_API_KEY
およびDEEPL_PLAN
- この2つの項目はもともと
/home/mastodon/live/.env.production
に入っている項目ではなく、Mastodon v4.0.0以降に導入された翻訳機能を利用するときに追記する必要のある項目。 - 翻訳機能を有効化させるためには、下記の手順を踏む必要がある。
- 「DeepLのAPI翻訳」に登録する。
- とりあえずは無料プランでよいが、無料でもなぜかクレジットカード番号の入力を求められる。
- 下記トゥートを参考に、
/home/mastodon/live/.env.production
を編集する。
- 「DeepLのAPI翻訳」に登録する。
- この2つの項目はもともと
そのほかの項目については、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の設定などをおこなえば、晴れてサーバ運営再開となります。
最後に
今回は、事前作業まで含めるとまるまる一日がかりの作業となってしまいました。
順調に行けばたいしたことはないと思うのですが、主に下記の点でつまずいてしまいました。
- OS初期設定でSSH鍵認証が通らなかった点
- NginxとSSLまわり
なお、今回は次の3名の方よりアドバイスを頂戴しておりました(順不同)。厚く御礼申し上げます。
- くろりんご氏( @kuroringo@mastodon-japan.net )
- とねぢ氏( @toneji@minohdon.jp )
- hinketu氏( @hinketu_n@gamingjp.org )
特にhinketu氏には、SSL周りについて時間を割いて助けていただきました。
多くの方のご協力によって何とか復旧できたマイお一人様サーバは、私自身の言論の自由の確保にとって、もはやなくてはならないツールです。
今度は自分がほかの方や将来の自分自身のお役に立てるように、場数を踏んでおきたいところです。
なお、来月に入ってからになりますが、マイお一人様サーバ「Telmina One」とは別に運営しているリベラル専用コミュニティ「LIBERA TOKYO」におきましても、恐らく今回と同様の作業をおこなう必要が生じると思います。そのときには、もしかしたら今回書き漏らしている重要な点もあるかも知れませんので、その辺りについてもキャッチアップできればと思います。
#2022年 #2022年11月 #2022年11月20日 #お知らせ #業務連絡 #Mastodon #マストドン #SNS #分散型SNS #Fediverse #復旧