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.

VM-, Proxmox- und Einzelupdateverfahren. Unter „Gezielt ausrollen“ zuerst eine frische main-Vorschau erzeugen, dann ausgewählte Dienste mit Einzelzielstatus aktualisieren. Discovery bietet kombinierte Typ-/Rollen-/Online-/Textfilter sowie persistentes Entfernen und Wiederherstellen. Ein Scan stellt entfernte Hosts nicht automatisch wieder her.

Deployment Core benötigt eine vollständige Ubuntu-VM mit getrenntem Imagebuilder, kein LXC. Controller TCP 8320, Agent TCP 8321, Discovery 239.192.84.82:48320/UDP mit TTL 1 und optionalen Unicast-Seeds. Kein zusätzliches VLAN als Feldvoraussetzung; vorhandenes gemeinsames Backend-VLAN bleibt verwendbar. Open-Lab-Discovery ist kein Vertrauens-/IAM-Nachweis.

Desktopwahl: KDE, XFCE, GNOME oder Lite. Grafisches OpenVPN über NetworkManager; getrennte Zugangsdaten und akzeptiertes lport 0. Heimnetzerkennung nur über physisches LAN/vertrautes WLAN, nicht über Tunnelrouten. Pi-VPN-Wechsel und neue ARM64-Images bleiben gesondert abzunehmen.

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

Der historische Featurecommit bleibt erreichbar, sein Branch ist gelöscht. Deployment Core, Discovery, Imagebuilder und Pi-VPN fehlen am geprüften main. Z01.1 verlangt vollständigen Tip-Vergleich samt Konflikt-/Integrationsplan; Z01.2 ist die anschließende Implementierung. Neuere main-WebUIs erhalten. Keine vorhandene Live-Installation aus alten Chatlogs ableiten.

Die gewünschte VM führt WebUI/Notfall-GUI und Imagebuilder; Bestands-LXCs bleiben getrennt. Kein zusätzliches VLAN als Einrichtungsvoraussetzung im Feld; vorhandenes gemeinsames Backend-VLAN für Discovery nutzen. Pi-VPN-Heimnetzerkennung bezieht sich auf physische LAN-/freigegebene WLAN-Verbindungen, niemals auf Tunnelrouten. Standortkennungen abstrahieren.

Entwicklungsvorschau vom 28. September 2026. Diese Seite beschreibt ausschließlich feature/openlab-discovery-deployment bei bbf039729b9b05f8d623b11195ca24a124f68d16. Die Deployment-Komponente nennt 0.2.3; dies ist keine neue NetCore-Gesamtrelease. Der verbindliche Betriebsstand der übrigen main-Anleitungen bleibt main bei 20603a042c97b60fb78599db3bc675993f3e74f9, Softwarestand 086a81fa und Release v1.9.0. PR #57 integrierte Syslog in den Entwicklungsbranch, nicht in main. Der frühere Syslog-Branch ist deshalb keine aktuelle Installationsquelle.

Die frühere Idee eines Deployment-LXC ist konkretisiert: Für personalisierte Pi-Images ist eine vollständige Ubuntu-VM vorgesehen. Ein vorhandener Controller-LXC kann die Verwaltung ohne Imagebuilder weiter übernehmen. Die Backend-LXC und der Observability-LXC bleiben eigene Hosts. Der neue Controller ist kein Bestandteil des zeitkritischen Funk- oder Medienpfads; jeder Agent behält seine letzte gültige Dienstzuordnung auch bei Ausfall der VM.

Die Vorschau enthält eine Weboberfläche für Hosts, Rollen, bekannte installierte Commits, Git-Referenzen, gezielte Installationen, Updates, Neustarts und Auftragsprotokolle. Der Rollout löst eine gewählte Referenz vor dem Versand in einen vollständigen Commit-SHA auf. Das Entwicklungs-Inventory zählt 26 Dienste einschließlich Deployment Core; auf main bleiben es 25. Die Anzahl bekannter Observability-Ziele oder Maschinen ist eine andere Größe und darf nicht als Dienstinventur verwendet werden.

Die Open-Lab-Verwaltung arbeitet ohne Login, TLS, Token oder Rollenprüfung. Ein erreichbarer Lab-Teilnehmer kann Änderungen anstoßen. Der Controller läuft unprivilegiert als netcore-deploy; der Agent benötigt root für Installer und systemd. Der separate Imagebuilder besitzt ausschließlich einen lokalen Unix-Socket. Diese Trennung ist vorhanden, eine produktive Zugriffskontrolle ist weiter ein Ausbauziel.

Der VM-Installer unterstützt Ubuntu 24.04 und 26.04 LTS, AMD64 und ARM64. Ubuntu Server und eine vorhandene Desktopinstallation sind möglich. Als Planungsgröße gelten 4 vCPU, 8 GiB RAM und 100 GiB Disk; vor einem Imagebuild werden mindestens 32 GiB freier Speicher geprüft. QEMU-User-Emulation benötigt kein verschachteltes KVM. Der erste ARM64-Softwarebuild kann lange dauern; daraus folgt keine zugesicherte Buildzeit.

Für die hier dokumentierte Vorschau eine neue Arbeitskopie verwenden und ihren Stand festhalten:

git clone --branch feature/openlab-discovery-deployment \
  https://github.com/JanHG98/netcore-tetra.git netcore-preview
cd netcore-preview
git checkout --detach bbf039729b9b05f8d623b11195ca24a124f68d16
git rev-parse HEAD
sudo bash system-backend/deployment-core/install/install-vm.sh

Anschließend http://<VM-IP>:8320 öffnen. Die veröffentlichte Adresse muss vom Pi erreichbar sein; localhost eines SSH-Tunnels ist dafür ungeeignet. --advertise-url http://<VM-IP>:8320 setzt sie ausdrücklich. Eine DHCP-Reservierung vermeidet veraltete Image-Adressen. Ubuntu 24.04 verwendet qemu-user-static und binfmt-support, 26.04 qemu-user und qemu-user-binfmt; der Installer prüft die ARM64-Registrierung mit dem für Chroot nötigen F-Flag. Ein aktiver Imageauftrag blockiert ein VM-Softwareupdate.

Ohne Imagebuilder genügt auf einem vorbereiteten Debian-12+-LXC beziehungsweise einer VM bash system-backend/deployment-core/install/install.sh controller. Das separate install/create-lxc.sh läuft auf dem Proxmox-Host, benötigt eine freie CTID und ein tatsächlich vorhandenes Debian-Template und erstellt einen unprivilegierten Container. Bestehende IDs werden abgewiesen; ein Fehler löscht keinen vorhandenen Container. Dieser Weg ersetzt nicht die Ubuntu-VM für Images.

Auf jedem vorhandenen Zielhost denselben geprüften Quellstand bereitstellen und den Agenten installieren:

sudo bash system-backend/deployment-core/install/install.sh agent \
  --seed http://<VM-IP>:8320 --managed-service <DIENSTNAME>

Platzhalter vorher ersetzen. Mehrere absichtlich gemeinsam betriebene Rollen können wiederholt angegeben werden; --managed-service none meldet einen externen Host ohne NetCore-Dienstverwaltung. Ohne Einschränkung werden tatsächlich installierte Katalogdienste erkannt. Seit 0.2.3 genügt eine herumliegende TOML nicht: Die systemd-Unit muss geladen sein und einen echten FragmentPath besitzen. Die Einschränkung stoppt oder deinstalliert keine anderen Dienste.

Der Controller bietet nach erfolgreicher Git-Prüfung alternativ ein Bootstrap-Skript zum Download. Es wird am Zielhost ausgeführt; ein SSH-Zugang vom Controller zum Ziel ist dafür nicht erforderlich. Die im Projekt vorhandenen Windows-Rollout-Dateien enthalten standortspezifische Inventare und sind vor Nutzung gegen die eigene Hostliste zu prüfen. Ihr Status Eingeschraenkt bedeutet lebendiger Dienst mit noch fehlender Readiness; Ungeklaert verlangt Auftragsprüfung und beendet den Gesamtlauf.

Historische TBS-Units wie tetra.service behalten beim Update ihren wirksamen ExecStart. Bei abweichenden Pfaden sind --tbs-unit, --tbs-config und --tbs-command ausdrücklich zu setzen. Das TBS-Binary erwartet die TOML als Positionsargument, Backend-Binaries verwenden --config. Eine bestehende TBS ohne Discovery-Wrapper erhält durch bloße Agent-Anmeldung keinen neuen Wrapper und übernimmt folglich keine automatisch aufgelösten Startadressen. Neu installierte TBS und Images bekommen diesen Wrapper.

Discovery prüft Umgebung, Rollen und Quellnetz. Alle 15 Sekunden wird angekündigt; nach 90 Sekunden ohne Antwort erscheint ein Host offline. IPv4-Multicast ist auf das lokale Netz begrenzt. Für geroutete Netze und VPN werden erreichbare Unicast-Seeds hinterlegt; daraus entsteht weder ein VPN noch ein Multicast-Tunnel. Gleichlautende Rollen werden nicht anhand einer zufällig passenden Portnummer zugeordnet. Mehrere Instanzen erzeugen einen sichtbaren Konflikt; eine ausdrückliche Bindung wie node-gateway=<HOST-ID> löst ihn.

Controller-Konfiguration liegt in /etc/netcore/deployment.toml, Agent-Konfiguration in /etc/netcore/discovery.toml. Wichtige Felder sind environment, allowed_networks, interface, seeds, advertise_url, managed_services und [bindings]. Die Vorlage erlaubt RFC1918 und Loopback; abweichende VPN-Netze sind bewusst zu ergänzen. Git-Abgleich erfolgt standardmäßig stündlich. Diese neuen Ports ergänzen die bestehende main-Portmatrix ausschließlich für die Vorschau.

launch.py erzeugt beim Start eine Arbeitskonfiguration unter /var/lib/netcore-discovery-<dienst>/config.toml. Die ursprüngliche TOML und bekannte TBS-Fallback-Dateien bleiben erhalten. UI-Änderungen an der Arbeitsdatei werden weitergeführt; eine ausdrückliche Änderung der Original-TOML hat im Konflikt Vorrang. Danach setzt der Wrapper die aufgelösten Verbindungsfelder ein. Den wirksamen Startpfad und beide Dateien bei einer Diagnose gemeinsam betrachten.

Ein Suchlauf startet keine Dienste neu. Neue Verbindungen wirken beim nächsten Start oder durch die gezielte Aktion „Verbindungen übernehmen / Neustart“. Ein vorhandener guter Cache bleibt bei Ausfall oder Konflikt erhalten; ein alter Cache ist kein aktueller Healthcheck. Bei ausgeschaltetem Controller muss die lokale TBS weiterarbeiten können; dieser Fehlerfall gehört in die Standortabnahme.

Der TBS-Assistent benötigt eine geprüfte Standort-TOML sowie Name, MCC, MNC, ISSI, LA und CC. RF-, SDR- und Frequenzwerte werden daraus übernommen und nicht erfunden. Die Profil-ISSI setzt Brew- beziehungsweise lokale Audioidentität und ersetzt keine Teilnehmer-ISSIs. Vorhandene Hardware mit installiertem SDR-Treiber kann per Bootstrap aufgenommen werden; für eine neue SD-Karte wird das VM-Imageverfahren verwendet.

Im Imageformular Profil und Git-Referenz wählen, erreichbare Controller-Adresse, Hostname, OS-Benutzer, SSH-Zugang und optional WLAN/OpenVPN festlegen. Üblicherweise HAT-EEPROM verwenden; das manuelle SX1255-Overlay ist für unprogrammiertes EEPROM vorgesehen. Der Builder programmiert kein EEPROM. Nach erfolgreichem Build .img.xz, SHA256 und Manifest herunterladen, Prüfsumme vergleichen und in Raspberry Pi Imager als eigenes Image flashen. Zusätzliche Imager-Personalisierung würde die schon eingebauten Angaben verändern und ist nicht Teil dieses Ablaufs.

Das Rezept beginnt mit Raspberry Pi OS Lite Bookworm ARM64 vom 13.05.2025 mit festem Download-Hash. NetCore wird am gewählten SHA, SoapySX am Commit 9705147dd8c189625071f3f163ea56119bda4a05 gebaut. Codec und bluestation-bs mit Asterisk-, Recording- und Audio-Player-Features werden vorinstalliert. Paketquellen und Rust-Toolchain sind nicht auf einen Snapshot eingefroren: Quell-Pinning und Manifest bedeuten keine bitidentischen Neubauten. Ein lokaler Asterisk samt SIP-Fallback ist gesondert über den vorhandenen Fallback-Installer einzurichten.

Beim ersten Start entstehen eigene SSH-Hostschlüssel und Machine-ID; die Rootpartition wächst auf die SD-Größe. Dafür braucht der Pi keinen Controllerkontakt und keinen Neubau aus GitHub. Vor dem Funkstart prüft SoapySDRUtil --probe=driver=sx das Gerät. Ein erfolgreicher CI- oder VM-Build ersetzt diesen realen Pi-/SXceiver-Test nicht.

Mit einem eingebetteten OpenVPN-Profil startet die Netzrichtlinie nach dem Boot und prüft etwa alle 15 Sekunden aktive NetworkManager-Verbindungen. Eine konfigurierte vertrauenswürdige WLAN-SSID oder eine kabelgebundene Adresse im konfigurierten LAN-Präfix schaltet VPN aus; außerhalb schaltet sie [email protected] ein. Die Tunneladresse selbst zählt nicht als Heimnetz. Die Richtlinie startet keine Funkdienste neu. Ihre Daten liegen in /etc/netcore/image-network.json; ohne Profil wird der Timer nicht aktiviert. Die Erkennung ist eine Netzzuordnung, kein kryptografischer Identitätsnachweis des Heimnetzes.

OpenVPN wird mit eingebetteten Schlüsseln/Zertifikaten unterstützt; externe Dateireferenzen, TAP, Skripte und Plugins werden abgewiesen. Images enthalten die ausgewählten OS-/WLAN-/VPN-Daten. Die HTTP-Downloads sind im erreichbaren Open Lab offen. Deshalb nur personalisierte Artefakte für den vorgesehenen Betreiber erzeugen und ihre Aufbewahrung begrenzen; keine echten Zugangsdaten in Wiki, PR oder Beispiele übernehmen.

Controller- und Agentaufträge werden in SQLite gespeichert. Änderungen sind pro Host serialisiert; Logs und Laufzeiten sind begrenzt. Vor einem bestehenden Deployment wird die ursprüngliche Konfiguration unter /var/lib/netcore-discovery/backups/ gesichert. Ein unbekannter installierter Commit bleibt unbekannt: Der Stand einer beliebigen Arbeitskopie wird nicht als laufende Binary-Version ausgegeben. Liveness und Readiness bleiben getrennte Befunde.

Ein Deployment-POST darf bei verlorener Antwort nicht blind wiederholt werden. Die aktuelle Fassung fragt denselben Remote-Auftrag nach; remote_uncertain, remote_url und remote_job kennzeichnen einen unklaren Zustand. Vor einer Wiederholung zuerst diesen Auftrag, Agent und systemd prüfen. Ein Neustart des beschäftigten Agenten kann den Befund weiter verschlechtern. Beim nächsten Start werden unterbrochene Aufträge gekennzeichnet; sie werden nicht automatisch erneut ausgeführt.

Seit 0.2.2 wird eine fremde Git-index.lock nicht gelöscht. Stattdessen kann der Agent einen frischen verwalteten Clone verwenden. source-location.json wird erst nach Erfolg auf den neuen Ort gesetzt; ein eigenes source.mutex serialisiert die Quellenverwaltung. Alte Arbeitskopien bleiben für die Untersuchung erhalten und benötigen Speicher. Der Hardware-Gateway-Fix in 0.2.3 beendet Webserver und MQTT-Unterprozess geordnet; beim ersten Übergang aus einer älteren hängenden Version sind bis zu 240 Sekunden Stop-Wartezeit vorgesehen.

systemctl status netcore-deployment netcore-image-builder --no-pager
journalctl -u netcore-image-builder -n 100 --no-pager
systemctl status netcore-discovery --no-pager
journalctl -u netcore-discovery -n 100 --no-pager

Controllerzustand liegt unter /var/lib/netcore-deployment, Agentzustand unter /var/lib/netcore-discovery, Imagecache, Arbeitsbereiche und Artefakte unter /var/lib/netcore-image-builder. Konsistente Datenbanksicherungen zusammen mit Original-TOML, Runtime-Konfiguration, Quell-SHA und Image-Manifest aufbewahren. Artefaktlöschung in der UI entfernt kein bereits geflashtes System. Caches werden nicht automatisch vollständig bereinigt. Nur abgeschlossene Images erscheinen als Download; unterbrochene Builds behalten einen ausdrücklichen Fehlerstatus.

Ein allgemeiner atomarer Rollout oder automatischer Rollback aller Dienste ist nicht implementiert. Die Wiederherstellung verwendet den bekannten vorherigen Commit, passende Konfigurationssicherung und eine anschließende Health-/Fachprüfung. Der bestehende TBS-Updater behält seinen eigenen Binary-Rollback. Schemaänderungen einer Datenbank brauchen zusätzlich ihre eigene Rücknahmestrategie.

Am 28.09.2026 bestanden lokal 43 von 44 Deployment-Tests; ein Test der echten Unix-Socket-Verbindung wurde wegen fehlender Umgebungsvoraussetzung übersprungen. Die 15 Syslog-Unit-/Archivtests bestanden. Ihre temporären Share-Ersatzverzeichnisse sind kein reales NAS. Die Syslog-Wiretests und eine Live-Anlage wurden in diesem Dokumentationslauf nicht ausgeführt.

Der GitHub-Workflow OpenLab deployment and discovery, Lauf 36349402097 ist für bbf0397 erfolgreich: Discovery, Rust/UI und Image-Engine auf Ubuntu 24.04 sowie 26.04. Die Image-Jobs prüfen das echte OS-Image, ARM64-Chroot und Personalisierung; sie sind kein vollständiger Softwarebau im Image und kein physischer Pi-Boot. Der Rust-Job prüft den Workspace und baut die TBS mit Standardfeatures separat.

Vor einer Übernahme nach main bleiben konkret: Installation und Update eines echten Zielhosts mit falscher Rolle als Negativfall; Wiederanlauf nach verlorener HTTP-Antwort ohne Doppelauftrag; Controllerausfall mit weiterlaufender TBS; Pi-Start mit Soapy-Probe; WLAN/LAN/VPN-Wechsel ohne Funkneustart; NFS-Ausfall und verifizierter Archivtransfer; anschließend Funk-, SDS-, SIP- und Readiness-Abnahme. Frühere Chatberichte über erfolgreiche Einzelschritte sind Hinweise und ersetzen für diese Ausgabe keine selbst gelesenen aktuellen Laufzeitprotokolle.

Die Vorschau basiert auf Deployment-Dokumentation und Implementierung bei bbf0397, der Syslog-Dokumentation, PR #57 und dem genannten CI-Lauf. Die Quellen-SHAs machen diese Ausgabe unabhängig von späteren Branchbewegungen. Die laufende Übersicht steht unter Roadmap und Releases, Deployment und Discovery und Syslog und Archivierung.

Syslog und Archivierung · Roadmap und Releases · Open-Lab-Deployment

Der aktuelle bereitgestellte NetCore-Discovery.bat-Launcher nennt Stand 28.09.2026 / Rollout-Fix 0.2.6. Geprüft sind im Dateikopf und den Hilfsfunktionen eine SSH-Portprüfung mit begrenzter Wartezeit und verdeckte Eingabe am Bereitschaftshinweis. Der Deployment-Repositorybranch bleibt hingegen bei bbf0397 und Komponentenversion 0.2.3. Launcher-Version, Agent-/Controller-Version und Gesamtrelease dürfen nicht gleichgesetzt werden.

Das Hilfsartefakt enthält standortspezifische Zieldefinitionen und wird hier nicht veröffentlicht. Vor dem nächsten Anlagenlauf tatsächliche Rollen, Erreichbarkeit, installierte Commits und Wiederaufnahmeverhalten prüfen. Frühere Rollout-Logs sind historische Beobachtungen; sie belegen weder einen heutigen Fehler noch einen erfolgreichen Gesamtlauf. Projektideen und Entwicklungsstand