De node draaien

Dagelijks werk op een node is klein. Dit is wat er is.

Gezondheid

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

Alleen-lezen, en het vraagt je nooit iets te bevestigen, dus kun je het plannen. Het print een menselijke samenvatting van de status van elke container, de federatie-identiteit van de node, welke vlaggen aan staan, welke integraties zijn geconfigureerd, en de build die op dit moment draait. Het schrijft ook een machineleesbare JSON-regel, zodat je er een monitor op kunt richten.

Draai het als root. Alles voorbij de containerstatussen wordt gelezen via /etc/trusted-codes/secrets.env, dat alleen root kan openen. Zonder root krijg je de containerstatussen en verder niets, en het vertelt je niet dat de rest ontbreekt — dus meldt een monitor die zonder rechten is ingesteld een gezonde node terwijl hij niets van zijn identiteit ziet.

De containers waarover het rapporteert, en wat het betekent als elk daarvan uit staat:

Container	Wat het is	Als het uit staat
`db`	de database — alle status van de node	alles staat uit
`auth`	registratie, aanmelden, uitgifte van tokens	geen nieuwe aanmeldingen; uitgegeven tokens werken tot ze verlopen
`rest`	de REST-API over de database	alle lees- en schrijfacties van clients mislukken
`functions`	alle businesslogica en de federatiehandlers	app-acties en federatie mislukken; ruwe auth en REST antwoorden nog wel
`storage`	bestanden en blobs	uploads en downloads mislukken; verder niets
`realtime`	synchronisatieprikkels over WebSocket	clients vallen terug op voorgrondsynchronisaties — gedegradeerd, niet stuk
`kong`	de enige gateway ervoor	de hele API is onbereikbaar, ook al staan de diensten aan

Er draaien nog twee mee: een WebFinger-sidecar, waarmee peers gebruikers op jouw node oplossen, en de proxy die TLS afhandelt en de oppervlakken aanbiedt.

/etc/trusted-codes/README.md op de doos draagt dezelfde tabel met de echte containernamen van jouw node, plus waarvoor elk bestand in die map dient. /etc/trusted-codes/install.log heeft de volledige uitvoer van elk commando dat de installer heeft gedraaid.

Oppervlakken starten en stoppen

Welke oppervlakken zijn aangezet komt uit operator.yaml, maar je kunt er tijdens het draaien een aan- of uitzetten zonder opnieuw te installeren.

tc-operator service status              # per oppervlak: aangezet, gebouwd, draait
tc-operator service start my            # bouw indien nodig, bied dan aan
tc-operator service stop business       # verwijder de vhost; de bundel blijft bewaard
tc-operator service restart verify
tc-operator service start all           # elk oppervlak behalve admin

De oppervlakken zijn my, business, verify, provider, status en admin.

start zet de bundel klaar als hij nog niet is gebouwd, voegt de vhost van het oppervlak toe en herlaadt de proxy. Een nieuwe host geeft zijn certificaat uit in ongeveer 30 tot 60 seconden; service status toont cert-pending totdat hij antwoordt, daarna serving.
Een oppervlak heeft zijn eigen DNS A-record nodig voordat het certificaat kan worden uitgegeven.
admin kan nooit worden gestopt. Het is het herstelvlak.
Dit is de enige manier om te bepalen of een oppervlak wordt aangeboden. De beheerapp toont je het commando maar start of stopt zelf nooit iets — een webapplicatie mag jouw host niet kunnen beheren.

Beheeraccounts

De beheerapp van je node is rolgebonden. Er is één rol die je gebruikt: operator_admin. Die beheert deze server — gebruikers, sessies, aanmeldgeschiedenis, geblokkeerde pogingen, organisaties, kluizen, meldingen.

Hij wordt geweigerd bij elk centraal beheeroppervlak: operatorgrants, rechten, abonnementen, systeemparameters, marketing, en de bevoorrechte acties daarachter. Die weigering wordt bij elk verzoek op de server afgedwongen, niet alleen verborgen in de interface, en er is geen pad van operator_admin naar de centrale rol super_admin.

Toevoegen en verwijderen

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

Geen terminalbevestiging, idempotent, veilig om opnieuw te draaien. Het commando is hardgecodeerd naar operator_admin en kan nooit de centrale rol toekennen.

Het account moet al bestaan — de persoon moet zich al minstens één keer hebben aangemeld. add-admin kent alleen toe; het maakt geen accounts aan. Het admin_email-pad van de installer is wat de eerste aanmaakt.

Twee capaciteiten bovenop de rol

tc-operator add-admin --email <adres> --can-revoke
tc-operator add-admin --email <adres> --can-reveal
tc-operator add-admin --email <adres> --revoke --can-reveal   # alleen die capaciteit

can_revoke snijdt een peerserver af, in beide richtingen. Je eerste beheerder krijgt dit bij install, omdat een noodcontrole die een stap op de opdrachtregel midden in een incident nodig heeft geen noodcontrole is.

can_reveal demaskeert één adres in het uitnodigingslog — een getypte reden, gecontroleerd, met snelheidslimiet — en zet de bewaring aan die de herstelbare kopie überhaupt creëert. Het staat standaard uit en blijft uit totdat jij anders beslist. Het is nieuwe blootstelling van persoonlijke data, dus is het jouw bewuste beslissing in plaats van een standaard.

Een kaal --revoke neemt de rol en alle capaciteiten weg. --revoke met een capaciteitsvlag verwijdert alleen die capaciteit.

Aanmelden

De beheerapp detecteert welke methoden jouw node heeft geconfigureerd en toont die.

Wachtwoord. Altijd beschikbaar, en je eerste manier naar binnen: admin_email plus het eenmalige wachtwoord dat de installer printte. Het werkt op een kale node zonder e-mail en zonder OAuth, wat het de gegarandeerde route maakt. Wijzig het na de eerste aanmelding.
Magic link. Vereist SMTP. De optie is verborgen totdat het transport is geconfigureerd.
Google of Apple. Vereist provider-inloggegevens in de omgeving van de aanmelddienst, met de callback-URL van jouw eigen node geregistreerd bij Google of Apple. De knop verschijnt automatisch zodra die zijn ingesteld.

In elk geval laat de node alleen gebruikers toe met operator_admin of super_admin. Een geslaagde aanmelding door iemand anders wordt geweigerd en afgemeld.

Portaal-URL’s

Uitnodigingslinks en portaalverwijzingen worden opgelost naar URL’s afgeleid van home_server — https://my.<domein>, https://admin.<domein>, enzovoort. Om ze ergens anders naartoe te wijzen, open de beheerapp en bewerk ze onder This Server → Portal URLs. Wijzigingen gaan meteen in, en de installatie opnieuw draaien overschrijft nooit een URL die je hebt aangepast.

Als jouw node onder een Operating Grant draait

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

Eén vernieuwingspoging voor de lease: het ondertekent een attestatie, plaatst die centraal, verifieert de teruggegeven grant en bewaart hem. Install regelt hiervoor een dagelijkse geplande taak, dus draai je dit normaal nooit met de hand. Het stopt netjes en doet niets als centraal onbereikbaar is of er geen grant aanwezig is, en logt naar /etc/trusted-codes/renew-grant.log.

Het mTLS-certificaat van de node roteren

Jouw node bewaart een zelfondertekend clientcertificaat, één keer uitgegeven bij de eerste installatie, opgeslagen onder /etc/trusted-codes/mtls/, 398 dagen geldig. De vingerafdruk ervan maakt deel uit van je toelatingspayload — het is de stabiele identiteit van jouw node richting het register, en daarom bewaart install opnieuw draaien hem met opzet en roteert hij hem nooit stilzwijgend.

Roteer alleen wanneer hij bijna verloopt of je denkt dat de sleutel is blootgesteld. Er is nog geen enkel commando voor:

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

Install geeft een vers certificaat uit, wat een nieuwe vingerafdruk betekent. Het register blijft de oude vertrouwen totdat iemand bij Trusted Codes de nieuwe vingerafdruk buiten om verifieert en goedkeurt — precies zoals bij de eerste installatie. Bewaar mtls.old tot dan, zodat je terug kunt.

Hoe de doos wordt beschermd

Elke gepubliceerde containerpoort bindt alleen aan 127.0.0.1. Dit is de structurele controle, en het is belangrijker dan het lijkt: Docker publiceert poorten door zijn eigen firewallregels in te voegen, die ufw omzeilen. Een firewallweigering blokkeert geen gepubliceerde containerpoort. Een aan loopback gebonden poort is hoe dan ook alleen bereikbaar vanaf de doos zelf. De firewallregels op 22, 80 en 443 zijn extra bescherming, niet het mechanisme.

Bereik Postgres vanaf je werkstation via een SSH-tunnel:

ssh -L 5432:127.0.0.1:5432 <jouw-doos>

De proxy is het enige proces gebonden aan een publieke poort. Hij handelt TLS af en stuurt door naar de gateway op loopback.

Geheimen leven alleen in /etc/trusted-codes/secrets.env, modus 0600. De toelatingspayload draagt alleen publiek sleutelmateriaal.