Aller au contenu

tc-operator

tc-operator est la commande qui installe et fait tourner un nœud Trusted Codes sur ta propre machine. Une commande sur un serveur neuf transforme la machine en un serveur d’origine complet et capable de fédération.

C’est une capacité Enterprise, et c’est la seule chose à laquelle tc-operator sert. Exploiter ton propre nœud fédéré fait partie du plan Enterprise ; l’outil existe pour installer, configurer et maintenir un tel nœud, et rien de plus. Si tu es sur un autre plan, rien sur cette page ne te concerne — l’application mobile, le client de bureau et les portails parlent tous à des serveurs que nous exploitons, et il n’y a rien pour toi à exploiter. Personne n’a besoin de tc-operator pour utiliser Trusted Codes.

Cette section est le chemin que tu parcours : décider si tu en veux un, l’installer, le configurer, le faire tourner au quotidien, et le démonter. Ce qu’est un serveur fédéré — le maillage, l’admission, ce qui passe entre les serveurs — est couvert dans la section Serveur fédéré.

Le backend complet sur ta machine : la base de données, le service de connexion, la couche REST, les fonctions edge qui portent toute la logique métier, la passerelle API, le stockage de fichiers et le temps réel. Il fait tourner le même schéma et le même code que les serveurs exploités par Trusted Codes, derrière HTTPS sur ton propre domaine.

Le nœud est backend uniquement. Les clients sont l’application mobile, le compagnon de bureau et MCP — il n’y a pas de client web à déployer. Le nœud sert bien un ensemble de surfaces web (l’application d’administration, et en option le portail utilisateur, le portail entreprise, les pages de vérification et de statut) sous ton domaine, et tu choisis lesquelles.

Les comptes, connexions, codes et coffres de tes membres vivent dans ta base de données et nulle part ailleurs.

Une machine que tu gardes en marche. La machine de référence est Ubuntu 26.04 (tout ce qui va de 22.04 fonctionne), 2 vCPU, 4 Go de RAM, 20 Go de disque. L’installateur provisionne un fichier d’échange de 4 Go. Les constructions de surfaces sont gourmandes en mémoire ; en dessous de 4 Go elles sont interrompues.

Un domaine et son DNS. Le nœud a besoin d’un enregistrement A, et chaque surface que tu actives en a besoin d’un pour elle.

Un fournisseur e-mail. Un fournisseur SMTP porte tout le courrier du nœud. Un nœud sans fournisseur ne peut accueillir personne, et démarre avec toutes les surfaces de fédération forcées à l’arrêt.

Des sauvegardes que tu fais toi-même. L’installateur ne prend un vidage de la base de données que lorsque tu désinstalles. Un nœud en marche a besoin de ton propre calendrier — et le vidage seul ne suffit pas pour restaurer. Voir Sauvegardes et restauration.

Rester à jour. Un nœud n’est pas une bifurcation privée. Les mises à jour arrivent sous forme de nouvelles archives de distribution et tu les appliques.

La facturation et les identifiants de notification push mobile restent centraux. Le plafond de droits sous lequel tourne ton nœud aussi : il est accordé et signé de façon centrale, et le rôle admin de ton nœud ne peut pas le relever. La section fédération explique pourquoi.

Lis ça avant de commencer, pas après.

  • uninstall --purge détruit le nœud et ses données. Ça prend un vidage d’abord et refuse sans --purge quand des utilisateurs réels existent, mais passé cette confirmation il n’y a pas de retour en arrière.
  • rollback ne revient en arrière que sur le code. Le schéma de la base de données est uniquement progressif et n’est pas restauré. L’ancien code tourne alors contre le schéma actuel.
  • Perdre /etc/trusted-codes/secrets.env fait perdre le nœud. Les données restaurées sont illisibles sans la clé de chiffrement d’origine, et le nœud obtient une nouvelle identité de fédération.
  • home_server ne peut pas être changé sur un nœud en marche. Le changer est une nouvelle identité : nouveau DNS, nouveau TLS, nouvelle admission.