thongor77/nmlinuxLinux向け統合ネットワークツールキット — Python 3 + PySide6
Linux と macOS 向けの統合ネットワークツールキット — 検査、接続、診断。
NMLinux は、29 のネットワークモジュールを 1 つのウィンドウにまとめた単一の統合 GUI です。インターフェース監視、Wi-Fi、DNS、SSH ターミナル、ファイアウォールビューア、トポロジマップ、traceroute など。Python と PySide6 (Qt 6) でゼロから構築され、8 つのインターフェース言語を備え、標準的なシステムツール以外の外部依存はありません。
[!NOTE] NMLinux は Linux のシステムデーモン
/usr/bin/NetworkManager(Red Hat/GNOME による NetworkManager) とは無関係です。 NMLinux は Python と PySide6 でゼロから構築された独立したプロジェクトです。
Claude Code (Anthropic) とその作者の貢献によって構築されました。
NMLinux は AI の支援 — 具体的には Claude Code — を用いて構築されており、そのことはこのリポジトリのどこにも隠されていません。今日のほとんどすべての真剣なソフトウェアプロジェクトは、公言しているかどうかにかかわらず、そのパイプラインのどこかで AI を使用しています。したがって「AI が関与したか」は興味深い問いではありません。興味深い問いはこれです。AI が何かを間違えたとき、それを見つけるものはあるのか?
私の言葉を信じるよりも自分で確認したいなら、それを担っているのはこれです:
pytest tests/ -v。純粋なロジックに加え、少数の実際の Qt ウィジェットテスト (メニュー、テーブル) があり、興味深い部分をモックでごまかしていません。docs/Decisions-Techniques.md — 自明ではないすべての技術的判断、却下された代替案、そして発見・修正されたバグ (AI が持ち込んだものを含む) と、その理由が書き留められています。docs/Architecture.md と docs/Carte-des-Modules.md — コードの実際の構造を、出荷されるものと同期させて維持しています。これらのどれも、AI が信頼できないから存在するわけではありません。手書きのコードを含め、何も検証するプロセスなしに出荷されるべきではないから存在します。評価すべきは、出力とそれがどのように検証されているかであり、書くのを手伝ったツールではありません。
それでもバグを見つけましたか? それは恥ずかしいことではなく、役に立ちます — issue を開いてください。
GitHub Discussions はオープンです — フィードバックの共有、アイデアの報告、質問、あるいはただ挨拶するだけでも。作者はインフラストラクチャと運用の分野で 30 年以上の経験を持ち、優れた、無料で、シンプルなソフトウェアが Linux にも存在すべきだと考えてこのツールを作りました。
Linux のスクリーンショットは v1.2.7 — macOS のスクリーンショットは v1.3.5 のものです。アプリは現在 29 のモジュールと 8 つのインターフェース言語 (FR/EN/ES/DE/IT/PT/JA/ZH) を備えています。
Linux (KDE)
| Dashboard | Topology |
|---|---|
 |  |
| Traceroute | Wi-Fi |
|---|---|
 |  |
macOS
| Dashboard | Traceroute |
|---|---|
 |  |
libpython3.14.so.1.0、Arch Linux 開発マシンの glibc 2.44 に対してビルド) が、AppImageHub カタログのテストマシン (Ubuntu 22.04、glibc 2.35) が持つよりも新しい glibc シンボルを依然として要求していたため、AppImage は起動直後にクラッシュし続けました。build-appimage.sh は PyInstaller バンドルをホスト上ではなく ubuntu:22.04 コンテナ内で (podman 経由で) ビルドするようになり、埋め込まれるすべてのバイナリが、AppImage がサポートする必要のある glibc バージョンに対して正確にリンクされるようになりました。build-appimage.sh は共有ライブラリ (libz.so.1、libstdc++.so.6、libX11.so.6、libfontconfig.so.1 など) を Arch Linux ビルドマシンの非常に新しい glibc からそのまま同梱していました。古いディストリビューションでは AppImage が起動直後にクラッシュし (GLIBC_ABI_DT_RELR' not found)、AppImageHub カタログの自動テストで検出されました。これらのライブラリはバンドルから除去され、AppImage はホストシステム自身のコピーにフォールバックするようになりました。これは AppImage の標準的なアプローチです。traceroute バイナリがインストールされていなくても、traceroute は常にホストシム経由で PATH 上で解決されていたため、ワーカーが tracepath にフォールバックすることはなく、トレースはホップもエラー表示もなく即座に終了していました。traceroute が解析可能な出力をまったく生成しない場合は常に tracepath にフォールバックするようになり、失敗の理由に関係なく動作します。DISPLAY/WAYLAND_DISPLAY が設定されている場合 (任意の GUI セッション)、ssh がクリーンな tty を持たないとき、パスワードプロンプトに埋め込みターミナルではなく $SSH_ASKPASS を試みることがあり、askpass ヘルパーがインストールされていないと認証が黙って失敗していました。SSH_ASKPASS_REQUIRE=never により、パスワードプロンプトは常にターミナル自体を経由するよう強制されるようになりました。flatpak-spawn --host 経由で中継されたプロセスは、転送された pty の制御端末の所有者になることが決してできません (TIOCSCTTY が EPERM で拒否される — 別の無関係なセッションがすでに所有しているため。これはバグではなく、意図的なカーネルのセキュリティ境界です)。唯一機能する回避策 (script で新しい pty を割り当てる) はパスワードプロンプトを修正しますが、そのセッションのライブターミナルリサイズ伝播を壊してしまい、Flatpak をまったく出荷しないよりも悪いトレードオフと判断されました。今後、サポートされる Linux インストール経路は AUR と AppImage です。packaging/flatpak/ 配下のローカルビルドマニフェストは、KDE Linux およびその他の Flatpak 専用ディストリビューションを対象としています。nmlinux がシェルアウトするホスト CLI ツール (nmcli、pkexec、mount.cifs、ssh、nmap など) は、それぞれを個別にサンドボックス化するのではなく、PATH 上の flatpak-spawn --host シム経由でブリッジされます。PySide6 は PyPI ホイールではなく Flathub の io.qt.PySide.BaseApp から取得されます。Flathub には公開されておらず、代わりに単一の .flatpak バンドルが packaging/flatpak/build-bundle.sh でビルドされ、AppImage と同様に各リリースに添付されます。v1.7.12 で廃止 — 上記参照。Ctrl+Shift+C または右クリックメニューでコピー、Ctrl+Shift+V でペースト (既存)。以前はコピーが不可能でした — テキスト選択自体が存在しませんでしたiperf3 テストを、同梱の公開サーバーリスト (26 か国) または保存されたカスタムサーバー (例: 組織内サーバー) に対して実行します。TCP/UDP、IPv4/IPv6/自動、およびリバース (ダウンロード) 方向をサポートし、UDP テストではジッター/ロスが表示されます。issue #6 による提案iperf3 — LAN タブを有効にするにはインストールしてください。それ以外の場合、タブはバナーを表示して無効のままです