Funktionsumfang
StarfleetController befindet sich im Aufbau. Diese Seite trennt deshalb sauber zwischen dem, was bereits trägt, und dem, was noch entsteht. Eine Doku, die einen Stand verspricht, den es nicht gibt, kostet mehr Vertrauen, als sie bringt.
Die Kennzeichnung ist durchgehend:
Bestand und Inventar
Anlagenliste
Alle Anlagen, auf die Ihr Partnerzugang ein Recht hat, in einer Liste. Je Anlage: Kundenname, Online-Zustand, letztes Lebenszeichen, STARFACE-Version, Modulversion, Serverlizenzschlüssel und Standortangaben. Sie können über Name, Serverlizenz und Standort suchen und auf verbundene Anlagen filtern.
Ein Kunde ruft an und nennt nur seinen Firmennamen. Sie tippen ihn in die Suche und haben sofort Serverlizenz, STARFACE-Version und Online-Zustand vor sich – ohne die Anlage zu öffnen und ohne in einer Excel-Liste zu suchen, die seit dem letzten Update veraltet ist.
Inventarabgleich
Sobald sich eine Anlage verbindet, holt der Controller ihren Bestand ab. Erfasst werden installierte Module, Lizenzen, Systemstatus, SIP-Leitungen und der Fähigkeitskatalog. Jede Momentaufnahme trägt einen Zeitstempel – eine Anlage, die seit Tagen offline ist, zeigt deshalb weiterhin ihren letzten bekannten Stand und nicht eine leere Seite.
Aufgefrischt wird beim Verbindungsaufbau, wenn die Anlage im Lebenszeichen eine Änderung meldet, auf Knopfdruck und spätestens einmal am Tag für jede verbundene Anlage mit erteilter Berechtigung. Wann welche Angabe entsteht, steht unter Datenquellen und Aktualität.
Der Inventarabgleich liest ausschließlich über read_-Werkzeuge. Er verändert nichts auf der Anlage.
Fähigkeitsmatrix
Die Matrix beantwortet je Anlage und Bereich die Frage „geht das hier?" – und wenn nein, warum nicht. Unterschieden wird unter anderem zwischen:
| Begründung | Bedeutung |
|---|---|
| tool_disabled | Der Kunde hat dieses Werkzeug auf seiner Anlage abgeschaltet |
| module_not_installed | Das benötigte Modul ist dort nicht installiert |
| module_inactive | Das Modul ist installiert, aber nicht aktiv |
| module_not_licensed | Das Modul ist installiert, aber nicht lizenziert |
| module_version_too_old | Die installierte Modulversion kennt dieses Werkzeug noch nicht |
| delete_not_permitted | Löschende Operationen sind für diese Berechtigung nicht erlaubt |
Sie wollen bei zwölf Kunden dieselbe Einstellung anpassen. Die Matrix zeigt vorab: bei neun geht es, bei zweien fehlt die Modulversion, bei einem hat der Kunde das Werkzeug bewusst abgeschaltet. Sie sparen sich zwölf Fehlversuche und wissen, welche drei Kunden Sie vorher anrufen müssen.
Aufmerksamkeit und Meldungen der Module
Die Karte Aufmerksamkeit über der Anlagenliste zeigt, wo Sie hinsehen sollten. Zwei Arten von Einträgen stehen dort:
- Befunde, die der Controller selbst erkennt: Anlage nicht erreichbar, Leitungen nicht registriert, Backup fehlt oder schlug fehl, STARFACE-Version zu alt, Module veraltet. Diese Einträge verschwinden von selbst, sobald die Ursache behoben ist.
- Meldungen der Module: Fluxpunkt-Module auf der Anlage melden Probleme selbst, zum Beispiel ein nicht erreichbares Aufzeichnungsziel. Jede Meldung steht als eigene Zeile mit Schwere, Anlage, Modul und Alter. Wiederholt ein Modul dieselbe Meldung, zählt die Zeile hoch, statt die Karte zu füllen.
Ein Klick auf einen Eintrag filtert die Anlagenliste auf die betroffene Anlage. Meldungen der Module bestätigen Sie über das Häkchen daneben, auf Wunsch mit Begründung. Die Meldung verschwindet dann für Ihren Partnerzugang. Meldet das Modul das Problem erneut, erscheint sie wieder. Die Bestätigung steht mit Person, Zeitpunkt und Begründung in der Historie der Anlage. Andere Partner derselben Anlage bestätigen für sich und sehen Ihre Bestätigung nicht. Benutzer mit der Rolle Betrachter sehen die Einzelheiten, bestätigen aber nicht.
Am Montagmorgen meldet Call Recording bei einem Kunden: „Aufzeichnungsziel nicht erreichbar“, 7× seit Freitagabend. Sie klicken die Zeile an, sehen die Anlage, lassen den Kunden das NAS neu starten und bestätigen mit „NAS nach Stromausfall neu gestartet“. Ihr Kollege sieht später in der Historie, wer das Problem wann erledigt hat – ohne nachzufragen.
Die Meldungen sind auch über die Schnittstellen des Controllers lesbar und bestätigbar, siehe API – Aufmerksamkeit.
Was das Monitoring-Modul meldet
Ist auf einer Anlage das Modul Monitoring installiert, prüft es die Anlage laufend selbst und meldet Auffälligkeiten in diese Karte. Sie brauchen dafür keinen eigenen Monitoring-Server – der Controller wird zur Zustandsübersicht Ihrer ganzen Flotte.
| Meldung (Betreff) | Was geprüft wird | Wie oft | Plattform |
|---|---|---|---|
| Freier Festplattenplatz | freier Platz auf der Systempartition | alle 10 Minuten | alle |
| Gültigkeit des SSL-Zertifikats | Restlaufzeit des Zertifikats der Weboberfläche, Zustand der Let's-Encrypt-Erneuerung | täglich | alle |
| Festplattenzustand Modell (S/N Seriennummer) | S.M.A.R.T.-Werte jeder Festplatte bzw. SSD: Gesamtbewertung, ersetzte, schwebende und nicht korrigierbare Sektoren, Übertragungsfehler, Abnutzung und Medienfehler bei NVMe | stündlich, hinter einem MegaRAID-Controller alle 10 Minuten | nur Appliance |
| Speichermangel | ob der Kernel wegen fehlenden Arbeitsspeichers einen Prozess beenden musste | alle 10 Minuten | alle |
Jede Prüfung meldet mit den Schweren Warnung, Fehler oder kritisch und meldet sich mit Hinweis zurück, sobald der Zustand wieder in Ordnung ist. Unveränderte Befunde wiederholt das Modul höchstens einmal am Tag. Schwellenwerte und Beispiele stehen in der Doku des Moduls unter Zustandsprüfungen.
In der Karte steht bei einem Kunden: „Festplattenzustand Samsung SSD 870 EVO 500GB (S/N …) – Fehler", seit gestern 2×. Die Beschreibung nennt Modell, Seriennummer und 8 schwebende Sektoren. Sie bestellen die Ersatzplatte, vereinbaren einen Termin und bestätigen die Meldung mit „Tausch am Samstag geplant". Der Ausfall findet nie statt.
Arbeiten auf den Anlagen
Kommandos mit Probelauf
Jedes Kommando läuft entweder als Probelauf oder als Ausführung. Im Probelauf führt der Agent ausschließlich lesende Werkzeuge aus; alles Verändernde wird abgelehnt, samt Beschreibung dessen, was passiert wäre. Der Probelauf ist die Voreinstellung.
Jedes Kommando trägt ein Ablaufdatum. Es gibt kein Kommando ohne Ablauf – eines, das an einer drei Wochen offline gewesenen Anlage bei Rückkehr zündet, wäre ein Unfall mit Ansage.
Zustellung an offline gegangene Anlagen
Kommandos werden abgelegt und zugestellt, sobald die Anlage wieder verbunden ist. Läuft die Frist vorher ab, wird das Kommando als abgelaufen beantwortet und nicht mehr ausgeführt. Offene Kommandos lassen sich einsehen und abbrechen.
Serialisierung verändernder Kommandos
Auf einer Anlage läuft höchstens ein veränderndes Kommando gleichzeitig – auch dann, wenn zwei verschiedene Partner-Controller gleichzeitig etwas anstoßen. Weitere werden mit Anlage beschäftigt abgewiesen. Lesende Kommandos laufen parallel weiter.
Die Sperre liegt bewusst auf der Anlage und nicht im Controller: Zwei selbsthostende Partner wissen nichts voneinander, eine zentrale Sperre wäre wirkungslos.
Job-Orchestrierung über viele Anlagen
Das Datenmodell für Sammelaufträge über viele Anlagen – mit Auswahlregeln, Ringen und Abbruchbedingungen – steht. Die Oberfläche dazu und die vollständige Ausführungslogik entstehen gerade. Heute arbeiten Sie anlagenbezogen.
Selbst-Update des Moduls über den Kanal
Der Kanal ist genau dafür gebaut: Der Agent bestätigt die Annahme, verschwindet, kommt zurück und liefert das Ergebnis nach. Die Erfolgskontrolle ist die neue Version in der Wiederanmeldung. Der Ablauf ist im Protokoll festgelegt, aber noch nicht freigegeben.
Zugang und Nachvollziehbarkeit
Anmeldung mit lokalen Konten und Identitätsanbietern
Lokale Konten funktionieren immer, auch ohne Internet. Zusätzlich lassen sich Identitätsanbieter anbinden – Microsoft Entra ID, Google Workspace und eine STARFACE ID sind vorbereitet. Ein Konto muss in jedem Fall vorher angelegt worden sein. Details unter Zugang zur Konsole.
Rollen
Vier Rollen sind angelegt: OWNER, ADMIN, TECHNICIAN und VIEWER. Wirksam unterschieden wird heute an den Stellen, die über das Lesen der eigenen Flotte hinausgehen: Einrichtungscodes ausstellen und den Partnerportal-Abgleich starten dürfen nur OWNER und ADMIN. Die feinere Abstufung zwischen TECHNICIAN und VIEWER wird gerade ausgebaut.
Benutzerverwaltung in der Konsole
Konten und Rollen werden derzeit noch nicht über die Oberfläche gepflegt. Das erste Konto entsteht beim ersten Start des Controllers.
Protokoll der Vorgänge
Jedes von einem Menschen ausgelöste Kommando wird archiviert, mit Zeit, handelnder Person, Anlage, Werkzeug und Ausgang; die vollständige Antwort der Anlage steht 31 Tage lang zur Verfügung. Die Hash-Verkettung, die nachträgliche Änderungen am Protokoll auffallen lässt, ist im Datenmodell vorgesehen, aber noch nicht geschlossen. Mehr dazu unter Daten, Protokoll und Datenhoheit.
Ergänzende Funktionen
Abgleich mit dem STARFACE-Partnerportal
Der Controller kann Ihren Anlagenbestand aus dem STARFACE-Partnerportal einlesen, damit Sie Ihre Liste nicht von Hand aufbauen. Eingelesene Anlagen erscheinen als importiert – sie sind noch nicht angebunden und erteilen keinerlei Rechte.
Die Zugangsdaten zum Partnerportal werden für die Dauer eines Abgleichs verwendet und danach verworfen. Sie landen weder in der Datenbank noch in einem Log.
MCP-Schnittstelle des Controllers
Der Controller kann selbst als MCP-Server auftreten, sodass ein KI-Assistent im Auftrag eines Technikers die Flotte abfragen und – im Rahmen der Berechtigung – Werkzeuge auf einer Anlage aufrufen kann. Die Schnittstelle ist standardmäßig abgeschaltet und antwortet dann gar nicht. Sie muss ausdrücklich mit einem Aussteller und einer Zielgruppe für die Zugangstoken eingeschaltet werden.
Auch hier gilt: Das Token sagt nur, in welcher Tonart ein Assistent sprechen darf. Was tatsächlich möglich ist, entscheidet weiterhin die Berechtigung auf der Anlage und deren lokale Einstellungen.
Nächster Schritt
Weiter mit Betriebsmodelle und Kosten.