By ftake @
2021-05-02 22:57
自宅サーバーをセットアップした際に、すべてを 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"
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 |
#!/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番目のサブボリュームがデフォルトになっていますので、明示的に 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 |
送信前に読み取り専用のスナップショットを作成していますので、読み取り専用を含めた、送信後サブボリュームのプロパティをもと同じに戻します。
By ftake @
2021-02-28 23:12
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 が使えるようになります。
By ftake @
2020-12-25 23:41
今年も 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 はもちろん、小江戸らぐなどオンラインイベントにも出没していますので、ぜひ、参加してみて下さい。
By ftake @
2020-12-22 23:47
この記事は 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 を使って今後の開発についてリクエストを出したり、議論したりすることができるようになる予定です。
By ftake @
2020-12-19 22:47
開発環境である日突然 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 を動かしてみると、
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# 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つ戻すか、修正が配信されるのを待ちましょう。
By ftake @
2020-12-18 01:59
この記事は 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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
#!/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 クライアント も動いています。新たな活用を始めたら記事にしたいと思います。
By ftake @
2020-12-14 23:16
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 |
