Daniel Allaire
4a1d0836d0
Solde la dette documentaire repérée à l'audit du 2026-07-03. Tous les rôles ont désormais un README, au format maison (intention → rôle → variables → notes/limites → prérequis). Ils documentent ce qui ne se lit PAS dans les tâches : - serveur_debian : rôle-catégorie sans tâches — il ne porte que le flux SSH du plan de gestion, sans quoi les nftables générés couperaient l'accès Ansible à toute la flotte ; le vrai travail est dans le playbook de groupe. - hosts_statiques : le plancher /etc/hosts comme CONDITION de l'ordre de reconstruction (résolution par nom avant que PowerDNS existe) ; fichier entièrement géré, alias d'exposition best-effort. - resoudre_base / resoudre_annuaire : entrées, sorties (facts), et pourquoi le FQDN plutôt que le nom court (fédération + nom canonique pour verify-full). - serveur_dovecot : les 3 réglages Dovecot 2.4 qui conditionnent la remise (static_allow_all_users, mail_inbox_path vide, mail_path par utilisateur) et le local-part seul comme chemin commun LMTP/IMAP ; limite mono-domaine. - serveur_postfix : liens mailstore/milter, recopie de /etc/hosts dans le chroot. - serveur_rspamd : clé DKIM idempotente ; le domaine signé doit être PUBLIC en prod, sinon la signature ne vaut rien pour les MX distants. - client_backup / serveur_backup : jobs déclaratifs, chiffrement côté client, deux pièges (jobs vides = silencieux ; dépôt neuf vide après un from-zero) ; hors-nœud n'est pas hors-site. - serveur_oauth2_proxy : le patron réutilisable Keycloak-devant-n'importe-quoi, et pourquoi allow_unverified_email est nécessaire avec un annuaire LDAP. - serveur_icingaweb2 : modes ldap vs external, écoute à restreindre en SSO. - client_unbound : le garde-fou de bascule (apply ET confirm, validation réelle avant de toucher /etc/resolv.conf). docs/carte-set-ops.md ne décrivait plus l'état du code : - expose EST consommé au déploiement (annoncé comme « Phase 3 à venir ») : expositions_des_applications + expositions.conf.j2, alias /etc/hosts, SANs d'edge dérivés par instancier.py ; - 3 mécanismes transverses ajoutés (résolution d'annuaire, plancher de résolution, resoudre_base nommé dans les bindings app→base) ; - 5 entrées d'index ajoutées : réseau/pare-feu, ordre de déploiement, preuve/recette, exploitation courante, wiki — pans du corpus non indexés ; - ce qui reste ouvert est marqué : meta/liens.yml sur le seul serveur_postfix, requiert non consommé au déploiement (l'ordre vient des couches + du graphe). make verifier vert : ansible-lint 514 fichiers, tests, syntax-check, 23 preuves CONFORME / 0 échec / 0 sauté. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| docs | ||
| exemples | ||
| filter_plugins | ||
| playbooks | ||
| promo | ||
| roles | ||
| scripts | ||
| wiki | ||
| .ansible-lint | ||
| .gitignore | ||
| AGENTS.md | ||
| ansible.cfg | ||
| CHANGELOG.md | ||
| CLAUDE.md | ||
| LICENSE | ||
| Makefile | ||
| QUICKSTART.md | ||
| README.md | ||
| requirements.yml | ||
| SOLUTION.md | ||
| tl.ini | ||
| underlay.yml.example | ||
Set-OPS — moteur d'écosystèmes numériques souverains
Set-OPS est un moteur Ansible générique qui permet à un hébergeur de construire et exploiter un écosystème numérique souverain — DNS interne, AC/PKI, identité (LDAP + SSO), relais courriel, bases de données, observabilité, applications — sur sa propre grappe Proxmox, à partir d'un plan déclaratif.
Le dépôt est le moteur (générique, partageable). Chaque déploiement réel est une instance (le plan + l'inventaire d'un hébergeur, dans son propre dépôt). Tu crées la tienne à partir d'un modèle prêt à déployer (exemples/modeles/).
👉 Tu débarques avec une grappe Proxmox et tu veux monter ton écosystème ? Commence par
QUICKSTART.md.
Souveraineté jusqu'au bout : Set-OPS s'exploite entièrement à la main — la doc, make et le GUI suffisent, sans aucune IA. L'outil libère de la dépendance aux géants ; il ne la remplace pas par une dépendance à une IA.
Mission (la vision derrière l'outil)
Set-OPS ne se limite plus à l'exploitation : il définit et construit un écosystème numérique souverain — une infrastructure interne auto-suffisante, sans dépendance SaaS, décrite en code et pilotée par des registres machine-lisibles qui font office de source unique de vérité (instance/plan/serveurs.yml, instance/plan/applications.yml, instance/plan/bases-donnees.yml, instance/plan/domaines.yml, instance/plan/nomenclature.yml, docs/dependances-groupes.yml).
Piliers de l'écosystème :
- identité — machines (PKI / certificats) et utilisateurs (annuaire + SSO) ;
- confiance — autorité de certification interne (ACME) ;
- nommage et adressage — DNS interne et nomenclature dérivable ;
- données — bases relationnelles et cache, avec registre des connexions ;
- communication — relais courriel interne ;
- observabilité et supervision — métriques, journaux, tableaux de bord, supervision active ;
- applicatif — services internes (forge, etc.) et couche web.
L'état voulu est déclaratif et convergent (appliqué par les groupes Ansible), souverain par conception, mais piloté par l'opérateur (pas d'auto-remédiation : la boucle n'est pas fermée). Une grande partie est aujourd'hui définie et validée avant d'être déployée sur des VM réelles ; le template Debian 13 reste la fondation, pas la finalité.
Cadre et règles d'autorité : voir AGENTS.md (section « Mission et identité »).
Le plan : on édite, l'inventaire se génère
Set-OPS se pilote par un plan, pas par l'édition directe de l'inventaire.
instance/inventories/production/hosts.yml est généré depuis le plan — ne pas l'éditer à la main.
éditer le PLAN → make instancier (revoir le diff) → make instancier-appliquer → make deployer
- Plan :
instance/plan/serveurs.yml(les VM),instance/plan/applications.yml(les services et leurs liens),instance/plan/bases-donnees.yml,instance/plan/domaines.yml, dérivés viainstance/plan/nomenclature.yml. - GUI (
make inventaire-ui) : vues Serveurs et Applications pour éditer, puis « Appliquer le plan » ; la vue Inventaire est en lecture seule. - VMID / IP / VLAN sont dérivés de la
fonction; les groupes d'une VM sont dérivés des applications qui y tournent.
Guide complet : docs/plan-et-generation.md.
Portée transverse
Au-delà des piliers ci-dessus, le dépôt couvre des préoccupations transverses, communes à toutes les VM :
- templates de VM Proxmox (la fondation) ;
- groupes de conformité et durcissement ;
- maintenance ;
- sauvegardes.
Premier chantier
Template Debian 13 Proxmox :
playbooks/modeles_vm/debian13_proxmox_preparer.yml
playbooks/modeles_vm/debian13_proxmox_verifier.yml
playbooks/modeles_vm/debian13_proxmox_nettoyer.yml
Principe
Le template contient seulement le socle commun.
Les services spécialisés seront installés ensuite sur les clones :
- NGINX ;
- PostgreSQL ;
- MariaDB ;
- Docker/Podman ;
- monitoring complet ;
- applications métier.
Exploitation courante
Un Makefile fournit les commandes d'exploitation principales.
Afficher l'aide :
make
Valider le dépôt :
make verifier
Produire une preuve de conformité horodatée (rejoue les preuves du registre des
affirmations → docs/audit/preuve-<date>.md ; mode d'emploi : docs/audit/README.md) :
make prouver
Inspecter les inventaires :
make inventaire
make hote-afficher HOTE=web-frontal-01
Ouvrir l'interface locale de gestion d'inventaire :
make inventaire-ui
Planifier une VM passe désormais par le plan, pas par l'édition de l'inventaire :
- déclarer la VM dans
instance/plan/serveurs.yml(vue Serveurs du GUI, oumake serveurs) —fonction,etat, placement ; VMID/IP/VLAN sont dérivés ; - déclarer les services qui y tournent dans
instance/plan/applications.yml(vue Applications) ; - régénérer l'inventaire :
make instancier # génère + diff sémantique (que va-t-il changer ?)
make instancier-appliquer # régénère instance/inventories/production/hosts.yml
Les anciennes commandes make hote-planifier / hote-ajouter / hote-groupes éditaient l'inventaire directement ; elles sont supplantées par le plan (l'inventaire est généré, ne pas l'éditer à la main).
Chaque groupe opérationnel doit avoir son playbook homonyme dans playbooks/groupes/.
La conformité normale des VM passe par ces playbooks de groupes. Les rôles de socle et de durcissement sont appliqués par serveur_debian et serveur_durci, pas par des playbooks de couches séparés.
Les groupes opérationnels avec des hôtes, comme serveur_keycloak ou client_pki, sont validés contre playbooks/groupes/ par les commandes d'inventaire.
Le catalogue des services et intégrations prévus est dans docs/catalogue-services.md.
Les dépendances causales entre groupes sont dans docs/dependances-groupes.yml.
Le runbook du DNS interne initial est dans docs/dns-interne.md.
La nomenclature des noms de VM et des VMID est dans docs/nomenclature-vm.md.
Créer un clone depuis le modèle Debian 13 via l'API Proxmox :
make config
make creer-vm HOTE=web-frontal-01 # VMID/IP/VLAN/passerelle lus dans le plan
make deployer HOTE=web-frontal-01
L'hôte doit d'abord être déclaré dans instance/plan/serveurs.yml et l'inventaire régénéré (make instancier-appliquer) : creer-vm ne prend que HOTE, le reste est dérivé.
Les valeurs Cloud-Init communes déjà présentes dans le modèle Proxmox sont héritées par les clones.
Préparer le golden template Debian 13 Proxmox :
make preparer-modele
make verifier-modele
Le nettoyage final du template est protégé :
make nettoyer-modele CONFIRMER=true
Déployer ou remettre en conformité une VM Debian clonée depuis le template :
make deployer HOTE=web-frontal-01
Déployer ou remettre en conformité un groupe :
make deployer-groupe GROUPE=serveur_debian
Les déploiements de groupes ciblent automatiquement les hôtes actifs seulement.
Licence
Copyright (C) 2026 Daniel Allaire — Chezlepro / Alliance Boréale.
Set-OPS est un logiciel libre : vous pouvez le redistribuer et/ou le modifier selon les termes de la GNU Affero General Public License telle que publiée par la Free Software Foundation, soit la version 3, soit (à votre choix) toute version ultérieure.
Set-OPS est distribué dans l'espoir qu'il sera utile, mais SANS AUCUNE GARANTIE ; sans même la garantie implicite de QUALITÉ MARCHANDE ou d'ADÉQUATION À UN USAGE PARTICULIER. Voir la GNU Affero General Public License pour plus de détails.
Le texte intégral fait foi dans le fichier LICENSE et sur
https://www.gnu.org/licenses/agpl-3.0.html.
Pourquoi l'AGPLv3
Libre et copyleft fort. Chacun peut utiliser, exécuter, étudier et modifier Set-OPS — y compris commercialement. En contrepartie, quiconque l'offre comme service en réseau doit mettre à disposition ses modifications sous la même licence. Cela protège la souveraineté (pas de captation propriétaire) sans jamais interdire l'usage commercial — cohérent avec le principe fondateur : tout est libre.
Modèle : libre + services
Set-OPS est entièrement libre ; aucune fonctionnalité n'est réservée ni verrouillée. Les revenus, le cas échéant, proviennent de services autour du logiciel, jamais de sa fermeture :
- support / SLA, hébergement géré, formation, intégration, développement sur mesure ;
- certification d'écosystèmes (label Souverain / Résilient / Exemplaire).
Les artisans et coopératives peuvent exploiter Set-OPS pour leur propre infrastructure sans redevance : l'usage interne ne déclenche aucune obligation de partage. Le copyleft AGPL ne vise que la captation propriétaire (offrir Set-OPS en service fermé sans en partager les évolutions).