3プロジェクト進行中

つくづく自分はコンピューターとネットワークがあれば生きていけるんだなあと思う今日この頃です😓

さて,現在3つのプロジェクトが進行中です.

メインWSのリプレース

メインWSは現在史上最強のIntel Mac miniです.Mac mini最初で最後のデスクトップIntel Core CPUを搭載したMac miniで,しかもCore i7にCTOしてますので,間違いなくIntel Mac miniとしては他に右に出るものはありません.

たしかに抜群のパフォーマンスでしたが,Apple Siliconと比較すると何分の1も遅いようですし,いよいよ次のmacOSのメジャーリリースmacOS 26では対象外となるようなので,ここで最新のMac miniを導入しようと画策中です.

まあ,このプロジェクトはその購入資金をいかに用立てるかということが主で,技術的な要素はあんまりないです😓

Webサーバー/プライベートサーバー更新

現在Raspberry Pi 4 Model B (RAM 8GB)でSlackware ARM (32bit)を走らせています.Slackware ARMは15.0が最新で,いろいろ陳腐化してきています.たぶん15.1(または16.0)のリリース時にはSlackware ARMプロジェクトもaarch64版を出すと思うのですが,いつになるか解りません.

そこで,素直にRaspberr Pi OS 64bitに移行します.必要なデーモン類についてはセキュリティー上詳しく書きませんが,まあ何とかなるとは思います.

ただ,Linuxサーバーの更新は気合いが必要なのでそれが心配です.

ハードウェアとしては現在予備役のRapsberry Pi 4 Model B (RAM 4GB)を使用して立ち上げようと思います.必要なUSB HUBも入手しましたし,ルートドライブとする予定の1TB SSDも確保済です.

それと置き場所がないのでWindow 10 32bitで使っていたデスクトップPCを廃棄します.メーカーのクレバリーが倒産してしまったのですが,PCリサイクル料金は払っているので,PC3R : : 一般社団法人 パソコン3R推進協会に申し込めば何とかなるようです.

そうしたスペース,設備的な整備の後,気合いが出るかというプロジェクトです.

門柱灯サイバー化計画

これが一番面白みがあるプロジェクトです.現在門柱にセットした防犯カメラはLEDの門柱灯の電源にACアダプターを付けて供給しています

現在の問題点は,

  • 屋内にあるWi-Fiルーターとの接続がぎりぎり
  • 門柱灯を24時間点けっぱなしにするとセキュリティーが甘いと見られかねないので,朝夕門柱灯はOff/Onしていますが,それだと防犯カメラもその時間しか動かない

の2つがあげられます.これを解決するために,

  • 屋外にWi-Fiルーターを設置する
  • 門柱灯を自動的にOn/Offする仕掛けをする

ことが必要です.

セキュリティー上詳細は書けませんが,一番チャレンジングです.

購入代金に含まれています.
第二種電気工事士の有資格者です.資格の範囲の工事です.

Moving to RPi OS (debian)

当BLOGの前身はもともとはx86_64のSlackware64で動いていました.それをSlackware ARM 14.xに移行したのは2016年頃であったようです.

Slackwareを使っているといつも遭遇するのですが,ソフトの陳腐化です.パッチレベルでは新しいものが配給されますが,メジャーバージョンのupgradeは基本的にありません.それで14.2でしびれを切らせていた頃15.0が出てくれました.

そのSlackware ARM 15.0に移行したのが2022年4月です.それから3年ちょっとですが,いくつか前述のように最新のソフトをキャッチアップしない故の不具合が出てきました

長年愛用してきたSlackwareを離れてRaspberry Pi OSに移行することにしました.まあそれなりに慣れたdebianみたいなもんです.

GUIなしでRaspberry Pi 4 Model B (RAM 4GB)に仕立てて,うまくいったらサーバーをスイッチし,さらにRaspberry Pi 5 Model Bにして,GUIもいれます.

なかなか前途は多難だと思いますが,ひと頑張りしてみます.

詳しくは書きませんが😓

Manjaroの弱点

筆者の愛用しているManjaroはrolling release modelというバージョンアップの方法を採用しています(ベースのArch Linuxがそうであるため).

まあ,GentooSlackware-currentも同様ではあります.この手のdistroの弱点は,しばらくupdateをしないで放置しておくと通常のupdateの手段ではupdateができなくなってしまうことです.

実マシンから作ったディスク仮想イメージとして存在させている仮想マシンは,もとの実マシンのバックアップ的な意味合いなので存在感が薄く,気がつくと最後の更新が何か月も前だったりします.

筆者のLinux第一WSであるManjaro AMD64も,ときどきバックアップのためにディスクを仮想化して仮想マシンに仕立ててます.仮想マシンとしても実は一番気に入っているので,Mac mini2台と実マシンであるManjaroのWS自身の中で仮想マシンとして “飼って” います.

気に入っているとは言えバックアップなので新し味がなく,ときどきupdateが何か月ぶりになってしまうことがあります.そんなときは他のupdate可能なイメージをコピーしたり,新たに実マシンから仮想化しました.パックアップの更新としての意義があります.

たまたま,前日updateができなくなった状態をあるSNSに投稿したら,親切な方が,

pacman-key --refresh-keys
pacman -Sc

を試してみてはと教えてくださいました

一台目はそれで復活しました.しかし,別の仮想マシンが同様の症状になっていましたが,上記の方法では復活できませんでした.1勝1敗です.

NGなほうはさらに別のマシンで動いているupdate可能なManjaroのディスクイメージをコピーして差し替え,動くようになりましたが,バックアップの意味を込めて後で久しぶりに実マシンから仮想化しようと思います.

筆者はシステムのメンテはrootでログインした状態で行うことをポリシーにしています(Slackware流)ので,コマンドごとにsudoを使う事はしません.

バックアップの削除でサーバーが無応答に

現在サーバーのバックアップは,バックアップの際にマウントする2TBのHDDに,前回からの差分をバックアップする形にしています.

rsyncでバックアップしています.今日の日付からなるディレクトリーをバックアップのボリュームに作り,ひとつ前の日付のディレクトリーを--link-destオプションで指定してサーバー内の全部(ただし,バックアップのボリュームのマウントボインや/tmp, /dev等は除く)をコピーすることで,変更がないファイルはハードリンク,変更があったファイルは新しいファイルをコピーするようなことを勝手にやってくれます.

rsyncは優秀で他のサービスに影響ありません.だいたい15分くらいで終わります.ただし,毎日毎日バックアップを続けると,だんだんハードリンクが長くなるせいか,バックアップに要する時間が長くなってきます.30分,1時間,ついには1時間越えと.

そこでときどき古いバックアップを削除します.手作業です.削除は普通にrmコマンドに-rオプションを付ければよいです.ただこれがなかなか重い作業で,rm自体はメモリーをほとんど食わず,SWAP領域が増えることもないのですが,kswapd0デーモンがかなりCPUサイクルを食います.何が起こっているかよく解らないのですが,ルートドライブもこのバックアップドライブもUSB接続だというのが良くないのではないかと今は推測しています.

昨日もずっとhttpdやその他のデーモンが動かなくなっていたのを知っていましたが,rmコマンドを途中でやめるわけにも行かず,一晩そのままにしておきました.

rmコマンドが終了しても,デーモン類はスタックしたまま自動的には復活しないので今朝システムごとリブートしました.

今後はバックアップの削除は他のWSにつないで行うことにします.

ThunderbirdがDovecotに繋がらなくなった件 (解決済み)

自前のサーバーで動くLet’s Encryptの証明書をupdateしてからどうもクライアントであるThunderbirdの挙動がおかしくなりました.

TLSのimap (=imaps)でつないでいます.ログインはできて新着メールは読めるのだけれど読んだメールをサブディレクトリーに移そうとしてもうまく操作ができません.

Appleの iOSやmacOSの “Mail” では正常に動作します.

サーバーのログを見ると,

というのがあり,たぶんこれだと思います.ネット検索した所,どうもDovecotのSSL/TLS設定が良くなかったようです.これまで,/etc/dovecot/conf.d/10-ssl.confのssl_certの設定は,

ssl_cert = </etc/letsencrypt/live/FQDN/cert.pem

としていました.これでこれまでAppleの “Mail” (iOS, macOS)もThunderbirdもつながっていましたが,

ssl_cert = </etc/letsencrypt/live/FQDN/fullchain.pem

としないといけないようです😅

これで,サーバーのDovecotのログにエラーは出ず,Thunderbirdも正常にサブフォルダーをアクセスできるようになったようではあります.

しかし,違うマシンのThunderbirdでアクセスすると見えないサブフォルダーが存在するなど今いち動作の信頼に欠けます.

Distroによっては番号が違う場合があります.