14 KiB
| title | date | draft | tags | |
|---|---|---|---|---|
| かゆいところに手が届くインスタンス運用の初級テクニック集 | 2023-07-22T20:47:25+09:00 | false |
|
ソロインスタンスを建ててそろそろ2週間が経とうとしている。おかげさまで絶好調だ。本稿では僕がMastodonインスタンスの運用を改善していく上で、手頃ながら日本語情報が乏しかった情報について取り上げる。
SSLの対応をCloudflareに丸投げする
前提
・運用中のドメインをCloudflareで管理しているか、またはネームサーバを向けている。
・CloudflareのSSL/TLS設定で暗号化モードを フル（厳密） に設定している。
各種の文献ではインスタンスを建てる過程でLet's Encryptを紹介しているものが多い。確かにこの証明書は様々な用途において気安い選択肢だが、反面、3ヶ月に1回の更新作業が地味に面倒だったり、cronで自動化してもなぜかcertbotがコケていたりと微妙な使い勝手の悪さは否めない。
そこで、僕はSSLの対応をCloudflareに丸投げすることを提案したい。多少の面倒を押してひとたび設定してしまえば以降は二度と証明書の顔を見なくて済む最高の選択肢がここにある。まずはCloudflareのページから運用中のドメインを指定して、SSL/TLS → オリジンサーバへと進む。
次に「証明書を作成」をクリックして画面下の「作成」を押す。設定項目は特にいじらなくても差し支えない。証明書の有効期限はデフォルトで15年間となる。西暦2038年7月22日……。その頃には紙より薄いスマホの上にインスタンスが建っていそうだ。
暗号鍵が作成されると画面上に文字列が現れるので、速やかにコピペして指示通りの拡張子で保存する。この画面は再び開けないため、インスタンスを動かしているサーバ上だけでなく安全なローカル環境にも予備を保存しておくのが望ましい。サーバにそれぞれの鍵を保存したら、先にLet's Encryptで発行したSSL証明書を削除する。以降の操作はroot権限で行う。
$ certbot revoke --cert-path /etc/letsencrypt/live/あんたのドメイン名/cert.pem
実行確認を承諾すると証明書は直ちに失効される。cronを設定している人はcrontabを実行して自動更新も忘れずに解除しよう。続いて、nginxの設定に進む。手始めに必要なディレクトリを作成してCloudflareの暗号鍵を移動する。
$ mkdir /etc/ssl/certs
$ mkdir /etc/ssl/private
$ mv あんたのドメイン名.pem /etc/ssl/certs/あんたのドメイン名.pem
$ mv あんたのドメイン名.key /etc/ssl/private/あんたのドメイン名.key
移動したら任意のエディタでnginxの設定ファイルを編集する。
$ vim /etc/nginx/sites-available/あんたのドメイン名.conf
ssl_certificate /etc/ssl/certs/あんたのドメイン名.pem;
ssl_certificate_key /etc/ssl/private/あんたのドメイン名.key;
編集後、念のためにnginx -tでエラーを確認して問題がなければsystemctl restart nginxでnginxを再起動する。Web UIに接続して証明書の有効性が確認できたら作業は完了だ。
Mastodonのリモートメディアを確認して削除する
前提
・Docker環境でMastodonインスタンスを動かしている。
Web UIのサーバ設定でもリモートメディアを自動削除するようにできるが、具体的に何GBのキャッシュが存在していて何GBぶん減らせたのか判らないところがちょっと物足りない。下記の平易なスクリプトでそれを補える。
#!/bin/bash
cd /home/ユーザ/インスタンスのディレクトリ/
echo "Check media usage..."
docker-compose run web bundle exec bin/tootctl media usage
read -p "Enter to proceed..."
echo "Removing..."
docker-compose run web bundle exec bin/tootctl media remove -d 1
echo "Done."
この記述例ではメディアの使用量を照会した後に処理の続行を確認して、Enterキーを押すと24時間以前のリモートメディアが削除される。予期せぬ請求やストレージの圧迫を避けるためにもそれなりの頻度で実施しておきたい。
Mastodonの投稿読み込み数上限を破壊する
前提
・Docker環境でMastodonインスタンスを動かしている。
Mastodonは投稿の読み込み数に制限がある。おそらく負荷対策だろう。過去の投稿は最大で800までしか読み込めない。いちユーザの立場では変えられないゆえ不便を被っている者も少なくないと思われるが、我々は圧倒的権力を誇る鯖缶だ。いくらでも好きな数字に書き換えられる。
# mastodon/app/lib/feed_manager.rb
MAX_ITEMS = 2000
さしあたり僕は2000にした。編集後はsudo docker-compose buildで再ビルドしなければ反映されない。これで深夜帯に蓄積された投稿の一部しか読めないなどという理不尽から解き放たれる。
Mastodonの画像リサイズ制限を破壊する
前提
・Docker環境でMastodonインスタンスを動かしている。
Mastodonは画像の最大解像度が1080p相当に抑えられている。多くのユーザを限られたリソースで支える状況下ではやむをえないが、ソロインスタンスの支配者には意味のない制約だ。4K画質相当まで上げてしまおう。
// resize_image.js
const MAX_IMAGE_PIXELS = 8847360;
# media_attachment.rb
IMAGE_STYLES = {
original: {
pixels: 8_847_360,
file_geometry_parser: FastGeometryParser,
}.freeze,
こっちも再ビルドを忘れてはならない。もちろん4Kを越える解像度のカメラやディスプレイを持っている人は8Kなどにしてもよい。
Mastodonの文字数上限を破壊する
前提
・Docker環境でMastodonインスタンスを動かしている。
500文字もあれば十分と思いきや、ここ一番の時に足りない場合が意外とあったりする。実装系にもよるがだいたいどれも8000文字くらいは受け取れるらしいので不要は制限は予め取り払っておいた方が楽だ。僕は9999文字に設定した。ここでも2つのファイルを編集するが、当該のファイル内を「500」で検索すれば容易に修正箇所を見つけることができる。
# mastodon/app/javascript/mastodon/features/compose/components/compose_from.javascript
return !(isSubmitting || isUploading || isChangingUpload || length(fulltext) > 9999 || (isOnlyWhitespace && !anyMedia));
};
<CharacterCounter max={9999} text={this.getFulltextForCharacterCounting()} />
# mastodon/app/validators/status_length_validator.rb
class StatusLengthValidator < ActiveModel::Validator
MAX_CHARS = 9999
余談だが、最近華々しいリニューアルを果たしたMisskeyフォークのFirefishは一瞬だけ最大文字数を2億5000万文字に設定できたらしい。いい心意気だ。