八雲技術帳

環境

• k8s 1.22.1
• iSCSI TargetはTrueNAS Core
• k8sにstaticなPVとしてiSCSIをマウントしている

statefulsetとして定義しているPodが使用するiSCSI PV を拡張するというのを前提に記述する。

大まかな手順

1. PV削除 & 再生成
2. PVC 削除 & 再生成
3. ファイルシステム拡張

1. PV削除

1
2

kubectl delete -f pv.yaml
kubectl apply -f pv.yaml

PVには容量が定義されているので、そこを変更するために削除して再生成する。
patch等で変更できればいいのだが、容量は変更不可なので削除→再生成が必要。
なお、PVを削除してもiSCSIのディスク上のデータが削除されたりすることはないので安心してほしい。

2. PVC削除 & 再生成

1と同じ手順なので省略。理由も一緒。
statefulsetの場合は一度statefulsetを削除->PVCを削除→再度作成するのが早い
statefulsetの場合、再度作成した時点でPodが走ってしまうがそのままで問題ない。

3. ファイルシステム拡張

実行ノードの特定

ファイルシステムを拡張する。この手順は拡張したいPVをマウントしているPodが動いている状態で行う。 kubectl get pod -o wide を実行して、PVをマウントしているPodがどのノードで動いているかを確認する。

Pod内でデバイスを特定する

1
2
3
4
5
6
7
8
9
10
11
12

kubectl exec podname-0 -- df

Filesystem     1K-blocks     Used Available Use% Mounted on
overlay         38572396 29764404   6972620  82% /
tmpfs              65536        0     65536   0% /dev
tmpfs            4326452        0   4326452   0% /sys/fs/cgroup
shm                65536       40     65496   1% /dev/shm
/dev/sda2       38572396 29764404   6972620  82% /etc/hosts
/dev/sde        33542144 25336792   8205352  76% /var/lib/postgresql/data  <- これ！
tmpfs            3145728       12   3145716   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs            4326452        0   4326452   0% /proc/acpi
tmpfs            4326452        0   4326452   0% /sys/firmware

/dev/sde をマウントしていることがわかる。

ファイルシステム拡張を実行

この手順はpodを実行しているノードで行う。

1
2
3

user@kubeworker2:~$ df -a | grep /dev/sde
/dev/sde                                  -        -         -    - /var/lib/kubelet/plugins/kubernetes.io/iscsi/iface-default/192.168.10.220:3260-iqn.2005-10.org.freenas.ctl:k8s-tgt-lun-3
/dev/sde                                  -        -         -    - /var/lib/kubelet/pods/26d4ed85-a26e-447f-8dc0-7a1468d940b0/volumes/kubernetes.io~iscsi/iscsi-db

上記で2行表示されるが、/var/lib/kubelet/〜 のどちらかを次のコマンドに指定する（どちらでもOK）

1
2
3
4
5
6
7
8
9
10
11
12

root@kubeworker2:~# xfs_growfs /var/lib/kubelet/plugins/kubernetes.io/iscsi/iface-default/192.168.10.220:3260-iqn.2005-10.org.freenas.ctl:k8s-tgt-lun-3
meta-data=/dev/sde               isize=512    agcount=4, agsize=1572865 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=0
data     =                       bsize=4096   blocks=6291460, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=3072, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 6291460 to 8388608

ちなみに、iSCSI PVのyamlでext4を指定しているのであれば、xfs_growfs の変わりに resize2fs を使用する。ファイルシステム拡張なので稼働中に行っても安全。

失敗例

Pod上や、ノード上で /dev/sdX にiSCSI LUNがマウントされているように表示されるが、これを拡張しようとするとエラーになる。xfs_growfsは、マウントポイントを指定しなければいけないのにデバイスを指定しているのが原因

1
2

root@kubeworker2:~# xfs_growfs /dev/sde
xfs_growfs: /dev/sde is not a mounted XFS filesystem

蛇足

静的iSCSI PV 定義

以下のような定義をしている。なお、ノードにiscsi関連のツールをインストールする必要があるので注意。（それすらPodにする方法もあるようだが、うまく動かなかった）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv-db
spec:
  capacity:
    storage: 5Gi
  #volumeMode: Block
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: iscsi-static
  iscsi:
    targetPortal: 192.168.0.1:3260
    portals: ['0.0.0.0:3260']
    iqn: iqn.2005-10.org.freenas.ctl:k8s-tgt
    lun: 0
    fsType: xfs
    readOnly: false

ゴール

• ステータス表示7Seg LEDは諦める
• とりあえず普通の microATXマザーが使えるように改造する

やったこと

使える工具が弓のこ、ハンドニブラーしか無かったのでそれだけを使ってなんとかしている。
電動ドリルとかがあればもっと楽ができた気がする。

(2022/02/07追記)
電動ドリルがあってもあまり変わらない。あと安物の電動ドリル(〜4000円）だと回転数が低すぎてドリルの刃がすぐに^[穴3~4個]駄目になるので1万円くらい出したほうがいい。

背面パネルを切り落とす

マザーボードを固定するプレートにI/Oブラケット相当の部分まで含まれてしまっているのでI/Oブラケット相当の部分を切り落とす。 ┘ ←こういう形になっているので切り落として | にする
弓のこで切り落とせる。 この時、マザーボードを固定するプレートに貼り付けいている絶縁シートは剥がしておいた方がいい。傷がつくから。

CPUクーラー固定用ネジ受けを切除する

元のマザーボードでCPUクーラーを固定するために使っているネジ受けがマザーボードに接触するのでこれを切除する必要がある。数ミリ短くなってくれればいいので根本まで行く必要はない。
弓のこしかない場合は、ネジ受けを斜めに切ることで十分目的は達成できる。

電動ドリルがあれば、おそらく裏からドリルで揉んであげれば取れる…のではないだろうか。

I/Oブラケットの位置合わせ

I/Oブラケットをつけるのであれば、それにあわせてケースを切断する必要がある。
これはハンドニブラーを使って少しずつ現物合わせをするのが楽だった。
この時のポイントは、ちょっと小さめなところにあわせて、そこからは慎重に切ったほうが良いということ。大胆に行くとガバガバになるので…
なお、見た目でちょっと出っ張ってるなぁ…と思ったところはだいたい切断対象。そして、拡張スロットのかなり近くまで切ることになるので、拡張スロット部分にダメージを入れないように注意。

I/Oブラケットがいらない場合でも、ケース切断は必須。

ちなみに、PCI-Express等の拡張カードのスロットは場所がピタリと合うので加工は不要。

電源スイッチ等の配線

…実はここが書きたいだけだった。フロントの電源ボタン等のユニットは TS20でも共通。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

┌──────┐
│02　01│ 01は赤いケーブルが出ている
│04　03│
│06　05│
│08　07│
│10　09│
│12　11└─┐
│14　13  │
│16　15┌─┘
│18　17│
│20　19│
│22　21│
│24　23│
│26　25│
└──────┘

上記の番号で

TS20 の場合

• ピンのピッチが狭い。普通にマザーボード等で見るピンピッチの半分くらいになっている(2.54mmではなく2.0mmだと思われる。 TS10は2.54mm）
• なのでピンを引き出す際に使うジャンパワイヤは狭いピッチのものを使う必要あり。
• フロントの電源パネルユニットは共通なのでTS10のケーブルをTS20に流用するとTS10と同じように扱える
• TS20の場合（TS10もかもしれないが）電源ボタン、電源LED、HDD LED以外のピン配置は怪しい。間違っているかも。

その他

電源ユニット

電源ユニットのネジ穴はだいたい合う。しかし、電源ユニットの吸気ファンが下を向いてしまうため、あまり嬉しくない。また、ただでさえ吸排気ファンがないので下向きだと温度的に厳しい（別にコケる程ではない。ちょっとCPUファンが回るかなぁという程度）

電源ユニットを逆さまにすると排気が行われるようになるので、CPU温度もだいぶ楽になる感じ。ネジは一本しか合わなくなるが、ハニカム部分に固定したりすることでどうにかなる（そもそも、一本だけでも程々に止まるし、土台もあるので…） 電動ドリルがあれば、適切な位置に穴を開けることでうまく止められるようになるはず。

上部5インチベイらしきもの

おそらく普通の5インチベイx2 が謎のルーバーと、謎のケージで塞がれている。
これは、フロントパネルのネジを全部取り外すと取れる。
普通に切り取ってしまえば普通に5インチベイx2として使えると思われる。

蛇足

雑記

• マザーボードの型番は GA-6LASV1 rev 1.1 だが、これの資料は探した限りなさそう。
• 似たような型番の取説は出てくるが、ピン数が24ピンだったりして流用できない。
• とりあえずこれで使えるようにはなるが、全面ファン、背面ファンは別途考慮が必要。背面8cm、前面は12cm（5インチベイががら空きなのでそこに入るサイズなら入る）といったところか。

TS20 のケース流用

TS20のケースは、最初から普通にATX（E-ATXも行けそう）仕様にだいぶ近い。

• 電源ユニット部のサイズはATXではないので加工というかブラケットが必要。片方に寄せればネジが2本入るので、それでOKとするならOKではある（ネジがない方はケース内部に支えるような形が出ている）
• フロントの5インチベイと思しきもの（下部）は固定箇所が（おそらく）エンクロージャ専用になっていて普通ではない（固定はブラケットを自作すれば行ける）
• フロントの5インチベイ（上部2スロット）は普通に使えそう。
• 導風板（黒いカバー）は中央部分だけ活かして後は切除するしかなさそう。自分が使うマザーに合わせてカットしても良いのだが、CPUクーラーとかを選ぶようになって面倒だと思う。
• 導風板をカットすると背面ファンが固定できなくなる。正確にはネジ2本しか止まらない。うちのサーバーで試してみた範囲では2本でも特に問題なく使えている。
• これは、TS10も同じだが、床に直置きする場合はちょっと持ち上げるようにしておかないとケースのフロントパネルが開けられなくなる。(フロントパネルがちょっと下がり気味になるので床に引っかかってあかない）
• 足は http://www.shop-siomi.com/shopdetail/000000000041/ のようなのをつければ良いと思う（私は処分するPCケースについてた足を移植した）。ケースにドリルで穴を開けてネジとナットで止める感じ。 両面テープで貼っても良いかも。
• TS20に関しては重量がすごい(25kgとか)のでキャスターをつけてしまった方が良いかもしれない。

tl;dr

zabbix-senderの逆で最新の値を取得するツール、zabbix-getterを作りました。

https://github.com/yakumo-saki/zabbix-getter

背景

我が家のインフラでは各種のメトリクスをzabbixに蓄積しています。IoT的なセンサー類のデータもzabbixに蓄積されています。zabbixから値を取り出してよしなに表示するサイネージ的なものを作ろうとした時に困ってしまいました。

そう、zabbixから値を取得するツールはzabbixに含まれていません。^[zabbixに送信する方はzabbix_senderというお手軽ツールが同梱されています]
そこで、zabbix_senderのようなお手軽さでzabbixのデータを取得するツールを開発しました。

実装

このツールはできるだけ多くのプラットフォームで動作してほしいというのと、デプロイが容易であることが重要なのでgolangで開発しました。
まだgolangには不慣れなのでできるだけシンプルに、依存性を減らして開発することを心がけました。
結果、デプロイはgithubからバイナリを取得して解凍して即実行できるようになりました。

インターフェイス

設定ファイルを用意してしまえば、zabbix_senderと同じ引数で動くような形にしました。
また、スクリプトから使うことも考慮した設計になっています。

• 出力は stdout、ログはstderrに出力される
• 異常終了時、リターンコードが非ゼロになる

実行例

例えば、 zabbix-getter -s hostname -k keyname で値が取得できます。
項目名等が必要であれば -o JSON とオプション^[これはkubectl -oを真似しました。]を追加することでもう少し詳細な情報が出力されます。 逆に、-o PLAIN の場合は値だけを出力します。

1
2
3
4
5
6
7
8
9
10

{
  "hostid": "10307",
  "itemid": "32337",
  "key_": "temperature",
  "lastclock": "1636348382",
  "lastclockString": "2021-11-08 14:13:02 +0900 JST",
  "lastvalue": "28.48",
  "name": "気温",
  "units": "℃"
}

今後の機能追加予定（と足りない機能）

最新の値がある程度以上古かったら無かったことにする

これは個人的なユースケースです。30分以上前のデータが最新だったらそれはデータ取得プロセスがコケているのでデータなし扱いしたい。というものです。うちだと消費電力を30秒ごとに取得しているのですが、たまにこのプロセスがコケることがあります。その際この機能がないと古いデータをサイネージに表示してしまって、混乱することがあります^[電子レンジ使ってるのに消費電力が低いとか。実際にあった話です]

履歴が複数件欲しい

内部的には持っているので、出力することは可能なんですがユースケースがあるのかなぁ…という疑問があります。 追加するとしたら -l 10 のような感じで件数を指定すると-o PLAIN の場合は行区切りで値がどばっと出る感じ、-o JSON ならJSONの配列で返す形になると思います。

ユーザー名とパスワードをセットしないといけないのがイマイチ

設定ファイルに記述するか、環境変数で設定できるのですが、それ以前にこれはAPIキーみたいなものでどうにかできないものか… と調べては見たものの、zabbixにそういう機能がないようです。

実装の細かい話

以下は完全に蛇足です。読み物として読んでもらえれば。

コマンドラインパーサー

依存性を最小限にするとはいえ、さすがにコマンドラインオプションを一つずつ解釈していくのは骨が折れるのでここはなにかのライブラリに頼りたいところです。
あれ？ golang標準のflagパッケージは？ となるところですが、標準のflagパッケージはショートハンドなオプションに対応していません。^[-o と –output は同じ。というようなの]
無理やり対応することもできそうですがアレなので早々にほかを探すことにしました。^[ヘルプの出力で -o –output が同じであるような出力にならないのが致命的でした]

この項目、 https://sourjp.github.io/posts/go-cmd/ の記事を見たほうがより詳しいと思うのでこちらも参考になさってください。

要件としては、サブコマンドは作る気がないのでできるだけシンプルなものが欲しい。です。
結論としては、https://github.com/spf13/pflag を使用しました。標準のflagパッケージの不満点だけを解消してくれていて、使い心地はそのまま。さすが drop-in replacement なだけあります。

ロガー

これも標準のロガーがありますが、なんとログレベルの概念が一切ない。ちょっとこれはつらいです。では他のロガーを探そうとなるのですが… 多機能すぎて複雑そう。
fmt.Println に毛が生えたようなので良いので^[それはgolang標準ロガーでは？という気がします] 作ってみることにしました。まだライブラリとしては公開されていませんがそのうち公開しようと思っています。^[ソース中には含まれているのでファイルをコピーすれば使えます]

ちなみに、このロガーを他のgolangのコードで使いまわした際にJSON出力やコンテキストロギングのような機能が追加されて程々感が出てきたのはまた別のタイミングで…^[しかし、ファイルにログを出力する機能さえ未だに実装されていない。今どきは標準出力と標準エラー出力だけにしておいた方が色々と都合が良いので…]

zabbixのitem.get API

初期のころは、zabbixのitem.get APIに含まれるlastvalueという項目の値を結果として出力していたのですが、項目によってこの値が常に “” となることに気が付きました。
テスト用に作った項目ではそういう動作をしないのですが… 諦めて真面目に項目の履歴を取得してそちらから値を出力するように変更しました。^[v0.9.2くらいの変更です]

はじめに

• そもそもproxmoxはdebianなので普通にpostfixを設定すればいい。

背景

• Proxmoxをインストールしたあとのpostfixの設定が素朴すぎて、日本ではおそらくメールが飛ばない（SMTPを素朴に使うため、OP25B にひっかかる）

解決方法

sendgridにメールを中継してもらうように設定します。

手順

sendgridのアカウントを作る

英語 https://sendgrid.com/
日本語 https://sendgrid.kke.co.jp/ （もしかすると、こちらで登録するとアカウントができるまで数日かかるかもしれない）

※ちなみにどちらで作っても同じ結果になるはず。

アカウント作成〜ログインまでは省略。

API Keyを作成する

• ログイン後、左枠の Setting -> API Keys をクリック
• 右上の Create API Keyボタンをクリック
• 右枠の API Key Name に好きな名前を入れる。例えば Proxmox とか。
• 名前の下の Restricted Access を選択
• 権限一覧の Mail Send をクリック、展開された項目内の Mail Send の右にあるスライダーを一番右にする（この項目は ON OFF の2段階しかない）
• 右枠を下にスクロールして、 Create and View Keyボタン をクリック
• 画面が切り替わって API Key が表示されるのでこの画面をそのままにしておく。表示されている通り、この API Key は二度と表示できない。（が、失くしちゃったらもう一度この手順で作れば良いので面倒くさい以外の問題はない）

Postfixの設定

https://sendgrid.kke.co.jp/docs/Integrate/Mail_Servers/postfix.html
日本語で説明してくれているので上記の手順を踏むだけ。

• Proxmoxにシェルでログインする。 (SSHでつなぐか、Proxmox管理画面のShellボタン）

必要なモジュールを入れる

• apt-get install libsasl2-modules

main.cf

vi /etc/postfix/main.cf

• 末尾から 6行目くらいにある relayhost = という行の先頭に # をつけてコメントアウト #relayhost =
• 末尾に以下を挿入

1
2
3
4
5
6
7
8

# sendgrid
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_security_level = encrypt
header_size_limit = 4096000
relayhost = [smtp.sendgrid.net]:587

sasl_passwd を作成

このファイルは存在していないので新規作成。

• touch /etc/postfix/sasl_passwd
• chmod 600 /etc/postfix/sasl_passwd
• vi chmod 600 /etc/postfix/sasl_passwd

1

[smtp.sendgrid.net]:587 apikey:先程画面で表示されたキー

例えば、 [smtp.sendgrid.net]:587 apikey:SG.Ti_nVs_fdjsleybadfErdFEF... のような感じになる。

設定を反映させる

• postmap /etc/postfix/sasl_passwd
• systemctl restart postfix

確認

テストメール送信

1
2
3

mail -s testmail <メールアドレス>
testmail
.

コマンドを打った直後、何も表示されない状態になるが、そこで本文を入力する。
上記の例では、 testmail と入力して改行。その後 . だけを入力して改行するとメールが送信される。

メール送信確認

• mailq
  OK: Mail queue is empty

NG例

1
2
3
4

root@proxmox:~# mailq
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
43B2E100F17    1399 Mon Nov  1 18:36:56  root@proxmox.local
(SASL authentication failed; cannot authenticate to server smtp.sendgrid.net[13.114.210.107]: no mechanism available)

NGの場合

• tail /var/log/mail.log

おそらく、以下のどれか

• apt-get install libsasl2-modules
• postmap /etc/postfix/sasl_passwd
• apikeyを入れ間違えた。

リトライ

• postqueue -f

更新記事があります。

https://zenn.dev/yakumo/articles/4d9adb8a4a338e

注意：この手順は失敗しています。

• USBカードリーダーをコンテナに見せる方法がわからなかった
• DVBデバイスをコンテナに公開することはできたが、自動的に割当ができなかった。手動では割当可能

環境

• PT3
• Proxmox VE 7.0 (Debianベース)

コンテナ作成

とりあえず Debian 10のコンテナを作る。これはGUIから可能ので省略

コンテナにDVBデバイスを追加

コンテナ起動後にホスト側で以下のコマンドを実行。
これを自動化することができなかった。lxc.hook.post-start はProxmoxではうまく動かなかった。 Proxmox独自の hookscript を使うことでうまく行きそうな感じはあるのだが、今度はhookscriptをどう指定するのかわからない。 hookscript: local:hookscript.pl という記述は見かけたのだが…

Mirakurunコンテナはそうそう再起動しないので、 pct stop/start <ID> と以下の記述を組み合わせれば半自動くらいにはなるのでヨシとした。

1
2
3
4
5
6
7
8
9
10
11
12
13

CTID=110   // ProxmoxのIDと合わせる
lxc-device -n $CTID add /dev/dvb/adapter0/demux0
lxc-device -n $CTID add /dev/dvb/adapter0/frontend0
lxc-device -n $CTID add /dev/dvb/adapter0/dvr0
lxc-device -n $CTID add /dev/dvb/adapter1/demux0
lxc-device -n $CTID add /dev/dvb/adapter1/frontend0
lxc-device -n $CTID add /dev/dvb/adapter1/dvr0
lxc-device -n $CTID add /dev/dvb/adapter2/demux0
lxc-device -n $CTID add /dev/dvb/adapter2/frontend0
lxc-device -n $CTID add /dev/dvb/adapter2/dvr0
lxc-device -n $CTID add /dev/dvb/adapter3/demux0
lxc-device -n $CTID add /dev/dvb/adapter3/frontend0
lxc-device -n $CTID add /dev/dvb/adapter3/dvr0

Node.js

https://github.com/nodesource/distributions/blob/master/README.md
上記の通り。

• curl -fsSL https://deb.nodesource.com/setup_16.x | bash -
• apt-get install -y nodejs

Mirakurun

https://github.com/Chinachu/Mirakurun/blob/master/doc/Platforms.md

• apt install build-essential git
• npm install pm2 -g
• npm install mirakurun -g –unsafe-perm –production

POINT: arib-b25-stream-test はあとで入れるのでここで入れない

Config

• cd /usr/local
• git clone https://github.com/Chinachu/dvbconf-for-isdb.git
• cd etc/mirakurun
• channels.ymlは省略。 channel: ‘BS1_1’ のような形式で入っている場合、BS01_1 のように修正する必要がある。(dvbv5_channels_isdbs.conf に登録されている名前と合わせる必要がある）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

- name: PT3-S0
  types:
    - BS
    - CS
  command: dvbv5-zap -a 0 -c /usr/local/dvbconf-for-isdb/conf/dvbv5_channels_isdbs.conf -r -P <channel>
  dvbDevicePath: /dev/dvb/adapter0/dvr0
  decoder: arib-b25-stream-test

- name: PT3-T0
  types:
    - GR
  command: dvbv5-zap -a 1 -c /usr/local/dvbconf-for-isdb/conf/dvbv5_channels_isdbt.conf -r -P <channel>
  dvbDevicePath: /dev/dvb/adapter1/dvr0
  decoder: arib-b25-stream-test

- name: PT3-S1
  types:
    - BS
    - CS
  command: dvbv5-zap -a 2 -c /usr/local/dvbconf-for-isdb/conf/dvbv5_channels_isdbs.conf -r -P <channel>
  dvbDevicePath: /dev/dvb/adapter2/dvr0
  decoder: arib-b25-stream-test

- name: PT3-T1
  types:
    - GR
  command: dvbv5-zap -a 3 -c /usr/local/dvbconf-for-isdb/conf/dvbv5_channels_isdbt.conf -r -P <channel>
  dvbDevicePath: /dev/dvb/adapter3/dvr0
  decoder: arib-b25-stream-test

libaribb25

https://github.com/tsukumijima/libaribb25

• git clone https://github.com/tsukumijima/libaribb25.git
• cd libaribb25
• (中身確認するのであれば CMakeLists.txtをチェック）
• cmake -B build -DCMAKE_VERBOSE_MAKEFILE=1
• cd build
• make
• make install

arib-b25-stream-test（試したときはファイルサイズ22KBの実行ファイルだった）

USBカードリーダー

/etc/pve/lxc/<CTID>.conf にUSBデバイスのIDを書いたりすると転送可能なようだがうまくいかなかった。ここでギブアップした。

1
2

lxc.mount.entry%3A /run/pcscd mount/run/pcscd none bind,ro,create=dir
lxc.hook.start%3A /opt/scripts/hook_start.sh

ちなみに…（2022/02/02追記）

現在は、Proxmoxに直接nodejsとmirakurunを導入しています。
USBカードリーダーも問題なく動いてとりあえず安定稼働しています。
いくらdebianベースとはいえ、ハイパーバイザーに余計なものを載せちゃってるのでちょっと微妙なんですが…

• Ryzen 1700
• ASRock X370 Gaming K4
• Dell PERC h740p
• GeForce GTX 1060

Proxmox自体のインストール

• isoをダウンロードして balenaEtherでUSBメモリに書いてそこから起動してインストール。
• 特にむずかしいところはないので省略
• ちなみにHyper-Vからの移行なのでそのための覚書も含む
• ProxmoxはDebianベースということを覚えておくと吉

MegaRAID CLIのインストール

Broadcomのサイトがあまりに使いにくいので以下の手順にしたがう。
元：https://gist.github.com/fxkraus/595ab82e07cd6f8e057d31bc0bc5e779

ようやくすると、必要なツール類を入れて、BroadcomからMegaCLIをダウンロードして展開。
展開した結果RPMファイルが得られるが、ProxmoxはdebianベースなのでRPM->DEBに変換する。
DEBファイルをインストールして、動作確認。という流れ。

• apt install libncurses5 unzip alien
• wget https://docs.broadcom.com/docs-and-downloads/raid-controllers/raid-controllers-common-files/8-07-14_MegaCLI.zip
• unzip 8-07-14_MegaCLI.zip
• cd Linux
• alien MegaCli-8.07.14-1.noarch.rpm
• dpkg -i megacli_8.07.14-2_all.deb
• /opt/MegaRAID/MegaCli/MegaCli64 -h
• /opt/MegaRAID/MegaCli/MegaCli64 -AdpCount
• /opt/MegaRAID/MegaCli/MegaCli64 -AdpAllInfo -aALL

VHDX からのコンバート

接続先VMの作成

必要なVMをWeb GUIから作成する。
ディスクはあとで正式なものを接続するが、作成しないと先に進めないため、容量は0.1GBのような小さい値で作成する。
VMの作成が完了したら、

• 作成したVMのハードウェアからディスクを選択して Detachする。
• ハードウェア一覧の一番下に未使用:〜〜のようにディスクが表示されるので更にそれを選択して、削除 しておく。これでコンバートの下準備が完了。

VHDXからコンバートする

qm importdisk 100 Windows10_c.vhdx SUM980EVO

• 100 -> VMID。Proxmoxのツリー表示で表示される数字。VMを作ったときに採番される。100からの連番
• Windows_10_c.vhdx -> 変換元VHDX
• SUM980EVO -> ストレージの名前。 Proxmoxのツリーでデータセンターを選択して真ん中の選択でストレージを選んだ時に表示される一覧の、IDを指定する。

1
2
3
4
5
6
7
8
9
10
11
12
13

root@proxmox:~/hyper-v/Windows10# qm importdisk 100 Windows10_c.vhdx SUM980EVO
importing disk 'Windows10_c.vhdx' to VM 100 ...
  Logical volume "vm-100-disk-0" created.
transferred 0.0 B of 59.0 GiB (0.00%)
transferred 604.2 MiB of 59.0 GiB (1.00%)
transferred 1.2 GiB of 59.0 GiB (2.01%)
transferred 1.8 GiB of 59.0 GiB (3.01%)
transferred 2.4 GiB of 59.0 GiB (4.01%)
~~~~~~~~~~~
transferred 58.6 GiB of 59.0 GiB (99.30%)
transferred 59.0 GiB of 59.0 GiB (100.00%)
transferred 59.0 GiB of 59.0 GiB (100.00%)
Successfully imported disk as 'unused0:SUM980EVO:vm-100-disk-0'

メッセージの通り、VMに未使用のディスクとして追加されている。
アタッチには、 VMのハードウェアから未使用のディスクを選択して編集ボタンを押す。

起動順設定

アタッチしたディスクが起動ディスクの場合、VM オプション ブート順 の設定で今追加したディスクからのブートを有効にして（チェックを入れる）、ブート順の優先順位を上げておく（三 をドラッグ）

ディスクパススルー (RDM)

物理ディスク全体をVMに見せるには以下のコマンドを使用する。

qm set 100 -virtio0 /dev/disk/by-id/scsi-36d0946606c11150028b3e11557046428

• 100 -> VMID
• -virtio0 接続するバス sataN virtioN ideN 既存のを指定すると上書きされる。適当に空いているところをセットしておいて、Web GUIからデタッチすれば接続先を変更できる。
• /dev/disk〜 デバイス

by-id の次がわからない場合は、 ls -l /dev/disk/by-id/ でリンク先を表示させるとわかりやすくなると思う。 (/sdaとかその名前が表示される）

TrueNAS

TrueNASはKVMのエージェントが入っていないので、Web GUIからのシャットダウン・リブートに一切応答しない。これでは困るのでどうにかする。

https://www.truenas.com/community/resources/qemu-guest-agent.167/

手順的には上記の通りと言いたいところだが、 virtio_console.ko はリンク先のGitHubに存在しない。というよりFreeBSD由来のファイルなのでFreeBSDのisoから持ってくる必要がある（と思われる。） 使用しているTrueNAS 12-U6 はFreeBSD 12ベースなので、
https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.2/FreeBSD-12.2-RELEASE-amd64-disc1.iso
のisoの /boot/kernel/virtio_console を持ってくる。

UEFIのDebian VMが自動起動できない(Linux全般？)

VHDXから変換をかけて起動させると、EFI Shellが起動してしまう。
EFI Shellで以下のようにすると起動させることができる。

1
2
3
4

FS0:
cd EFI
cd debian
grubx64.efi

この原因は、EFIブートエントリにgrubがないことが原因と思われる。

1
2
3
4
5
6
7
8

# efibootmgr
efibootmgr 
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0001,0000,0002
Boot0000* UiApp
Boot0001* UEFI QEMU QEMU HARDDISK 
Boot0002* EFI Internal Shell

Debianの場合、debianという名前のブートエントリがなければ起動してこない。

修正方法

VMの設定を確認した上で grub-install で修復可能。

• BIOS の設定が OVMF(UEFI) に設定されている
• ハードウェアに EFIディスク が存在している

1
2
3

$ sudo grub-install 
Installing for x86_64-efi platform.
Installation finished. No error reported.

1
2
3
4
5
6
7
8
9

$ efibootmgr 
BootCurrent: 0003
Timeout: 3 seconds
BootOrder: 0004,0001,0002,0000,0003  ※ 0004が先頭になっている
Boot0000* UiApp
Boot0001* UEFI QEMU DVD-ROM QM00003 
Boot0002* UEFI QEMU HARDDISK QM00005 
Boot0003* EFI Internal Shell
Boot0004* debian                  ※ 追加されたエントリ

蛇足

WindowsとFreeBSD（TrueNAS）は同じUEFIなのに問題が発生していない理由がよくわからない。
startup.nsh でも置いてるのかなぁ

まえがき

• gnome-keyringを有効にした状態でターミナルを開くとjournalに警告が表示される
• 特に動作には問題ないが…

警告ログ

ターミナルを開いた時

1

gnome-keyring-daemon: no process capabilities, insecure memory might get used

keyringを使おうとしたとき

1

gnome-keyring-daemon[1370]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk

解決方法

以下のコマンドを実行して権限を与えればOK。

1

sudo setcap cap_ipc_lock=+ep /sbin/gnome-keyring-daemon

ネタ元： https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/36

蛇足

なんか修正されるのかも。

https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/41

環境

• ArchLinux
• ZFS root

まえがき

dockerを普通にインストールして、起動すると overlayfs がエラーを出してデーモンが起動しない。

1
2

overlayfs: upper fs does not support RENAME_WHITEOUT.
overlayfs: upper fs missing required features.

修正方法

/etc/docker/daemon.json に以下を記述する。

1
2
3

{
    "storage-driver": "zfs",
}

これで systemctl restart docker すれば起動するようになる。
…が。これだけだと、 zfs list したときに

1
2
3
4
5
6
7
8
9
10
11
12
13

zroot                                                                                271G   179G     32.2G  /zroot
zroot/01760219725a63b485556ab9885ee97e1b87827da95d682293371c1f2d179645               501K   179G     74.0M  legacy
zroot/037bb15aa1e016188c42f0d6cd9657d56bbb0438369d7b6f285e1441cbe6b0e7                76K   179G      914M  legacy
zroot/04462e6d8f2062374364a8716326e01a1c88d5bdc3b7915da73f7a7e82299d67               367M   179G      502M  legacy
zroot/187c22b305f7954a9ac62daa046717ba9c6f623debcc5dbbf9315421957f5078              8.58M   179G      923M  legacy
zroot/3fe24dc8ad126ac3e27061ff66d57a0c2280c4eebe5d4acd48a884be45994629              43.6M   179G      966M  legacy
zroot/47444a9fbb311dd6dffd0354c797ab157d9b22f517fb1f79024f46c38bb261ce              10.3M   179G     83.3M  legacy
zroot/4e2c9621b69fdf9ae7af7a49520dfbbcc7e9fcae2fbf2df82c43d33f4e5b87e9                45K   179G     85.7M  legacy
zroot/4f4354531f31a28618b2309219e17c21c304bebed17232eb8ccc3989b0281e4d               158M   179G      321M  legacy
zroot/50a7b5d1c974be396de8afe91b7d379919229dbd079986ba61aa54be319c6a9f                67K   179G      966M  legacy
zroot/5abf3459d5f578114a6eaea508d7d8c56d86edf3d7ca8ce8495d535aad23b7d4              63.5K   179G      137M  legacy
zroot/6392643e8c58e4b89ac899ae96bc28dcf817a5e0f54ca478f32bd2f09fab04e8              22.0M   179G      165M  legacy
zroot/6cfb82787e34bad9b15b4faa18346065928f6146bdd557d2a336fcf7b62b42d3                52K   179G      502M  legacy

このような感じになってしまってイマイチ嬉しくない。これは、/var/lib/docker を独立したzvolに作成することで少し良くなる。

1
2
3
4
5

# rm -rf /var/lib/docker
# mkdir -p /var/lib/docker
# systemctl stop docker
# zfs create -o mountpoint=/var/lib/docker zroot/docker
# systemctl start docker

※ これを実行する前に /var/lib/docker を空にしておくとゴミが残らなくて良い

実行後

1
2
3
4
5
6
7

zroot/docker                                                                         511M   180G      963K  /var/lib/docker
zroot/docker/1e4fb5f1b1b030101aec07118d73d73589e1e2348434a7df28eff3efab3e9963       62.5K   180G      137M  legacy
zroot/docker/4bb7f02c4fcb8b2f3c7739147f94f4c6cedc94b45ee61e1a59985cef05647fac         74K   180G      502M  legacy
zroot/docker/51c460dd69b9cd9abe17c7179167bb21604e0d69cc7b2bfb10bf5395aeb94680        367M   180G      502M  legacy
zroot/docker/612f66a077f07d5e5ded79454deaad77204e390ef923c6ba67ddc26ea80e4c98       4.28M   180G     85.7M  legacy
zroot/docker/658be2eba3faec489b7f8f5d6818b17db14c9d13c7b9ee6b06f228c2d8630c6d        240K   180G      502M  legacy
zroot/docker/658be2eba3faec489b7f8f5d6818b17db14c9d13c7b9ee6b06f228c2d8630c6d-init    75K   180G      502M  legacy

こうしておけば、dockerがどれだけのdisk容量を使っているかもわかりやすくなります。
…ごちゃごちゃ出てきちゃうのは変わらないですが。

前提条件

• Raspberry Pi 4B
• Raspberry Pi OS 32bit (2021-05-07-raspios-buster-armhf-lite)

USBブートできるのになぜ？

うちにあるUSB-SATA変換箱のどれを使ってもUSBブートが安定しなかったから。症状は…

• 起動してしまえば安定する
• reboot などで再起動するとほぼ確実に再起動に失敗する

やり方

概略は以下の通り

1. RaspbianのイメージをmicroSDカードに焼く。
2. vfatパーティションの cmdline.txt の root= の指定を書き換える
3. 起動後に /etc/fstab を変更してmicroSDのbootをマウントする

2. cmdline.txtのルートファイルシステムの指定を書き換える

PARTUUIDの取得

microSDカードから起動してもUSBデバイスからブートしても良いので、ルートファイルシステムにしたいディスクがつながっている状態で sudo blkid を実行する。
ここでほしいのはPARTUUIDの値である。

1
2
3
4
5
6
7

$ sudo blkid

/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="5DE4-665C" TYPE="vfat" PARTUUID="8024d03d-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="7295bbc3-bbc2-4267-9fa0-099e10ef5bf0" TYPE="ext4" PARTUUID="8024d03d-02"
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="7581-8A48" TYPE="vfat" PARTUUID="7a063ee3-01"
/dev/sda2: LABEL="rootfs" UUID="fa37d515-e741-4d35-bcec-4580aef395e1" TYPE="ext4" PARTUUID="7a063ee3-02"
/dev/mmcblk0: PTUUID="8024d03d" PTTYPE="dos"

/dev/mmcblk... で始まる行はmicroSDカードなので無視する。
たいていの場合は、 /dev/sda2 になっていると思われる。上記の例の場合は、7a063ee3-02 が欲しい値。 これをメモしておく。

cmdline.txtの書き換え

Windowsから編集するのであれば microSDカードの cmdline.txt
microSDカードから起動しているのであれば、 /boot/cmdline.txt
USBデバイスから起動しているのであれば、

1
2

sudo mkdir /mnt/tmp
sudo mount /dev/mmcblk0p1 /mnt/tmp

した上で、 /mnt/tmp/cmdline.txt

1
2
3
4
5

変更前
console=serial0,115200 console=tty1 root=PARTUUID=8024d03d-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

変更後
console=serial0,115200 console=tty1 root=PARTUUID=7a063ee7-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

これでmicroSDカードを差した状態で起動すれば、microSDカードから起動して / がUSBデバイスな状態になります。

/etc/fstab を変更してmicroSDのbootをマウントする

USBデバイスの状態によりますが、microSDカードの中身をそのままUSBデバイスにコピーする。というパターンが多いと思います。
この場合、USBデバイス内にあるbootパーティションが /boot としてマウントされるようになっているので修正する。

/etc/fstab

1
2
3
4

PARTUUID=8024d03d-01  /boot           vfat    defaults          0       2
# ↓は元の値
#PARTUUID=7a063ee7-01  /boot           vfat    defaults          0       2
PARTUUID=7a063ee7-02  /               ext4    defaults,noatime  0       1

完了

あとは普通にRPiが起動してくれば完了です。
起動したら mount | grep "/dev" で想定通りになっているか確認しておきます。

だめな例 （/bootが/dev/sdaになってしまっている）

1
2

/dev/sda2 on / type ext4 (rw,noatime)
/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

よい例

1
2

/dev/sda2 on / type ext4 (rw,noatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

問題

• Firefoxを標準のブラウザにしているときに、VSCode等でリンクを開いた際にエラーダイアログが表示されて、リンクがFirefoxで開かれない

解決策

• MOZ_DBUS_REMOTE=1 をセットする

蛇足

使用している環境は、 Archlinux、Wayland、Swaywm です。
環境依存の部分が多分にあると思うので話半分で。

環境変数のセット方法は以下に記述がある

• https://wiki.archlinux.jp/index.php/%E7%92%B0%E5%A2%83%E5%A4%89%E6%95%B0
• https://wiki.archlinux.org/title/environment_variables

~/.config/environment.d/envvars.conf に書けば反映されるという記述があるけれども、手元の環境では反映されなかった。（再起動しても反映されなかった）

/etc/environment に書くのは反映される。しかしこれはシステムの全ユーザーに効いてしまうのでできれば避けたい。

~/.pam_environment 英語版のArchwikiにdeprecatedの表記があるが、これならユーザー毎に書けて、しかも反映される。

元ネタ

https://mastransky.wordpress.com/2020/03/16/wayland-x11-how-to-run-firefox-in-mixed-environment/