|
|
| Ligne 1 : |
Ligne 1 : |
| = AJLSM-DEPLOY — Déploiement automatisé des VM Proxmox =
| | Obsolète : |
|
| |
|
| {{Note|Mise à jour du 15 octobre 2026. Les sections 1 à 13 conservent les informations de la recette initiale ; les ajouts et corrections actuels figurent en section 14. En cas de divergence, la procédure opérationnelle de la section 14 et le manuel installé sur Saturne3 prévalent.}}
| | Voir [[Déploiement_technique_d’une_VM_AJLSM]] |
| | |
| == 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 ===
| |
| | |
| <syntaxhighlight lang="yaml">
| |
| projet:
| |
| code: mercure3
| |
| nom: MERCURE3
| |
| environnement: interne
| |
| | |
| proxmox:
| |
| serveur: Saturne3
| |
| template_vmid: 506
| |
| vmid: null
| |
| nom_vm: MERCURE3
| |
| | |
| cpu:
| |
| sockets: 1
| |
| cores: 8
| |
| | |
| memoire:
| |
| maximale_mib: 24576
| |
| minimale_mib: 16384
| |
| | |
| disque_systeme:
| |
| stockage: local-zfs
| |
| taille_gib: 100
| |
| etendre_volume_racine: true
| |
| | |
| demarrage_auto: true
| |
| | |
| tags:
| |
| - interne
| |
| | |
| systeme:
| |
| hostname: mercure3.ajlsm.com
| |
| | |
| reseau:
| |
| interfaces:
| |
| - nom: net0
| |
| bridge: vmbr2
| |
| systeme: ens18
| |
| ipv4: 10.0.0.43/24
| |
| | |
| - nom: net1
| |
| bridge: vmbr1
| |
| systeme: ens19
| |
| ipv4: 192.168.123.27/24
| |
| | |
| loopback:
| |
| ipv4: 51.83.117.113/32
| |
| | |
| passerelle:
| |
| ipv4: 10.0.0.4
| |
| interface: ens18
| |
| | |
| dns:
| |
| - 10.0.0.4
| |
| </syntaxhighlight>
| |
| | |
| === 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.
| |
| | |
| {| class="wikitable"
| |
| ! É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 || <code>/usr/local/sbin/ajlsm-deploy</code>
| |
| |-
| |
| | Extension racine || <code>/usr/local/sbin/ajlsm_deploy_rootgrow.py</code>
| |
| |-
| |
| | Postconfiguration || <code>/usr/local/sbin/ajlsm_deploy_postconfig.py</code>
| |
| |-
| |
| | Configurations || <code>/etc/ajlsm/deploy/projets/</code>
| |
| |-
| |
| | README d'exploitation || <code>/usr/local/sbin/README-ajlsm-deploy</code>
| |
| |-
| |
| | Manuel système || <code>/usr/local/man/man8/ajlsm-deploy.8</code> ; <code>man 8 ajlsm-deploy</code>
| |
| |-
| |
| | Dossier de revue || <code>/root/ajlsm-deploy-review/</code>
| |
| |-
| |
| | Sauvegardes des correctifs || <code>/root/ajlsm-deploy-review/correctifs-20261015/</code>
| |
| |}
| |
| | |
| Les programmes autonomes <code>ajlsm-deploy-check</code> et <code>ajlsm-deploy-resources</code> figurent également dans le manuel. Leur présence et leur version effectives sont à vérifier avant toute intervention.
| |
| | |
| Le README situé dans <code>/home/ajlsm/README</code> 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 <code>root</code>. 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.
| |
| | |
| <syntaxhighlight lang="bash">
| |
| 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
| |
| </syntaxhighlight>
| |
| | |
| 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 <code>--configure-resources</code> 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''.
| |
| | |
| * <code>--root-grow-dry-run</code> : 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.
| |
| * <code>--root-grow-apply</code> : après confirmation, exécution de <code>growpart /dev/sda 3</code>, <code>pvresize /dev/sda3</code> et <code>lvextend -r -l +100%FREE</code> sur le LV racine.
| |
| | |
| '''Limitation de sécurité :''' la procédure est limitée à la topologie contrôlée de TEMPLATE3 : <code>/dev/sda3</code>, 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é :
| |
| | |
| <syntaxhighlight lang="bash">
| |
| lsblk
| |
| df -hT /
| |
| pvs
| |
| vgs
| |
| lvs
| |
| </syntaxhighlight>
| |
| | |
| 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 <code>--system-dry-run</code> et <code>--system-apply</code> personnalisent le hostname, <code>/etc/hosts</code> et le <code>machine-id</code>, en respectant le journal de reprise. La VM reste isolée. Le journal de transaction de l'invité est conservé sous <code>/var/lib/ajlsm/system-personalisation/</code> ; ne pas le supprimer pour forcer une reprise.
| |
| | |
| <code>--network-dry-run</code> et <code>--network-apply</code> préparent Netplan et vérifient <code>netplan generate</code> sans activer les interfaces Proxmox.
| |
| | |
| <code>--network-enable-dry-run</code> 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.
| |
| | |
| <code>--network-enable</code> 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 <code>--ssh-audit</code> 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 <code>/etc/ssh/ssh_host_ed25519_key.pub</code> ''dans 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 <code>ssh-keyscan -T 8 -t ed25519</code>.
| |
| # Il compare les deux clés. Une clé absente, malformée ou différente entraîne un refus sans remplacement de <code>known_hosts</code>.
| |
| # En cas de concordance, il sauvegarde <code>/root/.ssh/known_hosts</code> 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.
| |
| # Il lance ensuite l'audit des accès SSH, des clés autorisées, de sudo et du compte <code>ajlsm</code>.
| |
| | |
| '''Précision :''' l'audit des paramètres SSH ''dans la VM'' est en lecture seule ; cependant, la synchronisation préalable peut modifier <code>/root/.ssh/known_hosts</code> ''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 ===
| |
| | |
| <code>--ssh-secure</code> 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 <code>--ssh-audit</code>. Ne pas fermer la dernière session administrative fonctionnelle avant vérification.
| |
| | |
| <code>--password-ajlsm</code> lance une saisie interactive masquée, répétée deux fois, pour définir le mot de passe du compte <code>ajlsm</code>. 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.
| |
| | |
| <code>--tls-apply</code> 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 <code>projet</code>, <code>proxmox</code>, <code>systeme</code> et <code>reseau</code>. 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 <code>proxmox.vmid</code> peut être <code>null</code> 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 <code>/32</code>, 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 <code>OUI</code> (sans distinction de casse, espaces périphériques ignorés). <code>NON</code>, 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.
| |
| | |
| {| class="wikitable"
| |
| ! 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 <code>known_hosts</code>. Ne jamais effacer le journal de transaction système pour relancer artificiellement une phase.
| |
| | |
| === 14.9. Maintenance et documentation installée ===
| |
| | |
| Sur Saturne3 :
| |
| | |
| <syntaxhighlight lang="bash">
| |
| # 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
| |
| </syntaxhighlight>
| |
| | |
| Le manuel se trouve dans <code>/usr/local/man/man8/ajlsm-deploy.8</code>, 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 <code>man8</code>, dans <code>/root/ajlsm-deploy-review/sauvegardes-man/</code>, 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 <code>/root/ajlsm-deploy-review/correctifs-20261015/</code>.
| |
| | |
| === 14.10. Historique complémentaire des validations ===
| |
| | |
| {| class="wikitable"
| |
| ! 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 <code>rootgrow</code> et <code>postconfig</code> || 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 <code>known_hosts</code> || 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.
| |
| | |
| [[Catégorie:Infrastructure]]
| |
| [[Catégorie:Proxmox]]
| |
| [[Catégorie:Déploiement]]
| |
| [[Catégorie:AJLSM]] | |