- BSDデスクトップやchroot、jailをよく使うユーザーが Alpine Linux を試し、セキュリティ・シンプルさ・リソース効率を重視した設計がBSDユーザーにとってなじみやすいと見ている
- 小さなサイズと限定的な依存関係のおかげで、Alpineは コンテナのベースイメージ だけでなく、組み込みシステム、ルーター、モバイル機器、サーバー、デスクトップまで幅広く使われている
- インストールはライブ環境で
setup-alpine を実行し、キーマップ、ネットワーク、タイムゾーン、SSH、NTPなどの 基本設定 を順に行う方式
- 初回起動後には OpenRC、
musl、busyboxの組み合わせが見え、/etc/rc.conf や crond(8) などの要素がBSD式rcの体験と通じている
apk によるパッケージ管理、リポジトリ設定、ZFSインストールの可能性まで確認したうえで、テスト用およびサーバー用の メインLinuxディストリビューション候補 として真剣に検討するほど好印象を受けた
BSDユーザーになじみやすいAlpineの性格
- Alpine Linuxは、セキュリティ、シンプルさ、リソース効率を重視するパワーユーザー向けの 独立・非商用・汎用Linuxディストリビューション
- ユーザー空間のバイナリは PIE（Position Independent Executables） とstack smashing protection付きでコンパイルされており、特定のゼロデイや脆弱性悪用を減らすことに重点を置いている
- Natanael Copaが2005年にプロジェクトの起源について議論していたほど、Alpineは予想以上に歴史のあるプロジェクト
- BSD系と同様に、組み込みシステム、ルーター、モバイル機器だけでなく、一般的なサーバーやデスクトップでも使われている
- 小さなサイズと限定的な依存関係のため、Linuxコンテナの ベースイメージ として広く使われており、
chroot(8) で簡単に実行するための alpine-chroot-install のようなツールもある
- NetBSDの
chroot(8) やFreeBSD jailをテストとデプロイに多用するユーザーにとって、特に興味深い点
インストール体験
- AlpineはARM、PPC64、x86、x86_64など複数のビルドを提供している
- Xen ISOイメージをVMで起動したが、Dom0をDomUと読み違えた選択だった
- Dom0はXenハイパーバイザーを指し、ゲストではない
- それでも標準ISOのように起動とインストールは進んだ
- インストールはライブ環境で
root と空のパスワードでログインした後、setup-alpine を実行する方式
- インストール中は キーマップ、ネットワーク、タイムゾーン、root認証などの基本項目を順番に設定する
- 開始段階でSSHキーを注入できる
- その後、オーケストレーションツールでVMやサーバー群をデプロイする際に有用
- OOBコンソールを提供しないホスティング環境でも役立つ
- SSHサーバーとNTPクライアントを選択でき、OpenSSHとopenntpdを選べた
- インストール過程では、Xen上で動作中であることを正しく検出した
- LVM設定も可能だが、今回はAlpineが
sys パーティションと呼ぶ標準構成を選択した
初回起動後に見えるシステム構成
- 初回起動後、
dmesg(1) でシステムが OpenRC を使用中であることを確認できる
- OpenRCは、移植性、小さなサイズ、高速性、効率、透明性、セキュリティを備えたinitシステム
- BSD式rcスクリプトの作成に慣れているユーザーにとって、OpenRCは非常になじみ深い
/etc/rc.conf や crond(8) などの要素がBSDユーザー体験と通じている
- Devuan、Gentoo、AlpineのようにOpenRCを使うLinuxディストリビューションがあり、Linuxが再び面白く感じられる
- AlpineはOpenRCとともに musl を含み、busyboxを使用する
- muslとbusyboxはGCCやGNU coreutilsより制限があるが、ベースシステムの 小さなサイズ と攻撃対象領域の縮小に貢献している
- llvmも利用できる
- MirBSD Korn shellもパッケージとして提供されており、好みの対話型シェルの一つ
パッケージ管理とリポジトリ
- Alpineの標準パッケージマネージャーは apk
- Linuxで一般的な方式と同じく、
apk はベースシステムとパッケージを区別せず、まとめて更新する
- BSDのように権限のないコピーとして実行できるかは、まだ確認していない
- pkgsrcも利用できるため、代替手段は残っている
- リポジトリ設定は
/etc/apk/repositories にある
- インストーラーが提示した2つ目のURLのコメントを解除すると、communityリポジトリ を有効化できる
- Alpineには
testing リポジトリもあり、独自リポジトリも追加可能
- 使い方はシンプルだが、これまでの習慣で
apk add の代わりに apt install と誤入力してしまうこともある
- 公式パッケージWebインターフェイスは pkgs.alpinelinux.org にある
- Alpineのリポジトリは pkgs.org でも確認できる
ZFSとサーバー用候補としての評価
- いくつかのパッケージをインストールした後、コンソール専用ノートPCで使っていた「必須ツール」構成をそろえることができた
- 最も驚いたパッケージの一つは ZFS だった
- インストールとカーネルモジュールのロードは2つのコマンドで可能だった
# apk add zfs zfs-lts
# modprobe zfs
- rootファイルシステムをZFSで構成する作業は、より複雑になる可能性がある
- アップグレード後にZFS構成がどう動作するかは、まだ確認していない
- これまでの経験だけでも、テスト用およびサーバー用のメインLinuxディストリビューションとして 移行を真剣に検討 するほど印象は良い
htop(1) と lsof(1) で認識できる少数のプロセスしか見えない点、OpenRCの使用、シンプルに見えるパッケージ管理、容易な設定が利点として挙げられる- モダンで機能的な「Occam’s Linux」があるとすれば、Alpineはそれに近い姿だと評価している
- busyboxより多くの機能が必要な場合は uutils を実行してみることもできるが、サーバーでは必要性は低そうだ
1件のコメント
Hacker News の意見
セキュリティの観点で見ると、最近の Linux バイナリはほとんど PIE でコンパイルされている
Ubuntu の任意のバイナリに
checksecを実行してみるとそうした属性が表示されるし、pip install pwntoolsでchecksecをインストールできる一方で GLIBC は、私の知る限り最も堅牢化されたヒープ実装を持っており、二重解放やその他のヒープ攻撃に対する緩和策もより多い
なのでその面では、Alpine は musl を使っているため安全性が低いと見なせるが、小さく理解しやすいシステムであることはセキュリティ上、本当に大きな利点だ
checksecを実行しているが、プロセスはすべてこんな感じで表示される。出力全体は長いので省略するが、Alpine がビルドしたものでこれらのフラグが抜けているものは見たことがないCOMMAND PID RELRO STACK CANARY NX/PaX PIEinit 1 Full RELRO Canary found NX enabled PIE enabled[snip...]crond 422838 Full RELRO Canary found NX enabled PIE enabled正直なところ、現代の Windows と macOS のほうがどちらもより優れた セキュリティアーキテクチャを持っていると思う
私も BSD 寄りの人間で、偶然にも今週、bhyve 上の VM で Alpine を初めて動かしてみた
重要なのは BusyBox だ。
/binと/sbinのユーティリティがそれぞれ独立したバイナリである必要がなければ、ユーザー空間は非常に小さく、起動も速い。Tmux と zsh くらいを入れたら、たいていの Unix 用途には十分だった最終的な環境にするまでには
apkでかなり多くインストールすることになったが、全体としては久しぶりに味わった最高の Linux 体験だった。ZFS が標準で入っていて、bhyve の ZFS ベースの実行に合わせた virtio 接続がもっと明示的だとよいと思うそれでも正気な Linux ディストリビューションがあるかもしれないと聞けるのはうれしいし、Linux マシンが必要になったら一度試してみるつもりだ。ただ、そういう機会はかなりまれだ
apkコマンド一発でほぼインストールできるAlpine Wiki には、ルートファイルシステムを ZFS にしてインストールするための文書もかなりよくまとまっている: https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_en...
BSD ユーザーなら Void Linux も気に入るかもしれない。NetBSD 開発者の xtraeme が作ったディストリビューションで、glibc 版と musl 版があり、init システムには runit を使っている
xbps-srcでソースからパッケージをビルドすることもできるhttps://voidlinux.org/
ただし、最小限の変更だけを加えた xfce インストールしか使っていない点には注意が必要だ。複雑なマルチユーザー構成では、runit は systemd より標準搭載の機能が少ないため、少し面倒になるかもしれない
BSD たちが誇る man ページが Alpine には標準で含まれていない、という話が出ると思っていた。それが旅行用ノートPCで Alpine を使わなくなった理由の一つで、今は OpenBSD を使っている
Alpine でパッケージを入れるとき、ドキュメントが常にインストールされるようにする設定オプションを私が見落としているのだろうか？ それとも毎回
-docパッケージを手動でインストールするしかないのか？docsメタパッケージをインストールすればよい。以後インストールする項目に対応する*-docパッケージを引っ張ってきてくれる人々がなぜ OpenRC のようなものを魅力的だと感じるのか、正直まったく分からない。監視ベースの方式なら何であれ、PID を吐き出して PID ファイルに保存し、3週間後にもその値がまだ起動したデーモンを指していることを願う方式よりは良いと思う
しかも場合によっては、特定のプロセス名を
pgrepしてサービス管理作業を処理することもある。すべてをデフォルトで自動再起動すべきではないという考えにはある程度同意するが、この手のものが掲げられる長所は実質的にそれだけだまた結局、こうしたものは syslog に大きく依存しているが、これはまさに80年代の技術そのものだ。
multilogやsvlogdのようなツールは、複数のツールで起きた出来事の順序を一目で見られる中央ビューをより簡単に提供できるよう改善できるかもしれないが、曖昧なカテゴリでログをまとめ、誰でも任意の名前でどこにでもログを残せるようにする機能は奇妙に感じるhttps://mastodon.social/@ariadne@treehouse.systems/112044942...
https://mastodon.social/@ariadne@treehouse.systems/112214386...
PID1 の中にあまりに多くの処理が入っており、メモリ安全ではない言語で書かれている。最小限の PID1 といくつかの setuid プログラムに分けられない技術的理由は見当たらない
Docker コンテナ内で systemd を動かせるようになる点以外には思いつかないが、Red Hat/IBM は systemd-nspawn のような自社のコンテナ化ツールを使ってほしいはずなので、それを強く望んでいるとは思えない。今の構造では、セキュリティの観点から到底妥当にはなり得ないと思う
Alpine には面白い利点がある。Nix ユーザーが 宣言的パッケージ管理を自慢するとき、
/etc/apk/worldを直接編集してapk fixを実行し、Nix なしでもどうやるかを見せられる/var/lib/portage/world、選択した集合は/var/lib/portage/world_sets、集合定義は/etc/portage/sets/に置けるこうすればパッケージをカテゴリ別に分け、必要なシステムにだけ一部をインストールし、ファイルにコメントも好きなように追加できる。
apk fixに相当するのはemerge -uDU @world && emerge -cだが、少し面倒ではあるAlpine でも
apk add -t setname pkg1 pkg2 pkg3で集合に似たものを作れるし、そうすると選択したパッケージに依存するダミーパッケージが作られる。私はたいてい Gentoo っぽさをまねようとして/etc/apk/sets/にシェルスクリプトを作るが、いつも同じではない以前 Docker で Alpine を動かす際の性能に関する記事があり、Debian/Ubuntu を使うよう勧めていた記憶がある
遅い Alpine に関する記事:
https://pythonspeed.com/articles/alpine-docker-python/
https://superuser.com/questions/1219609/why-is-the-alpine-do...
Alpine に好意的な記事:
https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine...
この話が今でも有効なのか気になる
それでも性能面でベンチマークを回して実際の数字を見るのは興味深そうだ
musl はまだ
pthread_attr_setaffinity_npをサポートしていないのでは？ そうだとすると一部のソフトウェアは実行できず、最大の例が PyTorch だ多くの状況では、性能よりも単純さやセキュリティの方が重要な関心事だ
BSD と Linux の間で私が見つけたちょうどよい中間地点は Slackware だ。堂々と Unix らしく複雑でなく、Slackbuilds を通じた豊富な独自 ports ツリーもある
以前は邪魔をしない最小限のディストリビューションとして気に入っていたし、少し技術寄りの人たちを対象にしていると見ていた
ところが問題を掘り下げるとき、フルインストールしていないという理由でコミュニティが敵対的に振る舞うことがあった。フルインストールが推奨方式だというのが理由で、そうしないと samba がないために mplayer が動かないといった馬鹿げた依存関係の問題も起きた
Alpine はあらゆる面で Slackware より改善されていると思う
Alpine Linux は実は GNU/Linux ではなかったのか。知らなかった
では BusyBox/Linux なのか？