テクニカルプア

備忘録と若干の補足

nspawn コンテナのなかで X なアプリケーションを動かす

追記:

当初の記事ではコンテナ内 qutebrowser を起動させるときに systemd-nspawn -M CONTAINER という感じのコマンドを使用していたが、これはコンテナが登録済み(machinectl list に使用したコンテナが表示される状態)では上手く動かないことがわかった。

環境変数を直打ちしないといけない面倒さはあるが machinectl shell で同様のことができるようなので、本文中は machinectl コマンドに差しかえしている。

動機

人生オワタの大冒険 みたいな Flash ゲームをたまにやりたくなる。 が、2018年にもなって手元の PC に Flash を入れたくはない。

いままでは LiveUSB かなにかで起動した GUIFlash をいれて凌いでいたが、ゲームやるためだけに 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 の倒しかたがわからず進捗していない。

参考

ThinkPad X201s 買った(2枚目)

秋葉原を歩いてたらジャンクの X201s が他のジャンクな PC と一緒に棚へ詰め込まれていたので買った。

液晶割れあり、メモリおよびディスク無し、外装割れなくも汚ない、割合きれいな US キー付き、タッチパッドありで6000円也。型番は 5129CTO。 画面割れは残念だけれど*1 US キーつきでこの値段はお買い得だったと思う。

持ち帰ってから細部を確認したところ AC アダプタのジャックや USB ポートなどの状態がだいぶ前に買っていまだ現役の X201sよりも良いことが判明した。部品単位で引き剥すのが面倒臭いのと下半身の外装が綺麗なのとを鑑みて旧来の X201s とニコイチにすることにした。いまこの記事はニコイチにしたあとの X201s で書いている。

2018年にもなってまだ X201s を使い続けているとは正直以外だった。 とっくの昔に ThinkPad に見切りをつけて他の機械を使っていると思っていたし気持ちとしては今もそうなのだが、結果として今も X201s を使い続けている。 あたらしい機械を買おうとしてもどうも食指が動かず結局 X201s を使いつづけてしまう。 最近はちょっと諦めの境地に逹しつつあり、X201s でダメになる日が来るまでは X201s を使い続けようと思うようになった。

*1:意地でも X201s を使う理由って 1440 x 900 な画面だからだとおもう

近況

放置しすぎて広告が出てしまうようになったので書く。
それぞれ別個の記事にしてもよいのではと思うのだが、いかんせんネタを膨らませるに至らなかったので纏めて書く。

SKK 導入

mozc の更新がもう一年以上止まってるよねという話があちらこちらで目に入るようになったので、そういえばそうだなあと思い移行先を考えた結果として SKK を選ぶに至った。
下記のようにしておわり(普段 Fcitx を使っている為こうなっている):

$ sudo pacman -Rscnu fcitx-mozc-ut
$ sudo pacman -S fcitx-skk skk-jisyo skktools

設定や辞書の追加みたいなやつは kcm-fcitx などが入っていれば systemsettings から適当に出来る。

SKK 自体のお作法に不慣れな部分もまだかなり有るが、一通りの文章を書けるようにはなった。
この記事も SKK で書いている。

「おみくじ」や「う゛ぁーじょん」などを変換して遊んでいた時分が懐かしい。

pacaur から aurutils への乗り換え

pacaur が2017年12月15日を以って更新を停止したようなので、移行先を探さねばなあと思いいろいろ探し回っていた。
以前使っていた yaourt へ戻るのでもまあ良かったのだが、せっかくなので bauerpill や auracle 等いろいろ試して回った結果として aurutils を選んだ:

$ sudo pacman -Rscnu pacaur cower
$ sudo pacman -S pacutils
$ git clone https://aur.archlinux.org/aurutils.git
$ cd aurutils/
$ makepkg -sri

aurutils を使用する場合 pacaur とは異なり AUR のパッケージを別レポジトリとして管理しなくてはならないようなので、そのあたりの設定もあわせて実施した。
このあたりは aurutils の man が詳しい*1

pacaur とは異なり操作内容によりコマンドが分離しているので慣れるまでは取っつきづらいと感じたが、これはまあ時間が解決してくれるだろうとは思っている。
pacaur で特にトラブルが無ければそのまま pacaur を使用し続けたと思うので、悲しいことに全てが pacaur の比較になってしまう……。

*1:man をよく読まなかった結果つまったのでここで恥を晒しておく。 man に従えば /etc/pacman.d/ 下にレポジトリを定義する設定ファイルを作り、それを /etc/pacman.conf で Include する。このとき /etc/pacman.d/ 下に置く設定ファイルと /etc/pacman.conf 内の記載とで同一セクション名でレポジトリを設定するとエラーとなってしまう。 要は /etc/pacman.d/ 下でレポジトリを定義してそいつを単に /etc/pacman.conf で読み込ませればよい。 私はこれを勘違いして結構悩んだ。

mkosi をつかって nspawn 用のコンテナイメージをつくる

2017-07-19 追記:

下記で GitHub 上においてある mkosi を使用してコンテナイメージをつくる設定ファイルを紹介しているが、いろいろいじくった結果この記事で紹介した内容と使い方がかなり乖離してしまうようになってしまった。
もし使用される際は README を参照のこと。

mkosi という OS イメージをいろんなフォーマットでいい感じに作れるものがある。
github.com
これを使うと、いままで

$ mkdir container
# pacstram -i -d container base
# tar cvf container container.tar
# machinectl import-tar container.tar

とかしてたやつが

# mkosi
# machinectl import-tar container.tar.xz

くらいでよくなる。
何も考えずに mkosi 叩くだけでもホストと同じ OS でコンテナを作ってくれたりといい感じに動くのだけれど、設定ファイルとかコンテナ内に置いておきたいファイルなどを事前に用意しておけばもっとよしなにやってくれるということなので、早速作ってみた。
github.com

archlinux しか知らないので archlinux 用の書き方とかファイルを使うようになってしまっている。
mkosi コマンドは AUR にしかないので、

$ pacaur -S mkosi

などしたあと、上のリンクからレポジトリを引っ張ってきて、

# mkosi

とすると、corespawn.tar.xz という名前で圧縮ファイルができる。
これを展開して systemd-nspawn に直接食わしてもよし、machinectl import-tar で取り込んで machinectl start してもよしで、作ってしまえばどうにでもなる。

レポジトリの中身は下記の通り(主要なものを記載)

.
├── mkosi.default     # 設定ファイル
├── mkosi.extra       # コンテナ作成後にコピーしたいファイルを入れる
│   ├── pacman.conf  # pacman 設定ファイル(ILoveCandy とか追記してあるだけ)
│   └── securetty    # machinectl login で root ユーザからのログインがこけるので pts/0 を追記してある
└── mkosi.postinst    # コンテナ作成後にコンテナ内部で実行するスクリプト

mkosi.default は作りたいコンテナで使う OS やパッケージ、出力するファイル形式などを指定する。
注意すべきは mkosi.extra/ で、この中にいれたファイルはコンテナ内の / 下にすべて置かれてしまう。mkosi.extra/ 単体ではいい感じのパスにファイルを置くなどはできない。
こういうことをしたければ mkosi.postinst としてコンテナ作成後に実行するスクリプトを用意し、その中で mv などをするようにするとよい。

pacstrap でやるのがめんどくさかったり pacstrap でのコンテナ作成作業をシェルスクリプトで書いていたりする場合には mkosi を使うと便利になったりするかなあと思った。

nspawn コンテナに対して machinectl login とかしないでホストからコマンドをたたく

TL; DR

nsenter を知りませんでした。

本題

nspawn コンテナのパッケージを更新するときにわざわざ

$ machinectl login <コンテナ>

して PolicyKit の諸々を通過した後

# pacmatic -Syu
# pacman -Scc
# pacman-optimize

などをするのが面倒で、これをなんとかする方法をずっと探していた。そしてそれをやっと見つけた。
util-linux パッケージの中に含まれている nsenter というコマンドを使えば出来る。

参考にしたサイトに掲載されていたやつをほぼマルっとパクって下記を書いた:
update packages for arch linux nspawn container

pacmatic ではなく pacman を使っているのは yes コマンドで問答を潰すにはいささか面倒な事態に陥る事が多々あるため。

余談

nsenter で調べるとこういうことやってる情報がそれなりに出てくる。
わからないことを調べるのにも背景の知識が必要ということがよくわかった。
nspawn でやりたいことを解決するのに詰まったら根底にある namespace とか cgroup まで戻るのが大事。

*1:"nspawn nsenter" でググると一番上にでてくる。言葉を知っているとすぐ見つかる。

sngsk.info について(nspawn 活用の記録)

90日以上更新されていないブログに表示されてしまうアレが出てしまったので書く。

https://sngsk.info というサイトがあり、わたしはこいつを運営している。
このサイトの下でいちおうコンテンツとよべるやつは下記のものがある:

これらは下記のように2台のインスタンスにまたがり、リバースプロキシとしての Nginx と、それにぶら下がる nspawn コンテナで構成されている:

メモリ 512MB のインスタンス
  • sngsk.info および mastodon.sngsk.info のリバースプロキシ(Nginx)
  • sngsk.info のコンテンツをもつ nspawn
メモリ 2GB のインスタンス
  • mastodon な nspawn へ HTTP リクエストを転送するための Nginx
  • mastodon.sngsk.info のコンテンツをもつ nspawn

図はこんな感じ

       |
       |  HTTP request
       |
  -----------
  |  Nginx  | *
  -----------
       |
       |                                  -----------
       |----------------------------------|  Nginx  | **
       |                                  -----------
       |                                       |
       | sngsk.info                            | mastodon.sngsk.info
       |                                       |
----------------                     -------------------------
|   nspawn     | *                   |        nspawn         | **
| (sngsk.info) |                     | (mastodon.sngsk.info) |
----------------                     -------------------------

*  : RAM 512MB instance
** : RAM 2GB instance

以前まではメモリ 512MB のインスタンスしか無かったのだけれど、Mastodon を使ってみたら思いのほかリソースを食ったので急遽追加した。
設定とかは全部 https://github.com/nosada/sngsk.info にある。nspawn のコンテンツも可能な限り追加している。

nspawn を使っていると QEMU 上でうごく VM をお世話するみたいな感じで適度にコンテナ自体のお世話をする必要があるなあと感じる。
Docker みたいにコンテナをバカスカおっ立てては潰すみたいな使い方も無論可能ではあるが、それをやるには道具のお膳立てがまったくない。
Docker みたいに nspawn を使ってみたいという気持ちもあるけどそれなら Docker でいいじゃんとなってしまうので、難しい。

ちなみに上記のコンテナおよびホストは全部 Arch Linux で構成されている。
Arch Linux 以外での nspawn の使い方をいまだによくわかっていない……。

MiniPCIe - SDHC 変換アダプタ買った

http://www.aitendo.com/product/5034www.aitendo.com
これ買って適当に買った SDXC カードを差して X201s の空き Mini PCI Express スロットに突っ込んだ。
なにかしくじるかなと思ったが特になにごともなく無事に起動 & 認識していい感じになった。
上記では 32GB まで対応とあるが、今回刺した SDXC カードは 64GB のもの。今の所 OS から見えるし読み書きも普通に出来る。

I/O の性能はどんなかなとおもい適当に /dev/urandom をソースに dd してみたりしたが、X201s にもともとついている SD カードスロット(速度がでないことで有名)と対して変わらない速度しかでていなかった。その意味ではちょっと残念だった。
fio を頑張るまでの気力はないのでその意味では不正確な確認結果にとどまる。
用途的には別に速度を求めているわけではないのでまあこれでもいいかねという感じ。

本当は上海問屋の同様な製品(これ)をつかうつもりだったけどディスコンになっているようで手に入らなかった……。