Déploiement technique d’une VM AJLSM

AJLSM-DEPLOY — Déploiement automatisé des VM Proxmox

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.

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

1. Périmètre et résultat de la recette

Le cycle technique a été exécuté sur MERCURE3 sans erreur signalée. Les vérifications finales transmises confirment :

• connexion SSH avec le compte ajlsm ;
• élévation sudo avec le mot de passe défini pendant le cycle ;
• 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.

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.

2. Où exécuter les commandes

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

/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

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.

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. 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.

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.

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.

5. Préparer et valider le YAML

Sur Saturne3, se placer dans le lot de recette :

cd /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle

5.1. Vérifier un fichier existant sans le modifier

./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3.yaml --check

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.

5.2. Compléter le modèle vierge

Après extraction du présent lot documentaire :

./ajlsm-deploy-yaml \
  /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-documentation/projet-vierge.yaml \
  --output /root/ajlsm-deploy/recettes/20261016/nouveau-projet.yaml

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.

5.3. Créer sans modèle

./ajlsm-deploy-yaml /root/ajlsm-deploy/recettes/20261016/nouveau-projet.yaml --new

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.

5.4. Revoir un projet renseigné

./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3.yaml --review \
  --output /root/ajlsm-deploy/recettes/20261016/mercure3-relecture.yaml

• Entrée conserve une valeur existante valide.
• ANNULER, Ctrl-C ou fin d’entrée abandonnent sans enregistrer.
• Tags et DNS sont saisis séparés par des virgules ; [] ou aucun signifie tags vides.
• Saisir auto ou null pour un VMID automatique.
• Après une incohérence, donner le chemin du champ à corriger ; ? affiche les chemins.
• Le résumé complet est présenté avant confirmation OUI/NON d’enregistrement.

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.

5.5. Préparatifs externes

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.

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.

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é :

./ajlsm-deploy-check /chemin/vers/projet.yaml

6. Afficher le plan puis lancer le cycle

6.1. Plan sans exécution

./ajlsm-deploy-cycle /chemin/vers/projet.yaml --plan

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.

6.2. Cycle réel pour une nouvelle VM

./ajlsm-deploy-cycle /chemin/vers/projet.yaml

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.

N°	Étape	Commande réelle	Simulation facultative
1	Clonage	--clone	--dry-run
2	Ressources	--configure-resources	--resources-dry-run
3	Premier démarrage isolé	--first-boot-apply	--first-boot-dry-run
4	Extension partition/LVM/ext4	--root-grow-apply	--root-grow-dry-run
5	Identité système	--system-apply	--system-dry-run
6	Préparation Netplan	--network-apply	--network-dry-run
7	Activation réseau	--network-enable	--network-enable-dry-run
8	Audit SSH	--ssh-audit	Aucune option dédiée
9	Sécurisation SSH	--ssh-secure	Aucune option dédiée
10	Mot de passe ajlsm	--password-ajlsm	Aucune option dédiée
11	Certificat TLS interne	--tls-apply	Aucune option dédiée

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 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.

Le certificat TLS interne ne constitue pas, à lui seul, une configuration des applications du projet ou un certificat publiquement reconnu.

6.3. Mode manuel

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.

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.

7. Erreur, annulation et reprise

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.

./ajlsm-deploy-cycle /chemin/vers/projet.yaml --from extension-racine

--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.

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.

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.

8. Vérifications finales

Sur Saturne3, avec le VMID réellement annoncé au clonage :

qm list
qm status VMID
qm config VMID

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.

Depuis Saturne3, ouvrir la connexion et attendre l’invite de la VM :

ssh ajlsm@10.0.0.43

Dans MERCURE3, saisir sudo -i, attendre l’authentification et l’invite root, puis :

hostname
lsblk
df -hT /
ip -br addr
ip route
resolvectl status

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.

9. Reconstruire MERCURE3 ultérieurement

1. Conserver le fichier mercure3-reference.yaml, le lot de scripts validé et l’identification du modèle utilisé.
2. Comparer la référence au YAML effectivement utilisé avant reconstruction ; actualiser les changements d’infrastructure.
3. Identifier et sauvegarder les données à conserver : le YAML n’est pas une sauvegarde de VM.
4. 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.
5. Contrôler DNS, OPNsense, Ansible et les réservations d’IP. Ne pas laisser deux VM actives avec les mêmes adresses.
6. 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.
7. Relever le nouveau VMID et effectuer les vérifications finales.

On retrouve ainsi les paramètres de la VM, sans chercher à reproduire ses anciennes identités techniques.

10. Protections et détails techniques

10.1. Isolation, identité et journal de personnalisation

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.

La personnalisation système conserve dans l’invité :

/var/lib/ajlsm/system-personalisation/state.json
/var/lib/ajlsm/system-personalisation/backup/

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.

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.

10.2. Audit SSH : lecture dans la VM, écriture possible sur Saturne3

La phase --ssh-audit commence par synchroniser l’identité SSH :

1. Lire la clé publique /etc/ssh/ssh_host_ed25519_key.pub dans la VM via l’agent QEMU.
2. Valider le format ED25519 et sa structure binaire attendue.
3. Lire indépendamment la clé exposée sur le réseau avec ssh-keyscan -T 8 -t ed25519.
4. Comparer les clés : une divergence, une absence ou un format invalide provoque un refus.
5. 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.
6. Contrôler les connexions par clé, les clés autorisées, sudo et l’état du compte ajlsm.

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/.

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.

10.3. Sécurisation SSH et mot de passe

--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.

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.

10.4. Certificat TLS interne et Apache

--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.

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.

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 :

./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

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 :

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

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 :

man -w ajlsm-deploy
man 8 ajlsm-deploy

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.

12. État des validations et limites

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.

13. Réconciliation avec la page du 15 octobre

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.

Le présent document remplace les indications opérationnelles anciennes :

• confirmations CLONER/APPLIQUER/DEMARRER remplacées par OUI/NON ;
• parcours manuel seul remplacé par le choix entre mode manuel et cycle interactif ;
• liste des étapes incluant l’extension racine, SSH, mot de passe et TLS ;
• extension racine et cycle complet désormais validés sur la recette du 16 octobre ;
• suggestions manuelles affichant les deux commandes disponibles, sans oublier l’extension racine ;
• création et relecture du YAML par l’assistant, sans écraser l’original ;
• ajout du modèle vierge et de la référence MERCURE3 renseignée ;
• séparation explicite des scripts installés, du lot de recette, du manuel historique et de la future installation.

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.

14. Suites prévues

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.

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.