Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity

0 releases 3 tags

RSS feed
  • v2026.10.07 e9215a2141

    Set-OPS v2026.10.07 — deux locataires détruits et reconstruits, leurs données vérifiées intactes

    danallaire released this 2026-10-07 18:21:17 -04:00 | 4 commits to main since this release

    No known key found for this signature in database

    Code prouvé : commit 2cbfa2d. Les commits qui suivent ne modifient que le
    CHANGELOG.

    CE QUI A ÉTÉ FAIT LE 2026-10-07

    Les 13 machines virtuelles de chacun des deux locataires, OPS-Technolibre
    puis OPS-Chezlepro, ont été détruites, puis recréées et redéployées de zéro
    par une seule commande : make reconstruire-locataire. Chaque
    reconstruction a pris 43 minutes, sans arrêt ni échec :

    • les 13 machines recréées ;
    • la recette de validation passée (make valider) ;
    • le pare-feu Proxmox réactivé sur les 13 machines ;
    • aucune alerte critique dans Icinga.

    Les données de chaque locataire ont été sauvegardées juste avant la
    destruction, puis remises en place pendant la reconstruction : l'autorité
    de certification, l'annuaire LDAP, les bases PostgreSQL, Nextcloud, le
    courriel, la clé DKIM, l'application web et, nouveauté, l'autorité de
    certification d'Icinga. Une comparaison automatique entre l'état d'avant
    et l'état d'après n'a trouvé aucune perte et aucune identité changée.

    CE QUI CHANGE DEPUIS v2026.10.04

    1. Le site reconstruit un locataire sans avoir besoin de son dépôt complet.
      Chaque locataire publie un fichier (face-reseau.yml) qui décrit ce
      que le site doit savoir de lui : ses machines, leurs adresses, leurs
      flux, leurs paramètres de clonage. Le site s'en sert pour configurer
      la frontière OPNsense et le pare-feu Proxmox, et pour créer, détruire
      et ranger les machines du locataire. Les commandes du site désignent le
      locataire par son nom (make locataire-creer TENANT=OPS-Technolibre).

    2. La sauvegarde prise juste avant la destruction n'est plus effacée.
      Elle est étiquetée « avant-raser » et gardée jusqu'à la reconstruction
      suivante. Avant, la première sauvegarde automatique de la flotte
      reconstruite la remplaçait le jour même, et il ne restait rien pour
      vérifier ce qui avait été remis.

    3. Une vérification automatique compare l'état remis à cet état d'avant
      (make temoins-etat, lancée aussi à la fin de chaque reconstruction).
      Elle signale toute perte (fichier, courriel, entrée de l'annuaire,
      base, table, ligne d'historique) et tout changement d'identité (clés
      des autorités de certification, clé DKIM, identifiant de Nextcloud,
      mot de passe d'un utilisateur). S'il y en a, la reconstruction se
      termine en échec et affiche le détail.

    4. L'historique de supervision d'Icinga survit à la reconstruction.
      Il était volontairement jeté depuis le 2026-09-30 : Icinga recréait son
      autorité de certification à chaque reconstruction, ce qui rendait
      l'ancien historique inutilisable. Cette autorité est maintenant
      sauvegardée et remise ; l'historique (incidents, disponibilité) est
      conservé et reste rattaché aux machines.

    5. Le contrôle de placement vérifie le bon modèle de VM. Il vérifiait un
      modèle déclaré par le locataire, alors que le clonage utilise celui que
      fournit le site.

    LIMITES CONNUES

    • Le site lui-même n'a jamais été reconstruit de zéro.
    • Keycloak perd ses sessions hors ligne à chaque reconstruction : les
      applications qui s'en servent doivent se reconnecter.
    • Les métriques (Prometheus) et les journaux (Loki) ne sont pas
      sauvegardés : ils repartent de zéro à chaque reconstruction.
    • L'historique Icinga de Chezlepro antérieur au 2026-10-07 à 14 h 34 est
      perdu (reconstruction faite avant la correction du point 4).
    • make ci, qui vérifie le modèle public, n'a pas été relancé depuis
      v2026.10.04.
    Downloads