諸事情で、MicroOSのルートにbtrfsの機能でディスクを追加したのですが、balasceを実行しようとすると「read onlyだよ」と警告が。

ユーザ会slackに投げてみた所、武山さんから「transactional-update shellの中ならいけるのでは？」との助言を頂きました。

結論

成功

コマンド

transactional-update shell

transactional-updateそのもののアップデートが行われた後、独自のシェルに移行しました。

transactional update #

この状態で書き込み可能になります。書き込み後、シェルを抜けてrebootすれば反映されるしくみですね。

btrfs balance /

前後の状態を撮り損ねてしまったのですが、無事にbalanceされてました。

transactional-updateの真価はまだ味わえてないので、ロールバック等含め、近いうちにまとめて検証してみたいですね。

そもそも、transactional-update shellが一体何をどうしているのかも追えていない・・・

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

12/19(土)に開催された、ODC 2020 onlineに参加してきました。

Cross Distro Developers Camp

今回は、ディストリビューション横断で日本語入力の課題などを解決しようと結成されたチーム、Cross Distro Developers Campで参加してきました。

Linuxディストリビューション大集合　〜あなたのLinuxディストリビューションを見つけてみよう〜

ディストリビューションとはなんぞや？から、openSUSE、Debian、Solusの各ディストリビューションの紹介を行いました。

openSUSEは武山さんが紹介してくださいました。

Debianさんなど、あらためて説明を聞くと、特色や方向性が理解できて面白かったです。開発体制なんかも普段は目にすることがないので、興味深かったです。

Solusさんからは、日本語入力関連のパッケージの開発にまつわる、難題のお話も・・・・

休憩時間・雑談タイム

次のコマがミーティングだったので、間で雑談を。

参加者からは話題の？Centos8の事や、ターミナルでの日本語表示に関する問題などが出てました。

データの形式と、それを表示するソリューション（ターミナル）は独立しているべきですけど、ソリューション側で対応すると、それぞれのソリューションで日本語対応しなければならないことに・・

Linuxディストリビューション開発談話

openSUSEから武山さん、Debianから杉本さんがメインパネラーとして、あとはSolusのPG_MANAさん、ひよこLinux（?）の羽鳥さん、opencoconの島田さんにオブザーバーとして参加して頂いて、ディストリビューション開発について談話しました。

結構、ディストリビューション開発って（ソフトウェアもですが）敷居高いイメージありましたが、もちろん世界でどなたかが実際に開発しているわけで、方法もノウハウもあるわけですよね。

日本のコミュニティがそういった情報を持っているし、世界とのコネクションもあるので、まぁアクセスしてよ、とおっしゃってました。

私も来年はパッケージ開発何かしたいなぁ。

ブース

終日、JitsiをOSPNからお借りしてブース展示をしていました。私は主にこのブースの管理をしていました。

関係者の方？が多く入ってくださって、openSUSEユーザ会のRibbonさんとは、最近MLで話題になってた日本語manの話とかを聞けました。あとはみなさんと近況を連絡しあったり、と、普段はオフラインで開催している時にやってた情報交換ができた感じでよかったです。

新しい方はちょっと入りにくかったですかね・・私も無理に声掛けとかしなかったのですが、もうちょっと配慮してもよかったかもしれません。反省。そのあたり、東海道LUGの島田さんが上手にアプローチしてくださっていて、さすがだなぁと思いました。（島田さんには、セミナーのディストロとは？の所をお話して頂きまして、それもあってブースに来てくださってました。）

感想

セミナー・ミーティングは、Zoom 30人強、YouTube 40人弱で70人前後の方が見てくださってました。ありがとうございます。

openSUSEに興味持たれたら、ぜひアクセスしてください！

Cross Distro Developers Campとしては、次回活動は2021年1/31日（日）にもくもく会（オンライン）を予定しています。

めでたく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 クライアント も動いています。新たな活用を始めたら記事にしたいと思います。

私はKubicでKubernetesを構築しているのですが、Kuibcをアップデートしてkubeletのバージョンが1.19に上がったはずなのにもかかわらず、kubectl get nodeでずっとバージョンが1.18となっていて悩んでいました。

結論

/etc/sysconfig/kubelet に設定されている KUBELET_VERを、1.18から1.19に変更する

調査

パッケージを確認

まず、パッケージがなんのバージョンが入っているかを確認します。

kubic1-host:~ # zypper se kubelet

S  | Name                          | Summary                   | Type
—+——————————-+—————————+——–
i  | kubernetes-kubelet            | Kubernetes kubelet daemon | package
i  | kubernetes1.17-kubelet        | Kubernetes kubelet daemon | package
  | kubernetes1.17-kubelet-common | Kubernetes kubelet daemon | package
i  | kubernetes1.18-kubelet        | Kubernetes kubelet daemon | package
i  | kubernetes1.18-kubelet-common | Kubernetes kubelet daemon | package
i+ | kubernetes1.19-kubelet        | Kubernetes kubelet daemon | package
  | kubernetes1.19-kubelet-common | Kubernetes kubelet daemon | package
  | kubernetes1.20-kubelet        | Kubernetes kubelet daemon | package
  | kubernetes1.20-kubelet-common | Kubernetes kubelet daemon | package

　どうやら、1.17、1.18、1.19、と、いろいろなバージョンが入ってるようです。

今見たら、1.20も入ってますね。

使ってるバイナリを確認

kubic1-host:~ # type kubelet

kubelet is hashed (/usr/bin/kubelet)

ふむふむ。/usr/bin/kubelet、ですね。

こういう実行ファイルはスクリプトの場合があったりするので、種別を調べてみます。

kubic1-host:~ # file /usr/bin/kubelet
/usr/bin/kubelet: POSIX shell script, ASCII text executable

なるほど、スクリプトっぽいですね。

中身を確認します。

kubic1-host:~ # cat /usr/bin/kubelet
#!/bin/sh
# Loader Script for Multi-Version Kubelet arrangement introduced to openSUSE in March 2020
source /etc/sysconfig/kubelet

if [ -z “$KUBELET_VER” ]       
then
  echo “ERROR: KUBELET_VER= not defined in /etc/sysconfig/kubelet”
  exit 1
else
  /usr/bin/kubelet$KUBELET_VER “$@”
fi

どうやら、/etc/sysconfig/kubeletの値を参照しているようです。こちらを確認してみます。

kubic1-host:~ # cat /etc/sysconfig/kubelet
KUBELET_VER=1.19
KUBELET_EXTRA_ARGS=”–container-runtime=remote –container-runtime-endpoint=unix:///var/run/crio/crio.sock –runtime-request-timeout=15m –c
group-driver=systemd -v=2 –runtime-cgroups=/systemd/system.slice –kubelet-cgroups=/systemd/system.slice”

なるほど、KUBELET_VERが定義されています。nodeのバージョンが低いときは、ここが1.18となっていましたので、それを1.19に更新しました。

それからKubernetesを起動すると、見事バージョンが1.19にあがってました。

今なら1.20に上がる予感・・・・

メーリングリスト

最近忙しいこともあって、なかなかメーリングリストなどの情報源にあたれず・・・もしかしたら、こういったことはとうに情報共有されていたのかもしれません。また、この設定がKubic独自なのか、一般的なのか、といったことも追いきれておらず。追って調査したいと思います。

そもそもの使い方

アップデートで使い続けるのではなく、折を見て最新プリメイドイメージに乗り換えていく運用が今っぽいのかも・・・・・