ホーム » T-Saitoh
「T-Saitoh」カテゴリーアーカイブ
EPG番組表ふたたび
以前運用(EPG番組表とリモコンの連動)していた自宅でよく見るチャンネルを優先する EPG 番組表だけど、番組表が Cable Gate に変わって、番組表情報が取得できなくなっていた。今回、agy (Gemini) にて「このプログラムを参考にEPG情報をとれるように直して」と命令したら、スクレイピングしていたプログラムを、内部で json 形式で読みだす API を見つけてくれたようで、無事元通り。
番組名をクリックすれば、チャンネル変更もできる機能も元通り。
P2P地震情報 API
出張中に地震もあったりで、P2P地震情報 API の通知を使えないかと考えてみた。
緊急地震速報が出たときに、Raspberry Pi の cec-client で TV などを点けるなど処理をさせたいな。
ということで、Gemini でプログラムのひな形を作らせてみた。Systemd で起動するようにちょい修正だな。
import asyncio
import json
import websockets
# あなたが住んでいる、または通知を受け取りたい地域(例:東京都)
MY_PREF = "東京都"
MY_CITIES = ["千代田区", "新宿区"] # 必要に応じて市区町村まで絞る場合
async def listen_eew():
uri = "wss://api.p2pquake.net/v2/ws"
async with websockets.connect(uri) as websocket:
print("地震情報の受信を待機中...")
async for message in websocket:
data = json.loads(message)
# --- パターンA: 震度情報(code: 551 など)の場合 ---
if data.get("code") == 551:
# 各地の震度データから自分の地域を探す
for pref_data in data.get("pref", []):
if pref_data.get("name") == MY_PREF:
max_scale = pref_data.get("maxScale")
print(f"【地元で地震を検知】{MY_PREF} 予想/観測震度: {max_scale}")
# TODO: 通知処理をここに書く
# --- パターンB: 緊急地震速報(code: 554 / 556 など)の場合 ---
elif data.get("code") in [554, 556]:
# 警報・予報の対象地域に自分の地域が含まれているかチェック
# (※実際のJSON構造に合わせたキー指定が必要です)
areas = data.get("areas", [])
for area in areas:
if MY_PREF in area.get("pref", ""):
print(f"【緊急地震速報】お住まいの地域が含まれています: {area}")
# TODO: 強い揺れへの警戒・音声アラートなど
asyncio.run(listen_eew())
pnrcon.net からメール送信?
DMARC を運用しているけど、自宅ドメインを語ったメールが送信されたとの報告。ちょっと不気味だな。
1件だけなので、偽装送信に悪用可能なドメイン名なのかを確認するために使われたのだろうか。
事前偵察(プロビング)というらしいが、確実に reject しているので、悪用できないドメインとして記録された…ということで、現状では見守るしかないかな。
dmarc-cat 0.15.0,parallel/j4 by Ollivier Robert Reporting by: google.com — noreply-dmarc-support@google.com From 2026-10-28 09:00:00 +0900 JST to 2026-10-29 08:59:59 +0900 JST Domain: tsaitoh.net Policy: p=reject; dkim=r; spf=r Reports(1): IP Count From RFrom RDKIM RSPF 149-137-190-134.dynamic.pnrcon.net. 1 tsaitoh.net tsaitoh.net fail fail
switchbot の munin プラグインを multigraph 化
自宅内を switchbot で色々と管理できるようになったけど、温湿度測定の対象も増えてきたら、munin のデータ更新の時間がどんどんと長くなってきた。
gemini に手伝ってもらい、パケット流量の監視などでセッションを残すことなどで、早くなってきたけど、もう少し改善したい。確認を行うと、Switchbot の温湿度測定をセンサー毎に lua プログラムで実行しているのに時間がかかり、複数センサーを一括で取り込むことを勧められる。
そこで、tokenやらアクセス用のタイムスタンプ情報などを作る部分を最初に1度行って、データ取得は一括で取り込むことにした。このような処理のために、munin では multigraph という機能があるので、プラグインを multigraph 化してみた。11秒ほどかかっている munin-update が 8秒ほどに短縮できた。
php2shell の対応
PHPの更新が前日に予告され、一斉更新がかかるという流れは、かなり重大。
ということで、いつもなら職場にいってから対応なんだろうけど、高市さんの危険勧告のニュースを見ながら、職場や自宅のサーバの更新をかけた。ひとまず、debian, ubuntu の更新情報で対応版のバージョンなのを確認でひとまず安心かな。

(追記) 公開前後への攻撃の可能性もあるので、https://x.com/okdt/status/2113066222870999515 の記事を参考に、error.log や access.log を確認。特に問題となる攻撃の痕跡は見つからなかった。
Ubuntu 26.10 への更新(mariadbトラブル)
Ubuntu 26.10 の公開に合わせて、自宅サーバの do-release-upgrade -d を実行してみた。
約3000パッケージほどが更新されたが、upgrade 時点では大きなトラブルなく終了&再起動。
mariadb の修復
しかしながら、再起動後に wordpress が定番の”データベース接続確立エラー”で動かない。Apache,PHPなどは普通に動いているようなので、困った。
トラブルが次々発生したけど…
- 更新作業中に既存の設定ファイルを残す方針で更新をしたため、mysqlからmariadbの移行が中途半端だったので /run/mysql を参照する設定になっていた。パッケージの設定ファイルを更新パッケージ付属の mariadb の純正の設定ファイルに変更し、mariadb がひとまず起動。
- しかしながら event や proc などのファイルが壊れていたり整合性のエラーで正常起動状態にならず、Gemini に聞きながら、壊れている関連ファイルを削除し、mariadb の再起動で関連ファイルを修復し、ようやく mariadb が正常起動。
- でも、接続確立エラーがでたけど、最後に wordpress の DB_HOST の設定が localhost になっていたものを 127.0.0.1 に変更したら wordpress が正しく動くようになった。
確認作業
その他の機能は、nagios4 とかで確認すると、正常に動いているように思える。メールの送受信あたりがややこしいけど、Gmail 間で送受信ができたので大丈夫かな。
更新時に、dmarc-cat や nodejs などの PPA の設定で入れたものが動かなくなるかも… との警告が出てたけど、更新後にパッケージなどで残っているので、ひとまず大丈夫っぽい。
我が家で大活躍している、HomeAssistant も正常に動いている…たぶん…これからの運用でトラブルが見えてくるかもしれないけど、26.10 を危険覚悟で入れたのだから仕方がないだろうな。
PPAパッケージの復活
do-release-upgrade の際に無効化されていた、/etc/apt/sources.list.d/ 配下の PPA パッケージは、更新時に “Enabled: no” にされていたけど、改めて “Enabled: yes” に変更し更新の有無を確認。
WSL で 26.10
WSL環境も、先日 docker なども容易になった wsl-3.0.3 が出てきてるけど、Ubuntu 24.04 から 26.04 に更新した環境で 26.10 に更新。
蝗はイナゴ?バッタ?
薬屋のひとりごとの3期で蝗害がネタになってるけど、ストーリーの雰囲気からするとイナゴのかわりにバッタが増えると蝗害が発生するような関係のように思っていた。でも漢字変換するとイナゴ=蝗で、蝗害はイナゴの害?でなんかストーリーに合ってない。
んで、Wikipedia 蝗害をみてみた。なるほど中国では「蝗=バッタやイナゴ」。んで日本ではイナゴの大量発生のような蝗害は発生しないし、「蝗=イナゴ」と読んでいる。
んで、中国での蝗害は、バッタが単独で生活する「孤独相」の状態と、群生して移動する「群生相」があり、「孤独相が群生相に変異」すると蝗害となるらしい。つまりどっちもバッタ。イナゴ類が減ってバッタ目が増える訳ではない。「イナゴは相変異しない。(株エコリスより引用)」」 薬屋のひとりごとは、ストーリーの分かり易さを優先し「孤独相=イナゴ」、「群生相=バッタ」と表現しているようだ。

外部からの到達確認
外部からの HTTPS トラブルもあり、nagios に外部から自宅サーバへの到達性チェックを追加。
自宅から nrpe で監視している さくらインターネット 上のサーバに以下の設定を追加。
((( 外部サーバ: /etc/nagios/nrpe.d/enabled.cfg )))
# -s 文字が含まれるかチェック(DDNS環境なので文字検索チェック付き)
command[check_tsaitohnet_http]=/usr/lib/nagios/plugins/check_http tsaitoh.net -s tsaitoh.net
command[check_tsaitohnet_https]=/usr/lib/nagios/plugins/check_http --ssl tsaitoh.net -s tsaitoh.net
((( 自宅 )))
define service{
use local-service ; Name of host template to use
host_name .....
service_description TSAITOH_HTTP
check_command check_nrpe!check_tsaitohnet_http
check_interval 1440 ; 1day 確認頻度は低く
retry_interval 60 ; 1h
notification_interval 0 ;
}
# HTTPSチェックは、HTTPSトラブルが解消してから
https 接続トラブルの対応 (解決)
自宅の D-ONU の交換に伴い、https 通信が繋がらなくなった。色々動かない状況から原因を推理していたが、最終的には DMZ と ポートフォワードの組み合わせが原因だったという結論。
自分なりの原因分析 (失敗のまとめ)
丹南ケーブルの光ルータ(GPON G240)の故障に伴い、光ルータ(GPON G2425)に交換となったが、この影響で https がインターネット側から自宅サーバの接続ができなくなった。色々確認する中で、当初は GPON G2425 の外部メンテナンス用の TR069 関連のトラブルを予想していたが、丹南ケーブル側のルータのWAN側メンテナンスポートの問題の可能性があると考察中。(業者の方と情報交換用にメモ)
- 丹南ケーブルでは、D-ONU とインターネット間に何らかのルータ(たぶんFortiGuard)がある。
- FortiGuard Web Filter (記事A)
- https 通信が接続できないトラブルが光ルータの交換でつながったことがある。
- 丹南CATVの光ルータ交換 (記事B)
この点を考えると、今回の原因は、記事A のように GPON G2425 の上にある上流ルータ(たぶんFortiGuard系) で、WAN側のメンテナンス https ポートが開いていて、インターネット側からアクセスすると、Fortigate ? につながろうとする。ただし Fortigate でアクセス可能IPアドレス設定で特定アドレスからしか受け付けないように設定してあるため、Connection Refused になる…. と想定している。記事B の光ルータ交換でつながるようになったのは、収納されているセグメントが変わり、ルータのWAN側メンテナンスhttpsポートが消されているセグメントに移ったためと推定している。
技術さんの訪問確認
丹南ケーブルさんの訪問を受け、現状の確認作業を行い、上記推定の理由の情報交換を行った。
確認ポイント
- 接続までの経路確認
- G2425 は、DMZ 設定で 自宅内ルータ(AirStation)に接続
- 自宅内ルータ(AirStation)は、DMZ設定は使わず、静的ポート変換で(22,25,53,80,123,443,993,465)を、自宅内サーバに流れる。
- 動作検証用に G2425 に 8443 を 自宅内ルータ(AirStation) の 443 にポートフォワードをかけてある。
- 丹南ケーブルの外から、以下を確認
- telnet … 80 で自宅サーバページにアクセス可能。w3m http://tsaitoh.net/ で自宅ページを表示可能。
- telnet … 443 Connection Refused
- telnet … 8443 自宅サーバにアクセス可能。telnet の接続なので 400 エラーが表示されるが、サーバ側がApache2.4.66 / Ubuntu と表示されるので、自宅以外の物につながっている訳ではない。
この結果から、(a) G2425 で 443 が使われている、or (b) G2425 のインターネット側上流ルータが 443 を使っている。この確認としては、丹南ケーブルの内部から telnet … 443 を実行してもらい、つながれば(b)、つながらなければ(a) と原因切り分けが可能なはず。
https 接続は異常なマニアの要求?
https で自宅Webサーバの公開ができない…というクレームは、逸般家庭(異常なマニア)の要求であり、https 接続は諦めて…という論調にならないか心配していた。でも、技術の方との話だと「最近は自宅 IP カメラに https 接続というのはよくある話なので、https はつながる設定は普通」とのお話で、原因究明をちゃんとしてくれそうで良かった。
んで、設定確認で LAN ケーブル抜き差ししてたら、古いケーブルの抜け止めのノッチが折れた。いい機会だし LAN ケーブル買い出しかな。
追記 HTTPS 問題解決 (DMZなし+ポートフォワード)
HTTPS が繋がらないトラブルを改めて見直してみた。
上記の接続で失敗したのは、DMZ を基本として、繋がらない HTTPS だけポートフォワード転送の設定であった。
- (失敗A) – DMZ 転送 – [443 は繋がらない]
- (失敗B) – DMZ 転送 + 443 ポートフォワード – [443 は繋がらない]
ここで、こういった複合設定の相性問題の時は、地道な設定変更が必要。ということで色々組み合わせて実験した結果…
- (成功C) – DMZ 転送なし + 443 ポートフォワード
であればつながることが確認できた。DMZ とポートフォワードの組み合わせが原因だろうか?
原因のまとめ
- G2425のDMZ機能は、HTTPS を正しく通すことができない。
- G2425はDMZ機能とポートフォワードの両方を設定できない。
Gemini でDMZとポートフォワードの処理順序を問い合わせると『一部の特殊な海外製ルータやファームウェアによっては同時に設定すると競合を起こしたり、挙動が変化する場合があります。』だそうな。
ということで、自宅サーバで動かしているプロトコルをポートフォワードで一つ一つ全て記載した。
(2段目のバッファロールータのポートフォワードをコピーし、これに加え ルータ VPN の L2TP/IPsec のポート転送を追記)
| WAN接続 | WAN | LAN | 端末名 | 端末 | protocol | 概要 |
| 1_INTERNET_R_VID_881 | 53~53 | 53~53 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP/UDP | DNS |
| 1_INTERNET_R_VID_881 | 80~80 | 80~80 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP/UDP | HTTP |
| 1_INTERNET_R_VID_881 | 443~443 | 443~443 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP/UDP | HTTPS |
| 1_INTERNET_R_VID_881 | 123~123 | 123~123 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP/UDP | NTP |
| 1_INTERNET_R_VID_881 | 22~22 | 22~22 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP | SSH |
| 1_INTERNET_R_VID_881 | 993~993 | 993~993 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP/UDP | IMAPS |
| 1_INTERNET_R_VID_881 | 25~25 | 25~25 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP | SMTP |
| 1_INTERNET_R_VID_881 | 465~465 | 465~465 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP | SSMTP |
| 1_INTERNET_R_VID_881 | 587~587 | 587~587 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP | SSMTP(Submission) |
| 1_INTERNET_R_VID_881 | 500~500 | 500~500 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | UDP | L2TP/IPsec(IKE) |
| 1_INTERNET_R_VID_881 | 4500~4500 | 4500~4500 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | UDP | L2TP/IPsec(NAT-T) |
| 1_INTERNET_R_VID_881 | 1701~1701 | 1701~1701 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | UDP | L2TP/IPsec |
ということで、丹南ケーブルさんにメールに、情報共有しておいた。
gpon G2425 のパケット流量プラグイン
ケーブルテレビの光ルータが入れ替えとなったが、パケット流量を観測していた munin のプラグインが動かなくなる。
Nodejs で実装(Gemini作)
更新前の Nokia G-240 の時には、自分でスクレイピングしてスクリプトを作ったけど、新しい Nokia G-2425 は、セキュリティ対策から色々と事前設定が面倒になってる。そこで、Gemini に「ルータが 192.168.xx.xx にある userid=…. , password=…. の Nokia G2425 の光ルータの munin 用プラグインを作って」と命令したら、作ってくれた。(別日に作らせようとしたら無課金枠を使い切って失敗)
ただ、nodejs なので、処理負荷が高いなぁ…
Lua で実装(Gemini作)
nodejs では、処理負荷が高いので、「 ./gpon.js を Lua で実装して 」と命令してみた。結果として system 時間は減少させることができたけど、若干 lua の方が遅くなった。たぶん、データ取得時に logout 処理が実行されていないため、次回処理でセッション切れの処理がはいっていることも想定できたので、「 処理時間が遅いので logout 処理を追加して 」と命令してみた。(ただし、プログラムの行数は 1.5倍になった)
$ time ./gpon.js ./gpon.js 0.23s user 0.04s system 4% cpu 5.996 total $ time ./gpon.lua (logoutの改良前) ./gpon.lua 0.02s user 0.02s system 0% cpu 6.123 total $ time ./gpon.lua (logoutの処理の改良後) ./gpon.lua 0.02s user 0.02s system 0% cpu 4.551 total



