Modules de service

Note

Un module de service fournit un service prêt à l’emploi (démon).

✨ darkone.service.adguardhome

AdGuard Home entièrement configuré pour passerelle / routeur local.

Note

Cette configuration lit la conf network dans le fichier config.yaml. Elle utilise le module DNF dnsmasq comme DNS amont et DHCP.

• enable bool Active le service adguardhome local

darkone.service.adguardhome.enable = false;

✨ darkone.service.ai

Intelligence artificielle locale (open-webui + ollama + llms).

• enable bool Activer le service d’IA local

darkone.service.ai.enable = false;

✨ darkone.service.audio

Services audio : alsa, pulse (pas jack pour le moment). Ajoute automatiquement les utilisateurs au groupe audio quand il est activé.

• enable bool Activer le système sonore

darkone.service.audio.enable = false;

✨ darkone.service.dnsmasq

dnsmasq pré-configuré pour la passerelle / routeur local.

Note

Cette configuration lit la conf network dans le fichier config.yaml. C’est la fonctionnalité essentielle de la passerelle locale.

Hôtes venant d’une autre zone

Chaque zone réserve <ipPrefix>.6.0/24 pour les hôtes dont le domicile est ailleurs. Le générateur émet, dans zone.extraDnsmasqSettings, un dhcp-host par MAC de flotte connu non natif ici, plus un host-record liant <host>.<this-zone-domain> à cette adresse, de sorte qu’une machine branchée sur la mauvaise zone (installation d’une passerelle, ordinateur portable en itinérance) obtienne quand même un bail et un nom prévisibles. Son nom court continue de résoudre vers son adresse de domicile. zone.roaming expose la même table à l’outillage d’installation.

• enable bool Active le service dnsmasq local

darkone.service.dnsmasq.enable = false;

---

✨ darkone.service.docs

Un module LaSuite Docs entièrement configuré.

• enable bool Activer le service de documentation local
• s3Host str Nom d’hôte du backend S3
• s3Port port Port du backend S3
• s3Bucket str Nom du bucket S3 pour le stockage des documents

darkone.service.docs = {
  enable = false;
  s3Host = "127.0.0.1";
  s3Port = dnfConfig.network.ports.garage;
  s3Bucket = "docs";
};

---

✨ darkone.service.element

Client web Element pour le service matrix local.

• enable bool Activer le service element local

darkone.service.element.enable = false;

✨ darkone.service.fail2ban

Module fail2ban spécifique à DNF.

• enable bool Activer fail2ban avec les spécificités DNF

darkone.service.fail2ban.enable = false;

✨ darkone.service.forgejo

Une forge git forgejo entièrement configurée.

Accès SSH

Push/pull par SSH passe par AuthorizedKeysCommand et non par le fichier authorized_keys que Forgejo écrit dans son répertoire personnel : core.nix définit authorizedKeysInHomedir = false, donc sshd ne lit jamais ce fichier.

• enable bool Active le service forgejo local

darkone.service.forgejo.enable = false;

---

✨ darkone.service.garage

Un service Garage S3 local entièrement configuré.

Fournit un stockage d’objets interne compatible S3 accessible uniquement sur 127.0.0.1:3900.

Création manuelle des buckets

Les buckets ne sont PAS créés automatiquement par ce module. Chaque service consommateur provisionne son propre bucket et sa clé d’accès via une unité systemd oneshot dédiée ordonnée After= garage-init.service. Les identifiants de chaque consommateur sont stockés dans sops en tant que garage-<consumer>-key-id et garage-<consumer>-key-secret, importés dans Garage au premier démarrage.

Migration vers un cluster multi-nœuds

Nœud unique, replication_factor = 1. Pour évoluer vers un cluster multi-nœuds, augmenter replication_factor, exposer rpc_public_addr sur le maillage, et étendre garage-init pour piloter un layout multi-nœuds.

Initialisation du layout du cluster

En cas d’échec, attendre que le service garage soit pleinement opérationnel, puis le redémarrer.

• enable bool Activer le service Garage S3 local
• srvPort port Port de l’API S3 exposé sur l’IP interne
• s3Region str Nom de la région S3 (doit correspondre à la config du consommateur)
• capacity str Indication de capacité de stockage du nœud transmise à garage layout assign. Utilisée uniquement au premier démarrage pour l’initialisation du layout ; n’agit pas comme un quota strict sur le système de fichiers sous-jacent. Suffixes pris en charge : B, KB, MB, GB, TB, PB.

darkone.service.garage = {
  enable = false;
  srvPort = srvPort;
  s3Region = s3Region;
  capacity = "500GB";
};

---

✨ darkone.service.geneweb

GeneWeb — Service de généalogie puissant.

Service en cours de validation

Wrapper DNF autour du module nixpkgs (issu de PR #522751 🡕).

Déclaration de base de données

Pour déclarer un fichier base.gw (répertoire par défaut : /var/lib/geneweb), ajoutez ceci dans votre configuration serveur :

services.geneweb.databases.base = {};

Secrets SOPS

L’option enablePasswords lit les mots de passe friend et wizard depuis les secrets sops geneweb-friend et geneweb-wizard. Si activée, ajoutez les entrées dans usr/secrets/ avant de rebuild, sinon l’activation sops-nix échouera.

Note importante : Les mots de passe Sops doivent être envoyés en texte clair au démon Geneweb. Pour plus de sécurité, il est préférable de définir ces mots de passe dans le fichier de configuration de la base de données (your-base.gwf) plutôt que d’utiliser enablePasswords.

• enable bool Activer le service de généalogie GeneWeb local
• enablePasswords bool Activer les mots de passe sops (non recommandé)

darkone.service.geneweb = {
  enable = false;
  enablePasswords = false;
};

---

✨ darkone.service.harmonia

Harmonia : serveur local de cache binaire Nix (sert le /nix/store de cet hôte).

Expose les chemins du store locaux construits / réalisés en HTTP simple (port 5000), signés avec la clé de cache binaire propre au déploiement. Active par hôte depuis etc/config.yaml (services.harmonia), comme tout autre service DNF.

Comment harmonia fonctionne avec le proxy nix-cache

Harmonia est une source de paquets, servie directement aux clients par le LAN (in-zone) ou le tailnet (lorsqu’elle est marquée global). Le proxy nix-cache par zone est un sujet distinct : il met en cache le cache binaire public (cache.nixos.org), jamais harmonia.

Les substituers de chaque hôte de zone locale deviennent, par ordre de priorité :

• les instances harmonia de sa propre zone (priorité la plus haute, LAN), puis
• tout harmonia marqué global (généralement sur le HCS, par le tailnet), puis
• le proxy nix-cache de la zone (cache public).

Cet ordre est épinglé côté client avec ?priority= sur chaque URL de substituer (voir nix-cache.nix), car le priority défini ci-dessous est identique sur chaque instance et Nix trie les substituers par priorité annoncée, pas par l’ordre de la liste.

Un hôte exécutant harmonia ne reçoit pas sa propre instance comme substituer : elle ne servirait que des chemins que son store local possède déjà.

Un hôte de zone globale (www) n’a ni LAN ni proxy : son seul substituer de flotte est l’harmmonia global, par le tailnet.

Les harmonia non globaux des autres zones ne sont jamais utilisés. La signature d’harmmonia est transmise inchangée, si bien que chaque hôte fait confiance à la clé publique harmonia propre au déploiement (usr/secrets/harmonia.pub). Le transport est en HTTP simple sur le LAN / VPN de confiance : l’intégrité vient de la signature NAR, pas de TLS.

Provision de la clé de signature

just configure-admin-host génère automatiquement la paire de clés propre au déploiement lorsque usr/secrets/harmonia.pub est absent : la clé publique est commitée et la clé privée est injectée dans le secret sops harmonia-secret-key.

Avertissement de démarrage bénin au sujet des permissions de la clé

WARN harmonia_cache::tls: /run/credentials/harmonia.service/sign-key-0 has insecure permissions 0o440; recommend 0600 est un faux positif : systemd expose les fichiers LoadCredential possédés par root en mode 0440 avec une ACL qui n’accorde l’accès qu’à l’utilisateur du service (systemd/systemd#29435) ; harmonia vérifie naïvement les bits du chmod. Surveillez néanmoins l’amont : harmonia rejette déjà à l’amarrage les clés TLS lisibles par le groupe — si cette politique s’étendait un jour aux clés de signature, cette unité cassera à la mise à jour.

• enable bool Activer un serveur de cache binaire Nix Harmonia local

darkone.service.harmonia.enable = false;

---

✨ darkone.service.headscale.audit

DNF headscale : headscale-audit. Doc : en-tête de ../headscale.nix.

---

✨ darkone.service.headscale.dns

DNF headscale : DNS pivot du tailnet. Doc : en-tête de ../headscale.nix.

---

✨ darkone.service.headscale.enroll

DNF headscale : dnf-tailnet-enroll. Doc : en-tête de ../headscale.nix.

---

✨ darkone.service.headscale

Un service headscale entièrement configuré pour le HCS.

La politique ACL du tailnet est générée depuis la topologie (zones, hôtes, utilisateurs) par dnfLib.mkHeadscalePolicy, validée par headscale policy check à la construction, puis rechargée au changement (SIGHUP) sans redémarrer headscale.

• Les machines sont taguées : tag:hcs, tag:gw-<zone>, tag:admin (hôte dont groups contient admin).
• Les machines et les LAN de zone joignent les autres. Appareils personnels : DNS et HTTPS sur le HCS, HTTPS sur les passerelles de zone (toutes les zones pour les admin, sinon leurs groupes zone-*). SSH depuis les postes d’admin et policy.adminDevices.
• Les appareils personnels se connectent via Kanidm (OIDC), pour les membres du groupe Kanidm tailnet ; leurs clés expirent après nodeExpiry.

darkone.service.headscale.policy.adminDevices.phone-alice = "100.64.0.9";

Mode ouvert

policy.enforce = false conserve les identités mais autorise tout trafic : pour une migration uniquement, pendant que les nœuds sont tagués.

Indisponibilité de Kanidm

headscale démarre quand même sans Kanidm et bascule sur l’enregistrement CLI jusqu’à son prochain redémarrage. Les nœuds déjà enregistrés ne sont pas affectés.

Sous-modules (headscale/) :

• dns.nix : unbound, le DNS pivot du tailnet et sa vue tailnet-machines ;
• audit.nix : headscale-audit, nœuds actifs confrontés à la topologie déclarée ;
• enroll.nix : dnf-tailnet-enroll, derrière just tailnet-enroll.

DNS pivot (dns.nix)

unbound sur le HCS. Les noms internes l’atteignent par le split DNS de headscale ; il relaie chaque domaine de zone vers la passerelle de zone, le reste vers Quad9 par TLS.

Vue tailnet-machines : les nœuds tagués (HCS mis à part) reçoivent l’adresse LAN de zone des services globaux qu’une zone dessert (git.<domain> sur une passerelle), tous les autres reçoivent l’adresse publique. unbound-tailnet-view liste leurs IP de tailnet depuis headscale, déclarées nulle part ailleurs.

Audit (audit.nix)

headscale-audit, toutes les 15 min : nœuds actifs confrontés à la topologie déclarée. Métriques pour les alertes dnf-headscale-<zone>, détails dans son journal. Ne tague ni ne supprime jamais.

Enrôlement (enroll.nix)

dnf-tailnet-enroll, côté root de just tailnet-enroll : clés à usage unique taguées depuis la topologie déclarée ; le nœud enrôlé reçoit son nom et ses tags déclarés.

• enable bool Activer le service DNF headscale
• enableGRPC bool Ouvrir le port TCP GRPC
• nodeExpiry str Expiration des clés des appareils personnels (0 : jamais). Les machines taguées n’expirent jamais.
• policy.enforce bool ACL du tailnet en refus par défaut. false autorise tout trafic, pour une migration uniquement.
• policy.adminDevices attrs Appareils personnels autorisés en SSH sur chaque machine et zone : nom -> IPv4 de tailnet.
• policy.exitNodeSources listOf str Sources de politique autorisées à utiliser le HCS comme nœud de sortie.
• policy.extraHosts attrs Alias d’hôte de politique supplémentaires (nom -> CIDR), à utiliser dans extraAcls.
• policy.extraAcls listOf (attrsOf anything) Règles ACL ajoutées après celles générées.
• shared raw Valeurs headscale partagées avec les sous-modules headscale/.

darkone.service.headscale = {
  enable = false;
  enableGRPC = false;
  nodeExpiry = "180d";
  policy.enforce = true;
  policy.adminDevices = { };
  policy.exitNodeSources = [ ];
  policy.extraHosts = { };
  policy.extraAcls = [ ];
  shared = {
        inherit
          policy
          auditSpec
          idmUrl
          hcsTailnetIpv4
          ;
      };
};

---

✨ darkone.service.home-assistant

Un Home Assistant avec certains plugins (en cours).

• enable bool Activer home-assistant

darkone.service.home-assistant.enable = false;

✨ darkone.service.homepage

Tableau de bord de page d’accueil configuré dynamiquement pour votre réseau local.

Note

Pour chaque service DNF activé, une entrée est automatiquement ajoutée à la configuration de la page d’accueil.

• enable bool Activer le tableau de bord de la page d’accueil + httpd + hôte
• protect bool Restreindre la page d’accueil aux utilisateurs Kanidm authentifiés (oauth2-proxy forward auth)
• localServices listOf attrs Services à ajouter dans la section Applications locales
• globalServices listOf attrs Services communs du réseau & accessibles publiquement
• remoteServices listOf attrs Services à ajouter dans la section Applications distantes
• bookmarks listOf attrs Remplacer les favoris par défaut (liens)
• widgets listOf attrs Remplacer les widgets par défaut

darkone.service.homepage = {
  enable = false;
  protect = true;
  localServices = [ ];
  globalServices = [ ];
  remoteServices = [ ];
  bookmarks = [ ];
  widgets = [ ];
};

---

✨ darkone.service.idm.provision

DNF idm : provision Kanidm. Doc : en-tête de ../idm.nix.

• oauth2 attrs Gabarits de client OAuth2/OIDC fournis par les modules de service. Kanidm provisionne un client par entrée correspondante dans network.services, avec clientId = dnfLib.oauth2ClientName.
  • enable bool Provisionner ou non des clients OAuth2 pour ce gabarit.
  • clientName nullOr str Remplace le nom de client kanidm. Par défaut dnfLib.oauth2ClientName.
  • displayName str Nom lisible affiché sur l’écran de consentement kanidm.
  • imageFile path Icône de l’application. Renvoyée à chaque exécution de kanidm-provision.
  • redirectPaths listOf str Chemins de redirection OAuth2 (un par URL de rappel acceptée).
  • landingPath str Chemin du point d’entrée de connexion automatique sur le service.
  • enableLegacyCrypto bool Autoriser les algorithmes de signature JWT hérités (ex. RS256).
  • allowInsecureClientDisablePkce bool Désactiver PKCE sur le client (uniquement pour les clients qui ne l’implémentent pas).
  • preferShortUsername nullOr bool Utiliser le nom d’utilisateur court (sans domaine) dans la revendication preferred_username.
  • extra attrs Attributs supplémentaires fusionnés dans le client provisionné (claimMaps, etc).

darkone.service.idm.provision = {
  oauth2.enable = true;
  oauth2.clientName = null;
  oauth2.displayName = null;
  oauth2.imageFile = null;
  oauth2.redirectPaths = [ ];
  oauth2.landingPath = "/";
  oauth2.enableLegacyCrypto = false;
  oauth2.allowInsecureClientDisablePkce = false;
  oauth2.preferShortUsername = null;
  oauth2.extra = { };
};

---

✨ darkone.service.idm.replication

DNF idm : réplication Kanidm. Doc : en-tête de ../idm.nix.

• replication raw Faits de réplication de ce nœud.

darkone.service.idm.replication.replication = { inherit isMainReplica isReplConsumer; };

---

✨ darkone.service.idm

Service DNF Kanidm (gestionnaire d’identités).

Les secrets sont générés, pas saisis

just configure-admin-host crée chaque entrée lue par ce module : les mots de passe du compte break-glass (kanidm-admin-password, kanidm-idm-admin-password), la paire auto-signée de l’écouteur HTTPS interne (kanidm-tls-chain / kanidm-tls-key, 10 ans, CN=127.0.0.1) et un oidc-secret-<client> par client OAuth2 provisionné. Relisez-les avec just sops aux rares occasions où un admin en a besoin.

Sous-modules (idm/) :

• replication.nix : réplication en lecture seule multi-zones, du HCS vers les passerelles de zone ;
• provision.nix : clients OAuth2 (registre de gabarits), groupes et personnes.

Réplication (replication.nix)

Automatique, dérivée de l’endroit où idm est déclaré :

• idm sur le HCS seul, ou sur une passerelle sans HCS : une instance ;
• sur le HCS et >= 1 passerelle de zone : le HCS fournit (WriteReplica), chaque passerelle idm consomme.

Amorçage en deux temps : just apply génère tous les certificats de réplication (les passerelles restent WriteReplicaNoUI), puis just idm-sync-certs + just apply ajoute les partenaires et fait basculer les passerelles en ReadOnlyReplica.

Provisionnement (provision.nix)

Chaque module de service compatible OIDC contribue un modèle de client à darkone.service.idm.oauth2 ; un client est provisionné par (modèle, instance), fusionné par clientId à travers les zones. Jamais sur un consommateur de réplication : il reflète le HCS.

• enable bool Activer le SSO local avec Kanidm

darkone.service.idm.enable = false;

---

✨ darkone.service.immich

Service Immich (gestion de photos) entièrement configuré.

• enable bool Activer le service immich local
• enableMachineLearning bool Activer les fonctionnalités d’apprentissage automatique (reconnaissance faciale, détection d’objets)
• enableRedis bool Activer Redis pour la mise en cache (recommandé pour les performances)

darkone.service.immich = {
  enable = false;
  enableMachineLearning = false;
  enableRedis = false;
};

✨ darkone.service.jellyfin

Un serveur jellyfin entièrement configuré.

• enable bool Activer le service jellyfin

darkone.service.jellyfin.enable = false;

✨ darkone.service.jitsi-meet

Un service jitsi-meet entièrement configuré.

• enable bool Activer le service jitsi-meet local

darkone.service.jitsi-meet.enable = false;

✨ darkone.service.loki

Loki + Alloy, statistiques HTTP avec Grafana.

Note

Collecte centralisée des logs d’accès Caddy, consommés par Grafana via un datasource Loki provisionné et un tableau de bord dédié.

Double schéma aligné avec monitoring.nix :

• enable : déploie le serveur Loki + le datasource Grafana sur le même hôte que le service monitoring (Grafana).
• isClient : déploie Alloy sur chaque hôte exécutant Caddy. Les logs Caddy sont attendus en JSON dans /var/log/caddy/access-*.log (voir dnf/modules/system/services.nix).

Par défaut, enable suit darkone.service.monitoring.enable et isClient suit services.caddy.enable : la configuration est entièrement automatique une fois le monitoring et Caddy actifs.

Pas d’authentification, tailnet uniquement

Loki accepte les lectures et écritures de toute personne pouvant l’atteindre. Le port 3100 est donc ouvert uniquement sur tailscale0 ; auth_enabled est le commutateur multi-tenancy de Loki, pas une connexion, et reste false.

Débogage et nettoyage manuel

Symptômes les plus courants après une (dés)activation de Loki ou un changement de format de log Caddy :

1. « NO DATA » sur le tableau de bord Caddy malgré des requêtes entrantes. Vérifier la chaîne d’ingestion de bout en bout :

# Sur l'hôte Caddy : Alloy fonctionne-t-il ? lit-il les fichiers ?
sudo systemctl status alloy --no-pager
sudo journalctl -u alloy -n 100 --no-pager | grep -iE 'error|permission'
ls -la /var/log/caddy/access-*.log   # doit être caddy:caddy

# Sur l'hôte de monitoring lui-même, ou depuis le tailnet : Loki reçoit-il ?
# (remplacer <IP> par l'adresse interne de l'hôte de monitoring, Loki ne se
# lie PAS sur 127.0.0.1 — voir http_listen_address = bindAddr. Depuis un
# client LAN simple, la connexion est refusée, par conception.)
curl -s http://<IP>:3100/loki/api/v1/labels | jq
curl -sG http://<IP>:3100/loki/api/v1/query \
     --data-urlencode 'query={job="caddy"}' | jq '.data.result | length'

Une réponse vide sur /loki/api/v1/* alors que /ready répond 200 indique que le frontend annonce la mauvaise adresse (voir common.instance_addr) ; journalctl -u loki | grep frontend= l’affiche. Redémarrer Loki après correction.

2. alloy.service: mkdir data-alloy/remotecfg: permission denied. Propriété orpheline de /var/lib/alloy héritée d’un ancien DynamicUser. Le ExecStartPre du service la corrige normalement, mais si bloqué (ex. unité en start-limit-hit) :

sudo systemctl stop alloy
sudo chown -R caddy:caddy /var/lib/alloy
sudo systemctl reset-failed alloy
sudo systemctl start alloy

3. Grafana refuse de démarrer : Datasource provisioning error: data source not found. Conflit d’UID en base SQLite après modification du provisionnement (typiquement passage d’un UID auto-généré à uid = "loki"). L’option deleteDatasources gère cela en théorie ; sinon nettoyage manuel :

sudo systemctl stop grafana
sudo sqlite3 /var/lib/grafana/grafana.db \
     "DELETE FROM data_source WHERE name='Loki';"
sudo systemctl reset-failed grafana
sudo systemctl start grafana

4. Fichiers de log Caddy obsolètes (ancien nommage avec : ou schéma, par ex. access-http:__nextcloud.log). Inoffensifs mais encombrants dans la sortie de la queue Alloy. Nettoyage après migration :

sudo rm /var/log/caddy/access-{http,https}:__*.log
sudo rm /var/log/caddy/access-:*.log     # variantes `:80`, `:443`
sudo systemctl reload caddy              # optionnel

• enable bool Déploie le serveur Loki + le datasource Grafana (co-localisé avec Grafana).
• isClient bool Déploie Alloy pour collecter les logs d’accès Caddy locaux.
• retentionTime str Durée de rétention des logs dans Loki (30 jours par défaut).

darkone.service.loki = {
  enable = config.darkone.service.monitoring.enable;
  isClient = config.services.caddy.enable && hasMonitoringHost;
  retentionTime = "720h";
};

---

✨ darkone.service.matrix.bridges

DNF matrix : ponts mautrix. Doc : en-tête de ../matrix.nix.

---

✨ darkone.service.matrix.mas

DNF matrix : authentification déléguée à MAS. Doc : en-tête de ../matrix.nix.

---

✨ darkone.service.matrix.rtc

DNF matrix : appels MatrixRTC (LiveKit). Doc : en-tête de ../matrix.nix.

---

✨ darkone.service.matrix

Service matrix (synapse) DNF avec les ponts mautrix.

Les ponts (whatsapp, signal, telegram, messenger, discord) sont utilisables par tous les comptes locaux : chaque utilisateur lie son propre compte distant en dialoguant avec le bot du pont (@whatsappbot, @signalbot, … puis login) ; les sessions sont isolées par utilisateur. Les network.matrix.admins déclarés administrent les ponts et le serveur (cf. « Administrateurs » ci-dessous).

Le double puppeting utilise la méthode officielle appservice (https://docs.mau.fi/bridges/general/double-puppeting.html 🡕) : un token appservice doublepuppet partagé permet aux ponts d’envoyer les messages d’origine distante sous le vrai compte matrix de l’utilisateur. Secrets sops requis : mautrix-doublepuppet-as-token et mautrix-doublepuppet-hs-token (openssl rand -hex 32 chacun).

Les tokens as/hs de chaque pont sont fournis par sops plutôt que générés automatiquement : le fichier de registration devient une pure fonction des secrets, donc réinitialiser le répertoire d’état d’un pont n’invalide jamais la registration chargée par synapse (sinon il faudrait purger la registration + redémarrer synapse, ce qui produirait des erreurs « as_token was not accepted »).

✨ darkone.service.matrix

DNF matrix (synapse) homeserver.

Sous-modules (matrix/) :

• mas.nix : authentification, déléguée au Matrix Authentication Service ;
• bridges.nix : ponts mautrix, utilisables par tout compte local ;
• rtc.nix : backend MatrixRTC (LiveKit) pour Element Call.

Fédération

La fédération est configurable via darkone.service.matrix.federation :

• enable = false : bloque toute la fédération (liste blanche de domaines vide).
• enable = true; whitelist = [ ] : fédération ouverte avec tous les serveurs.
• enable = true; whitelist = [ "ami.org" ] : liste blanche (entrante + sortante).

La découverte reste verrouillée quoi qu’il arrive (salons absents des répertoires distants, profils privés sur la fédération), si bien que le réseau est joignable mais pas consultable.

Compatible enfant

Une fédération ouverte permet à tout serveur fédéré de DM/inviter les utilisateurs locaux. Pour un réseau familial, remplir whitelist uniquement avec des serveurs de confiance.

L’auto-inscription des amis (friendRegistration.enable) ouvre des comptes mot de passe locaux conditionnés par un jeton, en parallèle des utilisateurs OIDC Kanidm. Fabriquer un jeton sur l’hôte avec sudo dnf-mas manage issue-user-registration-token.

Un seul espace de noms, ids permanents

Les amis et les utilisateurs déclarés puisent dans le même espace de noms de localpart, et un id matrix n’est jamais libéré (unique dans les users de MAS, la désactivation le conserve). Déclarer un utilisateur dont un ami a déjà pris le localpart échoue à sa première connexion SSO : l’on_conflict de MAS reste sur fail, puisque tout autre choix remet le compte existant à qui s’inscrit avec un nom correspondant en amont. Procédure de fusion dans le guide administrateur (operate/matrix.mdx).

Administrateurs

network.matrix.admins (parties locales) est la source déclarative unique des deux administrations, appliquée à la reconstruction sans écriture en base :

• ponts : niveau admin dans chaque carte permissions mautrix ;
• serveur : policy.data.admin_users, que la politique MAS fournie transforme en scopes urn:mas:admin et urn:synapse:admin:* (API admin MAS, API admin synapse, connexion à l’UI matrix-admin).

Les promotions impératives persistent

La politique accorde l’admin sur admin_users OU sur l’indicateur de base can_request_admin posé par dnf-mas manage promote-admin. Auditer les restes avec list-admin-users, les retirer avec demote-admin.

Authentification (mas.nix)

Toute l’authentification passe toujours par le Matrix Authentication Service : Element X, la connexion par QR code et le portail d’auto-service /account n’existent que là, et l’auth propre à synapse est dépréciée en amont (MSC3861). Kanidm reste la source d’identité : MAS est le client OIDC à la place de synapse, et synapse ne fait qu’interroger MAS pour introspecter les jetons.

Même vhost : MAS détient les points d’auth racine + compat, synapse garde /_matrix/* et /_synapse/*. La découverte des clients est automatique (synapse sert lui-même auth_metadata), aucun changement de well-known.

Secrets sops requis, tous créés par just configure-admin-host : mas-encryption-secret, mas-synapse-secret et mas-rsa-private-key.

dnf-mas (root) enveloppe mas-cli pour l’administration côté hôte : jetons d’inscription, promote-admin, register-user, syn2mas. MAS tourne avec DynamicUser et lit ses secrets depuis les credentials systemd, absents hors de l’unité en cours ; le wrapper reconstruit un répertoire de credentials équivalent à partir des fichiers sops, donc fonctionne que le service soit en service ou non (syn2mas l’exige à l’arrêt).

mas-cli n’agit que, jamais de listage : activer le service matrix-admin pour le côté lecture (comptes, appareils, sessions), il parle les deux API admin.

Immutable une fois démarré

mas-encryption-secret et le ULID du fournisseur Kanidm ne doivent jamais changer après le premier démarrage de MAS (données de DB chiffrées / liens de comptes amont).

Migrer une instance pré-MAS

Un homeserver antérieur à MAS requiert la migration syn2mas (comptes, mots de passe, sessions, ids externes), sans quoi plus personne ne se connecte. Déployer d’abord, puis, services arrêtés tous les deux : sudo dnf-mas syn2mas check, ... migrate --dry-run, ... migrate. Procédure dans .specs/matrix-authentication-service.md.

Ponts (bridges.nix)

Ponts mautrix : WhatsApp, Signal, Telegram, Messenger, Discord. Chaque utilisateur lie son propre compte distant en parlant au bot du pont (@whatsappbot, @signalbot, … puis login) ; les sessions sont isolées par utilisateur. Administrateurs des ponts : cf. « Administrateurs » ci-dessus.

Double puppeting : méthode officielle appservice (https://docs.mau.fi/bridges/general/double-puppeting.html 🡕). Un jeton appservice doublepuppet partagé permet aux ponts d’envoyer des messages à origine distante sous le vrai compte matrix de l’utilisateur. Secrets sops requis : mautrix-doublepuppet-as-token et mautrix-doublepuppet-hs-token (générés par just configure-admin-host).

Les jetons as/hs appservice de chaque pont proviennent de sops, jamais auto-générés : le fichier de registration est une fonction pure des secrets, si bien qu’effacer le répertoire d’état d’un pont n’invalide jamais la registration chargée par synapse (« as_token was not accepted », effacement de la registration + redémarrage de synapse).

Appels (rtc.nix)

Deux stacks coexistent, car aucune seule ne couvre tous les clients :

• WebRTC 1:1 historique, négocié via synapse et relayé par coturn (darkone.service.turn). La seule chose que parle Element Classic.
• MatrixRTC (matrixRtc.enable) : un SFU LiveKit plus son service d’autorisation, pour les appels de groupe et Element Call. Element X ne parle que celui-là et affiche « call is not supported » (MISSING_MATRIX_RTC_TRANSPORT) sans lui ; Element Web/Desktop intègrent aussi Element Call et en gagnent les appels de groupe.

Les deux sont servis depuis le vhost matrix, à côté de synapse et MAS : le websocket du SFU sur /livekit/sfu, le service JWT sur /livekit/jwt. Les clients le découvrent via matrix_rtc.transports (synapse, MSC4143) et, en repli pour les plus anciens, via rtc_foci dans le well-known.

Secret sops requis : livekit-secret (just configure-admin-host), partagé par le SFU et le service JWT.

Les ports média doivent atteindre l’hôte

Le média ne passe pas par le reverse proxy. La plage UDP et le repli TCP sont ouverts sur l’interface publique : un hôte derrière NAT doit les faire forwarder, et rtc.use_external_ip défini (non testé ici : le HCS détient directement son adresse publique).

La réduction d’écho n’est pas un réglage serveur

services.livekit.settings est freeform : les clés inconnues atteignent le fichier de config silencieusement. La section audio de LiveKit ne règle que la détection du locuteur actif et la redondance RED ; echo_cancellation, noise_suppression et channels n’y existent pas. Ce sont des contraintes getUserMedia, du ressort du client.

Aucun réglage SFU ne peut réparer un participant qui échoie :

• LiveKit relaie l’Opus sans jamais le décoder.
• L’AEC a besoin de la référence du haut-parleur local, qui ne quitte jamais l’appareil.
• Element Call chiffre le média de bout en bout, le SFU ne peut donc pas le lire.

Le remède est côté appareil : un casque, ou les interrupteurs de traitement audio d’Element Call. Attention au piège de diagnostic : un combiné dont l’AEC matérielle s’annonce sans rien faire échoie pour les autres, jamais pour son propre utilisateur.

• enable bool Activer le service matrix (synapse)
• federation.enable bool Autoriser la fédération serveur-à-serveur. False bloque toute la fédération.
• federation.whitelist listOf str Vide = fédérer avec tous les serveurs ; non vide = seulement ces domaines (entrant + sortant).
• matrixRtc.enable bool Activer le backend MatrixRTC (SFU LiveKit) pour les appels de groupe Element Call.
• friendRegistration.enable bool Autoriser les amis à s’auto-inscrire avec un jeton d’invitation (conditionné par jeton).
• bridges.whatsapp.enable bool Pont Mautrix WhatsApp (connexion par QR code).
• bridges.signal.enable bool Pont Mautrix Signal (connexion par QR code).
• bridges.telegram.enable bool Pont Mautrix Telegram (connexion par numéro de téléphone).
• bridges.messenger.enable bool Pont Mautrix Facebook Messenger (connexion par cookies).
• bridges.discord.enable bool Pont Mautrix Discord (connexion par QR code, expérimental).
• shared raw Valeurs matrix partagées avec les sous-modules matrix/.

darkone.service.matrix = {
  enable = false;
  federation.enable = false;
  federation.whitelist = [ ];
  matrixRtc.enable = false;
  friendRegistration.enable = false;
  bridges.whatsapp.enable = true;
  bridges.signal.enable = true;
  bridges.telegram.enable = true;
  bridges.messenger.enable = true;
  bridges.discord.enable = false;
  shared = {
          inherit
            params
            masKanidmUlid
            livekitJwtUrl
            matrixAdmins
            ;
        };
};

---

✨ darkone.service.mealie

Gestion de recettes Mealie

• enable bool Activer le service mealie

darkone.service.mealie.enable = false;

✨ darkone.service.minio

Un service MinIO S3 local entièrement configuré. (wip)

Fournit un backend de stockage d’objets compatible S3 interne accessible uniquement sur 127.0.0.1:9000. L’interface Web de la console s’exécute sur 127.0.0.1:9001 pour l’administration et le débogage.

Note

Les buckets ne sont PAS créés automatiquement par ce module. Chaque service consommateur est responsable de la création de ses propres buckets via un hook postStart systemd en utilisant l’outil mc (MinIO Client). Les identifiants sont gérés via sops.

• enable bool Activer le service MinIO S3 local

darkone.service.minio.enable = false;

✨ darkone.service.monitoring.fs-readonly

Supervision DNF : montages rw rendus en lecture seule par le noyau. Doc : en-tête de ../monitoring.nix.

---

✨ darkone.service.monitoring

Module de supervision : tableaux de bord Grafana + exporteur par nœud.

Astuce

Grafana visualise les métriques collectées par le service prometheus (dont il a besoin sur le même hôte, imposé par le générateur). Pour chaque zone :

• Tous les nœuds avec le tag « monitoring-node » exécutent l’exporteur de nœud.
• Le nœud avec le service « monitoring » exécute Grafana (et requiert prometheus).
• Un seul hôte de supervision par zone est accepté.
• Un tag « monitoring-node:[zone] » rattache un nœud au Prometheus de cette zone.

Surveillance en lecture seule (monitoring/fs-readonly.nix) : chaque nœud exporte dnf_filesystem_forced_readonly, ses montages rw dont le noyau a rendu le système de fichiers en lecture seule, derrière FilesystemReadOnly. Les montages ro et liaisons prévus n’y apparaissent jamais ; le fichier vit sur tmpfs, il survit donc au disque défaillant.

• enable bool Activer la supervision avec prometheus, grafana et l’exporteur de nœud
• isNode bool S’agit-il d’un nœud de supervision
• kioskTarget str Cible (relative, sans /) de la redirection automatique vers Grafana depuis la racine du domaine de supervision. Surchargée par le module Loki lorsqu’il est actif pour pointer vers un tableau de bord multi-sources.

darkone.service.monitoring = {
  enable = false;
  isNode = lib.hasAttrByPath [ "features" "monitoring-node" ] host;
  kioskTarget = "d/dnf-monitoring-home/home?kiosk";
};

---

✨ darkone.service.nextcloud

Service Nextcloud entièrement configuré.

Secrets sops requis

Lorsque ce module est activé, il lit :

• nextcloud-admin-password : mot de passe initial du compte administrateur ;
• nextcloud-whiteboard-secret : JWT partagé avec le backend tableau blanc (lu uniquement quand whiteboard figure dans plugins) ;
• oidc-secret-<client> : secret client OAuth2 Kanidm, déclaré par le module idm et rechiffré ici pour l’unité de provisionnement occ ;
• smtp/password : mot de passe du relais SMTP (uniquement avec network.smtp). Externe : saisi à la main, jamais généré.

just configure-admin-host génère les autres, de façon idempotente, et n’écrase jamais un secret existant. Lancez-le avant de reconstruire : la activation de sops-nix échoue si une entrée manque.

Exécuter occ

services.nextcloud.secrets fait charger à occ des credentials systemd : lancez sudo nextcloud-occ (PHP s’exécute toujours en tant que nextcloud), pas sudo -u nextcloud.

• enable bool Activer le service nextcloud local

• adminUser str Nom d’utilisateur administrateur pour Nextcloud

• enableSsoRedirect bool Envoyer les utilisateurs directement vers Kanidm au lieu d’afficher le formulaire de connexion Nextcloud (user_oidc allow_multiple_user_backends). Économise un clic à chaque connexion, y compris celle du client de bureau via Login Flow v2.

  Formulaire de connexion local

  Cela masque le formulaire de mot de passe, compte administrateur compris. Y accéder avec /login?direct=1.

  Sans effet si Kanidm est absent du réseau.

• plugins listOf (enum (appstoreApps ++ shippedToggleableApps)) Applications Nextcloud à activer. Seuls calendar, contacts et tasks sont activés par défaut ; Talk (spreed), le tableau de bord, le flux d’activité, les photos et toutes les autres applications restent désactivées tant qu’elles ne sont pas listées ici.

  user_oidc (SSO Kanidm) et notify_push (push client) sont toujours activés, quelle que soit cette liste.

darkone.service.nextcloud = {
  enable = false;
  adminUser = "admin";
  enableSsoRedirect = true;
  plugins = [ ];
};

---

✨ darkone.service.nfs

Serveur + client NFS pour les partages domestiques.

Note

Ce module est activé si un serveur NFS est déclaré dans le réseau local. Il crée :

• Un partage (srv-dirs.homes) sur le serveur.
• Des répertoires de montage (/mnt/nfs/homes/[user]) sur les clients.

Le script nfs home manager lie les répertoires xdg aux répertoires de montage. Dans le fichier config.yaml (hosts) :

• Un seul hôte possède le service service.nfs.
• Les clients nécessitent features = [ "nfs-client" ].

Les exports sont par IP client

Seuls les hôtes nfs-client déclarés de la zone apparaissent dans /etc/exports ; une machine absente de config.yaml n’obtient pas de montage. Root est squashé sur chaque partage : un root client est nobody sur le serveur.

• enable bool Active le serveur NFS DNF (éviter l’activation manuelle)
• serverDomain str FQDN du serveur NFS

darkone.service.nfs = {
  enable = hasServer && (isServer || isClient);
  serverDomain = "nfs";
};

---

✨ darkone.service.nix-cache

Proxy de cache binaire Nix par zone (nginx proxy_cache).

Met en cache le cache Nix public (cache.nixos.org) sur la passerelle de zone, afin qu’un déploiement à l’échelle de la flotte récupère chaque fermeture depuis le WAN une seule fois, puis la serve sur le LAN à tous les autres hôtes. Les chemins compilés localement sont servis directement depuis harmonia (voir harmonia.nix) ; ce proxy ne sert jamais de façade à harmonia.

Pourquoi nginx plutôt qu’un proxy réécrivain

Un point de cache dessert exactement un amont. Un narinfo et son nar sont deux requêtes distinctes et l’URL du nar est indépendante de l’amont, si bien qu’un proxy multi-amont doit réécrire les URL narinfo dans son propre espace de noms et les suivre en base de données (l’approche retenue par l’ancien proxy ncps — et la source de ses récurrentes HTTP 500 « invalid nar hash »). Avec un amont unique, il n’y a aucune ambiguïté : nginx met en cache narinfo + nar tels quels, les signatures transitent intactes et les clients les vérifient. Pas de réécriture, pas de base de données, et donc pas ce bogue par construction.

Topologie

• server : l’hôte passerelle qui déclare nix-cache dans config.yaml (un par zone). Fait tourner nginx sur l’IP interne, port network.ports.nixCache.
• clients : tous les hôtes de la zone locale. Leurs substituteurs deviennent les instances harmonia de la zone (directes, LAN/tailnet) plus ce proxy.
• clients nomades (roaming = true, défini par la fonctionnalité hôte roaming) : hôtes itinérants déplacés entre zones. Leurs substituteurs sont les noms neutres de zone (harmonia.dnf.internal, nix-cache.dnf.internal) que le DNS de chaque zone résout vers ses propres services de cache (voir service/dnsmasq.nix), afin que le cache suive l’ordinateur portable. fleet-update construit un tel hôte sur lui-même.
• hôtes de la zone globale (www, un VPS de datacenter) : pas de LAN, pas de passerelle, donc pas de proxy. Ils utilisent l’harmonia global via le tailnet et la clé de flotte, sans laquelle ils ne pourraient rien récupérer de ce que la flotte a compilé.

• enable bool Le proxy de cache binaire Nix par zone (nginx devant cache.nixos.org)
• maxSize str Taille maximale du cache sur disque ; nginx évince au-delà les entrées les moins récemment utilisées.
• roaming bool Hôte nomade (ordinateur portable déplacé entre zones) : remplacer les substituteurs épinglés à la zone par les noms neutres de zone que le DNS de chaque zone résout vers ses propres services de cache. Hors de toute zone DNF, ces noms répondent NXDOMAIN immédiatement et Nix se rabat sur cache.nixos.org. Déclaré par la fonctionnalité roaming dans config.yaml ; à définir à la main pour un déplacement temporaire.

darkone.service.nix-cache = {
  enable = false;
  maxSize = "40g";
  roaming = (host.features or { }) ? "roaming";
};

---

✨ darkone.service.openclaw

Assistant OpenClaw d’un espace IA (passerelle + interface de gestion, derrière le SSO de la zone).

Une instance par hôte ai-space, déclarée comme n’importe quel service :

- hostname: "ia-pro"
  profile: "ai-space"
  users: ["alice"]          # membres : groupe Kanidm `space-ia-pro`
  features: ["monitoring-node"] # alertes : espace injoignable, unité de la passerelle en échec
  services: { openclaw: {} }

• accès : forward auth Caddy, membres de space-<host> uniquement (proxy.spaceMembersOnly) ; OpenClaw fait confiance à la passerelle de la zone en tant que proxy (trusted-proxy) et lit l’identité dans x-auth-request-email ;
• appareils : le navigateur d’un membre est appairé à la première visite, sans admin de l’opérateur (accordé uniquement depuis le CLI de l’hôte) ;
• port : joignable depuis la passerelle de la zone uniquement ;
• CLI hôte : openclaw, relancé en tant qu’utilisateur du service, au-delà de trusted-proxy avec le mot de passe de la passerelle (openclaw-gateway-password, just space-init) ;
• état : /var/lib/openclaw (connexions aux fournisseurs, sessions, espace de travail, clés E2EE Matrix) ;
• propriétaire (owner, par défaut : l’unique membre) : son abonnement fait tourner l’agent, il reçoit les demandes d’approbation et les messages proactifs ;
• Matrix : canal de DM avec le bot @<host>:<domain>, membres uniquement, salons ignorés, une session par membre quand il y en a plusieurs, quand le réseau dispose de Matrix et que just space-init <host> a créé le bot (marqueur var/generated/spaces/<host>.nix, jeton dans le fichier sops de l’espace) ; approbations d’exec demandées au propriétaire en DM ;
• outillage de l’agent : MCP, skills, Claude Code / Codex et packages de l’espace (darkone.host.ai-space), partagés avec les homes des membres ;
• identité (identity : nom, emoji, avatar) : déclarée, la configuration étant en lecture seule (openclaw agents set-identity échoue) ;
• espace de travail (/var/lib/openclaw/workspace) : fichiers workspace (AGENTS.md, SOUL.md…) remplacés à chaque démarrage, les autres laissés à l’agent ; projects clonés une fois en projects/<name> ;
• notes vocales : whisper.cpp local (transcription, modèle ggml small).

darkone.service.openclaw = {
  workspace."AGENTS.md" = ./agents/AGENTS.md;
  projects.notes = "git@forge.example.com:alice/notes.git";
};

Commandes exécutées sans approbation par défaut

exec = "full" (défaut d’OpenClaw) : l’agent exécute n’importe quelle commande en tant qu’openclaw, jetons de l’espace à portée de main. La microVM est la limite, l’unité durcie une seconde muraille (écritures dans l’état uniquement). ask, auto : les manques vont au propriétaire, un garde-fou contre les erreurs, pas une muraille (même utilisateur).

Les membres se font confiance

Une passerelle, un domaine d’opérateur : l’interface de chaque membre montre toutes les sessions, DM compris. Les membres qui ne se font pas confiance obtiennent des espaces séparés.

Connexion au fournisseur

Une fois par espace, depuis l’hôte en tant que nix (le CLI openclaw se relance lui-même en tant qu’utilisateur du service), par fournisseur model. Les connexions restent dans l’état.

• anthropic/* (défaut) : sudo -u openclaw -H claude auth login ;
• openai/* : openclaw models auth login --provider openai.

• enable bool Activer l’assistant OpenClaw d’un espace IA

• owner nullOr str Membre propriétaire de l’espace : son abonnement connecte l’agent (model), il reçoit les demandes d’approbation et les messages proactifs. Requis avec plusieurs membres (l’ordre de users n’est pas conservé).

• model str Modèle principal. Runtime d’abonnement de son fournisseur : anthropic/* via le CLI claude (avec darkone.host.ai-space.enableClaude), openai/* via le plugin codex (OAuth ChatGPT).

• exec enum [ "full" "auto" "ask" "allowlist" "deny" ] Politique de commandes de l’agent (OpenClaw tools.exec.mode) :

  • full : n’importe quelle commande, non approuvée (défaut d’OpenClaw) ;
  • ask : commandes de la liste blanche exécutées, toute autre interroge le propriétaire ;
  • auto : un modèle examine les manques, le propriétaire décide en cas de doute ;
  • allowlist, deny : commandes de la liste blanche uniquement, aucune.

  Liste blanche : openclaw approvals allowlist add --agent main <path>. Avec le runtime claude-cli, les pipes, redirections et substitutions sont refusés avant toute invite hors full.

• identity.name nullOr str Nom de l’assistant, affiché dans l’interface.

• identity.emoji nullOr str Emoji de l’assistant, affiché dans l’interface.

• identity.avatar nullOr str Image d’avatar (URL ou chemin relatif à l’espace de travail).

• workspace attrs Fichiers de l’espace de travail de l’agent, par chemin relatif : contenu ou fichier. Remplacés à chaque démarrage de la passerelle ; les fichiers non déclarés appartiennent à l’agent.

• projects attrs Dépôts git clonés une fois dans workspace/projects/<name>, jamais tirés. Les remotes SSH utilisent la clé d’openclaw (/var/lib/openclaw/.ssh, créée à la main) ; la clé du serveur est acceptée au premier clonage.

• transcription.enable bool Transcrire les notes vocales en local (whisper.cpp, CPU).

• transcription.model path Modèle ggml de whisper.cpp.

• transcription.language str Langue parlée (auto : détectée par note).

darkone.service.openclaw = {
  enable = false;
  owner = "alice";
  model = "openai/gpt-6-astra";
  exec = "ask";
  identity.name = "Jarvis";
  identity.emoji = "🦉";
  identity.avatar = null;
  workspace = { };
  projects = { };
  transcription.enable = true;
  transcription.model = pkgs.fetchurl {
            url = "https://huggingface.co/ggerganov/whisper.cpp/resolve/main/ggml-small.bin";
            sha256 = "0ywqxbziyp2bv72riyjpw4brk9v46d4cfbjfwqvvjrrq0srakqqv";
          };
  transcription.language = "fr";
};

---

✨ darkone.service.outline

Un wiki outline complètement configuré.

• enable bool Activer le service outline local

darkone.service.outline.enable = false;

✨ darkone.service.oxicloud

OxiCloud — Fast Sovereign Cloud (stockage de fichiers, WebDAV, CalDAV et CardDAV).

Service en cours de validation

Emballage DNF autour du module nixpkgs (depuis le PR #516113 🡕). Le paquet oxicloud est déjà disponible dans nixpkgs ; seul le module est copié depuis le PR (cf. backports/nixos/oxicloud.nix).

SSO

Quand un service idm (Kanidm) existe sur le réseau (zone ou global), l’OIDC est branché automatiquement : un client OAuth2 est enregistré et OxiCloud est pointé vers les points d’entrée de Kanidm. Sans idm, le comportement en amont est laissé tel quel (connexion par mot de passe local uniquement).

Comptes avec SSO

• L’auto-inscription est fermée : les comptes sont créés à la première connexion SSO.
• Les membres du groupe admins de Kanidm deviennent administrateurs OxiCloud à cette première connexion uniquement ; les changements de rôle ultérieurs se font dans l’interface d’admin OxiCloud.

Clients et stockage

Le stockage de fichiers, WebDAV (/webdav/), CalDAV (/caldav) et CardDAV (/carddav) sont servis sur le même port HTTP, derrière le proxy inverse Caddy. La couche de compatibilité Nextcloud est active : les clients Nextcloud de bureau et mobiles, ainsi que le fournisseur Nextcloud des comptes en ligne GNOME, se connectent à l’URL du service. La base de données PostgreSQL est créée localement.

Courriel

Quand network.smtp est défini, OxiCloud envoie les notifications de partage et les invitations par courriel (liens magiques) via ce relais. Sans lui, les fonctionnalités de courriel sont désactivées.

• enable bool Activer le service OxiCloud local

darkone.service.oxicloud.enable = false;

---

✨ darkone.service.postfix

Relais SMTP Postfix.

• enable bool Activer le relais SMTP Postfix

darkone.service.postfix.enable = false;

✨ darkone.service.printing

Imprimantes et scanners.

• enable bool Paquets utiles par défaut
• loadAll bool Imprimantes et scanners complets
• enableScanners bool Activer les scanners
• enableHpPrinters bool Imprimantes HP uniquement
• enableManualInstall bool Installation manuelle des pilotes

darkone.service.printing = {
  enable = false;
  loadAll = false;
  enableScanners = false;
  enableHpPrinters = false;
  enableManualInstall = false;
};

✨ darkone.service.prometheus

Serveur de supervision Prometheus avec escalade déclarative via Alertmanager.

Prometheus & Grafana

Service autonome de métriques + d’alerting, indépendant de Grafana :

• Interroge chaque nœud de zone portant la feature monitoring-node:<zone>.
• Alertmanager route par gravité : warning -> Matrix #warnings, critical -> Matrix #incidents + mail (relais Postfix local).
• blackbox_exporter sonde l’atteignabilité de la passerelle / du tailnet / du DNS, ainsi que les passerelles des autres zones : Prometheus d’une zone réside sur sa propre passerelle, seuls les pairs peuvent donc signaler qu’un site entier a disparu.
• Les classes de nœud (critical/non-critical/disabled) proviennent des features alert-* ou du profil d’hôte (voir dnf/lib/alerts.nix).

monitoring (Grafana) requiert un prometheus sur le même hôte (imposé par le require du générateur). L’interface web est exposée à https://prometheus.<zone>.<domain> derrière oauth2-proxy (groupe admins), ce qui corrige aussi les liens d’alerte renvoyant vers Prometheus.

• enable bool Activer le serveur de métriques + d’alerting Prometheus

• retentionTime str Durée de rétention des métriques Prometheus

• alerting.enable bool Activer Alertmanager (activé par défaut une fois les salons Matrix d’alerte provisionnés)

• alerting.matrix.enable bool Diffuser les alertes dans les salons Matrix via le bot matrix-alertmanager

• alerting.matrix.userId str ID utilisateur Matrix du bot d’alerte (par défaut depuis network.matrix.bot)

• alerting.matrix.warningsRoom str ID du salon Matrix pour les avertissements (par défaut depuis network.matrix.warningsRoom)

• alerting.matrix.incidentsRoom str ID du salon Matrix pour les incidents (par défaut depuis network.matrix.incidentsRoom)

• alerting.email.enable bool Envoyer aussi les alertes critiques par mail (via le relais Postfix local)

• alerting.email.to str Destinataire des mails d’alerte critique

• alerting.network.enable bool Sonder l’atteignabilité réseau (passerelle/tailnet/DNS) avec blackbox_exporter

• alerting.network.internetProbeTargets listOf str Adresses IP externes que la passerelle de zone ping pour détecter une coupure WAN. Si toutes échouent, ZoneInternetDown se déclenche et inhibe les alertes de down (erronées) des hôtes accessibles uniquement via le WAN (par ex. le HCS). Liste vide = désactivé.

• alerting.network.httpProbeUrls listOf str URLs HTTP(S) sondées pour la vivacité (ServiceEndpointDown) et l’expiration du certificat TLS (CertificateExpiringSoon/Critical). Vide par défaut : lister les endpoints web publics à surveiller. Les redirections vers un login SSO (3xx) sont comptées comme up ; l’expiration du certificat est lue depuis la poignée de main TLS quelle que soit la réponse HTTP.

• alerting.silenceOnRebuild bool Émettre le flag dnf-maintenance (textfile collector) afin que les reconstructions inhibent les alertes d’un nœud

• alerting.thresholds attrs Remplacer les seuils d’alerte de ressources (voir les valeurs par défaut dans dnf/lib/alerts.nix)

• alerting.silences listOf submodule Alertes connues et acceptées qui ne doivent jamais notifier. Chaque entrée devient une route Alertmanager vers le récepteur null : l’alerte se déclenche toujours et reste visible dans les interfaces Prometheus/Alertmanager/Grafana, elle ne parvient simplement plus à Matrix ni par mail.

  Déclaré sur l’hôte qui fait tourner Prometheus, car c’est là que les règles et routes de la zone sont générées. Un module consommateur à l’échelle de la flotte (usr/modules/alerts.nix) est l’endroit pratique : il est importé partout et ne prend effet que là où Prometheus tourne.

  Dernier recours

  Corriger ou reconfigurer d’abord la condition sous-jacente. Un silence masque un vrai signal, donc reason est obligatoire et la liste reste auditable.

  • alert str Nom de l’alerte à mettre en sourdine (label alertname). Toujours restreint, afin que les niveaux de gravité voisins restent armés.
  • host nullOr str Restreindre le silence à un seul hôte. Null met en sourdine l’alerte pour toute la flotte.
  • matchers attrs Étiquettes de correspondance exacte supplémentaires, combinées en ET avec les autres (par ex. le point de montage ou le device visé par l’alerte).
  • reason str Pourquoi cette alerte est acceptée, et ce qui rendrait le silence supprimable.

darkone.service.prometheus = {
  enable = false;
  retentionTime = "30d";
  alerting.enable = roomsReady;
  alerting.matrix.enable = true;
  alerting.matrix.userId = "@alertbot:domain.tld";
  alerting.matrix.warningsRoom = "!warnings:domain.tld";
  alerting.matrix.incidentsRoom = "!incidents:domain.tld";
  alerting.email.enable = true;
  alerting.email.to = "admin@${network.domain}";
  alerting.network.enable = true;
  alerting.network.internetProbeTargets = [ ];
  alerting.network.httpProbeUrls = [ ];
  alerting.silenceOnRebuild = true;
  alerting.thresholds = { };
  alerting.silences = [ ];
  alerting.silences.alert = "DiskSpaceLow";
  alerting.silences.host = "srv-main";
  alerting.silences.matchers = { };
  alerting.silences.reason = null;
};

---

✨ darkone.service.restic.metrics

DNF restic : métriques de fraîcheur des sauvegardes. Doc : en-tête de ../restic.nix.

---

✨ darkone.service.restic.server

DNF restic : le serveur REST. Doc : en-tête de ../restic.nix.

---

✨ darkone.service.restic

Module de sauvegarde restic : serveur REST + cibles de sauvegarde par hôte.

Deux rôles, un module

• Serveur : un hôte avec restic dans ses services config.yaml exécute le serveur REST (enableServer) et stocke le dépôt de chaque hôte.
• Client : tout hôte avec enable = true déclare des targets de sauvegarde (chemin local ou rest:http://restic.<zone>:<port>).

Deux mots de passe, ne pas confondre

• Phrase secrète du dépôt : restic-password-<zone>, chiffre le contenu du dépôt.
• Identifiant REST : restic/<hostname>/rest-password par hôte, authentifie l’hôte auprès du serveur REST.

Les deux sont créés par just configure-admin-host (idempotent), qui lit les hôtes et zones déclarés dans la flotte.

Exemple (configuration machine) :

darkone.service.restic = {
  enable = true;
  targets = [
    { name = "main"; root = "rest:http://restic.my-zone.my-domain.tld:8888";
      zone = "ag"; categories = [ "system" "nfs" ]; }
  ];
};

Disposition des dépôts par cible : un dépôt par catégorie, nommé d’après elle.

<root>/<hostname>/system  <- catégorie "system" (/ moins les exclusions)
<root>/<hostname>/nfs     <- catégorie "nfs"    (/srv/nfs/<...>)
<root>/<hostname>/medias  <- catégorie "medias" (/srv/medias/<...>)

Le chemin du dépôt a exactement deux niveaux

rest-server sert les dépôts à deux composantes au plus sous son --path : <hostname>/medias répond, <hostname>/srv/medias renvoie 404 et restic signale un repository does not exist trompeur. Le sous-chemin est donc le nom brut de la catégorie, jamais le répertoire source. Une disposition identique pour les cibles locales et REST permet à un dépôt de passer de l’une à l’autre sans renommage.

Un serveur REST injoignable saute la sauvegarde

Chaque cible rest: porte une sonde d’accessibilité ExecCondition. Une sauvegarde dont le serveur est en panne est ignorée, jamais échouée : pas de SystemdUnitFailed nocturne, pas de quart d’heure de nouvelles tentatives restic, et pas d’initialize créant un dépôt vide contre un point d’accès mort. La sauvegarde manquante apparaît quand même, via ResticBackupStale / ResticBackupCritical, qui surveillent la dernière exécution réussie.

Les dossiers de synchronisation cloud ne sont jamais sauvegardés

Un dossier de synchronisation Nextcloud/ownCloud réplique un original côté serveur qui est sauvegardé à part, et restic ne fait jamais de déduplication entre dépôts. Détecté par le chemin (/home/*/Nextcloud, variantes numérotées incluses) et par la marque dans le journal.

Migrer les dépôts créés avant cette disposition

Les dépôts écrits quand le sous-chemin reflétait le répertoire source se trouvent sous <hostname>/srv/{nfs,medias}. Renommez-les sur le serveur avant la prochaine exécution : sinon initialize = true créerait un dépôt vide au nouveau chemin et lancerait silencieusement un ré-ensemblage complet.

mv <data-dir>/<hostname>/srv/medias <data-dir>/<hostname>/medias
rmdir <data-dir>/<hostname>/srv

Sous-modules (restic/) :

• server.nix : le serveur REST, un compte par hôte de la flotte ;
• metrics.nix : métriques de fraîcheur des sauvegardes pour les alertes restic.

Serveur REST (server.nix)

Un compte par hôte de la flotte (restic/<hostname>/rest-password), vérifié contre un htpasswd assemblé au démarrage ; privateRepos confine chaque hôte à son propre préfixe <hostname>/.

listenAll élargit la liaison, pas le pare-feu

Le serveur se lie à params.ip, c’est-à-dire l’adresse LAN sur une passerelle. Les clients qui l’atteignent depuis une autre zone par le tailnet ont besoin de listenAll = true (liaison sur 0.0.0.0). Le pare-feu reste la frontière : lan0 reçoit le port via getInternalInterfaceFwPath, tailscale0 est déjà une interface de confiance sur une passerelle, et le WAN ne l’ouvre jamais.

Métriques (metrics.nix)

Nœuds monitorés uniquement (fonction monitoring-node) : chaque tâche horodate sa dernière réussite dans le collecteur textfile, et restic-declared liste les tâches déclarées pour qu’une tâche qui ne réussit jamais vieillisse quand même en alerte dnf-restic-<zone>.

• enable bool Activer le client de sauvegarde restic
• enableDryRun bool Mode simulation (dry run)
• enableWaitRemoteFs bool Exécuter les sauvegardes seulement après remote-fs.target
• enableServer bool Activer le serveur REST restic
• listenAll bool Lier le serveur REST sur 0.0.0.0 (clients hors site)
• serverDataDir str Racine de stockage locale du serveur REST (dépôts de tous les hôtes)
• targets listOf submodule Destinations de sauvegarde pour cet hôte (chemin local ou URL REST)
  • name str Identifiant de cible, utilisé dans les noms de sauvegarde/d’unité (<category>-<name>)
  • root str Racine du dépôt : chemin local ou URL REST
  • zone str Zone sélectionnant la phrase secrète du dépôt (restic-password-<zone>)
  • categories listOf ( enum [ "system" "nfs" "medias" ] ) Ce qu’il faut sauvegarder vers cette cible
• nfsPaths listOf str Répertoires NFS (/srv/nfs/<xxx>) inclus dans la catégorie ‘nfs’
• mediasPaths listOf str Répertoires médias (/srv/medias/<xxx>) inclus dans la catégorie ‘medias’
• shared raw Valeurs restic partagées avec les sous-modules restic/.

darkone.service.restic = {
  enable = false;
  enableDryRun = false;
  enableWaitRemoteFs = false;
  enableServer = false;
  listenAll = false;
  serverDataDir = "/mnt/backup/restic";
  targets = [ ];
  targets.name = "main";
  targets.root = "rest:http://restic.${zone.domain}:${toString srvPort}";
  targets.zone = zone.name;
  targets.categories = [ ];
  nfsPaths = [ ];
  mediasPaths = [ ];
  shared = { inherit params; };
};

---

✨ darkone.service.searx

Un moteur de recherche durci et entièrement configuré.

• enable bool Activer le proxy de recherche local

darkone.service.searx.enable = false;

---

✨ darkone.service.stk

Pistes partagées SuperTuxKart, servies via NFS.

Note

Déclarer services: stk: sur un hôte de la zone (config.yaml) : il exporte srv-dirs.stkTracks en lecture seule. Tout hôte souhaitant les pistes active darkone.graphic.supertuxkart.enableNfsClient, qui branche enableClient ci-dessous ; les clients adressent le serveur par son propre hostname, toujours résolvable.

Le serveur n’a besoin d’aucun montage

enableClient sur l’hôte servant est un no-op : les pistes sont déjà locales, et home/modules/games.nix lie le répertoire des addons directement vers elles.

Exporté à tout le préfixe de la zone

Lecture seule, all_squash pour les données de jeu — même portée que les propres règles de pare-feu du jeu, et une liste d’IP par client de moins à maintenir à jour avec config.yaml.

• enable bool Exporter les pistes partagées SuperTuxKart (éviter d’activer manuellement)
• enableClient bool Monter les pistes partagées SuperTuxKart de la zone
• serverName nullOr str Hostname du serveur hébergeant les pistes, par défaut l’hôte stk de la zone

darkone.service.stk = {
  enable = stk.isServer;
  enableClient = false;
  serverName = stk.server;
};

---

✨ darkone.service.tailscale.autopause

DNF tailscale : mise en pause automatique lors des déplacements. Doc : en-tête de ../tailscale.nix.

---

✨ darkone.service.tailscale.cert-sync

DNF tailscale : synchronisation des certificats HCS. Doc : en-tête de ../tailscale.nix.

---

✨ darkone.service.tailscale.selfheal

DNF tailscale : chien de garde d’auto-réparation. Doc : en-tête de ../tailscale.nix.

---

✨ darkone.service.tailscale

Client tailscale du tailnet DNF (headscale sur le HCS).

Rejoint le HCS, les passerelles de zone (isGateway : sous-réseau de zone annoncé, routes acceptées, propre résolveur conservé) et les hôtes en déplacement.

Inscription

Pas de clé partagée. just tailnet-enroll <host>, lancé aussi par just configure, fabrique sur le HCS une clé à usage unique étiquetée pour l’hôte et la remet à dnf-tailnet-join. Idempotent : un nœud déjà inscrit reste intact.

Sous-modules (tailscale/) :

• cert-sync.nix : les passerelles de zone récupèrent les certificats Caddy du HCS ;
• selfheal.nix : chien de garde redémarrant un tailscaled déconnecté ;
• autopause.nix : les clients en déplacement mettent tailscale en pause sur une LAN de zone.

Synchronisation des certificats (cert-sync.nix)

Les certificats publics sont émis sur le HCS uniquement ; chaque passerelle de zone récupère tout le stockage Caddy par le tailnet (rsync en tant que nix, élevé à caddy côté HCS), puis le publie sur son propre Caddy.

Auto-réparation (selfheal.nix)

Chaque minute, vérifie que le backend tourne et que le plan de contrôle voit le nœud en ligne ; redémarre tailscaled après une perte prolongée. Exporte les métriques dnf_tailscale_* pour les alertes TailscaleFlapping/ TailscaleUnhealthy.

Mise en pause automatique (autopause.nix)

Clients en déplacement uniquement. Sur une LAN de zone DNF, --accept-dns hijackerait resolv.conf (dnsmasq/AdGuard local) et --accept-routes entrerait en conflit avec le sous-réseau de zone connecté : un dispatcheur NetworkManager met tailscale en pause sur place et le réactive ailleurs.

• enable bool Activer le client tailscale pour se connecter au HCS
• isGateway bool Ce nœud tailscale est une passerelle de sous-réseau
• isExitNode bool Configurer ce client comme nœud de sortie
• selfHeal.enable bool Chien de garde : détecter la déconnexion d’headscale et redémarrer tailscaled.
• autoPauseOnLan.enable bool Client en déplacement : mettre tailscale en pause (down) branché sur une LAN de zone DNF connue, le réactiver ailleurs. Clients NetworkManager non passerelle uniquement.
• shared raw Valeurs tailscale partagées avec les sous-modules tailscale/.

darkone.service.tailscale = {
  enable = false;
  isGateway = false;
  isExitNode = false;
  selfHeal.enable = true;
  autoPauseOnLan.enable = false;
  shared = {
        inherit
          tsBin
          isHcsSubnetGateway
          selfHealEnable
          selfHealStateDir
          autoPauseEnable
          autoPauseStateFile
          ;
      };
};

---

✨ darkone.service.turn

Serveur Coturn (matrix).

Ajouter des entrées DNS pour optimiser :

Type,Name,Priority,Pds,Port,Target
SRV,_stun._udp,0,0,3478,turn.mydomain.tld
SRV,_stun._tcp,0,0,3478,turn.mydomain.tld
SRV,_turn._udp,0,0,3478,turn.mydomain.tld
SRV,_turn._tcp,0,0,3478,turn.mydomain.tld
SRV,_turns._tcp,0,0,5349,turn.mydomain.tld

• enable bool Activer le service turn local (visio)

darkone.service.turn.enable = false;

---

✨ darkone.service.vaultwarden

Un serveur vaultwarden entièrement configuré.

Panneau d’administration

/admin répond au LAN et au tailnet uniquement : les zones et le tailnet résolvent le service vers l’IP tailnet HCS. Les clients Bitwarden (web, extension, mobile) restent publics.

• enable bool Activer le service Vaultwarden local
• enableSmtp bool Activer SMTP pour l’envoi d’e-mails (recommandé, nécessite network.smtp)

darkone.service.vaultwarden = {
  enable = false;
  enableSmtp = true;
};

---