AJLSM - Modifications récentes [fr]

MediaWiki:Sidebar

Jlarvers — Fri, 06 Nov 2026 12:54:48 GMT

Ajout liens pages spéciales

← Version précédente		Version du 6 novembre 2026 à 12:54
Ligne 13 :		Ligne 13 :
	** helppage\|help		** helppage\|help
	** Special:UserLogin\|Créer un utilisateur		** Special:UserLogin\|Créer un utilisateur

			* administration
			** Special:SpecialPages\|Pages spéciales
			** Special:Version\|Version de MediaWiki
			** Special:UserRights\|Droits des utilisateurs
			** Special:CreateForm\|Créer un formulaire

	* SEARCH		* SEARCH

MediaWiki:AJLSM-WikiEditor.js

Jlarvers — Fri, 06 Nov 2026 12:30:22 GMT

Restauration des 14 boutons historiques AJLSM

Voir les modifications

MediaWiki:Common.js

Jlarvers — Fri, 06 Nov 2026 12:25:20 GMT

← Version précédente		Version du 6 novembre 2026 à 12:25
Ligne 463 :		Ligne 463 :
	} );		} );
	/* DO NOT ADD CODE BELOW THIS LINE */		/* DO NOT ADD CODE BELOW THIS LINE */

			/* AJLSM - Boutons personnalises de WikiEditor */
			mw.loader.load( mw.util.getUrl( 'MediaWiki:AJLSM-WikiEditor.js', {
			action: 'raw',
			ctype: 'text/javascript'
			} ) );

MediaWiki:AJLSM-WikiEditor.js

Jlarvers — Fri, 06 Nov 2026 12:23:29 GMT

Restauration des boutons WikiEditor AJLSM - premier test

Nouvelle page

mw.hook( 'wikiEditor.toolbarReady' ).add( function ( $textarea ) {
$textarea.wikiEditor( 'addToToolbar', {
section: 'advanced',
group: 'insert',
tools: {
ajlsmPath: {
label: 'Ajouter un chemin vers un fichier/dossier',
type: 'button',
icon: mw.config.get( 'wgScriptPath' ) + '/images/9/96/Toolbar-path.svg',
action: {
type: 'encapsulate',
options: {
pre: '{{path|',
peri: '/path/to/dir-or-file',
post: '}}'
}
}
}
}
} );
} );

Utilisateur:Jlarvers

Jlarvers — Fri, 06 Nov 2026 12:21:52 GMT

Jlarvers a modifié l’appartenance aux groupes de Jlarvers : Ajout de administrateur d’interface ; Mantien de bureaucrate et administrateur Administration des scripts JavaScript AJLSM (migration MediaWiki 1.46)

WAF 2026

Jlarvers — Thu, 05 Nov 2026 14:32:40 GMT

Certificats automatiques (SSL Lets Encrypt) via Haproxy :

Voir les modifications

Sécurité PHP – CVE-2026-109618 / CVE-2026-109619 – Interventions des 21 et 22 octobre 2026

Jlarvers — Thu, 22 Oct 2026 15:11:52 GMT

1.1. Tableau de suivi :

← Version précédente		Version du 22 octobre 2026 à 15:11
Ligne 124 :		Ligne 124 :

	'''Important :''' ce tableau reprend les machines dont les interventions ont été identifiées dans le suivi. Il ne constitue pas, à lui seul, un inventaire exhaustif de toutes les VM Proxmox.		'''Important :''' ce tableau reprend les machines dont les interventions ont été identifiées dans le suivi. Il ne constitue pas, à lui seul, un inventaire exhaustif de toutes les VM Proxmox.

			=== Machines à réintégrer au bilan des 21 et 22 octobre 2026 ===

			{\| class="wikitable"
			! Machine
			! Version PHP
			! Intervention réalisée
			! Vérifications restantes
			\|-
			\| Basse-Bretagne
			\| À retrouver dans les journaux d'intervention
			\| Intervention du chantier de sécurité PHP à documenter
			\| Confirmer versions, correctifs et redémarrage éventuel
			\|-
			\| ENS Lyon
			\| À retrouver dans les journaux d'intervention
			\| Intervention du chantier de sécurité PHP à documenter
			\| Confirmer versions, correctifs et redémarrage éventuel
			\|-
			\| APBP
			\| À retrouver dans les journaux d'intervention
			\| Intervention du chantier de sécurité PHP à documenter
			\| Confirmer versions, correctifs et redémarrage éventuel
			\|}

			'''Attention :''' APBP et APBP2 sont deux machines distinctes. Les opérations effectuées sur APBP2 ne doivent pas être attribuées automatiquement à APBP.

	== 2. Origine de l'intervention ==		== 2. Origine de l'intervention ==

Sécurité PHP – CVE-2026-109618 / CVE-2026-109619 – Interventions des 21 et 22 octobre 2026

Jlarvers — Thu, 22 Oct 2026 15:09:59 GMT

Page créée avec « = Sécurité PHP – CVE-2026-109618 / CVE-2026-109619 – Interventions des 21 et 22 octobre 2026 = {| class="wikitable" ! Élément ! Information |- | Période | 21 et... »

Nouvelle page

= Sécurité PHP – CVE-2026-109618 / CVE-2026-109619 – Interventions des 21 et 22 octobre 2026 =

{| class="wikitable"
! Élément
! Information
|-
| Période
| 21 et 22 octobre 2026
|-
| Infrastructure
| AJLSM – Machines virtuelles, HAProxy et OPNsense
|-
| Objet
| Correction ou atténuation des vulnérabilités PHP et mises à jour des systèmes
|-
| Nature des travaux
| Maintenance de sécurité, contrôles applicatifs, haute disponibilité
|-
| État
| Partiellement terminé – maintenance OPNsense et systèmes anciens à poursuivre
|}

== 1. Synthèse ultra-courte ==

'''Bilan :'''

* Les vulnérabilités PHP '''CVE-2026-109618''' et '''CVE-2026-109619''' ont été identifiées.
* Les VM utilisant des versions PHP corrigées ont été mises à jour lorsque les paquets étaient disponibles.
* Les VM utilisant d'anciennes versions de PHP ont reçu une '''atténuation provisoire''' par désactivation de <code>session.upload_progress.enabled</code>.
* Les deux HAProxy ont été mis à jour ; leur fonctionnement Keepalived/VRRP a été corrigé et contrôlé.
* Les deux OPNsense ont reçu la même atténuation PHP provisoire.
* '''Les mises à jour complètes des deux OPNsense restent à effectuer.'''
* La version PHP 8.3.31 proposée par le dépôt OPNsense ne corrige pas les deux CVE selon FreeBSD VuXML.
* Les anciennes branches PHP devront faire l'objet d'un suivi particulier : l'atténuation ne constitue pas un correctif définitif.

=== 1.1. Tableau de suivi ===

{| class="wikitable sortable"
! Machine
! VMID
! PHP / système
! Intervention
! État
|-
| TEMPLATE3
| 506
| Ubuntu 26.04.1 ; PHP 8.4.27 / 8.5.12
| Versions PHP corrigées ; contrôles et redémarrage
| Terminé
|-
| AD64
| 507
| Ubuntu 26.04.1 ; PHP 8.4.27 / 8.5.12
| Versions PHP corrigées ; contrôles et redémarrage
| Terminé
|-
| DEVTOOLS2 / pleade.com
| 508
| PHP 7.2
| Mise à jour disponible + atténuation provisoire
| Atténué ; PHP ancien
|-
| APBP2
| 510
| Ubuntu 26.04.1 ; PHP 8.4.27 / 8.5.12
| Versions PHP corrigées ; contrôles et redémarrage
| Terminé
|-
| DEVTOOLS
| 513
| PHP 5.6
| Atténuation provisoire
| PHP ancien – suivi nécessaire
|-
| ENCELADE
| 514
| PHP 7.4
| Atténuation provisoire
| PHP ancien – suivi nécessaire
|-
| MERCURE
| 515
| Ubuntu 20.04.6 ; PHP 7.2 / 7.4 / 8.0 / 8.1
| Atténuation provisoire sur les quatre branches
| Migration vers MERCURE3 à poursuivre
|-
| CENTREON-R8
| 520
| PHP 8.2.35
| Mise à jour PHP et contrôles Centreon
| PHP corrigé ; reboot noyau restant
|-
| AD53
| —
| PHP 7.2 / 7.3 / 8.0
| Atténuation provisoire dans les configurations PHP
| Atténué ; PHP ancien
|-
| HAProxy-01
| —
| Ubuntu 24.04 LTS
| Mise à jour OS, HAProxy et Keepalived
| Opérationnel
|-
| HAProxy-02
| —
| Ubuntu 24.04 LTS
| Mise à jour OS, HAProxy et Keepalived
| Opérationnel
|-
| SaturneFW1
| —
| OPNsense 26.1 ; PHP 8.3
| Atténuation PHP provisoire
| Mise à jour OPNsense restante
|-
| SaturneFW2
| —
| OPNsense 26.1.6 ; PHP 8.3.30
| Audit et atténuation PHP provisoire
| Mise à jour OPNsense restante
|}

'''Important :''' ce tableau reprend les machines dont les interventions ont été identifiées dans le suivi. Il ne constitue pas, à lui seul, un inventaire exhaustif de toutes les VM Proxmox.

== 2. Origine de l'intervention ==

=== 2.1. Vulnérabilités PHP ===

Deux vulnérabilités critiques ont motivé l'intervention :

* CVE-2026-109618
* CVE-2026-109619

L'avis FreeBSD VuXML publié le 21 octobre 2026 indique que ces vulnérabilités peuvent permettre une exécution de code à distance sans authentification, selon les conditions d'exploitation.

Référence :

https://vuxml.FreeBSD.org/freebsd/d8e16d08-cd2f-11f1-8135-8447094a420f.html

=== 2.2. Versions corrigées ===

{| class="wikitable"
! Branche PHP
! Première version corrigée
|-
| PHP 8.2
| 8.2.35
|-
| PHP 8.3
| 8.3.36
|-
| PHP 8.4
| 8.4.27
|-
| PHP 8.5
| 8.5.12
|}

Les versions plus anciennes, notamment PHP 5.6, 7.2, 7.3, 7.4, 8.0 et 8.1, ne disposent pas d'une version corrigée dans les branches officielles encore maintenues.

'''Conséquence :''' sur les serveurs anciens, la désactivation de la progression des téléversements PHP est une atténuation provisoire, et non une correction complète.

== 3. Méthode de traitement ==

Les interventions ont été organisées machine par machine :

# Identifier la version de l'OS.
# Identifier toutes les versions PHP installées.
# Déterminer les versions réellement utilisées par Apache ou PHP-FPM.
# Vérifier la disponibilité des mises à jour.
# Appliquer les correctifs PHP disponibles.
# Lorsque les correctifs ne sont pas disponibles, désactiver la progression des téléversements PHP.
# Redémarrer ou recharger les services concernés.
# Vérifier les versions PHP effectives.
# Contrôler le fonctionnement des applications.
# Identifier les redémarrages système encore nécessaires.

=== 3.1. Commandes générales de diagnostic ===

<syntaxhighlight lang="bash">
cat /etc/os-release

php -v

php -i | grep -E \
'Loaded Configuration File|Scan this dir|session.upload_progress.enabled'

systemctl --type=service --state=running \
| grep -Ei 'apache|php.*fpm'
</syntaxhighlight>

Sur Ubuntu :

<syntaxhighlight lang="bash">
apt list --upgradable
</syntaxhighlight>

La disponibilité d'un correctif ne doit pas être déduite uniquement du numéro de version PHP lorsque la distribution applique des correctifs rétroportés.

== 4. Atténuation provisoire PHP ==

=== 4.1. Principe ===

La mesure retenue consiste à désactiver :

<syntaxhighlight lang="ini">
session.upload_progress.enabled = Off
</syntaxhighlight>

Elle empêche PHP d'utiliser le mécanisme de suivi de progression des téléversements.

'''Limites :'''

* Elle réduit l'exposition à certains chemins d'exploitation.
* Elle ne corrige pas nécessairement les deux CVE.
* Elle ne remplace pas une mise à jour de sécurité.
* Elle doit être appliquée à toutes les configurations PHP réellement utilisées par le serveur Web.
* Une vérification en PHP CLI ne garantit pas, à elle seule, la configuration effective des processus Web.

=== 4.2. Contrôle ===

<syntaxhighlight lang="bash">
php -i | grep session.upload_progress.enabled
</syntaxhighlight>

Résultat attendu :

<syntaxhighlight lang="text">
session.upload_progress.enabled => Off => Off
</syntaxhighlight>

Sur les systèmes utilisant plusieurs versions PHP, chaque branche doit être contrôlée séparément.

== 5. Interventions sur les machines virtuelles ==

=== 5.1. TEMPLATE3 – VM 506 ===

'''Système :''' Ubuntu 26.04.1 LTS.

Versions PHP présentes après intervention :

* PHP 8.4.27
* PHP 8.5.12

Ces versions correspondent aux premières versions corrigées identifiées dans l'avis de sécurité.

Contrôles effectués :

* Versions PHP installées.
* Utilisation de PHP 8.4 par Apache.
* Vérification des configurations.
* Redémarrage de la VM.

'''État :''' intervention terminée pour les vulnérabilités PHP concernées.

=== 5.2. AD64 – VM 507 ===

'''Système :''' Ubuntu 26.04.1 LTS.

Versions PHP :

* PHP 8.4.27
* PHP 8.5.12

Interventions :

* Mise à jour des versions PHP.
* Contrôle de la configuration Apache.
* Vérification de la version PHP utilisée par le serveur Web.
* Redémarrage de la VM.

'''État :''' versions PHP corrigées installées.

Les contrôles fonctionnels Drupal/Pleade doivent rester intégrés à la validation des prochaines maintenances.

=== 5.3. APBP2 – VM 510 ===

'''Système :''' Ubuntu 26.04.1 LTS.

Versions PHP :

* PHP 8.4.27
* PHP 8.5.12

Interventions :

* Mise à jour PHP.
* Vérification de la configuration Apache utilisant PHP 8.4.
* Contrôle des services.
* Redémarrage de la VM.

'''État :''' versions PHP corrigées installées.

=== 5.4. DEVTOOLS2 / pleade.com – VM 508 ===

'''Version PHP :''' branche 7.2.

Mise à jour constatée :

<syntaxhighlight lang="text">
PHP 7.2 -> 7.2.24.17
</syntaxhighlight>

La branche PHP 7.2 étant ancienne, cette mise à jour ne doit pas être assimilée à une correction définitive des deux CVE.

Atténuation appliquée :

<syntaxhighlight lang="ini">
session.upload_progress.enabled = Off
</syntaxhighlight>

Contrôles réalisés :

* Configuration PHP.
* Fonctionnement d'Apache.
* Fonctionnement de Mantis.

'''État :''' service fonctionnel avec atténuation provisoire.

'''À faire :''' planifier le remplacement de PHP 7.2 par une branche maintenue, sous réserve de compatibilité applicative.

=== 5.5. DEVTOOLS – VM 513 ===

'''Version PHP :''' PHP 5.6.

Mesure appliquée :

<syntaxhighlight lang="ini">
session.upload_progress.enabled = Off
</syntaxhighlight>

'''État :''' atténuation provisoire.

'''À faire :'''

* Identifier les dépendances applicatives à PHP 5.6.
* Préparer une migration vers une version PHP maintenue.
* Vérifier les autres mécanismes de réduction d'exposition disponibles.

=== 5.6. ENCELADE – VM 514 ===

'''Version PHP :''' PHP 7.4.

Atténuation appliquée :

<syntaxhighlight lang="ini">
session.upload_progress.enabled = Off
</syntaxhighlight>

'''État :''' atténuation provisoire.

'''À faire :''' migration vers une version PHP maintenue ou remplacement de l'environnement ancien.

=== 5.7. MERCURE – VM 515 ===

'''Système :''' Ubuntu 20.04.6 LTS.

Versions PHP-FPM identifiées :

* PHP 7.2
* PHP 7.4
* PHP 8.0
* PHP 8.1

La mesure provisoire a été appliquée aux quatre branches.

<syntaxhighlight lang="ini">
session.upload_progress.enabled = Off
</syntaxhighlight>

Contrôles réalisés :

* Services PHP-FPM actifs.
* Vérification des configurations.
* Contrôle HTTP : réponse 200.
* Vérification de l'état applicatif.

Aucune mise à jour de paquet n'a été réalisée pendant cette intervention.

Des extensions manquantes avaient également été relevées pour PHP 7.2, notamment concernant memcache et uploadprogress.

'''État :''' atténuation appliquée ; applications accessibles.

'''Suite prévue :''' poursuivre la migration vers MERCURE3, plutôt que maintenir durablement cet environnement PHP ancien.

=== 5.8. CENTREON-R8 – VM 520 ===

Mise à jour PHP effectuée :

<syntaxhighlight lang="text">
PHP 8.2.30 -> PHP 8.2.35
</syntaxhighlight>

Contrôles réalisés :

* PHP-FPM 8.2.35 opérationnel.
* Extension SourceGuardian opérationnelle.
* Interface Centreon fonctionnelle.
* Métriques Centreon disponibles.

'''État :''' PHP corrigé.

'''Reste à faire :''' redémarrage de la VM pour activer le noyau système mis à jour.

=== 5.9. AD53 ===

Versions PHP concernées :

* PHP 7.2
* PHP 7.3
* PHP 8.0

L'intervention a porté sur '''11 fichiers php.ini''' correspondant aux différentes versions et aux différents contextes d'exécution.

Mesure appliquée :

<syntaxhighlight lang="ini">
session.upload_progress.enabled = Off
</syntaxhighlight>

Contrôles réalisés :

* Vérification des configurations PHP.
* Redémarrage ou rechargement des services PHP-FPM concernés.
* Contrôle d'Apache.
* Vérification du fonctionnement applicatif.

'''État :''' atténuation provisoire appliquée.

'''Attention :''' ces versions PHP restent anciennes. La désactivation de la progression des téléversements ne constitue pas une correction complète des vulnérabilités.

== 6. HAProxy-01 et HAProxy-02 ==

=== 6.1. Architecture ===

{| class="wikitable"
! Serveur
! Adresse
! Rôle
|-
| HAProxy-01
| 10.0.0.30
| MASTER nominal
|-
| HAProxy-02
| 10.0.0.31
| BACKUP nominal
|-
| VIP
| 10.0.0.32
| Adresse virtuelle Keepalived
|}

=== 6.2. Mises à jour ===

Les deux serveurs ont été mis à jour vers un état Ubuntu 24.04 LTS cohérent.

Versions vérifiées :

<syntaxhighlight lang="text">
Ubuntu 24.04 LTS
Linux 6.8.0-147-generic
HAProxy 2.8.16
Keepalived 2.2.8
</syntaxhighlight>

Les mises à jour ont concerné environ 182 et 177 paquets selon les opérations examinées.

Six paquets étaient temporairement retenus dans les résultats APT.

Les services suivants ont été contrôlés :

* HAProxy
* Keepalived
* systemd-networkd

Aucun PHP installé par APT n'a été identifié sur ces deux machines.

=== 6.3. Incident Keepalived ===

Pendant les mises à jour, des redémarrages de Keepalived ont provoqué des changements temporaires de rôle VRRP.

Un problème de droits a également été identifié dans le script de contrôle HAProxy.

Le script <code>chk_haproxy</code> était exécuté sous un compte ne disposant pas des permissions nécessaires pour contrôler les processus HAProxy.

Correction :

<syntaxhighlight lang="text">
user root
</syntaxhighlight>

Cette directive a été ajoutée dans le bloc <code>vrrp_script chk_haproxy</code>, en conservant les autres paramètres existants.

Priorités VRRP :

<syntaxhighlight lang="text">
HAProxy-01 : 103
HAProxy-02 : 102
</syntaxhighlight>

État final :

* HAProxy-01 : MASTER.
* HAProxy-02 : BACKUP.
* VIP présente sur HAProxy-01.

=== 6.4. Test fonctionnel ===

<syntaxhighlight lang="bash">
curl --resolve archives.lamayenne.fr:443:10.0.0.32 \
https://archives.lamayenne.fr/
</syntaxhighlight>

Résultat :

<syntaxhighlight lang="text">
HTTP 200
</syntaxhighlight>

'''État :''' fonctionnement confirmé pour le service testé.

=== 6.5. Points restant à vérifier ===

* Examiner les paquets APT retenus.
* Confirmer la stabilité de Keepalived lors des prochaines mises à jour.
* Refaire un test de bascule VRRP dans une fenêtre de maintenance.
* Vérifier la cohérence des configurations et certificats sur les deux HAProxy.

Les certificats et certaines configurations sont déployés séparément sur HAProxy-01 et HAProxy-02 : leur synchronisation ne doit pas être présumée automatique.

== 7. OPNsense – SaturneFW1 et SaturneFW2 ==

=== 7.1. Architecture ===

{| class="wikitable"
! Pare-feu
! Adresse
! Fonction
|-
| SaturneFW1
| 10.0.0.2
| Principal
|-
| SaturneFW2
| 10.0.0.3
| Secondaire
|-
| Interface Web
| TCP 453
| Administration HTTPS
|}

L'accès distant d'administration dépend notamment d'un VPN OpenVPN hébergé sur FW1.

Cette dépendance doit être prise en compte avant toute mise à jour ou redémarrage de FW1.

=== 7.2. État des versions ===

Sur FW2, les versions suivantes ont été constatées :

<syntaxhighlight lang="text">
OPNsense 26.1.6
FreeBSD 14 amd64
PHP 8.3.30
</syntaxhighlight>

Mise à jour proposée par le dépôt OPNsense :

<syntaxhighlight lang="text">
OPNsense 26.1.11_10
79 paquets
307,5 Mio à télécharger
Redémarrage requis
</syntaxhighlight>

Cette mise à jour reste dans la branche 26.1.

'''Décision :''' reporter la mise à jour complète pour disposer d'une fenêtre de maintenance suffisante.

=== 7.3. Accès d'administration à FW2 ===

Tunnel fonctionnel depuis le Mac via HAProxy-02 :

<syntaxhighlight lang="bash">
ssh -N -o ExitOnForwardFailure=yes \
-L 8453:10.0.0.3:453 \
hpr@10.0.0.31
</syntaxhighlight>

Accès navigateur :

<syntaxhighlight lang="text">
https://127.0.0.1:8453/
</syntaxhighlight>

Un problème a été constaté avec le même tunnel via HAProxy-01 :

* FW2 répond au ping depuis HAProxy-01.
* Le port TCP 453 de FW2 ne répond pas depuis HAProxy-01.
* Le même port est accessible depuis HAProxy-02.

'''À diagnostiquer :''' éventuelle règle de filtrage ou blocage dynamique de la source <code>10.0.0.30</code> sur FW2.

=== 7.4. Audit PHP sur FW2 ===

Inventaire :

<syntaxhighlight lang="sh">
pkg info -x '^php83'
</syntaxhighlight>

Version principale :

<syntaxhighlight lang="text">
php83-8.3.30
</syntaxhighlight>

Simulation de mise à jour :

<syntaxhighlight lang="sh">
pkg upgrade -n -g 'php83*'
</syntaxhighlight>

Résultat :

<syntaxhighlight lang="text">
23 paquets concernés
19 Mio à télécharger
4 Mio supplémentaires sur disque
</syntaxhighlight>

Principaux paquets :

{| class="wikitable"
! Paquet
! Installé
! Proposé
|-
| php83
| 8.3.30
| 8.3.31
|-
| php83-phalcon
| 5.10.0
| 5.16.0
|-
| php83-phpseclib
| 3.0.50
| 3.0.55
|-
| openssl
| 3.0.20
| 3.0.21
|-
| curl
| 8.19.0_2
| 8.21.0
|-
| sqlite3
| 3.50.4_2
| 3.53.1
|}

Une mise à jour PHP isolée aurait donc également modifié plusieurs bibliothèques système.

'''Décision :''' ne pas effectuer cette mise à jour partielle.

=== 7.5. Audit des vulnérabilités ===

Commande :

<syntaxhighlight lang="sh">
pkg audit -F
</syntaxhighlight>

Résultat :

<syntaxhighlight lang="text">
28 problem(s) in 11 package(s) found.
</syntaxhighlight>

Paquets concernés :

* unbound
* openssl
* ldns
* python313
* openvpn
* dnsmasq
* curl
* php83
* openssh-portable
* strongswan
* expat

Ces résultats justifient de ne pas différer indéfiniment la maintenance OPNsense.

=== 7.6. Vérification du correctif PHP proposé ===

Test de la version 8.3.31 :

<syntaxhighlight lang="sh">
pkg audit -f /var/db/pkg/vuln.xml php83-8.3.31
</syntaxhighlight>

Résultat :

<syntaxhighlight lang="text">
php83-8.3.31 is vulnerable:
CVE-2026-109619
CVE-2026-109618
</syntaxhighlight>

L'avis FreeBSD VuXML indique que la première version corrigée de PHP 8.3 est '''8.3.36'''.

'''Conclusion :''' le dépôt OPNsense examiné ne proposait pas encore une version PHP reconnue comme corrigée pour ces deux CVE.

Une mise à jour complète d'OPNsense reste nécessaire pour les autres vulnérabilités, mais ne doit pas être considérée comme suffisante pour PHP tant que ce point n'est pas vérifié.

=== 7.7. Identification du serveur Web OPNsense ===

Sur FW2 :

<syntaxhighlight lang="sh">
service php_fpm status
</syntaxhighlight>

Résultat :

<syntaxhighlight lang="text">
php_fpm is not running.
</syntaxhighlight>

Recherche des processus :

<syntaxhighlight lang="sh">
ps auxww | grep -E '[l]ighttpd|[p]hp-cgi|[p]hp-fpm'
</syntaxhighlight>

Processus identifiés :

* lighttpd
* php-cgi

Fichier de configuration :

<syntaxhighlight lang="text">
/usr/local/etc/lighttpd_webgui/lighttpd.conf
</syntaxhighlight>

Configuration FastCGI observée :

<syntaxhighlight lang="text">
"max-procs" => 8,
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "5",
"PHP_FCGI_MAX_REQUESTS" => "100"
),
"bin-path" => "/usr/local/bin/php-cgi"
</syntaxhighlight>

'''Conclusion :''' l'interface d'administration OPNsense utilise lighttpd avec PHP-CGI, et non PHP-FPM.

=== 7.8. Atténuation appliquée sur FW2 ===

État initial :

<syntaxhighlight lang="text">
Loaded Configuration File => /usr/local/etc/php.ini
session.upload_progress.enabled => On => On
</syntaxhighlight>

Le paramètre n'était défini explicitement ni dans <code>php.ini</code> ni dans les fichiers complémentaires examinés.

Sauvegarde :

<syntaxhighlight lang="sh">
cp -p /usr/local/etc/php.ini \
/usr/local/etc/php.ini.bak-20261022
</syntaxhighlight>

Modification :

<syntaxhighlight lang="sh">
printf '\n; Mitigation provisoire PHP2Shell\nsession.upload_progress.enabled = Off\n' >> /usr/local/etc/php.ini
</syntaxhighlight>

Contrôle :

<syntaxhighlight lang="sh">
php -i | grep session.upload_progress.enabled
</syntaxhighlight>

Résultat :

<syntaxhighlight lang="text">
session.upload_progress.enabled => Off => Off
</syntaxhighlight>

Le redémarrage classique de lighttpd a été refusé :

<syntaxhighlight lang="text">
Cannot 'restart' lighttpd.
Set lighttpd_enable to YES in /etc/rc.conf
or use 'onerestart' instead of 'restart'.
</syntaxhighlight>

Commande de redémarrage retenue :

<syntaxhighlight lang="sh">
service lighttpd onerestart
</syntaxhighlight>

L'intervention a été signalée comme terminée.

=== 7.9. Atténuation appliquée sur FW1 ===

La console OPNsense utilise <code>csh</code>.

Les commandes saisies avec <code>&&</code> en fin de ligne ont provoqué :

<syntaxhighlight lang="text">
Invalid null command.
</syntaxhighlight>

Les commandes ont donc été exécutées séparément.

Sauvegarde :

<syntaxhighlight lang="sh">
cp -p /usr/local/etc/php.ini \
/usr/local/etc/php.ini.bak-20261022
</syntaxhighlight>

Modification :

<syntaxhighlight lang="sh">
printf '\n; Mitigation provisoire PHP2Shell\nsession.upload_progress.enabled = Off\n' >> /usr/local/etc/php.ini
</syntaxhighlight>

Contrôle :

<syntaxhighlight lang="sh">
php -i | grep session.upload_progress.enabled
</syntaxhighlight>

Résultat :

<syntaxhighlight lang="text">
session.upload_progress.enabled => Off => Off
</syntaxhighlight>

Redémarrage demandé :

<syntaxhighlight lang="sh">
service lighttpd onerestart
</syntaxhighlight>

L'intervention a été confirmée comme terminée.

=== 7.10. État des deux pare-feu ===

{| class="wikitable"
! Contrôle
! FW1
! FW2
|-
| Sauvegarde php.ini
| Effectuée
| Effectuée
|-
| upload_progress désactivé
| Oui
| Oui
|-
| Vérification PHP CLI
| Off
| Off
|-
| Redémarrage lighttpd
| Signalé terminé
| Signalé terminé
|-
| Vérification indépendante PHP-CGI
| À compléter
| À compléter
|-
| Mise à jour complète OPNsense
| Restante
| Restante
|-
| Correctif PHP définitif
| À vérifier
| Non disponible dans le dépôt examiné
|}

== 8. Proposition de protection Coraza ==

Des règles de filtrage supplémentaires ont été envisagées sur les deux HAProxy, notamment :

* Blocage des cookies contenant <code>PHPSESSID</code>.
* Blocage de <code>PHPSESSID</code> dans la chaîne de requête.
* Blocage des requêtes <code>multipart/form-data</code>.

'''Décision : ne pas déployer globalement ces règles.'''

Motifs :

* <code>PHPSESSID</code> est un identifiant de session PHP légitime.
* Le blocage de <code>multipart/form-data</code> empêcherait des téléversements et formulaires légitimes.
* Les règles globales pourraient perturber Drupal, Pleade et d'autres applications.
* Les interfaces OPNsense accessibles directement ne traversent pas nécessairement Coraza.
* Ces règles ne constituent pas une garantie de protection contre les deux CVE.

Une protection WAF ciblée pourra être réétudiée après analyse des chemins d'exploitation concernés.

== 9. Travaux restant à effectuer ==

=== 9.1. Priorité haute – OPNsense ===

# Préparer une fenêtre de maintenance.
# Sauvegarder les configurations FW1 et FW2.
# Vérifier l'accès console ou un accès indépendant du VPN hébergé sur FW1.
# Mettre à jour FW2 vers une version OPNsense officiellement prise en charge.
# Contrôler les services, l'administration Web, les VPN et la haute disponibilité.
# Mettre à jour FW1 après validation de FW2.
# Vérifier les versions PHP réellement installées.
# Vérifier la disponibilité de PHP 8.3.36 ou d'un correctif rétroporté équivalent.
# Relancer <code>pkg audit -F</code>.
# Vérifier la persistance de l'atténuation <code>session.upload_progress.enabled = Off</code>.
# Ne supprimer l'atténuation qu'après validation d'une correction définitive.

=== 9.2. Priorité haute – Anciennes versions PHP ===

Machines concernées notamment :

* AD53 : PHP 7.2 / 7.3 / 8.0.
* DEVTOOLS2 : PHP 7.2.
* DEVTOOLS : PHP 5.6.
* ENCELADE : PHP 7.4.
* MERCURE : PHP 7.2 / 7.4 / 8.0 / 8.1.

Actions :

# Conserver les atténuations provisoires.
# Vérifier leur application effective dans les processus Web.
# Identifier les contraintes applicatives empêchant la montée de version.
# Préparer les migrations vers des versions PHP maintenues.
# Suivre les éventuels correctifs de sécurité fournis par les distributions ou mainteneurs concernés.
# Réaliser des tests applicatifs avant toute migration majeure.

'''Attention :''' les versions PHP anciennes peuvent présenter d'autres vulnérabilités indépendantes des deux CVE traitées ici.

=== 9.3. Priorité moyenne – CENTREON-R8 ===

* Effectuer le redémarrage nécessaire pour activer le nouveau noyau.
* Vérifier Centreon après redémarrage.
* Contrôler la collecte des métriques et les services associés.

=== 9.4. Priorité moyenne – HAProxy ===

* Examiner les paquets APT retenus.
* Contrôler la stabilité de Keepalived.
* Refaire un test de bascule VRRP.
* Vérifier la cohérence des configurations sur HAProxy-01 et HAProxy-02.
* Diagnostiquer le blocage d'accès au port 453 de FW2 depuis HAProxy-01.

=== 9.5. Vérifications transversales ===

* Contrôler les versions PHP réellement utilisées par Apache, PHP-FPM et PHP-CGI.
* Vérifier les applications après les prochaines mises à jour.
* Vérifier la persistance des modifications manuelles après régénération de configuration.
* Conserver les sauvegardes de configuration jusqu'à validation complète.
* Actualiser l'inventaire des VM et leur état de sécurité.

== 10. Commandes de contrôle ==

=== 10.1. Ubuntu – Versions et mises à jour ===

<syntaxhighlight lang="bash">
cat /etc/os-release

apt list --upgradable

php -v

php -i | grep session.upload_progress.enabled

systemctl --failed
</syntaxhighlight>

=== 10.2. OPNsense – Versions et vulnérabilités ===

<syntaxhighlight lang="sh">
pkg info -x '^php83'

pkg audit -F

php -v

php -i | grep session.upload_progress.enabled
</syntaxhighlight>

Simulation de mise à jour PHP, sans installation :

<syntaxhighlight lang="sh">
pkg upgrade -n -g 'php83*'
</syntaxhighlight>

=== 10.3. OPNsense – Processus Web ===

<syntaxhighlight lang="sh">
ps auxww | grep -E '[l]ighttpd|[p]hp-cgi|[p]hp-fpm'
</syntaxhighlight>

Redémarrage de lighttpd lorsque nécessaire :

<syntaxhighlight lang="sh">
service lighttpd onerestart
</syntaxhighlight>

=== 10.4. OPNsense – Retour arrière de la mitigation ===

'''À utiliser uniquement si la modification doit être annulée.'''

<syntaxhighlight lang="sh">
cp -p /usr/local/etc/php.ini.bak-20261022 \
/usr/local/etc/php.ini
</syntaxhighlight>

Puis :

<syntaxhighlight lang="sh">
service lighttpd onerestart
</syntaxhighlight>

'''Attention :''' ce retour arrière réactive potentiellement le mécanisme PHP ayant motivé l'atténuation.

== 11. Plan de reprise des interventions ==

{| class="wikitable"
! Ordre
! Machine(s)
! Action
! Validation attendue
|-
| 1
| FW2
| Sauvegarde et mise à jour OPNsense
| Services et administration fonctionnels
|-
| 2
| FW2
| Contrôle PHP et audit de sécurité
| Vulnérabilités restantes identifiées
|-
| 3
| FW1
| Sauvegarde et mise à jour OPNsense
| VPN, routage et administration fonctionnels
|-
| 4
| FW1 / FW2
| Vérification HA et configurations PHP
| Bascule et mitigation contrôlées
|-
| 5
| CENTREON-R8
| Redémarrage noyau
| Centreon et métriques fonctionnels
|-
| 6
| MERCURE
| Poursuite migration MERCURE3
| Réduction des dépendances PHP anciennes
|-
| 7
| AD53 / DEVTOOLS / ENCELADE
| Planification migration PHP
| Applications compatibles avec une branche maintenue
|-
| 8
| HAProxy-01 / HAProxy-02
| Contrôles VRRP et paquets retenus
| Haute disponibilité stable
|}

== 12. Conclusion ==

Les interventions des 21 et 22 octobre 2026 ont permis :

* De corriger les versions PHP sur plusieurs VM récentes.
* De mettre en place une atténuation provisoire sur les environnements PHP anciens.
* De sécuriser provisoirement les interfaces PHP des deux OPNsense.
* De mettre à jour les deux HAProxy et de corriger leur surveillance Keepalived.
* D'identifier les vulnérabilités restant présentes sur OPNsense.

'''Les travaux ne sont pas terminés.'''

Les deux priorités restantes sont :

# '''Effectuer les mises à jour complètes des deux OPNsense dans une fenêtre de maintenance sécurisée.'''
# '''Remplacer progressivement les anciennes versions PHP, dont la mitigation actuelle ne constitue pas un correctif définitif.'''

La correction des CVE PHP devra être vérifiée à partir des versions réellement installées, des éventuels correctifs rétroportés et des avis de sécurité officiels.

Matomo/Maintenance

Jlarvers — Tue, 20 Oct 2026 11:06:50 GMT

Exemple de tâche cron :

← Version précédente		Version du 20 octobre 2026 à 11:06
(Une version intermédiaire par le même utilisateur non affichée)
Ligne 21 :		Ligne 21 :
	* [[Matomo/HAProxy]]		* [[Matomo/HAProxy]]
	* [[Matomo/Debug]]		* [[Matomo/Debug]]
			=== Portée de cette documentation ===

			Cette procédure est générique et s'applique aux installations Matomo
			hébergées sur les VM AJLSM.

			Les références à '''AD64''' correspondent à un exemple réel
			d'installation, vérifié en octobre 2026.

			Elles illustrent les choix techniques effectués sur ce projet,
			mais ne constituent pas des paramètres obligatoires pour les
			futures installations.

			Les versions logicielles, chemins, domaines, fréquences d'archivage
			et modalités de sauvegarde doivent être adaptés à chaque environnement.

	== 1. Vérifications courantes ==		== 1. Vérifications courantes ==
Ligne 248 :		Ligne 262 :
	Exemple de configuration pour un archivage toutes les heures :		Exemple de configuration pour un archivage toutes les heures :

	<syntaxhighlight lang="~~cron~~">		<syntaxhighlight lang="bash">
	0 * * * * /usr/bin/php /var/www/matomo/console core:archive --url=https://matomo.exemple.fr/ >> /var/log/matomo-archive.log 2>&1		0 * * * * /usr/bin/php /var/www/matomo/console core:archive --url=https://matomo.exemple.fr/ >> /var/log/matomo-archive.log 2>&1
	</syntaxhighlight>		</syntaxhighlight>

Matomo/Maintenance

Jlarvers — Tue, 20 Oct 2026 11:04:34 GMT

Page créée avec « = Maintenance de Matomo = == Objectif == Cette procédure décrit la maintenance des installations Matomo hébergées sur les VM AJLSM. Elle couvre : * La surveillance... »

Nouvelle page

= Maintenance de Matomo =

== Objectif ==

Cette procédure décrit la maintenance des installations Matomo hébergées sur les VM AJLSM.

Elle couvre :

* La surveillance des services.
* Les mises à jour de Matomo.
* Les sauvegardes et la restauration.
* L'archivage des statistiques.
* La vérification de la collecte.
* Les contrôles de sécurité.

Voir également :

* [[Matomo/Installation]]
* [[Matomo/Apache]]
* [[Matomo/Drupal]]
* [[Matomo/HAProxy]]
* [[Matomo/Debug]]

== 1. Vérifications courantes ==

=== Version de Matomo ===

<syntaxhighlight lang="bash">
cd /var/www/matomo
sudo -u www-data php console core:version
</syntaxhighlight>

=== Services Apache et MariaDB ===

<syntaxhighlight lang="bash">
systemctl is-active apache2
systemctl is-active mariadb
</syntaxhighlight>

Si la VM utilise PHP-FPM, vérifier également le service correspondant :

<syntaxhighlight lang="bash">
systemctl is-active php8.4-fpm
</syntaxhighlight>

'''Important :''' PHP-FPM n'est pas nécessaire lorsque PHP est exécuté par Apache avec `mod_php`, comme sur AD64.

=== Espace disque ===

<syntaxhighlight lang="bash">
df -h
du -sh /var/www/matomo
</syntaxhighlight>

=== Taille de la base Matomo ===

<syntaxhighlight lang="bash">
sudo mariadb -t -e "
SELECT
table_schema AS base,
ROUND(SUM(data_length + index_length)/1024/1024, 2) AS taille_Mo
FROM information_schema.tables
WHERE table_schema = 'matomo'
GROUP BY table_schema;
"
</syntaxhighlight>

La taille de la base doit être surveillée, notamment lorsque le nombre de visites et la durée de conservation des données augmentent.

== 2. Mise à jour de Matomo ==

=== Méthode habituelle AJLSM ===

Les mises à jour de Matomo sont proposées directement dans son interface d'administration.

Sur AD64, les précédentes mises à jour ont été réalisées depuis cette interface, sans passer par le terminal.

Cette méthode est retenue comme procédure habituelle.

=== Avant la mise à jour ===

# Vérifier la compatibilité de la nouvelle version avec PHP et MariaDB.
# Vérifier l'espace disque disponible.
# Effectuer une sauvegarde de la base MariaDB.
# Sauvegarder les fichiers de configuration et les éventuels plugins personnalisés.
# Vérifier que les sauvegardes sont exploitables.

Exemple de sauvegarde manuelle de la base :

<syntaxhighlight lang="bash">
sudo mariadb-dump --single-transaction \
--routines --triggers --events \
matomo > "$HOME/matomo-$(date +%Y%m%d-%H%M%S).sql"
</syntaxhighlight>

'''Attention :''' cette commande crée une sauvegarde ponctuelle dans le répertoire personnel de l'utilisateur courant. Elle ne remplace pas la stratégie de sauvegarde générale de la VM.

Vérifier également les sauvegardes existantes avant toute intervention importante.

=== Effectuer la mise à jour ===

# Se connecter à l'administration Matomo depuis une adresse IP autorisée.
# Ouvrir la notification de nouvelle version.
# Lire les informations et les prérequis.
# Lancer la mise à jour depuis l'interface.
# Effectuer, si demandé, la mise à jour de la base de données.
# Attendre la confirmation de fin d'opération.

Ne pas interrompre une mise à jour en cours.

=== Après la mise à jour ===

Vérifier :

* La version affichée par Matomo.
* L'accès à l'interface d'administration.
* L'absence d'erreurs dans les journaux.
* Le fonctionnement des rapports.
* La réception de nouvelles visites.
* Le fonctionnement des plugins installés.

Commande de vérification :

<syntaxhighlight lang="bash">
cd /var/www/matomo
sudo -u www-data php console core:version
</syntaxhighlight>

== 3. Sauvegardes ==

=== Éléments à sauvegarder ===

Une sauvegarde exploitable doit couvrir :

* La base MariaDB `matomo`.
* Le fichier `/var/www/matomo/config/config.ini.php`.
* Les plugins ou personnalisations non fournis par l'installation standard.
* Les autres fichiers spécifiques à l'installation, s'il en existe.

Le code standard de Matomo peut être réinstallé, mais la base de données et la configuration sont indispensables à la restitution de l'installation.

=== Sauvegarde de la base ===

Exemple de sauvegarde compressée :

<syntaxhighlight lang="bash">
sudo mariadb-dump --single-transaction \
--routines --triggers --events \
matomo | gzip > "$HOME/matomo-$(date +%Y%m%d-%H%M%S).sql.gz"
</syntaxhighlight>

Protéger les sauvegardes : elles peuvent contenir des informations sur les visiteurs et des données de configuration sensibles.

=== Sauvegarde de la configuration ===

<syntaxhighlight lang="bash">
sudo tar -czf "$HOME/matomo-config-$(date +%Y%m%d-%H%M%S).tar.gz" \
-C /var/www/matomo \
config
</syntaxhighlight>

Les archives doivent être conservées dans un emplacement protégé, idéalement distinct de la VM.

=== Sauvegardes de l'infrastructure ===

Avant d'ajouter une sauvegarde spécifique, vérifier si Matomo est déjà couvert par :

* Les sauvegardes de la VM Proxmox.
* Les sauvegardes applicatives existantes.
* Les sauvegardes MariaDB éventuellement configurées sur la VM.

'''Important :''' la présence d'une sauvegarde ne garantit pas sa restaurabilité. Un test de restauration doit être prévu.

=== Restauration ===

Une restauration doit être préparée en fonction de l'incident.

La procédure générale consiste à :

# Préserver l'état actuel avant toute intervention.
# Identifier une sauvegarde cohérente de la base et des fichiers.
# Restaurer dans un environnement de test lorsque cela est possible.
# Vérifier la compatibilité entre la version du code Matomo et le schéma de la base restaurée.
# Restaurer les données et la configuration.
# Vérifier les permissions.
# Tester l'interface et la collecte.

Ne pas restaurer directement une ancienne base sur une installation Matomo plus récente sans avoir vérifié la compatibilité.

== 4. Archivage des statistiques ==

=== Principe ===

Matomo calcule des rapports statistiques à partir des données de visites.

Deux méthodes principales sont possibles :

* Archivage déclenché par la consultation des rapports dans le navigateur.
* Archivage automatique par une tâche planifiée exécutant `core:archive`.

=== Méthode 1 : archivage depuis le navigateur ===

Cette méthode est utilisée sur AD64 en octobre 2026.

Dans l'administration Matomo :

'''Administration → Système → Paramètres généraux → Paramètres d'archivage'''

Configuration constatée :

{| class="wikitable"
! Paramètre
! Valeur AD64
|-
| Archiver les rapports lorsqu'ils sont affichés depuis le navigateur
| Oui
|-
| Archiver les rapports au plus toutes les X secondes
| 900 secondes (15 minutes)
|}

Les rapports peuvent donc être calculés lors de leur consultation.

Cette configuration convient à une installation de faible volume, notamment lors de la mise en service.

Elle peut cependant provoquer des calculs au moment où un utilisateur consulte les statistiques.

=== Méthode 2 : archivage automatique ===

Pour une installation plus sollicitée, un archivage planifié est préférable.

Matomo fournit la commande :

<syntaxhighlight lang="bash">
sudo -u www-data php /var/www/matomo/console core:archive
</syntaxhighlight>

'''Attention :''' cette commande lance réellement l'archivage. Ne pas l'exécuter pour une simple vérification.

Pour afficher les options sans lancer de traitement :

<syntaxhighlight lang="bash">
sudo -u www-data php /var/www/matomo/console core:archive --help
</syntaxhighlight>

=== Exemple de tâche cron ===

Exemple de configuration pour un archivage toutes les heures :

<syntaxhighlight lang="cron">
0 * * * * /usr/bin/php /var/www/matomo/console core:archive --url=https://matomo.exemple.fr/ >> /var/log/matomo-archive.log 2>&1
</syntaxhighlight>

Cette ligne est un '''exemple de configuration''', et non une tâche déjà installée sur AD64.

Elle doit être adaptée avant utilisation :

* À l'URL réelle de Matomo.
* À l'utilisateur d'exécution PHP.
* Aux permissions du fichier journal.
* À la fréquence d'archivage souhaitée.
* Aux restrictions réseau ou HAProxy.

Le processus d'archivage doit pouvoir joindre les ressources Matomo nécessaires. Une interface d'administration protégée par HAProxy peut imposer une configuration particulière de l'URL utilisée.

=== Passage à l'archivage automatique ===

Avant de mettre en service une tâche planifiée :

# Vérifier le bon fonctionnement de la commande `core:archive`.
# Vérifier que l'URL utilisée est accessible depuis la VM.
# Configurer une tâche planifiée sous l'utilisateur approprié.
# Vérifier les journaux d'exécution.
# Contrôler que les rapports sont correctement actualisés.
# Désactiver ensuite l'archivage déclenché par le navigateur dans les paramètres généraux de Matomo, conformément à la configuration retenue.

'''Ne pas désactiver l'archivage depuis le navigateur avant d'avoir confirmé le fonctionnement de l'archivage automatique.'''

== 5. Vérification de la collecte ==

=== Tests HTTP ===

Depuis une connexion extérieure au réseau AJLSM :

<syntaxhighlight lang="bash">
MATOMO_URL="https://matomo.exemple.fr"

for RESOURCE in matomo.js matomo.php; do
echo "===== /$RESOURCE ====="

curl -sS -o /dev/null -w "HTTP %{http_code}\n" \
"$MATOMO_URL/$RESOURCE"
done
</syntaxhighlight>

Pour une installation utilisant les ACL HAProxy décrites dans [[Matomo/HAProxy]], les ressources de collecte doivent rester accessibles publiquement.

=== Vérification en base ===

<syntaxhighlight lang="sql">
SELECT
idsite,
COUNT(*) AS visites,
MAX(visit_last_action_time) AS derniere_activite
FROM matomo_log_visit
GROUP BY idsite;
</syntaxhighlight>

La présence de visites récentes confirme que des données sont enregistrées.

Cette requête ne permet cependant pas, à elle seule, de vérifier l'exactitude de tous les rapports.

=== Vérification depuis Drupal ===

Consulter une page publique de l'application Drupal suivie.

Vérifier ensuite :

* Que le script Matomo est chargé.
* Qu'une requête de suivi est transmise.
* Qu'aucune erreur de suivi n'apparaît.
* Que la visite est enregistrée sur le bon identifiant de site Matomo.

Voir [[Matomo/Drupal]].

== 6. Certificats et sécurité ==

=== HTTPS ===

Pour les installations publiées par HAProxy, le certificat public est généralement géré sur les répartiteurs.

Vérifier la date d'expiration :

<syntaxhighlight lang="bash">
openssl s_client \
-connect matomo.exemple.fr:443 \
-servername matomo.exemple.fr </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates
</syntaxhighlight>

Vérifier également le renouvellement automatique et le déploiement effectif du certificat.

Voir [[Matomo/HAProxy]].

=== Restrictions d'accès ===

Lorsque l'administration est réservée à AJLSM :

* L'interface Matomo doit être inaccessible depuis une IP extérieure non autorisée.
* Les points de collecte nécessaires doivent rester accessibles.
* L'accès à l'administration doit rester possible depuis le réseau autorisé.

=== Permissions ===

Vérifier périodiquement les permissions des fichiers sensibles :

<syntaxhighlight lang="bash">
stat -c '%A %a %U:%G %n' \
/var/www/matomo \
/var/www/matomo/config/config.ini.php
</syntaxhighlight>

Voir [[Matomo/Installation]] pour les permissions recommandées.

== 7. Journaux et diagnostic ==

En cas de dysfonctionnement, consulter les journaux Apache :

<syntaxhighlight lang="bash">
sudo journalctl -u apache2 --since "1 hour ago" --no-pager
</syntaxhighlight>

Les fichiers de logs Apache peuvent également être consultés dans `/var/log/apache2/`, selon la configuration du VirtualHost.

Pour MariaDB :

<syntaxhighlight lang="bash">
sudo journalctl -u mariadb --since "1 hour ago" --no-pager
</syntaxhighlight>

Vérifier aussi les journaux et messages d'erreur propres à Matomo.

Voir [[Matomo/Debug]].

== 8. Retour d'expérience AD64 — octobre 2026 ==

{| class="wikitable"
! Élément
! Situation constatée
|-
| Matomo
| Version 5.10.1
|-
| Serveur
| ad64
|-
| Répertoire
| /var/www/matomo
|-
| Serveur web
| Apache avec mod_php et mpm_prefork
|-
| Base de données
| MariaDB, base matomo
|-
| Taille de la base
| 5,70 Mo au 20 octobre 2026
|-
| Mise à jour Matomo
| Depuis l'interface d'administration
|-
| Archivage
| Déclenché depuis le navigateur
|-
| Fréquence d'archivage configurée
| 900 secondes
|-
| Cron core:archive
| Aucune tâche identifiée dans les emplacements examinés
|-
| Sites suivis
| Drupal Internet et Salle de lecture
|-
| Administration
| Restreinte par HAProxy aux adresses AJLSM autorisées
|}

=== Points restant à vérifier ===

* La couverture exacte de Matomo par les sauvegardes existantes.
* La présence éventuelle d'une sauvegarde MariaDB indépendante.
* Le test de restauration.
* Le renouvellement effectif du certificat public lors de sa prochaine échéance.

'''Conclusion :''' AD64 fonctionne actuellement avec un archivage à la demande et des mises à jour réalisées depuis l'interface Matomo. Il n'est pas nécessaire de modifier immédiatement cette configuration. Pour les futures installations, les sauvegardes et l'archivage automatique devront être évalués selon le volume et les exigences du projet.

Matomo/Installation

Jlarvers — Tue, 20 Oct 2026 10:56:09 GMT

1. Environnement technique :

← Version précédente		Version du 20 octobre 2026 à 10:56
(2 versions intermédiaires par le même utilisateur non affichées)
Ligne 16 :		Ligne 16 :
	== 1. Environnement technique ==		== 1. Environnement technique ==

	=== Versions ~~d'Ubuntu et de~~ PHP ===		Matomo fonctionne avec Apache 2.4, PHP et MariaDB/MySQL.

			Deux modes d'exécution de PHP sont possibles :

			* '''mod_php''' : PHP est exécuté directement par Apache.
			* '''PHP-FPM''' : PHP est exécuté par un service indépendant auquel Apache transmet les requêtes PHP.

			Le choix dépend de la configuration de la VM. Il n'est pas nécessaire d'installer PHP-FPM lorsque Matomo fonctionne déjà avec mod_php.

			=== Versions PHP ===

	{\| class="wikitable"		{\| class="wikitable"
	! Ubuntu		! Ubuntu
	! PHP		! Version PHP de référence
	! ~~Statut documentaire~~		! Observations
	\|-		\|-
	\| Ubuntu 18.04		\| Ubuntu 18.04
	\| PHP 8.1 ~~via PHP-FPM~~		\| PHP 8.1
	\| Installation historique~~, hors support standard~~		\| Installation historique avec version PHP ajoutée séparément
	\|-		\|-
	\| Ubuntu 24.04		\| Ubuntu 24.04
	\| PHP 8.3 ~~via PHP-FPM~~		\| PHP 8.3
	\| ~~Installation existante~~		\| Version fournie par Ubuntu
	\|-		\|-
	\| Ubuntu 26.04		\| Ubuntu 26.04
	\| PHP 8.4 ~~via PHP-FPM~~		\| PHP 8.4
	\| ~~Environnement utilisé pour~~ AD64 en octobre 2026		\| Version utilisée sur AD64 en octobre 2026
	\|}		\|}

	~~'''Important :''' vérifier~~ la compatibilité entre la version de Matomo ~~et celle de PHP avant toute nouvelle installation ou mise à jour~~.		Vérifier systématiquement la compatibilité entre PHP et la version de Matomo installée.

	=== Composants nécessaires ===		=== Composants nécessaires ===

	* Apache 2.4		* Apache 2.4
	* PHP-FPM		* PHP avec '''mod_php''' ou '''PHP-FPM'''
	* MariaDB ou MySQL		* MariaDB ou MySQL
	* Extensions PHP requises par Matomo		* Extensions PHP requises par Matomo
Ligne 74 :		Ligne 83 :
	</syntaxhighlight>		</syntaxhighlight>

	== 3. ~~Activation de~~ PHP-FPM ==		== 3. Configuration PHP avec Apache ==

			=== Identifier le mode PHP utilisé ===

			<syntaxhighlight lang="bash">
			apache2ctl -M 2>/dev/null \| grep -E 'php_module\|proxy_fcgi_module\|mpm_'

			systemctl list-units --all 'php*-fpm.service' --no-pager

			php -v
			</syntaxhighlight>

			'''Attention :''' la présence du module proxy_fcgi_module ne signifie pas nécessairement que PHP-FPM est utilisé. Il faut également vérifier les VirtualHosts et les gestionnaires PHP configurés.

			=== Cas 1 : Apache avec mod_php ===

			Dans cette configuration, PHP est exécuté directement par Apache.

			Exemple observé sur AD64 :

			<syntaxhighlight lang="text">
			mpm_prefork_module (shared)
			php_module (shared)
			</syntaxhighlight>

			Aucun service PHP-FPM n'est nécessaire.

			Vérifier qu'Apache fonctionne :

			<syntaxhighlight lang="bash">
			systemctl is-active apache2
			</syntaxhighlight>

			Pour une nouvelle installation utilisant ce mode, installer le module Apache correspondant à la version PHP disponible, par exemple :

			<syntaxhighlight lang="bash">
			sudo apt install libapache2-mod-php
			</syntaxhighlight>

			Ne pas modifier le mode d'exécution PHP d'une VM existante sans vérifier les autres applications hébergées.

	Exemple ~~pour~~ PHP 8.4 :		=== Cas 2 : Apache avec PHP-FPM ===

			PHP-FPM est une autre architecture possible, notamment lorsqu'une VM utilise plusieurs pools PHP.

			Exemple avec PHP 8.4 :

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	sudo apt install php8.4-fpm		sudo apt install php8.4-fpm

	sudo a2enmod proxy_fcgi setenvif		sudo a2enmod proxy_fcgi setenvif
	sudo a2enconf php8.4-fpm		sudo a2enconf php8.4-fpm

			sudo apache2ctl configtest
	sudo systemctl reload apache2		sudo systemctl reload apache2
	</syntaxhighlight>		</syntaxhighlight>

	Vérifier ~~le service~~ :		Vérifier ensuite :

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	systemctl ~~status~~ php8.4-fpm		systemctl is-active php8.4-fpm
	</syntaxhighlight>		</syntaxhighlight>

	'''~~Attention~~ :''' ~~sur une VM hébergeant~~ plusieurs applications PHP, ~~vérifier les configurations Apache existantes avant~~ d'~~activer~~ une configuration PHP-FPM ~~globale~~.		'''Important :''' si plusieurs applications utilisent différentes versions de PHP, privilégier une configuration explicite par VirtualHost ou par pool plutôt que l'activation systématique d'une configuration globale.

			=== Retour d'expérience AD64 — octobre 2026 ===

			L'installation Matomo 5.10.1 sur AD64 utilise :

			Apache 2.4

			PHP 8.4

			mod_php

			mpm_prefork

			MariaDB

			Aucun service PHP-FPM n'est actif.

			Cette configuration est fonctionnelle et ne nécessite aucune modification.

	== 4. Préparation de MariaDB ==		== 4. Préparation de MariaDB ==

Matomo/HAProxy

Jlarvers — Tue, 20 Oct 2026 10:51:01 GMT

Exemple générique :

← Version précédente		Version du 20 octobre 2026 à 10:51
(7 versions intermédiaires par le même utilisateur non affichées)
Ligne 106 :		Ligne 106 :
	Ajouter les règles suivantes dans le frontend HAProxy approprié :		Ajouter les règles suivantes dans le frontend HAProxy approprié :

	<syntaxhighlight lang="~~haproxy~~">		<syntaxhighlight lang="yaml">
	# MATOMO - PROJET		# MATOMO - PROJET
	acl host_projet_matomo hdr(host),host_only -i matomo.exemple.fr		acl host_projet_matomo hdr(host),host_only -i matomo.exemple.fr
Ligne 133 :		Ligne 133 :
	=== Exemple HTTPS ===		=== Exemple HTTPS ===

	<syntaxhighlight lang="~~haproxy~~">		<syntaxhighlight lang="yaml">
	backend back_ssl_projet_matomo		backend back_ssl_projet_matomo
	server SSLPROJETMATOMO 10.0.0.X:443 check ssl verify none sni str(matomo.exemple.fr)		server SSLPROJETMATOMO 10.0.0.X:443 check ssl verify none sni str(matomo.exemple.fr)
Ligne 148 :		Ligne 148 :
	Un backend HTTP peut également être utilisé sur un réseau interne maîtrisé :		Un backend HTTP peut également être utilisé sur un réseau interne maîtrisé :

	<syntaxhighlight lang="~~haproxy~~">		<syntaxhighlight lang="yaml">
	backend back_projet_matomo		backend back_projet_matomo
	server PROJETMATOMO 10.0.0.X:80 check		server PROJETMATOMO 10.0.0.X:80 check
Ligne 178 :		Ligne 178 :

	== 7. Déploiement avec Ansible ==		== 7. Déploiement avec Ansible ==
			Voir aussi la configuration du WAF avec ansible : [[WAF_2026#Ansible\|WAF 2026]]
	=== Modification ===		=== Modification ===

Ligne 327 :		Ligne 327 :
	=== Configuration HAProxy ===		=== Configuration HAProxy ===

	<syntaxhighlight lang="~~haproxy~~">		<syntaxhighlight lang="yaml">
	# AD64 MATOMO		# AD64 MATOMO
	acl host_ad64_matomo hdr(host),host_only -i ad64-matomo.pleade.com		acl host_ad64_matomo hdr(host),host_only -i ad64-matomo.pleade.com
Ligne 344 :		Ligne 344 :
	Backend HTTPS existant :		Backend HTTPS existant :

	<syntaxhighlight lang="~~haproxy~~">		<syntaxhighlight lang="yaml">
	backend back_ssl_ad64_matomo		backend back_ssl_ad64_matomo
	server SSLAD64MATOMO 10.0.0.41:443 check ssl verify none sni str(ad64-matomo.pleade.com)		server SSLAD64MATOMO 10.0.0.41:443 check ssl verify none sni str(ad64-matomo.pleade.com)

Matomo/HAProxy

Jlarvers — Tue, 20 Oct 2026 10:40:43 GMT

Page créée avec « = Publication et sécurisation de Matomo avec HAProxy = == Objectif == Cette procédure décrit la publication d'une instance Matomo derrière les répartiteurs HAProxy ... »

Nouvelle page

= Publication et sécurisation de Matomo avec HAProxy =

== Objectif ==

Cette procédure décrit la publication d'une instance Matomo derrière les répartiteurs HAProxy d'AJLSM.

Elle permet de :

* Publier Matomo en HTTPS.
* Autoriser les requêtes de collecte des statistiques provenant des visiteurs.
* Réserver l'interface d'administration aux adresses IP autorisées.
* Déployer une configuration identique sur les deux HAProxy à l'aide d'Ansible.
* Vérifier le fonctionnement depuis une connexion extérieure.

Cette procédure complète :

* [[Matomo/Installation]]
* [[Matomo/Apache]]
* [[Matomo/Drupal]]
* [[Matomo/Debug]]

== 1. Architecture ==

Dans l'infrastructure AJLSM, le trafic suit généralement le chemin suivant :

<syntaxhighlight lang="text">
Navigateur du visiteur
|
| HTTPS
v
HAProxy (haproxy-01 / haproxy-02)
|
| HTTPS ou HTTP interne
v
VM applicative
|
v
Apache + PHP-FPM + Matomo
|
v
MariaDB
</syntaxhighlight>

Le navigateur charge le JavaScript Matomo et transmet les données de fréquentation au serveur Matomo.

'''Important :''' la collecte des statistiques doit fonctionner pour les visiteurs extérieurs, même lorsque l'interface d'administration Matomo est réservée à AJLSM.

== 2. Prérequis ==

Avant de modifier HAProxy, vérifier :

* Que Matomo fonctionne sur la VM applicative.
* Que le VirtualHost Apache est configuré.
* Que le nom DNS public de Matomo est défini.
* Que le certificat HTTPS public est disponible sur HAProxy.
* Que le backend Matomo est joignable depuis les répartiteurs.
* Que l'adresse IP ou le réseau autorisé pour l'administration est connu.

La configuration HAProxy est gérée par Ansible. Les modifications doivent être réalisées dans les fichiers sources du dépôt `ansible-ajlsm`, et non directement dans `/etc/haproxy/haproxy.cfg` sur les serveurs.

== 3. Paramètres à personnaliser ==

Pour chaque nouvelle installation, identifier les paramètres suivants :

{| class="wikitable"
! Paramètre
! Exemple
! Description
|-
| Domaine Matomo
| matomo.exemple.fr
| Nom DNS public de Matomo
|-
| Backend
| back_ssl_projet_matomo
| Nom du backend HAProxy
|-
| Adresse de la VM
| 10.0.0.X
| Adresse privée de la VM hébergeant Matomo
|-
| Port backend
| 443
| Port HTTPS interne, si utilisé
|-
| ACL des administrateurs
| allowed_ajlsm
| Adresses IP autorisées à accéder à l'interface
|}

== 4. Configuration des ACL ==

=== Principe ===

Deux chemins sont nécessaires au suivi Matomo standard :

* `/matomo.js` : chargement du JavaScript de suivi.
* `/matomo.php` : réception des données de fréquentation.

Ces deux chemins doivent rester accessibles publiquement.

Les autres chemins de l'interface Matomo sont réservés aux adresses IP autorisées.

=== Exemple générique ===

Ajouter les règles suivantes dans le frontend HAProxy approprié :

<syntaxhighlight lang="haproxy">
# MATOMO - PROJET
acl host_projet_matomo hdr(host),host_only -i matomo.exemple.fr

# Ressources de collecte accessibles publiquement
acl projet_matomo_tracking path -i /matomo.js /matomo.php

# Interface Matomo réservée à AJLSM
http-request deny if host_projet_matomo !allowed_ajlsm !projet_matomo_tracking

# Redirection HTTP vers HTTPS
http-request redirect scheme https if host_projet_matomo !{ ssl_fc }

# Routage vers le backend Matomo
use_backend back_ssl_projet_matomo if host_projet_matomo
</syntaxhighlight>

'''Attention :''' cet exemple utilise l'ACL `allowed_ajlsm` déjà présente dans l'infrastructure AJLSM. Vérifier son existence et son contenu avant de déployer la configuration.

L'ACL `path -i` effectue une correspondance exacte des chemins. Elle ne rend pas accessibles les autres pages de l'administration Matomo.

Cette configuration est adaptée au suivi JavaScript standard. Si des fonctionnalités supplémentaires nécessitent d'autres points d'accès, leurs chemins doivent être étudiés séparément avant toute ouverture.

== 5. Configuration du backend ==

=== Exemple HTTPS ===

<syntaxhighlight lang="haproxy">
backend back_ssl_projet_matomo
server SSLPROJETMATOMO 10.0.0.X:443 check ssl verify none sni str(matomo.exemple.fr)
</syntaxhighlight>

Remplacer l'adresse IP, le nom du serveur et le nom de domaine par les paramètres du projet.

'''Sécurité :''' `verify none` désactive la vérification du certificat présenté par le backend. Cette configuration existe sur AD64, mais ne doit pas être considérée comme une recommandation générale.

Pour une nouvelle installation, privilégier une validation TLS du backend avec une autorité de certification appropriée lorsque l'architecture le permet.

=== Backend HTTP ===

Un backend HTTP peut également être utilisé sur un réseau interne maîtrisé :

<syntaxhighlight lang="haproxy">
backend back_projet_matomo
server PROJETMATOMO 10.0.0.X:80 check
</syntaxhighlight>

Le choix entre HTTP et HTTPS interne dépend de l'architecture du projet et des exigences de sécurité.

== 6. Certificats HTTPS ==

Dans l'infrastructure AJLSM, les certificats publics HAProxy peuvent être gérés par `acme.sh`.

Sur les serveurs HAProxy concernés, vérifier :

* L'existence du certificat pour le domaine Matomo.
* Sa date d'expiration.
* La configuration de renouvellement automatique.
* Le mécanisme de déploiement du certificat dans HAProxy.

Exemple de vérification depuis un poste client :

<syntaxhighlight lang="bash">
openssl s_client \
-connect matomo.exemple.fr:443 \
-servername matomo.exemple.fr </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates
</syntaxhighlight>

La présence d'une tâche automatique de renouvellement ne garantit pas à elle seule que le déploiement d'un nouveau certificat fonctionnera. Le renouvellement et le rechargement effectif du certificat doivent être contrôlés.

== 7. Déploiement avec Ansible ==

=== Modification ===

Depuis le Mac d'administration :

# Ouvrir le dépôt `ansible-ajlsm`.
# Modifier la configuration HAProxy dans les sources Ansible.
# Ajouter les ACL et le routage du nouveau domaine Matomo.
# Vérifier que les backends sont définis.
# Ne pas modifier directement les configurations générées sur les deux serveurs.

=== Vérification de la syntaxe du playbook ===

<syntaxhighlight lang="bash">
ansible-playbook -i inventory ./plays/deploy.haproxy.yml \
--limit ajlsm_loadbalancer --syntax-check
</syntaxhighlight>

=== Simulation du déploiement ===

<syntaxhighlight lang="bash">
ansible-playbook -i inventory ./plays/deploy.haproxy.yml \
--limit ajlsm_loadbalancer --check --diff
</syntaxhighlight>

Vérifier :

* Que les modifications sont identiques sur les deux HAProxy.
* Que seuls les blocs attendus changent.
* Qu'aucune configuration d'un autre client n'est modifiée.
* Qu'aucune erreur n'est signalée.

'''Important :''' le mode `--check` est une simulation. Il ne garantit pas à lui seul le succès du déploiement réel ni le comportement des ACL en production.

=== Déploiement réel ===

<syntaxhighlight lang="bash">
ansible-playbook -i inventory ./plays/deploy.haproxy.yml \
--limit ajlsm_loadbalancer --diff
</syntaxhighlight>

Vérifier le résultat du playbook sur les deux serveurs.

Si le playbook prévoit un redémarrage ou un rechargement HAProxy, contrôler ensuite que les services restent actifs et que les applications existantes répondent normalement.

== 8. Vérification depuis une connexion extérieure ==

'''Important :''' effectuer les tests depuis une connexion qui n'utilise ni l'adresse IP publique du bureau ni le VPN AJLSM.

Une connexion autorisée ne permet pas de vérifier correctement le refus d'accès à l'administration.

=== Tester les ressources de suivi ===

<syntaxhighlight lang="bash">
MATOMO_URL="https://matomo.exemple.fr"

for RESOURCE in matomo.js matomo.php; do
echo "===== /$RESOURCE ====="

curl -sS -o /dev/null -w "HTTP %{http_code}\n" \
"$MATOMO_URL/$RESOURCE"
done
</syntaxhighlight>

Résultats attendus pour l'installation standard :

{| class="wikitable"
! Ressource
! Résultat attendu
|-
| /matomo.js
| HTTP 200
|-
| /matomo.php
| Accessible sans HTTP 403 HAProxy
|}

'''Remarque :''' une réponse HTTP 200 de `matomo.php` sans paramètres de suivi ne constitue pas une preuve de collecte effective.

=== Tester la protection de l'administration ===

<syntaxhighlight lang="bash">
curl -sS -o /dev/null -w "HTTP %{http_code}\n" \
"$MATOMO_URL/"
</syntaxhighlight>

Résultat attendu depuis une adresse IP extérieure non autorisée :

<syntaxhighlight lang="text">
HTTP 403
</syntaxhighlight>

=== Tester depuis une adresse autorisée ===

Depuis le réseau AJLSM ou un accès VPN autorisé, vérifier que l'interface Matomo reste accessible et que l'authentification Matomo fonctionne.

== 9. Vérification de la collecte ==

Une fois les règles HAProxy appliquées :

# Ouvrir une application Drupal ou Pleade suivie par Matomo.
# Naviguer sur plusieurs pages publiques.
# Vérifier l'envoi des requêtes de suivi dans les outils réseau du navigateur.
# Vérifier l'apparition des visites dans l'interface Matomo.

Pour une vérification directe en base :

<syntaxhighlight lang="sql">
SELECT
idsite,
COUNT(*) AS visites,
MAX(visit_last_action_time) AS derniere_activite
FROM matomo_log_visit
GROUP BY idsite;
</syntaxhighlight>

Cette requête doit être exécutée dans la base Matomo avec un compte disposant des droits nécessaires.

Voir [[Matomo/Drupal]] et [[Matomo/Debug]].

== 10. Exemple validé : AD64 — octobre 2026 ==

=== Environnement ===

{| class="wikitable"
! Élément
! Valeur
|-
| Serveur Matomo
| ad64
|-
| Domaine
| ad64-matomo.pleade.com
|-
| Adresse privée de la VM
| 10.0.0.41
|-
| Backend HTTPS
| back_ssl_ad64_matomo
|-
| Répartiteurs
| haproxy-01 et haproxy-02
|-
| Applications suivies
| Drupal Internet et Drupal Salle de lecture
|}

=== Configuration HAProxy ===

<syntaxhighlight lang="haproxy">
# AD64 MATOMO
acl host_ad64_matomo hdr(host),host_only -i ad64-matomo.pleade.com

# Points de collecte accessibles publiquement
acl ad64_matomo_tracking path -i /matomo.js /matomo.php

# Administration réservée à AJLSM
http-request deny if host_ad64_matomo !allowed_ajlsm !ad64_matomo_tracking

http-request redirect scheme https if host_ad64_matomo !{ ssl_fc }

use_backend back_ssl_ad64_matomo if host_ad64_matomo
</syntaxhighlight>

Backend HTTPS existant :

<syntaxhighlight lang="haproxy">
backend back_ssl_ad64_matomo
server SSLAD64MATOMO 10.0.0.41:443 check ssl verify none sni str(ad64-matomo.pleade.com)
</syntaxhighlight>

L'ancien backend HTTP `back_ad64_matomo` a été conservé sans modification, bien qu'il ne soit plus utilisé par ce routage.

=== Résultats des tests ===

Les vérifications réalisées le 20 octobre 2026 depuis une connexion extérieure au bureau ont donné :

{| class="wikitable"
! Test
! Résultat
|-
| https://ad64-matomo.pleade.com/matomo.js
| HTTP 200
|-
| https://ad64-matomo.pleade.com/matomo.php
| HTTP 200
|-
| https://ad64-matomo.pleade.com/
| HTTP 403
|}

Les visites Drupal Internet et Salle de lecture avaient également été enregistrées dans MariaDB, avec les identifiants Matomo 2 et 3.

La collecte et la restriction d'accès ont donc été vérifiées.

== 11. Points de vigilance ==

* Ne jamais ouvrir toute l'interface Matomo à Internet uniquement pour permettre la collecte.
* Ne pas autoriser systématiquement les adresses IP du client à accéder à l'administration.
* Ne pas bloquer les points de collecte nécessaires aux visiteurs.
* Ne pas modifier directement les fichiers HAProxy générés par Ansible.
* Tester depuis une véritable connexion extérieure.
* Vérifier le certificat HTTPS et son renouvellement.
* Vérifier que la collecte réelle fonctionne, au-delà du simple chargement du JavaScript.

== 12. Maintenance et diagnostic ==

En cas d'anomalie, vérifier successivement :

# La résolution DNS du domaine Matomo.
# Le certificat HTTPS présenté par HAProxy.
# La correspondance de l'ACL `host`.
# Les règles `http-request deny`.
# Les chemins autorisés pour le suivi.
# L'état du backend HAProxy.
# La disponibilité d'Apache et PHP-FPM sur la VM.
# La réception effective des visites dans Matomo.

Voir [[Matomo/Debug]] et [[Matomo/Maintenance]].

Matomo

Jlarvers — Tue, 20 Oct 2026 10:35:23 GMT

Matomo – Portails d'archives numériques :

← Version précédente		Version du 20 octobre 2026 à 10:35
Ligne 6 :		Ligne 6 :
	* Ubuntu 18.04 et sur Ubuntu 24.04		* Ubuntu 18.04 et sur Ubuntu 24.04
	* Apache		* Apache
			* Haproxy
	* PHP-FPM		* PHP-FPM
	* Drupal 10		* Drupal 10
Ligne 16 :		Ligne 17 :
	* [[Matomo/Apache]]		* [[Matomo/Apache]]
	* [[Matomo/Drupal]]		* [[Matomo/Drupal]]
			* [[Matomo/HAProxy]]
			* [[Matomo/Maintenance]]
	* [[Matomo/Recherche]]		* [[Matomo/Recherche]]
	* [[Matomo/Pleade]]		* [[Matomo/Pleade]]

Matomo/Drupal

Jlarvers — Tue, 20 Oct 2026 10:30:22 GMT

Voir les modifications

Matomo/Apache

Jlarvers — Tue, 20 Oct 2026 10:29:59 GMT

Voir les modifications

Matomo/Installation

Jlarvers — Tue, 20 Oct 2026 10:28:13 GMT

5. Installation des fichiers Matomo :

Voir les modifications

AJLSM-DEPLOY — Version 1.0.2

Jlarvers — Mon, 19 Oct 2026 07:36:46 GMT

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

Déploiement technique d’une VM AJLSM

Jlarvers — Mon, 19 Oct 2026 07:35:35 GMT

Voir les modifications

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

Jlarvers — Fri, 16 Oct 2026 16:18:24 GMT

Contenu remplacé par « Obsolète : Voir Déploiement_technique_d’une_VM_AJLSM »

Voir les modifications

Déploiement technique d’une VM AJLSM

Jlarvers — Fri, 16 Oct 2026 15:44:55 GMT

Voir les modifications

Déploiement technique d’une VM AJLSM

Jlarvers — Fri, 16 Oct 2026 15:37:53 GMT

Page créée avec « = Déploiement technique d’une VM AJLSM = Document du 16 octobre 2026. Référence : scripts reçus de Saturne3, puis lot de recette avec lanceur du cycle et assistant ... »

Nouvelle page

= Déploiement technique d’une VM AJLSM =

Document du 16 octobre 2026. Référence : scripts reçus de Saturne3, puis lot de recette avec lanceur du cycle et assistant YAML.

== 1. Périmètre et résultat de la recette ==

Le cycle technique a été exécuté sur MERCURE3 sans erreur signalée. Les vérifications finales transmises confirment :
* connexion SSH avec le compte ajlsm ;
* élévation sudo avec le mot de passe défini pendant le cycle ;
* hostname mercure3.ajlsm.com ;
* volume racine ext4 de 97 Gio, dont 85 Gio disponibles lors du contrôle.

Le cycle couvre le clonage, les ressources, l’initialisation du clone, l’extension de la racine, l’identité système, le réseau, SSH, le mot de passe et le certificat TLS interne.

NFS, les configurations applicatives Apache2, Pleade, Drupal et Matomo ne font pas encore partie de ce cycle. Certains logiciels peuvent déjà être présents dans le modèle : leur présence ne constitue pas une configuration applicative du projet.

== 2. Où exécuter les commandes ==

{| class="wikitable"
! Machine !! Rôle !! Exemple d’invite
|-
| Mac de l’administrateur || Transfert des archives par scp || Invite locale du Mac
|-
| Saturne3 || Préparation YAML, scripts Proxmox et cycle || root@Saturne3
|-
| MERCURE3 || Vérifications dans la VM || ajlsm@mercure3 ou root@mercure3
|}

Les scripts de déploiement sont exécutés sur Saturne3, pas dans MERCURE3.
Après « ssh ajlsm@10.0.0.43 », attendre l’invite de la VM avant de saisir les commandes suivantes.
Pour revenir de root@mercure3 à Saturne3 : un exit quitte sudo, puis un second exit ferme SSH.

== 3. Organisation des fichiers ==

<syntaxhighlight lang="text">
/root/ajlsm-deploy/
archives/ Archives reçues, conservées comme références
recettes/20261016/
ajlsm-deploy-cycle/ Lot technique validé et assistant ajouté
ajlsm-deploy-assistant/ Distribution de l’assistant et tests
ajlsm-deploy-documentation/ Présent guide et modèles YAML

/etc/ajlsm/deploy/projets/mercure3.yaml Configuration actuellement utilisée
/usr/local/sbin/ Scripts installés antérieurement
</syntaxhighlight>

Le lot de recette contient ajlsm-deploy, ajlsm-deploy-check, ajlsm-deploy-resources, ajlsm-deploy-cycle et les modules ajlsm_deploy_common.py, ajlsm_deploy_rootgrow.py et ajlsm_deploy_postconfig.py. L’assistant ajlsm-deploy-yaml a été ajouté à ce même dossier.

Conserver exécutables et modules ensemble. Utiliser les chemins ./ depuis le dossier de recette pour ne pas appeler une ancienne version de /usr/local/sbin.
Les anciennes archives « ajlsm-deploy-revise » et « correction-suggestions » ne sont pas la référence courante : elles précèdent les phases supplémentaires reçues dans l’archive serveur.

Prérequis : Python 3.9 ou supérieur, PyYAML 6, outils Proxmox sur le nœud cible et prérequis du modèle AJLSM. Les phases invitées utilisent notamment l’agent QEMU, ajlsm-clone-init, Python, systemd et Netplan. L’extension actuelle cible ext4/LVM sur /dev/sda3, avec un seul PV et un seul LV.

== 4. Les deux fichiers de préconfiguration ==

=== 4.1. projet-vierge.yaml ===

Ce modèle reprend toute la structure actuelle sans valeur opérationnelle préremplie. Chaque champ doit être renseigné. Seul proxmox.vmid peut rester null : il signifie alors attribution automatique.

Le modèle comporte deux interfaces dont les valeurs sont null. Adapter le nombre d’interfaces avant la saisie si nécessaire. Pour déterminer ce nombre par les questions de l’assistant, utiliser plutôt le mode --new.

Un modèle vierge est volontairement refusé par --check. Il ne doit jamais être passé directement au lanceur du cycle.

=== 4.2. mercure3-reference.yaml ===

Ce fichier conserve les valeurs du projet validé : modèle 506 sur Saturne3, nom MERCURE3, 8 vCPU, 24576 Mio de RAM maximale, 16384 Mio minimale, disque 100 Gio, extension racine activée et paramètres réseau du projet.

Il permet de reconstruire une nouvelle VM avec la même configuration technique si le modèle, le stockage, les bridges et les préparatifs externes sont toujours disponibles. Il ne sauvegarde ni les données de l’ancienne VM, ni ses UUID, machine-id, clés hôte SSH ou mots de passe. Ces identités sont traitées par le cycle et ne sont pas à recopier.

Avec vmid: null, le VMID de remplacement peut différer de celui de l’ancienne VM. Le VMID 505 observé pendant la recette n’est pas une réservation permanente.

'''Ne pas lancer cette référence tant que MERCURE3 existe encore.''' Le clonage refuse un nom déjà présent. Pour tester une deuxième VM en parallèle, définir un autre nom, hostname, des IP distinctes et préparer DNS/OPNsense/Ansible en conséquence.

=== 4.3. Valeurs acceptées ===

* projet.environnement et tags : interne, client, prod. Les tags sont une liste sans doublons ; [] est admis.
* CPU, mémoire et taille du disque : entiers strictement positifs ; mémoire minimale inférieure ou égale à la maximale.
* Booléens : utiliser true ou false sans guillemets.
* Interfaces Proxmox : net suivi de chiffres ; interfaces invitées : ens suivi de chiffres.
* Adresses d’interfaces : IPv4/CIDR. Loopback : IPv4/32. Passerelle et DNS : IPv4 sans préfixe.
* Passerelle : interface déclarée et adresse appartenant à son sous-réseau, distincte des adresses de la VM.
* Hostname : nom DNS en minuscules.
* Serveur, bridge et stockage : valeurs adaptées à l’infrastructure ; aucune liste fermée inventée.

Les clés inconnues ou répétées sont refusées. Ne pas ajouter de sections applicatives avant l’évolution coordonnée du schéma et des scripts. Ne pas utiliser [à renseigner] : les crochets créent une liste YAML.

== 5. Préparer et valider le YAML ==

Sur Saturne3, se placer dans le lot de recette :

<syntaxhighlight lang="bash">
cd /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle
</syntaxhighlight>

=== 5.1. Vérifier un fichier existant sans le modifier ===

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

Le message de succès signifie que les valeurs et leur cohérence locale sont conformes. Il ne certifie pas la préparation des services externes.

=== 5.2. Compléter le modèle vierge ===

Après extraction du présent lot documentaire :

<syntaxhighlight lang="bash">
./ajlsm-deploy-yaml \
/root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-documentation/projet-vierge.yaml \
--output /root/ajlsm-deploy/recettes/20261016/nouveau-projet.yaml
</syntaxhighlight>

Toutes les valeurs obligatoires seront demandées. Pour saisir de nouveau le projet MERCURE3, consulter mercure3-reference.yaml comme fiche de paramètres, sans lancer de déploiement.

=== 5.3. Créer sans modèle ===

<syntaxhighlight lang="bash">
./ajlsm-deploy-yaml /root/ajlsm-deploy/recettes/20261016/nouveau-projet.yaml --new
</syntaxhighlight>

Cette commande est une alternative à la précédente : le chemin doit être inexistant. L’assistant pose les questions, y compris le nombre d’interfaces, sans reprendre implicitement les valeurs de MERCURE3.

=== 5.4. Revoir un projet renseigné ===

<syntaxhighlight lang="bash">
./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3.yaml --review \
--output /root/ajlsm-deploy/recettes/20261016/mercure3-relecture.yaml
</syntaxhighlight>

* Entrée conserve une valeur existante valide.
* ANNULER, Ctrl-C ou fin d’entrée abandonnent sans enregistrer.
* Tags et DNS sont saisis séparés par des virgules ; [] ou aucun signifie tags vides.
* Saisir auto ou null pour un VMID automatique.
* Après une incohérence, donner le chemin du champ à corriger ; ? affiche les chemins.
* Le résumé complet est présenté avant confirmation OUI/NON d’enregistrement.

L’original reste intact, avec ses commentaires. La copie est réécrite en YAML, sans reprise des commentaires. Aucun fichier existant n’est écrasé. Si une destination existe, choisir un nouveau nom avec --output.

=== 5.5. Préparatifs externes ===

Avant une création, vérifier séparément la réservation des IP, les déclarations DNS, les règles/routes/NAT nécessaires dans OPNsense et l’inventaire ou les préparatifs Ansible. Ne pas inscrire de mots de passe dans le YAML ; conserver les secrets dans le dispositif prévu pour leur gestion.

L’assistant actuel ne vérifie pas automatiquement ces services et ne marque pas un projet « prêt à déployer » sur cette seule base. Leur intégration reste à réaliser.

Le contrôle Proxmox autonome examine notamment le modèle, ses ressources, le stockage et les bridges. Il concerne une nouvelle création et peut refuser un projet déjà déployé :

<syntaxhighlight lang="bash">
./ajlsm-deploy-check /chemin/vers/projet.yaml
</syntaxhighlight>

== 6. Afficher le plan puis lancer le cycle ==

=== 6.1. Plan sans exécution ===

<syntaxhighlight lang="bash">
./ajlsm-deploy-cycle /chemin/vers/projet.yaml --plan
</syntaxhighlight>

Le plan valide le YAML et affiche les commandes, sans exécuter les phases ni vérifier l’infrastructure. Il doit contenir les 11 étapes, toutes dans le dossier de recette.

=== 6.2. Cycle réel pour une nouvelle VM ===

<syntaxhighlight lang="bash">
./ajlsm-deploy-cycle /chemin/vers/projet.yaml
</syntaxhighlight>

Le lanceur exécute les phases réelles, sans simulation automatique. Il attend seulement les confirmations, les saisies nécessaires et la fin de chaque commande. Il s’arrête sur refus ou erreur. Il ne répond pas à la place de l’administrateur et ne capture pas les mots de passe.

{| class="wikitable"
! N° !! Étape !! Commande réelle !! Simulation facultative
|-
| 1 || Clonage || --clone || --dry-run
|-
| 2 || Ressources || --configure-resources || --resources-dry-run
|-
| 3 || Premier démarrage isolé || --first-boot-apply || --first-boot-dry-run
|-
| 4 || Extension partition/LVM/ext4 || --root-grow-apply || --root-grow-dry-run
|-
| 5 || Identité système || --system-apply || --system-dry-run
|-
| 6 || Préparation Netplan || --network-apply || --network-dry-run
|-
| 7 || Activation réseau || --network-enable || --network-enable-dry-run
|-
| 8 || Audit SSH || --ssh-audit || Aucune option dédiée
|-
| 9 || Sécurisation SSH || --ssh-secure || Aucune option dédiée
|-
| 10 || Mot de passe ajlsm || --password-ajlsm || Aucune option dédiée
|-
| 11 || Certificat TLS interne || --tls-apply || Aucune option dédiée
|}

L’extension racine est indispensable quand etendre_volume_racine vaut true. Agrandir le disque Proxmox ne suffit pas : la partition, le PV LVM, le LV et ext4 doivent aussi être étendus. Cette phase doit figurer après le premier démarrage, avant la personnalisation système. Avec false, la phase annonce sa désactivation.

Le démarrage et la personnalisation se font réseau isolé. Netplan est préparé avant activation des liens. La phase d’activation contrôle le réseau et applique demarrage_auto.

Le certificat TLS interne ne constitue pas, à lui seul, une configuration des applications du projet ou un certificat publiquement reconnu.

=== 6.3. Mode manuel ===

Chaque phase peut être lancée séparément avec ./ajlsm-deploy suivi du YAML et de son option. Après succès, le lot courant affiche deux lignes pour l’étape suivante : Simulation et Exécution. Si la simulation n’existe pas, il le signale. Aucune suggestion n’est exécutée automatiquement.

Les simulations peuvent consulter l’invité et émettre des sondes ARP selon la phase : elles ne sont pas toutes des contrôles hors ligne. L’absence de réponse ARP ne remplace pas la réservation des adresses dans l’inventaire réseau.

== 7. Erreur, annulation et reprise ==

Conserver la sortie complète et diagnostiquer la phase fautive avant de reprendre. Une phase peut être partiellement effectuée ; le lanceur n’effectue ni suppression de VM ni restauration globale automatique.

<syntaxhighlight lang="bash">
./ajlsm-deploy-cycle /chemin/vers/projet.yaml --from extension-racine
</syntaxhighlight>

--from inclut l’étape indiquée et saute les précédentes à la demande de l’administrateur. Il ne certifie pas leur état. Les contrôles propres aux phases restent actifs. Le lanceur ne possède pas de journal persistant global de progression.

Ne pas relancer le cycle depuis le clonage sur une VM existante pour terminer une étape. Ne pas relancer des étapes déjà terminées uniquement parce qu’une commande manuelle les suggère. Les suggestions suivent l’ordre théorique et ne constituent pas un inventaire de l’état de la VM.

Codes de sortie : 0 succès, 1 annulation, 2 erreur. Le lanceur normalise les autres codes d’échec de ses sous-processus en erreur et ne poursuit pas.

== 8. Vérifications finales ==

Sur Saturne3, avec le VMID réellement annoncé au clonage :

<syntaxhighlight lang="bash">
qm list
qm status VMID
qm config VMID
</syntaxhighlight>

Remplacer VMID par l’identifiant vérifié. Contrôler le nom, les CPU, la RAM, le disque, les liens réseau et onboot selon le YAML.

Depuis Saturne3, ouvrir la connexion et attendre l’invite de la VM :

<syntaxhighlight lang="bash">
ssh ajlsm@10.0.0.43
</syntaxhighlight>

Dans MERCURE3, saisir sudo -i, attendre l’authentification et l’invite root, puis :

<syntaxhighlight lang="bash">
hostname
lsblk
df -hT /
ip -br addr
ip route
resolvectl status
</syntaxhighlight>

Résultat vérifié pendant la recette : hostname mercure3.ajlsm.com, racine ext4 97 Gio. Les tailles disponibles évoluent avec l’utilisation. Les commandes SSH et TLS du cycle vérifient leurs propres résultats ; compléter par les tests d’accès attendus dans le réseau cible.

== 9. Reconstruire MERCURE3 ultérieurement ==

# Conserver le fichier mercure3-reference.yaml, le lot de scripts validé et l’identification du modèle utilisé.
# Comparer la référence au YAML effectivement utilisé avant reconstruction ; actualiser les changements d’infrastructure.
# Identifier et sauvegarder les données à conserver : le YAML n’est pas une sauvegarde de VM.
# Vérifier explicitement l’identité de l’ancienne VM et traiter séparément son arrêt et sa suppression volontaire. Le cycle ne détruit jamais automatiquement une VM existante.
# Contrôler DNS, OPNsense, Ansible et les réservations d’IP. Ne pas laisser deux VM actives avec les mêmes adresses.
# Valider la référence avec --check, afficher le --plan, puis lancer le cycle sur la référence après libération de la cible.
# Relever le nouveau VMID et effectuer les vérifications finales.

On retrouve ainsi les paramètres de la VM, sans chercher à reproduire ses anciennes identités techniques.

== 10. Suites prévues ==

Prévoir les paramètres NFS, sites Apache2, Pleade, Drupal et Matomo dans le même YAML lorsque leurs exigences seront définies. Modifier ensemble le schéma, l’assistant, les modèles, les précontrôles, les phases et leur documentation. Documenter les références aux secrets plutôt que leurs valeurs.

L’intégration des contrôles DNS, OPNsense et Ansible précédera une déclaration automatisée de disponibilité du projet. Le modèle actuel ne contient pas encore ces nouvelles sections.

EOLE3 — Accès, sécurité et pare-feu

Jlarvers — Fri, 16 Oct 2026 12:37:39 GMT

← Version précédente		Version du 16 octobre 2026 à 12:37
Ligne 1 :		Ligne 1 :
	= EOLE3 — Accès, sécurité et pare-feu =		= EOLE3 — Accès, sécurité et pare-feu =
			Voir aussi [[Eole3_–_Checklist_mensuelle_de_sécurité]] :
	~~{{Sommaire}}~~

	== 1. Objet du document ==		== 1. Objet du document ==

EOLE3 — Accès et sécurité

Jlarvers — Fri, 16 Oct 2026 12:36:10 GMT

← Version précédente	Version du 16 octobre 2026 à 12:36
Ligne 1 :	Ligne 1 :
		Obsolète :

		Voir :

		# http://mw.ajlsm.com/wiki/Eole3_%E2%80%93_Checklist_mensuelle_de_s%C3%A9curit%C3%A9
		# http://mw.ajlsm.com/wiki/EOLE3_%E2%80%94_Acc%C3%A8s,_s%C3%A9curit%C3%A9_et_pare-feu

Sécurité Eole3 – Règles à ne pas oublier

Jlarvers — Fri, 16 Oct 2026 12:35:47 GMT

← Version précédente	Version du 16 octobre 2026 à 12:35
(Une version intermédiaire par le même utilisateur non affichée)
Ligne 1 :	Ligne 1 :
		Obsolète :

		Voir :

		# http://mw.ajlsm.com/wiki/Eole3_%E2%80%93_Checklist_mensuelle_de_s%C3%A9curit%C3%A9
		# http://mw.ajlsm.com/wiki/EOLE3_%E2%80%94_Acc%C3%A8s,_s%C3%A9curit%C3%A9_et_pare-feu

Eole3 – Checklist mensuelle de sécurité

Jlarvers — Fri, 16 Oct 2026 12:34:39 GMT

Voir les modifications

EOLE3 — Accès, sécurité et pare-feu

Jlarvers — Fri, 16 Oct 2026 12:33:46 GMT

Page créée avec « = EOLE3 — Accès, sécurité et pare-feu = {{Sommaire}} == 1. Objet du document == Cette documentation décrit l'organisation des accès et les mécanismes de sécuri... »

Nouvelle page

= EOLE3 — Accès, sécurité et pare-feu =

{{Sommaire}}

== 1. Objet du document ==

Cette documentation décrit l'organisation des accès et les mécanismes de sécurité du serveur EOLE3.

Elle couvre notamment :

* les comptes d'administration ;
* les comptes techniques nominatifs ;
* les comptes clients SFTP ;
* les accès réseau publics et privés ;
* le pare-feu nftables ;
* Fail2ban ;
* les procédures de maintenance et de retour arrière.

'''Principe général :''' n'exposer sur Internet que les services strictement nécessaires.

Voir également :

* [[EOLE3 — Administration, maintenance et flux de données]]
* [[EOLE3 — Checklist mensuelle de sécurité]]

== 2. Architecture réseau ==

=== 2.1 Interfaces ===

{| class="wikitable"
! Interface
! Adresse
! Utilisation
|-
| <code>enp9s0f0np0</code>
| <code>51.178.110.230</code>
| Réseau public OVH
|-
| <code>enp9s0f1np1</code>
| <code>192.168.123.202/24</code>
| Réseau privé OVH vRack
|}

EOLE3 dispose également d'une connectivité IPv6 publique.

Le réseau privé vRack est utilisé pour les échanges techniques entre serveurs, notamment les accès NFS et la supervision.

=== 2.2 Politique de sécurité ===

Les flux entrants sont refusés par défaut.

Seuls sont autorisés :

* les connexions déjà établies ;
* les communications locales ;
* les communications du réseau privé vRack ;
* les services publics explicitement autorisés ;
* les connexions SSH provenant des adresses administratives autorisées ;
* les protocoles nécessaires au fonctionnement réseau, notamment ICMP et ICMPv6.

Les flux sortants ne sont pas filtrés par la configuration AJLSM actuelle.

== 3. Politique des accès ==

Les comptes sont répartis en quatre catégories :

# compte système root ;
# compte d'administration ubuntu ;
# comptes techniques nominatifs ;
# comptes clients SFTP.

Cette séparation évite de mélanger les usages d'administration, de maintenance et de transfert de fichiers.

=== 3.1 Compte root ===

Le compte <code>root</code> dispose de tous les privilèges système.

Il est utilisé pour :

* l'administration du système ;
* la gestion ZFS ;
* les modifications de configuration ;
* les opérations de migration ;
* la maintenance et le dépannage ;
* la gestion des droits et propriétaires ;
* les opérations critiques sur les données clients.

Son utilisation doit rester réservée aux opérations nécessitant réellement des privilèges administratifs.

=== 3.2 Compte ubuntu ===

Le compte <code>ubuntu</code> constitue un point d'entrée pour l'administration distante.

Il permet notamment :

* la connexion SSH ;
* l'utilisation de <code>sudo</code> ;
* les opérations courantes d'administration.

Il ne doit pas être utilisé comme compte client ou compte de dépôt.

=== 3.3 Comptes techniques nominatifs ===

Les comptes techniques sont individuels.

Principes :

* un compte par personne ;
* authentification par clé SSH ;
* droits attribués selon les besoins ;
* utilisation de <code>sudo</code> lorsque nécessaire ;
* traçabilité des interventions.

Les comptes nominatifs ne doivent pas être partagés.

=== 3.4 Comptes clients SFTP ===

Les comptes clients servent aux dépôts et récupérations de fichiers.

Exemple : <code>ad53</code>.

Ils sont associés à la logique métier Pleade et au confinement SFTP.

La configuration OpenSSH documentée utilise notamment :

<syntaxhighlight lang="apache">
Match Group eole3-sftp
ChrootDirectory %h
ForceCommand internal-sftp -P setstat,fsetstat
</syntaxhighlight>

Les restrictions complémentaires de transfert et de tunnel doivent être vérifiées dans la configuration SSH effective.

Les comptes clients concernés :

* ne disposent pas d'un shell interactif ;
* sont confinés dans leur environnement ;
* ne peuvent pas accéder librement aux données des autres clients ;
* restent soumis aux permissions Unix.

'''Attention :''' ces comptes SFTP OpenSSH ne doivent pas être confondus avec les utilisateurs gérés par le service SFTPGo sur le port 2022.

=== 3.5 Permissions des données ===

Les permissions d'écriture sont définies par les droits Unix et les ACL éventuelles.

Dans l'organisation documentée, les zones de travail comprennent notamment :

<syntaxhighlight lang="text">
/data/pleade
/data/projets
</syntaxhighlight>

Les répertoires suivants ne doivent pas devenir librement accessibles en écriture :

<syntaxhighlight lang="text">
/data
/data/data-private
</syntaxhighlight>

Les droits réels doivent être contrôlés avant toute modification.

== 4. Pare-feu nftables ==

=== 4.1 Solution retenue ===

EOLE3 utilise nftables pour le filtrage réseau.

Le pare-feu AJLSM est indépendant de Fail2ban.

Il utilise exclusivement :

<syntaxhighlight lang="text">
table inet ajlsm_eole3
</syntaxhighlight>

Fail2ban conserve sa propre table :

<syntaxhighlight lang="text">
table inet f2b-table
</syntaxhighlight>

'''Ne jamais utiliser <code>flush ruleset</code> pour administrer le pare-feu AJLSM.'''

Cette commande pourrait supprimer les règles de Fail2ban.

Le service standard <code>nftables.service</code> n'est pas utilisé pour charger la configuration AJLSM.

=== 4.2 Fichiers de configuration ===

{| class="wikitable"
! Fichier
! Fonction
|-
| <code>/etc/nftables/ajlsm-eole3.nft</code>
| Configuration principale du pare-feu
|-
| <code>/etc/nftables/ajlsm-eole3-reload.nft</code>
| Rechargement atomique des règles
|-
| <code>/etc/systemd/system/ajlsm-firewall.service</code>
| Service systemd dédié
|-
| <code>/root/ajlsm-eole3.nft</code>
| Copie de travail historique
|}

La configuration de référence est celle située dans <code>/etc/nftables/</code>.

=== 4.3 Ports publics autorisés ===

{| class="wikitable"
! Port
! Protocole
! Service
! Origine autorisée
|-
| 80
| TCP
| Apache HTTP
| Internet
|-
| 443
| TCP
| Apache HTTPS
| Internet
|-
| 2022
| TCP
| SFTPGo
| Internet
|-
| 22
| TCP / IPv4
| SSH administration
| Adresses administratives autorisées
|}

=== 4.4 Adresses administratives autorisées ===

{| class="wikitable"
! Adresse IPv4
! Usage
|-
| <code>109.190.129.96</code>
| Bureau AJLSM
|-
| <code>82.66.151.165</code>
| Domicile
|}

Toute modification de ces adresses nécessite une mise à jour du fichier nftables.

'''Ne jamais remplacer une adresse administrative sans avoir vérifié la possibilité de conserver un accès au serveur.'''

=== 4.5 Ports interdits depuis Internet ===

{| class="wikitable"
! Port
! Service
! Politique
|-
| 111
| RPC
| Réseau privé uniquement
|-
| 2049
| NFS
| Réseau privé uniquement
|-
| 9001
| Lighttpd
| Réseau privé uniquement
|-
| 9090
| Cockpit
| Non accessible publiquement
|-
| 4330
| PCP
| Non accessible publiquement
|-
| 44321–44323
| PCP
| Non accessibles publiquement
|}

Le pare-feu autorise les communications provenant du réseau privé <code>192.168.123.0/24</code> lorsqu'elles arrivent par l'interface vRack.

=== 4.6 Configuration nftables ===

Le fichier principal est :

<syntaxhighlight lang="bash">
/etc/nftables/ajlsm-eole3.nft
</syntaxhighlight>

Configuration validée lors des tests du 16 octobre 2026 :

<syntaxhighlight lang="nft">
#!/usr/sbin/nft -f

table inet ajlsm_eole3 {

define WAN = "enp9s0f0np0"
define VRACK = "enp9s0f1np1"

define ADMIN_IPS = {
109.190.129.96,
82.66.151.165
}

chain input {
type filter hook input priority filter;
policy drop;

ct state established,related accept
ct state invalid drop

iifname "lo" accept

iifname $VRACK ip saddr 192.168.123.0/24 accept

iifname $WAN ip protocol udp \
udp sport 67 udp dport 68 accept

ip protocol icmp accept
meta l4proto ipv6-icmp accept

iifname $WAN tcp dport { 80, 443 } accept

iifname $WAN tcp dport 2022 accept

iifname $WAN ip saddr $ADMIN_IPS tcp dport 22 accept
}
}
</syntaxhighlight>

Cette configuration applique une politique de refus par défaut aux connexions entrantes.

Elle n'ajoute pas de règles aux chaînes <code>forward</code> et <code>output</code>.

=== 4.7 Rechargement atomique ===

Le fichier :

<syntaxhighlight lang="bash">
/etc/nftables/ajlsm-eole3-reload.nft
</syntaxhighlight>

contient :

<syntaxhighlight lang="nft">
#!/usr/sbin/nft -f

destroy table inet ajlsm_eole3
include "/etc/nftables/ajlsm-eole3.nft"
</syntaxhighlight>

L'instruction <code>destroy</code> et le chargement de la nouvelle table sont exécutés dans une même transaction nftables.

Le rechargement ne modifie pas la table Fail2ban.

=== 4.8 Service systemd ===

Le pare-feu est géré par :

<syntaxhighlight lang="bash">
ajlsm-firewall.service
</syntaxhighlight>

Commandes principales :

'''État :'''

<syntaxhighlight lang="bash">
systemctl status ajlsm-firewall.service
</syntaxhighlight>

'''Démarrage :'''

<syntaxhighlight lang="bash">
systemctl start ajlsm-firewall.service
</syntaxhighlight>

'''Arrêt :'''

<syntaxhighlight lang="bash">
systemctl stop ajlsm-firewall.service
</syntaxhighlight>

'''Rechargement :'''

<syntaxhighlight lang="bash">
systemctl reload ajlsm-firewall.service
</syntaxhighlight>

'''Activation au démarrage :'''

<syntaxhighlight lang="bash">
systemctl enable ajlsm-firewall.service
</syntaxhighlight>

'''Désactivation au démarrage :'''

<syntaxhighlight lang="bash">
systemctl disable ajlsm-firewall.service
</syntaxhighlight>

'''Important :''' <code>enable</code> et <code>disable</code> modifient uniquement le comportement au démarrage. Ils ne démarrent ni n'arrêtent immédiatement le pare-feu.

=== 4.9 Vérifications ===

Lister les tables :

<syntaxhighlight lang="bash">
nft list tables
</syntaxhighlight>

Avec le pare-feu actif, les tables attendues sont :

<syntaxhighlight lang="text">
table inet f2b-table
table inet ajlsm_eole3
</syntaxhighlight>

Afficher les règles AJLSM :

<syntaxhighlight lang="bash">
nft list table inet ajlsm_eole3
</syntaxhighlight>

Vérifier la syntaxe avant toute modification :

<syntaxhighlight lang="bash">
nft -c -f /etc/nftables/ajlsm-eole3-reload.nft
</syntaxhighlight>

Vérifier le service :

<syntaxhighlight lang="bash">
systemctl is-active ajlsm-firewall.service
systemctl is-enabled ajlsm-firewall.service
</syntaxhighlight>

== 5. Procédure de modification du pare-feu ==

=== 5.1 Précautions obligatoires ===

Avant toute modification :

# conserver une session SSH administrative ouverte ;
# disposer d'un accès de secours au serveur ;
# vérifier les adresses administratives autorisées ;
# sauvegarder la configuration précédente ;
# vérifier la syntaxe ;
# programmer un retour arrière automatique ;
# tester les services après modification.

'''Ne jamais modifier les règles de filtrage à distance sans possibilité de retour arrière.'''

=== 5.2 Sauvegarder la configuration ===

<syntaxhighlight lang="bash">
cp -a /etc/nftables/ajlsm-eole3.nft \
/etc/nftables/ajlsm-eole3.nft.bak
</syntaxhighlight>

Pour les interventions successives, utiliser de préférence des sauvegardes horodatées.

=== 5.3 Vérifier les règles ===

<syntaxhighlight lang="bash">
nft -c -f /etc/nftables/ajlsm-eole3-reload.nft
</syntaxhighlight>

Cette commande ne modifie pas le pare-feu actif.

=== 5.4 Programmer un retour arrière ===

Exemple : arrêt automatique du service après 15 minutes.

<syntaxhighlight lang="bash">
systemd-run \
--unit=ajlsm-firewall-rollback \
--on-active=15min \
/usr/bin/systemctl stop ajlsm-firewall.service
</syntaxhighlight>

Vérification :

<syntaxhighlight lang="bash">
systemctl list-timers --all | grep ajlsm-firewall-rollback
</syntaxhighlight>

Attention : un retour arrière qui arrête uniquement le service ne restaure pas automatiquement une ancienne configuration.

Pour une modification de règles, prévoir également la restauration du fichier précédent si nécessaire.

=== 5.5 Appliquer les modifications ===

<syntaxhighlight lang="bash">
systemctl reload ajlsm-firewall.service
</syntaxhighlight>

Puis :

<syntaxhighlight lang="bash">
systemctl status ajlsm-firewall.service --no-pager
nft list tables
</syntaxhighlight>

=== 5.6 Vérifier les accès ===

Tester notamment :

* une nouvelle connexion SSH depuis une adresse administrative ;
* les accès HTTP et HTTPS ;
* SFTPGo ;
* les échanges NFS sur le vRack ;
* la supervision Centreon ;
* le blocage des ports internes depuis une connexion extérieure.

== 6. Tests de sécurité réalisés le 16 octobre 2026 ==

=== 6.1 Origine du test ===

Les tests ont été réalisés depuis un Mac connecté au partage de connexion mobile d'un iPhone.

Adresse IPv4 publique utilisée :

<syntaxhighlight lang="text">
176.135.13.221
</syntaxhighlight>

Cette adresse n'appartient pas à la liste des adresses administratives autorisées.

=== 6.2 Résultats ===

{| class="wikitable"
! Port
! Résultat observé
! Conforme
|-
| 22
| Bloqué
| Oui
|-
| 80
| Accessible
| Oui
|-
| 443
| Accessible
| Oui
|-
| 2022
| Accessible
| Oui
|-
| 111
| Bloqué
| Oui
|-
| 2049
| Bloqué
| Oui
|-
| 9001
| Bloqué
| Oui
|-
| 9090
| Bloqué
| Oui
|-
| 4330
| Bloqué
| Oui
|-
| 44321–44323
| Bloqués
| Oui
|}

Les résultats confirment le comportement attendu des règles IPv4 pour les ports TCP testés.

=== 6.3 Tests internes ===

Les vérifications précédentes ont confirmé :

* les accès NFS depuis les serveurs du vRack ;
* le fonctionnement de Lighttpd ;
* le fonctionnement de la supervision Centreon ;
* les accès publics Apache et SFTPGo ;
* l'accès SSH depuis le bureau.

=== 6.4 Limites des tests ===

Les tests extérieurs ont principalement porté sur IPv4 et TCP.

Ils ne constituent pas un audit exhaustif de l'exposition IPv6, des services UDP ou de la configuration applicative.

Ces points doivent faire l'objet de contrôles complémentaires.

== 7. Fail2ban ==

=== 7.1 Principe ===

Fail2ban complète le pare-feu en bloquant temporairement certaines adresses IP à partir des événements détectés dans les journaux.

Il ne remplace pas la politique de filtrage nftables.

Les règles Fail2ban sont gérées indépendamment dans :

<syntaxhighlight lang="text">
table inet f2b-table
</syntaxhighlight>

=== 7.2 Vérification ===

<syntaxhighlight lang="bash">
systemctl status fail2ban
fail2ban-client status
</syntaxhighlight>

Vérification de la jail SSH :

<syntaxhighlight lang="bash">
fail2ban-client status sshd
</syntaxhighlight>

Les autres jails doivent être contrôlées selon la configuration réellement active.

Ne pas considérer qu'une jail SFTPGo ou Cockpit existe sans l'avoir vérifié.

=== 7.3 Précautions ===

* Ne pas supprimer la table Fail2ban.
* Ne pas utiliser <code>flush ruleset</code>.
* Vérifier les exclusions d'adresses administratives.
* Contrôler régulièrement les bannissements.
* Vérifier les journaux en cas d'activité inhabituelle.

== 8. SSH ==

=== 8.1 Politique réseau ===

Le port SSH 22 est accessible depuis les adresses administratives autorisées.

Il est bloqué depuis les autres adresses publiques IPv4.

Le pare-feu ne prévoit pas d'ouverture publique SSH en IPv6.

=== 8.2 Authentification ===

La configuration d'authentification SSH doit être contrôlée séparément.

Commandes :

<syntaxhighlight lang="bash">
sshd -T | grep -E \
'^(port|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '
</syntaxhighlight>

Les restrictions par groupe doivent également être vérifiées dans les fichiers de configuration SSH.

'''Attention :''' le filtrage réseau et l'authentification SSH sont deux mécanismes distincts.

== 9. SFTPGo ==

SFTPGo est accessible publiquement sur le port TCP 2022.

Son exposition est volontaire pour permettre les transferts clients.

La sécurité repose notamment sur :

* l'authentification des utilisateurs ;
* les permissions des comptes ;
* la limitation des accès aux données ;
* la journalisation ;
* les éventuelles protections Fail2ban effectivement configurées.

Vérification :

<syntaxhighlight lang="bash">
systemctl status sftpgo
journalctl -u sftpgo --since "24 hours ago"
</syntaxhighlight>

Les interfaces d'administration de SFTPGo ne doivent pas être exposées publiquement sans justification et protection adaptées.

== 10. NFS et vRack ==

Les échanges NFS sont autorisés sur le réseau privé :

<syntaxhighlight lang="text">
192.168.123.0/24
</syntaxhighlight>

Les ports NFS et RPC ne sont pas accessibles depuis Internet lorsque le pare-feu AJLSM est actif.

Vérifications :

<syntaxhighlight lang="bash">
exportfs -v
showmount -e localhost
ss -tulpen
</syntaxhighlight>

Les exports NFS doivent conserver leurs propres restrictions d'accès.

Le pare-feu ne remplace pas les contrôles définis dans la configuration NFS.

== 11. Supervision Centreon ==

La supervision d'EOLE3 doit utiliser son adresse privée vRack :

<syntaxhighlight lang="text">
192.168.123.202
</syntaxhighlight>

Cette configuration permet de superviser les services internes sans ouvrir leurs ports sur Internet.

Lors des tests du 16 octobre 2026, la supervision a été adaptée pour utiliser cette adresse.

== 12. Tests réseau depuis l'extérieur ==

Pour tester réellement les restrictions Internet, il faut utiliser une connexion extérieure indépendante du bureau et des VPN.

=== 12.1 Particularité du Mac AJLSM ===

L'adaptateur Ethernet USB du Mac utilise :

<syntaxhighlight lang="text">
en7
</syntaxhighlight>

Le Wi-Fi utilise :

<syntaxhighlight lang="text">
en0
</syntaxhighlight>

macOS peut continuer à privilégier Ethernet même lorsque le partage de connexion de l'iPhone est activé.

=== 12.2 Procédure ===

# Désactiver les VPN.
# Désactiver temporairement l'adaptateur Ethernet <code>en7</code>.
# Connecter le Mac au partage de connexion de l'iPhone.
# Vérifier la route et l'adresse publique.

<syntaxhighlight lang="bash">
route -n get 1.1.1.1
curl -4 https://api.ipify.org
echo
</syntaxhighlight>

L'interface attendue est <code>en0</code>.

L'adresse publique doit être différente de celle du bureau.

=== 12.3 Tester les ports ===

<syntaxhighlight lang="bash">
for port in 22 80 443 2022 111 2049 9001 9090 4330 44321 44322 44323; do
nc -vz -G 3 51.178.110.230 "$port" 2>&1
done
</syntaxhighlight>

Après les tests, réactiver Ethernet.

== 13. Contrôles après redémarrage ==

Après chaque redémarrage d'EOLE3 :

# vérifier le service AJLSM ;
# vérifier Fail2ban ;
# contrôler les tables nftables ;
# tester une nouvelle connexion SSH ;
# vérifier Apache et SFTPGo ;
# vérifier les échanges NFS ;
# contrôler Centreon.

Commandes :

<syntaxhighlight lang="bash">
systemctl is-active ajlsm-firewall.service
systemctl is-enabled ajlsm-firewall.service

systemctl is-active fail2ban.service

nft list tables
</syntaxhighlight>

== 14. Règles à ne jamais oublier ==

* Ne jamais utiliser <code>flush ruleset</code>.
* Ne jamais activer UFW en parallèle sans étude préalable.
* Ne jamais exposer NFS sur Internet.
* Ne jamais ouvrir Cockpit publiquement.
* Ne jamais modifier les adresses SSH autorisées sans accès de secours.
* Toujours conserver un mécanisme de retour arrière.
* Toujours tester depuis une véritable connexion extérieure.
* Toujours vérifier Fail2ban après une modification du pare-feu.
* Toujours vérifier les services internes après modification.

== 15. Historique ==

{| class="wikitable"
! Date
! Intervention
|-
| 16/10/2026
| Création et validation des règles nftables AJLSM
|-
| 16/10/2026
| Validation des accès publics et des restrictions depuis le réseau mobile
|-
| 16/10/2026
| Validation du démarrage, de l'arrêt et du rechargement via systemd
|-
| 16/10/2026
| Activation du service au démarrage ; vérification finale de persistance à confirmer
|}

[[Catégorie:Eole3]]
[[Catégorie:Sécurité]]
[[Catégorie:Infrastructure]]

EOLE3 — Accès et sécurité

Jlarvers — Fri, 16 Oct 2026 12:33:02 GMT

Page blanchie

← Version précédente		Version du 16 octobre 2026 à 12:33
Ligne 1 :		Ligne 1 :
	~~= EOLE3 — Accès et sécurité =~~
	~~[[category:eole3]]~~
	~~== 1. Principe ==~~

	~~Séparer les usages :~~

	* administration
	* SFTP clients
	* comptes nominatifs

	~~== 2. Comptes ==~~

	~~=== root ===~~

	* accès total
	* réservé maintenance

	~~=== ubuntu ===~~

	* accès SSH principal
	* sudo vers root

	~~=== SFTP ===~~

	* pas de shell
	* accès limité au dataset

	~~=== comptes nominatifs ===~~

	* accès SSH personnel
	* traçabilité

	~~== 3. Configuration SSH ==~~

	~~Fichier :~~

	~~/etc/ssh/sshd_config.d/20-eole3-sftp.conf~~

	~~Contenu :~~

	~~Match Group eole3-sftp~~
	~~ChrootDirectory %h~~
	~~ForceCommand internal-sftp~~
	~~AllowTcpForwarding no~~
	~~PermitTunnel no~~
	~~X11Forwarding no~~

	~~== 4. Règles ==~~

	* ne jamais ajouter admin dans eole3-sftp
	* ne jamais donner de shell aux clients
	* toujours utiliser chroot

	~~== 5. Sécurité réseau ==~~

	* exposer uniquement Apache (443)
	* ne pas exposer ports internes (9090, 8080)
	* restreindre par IP si possible

	~~== 6. Bonnes pratiques ==~~

	* authentification par clé SSH
	* comptes nominatifs obligatoires
	* logs actifs

Sécurité Eole3 – Règles à ne pas oublier

Jlarvers — Fri, 16 Oct 2026 12:31:34 GMT

Page blanchie

Voir les modifications

← Version précédente		Version du 6 novembre 2026 à 12:54
Ligne 13 :		Ligne 13 :
	** helppage\|help		** helppage\|help
	** Special:UserLogin\|Créer un utilisateur		** Special:UserLogin\|Créer un utilisateur

			* administration
			** Special:SpecialPages\|Pages spéciales
			** Special:Version\|Version de MediaWiki
			** Special:UserRights\|Droits des utilisateurs
			** Special:CreateForm\|Créer un formulaire

	* SEARCH		* SEARCH