# Les pouvoirs de Set-OPS > **Pour qui :** qui **évalue le moteur** — ce qu'il sait faire, et ce qu'il ne sait pas encore. > Bilan des capacités du moteur. Établi le 2026-07-02, **revu le 2026-09-06** : la > frontière ⭐/🔧 avait cessé de dire vrai — deux reconstructions depuis zéro (2026-08-13, > puis 2026-09-02) ont fait passer côté ⭐ presque tout ce que le §5 annonçait « à > éprouver ». Fondé sur l'état réel du dépôt (≈65 rôles, ≈60 playbooks, le moteur de plan, > la GUI). **Le détail rôle par rôle vit dans [`catalogue-services.md`](catalogue-services.md)** ; > ici on ne garde que le bilan. > > Deux niveaux de maturité sont distingués honnêtement : > - **⭐ Prouvé** — déployé et vérifié de bout en bout sur cluster Proxmox réel. > - **🔧 Outillé** — le rôle existe et est câblable par le plan, mais n'a pas (encore) été éprouvé > en déploiement réel. À valider avant de le déclarer « prouvé » (cf. la méthode > « éprouver l'outil avant le rôle »). --- ## En une phrase **Set-OPS est un moteur souverain qui transforme un plan déclaratif en écosystème numérique complet — PKI, identité, DNS, web, courriel — cloné depuis un golden template durci, piloté par une GUI utilisable sans IA, en multi-tenant, tout en logiciel libre.** Le cœur d'infrastructure **et** la couche des services applicatifs (SSO, données, forge, observabilité, supervision, collaboration) sont **prouvés de bout en bout** : la flotte a été rasée puis remontée d'un seul trait, deux fois, sans échec. --- ## 1. Le moteur — transformer une intention en écosystème Pouvoir central : **plan déclaratif → écosystème vivant**. On décrit *quoi* (des fichiers `plan/*.yml`), Set-OPS fait *comment*. - **`scripts/instancier.py`** — lit `nomenclature / serveurs / applications / bases-donnees.yml` et **dérive** tout : VMID, IP, groupes d'inventaire, dimensionnement. ⭐ - **Nomenclature fédérée** — le seul champ saisi est l'**`index`** ; supernet, VLAN, IP, passerelle et **VMID** en dérivent, sans collision possible entre instances. Le VMID est le **miroir de l'adresse** sur neuf chiffres — ``, soit `117602101` pour `1176` · `021` · `01` : on retrouve la VM depuis son adresse, et l'inverse, sans registre. **P20** interdit d'écrire un adressage au plan. ⭐ - **Dimensionnement automatique** — chaque rôle porte une `meta/empreinte.yml` (cœurs / RAM / disque) ; l'outil **somme les empreintes et taille la VM** hôte. ⭐ - **Multi-instance = multi-tenant** — le symlink `instance/` pointe vers un dépôt par écosystème, avec voûte et identité propres. Lab et prod ne sont qu'un cas particulier. ⭐ - **Cycle de vie complet** (cibles `make`) : `preparer-modele → instancier → creer-vm → deployer → verifier`. ⭐ ## 2. Le plan de contrôle — exploitable sans IA Impératif fondateur : un sysadmin exploite l'outil **sans IA** ; l'IA n'assiste que le mainteneur. - **GUI souveraine** (`scripts/inventory_gui.py`, stdlib pure, aucune dépendance) : visualise le plan, **bouton « Pousser »** (crée la VM pour un serveur / déploie pour une app ou une base), **sonde de vivacité**, passage auto en « actif », jeton d'authentification. ⭐ - **Voûte au déploiement** — secrets chiffrés par Ansible Vault, **jamais en clair** dans la GUI, qui n'en montre que les *noms*. **Une voûte, une clé** (2026-08-28) : chaque dépôt a la sienne, et le `Makefile` les rassemble tout seul (`scripts/voutes.py`), sans rien exporter ni rendre l'exécution interactive. ⭐ - **Validation intégrée** — `syntax-check`, `ansible-lint` (profil *production*), `verifier`. ⭐ ## 3. Le socle — un golden template durci **⭐ Prouvé** : clone + application du socle de bout en bout sur le cluster Proxmox. - **Base** : `common_packages`, `chrony`, `qemu_guest_agent`, `cloud_init`, `motd`, `hosts_statiques` (plancher de résolution, indépendant du DNS), `sudo_ansible`, `template_cleanup`. - **SSH** : `ssh_baseline` puis `ssh_hardening` (bascule mot de passe → clé, seulement après validation de l'accès par clé). - **Durcissement** — les **dix** rôles que compose le groupe `serveur_durci` : `hardening_packages`, `sysctl_hardening`, `core_dumps`, `unattended_upgrades`, `apparmor`, `auditd`, `fail2ban_ssh`, `journald`, `ssh_hardening`, `nftables_baseline` (**éteint dans le rôle, armé par le plan** : `hotes_actifs` le met à `true`, le gabarit doré le laisse à `false` — le pare-feu n'est pas une propriété du rôle, c'est une décision de l'instance). Le jeu de règles n'est pas écrit à la main : il est **dérivé du registre des flux** (`meta/flux.yml` → `scripts/resoudre_flux.py`). - **Proxmox** : clonage depuis le golden template + redimensionnement disque (grow-only). > Séparation nette : **Proxmox + cloud-init** donnent l'identité initiale de la VM ; > **Set-OPS + Ansible** font la configuration réelle du serveur. ## 4. Les piliers d'infrastructure — tous prouvés ⭐ | Domaine | Rôle(s) | Preuve | |---|---|---| | **PKI** | `serveur_step_ca` + `client_pki` | AC interne + **mTLS avec SAN**, empreinte racine câblée | | **Identité** | `serveur_openldap` | **LDAPS** réel sur certificat step_ca | | **DNS interne** | `serveur_powerdns` | résolution interne | | **Reverse-proxy** | `serveur_nginx` | frontal web | | **Courriel (Étape A)** | `serveur_dovecot` + `serveur_postfix` + `serveur_rspamd` | **flux complet** : SMTP → validation LDAP → LMTP → boîte → **lecture IMAP** + antispam + **signature DKIM** | La messagerie interne est un service souverain complet : réception SMTP, validation des boîtes par annuaire LDAP, remise LMTP réseau chiffrée step_ca vers le stockage, accès IMAP authentifié LDAP, filtrage antispam et signature DKIM en milter. Topologie **MTA dédié en périphérie / boîtes à l'intérieur** (défense en profondeur). ## 5. Les services applicatifs — prouvés depuis ⭐ Ce paragraphe annonçait, jusqu'au 2026-09-06, des rôles « construits mais à éprouver ». Ils l'ont été : **la reconstruction depuis zéro les a tous repris sur machine nue** (2026-08-13, puis 15/15 et 14/14 hôtes le 2026-09-02, `make valider` à 0 échec). - **SSO web** : `serveur_keycloak` — OpenLDAP source de vérité, fédération LDAP automatisée, courriel en bind LDAP direct. ⭐ - **Passerelle SSO** : `serveur_oauth2_proxy` — met au SSO une application sans OIDC natif (éprouvé devant Icinga Web 2). ⭐ - **Données** : `serveur_postgresql`, `serveur_redis` — bases et comptes dérivés du registre, TLS `verify-full` de bout en bout. ⭐ - **Forge logicielle** : `serveur_forgejo` — Git + PostgreSQL + SSO OIDC. ⭐ - **Observabilité** : `serveur_prometheus`, `serveur_grafana`, `serveur_loki`, avec les clients `client_metrique` et `client_journal`. ⭐ - **Supervision** : `serveur_icinga`, `serveur_icingaweb2` — Icinga 2 + IcingaDB + Web 2 + BPM. **Sans agent sur les hôtes** : contrôles actifs depuis le cœur, résultats passifs poussés par l'API. ⭐ - **Sauvegardes** : `serveur_backup`, `client_backup` — restic hors-nœud, chaque nœud vérifiant son **propre dépôt distant**, restauration éprouvée. ⭐ - **Plateforme webapp** : `serveur_web_frontal`, `serveur_web_dorsal` — statique et natif (venv + systemd + nginx), zéro conteneur. ⭐ - **Intégrations transverses** : `client_pki`, `client_backup`, `client_smtp`, `client_metrique`, `client_journal`, `client_resolveur`, `client_artefacts`. ⭐ Reste **🔧 outillé** — déployé, mais dont l'*usage* n'est pas consigné comme preuve : - **Collaboration** : `serveur_nextcloud`, `serveur_collabora` (natif, plus de conteneur). Base et client OIDC dérivés du plan, posés par la reconstruction ; le dépôt d'un fichier et l'édition partagée à deux, eux, n'ont pas été consignés. 🔧 > Deux noms ont été retirés de ce paragraphe parce qu'ils n'ont jamais existé : > `client_supervision` (la supervision est sans agent — cf. `catalogue-services.md`) et les > « méta-rôles d'agrégation » `identity` / `storage`. La conformité passe par > `playbooks/groupes/`, un playbook par groupe ; les répertoires `playbooks/applications/`, > `database/`, `web/`, `monitoring/`, `backup/` ne contiennent qu'un README d'espace réservé. ## 6. Les patrons d'ingénierie — la valeur invisible ⭐ - **Pont de certificat** step_ca → service, avec **resynchronisation au renouvellement** (unité systemd `.path`). Réutilisé par openldap, dovecot, postfix. - **Ordonnancement socle-first** — le plancher `/etc/hosts` est posé avant les clients qui en dépendent (ex. `client_pki` sur un nœud neuf). - **Sûreté en check-mode** — `when: not ansible_check_mode` sur les tâches de service, pour un dry-run fiable même quand le service n'est pas encore installé. - **Idempotence** — `changed=0` au redéploiement (prouvé). - **Méthode « éprouver l'outil avant le rôle »** — inspecter empiriquement le vrai binaire avant d'écrire le rôle qui l'enveloppe. A évité les bugs de premier déploiement (rspamd : zéro bug ; pivot Stalwart → Postfix/Dovecot/rspamd décidé sur preuve). - **Machine d'épreuve jetable** (`make cloner-vm`) — l'**instrument** de la méthode ci-dessus : une Debian issue du gabarit doré, sur le réseau choisi, en deux minutes, **hors du plan**. Le moteur ne la connaît pas — donc aucune politique, aucun certificat, aucune sauvegarde, et `make raser` ne la détruira jamais. À détruire à la main. Voir `vm-lifecycle.md` §4bis. --- ## Prochaines frontières - **Consigner l'usage** de la collaboration (dépôt de fichier, édition partagée) — le seul 🔧 qui reste. - **Courriel Étape B** (public) : DNS public (MX, SPF, **DKIM** — clé `setops._domainkey` déjà générée, DMARC), MX externe et réputation, PTR / FCrDNS. - **Les équipements de l'hébergeur** — hyperviseurs, commutateurs, frontière : ni inventaire, ni sauvegarde de configuration, ni supervision. Les *VM* du site en ont depuis le 2026-09-02, les *équipements* non (cf. `hebergeur-exploitation.md`). - **Seuils d'adoption** d'outils tiers (NetBox, AWX) plutôt que de réimplémenter le plan de contrôle maison, qui reste volontairement gelé. > Principe fondateur : **tout est libre**. L'univers numérique (Alliance Boréale / Chezlepro / > Set-OPS) se construit exclusivement avec du logiciel libre.