Among Us でゲームの状況に応じて自動でミュート・アンミュートしてくれる便利なボットこと AutoMuteUs、ほんとうに便利ですよね。
簡単な使い方であればインタネットの各所に解説記事がたくさんありますが、実は AutoMuteUs には、さらに便利に活用できるいろいろな機能 が用意されています。
本エントリでは、他の解説記事ではあまり触れられていない機能 を中心に、AutoMuteUs をさらに活用するための情報 を紹介します。
なお、文中で 公式サービス と記載していますが、これは AutoMuteUs 開発者が直々に運営しているサービス というだけの意味であり、Among Us の公式サービス ではない ことは念のため明記しておきます。
続きを読む
NUC 8 のオンボード NIC は、ESXi 7.0 U1 から、組み込みのドライバではうまく認識されなくなっています。このため、NUC 8 の ESXi を 7.0U1 以降にアップグレードするには、これまでは対象のドライバ ne1000 だけ旧バージョン（7.0b 世代）にダウングレードする必要がありました。この目的で、以前のエントリ では、特定のドライバだけダウングレードしたカスタムイメージプロファイルの作成と、それを利用したアップグレードを紹介しています。
が、先日、VMware Flings でこの問題を解決できる新しいドライバがリリースされました。
このドライバは、ne1000 ではなく別の新しい e1000-community（と igc-community）として認識されるため、組み込みの ne1000 ドライバと一切競合せず、共存できる 点がポイントです。NIC は ne1000 でなく e1000-community を使って動作するようになるため、ne1000 のバージョンは気にする必要がなくなり、ダウングレードが不要 になります。
プライベート CA が ACME プロトコルを喋れれば、ACME クライアントを使った証明書の発行や更新を気軽に試せて便利です。
もちろん正規の証明書は得られませんが、その代わり、インタネットにポートを露出することなく HTTP-01 チャレンジや TLS-ALPN-01 チャレンジが行えます。公開認証局のリソース負荷やレート制限、CT ログなども気にする必要はなくなりますし、上位の DNS で応答をコントロールすれば、実在しない TLD の証明書も発行できます。
このエントリでは、気軽に実現できる方法のうち、実際に試した次の三パタンを紹介します。
ACME クライアントを試す目的では、ふたつめの Caddy 案が個人的にはいちばん手軽で小回りが効く印象でした。
続きを読む
Among Us のゲームの進行に応じて Discord 上の各参加者のミュート・アンミュートを自動制御してくれるとても便利なボット、AutoMuteUs を初めて触りました。
動作にはボットのインスタンスを立てる必要があり、公開インスタンスが満員だったため、その場で自前サーバでのセルフホスト構成を作ったのですが、Docker でホストできることもあって、動かすだけならとても簡単です。Discord でのボット操作を一手に引き受けられるのであれば、インタネット上で公開する必要すらなく、LAN 内に配置するだけで済みます。
が、自分が居ないときでも仲間内で共同利用できるようにしたい場合、どうしてもボットのインスタンスはインタネット上でホストする必要があり、であれば少しでもセキュアにしたい感触があります。
そんなわけで、平文で行われている一部の HTTP や WebSocket の通信を、Let’s Encrypt の SSL 証明書とリバースプロキシ（Nginx）で暗号化したので、実装例の紹介です。
追記： Caddy でも実装 しました。エントリ末尾の追記部分 で紹介しています。
続きを読む
前回のエントリ で、AfterShokz のフラグシップモデルである Aeropex の音質を紹介しました。その中では、骨伝導であることそれ自体や防水・防塵のメリットは非常に大きい一方で、特に マイクの音質については厳しさがある 旨の記載をしていました。
根本的には Bluetooth のプロファイル（HFP）の仕様の限界があるので、有線のマイクと同等の高音質にはどうやってもできない（サンプリングレートが 16 kHz なので波形は 8 kHz で頭打ちする）のは仕方がないのですが、それにしても常用は厳しいと言わざるを得ない音質でした。
マイクの性能を重視するのであれば、Aeropex ではなく通話に特化した OpenComm の発売を待った方が良さそうです。
AfterShokz Aeropex の快適さと、音質の正直なところ | kurokobo.com
今回、この中でも言及している、通話に特化したモデルであるところの AfterShokz OpenComm を入手したので、主にマイクの性能の観点で、Aeropex と比較しました。
結果として、OpenComm のマイクは、Bluetooth 自体の仕様上の音質の限界はあるものの、Aeropex のそれとは比較にならないくらい充分常用できるレベルで音がよく、総じて満足できそうでした。
続きを読む
本ブログでもちょこちょこ話題にしてきた EdgeX Foundry ですが、最後のエントリからもう半年以上経過してしまいました。
EdgeX Foundry は、半年に一度のペースで新しいバージョンがリリースされます。ぼくが 日本語のハンズオンラボガイド を最初に公開した 4 月時点ではまだ Fuji（1.1） が最新でしたが、5 月に Geneva（1.2）がリリースされ、11 月には Hanoi（1.3）がリリースされています。
というわけで、リリースノートを中心に、Geneva をいまさらおさらいした後、Hanoi の更新情報も見ていきましょう。
続きを読む
AfterShokz の Aeropex を買いました。世に出ているコンシューマ向け骨伝導イヤホンというとだいたい AfterShokz か BoCo あたりになるかと思いますが、Aeropex はそのうち AfterShokz の現時点でのフラグシップモデルです。
骨伝導であること、耳を塞がないこと、装着感の軽さなどから、音を聴くためのコストを圧倒的に下げられて総じて非常に快適 で、防水・防塵性能も満足のいくものでしたが、音質は絶対評価すると正直だいぶ厳しい 感触でした。
もちろん、根本的には 骨伝導方式は絶対的な音質を重視して買うものではない ですし、本質的な価値は骨伝導であることそのもの にこそあるので、そもそも音質 “のみ” でこの製品を語るべきではありません。また当然ながら、骨伝導だと肉や骨の影響も個人で異なりますし、そうでなくても音質の感じ方や捉え方にはそもそも個人差があります。
が、特に音質については、インタネット上のレビュ記事では過大評価感も否めませんでした。そこでこのエントリでは、あくまで個人的な（ぼくの耳に依存した）ものではありますが、音質面での正直な感想をちょろっと書いていきます。
続きを読む
OpenShift 4 では、そのクラスタの構成方法に IPI（Installer-Provisioned Infrastructure）と UPI（User-Provisioned Infrastructure） の二種類があります。
これまで、IPI をサポートするプラットフォームは AWS や Azure、GCP、RHV、vSphere などのパブリッククラウドやオンプレミスの仮想化基盤に限定されていましたが、どうやら先月末にリリースされた OpenShift 4.6 で、ベアメタル環境への IPI インストールが公式にサポートされたようです。
In 4.6, the full stack automation installation of OpenShift on bare metal is generally available.
Red Hat OpenShift 4.6 Is Now Available
これまでも、GitHub 上では ベアメタル IPI の情報は公開 されており、以前も VirtualBMC for vSphere のユースケースとしても実際に 4.5 で動作を確認済み でした。
とはいえ、せっかく公式手順に仲間入りしたので、このエントリでは、OpenShift 4.6 で公式にサポートされたベアメタル IPI インストールの方法を、改めて紹介します。ただし、BMC を積んだ物理サーバが潤沢にあるわけではないので、物理サーバは VirtualBMC for vSphere を使った vSphere 環境の仮想マシンで代替します。
なお、今回紹介する手順は OKD でなく OpenShift のものです。インストールすると Red Hat OpenShift Cluster Manager に登録され、60 日間の評価期間 が始まります。
続きを読む
数年前の VMworld で参考展示がされていた ESXi on ARM ですが、Flings からついに ESXi Arm Edition としてリリースされました。
現段階ではバージョンは 7.0.0（ビルド 16966451）で、機能上は 7.0 の GA 版準拠のようです。
Supported ESXi-Arm Hardware として Raspberry Pi 4 Model B も挙げられていて、家に 4 GB の子が遊んでいた ので、入れてみました。
期待以上に素直に動きましたが、vCLS のエージェント VM が ARM だと動かないため、vCenter Server のバージョンが 7.0 update 1 の場合はクラスタに入れられなくなる（入れられはするがエラーが出続ける）点には注意が必要です。
続きを読む
自宅の第 8 世代の NUC（NUC8i5BEK）で動いている ESXi 7.0b を、出たばかりの 7.0 update 1 にアップグレードしようとしたら、ドライバまわりで死んだので、最終的にどうにかするまでを含めて作業内容を書いておきます。
まとめると、
ne1000 だけは 7.0b のドライバのままにする必要があるな感じです。
今回は、vLCM のイメージ管理を使っていた環境だったので、
ことでアップグレードを行いました。
なお、vCenter Server は ESXi の前に 7.0 update 1 にしていますが、VAMI からすんなりできて特別なこともなかったので、特に触れていません。
続きを読む