Jlarvers : Page créée avec « = AJLSM-DEPLOY — Version 1.0.2 = Mise à jour : 19 octobre 2026. Ce guide décrit les scripts du dossier '''ajlsm-deploy-v1.0.2''', à installer dans '''/opt/ajlsm-depl... »

2026-10-19T07:36:46Z

Page créée avec « = AJLSM-DEPLOY — Version 1.0.2 = Mise à jour : 19 octobre 2026. Ce guide décrit les scripts du dossier '''ajlsm-deploy-v1.0.2''', à installer dans '''/opt/ajlsm-depl... »

Nouvelle page

= AJLSM-DEPLOY — Version 1.0.2 =

Mise à jour : 19 octobre 2026. Ce guide décrit les scripts du dossier
'''ajlsm-deploy-v1.0.2''', à installer dans '''/opt/ajlsm-deploy/v1'''.
Ce chemin est le répertoire définitif de lancement sur le nœud Proxmox ;
les anciennes copies de /usr/local/sbin ne sont pas remplacées implicitement.
Les lots NFS, Apache et Matomo précédents sont historiques. Garder scripts,
modules et modèles du même lot. Rotation des logs et update.sh hors périmètre.

== Périmètre et architecture ==

Les scripts tournent sur le nœud Proxmox. Ils configurent le clone depuis un
projet YAML strict, utilisent QEMU Guest Agent pour les opérations invitées,
et SSH pour certaines vérifications/postconfigurations. Le moteur principal
orchestre les phases ; les modules spécialisés traitent racine, postconfiguration,
NFS, Apache, SQL Matomo, activation Matomo et inventaire des tâches planifiées.
Les helpers communs valident le YAML et affichent les commandes suivantes.

'''Ce n'est pas un gestionnaire complet de l'infrastructure externe.''' DNS,
OPNsense, Ansible, autorisation Eole3 et certificats publics ont leurs procédures.
Le script ne détruit pas la VM existante et ne modifie pas TEMPLATE3.

== Répertoire définitif et exemple MERCURE3 ==

Les cinq programmes affichent la version 1.0.2 avec --version.
Leur --help rappelle le même répertoire et le même exemple que cette page.
Ces valeurs sont centralisées dans ajlsm_deploy_version.py.
Les suggestions visent les programmes du dossier réellement exécuté :
utiliser le lot installé ci-dessous, pas un ancien dossier de recette.

Sur Saturne3, après installation du lot complet selon INSTALLATION-V1.txt :
<syntaxhighlight lang="bash">
cd /opt/ajlsm-deploy/v1
</syntaxhighlight>

Toutes les commandes ./ de cette page se lancent depuis ce répertoire.
Depuis un autre répertoire du même nœud, utiliser le chemin absolu du
programme sous /opt/ajlsm-deploy/v1 et celui du YAML.
Les YAML opérationnels restent sous /etc/ajlsm/deploy/projets/,
les journaux sous /var/lib/ajlsm-deploy/cycles/. Les archives/recettes
sous /root/ajlsm-deploy ne sont plus le répertoire de lancement v1.
Ne pas mélanger les modules ou changer de lot pendant un cycle.

'''exemples/mercure3-exemple.yaml''' est un exemple renseigné avec les IP
réelles de MERCURE3, pas une préconfiguration générique.
Les commandes MERCURE3 de ce guide sont des exemples à adapter au projet.
Le nom de la VM, ses DNS et ses fichiers YAML opérationnels existants ne sont
pas renommés. En particulier, conserver le chemin du YAML pour la reprise :
le journal est indexé par ce chemin absolu.
modeles/projet-vierge.yaml demeure le modèle générique sans valeurs.

== Prérequis impératif : OS de TEMPLATE3 à jour ==

Avant TOUT nouveau clonage, maintenir l’OS Ubuntu de TEMPLATE3 à jour.
La VM clonée hérite de cet état. Maintenance manuelle distincte : les scripts
de déploiement ne mettent pas le modèle à jour. Prévoir une sauvegarde
récupérable et une fenêtre sans conflit d’IP avec les clones existants.
Ne pas démarrer ni convertir à l’aveugle un modèle marqué template Proxmox.

Dans la console de TEMPLATE3, après vérification de son identité :
<syntaxhighlight lang="bash">
hostname -f
cat /etc/os-release
sudo apt update
sudo apt upgrade
apt list --upgradable
if [ -f /var/run/reboot-required ]; then
cat /var/run/reboot-required
cat /var/run/reboot-required.pkgs 2>/dev/null || true
fi
</syntaxhighlight>

Examiner toutes les erreurs, messages APT et paquets retenus/différés.
apt update seul ne met pas les paquets à jour. Pas de -y, full-upgrade,
do-release-upgrade ou update.sh automatique. Si un redémarrage est demandé :
<syntaxhighlight lang="bash">
sudo reboot
</syntaxhighlight>

Attendre le retour du modèle, puis dans sa console :
<syntaxhighlight lang="bash">
hostname -f
uname -r
systemctl --failed
apt list --upgradable
test ! -f /var/run/reboot-required
</syntaxhighlight>

Examiner les résultats, noter date/OS/noyau dans le registre de maintenance.
Après validation, arrêter proprement TEMPLATE3 :
<syntaxhighlight lang="bash">
sudo shutdown -h now
</syntaxhighlight>

Puis sur Saturne3 :
<syntaxhighlight lang="bash">
qm status 506
</syntaxhighlight>

506 correspond au template_vmid de cette recette : vérifier la valeur du YAML.
Le modèle doit être arrêté avant le clonage. Ni le lanceur ni les précontrôles
ne certifient automatiquement sa fraîcheur APT. Cette maintenance n’a pas
été réalisée par les scripts livrés. Saturne3 et HAProxy ont leur maintenance
distincte, non demandée ici.
Voir PREREQUIS-OS-ET-PUBLICATION.txt et les documentations Ubuntu :
[https://ubuntu.com/server/docs/how-to/software/package-management/ Gestion des paquets]
et [https://ubuntu.com/server/docs/how-to/software/automatic-updates/ Mises à jour automatiques].

== Paramètres prévus avant la création ==

* Identité projet, environnement et tags : interne, client, prod ; types YAML stricts.
* Ressources, template, stockage, IP privées/VPN/publique, passerelle et DNS.
* Domaines principal, préprod et Matomo définitifs, sans https:// ni chemin.
* NFS existant et droits accordés par l'administrateur du serveur.
* Activation des vhosts distincte de l'installation des logiciels.
* Noms SQL dédiés Matomo, sans secret dans le YAML.

Référence MERCURE3 : hostname mercure3.ajlsm.com, VPN 10.0.0.43,
réseau données 192.168.123.27, publique 51.83.117.113. Matomo :
mercure3-matomo.pleade.com ; préprod : mercure3-preprod.pleade.com.
Ne pas conserver deux VM avec ces mêmes adresses.

Chez OVH, principal A vers 51.83.117.113, domaines secondaires CNAME vers
mercure3.ajlsm.com dans la recette. Ne pas publier d'AAAA sans IPv6 opérationnel.
Pour un domaine secondaire sur la même IP, réutiliser la VIP/NAT existante si
elle et le filtrage traitent déjà le flux requis ; ne pas dupliquer OPNsense.
Le trafic public passe par la VIP HAProxy 10.0.0.32, nœuds .30 et .31.

== Préconfiguration et contrôle ==

modeles/projet-vierge.yaml contient des null, jamais une liste [à renseigner].
null est valide pour proxmox.vmid automatique, pas pour un champ obligatoire.
Les sections métier peuvent être omises, mais doivent être complètes si présentes.
exemples/mercure3-exemple.yaml prépare une recréation volontaire, pas une VM parallèle.

<syntaxhighlight lang="bash">
./ajlsm-deploy-yaml ./modeles/projet-vierge.yaml --with-metier --output /etc/ajlsm/deploy/projets/mercure3-initial.yaml
./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3-initial.yaml --check
./ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml --plan
./ajlsm-deploy-check /etc/ajlsm/deploy/projets/mercure3-initial.yaml
</syntaxhighlight>

Le parcours complet de l'assistant est désormais '''--with-metier''' :
NFS, domaines Matomo/Apache et SQL dédiés dans le même YAML initial.
Sans modèle, utiliser --new --with-metier avec un chemin inexistant.
Les valeurs valides existantes sont conservées ; --review les revoit aussi.
Le guide détaillé GUIDE-YAML.txt décrit les questions et les activations :
Drupal seulement si vérifié, Pleade préprod désactivé en son absence,
Matomo Apache false jusqu'à publication-matomo après pause externe.
Le mode --with-matomo-site reste une activation MANUELLE distincte,
incompatible avec --with-metier ; inutile au cycle guidé actuel.
OS du modèle, DNS, OPNsense, ACME sur les deux HAProxy, Ansible/whitelist
et autorisation NFS sont rappelés mais pas vérifiés ni enregistrés comme tels.

Les options individuelles restent disponibles : --with-nfs, --with-matomo, --with-apache et
--with-matomo-sql ; --review revoit aussi les valeurs valides. --new crée un
nouveau chemin. Les fichiers existants ne sont pas écrasés. --check et
--yaml-only sont des contrôles locaux, pas une vérification d'infrastructure.
Prévoir apache.matomo.activer=false pour le cycle initial ; un projet
d'activation true est refusé par le cycle avant toute phase passant par Apache.

== Cycle initial : dix-sept étapes ==

{| class="wikitable"
! Étape !! Simulation / lecture !! Exécution
|-
| clonage || --dry-run || --clone
|-
| ressources || --resources-dry-run || --configure-resources
|-
| premier-demarrage || --first-boot-dry-run || --first-boot-apply
|-
| extension-racine || --root-grow-dry-run || --root-grow-apply
|-
| identite || --system-dry-run || --system-apply
|-
| netplan || --network-dry-run || --network-apply
|-
| activation-reseau || --network-enable-dry-run || --network-enable
|-
| audit-ssh || --ssh-audit || audit, pas de simulation distincte
|-
| securisation-ssh || aucune || --ssh-secure
|-
| mot-de-passe || aucune || --password-ajlsm
|-
| tls || aucune || --tls-apply
|-
| nfs || --nfs-dry-run puis --nfs-check || --nfs-apply
|-
| apache || --apache-dry-run || --apache-apply
|-
| matomo-sql || --matomo-sql-dry-run || --matomo-sql-prepare
|-
| tomcat-cron || --scheduled-dry-run || --scheduled-apply
|-
| taches-planifiees || --scheduled-audit || aucune modification
|-
| publication-matomo || --matomo-guided-dry-run || --matomo-guided
|}

Le clone est isolé avant premier démarrage. L'extension racine suit le premier
démarrage et ne doit pas être confondue avec le disque virtuel déjà agrandi.
Puis identité, réseau, SSH, mot de passe et certificat interne sont traités.
Les phases métier non demandées sont ignorées explicitement.

=== Attente réseau pendant l'isolation ===

Le journal MERCURE3 transmis montre wait-online en attente 120 secondes avant
activation des carriers ; le réseau est ensuite online sur les deux cartes.
Le lot ajoute une dispense conditionnelle liée à l'UUID pendant l'isolation,
dès que QGA est disponible. Les phases first-boot et system l'installent après
les confirmations et gardes ; network-enable la retire après ses contrôles
puis vérifie le fonctionnement normal de wait-online avant onboot.
Le repli réseau remet la dispense après réisolation. Pas de mask/disable,
pas de changement Netplan optional ou de TEMPLATE3. Les simulations n'écrivent
aucun fichier. Ce correctif reste à recetter sur un clone ; il ne nécessite
pas de reconstruire la VM actuelle pour continuer les étapes métier.
Voir CORRECTIF-WAIT-ONLINE.txt pour les deux fichiers gérés, limites et reprise.

<syntaxhighlight lang="bash">
./ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml
</syntaxhighlight>

Les confirmations OUI/NON, défaut NON, et saisies natives restent interactives.
Pas d'arrêt entre commandes réussies ; arrêt au premier refus ou erreur.
--agent-timeout est transmis aux phases, défaut 300 secondes, pas un timeout global.
Après diagnostic, --from reprend l'étape incluse sans refaire les précédentes.
Un --plan n'exécute rien mais ne garantit ni Proxmox ni l'infrastructure externe.

== NFS : autorisation manuelle guidée ==

Dépôt d'exemples : 192.168.123.202:/var/data/pleade.com-data/data,
point local identique, mode ro. Un autre dépôt est paramétrable ; plusieurs
dépôts de MERCURE3 restent une exception manuelle. Le script affiche le fichier
exports et la ligne à adapter sur Eole3, sans s'y connecter en administrateur.
L'autorisation de 192.168.123.27 en ro a été réalisée dans la recette.
Les autres exports et données doivent être conservés. Pas de chmod/chown récursif.

== Apache, Drupal et Pleade ==

Six fichiers gérés sous /etc/apache2/sites-available : HTTP et TLS pour Drupal,
préprod et Matomo ; fichier robots préprod séparé. Activation par symlinks selon
le YAML, manifeste, sauvegarde, syntaxe candidate et reload avec tentative de
restauration locale sur erreur. Une interruption brutale demande un diagnostic.
Un vhost préparé n'installe pas un logiciel et ne valide pas une application.
Les fichiers gérés modifiés hors déploiement provoquent un refus, pas un écrasement.

Drupal hérité a été vérifié utilisable avec MariaDB et drupal_template ; son
vhost principal est actif dans la recette. Pas de personnalisation SQL Drupal
dédiée dans ce lot. Pleade n'est pas installé, sa préprod reste désactivée ;
pas d'appel à update.sh. Les futurs slecture et internet ne sont pas publiés.

== Matomo : préparation SQL puis activation coordonnée ==

Base et compte locaux dédiés : matomo_mercure3, sans adoption de matomo_template.
Configuration préparée root privée dans /var/lib/ajlsm-matomo-sql ; ne pas
transmettre ces fichiers. En fin de cycle, publication-matomo affiche la pause
externe, demande une attestation OUI/NON puis active Matomo avec le MÊME YAML.
Il passe activer=true en mémoire uniquement ; le YAML initial reste intact.
En mode manuel, après SQL :

<syntaxhighlight lang="bash">
./ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3-initial.yaml --matomo-guided-dry-run
./ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3-initial.yaml --matomo-guided
</syntaxhighlight>

L’activation coordonnée conserve Drupal/Pleade. Le mode historique reste
possible : --with-matomo-site crée une copie d’activation, ensuite utilisée par
--matomo-site-dry-run puis --matomo-site-apply.
Ne pas utiliser --apache-apply seul pour cette transition et ne pas relancer
le clonage avec la copie d'activation. Le module désactive les anciens vhosts
Matomo connus, sauvegarde le cache, installe la configuration privée et active
le projet avec contrôle HTTPS local. Les sauvegardes peuvent contenir des secrets.

== Certificats en prérequis et pause avant activation ==

Recommandation : DNS puis challenge ACME stateless prêts, émettre/déployer les
certificats publics en prérequis, avant même le clonage backend. Le challenge
HAProxy ne dépend pas de Matomo. Une pause reste obligatoire à publication-matomo
pour vérifier les certificats et le routage restreint sur LES DEUX nœuds.
NON arrête proprement le cycle ; --resume reprend après préparation externe.
Aucune commande ACME/Ansible n’est exécutée par le script et l’attestation
humaine ne constitue pas une vérification automatisée.

Le certificat interne généré dans le clone n'est pas le certificat public.
Les certificats publics sont vérifiés/générés avec acme.sh sous l'utilisateur
acme sur les deux HAProxy, l'un après l'autre. Connexion hpr puis sudo -i,
pas root SSH. Conserver le challenge HTTP-01 stateless avant la whitelist.
Émission et déploiement Matomo ont réussi sur les deux nœuds lors de la recette.
Un certificat valide pour le même domaine n'est pas à refaire parce que le
backend est recréé ; revérifier validité, déploiement et renouvellement.

Ansible ajoute ACL du domaine, refus hors whitelist, redirection HTTPS et
backend SNI vers 10.0.0.43:443. Matomo interne MERCURE3 : allowed_ajlsm uniquement.
Pour un client, prévoir AJLSM et whitelist client selon les règles préprod.
Le backend conserve ssl verify none : l'identité du backend n'est pas validée.

<syntaxhighlight lang="bash">
ansible-playbook -i inventory ./plays/deploy.haproxy.yml --syntax-check
ansible-playbook -i inventory ./plays/deploy.haproxy.yml --limit haproxy01.ajlsm.lan --check --diff
ansible-playbook -i inventory ./plays/deploy.haproxy.yml --limit haproxy02.ajlsm.lan --check --diff
</syntaxhighlight>

Examiner tous les diffs puis appliquer séparément en retirant --check, attendre
le succès du premier nœud avant le second. Aucun lancement Ansible automatique
depuis Proxmox. Le check-mode n'est pas l'application réelle.
Recette transmise : deux applications réussies, validation et restart signalés,
aucun failed/unreachable. Avertissement Python découvert /usr/bin/python3.10,
non bloquant dans ces exécutions. Aucun changement d'interpréteur ici.

Tester HTTPS sans -k depuis l'IP autorisée puis hors whitelist. Résultats
transmis : 200 avec en-tête Matomo via VPN bureau, 403 hors whitelist.
Un HTTP 200 n'est pas une validation d'installation fonctionnelle.

== Tâches planifiées : correction ciblée puis audit ==

--scheduled-audit inventorie crontabs root/ajlsm/www-data, fichiers système,
noms des scripts périodiques, timers systemd et instances Tomcat. Les commandes
et arguments privés ne sont pas affichés. L'audit historique et l'inventaire
avant traitement confirment 13 lignes Tomcat et trois processus, sans Pleade détecté.
Après cycle du 18 octobre : zéro tâche Tomcat active pour les trois instances
vides ; processus déjà lancés conservés et archivage mensuel inchangé.
Les tâches des autres comptes, timers utilisateurs et contenus des scripts
restent hors audit. L'inventaire seul n'effectue aucune désactivation.
Code 0 = inventaire obtenu, pas tâches approuvées. Rotation des logs inchangée.

La phase '''tomcat-cron''' a été autorisée pour ne pas reproduire ces tâches
inutiles sur les nouveaux clones. --scheduled-dry-run affiche les lignes
reconnues à commenter ; --scheduled-apply demande OUI/NON, sauvegarde la crontab
ajlsm et commente ces seules lignes avec un marqueur réversible. Elle ne lance
aucune commande de démarrage, arrêt ou nettoyage Tomcat. Le cycle l'exécute en
étape 15, puis audite le résultat en étape 16.

Critères conservateurs : répertoire Pleade présent et entièrement vide,
webapps absent d'autre application et lien pleade vers le chemin attendu,
pas de contexte externe dans conf/Catalina/localhost. Une implantation non
vérifiable ou un contenu partiel conserve les tâches. Une commande inconnue
visant une instance vide bloque la phase, sans modification partielle.
Seules les formes exactes des commandes héritées auditées sont reconnues.

Sauvegarde privée : /var/backups/ajlsm-scheduled/transaction-* ; journal :
/var/lib/ajlsm-scheduled/transaction.json. Vérification identité/UUID et
empreinte de la crontab avant application, relecture après installation.
Restauration tentée sur erreur contrôlée si elle n'écrase pas un changement
concurrent détecté. Sinon journal conservé et reprise bloquée pour examen manuel.
Le verrou ne protège pas contre crontab -e dans un autre terminal : ne pas
modifier simultanément les tâches ou déployer une application pendant la phase.
L'interface crontab ne fournit pas de comparaison-installation atomique face
aux outils extérieurs. Les @reboot des premiers démarrages du clone peuvent
déjà avoir lancé Tomcat : seuls les lancements futurs sont neutralisés.
Pas de réactivation automatique lors d'une installation Pleade ultérieure.

== Finalisation fonctionnelle, hors déploiement piloté ==

L'installateur Matomo a confirmé « Tables créées » dans la recette. Création
du superadministrateur, premier site, fin de l'assistant et intégration du suivi
restent manuelles. Ne pas laisser un installateur inachevé ouvert durablement.
Lire FINALISATION-MATOMO.txt : reprise directe tablesCreation et avertissement
sur systemCheck qui supprime la configuration locale préparée en version auditée.
Diagnostics applicatifs non annoncés comme faits. Ne pas partager de secrets.

== Point d’arrêt et reprise depuis tout répertoire ==

Le nouveau lanceur conserve un journal privé sur Saturne3 dans
/var/lib/ajlsm-deploy/cycles/, mode 600, historique par exécution.
Il n’enregistre ni mots de passe, ni sortie complète des phases.
Il suit étape courante, dernière réussite, dates UTC, codes de sortie,
empreintes du YAML/lot, hôte et identité VMID/UUID de la cible.
Un verrou protège ce journal, pas les interventions d’un autre administrateur.

Avec chemins absolus, depuis n’importe quel répertoire '''du même nœud''' :
<syntaxhighlight lang="bash">
/opt/ajlsm-deploy/v1/ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml --status
/opt/ajlsm-deploy/v1/ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3-initial.yaml --resume
</syntaxhighlight>

--status ne contacte pas Proxmox et ne crée aucun journal. --resume reprend
la première étape non réussie, avec contrôles et confirmations habituels.
Une faute « ouii » à tls se reprend donc à tls sans reclonage.
La reprise refuse les changements de nœud, YAML, code/ordre ou d’identité
VM enregistrée. Elle ne relance pas un cycle déjà terminé.
Après coupure brutale, en_cours signifie résultat inconnu : examiner les
journaux transactionnels, l’état et les processus avant reprise.
Le journal n’est pas une preuve de conformité permanente de l’infrastructure.

--from étape reste une reprise explicite après diagnostic, qui démarre un
nouveau journal et marque les étapes antérieures ignorées, pas vérifiées.
Ne pas effacer les journaux pour contourner une erreur.
Les anciens lots sans journal ne permettent pas --resume rétroactif :
consulter leur sortie console puis reprendre avec --from.
Pour la VM actuelle, l’application de la dernière simulation Matomo n’est
pas confirmée. Contrôler avant de reprendre à publication-matomo, sans clonage.

== Détails de sécurité conservés de la documentation du 16 octobre ==

L’audit SSH lit la clé ED25519 via QEMU, vérifie son format binaire, puis
compare indépendamment celle exposée par ssh-keyscan. Une divergence refuse
la suite. Après concordance seulement, sauvegarde et remplacement atomique
possible de /root/.ssh/known_hosts sur Saturne3 ; les autres hôtes sont conservés,
y compris traitement ciblé des anciennes entrées hachées de l’IP du clone.
--ssh-audit n’est donc pas entièrement sans écriture.
--ssh-secure vérifie la syntaxe/effectivité et les connexions par clé avant/après
reload ; le mot de passe local reste utile à sudo.
--password-ajlsm utilise passwd interactif masqué ; aucun secret dans le YAML.

La personnalisation système conserve dans la VM
/var/lib/ajlsm/system-personalisation/state.json et backup/. Ce journal décrit
une transaction, pas le cycle global. Ne pas l’effacer pour forcer une reprise.
La phase TLS vérifie le certificat interne /etc/ssl/ajlsm/server.crt, utilise
si nécessaire /usr/local/sbin/ajlsm-init-tls.sh déjà présent dans le modèle,
puis contrôle Apache. Cela ne valide pas les applications ou le TLS public.
Le README applicatif /home/ajlsm/README ne doit pas être remplacé par le
README-ajlsm-deploy de l’outil. Le document README-TEMPLATE3.txt est proposé
séparément, pas installé automatiquement.

Validation YAML stricte : clés inconnues/répétées et types incorrects refusés ;
environnement/tags interne, client, prod, sans doublons ; tags [] admis ;
entiers positifs, mémoire minimale <= maximale, booléens true/false ;
interfaces netN/ensN uniques, IPv4/CIDR, loopback /32, DNS sans préfixe.
Passerelle dans le sous-réseau de son interface et distincte de la VM.
Serveur, bridge et stockage sont à adapter à l’infrastructure, sans liste
fermée inventée. Les sections métier sont désormais prises en charge :
l’interdiction historique d’ajouter metier ne s’applique plus à ce schéma.

== Manuels, reprise et validation du lot ==

Pages section 8 de la version 1.0.2 du 19 octobre : deploy, cycle, yaml, check, resources.
Lecture locale avec man ./man8/ajlsm-deploy.8 ; sauvegarde et installation
optionnelle décrites dans INSTALLATION-MANUELS.txt, sans copier les scripts.
Le lancement définitif se fait dans /opt/ajlsm-deploy/v1, sans copier les
programmes du nœud dans /usr/local/sbin. La commande invitée
/usr/local/sbin/ajlsm-init-tls.sh reste distincte et n'est pas déplacée.
Conserver le lot complet, modules et modèles, sans mélanger les versions.
Une installation du lot ne remplace pas une recette complète sur Proxmox.
Tests locaux sous tests/, résultats dans RAPPORT-TESTS.txt ; QGA, SQL, PHP
et services simulés. Ils ne prouvent pas la réussite d'un déploiement distant.
Une restauration de phase n'annule pas SQL ni les actions web ultérieures.
Ne pas effacer un journal transaction.json pour forcer une reprise.

== Réconciliation de la page reçue du 16 octobre et état de recette ==

Cette procédure remplace les indications historiques « 11 étapes »,
« NFS/Apache/Matomo hors cycle » et « aucun journal global ». Le nouveau lot
compte 17 étapes avec publication protégée, mais la finalisation fonctionnelle
Matomo reste indépendante. L’ancien man reproduit intégralement dans la page
du 16 octobre n’est pas recopié ici : les cinq sources man8 de ce lot sont
la référence de version, sans procédure concurrente.
Les anciens chemins du 16 octobre restent des archives, pas le lot courant.

Le cycle 16 étapes du lot consolide-taches a été exécuté sur un clone recréé
le 18 octobre, reprise TLS après faute de saisie incluse. Hostname et racine
ext4 97 Gio confirmés. Tâches Tomcat neutralisées pour les instances vides ;
les processus déjà lancés n’ont pas été arrêtés. Le correctif wait-online et
le nouveau cycle 17 étapes avec journal restent à valider sur Proxmox.
Les tests locaux ne sont pas une nouvelle recette distante.
La capture « Tables créées » et la première activation Matomo concernent le
clone antérieur : ne pas les attribuer automatiquement au clone actuel.
Le succès nominal ne valide pas le repli réseau après panne.

Le modèle TEMPLATE3 n’a pas été modifié par ces scripts. Cela ne démontre
pas l’absence de toute autre intervention. Sa mise à jour OS demandée est
une maintenance à réaliser/valider séparément avant le prochain clonage.
Aucun nettoyage serveur ni envoi SVN n’est exécuté par cette livraison.

[[Category:Proxmox]][[Category:AJLSM]][[Category:Déploiement]]

AJLSM-DEPLOY — Version 1.0.2 - Historique des versions

Jlarvers : Page créée avec « = AJLSM-DEPLOY — Version 1.0.2 = Mise à jour : 19 octobre 2026. Ce guide décrit les scripts du dossier '''ajlsm-deploy-v1.0.2''', à installer dans '''/opt/ajlsm-depl... »

Jlarvers : Page créée avec « = AJLSM-DEPLOY — Version 1.0.2 = Mise à jour : 19 octobre 2026. Ce guide décrit les scripts du dossier '''ajlsm-deploy-v1.0.2''', à installer dans '''/opt/ajlsm-depl... »