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 にマウントする事で、スナップショット単位を分割する事にします。

今月から、MTで運行しはじめました。まだ慣れていないので、変速を誤ったり、変速に気を取られておぼつか無くなっています。

Euro Truck Simulator 2 2022 02 06 Part.01

今月も忙しく、ETS2の運行は行えませんでした。 来月から、運行が無い月は記事を作成しないようにしようと思います。

前回 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 製

今月はもろもろ忙しく、ETS2の運行は行えませんでした。 同様に、ブログ更新やユーザ会での発表も行えておらず、気を引き締め直さなければと感じています。

来月は運行したいと思いますが、技術記事の執筆を優先する為、実際に運行できるかは不透明です。 また、次回からは MT車 で運行いたします。

先月に引き続き、ETS2という、ドライビングシミュレーションゲームの録画をYouTubeにアップロードしてまとめてます。

Euro Truck Simulator 2 2021 11 21 Part.01で、HCTを初めて引きました、もちろんダブルと比べると長いので気を使いますが、思ったより素直に付いてきてくれました。 ただ、接点が増えているのでバックは段違いに難しいですね、諦めました。

まだ Bダブル は引いた事が無いので、近いうちにトレーラーを購入したいと思います。

プレイスタイルですが、YouTube の「後で見る」リストに貯まった動画を流しながらプレイしており、基本的に集中力が減っている状態である上に、「後で見る」リストが多いほど、その週末にプレイする時間が増える傾向に有ります。

利用しているコントローラも経年劣化により、動作不良が躊躇になってきました。 元々はシーケンシャルを利用していたのですが、ここ最近は前述のプレイスタイルに合わせて、オートマチックを基本にしています。 しかし、調子の悪いコントローラを買い変えて、マニュアルに変更しても良いかなぁと思っています。 ダブル や HCT に合わせて重量貨物が増え、オートマチックの動作に不満が出る事が増えたのも、マニュアルを検討しはじめた理由の1つです。

Euro Truck Simulator 2 2021 11 05 Part.01

本記事は、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 の変更も検討もしましたが、途中で諦めたので、改めてやり直したいと思っています。