Modules d'administration

Note

Un module d’administration s’occupe des fonctionnalités spécifiques au système pour les administrateurs.

👑 darkone.admin.fleet-update

Outil de mise à jour de la flotte (fleet-update) et son exécution quotidienne sans surveillance.

enable installe l’outil sur un hôte de déploiement ; just fleet-update l’exécute ensuite. timer.enable ajoute une exécution quotidienne fleet-update --no-ui : mise à jour du flake, build, tests par vagues, switch.

Identité de service

L’exécution appartient à user, propriétaire de workDir : identité git, clé age sops, identifiants IA et Matrix. Elle a besoin d’un sudo sans mot de passe (permissions de just clean, identité de déploiement nix dont la clé se trouve dans ~nix/.ssh).

Outils IA

--ai-model lance claude ou opencode depuis le PATH. Déclarez ce que l’exécution non supervisée peut atteindre dans aiPackages ; sans cela, l’exécution avertit une fois et continue sans IA.

Contexte IA

aiContext (langue, style) est écrit dans /etc/fleet-update/ai-context : chaque exécution sur l’hôte le lit, just fleet-update comme le timer.

Codes de sortie

4 (une exécution détient déjà le verrou) compte comme un succès : aucune alerte. Toute autre défaillance fait échouer l’unité et déclenche l’alerte SystemdUnitFailed existante, tout comme une exécution toujours en cours après timer.timeout.

Activation sur l’hôte d’administration

darkone.admin.fleet-update = {
  enable = true;
  user = "admin";
  timer.enable = true;
};

• enable bool fleet-update, l’outil de mise à jour et de déploiement de la flotte

• package package Le paquet fleet-update. Son nix-eval-jobs est aligné sur le Nix du système : l’outil évalue le flake consommateur avec celui-ci.

• aiPackages listOf package Outils IA accessibles depuis l’exécution non supervisée (--ai-model). Facultatif : l’outil avertit et continue sans IA quand aucun n’est trouvé.

  Ce n’est pas une dépendance du paquet, car pkgs.claude-code est non libre et imposerait allowUnfree à chaque consommateur. pkgs.opencode est en MIT.

• aiContext nullOr str Consignes opérateur (langue, style) incluses dans chaque prompt IA d’une exécution sur cet hôte, just fleet-update comme le timer. Écrit dans /etc/fleet-update/ai-context, même sans enable : en co-développement, la recette exécute les sources. --ai-context, sur la ligne de commande ou dans timer.extraArgs, le remplace.

• user nullOr str Compte exécutant la mise à jour non supervisée : propriétaire de workDir, détenant l’identité git, la clé age sops et les identifiants IA et Matrix.

• workDir str Espace de travail consommateur sur disque. Pas l’argument de module workDir, qui est sa copie dans le store nix.

• timer.enable bool l’exécution quotidienne non supervisée (fleet-update --no-ui)

• timer.onCalendar str Quand l’exécution démarre (systemd OnCalendar).

• timer.extraArgs listOf str Options passées après --no-ui, que le module définit toujours.

• timer.timeout str Durée maximale d’une exécution avant que systemd l’arrête (TimeoutStartSec). Une exécution bloquée détiendrait sinon le verrou, et toute exécution ultérieure sortirait avec 4 sans aucune alerte.

darkone.admin.fleet-update = {
  enable = false;
  package = pkgs.fleet-update.override { nix-eval-jobs = nixEvalJobs; };
  aiPackages = [ ];
  aiContext = "Answer in French and keep the response concise.";
  user = "admin";
  workDir = "/etc/nixos";
  timer.enable = false;
  timer.onCalendar = "*-*-* 04:00";
  timer.extraArgs = [ ];
  timer.timeout = "6h";
};

---

👑 darkone.admin.locate

Localiseur d’hôtes du parc (dnf-locate) : ssh retrouve un hôte où qu’il soit branché.

Un nom de parc se résout vers l’adresse maison de l’hôte. Dès que l’hôte roame (autre zone, ou dehors sur le tailnet), chaque ssh nix@<host> — colmena, fleet-update, just enter — viserait cette adresse morte. Activé sur un hôte d’administration, un ProxyCommand route ces connexions via dnf-locate.

Chemins essayés, tous dérivés de la topologie :

• <host> : adresse maison, seule en premier — le cas courant coûte une seule résolution ;
• <host>.<zone domain> : réservation que chaque zone tient pour les hôtes visiteurs ;
• <host>.tailnet.internal : adresse tailnet (les passerelles de zone la résolvent).

Le premier chemin qui répond sur le port l’emporte.

Plages du parc uniquement

Un chemin alternatif ne compte que si son adresse se situe dans sa propre plage (sous-réseau de zone, tailnet). Un enregistrement joker du domaine public résout n’importe quel nom, et le compte nix ne fige aucune clé d’hôte : le déploiement atterrirait chez un inconnu.

Où est mon hôte ?

dnf-locate --print <host> affiche le chemin qui répond, ou échoue.

• enable bool Routage de ssh vers les hôtes du parc via dnf-locate (maison, réservations de zone, tailnet).

darkone.admin.locate.enable = config.darkone.admin.nix.enable;

---

👑 darkone.admin.nix

Configuration NixOS pour l’ordinateur de l’administrateur du réseau local.

Ferme de compilation (builders distants)

Un hôte admin compile chaque fermeture (closure) de nœud en local et la pousse (buildOnTarget vide, voir just/project.just), c’est donc lui qui compile réellement. Tout hôte de la flotte marqué build-farm dans config.yaml devient l’un de ses nix.buildMachines, accessible en SSH via l’utilisateur de déploiement nix.

La délégation est volontairement restreinte. mandatoryFeatures (par défaut big-parallel) signifie que la ferme ne reçoit que les dérivations qui déclarent requiredSystemFeatures = [ "big-parallel" ] : kernel, chromium, firefox, llvm, rustc… c’est-à-dire les compilations longues pour lesquelles une machine puissante est souhaitée. Le reste reste local, ce qui est important lorsque la ferme se trouve derrière une liaison montante lente : seul le résultat demandé remonte.

Ne retirez jamais big-parallel des nix.settings.system-features de cet hôte pour forcer la délégation : le conserver signifie qu’une ferme injoignable fait échouer le hook de compilation et que la dérivation est simplement construite en local au lieu d’échouer.

Clé de déploiement requise

sshKey pointe vers la clé de déploiement partagée générée par just configure-admin-host sous le répertoire personnel de l’utilisateur nix. Les hôtes admin la détiennent par construction ; un hôte qui active ce module sans la clé enregistre des échecs SSH sur chaque compilation déléguée.

Pas de cache binaire, et pourquoi

Un harmonia sur la ferme partagerait ses résultats de compilation, mais harmonia dessert la totalité de /nix/store et ne peut pas exprimer « uniquement ce que j’ai compilé » : il intercepte le trafic que le cache public devrait gérer. Le délestage relève de la planification de compilation, pas de la substitution — d’où buildMachines ici et un substituteur de dernier recours dans service/nix-cache.nix.

• enable bool Activer les outils de configuration NIX builder
• enableNh bool Activer l’outil de gestion nix helper (nh)
• remoteBuilders.enable bool Délester les compilations vers les hôtes de la flotte marqués build-farm dans config.yaml. Inactif tant qu’aucun hôte ne porte ce marqueur.
• remoteBuilders.maxJobs int Nombre de slots de compilation parallèles à utiliser sur chaque ferme.
• remoteBuilders.speedFactor int Vitesse relative de compilation d’une ferme, par rapport à cet hôte.
• remoteBuilders.mandatoryFeatures listOf str Caractéristiques qu’une dérivation DOIT exiger pour qu’une ferme lui soit proposée. C’est ce qui empêche les petites dérivations d’emprunter une liaison distante (potentiellement lente). Une liste vide envoie toutes les dérivations éligibles à la ferme.
• remoteBuilders.supportedFeatures listOf str Caractéristiques système qu’une ferme peut fournir.
• remoteBuilders.systems listOf str Plateformes pour lesquelles une ferme compile. Valeurs explicites plutôt que déduites : hosts.nix ne contient une architecture que lorsqu’elle diffère de la valeur par défaut.

darkone.admin.nix = {
  enable = false;
  enableNh = false;
  remoteBuilders.enable = true;
  remoteBuilders.maxJobs = 8;
  remoteBuilders.speedFactor = 2;
  remoteBuilders.mandatoryFeatures = [ ];
  remoteBuilders.supportedFeatures = [ ];
  remoteBuilders.systems = [ ];
};

---

👑 darkone.admin.welcome

Page de bienvenue au premier démarrage de l’hôte admin installée par darkone new.

À la première session GNOME de chaque membre de wheel, le navigateur ouvre une page locale : étape 1 sur 4 terminée (l’hôte admin), puis la passerelle, puis les services et le serveur de coordination, avec des liens vers la documentation. Affichée une seule fois par utilisateur (~/.local/state/dnf/welcome-shown). Le lanceur « Onboarding » de nix-admin la rouvre (darkone.admin.welcome.page).

Défini par l’installateur

darkone new écrit darkone.admin.welcome.enable = true; dans le configuration.nix de l’hôte admin. Supprimez la ligne pour arrêter la page pour les utilisateurs qui ne l’ont pas encore vue.

• enable bool la page de bienvenue au premier démarrage de l’hôte admin
• page path La page de bienvenue, un fichier HTML du store

darkone.admin.welcome = {
  enable = false;
  page = page;
};

---