Aller au contenu

Faire tourner le nœud

Le travail quotidien sur un nœud est réduit. Voici ce qu’il y a.

Fenêtre de terminal
sudo scripts/tc-operator/tc-operator status --config operator.yaml

En lecture seule, et ça ne te demande jamais de confirmer quoi que ce soit, donc tu peux le planifier. Ça imprime un résumé humain de l’état de chaque conteneur, l’identité de fédération du nœud, quels drapeaux sont actifs, quelles intégrations sont configurées, et la version en cours d’exécution. Ça écrit aussi une ligne JSON lisible par machine, pour que tu puisses y pointer un moniteur.

Lance-le en root. Tout ce qui va au-delà des états des conteneurs est lu via /etc/trusted-codes/secrets.env, que seul root peut ouvrir. Sans root, tu obtiens les états des conteneurs et rien d’autre, et ça ne te dit pas que le reste manque — donc un moniteur mis en place sans privilège rapporte un nœud sain tout en ne voyant rien de son identité.

Les conteneurs qu’il rapporte, et ce que signifie chacun d’eux arrêté :

ConteneurCe que c’estS’il est arrêté
dbla base de données — tout l’état du nœudtout est arrêté
authinscription, connexion, émission de jetonspas de nouvelle connexion ; les jetons déjà émis fonctionnent jusqu’à expiration
restl’API REST sur la base de donnéestoutes les lectures et écritures des clients échouent
functionstoute la logique métier et les gestionnaires de fédérationles actions de l’app et la fédération échouent ; auth et REST bruts répondent encore
storagefichiers et blobstéléversements et téléchargements échouent ; rien d’autre
realtimesignaux de synchronisation sur WebSocketles clients basculent sur des balayages au premier plan — dégradé, pas cassé
kongla passerelle unique devant tout çatoute l’API est injoignable même si les services tournent

Deux autres tournent à côté : un agent WebFinger, qui est ce qui permet aux pairs de résoudre les utilisateurs sur ton nœud, et le proxy qui termine le TLS et sert les surfaces.

/etc/trusted-codes/README.md sur la machine porte le même tableau avec les vrais noms de conteneurs de ton nœud, plus ce à quoi sert chaque fichier de ce répertoire. /etc/trusted-codes/install.log a la sortie complète de chaque commande que l’installateur a lancée.

Quelles surfaces sont actives vient de operator.yaml, mais tu peux en activer ou désactiver une au moment de l’exécution sans réinstallation.

Fenêtre de terminal
tc-operator service status # par surface : activée, construite, servie
tc-operator service start my # construit si nécessaire, puis sert
tc-operator service stop business # retire le vhost ; le paquet est conservé
tc-operator service restart verify
tc-operator service start all # chaque surface sauf admin

Les surfaces sont my, business, verify, provider, status et admin.

  • start met en scène le paquet s’il n’a pas été construit, ajoute le vhost de la surface et recharge le proxy à chaud. Un nouvel hôte émet son certificat en environ 30 à 60 secondes ; service status montre cert-pending jusqu’à ce qu’il réponde, puis serving.
  • Une surface a besoin de son propre enregistrement A DNS avant que le certificat puisse s’émettre.
  • admin ne peut jamais être arrêtée. C’est la surface de récupération.
  • C’est la seule façon de contrôler le service des surfaces. L’application d’administration te montre la commande mais ne démarre ni n’arrête jamais rien elle-même — une application web ne doit pas pouvoir contrôler ta machine.

L’application d’administration de ton nœud est verrouillée par rôle. Il y a un rôle que tu utilises : operator_admin. Il administre ce serveur — utilisateurs, sessions, historique de connexion, tentatives bloquées, organisations, coffres, notifications.

Il se voit refuser toute surface de contrôle centrale : licences d’exploitant, droits, plans, paramètres système, marketing, et les actions privilégiées derrière eux. Ce refus est appliqué au niveau du serveur à chaque requête, pas seulement caché dans l’interface, et il n’y a aucun chemin de operator_admin vers le rôle central super_admin.

Fenêtre de terminal
tc-operator add-admin --email someone@example.com
tc-operator add-admin --email someone@example.com --revoke

Pas de verrou terminal, idempotent, sûr à relancer. Le verbe est figé sur operator_admin et ne peut jamais accorder le rôle central.

Le compte doit déjà exister — la personne doit s’être connectée au moins une fois. add-admin n’accorde que ; ça ne crée pas de comptes. Le chemin admin_email de l’installateur est ce qui crée le premier.

Fenêtre de terminal
tc-operator add-admin --email <addr> --can-revoke
tc-operator add-admin --email <addr> --can-reveal
tc-operator add-admin --email <addr> --revoke --can-reveal # cette capacité seulement

can_revoke coupe un serveur pair, dans les deux directions. Ton premier admin l’obtient à l’installation, parce qu’un contrôle d’urgence qui nécessite une étape en ligne de commande en pleine crise n’est pas un contrôle d’urgence.

can_reveal démasque une adresse dans le journal des invitations — une raison tapée, auditée, limitée en débit — et active la rétention qui crée la copie récupérable en premier lieu. C’est désactivé par défaut et le reste tant que tu n’en décides pas autrement. C’est une nouvelle exposition de données personnelles, donc c’est ta décision consentie plutôt qu’un défaut.

Un simple --revoke retire le rôle et toutes les capacités. --revoke avec un drapeau de capacité ne retire que cette capacité.

L’application d’administration détecte quelles méthodes ton nœud a configurées et les montre.

  • Mot de passe. Toujours disponible, et ta première façon d’entrer : admin_email plus le mot de passe à usage unique que l’installateur a imprimé. Ça fonctionne sur un nœud nu sans e-mail ni OAuth, ce qui explique pourquoi c’est le chemin garanti. Change-le après la première connexion.
  • Lien magique. Nécessite le SMTP. L’option est cachée tant que le transport n’est pas configuré.
  • Google ou Apple. Nécessite des identifiants fournisseur dans l’environnement du service d’authentification, avec l’URL de rappel de ton propre nœud enregistrée chez Google ou Apple. Le bouton apparaît automatiquement une fois réglés.

Dans tous les cas, le nœud n’admet que les utilisateurs détenant operator_admin ou super_admin. Une connexion réussie de quelqu’un d’autre est rejetée et déconnectée.

Les liens d’invitation et les références de portail se résolvent vers des URL dérivées de home_server — https://my.<domaine>, https://admin.<domaine>, et ainsi de suite. Pour les pointer ailleurs, ouvre l’application d’administration et édite-les sous Ce serveur → URL des portails. Les changements prennent effet immédiatement, et relancer l’installation n’écrase jamais une URL que tu as personnalisée.

Si ton nœud tourne sous une licence d’exploitation

Section intitulée « Si ton nœud tourne sous une licence d’exploitation »
Fenêtre de terminal
sudo scripts/tc-operator/tc-operator renew-grant --config operator.yaml

Une tentative de renouvellement de bail : ça signe une attestation, la poste de façon centrale, vérifie la licence retournée et la stocke. L’installation branche une tâche planifiée quotidienne pour ça, donc tu ne le lances normalement jamais à la main. Ça se termine proprement et ne fait rien si le central est injoignable ou qu’aucune licence n’est présente, et ça journalise dans /etc/trusted-codes/renew-grant.log.

Ton nœud détient un certificat client auto-signé, émis une fois à la première installation, stocké sous /etc/trusted-codes/mtls/, valide 398 jours. Son empreinte fait partie de ta charge d’admission — c’est l’identité stable de ton nœud vis-à-vis du registre, ce qui explique pourquoi relancer l’installation la préserve délibérément et ne la renouvelle jamais en silence.

Renouvelle-le seulement quand il approche de l’expiration ou que tu penses que la clé a été exposée. Il n’y a pas encore de commande unique pour ça :

Fenêtre de terminal
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

L’installation frappe un certificat neuf, ce qui signifie une nouvelle empreinte. Le registre fait encore confiance à l’ancienne jusqu’à ce que quelqu’un chez Trusted Codes vérifie la nouvelle empreinte hors bande et l’approuve — exactement comme à la première installation. Garde mtls.old jusque-là, pour pouvoir revenir en arrière.

Chaque port de conteneur publié se lie à 127.0.0.1 uniquement. C’est le contrôle structurel, et ça compte plus qu’il n’y paraît : Docker publie les ports en insérant ses propres règles de pare-feu, qui contournent ufw. Un refus de pare-feu ne bloque pas un port de conteneur publié. Un port lié au bouclage n’est joignable que depuis la machine elle-même, quoi qu’il arrive. Les règles de pare-feu sur 22, 80 et 443 sont une défense en profondeur, pas le mécanisme.

Atteins Postgres depuis ton poste de travail par un tunnel SSH :

Fenêtre de terminal
ssh -L 5432:127.0.0.1:5432 <ta-machine>

Le proxy est le seul processus lié à un port public. Il termine le TLS et transmet vers la passerelle en bouclage.

Les secrets ne vivent que dans /etc/trusted-codes/secrets.env, mode 0600. La charge d’admission ne porte que du matériel de clé publique.