この記事は openSUSE Advent Calendar の1日目です。
今回は、 headmore を紹介します。
パッケージ名 headmore
バージョン headmore-1.2-1.16.x86_64
動作 △
テキストベースのVNC クライアントです。しかし、一応画面は表示されるのですが（ここではWindowsに繋いでいます）、GUIな画面をテキストで表示しているため、大まかな雰囲気が掴めるという感じでしかありません。ものすごくズームすれば、大まかな形は分かりますが。
取りあえずコンソールから、GUIな画面がおおよそどうなっているかを簡単に確認するときには便利に使えるかもしれません。
この記事は小江戸らぐ 5月のオフな集まりの発表ネタです。
2回目の夏を迎えるに当たり、自宅ファイルサーバーの熱とファンの音が気になり、モニタリングしてみることにしてみました。今回は他の用途でも興味があった Grafana を使ってみました。Grafana は CPU 使用率やメモリ使用量といったハードウェアから、データベースやアプリケーションの性能といった様々なメトリクスを可視化・分析するための Web アプリケーションです。インタラクティブに操作できたり、かっこいい見た目だったりで、最近よく見かけます。
小江戸らぐ向け注記: よくカロスさんの発表に出てきます。K8s のクラスタやラズパイの環境センサーの表示で使っていますね。
今回はちょっと横着して、Grafana の SaaS である Grafana Cloud を使いました。Grafana といえば、多くの場合、メトリクス収集と時系列データベース機能を持つ Prometheus と組み合わせ、これら2つをどこかにインストールして使います。Grafana Cloud では Grafana 本体と Prometheus のデータベース部分は Grafana Cloud で動いているものを使うことができます。データの収集は Prometheus からデータベース部分などを簡略化した Grafana Agent で収集できます。
気になるお値段ですが、Free プランがあります。メトリクスの保持期間は2週間というのがポイントになりますが、ちょっと試して見るには十分です。無料プランの主なスペックはこんな感じです:
アカウントを作るためにクレジットカードなどの情報は特に必要ありません。 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 にして次を追加してみました。収集されているメトリクスの一覧がドロップダウンメニューに表示されるので、ここからそれっぽいものを選んで追加することができます。
各系列のスタイルや、単位、Y軸の設定は、ちょっとわかりにくいですが Overrides タブで系列を選んで個別に設定できます。
このファイルサーバーは普段ほとんどアイドル状態なのですが、CPU クロックが思った以上に落ちていないことが分かりました。ファンコントロールのターゲット温度が45℃設定なのですが、55℃くらいをキープしているようです。
Grafana Cloud を使って自宅ファイルサーバーの監視を簡単にしてみました。そして Grafana Agent が CPU 時間を他と比較して使ってしまっていますので、場合によっては収集する項目を減らすなどを考えたほうが良いかもしれません。
前回は S でしたが、今回は A です。
パッケージ名 ansifilter
バージョン ansifilter-2.18-1.5.x86_64
動作 △
詳細
テキスト中の ANSI エスケープシーケンスを取り去ったり、HTMLなどの形式に変換できます。たとえば、script コマンドで、ANSI エスケープシーケンス付きのメッセージを記録したのち、それをテキストとして利用するときなどには便利に使えます。
ただし、漢字についてはうまくいかない場合がかなりあります。また、HTML 変換については、エスケープシーケンスを落として変換、すなわち、色とかの情報がまるまる落ちて変換されます。ここはちょっと惜しいところです。
漢字が含まれていない、typescript の結果を整理する場合などには便利に使えそうです。
パッケージ名 arping2
バージョン arping2-2.21-1.5.x86_64
動作 ◎
詳細
ICMP のほかに、ARP を使って相手との疎通を確認するツールです。ICMP echo に反応しない機器との疎通を確認できます。但し、root でないと動きません。
# ping -c 4 192.168.A.BB
PING 192.168.A.BB (192.168.A.BB) 56(84) bytes of data.
--- 192.168.A.BB ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3058ms
tw:~ # arping2 -c 4 192.168.A.BB
ARPING 192.168.A.BB
42 bytes from a6:3a:xx:yy:zz:98 (192.168.A.BB): index=0 time=487.929 usec
42 bytes from a6:3a:xx:yy:zz:98 (192.168.A.BB): index=1 time=362.456 usec
42 bytes from a6:3a:xx:yy:zz:98 (192.168.A.BB): index=2 time=356.881 usec
42 bytes from a6:3a:xx:yy:zz:98 (192.168.A.BB): index=3 time=389.354 usec
--- 192.168.A.BB statistics ---
4 packets transmitted, 4 packets received, 0% unanswered (0 extra)
rtt min/avg/max/std-dev = 0.357/0.399/0.488/0.053 msたとえば、Windows Server の既定状態のような機器との疎通を確認するには便利に使えそうです。
自宅サーバーをセットアップした際に、すべてを 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
送信前に読み取り専用のスナップショットを作成していますので、読み取り専用を含めた、送信後サブボリュームのプロパティをもと同じに戻します。
前回は T でしたが、今回は S です。
パッケージ名 scout
バージョン scout-0.2.4+20210325.6c2d9f3-1.1.noarch
動作 △
詳細
コマンドが見つからない場合、パッケージ内にあれば、そのパッケージを表示してくれるツールです。たとえば、
> scout bin sdl-config
リポジトリ | パッケージ | パス | バイナリ
----------------------------------+--------------+----------+------------
zypp (openSUSE-20210325-0) | libSDL-devel | /usr/bin | sdl-config
zypp (download.opensuse.org-oss) | libSDL-devel | /usr/bin | sdl-configというような感じになります。
ただ、日本語で表示するとカラムがずれてしまうこと、マニュアルに書いた例題が、上記以外では動作しないこと(python のエラーになります)があるので、使えるかどうかは微妙なところです。
パッケージ名 sc
バージョン sc-7.16-13.26.x86_64
動作 ◯
詳細
コンソールで動くスプレッドシートです。但しちょっとくせがあります。文字はそのまま入力できず、必ずプレフィックスをつける必要があります。例えば、数字や数式を入力する際には、まず = キーを押してから、入力したい文字列を入れます。
文字列も入りますが、日本語文字列は、UTF-8環境では入りませんでした。
カーソル移動は矢印キーのほかに、h、j、k、l の vi 風キーバインドでも使えます。
関数は @sum とか @lookup とか、@logとか、最低限のものは揃っているようです。
sc は、大昔のPC を知っている人ならば、 VisiCalc だと思えば感覚が掴めるかと思います。
パッケージ名 socat
バージョン socat-1.7.4.1-1.4.x86_64
動作
詳細
種々のソケットによる通信を中継してくれるツールです。IPv6 にも対応し、種々のネットワークオプションや細かな制御のためのオプションも用意されています。
一番簡単な使い方としては、ファイアウォールの内側にあるサーバに対して、入口のサーバに socat を設定しておき、socat 経由で接続するというやり方でしょう。あるいは直接ルーティングされていないセグメントへの接続時にも使えます。
たとえば、192.168.x.0 のセグメントから、172.31.y.0 のセグメントにあるサーバを経由し、 172.16.z.0 のセグメントにあるマシンに繋ぐには以下のようにします(ここでは、daytime プロトコルを起動しておいてそこに繋ぎます)。
socat tcp4-listen:8089,reuseaddr,fork tcp:172.16.z.zz:13結果はこうなります。
% telnet 172.31.y.yy 8089
Trying 172.31.y.yy...
Connected to susedev.
Escape character is '^]'.
28 APR 2021 18:00:15 JST
Connection closed by foreign host.このようにすることで、2段階のログインをしなくとも172.16.z.0 のセグメントにあるマシンに接続することが出来ます。
前回は Q でしたが、今回は T です。
パッケージ名 tcptraceroute
バージョン tcptraceroute-1.5.beta7-lp152.48.5
動作 ○
詳細
tcp を使った traceroute と同等の機能を実行するツールです。ICMP ではなくて、TCPで特定のポートを叩く形で traceroute 相当の出力を表示します。インストール時にはlibnet9-1.2~rc3-lp152.3.4 も必要となります(自動でインストールされます)。また、Thumbleweed には入っていません。LEAP のみです。
とあるサーバにtraceroute をしてみてもうまく動かなかったのですが、ポート 22 を指定して tcptraceroute を実行したところ、うまく表示できました。
% traceroute -n 210.171.174.178
traceroute to 210.171.174.178 (210.171.174.178), 30 hops max, 60 byte packets
1 172.31.255.254 0.875 ms 0.529 ms 0.612 ms
2 124.155.82.121 26.090 ms 25.900 ms 25.712 ms
3 124.155.82.69 25.762 ms 25.571 ms 25.651 ms
4 124.155.82.2 25.465 ms 25.627 ms 25.441 ms
5 202.224.52.170 62.408 ms 62.183 ms 61.993 ms
6 202.224.52.5 24.652 ms 27.474 ms 27.147 ms
7 202.224.52.13 27.300 ms 16.913 ms 16.556 ms
8 203.190.230.13 16.553 ms 16.760 ms 16.508 ms
9 61.211.190.90 16.626 ms 16.458 ms 61.211.190.98 16.564 ms
10 219.124.151.210 16.147 ms 20.514 ms 19.783 ms
11 210.171.170.10 19.491 ms 19.283 ms 8.395 ms
12 210.171.170.34 7.396 ms 18.154 ms 17.967 ms
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
% tcptraceroute -n 210.171.174.178 22
Selected device eth0, address 172.31.255.189, port 57123 for outgoing packets
Tracing the path to 210.171.174.178 on TCP port 22 (ssh), 30 hops max
1 172.31.255.254 0.614 ms 0.723 ms 0.702 ms
2 124.155.82.121 4.183 ms 3.435 ms 3.461 ms
3 124.155.82.69 4.362 ms 4.036 ms 3.909 ms
4 124.155.82.2 3.690 ms 3.572 ms 4.257 ms
5 202.224.52.170 6.843 ms 6.607 ms 10.887 ms
6 202.224.52.5 6.634 ms 6.954 ms 6.597 ms
7 202.224.52.13 5.601 ms 4.822 ms 5.065 ms
8 203.190.230.13 5.674 ms 6.073 ms 7.402 ms
9 61.211.190.90 6.423 ms 5.553 ms 6.690 ms
10 219.124.151.214 5.680 ms 6.735 ms 5.742 ms
11 210.171.170.10 6.646 ms 6.523 ms 7.012 ms
12 210.171.170.34 5.233 ms 7.322 ms 6.962 ms
13 192.168.3.252 10.616 ms 6.878 ms 10.268 ms
14 210.171.174.178 [open] 8.053 ms * *
ただ、万能ではないようです。Azure の中にある仮想マシンに、 tcptraceroute をポート 3389 や port 22 で実行してみたのですが、やはり繋がりませんでした。
パッケージ名 tdiff
バージョン tdiff-0.8.5-3.6.x86_64
動作 ◎
詳細
ディレクトリの比較をするコマンドです。diff とは違い、ファイルの差分を取るわけではありません。ディレクトリ中のファイルについて、日付や属性などを比較するためのツールです。たとえば、このような感じになります。
# tdiff . /home/ribbon
tdiff: (top-level): mode: 0700 0755
tdiff: (top-level): uid: root(0) ribbon(1000)
tdiff: (top-level): gid: root(0) users(100)
tdiff: (top-level): nlink: 9 21
tdiff: .bash_history: uid: root(0) ribbon(1000)
tdiff: .bash_history: gid: root(0) users(100)
tdiff: .bash_history: size: 1382 3546
tdiff: .bash_history: contents differ
tdiff: .bashrc: only present in /home/ribbon
tdiff: .cache: uid: root(0) ribbon(1000)また、-v オプション( -vv,-vvv,-vvvv もあります)を指定すると統計情報を出力します。
tdiff: inode cache statistics:
Hashing statistics for inode cache (@0x55916e3e4610):
Table size : 101
Entry count : 11
Occupied buckets : 10
Distribution efficiency : 90.91%
Average bucket length : 1.1
Max bucket length : 2
tdiff: endそのほかにもオプションが多数あります。数字の0 から 9 までのオプションを指定すると、チェックする項目が徐々に増えていくようになっています。
# tdiff -0 .local /home/ribbon/.local
# tdiff -1 .local /home/ribbon/.local
tdiff: share/RecentDocuments: only present in /home/ribbon/.local
tdiff: share/baloo: only present in /home/ribbon/.local
tdiff: share/flatpak/.changed: only present in .local
(略)
# tdiff -2 .local /home/ribbon/.local
tdiff: (top-level): mode: 0755 0700
tdiff: share/RecentDocuments: only present in /home/ribbon/.local
tdiff: share/baloo: only present in /home/ribbon/.local
tdiff: share/flatpak: mode: 0700 0755
tdiff: share/flatpak/.changed: only present in .local
(略)
# tdiff -3 .local /home/ribbon/.local
tdiff: (top-level): mode: 0755 0700
tdiff: (top-level): uid: root(0) ribbon(1000)
tdiff: (top-level): gid: root(0) users(100)
tdiff: share: uid: root(0) ribbon(1000)
tdiff: share: gid: root(0) users(100)
tdiff: share/RecentDocuments: only present in /home/ribbon/.local
tdiff: share/baloo: only present in /home/ribbon/.local
tdiff: share/flatpak: mode: 0700 0755
tdiff: share/flatpak: uid: root(0) ribbon(1000)
tdiff: share/flatpak: gid: root(0) users(100)
tdiff: share/flatpak/.changed: only present in .local
(略)tdiff は、ファイルの有無や、属性の違いなどを一気に調べるときに便利に使えそうです。
前回は D でしたが、今回は Q です。Qt関連のパッケージが多く存在していました。
パッケージ名 qdirstat
バージョン qdirstat-1.7-1.6.x86_64
動作 ◎
詳細
グラフィカルにディスクの使用量を見たり、ファイルやディレクトリの操作をするツールです。Qt ベースで動きます。見栄えはかなり良いです。
面白いのは、下部に表示されている図で、これは、各ファイルの大きさをベースにしたイメージです。例えば、ある大きな模様の所をクリックすると、そのイメージに対応するファイルに移動することが出来ます。
さらに、右クリックで種々の操作を選ぶことも出来ます。
qdirstat は、ディレクトリを渡りながら、ディスクの掃除をするときなどに便利に使えそうです。
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 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 | ||||
