By ftake @
2021-05-08 12:06
この記事は小江戸らぐ 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 時間を他と比較して使ってしまっていますので、場合によっては収集する項目を減らすなどを考えたほうが良いかもしれません。
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番目の 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
送信前に読み取り専用のスナップショットを作成していますので、読み取り専用を含めた、送信後サブボリュームのプロパティをもと同じに戻します。
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 クライアント も動いています。新たな活用を始めたら記事にしたいと思います。
