ホーム » コンピュータ (ページ 4)
「コンピュータ」カテゴリーアーカイブ
homebridgeをSSL化のトラブル
homebridge-config-ui-x の更新をかけたときに homebridge が動かなくなった。
https://….:8581 で起動していたけどページが表示できず、http://…:8581 ならページが見れる。
以前、homebridgeのSSL化を行っていたけど、Let’s encrypt の SSL の更新が行われていて、homebridge の再起動時に SSL の鍵が読めなくなったのが原因。ということで、Let’s encrypt の更新スクリプトに、以下の処理を追加
# homebridge に SSLキーのアクセス権を与え、再起動 /usr/bin/setfacl -m u:homebridge:r 証明書へのPATH/fullchain.pem /usr/bin/setfacl -m u:homebridge:r 証明書へのPATH/privkey.pem /usr/bin/hb-service restart # homeassistant の再起動 /usr/bin/docker restart homeassistant > /dev/null
openDMARCの設定
gemini cli で設定確認
最近の自宅サーバでの暇つぶしは、gemini-cli を使って設定の見直し。
gemini が確認する際には、sudo 付きで systemctl restart やら LOGファイルにエラーが記録されていないか見たうえで、次々と問題点の提案&改善&実行してくれる。
openDMARCが動かなかった原因
んで、自サバで動かしているメールサーバで、メール受信時の確認として、openDMARC を導入しようとしてたけど、うまくいってなかった。そこで、「”/etc/postfix”を確認して、”/etc/opendmarc.conf”を確認して」を連発してみた。
openDMARC については、opendmarc のグループに postfix ユーザが含まれていなかったのが原因。
これで、受信メールの正当性チェックで spam が減らせるかな。
Switchbot 学習リモコンがリセットできない
買った割にあまり活用できていない学習リモコンだけど、Hub mini 側での再学習があったので同期をとろうとするが失敗。
リセットできない
しかたがないので、スマホのアプリ側から一旦削除して再接続させようとリセットピンでのリセットを試みたけど、リセットされず、ONボタン長押しによるスマホアプリとの連携ができない。ファームウェア修復(中央の赤ボタン/kataボタンを押しながらのピンリセット)を試みるけど、赤い壊れたアイコン画面がでて、ファームウェアリセットが始まらない。
うーむ、色々試したけど、うまくいかないのでサポートにメッセージを入れた。前回は対応丁寧だったし。
サポートの説明手順でファームウェア修復
ファームウェア修復だけど、kata+ピンリセットで学習リモコンの画面にファーム修復の画面が出てくると思っていたけど、SwitchBotアプリ側に出てくる…という勘違いポイントが判明。
- SwitchBotアプリ⇒プロフィール⇒ファームウェア修復
- その後、学習リモコン側でKataボタン+ピンリセット
- SwitchBotアプリに、「ファームウェア修復」が表示されるので修復を開始

修復にはかなり時間がかかった。
んで、SwitchBotアプリと接続させたら、早々にファームウェアV4.6への更新がかかった。修復は10分ほどかかったけど、更新は1分ほどだな。更新前のファームは、V2.4?で大幅な更新だった。動かなくなったのはこれが原因だったのかも。
homeassistant を watchtower で更新
先日 DHCP の設定で、Docker 環境が DHCPREQUEST を出しているかもとの勘違いで、HomeAssistant をアンインストールしていたけど、改めて HomeAssistant を運用再開。
HomeAssistant の運用再開(HTTPSに変更)
HomeAssistant のイメージダウンロードして、設定を最初から…と思ったけど、前回インストールしてあったものが残ってて、一発で環境が復活。
でも、homeassistant の更新方法を確認すると、docker image をダウンロード, stop, remove ,新しいイメージを run させるとかの手順が出てきて面倒。Gemini に聞いたら、Watchtower を勧めてくれた。
また、HomeAssistant を https で起動するように設定を見直す。
$ sudo docker stop homeassistant
$ sudo docker rm homeassistant
$ sudo docker run -d \
--name homeassistant \
--privileged \
--restart=unless-stopped \
-v /var/lib/homeassistant:/config \
-v 証明書へのPATH:/certs:ro \
--network=host \
ghcr.io/home-assistant/home-assistant:stable
$ sudo /var/lib/homeassistant/configuration.yaml # 以下を追記
http:
ssl_certificate: /certs/fullchain.pem
ssl_key: /certs/privkey.pem
$ sudo docker restart homeassistant
Watchtower で HomeAssistant の更新
HomeAssistant を自動更新させる Watchtower をインストールする手順は、Gemini に出てきた設定方法をそのまま実行。
$ sudo docker run -d \ --name watchtower \ --restart=unless-stopped \ -v /var/run/docker.sock:/var/run/docker.sock \ containrrr/watchtower --interval 86400 homeassistant $ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e94a5eea7468 containrrr/watchtower "/watchtower --inter…" 4 seconds ago Up 1 second (health: starting) 8080/tcp watchtower 94c7a25097d4 ghcr.io/home-assistant/home-assistant:stable "/init" 6 minutes ago Up 6 minutes homeassistant
でも、現状のバージョンが 2025.9 だったので、最新の 2025.12 に早々に上げたいので、確認したら、以下のように、 –run-once を指定して実行すればいいらしい。
$ sudo docker run --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
containrrr/watchtower \
--run-once \
homeassistant
エラーが出たので、Gemini の協力もあり、バージョン指定で更新。
$ sudo docker run --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
-e DOCKER_API_VERSION=1.44 \
containrrr/watchtower \
--run-once \
homeassistant
無事に、2025.12.5 に更新ができた。
んん? –run-once で更新ができるのなら、watchtower を起動させっぱなしなのは、プロセス資源がもったいない。/etc/cron.monthly で “docker run … watchtower –run-once …” を実行した方がいいじゃん。docker stop/rm watchtower して cron 管理に移行させた。
Docker管理の Portainer のインストール
Docker 絡みで Gemini にお勧めを聞いたら、Docker を Web の GUI で管理ができる Portainer をすすめられた。
ということで、おすすめ設定を実行。
https 通信を使うので、オレオレ証明書のエラー画面で継続をすると、自宅サーバのアクセスで信用できない通信が表示されるようになる。そこで自宅サーバの証明書を使うように設定を追加。(Gemini に聞くと証明書の設定方法を提案してくれる。便利。)
((( 設定データ保存用のボリューム作成 )))
$ sudo docker volume create portainer_data
((( Portainer コンテナの起動 )))
$ sudo docker run -d \
-p 8000:8000 \ # Edge Agent通信用の HTTPポートの割り当て
-p 9443:9443 \ # HTTPSポートの割り当て
--name portainer \
--restart=always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v portainer_data:/data \
-v 証明書へのPATH:/certs \
portainer/portainer-ce:latest \
--sslcert /certs/fullchain.pem \
--sslkey /certs/privkey.pem
Homebridge を https に変更
Dockerの https の設定がうまくできたし、Homebridge も https で使えないか確認。ただし、homebridge は user=homebridge で起動しているので、アクセス権を与えないと、秘密鍵が読めない。かといって 証明書のアクセス権をユルユルにするのも避けたいので、Geminiに設定を提案してもらうと ACL でアクセス権を与える方法を示してくれた。(Linux での ACL の使い方、参考になる。Geminiに感謝。)
((( ACL で 読み込み権限を与える )))
$ sudo setfacl -m u:homebridge:r 証明書へのPATH/fullchain.pem
$ sudo setfacl -m u:homebridge:r 証明書へのPATH/privkey.pem
((( /var/lib/homebridge/config.json )))
"platforms": [
{ "name": "Config",
"port": 8581,
"lang": "ja",
"theme": "purple",
"menuMode": "default",
"lightingMode": "light", "sessionTimeout": 100000,
"platform": "config",
"ssl": {
"cert": "証明書へのPATH/fullchain.pem",
"key": "証明書へのPATH/privkey.pem"
}
},
((( homebridge 再起動 )))
$ sudo systemctl restart homebridge
ということで、homebridge, HomeAssistant, DockerのPortainer などの Web サービスを https 化することができ、ブラウザの「保護されていない通信」の表示を消すことができた。
arpalertをarpwatchに変更
不審なネットワーク接続を見つけるために、arpalert を使っていたけど、新しい端末を登録するときに警告メールが飛んでこない。サーバを切り替え ubuntu に変更となって、何も考えずに arpalert をインストールしてあったけど、細かい点の動作確認をしていなかった。
調べると arpalert は最近メンテナンスされていないらしい。systemctl status arpalert すると、/etc/init.d/arpalert の sysv 形式で起動している。古い証拠なので切り替え。
最近は arpwatch を進められたので、arpwatch に切り替え。
arpwatch の設定
設定は、設定対象のインタフェース名(自宅の場合 enp2s0)をしらべ、以下で起動
$ sudo apt install arpwatch $ sudo vi /etc/arpwatch/enp2s0.iface IFACE_ARGS="-m root@tsaitoh.net" # 警告メールの送り先 PCAP_FILTER="net 192.168.11.0/24" # 監視対象を制限 $ sudo systemctl enable arpwatch@enp2s0 $ sudo systemctl start arpwatch@enp2s0 $ sudo apt remove arpalert
iOS26.2とIPアドレストラッキング
iOS26.2にして、自宅サーバ限定ページが見えない。確認すると「IPアドレスのトラッキング制限」が ON になってら。
マナーの悪いクローラーの拒否
自宅サーバの Web サーバの負荷が上がってる。
CTFで公開しているブルートフォース問題へのアクセスかと思ったけど、apache2のaccess.log をみると、207.241.225.60 のアドレスからページ全体をなめまわしている。whois を実行すると、アメリカの Internet Archive なる組織。
間髪を入れないでアクセスしてくるような、マナーの悪いクローラは拒否されても仕方ないよね。
ということで、個別の アクセス拒否リストに、以下を追加する。
207.241.225.0/24 # 2025-11-21 207.241.238.0/24 # 2025-11-21
Ubuntu 25.10 へのアップグレード
Ubuntu 25.10 も公開されたので、do-release-upgrade を実行。X.org が使えなくなり Wayland だけになるとのことであったが、ssh x-forward で使うのがほとんどだし影響も少ないだろうと更新を行ってみた。
dovecot が動かない
最初のトラブルは、dovecot 。設定ファイルの変更が原因。dovecot って、設定ファイルの基本的な書式で動かなくなることが多い。
メールボックスを Maildir 形式 に変更と、SSL の設定ファイルを変更
((( /etc/dovecot/conf.d/10-mail.conf )))
#mail_driver = mbox
#mail_home = /home/%{user|username}
#mail_path = %{home}/mail
#mail_inbox_path = /var/mail/%{user}
mail_driver = maildir
mail_path = ~/Maildir
## mail_inbox_path = ~/Maildir/.INBOX -- 設定ミス(自宅サーバでは.INBOXはナシ)
mail_inbox_path = ~/Maildir
((( /etc/dovecot/conf.d/10-ssl.conf )))
# Preferred permissions: root:root 0444
ssl_server_cert_file = /var/lib/dehydrated/certs/tsaitoh.net/fullchain.pem
# Preferred permissions: root:root 0400
ssl_server_key_file = /var/lib/dehydrated/certs/tsaitoh.net/privkey.pem
sudo-rs で CIDR記法が使えない
Ubuntu 25.10 での大きな特徴では、sudo が Rust で書かれた sudo-rs に移行したことらしい。んで、Host_Alias で の文法やセキュリティが厳格になったようだ。
Host_Alias LOCAL = 127.0.0.1 , 192.168.11.0/24
といった書き方で記載してあったが、コンマ空白区切りが、厳密にコンマか空白で区切るようになり ” , ” のような前後空白コンマなどがエラーになる。また、自宅内ネットワークからという意味で、CIDR 記法を使っていたが、Host_Alias では CIDR 記法が使えなくなった。自宅ネットワークなら OK といった雑な指定はセキュリティ的にまずいということらしく、CIDR 記法が使える部分に制限が加わった様子。今回は、localhost だけに変更しておいた。
LEDバッジが動かない(11/16追記)
自宅でスケジュール表示などに活用していた LED バッジが動かなくなった。
Perl で書いてあるし、今までの OS のアップグレードでは、ほぼ問題なく移行できていたのに…
Kernel が Linux 6.14.x から 6.17 に更新された影響かと思い grub メニューで 6.14 で起動したけど改善せず。Kernel が原因ではないのかな。
Raspberry-Pi で再起動後に vcgencmd のエラー
Debian/GNU/Linux bullseye で運用している Raspberry-Pi が 再起動後に vcgencmd がエラーをだす。通常 vcgencmd を実行するには、/dev/vcio のアクセスが root にしか許可されていない。そこで root 以外が使えるようにするには video グループで読み込みできるようにすればいいけど、再起動すると設定が消えてしまう。
このために udev のルールを作成して、起動時にアクセス権を変更させる。
$ sudo vi /etc/udev/rules.d/99-vcio.rules KERNEL=="vcio", GROUP="video", MODE="0660" $ sudo udevadm control --reload-rules # 新しいルールを読み込み $ sudo udevadm trigger # ルールを即時摘要


