停電でネットワークだけ切れた後にトンネルを繋ぎ直そうとしたらリモート側だけでsshの接続が生きているように見えて繋ぎ直せない現象を確認しました。
停電でネットワークだけ切れた後にトンネルを繋ぎ直そうとしたらリモート側だけでsshの接続が生きているように見えて繋ぎ直せない現象を確認しました。
ただ Ubuntu は親切設計指向なぶん依存や設定が基本的に盛り盛りで，「私はこの機能要らないから外したいんだけどなあ」とか思っても入ってくることはある（Gentoo だとそれを回避できる）
Ubuntuに外部レポジトリが追加される時にはパッケージに署名する鍵を信用するような気がする。snapはどうじゃろ。
StatusesController#showでJSONを生成する部分は2行しかなくて各行にかかった時間を記録するようにしたんだけどまだ遅いリクエストをもらってないねえ
https://github.com/zunda/mastodon/commit/864ef58e52b343e028b0852fd91312dfd5898ade
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
#7119 救急相談センター
> 急な病気やケガをした場合に、「救急車を呼んだほうがいいのかな？」、「今すぐ病院に行ったほうがいいのかな？」など迷った際の相談窓口として、「東京消防庁救急相談センター」を開設しています。
https://www.tfd.metro.tokyo.lg.jp/lfe/kyuu-adv/soudan-center.htm
とかかな？
Git 豆知識
一度コミットしたことはブランチを消す、HEADを過去のものにRESETするなど、ログラインから離れて目に見えなくなってしまってもすぐには消えないので、git reset --hard <失われたコミットID>で復活させることができる
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
Mastodon、データベースさえ守ればサーバ全体をSnapshot等でバックアップ取らなくても良いのではという考えがあり
たいていのウェブアプリのアイデンティティはコードじゃなくてデータに宿ってるよね
手元のマシンたちのrbenvでは古い版の放置して置いてあって特に問題は起きてない気のするなあ
近所のスーパーで買ってきたブリーチーズからぷんぷんアンモニア臭がしてとっても良い
Mastodonのruby 2.7、いつ行けるんだ。Paperclipどーするんだ…
@mayaeh なるほど! あんまり突然でこちらへのノーティフィケーションよりだいぶ前にスパイクが来てました (乱数のディレイちゃんと効いてるよねえ…)
@noellabo オイゲンさんレベルだと何分かの間なんもできなくなりますw Puma 6スレッドでなんとかしてるので。
This account is not set to public on notestock.
スパイクの高さとか幅とか遅くなりかたとか何パターンかあるみたいなのおもしろいよねえ (なんもわからん)
님의 게시물
mayaeh@taruntarun.net
This account is not set to public on notestock.
@mayaeh さんの調査によりブーストされた時のリクエストのスパイクはリモートのfetch_remote_original_statusから来ていてディレイはかけられていないことがはっきりしました
@yakitama curlやopensslでアクセスしてみるとsupport.conoha.jpとmanage.conoha.jpとで挙動が違うのですが具体的に何が違うのかなんもわからん状態になってしまいました…
@yakitama もうちょっと詳しくみてみました。manage.conoha.jpから返却される証明書バンドルにはサーバ証明書の1枚のみが含まれて中間証明書が含まれないため、手元に中間証明書のない環境ではサーバ証明書の検証ができないことが問題のようです。support.conoha.jpから返却される証明書バンドルには同じサーバ証明書と一緒に手元のルートCAで検証できる中間証明書が含まれてました。詳細は https://gist.github.com/zunda/0a61081a4be903b4bb6f74b55d100d44 にて。このはさんに、manage.conoha.jpに中間証明書もいっしょにアップロードしてくださーいってお願いするのが良いかもしれません。
@kuroringo cld3 gemはprotobuf-compilerに依存するのですが、依存先のライブラリが消えちゃってるのかもしれません。protobuf-compilerとlibprotobuf-devが入っているのを確認してcld3 gemを作り直してみるといいかもです。（パッケージ名はUbuntuの場合です）
@mayaeh @kuroringo protobuf関係はyumやapt側です。MastodonのAptfileというファイルにHerokuで提供されていないけれど必要なaptパッケージが列挙されてるので手がかりにできそうです。
@kuroringo 不明瞭でごめんなさい！protobuf関係はyumでインストールします
@kuroringo @mayaeh いつもbundle installをするユーザーでいつものディレクトリに行ってbundle exec gem uninstall cld3とかでcld3 gemを一度消していつもと同じ方法でbundle installしてみるとどうなるでしょう？
@kuroringo それぞれのRubyのバージョンについてこれまでにインストールされたcld3 gemのバージョンの数の合計くらいあったらちょうどいいくらいだと思いますー
@kuroringo InitializationErrorStringというシンボルを提供しているprotobuf関連のライブラリが2つ以上あって、bundle installの時とdb:migrateの時とで違うものを参照してるんだろうとは思うのですが…
@kuroringo find / -name '*protobuf*' などで前後にワイルドカードを付けてみると見つかるかもです
@kuroringo どこのパスに必要なライブラリがあるかはっきりすれば、LD_LIBRARY_PATHでパスを指定したりLD_PRELOADでまず読ませたりもできるかもですけど、うーん…
そもそもなぜbundle installの時とrakeあ、rake db:migrateじゃなくてbundle exec rake db:migrateしてみたらいいのかな？もうそうしてるのかな？
ちなみに弊ぼっちではAptfileからheroku-buildpack-aptによってインストールされるファイルは非標準のディレクトリにあるので、LD_LIBRARY_PATH環境変数を取り除くとRailsが起動できなくなりますw
