トピック立てるほどではないハマったところ


#1

インスタンス運営の知見を得たい!
特に立てるほどでもないけどハマったところや、その解決法を共有しませんか。


#2

RAILS_ENV=productionを付け忘れてbundle ex rails assets:precompileした結果、デバッグ情報入りのjsがユーザに配信され、ユーザのブラウザが無限に重くなる(一度アイマストドンでやらかした


#3

画像がアップロードできないと思ったら、ディスク容量を8GBしか確保していなかったWebAppサーバのpumaがディスクフルを吐いており、その原因がbundle installでアップデートし続けたまま消していなかった過去バージョンのruby gemsだったお話
(添付画像回りを扱うPaperClipが/tmpに一時ファイルを書こうとして書けず死んでいた)

bundle cleanしたら1.5GBほど空いた


#4

v2.0.0アップデートに伴いRuby 2.4.2にしようとしてrbenv install 2.4.2をするも、何度やってもビルドに失敗する。
dfで見る限りディスクには空き容量が存在する…と思ったらiノード枯渇だったお話。
(直前に行ったapt upgradeの影響で膨大な量のカーネルのソースコード等が溜まっており、それらのせいだった)

apt autoremoveを実行したことでiノードの使用量が50%減った


#5

いつだったかのアップデートの際に、
nginxのlocationディレクティブに変更があった事に気付かず、
アプデ作業は通ってサービスも起動出来る、しかしスマホアプリ経由ならアクセス出来るのにブラウザから見れない、という状態になって、数日頭を捻る羽目に。
以後、アップデートする時は、Production Guideの変更もチェックするようになりました。


#6

.env.productionをロストして、SidekiqでWebpush::ResponseErrorがどんどん増えたときWebpushをすべて消すSQL
delete from web_push_subscriptions;
一応解決はしたけど、これでよかったのかはわからない


#7

SWIFT_ENABLED=true で Swift ObjectStorage を使っていたが、 SWIFT_OBJECT_URL=https://mastodon.cardina1.red/media のようにメディアの URL を /media にマップしてしまったため、画像添付でトゥート本文に出てくる短縮 URL (これも /media 以下にマップされる)へのリクエストが mastodon により展開されずそのまま全て swift の鯖に飛び、 404 になってしまった(添付画像自体は正しい URL に存在するので閲覧できる)

今から reverse proxy でどうにか調整して直します(できるかな……)
追記: 以下のようにして、サブディレクトリ以下にないものを mastodon へ流すという方法で正常に動作させることができました。

    location ~ ^/media/[^/]*$ {
        add_header Cache-Control "public, max-age=31536000, immutable";
        try_files $uri @proxy;
    }

#8

Mastodonインスタンスを立て初めの頃、メインインスタンスにWAFを通してました。(Sophos UTM9 Home Licenseを使ってました)すると、タイムラインの更新が出来ないという事象が発生しました。

理由はごくごく単純で、UTM9に搭載されているWAFがStreamで使ってるWebsocketに対応していないことだったのですが、UTM9のWAFって実はApacheのmod_security使ってるんですよね。そして、proxy_wstunnel_moduleをじつは持っていたりするんですよね、コイツ。

よって、無理やりCLIでコンフィグ書き換えてWebsocketを通すようにしました。

この時大いにハマったので、ブログに記録を残してます。
https://www.bluecore.net/?p=4235

Mastodonを、3大インスタンス以外のエンタープライズ分野で立てるケースが有るかどうかわからないですが、WAFを通すことを考えた時、それがWebsocketを通せるかどうか、その難易度は如何程かは見定めたほうが良いように思います。


#9

今日来た
ReFix font-weight of element for CJK fonts (#5920)


の影響で、カスタムテーマ用のファイルに
$cjk-langs: ja, ko, zh-CN, zh-HK, zh-TW;
の一行を足さないとアセットのプリコンパイルで止められました・・・。


#10

最近知ったんですが /api/v1/streaming 下は全てがWebSocketで通信するわけではなくて、一部Httpロングポーリング(Server Sent Event)で通信するところもあるようです。
なので記述されてる方法でやってもクライアントによってはだめな場合があるかも?(ちょっとよく調べてないですが)


#11

最近知ったんですが /api/v1/streaming 下は全てがWebSocketで通信するわけではなくて、一部Httpロングポーリング(Server Sent Event)で通信するところもあるようです。

なるほど・・・となると、WebsocketとHttp通信を明確に定義する必要のあるApache自体、Webフロントエンドやリバースプロキシでは使えないということになってしまいますね・・・とは言え、Server Sent Eventで通信するところが明確にわかっていれば、サイトパスポリシーを追加するだけで良いのかなとも思います。

  1. /api/v1/streaming の特定パス配下はhttpプロトコルで4000番ポート★コヤツを追加
  2. /api/v1/streaming配下はwebsocketプロトコルで4000番ポート
  3. / 配下はhttpプロトコルで3000番ポート(ホントはよくないんだけど)

と言う感じにしたら何となくうまく行けそうな気がします。とは言え、ステージング環境で動いてる代物なので、あまり積極的にいじる気はないんですけども(^^;


#12

アクセスログを調べたところ、iOS版PawooやOre2は/api/v1/streaming以下を読んだ結果が200になっているのでServer Side Eventのようです


#13

v2.1.0アプデでこけたところ
asset:precompileがコケる
原因
過去に https://github.com/tootsuite/documentation/blob/d892b9ff8f038d9e7d664c914a169d516fecbc75/Running-Mastodon/Customizing.md
を利用してカスタマイズしていたためcustom.jsというファイルを作成していた。
これを削除するとprecompileが通るようになった。
v2.0.0まではcustom.jsがあったままでも問題なかったが何かが変わったらしい。


#14

本家の #6038 にも挙がっていた問題ですが、おかげで謎が解けました…。

custom.jsがあるとcustom.cssを生成しようとするんですが、custom.cssとdefault.cssで重複する内容をcommon.cssに抽出した結果、中身が空になったdefault.cssは生成されず、defaultテーマが見つからないというエラーになります。

custom.jsが不要になったv1.4.2以来ずっと、この問題を回避するためにcustom.jsを除外してきたのですが、とある修正と一緒にそれがなくなってしまったようです。


#15

リリースノートかなにかに書いて欲しかったですね(>︿<。)

気づいてなかったのかな…?


#16

ハマったところ、というか現在進行系でハマっているのですが、
v2.4.0rc1以降(現在はv2.4.0)、ブラウザで開きっぱなしにしていると、
突然sw.jsが「Uncaught (in promise) DOMException: Quota exceeded.」を出して、
それ以降画像が「Failed to load resource: net::ERR_FAILED」となり表示出来なくなる現象が何度も起きて困っています。

ブラウザのキャッシュ削除をしても解消せず、
v2.4.0の注意書きにあった、

If avatars and images in web UI are suddenly not loading, check if the server serves them with a CORS header, e.g. Access-Control-Allow-Origin: https://example.com/ where example.com is your domain. This is needed for the offline functionality of the webapp to work.

を読んで、nginxの設定に

add_header Access-Control-Allow-Origin “(ドメイン)”;
add_header Access-Control-Allow-Methods “POST, GET, OPTIONS”;
add_header Access-Control-Allow-Headers “Origin, Authorization, Accept”;
add_header Access-Control-Allow-Credentials true;

を足して、反映されているのは確認したのですが、それでも現象は変わらず、という状態です。
どなたかお力添えいただけないでしょうか・・・。


#17

v2.4.0ではIndexedDBやCacheAPIを使って投稿情報や画像をキャッシュするようになっていて、ご指摘のエラーはそれが上限サイズに逹したことによるものだと思います。キャッシュ削除でも消えるはずではありますが、削除範囲の指定にもよるかもしれません。

上限値や現在のサイズを取得するなどして、エラー時や、そもそも上限に逹しないよう事前に、適宜キャッシュを削除する実装はあったはずですが、漏れがあるのかもしれません。OSやブラウザなどの詳細を教えてもらえないでしょうか?


#18

元は、iOS + Safari(詳細不明)のユーザーの問い合わせから調べ始めたのですが、
Windows 10 pro 64bit
Google Chrome バージョン: 66.0.3359.181(Official Build) (64 ビット)
のシークレットモードで同じ現象が再現し、その状態で試行錯誤した後ここでご相談をさせて頂きました。

が、ご返答頂いた後ふと気になって、同じ環境でシークレットモードを使用しない状態で試した所、再現しておりません。
間抜けな話なのですが、「シークレットモードを使うのが悪い」という事なんでしょうかね・・・?