「Ubuntu」カテゴリーアーカイブ

システム

最近の投稿

アーカイブ

カテゴリー

CVE-2026-98432 の暫定対策で MPTCP 無効化

p2pshell の脆弱性の問題が騒がれている中、CVE-2026-98432 の問題が score 9.8 で報告されてきた。

セキュリティが騒がれているし、対策を探すけど ubuntu 26.10 ではまだ対応カーネルが出てこない。対策をしらべると、MPTCP (Multipath TCP – 複数の TCP 通信を束ねた通信) のトラブルなので、MPTCP を無効化すれば暫定対策になるとな。

MPTCP の機能は ON になっているものの、MPTCPの機能は使っていないので、問題ないだろう。sysctl -w の設定は、再起動時には元に戻るので、MPTCP 対応のカーネルが配布されて再起動すればいい。

$ sudo sysctl -w net.mptcp.enabled=0

EPG番組表ふたたび

EPGデータの取得処理

以前運用(EPG番組表とリモコンの連動)していた自宅でよく見るチャンネルを優先する EPG 番組表だけど、番組表が Cable Gate に変わって、番組表情報が取得できなくなっていた。今回、agy (Gemini) にて「このプログラムを参考にEPG情報をとれるように直して」と命令したら、スクレイピングしていたプログラムを、内部で json 形式で読みだす API を見つけてくれたようで、無事元通り。

番組名をクリックすれば、チャンネル変更もできる機能も元通り。

追記 loading 表示

EPG の取得には時間がかかるため、loading… の表示をするように処理中に ob_flush() など埋め込んでいた。しかしながら、今回の修正で機能が復活したけど loading… の表示が正しく動いていなかった。HTTP2の機能を導入する過程で、出力データはバッファリングして一括送付するようになり、PHP の出力バッファリングで、ob_flush() などの効果がなくなっていた。

そこで、以下のような処理を PHP の先頭に埋め込んで、出力バッファリングを抑止して、loading 表示機能も復活。

// EPG取得に時間がかかるのでloading表示したい。
// このため出力バッファリングをさせない
if ( true ) {
    // 1. PHPの出力バッファリングをクリア
    while( ob_get_level() > 0 )
        ob_end_flush() ;
    // 2. mod_deflate による圧縮を回避
    if ( function_exists( 'apache_setenv' ) )
        apache_setenv( 'no-gzip' , '1' ) ;
    // 3. PHP の zlib 圧縮をオフ
    ini_set( 'zlib.output_compression' , 'Off' ) ;
    // Nginx でのみ有効
    header( "X-Accel-Buffering: no" ) ;
    // 4. キャッシュや圧縮をさせないヘッダ
    header( 'Content-Encoding: identify' ) ;
    header( 'Cache-Control: no-cache, no-store, must-revalidate' ) ;
}

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())

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 に更新。

タグ,カテゴリに noindex を追加

情報探しで、自分のページが google 検索で表示されることがあるけど、記載ページ以外にタグ・ページやカテゴリ・ページが重複して表示されることがある。

タグ,カテゴリに noindex

無駄な情報が表示されないように、noindex, follow(記事を検索結果に表示させないけど、続けて検索を許す) のタグを入れる処理を追加する。(といっても gemini のアドバイスをまとめただけだけど)

WordPress 管理画面で functions.php を編集

  • WordPress 管理画面の [外観] > [テーマファイルエディター]
  • 「テーマファイル」一覧から [テーマのための関数 (functions.php)]
/////////////////////
/// functions.php /// 
/////////////////////
/**
 * カテゴリ,タグ等 に noindex を追加
 */
if (!function_exists('add_custom_noindex_tags')) {
    function add_custom_noindex_tags() {
        if ( is_tag() || is_search() || is_date()
             || is_404() || is_author() || is_category() ) {
            echo "\n".''."\n";
    	}
    }
    add_action( 'wp_head', 'add_custom_noindex_tags' );
}

WordPress プラグイン Postie のトラブル

WordPress も 8月に 7.1 系にアップグレードされたけど、この1年ほどは大きなトラブルもなく更新がでたらポチるだけの安定運用。

Postie のトラブルと更新

ただ、今日は Postie の更新が来ていたので更新をかけたら、起動しなくなった。安定実績のあるプラグインが動かなくなるのは久々だな。

ひとまずは、plugins ディレクトリに入って mv postie postie.disabled で一旦無効化させる。

確認すると、この数日で 1.9.82,83,84,85,86 と微妙に更新がかかっているなか、「注意: このプラグインは現在使用中の WordPress バージョンではテストされていません。」となっている。変な動き…ではなく、WordPress の起動さえ邪魔するようなトラブルは珍しい。

WordPress 本体の更新を確認すると、WordPress 7.1.1 が 9/17, 7.1.2 が 9/22 に自動更新かかっているなぁ。

(2026/09/24 追記)

新しく更新が出たようなので、元に戻して更新で無事復帰。

同様のトラブルが職場の WordPress でも発生。休み明け早々の朝イチ仕事で対応(済)

(2026/09/24 追記2) WordPress 7.1.2 で深刻な脆弱性の修正

WordPress 7.1.2が公開。深刻な脆弱性を修正、サイト運営者は速やかな更新を

HomeAssassinにHomeKit Bridgeを登録

iOS27 で Siri AI が強化され、改めて iPhone のホームアプリを使いたくなってきた。

以前は、HomeBridge を使っていたけど、連携などの問題で HomeAssassin に移行したうえで、HomeBridge はお役御免としていた。となると、HomeAssassin で連携させたい。Gemini で聞いてみたら連携機能があるな。

HomeKit Bridgeのインストール

『設定 – 統合を追加 – Apple – HomeKit Bridge 』にて、iPhone ホームアプリ用の QR コードを生成させ、iPhone で読み込ませたら、連携ができた。(統合追加で “Apple – HomeKit デバイス” との勘違いに注意)

動作テスト (9/23追記)

iPhone(iOS27.2β1) の Siri に「リビングの照明を消して」としたら、ちゃんと消してくれた。でも、Apple Watch だと「リビングルームには電力を制御できる照明はありません」と言われる。微妙だな。

次に、複合技の実験で iPhoneで「リビングの照明を1分後に消して」としたら、「ホームハブの設定が必要」とのエラーメッセージ。この機能は、Google の Gemini for Home だと、一応動いてくれる。でも、設定に失敗したりすることもある多い微妙な機能だし、Siri だと動くかなと期待したけど残念。

Screenshot

readynas の運用開始と DNS,DHCPの多重運用

NETGEAR の ReadyNAS Pro 2 を入手。readynas の 正規 OS は、バージョンが古く debian ベースの でも samba などが古いプロトコルしか使えないので、便利な使い方ができない。

このため、Serial ポートを使って debian/forky をインストール。

サーバを運用していると、ネットワークの設定を間違って DNS, DHCP を止めてしまうと、自宅ネットワークが全滅する。 Raspberry-Pi で DNS セカンダリサーバなどを動かしていたけど、この readynas のサーバで多重サーバ構成にしたい。

DNS のキャッシュサーバ運用

まずは、DNS (bind9)のセカンダリ運用。

((( /etc/bind/named.conf.local )))
zone "tsaitoh.net" {
        type slave ;
        file    "db.tsaitoh.net.slave";
        masters {
                192.168.xx.yy;
        };
};
((( /etc/bind/named.conf.options )))
acl     internal-network {
        ::1;
        127.0.0.1;
        192.168.xx.0/24;
};
options {
        directory "/var/cache/bind";
        forwarders      { 192.168.xx.yy;    };
        allow-query     { internal-network; };
        allow-recursion { internal-network; };
        dnssec-validation auto;
        listen-on       { any; };
        allow-transfer  { none; };
};

DHCP のホットスタンバイ運用

続いて、DHCP の多重化。最近まで isc-dhcp-server を使っていたけど、kea-dhcp4-server に切り替えていたが、kea-dhcp4-server では、hot-standby 構成を組めるので、設定。2台の DHCP サーバは、8000 ポートで相互に死活状態を確認し、相手が機能していないと、自身が DHCP 処理を行う。

((( /etc/kea/kea-dhcp4.conf )))
    "hooks-libraries": [
      {
          "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
          "parameters": { }
      },
      {
          "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
          "parameters": {
              "high-availability": [ {
                  "this-server-name": "プライマリホスト名",  // セカンダリの設定ではセカンダリホスト名を記入
                  "mode": "hot-standby",
                  "heartbeat-delay": 1000,
                  "max-response-delay": 10000,
                  "max-unacked-clientsets": 5,
                  "peers": [
                      {
                          "name": "プライマリホスト名",
                          "url": "http://192.168.xx.yy:8000",
                          "role": "primary"
                      },
                      {
                          "name": "セカンダリホスト名",
                          "url": "http://192.168.xx.zz:8000",
                          "role": "standby"
                      }
                  ]
              } ]
          }
      },
    ],

これで、メインサーバにトラブルがあっても、自宅内ネットワーク全滅は避けられる。

Google 検索

My Google   Yahoo

Microsoft

ファンサイト

メタ情報