bundle install時にGitHubが認証を求めてきたら環境変数を設定しろ
bundle installを実行したとき、途中でGitHubが認証を求めてくるケースがある。具体的には、GitHubのprivate repoに置かれているソースを直接gemとして利用したい場合である。
つまりGemfileにこういう書かれ方をしてて、 karia/hogefuga がprivate repoなときね。
git_source(:github) { |repo| "https://github.com/#{repo}.git" } gem 'hogefuga', github: 'karia/hogefuga'
このとき以下のような間違いをよく犯す。
- GitHubのSSHキーが正しく設定されていることを確認する（git_sourceの通りhttpsで取得するのでSSHを確認しても無意味）
- IDとパスワードの入力プロンプトが出るのでGitHubのIDとパスワードを入れてみる（入力を求められるので「行けるのか？」と期待してしまうが、実際入れてみると「2021年でその機能は廃止された」と表示される）
正解は
である。何度やっても忘れるんだよこれ。というわけでタイトルが全ての記事でした。
参考
BUNDLE_GITHUB__COM っていうダサい環境変数名一体なんなの？と長年思っていたが、ホスト名 github.com に含まれるドットを__に変換するルールによるものだとわかった。
Any . characters in a host name are mapped to a double dash (__) in the corresponding environment variable.
きちんと一次ソースに当たるのは大事。
Amazon Linux 2023とRuby3.0とOpenSSL 3
Amazon Linux 2使いの皆さんはもうAmazon Linux 2023への移行を済ませただろうか。私はまだだ。もうそろそろ移行を開始したいところではあるが、どうもOpenSSLを巡ってかなりややこしい状態になっている。
現状の整理
AmazonLinux2/2023と、デフォルトでインストールされているOpenSSLの関係は以下のようになっている。
| OS | OpenSSL |
|---|---|
| Amazon Linux 2 | OpenSSL 1.0.2 *1 |
| Amazon Linux 2023 | OpenSSL 3 |
Amazon Linux 2023への移行を早々に進めていきたいところではあるのだが、動作させるアプリケーションがRuby3.0である場合に問題となる。
なぜなら、Ruby3.0はOpenSSL 3をサポートしないからである。このためOpenSSL 3しか存在しないAmazon Linux 2023にはRuby3.0を直接入れることができない。この問題はUbuntu 22.04でも同様のようだ。
戦略
一旦OSはAmazon Linux 2のままとしておき、rbenv & ruby-build経由でインストールすることとした。もしruby-buildがうまくいかなければ、ruby-buildを最新版にすること。ruby-build 20220710以降でなければ、以下のPRが含まれていないためだ。
先の見通し
これでRuby3.0のインストールは何とかなった。だが、そもそもOSがサポートするOpenSSLが1.0.2なのは早急になんとかしたい。OpenSSL 1.1.1ですら2023/09/11でEOLを迎えるようで、さっさとOpenSSL 3系の世界に行かないと。
Ruby3.1以降はOpenSSL 3をサポートしたので、アプリケーションをRuby3.1以上に対応させた上で大手を振ってAmazon Linux 2023に移行することにしよう。どうせRuby3.0のサポートももうすぐ終わってしまうことだし。
余談
早くdockerにしろという声が聞こえてくるが、深淵な理由でローカルにもRubyを入れる必要があったため、この記事に書いた内容を調査するに至った。この辺りは語る機会があればまた今度。
ちなみにpythonのurllib3モジュールが、最近OpenSSL 1.1.1未満のサポートを切った。
この影響を受けてansibleのdockerモジュールがAmazon Linux 2上では動作しなくなった。つまり、dockerのホストOSとしてもAmazon Linux 2は適切ではなくなってきている。
Among Usと連携するDiscordのBOT「AutoMuteUs」をVPSで動かしたときのメモ
Among Usと連携してDiscordを自動ミュートにしたり部屋のIDを通知したりする「AutoMuteUs」というBOTがある。
github.com
非常に便利なのだが、Among Usが人気なせいか公開されているBOTは動作がいまいち不安定だったり遅かったりするらしい。また、自前で立てようとするとバージョンによってコロコロ設定すべき箇所が変わってるようだ*1。
ということで、自分が管理するVPSで動かした際の要点をメモっておく。また一度も実際に遊んだことがなく、これで本当にミュートが動作するのかはわからない（人がいないときに動作を確認したため）。現在のバージョン・ご自身の環境などを勘案して適宜読み替えてほしい。
目次！
サーバー側（AutoMuteUs）
- Lightsailのコンソールにて、ファイアーウォールで任意のポートを開放しておく
- 以下のサンプルでは65535にしている
- dockerおよびdocker-composeをインストールしておく
あとは以下のQiitaの記事通りで概ね動作する……ハズなのだが、バージョンが上がったせいか .env の設定でハマりどころがあった。
.env の設定
.envで実際に設定が必要だったのは以下。
AUTOMUTEUS_TAG=6.5.0 GALACTUS_TAG=2.4.0
dockerイメージのタグを指定する。タグの一覧は以下にあり、現時点での最新バージョンを指定した。
- AUTOMUTEUS_TAG
- GALACTUS_TAG
DISCORD_BOT_TOKEN=xxxxxxxxxxxxxxxx
Discord Developer Portal にて発行したTokenをコピーして貼り付ける。発行方法の詳細は以下の「BOT_README.md」を参照。なおこのTokenは後ほどクライアント側でも必要となる。
https://github.com/denverquane/automuteus/blob/master/BOT_README.md
GALACTUS_HOST=http://example.com:65535 GALACTUS_EXTERNAL_PORT=65535
example.com にはホスト名を、GALACTUS_HOSTの末尾とGALACTUS_EXTERNAL_PORTには先ほど解放したポート番号を指定する*2。
なお、人によっては「2020年になってHTTP？」と思われるかもしれない。リバースプロキシを立てればHTTPSにすることが出来るようだがまだ試していない*3。
クライアント側（AmongUsCapture）
AmongUsCaptureを動作させる人は、 理論上は AutoMuteUs を稼働させている人と同一でなくても良いはずなので、そういう書き方にしてみた。1台のAutoMuteUsを使って複数の部屋を同時進行させることも可能なようだが保証はしない。
初回のみ
1) Among Usを遊ぶのと同じWindowsマシンで「AmongUsCapture.exe」を起動 2) settings→Discordで「Discord token」を設定しsubmit
※Discord tokenは、AutoMuteUsを動かしてる人に聞いて設定する（＝先ほど設定したものを利用する）
3) Among Usを起動し、FREEPLAYを遊んでみてAmongUsCaptureにログが出ることを確認する
※FREEPLAYではDiscordのミュートのオンオフは操作されずログだけが流れる
ゲームプレイ時
1) ボイスチャンネルに入る（次のコマンドより先にVCに入ってないとエラーになる） 2) テキストチャンネルで .au new と打つ 3) BOTからDMが来るので、aucapture:// から始まるURLをクリック 4) [ClientSockeet]: Connected successfully! と表示されたら接続OK
※AmongUsCapture.exe は、URLをクリックすると勝手に起動するので事前に起動しなくてよい
こんなときは
- 複数のDiscordサーバーにAutoMuteUsを導入したいとき
Discord Developer PortalでOAuth2を複数回（Discordサーバーの数だけ）認証すればよい- 全サーバーでTokenは共通である。Tokenをリセットする時は全サーバーに影響するので注意する
1つのAutoMuteUsプロセスを複数サーバーで共用させるのは、あまりセキュアじゃなさそうに思える。テスト用の1人サーバーと本番用サーバーぐらいに留めておくべきではないかと思う。
