このところ迷惑メールが多くなってきているので対策。以下の送信元アドレスからのメールを受信拒否に設定。
- @creema.jp
- @gilt.jp
- @giltcity.jp
- @mp.cecile.co.jp
具体的にはメールサーバのSpamassassinの機能を利用し、 $HOME/.spamassassin/user_prefs に blocklist_from で登録。
OCNのアドレスも同様に設定。
(追記) ついでに *@*.cn も拒否。CNドメインから直接メールが来ることもないし。
Festina Lente ~悠々として急げ~
このところ迷惑メールが多くなってきているので対策。以下の送信元アドレスからのメールを受信拒否に設定。
具体的にはメールサーバのSpamassassinの機能を利用し、 $HOME/.spamassassin/user_prefs に blocklist_from で登録。
OCNのアドレスも同様に設定。
(追記) ついでに *@*.cn も拒否。CNドメインから直接メールが来ることもないし。
Dell Latitude 5285にWindows 11が搭載されたものを中古で購入したのだが、ふと気が付くと22H2にアップグレードできていない。どうやらスペック要件を満たしていないために自動でのアップグレードができない模様。
いろいろと調査して、スペック要件チェックをすっ飛ばす方法が分かったので 23H2にアップグレードしてみた。特に問題なく動作している。
調子に乗って、Windows 10のSurface Pro 2もWindows 11 23H2にしてみた。こちらも問題なし。これで来年の10月も安心。
いわゆる「Amazonの整備済み品」として購入。朝購入したら、当日の夕方には到着していた。
USB Type-C のポートが二つあるのだが、困ったことに Thundervolt 対応のポートは一つだけだった。これは電源を確保しつつ外部ディスプレイに接続することができないということを意味する!
ということで急遽 USB Type-C ドッキングステーションを急遽追加購入。
ついでに3デバイス接続可能のトラックボールも併せて購入。作業場所のマウススペースが狭い(A6サイズが確保できない‼)ので、トラックボールには期待。これで(スペースさえ許せば、だが)仕事用、古い個人用、新しい個人用、を使うことができる環境が整ったことになる。さて、作業性はいかに⁉
マウスもキーボードも何かの拍子にBluetoothの接続が外れて再接続されない.原因不明.困った…
(追記) どうやらスリープに移行した際に事象が発生しているような気がする。事象が発生したら、デバイスドライバからエラーを起こしているデバイスを一旦無効にしてそのまま再起動、再起動後にデバイスを有効化することで復旧する模様。
(追記) スリープ時に bluetooth の電源が off になってしまっている可能性もあるようなので、ドライバの設定を変更してみた。様子をみてみることに。
4年ほど使っていたbloetoothキーボードがヘタってきたので,Logicool K855を購入.
複数のデバイスを切り替えて利用できることがマスト条件で,どうせならメカニカルが良い,そして当然「それなりの価格」であることからの選択.
本日一日利用したが,なかなか具合がよろしい.
難を言えば,F1~F12キーを使う際にいちいちFnキーを押さないとならないのがちょっと面倒.Fn+EscでF1~F12に固定することもできるのだが,これをやってしまうとデバイスの切り替え(F1~F3に割り当てられている)の際にFn+Escのおまじないが必要になってしまうという,ちょっと悩ましい状態.まぁしばらく使ってみてどうすかを決めようか.
なおキーボード自体のリセットの方法が分かりにくかったのでメモ.
Esc o Esc o Esc b
の順番でキーを押す.これでF1~F3が同時に点滅するようになるので,おもむろに電源off, onでリセット完了.マウスに割り当てたデバイス番号とキーボードに割り上げた番号があべこべになってしまったのでリセットが必要になってしまった次第.落ち着いて作業しなきゃ…
(追記)
ちょっと落ち着いて考えればすぐにわかることなんだが… Fnキーをデフォルトにしておいて,デバイスを切り替える際に Fn+F1-3 を使うようにすれば問題なかった.しばらくの間はこれで行こう.
Ubuntu 18.04 LTS くらいからネットワークまわりの設定等を netplan を利用するようになっていることを,今更ながらに知った.
そろそろ追従しておくべきとも思うのだが,自宅のサーバはKVMレス運用なのでネットワークが利かなくなった時点でただの箱.
慎重に進めるべきだろうなぁ.
OSをjammyにアップグレードしたので念のため update しようと思ったら,サーバの名前解決ができない!?
どうやらDNSの情報がfossaから引き継がれていない模様.
/etc/systemd/resolved.conf にDNSを登録して再起動.
$sudo vi /etc/systemd/resolved.conf
[Resolve]
DNS=(DNSのアドレス) <-- この行を追加
$sudo systemctl restart systemd-resolved
ついでに接続先をIIJのミラーに変更.
自宅ではUbuntu 20.04 が主にファイルサーバとして稼働中.2025年4月まではサポートされるはずだが,ちょうどその時期は60歳をむかえて色々と生活が変わるはずなので,慌ててOSをアップグレードする心の余裕がないことが容易に想像される.というわけで,決して今が暇というわけではなくどちらかと言えば忙しいのだが,現実逃避効果を期待しつつ(?)アップグレードを決意.
主な用途はPCやスマホのファイルのバックアップだが,最近はWindowsで扱うファイルのメインのフォルダになっていたりするのでデータが飛んだりすると厄介.また手持ちのCDのほとんどをMP3にして保管してあるので,これがなくなると倉庫からCDを引っ張り出してこないとならないのも面倒だし,そもそもCDプレイヤも今となっては無い.AmazonMusicに全依存するのも悪くはないが,ふと聴きたくなったものが常に都合よくAmazonMusicにあるとも限らないし.
データのバックアップにはちょっと悩んだが,128GByteのUSBメモリを2本確保し,これらをext4でフォーマット,必要そうなデータはすべてcpコマンドでUSBメモリに放り込む.アップグレードに失敗したらサラからOSをインストールして必要なサーバをセットアップし,データはUSBメモリからコピーして使えばいいか,という作戦.なおこのコピー作業にかなり時間がかかり,都合3日(笑).
データのコピーが完了したら,まずは20.04を最新化(apt update & upgrade & autoremove).その後に22.04へのアップグレード(do-release-upgrade)を実行.ちなみにサーバ機にはKVMは一切接続されていないのでSSH接続にて実施した.アップグレード開始後にぼーっとターミナルを眺めている最中に,もしアップグレードの最中に不測の事態が発生してKVMを接続せざるを得なくなった場合,実はKもMもBluetooth接続のものしかないことに気づいてちょっと嫌な気分になった.Mはともかく,Kは有線のものを確保しておくべきかもしれない.
一抹の不安を抱えながらアップグレード作業を傍観すること5時間強,KVMを持ち出す必要もなく無事にアップグレードは完了.再起動すればjammyが起動してくるはず…
$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
お疲れ様!
数年前に購入して,主に宅内オーディオサーバとして利用していたRaspberry pi 3Bが休眠状態.スマホとBluetoothスピーカで代用できてしまうし,この方が手間がかからないので当然の流れか…
とは言え巷ではRaspberry piの価格が高騰している模様だし,このまま文鎮として利用する(文鎮としてすら利用していない?)のも勿体ないので,とある目的の測定器としての利用を画策中.
よくよく考えると計算機としてコンピュータを利用してきたものの,制御装置としての利用経験はほとんどないので,四苦八苦しながらもなかなか楽しい時間を過ごしている.かれこれ20年近くまともにコードなんて書いていなかったが,仕事ではないプログラム書きって,やっぱり面白い!
訳あってサーバをShutdownしようとしたのだが、MariaDBの停止プロセス中に以下の状態で引っかかる事象に遭遇。
A stop job is running for MariaDB 10.x.xx database server
ざっくりとネット上の情報を探ってみたが、どうにも今一つ納得のできる解決法に行き当たらない。
当面はreboot/shutdownの際には明示的にsystemctlからMariaDBを停止したほうが良さそう。
もっともこれで事象が再現しないという保証はないのだが… とりあえずメモ。