第 III
サーバを 1 つのフリートにまとめ、Mac・Linux・BSD・Raspberry Pi・Windows をひとつのウィンドウからネットワーク化・堅牢化・監視します。
第 8
サーバ連携：ロケーションとフリート
1 台の Mac は始まりにすぎません。FrontierStack は SSH で運用中の全サーバに手を伸ばし、そのとき自分がネットワーク上のどこにいるかも把握します。
ここまでは目の前の 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.16.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 専用センサーなど）。オレンジは「消えた」ではなく「ここからは確認できない」という意味です。
これらすべての狙いは「ロケーション依存の監視」セクションです。Overview ▸ Alerts でデバイス・Wi-Fi・Cloudflare ゾーン・ウォッチを重要としてマークし、ここで「Office のときのみ」に絞ります。そのチェックは他の場所では一時停止され、ホテルから NAS が DOWN と鳴ることも、職場で自宅 Wi-Fi が失われたとアラートが出ることもありません。一時停止された項目は戻れば静かに再開します。ロケーション自体が変わったときは、ローカル通知の表示、Messaging Gateways 経由の「📍 Now at: Office」アラート送信、またはその両方が可能です。
get_location ツールでこれを読めます。アクティブなロケーション、判定方法（固定か自動検出か）、ライブのスナップショット、そして設定済み各ロケーションの条件です。これを使って、LAN 限定サービスが今いる場所から到達可能か、VPN で外出中かを推論します。8.2SSH によるサーバ連携
サーバは「Link a Server」シート（デバイスのペイン・Device Discovery・Cloud Servers／Remote Tools ペインから開けます）でフリートに加わります。名前、ホストまたは IP、ポート、SSH ユーザ名（root・ubuntu・ec2-user など）、ログインパスワードを入力します。そのパスワードは一度だけ使われます。アプリがこの Mac の管理対象 SSH 鍵をサーバの authorized_keys に入れ、以降は鍵のみで接続します。保存されるのはサーバのアドレスだけで、パスワードは破棄されます。
パスワードログインのない鍵専用サーバでは、「パスワードが使えない場合は鍵を手動でインストール」を展開し、表示された公開鍵を自分で authorized_keys にコピーしてから連携します。「監視ヘルパーも併せてインストール」にチェックを入れると、同じ手順でホストモニタを設定できます（後述）。
連携サーバには到達性を示す小さな緑／赤のステータスドットが付きます。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）。
repair_ssh_access ツールは一度きりのパスワードをローカルの .env ボールトから名前で読み取り、値が AI モデルに送られることはありません。8.3管理対象鍵と保存された sudo パスワード
鍵アクセスでアプリは接続できますが、多くの有用な操作（/var/log の読み取り、Apache 設定の編集、ファイアウォールのリロード）にはサーバ上の root が必要です。FrontierStack はホストごとの sudo パスワードでこれを扱い、macOS キーチェーンに保存します（平文ファイルには決して書きません）。サーバ連携時に自動取得され、後からホストのペインや Remote Tools のターゲットセクション（Sudo password 欄）で設定・変更できます。
root 限定のコマンドを実行するとき、ヘルパーは SSH セッション越しに保存済みパスワードで sudo の資格情報キャッシュを準備してからコマンドを実行します。パスワードが保存されていない場合、root 操作はパスワード不要の sudo -n にフォールバックし、それも未設定なら単に「needs sudo」と報告します。秘密情報は名前で参照されるため、複数を保持できます。たとえばサーバごとに異なる MySQL パスワードを .env ボールトに置けます。
sudo -S へ渡され、AI モデルに表示されることもログに書かれることもありません。欄を空にすれば失効でき、1 台だけ再登録・再鍵化しても他には影響しません。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。手早いデプロイ。 |
| カスタムコマンド | 選択した全ホストでシェルコマンドをそのまま実行。展開前に必ず確認。 |
Fleet Run はドリフトを見つける最速の手段です。ディスク使用量や稼働時間と負荷を実行してホストをひと目で比較するか、次の Remote Tools にあるファイルチェックサムやヘルスチェックで、フリート間で食い違った設定を見つけられます。
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 のコマンドがそのまま表示され、コピーできます。作成時はまずイメージを取得し（オフにもできます）、続いて実行して出力をシートに表示します。
docker グループにいない場合、パスワード不要の sudo docker にフォールバックします — 新しい Linux サーバでの最初の試行が権限エラーになる典型的な原因です。8.16.2モニタとしての Containers ボード
Containers ペインは一覧であるだけでなく、この Mac のすべてのランタイムを 1 つの判定にまとめたステータスドットを持ちます。サイドバーを一目見れば、対応が必要かどうかが分かります。緑はインストール済みのものがすべて正常、オレンジは停止中または確認中、赤はインストール済みエンジンの停止、あるいはコンテナの unhealthy・再起動ループ・エラー終了です。一度もインストールしていないランタイムは異常とは見なしません — つまり緑は「すべて実行中」ではなく「存在するものがすべて正常」を意味します。
セクションの並びはサービス一覧と同じで、Apple Containers、Docker、Kubernetes、OrbStack、コンテナマシン、Vagrant の順です。Kubernetes はここでは読み取り専用で、Kubernetes Clusters でピン留めしたクラスタを表示します。ピン留めとクラスタごとの操作は同ペインに残ります — そちらはこの Mac の中だけでなく、どこで動いているクラスタでも監視するためです。未インストールのランタイムでは、ダウンロードページではなく導入用のペインを開くボタンが表示されます。
ヘッダのピンボタンは、小さなフローティングパレットを開きます。全体のドットと実行数を示すステータスバーが 1 行あり、その下に実行中のものの短い一覧、さらに設定済みで待機中のものを Waiting としてまとめます。画面の隅に置いたまま別の作業ができるよう、意図的に小さくしてあります。行をクリックすると、メインウインドウがその項目へ移動します。
8.16.3Docker Swarm
Swarm は別途インストールする製品ではなく、Docker エンジンに組み込まれています。FrontierStack が専用ペインを設けず Docker ペインから監視するのはそのためです。表示中のエンジンが swarm に参加していると Docker Swarm セクションが現れ、クラスタのノード（Ready か Down か、drain 中か、どれがマネージャか）とサービスをレプリカ数とともに一覧します — 必要なタスクがすべて揃っていれば 3/3、足りなければ 1/3 のように表示されます。サーバアクティビティウインドウの Docker タブにも Swarm セグメントとして同じ内容があり、連携サーバからクラスタを確認できます。
状態はペインがエンジンの健全性確認で既に実行している docker info から取得するため、swarm に参加していないマシンでは追加のコストがかかりません。表示内容を左右する Swarm の規則がひとつあります — クラスタを一覧できるのはマネージャだけです。ワーカーに尋ねてもデーモンが拒否するため、FrontierStack は失敗に見える空の表ではなく、その旨をはっきり表示します。
8.16.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 で済むのはそのためです。
docker compose up -d を実行することです — FrontierStack が何かを隠しているわけではありません。container CLI には compose 相当がなく、カスタムネットワークではまだ他のコンテナを素の名前で解決できないため、スタックに必要な相互参照が成立しません。8.16.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 以降が必要です。
container CLI を操作するため、両者の表示が食い違うことはありません — ただし、どちらにとっても対象となる Apple の container のインストールは必須です。Davit だけを入れても動きません。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 も要求に応じて同じことを行います。
登録されると、モニタはライブのメトリクスをストリームします。CPU・メモリ・マウントごとのディスク・起動中のネットワークインターフェイス、検出されたサービス、ファイアウォールと fail2ban の状態、そして GPU ホストでは GPU ごとの温度と使用率を報告し、マイニングや ML のリグでも温度が把握できます。list_monitors はフリートのヘルパー、バージョン、最新メトリクスを報告します。重要なのは、モニタは Mac アプリがオフラインのときでも監視を続けてアラートでき、自前のチャネルで直接通知し、アプリが戻れば蓄積分を再送します。ログウィンドウもモニタを優先します。サーバ上で root として動くため、sudo パスワードなしで特権ログを読めます。
登録済みホストのペインには動作と履歴チャートも表示されます。CPU・メモリ・ディスク・温度を5分解像度で最大30日分描画し、学習したベースラインで異常を検出します。温度は専用の摂氏スケールを使うため、パーセント表示のリソース使用率と並べても読み違えません。赤い縦線が同じタイムライン上にインシデントを示します。実線の赤はサーバの再起動（報告された稼働時間から導出）、オレンジの破線はウォッチドッグの問題 — サービスの強制再起動、データベース破損警告、再起動エスカレーションです。OS のクラッシュレポータが CPU を使い始めた場合（プロセスが繰り返しクラッシュしている状態）はオレンジの Crashes 曲線も加わり、「昨夜 MySQL が2回強制再起動され、何かがクラッシュループしていた」ことが一目で分かります。
モニタは既定で読み取り専用です。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.8Cloud 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 ボタンがあります。シートで正しいユーザ名と鍵を設定するだけです。
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 章が扱います。
8.9ホストへの画面共有
各サーバのペインは、プローブが検出したリモートアクセス手段を提供します — 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.10KVM-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.11Boot Media：ネットワーク越しに OS をインストール
かつてサーバの再インストールといえば、USB メモリを持ってラックまで行くことでした。Boot Media ペイン（フリートとリモート）は USB メモリの代わりになります。インストーライメージをこの Mac のライブラリにまとめておき、選んだものを FrontierStack が仮想 CD として対象マシンに提示します — サーバの管理コントローラ、PiKVM、Proxmox VE 仮想マシンの CD ドライブ、またはネットワークブートメニューを通じて。Mac は扱いが異なります。Apple がもうこの方法での起動を認めていないためです。後述のMacを参照してください。
8.16.6イメージライブラリ
Add ISO or Disk Image… はローカルファイルを登録します。ファイルはその場所のままで、コピーはしません。Add Image URL… は Web サーバやファイルサーバ上にすでにあるイメージ（http・https・nfs・cifs）を登録します — リモート URL は対象にそのまま渡されるので、この Mac がデータを中継する必要はありません。Compute SHA-256 はファイルのチェックサムを記録し、インストール前にベンダが公開している値と照合できるようにします。各項目は名前の変更、Finder での表示、ライブラリからの削除ができ、Copy Image URL で配信アドレスをコピーできます。保存した場所にファイルがなくなった項目には、見つからない旨の印が付きます。
8.16.7内蔵メディアサーバ
管理コントローラは 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 またはアプリケーションファイアウォールが有効で、コントローラからの接続を遮る可能性があるときに表示されます。管理者の確認のうえでポートを開きます。 |
403 を返します。各イメージは推測不能な 128 ビットのトークン URL で、配信がオンの間だけ公開されます。インストーラ ISO はふつう秘密ではありませんが、カスタマイズしたイメージには鍵や応答ファイルが含まれることがあります。共有ネットワークでは Until I stop it を選ばず、タイマを使ってください。8.16.8サーバ管理コントローラ（Redfish）
多くのラックサーバは、イメージを仮想 CD として提示できるベースボード管理コントローラを備えています。FrontierStack は標準の DMTF Redfish API でこれを操作します：Dell iDRAC 8／9、HPE iLO 4／5／6、Lenovo XClarity Controller（XCC）、Supermicro X12 以降、そして標準の Redfish 仮想メディアを実装したその他のコントローラです。
- Add Controller でアドレス・ポート・ユーザ名・パスワードを入力します。パスワードは Keychain に保存され、コントローラにだけ送られます。必要ならフリートのサーバとリンクして、両者を並べて表示できます。Virtual Media と Control の権限を持つアカウントを使ってください。
- Read Controller で管理対象を検出します：各システムのモデルと電源状態、各仮想 CD スロットと現在マウントされているもの。
- System・Virtual CD・Image を選びます。Boot from it once をオンのままにすると CD から 1 回だけ起動し、その後は通常の起動順序に戻ります。
- Then で Don't restart（再起動しない）・Graceful restart（正常再起動）・Force restart（強制再起動）を選び、Mount（または確認を求める Mount and Restart）を押します。
- インストールが終わったら仮想 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.16.9PiKVM 仮想メディア
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.16.10Proxmox 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.16.11ネットワークブート（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.16.12その他の KVM-over-IP 機器
JetKVM・GL.iNet Comet・NanoKVM・TinyPilot・Raritan・ATEN・Avocent・Lantronix・Adder には、仮想メディア用の安定した公開 API がありません。そのため FrontierStack は操作できるふりをしません。代わりに Copy URL が配信を開始して KVM から到達できるイメージアドレスをコピーし、ペインはそのベンダ自身のコンソールのどこに貼り付けるかを示します。
8.16.13Mac
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.16.14AI 管理者から
AI 管理者と MCP クライアントは、既存の kvm ツールで Boot Media を使えます：media_list（読み取り専用）はライブラリ、メディアサーバの状態、各コントローラの電源とマウント中のイメージ、各 PiKVM のドライブを報告します。media_attach は対象 — 名前で指定するコントローラや PiKVM、または proxmox:<vmid> — にイメージをマウントし、boot=true ならそこへの再起動も行います。media_eject は取り外します。接続・取り出し・再起動には Allow changes が必要で、必ず確認を求めます（第 13 章）。
8.12Proxmox 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 でゲストの電源を操作できます（必ず確認を求めます）。
PVEAuditor で十分です。ここからインストーラを起動することにしたら、あとで VM とデータストアの権限を追加します。8.13古い 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・ディスク・サービスを他のすべてと並べて監視できます。
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 段階で診断・修正できます。読み取り専用のテスト、続いて最小限の修正、そして再実行で確認です。
8.14OpenCore 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 をアップデートしても安全、注意してアップデート、安全ではない — 理由付きで。
このペインは意図的に OCLP を管理しません — OpenCore の構築とルートパッチの適用は OCLP 自身のアプリの役目のままです。提供するのは固定で可逆な管理者アクション 3 つだけ：macOS の自動インストールをオフ（システム設定が OCLP Mac を無人でアップデートしないように）、EFI をバックアップ（EFI/OC フォルダのアーカイブをその Mac に保存）、OpenCore を再 bless（OCLP の「Install to disk」と同じ bless --setBoot。OpenCore.efi が実在しなければ拒否）。フリートのステータスプローブもピン留めしたすべての Mac で OCLP を検出します。ホスト行とサーバアクティビティウィンドウに表示され、ルートパッチが欠けているか起動エントリが OpenCore を迂回している場合はアラートにセキュリティ項目が上がります。
diagnose ["oclp"] は完全なレポートを返し、スクリプトはペインの判定が安全になるまで macOS アップデートのインストール — や、起動エントリが OpenCore を迂回する Mac の再起動 — を拒否します。「この Mac をアップデートしたら Wi-Fi が消えたのはなぜ？」と尋ねれば、公式サポート Mac に対する診断ではなく、OCLP = true、実機モデル、最近のアップデート、ルートパッチ = 欠落から推論します。8.15移行ウィザード：スタックを新しいデバイスへ
古いサーバの引退が「すべて手作業で再インストール」を意味することは、もうありません。FrontierStack はレガシーマシンからスタックを取り出し、選んだ移行先——この Mac、別の Mac、あるいは Linux——に立ち上げる移行ウィザードを備えています。移行元は読み取るだけで、書き込みはすべて移行先に対して行います。
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 章）。
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 を選ぶと、代替をインストールし、正確な引き継ぎチェックリストを表示します。専用インポータを持つサービス——Websites（vhost とファイルの完全コピー）と Open Directory（ユーザとグループ）——はそれぞれのペインへ、検出された git サーバは Git Server 移行へ引き継ぎます。
serviceproxy が受け持ちますが、古いリリース——特に High Sierra——ではこのプロセスがハングします。接続は受け付け続けるのに、応答を返さなくなる状態です。ping は通り、ポートは開いて見え、SSH も使えるため、サイトは到達可能に見えながら、すべてが応答しません。この特徴ゆえに DNS やネットワークの障害と誤診されがちで、プロセス自体は生きているため「サービスは稼働中か」という確認でも検出できません。移行元マシンには http://127.0.0.1/ をサービス serviceproxy で監視する Service Guardian を設定してください（背後のバックエンドを見る場合は server-httpd）。移行を計画する間、ハングを検出して launchctl kickstart で自動復旧できます。サイトを素の Apache へ移行すれば、ハングしやすいプロキシを配信経路から恒久的に取り除けます。serveradmin を root で実行するため、まずそのホストの sudo パスワードを設定に保存してください（第 8 章「管理対象鍵と保存された sudo パスワード」）。一部の Apple サービスは設定を自動で引き継ぎ（DNS ゾーン、Apache vhost、Postfix の main.cf）、他はコピー先に代替をインストールして手順を提示します。各項目はAutomatic・Assisted・Manual と明示されます。8.16Git サーバ：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 上で実行されます。
FrontierStack ユーザマニュアル · バージョン 1.0.0 · 第 8