システムが壊れたのを契機に、 X から Wayland への乗り換えと、合わせて Arch Linux から Debian bookworm に変更することとしました。 Arch Linux は 10 年前後ほど使っており、その前は 2 年ほど Debian sid を利用していたので、 Debian に戻ることとなります。 2 年ほど前にも Debian sid への乗り換えを試み、半年ほどで断念して Arch Linux に戻ってきたので、ふたたび Arch Linux に戻るかもしれませんが…

rss2email を利用して、 RSS を電子メールとして送信することができます。

RSSアグリゲーターとして Newsboat を利用しており、 Linux CLI ユーザとしては、 TUI で操作でき便利に利用していました。 しかし、同期やスマートフォンなどからの利用を考えると不便だったので、 rss2email を試してみることにします。

なぜ rss2email か

「大量のメールを効率的に捌く手法を構築しており、今後もメールは捨てる見込みが無いから」という理由につきます。 多くの OSS コミュニティはメールベースのコミュニケーション手法を確立しており、当方も procmail レシピによるメッセージデリバリーや、ターミナルベース MUA の NeoMutt などを利用しており、この仕組みに載せてしまえば良いと考えた為です。 同期やスマートフォンなどからの利用としては、 IMAP でカバーする事とします。

Phoronix Test Suite (pts) を使って、簡単なベンチマークを実施してみることにします。

Phoronix Test Suite は、クロスプラットフォームのベンチマークプラットフォームです。 プラットフォームと記載したのは、各ベンチマークがプロファイルとして記述され、プロファイルに基づきベンチマークのインストール及び実行とレポート生成を実行するフレームワークだからです。

Phoronix Test Suite には、 OpenBenchmarking.org との連携機能や、複数マシンでのベンチマークを管理する Phoromatic も存在します。 今回は、仮想マシンを用いて Phoromatic も試してみることにします。

各ベンチマークの詳細や、プロファイルの記述については記載しません。

これまで LUKS + LVM + ext4 で組んでいたのですが、スナップショットを手軽に取得したかったので、 LUKS + Btrfs に移行する事にしました。

LVMを用いているのでスナップショットを取得する事は可能なのですが、ブロックデバイスのスナップショットであり、事前に容量をReserveする必要があり、ファイルシステム用途としては使いやすいものでは有りません。 システムアップデートや巨大なソフトウェアをインストールする前にスナップショットの取得をするのですが、徐々に面倒になり、取得しないままシステムを汚してしまう事も有ったので、 Snapper を用いてスナップショット管理も実施します。

また、Btrfsファイルシステムは1つとし、サブボリュームを作成し /home や /var/log にマウントする事で、スナップショット単位を分割する事にします。

前回 BackupPC でバックアップを取得する で BackupPC を使ってみました。

複数クライアントのバックアップを取得でき、バックアップ対象にエージェントが不要など便利なのですが、 VPS 等のVMインスタンスが必要となるのが不便な点です。 NAS等の大容量プールをバックアップする際、それだけ大容量なブロックストレージをアタッチしなければなりません。 安価に構築する手法としてオブジェクトストレージをVMでマウントする方法も有りますが、それでは LUKS 等を利用できないので、バックアップソフトウェアで暗号化を担保する必要も有ります。 (前回の BackupPC では LUKS 上に構築しています)

今回は、ファイルサーバに Duplicity をインストールし、オブジェクトストレージ Backblaze B2 Cloud Storage にバックアップしようと思います。

Duplicity: https://duplicity.gitlab.io/duplicity-web/

Backblaze B2 Cloud Storage: https://www.backblaze.com/b2/cloud-storage.html

Duplicity の主な特徴

• OSS の CLI バックアップソフトウェア(Ubuntu の 標準 GUI バックアップツールである Deja Dup のバックエンド)
• GnuPG を用いた暗号化及び、署名による改竄検知が可能
• 各種オブジェクトストレージ、クラウドストレージサービス、scp、WebDAV 等をサポート

OSS の BackupPC を用いると、 Linux, macOS, Microsoft Windows のファイルレベルのバックアップをエージェントレスで取得できます。 WebUI から複数ユーザで利用する事ができ、重複排除及び圧縮、世代管理など、コンピュータのバックアップには十分な機能だと思います。 今回は、サーバ及びバックアップ対象のクライアント、どちらも Debian を用い、プロトコルとして rsync を用います。

https://backuppc.github.io/backuppc/

BackupPC の主な特徴

• NFS, rsync, smb, ftp 等が利用でき、エージェントレスで実行できる。
• データ圧縮及び、単一もしくは複数コンピュータ間でのデータ重複排除。
• WebUI から複数ユーザで利用する事ができる。(今回は管理ユーザのみ利用する)
• 電子メールでの各種通知。
• Perl 製

本記事は、CentOS 8のリリース時に調査した内容を、Rocky Linux 8.5 ベースで再調査した内容です。

仮想マシンの普及に合わせて、実行タイミングをランダム化しホストサーバに負荷が集中しないようにできる anacron は注目されたタスクスケジューラーですが、設定ファイルの内容とジョブの実行タイミングについて、誤った認識を持つ事が有ります。 例えば、以下の /etc/anacrontab において、ジョブが実行されるのは次のどれでしょうか？

]$ cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly

A. START_HOURS_RANGE と RANDOM_DELAY から求められ、[3-22]:00 - [3-22]:45 のいずれかランダム。つまり、3時 ~ 23時 の間の 00分 ~ 45分 のいずれか。
B. 上記のAに delay in minutes を足した値。cron.dailyであれば 5 なので、 [3-22]:05 - [3-22]:50 のいずれかランダム。
C. 上記のBの範囲にて、 anacron が最も初めに起動したタイミング。つまり24h稼動であれば 3:[05-50] のいずれかランダムに実施し、3:51以降に cron.daily を実施する事は無い。22:00 にマシンが初めて起動した場合、 22:[05-50] のいずれかランダム。
D. 上記のCと似ているが、「delay in minutes + (RANDOM_DELAYによってランダムに算出された分数)」は、毎時00分では無く、 anacron の起動タイミングに加算される。つまり、 21:58 に anacron が初めて起動し RANDOM_DELAY で算出された値が3で有る場合に cron.daily であれば 「21:58 + 5 + 3 = 22:06」 に実行される。START_HOURS_RANGE の範囲外である 22:01 にanacronが起動した場合は範囲外なので実行されない。
E. 上記のDと似ているが、ジョブ実行タイミングが START_HOURS_RANGE の範囲内である場合のみ実行する。つまり、 21:52 に anacron が初めて起動し RANDOM_DELAY で算出された値が3で有る場合に cron.daily であれば 「21:52 + 5 + 3 = 22:00」 に実行される。より厳密には、22:00:00 は範囲内として実行されるが、22:00:01 以降であれば、実行しない。

COVID-19 が日本で落ち付き始めているので長期外出にも対応できるよう、 macOS Monterey を試用していたラップトップを Linux に戻す事にしました。 MacBook Pro Early 2015 (MacBookPro12,1) を用い、 Arch Linux では無く、 Debian bullseye をベースに構築します。

サーバとして Arch Linux or CentOS を用いていたのを最近は Debian に変更しており、クライアントでも Debian を取り入れようと考えており検証も兼ねています。 X Window Server -> Wayland の変更も検討もしましたが、途中で諦めたので、改めてやり直したいと思っています。

今まで Haswell (第4世代Intel Coreプロセッサ) のマシンを使っていたのですが、Rocket Lake (第11世代Intel Coreプロセッサ) のマシンに買い変えました。Arch Linux + i3-wm という軽量な環境を利用しているので、性能の観点から買い替えの必要が逼迫していたわけでは有りませんでした。ただし、大きめのコードをコンパイルする時や、NVIDIA + Nouveau の動作安定性などの観点からストレスは有ったので、性能向上とIntel iGPUへの変更を兼ねてリプレースする事としました。

dd(1) はブロックデバイスを読み書きする際に非常に便利で、ストレージ装置のバックアップやクローン作成、データ消去などに利用します。その際に(i)bs=[bytes]とcount=[count]で読み込みブロックサイズと個数を指定できますが、ddコマンドと、内部で利用される read(2) の特性を把握しておかなければ、部分的な読み出しにより、期待した出力が得られない事があります。通常は警告が表示されますが、バックアップやクローン用途で使っておりスクリプトで実行している場合、気が付かなければデータ破損に繋がります。

ここではデータ破損と表現していますが、入力と出力がブロック単位で同一とならない事象が発生するものであり、入力データが破損するものでは有りません。

久し振りにLinux workstationとしてArch Linuxをセットアップしたので記録を残しておきます。 Part.1 として、OSのインストールまでを実施します。

以前から引き継ぐポイントや重要視した事

• UEFI GPT boot とする。
• UEFI GPT boot に必要な ESP (EFIシステムパーティション) 以外は、/boot も含めて LUKS にて暗号化を実施する。
• ESP に設置するファイルに関しては、UEFI Secure Boot を用いる事で改竄検知の対策とする。

昨年、ディスプレイ故障によりDell製の27インチWQHDディスプレイP2720DC x2に買い替えたのですが、ComfortViewというバックライトや発色を優しくするプリセットモードが有り利用していました。いわゆるムービーモードやゲームモードと同様にOSDにて設定できる表示モードの1つなのですが、最近はコンソール以外に動画等も見る機会が増えたので、標準とComfortViewを容易に切り替えられる事が望ましくなったためスクリプトを組みました。