make instancier genere hosts.genere.yml (gitignore) depuis le plan (serveurs.yml + applications.yml + nomenclature.yml) et compare SEMANTIQUEMENT a l'inventaire actuel via ansible-inventory --list. - scripts/instancier.py : generer + comparer (host vars derives, groupes derives = socle + services (applications) + integrations (clients_*) + etat). - serveurs.py bootstrap capture les clients_* comme 'integrations' par VM. - inventory_rules : valide 'integrations'. Resultat : DIFF VIDE -- le plan reproduit exactement les 13 hotes. La bascule (hosts.yml genere + UI editant le plan) reste NON effectuee : elle attend une validation explicite. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
254 lines
36 KiB
Markdown
254 lines
36 KiB
Markdown
# CHANGELOG — Set-OPS
|
||
|
||
## 2026-06-23
|
||
|
||
### Modifié
|
||
- **Phase 2 (début) — vue Chaîne holistique.** Dans `make inventaire-ui`, la vue Chaîne montre désormais, pour chaque application d'un hôte, l'ensemble de ses liens : `expose` (FQDN publics), `requiert` (applications dont elle dépend) et ses bases (DSN), plus son port. On voit d'un coup d'œil comment VM, applications, bases et domaines s'articulent.
|
||
- **Phase 1b — clarté de nommage.** La clé `domaines:` de `docs/nomenclature.yml` (familles fonctionnelles : `infra-pki`, `web-frontal`…) est renommée **`fonctions:`** pour lever la collision avec les domaines DNS (`docs/domaines.yml`). L'auto-proposition du GUI suit (`fonctionDe` / `infoFonction`, `nomenclature.fonctions`, libellés « Fonction inconnue… », placeholder `fonction-NN`). Aucun rôle ni inventaire impacté : la nomenclature n'est consommée qu'au moment de la planification.
|
||
- **Refonte « application-hub », Phase 1 — les liens deviennent explicites (inventaire inchangé, zéro régression).** L'application porte désormais tous ses liens : `groupe` (capacité/rôle), `hote` (VM), `port`, **`requiert`** (autres applications dont elle dépend) et **`expose`** (FQDN publics qui la publient). L'**exposition DNS quitte `docs/domaines.yml`** (le bloc `exposition` est retiré) et vit sur l'application via `expose` ; `docs/domaines.yml` ne décrit plus que les zones (autorité, edge, secondaires, dnssec, mail). `serveurs_nginx` dérive ses vhosts des **applications** (`expose` + edge du domaine), résolvant `application → hôte → IP` (rôle + `expositions.conf.j2` réécrits). Nouvelle règle partagée `expositions_des_applications` (+ `domaine_parent`) dans `inventory_rules.py`, exposée à Ansible par le filter plugin ; `valider_applications` valide `requiert` (applis connues), `expose` (domaine parent déclaré) et `port`. CLI (`applications.py --port/--requiert/--expose`, `domaines.py` affiche les expositions dérivées) et **GUI** (champs Port/Requiert/Expose sur la fiche Application, persistés) suivent ; l'API expose aussi le registre des domaines. Le groupe n'est plus une cible de liaison, seulement une capacité. *(Renommage `nomenclature.domaines:` → `fonctions:` reporté en Phase 1b ; génération de l'inventaire depuis le plan en Phase 3.)*
|
||
|
||
### Ajouté
|
||
- **Phase 3 — générateur d'inventaire depuis le plan (non destructif ; diff vide prouvé).** `make instancier` (`scripts/instancier.py`) génère `inventories/production/hosts.genere.yml` (gitignoré, artefact) depuis le plan — `docs/serveurs.yml` + `docs/applications.yml` + `docs/nomenclature.yml` — puis **compare sémantiquement** (via `ansible-inventory --list`, formatage ignoré) avec l'inventaire actuel : host vars dérivés (IP/VMID/VLAN/passerelle de la nomenclature, placement/taille du registre serveurs), groupes dérivés (socle `debian`/`durcis` + services depuis les applications + intégrations `clients_*` + état). Prérequis posés : `make applications-bootstrap` (services `serveurs_*` → applications) et `serveurs.yml` enrichi d'`integrations` (les `clients_*` par VM, capturés au bootstrap). **Résultat : DIFF VIDE — le plan reproduit exactement les 13 hôtes de l'inventaire.** La bascule (rendre `hosts.yml` généré et faire éditer le plan par l'UI) reste **non effectuée** : elle attend une validation explicite.
|
||
- **Phase 2 — le serveur (VM) entre dans le plan (lecture seule, l'inventaire reste autorité).** Nouveau registre `docs/serveurs.yml` (VM = `fonction` + `etat` + placement/dimensionnement Proxmox), **bootstrapé depuis l'inventaire** (`make serveurs-bootstrap`). La dérivation nomenclature (fonction + rang → VMID/IP/VLAN/passerelle) est portée en Python (`deriver_nomenclature`, source unique, miroir de l'auto-proposition du GUI) et la **réconciliation** compare le dérivé aux valeurs de l'inventaire (`reconcilier_serveur`). CLI `scripts/serveurs.py` (`lister`/`verifier`/`bootstrap`) + cibles `make serveurs` / `serveurs-verifier` / `serveurs-bootstrap`, intégré à `make inventaire-verifier`. GUI : vue **Serveurs** (lecture seule) affichant le plan + valeurs dérivées + statut de réconciliation. Bootstrap initial : **13 serveurs, tous réconciliés** (le dérivé reproduit exactement l'inventaire → la génération de Phase 3 pourra viser un diff vide).
|
||
- **Application = entité de première classe** (une VM peut porter plusieurs applications). Nouveau registre `docs/applications.yml` (`application → groupe, hote`). Les bases se lient via `consommateur` + **`portee`** (`application` | `groupe` | `hote`, défaut `groupe`) dans `docs/bases-donnees.yml` : une application `A` (groupe `G`, hôte `H`) reçoit les bases où `(portee=application ET consommateur=A) OU (portee=groupe ET consommateur=G) OU (portee=hote ET consommateur=H)` — plusieurs DSN par application. Résolution + validation partagées dans `inventory_rules.py` (`charger_applications`, `valider_applications`, `applications_de_hote`, `bases_de_application`, `PORTEES_BD` ; `valider_bases` croise désormais `portee=application` avec le registre des applications). CLI `scripts/applications.py` (`lister`/`verifier`/`ajouter`/`retirer`) + `scripts/bases_donnees.py --portee` ; cibles `make applications` / `applications-verifier` ; validation intégrée dans `make inventaire-verifier`. GUI : vue **Applications** (CRUD), sélecteur de **portée** + consommateur dynamique (groupe/hôte/application) dans la vue Bases, et **vue Chaîne par application** (DSN résolus par hôte). Filter plugin `filter_plugins/registres.py` exposant la **même** règle de résolution à Ansible (source unique) ; les playbooks `serveurs_web_dorsaux` / `serveurs_web_frontaux` itèrent désormais sur les applications de l'hôte et résolvent leurs bases (scaffold ; le déploiement applicatif réel s'y insère). Les services en grappe (keycloak/icingadb/forgejo) restent en `portee: groupe` (inchangés).
|
||
- Vhosts `serveurs_nginx` **dérivés du registre `docs/domaines.yml`** (bloc `exposition`) : pour chaque exposition `web` ciblant cet edge, un vhost est généré (`expositions.conf.j2`) avec amont = `amont` explicite, sinon `http://<IP interne de la cible>:<port>` résolu depuis l'inventaire ; une exposition non résolvable (cible sans hôte actif, ou sans port) est listée mais non publiée. Variables `serveurs_nginx_groupe` (edge ciblé) et `serveurs_nginx_publier_expositions` (bascule). Les sites déclarés à la main continuent de coexister. Ajout du `port: 3000` à l'exposition `forge`.
|
||
|
||
## 2026-06-22
|
||
|
||
### Ajouté
|
||
- Registre déclaratif des domaines publics `docs/domaines.yml` (publication externe des hostnames), symétrique de `docs/bases-donnees.yml`. Modèle d'autorité retenu : **primaire caché + secondaires** (PowerDNS backend PostgreSQL + API non exposé, secondaires publics via AXFR/TSIG). Bloc **`exposition`** = binding `nom public → service interne (cible) → edge`, destiné à trois consommateurs (génération de zone publique, vhosts `serveurs_nginx`, noms à certifier ACME). Validation partagée dans `inventory_rules.py` (`charger_domaines`, `valider_domaines`, `fqdn_exposition`, `expositions_du_groupe` ; autorités connues `primaire-cache|auto-heberge|delegue`, `edge` requis, FQDN uniques). CLI miroir `scripts/domaines.py` (`lister`/`verifier`) + cibles `make domaines` / `make domaines-verifier`, et validation intégrée dans `make inventaire-verifier`. Première entrée réelle : `forge.alliance-boreale.ca → serveurs_forgejo` (DNSSEC, secondaires et enregistrements mail laissés à renseigner).
|
||
- Formalisation de l'identité du dépôt : `AGENTS.md` (nouvelle section « Mission et identité ») et `README.md` (section « Mission ») actent que `Set-OPS` **définit et construit l'écosystème numérique souverain de Chezlepro Inc.** — piliers (identité, confiance, nommage/adressage, données, communication, observabilité/supervision, applicatif), propriétés (souverain, déclaratif/convergent) et limites honnêtes (pas d'auto-remédiation ; en grande partie défini/validé avant déploiement réel). Le template Debian 13 reste la fondation, pas la finalité.
|
||
- Gestion des bases de données dans la GUI et la CLI : vue « Bases » de `make inventaire-ui` présentant les serveurs de BD, les bases applicatives et leurs **chaînes de connexion** (mot de passe masqué), avec gestion complète (ajout / édition / retrait) et endpoint `POST /api/bases` (validé, jeton). CLI `scripts/bases_donnees.py` (`lister` / `verifier` / `ajouter-serveur` / `ajouter-base` / `retirer-*`) + cibles `make bases` et `make bases-verifier`. Le registre est désormais validé dans `make inventaire-verifier`. GUI et CLI partagent les mêmes règles (`inventory_rules`).
|
||
- Rôle `serveurs_forgejo` (forge Git, Phase 5) : binaire officiel Forgejo (version épinglée + lien symbolique), utilisateur `git`, **base PostgreSQL via le registre** (4e consommateur, entrée `forgejo`), publication derrière `serveurs_nginx` (`HTTP_ADDR=127.0.0.1`, `INSTALL_LOCK`), secrets (BD + `SECRET_KEY` + `INTERNAL_TOKEN` + admin) via Vault, mailer vers `serveurs_sendmail`, compte administrateur initial créé une fois. Détails d'installation tirés de la doc officielle Forgejo. Activation de l'entrée `forgejo` dans `docs/bases-donnees.yml`. Playbook de groupe et `group_vars` production associés.
|
||
- Rôle `serveurs_icinga` (supervision active — cœur, Phase 4) : dépôt apt officiel Icinga, `icinga2` + `icingadb` + `icingadb-redis`, `icinga2 api setup` + activation de la fonctionnalité `icingadb`, **base PostgreSQL via le registre** (entrée `icingadb`, import du schéma, mot de passe partagé via Vault), config Icinga DB (BD + Redis). **Icinga Web 2 différé** à une phase dédiée. Détails de configuration Icinga DB paramétrés et signalés comme non vérifiables verbatim (pages doc partiellement indisponibles). Ajout de l'entrée `icingadb` à `docs/bases-donnees.yml`. Playbook de groupe et `group_vars` production associés.
|
||
- Rôle `serveurs_redis` (cache / files, paquet Debian) : surcharge **non destructive** de `redis.conf` via `include`, `requirepass` (Vault, car exposé sur le réseau interne), `maxmemory` + politique `allkeys-lru`, écoute localhost + IP interne. Complète le nœud données (data-01) aux côtés de PostgreSQL. Playbook de groupe et `group_vars` production associés.
|
||
- Rôle `clients_smtp` (intégration cliente relais mail) : `msmtp` + `msmtp-mta` relaient le courrier sortant (notifications, cron, alertes) vers `serveurs_sendmail`, sans daemon. Dernière intégration cliente dont le serveur central existe. Playbook de groupe et `group_vars` production associés.
|
||
- Rôle `clients_ldap` (intégration cliente identité utilisateur) : **SSSD** (NSS + PAM) vers `serveurs_openldap`, activation de `sss` dans `/etc/nsswitch.conf` (passwd/group/shadow), création automatique des répertoires personnels (`mkhomedir`), bind anonyme par défaut (bind dédié possible via Vault). Authentification des utilisateurs centralisée — complète l'identité machine de `clients_pki`. Playbook de groupe et `group_vars` production associés.
|
||
- Rôle `clients_pki` (intégration cliente PKI / identité machine) : `step-cli` (dépôt Smallstep), **confiance** dans l'AC interne (`step ca bootstrap --install` → racine dans le magasin système), **certificat d'hôte** via le provisioner, **renouvellement automatique** (unités systemd officielles `cert-renewer@.{service,timer}`, vérification toutes les 15 min). Chaque hôte obtient une identité machine vérifiable et un TLS interne réel (remplace les certificats auto-signés). Secrets (empreinte racine + mot de passe provisioner, partagé avec `serveurs_step_ca`) via Vault. Détails tirés de la doc officielle Smallstep. Playbook de groupe et `group_vars` production associés.
|
||
- Rôle `clients_journaux` (intégration cliente journaux) : **Grafana Alloy** (dépôt apt Grafana) lit le journal système (journald) et le pousse vers `serveurs_loki` ; l'utilisateur `alloy` est ajouté au groupe `systemd-journal`. Complète l'observabilité côté client (métriques + journaux). Playbook de groupe associé.
|
||
- Rôle `clients_metriques` (intégration cliente métriques) : installe `prometheus-node-exporter` (paquet Debian) sur les VM du groupe ; `serveurs_prometheus` dérive et scrape automatiquement la cible depuis l'inventaire. Première intégration cliente — ferme la boucle d'observabilité côté métriques. Playbook de groupe associé.
|
||
- Rôle `serveurs_grafana` (tableaux de bord, dépôt apt officiel Grafana) : datasources Prometheus + Loki **provisionnées automatiquement** (`/etc/grafana/provisioning/datasources/`), domaine/`root_url` et mot de passe admin (Vault) via un **drop-in systemd non destructif** (ne touche pas `grafana.ini` du paquet), inscriptions publiques désactivées, publication derrière `serveurs_nginx`. Clôt la Phase 3 observabilité. Playbook de groupe et `group_vars` production associés.
|
||
- Rôle `serveurs_loki` (agrégation de journaux, dépôt apt officiel Grafana) : configuration single-node (stockage `filesystem`, schéma TSDB v13), rétention via compactor (`retention_enabled`), écoute `:3100`. Le dépôt apt Grafana est partagé avec `serveurs_grafana`. Playbook de groupe associé.
|
||
- Rôle `serveurs_prometheus` (collecte de métriques, paquet Debian) : début de la Phase 3 observabilité. Config Prometheus avec cibles `node_exporter` **dérivées de l'inventaire** (hôtes actifs de `clients_metriques` → `:9100`, comme la zone DNS), jobs additionnels libres, rétention configurable via `/etc/default/prometheus`, `promtool check config` avant rechargement (handler dans le rôle). Playbook de groupe associé.
|
||
- Rôle `serveurs_keycloak` (SSO/IAM, hub d'authentification centralisée) : distribution Quarkus (version en variable, URL release officielle), **premier consommateur de bout en bout du registre de BD** (`serveurs_postgresql` crée la base/compte `keycloak`, le rôle lit la même entrée pour son DSN — mot de passe partagé via `vault_bd_keycloak`), publication derrière `serveurs_nginx` (`proxy-headers=xforwarded`, `http-enabled=true`), secrets (BD + admin bootstrap) dans un `EnvironmentFile 0640`/`no_log`, `kc.sh build` puis service systemd `start --optimized`. Activation de l'entrée `keycloak` dans `docs/bases-donnees.yml`. Détails de configuration tirés de la doc officielle Keycloak. Playbook de groupe et `group_vars` production associés.
|
||
- Rôle `serveurs_openldap` (annuaire interne) : slapd Debian configuré via debconf (installation non interactive, backend MDB), base DN dérivée du domaine (`dc=chezlepro,dc=internal`), mot de passe admin **obligatoire depuis Vault**, unités organisationnelles de base (`people`, `groups`) via `community.general.ldap_entry`. Playbook de groupe et `group_vars` production associés.
|
||
- Registre déclaratif des bases de données applicatives `docs/bases-donnees.yml` (patron « 1 appli → 1 base → 1 compte propriétaire → 1 chaîne de connexion »). Consommé côté serveur par `serveurs_postgresql` (crée base + compte propriétaire, mot de passe depuis la variable Vault nommée par `secret`) et, côté appli, pour bâtir la chaîne de connexion — secret partagé, source unique. Évite un rôle par base. Vide par défaut.
|
||
- Rôle `serveurs_step_ca` (AC interne Smallstep step-ca + provisioner ACME) : dépôt apt officiel Smallstep (clé + source deb822), installation `step-ca`/`step-cli`, utilisateur système `step`, initialisation de l'AC **une seule fois** (`step ca init` standalone + ACME, garde-fou `creates: ca.json`), mots de passe CA et provisioner **obligatoires depuis Vault**, unité systemd durcie officielle. Playbook de groupe et `group_vars` production associés. Clôt la Phase 1 des fondations. Détails d'installation tirés de la documentation officielle Smallstep (non inventés).
|
||
- Rôle `serveurs_sendmail` (relais SMTP sortant, basé sur Postfix qui fournit l'interface `sendmail`-compatible) : installation non interactive (debconf), relais limité à `mynetworks` (`10.1.0.0/16`, pas de relais ouvert), smarthost amont optionnel, TLS opportuniste (snakeoil par défaut), `postfix check` avant reload. Playbook de groupe et `group_vars` production associés.
|
||
- Rôle `serveurs_nginx` (edge) : reverse proxy et terminaison TLS, certificat auto-signé (snakeoil) par défaut avec chemins en variables pour bascule vers l'AC interne/ACME, durcissement de base (`server_tokens off`, TLS 1.2/1.3), sites de reverse proxy pilotés par variables (vides par défaut), validation `nginx -t` avant reload (handler dans le rôle). Playbook de groupe `serveurs_nginx` et `group_vars` production associés.
|
||
- Rôle `serveurs_postgresql` (premier service applicatif après PowerDNS) : PostgreSQL packagé Debian 13, écoute `127.0.0.1` + IP interne, `pg_hba` en `scram-sha-256` ouvert au réseau interne `10.1.0.0/16`, configuration via `conf.d`, provisionnement optionnel de comptes/bases par variables (mots de passe via Vault), handlers reload/restart dans le rôle. Playbook de groupe `serveurs_postgresql` et `group_vars` production associés. Ajout de `requirements.yml` (collections `community.postgresql`, `community.general`).
|
||
- Vue des liens VM → groupes → playbooks → rôles dans `make inventaire-ui` : onglet « Chaîne » par hôte (panneau détail) et vue arbre globale (bascule « Inventaire / Chaîne » en en-tête). Les rôles sont extraits des `playbooks/groupes/*.yml` et exposés dans l'API ; les groupes sans rôle sont signalés « stub ».
|
||
- Champ de mot de passe du vault Ansible dans la modale de déploiement de `make inventaire-ui` : transmis via fichier temporaire `0600` + `ANSIBLE_VAULT_PASSWORD_FILE`, supprimé après exécution, jamais journalisé. Évite tout prompt `--ask-vault-pass` bloquant en exécution non-interactive. Le flux vault de `make cloner-vm` / `creer-vm` n'est pas modifié.
|
||
- Catégorie « Modèles / essais » (VLAN 99 → `10.1.99.0/24`) dans `docs/nomenclature.yml`.
|
||
- Registre de nomenclature machine-lisible `docs/nomenclature.yml` (source unique) : domaines, catégories, plan d'adressage `10.1.0.0/16` segmenté par fonction (un /24 et un VLAN par catégorie), dérivations hostname / VMID / VLAN / IP / passerelle.
|
||
- Auto-proposition dans `make inventaire-ui` : bouton « ✨ Proposer » et auto-remplissage à la saisie du nom, qui dérivent VMID, VLAN, IP et passerelle depuis `docs/nomenclature.yml` (avec indice de zone). Migration du plan d'adressage interne vers `10.1.0.0/16` (remplace les essais `192.168.12.x`).
|
||
- Adoption du nom officiel « Set-OPS — Votre artisan numérique » : titre et en-tête de `make inventaire-ui`, et titre du `README.md`.
|
||
- Déploiement depuis `make inventaire-ui` : boutons « Vérifier » (dry-run `--check --diff`) et « Déployer » (réel) par hôte, avec console de sortie en direct. Garde-fous : jeton anti-CSRF (`X-Jeton`), verrou (une seule exécution à la fois), validation du nom d'hôte (anti-injection), refus si l'hôte n'est pas actif, déploiement bloqué tant qu'une vérification n'a pas réussi (réarmé à chaque sauvegarde), restriction à l'inventaire production. Déploiement non transactionnel (sans rollback) signalé à l'opérateur.
|
||
- Cible `make verifier-deploiement HOTE=…` : déploiement à blanc (`--check --diff`) d'un hôte selon ses groupes, réutilisée par l'interface.
|
||
- Refonte de l'interface `make inventaire-ui` : thème sombre dense, grille de cartes d'hôtes groupées par état (Actifs / Planifiés) avec badge de statut coloré, chips de filtre (Tous / Actifs / Planifiés / Bloqués), recherche, et panneau détail maître-détail à onglets (Réseau / Proxmox / Groupes) avec tuiles de chiffres-clés (VMID, mémoire, cœurs, disque, groupes), bascule d'état actif/planifié, panneau de dépendances repliable, raccourci Ctrl/Cmd+S.
|
||
- Saisie des paramètres de provisioning par hôte dans l'inventaire (variables d'hôte) : `proxmox_cidr`, `proxmox_passerelle`, `proxmox_vlan`, `proxmox_pont`, `proxmox_dns`, `proxmox_noeud`, `proxmox_stockage`, `proxmox_disque_taille`, `proxmox_memoire`, `proxmox_coeurs`, avec validation (VLAN 1-4094, CIDR 0-32, entiers positifs) et round-trip non destructif. Documentées dans `docs/nomenclature-vm.md`.
|
||
- Scission de la couche applicative web en deux groupes distincts de l'edge `serveurs_nginx` :
|
||
- `serveurs_web_frontaux` (présentation web : UI, rendu, assets) ;
|
||
- `serveurs_web_dorsaux` (application web : API, traitement) ;
|
||
- playbooks homonymes et entrée dédiée dans `docs/catalogue-services.md`.
|
||
- Ajout de `make hote-planifier` pour renseigner un hôte, son VMID et ses groupes sans création ni déploiement immédiat.
|
||
- Ajout de `scripts/inventory_rules.py` pour centraliser les règles partagées entre la gestion CLI et l'interface locale d'inventaire.
|
||
- Ajout de `docs/dependances-groupes.yml` comme registre exploitable des dépendances causales entre groupes.
|
||
- Ajout du contrat `serveurs_powerdns` afin de représenter la capacité DNS centrale requise par `clients_dns`.
|
||
- Ajout du premier jalon DNS interne :
|
||
- rôle `serveurs_powerdns` avec PowerDNS Authoritative et backend BIND ;
|
||
- génération de la zone interne depuis l'inventaire actif ;
|
||
- rôle `clients_dns` avec validation de zone et modification resolver protégée ;
|
||
- variables de production DNS et runbook `docs/dns-interne.md`.
|
||
|
||
### Modifié
|
||
- Bindings appli↔BD explicites et **plusieurs bases par application** : chaque base porte un `consommateur` (le groupe applicatif qui l'utilise) et un `usage` (principale/cache…). La GUI (vue « Bases » : menu déroulant **Consommateur** + champ **Usage**) et la CLI (`ajouter-base --consommateur --usage`) gèrent le lien ; la vue **Chaîne devient détaillée** (chaque groupe affiche ses rôles ET ses bases avec leur chaîne de connexion). Rôles `serveurs_keycloak`/`serveurs_forgejo`/`serveurs_icinga` migrés pour résoudre leur base par consommateur (plus de clé codée en dur).
|
||
- Registre `docs/bases-donnees.yml` passé à un **modèle multi-serveurs** : section `serveurs_bd` (serveurs de BD nommés — `type`/`hôte`/`port`/`groupe`) que chaque base référence. La **chaîne de connexion dérivée** devient le lien appli↔BD ; l'hôte n'est plus codé en dur. Rôles `serveurs_postgresql` (filtre par serveur nommé relié à son groupe) et `serveurs_keycloak`/`serveurs_forgejo`/`serveurs_icinga` (hôte/port lus depuis le registre) migrés.
|
||
- Robustesse du serveur `make inventaire-ui` : `repondre()` avale proprement les connexions fermées par le client (`BrokenPipeError`/`ConnectionResetError`) au lieu de déverser une trace dans la console ; ajout d'un favicon (204) pour éviter le 404 répété du navigateur.
|
||
- `make deployer` et `make verifier-deploiement` détectent un `group_vars` de production chiffré (Ansible Vault) et demandent le mot de passe **une seule fois** (réutilisé pour tous les playbooks et sous-vérifications via fichier temporaire `0600`, nettoyé en fin de run). Refus propre si vault chiffré détecté en exécution **non-interactive** ; la GUI ferme `stdin` du sous-processus et fournit le mot de passe via la modale, donc elle ne bloque jamais. Ferme l'asymétrie de gestion des secrets entre terminal et GUI.
|
||
- Migration complète de l'adressage interne vers `10.1.0.0/16` : golden template `basiqueChezlepro` → `10.1.99.99`, et tous les exemples `192.168.x` (README, Makefile, runbooks Proxmox et template) réécrits vers le schéma `10.1.x` / `web-frontal-01`.
|
||
- Remplacement du groupe `serveurs_web` par `serveurs_web_frontaux` et `serveurs_web_dorsaux` dans les inventaires lab et production, mises à jour des exemples `README.md` et `AGENTS.md`.
|
||
- Retrait des hôtes de test `web-01` et `web-02` de l'inventaire production.
|
||
- Planification de la couche applicative web : `web-frontal-01` (95301), `web-frontal-02` (95302) dans `serveurs_web_frontaux` et `web-dorsal-01` (95401) dans `serveurs_web_dorsaux`, tous en `hotes_planifies` avec socle et durcissement.
|
||
- Mise à jour de `docs/nomenclature-vm.md` : domaines `web-frontal` / `web-dorsal`, retrait des noms de test `web-01`/`web-02`.
|
||
- Renforcement de la validation d'inventaire :
|
||
- un hôte doit être soit planifié, soit actif, mais pas les deux ;
|
||
- un hôte actif doit avoir `ansible_host` ;
|
||
- un hôte doit porter au moins un groupe opérationnel ;
|
||
- les VMID dupliqués sont refusés.
|
||
- Conservation du VMID dans l'inventaire lors de `make creer-vm` et `make hote-ajouter`.
|
||
- Alignement de l'aide Makefile et de la documentation sur le flux opérateur : planifier, activer/créer, déployer.
|
||
- Retrait des groupes génériques obsolètes `serveurs_bases_donnees` et `serveurs_supervision` au profit des groupes de services précis.
|
||
- Consolidation des groupes Icinga en `serveurs_icinga` afin de représenter une seule capacité de supervision serveur sur `mon-01`.
|
||
- Validation des prérequis actifs avant déploiement d'un groupe, déploiement d'un hôte ou sauvegarde active via l'interface d'inventaire.
|
||
- Refonte visuelle de `make inventaire-ui` pour afficher les dépendances causales, les prérequis manquants et l'état déployable ou bloqué des hôtes.
|
||
|
||
## 2026-06-21
|
||
|
||
### Ajouté
|
||
- Ajout de facilités `make` pour exploiter Ansible sur les VM Debian déployées :
|
||
- diagnostic `ping`, `sudo` et `faits` ;
|
||
- variables `LIMITE`, `VERIFICATION`, `DIFF`, `ETIQUETTES`, `SAUTER_ETIQUETTES` et `VARIABLES`.
|
||
- Ajout de facilités `make` pour inspecter et valider les inventaires Ansible :
|
||
- `hote-ajouter` ;
|
||
- `hote-groupes` ;
|
||
- `hote-afficher` ;
|
||
- `inventaire-verifier` ;
|
||
- `inventaire-lister` ;
|
||
- `inventaire-graphe` ;
|
||
- `inventaire-hote` ;
|
||
- `inventaire-lab` ;
|
||
- `inventaire-production`.
|
||
- Ajout de `deployer` et `deployer-groupe` comme commandes opérateur simplifiées pour appliquer les playbooks de groupes.
|
||
- Ajout de `scripts/inventory_host.py` pour gérer les entrées d'inventaire et leur appartenance aux groupes sans édition YAML manuelle.
|
||
- Ajout de la convention `1 groupe opérationnel = 1 playbook homonyme` avec les premiers playbooks :
|
||
- `playbooks/groupes/serveurs_debian.yml` ;
|
||
- `playbooks/groupes/serveurs_durcis.yml`.
|
||
- Ajout du playbook `playbooks/maintenance/verifier_hote_debian.yml` pour valider une VM Debian 13 gérée par Set-OPS après socle et durcissement.
|
||
- Ajout de directives `AGENTS.md` pour formaliser le `Makefile` comme interface opérateur, la convention groupe/playbook, la francisation de la surface opérateur et les points de stabilisation avant commit.
|
||
- Ajout du playbook `playbooks/proxmox/cloner_vm_debian.yml` et des cibles `make cloner-vm` / `make creer-vm` pour créer des clones Debian via l'API Proxmox sans stocker de secret dans le dépôt.
|
||
- Ajout de `inventories/lab/group_vars/proxmox.yml` pour les paramètres Proxmox non sensibles et de `proxmox.vault.yml.example` pour préparer les secrets API avec Ansible Vault.
|
||
- Ajout de `make config` pour renseigner les paramètres Proxmox et créer ou éditer le Vault API depuis le terminal.
|
||
|
||
### Modifié
|
||
- Francisation de la surface opérateur :
|
||
- variables `make` ;
|
||
- cibles `make` ;
|
||
- groupes d'inventaire ;
|
||
- chemins des playbooks maison ;
|
||
- libellés du script de gestion d'inventaire.
|
||
- Documentation du flux de déploiement d'une VM clonée depuis le modèle doré avec les commandes `make`.
|
||
- Optimisation de la procédure de bootstrap du modèle Debian 13 pour utiliser Cloud-Init comme source unique de l'identité initiale au lieu de maintenir une création manuelle parallèle du compte et de la clé SSH.
|
||
- Simplification de `make cloner-vm` et `make creer-vm` pour que les paramètres Proxmox communs viennent des variables Ansible plutôt que de la ligne de commande ou de l'environnement.
|
||
- Ajustement de `make config` pour ne plus redemander les valeurs Cloud-Init déjà portées par le modèle Proxmox.
|
||
- Déplacement du VLAN hors de `make config` afin de l'exiger explicitement à chaque création de VM avec `VLAN=...`.
|
||
- Retrait des options `DEMANDER_MDP` et `DEMANDER_SUDO` du `Makefile`; le flux suppose SSH par clé et sudo NOPASSWD déjà fonctionnels.
|
||
- Retrait des playbooks de couches redondants `playbooks/socle/debian_commun.yml` et `playbooks/durcissement/debian_serveur_durcissement.yml`; la conformité des VM déployées passe maintenant par `playbooks/groupes/`.
|
||
- Bonification de `AGENTS.md` pour désigner `playbooks/groupes/` comme source officielle de conformité et éviter les cibles `make` de couches parallèles.
|
||
- Simplification de l'aide du `Makefile` pour exposer d'abord les gestes opérateur : inventaire, groupes, déploiement.
|
||
- Clarification de `make aide` pour expliquer les différences entre `creer-vm`, `cloner-vm`, `deployer`, `deployer-groupe` et `appliquer`.
|
||
- Réorganisation de `make aide` par objets d'exploitation : VM, hôtes, groupes, inventaires, modèle et validation.
|
||
- Retrait des commandes opérateur explicites de ping et sudo; ces vérifications sont maintenant implicites dans `deployer` et `preparer-modele`.
|
||
- Ajout d'une demande automatique de mot de passe Ansible Vault pour `make cloner-vm` et `make creer-vm` lorsqu'un `proxmox.vault.yml` chiffré est présent.
|
||
- Amélioration du message d'erreur lorsque `proxmox.vault.yml` ne peut pas être chargé.
|
||
- Ajustement du playbook Proxmox pour laisser apparaître les erreurs API utiles sans masquer entièrement les échecs de clonage.
|
||
- Modification de `make deployer HOTE=...` pour appliquer les playbooks correspondant aux groupes de l'hôte.
|
||
- Ajout d'une vérification explicite de la bibliothèque Python `proxmoxer` avant les appels API Proxmox.
|
||
- Retrait de la taille disque clone des paramètres Proxmox persistés afin de ne pas tenter de réduire un disque hérité du modèle.
|
||
- Ajout de la validation inventaire/playbooks pour empêcher un groupe opérationnel avec hôtes sans playbook homonyme.
|
||
- Ajout du playbook de groupe `serveurs_web` comme point d'ancrage explicite avant l'ajout d'un rôle web.
|
||
- Ajout d'un catalogue de services pour préparer Keycloak, OpenLDAP, PostgreSQL, Loki, Icinga, Prometheus, Grafana, Forgejo, Sendmail, step-ca, Redis, NGINX, Nextcloud et Collabora.
|
||
- Ajout des groupes et playbooks homonymes neutres pour les prochains services centraux et intégrations clientes.
|
||
- Documentation de l'ordre d'implémentation recommandé des services selon leurs dépendances et intégrations.
|
||
- Ajout d'une nomenclature VM/VMID et distinction entre hôtes planifiés et hôtes actifs dans l'inventaire.
|
||
- Ajout d'une interface web locale `make inventaire-ui` pour éditer et sauvegarder l'inventaire sans lancer de déploiement.
|
||
- Ajustement de la nomenclature planifiée vers des noms d'hôtes par domaine afin de permettre la cohabitation de plusieurs services sur une même VM.
|
||
|
||
## 2026-06-19
|
||
|
||
### Ajouté
|
||
- Structure initiale globale du dépôt Set-OPS.
|
||
- Playbooks de création du template Debian 13 Proxmox.
|
||
- Rôles de base Debian.
|
||
- Rôles de durcissement template-safe.
|
||
- Playbook de vérification.
|
||
- Playbook de nettoyage final avant conversion en template.
|
||
|
||
## 2026-06-20
|
||
|
||
### Contexte
|
||
- Clarification : `Set-OPS` est le dépôt global d’exploitation Ansible de Chezlepro Inc.
|
||
- Clarification : le template Debian 13 Proxmox est un sous-ensemble du dépôt, pas sa finalité unique.
|
||
- Clarification : les services applicatifs spécialisés doivent être installés sur les clones par des playbooks dédiés, pas directement dans le template.
|
||
|
||
### Ajouté
|
||
- Ajout des directives renforcées dans `AGENTS.md` :
|
||
- validation Ansible obligatoire ;
|
||
- vérification des handlers Ansible ;
|
||
- interdiction de déclarer un playbook prêt si `--syntax-check` échoue ;
|
||
- préférence pour les correctifs ciblés au lieu des régénérations massives ;
|
||
- rappel que `Set-OPS` ne doit pas être restructuré autour d’un seul besoin ponctuel.
|
||
- Ajout d’une logique de 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`.
|
||
- Ajout d’une couche de durcissement template-safe :
|
||
- AppArmor ;
|
||
- auditd ;
|
||
- fail2ban SSH ;
|
||
- unattended-upgrades ;
|
||
- journald ;
|
||
- sysctl de sécurité ;
|
||
- nftables installé et préparé, mais désactivé par défaut dans le template.
|
||
- Ajout d’un document d’architecture pour les intégrations futures des VM :
|
||
- supervision ;
|
||
- métriques ;
|
||
- identité ;
|
||
- PKI interne ;
|
||
- DNS interne.
|
||
- Documentation détaillée des ajouts appliqués au modèle doré Debian 13 Proxmox depuis une installation minimale.
|
||
- Ajout d'un runbook explicite pour le playbook de préparation du modèle doré Debian 13 Proxmox.
|
||
- Ajout d'un runbook manuel précis pour le bootstrap initial de la VM vanille Debian 13 :
|
||
- correction des sources APT après installation depuis DVD ;
|
||
- installation minimale de `sudo`, SSH, `cloud-init`, `cloud-guest-utils` et `qemu-guest-agent` ;
|
||
- utilisation de Cloud-Init pour injecter le compte `ansible`, sa clé SSH, le réseau et le point de bascule vers le `Makefile`.
|
||
- Ajout d'un document de cycle de vie des VM Chezlepro :
|
||
- VM vanille ;
|
||
- goldenisation ;
|
||
- clonage ;
|
||
- socle ;
|
||
- durcissement ;
|
||
- conformité continue.
|
||
- Ajout de directives `AGENTS.md` pour la convergence des VM existantes et futures :
|
||
- cycle de vie des VM ;
|
||
- distinction service central et intégration cliente ;
|
||
- groupes d'inventaire par intégration ;
|
||
- séparation des variables de template, conformité et services.
|
||
- Ajout d'un `Makefile` comme interface d'exploitation courante :
|
||
- validation ;
|
||
- syntax-checks ;
|
||
- préparation, vérification et nettoyage protégé du template ;
|
||
- socle et durcissement des VM Debian.
|
||
- Durcissement SSH du template dès la construction :
|
||
- accès par clé publique obligatoire ;
|
||
- authentification par mot de passe désactivée ;
|
||
- forwarding et tunnels SSH désactivés par défaut ;
|
||
- limites de tentatives, sessions et démarrages SSH resserrées.
|
||
|
||
### Modifié
|
||
- Renforcement attendu de `CLAUDE.md` pour rappeler que `AGENTS.md` est la source d’autorité principale.
|
||
- Clarification du comportement attendu de Claude Code :
|
||
- lire l’existant avant modification ;
|
||
- vérifier `git status --short` ;
|
||
- ne pas faire de régénération massive sans demande explicite ;
|
||
- valider les playbooks touchés ;
|
||
- signaler les tests non exécutés ;
|
||
- mettre à jour `CHANGELOG.md` si pertinent.
|
||
- Migration des variables de rôles vers des préfixes propres à chaque rôle pour respecter `ansible-lint`.
|
||
- Mise à jour de la variable de confirmation du nettoyage final :
|
||
- `template_cleanup_confirm`.
|
||
- Correction de la structure du `CHANGELOG.md` pour retirer le titre dupliqué.
|
||
- Simplification ciblée de l'arborescence `roles/` :
|
||
- retrait des doublons non utilisés sous `roles/base/` ;
|
||
- retrait des doublons non utilisés sous `roles/security/` ;
|
||
- retrait des doublons non utilisés sous `roles/vm_template/`.
|
||
- Ajout d'un renvoi depuis la procédure manuelle vers la justification du golden template.
|
||
- Séparation documentaire et opérationnelle entre variables de template et variables de conformité.
|
||
- Extension du playbook de groupe `playbooks/groupes/serveurs_debian.yml` pour maintenir le socle commun des VM Debian déployées.
|
||
- Mise à jour de la documentation pour exiger un `ciuser` cloud-init avec clé publique avant l'exécution d'Ansible.
|
||
- Déplacement des listes de paquets communes dans les defaults des rôles `common_packages` et `hardening_packages`.
|
||
- Déplacement des variables de construction du template dans `inventories/lab/group_vars/modeles_vm.yml`.
|
||
- Déplacement des variables de conformité Debian dans `inventories/production/group_vars/serveurs_debian.yml`.
|
||
- Ciblage du playbook de durcissement sur `serveurs_debian` au lieu de `all`.
|
||
- Renforcement du playbook de vérification du modèle doré.
|
||
|
||
### Corrigé
|
||
- Vérification des rôles contenant `notify`.
|
||
- Confirmation des handlers SSH requis dans les rôles concernés :
|
||
- `roles/ssh_baseline/handlers/main.yml` ;
|
||
- `roles/ssh_hardening/handlers/main.yml`.
|
||
|
||
### Validé
|
||
- Vérification que chaque `notify` du template Debian 13 Proxmox pointe vers un handler existant.
|
||
- Relance du playbook de préparation du template Debian 13 Proxmox.
|
||
- Nettoyage final non lancé.
|