サーバ連携：ロケーションとフリート

ここまでは目の前の Mac の話でした。本パートでは視野を一気に広げ、運用環境全体を扱います。ラック内の Linux、いまも macOS Server が動く旧来の Xserve、棚の Raspberry Pi、クラウド VPS、そして Windows ホストまで。それぞれを SSH で一度連携すれば、FrontierStack はそれらを単一のフリートとして扱います。診断を実行し、コマンドを一斉展開し、サイトをデプロイし、健全性を見守ります。さらに、この Mac がネットワーク上のどこにいるかも把握するので、自宅・オフィス・カフェを移動するノートでも、いま単に見えないだけのサーバについて誤報を出すことはありません。

本章では連携とフリートの運用を扱います。第 9 章はネットワークと境界を、第 10 章は堅牢化とセキュリティ監査を、第 11 章は継続的な監視とアラートを掘り下げます。AI 管理者は同じツール群でここのほとんどを操作できます（第 13 章）。

8.1ロケーションとプレイス

Locations & Places ▸ Locations を開きます。ロケーションとは、名前を付けたネットワーク（Home・Office・On VPN）にすぎず、複数の信号から認識されます。Wi-Fi の SSID、ルータ（ゲートウェイ）の MAC アドレス、Wi-Fi の BSSID、IP アドレスのサブネットプレフィックス（例：192.168.1.）、グローバル IP のブロック、そして VPN が有効かどうかです。ヘッダーは今どこにいるか（Now: Office）を示し、その下にライブのスナップショット（Wi-Fi 名・IP・ゲートウェイ・VPN 状態）が並びます。検出は 30 秒ごとに走ります。

FrontierStack が見覚えのないネットワークを検出すると「新しいネットワークを検出」のバナーを表示します。「追加…」で保存できます。「現在のネットワークをロケーションとして追加」を押してから条件を調整することもできます。ロケーションは設定したすべての条件が成立したときに一致し（SSID とルータ MAC はいずれか一致）、空欄の項目は無視されます。複数が一致した場合は、リストの先頭ではなく最も限定的なものが採用されます。モードピッカーで自動検出の代わりに手動で固定することもでき、信号が曖昧なときに便利です。

信号の信頼度は同じではなく、この違いは見た目以上に重要です。サブネットは identity ではありません。家庭用ルータもカフェもホテルも 192.168.1.× を配るため、サブネットだけで定義したロケーションはまったく別の建物にも平然と一致します。ルータ MAC が最も強い信号です。1 台のハードウェアに固有で、特別な許可なしに読み取れます。ルータ照合が存在する前に保存したロケーションには、「現在のネットワークからすべての条件を更新」がワンクリックの修正になります。

8.22.1GPS で場所をピン留めする

やっかいなケース — 2 つの拠点が本当に同じサブネットを使っていて、MAC アドレスをいじりたくない場合 — では、ロケーションに GPS ピン を持たせることもできます。その場所に立って対象のロケーションを開き、「Pin This Spot (GPS)」を押します。半径スライダで「ここ」とみなす範囲を設定します（既定 150 m。屋内測位は粗く、拠点は点ではなく建物だからです）。

ピンは相互参照であり、必須条件ではありません。役割は 2 つです。弱い一致を裏付けること、そしてより有用なこととして、誤った一致を拒否することです。これにより、同じサブネットを使うカフェを Home と判定しなくなります。検出が悪化しないよう、共有されうる条件（サブネット、VPN の有無）だけで識別されたロケーションは、位置情報が得られていてそれと矛盾する場合、確定として報告されなくなりました。自信を持った誤答の代わりに Away / Unknown が表示されます。

デバイスもロケーションに属します。Device Discovery で、監視デバイスの ⋯ メニュー ▸ Assign to Location から特定の拠点に配置できます。自動のままにすると、そのサブネットを持つロケーションに入ります。デバイス自身のペインからも設定でき、各ロケーションの行には割り当て済みデバイスが一覧されます。プライベートサブネットは拠点間で重複するため、別の拠点でピン留めしたデバイスがサブネット別にロケーションへ入ることがあります。一覧の ×（または No Location）で除外すると、同じサブネットでも戻りません。Mac が認識済みのロケーションに到着すると、FrontierStack はそれらのデバイスを確認し（VPN 経由などで最近確認済みのものはスキップ）、状態を色で示します：緑=到達可能、赤=ここにあるはずなのに応答なし、オレンジ=この Mac が到達できない Wi-Fi セグメント上（別のアクセスポイントや帯域が典型。Mac が 5 GHz のときの 2.4 GHz 専用センサーなど）。オレンジは「消えた」ではなく「ここからは確認できない」という意味です。

リンクするサブネット。ロケーションは、Mac が直接つながっていないサブネット上のデバイスもまとめられます。リンクするサブネット欄に 10.20.0.0/24 のような IPv4 CIDR を入力するか、tailnet 上のサブネットルートを一覧する Tailscale ルートメニューから選びます。Tailscale のサブネットルータ経由で届く離れた拠点に、その拠点のデバイスを持たせる方法です。リンクしたサブネットはデバイスの配置だけに使われ、別のロケーションの同じように見えるサブネットプレフィックスより優先されます。ルーティングされたサブネットはどこからでも応答するため、Mac がそのロケーションに「いる」と判定されることはありません。tailnet の 100.x アドレスは tailnet 全体に散らばっているので、それらのデバイスは手動で割り当ててください。

同じアドレス、別のハードウェア。2 つの拠点がどちらも 192.168.0.1 にルータを置いていることがあるため、FrontierStack はアドレスだけを信用せず、ハードウェア（MAC）アドレスでルータとデバイスを識別します。ピン留めしたルータは MAC が一致したときだけ稼働中とみなし、ロケーションのルータ MAC と一致するルータはそのロケーションに属します。ルータ MAC なしで保存したロケーションは、次にアクセスポイント（BSSID）か、Wi-Fi 名とピン範囲内の GPS 位置で識別されたときに自動で MAC を記録します。トラベルルータはどこでも同じ名前になるため、Wi-Fi 名だけでは記録しません。デバイスのアドレスが変わったとき（多くは DHCP の新しいリース）は、MAC がわかっているピン留めデバイスが信頼済みロケーションの LAN で応答しなくなると、そのサブネット全体で MAC を探し、新しいアドレスにピンを移します（Followed by MAC from …）。この確認はサブネットごとに最大 5 分に 1 回で、見つからない間は 1 時間に 1 回まで間隔を延ばします。

これらすべての狙いは「ロケーション依存の監視」セクションです。Overview ▸ Alerts でデバイス・Wi-Fi・Cloudflare ゾーン・ウォッチを重要としてマークし、ここで「Office のときのみ」に絞ります。そのチェックは他の場所では一時停止され、ホテルから NAS が DOWN と鳴ることも、職場で自宅 Wi-Fi が失われたとアラートが出ることもありません。一時停止された項目は戻れば静かに再開します。ロケーション自体が変わったときは、ローカル通知の表示、Messaging Gateways 経由の「📍 Now at: Office」アラート送信、またはその両方が可能です。

スクリーンショット追加予定

8.2SSH によるサーバ連携

サーバは「Link a Server」シート（デバイスのペイン・Device Discovery・Cloud Servers／Remote Tools ペインから開けます）でフリートに加わります。名前、ホストまたは IP、ポート、SSH ユーザ名（root・ubuntu・ec2-user など）、ログインパスワードを入力します。そのパスワードは一度だけ使われます。アプリがこの Mac の管理対象 SSH 鍵をサーバの authorized_keys に入れ、以降は鍵のみで接続します。保存されるのはサーバのアドレスだけで、パスワードは破棄されます。

パスワードログインのない鍵専用サーバでは、「パスワードが使えない場合は鍵を手動でインストール」を展開し、表示された公開鍵を自分で authorized_keys にコピーしてから連携します。「監視ヘルパーも併せてインストール」にチェックを入れると、同じ手順でホストモニタを設定できます（後述）。

Windows と Tailscale のサーバ。OpenSSH を有効にした Windows PC も同じ手順で連携できます。FrontierStack が Windows のシェルを検出し、PowerShell で鍵をインストールします。管理者アカウントでは C:\ProgramData\ssh\administrators_authorized_keys（sshd が要求するアクセス権付き）に、それ以外ではユーザの .ssh\authorized_keys に追加します。サーバの SSH ホスト鍵は FrontierStack 独自の信頼ストアに記録されるため、~/.ssh/config が一部のアドレスのホスト鍵を破棄する設定（Tailscale 向けに Host 100.* と UserKnownHostsFile /dev/null を指定する例はよくあります）でも連携できます。

ログインシェルが sh 以外のサーバ。FreeBSD の root（FreeBSD 13 以前は csh または tcsh）、OPNsense のコンソールメニュー用シェル、fish を使うユーザでも、通常どおり連携してコマンドを実行できます。FrontierStack はアプリを起動するたびに、最初のコマンドの前にサーバのログインシェルを 1 回だけ確認します。sh 互換でなければ、スクリプトをそのシェルに解釈させず、そのまま /bin/sh に渡します。sh・bash・zsh・ksh・dash のサーバには、これまでどおりコマンドを送ります。

連携サーバには到達性を示す小さな緑／赤のステータスドットが付きます。Permission denied (publickey) で赤くなった場合（通常はサーバ再インストール後や鍵が未インストールのとき）、AI ツール repair_ssh_access が古いホスト鍵を消して管理対象鍵を再インストールします。一度きりのログインパスワードはボールトの秘密情報として保持され、ローカルで読み取られて鍵アクセスを再設定します。成功するとドットは再び緑になります。

ホストのステータスセクションには接続行も表示されます。サーバのデフォルトルートを実際に担うもの — ネゴシエートされたイーサネット速度（10 GbE、2.5 GbE、1 GbE）、Wi-Fi 世代（Wi-Fi 7 = 802.11be、Wi-Fi 6E/6/5）とチャネル幅、または VPN トンネル — を示します。Linux・macOS・FreeBSD ホストでは通常のステータスプローブ時に読み取り、エージェントのみのホストではホストモニタ（v1.17 以降）が報告します。同じ行は この Mac にも表示され、SNMP デバイスでは Interfaces クエリが各ポートのネゴシエート済みリンク速度を一覧表示するようになりました。

各サーバには対話型シェル用の接続方式設定（編集シート内）もあります。通常の SSH（既定）、mosh — SSH 設定でログインした後、独自の UDP トランスポートに切り替わり、スリープ・ネットワーク切替・不安定な回線でもセッションを維持 — 、または実験的な SSH3（QUIC/HTTP3 上で動作し、サーバは UDP 443 の秘密 URL の背後に隠せます）です。「シェルを開く」と「SSHを開く」はこの選択に従い、プローブとファイル転送は常に通常の SSH を使います。両クライアントはサービスカタログにあります（mosh は Homebrew、SSH3 は Go）。

8.3管理対象鍵と保存された sudo パスワード

鍵アクセスでアプリは接続できますが、多くの有用な操作（/var/log の読み取り、Apache 設定の編集、ファイアウォールのリロード）にはサーバ上の root が必要です。FrontierStack はホストごとの sudo パスワードでこれを扱い、macOS キーチェーンに保存します（平文ファイルには決して書きません）。サーバ連携時に自動取得され、後からホストのペインや Remote Tools のターゲットセクション（Sudo password 欄）で設定・変更できます。

root 限定のコマンドを実行するとき、ヘルパーは SSH セッション越しに保存済みパスワードで sudo の資格情報キャッシュを準備してからコマンドを実行します。パスワードが保存されていない場合、root 操作はパスワード不要の sudo -n にフォールバックし、それも未設定なら単に「needs sudo」と報告します。秘密情報は名前で参照されるため、複数を保持できます。たとえばサーバごとに異なる MySQL パスワードを .env ボールトに置けます。

8.4Fleet Run — 全ノードへ 1 コマンド

Fleet & Remote ▸ Fleet Run は、単一の操作をすべての連携サーバ（または選んだ一部）へ一斉展開し、ホストごとのライブ結果を返します。Targets を選び（ホストをトグル。到達性ドットで起動中が分かります）、Operation を選んで「Run on N Server(s)」を押すと、すべてが SSH 上で並行実行され、各ホストが下に結果を返し、展開すれば全出力が見られます。

操作は OS を認識します。パッケージ更新はホストに応じて apt・dnf・pacman・zypper・apk・brew に割り当てられ、サービス再起動は systemd を試してから Homebrew にフォールバックします。OS ごとのコマンドを手で書く必要はありません。

操作	フリート全体で行うこと
全パッケージの更新／アップグレード	ホストのパッケージマネージャの update + upgrade を実行。展開前に確認します。
パッケージのインストール	指定パッケージ（例：htop）を選択した全ホストにインストール。
サービスの再起動	指定ユニット（例：nginx）を systemd または brew で再起動。
再起動要否のチェック	更新後に再起動待ちのホストを報告。
ディスク使用量（df）	フリート横断の df で逼迫したディスクを発見。
稼働時間と負荷	ホストごとの稼働時間とロードアベレージ。
リポジトリの git pull	各ホストの指定パスでリポジトリを pull。手早いデプロイ。
カスタムコマンド	選択した全ホストでシェルコマンドをそのまま実行。展開前に必ず確認。
PHP のバージョンとセキュリティ修正	読み取り専用。各ホストの PHP をすべて一覧にし、php.net にあるそのブランチの最新リリースと比べます（下記）。

Fleet Run はドリフトを見つける最速の手段です。ディスク使用量や稼働時間と負荷を実行してホストをひと目で比較するか、次の Remote Tools にあるファイルチェックサムやヘルスチェックで、フリート間で食い違った設定を見つけられます。

PHP のバージョンとセキュリティ修正は、PHP のセキュリティリリースのたびに生じる「どのサーバにまだ必要か」という問いに答えます。各ホストの PHP（Homebrew、MacPorts、MAMP、Apple 標準、ディストリビューションのパッケージ、SSH 経由の OPNsense や pfSense のファームウェア）をすべて一覧にし、ホストが php-fpm、php-cgi、mod_php で Web に PHP を提供しているかを示し、それぞれを php.net にあるそのブランチの最新リリースと比べます。セキュリティリリースより古いものや、修正が提供されなくなったブランチのものには、結果に印が付きます。何も変更しません。印が付いたら、AI プロンプトをコピーで Claude Code、AI 管理者、またはほかのエージェント向けのプロンプトをクリップボードに入れます。見つかったサーバとバージョンを示し、各サーバの入手元から PHP を 1 台ずつアップデートし、変更のたびに確認を求め、PHP を提供しているものを再起動して新しいバージョンを確かめるよう、エージェントに依頼する内容です。

8.5コンテナの作成 — この Mac にも、サーバにも

FrontierStack がコンテナを一覧する場所には必ず コンテナを作成… ボタンがあり、いずれも同じシートを開きます。この Mac 用の Docker ペイン、ホストピッカーで連携サーバを選んだ同じペイン、サーバアクティビティウィンドウの Docker タブです。作成したものは、開始した対象で実行されます — ローカルなら docker バイナリ経由、サーバなら既存の SSH 接続経由です。

プリセットから始めることも、空から始めることもできます。プリセットにはプレーンなイメージ — nginx、PostgreSQL、MySQL、Redis、使い捨ての Ubuntu シェル — に加え、アプリが単一コンテナとして実行できるセルフホスト可能なサービス（n8n、Flowise、Langflow、Vaultwarden、Checkmk など）がすべて含まれます。選ぶとイメージ、ポート、ボリューム、環境変数が入力され、あとから変更できます。docker-compose スタックが必要なサービスは、この Mac 上の専用ペインからインストールします。対象はシートに明記されます。

項目	内容
イメージ	イメージ参照。対象に既にあるイメージのメニュー付き。
名前	省略可。対象で使用中の名前と照合します。
公開ポート	各行のこのマシンのみで 127.0.0.1 にバインド。指定しない限りネットワークには公開しません。
ボリューム	単なる名前は Docker 管理のボリューム、/ で始まるパスは対象上のフォルダ。
環境変数	シークレット指定するとパスワードとして入力し、プレビューでは隠れます。
詳細設定	再起動ポリシー、ネットワーク、コマンドの上書き、追加の Docker 引数、バックグラウンド実行の有無。

実行前に、シークレットを伏せ字にした docker run のコマンドがそのまま表示され、コピーできます。作成時はまずイメージを取得し（オフにもできます）、続いて実行して出力をシートに表示します。

8.22.2モニタとしての Containers ボード

Containers ペインは一覧であるだけでなく、この Mac のすべてのランタイムを 1 つの判定にまとめたステータスドットを持ちます。サイドバーを一目見れば、対応が必要かどうかが分かります。緑はインストール済みのものがすべて正常、オレンジは停止中または確認中、赤はインストール済みエンジンの停止、あるいはコンテナの unhealthy・再起動ループ・エラー終了です。一度もインストールしていないランタイムは異常とは見なしません — つまり緑は「すべて実行中」ではなく「存在するものがすべて正常」を意味します。

セクションの並びはサービス一覧と同じで、Apple Containers、Docker、Kubernetes、OrbStack、コンテナマシン、Vagrant の順です。Kubernetes はここでは読み取り専用で、Kubernetes Clusters でピン留めしたクラスタを表示します。ピン留めとクラスタごとの操作は同ペインに残ります — そちらはこの Mac の中だけでなく、どこで動いているクラスタでも監視するためです。未インストールのランタイムでは、ダウンロードページではなく導入用のペインを開くボタンが表示されます。

ヘッダのピンボタンは、小さなフローティングパレットを開きます。全体のドットと実行数を示すステータスバーが 1 行あり、その下に実行中のものの短い一覧、さらに設定済みで待機中のものを Waiting としてまとめます。画面の隅に置いたまま別の作業ができるよう、意図的に小さくしてあります。行をクリックすると、メインウインドウがその項目へ移動します。

8.22.3Docker Swarm

Swarm は別途インストールする製品ではなく、Docker エンジンに組み込まれています。FrontierStack が専用ペインを設けず Docker ペインから監視するのはそのためです。表示中のエンジンが swarm に参加していると Docker Swarm セクションが現れ、クラスタのノード（Ready か Down か、drain 中か、どれがマネージャか）とサービスをレプリカ数とともに一覧します — 必要なタスクがすべて揃っていれば 3/3、足りなければ 1/3 のように表示されます。サーバアクティビティウインドウの Docker タブにも Swarm セグメントとして同じ内容があり、連携サーバからクラスタを確認できます。

状態はペインがエンジンの健全性確認で既に実行している docker info から取得するため、swarm に参加していないマシンでは追加のコストがかかりません。表示内容を左右する Swarm の規則がひとつあります — クラスタを一覧できるのはマネージャだけです。ワーカーに尋ねてもデーモンが拒否するため、FrontierStack は失敗に見える空の表ではなく、その旨をはっきり表示します。

8.22.4既成のスタック

1 つのコンテナではなく、単独では役に立たない複数のコンテナで成り立つものがあります。Containers ペインとサーバアクティビティウインドウの Docker タブにある Install Stack… は、その一群をまとめて導入します。標準で 4 つを用意しています：*arr メディアスタック（他のアプリが参照するインデクサ一覧を持つ Prowlarr、連続ドラマの Sonarr、映画の Radarr、音楽の Lidarr、書籍の Readarr、字幕の Bazarr、そしてダウンロードクライアント）、監視（Prometheus、Grafana、node-exporter）、メディアサーバ（Jellyfin、任意でリクエスト用の Jellyseerr）、そして Immich（サーバ・機械学習・Redis・PostgreSQL の 4 つを本当に必要とするセルフホスト写真ライブラリ）。

含めるメンバー、設定とメディアのフォルダ、コンテナが書き込むユーザとグループ、そしてスタック全体を既存の待ち受けから一括でずらすポートオフセットを選べます。公開ポートは、指定しない限り 127.0.0.1 にバインドします。FrontierStack はプロジェクトフォルダに docker-compose.yml を書き出し、docker compose up -d を実行します。スタックをスタックたらしめているのが compose です — メンバーはネットワークを共有し、名前で互いに到達できます。Sonarr のインデクサ設定が単に http://prowlarr:9696 で済むのはそのためです。

8.22.5Apple コンテナと、推奨する GUI

Apple シリコンでは、Apple 自身の container コマンドにより macOS が Linux コンテナをネイティブに実行できます。1 つの大きな Linux VM を共有するのではなく、コンテナごとに軽量な仮想マシンが割り当てられます。Containers ペインの Apple Containers セクションがこれを担当し、実行中のものを一覧し、コンテナシステムを起動／停止し、イメージを取得し、新しいコンテナを作成します — 上記の Docker セクションと同じ構成です。Apple のツールはコマンドラインプログラムで、FrontierStack は GitHub のリリースから導入します。

Apple コンテナの日常的な操作には、Davit を推奨します。同じ container コマンドに本格的なグラフィカルフロントエンドを与える独立した macOS アプリで、サブコマンドを覚えなくても、コンテナとイメージの閲覧、起動と停止、ログの追跡ができます。Apple Containers セクションから Homebrew cask で導入し、そのまま開けます。Davit には Apple シリコンと macOS 15 以降が必要です。

8.22.6サーバ上の Watchtower

Watchtower は新しいイメージを取得してコンテナを作り直し、Docker コンテナを最新に保ちます。連携サーバで動いていると、FrontierStack は定期ステータス確認でそのコンテナを見つけ、設定とログを SSH 経由で最大 1 時間ごとに読み取ります。サーバペイン、サーバアクティビティウィンドウの Docker タブ、コンテナの下の Watchtower ペインに、前回のスキャン（確認・更新・更新失敗したコンテナの数）を表示します。スケジュールとモード、それ以降のエラーも表示します。通知 URL や API トークンは読み取りません。Watchtower が停止したとき、Docker に拒否されたとき、更新に失敗したとき、スキャンが届かなくなったときにアラートが出ます。

8.6Remote Tools — ノード単位の診断

Fleet & Remote ▸ Remote Tools は、実際のフリートデバッグ作業から抽出した SSH 駆動の診断スイートです。まずターゲット（固定サーバ、または保存していないアドレス用の Other (IP / host)…。その sudo パスワードもキーチェーンに保持されます）を選び、次にツールとそのパラメータを選びます。読み取り専用チェックに root は不要で、保護されたログや設定を読むものは保存済み sudo パスワードをヘルパー経由で使い、一部はmutating（変更あり）と表示されます。

ツール	用途
Ping・Traceroute・Whois	選んだノードからの基本的な到達性・経路・登録情報の照会。
Net Info・Netstat	インターフェイスとアドレス。ルーティングテーブル、インターフェイス／プロトコル統計、アクティブソケット。
Port Scan・Port Check・Web Check	範囲スキャン、単一ポートのテスト、HTTP/HTTPS エンドポイント取得とステータス報告。
TLS Inspect・TLS Expiry	証明書の検査。選択ノード横断で有効期限を一括チェック。
System Resources・Listening Ports	ノードの負荷・メモリ・ディスク。待ち受け状況（必要なら sudo で）。
Tail Log・Config Test	任意のログパスを tail。Web サーバ設定を検証。
File Diff・Healthcheck	ファイル内容をノード間で比較（ドリフト）。各ノードでループバック越しに vhost のパスを叩く。
rsync Deploy	ローカルフォルダをリモートパスへ送信。ドライランのプレビューと任意の --delete 付き。
Security・SSH・Exposure・Auth・User 監査	任意のノードや IP に対する読み取り専用監査（第 10 章）。
Flush DNS・Restart Backend	リゾルバキャッシュのフラッシュ。macOS Server の Web バックエンドを再起動（mutating — サイトが一瞬途切れます）。

一部のツールは複数の選択ノードに同時に働きます。File Diff・Healthcheck・TLS Expiry・配信経路診断（Serving Path Diagnosis）（どのノードが稼働中か、各ノードがどの公開 IP をバインドしているか、プロセス単位の CPU 飽和と停止中サービス、そしてピン留めした全 Cloudflare ゾーンのオリジン IP との照合）は設計上フリート横断で、すべての Web ノードが同じ内容を有効な証明書で配信していることを確認するのにまさに使えます。ペイン下部では、/etc/hosts（root、ヘルパー経由）と SSH ユーザ自身の ~/.ssh/known_hosts を SSH 越しに安全に編集でき、各保存はまず .fsbak にバックアップします。

8.7ホストモニタ（リモートエージェント）

SSH 診断はオンデマンドです。継続的な可視性にはホストモニタをインストールします。サーバ上に常駐する小さな読み取り専用の Go ヘルパー（fsagent）で、サイクルごとの SSH なしに自分の健全性を報告します。連携ホストのペインからインストールを選ぶ（または Link a Server のチェックボックスをオンにする）と、既存の鍵越しにアプリがホストの OS とアーキテクチャに合ったバイナリを送り、プラットフォームのサービス（systemd・launchd・BSD の rc.d）を設定し、その TLS 証明書をピン留めします。AI ツール install_monitor も要求に応じて同じことを行います。

LAN と Tailscale の両方で待ち受け。モニタは、この Mac がインストールに使ったアドレスに加えて、サーバ自身の LAN アドレスと Tailscale アドレスで待ち受けます。すべてのインターフェイスや、グローバルアドレス・コンテナのブリッジアドレスでは待ち受けません。一方のアドレスで応答しなくなると（オフィスを離れて Tailscale 経由で接続している場合など）、同じ固定済み証明書を示す別のアドレスに自動で切り替えます。バージョン 1.22 より前にインストールしたモニタは 1 つのアドレスでしか待ち受けません。モニタを検出が「動作中だが届かない」状態を知らせ、「SSH経由でインストール・登録」で更新できます。

登録されると、モニタはライブのメトリクスをストリームします。CPU・メモリ・マウントごとのディスク・起動中のネットワークインターフェイス、検出されたサービス、ファイアウォールと fail2ban の状態、そして GPU ホストでは GPU ごとの温度と使用率を報告し、マイニングや ML のリグでも温度が把握できます。list_monitors はフリートのヘルパー、バージョン、最新メトリクスを報告します。重要なのは、モニタは Mac アプリがオフラインのときでも監視を続けてアラートでき、自前のチャネルで直接通知し、アプリが戻れば蓄積分を再送します。ログウィンドウもモニタを優先します。サーバ上で root として動くため、sudo パスワードなしで特権ログを読めます。

登録済みホストのペインには動作と履歴チャートも表示されます。CPU・メモリ・ディスク・温度を5分解像度で最大30日分描画し、学習したベースラインで異常を検出します。温度は専用の摂氏スケールを使うため、パーセント表示のリソース使用率と並べても読み違えません。赤い縦線が同じタイムライン上にインシデントを示します。実線の赤はサーバの再起動（報告された稼働時間から導出）、オレンジの破線はウォッチドッグの問題 — サービスの強制再起動、データベース破損警告、再起動エスカレーションです。OS のクラッシュレポータが CPU を使い始めた場合（プロセスが繰り返しクラッシュしている状態）はオレンジの Crashes 曲線も加わり、「昨夜 MySQL が2回強制再起動され、何かがクラッシュループしていた」ことが一目で分かります。グラフの下のクラッシュログを開く…で、サーバのクラッシュ・ハング・パニックレポート（macOS の DiagnosticReports）をログビューアで開き、その曲線がどのプロセスによるものか確認できます。

モニタは既定で読み取り専用です。Host Monitor ペインでAllow actionsをオンにすると、小さく固定された制御動詞（任意シェルは決して含みません）が解放され、ゲートされた monitor_action ツールで駆動されます。許可リスト内サービスの restart/reload/start/stop、DNS フラッシュ、ファイアウォールや fail2ban のリロード、再起動です。各アクションはサーバ上に記録されます。対象は Linux（amd64／arm64／arm — あらゆる Raspberry Pi を網羅）、macOS（OS X 10.11 El Capitan までさかのぼるレガシー Intel ビルドを含む）、FreeBSD（pfSense／OPNsense／TrueNAS）、Windows です。

モニタを長期的に健全に保つ作業は自動化されています。モニタ認証情報をローテーションはベアラー認証情報をその場で差し替えます。新しいシークレットは Mac 上で生成され、承認済みの FS1 署名鍵で送られ、表示や AI への引き渡しなしにサーバ上で有効化されます。自己アップデートを許可が有効なら、新しいビルドの配布は構造的に安全です。候補バイナリのリリース署名を検証し、root 権限を与える前に互換性セルフテストに合格する必要があり、直前のバイナリはロールバック用に保持されます。新しいバイナリがヘルスチェックに応答しなければ、FrontierStack が自動的に元へ戻します。プルモードの更新は、恒久トークンではなく短命・単回使用の付与でバイナリを取得します。モニタが FS1 署名リクエストを検証しているときは、そのペインに FS1 signed バッジが表示されます。

8.8サーバが応答しないとき：FrontierStack が最後に見た情報

応答しなくなったサーバこそ、詳細が必要なサーバです。別経路で試すためのアドレス、ラックで探すためのハードウェア、影響範囲を知るための稼働サービス。そこで FrontierStack は、連携サーバごとに応答していた間に最後に確認した内容を記録し、空欄の「確認中…」が並ぶペインの代わりにその記録を表示します。

サーバが応答しなくなると、ペインの先頭にオレンジ色の行 — 「応答なし — 以下は FrontierStack が最後に確認した内容です」とその日時 — が表示され、記録済みの値が時計アイコン付きの淡色で並びます。サービスの下には最終確認時に稼働中として、その時点で動いていたサービスが一覧されます。淡色の値はライブの読み取りではなく、その時点の事実です。その後サーバ側が変わっている可能性があります。サーバが再び応答すると、すぐにライブの値に置き換わります。

記録する項目	内容
システム	OS バージョン、ハードウェア、最終確認時の稼働時間。
アドレス	IPv4 とすべてのアドレス、安定した IPv6 アドレス（リンクローカルと一時的なプライバシーアドレスは、変わるか他のマシンから使えないため除外）、Tailscale の IP と MagicDNS 名、公開名。
ネットワーク	DNS リゾルバと接続種別（Ethernet の速度、Wi-Fi の世代、VPN）。
サービス	最後に確認したときに動いていたサービス。
定期再起動	OS 自身に設定された再起動：省エネルギー設定の繰り返し再起動（pmset）、reboot や shutdown を呼ぶ LaunchDaemon、cron、systemd タイマー、unattended-upgrades の Automatic-Reboot。設定なしも記録するので、定期再起動の可能性を除外できます。
モニタの設定	モニタのバージョン、Allow actions と Allow reboot、監視中のサービス、ロックアップ再起動の設定、再起動センチネルの状態、有効な直接通知の種類。通知 URL やトークンは決して記録しません。

Status セクションには新しい行が 2 つあり、サーバが応答している間はライブで表示されます。IPv6 は安定した IPv6 アドレスを、定期再起動は OS が自動で行うよう設定された再起動を表示します。サーバが毎週同じ時刻に「謎の」再起動をするとき、最初に確認すべき項目です。

AI 管理者も同じ記録を、最終確認の日時付きで参照します。そのため「さっき落ちたサーバの IP は？」という質問に、サーバ自身が答えられなくても回答できます（第 13 章）。

スクリーンショット追加予定

8.9ロックアップ再起動：電源は入っているのに誰も入れないとき

サービスウォッチドッグ（第 11 章）はサービスを 1 つずつ復旧します。しかし、内部から見ると各サービスが正常なまま、マシン全体が使えなくなる障害があります。SSH と画面共有が応答しなくなった Mac や、いつの間にかネットワークを失ったサーバです。外からは誰も届かないため、復旧はサーバ自身が行うしかありません。サーバのペインのサービスウォッチドッグパネルにあるロックアップ再起動がそれを担います。モニタ 1.23.0 以降が必要で、古い場合はパネルにその旨が表示されます。

設定	動作
SSH が応答しなくなったら再起動	モニタが SSH ポート（変更しなければ 22）に接続し、ポートが開いているかだけでなく sshd の SSH グリーティングを待ちます。ハングした Mac は、ポート 22 で TCP 接続を受け付けたまま、何も返さずに切断することがよくあります。ポート確認ではこれを正常と判定してしまいます。
サーバがネットワークを失ったら再起動	モニタがデフォルトゲートウェイに届くかを確認します。追加の確認先を host または host:port で指定でき、いずれかが応答すればオンラインとみなします。
N 分間失敗が続いたら再起動	既定は 10 分。その間に 1 回でも成功すると、カウントはやり直しです。
自動再起動は N 分ごとに最大 1 回	ブートループ防止です。障害がどれだけ続いても、自動再起動はこの間隔に 1 回までです。

各チェックは、モニタの起動後に 1 回成功してから初めて有効になります。sshd のないサーバや、モニタがゲートウェイを見つけられないサーバが、このチェックで再起動されることはありません。チェックは待ち続けるだけです。また、ペインのリモートアクションで Allow actions と再起動を許可の両方がオンでなければ、サーバは再起動を拒否します。オフの場合はパネルに警告が出ます。

ロックアップ再起動がオンの間、パネルには各チェックのライブ状態（応答あり · 有効、最初の成功確認を待機中、○○ から失敗中）、ネットワークチェックが使っているゲートウェイ、最後の自動再起動の日時が表示されます。

8.22.7root で動く再起動センチネル

この機能のきっかけになったハングは、クラッシュより奇妙なものでした。サーバのポートは接続を受け付けるのに、sshd も画面共有もまったく応答しない。マシンが新しいプロセスを起動できなくなっていたのです。そうなると、shutdown コマンドの起動から始まる再起動も実行できません。モニタ 1.24.0 からは、macOS と Linux でモニタと一緒に再起動センチネルがインストールされます。同じバイナリを root で動かすもので、ネットワークの待ち受けもトークンもありません。

センチネルは独自のポリシーを持ちません。モニタ自身のロックアップ再起動の設定と権限だけに従うバックストップです。モニタによる再起動が行われるはずだったのに行われていなければ、その 3 分後に再起動します（既定の 10 分なら障害発生から 13 分後）。この経路ではプログラムを一切起動せず、ディスクも待たず、カーネルの再起動を直接呼び出すため、サーバが新しいプロセスを起動できない状態でも動作します。再起動の直前には、プロセスを起動できたかどうかを記録します。「プロセス枠が尽きていた」ことを後から裏付ける証拠になります。パネルには、センチネルがインストール済みで報告しているか、いつ動作するか、最後の再起動が表示されます。未インストールと表示された場合はモニタを更新してください。

8.22.8プロセス数

プロセス枠が尽きると、サーバは接続を受け付けても sshd や画面共有を起動できなくなります。モニタは 1.24.0 から毎分プロセス数を記録します。カーネルの上限に対する総数、ユーザごとの上限、プロセスの多いユーザです。ロックアップ再起動の欄にあるプロセスの行には、現在の値、ピーク付きの直近 24 時間のグラフ、そして総数または特定ユーザの数が上限に近づいたときのオレンジ色の警告が表示されます。ロックアップになる前に暴走を見つけるタイミングです。

8.10Cloud Servers・Server Clone・リモート Apache

コンピュート系のペインに加え、AWS ▸ DynamoDB は選択中のリージョンのテーブルを、ステータス・アイテム数・サイズ・パーティションキー/ソートキーとともに一覧します。実際にコストや事故につながる 2 点を重視しています。キャパシティモードのカプセルは、アクセスの有無にかかわらず読み書きキャパシティに継続課金されるプロビジョンドのテーブルと、リクエスト単位で課金されるオンデマンドのテーブルを区別します。PITR無効の表示は、ポイントインタイムリカバリが無いテーブルを示します。新規テーブルでは既定で無効であり、誤った書き込みから巻き戻す唯一の手段です。ポイントインタイムリカバリは各行のメニューから切り替えられます。DynamoDB には一括の describe が無いため、テーブルごとに問い合わせ、リージョンあたり 40 件を上限としています。

Fleet & Remote ▸ Cloud Servers は、API トークンを設定したクラウドプロバイダ（DigitalOcean・Vultr・Linode・Hetzner・Sakura・Contabo）と AWS の EC2・Lightsail・RDS を横断する 1 つのインベントリにまとめます。読み取り専用のロールアップです（電源制御は各プロバイダのペインに残ります）。IP を持つ起動中インスタンスごとに、待ち受けを調べる Services ボタンと、SSH で連携してモニタを一手にインストールする + Helper ボタンがあります。シートで正しいユーザ名と鍵を設定するだけです。

Google Cloud は Google Cloud CLI ペイン（Hosting）を通じて同じインベントリに加わります。そこでインストールするとブラウザで gcloud auth login も実行され、以後 FrontierStack はキーを保存せず、お使いのログインを利用します。プロジェクトまたはすべてのプロジェクトを選び、Compute Engine の VM を SSH、開始、停止、リセットできます。停止とリセットは実行前に確認します。AI Administrator は diagnose で読み取り、list コマンド以外はユーザの承認が必要です。

Microsoft Azure も Azure CLI ペイン（Hosting）を通じて同じように加わります。そこでインストールするとブラウザで az login も実行されます。サブスクリプションまたはすべてのサブスクリプションを選び、Linux VM に SSH で接続したり、VM を開始、停止、再起動したりできます。停止と再起動は実行前に確認します。Azure では電源を切っただけの VM にもコンピューティング料金がかかるため、停止は VM の割り当てを解除します。AI Administrator は diagnose で読み取ります。秘密情報を返す Azure の list が多いため、実行できるコマンドは決められたものに限られ、それ以外はユーザの承認が必要です。

Server Clone は、フリートサーバをこの Mac に合わせて立ち上げるガイド付きウィザードです。検出した Homebrew スタックをインストールし、設定とサイトファイルを元のパスにコピーし、ドメイン設定をプッシュして Web サーバをリロードし、MySQL データベースをクローン（ローカルの mysqldump を SSH 越しにターゲットの mysql へパイプ）できます。各ステップは鍵ベースの SSH で実行され、再実行しても安全で、既存データは削除されません。

単一サイトを公開する準備ができたら、（ドメインのコンテキストメニューからの）Promote to Production プッシュが、その vhost 設定をローカルと同じパスへ送り、必要ならドキュメントルートとデータベースをコピーし、Cloudflare 経由で DNS をターゲットに向け、certbot で本物の Let's Encrypt 証明書を発行できます。ファイル・データベース・vhost・DNS・HTTPS を 1 回のプッシュで。

リモートサーバの Apache も直接管理できます。リモートホストが 1 つでもあると Apache ペインにホストセレクタ（This Mac／各連携サーバ）が現れます。サーバを選ぶと FrontierStack が SSH 越しにその Apache を検出し（バージョン・設定構成・実ログパス付きの全アクティブ vhost）、vhost・モジュール・MIME タイプ・ポート・WebDAV を編集できます。各変更は検証（httpd -t）して優雅にリロードしてから確定し、設定が無効ならロールバックします。レガシーの macOS Server.app の Apache ツリーも理解します。Sites リストの Push to Server… は、ローカルサイトの vhost をモニタ連携サーバにドキュメントルートを差し替えて展開します。これらが対応するローカル Apache と Sites のワークフローは第 7 章が扱います。

サイトが 5 つ以上あるリストには、連携サーバでもこの Mac でも、横にすべてテストが表示されます。各サイトにこの Mac から 1 回ずつ、そのサーバへ直接接続してリクエストし、それぞれの応答を問題のあるものから順に一覧表示します。Web サーバを開始または停止するには、サイドバーのサーバを Control クリックして Web サーバを開始または Web サーバを停止を選びます。停止するときは確認があります。

スクリーンショット追加予定

8.11ホストへの画面共有

各サーバのペインは、プローブが検出したリモートアクセス手段を提供します — Mac なら Apple 画面共有／VNC、Windows なら RDP、クライアントがあれば AnyDesk・TeamViewer・RustDesk・NoMachine。この Mac に Apple Remote Desktop がインストールされていると vnc:// ハンドラを乗っ取るため、ペインは代わりに Apple 標準の画面共有クライアントを必ず開く画面共有（macOS）アクションを別途提供します。ホストが複数のアドレスで到達可能な場合 — 例えば LAN の IP と VPN／Tailscale のアドレス — このアクションはどのネットワークで接続するかを選ぶメニューになります。各選択は数値 IP に直接接続するため、ホスト名が解決しないとき（mDNS、split-horizon DNS、VPN の癖）でも機能します。ペインが解決しないかもしれない名前を使う場合は、VNC と RDP にも同様の「— by IP」ボタンが現れます。

8.22.9自分の RustDesk サーバ

RustDesk はすべてを自前で運用できるオープンソースのリモートデスクトップで、そのペイン（Fleet & Remote ▸ RustDesk）はクライアントを開くだけではありません。セルフホストの RustDesk サーバを認証情報なしで監視します — ID サーバ（hbbs、TCP 21115。無関係なポートが開いているだけでは合格しません）との実際のランデブー通信、TCP 21116、リレー（hbbr、TCP 21117）を確認し、応答しなくなるとアラートを出します。

この Mac の RustDesk クライアントが使っているサーバも表示し、RustDesk の公開サーバのままのときや、キーがない・異なるときに警告します。クライアントを移行するには、サーバごとに公開キー（id_ed25519.pub）を貼り付け、RustDesk ▸ Settings ▸ Network で取り込む設定文字列か、Windows インストーラを自動設定させるファイル名をコピーします。RustDesk Server には macOS 版がないため、独自の RustDesk サーバを運用では Linux サーバや VPS 向けの Docker compose ファイルを提供します。ポートは明示的に割り当て、hbbr -k _ によってリレーは自分のキーを持つクライアントだけに応じます。

8.12KVM-over-IP：コンソールと電源、無人運用

SSH や画面共有は、マシンが起動しネットワーク上にあることが前提です。そうでないとき — カーネルパニック、BIOS／ファームウェア画面、ネットワークスタックが上がらない — に必要なのがアウトオブバンドアクセス、すなわち OS に依存せず実際の HDMI 出力を取り込み USB キーボード／マウスを注入する KVM-over-IP 機器です。リモート KVMペインは、所有する機器（PiKVM・JetKVM・TinyPilot・NanoKVM・GL.iNet Comet・汎用機）を好きなだけ登録でき、各機器はピン留めでき、Web コンソール（BIOS レベルまで）にワンクリックで接続できます。

電源制御を持つ機器はループを閉じます。ATX ボード付き PiKVM、ネットワーク PDU、あるいは GL.iNet の Comet Pro（GL-RM10） — KVM とスマート電源プラグを 1 台に兼ねる — は主電源を切り替えられ、本当にフリーズした機体を強制的に電源サイクルできます。こうした機器はサーバの電源セクション（SwitchBot・UPS・PDU コマンドと並ぶ）で電源ソースとしてリンクでき、オン／オフ／サイクルが可能です。AI 管理者からも操作できます：list_kvms・kvm_power・server_power（最後のものは reboot_host に応答しないハングしたサーバを、リンク済みのプラグ／PDU／KVM で再起動します）。

8.13コンソール接続：シリアルとコンソールサーバ

ネットワーク設定を失ったルータやスイッチには、SSH・Web UI・KVM では届きませんが、コンソールポートはまだ使えます。コンソール接続ペイン（Fleet & Remote）は FrontierStack に組み込まれたシリアルターミナルです。USB シリアルアダプタ（FTDI、Silicon Labs CP210x、WCH CH340／CH9102、Prolific）か、機器本体の USB コンソールポート（Cisco の USB mini-B／USB-C、Netgate のファイアウォール）を接続すると、数秒以内に接続中のシリアルポートにチップ名付きで表示されます。クイック接続は何も保存せず、選んだ速度で開きます。保存…はベンダのコンソール設定で接続を保存します。対応ベンダは Cisco、Juniper、Arista、Aruba CX、ProCurve、Ruckus、Fortinet、Palo Alto、SonicWall、WatchGuard、pfSense／OPNsense、MikroTik、Ubiquiti、TP-Link Omada、Dell OS10、Allied Telesis、APC、Raspberry Pi、Linux、OpenWrt や GL.iNet ルータの基板 UART です。

設定はすべて変更できます。速度（460800、921600 などアダプタが対応する任意の値）、データビット、パリティ、ストップビット、フロー制御に加え、Return の送信内容（CR、CR LF、LF）、Backspace を ^H にする設定、ローカルエコー、表示が階段状にずれる機器向けの LF → CR LF があります。アダプタを別の USB ポートに挿し替えて macOS が名前を変えても、USB シリアル番号で再検出します。コンソールサーバ（Lantronix、Opengear、Digi、Avocent ACS、Cisco ターミナルサーバのリバース telnet、Raspberry Pi の ser2net）は、telnet、raw TCP、SSH の接続として追加します。

セッションはそれぞれ個別のウィンドウで開きます。Break は BREAK 信号を送ります。Cisco の ROMMON、Juniper、多くのブートローダはパスワード回復時にこの信号を待っています。DTR と RTS も切り替えられます。貼り付け間隔を設定すると、貼り付けた設定を 1 行ずつ送るため、9600 bps のコンソールでも文字が欠けません。セッションログは機器から受信したすべてを ~/Library/Logs/FrontierStack/Console に保存し、書き出しで画面を保存・メール送信できます。接続をピン留めデバイスにリンクすると、そのデバイスのページのコンソールセクションに表示されます。そこから追加した接続には、プラットフォームの標準設定が最初から入ります。AI 管理者はコンソールと接続中のアダプタを一覧できます（kvm の consoles アクション）が、セッションを開いたり入力したりはしません。

スクリーンショット追加予定

8.14Boot Media：ネットワーク越しに OS をインストール

かつてサーバの再インストールといえば、USB メモリを持ってラックまで行くことでした。Boot Media ペイン（フリートとリモート）は USB メモリの代わりになります。インストーライメージをこの Mac のライブラリにまとめておき、選んだものを FrontierStack が仮想 CD として対象マシンに提示します — サーバの管理コントローラ、PiKVM、Proxmox VE 仮想マシンの CD ドライブ、またはネットワークブートメニューを通じて。Mac は扱いが異なります。Apple がもうこの方法での起動を認めていないためです。後述のMacを参照してください。

スクリーンショット追加予定

8.22.10イメージライブラリ

Add ISO or Disk Image… はローカルファイルを登録します。ファイルはその場所のままで、コピーはしません。Add Image URL… は Web サーバやファイルサーバ上にすでにあるイメージ（http・https・nfs・cifs）を登録します — リモート URL は対象にそのまま渡されるので、この Mac がデータを中継する必要はありません。Compute SHA-256 はファイルのチェックサムを記録し、インストール前にベンダが公開している値と照合できるようにします。各項目は名前の変更、Finder での表示、ライブラリからの削除ができ、Copy Image URL で配信アドレスをコピーできます。保存した場所にファイルがなくなった項目には、見つからない旨の印が付きます。

8.22.11内蔵メディアサーバ

管理コントローラは ISO を HTTP で少しずつ読みながらマウントし、インストールが続く間ずっと読み続けます。ペインの Media server は、まさにそのためにライブラリのローカルイメージを配信します。仮想 CD に必要なバイト範囲リクエストとキープアライブに対応し、最近のリクエストのログとイメージごとの配信バイト数を表示するので、コントローラが実際に読んでいることを確認できます。ローカルイメージを必要とする対象があれば自動的に開始し、Start Serving で手動で開始することもできます。

設定	内容
Stop serving after	1・3・6・12・24 時間、または Until I stop it（停止するまで）。読み込みがあるたびに時間はリセットされるため、遅いインストールが途中で切られることはありません。FrontierStack を終了したときも配信は止まります。
Address in image URLs	Automatic は、この Mac が各対象へ到達するときのアドレスを使います。別の管理用 VLAN にあるコントローラにも、実際に届くアドレスが渡されます。固定アドレスを 1 つ選ぶこともできます。
Port	既定は 8742。
Open Port…	pf またはアプリケーションファイアウォールが有効で、コントローラからの接続を遮る可能性があるときに表示されます。管理者の確認のうえでポートを開きます。

8.22.12サーバ管理コントローラ（Redfish）

多くのラックサーバは、イメージを仮想 CD として提示できるベースボード管理コントローラを備えています。FrontierStack は標準の DMTF Redfish API でこれを操作します：Dell iDRAC 8／9、HPE iLO 4／5／6、Lenovo XClarity Controller（XCC）、Supermicro X12 以降、そして標準の Redfish 仮想メディアを実装したその他のコントローラです。

1. Add Controller でアドレス・ポート・ユーザ名・パスワードを入力します。パスワードは Keychain に保存され、コントローラにだけ送られます。必要ならフリートのサーバとリンクして、両者を並べて表示できます。Virtual Media と Control の権限を持つアカウントを使ってください。
2. Read Controller で管理対象を検出します：各システムのモデルと電源状態、各仮想 CD スロットと現在マウントされているもの。
3. System・Virtual CD・Image を選びます。Boot from it once をオンのままにすると CD から 1 回だけ起動し、その後は通常の起動順序に戻ります。
4. Then で Don't restart（再起動しない）・Graceful restart（正常再起動）・Force restart（強制再起動）を選び、Mount（または確認を求める Mount and Restart）を押します。
5. インストールが終わったら仮想 CD を Eject します。

コントローラ	仮想メディアに関する注意
Dell iDRAC 8／9	Enterprise または Datacenter ライセンスが必要。
HPE iLO 4／5／6	iLO Advanced が必要。
Lenovo XClarity（XCC）	XCC Advanced または Enterprise が必要。
Supermicro X12 以降	標準の Redfish 仮想メディア。X10／X11 のボードは独自コンソールでしか仮想メディアを提供しないため、コピーした URL を使ってそちらでマウントします。
その他の Redfish コントローラ	標準の VirtualMedia 挿入／取り出しアクションを実装したもの。

8.22.13IPMI コントローラとネットワークから 1 回起動

古いボードには、Redfish がない、または Redfish はあっても仮想メディアがないコントローラがあります（Supermicro X10／X11、ASRock Rack、Gigabyte、Intel、iDRAC 7）。そうしたコントローラはProtocolを IPMI over LAN に設定します。FrontierStack は ipmitool で操作します（Install ipmitool でアプリ内コンソールから Homebrew でインストール）。パスワードはキーチェーンに保存したまま、コマンドラインではなく環境変数で ipmitool に渡します。Read Controller で電源状態を表示します。IPMI には標準の仮想メディアがないため、OS のインストールにはネットワークを使います。ネットワークから 1 回起動は次回の起動を PXE に設定し（chassis bootdev pxe。レガシー BIOS 起動にチェックしない限り UEFI モード）、必要に応じてハードリセットを送ります。電源が切れていれば電源を入れます。IPMI には正常な再起動はありません。

Redfish コントローラにもネットワークから 1 回起動があります。1 回限りの Pxe 起動指定のあと、選んだ方法で再起動します。下の内蔵 PXE サーバと組み合わせれば、仮想メディアを使わずにリモートのサーバをこの Mac の ISO メニューから起動できます。

8.22.14PiKVM 仮想メディア

PiKVM は、接続先のマシンに対して USB ドライブをエミュレートできます。Boot Media は PiKVM の公開 /api/msd インタフェースを使い、ATX 電源制御と同じ PiKVM API アカウントで接続します（KVM-over-IP を参照）。まずイメージを PiKVM 自身のストレージにコピーします：ローカルファイルは進捗バー付きでストリーミング転送し、リモート URL は PiKVM が自分でダウンロードします。コピー開始前に空き容量を確認します。続いて保存済みイメージを As CD-ROM（ISO 用）または As Flash（raw の .img 用）で接続し、マシンの起動メニューで選ぶか Power Cycle…（確認付きのハード ATX サイクル）を使い、コンソールを開いてインストールを見守ります。後片付けは Disconnect Drive と削除で行います。

8.22.15Proxmox VE 仮想マシン

Proxmox VE 上の仮想マシン（後述の Proxmox VE のとおり接続済みのもの）では、Node・Virtual machine・ISO storage を選び、次に Source を選びます。Image from the library は Proxmox 自身にイメージを ISO ストレージへダウンロードさせる（download-url 呼び出し）ため、ローカルイメージはこの Mac のメディアサーバから取得されます。ISO already on Proxmox はすでにある ISO を使います。FrontierStack は ISO を VM の CD ドライブに接続し、CD を起動順序の先頭にすることもできます — 元の順序は記憶され、取り出し時に復元されます。最後に、VM をそのままにする・起動する・リセットする（確認を求めるハードリセット）から選びます。

API トークンには、ダウンロード用に Datastore.AllocateTemplate と Sys.AccessNetwork、VM に対して VM.Config.CDROM・VM.Config.Options・VM.PowerMgmt が必要です。ペインの操作部の横にもこの一覧が表示されます。

8.22.16ネットワークブート（PXE／iPXE）

コントローラも KVM もないマシンでも、ネットワークから起動できます。Serve an iPXE boot menu from this Mac をオンにすると、メディアサーバは iPXE メニューも公開します。このメニューはライブラリの ISO を HTTP で SAN ブートし、インストーラのカタログを持つ netboot.xyz へチェーンし、iPXE シェルとローカルディスクから起動も備えます。Download iPXE Boot Loaders は boot.ipxe.org から公式ローダ（ipxe.efi・undionly.kpxe・arm64 版 ipxe.efi）を取得し、UEFI HTTP Boot のクライアントがこの Mac から直接 iPXE を読み込めるようにします。

残るのは、起動するマシンの行き先を DHCP サーバに伝えることです。DHCP server を選んで Copy Settings を押すと、そのまま使える設定例がコピーされます：

DHCP サーバ	使う場面
dnsmasq	dnsmasq が DHCP サーバの場合。TFTP サーバも内蔵しています。
dnsmasq (proxy-DHCP)	ルータがアドレス配布を続け、dnsmasq は PXE クライアントにだけ応答する場合。
ISC dhcpd · Kea	自分で編集する Linux の DHCP サーバ。
OPNsense / pfSense	ファイアウォールが DHCP サーバの場合。設定例はネットワークブート欄の項目名で示します。
UEFI HTTP Boot (no TFTP)	ファームウェアが TFTP を使わず、この Mac から HTTP で iPXE をダウンロードする場合。

8.22.17内蔵 PXE サーバ

ネットワークに dnsmasq がなく、DHCP サーバも変更したくない場合は、ネットワークブート設定のこの Mac から PXE クライアントに応答をオンにします。配信中、Mac は 2 つの小さなサービスを動かします：

• ProxyDHCP（UDP 67 と 4011）は、ネットワーク起動を求めるマシン（PXE ファームウェア、UEFI HTTP ブート、iPXE）にだけ、ブートファイルだけを返します。アドレスは配らないため、ルータの DHCP はこれまでどおり動作します。
• TFTP（UDP 69、読み取り専用）は 3 つの iPXE ローダだけを配信します。BIOS マシンには undionly.kpxe、UEFI x64 マシンには ipxe.efi、ARM64 マシンには ARM64 版 ipxe.efi を渡します。UEFI HTTP ブートのクライアントには HTTP でローダを渡します。iPXE が起動すると、もう一度問い合わせてメニューを受け取ります。

応答するネットワークを選び（サービスはその 1 つのインタフェースにだけ結び付けます）、必要なら応答するマシンの MAC アドレスを指定します。各要求と転送はスイッチの下に表示されます。ローダは初回に自動でダウンロードします。pf またはアプリケーションファイアウォールがオンの場合、サーバセクションのファイアウォールボタンで UDP 67・69・4011 も開放します。

8.22.18その他の KVM-over-IP 機器

JetKVM のファームウェア。JetKVM、JetKVM Mini、Mini W では、リモート KVM にインストール済みのファームウェアとアップデートの有無が表示されます。FrontierStack はログインなしで KVM の Web インターフェイスからバージョンを読み取り、最新リリースを JetKVM のアップデートサーバに問い合わせ、30 分ごとに再確認します。0.5.4 より前のファームウェアは、ダウンロードしたアップデートが本当に JetKVM のものか検証しないため（CVE-2026-32294）、要アップデートと表示されます。JetKVM で MQTT をオンにしてベーストピックを入力すると、代わりに KVM 自身のアップデート状態と、オンライン状態・CPU・温度・メモリ・ストレージを読み取ります。JetKVM は通常アップデートを自分でインストールしますが、自動アップデートがオフの場合や常に誰かがコンソールに接続している場合は保留のままになります。KVM の行の通知するをオンにすると、応答しなくなったとき、脆弱なファームウェアのとき、アップデートが 1 週間以上保留されているときにアラートします。

KVM のストレージ。小型 KVM の多くは SD カードまたは内蔵 eMMC から動作し、カードの消耗は起動しなくなる原因としてよくあります。各 KVM のストレージセクションには、動作元（microSD・SD・eMMC・USB・SSD）、容量、カードのメーカーとモデル、取り付け日、予備の保管場所などのメモを記録します。3 年以上使っている着脱式カードには消耗の警告を表示します。PiKVM では PiKVM から読み取るで、ATX 電源と同じ API アカウントを使ってカードのイメージパーティションの空き容量を表示します。JetKVM のストレージ使用率は MQTT をオンにすると表示されます。FrontierStack がカード自体を読み書きすることはありません。

JetKVM・GL.iNet Comet・NanoKVM・TinyPilot・Raritan・ATEN・Avocent・Lantronix・Adder には、仮想メディア用の安定した公開 API がありません。そのため FrontierStack は操作できるふりをしません。代わりに Copy URL が配信を開始して KVM から到達できるイメージアドレスをコピーし、ペインはそのベンダ自身のコンソールのどこに貼り付けるかを示します。

8.22.19Mac

Mac はインストーラ ISO から起動できず、ネットワークブートももうありません：Apple シリコンにはそもそもなく、Intel の NetBoot は macOS Server 5.7 でサーバ側を失い、T2 搭載 Mac は「完全なセキュリティ」ではこれを拒否します。そこで Mac については、Apple がサポートする方法で macOS をインストールします — Apple のフルインストーラを SSH 経由でその Mac 自身にダウンロードし、実行します。フリートの各リモート Mac にカードが表示されます（先に Remote Servers で Mac を追加してください）：

• Refresh は macOS のバージョン、Apple シリコン・Intel・T2 付き Intel の別、モデル、空き容量、既存のインストーラ、コンテンツキャッシュの状態を読み取ります。
• List は利用可能なフルインストーラを Apple に問い合わせ（softwareupdate --list-full-installers）、Download on その Mac はバックグラウンドで進捗付きに取得します（--fetch-full-installer）。
• Install… は startosinstall を 2 つのモードのどちらかで実行します：Upgrade / reinstall (keeps data)（アップグレード／再インストール、データは保持）または Erase and install（消去してインストール）。Apple シリコンではボリューム所有者しかインストールを開始できないため、管理者ユーザとそのパスワードを入力します。パスワードは標準入力で startosinstall に渡され、保存されません。
• Turn On Content Caching（この Mac または任意のフリート Mac）は Apple のアップデートとインストーラのコピーを LAN 内に保持し、他の Mac が Apple からではなくそこからダウンロードするようにします。
• KVM をリンクした Intel Mac では、Internet Recovery… が確認のうえで Apple 自身のネットワークリカバリへ再起動します。リカバリには画面共有も SSH もないため、操作には KVM が必要です。

8.22.20AI 管理者から

AI 管理者と MCP クライアントは、既存の kvm ツールで Boot Media を使えます：media_list（読み取り専用）はライブラリ、メディアサーバの状態、各コントローラの電源とマウント中のイメージ、各 PiKVM のドライブを報告します。media_attach は対象 — 名前で指定するコントローラや PiKVM、または proxmox:<vmid> — にイメージをマウントし、boot=true ならそこへの再起動も行います。media_eject は取り外します。接続・取り出し・再起動には Allow changes が必要で、必ず確認を求めます（第 13 章）。

8.22.21シリアルコンソールでのインストール

アプライアンス、UP Squared のような小型 x86 ボード、コンソールポートしか配線していないサーバには、インストールに使える画面がありません。インストーラをシリアルで動かす必要があります。ブートメディアでシリアルコンソールでインストールをオンにし、マシン側のポート（ttyS0〜ttyS7。UP Squared のデバッグ UART は ttyS4）と速度（9600・19200・38400・57600・115200 bps、対応する UART とアダプタなら 230400〜921600）を選びます。以後 iPXE メニューは、netboot.xyz から起動するすべての Linux インストーラに console=tty0 console=ttySn,baudn8 を設定し、netboot.xyz に画面消去コードを送らないよう指示します。

ISO 自身のブートメニューは外から変更できないため、インストーラごとに正確な編集内容を示します。Ubuntu、Debian（設定がインストール後のシステムにも引き継がれるよう --- の後ろに追加）、Rocky／Alma／RHEL（inst.text 付き）、その他の Linux ISO の GRUB／ISOLINUX カーネル行、Proxmox VE の Terminal UI, Serial Console 項目（ttyS0・115200 固定。別のポートや速度は編集）、pfSense の memstick と OPNsense のシリアル用イメージ（別の速度なら FreeBSD ローダのコマンド）、シリアル用のセットアップがない Windows にはインストール後の EMS コマンドです。インストール後のシステム用 GRUB 設定をコピーで、インストール後もシリアルに出力し続けるための /etc/default/grub の行が得られます。n bps でコンソールを開くは、この Mac に挿した USB アダプタで同じ速度のセッションを開き、速度の異なる保存済みコンソールはワンクリックで合わせられます。

8.15Proxmox VE：クラスタのライブ状態とゲストの電源

Proxmox VE ホストはサーバを詰め込んだサーバであり、ノードへの SSH だけではゲストのことはあまりわかりません。そこで Proxmox VE のサービスページ（Containers カテゴリ。第 6 章を参照）は Proxmox 自身の API と通信します。Add Connection でクラスタまたは単一ノードのアドレスと API トークンを入力します — user@realm!name 形式のトークン ID とシークレットで、シークレットは Keychain に保存され、Authorization ヘッダでのみ送信されます。Proxmox の自己署名証明書は、プライベートアドレスの場合に限り受け入れます。状態の確認だけなら PVEAuditor ロールのトークンで十分です。電源操作とブートメディアには、前述の追加権限が必要です。

接続すると、クラスタ名・Proxmox のバージョン・クォーラム、ノードごとの CPU・メモリ・ルートディスク・稼働時間、すべての VM とコンテナとその状態、ストレージごとの使用率バーが表示されます。各ゲストは起動・シャットダウン・再起動ができ、確認のうえでハード停止・リセットもできます。Show in Server Activity と Boot an ISO… で、Proxmox が現れる他の 2 か所へ移動できます。

サーバアクティビティウィンドウ（第 11 章）では、各ノードが All Servers・Cluster・Everything の各レイアウトにタイルとして表示されます。CPU・メモリ・ディスク・稼働時間のスパークラインと、「5/7 VMs · 2/3 containers running」のような行が付きます。ノードの詳細には KPI、CPU とメモリのグラフ、同じ電源操作付きのゲスト一覧、ストレージ、クラスタ情報が表示され、Open Web UI・Refresh・Boot an ISO… ボタンもあります。

アラートは各接続をバックグラウンドで約 5 分ごとに更新して監視します：API への到達性、各ノードのオンライン状態、クラスタのクォーラム、使用率 90% を超えたストレージ。AI 管理者も kvm ツールの proxmox_status アクション（読み取り専用）で同じ情報を見られ、proxmox_power でゲストの電源を操作できます（必ず確認を求めます）。

8.16Garage：オブジェクトストレージのクラスタをひと目で

Garage は、データを複数の小さなノード（多くは別々の場所）に分散させる軽量な S3 互換オブジェクトストアです。Garage のサービスページ（オブジェクトストレージのカテゴリ）は、Garage の管理 API を使って複数の Garage クラスタを監視します。クラスタを追加し、いずれかのノードの管理エンドポイントと管理トークンを入力します。LAN ではポート 3903 と平文 HTTP を前提にするので、10.0.0.5:3903 だけで足ります。1 つのノードがクラスタ全体の状態を報告します。別のノードを2 つ目のエンドポイントとして追加しておけば、1 つ目が停止してもクラスタを確認できます。トークンは Keychain に保存し、Authorization ヘッダでのみ送信します。平文の HTTP はプライベート・Tailscale・.local のアドレスに限り、それ以外は https:// が必要です。Garage 2.x（管理 API v2）と 0.9／1.x（v1）のどちらにも対応します。

セクションの最初の行で、すべてのクラスタを正常・要確認・停止に分けて数えます。続いて各クラスタの状態 — healthy、degraded（本来より複製の少ないデータがある）、unavailable（読み書きできないデータがある）— を、接続中のノード数、稼働中のストレージノード数、クォーラムのあるパーティション数と完全に複製されたパーティション数、レイアウトのバージョン、ゾーン、割り当て容量とともに表示します。その下に全ノードを、停止中のノードと使用率の高いディスクを先頭にして並べます：ゾーン、容量、Garage のバージョン（他と異なるバージョンのノードは強調）、ドレイン状態、データ／メタデータディスクの使用率。/metrics も読み取るをオンにすると、登録したノードで再同期に失敗したブロック数（常に 0 であるべき値）も数えます。

アラートは各クラスタを約 5 分ごとに確認します：管理 API への到達性、クラスタの状態、レイアウト内の各ノード、クラスタのしきい値（変更しなければ 90%）以上のデータ／メタデータディスク、エラーになったブロック。AI 管理者は get_server_health の area object_storage で同じ内容を読み取ります。ここからクラスタを変更することはありません。

8.17古い Mac・Raspberry Pi・Windows ホスト

フリートの意義のひとつは、古い・風変わりなハードウェアを活かし続けることです。いまも macOS Server が動く旧来の Xserve や Mac mini は他のホスト同様に連携できます。リモート Apache 検出は Server.app 独自の Apache ツリーと内部ポートを理解するので、その Web サイトが表示され編集でき、モニタのレガシー Intel ビルドは OS X 10.11 El Capitan までさかのぼって動きます。棚いっぱいの Raspberry Pi は通常の Linux として連携できます。モニタの arm ビルドは Zero を含む全 Pi を網羅するので、CPU・ディスク・サービスを他のすべてと並べて監視できます。

Pop!_OS などの Ubuntu ベースのシステムは、OS 名に含まれる「Linux」という語ではなくディストリビューションで判別します。Pop!_OS は「Pop!_OS 24.04 LTS」と名乗るため、以前のリリースでは Linux と認識されず、（一部の Ubuntu と同様に）モニタの自動更新が拒否されていました。apt 系では、サーバのパッケージツール（Manage in Server Activity…）のアップデートを確認が、apt だけでは分からない次の情報も報告します：インストール済みでまだ起動していない新しいカーネル（Pop!_OS や一部の Debian のように /var/run/reboot-required が作られない環境でも検出）、EFI システムパーティションの空き容量 — Pop!_OS は systemd-boot で起動し、kernelstub がカーネルと initrd をすべてここへコピーするため、容量不足はカーネル更新が途中で失敗する典型的な原因です — そして Flatpak アプリの更新数。

Windows ホストは Microsoft の OpenSSH サーバ経由で参加します。SSH 診断のために Linux 同様に連携し、モニタはネイティブの Windows サービスとしてインストールします（Windows サービスはマシン環境変数を確実には継承しないため、設定は実行ファイルの隣のファイルから読みます）。Windows のモニタインストールは自動プッシュではなく、Host Monitor ペインから付属の PowerShell インストーラで手動で行います。

診断を超えた対話的な制御には、カタログにリモートアクセスツール（RustDesk・MeshCentral・Apache Guacamole・Windows Remote Desktop・WinRM）も揃っていますが、それらは SSH フリート自体ではなく運用するサービスです。フリートの強みは、すべてを 1 つのウィンドウから均一・スクリプト可能・低負荷で管理できることであり、第 13 章の run_script でノードを名前で指定すれば、AI がリモートサーバを 2 段階で診断・修正できます。読み取り専用のテスト、続いて最小限の修正、そして再実行で確認です。

UP Squared などの UP ボード。AAEON の UP ボード（UP Squared、UP Squared Pro／V2／6000／Pro 7000、UP 7000、UP Xtreme）は、ファイアウォール、Proxmox ノード、Linux 機としてヘッドレスで使われることの多い小型 x86 マシンです。ほかの Linux ホストと同じように連携でき、ステータスチェックがボードのファームウェア識別情報（DMI。シリアル番号は読み取りません）を読むため、サーバのページにモデル名、3.3 V デバッグ UART の位置と Linux での ttyS 名（UP Squared は ttyS4、初代 UP Xtreme は ttyS5）、ファームウェアのキー（F7 でブートメニュー、Del または Esc でセットアップ）、PXE を有効にする BIOS の場所が表示されます。コンソール接続には対応する UP Squared／UP ボードのプリセットがあり、デバイス検出は AAEON の MAC プレフィックスを認識し、あとはブートメディアのシリアルコンソールでのインストールで進められます。同じチェックでほかのハードウェア（Dell・HPE・Supermicro のサーバ、Raspberry Pi のデバイスツリー上のモデル名）も表示します。

8.18グループポリシーとドメインの信頼関係

Windows ドメイン向けのグループポリシーと信頼関係ペイン（ID とアカウントの下、フルフリート）は、連携済みのドメインコントローラを SSH で読み取ります。Windows Server の DC にはグループポリシーの管理機能と AD PowerShell モジュールが必要です（通常の DC には両方あります）。Samba AD の DC は samba-tool で読み取り、サーバの sudo パスワードを保存してあれば ldbsearch で各 GPO のリンク先も表示します。ペインには 3 つのタブがあります。

タブ	表示内容
概要	ドメイン、フォレスト、NetBIOS 名、機能レベル、PDC エミュレータ、ドメインコントローラ、SYSVOL の複製方式（DFSR または廃止済みの FRS）、すべての検出事項。
グループポリシー	すべての GPO とそのリンク（強制は鍵アイコン、無効なリンクは取り消し線）、ユーザ／コンピュータの設定が無効かどうか、バージョン番号、WMI フィルタ。
信頼関係	すべての信頼関係：種類（フォレスト、外部、親子、レルム）、方向、推移性、セキュアチャネルのテスト結果、セキュリティ設定。

検出する内容。グループポリシー：Active Directory と SYSVOL のバージョンが一致しない GPO（続くなら複製が壊れています）、SYSVOL がまだ FRS か DFSR への移行途中、既定のポリシーがないかリンクされていない、情報としてリンクのない GPO・空の GPO・すべて無効の GPO。信頼関係：セキュアチャネルが失敗する信頼関係（Windows は nltest /sc_query、Samba は samba-tool domain trust validate）、外部信頼で SID フィルタリングがオフ、フォレスト信頼で SID 履歴を許可、信頼関係をまたぐ TGT 委任、RC4 のみの信頼関係、下位レベル（NTLM）の信頼関係、選択的認証ではなくフォレスト全体の認証を使う双方向の信頼関係。受信のみの信頼関係は相手のドメインからしかテストできません。

操作（Windows の DC のみ）：レポートは GPO の全設定レポート（Get-GPOReport）をブラウザで開きます。すべての GPO をバックアップ…は DC 上の ProgramData\FrontierStack\GPOBackups の下に日付付きフォルダを作って Backup-GPO を実行します。コンピュータで強制更新…は 1 台のドメインコンピュータに Invoke-GPUpdate を実行します。FrontierStack が GPO や信頼関係を作成・編集・リンク・削除することはありません。

アラートで監視をオンにすると DC を 30 分ごとに確認し、信頼関係の失敗や DC の無応答をディレクトリサービスのアラートとして通知します。AI 管理者は get_server_health の area=domain で同じ状態を読めます。

8.19OpenCore Legacy Patcher の Mac：アップデートしても安全か

古い Intel Mac の中には、OpenCore Legacy Patcher（OCLP）のおかげで Apple が提供したことのない新しい macOS を動かしているものがあります。これは「再起動」の意味を変えます。通常のサーバ Mac は電源 → macOS → FrontierStack エージェントで起動しますが、OCLP Mac は電源 → ファームウェア → EFI/OpenCore → macOS → OCLP ルートパッチ → FrontierStack と起動します。リンクが増えるぶんだけ、無人起動が止まる場所も増えます。macOS アップデートは封印されたシステムボリュームを置き換えてルートパッチを消してしまい（再適用するまで Wi-Fi・グラフィックスアクセラレーション・Bluetooth が消えます）、メジャーアップグレードには先に対応する OCLP リリースが必要で、ファームウェアの起動エントリが OpenCore を指さなくなれば、誰かが Option を押して「EFI Boot」を選ぶまでブートピッカーで止まります — その Mac が別の建物にあれば、なおさら厄介です。

OpenCore Patcher ペイン（フリートとリモート）は、アップデートを押す前にそれを知るためにあります。この Mac か連携 Mac を選ぶと読み取り専用のプローブを実行し — OCLP アプリのバージョン、OpenCore の NVRAM スタンプ（実際に OpenCore 経由で起動したときだけ存在）、ルートパッチの記録、bless --getBoot、SIP、ソフトウェアアップデート設定、OpenCore が偽装したモデルの背後にある実機モデル — それをリモート起動の安全性リストにまとめます：ファームウェアの起動エントリ → OpenCore、デフォルト起動ボリューム設定済み、FileVault が無人再起動に与える影響、ルートパッチが存在し最新、OCLP リリースがインストール済み macOS に対応（GitHub の最新リリースと照合）、保留中の macOS アップデート、macOS 自動インストールがオフ、EFI/OpenCore のバックアップ。その上にひとつの判定が表示されます：macOS をアップデートしても安全、注意してアップデート、安全ではない — 理由付きで。

[[FIG id="oclp-pane" caption="OpenCore Patcher ペイン：判定、リモート起動の安全性チェックリスト、3 つの管理者アクション。" capture="保留中のアップデートとルートパッチありの OCLP MacBook Pro に対する OpenCore Patcher ペイン。"]]

このペインは意図的に OCLP を管理しません — OpenCore の構築とルートパッチの適用は OCLP 自身のアプリの役目のままです。提供するのは固定で可逆な管理者アクション 3 つだけ：macOS の自動インストールをオフ（システム設定が OCLP Mac を無人でアップデートしないように）、EFI をバックアップ（EFI/OC フォルダのアーカイブをその Mac に保存）、OpenCore を再 bless（OCLP の「Install to disk」と同じ bless --setBoot。OpenCore.efi が実在しなければ拒否）。フリートのステータスプローブもピン留めしたすべての Mac で OCLP を検出します。ホスト行とサーバアクティビティウィンドウに表示され、ルートパッチが欠けているか起動エントリが OpenCore を迂回している場合はアラートにセキュリティ項目が上がります。

8.20ビルド Mac：サーバでの Xcode ビルド

Xcode のビルドボタンは、いつも目の前の Mac でビルドします。コア数が多く、署名環境が安定し、誰のエディタも開いていないラックの Mac mini など別の場所でビルドしたいときは、連携中の Mac にビルド Mac の役割を与えます（フルフリートの機能）。サーバペインまたはサーバの編集画面のスイッチをオンにすると、ペインにビルド Mac の項目が加わります。

この項目には、その Mac がビルドに使える環境が表示されます。30 分ごとに SSH で読み取り専用で確認します：インストール済みの Xcode と選択中のもの、ライセンスへの同意と初回起動コンポーネントの有無、空きディスク、DerivedData・アーカイブ・シミュレータの容量、シミュレータランタイム、期限付きのコード署名証明書すべて。問題はアラートのビルド Mac に出ます：Xcode が無い、ライセンス未同意、空きが 30 GB 未満（変更可）、14 日以内に期限が切れる証明書。

プロジェクトはサーバごとに保存します：git の URL・ブランチ・プロジェクトまたはワークスペース（任意）・スキーム・デスティネーション。ビルド・テスト・アーカイブは、ビルド Mac の ~/fs-builds にリポジトリをクローンまたは更新し、コンソールで xcodebuild を実行します。ログはすべて目の前に表示され、途中で止めることもできます。ビルド Mac 自身がリポジトリにアクセスできる必要があります。SSH 越しの署名はロックされたキーチェーンを使えないため、アーカイブはまずログインキーチェーンのロックを解除します。

2 つのセットアップで本格的なビルドサーバになります。Gitea ランナーを設定は act_runner をインストールし、Gitea に登録して、ラベル macos-xcode で常駐させます。登録トークンはコンソールに貼り付け、FrontierStack は保存しません。あとはワークフローに runs-on: macos-xcode と書けば、プッシュのたびにビルドとテストが走ります。かつて Xcode Server が担っていた仕事です。ヘッドレス Xcode MCP をオンは Xcode 27 の xcrun mcp-server をビルドフォルダ用に有効にし、コーディングエージェントが Xcode のウインドウなしでその Mac の Xcode ツールを使えるようにします。

8.21移行ウィザード：スタックを新しいデバイスへ

古いサーバの引退が「すべて手作業で再インストール」を意味することは、もうありません。FrontierStack はレガシーマシンからスタックを取り出し、選んだ移行先——この Mac、別の Mac、あるいは Linux——に立ち上げる移行ウィザードを備えています。移行元は読み取るだけで、書き込みはすべて移行先に対して行います。

セットアップを移行は移行元から始まります：この Mac で見つかったスタック（MAMP、XAMPP、Pancake Stack）、Apple Server（Server.app マシン全体。後述）、Windows、Web サーバ（ほかの Web サーバ、開発ツール、開発サーバ）、その他のツール（Web サイト以外のもの：ほかのアプリのデータベース、Git サーバ、hosts ファイルやリポジトリ）。どれも作業の順に進み——移すもの、移行先、移す——最後にすべて確認してから廃止します。「古い Mac サーバのモダナイズ」の Apple の PHP の停止と同じく、名前を挙げて確認するまでは何も廃止できる状態になりません。読み込んだ各サイトのすべてのページとファイルを新しい Apache から取得し（ページは状態と PHP ソースで、普通のファイルは移行元のコピーとバイト単位で比較）、すべてのデータベーステーブルの行数を移行元と比べます。フォルダの index ページ以外のスクリプトは開きません（開くと実行されることがあるため）。違うものや確認できなかったものは名前で一覧表示し、確認が通るまで古い環境を残すよう案内します。別のデバイスへの移行ではファイル（rsync のチェックサム）とテーブルを同じようにコンソールで比べ、ほかのデータベースアプリからのコピーもテーブルごとに確認します。

Migrate Setups ペインは MAMP・XAMPP・Apple Server.app の Web スタックを扱います。移行元を自動検出し、何を引き継ぐかをチェックで選べます。Homebrew ツール、Web ファイル、MySQL データベース、サイト（vhost）、MIME の上書き、Apache モジュール、PHP 設定、WordPress の wp-config.php 修正、Git リポジトリなどです。Set up on ピッカーで移行先を選択します。This Mac のままならアプリ内で完全移行し、連携ホストを選べば SSH 経由でその新しいデバイスにスタックをインストールし、Web ファイル（rsync）とデータベース（SSH 経由のダンプ）をコピーします。Linux トグルで Homebrew の代わりに apt/dnf を使います。

その他のツール ▸ サーバと設定にはリポジトリからインポート…もあります。SSH 設定、Ansible インベントリ、.env ファイルを含むフォルダや git リポジトリを指定すると、確認のうえでサーバをフリートに、認証情報をスクリプトシークレットや対応するサービスに追加します。それ以外の形式は、値を一切見ることなく FrontierStack AI が読み取れます（第 13 章）。

ほかのツールから移行する場合は、Web サーバや開発ツールから読み込む…（セットアップを移行 ▸ Web サーバと、Apache ペインのサイトを読み込み…の隣）を使います。Laravel Herd・Laravel Valet・ServBay・AMPPS・DesktopServer・Devilbox・DDEV・Docksal・Lando・Local・DevKinsta、Web サーバ自身の設定ファイル（Caddy・nginx・Lighttpd・OpenLiteSpeed・H2O・Cherokee・Abyss・Tomcat・Jetty・WildFly/Undertow・CivetWeb・Mongoose）、そしていま動いている開発サーバ（Python http.server、Uvicorn、Gunicorn、Waitress、Vite、webpack-dev-server、BrowserSync、http-server、live-server、miniserve、Node.js、Bun、Deno）から、サイト・設定・データベースを読み込みます。各サイトはポート 80/443 の Apache サイト（ファイルを配信するか、動き続けるアプリサーバへ転送）または Localhost プロジェクトになります。ドメイン・エイリアス・HTTPS 証明書・リダイレクト・プロキシのパスを引き継ぎ、読み込む前にドメイン名を変えることもできます。データベースタブは、この Mac で動いている MySQL・MariaDB・PostgreSQL サーバ（DBngin、Herd、ServBay、MAMP、Local など）をすべて見つけ、選んだデータベースをそのサーバ自身のツールでダンプして、FrontierStack の Homebrew MySQL または PostgreSQL に読み込み、すべてのテーブルの行数を移行元と比べます（その他のツール ▸ データベースをコピー…から単独でも使えます）。Docker ベースのプロジェクト（DDEV・Lando・Docksal・Devilbox・DevKinsta）は各ツール自身のコマンドで書き出します。オプションで、コピーした各サイトの wp-config.php または .env を FrontierStack の MySQL に向けることもできます（.pre-migrate.bak のコピーを残します）。

Windows から移行する場合は、C:\laragon フォルダ全体を Mac にコピーし（USB ドライブ、共有フォルダ、Parallels/VMware の Windows ディスク、ZIP）、セットアップを移行 ▸ Windows ▸ Windows のスタックから読み込む…を使います。同じ読み込みで Windows 版 XAMPP、WampServer、AMPPS、Uniform Server、IIS もフォルダのコピーから読めます（IIS は applicationHost.config と各サイトのフォルダもコピー）。バーチャルホストのないフォルダは <フォルダ>.test になり、ASP.NET のサイトは参考としてコピーされます。www の各プロジェクトと etc/apache2/sites-enabled の各バーチャルホストが、Laragon のホスト名（{name}.test または独自のテンプレート）の Apache サイトになり、Windows のパスはコピー先に変換されます。Laragon の data フォルダは Mac では再利用できないため、先に PC で各データベースをエクスポートし（HeidiSQL ▸ SQL としてデータベースをエクスポート）、Laragon フォルダかサイトのフォルダに保存してください。サイトに対応付けられ、データベースタブで読み込めます。

セットアップを移行 ▸ Apple Server（以前の Apple Server Migration ペイン）は Server.app マシン全体を扱います。移行元（この Mac またはリモート）を指定すると、serveradmin で全サービス——Websites・Mail・Calendar と Contacts・Messages（XMPP）・VPN・DNS・DHCP・NetInstall・Open Directory・File Sharing・Time Machine・Profile Manager ほか——に加えて、稼働中の git サーバ・データベース・Docker・単体の Nginx なども棚卸しします。各サービスに状態バッジと現代的な代替が示され、妥当な代替が複数ある場合（Calendar → Radicale／SOGo／Baïkal、VPN → WireGuard／strongSwan、DHCP → dnsmasq／Kea）はどれを使うか選べます。移行先マシンと OS を選ぶと、代替をインストールし、正確な引き継ぎチェックリストを表示します。この Mac の Web サイトも同じ場所で移し（vhost とファイルの完全コピー）、廃止する前に同じ確認を行います。サービスの実行がコピーした DNS ゾーンファイルも名前を挙げて移行元と比べます。Open Directory（ユーザとグループ）はアカウントペインへ、検出された git サーバは Git Server 移行へ引き継ぎます。Mac を手放さずに残すなら「古い Mac サーバのモダナイズ」（第 4 章）を使います。

サイトビルダーから移るには。 セットアップを移行 ▸ サイトビルダー ▸ STUDIO から読み込む…は、書き出し機能のない STUDIO（studio.design）のサイトを移します。サイトのアドレスを入力すると、FrontierStack はサイトがすべての訪問者に見せている内容を読み（STUDIO へのサインインは不要）、ページ、CMS アイテム（記事として。日付、カバー画像、カテゴリ、タグつき）、画像を、この Mac の新しい WordPress サイトに追加します。FrontierStack が WordPress をダウンロードし、サイト専用のデータベースと MySQL ユーザを作成し、その名前の Apache サイトを追加してインストールします（WordPress ペインにすでにあるサイトも選べます）。古いアドレスからのリダイレクトも用意します。新しい STUDIO サイトは完成したページから読み、空のページとして届く古いサイトは、訪問者のブラウザと同じリクエストで STUDIO の公開ストレージと CMS サービスから読みます。デザイン、アニメーション、共有のヘッダーとフッター、フォーム、フォントは取り込まれず、読み込みの最後にそのチェックリストが表示されます。新しいサイトの準備ができたら、ホストに公開…で「サイトの複製」が開き、サイトとデータベースを STUDIO サイトと同じアドレスでサーバまたはホスティングアカウントにコピーする設定になります。WordPress のコピーには、その場所専用のデータベースログインを書いた新しい場所用の wp-config.php が用意されます。読み込みの実行にはライセンスが必要ですが、サイトの確認には不要です。

8.22Git サーバ：Gitea とリポジトリ移行

Git Server ペインは、任意の移行先——この Mac、連携サーバ、NAS、Docker ホスト、Linux——にセルフホストの Gitea（自動 HTTPS のため Caddy 背後）を立ち上げます。プラットフォームを検出して適切な方法でインストールします。稼働後はアクセストークンで接続すると、バージョン・リポジトリ数のライブ監視と、ミラーが元から遅れたときのバックアップ鮮度アラートが得られます。

同じペインで別の Git サーバを Gitea へ移行・ミラーできます。ディスク上のベアリポジトリ——レガシー macOS アプリ Simple Git Server、Xcode Server、Gitolite、素の git-daemon、任意のフォルダ——か、稼働中のリモートサーバ（git://・https://・ssh:// の任意のクローンベース。リポジトリ名は SSH で列挙するか貼り付け）を指定します。Scan でリポジトリを一覧し、Migrate で各リポジトリを全履歴・全ブランチ・全タグごとミラークローンし、API でリポジトリを作成して Gitea へ push します。コピーはこの Mac 上で実行されます。