advanceboyの投稿 - Crieit

Raspberry Pi 5 に Ubuntu 24.04 LTS を入れて SSH するまで

2024-02-27T00:46:48+09:00

ついに日本でも、 Raspberry Pi 5 の技適対応モデルが発売された。

Raspberry Pi にインストールする OS と言えば、まずは Raspberry Pi OS (旧 Raspbian) だが、同じ Debian ベースの Ubuntu も Raspberry Pi 向けの公式イメージを出している。

但し、 Raspberry Pi 5 に対応しているのは、 Ubuntu 23.10 (コードネーム: mantic) 以降のみとなる。

現在リリース済みの 23.10 は「非LTS」バージョンとなり、サポートが 9ヶ月 (2024年6月まで) と短い。
常用するなら、サポートが 5年 (ESM なら 10年) と長い LTS バージョンが望ましいが、残念ながら 22.04 LTS Raspberry Pi 5 に非対応だ。

LTS バージョンの次回リリースは 24.04 LTS (コードネーム: noble / 2024年4月リリース予定) で、現在絶賛開発中だ。

そんな開発中の 24.04 LTS も、デイリースナップショットが手に入る。
そいつを使ってディスプレイやキーボードが無い状態で、インストールから SSH 接続までやってみよう。

Raspberry Pi 5 をターゲットに書いているが、 Raspberry Pi 3, 4, Raspberry Pi Zero 2 W でも同じ手順でできるはずだ。

なお、この記事は 24.04 LTS がリリースされたら、それに併せて内容に書き換えていくつもり。

TL;DR

microSD カードに Ubuntu の OS イメージを焼いたあと、 RasPi に挿す前に初回起動時の設定を書き換える
cloud-init の挙動を理解しよう
ディスプレイなし & 無線LAN Only だと少し工夫がいる
今回の記事の内容は、Raspberry Pi に Ubuntu を入れて SSH でログインするまでの A to B | Aqua Ware つぶやきブログの二番煎じ
- Ubuntu 24.04 LTS に合わせて内容はアップデートされている

準備するもの

Raspberry Pi 5
- Raspberry Pi 3, 4 でも同じ手順でいけるはず
4GB 以上の micorSD カード
- IOPS が高い、「アプリケーションパフォーマンスクラス」が A2 のものが良いだろう。値段や速度を考えると、実用上は 64GB 以上になるだろうか。
- 私は、ARCANITE 64GB microSDXCカード【A2】、UHS-I U3、V30、4K、C10 値段の割にパフォーマンスが良かったため、これを使った。
- 後述するが、最終的には NVMe SSD にした方が断然良い
microSD を書き込める PC (Win, Linux, mac)
インターネットに繋がる Wi-Fi またはイーサネットケーブル

以下もあると便利だが、今回の手順では無くても問題ない。

micro-HDMI で繋がるディスプレイ又は変換コネクタ
RasPi に繋げる USB キーボード

イメージファイルの取得

正式リリース前の Raspberry Pi 向けデイリースナップショットイメージは、以下のいずれかから手に入る。

今回は、サーバーOS的に SSH して使う事が目的なので、後者のサーバー版を利用する。

Raspberry Pi 向けデスクトップ版イメージ
- https://cdimage.ubuntu.com/daily-preinstalled/current/
Raspberry Pi や、汎用 64-bit ARM, RISC-V 向けサーバー版イメージ
- https://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/

リンク先から、 noble-preinstalled-server-arm64+raspi.img.xz を選択してダウンロードしよう。

24.04 LTS が正式リリースされれば、 Install Ubuntu on a Raspberry Pi | Ubuntu のページからダウンロードできるようになるはずだ。

ブータブル SD の焼き込み

ダウンロードしたイメージファイルを、ブート可能な状態で microSD に書き込む。
ダウンロードしたファイルをただ SD カードに保存するのではなく、専用のツールで書き込む必要があるぞ。

方法は色々あるのだが、今回は個人的にオススメな balenaEtcher を使った方法で紹介しよう。

microSD を SDカードスロットに挿す
balenaEtcher を DL & 起動する。
- DLする balenaEtcher は Portable 版で良い
前項でダウンロードするした ***.img.xz を選択して、書き込みを開始する
- ***.img.xz は、 ***.img ファイルを .xz 形式で圧縮したものなのだが、手動で解凍せず直接 balenaEtcher で選択してしまって問題ない。 balenaEtcher は書き込み時にオンザフライで解凍する。

なお、リリース済みの Ubuntu (や Raspberry Pi OS など) であれば、一般的に Raspberry Pi Imager というツールを使った方法がオススメされるのだが、DLが遅いからか、全体的に時間がかかるので私はあまりオススメしない。

system-boot パーティション内の cloud-init 等の設定を書き換える

作成した micorSD を早速 RasPi に挿す …前に 、初回セットアップ設定を書き換える。

一度書き込んだ microSD を再び PC に挿し直すと、 "system-boot" という 500MB 位の FAT32 パーティションが開けるはずだ。

ここには、 cloud-init という仕組みで初回起動時の設定を定義するファイルがいくつか含まれている。
これらを書き換えていく。

書き換え後のファイルはこちらの Gist に置いてあるので、結果だけ欲しい人はここから DL をば。

cloud-init の network-config

以下のように書き換える。
(元のファイルからの差分を diff のフォーマットで表示している。以降同様。)

--- network-config.org  
+++ network-config      
@@ -22,23 +22,11 @@
   ethernets:
     eth0:
       dhcp4: true
       optional: true

-#  wifis:
-#    wlan0:
-#      dhcp4: true
-#      optional: true
-#      access-points:
-#        myhomewifi:
-#          password: "S3kr1t"
-#        myworkwifi:
-#          password: "correct battery horse staple"
-#        workssid:
-#          auth:
-#            key-management: eap
-#            method: peap
-#            identity: "[email protected]"
-#            password: "passw0rd"
-#            ca-certificate: /etc/my_ca.pem
-
-#      regulatory-domain: GB
+  wifis:
+    wlan0:
+      dhcp4: true
+      access-points:
+        "SSID-of-myhomewifi":
+          password: "password-of-myhomewifi"

Ubuntu では Netplan を使ってネットワークが管理されるため、 Netplan の形式で記述する。

規定値では IPv4 の有線イーサネットのみ、 DHCP 自動取得で接続されるようになっている。
必要に応じて、上述のように Wi-Fi で接続する SSID 等の情報を追記したり、逆に有線LANを使わないなら ethernet: プロパティごと削除してしまってもよいだろう。

SSID やパスワードは、各自の環境のものに置き換えて書き換えてほしい。

コメントアウトされている wifi の記述例では、 wifis.wlan0.optional を true に設定しているが、もし Wi-Fi 単独でネットワークに接続するつもりならこの設定は行わないようにしよう。
さもないと、OS起動の度に2分も余計に時間かかる羽目になる。
これは、 systemd-networkd-wait-online.service デーモンが、(optional true を指定していない) 有効なネットワークの接続をタイムアウトするまで待機してしまうためだ。

network-config 自体のリファレンスはこちら。
https://cloudinit.readthedocs.io/en/23.4.1/reference/network-config.html

cloud-init の user-data

こちらは書き換え箇所が多いので、何箇所かに分けて説明していく。

まず最初はユーザー名まわり。

--- user-data.org
+++ user-data
@@ -17,13 +17,17 @@
 # Some additional examples are provided in comments below the default
 # configuration.

+# Override the `default_user` configuration from `/etc/cloud/cloud.cfg`. The `user` dictionary keys supported for the default_user are the same as the `users` schema.
+user:
+  name: newusername
+
 # On first boot, set the (default) ubuntu user's password to "ubuntu" and
 # expire user passwords
 chpasswd:
   expire: true
   users:
-  - name: ubuntu
-    password: ubuntu
+  - name: newusername
+    password: newpassword
     type: text

 ## Set the system's hostname. Please note that, unless you have a local DNS

規定では、 cloud-init パッケージの /etc/cloud/cloud.cfg ファイルの定義によって、 "ubuntu" というユーザーが作成される。

しかし、既知のユーザー名をそのまま使うのはセキュリティ的にも若干不安があるし、作成後のユーザー名を書き換えるのは若干面倒なので、作成されるデフォルトのユーザー名自体を、他の名前 (上記例だと "newusername") に書き換えてしまおう。

また、 chpasswd による、初回アクセス時のパスワード変更対象とするユーザー名も、併せて変更しておく。

次にホスト名とキーボード周りの設定。

@@ -31,14 +35,14 @@
 ## setting the hostname here will not make the machine reachable by this name.
 ## You may also wish to install avahi-daemon (see the "packages:" key below)
 ## to make your machine reachable by the .local domain
-#hostname: ubuntu
+hostname: ubuntu-raspi5

 ## Set up the keyboard layout. See localectl(1), in particular the various
 ## list-x11-* sub-commands, to determine the available models, layouts,
 ## variants, and options
-#keyboard:
-#  model: pc105
-#  layout: gb
+keyboard:
+  model: pc105
+  layout: jp
 #  variant:
 #  options: ctrl:nocaps

ここはまぁ、見た通りなので追加での説明はいらないかな。

お次は SSH まわり。

@@ -53,6 +57,8 @@
 #ssh_import_id:
 #- lp:my_launchpad_username
 #- gh:my_github_username
+ssh_authorized_keys:
+- ssh-rsa AAAA<中略>== rsa-key-of-user1

 ## Add users and groups to the system, and import keys with the ssh-import-id
 ## utility

ssh_authorized_keys に直接指定するか、ssh_import_id: のところで自分の GitHub のユーザー名を指定してインポートすることにより、デフォルトのユーザー (上記例だと "newusername") に登録する公開鍵を指定する。

SSH に登録するパスワードログインは規定で禁止されているので、この設定をしておかないと SSH による遠隔からのアクセスができない。

タイムゾーンや起動後の処理まわり。

@@ -82,8 +88,13 @@
 #- python3-gpiozero
 #- [python3-serial, 3.5-1]

+# locale and timezone
+timezone: Asia/Tokyo
+
 ## Write arbitrary files to the file-system (including binaries!)
-#write_files:
+write_files:
+- path: /etc/cloud/cloud-init.disabled
+  defer: true
 #- path: /etc/default/console-setup
 #  content: |
 #    # Consult the console-setup(5) manual page.

とりあえずタイムゾーンは日本標準時にしておこう。

次に、 write_files: のほうだが、これは次回以降のブート時に cloud-init が余計に起動しないようにするための設定だ。

cloud-init の設定の大半は、初回ブート時にただ一度だけ実行されるのだが、 cloud-init サービス自体は基本的に毎回常に起動して、サービスとして常駐しっぱなしになっている。
Modules で、 Module frequency: per always となっているモジュールの実行などは、ブートする度に毎回実行される。
そうすると、場合によっては cloud-init の実行ログがログイン画面を覆ってしまうことが毎回の起動ごとに発生して鬱陶しい。
このため、 /etc/cloud/cloud-init.disabled という空ファイルを作成しておくことで、次回以降の起動時に cloud-init を無効にしている。

defer: true が指定されている部分についてだが、これは cloud-init の初期化処理が大きく分けて Network (cloud_init_modules), Config (cloud_config_modules), Final (cloud_final_modules) という 3ステージに分かれていることに関係する。
write_files: モジュールは Ubuntu の既定だと Network ステージに実行されてしまい、このタイミングで cloud-init.disabled ファイルが作成されてしまうと、 Config や Final ステージの処理が実行されなくなってしまう。
このため、 defer オプションを true にして Final ステージで cloud-init.disabled ファイルが作成されるよう調整しているのだ。

なお、どのモジュールがどのステージで実行されるかは、 /etc/cloud/cloud.cfg で定義されている。
（各ディストリビューション毎の cloud.cfg のテンプレートソースはこちら）

最後に、コマンドの実行。
以下の 192.168.0.2 の部分は、 ssh で RasPi に接続するゲスト PC の IPアドレスに書き換えてくれ。

@@ -106,7 +117,9 @@
 #  permissions: '0644'

 ## Run arbitrary commands at rc.local like time
-#runcmd:
+runcmd:
+# after wlan0 is connected, write the arp entry to target machine on background job
+- [ sh, -c, 'sleep 2; ping -c 4 192.168.0.2' ]
 #- [ ls, -l, / ]
 #- [ sh, -xc, "echo $(date) ': hello world!'" ]
 #- [ wget, "http://ubuntu.com", -O, /run/mydir/index.html ]

このコマンドは、仮に ssh ゲストの IP アドレスが 192.168.0.2 であると仮定して、そこへ向かって Ping を打っている。
なぜなら、ゲストPC から RaspPi の IP アドレスを ARP コマンドで確実に調べられるようにするためだ。

RasPi に繋げるディスプレイがないことを前提とすると、 SSH するために DHCP によって RasPi に割り当てられた IP アドレスをどうやって調べるのか、と言う問題に直面する。

RasPi の MAC アドレスの先頭 24bit は、 Raspberry 財団の所持する OUI から割り当てられるはずなので、以下のいずれかになるはずだ。

28:CD:C1
2C:CF:67
B8:27:EB
D8:3A:DD
DC:A6:32
E4:5F:01

通常、 RasPi がオンラインになったときに、 ARPリクエストがブロードキャストされるため、同一ネットワーク内の PC の ARP テーブルに RasPi のレコードが追加され、以下のような arp コマンドで対象の IP アドレスを調べることができるようになる。。。 多くの場合は。

while(1) { arp -a | ?{ $_ -match '\s(28-cd-c1|2c-cf-67|b8-27-eb|d8-3a-dd|dc-a6-32|e4-5f-01)' }; Start-Sleep -Seconds 1}

ところが、 RasPi が Wi-Fi で繋いでいる先が (単なるアクセスポイントではなく) ルーターだったりすると、 RasPi が同じサブネット内に ARPリクエストをブロードキャストしたのにも関わらず、ルーターが無駄に気を利かせて ARPリクエストを代替して投げてしまい、同じサブネットの別の端末の ARP テーブルには、 RasPi の MAC アドレスのレコードが記録されないことがある。

そこで、 RasPi 側から SSH のアクセス元となる PC を指定して ping を投げることで、その PC の ARP テーブルに確実に RasPi が載るようにしている。

ここまで書き換えたら、 SD カードを取り外して RasPi に挿し、いよいよ起動する。

cloud-init 周りの補足

system-boot パーティション内の中身について、もう少し細かい仕組み周りを深堀りして補足したい。
興味が無ければ、読み飛ばしてしまって次の章に進んでもらって問題ない。

system-boot パーティション直下にある README というファイルを開くと、このパーティションに存在するファイルの概要が簡単に書いてある。

==================
The Boot Partition
==================

This file belongs to the boot partition of the Ubuntu Server for Raspberry Pi.

...

このパーティションには、Raspberry Pi に於ける BIOS の代替となる config.txt といった H/W 設定用のファイルや、 cloud-init の構成ファイルなどが含まれていることがわかる。

このうち、cloud-init は Infrastructure as Code (IaC) の一種だ。
その名の通り、 AWS などのクラウド上の仮想マシンの初期設定を念頭においた仕組みだが、それに留まらず、一般的な Linux インスタンスの初期設定に活用される。
設定内容は、YAML形式の設定ファイルを使用して記述し、クラウドやディストリビューションの違いをある程度吸収して初期設定を行うことができる。
Ubuntu の OS のイメージ内には、事前に cloud-init のサービス（デーモン）が組み込まれており、OS の起動時に何らかの方法で指定された設定ファイルを読み取って、初回設定処理が実行される仕組みとなっている。

Raspberry Pi 用の Ubuntu Server イメージでは、この cloud-init 用の設定ファイルが上記の system-boot パーティションから取得される。
イメージ内のデフォルト値の定義と、system-boot パーティション内のユーザー定義が組み合わされ、初期設定が進められるワケだ。

たとえば、今回 microSD に書き込んだイメージをそのまま書き換えずに Ubuntu を起動すると、ユーザー認証が以下のように構成される。

ubuntu というユーザーID
ubuntu というパスワード
初回起動時にパスワードの変更を求める
SSH サーバーの起動

このうち、 (1), (4) は、OSに組み込まれた /etc/cloud/cloud.cfg の定義によるもの。
そして、 (2), (3) は system-boot パーティション内の user-data ファイル内の以下の部分の定義によるモノだ。

#cloud-config
chpasswd:
  expire: true
  users:
  - name: ubuntu
    password: ubuntu
    type: text

このデフォルトの構成だと流石にセキュリティ的にアレなので、書き換えを行っている… というのが、前項の設定の真相となる。

Raspberry Pi に割り当てられた IP アドレスを調べられるようにして起動

こんな感じでひととおりファイルを書き換えたら、いよいよ RasPi を起動する。

…と、その前に、 ssh でつなぐ予定のゲスト端末で、管理者権限で以下のコマンドを実行し、端末内の「arp テーブル」をリセットする。

arp -d *

その後、ようやくだが RasPi に microSD を挿して起動させよう。
初回ブート時の設定を適用しながら起動してくれる。

ssh でつなぐ予定のゲスト端末の PowerShell で、以下のような arp コマンドのループを実行し、ゲストPC から RasPi の IPアドレスを調べよう。
初回起動され安定しただろうところ（SDカードの I/O 性能によるが 1～5分？）で、 RasPi の IP アドレスがヒットしてくるようになるはずだ。

while(1) { arp -a | ?{ $_ -match '\s(28-cd-c1|2c-cf-67|b8-27-eb|d8-3a-dd|dc-a6-32|e4-5f-01)' }; Start-Sleep -Seconds 1}

公開鍵の登録が適切に行えれば、その IP アドレスに対し SSH できるはずだ。

初回アクセス時は、以下のようなパスワード変更を求められる。

WARNING: Your password has expired.
You must change your password now and login again!
Changing password for newusername.

古いパスワード ("newpassword") と変更後のパスワードを改めて入れる。

おわりに

一般的な1列端子の microSD で最速な UHS-I SDR104 のバスインターフェースに Raspberry Pi 5 が対応したことや、最近の安価な microSD の I/O 速度もだいぶ向上したのも相まって、 RasPi 4B が登場した頃と比べると、体感できる I/O 性能が大きく向上している。
おかげで、起動やパッケージのインストール、更新などが快適になった。

だいぶ高価になってしまった価格的な面からも、 Raspberry Pi の非Zero/Pico シリーズは「Linuxが動くマイコン」から「小型のLinuxマシン」という面がより強くなったと感じる。
（それはどうなんだという気もするけど。）

更に RasPi 5 では PCI Express (PCIe) にも対応しているため、 NVMe で繋いだ SSD からブートさせると、更に桁違いの高速化が臨める。

近いうちに、そちらも試してみようと思う。

…ただ、どうせ PCIe に対応するなら、microSD Express に対応してくれれば、 NVMe 用 HAT とか買い足さんで済むから良かったのにな～…と、思わんでもない。
しかし、2019年にSD7.1の規格として登場してから4年も経った2024年現在その製品が売られているとこを見たことないので、まぁ無理な相談か。

JavaScript で TOTP を計算する

2024-02-09T02:11:50+09:00

TOTP: Time-Based One-Time Password Algorithm とは、二要素認証でよく見る Google Authenticator 等で QRコードを読み込ませたりして、一定時間毎に替わる 6桁くらいの数字を入力するアレだ。

RFC 6238 に詳しい仕様が書かれている。
コイツを TOTP をブラウザ上で生成したい。

幸い近年の Web API には、バイナリ操作やクリプトまわりの機能が出揃っているので、わりかし簡単に実装できそうだ。
…とまぁ、そんな愚生が思いつくような話など既に、偉大なる先人たちによる多くのサンプルが残されている。

せっかく自分で実装するなら、最新の ES 仕様や Web API を活用して簡潔に、それでいて汎用的な仕様で書いてみよう。

実装

// @ts-check
const base32Alphabet = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ234567';
const base32AlphabetValuesMap = new Map([
    ...Array.from(base32Alphabet, (key, index) => /** @type {[string, number]} */([key, index])),
]);
/** @type { (strBase32: string) => Uint8Array } */
function decodeBase32(strBase32) {
    const strTrimmed = strBase32.replace(/=*$/, "");
    const result = new Uint8Array(strTrimmed.length * 5 >>> 3);
    let dataBuffer = 0;
    let dataBufferBitLength = 0;
    let byteOffset = 0;
    for (const encoding of strTrimmed) {
        const value = base32AlphabetValuesMap.get(encoding);
        if (typeof value === "undefined") throw new Error("Invalid base32 string");
        dataBuffer <<= 5;
        dataBuffer |= value;
        dataBufferBitLength += 5;
        if (dataBufferBitLength >= 8) {
            dataBufferBitLength -= 8;
            result[byteOffset++] = dataBuffer >>> dataBufferBitLength;
        }
    }
    if (dataBufferBitLength >= 5) throw new Error("Invalid base32 string");
    if ((dataBuffer << (4 - dataBufferBitLength) & 0xf) !== 0) throw new Error("Invalid base32 string");
    return result;
}

const hashAlgorithmNameMap = new Map([
    ["SHA1", "SHA-1"],
    ["SHA256", "SHA-256"],
    ["SHA512", "SHA-512"],
]);
/** @type { (secretUint8Array: Uint8Array, unixTimeMilliseconds: number, digits?: 6|7|8, period?: number, algorithm?: "SHA1"|"SHA256"|"SHA512") => Promise } */
async function generateTOTP(secretUint8Array, unixTimeMilliseconds, digits = 6, period = 30, algorithm = "SHA1") {
    // unixTimeMilliseconds to step binary
    const stepsBuffer = new ArrayBuffer(8);
    const dv = new DataView(stepsBuffer);
    dv.setBigUint64(0, BigInt(Math.floor(unixTimeMilliseconds / 1000 / period)));

    // calc Hash
    const hashAlgorithmName = hashAlgorithmNameMap.get(algorithm);
    if (!hashAlgorithmName) throw new Error(`invalid algorithm: ${algorithm}`);
    const cryptKey = await crypto.subtle.importKey("raw", secretUint8Array, { name: "HMAC", hash: hashAlgorithmName }, false, ["sign"]);
    const hash = new Uint8Array(await crypto.subtle.sign("HMAC", cryptKey, stepsBuffer));

    // Truncate
    const offset4Bit = hash.at(-1) & 0xf;
    const binary = (
        (hash[offset4Bit] & 0x7f) << 24 |
        hash[offset4Bit + 1] << 16 |
        hash[offset4Bit + 2] << 8 |
        hash[offset4Bit + 3]
    );

    // stringify
    const otp = binary % Math.pow(10, digits);
    return otp.toString().padStart(digits, "0");
}

実行例

// 実行例
await generateTOTP(decodeBase32('XXXXXXXXXXXXXXXX'), Date.now(), 8, 30, "SHA1");
// 実行例2 => "94287082"
await generateTOTP(decodeBase32('GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ'), Date.parse("1970-01-01T00:00:59Z"), 8)
// 実行例2.2 => "94287082"
await generateTOTP(decodeBase32('GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ'), Date.parse("1970-01-01T00:00:59Z"), 8, 30, "SHA1")
// 実行例3 => "32247374"
await generateTOTP(decodeBase32('GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ'), Date.parse("1970-01-01T00:00:59Z"), 8, 30, "SHA256")
// 実行例4 => "69342147"
await generateTOTP(decodeBase32('GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ'), Date.parse("1970-01-01T00:00:59Z"), 8, 30, "SHA512")

ハッシュアルゴリズムや、表示桁数、表示期間と言ったパラメータを変化させて、TOTP を出力できる。

応用例

例えば、前回の QRコードリーダーと組み合わせれば、 TOTP の管理を Web アプリ側で完結させるような実装もできる。

D&DしたQRコード画像をブラウザ上でデコードする | Aqua Ware つぶやきブログ

ちゃんと多要素認証の一要素として所有者認証を満たせるよう、実装にはかなり気をつける必要はあるだろうが。

参考

D&DしたQRコード画像をブラウザ上でデコードする

2024-02-08T01:37:05+09:00

ブラウザ上にドラッグ＆ドロップ (D&D) されたQRコードの画像を、読み込んでデコードするUIを作りたい。

Pure JavaScript で動作する、QR コードデコーダー（パーサー） cozmo/jsQR が有名なので、これを使ってみよう。

jsQR は、 png や jpg といった画像コンテナの解凍機能も、 HTML や DOM, Web 周りに特化した機能も一切無いため、読み込ませた画像は何らかの方法で Uint8ClampedArray な RAW 画像に変換して渡す必要がある。

ちょっと遠回りにはなるが、

D&D されたファイルの File API を読み取る
FileReader API を使って、ファイルを DataURI として読み込ませ、 img タグに表示させる
OffscreenCanvas と OffscreenCanvasRenderingContext2D を経由して ImageData を作成する
jsQR に処理を投げる

といった処理になるだろうか。

早速実装してみよう。

実装


    Drag and drop an image file here
    or

See the Pen decode D&Ded QR images by advanceboy (@advanceboy) on CodePen.

いったん img タグで画像を表示させるワンクッションを置いているおかげで、 png, jpg のみならず svg 等の画像もデコードできるようになっている。

Edge や Chrome ブラウザであれば、表示されている画像をそのまま D&D してきてのデコードもできるぞ。

jsQR の処理は、 JavaScript のスレッドで行われるので、処理が重くなるとブラウザが固まってしまう。
このため、理想的には Web Worker に処理を渡してしまうほうがよさそうではある。

ただ、1000x1000ピクセル程度の画像であれば、近年のデバイスなら一瞬でデコードできるので、実際のところはメインスレッド側で処理してしまって問題ないだろう。

ブラウザのタイトルや URL をコピーするブックマークレット【スマホ＆阿部寛対応】

2024-02-08T01:34:00+09:00

ブラウザで表示しているページのタイトルと URL を一括でコピーしたり、 markdown などのマークアップ言語でフォーマットされたものを、クリップボードにコピーしたくなることは無いだろうか？

意外にも、主要なブラウザには表示ページのタイトル名すら簡単にコピーする方法がない。

いくつかのブラウザ拡張機能（アドオン）には、上述の機能を提供しているものがいくつもある。
しかし、これだけのために拡張機能を入れるのもなんだかなと。
場合によっては、ポリシー等様々な理由で拡張機能を入れることを制限されている場合もあるだろうし。

そこで、表示中ページのタイトルと URL を任意の種類にフォーマットしてクリップボードへコピーしてくれるブックマークレットを作ってみた。

ブックマークレットとした事により、拡張機能の使えないスマートフォンの Chrome や Safari といった、とても不便なブラウザでも利用できる。

使い方

ブラウザのタイトルや URL をコピーするブックマークレット

上記のリンクを（Firefox なら右クリックから直接、 Edge や Chrome ならブックマークバーに D&D する等の方法で）ブックマークとして保存し、任意のページで呼び出すと、下記のようなダイアログが表示される。
お好きなボタンをクリックすれば、クリップボードにフォーマット済みのリンクが格納されるという算段だ。

暗転したところをクリックすれば、ダイアログはクローズされる。

最低限のコードにするため、 CSS は表示中のページのものを使っており、開いたページによってダイアログのデザインが変わるのは仕様となっている。

Firefox, Chrome, Edge いずれでも動作することは確認している。
Edge の場合ツールバーの「お気に入り☆」ボタンからではブックマークレットが動かないようなので、ブックマークバーから実行する必要があるようだ。（v121 現在）

もちろん、「阿部寛のホームページ」にも対応している。
このようにフレームセットを使っている場合は、最初のフレームにダイアログを表示させる形で、対応している。

カスタマイズ方法

既定で markdown, textile, LaTeX などいくつかのテンプレートを用意している。

もし追加したいものがあれば、後述のソースコードの Object.entries({の後ろに、 JSON キーにボタンのタイトルを、 JSON 値に変換のテンプレートを指定したものを追加し、各自 minify して使ってもらえれば OK だ。（ライセンスは CC-0）

ソースコード中に %5B, %5D などといった URL エンコードと解釈できてしまう部分があるため、ブックマークの編集画面の URL に直接貼り付ける場合は、 %255B, %255D などとエスケープしておこう。

なお、テンプレートの定義方法だが、 {{}} で括った部分に title (ページタイトル) もしくは url と、 0～8 の偶数個の / を記述し、置換対象を表す正規表現と、置換後の文字列を交互に記述する。

例えば、

String.raw`{{url/\[/%5B/\]/%5D/\|/%7C}}`

なら、以下と等価となる。

url.replace(RegExp(String.raw`\[`, "g"), "%5B")
  .replace(RegExp(String.raw`\]`, "g"), "%5D")
  .replace(RegExp(String.raw`\|`, "g"), "%7C");

雑な説明だがわかって。

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

2023-12-01T01:13:10+09:00

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

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

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

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

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

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

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

早速コード例

#Requires -Version 5
$addTypeOptions = if ($PSVersionTable.PSVersion -lt [version]'6.0') { @{ Language = 'CSharpVersion3' }; } else { @{}; };
$typeKeyboard = Add-Type -PassThru @addTypeOptions -TypeDefinition @'
using System;
using System.Runtime.InteropServices;
namespace D8B35E79FC964E69854B61A2C9FB3C08 {
    public static class Keyboard {
        [StructLayout(LayoutKind.Sequential)]
        struct MOUSEINPUT {
            public Int32 dx; public Int32 dy; public UInt32 mouseData; public UInt32 dwFlags; public UInt32 time; public IntPtr dwExtraInfo;
        }
        [StructLayout(LayoutKind.Sequential)]
        struct KEYBDINPUT {
            public UInt16 wVk; public UInt16 wScan; public UInt32 dwFlags; public UInt32 time; public IntPtr dwExtraInfo;
        }
        // Define the unused MOUSE structure due to the UNION_INPUT structure size determination.
        [StructLayout(LayoutKind.Explicit)]
        struct UNION_INPUT {
            [FieldOffset(0)] public MOUSEINPUT mi;
            [FieldOffset(0)] public KEYBDINPUT ki;
        }
        [StructLayout(LayoutKind.Sequential)]
        struct INPUT {
            public int type;
            public UNION_INPUT ui;
        }

        [DllImport("user32.dll", SetLastError = true)]
        extern static uint SendInput(uint nInputs, INPUT[] pInputs, int cbSize);

        public static void TypeKey(UInt16 vk) {
            var inputs = new INPUT[2];
            inputs[1].type = inputs[0].type = 1; // INPUT_KEYBOARD
            inputs[1].ui.ki.wVk = inputs[0].ui.ki.wVk = vk;
            inputs[0].ui.ki.dwFlags = 0x0000; // KEYEVENTF_KEYDOWN
            inputs[1].ui.ki.dwFlags = 0x0002; // KEYEVENTF_KEYUP
            var uSent = SendInput(2, inputs, Marshal.SizeOf(inputs[0]));
            if (uSent != 2) {
                throw new System.ComponentModel.Win32Exception(Marshal.GetLastWin32Error());
            }
        }
    }
}
'@ | Where-Object Name -EQ Keyboard;
$typeKeyboard::TypeKey(<# VK_VOLUME_MUTE #> 0xAD);

これを Push-MuteKey.ps1 等の名前で保存しておいて、

Start-Sleep -Seconds ([datetime]'11:01' - [datetime]::Now).TotalSeconds; .\Push-MuteKey.ps1;

などと指定して実行すれば、指定時間にミュートキーが押されてミュートが解除される。

Win32 API C# 経由で叩く場合、 32bit か 64bit どちらのプロセスでも問題なく動くよう気をつける必要があったり、 PowerShell のバージョン (5 か 7以降か) でコンパイル時の挙動が異なるので、そこらへんも気をつけて実装した。
うーん、 Win32 API 叩くために色々構造体を定義する必要もあって、結局仰々しいなぁ。。。

おわりに

シェルスクリプト＆PowerShell Advent Calendar 2023 は、執筆者募集中です！
こんな割としょうも無い内容で構わないので、久々になんか書いてみませんか！？

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

2023-11-03T22:58:23+09:00

電車でＧＯ！！専用ワンハンドルコントローラー - 瑞起 ZUIKI (以下、 ZUIKIコン) には、型番 : ZKNS-001 の通常版と、型番：‎ZKNS-002 の EXCLUSIVE EDITION の二種類ある。

ただどうも、それ以外に製造時期による違いもあるようだ。

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

きっかけ

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

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

…ところが買い増しした ZKNS-002 は、Switch 版や鉄道にっぽん! シリーズでは問題なく動くのに、上記ツールを使って JR東トレシムしようとすると以下のようなエラーが出て動かない。
```text/plain
Traceback (most recent call last):
File "main.py", line 24, in
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" と認識され、全くボタン配置で認識されている。
なんでボタン配置がズレるのか、訳がわからないよ。
[![](https://aquasoftware.net/blog/wp-content/uploads/2023/11/zuiki-dengo-controller-11-old-237x300.png)](https://aquasoftware.net/blog/wp-content/uploads/2023/11/zuiki-dengo-controller-11-old.png)[![](https://aquasoftware.net/blog/wp-content/uploads/2023/11/zuiki-dengo-controller-21-new-237x300.png)](https://aquasoftware.net/blog/wp-content/uploads/2023/11/zuiki-dengo-controller-21-new.png)

[上記 Steam コミュニティー](https://steamcommunity.com/app/2111630/discussions/0/3360272431836180307/) でも、同じような問題に遭遇している人が何人かいる。
しかも、 通常版 ZKNS-001 か EXCLUSIVE EDITION ZKNS-002 かを問わず発生するようだ。

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

## 意外なる原因



せっかく、エラーが出るデバイスと出ないデバイスが揃っているので、もう少し深く掘って調べてみる。

このツール [mipsparc/JRESim_Dengo](https://github.com/mipsparc/JRESim_Dengo/blob/v1.0/SwitchDenGo.py) のソースを取って Python のデバックをしてみたところ、やはりというか [pygame](https://www.pygame.org/news) というライブラリでコントローラーを操作するあたりでエラーがでている。
```text/plain
031:        # ○ボタン
032:        if self.joy.get_button(15):  # <- ここでエラー
033:            self.buttons.append("SW_CIRCLE")
034:        # HOMEボタン
035:        if self.joy.get_button(5):
036:            self.buttons.append("SW_HOME")

試しに、 pygame のジョイスティック実行例コード joystick.py を実行して、 pygame 側でどのように認識されているか確認してみる。

んんﾞっ!?
ZKNS-002 のほうは "One Handle MasCon for Nintendo Switch Exclusive Edition" として認識されるものの、
発売日に買った方の ZKNS-001 が "Nintendo Switch Pro Controller" と認識されて、ボタンの認識軸数が大きく変わっている。

pygame は、内部的に SDL2 (libsdl-org/SDL) というライブラリでジョイスティック操作をしている。
その SDL では、既知の様々なコントローラに様々な特殊対応が為されているので、そこらへんが影響していそうだ。

こういったものは、 USB の VID (ベンダーID) と PID (プロダクトID) で場合分けしているものと相場が決まっている。
ということで、デバイスマネージャーのプロパティ（ハードウェアID）から VID と PID を確認してみる。

発売日購入の通常版 ZKNS-001:
- HID\VID_0F0D&PID_00C1&REV_0106
最近買った EXCLUSIVE EDITION ZKNS-002:
- HID\VID_33DD&PID_0002&REV_0111

VID ちゃうやんけ。

https://www.usb.org/developers で USB ベンダーID を検索してみると…
0x0F0D (3853): HORI CO., LTD.
0x33DD (13277): ZUIKI Inc.

？？ HORI ？？

とりあえず、上記の VID と PID をもとに、 SDL2 (SDL 2.0.18) でどのように動作が定義されているか調べてみる。

SDL/src/joystick/controller_type.h at release-2.0.18 · libsdl-org/SDL

    { MAKE_CONTROLLER_ID( 0x0f0d, 0x00c1 ), k_eControllerType_SwitchInputOnlyController, NULL },  // HORIPAD for Nintendo Switch

ホリパッド for Nintendo Switch って書いてあるぞ。

更にここら辺 (SDL/src/joystick/SDL_joystick.c) の処理を経て、 VID: 0x0F0D & PID: 0x00C1 の組み合わせのものが "Nintendo Switch Pro Controller" と認識されているようだ。

なお、 VID: 0x33DD & PID: 0x0002 については、特に SDL 側での特殊処理は定義されていなそうだった。
このため、 USB H/W 側で定義されている "One Handle MasCon for Nintendo Switch Exclusive Edition" の名前がそのまま pygame での認識名として表示されていたのだろう。

うーん、製造当初は適当に（Switch に対応した）ホリパッドを偽装してたのを、後のロットではちゃんと VID や PID とって設定したってコトかしら…？
ライセンス品としてどうなんだソレ。

とりあえず、以下の2点が今回の問題が発生していることがわかった。

製造時期？によって、ホリパッドを偽装しているものとそうでないものがある
ホリパッドは SDL 側に特殊対応があり、偽装の有無でライブラリからとれるキー配置が異なっている

JRESim_Dengo の修正

原因がわかったところで、 JRESim_Dengo の方をどちらの ZUIKIコンにも対応させたい。

とはいえ、 VID や PID で動作し分けるにしても、私が持っている２台とは別の VID や PID を持つものもありそうだ。
（製造時期の違いからか同じ不具合に遭遇していた、通常版の ZKNS-001 とか）

SDL が動作を書き換えなければ、 USB から出ている信号は同じボタン配置で出ているっぽい為、コントローラーの軸数やボタン数で SDL 側での書き換えが行われたか判別すればよさそうだ。

--- ./SwitchDenGo_old.py    2022-10-03 18:55:53 +0900
+++ ./SwitchDenGo.py        2023-10-08 05:51:32 +0900
@@ -7,36 +7,64 @@

     def __init__(self):
         pygame.init()
         self.joy = pygame.joystick.Joystick(0)
+        self.ctrl_nums = (self.joy.get_numaxes(), self.joy.get_numballs(), self.joy.get_numbuttons(), self.joy.get_numhats())
+        if self.ctrl_nums not in [(6, 0, 16, 0), (4, 0, 14, 1)]:
+            raise Exception("サポートされていないコントローラです")
         self.joy.init()

     def loadStatus(self):
         self.brake_knotch = 0
         self.accel_knotch = 0
         self.buttons = []
         pygame.event.get()

-        # Xボタン
-        if self.joy.get_button(2):
-            self.buttons.append("SW_X")
-        # Yボタン
-        if self.joy.get_button(3):
-            self.buttons.append("SW_Y")
-        # Aボタン
-        if self.joy.get_button(0):
-            self.buttons.append("SW_A")
-        # Bボタン
-        if self.joy.get_button(1):
-            self.buttons.append("SW_B")
-        # ○ボタン
-        if self.joy.get_button(15):
-            self.buttons.append("SW_CIRCLE")
-        # HOMEボタン
-        if self.joy.get_button(5):
-            self.buttons.append("SW_HOME")
-
-        knotch_level = self.joy.get_axis(1)
+        # ロンチ版
+        if self.ctrl_nums == (6, 0, 16, 0):
+            # Xボタン
+            if self.joy.get_button(2):
+                self.buttons.append("SW_X")
+            # Yボタン
+            if self.joy.get_button(3):
+                self.buttons.append("SW_Y")
+            # Aボタン
+            if self.joy.get_button(0):
+                self.buttons.append("SW_A")
+            # Bボタン
+            if self.joy.get_button(1):
+                self.buttons.append("SW_B")
+            # ○ボタン
+            if self.joy.get_button(15):
+                self.buttons.append("SW_CIRCLE")
+            # HOMEボタン
+            if self.joy.get_button(5):
+                self.buttons.append("SW_HOME")
+
+            knotch_level = self.joy.get_axis(1)
+        elif self.ctrl_nums == (4, 0, 14, 1):
+            # Xボタン
+            if self.joy.get_button(3):
+                self.buttons.append("SW_X")
+            # Yボタン
+            if self.joy.get_button(0):
+                self.buttons.append("SW_Y")
+            # Aボタン
+            if self.joy.get_button(2):
+                self.buttons.append("SW_A")
+            # Bボタン
+            if self.joy.get_button(1):
+                self.buttons.append("SW_B")
+            # ○ボタン
+            if self.joy.get_button(13):
+                self.buttons.append("SW_CIRCLE")
+            # HOMEボタン
+            if self.joy.get_button(12):
+                self.buttons.append("SW_HOME")
+
+            knotch_level = self.joy.get_axis(1)
+        else:
+            raise Exception("サポートされていないコントローラです")

         if knotch_level > 0.95:
             self.accel_knotch = 5
         elif knotch_level > 0.75:

こんな感じの修正を入れてビルドしたものを以下のリリースで展開した。

Release JRESim_Dengo v1.0p1 · advanceboy/JRESim_Dengo

もし、最近 ZUIKIコンを JREトレシムで使おうと思って困っている人がいればどうぞ。

元の作者の方にもプルリク投げとくか。

補足

実装のために調査した、各環境・デバイス毎の、キー割り当ては以下の通りだった。

DirectInput からの取得 (ロンチ版, 最近の Exclusive Edition 共通):

```text/plain
index 1軸: マスコン
Button 1: Y
Button 2: B
Button 3: A
Button 4: X
Button 5: L
Button 6: R
Button 7: ZL, EB
Button 8: ZR
Button 9: -
Button 10: +
Button 11: N/A
Button 12: N/A
Button 13: HOME
Button 14: Capture
PoVハット 1: 方向キー


### pygame 経由の、ロンチ版

```text/plain
index 1軸: マスコン
index 4軸: ZL
index 5軸: ZR
Button 0: A
Button 1: B
Button 2: X
Button 3: Y
Button 4: -
Button 5: Home
Button 6: +
Button 7: N/A
Button 8: N/A
Button 9: L
Button 10: R
Button 11: Up
Button 12: Left
Button 13: Down
Button 14: Right
Button 15: Capture

# ハードウェアID: 'HID\VID_0F0D&PID_00C1&REV_0106'
joy = pygame.joystick.Joystick(0)
joy.get_guid()
# -> '030000000d0f0000c100000006016800'
joy.get_name()
# -> 'Nintendo Switch Pro Controller'
joy.get_numaxes()
# -> 6
joy.get_numballs()
# -> 0
joy.get_numbuttons()
# -> 16
joy.get_numhats()
# -> 0

pygame 経由の、 Exclusive Edition

```text/plain
index 1軸: マスコン
Button 0: Y
Button 1: B
Button 2: A
Button 3: X
Button 4: L
Button 5: R
Button 6: ZL
Button 7: ZR
Button 8: -
Button 9: +
Button 10: N/A
Button 11: N/A
Button 12: Home
Button 13: Capture
PoVハット 1: 方向キー

[![](https://aquasoftware.net/blog/wp-content/uploads/2023/11/zuiki-dengo-controller-22-new.png)](https://aquasoftware.net/blog/wp-content/uploads/2023/11/zuiki-dengo-controller-22-new.png)

```python
# ハードウェアID: 'HID\VID_33DD&PID_0002&REV_0111' 
joy = pygame.joystick.Joystick(0)
joy.get_guid()
# -> '03000000dd3300000200000000000000'
joy.get_name()
# -> 'One Handle MasCon for Nintendo Switch Exclusive Edition'
joy.get_numaxes()
# -> 4
joy.get_numballs()
# -> 0
joy.get_numbuttons()
# -> 14
joy.get_numhats()
# -> 1

PC Manager をオフラインやプロキシ環境下でインストールする

2023-11-01T01:41:31+09:00

システム最適化ソフト「Microsoft PC Manager」が、 v3.1.3 で日本語に対応したらしい。
→ Microsoft純正のシステム最適化アプリが日本語に対応、「PC Manager」v3.1 - 窓の杜

元々中国向けに提供されていたものが、英語、それ以外の言語と順次展開が拡大されおり、今回めでたく日本語対応したようだ。
…あれ？こないだまで最新ベータ版は v3.2 だったような…？
まぁいいか。

Windows 11 だと何かとメモリを食いつぶされて、 16～32GB 程度のメモリでは VM や WSL の起動に失敗することが多々あるので、 Windows 98 や Me の時代を思い出すようなメモリクリーンアップ機能は、今の時代でも重宝される。

さて、この Microsoft PC Manager だが Microsoft の公式ページからインストーラをダウンロードして実行しても、オフライン環境やプロキシ環境下だと「インストールファイルをダウンロードできませんでした。後でもう一度お試しください。」等と表示されて、インストールに失敗する。

インストーラ (MSPCManagerSetup.exe) が実行時に実プログラムをダウンロードする必要があるからだ。

どこかにオフライン版のインストーラはないものか…
と調べていたら、 FANDOM の Wiki にオフラインインストーラのリンクの作り方が書いてあった。

Microsoft PC Manager | Microsoft Wiki | Fandom
aka.ms/PCManager[ChannelNo.]

2023年11月現在、前述の公式サイトからオンラインインストーラをダウンロードしようとすると、以下のリンク先 (に認証用のシグネチャのパラメータが付いたもの) へリダイレクトされてダウンロードされる。
https://pcmdistributestorage.blob.core.windows.net/mvp/500000/56784/MSPCManagerSetup.exe

このことから、最新版系統は Channel 500000 のようだ。

つまり、以下のリンク先からダウンロードすれば、 v3.1 系統のオフライン版インストーラが手に入るようだ。

https://aka.ms/PCManagerOFL500000

しっかりマイクロソフトによるデジタル署名がついたインストーラが手に入るので、ウイルスなどが仕込まれたファイルであるリスクは低そうだ。

個人用 Clipchamp から組織ユーザーへプロジェクトを無理やり移行する

2023-10-29T13:16:05+09:00

この記事では、個人アカウント用 Clipchamp から組織（法人）ユーザーの Clipchamp へプロジェクトを移行する方法、およびその応用で、個人用から別の個人用ユーザーに Clipchamp プロジェクトを移行（コピー）する方法を説明する。

去る7月31日に、動画編集アプリ Clipchamp が組織アカウントに対応し、ビジネス向け Microsoft 365 に加わることが発表された。
→ 動画編集アプリ「Clipchamp」、ビジネス向け「Microsoft 365」にも導入開始 - 窓の杜

これにより、 Microsoft での買収以降どのプランが商用利用可能なのか曖昧だった Clipchamp が、組織アカウント上で安心して商用利用できる事になる。
北米時間の 2023年10月15日に Clipchamp が商用ユーザーで利用可能になったことが発表され、 Microsoft 365 の対象プランのライセンスを持つ全てのユーザーに対し Clipchamp が一般公開された。
→ 動画編集アプリ「Clipchamp」が法人「Microsoft 365」に～上位版・単体プランも提供へ - 窓の杜

さて、 Clipchamp が組織アカウントに対応したことで、旧来の個人アカウント用 Clipchamp アカウントで作成していたプロジェクトを、組織アカウントに移行したくなる場合もあるだろう。

しかし FAQ などをみると、

職場アカウントで Microsoft Clipchamp にアクセスする方法 - Microsoft サポート

個人アカウント用に Clipchamp で作成されたプロジェクトを作業バージョンに移動できますか?

いいえ。

無慈悲。

仕事向けの Clipchamp - clipchamp.com

個人用アカウントの Clipchamp で作成したプロジェクトを職場アカウントに移行できますか?

現時点では、個人用アカウントで作成したプロジェクトを職場アカウントに移行することはできません。

こちらは、もうちょいマイルドだ。

将来的にやる気があるのかはわからんが、少なくとも現時点では、個人アカウントのデータの組織アカウントへの移行は、公式的にはできないらしい。

ところで、実際に組織アカウントで Clipchamp を使ってみると、プロジェクトファイルが OneDrive for Bussiness の <ルート>\動画\Clipchamp\<プロジェクト名>\ あたりの、 *.clipchamp という、 JSON が実体のファイルとして保存されていることに気づく。

個人用 Clipchamp の動作を思い出してみると、画像や音声などのアセットはローカルにキャッシュや保存されているものが参照されているだけで、別 PC でプロジェクトを開こうとすると、改めてアセットファイルを紐づける必要があった。

このため、個人用 Clipchamp のプロジェクトも、この JSON ファイル程度の情報しかサーバーで管理されていないのではと推測できる。

つまり、何らかの方法でこの JSON ファイル相当の情報を個人用 Clipchamp から抜き出せれば、組織アカウントに移行できるかもしれない。

試行錯誤してみたところ、どうやら上手くいったようなので、その方法を紹介しよう。

対象者:
- 最低限の JSON の読み書きができる
- ブラウザの開発者ツールを多少触ったことがある
対象環境:
- Microsoft Store Clipchamp アプリ又は Chromium 系ブラウザ
  - 以降の説明は Clipchamp アプリ又は Edge を例に説明
- 何らかのテキストエディタ
  - vscode あたりがオススメ

ちなみに Clipchamp は Firefox 非対応だ。
Web 標準に仇なすクソがよ。

準備

まず、組織アカウントで一度は何らかの Clipchamp のプロジェクトを作成しておく。（但しそのプロジェクトは以降の手順では使わない）

個人アカウントからプロジェクトデータの取り出し

移行元の個人アカウントを使い、 Clipchamp アプリか Edge で、 Clipchamp サービスを開く。

ウィンドウ内の何らかのコンテンツにフォーカスをあわせた状態で、 Ctrl+Shift+I または F12 キーを押し、開発者ツールを起動する。

Clipchamp 側ではエクスポートしたいプロジェクトを開き、開発者ツール側でネットワークタブを開く。

Ctrl+F でネットワークタブの検索窓を開いて、 URL に /projects/ が含まれているものを探す。
例えば下のスクショの場合、検索結果の 2つ目, 3つ目のレコードは /projects/ が含まれているのが URL ではないので該当しない。
該当するものが複数ある場合は、ヘッダーの要求方法 (METHOD) が GET となっているモノを探す。

URL 一覧からアクティブになっているレコードを右クリックし、「編集して再送信する」をクリックする。

すると、開発者ツールウィンドウの下半分にネットワークコンソールが開くので、 Send ボタンをクリックする。

すると、更にその下に再送信結果が表示されるので、 Download をクリック。

既定のダウンロード先に .json ファイルがダウンロードされているはずなので、任意のテキストエディタで開く。 (vscode がオススメ)

JSON の projectState プロパティの中身だけを繰り出して、 .clipchamp の拡張子で保存する。
具体的には、 vscode の場合 Shift+Alt+F で JSON を整形し、 { "projectState": { の部分まで削除したのち Ctrl+Shift+\ で次の対応する括弧に移動して、その閉じ括弧 } より後ろを削除するとよいだろう。

以上で、移行に用いる .clipchamp ファイルのエクスポートは完了だ。

組織アカウントへの取り込み

OneDrive for Bussiness の <ルート>\動画\Clipchamp\ あたりにプロジェクトフォルダを作成して、そこに .clipchamp ファイルを移動する。

OneDrive for Business の WebUI 上から上記ファイルを開いて、 Clipchamp のウェブエディタを起動する。

もし、「予期しないエラーが見つかりました ... Error: Project schema is an unsupported version」というエラーが発生した場合、
上記 .clipchamp ファイルの JSON の $.schemaVersion のところを、 1.3.3 くらいに書き換えて、改めて開く。
（組織アカウントで予め作製しておいた Clipchamp のプロジェクトの .clipchamp を開いてみて、それと同じ schemaVersion の値にしておくのが良いだろう。）

Clipchamp の編集画面が読み込まれたら、不足しているアセットを「アセットを探す」をクリックしてたダイアログ上で探して取り込む。

アセットが一箇所にまとまっているなら、「フォルダーを選択」でアセットが入っているフォルダを選択すれば、そのフォルダに含まれているファイルが再帰的に検索され、プロジェクトで使われているアセットが自動的に読み込まれるはずだ。

読み込めないアセットが全て紐付けられたか、あるいはどうして見つからないファイルについてはタイムラインから削除すれば、「アセットを探す」の表示が消え動画のプレビューができるようになるはずだ。

なお、 2023年10月現在、組織アカウントの Clipchamp では内蔵ストックアセットが使えないようだ。これも 10月以降順次ロールアウトされるらしいので、移行元プロジェクトでストックアセットを使っている場合、そのあとに移行した方が良さそうだ。

キャッシュからアセットの取り出し

更に突っ込んで、一部ファイルがローカルのどこにあるかわからなくなっている場合、キャッシュなどからリソースをファイルとして取り出せる場合もある。

但しこの方法を使うと、移行元のプランで使える一部のストックアセットなども取り出せてしまうが、それはライセンス的に微妙なので要注意。

読み込めていないアセットの ID を、プロジェクトの JSON から表示名をキーにして探す。

移行元の Clipchamp のプロジェクトを開発者ツールを開いた状態で開き、先ほどのプロジェクトデータの取り出しと同じ要領で、今度はネットワークタブの検索窓を開いて、 URL に /local-cache/{id} が含まれている要求方法 (METHOD) が GET となっているレコードを探し、同じくアクティブレコードを右クリックで「編集して再送信する」をクリックする。

開発者ツールウィンドウの下半分にネットワークコンソールが開かれるが、 まずは Headers を開き Range のチェックを外してから、 Send ボタンをクリックする。そして、再送信結果が表示されたら Download をクリック。

保存される拡張子は必ずしも正しく設定されないので、動画なら .mp4 や .webm, .gif など、画像なら .png, .jpg, .svg などにファイル名を書き換えよう。

このファイルを、移行先の「アセットを探す」で指定すれば、移行先に取り込めるはずだ。

別の個人アカウントへプロジェクトの取り込み

組織アカウントと異なり、個人アカウントでは .clipchamp ファイルが OneDrive 等の見える所に存在しないので、別の方法で取り込む必要がある。
Clipchamp は、かなり綺麗な URI 設計となっているようで、取り出し方法を応用すれば、個人アカウントを跨いでプロジェクトの移行もできそうだ。

移行先のアカウントで Clipchamp を開き、適当な名前で新しいプロジェクトを作成したのち、開発者ツールを開く。タイトル名を変えるなど何らかの変更を加え、いったん編集した場所からフォーカスを外す。

この状態で開発者ツールのネットワークタブの検索窓を開いて、 URL に /projects/ が含まれているもののうち、今度はヘッダーの要求方法 (METHOD) が PUT となっているモノを探す。

ペイロードタブを開いて、 "id" プロパティの値をいったんどこかにコピペしておこう。
ちなみにこの値は、 /projects/ の URL に含まれている ID と同じ値のはずだ。

今度は、インポート対象となるエクスポート済みの .clipchamp ファイルを任意のテキストエディタで開く。そして、ルート直下の "id" プロパティの値を、前述のコピペしといた "id" プロパティの値に書き換える。
"id" プロパティ自体は JSON の中にいくつもあるが、書き換えるのはルート直下のひとつだけにすることに要注意だ。

更に、 .clipchamp ファイルの中身全体を { "projectState": と } でくくって、 .json ファイルとして保存する。

移行先の Clipchamp の開発者ツールに戻り、先ほどの PUT のレコードが選択されている状態で、アクティブレコードを右クリックして「編集して再送信する」をクリックする。開発者ツールウィンドウの下半分に開いたネットワークコンソールの、今度は Body を開き、そこに、先ほどの書き換えた .json ファイルの中身をペーストして、 Send ボタンをクリックする。

リクエストが成功して何らかのレスポンスが返ってきたら、いったん Clipchamp アプリ（またはブラウザタブ）をすぐに閉じる。

その後、改めて Clipchamp アプリまたは、ブラウザの新しいタブで Clipchamp を開き、プロジェクト一覧を見ると、先ほど作成した新しいプロジェクトが移行したプロジェクトに置き換わっているはずだ。
もしそのプロジェクトを開いた際にエラーが出る場合は、 PUT する JSON の書き換えや指定方法が誤っているので、一旦プロジェクトを削除後、もう一度最初の手順からやり直そう。

おわりに

だいぶ無理矢理な方法だが、上記のような方法で個人用アカウント同士や、個人アカウントと組織アカウントの間でプロジェクトを移行できた。
ただ、 Clipchamp の仕様変更で同じ方法が使えなくなくなっている可能性がある点にはご了承願いたい。

Pester v3 & v5 互換のテストコードを書く (PowerShell)

2023-10-03T09:07:43+09:00

PowerShell のテストフレームワークである Pester は、単体テストや自動テストなどを手軽に書けるので、スクリプトやコードの品質を保つのに役立つ。

しかし、 Pester は v3 から v5 にかけてかなり大きな破壊的変更がある。

この記事では、 Pester v3 と v5 の両方に互換があるテストコードの書き方について紹介したい。

何故 v3 と v5 で互換を取りたいか

Windows 10 や 11 では、デフォルトで Windows PowerShell 5.1 がインストールされており、更にそこには Pester モジュールの v3.4.0 もインストールされている。
Windows 上の PowerShell モジュールディレクトリはシステム全体で共通のため、たとえ別途 PowerShell 7.3 LTS などをインストールしていたとしても、既定では Pester v3.4.0 が読み込まれるわけだ。

一方、 Linux 等のそれ以外のシステムで PowerShell をインストールした場合は、 Pester が自動的にインストールされることはないため、 Pester モジュールを追加でインストールすることになる。
このとき、普通は最新版の v5 が入るだろう。

Windows PowerShell の Pester を v5 に更新させたり、 Linux 等のシステムでインストールする Pester モジュールを v3.4 に抑えさせたりできればよいが、まぁなかなかそうも行かない時がある。

そんなのっぴきならん状況だと、多少苦労してでもテストコード側を Pester v3 と v5 どちらにも互換を取ってしまったほうが手っ取り早いかも…なんて状況が地球上の何処かには存在するかもしれない。

テストコードの書き方

v3 と v4 の間の破壊的変更で一番デカいのは、 Should 構文の変更で互換切りを行っている部分だ。

https://pester.dev/docs/migrations/breaking-changes-in-v5

Legacy syntax Should Be (without -) is removed, see Migrating from Pester v3 to v4

構文自体の変更自体は v4 で行われたものだが、このときは以前の構文も互換性が残されていた。
ところが、 v5 で早速この互換が切られてしまっている。

コレのせいで、ほぼすべてのテストコードが、そのままでは v3 と v5 の間で互換を取ることが不可能になっている。
何考えてんだ……

位置指定パラメータからスイッチパラメータに変わっているため、このどちらにも渡せるようにするためには Splatting 表記に頼ることにする。
v3 で使える Should のオペレーターそれぞれについて、 v3 以下なら位置指定パラメータで渡す方法で、 v4 以上ならスイッチパラメータで渡す方法で、それぞれ $BeForCompat のような形で $*ForCompat, $Not*ForCompat の形式の変数をテストコード開始時に定義する。
そして、その変数を Should で @BeForCompat のように Splatting 表記にて使用する。

また、 v4 では Contain/ContainExactly オペレーターが -FileContentMatch/-FileContentMatchExactly にリネームされていたり、
v5 では *.Tests.ps1 ファイル先頭や、 Context, Describe 直下にセットアップコードが記載できなくなっているので、全て BeforeAll ブロック内に記述する必要がある。

これらのマイグレーションをまとめると、 v3/v5 互換の Pester テストコードは以下のようになる。
(v3-to-v5-Migrations.Tests.ps1 というファイル名で保存されているものとする)

#Requires -Version 5
#Requires -Modules @{ ModuleName="Pester"; ModuleVersion="3.0" }
trap { break; }

$GlobalBeforeAll = {
    # Write here the code that needs to be executed at the start of the test
    $shouldParams = 'Be','BeExactly','BeGreaterThan','BeLessThan','BeLike','BeLikeExactly','BeNullOrEmpty','BeOfType','Exist','Match','MatchExactly','Throw';
    if ((Get-Module Pester).Version -ge [version]'4.0') {
        $shouldParams | ForEach-Object {
            Set-Variable "${_}ForCompat" @{ $_ = $true };
            Set-Variable "Not${_}ForCompat" @{ Not = $true; $_ = $true };
        };
        $FileContentMatchForCompat = @{ FileContentMatch = $true };
        $FileContentMatchExactlyForCompat = @{ FileContentMatchExactly = $true };
        $NotFileContentMatchForCompat = @{ Not = $true; FileContentMatch = $true };
        $NotFileContentMatchExactlyForCompat = @{ Not = $true; FileContentMatchExactly = $true };
    } else {
        $shouldParams | ForEach-Object {
            Set-Variable "${_}ForCompat" @($_);
            Set-Variable "Not${_}ForCompat" @('Not', $_);
        };
        $FileContentMatchForCompat = @('Contain');
        $FileContentMatchExactlyForCompat = @('ContainExactly');
        $NotFileContentMatchForCompat = @('Not','Contain');
        $NotFileContentMatchExactlyForCompat = @('Not','ContainExactly');
    }
}
if ((Get-Module Pester).Version -ge [version]'5.0') {
    BeforeAll $GlobalBeforeAll;
} else {
    . $GlobalBeforeAll;
}

Describe 'Pester v3, v5 compatibility notation test' {
    BeforeAll {
        # DON'T use $MyInvocation.MyCommand.Path
        $filePath = '.\v3-to-v5-Migrations.Tests.ps1';
    }

    It "Pattern: (, )" -TestCases @(
        @{A=1; B=2};
        @{A=3; B=4};
    ) {
        param ($A, $B);
        ($A / $A) | Should @BeForCompat 1;
        ($B * $A) | Should @NotBeForCompat 0;
        $filePath | Should @FileContentMatchExactlyForCompat 'BeforeAll';
    }
}

PS > # Pester 3.4.0 の場合 PS > Get-Module Pester ModuleType Version PreRelease Name ---------- ------- ---------- ---- Script 3.4.0 Pester PS > Invoke-Pester Describing Pester v3, v5 compatibility notation test [+] Pattern: (1, 2) 74ms [+] Pattern: (3, 4) 5ms Tests completed in 53ms Passed: 2 Failed: 0 Skipped: 0 Pending: 0 Inconclusive: 0 PS >

PS > # Pester 5.5.0 の場合 PS /> Get-Module Pester ModuleType Version PreRelease Name ---------- ------- ---------- ---- Script 5.5.0 Pester PS > Invoke-Pester Starting discovery in 1 files. Discovery found 2 tests in 21ms. Running tests. [+] .../v3-to-v5-Migrations.Tests.ps1 115ms (82ms|13ms) Tests completed in 117ms Tests Passed: 2, Failed: 0, Skipped: 0 NotRun: 0 PS >

うーん、面倒くさいね。
Tips

こんなアホなことはせずに、Pester v3 なら v3 のコードで、 v5 なら v5 のコードで記述する場合、せめてテストコードの先頭で #Requires 構文を書いて、どのバージョンの Pester をターゲットにしているかしっかり明示しよう。

# Pester v3, v4 をターゲットにする場合 #Requires -Modules @{ ModuleName="Pester"; ModuleVersion="3.0"; MaximumVersion="4.99" } (Get-Module Pester).Version; Describe 'desc' { It 'it' { 1 | Should Be 1; }; };

# Pester v5 以降をターゲットにする場合 #Requires -Modules @{ ModuleName="Pester"; ModuleVersion="5.0" } BeforeAll { (Get-Module Pester).Version; }; Describe 'desc' { It 'it' { 1 | Should -Be 1; }; };

本来 #Requires 構文には、必要なモジュールが現在のセッションにない場合自動でインポートする機能があり、例えば複数のバージョンのモジュールがサイドバイサイドでインストールされていた場合だと、条件に一致するバージョンのものがインポートされる便利な機能がある。
しかし Pester の場合は、必ずしも良い感じには機能してくれるとは限らない。

テストコードが読み込まれる前 Invoke-Pester した時点で Pester モジュールのインポートが走ってしまうことや、複数のバージョンのモジュールがインポートされた状態になると、いずれか一つのモジュールが条件を満たせば #Requires の検証をパスしてしまうのに、インポートされたもののうち最も古いバージョンのモジュールで実行されてしまうような挙動をとるためだ。

それでも、 Pester モジュールがひとつしかインストールされていないような多くの状況では、バージョンを明示しておくことでエラー原因がわかりやすくはなるはずだ。

NEC IXシリーズルーターでポートVLANとタグVLANをVLANスイッチ的に併用する

2023-09-23T02:32:08+09:00

この記事では、 GE0, GE1 の 2つの "デバイス" を持つ NEC の IX2105 ルーターを例に、1カ所のスイッチングハブ用のデバイスの中でポートVLAN とタグVLAN を併用し、スイッチングハブのトランクポートやアクセスポートのように使う方法について説明する。

はじめに

国内の中規模オフィス向けのルーターとして、 Yamaha や Cisco がよく知られているが、 NEC も UNIVERGE IXシリーズを提供している。

Yamaha の RTXシリーズと価格帯が近いものの、 NEC の IXシリーズには、 Yamaha と比べてもわりと柔軟な構成を行える利点がある。

一方で Yamaha と比べた場合、 NEC の IXシリーズの設定方法を調べるのは少し…いや、だいぶ難しい。
書籍や Web 記事、公式マニュアルなど、ドキュメントや設定例の全てに於いて、 Yamaha と比べて著しく情報が少ないためだ。

そんな IXシリーズを使って、ポートVLAN とタグVLAN を併用する方法について紹介しよう。
（この併用も、Yamaha の RTX で同一ポート内で実現するのは難しい機能のひとつだ）

なお、同じ UNIVERGE でも LTE や Wi-Fi などのワイヤレス機能を持った WAシリーズでは、 VLAN 周りのコマンド体系が異なるため、このページの方法は使えない。

設定例として挙げている IX2105 は 2019年9月30日をもって販売を終了しているが、マイナーバージョンこそ Ver.10.2 までに留まるものの不具合修正は続いている。
（例えば後継の IX2106 だと 10.2系は Ver.10.2.26 までで終了し、最新版は Ver.10.8.21 となっている）
中古ならヤフオク等で二束三文で手に入るし、最新 FW (ソフトウェア) も NEC に "UNIVERGE IXシリーズソフトウェアダウンロードサイトへの接続申請書" を出せば手に入るので、練習機としてはもってこいだ。

ゴール

以下のような構成を行う。

既定ではスイッチングハブとなっている、 GE1 デバイスの4つの物理ポートを、以下の3つに分割する

タグ付き通信を行う（即ちトランクポートとなる）1番ポート

但し、管理VLAN 的に使うため、 untag のフレームも受け付ける

VLAN100 の通信を untag で行う（即ちアクセスポートとなる）2番ポート

VLAN200 の通信を untag で行う（即ちアクセスポートとなる）3, 4番ポート

各 VLAN それぞれで DHCP サーバによる異なるセグメントの IP アドレスの割り当てを行う

GE0 デバイスでは NAT (NAPT) を行い、 GE1 デバイスの各セグメントからのルーティングも受け付ける

先に最終的な構成を載せておくと、以下のようになる。

ip ufs-cache enable ip dhcp enable ip access-list web-http-acl permit ip src any dest 192.168.99.1/32 ! ! ! ! ! ブリッジの有効化 bridge irb enable ! ! ! ! GE0 から DNS サーバーを自動取得し DNSプロキシーを実行 proxy-dns ip enable proxy-dns interface GigaEthernet0.0 priority 254 ! Webコンソールを管理ポートの 192.168.99.1 として開始 http-server ip access-list web-http-acl http-server ip enable ! ! ! ! 各サブネットごとに、自身をDNSサーバーと通知するDHCPプロファイルを作成 ip dhcp profile dhcp-profile-99 dns-server 192.168.99.1 ! ip dhcp profile dhcp-profile-120 dns-server 192.168.120.1 ! ip dhcp profile dhcp-profile-130 dns-server 192.168.130.1 ! device GigaEthernet0 ! GE1 ポートにポートベース VLAN グループを設定 device GigaEthernet1 vlan-group 2 port 2 vlan-group 3 port 3 4 ! GE0 は WAN 側として、 IPアドレスを DHCP から自動取得し、 NAPT を有効化 interface GigaEthernet0.0 description WAN1 ip address dhcp receive-default ip napt enable ip napt hairpinning no shutdown ! GE0 のグループ N/A (ポート1番) のアドレスと DHCP の設定 interface GigaEthernet1.0 description LAN1 ip address 192.168.99.1/24 ip dhcp binding dhcp-profile-99 no shutdown ! GE0 のグループ N/A (ポート1番) の VLANID 222 の VLAN タグ付きの設定 (BVI20とブリッジ) interface GigaEthernet1.2 description VLAN222 encapsulation dot1q 222 tpid 8100 auto-connect no ip address bridge-group 200 no shutdown ! GE0 のグループ N/A (ポート1番) の VLANID 333 の VLAN タグ付きの設定 (BVI30とブリッジ) interface GigaEthernet1.3 description VLAN333 encapsulation dot1q 333 tpid 8100 auto-connect no ip address bridge-group 300 no shutdown ! GE0 のグループ 2 (ポート2番) の untag の設定 (BVI20とブリッジ) interface GigaEthernet1:2.0 no ip address bridge-group 200 no shutdown ! GE0 のグループ 3 (ポート3番&4番) の untag の設定 (BVI30とブリッジ) interface GigaEthernet1:3.0 no ip address bridge-group 300 no shutdown ! VLANID 222 向けのブリッジインタフェースのアドレスと DHCP の設定 interface BVI20 ip address 192.168.120.1/24 ip dhcp binding dhcp-profile-120 bridge-group 200 no shutdown ! VLANID 333 向けのブリッジインタフェースのアドレスと DHCP の設定 interface BVI30 ip address 192.168.130.1/24 ip dhcp binding dhcp-profile-130 bridge-group 300 no shutdown ! interface Loopback0.0 no ip address ! interface Null0.0 no ip address !

メモ:

なお、このページのコンフィグ例では、 IX2105 や IX2106, IX2107 のように GigaEthernet1 デバイスがスイッチングハブであることを前提としている。
IX2215 や IX2235 のように GigaEthernet2 デバイスなどがスイッチングハブとなっている場合、適宜読み替えて設定して欲しい。

前提知識

ひとつひとつ、細かく解説していこう。

まず前提として理解しておかなくてはならないのは、 IXシリーズの設定の考え方に於いて タグVLAN とポートVLAN は全く異なる機能 であり、独立した設定となっている、という点だ。

タグVLAN

タグVLAN は、

ある GigaEthernet1.0 といった "基本インタフェース" に対して、 GigaEthernet1.2 のような "サブインタフェース" を作成し… ¹

各サブインタフェースに VLAN ID を割り当てると…

基本インタフェース側では IEEE 802.1Q VLANタギングでカプセル化されたフレームが流れる

という仕組みだ。

すなわち、基本インタフェース GigaEthernet1.0 内にて、各サブインタフェース GigaEthernet1.1, GigaEthernet1.2 が、 VLANタギングによってトンネリングされていると見做せる。

基本インタフェースも各サブインタフェースも、それぞれに IP アドレスを割り当てれば、各々がルーティングの対象となる。

メモ:

IXルーター上でトンネリングを行う仕組みとしては、似たようなもので他にも Tunnelインタフェースが存在する。

Tunnelインタフェースでは、カプセル化後が (L3 の) IP パケットとなるようなモノを対象とするため、カプセル化後のパケットはルーティングされる。

一方、サブインタフェースでは、 VLANタギングや PPPoE といった、カプセル化後が (L2 の) Ethernet フレームとなるようなモノを対象としているため、カプセル化後のフレームは親となる基本インタフェース（と後述するブリッジ先）にしか流れない、といった仕組みの違いがある。

ポートVLAN

一方で ポートVLAN は、

スイッチハブ機能を持つデバイス (IX2105 なら GigaEthernet1) を

複数のサブネット (グローバルキャストドメイン) に分割＆グループ化し

GigaEthernet1:2.0, GigaEthernet1:3.0 のような「ポートベース VLAN グループ番号」が異なる独立したインタフェースを作成する ¹

という仕組みだ。

すなわち、グループなし GigaEthernet1.0 や、ポートベース VLAN でグループ化された GigaEthernet1:2.0, GigaEthernet1:3.0 などは、それぞれ L2 (レイヤー2) 的に互いに独立していると見做せる。

もちろん、各ポートVLANグループにそれぞれ IP アドレスを割り当てれば、各々がルーティングの対象となる。

ブリッジ

独立したタグVLAN とポートVLAN を紐づけるためには、複数のインタフェースをひとつのサブネット（グローバルキャストドメイン）にまとめる ブリッジ機能 を活用する。

インタフェースにブリッジ機能を割り当てると、そのインタフェースでは L3 のネットワーク層の情報が機能しなくなるため、IPアドレスや DHCP の設定など L3 に関する機能が使用できなくなる。 ²

このため、ブリッジしたインタフェース上でルーティングや IPアドレスの設定などを行う場合、 BVIインタフェース という仮想インタフェースを作成してブリッジに加え、これに IPアドレスなどの L3 に関する機能を割り当てる必要がある。

具体的なコンフィグの解説

まず、 GE0 を NAPT する WAN側、 GE1 を DHCP と Webコンソールを有効にした LAN側と見立てた、以下のようなコンフィグを入れてある状態とする。

ip ufs-cache enable ip dhcp enable ip access-list web-http-acl permit ip src any dest 192.168.99.1/32 ! proxy-dns ip enable proxy-dns interface GigaEthernet0.0 priority 254 ! http-server ip access-list web-http-acl http-server ip enable ! ip dhcp profile dhcp-profile-99 dns-server 192.168.99.1 ! interface GigaEthernet0.0 description WAN1 ip address dhcp receive-default ip napt enable ip napt hairpinning no shutdown ! interface GigaEthernet1.0 description LAN1 ip address 192.168.99.1/24 ip dhcp binding dhcp-profile-99 no shutdown !

タグVLANの構成

タグVLAN のトランクポートを扱うには、前述の「サブインタフェース」を作成する必要がある。

以下のように、 GigaEthernet1.0 に対応する各サブインタフェースにも IP アドレスや DHCP の設定を行うと、 GE1 の各ポートでは

タグなし: 192.168.99.1/24 の基本インタフェース

VLAN ID 222: 192.168.120.1/24 のサブインタフェース番号2

VLAN ID 333: 192.168.130.1/24 のサブインタフェース番号3

に割当たるようになる。

encapsulation dot1q コマンドを実行した場合は、その反映には端末の再起動が必要な点には注意。

ip dhcp profile dhcp-profile-120 dns-server 192.168.120.1 ! ip dhcp profile dhcp-profile-130 dns-server 192.168.130.1 ! interface GigaEthernet1.2 description VLAN222 encapsulation dot1q 222 tpid 8100 auto-connect ip address 192.168.120.1/24 ip dhcp binding dhcp-profile-120 no shutdown ! interface GigaEthernet1.3 description VLAN333 encapsulation dot1q 333 tpid 8100 auto-connect ip address 192.168.130.1/24 ip dhcp binding dhcp-profile-130 no shutdown

encapsulation dot1q コマンドで tpid の値を省略してもデフォルト値 0x8100 が設定されるのだが、省略したか否かにかかわらず show running-config や show startup-config のダンプ結果には表示されるため、最初からコマンドに含めている。

上記の例では、説明のために敢えてサブインタフェース番号 2 に VLAN ID 222、等と異なる番号を割り当てているが、実際に設定するときはある程度揃えておいた方が分かりやすいだろう。
サブインタフェース番号の上限は 32 等と少なめ（機種による）なので、 VLAN ID と完全に一致させるのはなかなか難しいだろうが。

ポートVLANとブリッジの追加構成

前項のタグVLAN の構成だけでは、 GE1 のどの番号のポートもトランクポートへのアクセスとなるため、 untagged なフレームを VLAN 用のサブネットにスイッチングできない。

GE1 の 2番～4番ポートをアクセスポートのように扱うために、これらのポートにポートVLANのグループ設定を構成し、トランクポートとネットワークを分割する以下のコードを実行する。

device GigaEthernet1 vlan-group 2 port 2 vlan-group 3 port 3 4

"ポートベース VLAN グループ番号" 2 に、 GE1 の 2番ポートを、グループ番号 3 に、 GE1 の 2番 & 4番ポートを、それぞれ割り当てている。

なお、グループ番号は 1 からスイッチングハブスロット上のポート数以下の整数値 (IX2105 なら 4) を設定できる。

GE1 の 1番ポートをグループ化の対象としないことにより、1番ポートには GigaEthernet0.0 のタグVLAN トランクポートのフレームが引き続き流れ続ける。

一方で、単にポートVLANグループに分割しただけでは、2番～4番ポートに untagged のフレームはスイッチングされてこない。

そこで、 untagged なフレームが流れているタグVLAN の各サブインタフェースと、 ブリッジ させてしまおう。

configure bridge irb enable ! ! interface GigaEthernet1.2 description VLAN222 encapsulation dot1q 222 tpid 8100 no ip address no ip dhcp binding dhcp-profile-120 bridge-group 200 no shutdown ! interface GigaEthernet1:2.0 no ip address bridge-group 200 no shutdown ! interface BVI20 ip address 192.168.120.1/24 ip dhcp binding dhcp-profile-120 bridge-group 200 no shutdown ! ! interface GigaEthernet1.3 description VLAN333 encapsulation dot1q 333 tpid 8100 no ip address no ip dhcp binding dhcp-profile-130 bridge-group 300 no shutdown ! interface GigaEthernet1:3.0 no ip address bridge-group 300 no shutdown ! interface BVI30 ip address 192.168.130.1/24 ip dhcp binding dhcp-profile-130 bridge-group 300 no shutdown !

まず、ブリッジ機能を有効にするために bridge irb enable コマンドの実行が必要だ。
(このコマンドはグローバルコンフィグモードで実行する必要があるため、手前で configure コマンドを実行している)

ここでタグVLAN のサブインタフェースと、グループ化したポートをブリッジするのだが、前述の通りブリッジ機能を使うとサブインタフェースに設定していた L3 の IP 関連の構成が機能しなくなる。
このため、 VLAN 毎に BVI インタフェースを作成してブリッジに加えたうえで、そちらに ip address や ip dhcp binding の構成を移植する。

なお、タグVLAN で使用している "サブインタフェース番号" GigaEthernet1.2 と、ポートベース VLAN で使用している "グループ番号" GigaEthernet1:2.0 (、そして BVI インタフェース番号 BVI20 や bridge-group 200、 VLANID VLAN222) をある程度数字揃えてブリッジしているが、必ずしもこれら番号は揃えておく必要は無い。
見やすさやわかりやすさを重視しつつ、指定できる範囲内で設定するのが良いだろう。

動作確認

ここまでの設定が完了すると、4つのサブネット間でルーティングされ、GE1 デバイスの各ポートでは以下のような組み合わせで VLAN のイーサネットフレームが流れるようになる。

試しに、GE1 の 2番ポートに繋いだ PC (192.168.120.2) から、 GE1 の 1番ポートに繋いだ PC (192.168.99.2) に、 ping を打ってみた所を、 GE1 の 1番ポートに繋いだ PC 側でパケットキャプチャしてみる。

192.168.120.1/24 のサブネットで ARP のブロードキャストされたフレームが、送信元 PC に繋いだ NIC の MACアドレス (Buffalo_f0:1X:XX) より VLANID 222 のタグ付きで 1番ポートへ届いていることがわかる。

一方、 ICMP の通信はルーティングされた上で 192.168.99.2/24 のサブネットへ届いているため、 IXルーターの MACアドレス (NECPlatf_4f:XX:XX) よりタグなしで 1番ポートへ届いていることがわかる。

おわりに

上記の設定では、VLANグループ間でスイッチングはされないが、サブネット同士で自由にルーティングされる。このため、L3スイッチで VLAN を分割しただけの場合とは異なり、 VLAN 間でも IPレイヤーの通信は行われる。実運用で VLAN 間の通信を制限したい場合は、適宜フィルタなどを追加して使う事になるだろう。
また、パスワードが設定されていないので、実運用では設定しておこう。

以上のように、VLAN スイッチなどでは単純にできるような設定でも、ルーターで実現するにはまぁまぁ大変であることがわかると思う。

とはいえ、ブリッジなどを駆使すれば、このような複雑な構成であってもルーターだけで構成できるのが IXルーターの強みとも言える。

上記の例では使用しなかったが、 GigaEthernet1:2****.3 のように、"ポートベース VLAN グループ番号" に "サブインタフェース番号" をつけることもできるため、ポートベース VLAN グループに割り当てたポートに VLAN タグがついたフレームを流すことも可能だ。 ³

参考: NEC IX2207 の VLAN 設定備忘録 | hyt adversaria

IX2000シリーズ取扱説明書の【3 基本操作と各種説明 → モードについて → インタフェース表示の意味】あたりを参照 ↩︎ ↩︎

IX2000/IX3000 シリーズ機能説明書の【■2.9 ブリッジの設定】より ↩︎

UNIVERGE IXシリーズ設定事例集の【19.2 ポートベース VLAN とタグ VLAN の併用】あたりを参照 ↩︎

Keepass2Android は Offline 版がオススメ

2023-08-19T01:00:36+09:00

パスワード管理ソフトの中でも非常に有名なものの一つが KeePass シリーズだ。

複数の端末での同期や、多要素認証などのセキュリティ向上設定には少し知識が必要なものの、 LastPass や 1Password などのクラウド型のソリューションとは異なり、有料プランの課金やサービス提供企業側のヘマによるセキュリティ侵害などのリスクが低いのが特徴だ。

Andoroid 向けの古参 KeePass 互換のパスワード管理ソフトとして、 Keepass2Android が存在する。

この Keepass2Android には、同じ作者によって提供される以下の2つのバージョンがある。

Keepass2Android Password Safe

Keepass2Android Offline

一見すると、インストール数の多い Keepass2Android Password Safe (以下、非オフライン版) の方が良さそうに見えるかもしれないが、実際には Keepass2Android Offline をオススメする。

Offline版と非オフライン版の違い

そもそも、 Offline版と非オフライン版の違いは、アプリが直接インターネットにアクセスしてデータベースファイルを取得する機能の有無だ。

しかし、 Offline版ではデータベースファイルのクラウド同期ができない…かというとそんなことはない。
Android には、 "Storage Access Framework" (SAF) という機能が備わっており、アプリがクラウドストレージと直接通信する必要なく、システムのファイルピッカーを介して、 Google Drive や OneDrive のアプリを開き、クラウドストレージとの同期ができる。

このため、 FTP や WebDAV などの一部の特殊な場所を除いて、ほとんどのクラウドストレージを Offline版でも問題なく利用できる。
開くだけでなく、データベースを編集して保存すれば、もちろんクラウド側にも変更が反映される。

すなわち、ほとんどの場合は Offline版で十分なのだ。

非オフラインが、アプリ内部から直接 Google ドライブや OneDrive, Dropbox 等を開けるのは、 SAF が一般的ではなかった過去の名残という面が大きい。

なぜ Offline版が良いのか

上記のような前提を踏まえ、そのなかで何故 Offline版が良いのかというと、アプリが 「ネットワークへのフルアクセス」の権限を持っていない からだ。

パスワード管理ソフトのリスクのひとつに、開発者の PC がクラッキングされて、ソフト側にキーロガーや他の脆弱性が仕込まれる可能性がある。
（以前、 LastPass でやられたのがまさにそれ）

しかし、万が一にもそのような脆弱性を仕込まれても、そもそもネットワークアクセス権限がなければ、奪われた情報をどこかに送信されることもない。
すなわち、より安全になる…というワケだ。

そのほか

Keepass2Android 以外の Android 向け KeePass 互換ソフトで最近人気が出てきているのが KeePassDX だ。
元々は KeePassDroid のフォークだったものだが、 UI はだいぶモダナイズされている。
権限回りもだいぶ尖っていて、「バイブレーションの制御」しか存在しない。

個人的には、ロック解除後の UI は KeePassDX の方が好みだが、生体認証を用いたクイック解除まわりの挙動は Keepass2Android の方が使いやすいので、もっぱら後者を使っている。

利用者の多さだけでなく、 GitHub 上の OSS 開発者コミュニティの活発さからもアプリの安全性が推察できるので、ぜひ利便性と安全性のバランスが取れた、お好みの KeePass クライアントを探してみると良いだろう。

Ubuntu で Main リポジトリ以外のインストール済みパッケージを一覧にする

2023-07-06T01:13:51+09:00

以下のコマンドを使用すると、 Ubuntu にインストールされているパッケージのうち、Main リポジトリ以外（Restricted, Universe, Multiverse）に属するものを一覧で表示できる。

dpkg-query --show --showformat='${binary:Package}\n' | xargs -IX bash -c "apt-cache policy X | sed -n --regexp-extended '1h;/.*(\/restricted|\/universe|\/multiverse) .*/{x;p;x;p;Q}'"

以上！

…とすると、この記事だけでは少し物足りない気がするので、使い方についても少し説明しておく。

なぜ Main リポジトリ以外のものを把握したいのか？

パッケージの取得元リポジトリのカテゴリを把握する理由は、Canonical による Ubuntu Pro のサポート範囲が関係しているからだ。

apt コマンドを使用して、Ubuntu の標準リポジトリから取得される各パッケージは、以下の4つのカテゴリに分類される。 ¹

Main

Ubuntu チームによってサポートされる、フリーソフトウェアを収容するコンポーネントで、 2,300 以上のパッケージを含む。

Ubuntu インストール時にデフォルトでインストールされるパッケージの大半はこれ。

Restricted

ドライバーなど、利便性の面でデフォルトでインストールされたほうが望ましいものの、プロプライエタリであるソフトウェアを含むコンポーネント。

Universe

Ubuntu コミュニティによって管理されている、 Linux 界の多くのオープンソースソフトウェアを収容するコンポーネントで、 23,000 以上のパッケージを含む。

Multiverse

フリーソフトの要件を満たさないような、特殊なライセンス要件をもつソフトウェアを収容するコンポーネント。

GPU 関連 (CUDA 等) や, VirtualBox などが含まれている。

これらのうち、Restricted と Multiverse リポジトリのパッケージについては、それぞれのソフトの提供元によってのみメンテナンスされ、Canonical によるサポートは行われない。

一方で、Main と Universe リポジトリのパッケージについては、セキュリティ修正の提供期間や、電話/オンラインチケットサポート範囲が、 Ubuntu Pro の有無やライセンスの種類ごとに以下のような内訳となっている。 ²

Security patching Ubuntu LTS Ubuntu Pro (Infra-only) Ubuntu Pro

Over 2,300 packages in Ubuntu Main repository 5 years 10 years 10 years

Over 23,000 packages in Ubuntu Universe repository Best effort Best effort 10 years

Optional phone/ticket support No Yes Yes

5年のLTSの期間中、Main リポジトリのパッケージを主に使用する場合、（ライブパッチ等の他のUbuntu Proのサービスが不要であれば）無料の範囲内で十分だ。

Main リポジトリのパッケージを主に使用しながら、10年の延長サポートを望む場合は、"Ubuntu Pro (Infra-only)" を契約することをおすすめする。

また、Universe リポジトリのパッケージを積極的に活用したい場合は、"Ubuntu Pro" を契約しておくと、より安心だろう。

Ubuntu の Universe リポジトリのパッケージの更新基準

ちなみに、Universe repository の "Best effort" と "10 years" の違いがいまいちわかりにくいが…

例えば、サポート中の Ubuntu 22.04 LTS であっても、 Universe リポジトリの imagemagick パッケージを更新しようとすると、 Ubuntu Pro with 'esm-apps' の有効化が必要と広告が表示される。

$ cat /etc/os-release PRETTY_NAME="Ubuntu 22.04.2 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04.2 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=jammy $ $ sudo apt update $ sudo apt install imagemagick $ $ sudo apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done Get more security updates through Ubuntu Pro with 'esm-apps' enabled: imagemagick ansible libopenexr25 libmagickcore-6.q16-6-extra libmagickwand-6.q16-6 imagemagick-6.q16 libmagickcore-6.q16-6 imagemagick-6-common Learn more about Ubuntu Pro at https://ubuntu.com/pro 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. $ $ apt-cache policy imagemagick imagemagick: Installed: 8:6.9.11.60+dfsg-1.3ubuntu0.22.04.3 Candidate: 8:6.9.11.60+dfsg-1.3ubuntu0.22.04.3 Version table: *** 8:6.9.11.60+dfsg-1.3ubuntu0.22.04.3 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/universe amd64 Packages 500 http://archive.ubuntu.com/ubuntu jammy-security/universe amd64 Packages 100 /var/lib/dpkg/status 8:6.9.11.60+dfsg-1.3build2 500 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages

package management - I'm getting the message: "The following security updates require Ubuntu Pro with 'esm-apps' enabled" when updating Ubuntu 22.04 - Ask Ubuntu

上記の回答によると、 Ubuntu の Universe リポジトリのアップストリームパッチの取り込みは引き続き行っているものの、 Canonical のセキュリティチームによるパッチは Ubuntu Pro の 'esm-apps' に限って行うようになっている。

ここでいう「アップストリームパッチ」とはなんぞや？

ImageMagick/ImageMagick6 at 6.9.12-90

ImageMagick の元の開発元の GitHub を見れば分かる通り、より高いバージョンのパッケージもメンテナンスリリースされ続けているが、これがそのまま取り込まれているわけではなさそうだ。

Debian -- bullseye の imagemagick パッケージに関する詳細

一方で、Ubuntu 22.04 LTS の元となっている Debian 11 bullseye のパッケージを見ると、 2023年7月現在は

imagemagick (8:6.9.11.60+dfsg-1.3+deb11u1)

と、 Ubuntu 側の非ESMのバージョンと、似たようなバージョンにとどまっている。

すなわち、ココで言う「アップストリーム」とは、 Debian のパッケージ管理の方を指しているのだと思われる。

おそらく、Universe リポジトリのパッケージについては以下のようになっているのだろう。

ベースとなっている Debian でリリースされているバージョンは Best effort で LTS へ取り込み

それ以外の Canonical 側で当てたセキュリティパッチは Ubuntu Pro のみに提供

だとすれば、Ubuntu Pro の esm-apps を有効にしていなくても、ベースとなった Debian レベルの修正はされると考えてよさそうだ。

実際にソースコードを見てみる

実際に、 Debian 11 bullseye, Ubuntu 22.04 LTS, Ubuntu 22.04 ESM それぞれに於ける2023年7月現在最新版のソースを、 apt source コマンドで入手してみて比べてみると…

ディストリビューション .dsc (Debian Source Control) ファイルソースファイル

Debian 11 bullseye imagemagick_6.9.11.60+dfsg-1.3+deb11u1.dsc imagemagick_6.9.11.60+dfsg.orig.tar.xzimagemagick_6.9.11.60+dfsg-1.3+deb11u1.debian.tar.xz

Ubuntu 22.04 LTS imagemagick_6.9.11.60+dfsg-1.3ubuntu0.22.04.3.dsc imagemagick_6.9.11.60+dfsg.orig.tar.xzimagemagick_6.9.11.60+dfsg-1.3ubuntu0.22.04.3.debian.tar.xz

Ubuntu 22.04 esm-apps imagemagick_6.9.11.60+dfsg-1.3ubuntu0.22.04.3+esm2.dsc ³ imagemagick_6.9.11.60+dfsg.orig.tar.xzimagemagick_6.9.11.60+dfsg-1.3ubuntu0.22.04.3+esm2.debian.tar.xz

このうち、 imagemagick_6.9.11.60+dfsg.orig.tar.xz についてはハッシュ値まで同じファイルなので、相違点は以下のファイルとなる。

imagemagick_6.9.11.60+dfsg-1.3+deb11u1.debian.tar.xz

imagemagick_6.9.11.60+dfsg-1.3ubuntu0.22.04.3.debian.tar.xz

imagemagick_6.9.11.60+dfsg-1.3ubuntu0.22.04.3+esm2.debian.tar.xz

これらのアーカイブファイルの中身に対して WinMerge の3方向マージなどを使い、changelog やパッチファイルなどの比較をしてみよう。
すると、いずれも 6.9.11.60+dfsg-1.3 までのパッチがあたっているのに加えて、それぞれ以下のセキュリティフィックスを含んでいることがわかる。

Debian 11 と Ubuntu 22.04 LTS

CVE-2022-44267

CVE-2022-44268

Ubuntu 22.04 esm-apps

CVE-2022-44267

CVE-2022-44268

CVE-2021-3574

CVE-2021-3610

CVE-2021-4219

CVE-2021-20241

CVE-2021-20243

CVE-2021-20244

CVE-2021-20245

CVE-2021-20246

CVE-2021-20309

CVE-2021-20312

CVE-2021-20313

CVE-2021-39212

CVE-2022-1114

CVE-2022-28463

CVE-2022-32545

CVE-2022-32546

CVE-2022-32547

CVE-2023-1289

CVE-2023-1906

CVE-2023-3195

CVE-2023-3428

CVE-2023-34151

前述の、 Debian 11 ≒ Ubuntu 22.04 LTS ≦ Ubuntu 22.04 esm-apps だろうという予想は当たっていそうだ。

ちなみに、つい先日2023年6月にリリースされたばかりの Debian 12 bookworm では、imagemagick_6.9.11.60+dfsg-1.6.dsc という少し dfsg のバージョンが高いパッケージがリリースされている。
その changelog を見てみると、6.9.11.60+dfsg-1.3 までのパッチに加えて、以下のセキュリティフィックスが含まれていた。

Debian 12

CVE-2022-44267

CVE-2022-44268

CVE-2021-3574

CVE-2021-4219

CVE-2021-20241

CVE-2021-20243

CVE-2021-20244

CVE-2021-20245

CVE-2021-20246

CVE-2021-20309

CVE-2021-20312

CVE-2021-20313

CVE-2021-39212

CVE-2022-1114

CVE-2022-28463

CVE-2022-32545

CVE-2022-32546

CVE-2022-32547

Ubuntu Pro の esm-apps のほうが、Debian 12 に含まれているパッチに加え、更に多くのセキュリティフィックスを含んでいることがわかる。

… Debian 12 bookworm のパッケージでも、ImageMagick 6.9.12系や ImageMagick 7系へのパッケージの更新はしていないのね。

参考:

「Ubuntu Pro」のワークステーション・データセンター向けベータリリース | gihyo.jp

【Ubuntu日和】【第30回】DebianとUbuntu、CentOSとRHELから学ぶ、Upstreamとの関係 - PC Watch

Repositories - Community Help Wiki ↩︎

Ubuntu Pro | Ubuntu ↩︎

ESM向けの配信ページはパスワード保護がかかっているが、Ubuntu Pro を有効すると作成される/etc/apt/auth.conf.d/内のファイルに記載されたユーザー名(bearer)とパスワードで認証できる。 ↩︎

超コスパ左手デバイス SIKAI CASE を安全に設定する

2023-06-28T01:34:29+09:00

世の中には、「片手キーボード」とか「左手デバイス」と呼ばれるデバイスが存在する。

ペンを使ったお絵かきや、マウス中心の作業を行う際に使われるデバイスで、必要なショートカットキーなどを登録しておくことで、複雑な操作を簡略化して入力を行えるものだ。

こういった商品は、世の中にいろいろあるのだが、有名な商品はまぁ高い。

自分で好きなようにショートカットキーを登録できる汎用的なものだと、2万3万は余裕で飛ぶようなものばかりだ。

こういったジャンルには、いわゆる中華デバイスなどとも呼ばれる、機能を割り切った安価なデバイスが売られていることが多く、この「左手デバイス」も例外ではない。

そんな、中華左手デバイスの中で、デバイスとしては比較的評判が悪くない SIKAI CASE 片手キーボードを、少し安全に使う方法について、少し考えてみようと思う。

なお、この製品自体がどんなものなのかは、ここらへんの解説動画あたりが参考になるので、そちらをどうぞ。
（私自身も、この動画を見て買った）

「安全に使う」とは？

この SIKAI CASE の片手キーボードの難点として挙げられるポイントの筆頭が、「設定ツール」に関するものだ。

まず、 UI あまりよろしくなく、だいぶ使いにくい。

そして、一番の難点は 得体の知れない Google ドライブから、設定ツールをダウンロードさせる ところだろう。
正直、こんな怪しいツールをメインのマシンで動かしたくはない。

「設定ツールすら信用できないのに、問題の片手デバイスを USB で繋ぐ事を許容するのは、矛盾してるのでは？」と思われるかもしれない。

しかし、だ。

設定ツールで書き込まれた設定内容は、片手デバイス内部に保存され、他の Windows や Androidb, macOS でも使える仕組みになっている。
このとき、汎用 HID デバイス（一般的なマウスやキーボード）として振る舞い、ドライバーも OS 組み込みのものが使われる。

そのため、仮にデバイス側に悪意があっても、過電流でPCを物理的にぶっ壊すか、入力されたキーでなんかするくらいしかできず、現実的にはあまり大きなリスクにはならないと考えられる。

つまり、なんとかキー割り当ての設定さえしてしまえれば、値段のわりに安全 ¹ に使えるのでは、というワケだ。

仮想マシンの中から設定

さて、前項を話をまとめると、
『得体の知れない設定ツールによって「自分のPCの中身」を読み書きさせるのを避けたい』
ということになる。

そこで、自分の PC の中に分離された環境の仮想マシンを立て、その中でツールを動かしてしまえば、問題を解決できそうだ。

ツールを逆コンパイルしてざっとの動作を見た感じ、 hidlibrary を使って、以下のような条件に一致する USB デバイスを探して、HID レポートを送りつけて設定を書き換えているようだ。

Vendor ID: 0x1189 (Trisat Industrial Co., Ltd.)

Product ID: 0x8890, 0x8810,0x8830-0x8834, 0x8840

"mi_00" や "mi_01" といったデバイスパスを持つ

このため、仮想マシンゲストOSに USB デバイスをマウントしてしまえば、ゲストOS からキーの設定ができそうだ。

ということで、 VirtualBox と Extension Pack を用いて、 USB デバイスのマウントを行い、ゲスト OS の中から設定する方法をとる。

なお、 Windows 10/11 の Pro エディションなら、 Hyper-V と RemoteFX USB Redirect の組み合わせでも同じ事ができると思われる。

とりあえず VirtualBox に Windows を入れる

ここの手順はざっくりとだけ説明する。
詳しくは、 "VirtualBox Windows インストール" とかで検索してくれ。

以下のファイルをそれぞれダウンロードし、

VirtualBox

VirtualBox Extension Pack

Windows 10 または 11 の評価版の ISO

VirtualBox をインストール＆ Extension Pack のインポートを実施する。

VirtualBox を立ち上げて仮想マシンを新規作成し、 ISO に評価版のものを指定し、 Windows をインストールさせる。
(評価版だと、 "Unattended Install" ができないので、手動でインストールウィザードを進めよう。)

仮想マシンのゲストに USB 機器をマウントして設定

仮想マシンのゲストOSのインストールが終わったら、ゲストOS内で設定ツールをダウンロードする。

設定ツールを起動させても、以下のようにデバイスが未接続だと表示されるはずだ。

ゲストOS に USB デバイスをマウントするために、ホストPC側に左手デバイスを USB で接続し、VirtualBox の「デバイス」オプションから、 USB -> wch.cn などと書いてある（左手デバイスによって異なる）ベンダーID 1189 のデバイスを選択する。

すると、ゲスト側の設定ツールが反応し、接続状態に切り替わる。

この状態になれば、設定ツールによる書き込みが可能になる。

設定するキーやジョグダイヤルを選択し、1キーずつ設定をダウンロードさせていこう。

全て設定が終わったら、ゲストOSから USB のマウントを停止させる。

ゲストOS 自体もシャットダウンさせてしまって良いだろう。

動作確認

ホスト PC から左手デバイスを一旦取り外し、実際に使いたいマシンに改めて接続する。

すると、先ほど設定した内容は片手デバイスの中に保存されているため、設定したとおりに機能するはずだ。

その他

説明としては以上だが、この SIKAI CASE 左手デバイスについて気になる点をいくつか。

Bluetooth版 (無線版) には技適マークが無い

無線を使っているかにかかわらず、国内で通電させたら厳密には法律違反となるので注意

レイヤー機能が Bluetooth版 (無線版) にしか存在しない

キーの組み合わせを3パターンも登録できるレイヤー機能が便利なのだが、Bluetooth版にしか存在しない

レイヤー機能の無い有線版を買うか、電波法違反を承知で無線版を有線接続して使うか、の2択になる。

もちろん、後者は違法なのでオススメしない。

あくまで「値段の割に」であり、その安全性を保証しているわけではないので、使用は各自の自己責任で。 ↩︎

ミドルGPUで35億の女(RINNA AI)のローカル実行ことはじめ

2023-05-29T09:25:32+09:00

RINNA社が 5月17日に、 rinna/japanese-gpt-neox-3.6b-instruction-sft という、対話言語 AI モデルを公開したと、プレスリリースを出した。
その後さらに 5月31日、人間の評価による強化学習したモデル rinna/japanese-gpt-neox-3.6b-instruction-ppo を追加リリースしている。

この AI モデルは、ご家庭にあるミドルレンジ GPU でもサクサク動く性能だったので、 AI 系に明るくない人にも導入できるように、詳しい導入手順を紹介しようと思う。

こう言うのって、登場して直ぐ情報がホットなうちに記事にすることに価値があって、こんな 1～2週間経ってから記事を書いたって誰にも届かないんだろうけど、とりあえず書いてみる。

この界隈の情報はコンテクストが高いというか、あんまりイチから導入方法を説明している記事って目にしないので、多少は需要があるかなと。

はじめに断っておくが、 Chat-GPT や新しいBing 等と比べると数段落ちる回答精度となる。
ただ、個人がお手軽に購入できる程度の GPU を使って、完全にローカルで動かす事ができるという点が、一種の浪漫だ。

前提条件

以下のスペックを持った PC。

OS は Windows 10 または Windows 11

GeForce RTX 3060 以上、 VRAM 12GB 以上が載った NVIDIA の GPU

GPU ドライバはインストール済み

具体的には 2023年5月現在以下のいずれかモデル

GeForce RTX 3060 (12 GB)

GeForce RTX 3080 (12 GB)

GeForce RTX 3090

GeForce RTX 3090 Ti

GeForce RTX 4060 Ti (16 GB)

GeForce RTX 4070

GeForce RTX 4070 Ti

GeForce RTX 4080

GeForce RTX 4090

3070 Ti, 3060 Ti, 3060 (8GB) だと VRAM が足りないので、多分動かすとエラーになる

導入手順

Python のインストール

Python と呼ばれるプログラミング言語（の、「ランタイム」と呼ばれるもの）をインストールする。

https://www.python.org/downloads/windows/

こちらのページから、 Python Releases for Windows の Latest Python 3 Release のバージョン (以下のスクショだと 3.11.3) を確認し、下のリストからそのバージョンの "Windows Installer (64-bit)" をダウンロード。

ダウンロードしたインストーラーを実行し、デフォルトの "Use admin privileges when installing py.exe" にチェックが入っていることを確認して、インストールを実行。

Python 仮想環境の作成

先ほどインストールした Python に、追加で必要なツールをダウンロードする環境（仮想環境と呼ばれるもの）を作成する。

まず、これから環境を作成していく元のフォルダをエクスプローラで開き、アドレスバーに powershell と入力する。

すると、黒い画面が立ち上がるので、以下のコマンドを実行。

py -3 -m venv rinna-japanese-gpt-chat

すると、 rinna-japanese-gpt-chat という名前のフォルダ作成されているはず。

vscode のインストール

Visual Studio Code (vscode) という、プログラム用のテキストエディタ（コードエディタ）をインストールする。

https://code.visualstudio.com/

Download for Windows からインストーラをダウンロードし実行する。

途中、インストールタスクの選択で、「エクスプローラーのディレクトリコンテキストメニューに [Code で開く] アクションを追加する」を追加しておく。

スクリプトファイルのダウンロード

実行するスクリプトファイルをダウンロード。

以下のページの右上らへんにある、「Download ZIP」をクリックしてダウンロードした ZIP を解凍し、中にある rinna_gradio_chat.py を、先ほど作成された rinna-japanese-gpt-chat という名前のフォルダの中に置く。

https://gist.github.com/advanceboy/717fde162a6f9ccb592f04898f0aacc1

vscode の環境のセットアップ

後半の作業を簡単にするため、 vscode の環境を整える。

先ほど作成された rinna-japanese-gpt-chat という名前のフォルダを右クリックして（Windows 11 の場合は、更に「その他のオプションを表示を」クリックして）、「Code で開く」を選択する。

すると、 vscode が立ち上がる (フォルダを信用しますか？的な Trust 何ちゃらの画面が出たら、 yes を選択しておく)。

Ctrl + Shift + E キーを押すと開く vscode 上の Explorer ペインで、先ほどダウンロードした .py ファイルを選択する。
すると、 "Do you want to install the recommented 'Python' Extension..." と聞かれるので、 Install を選択。

インストールが終わったら、再び vscode 上の Explorer ペインで .py ファイルを選択して Ctrl+@ キーを押し、 PowerShell ターミナルを表示させる。

このとき、表示される TERMINAL ウィンドウでは (rinna-japanese-gpt-chat) PS と先頭に表示されるようになっているはずだが、もしそれが表示されない場合は、このターミナル上で .\Scripts\Activate.ps1 と入力しておく。

Python の依存パッケージ (CUDA 対応 CUDA) の確認とインストール

Python で AI を実行するため、 AI 関連ライブラリーを、先ほど作成した Python の仮想環境内にインストールする。

まず、 PyTorch という機械学習ライブラリのページに飛ぶ。
https://pytorch.org/get-started/locally/

以下のような組み合わせの選択肢を選び、表示されたコマンドを前述の vscode のターミナル上（ (rinna-japanese-gpt-chat) PS と先頭に表示される状態）で実行する。

PyTorch Build: Stable

Your OS: Windows

Package: Pip

Language: Python

Compute Platform: CUDA の最新版

例えば、 CUDA 11.8 の環境をインストールする場合は、以下のようなコマンドになると思われる。

pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

その後、残りの依存ライブラリもインストールしておく。

pip3 install ipython sentencepiece transformers accelerate gradio

pip3 install の実行順を逆にすると、 CUDA に対応していない torch がインストールされてしまい、後々エラーになってしまうので注意。

CUDA ツールキットのインストール

最後に、 CUDA と呼ばれる NVIDIA の GPU 上で AI を効率よく実行するためのツールキットをインストールする。

以下の CUDA Toolkit Archive のページを開き、前項で "Compute Platform" で選択したバージョンの CUDA Toolkit をダウンロードし、インストールする。

https://developer.nvidia.com/cuda-toolkit-archive

最新版ではなく、前項の PyTorch ライブラリのダウンロード時に選択したバージョンの CUDA をダウンロードする必要がある点に注意が必要だ。

例えば、 2023年5月現在、 CUDA Toolkit の最新版は 12.1.1 だが、前述の PyTorch ライブラリが対応する CUDA が 11.8 までなので、 CUDA Toolkit 11.8.0 をダウンロード＆インストールする。

実行手順

vscode のターミナル上（ (rinna-japanese-gpt-chat) PS と先頭に表示される状態）で、以下のように実行する。

python .\rinna_gradio_chat.py

しばらくすると、ターミナルにローカルで立ち上がったサーバーの URL http://127.0.0.1:7860 が表示されるので、 Ctrl キーを押しながらクリックして、ブラウザでアクセスする。

あとはお好きなようにいじくり倒すだけだ。

前述の動画は生成部分も含めて等倍速だが、ミドルレンジの GPU でもそれなりの速度で生成できていることがわかる。

停止させたい場合は、ターミナル上で Ctrl + C キーを押そう。

補足

生成速度

ChatGPT などでは元々生成速度が速いので気になりにくいが、英語と比べて日本語テキストの生成は遅く、同じ情報量で生成時間も利用料金も数倍かかってしまう。
その理由を雑に説明すると、「トークン」と呼ばれる学習・生成の単位が、英語では単語単位となる一方で、日本語は文字単位となっているためだ。

一方、りんなさんこと japanese-gpt-neox-3.6b では、単語間にスペースが存在しない日本語でも、ある程度単語ごとにトークン化されてから処理されるので、生成も文字単位では無く単語単位となり、処理効率が大幅に向上しているのだろうと考えられる。
ChatGPT などが存在しても、国産ないし国内向けの AI モデルが必要とされる理由の一つに、こういった背景があるようだ。

対応GPU

対応GPUを RTX30 世代以降に限っているのは、VRAM の利用を節約するために bfloat16 量子化して動かしているのだが、この bloat16 での効率的な計算に対応しているのが Ampere 以降世代の GPU となるためだ。

もし、 RTX 10, 20 の GPU で動かしてみたい場合、

https://gist.github.com/advanceboy/717fde162a6f9ccb592f04898f0aacc1#file-rinna_gradio_chat-py-L35

torch_dtype = torch.bfloat16

この部分を、搭載 VRAM に応じて torch_dtype = torch.float16 や torch_dtype = torch.float32 に書き換えれば上手く動くかもしれない。

CUI版

わざわざブラウザ立ちあげず CUI 上でチャットしたい場合は、上記のスクリプトの替わりに以下のスクリプトを使うと良いだろう。

rinna_chat_streaming.pyrinna/japanese-gpt-neox-3.6b-instruction-sft を使ったチャット UI のサンプル実装です。 transformers.TextIteratorStreamer API を利用して、 ChatGPT のように生成したテキストを少しずつ表示し、ユーザー体験を向上させています。https://t.co/tXtoN952un
— ながいの as a サービス (@longer_n) May 19, 2023

YAML の細かい仕様の話

2023-05-01T01:32:11+09:00

グワーッ！YAML 1.2 って、 yes,no,on,off 系が Boolean リテラルではなくなる破壊的変更あるん!?Docker Compose v2.17.0 で内部パーサが go-yaml/yaml.v3 に更新され、真偽値を yes, no で書いてた compose.yml ファイルが軒並み must be a boolean エラー出まくってて死。https://t.co/PVpdIWFVgA
— ながいの as a サービス (@longer_n) April 12, 2023

趣味アカウントのほうでバズった… ってほどでは無いけど、割と反響があったので、 YAML に関する話をいくつか。

YAML 1.2 では Boolean として扱うのは true, false だけ

https://yaml.org/type/bool.html

YAML 1.1 では以下の文字が Boolean として認識されるのが一般的だ。
y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF

厳密には、 !!bool タグを使って Boolean 型を表現する場合の表記方法だが、基本的には多くのパーサーではタグを書かなくても Boolean 型として扱われる。

https://yaml.org/spec/1.2.0/#id2602744

しかし YAML 1.2 以降ではこれが、 true, false のみが Boolean として認識されるという、だいぶデカい破壊的変更が入っている。

ここで、 1.2.0 の主たる更新点を見てみると…
https://yaml.org/spec/1.2.2/ext/changes/#changes-in-version-12-revision-120-2009-07-21

Changes in version 1.2 (revision 1.2.0) (2009-07-21)

[...]

Only true and false strings are parsed as booleans (including True and TRUE); y, yes, on, and their negative counterparts are parsed as strings.

Underlines _ cannot be used within numerical values.

Octal values need a 0o prefix; e.g. 010 is now parsed with the value 10 rather than 8.

The binary and sexagesimal integer formats have been dropped.

The !!pairs, !!omap, !!set, !!timestamp and !!binary types have been dropped.

The merge

参考日本語訳:

true と false の文字列のみがブーリアン（TrueとTRUEを含む）として解析される。 y, yes, on およびそれらの否定語は文字列として解析される。

アンダーライン _ は、数値の中では使用できません。

8進数の値には0oのプレフィックスが必要です。例えば010は8ではなく10という値で解析されるようになりました。

二進法と十進法の整数形式は廃止されました。

ペア、オマップ、セット、タイムスタンプ、バイナリ型は削除されました。

merge

うーん、現代のセマンティックバージョニングだったら、絶対にマイナー場ジョンアップじゃダメなヤツ。

こういった仕様のため、 yes, no と書いた際にどう扱われるかは、パーサーの実装による。

例えば、 PyYAML などは Boolean リテラルとして扱われるが、 go-yaml/yaml.v3 では文字列として扱われる。

内部パーサーの更新でこの解釈が変わってしまったために発生したのが、冒頭の問題だ。

Ansible などでは、真偽値を yes, no と書く慣習があるせいで、もうめちゃくちゃあっちこっちで yes, no って書いてるわ…

なお、冒頭の Docker Compose については、 Docker Compose version v2.17.3 で yes 等を書いてもエラーにせずワーニングだけ出すように修正された。
[BUG] Error "must be a boolean" with yes scalar in Docker Compose v2.17.0 · Issue #10465 · docker/compose

">" は全ての改行をスペースに置き換えるわけではない

ブロックスタイルの文字列表記で、 ">" インジゲータを置くと、次の行から途中の改行が半角スペースに置き換えられると説明されがちだ。

foo: > trimmed line

しかし、半角スペースに置き換えられる条件はもう少し複雑だ。

https://yaml.org/spec/1.2.2/#line-folding

この Line Folding と言うのがこれに当たるのだが、これは長い行を折りたたんで読みやすくするための機能だ。

折りたたまれた部分（改行）が半角スペース (0x20) に変換されるものだが、

複数の改行が続く場合は最初の改行が破棄され、残りは保持される

先頭の空白を含むテキスト行（つまりインデントされた行）は、行の折り返しは適用されない。

という仕様がある。

このため、以下のように動作する。

YAML 入力:

foo: > trimmed line breaking but blank line and nested line are are retained.

JSON 出力:

{ "foo": "trimmed line breaking\nbut blank line and\n nested\n line\nare are retained.\n" }

つまり、「改行を消す」というよりは、「次の行のインデントの高さがブロックの先頭と同じ場合のみ、行の折りたたみと見なして改行を削除する」という動作となる。

マージキー (<<) によるマージは 1回しか記述できない。

複数のマップをマージしたい場合は、シーケンス（配列）によって指定する。

https://yaml.org/type/merge.html

YAML 入力:

- - &ANCHER1 { '0': 0, a: 0, b: 0 } - &ANCHER2 { b: 99, c: 99 } - &ANCHER3 { c: 255, d: 255 } #- # Eror # '0': 1 # << : *ANCHER1 # << : *ANCHER2 # << : *ANCHER3 # a: 1 - # Single map b: 1 << : *ANCHER2 - # Override multiple maps '0': 1 << : - *ANCHER1 - *ANCHER2 - *ANCHER3 a: 1

JSON 出力:

[ [ { "a": 0, "b": 0 }, { "b": 99, "c": 99 }, { "c": 255, "d": 255 } ], { "b": 1, "c": 99 }, { "0": 1, "a": 1, "b": 0, "c": 99, "d": 255 } ]

シーケンスで複数のマップを指定した場合で、キーが重複している物は、シーケンス内では順序が前のものが常に優先される。
一方で、マージキーで指定したモノよりは、マージ先のものが優先となる。

ただ、パーサーによってはマージキー (<<) を複数書く誤った書き方に対応しているモノがあり、
実際、 Docker Compose v2.17.0 で、内部パーサーが go-yaml/v3 に切り替わったときに、誤った書き方が対応から未対応に変わって、以下のようなエラーが出てハマった。

mapping key "<<" already defined at line nnn

[[BUG]using multiple yaml alias not working. mapping key "

もちろんこれは、マージキーを複数書く方が悪いので、 YAML の方を直す必要がある。

例: https://go.dev/play/p/jos7jc38loK
-->

[Windows] MBR パーティションの SSD を GPT へコピーする

2023-04-01T01:43:53+09:00

突然だが、超久々に自作 PC を組んだ。
前回は Windows 7 登場の 2009年に、第1世代 Core i5 750 で組んだ時なので、約14年ぶりとなる。

ハードは一度、中古でもらった第3世代 Core i7 3770 に置換えているのだが、その際もストレージや Windows 7 Pro のライセンスはそのまま流用していてる。
その後も、ストレージをクローンしたり「初期状態に戻す」で再インストールしながら、脈々と使い続けているものとなる。

このため今回も、旧PCに入っている SATA SSD に入っている Windows 10 を、新PC の NVMe SSD にコピーして、その状態で起動させてから（ライセンスにハード構成覚えさせてから）、 Windows 11 に上げようと考えた。

ところが、 NVMe SSD で起動するのに結構苦戦したので、その解決策のメモ。

とりあえず最初に試したこと

Ventoy をインストールしたブータブル USB メモリに GParted live を入れ、 GParted を使い、

新NVMe SSD をパーティションテーブル GPT で初期化

旧SATA SSD から新NVMe SSD へ雑にパーティションをコピー

を行った。

この状態で試したところ、ブルースクリーンすら表示されず、 UEFI から何もブートできない。
USB メモリ内の Windows ISO からブートして、回復コンソールからスタートアップ修復などを試しても駄目だった。

根本的な原因

原因は言わずもがな、パーティション弄った際のお馴染みのトラブルである、ブートレコードまわりの問題だ。
今回は、パーティションテーブルの違い (MBR と GPT) もあって、少々ややこしいことになっていた。

この PC の系譜の元祖を組んだ 2009年当時も UEFI は存在はしていたものの、当時サポートしていた M/B (マザボ) なんぞ殆どなく、そこから脈々とクローンしている旧 PC の SATA SSD のパーティションテーブルは MBR のままだ。

一応、 M/B には CSM Support という BIOS 互換モードの設定があるので、新SSD も MBR でパーティション作り直し、セキュアブートを無効にすれば起動はできるはず？
…とは思ったのだが…、

なんと最近の CPU, チップセットは Legacy BIOS のブートに対応しない方針らしい。

【サポート情報】最新世代のマザーボードでのLegacy BOOTには注意しよう - ツクモ東京地区店舗BLOG

あまりに長いこと自作マシンから距離を置いていたせいで全然知らなかった…
パーティションテーブルが MBR なら Legacy BIOS ブート、 GPT なら UEFI ブートにしようみたいなところで知識が止まっていたぞ。

MBR でのブート対応しない Windows 11 に今後更新することを想定すれば、 GPT に変更しておくべきだろう。
どうせ今回は旧SATA SSD から新NVMe SSD へのパーティションのクローンもしなくてはならないので、 MBR から GPT への切替をしながらクローンを進める方向で考える。

ところが、色々調べても MiniTool, EaseUS, AOMEI の広告記事の機械翻訳といったゴミ情報ばかりでなかなか情報にたどり着けず。
ChatGPT や "新しい Bing" に聞いてみても、残念ながらあんまり役に立つ回答が得られなかったし。

兎にも角にもクリーンインストール

UEFI ベースのデバイスに GUIDパーティションテーブル (GPT) のファイルシステムで Windows を起動させる場合、 EFI システムパーティション (ESP) というものが必要になる。
こいつは MBR では存在しなかったものなので、別途作ってやらなければならない。

また、 Windows 側でパーティション管理しやすくするため、 Microsoft 予約パーティション (MSR) というものも必要らしい。

UEFI/GPT ベースのハードドライブパーティション | Microsoft Learn

ちまちまパーティションを作るのは面倒なので、新NVMe SSD の中身を綺麗さっぱり削除し、 Windows 10 のクリーンインストール → 旧SATA SSD の Windows パーティションで上書き ……という方法を取る。

Ventoy に Windows 10 インストーラ ISO イメージを書き込んでブート

手順に従って、 Windows 10 を新規インストール

ココで入れた Windows はすぐ消すので、プロダクトキーは入れずに進めて良い

起動するパーティションを覚えさせるため、インストール完了後一度 Windows を起動させる

再び Ventory に入れた GParted をブート

旧SATA SSD の Windows パーティションを、新NVMe SSD の Windows パーティションにコピー



コピーの方向逆にするとデータが全部飛ぶので要注意

うまく行けば、この状態で再起動すれば問題なく Windows が起動するだろう。

それでもブルースクリーンが出る場合

少なくとも、上記の手順で ESP はブートするはずなので、悪くてもブルースクリーンぐらいは出るはずだ。

ここでもしエラーコード 0xc000000e などが出ている場合、 ESP 内の Boot Configuration Data (BCD) や M/B の NVRAM にあるブートオプションが、次に起動する Windows パーティションを適切に指せていない可能性がある。

この場合、回復コンソール上で echo list volume | diskpart と実行して Windows が入っているとみられるパーティションのドライブレターを確認し、（ラベルやサイズで判断する）

```text/plain
X:\Sources>echo list volume | diskpart

Microsoft DiskPart バージョン 10.0.19041.964

Copyright (C) Microsoft Corporation.

Volume ### Ltr Label Fs Type Size Status Info

Volume 0 C Windows NTFS Partition 461 GB Healthy
Volume 1 BOOT FAT32 Partition 499 MB Healthy
Volume 2 Recovery NTFS Partition 4881 MB Healthy Hidden

その結果例えばドライブレターが `C` であれば以下のように実行し、「ブートファイルは正常に作成されました。」と結果が出れば OK なはずだ。

bcdboot C:\Windows /l ja-JP
```

終わりに

以上が、 Windows メディアや OSS の無料のツールだけを使って、 MBR のディスクから GPT のディスクにパーティションをクローンする方法だ。

もう流石に、今後 MBR を触ることはないかな…

余談1 (Ventoy)

本文中にも出てくるが、 Ventoy: A New Bootable USB Solution が便利すぎる。

PC を構成しているとどうしても、パーティション弄るツールやインストールメディアなど、複数のブータブルメディアを使う羽目になってくる。
昔は種類ごとに CD/DVD を焼いたり、 USBメモリを焼き込んだりしていたもので、使い分ける際もいちいち本体に入れ直さなくてはならないなど、面倒この上なかった。

Ventoy をインストールした USBメモリを一つ用意しておけば、そのメモリの exFAT パーティションに好きな iso ファイルを複数放り込んで、簡単にブート仕分けることができる。

ブートするツールを更新する際も、 iso ファイルを入れ替えれば良いので、最新のツールに更新する敷居も下がってとても良い。

余談2 (光ディスクの劣化)

Ventoy を使いだす前、昔焼いたブータブルCD/DVD 使ってパーティション弄ろうとしていた。
しかし、流石に5年以上前にしかも安物のディスクに焼いたものだったので、ディスクのエラー率高くて時折ブートに失敗してしまう。

普通の色素系ディスクだとこれくらいの年月で駄目になってくるのねー、と実感してしまった。

長期とっときたいデータはやはり、選別や再エンコードなどして M-DISC とかに焼いとかないと駄目だなー

PowerShell で中身がランダムな大きめのファイルを高速に作る

2023-02-14T12:41:19+09:00

色々テストをしていると、ユニークなランダムの中身で、任意サイズのファイルが欲しくなることがままある。

デバイスを全てファイルとして扱う Unix や Linux なら、 /dev/urandom 擬似デバイスを使って dd if=/dev/urandom of=out.bin bs=1M count=64 みたいに任意サイズでファイルをコピーして作れば良い。

しかし API ベースの Windows だとそういうわけにいかないので、何らかのスクリプトから API を呼んでやる必要がある。

呼ばせるスクリプトは、 Windows に標準で搭載されていて追加でインストール不要な、毎度おなじみ PowerShell が良いだろう。
作りたいランダムなファイルのサイズが小さければ、 PowerShell 上で以下のような雑なコードを実行すればよい。

$Size = 16KB; [byte[]]$bin = &{foreach($i in 1..$Size) { Get-Random -Maximum 255 }}; [System.IO.File]::WriteAllBytes((Join-Path (Get-Location) .\out.bin), $bin);

しかし、 MiB オーダーを越えてくると、上記のコードでは速度が実用的ではなくなる。

と言うことで、出力速度も気にしながら、大きめなランダムなファイルを作成するコードを考えてみる。

コード

function Make-RandomFile ([Parameter(Mandatory=$true)][string]$OutPath, [Parameter(Mandatory=$true)][long]$FileSize, [int]$ChunkSize = 16MB) { $bin1 = [byte[]]::new($ChunkSize); $bin2 = [byte[]]::new($ChunkSize); $r = [System.Random]::new(); [long]$progress = 0; [int]$nextLen = 0; $fs = [System.IO.File]::Create([System.IO.Path]::Combine($PWD, $OutPath)); try { do { $task = $fs.WriteAsync($bin1, 0, $nextLen); $r.NextBytes($bin2); $task.Wait(); $bin1, $bin2 = $bin2, $bin1; $progress += $nextLen; $nextLen = [System.Math]::Min([long]$ChunkSize, $FileSize - $progress); } while ($nextLen -gt 0); } finally { $fs.Dispose(); } }

上記のような関数をコンソールに貼り付けて定義し、あとは以下のように実行すれば良い。

Make-RandomFile .\out.bin -FileSize 1GB;

解説

大きなファイルを作る際、最初に挙げたような雑なコードだと、一旦全てのデータをメモリ (RAM) に置いてしまうため、メモリ不足になったり動作が遅くなったりしかねない。
そこで、適当なチャンクサイズ (上記コードだと標準では 16MiB) 毎にランダムなデータを作って、それを書き込んでいる。

また、ランダムな配列を作るのも、その配列をファイルに書き込むのも、それぞれ時間がかかるため、それらを同期的に逐次実行すると効率が悪い。
そこでバッファを2つ用意して、片方のバッファでファイルを非同期的に書き込んでいる間に、もう一方のバッファでランダムなデータを生成することで、効率を上げている。

補足

ちなみに、 .NET 5 以前の System.Random の擬似乱数生成器は、あまり乱数精度が高くないと言われているので、セキュリティ的に精度の高いランダム性であることが重要な場合は、より乱数精度の高い別の API を使った方が良いかもしれない。

とりあえず、ちょっとしたテストファイルでランダムなデータが欲しいだけなら、 System.Random で十分だと思うが。

また、ストレージの速度が十分に速い状況でより速く実行させたいなら、 Windows 10/11 標準の Windows PowerShell 5.1 より PowerShell 7.2 以降で実行したほうが、圧倒的に速いはずだ。 ¹

Windows PowerShell 5.1 では .NET Framework 4.8 が、 PowerShell 7.2 LTS では .NET 6 が、それぞれ使われているが、その .NET 6 以降では、擬似乱数生成器が性能の良いものに切り替わった為 (.NET 6 (Preview) における System.Random の実装変更 - 屋根裏工房改) ↩︎

Git と OneDrive 等のクラウドストレージを併用する

2023-01-31T23:59:28+09:00

ブログに書きたいネタとか雑多なメモを管理する際、Git によるバージョン管理と、クラウドストレージによる同期を併用したくなる。

具体的には、こんなことがしたい：

コミットに至らないメモ書きの段階では、クラウドストレージで同期させたい

ついでにそのメモ書きは、タブレット等の複数の端末から更新したい

ブログで記事を公開してからの差分を Git で管理

プライベートのリモートリポジトリ代わりに、ベアリポジトリを OneDrive に共有する話は見たことある (これとかこれ) のだが、私がやりたいこととはちょっと違うんだよな。
そもそも、 Microsoft 買収後に GitHub で無制限にプライベートリポジトリ作れるようになったので、 Git リポジトリの共有自体は GitHub とかで良いので。

以前、ローカルリポジトリをまるごと OneDrive で共有させてみたのだが、複数の端末で編集すると同期の競合が発生しまくってしまった。
特に .\.git ディレクトリ内でコンフリクトすると後処理が面倒くさすぎる。

どうにかならんもんか。

.\.git ディレクトリだけ同期除外

先に答えを言ってしまうと、クラウドストレージでの同期で特定のディレクトリの同期を除外させれば良い。

.\.git ディレクトリ内のコンフリクトが面倒なら、 .\.git ディレクトリだけ同期を除外させればいじゃない… という精神だ。

ただ、 OneDrive では一筋縄ではいかなかったので、少々トリッキーな方法を採っている。

そのやり方を、 Windows 上の OneDrive を例に紹介する。

1つ目の端末

既に OneDrive で管理しているフォルダを、 Git 管理させる方法。

同期させたいディレクトリのルート直下に .\.git フォルダを手動で新規作成する

OneDrive の設定から、アカウント → フォルダの選択から、 .\.git フォルダーを同期の対象外にする


ローカルから .\.git フォルダが消える

git init する

.\.git 隠しフォルダが再作成される

適当に Git のコミットしたり、 remote の追加・プッシュしたりする

この結果、 Git のリポジトリやステージングのデータを除く、ワーキングツリーのファイルだけをクラウドストレージで同期できる。

難点なのが、 OneDrive 上で「同期の問題」として以下のエラーが出続けることだ。

この名前のファイルまたはフォルダーが、同じ場所にあります。
両方のバージョンを残すには、この PCまたはオンラインのどちらかでこのアイテムの名前を変更してください。両方のアイテムが同じ場合は、この PCにあるバージョンを削除するとオンラインのバージョンをダウンロードできます。

なお、エラーが出ていても同期はされる。

2つ目の端末

上記と同様、 OneDrive でワーキングツリーを同期させつつ、 .\.git ディレクトリは同期させないフォルダを、別のマシンに構築する方法。

一旦、対象ディレクトリを「このデバイス上で常に保持する」を実行して、ファイルをローカルにおいておく

OneDrive の設定から、アカウント → フォルダの選択から、 .\.git フォルダーを同期の対象外にする

1つ目の端末の設定で、既に空の .\.git フォルダが存在しているはず

設定後ローカルから .\.git フォルダが消える

同期を一時停止

clone の替わりに fetch と reset を使い、ワーキングツリーはそのままリポジトリだけ更新する

$ git init $ git remote add origin [email protected]:username/reponame.git $ git fetch origin master $ git reset origin/master

同期を再開させる

リポジトリの同期

片方で push した後もう一方で pull しようとしても、先に OneDrive の同期によってワーキングツリーのファイルが更新されてしまっているので、 pull がエラーになってしまう。

こればかりはどうしようもないので、2つ目の端末のセットアップと同様、以下のように ワークツリーを維持したまま、 リポジトリとステージングを (--mixed オプション相当で) リセットしてやれば良い。

$ git fetch origin master $ git reset origin/master

こんな感じで、期待していた環境が整った。

Android からは Jota+ あたりを使って OneDrive 上のファイルを直接更新したりしながら活用している。

【参考】: OneDrive で特定のファイル名パターンのファイルをアップロードから除外する方法

ちなみに、グループポリシーやレジストリをいじることで、「特定の種類のファイルをアップロードから除外」する事ができる (OneDrive ポリシーを使用して同期設定を制御する - SharePoint in Microsoft 365 | Microsoft Learn)。

が、残念ながらフォルダに対してはこの機能が働かないので、上記の用途を満たさない。

参考までに、やり方だけ下記に示しておく。

レジストリを弄る場合:

HKLM\SOFTWARE\Policies\Microsoft\OneDrive\ の下に EnableODIgnoreListFromGPO というキーを作る

その中に「除外したいファイル名」を名前と値の両方に持った、文字列値（複数可）を入れる

PC を再起動する

グループポリシーを使う場合:

「グループポリシーの編集」を使える状態にする

Windows の Pro エディション以上なら標準では言っている。 Home エディションなら、ググって調べて。

C:\Users\N2633\AppData\Local\Microsoft\OneDrive\<ビルド番号>\adm\ 内の以下のファイルをコピーする

.\OneDrive.admx を C:\Windows\PolicyDefinitions\ へ

.\ja\OneDrive.adml を C:\Windows\PolicyDefinitions\ja-JP\ へ

Win+R で gpedit.msc を入力し「ローカルグループポリシーエディター」を立ち上げる

[コンピューターの構成] → [管理用テンプレート] → [OneDrive] → [特定の種類のファイルをアップロードから除外] を選択

構成を有効にして、キーワード一覧に除外したいファイル名（アスタリスク可）を設定する

Docker run の起動時に任意コードを実行後 bash や ash を終了しない

2022-12-29T16:47:37+09:00

この記事は、 Docker Advent Calendar 2022 の 23日目の記事だ。
空いていたので埋めちゃうよ。

この記事では、 bash や ash で任意のコードの実行後、ターミナルを終了せずに入力待ちにする方法について紹介する。
特に、 docker run の実行後に、その環境を維持したまま入力待ちにすることを考える。

例えば、 Windows コマンドプロンプトや PowerShell であれば、 CMD /K *** オプションや、 -NoExit -Command *** オプションで実現できるような内容だ。

本来なら、 docker build にてその任意コードの実行後の内容をイメージにするべきだが、わざわざ build するまでもないとか、 build できない事情などもあるかもしれない。

ということで、 bash の場合と、 alpine などで使われる BusyBox ash それぞれについて、 docker run 実行時に任意コード実行後、ターミナルの入力待ちにする方法を紹介する。

bash の場合

bash の場合、 --rcfile オプションにて、起動時に実行するコマンドを指定できる。

ただし、 --rcfile はファイルを指定する必要があるため、替わりにプロセス置換で実行コードを与えてやる方法をとる。

user@hostmachine:~$ docker run --rm -it debian:bullseye bash -c "bash --rcfile <(echo 'ls && export '\''FOO=B A R'\'' && MY_TIME=\$(date)')" bin dev home lib64 mnt proc run srv tmp var boot etc lib media opt root sbin sys usr root@container:/# echo $FOO : $MY_TIME B A R : Thu Dec 22 15:00:00 UTC 2022 root@container:/#

プロセス置換はコンテナ内で実行される必要があるため、一旦 bash -c にてコンテナ内で bash 実行させ、その中で改めて --rcfile オプションを指定した bash を起動する流れとなる。

実際に実行したいコマンドは、 echo で文字列として書き出す。
上記例では、 ls && export 'FOO=B A R' && MY_TIME=$(date) と言う文字列を echo させている。

引用符が二重三重になっていて、エスケープが非常に難しくなっているので注意。

BusyBox ash

alpine 3.15 以降に含まれる BusyBox の ash であれば、意外にもプロセス置換が使える。

しかし、 --rcfile に相当するオプションは残念ながら無い。
替わりに、 ash には ENV という環境変数に記載されたファイルを ash 起動時に実行する機能がある。

これを使おう。

user@hostmachine:~$ docker run --rm -it alpine:3.15 ash -c "ash -c 'export ENV=\$1;ash' -s <(echo 'ls && export '\''FOO=B A R'\'' && MY_TIME=\$(date)')" bin etc lib mnt proc run srv tmp var dev home media opt root sbin sys usr / # echo $FOO : $MY_TIME B A R : Thu Dec 22 15:00:00 UTC 2022 / #

ash の -c のコマンドに対して引数を与える -s オプションを使ってプロセス置換のファイルを与え、それを $1 経由で ENV 環境変数にセット。その状態で再度 ash を起動させれば、 bash と同様のことが行える。

ENV 環境変数に直接プロセス置換のファイルを指定せず、わざわざ一旦引数を経由させているのは、入力を受け付ける ash プロセスが動いている間、プロセス置換のファイルにアクセス可能にする必要があるためだ。
例えば、 export ENV=<(echo 'command');ash と実行しても、 ash 実行の段階ではプロセス置換のファイルが閉じられているので、コマンドは実行されない。

もうちょっと複雑な例

起動時に apt パッケージマネージャーのリポジトリを書き換える方法（Ubuntu）:

docker run --rm -it ubuntu:22.04 bash -c "bash --rcfile <(echo 'sed -i -E '\''s%^(deb(-src|)\s+)https?://(archive|security)\.ubuntu\.com/ubuntu/%\1http://srv2.ftp.ne.jp/Linux/packages/ubuntu/archive/%'\'' /etc/apt/sources.list && apt update && FooBar=`date -uIs`')"

起動時に apk パッケージマネージャーのリポジトリを書き換える方法（Alpine）:

docker run --rm -it alpine:3.15 ash -c "ash -c 'export ENV=\$1;ash' -s <(echo 'sed -i -E '\''s%^https?://dl-cdn\.alpinelinux\.org/alpine/%https://ftp.udx.icscoe.jp/Linux/alpine/%'\'' /etc/apk/repositories && apk update && FooBar=`date -uIs`')"

参考: https://stackoverflow.com/questions/74094552/how-not-to-terminate-after-carried-out-commands-in-bash

GNS3 に VyOS 仮想ルーターを追加する長い道のり④ 応用編

2022-12-28T23:48:38+09:00

本記事は【アットホームな現場です】🎄★☆ネットワーク系エンジニア★☆アレコレアウトプット★☆🎄 Advent Calendar 2022 25日目の記事だ。
ごめんなさい、色々書いてたら結局分量が多くなって期限内に書き切れなかった。

GNS3 という OSS のネットワークエミュレータを、 Cisco の IOS などの取得なしに、無料のライセンス内で利用できるようにしようという話。

今回は最終回の応用編。
以前の投稿はこちら。
https://crieit.net/posts/GNS3-VyOS (① 環境導入編)
https://crieit.net/posts/GNS3-VyOS-63ac561ed5a75 (② イメージ準備編)
https://crieit.net/posts/GNS3-VyOS-63ac5693838af (③ 実践編)

目指すゴール

今回は、上記の図のように、ルーターを 2台置いて、ルーターを跨いだ端末間 (tmp-net-tools-1, -2) で通信ができるように構成していく。

相互通信するコンテナの準備

ルーターを跨いだ通信を実際に行うことになるコンテナを準備する。

通信の確認を行う最低限のモジュール（パッケージ）をインストールしたイメージを用意する。

（リスクを自分で評価しつつ）第三者が用意したイメージを使っても良いのだが、今回は自分でビルドしてみよう。

まず、 VM管理ツールや ssh で GNS3 VM の管理画面に入る

メニューから Shell を選択する

以下のコマンドで、 tmp-net-tools という名前をつけた Docker イメージをビルドする

shell gns3@gns3vm:~$ docker build -t tmp-net-tools - FROM alpine:latest RUN apk add --no-cache curl iperf3 net-tools EOF

GNS3 (GUI) の Preferences を開き、 Docker コンテナテンプレートで上記のビルド済み tmp-net-tools でテンプレートを作成する。

Console type は telnet で OK.

ここでポイントとなるのは、 GNS3 で動かすコンテナは基本的に（明示的に接続市内限り）外部ネットワークに繋がっていないが、 GNS3 VM で Docker をビルドする際は、外部ネットワークに繋がると言う点だ。
このため、コンテナ内にて追加で必要なパッケージがある場合、このように予めコンテナの build 段階でインストールしておく必要がある。

ネットワークの構成 1

コンテナテンプレートの準備ができたら、ペタペタとデバイスを貼って結線していく。
2つの VyOS とも、 eth0 を端末のコンテナ側に、 eth1 をルーター同士を繋ぐ Switch に繋いでいこう。

本来 VyControl は、 1サービスで複数の VyOS を管理できるはずなのだが、試した感じどうも管理対象の切り替えでエラーになってしまうので、素直に VyOS と VyControl を 1対1 で作成している。
ただ、そうするとホストPCからそれぞれの VyControl にアクセスする際に同じ IP アドレスとなって Cookie が衝突するため、片方にログインするともう一方からログアウトされてしまう問題があるので注意。

また、 vycontrol-host や tmp-net-tools の各コンテナにて、 Edit config からの /etc/network/interfaces の編集で、 eth0 を DHCP から IP アドレスを取得するよう設定することを忘れずに。

VyOS は前回の設定に加えて eth1 の IP アドレスを静的に決めるため、それぞれ以下のように設定する。

VyOS1.3.2-1:

vyos@vyos:~$ configure vyos@vyos# set interfaces ethernet eth0 address '192.168.11.254/24' vyos@vyos# set interfaces ethernet eth1 address '192.168.1.1/24' vyos@vyos# set service dhcp-server shared-network-name 'subnet01' vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.11.0/24' default-router '192.168.11.254' vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.11.0/24' name-server '192.168.11.254' vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.11.0/24' range 0 start '192.168.11.17' vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.11.0/24' range 0 stop '192.168.11.126' vyos@vyos# set service https api keys id my_id key 'my_secret_key' vyos@vyos# set service https certificates system-generated-certificate lifetime '65535' vyos@vyos# set service https virtual-host vyos1 listen-address '192.168.11.254' vyos@vyos# set service https virtual-host vyos1 listen-port '6443' vyos@vyos# set service https virtual-host vyos1 server-name 'vyos1.example.com' vyos@vyos# commit vyos@vyos# save vyos@vyos# exit

VyOS1.3.2-2:

vyos@vyos:~$ configure vyos@vyos# set interfaces ethernet eth0 address '192.168.21.254/24' vyos@vyos# set interfaces ethernet eth1 address '192.168.1.2/24' vyos@vyos# set service dhcp-server shared-network-name 'subnet01' vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.21.0/24' default-router '192.168.21.254' vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.21.0/24' name-server '192.168.21.254' vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.21.0/24' range 0 start '192.168.21.17' vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.21.0/24' range 0 stop '192.168.21.126' vyos@vyos# set service https api keys id my_id key 'my_secret_key' vyos@vyos# set service https certificates system-generated-certificate lifetime '65535' vyos@vyos# set service https virtual-host vyos1 listen-address '192.168.21.254' vyos@vyos# set service https virtual-host vyos1 listen-port '6443' vyos@vyos# set service https virtual-host vyos1 server-name 'vyos1.example.com' vyos@vyos# commit vyos@vyos# save vyos@vyos# exit

ちなみに、 VyOS の仮想デバイスは、一通り設定を完了させてから、仮想デバイスを複製できる。
VyOS のインストールなどの作業が 1回で済む点は便利なのだが、コピー後 MAC アドレスが変更になるため、仮想デバイス内のインターフェース名が、 eth0, eth1, eth2 から eth3, eth4, eth4 へと名前を変えてしまうことが多く、 GNS3 UI 上の NIC のインターフェース名と、仮想デバイス内の名前が一致しなくなってややこしい事になるので、ご注意を。

ネットワークの構成 2

さて、ここで各端末 (tmp-net-tools-1, -2) が DHCP サーバーに割り当てられた IP アドレスを使って、お互いに ping を打っても、当然届かず失敗する。

ここで VyControl を使って、それぞれの VyOS に静的ルーティングを定義する。

その後改めてお互いに ping を打つと、無事疎通ができるようになった。

外部との接続

さらなる応用として、 "Cloud" デバイスを使って外部機器との接続もできる。

まず、適当な物理NIC (USB LAN アダプタ) を、仮想マシン管理ツール側で GNS3 VM のネットワークアダプタに割り当てる。
その後、 GNS3 内で "Cloud" デバイスをその物理NIC に割り当ててやれば、物理ルーターと仮想ルーターとの間で、論理的なネットワークの接続を構成できる。

おわりに

…とまあ、こんなところが GNS3 の基本的な使い方となる。
慣れてきたら、不完全な VyControl なんか使わず、直接 VyOS に CUI コマンドで設定を定義してやると良いかもしれない。

長々となる解説となったが、誰かの役に立てば幸いだ。

Security patching	Ubuntu LTS	Ubuntu Pro (Infra-only)	Ubuntu Pro
Over 2,300 packages in Ubuntu Main repository	5 years	10 years	10 years
Over 23,000 packages in Ubuntu Universe repository	Best effort	Best effort	10 years
Optional phone/ticket support	No	Yes	Yes

ディストリビューション	.dsc (Debian Source Control) ファイル	ソースファイル
Debian 11 bullseye	imagemagick_6.9.11.60+dfsg-1.3+deb11u1.dsc	imagemagick_6.9.11.60+dfsg.orig.tar.xzimagemagick_6.9.11.60+dfsg-1.3+deb11u1.debian.tar.xz
Ubuntu 22.04 LTS	imagemagick_6.9.11.60+dfsg-1.3ubuntu0.22.04.3.dsc	imagemagick_6.9.11.60+dfsg.orig.tar.xzimagemagick_6.9.11.60+dfsg-1.3ubuntu0.22.04.3.debian.tar.xz
Ubuntu 22.04 esm-apps	imagemagick_6.9.11.60+dfsg-1.3ubuntu0.22.04.3+esm2.dsc ³	imagemagick_6.9.11.60+dfsg.orig.tar.xzimagemagick_6.9.11.60+dfsg-1.3ubuntu0.22.04.3+esm2.debian.tar.xz

advanceboyの投稿 - Crieit

Raspberry Pi 5 に Ubuntu 24.04 LTS を入れて SSH するまで

JavaScript で TOTP を計算する

D&DしたQRコード画像をブラウザ上でデコードする

ブラウザのタイトルや URL をコピーするブックマークレット【スマホ＆阿部寛対応】

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

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

PC Manager をオフラインやプロキシ環境下でインストールする

個人用 Clipchamp から組織ユーザーへプロジェクトを無理やり移行する

Pester v3 & v5 互換のテストコードを書く (PowerShell)

NEC IXシリーズルーターでポートVLANとタグVLANをVLANスイッチ的に併用する

Keepass2Android は Offline 版がオススメ

Ubuntu で Main リポジトリ以外のインストール済みパッケージを一覧にする

超コスパ左手デバイス SIKAI CASE を安全に設定する

ミドルGPUで35億の女(RINNA AI)のローカル実行 ことはじめ

導入手順

実行手順

補足

YAML の細かい仕様の話

[Windows] MBR パーティションの SSD を GPT へコピーする

PowerShell で中身がランダムな大きめのファイルを高速に作る

Git と OneDrive 等のクラウドストレージを併用する

.\.git ディレクトリだけ同期除外

Docker run の起動時に任意コードを実行後 bash や ash を終了しない

GNS3 に VyOS 仮想ルーターを追加する長い道のり④ 応用編

ミドルGPUで35億の女(RINNA AI)のローカル実行ことはじめ

`.\.git` ディレクトリだけ同期除外