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によっては番号が違う場合があります.

サーバー不安定

下記のようにUSB HUBの故障かと思いましたが,予備用のHUBを使っても起動後しばらくしてシステムがハングアップしてしまいます.トラブルの原因の特定にはもう少し時間がかかりそうです.

USB HUBの故障と推定(たぶん誤り)

某サーバーですが,本日電力系統への落雷が原因と思われる停電があり,数分後に復電しましたが,ブートしなくなりました.

BIOSのメッセージからブート用のメディアが見つからないようです.メインのSSDは,/bootとROOTとの2パーティションなので,たぶん/bootがファイル的に壊れたものと思い,他のLinuxマシン(以下 “作業用マシン” )でfsckをかけました.致命的ではない軽微な修復がなされましたが,サーバーに繋いでも症状は変わりません.

もう一度作業用マシンに繋いで/bootとROOTもfsckをかけました.ext4のROOTは頑強で何の問題もありませんでした.念の為/bootはフォーマットしたうえで今朝のバックアップをコピーしました.

それでも症状は変わりません.これは本体かなと思い,サーバー機とほぼ同じスペックの予備機と入れ替えましたが,やはりブート用のメディアが見つかりません.

これはひょっとしてと思い,USB3.0のHUBをとばしてSSDをサーバー本体に繋いだらブートしました.

これは間違いなくUSB3.0HUBの故障です.予備用のUSB3.0HUBを使って従前と同じマスストレージの接続形態に戻したら,サーバーは無事にブートしました.

当面はこの予備用のHUBを使いますが,安くて良さそうなUSB3.0HUBを探して注文することにします.

本当はBIOSではないのですが,一般的なPCならBIOSなので,説明の省略も兼ねてそう記します.

DOSBox-Xメモ (2) Flatpakのトラブル

DOSBox-Xは正式なチャンネルでインストールできるdistroはないものの,Slackware系ではSlackBuilds (sbopkg)でインスール可能で,また,Flatpakを正式にサポートしているDebian (Raspberry Pi OSを含む)とManjaroで利用可能である可能性が広がります.

早速手当り次第やってみたところ,Raspberry Pi OS (RPiOS)でFlatpakのインストール後,

flatpak install dosbox-x

としても,見つからないよ,とエラーが出ます.

昨夜はヤホーの検索の結果をいくつか眺めていましたが,そのひとつにgitでDOSBox-Xのソースを取り寄せてbuildして,Flatpakのパケージを作って,ローカルからflatpakでインストールしろなんて途方もない事が書かれていました.

自力でbuildするなら敢えてflatpakを使用する意味がないような気がします.

今朝,何気なくもう一度検索してみたら正しい答えが見つかりました.

Abhishek Prakashさんの “Fixing Flatpak Error: No remote refs found similar to ‘flathub’” (It’s Foss)より,

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

をroot権限で実行することにより解決しました.

あくまで,筆者が日常的に実マシン・仮想マシンをいじっている中の話です.
本当はGoogle検索です.

DOSBox-XでLog200

DOS用LogソフトLog200をWindowsのDOS窓以外で動かす取り組みですが,Slackware64 (AMD64)のDOSEMUのもとで,Log200を動かして,Slackware ARM (32bit)のサーバー上にあるデータファイルはNFSでアクセスしよう,ということにしました.DOSEMUはmacOS上で動くVMWare Fusionで動くSlackware64でも動きますし,そこからNFSでサーバーのディレクトリーをマウントすることもできますから,仮想マシンと実マシンのいくつかの環境からLog200を実用的に使えます

いちおうこの状態を結論としていました.

ところが先日,親切な通りすがりのかたが,DOSBox-XのDOS/VモートでLog200が動く可能性が高いとアドバイスしてくださいました.

さっそくDOSBox-Xがインストール済みなmacOS (x86_64 Sonoma 14.5, x86_64 Ventura 13.8.7)で試したところ,あっさり動きました.通りすがりのかたに教えていただいた通り,基本的に設定ファイルである “dosbox-x.conf” に,

[dosv]
dosv=jp

と書くだけで自前でDOSを用意する必要さえもありません.

macOS Ventura (x86_64 13.8.7)上で動くDOSBox-Xで動くLog200 (DOS版)

以前調べたところではDOSB0x-Xは,Debian (Raspberry Pi OS)やManjaroでは公式チャンネルからの配布はありません.代わりにFlatpakというパッケージマネージャーでインストールすることになっていて,今回あらためてインストールしたところ,日本語DOS/Vモードがちゃんと動き,Log200も問題なく動きました.

Raspberry Pi OSにインストールしたFlatpakで動くDOSBox-Xで動くLog200

Flatpakでうまく行った環境は,

  • Manjaro AMD64
  • Raspberry Pi OS (64bit)

です.あっさり書いちゃましたが,非x86のRaspberry Pi OS(Raspberry Pi 5 Model B 8GB RAM)でも簡単に,しかも実用上問題ない速度で動きました.

Raspberry Pi OSで動きますから,Debian AMD64でも間違いなく動くでしょう.

最終目標である,Slackware ARM (32bit)ですが,もちろん公式配布パッケージにDOSBox-Xは含まれていませんが,SlackBuildsにはあるので,sbopkgでインストール可能な可能性があります.一方SlackBuildsにはFlatpakもあります.

他にFlatpakで動かすアプリがいくつかあれば先にFlatpakを試す価値はありますが,いまのところDOSBox-Xだけですから,先にDOSBox-Xをsbopkgでbuildするほうがいいだろうと判断してそうしました.

で,buildできて動きました

Slarckware ARM (32bit) 15.0にsbopkgでインストールしたDOSBox-Xで動くLog200 DOS版

いよいよSlackware ARM64 15.1のリリースが待ち遠しいです.

仕立ててはいませんが,Manjaro AMD64をホストにしてSlackware64のゲストからも同様にLog200は動かせます.
MacPortsによる.
buildには少々時間がかかりますが.

Manjaro ARMのRPi5 kernel

Raspberry Pi 5 Model B (RPi5)の評価はその後も続けています.テストしているのはRaspberry Pi OS (RPiOS), Manjaro ARM(64bit), Slackware ARM64 (Slackware-current)の3OSで,そのうちのRPiOSとSlackware ARM64はRPi5を入手した2024年初時点でRPi5をサポートしてました

Manjaro ARM64は一番使いたかったOSでしたが,当時は公式にRPi5をサポートしておらずどうしたものかとヤホーで検索したところRPiOSのKernelとモジュールなどを使えばよいと知りその状態で動かしてきました

その後4か月も経つので正式Kernelもあるだろうと,PacmanのGUIフロントエンドであるAdd/Remove Softwareの検索窓に “rpi5” と入れて検索したら,Kernelなどがあることが解り,早速インストールしました.

ネットで調べたところ本年3月には公式Kernelがあったようです.まあ,Manjaro ARM64がRPi5で動かせていたので今更どうでもいいですが😅

今後,ないとは思いますが,RPi4で使うことも考えて,RPi4用のKernelなども残しました.削除するのは簡単ですし.

今までのところ,RPi5上でRPiOSとManjaro ARM64は十分使える感じです.

Slackware ARM64に関しては,Slackware-currentであるため,ほとんど毎日のようにいくつものupdateが来て,サーバーがあまり強力でないこともあって,その度にupgradeにものすごく時間がかかります.その事もあっておよそ使いやすいとは言えません.

現在の “結論” 的には,Slackware ARM64の15.1 (次期公式リリース)が出るのを待って,RPi5にインストールして,次期サーバーに仕立てます.

Slackware ARM64は,SARPi5により.
本当はGoogleです.
slackpkg upgrade-allをかけたまま就寝することが多いです.
現在使用している8GB RAMのものか新規に購入するかは未定.