MeshMonitor: MeshtasticとMeshCoreを一つの監視画面へ

最初の画面までDockerで進む

MeshMonitorはオフグリッドのメッシュネットワークを単一ダッシュボードで監視するWebアプリです。READMEはMeshtastic、MeshCore、MQTTを対象にし、React、TypeScript、Node.jsで構成すると説明しています。データベースはSQLite、PostgreSQL、MySQLの選択肢があります。

Quick Startでは`ghcr.io/yeraze/meshmonitor:latest`を8080から3001へ公開し、`meshmonitor-data`を`/data`へマウントします。`MESHTASTIC_NODE_IP`は初回起動時の最初のソースを作る値です。起動後は`http://localhost:8080`を開き、初期認証`admin`と`changeme`を変更します。latestを固定版として扱うかは別に決めます。

採用前の記録ではyeraze-meshmonitor-deep-analysisのリリース、実行環境、入力、出力を固定します。画面やREADMEの印象ではなく、コマンドの終了コード、生成されたファイル、ネットワーク接続、エラー時の復帰を確認します。正常系だけでなく、設定値を欠かせた場合、権限を持たない場合、途中でプロセスを止めた場合も試します。観察結果は人が読めるメモと機械的なログの両方に残し、次の更新で同じ手順を再実行できる形にします。

導入を決める前に、yeraze-meshmonitor-deep-analysisが触れる範囲を一覧化します。読み取りだけか、ファイル変更や外部接続も行うかを分け、許可した範囲を越えた記録がないかを確認します。依存するランタイムと補助サービスの版を保存し、更新前後で差分を比較します。失敗したときに残るログの場所、利用者が元の状態へ戻す方法、削除や無効化の手順が説明できなければ、本番の対象には広げません。

この確認では、yeraze-meshmonitor-deep-analysisにない機能を推測で補いません。READMEに記載された入口から小さな入力を与え、期待する応答と実際の応答を比べます。未記載の挙動は未確認として残し、数値や互換性を一般化しません。

Helmで永続化と公開を組み立てる

Kubernetesでは、READMEの手順に従って`helm repo add meshmonitor https://meshmonitor.org/charts`、`helm repo update`を実行し、`meshmonitor/meshmonitor`をinstallします。valuesにはMeshtasticのIPとTLS利用の値を置きます。ローカルcheckoutから`./helm/meshmonitor`を指定する経路も記載されています。

Ingress、TLS、永続化、全valuesはHelm Chart READMEと公式のデプロイガイドへ分けて説明されています。クラスターへ適用する前に、生成されたDeployment、Service、volume、環境変数を確認し、公開ポートとデータの保存先が想定どおりかを見ます。READMEだけから可用性や復旧時間を推測しません。

ソースはDashboardから増やす

初回の`MESHTASTIC_NODE_IP`は最初のソースの種になるだけで、READMEは追加のソースをDashboardのSourcesから管理すると説明しています。TCPやHTTP経由の接続、Meshtastic、MeshCore、MQTTの構成を実環境に合わせて登録します。ノードが見えない場合、Web画面の状態だけでなくコンテナログと到達性を分けて調べます。

SQLiteから別のデータベースへ移す場合の具体的な移行手順や、各プロトコルの機能差は素材から確定できません。まず一つのノードと少量のデータで接続、再起動、切断後の再接続を試し、Dashboardの表示と保存データを照合してからソース数を増やします。

リバースプロキシを信頼する条件

Cloudflare Access、oauth2-proxy、Authelia、Traefik ForwardAuthなどのヘッダー認証に対応します。ただしREADMEの要件は厳格で、MeshMonitorを直接到達可能にせず、プロキシが認証を済ませ、`TRUST_PROXY`を適切に設定する必要があります。v4.13では既定値がfalseなので、プロキシ経由では`TRUST_PROXY=1`または環境に合うhop数・サブネットを明示します。

設定を誤るとクライアントIP、レート制限、監査ログがプロキシのIPとして記録されます。Cloudflare JWTのgroups claimはIdP設定により欠落したり`custom`配下になったりします。実際の`Cf-Access-Jwt-Assertion`をデコードしてclaim名と形を確認し、groupsがなければ`PROXY_AUTH_ADMIN_EMAILS`の許可リストを検討します。

自動プロビジョニングの落とし穴

`PROXY_AUTH_ENABLED`と`PROXY_AUTH_AUTO_PROVISION`、管理者グループやメール、一般ユーザーグループを環境変数で設定できます。groupsは配列、単一文字列、nameを持つrole objectを正規化し、照合は大文字小文字を区別しません。これは入力形式を吸収する処理であり、認証プロキシそのものの検証を代替しません。

READMEはデータベーススキーマでメールアドレスの一意性を強制していないと注意しています。同じメールを持つ複数ユーザーでは最初の一致が使われるため、プロキシ側で一意のアドレスを渡します。自動作成を有効にする前に、管理者でないユーザー、所属外グループ、重複メールの三ケースをテストします。

導入後に保存する観察結果

自宅や現場のメッシュを自分で監視したい運用者、既存の認証プロキシとコンテナ基盤を持つチームに適します。インターネットへ直接公開するだけの構成や、認証ヘッダーを検証できない環境には向きません。BSD-3-Clauseはコード利用の条件であり、ネットワーク構成の安全性を保証しません。

検証は固定したイメージまたはHelmチャートで行い、初期ログイン、ノード接続、`/data`の永続化、再起動後の復元を記録します。認証を有効にした後は、JWTのemail、aud、iss、groups、監査ログのIPを確認します。直接のコンテナポートを閉じた状態で正常利用できることが、採用判断の最初の条件です。

Dockerの検証では、`docker compose up -d`直後のログ、8080から3001への到達、`/data`のvolume、初回パスワード変更を記録します。Meshtasticノードを切断して再接続し、DashboardのSourcesと保存データが戻るかを見ます。プロキシ経由では直接ポートを閉じ、groups claimがないJWT、重複メール、管理者メールの三つを試します。

編集部の結論

MeshMonitorは、Meshtastic、MeshCore、MQTTのノードを自前のダッシュボードで見たい運用者向けです。プロキシ認証を使う場合は直接公開を避け、TRUST_PROXYとJWTのgroups claimを実トークンで確認し、初期adminパスワード変更とメール重複の扱いを検証してから運用してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes