Verbindlich: main@8fb581b730f7a3833566c4bbb7c87875ad921e69; veröffentlicht bleibt v1.9.0. PR #74–#97 sind integriert. Deployment/Discovery, Imagebuilder, Pi-VPN und Syslog sind auf main, nicht mehr nur historische Vorschau. 26 reguläre Rollen einschließlich Deployment-VM; Provisioning ist optional zusätzlich.

Betreiberbestätigt: KDE-Boot, Rufe, SDS, Aufnahme/RF-Wiedergabe und WLAN am 13.10.; 28/28 Discovery-Agenten aktualisiert und keine ungeklärten Remote-Aufträge mehr am 15.10. Ein aktueller Backend-Gesamtrollout, NAS-Entlastung, SIP/Telegram, VPN-Wechsel und Dauerlauf bleiben separat offen. Vier alte Git-/Timeoutfehler bleiben Fehler.

Gesamtroadmap · Upstream-Vergleich · Roadmap und Releases. NETCORE-IAM-01 ist weiterhin Planung; AD-SSO-Pilot und Gruppenmapping sind konkretisiert, Produkt-/Betriebsentscheidung und Umsetzung offen.

26 reguläre Rollen. Deployment Core/Imagebuilder benötigt eine vollständige Ubuntu-VM, kein LXC. Für Sammelvorschau, Einzelzielstatus und Discovery-Filter siehe aktuelle Updates.

Kanonische aktuelle Fachanleitung.

Die folgende frühere Fassung bleibt als datierte Historie erhalten. Frühere Dienstzahlen, Featurebranch-Aussagen, offene Tests und Prioritäten sind keine aktuelle Statusaussage; heutige Verfahren stehen oben beziehungsweise in den verlinkten kanonischen Docs.

Aktueller Quellenstand 07.10.2026: main 990bffb2; Release weiterhin v1.9.0. PR #59 mit Hell/Dunkel ist integriert, PR #60 ergänzt Projektarchive. Nur main ist als Branch vorhanden. Deployment/Discovery, Imagebuilder, Pi-VPN und neuere Syslog-Pipeline bleiben ausschließlich am historischen Featurecommit bbf0397 vorhanden. Keine neue Live-Abnahme. Roadmap und Releases · Upstream-Vergleich

Das neue Design ändert weder vorhandene Dienstports noch Zugangsverfahren. Deployment-Ports 8320/8321, Discovery und die neuere Syslog-Pipeline gehören weiterhin ausschließlich zur historischen Vorschau. IAM/Drive sind Planung ohne festgelegte neue Produktivports. Bedienoberflaechen · Roadmap und Releases

Die aktuelle Vorlage in deploy/open-lab/ plant einen Dienst pro LXC. Der Deployment-Host rendert aus einem lokalen Inventory Konfigurationen und führt Installer in Abhängigkeitsreihenfolge per SSH aus. Er speichert nach der README keine Passwörter, Tokens oder KMF-Schlüssel.

Die Vorlage ist mode = "open_lab". Alle erreichbaren Clients im Managementnetz können bei vielen Diensten Verwaltungsaktionen auslösen. Vor dem ersten apply Netzisolation und die zugewiesenen LXC-Adressen prüfen. Security-and-Operations

• Debian 13 oder kompatible LXC mit systemd, Rust-Toolchain und C-Build-Werkzeugen;
• separater Deployment-Host mit Root-SSH-Schlüsselzugriff zu den Zielcontainern;
• auf jedem LXC echte IP-Adresse, DNS/Hosts-Auflösung und erreichbare Abhängigkeiten;
• /dev/net/tun für den IP Gateway, vorbereiteter NFS-Mount für Archivfunktionen;
• Quellstand, Wartungsfenster und Sicherung festhalten. Bei laufenden Rufen keine unkoordinierte Dienstwelle auslösen.

Im Repositoryverzeichnis auf dem Deployment-Host:

cp deploy/open-lab/inventory.example.toml deploy/open-lab/inventory.toml
$EDITOR deploy/open-lab/inventory.toml
python3 deploy/open-lab/netcore-deploy.py --inventory deploy/open-lab/inventory.toml validate
python3 deploy/open-lab/netcore-deploy.py --inventory deploy/open-lab/inventory.toml plan
python3 deploy/open-lab/netcore-deploy.py --inventory deploy/open-lab/inventory.toml render

Alle Beispielhosts ersetzen. Insbesondere die TBS-[control_room]-Adresse auf denselben Node Gateway wie das Inventory setzen; die TBS verbindet sich im verteilten Aufbau über /ws/node, nicht direkt mit der Control-Room-WebUI. Gerenderte Dateien, Abhängigkeiten und Portliste vor der Installation lesen.

python3 deploy/open-lab/netcore-deploy.py --inventory deploy/open-lab/inventory.toml apply --dry-run
python3 deploy/open-lab/netcore-deploy.py --inventory deploy/open-lab/inventory.toml apply
python3 deploy/open-lab/netcore-deploy.py --inventory deploy/open-lab/inventory.toml status

Die zweite Zeile verändert die Ziel-LXCs. Der Deployer baut die betroffenen Binärdateien auf den Zielhosts, überträgt gerenderte Konfigurationen und startet Dienste in Abhängigkeitsreihenfolge. Kein blindes Wiederholen bei Teilfehlern: zuerst betreffenden LXC, Installer-Log, TOML und Journal prüfen. Das lokale inventory.toml enthält Standortdaten und gehört nicht als unveränderte Vorlage ins Wiki.

python3 deploy/open-lab/netcore-deploy.py --inventory deploy/open-lab/inventory.toml test --profile full --validate-only
python3 deploy/open-lab/netcore-deploy.py --inventory deploy/open-lab/inventory.toml test --profile smoke

validate-only prüft lokal, smoke liest Dienstverträge und nutzt einen Mock-TBS-Pfad. Die Profile full --allow-mutations und fault --allow-mutations --allow-restarts verändern Testdaten bzw. stoppen Dienste absichtlich; nur in einem dafür vorgesehenen Labornetz durchführen. Ausgaben liegen unter tests/e2e/artifacts/<run-id>/. Das ältere E2E-Runbook erwähnt noch 17 Dienste: Befehle und Dienstzahl stets am aktuellen Inventory prüfen.

Die lokale TBS, Provisioning Core, Directory, Piper, lokaler TBS-Asterisk und Brew-Server sind keine stillschweigend vom 25er-Inventory installierten Komponenten. Sie haben eigene Installations- und Freigabeschritte: Installation · Provisioning · NetCore-Directory · SIP-und-Brew.

1. git status, Branch/Commit und Ist-Konfiguration auf Deployment- und Zielhosts dokumentieren.
2. Konfigurationen, Persistenzdaten und Keys nach passendem Verfahren sichern. Backup-and-Fallback
3. Änderungen per validate → plan → render → apply --dry-run prüfen.
4. Abhängigkeitsreihenfolge beachten; erst danach apply und status.
5. Bei Fehler: Zielhost auf letzten bekannten Build/Konfigurationsstand zurücksetzen und Datenmigration gesondert behandeln.

Dieser main-Deployer erzeugt kein Pi-Image und keine allgemeine Dienstsuche. Dafür gibt es jetzt die getrennte Entwicklungsvorschau.

Das Inventory umfasst 25 Dienste. Die Warnzentrale ist ein Python-Dienst ohne zusätzlichen Cargo-Build und benötigt Token sowie persistente SQLite-Daten. Die Inbetriebnahmefolge lautet SDS Router → Control Room mit Gateway-Telemetrie → Warn-LXC → betroffene TBS → kontrollierte Versandfreigabe. Warnzentrale

Der Inventory-Validator besteht; der Gesamt-Audit erwartet noch 24 Dienste und bei alert-service nicht vorhandene Metrics-/OpenAPI-Marker. Hinzu kommt die Gateway-Hostabweichung. Diese Befunde erst beheben oder begründet einordnen, bevor ein Gesamterfolg behauptet wird. Projektstand

Entwicklungsvorschau vom 28.09.2026: Historischer Featurecommit bbf0397, Deployment-Komponente 0.2.3. Diese Funktionen sind noch nicht auf main und kein neuer Gesamtrelease. PR #57 wurde in den Entwicklungsbranch gemergt. Die VM übernimmt Images und Verwaltung; bestehende LXCs/Pis erhalten einen Agenten. Ein Controller-LXC bleibt ohne Imagebuilder möglich. Rollen, Seeds, Cache, Aufträge und Wiederherstellung sind unter Deployment und Discovery beschrieben. Die Live-Abnahme bleibt offen.