テクニカルプア

備忘録と若干の補足

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 を頑張るまでの気力はないのでその意味では不正確な確認結果にとどまる。
用途的には別に速度を求めているわけではないのでまあこれでもいいかねという感じ。

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

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 をいれて普段使い用の環境は整えた。
買わなくても良かったんじゃないかという疑念を払拭できるすてきな用途を見出したい。

松花堂弁当と妄想

浜松の友人が ThinkPad について懐古していたので、こちらも懐古してみようと思った。これに加えて最近ずっと考えていることも文章にしてみるつもり。

現在に至ってもまだ手元では X201s がメインのマシンである。X220 に移ろうかなと思うこともあったが、これはどちらかというと X220 を使いたいという気持ちではなく物欲の発散に近いものがあると自分でもわかっていたので押さえ込んでいた。
おそらく今の X201s が私の最後の ThinkPad になるような気がしている。X201s が修理不可能な状態まで崩壊してしまうか物欲が臨界点を超えて爆発したら MacBook Pro あたりを新品で買うのだろうなと思う。ThinkPad 生活も中古 PC 生活も終焉である。

ThinkPad を使い始めたのは X40 が最初だった。その後部品を買い集めて X41 を組み、気の迷いで X32 を買って放置し、スペック不足に悩んで X61 を買い、なんかよくわからん間に X60 やら X61s が手元に湧いてきたりした。B5 ノートしか使うつもりはないみたいな事をいいながら T61 を買ってつかってみたら便利で手放せなくなったというようなこともあった。その後 X200 を買い、ThinkPad の終焉を悲しんで X201s を買い、今に至る*1
X40 や X41 は薄くて軽くて使いやすい素敵なマシンだった。ただし性能不足は如何ともしがたく、あれこれシステムボードを買い換えたりディスクを ZIF -> IDE 化したり SSD 化したりいろいろし、バラバラに分解ということも何回もやった。このころ普段つかう OS を Windows から GNU/Linux にかえた。
X61 になってから突然筐体が分厚くなりパームレストが熱くなった。事前情報として知っていたのでうろたえはしなかったし、スペック向上のトレードオフなのだろうなと考えている。X60X61、X61s についてもシステムボード交換を含め何度もバラバラに分解し、手垢がつくほど様々なところをいじくりまわした。いちばん中身をいじくり回したマシンは X61 だと思う。
X200 や X201s にしてから横幅が広がり、画面の解像度が高くなった。横幅が広がったのは当初戸惑ったが慣れるに従い X61 の画面が狭く感じるようになったことが印象深い。 この世代になってから中身をあまりいじらなくなった。
X32 や T61 は忘れた。

いま手元に残っているのは X41、X61、X201s のみ。
中古 PC 屋やジャンク屋、ヤフオク等を漁ることもしなくなり、以前は暇さえあれば行っていた意味のない分解もしなくなった。
ThinkPad の終焉に伴い、次はなにを買おうか、次はどの部品を替えようかという気持ちもなくなった。単に老化かもしれないが。

ローカル PC のスペックは少なくとも個人用途に限ればクラウドなりなんなりでどうとでもなる昨今の事情をみるに、「いかに高性能なマシンを入手するか」ではなく「いかに使いやすい道具を仕入れるか」「いかに手に馴染む道具を手に入れるか」という方向で PC を選んだほうがいいとずっと考えている。
この「使いやすい道具」「手に馴染む道具」がいままでずっと ThinkPad だったわけだが、未来の*2 ThinkPad

という理由でどうしても使いやすい或いは手に馴染む道具であるとは思えず、他の機種へ鞍替えが必要になってしまった。
逆に言えば既に今使いやすい道具が手元にあり、それが崩壊せず完動するならばその使いやすい道具を維持管理すれば良いわけで、未来の ThinkPad に絶望するよりはいま動いている X201s をお世話するほうが有意義である。

古くて使いやすいものをずっと使い続けられる昨今の状況を嬉しく思う反面、死屍累々の未来を眺めるのがとても悲しい。

*1:以上全部中古およびジャンク品

*2:中古目線での「未来」であることに注意

systemd-nspawn を軽くつかって得られたことの記録

docker みたいなことをしたかったが docker よくわからんかったので systemd-nspawn に逃げてみたらいい感じだったので適当につかってみた。
その記録。

systemd-networkd がホストで動いていることが前提(っぽい)

systemd-nspawn は systemd-networkd の機能をガンガンつかっていく。
なので NetworkManager とか netctl とか使っていると痛い目をみる。

ホストからコンテナへの通信

ホストからコンテナへ通信するためには /etc/nsswitch.conf の

hosts: files resolve myhostname

hosts: files mymachines resolve myhostname

にする。これでコンテナのホスト名で名前解決ができる。

ポートフォワード

systemd-nspawn (もしかしたら systemd-networkd の範疇かもしれない)のポートフォワードは結構あてにならない(少なくとも私がやってみたところでは全然うごかなかった)。
web サーバとかを systemd-nspawn でやる場合、ホストでリバースプロキシとかを動かしておいてそこからコンテナにリクエストを転送するようにしたほうがよさそう。

コンテナをおくファイルシステム

ベースになるコンテナをひとつこさえて、いろいろやるコンテナを先のベースコンテナから派生して作りたいとなった場合、

$ machinectl clone <ベースコンテナの名前> <いろいろやる予定のコンテナの名前>

とやって派生したコンテナをつくるが、ここで作られるコンテナは Btrfs の subvolume をつかって作られているので、systemd-nspawn がデフォルトでコンテナを置くディレクトリである /var/lib/machines/ は Btrfs 上に作成されなくてはならない。
そうでないと

Failed transfer image: /var/lib/machines is not a btrfs file system. Operation is not supported on legacy file systems.

とかいわれてコンテナの複製に失敗する。
これを回避する方法として一度

$ sudo machinectl export-tar <ベースコンテナの名前> <適当な名前>

でベースコンテナをエクスポートし、

$ sudo machinectl import-tar <エクスポート先のアーカイブ名> <いろいろやる予定のコンテナの名前>

でイメージをインポートし、ここでいろいろやる、とものがある。ただこの方法はめんどくさいし時間もかかってよくない。

コンテナでは sshd を動かしておいたほうがいい

コンテナ起動後

$ machinectl shell <コンテナのホスト名>

とかでコンテナに入って操作ができるけど、ちまちま操作するのはめんどくさいので Ansible でササッとやってしまいたくなる。
このとき sshd が動いてないと困るので、コンテナをつくるときにあわせて sshd を入れておくのがよい。

(2018-04-01 追記:意地でも Ansible でコンテナをセットアップしたいとかでなければ mkosi をつかったほうが今は良いと思う。mkosi をつかって nspawn 用のコンテナイメージをつくる - テクニカルプア も参照のこと)