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.

Voici un exemple :

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

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.

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

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.

Man le 16/10/2026

AJLSM-DEPLOY(8)                                     Administration système                                     AJLSM-DEPLOY(8)

NOM
       ajlsm-deploy - déployer une VM Proxmox par phases contrôlées

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‐
       tions telles que --network-dry sont refusées.

CONFIRMATIONS
       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
       Le  disque  Proxmox  agrandi  par  la phase ressources ne suffit pas à agrandir le système de fichiers de l'invité.  La
       phase racine réalise growpart, pvresize et lvextend avec redimensionnement du système de fichiers.

       Topologie prise en charge : racine ext4, PV /dev/sda3, partition terminale parmi trois partitions de /dev/sda, un  seul
       PV  et  un seul LV. La taille du disque doit correspondre au YAML. Les outils doivent déjà être présents ; aucun paquet
       n'est installé par cette phase.

       Si la partition est déjà agrandie, le code saute growpart et poursuit le traitement LVM. Si etendre_volume_racine  vaut
       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)
~

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.