openSUSE Advent Calendar 2021 の 4日目です。書き手がまだまだ足りませんので、ぜひ気軽に投稿をお願いします。

今日は新しいPCの話です。これまでは、2012年に組んだ Core i7-3770S のデスクトップ PC を Windows 10 で、Dynabook VZ72 (i7-7500U) で openSUSE Leap を使ってきました。このデスクトップPCのほうが、まもなく10年ということもあり、時々フリーズしたり、性能不足なところもあり、半導体が高騰している微妙なタイミングですが、完全に壊れる前に買い換えることにしました。

構成

新しい PC の構成は次のとおりです。

• CPU: Ryzen 7 5700G
• M/B: Gigabyte X570S
  • ネットワークカードは RTL8125 2.5GbE
• メモリー: SanMax Technologies PC4-25600 16GB CL22 Skhynix × 2
• SSD: CFD CSSD-M2B5GPG3VNF (512GB, PCIe Gen 4×4)
• ケース: Fractal Design Define 7 Compact
• 電源: Antec NeoECO GOLD 550W（旧PCから流用）

マザーボードが無駄にX570なのは、実家の DeskMini A300 の PC の調子が悪く、故障箇所の切り分けを行うために旧CPUに対応したX570にしました。ちょっと無駄です。さらに、GPU 内臓の Ryzen 7 5000G は PCIe が Gen 3 になってしまうので、X570 の意味がありません…。残ったメリットは、増設した場合のメモリークロックくらいでしょうか。

今回こそコンパクトな PC にしたいと思っていたのですが、この状況でマザーボードの選択肢が少なく、結局 ATX ケースになってしまいました。Fractal Design の 5インチベイのないコンパクトラインのケースなのですが、今まで使っていた 15年以上前の ATX ケースよりずいぶん大きいです。最近、デスクトップ PC をわざわざ買う人は、ハイエンドのグラッフィックカードを付けるからか仕方がないですね。HDD は NAS に移してしまったので、3.5インチや2.5インチベイも使っておらず、中身はすっからかんです。そのうち簡易水冷でも導入して有効活用することにしましょう。

openSUSE Leap を入れる

これまで、デスクトップでは Windows を使っていましたが、最近、Steam で配信されているゲーム（AOCとか）は Linux でも動くので、ホスト OS を openSUSE にしてしまうことにしました。加えて、openSUSE 界隈で流行っているかもしれない、PCI pass-through を使って、物理 GPU を Windows ゲストに直接接続すれば快適な Windows ゲスト環境が作れるはず…と考えていました。結局、Windows ゲストはちょっと試しただけで使っていないのですが、この話はまた今度。

さて、openSUSE Leap のカーネルは、新しいハードウェアに対応できるようにパッチがたくさん入っていますが、ちょっと古いです。そのため、最新のハードウェアでは一部の機能が使えないことがあります。今回、Leap は普通にインストールできましたが、画面の解像度が 4K にならないし、もっさりしていて、少なくともグラフィックドライバまわりが動いてない感じでした。

そんなときは、最新のカーネルを OBS から持ってきます。Leap 向けの最新カーネルは以下の OBS プロジェクトでビルドされています。このリポジトリを登録して、kernel-default や kernel-frimware-* をインストールすれば OK です。
https://build.opensuse.org/project/show/Kernel:stable:Backport
このリポジトリは openSUSE Leap としてメンテされているものではありませんのでご注意ください。

新しいPCは？

8コア、16スレッドということで、やっぱりパッケージのビルド作業が快適になりました。CPU内蔵のGPUですが、Full HDでゲームをする分には十分で、グラフィックカードを増設するのはだいぶ先になりそうです。

この記事は小江戸らぐ 5月のオフな集まりの発表ネタです。

2回目の夏を迎えるに当たり、自宅ファイルサーバーの熱とファンの音が気になり、モニタリングしてみることにしてみました。今回は他の用途でも興味があった Grafana を使ってみました。Grafana は CPU 使用率やメモリ使用量といったハードウェアから、データベースやアプリケーションの性能といった様々なメトリクスを可視化・分析するための Web アプリケーションです。インタラクティブに操作できたり、かっこいい見た目だったりで、最近よく見かけます。

小江戸らぐ向け注記: よくカロスさんの発表に出てきます。K8s のクラスタやラズパイの環境センサーの表示で使っていますね。

Grafana Cloud

今回はちょっと横着して、Grafana の SaaS である Grafana Cloud を使いました。Grafana といえば、多くの場合、メトリクス収集と時系列データベース機能を持つ Prometheus と組み合わせ、これら2つをどこかにインストールして使います。Grafana Cloud では Grafana 本体と Prometheus のデータベース部分は Grafana Cloud で動いているものを使うことができます。データの収集は Prometheus からデータベース部分などを簡略化した Grafana Agent で収集できます。

気になるお値段ですが、Free プランがあります。メトリクスの保持期間は2週間というのがポイントになりますが、ちょっと試して見るには十分です。無料プランの主なスペックはこんな感じです:

• 10,000 系列（種類）までの Prometheus または Graphite のメトリクス
• 50 GB のログ
• 14日間のメトリクスとログの保持期間
• 3人までのチームメンバー

アカウントを作るためにクレジットカードなどの情報は特に必要ありません。 Grafana Cloud のページでアカウント作成に進み、GitHub などの SSO でログインすればすぐ準備完了です。

メトリクス収集

次に、メトリクスの収集を始めましょう。雷のアイコン（⚡） > Walk through をクリックすると、スクリーンショットのように Grafana Cloud がサポートしているプラットフォームのメトリクス収集を簡単にセットアップできるガイドが用意されています。今回は Linux Server を使用します。Prometheus では Node Exporter と呼ばれているものです。

Linux Server をクリックすると、セットアップするためのスクリプトが表示されます。「Choose your OS」には openSUSE が見当たりませんが、「RedHat – based」で OK です。Go言語で実装されたアプリなので、システムライブラリにほとんど依存していません。

あとは、その下に表示されたスクリプトを実行すれば OK です。Grafana Agent の RPM のインストールと設定ファイルの作成、起動まで一気に行われます。セットアップが終わると、最初から用意されているダッシュボードに収集した情報が表示されます。（datasource で grafanacloud-xxxx-prom を選択）

ダッシュボードの作成

もちろん、ダッシュボードを自分で組み立てることもできます。ここではパネルを配置し、Visualization を Time Series にして次を追加してみました。収集されているメトリクスの一覧がドロップダウンメニューに表示されるので、ここからそれっぽいものを選んで追加することができます。

• node_cpu_scaling_frequency_hertz
• instance:node_cpu_utilisation:rate1m
• node_hwmon_temp_celsius

各系列のスタイルや、単位、Y軸の設定は、ちょっとわかりにくいですが Overrides タブで系列を選んで個別に設定できます。

このファイルサーバーは普段ほとんどアイドル状態なのですが、CPU クロックが思った以上に落ちていないことが分かりました。ファンコントロールのターゲット温度が45℃設定なのですが、55℃くらいをキープしているようです。

おわりに

Grafana Cloud を使って自宅ファイルサーバーの監視を簡単にしてみました。そして Grafana Agent が CPU 時間を他と比較して使ってしまっていますので、場合によっては収集する項目を減らすなどを考えたほうが良いかもしれません。

自宅サーバーをセットアップした際に、すべてを HDD にインストールしていたのですが、今回、/home と /boot、過去のスナップショットデータ以外を SSD に引っ越しました。このとき、Btrfs のサブボリュームとしての引っ越しをしてみました。

最初に openSUSE の Btrfs のサブボリューム構成についておさらいです。Snapper が有効化された状態のサブボリューム構成は次のようになっていました。Btrfs の / には @ というサブボリュームが1つだけあります。@ の中にマウントしたシステムの / にあるディレクトリに対応したサブボリュームがあります。ちなみに /@ が / としてマウントするのではなく、それぞれのサブボリュームごとに /etc/fstab でマウントしています（例: /@/home が /home）。Snapper を使用している場合は 1 番目のスナップショットが現在の / です。

以下のリストに無い、/@/.snapshots/1/ や /@/boot/grub2/ はサブボリュームではなく、その上にあるサブボリューム内のディレクトリです。

/@
/@/.snapshots
/@/.snapshots/1/snapshot
略
/@/.snapshots/61/snapshot
/@/boot/grub2/i386-pc
/@/boot/grub2/x86_64-efi
/@/home
/@/opt
/@/root
/@/srv
/@/tmp
/@/usr/local
/@/var
/@/var/lib/machines

さて、今回は /@/home と /@/boot/* を HDD に残し、その他を SSD に移動することにしました。パーティション全体であれば、dd で、ファイルレベルであれば rsync と色々な方法がありますが、今回は Btrfs のサブボリュームを他の Btrfs ファイルシステムに転送する btrfs send を使いました。

作ってみたスクリプトを先に貼り付けて、ポイントを個別に説明します。使い方はコピー元を /dev/sda1、コピー先を /dev/sdb1 とし、次のように使います。3番目の引数はスキップするサブボリュームのパターンです。/dev/sdb1 は mkfs.btrfs でフォーマットしてある前提です。
$ btrfs-subvols-copy.sh /dev/sda1 /dev/sdb1 "@/home|@/.snapshots/[2-9][0-9]*|@/boot"

#!/bin/sh

set -eu

exclude=$3

# mounting root volumes
workdir=`mktemp -d`
echo "working directory is '$workdir'"
cd $workdir
mkdir src
mkdir dest

# ルートのサブボリュームをマウントマウントする
echo "mounting root subvolumes of src and dest"
mount -t btrfs -o subvol=/ $1 $workdir/src
mount -t btrfs -o subvol=/ $2 $workdir/dest

src=$workdir/src
dest=$workdir/dest

backup_date=`date -u +'%s'`

# サブボリュームの一覧を出力
for subvol in `btrfs subvolume list --sort=path $src | awk '{print $9}'`; do
    echo -n ">> $subvol: "
    if [[ $subvol =~ $exclude ]]; then
        echo "matched to a exclude pattern, skipped"
    elif [ -e $dest/$subvol ]; then
        echo "the destination subvolume already exists, skipped"
    else
        echo "create readonly tmp snapshot"
        tmpsnap=$subvol.tmpsnap
        # スナップショットを作って送る
        echo "creating a read-only temporary snapshot to send] $src/$tmpsnap"
        btrfs subvolume snapshot -r $src/$subvol $src/$tmpsnap
        echo "copying"
        btrfs send $src/$tmpsnap | btrfs receive $dest/`dirname $tmpsnap`

        # 送信用のスナップショットを消す
        echo "deleting the temporary snapshot: $src/$tmpsnap"
        btrfs subvolume delete $src/$tmpsnap

        # .tmpsnap を外す
        echo "renaming the copied subvolume"
        mv $dest/$tmpsnap $dest/$subvol

        # property を元のサブボリュームと同じにする
        echo "copying subvolume properties"
        for prop in `btrfs property get $src/$subvol`; do
            btrfs property set $dest/$subvol ${prop/=/ }
        done

        echo "done"
    fi
done

echo "unmounting src and dest"
umount $workdir/src
umount $workdir/dest
echo "cleaning up working directory"
rmdir src
rmdir dest
rmdir $workdir

まずは、送信元、先のボリュームのマウントです。

# ルートのサブボリュームをマウントマウントする
echo "mounting root subvolumes of src and dest"
mount -t btrfs -o subvol=/ $1 $workdir/src
mount -t btrfs -o subvol=/ $2 $workdir/dest

送信元と先をマウントするだけなのですが、注意点が1つあります。Btrfs では任意のサブボリュームを選んでマウントすることができますが、何も指定しないと / ではなく、デフォルトのサブボリューム（btrfs subvolume set-default で設定可能）がマウントされてしまいます。特に Snapper を使用していると、1番目の Snapper スナップショットがデフォルトになっていますので、明示的に subvol でマウントしたいサブボリュームの指定が必要です。

次に、送信元のサブボリュームのリストアップです。

# サブボリュームの一覧を出力
for subvol in `btrfs subvolume list --sort=path $src | awk '{print $9}'`; do

--sort=path を指定して、親ディレクトリを含むサブボリュームを先にリストし、サブボリュームのツリー構造の親サブボリュームとディレクトリを先にコピーするようにします（存在しないとエラーになってしまいます）。

次に送信するところです。

        # スナップショットを作って送る
        echo "creating a read-only temporary snapshot to send] $src/$tmpsnap"
        btrfs subvolume snapshot -r $src/$subvol $src/$tmpsnap
        echo "copying"
        btrfs send $src/$tmpsnap | btrfs receive $dest/`dirname $tmpsnap`

btrfs send コマンドを使ってコピーするのですが、送信できるのは読み取り専用のサブボリュームなので、一度スナップショットを読み取り専用で作成し、このスナップショットを送ります。コピーは btrfs send と btrfs receive のペアで行えます。サブボリュームの名前（パス）は送信元と同じものが作成されます。そのため、スナップショットの名前になってしまうので、あとで mv が必要でちょっと不便です（スナップショットを別のディレクトリに作成する方法もあり）。

注意が必要なことが1つあります。この送り方では Snapper のスナップショットを送れません。Snapper のスナップショットはスナップショット間で共通するデータを共有していますが、この方法ではこの共有が解けて複製されてしまいます。btrfs send のオプションにベースとなったスナップショットを指定し、差分だけを送る機能があるようなので、もう少し工夫すると実現できるかもしれません。

最後に、サブボリュームのプロパティのコピーです。

        # property を元のサブボリュームと同じにする
        echo "copying subvolume properties"
        for prop in `btrfs property get $src/$subvol`; do
            btrfs property set $dest/$subvol ${prop/=/ }
        done

送信前に読み取り専用のスナップショットを作成していますので、読み取り専用を含めた、送信後サブボリュームのプロパティをもと同じに戻します。

openSUSE Leap 15.2 の Raspberry Pi では Bluetooth が使える状態になっていません。SLE の Raspberry Pi Quick Start に書かれている次のコマンドで初期化する必要があります。

https://documentation.suse.com/sles/15-SP1/pdf/art-rpiquick_color_en.pdf

hciattach /dev/ttyAMA1 bcm43xx 921600
hciconfig hci0 up

このコマンドを実行することでファームウェアが読み込まれ、Bluetooth が使えるようになります。

今年も openSUSE Advent Calendar に参加頂きありがとうございました。

最終日は今年1年を振り返っていきたいと思います。

今年最初のイベントは1月3日の京都での新年会&もくもく会でした。続いて4日に東京での新年会でした。このときはこんな状況になるとも知らず、オフラインでの開催でした。

新年会以降、国内でも COVID-19 の感染者数が増え始め、今年のイベントはストップ。9年ぶりに都内に戻るはずだった OSC 東京も中止になってしまいました。

4月は OSC Online/Spring に参加。2月のOSCで発表予定だった Snapper を有効にしたファイルサーバーの話をしました。初のオンラインイベントにもかかわらず、Remo を使ったバーチャル展示にも挑戦しましたが（枠は XDDC）、こちらはちょっと時代がまだ追いついていない感じでした。

5月は OSC Nagoya/Online に出展。川上さんが「Dockerで始めるネットワーク実験入門」について話してくれました。

openSUSE Leap 15.2 の Release Party はなんとかオンライン開催しました。昼間から乾杯して、15.2のリリース情報を眺めて、修太さんがセキュアブートの話をしてくれました。

8月の OSC 京都は「あつまれ！openSUSEユーザーの森」。京都でこのタイトルは流石に事務局に何か言われるんじゃないだろうかと言う声もありましたが、このままのタイトルになりました。ユーザー会のメンバーがどのように openSUSE を使っているかを紹介するという新しいスタイルのセミナーでした。

うちだけではないようですが、OSC のブースはユーザ会の出展モチベーションの大きな割合を占めていて、展示がないことで OSC 東京はスキップしてしまいました。このまま今年の OSC はおしまいとなりそうでしたが、12月、ODC は XDDC として春に開催予定であったディストリビューション大集合を開催し、openSUSEも参加しました。

来年に向けて

今年は1年間を通して Geeko Magazine を出しませんでした。コミケも2回ともなくなってしまいましたし、技術書典や OSC などのオフラインでの頒布機会もありませんでした。

来年は GW に開催される予定の C99 に申し込んでいます。もしスペースを確保できれば、久しぶりの新刊を出すことができそうです。

イベントは当面オンラインになるかと思います。ユーザ会の単独イベントはどれくらい行うかは決めていませんが、メンバーは OSC はもちろん、小江戸らぐなどオンラインイベントにも出没していますので、ぜひ、参加してみて下さい。

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

今日は openSUSE Leap 15.3 に向けて openSUSE Leap を SUSE Linux Enterprise にさらに近づける取り組み Closing The Leap Gap について紹介します。

openSUSE Leap のおさらい

openSUSE Leap は openSUSE 13.2 の後継のディストリビューションで、2015年に最初のバージョンの 42.1 がリリースされました。openSUSE Leap では、それまでの openSUSE よりも長期間のサポートと安定性を目指すことになりました。

これを実現するための手段として、openSUSE Leap と SUSE Linux Enterprise (SLE) の間でコアパッケージを共通化することになりました。これにより、パッケージに対して何らかの修正をしなければいけなくなったときも、SLE の修正を取り込むだけでコアパッケージをほぼ保守することができるようになりました。

openSUSE Leap は SLE のクローンではありません。コミュニティディストリビューションとして魅力的なものとなるよう、SLE 由来のコアパッケージに加え、openSUSE Tumbleweed ベースの多数のパッケージが含まれています。また、すべての SLE のパッケージが含まれていたり、完全な互換性を目指しているわけではありません。この点では多くの RedHat Enterprise Linux 派生ディストリビューションとは異なります。

Closing the Leap Gap

openSUSE Leap 15.2 まではコアパッケージのソースコードは共有していましたが、バイナリレベルでは違いがありました。その原因は、ビルドオプションの違いで、多くの場合は openSUSE のほうが有効化される機能が多い傾向があります。

このバイナリレベルでの微妙な違いが品質保証やメンテナンス上の二度手間になっていました。また、SLE では、openSUSE Leap のパッケージを SLE で使えるようにする Backport リポジトリがありますが、コアパッケージが微妙に違うことで openSUSE Leap のパッケージをそのまま使えず、少なくとも再ビルド、場合によっては手直しが必要でした。サードパーティーのパッケージについても、openSUSE Leap と SLE で同一のビルドを利用できない場合がありました。

そこで、この微妙な違いを無くす、Closing the Leap Gap が始動しました。このプロジェクトでは SLE から openSUSE にビルド済みのバイナリパッケージを提供し、SLE と openSUSE Leap のコアパッケージをバイナリレベルで同一にすることを目指しています。同一にするために、一部のでは openSUSE の独自機能を SLE に取り込んだり、openSUSE の独自部分をサブパッケージに分離したりしました。

https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap

この活動の成果として、openSUSE Leap 15.2 をベースに本活動の成果を反映したプロトタイプ、 openSUSE Jump (あるいは openSUSE 15.2.1) が開発されました。

なお、一部のパッケージは技術上の問題で同一にできない見込みで、その差分については wiki などでドキュメント化されることになりそうです。

https://en.opensuse.org/Portal:15.3/Features:Identicality

15.3 に向けて

openSUSE Leap 15.3 は Closing the Leap Gap の成果が反映されたディストリビューションとしてリリースされることになっています。

開発インフラの調整も進められており、SLE のバイナリパッケージと openSUSE のパッケージを使ってビルドできるようになっています。

これまで同様、またそれ以上に、コミュニティ開発者が openSUSE Leap と SLE に貢献できるよう、openSUSE のコミュニティ開発者が、SUSE の JIRA を使って今後の開発についてリクエストを出したり、議論したりすることができるようになる予定です。

開発環境である日突然 venv が使えなくなり、はまりました。先日のアップデートで配信された python3-base-3.6.12-lp152.4.9.1 に不具合があり、起動できなくなりました。
https://bugzilla.opensuse.org/show_bug.cgi?id=1179756

# python3 -m venv venv
Error: Command '['/home/geeko/venv/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned
non-zero exit status 1.

ensurepip を動かしてみると、

# python3 -Im ensurepip --upgrade --default-pip
Traceback (most recent call last):
File "/usr/lib64/python3.6/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/usr/lib64/python3.6/ensurepip/__main__.py", line 5, in <module>
sys.exit(ensurepip._main())
File "/usr/lib64/python3.6/ensurepip/__init__.py", line 204, in _main
default_pip=args.default_pip,
File "/usr/lib64/python3.6/ensurepip/__init__.py", line 99, in _bootstrap
"_bundled/{}".format(wheel_name),
File "/usr/lib64/python3.6/pkgutil.py", line 634, in get_data
return loader.get_data(resource_name)
File "<frozen importlib._bootstrap_external>", line 832, in get_data
FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib64/python3.6/ensurepip/_bundled/setuptools-
40.6.2-py2.py3-none-any.whl'

実際にあるのは…

/usr/lib64/python3.6/ensurepip/_bundled/setuptools-44.1.1-py2.py3-none-any.whl

当面はバージョンを1つ戻すか、修正が配信されるのを待ちましょう。