AJLSM - Contributions [fr]

MediaWiki:Sidebar

2026-11-06T12:54:48Z

Jlarvers : Ajout liens pages spéciales

* Accès Rapide
** recentchanges-url|recentchanges
** special:allpages|Toutes les pages

** Special:Categories|Catégories (toutes)
** Special:Toutes_les_pages/template:!|Modèles (toutes)

* Autres



** helppage|help
** 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

* TOOLBOX

MediaWiki:AJLSM-WikiEditor.js

2026-11-06T12:30:22Z

Jlarvers : Restauration des 14 boutons historiques AJLSM

/*
* AJLSM - Barre d'outils WikiEditor
* Migration MediaWiki 1.18.2 vers 1.46.2
* 14 boutons historiques, sans modification de l'extension.
*/
mw.hook( 'wikiEditor.toolbarReady' ).add( function ( $textarea ) {

var imageBase = mw.config.get( 'wgScriptPath' ) + '/images/';

function bouton( label, icon, pre, peri, post ) {
return {
label: label,
type: 'button',
icon: imageBase + icon,
action: {
type: 'encapsulate',
options: {
pre: pre,
peri: peri,
post: post
}
}
};
}

// Onglet AJLSM
$textarea.wikiEditor( 'addToToolbar', {
sections: {
ajlsm: {
type: 'toolbar',
label: 'AJLSM'
}
}
} );

// Groupe de boutons
$textarea.wikiEditor( 'addToToolbar', {
section: 'ajlsm',
groups: {
insertion: {
label: 'Insertion'
}
}
} );

// Les 14 boutons historiques
$textarea.wikiEditor( 'addToToolbar', {
section: 'ajlsm',
group: 'insertion',
tools: {

ajlsmRef: bouton(
'Insérer une référence',
'7/73/Toolbar-ref.png',
'<ref>',
'texte de la référence',
'</ref>'
),

ajlsmReferences: bouton(
'Insérer la liste des références',
'8/8d/Toolbar-references.png',
'== Références ==\n<references/>',
'',
''
),

ajlsmCategory: bouton(
'Ajouter une catégorie',
'c/c4/Toolbar_category.png',
'[[category:',
"catégorie à laquelle appartient l'article",
']]'
),

ajlsmVar: bouton(
'Insérer une variable',
'2/24/Toolbar-var.svg',
'{{var|',
'maVariable',
'}}'
),

ajlsmPath: bouton(
'Ajouter un chemin vers un fichier/dossier',
'9/96/Toolbar-path.svg',
'{{path|',
'/path/to/dir-or-file',
'}}'
),

ajlsmSyntaxHighlight: bouton(
'Insérer un bloc de code',
'1/16/Toolbar-code.svg',
'<syntaxhighlight lang="bash">\n',
"echo $(date '+%Y-%b-%d') # affiche la date en BASH",
'\n</syntaxhighlight>'
),

ajlsmRemarque: bouton(
'Insérer une remarque',
'6/6d/Toolbar-remarque.svg',
'{{remarque|',
'remarque sur le paragraphe précédent/suivant (à vous de préciser)',
'}}'
),

ajlsmImportant: bouton(
'Insérer une remarque importante',
'8/89/Important.svg',
'{{important|',
'remarque IMPORTANTE sur le paragraphe précédent/suivant (à vous de préciser)',
'}}'
),

ajlsmNotice: bouton(
'Insérer une notice',
'0/02/Notice.svg',
'{{notice|',
'notice sur le paragraphe précédent/suivant (à vous de préciser)',
'}}'
),

ajlsmTodo: bouton(
'Insérer une tâche à faire',
'2/25/Todo.svg',
'{{todo|',
'todo sur le paragraphe précédent/suivant (à vous de préciser)',
'}}'
),

ajlsmCmd: bouton(
'Insérer une commande shell',
'8/84/Toolbar-shell.svg',
'{{cmd|',
'commande, option ou flag (-h, -v, etc.)',
'}}'
),

ajlsmXmlTag: bouton(
'Insérer une balise XML',
'c/c8/Toolbar-XML-tag.svg',
'{{tag|',
'élément XML (les < > sont ajouté automatiquement)',
'}}'
),

ajlsmXmlAttr: bouton(
'Insérer un attribut XML',
'1/13/Toolbar-XML-attr.svg',
'{{attr|',
"nom de l'attribut XML (il sera @préfixé)",
'}}'
),

ajlsmValue: bouton(
'Insérer une valeur',
'4/4d/Toolbar-value.svg',
'{{value|',
'maValue',
'}}'
)
}
} );
} );

MediaWiki:AJLSM-WikiEditor.js

2026-11-06T12:28:43Z

Jlarvers : Création de l'onglet AJLSM dans WikiEditor

mw.hook( 'wikiEditor.toolbarReady' ).add( function ( $textarea ) {
$textarea.wikiEditor( 'addToToolbar', {
sections: {
ajlsm: {
type: 'toolbar',
label: 'AJLSM'
}
}
} );

$textarea.wikiEditor( 'addToToolbar', {
section: 'ajlsm',
groups: {
insertion: {
label: 'Insertion'
}
}
} );

$textarea.wikiEditor( 'addToToolbar', {
section: 'ajlsm',
group: 'insertion',
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: '}}'
}
}
}
}
} );
} );

MediaWiki:Common.js

2026-11-06T12:25:20Z

Jlarvers :

/**
* Keep code in MediaWiki:Common.js to a minimum as it is unconditionally
* loaded for all users on every wiki page. If possible create a gadget that is
* enabled by default instead of adding it here (since gadgets are fully
* optimized ResourceLoader modules with possibility to add dependencies etc.)
*
* Since Common.js isn't a gadget, there is no place to declare its
* dependencies, so we have to lazy load them with mw.loader.using on demand and
* then execute the rest in the callback. In most cases these dependencies will
* be loaded (or loading) already and the callback will not be delayed. In case a
* dependency hasn't arrived yet it'll make sure those are loaded before this.
*/
/*global mw, $, importStylesheet, importScript */
/*jshint curly:false eqnull:true, strict:false, browser:true, */
mw.loader.using( ['mediawiki.util', 'mediawiki.notify', 'jquery.client'], function () {
/* Begin of mw.loader.using callback */

/**
* Main Page layout fixes
*
* Description: Adds an additional link to the complete list of languages available.
* Maintainers: [[User:AzaToth]], [[User:R. Koot]], [[User:Alex Smotrov]]
*/
if ( mw.config.get( 'wgPageName' ) === 'Main_Page' || mw.config.get( 'wgPageName' ) === 'Talk:Main_Page' ) {
$( document ).ready( function () {
mw.util.addPortletLink( 'p-lang', '//meta.wikimedia.org/wiki/List_of_Wikipedias',
'Complete list', 'interwiki-completelist', 'Complete list of Wikipedias' );
} );
}

/**
* Redirect User:Name/skin.js and skin.css to the current skin's pages
* (unless the 'skin' page really exists)
* @source: http://www.mediawiki.org/wiki/Snippets/Redirect_skin.js
* @rev: 2
*/
if ( mw.config.get( 'wgArticleId' ) === 0 && mw.config.get( 'wgNamespaceNumber' ) === 2 ) {
var titleParts = mw.config.get( 'wgPageName' ).split( '/' );
/* Make sure there was a part before and after the slash
and that the latter is 'skin.js' or 'skin.css' */
if ( titleParts.length == 2 ) {
var userSkinPage = titleParts.shift() + '/' + mw.config.get( 'skin' );
if ( titleParts.slice( -1 ) == 'skin.js' ) {
window.location.href = mw.util.wikiGetlink( userSkinPage + '.js' );
} else if ( titleParts.slice( -1 ) == 'skin.css' ) {
window.location.href = mw.util.wikiGetlink( userSkinPage + '.css' );
}
}
}

/**
* Map addPortletLink to mw.util
*
* @deprecated: Use mw.util.addPortletLink instead.
*/
window.addPortletLink = function () {
return mw.util.addPortletLink.apply( mw.util, arguments );
};

/**
* Extract a URL parameter from the current URL
*
* @deprecated: Use mw.util.getParamValue with proper escaping
*/
window.getURLParamValue = function () {
return mw.util.getParamValue.apply( mw.util, arguments );
};

/**
* Test if an element has a certain class
*
* @deprecated: Use $(element).hasClass() instead.
*/
window.hasClass = function ( element, className ) {
return $( element ).hasClass( className );
};

/**
* @source www.mediawiki.org/wiki/Snippets/Load_JS_and_CSS_by_URL
* @rev 5
*/
// CSS
var extraCSS = mw.util.getParamValue( 'withCSS' );
if ( extraCSS ) {
if ( extraCSS.match( /^MediaWiki:[^&<>=%#]*\.css$/ ) ) {
importStylesheet( extraCSS );
} else {
mw.notify( 'Only pages from the MediaWiki namespace are allowed.', { title: 'Invalid withCSS value' } );
}
}

// JS
var extraJS = mw.util.getParamValue( 'withJS' );
if ( extraJS ) {
if ( extraJS.match( /^MediaWiki:[^&<>=%#]*\.js$/ ) ) {
importScript( extraJS );
} else {
mw.notify( 'Only pages from the MediaWiki namespace are allowed.', { title: 'Invalid withJS value' } );
}
}

/**
* Import more specific scripts if necessary
*/
if ( mw.config.get( 'wgAction' ) === 'edit' || mw.config.get( 'wgAction' ) === 'submit' || mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Upload' ) {
/* scripts specific to editing pages */
importScript( 'MediaWiki:Common.js/edit.js' );
} else if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Watchlist' ) {
/* watchlist scripts */
importScript( 'MediaWiki:Common.js/watchlist.js' );
}
if ( mw.config.get( 'wgNamespaceNumber' ) === 6 ) {
/* file description page scripts */
importScript( 'MediaWiki:Common.js/file.js' );
}

/**
* Load scripts specific to Internet Explorer
*/
if ( $.client.profile().name === 'msie' ) {
importScript( 'MediaWiki:Common.js/IEFixes.js' );
}

/**
* Fix for Windows XP Unicode font rendering
*/
if ( navigator.appVersion.search(/windows nt 5/i) !== -1 ) {
mw.util.addCSS( '.IPA { font-family: "Lucida Sans Unicode", "Arial Unicode MS"; } ' +
'.Unicode { font-family: "Arial Unicode MS", "Lucida Sans Unicode"; } ' );
}

/**
* WikiMiniAtlas
*
* Description: WikiMiniAtlas is a popup click and drag world map.
* This script causes all of our coordinate links to display the WikiMiniAtlas popup button.
* The script itself is located on meta because it is used by many projects.
* See [[Meta:WikiMiniAtlas]] for more information.
* Maintainers: [[User:Dschwen]]
*/
( function () {
var require_wikiminiatlas = false;
var coord_filter = /geohack/;
$( document ).ready( function() {
$( 'a.external.text' ).each( function( key, link ) {
if ( link.href && coord_filter.exec( link.href ) ) {
require_wikiminiatlas = true;
// break from loop
return false;
}
} );
if ( $( 'div.kmldata' ).length ) {
require_wikiminiatlas = true;
}
if ( require_wikiminiatlas ) {
mw.loader.load( '//meta.wikimedia.org/w/index.php?title=MediaWiki:Wikiminiatlas.js&action=raw&ctype=text/javascript' );
}
} );
} )();

/**
* Interwiki links to featured articles ***************************************
*
* Description: Highlights interwiki links to featured articles (or
* equivalents) by changing the bullet before the interwiki link
* into a star.
* Maintainers: [[User:R. Koot]]
*/
function LinkFA() {
if ( document.getElementById( 'p-lang' ) ) {
var InterwikiLinks = document.getElementById( 'p-lang' ).getElementsByTagName( 'li' );

for ( var i = 0; i < InterwikiLinks.length; i++ ) {
if ( document.getElementById( InterwikiLinks[i].className + '-fa' ) ) {
InterwikiLinks[i].className += ' FA';
InterwikiLinks[i].title = 'This is a featured article in another language.';
} else if ( document.getElementById( InterwikiLinks[i].className + '-ga' ) ) {
InterwikiLinks[i].className += ' GA';
InterwikiLinks[i].title = 'This is a good article in another language.';
}
}
}
}

$( LinkFA );

/**
* Collapsible tables *********************************************************
*
* Description: Allows tables to be collapsed, showing only the header. See
* [[Wikipedia:NavFrame]].
* Maintainers: [[User:R. Koot]]
*/

var autoCollapse = 2;
var collapseCaption = 'hide';
var expandCaption = 'show';

window.collapseTable = function ( tableIndex ) {
var Button = document.getElementById( 'collapseButton' + tableIndex );
var Table = document.getElementById( 'collapsibleTable' + tableIndex );

if ( !Table || !Button ) {
return false;
}

var Rows = Table.rows;
var i;

if ( Button.firstChild.data === collapseCaption ) {
for ( i = 1; i < Rows.length; i++ ) {
Rows[i].style.display = 'none';
}
Button.firstChild.data = expandCaption;
} else {
for ( i = 1; i < Rows.length; i++ ) {
Rows[i].style.display = Rows[0].style.display;
}
Button.firstChild.data = collapseCaption;
}
};

function createCollapseButtons() {
var tableIndex = 0;
var NavigationBoxes = {};
var Tables = document.getElementsByTagName( 'table' );
var i;

function handleButtonLink( index, e ) {
window.collapseTable( index );
e.preventDefault();
}

for ( i = 0; i < Tables.length; i++ ) {
if ( $( Tables[i] ).hasClass( 'collapsible' ) ) {

/* only add button and increment count if there is a header row to work with */
var HeaderRow = Tables[i].getElementsByTagName( 'tr' )[0];
if ( !HeaderRow ) continue;
var Header = HeaderRow.getElementsByTagName( 'th' )[0];
if ( !Header ) continue;

NavigationBoxes[ tableIndex ] = Tables[i];
Tables[i].setAttribute( 'id', 'collapsibleTable' + tableIndex );

var Button = document.createElement( 'span' );
var ButtonLink = document.createElement( 'a' );
var ButtonText = document.createTextNode( collapseCaption );

Button.className = 'collapseButton'; /* Styles are declared in Common.css */

ButtonLink.style.color = Header.style.color;
ButtonLink.setAttribute( 'id', 'collapseButton' + tableIndex );
ButtonLink.setAttribute( 'href', '#' );
$( ButtonLink ).on( 'click', $.proxy( handleButtonLink, ButtonLink, tableIndex ) );
ButtonLink.appendChild( ButtonText );

Button.appendChild( document.createTextNode( '[' ) );
Button.appendChild( ButtonLink );
Button.appendChild( document.createTextNode( ']' ) );

Header.insertBefore( Button, Header.firstChild );
tableIndex++;
}
}

for ( i = 0; i < tableIndex; i++ ) {
if ( $( NavigationBoxes[i] ).hasClass( 'collapsed' ) || ( tableIndex >= autoCollapse && $( NavigationBoxes[i] ).hasClass( 'autocollapse' ) ) ) {
window.collapseTable( i );
}
else if ( $( NavigationBoxes[i] ).hasClass ( 'innercollapse' ) ) {
var element = NavigationBoxes[i];
while ((element = element.parentNode)) {
if ( $( element ).hasClass( 'outercollapse' ) ) {
window.collapseTable ( i );
break;
}
}
}
}
}

$( createCollapseButtons );

/**
* Dynamic Navigation Bars (experimental)
*
* Description: See [[Wikipedia:NavFrame]].
* Maintainers: UNMAINTAINED
*/

/* set up the words in your language */
var NavigationBarHide = '[' + collapseCaption + ']';
var NavigationBarShow = '[' + expandCaption + ']';

/**
* Shows and hides content and picture (if available) of navigation bars
* Parameters:
* indexNavigationBar: the index of navigation bar to be toggled
**/
window.toggleNavigationBar = function ( indexNavigationBar, event ) {
var NavToggle = document.getElementById( 'NavToggle' + indexNavigationBar );
var NavFrame = document.getElementById( 'NavFrame' + indexNavigationBar );
var NavChild;

if ( !NavFrame || !NavToggle ) {
return false;
}

/* if shown now */
if ( NavToggle.firstChild.data === NavigationBarHide ) {
for ( NavChild = NavFrame.firstChild; NavChild != null; NavChild = NavChild.nextSibling ) {
if ( $( NavChild ).hasClass( 'NavContent' ) || $( NavChild ).hasClass( 'NavPic' ) ) {
NavChild.style.display = 'none';
}
}
NavToggle.firstChild.data = NavigationBarShow;

/* if hidden now */
} else if ( NavToggle.firstChild.data === NavigationBarShow ) {
for ( NavChild = NavFrame.firstChild; NavChild != null; NavChild = NavChild.nextSibling ) {
if ( $( NavChild ).hasClass( 'NavContent' ) || $( NavChild ).hasClass( 'NavPic' ) ) {
NavChild.style.display = 'block';
}
}
NavToggle.firstChild.data = NavigationBarHide;
}

event.preventDefault();
};

/* adds show/hide-button to navigation bars */
function createNavigationBarToggleButton() {
var indexNavigationBar = 0;
var NavFrame;
var NavChild;
/* iterate over all < div >-elements */
var divs = document.getElementsByTagName( 'div' );
for ( var i = 0; (NavFrame = divs[i]); i++ ) {
/* if found a navigation bar */
if ( $( NavFrame ).hasClass( 'NavFrame' ) ) {

indexNavigationBar++;
var NavToggle = document.createElement( 'a' );
NavToggle.className = 'NavToggle';
NavToggle.setAttribute( 'id', 'NavToggle' + indexNavigationBar );
NavToggle.setAttribute( 'href', '#' );
$( NavToggle ).on( 'click', $.proxy( window.toggleNavigationBar, window, indexNavigationBar ) );

var isCollapsed = $( NavFrame ).hasClass( 'collapsed' );
/**
* Check if any children are already hidden. This loop is here for backwards compatibility:
* the old way of making NavFrames start out collapsed was to manually add style="display:none"
* to all the NavPic/NavContent elements. Since this was bad for accessibility (no way to make
* the content visible without JavaScript support), the new recommended way is to add the class
* "collapsed" to the NavFrame itself, just like with collapsible tables.
*/
for ( NavChild = NavFrame.firstChild; NavChild != null && !isCollapsed; NavChild = NavChild.nextSibling ) {
if ( $( NavChild ).hasClass( 'NavPic' ) || $( NavChild ).hasClass( 'NavContent' ) ) {
if ( NavChild.style.display === 'none' ) {
isCollapsed = true;
}
}
}
if ( isCollapsed ) {
for ( NavChild = NavFrame.firstChild; NavChild != null; NavChild = NavChild.nextSibling ) {
if ( $( NavChild ).hasClass( 'NavPic' ) || $( NavChild ).hasClass( 'NavContent' ) ) {
NavChild.style.display = 'none';
}
}
}
var NavToggleText = document.createTextNode( isCollapsed ? NavigationBarShow : NavigationBarHide );
NavToggle.appendChild( NavToggleText );

/* Find the NavHead and attach the toggle link (Must be this complicated because Moz's firstChild handling is borked) */
for( var j = 0; j < NavFrame.childNodes.length; j++ ) {
if ( $( NavFrame.childNodes[j] ).hasClass( 'NavHead' ) ) {
NavToggle.style.color = NavFrame.childNodes[j].style.color;
NavFrame.childNodes[j].appendChild( NavToggle );
}
}
NavFrame.setAttribute( 'id', 'NavFrame' + indexNavigationBar );
}
}
}

$( createNavigationBarToggleButton );

/**
* Uploadwizard_newusers
* Switches in a message for non-autoconfirmed users at [[Wikipedia:Upload]]
*
* Maintainers: [[User:Krimpet]]
*/
function uploadwizard_newusers() {
if ( mw.config.get( 'wgNamespaceNumber' ) === 4 && mw.config.get( 'wgTitle' ) === 'Upload' && mw.config.get( 'wgAction' ) === 'view' ) {
var oldDiv = document.getElementById( 'autoconfirmedusers' ),
newDiv = document.getElementById( 'newusers' );
if ( oldDiv && newDiv ) {
var userGroups = mw.config.get( 'wgUserGroups' );
if ( userGroups ) {
for ( var i = 0; i < userGroups.length; i++ ) {
if ( userGroups[i] === 'autoconfirmed' ) {
oldDiv.style.display = 'block';
newDiv.style.display = 'none';
return;
}
}
}
oldDiv.style.display = 'none';
newDiv.style.display = 'block';
return;
}
}
}

$(uploadwizard_newusers);

/**
* Magic editintros ****************************************************
*
* Description: Adds editintros on disambiguation pages and BLP pages.
* Maintainers: [[User:RockMFR]]
*/
function addEditIntro( name ) {
$( '.editsection, #ca-edit' ).find( 'a' ).each( function ( i, el ) {
el.href = $( this ).attr( 'href' ) + '&editintro=' + name;
} );
}

if ( mw.config.get( 'wgNamespaceNumber' ) === 0 ) {
$( function () {
if ( document.getElementById( 'disambigbox' ) ) {
addEditIntro( 'Template:Disambig_editintro' );
}
} );

$( function () {
var cats = document.getElementById( 'mw-normal-catlinks' );
if ( !cats ) {
return;
}
cats = cats.getElementsByTagName( 'a' );
for ( var i = 0; i < cats.length; i++ ) {
if ( cats[i].title === 'Category:Living people' || cats[i].title === 'Category:Possibly living people' ) {
addEditIntro( 'Template:BLP_editintro' );
break;
}
}
} );
}

/**
* Description: Stay on the secure server as much as possible
* Maintainers: [[User:TheDJ]]
*/
if ( document.location && document.location.protocol && document.location.protocol === 'https:' ) {
/* New secure servers */
importScript( 'MediaWiki:Common.js/secure new.js' );
}

/* End of mw.loader.using callback */
} );
/* 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

2026-11-06T12:23:29Z

Jlarvers : Restauration des boutons WikiEditor AJLSM - premier test

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: '}}'
}
}
}
}
} );
} );

WAF 2026

2026-11-05T14:32:40Z

Jlarvers : /* Certificats automatiques (SSL Lets Encrypt) via Haproxy */

[[category:Ansile]][[category:Haproxy]][[category:modsec]][[category:coraza]]
== Documentation externe ==
Voir Coraza : https://www.coraza.io/
[[category:letsencrypt]][[category:OPNsense]][[category:opnsens]][[category:opensens]][[category:opensense]]
WAF : Web Application Firewall.

== Description de l'infrastructure ==
=== Schéma de l'infra ===

Dans notre infra (aujourd'hui Saturne3) et sur Proxmox, on a installé 4 VM.

2 VM Haproxy (en cluster) récupèrent le flux et le renvoi vers 2 VM modsecurity (en cluster) qui analysent et traitent les requêtes et renvoient vers les VM HAPROXY qui renvoient, ou non, vers les VM clients.

* Mise en place de deux nœuds Haproxy redondés via VRRP
# IP 1 : 10.0.0.30,
# IP 2 : 10.0.0.31,
# IP redondée/balancée : 10.0.0.32, IP externe redondée : 51.83.117.120)
{{important|Pré-requis pour les étapes suivantes :
# Accès par VPN Wireguard, ou,
# Accès par OpenVPN,
# Utilisateur root}}

== Ajouts des certificats SSL (manuelle) ==
=== Rajouter un domaine (un certificat SSL) dans le reverse proxy HAPROXY ===
1 -> Copier le certificat complet (voir où se trouve les certificats dans la conf apache du domaine ...-le-ssl.conf, puis réunir la clé publique et la clé privée en 1 fichier.

Depuis la VM (voir celui de portdunkerque pour exemple) vers les 2 VM HAPROXY,
dans {{path|/etc/haproxy/certs/}} en prenant soin de respecter le nom de domaine, par exemple :
<syntaxhighlight lang="bash">port-dunkerque.pleade.com.pem</syntaxhighlight>
Une fois les certificats SSL en place, relancez le service haproxy :
<syntaxhighlight lang="bash">service haproxy reload</syntaxhighlight>
{{notice|Contrairement à la recommandation qui suit, l'intégration du contenu des fichiers .crt, .key et .pem fonctionne très bien : Attention, ne pas ajouter le contenu du fichier .pem s'il existe !}}

==Certificats automatiques (SSL Lets Encrypt) via Haproxy==
{{important|Utiliser le projet Ansible : [[WAF#Ansible]]}}
{{important|Le domaine doit être géré par Haproxy. Il doit être "derrière" le pare-feu, c'est-à-dire : Firewall: NAT: One-to-One : IP interne 10.0.0.32. Ne fonctionne pas avec l'IP native du serveur.}}
===Modification du fichier haproxy.yml d'Ansible===
# Le chemin des certificats change de /etc/haproxy/ssl à /etc/haproxy/certs
# Ajout de la clé ACCOUNT_THUMBPRINT qui gère les challenge acme-challenge
===Ajout de certificat sur un nouveau domaine===
L'exemple ici porte sur port-dunkerque.pleade.com
{{important|A exécuter séquentiellement (un après l'autre, pas en parallèle) sur HAPROXY-01 et HAPROXY-02}}
====S'authentifier en tant qu'acme====
<syntaxhighlight lang="bash">$ sudo -u acme -s /!\ IMPORTANT d'être authentifié en tant qu'acme</syntaxhighlight>
====Génération des certificats via LetsEncrypt====
<syntaxhighlight lang="bash">$ acme.sh --issue -d port-dunkerque.pleade.com --stateless --server letsencrypt</syntaxhighlight>
====Déploiement dans le dossier Haproxy grâce au hook correspondant qui met à jour à chaud les certs====
<syntaxhighlight lang="bash">$ DEPLOY_HAPROXY_HOT_UPDATE=yes DEPLOY_HAPROXY_STATS_SOCKET=/var/run/haproxy/admin.sock DEPLOY_HAPROXY_PEM_PATH=/etc/haproxy/certs acme.sh --deploy -d port-dunkerque.pleade.com --deploy-hook haproxy</syntaxhighlight>
{{notice|Si, en tant qu'acme, on fait un crontab -l, on peut voir qu'une tâche de renouvellement de certificats tourne régulièrement.}}

= Certificats automatiques Let's Encrypt via HAProxy =

== Présentation ==

Les certificats TLS des domaines publiés par les serveurs HAProxy AJLSM sont gérés avec '''acme.sh''' et '''Let's Encrypt'''.

L'installation et le renouvellement des certificats sont effectués sur deux serveurs :

* '''haproxy-01''' : 10.0.0.30
* '''haproxy-02''' : 10.0.0.31

Les certificats sont stockés dans :

<syntaxhighlight lang="text">
/etc/haproxy/certs/
</syntaxhighlight>

Le hook ''haproxy'' d'acme.sh permet le déploiement des certificats et leur mise à jour à chaud par le socket d'administration HAProxy.

'''Important :'''

Les opérations doivent être effectuées '''successivement sur HAProxy-01 puis HAProxy-02''', jamais en parallèle.

Chaque serveur possède sa propre installation d'acme.sh et ses propres certificats. Il n'existe pas de synchronisation automatique des fichiers PEM entre les deux serveurs.

== 1. Prérequis ==

=== 1.1. Configuration réseau et DNS ===

Le domaine doit :

* disposer d'un enregistrement DNS public pointant vers l'adresse IP publique utilisée par l'infrastructure ;
* être acheminé par OPNsense vers la VIP HAProxy '''10.0.0.32''' ;
* être pris en charge par la configuration HAProxy.

La configuration NAT dépend de l'adresse publique concernée.

Pour l'installation de CDF du 5 novembre 2026, le routage utilise '''OPNsense Destination NAT''', et non NAT One-to-One.

'''Attention :'''

Le domaine doit être publié derrière HAProxy. La procédure de validation ACME ne fonctionne pas si les requêtes arrivent directement sur un serveur qui ne dispose pas de la configuration de validation correspondante.

La validation Let's Encrypt utilise le challenge HTTP-01 en mode '''stateless''', sur le port 80.

=== 1.2. Configuration HAProxy avec Ansible ===

La configuration HAProxy est maintenue dans le projet Ansible AJLSM.

Voir : [[WAF#Ansible]]

Les éléments nécessaires comprennent :

* le répertoire des certificats <code>/etc/haproxy/certs/</code> ;
* la clé <code>ACCOUNT_THUMBPRINT</code> utilisée pour la validation ACME ;
* la règle HTTP permettant de répondre aux requêtes <code>/.well-known/acme-challenge/</code> ;
* les ACL correspondant au domaine ;
* le backend associé à l'application.

La configuration Ansible doit être déployée et validée avant de demander le certificat.

== 2. Création d'un certificat ==

L'exemple suivant concerne le domaine :

<syntaxhighlight lang="text">
cdf-recette.pleade.com
</syntaxhighlight>

'''Toutes les opérations doivent être réalisées sur HAProxy-01, puis répétées sur HAProxy-02.'''

=== 2.1. S'authentifier en tant qu'acme ===

Depuis une session administrateur :

<syntaxhighlight lang="bash">
sudo -u acme -s
</syntaxhighlight>

'''Important :'''

Les commandes acme.sh doivent être exécutées avec l'utilisateur '''acme''', et non avec root.

=== 2.2. Générer le certificat avec Let's Encrypt ===

Toujours dans la session de l'utilisateur <code>acme</code> :

<syntaxhighlight lang="bash">
acme.sh --issue \
-d cdf-recette.pleade.com \
--stateless \
--server letsencrypt
</syntaxhighlight>

Vérifier que la commande se termine par :

<syntaxhighlight lang="text">
Success
Cert success.
</syntaxhighlight>

Les fichiers générés sont enregistrés dans :

<syntaxhighlight lang="text">
/var/lib/acme/.acme.sh/cdf-recette.pleade.com_ecc/
</syntaxhighlight>

Ce répertoire contient notamment :

* le certificat ;
* la clé privée ;
* le certificat intermédiaire ;
* la chaîne complète.

Ne pas modifier manuellement ces fichiers.

=== 2.3. Déployer le certificat dans HAProxy ===

Toujours avec l'utilisateur <code>acme</code> :

<syntaxhighlight lang="bash">
DEPLOY_HAPROXY_HOT_UPDATE=yes \
DEPLOY_HAPROXY_STATS_SOCKET=/var/run/haproxy/admin.sock \
DEPLOY_HAPROXY_PEM_PATH=/etc/haproxy/certs \
acme.sh --deploy \
-d cdf-recette.pleade.com \
--deploy-hook haproxy
</syntaxhighlight>

Cette commande :

# prépare le certificat au format PEM ;
# l'installe dans <code>/etc/haproxy/certs/</code> ;
# demande son chargement à chaud par HAProxy via le socket d'administration.

Lors de l'installation CDF du 5 novembre 2026, le résultat a été :

<syntaxhighlight lang="text">
Deploying PEM file
Moving new certificate into place
Creating new certificate '/etc/haproxy/certs/cdf-recette.pleade.com.pem' over HAProxy stats socket.
Success
</syntaxhighlight>

Le certificat a donc été émis et son déploiement a réussi.

'''Attention :'''

La réussite du déploiement ne dispense pas de vérifier que HAProxy présente effectivement le nouveau certificat lors d'une connexion HTTPS.

== 3. Vérifications après installation ==

=== 3.1. Vérifier la présence du fichier PEM ===

Depuis une session administrateur :

<syntaxhighlight lang="bash">
ls -l /etc/haproxy/certs/cdf-recette.pleade.com.pem
</syntaxhighlight>

Le fichier doit être présent dans le répertoire des certificats HAProxy.

=== 3.2. Vérifier le certificat et ses dates ===

<syntaxhighlight lang="bash">
openssl x509 \
-in /etc/haproxy/certs/cdf-recette.pleade.com.pem \
-noout -subject -dates
</syntaxhighlight>

Vérifier :

* le nom du domaine ;
* la date de début de validité ;
* la date d'expiration.

=== 3.3. Tester l'accès HTTPS ===

Depuis un poste extérieur :

<syntaxhighlight lang="bash">
curl -vI --max-time 10 \
--resolve cdf-recette.pleade.com:443:51.83.117.113 \
https://cdf-recette.pleade.com/
</syntaxhighlight>

L'option <code>--resolve</code> permet de forcer l'adresse IP publique et de contourner un éventuel cache DNS obsolète.

'''Ne pas utiliser l'option -k pour le contrôle final.'''

Il faut vérifier que :

* la négociation TLS aboutit ;
* le certificat est reconnu comme valide ;
* le certificat correspond au domaine demandé ;
* le serveur répond avec un code HTTP attendu (200 ou redirection légitime).

'''Attention :'''

Lorsque deux HAProxy partagent une VIP, un test par l'adresse IP publique ne permet pas nécessairement de savoir quel serveur a répondu.

Les deux nœuds doivent donc être contrôlés individuellement.

== 4. Répéter l'installation sur HAProxy-02 ==

Après validation de HAProxy-01 :

# se connecter à HAProxy-02 ;
# ouvrir une session sous l'utilisateur <code>acme</code> ;
# exécuter la commande <code>acme.sh --issue</code> ;
# exécuter la commande <code>acme.sh --deploy</code> ;
# vérifier la présence du fichier PEM ;
# vérifier le certificat ;
# contrôler son chargement effectif par HAProxy.

'''Important :'''

Ne jamais considérer l'installation comme terminée tant que le certificat n'a pas été installé et vérifié sur les deux serveurs.

== 5. Renouvellement automatique ==

Une tâche cron de l'utilisateur <code>acme</code> exécute régulièrement acme.sh afin de renouveler les certificats arrivant à expiration.

=== 5.1. Vérifier la tâche cron ===

Depuis une session administrateur :

<syntaxhighlight lang="bash">
sudo crontab -u acme -l
</syntaxhighlight>

Sur HAProxy-01, la tâche observée le 5 novembre 2026 est :

<syntaxhighlight lang="text">
27 19 * * * /usr/local/share/acme.sh/acme.sh --cron --home "/var/lib/acme/.acme.sh" > /dev/null
</syntaxhighlight>

=== 5.2. Lister les certificats gérés ===

<syntaxhighlight lang="bash">
sudo -u acme /usr/local/bin/acme.sh \
--list \
--home /var/lib/acme/.acme.sh
</syntaxhighlight>

Vérifier que le nouveau domaine apparaît dans la liste.

=== 5.3. Paramètres du hook HAProxy ===

Les paramètres de déploiement sont enregistrés dans la configuration propre au domaine.

Exemple pour Mercure3 :

<syntaxhighlight lang="text">
Le_DeployHook='haproxy,'
Le_Deploy_haproxy_pem_path='/etc/haproxy/certs'
Le_Deploy_haproxy_hot_update='yes'
</syntaxhighlight>

Ces paramètres permettent à acme.sh de retrouver le mécanisme de déploiement lors des renouvellements.

'''Attention :'''

La présence du hook dans la configuration ne garantit pas à elle seule que le renouvellement et le chargement à chaud aboutiront.

Le renouvellement doit être contrôlé sur les deux HAProxy.

== 6. Points d'attention ==

* Toujours intervenir successivement sur HAProxy-01 puis HAProxy-02.
* Toujours exécuter acme.sh avec l'utilisateur <code>acme</code>.
* Ne pas modifier directement les certificats gérés par acme.sh.
* Ne pas confondre émission, déploiement et activation effective du certificat.
* Vérifier le DNS public avant l'émission.
* Vérifier le fonctionnement du challenge HTTP-01 sur le port 80.
* Ne pas modifier le mécanisme de renouvellement existant sans validation.
* Contrôler la validité du certificat sur les deux HAProxy.
* Ne pas supposer qu'un certificat installé sur HAProxy-01 est automatiquement disponible sur HAProxy-02.

== 7. Historique des installations ==

=== 5 novembre 2026 — cdf-recette.pleade.com ===

{| class="wikitable"
! Élément
! Valeur ou état
|-
| Domaine
| <code>cdf-recette.pleade.com</code>
|-
| IP publique
| <code>51.83.117.113</code>
|-
| VIP HAProxy
| <code>10.0.0.32</code>
|-
| VM applicative
| <code>mercure3 — 10.0.0.43</code>
|-
| Backend HAProxy
| <code>back_mercure3</code>
|-
| Port backend
| <code>80</code>
|-
| Émission Let's Encrypt sur HAProxy-01
| Réussie
|-
| Déploiement à chaud sur HAProxy-01
| Réussi
|-
| Contrôle HTTPS
| À effectuer
|-
| Installation sur HAProxy-02
| À effectuer
|}

La procédure sera considérée comme entièrement validée après les contrôles HTTPS sur les deux serveurs.

== Configuration de HaProxy - Méthode 1 ==
On utilise ansible pour générer les fichiers de configuration dans Haproxy, les appliquer, redémarrer les Haproxy, etc.

[[WAF#Ansible|Voir la section : Ansible]]

La configuration du fichier est la même, avec la possibilité de
# variabiliser : voir section : http://mw.ajlsm.com/wiki/WAF#Variabilisation
# déployer la configuration sur les 2 Haproxy en une seule action.

Pour utiliser cette méthode, récupérer le projet '''ansible-ajlsm-haproxy''' en SVN.

La création des règles est la même que celle décrite en méthode 2.

La différence est que l'on ne travaille pas "directement" dans le fichier {{path|/etc/haproxy/haproxy.cfg}}, mais dans le fichier {{path|/ansible-ajlsm-haproxy/inventory/group_vars/ajlsm_loadbalancer/haproxy.yml}} qui est déployé en ligne de commande avec Ansible.

Cette méthode est celle utilisée en production.

== Configuration de HaProxy - Méthode 2 ==
Voir aussi projet ansible en SVN : [[WAF#Ansible]].

Modifier directement le fichier de configuration configuration {{path|/etc/haproxy/haproxy.cfg}}.

Rajouter les lignes suivantes dans la configuration {{path|/etc/haproxy/haproxy.cfg}} (dans les blocs {{path|frontend front_web}} et {{path|backend }}) :
<syntaxhighlight lang="bash">
acl host_leclientvoulu hdr(host) -i lenomdedomaineduclientvoulu.com
use_backend back_leclientvoulu if host_leclientvoulu</syntaxhighlight>
et rajouter un nouveau bloc backend comme ceci :
# Configuration avec certificat SSL :
<syntaxhighlight lang="bash">backend back_leclientvoulu
server LECLIENTVOULU ipduclientvoulu:443 check ssl verify none</syntaxhighlight>
# Configuration sans certificat :
<syntaxhighlight lang="bash">backend back_leclientvoulu
server LECLIENTVOULU ipduclientvoulu:80 check</syntaxhighlight>
Par exemple, pour archives.lamayenne.fr :
<syntaxhighlight lang="bash"> acl host_ssl_archiveslamayenne hdr(host) -i archives.lamayenne.fr
use_backend back_ssl_archiveslamayenne if host_ssl_archiveslamayenne

acl host_salledelecturearchiveslamayenne hdr(host) -i salle-de-lecture-archives.lamayenne.fr
use_backend back_salledelecturearchiveslamayenne if host_salledelecturearchiveslamayenne

...

backend back_ssl_archiveslamayenne
server ARCHIVESLAMAYENNE ad53.ajlsm.lan:443 check ssl verify none

backend back_salledelecturearchiveslamayenne
server SALLEDELECTUREARCHIVESLAMAYENNE ad53.ajlsm.lan:80 check</syntaxhighlight>

=== Traitement des blocages par IP ===
La règle apache pour le blocage des IP de chaque site : <syntaxhighlight lang="bash">RewriteCond %{REMOTE_ADDR}</syntaxhighlight> renvoie sur le Haproxy.

Le blocage d'IP ne se fait plus.

Lorsque toutes les IP doivent être bloquées sauf les accès prévus : pour le client, AJLSM, etc, (Par exemple, pour une application intranet) la '''gestion des accès par IP est à configurer dans Haproxy'''.

De plus, les [[WAF#Modification_de_la_configuration_apache_des_domaines|configurations apache]] doivent être modifiées sur chaque VM.
==== Blocage des IP dans Haproxy ====
Créez les IP allowed dans la configuration Haproxy en ajoutant, dans le {{var|frontend front_web}} et avant les autres acl, l'instruction suivante :
<syntaxhighlight lang="bash"> acl allowed_ajlsm src xx.xx.xx.xx xx.xx.xx.xx xx.xx.xx.xx/xx
acl allowed_xx_client src xx.xx.xx.xx

(Par exemple, pour les IP AJLSM et le client ad53)

acl allowed_ajlsm src 82.65.94.250 109.190.129.96 91.174.149.42 10.0.0.0/24
acl allowed_ad53_client src 85.115.60.201</syntaxhighlight>
==== Association des règles aux acl du client ====
Enfin, modifier les acl des domaines qui utilisent ces règles de blocage d'IP en ajoutant l'instruction suivante :
<syntaxhighlight lang="bash"> http-request deny if host_[le-host] !allowed_ajlsm !allowed_xx_client</syntaxhighlight>
Par exemple :
<syntaxhighlight lang="bash"> acl host_salledelecturearchiveslamayenne hdr(host) -i salle-de-lecture-archives.lamayenne.fr
use_backend back_salledelecturearchiveslamayenne if host_salledelecturearchiveslamayenne
http-request deny if host_salledelecturearchiveslamayenne !allowed_ajlsm !allowed_ad53_client</syntaxhighlight>
==== Forcer le HTTPS sur un domaine ====
On souhaite que le WAF prenne bien en compte l'acl pour un domaine avec SSL.

Ajouter la commande suivante dans l'acl concerné.
<syntaxhighlight lang="bash">http-request redirect scheme https if { hdr(Host) -i [le-domaine] } !{ ssl_fc }</syntaxhighlight>
Par exemple, pour ad53 :
<syntaxhighlight lang="bash"> acl host_ssl_archiveslamayenne hdr(host) -i archives.lamayenne.fr
use_backend back_ssl_archiveslamayenne if host_ssl_archiveslamayenne
http-request redirect scheme https if { hdr(Host) -i archives.lamayenne.fr } !{ ssl_fc }</syntaxhighlight>
Vérifier la configuration haproxy avec la commande :
<syntaxhighlight lang="bash">haproxy -f /etc/haproxy/haproxy.cfg -c -V</syntaxhighlight>

== Modification de la configuration apache des domaines ==
Dans la configuration apache de chaque site, il faut ajouter les IP privées des 2 Haproxy.
<syntaxhighlight lang="bash"> RewriteCond %{REMOTE_ADDR} !10.0.0.30
RewriteCond %{REMOTE_ADDR} !10.0.0.31</syntaxhighlight>
Puis, commenter la ligne :
<syntaxhighlight lang="bash">#RewriteRule .* /403.html [R=403,L]</syntaxhighlight>

==== Modification des logs pour le suivi des utilisateurs ====
Lorsque l'on bascule le flux vers le WAF, c'est l'IP de Haproxy qui est la seule à communiquer avec la VM.

Pour avoir des statistiques du nombre d'utilisateurs, il faut modifier les configuration apache et ajoutant les instructions suivantes (conserver la configuration hors WAF en cas de suppression du WAF) :

Activer le module Apache remoteip :
<syntaxhighlight lang="bash">a2enmod remoteip</syntaxhighlight>
Modifier la configuration Apache du site :
<syntaxhighlight lang="bash"> # Configuration des logs pour suivi par IP utilisateurs
RemoteIPHeader X-Forwarded-For
LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" forwarded

ErrorLog /var/log/apache2/archives.lamayenne.fr.errors.log
CustomLog /var/log/apache2/archives.lamayenne.fr.log forwarded
# Fin configuration des logs pour suivi par IP utilisateurs

#### Configuration log hors WAF
#ErrorLog /var/log/apache2/archives.lamayenne.fr.errors.log
#CustomLog /var/log/apache2/archives.lamayenne.fr.log combined
#### Fin configuration log hors WAF</syntaxhighlight>

== Application des règles HaProxy ==
Une fois les modifications terminées, on applique la configuration en relançant le service.
=== Redémarrer HAPROXY ===
<syntaxhighlight lang="bash">service haproxy restart</syntaxhighlight>

=== Vérifier que le HAPROXY est en vie ===
<syntaxhighlight lang="bash">service haproxy status</syntaxhighlight>

=== Logrotate Haproxy ===
Le logrotate est configuré et fait une rotation journalière (configuration dans {{path|/etc/logrotate.d/haproxy}}),
Il y a un palier maximum de 500M par fichier de log (on peut adapter).

Le log est compressé (en .1, .2.gz ...) soit lorsqu'il atteint 500M, soit au terme de la journée.
Les plus anciens logs compressés sont supprimés graduellement et automatiquement.

La conf est la suivante :
<syntaxhighlight lang="bash">/var/log/haproxy.log {
daily
rotate 15
maxsize 500M</syntaxhighlight>

== Problèmes et solutions ==
En cas d'erreur de configuration, on peut sortir un état plus détaillé du service haproxy avec la commande :
<syntaxhighlight lang="bash">$ sudo systemctl status haproxy.service -l --no-pager
● haproxy.service - HAProxy Load Balancer
Loaded: loaded (/lib/systemd/system/haproxy.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2022-05-19 10:36:36 UTC; 9s ago
Docs: man:haproxy(1)
file:/usr/share/doc/haproxy/configuration.txt.gz
Process: 88895 ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q $EXTRAOPTS (code=exited, status=0/SUCCESS)
Main PID: 88906 (haproxy)
Tasks: 5 (limit: 9327)
Memory: 9.4M
CGroup: /system.slice/haproxy.service
├─88906 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -S /run/haproxy-master.sock
└─88916 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -S /run/haproxy-master.sock

May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53goaccess started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53goaccess started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_salledelecturearchiveslamayenne started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_salledelecturearchiveslamayenne started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53internetpublicationajlsm started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53internetpublicationajlsm started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53preprodajlsm started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53preprodajlsm started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53slecturepublicationajlsm started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53slecturepublicationajlsm started.</syntaxhighlight>
== Tester un domaine en passant par le reverse proxy HAPROXY ==
(sans avoir à faire une migration PROD / sans impact CLIENT).

Les tests sont lancés depuis votre poste de travail en suivant les instructions ci-dessous.

'''Exemple : Tests sur la VM Port Dunkerque'''

Rajouter cette ligne dans le fichier hosts du poste de travail d'où seront lancés les tests :
<syntaxhighlight lang="bash">51.83.117.120 port-dunkerque.pleade.com</syntaxhighlight>
{{remarque|Pour info, cette IP 51.83.117.120 pointe sur l'IP redondée du HAPROXY soit 10.0.0.32.}}
Il faut bien tester pour détecter d'éventuels faux positifs (logs : {{path|/var/log/haproxy.log}})
== Réplication de la configuration dans les 2 Haproxy ==
Une fois la configuration {{path|/etc/haproxy/haproxy.cfg}} testée et validée dans le Haproxy01, répliquez cette configuration dans Haproxy02.
== Ansible ==
=== Réplication avec ansile ===
{{important|Source V1 pour l'ansibelisation du déploiement Haproxy dans le SVN sous le nom : {{path|ansible-ajlsm/trunk/ansible-ajlsm-haproxy}}.

Après chaque modification, pensez à commiter !!!}}

{{notice|Ne pas oublier de changer les mots de passes dans inventory/ajlsm_loadbalancer.inventory (à terme il faudra utiliser des clés publiques ainsi qu'Ansible-Vault)}}
==== Installation de Ansible ====
Il faut installer Ansible au préalable ( https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#installing-ansible-on-ubuntu )
==== Paramétrage de Ansible ====
#Ajouter la variable d'environnement.
#Modifier les clés dans le fichier ansible-ajlsm-haproxy/inventory/ajlsm_loadbalancer.inventory

==== Variabilisation ====
Par exemple, les IP pour le traitement des accès par IP et blocage, on variabilise la configuration dans Haproxy en ajoutant, Dans le fichier {{path|/ansible-ajlsm-haproxy/inventory/group_vars/ajlsm_loadbalancer/haproxy.yml}} et juste avant {{var|frontend front_web}} :

<syntaxhighlight lang="bash">---
haproxy_allowed_ips_ajlsm: " xx.xx.xx.xx xx.xx.xx.xx xx.xx.xx.xx/xx"
haproxy_allowed_ips_[le-client]_client: "xx.xx.xx.xx"
haproxy_custom_configuration: |</syntaxhighlight>
Puis en ajoutant, dans le frontend front_web et avant les autres acl, l'instruction suivante :
<syntaxhighlight lang="bash"> acl allowed_ajlsm src {{ haproxy_allowed_ips_ajlsm }}
acl allowed_[le-client]_client src {{ haproxy_allowed_ips_[le-client]_client }}</syntaxhighlight>
Par exemple, pour AJLSM et ad53 :
<syntaxhighlight lang="bash">---
haproxy_allowed_ips_ajlsm: "82.65.94.250 109.190.129.96 91.174.149.42 10.0.0.0/24"
haproxy_allowed_ips_ad53_client: "85.115.60.201"
haproxy_custom_configuration: |

...

acl allowed_ajlsm src {{ haproxy_allowed_ips_ajlsm }}
acl allowed_ad53_client src {{ haproxy_allowed_ips_ad53_client }}</syntaxhighlight>
==== Réplication ====
#Il faut être sous VPN.
#Dans {{path|/etc/host}}, ajouter les 2 hosts : 10.0.0.30 haproxy01.ajlsm.lan, et : 10.0.0.31 haproxy02.ajlsm.lan
#Après avoir testé la configuration dans Haproxy01, créer le fichier Haproxy.yml (copie du fichier Haproxy01 en retirant les sections "global" et "default") et ajoutant les variables, si nécessaire.
#Le fichier Haproxy.yml doit être placé dans le répertoire {{path|/ansible-ajlsm-haproxy/inventory/group_vars/ajlsm_loadbalancer/haproxy.yml}}
#Lancer la commande depuis la racine du dossier décompressé (il faut avoir ansible.cfg en visu lorqu'on fait un ls).
<syntaxhighlight lang="bash">ansible-playbook ./plays/deploy.haproxy.yml -l ajlsm_loadbalancer</syntaxhighlight>
{{notice|Il faut un environnement python. Penser à lancer <syntaxhighlight lang="bash">source .venv/bin/activate</syntaxhighlight> si vous travaillez dans un environnement spécifique}}
<syntaxhighlight lang="bash">source .venv/bin/activate && ansible-playbook ./plays/deploy.haproxy.yml -l ajlsm_loadbalancer</syntaxhighlight>
Si tout va bien :
<syntaxhighlight lang="bash">ansible-ajlsm-haproxy ~$ ansible-playbook ./plays/deploy.haproxy.yml -l ajlsm_loadbalancer

PLAY [ajlsm_loadbalancer] ****************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] *******************************************************************************************************************************************************************************************************************
ok: [haproxy01.ajlsm.lan]
ok: [haproxy02.ajlsm.lan]

TASK [haproxy : Install packages] ********************************************************************************************************************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [haproxy : Deploy configuration and validate it] ************************************************************************************************************************************************************************************
changed: [haproxy02.ajlsm.lan]
changed: [haproxy01.ajlsm.lan]

TASK [haproxy : Restore configuration (validation failed)] *******************************************************************************************************************************************************************************
skipping: [haproxy01.ajlsm.lan]
skipping: [haproxy02.ajlsm.lan]

TASK [haproxy : Remove restored backup file] *********************************************************************************************************************************************************************************************
skipping: [haproxy01.ajlsm.lan]
skipping: [haproxy02.ajlsm.lan]

TASK [haproxy : Start service and enable it on boot] *************************************************************************************************************************************************************************************
ok: [haproxy01.ajlsm.lan]
ok: [haproxy02.ajlsm.lan]

TASK [haproxy : Failure] *****************************************************************************************************************************************************************************************************************
skipping: [haproxy01.ajlsm.lan]
skipping: [haproxy02.ajlsm.lan]

RUNNING HANDLER [haproxy : restart haproxy] **********************************************************************************************************************************************************************************************
changed: [haproxy02.ajlsm.lan]
changed: [haproxy01.ajlsm.lan]

PLAY RECAP *******************************************************************************************************************************************************************************************************************************
haproxy01.ajlsm.lan : ok=5 changed=2 unreachable=0 failed=0 skipped=3 rescued=0 ignored=0
haproxy02.ajlsm.lan : ok=5 changed=2 unreachable=0 failed=0 skipped=3 rescued=0 ignored=0 </syntaxhighlight>

==== En cas d'erreur après le lancement de la commande ====
===== Essayer la commande =====
<syntaxhighlight lang="bash">ANSIBLE_CONFIG=ansible.cfg ansible-playbook ./plays/deploy.haproxy.yml -l ajlsm_loadbalancer</syntaxhighlight>

Cette partie est à compléter selon l'évolution du script de déploiement.
===== 1 - Si la commande renvoie : =====
<syntaxhighlight lang="bash">-bash: ansible-playbook: command not found</syntaxhighlight>
Voir tuto : https://stackoverflow.com/questions/63177609/zsh-command-not-found-ansible-after-pip-installing
===== 2 - Si la commande renvoie : =====
<syntaxhighlight lang="bash">ansible-playbook ./plays/deploy.haproxy.yml -l ajlsm_loadbalancer

PLAY [ajlsm_loadbalancer] *****************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ********************************************************************************************************************************************************************************************************************************
fatal: [haproxy01.ajlsm.lan]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: Could not resolve hostname haproxy01.ajlsm.lan: nodename nor servname provided, or not known", "unreachable": true}
fatal: [haproxy02.ajlsm.lan]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: Could not resolve hostname haproxy02.ajlsm.lan: nodename nor servname provided, or not known", "unreachable": true}

PLAY RECAP ********************************************************************************************************************************************************************************************************************************************
haproxy01.ajlsm.lan : ok=0 changed=0 unreachable=1 failed=0 skipped=0 rescued=0 ignored=0
haproxy02.ajlsm.lan : ok=0 changed=0 unreachable=1 failed=0 skipped=0 rescued=0 ignored=0</syntaxhighlight>
Dans {{path|/etc/host}}, ajouter les 2 hosts :
#10.0.0.30 haproxy01.ajlsm.lan
#10.0.0.31 haproxy02.ajlsm.lan

==== Reste à faire ====
Fine-tuning pour une maintenance simplifiée + le vault&clé publique pour la sécurité des mots de passes
# Il faudrait vaulter des choses,
# améliorer le playbook & le rôle
# ainsi que variabiliser plus de choses;

== Migrer un site vers HAPROXY (mise en production) ==
(après avoir testé)

* Soit changer le DNS vers 51.83.117.120 (le client doit faire pointer son DNS sur cette IP)
* Soit aller dans les NAT One-to-One (1:1) d'OPNSENSE, et changer l'IP du client vers 10.0.0.32 (sur la correspondance IP externe client <-> IP interne client de la page)
Lors d'une mise en production, pour éviter faire changer aux clients le DNS tout de suite et pour garder un débrayage facile : depuis le pare-feu OPNSense -> firewall -> NAT -> one-to-one, on fait pointer l'IP initiale de la VM vers 10.0.0.32.

Dans l'exemple pour PORT DUNKERQUE, ça voudrait dire faire pointer 46.105.188.170 sur 10.0.0.32 au lieu de 10.0.0.24.

Voir la copie d'écran de OPNSense : [[media:Nat.png]]

== Arrêter le WAF ==
En cas de problème avec une VM client (un blocage, ralentissement, faux positifs, etc.)
* Modifier les configuration apache en décommentant <syntaxhighlight lang="bash">#RewriteRule .* /403.html [R,L]</syntaxhighlight>
et en remettant les règles pour les logs (commenter la section et décommenter l'autre) :
<syntaxhighlight lang="bash"> # Configuration des logs pour suivi par IP utilisateurs
#RemoteIPHeader X-Forwarded-For
#LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" forwarded

#ErrorLog /var/log/apache2/chercher-archives.lamayenne.fr.errors.log
#CustomLog /var/log/apache2/chercher-archives.lamayenne.fr.log forwarded
# Fin configuration des logs pour suivi par IP utilisateurs

#### Configuration log hors WAF
ErrorLog /var/log/apache2/archives.lamayenne.fr.errors.log
CustomLog /var/log/apache2/archives.lamayenne.fr.log combined
#### Fin configuration log hors WAF </syntaxhighlight>
* Remettre l'IP interne du client (et pas celle du HAPROXY) dans le NAT 1:1 d'OPNSENSE.
* Ou bien, éteindre les deux machines VM modsec-spoe (Proxmox Saturne) pour désactiver le WAF de force.
== Faux positifs ==
On parle de "faux positif " lorsque un paquet anodin (ne constituant aucune menace réelle) est détecté comme tentative d'intrusion.

On parle de "faux négatif" lorsqu'une tentative d'intrusion n'est pas détectée.

{{important|En attente de la nouvelle documentation de Coraza}}

= Gestion d'un faux positif Coraza (OWASP CRS) sur Archives de la Mayenne =

== Contexte ==

L'application Archives de la Mayenne (Drupal + Pleade/Lucene) générait une erreur HTTP 403 sur certaines recherches contenant :

<syntaxhighlight lang="text">
Saint-Vénérand (Laval)
</syntaxhighlight>

Le WAF Coraza détectait à tort une tentative d'injection SQL car la chaîne :

<syntaxhighlight lang="text">
Vénérand (
</syntaxhighlight>

contient le motif :

<syntaxhighlight lang="text">
rand (
</syntaxhighlight>

qui correspond à une signature SQL de la règle OWASP CRS 942151.

== Identification du faux positif ==

Recherche dans les logs Coraza :

<syntaxhighlight lang="bash">
tail -f /var/log/coraza-spoa/coraza-agent.log
</syntaxhighlight>

Extrait du log :

<syntaxhighlight lang="bash">
{
"rule_id":942151,
"msg":"SQL Injection Attack: SQL function name detected",
"data":"Matched Data: rand ( found within ARGS:fquery1: Saint-Vénérand (Laval)"
}
</syntaxhighlight>

La règle responsable est :

<syntaxhighlight lang="text">
942151 - SQL Injection Attack: SQL function name detected
</syntaxhighlight>

== Localisation de la configuration Coraza ==

Service :

<syntaxhighlight lang="bash">
systemctl status coraza-spoa
</syntaxhighlight>

Configuration principale :

<syntaxhighlight lang="text">
/etc/coraza-spoa/config.yaml
</syntaxhighlight>

Extrait :

<syntaxhighlight lang="yaml">
Include /etc/coraza-spoa/custom-rules/*.conf
</syntaxhighlight>

Le fichier de règles est généré automatiquement par Ansible :

<syntaxhighlight lang="text">
/etc/coraza-spoa/custom-rules/900-runtime-overrides.conf
</syntaxhighlight>

== Localisation de la source Ansible ==

Recherche de la variable :

<syntaxhighlight lang="bash">
grep -R "coraza_spoa_custom_rules_request_body_exclusions" -n .
</syntaxhighlight>

Résultat :

<syntaxhighlight lang="text">
roles/coraza/templates/custom-rules.conf.j2
inventory/group_vars/ajlsm_loadbalancer/coraza.yml
</syntaxhighlight>

Template générateur :

<syntaxhighlight lang="text">
roles/coraza/templates/custom-rules.conf.j2
</syntaxhighlight>

Variables du groupe load balancer :

<syntaxhighlight lang="text">
inventory/group_vars/ajlsm_loadbalancer/coraza.yml
</syntaxhighlight>

== Vérification de la prise en compte de la variable ==

Contrôle de la variable vue par Ansible :

<syntaxhighlight lang="bash">
ansible -i inventory haproxy01.ajlsm.lan \
-m debug \
-a 'var=coraza_spoa_custom_rules_request_body_exclusions'
</syntaxhighlight>

La nouvelle règle doit apparaître dans la sortie.

== Ajout de l'exception ==

Modification du fichier :

<syntaxhighlight lang="text">
inventory/group_vars/ajlsm_loadbalancer/coraza.yml
</syntaxhighlight>

Ajout dans la section :

<syntaxhighlight lang="yaml">
coraza_spoa_custom_rules_request_body_exclusions:
</syntaxhighlight>

Règle finale retenue :

<syntaxhighlight lang="yaml">
- id: 123471
variable: "REQUEST_FILENAME"
operator: "@rx"
pattern: "^/(archives-en-ligne|pleade)/.*results(\\.html|\\.ajax-html)$"
actions: "nolog,pass,ctl:ruleRemoveTargetById=942151;ARGS:/^(?:query[0-9]+|fquery[0-9]+)$/"
</syntaxhighlight>

Cette règle :

* s'applique aux pages de résultats Pleade ;
* couvre les pages HTML classiques et les appels AJAX ;
* retire la règle CRS 942151 ;
* uniquement pour le paramètre ARGS:fquery1 ;
* conserve toutes les autres protections CRS.

Exemples d'URLs couvertes :

<syntaxhighlight lang="text">
/archives-en-ligne/custom-results.html
/archives-en-ligne/results.html
/archives-en-ligne/functions/ead/custom-results.ajax-html
/pleade/custom-results.html
/pleade/functions/ead/custom-results.ajax-html
</syntaxhighlight>

Ainsi que les motifs suivants :

<syntaxhighlight lang="text">
ARGS:query1
ARGS:query2
ARGS:query3
ARGS:fquery1
ARGS:fquery2
</syntaxhighlight>

== Vérification du rendu du template ==

Simulation du déploiement :

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

Le diff doit montrer :

<syntaxhighlight lang="apache">
SecRule REQUEST_FILENAME "@rx ^/(archives-en-ligne|pleade)/.*results(\.html|\.ajax-html)$" \
"id:123471,phase:1,nolog,pass,ctl:ruleRemoveTargetById=942151;ARGS:/^(?:query[0-9]+|fquery[0-9]+)$/"
</syntaxhighlight>

== Déploiement ==

Attention : le rôle Coraza est indépendant du rôle HAProxy.

Le playbook HAProxy :

<syntaxhighlight lang="text">
plays/deploy.haproxy.yml
</syntaxhighlight>

ne déploie pas les règles Coraza.

Le playbook Coraza est :

<syntaxhighlight lang="text">
plays/deploy.coraza.yml
</syntaxhighlight>

Déploiement sur tous les load balancers :

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

Déploiement uniquement sur haproxy01 :

<syntaxhighlight lang="bash">
ansible-playbook \
-i inventory \
./plays/deploy.coraza.yml \
--limit haproxy01.ajlsm.lan \
--diff
</syntaxhighlight>

Déploiement uniquement sur haproxy02 :

<syntaxhighlight lang="bash">
ansible-playbook \
-i inventory \
./plays/deploy.coraza.yml \
--limit haproxy02.ajlsm.lan \
--diff
</syntaxhighlight>

== Vérifications après déploiement ==

Contrôle de la présence de la règle :

<syntaxhighlight lang="bash">
grep -R "123471\|942151" /etc/coraza-spoa/custom-rules -n
</syntaxhighlight>

Résultat attendu :

<syntaxhighlight lang="text">
/etc/coraza-spoa/custom-rules/900-runtime-overrides.conf:
SecRule REQUEST_FILENAME "@rx ^/(archives-en-ligne|pleade)/.*results(\.html|\.ajax-html)$" \
"id:123471,...ctl:ruleRemoveTargetById=942151;ARGS:fquery1"
</syntaxhighlight>

Contrôle du service :

<syntaxhighlight lang="bash">
systemctl status coraza-spoa
</syntaxhighlight>

Vérification via Ansible :

<syntaxhighlight lang="bash">
ansible -i inventory ajlsm_loadbalancer \
-m shell \
-a 'grep -R "123471\|942151" /etc/coraza-spoa/custom-rules -n && systemctl is-active coraza-spoa'
</syntaxhighlight>

== Validation fonctionnelle ==

Tester la recherche :

<syntaxhighlight lang="text">
Saint-Vénérand (Laval)
</syntaxhighlight>

L'URL principale ne doit plus renvoyer de 403 :

<syntaxhighlight lang="text">
/archives-en-ligne/custom-results.html
</syntaxhighlight>

Les appels AJAX associés ne doivent plus être bloqués :

<syntaxhighlight lang="text">
/archives-en-ligne/functions/ead/custom-results.ajax-html
</syntaxhighlight>

Les logs Coraza ne doivent plus contenir de déclenchement de la règle 942151 pour le paramètre :

<syntaxhighlight lang="text">
ARGS:fquery1
</syntaxhighlight>

== Points importants ==

* Les règles Coraza sont gérées par Ansible.
* Toute modification manuelle dans /etc/coraza-spoa/custom-rules/ sera écrasée lors d'un prochain déploiement.
* La source de vérité est :

<syntaxhighlight lang="text">
inventory/group_vars/ajlsm_loadbalancer/coraza.yml
</syntaxhighlight>

* Les déploiements de configuration HAProxy et Coraza sont indépendants.
* Une modification des règles Coraza nécessite l'exécution du playbook :

<syntaxhighlight lang="text">
plays/deploy.coraza.yml
</syntaxhighlight>

Sur le poste local, dans le répertoire ansible-ajlsm, lancez :
<syntaxhighlight lang="bash">
ansible-playbook -i inventory ./plays/deploy.coraza.yml --limit ajlsm_loadbalancer --diff
</syntaxhighlight>
<syntaxhighlight lang="yaml">
ansible-playbook -i inventory ./plays/deploy.coraza.yml --limit ajlsm_loadbalancer --diff

PLAY [Deploy Coraza SPOA WAF] ***************************************************************************************************************************

TASK [Gathering Facts] **********************************************************************************************************************************
[WARNING]: Host 'haproxy02.ajlsm.lan' is using the discovered Python interpreter at '/usr/bin/python3.10', but future installation of another Python interpreter could cause a different interpreter to be discovered. See https://docs.ansible.com/ansible-core/2.20/reference_appendices/interpreter_discovery.html for more information.
ok: [haproxy02.ajlsm.lan]
[WARNING]: Host 'haproxy01.ajlsm.lan' is using the discovered Python interpreter at '/usr/bin/python3.10', but future installation of another Python interpreter could cause a different interpreter to be discovered. See https://docs.ansible.com/ansible-core/2.20/reference_appendices/interpreter_discovery.html for more information.
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Install build dependencies] **************************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Install Go via snap] *********************************************************************************************************************
ok: [haproxy01.ajlsm.lan]
ok: [haproxy02.ajlsm.lan]

TASK [coraza : Create build directory] ******************************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Clone coraza-spoa repository] ************************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Check if coraza-spoa binary already exists] **********************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Build coraza-spoa] ***********************************************************************************************************************
skipping: [haproxy01.ajlsm.lan]
skipping: [haproxy02.ajlsm.lan]

TASK [coraza : Install coraza-spoa binary] **************************************************************************************************************
skipping: [haproxy01.ajlsm.lan]
skipping: [haproxy02.ajlsm.lan]

TASK [coraza : Create coraza-spoa group] ****************************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Create coraza-spoa user] *****************************************************************************************************************
ok: [haproxy01.ajlsm.lan]
ok: [haproxy02.ajlsm.lan]

TASK [coraza : Create configuration directory] **********************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Create log directories] ******************************************************************************************************************
ok: [haproxy01.ajlsm.lan] => (item=/var/log/coraza-spoa)
ok: [haproxy02.ajlsm.lan] => (item=/var/log/coraza-spoa)
ok: [haproxy02.ajlsm.lan] => (item=/var/log/coraza-spoa/audit)
ok: [haproxy01.ajlsm.lan] => (item=/var/log/coraza-spoa/audit)

TASK [coraza : Create log files] ************************************************************************************************************************
ok: [haproxy02.ajlsm.lan] => (item=server.log)
ok: [haproxy01.ajlsm.lan] => (item=server.log)
ok: [haproxy01.ajlsm.lan] => (item=error.log)
ok: [haproxy02.ajlsm.lan] => (item=error.log)
ok: [haproxy01.ajlsm.lan] => (item=audit.log)
ok: [haproxy02.ajlsm.lan] => (item=audit.log)
ok: [haproxy01.ajlsm.lan] => (item=debug.log)
ok: [haproxy02.ajlsm.lan] => (item=debug.log)
ok: [haproxy01.ajlsm.lan] => (item=coraza-agent.log)
ok: [haproxy02.ajlsm.lan] => (item=coraza-agent.log)

TASK [coraza : Create rollback backup directory] ********************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Deploy coraza.cfg for HAProxy] ***********************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Check if current coraza-spoa config exists] **********************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Check if current custom rules file exists] ***********************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Backup current coraza-spoa config] *******************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Backup current custom rules file] ********************************************************************************************************
changed: [haproxy01.ajlsm.lan]
changed: [haproxy02.ajlsm.lan]

TASK [coraza : Deploy coraza-spoa config.yaml] **********************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Create custom rules directory] ***********************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Deploy custom rules] *********************************************************************************************************************
--- before: /etc/coraza-spoa/custom-rules/900-runtime-overrides.conf
+++ after: /Users/jlarvers/.ansible/tmp/ansible-local-20994a3e3jiy7/tmp2vqgd1ck/custom-rules.conf.j2
@@ -47,7 +47,7 @@
SecRule REQUEST_FILENAME "@rx /full_html?" \
"id:123470,phase:1,nolog,pass,ctl:requestBodyAccess=Off"
SecRule REQUEST_FILENAME "@rx ^/(archives-en-ligne|pleade)/.*results(\.html|\.ajax-html)$" \
- "id:123471,phase:1,nolog,pass,ctl:ruleRemoveTargetById=942151;ARGS:fquery1"
+ "id:123471,phase:1,nolog,pass,ctl:ruleRemoveTargetById=942151;ARGS:/^(?:query[0-9]+|fquery[0-9]+)$/"

SecRequestBodyLimit 524288000
SecRequestBodyNoFilesLimit 524288000

changed: [haproxy02.ajlsm.lan]
--- before: /etc/coraza-spoa/custom-rules/900-runtime-overrides.conf
+++ after: /Users/jlarvers/.ansible/tmp/ansible-local-20994a3e3jiy7/tmpd0a58h10/custom-rules.conf.j2
@@ -47,7 +47,7 @@
SecRule REQUEST_FILENAME "@rx /full_html?" \
"id:123470,phase:1,nolog,pass,ctl:requestBodyAccess=Off"
SecRule REQUEST_FILENAME "@rx ^/(archives-en-ligne|pleade)/.*results(\.html|\.ajax-html)$" \
- "id:123471,phase:1,nolog,pass,ctl:ruleRemoveTargetById=942151;ARGS:fquery1"
+ "id:123471,phase:1,nolog,pass,ctl:ruleRemoveTargetById=942151;ARGS:/^(?:query[0-9]+|fquery[0-9]+)$/"

SecRequestBodyLimit 524288000
SecRequestBodyNoFilesLimit 524288000

changed: [haproxy01.ajlsm.lan]

TASK [coraza : Remove legacy split custom rules files] **************************************************************************************************
ok: [haproxy01.ajlsm.lan] => (item=900-legacy-overrides.conf)
ok: [haproxy02.ajlsm.lan] => (item=900-legacy-overrides.conf)
ok: [haproxy01.ajlsm.lan] => (item=900-exclusions.conf)
ok: [haproxy02.ajlsm.lan] => (item=900-exclusions.conf)
ok: [haproxy01.ajlsm.lan] => (item=910-crs-policy.conf)
ok: [haproxy02.ajlsm.lan] => (item=910-crs-policy.conf)
ok: [haproxy01.ajlsm.lan] => (item=920-body-limits.conf)
ok: [haproxy02.ajlsm.lan] => (item=920-body-limits.conf)

TASK [coraza : Validate coraza-spoa config and custom rules before restart] *****************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Deploy coraza-spoa systemd unit] *********************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Enable and start coraza-spoa service] ****************************************************************************************************
ok: [haproxy01.ajlsm.lan]
ok: [haproxy02.ajlsm.lan]

RUNNING HANDLER [coraza : Restart coraza-spoa] **********************************************************************************************************
changed: [haproxy01.ajlsm.lan]
changed: [haproxy02.ajlsm.lan]

PLAY RECAP **********************************************************************************************************************************************
haproxy01.ajlsm.lan : ok=25 changed=3 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
haproxy02.ajlsm.lan : ok=25 changed=3 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
</syntaxhighlight>
Les paramètres suivants puvent être utilisés avec ansible :
{| class="wikitable"
! Option
! Description
! Modifie le serveur
! Affiche les différences
! Usage typique
|-
| aucune option
| Exécution normale du playbook
| Oui
| Non
| Déploiement standard
|-
| --check
| Simulation (dry-run)
| Non
| Non
| Vérifier ce qui serait modifié
|-
| --diff
| Exécution réelle avec affichage des différences
| Oui
| Oui
| Déployer en visualisant les changements
|-
| --check --diff
| Simulation avec affichage des différences
| Non
| Oui
| Vérifier précisément les modifications avant déploiement
|-
| --limit <hôte>
| Limite l'exécution à un ou plusieurs hôtes
| Selon les autres options
| Selon les autres options
| Tester sur un seul serveur
|-
| --tags <tag>
| Exécute uniquement les tâches portant un tag donné
| Selon les autres options
| Selon les autres options
| Déployer uniquement un composant spécifique
|-
| --skip-tags <tag>
| Ignore les tâches portant un tag donné
| Selon les autres options
| Selon les autres options
| Exclure une partie du playbook
|-
| -v
| Mode verbeux
| Selon les autres options
| Selon les autres options
| Voir davantage d'informations
|-
| -vv
| Mode très verbeux
| Selon les autres options
| Selon les autres options
| Débogage
|-
| -vvv
| Mode débogage avancé
| Selon les autres options
| Selon les autres options
| Analyse détaillée des connexions et modules
|}

= Coraza =

WAF 2026

2026-11-05T14:31:26Z

Jlarvers : /* Certificats automatiques (SSL Lets Encrypt) via Haproxy */

[[category:Ansile]][[category:Haproxy]][[category:modsec]][[category:coraza]]
== Documentation externe ==
Voir Coraza : https://www.coraza.io/
[[category:letsencrypt]][[category:OPNsense]][[category:opnsens]][[category:opensens]][[category:opensense]]
WAF : Web Application Firewall.

== Description de l'infrastructure ==
=== Schéma de l'infra ===

Dans notre infra (aujourd'hui Saturne3) et sur Proxmox, on a installé 4 VM.

2 VM Haproxy (en cluster) récupèrent le flux et le renvoi vers 2 VM modsecurity (en cluster) qui analysent et traitent les requêtes et renvoient vers les VM HAPROXY qui renvoient, ou non, vers les VM clients.

* Mise en place de deux nœuds Haproxy redondés via VRRP
# IP 1 : 10.0.0.30,
# IP 2 : 10.0.0.31,
# IP redondée/balancée : 10.0.0.32, IP externe redondée : 51.83.117.120)
{{important|Pré-requis pour les étapes suivantes :
# Accès par VPN Wireguard, ou,
# Accès par OpenVPN,
# Utilisateur root}}

== Ajouts des certificats SSL (manuelle) ==
=== Rajouter un domaine (un certificat SSL) dans le reverse proxy HAPROXY ===
1 -> Copier le certificat complet (voir où se trouve les certificats dans la conf apache du domaine ...-le-ssl.conf, puis réunir la clé publique et la clé privée en 1 fichier.

Depuis la VM (voir celui de portdunkerque pour exemple) vers les 2 VM HAPROXY,
dans {{path|/etc/haproxy/certs/}} en prenant soin de respecter le nom de domaine, par exemple :
<syntaxhighlight lang="bash">port-dunkerque.pleade.com.pem</syntaxhighlight>
Une fois les certificats SSL en place, relancez le service haproxy :
<syntaxhighlight lang="bash">service haproxy reload</syntaxhighlight>
{{notice|Contrairement à la recommandation qui suit, l'intégration du contenu des fichiers .crt, .key et .pem fonctionne très bien : Attention, ne pas ajouter le contenu du fichier .pem s'il existe !}}

==Certificats automatiques (SSL Lets Encrypt) via Haproxy==
{{important|Utiliser le projet Ansible : [[WAF#Ansible]]}}
{{important|Le domaine doit être géré par Haproxy. Il doit être "derrière" le pare-feu, c'est-à-dire : Firewall: NAT: One-to-One : IP interne 10.0.0.32. Ne fonctionne pas avec l'IP native du serveur.}}
===Modification du fichier haproxy.yml d'Ansible===
# Le chemin des certificats change de /etc/haproxy/ssl à /etc/haproxy/certs
# Ajout de la clé ACCOUNT_THUMBPRINT qui gère les challenge acme-challenge
===Ajout de certificat sur un nouveau domaine===
L'exemple ici porte sur port-dunkerque.pleade.com
{{important|A exécuter séquentiellement (un après l'autre, pas en parallèle) sur HAPROXY-01 et HAPROXY-02}}
====S'authentifier en tant qu'acme====
<syntaxhighlight lang="bash">$ sudo -u acme -s /!\ IMPORTANT d'être authentifié en tant qu'acme</syntaxhighlight>
====Génération des certificats via LetsEncrypt====
<syntaxhighlight lang="bash">$ acme.sh --issue -d port-dunkerque.pleade.com --stateless --server letsencrypt</syntaxhighlight>
====Déploiement dans le dossier Haproxy grâce au hook correspondant qui met à jour à chaud les certs====
<syntaxhighlight lang="bash">$ DEPLOY_HAPROXY_HOT_UPDATE=yes DEPLOY_HAPROXY_STATS_SOCKET=/var/run/haproxy/admin.sock DEPLOY_HAPROXY_PEM_PATH=/etc/haproxy/certs acme.sh --deploy -d port-dunkerque.pleade.com --deploy-hook haproxy</syntaxhighlight>
{{notice|Si, en tant qu'acme, on fait un crontab -l, on peut voir qu'une tâche de renouvellement de certificats tourne régulièrement.}}

# Certificats Let's Encrypt automatiques via HAProxy

## Présentation

Les certificats TLS des domaines publiés par les serveurs HAProxy AJLSM sont gérés avec **acme.sh** et Let's Encrypt.

L'installation et le renouvellement des certificats s'effectuent sur les deux serveurs :

- `haproxy-01` — `10.0.0.30`
- `haproxy-02` — `10.0.0.31`

Les certificats sont stockés dans `/etc/haproxy/certs/`.

Le hook `haproxy` d'acme.sh permet leur déploiement et leur mise à jour à chaud par le socket d'administration HAProxy.

**Important : les opérations doivent être effectuées successivement sur HAProxy-01 puis HAProxy-02, jamais en parallèle.** Chaque serveur possède sa propre installation d'acme.sh et ses propres certificats.

## 1. Prérequis

### 1.1. Configuration réseau et DNS

Le domaine doit :

- disposer d'un enregistrement DNS public pointant vers l'adresse IP publique utilisée par l'infrastructure ;
- être acheminé par OPNsense vers la VIP HAProxy `10.0.0.32` ;
- être pris en charge par la configuration HAProxy.

La configuration du NAT dépend de l'adresse publique concernée. Pour l'installation CDF du 5 novembre 2026, le routage utilise **OPNsense Destination NAT**, et non NAT One-to-One.

La validation Let's Encrypt utilise le challenge HTTP-01 en mode `stateless`, sur le port 80.

### 1.2. Configuration HAProxy avec Ansible

La configuration HAProxy est maintenue dans le projet Ansible AJLSM.

Voir : `[[WAF#Ansible]]`

Les éléments nécessaires comprennent :

- le répertoire des certificats `/etc/haproxy/certs/` ;
- la clé `ACCOUNT_THUMBPRINT` utilisée pour la validation ACME ;
- la règle HTTP permettant de répondre aux requêtes `/.well-known/acme-challenge/` ;
- les ACL du domaine et son backend.

La configuration Ansible doit être déployée et validée avant de demander le certificat.

## 2. Création d'un certificat

Exemple : `cdf-recette.pleade.com`

Toutes les commandes ci-dessous sont à effectuer sur **HAProxy-01**, puis à répéter sur **HAProxy-02**.

### 2.1. Se connecter avec l'utilisateur acme

Depuis une session administrateur :

```bash
sudo -u acme -s
```

**Important : les commandes acme.sh doivent être exécutées avec l'utilisateur `acme`, et non avec `root`.**

### 2.2. Demander le certificat Let's Encrypt

```bash
acme.sh --issue \
-d cdf-recette.pleade.com \
--stateless \
--server letsencrypt
```

Vérifier que la commande se termine par :

```text
Success
Cert success.
```

Les fichiers du certificat sont enregistrés dans :

```text
/var/lib/acme/.acme.sh/cdf-recette.pleade.com_ecc/
```

Ne pas modifier manuellement les fichiers de ce répertoire.

### 2.3. Déployer le certificat dans HAProxy

Toujours avec l'utilisateur `acme` :

```bash
DEPLOY_HAPROXY_HOT_UPDATE=yes \
DEPLOY_HAPROXY_STATS_SOCKET=/var/run/haproxy/admin.sock \
DEPLOY_HAPROXY_PEM_PATH=/etc/haproxy/certs \
acme.sh --deploy \
-d cdf-recette.pleade.com \
--deploy-hook haproxy
```

Le hook :

1. prépare le certificat au format PEM ;
2. l'installe dans `/etc/haproxy/certs/` ;
3. demande son chargement à chaud par HAProxy.

Lors de l'installation CDF du 5 novembre 2026, le déploiement a retourné :

```text
Deploying PEM file
Moving new certificate into place
Creating new certificate '/etc/haproxy/certs/cdf-recette.pleade.com.pem' over HAProxy stats socket.
Success
```

Ce résultat confirme le succès de l'opération de déploiement. Le fonctionnement HTTPS doit néanmoins être vérifié séparément.

## 3. Vérifications

### 3.1. Présence du certificat

Depuis une session administrateur :

```bash
ls -l /etc/haproxy/certs/cdf-recette.pleade.com.pem
```

###

== Configuration de HaProxy - Méthode 1 ==
On utilise ansible pour générer les fichiers de configuration dans Haproxy, les appliquer, redémarrer les Haproxy, etc.

[[WAF#Ansible|Voir la section : Ansible]]

La configuration du fichier est la même, avec la possibilité de
# variabiliser : voir section : http://mw.ajlsm.com/wiki/WAF#Variabilisation
# déployer la configuration sur les 2 Haproxy en une seule action.

Pour utiliser cette méthode, récupérer le projet '''ansible-ajlsm-haproxy''' en SVN.

La création des règles est la même que celle décrite en méthode 2.

La différence est que l'on ne travaille pas "directement" dans le fichier {{path|/etc/haproxy/haproxy.cfg}}, mais dans le fichier {{path|/ansible-ajlsm-haproxy/inventory/group_vars/ajlsm_loadbalancer/haproxy.yml}} qui est déployé en ligne de commande avec Ansible.

Cette méthode est celle utilisée en production.

== Configuration de HaProxy - Méthode 2 ==
Voir aussi projet ansible en SVN : [[WAF#Ansible]].

Modifier directement le fichier de configuration configuration {{path|/etc/haproxy/haproxy.cfg}}.

Rajouter les lignes suivantes dans la configuration {{path|/etc/haproxy/haproxy.cfg}} (dans les blocs {{path|frontend front_web}} et {{path|backend }}) :
<syntaxhighlight lang="bash">
acl host_leclientvoulu hdr(host) -i lenomdedomaineduclientvoulu.com
use_backend back_leclientvoulu if host_leclientvoulu</syntaxhighlight>
et rajouter un nouveau bloc backend comme ceci :
# Configuration avec certificat SSL :
<syntaxhighlight lang="bash">backend back_leclientvoulu
server LECLIENTVOULU ipduclientvoulu:443 check ssl verify none</syntaxhighlight>
# Configuration sans certificat :
<syntaxhighlight lang="bash">backend back_leclientvoulu
server LECLIENTVOULU ipduclientvoulu:80 check</syntaxhighlight>
Par exemple, pour archives.lamayenne.fr :
<syntaxhighlight lang="bash"> acl host_ssl_archiveslamayenne hdr(host) -i archives.lamayenne.fr
use_backend back_ssl_archiveslamayenne if host_ssl_archiveslamayenne

acl host_salledelecturearchiveslamayenne hdr(host) -i salle-de-lecture-archives.lamayenne.fr
use_backend back_salledelecturearchiveslamayenne if host_salledelecturearchiveslamayenne

...

backend back_ssl_archiveslamayenne
server ARCHIVESLAMAYENNE ad53.ajlsm.lan:443 check ssl verify none

backend back_salledelecturearchiveslamayenne
server SALLEDELECTUREARCHIVESLAMAYENNE ad53.ajlsm.lan:80 check</syntaxhighlight>

=== Traitement des blocages par IP ===
La règle apache pour le blocage des IP de chaque site : <syntaxhighlight lang="bash">RewriteCond %{REMOTE_ADDR}</syntaxhighlight> renvoie sur le Haproxy.

Le blocage d'IP ne se fait plus.

Lorsque toutes les IP doivent être bloquées sauf les accès prévus : pour le client, AJLSM, etc, (Par exemple, pour une application intranet) la '''gestion des accès par IP est à configurer dans Haproxy'''.

De plus, les [[WAF#Modification_de_la_configuration_apache_des_domaines|configurations apache]] doivent être modifiées sur chaque VM.
==== Blocage des IP dans Haproxy ====
Créez les IP allowed dans la configuration Haproxy en ajoutant, dans le {{var|frontend front_web}} et avant les autres acl, l'instruction suivante :
<syntaxhighlight lang="bash"> acl allowed_ajlsm src xx.xx.xx.xx xx.xx.xx.xx xx.xx.xx.xx/xx
acl allowed_xx_client src xx.xx.xx.xx

(Par exemple, pour les IP AJLSM et le client ad53)

acl allowed_ajlsm src 82.65.94.250 109.190.129.96 91.174.149.42 10.0.0.0/24
acl allowed_ad53_client src 85.115.60.201</syntaxhighlight>
==== Association des règles aux acl du client ====
Enfin, modifier les acl des domaines qui utilisent ces règles de blocage d'IP en ajoutant l'instruction suivante :
<syntaxhighlight lang="bash"> http-request deny if host_[le-host] !allowed_ajlsm !allowed_xx_client</syntaxhighlight>
Par exemple :
<syntaxhighlight lang="bash"> acl host_salledelecturearchiveslamayenne hdr(host) -i salle-de-lecture-archives.lamayenne.fr
use_backend back_salledelecturearchiveslamayenne if host_salledelecturearchiveslamayenne
http-request deny if host_salledelecturearchiveslamayenne !allowed_ajlsm !allowed_ad53_client</syntaxhighlight>
==== Forcer le HTTPS sur un domaine ====
On souhaite que le WAF prenne bien en compte l'acl pour un domaine avec SSL.

Ajouter la commande suivante dans l'acl concerné.
<syntaxhighlight lang="bash">http-request redirect scheme https if { hdr(Host) -i [le-domaine] } !{ ssl_fc }</syntaxhighlight>
Par exemple, pour ad53 :
<syntaxhighlight lang="bash"> acl host_ssl_archiveslamayenne hdr(host) -i archives.lamayenne.fr
use_backend back_ssl_archiveslamayenne if host_ssl_archiveslamayenne
http-request redirect scheme https if { hdr(Host) -i archives.lamayenne.fr } !{ ssl_fc }</syntaxhighlight>
Vérifier la configuration haproxy avec la commande :
<syntaxhighlight lang="bash">haproxy -f /etc/haproxy/haproxy.cfg -c -V</syntaxhighlight>

== Modification de la configuration apache des domaines ==
Dans la configuration apache de chaque site, il faut ajouter les IP privées des 2 Haproxy.
<syntaxhighlight lang="bash"> RewriteCond %{REMOTE_ADDR} !10.0.0.30
RewriteCond %{REMOTE_ADDR} !10.0.0.31</syntaxhighlight>
Puis, commenter la ligne :
<syntaxhighlight lang="bash">#RewriteRule .* /403.html [R=403,L]</syntaxhighlight>

==== Modification des logs pour le suivi des utilisateurs ====
Lorsque l'on bascule le flux vers le WAF, c'est l'IP de Haproxy qui est la seule à communiquer avec la VM.

Pour avoir des statistiques du nombre d'utilisateurs, il faut modifier les configuration apache et ajoutant les instructions suivantes (conserver la configuration hors WAF en cas de suppression du WAF) :

Activer le module Apache remoteip :
<syntaxhighlight lang="bash">a2enmod remoteip</syntaxhighlight>
Modifier la configuration Apache du site :
<syntaxhighlight lang="bash"> # Configuration des logs pour suivi par IP utilisateurs
RemoteIPHeader X-Forwarded-For
LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" forwarded

ErrorLog /var/log/apache2/archives.lamayenne.fr.errors.log
CustomLog /var/log/apache2/archives.lamayenne.fr.log forwarded
# Fin configuration des logs pour suivi par IP utilisateurs

#### Configuration log hors WAF
#ErrorLog /var/log/apache2/archives.lamayenne.fr.errors.log
#CustomLog /var/log/apache2/archives.lamayenne.fr.log combined
#### Fin configuration log hors WAF</syntaxhighlight>

== Application des règles HaProxy ==
Une fois les modifications terminées, on applique la configuration en relançant le service.
=== Redémarrer HAPROXY ===
<syntaxhighlight lang="bash">service haproxy restart</syntaxhighlight>

=== Vérifier que le HAPROXY est en vie ===
<syntaxhighlight lang="bash">service haproxy status</syntaxhighlight>

=== Logrotate Haproxy ===
Le logrotate est configuré et fait une rotation journalière (configuration dans {{path|/etc/logrotate.d/haproxy}}),
Il y a un palier maximum de 500M par fichier de log (on peut adapter).

Le log est compressé (en .1, .2.gz ...) soit lorsqu'il atteint 500M, soit au terme de la journée.
Les plus anciens logs compressés sont supprimés graduellement et automatiquement.

La conf est la suivante :
<syntaxhighlight lang="bash">/var/log/haproxy.log {
daily
rotate 15
maxsize 500M</syntaxhighlight>

== Problèmes et solutions ==
En cas d'erreur de configuration, on peut sortir un état plus détaillé du service haproxy avec la commande :
<syntaxhighlight lang="bash">$ sudo systemctl status haproxy.service -l --no-pager
● haproxy.service - HAProxy Load Balancer
Loaded: loaded (/lib/systemd/system/haproxy.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2022-05-19 10:36:36 UTC; 9s ago
Docs: man:haproxy(1)
file:/usr/share/doc/haproxy/configuration.txt.gz
Process: 88895 ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q $EXTRAOPTS (code=exited, status=0/SUCCESS)
Main PID: 88906 (haproxy)
Tasks: 5 (limit: 9327)
Memory: 9.4M
CGroup: /system.slice/haproxy.service
├─88906 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -S /run/haproxy-master.sock
└─88916 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -S /run/haproxy-master.sock

May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53goaccess started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53goaccess started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_salledelecturearchiveslamayenne started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_salledelecturearchiveslamayenne started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53internetpublicationajlsm started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53internetpublicationajlsm started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53preprodajlsm started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53preprodajlsm started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53slecturepublicationajlsm started.
May 19 10:36:36 haproxy-01 haproxy[88906]: Proxy back_ad53slecturepublicationajlsm started.</syntaxhighlight>
== Tester un domaine en passant par le reverse proxy HAPROXY ==
(sans avoir à faire une migration PROD / sans impact CLIENT).

Les tests sont lancés depuis votre poste de travail en suivant les instructions ci-dessous.

'''Exemple : Tests sur la VM Port Dunkerque'''

Rajouter cette ligne dans le fichier hosts du poste de travail d'où seront lancés les tests :
<syntaxhighlight lang="bash">51.83.117.120 port-dunkerque.pleade.com</syntaxhighlight>
{{remarque|Pour info, cette IP 51.83.117.120 pointe sur l'IP redondée du HAPROXY soit 10.0.0.32.}}
Il faut bien tester pour détecter d'éventuels faux positifs (logs : {{path|/var/log/haproxy.log}})
== Réplication de la configuration dans les 2 Haproxy ==
Une fois la configuration {{path|/etc/haproxy/haproxy.cfg}} testée et validée dans le Haproxy01, répliquez cette configuration dans Haproxy02.
== Ansible ==
=== Réplication avec ansile ===
{{important|Source V1 pour l'ansibelisation du déploiement Haproxy dans le SVN sous le nom : {{path|ansible-ajlsm/trunk/ansible-ajlsm-haproxy}}.

Après chaque modification, pensez à commiter !!!}}

{{notice|Ne pas oublier de changer les mots de passes dans inventory/ajlsm_loadbalancer.inventory (à terme il faudra utiliser des clés publiques ainsi qu'Ansible-Vault)}}
==== Installation de Ansible ====
Il faut installer Ansible au préalable ( https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#installing-ansible-on-ubuntu )
==== Paramétrage de Ansible ====
#Ajouter la variable d'environnement.
#Modifier les clés dans le fichier ansible-ajlsm-haproxy/inventory/ajlsm_loadbalancer.inventory

==== Variabilisation ====
Par exemple, les IP pour le traitement des accès par IP et blocage, on variabilise la configuration dans Haproxy en ajoutant, Dans le fichier {{path|/ansible-ajlsm-haproxy/inventory/group_vars/ajlsm_loadbalancer/haproxy.yml}} et juste avant {{var|frontend front_web}} :

<syntaxhighlight lang="bash">---
haproxy_allowed_ips_ajlsm: " xx.xx.xx.xx xx.xx.xx.xx xx.xx.xx.xx/xx"
haproxy_allowed_ips_[le-client]_client: "xx.xx.xx.xx"
haproxy_custom_configuration: |</syntaxhighlight>
Puis en ajoutant, dans le frontend front_web et avant les autres acl, l'instruction suivante :
<syntaxhighlight lang="bash"> acl allowed_ajlsm src {{ haproxy_allowed_ips_ajlsm }}
acl allowed_[le-client]_client src {{ haproxy_allowed_ips_[le-client]_client }}</syntaxhighlight>
Par exemple, pour AJLSM et ad53 :
<syntaxhighlight lang="bash">---
haproxy_allowed_ips_ajlsm: "82.65.94.250 109.190.129.96 91.174.149.42 10.0.0.0/24"
haproxy_allowed_ips_ad53_client: "85.115.60.201"
haproxy_custom_configuration: |

...

acl allowed_ajlsm src {{ haproxy_allowed_ips_ajlsm }}
acl allowed_ad53_client src {{ haproxy_allowed_ips_ad53_client }}</syntaxhighlight>
==== Réplication ====
#Il faut être sous VPN.
#Dans {{path|/etc/host}}, ajouter les 2 hosts : 10.0.0.30 haproxy01.ajlsm.lan, et : 10.0.0.31 haproxy02.ajlsm.lan
#Après avoir testé la configuration dans Haproxy01, créer le fichier Haproxy.yml (copie du fichier Haproxy01 en retirant les sections "global" et "default") et ajoutant les variables, si nécessaire.
#Le fichier Haproxy.yml doit être placé dans le répertoire {{path|/ansible-ajlsm-haproxy/inventory/group_vars/ajlsm_loadbalancer/haproxy.yml}}
#Lancer la commande depuis la racine du dossier décompressé (il faut avoir ansible.cfg en visu lorqu'on fait un ls).
<syntaxhighlight lang="bash">ansible-playbook ./plays/deploy.haproxy.yml -l ajlsm_loadbalancer</syntaxhighlight>
{{notice|Il faut un environnement python. Penser à lancer <syntaxhighlight lang="bash">source .venv/bin/activate</syntaxhighlight> si vous travaillez dans un environnement spécifique}}
<syntaxhighlight lang="bash">source .venv/bin/activate && ansible-playbook ./plays/deploy.haproxy.yml -l ajlsm_loadbalancer</syntaxhighlight>
Si tout va bien :
<syntaxhighlight lang="bash">ansible-ajlsm-haproxy ~$ ansible-playbook ./plays/deploy.haproxy.yml -l ajlsm_loadbalancer

PLAY [ajlsm_loadbalancer] ****************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] *******************************************************************************************************************************************************************************************************************
ok: [haproxy01.ajlsm.lan]
ok: [haproxy02.ajlsm.lan]

TASK [haproxy : Install packages] ********************************************************************************************************************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [haproxy : Deploy configuration and validate it] ************************************************************************************************************************************************************************************
changed: [haproxy02.ajlsm.lan]
changed: [haproxy01.ajlsm.lan]

TASK [haproxy : Restore configuration (validation failed)] *******************************************************************************************************************************************************************************
skipping: [haproxy01.ajlsm.lan]
skipping: [haproxy02.ajlsm.lan]

TASK [haproxy : Remove restored backup file] *********************************************************************************************************************************************************************************************
skipping: [haproxy01.ajlsm.lan]
skipping: [haproxy02.ajlsm.lan]

TASK [haproxy : Start service and enable it on boot] *************************************************************************************************************************************************************************************
ok: [haproxy01.ajlsm.lan]
ok: [haproxy02.ajlsm.lan]

TASK [haproxy : Failure] *****************************************************************************************************************************************************************************************************************
skipping: [haproxy01.ajlsm.lan]
skipping: [haproxy02.ajlsm.lan]

RUNNING HANDLER [haproxy : restart haproxy] **********************************************************************************************************************************************************************************************
changed: [haproxy02.ajlsm.lan]
changed: [haproxy01.ajlsm.lan]

PLAY RECAP *******************************************************************************************************************************************************************************************************************************
haproxy01.ajlsm.lan : ok=5 changed=2 unreachable=0 failed=0 skipped=3 rescued=0 ignored=0
haproxy02.ajlsm.lan : ok=5 changed=2 unreachable=0 failed=0 skipped=3 rescued=0 ignored=0 </syntaxhighlight>

==== En cas d'erreur après le lancement de la commande ====
===== Essayer la commande =====
<syntaxhighlight lang="bash">ANSIBLE_CONFIG=ansible.cfg ansible-playbook ./plays/deploy.haproxy.yml -l ajlsm_loadbalancer</syntaxhighlight>

Cette partie est à compléter selon l'évolution du script de déploiement.
===== 1 - Si la commande renvoie : =====
<syntaxhighlight lang="bash">-bash: ansible-playbook: command not found</syntaxhighlight>
Voir tuto : https://stackoverflow.com/questions/63177609/zsh-command-not-found-ansible-after-pip-installing
===== 2 - Si la commande renvoie : =====
<syntaxhighlight lang="bash">ansible-playbook ./plays/deploy.haproxy.yml -l ajlsm_loadbalancer

PLAY [ajlsm_loadbalancer] *****************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ********************************************************************************************************************************************************************************************************************************
fatal: [haproxy01.ajlsm.lan]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: Could not resolve hostname haproxy01.ajlsm.lan: nodename nor servname provided, or not known", "unreachable": true}
fatal: [haproxy02.ajlsm.lan]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: Could not resolve hostname haproxy02.ajlsm.lan: nodename nor servname provided, or not known", "unreachable": true}

PLAY RECAP ********************************************************************************************************************************************************************************************************************************************
haproxy01.ajlsm.lan : ok=0 changed=0 unreachable=1 failed=0 skipped=0 rescued=0 ignored=0
haproxy02.ajlsm.lan : ok=0 changed=0 unreachable=1 failed=0 skipped=0 rescued=0 ignored=0</syntaxhighlight>
Dans {{path|/etc/host}}, ajouter les 2 hosts :
#10.0.0.30 haproxy01.ajlsm.lan
#10.0.0.31 haproxy02.ajlsm.lan

==== Reste à faire ====
Fine-tuning pour une maintenance simplifiée + le vault&clé publique pour la sécurité des mots de passes
# Il faudrait vaulter des choses,
# améliorer le playbook & le rôle
# ainsi que variabiliser plus de choses;

== Migrer un site vers HAPROXY (mise en production) ==
(après avoir testé)

* Soit changer le DNS vers 51.83.117.120 (le client doit faire pointer son DNS sur cette IP)
* Soit aller dans les NAT One-to-One (1:1) d'OPNSENSE, et changer l'IP du client vers 10.0.0.32 (sur la correspondance IP externe client <-> IP interne client de la page)
Lors d'une mise en production, pour éviter faire changer aux clients le DNS tout de suite et pour garder un débrayage facile : depuis le pare-feu OPNSense -> firewall -> NAT -> one-to-one, on fait pointer l'IP initiale de la VM vers 10.0.0.32.

Dans l'exemple pour PORT DUNKERQUE, ça voudrait dire faire pointer 46.105.188.170 sur 10.0.0.32 au lieu de 10.0.0.24.

Voir la copie d'écran de OPNSense : [[media:Nat.png]]

== Arrêter le WAF ==
En cas de problème avec une VM client (un blocage, ralentissement, faux positifs, etc.)
* Modifier les configuration apache en décommentant <syntaxhighlight lang="bash">#RewriteRule .* /403.html [R,L]</syntaxhighlight>
et en remettant les règles pour les logs (commenter la section et décommenter l'autre) :
<syntaxhighlight lang="bash"> # Configuration des logs pour suivi par IP utilisateurs
#RemoteIPHeader X-Forwarded-For
#LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" forwarded

#ErrorLog /var/log/apache2/chercher-archives.lamayenne.fr.errors.log
#CustomLog /var/log/apache2/chercher-archives.lamayenne.fr.log forwarded
# Fin configuration des logs pour suivi par IP utilisateurs

#### Configuration log hors WAF
ErrorLog /var/log/apache2/archives.lamayenne.fr.errors.log
CustomLog /var/log/apache2/archives.lamayenne.fr.log combined
#### Fin configuration log hors WAF </syntaxhighlight>
* Remettre l'IP interne du client (et pas celle du HAPROXY) dans le NAT 1:1 d'OPNSENSE.
* Ou bien, éteindre les deux machines VM modsec-spoe (Proxmox Saturne) pour désactiver le WAF de force.
== Faux positifs ==
On parle de "faux positif " lorsque un paquet anodin (ne constituant aucune menace réelle) est détecté comme tentative d'intrusion.

On parle de "faux négatif" lorsqu'une tentative d'intrusion n'est pas détectée.

{{important|En attente de la nouvelle documentation de Coraza}}

= Gestion d'un faux positif Coraza (OWASP CRS) sur Archives de la Mayenne =

== Contexte ==

L'application Archives de la Mayenne (Drupal + Pleade/Lucene) générait une erreur HTTP 403 sur certaines recherches contenant :

<syntaxhighlight lang="text">
Saint-Vénérand (Laval)
</syntaxhighlight>

Le WAF Coraza détectait à tort une tentative d'injection SQL car la chaîne :

<syntaxhighlight lang="text">
Vénérand (
</syntaxhighlight>

contient le motif :

<syntaxhighlight lang="text">
rand (
</syntaxhighlight>

qui correspond à une signature SQL de la règle OWASP CRS 942151.

== Identification du faux positif ==

Recherche dans les logs Coraza :

<syntaxhighlight lang="bash">
tail -f /var/log/coraza-spoa/coraza-agent.log
</syntaxhighlight>

Extrait du log :

<syntaxhighlight lang="bash">
{
"rule_id":942151,
"msg":"SQL Injection Attack: SQL function name detected",
"data":"Matched Data: rand ( found within ARGS:fquery1: Saint-Vénérand (Laval)"
}
</syntaxhighlight>

La règle responsable est :

<syntaxhighlight lang="text">
942151 - SQL Injection Attack: SQL function name detected
</syntaxhighlight>

== Localisation de la configuration Coraza ==

Service :

<syntaxhighlight lang="bash">
systemctl status coraza-spoa
</syntaxhighlight>

Configuration principale :

<syntaxhighlight lang="text">
/etc/coraza-spoa/config.yaml
</syntaxhighlight>

Extrait :

<syntaxhighlight lang="yaml">
Include /etc/coraza-spoa/custom-rules/*.conf
</syntaxhighlight>

Le fichier de règles est généré automatiquement par Ansible :

<syntaxhighlight lang="text">
/etc/coraza-spoa/custom-rules/900-runtime-overrides.conf
</syntaxhighlight>

== Localisation de la source Ansible ==

Recherche de la variable :

<syntaxhighlight lang="bash">
grep -R "coraza_spoa_custom_rules_request_body_exclusions" -n .
</syntaxhighlight>

Résultat :

<syntaxhighlight lang="text">
roles/coraza/templates/custom-rules.conf.j2
inventory/group_vars/ajlsm_loadbalancer/coraza.yml
</syntaxhighlight>

Template générateur :

<syntaxhighlight lang="text">
roles/coraza/templates/custom-rules.conf.j2
</syntaxhighlight>

Variables du groupe load balancer :

<syntaxhighlight lang="text">
inventory/group_vars/ajlsm_loadbalancer/coraza.yml
</syntaxhighlight>

== Vérification de la prise en compte de la variable ==

Contrôle de la variable vue par Ansible :

<syntaxhighlight lang="bash">
ansible -i inventory haproxy01.ajlsm.lan \
-m debug \
-a 'var=coraza_spoa_custom_rules_request_body_exclusions'
</syntaxhighlight>

La nouvelle règle doit apparaître dans la sortie.

== Ajout de l'exception ==

Modification du fichier :

<syntaxhighlight lang="text">
inventory/group_vars/ajlsm_loadbalancer/coraza.yml
</syntaxhighlight>

Ajout dans la section :

<syntaxhighlight lang="yaml">
coraza_spoa_custom_rules_request_body_exclusions:
</syntaxhighlight>

Règle finale retenue :

<syntaxhighlight lang="yaml">
- id: 123471
variable: "REQUEST_FILENAME"
operator: "@rx"
pattern: "^/(archives-en-ligne|pleade)/.*results(\\.html|\\.ajax-html)$"
actions: "nolog,pass,ctl:ruleRemoveTargetById=942151;ARGS:/^(?:query[0-9]+|fquery[0-9]+)$/"
</syntaxhighlight>

Cette règle :

* s'applique aux pages de résultats Pleade ;
* couvre les pages HTML classiques et les appels AJAX ;
* retire la règle CRS 942151 ;
* uniquement pour le paramètre ARGS:fquery1 ;
* conserve toutes les autres protections CRS.

Exemples d'URLs couvertes :

<syntaxhighlight lang="text">
/archives-en-ligne/custom-results.html
/archives-en-ligne/results.html
/archives-en-ligne/functions/ead/custom-results.ajax-html
/pleade/custom-results.html
/pleade/functions/ead/custom-results.ajax-html
</syntaxhighlight>

Ainsi que les motifs suivants :

<syntaxhighlight lang="text">
ARGS:query1
ARGS:query2
ARGS:query3
ARGS:fquery1
ARGS:fquery2
</syntaxhighlight>

== Vérification du rendu du template ==

Simulation du déploiement :

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

Le diff doit montrer :

<syntaxhighlight lang="apache">
SecRule REQUEST_FILENAME "@rx ^/(archives-en-ligne|pleade)/.*results(\.html|\.ajax-html)$" \
"id:123471,phase:1,nolog,pass,ctl:ruleRemoveTargetById=942151;ARGS:/^(?:query[0-9]+|fquery[0-9]+)$/"
</syntaxhighlight>

== Déploiement ==

Attention : le rôle Coraza est indépendant du rôle HAProxy.

Le playbook HAProxy :

<syntaxhighlight lang="text">
plays/deploy.haproxy.yml
</syntaxhighlight>

ne déploie pas les règles Coraza.

Le playbook Coraza est :

<syntaxhighlight lang="text">
plays/deploy.coraza.yml
</syntaxhighlight>

Déploiement sur tous les load balancers :

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

Déploiement uniquement sur haproxy01 :

<syntaxhighlight lang="bash">
ansible-playbook \
-i inventory \
./plays/deploy.coraza.yml \
--limit haproxy01.ajlsm.lan \
--diff
</syntaxhighlight>

Déploiement uniquement sur haproxy02 :

<syntaxhighlight lang="bash">
ansible-playbook \
-i inventory \
./plays/deploy.coraza.yml \
--limit haproxy02.ajlsm.lan \
--diff
</syntaxhighlight>

== Vérifications après déploiement ==

Contrôle de la présence de la règle :

<syntaxhighlight lang="bash">
grep -R "123471\|942151" /etc/coraza-spoa/custom-rules -n
</syntaxhighlight>

Résultat attendu :

<syntaxhighlight lang="text">
/etc/coraza-spoa/custom-rules/900-runtime-overrides.conf:
SecRule REQUEST_FILENAME "@rx ^/(archives-en-ligne|pleade)/.*results(\.html|\.ajax-html)$" \
"id:123471,...ctl:ruleRemoveTargetById=942151;ARGS:fquery1"
</syntaxhighlight>

Contrôle du service :

<syntaxhighlight lang="bash">
systemctl status coraza-spoa
</syntaxhighlight>

Vérification via Ansible :

<syntaxhighlight lang="bash">
ansible -i inventory ajlsm_loadbalancer \
-m shell \
-a 'grep -R "123471\|942151" /etc/coraza-spoa/custom-rules -n && systemctl is-active coraza-spoa'
</syntaxhighlight>

== Validation fonctionnelle ==

Tester la recherche :

<syntaxhighlight lang="text">
Saint-Vénérand (Laval)
</syntaxhighlight>

L'URL principale ne doit plus renvoyer de 403 :

<syntaxhighlight lang="text">
/archives-en-ligne/custom-results.html
</syntaxhighlight>

Les appels AJAX associés ne doivent plus être bloqués :

<syntaxhighlight lang="text">
/archives-en-ligne/functions/ead/custom-results.ajax-html
</syntaxhighlight>

Les logs Coraza ne doivent plus contenir de déclenchement de la règle 942151 pour le paramètre :

<syntaxhighlight lang="text">
ARGS:fquery1
</syntaxhighlight>

== Points importants ==

* Les règles Coraza sont gérées par Ansible.
* Toute modification manuelle dans /etc/coraza-spoa/custom-rules/ sera écrasée lors d'un prochain déploiement.
* La source de vérité est :

<syntaxhighlight lang="text">
inventory/group_vars/ajlsm_loadbalancer/coraza.yml
</syntaxhighlight>

* Les déploiements de configuration HAProxy et Coraza sont indépendants.
* Une modification des règles Coraza nécessite l'exécution du playbook :

<syntaxhighlight lang="text">
plays/deploy.coraza.yml
</syntaxhighlight>

Sur le poste local, dans le répertoire ansible-ajlsm, lancez :
<syntaxhighlight lang="bash">
ansible-playbook -i inventory ./plays/deploy.coraza.yml --limit ajlsm_loadbalancer --diff
</syntaxhighlight>
<syntaxhighlight lang="yaml">
ansible-playbook -i inventory ./plays/deploy.coraza.yml --limit ajlsm_loadbalancer --diff

PLAY [Deploy Coraza SPOA WAF] ***************************************************************************************************************************

TASK [Gathering Facts] **********************************************************************************************************************************
[WARNING]: Host 'haproxy02.ajlsm.lan' is using the discovered Python interpreter at '/usr/bin/python3.10', but future installation of another Python interpreter could cause a different interpreter to be discovered. See https://docs.ansible.com/ansible-core/2.20/reference_appendices/interpreter_discovery.html for more information.
ok: [haproxy02.ajlsm.lan]
[WARNING]: Host 'haproxy01.ajlsm.lan' is using the discovered Python interpreter at '/usr/bin/python3.10', but future installation of another Python interpreter could cause a different interpreter to be discovered. See https://docs.ansible.com/ansible-core/2.20/reference_appendices/interpreter_discovery.html for more information.
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Install build dependencies] **************************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Install Go via snap] *********************************************************************************************************************
ok: [haproxy01.ajlsm.lan]
ok: [haproxy02.ajlsm.lan]

TASK [coraza : Create build directory] ******************************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Clone coraza-spoa repository] ************************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Check if coraza-spoa binary already exists] **********************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Build coraza-spoa] ***********************************************************************************************************************
skipping: [haproxy01.ajlsm.lan]
skipping: [haproxy02.ajlsm.lan]

TASK [coraza : Install coraza-spoa binary] **************************************************************************************************************
skipping: [haproxy01.ajlsm.lan]
skipping: [haproxy02.ajlsm.lan]

TASK [coraza : Create coraza-spoa group] ****************************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Create coraza-spoa user] *****************************************************************************************************************
ok: [haproxy01.ajlsm.lan]
ok: [haproxy02.ajlsm.lan]

TASK [coraza : Create configuration directory] **********************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Create log directories] ******************************************************************************************************************
ok: [haproxy01.ajlsm.lan] => (item=/var/log/coraza-spoa)
ok: [haproxy02.ajlsm.lan] => (item=/var/log/coraza-spoa)
ok: [haproxy02.ajlsm.lan] => (item=/var/log/coraza-spoa/audit)
ok: [haproxy01.ajlsm.lan] => (item=/var/log/coraza-spoa/audit)

TASK [coraza : Create log files] ************************************************************************************************************************
ok: [haproxy02.ajlsm.lan] => (item=server.log)
ok: [haproxy01.ajlsm.lan] => (item=server.log)
ok: [haproxy01.ajlsm.lan] => (item=error.log)
ok: [haproxy02.ajlsm.lan] => (item=error.log)
ok: [haproxy01.ajlsm.lan] => (item=audit.log)
ok: [haproxy02.ajlsm.lan] => (item=audit.log)
ok: [haproxy01.ajlsm.lan] => (item=debug.log)
ok: [haproxy02.ajlsm.lan] => (item=debug.log)
ok: [haproxy01.ajlsm.lan] => (item=coraza-agent.log)
ok: [haproxy02.ajlsm.lan] => (item=coraza-agent.log)

TASK [coraza : Create rollback backup directory] ********************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Deploy coraza.cfg for HAProxy] ***********************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Check if current coraza-spoa config exists] **********************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Check if current custom rules file exists] ***********************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Backup current coraza-spoa config] *******************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Backup current custom rules file] ********************************************************************************************************
changed: [haproxy01.ajlsm.lan]
changed: [haproxy02.ajlsm.lan]

TASK [coraza : Deploy coraza-spoa config.yaml] **********************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Create custom rules directory] ***********************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Deploy custom rules] *********************************************************************************************************************
--- before: /etc/coraza-spoa/custom-rules/900-runtime-overrides.conf
+++ after: /Users/jlarvers/.ansible/tmp/ansible-local-20994a3e3jiy7/tmp2vqgd1ck/custom-rules.conf.j2
@@ -47,7 +47,7 @@
SecRule REQUEST_FILENAME "@rx /full_html?" \
"id:123470,phase:1,nolog,pass,ctl:requestBodyAccess=Off"
SecRule REQUEST_FILENAME "@rx ^/(archives-en-ligne|pleade)/.*results(\.html|\.ajax-html)$" \
- "id:123471,phase:1,nolog,pass,ctl:ruleRemoveTargetById=942151;ARGS:fquery1"
+ "id:123471,phase:1,nolog,pass,ctl:ruleRemoveTargetById=942151;ARGS:/^(?:query[0-9]+|fquery[0-9]+)$/"

SecRequestBodyLimit 524288000
SecRequestBodyNoFilesLimit 524288000

changed: [haproxy02.ajlsm.lan]
--- before: /etc/coraza-spoa/custom-rules/900-runtime-overrides.conf
+++ after: /Users/jlarvers/.ansible/tmp/ansible-local-20994a3e3jiy7/tmpd0a58h10/custom-rules.conf.j2
@@ -47,7 +47,7 @@
SecRule REQUEST_FILENAME "@rx /full_html?" \
"id:123470,phase:1,nolog,pass,ctl:requestBodyAccess=Off"
SecRule REQUEST_FILENAME "@rx ^/(archives-en-ligne|pleade)/.*results(\.html|\.ajax-html)$" \
- "id:123471,phase:1,nolog,pass,ctl:ruleRemoveTargetById=942151;ARGS:fquery1"
+ "id:123471,phase:1,nolog,pass,ctl:ruleRemoveTargetById=942151;ARGS:/^(?:query[0-9]+|fquery[0-9]+)$/"

SecRequestBodyLimit 524288000
SecRequestBodyNoFilesLimit 524288000

changed: [haproxy01.ajlsm.lan]

TASK [coraza : Remove legacy split custom rules files] **************************************************************************************************
ok: [haproxy01.ajlsm.lan] => (item=900-legacy-overrides.conf)
ok: [haproxy02.ajlsm.lan] => (item=900-legacy-overrides.conf)
ok: [haproxy01.ajlsm.lan] => (item=900-exclusions.conf)
ok: [haproxy02.ajlsm.lan] => (item=900-exclusions.conf)
ok: [haproxy01.ajlsm.lan] => (item=910-crs-policy.conf)
ok: [haproxy02.ajlsm.lan] => (item=910-crs-policy.conf)
ok: [haproxy01.ajlsm.lan] => (item=920-body-limits.conf)
ok: [haproxy02.ajlsm.lan] => (item=920-body-limits.conf)

TASK [coraza : Validate coraza-spoa config and custom rules before restart] *****************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Deploy coraza-spoa systemd unit] *********************************************************************************************************
ok: [haproxy02.ajlsm.lan]
ok: [haproxy01.ajlsm.lan]

TASK [coraza : Enable and start coraza-spoa service] ****************************************************************************************************
ok: [haproxy01.ajlsm.lan]
ok: [haproxy02.ajlsm.lan]

RUNNING HANDLER [coraza : Restart coraza-spoa] **********************************************************************************************************
changed: [haproxy01.ajlsm.lan]
changed: [haproxy02.ajlsm.lan]

PLAY RECAP **********************************************************************************************************************************************
haproxy01.ajlsm.lan : ok=25 changed=3 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
haproxy02.ajlsm.lan : ok=25 changed=3 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
</syntaxhighlight>
Les paramètres suivants puvent être utilisés avec ansible :
{| class="wikitable"
! Option
! Description
! Modifie le serveur
! Affiche les différences
! Usage typique
|-
| aucune option
| Exécution normale du playbook
| Oui
| Non
| Déploiement standard
|-
| --check
| Simulation (dry-run)
| Non
| Non
| Vérifier ce qui serait modifié
|-
| --diff
| Exécution réelle avec affichage des différences
| Oui
| Oui
| Déployer en visualisant les changements
|-
| --check --diff
| Simulation avec affichage des différences
| Non
| Oui
| Vérifier précisément les modifications avant déploiement
|-
| --limit <hôte>
| Limite l'exécution à un ou plusieurs hôtes
| Selon les autres options
| Selon les autres options
| Tester sur un seul serveur
|-
| --tags <tag>
| Exécute uniquement les tâches portant un tag donné
| Selon les autres options
| Selon les autres options
| Déployer uniquement un composant spécifique
|-
| --skip-tags <tag>
| Ignore les tâches portant un tag donné
| Selon les autres options
| Selon les autres options
| Exclure une partie du playbook
|-
| -v
| Mode verbeux
| Selon les autres options
| Selon les autres options
| Voir davantage d'informations
|-
| -vv
| Mode très verbeux
| Selon les autres options
| Selon les autres options
| Débogage
|-
| -vvv
| Mode débogage avancé
| Selon les autres options
| Selon les autres options
| Analyse détaillée des connexions et modules
|}

= Coraza =

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

2026-10-22T15:11:52Z

Jlarvers : /* 1.1. Tableau de suivi */

= 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.

=== 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.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.

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

2026-10-22T15:09:59Z

Jlarvers : 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... »

= 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

2026-10-20T11:06:50Z

Jlarvers : /* Exemple de tâche cron */

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

=== 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="bash">
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/Maintenance

2026-10-20T11:04:54Z

Jlarvers : /* Objectif */

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

=== 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/Maintenance

2026-10-20T11:04:34Z

Jlarvers : 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... »

= 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

2026-10-20T10:56:09Z

Jlarvers : /* 1. Environnement technique */

= Installation de Matomo sur une VM Ubuntu =

== Objectif ==

Cette procédure décrit l'installation de Matomo sur les VM AJLSM hébergeant les applications Pleade et Drupal.

Elle est destinée à être réutilisée pour les nouveaux projets, indépendamment du client et du nom de domaine.

La configuration Apache, l'intégration Drupal et la publication sécurisée par HAProxy sont détaillées dans des chapitres distincts :

* [[Matomo/Apache]]
* [[Matomo/Drupal]]
* [[Matomo/HAProxy]]
* [[Matomo/Maintenance]]

== 1. Environnement technique ==

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"
! Ubuntu
! Version PHP de référence
! Observations
|-
| Ubuntu 18.04
| PHP 8.1
| Installation historique avec version PHP ajoutée séparément
|-
| Ubuntu 24.04
| PHP 8.3
| Version fournie par Ubuntu
|-
| Ubuntu 26.04
| PHP 8.4
| Version utilisée sur AD64 en octobre 2026
|}

Vérifier systématiquement la compatibilité entre PHP et la version de Matomo installée.

=== Composants nécessaires ===

* Apache 2.4
* PHP avec '''mod_php''' ou '''PHP-FPM'''
* MariaDB ou MySQL
* Extensions PHP requises par Matomo
* Accès HTTPS, directement ou via HAProxy
* Accès réseau permettant le téléchargement et les mises à jour de Matomo

== 2. Installation des dépendances PHP ==

Adapter la version de PHP à celle installée sur la VM.

=== Ubuntu 24.04 — PHP 8.3 ===

<syntaxhighlight lang="bash">
sudo apt install \
php8.3-mysql php8.3-gd php8.3-curl php8.3-xml \
php8.3-mbstring php8.3-zip php8.3-intl
</syntaxhighlight>

=== Ubuntu 26.04 — PHP 8.4 ===

<syntaxhighlight lang="bash">
sudo apt install \
php8.4-mysql php8.4-gd php8.4-curl php8.4-xml \
php8.4-mbstring php8.4-zip php8.4-intl
</syntaxhighlight>

=== Vérification ===

<syntaxhighlight lang="bash">
php -v
php -m | grep -Ei 'mysqli|pdo_mysql|gd|curl|mbstring|xml|zip|intl'
</syntaxhighlight>

== 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.

=== 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">
sudo apt install php8.4-fpm

sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.4-fpm

sudo apache2ctl configtest
sudo systemctl reload apache2
</syntaxhighlight>

Vérifier ensuite :

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

'''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 ==

Vérifier que MariaDB est installé et actif :

<syntaxhighlight lang="bash">
systemctl status mariadb
</syntaxhighlight>

Matomo nécessite :

* Une base de données dédiée
* Un utilisateur SQL dédié
* Des droits limités à cette base

Exemple générique à adapter :

<syntaxhighlight lang="sql">
CREATE DATABASE matomo
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

CREATE USER 'matomo'@'localhost'
IDENTIFIED BY 'MOT_DE_PASSE_FORT_A_REMPLACER';

GRANT ALL PRIVILEGES ON matomo.*
TO 'matomo'@'localhost';
</syntaxhighlight>

Ne jamais conserver le mot de passe d'exemple dans une installation réelle.

== 5. Permissions et sécurisation des fichiers Matomo ==

=== Principes ===

L'installation Matomo est située dans :

<syntaxhighlight lang="text">
/var/www/matomo
</syntaxhighlight>

Sur les VM AJLSM, lorsque PHP-FPM s'exécute sous l'utilisateur `www-data`, les fichiers de Matomo appartiennent normalement à `www-data:www-data`.

Les permissions de référence sont :

{| class="wikitable"
! Élément
! Permissions
! Observations
|-
| Répertoires de l'application
| 755
| Lecture et traversée autorisées ; écriture réservée au propriétaire
|-
| Fichiers de l'application
| 644
| Lecture autorisée ; écriture réservée au propriétaire
|-
| config/config.ini.php
| 600
| Fichier sensible contenant notamment les paramètres de connexion à MariaDB
|-
| Répertoires temporaires et de configuration
| 755
| Accessibles en écriture au compte PHP-FPM lorsqu'il en est propriétaire
|-
| .well-known/acme-challenge
| 755
| Peut appartenir à root:root ; ne pas modifier sans vérifier la configuration ACME
|}

'''Important :''' les permissions 755 et 644 ne rendent pas les fichiers accessibles en écriture à tous. Elles permettent uniquement au propriétaire de les modifier.

=== Configuration initiale ===

Pour une nouvelle installation dont l'ensemble des fichiers applicatifs doit appartenir à `www-data` :

<syntaxhighlight lang="bash">
sudo chown -R www-data:www-data /var/www/matomo

sudo find /var/www/matomo -type d -exec chmod 755 {} \;
sudo find /var/www/matomo -type f -exec chmod 644 {} \;

sudo chmod 600 /var/www/matomo/config/config.ini.php
</syntaxhighlight>

'''Attention :''' ces commandes concernent une installation initiale, avant la création éventuelle de répertoires spécifiques par d'autres services. Ne pas les réexécuter aveuglément sur une installation existante.

Vérifier préalablement le compte utilisé par PHP-FPM. Si celui-ci est différent de `www-data`, adapter les propriétaires et permissions.

=== Vérification des permissions ===

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

Vérifier la répartition des propriétaires :

<syntaxhighlight lang="bash">
sudo find /var/www/matomo -xdev -printf '%u:%g\n' \
| sort | uniq -c | sort -nr
</syntaxhighlight>

Identifier les fichiers ou répertoires accessibles en écriture à tous :

<syntaxhighlight lang="bash">
sudo find /var/www/matomo -xdev -perm -0002 \
-printf '%m %u:%g %p\n'
</syntaxhighlight>

Cette dernière commande ne doit normalement rien retourner.

=== Vérification des répertoires accessibles en écriture ===

<syntaxhighlight lang="bash">
for DIR in config tmp plugins; do
if sudo -u www-data test -w "/var/www/matomo/$DIR"; then
echo "$DIR : écriture OK"
else
echo "$DIR : écriture NON autorisée"
fi
done
</syntaxhighlight>

Adapter `www-data` si Matomo utilise un autre compte PHP-FPM.

=== Cas particulier des répertoires ACME ===

Certains répertoires peuvent être créés et administrés par le mécanisme de validation des certificats Let's Encrypt :

<syntaxhighlight lang="text">
/var/www/matomo/.well-known
/var/www/matomo/.well-known/acme-challenge
</syntaxhighlight>

Ils peuvent légitimement appartenir à `root:root` avec des permissions `755`.

Ne pas modifier systématiquement leur propriétaire : vérifier au préalable le mécanisme de validation ACME utilisé sur la VM.

=== Vérification après modification ===

Après toute modification des permissions :

* Vérifier que l'interface Matomo reste accessible.
* Vérifier que la connexion à MariaDB fonctionne.
* Vérifier qu'aucune erreur de permission n'apparaît dans les journaux Apache/PHP-FPM.
* Vérifier que les statistiques continuent à être collectées.

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

L'audit de `/var/www/matomo` sur AD64 a donné les résultats suivants :

* 13 315 éléments appartenant à `www-data:www-data`.
* 2 répertoires appartenant à `root:root` : `.well-known` et `.well-known/acme-challenge`.
* Répertoires `config`, `tmp` et `plugins` accessibles en écriture à `www-data`.
* Aucun fichier ou répertoire accessible en écriture à tous.
* Fichier `config/config.ini.php` initialement en `644` : passage recommandé en `600`.
* Interface Matomo vérifiée fonctionnelle.

Aucune autre modification des propriétaires ou des permissions n'était nécessaire.

'''Conclusion :''' pour les nouvelles installations, appliquer des permissions adaptées dès le départ et réserver l'accès aux fichiers sensibles. Sur les installations existantes, effectuer un audit avant toute modification globale.

== 6. Configuration Apache et HTTPS ==

La configuration du VirtualHost Matomo est décrite dans :

[[Matomo/Apache]]

Deux architectures sont possibles :

* Apache assure directement la terminaison HTTPS.
* HAProxy assure la terminaison HTTPS et transmet les requêtes à Apache.

Dans l'infrastructure AJLSM utilisant HAProxy, le certificat public est généralement géré sur les répartiteurs de charge.

La procédure de configuration des certificats et des ACL est décrite dans :

[[Matomo/HAProxy]]

Pour une installation utilisant directement Certbot sur Apache :

<syntaxhighlight lang="bash">
sudo apt install certbot python3-certbot-apache
sudo certbot --apache
</syntaxhighlight>

Cette procédure Certbot ne doit pas être appliquée automatiquement à une VM dont le HTTPS public est déjà géré par HAProxy.

== 7. Initialisation de Matomo ==

Après configuration du VirtualHost, ouvrir dans un navigateur l'URL HTTPS prévue pour Matomo.

L'assistant d'installation permet notamment de :

# Vérifier les prérequis système
# Configurer la connexion à MariaDB
# Initialiser les tables Matomo
# Créer le compte administrateur
# Déclarer le premier site suivi

'''Important :''' chaque application suivie doit disposer de son propre identifiant de site Matomo lorsque l'on souhaite séparer ses statistiques.

Exemple : une application Internet et une salle de lecture Drupal peuvent être déclarées comme deux sites distincts.

== 8. Vérifications après installation ==

=== Vérifier la version installée ===

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

=== Vérifier les services ===

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

Adapter la version PHP-FPM si nécessaire.

=== Vérifier les points d'accès ===

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

curl -I "$MATOMO_URL/matomo.js"
curl -I "$MATOMO_URL/matomo.php"
</syntaxhighlight>

'''Note :''' selon le comportement du serveur, une requête HEAD peut ne pas produire le même résultat qu'une requête GET. Pour vérifier précisément les codes HTTP :

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

L'installation de Matomo ne garantit pas à elle seule que les applications transmettent leurs visites. Cette vérification relève des chapitres d'intégration.

== 9. Intégration aux applications ==

=== Drupal ===

Voir [[Matomo/Drupal]] pour :

* L'installation du module Drupal Matomo
* La configuration de l'identifiant du site
* L'adresse HTTPS du serveur Matomo
* Les exclusions des pages d'administration
* Les vérifications de collecte

=== Pleade ===

Voir [[Matomo/Pleade]].

=== Suivi IIIF et événements ===

* [[Matomo/IIIF]]
* [[Matomo/Evenements]]

== 10. Sécurité et maintenance ==

Après installation, vérifier :

* Que l'interface d'administration Matomo n'est accessible qu'aux utilisateurs ou réseaux autorisés
* Que les points de collecte nécessaires restent accessibles aux visiteurs
* Que le certificat HTTPS est valide
* Que les sauvegardes couvrent la base MariaDB et la configuration Matomo
* Que les mises à jour de sécurité sont suivies

Voir :

* [[Matomo/HAProxy]]
* [[Matomo/Maintenance]]
* [[Matomo/Debug]]

== 11. Installations de référence ==

{| class="wikitable"
! Projet
! Serveur
! Domaine Matomo
! Particularités
|-
| AD64
| ad64
| ad64-matomo.pleade.com
| Matomo 5.10.1 ; deux Drupal suivis séparément
|-
| APBP2
| À compléter
| apbp2-matomo.pleade.com
| Publication via HAProxy avec restriction de l'administration
|-
| MERCURE3
| À compléter
| mercure3-matomo.pleade.com
| Accès restreint à AJLSM
|}

Les paramètres propres à chaque client (domaines, adresses IP, identifiants Matomo, backends HAProxy) ne doivent pas être intégrés directement dans les commandes génériques.

Matomo/Installation

2026-10-20T10:55:15Z

Jlarvers : /* 3. Activation de PHP-FPM */

= Installation de Matomo sur une VM Ubuntu =

== Objectif ==

Cette procédure décrit l'installation de Matomo sur les VM AJLSM hébergeant les applications Pleade et Drupal.

Elle est destinée à être réutilisée pour les nouveaux projets, indépendamment du client et du nom de domaine.

La configuration Apache, l'intégration Drupal et la publication sécurisée par HAProxy sont détaillées dans des chapitres distincts :

* [[Matomo/Apache]]
* [[Matomo/Drupal]]
* [[Matomo/HAProxy]]
* [[Matomo/Maintenance]]

== 1. Environnement technique ==

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"
! Ubuntu
! Version PHP de référence

! Observations

Ubuntu 18.04

PHP 8.1

Installation historique avec version PHP ajoutée séparément

-

Ubuntu 24.04

PHP 8.3

Version fournie par Ubuntu

-

Ubuntu 26.04

PHP 8.4

Version utilisée sur AD64 en octobre 2026

}

Vérifier systématiquement la compatibilité entre PHP et la version de Matomo installée.

=== Composants nécessaires ===

* Apache 2.4
* PHP-FPM
* MariaDB ou MySQL
* Extensions PHP requises par Matomo
* Accès HTTPS, directement ou via HAProxy
* Accès réseau permettant le téléchargement et les mises à jour de Matomo

== 2. Installation des dépendances PHP ==

Adapter la version de PHP à celle installée sur la VM.

=== Ubuntu 24.04 — PHP 8.3 ===

<syntaxhighlight lang="bash">
sudo apt install \
php8.3-mysql php8.3-gd php8.3-curl php8.3-xml \
php8.3-mbstring php8.3-zip php8.3-intl
</syntaxhighlight>

=== Ubuntu 26.04 — PHP 8.4 ===

<syntaxhighlight lang="bash">
sudo apt install \
php8.4-mysql php8.4-gd php8.4-curl php8.4-xml \
php8.4-mbstring php8.4-zip php8.4-intl
</syntaxhighlight>

=== Vérification ===

<syntaxhighlight lang="bash">
php -v
php -m | grep -Ei 'mysqli|pdo_mysql|gd|curl|mbstring|xml|zip|intl'
</syntaxhighlight>

== 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.

=== 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">
sudo apt install php8.4-fpm

sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.4-fpm

sudo apache2ctl configtest
sudo systemctl reload apache2
</syntaxhighlight>

Vérifier ensuite :

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

'''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 ==

Vérifier que MariaDB est installé et actif :

<syntaxhighlight lang="bash">
systemctl status mariadb
</syntaxhighlight>

Matomo nécessite :

* Une base de données dédiée
* Un utilisateur SQL dédié
* Des droits limités à cette base

Exemple générique à adapter :

<syntaxhighlight lang="sql">
CREATE DATABASE matomo
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

CREATE USER 'matomo'@'localhost'
IDENTIFIED BY 'MOT_DE_PASSE_FORT_A_REMPLACER';

GRANT ALL PRIVILEGES ON matomo.*
TO 'matomo'@'localhost';
</syntaxhighlight>

Ne jamais conserver le mot de passe d'exemple dans une installation réelle.

== 5. Permissions et sécurisation des fichiers Matomo ==

=== Principes ===

L'installation Matomo est située dans :

<syntaxhighlight lang="text">
/var/www/matomo
</syntaxhighlight>

Sur les VM AJLSM, lorsque PHP-FPM s'exécute sous l'utilisateur `www-data`, les fichiers de Matomo appartiennent normalement à `www-data:www-data`.

Les permissions de référence sont :

{| class="wikitable"
! Élément
! Permissions
! Observations
|-
| Répertoires de l'application
| 755
| Lecture et traversée autorisées ; écriture réservée au propriétaire
|-
| Fichiers de l'application
| 644
| Lecture autorisée ; écriture réservée au propriétaire
|-
| config/config.ini.php
| 600
| Fichier sensible contenant notamment les paramètres de connexion à MariaDB
|-
| Répertoires temporaires et de configuration
| 755
| Accessibles en écriture au compte PHP-FPM lorsqu'il en est propriétaire
|-
| .well-known/acme-challenge
| 755
| Peut appartenir à root:root ; ne pas modifier sans vérifier la configuration ACME
|}

'''Important :''' les permissions 755 et 644 ne rendent pas les fichiers accessibles en écriture à tous. Elles permettent uniquement au propriétaire de les modifier.

=== Configuration initiale ===

Pour une nouvelle installation dont l'ensemble des fichiers applicatifs doit appartenir à `www-data` :

<syntaxhighlight lang="bash">
sudo chown -R www-data:www-data /var/www/matomo

sudo find /var/www/matomo -type d -exec chmod 755 {} \;
sudo find /var/www/matomo -type f -exec chmod 644 {} \;

sudo chmod 600 /var/www/matomo/config/config.ini.php
</syntaxhighlight>

'''Attention :''' ces commandes concernent une installation initiale, avant la création éventuelle de répertoires spécifiques par d'autres services. Ne pas les réexécuter aveuglément sur une installation existante.

Vérifier préalablement le compte utilisé par PHP-FPM. Si celui-ci est différent de `www-data`, adapter les propriétaires et permissions.

=== Vérification des permissions ===

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

Vérifier la répartition des propriétaires :

<syntaxhighlight lang="bash">
sudo find /var/www/matomo -xdev -printf '%u:%g\n' \
| sort | uniq -c | sort -nr
</syntaxhighlight>

Identifier les fichiers ou répertoires accessibles en écriture à tous :

<syntaxhighlight lang="bash">
sudo find /var/www/matomo -xdev -perm -0002 \
-printf '%m %u:%g %p\n'
</syntaxhighlight>

Cette dernière commande ne doit normalement rien retourner.

=== Vérification des répertoires accessibles en écriture ===

<syntaxhighlight lang="bash">
for DIR in config tmp plugins; do
if sudo -u www-data test -w "/var/www/matomo/$DIR"; then
echo "$DIR : écriture OK"
else
echo "$DIR : écriture NON autorisée"
fi
done
</syntaxhighlight>

Adapter `www-data` si Matomo utilise un autre compte PHP-FPM.

=== Cas particulier des répertoires ACME ===

Certains répertoires peuvent être créés et administrés par le mécanisme de validation des certificats Let's Encrypt :

<syntaxhighlight lang="text">
/var/www/matomo/.well-known
/var/www/matomo/.well-known/acme-challenge
</syntaxhighlight>

Ils peuvent légitimement appartenir à `root:root` avec des permissions `755`.

Ne pas modifier systématiquement leur propriétaire : vérifier au préalable le mécanisme de validation ACME utilisé sur la VM.

=== Vérification après modification ===

Après toute modification des permissions :

* Vérifier que l'interface Matomo reste accessible.
* Vérifier que la connexion à MariaDB fonctionne.
* Vérifier qu'aucune erreur de permission n'apparaît dans les journaux Apache/PHP-FPM.
* Vérifier que les statistiques continuent à être collectées.

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

L'audit de `/var/www/matomo` sur AD64 a donné les résultats suivants :

* 13 315 éléments appartenant à `www-data:www-data`.
* 2 répertoires appartenant à `root:root` : `.well-known` et `.well-known/acme-challenge`.
* Répertoires `config`, `tmp` et `plugins` accessibles en écriture à `www-data`.
* Aucun fichier ou répertoire accessible en écriture à tous.
* Fichier `config/config.ini.php` initialement en `644` : passage recommandé en `600`.
* Interface Matomo vérifiée fonctionnelle.

Aucune autre modification des propriétaires ou des permissions n'était nécessaire.

'''Conclusion :''' pour les nouvelles installations, appliquer des permissions adaptées dès le départ et réserver l'accès aux fichiers sensibles. Sur les installations existantes, effectuer un audit avant toute modification globale.

== 6. Configuration Apache et HTTPS ==

La configuration du VirtualHost Matomo est décrite dans :

[[Matomo/Apache]]

Deux architectures sont possibles :

* Apache assure directement la terminaison HTTPS.
* HAProxy assure la terminaison HTTPS et transmet les requêtes à Apache.

Dans l'infrastructure AJLSM utilisant HAProxy, le certificat public est généralement géré sur les répartiteurs de charge.

La procédure de configuration des certificats et des ACL est décrite dans :

[[Matomo/HAProxy]]

Pour une installation utilisant directement Certbot sur Apache :

<syntaxhighlight lang="bash">
sudo apt install certbot python3-certbot-apache
sudo certbot --apache
</syntaxhighlight>

Cette procédure Certbot ne doit pas être appliquée automatiquement à une VM dont le HTTPS public est déjà géré par HAProxy.

== 7. Initialisation de Matomo ==

Après configuration du VirtualHost, ouvrir dans un navigateur l'URL HTTPS prévue pour Matomo.

L'assistant d'installation permet notamment de :

# Vérifier les prérequis système
# Configurer la connexion à MariaDB
# Initialiser les tables Matomo
# Créer le compte administrateur
# Déclarer le premier site suivi

'''Important :''' chaque application suivie doit disposer de son propre identifiant de site Matomo lorsque l'on souhaite séparer ses statistiques.

Exemple : une application Internet et une salle de lecture Drupal peuvent être déclarées comme deux sites distincts.

== 8. Vérifications après installation ==

=== Vérifier la version installée ===

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

=== Vérifier les services ===

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

Adapter la version PHP-FPM si nécessaire.

=== Vérifier les points d'accès ===

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

curl -I "$MATOMO_URL/matomo.js"
curl -I "$MATOMO_URL/matomo.php"
</syntaxhighlight>

'''Note :''' selon le comportement du serveur, une requête HEAD peut ne pas produire le même résultat qu'une requête GET. Pour vérifier précisément les codes HTTP :

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

L'installation de Matomo ne garantit pas à elle seule que les applications transmettent leurs visites. Cette vérification relève des chapitres d'intégration.

== 9. Intégration aux applications ==

=== Drupal ===

Voir [[Matomo/Drupal]] pour :

* L'installation du module Drupal Matomo
* La configuration de l'identifiant du site
* L'adresse HTTPS du serveur Matomo
* Les exclusions des pages d'administration
* Les vérifications de collecte

=== Pleade ===

Voir [[Matomo/Pleade]].

=== Suivi IIIF et événements ===

* [[Matomo/IIIF]]
* [[Matomo/Evenements]]

== 10. Sécurité et maintenance ==

Après installation, vérifier :

* Que l'interface d'administration Matomo n'est accessible qu'aux utilisateurs ou réseaux autorisés
* Que les points de collecte nécessaires restent accessibles aux visiteurs
* Que le certificat HTTPS est valide
* Que les sauvegardes couvrent la base MariaDB et la configuration Matomo
* Que les mises à jour de sécurité sont suivies

Voir :

* [[Matomo/HAProxy]]
* [[Matomo/Maintenance]]
* [[Matomo/Debug]]

== 11. Installations de référence ==

{| class="wikitable"
! Projet
! Serveur
! Domaine Matomo
! Particularités
|-
| AD64
| ad64
| ad64-matomo.pleade.com
| Matomo 5.10.1 ; deux Drupal suivis séparément
|-
| APBP2
| À compléter
| apbp2-matomo.pleade.com
| Publication via HAProxy avec restriction de l'administration
|-
| MERCURE3
| À compléter
| mercure3-matomo.pleade.com
| Accès restreint à AJLSM
|}

Les paramètres propres à chaque client (domaines, adresses IP, identifiants Matomo, backends HAProxy) ne doivent pas être intégrés directement dans les commandes génériques.

Matomo/Installation

2026-10-20T10:53:20Z

Jlarvers : /* 1. Environnement technique */

= Installation de Matomo sur une VM Ubuntu =

== Objectif ==

Cette procédure décrit l'installation de Matomo sur les VM AJLSM hébergeant les applications Pleade et Drupal.

Elle est destinée à être réutilisée pour les nouveaux projets, indépendamment du client et du nom de domaine.

La configuration Apache, l'intégration Drupal et la publication sécurisée par HAProxy sont détaillées dans des chapitres distincts :

* [[Matomo/Apache]]
* [[Matomo/Drupal]]
* [[Matomo/HAProxy]]
* [[Matomo/Maintenance]]

== 1. Environnement technique ==

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"
! Ubuntu
! Version PHP de référence

! Observations

Ubuntu 18.04

PHP 8.1

Installation historique avec version PHP ajoutée séparément

-

Ubuntu 24.04

PHP 8.3

Version fournie par Ubuntu

-

Ubuntu 26.04

PHP 8.4

Version utilisée sur AD64 en octobre 2026

}

Vérifier systématiquement la compatibilité entre PHP et la version de Matomo installée.

=== Composants nécessaires ===

* Apache 2.4
* PHP-FPM
* MariaDB ou MySQL
* Extensions PHP requises par Matomo
* Accès HTTPS, directement ou via HAProxy
* Accès réseau permettant le téléchargement et les mises à jour de Matomo

== 2. Installation des dépendances PHP ==

Adapter la version de PHP à celle installée sur la VM.

=== Ubuntu 24.04 — PHP 8.3 ===

<syntaxhighlight lang="bash">
sudo apt install \
php8.3-mysql php8.3-gd php8.3-curl php8.3-xml \
php8.3-mbstring php8.3-zip php8.3-intl
</syntaxhighlight>

=== Ubuntu 26.04 — PHP 8.4 ===

<syntaxhighlight lang="bash">
sudo apt install \
php8.4-mysql php8.4-gd php8.4-curl php8.4-xml \
php8.4-mbstring php8.4-zip php8.4-intl
</syntaxhighlight>

=== Vérification ===

<syntaxhighlight lang="bash">
php -v
php -m | grep -Ei 'mysqli|pdo_mysql|gd|curl|mbstring|xml|zip|intl'
</syntaxhighlight>

== 3. Activation de PHP-FPM ==

Exemple pour PHP 8.4 :

<syntaxhighlight lang="bash">
sudo apt install php8.4-fpm
sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.4-fpm
sudo systemctl reload apache2
</syntaxhighlight>

Vérifier le service :

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

'''Attention :''' sur une VM hébergeant plusieurs applications PHP, vérifier les configurations Apache existantes avant d'activer une configuration PHP-FPM globale.

== 4. Préparation de MariaDB ==

Vérifier que MariaDB est installé et actif :

<syntaxhighlight lang="bash">
systemctl status mariadb
</syntaxhighlight>

Matomo nécessite :

* Une base de données dédiée
* Un utilisateur SQL dédié
* Des droits limités à cette base

Exemple générique à adapter :

<syntaxhighlight lang="sql">
CREATE DATABASE matomo
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

CREATE USER 'matomo'@'localhost'
IDENTIFIED BY 'MOT_DE_PASSE_FORT_A_REMPLACER';

GRANT ALL PRIVILEGES ON matomo.*
TO 'matomo'@'localhost';
</syntaxhighlight>

Ne jamais conserver le mot de passe d'exemple dans une installation réelle.

== 5. Permissions et sécurisation des fichiers Matomo ==

=== Principes ===

L'installation Matomo est située dans :

<syntaxhighlight lang="text">
/var/www/matomo
</syntaxhighlight>

Sur les VM AJLSM, lorsque PHP-FPM s'exécute sous l'utilisateur `www-data`, les fichiers de Matomo appartiennent normalement à `www-data:www-data`.

Les permissions de référence sont :

{| class="wikitable"
! Élément
! Permissions
! Observations
|-
| Répertoires de l'application
| 755
| Lecture et traversée autorisées ; écriture réservée au propriétaire
|-
| Fichiers de l'application
| 644
| Lecture autorisée ; écriture réservée au propriétaire
|-
| config/config.ini.php
| 600
| Fichier sensible contenant notamment les paramètres de connexion à MariaDB
|-
| Répertoires temporaires et de configuration
| 755
| Accessibles en écriture au compte PHP-FPM lorsqu'il en est propriétaire
|-
| .well-known/acme-challenge
| 755
| Peut appartenir à root:root ; ne pas modifier sans vérifier la configuration ACME
|}

'''Important :''' les permissions 755 et 644 ne rendent pas les fichiers accessibles en écriture à tous. Elles permettent uniquement au propriétaire de les modifier.

=== Configuration initiale ===

Pour une nouvelle installation dont l'ensemble des fichiers applicatifs doit appartenir à `www-data` :

<syntaxhighlight lang="bash">
sudo chown -R www-data:www-data /var/www/matomo

sudo find /var/www/matomo -type d -exec chmod 755 {} \;
sudo find /var/www/matomo -type f -exec chmod 644 {} \;

sudo chmod 600 /var/www/matomo/config/config.ini.php
</syntaxhighlight>

'''Attention :''' ces commandes concernent une installation initiale, avant la création éventuelle de répertoires spécifiques par d'autres services. Ne pas les réexécuter aveuglément sur une installation existante.

Vérifier préalablement le compte utilisé par PHP-FPM. Si celui-ci est différent de `www-data`, adapter les propriétaires et permissions.

=== Vérification des permissions ===

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

Vérifier la répartition des propriétaires :

<syntaxhighlight lang="bash">
sudo find /var/www/matomo -xdev -printf '%u:%g\n' \
| sort | uniq -c | sort -nr
</syntaxhighlight>

Identifier les fichiers ou répertoires accessibles en écriture à tous :

<syntaxhighlight lang="bash">
sudo find /var/www/matomo -xdev -perm -0002 \
-printf '%m %u:%g %p\n'
</syntaxhighlight>

Cette dernière commande ne doit normalement rien retourner.

=== Vérification des répertoires accessibles en écriture ===

<syntaxhighlight lang="bash">
for DIR in config tmp plugins; do
if sudo -u www-data test -w "/var/www/matomo/$DIR"; then
echo "$DIR : écriture OK"
else
echo "$DIR : écriture NON autorisée"
fi
done
</syntaxhighlight>

Adapter `www-data` si Matomo utilise un autre compte PHP-FPM.

=== Cas particulier des répertoires ACME ===

Certains répertoires peuvent être créés et administrés par le mécanisme de validation des certificats Let's Encrypt :

<syntaxhighlight lang="text">
/var/www/matomo/.well-known
/var/www/matomo/.well-known/acme-challenge
</syntaxhighlight>

Ils peuvent légitimement appartenir à `root:root` avec des permissions `755`.

Ne pas modifier systématiquement leur propriétaire : vérifier au préalable le mécanisme de validation ACME utilisé sur la VM.

=== Vérification après modification ===

Après toute modification des permissions :

* Vérifier que l'interface Matomo reste accessible.
* Vérifier que la connexion à MariaDB fonctionne.
* Vérifier qu'aucune erreur de permission n'apparaît dans les journaux Apache/PHP-FPM.
* Vérifier que les statistiques continuent à être collectées.

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

L'audit de `/var/www/matomo` sur AD64 a donné les résultats suivants :

* 13 315 éléments appartenant à `www-data:www-data`.
* 2 répertoires appartenant à `root:root` : `.well-known` et `.well-known/acme-challenge`.
* Répertoires `config`, `tmp` et `plugins` accessibles en écriture à `www-data`.
* Aucun fichier ou répertoire accessible en écriture à tous.
* Fichier `config/config.ini.php` initialement en `644` : passage recommandé en `600`.
* Interface Matomo vérifiée fonctionnelle.

Aucune autre modification des propriétaires ou des permissions n'était nécessaire.

'''Conclusion :''' pour les nouvelles installations, appliquer des permissions adaptées dès le départ et réserver l'accès aux fichiers sensibles. Sur les installations existantes, effectuer un audit avant toute modification globale.

== 6. Configuration Apache et HTTPS ==

La configuration du VirtualHost Matomo est décrite dans :

[[Matomo/Apache]]

Deux architectures sont possibles :

* Apache assure directement la terminaison HTTPS.
* HAProxy assure la terminaison HTTPS et transmet les requêtes à Apache.

Dans l'infrastructure AJLSM utilisant HAProxy, le certificat public est généralement géré sur les répartiteurs de charge.

La procédure de configuration des certificats et des ACL est décrite dans :

[[Matomo/HAProxy]]

Pour une installation utilisant directement Certbot sur Apache :

<syntaxhighlight lang="bash">
sudo apt install certbot python3-certbot-apache
sudo certbot --apache
</syntaxhighlight>

Cette procédure Certbot ne doit pas être appliquée automatiquement à une VM dont le HTTPS public est déjà géré par HAProxy.

== 7. Initialisation de Matomo ==

Après configuration du VirtualHost, ouvrir dans un navigateur l'URL HTTPS prévue pour Matomo.

L'assistant d'installation permet notamment de :

# Vérifier les prérequis système
# Configurer la connexion à MariaDB
# Initialiser les tables Matomo
# Créer le compte administrateur
# Déclarer le premier site suivi

'''Important :''' chaque application suivie doit disposer de son propre identifiant de site Matomo lorsque l'on souhaite séparer ses statistiques.

Exemple : une application Internet et une salle de lecture Drupal peuvent être déclarées comme deux sites distincts.

== 8. Vérifications après installation ==

=== Vérifier la version installée ===

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

=== Vérifier les services ===

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

Adapter la version PHP-FPM si nécessaire.

=== Vérifier les points d'accès ===

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

curl -I "$MATOMO_URL/matomo.js"
curl -I "$MATOMO_URL/matomo.php"
</syntaxhighlight>

'''Note :''' selon le comportement du serveur, une requête HEAD peut ne pas produire le même résultat qu'une requête GET. Pour vérifier précisément les codes HTTP :

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

L'installation de Matomo ne garantit pas à elle seule que les applications transmettent leurs visites. Cette vérification relève des chapitres d'intégration.

== 9. Intégration aux applications ==

=== Drupal ===

Voir [[Matomo/Drupal]] pour :

* L'installation du module Drupal Matomo
* La configuration de l'identifiant du site
* L'adresse HTTPS du serveur Matomo
* Les exclusions des pages d'administration
* Les vérifications de collecte

=== Pleade ===

Voir [[Matomo/Pleade]].

=== Suivi IIIF et événements ===

* [[Matomo/IIIF]]
* [[Matomo/Evenements]]

== 10. Sécurité et maintenance ==

Après installation, vérifier :

* Que l'interface d'administration Matomo n'est accessible qu'aux utilisateurs ou réseaux autorisés
* Que les points de collecte nécessaires restent accessibles aux visiteurs
* Que le certificat HTTPS est valide
* Que les sauvegardes couvrent la base MariaDB et la configuration Matomo
* Que les mises à jour de sécurité sont suivies

Voir :

* [[Matomo/HAProxy]]
* [[Matomo/Maintenance]]
* [[Matomo/Debug]]

== 11. Installations de référence ==

{| class="wikitable"
! Projet
! Serveur
! Domaine Matomo
! Particularités
|-
| AD64
| ad64
| ad64-matomo.pleade.com
| Matomo 5.10.1 ; deux Drupal suivis séparément
|-
| APBP2
| À compléter
| apbp2-matomo.pleade.com
| Publication via HAProxy avec restriction de l'administration
|-
| MERCURE3
| À compléter
| mercure3-matomo.pleade.com
| Accès restreint à AJLSM
|}

Les paramètres propres à chaque client (domaines, adresses IP, identifiants Matomo, backends HAProxy) ne doivent pas être intégrés directement dans les commandes génériques.

Matomo/HAProxy

2026-10-20T10:51:01Z

Jlarvers : /* Exemple générique */

= 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="yaml">
# 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="yaml">
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="yaml">
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 ==
Voir aussi la configuration du WAF avec ansible : [[WAF_2026#Ansible|WAF 2026]]
=== 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="yaml">
# 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="yaml">
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/HAProxy

2026-10-20T10:45:52Z

Jlarvers : /* 7. Déploiement avec Ansible */

= 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="yaml">
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="yaml">
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 ==
Voir aussi la configuration du WAF avec ansible : [[WAF_2026#Ansible|WAF 2026]]
=== 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="yaml">
# 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="yaml">
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/HAProxy

2026-10-20T10:44:16Z

Jlarvers : /* 7. Déploiement avec Ansible */

= 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="yaml">
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="yaml">
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 ==
Voir aussi : [[WAF_2026#Ansible|WAF 2026]]
=== 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="yaml">
# 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="yaml">
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/HAProxy

2026-10-20T10:43:40Z

Jlarvers : /* 7. Déploiement avec Ansible */

= 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="yaml">
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="yaml">
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 ==
Voir aussi : [[WAF 2026|WAF_2026#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="yaml">
# 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="yaml">
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/HAProxy

2026-10-20T10:43:11Z

Jlarvers : /* 7. Déploiement avec Ansible */

= 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="yaml">
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="yaml">
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 ==
Voir aussi :[[WAF_2026#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="yaml">
# 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="yaml">
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/HAProxy

2026-10-20T10:41:42Z

Jlarvers : /* Configuration HAProxy */

= 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="yaml">
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="yaml">
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="yaml">
# 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="yaml">
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/HAProxy

2026-10-20T10:41:25Z

Jlarvers : /* Backend HTTP */

= 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="yaml">
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="yaml">
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/HAProxy

2026-10-20T10:41:17Z

Jlarvers : /* 5. Configuration du backend */

= 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="yaml">
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/HAProxy

2026-10-20T10:40:43Z

Jlarvers : 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 ... »

= 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

2026-10-20T10:35:23Z

Jlarvers : /* Matomo – Portails d'archives numériques */

= Matomo – Portails d'archives numériques =

Documentation MediaWiki pour installer, configurer et exploiter Matomo
dans un portail basé sur :

* Ubuntu 18.04 et sur Ubuntu 24.04
* Apache
* Haproxy
* PHP-FPM
* Drupal 10
* Pleade
* Lucene
* Mirador / IIIF

== Sommaire ==
* [[Matomo/Installation]]
* [[Matomo/Apache]]
* [[Matomo/Drupal]]
* [[Matomo/HAProxy]]
* [[Matomo/Maintenance]]
* [[Matomo/Recherche]]
* [[Matomo/Pleade]]
* [[Matomo/IIIF]]
* [[Matomo/Evenements]]
* [[Matomo/Objectifs]]
* [[Matomo/Dashboards]]
* [[Matomo/Debug]]
* [[Matomo/KPI Archives]]
* [[Matomo/Lucene]]

Matomo/Drupal

2026-10-20T10:30:22Z

Jlarvers :

= Intégration Matomo dans Drupal =

== Objectif ==

Configurer le module Matomo de Drupal pour transmettre les statistiques de fréquentation vers un serveur Matomo.

Chaque application Drupal peut utiliser un identifiant de site Matomo distinct, même lorsque plusieurs applications partagent le même serveur Matomo.

== 1. Prérequis ==

* Matomo installé et accessible en HTTPS.
* Site déclaré dans l'administration Matomo.
* Identifiant Matomo du site connu.
* Drupal fonctionnel.
* Composer et Drush disponibles.
* Module Drupal Matomo compatible avec la version de Drupal utilisée.

== 2. Installation du module ==

Se placer dans le répertoire racine du projet Drupal, contenant `composer.json`.

<syntaxhighlight lang="bash">
composer require drupal/matomo

./vendor/bin/drush --root=web en matomo -y
./vendor/bin/drush --root=web cache:rebuild
</syntaxhighlight>

'''Important :''' exécuter Composer avec le compte habituel de maintenance du projet Drupal, et non systématiquement sous `root` ou `www-data`.

Adapter `--root=web` si le document root du projet est différent.

== 3. Configuration de Matomo ==

=== Paramètres du projet ===

Définir les paramètres correspondant à l'application :

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

L'identifiant doit correspondre au site créé dans l'interface d'administration Matomo.

=== Configuration via Drush ===

<syntaxhighlight lang="bash">
./vendor/bin/drush --root=web config:set matomo.settings \
site_id "$MATOMO_SITE_ID" -y

./vendor/bin/drush --root=web config:set matomo.settings
url_http "$MATOMO_URL" -y

./vendor/bin/drush --root=web config:set matomo.settings
url_https "$MATOMO_URL" -y

./vendor/bin/drush --root=web cache:rebuild
</syntaxhighlight>

Même si les paramètres portent les noms `url_http` et `url_https`, utiliser l'adresse HTTPS du serveur Matomo lorsque celle-ci est disponible.

== 4. Exclusion des pages d'administration ==

Il est généralement préférable de ne pas comptabiliser les consultations des pages d'administration Drupal dans les statistiques publiques.

=== Configuration standard ===

<syntaxhighlight lang="bash">
./vendor/bin/drush --root=web config:set matomo.settings \
visibility.request_path_pages \
$'/admin\n/admin/*\n/batch\n/node/add*\n/node/*/*\n/user/*/*' -y

./vendor/bin/drush --root=web cache:rebuild
</syntaxhighlight>

Cette configuration exclut les chemins indiqués lorsque le mode d'exclusion est actif.

=== Vérification du mode d'exclusion ===

<syntaxhighlight lang="bash">
./vendor/bin/drush --root=web config:get matomo.settings \
visibility.request_path_mode
</syntaxhighlight>

Sur les installations AD64 validées en octobre 2026, la valeur utilisée est `0`.

=== Cas des chemins d'administration renommés ===

Certains projets Drupal utilisent le module `rename_admin_paths` pour modifier les chemins d'administration.

Exemple AD64 :

* `/admin` devient `/bacad64`.
* `/user` devient `/arc-ad64`.

Dans ce cas, ajouter les chemins personnalisés à la liste d'exclusion.

<syntaxhighlight lang="bash">
./vendor/bin/drush --root=web config:set matomo.settings \
visibility.request_path_pages \
$'/admin\n/admin/*\n/bacad64\n/bacad64/*\n/batch\n/node/add*\n/node/*/*\n/user/*/*\n/arc-ad64\n/arc-ad64/*' -y

./vendor/bin/drush --root=web cache:rebuild
</syntaxhighlight>

'''Important :''' les chemins `/bacad64` et `/arc-ad64` sont propres à l'exemple AD64. Ils doivent être remplacés par les chemins réellement configurés sur chaque projet.

== 5. Gestion des utilisateurs et de la confidentialité ==

Le module Drupal Matomo propose plusieurs paramètres de visibilité et de confidentialité.

Vérifier les valeurs en vigueur :

<syntaxhighlight lang="bash">
./vendor/bin/drush --root=web config:get matomo.settings
</syntaxhighlight>

Paramètres notamment concernés :

* `visibility.user_account_mode`
* `visibility.user_role_mode`
* `visibility.user_role_roles`
* `privacy.donottrack`
* `privacy.disablecookies`

La documentation historique AJLSM utilisait notamment :

<syntaxhighlight lang="bash">
drush config:set matomo.settings visibility.user_account_mode 0 -y
drush config:set matomo.settings visibility.user_role_mode 0 -y
drush config:set matomo.settings privacy.donottrack false -y
</syntaxhighlight>

Ces valeurs ne doivent pas être réappliquées systématiquement.

Sur AD64, le paramètre `privacy.donottrack` était configuré à `true` lors de la vérification d'octobre 2026.

La politique de suivi, de cookies et de respect du signal Do Not Track doit être déterminée selon les exigences applicables au projet.

== 6. Recherche interne Drupal ==

Le module Matomo permet de suivre les recherches internes Drupal.

Activation, lorsque cette fonctionnalité est nécessaire :

<syntaxhighlight lang="bash">
./vendor/bin/drush --root=web config:set matomo.settings \
track.site_search true -y

./vendor/bin/drush --root=web cache:rebuild
</syntaxhighlight>

'''Attention :''' l'activation de ce paramètre ne garantit pas à elle seule que toutes les recherches seront reconnues correctement. Vérifier le fonctionnement réel du moteur de recherche Drupal et les paramètres transmis à Matomo.

Voir [[Matomo/Recherche]].

== 7. Vérification de l'injection JavaScript ==

Définir l'URL publique de l'application Drupal :

<syntaxhighlight lang="bash">
DRUPAL_URL="https://drupal.exemple.fr/"
</syntaxhighlight>

Vérifier la présence du code de suivi :

<syntaxhighlight lang="bash">
curl -sSL "$DRUPAL_URL" \
| grep -iE 'matomo.js|matomo.php|_paq|setSiteId'
</syntaxhighlight>

Vérifier que l'identifiant Matomo injecté correspond bien à celui du site Drupal concerné.

'''Important :''' cette vérification confirme uniquement la présence du code de suivi dans la page HTML. Elle ne prouve pas que Matomo reçoit les visites.

== 8. Vérification de la collecte réelle ==

=== Test navigateur ===

# Ouvrir le site Drupal dans un navigateur.
# Consulter plusieurs pages publiques.
# Éviter, pour ce test, une session d'administration Drupal.
# Vérifier l'apparition des visites dans Matomo.

Les bloqueurs de publicité, les paramètres de confidentialité du navigateur ou les restrictions réseau peuvent empêcher la collecte.

=== Vérification dans MariaDB ===

Sur le serveur Matomo, adapter le nom de la base et les identifiants des sites :

<syntaxhighlight lang="bash">
sudo mariadb -t -e "
SELECT
idsite,
COUNT(*) AS visites,
MAX(visit_last_action_time) AS derniere_activite
FROM matomo.matomo_log_visit
WHERE idsite IN (2,3)
GROUP BY idsite;
"
</syntaxhighlight>

Cette requête permet de vérifier que des visites ont été enregistrées.

'''Attention :''' les identifiants `2` et `3` sont ceux de l'exemple AD64. Ils doivent être adaptés aux sites Matomo du projet.

== 9. Exemple : AD64 ==

En octobre 2026, les deux applications Drupal AD64 ont été configurées indépendamment.

{| class="wikitable"
! Application
! Répertoire Drupal
! Identifiant Matomo
|-
| Internet
| /home/ajlsm/drupals/internet
| 2
|-
| Salle de lecture
| /home/ajlsm/drupals/slecture
| 3
|}

Serveur Matomo commun :

<syntaxhighlight lang="text">
https://ad64-matomo.pleade.com/
</syntaxhighlight>

Les deux applications disposent :

* Du module Drupal Matomo activé.
* De leur propre identifiant Matomo.
* D'exclusions des chemins d'administration.
* D'une collecte vérifiée par consultation des données MariaDB.

L'application de préproduction n'a pas été configurée pour le suivi Matomo, celui-ci n'étant pas nécessaire à son utilisation.

== 10. Diagnostic ==

Si aucune visite n'apparaît dans Matomo :

# Vérifier l'identifiant du site Matomo.
# Vérifier les URL configurées dans Drupal.
# Vérifier la présence du JavaScript dans les pages publiques.
# Vérifier les requêtes réseau vers `matomo.php`.
# Vérifier les ACL HAProxy.
# Vérifier les éventuels bloqueurs ou restrictions de confidentialité.
# Vérifier les journaux Apache et les données MariaDB.

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

Matomo/Apache

2026-10-20T10:29:59Z

Jlarvers :

= Configuration Apache pour Matomo =

== Objectif ==

Configurer Apache pour publier une installation Matomo située dans `/var/www/matomo`.

Dans l'infrastructure AJLSM, Matomo peut être accessible :

* Directement via Apache, avec un certificat HTTPS local.
* Derrière les répartiteurs HAProxy, qui assurent le HTTPS public et les restrictions d'accès.

La configuration des ACL et des certificats HAProxy est décrite dans [[Matomo/HAProxy]].

== 1. Prérequis ==

* Matomo installé dans `/var/www/matomo`.
* Apache 2.4 installé et actif.
* PHP-FPM installé et configuré.
* Nom DNS prévu pour Matomo.
* Base MariaDB configurée.

Voir [[Matomo/Installation]].

== 2. Création du VirtualHost ==

Créer le fichier `/etc/apache2/sites-available/matomo.conf`.

=== Exemple HTTP ===

<syntaxhighlight lang="apache">
<VirtualHost *:80>
ServerName matomo.exemple.fr
DocumentRoot /var/www/matomo

<Directory /var/www/matomo>
Options FollowSymLinks
AllowOverride All
Require all granted
</Directory>

ErrorLog ${APACHE_LOG_DIR}/matomo-error.log
CustomLog ${APACHE_LOG_DIR}/matomo-access.log combined
</VirtualHost>
</syntaxhighlight>

Remplacer `matomo.exemple.fr` par le nom DNS du projet.

'''Attention :''' cet exemple configure uniquement le VirtualHost HTTP. Il ne constitue pas, à lui seul, une publication sécurisée sur Internet.

== 3. Configuration PHP-FPM ==

Vérifier que PHP-FPM est actif :

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

Adapter la version de PHP à celle installée sur la VM.

Vérifier les modules Apache :

<syntaxhighlight lang="bash">
apache2ctl -M | grep -E 'proxy|fcgi|rewrite'
</syntaxhighlight>

Si nécessaire :

<syntaxhighlight lang="bash">
sudo a2enmod proxy_fcgi setenvif rewrite
sudo a2enconf php8.4-fpm
</syntaxhighlight>

'''Important :''' si plusieurs applications utilisent des versions PHP différentes, ne pas activer automatiquement une configuration PHP-FPM globale. Utiliser le pool et le gestionnaire PHP appropriés au VirtualHost.

== 4. Activation du VirtualHost ==

<syntaxhighlight lang="bash">
sudo a2ensite matomo.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
</syntaxhighlight>

Résultat attendu pour `configtest` :

<syntaxhighlight lang="text">
Syntax OK
</syntaxhighlight>

== 5. Configuration HTTPS ==

=== HTTPS directement sur Apache ===

Lorsque Matomo est publié directement par Apache, configurer un VirtualHost HTTPS et un certificat valide.

Une installation Certbot peut être utilisée si elle correspond à l'architecture du serveur :

<syntaxhighlight lang="bash">
sudo apt install certbot python3-certbot-apache
sudo certbot --apache
</syntaxhighlight>

=== HTTPS via HAProxy ===

Lorsque Matomo est publié derrière HAProxy :

* Le domaine public pointe vers HAProxy.
* HAProxy présente le certificat HTTPS public.
* HAProxy transmet les requêtes au backend Apache.
* Le backend peut utiliser HTTP ou HTTPS selon la configuration du projet.

Dans le cas d'un backend HTTPS, vérifier le certificat utilisé côté Apache et la configuration de validation TLS du backend HAProxy.

Ne pas installer automatiquement un second certificat public sur Apache si ce n'est pas nécessaire.

Voir [[Matomo/HAProxy]].

== 6. Protection des fichiers sensibles ==

Le répertoire Matomo contient des fichiers qui ne doivent pas être accessibles directement depuis le navigateur, notamment les fichiers de configuration.

Vérifier que les règles de protection fournies avec Matomo sont effectivement appliquées par Apache.

La directive suivante autorise Apache à prendre en compte les fichiers `.htaccess` de l'application :

<syntaxhighlight lang="apache">
<Directory /var/www/matomo>
AllowOverride All
Require all granted
</Directory>
</syntaxhighlight>

'''Important :''' `AllowOverride All` ne remplace pas une vérification effective de la protection des fichiers sensibles.

Les permissions système sont décrites dans [[Matomo/Installation]].

== 7. Vérifications ==

=== Vérifier la configuration Apache ===

<syntaxhighlight lang="bash">
sudo apache2ctl configtest
sudo apache2ctl -S
</syntaxhighlight>

=== Vérifier la réponse HTTP ===

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

curl -sS -o /dev/null -w "HTTP %{http_code}\n"
"$MATOMO_URL/matomo.js"

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

Les deux points de collecte doivent être accessibles aux visiteurs autorisés à consulter les applications suivies.

Une réponse HTTP 200 sur `matomo.php` ne prouve pas à elle seule qu'une visite a été enregistrée.

=== Vérifier les journaux ===

<syntaxhighlight lang="bash">
sudo tail -n 50 /var/log/apache2/matomo-error.log
sudo tail -n 50 /var/log/apache2/matomo-access.log
</syntaxhighlight>

Adapter les chemins si les journaux du projet utilisent d'autres noms.

== 8. Cas d'une publication sécurisée par HAProxy ==

Dans les installations AJLSM où l'administration Matomo est réservée à certaines adresses IP :

* `/matomo.js` doit rester accessible pour le chargement du script de suivi.
* `/matomo.php` doit rester accessible pour la transmission des statistiques.
* L'interface Matomo doit être protégée par les ACL HAProxy.
* Les autres chemins doivent être examinés selon les fonctionnalités utilisées.

La restriction par IP de l'interface ne remplace pas l'authentification propre à Matomo.

La procédure de configuration et de déploiement Ansible est détaillée dans [[Matomo/HAProxy]].

== 9. Diagnostic ==

En cas de dysfonctionnement, vérifier successivement :

# La résolution DNS.
# La validité du certificat HTTPS.
# Le routage HAProxy, si utilisé.
# La configuration du VirtualHost Apache.
# Le fonctionnement de PHP-FPM.
# Les permissions de `/var/www/matomo`.
# La connexion à MariaDB.
# Les journaux Apache et PHP-FPM.

Voir [[Matomo/Debug]].

Matomo/Installation

2026-10-20T10:28:13Z

Jlarvers : /* 5. Installation des fichiers Matomo */

= Installation de Matomo sur une VM Ubuntu =

== Objectif ==

Cette procédure décrit l'installation de Matomo sur les VM AJLSM hébergeant les applications Pleade et Drupal.

Elle est destinée à être réutilisée pour les nouveaux projets, indépendamment du client et du nom de domaine.

La configuration Apache, l'intégration Drupal et la publication sécurisée par HAProxy sont détaillées dans des chapitres distincts :

* [[Matomo/Apache]]
* [[Matomo/Drupal]]
* [[Matomo/HAProxy]]
* [[Matomo/Maintenance]]

== 1. Environnement technique ==

=== Versions d'Ubuntu et de PHP ===

{| class="wikitable"
! Ubuntu
! PHP
! Statut documentaire
|-
| Ubuntu 18.04
| PHP 8.1 via PHP-FPM
| Installation historique, hors support standard
|-
| Ubuntu 24.04
| PHP 8.3 via PHP-FPM
| Installation existante
|-
| Ubuntu 26.04
| PHP 8.4 via PHP-FPM
| Environnement utilisé pour 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.

=== Composants nécessaires ===

* Apache 2.4
* PHP-FPM
* MariaDB ou MySQL
* Extensions PHP requises par Matomo
* Accès HTTPS, directement ou via HAProxy
* Accès réseau permettant le téléchargement et les mises à jour de Matomo

== 2. Installation des dépendances PHP ==

Adapter la version de PHP à celle installée sur la VM.

=== Ubuntu 24.04 — PHP 8.3 ===

<syntaxhighlight lang="bash">
sudo apt install \
php8.3-mysql php8.3-gd php8.3-curl php8.3-xml \
php8.3-mbstring php8.3-zip php8.3-intl
</syntaxhighlight>

=== Ubuntu 26.04 — PHP 8.4 ===

<syntaxhighlight lang="bash">
sudo apt install \
php8.4-mysql php8.4-gd php8.4-curl php8.4-xml \
php8.4-mbstring php8.4-zip php8.4-intl
</syntaxhighlight>

=== Vérification ===

<syntaxhighlight lang="bash">
php -v
php -m | grep -Ei 'mysqli|pdo_mysql|gd|curl|mbstring|xml|zip|intl'
</syntaxhighlight>

== 3. Activation de PHP-FPM ==

Exemple pour PHP 8.4 :

<syntaxhighlight lang="bash">
sudo apt install php8.4-fpm
sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.4-fpm
sudo systemctl reload apache2
</syntaxhighlight>

Vérifier le service :

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

'''Attention :''' sur une VM hébergeant plusieurs applications PHP, vérifier les configurations Apache existantes avant d'activer une configuration PHP-FPM globale.

== 4. Préparation de MariaDB ==

Vérifier que MariaDB est installé et actif :

<syntaxhighlight lang="bash">
systemctl status mariadb
</syntaxhighlight>

Matomo nécessite :

* Une base de données dédiée
* Un utilisateur SQL dédié
* Des droits limités à cette base

Exemple générique à adapter :

<syntaxhighlight lang="sql">
CREATE DATABASE matomo
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

CREATE USER 'matomo'@'localhost'
IDENTIFIED BY 'MOT_DE_PASSE_FORT_A_REMPLACER';

GRANT ALL PRIVILEGES ON matomo.*
TO 'matomo'@'localhost';
</syntaxhighlight>

Ne jamais conserver le mot de passe d'exemple dans une installation réelle.

== 5. Permissions et sécurisation des fichiers Matomo ==

=== Principes ===

L'installation Matomo est située dans :

<syntaxhighlight lang="text">
/var/www/matomo
</syntaxhighlight>

Sur les VM AJLSM, lorsque PHP-FPM s'exécute sous l'utilisateur `www-data`, les fichiers de Matomo appartiennent normalement à `www-data:www-data`.

Les permissions de référence sont :

{| class="wikitable"
! Élément
! Permissions
! Observations
|-
| Répertoires de l'application
| 755
| Lecture et traversée autorisées ; écriture réservée au propriétaire
|-
| Fichiers de l'application
| 644
| Lecture autorisée ; écriture réservée au propriétaire
|-
| config/config.ini.php
| 600
| Fichier sensible contenant notamment les paramètres de connexion à MariaDB
|-
| Répertoires temporaires et de configuration
| 755
| Accessibles en écriture au compte PHP-FPM lorsqu'il en est propriétaire
|-
| .well-known/acme-challenge
| 755
| Peut appartenir à root:root ; ne pas modifier sans vérifier la configuration ACME
|}

'''Important :''' les permissions 755 et 644 ne rendent pas les fichiers accessibles en écriture à tous. Elles permettent uniquement au propriétaire de les modifier.

=== Configuration initiale ===

Pour une nouvelle installation dont l'ensemble des fichiers applicatifs doit appartenir à `www-data` :

<syntaxhighlight lang="bash">
sudo chown -R www-data:www-data /var/www/matomo

sudo find /var/www/matomo -type d -exec chmod 755 {} \;
sudo find /var/www/matomo -type f -exec chmod 644 {} \;

sudo chmod 600 /var/www/matomo/config/config.ini.php
</syntaxhighlight>

'''Attention :''' ces commandes concernent une installation initiale, avant la création éventuelle de répertoires spécifiques par d'autres services. Ne pas les réexécuter aveuglément sur une installation existante.

Vérifier préalablement le compte utilisé par PHP-FPM. Si celui-ci est différent de `www-data`, adapter les propriétaires et permissions.

=== Vérification des permissions ===

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

Vérifier la répartition des propriétaires :

<syntaxhighlight lang="bash">
sudo find /var/www/matomo -xdev -printf '%u:%g\n' \
| sort | uniq -c | sort -nr
</syntaxhighlight>

Identifier les fichiers ou répertoires accessibles en écriture à tous :

<syntaxhighlight lang="bash">
sudo find /var/www/matomo -xdev -perm -0002 \
-printf '%m %u:%g %p\n'
</syntaxhighlight>

Cette dernière commande ne doit normalement rien retourner.

=== Vérification des répertoires accessibles en écriture ===

<syntaxhighlight lang="bash">
for DIR in config tmp plugins; do
if sudo -u www-data test -w "/var/www/matomo/$DIR"; then
echo "$DIR : écriture OK"
else
echo "$DIR : écriture NON autorisée"
fi
done
</syntaxhighlight>

Adapter `www-data` si Matomo utilise un autre compte PHP-FPM.

=== Cas particulier des répertoires ACME ===

Certains répertoires peuvent être créés et administrés par le mécanisme de validation des certificats Let's Encrypt :

<syntaxhighlight lang="text">
/var/www/matomo/.well-known
/var/www/matomo/.well-known/acme-challenge
</syntaxhighlight>

Ils peuvent légitimement appartenir à `root:root` avec des permissions `755`.

Ne pas modifier systématiquement leur propriétaire : vérifier au préalable le mécanisme de validation ACME utilisé sur la VM.

=== Vérification après modification ===

Après toute modification des permissions :

* Vérifier que l'interface Matomo reste accessible.
* Vérifier que la connexion à MariaDB fonctionne.
* Vérifier qu'aucune erreur de permission n'apparaît dans les journaux Apache/PHP-FPM.
* Vérifier que les statistiques continuent à être collectées.

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

L'audit de `/var/www/matomo` sur AD64 a donné les résultats suivants :

* 13 315 éléments appartenant à `www-data:www-data`.
* 2 répertoires appartenant à `root:root` : `.well-known` et `.well-known/acme-challenge`.
* Répertoires `config`, `tmp` et `plugins` accessibles en écriture à `www-data`.
* Aucun fichier ou répertoire accessible en écriture à tous.
* Fichier `config/config.ini.php` initialement en `644` : passage recommandé en `600`.
* Interface Matomo vérifiée fonctionnelle.

Aucune autre modification des propriétaires ou des permissions n'était nécessaire.

'''Conclusion :''' pour les nouvelles installations, appliquer des permissions adaptées dès le départ et réserver l'accès aux fichiers sensibles. Sur les installations existantes, effectuer un audit avant toute modification globale.

== 6. Configuration Apache et HTTPS ==

La configuration du VirtualHost Matomo est décrite dans :

[[Matomo/Apache]]

Deux architectures sont possibles :

* Apache assure directement la terminaison HTTPS.
* HAProxy assure la terminaison HTTPS et transmet les requêtes à Apache.

Dans l'infrastructure AJLSM utilisant HAProxy, le certificat public est généralement géré sur les répartiteurs de charge.

La procédure de configuration des certificats et des ACL est décrite dans :

[[Matomo/HAProxy]]

Pour une installation utilisant directement Certbot sur Apache :

<syntaxhighlight lang="bash">
sudo apt install certbot python3-certbot-apache
sudo certbot --apache
</syntaxhighlight>

Cette procédure Certbot ne doit pas être appliquée automatiquement à une VM dont le HTTPS public est déjà géré par HAProxy.

== 7. Initialisation de Matomo ==

Après configuration du VirtualHost, ouvrir dans un navigateur l'URL HTTPS prévue pour Matomo.

L'assistant d'installation permet notamment de :

# Vérifier les prérequis système
# Configurer la connexion à MariaDB
# Initialiser les tables Matomo
# Créer le compte administrateur
# Déclarer le premier site suivi

'''Important :''' chaque application suivie doit disposer de son propre identifiant de site Matomo lorsque l'on souhaite séparer ses statistiques.

Exemple : une application Internet et une salle de lecture Drupal peuvent être déclarées comme deux sites distincts.

== 8. Vérifications après installation ==

=== Vérifier la version installée ===

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

=== Vérifier les services ===

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

Adapter la version PHP-FPM si nécessaire.

=== Vérifier les points d'accès ===

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

curl -I "$MATOMO_URL/matomo.js"
curl -I "$MATOMO_URL/matomo.php"
</syntaxhighlight>

'''Note :''' selon le comportement du serveur, une requête HEAD peut ne pas produire le même résultat qu'une requête GET. Pour vérifier précisément les codes HTTP :

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

L'installation de Matomo ne garantit pas à elle seule que les applications transmettent leurs visites. Cette vérification relève des chapitres d'intégration.

== 9. Intégration aux applications ==

=== Drupal ===

Voir [[Matomo/Drupal]] pour :

* L'installation du module Drupal Matomo
* La configuration de l'identifiant du site
* L'adresse HTTPS du serveur Matomo
* Les exclusions des pages d'administration
* Les vérifications de collecte

=== Pleade ===

Voir [[Matomo/Pleade]].

=== Suivi IIIF et événements ===

* [[Matomo/IIIF]]
* [[Matomo/Evenements]]

== 10. Sécurité et maintenance ==

Après installation, vérifier :

* Que l'interface d'administration Matomo n'est accessible qu'aux utilisateurs ou réseaux autorisés
* Que les points de collecte nécessaires restent accessibles aux visiteurs
* Que le certificat HTTPS est valide
* Que les sauvegardes couvrent la base MariaDB et la configuration Matomo
* Que les mises à jour de sécurité sont suivies

Voir :

* [[Matomo/HAProxy]]
* [[Matomo/Maintenance]]
* [[Matomo/Debug]]

== 11. Installations de référence ==

{| class="wikitable"
! Projet
! Serveur
! Domaine Matomo
! Particularités
|-
| AD64
| ad64
| ad64-matomo.pleade.com
| Matomo 5.10.1 ; deux Drupal suivis séparément
|-
| APBP2
| À compléter
| apbp2-matomo.pleade.com
| Publication via HAProxy avec restriction de l'administration
|-
| MERCURE3
| À compléter
| mercure3-matomo.pleade.com
| Accès restreint à AJLSM
|}

Les paramètres propres à chaque client (domaines, adresses IP, identifiants Matomo, backends HAProxy) ne doivent pas être intégrés directement dans les commandes génériques.

Matomo/Installation

2026-10-20T10:14:34Z

Jlarvers :

AJLSM-DEPLOY — Version 1.0.2

2026-10-19T07:36:46Z

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

= 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

2026-10-19T07:35:35Z

Jlarvers :

Déploiement technique d’une VM AJLSM

2026-10-19T07:35:05Z

Jlarvers :

Déploiement technique d’une VM AJLSM

2026-10-16T16:40:28Z

Jlarvers : /* 11.3. Page man */

Déploiement technique d’une VM AJLSM

2026-10-16T16:39:39Z

Jlarvers : /* 11.3. Page man */

Déploiement technique d’une VM AJLSM

2026-10-16T16:38:39Z

Jlarvers : /* 11.3. Page man */

Déploiement technique d’une VM AJLSM

2026-10-16T16:37:31Z

Jlarvers : /* 11.3. Page man */

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

Document consolidé au 16 octobre 2026. Cette procédure réunit la page du 15 octobre et la recette actuelle. Elle remplace leurs indications opérationnelles divergentes. L’original du 15 octobre reste archivé séparément.

Référence technique : 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.

Voici un exemple :
<syntaxhighlight lang="yaml">projet:
code: mercure3
nom: MERCURE3
environnement: interne

proxmox:
serveur: Saturne3
template_vmid: 506
vmid: null
nom_vm: MERCURE3

cpu:
sockets: 1
cores: 8

memoire:
maximale_mib: 24576
minimale_mib: 16384

disque_systeme:
stockage: local-zfs
taille_gib: 100
etendre_volume_racine: true

demarrage_auto: true

tags:
- interne

systeme:
hostname: mercure3.ajlsm.com

reseau:
interfaces:
- nom: net0
bridge: vmbr2
systeme: ens18
ipv4: 10.0.0.43/24

- nom: net1
bridge: vmbr1
systeme: ens19
ipv4: 192.168.123.27/24

loopback:
ipv4: 51.83.117.113/32

passerelle:
ipv4: 10.0.0.4
interface: ens18

dns:
- 10.0.0.4
</syntaxhighlight>

=== 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.
<syntaxhighlight lang="yaml"># Préconfiguration AJLSM vierge : aucune valeur d’infrastructure préremplie.
# Compléter avec ajlsm-deploy-yaml ; ne pas déployer ce modèle tel quel.
# null = champ à renseigner, SAUF proxmox.vmid où null = attribution automatique.
# Les crochets [à renseigner] sont interdits : ils représenteraient une liste YAML.
# Deux interfaces sont proposées : adapter leur nombre avant la saisie.
projet:
code: null # Obligatoire : minuscules/chiffres, tiret et souligné ; ex. mercure3.
nom: null # Obligatoire : nom lisible du projet.
environnement: null # Liste fermée : interne, client, prod.

proxmox:
serveur: null # Obligatoire : nom du nœud Proxmox, ex. Saturne3.
template_vmid: null # Obligatoire : entier positif, VM modèle existante et arrêtée.
vmid: null # Automatique ; sinon entier positif différent de template_vmid.
nom_vm: null # Obligatoire : nom de VM, lettres/chiffres/point/tiret.
cpu:
sockets: null # Obligatoire : entier positif.
cores: null # Obligatoire : entier positif ; vCPU = sockets × cores.
memoire:
maximale_mib: null # Obligatoire : entier positif, en Mio.
minimale_mib: null # Obligatoire : entier positif, inférieur ou égal au maximum.
disque_systeme:
stockage: null # Obligatoire : identifiant de stockage Proxmox existant.
taille_gib: null # Obligatoire : entier positif en Gio ; aucune réduction de disque.
etendre_volume_racine: null # Obligatoire : true ou false ; active la phase racine.
demarrage_auto: null # Obligatoire : true ou false ; appliqué à l’activation réseau.
tags: null # Obligatoire : liste ; interne/client/prod uniquement, sans doublons ; [] admis.

systeme:
hostname: null # Obligatoire : nom DNS en minuscules ; vérifier sa déclaration en amont.

reseau:
interfaces:
- nom: null # Obligatoire : net suivi de chiffres, conforme à la VM modèle.
bridge: null # Obligatoire : bridge existant, au plus 15 caractères.
systeme: null # Obligatoire : ens suivi de chiffres, conforme au modèle actuel.
ipv4: null # Obligatoire : IPv4/CIDR, ex. 10.0.0.43/24 ; adresse unique.
- nom: null
bridge: null
systeme: null
ipv4: null
loopback:
ipv4: null # Obligatoire : IPv4 avec préfixe /32, distincte des interfaces.
passerelle:
ipv4: null # Obligatoire : IPv4 seule, dans le sous-réseau de son interface.
interface: null # Obligatoire : un des noms systeme déclarés ci-dessus.
dns: null # Obligatoire : liste non vide d’IPv4 sans préfixe, ex. [10.0.0.4].
</syntaxhighlight>

=== 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. Protections et détails techniques ==

=== 10.1. Isolation, identité et journal de personnalisation ===

Le clone est arrêté après création, avec onboot désactivé et les interfaces isolées. Le premier démarrage s’effectue dans cet état d’isolation. Les phases système et réseau vérifient l’identité de la cible et l’UUID attendu selon leurs contrôles propres.

La personnalisation système conserve dans l’invité :
<syntaxhighlight lang="text">
/var/lib/ajlsm/system-personalisation/state.json
/var/lib/ajlsm/system-personalisation/backup/
</syntaxhighlight>

Ce journal décrit la transaction d’identité, pas l’ensemble du cycle. Ne pas le supprimer pour forcer une nouvelle exécution. Après interruption, conserver les sauvegardes et examiner l’état réel avant reprise.

La VM 515 est signalée comme hors périmètre par la documentation historique. Elle ne fait pas partie de la recette MERCURE3 et ne doit pas être ciblée par cette procédure.

=== 10.2. Audit SSH : lecture dans la VM, écriture possible sur Saturne3 ===

La phase --ssh-audit commence par synchroniser l’identité SSH :
# Lire la clé publique /etc/ssh/ssh_host_ed25519_key.pub dans la VM via l’agent QEMU.
# Valider le format ED25519 et sa structure binaire attendue.
# Lire indépendamment la clé exposée sur le réseau avec ssh-keyscan -T 8 -t ed25519.
# Comparer les clés : une divergence, une absence ou un format invalide provoque un refus.
# Après concordance seulement, sauvegarder /root/.ssh/known_hosts sur Saturne3, travailler sur une copie et remplacer le fichier avec la nouvelle entrée vérifiée pour l’IP cible.
# Contrôler les connexions par clé, les clés autorisées, sudo et l’état du compte ajlsm.

Les autres entrées d’hôtes sont conservées ; le traitement retire aussi les anciennes entrées hachées correspondant à l’IP cible. Les sauvegardes utilisent le préfixe known_hosts.ajlsm-backup. dans /root/.ssh/.

'''L’audit n’est donc pas entièrement sans écriture :''' ses lectures dans la VM sont accompagnées d’une mise à jour possible de known_hosts sur Saturne3. Ne jamais contourner une divergence en effaçant aveuglément known_hosts.

=== 10.3. Sécurisation SSH et mot de passe ===

--ssh-secure effectue un audit préalable, prépare un fichier SSH dédié, vérifie la syntaxe et les valeurs effectives, puis recharge SSH. Il désactive l’authentification SSH par mot de passe et conserve root par clé. Les connexions root et ajlsm par clé sont revérifiées par le code reçu.

Le mot de passe local ajlsm reste utile pour sudo. --password-ajlsm utilise un terminal interactif et lance passwd dans la VM, avec sa double saisie masquée. Le secret n’est pas inscrit dans le YAML ni dans la ligne de commande. La procédure historique prévoit un report manuel dans le registre ODS d’administration ; appliquer les règles internes de gestion des secrets. Ne pas joindre ce registre à une documentation publique.

=== 10.4. Certificat TLS interne et Apache ===

--tls-apply lit le certificat /etc/ssl/ajlsm/server.crt. Si le CN et le SAN correspondent déjà au hostname attendu, la phase termine sans réinitialisation. Sinon, après confirmation, elle appelle /usr/local/sbin/ajlsm-init-tls.sh '''dans la VM'''. Ce dernier script doit être présent dans le modèle ; son contenu n’était pas inclus dans l’archive des scripts de déploiement reçue.

Après une initialisation réussie, le module contrôle le certificat, apache2ctl configtest et systemctl is-active apache2. Ce contrôle technique d’Apache ne constitue pas une recette des VirtualHosts et des applications du projet.

La documentation historique désigne /home/ajlsm/README, hérité de TEMPLATE3, comme README applicatif Pleade/Drupal. Le conserver séparément du README-ajlsm-deploy de l’outil de déploiement ; ne pas remplacer l’un par l’autre.

=== 10.5. Attente réseau au premier démarrage ===

La recette du 15 octobre signalait environ 60 secondes d’attente dans systemd-networkd-wait-online lorsque les interfaces étaient isolées. Ce constat historique n’a pas empêché l’agent QEMU ni ajlsm-clone-init de répondre. Une optimisation éventuelle du modèle reste distincte du déploiement ; ne pas désactiver le service sans vérifier ses dépendances.

== 11. Maintenance, sauvegardes et manuel ==

=== 11.1. Identifier les fichiers réellement exécutés ===

La recette du 16 octobre utilise le dossier /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/. Elle ne démontre pas une mise à jour globale de /usr/local/sbin/. Toujours distinguer le lot validé et les programmes installés.

Dans le dossier de recette :
<syntaxhighlight lang="bash">
./ajlsm-deploy --help
./ajlsm-deploy-cycle --help
./ajlsm-deploy-yaml --help
python3 -m py_compile ajlsm-deploy ajlsm-deploy-check ajlsm-deploy-resources ajlsm-deploy-cycle ajlsm-deploy-yaml ajlsm_deploy_common.py ajlsm_deploy_rootgrow.py ajlsm_deploy_postconfig.py
</syntaxhighlight>

Une compilation vérifie la syntaxe, pas le bon déroulement d’une phase ni les prérequis serveur.

=== 11.2. Sauvegarder et restaurer un lot cohérent ===

Conserver ensemble programmes, modules et configuration de référence. Sauvegarder le lot complet avant une installation ou une correction. Exemple sur Saturne3 :
<syntaxhighlight lang="bash">
tar -czf "/root/ajlsm-deploy/archives/lot-recette-$(date +%Y%m%d-%H%M%S).tar.gz" \
-C /root/ajlsm-deploy/recettes/20261016 ajlsm-deploy-cycle
</syntaxhighlight>

Une restauration doit porter sur un ensemble compatible. Ne pas réinstaller uniquement ajlsm-deploy.bak-20261015 : ce fichier peut précéder les modules et phases nécessaires. L’ancienne sauvegarde et les répertoires de revue sont des références historiques à inventorier avant nettoyage.

Ne pas supprimer INSTRUCTIONS-TEST.txt ou d’autres fichiers de /root/ajlsm-deploy-review/ sur la seule base de l’ancienne page. Leur archivage et le nettoyage ne font pas partie de cette mise à jour documentaire.

=== 11.3. Page man ===

La page du 15 octobre indique un manuel installé en /usr/local/man/man8/ajlsm-deploy.8 et une sauvegarde hors man8 dans /root/ajlsm-deploy-review/sauvegardes-man/. Ce sont des informations historiques, dont l’état actuel n’a pas été vérifié pendant la recette du 16 octobre.

Pour identifier la page disponible sur Saturne3 :
<syntaxhighlight lang="bash">
man -w ajlsm-deploy
man 8 ajlsm-deploy
</syntaxhighlight>

Une page absente ne signifie pas que le script est absent : --help est l’aide intégrée de l’exécutable. Le manuel installé doit être réconcilié avec le cycle et l’assistant avant d’être considéré comme référence de cette version. En attendant, le présent guide et l’aide des fichiers du lot de recette décrivent le fonctionnement courant.
<syntaxhighlight lang="bash">Last login: Fri Oct 16 15:21:06 on ttys000
jlarvers@MacBook-Pro ~ % ssh saturne3
Linux Saturne3 7.0.14-23-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.14-23 (2026-10-07T20:25Z) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Oct 16 09:46:02 2026 from 109.190.129.96
root@Saturne3:~# qm status 505
qm config 505
status: running
agent: 1
balloon: 16384
boot: order=scsi0;net0
cores: 8
cpu: x86-64-v2-AES
memory: 24576
meta: creation-qemu=11.0.0,ctime=1779439732
name: MERCURE3
net0: virtio=BC:24:11:D5:B4:C2,bridge=vmbr2,firewall=1,link_down=0
net1: virtio=BC:24:11:E8:F0:BD,bridge=vmbr1,firewall=1,link_down=0
numa: 0
onboot: 1
ostype: l26
scsi0: local-zfs:vm-505-disk-0,iothread=1,size=100G
scsihw: virtio-scsi-single
smbios1: uuid=f47653e5-e87f-4765-bd41-46bb2eaac990
sockets: 1
tags: interne
vmgenid: d0cfe3f4-9292-4c03-81d9-662131e54889
root@Saturne3:~# qm set 505 --onboot 0
qm shutdown 505 --timeout 120
qm status 505
update VM 505: -onboot 0
status: stopped
root@Saturne3:~# PROJET_YAML=/etc/ajlsm/deploy/projets/mercure3.yaml
root@Saturne3:~# ./ajlsm-deploy "$PROJET_YAML" --clone
-bash: ./ajlsm-deploy: No such file or directory
root@Saturne3:~# history
1 Ne pas lancer toutes les phases dans un script ou une chaîne de
2 commandes.
3 PHASE 1 - CLONAGE
4 Simulation :
5 ajlsm-deploy "$PROJET" --dry-run
6 Clonage :
7 ajlsm-deploy "$PROJET" --clone
8 Le clone est créé sans démarrage.
9 Vérifier le VMID réellement attribué.
10 PHASE 2 - CONFIGURATION DES RESSOURCES
11 Simulation :
12 ajlsm-deploy "$PROJET" --resources-dry-run
13 Application :
14 ajlsm-deploy "$PROJET" --configure-resources
15 Configuration des ressources CPU, RAM et disque.
16 L'agrandissement du disque Proxmox ne suffit pas à agrandir le
17 système de fichiers à l'intérieur de la VM.
18 PHASE 3 - PREMIER DEMARRAGE ISOLE
19 Simulation :
20 ajlsm-deploy "$PROJET" --first-boot-dry-run
21 Application :
22 ajlsm-deploy "$PROJET" --first-boot-apply
23 Le clone démarre avec ses interfaces réseau isolées.
24 Le programme contrôle notamment l'agent QEMU et l'initialisation
25 du clone.
26 Ne pas activer manuellement les interfaces réseau.
27 PHASE 4 - EXTENSION DU VOLUME RACINE
28 Simulation :
29 ajlsm-deploy "$PROJET" --root-grow-dry-run
30 Application :
31 ajlsm-deploy "$PROJET" --root-grow-apply
32 Cette phase étend la partition, le volume LVM et le système de
33 fichiers ext4 selon la configuration prévue.
34 Elle doit être effectuée après le premier démarrage et avant la
35 personnalisation système.
36 En cas d'erreur, ne pas poursuivre sans diagnostic.
37 PHASE 5 - PERSONNALISATION SYSTEME
38 Simulation :
39 ajlsm-deploy "$PROJET" --system-dry-run
40 Application :
41 ajlsm-deploy "$PROJET" --system-apply
42 Personnalisation de l'identité système, notamment du hostname
43 et du machine-id.
44 La VM reste isolée du réseau.
45 Les informations de transaction sont conservées dans :
46 /var/lib/ajlsm/system-personalisation/
47 Ne pas supprimer ces informations pour forcer une nouvelle opération.
48 PHASE 6 - CONFIGURATION NETPLAN
49 Simulation :
50 ajlsm-deploy "$PROJET" --network-dry-run
51 Application :
52 ajlsm-deploy "$PROJET" --network-apply
53 Préparation de Netplan et vérification de sa génération.
54 Les interfaces Proxmox restent isolées.
55 PHASE 7 - ACTIVATION DU RESEAU
56 Simulation :
57 ajlsm-deploy "$PROJET" --network-enable-dry-run
58 Application :
59 ajlsm-deploy "$PROJET" --network-enable
60 Avant activation, le programme effectue les contrôles prévus,
61 notamment la recherche de conflits d'adresses IPv4 par ARP.
62 Après activation, vérifier :
63 - Les adresses IPv4.
64 - La route par défaut.
65 - La passerelle.
66 - Les DNS.
67 - L'adresse loopback, si elle est configurée.
68 - Le paramètre onboot de la VM.
69 Le mécanisme de repli en cas d'échec réseau reste à valider
70 par un test réel de panne.
71 PHASE 8 - AUDIT SSH
72 ajlsm-deploy "$PROJET" --ssh-audit
73 Avant l'audit SSH, le programme synchronise l'identification
74 du serveur dans /root/.ssh/known_hosts sur Saturne3.
75 Il compare :
76 - La clé publique ED25519 obtenue directement dans la VM
77 via l'agent QEMU.
78 - La clé ED25519 présentée sur le réseau via ssh-keyscan.
79 Si les clés diffèrent, l'opération est refusée.
80 Si elles correspondent, known_hosts peut être actualisé après
81 sauvegarde.
82 L'audit ne modifie pas la configuration SSH de la VM.
83 ATTENTION :
84 Bien que l'audit soit sans modification de la configuration SSH
85 invitée, la synchronisation préalable peut modifier le fichier
86 known_hosts de Saturne3.
87 PHASE 9 - SECURISATION SSH
88 ajlsm-deploy "$PROJET" --ssh-secure
89 Cette phase désactive l'authentification SSH par mot de passe
90 et conserve l'accès root par clé publique.
91 Vérifier impérativement les accès par clé avant de confirmer.
92 Après application, refaire un audit :
93 ajlsm-deploy "$PROJET" --ssh-audit
94 PHASE 10 - MOT DE PASSE DU COMPTE AJLSM
95 ajlsm-deploy "$PROJET" --password-ajlsm
96 Le mot de passe est demandé interactivement avec double saisie.
97 Ne pas inscrire de mot de passe dans le YAML ou dans une commande.
98 PHASE 11 - CERTIFICAT TLS INTERNE
99 ajlsm-deploy "$PROJET" --tls-apply
100 Initialisation ou vérification du certificat TLS interne.
101 Vérifier le résultat et le fonctionnement du service concerné.
102 6. VERIFICATIONS FINALES
103 ------------------------
104 Sur Saturne3, avec le VMID réellement attribué :
105 qm status VMID
106 qm config VMID
107 Dans la VM :
108 hostnamectl
109 ip -br addr
110 ip route
111 resolvectl status
112 Pour vérifier le volume racine :
113 lsblk
114 df -hT /
115 pvs
116 vgs
117 lvs
118 Pour vérifier SSH depuis Saturne3 :
119 ssh root@ADRESSE_IP_VM
120 Adapter VMID et ADRESSE_IP_VM au projet.
121 Ne jamais accepter aveuglément une empreinte SSH différente.
122 7. CONFIRMATIONS ET CODES DE RETOUR
123 -----------------------------------
124 Chaque modification nécessite une confirmation.
125 La réponse par défaut est NON.
126 Respecter la confirmation réellement demandée par la version
127 installée du programme.
128 Codes de retour :
129 0 : succès
130 1 : annulation
131 2 : erreur
132 Une erreur impose un diagnostic avant de poursuivre.
133 8. REPRISE APRES INCIDENT
134 -------------------------
135 En cas d'échec :
136 1. Ne pas lancer la phase suivante.
137 2. Conserver la sortie complète du programme.
138 3. Vérifier le VMID et l'identité de la VM.
139 4. Contrôler son état dans Proxmox.
140 5. Vérifier que le réseau est toujours isolé si nécessaire.
141 6. Examiner les sauvegardes et informations de transaction.
142 7. Corriger la cause avant de reprendre.
143 Ne jamais supprimer une VM pour recommencer sans avoir vérifié
144 son identité et ses données.
145 Ne jamais modifier manuellement known_hosts pour contourner
146 une erreur de correspondance de clés SSH.
147 9. MAINTENANCE DES SCRIPTS
148 --------------------------
149 Vérifier la syntaxe Python :
150 python3 -m py_compile \
151 /usr/local/sbin/ajlsm-deploy \
152 /usr/local/sbin/ajlsm_deploy_rootgrow.py \
153 /usr/local/sbin/ajlsm_deploy_postconfig.py
154 Les trois scripts forment un ensemble cohérent.
155 Effectuer une sauvegarde avant toute modification.
156 Ne pas restaurer un module isolément sans vérifier sa
157 compatibilité avec les autres.
158 10. ETAT DES VALIDATIONS AU 15 OCTOBRE 2026
159 -------------------------------------------
160 Recette MERCURE3 :
161 - Clonage depuis TEMPLATE3.
162 - Configuration des ressources.
163 - Premier démarrage isolé.
164 - Personnalisation système.
165 - Configuration Netplan.
166 - Contrôle ARP.
167 - Activation réseau.
168 - Vérifications réseau.
169 Tests fonctionnels isolés du 15 octobre :
170 - Validation de la comparaison des clés ED25519.
171 - Acceptation de deux clés identiques.
172 - Refus de clés différentes.
173 - Refus de clés malformées.
174 - Préservation de known_hosts en cas de refus.
175 - Conservation des autres entrées de known_hosts.
176 - Compilation Python des trois scripts.
177 Restent à confirmer lors d'un déploiement complet avec les
178 dernières versions des scripts :
179 - Extension du volume racine.
180 - Enchaînement complet des phases.
181 - Synchronisation SSH avec une nouvelle VM réelle.
182 - Sécurisation SSH et postconfiguration.
183 - Repli en cas d'échec réseau.
184 11. PRECAUTIONS
185 ---------------
186 TEMPLATE3 : VMID 506, modèle de clonage.
187 MERCURE3 : VMID 505, VM utilisée pour la recette.
188 Ces identifiants ne doivent jamais être réutilisés aveuglément.
189 La VM 515 est indépendante de cette procédure et ne doit pas
190 être modifiée.
191 Le README applicatif présent sur TEMPLATE3 et MERCURE3 ne doit
192 pas être remplacé par ce document.
193 12. DOCUMENTATION COMPLEMENTAIRE
194 --------------------------------
195 Aide rapide :
196 ajlsm-deploy --help
197 Manuel système :
198 man ajlsm-deploy
199 Documentation technique complète :
200 AJLSM-DEPLOY - Déploiement automatisé des VM Proxmox
201 (documentation MediaWiki AJLSM)
202 Le manuel et la documentation MediaWiki doivent être maintenus
203 en cohérence avec les scripts.
204 FIN DU README
205 =============
206 FIN_README
207 chmod 644 /usr/local/sbin/README-ajlsm-deploy; echo "README créé : /usr/local/sbin/README-ajlsm-deploy"; fi
208 ls -l /usr/local/sbin/README-ajlsm-deploy
209 head -20 /usr/local/sbin/README-ajlsm-deploy
210 ls -l /usr/local/sbin/README-ajlsm-deploy
211 head -20 /usr/local/sbin/README-ajlsm-deploy
212 vim /usr/local/sbin/README-ajlsm-deploy
213 man -w ajlsm-deploy
214 cat /usr/local/man/man8/ajlsm-deploy.8
215 python3 - <<'PY'
216 from pathlib import Path
217 from datetime import datetime
218 import shutil
219 path = Path("/usr/local/man/man8/ajlsm-deploy.8")
220 original = path.read_text(encoding="utf-8")
221 updated = original
222 old_audit = r""".TP
223 .B \-\-ssh-audit
224 Contrôler en lecture seule les empreintes de clés autorisées, la configuration
225 SSH, sudo et l'accès par clé au compte ajlsm.
226 """
227 new_audit = r""".TP
228 .B \-\-ssh-audit
229 Identifier la VM Proxmox concernée, synchroniser sa clé d'hôte SSH ED25519
230 dans /root/.ssh/known_hosts sur Saturne3, puis contrôler les clés autorisées,
231 la configuration SSH, sudo et l'accès par clé au compte ajlsm.
232 .PP
233 Avant l'audit, la clé publique ED25519 est récupérée directement dans
234 l'invité via l'agent QEMU, puis comparée à la clé présentée sur le réseau
235 par ssh-keyscan. La structure de la clé est vérifiée. Une clé malformée,
236 une divergence ou une récupération impossible provoque un refus.
237 .PP
238 Lorsque les clés correspondent, le programme peut actualiser
239 /root/.ssh/known_hosts après sauvegarde. Les anciennes entrées associées
240 à l'adresse IP, y compris les entrées hachées, sont supprimées de la copie
241 de travail avant insertion de la clé vérifiée. Les autres entrées sont
242 conservées. Le remplacement est atomique.
243 .PP
244 L'audit de la configuration SSH dans l'invité est en lecture seule,
245 mais la synchronisation préalable peut modifier known_hosts sur Saturne3.
246 """
247 old_examples = r"""\&./ajlsm-deploy projet-test.yaml --root-grow-apply
248 \&./ajlsm-deploy projet-test.yaml --ssh-audit
249 \&./ajlsm-deploy projet-test.yaml --ssh-secure
250 \&./ajlsm-deploy projet-test.yaml --password-ajlsm
251 \&./ajlsm-deploy projet-test.yaml --tls-apply
252 \&./ajlsm-deploy projet-test.yaml --system-dry-run
253 \&./ajlsm-deploy projet-test.yaml --system-apply
254 \&./ajlsm-deploy projet-test.yaml --network-dry-run
255 \&./ajlsm-deploy projet-test.yaml --network-apply
256 \&./ajlsm-deploy projet-test.yaml --network-enable-dry-run
257 \&./ajlsm-deploy projet-test.yaml --network-enable
258 """
259 new_examples = r"""\&./ajlsm-deploy projet-test.yaml --root-grow-apply
260 \&./ajlsm-deploy projet-test.yaml --system-dry-run
261 \&./ajlsm-deploy projet-test.yaml --system-apply
262 \&./ajlsm-deploy projet-test.yaml --network-dry-run
263 \&./ajlsm-deploy projet-test.yaml --network-apply
264 \&./ajlsm-deploy projet-test.yaml --network-enable-dry-run
265 \&./ajlsm-deploy projet-test.yaml --network-enable
266 \&./ajlsm-deploy projet-test.yaml --ssh-audit
267 \&./ajlsm-deploy projet-test.yaml --ssh-secure
268 \&./ajlsm-deploy projet-test.yaml --ssh-audit
269 \&./ajlsm-deploy projet-test.yaml --password-ajlsm
270 \&./ajlsm-deploy projet-test.yaml --tls-apply
271 """
272 old_limit = r"""L'absence de réponse ARP ne garantit pas qu'une IP est libre, et ne
273 remplace
274 pas l'inventaire réseau. Le repli réseau nécessite
275 une recette sur une VM dédiée.
276 """
277 new_limit = r"""L'absence de réponse ARP ne garantit pas qu'une IP est libre, et ne
278 remplace
279 pas l'inventaire réseau. Le repli réseau nécessite
280 une recette sur une VM dédiée.
281 .PP
282 La synchronisation des clés SSH a été validée par tests fonctionnels
283 isolés le 15 octobre 2026 : clés concordantes, divergentes et malformées,
284 préservation de known_hosts en cas de refus. Elle reste à confirmer
285 lors d'un nouveau déploiement complet sur une VM réelle.
286 """
287 replacements = [
288 ("section SSH", old_audit, new_audit),
289 ("ordre des exemples", old_examples, new_examples),
290 ("limites et validation", old_limit, new_limit),
291 ]
292 for label, old, new in replacements:
293 count = updated.count(old)
294 if count != 1:
295 raise SystemExit(
296 f"ERREUR : section '{label}' trouvée {count} fois. "
297 "Aucune modification effectuée."
298 )
299 updated = updated.replace(old, new, 1)
300 backup = path.with_name(
301 path.name + ".bak-" + datetime.now().strftime("%Y%m%d-%H%M%S")
302 )
303 shutil.copy2(path, backup)
304 path.write_text(updated, encoding="utf-8")
305 print("Manuel actualisé :", path)
306 print("Sauvegarde :", backup)
307 print("Sections modifiées : SSH, exemples, limites.")
308 PY
309 man 8 ajlsm-deploy
310 man 8 ajlsm-deploy | col -b | grep -n -E 'known_hosts|ssh-keyscan|ED25519|déploiement complet'
311 mkdir -p /root/ajlsm-deploy-review/sauvegardes-man
312 mv /usr/local/man/man8/ajlsm-deploy.8.bak-20261015-235157 /root/ajlsm-deploy-review/sauvegardes-man/
313 man 8 ajlsm-deploy >/dev/null
314 echo "=== INTERFACES RESEAU ==="
315 ip -br -4 addr
316 echo
317 echo "=== ROUTE VERS EOLE3 ==="
318 ip route get 192.168.123.202
319 ip route get 51.178.110.230
320 echo
321 echo "=== MONTAGES NFS ==="
322 findmnt -t nfs,nfs4 -o SOURCE,TARGET,FSTYPE,OPTIONS
323 echo
324 echo "=== CONNEXIONS ACTIVES VERS EOLE3 ==="
325 ss -tn state established | grep -E '192\.168\.123\.202|51\.178\.110\.230' || true
326 echo
327 echo "=== STOCKAGES PROXMOX ==="
328 pvesm status
329 echo "=== REFERENCES A EOLE3 DANS LES TACHES CRON ==="
330 grep -RInE 'eole3|51\.178\.110\.230|192\.168\.123\.202' /etc/cron.d /etc/crontab /var/spool/cron/crontabs 2>/dev/null || true
331 echo
332 echo "=== REFERENCES A EOLE3 DANS LES SCRIPTS LOCAUX ==="
333 grep -RInE 'eole3|51\.178\.110\.230|192\.168\.123\.202' /usr/local/sbin /usr/local/bin 2>/dev/null | head -60
334 echo
335 echo "=== TIMERS SYSTEMD ==="
336 systemctl list-timers --all --no-pager
337 exit
338 qm status 505
339 qm config 505
340 qm set 505 --onboot 0
341 qm shutdown 505 --timeout 120
342 qm status 505
343 PROJET_YAML=/etc/ajlsm/deploy/projets/mercure3.yaml
344 ./ajlsm-deploy "$PROJET_YAML" --clone
345 history
root@Saturne3:~# cd /usr/local/sbin
root@Saturne3:/usr/local/sbin# ls -la
total 216
drwxr-xr-x 3 root root 4096 Oct 15 23:50 .
drwxr-xr-x 11 root root 4096 Mar 27 2026 ..
-rw-r--r-- 1 root root 10453 Oct 15 23:44 README-ajlsm-deploy
drwxr-xr-x 2 root root 4096 Oct 15 23:26 __pycache__
-rwxr-x--- 1 root root 66119 Oct 15 23:17 ajlsm-deploy
-rwxr-xr-x 1 root root 11954 Oct 15 21:41 ajlsm-deploy-check
-rwxr-xr-x 1 root root 6874 Oct 15 21:41 ajlsm-deploy-resources
-rwxr-xr-x 1 root root 2945 Oct 15 11:19 ajlsm-deploy.avant-clonage
-rwxr-xr-x 1 root root 10383 Oct 15 12:05 ajlsm-deploy.avant-first-boot
-rwxr-xr-x 1 root root 9664 Oct 15 11:51 ajlsm-deploy.avant-integration-ressources
-rwxr-x--- 1 root root 18851 Oct 15 12:51 ajlsm-deploy.bak-20261015
-rw-r--r-- 1 root root 10349 Oct 15 21:41 ajlsm_deploy_common.py
-rw-r--r-- 1 root root 9595 Oct 15 23:26 ajlsm_deploy_postconfig.py
-rw-r--r-- 1 root root 6192 Oct 15 22:14 ajlsm_deploy_rootgrow.py
-rwx------ 1 root root 863 Apr 20 11:03 backup_pbs_saturne3.sh
-rwx------ 1 root root 5289 Oct 14 12:55 supervision_rapport.sh
-rwxr-x--- 1 root root 4112 Oct 14 12:23 supervision_updates.sh
-rw-r--r-- 1 root root 1673 Oct 13 17:15 supervision_updates_collect.py
root@Saturne3:/usr/local/sbin# ./ajlsm-deploy "$PROJET_YAML" --clone

=== PRÉCONTRÔLES ===
[OK] Configuration YAML chargée

=== CONTRÔLES PROXMOX ===
[OK] VM source 506 présente
[OK] VM source 506 arrêtée
[OK] QEMU Guest Agent activé dans la configuration
[OK] Disque source scsi0 : 32 Gio
[OK] Prochain VMID proposé : 511 (non réservé)
[OK] CPU : 1 socket(s) × 8 cœur(s) = 8 vCPU
[OK] RAM : 16384 à 24576 Mio
[OK] Stockage local-zfs actif
[OK] Disque demandé : 100 Gio
[OK] Tags : interne

=== CONTRÔLES RÉSEAU ===
[OK] Bridge vmbr2 présent
[OK] net0 / ens18 : 10.0.0.43/24
[OK] Bridge vmbr1 présent
[OK] net1 / ens19 : 192.168.123.27/24
[OK] IP loopback : 51.83.117.113/32
[OK] Passerelle : 10.0.0.4 via ens18
[OK] DNS : 10.0.0.4
[AVERTISSEMENT] Disponibilité réelle des IP non vérifiée sur le réseau

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

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --dry-run

[ERREUR] Une VM nommée MERCURE3 existe déjà :
VMID 505 : stopped
root@Saturne3:/usr/local/sbin# qm destroy 505
qm config 505
Configuration file 'nodes/Saturne3/qemu-server/505.conf' does not exist
root@Saturne3:/usr/local/sbin# ./ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --clone

=== PRÉCONTRÔLES ===
[OK] Configuration YAML chargée

=== CONTRÔLES PROXMOX ===
[OK] VM source 506 présente
[OK] VM source 506 arrêtée
[OK] QEMU Guest Agent activé dans la configuration
[OK] Disque source scsi0 : 32 Gio
[OK] Prochain VMID proposé : 505 (non réservé)
[OK] CPU : 1 socket(s) × 8 cœur(s) = 8 vCPU
[OK] RAM : 16384 à 24576 Mio
[OK] Stockage local-zfs actif
[OK] Disque demandé : 100 Gio
[OK] Tags : interne

=== CONTRÔLES RÉSEAU ===
[OK] Bridge vmbr2 présent
[OK] net0 / ens18 : 10.0.0.43/24
[OK] Bridge vmbr1 présent
[OK] net1 / ens19 : 192.168.123.27/24
[OK] IP loopback : 51.83.117.113/32
[OK] Passerelle : 10.0.0.4 via ens18
[OK] DNS : 10.0.0.4
[AVERTISSEMENT] Disponibilité réelle des IP non vérifiée sur le réseau

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

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --dry-run

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

Pour créer la VM 505, confirmer (OUI/NON) : oui

[ACTION] Clonage en cours...
[OK] VM 505 créée
[ACTION] Isolation de net0
[ACTION] Isolation de net1
[OK] Adresses MAC du clone distinctes de TEMPLATE3
[OK] Clone arrêté
[OK] Démarrage automatique désactivé
[OK] Toutes les interfaces réseau isolées

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

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --resources-dry-run
root@Saturne3:/usr/local/sbin# /usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --resources-dry-run

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

[DRY-RUN] Aucune modification effectuée.

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --configure-resources
root@Saturne3:/usr/local/sbin# /usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --configure-resources

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

Pour appliquer les ressources à la VM 505, confirmer (OUI/NON) : oui
[ACTION] CPU : 2 x 4 -> 1 x 8
[ACTION] RAM : 8192 -> 24576 Mio ; balloon : non défini -> 16384 Mio
[ACTION] Disque scsi0 : 32 -> 100 Gio

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

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --first-boot-dry-run
root@Saturne3:/usr/local/sbin# /usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --first-boot-apply

=== PREMIER DÉMARRAGE : MERCURE3 (VM 505) ===
[OK] Démarrage automatique désactivé, interfaces isolées
État actuel : stopped

Pour démarrer la VM 505 avec le réseau isolé, confirmer (OUI/NON) : oui
[ACTION] Démarrage de la VM 505 avec interfaces isolées
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
[OK] UUID matériel conforme : ab93f3d0-c137-428c-acad-81f3196329c6
[OK] Phase de premier démarrage validée ; interfaces toujours isolées

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --system-dry-run
root@Saturne3:/usr/local/sbin# /usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --system-dry-run
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
Cible : MERCURE3 VM505, UUID ab93f3d0-c137-428c-acad-81f3196329c6, hostname mercure3.ajlsm.com
État de reprise : nouvelle transaction
[DRY-RUN] Sauvegarder hostname, hosts et les deux machine-id dans l'invité
[DRY-RUN] Préparer une identité aléatoire persistante, puis redémarrer isolé
[DRY-RUN] Vérifier boot_id, identité PID1, hostname, hosts et isolation

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --system-apply
root@Saturne3:/usr/local/sbin# /usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --system-apply
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
Cible : MERCURE3 VM505, UUID ab93f3d0-c137-428c-acad-81f3196329c6, hostname mercure3.ajlsm.com
État de reprise : nouvelle transaction

Cible : VM505 — mercure3.ajlsm.com
Cette opération modifiera l’identité système et redémarrera la VM avec le réseau isolé.
Confirmer (OUI/NON) : oui
[ACTION] Identité disque préparée ; identité active non encore validée
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
[OK] Nouveau démarrage et identité active vérifiés ; VM505 toujours isolée

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --network-dry-run
root@Saturne3:/usr/local/sbin# /usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --network-dry
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
Cible : MERCURE3 VM505 ; reseau Proxmox isole
ens18: 10.0.0.43/24
ens19: 192.168.123.27/24
lo: 51.83.117.113/32 ; passerelle: 10.0.0.4 (ens18) ; DNS: 10.0.0.4
[DRY-RUN] Sauvegarder le Netplan initial, ecrire la configuration et executer netplan generate
[DRY-RUN] Aucune modification ni activation reseau
[OK] Déploiement terminé ; procéder aux vérifications finales du manuel.
root@Saturne3:/usr/local/sbin# /usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --network-apply
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
Cible : MERCURE3 VM505 ; reseau Proxmox isole
ens18: 10.0.0.43/24
ens19: 192.168.123.27/24
lo: 51.83.117.113/32 ; passerelle: 10.0.0.4 (ens18) ; DNS: 10.0.0.4
Cette operation remplace Netplan dans l'invite, sans activer les interfaces Proxmox.
Confirmer (OUI/NON) : oui
[OK] Netplan ecrit et netplan generate valide : {"changed": true, "backup": true}
[OK] VM505 toujours isolee ; aucune activation des liens

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --network-enable-dry-run
root@Saturne3:/usr/local/sbin# /usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --network-enable
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
[OK] ARP DAD 10.0.0.43 sur vmbr2 (aucune reponse)
[OK] ARP DAD 192.168.123.27 sur vmbr1 (aucune reponse)
[OK] VM505 UUID=ab93f3d0-c137-428c-acad-81f3196329c6, clone et Netplan valides, reseau isole
Activer le reseau de cette VM (OUI/NON) : oui
[OK] ARP DAD 10.0.0.43 sur vmbr2 (aucune reponse)
[OK] ARP DAD 192.168.123.27 sur vmbr1 (aucune reponse)
[OK] Adresses, loopback, route, DNS et ping passerelle valides
[OK] VM505 : reseau actif et controle, onboot conforme au YAML

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --ssh-audit
root@Saturne3:/usr/local/sbin# /usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --ssh-audit
[OK] Clé ED25519 vérifiée via QEMU : 10.0.0.43
[OK] known_hosts actualisé avec sauvegarde conservée
=== Contrôle SSH, sans modification ===
Identité : mercure3.ajlsm.com

Clés autorisées ajlsm :
4096 SHA256:zGdW2VjyzL/p30BjtNy6dzXIahBWTH9djZLc62IKCAk siva@MacBook-Pro-de-Sivakavi.local (RSA)
256 SHA256:lVtwxE0No+RZNyOXpf64JBCnMYIk9YaMw43clCV92hk jlarvers@MacBook-Pro.lan (ED25519)
256 SHA256:HAHGVQ2Afy6vGJpLhJ2vftXonwV31QNOiFHH6t5BfB4 modou-mbp (ED25519)

Configuration effective SSH :
permitrootlogin prohibit-password
pubkeyauthentication yes
passwordauthentication yes
kbdinteractiveauthentication no

Règles sudo pour ajlsm :
User ajlsm may run the following commands on mercure3.ajlsm.com:
(ALL : ALL) ALL

Etat du mot de passe ajlsm :
ajlsm P 2026-05-22 0 99999 7 -1
[OK] Connexion ajlsm par clé vérifiée.

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --ssh-secure
root@Saturne3:/usr/local/sbin# /usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --ssh-secure
=== Contrôle SSH, sans modification ===
Identité : mercure3.ajlsm.com

Clés autorisées ajlsm :
4096 SHA256:zGdW2VjyzL/p30BjtNy6dzXIahBWTH9djZLc62IKCAk siva@MacBook-Pro-de-Sivakavi.local (RSA)
256 SHA256:lVtwxE0No+RZNyOXpf64JBCnMYIk9YaMw43clCV92hk jlarvers@MacBook-Pro.lan (ED25519)
256 SHA256:HAHGVQ2Afy6vGJpLhJ2vftXonwV31QNOiFHH6t5BfB4 modou-mbp (ED25519)

Configuration effective SSH :
permitrootlogin prohibit-password
pubkeyauthentication yes
passwordauthentication yes
kbdinteractiveauthentication no

Règles sudo pour ajlsm :
User ajlsm may run the following commands on mercure3.ajlsm.com:
(ALL : ALL) ALL

Etat du mot de passe ajlsm :
ajlsm P 2026-05-22 0 99999 7 -1
[OK] Connexion ajlsm par clé vérifiée.
Appliquer PasswordAuthentication no et root par clé seulement [oui/non] : oui
[OK] SSH sécurisé ; root reste autorisé par clé.
[OK] Connexions root et ajlsm par clé toujours fonctionnelles.

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --password-ajlsm
root@Saturne3:/usr/local/sbin# /usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --password-ajlsm
Ouvrir passwd ajlsm sur MERCURE3 [oui/non] : oui
Le mot de passe sera demandé deux fois par passwd sur la VM.
Il ne sera pas enregistré dans le script. Le reporter manuellement dans le fichier ODS.
New password:
Retype new password:
passwd: password updated successfully
Connection to 10.0.0.43 closed.
[OK] Mot de passe ajlsm modifié ; vérifier ensuite sudo -i depuis ajlsm.

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --tls-apply
root@Saturne3:/usr/local/sbin# /usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --tls-apply
mercure3.ajlsm.com
subject=CN=clone-ab93f3d0-c13.internal
X509v3 Subject Alternative Name:
DNS:clone-ab93f3d0-c13.internal

Initialiser le certificat TLS interne [oui/non] : oui
Initialisation TLS pour : mercure3.ajlsm.com
....++++++++++++++++++++++++++++++++++++++++++*..+...++++++++++++++++++++++++++++++++++++++++++*........+............+...+.............+..+.......+.....................+..+............+.+.....+.+...+..+.+...+...........+.+...............+..............+.........+....+.....+.+.........+....................+...+..........+..............+.+.....+...+++++
...........+..+...+.............+.....+....+..+......+.........+......+.......++++++++++++++++++++++++++++++++++++++++++*.........++++++++++++++++++++++++++++++++++++++++++*....................+................+...+......+.....+....+.....+.........+...+....+...+..+..........+.........+.........+..+....+++++
-----
Syntax OK

Initialisation TLS terminée.
Sauvegarde : /etc/ssl/ajlsm/backup.8vB54QHP
subject=CN=mercure3.ajlsm.com
notBefore=Oct 16 13:54:38 2026 GMT
notAfter=Oct 13 13:54:38 2036 GMT
subject=CN=mercure3.ajlsm.com
X509v3 Subject Alternative Name:
DNS:mercure3.ajlsm.com
active

[OK] Phases techniques terminées ; les opérations applicatives seront traitées séparément.
root@Saturne3:/usr/local/sbin#
root@Saturne3:/usr/local/sbin#
root@Saturne3:/usr/local/sbin#
root@Saturne3:/usr/local/sbin#
root@Saturne3:/usr/local/sbin#
root@Saturne3:/usr/local/sbin#
root@Saturne3:/usr/local/sbin#
root@Saturne3:/usr/local/sbin#
root@Saturne3:/usr/local/sbin#
root@Saturne3:/usr/local/sbin# ssh ajlsm@10.0.0.43
sudo -i
hostname
lsblk
df -hT /
Welcome to Ubuntu 26.04.1 LTS (GNU/Linux 7.0.0-38-generic x86_64)

* Documentation: https://docs.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/pro

System information as of Fri Oct 16 03:56:00 PM CEST 2026

System load: 0.35 Processes: 190
Usage of /: 54.2% of 14.66GB Users logged in: 0
Memory usage: 3% IPv4 address for ens18: 10.0.0.43
Swap usage: 0%

* Canonical Workshop gives developers fast, composable, reproducible, and
secure developer environments that are perfect for agentic workflows.

https://ubuntu.com/workshop

Expanded Security Maintenance for Applications is not enabled.

1 update can be applied immediately.
To see these additional updates run: apt list --upgradable

9 additional security updates can be applied with ESM Apps.
Learn more about enabling ESM Apps service at https://ubuntu.com/esm

You have new mail.
Last login: Thu Oct 15 08:18:27 2026 from 10.40.0.2
ajlsm@mercure3:~$ sudo -i
[sudo: authenticate] Password:
root@mercure3:~# hostname
lsblk
df -hT /
mercure3.ajlsm.com
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 100G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 2G 0 part /boot
└─sda3 8:3 0 30G 0 part
└─ubuntu--vg-ubuntu--lv 252:0 0 15G 0 lvm /
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv ext4 15G 8.0G 6.0G 58% /
root@mercure3:~# pvs
vgs
lvs -o lv_path,lv_size,vg_name
findmnt -no SOURCE,FSTYPE /
command -v growpart
PV VG Fmt Attr PSize PFree
/dev/sda3 ubuntu-vg lvm2 a-- <30.00g 15.00g
VG #PV #LV #SN Attr VSize VFree
ubuntu-vg 1 1 0 wz--n- <30.00g 15.00g
Path LSize VG
/dev/ubuntu-vg/ubuntu-lv <15.00g ubuntu-vg
/dev/mapper/ubuntu--vg-ubuntu--lv ext4
/usr/bin/growpart
root@mercure3:~#
root@mercure3:~# lsblk
pvs
vgs
df -hT /
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 100G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 2G 0 part /boot
└─sda3 8:3 0 30G 0 part
└─ubuntu--vg-ubuntu--lv 252:0 0 15G 0 lvm /
PV VG Fmt Attr PSize PFree
/dev/sda3 ubuntu-vg lvm2 a-- <30.00g 15.00g
VG #PV #LV #SN Attr VSize VFree
ubuntu-vg 1 1 0 wz--n- <30.00g 15.00g
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv ext4 15G 8.0G 6.0G 58% /
root@mercure3:~# growpart /dev/sda 3
CHANGED: partition=3 start=4198400 old: size=62908416 end=67106815 new: size=205516767 end=209715166
root@mercure3:~# /usr/local/sbin/ajlsm-deploy --help
-bash: /usr/local/sbin/ajlsm-deploy: No such file or directory
root@mercure3:~# exit
logout
ajlsm@mercure3:~$ exit
logout
Connection to 10.0.0.43 closed.
root@Saturne3:~# /usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --root-grow-apply
=== EXTENSION RACINE : VM 505 (APPLY) ===
Étendre la partition, le LVM et ext4 de la VM 505 [OUI/NON] : oui
[ETAT] {"disk_bytes": 107374182400, "grow_partition": false, "lv": "/dev/ubuntu-vg/ubuntu-lv", "partition_free_bytes_approx": 16896, "pv": "/dev/sda3", "root": "/dev/mapper/ubuntu--vg-ubuntu--lv ext4", "vg": "ubuntu-vg", "vg_free_bytes": 89120571392}
[ACTION] pvresize /dev/sda3
[ACTION] lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
[OK] Extension racine vérifiée : Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv ext4 97G 8.0G 85G 9% /

Commande suggérée (à lancer manuellement) :
/usr/local/sbin/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --system-apply
[OK] Déploiement terminé ; procéder aux vérifications finales du manuel.
root@Saturne3:~# Read from remote host 141.95.206.118: Connection reset by peer
Connection to 141.95.206.118 closed.
client_loop: send disconnect: Broken pipe
jlarvers@MacBook-Pro ~ % ssh saturne3
Linux Saturne3 7.0.14-23-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.14-23 (2026-10-07T20:25Z) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Oct 16 16:02:53 2026 from 109.190.129.96
root@Saturne3:~# ls -la
total 208
drwx------ 9 root root 4096 Oct 16 16:44 .
drwxr-xr-x 18 root root 4096 Apr 1 2026 ..
-rw------- 1 root root 14581 Oct 16 16:36 .bash_history
-rw-r--r-- 1 root root 607 Mar 2 2026 .bashrc
drwxr-xr-x 3 root root 4096 Apr 2 2026 .cache
drwx------ 5 root root 4096 Apr 20 10:28 .config
-rw-r--r-- 1 root root 35 Apr 30 11:01 .forward
-rw------- 1 root root 28 Oct 15 23:52 .lesshst
drwxr-xr-x 3 root root 4096 Apr 1 2026 .local
-rw-r--r-- 1 root root 50 Apr 1 2026 .ovhrc
-rw------- 1 root root 37 Apr 20 11:05 .pbs_token_saturne3
-rw-r--r-- 1 root root 132 Mar 2 2026 .profile
-rw------- 1 root root 1024 Apr 1 2026 .rnd
-rw-r--r-- 1 root root 75 Apr 20 10:24 .selected_editor
drwx------ 2 root root 4096 Oct 16 15:53 .ssh
-rw------- 1 root root 16696 Oct 15 23:50 .viminfo
-rw-r--r-- 1 root root 32718 Oct 16 16:06 ajlsm-deploy-actuel.tar.gz
-rw-r--r-- 1 root root 46186 Oct 16 16:44 ajlsm-deploy-cycle.zip
drwxr-x--- 8 root root 4096 Oct 15 23:53 ajlsm-deploy-review
-rw------- 1 root root 161 Apr 2 2026 dead.letter
drwxr-xr-x 6 root root 4096 Oct 14 13:16 export-supervision-svn
-rw-r--r-- 1 root root 12216 Oct 15 23:52 'm-deploy | col -b | grep -n -E '
-rw-r--r-- 1 root root 4680 Oct 14 13:19 supervision-ajlsm-2026-10-14.tar.gz
drwxr-xr-x 2 root root 4096 Oct 13 17:15 supervision-test
root@Saturne3:~# mkdir -p /root/ajlsm-deploy/archives
mkdir -p /root/ajlsm-deploy/recettes/20261016

mv /root/ajlsm-deploy-actuel.tar.gz /root/ajlsm-deploy/archives/
mv /root/ajlsm-deploy-cycle.zip /root/ajlsm-deploy/archives/

unzip /root/ajlsm-deploy/archives/ajlsm-deploy-cycle.zip \
-d /root/ajlsm-deploy/recettes/20261016

cd /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle
chmod 750 ajlsm-deploy ajlsm-deploy-check ajlsm-deploy-resources ajlsm-deploy-cycle
-bash: unzip: command not found
-bash: cd: /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle: No such file or directory
chmod: cannot access 'ajlsm-deploy-check': No such file or directory
chmod: cannot access 'ajlsm-deploy-resources': No such file or directory
chmod: cannot access 'ajlsm-deploy-cycle': No such file or directory
root@Saturne3:~# mkdir -p /root/ajlsm-deploy/archives
mkdir -p /root/ajlsm-deploy/recettes/20261016

mv /root/ajlsm-deploy-actuel.tar.gz /root/ajlsm-deploy/archives/
mv /root/ajlsm-deploy-cycle.zip /root/ajlsm-deploy/archives/

unzip /root/ajlsm-deploy/archives/ajlsm-deploy-cycle.zip \
-d /root/ajlsm-deploy/recettes/20261016

cd /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle
chmod 750 ajlsm-deploy ajlsm-deploy-check ajlsm-deploy-resources ajlsm-deploy-cycle
mv: cannot stat '/root/ajlsm-deploy-actuel.tar.gz': No such file or directory
mv: cannot stat '/root/ajlsm-deploy-cycle.zip': No such file or directory
-bash: unzip: command not found
-bash: cd: /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle: No such file or directory
chmod: cannot access 'ajlsm-deploy-check': No such file or directory
chmod: cannot access 'ajlsm-deploy-resources': No such file or directory
chmod: cannot access 'ajlsm-deploy-cycle': No such file or directory
root@Saturne3:~# python3 -m zipfile -e \
/root/ajlsm-deploy/archives/ajlsm-deploy-cycle.zip \
/root/ajlsm-deploy/recettes/20261016 &&
cd /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle &&
chmod 750 ajlsm-deploy ajlsm-deploy-check ajlsm-deploy-resources ajlsm-deploy-cycle &&
./ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3.yaml --plan

=== ÉTAPE 1/11 : clonage ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --clone --agent-timeout 300

=== ÉTAPE 2/11 : ressources ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --configure-resources --agent-timeout 300

=== ÉTAPE 3/11 : premier-demarrage ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --first-boot-apply --agent-timeout 300

=== ÉTAPE 4/11 : extension-racine ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --root-grow-apply --agent-timeout 300

=== ÉTAPE 5/11 : identite ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --system-apply --agent-timeout 300

=== ÉTAPE 6/11 : netplan ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --network-apply --agent-timeout 300

=== ÉTAPE 7/11 : activation-reseau ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --network-enable --agent-timeout 300

=== ÉTAPE 8/11 : audit-ssh ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --ssh-audit --agent-timeout 300

=== ÉTAPE 9/11 : securisation-ssh ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --ssh-secure --agent-timeout 300

=== ÉTAPE 10/11 : mot-de-passe ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --password-ajlsm --agent-timeout 300

=== ÉTAPE 11/11 : tls ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --tls-apply --agent-timeout 300

[PLAN] Aucune phase exécutée.
root@Saturne3:~/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle#
root@Saturne3:~/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle#
root@Saturne3:~/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle# qm config 505
agent: 1
balloon: 16384
boot: order=scsi0;net0
cores: 8
cpu: x86-64-v2-AES
memory: 24576
meta: creation-qemu=11.0.0,ctime=1779439732
name: MERCURE3
net0: virtio=BC:24:11:F6:BC:A4,bridge=vmbr2,firewall=1,link_down=0
net1: virtio=BC:24:11:A5:17:8E,bridge=vmbr1,firewall=1,link_down=0
numa: 0
onboot: 1
ostype: l26
scsi0: local-zfs:vm-505-disk-0,iothread=1,size=100G
scsihw: virtio-scsi-single
smbios1: uuid=ab93f3d0-c137-428c-acad-81f3196329c6
sockets: 1
tags: interne
vmgenid: d71326df-130f-4394-bd68-6f8c493047e1
root@Saturne3:~/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle# qm set 505 --onboot 0 &&
qm shutdown 505 --timeout 120 &&
qm destroy 505 &&
./ajlsm-deploy-cycle /etc/ajlsm/deploy/projets/mercure3.yaml
update VM 505: -onboot 0

=== ÉTAPE 1/11 : clonage ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --clone --agent-timeout 300

=== PRÉCONTRÔLES ===
[OK] Configuration YAML chargée

=== CONTRÔLES PROXMOX ===
[OK] VM source 506 présente
[OK] VM source 506 arrêtée
[OK] QEMU Guest Agent activé dans la configuration
[OK] Disque source scsi0 : 32 Gio
[OK] Prochain VMID proposé : 505 (non réservé)
[OK] CPU : 1 socket(s) × 8 cœur(s) = 8 vCPU
[OK] RAM : 16384 à 24576 Mio
[OK] Stockage local-zfs actif
[OK] Disque demandé : 100 Gio
[OK] Tags : interne

=== CONTRÔLES RÉSEAU ===
[OK] Bridge vmbr2 présent
[OK] net0 / ens18 : 10.0.0.43/24
[OK] Bridge vmbr1 présent
[OK] net1 / ens19 : 192.168.123.27/24
[OK] IP loopback : 51.83.117.113/32
[OK] Passerelle : 10.0.0.4 via ens18
[OK] DNS : 10.0.0.4
[AVERTISSEMENT] Disponibilité réelle des IP non vérifiée sur le réseau

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

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

Pour créer la VM 505, confirmer (OUI/NON) : oui

[ACTION] Clonage en cours...
[OK] VM 505 créée
[ACTION] Isolation de net0
[ACTION] Isolation de net1
[OK] Adresses MAC du clone distinctes de TEMPLATE3
[OK] Clone arrêté
[OK] Démarrage automatique désactivé
[OK] Toutes les interfaces réseau isolées

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

=== ÉTAPE 2/11 : ressources ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --configure-resources --agent-timeout 300

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

Pour appliquer les ressources à la VM 505, confirmer (OUI/NON) : oui
[ACTION] CPU : 2 x 4 -> 1 x 8
[ACTION] RAM : 8192 -> 24576 Mio ; balloon : non défini -> 16384 Mio
[ACTION] Disque scsi0 : 32 -> 100 Gio

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

=== ÉTAPE 3/11 : premier-demarrage ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --first-boot-apply --agent-timeout 300

=== PREMIER DÉMARRAGE : MERCURE3 (VM 505) ===
[OK] Démarrage automatique désactivé, interfaces isolées
État actuel : stopped

Pour démarrer la VM 505 avec le réseau isolé, confirmer (OUI/NON) : oui
[ACTION] Démarrage de la VM 505 avec interfaces isolées
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
[OK] UUID matériel conforme : 89aea8cb-9fd5-4b3b-9e06-a80cfa014f5b
[OK] Phase de premier démarrage validée ; interfaces toujours isolées

=== ÉTAPE 4/11 : extension-racine ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --root-grow-apply --agent-timeout 300
=== EXTENSION RACINE : VM 505 (APPLY) ===
Étendre la partition, le LVM et ext4 de la VM 505 [OUI/NON] : oui
[ETAT] {"disk_bytes": 107374182400, "grow_partition": true, "lv": "/dev/ubuntu-vg/ubuntu-lv", "partition_free_bytes_approx": 73015492608, "pv": "/dev/sda3", "root": "/dev/mapper/ubuntu--vg-ubuntu--lv ext4", "vg": "ubuntu-vg", "vg_free_bytes": 16106127360}
[ACTION] growpart /dev/sda 3
[ACTION] pvresize /dev/sda3
[ACTION] lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
[OK] Extension racine vérifiée : Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv ext4 97G 8.0G 85G 9% /

=== ÉTAPE 5/11 : identite ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --system-apply --agent-timeout 300
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
Cible : MERCURE3 VM505, UUID 89aea8cb-9fd5-4b3b-9e06-a80cfa014f5b, hostname mercure3.ajlsm.com
État de reprise : nouvelle transaction

Cible : VM505 — mercure3.ajlsm.com
Cette opération modifiera l’identité système et redémarrera la VM avec le réseau isolé.
Confirmer (OUI/NON) : oui
[ACTION] Identité disque préparée ; identité active non encore validée
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
[OK] Nouveau démarrage et identité active vérifiés ; VM505 toujours isolée

=== ÉTAPE 6/11 : netplan ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --network-apply --agent-timeout 300
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
Cible : MERCURE3 VM505 ; reseau Proxmox isole
ens18: 10.0.0.43/24
ens19: 192.168.123.27/24
lo: 51.83.117.113/32 ; passerelle: 10.0.0.4 (ens18) ; DNS: 10.0.0.4
Cette operation remplace Netplan dans l'invite, sans activer les interfaces Proxmox.
Confirmer (OUI/NON) : oui
[OK] Netplan ecrit et netplan generate valide : {"changed": true, "backup": true}
[OK] VM505 toujours isolee ; aucune activation des liens

=== ÉTAPE 7/11 : activation-reseau ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --network-enable --agent-timeout 300
[OK] Agent QEMU disponible
[OK] ajlsm-clone-init terminé avec succès
[OK] ARP DAD 10.0.0.43 sur vmbr2 (aucune reponse)
[OK] ARP DAD 192.168.123.27 sur vmbr1 (aucune reponse)
[OK] VM505 UUID=89aea8cb-9fd5-4b3b-9e06-a80cfa014f5b, clone et Netplan valides, reseau isole
Activer le reseau de cette VM (OUI/NON) : oui
[OK] ARP DAD 10.0.0.43 sur vmbr2 (aucune reponse)
[OK] ARP DAD 192.168.123.27 sur vmbr1 (aucune reponse)
[OK] Adresses, loopback, route, DNS et ping passerelle valides
[OK] VM505 : reseau actif et controle, onboot conforme au YAML

=== ÉTAPE 8/11 : audit-ssh ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --ssh-audit --agent-timeout 300
[OK] Clé ED25519 vérifiée via QEMU : 10.0.0.43
[OK] known_hosts actualisé avec sauvegarde conservée
=== Contrôle SSH, sans modification ===
Identité : mercure3.ajlsm.com

Clés autorisées ajlsm :
4096 SHA256:zGdW2VjyzL/p30BjtNy6dzXIahBWTH9djZLc62IKCAk siva@MacBook-Pro-de-Sivakavi.local (RSA)
256 SHA256:lVtwxE0No+RZNyOXpf64JBCnMYIk9YaMw43clCV92hk jlarvers@MacBook-Pro.lan (ED25519)
256 SHA256:HAHGVQ2Afy6vGJpLhJ2vftXonwV31QNOiFHH6t5BfB4 modou-mbp (ED25519)

Configuration effective SSH :
permitrootlogin prohibit-password
pubkeyauthentication yes
passwordauthentication yes
kbdinteractiveauthentication no

Règles sudo pour ajlsm :
User ajlsm may run the following commands on mercure3.ajlsm.com:
(ALL : ALL) ALL

Etat du mot de passe ajlsm :
ajlsm P 2026-05-22 0 99999 7 -1
[OK] Connexion ajlsm par clé vérifiée.

=== ÉTAPE 9/11 : securisation-ssh ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --ssh-secure --agent-timeout 300
=== Contrôle SSH, sans modification ===
Identité : mercure3.ajlsm.com

Clés autorisées ajlsm :
4096 SHA256:zGdW2VjyzL/p30BjtNy6dzXIahBWTH9djZLc62IKCAk siva@MacBook-Pro-de-Sivakavi.local (RSA)
256 SHA256:lVtwxE0No+RZNyOXpf64JBCnMYIk9YaMw43clCV92hk jlarvers@MacBook-Pro.lan (ED25519)
256 SHA256:HAHGVQ2Afy6vGJpLhJ2vftXonwV31QNOiFHH6t5BfB4 modou-mbp (ED25519)

Configuration effective SSH :
permitrootlogin prohibit-password
pubkeyauthentication yes
passwordauthentication yes
kbdinteractiveauthentication no

Règles sudo pour ajlsm :
User ajlsm may run the following commands on mercure3.ajlsm.com:
(ALL : ALL) ALL

Etat du mot de passe ajlsm :
ajlsm P 2026-05-22 0 99999 7 -1
[OK] Connexion ajlsm par clé vérifiée.
Appliquer PasswordAuthentication no et root par clé seulement [oui/non] : oui
[OK] SSH sécurisé ; root reste autorisé par clé.
[OK] Connexions root et ajlsm par clé toujours fonctionnelles.

=== ÉTAPE 10/11 : mot-de-passe ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --password-ajlsm --agent-timeout 300
Ouvrir passwd ajlsm sur MERCURE3 [oui/non] : oui
Le mot de passe sera demandé deux fois par passwd sur la VM.
Il ne sera pas enregistré dans le script. Le reporter manuellement dans le fichier ODS.
New password:
Retype new password:
passwd: password updated successfully
Connection to 10.0.0.43 closed.
[OK] Mot de passe ajlsm modifié ; vérifier ensuite sudo -i depuis ajlsm.

=== ÉTAPE 11/11 : tls ===
/usr/bin/python3 /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy /etc/ajlsm/deploy/projets/mercure3.yaml --tls-apply --agent-timeout 300
mercure3.ajlsm.com
subject=CN=clone-89aea8cb-9fd.internal
X509v3 Subject Alternative Name:
DNS:clone-89aea8cb-9fd.internal

Initialiser le certificat TLS interne [oui/non] : oui
Initialisation TLS pour : mercure3.ajlsm.com
...+......+.+..+.......+...+.....+......++++++++++++++++++++++++++++++++++++++++++*.+....+...+..+......+.++++++++++++++++++++++++++++++++++++++++++*....+...............+.....+....+............+..+......+........................+.+.........+.....+......+....+...+++++
...+..........+...++++++++++++++++++++++++++++++++++++++++++*.+....+...+...+..............+............+.+........+.+...............+...........++++++++++++++++++++++++++++++++++++++++++*...+......+...+....+.................+....+..+...+....+.....+..........+......+.....................+...+...+.....+...+.+...+........+...+.......+..+..........+..+....+..+....+.........+...........+...................+......+.....+.............+..+.+...............+............+......+.....+.+.........+....................+.......+............+...+..+......+.+.........+..+.......+...+.................+.+.....+.+..............+.+...............+........+......+.........+.......+.....+....+..+.......+......+...........+...+......+.........+............+.+..+.......+......+.....+....+.....+.............+........+.........+.+............+......+.....+..........+......+.....+....+......+.....+.+...+..+............+......+......+....+...........+.+..+.+..............+............................+...+.....+.......+..+..........+.....+.......+....................+....+..+.......+..+....+.........+...........+.+.........+...........+....+.........+...........+..........+.....+......+.+.....+.......+..+......+...+++++
-----
Syntax OK

Initialisation TLS terminée.
Sauvegarde : /etc/ssl/ajlsm/backup.ZSmJKspN
subject=CN=mercure3.ajlsm.com
notBefore=Oct 16 14:58:53 2026 GMT
notAfter=Oct 13 14:58:53 2036 GMT
subject=CN=mercure3.ajlsm.com
X509v3 Subject Alternative Name:
DNS:mercure3.ajlsm.com
active

[OK] Cycle technique terminé ; procéder aux vérifications finales.
root@Saturne3:~/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle# ssh ajlsm@10.0.0.43
sudo -i
hostname
df -hT /
Welcome to Ubuntu 26.04.1 LTS (GNU/Linux 7.0.0-38-generic x86_64)

* Documentation: https://docs.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/pro

System information as of Fri Oct 16 05:00:42 PM CEST 2026

System load: 0.09 Processes: 193
Usage of /: 8.2% of 96.34GB Users logged in: 0
Memory usage: 3% IPv4 address for ens18: 10.0.0.43
Swap usage: 0%

* Canonical Workshop gives developers fast, composable, reproducible, and
secure developer environments that are perfect for agentic workflows.

https://ubuntu.com/workshop

Expanded Security Maintenance for Applications is not enabled.

1 update can be applied immediately.
To see these additional updates run: apt list --upgradable

9 additional security updates can be applied with ESM Apps.
Learn more about enabling ESM Apps service at https://ubuntu.com/esm

You have new mail.
Last login: Thu Oct 15 08:18:27 2026 from 10.40.0.2
ajlsm@mercure3:~$ sudo -i
[sudo: authenticate] Password:
root@mercure3:~# hostname
df -hT /
mercure3.ajlsm.com
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv ext4 97G 8.0G 85G 9% /
root@mercure3:~# exit
logout
ajlsm@mercure3:~$ exit
logout
Connection to 10.0.0.43 closed.
root@Saturne3:~# python3 -m zipfile -e \
/root/ajlsm-deploy/archives/ajlsm-deploy-assistant.zip \
/root/ajlsm-deploy/recettes/20261016
root@Saturne3:~# install -m 750 \
/root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-assistant/ajlsm-deploy-yaml \
/root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy-yaml
root@Saturne3:~# cd /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle &&
./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3.yaml --check
[OK] Valeurs YAML valides. Aucun fichier modifié, aucun contrôle d’infrastructure effectué.
root@Saturne3:~/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle# ./ajlsm-deploy-yaml /etc/ajlsm/deploy/projets/mercure3.yaml --review \
--output /root/ajlsm-deploy/recettes/20261016/mercure3-relecture.yaml
Assistant local : ANNULER permet de quitter sans enregistrer.
Les commentaires du fichier source restent dans l’original ; la copie sera réécrite en YAML.

projet.code — texte obligatoire ; syntaxe : [a-z0-9][a-z0-9_-]*
Valeur actuelle : mercure3
Nouvelle valeur (Entrée = conserver) :

projet.nom — texte obligatoire
Valeur actuelle : MERCURE3
Nouvelle valeur (Entrée = conserver) :

projet.environnement — interne, client ou prod
Valeur actuelle : interne
Nouvelle valeur (Entrée = conserver) :

proxmox.serveur — texte obligatoire ; syntaxe : [A-Za-z0-9][A-Za-z0-9.-]*
Valeur actuelle : Saturne3
Nouvelle valeur (Entrée = conserver) :

proxmox.template_vmid — entier strictement positif
Valeur actuelle : 506
Nouvelle valeur (Entrée = conserver) :

proxmox.vmid — null ou auto = automatique ; sinon entier positif
Valeur actuelle : null
Nouvelle valeur (Entrée = conserver) :

proxmox.nom_vm — texte obligatoire ; syntaxe : [A-Za-z0-9][A-Za-z0-9.-]*
Valeur actuelle : MERCURE3
Nouvelle valeur (Entrée = conserver) :

proxmox.cpu.sockets — entier strictement positif
Valeur actuelle : 1
Nouvelle valeur (Entrée = conserver) :

proxmox.cpu.cores — entier strictement positif
Valeur actuelle : 8
Nouvelle valeur (Entrée = conserver) :

proxmox.memoire.maximale_mib — entier strictement positif
Valeur actuelle : 24576
Nouvelle valeur (Entrée = conserver) :

proxmox.memoire.minimale_mib — entier strictement positif
Valeur actuelle : 16384
Nouvelle valeur (Entrée = conserver) :

proxmox.disque_systeme.stockage — texte obligatoire ; syntaxe : [A-Za-z0-9][A-Za-z0-9_.-]*
Valeur actuelle : local-zfs
Nouvelle valeur (Entrée = conserver) :

proxmox.disque_systeme.taille_gib — entier strictement positif
Valeur actuelle : 100
Nouvelle valeur (Entrée = conserver) :

proxmox.disque_systeme.etendre_volume_racine — true ou false
Valeur actuelle : true
Nouvelle valeur (Entrée = conserver) :

proxmox.demarrage_auto — true ou false
Valeur actuelle : true
Nouvelle valeur (Entrée = conserver) :

proxmox.tags — interne, client, prod séparés par virgules ; [] = aucun
Valeur actuelle : [interne]
Nouvelle valeur (Entrée = conserver) :

systeme.hostname — nom DNS en minuscules
Valeur actuelle : mercure3.ajlsm.com
Nouvelle valeur (Entrée = conserver) :

reseau.interfaces[0].nom — texte obligatoire ; syntaxe : net[0-9]+
Valeur actuelle : net0
Nouvelle valeur (Entrée = conserver) :

reseau.interfaces[0].bridge — texte obligatoire ; syntaxe : [A-Za-z0-9_.-]{1,15}
Valeur actuelle : vmbr2
Nouvelle valeur (Entrée = conserver) :

reseau.interfaces[0].systeme — texte obligatoire ; syntaxe : ens[0-9]+
Valeur actuelle : ens18
Nouvelle valeur (Entrée = conserver) :

reseau.interfaces[0].ipv4 — IPv4/CIDR, ex. 10.0.0.43/24
Valeur actuelle : 10.0.0.43/24
Nouvelle valeur (Entrée = conserver) :

reseau.interfaces[1].nom — texte obligatoire ; syntaxe : net[0-9]+
Valeur actuelle : net1
Nouvelle valeur (Entrée = conserver) :

reseau.interfaces[1].bridge — texte obligatoire ; syntaxe : [A-Za-z0-9_.-]{1,15}
Valeur actuelle : vmbr1
Nouvelle valeur (Entrée = conserver) :

reseau.interfaces[1].systeme — texte obligatoire ; syntaxe : ens[0-9]+
Valeur actuelle : ens19
Nouvelle valeur (Entrée = conserver) :

reseau.interfaces[1].ipv4 — IPv4/CIDR, ex. 10.0.0.43/24
Valeur actuelle : 192.168.123.27/24
Nouvelle valeur (Entrée = conserver) :

reseau.loopback.ipv4 — IPv4/CIDR, ex. 10.0.0.43/24
Valeur actuelle : 51.83.117.113/32
Nouvelle valeur (Entrée = conserver) :

reseau.passerelle.ipv4 — IPv4 sans préfixe
Valeur actuelle : 10.0.0.4
Nouvelle valeur (Entrée = conserver) :

reseau.passerelle.interface — texte obligatoire ; syntaxe : ens[0-9]+
Valeur actuelle : ens18
Nouvelle valeur (Entrée = conserver) :

reseau.dns — IPv4 sans préfixes, séparées par virgules
Valeur actuelle : [10.0.0.4]
Nouvelle valeur (Entrée = conserver) :

=== PROJET PROPOSÉ ===
projet:
code: mercure3
nom: MERCURE3
environnement: interne
proxmox:
serveur: Saturne3
template_vmid: 506
vmid: null
nom_vm: MERCURE3
cpu:
sockets: 1
cores: 8
memoire:
maximale_mib: 24576
minimale_mib: 16384
disque_systeme:
stockage: local-zfs
taille_gib: 100
etendre_volume_racine: true
demarrage_auto: true
tags:
- interne
systeme:
hostname: mercure3.ajlsm.com
reseau:
interfaces:
- nom: net0
bridge: vmbr2
systeme: ens18
ipv4: 10.0.0.43/24
- nom: net1
bridge: vmbr1
systeme: ens19
ipv4: 192.168.123.27/24
loopback:
ipv4: 51.83.117.113/32
passerelle:
ipv4: 10.0.0.4
interface: ens18
dns:
- 10.0.0.4

[OK] Valeurs et cohérence YAML validées par le validateur du déploiement.
[NON VÉRIFIÉS] DNS, OPNsense, Ansible, objets Proxmox et disponibilité des IP.
Enregistrer la nouvelle copie dans /root/ajlsm-deploy/recettes/20261016/mercure3-relecture.yaml ? OUI/NON : oui
[ENREGISTRÉ] /root/ajlsm-deploy/recettes/20261016/mercure3-relecture.yaml
Contrôle Proxmox en lecture seule, à lancer sur le nœud cible avant un nouveau déploiement :
/root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle/ajlsm-deploy-check /root/ajlsm-deploy/recettes/20261016/mercure3-relecture.yaml
root@Saturne3:~/ajlsm-deploy/recettes/20261016/ajlsm-deploy-cycle# Read from remote host 141.95.206.118: Connection reset by peer
Connection to 141.95.206.118 closed.
client_loop: send disconnect: Broken pipe
jlarvers@MacBook-Pro ~ % ssh saturne3
Linux Saturne3 7.0.14-23-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.14-23 (2026-10-07T20:25Z) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Oct 16 16:43:10 2026 from 109.190.129.96
root@Saturne3:~# man -w ajlsm-deploy
/usr/local/man/man8/ajlsm-deploy.8
root@Saturne3:~# man -w ajlsm-deploy
/usr/local/man/man8/ajlsm-deploy.8
root@Saturne3:~# scp root@141.95.206.118:/usr/local/man/man8/ajlsm-deploy.8 ~/Downloads/ajlsm-deploy-existant.8
The authenticity of host '141.95.206.118 (141.95.206.118)' can't be established.
ED25519 key fingerprint is SHA256:GaOnRcly/RWj3rX8/2/Y/gdlagmDypNNvo0xRK1kQaE.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:21: [hashed name]
~/.ssh/known_hosts:26: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '141.95.206.118' (ED25519) to the list of known hosts.
scp: open local "/root/Downloads/ajlsm-deploy-existant.8": No such file or directory
root@Saturne3:~# python3 -m zipfile -e \
/root/ajlsm-deploy/archives/ajlsm-deploy-man.zip \
/root/ajlsm-deploy/recettes/20261016 &&
cd /root/ajlsm-deploy/recettes/20261016/ajlsm-deploy-man
root@Saturne3:~/ajlsm-deploy/recettes/20261016/ajlsm-deploy-man# SAUVEGARDE_MAN=$(mktemp -d /root/ajlsm-deploy/archives/man-avant-20261016.XXXXXX)

for NOM_MAN in ajlsm-deploy ajlsm-deploy-cycle ajlsm-deploy-yaml ajlsm-deploy-check ajlsm-deploy-resources; do
for SUFFIXE_MAN in .8 .8.gz; do
PAGE_MAN="/usr/local/man/man8/$NOM_MAN$SUFFIXE_MAN"
if [ -e "$PAGE_MAN" ] || [ -L "$PAGE_MAN" ]; then
cp -a "$PAGE_MAN" "$SAUVEGARDE_MAN/" || break 2
fi
done
done

printf 'Sauvegarde : %s\n' "$SAUVEGARDE_MAN"
Sauvegarde : /root/ajlsm-deploy/archives/man-avant-20261016.WiJHQn
root@Saturne3:~/ajlsm-deploy/recettes/20261016/ajlsm-deploy-man# install -d -m 755 /usr/local/man/man8

for NOM_MAN in ajlsm-deploy ajlsm-deploy-cycle ajlsm-deploy-yaml ajlsm-deploy-check ajlsm-deploy-resources; do
install -m 644 "man8/$NOM_MAN.8" "/usr/local/man/man8/$NOM_MAN.8" || break
done

if command -v mandb >/dev/null 2>&1; then
mandb
fi
Purging old database entries in /usr/share/man...
Processing manual pages under /usr/share/man...
Checking for stray cats under /usr/share/man...
Checking for stray cats under /var/cache/man...
Purging old database entries in /usr/share/man/pl...
Processing manual pages under /usr/share/man/pl...
Checking for stray cats under /usr/share/man/pl...
Checking for stray cats under /var/cache/man/pl...
Purging old database entries in /usr/share/man/ru...
Processing manual pages under /usr/share/man/ru...
Checking for stray cats under /usr/share/man/ru...
Checking for stray cats under /var/cache/man/ru...
Purging old database entries in /usr/share/man/id...
Processing manual pages under /usr/share/man/id...
Checking for stray cats under /usr/share/man/id...
Checking for stray cats under /var/cache/man/id...
Purging old database entries in /usr/share/man/es...
Processing manual pages under /usr/share/man/es...
Checking for stray cats under /usr/share/man/es...
Checking for stray cats under /var/cache/man/es...
Purging old database entries in /usr/share/man/zh_TW...
Processing manual pages under /usr/share/man/zh_TW...
Checking for stray cats under /usr/share/man/zh_TW...
Checking for stray cats under /var/cache/man/zh_TW...
Purging old database entries in /usr/share/man/sl...
Processing manual pages under /usr/share/man/sl...
Checking for stray cats under /usr/share/man/sl...
Checking for stray cats under /var/cache/man/sl...
Purging old database entries in /usr/share/man/pt...
Processing manual pages under /usr/share/man/pt...
Checking for stray cats under /usr/share/man/pt...
Checking for stray cats under /var/cache/man/pt...
Purging old database entries in /usr/share/man/hr...
Processing manual pages under /usr/share/man/hr...
Checking for stray cats under /usr/share/man/hr...
Checking for stray cats under /var/cache/man/hr...
Purging old database entries in /usr/share/man/pt_BR...
Processing manual pages under /usr/share/man/pt_BR...
Checking for stray cats under /usr/share/man/pt_BR...
Checking for stray cats under /var/cache/man/pt_BR...
Purging old database entries in /usr/share/man/hu...
Processing manual pages under /usr/share/man/hu...
Checking for stray cats under /usr/share/man/hu...
Checking for stray cats under /var/cache/man/hu...
Purging old database entries in /usr/share/man/da...
Processing manual pages under /usr/share/man/da...
Checking for stray cats under /usr/share/man/da...
Checking for stray cats under /var/cache/man/da...
Purging old database entries in /usr/share/man/cs...
Processing manual pages under /usr/share/man/cs...
Checking for stray cats under /usr/share/man/cs...
Checking for stray cats under /var/cache/man/cs...
Purging old database entries in /usr/share/man/tr...
Processing manual pages under /usr/share/man/tr...
Checking for stray cats under /usr/share/man/tr...
Checking for stray cats under /var/cache/man/tr...
Purging old database entries in /usr/share/man/fr...
Processing manual pages under /usr/share/man/fr...
Checking for stray cats under /usr/share/man/fr...
Checking for stray cats under /var/cache/man/fr...
Purging old database entries in /usr/share/man/nl...
Processing manual pages under /usr/share/man/nl...
Checking for stray cats under /usr/share/man/nl...
Checking for stray cats under /var/cache/man/nl...
Purging old database entries in /usr/share/man/ko...
Processing manual pages under /usr/share/man/ko...
Checking for stray cats under /usr/share/man/ko...
Checking for stray cats under /var/cache/man/ko...
Purging old database entries in /usr/share/man/zh_CN...
Processing manual pages under /usr/share/man/zh_CN...
Checking for stray cats under /usr/share/man/zh_CN...
Checking for stray cats under /var/cache/man/zh_CN...
Purging old database entries in /usr/share/man/sv...
Processing manual pages under /usr/share/man/sv...
Checking for stray cats under /usr/share/man/sv...
Checking for stray cats under /var/cache/man/sv...
Purging old database entries in /usr/share/man/ro...
Processing manual pages under /usr/share/man/ro...
Checking for stray cats under /usr/share/man/ro...
Checking for stray cats under /var/cache/man/ro...
Purging old database entries in /usr/share/man/uk...
Processing manual pages under /usr/share/man/uk...
Checking for stray cats under /usr/share/man/uk...
Checking for stray cats under /var/cache/man/uk...
Purging old database entries in /usr/share/man/sr...
Processing manual pages under /usr/share/man/sr...
Checking for stray cats under /usr/share/man/sr...
Checking for stray cats under /var/cache/man/sr...
Purging old database entries in /usr/share/man/ja...
Processing manual pages under /usr/share/man/ja...
Checking for stray cats under /usr/share/man/ja...
Checking for stray cats under /var/cache/man/ja...
Purging old database entries in /usr/share/man/de...
Processing manual pages under /usr/share/man/de...
Checking for stray cats under /usr/share/man/de...
Checking for stray cats under /var/cache/man/de...
Purging old database entries in /usr/share/man/fi...
Processing manual pages under /usr/share/man/fi...
Checking for stray cats under /usr/share/man/fi...
Checking for stray cats under /var/cache/man/fi...
Purging old database entries in /usr/share/man/it...
Processing manual pages under /usr/share/man/it...
Checking for stray cats under /usr/share/man/it...
Checking for stray cats under /var/cache/man/it...
Purging old database entries in /usr/local/man...
Processing manual pages under /usr/local/man...
Updating index cache for path `/usr/local/man/man8'. Wait...done.
Checking for stray cats under /usr/local/man...
Checking for stray cats under /var/cache/man/oldlocal...
1 man subdirectory contained newer manual pages.
5 manual pages were added.
0 stray cats were added.
0 old database entries were purged.
root@Saturne3:~/ajlsm-deploy/recettes/20261016/ajlsm-deploy-man# man -w ajlsm-deploy
man 8 ajlsm-deploy
man 8 ajlsm-deploy-cycle
man 8 ajlsm-deploy-yaml
/usr/local/man/man8/ajlsm-deploy.8

AJLSM-DEPLOY(8) Administration système AJLSM-DEPLOY(8)

NOM
ajlsm-deploy - déployer une VM Proxmox par phases contrôlées

SYNOPSIS
ajlsm-deploy projet.yaml PHASE [--agent-timeout secondes]
ajlsm-deploy-check projet.yaml [--phase proxmox] [--yaml-only]
ajlsm-deploy-resources projet.yaml (--dry-run | --apply)

DESCRIPTION
Programme à exécuter sur le nœud Proxmox cible, avec les droits administrateur. Chaque invocation traite une seule
phase. Le YAML est validé avant les commandes externes.

Après succès, les suggestions affichent les commandes de simulation et d'exécution de la prochaine étape, ou de l'étape
simulée. Les étapes sans simulation dédiée le signalent explicitement. Ces suggestions ne sont jamais exécutées au‐
tomatiquement. Elles décrivent l'ordre théorique, sans mémoriser l'état du cycle.

Pour enchaîner les onze étapes sans en oublier, utiliser ajlsm-deploy-cycle(8). Ce lanceur conserve les confirmations
et les saisies interactives.

ORDRE DES PHASES
1. --clone
Créer le clone complet, désactiver onboot, isoler les interfaces, vérifier l'arrêt et les adresses MAC. Aucun
démarrage. Simulation : --dry-run, qui comprend les précontrôles.

2. --configure-resources
Configurer et vérifier CPU, mémoire, balloon et disque scsi0. Exige une VM arrêtée, onboot désactivé et inter‐
faces isolées. La réduction du disque est interdite. Simulation : --resources-dry-run.

3. --first-boot-apply
Démarrer le clone isolé, attendre l'agent QEMU et ajlsm-clone-init, puis vérifier les identités attendues. Si
la VM tourne déjà, reprendre les contrôles sans redémarrage. Simulation : --first-boot-dry-run.

4. --root-grow-apply
Après le premier démarrage et avant la personnalisation système, étendre la partition, le PV LVM, le LV racine
et ext4. Cette étape dépend de etendre_volume_racine dans le YAML. Simulation : --root-grow-dry-run.

5. --system-apply
Personnaliser hostname, hosts et machine-id, redémarrer isolé et vérifier l'identité active. Respecter le jour‐
nal de transaction. Simulation : --system-dry-run.

6. --network-apply
Sauvegarder et écrire Netplan dans l'invité, puis exécuter netplan generate. Les liens Proxmox restent isolés.
Simulation : --network-dry-run.

7. --network-enable
Contrôler identité, configuration et conflits ARP, activer les liens, vérifier adresses, loopback, route, DNS et
passerelle, puis appliquer demarrage_auto. Un mécanisme de repli tente de rétablir l'isolation en cas d'échec.
Simulation : --network-enable-dry-run.

8. --ssh-audit
Comparer la clé ED25519 lue via QEMU à celle exposée sur le réseau, actualiser known_hosts après concordance,
puis vérifier les accès, clés autorisées, sudo et état du compte ajlsm. Aucune simulation dédiée.

9. --ssh-secure
Après audit et confirmation, désactiver l'authentification SSH par mot de passe, conserver root par clé, véri‐
fier la configuration, recharger SSH et contrôler les connexions root et ajlsm par clé. Aucune simulation
dédiée.

10. --password-ajlsm
Ouvrir passwd pour ajlsm dans la VM avec double saisie native masquée. Un terminal interactif est obligatoire.
Le mot de passe n'est pas placé dans le YAML ni la ligne de commande. Aucune simulation dédiée.

11. --tls-apply
Vérifier le certificat TLS interne. Si CN et SAN correspondent déjà au hostname, ne pas réinitialiser. Sinon,
après confirmation, appeler ajlsm-init-tls.sh dans la VM, puis vérifier certificat, syntaxe Apache et service
actif. Aucune simulation dédiée.

OPTIONS COMMUNES
--agent-timeout secondes
Entier strictement positif, défaut 300. Délai transmis aux attentes utilisant l'agent QEMU. Il ne constitue
Manual page ajlsm-deploy(8) line 1/219 32% (press h for help or q to quit)
</syntaxhighlight>

== 12. État des validations et limites ==

{| class="wikitable"
! Date / source !! Vérification !! Portée
|-
| 15/10/2026, page historique || Déploiements initiaux jusqu’à l’activation réseau || Résultats historiques conservés ; ne décrivent pas à eux seuls le cycle actuel
|-
| 15/10/2026, page historique || Comparaison ED25519, clés divergentes ou malformées, préservation de known_hosts || Tests isolés rapportés dans la documentation reçue, non rejoués lors de cette consolidation
|-
| 16/10/2026, tests locaux du lot cycle || Ordre des 11 étapes, arrêt sur refus/erreur, reprise et suggestions || 8 tests réussis, incluant des sous-cas ; sous-processus des phases simulés
|-
| 16/10/2026, sorties Saturne3 transmises || Cycle technique complet sur un nouveau clone MERCURE3 || Terminé sans erreur signalée, extension racine incluse
|-
| 16/10/2026, sorties invitées transmises || SSH ajlsm, sudo, hostname et racine ext4 || Confirmés ; mercure3.ajlsm.com et 97 Gio pour /
|-
| 16/10/2026, tests locaux assistant || Création, correction, copie, validation et annulation || 14 tests réussis, saisies simulées
|-
| 16/10/2026, sortie Saturne3 transmise || Assistant --check sur mercure3.yaml || Valeurs YAML valides ; aucune écriture ni validation externe
|-
| 16/10/2026, vérification locale des modèles || Modèle vierge complété par l’assistant || Paramètres identiques à la référence MERCURE3 ; original intact
|-
| À réaliser || Essai réel du mécanisme de repli après échec d’activation réseau || Non confirmé ; le succès du parcours nominal ne valide pas ce scénario
|-
| À réaliser || Vérifications automatiques DNS, OPNsense, Ansible et recette applicative || Hors périmètre actuel
|}

Le message de fin du cycle signifie que ses phases ont retourné un succès. Il ne vaut pas validation des applications ni détection de toutes les défaillances possibles. Conserver les vérifications finales et les limites propres aux phases.

== 13. Réconciliation avec la page du 15 octobre ==

L’original reçu est conservé intégralement dans historique/guide-20261015.mediawiki. Il sert de trace, pas de seconde procédure opérationnelle concurrente.

Le présent document remplace les indications opérationnelles anciennes :
* confirmations CLONER/APPLIQUER/DEMARRER remplacées par OUI/NON ;
* parcours manuel seul remplacé par le choix entre mode manuel et cycle interactif ;
* liste des étapes incluant l’extension racine, SSH, mot de passe et TLS ;
* extension racine et cycle complet désormais validés sur la recette du 16 octobre ;
* suggestions manuelles affichant les deux commandes disponibles, sans oublier l’extension racine ;
* création et relecture du YAML par l’assistant, sans écraser l’original ;
* ajout du modèle vierge et de la référence MERCURE3 renseignée ;
* séparation explicite des scripts installés, du lot de recette, du manuel historique et de la future installation.

Les détails encore utiles de l’ancienne page sur l’isolation, les transactions, ED25519, les sauvegardes, le README applicatif et les limites de validation sont repris ci-dessus. Une nouvelle mise à jour fonctionnelle doit modifier cette procédure directement plutôt que superposer une nouvelle section corrective à une ancienne procédure contradictoire.

== 14. 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.

[[Catégorie:Infrastructure]]
[[Catégorie:Proxmox]]
[[Catégorie:Déploiement]]
[[Catégorie:AJLSM]]

Déploiement technique d’une VM AJLSM

2026-10-16T16:21:51Z

Jlarvers : /* 5.2. Compléter le modèle vierge */

Déploiement technique d’une VM AJLSM

2026-10-16T16:21:09Z

Jlarvers : /* 5.1. Vérifier un fichier existant sans le modifier */

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

2026-10-16T16:18:24Z

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

Obsolète :

Voir [[Déploiement_technique_d’une_VM_AJLSM]]

Déploiement technique d’une VM AJLSM

2026-10-16T15:44:55Z

Jlarvers :

Déploiement technique d’une VM AJLSM

2026-10-16T15:37:53Z

Jlarvers : 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 ... »

= 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

2026-10-16T12:37:39Z

Jlarvers :

= EOLE3 — Accès, sécurité et pare-feu =
Voir aussi [[Eole3_–_Checklist_mensuelle_de_sécurité]] :

== 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é

2026-10-16T12:36:10Z

Jlarvers :

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

2026-10-16T12:35:47Z

Jlarvers :

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

2026-10-16T12:35:04Z

Jlarvers :

Obsolète :

Voir : http://mw.ajlsm.com/wiki/Eole3_%E2%80%93_Checklist_mensuelle_de_s%C3%A9curit%C3%A9

Eole3 – Checklist mensuelle de sécurité

2026-10-16T12:34:39Z

Jlarvers :

= EOLE3 — Checklist mensuelle de sécurité =

{{Sommaire}}

'''Serveur :''' EOLE3

'''Système :''' Ubuntu 24.04 LTS

'''Documentation de référence :''' [[EOLE3 — Accès, sécurité et pare-feu]]

== 1. Vérification du pare-feu ==

=== État du service ===

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

Attendu :

<syntaxhighlight lang="text">
active
enabled
</syntaxhighlight>

=== Tables nftables ===

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

Attendu :

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

=== Contrôle des règles ===

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

Vérifier :

* politique INPUT DROP ;
* ports publics 80, 443 et 2022 ;
* SSH limité aux IP administratives ;
* réseau vRack autorisé ;
* absence d'ouverture publique NFS, Cockpit ou Lighttpd.

== 2. Vérification Fail2ban ==

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

Vérifier :

* service actif ;
* jails réellement chargées ;
* adresses bannies ;
* absence de bannissement administratif inattendu.

== 3. Vérification SSH ==

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

Contrôler :

* les méthodes d'authentification ;
* les comptes administratifs ;
* les restrictions des comptes SFTP ;
* les nouvelles connexions depuis les adresses autorisées.

== 4. Vérification des services ==

<syntaxhighlight lang="bash">
systemctl --failed
systemctl status ssh fail2ban sftpgo apache2 --no-pager
</syntaxhighlight>

Contrôler également les services NFS, Lighttpd et de supervision selon leur configuration effective.

== 5. Vérification SFTPGo ==

<syntaxhighlight lang="bash">
systemctl status sftpgo --no-pager
journalctl -u sftpgo --since "1 month ago" --no-pager
</syntaxhighlight>

Rechercher :

* tentatives de connexion inhabituelles ;
* erreurs d'authentification ;
* téléchargements anormalement volumineux ;
* comptes inutilisés ;
* activités suspectes.

== 6. Vérification NFS ==

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

Vérifier :

* les clients autorisés ;
* les exports ;
* les droits d'accès ;
* le fonctionnement des montages depuis le vRack.

== 7. Vérification des ports en écoute ==

<syntaxhighlight lang="bash">
ss -tulpen
</syntaxhighlight>

Comparer les services en écoute avec les règles nftables.

'''Important :''' un service peut écouter sur une adresse publique tout en étant bloqué par le pare-feu.

Le contrôle des sockets ne remplace donc pas un test depuis Internet.

== 8. Vérification des journaux ==

<syntaxhighlight lang="bash">
journalctl -p err -b --no-pager
journalctl -u ajlsm-firewall.service --since "1 month ago" --no-pager
</syntaxhighlight>

Rechercher :

* erreurs système répétées ;
* redémarrages inattendus ;
* échecs de chargement nftables ;
* anomalies réseau.

== 9. Vérification ZFS ==

<syntaxhighlight lang="bash">
zpool status
zpool list
zfs list
df -h
</syntaxhighlight>

Vérifier :

* état ONLINE ;
* absence d'erreurs de lecture, écriture ou checksum ;
* capacité disponible ;
* résultats des scrubs.

== 10. Vérification des ressources ==

<syntaxhighlight lang="bash">
free -h
uptime
df -h
</syntaxhighlight>

Contrôler :

* mémoire disponible ;
* charge système ;
* occupation disque ;
* évolution des ressources par rapport aux contrôles précédents.

== 11. Vérification des mises à jour ==

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

Analyser les mises à jour disponibles.

Les mises à jour et redémarrages doivent être réalisés dans une fenêtre de maintenance adaptée.

== 12. Vérification de la supervision ==

Vérifier dans Centreon :

* disponibilité d'EOLE3 ;
* utilisation de l'adresse vRack <code>192.168.123.202</code> ;
* absence d'alertes persistantes ;
* fonctionnement des contrôles de services et de ressources.

== 13. Vérification des accès extérieurs ==

Réaliser périodiquement un test depuis une connexion indépendante du bureau et des VPN.

Ports publics attendus :

* 80 ;
* 443 ;
* 2022.

Ports devant être bloqués depuis une adresse non autorisée :

* 22 ;
* 111 ;
* 2049 ;
* 9001 ;
* 9090 ;
* 4330 ;
* 44321 à 44323.

Effectuer également un contrôle IPv6.

== 14. Vérification des sauvegardes et du retour arrière ==

Contrôler :

* l'état des sauvegardes ;
* les possibilités de restauration ;
* l'accès administratif de secours ;
* la disponibilité des configurations précédentes ;
* la possibilité de désactiver le pare-feu AJLSM sans toucher à Fail2ban.

== 15. Synthèse du contrôle ==

{| class="wikitable"
! Contrôle
! Résultat
! Observations
|-
| Pare-feu nftables
| À vérifier
|
|-
| Fail2ban
| À vérifier
|
|-
| SSH
| À vérifier
|
|-
| Apache / SFTPGo
| À vérifier
|
|-
| NFS / vRack
| À vérifier
|
|-
| Supervision Centreon
| À vérifier
|
|-
| ZFS
| À vérifier
|
|-
| Ressources système
| À vérifier
|
|-
| Mises à jour
| À vérifier
|
|-
| Sauvegardes
| À vérifier
|
|}

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

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

2026-10-16T12:33:46Z

Jlarvers : 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... »

= 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é

2026-10-16T12:33:02Z

Jlarvers : Page blanchie

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

2026-10-16T12:31:34Z

Jlarvers : Page blanchie

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

2026-10-15T22:01:53Z

Jlarvers :

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

{{Note|Mise à jour du 15 octobre 2026. Les sections 1 à 13 conservent les informations de la recette initiale ; les ajouts et corrections actuels figurent en section 14. En cas de divergence, la procédure opérationnelle de la section 14 et le manuel installé sur Saturne3 prévalent.}}

== 1. Présentation ==

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

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

Le script permet notamment :

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

Chaque phase est indépendante.

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

L'administrateur décide de poursuivre après examen des résultats.
== 2. Infrastructure de référence ==
=== 2.1. Serveur Proxmox ===
Élément Valeur
Hyperviseur Saturne3
Système Proxmox VE 9.2.1 lors de la recette
VM modèle TEMPLATE3
VMID modèle 506
Stockage local-zfs
Script principal /usr/local/sbin/ajlsm-deploy
Répertoire des projets /etc/ajlsm/deploy/projets/
=== 2.2. Scripts ===

Le script principal est installé dans :

/usr/local/sbin/ajlsm-deploy

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

ajlsm-deploy-check
ajlsm-deploy-resources

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

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

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

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

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

install -o root -g root -m 750 \
/root/ajlsm-deploy-review/ajlsm-deploy-network-enable \
/usr/local/sbin/ajlsm-deploy

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

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

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

== 3. Prérequis ==
=== 3.1. Sur l'hyperviseur ===

Les éléments suivants doivent être disponibles :

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

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

La VM modèle doit disposer :

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

TEMPLATE3 doit être arrêtée avant le clonage.
=== 3.3. Vérification du modèle ===

qm status 506
qm config 506

Le résultat attendu est notamment :

status: stopped

L'agent QEMU doit être activé dans la configuration Proxmox.
== 4. Configuration YAML ==

Chaque projet possède son propre fichier YAML.

Exemple :

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

=== 4.1. Exemple MERCURE3 ===

<syntaxhighlight lang="yaml">
projet:
code: mercure3
nom: MERCURE3
environnement: interne

proxmox:
serveur: Saturne3
template_vmid: 506
vmid: null
nom_vm: MERCURE3

cpu:
sockets: 1
cores: 8

memoire:
maximale_mib: 24576
minimale_mib: 16384

disque_systeme:
stockage: local-zfs
taille_gib: 100
etendre_volume_racine: true

demarrage_auto: true

tags:
- interne

systeme:
hostname: mercure3.ajlsm.com

reseau:
interfaces:
- nom: net0
bridge: vmbr2
systeme: ens18
ipv4: 10.0.0.43/24

- nom: net1
bridge: vmbr1
systeme: ens19
ipv4: 192.168.123.27/24

loopback:
ipv4: 51.83.117.113/32

passerelle:
ipv4: 10.0.0.4
interface: ens18

dns:
- 10.0.0.4
</syntaxhighlight>

=== 4.2. Attribution automatique du VMID ===

Le paramètre :

vmid: null

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

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

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

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

Il peut donc changer avant le clonage effectif.
=== 4.3. Réutilisation pour un nouveau projet ===

Pour déployer une autre VM :

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

Le nom du fichier YAML n'est pas imposé par le script.
== 5. Déploiement d'une nouvelle VM (recette initiale) ==

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

La procédure comporte sept phases :

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

Chaque phase comporte une simulation lorsque l'option correspondante est disponible.
=== 5.1. Phase 1 — Simulation du clonage ===

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

Cette commande vérifie :

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

Exemple de résultat :

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

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

[DRY-RUN] Aucune modification effectuée.

L'avertissement concernant la disponibilité réelle des adresses IP est normal à ce stade : le contrôle réseau actif intervient ultérieurement.
=== 5.2. Phase 1 — Clonage effectif ===

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

Dans la version validée, le script demande :

Pour créer la VM 505, saisir CLONER :

La réponse attendue est :

CLONER

Le script effectue ensuite :

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

Résultat attendu :

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

Ne pas démarrer manuellement la VM à ce stade.
=== 5.3. Phase 2 — Simulation des ressources ===

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

Exemple :

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

[DRY-RUN] Aucune modification effectuée.

=== 5.4. Phase 2 — Application des ressources ===

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

Confirmation actuelle :

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

Répondre :

APPLIQUER

Résultat attendu :

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

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

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

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

Exemple :

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

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

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

Confirmation actuelle :

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

Répondre :

DEMARRER

Le script :

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

Exemple :

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

==== Particularité : attente réseau au démarrage ====

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

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

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

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

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

Une amélioration ultérieure de TEMPLATE3 pourra être étudiée pour éviter cette attente inutile pendant les phases isolées.
=== 5.7. Phase 4 — Simulation de personnalisation système ===

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

Cette phase prépare :

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

Exemple :

État de reprise : nouvelle transaction

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

=== 5.8. Phase 4 — Personnalisation système ===

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

Confirmation :

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

Répondre :

oui

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

Résultat obtenu lors de la recette :

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

==== Journal de personnalisation ====

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

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

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

Ne pas supprimer manuellement ces fichiers pour relancer une personnalisation.

En cas d'interruption, conserver la VM isolée et examiner les résultats des commandes dry-run avant toute reprise.
=== 5.9. Phase 5 — Simulation de la configuration réseau ===

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

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

Exemple :

Cible : MERCURE3 VM505 ; reseau Proxmox isole
ens18: 10.0.0.43/24
ens19: 192.168.123.27/24
lo: 51.83.117.113/32 ; passerelle: 10.0.0.4 (ens18) ; DNS: 10.0.0.4

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

=== 5.10. Phase 5 — Application de Netplan ===

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

Confirmation :

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

Répondre :

oui

Le script :

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

Résultat obtenu :

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

Important : cette phase ne connecte pas les interfaces réseau.
=== 5.11. Phase 6 — Simulation de l'activation réseau ===

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

Cette commande effectue notamment :

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

Exemple :

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

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

==== Contrôle ARP DAD ====

ARP DAD signifie Address Conflict Detection.

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

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

Il convient donc de vérifier également l'attribution des adresses dans l'inventaire réseau AJLSM.
=== 5.12. Phase 7 — Activation du réseau ===

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

Confirmation :

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

Répondre :

oui

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

Il contrôle ensuite :

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

Résultat obtenu lors de la recette :

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

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

Limite de la recette : le chemin nominal a été validé deux fois, mais le repli sur erreur n'a pas encore été testé en situation réelle.
== 6. Vérifications finales ==
=== 6.1. État de la VM ===

qm status 505

Résultat attendu :

status: running

=== 6.2. Configuration Proxmox ===

qm config 505

Vérifier notamment :

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

Contrôle ciblé :

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

Résultat attendu :

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

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

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

Exemples de commandes dans la VM :

hostnamectl

ip -br addr

ip route

resolvectl status

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

=== 6.4. Vérification du volume racine ===

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

Vérifier dans l'invité :

lsblk

df -hT /

pvs

vgs

lvs

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

Adapter les contrôles au partitionnement réel de TEMPLATE3.
== 7. Sécurité et principes de fonctionnement ==
=== 7.1. Isolation réseau ===

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

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

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

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

=== 7.2. Contrôle de l'identité ===

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

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

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

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

Certaines phases demandent :

CLONER
APPLIQUER
DEMARRER

D'autres utilisent :

Confirmer (OUI/NON) :

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

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

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

L'état de Proxmox, de la VM ou du réseau peut évoluer entre la simulation et l'exécution.
=== 7.5. Reprise après incident ===

En cas d'erreur :

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

Ne pas supprimer les fichiers de transaction de personnalisation pour forcer une nouvelle exécution.
== 8. Tableau récapitulatif des commandes (version de la recette initiale) ==

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

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

Exemple :

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

Remplacer OPTION par le mode souhaité.
== 9. Maintenance ==
=== 9.1. Vérification de la syntaxe ===

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

=== 9.2. Affichage des options ===

ajlsm-deploy --help

=== 9.3. Sauvegarde avant modification ===

Avant toute mise à jour :

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

Si les scripts complémentaires sont modifiés, les sauvegarder également.
=== 9.4. Restauration de la version précédente ===

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

install -o root -g root -m 750 \
/usr/local/sbin/ajlsm-deploy.bak-20261015 \
/usr/local/sbin/ajlsm-deploy

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

Vérifier la compatibilité avec les scripts complémentaires avant toute restauration.
== 10. Améliorations prévues (état historique à l’issue de la première recette) ==

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

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

Elles ne sont pas encore intégrées dans la version installée.
=== 10.1. Uniformisation des confirmations ===

Toutes les phases utiliseront :

Confirmer (oui/non) :

Comportement souhaité :

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

Les majuscules et minuscules devront être acceptées.
=== 10.2. Affichage des commandes suivantes ===

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

Exemple :

============================================================
[OK] RESSOURCES CONFIGURÉES
============================================================

VM : 505 (MERCURE3)

PROCHAINE ÉTAPE : PREMIER DÉMARRAGE

1. Simulation :

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

2. Application :

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

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

Ces commandes seront uniquement affichées, jamais exécutées automatiquement.
=== 10.3. Aide intégrée ===

Améliorer :

ajlsm-deploy --help

L'aide devra être organisée par phases et rédigée en français.
=== 10.4. Manuel système ===

Créer une page de manuel accessible avec :

man ajlsm-deploy

Elle devra présenter :

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

=== 10.5. Optimisation de TEMPLATE3 ===

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

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

Le répertoire utilisé pour la recette est :

/root/ajlsm-deploy-review/

Il contient notamment :

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

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

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

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

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

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

Ne pas supprimer les autres fichiers de développement tant que leur rôle et leur emplacement définitif n'ont pas été vérifiés.
== 12. Historique des validations ==
Date Opération Résultat
15/10/2026 Installation du script avec activation réseau Validée
15/10/2026 Premier déploiement MERCURE3 Validé
15/10/2026 Suppression du premier clone Effectuée
15/10/2026 Second clonage complet depuis TEMPLATE3 Validé
15/10/2026 Configuration CPU/RAM/disque Validée
15/10/2026 Premier démarrage isolé Validé
15/10/2026 Personnalisation système Validée
15/10/2026 Configuration Netplan Validée
15/10/2026 Contrôle ARP des adresses IPv4 Validé
15/10/2026 Activation réseau et contrôles Validée
À réaliser Test du repli automatique sur échec réseau Non testé
À réaliser Harmonisation des confirmations et aide intégrée Non réalisée
== 13. Conclusion ==

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

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

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

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

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

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

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

== 14. Actualisation technique du 15 octobre 2026 ==

=== 14.1. Périmètre et emplacement des fichiers ===

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

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

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

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

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

=== 14.2. Ordre actuel des phases ===

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

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

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

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

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

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

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

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

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

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

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

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

# 11. Certificat TLS interne
ajlsm-deploy "$PROJET" --tls-apply
</syntaxhighlight>

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

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

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

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

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

Contrôles manuels possibles dans l'invité :

<syntaxhighlight lang="bash">
lsblk
df -hT /
pvs
vgs
lvs
</syntaxhighlight>

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

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

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

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

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

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

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

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

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

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

Les tests isolés du 15 octobre 2026 ont confirmé :
* Clés concordantes : acceptation et écriture.
* Clés divergentes : refus sans modification.
* Clé malformée : refus sans modification.
* Préservation des autres entrées, y compris lors du traitement des anciennes entrées hachées.

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

=== 14.6. Durcissement SSH, compte ajlsm et TLS ===

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

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

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

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

=== 14.7. Format YAML et protections ===

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

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

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

=== 14.8. Confirmations, codes de sortie et reprise ===

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

{| class="wikitable"
! Code !! Signification
|-
| 0 || Succès
|-
| 1 || Annulation
|-
| 2 || Erreur de configuration, de contrôle ou d'exécution
|}

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

=== 14.9. Maintenance et documentation installée ===

Sur Saturne3 :

<syntaxhighlight lang="bash">
# Vérifier les trois scripts Python
python3 -m py_compile \
/usr/local/sbin/ajlsm-deploy \
/usr/local/sbin/ajlsm_deploy_rootgrow.py \
/usr/local/sbin/ajlsm_deploy_postconfig.py

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

# Identifier le manuel installé
man -w ajlsm-deploy
</syntaxhighlight>

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

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

=== 14.10. Historique complémentaire des validations ===

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

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

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

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

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

[[Catégorie:Infrastructure]]
[[Catégorie:Proxmox]]
[[Catégorie:Déploiement]]
[[Catégorie:AJLSM]]