機種変更時のAuthenticaterの移行方法のメモ

最初、ここを参考にしていたが、「サインイン中に問題が発生しました」と表示されて入れない。調べたら、この方法は企業など独自のEntra-IDなどの場合の手順だった。

個人のアカウントの場合は、バックアップからアカウントの資格情報を復元するを実施する必要があった。

新しいPCは、WiFi 6Eに対応している。なのでWiFiルーターも更新することにした 。

WiFi 5からの目玉機能としてはメッシュWiFiがあるが、現在のWi-Fiルーターおよび中継器はWiFi 4相当なのでメッシュ機能に対応していない。 なので、ルーターとして使っているAterm WG2600HSと、メインの中継器であるAterm WG2200HPをAterm WX5400T6とAterm WX11000T12に更新した。

WiFi 6Eでは6GHzをバックホールとして使うことができ、LANの高速通信が期待できるので、ルーターをT6に、主に利用する環境のAPをT12にして普段の接続の高速化を狙った。 メッシュ化はマニュアルどおりに実施することで特に問題なく完了。リンク速度は2.4Gbpsがでており期待通りとなった。

しかしながら、従来の中継器を別の場所のレピータ(有線LAN延長)に使用しようとしたら問題が発生。 どうやら完全子機としては使えず、WiFiを中継器仕様とするため、無線LANの競合がおこり、電波をとめてしまっている模様。 バンドステアリングをoffにして電波帯ごとに個別のSSIDを割り振れば使えるのかもしれないが、ssidは一つにしたいので、保管していたAtermWL300NE-AGを引っ張りだすことに。 こちらはちゃんと子機として認識してリピーターとして使用できた。

T460sがWindows 11にアップデートできないため、X13 Gen5を購入。 Tシリーズが好きだったが構成的に気に入った形が選べなかったので一回り小さいXシリーズを購入した。

いろいろアップデートしていたたら、ディスプレイが暗くなってしまい、OS設定やキーボードから変更しても明るくならなくなった。 Intelのドライバー&サポートアシスタントですべてのドライバーを更新したのが原因だった。

レノボのサポートサイトからドライバーをダウンロードして元に戻して修復完了。 今まで20年以上ThinkPadを使い続けてきたが、インテルドライバーで問題なかったので初めての事象だった。

Shuriken 2018ならShuriken TLS設定ツールで対応できるのだが、2016なので繋がらない。 なので、stunnelで、rocky linuxのサーバにproxyを立てて、TLS 1.0 <-->TLS 1.2のバージョン変換をすることにした。 stunnelはwindows版もあるので、サーバーではなくPCそのものにインストール・設定してもつかえるかもしれない。
参考にしたのは、このページ。
stunnelはパッケージがあるので、dnf install -y stunnelでインストール。 設定ファイルは、/etc/stunnelにおけば名前はなんでも良いようだが、慣例にしたがってstunnel.confとした。記述内容は以下のとおり。

# /etc/stunnel/stunnel.conf # Log settings output=/var/log/stunnel.log service=stunnel # connect to sonet [TLS_proxy_connector] client = yes accept = 127.0.0.1:2525 protocol = smtp connect = mail.so-net.ne.jp:587 sslVersion = TLSv1.2 # connect from shuriken [TLS_proxy_listener] accept = 9025 protocol = smtp key = /etc/letsencrypt/live/jp-oota.net/privkey.pem cert = /etc/letsencrypt/live/jp-oota.net/cert.pem CAFile = /etc/letsencrypt/live/jp-oota.net/fullchain.pem connect = 2525

[TLS_proxy_connector]のセクションは、so-netへ接続させるためのもの。参考にしたページは証明書のverifyをしていたが、ルート証明書の指定と管理が面倒なのでverifyは行わないこととした。
sslVersionの設定は最初はしていなかったが、接続できなかったので追加した。 しかしながら、接続できなかったのは後述の「STARTTLSを使用」の設定の問題かもしれず、不要の可能性もあるが未検証。現時点では実害はないはずなので、そのまま。
[TLS_proxy_listener]のセクションは、shurikenからの接続を受けるためのもの。9025ポートでlistenして、2525ポートにforwardしている。 このポート番号は[TLS_proxy_connector]セクションのAcceptで受けているポートと合わせる必要がある。
証明書ファイル類は、letsenvryptでwebサーバ用に作成したものを指定した。 なので本当のファイル名はちょっと違し、メールサーバらしからぬFQDN。
また、firewallで不要なポートは閉じていたので、/usr/lib/firewalld/serviceに、9025ポートのservice定義を書いてfirewall-cmdでポートを開けた。

これで、shurikenのアカウント登録設定の「送信(SMTP)サーバの名前」にstunnelが動作しているサーバ名(SSL証明書と一致するもの)、「送信サーバのポート番号」に9025を指定し、「SSLを使用」を「する」に、「STARTTLSを使用」を「しない」にすることで、メール送信が可能になった。

ここを参考に、/etc/cron.daily/clamdscanを修正。

--- /etc/cron.daily/clamdscan.orig 2023-08-15 09:15:11.496374765 +0900 +++ /etc/cron.daily/clamdscan 2023-08-15 09:05:23.429737649 +0900 @@ -5,7 +5,7 @@ CLAMSCANLOG=`mktemp` QUARANTINEDIR=/tmp/clamdscan-quarantine-$(date +%Y%m%d) mkdir -p ${QUARANTINEDIR} -clamdscan -c ${CONFIG} --move=${QUARANTINEDIR} / > ${CLAMSCANLOG} 2>&1 +clamdscan -c ${CONFIG} --move=${QUARANTINEDIR} -fdpass / > ${CLAMSCANLOG} 2>&1 # ウイルス検知時、root宛にメール通知 if [ -z "$(grep FOUND$ ${CLAMSCANLOG})" ]; then

追加したのは、fdpathオプション。このオプションは、manによると、

--fdpass ファイルディスクリプタの権限をclamdに渡します。 これは、clamdが異なるユーザーとして実行されている場合に役立ちます。 ファイルをclamdにストリーミングするよりも高速です。local(unix)ソケット経由でclamdに接続されている場合にのみ使用可能です。

元ネタは英文だったので、ChatGPTに翻訳してもらった。