winget が使える状態で Windows Sandbox を起動する

Windows Sandbox は、Windows 10/11 Pro 以降に搭載されている仮想環境機能だ。
一時的でクリーンな Windows 環境を素早く作成し、アプリケーションのテストやファイルの検証を安全に行うことができる。

Windows Sandbox を使うにあたって、目的の作業に必要なツールをサクッとインストールしたいことがままある。
Windows 上でツールをインストールする場合、 Microsoft Store や winget を使う事が一般的だ。
しかし、 Windows Sandbox を立ち上げてすぐの環境ではこれらを使うことができない。
加えて、素直にこれらをインストールしようにも、依存関係が満たされていないためインストールに失敗してしまう。

そこで、 Windows Sandbox の設定ファイル (.wsb) を使用して、 Windows Sandbox 起動時に winget が使える状態を整えよう…というが、今回の話。

Windows Sandbox の設定ファイル (.wsb) とは

Windows Sandbox は、XML 形式の設定ファイル (.wsb) を使用して起動時の構成をカスタマイズできる。
この設定ファイルでは、主に以下のような設定が可能だ。

  • vGPU(仮想 GPU)の有効/無効
  • ネットワークの有効/無効
  • 共有フォルダの設定
  • メモリ使用量の制限
  • ログオン時のコマンド実行

詳細な設定オプションについては、以下のマイクロソフト公式ドキュメントを参照:

今回は、上記のうち「ログオン時のコマンド実行」の機能を利用する。

winget をインストールするログオンコマンド

続きを読む

AutoHotKey v2 で 令和の ThumbSense

本記事は、 Windows Advent Calendar 2024 18日目 の記事だ。
思いっきり遅刻してしまって申し訳ない。

突然だが、 ThumbSense を覚えているだろうか?
2002年に SONY が発表した、ノートPCのタッチパッドを用いて、手をホームポジションから動かさずに、マウス操作や様々なショートカットを起動するユーティリティツールだ。
(本家, 窓の杜の紹介記事)

当時はその革新的な操作体験で大いに注目されていたと記憶している 1 し、 ThumbRemap や NewtonPad などのインスパイアされたツールがいくつも登場していた。

しかし、当時のこれらの実装は Synaptic または ALPS 製のタッチパッドのドライバーをフックして実装されていた。このため、令和となった現代、 Windows 10 や Windows 11 が入っているような PC では動かない。

現在流通しているノートPCのタッチパッドは、Windows 8.1 で追加され Windows 10 で強化された、 USB 等の HID プロファイルに基づいた実装になっている。

先日の記事 の通り、 RawInput で HID の情報を拾えばかなり細かくタッチパッドの状況がとれる。
AutoHotKey 使えば、 ThumbSense のような実装もそこまで難しくないのでは…?

…と思って AutoHotKey v2 で実装してみたのが、本日の記事になる。

ThumbReSense のインストール

GitHub の advanceboy/ThumbReSense-ahk のリリースページ から、最新の exe ファイルをダウンロードして、起動するだけ。

SmartScreen の警告が出る場合は、 exe ファイルを右クリックして、セキュリティのブロック (ZoneId) を解除しよう。

また、 AutoHotKey v2 用のソースもリポジトリにあるので、こちらをダウンロードしてインストール済みの AutoHotKey v2 で起動しても OK だ。

常用するなら、 Windows のスタートアップフォルダにでも突っ込んでおけば PC 起動時に自動で起動するようになる。

AutoHotKey の制限として、通常タスクマネージャなどの管理者特権で動くソフト上では機能しないのだが、 ThumbReSense の実行ファイル (またはスクリプトを起動する AutoHotKey) 自体を管理者権限として実行すればこの制限を回避できる。
自動起動させたい場合、タスクスケジューラを使って、ログオン時に管理者権限として起動する設定にしておくと良いだろう。

残念ながら、 Windows Sandbox やリモートデスクトップでは、ホットキーを機能させる方法がなさそうだ。

使い方

続きを読む

毎日最初のロック解除時に特定の URL を開くためタスクトレイに常駐する PowerShell スクリプト

シェルスクリプト&PowerShell Advent Calendar 2024 の 15日目 の記事だ。
ついでに、 Windows Advent Calendar 2024 15日目 の記事としても登録させてもらっている。

電子タイムカードの打刻など、毎日出勤時に PC で特定の Web サイトを操作する事を強要されることは無いだろうか?
その作業習慣が血肉となるまで魂に刻み込まれるまで飼い慣らされていないと、頻繁に操作を忘れてしまう。

普段 PC をシャットダウンしているのであれば、スタートアップにその Web サイトの URL を登録しておくことで、 PC ログイン時に自動的にそのページが立ち上げられるので、やり忘れを防止できる。

しかし、普段 PC をスリープしっぱなしな運用にしている場合、朝初めてPCを立ち上げ(スリープ解除)した際に、特定のページを開かせるのは意外と難しい。

そこで、 PC のタスクトレイに PC のロック解除イベントを監視する PowerShell スクリプトをタスクトレイに常駐させ、「その日最初のロック解除」の時に特定の URL を開く仕組みを作成してみた。

導入手順

続きを読む

docker の snap パッケージをプロキシ環境で使う方法と、 compose で build エラーになる話

本記事は、 Docker/コンテナ仮想環境 Advent Calendar 2024 - Qiita 5日目の記事だ。

Linux で docker をインストールする場合、どのようにしているだろうか?
OS 標準のパッケージマネージャーからのインストールが一般的? それとも、 Docker 公式のリポジトリ (Install - Docker Docs) を使っているだろうか?

そんな docker インストールする方法のひとつに Snap (Snapcraft) がある。

Snap (Snapcraft) とは

Snap (Snapcraft) は、Canonical が開発・管理している、アプリケーションをパッケージ化して配布するためのシステムのひとつだ。 Canonical は Ubuntu を支援している企業だが、 Ubuntu 以外の多くの主要なディストリビューションでも Snap を利用できる。

依存関係を含む一式がコンテナ化されており、異なる Linux ディストリビューション間で共通のパッケージで動作するのが特徴だ。 サンドボックス化したファイルシステム内でインストールしたアプリケーションを動かすという、セキュリティ面の特徴もある。

snap 版 docker は、 /home/ 以下のファイルしか参照できない強い制限 1 や、インストール時に docker グループを作成してくれない制限があるが、それ以外はわりと問題なく動く。

Snap 版 docker に於けるプロキシ設定手順

プロキシの設定さえ適切に行えば、 snap 版 docker もプロキシ環境下で動作する。

基本的な設定箇所は、 Docker DaemonDocker CLI の設定と同じだが、前述のサンドボックス化の関係で、記述するファイルの場所が異なる。

具体的には

  • /etc/docker/daemon.json の替わりに /var/snap/docker/current/config/daemon.json
  • ~/.docker/config.json の替わりに ~/snap/docker/current/.docker/config.json

をそれぞれ書き換える。

特に後者 (~/snap/docker/current/* 以下) については、一度そのユーザーで何らかの docker コマンド (後述の例では docker info) を実行してから設定しなくてはならない。
そうしないと、フォルダが Snap サンドボックスへマッピングされないからだ。

では、インストールからの手順を追ってみよう

続きを読む

k8s ミリしら向けの AWX on MicroK8s with プロキシ

Docker ぐらいならなんとかわかるけど、 Kubernetes (k8s) は全然わかっていない人向けに、プロキシ環境下の MicroK8s 上で AWX をインストールする手順と、その周囲情報を説明していく。

AWX とは

AWX とは、 Ansible Automation Controller (旧称: Ansible Tower) と呼ばれる Ansible の構成コードの実行を管理する WebUI を持ったツールの OSS版だ。

Ansible とは IaC (Infrastracture as Code) ができる CUI ツールであり、構成先に Python さえ入っていれば、そこに ssh するだけで実行できるのが特徴だ。
AWX はこれを Git などのソースコード管理ツールと連携しながら、 Web UI 上で実行・管理・記録できるツールとなる。

Ansible Automation Controller と比べると、 Red Hat によるサポートや LTS はなく、 ローリングリリースモデルを採用していて更新が激しい。
このため、エンタープライズ用途には基本的には向かないものの、元々そんなに破壊的変更が頻繁にあるタイプのツールではないため、小規模に使う程度ならかなり実用的になっている。
(但し 2024年9月現在、次回のメジャー更新の v25 あたりで、認可・認証の内部構成が大きく変わる予定ではある 1)

Kubernetes と MicroK8s

AWX を運用環境にインストールするには、 Kubernetes が必須となっている。

Kubernetes (多くは K8s と略される) は、コンテナ管理ツールのひとつで、コンテナオーケストレーションツールとも呼ばれる。

コンテナ管理といえば、 Docker が非常に有名だ。
Docker はどちらかというと開発者よりのツールで、一つのコンテナないし、 Docker Compose を使って一つのホスト(マシン)内に閉じた複数のコンテナの管理に特化している。

一方、多少規模のあるサービスをコンテナで運用する場合、複数ホストにまたがっていくつものコンテナを協調動作させる場合が多い。

Kubernetes であれば複数のホストに跨がって複数のコンテナを協調操作させる運用管理ができる。
例えば・・・

  • 異なるホストで動作しているコンテナを、同じ仮想ネットワークにあるかのように扱う
  • 負荷に応じてコンテナをスケーリングする
  • コンテナ起動やダウン時の自己修復や負荷分散のロジック等を自分で作り込む

といった事ができる。

続きを読む

Ventoy ブート時の Verifiying shim SBAT data エラーのワークアラウンド

久々に、 Ventoy: A New Bootable USB Solution をブートしようとしたら、以下のようなエラーが発生してしまった。

Verifiying shim SBAT data failed: Security Policy Violation
Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation

スペルのブレで場合によっては以下の表記となっているかもしれない。

Verifying shim SBAT data failed: Security Policy Violation
Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation

どうやら、セキュアブートをサポートする UEFI 環境で起動しようとすると、上記エラーが発生するようだ。

本記事執筆時の Ventoy 最新版 1.99 では修正されていない。
もしかしたらより新しいバージョンでは修正されているかもしれないので、古いバージョンを使用しているなら、まずはバージョンアップを試してみよう。

ただ、大分前 (2023年12月) から問題になっているのに、 Ventoy 側にはこの修正が反映されていない。
このため、この問題のワークアラウンドについて紹介しよう。

ワークアラウンド方法1) セキュアブートを無効にする

単純な話、セキュアブートでエラーになっているのだから、 UEFI 設定でセキュアブートを無効にしてしまえば良い。

続きを読む

MicroK8s で kustomization.yaml を apply すると error: accumulating resources になる問題

MicroK8s で kustomization.yaml を apply した際に、 error: accumulating resources が発生する問題についてのメモ。

端的に言うと、snap でインストールした MicroK8s で、内部的に git コマンドが実行される操作をすると、おかしくなる模様。

発生する問題

snap で MicroK8s をインストールし、 kubectl apply -k する。
このとき、Kustomize に指定する kustomization.yaml には、直接的または間接的に remote directory 方式のリソースを参照する。

$ sudo snap install microk8s --classic --channel=latest/stable
$ cat << EOF > ./kustomization.yaml
resources:
- https://github.com/kubernetes-sigs/kustomize//examples/helloWorld/?timeout=120&ref=v3.3.1
EOF
$ microk8s kubectl apply -k .

すると、以下のようなエラーが発生する。

ホストOS に git がインストールされている場合:

error: accumulating resources: accumulation err='accumulating resources from 'https://github.com/kubernetes-sigs/kustomize//examples/helloWorld/?timeout=120&ref=v3.3.1': URL is a git repository': failed to run '/snap/microk8s/6364/usr/bin/git fetch --depth=1 https://github.com/kubernetes-sigs/kustomize v3.3.1': /usr/lib/git-core/git-remote-https: symbol lookup error: /snap/core20/current/lib/x86_64-linux-gnu/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE
: exit status 128

ホストOS に git がインストールされていない場合:

error: accumulating resources: accumulation err='accumulating resources from 'https://github.com/kubernetes-sigs/kustomize//examples/helloWorld/?timeout=120&ref=v3.3.1': URL is a git repository': failed to run '/snap/microk8s/6364/usr/bin/git fetch --depth=1 https://github.com/kubernetes-sigs/kustomize v3.3.1': fatal: unable to find remote helper for 'https'
: exit status 128

ワークアラウンド

続きを読む

Docker Compose で、ベースイメージが更新された場合のみ再 up する

本記事は Docker/コンテナ仮想環境 Advent Calendar 2023 の3日目の記事だ。

2日目は @ko-he-8 氏の /var/lib/docker/が肥大化していたけどdocker system prune --volumesで解決しなかったので調べてみた #Docker だった。
なんかの拍子にコンテナが管理外になってしまっていて docker system prune で削除できないときのお話になっている。
開発用の仮想マシンをリセットせずに使い続けていたりすると、こういう状況に良くなるよね…


Docker Compose だけで雑に本番運用する際に、定期的にリビルドしたい

信頼できるオフィシャルイメージを元に、カスタムイメージをビルドして本番運用する場合、 CI 等でビルドしたイメージをコンテナレジストリに push し、それを本番環境側で pull するのが一般的なベストプラクティスだ。

しかし、クラスタも構築せず VM 1台でいくつかのコンテナを動かすような小規模な運用ほ場合、わざわざ CI やレジストリを準備するのも面倒だ。
このため、運用環境上で Docker Compose を使ってイメージのビルドやコンテナの起動を行ってしまう単純な構成にしたくなる。

そんな時、ベースイメージのセキュリティ更新に追従するために、定期的にイメージをリビルドした上で、必要な場合に限ってコンテナを再 create & up させる方法を考える。

BuildX 既定化による弊害

以前は、 docker-compose pull --no-paralleldocker-compose build --pull の標準出力のいずれかから、 新しいイメージが pull されたことを示す "Downloaded newer image" の文字列があるかどうかを確認し、 docker-compose up すればよかった。

ところが、 docker 23.0.0 にて、 Linux 環境における既定のビルダーが BuildKit というものに切り替わってしまった。
旧来の docker-compose V1 の docker-compose build ないし、 Docker Compose V2 の docker compose build 実行時は docker CLI を通じてビルドされる ため、この仕様変更の影響を受ける。
このため、規定の設定のままだと build の仕組みが変わってしまい、上述のベースイメージのダウンロードを検出できなくなった。

BuildKit は規定では出力をいい感じにまとめてしまうので、そのままだとベースイメージの pull があったかどうか判別できない。

環境変数で DOCKER_BUILDKIT=0 を設定しておけば、旧来の Legacy Builder でビルドをしてくれるが、いつまでサポートされるかわからないので、 BuildKit を使う方法でなんとかしたい。

幸い、 docker build --progress=plain の出力の指定 は、 docker compose build でも働いてくれる。

この出力から ^#[0-9]+\s+resolve\s+ の正規表現がヒットする場所を探してくれば検出できそうだ。

Docker Compose V2 に対する出力オプション

また、既に廃止済みの docker-compose V1 の代替として、 Docker Engine 20.10.13Docker Compose V2 プラグイン がインストールされるようになって以降、現在はこちらの docker compose コマンド使う必要がある。

Compose V2 は、多くの面では docker-compose V1 と互換があり、作成されるコンテナ名のセパレータが一致しない事 (これも --compatibility フラグ で互換性を維持できる)以外はおおむねそのまま利用できる。

ただ、コマンドの UI 出力の内容や、それに纏わるオプションは V1 から大きく変わっているので、そこらへんは調整してやる必要がある。

--ansi never オプションを指定すると、ANSI エスケープコードが無効化され、ターミナルの色がつかなくなったり、パイプ時に余計な文字コードが確実につかなくなる…はずなのだが、指定しても up した時のログぐらいにしか効果が出ないような気はする。
規定値だと auto なので、パイプ処理された場合はそもそも ANSI エスケープコードがつかないはずではあるが、とりあえずオプションの方でも never を強制しといた方が良さそうなので設定しておく。

--progress plain オプションを指定すると、インタラクティブな出力が無くなり、以下のようにパイプで処理しやすいプレーンなテキストが出力されるようになる。
Docker Engine 24.0.3 に同梱されている Docker Compose 2.19.0 移行で compose のグローバルオプションに昇格したオプションであるため、それより低いバージョンだと指定できない点に注意。

$ docker compose --progress plain pull
 alpine-built1 Skipped - No image to be pulled
 alpine-built2 Skipped - No image to be pulled
 alpine-pure2 Skipped - Image is already being pulled by alpine-pure1
 alpine-pure1 Pulling
 070eb51debd9 Pulling fs layer
 070eb51debd9 Downloading [>                                                  ]   28.1kB/2.808MB
 070eb51debd9 Downloading [==================================>                ]  1.911MB/2.808MB
 070eb51debd9 Verifying Checksum
 070eb51debd9 Download complete
 070eb51debd9 Extracting [>                                                  ]  32.77kB/2.808MB
 070eb51debd9 Extracting [==================================================>]  2.808MB/2.808MB
 070eb51debd9 Pull complete
 alpine-pure1 Pulled

docker compose build, up のステータスの出力は、標準出力ではなくて標準エラーの方に出るので、パイプラインつなぐときは注意。

実際のコード例

compose.yaml が存在するディレクトリを /var/lib/docker-compose-dir とした場合、以下のようにできるだろう。

cd /var/lib/docker-compose-dir && { \
  /usr/bin/docker compose --ansi never --progress=plain pull --no-parallel; \
  /usr/bin/docker compose --ansi never --progress=plain build --pull; \
} 2>&1 | \
grep -E "Downloaded newer image|\s+Pull complete\s*$|^#[0-9]+\s+resolve\s+" && \
/usr/bin/docker compose --ansi never up -d

--

さて、こういうコードは cron 等で定期的に実行させたい。
そういった場合、あとから状況を確認しやすくするために、 docker compose の各出力は journald にも書き込んでおきたい。

条件分岐を行うための grep と、 journald に記録するコマンド (logger 等) の両方にパイプしたい場合、 bash や BusyBox ash 等が持つ プロセス置換 が使えそうだ。
crontab が起動するコマンドは、 sh という名前で POSIX 標準互換モードで動かすディストリビューションが多い (debian (Ubuntu) 系, fedora (RHEL, CentOS) 系) ので、明示的に bash (または ash) を呼び出し、その中でプロセス置換を行う方が安全だろう。

例えば Ubuntu の crontab 内で定期的にイメージのリビルドを行う場合、以下のようにすると良いだろう。

cd /var/lib/docker-compose-dir && { \
  /usr/bin/docker compose --ansi never --progress=plain pull --no-parallel; \
  /usr/bin/docker compose --ansi never --progress=plain build --pull; \
} 2>&1 | \
bash -c "tee >( logger -i -t user/docker-auto-rebuild -p user.info )" | \
grep -E "Downloaded newer image|\s+Pull complete\s*$|^#[0-9]+\s+resolve\s+" && { \
  /usr/bin/docker compose --ansi never up -d 2>&1 | \
  logger -i -t user/docker-auto-recreate -p user.info; \
}

なお、実際には cron 内のコマンドでは改行できないので、改行は削除して記述しよう。

後ほどミュートを解除しておく PowerShell スクリプト

本記事は シェルスクリプト&PowerShell Advent Calendar 2023 の1日目の記事だ。
如何にハードルを下げるかを考え、しょーもない内容となることを意識している…と言い訳しておこう。

何故ミュートを解除したいのか

さて、一時的に PC をミュートにしておきたい事がある。

コロナ禍を経て、 Cisco や Polycom といったテレビ会議システムに替わって、 Zoom などのWeb会議ソフトが普及した。
しかし、近年出社を強要されるのが一般化してくると、結局以前のように会議室に集まって、離れた拠点の相手とビデオ会議を行うことになる。
このとき、全員各々のPCでビデオ会議には参加するものの、音声は卓上マイク&スピーカー使う事があり、ハウリングを避ける為に卓上マイクを使う人以外はスピーカー・マイクをミュートにするだろう。

ところが、会議終了後ミュートしっぱなしにしてしまい、通知等に気づきにくくなることがあるので、一定時間後にミュートを簡単に解除できるようにしておきたい。

それだけのために、スクリプト経由で MMDevice API 呼ぶのも仰々しいなぁと思っていた所、よく考えたらキーボードにあるミュート状態をトグルキーを仮想的に押せばいいじゃないかと気づいた。

ということで、早速 PowerShell でキーボードのマルチメディアキーを押すスクリプトを書いてみる。

早速コード例

続きを読む

電Go!! の ZUIKI コンは製造時期による違いがある?

電車でGO!!専用ワンハンドルコントローラー - 瑞起 ZUIKI (以下、 ZUIKIコン) には、 型番 : ZKNS-001 の通常版 と、 型番 : ZKNS-002 の EXCLUSIVE EDITION の二種類ある。
更に、2023年12月には「ズイキマスコン for Nintendo Switch™ RED (ZKNS-011) / BLUE (ZKNS-012)」がリブランドされて追加発売となった。

これらは、 Nintendo Swtich 上では同じように使えることから、外観以外は同じものにも見える。
しかしどうも、製造時期による微妙な違いもあるようだ。

その違いのせいで、 JR東日本トレインシミュレータ で ZUIKIコン 使うツールがな機能しなくなって困ったので、その対処をした話。

きっかけ

元々、2021年の発売当初から通常版の ZUIKIコン を購入しており、公式で対応している 電車でGo!! Switch 版 や ソニックパワードの 鉄道にっぽん! シリーズ Real Pro など に加え、 Switch版電車でGOワンハンドルマスコンで操作できるようにしてみました - Steam コミュニティー で紹介されてるツールを使って JR東トレシム で使っていたりしていた。

程よい重量感や操作感で臨場感が爆上がり… というか、無いと面白みが8割減レベルに気に入っており、最近 EXCLUSIVE EDITION を買い増した。

…ところが買い増しした ZKNS-002 は、Switch 版や 鉄道にっぽん! シリーズでは問題なく動くのに、上記ツールを使って JR東トレシム しようとすると以下のようなエラーが出て動かない。

Traceback (most recent call last):
  File "main.py", line 24, in <module>
  File "SwitchDenGo.py", line 32, in loadStatus
pygame.error: Invalid joystick button
[33064] Failed to execute script 'main' due to unhandled exception!

存在しない joystick 番号を指定されてエラーになってる。
…つまりボタン配置が違う?

しかしそもそも、この ZUIKIコン は汎用 USB コントローラ として認識されるモノだし、Windows OS 側のデバイスの設定を見ても、どちらも同じ "One Handle MasCon for Nintendo Switch" と認識され、全くボタン配置で認識されている。
なんでボタン配置がズレるのか、訳がわからないよ。

上記 Steam コミュニティー でも、同じような問題に遭遇している人が何人かいる。
しかも、 通常版 ZKNS-001 か EXCLUSIVE EDITION ZKNS-002 かを問わず発生するようだ。

つまり、型番違いによる仕様変更が原因ではない…?

意外なる原因

続きを読む