Category: Debian

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

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のものか新規に購入するかは未定．

xzにsshのバックドア

久しぶりにセキュリティー界騒然の事態ですね．劇場型のやり取りなどで3年がかりでxzのメインテナーに加わった人物がxzにsshのバックドアを仕組んだそうで，スパイ映画さながらです．

問題になるのは，xz (liblzma) 5.6.0と5.6.1だそうです．日常的なファイルの圧縮展開に利用されるばかりでなく，圧縮効率が高いため多くのdistroがパッケージをxzで圧縮して配布していてます．

手元のMac miniではMacPortsを使っているのでxzが入っているはずです．調べてみると（注意: xzコマンドを発行してバージョンを調べるのは危険かもしれません），

まさにドンピシャのものが入ってました．早速，

port selfupdate
port upgrade outdated

をかけたら，安全とされる古いバージョンに戻りました．

ちなみに，手元のいくつかのdistroで調べたところ，Slackware64とARM (32bit)の15.0は5.2.5で問題なし，Debian BookwormとRaspberry Pi OS Bookwormも5.4.1で問題なしですが，ManjaroはAMD64, ARM64とも5.6.1で今のところupdateは来てません（2024年4月4日09:35JST現在）．

圧縮のスピードはかなり遅いですが😅
ただし，Slackware AArch64 currentは5.6.1です．他のアーキテクチャーのcurrentも5.6.1の可能性が高いです．
Manjaroは配布パッケージの圧縮にgzipを使っているようなので．ユーザーがxzをなにかの目的で使わなければ大丈夫なのかもしれません．

DOSBoxメモ (9) 一から出直し

行き詰まってしまいました．というのは，DebianのBochsがまともに動いてくれないのです．起動するとすぐにデバッガーに落ちます．

動作をまとめた表には， “Installed and working” としていましたが， “Installed but NOT working” にしました．Raspberry Pi 5 Model B (RPi5)のRaspberry Pi OS (RPiOS)も同じです．これらの環境ではインストールに成功して試しもしないで動くものだと思い込んだようです．

なんかDebianはモジュール化にこだわっているようで，Bochsを動かしたいだけなのに，いくつものバッケージをインストールする必要があり，それに過不足があるのか他の設定に問題があるのか，そのあたりかなり手強そうなので，もうこれ以上追求しません．

現在Bochsがまともに動くことを確認している環境は，Slackware AArch64 current (RPi5), Slackware ARM 32bit 15.0 (RPi4), macOS (Mac mini & Macbook)のみです．

スピード的に，CPUをエミュレートするRPi4, RPi5は不利なのでマクドで行くのがよさそうです．

しかし，マクドではQEMUの環境を整えていないので，Bochsのディスクイメージをホスト側でいじる事ができません．

なら，Slackware64でいこう，ということになりました．Slackware ARMとAArch64でbuildできて動くんですから，AMD64用OSならまちがいなく動くでしょう．

また，方針も大幅変更で，クリーンインストールにより最新のFreeDOSが動くようにして，そこになんとか鳳をはめ込む方向にします．

RPi5はまだなんとか使えそうなスピードですが，RPi4は無理です．
関東ではマック，関西とフランスではマクド．
仮想ディスクイメージをnbdによってボリュームとしてマウントする事ができない．