テクニカルプア

備忘録と若干の補足

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 変換アダプタ買った

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

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

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

Intel Dual Band Wireless-AC 7260 で 802.11ac な通信を実現した

気持ち的には

の続編な気がしないでもない。
なかでやっている事は全く異なるが。

インテル デュアルバンド 高速 Wi-Fi 通信Band Wireless-802.11 AC Intel 7260 最大リング867 Mbps+ Bluetooth 4.0 無線LANカード
これを買ったので X201s に実装した。Lenovo 謹製の BIOS だと ここで説明がある ように

1802: Unauthorized network card is plugged in Power off and remove the miniPCI network card

が出て起動出来ないのでいわゆる mod BIOS なるものをつかう(この mod BIOS の入手が今回の作業で一番時間がかかった)。
BIOS さえ通過できればあとは何も考えずにつかえる。ドライバ云々の問題は Arch Linux デフォルトの core/linux だと何もしなくても普通に動いた*1し、.config を触っている場合でも

CONFIG_IWLWIFI=m
CONFIG_IWLWIFI_LEDS=y
CONFIG_IWLDVM=m
CONFIG_IWLMVM=m
CONFIG_IWLWIFI_OPMODE_MODULAR=y
CONFIG_IWLWIFI_DEVICE_TRACING=y

あたりをやってカーネルコンパイルしなおせば動いた*2

こんなかんじ。ちょっと遅くなってる。
f:id:aaodsn:20161107210534p:plain

これであとパームレストとキーボード(どちらもだんだんヘタってきた)をとっかえれば X201s もまだまだ使えるなあとおもう。
でもパームレストとキーボードをチマチマ買うのと新しいパソコンを思い切って買うのとどっちが有意義なのだろうと考えてしまい、悶々としている。
物欲を割り切るのは難しい。

*1:4.8.6-1 で確認した

*2:2016-11-07 に AUR からとってきた linux-ck 4.8.6-2 で確認した

Nexus 5X 買った

f:id:aaodsn:20161015211116j:plain
Nexus4 の電源が入らなくなってしまった上にいくら充電をしてもウンともスンともいわなくなってしまった。ので買った。
Nexus9 と同様適当に CyanogenMod 13.0 をいれて常用できるようにした。
Nexus4 が突然死んでしまった慌ただしさの中で購入した(いちおう買い換えるとしたらこれかなという目星はつけていたものではあるが)ので、なんだかあまり感動がない。
Nexus Imprint は便利でよかった。

Nexus 9 買った

f:id:aaodsn:20160731220115j:plain

2012年に買った Nexus7 がヘタってしまってなにをするにも100年待たされる程に動作がもたつくようになってしまったので買った。
前からほしかったもののひとつだったが買ってみるとなんか別に買わなくても良かったんじゃないかと思えてきて心苦しい。
4万円弱で購入したがあと10万円程積んで Macbook Air とか買ったほうが良かったんじゃないかと思えてきた。

機械としてはなにも文句はない。
とりあえず CyanogenMod 13.0 をいれて普段使い用の環境は整えた。
買わなくても良かったんじゃないかという疑念を払拭できるすてきな用途を見出したい。