Systemd Service

Aktueller Stand 16.10.2026

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.

Aktuelle Fachanleitung und Grenzen. Die bestätigte Pi-Kurzabnahme gilt nur für den dokumentierten Build und Funktionsumfang; sie ist keine generelle Mehrzellen-, SIP-, VPN- oder Dauerlaufabnahme.

Historischer Seitenstand bis 07.10.2026

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.

Systemd-Service

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

Aktuelle Einordnung

Das neue Design ist implementiert; IAM/Drive bleiben Planung. Discovery, Imagebuilder, Pi-VPN und neuere Syslog-Funktionen sind weiterhin historische Entwicklung ohne main-Integration. Die aktuelle Reihenfolge und Nachweise stehen unter Roadmap und Releases und Projektstand.

Eine robuste Unit startet die Basisstation mit einem festen Konfigurationspfad und einem dedizierten Benutzer.

Beispiel

[Unit]
Description=NetCore TETRA Basisstation
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=netcore
Group=netcore
WorkingDirectory=/opt/netcore
ExecStart=/usr/local/bin/bluestation-bs /etc/netcore/config.toml
Restart=on-failure
RestartSec=5
TimeoutStopSec=20
LimitNOFILE=65536
Environment=RUST_LOG=info

[Install]
WantedBy=multi-user.target

Als /etc/systemd/system/tetra.service speichern.

Aktivieren

sudo systemctl daemon-reload
sudo systemctl enable --now tetra.service
sudo systemctl status tetra.service --no-pager

Rechte

Der Dienstbenutzer benötigt Zugriff auf:

• SDR-Gerät bzw. USB-/Gerätegruppe
• Konfiguration
• lokale Aufnahme- und Medienverzeichnisse
• Cache-Verzeichnisse
• gemountete NFS-Ziele
• eventuell Netzwerkverwaltung, falls WLAN aus dem Dashboard gesteuert wird

Keine pauschalen Root-Rechte vergeben, wenn gezielte Gruppen- oder PolicyKit-Regeln ausreichen.

Neustartverhalten

Restart=on-failure startet bei unerwartetem Prozessende neu, aber nicht bei einem sauberen Stop. Ein zu kurzer Neustartzyklus kann bei einer dauerhaft falschen RF-Konfiguration das Log fluten; fünf Sekunden sind ein sinnvoller Ausgangswert.

Ergänzende Units

• netcore-directory.service
• netcore-piper.service
• netcore-control-room.service

NFS-Mounts sollten als eigene Mount-Unit oder über /etc/fstab mit netzwerktauglichen Optionen bereitgestellt werden. Die Basisstation darf nicht davon abhängen, dass ein langsames NFS den Start unbegrenzt blockiert.

Weiterführend

Installation · Betrieb-und-Wartung · Troubleshooting