sshとscpの話

作業日：2019年7月27日（土）とか

favicon.icoの置き換えなどでSSH接続したりscpしたりする方法について、毎回ググってたのでメモ。

bashを使います。私のノーパソはwindowsですが、github desktopを入れた時にgit bashというのが付いてきた（ような記憶）ので、それでやります。

$ cd /d/Users/USERNAME/みちく茶話会/mastodon #作業フォルダの場所へ
$ scp -i キーペア.pem public/favicon.ico ubuntu@IPア.ド.レ.ス:~/mastodon/public/
favicon.ico                                   100%   17KB  47.5KB/s   00:00
$ ssh -i キーペア.pem ubuntu@IPア.ド.レ.ス
ubuntu@ip-ア-ド-レ-ス:~$ sudo service nginx reload

アップデートとgitの話

作業日：2019年7月27日（土）ごろ

アップデートはおよそいつもの参考ページの通りなのですが、実はgit stash pop？のあたりで「CONFLICTしてますよ！」というWARNINGが出てました（実は前回のときも出てましたが無理やり押し進めてました）。ほにゃらら/elephant-fren.pngとdocker-compose.ymlがアレらしい。

docker-compose.ymlはDBの永続化とかで初回セットアップ時に修正したファイルですので、自分が修正したほうを採用するふうに変更します。テキストファイルなので、vim docker-compose.ymlで差分箇所（<<<<<<<<<<<<とか============とか>>>>>>>>>>>>みたいな記号で指示されてる）をいい感じにすればいい感じになります。前回アップデート時も結果的にそんな感じのvim作業をしてました。いちおうmastodon/docker-compose.yml at master · tootsuite/mastodonと見比べて確認。もしかしてこれ次回以降退避しなくていいやつか？（「セットアップ時にコメントアウトを外してね！」だったのが、すでにコメントアウトが外された状態になってる）

elephant-fren.pngは、以前サイトデザインを変えようと格闘した時に触ったファイルです。前回アップデート時にはCONFLICTを放置したのですが、そしたらこちらで変更したファイルがそのままになっていたようです。次回以降もWARNINGされても面倒なので、master側のやつで上書きしたい。

ということで検索して見付けたのがこの記事：
マージでバイナリファイルがコンフリクトした場合のGitの動作と対処方法 - アインシュタインの電話番号

~/mastodon$ git checkout --theirs app/javascript/images/elephant-fren.png

こんなコマンドを打てばいいらしいです。打ちました。これでOKかどうかは次回アップデートをお楽しみに……。

というわけでアップデート作業を行ったのですが、sudo docker-compose buildの途中で出力がこんなことに。

:
yarn install v1.17.3
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
info There appears to be trouble with your network connection. Retrying...
:
info There appears to be trouble with your network connection. Retrying...
error An unexpected error occurred: "https://registry.yarnpkg.com/rxjs/-/rxjs-6.3.3.tgz: ESOCKETTIMEDOUT".
info If you think this is a bug, please open a bug report with the information provided in "/opt/mastodon/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
ERROR: Service 'web' failed to build: The command 'bash -c cd /opt/mastodon && bundle install -j$(nproc) --deployment --without development test &&     yarn install --pure-lockfile' returned a non-zero code: 1

ネットワークエラーでタイムアウトでコマンドが非零を返した？そうです。これはsudo docker-compose buildをやり直すしかないのかな？ということでコマンド打って2周目トライ。前回途中までで再利用できる部分は再利用されるんでしょうか？

~/mastodon$ sudo docker-compose build
db uses an image, skipping
redis uses an image, skipping
Building streaming
:

しかしまた同じ場所でエラーになってしまいます。何度もリトライするうちに、どんどん重く……。気付いた時にdf -hしてみたら/dev/nvme0n1p1が100%になっていました。わあ！どおりで……。

sudo docker system pruneで空けると65%（20G中13G）くらいまで減りまして、これでsudo docker-compose buildができましたが、このコマンドが終わった時点で使用容量は86%（20G中17G）になっていました。ちなみにコマンド実行中に何度かdf -hして、観測最大値は88%でした。

sudo docker system pruneするとめっちゃ時間がかかった末に2.395GBほど削減されたとのこと。ついでにgit gc --autoもして（.git/objectは87MBくらいあるらしい？）、64%（20G中13G）まで減りました。

さて、これでmigrateしてprecompileしてupすれば起動出来る訳ですが、これがどうにも重い……。アップデートのたびに要求マシンスペックが増えてるのでは……？

仕方ないので、いったんsudo docker-compose downしてから、AWSでインスタンスタイプをt3a.smallにアップグレードしました。puttyの接続設定を直してログインしてsudo docker-compose up -d。

よっしゃ！さくさく動く！ということで、アップデート・アップグレード作業が完了しました。

.gitのメンテナンスに関しては、次のようなページを眺めました。
Gitの驚愕の真実：1億行のファイルに1行追記するとレポジトリ容量が200MB増える[※補足あり]・DQNEO起業日記
Gitリポジトリをメンテナンスして軽量化する - Qiita

~/mastodon$ git gc --auto

でも怖いのでガーベージコレクション命令しか打ってません。

アップデートのためのコマンドをいつもの参考ページのTL;DRに倣って並べるとこんな感じ。

~$ cd mastodon
~/mastodon$ git fetch
~/mastodon$ git stash
~/mastodon$ git tag
~/mastodon$ git checkout v2.9.2 #素人はrcとか選ばない方がいいと思う（過去の自分へ向けて）
~/mastodon$ git stash pop
~/mastodon$ vim CONFLICTED/TEXT.file #解消作業
~/mastodon$ git checkout --theirs CONFLICTED/BINARY/FILE #解消作業
~/mastodon$ sudo docker-compose down #先にいったん落とす
~/mastodon$ sudo docker system prune #容量を開ける
~/mastodon$ sudo docker-compose pull
~/mastodon$ sudo docker-compose build #めっちゃ時間かかる
~/mastodon$ sudo docker-compose run --rm web ./bin/rails db:migrate #参考ページと変わってます
~/mastodon$ sudo docker-compose run --rm web ./bin/rails assets:precompile #参考ページと変わってます
~/mastodon$ sudo docker-compose up -d

今回の作業で、バージョンはv2.8.0からv2.9.2になりました。

……あ！変更したfaviconが元に戻ってる！のは再度scpして更新のうえsudo service nginx reload。たぶんこれは今後git stashが必要なやつですね。

メモリが足りなくなった話

障害発生日：2019年7月14日（土）

18時37分ごろ、アクセスできないという報告がありました。

dockerが止まらない！

引越やらなんやらかんやらで心当たりがたくさんあったのですが、色々見た結果dockerに問題が起きている様子でした。ひとまず止めようとしたのですが、

~/mastodon$ sudo docker-compose stop
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).

とかいうエラー。dockerごと再起動してから、暴走タイムアウトになる前に止める、という手段を取ります。

~/mastodon$ sudo service docker restart
~/mastodon$ sudo docker-compose down #stopではない (コンテナの削除までやる)

で止まりました。

マシンスペックが不足していそう

鯖缶工場の方に教えていただき、サーバーの負荷などを調べます。

~$ uptime #起動時間とload average(サーバーの重さ)
 12:13:02 up 1 day, 15:35,  2 users,  load average: 5.20, 5.33, 5.42
~$ free #メモリ使用量
              total        used        free      shared  buff/cache   available
Mem:         498372      203188      102892       16312      192292      235460
Swap:       4194300      401940     3792360
~$ ps aux --sort -%cpu | head -10 #CPU使用率の高い順に10行
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
~/mastodon$ sudo docker-compose logs --tail=30 #mastodonのログ最終30行

鯖缶工場の方の見立てではdbのエラーとかでsidekiqが大変になってるのでは？ということだったので、sidekiq以外が問題ないか確認します。最低限のバックエンド：db,redisとフロント：webだけ立ち上げて、閲覧ができるか確かめます。

~/mastodon$ sudo docker-compose up -d db
Starting mastodon_db_1 ... done
~/mastodon$ sudo docker-compose up -d redis
Creating mastodon_redis_1 ... done
~/mastodon$ sudo docker-compose up -d web
Creating mastodon_web_1 ... done

この3アプリでは問題がない様子だった（webが閲覧できる）ので、「sidekiq（投稿からのDB処理や別鯖への配信）の重い処理にサーバーが耐えられていない」という判断になりました。

というわけで、AWSでインスタンスのグレードを上げることにしました。

グレードアップ

鯖缶さんの経験からすると「1vCPU,4GBメモリ」以上が推奨かなあという話でしたが、現在のt2.nano（1vCPU,0.5GBメモリ）では厳しくも、引越前のt2.micro（1vCPU,1GBメモリ）では動いていたことと、t2の次世代？のt3がリリースされていることから、t3.micro（2vCPU,1GBメモリ）で試してみることにしました。無理そうならまたあとでスペックを上げることにします。

アクション→インスタンスの状態→停止をするとインスタンスの設定→インスタンスタイプの変更ができます。インスタンスタイプが変わるとIPv4パブリックIPが変わるので、Puttyを設定し直してからSSHアクセスし、dockerを起動。

~/mastodon$ sudo docker-compose up -d
mastodon_redis_1 is up-to-date
mastodon_db_1 is up-to-date
mastodon_web_1 is up-to-date
Creating mastodon_streaming_1 ... done
Creating mastodon_sidekiq_1   ... done

これでweb投稿もできるようになり、23時32分ごろ、一安心となりました。スペックは惜しまず人が増えたら上げていく、というのが教訓です。

リージョンを引越した話

作業日：2019年7月13日（金）

実はインスタンスを「米国西部（オレゴン）」リージョンで作成してしまっていて、特に目に見える問題があるわけではありませんが、「地理的に遠いのもなあ」ということで、「アジアパシフィック（東京）」に引っ越すことにしました。

基本的にはこのサイトを参考にしました：
AWS EC2のインスタンスのリージョンを東京に移動する方法｜まろろぐ

ただし、この引越にあたっては、インスタンスだけでなく、SSL証明書も取り直す必要がありました。Amazon Certificate ManagerのSSL証明書はリージョンごとの設定になっているためです。ロードバランサーも作り変える必要があるので、設営時からたびたび参照しているマストドンAWS構築チュートリアル完全版|初心者から大規模運用までも確認しながら作業を進めました。手順は以下の通りです。

1. オレゴンにあるEC2のスナップショットを作成、東京へコピー
2. 待っている間に東京リージョンのACMでsawakai.spaceのSSL証明書を取得
3. 東京のスナップショットからAMI（Amazon Macine Image）を作成
4. AMIからインスタンスを作成
5. ELB（ロードバランサー）を東京リージョンで新規に作成
6. Route53で、sawakai.spaceの割り当てを新規ELBに変更

スナップショットにするのではなくマシンイメージにした状態で引っ越したほうがいいという説も見かけましたが、よく分かりませんでした。ともあれ無事に引っ越せたようです。

無事ではありませんでした（インスタンス作成時にスペックを落としたt2.nanoを選んでしまったため）。

画像置き場を移行した話

作業日：2019年6月16日（日）

メディアのやりとりでサーバーがあっという間に一杯になってしまうことを知ったので、メディアの保存先をAmazon S3に移行しました。基本的な手順は下記ページに従いました。
[1] Mastodon インスタンスの画像や動画の保存先をクラウドストレージ （Amazon S3） に移行した話 | WWW WATCH

ところどころ（データの移動など）では下記ページも参考にしています。
[2] Mastodon の画像などメディアデータをAmazon S3に移行する（非Docker環境） - Takanory Blog

つまづいたのは以下。

1. バケットの名前はドット（.）を含まない名前にしなくてはいけない（MastodonをDockerで構築(S3連携) | Kou's Web）らしいです。
2. アクセス権限について、バケット作成時の初期設定では「パブリックアクセスをすべてブロック」がオンになっていますが、このままだと500エラーになるようです。パブリックアクセスのブロックはすべてオフにしました。
3. .env.productionの設定に関しては[2]のほうが分かりやすかったのでこちらを参考に。
4. データ移行についても、[2]で紹介している方法で行いました。次節にて。
5. dockerのビルドで容量不足エラー。次々節。

データの移行

S3導入前のデータを移行する方法について、[1]では「コピーしてローカルに落として～」、[2]では「AWS CLIを使って～」と説明しています。合わせ技でやったので記録しておきます。

~$ cd mastodon/public/system # データはこのへんにあります。
~/mastodon/public/system$ sudo du -hs # ひとまず容量を調べると、
1.1G # めっちゃある

実際には「dockerからアクセスできる場所」にあるので、これを(1)普通にアクセスできる場所へコピー(2)AWSに同期、という方法をとります。

~$ mkdir mstdnbk # 一時保管庫
~$ cd mastodon
~/mastodon$ sudo docker cp mastodon_web_1:/mastodon/public/system ~/mstdnbk/web # コピー
~/mastodon$ cd mstdnbk
~/mstdnbk$ ls
web # コピーできました
~/mstdnbk$ sudo pip install awscli # AWS CLIをインストール
~/mstdnbk$ aws configure # 初期設定
AWS Access Key ID [None]: [myAccessKeyID]
AWS Secret Access Key [None]: [mySecretAccessKey]
Default region name [None]: ap-northeast-1
Default output format [None]: json
~/mstdnbk$ aws s3 sync web/ s3://[myBucketName] # 同期
~/mstdnbk$ sudo rm -r web # 一時コピーを削除

S3への転送（同期）にはそこそこ時間が掛かりましたが、AWSのコンソールを更新しながら、少しずつデータがアップロードされていくのを眺めていました。

ビルド

最後にビルドして終わりです。[1]の記事のコマンドをsudoで実行すればOKのはず。

~/mastodon$ sudo docker-compose stop
~/mastodon$ sudo docker-compose build # めっちゃ時間かかる
~/mastodon$ sudo docker-compose run --rm ./bin/rails db:migrate
~/mastodon$ sudo docker-compose run --rm ./bin/rails assets:precompile
~/mastodon$ sudo docker-compose up -d
~/mastodon$ nginx

ただでさえ時間のかかるsudo docker-compose buildですが、容量が不足すると途中でエラーになるので、事前に十分な容量を確保しましょう（やり直す羽目になりました）。

サーバーが一杯になった話

作業日：2019年5月16日（木）ごろ

サーバー容量がいっぱいになると「なんかタイムラインが取得できないな～？」となった（2019年5月16日ごろ）り、「500エラーでアクセスできないない～？」となった（2019年6月13日ごろ）りします。アップデートのためのsudo docker-compose buildもNo space left on deviceで失敗してしまいました。

容量を調べる

Linuxのファイル用容量を調べるコマンドメモ - Qiita
を参考に、どこが逼迫しているのか調べます。アクセス権限が必要なフォルダもあるのでsudoを付けます。

~$ sudo df -h # 全体の容量確認
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       20G   20G     0 100% / # みたいなことになってたので
~$ cd /
/$ sudo du | sort -nr | head -5 # 容量がでかいフォルダを探すと
/docker/aufs # というのを発見

容量を空ける

dockerがいっぱいいっぱいになっているっぽいので、
dockerのディスク容量削減 | ユニコーンリサーチ
の通りに

~/mastodon$ sudo docker system prune

を実行したところ、100%使用中だったのが89%くらいまで削減できました。

加えて、cronの設定ミスにより、マストドンが他鯖から保存した画像の削除などが一年間全く実行できていなかったことが判明。usernameが未記入になっていたほか、バージョンの違い等々あり、本来のコマンドは以下の通りだったようです。

~/mastodon$ sudo docker-compose run --rm web ./bin/rake mastodon:media:remove_remote

※上記のコマンドはmastodon ver2.6までで、現在（ver2.5以降）は次のコマンドです。

~/mastodon$ sudo docker-compose run --rm web tootctl media remove

アップデート

無事用量が確保できたので、下記バージョンアップの話と同様に、新たに見付けた記事（忘れたころに mastodon update 手順メモ – 男メイド ブログ）も参考にしながら、バージョンアップを行いました。今回の作業では、バージョンがv2.4.1からv2.8.0にアップデートされました。

容量問題については一時的な対処でしかないので、あとでメディアストレージをAWS S3に移行しようと思います。しました。

投稿がどこまで見えるかの話

実験日：2019年2月26日（火）ごろ

ただでさえややこしいマストドンの公開範囲ですが、以下の2点が話題になったので確認しました。

1. 「フォロワー限定」で投稿した画像がメディア欄に表示されない？
2. DMとかって管理者からはどこまで見れるの？

「フォロワー限定」の画像は、プロフィールページのメディア欄には表示されない

プロフィールページ（https://sawakai.space/@ユーザー名）はパブリックなページなので、そのメディア欄（https://sawakai.space/@ユーザー名/media）には、「フォロワー限定」「ダイレクト」で投稿した画像は表示されません。「公開」「未収載」の投稿は表示されます。一方でアプリ内（https://sawakai.space/web/accounts/ユーザーID/media）では見ることが出来ます。こんな感じ。

「ダイレクト」や「フォロワー限定」の投稿は管理画面からは見れない

管理者の管理画面からはモデレーション→アカウント→（特定のユーザー）→トゥート一覧を見ることができるのですが、ここに表示されるのは「公開」「未収載」の投稿だけで、「フォロワー限定」「ダイレクト」の投稿は見ることができません。管理者がフォロワーであったり管理者宛てのDMだとしてもです（1,2）。ただし、「通常の」管理画面から見れないだけで、データベースを直接叩けばたぶん見ることができるはずだと思います。そこまでの技術力は今はありませんが。

同様に、管理画面で登録メールアドレスは見れてもパスワードは見れません。なおパスワードに関してはデータベースでも暗号化されて保持されているらしいです。

SSL認証局を切り替えた話

作業日：2019年2月12日（火）ごろ

90日ごとに手動でSSL証明書の更新するのは面倒くさい（のちにcronの設定ミスと判明）なあ……と思い、SSL証明書をAmazon Cirtificate Managerのものに切り替えることにしました。

基本的にはマストドンAWS構築チュートリアル完全版|初心者から大規模運用まで の「ロードバランサーの導入」の通りです。AmazonによるSSL証明書はうっかり最初の設営時に済ませていたので、・ELBの作成 ・ドメインの割り当てをELBに変更 ・Nginxの設定変更 ・EC2の不要ポート閉鎖 ・cronの削除、を行いました。

設定変更の反映にまた少し時間がかかってドギマギしましたが、無事変更が完了しました。

スパム対策と追悼の話

対応日：2018年8月3日（金）ごろ

スパム

7月30日頃からスパムっぽいアカウントの新規登録が来るようになり、放っておいたら別鯖のスパムを連合タイムラインに呼び込んで異様な光景となっていたため、対策を行いました。

1. 7月30日： Mastodonのスパムアカウント対策 - ゆめをみること．等の情報を見付けたので、モデレーションの「メールブラックリスト」に「mxsrv.mailasrvs.pw」を登録しました
2. 8月3日： 登録されてたボットたちの活動停止処置を行いました
• ただし1匹だけサイレンスおよび追悼アカウント化の処置としました
• 上記はのちに停止させ、現在サイレンス・追悼として保存してあるのはこっち
3. 数日間： 連合タイムラインに現れていた別鯖の怪しげなアカウントをひたすらブロックしました

連合TLスパムブロックの結果、なんとか平和を取り戻すことが出来ました。

「追悼アカウント」化

スパムボット対策の過程で「追悼アカウント」という概念を知りました。

そこへ「追悼アカウントになってみたい」という方が現れたので、実験的に嘱託殺人を行いました（2019年1月8日）。その結果わかったこととしては、

• プロフィールページに「故人を偲んで。」が表示されるようになる
• ログインが無効化される
• 当該ユーザーのログインセッションや自分のプロフィールページは403エラーになるらしい
• サードパーティークライアントでログイン済みの状態であれば、引き続き閲覧だけはできるらしい

という感じです。403ということは、死とは魂が肉体へのアクセス権限を失った状態と言えるのかもしれません。

バージョンアップの話

作業日：2018年6月16日（土）ごろ

基本的には以下のページの手順に従いました。
Docker を利用したマストドンのアップデートメモ

ところが、sudo docker-compose run --rm web rails db:migrateおよびsudo docker-compose run --rm web rails assets:precompileの際にエラーが発生。検索したところ下記のブログの症例がそれっぽい。
Mastodon 2.4.0に上げるときに困ったこと - ゆめをみること．

この記事に従い、コマンド中のrailsを./bin/railsに変更したところ、成功しました。具体的には下記みたいな感じです。

~/mastodon$ sudo docker-compose run --rm web ./bin/rails db:migrate
~/mastodon$ sudo docker-compose run --rm web ./bin/rails assets:precompile

今回の作業により、バージョンが v2.2.0rc2 から v2.4.1 にアップデートされました。

構築の話

作業日：2018年2月24日（土）ごろ

要約：AWSのEC2でubuntuにdockerで立てました。

参考リンクとしてCentOSでの立て方

チュートリアルに従って立ち上げる

基本的には下記ページの「お手軽な手順」に従いました。
[1] マストドンAWS構築チュートリアル完全版|初心者から大規模運用まで

所々で下記の記事も参考にしました。
[2] AWSでMastodonインスタンスを作るまで。自分まとめ - Qiita
特に、インスタンスにSSH接続するためのPuTTYの使い方は、こちらの記事に書かれています。

実際に実行した手順で、[1]の記事と違いがあった部分は以下。

1. Let’s EncryptによるSSL証明書の取得に何度も失敗しました。ドメインをサーバーのIPアドレスと結び付けた際に、その情報がDNSにしっかり反映されるまでに時間がかかったのではないかと思います。この手順を後回しにして進め、Nginxの再起動前くらいにやり直してなんとかなりました。
2. 最初は[1]と[2]を何度も往復して見ながら作業していたため、AWS Cretificate ManagerでもSSL証明書を取得してしまいました。現状では正常に動いているように見えますが、どこかでLet’s Encryptと喧嘩してそうで怖い……詳しい人に見解を求めたい。
3. Nginxの設定ファイルは、この記事のものではなく公式ドキュメントのサンプルを元にしました。マストドン自体のアップデートにより変わっているかもしれないからです。example.comをsawakai.spaceに書き換え、root /home/mastodon/live/public;をroot /home/{username}/mastodon/public;としました。
4. マストドンソースコードの保存先はliveではなくmastodonにしました。コマンドとしては[2]の記事と同じ

   ~$ git clone https://github.com/tootsuite/mastodon
   ~$ cd mastodon
   

   になります。
5. sudo docker-compose run --rm web rails assets:precompileした際に「500.htmlが見つかりません」のような（正確な出力は失念）エラーが出ました。mastodon/public/下の500.htmlおよびsw.jsが"リンク先が存在しないシンボリックリンク"となっているのが原因だったようなので、リンク先（mastodon/public/assets/以下）に空のファイルを作成

   ~/mastodon$ cd public
   ~/mastodon/public$ mkdir assets
   ~/mastodon/public$ cd assets
   ~/mastodon/public/assets$ touch 500.html
   ~/mastodon/public/assets$ touch sw.js
   

   することで対応しました。ちなみにprecompileが終わってから覗いてみたらちゃんと中身ができてました。
6. 記事ではsudo docker-compose up -dしたらまるですぐにマストドンに入れるかのように書かれていますが、実際には起動するまでそれなりの時間がかかるようです。それを知らなかったのおかげで「まだ『何かが間違っています』だ……一体全体どこで間違えたんだ……！？」と何度も慌てふためくことになりました（いったんEC2インスタンスを削除して手順をはじめからやり直したのは内緒です）。
7. メールも、実際に送信ができるようになるまでには結構な時間がかかりました。原因がどこにあったのかは不明ですが、AWS内の送信テストでは遅れたので、マストドン本体側のどっかな気がします（わからない）。設定ファイルを書き換えるなど色々試しましたが、最終的にはチュートリアル通りの設定で届くようになりました。ついでに届いてなかった時に送信コマンドしたメールも、あとからあとから届いて着信音にビビってました。
8. 手順をはじめからやり直す前のとき、「何かが間違っています」（500番台エラー）の原因を探るべく色々やりま（「ご利用のpipは8.1.1ですが9.0.1が使えます」と言われてたのでアップデートにチャレンジしたり、docker-composeで「Unknown flag: chown」と言われたのでdocker CEの最新版をインストールしてみたり）したが、どれも再挑戦時には不要だったので原因ではなかったようです。

管理者としてログインしたい

アカウント作成時の確認メールがなかなか送れなかったので「管理者すらアカウントが作れねえ！」と嘆きかけましたが、下記ページの「STEP.6 アカウント登録」にコマンドから手動で承認する方法がありました。
[3] DockerでMastodonをローカルで動かしてみた！ ので、その方法をご紹介。｜AKITA SOLUTION MAGAZINE

おおむねこの通りに（docker-compose ほにゃららの前にsudoを付けるだけ）やって、管理者アカウントが作成できました。

画像がアップロードできない！

マストドンが立ち上がり、アカウントが作成でき、テキストのトゥートもできました！が、画像を投稿しようとすると500エラーが出てしまいました。プロフィール画像のアップロードでもエラーです。困りました。

ひとまずググったところ、2つの記事がヒット。
[4] Mastodonをアップデートしたらトラブル発生！　─インスタンス構築奮戦記：番外編3─ - 招き猫遊戯団日誌
[5] Mastodonインスタンスをv2.0.0にアップデートしたら画像をアップロードできなくなったお話: 羊羹音楽工房 -Yokan Music Factory-

私のところでの原因は[4]に近かったようで、mastodon/public/systemのパーミッションをchmodで変更したら直りました。

そこに至るまでに色々ありましたが、役に立ったのはdocker-composeのログでした。

~/mastodon$ sudo docker-compose logs -f

これを走らせながらブラウザで画像アップロードを試し、ログの中に現れたErrorを追いました。

実際には不正解でしたが、[5]の可能性を疑って作業した際の手順も、備忘のためにメモしておきます。[5]からリンクされている記事を参考に、/var/lib/nginxの所有者（関係ないですがXは数字を伏せています）と、/etc/nginx/nginx.confのuser（USERNAMEも伏せています）を確認。

~$ cd /var/lib
/var/lib$ ll
:
drwxr-xr-x X root root XXXX Feb 24 XX:XX nginx/
:
/var/lib$ vim /etc/nginx/nginx.conf

user USERNAME;

違っている！ので所有者を変更し、nginxをリロード。

/var/lib$ chown USERNAME:USERNAME nginx #グループも一緒に変更する
/var/lib$ chgrp USERNAME nginx #グループのみ変更する
/var/lib$ sudo service nginx reload

（llおよびchown,chgrpの覚え書きでした）。所有グループも変更してみたりもしましたが、ここが原因ではなかったようなので、問題対処後、元の値に戻しました。

コマンド覚え書き

cron

~$ cd /var/log # ログはこのへんにある
/var/log$ ls
cron.log

参考：cronのログを出すように設定する - もみあげあしめ

nginx

~$ cd /var/log/nginx # ログはこのへんにある
/var/log/nginx$ ls
access.log  error.log
~$ sudo service nginx reload # 設定反映するならこれだけ
~$ sudo systemctl stop nginx # 停止
~$ sudo systemctl start nginx # 起動

docker-compose

~/mastodon$ sudo docker-compose logs -f # ログを見る
~/mastodon$ sudo docker-compose ps # 動作状態の確認（StateがUpなら起動中）
~/mastodon$ sudo docker-compose up -d # バックグラウンドで起動
~/mastodon$ sudo docker-compose start # 起動
~/mastodon$ sudo docker-compose restart # 再起動（違いが分からん）
~/mastodon$ sudo docker-compose down # ダウン
~/mastodon$ sudo docker-compose stop # 停止（違いが分からん）
~/mastodon$ sudo docker-compose build # ビルド
~/mastodon$ sudo docker-compose run --rm web rails assets:clean # 古いデータを消去
~/mastodon$ sudo docker-compose run --rm web rails assets:precompile # プリコンパイル

参考：Dockerで雑にMastodonを起動する方法 - Qiita

ブラウザから見える範囲のページ構成ざっくり

public以下

• about　入口
• about/more　詳細・ルール
• terms　利用規約
• web/以下　メイン画面
• settings/以下　各設定項目
• auth/sign_in　ログインする
• auth/sign_up　登録する
• auth/edit　セキュリティ設定
• admin/以下　管理者用各設定項目

リソース置き場

• system/以下深くに画像
• emoji/*.svg
• sounds/boop.mp3,.ogg
• assets/500.html,sw.js

参考になったりならなかったりしそうなリンク集

• おひとりさまインスタンスにおけるMastodonの環境整備 - Komittee Express
• Mastodon 関連情報まとめ - Qiita
• マストドン運営Tips - Qiita
• みんなで作るマストドンサーバー管理チェックリスト - Qiita
• Mastodonのカスタム方法 | みんなのメモ帳

CSSや画像のカスタム方法ですがver1時代っぽい（2018年5月4日（金）ごろ試してみましたが全くダメ）