Daniel Allaire e006dee693 Retirer 3 rôles legacy (serveur_sendmail, client_dns, client_ldap) + nettoyage

Supprimés (supersédés / hors-conception) : serveur_sendmail (→ Postfix),
client_dns (→ plancher + client_unbound), client_ldap (login LDAP OS, hors
design). Rôles + playbooks de groupe retirés.

Nettoyage des références :
- dependances-groupes.yml : entrées client_dns/client_ldap retirées + entrées
  mortes des scaffoldings (nextcloud/collabora/client_supervision) ; deps
  périmées corrigées (client_smtp → serveur_postfix ; serveur_keycloak →
  serveur_postgresql, la raison parlait à tort de Nextcloud).
- 6 modèles d'exemple : app mail serveur_sendmail → serveur_postfix.
- README, AGENTS : listes/glossaire nettoyés.
- catalogue-services : listes, tables, roadmap ; note « rôles retirés ».
- nomenclature-vm : infra-mail-01 → serveur_dovecot (était faux).
- courriel-conception, dns-interne (re-ciblé client_unbound), pouvoirs,
  intrants, READMEs (client_smtp/forgejo/openldap/unbound).

ansible-lint : 0 échec (366 fichiers). instancier OK.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-04 12:14:04 -04:00

6.9 KiB

Raw Blame History

Les pouvoirs de Set-OPS

Bilan des capacités du moteur, au 2026-07-02. Fondé sur l'état réel du dépôt (≈50 rôles, ≈30 playbooks de groupe, le moteur de plan, la GUI).

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 est prouvé de bout en bout ; la couche des services applicatifs (SSO, données, forge, observabilité) est outillée et prête à éprouver.

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 — un index + catégorie + service produit un VMID {index}{cat}{svc}{seq} et une IP déterministes, sans collision entre instances. ⭐
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, saisis au déploiement, jamais en clair dans la GUI ; usage via le fichier de mot de passe, non interactif. ⭐
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 : apparmor, auditd, fail2ban_ssh, sysctl_hardening, hardening_packages, unattended_upgrades, journald, core_dumps, nftables_baseline (installé et préparé, non activé par défaut).
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 outillés — rôles présents 🔧

Construits et câblables par le plan ; à éprouver en déploiement réel avant de les déclarer prouvés.

SSO web : serveur_keycloak (architecture décidée : OpenLDAP source de vérité, Keycloak fédéré en OIDC, courriel en bind LDAP direct).
Données : serveur_postgresql, serveur_redis.
Forge logicielle : serveur_forgejo.
Observabilité : serveur_prometheus, serveur_grafana, serveur_loki, serveur_icinga, avec les clients client_metrique, client_journal, client_supervision.
Intégrations transverses : client_pki, client_backup, client_smtp, client_metrique, client_journal, client_unbound.
Méta-rôles d'agrégation : identity, applications, database, web, monitoring, backup, storage.

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).

Prochaines frontières

Éprouver les services outillés (Keycloak fédéré, observabilité, PostgreSQL, Forgejo).
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.
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.

6.9 KiB Raw Blame History