もぐてっく

人は1つ歳をとるたび、1ビットづつ大きくなれると信じてた。

CentOS7にMastodonをインストールしたときにハマったこと

CentOS Mastodon

すごく何となくMastdonインスタンスを立てたくなったので、週末を3つほど使って悪戦苦闘してました。

インストールはこちらのサイトを元に進めました。
要点が纏まっていて助かりました。

qiita.com

しかしながら、最後の「http://<ホスト名>:3000/」で動作確認するところがどうしてもうまく行きませんでした。

[root@localhost live]# curl http://localhost:3000
<html><body>You are being <a href="https://localhost/">redirected</a>.</body></html>

「http://<ホスト名>:3000/」にアクセスすると「https://<ホスト名>/」にリダイレクトされるのですが、webコンテナはHTTP用の3000ポートしか外部にNATしていないので、リダイレクト先のHTTPSポート(433)にアクセスできないという状況です。

よくよく調べてみると、HTTPプロトコルには要求時にUpgrade:と言うヘッダを付けるとHTTP用のポートを使ってHTTPSで通信できる機能があるらしく、Mastodonはそれを採用しているようです。

動作確認に使ってたChromeやcurlは要求時にこのUpgrade:ヘッダを付けないので上手く行かなかったと言う話でした。

RFC 2817 - Upgrading to TLS Within HTTP/1.1

結論として、Webサーバのnginxはリバースプロキシとして動作するときにUpgrade:ヘッダを付けられるようなので、Mastodon公式サイトの設定例を元にnginxを立ち上げてみました。

documentation/Production-guide.md at master · tootsuite/documentation · GitHub

結果、無事サインアップの画面が表示されました。
ミッションコンプリ。

Mastodonをインストールするだけでも各種最先端技術に振り回されて満身創痍になってしまったので、運用はもうちょっと経験値が貯まってからにしようと思います。

CentOS7.4でdocker-compose runがUpdating Permissions...から進まなくなった

CentOS Docker docker-compose

下記の組み合わせで、タイトルの現象が発生しました。

  • CentOS Linux release 7.4.1708 (Core)
  • Docker version 18.02.0-ce, build fc4de44
  • docker-compose version 1.19.0, build 9e633ef
[root@localhost live]# docker-compose --rm run web rake secret
Creating network "live_internal_network" with the default driver
Creating network "live_external_network" with the default driver
Starting live_db_1 ... done
Starting live_redis_1 ... done
Creating mastodon user (UID : 991 and GID : 991)...
Updating permissions...
（コンテナ内のファイルのfindとchownに明け暮れて全く帰ってこない。）

どうもDockerのストレージドライバoverlay2が原因の様です。
別のストレージドライバに切り替えればいい模様。

aufsが一般的らしいですが、今更だなぁと思ってbtrfsにしてみました。

CentOSを再インストール。インストール先の設定で/と/homeをbtrfsにするだけでOKでした。自動でストレージドライバをbtrfsにしてくれました。

mikutter 3.6のSpellのメモ

mikutter 3.6 メモ

スペル（Spell）って？

まだよくわからぬ。
mikutter内の「動作」を柔軟に抽象化する仕組みだと思います。

仕様

スペルはdefspellと言うDSLとして定義されています。

$(MIKUTTER_DIR)/core/plugin/spell/spell.rb

defdsl :defspell do |spell_name, *constraint, condition: nil, &block|

spell_name

スペル名をシンボルで指定します。
例えば「投稿」は:composeです。

constraint

そのスペルに関わるモデルのslugを適当に並べて指定します。

みたいな。

condition

そのスペルが今発動できるか否かを返すlambdaを渡します。
procにはconstraintに指定したモデルのインスタンスが渡されます。
発動可能ならtrue、ダメならfalseを返しましょう。

block

スペルを発動した時に行う処理です。

スペルの呼び出し方

任意のPluginのインスタンスにスペル名と同名のメソッド（「compose()」の様な）があるので、それを呼びます。

引数には関係するモデルのインスタンス、オプションたち（ハッシュ）を適当な順番で渡せばいいみたいです。引数にnilがあっても大丈夫っぽいです。

$(MIKUTTER_DIR)/core/mui/gtk_postbox.rb

@posting = Plugin[:gtk].compose(
current_world,                                     # :twitterモデルのインスタンス
to_display_only? ? nil : @to.first,         # 送り先があるならそのモデルのインスタンス
body: text,                                           # オプション
visibility: @visibility                             # オプション
).next{

発動可能なスペルが存在するかを事前にチェックするには、「スペル名?」と言うメソッド（「compose?()」の様な）があるので、それを呼びます。

Plugin[:gtk].compose?(current_world, to_display_only? ? nil : @to.first, visibility: @visibility)

スペルの呼び出され方

$(MIKUTTER_DIR)/core/plugin/twitter/twitter.rb

defspell(:compose, :twitter,・・・・) do |twitter, body:, to: nil, **options|

ブロックの引数の種類に意味合いがあるので注意が必要です。
（$(MIKUTTER_DIR)/core/plugin/spell/struct.rb"でやってます。）

  • twitter：普通の引数(req)
  • body：キーワード引数(keyreq)
  • to：デフォルト値ありのキーワード引数(key)
  • options：残りのキーワード引数(keyrest)

普通の引数(req)、デフォルト値ありの普通の引数(opt)

constraintに指定したモデルのインスタンス
（多かったり少なかったりすると例外が発生します*1）

デフォルト値ありのキーワード引数(key)

スペルのオプションに同名のキーがある場合、それが代入されます。

キーワード引数(keyreq)

スペルのオプションに同名のキーがある場合、それが代入されます。同名のキーが無い場合は例外が発生します（*1）

残りのキーワード引数(keyrest)

オプションの内容が全部渡されます。

メモ

発動するスキルは次の条件で発見されます。

  • 呼び出し側が引数に指定したモデルと、スペル側のconstraintが完全に一致していること。⇒スペルのconditionが実行される。
  • conditionの結果がtrueであること。

*1:Plugin::Spell::ArgumentErrorが発生してるはずなんですがmikutterが落ちるわけでも--debugでもログが出るわけでもなく。謎です。