Den Knoten betreiben

Die Arbeit an einem Knoten im Alltag ist gering. Das ist, was es gibt.

Gesundheit

sudo scripts/tc-operator/tc-operator status --config operator.yaml

Nur lesend, und es bittet dich nie, irgendetwas zu bestätigen, du kannst es also zeitgesteuert laufen lassen. Es gibt eine menschenlesbare Zusammenfassung jedes Container-Zustands aus, die Föderationsidentität des Knotens, welche Flags an sind, welche Integrationen konfiguriert sind, und den gerade laufenden Build. Es schreibt außerdem eine maschinenlesbare JSON-Zeile, sodass du einen Monitor darauf ansetzen kannst.

Führe es als root aus. Alles jenseits der Container-Zustände wird über /etc/trusted-codes/secrets.env gelesen, das nur root öffnen kann. Ohne root bekommst du die Container-Zustände und sonst nichts, und es sagt dir nicht, dass der Rest fehlt — ein unprivilegiert eingerichteter Monitor meldet also einen gesunden Knoten, ohne etwas von seiner Identität zu sehen.

Die Container, über die es berichtet, und was es bedeutet, wenn einer davon unten ist:

Container	Was er ist	Wenn er unten ist
`db`	die Datenbank — der gesamte Zustand des Knotens	alles ist unten
`auth`	Registrierung, Anmeldung, Token-Ausstellung	keine neuen Anmeldungen; ausgestellte Tokens funktionieren bis zum Ablauf
`rest`	die REST-API über der Datenbank	alle Client-Lese- und -Schreibvorgänge schlagen fehl
`functions`	die gesamte Geschäftslogik und die Föderations-Handler	App-Aktionen und Föderation schlagen fehl; rohe Auth- und REST-Antworten weiterhin
`storage`	Dateien und Blobs	Uploads und Downloads schlagen fehl; sonst nichts
`realtime`	Sync-Anstöße über WebSocket	Clients fallen auf Vordergrund-Abgleiche zurück — beeinträchtigt, nicht kaputt
`kong`	das eine Gateway vor allem davon	die gesamte API ist unerreichbar, auch wenn die Dienste laufen

Zwei weitere laufen daneben: ein WebFinger-Sidecar, über den Peers Nutzer auf deinem Knoten auflösen, und der Proxy, der TLS terminiert und die Oberflächen bereitstellt.

/etc/trusted-codes/README.md auf der Box trägt dieselbe Tabelle mit den tatsächlichen Container-Namen deines Knotens, plus wofür jede Datei in diesem Verzeichnis da ist. /etc/trusted-codes/install.log hat die vollständige Ausgabe jedes Befehls, den der Installer ausgeführt hat.

Oberflächen starten und stoppen

Welche Oberflächen aktiviert sind, kommt aus operator.yaml, aber du kannst eine zur Laufzeit ein- oder ausschalten, ohne neu zu installieren.

tc-operator service status              # je Oberfläche: aktiviert, gebaut, live
tc-operator service start my            # bei Bedarf bauen, dann bereitstellen
tc-operator service stop business       # den Vhost entfernen; das Bundle bleibt erhalten
tc-operator service restart verify
tc-operator service start all           # jede Oberfläche außer admin

Die Oberflächen sind my, business, verify, provider, status und admin.

start staged das Bundle, falls es noch nicht gebaut wurde, fügt den Vhost der Oberfläche hinzu und lädt den Proxy per Hot-Reload neu. Ein neuer Host stellt sein Zertifikat in etwa 30 bis 60 Sekunden aus; service status zeigt cert-pending, bis er antwortet, dann serving.
Eine Oberfläche braucht einen eigenen DNS-A-Record, bevor das Zertifikat ausgestellt werden kann.
admin kann nie gestoppt werden. Sie ist die Wiederherstellungs-Oberfläche.
Das ist der einzige Weg, die Bereitstellung von Oberflächen zu steuern. Die Admin-App zeigt dir den Befehl, startet oder stoppt aber selbst nie etwas — eine Webanwendung darf deinen Host nicht steuern können.

Admin-Konten

Die Admin-App deines Knotens ist rollenbasiert. Es gibt eine Rolle, die du verwendest: operator_admin. Sie verwaltet diesen Server — Nutzer, Sitzungen, Anmeldehistorie, blockierte Versuche, Organisationen, Tresore, Benachrichtigungen.

Ihr wird jede zentrale Steueroberfläche verweigert: Betreiber-Lizenzen, Berechtigungen, Pläne, Systemparameter, Marketing, und die privilegierten Aktionen dahinter. Diese Verweigerung wird bei jeder Anfrage am Server durchgesetzt, nicht nur in der Oberfläche versteckt, und es gibt keinen Weg von operator_admin zur zentralen Rolle super_admin.

Hinzufügen und Entfernen

tc-operator add-admin --email jemand@example.com
tc-operator add-admin --email jemand@example.com --revoke

Kein Terminal-Gate, idempotent, sicher, erneut auszuführen. Das Verb ist fest auf operator_admin verdrahtet und kann nie die zentrale Rolle gewähren.

Das Konto muss bereits existieren — die Person muss sich mindestens einmal angemeldet haben. add-admin gewährt nur; es legt keine Konten an. Der admin_email-Weg des Installers ist es, der das erste anlegt.

Zwei Fähigkeiten zusätzlich zur Rolle

tc-operator add-admin --email <adresse> --can-revoke
tc-operator add-admin --email <adresse> --can-reveal
tc-operator add-admin --email <adresse> --revoke --can-reveal   # nur diese Fähigkeit

can_revoke sperrt einen Peer-Server aus, in beide Richtungen. Dein erster Admin bekommt es bei der Installation, weil ein Notfallschalter, der einen Befehlszeilenschritt mitten in einem Vorfall braucht, kein Notfallschalter ist.

can_reveal demaskiert eine Adresse im Einladungsprotokoll — mit getipptem Grund, protokolliert, ratenbegrenzt — und schaltet die Aufbewahrung ein, die die wiederherstellbare Kopie überhaupt erst erzeugt. Es ist standardmäßig aus und bleibt es, bis du dich anders entscheidest. Das ist neue Offenlegung personenbezogener Daten, deshalb ist es deine bewusste Entscheidung statt einer Voreinstellung.

Ein bloßes --revoke nimmt die Rolle und alle Fähigkeiten. --revoke mit einem Fähigkeits-Flag entfernt nur diese Fähigkeit.

Anmelden

Die Admin-App erkennt, welche Methoden dein Knoten konfiguriert hat, und zeigt sie.

Passwort. Immer verfügbar, und dein erster Weg hinein: admin_email plus das einmalige Passwort, das der Installer ausgegeben hat. Es funktioniert auf einem nackten Knoten ohne E-Mail und ohne OAuth, weshalb es der garantierte Weg ist. Ändere es nach der ersten Anmeldung.
Magic Link. Braucht SMTP. Die Option bleibt verborgen, bis der Transport konfiguriert ist.
Google oder Apple. Braucht Provider-Zugangsdaten in der Umgebung des Anmeldedienstes, mit der Callback-URL deines eigenen Knotens bei Google oder Apple registriert. Der Button erscheint automatisch, sobald sie gesetzt sind.

In jedem Fall lässt der Knoten nur Nutzer mit operator_admin oder super_admin hinein. Eine erfolgreiche Anmeldung durch jeden anderen wird abgelehnt und abgemeldet.

Portal URLs

Einladungslinks und Portal-Verweise lösen zu URLs auf, die von home_server abgeleitet sind — https://my.<domain>, https://admin.<domain> und so weiter. Um sie woanders hinzeigen zu lassen, öffne die Admin-App und bearbeite sie unter This Server → Portal URLs. Änderungen wirken sofort, und ein erneuter Installationslauf überschreibt nie eine URL, die du angepasst hast.

Wenn dein Knoten unter einer Betriebslizenz läuft

sudo scripts/tc-operator/tc-operator renew-grant --config operator.yaml

Ein Lizenz-Erneuerungsversuch: Er signiert eine Bestätigung, sendet sie zentral ein, verifiziert die zurückgegebene Lizenz und speichert sie. Die Installation verdrahtet einen täglichen geplanten Job dafür, du führst das normalerweise nie von Hand aus. Er endet sauber und tut nichts, wenn die Zentrale unerreichbar ist oder keine Lizenz vorliegt, und protokolliert nach /etc/trusted-codes/renew-grant.log.

Das mTLS-Zertifikat des Knotens rotieren

Dein Knoten hält ein selbstsigniertes Client-Zertifikat, einmal bei der ersten Installation ausgestellt, gespeichert unter /etc/trusted-codes/mtls/, gültig für 398 Tage. Sein Fingerabdruck ist Teil deiner Aufnahme-Nutzlast — er ist die stabile Identität deines Knotens gegenüber der Registry, weshalb eine erneute Installation ihn absichtlich erhält und nie stillschweigend rotiert.

Rotiere nur, wenn er sich dem Ablauf nähert oder du denkst, der Schlüssel wurde offengelegt. Dafür gibt es noch keinen einzelnen Befehl:

sudo mv /etc/trusted-codes/mtls /etc/trusted-codes/mtls.old
sudo scripts/tc-operator/tc-operator install --config operator.yaml
scripts/tc-operator/tc-operator submit-admission

Die Installation prägt ein frisches Zertifikat, was einen neuen Fingerabdruck bedeutet. Die Registry vertraut dem alten weiterhin, bis jemand bei Trusted Codes den neuen Fingerabdruck außerhalb des Systems verifiziert und genehmigt — genau wie bei der ersten Installation. Behalte mtls.old, bis das geschehen ist, damit du zurückkannst.

Wie die Box geschützt ist

Jeder veröffentlichte Container-Port bindet ausschließlich an 127.0.0.1. Das ist die strukturelle Kontrolle, und sie zählt mehr, als es aussieht: Docker veröffentlicht Ports, indem es eigene Firewall-Regeln einfügt, die ufw umgehen. Eine Firewall-Sperre blockiert keinen veröffentlichten Container-Port. Ein an Loopback gebundener Port ist unabhängig davon nur von der Box selbst erreichbar. Die Firewall-Regeln auf 22, 80 und 443 sind zusätzliche Absicherung, nicht der Mechanismus.

Erreiche Postgres von deiner Workstation über einen SSH-Tunnel:

ssh -L 5432:127.0.0.1:5432 <deine-box>

Der Proxy ist der einzige Prozess, der an einen öffentlichen Port gebunden ist. Er terminiert TLS und leitet an das Gateway auf Loopback weiter.

Geheimnisse liegen nur in /etc/trusted-codes/secrets.env, Modus 0600. Die Aufnahme-Nutzlast trägt nur öffentliches Schlüsselmaterial.