Installer un nœud

Du conteneur clé en main au service NixOS.

Un nœud indexe la donnée Ğchange, la stocke et la sert en pair-à-pair aux autres nœuds et aux apps qui le suivent. Trois façons de l’installer :

Prérequis

• Un serveur Linux avec un bon uptime (le nœud gagne à rester allumé : il indexe en continu et sert les blocs aux autres pairs).

• Une clé d’administration : la clé publique de l’identité qui administrera le nœud. Elle s’obtient en important une phrase mnémonique Ğ1 dans l’app — écran « Mon compte », qui affiche la clé publique correspondante — ou en générant une clé dédiée. Seule la clé publique est posée sur le serveur : jamais la phrase secrète.

  --admin / TRAME_ADMIN accepte trois écritures de cette même clé (32 octets) :

  Forme	Exemple	Où on la voit
  hex (64 caractères)	6079aefe…ad1	logs du nœud, sortie CLI
  base58 « brut » (Ğ1/Duniter)	FMoatnYMuezZ…KJJe	clés Ğ1
  PeerId libp2p (12D3Koo…)	12D3KooW…	« Mon compte » de l’app

  ⚠️ Ne pas confondre cette clé avec le ticket du nœud (une longue chaîne endpoint…, qui encode une adresse réseau, pas une identité d’admin) ni avec le peerId réseau du nœud (affiché au boot, l’identité de transport, distincte de la clé d’admin). La clé d’admin est celle de votre compte Ğ1, telle qu’affichée dans « Mon compte ».

• Optionnel : un port UDP ouvert pour de la connectivité directe (voir Réglages essentiels). Par défaut, le nœud passe par les relais iroh et n’a besoin d’aucun port ouvert.

Le code est public : https://git.duniter.org/HugoTrentesaux/datapod.

Méthode 1 — Podman (clé en main)

La plus simple : récupérer le dépôt, fournir la clé admin, lancer.

git clone https://git.duniter.org/HugoTrentesaux/datapod
cd datapod

export TRAME_ADMIN=<clé-publique-hex>
podman compose -f compose.turnkey.yaml up --build

Le nœud démarre, imprime son peerId, son root (l’état de l’index) et « prêt ». Il écrit aussi son ticket (sa fiche de pair, à partager pour s’y connecter) dans ./shared/node.ticket.

Données héritées

Pour démarrer avec les données Cesium+/Ğchange déjà reprises, deux voies (cf. --state vs --import-car) :

1. Adopter un CAR de données publié en release de la forge. On le récupère par hash, puis on l’adopte tel quel :

   trame-noded --state geopod-data.car --admin <clé-publique> --network g1

   La release joint un manifeste précisant la taille de la sélection (root, nombre d’entrées, lignes par table). Ce CAR est data-only : il ne grave ni clé admin ni charte — la gouvernance est injectée par le nœud au démarrage (--admin).

2. Fusionner des archives *.car de données en les déposant dans ./import/ (chargées au boot, --car-dir).

Sans rien, le nœud démarre vide et se remplit par synchronisation avec ses pairs.

Le CAR de données est produit à partir des dumps v1 par un outil interne au dépôt de travail (non inclus dans cette distribution) ; pour un déploiement, la release ci-dessus est la source à utiliser.

Clé admin modifiable. Changer TRAME_ADMIN et relancer suffit : la gouvernance fine (modérateurs, règles d’admission) se fait ensuite par messages signés de cette clé.

Méthode 2 — Nix

Le flake.nix du dépôt est le point de build unique. Trois usages :

Lancer le binaire directement :

nix run "git+https://git.duniter.org/HugoTrentesaux/datapod#trame-noded" -- \
  --data ./data --wan --network g1 --admin <clé-publique-hex>

Construire l’image OCI (dérivée du même binaire, non-root, certificats embarqués) et la charger dans Podman :

podman load < $(nix build "git+https://git.duniter.org/HugoTrentesaux/datapod#oci-image" --print-out-paths)
# → localhost/trame-noded:latest

Une fois l’image chargée, les fichiers compose.*.yaml peuvent l’utiliser sans recompiler (retirer le bloc build:).

Construire juste le binaire :

nix build "git+https://git.duniter.org/HugoTrentesaux/datapod#trame-noded"
./result/bin/trame-noded --data ./data --wan

Méthode 3 — NixOS (service systemd)

Le flake expose un module : un service systemd durci, en utilisateur dynamique non privilégié, données dans /var/lib/trame-noded.

{
  inputs.trame.url = "git+https://git.duniter.org/HugoTrentesaux/datapod";

  # … dans la configuration de la machine :
  imports = [ inputs.trame.nixosModules.trame-noded ];

  services.trame-noded = {
    enable = true;
    network = "g1";
    admin = "<clé-publique-hex>";
    listenPort = 47811;     # port UDP fixe (optionnel)
    openFirewall = true;    # ouvre ce port
    # stateCar = "/srv/geopod/geopod-base.car";  # données héritées (optionnel)
  };
}

nixos-rebuild switch, et le nœud tourne et redémarre tout seul.

Réglages essentiels

Port fixe vs relais. En --wan, le nœud reste joignable via les relais iroh sans ouvrir de port. Pour de la connectivité directe (meilleures performances, ou plusieurs nœuds sur une même machine), fixer --listen-port et ouvrir ce port UDP (-p 47811:47811/udp en conteneur, openFirewall dans le module NixOS).

Vérifier que ça tourne

Au démarrage, le nœud écrit sur sa sortie d’erreur :

[noded] peerId  : 3afbbba3…
[noded] publish : fcd6f6d1…
[noded] admin   : 7Vbkt24p…
[noded] root    : ad4b108b… (107 entrées)
[noded] filtre  : aucun (admission par défaut — tout kind connu)
[noded] prêt. Ctrl-C / SIGTERM pour arrêter.

Trois clés distinctes :

• peerId — l’identité de transport (réseau iroh), stockée dans DIR/keys/node ;
• publish — la clé de publication (hex), stockée dans DIR/keys/publication : c’est elle qui signe les annonces d’index du nœud. C’est cette valeur qu’on communique pour être suivi comme indexeur (clé de confiance) ;
• admin — la clé de gouvernance fournie par l’opérateur (--admin).

root est l’état courant de l’index (il évolue à mesure que le nœud indexe et se synchronise). Le ticket se partage pour qu’un client ou un autre nœud s’y connecte.

ℹ️ Ces clés ne sont imprimées qu’au démarrage. Pour relire la clé de publication plus tard : journalctl -u trame-noded | grep publish (ou équivalent conteneur), et si le journal a tourné, redémarrer le service — identité et données sont préservées dans DIR.