Managed MCP-Clients ausrollen
Bei einem verwalteten Rollout übernimmt die Organisation Verantwortung für Runtime Profile, unterstützte Client-Targets und Policy für nicht verwaltete Einträge. Beginne nicht mit Fleet Enforcement. Erprobe Profil und Recovery-Pfad zuerst auf einem repräsentativen Host.
Rollout-Stufen
Organisationsprofil vorbereiten
Vor Änderungen an Client-Dateien:
- Organisationskontext auswählen,
- Runtime Profile für den Rollout festlegen,
- nützliche bestehende Einträge aus unterstützten Clients importieren,
- fehlende Runtime Inputs und Secret-Referenzen auflösen,
- Client-Targets und Config-Pfade im Scope erfassen und
- entscheiden, ob nicht verwaltete Einträge später erlaubt oder blockiert werden sollen.
Nutze --dry-run vor jeder neuen Import- oder Sync-Form.
lightnow context --tenant acme lightnow import-config --client codex --profile platform --dry-run lightnow import-config --client codex --profile platform lightnow sync --client codex --profile platform --local-proxy --dry-run lightnow sync --client codex --profile platform --local-proxy lightnow config-status --client codex --json lightnow-proxy --config ~/.lightnow/lightnow-proxy/codex.yaml --health --json
Die CLI legt vor dem Schreiben neben einer bestehenden Client-Config ein
.lightnow.bak-Backup an. Prüfe, ob der Pilot-Client startet, die erwarteten
Tools entdeckt und eine repräsentative Anfrage abschließt, bevor du die
Organisations-Policy änderst.
Organisations-Policy konfigurieren
Lege in LightNow Config die Local-Proxy-Policy der Organisation fest:
| Einstellung | Bedeutung für den Rollout |
|---|---|
| Enabled | Erlaubt Policy-Sync mit Local Proxy für ausgewählte Clients |
| Runtime Profile | Von --from-settings ausgewähltes Profil |
| Managed Clients | Unterstützte Targets, auf die Proxy-Policy angewendet wird |
| Unmanaged Entries | Erlaubt Koexistenz oder entfernt umgehende MCP-Einträge |
| Policy Mode | Observe erfasst Posture; Enforce wendet die Grenze an |
| Metadata-only Telemetry | Aktiviert Runtime- und Health-Events ohne MCP-Payload-Speicherung |
Beginne mit erlaubten nicht verwalteten Einträgen, sofern die Organisation nicht bereits alle benötigten direkten Einträge geprüft und importiert hat. Das Blockieren ist eine destruktive Policy-Entscheidung für die Client-Datei, auch wenn ein Backup angelegt wird.
Policy auf eine Pilotgruppe anwenden
Wähle ein repräsentatives unterstütztes Target und Betriebssystem.
Führe lightnow sync --client <client> --from-settings auf jedem Pilot-Host
aus.
Prüfe nach dem Client-Neustart sowohl die Client-Datei als auch aktive Upstream-Health.
Ergänze Client-Typen und Hosts erst, wenn die vorherige Kohorte keine ungelösten Config-, Authentifizierungs- oder Upstream-Fehler besitzt.
lightnow context --tenant acme
lightnow sync --client codex --from-settings
lightnow config-status --client codex --json
Wiederhole den Policy-Sync für jedes Managed-Client-Target. Das Speichern von Organisationseinstellungen allein schreibt keine Workstation-Dateien um.
Managed State verifizieren
Erfasse pro Host:
- Client-Target und Config-Pfad,
- ausgewählte Organisation und Profil,
config-status-Posture,- LightNow-Proxy-Health-Ergebnis,
- ob nicht verwaltete Einträge laut Policy bestehen bleiben und
- Client-Neustart sowie repräsentatives Tool-Ergebnis.
managed ist die gewünschte Posture, wenn umgehende Einträge blockiert sind.
mixed ist nur korrekt, wenn die Organisations-Policy nicht verwaltete
Einträge bewusst erlaubt.
Fehlgeschlagenen Host wiederherstellen
Verdecke einen fehlerhaften Rollout nicht durch ein unpassendes Profil oder anonymen Modus.
- Erweiterung der Kohorte stoppen.
config-status --jsonund Proxy-Health-Ausgabe erfassen.- Authentifizierung, Profil-Readiness oder fehlerhaften Upstream korrigieren.
- Ist die geschriebene Client-Datei selbst unbrauchbar, ihr benachbartes
.lightnow.bak-Backup wiederherstellen. --from-settingserst erneut ausführen, wenn die Ursache verstanden ist.