Among Us 用超便利 Discord bot “AutoMuteUs” をセルフホストした

注: この記事は、 2020年11月23日 時点の話だよ。 状況は今後も刻々と変わる可能性が高いよ。

今年の夏あたりから、日本でも爆発的なブームが続いている、 宇宙人狼 こと Among Us

Discord でボイスチャットしながらやるのが面白いのだけれど、 ゲームの仕様上、ミュート管理が結構面倒だ。

そこに、 Among Us のゲーム画面に同期してミュート管理を超いい感じに自動で行ってくれる Discord bot が存在する。

それが AutoMuteUs だ。

このツールは、 誰か一人が Windows Steam 版 Among Us のゲームと一緒にキャプチャープログラムを立ち上げ、 公式の Discord Bot と連携させるだけで超お手軽に使える…
…はずだった。

11月下旬現在、 AutoMuteUs 公式の手順に従って .au new コマンドで bot を起動しようとすると、以下のような悲しいメッセージを目にするだろう。

I'm very sorry, but Discord is rate-limiting me and I cannot accept any new games right now :frowning:
Please try again in a few minutes.

Discord のレート制限に引っかかってるって。
Among Us は人気すぎるし仕方ないね!

…何とかしたい。

ちょっと古い v2.4.3 をセルフホストするのが推奨

続きを読む

Raspberry Pi に Ubuntu を入れて SSH でログインするまでの A to B

何番煎じかわからないが、 Raspberry Pi (以下、 RasPi) に Ubuntu を入れる手順についてまとめてみようと思う。

Ubuntu 公式の How to install Ubuntu on your Raspberry Pi チュートリアルは充実しているし、 単にインストールして動かすだけなら、既にある記事でも十分だろうとは思う。
しかし、初回セットアップ時の細かいカスタマイズについて書かれているものがあまり見当たらなかったので、この記事ではそれについて補足しながらまとめていく。

先に断っておくが、 cloud-init による IaC の話が中心になる。

TL;DR

  • 焼いた SD を RasPi に挿すにブートプロセスの設定を書き換える
  • cloud-init の挙動を理解しろ
  • モニター無し & 無線LAN Only だと、工夫がいる
  • ARP リクエストのブロードキャストが届かないと苦労する

きっかけ

続きを読む

激安液タブPC: CHUWI UBook 11.6″ CWI509 お絵かきレビュー

親戚が簡単なお絵かきができる 2-in-1 タブレット PC を欲しがっているということなので、 セールしていた CHUWI UBook を入手してみた。

中華PCを人にオススメするのもどうかとは思ったが、一応 技適もとってる 日本向けのモデルだし、予算と目的がバッチリ一致するので、お絵かき用途ならこれでいいかなと。
10万近くかけて高いノートPC買うほどではものの、そもそもプライベートの PC も持ってないらしいので、基本的人権のメモリ 8GB はある安いの探してたのよね。

買ったマシンのキッティングを行うにあたって、 Windows OS 搭載の一体型液タブとして見てどうだったのかをレビューして見ようと思う。

購入したモデル

今回購入したのは CHUWI UBook と言うモデル。

主なスペックは以下の通り。

続きを読む

Outlook の “会議室の検索” が表示されない場合の対処法

Microsoft 365 (Office 365) など、 Exchange 上の Outlook で新しい会議を作成するウィンドウには、本来であれば 「会議室の検索」 というペインを表示させることができる。
具体的には、以下のスクリーンショットのように、リボンの 「スケジュール アシスタント」 タブに、「会議室の検索」ボタンが存在し、そのボタンによって「会議室の検索」 というペインが切り替えられるようになっている。
本来の表示

ところが、一部のユーザの環境で、この「会議室の検索」ペインも、リボンのボタンも表示されない状態に陥ってしまった。
会議室の検索が表示されない状態

これでは、組織で作成された「会議室の一覧」などが使えず、空き会議室を探すのがとても不便で困る。

ということで、この「会議室の検索」が消える問題の、解消法を紹介する。

続きを読む

ルータを経由すると仮想ブリッジ接続の VM にアクセスできない?

今回は、ネットワークの話。

解決してみれば割としょうも無いトラブルで、時間を浪費してしまったので、自戒の意味を込めて記事にしておく。

サブネット外から ping が通らない

ある日、 ホストPC の NIC とブリッジ接続されている VM に、 サブネット外からアクセスできなくなってしまった。

構成を図にすると、以下のような感じ。
(あまり UML図 に明るくないので、書き方がヘタクソだったり本来の意味と違う記号の使い方をしている点は大目に見て欲しい。)

data:application/gzip;base64,H4sIAAAAAAAEAIVTPU/DMBDdI+U/nLIihziUAhVC5UOCDmWgqAtlMM61jZTYleOIAbW/Hcdy6qQtwkt8757f3dkv40ozpeuyCIMw4IWsM4gmQqMSqCNgFeQuMFkptJIFRG+yNpjNKrsNA4VcM7EqECJ6lcZ0GA/SODlPBxH8hAGYxWW5kQKFhuhFVhqmjK9zgVZlwy3kmM2yVZeMo2O/Th4tE/W6iT2xU3g+raKuxoHO6/27lRBM9zm+s4PDBwKmNm2boMfMzoDzKTzXWGk3nN3/J5200kmfue2H7gKAfKzzLEPxSY4HMoDPn5BsENjtCa7BEZSoVc6BLgS9ad7wOr4cxmn/rCPDzt7CCPxr0+HpTnct9UHl2Qo9yU22PfKHswZIsRAzViLM6q/WjhtuGtqeNNzFn4brCj7lyyWqBu6pUqvamh1uCdl72ySB3Hmr2y+QTH4LcuYdaTpzYOLBMBijyMzv9QsMZU+SaAMAAA

同一サブネット内 (図の "Machine on Same Subnet") から 172.16.42.16 を叩くと VM ゲストに到達するのだが、 サブネット外 (図の "Machine on Different Subnet") からだと ping すら通らない。

以前は同じ構成で、サブネット外から繋がっていたはずだ。

ちょうど直前に、ネットワーク機器のメンテナンスがあったため、 そちらで IPフィルタの動作がおかしくなったのではないかと疑ってしまった。
しかし、繋がらなくなった直接的な原因は、 VM Gurest 側にあった。
このため、答えにたどり着くのに時間がかかってしまった。

アクセスできなかった原因

続きを読む

AWX をインストールした後の Server Error を解決したかった話

この記事は、 Ansible AWX をインストールしたときに、 Server Error に なったりならなかったりする 問題に対処したときのポエムだ。

はじめに断っておくが、最終的に AWX 8.0.0 で解消しているっぽいものの、 原因や正確な条件などは不明なままである。
また後述するが、 (タイトルに反して)おそらく Ansible AWX の問題ではなく、 postgres:9.6 の docker イメージの問題ではないかと思われる。

発生した問題の状況

続きを読む

プロキシ環境下で Ansible AWX をインストールする Playbook を作る

構成管理ツール (いわゆる Infrastructure as Code(IaC)) の中でも比較的易しいと言われる Ansible。
その Ansible の運用を省力化してくれるツールとして Ansible Tower というものがあり、そのコミュニティ管理版 (OSS版) が AWX だ。

その AWX がインストールされたサーバを作成する Playbook を作ろうとしたら意外と手間取ったので、そのメモ。

なお、インストール先は CentOS 7 である。
AWX のインストールは、 公式ビルド済み docker イメージを Docker Compose を使ってコンテナ化する方法 を使った。

11/21: 追記

docker-compose の PyPI (pip) パッケージが 1.25.0 に更新後、 CentOS 7 (正確には、 Python 2 系を使っている環境) で docker-compose のインストールや実行がうまくいかなくなった。
(commit:719a1b0 で) subprocess32 に依存するようになり、 gcc 等のビルド環境のインストールが別途必要になったためだ。

それに加え、たとえ gcc をインストールしても、依存パッケージの python2 対応が不十分なようで、 docker-compose 実行時にエラーになってしまう。

docker/compose#7030 の Issue には挙がっているが、修正されるかどうか不明なため、一つ前の 1.24.1 を使うことで回避するように、コードを修正した。

python2 ツラい。。。
しかし、 2020年にサポート切れになった後も、 CentOS 7 が生きているしばらくの間はこの辛みと付き合わなければならないようだ。
ツラい。。。

追記ここまで

最終的な Playbook

続きを読む

Proxy 下で vscode の WSL 上の他の拡張機能のインストールに失敗する

プロキシ環境下の vscode で、 WSL 上で拡張機能を動かしたいのに、 インストールインストールに失敗する問題を解決するメモ。

前回の↓の記事は、 『Remote – WSL 拡張が有効にできない』問題だったが、今回は『Remote – WSL 拡張 を有効にした後、その環境上で他の拡張機能がインストールできない』問題なのでちょっと違う点に注意。ややこしいね。

遭遇した問題

Visual Sutdio Code (以下、 vscode) へ 無事に Remote – WSL 拡張機能 の "VS Code Server for WSL" のインストールが完了し、 Windows 上から 快適に WSL の環境にアクセスできるようになった。
しかし、 いくつかの vscode の拡張機能は、 Windows 上の環境とは別に WSL 上の環境で改めてインストールしなくてはならない。

そこで、 UI 上の案内に従って各拡張機能で "Install in WSL" を行ったところ、 プロキシ環境下だと以下のエラーが発生してインストールに失敗する問題に遭遇した。

Failed to install extension

パネル上の OUTPUT タブで "Log (Remote Server)" の情報を見ると、以下のようなエラーが発生しているのがわかる。

[remoteagent] [error] Failed to install extension: {拡張機能ID} connect ECONNREFUSED 13.107.6.175:443

settings.json ではプロキシの設定しているし、更には WSL 上の環境変数 (http_proxy, https_proxy) にだってプロキシを入れている。
更には(前述の)前回の記事に倣って、 WSL のコンソール上から code . の立ち上げまで行ってみた。

それでも解消しない。何故だ。

なお、試した vscode のバージョンは、 August 2019 (version 1.38.1) だ。

"Remote [WSL]" 用の設定ファイルを書き換える

続きを読む

Proxy 下で vscode の WSL 拡張へ接続できない

Windows 上の Visual Studio Code (以下、 vscode) で、WSL 上のファイルやシェルを使えるようになる、 Remote - WSL 拡張機能。

これを、プロキシ環境下でインストールしたり更新したりすると、 vscode から WSL 環境ににアクセスするときに、

VS Code Server for WSL closed unexpectedly.
Check WSL terminal for mor details.

とエラーになってしまう。

WSL ターミナルのログを見てみると、だいたい以下のようになっていて、どうやら update.code.visualstudio.com から VS Code Server の更新版のファイルをダウンロードするのに失敗しているように見える。

Starting VS Code Server inside WSL (default distro)
Extension version: 0.39.5, Windows build: 17763. Multi distro support: disabled. WSL path support: enabled
Probing if server is already installed: C:\WINDOWS\System32\wsl.exe  -e sh -c "[ -d ~/.vscode-server/bin/3db7e09f3b61f915d03bbfa58e258d6eee843f35 ] && echo found || echo missing"
No server install found on WSL, downloading server on client side: C:\Users\user\AppData\Local\Temp\vscode-remote-wsl\3db7e09f3b61f915d03bbfa58e258d6eee843f35\vscode-server-linux-x64.tar.gz
Unable to detect if server is already installed: Error: connect ECONNREFUSED 104.42.78.153:443
Launching C:\WINDOWS\System32\wsl.exe sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 3db7e09f3b61f915d03bbfa58e258d6eee843f35 stable .vscode-server 0  --disable-telemetry' in c:\Users\user\.vscode\extensions\ms-vscode-remote.remote-wsl-0.39.5
WSL version: 4.4.0-17763-Microsoft 
Updating server...
Updating VS Code Server to version 3db7e09f3b61f915d03bbfa58e258d6eee843f35
Removing previous installation...
Downloading:     
Failed
--2019-09-11 20:50:12--  https://update.code.visualstudio.com/commit:3db7e09f3b61f915d03bbfa58e258d6eee843f35/server-linux-x64/stable
Resolving update.code.visualstudio.com (update.code.visualstudio.com)... 104.42.78.153
Connecting to update.code.visualstudio.com (update.code.visualstudio.com)|104.42.78.153|:443... 
failed: Connection refused.
ERROR: Failed to download https://update.code.visualstudio.com/commit:3db7e09f3b61f915d03bbfa58e258d6eee843f35/server-linux-x64/stable to ~/.vscode-server/bin/3db7e09f3b61f915d03bbfa58e258d6eee843f35-xxxxxxxxxx.tar.gz
VS Code Server for WSL closed unexpectedly.
For help with startup problems, go to
https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips

どう解決したものか。


そもそも wget でダウンロードができる状態なのか

続きを読む

同一ファイルに対して、 複数種類のファイルハッシュを高速に計算する

ネットワークドライブ上の GB オーダーのファイルに対して、複数のハッシュアルゴリズムでファイルハッシュを計算する必要に駆られていた。
「そんなシチュエーションが本当にあるのか?」と思うかも知れないが、あったのだから仕方ない。

最初は、 PowerShell を使って 愚直に Get-FileHash を 2回 計算していた。
しかし当たり前だが、 2回ファイルをダウンロードすることになるこの方法は遅くて仕方ない。

ということで、 C# でコンパイルしたコード上で、 一度メモリに読み込ませてから複数のハッシュアルゴリズムで計算できるようなコードを作成した。

バッファーサイズを 80KiB 程度とすると、 .NET の仕様で 85KB を境にメモリの扱いが変わる (LOH と呼ばれる特別なヒープに移動する) ことから、 このサイズを超えると一般的に動作速度が下がると言われている。
しかし、今回のコードの場合バッファーが小さいと、 Task 周りの処理がボトルネックになってしまうので、 8MiB くらいのサイズとしている。

80KiB としているのは、 .NET mscorlib の System.IO.Stream.CopyTo メソッドなどでもおなじみなのだが、これが必ずしも正解とは限らないわけだな。


パフォーマンス

800Mbps 位でシーケンシャルリードできるリモート上の 4GB のファイルを、 4回 ずつ計測した平均を計測した。
Get-FileHash の 2種類目 以外はクライアントキャッシュが効かないように注意し、 計測の各回でハッシュを計算するファイルはそれぞれ別のファイルで、中身はランダムバイナリとした。
Get-FileHash については、 計測の各回では同じファイルに対して -Algorithm パラメータを変えて複数回連続で呼び出した。

計算したハッシュの種類 Get-FileHash 上記の改良スクリプト
1種類 (SHA1) 48.8s 43.3s
2種類 (MD5, SHA1) 60.4s 44.2s
3種類 (MD5, SHA1, SHA256) 83.3s 48.2s

ん? 計算したハッシュが 1種類 の場合でも、改良スクリプトの方が早いぞ?


うわっ… HashAlgorithm.ComputeHash の実行速度、低すぎ…?

PowerShell v5 相当

PowerShell v6 相当

上記のように、 Get-FileHash は、内部的に HashAlgorithm.ComputeHash でハッシュ計算を実行している。

で、その HashAlgorithm.ComputeHash がどうなっているかというと、 4KiB 毎に ファイルの読み込みと、 ハッシュストリームへの書き込みを 同期的に 行っている。

ファイルの読み込みも、 (使うアルゴリズムにもよるけど) ハッシュの計算も、 どちらもコストがかかるので、同期的にやってたらそりゃ遅いわ。