2023 年の sngsk.info の状況
を動かしているサーバのお世話状況について書く。1年間でやってきたことのまとめでもある。
mkosi >= 15 むけの mkosi-files 対応
ということがあり、v15.1 以降の mkosi は systemd-repart に依存することとなり、その結果使い勝手が大きく変わることになった。後方互換性のない変更がかなり入っているので単にバージョンを上げるだけでは mkosi によるイメージ作成がコケる事態になってしまう。 これで何が困るかというとわたしは https://github.com/nosada/mkosi-files というものをメンテしており、こいつで作成されるコンテナイメージを使い動かしている systemd-nspawn コンテナを前述2サイトの運用に使っている。新しめの mkosi でイメージが作れないと大変困る。この為の対応を以下でいれた:
PR としては大変酷い内容なので、わざわざ見にゆく価値は無い。
なお https://github.com/systemd/mkosi/blob/main/mkosi/resources/mkosi.md の変遷を見てもらうとわかるのだが、systemd-repart に切り替わった直後の mkosi ではかなりの量の read-only 扱いのディレクトリがあり、これによって mkosi.build や mkosi.postinst を使うかたちでのコンテナイメージいじりがかなり厳しくなった。 このへんの制約をなんとかする為に手間を割くのも面倒だったので systemd-nspawn / mkosi によるコンテナ運用を止して OCI 的なコンテナ運用に切り替えようかなあと思った時期もあったのだが、しばらく様子をみていたところ read-only 扱いのディレクトリが減ってゆき、結果として前述 PR で対処ができるようなレベルにはなった。一安心。
サーバの作り直し
いろいろな事情で前掲2サイトを動かしているサーバ(https://www.digitalocean.com/ の droplet。要は VM)は定期的に再起動させている。ある日そんな感じで再起動させたところ、起動後 2 -- 3 分すると CPU が刺さって SSH できなくなるという事態に陥った。トラブルシュートも面倒だったのでデータを退避させて新サーバに移行した。以下が役に立った:
移行完了後に旧サーバは消したのだが、足掛け5年程度同じ VM を使い続けていたらしい。今までお疲れさまでした。
AUR パッケージのメンテナンス作業を GitHub Actions 化
といったようなことをしており、その為に使っているものが以下のようにある:
いままでこいつらは前述2サイトを動かしているサーバ内で docker コンテナとして動かしていたのだが、サーバを作り直したこともあり、良い機会だったので GitHub Actions 化してサーバ内で同居させていた状態を解消させた:
- https://github.com/nosada/update-pkgbuild-on-aur/actions/workflows/run.yaml
- https://github.com/nosada/check-aur-pkg-version/actions/workflows/run.yaml
ときどきコケているようだが(本稿を書くにあたり確認して気付いた)おおむね問題なく動いているようなので、まあそんなもんだろう。
13 インチ MacBook Air (M2, 2022) を買った
GPD Pocket をメイン機として使うには(正確には常時給電しっ放しで使うには)
のとおり色々と限界があることがわかった。よってメイン機として使う PC を新たに用意することにし、GPD Pocket は Arch Linux が使える携帯端末的な位置付けとすることにした。
中古 PC をどうこうする世界の動向をもう追っていない為その方面を攻めないほうがよいなと思ったので新品の PC を買うことにし、モニタとキーボードがついたマシンが欲しかったのでラップトップとし、そのうえで US キー配列のマシンが欲しかったので ThinkPad か MacBook くらいしか候補が無く、新品の ThinkPad には興味が無いので MacBook になり、Touch Bar は要らないので MacBook Air にした。大枚をはたく覚悟は決めてたので CPU / GPU / RAM は増やせるだけ増やし、やっぱり大枚になりすぎたのでストレージはじめ他の削れるところは全部削った。
いまこの記事は MacBook Air から macOS で書いている。現状は macOS と Asahi Linux とを両方使えるようにしてある。Asahi Linux 側は本稿冒頭の画像のように KDE を Wayland で動かすようにして一通り使える状態にはしてあるが、やはりデスクトップマシンという面では macOS で動かしたほうが相当楽ということがわかった。ずいぶん長いこと Linux デスクトップを使ってきたが、macOS ってのはずいぶんと快適なんだなあとしみじみ思った。
ThinkPad への憐憫の時期は MacBook を新品で買ったことで終止符が打たれた。わたしのひとつの時代が終わったと思う。
余談:Asahi Linux について
- The first Asahi Linux Alpha Release is here! - Asahi Linux に従えば本当に何もトラブルなく M2 な MacBook Air で Linux が動いたので感動した
- 外部モニタを認識してくれていない感じがする
- ただし本稿を書いていて気付いたのだが M2 is here! July 2022 Release & Progress Report - Asahi Linux を見落していた模様。対処法が書いてある
- 逆に言うとインストール時にインストーラを "expert mode" に設定しなくても M2 な Mac で Asahi Linux がある程度は動くみたい
- KDE + Wayland で使っていると kitty が CPU を全コア食い尽してすごいことになる
- GPU 関連な感じがするのでもしかしたら前項かあるいは Apple GPU drivers now in Asahi Linux - Asahi Linux でいけるかもしれない
- インストールが終わったら素直な Arch Linux になり慣れ親しんだ世界がやってきたので嬉しくなった
追記
- 外部モニタを認識してくれていない感じがする
- ただし本稿を書いていて気付いたのだが M2 is here! July 2022 Release & Progress Report - Asahi Linux を見落していた模様。対処法が書いてある
よく読んだら対処法ではなく将来の展望でしかなかった。とうぶんは本体側モニタのみで頑張る必要がある。
- KDE + Wayland で使っていると kitty が CPU を全コア食い尽してすごいことになる
- GPU 関連な感じがするのでもしかしたら前項かあるいは Apple GPU drivers now in Asahi Linux - Asahi Linux でいけるかもしれない
Apple GPU drivers now in Asahi Linux - Asahi Linux で完全に解決した。すくなくとも体感上は macOS と同程度のグラフィックになった。
GPD Pocket のバッテリを交換した
で手にいれた GPD Pocket を
のようにし、以後基本的に常時通電させて常用していた結果、ときどき通電せずに使った際に筐体が異様にガタついたり唐突に再起動を繰り返すようになった。よく見てみると筐体背面のバッテリ側が膨らんでいて、筐体が歪んでいた。これはいかんと
を買って交換することにした。
ネジを6本外して裏蓋を取ってコネクタを留めているプラスチックの部品を外し(ここで更にネジ +1本)てやるだけでバッテリへのアクセスはできたが、GPD Pocket バッテリ 交換
で調べると色々出てくる粘着テープが異様に強力という情報に違わず、膨らんだバッテリを取っ払う為に恐しい力仕事になった。定規みたいなやつでほじるとよいという情報をもとに手元にあった三角定規で本体とバッテリの隙間を攻めていたらヤバいところを突き刺したらしく刺激臭が漂ってきてスリルがあった。最終的には無事に済んだので一安心。
交換したことに満足したので以後とくに特別なことはしていない。ひとまず元気に動いているようではある。5年前に買った機械を修理したので、また5年使い続けられるといいなと思う。
参考
以下記事を参考にさせて頂いた。三角定規で攻めて妙なことになった本稿本文の状況は本稿筆者の責任であり以下記事は一切無関係である。バッテリ交換ができるという事実の裏付けと作業過程の参考とした。
Google Pixel 7a 買った
いつも機械を買った記事ではその機械の写真をあげているが、こんかい写真をとれる機械が手元に Pixel 7a しかないので省略する。
で買った PH-1 を足掛け5年程度使い続けてきたが、今回唐突に壊れたので新しい機械を買った。 唐突に壊れたといっても飲み屋を数件ハシゴして完全に酩酊した状態で歩いていたさい手に持っていた携帯を勢いよくすっ飛ばして地面に叩き付けてしまった為であり、まったく自損事故であった。しかしまあ5年も使ったのだから実質寿命としてよいだろう。
Pixel 7a が届いた瞬間に stock の Android を 13 に更新したあと消して LineageOS 20.0 に入れ替えてある。PH-1 でも LineageOS 20.0 を使っていたので、このあたりの感動はない。そして数日も使えば Pixel 7a の新鮮味も消えてしまった。使いこなせていないとも言えるかもしれない。
前掲記事ではドコモ回線をどうしようか悩んでおり懐しい思いになった。いまは Pixel 7a が物理 SIM と eSIM とに対応していることを利用して
- 物理 SIM:IIJ mio(主回線)
- eSIM:irumo(副回線;歴史的経緯により維持している)
という感じにしてある。巷では叩かれまくっている irumo ではあるが、当方諸々ドコモにベッタリなのと irumo のほうがユースケースにあっていてかつ安く済むということが解ったのでそのようにしている。これで回線に悩むことは当分無くなるだろう。
泥酔して手持ちの機械を壊すみたいな悲劇を今後やらないようにしたい。
2022年に GPD Pocket をメインマシンにする為の備忘録
注:後述するように11年前のノート PC で充分な程度の使い方しかしない人間からみた「メインマシン」の記録です。
X201s が 2100 エラーで死んだので GPD Pocket を代わりに使う必要に迫られているのだが外部モニタつないだ状態だとこいつ5分に1回は死んで使い物にならんな
— 之貞 (@ngsksdt) 2022年4月20日
ひとまず動態保存してた X201s から引っこ抜いた SSD は認識したので X201s 側がイカれた訳ではない事がわかり、じゃあ Arch 入れ直すかと思ってやっていこうとしたところ、X201s とまた数年付き合うのかと考えたら急激に萎えてきてやる気なくなってきた
— 之貞 (@ngsksdt) 2022年4月20日
X201s は全く壊れず、SSD のほうがこれまでに3回壊れており、激安ストレージの信頼性の無さと X201s さの頑健さがわかる
— 之貞 (@ngsksdt) 2022年4月20日
あらゆるハードウェアがぶっ壊れてパーツも調達できなくなったときが X201s に別れを告げる時だと思ってたので「萎えた」為にこうなる事を全く想定しておらずとにかく悲しい
— 之貞 (@ngsksdt) 2022年4月20日
ということがあり、
GPD Pocket メインで過ごす事にして X201s 埋葬した
— 之貞 (@ngsksdt) 2022年4月20日
となった。Twitter が死んだ時の為にちゃんと言葉にしておくと、
- だいぶ前 に入手し それなりに前 に手直しをし使い続けていた ThinkPad X201s が 2100 エラー*1で起動しなくなった
- 動態保存してた SSD があったのでそちらを使って再度セットアップすれば X201s は復活する
- しかし X201s をふたたび使い続ける状況が突然億劫になった
- ずいぶん前 に入手した GPD Pocket を X201s の代わりに使うことにした
- ちょっと前 に入手した MacBook Pro もあるのだがやっぱり JIS 配列のマシンは常用できずお蔵入りになっている
という次第。
いままで GPD Pocket はオモチャ扱いというか、X201s を持ち歩くのは厳しいがパソコンを使いたくなるような時の供え(例:遠出する時にカバンに忍ばせておく等)といった用途で使用しており、あまり長時間酷使するといった用途では使っていなかった。
このため
X が突然刺さって死に別の tty にも切り替えられなくなるみたいな事がしばしば起きるのは困りものだが、まあそれ以外はあんまり不満がない
— 之貞 (@ngsksdt) 2022年4月23日
や前述のようなグラフィックスまわりの問題を何度も踏むということがあるという事実を今回初めて知るに至り、中々ストレスフルな時間を過ごす羽目になった。
X201s の起動ディスクが物理的に死んだりそのセットアップが億劫になるということは、GPD Pocket でも同じような状況になり得るということである。その時にまた同じ轍を踏んで更にウンザリすることにならないよう、GPD Pocket をなんとかメインマシンにでっちあげる為にやったことを記録しておく。
普段の使い方
- USB-A:トラックボール / キーボード / Web カメラ を使う為の USB ハブを繋いでいる
- USB-C:給電用の USB-A to USB-C ケーブルでほぼ常時 AC アダプタに繋いでいる
- microHDMI:microHDMI -> HDMI な変換アダプタを噛ませた上で HDMI にて このモニタ を繋いでいる
- 4K 対応のモニタではあるが使い手の目とモニタの大きさの都合で WQHD 程度に落として使っている
やったこと
セットアップ
Arch Wiki には GPD Pocket - ArchWiki という専用の項目があるが、ここで案内されている独自リポジトリは現在不要。公式リポジトリからふつうにインストールできる ALSA や Linux カーネルで十分に動作する。
音
前述の使い方においてはモニタ側のオーディオ関連を HDMI 機器として認識してしまうようだが、この場合 PulseAudio を使う場合に
- そもそも PulseAudio が起動しない
- PulseAudio が起動しても音が出ない
といった事象を踏む。これには以下で案内されている snd_hdmi_lpe_audio
を blacklist にいれる方法が効く。
具体的にはこんなかんじ:
$ ls -lah /etc/modprobe.d/blacklist-snd-hdmi-lpe-audio.conf -rw-r--r-- 1 root 29 Apr 22 01:33 /etc/modprobe.d/blacklist-snd-hdmi-lpe-audio.conf $ cat /etc/modprobe.d/blacklist-snd-hdmi-lpe-audio.conf blacklist snd_hdmi_lpe_audio
グラフィックス
Intel graphics - ArchWiki では xf86-video-intel
およびこれを使う X 向け設定は不要な 場合がある という注釈があるが、GPD Pocket においては modesetting ではなく素直に xf86-video-intel
を使ったほうが安定している感覚がある(私見であり定量的な評価ではない)。
これに加えて同じ項目の以下をやってあげれば大分安定してきた感がある:
あと一応 Backlight_and_KMS(GPD Pocket な ArchWiki 内の項目にあり)もやっておく。
解決できてない問題
いくつかある:
- 時々 GPD Pocket 本体側のモニタが突然グリッチした感じになり極彩色になる
- 放っておくとだいたい直る
- 内蔵 Wi-Fi チップ + iwd + systemd-networkd で 802.11 ac な 5GHz 帯の Wi-Fi アクセスポイントに接続できない
- iwctl で見ると SSID が見えないのでアクセスポイントを拾えていない感じがする
ところで
上記の問題以外についてはあまり GPD Pocket を使う上で困ることは無い。少なくともわたしのユースケースにおいては。
要するに X201s でやってきた程度のことは GPD Pocket でも充分やれるということだなあ
— 之貞 (@ngsksdt) 2022年4月23日
X201s で頑張ってきた結果、貧相なコンピューティングしかできなくなっていたという事実を突き付けられた気がした。
systemd-nspawn コンテナの中の web ブラウザからホストに繋いだ web カメラを使う
人生とは不思議なもので、掲題のようなことをしたくなることがある。
より具体的には意地でも専用のクライアントをインストールしない(できない)という決意の下で Zoom や Meet を使わざるを得なくなることがあり、Zoom や Meet を web ブラウザで使うには Chrome 系のそれを使うのが確実である*1。しかし依存関係で GTK が入る為 Chromium を入れたくないという事情がある。
システムに直接いれたくないアプリケーションを誤魔化し使うにはコンテナにして使うのがそれなりにラクなので、必然的に nspawn コンテナへ Chromium をインストールして Zoom や Meet を使うということになる。そしてこれらを使う事情というのは web カメラで映像を写し、マイクに音を拾わせる、といったことになる。
そういったことをやる為に四苦八苦し、結果としてなんとかなったので記録しておく。
前提
たぶんデバイスに依存しない内容にはなっていると思うが一応記載しておく。使っている web カメラはこれ:
準備
web カメラがどのようなデバイスとして認識されているかを確認しておく:
$ v4l2-ctl --list-devices HD Pro Webcam C920 (usb-0000:00:1a.0-1.5.3): /dev/video0 /dev/video1 /dev/media0
この場合は以下が設定対象のデバイスとなる:
/dev/video0
/dev/video1
/dev/media0
以下、本項では上記3デバイスを設定対象としてゆく。
設定
nspawn コンテナ側と systemd-nspawn サービス側の各設定を修正する必要がある。
以下では nspawn コンテナの名前を CONTAINER
とする。
nspawn コンテナ側
/etc/systemd/nspawn/
下に存在するはずの CONTAINER.nspawn
設定内 [Files]
下に以下を追加する:
Bind=/dev/video0 Bind=/dev/video1 Bind=/dev/media0
これでひとまず対象のデバイスが nspawn コンテナ側からも見れるようになる。設定の意味合いは systemd-nspawn のドキュメント が詳しい。
systemd-nspawn サービス側
/etc/systemd/system/systemd-nspawn@CONTAINER.service.d/
下に override.conf
を以下のように用意する:
[Service] DeviceAllow=/dev/video0 rwm DeviceAllow=/dev/video1 rwm DeviceAllow=/dev/media0 rwm
これも詳細は systemd のドキュメント が詳しい。要するに当該デバイス名で参照されるデバイスを適切に使えるよう設定をいれるといったもの。
nspawn コンテナ準備
CONTAINER
なコンテナが既に起動していれば再起動する。止まっていれば起動する。
もちろん CONTAINER
なコンテナで web カメラを使いたい X アプリケーションが動くようになっている必要もある。このあたりは以下の拙稿が参考になるかもしれない:
Chromium を起動
nspawn コンテナ内に Chromium を何らかの方法で入れ、ホスト側から起動する。そのあたりも前掲の拙稿を参考のこと。
おわり
Chromium も専用クライアントもインストールしたくないが Linux 上で Zoom や Meet を使わなければならなくなった方のお役に立てれば幸い。
参考
- systemd.resource-control
- Access webcam using OpenCV (Python) in Docker? - Stack Overflow
- systemd-nspawn - ArchWiki
*1:別のネタになるかもしれなかったので Qt5 を使うブラウザで検証した:
qutebrowser:遅いがなんとか使える。
Falkon:一見使えそうだがマイクが音をうまく拾えない。
Konqueror:マイクもカメラも認識しない。
ただし検証に使用した機械は ThinkPad X201s などという12年前の代物であり、パフォーマンスの問題は機械の影響である可能性が非常に高い。
DS61 V1.1 を買った + xrdp で RDP と仲良くなるまでのメモ
通して読んでみると別に RDP と仲良くなれてないな。まあいいか。そんなかんじの内容です。
前フリ
掲題のパソコンを友人から購入した。以下で紹介されているものを手頃な金額で譲ってもらえた。 hanjuku-am2.hatenablog.com
とくに目的のない買い物ではあった。悩む理由が金なら買え、という古からの金言に従ったかたちとなる。
手にいれてからしばらく放置していたのだが、宅内サーバ的な用途で動かしたり動かさなかったりしている ThinkPad X61 & X201s をこいつで置き換えてしまおうと思い立ち、いつもどおり Arch をいれて動かせるようにしてみた。
ちなみに後者はこれで入手したものである。もう3年もまえになるのだな……。
で、作業している間にこいつを Blu-ray 再生専用機に仕立て上げ、手元の PC(これも今だにこの X201s。もう6年も前か……)に負荷をかけることなく映画を観ようと思い至った。 xrdp あたりをいれて手元 PC へ RDP で映像と音を飛ばしてもらうおうという魂胆である。
で、やってみたのだが割と苦戦した。DS61 V1.1 の中の SSD が吹き飛んで再びセットアップしなくてはならなくなった時に泣かないよう、今回泣いた内容を記録しておこうと思う。ということで私的な備忘録であり体系立ってはいないメモをかく。
初期設定
Installation guide - ArchWiki に従い素直にやる。
とりあえずちゃんと動くようになったら yay とかをいれて AUR も使えるようにしておく。
sudo の設定をした上で必要そうなグループにもユーザをいれておく:
$ sudo gpasswd -a $USER users
X をうごかす
まずはお約束のやつをいれる:
# pacman -S xorg-server # pacman -S xf86-video-intel xf86-video-fbdev xf86-video-vesa
/etc/mkinitcpio.conf
の MODULES
に i915
をいれてカーネルイメージを作りなおすやつもやる:
# grep 'MODULES=' /etc/mkinitcpio.conf | grep -v '#' MODULES=(i915)
# mkinitcpio -P
おわったら再起動をする。
こんかい当初はデスクトップ環境という大物をいれるのはやめて i3 + ly でシンプルにやろうとした。が、挫折した。諦めて馴れ親しんだ KDE をうごかすことにした:
# pacman -S plasma
当初は SDDM もいれたが、xrdp でリモートデスクトップをやる場合はディスプレイマネージャが不要なので SDDM は不要であった。ゆえに消してある。これに気付くまでかなり時間がかかった。
要するに startx
みたいな感じで X が起動されるため .xinitrc
を $HOME
下に置かねばならぬということで以下のようにする:
(注:ここの '#' はプロンプトではなくコメントの意) # cat ~/.xinitrc export DESKTOP_SESSION=plasma exec dbus-run-session startplasma-x11
ディスプレイマネージャは不要ということがわかったので、次回おなじ作業をやるときは i3 でリベンジできるかもしれない。
音
PulseAudio でいいので以下のようにする:
# pacman -S pulseaudio pulseaudio-alsa
一応この時点で必要そうなグループにユーザをいれておく:
$ sudo gpasswd -a $USER audio
xrdp をうごかす
素直に以下のようにする:
$ yay -S xrdp xordxrdp pulseaudio-module-xrdp
今回バックエンドを xorgxrdp にしたので Xrdp - ArchWiki に従い /etc/X11/XWrapper.config
をつくる:
(注:ここの '#' はプロンプトではなくコメントの意) # cat /etc/X11/Xwrapper.config allowed_users=anybody
わたしの環境だと xrdp.service
が吊るしのままだとうまく起動しなかった。
どうもネットワーク系サービスの起動中にこいつが起きてしまうせいでコケるようだったので、こいつが依存している xrdp-sesman.service
を network-online.target
の後で起動させるようにしてみた:
(注:ここの '#' はプロンプトではなくコメントの意) # cat /etc/systemd/system/xrdp-sesman.service.d/override.conf [Unit] After=network-online.target
ここまでやったら以下のようにして xrdp が起動してくるようにしてやる:
# systemctl enable xrdp.service # systemctl enable xrdp-sesman.service
必要そうなグループにユーザをいれるやつもやる:
$ sudo gpasswd -a $USER video
Blu-ray を再生できるようにする
いつも mpv を使用しているのでそんな感じにやる:
$ sudo pacman -S mpv libbluray $ yay -S makemkv-cli $ yay -S makemkv-libaacs
makemkv-cli
の作業中に教えてもらえる以下もやる:
# echo sg > /etc/modules-load.d/sg.conf
必要なグループにユーザをいれる。これをしないと RDP セッション内で Blu-ray ドライブにアクセスできなかった:
$ sudo gpasswd -a $USER lp $ sudo gpasswd -a $USER optical
あとはよしなに mpv の設定をする。個人の好みがあると思われるので内容は省略。 カーネルモジュールを読み込む設定をやっているので作業のキリがよいところでマシンを再起動してやる。
RDP でつなぐ
KDE ユーザなので KRDC で繋ぐようにしてみた。適当に設定をして繋ぐ。ただしSound
は On This Computer
で PulseAudio
を選択してやる必要がある。
xrdp.service
がうごいていれば問題なく接続できるはず。
ただしこれだと pulseaudio-module-xrdp
をいれているにもかかわらず RDP セッション内からサウンドデバイスがみえない。どうしたものか。
RDP セッション内で音を出せるようにする
2日くらい難儀した結果、以下の情報をみつけた:
これに従い設定をしてみる。まずは以下をやる:
$ systemctl --user mask pulseaudio.service $ systemctl --user mask pulseaudio.socket
このとき RDP セッション内のターミナルから作業すると Failed to get properties: Process org.freedesktop.systemd1 exited with status
といわれて詰むので SSH などの別セッションから作業するとよい。
次にデスクトップ環境側から PulseAudio を起動させるようにする。KDE の場合は以下のようにする:
- System Settings を開く
Startup and Shutdown
->Autostart
Add
からAdd Application
を選択/usr/bin/pulseaudio
を実行するよう色々設定する- 画面内でコマンドを指定する箇所があるので絶対パスを入れてやればよい
Teminal options
はとくにいじらなくてよい
ここまでやって RDP セッションを一度落として(単にログアウトすればよい)再度立ち上げると無事に KMix あたりから xrdp sink
と xrdp source
が見えるようになる。これで RDP を経由して手元の PC から音が出るようになる。
やってみて
X201s に WQHD な解像度に設定したモニタを接続し、全画面で RDP して Blu-ray を再生してみた。
X201s で Blu-ray を再生した場合はほとんど全てのコマが落ちて観れたものではないのだが、RDP 経由だとガクつきがするがまあ我慢すれば観れるかな程度までなんとかなることがわかった。
モニタ解像度を Full HD 程度まで落とせば現実的な快適さで観れるようになるだろう。LAN 的な影響は考慮していない。
リモートデスクトップというものをやってみたい気持ちがずっとあったが、その気持ちをようやく消化できて有意義だった、というところでオチとしておく。