今回は ranger を紹介します。

ranger は、コンソール上で動作するファイラーです。日本語化はされていませんが、要所要所で動的にヘルプが出てくるため、それほど困ることはありません。コンソール上で動作するファイラーには mc が有名ですが、mc とは違い、標準で1つのディレクトリに注目するタイプです。
起動すると、このような画面が表示されます。

画面は、三つのペインからなり、左二つがディレクトリ、一番右が注目しているファイルの内容を表示します。テキストファイルであればほとんどのものが表示できます。UTF-8でエンコードされていれば、日本語も表示できます。また、バイナリファイルでも、一部の形式では、ファイルの情報を表示します。
真ん中のペインが今注目しているディレクトリです。ファイルやディレクトリの選択にはカーソルキーのほか、vi と同じ hjkl のキーが使えます。但し、vi のキー配置は、QWERTY 配列に特化しているので、 DVORAK 配列で使うとかなり使いにくいです。

また、複数の画面を管理出来ます。この機能は、タブ機能を使います。”g”の次に”n”を入力することで、タブが有効になり、複数のディレクトリ表示ができるようになります。TAB キーで画面を切り換えることもできますし、”~”キーで左右に表示させることもできます。たとえば、片方のディレクトリからもう片方のディレクトリにファイルをコピーする際には、スペースキーで対象のファイルやディレクトリを選択した後、vi 風のコマンド yy でコピーして、pp でペーストします。

ranger にはこのほかにも、ファイルの整列や検索、パーミッションの設定、シェルの実行など多数の機能があります。色々試してみても面白いと思います。

この記事は openSUSE Advent Calendar の6日目です。

通常、root になって、 poweroff コマンドを投入すると、システムはシャットダウン動作を行い、電源を落として停止します。しかし、第四世代 Intel CPU の場合、poweroff コマンドで一度電源断まで行ったのち、数秒後に再起動してしまいます。少なくとも手元の i3-4130T、i5-4200M ではこの現象が発生します。
これを解決するには、boot時、grub.cfg の中に、
linux /vmlinuz-........ xhci_hcd.quirks=0x2000

のように、パラメータを追加する必要があります。

第四世代 Intel CPU を使ったマシンは、今から7-8年くらい前のもので、少々古いマシンではありますが、使い方によってはまだまだ使えます。もしもなぜか再起動してしまうという現象にお悩みの場合には上記のパラメータを試してみてください。

この記事は小江戸らぐ 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 時間を他と比較して使ってしまっていますので、場合によっては収集する項目を減らすなどを考えたほうが良いかもしれません。

前回は 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 のセグメントにあるマシンに接続することが出来ます。

諸事情で、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 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独自なのか、一般的なのか、といったことも追いきれておらず。追って調査したいと思います。

そもそもの使い方

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