背景

先日引っ越しをした。引っ越し先のインターネット環境は一言で言えば残念で、好きな ISP と契約することができず、マンションが包括して契約している ISP 経由でしかインターネットに接続できない。悲しいことにこの ISP は各個にグローバル IP を割り当てないので、外に向けたサーバーの公開が制限されている ^[1]。

この問題を回避するため、外部の VPS を VPN サーバーとし、ルータとの間にVPN を張ることでサーバーを公開できるようにした。外部のユーザーは、VPS に割り当てられたグローバル IP を通して、筆者の自宅内のサーバーに接続することができる。

構成

表題の通り、VPN には WireGuard を使う。高速に動作し、設定もシンプルらしい。

図 1 のように、ルーターには ISP からプライベート IP アドレス、10.167.X.Y/24 が割り当てられている。グローバル IP 203.0.113.1 が割り当てられた VPS とルーター間で 10.10.0.0/24 のサブネットで VPN を構築し、VPS に 10.10.0.1 、ルーターに 10.10.0.2 を割り当てる。VPS と ルーターのそれぞれで NAT を行い、LAN内のサーバーから公開するポートに外部から接続できるようにする。LAN 内では、ルーターに 192.168.1.1、公開するサーバーには 192.168.1.2 が割り当てられているものとする。

VPS の OS には Debian (bullseye) を使う。ルーターには OpenWRT (18.06.4) を使う。

なお、WireGuard はピアツーピア型の VPN であるため、本来どちらがサーバーであるという概念は存在しないが、便宜上 VPS 側をサーバー側と呼ぶことにする。

VPN サーバー (VPS) 側の設定

WireGuardのインストール

WireGuard をインストールする。

$ sudo apt install wireguard

鍵生成

サーバーの秘密鍵を生成する。

$ sudo wg genkey > server.key

秘密鍵から公開鍵を生成する。

$ cat server.key | sudo wg pubkey > server.pub

便宜上秘密鍵を server.key(.pub) として書き出したが、値をファイルから読むことはないので、値を控えしだいファイルを消してしまっても構わない。

同様にして、ルーター側の鍵ペアも生成する。

$ sudo wg genkey > client.key
$ cat client.key | sudo wg pubkey > client.pub

IP転送の許可

サーバー内でのIP転送を許可する。/etc/sysctl.conf を編集し、

net.ipv4.ip_forward=1

をアンコメントする。

$ sudo sysctl -p

として設定を反映させる。

設定

/etc/wireguard/[インターフェース名].conf として設定ファイルを作成する。今回は wg0 とする。内容は以下の通り。

[Interface]
ListenPort = 51820
Address = 10.10.0.1/32
PrivateKey = [生成したサーバー側の秘密鍵]
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o [WAN向きのインターフェース名] -j MASQUERADE;
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o [WAN向きのインターフェース名] -j MASQUERADE;
SaveConfig = true

[Peer]
PublicKey = [生成したルーター側の公開鍵]
AllowedIPs = 10.10.0.0/24
PersistentKeepalive = 25

各項目の意味は以下の通り。
[Interface]
サーバー側の設定。
ListenPort: WireGuard が待ち受けるポート
Address: 作成するインターフェース (wg0) に割り当てるアドレス。/32 以外にすると通信できないので注意。
PrivateKey: サーバーが利用する秘密鍵
PostUp/PostDown: インターフェースの作成後/破棄後に実行させるコマンド。IPマスカレードを行い、VPN 内から外向きの通信を WAN 側インターフェースを経由して行えるようにしている。
SaveConfig: インターフェースを破棄した際に現在の WireGuard の設定をこのファイルに書き出す。true にしていると、インターフェースを作成してから設定を変更しても、インターフェースを落とした際に設定が上書きされるので注意したい。^[2]

[Peer]
各クライアントに対する設定。複数のクライアントを設定するには、Peer セクションを複数書けば良い。
PublicKey: 接続を許可するクライアントの公開鍵
AllowedIPs: クライアントに許可する IP レンジ。0.0.0.0/0 には設定しないことを強く勧める。デフォルトゲートウェイが変更され、（SSH等でも）サーバーに接続できなくなる可能性がある。 → 参照
PersistentKeepalive: 無通信でも Keep-Alive パケットを送る間隔（秒）。NAT 越えの場合、無通信で切断されないように 25 に設定することが推奨されているようだ ^[3]。今回は NAT 越えではないが、念のために入れておいた。

ルーター側の設定

Web インターフェースにログインし、以下を行う。

必要なプラグインのインストール

上部メニューの System -> Software でソフトウェア管理ページを開き、Available Packages の中から luci-app-wireguard を探しインストールする。同様に luci-proto-wireguard もインストールする。

インターフェースの追加

Network -> Interfaces から、Add new interface... ボタンをクリックしてインターフェースを追加する。以下の通り設定する。

• Name of the new interface: 追加するインターフェース名（wg0とする）を入力する。
• Protocol of the new interface: WireGuard VPN

インターフェースの設定画面が開く。以下の通り設定する。

• Private Key: 前のステップで生成したクライアント秘密鍵
• Listen Port: 51820
• IP Address: このルーターに割り当てる VPN 内の IP、10.10.0.2 を入力する。

Peers セクションの Add ボタンをクリックして、ピアを追加する。これはクライアントから見たピアなので、つまりサーバーのこと。

• Public Key: 前のステップで生成したサーバー公開鍵
• Allowed IPs: サーバー側に許可される IP レンジを入力する。すなわち 10.10.0.1/24
• Route Allowed IPs: 有効にする
• Endpoint Host / Port: サーバーの WAN 側 IP とポート番号を入力する。203.0.113.1 および 51820 とする。
• Persistent Keep Alive: 有効にする。

こちらから接続に行くのに、接続に行った先が許可される IP レンジを指定するというのも妙な話だが、上でも書いたようにピアツーピア型の VPN であるためだ。

上のタブから Firewall Settings を開く。

• Create / Assign firewall-zone: wan にする。^[4]

Save & Apply ボタンを押して反映する。

接続の確認

ここまでで VPS とルータ間で接続が確立できているはずだ。Network -> Interface で、追加した wg0 がアクティブになったことや（図2）、Status -> Wireguard Status で Peer が表示され、Latest Handshake が直近の日次になっていることを確認する（図3）。また、VPS と ルーター、互いに VPN 内 IP で ping が通ることを確認する。

インターフェース一覧で wg0 にエラーが表示されている場合、Restart ボタンでインターフェースを再起動したり、ルーター本体を再起動すると直るかもしれない。

VPS 側でも

sudo wg

とすることで状態を確認できる。

ポートフォワードの設定

本記事の目的は、外部のユーザーが LAN 内のサーバーに接続できるようにすることである。つまり、ポートフォワードを設定しなければならない。今回の構成では、ルーター側で行う通常のポートフォワードに加え、最初に接続を受ける VPS 側でもポートフォワードを設定する必要がある。

VPS 側でのポートフォワードの設定

iptables で淡々とルールを追加する。例えば、TCP 80 に来た通信を LAN　内のサーバーで受け取れるようにするには、

$ sudo iptables -t nat -A PREROUTING -i [WAN向きのインターフェース名] -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.10.0.2;
$ sudo iptables -t nat -A POSTROUTING -m tcp -p tcp --dst 10.10.0.2 --dport 80 -j SNAT --to-source 10.10.0.1;

とする。上記のルールが VPN 生成/破棄時に自動で設定/削除されるように、wg0.conf のPostUp / PostDown に追加しておくと良い。直接書くと見づらいので、以下のような内容で /etc/wireguard/wg0-up.sh と /etc/wireguard/wg0-down.sh というファイルを作り、

wg0-up.sh

#!/bin/bash

iptables -t nat -A PREROUTING -i [WAN向きのインターフェース名] -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.10.0.2;
iptables -t nat -A POSTROUTING -m tcp -p tcp --dst 10.10.0.2 --dport 80 -j SNAT --to-source 10.10.0.1;

wg0-up.sh

#!/bin/bash

iptables -t nat -D PREROUTING -i [WAN向きのインターフェース名] -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.10.0.2;
iptables -t nat -D POSTROUTING -m tcp -p tcp --dst 10.10.0.2 --dport 80 -j SNAT --to-source 10.10.0.1;

PostUp / PostDown で実行されるようにした。

wg0.conf

[Interface]
...
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o [WAN向きのインターフェース名] -j MASQUERADE; /etc/wireguard/wg0-up.sh
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o [WAN向きのインターフェース名] -j MASQUERADE; /etc/wireguard/wg0-down.sh
...

ルーター側でのポートフォワードの設定

Network -> Firewall 内の Port Forwards タブから設定できる。上記の HTTP を転送する例であれば、

• Protocol: TCP
• External Zone: wan
• External Port: 80
• Internal Zone: lan
• Internal IP Address: 192.168.1.2
• Internal Port: 80

上記のようなフォワードルールを作成する。図4. に作成した後の画面を示す。

まとめ

本記事では、Wireguard を使って VPS と OpenWRT 間で拠点間 VPN を構築し、グローバル IP が与えられない環境下で外部向けにサーバーを公開する方法を説明した。Wireguard は初めて使ったが、設定ファイルがとても簡素で分かりやすく、またハマりそうな要素も少なく、必要最低限の VPN を構築するには便利だと感じた。

1月前から Chia ブロックチェーンのファーミングを行っているが、先日ようやくファーミングに成功した。Chia 自体についての詳細は前記事を参照されたい。

報酬として獲得できるネイティブトークン XCH のうち一部を売却して USDT に換金した。複数の取引所を試したのでそれぞれの比較をメモしておく。

以下は 2021 年 5 月 14 日の情報に基づく。それぞれの取引所で、1) XCH の入金、2) XCH 売り USDT 買いの取引、3) USDT の Binance への送付を試した。以下の全ての取引所で、TRX20 ネットワークでの USDT 送金がサポートされていた。出金手数料は TRX20 を利用した場合の手数料だ。

OKEX

• 最低出金額: 2USDT (Feeを除外して)
• 出金手数料: 1USDT
• 100USD相当入金+100USD相当の取引をすると80USDT分の取引手数料（出金手数料に使えるかは不明）に充当できるクーポンがもらえる。
  流動性がある。価格が安い。Googleアカウントで登録できて楽。出金パスワードを設定しないといけないのがちょっとめんどくさい（セキュリティ的には良いけど）。全体的にUXは良い気がする。とりあえず100USDはKYC無しで出金できた。上限不明

MXC.com

• 最低出金額: 30USDT
• 出金手数料: 1USDT
  流動性は低めだけどちょこちょこ売る分には大丈夫では。メール認証が時々到着遅いときがある（1分ほど待てばちゃんと来るけど）。0.7BTC/日まではKYC無しで出金できる。

Gate.io

• 最低出金額: 300USDT (!!)
• 出金手数料: 0USDT
  流動性はMXCと同じぐらい。10USDT ほど換金したものの、最低出金額が 300 USDT だったので怖いので出金は試さずそのまま放置している。他の通貨建てでも最低出金額が10000円相当だったりでクソ。パスポートと自撮り送ってのKYCを済ませないと出金できないような雰囲気があるけど不明...。

XT.com
XCHの入金ができなかった。

5 月 14 日時点では取引所間の価格が大きく、OKEX が　MXC や Gate.io に比べて安かったのだが、現在はほとんど変わらなくなっている（むしろ執筆時点では OKEX がやや高い）。現在は Huobi での取り扱いもされているので、Huobi も良いかもしれない（名前は時々聞くので）。

背景と概要

ここ 1 ヶ月ほど、ブロックチェーン Chia のファーミング ^[1] を試している。Chia は Proof of Space and Time (PoST) というコンセンサスアルゴリズムを用いたブロックチェーンだ。このコンセンサスアルゴリズムでは、Proof of Work (PoW) におけるハッシュ計算にあたる作業を事前に大量に行い plot と呼ばれるデータを作成し、実際のブロック検証（ファーミング）時には作成した plot 中から正解に近いデータを提出するという形で検証が行われる。plot はいわゆるレインボーテーブルのようなものだ。

plot の作成にはそれなりに計算負荷と時間がかかるが、一度作った plot を使ってファーミングを行うのはほぼ負荷なく行うことができるため、環境にやさしいとされている。

当然ながら、plot を多く作成すればするほど、その plot に含まれるデータを使ってブロックを検証できる機会が多くなるため、収益を上げるためには多くの plot を作り、それを保持することが重要になる。ここで問題になるのは HDD の管理だ。作った plot で既存の HDD が埋まるたびに買い足していく（現在、1 日あたり 8 plot ほど作成できている。これは約 800 GB に相当するので、10日で8TBの HDD が埋まる計算になる）ことになる。

plot を作り続けるたびに物理的に増え続ける HDD をいかに容易に管理するかが問題となった。これを検討した結果、MergerFS が適していたのでその概要と使い方を説明する。

要件

Chia における plot 保存用 ストレージ に求められることとして、以下の要件を検討した結果、MergerFS を使うことにした。

1. 複数の物理的なストレージを束ねて1つのストレージとして管理したい。
   HDD を買い足して接続するたびに、その HDD を plot の読み取り先や作成先として指定するのは手間だ。特に、plot の作成が大変で、現在のバージョンでは plot 作成の一時停止を行うことができない（中止すると作成中の plot が最初から作り直しになってしまう）ため、plot の作成完了を待ってから書き込み先を変更すればならず、厄介だ。

2. 障害が起こったときの影響範囲を局所化したい。
   例えば RAID-0 では複数のHDDを束ねることができるが、1つのHDDが壊れただけで全てのデータが読み取れなくなってしまう。これで全ての plot が壊れるとさすがにもったいないので、もし HDD が壊れても、その HDD にあるデータの損害だけですませたい。

3. 一方で、容量の効率を重視したいので、ミラーやパリティによる耐障害性の確保はしたくない。

4. 簡単にストレージを追加したい。
   貴重な収益機会を失いたくないため、新しいストレージを追加する場合でも、手軽に、かつダウンタイムをほぼ無くストレージを追加したい。

5. ** NFS で公開して他のマシンから rsync で plot をコピーできるようにしたい。**
   複数台の Linux マシンで plot を生成しているので、各マシンからはストレージを NFS でマウントして、生成した plot を rsync できるようにしたい。（これは要件としてあげるまでもないと考えていたが、結果的に MergerFS の利用を決定づけるものになった。後述する。）

MergerFS

MergerFS はこの用途に最適だった。指定された複数のディレクトリを結合したビューを持つファイルシステムを作成するものだ。例えば /mnt/a と /mnt/b を結合して /mnt/x というファイルシステムを作ったとする。この時、/mnt/a/a.txt、/mnt/b/b.txt という 2 つのファイルがあったとすれば、これらは/mnt/x/a.txt、/mnt/x/b.txt のように見える。サブディレクトリがあっても問題なく動き、また書き込みも行えて、結合したディレクトリに書き込みを行うと、結合元のディレクトリのいずれかに実体が書き込まれる。

ストレージが壊れた場合でも、MergerFS が提供しているのはただの結合したビューでしかないため、壊れたストレージに存在したファイルにアクセスできなくなるだけですむ。また、容量的なオーバーヘッドもない。

$ cd /mnt/merged # /mnt/a と /mnt/b をマージしたディレクトリを /mnt/merged とする
$ sudo xattr -w user.mergerfs.branches '+</mnt/c' ./.mergerfs

として、マージされたディレクトリのルートに存在する仮想的なファイルに対して拡張属性をセットすることでオンラインでのディスクの追加や削除ができる。

似たような、複数のディレクトリを束ねたビューを提供するファイルシステムとして、古くから mhddfs がある。MergerFS が優れている点はいくつかあるが、個人的に大きかった点を2点上げると、1つは上述したようにオンラインでのディスク追加や削除ができることだ。もう1つは、束ねたディレクトリに対して NFS 越しに rsync でファイルをコピーしても問題が起こらないことだ。（＝要件5）

mhddfs で作成したディレクトリを NFS で公開して、そこに対して rsync を行うと、ESTALL が発生し正しくファイルをコピーできないことがある。この問題^[2]は、正確には mhddfs ではなく fuse の問題であるのだが、同じく fuse でマウントされる MergerFS はこの問題を解決するためのオプションが用意されている。そこで、最終的に MergerFS を利用することにした。

MergerFS のインストールと使い方

Debian 10 (buster) の環境にインストールした。まだ apt によるインストールはできないが、MergerFS のリリースページには .deb ファイルが用意されているのでこれを利用できる。

$ curl -LO https://github.com/trapexit/mergerfs/releases/download/2.32.4/mergerfs_2.32.4.debian-buster_amd64.deb # バージョン、ディストリビューションとアーキテクチャは適宜読み替えること
$ sudo dpkg -i ./mergerfs_2.32.4.debian-buster_amd64.deb

以上でインストールができる。インストールした後は、以下のようにマウントする。

$ sudo mount -t fuse.mergerfs -o defaults,allow_other,use_ino,cache.files=partial,dropcacheonclose=true,category.create=mfs /mnt/a:/mnt:b /mnt/merged

以上で、/mnt/a と /mnt/b' をマージしたディレクトリが /mnt/merged にマウントされる。オプションは少し長いが、とりあえず default,allow_other を付けておけば動作するが、公式のドキュメント BASIC SETUP の "You need mmap" にならった。

NFS を通して公開したい場合に不都合無く動作させるためには、もう少しオプションを足す必要がある。NFS clients returning ESTALE / Stale file handle のところに書いてあるよう、noforget,use_ino,inodecalc=path-hash のオプションを加える。以下のようになる。

$ sudo mount -t fuse.mergerfs -o defaults,allow_other,use_ino,cache.files=partial,dropcacheonclose=true,category.create=mfs,nonempty,noforget,inodecalc=path-hash /mnt/a:/mnt:b /mnt/merged

起動時に自動でマウントするためには

/mnt/a:/mnt/b       /mnt/merged      fuse.mergerfs   defaults,allow_other,use_ino,cache.files=partial,dropcacheonclose=true,category.create=mfs,nonempty,noforget,inodecalc=path-hash      0       0

のような行を /etc/fstab に加えれば良い。

まとめ

本記事では、Chia の plot を保存するために、複数台のストレージを、MergerFS を使って束ねると管理しやすいことを説明し、その設定方法について述べた。現在のところ上手く動いているのでChia の ファーミングを行っている人は検討すると良いかもしれない。Chia のせいでストレージが手に入りずらくなっているのはマジでクソ。

以前の記事で書いたように、自宅のサーバー上で録画環境を構築している。このサーバーでは、番組の録画が完了すると、録画した TS ファイルを h.264 の MP4 ファイルにエンコードして別のディレクトリに保存するようなスクリプトを動かしている。元の TS ファイルもそのまま保持していたのだが、最近ストレージ容量が厳しくなってきたので、エンコード済みの TS ファイルを削除しようと思い立った。

問題は、エンコードが正しく終了せず破損した MP4 ファイルがいくつか存在することだ。これらのファイルについては元の TS ファイルを残しておきたい。そこで、大量のファイルの中から破損したファイルを高速に検出する方法を調べた。

調べた結果、以下のようにするのが良さそうだ。(ffprobe コマンドは ffmpeg をインストールするとインストールされる）

$ ffprobe -v error -f lavfi movie="/path/to/file.mp4" 2>&1 | grep lavfi;

まずパイプ前段の ffprobe がエラーを検出し、検出したエラーを標準エラー出力に書き出してくれる。例えばエラーがあると（ffprove 自体の出力は）以下のようになる。

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x5654a3bb3400] moov atom not found
[Parsed_movie_0 @ 0x5654a3bb2e80] Failed to avformat_open_input '/path/to/file.mp4'
[lavfi @ 0x5654a3bb1000] Error initializing filter 'movie' with args '/path/to/file.mp4'
movie=/path/to/file.mp4: Invalid data found when processing input

筆者が持っているファイル群では、正常にエンコードされたファイルでもなぜか音声にエラーが検出され

[aac @ 0x55a600a76380] Reserved bit set.
[aac @ 0x55a600a76380] Number of bands (4) exceeds limit (2).

のように表示された。このような出力は正常なものと見なしたかったため、標準出力にリダイレクトした上で lavfi からのエラーを grep で拾うようにしている。grep の出力や終了コードを確認することで、与えたファイルが壊れているかどうかを判断できる。

上記をもとに、大量のファイルを処理する例としては以下のようになる。

$ ls /path/to/movie_dir |\
  xargs -I@ bash -c '
    fn="@";
    if (ffprobe -v error -f lavfi movie="$fn" 2>&1 | grep lavfi) >/dev/null; then
      echo @ is corrupted;
    else
      echo @ is safe;
    fi
  '

上記のスクリプトは、指定されたディレクトリ内のファイルを全て調べ、壊れていた場合は

{{ filename }} is corrupt

壊れていない場合は

{{ filename }} is safe

と表示する。

上記の検査方法により、無事、正常にエンコードできたファイルの元 TS ファイルだけを削除することができた。これで壊れていると判断されたファイルは実際に VLC で再生できないことを確認できた。一方で正常とされたファイルについて（数が多いので）全てを確認できていないので、実は壊れているものが含まれている可能性もあるが、そこは...そんなことがなかったことを祈りたい...。

調べる方法としては、他にも ffmpeg を使って

$ ffmpeg -v error -i "/path/to/file.mp4" -f null -;

とする方法もあるようだが、こちらは全フレームを見て検査するようで結構時間がかかる。ただ、その分より正確に壊れたファイルを検出できそうだ。

参考にしたサイト

How can I tell if a video file is corrupted? FFmpeg? - Stack Overflow

ZFS で作成した ZVOL のサイズが足りなくなり拡張するという作業を数年に一度行っているが、毎回やり方をググっているのでメモを兼ねて書く。ZVOL を拡張しても、内部のパーティション（ext4 を想定）も拡張しないと、実際に使用可能な容量は増えないのでこちらも拡張する。

なお、ここでは内部にパーティションが1つしか無いことを想定している。複数ある場合、末尾のパーティションは簡単に拡張できる (partedで指定するパーティション番号を変更するだけ）が、それ以外は大変なはず.....。

（作業前にスナップショットを取っておくと安心）

$ sudo zfs snapshot pool0/vol0@before_expand

作業前にアンマウントすること！

$ sudo umount /mnt/path/of/where/volume/is/mounted

まず ZVOL を拡張する。

$ sudo zfs set volsize=1200G pool0/vol0
$ sudo zfs get volsize pool0/vol0 # 増えたことを確認する
NAME           PROPERTY  VALUE    SOURCE
pool0/vm/vol0  volsize   1.17T    local

ディスクサイズが増えたことで GPT テーブル情報が実際のディスクと一致しなくなるのでこれを修正し、さらにパーティションをリサイズする。

$ sudo parted /dev/zvol/pool0/vol0
Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra *** blocks) or continue with the current setting?
Fix/Ignore? Fix

parted でボリュームを開いた時にエラーが検出され、 Fix するかとのメッセージが出るので Fix と打つ。そのまま続けて p でパーティションを確認する。

(parted) p
Model: Unknown (unknown)
Disk /dev/zd192: 1288GB
Sector size (logical/physical): 512B/8192B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name  Flags
 1      1049kB  800GB  800GB  ext4

resizepart で1番目のパーティションをディスクの100%の位置まで拡張する。

(parted) resizepart 1 100%
(parted) p
Model: Unknown (unknown)
Disk /dev/zd192: 1288GB
Sector size (logical/physical): 512B/8192B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  1288GB  1288GB  ext4

parted を終了し、e2fsck でパーティションのエラーを確認する（resize2fs のために必要）

$ sudo e2fsck -f /dev/zvol/pool0/vol0-part1
... （終わるまでしばらく待つ）

最後に resize2fs で増えた分の領域を認識させる

$ sudo resize2fs /dev/zvol/pool0/vol0-part1

終わり。一応最後にまた e2fsck した方が良いかもしれない。

parted の代わりに fdisk でリサイズする方法もあるが、（たぶん）GPT テーブルの修正はできないし、パーティションを一度消す→開始位置が同じで終了位置が違うパーティションを再作成というオペレーションになるためちょっと怖いので parted を使った方が良いと思う。

参考にしたサイト

• Resizing Zvol | TrueNAS Community
• mastodonサーバのSSDを大容量の物に変更しました。（Linuxの大容量SSDへの移行） | tsukiyono.blue
• 【Linux】 partedでパーティションの拡張 - takafumi blog

最近は猫も杓子も Non Fungible Token (NFT) の話をしていて、道ばたの猫もﾆｬｰﾝﾌｧﾝｼﾞﾌﾞﾙﾄｰｸﾝと鳴いていた。NFT ブームの火付け役は恐らく NBA Top Shot だろう。

NBA Top Shot は Flow ブロックチェーン 上にデプロイされたコントラクトによって実現されている。この記事では Flow メインネットから Flow JavaScript SDK を使ってデータを取得する方法について述べる。

データを取得する方法にも、ブロックやトランザクションを直接指定して記録されたデータを読む方法や、コントラクトが発火させるイベントを取得する方法などいくつかがあるが、ここでは Script を実行してデータを取得する。Script とは、Cadence 言語で書かれたコードのうち、ブロックチェーンの状態を変化させないものを指す。これを使うと、例えば コントラクトが公開する関数のうち、単に値を返却するようなものを実行し、その結果を取得できる ^[1]。ガス代もかからない。

Cadence の詳細については公式の Cadence チュートリアルに詳しいが、実際にメインネット上でどうやってスクリプトを実行するかが書かれた記事が少なく、一方で公式のFlow App Quickstart では Web アプリを1つチュートリアルとして作るということで大きすぎるため、本記事で Script を動かすという点に絞って説明する。

@onflow/fcl と、 @onflow/types の2つのパッケージが必要なのでインストールしておく。

$ npm install --save @onflow/fcl @onflow/types

まずは単純な例として、足し算を行う Script を実行する例を示す。

const fcl = require('@onflow/fcl');

(async () => {
  fcl.config()
      .put("accessNode.api", 'https://access-mainnet-beta.onflow.org')

  const resp = await fcl.send([
    fcl.script(`
      pub fun main(): Int {
        return 1 + 2;
      }
    `)
  ]);
  
  const result = await fcl.decode(res);
  console.log(result)
})();

上記のコードを実行すると、

3

と表示されるはずだ。

見て分かるように、fcl.script() 内に実行したい Script を記述し、fcl.send() に配列の要素として渡せば良い。返り値は fcl.decode() でデコードする必要がある。これらの関数の使い方の例は、実は @onflow/types の使い方のページに一覧がある。

重要なのは、fcl.config() 以下を通して設定する API のエンドポイントだ。 公式の Flow App Quickstart にはテストネットのための設定は書いてあるが、メインネットの設定は書かれていない。ググるとFlow Japan Community の記事が出てきて、https://access-mainnet-beta.onflow.org を指定すれば良いことが分かる。 ^[2]

main() に引数を渡したい場合は、fcl.send() に渡す配列の2つめに、fcl.args() で生成した引数オブジェクトを渡せば良い。各引数は fcl.arg(1, types.Int) のように型を指定してラップする必要がある。以下のような例となる。

const fcl = require('@onflow/fcl');

(async () => {
  fcl.config()
      .put("accessNode.api", 'https://access-mainnet-beta.onflow.org');

  const resp = await fcl.send([
    fcl.script(`
      import TopShot from 0x0b2a3299cc857e29

      pub fun main(a: Int, b: Int): Int {
        return a + b;
      }
    `),
    fcl.args([
      fcl.arg(1, types.Int),
      fcl.arg(2, types.Int)
    ])
  ]);
  
  const result = await fcl.decode(resp);
  console.log(result);
})();

そろそろ、コントラクトと対話して実際にブロックチェーン上のデータを参照してみたい。今回は Top Shot のコントラクトに定義された getPlayMetaData(playID: UInt32) を呼び、指定された Play ^[3] が持つメタデータを取得してみたい。

const fcl = require('@onflow/fcl');

(async () => {
  fcl.config()
  .put("accessNode.api", 'https://access-mainnet-beta.onflow.org');

  const resp = await fcl.send([
    fcl.script(`
      import TopShot from 0x0b2a3299cc857e29

      pub fun main(): {String: String}? {
        let metadata = TopShot.getPlayMetaData(playID: 42);
        return metadata;
      }
    `)
  ]);
  
  const result = await fcl.decode(resp);
  console.log(result);
})();

上記では、playID = 42 である Play のメタデータを取得している。結果は以下のようになった。

{
  FullName: 'Lonnie Walker',
  FirstName: 'Lonnie',
  LastName: 'Walker',
  Birthdate: '1998-12-14',
  Birthplace: 'Reading, PA, USA',
  JerseyNumber: '1',
  DraftTeam: 'San Antonio Spurs',
  DraftYear: '2018',
  DraftSelection: '18',
  DraftRound: '1',
  TeamAtMomentNBAID: '1610612759',
  TeamAtMoment: 'San Antonio Spurs',
  PrimaryPosition: 'SG',
  PlayerPosition: 'GF',
  Height: '77',
  Weight: '204',
  TotalYearsExperience: '1',
  NbaSeason: '2019-20',
  DateOfMoment: '2019-12-04 01:30:00 +0000 UTC',
  PlayCategory: '3 Pointer',
  PlayType: '3 Pointer',
  HomeTeamName: 'San Antonio Spurs',
  AwayTeamName: 'Houston Rockets',
  HomeTeamScore: '135',
  AwayTeamScore: '133'
}

結果から、Top Shot では一つ一つの Play をどのようにブロックチェーン上で表現しているかが分かる。画像や動画のハッシュはおろか、URL や パス、ファイル名すら書き込まれていない点は気にしておいても良いかもしれない。

なお、

import TopShot from 0x0b2a3299cc857e29

この行について、どうやって TopShot のコントラクトがデプロイされたアドレスをするかという点だが、Flowscan で適当にいくつかトランザクションを漁ると Top Shot 関連のトランザクションを見つけることができ、それらのトランザクションの Event 欄を見ると、Event を発行したコントラクトを知ることができた。コントラクトのページに飛べばコントラクト自体のソースを見ることもできる。なお、Top Shot の全てのコントラクトは GitHub 上で公開されている ^[4]。

本記事では、Flow JavaScript SDK で Script を実行し、メインネットから情報を取得する方法について書いた。Flow には Go SDK と JavaScript SDK があるが、Go SDK については公式のドキュメントも充実しておりその他の情報も多く見つかるが、JavaScript SDK については情報が少なく少し苦労した。

@onflow/fcl はブラウザでも動き、これを使って Flow を使った Web アプリも作れるようだ（メインネットに対してトランザクションを投げるためには Dapper Labs からアクセス権をもらわないといけないようだが）。本記事の情報が参考になると嬉しい。

読む前に

この記事は、Among Us というゲームに関する記事であり、読者は本ゲーム及び人狼ゲームとされるゲーム類に関する基本的な知識があることを想定して書かれている。そのため、用語に関する詳細な説明はしない。

主張

Among Us において、エマージェンシークールタイムは、キルクールタイムより長くした方が良い。これは、クルーメイトらがローラーを選択するリスクを引き上げ、ローラーを行う場合でもローラーの順序について熟慮するインセンティブを与える。この設定は、結果としてゲームの持続的な面白さに貢献する。

emerg CD > kill CD だと、ローラーで先に白が吊られたときに、サボタージュとか駆使して対抗の黒が最後に必死の1キルをできるということです。https://t.co/HjQtEklB0Z

— 謹慎中 (@mecab) January 25, 2021

オリジナルの人狼はローラー別に良い（仕方ない）と思うんですけど、among us は among us なのでローラーし辛いほうが良いと思う。ローラー前にキャラコン次第でキル取るチャンスが与えると、アクションゲーム要素が光ると思ってる（現状ping高いのでアクションゲームとしてクソという話はある）

— 謹慎中 (@mecab) January 25, 2021

提案する設定によって期待されること

Among Usの仕様上、ローラーを行うためには1人目を追放した後に、2人目を追放するために、誰かが非常ボタンを押して会議を行う必要がある。この時、エマージェンシークールタイムがキルクールタイムより長ければ、インポスターはエマージェンシーボタンを押す前にサボタージュを駆使しながら、その間にキルを行えるチャンスも出てくる。

これは特にローラー対象が、実際に1人クルーメイト、1人インポスターだったときに大きく影響する。例えば、不幸にも先に追放されたのがクルーメイトだった場合、次に追放される予定のインポスターは身バレ覚悟で積極的にキルを狙うことができる。

以上のことから、提案する設定はローラーを実行することについてリスクを与え、またローラーを行う場合でも、追放順番に関する議論を慎重に行うようにさせる。

インポスターにおけるローラーについて

Among Usにおいて、ローラーが発生しやすいのは、キルする瞬間を他の1人のみに目撃され、お互い「あいつがヤった」と押しつけあっている状況においてだろう。

この状況でのローラーはかなり強力で、確実に1人のインポスターを追放することができる。また、味方のインポスターとしても、1人のクルーメイトが「確実に見た」と言っている以上、ローラー提案に異を唱えづらい。

特に多人数のプレイではこの影響は大きい。例えば10人中インポスター2人構成のゲームで、開始直ぐにインポスターが殺害現場を見られてしまい上記のローラーになった場合、8人中インポスター1人構成のゲームとなってしまい、クルーメイトがとても優勢になってしまう。言い方を変えると、「10人中インポスター2人」のゲームは、序盤に殺害現場を見られるだけで、実質的に「8人中インポスター1人」と化すのだ。

「見られるようにキルをするプレイヤーが悪い」という話はあるだろうし、それはもっともなのだが、その時点でクルーメイト勝利がほぼ確定となると、この状態が起こった時点でゲームがつまらなくなったと感じるプレイヤーも出てくるのではないかと思う。また、ゲームの起点として、リスクを取った行動をせざるを得ないインポスターに対して、最初の殺害を失敗した場合のハザードとしては大きすぎる気がする。人間誰しもミスはあるし、pingの問題もある ^[1]。

そこで、エマージェンシークールタイムを、キルクールタイムやサボタージュクールダウンよりも長くすることで、疑われたインポスターにローラー避けのチャンスを与えるのがいいのではないかと考える。

ローラーという戦術は、味方も犠牲にしながら確実に敵を吊ることができるということで、ある意味で思考停止しているといえる。これは実際にオリジナルの人狼ゲームのプレイヤーでも主張していたり、同様の理由でローラーが嫌いという人がいる^[2]。個人的には、思考停止した戦術であるとはいえ、人狼ゲームにおいては仕方ない、あるいは必要悪といえる部分だと思う。なぜなら、自分の役職以外については、確実に信じられるものは少ないか、かなり限られているからだ。その中で、リスクをとりながら確実に得られる物を得る戦略が必要になるのは分かる。狼に加えて凶人が居ることを考えるとなおさらだ。また、人狼の場合は人外がまだミスリードを誘うローラーを提案したり、議論を反らせてローラーを回避する余地もあるように思う。

しかし、このゲームはあくまでAmong Us というゲームであって、人狼ゲームではない^[3]。クルーメイトは、各々自由に動き回り他の人の位置や、細かい動きを伺う機会もある。その点から、戦術としてローラを選ぶにしても、どちらを先に追放するかという議論はより慎重なものとなった方が良いように思う。提案する設定を行っても、ローラーで追放する順番を間違えなければ大きな問題とはならないのだ。また、サボタージュを繰り出すタイミングやどのサボタージュを行うかといった駆け引きや、サボタージュにどのように対応し、疑わしいクルーからどう距離を取るかといったキャラコン ^[4]。これが Among Us のアクションゲームとしての面白さであり、プレイの幅を広げていると思う。 インポスターにより、誰かが2度目のボタンを押すことを妨害できるようにすることは、より Among Us の面白さを引き出し、長期的な楽しさに貢献すると私は信じている。

ちょうど、非常ボタンは極力使うなと主張する記事を見つけた。

【Among us】エマージェンシー押すな押すな押すなあああああああ : ハラミホホミラハ

エマージェンシーは押すべき時に押すんだ。　それ以外は押さないほうが面白いんだ。　エマージェンシー押しまくるゲームは長くなるしつまらない。

ハラミホホミラハ

理詰めで推理するのが好きな人もいる（私はその側）し、全員で一部屋ずつ回ろうという主張に対しては、サボタージュで妨害できるから全てに同意するわけではないのだが、「キルクールタイムまでの時間稼ぎに使われがち」 「ゲームの起点となるインポスターには優しくしたほうがいい」 という点は同意したい。この人はエマージェンシークールタイムがキルクールタイムより短い環境で遊ぶことが多いとのことだが、本記事で提案するようにクールタイムの長短を逆にするとバランスが取れると思うのだがどうだろうか。

制限

• 上記はある程度慣れたプレイヤーがボイスチャットを行いながらプレイをする場合について検討している。野良でのテキストチャットでのプレイはまるで別ゲームなので参考にならないと思う。
• この設定は、当然ながらインポスターを有利にする。が、ここでの主張は各クールタイムの設定によりローラーをしづらくした方が良いということで、インポスターはもっと有利な方が良いということではなく、インポスターの勝率がどうであるべきかということではないことに注意されたい。提案する設定でインポスターが有利になった分は、他のパラメータ（例: タスク数）を変更して補正できるのではないかと思う。
• ここまで熱く書いていながらだが、正直上記のような設定でのプレイはほとんどできていないため実際のところどうなのか分からない。感想教えてください。あと Among Us 誘ってください...。(´·ω·`)

この記事は実は2021年1月5日に書いている。が、2020年12月31日として公開する。だってそっちのほうがそれっぽいじゃん。

2020年は新型コロナウィルス感染症、通称コロナが流行った年だった。1月末頃は中国で新しいウィルスが流行っているんだってー。こわいねー。ぐらいのノリだったのが、3月末にはもう世界中で大騒ぎになっていて、怒濤の速さで物事がすすんだように思う。

トイレットペーパーが品切れになりつつあるらしいという話を Twitter で見て、そっかーと思っていたらすでに自分の周りでも品切れになっていて買えなかったり ^[1]、わずか数日で株価が急落して含み損がすごいことになったと思ったら、その後年末に向けて値を戻すどころか、コロナ以前の水準まで上がってびっくりしたりした^[2]。あと、原油の先物価格がマイナスになったのは面白かった。記念スクショを撮った。しかし、1年間コロナが収束する気配はなく、実体経済もボロボロになっているはずなのに、金融緩和のせいか株価だけが上がり続けるのは健全でないような気がして怖い。経済ガチ勢ではないので本当に健全でないのかは分からないのだが、直感的に。

労働環境でも大きな変化があった。基本的に仕事は在宅勤務が推奨（時期によっては強制）されるようになった。元々 VPN 環境が整備されていて Zoom も導入されているにもかかわらず、在宅勤務は特段の事情がないと認められなかった^[3]会社だったが、ほとんどの人が在宅で仕事をするようになった。僕は朝が苦手な上に、通勤が1時間半ほどかかるようなところに住んでいるので、これはとてもありがたかった。在宅勤務、基本的には良いと思うけど（特にコード書くだけの日とか）、企画を出すような段階だとちょっとつらそうな気もする。こればっかりは対面でワイワイやったほうがやりやすい気がする。

オンラインの PC ゲームを遊んでいたし、配信もやっていたこともあり、マイクやカメラ、ヘッドホンの環境はもともと整っていたので、特に在宅勤務のために家の環境を整える必要は無くて都合がよかった。調子に乗って HDMI キャプチャを買って、ミラーレスカメラを繋いで高画質 Zoom をやったりとか、 V カツと OBS を組み合わせてアバターで Zoom とか遊んでみたりしていたが、最近は飽きて普通に Web カムで Zoom している。Logicool BRIO は高いけど良い Web カムです。

俺もブームに乗って意識高い高い高画質Zoom環境整えたので月曜からの会議が楽しみだ pic.twitter.com/aobXDhflr5

— 謹慎中 (@mecab) May 16, 2020

異動した理由としては、お金の香りがすること（これは冗談）と、昔趣味でマイニングプールを運営したことがあって、その頃からブロックチェーンは面白いなあと感じていたことがある。また、以前に一度、研修という形で、北アイルランドの開発拠点で数ヶ月働かせてもらったことがあり、そのときに環境が気に入ったということもある。一体いつ行けるのか...。（2回目）

以前の部署では国際会議に投稿したり、社内外のイベントでデモを展示するようなことを時々やっていたが、そのような機会が無くなってしまうのは残念かもしれない。これまでは出した論文とか、会議やイベントに行ったときの写真とかを見直せばどういう仕事をしてきたかを振り返れたが、これからはやったことを意識して記録に残しておかないと忘れてしまうのでブログ書くなり、外に出せないことは個人的なメモに書くなり何か記録しておこうと思う。まぁ自由度は高い部署ではあるはずなので、ブロックチェーンをネタに研究とかできたらいいなぁ。

5月に部署移動してから、プライベートブロックチェーンを使ったとあるサービスの開発を手伝い、とりあえず社内向けに試験公開ができた。とりあえずはまずまずのパフォーマンスが出せたかなということで今後も頑張りたい。

2020年後半では家を買いたい気持ちになり、家を探していた。自分の周りでも家を買う人が出てくる歳になり、買うことを考え始めたのが2年ほど前だが、都内の物件の価格は上がり続ける一方で二の足を踏んでいた。コロナの影響でほとんどの金融商品の価格が落ちた後、不動産の価格も下がるのではないかと期待したのだが、夏頃にはREIT含め多くの指数が値を戻したのを見て、これはもう下がらないなと思った。さらに、コロナが落ち着いて海外赴任し、それから帰国してから家を買うとなると、既に手が出ないような価格になっているのではないかという恐怖感もあり、秋頃に本腰を入れて家を探し始めた。

人生で1度はタワーマンションでウェイウェイしてみたいなという気持ちがあったので、1年半ほど前から、ほぼ郊外みたいなところのタワマンに賃貸で入っていた。家賃も高いし半分ネタみたいな感じですぐに出ようと思っていたが、予想以上に住み心地が良かったためタワマンを買うことにした^[4]。特に良いなと思ったところは、ディスポーザー、眺望、各階ゴミ捨て場、かっこいい共用部だ ^[5]。特にディスポーザー。料理をするときに三角コーナーの処理しなくていいのは快適だ。

そして、現在気になっている部分として、駅から遠いのと、都心から離れているため電車もちょっと不便ということがあった。住んだ当初はそのうち慣れるだろうと思ったが、通勤は案外つらかった^[6]。そこで、これらの点を考慮して、もう少し都心に寄った（本当の都心はさすがに高すぎて買えない；；；）、駅近の新築物件を契約した。駅近なのは、賃貸に出したり、将来売却する際にも大きくプラスになるようだ。一時的に日本を離れたりする可能性があることも考えると、このあたりは大事だった。新築にはこだわっていなかったので、中古も見ていたのだが、緊急事態宣言が解除された頃から住宅の需要が高まり全体的に値上がりしたようで、この値段で買うなら新築でいいなという感じになったので、結果的に新築になった。

ちょっと無理をしたローンを組んだ自覚はあるが、極端な価格崩壊が起こらなければ、5年ほど住めば残債割れせず、最悪の場合でも売却してどうにかなるのではないかと考えている。極端な価格崩壊が起こったときは、買ったエリア、あるいは東京全体が大変なことになっていると思うので、そのときはそのときだ。運が悪かったと思うしかない。

新居の引き渡しを楽しみにしつつ、ローン返していくぞの気持ちを高めようと思う。

ところで、最後まで迷っていたが結果的に選ばなかったマンションがあって、それはシティタワー品川パークフロントという物件だ。これはなんと目の前が大井競馬場と平和島の競艇場だ。東向き高層階なら部屋から競馬と競艇が見れる。このような賭博施設は基本的にマイナス要素とされるようで、パンフレットの地図からもひたすら競馬場が隠されていたり、Twitter でもクソ物件 GO 扱いされていたが、競馬好きにはたまらないし、間取りも悪くないと思うので競馬で一発当てた人は買ってほしい。かなり迷っていたのでが、各階ゴミ捨て場がないという点が痛くて諦めた。

【シティータワー品川パークフロント】
ちゃんと内見してきたよ。たしかにここからの景色はギャンブラー御用達かもしれませぬ#クソ物件GO pic.twitter.com/RQ83ZGtJ6s

— とっくさん@おふぃす屋さん (@tokusenjouhou20) December 6, 2019

年末はビットコインが高値を更新してびっくりした。まさか2017年のバブルみたいな状況が再び到来するとは...。ブロックチェーン関連の部署に異動した一方で、個人的にはおいしいポジションをほとんど持っていなかったので悲しい。一発当てた人は寿司をおごってください。

2021年もがんばっていきましょう。

2020-10-19 13:16 修正。新しい列を作る必要は特にない。

pandas を使うと、例えば

horses.loc[:, 'horse_weight'] = horses.groupby('horse_id')['horse_weight'].ffill()

とすることで、horse_weight の中で欠損した値を、horse_id でグループ化した中での1つ前の値を使って埋めることができるが、1つ前の値が存在しない場合に、1つ後の値を使って補完 (bfill()) したい場合はどうしたら良いか。

# これは正しくない
horses.loc[:, 'horse_weight'] = horses.groupby('horse_id')['horse_weight'].ffill().bfill()

これはいけない。なぜなら ffill() が返す型は SeriesGroupBy ではなく Series であり、グループ化が解除されているため、グループに関係なく 1 つ後の値を使ってしまう。

Stack Overflow に回答があるが、apply() を使うのが正しい。

horses.loc[:, 'horse_weight'] = horses.groupby('horse_id')['horse_weight'].apply(lambda x: x.ffill().bfill())

ただ、実際やってみるとこれは結構遅かった。たぶん普通に SeriesGroupBy.ffill() やるときは何か良い感じの最適化がかかってる一方で、apply() の場合は律儀にグループ数分のループが走るからだと思う（未検証）。

ということで、愚直に

horses.loc[:, 'horse_weight_filled'] = horses.groupby('horse_id')['horse_weight'].ffill() # 別の列に ffill() した結果を入れておく
horses.loc[:, 'horse_weight_filled'] = horses.groupby('horse_id')['horse_weight_filled'].bfill()

よく考えたら別に新しい列を作る必要はなかった。

horses.loc[:, 'horse_weight'] = horses.groupby('horse_id')['horse_weight'].ffill()
horses.loc[:, 'horse_weight'] = horses.groupby('horse_id')['horse_weight'].bfill()

で良い。