超久しぶりのDerpfest

常用スマホのPixel6aですが、Google純正OSに少し退屈してきたのもあって、ＧＷ中からいくつかつまみ食いをしてきました。

で、「ファイナルアンサーかな」と思ったのが、コレ、Derpfest 13 "Tango" です。

導入してまだ間無しですが、素性の良さは充分感じられます。Moto G5Plus で一時期Derpfestを使ってたことがあり、その時も同じように好印象／好感触でしたが、その感じが全く変わってなくて、一瞬で「これに決ぃ〜めた！」となりました。

ミニマムではなく必要なアプリを絞り込んだ格好でGappsがパッケージされており、その選択が自分の好みにぴったり合ったものですし、機能やデザインも洗練されて良い感じです。

Derpfestのウェブサイトでは、まだPixel6aが公式デバイスとして掲載されていませんでしたが、Sourceforge上の公式ディレクトリには Bluejay ディレクトリが作成されROMがアップロードされていました。

ダウンロードしたROMアーカイブ中のpayload.binから vendor_boot.img を取り出してFlashし、その後リカバリを起動してFactory Resetしてからadb sideloadでインストールしました。

バッテリの保ち具合など常用機向けＯＳとしての使い勝手はこれから検証していくことになります。

【2023/05/25追記】
しばらく使ってみてDerpfestの良さがさらによく分かりました。開発者さんがTestbuildを公開してくれていて、現状で 20230524 build に更新していますが、何１つ問題は無く（私が見つけられないだけかも）極めて安定しています。バッテリ消費は十分に穏やかですし、UIのカスタマイズもとってもクールです。

ClamAV OnAccess スキャナと戯れる

まったく予定の無かったＧＷの空き時間の多くを埋めてくれたClamAVですが、「よっしゃこれでいこ」と思ってＧＷを終えた途端に問題発覚。てゆーか、ぜんぜん上手に設定できてなかった…。

ということで、ＧＷ明けも空き時間をClamAVと戯れておるワケですが、とりあえずバッチ一括検査処理の方は「なんとかこれで良いやろ」という感じに設定できたのですが、問題は OnAccess スキャナの方。こいつがぜんぜんダメ。

一番の問題は、Clamonaccから検疫処理を依頼されたclamdが途方もなく膨大な量のWARNINGログを吐き出すこと。１〜２分ほどの間に60万行以上も記録され、且つ、LogSyslog disabled と設定しているにもかかわらずSyslogにも同じ量が記録されてしまうこと。

発生するのは/home下ですが、記録されたファイルを見てますと、アプリ等の処理で一時的に生成してすぐ消えるようなファイルが対象になってしまうようです。その為、そういうログが出る度に、ログを点検してファイル名を確認して、パス名の共通性を見出してからclamd.confにExcludePathを正規表現で追記する、ということを「運用で」繰り返す必要に迫られました。

OnAccessExcludePath（--exclude-list=）は正規表現に対応しておらず柔軟性に欠けること、OnAccessスキャンだけではなくバッチ一括検査の時にも同様問題が起こる可能性があること、からclamd.confのExcludePathを修正してその都度clamav-daemonを再起動する、ということをやってます。（めんどくせー）

現状で、clamd.confのExcludePathは以下のように育ってますｗ

ExcludePath ^/dev/
ExcludePath ^/proc/
ExcludePath ^/sys/
ExcludePath ^/run/
ExcludePath ^/snap/
ExcludePath ^/media/
ExcludePath ^/var/lock/
ExcludePath ^/var/log/
ExcludePath ^/var/run/
ExcludePath ^/var/clamav/tmp/
ExcludePath ^/swapfile$
ExcludePath ^/.*lost\+found/
ExcludePath ^/root/quarantine/
ExcludePath ^/root/\.lesshsQ$
ExcludePath ^/timeshift/
ExcludePath ^/home/.+\.lesshsQ$
ExcludePath ^/home/.+\.tmp$
ExcludePath ^/home/.+\.txt$
ExcludePath ^/home/.+\.log$
ExcludePath ^/home/.+\.lock$
ExcludePath ^/home/.+\.sqlite-wal$
ExcludePath ^/home/.+\.db-journal$
ExcludePath ^/home/.+\.sqlite-journal$
ExcludePath ^/home/.+\.store_new$
ExcludePath ^/home/.+\.vbox-tmp$
ExcludePath ^/home/.+\.xml-tmp$
ExcludePath ^/home/.+\.js$
ExcludePath ^/home/.+\.json$
ExcludePath ^/home/.+temp-index$
ExcludePath ^/home/.+/\.temp.+$
ExcludePath ^/home/.+/\{.+\}\.final$
ExcludePath ^/home/.+.[a-zA-Z0-9]{6}$
ExcludePath ^/home/.+/[0-9]+\.ldb$
ExcludePath ^/home/.+/\.cache/.+/cache2/entries/[A-Z0-9]+$
ExcludePath ^/home/.+/\.cache/.+scr--[0-9]+\.png$
ExcludePath ^/home/.+/Downloads/.+\.crdownload$
ExcludePath ^/home/.+/\.config/google-chrome/Profile\ [1-9]+/
ExcludePath ^/home/.+/\.thunderbird/.+/virtualFolders-[0-9]+\.dat$
ExcludePath ^/home/.+/\.mozilla/firefox/.+/usage-journal$
ExcludePath ^/home/.+/\.mozilla/firefox/.+/newtab$
ExcludePath ^/home/.+/\.cache/mozilla/firefox/.+-\.vlpset$

まったくバカらしい話で、「OnAccessスキャンなんて使うもんじゃない」なんて意見も見られるワケで、ほんとにそういう感じで、つまらん運用作業に手間取られるぐらいなら .cache .local .config 辺りをClamonaccの監視対象から除外してしまうのが「賢いやり方」のようにも思いますし、一時はそのように設定していました。

ただ、そうしてしまうと「何の為にOnAccessスキャンなんて動かしてるの？」ということになって「Clamonaccなんて止めちゃえ」ということになってしまいます。現状まだそこまで諦めをつけられていないので、「つまらん運用作業」を繰り返してるしだい。（バカですよね…）

使うアプリが増えたら除外条件に影響するでしょう。使ってるアプリが機能修正されても影響することもあるでしょう。そういうのにどう対応していくのが良いのか…。とにかく、ClamAVのアップデートで膨大なログを吐き出すのが止まってくれたらありがたいのですが…。Syslogが無用に肥大するのが痛すぎ。

ということで、今のところ ClamAV OnAccessスキャナ には過度の期待は持てず、徐々に機能が良くなっていくのを眺めながら運用支障の無い範囲で自分なりの良い使い方を見出すしか方法が無いようです。

【後刻追記】
ExcludePathのコード内容ですが、この日記を書いてるシリから変更せざるをえない状況が何度か発生して、とりあえず最新内容に置き換えました。

【2023/05/25追記】
心底バカらしくなって OnAccessスキャナを使うのを止めました。ログの爆発を制御しきれませんわ。こんなのに付き合ってられん…。てことで、それに合わせて clamd.conf の内容をシンプルにして、１日１回バッチ一括検査する運用でいくことにしました。そう決めたら気が楽になった…。

Linux MINTにClamAVを導入

Linux MINTで平和に過ごしております。セキュリティ対策の基本方針として「ソフトウェアをきちんとアップデートするから、ウィルス対策アプリなんて要らん。ノーガード戦法や」ということにしていましたが、今頃になって「いかがなものか…」という気がしてきて、ようやく重たい腰をあげて ClamAV を利用することにしました。

今回自分でやってみて分かりましたが、導入/構成がこれほど大変だとは思いもしませんでした。まぁ、その「大変さ」の多くは自分の知識/技術が足りてないせい、ではありますが…。

Ubuntuにパッケージが準備されているので導入自体は簡単な話です。問題は「きちんと動かすこと」でして、これがまぁ、手数が多いうえに思った通りの結果にならずにナンギしました…。

OnAccess Scanもバッチ一括のフルスキャンも、基本的には以下のページに書いてある通りに実施しました。

Setting up ClamAV - GitHub
https://gist.github.com/johnfedoruk/19820540dc096380784c8cf0b7ef333b

この中で示されているscan.shの内容が一部間違ってて上手く動作しなかったので、以下の赤字の箇所を手直ししました。

また、ウィルス検知した時の通知とは別に、一括検査が終了した時に結果をメール通知するようにしました（その為に Postfix/dovecotまでインストール／設定しましたがな…）。日常運用的に問題が無くなってきたらメール通知は止めてしまうつもりです。

OnAccess Scanですが、説明通りに設定して実行すると猛烈なパフォーマンス悪影響で「こりゃダメや」となりました。チューニングして問題回避する（or症状緩和する）余地は何かあるんだろうと思いますが、他にやることがいっぱいあるので後回しにして、とりあえず、OnAccessPrevention false として逃げました。

OnAccess Scanが想定通りに機能させれたら定例的な一括検査はするつもりは無かったんですが、そうではなくなったので日次でフルスキャンをかけるようにしました。/proc, /devなど一部ディレクトリを除外しつつ ／ からのフルスキャン。普通に端末を使ってる裏でフルスキャンをかけてみましたが、端末操作に気になる影響は無く、ざっと2時間ほどでスキャン完了するので、まぁ、ヨシとしました。

今回導入したClamAVは v0.103.8ですが、バグが原因なのか妙なエラーやワーニングが山ほどログに記録されており、パッケージのアップデートが待たれます（と他力本願）。「そもそも」という話でいけば、VirusEvent が全く機能しないのはこの手のプロダクトとして「いかがなものか」という気がします。

OnAccess Scanのパフォーマンス影響の対策、clamd.confの整理整頓、など宿題が残っていますが、ぼちぼち対処していくことにします。

パソコン用スピーカを新調

デスクトップＰＣを初めて自作したのが１９９６年ぐらいだったと思います。最初のWindows95は既に出ててOSR2がまだ出てなかった頃です。

店員さんのお薦めで選んだスピーカがDIATONE DS-31Pで、それを今日までずっと使い続けてきました。四半世紀以上、ですね…

しかしさすがに寿命末期、右スピーカの出力がしだいに下がってきて、どうにもならなくなってしまいました。左右バランスを調整して誤魔化してきましたが、我慢の限界…

で、新しく調達したのが上の絵にあるFOSTEX PM0.1e。先代DS-31Pと同じく、設置場所の都合で横倒しで設置してありますが、ちゃんと鳴りますｗ

音は、小型フルレンジ一発のスピーカなりですが、机上で小音量で圧縮音楽／ストリーミング音楽を聴くぶんにはまったく問題ありません。下も上も聴きやすい音を出してくれます。

第一印象として唯一気に入らなかったのは前面の電源LED。白色ですが目に刺さりますｗので、黒のアセテートテープでおとなしくさせました。

小型スピーカなのに予想外に大きな梱包で届いて驚きました。丁寧に保護されてて好印象。また、重量も「それなりに」あって、安モン小型スピーカばりの軽々しさは微塵もありません。しっかりした感じで安心感も高い。「良質なスピーカは、それ相応に重量があるもの」と信じております。

っということで、このスピーカ、はたして何年もってくれるでしょうか…
先代同様の寿命なら、今回が「人生最後のスピーカ購入」となるはずｗｗｗ

大切に使います。

画面出力がスリープから復帰しない（ことがある）件

 前の日記に書いておりましたが、スリープから復帰する時、パソコン本体は復帰しているように思えるのにモニタが真っ暗なまま復帰してこないことがありました。

ハイバーネートを無効にしたり、nVidia Driverの一部設定を変更したりしましたが対処しきれずにいました。が、ようやく正当な対策らしきものを見つけました。（探し方が下手なだけ）

nVidiaの開発者向けフォーラムに投稿されていたものですが、nVidia driverの電力制御に関して、Kernel Driver Callbackからsystemdに方式が変更されたが、そのsystemd方式がバグってた、と。

なので、関連するサービス類を止めて（無効にして）しまえば良い、のだとか。

っということで、この投稿に記載されてある通りの対策を実施して現在様子見中です。問題の症状はまだ一度も起こっておりません。

で、その後いくつか追加で調べてみたところ、もっと簡単に「/usr/bin/nvidia-sleep.shの先頭に exit 0 を追加すりゃエエ」というものを見つけました。つまり、問題原因だったのはこの nvidia-sleep.sh の処理内容だ、てことのようで。

この方法が簡単・手軽で良いかもしれません。