Il y a 389 articles et 19 utilisateurs inscrits (ce bandeau est défini dans MediaWiki:Sitenotice)
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 degrowpart /dev/sda 3,pvresize /dev/sda3etlvextend -r -l +100%FREEsur 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.
- Le programme résout le VMID cible à partir du projet et de Proxmox.
- Il lit la clé publique d'hôte
/etc/ssh/ssh_host_ed25519_key.pubdans l'invité via l'agent QEMU. - Il vérifie le format de la clé ED25519, notamment sa structure binaire attendue.
- Il interroge indépendamment le service SSH exposé sur le réseau à l'aide de
ssh-keyscan -T 8 -t ed25519. - Il compare les deux clés. Une clé absente, malformée ou différente entraîne un refus sans remplacement de
known_hosts. - En cas de concordance, il sauvegarde
/root/.ssh/known_hostssur 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. - 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 :
- Les montages NFS et leurs dépendances.
- La personnalisation des VirtualHosts et des services Apache.
- La personnalisation des instances Drupal, de leurs bases et répertoires.
- La personnalisation des instances Tomcat/Pleade, de leurs connexions et répertoires.
- 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.