Il y a 389 articles et 19 utilisateurs inscrits (ce bandeau est défini dans MediaWiki:Sitenotice)

« Déploiement technique d’une VM AJLSM » : différence entre les versions

De AJLSM
Aller à la navigation Aller à la recherche
← Modification précédenteModification suivante →

Jlarvers (discussion | contributions)

3 groupes d'utilisateurs
2 791 modifications
annuler
VisuelWikicode
Aucun résumé des modifications
Ligne 1 : Ligne 1 :
= AJLSM-DEPLOY — Déploiement automatisé des VM Proxmox =
= AJLSM-DEPLOY — Version 1.0.2 =


Document consolidé au 16 octobre 2026. Cette procédure réunit la page du 15 octobre et la recette actuelle. Elle remplace leurs indications opérationnelles divergentes. L’original du 15 octobre reste archivé séparément.
Mise à jour : 19 octobre 2026. Ce guide décrit les scripts du dossier
'''ajlsm-deploy-v1.0.2''', à installer dans '''/opt/ajlsm-deploy/v1'''.
Ce chemin est le répertoire définitif de lancement sur le nœud Proxmox ;
les anciennes copies de /usr/local/sbin ne sont pas remplacées implicitement.
Les lots NFS, Apache et Matomo précédents sont historiques. Garder scripts,
modules et modèles du même lot. Rotation des logs et update.sh hors périmètre.


Référence technique : scripts reçus de Saturne3, puis lot de recette avec lanceur du cycle et assistant YAML.
== Périmètre et architecture ==


== 1. Périmètre et résultat de la recette ==
Les scripts tournent sur le nœud Proxmox. Ils configurent le clone depuis un
projet YAML strict, utilisent QEMU Guest Agent pour les opérations invitées,
et SSH pour certaines vérifications/postconfigurations. Le moteur principal
orchestre les phases ; les modules spécialisés traitent racine, postconfiguration,
NFS, Apache, SQL Matomo, activation Matomo et inventaire des tâches planifiées.
Les helpers communs valident le YAML et affichent les commandes suivantes.


Le cycle technique a été exécuté sur MERCURE3 sans erreur signalée. Les vérifications finales transmises confirment :
'''Ce n'est pas un gestionnaire complet de l'infrastructure externe.''' DNS,
* connexion SSH avec le compte ajlsm ;
OPNsense, Ansible, autorisation Eole3 et certificats publics ont leurs procédures.
* élévation sudo avec le mot de passe défini pendant le cycle ;
Le script ne détruit pas la VM existante et ne modifie pas TEMPLATE3.
* hostname mercure3.ajlsm.com ;
* volume racine ext4 de 97 Gio, dont 85 Gio disponibles lors du contrôle.


Le cycle couvre le clonage, les ressources, l’initialisation du clone, l’extension de la racine, l’identité système, le réseau, SSH, le mot de passe et le certificat TLS interne.
== Répertoire définitif et exemple MERCURE3 ==


NFS, les configurations applicatives Apache2, Pleade, Drupal et Matomo ne font pas encore partie de ce cycle. Certains logiciels peuvent déjà être présents dans le modèle : leur présence ne constitue pas une configuration applicative du projet.
Les cinq programmes affichent la version 1.0.2 avec --version.
Leur --help rappelle le même répertoire et le même exemple que cette page.
Ces valeurs sont centralisées dans ajlsm_deploy_version.py.
Les suggestions visent les programmes du dossier réellement exécuté :
utiliser le lot installé ci-dessous, pas un ancien dossier de recette.


== 2. Où exécuter les commandes ==
Sur Saturne3, après installation du lot complet selon INSTALLATION-V1.txt :
 
<syntaxhighlight lang="bash">
{| class="wikitable"
cd /opt/ajlsm-deploy/v1
! Machine !! Rôle !! Exemple d’invite
|-
| Mac de l’administrateur || Transfert des archives par scp || Invite locale du Mac
|-
| Saturne3 || Préparation YAML, scripts Proxmox et cycle || root@Saturne3
|-
| MERCURE3 || Vérifications dans la VM || ajlsm@mercure3 ou root@mercure3
|}
 
Les scripts de déploiement sont exécutés sur Saturne3, pas dans MERCURE3.
Après « ssh ajlsm@10.0.0.43 », attendre l’invite de la VM avant de saisir les commandes suivantes.
Pour revenir de root@mercure3 à Saturne3 : un exit quitte sudo, puis un second exit ferme SSH.
 
== 3. Organisation des fichiers ==
 
<syntaxhighlight lang="text">
/root/ajlsm-deploy/
  archives/                        Archives reçues, conservées comme références
  recettes/20261016/
    ajlsm-deploy-cycle/            Lot technique validé et assistant ajouté
    ajlsm-deploy-assistant/        Distribution de l’assistant et tests
    ajlsm-deploy-documentation/    Présent guide et modèles YAML
 
/etc/ajlsm/deploy/projets/mercure3.yaml  Configuration actuellement utilisée
/usr/local/sbin/                       Scripts installés antérieurement
</syntaxhighlight>
</syntaxhighlight>


Le lot de recette contient ajlsm-deploy, ajlsm-deploy-check, ajlsm-deploy-resources, ajlsm-deploy-cycle et les modules ajlsm_deploy_common.py, ajlsm_deploy_rootgrow.py et ajlsm_deploy_postconfig.py. L’assistant ajlsm-deploy-yaml a été ajouté à ce même dossier.
Toutes les commandes ./ de cette page se lancent depuis ce répertoire.
 
Depuis un autre répertoire du même nœud, utiliser le chemin absolu du
Conserver exécutables et modules ensemble. Utiliser les chemins ./ depuis le dossier de recette pour ne pas appeler une ancienne version de /usr/local/sbin.
programme sous /opt/ajlsm-deploy/v1 et celui du YAML.
Les anciennes archives « ajlsm-deploy-revise » et « correction-suggestions » ne sont pas la référence courante : elles précèdent les phases supplémentaires reçues dans l’archive serveur.
Les YAML opérationnels restent sous /etc/ajlsm/deploy/projets/,
 
les journaux sous /var/lib/ajlsm-deploy/cycles/. Les archives/recettes
Prérequis : Python 3.9 ou supérieur, PyYAML 6, outils Proxmox sur le nœud cible et prérequis du modèle AJLSM. Les phases invitées utilisent notamment l’agent QEMU, ajlsm-clone-init, Python, systemd et Netplan. L’extension actuelle cible ext4/LVM sur /dev/sda3, avec un seul PV et un seul LV.
sous /root/ajlsm-deploy ne sont plus le répertoire de lancement v1.
 
Ne pas mélanger les modules ou changer de lot pendant un cycle.
== 4. Les deux fichiers de préconfiguration ==
 
=== 4.1. projet-vierge.yaml ===
 
Ce modèle reprend toute la structure actuelle sans valeur opérationnelle préremplie. Chaque champ doit être renseigné. Seul proxmox.vmid peut rester null : il signifie alors attribution automatique.
 
Le modèle comporte deux interfaces dont les valeurs sont null. Adapter le nombre d’interfaces avant la saisie si nécessaire. Pour déterminer ce nombre par les questions de l’assistant, utiliser plutôt le mode --new.
 
Un modèle vierge est volontairement refusé par --check. Il ne doit jamais être passé directement au lanceur du cycle.
 
=== 4.2. mercure3-reference.yaml ===
 
Ce fichier conserve les valeurs du projet validé : modèle 506 sur Saturne3, nom MERCURE3, 8 vCPU, 24576 Mio de RAM maximale, 16384 Mio minimale, disque 100 Gio, extension racine activée et paramètres réseau du projet.
 
Il permet de reconstruire une nouvelle VM avec la même configuration technique si le modèle, le stockage, les bridges et les préparatifs externes sont toujours disponibles. Il ne sauvegarde ni les données de l’ancienne VM, ni ses UUID, machine-id, clés hôte SSH ou mots de passe. Ces identités sont traitées par le cycle et ne sont pas à recopier.
 
Avec vmid: null, le VMID de remplacement peut différer de celui de l’ancienne VM. Le VMID 505 observé pendant la recette n’est pas une réservation permanente.
 
'''Ne pas lancer cette référence tant que MERCURE3 existe encore.''' Le clonage refuse un nom déjà présent. Pour tester une deuxième VM en parallèle, définir un autre nom, hostname, des IP distinctes et préparer DNS/OPNsense/Ansible en conséquence.
 
=== 4.3. Valeurs acceptées ===
 
* projet.environnement et tags : interne, client, prod. Les tags sont une liste sans doublons ; [] est admis.
* CPU, mémoire et taille du disque : entiers strictement positifs ; mémoire minimale inférieure ou égale à la maximale.
* Booléens : utiliser true ou false sans guillemets.
* Interfaces Proxmox : net suivi de chiffres ; interfaces invitées : ens suivi de chiffres.
* Adresses d’interfaces : IPv4/CIDR. Loopback : IPv4/32. Passerelle et DNS : IPv4 sans préfixe.
* Passerelle : interface déclarée et adresse appartenant à son sous-réseau, distincte des adresses de la VM.
* Hostname : nom DNS en minuscules.
* Serveur, bridge et stockage : valeurs adaptées à l’infrastructure ; aucune liste fermée inventée.


Les clés inconnues ou répétées sont refusées. Ne pas ajouter de sections applicatives avant l’évolution coordonnée du schéma et des scripts. Ne pas utiliser [à renseigner] : les crochets créent une liste YAML.
'''exemples/mercure3-exemple.yaml''' est un exemple renseigné avec les IP
réelles de MERCURE3, pas une préconfiguration générique.
Les commandes MERCURE3 de ce guide sont des exemples à adapter au projet.
Le nom de la VM, ses DNS et ses fichiers YAML opérationnels existants ne sont
pas renommés. En particulier, conserver le chemin du YAML pour la reprise :
le journal est indexé par ce chemin absolu.
modeles/projet-vierge.yaml demeure le modèle générique sans valeurs.


== 5. Préparer et valider le YAML ==
== Prérequis impératif : OS de TEMPLATE3 à jour ==


Sur Saturne3, se placer dans le lot de recette :
Avant TOUT nouveau clonage, maintenir l’OS Ubuntu de TEMPLATE3 à jour.
La VM clonée hérite de cet état. Maintenance manuelle distincte : les scripts
de déploiement ne mettent pas le modèle à jour. Prévoir une sauvegarde
récupérable et une fenêtre sans conflit d’IP avec les clones existants.
Ne pas démarrer ni convertir à l’aveugle un modèle marqué template Proxmox.


Dans la console de TEMPLATE3, après vérification de son identité :
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
cd /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle
hostname -f
cat /etc/os-release
sudo apt update
sudo apt upgrade
apt list --upgradable
if [ -f /var/run/reboot-required ]; then
  cat /var/run/reboot-required
  cat /var/run/reboot-required.pkgs 2>/dev/null || true
fi
</syntaxhighlight>
</syntaxhighlight>


=== 5.1. Vérifier un fichier existant sans le modifier ===
Examiner toutes les erreurs, messages APT et paquets retenus/différés.
 
apt update seul ne met pas les paquets à jour. Pas de -y, full-upgrade,
do-release-upgrade ou update.sh automatique. Si un redémarrage est demandé :
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3.yaml --check
sudo reboot
</syntaxhighlight>
 
Le message de succès signifie que les valeurs et leur cohérence locale sont conformes. Il ne certifie pas la préparation des services externes.
 
Voici un exemple :
<syntaxhighlight lang="yaml">projet:
  code: mercure3
  nom: MERCURE3
  environnement: interne
 
proxmox:
  serveur: Saturne3
  template_vmid: 506
  vmid: null
  nom_vm: MERCURE3
 
  cpu:
    sockets: 1
    cores: 8
 
  memoire:
    maximale_mib: 24576
    minimale_mib: 16384
 
  disque_systeme:
    stockage: local-zfs
    taille_gib: 100
    etendre_volume_racine: true
 
  demarrage_auto: true
 
  tags:
    - interne
 
systeme:
  hostname: mercure3.ajlsm.com
 
reseau:
  interfaces:
    - nom: net0
      bridge: vmbr2
      systeme: ens18
      ipv4: 10.0.0.43/24
 
    - nom: net1
      bridge: vmbr1
      systeme: ens19
      ipv4: 192.168.123.27/24
 
  loopback:
    ipv4: 51.83.117.113/32
 
  passerelle:
    ipv4: 10.0.0.4
    interface: ens18
 
  dns:
    - 10.0.0.4
</syntaxhighlight>
</syntaxhighlight>


=== 5.2. Compléter le modèle vierge ===
Attendre le retour du modèle, puis dans sa console :
 
Après extraction du présent lot documentaire :
 
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
./ajlsm-deploy-yaml \
hostname -f
  /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-documentation/projet-vierge.yaml \
uname -r
  --output /root/ajlsm-deploy/recettes/20261016/nouveau-projet.yaml
systemctl --failed
</syntaxhighlight>
apt list --upgradable
 
test ! -f /var/run/reboot-required
Toutes les valeurs obligatoires seront demandées. Pour saisir de nouveau le projet MERCURE3, consulter mercure3-reference.yaml comme fiche de paramètres, sans lancer de déploiement.
<syntaxhighlight lang="yaml"># Préconfiguration AJLSM vierge : aucune valeur d’infrastructure préremplie.
# Compléter avec ajlsm-deploy-yaml ; ne pas déployer ce modèle tel quel.
# null = champ à renseigner, SAUF proxmox.vmid où null = attribution automatique.
# Les crochets [à renseigner] sont interdits : ils représenteraient une liste YAML.
# Deux interfaces sont proposées : adapter leur nombre avant la saisie.
projet:
  code: null  # Obligatoire : minuscules/chiffres, tiret et souligné ; ex. mercure3.
  nom: null  # Obligatoire : nom lisible du projet.
  environnement: null  # Liste fermée : interne, client, prod.
 
proxmox:
  serveur: null  # Obligatoire : nom du nœud Proxmox, ex. Saturne3.
  template_vmid: null  # Obligatoire : entier positif, VM modèle existante et arrêtée.
  vmid: null  # Automatique ; sinon entier positif différent de template_vmid.
  nom_vm: null  # Obligatoire : nom de VM, lettres/chiffres/point/tiret.
  cpu:
    sockets: null  # Obligatoire : entier positif.
    cores: null  # Obligatoire : entier positif ; vCPU = sockets × cores.
  memoire:
    maximale_mib: null  # Obligatoire : entier positif, en Mio.
    minimale_mib: null  # Obligatoire : entier positif, inférieur ou égal au maximum.
  disque_systeme:
    stockage: null  # Obligatoire : identifiant de stockage Proxmox existant.
    taille_gib: null  # Obligatoire : entier positif en Gio ; aucune réduction de disque.
    etendre_volume_racine: null  # Obligatoire : true ou false ; active la phase racine.
  demarrage_auto: null  # Obligatoire : true ou false ; appliqué à l’activation réseau.
  tags: null  # Obligatoire : liste ; interne/client/prod uniquement, sans doublons ; [] admis.
 
systeme:
  hostname: null  # Obligatoire : nom DNS en minuscules ; vérifier sa déclaration en amont.
 
reseau:
  interfaces:
    - nom: null  # Obligatoire : net suivi de chiffres, conforme à la VM modèle.
      bridge: null  # Obligatoire : bridge existant, au plus 15 caractères.
      systeme: null  # Obligatoire : ens suivi de chiffres, conforme au modèle actuel.
      ipv4: null  # Obligatoire : IPv4/CIDR, ex. 10.0.0.43/24 ; adresse unique.
    - nom: null
      bridge: null
      systeme: null
      ipv4: null
  loopback:
    ipv4: null  # Obligatoire : IPv4 avec préfixe /32, distincte des interfaces.
  passerelle:
    ipv4: null  # Obligatoire : IPv4 seule, dans le sous-réseau de son interface.
    interface: null  # Obligatoire : un des noms systeme déclarés ci-dessus.
  dns: null  # Obligatoire : liste non vide d’IPv4 sans préfixe, ex. [10.0.0.4].
</syntaxhighlight>
</syntaxhighlight>


=== 5.3. Créer sans modèle ===
Examiner les résultats, noter date/OS/noyau dans le registre de maintenance.
 
Après validation, arrêter proprement TEMPLATE3 :
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
./ajlsm-deploy-yaml /root/ajlsm-deploy/recettes/20261016/nouveau-projet.yaml --new
sudo shutdown -h now
</syntaxhighlight>
</syntaxhighlight>


Cette commande est une alternative à la précédente : le chemin doit être inexistant. L’assistant pose les questions, y compris le nombre d’interfaces, sans reprendre implicitement les valeurs de MERCURE3.
Puis sur Saturne3 :
 
=== 5.4. Revoir un projet renseigné ===
 
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3.yaml --review \
qm status 506
  --output /root/ajlsm-deploy/recettes/20261016/mercure3-relecture.yaml
</syntaxhighlight>
</syntaxhighlight>


* Entrée conserve une valeur existante valide.
506 correspond au template_vmid de cette recette : vérifier la valeur du YAML.
* ANNULER, Ctrl-C ou fin d’entrée abandonnent sans enregistrer.
Le modèle doit être arrêté avant le clonage. Ni le lanceur ni les précontrôles
* Tags et DNS sont saisis séparés par des virgules ; [] ou aucun signifie tags vides.
ne certifient automatiquement sa fraîcheur APT. Cette maintenance n’a pas
* Saisir auto ou null pour un VMID automatique.
été réalisée par les scripts livrés. Saturne3 et HAProxy ont leur maintenance
* Après une incohérence, donner le chemin du champ à corriger ; ? affiche les chemins.
distincte, non demandée ici.
* Le résumé complet est présenté avant confirmation OUI/NON d’enregistrement.
Voir PREREQUIS-OS-ET-PUBLICATION.txt et les documentations Ubuntu :
[https://ubuntu.com/server/docs/how-to/software/package-management/ Gestion des paquets]
et [https://ubuntu.com/server/docs/how-to/software/automatic-updates/ Mises à jour automatiques].


L’original reste intact, avec ses commentaires. La copie est réécrite en YAML, sans reprise des commentaires. Aucun fichier existant n’est écrasé. Si une destination existe, choisir un nouveau nom avec --output.
== Paramètres prévus avant la création ==


=== 5.5. Préparatifs externes ===
* Identité projet, environnement et tags : interne, client, prod ; types YAML stricts.
* Ressources, template, stockage, IP privées/VPN/publique, passerelle et DNS.
* Domaines principal, préprod et Matomo définitifs, sans https:// ni chemin.
* NFS existant et droits accordés par l'administrateur du serveur.
* Activation des vhosts distincte de l'installation des logiciels.
* Noms SQL dédiés Matomo, sans secret dans le YAML.


Avant une création, vérifier séparément la réservation des IP, les déclarations DNS, les règles/routes/NAT nécessaires dans OPNsense et l’inventaire ou les préparatifs Ansible. Ne pas inscrire de mots de passe dans le YAML ; conserver les secrets dans le dispositif prévu pour leur gestion.
Référence MERCURE3 : hostname mercure3.ajlsm.com, VPN 10.0.0.43,
réseau données 192.168.123.27, publique 51.83.117.113. Matomo :
mercure3-matomo.pleade.com ; préprod : mercure3-preprod.pleade.com.
Ne pas conserver deux VM avec ces mêmes adresses.


L’assistant actuel ne vérifie pas automatiquement ces services et ne marque pas un projet « prêt à déployer » sur cette seule base. Leur intégration reste à réaliser.
Chez OVH, principal A vers 51.83.117.113, domaines secondaires CNAME vers
 
mercure3.ajlsm.com dans la recette. Ne pas publier d'AAAA sans IPv6 opérationnel.
Le contrôle Proxmox autonome examine notamment le modèle, ses ressources, le stockage et les bridges. Il concerne une nouvelle création et peut refuser un projet déjà déployé :
Pour un domaine secondaire sur la même IP, réutiliser la VIP/NAT existante si
 
elle et le filtrage traitent déjà le flux requis ; ne pas dupliquer OPNsense.
<syntaxhighlight lang="bash">
Le trafic public passe par la VIP HAProxy 10.0.0.32, nœuds .30 et .31.
./ajlsm-deploy-check /chemin/vers/projet.yaml
</syntaxhighlight>


== 6. Afficher le plan puis lancer le cycle ==
== Préconfiguration et contrôle ==


=== 6.1. Plan sans exécution ===
modeles/projet-vierge.yaml contient des null, jamais une liste [à renseigner].
null est valide pour proxmox.vmid automatique, pas pour un champ obligatoire.
Les sections métier peuvent être omises, mais doivent être complètes si présentes.
exemples/mercure3-exemple.yaml prépare une recréation volontaire, pas une VM parallèle.


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
./ajlsm-deploy-cycle /chemin/vers/projet.yaml --plan
./ajlsm-deploy-yaml ./modeles/projet-vierge.yaml --with-metier --output /etc/ajlsm/deploy/projets/mercure3-initial.yaml
./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3-initial.yaml --check
./ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml --plan
./ajlsm-deploy-check /etc/ajlsm/deploy/projets/mercure3-initial.yaml
</syntaxhighlight>
</syntaxhighlight>


Le plan valide le YAML et affiche les commandes, sans exécuter les phases ni vérifier l’infrastructure. Il doit contenir les 11 étapes, toutes dans le dossier de recette.
Le parcours complet de l'assistant est désormais '''--with-metier''' :
NFS, domaines Matomo/Apache et SQL dédiés dans le même YAML initial.
Sans modèle, utiliser --new --with-metier avec un chemin inexistant.
Les valeurs valides existantes sont conservées ; --review les revoit aussi.
Le guide détaillé GUIDE-YAML.txt décrit les questions et les activations :
Drupal seulement si vérifié, Pleade préprod désactivé en son absence,
Matomo Apache false jusqu'à publication-matomo après pause externe.
Le mode --with-matomo-site reste une activation MANUELLE distincte,
incompatible avec --with-metier ; inutile au cycle guidé actuel.
OS du modèle, DNS, OPNsense, ACME sur les deux HAProxy, Ansible/whitelist
et autorisation NFS sont rappelés mais pas vérifiés ni enregistrés comme tels.


=== 6.2. Cycle réel pour une nouvelle VM ===
Les options individuelles restent disponibles : --with-nfs, --with-matomo, --with-apache et
--with-matomo-sql ; --review revoit aussi les valeurs valides. --new crée un
nouveau chemin. Les fichiers existants ne sont pas écrasés. --check et
--yaml-only sont des contrôles locaux, pas une vérification d'infrastructure.
Prévoir apache.matomo.activer=false pour le cycle initial ; un projet
d'activation true est refusé par le cycle avant toute phase passant par Apache.


<syntaxhighlight lang="bash">
== Cycle initial : dix-sept étapes ==
./ajlsm-deploy-cycle /chemin/vers/projet.yaml
</syntaxhighlight>
 
Le lanceur exécute les phases réelles, sans simulation automatique. Il attend seulement les confirmations, les saisies nécessaires et la fin de chaque commande. Il s’arrête sur refus ou erreur. Il ne répond pas à la place de l’administrateur et ne capture pas les mots de passe.


{| class="wikitable"
{| class="wikitable"
! N° !! Étape !! Commande réelle !! Simulation facultative
! Étape !! Simulation / lecture !! Exécution
|-
| clonage || --dry-run || --clone
|-
| ressources || --resources-dry-run || --configure-resources
|-
| premier-demarrage || --first-boot-dry-run || --first-boot-apply
|-
|-
| 1 || Clonage || --clone || --dry-run
| extension-racine || --root-grow-dry-run || --root-grow-apply
|-
|-
| 2 || Ressources || --configure-resources || --resources-dry-run
| identite || --system-dry-run || --system-apply
|-
|-
| 3 || Premier démarrage isolé || --first-boot-apply || --first-boot-dry-run
| netplan || --network-dry-run || --network-apply
|-
|-
| 4 || Extension partition/LVM/ext4 || --root-grow-apply || --root-grow-dry-run
| activation-reseau || --network-enable-dry-run || --network-enable
|-
|-
| 5 || Identité système || --system-apply || --system-dry-run
| audit-ssh || --ssh-audit || audit, pas de simulation distincte
|-
|-
| 6 || Préparation Netplan || --network-apply || --network-dry-run
| securisation-ssh || aucune || --ssh-secure
|-
|-
| 7 || Activation réseau || --network-enable || --network-enable-dry-run
| mot-de-passe || aucune || --password-ajlsm
|-
|-
| 8 || Audit SSH || --ssh-audit || Aucune option dédiée
| tls || aucune || --tls-apply
|-
|-
| 9 || Sécurisation SSH || --ssh-secure || Aucune option dédiée
| nfs || --nfs-dry-run puis --nfs-check || --nfs-apply
|-
|-
| 10 || Mot de passe ajlsm || --password-ajlsm || Aucune option dédiée
| apache || --apache-dry-run || --apache-apply
|-
|-
| 11 || Certificat TLS interne || --tls-apply || Aucune option dédiée
| matomo-sql || --matomo-sql-dry-run || --matomo-sql-prepare
|-
| tomcat-cron || --scheduled-dry-run || --scheduled-apply
|-
| taches-planifiees || --scheduled-audit || aucune modification
|-
| publication-matomo || --matomo-guided-dry-run || --matomo-guided
|}
|}


L’extension racine est indispensable quand etendre_volume_racine vaut true. Agrandir le disque Proxmox ne suffit pas : la partition, le PV LVM, le LV et ext4 doivent aussi être étendus. Cette phase doit figurer après le premier démarrage, avant la personnalisation système. Avec false, la phase annonce sa désactivation.
Le clone est isolé avant premier démarrage. L'extension racine suit le premier
 
démarrage et ne doit pas être confondue avec le disque virtuel déjà agrandi.
Le démarrage et la personnalisation se font réseau isolé. Netplan est préparé avant activation des liens. La phase d’activation contrôle le réseau et applique demarrage_auto.
Puis identité, réseau, SSH, mot de passe et certificat interne sont traités.
 
Les phases métier non demandées sont ignorées explicitement.
Le certificat TLS interne ne constitue pas, à lui seul, une configuration des applications du projet ou un certificat publiquement reconnu.


=== 6.3. Mode manuel ===
=== Attente réseau pendant l'isolation ===


Chaque phase peut être lancée séparément avec ./ajlsm-deploy suivi du YAML et de son option. Après succès, le lot courant affiche deux lignes pour l’étape suivante : Simulation et Exécution. Si la simulation n’existe pas, il le signale. Aucune suggestion n’est exécutée automatiquement.
Le journal MERCURE3 transmis montre wait-online en attente 120 secondes avant
 
activation des carriers ; le réseau est ensuite online sur les deux cartes.
Les simulations peuvent consulter l’invité et émettre des sondes ARP selon la phase : elles ne sont pas toutes des contrôles hors ligne. L’absence de réponse ARP ne remplace pas la réservation des adresses dans l’inventaire réseau.
Le lot ajoute une dispense conditionnelle liée à l'UUID pendant l'isolation,
 
dès que QGA est disponible. Les phases first-boot et system l'installent après
== 7. Erreur, annulation et reprise ==
les confirmations et gardes ; network-enable la retire après ses contrôles
 
puis vérifie le fonctionnement normal de wait-online avant onboot.
Conserver la sortie complète et diagnostiquer la phase fautive avant de reprendre. Une phase peut être partiellement effectuée ; le lanceur n’effectue ni suppression de VM ni restauration globale automatique.
Le repli réseau remet la dispense après réisolation. Pas de mask/disable,
pas de changement Netplan optional ou de TEMPLATE3. Les simulations n'écrivent
aucun fichier. Ce correctif reste à recetter sur un clone ; il ne nécessite
pas de reconstruire la VM actuelle pour continuer les étapes métier.
Voir CORRECTIF-WAIT-ONLINE.txt pour les deux fichiers gérés, limites et reprise.


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
./ajlsm-deploy-cycle /chemin/vers/projet.yaml --from extension-racine
./ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml
</syntaxhighlight>
</syntaxhighlight>


--from inclut l’étape indiquée et saute les précédentes à la demande de l’administrateur. Il ne certifie pas leur état. Les contrôles propres aux phases restent actifs. Le lanceur ne possède pas de journal persistant global de progression.
Les confirmations OUI/NON, défaut NON, et saisies natives restent interactives.
 
Pas d'arrêt entre commandes réussies ; arrêt au premier refus ou erreur.
Ne pas relancer le cycle depuis le clonage sur une VM existante pour terminer une étape. Ne pas relancer des étapes déjà terminées uniquement parce qu’une commande manuelle les suggère. Les suggestions suivent l’ordre théorique et ne constituent pas un inventaire de l’état de la VM.
--agent-timeout est transmis aux phases, défaut 300 secondes, pas un timeout global.
Après diagnostic, --from reprend l'étape incluse sans refaire les précédentes.
Un --plan n'exécute rien mais ne garantit ni Proxmox ni l'infrastructure externe.


Codes de sortie : 0 succès, 1 annulation, 2 erreur. Le lanceur normalise les autres codes d’échec de ses sous-processus en erreur et ne poursuit pas.
== NFS : autorisation manuelle guidée ==


== 8. Vérifications finales ==
Dépôt d'exemples : 192.168.123.202:/var/data/pleade.com-data/data,
point local identique, mode ro. Un autre dépôt est paramétrable ; plusieurs
dépôts de MERCURE3 restent une exception manuelle. Le script affiche le fichier
exports et la ligne à adapter sur Eole3, sans s'y connecter en administrateur.
L'autorisation de 192.168.123.27 en ro a été réalisée dans la recette.
Les autres exports et données doivent être conservés. Pas de chmod/chown récursif.


Sur Saturne3, avec le VMID réellement annoncé au clonage :
== Apache, Drupal et Pleade ==


<syntaxhighlight lang="bash">
Six fichiers gérés sous /etc/apache2/sites-available : HTTP et TLS pour Drupal,
qm list
préprod et Matomo ; fichier robots préprod séparé. Activation par symlinks selon
qm status VMID
le YAML, manifeste, sauvegarde, syntaxe candidate et reload avec tentative de
qm config VMID
restauration locale sur erreur. Une interruption brutale demande un diagnostic.
</syntaxhighlight>
Un vhost préparé n'installe pas un logiciel et ne valide pas une application.
Les fichiers gérés modifiés hors déploiement provoquent un refus, pas un écrasement.


Remplacer VMID par l’identifiant vérifié. Contrôler le nom, les CPU, la RAM, le disque, les liens réseau et onboot selon le YAML.
Drupal hérité a été vérifié utilisable avec MariaDB et drupal_template ; son
vhost principal est actif dans la recette. Pas de personnalisation SQL Drupal
dédiée dans ce lot. Pleade n'est pas installé, sa préprod reste désactivée ;
pas d'appel à update.sh. Les futurs slecture et internet ne sont pas publiés.


Depuis Saturne3, ouvrir la connexion et attendre l’invite de la VM :
== Matomo : préparation SQL puis activation coordonnée ==
 
<syntaxhighlight lang="bash">
ssh ajlsm@10.0.0.43
</syntaxhighlight>


Dans MERCURE3, saisir sudo -i, attendre l’authentification et l’invite root, puis :
Base et compte locaux dédiés : matomo_mercure3, sans adoption de matomo_template.
Configuration préparée root privée dans /var/lib/ajlsm-matomo-sql ; ne pas
transmettre ces fichiers. En fin de cycle, publication-matomo affiche la pause
externe, demande une attestation OUI/NON puis active Matomo avec le MÊME YAML.
Il passe activer=true en mémoire uniquement ; le YAML initial reste intact.
En mode manuel, après SQL :


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
hostname
./ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3-initial.yaml --matomo-guided-dry-run
lsblk
./ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3-initial.yaml --matomo-guided
df -hT /
ip -br addr
ip route
resolvectl status
</syntaxhighlight>
</syntaxhighlight>


Résultat vérifié pendant la recette : hostname mercure3.ajlsm.com, racine ext4 97 Gio. Les tailles disponibles évoluent avec l’utilisation. Les commandes SSH et TLS du cycle vérifient leurs propres résultats ; compléter par les tests d’accès attendus dans le réseau cible.
L’activation coordonnée conserve Drupal/Pleade. Le mode historique reste
possible : --with-matomo-site crée une copie d’activation, ensuite utilisée par
--matomo-site-dry-run puis --matomo-site-apply.
Ne pas utiliser --apache-apply seul pour cette transition et ne pas relancer
le clonage avec la copie d'activation. Le module désactive les anciens vhosts
Matomo connus, sauvegarde le cache, installe la configuration privée et active
le projet avec contrôle HTTPS local. Les sauvegardes peuvent contenir des secrets.


== 9. Reconstruire MERCURE3 ultérieurement ==
== Certificats en prérequis et pause avant activation ==


# Conserver le fichier mercure3-reference.yaml, le lot de scripts validé et l’identification du modèle utilisé.
Recommandation : DNS puis challenge ACME stateless prêts, émettre/déployer les
# Comparer la référence au YAML effectivement utilisé avant reconstruction ; actualiser les changements d’infrastructure.
certificats publics en prérequis, avant même le clonage backend. Le challenge
# Identifier et sauvegarder les données à conserver : le YAML n’est pas une sauvegarde de VM.
HAProxy ne dépend pas de Matomo. Une pause reste obligatoire à publication-matomo
# Vérifier explicitement l’identité de l’ancienne VM et traiter séparément son arrêt et sa suppression volontaire. Le cycle ne détruit jamais automatiquement une VM existante.
pour vérifier les certificats et le routage restreint sur LES DEUX nœuds.
# Contrôler DNS, OPNsense, Ansible et les réservations d’IP. Ne pas laisser deux VM actives avec les mêmes adresses.
NON arrête proprement le cycle ; --resume reprend après préparation externe.
# Valider la référence avec --check, afficher le --plan, puis lancer le cycle sur la référence après libération de la cible.
Aucune commande ACME/Ansible n’est exécutée par le script et l’attestation
# Relever le nouveau VMID et effectuer les vérifications finales.
humaine ne constitue pas une vérification automatisée.


On retrouve ainsi les paramètres de la VM, sans chercher à reproduire ses anciennes identités techniques.
Le certificat interne généré dans le clone n'est pas le certificat public.
Les certificats publics sont vérifiés/générés avec acme.sh sous l'utilisateur
acme sur les deux HAProxy, l'un après l'autre. Connexion hpr puis sudo -i,
pas root SSH. Conserver le challenge HTTP-01 stateless avant la whitelist.
Émission et déploiement Matomo ont réussi sur les deux nœuds lors de la recette.
Un certificat valide pour le même domaine n'est pas à refaire parce que le
backend est recréé ; revérifier validité, déploiement et renouvellement.


== 10. Protections et détails techniques ==
Ansible ajoute ACL du domaine, refus hors whitelist, redirection HTTPS et
backend SNI vers 10.0.0.43:443. Matomo interne MERCURE3 : allowed_ajlsm uniquement.
Pour un client, prévoir AJLSM et whitelist client selon les règles préprod.
Le backend conserve ssl verify none : l'identité du backend n'est pas validée.


=== 10.1. Isolation, identité et journal de personnalisation ===
<syntaxhighlight lang="bash">
 
ansible-playbook -i inventory ./plays/deploy.haproxy.yml --syntax-check
Le clone est arrêté après création, avec onboot désactivé et les interfaces isolées. Le premier démarrage s’effectue dans cet état d’isolation. Les phases système et réseau vérifient l’identité de la cible et l’UUID attendu selon leurs contrôles propres.
ansible-playbook -i inventory ./plays/deploy.haproxy.yml --limit haproxy01.ajlsm.lan --check --diff
 
ansible-playbook -i inventory ./plays/deploy.haproxy.yml --limit haproxy02.ajlsm.lan --check --diff
La personnalisation système conserve dans l’invité :
<syntaxhighlight lang="text">
/var/lib/ajlsm/system-personalisation/state.json
/var/lib/ajlsm/system-personalisation/backup/
</syntaxhighlight>
</syntaxhighlight>


Ce journal décrit la transaction d’identité, pas l’ensemble du cycle. Ne pas le supprimer pour forcer une nouvelle exécution. Après interruption, conserver les sauvegardes et examiner l’état réel avant reprise.
Examiner tous les diffs puis appliquer séparément en retirant --check, attendre
le succès du premier nœud avant le second. Aucun lancement Ansible automatique
depuis Proxmox. Le check-mode n'est pas l'application réelle.
Recette transmise : deux applications réussies, validation et restart signalés,
aucun failed/unreachable. Avertissement Python découvert /usr/bin/python3.10,
non bloquant dans ces exécutions. Aucun changement d'interpréteur ici.


La VM 515 est signalée comme hors périmètre par la documentation historique. Elle ne fait pas partie de la recette MERCURE3 et ne doit pas être ciblée par cette procédure.
Tester HTTPS sans -k depuis l'IP autorisée puis hors whitelist. Résultats
transmis : 200 avec en-tête Matomo via VPN bureau, 403 hors whitelist.
Un HTTP 200 n'est pas une validation d'installation fonctionnelle.


=== 10.2. Audit SSH : lecture dans la VM, écriture possible sur Saturne3 ===
== Tâches planifiées : correction ciblée puis audit ==


La phase --ssh-audit commence par synchroniser l’identité SSH :
--scheduled-audit inventorie crontabs root/ajlsm/www-data, fichiers système,
# Lire la clé publique /etc/ssh/ssh_host_ed25519_key.pub dans la VM via l’agent QEMU.
noms des scripts périodiques, timers systemd et instances Tomcat. Les commandes
# Valider le format ED25519 et sa structure binaire attendue.
et arguments privés ne sont pas affichés. L'audit historique et l'inventaire
# Lire indépendamment la clé exposée sur le réseau avec ssh-keyscan -T 8 -t ed25519.
avant traitement confirment 13 lignes Tomcat et trois processus, sans Pleade détecté.
# Comparer les clés : une divergence, une absence ou un format invalide provoque un refus.
Après cycle du 18 octobre : zéro tâche Tomcat active pour les trois instances
# Après concordance seulement, sauvegarder /root/.ssh/known_hosts sur Saturne3, travailler sur une copie et remplacer le fichier avec la nouvelle entrée vérifiée pour l’IP cible.
vides ; processus déjà lancés conservés et archivage mensuel inchangé.
# Contrôler les connexions par clé, les clés autorisées, sudo et l’état du compte ajlsm.
Les tâches des autres comptes, timers utilisateurs et contenus des scripts
restent hors audit. L'inventaire seul n'effectue aucune désactivation.
Code 0 = inventaire obtenu, pas tâches approuvées. Rotation des logs inchangée.


Les autres entrées d’hôtes sont conservées ; le traitement retire aussi les anciennes entrées hachées correspondant à l’IP cible. Les sauvegardes utilisent le préfixe known_hosts.ajlsm-backup. dans /root/.ssh/.
La phase '''tomcat-cron''' a été autorisée pour ne pas reproduire ces tâches
inutiles sur les nouveaux clones. --scheduled-dry-run affiche les lignes
reconnues à commenter ; --scheduled-apply demande OUI/NON, sauvegarde la crontab
ajlsm et commente ces seules lignes avec un marqueur réversible. Elle ne lance
aucune commande de démarrage, arrêt ou nettoyage Tomcat. Le cycle l'exécute en
étape 15, puis audite le résultat en étape 16.


'''L’audit n’est donc pas entièrement sans écriture :''' ses lectures dans la VM sont accompagnées d’une mise à jour possible de known_hosts sur Saturne3. Ne jamais contourner une divergence en effaçant aveuglément known_hosts.
Critères conservateurs : répertoire Pleade présent et entièrement vide,
webapps absent d'autre application et lien pleade vers le chemin attendu,
pas de contexte externe dans conf/Catalina/localhost. Une implantation non
vérifiable ou un contenu partiel conserve les tâches. Une commande inconnue
visant une instance vide bloque la phase, sans modification partielle.
Seules les formes exactes des commandes héritées auditées sont reconnues.


=== 10.3. Sécurisation SSH et mot de passe ===
Sauvegarde privée : /var/backups/ajlsm-scheduled/transaction-* ; journal :
/var/lib/ajlsm-scheduled/transaction.json. Vérification identité/UUID et
empreinte de la crontab avant application, relecture après installation.
Restauration tentée sur erreur contrôlée si elle n'écrase pas un changement
concurrent détecté. Sinon journal conservé et reprise bloquée pour examen manuel.
Le verrou ne protège pas contre crontab -e dans un autre terminal : ne pas
modifier simultanément les tâches ou déployer une application pendant la phase.
L'interface crontab ne fournit pas de comparaison-installation atomique face
aux outils extérieurs. Les @reboot des premiers démarrages du clone peuvent
déjà avoir lancé Tomcat : seuls les lancements futurs sont neutralisés.
Pas de réactivation automatique lors d'une installation Pleade ultérieure.


--ssh-secure effectue un audit préalable, prépare un fichier SSH dédié, vérifie la syntaxe et les valeurs effectives, puis recharge SSH. Il désactive l’authentification SSH par mot de passe et conserve root par clé. Les connexions root et ajlsm par clé sont revérifiées par le code reçu.
== Finalisation fonctionnelle, hors déploiement piloté ==


Le mot de passe local ajlsm reste utile pour sudo. --password-ajlsm utilise un terminal interactif et lance passwd dans la VM, avec sa double saisie masquée. Le secret n’est pas inscrit dans le YAML ni dans la ligne de commande. La procédure historique prévoit un report manuel dans le registre ODS d’administration ; appliquer les règles internes de gestion des secrets. Ne pas joindre ce registre à une documentation publique.
L'installateur Matomo a confirmé « Tables créées » dans la recette. Création
du superadministrateur, premier site, fin de l'assistant et intégration du suivi
restent manuelles. Ne pas laisser un installateur inachevé ouvert durablement.
Lire FINALISATION-MATOMO.txt : reprise directe tablesCreation et avertissement
sur systemCheck qui supprime la configuration locale préparée en version auditée.
Diagnostics applicatifs non annoncés comme faits. Ne pas partager de secrets.


=== 10.4. Certificat TLS interne et Apache ===
== Point d’arrêt et reprise depuis tout répertoire ==


--tls-apply lit le certificat /etc/ssl/ajlsm/server.crt. Si le CN et le SAN correspondent déjà au hostname attendu, la phase termine sans réinitialisation. Sinon, après confirmation, elle appelle /usr/local/sbin/ajlsm-init-tls.sh '''dans la VM'''. Ce dernier script doit être présent dans le modèle ; son contenu n’était pas inclus dans l’archive des scripts de déploiement reçue.
Le nouveau lanceur conserve un journal privé sur Saturne3 dans
/var/lib/ajlsm-deploy/cycles/, mode 600, historique par exécution.
Il n’enregistre ni mots de passe, ni sortie complète des phases.
Il suit étape courante, dernière réussite, dates UTC, codes de sortie,
empreintes du YAML/lot, hôte et identité VMID/UUID de la cible.
Un verrou protège ce journal, pas les interventions d’un autre administrateur.


Après une initialisation réussie, le module contrôle le certificat, apache2ctl configtest et systemctl is-active apache2. Ce contrôle technique d’Apache ne constitue pas une recette des VirtualHosts et des applications du projet.
Avec chemins absolus, depuis n’importe quel répertoire '''du même nœud''' :
 
La documentation historique désigne /home/ajlsm/README, hérité de TEMPLATE3, comme README applicatif Pleade/Drupal. Le conserver séparément du README-ajlsm-deploy de l’outil de déploiement ; ne pas remplacer l’un par l’autre.
 
=== 10.5. Attente réseau au premier démarrage ===
 
La recette du 15 octobre signalait environ 60 secondes d’attente dans systemd-networkd-wait-online lorsque les interfaces étaient isolées. Ce constat historique n’a pas empêché l’agent QEMU ni ajlsm-clone-init de répondre. Une optimisation éventuelle du modèle reste distincte du déploiement ; ne pas désactiver le service sans vérifier ses dépendances.
 
== 11. Maintenance, sauvegardes et manuel ==
 
=== 11.1. Identifier les fichiers réellement exécutés ===
 
La recette du 16 octobre utilise le dossier /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/. Elle ne démontre pas une mise à jour globale de /usr/local/sbin/. Toujours distinguer le lot validé et les programmes installés.
 
Dans le dossier de recette :
<syntaxhighlight lang="bash">
./ajlsm-deploy --help
./ajlsm-deploy-cycle --help
./ajlsm-deploy-yaml --help
python3 -m py_compile ajlsm-deploy ajlsm-deploy-check ajlsm-deploy-resources ajlsm-deploy-cycle ajlsm-deploy-yaml ajlsm_deploy_common.py ajlsm_deploy_rootgrow.py ajlsm_deploy_postconfig.py
</syntaxhighlight>
 
Une compilation vérifie la syntaxe, pas le bon déroulement d’une phase ni les prérequis serveur.
 
=== 11.2. Sauvegarder et restaurer un lot cohérent ===
 
Conserver ensemble programmes, modules et configuration de référence. Sauvegarder le lot complet avant une installation ou une correction. Exemple sur Saturne3 :
<syntaxhighlight lang="bash">
tar -czf "/root/ajlsm-deploy/archives/lot-recette-$(date +%Y%m%d-%H%M%S).tar.gz" \
  -C /root/ajlsm-deploy/recettes/20261016 ajlsm-deploy-cycle
</syntaxhighlight>
 
Une restauration doit porter sur un ensemble compatible. Ne pas réinstaller uniquement ajlsm-deploy.bak-20261015 : ce fichier peut précéder les modules et phases nécessaires. L’ancienne sauvegarde et les répertoires de revue sont des références historiques à inventorier avant nettoyage.
 
Ne pas supprimer INSTRUCTIONS-TEST.txt ou d’autres fichiers de /root/ajlsm-deploy-review/ sur la seule base de l’ancienne page. Leur archivage et le nettoyage ne font pas partie de cette mise à jour documentaire.
 
=== 11.3. Page man ===
 
La page du 15 octobre indique un manuel installé en /usr/local/man/man8/ajlsm-deploy.8 et une sauvegarde hors man8 dans /root/ajlsm-deploy-review/sauvegardes-man/. Ce sont des informations historiques, dont l’état actuel n’a pas été vérifié pendant la recette du 16 octobre.
 
Pour identifier la page disponible sur Saturne3 :
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
man -w ajlsm-deploy
/opt/ajlsm-deploy/v1/ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml --status
man 8 ajlsm-deploy
/opt/ajlsm-deploy/v1/ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml --resume
</syntaxhighlight>
</syntaxhighlight>


Une page absente ne signifie pas que le script est absent : --help est l’aide intégrée de l’exécutable. Le manuel installé doit être réconcilié avec le cycle et l’assistant avant d’être considéré comme référence de cette version. En attendant, le présent guide et l’aide des fichiers du lot de recette décrivent le fonctionnement courant.
--status ne contacte pas Proxmox et ne crée aucun journal. --resume reprend
 
la première étape non réussie, avec contrôles et confirmations habituels.
Man le 16/10/2026
Une faute « ouii » à tls se reprend donc à tls sans reclonage.
<syntaxhighlight lang="text">
La reprise refuse les changements de nœud, YAML, code/ordre ou d’identité
AJLSM-DEPLOY(8)                                    Administration système                                    AJLSM-DEPLOY(8)
VM enregistrée. Elle ne relance pas un cycle déjà terminé.
 
Après coupure brutale, en_cours signifie résultat inconnu : examiner les
NOM
journaux transactionnels, l’état et les processus avant reprise.
      ajlsm-deploy - déployer une VM Proxmox par phases contrôlées
Le journal n’est pas une preuve de conformité permanente de l’infrastructure.
 
SYNOPSIS
      ajlsm-deploy projet.yaml PHASE [--agent-timeout secondes]
      ajlsm-deploy-check projet.yaml [--phase proxmox] [--yaml-only]
      ajlsm-deploy-resources projet.yaml (--dry-run | --apply)
 
DESCRIPTION
      Programme  à  exécuter  sur  le  nœud Proxmox cible, avec les droits administrateur. Chaque invocation traite une seule
      phase.  Le YAML est validé avant les commandes externes.
 
      Après succès, les suggestions affichent les commandes de simulation et d'exécution de la prochaine étape, ou de l'étape
      simulée.  Les étapes sans simulation dédiée le signalent explicitement. Ces suggestions ne sont jamais  exécutées  au‐
      tomatiquement.  Elles décrivent l'ordre théorique, sans mémoriser l'état du cycle.
 
      Pour  enchaîner les onze étapes sans en oublier, utiliser ajlsm-deploy-cycle(8).  Ce lanceur conserve les confirmations
      et les saisies interactives.
 
ORDRE DES PHASES
      1. --clone
              Créer le clone complet, désactiver onboot, isoler les interfaces, vérifier l'arrêt et les  adresses  MAC.  Aucun
              démarrage.  Simulation : --dry-run, qui comprend les précontrôles.
 
      2. --configure-resources
              Configurer  et vérifier CPU, mémoire, balloon et disque scsi0.  Exige une VM arrêtée, onboot désactivé et inter‐
              faces isolées.  La réduction du disque est interdite.  Simulation : --resources-dry-run.
 
      3. --first-boot-apply
              Démarrer le clone isolé, attendre l'agent QEMU et ajlsm-clone-init, puis vérifier les identités  attendues.  Si
              la VM tourne déjà, reprendre les contrôles sans redémarrage.  Simulation : --first-boot-dry-run.
 
      4. --root-grow-apply
              Après le  premier démarrage et avant la personnalisation système, étendre la partition, le PV LVM, le LV racine
              et ext4.  Cette étape dépend de etendre_volume_racine dans le YAML.  Simulation : --root-grow-dry-run.
 
      5. --system-apply
              Personnaliser hostname, hosts et machine-id, redémarrer isolé et vérifier l'identité active. Respecter le  jour‐
              nal de transaction.  Simulation : --system-dry-run.
 
      6. --network-apply
              Sauvegarder  et  écrire Netplan dans l'invité, puis exécuter netplan generate. Les liens Proxmox restent isolés.
              Simulation : --network-dry-run.
 
      7. --network-enable
              Contrôler identité, configuration et conflits ARP, activer les liens, vérifier adresses, loopback, route, DNS et
              passerelle, puis appliquer demarrage_auto.  Un mécanisme de repli tente de rétablir l'isolation en cas  d'échec.
              Simulation : --network-enable-dry-run.
 
      8. --ssh-audit
              Comparer  la  clé  ED25519 lue via QEMU à celle exposée sur le réseau, actualiser known_hosts après concordance,
              puis vérifier les accès, clés autorisées, sudo et état du compte ajlsm.  Aucune simulation dédiée.
 
      9. --ssh-secure
              Après audit et confirmation, désactiver l'authentification SSH par mot de passe, conserver root par  clé,  véri‐
              fier  la  configuration,  recharger  SSH  et  contrôler les connexions root et ajlsm par clé.  Aucune simulation
              dédiée.
 
      10. --password-ajlsm
              Ouvrir passwd pour ajlsm dans la VM avec double saisie native masquée.  Un terminal interactif est  obligatoire.
              Le mot de passe n'est pas placé dans le YAML ni la ligne de commande.  Aucune simulation dédiée.
 
      11. --tls-apply
              Vérifier  le  certificat TLS interne. Si CN et SAN correspondent déjà au hostname, ne pas réinitialiser.  Sinon,
              après confirmation, appeler ajlsm-init-tls.sh dans la VM, puis vérifier certificat, syntaxe  Apache  et  service
              actif.  Aucune simulation dédiée.
 
OPTIONS COMMUNES
      --agent-timeout secondes
              Entier  strictement  positif,  défaut 300.  Délai transmis aux attentes utilisant l'agent QEMU.  Il ne constitue
              pas un délai maximal global.  La phase d'extension racine autorise au moins 600 secondes pour son exécution  in‐
              vitée après les précontrôles.
 
      -h, --help
              Afficher l'aide intégrée sans accéder à Proxmox.


      Choisir  exactement une phase. Les noms des options du programme principal doivent être écrits en entier ; les abrévia‐
--from étape reste une reprise explicite après diagnostic, qui démarre un
      tions telles que --network-dry sont refusées.
nouveau journal et marque les étapes antérieures ignorées, pas vérifiées.
Ne pas effacer les journaux pour contourner une erreur.
Les anciens lots sans journal ne permettent pas --resume rétroactif :
consulter leur sortie console puis reprendre avec --from.
Pour la VM actuelle, l’application de la dernière simulation Matomo n’est
pas confirmée. Contrôler avant de reprendre à publication-matomo, sans clonage.


CONFIRMATIONS
== Détails de sécurité conservés de la documentation du 16 octobre ==
      Seul OUI, sans distinction de casse et après suppression des espaces périphériques, autorise une opération à  la ques‐
      tion correspondante.  NON, vide, autre réponse, EOF ou interruption pendant la question annulent. Il n'existe pas d'op‐
      tion de confirmation automatique.  Une étape déjà conforme peut terminer sans modification ni nouvelle confirmation.


EXTENSION RACINE
L’audit SSH lit la clé ED25519 via QEMU, vérifie son format binaire, puis
      Le  disque  Proxmox  agrandi  par  la phase ressources ne suffit pas à agrandir le système de fichiers de l'invité.  La
compare indépendamment celle exposée par ssh-keyscan. Une divergence refuse
      phase racine réalise growpart, pvresize et lvextend avec redimensionnement du système de fichiers.
la suite. Après concordance seulement, sauvegarde et remplacement atomique
 
possible de /root/.ssh/known_hosts sur Saturne3 ; les autres hôtes sont conservés,
      Topologie prise en charge : racine ext4, PV /dev/sda3, partition terminale parmi trois partitions de /dev/sda, un  seul
y compris traitement ciblé des anciennes entrées hachées de l’IP du clone.
      PV  et  un seul LV. La taille du disque doit correspondre au YAML. Les outils doivent déjà être présents ; aucun paquet
--ssh-audit n’est donc pas entièrement sans écriture.
      n'est installé par cette phase.
--ssh-secure vérifie la syntaxe/effectivité et les connexions par clé avant/après
 
reload ; le mot de passe local reste utile à sudo.
      Si la partition est déjà agrandie, le code saute growpart et poursuit le traitement LVM. Si etendre_volume_racine  vaut
--password-ajlsm utilise passwd interactif masqué ; aucun secret dans le YAML.
      false, la phase annonce sa désactivation. Vérifier ensuite lsblk et df -hT /.
 
SSH ET TLS
      L'audit  SSH  n'est  pas  intégralement sans écriture : il peut sauvegarder et actualiser /root/.ssh/known_hosts sur le
      nœud Proxmox après comparaison indépendante des clés QEMU/réseau.  Une divergence provoque un refus ; ne pas  supprimer
      aveuglément known_hosts pour contourner ce contrôle.
 
      La  structure  binaire ED25519 est contrôlée avant comparaison.  Une clé absente ou malformée provoque également un re‐
      fus.  Après concordance, les anciennes entrées de l'IP cible, y compris hachées, sont retirées de la copie de  travail.
      Les autres hôtes sont conservés et le remplacement est atomique.
 
      Le  mot de passe local ajlsm reste utile pour sudo même lorsque l'authentification SSH par mot de passe est désactivée.
      Le conserver selon la procédure interne de gestion des secrets.  La procédure AJLSM prévoit un report  manuel  dans  le
      registre ODS d'administration ; ne pas inclure ce registre dans le YAML.
 
      Le  certificat  interne  et le contrôle technique d'Apache ne valident pas les VirtualHosts ni les applications. ajlsm-
      init-tls.sh doit être présent dans l'invité ; son contenu n'est pas fourni par le lot de scripts du nœud Proxmox.
 
FORMAT YAML
      Sections obligatoires : projet, proxmox, systeme et reseau.  Les clés inconnues, répétées ou manquantes sont  refusées.
      Seul  proxmox.vmid  peut rester null pour une attribution automatique.  Ce VMID n'est pas réservé avant clonage et peut
      changer.
 
      projet.environnement et tags acceptent interne, client ou prod.  Les tags forment une liste sans doublon ; []  est  ad‐
      mis.  Les  ressources  exigent des entiers positifs ; la mémoire minimale ne dépasse pas la maximale. Utiliser true ou
      false pour les booléens.
 
      Les chaînes numériques et les booléens ne sont pas convertis en entiers par le validateur. Le VMID explicite doit  être
      différent du template_vmid. Aucune correspondance automatique n'est imposée entre l'environnement et les tags.
 
      Hostname DNS en minuscules ; interfaces Proxmox netN et invitées ensN.  Les IPv4 d'interfaces exigent un préfixe CIDR ;
      la  loopback  exige  /32.  La passerelle est dans le sous-réseau de son interface déclarée.  Les interfaces et adresses
      sont uniques.  Les DNS forment une liste non vide d'IPv4 sans préfixe.  La passerelle doit différer  des  adresses  des
      interfaces.  Les adresses réseau et broadcast sont refusées pour les sous-réseaux de préfixe inférieur à 31.  Serveur,
      stockage et bridge restent des valeurs d'infrastructure à renseigner ; aucune liste  fermée  n'est  inventée  pour  ces
      champs.
 
      Préparer  le  fichier  avec  ajlsm-deploy-yaml(8).  projet-vierge.yaml  est volontairement incomplet.  mercure3-refer‐
      ence.yaml conserve les paramètres de reconstruction, pas les données, secrets ou anciennes identités de la VM.
 
AUXILIAIRES
      ajlsm-deploy-check
              Valider le YAML, puis contrôler le modèle, ses  ressources,  le  stockage  et  les  bridges  pour  une  nouvelle
              création.  --phase  accepte uniquement proxmox.  --yaml-only effectue seulement la validation locale, sans com‐
              mande Proxmox. Une VM de projet déjà existante peut faire échouer les contrôles de nouvelle création.
 
      ajlsm-deploy-resources
              Configurer les ressources avec --apply, ou simuler avec --dry-run. Ces modes  sont  exclusifs  et  obligatoires.
              Les  protections sont revérifiées avant chaque écriture.  Le programme refuse notamment une cible modèle ou con‐
              fondue avec la source, et un VMID explicite incohérent.
 
PRÉREQUIS
      Python 3.9 ou supérieur, PyYAML 6, outils Proxmox et outils réseau.  Conserver le principal, ses  deux  auxiliaires  et
      les  modules  common, rootgrow et postconfig dans le même répertoire.  Les auxiliaires doivent être exécutables et leur
      Python doit disposer de PyYAML.
 
      Le modèle arrêté doit disposer de l'agent QEMU, ajlsm-clone-init, Python, systemd, Netplan, outils LVM et outils  d'ex‐
      tension.  Les phases postréseau nécessitent les accès SSH par clé prévus et le script TLS invité.
 
FICHIERS
      /etc/ajlsm/deploy/projets/
              Configurations des projets.
 
      /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/
              Lot de recette validé le 16 octobre 2026.  Utiliser les chemins ./ pour ne pas appeler une ancienne version.
 
      /usr/local/sbin/
              Programmes installés antérieurement ; leur mise à jour n'est pas prouvée par le succès du lot de recette.
 
      /var/lib/ajlsm/system-personalisation/
              Journal et sauvegardes d'identité dans l'invité.  Ne pas effacer pour forcer une reprise.
 
LIMITES
      Les  simulations  ne  sont pas toutes hors ligne : la simulation d'activation réseau émet des sondes ARP.  L'absence de
      réponse ne garantit pas la disponibilité d'une IP.  Le repli réseau en situation réelle reste à recetter.
 
      Les validations locales ne certifient pas DNS, OPNsense ou Ansible.  NFS,  VirtualHosts  Apache2,  Pleade,  Drupal  et
      Matomo restent hors du cycle applicatif actuellement implémenté.
 
      Le  README  applicatif /home/ajlsm/README hérité du modèle est distinct du README de déploiement. Ne pas remplacer l'un
      par l'autre.
 
CODES DE SORTIE
      0 : succès. 1 : annulation. 2 : erreur.  L'aide quitte avec 0 ; une erreur d'arguments quitte avec 2.
 
EXEMPLES
      Depuis le dossier de recette, sur Saturne3 :
      ./ajlsm-deploy-check projet.yaml --yaml-only
      ./ajlsm-deploy projet.yaml --dry-run
      ./ajlsm-deploy projet.yaml --clone
      ./ajlsm-deploy projet.yaml --resources-dry-run
      ./ajlsm-deploy projet.yaml --configure-resources
      ./ajlsm-deploy projet.yaml --first-boot-dry-run
      ./ajlsm-deploy projet.yaml --first-boot-apply
      ./ajlsm-deploy projet.yaml --root-grow-dry-run
      ./ajlsm-deploy projet.yaml --root-grow-apply
      ./ajlsm-deploy projet.yaml --system-dry-run
      ./ajlsm-deploy projet.yaml --system-apply
      ./ajlsm-deploy projet.yaml --network-dry-run
      ./ajlsm-deploy projet.yaml --network-apply
      ./ajlsm-deploy projet.yaml --network-enable-dry-run
      ./ajlsm-deploy projet.yaml --network-enable
      ./ajlsm-deploy projet.yaml --ssh-audit
      ./ajlsm-deploy projet.yaml --ssh-secure
      ./ajlsm-deploy projet.yaml --password-ajlsm
      ./ajlsm-deploy projet.yaml --tls-apply
      Les simulations sont facultatives. Le mode manuel exige le contrôle de l'ordre des phases. Pour l'enchaînement guidé :
      ./ajlsm-deploy-cycle projet.yaml --plan
      ./ajlsm-deploy-cycle projet.yaml
      Ne pas relancer un cycle de création sur MERCURE3 déjà déployée.
 
ÉTAT DE LA RECETTE
      Le manuel installé reçu portait la date du 15 octobre 2026.  Il décrivait déjà les phases racine, SSH et TLS, mais  pas
      le nouveau lanceur ni l'assistant YAML.
 
      Le  16 octobre, les sorties transmises ont confirmé la fin du cycle complet sur MERCURE3. Les vérifications finales ont
      confirmé SSH, sudo, mercure3.ajlsm.com et une racine ext4 de 97 Gio.  Les scénarios négatifs de clés SSH  étaient  rap‐
      portés  comme  tests  isolés  du  15 octobre ; ils n'ont pas été rejoués lors de la présente révision documentaire.  Le
      repli réseau réel reste distinct de cette recette nominale.
 
VOIR AUSSI
      ajlsm-deploy-cycle(8), ajlsm-deploy-yaml(8), qm(1), lvm(8).
 
AJLSM                                                  October 16, 2026                                        AJLSM-DEPLOY(8)
~
</syntaxhighlight>
 
== 12. État des validations et limites ==
 
{| class="wikitable"
! Date / source !! Vérification !! Portée
|-
| 15/10/2026, page historique || Déploiements initiaux jusqu’à l’activation réseau || Résultats historiques conservés ; ne décrivent pas à eux seuls le cycle actuel
|-
| 15/10/2026, page historique || Comparaison ED25519, clés divergentes ou malformées, préservation de known_hosts || Tests isolés rapportés dans la documentation reçue, non rejoués lors de cette consolidation
|-
| 16/10/2026, tests locaux du lot cycle || Ordre des 11 étapes, arrêt sur refus/erreur, reprise et suggestions || 8 tests réussis, incluant des sous-cas ; sous-processus des phases simulés
|-
| 16/10/2026, sorties Saturne3 transmises || Cycle technique complet sur un nouveau clone MERCURE3 || Terminé sans erreur signalée, extension racine incluse
|-
| 16/10/2026, sorties invitées transmises || SSH ajlsm, sudo, hostname et racine ext4 || Confirmés ; mercure3.ajlsm.com et 97 Gio pour /
|-
| 16/10/2026, tests locaux assistant || Création, correction, copie, validation et annulation || 14 tests réussis, saisies simulées
|-
| 16/10/2026, sortie Saturne3 transmise || Assistant --check sur mercure3.yaml || Valeurs YAML valides ; aucune écriture ni validation externe
|-
| 16/10/2026, vérification locale des modèles || Modèle vierge complété par l’assistant || Paramètres identiques à la référence MERCURE3 ; original intact
|-
| À réaliser || Essai réel du mécanisme de repli après échec d’activation réseau || Non confirmé ; le succès du parcours nominal ne valide pas ce scénario
|-
| À réaliser || Vérifications automatiques DNS, OPNsense, Ansible et recette applicative || Hors périmètre actuel
|}


Le message de fin du cycle signifie que ses phases ont retourné un succès. Il ne vaut pas validation des applications ni détection de toutes les défaillances possibles. Conserver les vérifications finales et les limites propres aux phases.
La personnalisation système conserve dans la VM
/var/lib/ajlsm/system-personalisation/state.json et backup/. Ce journal décrit
une transaction, pas le cycle global. Ne pas l’effacer pour forcer une reprise.
La phase TLS vérifie le certificat interne /etc/ssl/ajlsm/server.crt, utilise
si nécessaire /usr/local/sbin/ajlsm-init-tls.sh déjà présent dans le modèle,
puis contrôle Apache. Cela ne valide pas les applications ou le TLS public.
Le README applicatif /home/ajlsm/README ne doit pas être remplacé par le
README-ajlsm-deploy de l’outil. Le document README-TEMPLATE3.txt est proposé
séparément, pas installé automatiquement.


== 13. Réconciliation avec la page du 15 octobre ==
Validation YAML stricte : clés inconnues/répétées et types incorrects refusés ;
environnement/tags interne, client, prod, sans doublons ; tags [] admis ;
entiers positifs, mémoire minimale <= maximale, booléens true/false ;
interfaces netN/ensN uniques, IPv4/CIDR, loopback /32, DNS sans préfixe.
Passerelle dans le sous-réseau de son interface et distincte de la VM.
Serveur, bridge et stockage sont à adapter à l’infrastructure, sans liste
fermée inventée. Les sections métier sont désormais prises en charge :
l’interdiction historique d’ajouter metier ne s’applique plus à ce schéma.


L’original reçu est conservé intégralement dans historique/guide-20261015.mediawiki. Il sert de trace, pas de seconde procédure opérationnelle concurrente.
== Manuels, reprise et validation du lot ==


Le présent document remplace les indications opérationnelles anciennes :
Pages section 8 de la version 1.0.2 du 19 octobre : deploy, cycle, yaml, check, resources.
* confirmations CLONER/APPLIQUER/DEMARRER remplacées par OUI/NON ;
Lecture locale avec man ./man8/ajlsm-deploy.8 ; sauvegarde et installation
* parcours manuel seul remplacé par le choix entre mode manuel et cycle interactif ;
optionnelle décrites dans INSTALLATION-MANUELS.txt, sans copier les scripts.
* liste des étapes incluant l’extension racine, SSH, mot de passe et TLS ;
Le lancement définitif se fait dans /opt/ajlsm-deploy/v1, sans copier les
* extension racine et cycle complet désormais validés sur la recette du 16 octobre ;
programmes du nœud dans /usr/local/sbin. La commande invitée
* suggestions manuelles affichant les deux commandes disponibles, sans oublier l’extension racine ;
/usr/local/sbin/ajlsm-init-tls.sh reste distincte et n'est pas déplacée.
* création et relecture du YAML par l’assistant, sans écraser l’original ;
Conserver le lot complet, modules et modèles, sans mélanger les versions.
* ajout du modèle vierge et de la référence MERCURE3 renseignée ;
Une installation du lot ne remplace pas une recette complète sur Proxmox.
* séparation explicite des scripts installés, du lot de recette, du manuel historique et de la future installation.
Tests locaux sous tests/, résultats dans RAPPORT-TESTS.txt ; QGA, SQL, PHP
et services simulés. Ils ne prouvent pas la réussite d'un déploiement distant.
Une restauration de phase n'annule pas SQL ni les actions web ultérieures.
Ne pas effacer un journal transaction.json pour forcer une reprise.


Les détails encore utiles de l’ancienne page sur l’isolation, les transactions, ED25519, les sauvegardes, le README applicatif et les limites de validation sont repris ci-dessus. Une nouvelle mise à jour fonctionnelle doit modifier cette procédure directement plutôt que superposer une nouvelle section corrective à une ancienne procédure contradictoire.
== Réconciliation de la page reçue du 16 octobre et état de recette ==


== 14. Suites prévues ==
Cette procédure remplace les indications historiques « 11 étapes »,
« NFS/Apache/Matomo hors cycle » et « aucun journal global ». Le nouveau lot
compte 17 étapes avec publication protégée, mais la finalisation fonctionnelle
Matomo reste indépendante. L’ancien man reproduit intégralement dans la page
du 16 octobre n’est pas recopié ici : les cinq sources man8 de ce lot sont
la référence de version, sans procédure concurrente.
Les anciens chemins du 16 octobre restent des archives, pas le lot courant.


Prévoir les paramètres NFS, sites Apache2, Pleade, Drupal et Matomo dans le même YAML lorsque leurs exigences seront définies. Modifier ensemble le schéma, l’assistant, les modèles, les précontrôles, les phases et leur documentation. Documenter les références aux secrets plutôt que leurs valeurs.
Le cycle 16 étapes du lot consolide-taches a été exécuté sur un clone recréé
le 18 octobre, reprise TLS après faute de saisie incluse. Hostname et racine
ext4 97 Gio confirmés. Tâches Tomcat neutralisées pour les instances vides ;
les processus déjà lancés n’ont pas été arrêtés. Le correctif wait-online et
le nouveau cycle 17 étapes avec journal restent à valider sur Proxmox.
Les tests locaux ne sont pas une nouvelle recette distante.
La capture « Tables créées » et la première activation Matomo concernent le
clone antérieur : ne pas les attribuer automatiquement au clone actuel.
Le succès nominal ne valide pas le repli réseau après panne.


L’intégration des contrôles DNS, OPNsense et Ansible précédera une déclaration automatisée de disponibilité du projet. Le modèle actuel ne contient pas encore ces nouvelles sections.
Le modèle TEMPLATE3 n’a pas été modifié par ces scripts. Cela ne démontre
pas l’absence de toute autre intervention. Sa mise à jour OS demandée est
une maintenance à réaliser/valider séparément avant le prochain clonage.
Aucun nettoyage serveur ni envoi SVN n’est exécuté par cette livraison.


[[Catégorie:Infrastructure]]
[[Category:Proxmox]][[Category:AJLSM]][[Category:Déploiement]]
[[Catégorie:Proxmox]]
[[Catégorie:Déploiement]]
[[Catégorie:AJLSM]]

Version du 19 octobre 2026 à 07:35

AJLSM-DEPLOY — Version 1.0.2

Mise à jour : 19 octobre 2026. Ce guide décrit les scripts du dossier ajlsm-deploy-v1.0.2, à installer dans /opt/ajlsm-deploy/v1. Ce chemin est le répertoire définitif de lancement sur le nœud Proxmox ; les anciennes copies de /usr/local/sbin ne sont pas remplacées implicitement. Les lots NFS, Apache et Matomo précédents sont historiques. Garder scripts, modules et modèles du même lot. Rotation des logs et update.sh hors périmètre.

Périmètre et architecture

Les scripts tournent sur le nœud Proxmox. Ils configurent le clone depuis un projet YAML strict, utilisent QEMU Guest Agent pour les opérations invitées, et SSH pour certaines vérifications/postconfigurations. Le moteur principal orchestre les phases ; les modules spécialisés traitent racine, postconfiguration, NFS, Apache, SQL Matomo, activation Matomo et inventaire des tâches planifiées. Les helpers communs valident le YAML et affichent les commandes suivantes.

Ce n'est pas un gestionnaire complet de l'infrastructure externe. DNS, OPNsense, Ansible, autorisation Eole3 et certificats publics ont leurs procédures. Le script ne détruit pas la VM existante et ne modifie pas TEMPLATE3.

Répertoire définitif et exemple MERCURE3

Les cinq programmes affichent la version 1.0.2 avec --version. Leur --help rappelle le même répertoire et le même exemple que cette page. Ces valeurs sont centralisées dans ajlsm_deploy_version.py. Les suggestions visent les programmes du dossier réellement exécuté : utiliser le lot installé ci-dessous, pas un ancien dossier de recette.

Sur Saturne3, après installation du lot complet selon INSTALLATION-V1.txt : 

cd /opt/ajlsm-deploy/v1

Toutes les commandes ./ de cette page se lancent depuis ce répertoire. Depuis un autre répertoire du même nœud, utiliser le chemin absolu du programme sous /opt/ajlsm-deploy/v1 et celui du YAML. Les YAML opérationnels restent sous /etc/ajlsm/deploy/projets/, les journaux sous /var/lib/ajlsm-deploy/cycles/. Les archives/recettes sous /root/ajlsm-deploy ne sont plus le répertoire de lancement v1. Ne pas mélanger les modules ou changer de lot pendant un cycle.

exemples/mercure3-exemple.yaml est un exemple renseigné avec les IP réelles de MERCURE3, pas une préconfiguration générique. Les commandes MERCURE3 de ce guide sont des exemples à adapter au projet. Le nom de la VM, ses DNS et ses fichiers YAML opérationnels existants ne sont pas renommés. En particulier, conserver le chemin du YAML pour la reprise : le journal est indexé par ce chemin absolu. modeles/projet-vierge.yaml demeure le modèle générique sans valeurs.

Prérequis impératif : OS de TEMPLATE3 à jour

Avant TOUT nouveau clonage, maintenir l’OS Ubuntu de TEMPLATE3 à jour. La VM clonée hérite de cet état. Maintenance manuelle distincte : les scripts de déploiement ne mettent pas le modèle à jour. Prévoir une sauvegarde récupérable et une fenêtre sans conflit d’IP avec les clones existants. Ne pas démarrer ni convertir à l’aveugle un modèle marqué template Proxmox.

Dans la console de TEMPLATE3, après vérification de son identité : 

hostname -f
cat /etc/os-release
sudo apt update
sudo apt upgrade
apt list --upgradable
if [ -f /var/run/reboot-required ]; then
  cat /var/run/reboot-required
  cat /var/run/reboot-required.pkgs 2>/dev/null || true
fi

Examiner toutes les erreurs, messages APT et paquets retenus/différés. apt update seul ne met pas les paquets à jour. Pas de -y, full-upgrade, do-release-upgrade ou update.sh automatique. Si un redémarrage est demandé : 

sudo reboot

Attendre le retour du modèle, puis dans sa console : 

hostname -f
uname -r
systemctl --failed
apt list --upgradable
test ! -f /var/run/reboot-required

Examiner les résultats, noter date/OS/noyau dans le registre de maintenance. Après validation, arrêter proprement TEMPLATE3 : 

sudo shutdown -h now

Puis sur Saturne3 : 

qm status 506

506 correspond au template_vmid de cette recette : vérifier la valeur du YAML. Le modèle doit être arrêté avant le clonage. Ni le lanceur ni les précontrôles ne certifient automatiquement sa fraîcheur APT. Cette maintenance n’a pas été réalisée par les scripts livrés. Saturne3 et HAProxy ont leur maintenance distincte, non demandée ici. Voir PREREQUIS-OS-ET-PUBLICATION.txt et les documentations Ubuntu : Gestion des paquets et Mises à jour automatiques.

Paramètres prévus avant la création

  • Identité projet, environnement et tags : interne, client, prod ; types YAML stricts.
  • Ressources, template, stockage, IP privées/VPN/publique, passerelle et DNS.
  • Domaines principal, préprod et Matomo définitifs, sans https:// ni chemin.
  • NFS existant et droits accordés par l'administrateur du serveur.
  • Activation des vhosts distincte de l'installation des logiciels.
  • Noms SQL dédiés Matomo, sans secret dans le YAML.

Référence MERCURE3 : hostname mercure3.ajlsm.com, VPN 10.0.0.43, réseau données 192.168.123.27, publique 51.83.117.113. Matomo : mercure3-matomo.pleade.com ; préprod : mercure3-preprod.pleade.com. Ne pas conserver deux VM avec ces mêmes adresses.

Chez OVH, principal A vers 51.83.117.113, domaines secondaires CNAME vers mercure3.ajlsm.com dans la recette. Ne pas publier d'AAAA sans IPv6 opérationnel. Pour un domaine secondaire sur la même IP, réutiliser la VIP/NAT existante si elle et le filtrage traitent déjà le flux requis ; ne pas dupliquer OPNsense. Le trafic public passe par la VIP HAProxy 10.0.0.32, nœuds .30 et .31.

Préconfiguration et contrôle

modeles/projet-vierge.yaml contient des null, jamais une liste [à renseigner]. null est valide pour proxmox.vmid automatique, pas pour un champ obligatoire. Les sections métier peuvent être omises, mais doivent être complètes si présentes. exemples/mercure3-exemple.yaml prépare une recréation volontaire, pas une VM parallèle. 

./ajlsm-deploy-yaml ./modeles/projet-vierge.yaml --with-metier --output /etc/ajlsm/deploy/projets/mercure3-initial.yaml
./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3-initial.yaml --check
./ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml --plan
./ajlsm-deploy-check /etc/ajlsm/deploy/projets/mercure3-initial.yaml

Le parcours complet de l'assistant est désormais --with-metier : NFS, domaines Matomo/Apache et SQL dédiés dans le même YAML initial. Sans modèle, utiliser --new --with-metier avec un chemin inexistant. Les valeurs valides existantes sont conservées ; --review les revoit aussi. Le guide détaillé GUIDE-YAML.txt décrit les questions et les activations : Drupal seulement si vérifié, Pleade préprod désactivé en son absence, Matomo Apache false jusqu'à publication-matomo après pause externe. Le mode --with-matomo-site reste une activation MANUELLE distincte, incompatible avec --with-metier ; inutile au cycle guidé actuel. OS du modèle, DNS, OPNsense, ACME sur les deux HAProxy, Ansible/whitelist et autorisation NFS sont rappelés mais pas vérifiés ni enregistrés comme tels.

Les options individuelles restent disponibles : --with-nfs, --with-matomo, --with-apache et --with-matomo-sql ; --review revoit aussi les valeurs valides. --new crée un nouveau chemin. Les fichiers existants ne sont pas écrasés. --check et --yaml-only sont des contrôles locaux, pas une vérification d'infrastructure. Prévoir apache.matomo.activer=false pour le cycle initial ; un projet d'activation true est refusé par le cycle avant toute phase passant par Apache.

Cycle initial : dix-sept étapes

Étape Simulation / lecture Exécution
clonage --dry-run --clone
ressources --resources-dry-run --configure-resources
premier-demarrage --first-boot-dry-run --first-boot-apply
extension-racine --root-grow-dry-run --root-grow-apply
identite --system-dry-run --system-apply
netplan --network-dry-run --network-apply
activation-reseau --network-enable-dry-run --network-enable
audit-ssh --ssh-audit audit, pas de simulation distincte
securisation-ssh aucune --ssh-secure
mot-de-passe aucune --password-ajlsm
tls aucune --tls-apply
nfs --nfs-dry-run puis --nfs-check --nfs-apply
apache --apache-dry-run --apache-apply
matomo-sql --matomo-sql-dry-run --matomo-sql-prepare
tomcat-cron --scheduled-dry-run --scheduled-apply
taches-planifiees --scheduled-audit aucune modification
publication-matomo --matomo-guided-dry-run --matomo-guided

Le clone est isolé avant premier démarrage. L'extension racine suit le premier démarrage et ne doit pas être confondue avec le disque virtuel déjà agrandi. Puis identité, réseau, SSH, mot de passe et certificat interne sont traités. Les phases métier non demandées sont ignorées explicitement.

Attente réseau pendant l'isolation

Le journal MERCURE3 transmis montre wait-online en attente 120 secondes avant activation des carriers ; le réseau est ensuite online sur les deux cartes. Le lot ajoute une dispense conditionnelle liée à l'UUID pendant l'isolation, dès que QGA est disponible. Les phases first-boot et system l'installent après les confirmations et gardes ; network-enable la retire après ses contrôles puis vérifie le fonctionnement normal de wait-online avant onboot. Le repli réseau remet la dispense après réisolation. Pas de mask/disable, pas de changement Netplan optional ou de TEMPLATE3. Les simulations n'écrivent aucun fichier. Ce correctif reste à recetter sur un clone ; il ne nécessite pas de reconstruire la VM actuelle pour continuer les étapes métier. Voir CORRECTIF-WAIT-ONLINE.txt pour les deux fichiers gérés, limites et reprise. 

./ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml

Les confirmations OUI/NON, défaut NON, et saisies natives restent interactives. Pas d'arrêt entre commandes réussies ; arrêt au premier refus ou erreur. --agent-timeout est transmis aux phases, défaut 300 secondes, pas un timeout global. Après diagnostic, --from reprend l'étape incluse sans refaire les précédentes. Un --plan n'exécute rien mais ne garantit ni Proxmox ni l'infrastructure externe.

NFS : autorisation manuelle guidée

Dépôt d'exemples : 192.168.123.202:/var/data/pleade.com-data/data, point local identique, mode ro. Un autre dépôt est paramétrable ; plusieurs dépôts de MERCURE3 restent une exception manuelle. Le script affiche le fichier exports et la ligne à adapter sur Eole3, sans s'y connecter en administrateur. L'autorisation de 192.168.123.27 en ro a été réalisée dans la recette. Les autres exports et données doivent être conservés. Pas de chmod/chown récursif.

Apache, Drupal et Pleade

Six fichiers gérés sous /etc/apache2/sites-available : HTTP et TLS pour Drupal, préprod et Matomo ; fichier robots préprod séparé. Activation par symlinks selon le YAML, manifeste, sauvegarde, syntaxe candidate et reload avec tentative de restauration locale sur erreur. Une interruption brutale demande un diagnostic. Un vhost préparé n'installe pas un logiciel et ne valide pas une application. Les fichiers gérés modifiés hors déploiement provoquent un refus, pas un écrasement.

Drupal hérité a été vérifié utilisable avec MariaDB et drupal_template ; son vhost principal est actif dans la recette. Pas de personnalisation SQL Drupal dédiée dans ce lot. Pleade n'est pas installé, sa préprod reste désactivée ; pas d'appel à update.sh. Les futurs slecture et internet ne sont pas publiés.

Matomo : préparation SQL puis activation coordonnée

Base et compte locaux dédiés : matomo_mercure3, sans adoption de matomo_template. Configuration préparée root privée dans /var/lib/ajlsm-matomo-sql ; ne pas transmettre ces fichiers. En fin de cycle, publication-matomo affiche la pause externe, demande une attestation OUI/NON puis active Matomo avec le MÊME YAML. Il passe activer=true en mémoire uniquement ; le YAML initial reste intact. En mode manuel, après SQL : 

./ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3-initial.yaml --matomo-guided-dry-run
./ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3-initial.yaml --matomo-guided

L’activation coordonnée conserve Drupal/Pleade. Le mode historique reste possible : --with-matomo-site crée une copie d’activation, ensuite utilisée par --matomo-site-dry-run puis --matomo-site-apply. Ne pas utiliser --apache-apply seul pour cette transition et ne pas relancer le clonage avec la copie d'activation. Le module désactive les anciens vhosts Matomo connus, sauvegarde le cache, installe la configuration privée et active le projet avec contrôle HTTPS local. Les sauvegardes peuvent contenir des secrets.

Certificats en prérequis et pause avant activation

Recommandation : DNS puis challenge ACME stateless prêts, émettre/déployer les certificats publics en prérequis, avant même le clonage backend. Le challenge HAProxy ne dépend pas de Matomo. Une pause reste obligatoire à publication-matomo pour vérifier les certificats et le routage restreint sur LES DEUX nœuds. NON arrête proprement le cycle ; --resume reprend après préparation externe. Aucune commande ACME/Ansible n’est exécutée par le script et l’attestation humaine ne constitue pas une vérification automatisée.

Le certificat interne généré dans le clone n'est pas le certificat public. Les certificats publics sont vérifiés/générés avec acme.sh sous l'utilisateur acme sur les deux HAProxy, l'un après l'autre. Connexion hpr puis sudo -i, pas root SSH. Conserver le challenge HTTP-01 stateless avant la whitelist. Émission et déploiement Matomo ont réussi sur les deux nœuds lors de la recette. Un certificat valide pour le même domaine n'est pas à refaire parce que le backend est recréé ; revérifier validité, déploiement et renouvellement.

Ansible ajoute ACL du domaine, refus hors whitelist, redirection HTTPS et backend SNI vers 10.0.0.43:443. Matomo interne MERCURE3 : allowed_ajlsm uniquement. Pour un client, prévoir AJLSM et whitelist client selon les règles préprod. Le backend conserve ssl verify none : l'identité du backend n'est pas validée. 

ansible-playbook -i inventory ./plays/deploy.haproxy.yml --syntax-check
ansible-playbook -i inventory ./plays/deploy.haproxy.yml --limit haproxy01.ajlsm.lan --check --diff
ansible-playbook -i inventory ./plays/deploy.haproxy.yml --limit haproxy02.ajlsm.lan --check --diff

Examiner tous les diffs puis appliquer séparément en retirant --check, attendre le succès du premier nœud avant le second. Aucun lancement Ansible automatique depuis Proxmox. Le check-mode n'est pas l'application réelle. Recette transmise : deux applications réussies, validation et restart signalés, aucun failed/unreachable. Avertissement Python découvert /usr/bin/python3.10, non bloquant dans ces exécutions. Aucun changement d'interpréteur ici.

Tester HTTPS sans -k depuis l'IP autorisée puis hors whitelist. Résultats transmis : 200 avec en-tête Matomo via VPN bureau, 403 hors whitelist. Un HTTP 200 n'est pas une validation d'installation fonctionnelle.

Tâches planifiées : correction ciblée puis audit

--scheduled-audit inventorie crontabs root/ajlsm/www-data, fichiers système, noms des scripts périodiques, timers systemd et instances Tomcat. Les commandes et arguments privés ne sont pas affichés. L'audit historique et l'inventaire avant traitement confirment 13 lignes Tomcat et trois processus, sans Pleade détecté. Après cycle du 18 octobre : zéro tâche Tomcat active pour les trois instances vides ; processus déjà lancés conservés et archivage mensuel inchangé. Les tâches des autres comptes, timers utilisateurs et contenus des scripts restent hors audit. L'inventaire seul n'effectue aucune désactivation. Code 0 = inventaire obtenu, pas tâches approuvées. Rotation des logs inchangée.

La phase tomcat-cron a été autorisée pour ne pas reproduire ces tâches inutiles sur les nouveaux clones. --scheduled-dry-run affiche les lignes reconnues à commenter ; --scheduled-apply demande OUI/NON, sauvegarde la crontab ajlsm et commente ces seules lignes avec un marqueur réversible. Elle ne lance aucune commande de démarrage, arrêt ou nettoyage Tomcat. Le cycle l'exécute en étape 15, puis audite le résultat en étape 16.

Critères conservateurs : répertoire Pleade présent et entièrement vide, webapps absent d'autre application et lien pleade vers le chemin attendu, pas de contexte externe dans conf/Catalina/localhost. Une implantation non vérifiable ou un contenu partiel conserve les tâches. Une commande inconnue visant une instance vide bloque la phase, sans modification partielle. Seules les formes exactes des commandes héritées auditées sont reconnues.

Sauvegarde privée : /var/backups/ajlsm-scheduled/transaction-* ; journal : /var/lib/ajlsm-scheduled/transaction.json. Vérification identité/UUID et empreinte de la crontab avant application, relecture après installation. Restauration tentée sur erreur contrôlée si elle n'écrase pas un changement concurrent détecté. Sinon journal conservé et reprise bloquée pour examen manuel. Le verrou ne protège pas contre crontab -e dans un autre terminal : ne pas modifier simultanément les tâches ou déployer une application pendant la phase. L'interface crontab ne fournit pas de comparaison-installation atomique face aux outils extérieurs. Les @reboot des premiers démarrages du clone peuvent déjà avoir lancé Tomcat : seuls les lancements futurs sont neutralisés. Pas de réactivation automatique lors d'une installation Pleade ultérieure.

Finalisation fonctionnelle, hors déploiement piloté

L'installateur Matomo a confirmé « Tables créées » dans la recette. Création du superadministrateur, premier site, fin de l'assistant et intégration du suivi restent manuelles. Ne pas laisser un installateur inachevé ouvert durablement. Lire FINALISATION-MATOMO.txt : reprise directe tablesCreation et avertissement sur systemCheck qui supprime la configuration locale préparée en version auditée. Diagnostics applicatifs non annoncés comme faits. Ne pas partager de secrets.

Point d’arrêt et reprise depuis tout répertoire

Le nouveau lanceur conserve un journal privé sur Saturne3 dans /var/lib/ajlsm-deploy/cycles/, mode 600, historique par exécution. Il n’enregistre ni mots de passe, ni sortie complète des phases. Il suit étape courante, dernière réussite, dates UTC, codes de sortie, empreintes du YAML/lot, hôte et identité VMID/UUID de la cible. Un verrou protège ce journal, pas les interventions d’un autre administrateur.

Avec chemins absolus, depuis n’importe quel répertoire du même nœud : 

/opt/ajlsm-deploy/v1/ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml --status
/opt/ajlsm-deploy/v1/ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml --resume

--status ne contacte pas Proxmox et ne crée aucun journal. --resume reprend la première étape non réussie, avec contrôles et confirmations habituels. Une faute « ouii » à tls se reprend donc à tls sans reclonage. La reprise refuse les changements de nœud, YAML, code/ordre ou d’identité VM enregistrée. Elle ne relance pas un cycle déjà terminé. Après coupure brutale, en_cours signifie résultat inconnu : examiner les journaux transactionnels, l’état et les processus avant reprise. Le journal n’est pas une preuve de conformité permanente de l’infrastructure.

--from étape reste une reprise explicite après diagnostic, qui démarre un nouveau journal et marque les étapes antérieures ignorées, pas vérifiées. Ne pas effacer les journaux pour contourner une erreur. Les anciens lots sans journal ne permettent pas --resume rétroactif : consulter leur sortie console puis reprendre avec --from. Pour la VM actuelle, l’application de la dernière simulation Matomo n’est pas confirmée. Contrôler avant de reprendre à publication-matomo, sans clonage.

Détails de sécurité conservés de la documentation du 16 octobre

L’audit SSH lit la clé ED25519 via QEMU, vérifie son format binaire, puis compare indépendamment celle exposée par ssh-keyscan. Une divergence refuse la suite. Après concordance seulement, sauvegarde et remplacement atomique possible de /root/.ssh/known_hosts sur Saturne3 ; les autres hôtes sont conservés, y compris traitement ciblé des anciennes entrées hachées de l’IP du clone. --ssh-audit n’est donc pas entièrement sans écriture. --ssh-secure vérifie la syntaxe/effectivité et les connexions par clé avant/après reload ; le mot de passe local reste utile à sudo. --password-ajlsm utilise passwd interactif masqué ; aucun secret dans le YAML.

La personnalisation système conserve dans la VM /var/lib/ajlsm/system-personalisation/state.json et backup/. Ce journal décrit une transaction, pas le cycle global. Ne pas l’effacer pour forcer une reprise. La phase TLS vérifie le certificat interne /etc/ssl/ajlsm/server.crt, utilise si nécessaire /usr/local/sbin/ajlsm-init-tls.sh déjà présent dans le modèle, puis contrôle Apache. Cela ne valide pas les applications ou le TLS public. Le README applicatif /home/ajlsm/README ne doit pas être remplacé par le README-ajlsm-deploy de l’outil. Le document README-TEMPLATE3.txt est proposé séparément, pas installé automatiquement.

Validation YAML stricte : clés inconnues/répétées et types incorrects refusés ; environnement/tags interne, client, prod, sans doublons ; tags [] admis ; entiers positifs, mémoire minimale <= maximale, booléens true/false ; interfaces netN/ensN uniques, IPv4/CIDR, loopback /32, DNS sans préfixe. Passerelle dans le sous-réseau de son interface et distincte de la VM. Serveur, bridge et stockage sont à adapter à l’infrastructure, sans liste fermée inventée. Les sections métier sont désormais prises en charge : l’interdiction historique d’ajouter metier ne s’applique plus à ce schéma.

Manuels, reprise et validation du lot

Pages section 8 de la version 1.0.2 du 19 octobre : deploy, cycle, yaml, check, resources. Lecture locale avec man ./man8/ajlsm-deploy.8 ; sauvegarde et installation optionnelle décrites dans INSTALLATION-MANUELS.txt, sans copier les scripts. Le lancement définitif se fait dans /opt/ajlsm-deploy/v1, sans copier les programmes du nœud dans /usr/local/sbin. La commande invitée /usr/local/sbin/ajlsm-init-tls.sh reste distincte et n'est pas déplacée. Conserver le lot complet, modules et modèles, sans mélanger les versions. Une installation du lot ne remplace pas une recette complète sur Proxmox. Tests locaux sous tests/, résultats dans RAPPORT-TESTS.txt ; QGA, SQL, PHP et services simulés. Ils ne prouvent pas la réussite d'un déploiement distant. Une restauration de phase n'annule pas SQL ni les actions web ultérieures. Ne pas effacer un journal transaction.json pour forcer une reprise.

Réconciliation de la page reçue du 16 octobre et état de recette

Cette procédure remplace les indications historiques « 11 étapes », « NFS/Apache/Matomo hors cycle » et « aucun journal global ». Le nouveau lot compte 17 étapes avec publication protégée, mais la finalisation fonctionnelle Matomo reste indépendante. L’ancien man reproduit intégralement dans la page du 16 octobre n’est pas recopié ici : les cinq sources man8 de ce lot sont la référence de version, sans procédure concurrente. Les anciens chemins du 16 octobre restent des archives, pas le lot courant.

Le cycle 16 étapes du lot consolide-taches a été exécuté sur un clone recréé le 18 octobre, reprise TLS après faute de saisie incluse. Hostname et racine ext4 97 Gio confirmés. Tâches Tomcat neutralisées pour les instances vides ; les processus déjà lancés n’ont pas été arrêtés. Le correctif wait-online et le nouveau cycle 17 étapes avec journal restent à valider sur Proxmox. Les tests locaux ne sont pas une nouvelle recette distante. La capture « Tables créées » et la première activation Matomo concernent le clone antérieur : ne pas les attribuer automatiquement au clone actuel. Le succès nominal ne valide pas le repli réseau après panne.

Le modèle TEMPLATE3 n’a pas été modifié par ces scripts. Cela ne démontre pas l’absence de toute autre intervention. Sa mise à jour OS demandée est une maintenance à réaliser/valider séparément avant le prochain clonage. Aucun nettoyage serveur ni envoi SVN n’est exécuté par cette livraison.

Récupérée de "https://mediawiki.ajlsm.com/index.php?title=Déploiement_technique_d’une_VM_AJLSM&oldid=6499"