Daniel Allaire
ac48b7650b
Some checks are pending
verifier / verifier (push) Waiting to run
Le decoupage du site en quatre zones a revele un defaut qui dormait dans le moteur. `firewall=1` sur l'interface d'une VM fait passer tout le trafic ponte par conntrack. Sur un VNet SDN c'est sans consequence : en EVPN le routage inter-VNet se fait dans le VRF, SUR LE NOEUD, et le flux ne quitte jamais l'hyperviseur. Sur un pont classique route par une frontiere externe, deux VM du MEME noeud dans deux VLAN differents ne se parlent qu'en EPINGLE : la trame sort par le lien physique, la frontiere la route, elle revient sur le meme pont. La meme table conntrack voit alors les deux moities de la connexion, classe le retour INVALID, et PVEFW-FORWARD le jette. La mesure a tranche : ops(asgard) -> pki(asgard) 0/8 dns(gandalf) -> cache(gandalf) 0/8 ops(asgard) -> forge(vishnu) 6/8 dns(gandalf) -> pki(asgard) 6/8 ops(asgard) -> cache(gandalf) 8/8 dns(gandalf) -> forge(vishnu) 8/8 Toutes les paires intra-noeud echouent, toutes les paires inter-noeuds passent. Douze tentatives faisaient monter le compteur `ctstate INVALID` de +112 sur asgard et +116 sur gandalf ; `firewall=0` pose, il ne bouge plus — 0 sur les deux, pour le meme trafic. Le defaut se deguise en panne reseau : la poignee TCP ABOUTIT, et ce sont les paquets de DONNEES qui disparaissent. L'AC le disait dans son propre journal (`TLS handshake error ... i/o timeout` : elle accepte et attend un ClientHello qui n'arrive jamais). Ecartes un par un, par la mesure : regles identiques champ par champ, alias corrects, assignation des interfaces confirmee, ARP et routes saines, IPS desactive, shaper vide, NAT source limite a `wan`, MTU a 1500 de bout en bout — et la taille sans effet, 100 octets se perdant comme 1460. L'INTENTION DECLAREE NE SUFFIT PAS : un tenant declare `proxmox_clone_parefeu_interface: true` avec `proxmox_clone_pont: vmbr1` comme valeur PAR DEFAUT, chaque hote la remplacant par son VNet derive. L'hote qui retombe sur `vmbr1` naitrait arme sur un pont classique. `cloner_vm_debian.yml` croise donc l'intention avec le pont REELLEMENT utilise, et le dit quand il desarme — un desarmement muet serait le meme piege, en silence. P45 EVALUE l'expression du playbook sur quatre cas plutot que d'en lire le texte, dont un qui DOIT rendre vrai : sans lui, une expression constamment fausse passerait la preuve sans rien garantir. Controle negatif verifie — le drapeau remis a plat fait echouer la preuve. Ce commit emporte aussi le desarmement d'`unattended-upgrades` dans `common_packages`, jusqu'ici applique sur les machines mais pas versionne : le verrou dpkg tenu 48 minutes par une vague de maj automatiques a coute deux deploiements. Le site a revele ce defaut parce qu'il a ete le premier a porter plusieurs zones. Ce n'est pas une particularite du site : un tenant derive les siennes du meme principe. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .forgejo/workflows | ||
| docs | ||
| exemples | ||
| filter_plugins | ||
| playbooks | ||
| promo | ||
| roles | ||
| scripts | ||
| wiki | ||
| .ansible-lint | ||
| .git-allowed-signers | ||
| .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/).
Par où entrer — selon ce que tu viens faire
On n'arrive pas avec un sujet, on arrive avec une situation. Il y en a cinq :
| Ta situation | Ta porte |
|---|---|
| « Je veux monter mon écosystème sur ma grappe Proxmox » | QUICKSTART.md |
| « Je prête mon matériel à quelqu'un qui déploiera dessus » | docs/preparer-un-site-hebergeur.md |
| « Je vais implanter un tenant existant sur un site neuf » | docs/implanter-un-tenant-sur-un-site.md |
| « Je viens d'hériter d'un écosystème déjà déployé, je dois l'exploiter » | wiki/Reprendre-l-écosystème.md |
| « Je dois modifier le moteur » | docs/carte-set-ops.md |
| « J'apprends le métier » | wiki/Home.md |
Et si tu veux d'abord savoir ce que c'est : continue simplement ci-dessous.
Le wiki (
wiki/) est publié depuis ce dépôt vers la forge. Une page modifiée dans l'interface de la forge est détruite à la publication suivante : on lit là-bas, on écrit ici.
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).