さて、毎度ながらの説明ですが、ALP (Adaptive Linux Platform)は、SUSEとopenSUSEで開発している次世代OSのベースです。イミュータブルで軽量な仕様となっています。

この冬発売のGeeko MagazineにインストールとCockpitというブラウザから管理できるアプリの体験記を書いていますので、ぜひ皆さん試してみてください。

今日はalpで動かしているCockpitから、podmanを制御してみたいと思います。

まず、左側に「Podmanコンテナー」というメニューがあるので、そこを選択します。

すると、画面にPodmanサービスを有効化というボタンが表示されるので、クリックして有効化します。（すみません、スクショを撮り損ねてしまいました）

すると、イメージやコンテナーなどを制御できる画面が表示されます。

かなり直感的な操作ができそうです。

では、コンテナーを作成してみます。右下にある「コンテナーの作成」をクリックすると、コンテナー作成ダイアログが表示されます。

試しでnginxを作成してみます。

イメージの所にnginxと入れると、候補が表示されて、そこから選ぶことができました。

また、ポートマッピングもしておきます。「インテグレーション」タブで設定できました。

左下の「作成して実行する」をクリックします。すると、イメージのダウンロードが始まりました。

少しすると、無事実行中になりました。

ホストのブラウザからアクセスすると、nginxが起動していることが確認できました。

停止や削除などの操作も一通り画面から行えました。Podman、というかコンテナーの基礎知識は必要だなとは思いましたが、かなり直感的で使いやすかったです。

ALP (Adaptive Linux Platform)は、SUSEとopenSUSEで開発している次世代OSのベースです。イミュータブルで軽量な仕様となっています。

この冬発売のGeeko MagazineにインストールとCockpitというブラウザから管理できるアプリの体験記を書いていますので、ぜひ皆さん試してみてください。

さて、今日は公式ドキュメントにある、firewolldをpodmanで動かす手順をやってみようと思います。

まず、alpにログインし、alp用のfirewalldのコンテナを特定します。

# podman search firewalld

そうすると、ドキュメントにも乗っているalp用ワークロードが搭載された registry.opensuse.org/suse/alp/workloads/tumbleweed_images/suse/alp/workloads/firewalld のイメージが見つかります。

次に、手順の通り、alpからパッケージとしてのfirewalldを削除します。alpはイミュータブルなため、通常のzypperコマンドではなく、専用のtransactional-updateコマンドで暫定的な削除を行い、リブートすることでそれがシステムに適用されます。

# transactional-update pkg remove firewalld
# reboot

では、イメージのワークロードを実行します。

# podman container runlabel install \
registry.opensuse.org/suse/alp/workloads/tumbleweed_images/suse/alp/workloads/firewalld

他のイメージの実行時にも触れましたが、podmanは実行コマンドにラベルを貼ることができ、runlabel コマンドでそのラベルを指定して実行することができます。一連のalpワークロード用イメージは、installといったラベルにホストの設定などの処理を持たせています。

ドキュメントによると、firewalldはpolkitやsystemdなどの準備をしてくれているようです。

そう言えば、冒頭にdbusとpolkitの設定ファイルが必要、と書いてあったのですが、特に用意はせず、、、さて、どうなるでしょうか。

インストールが終わったので実行します。

# podman container runlabel run \
registry.opensuse.org/suse/alp/workloads/tumbleweed_images/suse/alp/workloads/firewalld

コンテナが実行されました。ではコンテナ経由でfirewall-cmdを実行してみます。

# podman exec firewalld firewall-cmd --list-all-zones

すると、zoneが表示され、firewall-cmdが実行可能なことがわかりました。

なお、firewalldのコンテナはホストを制御する関係上、privilegedで動いています。また、podmanを使っている場合、systemdとも統合されていて、systemctlコマンドで制御することが可能です。例えば、コンテナの起動は以下のコマンドで代替できます。

# systemctl start firewalld

なお、firewalldやfirewall-cmdのマニュアルをコンテナ経由で見る方法もドキュメントに書かれていました。

firewalldならば、

# podman run -i --rm \
registry.opensuse.org/suse/alp/workloads/tumbleweed_images/suse/alp/workloads/firewalld \
man firewalld

firewall-cmdならば、

# podman run -i --rm \
registry.opensuse.org/suse/alp/workloads/tumbleweed_images/suse/alp/workloads/firewalld \
man firewall-cmd

で参照可能です。 manコマンドをコンテナの中で呼び出しているわけですね。

個人的に、firewalldをコンテナで実行する利点欠点が見えていない所があり、そのあたりも追って調査考察してみたいと思います。

openSUSE 15.5 で試したのですが、GlusterFS の中の glusterd は peer との通信にデフォルトで IPv6 で通信しています。 /etc/hosts に IPv4 アドレスでホスト名を指定してもそこを見ません。
IPv4 で通信させるためには、 /etc/glusterfs/glsuterd.vol に

option transport.listen-backlog 1024

と言う行を追加する必要があります。

第四世代の Intel CPU を使ったマシンで openSUSE を使っていると、シャットダウンコマンドで電源をOffにしようとしても( poweroff など)電源が切れません。一旦切れたようになりますが、再度起動してしまいます。この動作は、なぜか Windows と BSD (Dragon Fly BSD)では起こらず Linux のみ起こる現象のようです。 openSUSE 意外に Debian でも現象を確認しています。

色々調べたのですが、正解にはたどり着けず、毎回手動で電源を落としていました。そうすると、マジックパケットを飛ばして WOL による起動ができなくなり、ちょっと不便に感じていました。

結局、Kernel の詳しい人に正解をいただきました。Grub のオプションに
xhci_hcd.quirks=0x2000
を付けるのだそうです。これでちゃんと電源が切れ、さらに WOL も動くようになりました。

この記事は openSUSE Advent Calendar 2022 の18日目です。

systemd が使われるようになると、daemon の制御とかのやり方は大きく変わりました。/etc/init.d にあるスクリプトから、systemd パッケージに含まれるコマンドを使うようになってきました。それらのコマンドは、xxxxxctl という、末尾に ctl が含まれるものが多いように感じました。そこで、/usr/bin/ の中にある、末尾が ctl なプログラムがどんなものかを簡単に調べて見ることにしました。

今回は、wdctl を紹介します。

コマンド名: wdctl
パッケージ: util-linux-2.37.2-150400.8.8.1.x86_64
動作: ○

wdctl は、システムのウオッチドッグ情報を表示するコマンドです。引数なしで起動すると以下のように表示します。

% wdctl
Device:        /dev/watchdog0
Identity:      Software Watchdog [version 0]
Timeout:       10 seconds
Pre-timeout:    0 seconds

オプションによって表示形式を変更することは出来ますが、基本的に上記のような情報を表示するだけです。ですので、あまり使い道はないかと思います。

この記事は openSUSE Advent Calendar 2022 の15日目です。

CombustionはMicroOSのプリメイドイメージをプロビジョンしてくれるスクリプトです。

ここ数年でMicroOSのプリメイドイメージのプロビジョンソフトが移り変わったので、紹介させて頂きます。

cloud-init

cloud-initはもともとUbuntuのクラウドイメージのプロビジョンソフトウェアでした。MicroOSは初期の頃対応していました。今はOpenStack用のプリメイドイメージ専用になっています。

ignition

CoreOSのプロビジョンソフトウェアで、JSONで記述した設定ファイルを使います。

MicroOSは今もignitionに対応しています。MicroOSのignitionのwikiはこちらです。

Combustion

MicroOS専用のプロビジョンソフトウェアです。スクリプトを書くことで、かなり柔軟な設定をすることが出来ます。dracatモジュールとのことですので、追っていろいろ見てみたいと思います。Combustionのwikiはこちらです。

この記事は openSUSE Advent Calendar 2022 の13日目です。

さて、前回 AkamaiさんがLinodeサービスアピールしてますと紹介させて頂いたのですが、各リージョンのスピードテストが出来る場所があったので紹介させて頂きます。

なお、ちゃんとリージョンに日本もありました。

このページはログインせずとも使えるみたいですね。

日本で測定してみました。

試しに、ムンバイで測定してみました。

それぞれ一回測定しただけなので信憑性は微妙ですが、確かにpingやDLで差が出ていますね。

Akamaiが親会社なので、近いところのリージョンへのアクセスは期待できるのでは無いでしょうか。