今年も 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 を使って今後の開発についてリクエストを出したり、議論したりすることができるようになる予定です。

めでたくTumbleweedに20201115版の日本語マニュアルが入りましたが、必ずしも最新の日本語manpage が入ったわけではありません。たとえば、 od コマンドは、日本語訳が GNU textutils のバージョン2.1なのに対し、英語版の方はcoreutils のバージョン8.32になっています。coreutils にいくつかのパッケージが集約されたことも反映されていません。

たとえば od の日本語manpage には –endian オプションが含まれていません。また、接尾辞についての記述も、 b (512倍)しか記載がありません。8.32では、KB,K(KirobyteとKibibyte),MB,Mのように、単位を示す記述についての記載もあります(Mの上、G,T,P,E,Z,Yも使えます)。

openSUSEの場合、たとえば man od とすると、同じmanpage が複数ある場合、一旦マニュアルを選択する画面が表示されます。たとえば、環境変数で LANG=ja_JP.UTF-8 というように日本語を指定する場合、そのままEnterキーを入力すると、既定で日本語のmanpage が表示されます。しかし、1+1,あるいは +1 というように指定すると、英語版のマニュアルを表示できます。ですので、マニュアルページを参照する際は、適宜英語版のマニュアルも参照して、日本語版と差がないかどうかを確認することをお勧めします。

開発環境である日突然 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つ戻すか、修正が配信されるのを待ちましょう。

この記事は openSUSE Advent Calendar 18日目です。 残り、あと少しですが、まだ埋まってなく3年連続の完走がピンチ。みなさんご協力下さい。

この内容は小江戸らぐのオフな集まり2月と、オフだけどオンライン開催だった5月の発表内容でもあります。

ことの始まり

この春、ファイルサーバーを組みました。これまで、写真等の大きめのファイルはデスクトップに置いていましたが、タブレットやスマフォを使用しているとデスクトップを起動しないこともあり、アクセスするにはちょっと不便でした。かといってクラウドに上げるには容量が大きいのが現状です。

このとき、電源の故障で引退した、ちょっと古いけどまだ使える一式（Socket FM2 の M/B, AMD A4-5300 APU, DDR3 8 GBメモリ）があったのと、鹿さん から、使わなくなったファイルサーバー用の MiniITX ケースを頂いたので、これでファイルサーバーを組んでみることにしました。

RAID カード調達

HDD は NAS 用のものを適当に買うとして、1度はRAID 5 や 6 で組んでみたい！ということで、RAID カードを探しました。一般のご家庭（誤変換）では、数万円クラスのカードを使っているかと思いますが、この「ありあわせ構成」には不釣り合いです。安く入手する方法としては、ヤフオクなどでサーバーから抜き取ったものを探す手がありますが、あまりに古いと EFI に対応していなかったり、4 KB セクタや 2TB の壁にあたる可能性があります。また、中古品はキャッシュ保護用のバッテリーが死んでいる可能性もあります。

そこで今回は eBay で3世代前の Adaptec ASR-71605 の新古品を買ってみました。キャッシュ保護用のコンデンサ付き、送料込みで 8500円くらいでした。ドライバはカーネルに入っているのですぐに使えます。

意外と高かったのがケーブルでした。Mini SAS HD から SATA ×4にするもので、Amazon で 2500 円くらいでした。

OS インストール

セットアップに困ることはないはずが、openSUSE 15.1 をインストールすると、なぜかディスプレイドライバが固まります。いろいろ試したところ modeset ドライバを ACPI が有効な状態で使うとダメなようです。今回はディスプレイはほとんど使わないので nomodeset を起動オプションに追加することで回避しました。（modeset ドライバだと、コンソールの解像度がディスプレイにあわせて変わるので良いのですが…）

ファイルサーバーの設定

Samba は入れるだけです。とっても簡単ですね。

Btrfs にしてスナップショットを取るようにしました。このあたりはOSCのスライドや Geeko Magazine を見てください。

iSCSI サーバーは4月に書いた別の記事で。

バックアップの設定

重要なディレクトリを選んで USB 接続の HDD に1日に1回、Snapper の最新スナップショットからバックアップを取るようにしました。単純に rsync でコピーを取ります。Btrfs のバックアップといえば、ファイルシステムレベルで差分転送をできる btrfs send があります。しかし、ファイルシステムが壊れてしまった場合に、btrfs send を行うとバックアップも壊れる可能性があるのではないかと考え、今回は使用しませんでした。

タイマーとスクリプトはこのような感じです。タイマーの時間は Snapper の実行中にならないように気をつける必要があります。

backup-to-usb-disk.timer

[Unit]
Description=Back up files to USB disk daily

[Timer]
OnCalendar=*-*-* 6:20:00
Persistent=true

[Install]
WantedBy=timers.target

backup-to-usb-disk.service

[Unit]
Description=Back up files to USB disk

[Service]
ExecStart=/usr/local/sbin/backup-to-usb-disk.sh
Type=oneshot

backup-to-usb-disk.sh

#!/bin/bash

set -e

if [ ! -f /var/backup/backupdisk ]; then
    echo "Back up disk is not found"
    exit 1
fi

# home
snapshot_root=/home/.snapshots

cd $snapshot_root
latest_snapshot=`ls -1 | grep "[0-9]*" | sort -nr | head -n 1`/snapshot/
echo "creating back up of /home/.snapshots/$latest_snapshot"

if [ ! -e $latest_snapshot ]; then
    echo "Snapshot directory error"
    exit 1
fi

target_dir=/var/backup/home/

rsync -va --delete $latest_snapshot $target_dir 

様子見中

Snapper が走る時（おそらく）に btrfs-cleaner がかなり CPU を使うので、試しに Quota 機能を無効にしています。

おわりに

簡単にではありますが、ファイルサーバーを構築したときのいろいろを紹介しました。このファイルサーバーでは、先日書いた Spotify クライアント も動いています。新たな活用を始めたら記事にしたいと思います。

Geeko Blog » マニュアルのみのRPMファイルを作ってみた で、Sambaの日本語マニュアルパッケージを作成した時に参照したLinuxの日本語マニュアルページですが、2017年12月15日バージョンでした。これは openSUSE 15.0 から変わっていません。ちょっと古いですね。そこで、他のディストリビューションなどと比較して見ることにしました。結果は以下の通りです。なお、各ディストリビューションとも、各種コマンドでパッケージの最新化をして確認するか、配布サイトのパッケージ情報を見ています(※のもの)。

• CentOS 7 20130615版
• Debian10 20180315版
• openSUSE 15.2 20171215版
• openSUSE Thumbleweed 20191215版(※)
• Fedora 20200315版(※)
• Oracle Linux 20130615版(※)
• Arch Linux なし(※)
• Gentoo Linux 20180315版(※)

CentOS(=RedHat=Oracle Linux)はちょと古すぎますね。Fedora はやはりというか新しいです。しかし、Thumbleweed も結構新しい方でしょう。とりあえず15.2で使うのであれば、Thumbleweed版を持ってきて入れてしまうと言うのも手かもしれません。rpmファイルの中身はテキストだけなので、バイナリの互換性で引っかかることはないですから。

ちなみに、日本語マニュアルについては、Open Build Service で20201115版を作成し、更新をお願いしておきましたので、そのうちopenSUSE用の最新版が提供されるようになるのではないかと思います。

ただ、ls コマンドのマニュアルを見てみると、openSUSE 15.2 での日本語マニュアルはは GNU Fileutils のバージョンが4.1であると表示されますが、英語版は バージョン8.29 となっています。となると、日本語マニュアルに頼りすぎるのは少々危険かもしれません。

openSUSE Advent Calendar の14日目です。

オンラインイベント続きで Zoom が欠かせない今日この頃ですね。openSUSE 用のクライアントアプリの RPM パッケージは公開されていますが、なぜかリポジトリからの配信ではありません。そのため、アップデートが簡単にできなく不便です。

ということで、1コマンドで更新する小ネタです。単に zypper で URL を指定するだけです。自動更新がよければ、Systemd Timer で定期実行してもいいかもしれませんね。

sudo zypper in https://zoom.us/client/latest/zoom_openSUSE_x86_64.rpm