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

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

1. Présentation

ajlsm-deploy est un outil Python permettant de déployer une nouvelle machine virtuelle Proxmox à partir de la VM modèle TEMPLATE3.

L'objectif est de standardiser les déploiements AJLSM tout en conservant un contrôle humain à chaque étape.

Le script permet notamment :

   Le clonage complet d'une VM modèle.
   La configuration des ressources CPU, RAM et disque.
   Le premier démarrage avec les interfaces réseau isolées.
   La personnalisation du hostname et des identifiants système.
   La configuration réseau Netplan.
   La vérification de la disponibilité des adresses IPv4.
   L'activation contrôlée du réseau.
   La configuration du démarrage automatique.
   La vérification des opérations effectuées. 

Chaque phase est indépendante.

Aucune phase suivante n'est exécutée automatiquement.

L'administrateur décide de poursuivre après examen des résultats.

2. Infrastructure de référence

2.1. Serveur Proxmox

Élément Valeur Hyperviseur Saturne3 Système Proxmox VE 9.2.1 lors de la recette VM modèle TEMPLATE3 VMID modèle 506 Stockage local-zfs Script principal /usr/local/sbin/ajlsm-deploy Répertoire des projets /etc/ajlsm/deploy/projets/

2.2. Scripts

Le script principal est installé dans :

/usr/local/sbin/ajlsm-deploy

Les scripts complémentaires utilisés lors du développement sont :

ajlsm-deploy-check ajlsm-deploy-resources

Ils assurent respectivement les précontrôles et la configuration des ressources.

Attention : vérifier leur emplacement et leur version lors de toute maintenance. La recette finale a confirmé l'installation du script principal, mais ne constitue pas à elle seule un inventaire des versions de ses dépendances.

2.3. Sauvegarde de la version précédente

Avant l'installation de la version actuelle, une sauvegarde a été créée :

/usr/local/sbin/ajlsm-deploy.bak-20261015

La nouvelle version a été installée avec :

install -o root -g root -m 750 \

 /root/ajlsm-deploy-review/ajlsm-deploy-network-enable \
 /usr/local/sbin/ajlsm-deploy

La syntaxe Python et l'identité des deux fichiers ont été vérifiées :

python3 -m py_compile /usr/local/sbin/ajlsm-deploy

cmp /usr/local/sbin/ajlsm-deploy \

   /root/ajlsm-deploy-review/ajlsm-deploy-network-enable

3. Prérequis

3.1. Sur l'hyperviseur

Les éléments suivants doivent être disponibles :

   Python 3.
   PyYAML.
   Les outils Proxmox qm, pvesh et pvesm.
   La commande ip.
   Les scripts AJLSM nécessaires.
   Un stockage Proxmox opérationnel.
   Les bridges réseau définis dans le YAML. 

Les commandes sont exécutées avec les privilèges root sur le nœud Proxmox concerné.

3.2. Dans TEMPLATE3

La VM modèle doit disposer :

   D'un système Linux compatible avec les scripts.
   De Python 3.
   De systemd.
   De l'agent QEMU.
   De Netplan pour la configuration réseau.
   Du service ajlsm-clone-init.
   Des outils nécessaires à la personnalisation système. 

TEMPLATE3 doit être arrêtée avant le clonage.

3.3. Vérification du modèle

qm status 506 qm config 506

Le résultat attendu est notamment :

status: stopped

L'agent QEMU doit être activé dans la configuration Proxmox.

4. Configuration YAML

Chaque projet possède son propre fichier YAML.

Exemple :

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

4.1. Exemple MERCURE3

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

4.2. Attribution automatique du VMID

Le paramètre :

vmid: null

indique que le VMID doit être déterminé automatiquement par Proxmox.

Le script ne doit pas conserver un ancien VMID comme identifiant permanent du projet.

Lors de la recette du 15 octobre 2026, Proxmox a réattribué le VMID 505 après suppression de l'ancien clone.

Le VMID proposé lors d'une simulation n'est pas réservé.

Il peut donc changer avant le clonage effectif.

4.3. Réutilisation pour un nouveau projet

Pour déployer une autre VM :

   Copier le fichier YAML d'exemple.
   Modifier le code et le nom du projet.
   Modifier le hostname.
   Adapter CPU, RAM et disque.
   Définir les interfaces et les adresses IP.
   Vérifier les bridges Proxmox.
   Conserver vmid: null pour une attribution automatique.
   Exécuter les précontrôles. 

Le nom du fichier YAML n'est pas imposé par le script.

5. Déploiement d'une nouvelle VM (recette initiale)

Attention : la procédure ci-dessous décrit les sept phases de la première recette. La procédure actualisée comprend l’extension racine et la postconfiguration ; voir section 14.2 avant tout nouveau déploiement.

La procédure comporte sept phases :

   Clonage.
   Configuration des ressources.
   Premier démarrage isolé.
   Personnalisation système.
   Préparation Netplan.
   Vérification de l'activation réseau.
   Activation réseau. 

Chaque phase comporte une simulation lorsque l'option correspondante est disponible.

5.1. Phase 1 — Simulation du clonage

ajlsm-deploy \

 /etc/ajlsm/deploy/projets/mercure3.yaml \
 --dry-run

Cette commande vérifie :

   La validité du YAML.
   La présence de TEMPLATE3.
   L'arrêt de la VM modèle.
   La présence de l'agent QEMU.
   Le stockage Proxmox.
   Les ressources demandées.
   Les bridges réseau.
   Les paramètres IP.
   La disponibilité d'un VMID. 

Exemple de résultat :

BILAN

Erreurs : 0 Avertissements : 1 Précontrôles satisfaits. Aucune modification effectuée.

PLAN DE CLONAGE

Source  : VM 506 Clone  : MERCURE3 VMID  : 505 Stockage : local-zfs Type  : clone complet Réseau  : isolation avant premier démarrage Onboot  : désactivé Démarrage: aucun

[DRY-RUN] Aucune modification effectuée.

L'avertissement concernant la disponibilité réelle des adresses IP est normal à ce stade : le contrôle réseau actif intervient ultérieurement.

5.2. Phase 1 — Clonage effectif

ajlsm-deploy \

 /etc/ajlsm/deploy/projets/mercure3.yaml \
 --clone

Dans la version validée, le script demande :

Pour créer la VM 505, saisir CLONER :

La réponse attendue est :

CLONER

Le script effectue ensuite :

   Le clonage complet.
   L'isolation des interfaces.
   La vérification des adresses MAC.
   La vérification de l'arrêt de la VM.
   La désactivation du démarrage automatique. 

Résultat attendu :

CLONAGE TERMINÉ

VM 505 : MERCURE3 État : arrêtée, réseau isolé, onboot=0 Aucun démarrage effectué. Prochaine phase : ressources CPU/RAM/disque.

Ne pas démarrer manuellement la VM à ce stade.

5.3. Phase 2 — Simulation des ressources

ajlsm-deploy \

 /etc/ajlsm/deploy/projets/mercure3.yaml \
 --resources-dry-run

Exemple :

RESSOURCES : MERCURE3 (VM 505)

[OK] VM arrêtée, réseau isolé, onboot=0 [MODIFICATION] CPU : 2 x 4 -> 1 x 8 [MODIFICATION] RAM : 8192 -> 24576 Mio ; balloon : non défini -> 16384 Mio [MODIFICATION] Disque scsi0 : 32 -> 100 Gio

[DRY-RUN] Aucune modification effectuée.

5.4. Phase 2 — Application des ressources

ajlsm-deploy \

 /etc/ajlsm/deploy/projets/mercure3.yaml \
 --configure-resources

Confirmation actuelle :

Pour appliquer les ressources à la VM 505, saisir APPLIQUER :

Répondre :

APPLIQUER

Résultat attendu :

[OK] Ressources configurées et vérifiées. [OK] VM toujours arrêtée et réseau isolé.

Le disque virtuel est agrandi à la taille demandée.

Important : l'agrandissement du disque Proxmox et celui du système de fichiers invité sont deux opérations distinctes. Le YAML prévoit une extension du volume racine, mais la sortie de cette phase confirme uniquement la configuration des ressources Proxmox.

5.5. Phase 3 — Simulation du premier démarrage

ajlsm-deploy \

 /etc/ajlsm/deploy/projets/mercure3.yaml \
 --first-boot-dry-run

Exemple :

PREMIER DÉMARRAGE : MERCURE3 (VM 505)

[OK] Démarrage automatique désactivé, interfaces isolées État actuel : stopped [DRY-RUN] Démarrer la VM 505, réseau isolé [DRY-RUN] Attendre la réponse de l'agent QEMU (max. 300s) [DRY-RUN] Vérifier ajlsm-clone-init et l'UUID enregistré

5.6. Phase 3 — Premier démarrage réel

ajlsm-deploy \

 /etc/ajlsm/deploy/projets/mercure3.yaml \
 --first-boot-apply

Confirmation actuelle :

Pour démarrer la VM 505 avec le réseau isolé, saisir DEMARRER :

Répondre :

DEMARRER

Le script :

   Démarre la VM avec ses interfaces isolées.
   Attend la disponibilité de l'agent QEMU.
   Vérifie le service ajlsm-clone-init.
   Contrôle l'UUID matériel du clone. 

Exemple :

[OK] Agent QEMU disponible [OK] ajlsm-clone-init terminé avec succès [OK] UUID matériel conforme [OK] Phase de premier démarrage validée ; interfaces toujours isolées

Particularité : attente réseau au démarrage

Lors de la recette, la console Proxmox a affiché :

Job systemd-networkd-wait-online.service/start running

Le démarrage s'est poursuivi après environ 60 secondes.

Cette attente est cohérente avec l'isolation volontaire des interfaces réseau.

Elle n'a pas empêché l'agent QEMU et ajlsm-clone-init de fonctionner.

Une amélioration ultérieure de TEMPLATE3 pourra être étudiée pour éviter cette attente inutile pendant les phases isolées.

5.7. Phase 4 — Simulation de personnalisation système

ajlsm-deploy \

 /etc/ajlsm/deploy/projets/mercure3.yaml \
 --system-dry-run

Cette phase prépare :

   La sauvegarde des fichiers hostname et hosts.
   La sauvegarde des identifiants machine-id.
   La génération d'une nouvelle identité système.
   Le redémarrage isolé.
   Les contrôles après redémarrage. 

Exemple :

État de reprise : nouvelle transaction

[DRY-RUN] Sauvegarder hostname, hosts et les deux machine-id dans l'invité [DRY-RUN] Préparer une identité aléatoire persistante, puis redémarrer isolé [DRY-RUN] Vérifier boot_id, identité PID1, hostname, hosts et isolation

5.8. Phase 4 — Personnalisation système

ajlsm-deploy \

 /etc/ajlsm/deploy/projets/mercure3.yaml \
 --system-apply

Confirmation :

Cible : VM505 — mercure3.ajlsm.com Cette opération modifiera l’identité système et redémarrera la VM avec le réseau isolé. Confirmer (OUI/NON) :

Répondre :

oui

Le script personnalise l'identité système puis redémarre la VM.

Résultat obtenu lors de la recette :

[ACTION] Identité disque préparée ; identité active non encore validée [OK] Agent QEMU disponible [OK] ajlsm-clone-init terminé avec succès [OK] Nouveau démarrage et identité active vérifiés ; VM505 toujours isolée

Journal de personnalisation

Les informations de transaction sont conservées dans l'invité :

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

Ces éléments permettent au script de reconnaître une personnalisation déjà effectuée ou une transaction interrompue.

Ne pas supprimer manuellement ces fichiers pour relancer une personnalisation.

En cas d'interruption, conserver la VM isolée et examiner les résultats des commandes dry-run avant toute reprise.

5.9. Phase 5 — Simulation de la configuration réseau

ajlsm-deploy \

 /etc/ajlsm/deploy/projets/mercure3.yaml \
 --network-dry-run

Le script vérifie les paramètres réseau du YAML.

Exemple :

Cible : MERCURE3 VM505 ; reseau Proxmox isole

 ens18: 10.0.0.43/24
 ens19: 192.168.123.27/24
 lo: 51.83.117.113/32 ; passerelle: 10.0.0.4 (ens18) ; DNS: 10.0.0.4

[DRY-RUN] Sauvegarder le Netplan initial, ecrire la configuration et executer netplan generate [DRY-RUN] Aucune modification ni activation reseau

5.10. Phase 5 — Application de Netplan

ajlsm-deploy \

 /etc/ajlsm/deploy/projets/mercure3.yaml \
 --network-apply

Confirmation :

Cette operation remplace Netplan dans l'invite, sans activer les interfaces Proxmox. Confirmer (OUI/NON) :

Répondre :

oui

Le script :

   Sauvegarde la configuration Netplan initiale.
   Écrit la configuration du projet.
   Exécute netplan generate.
   Vérifie que les interfaces Proxmox restent isolées. 

Résultat obtenu :

[OK] Netplan ecrit et netplan generate valide : {"changed": true, "backup": true} [OK] VM505 toujours isolee ; aucune activation des liens

Important : cette phase ne connecte pas les interfaces réseau.

5.11. Phase 6 — Simulation de l'activation réseau

ajlsm-deploy \

 /etc/ajlsm/deploy/projets/mercure3.yaml \
 --network-enable-dry-run

Cette commande effectue notamment :

   La vérification de l'agent QEMU.
   La vérification du service ajlsm-clone-init.
   La vérification de l'identité de la VM.
   La validation de Netplan.
   Le contrôle ARP des adresses IPv4.
   La vérification de l'isolation réseau. 

Exemple :

[OK] ARP DAD 10.0.0.43 sur vmbr2 (aucune reponse) [OK] ARP DAD 192.168.123.27 sur vmbr1 (aucune reponse) [OK] VM505 UUID conforme, clone et Netplan valides, reseau isole

[DRY-RUN] Aucune modification. Activation puis controle et repli si erreur.

Contrôle ARP DAD

ARP DAD signifie Address Conflict Detection.

Le script recherche une éventuelle réponse ARP indiquant qu'une adresse IPv4 est déjà utilisée sur le réseau.

L'absence de réponse est nécessaire pour poursuivre, mais ne constitue pas une garantie absolue d'absence de conflit.

Il convient donc de vérifier également l'attribution des adresses dans l'inventaire réseau AJLSM.

5.12. Phase 7 — Activation du réseau

ajlsm-deploy \

 /etc/ajlsm/deploy/projets/mercure3.yaml \
 --network-enable

Confirmation :

Activer le reseau de cette VM (OUI/NON) :

Répondre :

oui

Le script vérifie une nouvelle fois la disponibilité des adresses IPv4 avant l'activation.

Il contrôle ensuite :

   Les adresses IPv4.
   L'adresse loopback.
   La route par défaut.
   La configuration DNS.
   La réponse de la passerelle.
   Le démarrage automatique conformément au YAML. 

Résultat obtenu lors de la recette :

[OK] ARP DAD 10.0.0.43 sur vmbr2 (aucune reponse) [OK] ARP DAD 192.168.123.27 sur vmbr1 (aucune reponse) [OK] Adresses, loopback, route, DNS et ping passerelle valides [OK] VM505 : reseau actif et controle, onboot conforme au YAML

Le script prévoit un mécanisme de repli en cas d'échec de l'activation réseau.

Limite de la recette : le chemin nominal a été validé deux fois, mais le repli sur erreur n'a pas encore été testé en situation réelle.

6. Vérifications finales

6.1. État de la VM

qm status 505

Résultat attendu :

status: running

6.2. Configuration Proxmox

qm config 505

Vérifier notamment :

   Le nom MERCURE3.
   Les 8 vCPU.
   La mémoire de 24576 Mio.
   Le balloon de 16384 Mio.
   Le disque scsi0 de 100 Go.
   Les deux interfaces réseau actives.
   Le démarrage automatique. 

Contrôle ciblé :

qm config 505 | grep -E '^(name|net[0-9]+|onboot):'

Résultat attendu :

name: MERCURE3 net0: ... link_down=0 net1: ... link_down=0 onboot: 1

6.3. Vérification du réseau dans l'invité

Lorsque nécessaire, utiliser la console Proxmox ou l'agent QEMU.

Exemples de commandes dans la VM :

hostnamectl

ip -br addr

ip route

resolvectl status

systemctl status qemu-guest-agent --no-pager

6.4. Vérification du volume racine

Le disque virtuel de 100 Go ne garantit pas, à lui seul, que le volume racine utilise tout cet espace.

Vérifier dans l'invité :

lsblk

df -hT /

pvs

vgs

lvs

Les trois dernières commandes concernent les installations utilisant LVM.

Adapter les contrôles au partitionnement réel de TEMPLATE3.

7. Sécurité et principes de fonctionnement

7.1. Isolation réseau

La VM est clonée et démarrée avec ses interfaces réseau déconnectées au niveau Proxmox.

Cette précaution évite notamment que le clone utilise temporairement les adresses réseau du modèle.

Le réseau n'est activé qu'après :

   L'initialisation du clone.
   La personnalisation de son identité système.
   La préparation de Netplan.
   La vérification de la disponibilité des adresses IP. 

7.2. Contrôle de l'identité

Le script utilise l'identité de la VM Proxmox et son UUID matériel pour vérifier qu'il agit sur la bonne cible.

Cette protection est particulièrement importante lorsque le VMID est attribué automatiquement.

7.3. Confirmations

Les opérations modifiant la VM nécessitent une confirmation.

Dans la version actuellement installée, les confirmations ne sont pas encore totalement uniformisées.

Certaines phases demandent :

CLONER APPLIQUER DEMARRER

D'autres utilisent :

Confirmer (OUI/NON) :

Il faut respecter la confirmation affichée par la version exécutée.

7.4. Simulations

Les commandes dry-run permettent d'examiner la cible et les modifications prévues.

Elles ne doivent pas être considérées comme une garantie absolue que l'application réussira.

L'état de Proxmox, de la VM ou du réseau peut évoluer entre la simulation et l'exécution.

7.5. Reprise après incident

En cas d'erreur :

   Ne pas poursuivre automatiquement avec la phase suivante.
   Examiner la sortie complète du script.
   Vérifier l'état réel de la VM.
   Conserver les journaux et sauvegardes.
   Vérifier l'isolation réseau avant toute reprise. 

Ne pas supprimer les fichiers de transaction de personnalisation pour forcer une nouvelle exécution.

8. Tableau récapitulatif des commandes (version de la recette initiale)

La liste complète actuelle est en section 14.2. Phase Simulation Application Clonage --dry-run --clone Ressources --resources-dry-run --configure-resources Premier démarrage --first-boot-dry-run --first-boot-apply Système --system-dry-run --system-apply Configuration réseau --network-dry-run --network-apply Activation réseau --network-enable-dry-run --network-enable

Toutes les commandes reçoivent le même fichier YAML.

Exemple :

ajlsm-deploy \

 /etc/ajlsm/deploy/projets/mercure3.yaml \
 --OPTION

Remplacer OPTION par le mode souhaité.

9. Maintenance

9.1. Vérification de la syntaxe

python3 -m py_compile /usr/local/sbin/ajlsm-deploy

9.2. Affichage des options

ajlsm-deploy --help

9.3. Sauvegarde avant modification

Avant toute mise à jour :

cp -a /usr/local/sbin/ajlsm-deploy \

 /usr/local/sbin/ajlsm-deploy.bak-$(date +%Y%m%d-%H%M%S)

Si les scripts complémentaires sont modifiés, les sauvegarder également.

9.4. Restauration de la version précédente

La version sauvegardée le 15 octobre 2026 peut être restaurée avec :

install -o root -g root -m 750 \

 /usr/local/sbin/ajlsm-deploy.bak-20261015 \
 /usr/local/sbin/ajlsm-deploy

Attention : cette version ne possède pas nécessairement toutes les fonctions de la version actuelle.

Vérifier la compatibilité avec les scripts complémentaires avant toute restauration.

10. Améliorations prévues (état historique à l’issue de la première recette)

Note 15/10/2026 : les paragraphes 10.1 à 10.4 ci-dessous sont conservés comme historique. Les confirmations OUI/NON, les suggestions de commandes, l’aide intégrée et le manuel système sont désormais présents. Voir section 14.

Les améliorations suivantes ont été décidées à l'issue de la recette.

Elles ne sont pas encore intégrées dans la version installée.

10.1. Uniformisation des confirmations

Toutes les phases utiliseront :

Confirmer (oui/non) :

Comportement souhaité :

   oui : exécuter.
   non : annuler.
   Réponse vide : annuler.
   Autre réponse : annuler. 

Les majuscules et minuscules devront être acceptées.

10.2. Affichage des commandes suivantes

Après chaque phase réussie, le script proposera les commandes permettant de poursuivre.

Exemple :

================================================

[OK] RESSOURCES CONFIGURÉES

================================================

VM : 505 (MERCURE3)

PROCHAINE ÉTAPE : PREMIER DÉMARRAGE

1. Simulation :

  ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml \
    --first-boot-dry-run

2. Application :

  ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml \
    --first-boot-apply

================================================

Ces commandes seront uniquement affichées, jamais exécutées automatiquement.

10.3. Aide intégrée

Améliorer :

ajlsm-deploy --help

L'aide devra être organisée par phases et rédigée en français.

10.4. Manuel système

Créer une page de manuel accessible avec :

man ajlsm-deploy

Elle devra présenter :

   Les prérequis.
   La syntaxe des commandes.
   Le format YAML.
   Les différentes phases.
   Les contrôles de sécurité.
   Les procédures de reprise.
   Les exemples d'utilisation. 

10.5. Optimisation de TEMPLATE3

Étudier l'attente de 60 secondes observée lors du premier démarrage isolé.

Vérifier si systemd-networkd-wait-online est nécessaire et, le cas échéant, adapter son comportement sans perturber les dépendances réseau.

11. Fichiers de développement et nettoyage

Le répertoire utilisé pour la recette est :

/root/ajlsm-deploy-review/

Il contient notamment :

ajlsm-deploy ajlsm-deploy-check ajlsm-deploy-resources ajlsm-deploy-network-enable INSTRUCTIONS-TEST.txt

Le fichier INSTRUCTIONS-TEST.txt correspond à une ancienne phase de développement.

Il ne décrit pas l'ensemble des fonctionnalités réseau désormais disponibles.

Il doit donc être considéré comme obsolète.

Après vérification et archivage éventuel, il pourra être supprimé :

rm /root/ajlsm-deploy-review/INSTRUCTIONS-TEST.txt

Ne pas supprimer les autres fichiers de développement tant que leur rôle et leur emplacement définitif n'ont pas été vérifiés.

12. Historique des validations

Date Opération Résultat 15/10/2026 Installation du script avec activation réseau Validée 15/10/2026 Premier déploiement MERCURE3 Validé 15/10/2026 Suppression du premier clone Effectuée 15/10/2026 Second clonage complet depuis TEMPLATE3 Validé 15/10/2026 Configuration CPU/RAM/disque Validée 15/10/2026 Premier démarrage isolé Validé 15/10/2026 Personnalisation système Validée 15/10/2026 Configuration Netplan Validée 15/10/2026 Contrôle ARP des adresses IPv4 Validé 15/10/2026 Activation réseau et contrôles Validée À réaliser Test du repli automatique sur échec réseau Non testé À réaliser Harmonisation des confirmations et aide intégrée Non réalisée

13. Conclusion

La procédure de déploiement AJLSM a été validée par deux déploiements successifs de MERCURE3.

Le second déploiement a été effectué depuis une VM modèle arrêtée, après suppression du premier clone.

Toutes les phases ont été exécutées successivement avec leurs contrôles.

Le réseau a été activé uniquement après personnalisation du système et vérification de sa configuration.

Le fonctionnement nominal de la chaîne de déploiement est validé.

Les principaux travaux restants concernent l'ergonomie, la documentation intégrée, la vérification de l'extension du volume racine et les essais du mécanisme de repli réseau. Catégories :

   InfrastructureProxmoxDéploiementAJLSMAJLSM-DEPLOY — Déploiement automatisé des VM Proxmox

14. Actualisation technique du 15 octobre 2026

14.1. Périmètre et emplacement des fichiers

Cette section complète les treize sections historiques précédentes. Elle reflète les fonctions documentées dans l'aide de la version courante et les corrections testées le 15 octobre 2026. Elle ne constitue pas une validation d'une nouvelle recette complète.

Élément	Emplacement / valeur
Hyperviseur	Saturne3 (Proxmox VE)
Modèle	TEMPLATE3, VMID 506
VM de recette	MERCURE3, VMID 505 (ne pas supposer que 505 sera réattribué)
Programme principal	/usr/local/sbin/ajlsm-deploy
Extension racine	/usr/local/sbin/ajlsm_deploy_rootgrow.py
Postconfiguration	/usr/local/sbin/ajlsm_deploy_postconfig.py
Configurations	/etc/ajlsm/deploy/projets/
README d'exploitation	/usr/local/sbin/README-ajlsm-deploy
Manuel système	/usr/local/man/man8/ajlsm-deploy.8 ; man 8 ajlsm-deploy
Dossier de revue	/root/ajlsm-deploy-review/
Sauvegardes des correctifs	/root/ajlsm-deploy-review/correctifs-20261015/

Les programmes autonomes ajlsm-deploy-check et ajlsm-deploy-resources figurent également dans le manuel. Leur présence et leur version effectives sont à vérifier avant toute intervention.

Le README situé dans /home/ajlsm/README sur TEMPLATE3 et hérité par MERCURE3 est le README applicatif Pleade/Drupal. Il ne doit pas être remplacé par le README de l'outil de déploiement.

La VM 515 n'appartient pas à cette recette et ne doit pas être modifiée.

14.2. Ordre actuel des phases

Toutes les commandes suivantes sont à exécuter une par une, sur Saturne3, avec les droits root. Aucune commande suggérée par l'outil n'est exécutée automatiquement. Ne jamais enchaîner les phases sans examiner les résultats.

PROJET=/etc/ajlsm/deploy/projets/mercure3.yaml

# 1. Clonage
ajlsm-deploy "$PROJET" --dry-run
ajlsm-deploy "$PROJET" --clone

# 2. Ressources Proxmox
ajlsm-deploy "$PROJET" --resources-dry-run
ajlsm-deploy "$PROJET" --configure-resources

# 3. Premier démarrage isolé
ajlsm-deploy "$PROJET" --first-boot-dry-run
ajlsm-deploy "$PROJET" --first-boot-apply

# 4. Extension du volume racine
ajlsm-deploy "$PROJET" --root-grow-dry-run
ajlsm-deploy "$PROJET" --root-grow-apply

# 5. Identité système
ajlsm-deploy "$PROJET" --system-dry-run
ajlsm-deploy "$PROJET" --system-apply

# 6. Préparation Netplan (réseau encore isolé)
ajlsm-deploy "$PROJET" --network-dry-run
ajlsm-deploy "$PROJET" --network-apply

# 7. Activation réseau
ajlsm-deploy "$PROJET" --network-enable-dry-run
ajlsm-deploy "$PROJET" --network-enable

# 8. Audit SSH et synchronisation de l'identité SSH
ajlsm-deploy "$PROJET" --ssh-audit

# 9. Durcissement SSH et contrôle
ajlsm-deploy "$PROJET" --ssh-secure
ajlsm-deploy "$PROJET" --ssh-audit

# 10. Mot de passe du compte ajlsm
ajlsm-deploy "$PROJET" --password-ajlsm

# 11. Certificat TLS interne
ajlsm-deploy "$PROJET" --tls-apply

Le choix de la phase est exclusif. Les simulations proposent l'application correspondante ; les succès proposent la simulation suivante. Le script n'exécute jamais la suggestion.

14.3. Extension de la partition, de LVM et d'ext4

La phase --configure-resources agrandit le disque virtuel Proxmox, mais n'agrandit pas à elle seule le volume racine du système invité. L'extension intervient après le premier démarrage isolé et avant la personnalisation système.

• --root-grow-dry-run : vérification sans écriture de la topologie, du disque, de la partition terminale, du volume physique, du volume logique et du système de fichiers.
• --root-grow-apply : après confirmation, exécution de growpart /dev/sda 3, pvresize /dev/sda3 et lvextend -r -l +100%FREE sur le LV racine.

Limitation de sécurité : la procédure est limitée à la topologie contrôlée de TEMPLATE3 : /dev/sda3, un unique PV, un unique LV racine et ext4. Une autre topologie doit être refusée. Aucun paquet ne doit être installé pendant cette phase.

Contrôles manuels possibles dans l'invité :

lsblk
df -hT /
pvs
vgs
lvs

Le 15 octobre 2026, la compilation du module a été validée. L'extension doit encore être confirmée au cours d'une recette intégrale avec la version actuelle.

14.4. Identité système et préparation du réseau

Les phases --system-dry-run et --system-apply personnalisent le hostname, /etc/hosts et le machine-id, en respectant le journal de reprise. La VM reste isolée. Le journal de transaction de l'invité est conservé sous /var/lib/ajlsm/system-personalisation/ ; ne pas le supprimer pour forcer une reprise.

--network-dry-run et --network-apply préparent Netplan et vérifient netplan generate sans activer les interfaces Proxmox.

--network-enable-dry-run vérifie l'identité et la configuration, puis recherche des réponses ARP sur les adresses des interfaces. Cette simulation émet des paquets ARP : elle ne modifie pas la configuration, mais n'est pas passive sur le réseau. L'absence de réponse ARP ne prouve pas qu'une adresse est libre.

--network-enable active les liens, contrôle adresses, loopback, route, DNS et passerelle, puis applique le paramètre de démarrage automatique du YAML. Le mécanisme de repli vers l'isolation en cas d'échec doit encore faire l'objet d'un essai réel sur une VM dédiée.

14.5. Audit SSH et vérification indépendante de la clé ED25519

L'audit --ssh-audit a été complété par une synchronisation de l'identité SSH de la VM avant les vérifications d'accès.

1. Le programme résout le VMID cible à partir du projet et de Proxmox.
2. Il lit la clé publique d'hôte /etc/ssh/ssh_host_ed25519_key.pub dans l'invité via l'agent QEMU.
3. Il vérifie le format de la clé ED25519, notamment sa structure binaire attendue.
4. Il interroge indépendamment le service SSH exposé sur le réseau à l'aide de ssh-keyscan -T 8 -t ed25519.
5. Il compare les deux clés. Une clé absente, malformée ou différente entraîne un refus sans remplacement de known_hosts.
6. En cas de concordance, il sauvegarde /root/.ssh/known_hosts sur Saturne3, retire les anciennes entrées de l'adresse IP sur une copie de travail, y compris les entrées hachées, puis écrit la nouvelle entrée vérifiée par remplacement atomique. Les autres hôtes restent inchangés.
7. Il lance ensuite l'audit des accès SSH, des clés autorisées, de sudo et du compte ajlsm.

Précision : l'audit des paramètres SSH dans la VM est en lecture seule ; cependant, la synchronisation préalable peut modifier /root/.ssh/known_hosts sur Saturne3. La description historique « sans modification » ne s'applique donc pas au fichier d'hôtes SSH de l'hyperviseur.

Les tests isolés du 15 octobre 2026 ont confirmé :

• Clés concordantes : acceptation et écriture.
• Clés divergentes : refus sans modification.
• Clé malformée : refus sans modification.
• Préservation des autres entrées, y compris lors du traitement des anciennes entrées hachées.

Limite de validation : ces essais étaient fonctionnels et isolés ; ils n'ont pas constitué une connexion complète à une nouvelle VM MERCURE3. La recette de bout en bout reste à effectuer.

14.6. Durcissement SSH, compte ajlsm et TLS

--ssh-secure désactive l'authentification SSH par mot de passe et conserve l'accès root par clé publique. Avant application, vérifier les accès par clé ; après application, relancer --ssh-audit. Ne pas fermer la dernière session administrative fonctionnelle avant vérification.

--password-ajlsm lance une saisie interactive masquée, répétée deux fois, pour définir le mot de passe du compte ajlsm. Le mot de passe ne doit pas être inscrit dans le YAML ou dans la ligne de commande. Le conserver dans le registre d'administration prévu (ODS), conformément à la procédure AJLSM.

--tls-apply vérifie le certificat TLS interne. Si un certificat personnalisé est déjà en place, il ne doit pas être écrasé inutilement ; sinon l'initialisation s'effectue après confirmation, suivie des contrôles Apache.

Ces fonctions appartiennent à la postconfiguration de la VM. Elles ne remplacent pas les travaux applicatifs ultérieurs sur les montages NFS, les VirtualHosts Apache, Drupal et Pleade.

14.7. Format YAML et protections

Le fichier YAML reste la source de configuration. Les sections obligatoires sont projet, proxmox, systeme et reseau. Les clés inconnues, répétées ou manquantes sont refusées par les contrôles prévus ; les types sont vérifiés. Seul proxmox.vmid peut être null pour l'attribution automatique.

L'attribution d'un VMID lors d'une simulation ne constitue pas une réservation. Vérifier l'identité de la VM et son VMID à chaque opération. La VM modèle 506 doit être arrêtée avant clonage ; ne jamais agir sur la VM 515.

Les adresses IPv4 des interfaces sont indiquées avec préfixe CIDR, la loopback en /32, les DNS sous forme d'une liste non vide d'IPv4. La passerelle doit appartenir au sous-réseau de l'interface déclarée. Les paramètres de réseau sont contrôlés avant activation, mais les contrôles ARP ne remplacent pas l'inventaire d'adressage.

14.8. Confirmations, codes de sortie et reprise

Les confirmations de la version actuelle acceptent uniquement OUI (sans distinction de casse, espaces périphériques ignorés). NON, une réponse vide, toute autre réponse ou une interruption annulent. La valeur par défaut est donc le refus. Une phase déjà conforme peut se terminer sans confirmation si elle n'a rien à modifier.

Code	Signification
0	Succès
1	Annulation
2	Erreur de configuration, de contrôle ou d'exécution

En cas d'échec, ne pas poursuivre : conserver la sortie complète, identifier le VMID, vérifier l'état réel de la VM et son isolation réseau, examiner les journaux et les sauvegardes. Ne jamais contourner une divergence de clés SSH en supprimant aveuglément known_hosts. Ne jamais effacer le journal de transaction système pour relancer artificiellement une phase.

14.9. Maintenance et documentation installée

Sur Saturne3 :

# Vérifier les trois scripts Python
python3 -m py_compile \
  /usr/local/sbin/ajlsm-deploy \
  /usr/local/sbin/ajlsm_deploy_rootgrow.py \
  /usr/local/sbin/ajlsm_deploy_postconfig.py

# Aide et documentation
ajlsm-deploy --help
man 8 ajlsm-deploy
cat /usr/local/sbin/README-ajlsm-deploy

# Identifier le manuel installé
man -w ajlsm-deploy

Le manuel se trouve dans /usr/local/man/man8/ajlsm-deploy.8, en section 8 (administration système). Il a été actualisé le 15 octobre 2026 : ordre des exemples, synchronisation ED25519 et limites de validation. Une sauvegarde du manuel précédent a été déplacée hors du répertoire man8, dans /root/ajlsm-deploy-review/sauvegardes-man/, pour éviter l'avertissement « ignoring bogus filename ».

Les trois scripts Python doivent être sauvegardés ensemble avant correction ou restauration ; leur compatibilité doit être vérifiée. Les sauvegardes des correctifs du 15 octobre sont conservées dans /root/ajlsm-deploy-review/correctifs-20261015/.

14.10. Historique complémentaire des validations

Date	Opération	Statut
15/10/2026	Recette historique : clonage, ressources, premier démarrage, identité, Netplan, contrôle ARP et activation réseau	Validé lors de la recette initiale MERCURE3
15/10/2026	Compilation Python du programme principal et des deux modules rootgrow et postconfig	Validée
15/10/2026	Comparaison ED25519 : concordance, divergence et clé malformée	Validée en tests isolés
15/10/2026	Protection et mise à jour de known_hosts	Validée en tests isolés
15/10/2026	README d'exploitation sur Saturne3	Rédigé ; présence effective à vérifier si nécessaire
15/10/2026	Manuel système section 8, mise à jour SSH et ordre des exemples	Actualisé et affichage vérifié
À réaliser	Extension racine avec le jeu actuel de scripts	Recette complète non confirmée
À réaliser	Chaîne complète jusqu'à SSH, mot de passe et TLS sur un nouveau clone	Recette complète non confirmée
À réaliser	Test d'échec réseau et du mécanisme de repli	Non testé

14.11. Travaux restant hors du périmètre système

Une fois la recette du socle système terminée, les prochaines étapes d'automatisation concernent :

1. Les montages NFS et leurs dépendances.
2. La personnalisation des VirtualHosts et des services Apache.
3. La personnalisation des instances Drupal, de leurs bases et répertoires.
4. La personnalisation des instances Tomcat/Pleade, de leurs connexions et répertoires.
5. Une recette applicative complète.

Ces opérations ne sont pas prises en charge par les phases système décrites ci-dessus à la date de cette mise à jour. Le README applicatif de TEMPLATE3 reste la référence pour la personnalisation applicative tant que ces nouvelles phases n'ont pas été développées et validées.