sngsk.info の現在
そろそろ三ヶ月以上更新されていない表示がされそうな雰囲気があるので書く。 だいぶ前に書いた下記の続編： nosada.hatenablog.com
現在 https://sngsk.info も https://mastodon.sngsk.info もしょぼいリソースしかない1台のサーバで動いている：
# ユーザ名やホスト名は適当に変えています
[user@remote-host ~]$ nproc
1
[user@remote-host ~]$ free -h
total used free shared buff/cache available
Mem: 1.9Gi 1.0Gi 76Mi 168Mi 890Mi 653Mi
Swap: 0B 0B 0B
[user@remote-host ~]$ uname -a
Linux remote-host 4.19.7.a-1-hardened #1 SMP PREEMPT Thu Dec 6 03:19:15 CET 2018 x86_64 GNU/Linux
sngsk.info で動かしているアプリケーションは先の記事では nspawn で動いていると書いたが、現在は Docker コンテナを docker-compose で動かすように改めている。これは下記によって nspawn 内で Nginx がうまく動かない為だ：
mastodon.sngsk.info については現在も nspawn コンテナで稼動している。 以前はもうちょっと潤沢なリソースが使えるサーバで動かしていたが、お金の節約のため前述のリソースしか使えないサーバに引っ越している。 その際にリソース不足ですぐアップアップになってしまったので下記を参考に PgBouncer やら puma / sidekiq のチューニングなどしてなんとか宥めることに成功した： docs.joinmastodon.org
sngsk.info やら mastodon.sngsk.info についての愚痴はだいたい toot として集約している： mastodon.sngsk.info
これは mastodon.sngsk.info がいつかフッ飛べば不浄な記録も全部消滅するだろうということを企図したためだ。自分が運用しているアプリケーションが今後も安定して動作しつづけるとは全く思っていないため、sngsk.info も mastodon.sngsk.info も基本的にはいつ消滅しても諦められるような気持ちで過ごしている。
Essential Phone PH-1 買った
Nexus5X 使うようになってからけっこう経ったしそろそろ買い替えるかあと思い、Essential Phone なんかいいんじゃないかなといろいろ調べてフームとなっていたところでIIJmio で Essential Phone が買えるようになったようでまあそれなら買ってしまうかとなり、サクっと買ってしまった。買ってから色々調べるともっと安く買えた時期があったようでちょっと哀しかった。
そして Nexus5X 使うようになってからけっこう経ったと書いたものの Nexus 5X 買った - テクニカルプア を見るとまだ2年も経っていなかったのだった。
これまでずっと Nexus 系統の携帯電話を使っていたのでほんとうは Pixel あたりを狙ったほうがよかったのだろうが、買いたいときに買いたいものを買ってしまって思い患いをなくしたほうが色々便利なのでそうした。どうやらPixel シリーズの新しいやつが日本で発売されるみたいな情報もあるらしい（信憑性は知らん）事を買ってから知ったので僻みも入っているかもしれない。
いまのところ stock の Android 9.0 で運用している。飽きたらカスタム ROM なりなんなりを調べ出すと思う。
ところで余談だが PH-1 を買ってから下記に突き当たってしまった。音声回線の維持に余計なコストを掛けたくないのでどうしようか思い悩んでいる。
FOMA 契約な SIM を刺してる Nexus4 を退役させ Nexus5X をその用途にあてて IIJmio な SIM を PH-1 に充てようと思っていたのだが Nexus5X で FOMA な SIM が使えないことを今日知ってこの始末をどうにかつける必要がでてきた結果とばっちりで PH-1 触る気力が失われてきた
— 之貞 (@ngsksdt) 2018年9月16日
systemd 239.0 で machinectl list-images の標準出力をパイプやリダイレクトで処理させようとすると assert して止まる
という事象がある。
これについては github.com で issue をつくった。
内容を追っていると assert() している箇所を消せば終わりな気がしたので github.com でプルリクもつくった。
先程プルリクを master にマージして頂いたのを記念して記事を書いている。
なお本件のワークアラウンドとしては /var/lib/machines/ 下をみてよしなにする以外の方法を思いついていない。
プルリクの中で
- 英語がずさんすぎる
- テスト書いてない
- レビュアーさんを急かす
ということをしていてだいぶひどいことになってしまった事をここで謝罪致します。
systemd 239.0 で machinectl import-(raw|tar) を使うと結果が返ってこない事象の迂回策
TL; DR
systemd-importを使うとよい。
/usr/lib/systemd/ 下にあるのでパスが通っていない場合は絶対パスで頑張る。
systemd のバージョン
Arch Linux を使っています：
$ systemctl --version
systemd 239
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid
$ machinectl --version
systemd 239
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid
$ pacman -Qs systemd
local/libsystemd 239.0-2
systemd client libraries
local/systemd 239.0-2 (base-devel)
system and service manager
内容
systemd 239.0 になってから machinectl のサブコマンドである import-raw と import-tar とで nspawn 用イメージのインポートができなくなった様子。
具体的にはインポートしたいイメージをこしらえてから machinectl import-raw や machinectl import-tar を実行しても transfer を enqueue したというメッセージ以降でコマンドが応答しなくなる（以下 import-raw を取りあげるが import-tar でも同じだった）：
# machinectl import-raw RAW_IMAGE Enqueued transfer job 1. Press C-c to continue download in background.
コマンドとしては何も返さないが、machinectl list-transfers をみるとイメージのインポートについての進捗が得られる：
$ machinectl list-transfers ID PERCENT TYPE LOCAL REMOTE 1 31% import-raw RAW_IMAGE 1 transfers listed.
しかし list-transfers が下記のようになり、machinectl list-images でインポートしたイメージが見れるようになっても import-raw はプロンプトを戻してくれず、ダンマリを決めこんでしまう。
$ machinectl list-transfers No transfers.
いろいろあって
https://www.freedesktop.org/software/systemd/man/systemd-importd.service.html によれば machinectl の import-(raw|tar) は systemd-importd の実装を借りているとのこと。
これを踏まえて import-raw 中に systemctl status systemd-importd を眺めていてみつけた /usr/lib/systemd/systemd-import を使ってみたところ、インポートの進捗がコマンドの応答として得られ、インポート完了後もプロンプトを返してくれた：
# /usr/lib/systemd/systemd-import raw RAW_IMAGE Importing 'RAW_IMAGE', saving as 'RAW_IMAGE'. Imported 0%. Imported 1%. Imported 2%. Imported 3%. Imported 4%. ... Imported 99%. Operation completed successfully. Exiting. #
いまのところ systemd-import を使うので特に問題なさそうなので、しばらくはこれでいこうと思う。
追記
issue あげた。勘違いとかでないとよいのだが。コメント欄の通り修正された。ご対応ありがとうございます。
pacman 5.1.0 の makepkg でのパッケージビルドが operation not permitted でコケる場合のワークアラウンド
pacman が 5.1.0
になった。
しかしながらこれに付属する makepkg でパッケージをビルドしようとすると、 /etc/makepkg.conf 内 BUILDDIR
に指定しているディレクトリによっては Operation not permitted となってコケる場合がある。
事象としては https://bugs.archlinux.org/task/58790
のとおりで、すでにバグとして報告されているの為そのうち修正ないし対策はされると思う。
ところでいつ対応されるかわからん状況をただ待っているのはつらいという向きもあると思う。 わたしもその質である。 そんな中いろいろやっていたらワークアラウンドをみつけたので書いておくことにした。
内容は単純で /etc/makepkg.conf 内 BUILDDIR で設定しているディレクトリを
makepkg する時に使用するユーザが所有するものに変更すればよい。
例えばログインユーザが hoge で hoge が fuga というグループに所属する場合、所有ユーザ及びグループが hoge:fuga なディレクトリを
BUILDDIR へ指定してやる。
わたしは普段 tmpfs としてマウントしている /ramdisk 内に scratch/ というディレクトリを tmpfiles
で勝手に作られるようにし、/ramdisk/scratch/ を /etc/makepkg.conf 内 BUILDDIR に設定している。
こいつは root:root で 0777 なディレクトリであるため、今回の事象に引っかかってしまった。
今回のワークアラウンドでは /ramdisk/scratch/nosada/ というディレクトリを新たに作成して適当なユーザ及びグループに所有させるように
tmpfiles へ設定を追加し、これを BUIILDDIR に設定するようにした。
これで pacman 5.1.0 の makepkg でもパッケージがいつもどおりビルドされるようになり、不安が解消されるに至った。
めでたし。
GPD Pocket 買った
確か去年秋の OSC Tokyo だと思うのだが、実際に動いている GPD Pocket を少し触らせてもらい、これはいつか欲しいなと思った。 月日が経ちそんな記憶も薄れたところで先々週くらいに偶然中古 PC 屋さんで GPD Pocket が売られているのを見付けてしまい、そういえばこんなものもあったなあと懐しみを覚えたのちに物欲がふつふつと沸いてきたのだった。
で、買った。実物を見掛けたのは中古 PC 屋だが買ったのは新品だ。Amazon で買った。
Windows 版を買ったのだがわたしは Windows を使えないので Arch Linux をいれている。先人の蓄積をありがたく流用し、GPD Pocket 固有の問題ではとくに躓くことなく Arch のインストールができた。
ちいさい鞄に適当に入るそれなりのパソコンが手に入ったのでとても満足度が高い。携帯電話を持ちあるくような気軽さでパソコンが持ち運べるのはとても嬉しい。
nspawn コンテナのなかで X なアプリケーションを動かす
追記：
当初の記事ではコンテナ内 qutebrowser を起動させるときに systemd-nspawn -M CONTAINER
という感じのコマンドを使用していたが、これはコンテナが登録済み（machinectl list
に使用したコンテナが表示される状態）では上手く動かないことがわかった。
環境変数を直打ちしないといけない面倒さはあるが machinectl shell で同様のことができるようなので、本文中は machinectl
コマンドに差しかえしている。
動機
人生オワタの大冒険 みたいな Flash ゲームをたまにやりたくなる。 が、2018年にもなって手元の PC に Flash を入れたくはない。
いままでは LiveUSB かなにかで起動した GUI に Flash をいれて凌いでいたが、ゲームやるためだけに PC 起動しなおすみたいなのはしたくない。
なんとかしたいなと思いチマチマ調べたり手を動かしていたものがやっとできるようになったので書く。
加えて昨今はコンテナ内で X なアプリケーションを動かすことが流行っているような印象があったので、流行にのれそうなチャンスを活かしたいという気持ちもあった。
やったこと
個人的な事情で make するときに reflector が必要。まずこれをインストールする：
# pacman -S reflector
そのあと mkosi-files/guispawn at master · nosada/mkosi-files · GitHub を手元にもってきて
# make # make install
したあと
$ xhost +local: $ machinectl start guispawn $ machinectl shell -E DISPLAY=:0 -E XAUTHORITY=~/.Xauthority -E PULSE_SERVER=unix:/run/user/host/pulse/native gui@guispawn /usr/bin/qutebrowser
すれば Flash の動く qutebrowser があがってくる。 この qutebrowser は nspawnコンテナのなかで動くので、Flash 関連の諸々がホストに入ることもない。
ブラウザに qutebrowser を使っているのは筆者が qutebrowser のファンであるため。
nspawn へ与える設定
[Exec] Environment=DISPLAY=:0 Environment=XAUTHORITY=~/.Xauthority Environment=PULSE_SERVER=unix:/run/user/host/pulse/native PrivateUsers=true NotifyReady=true [Files] BindReadOnly=/tmp/.X11-unix/ BindReadOnly=/etc/resolv.conf Bind=/run/user/1000/pulse:/run/user/host/pulse Bind=/dev/snd Bind=/dev/shm [Network] # Private=yes # VirtualEthernet=yes
Network セクションは好みにあわせて変更する。
こんな設定を /etc/systemd/nspawn/ 下に コンテナ名.nspawn で作成してコンテナを作れば、コンテナ内で X
が使え、それをホストから参照できるようになる様子。
備考
人生オワタの大冒険は tanasinn の倒しかたがわからず進捗していない。
