Mode opératoire — Donner à une machine un accès sûr au cluster Galera par un HAProxy local

Document autonome. Partie théorique, puis mise en œuvre telle qu’elle a été réalisée et vérifiée le 21/10/2026 sur srv-supervision (phase 14 du suivi, tâche 14.5). La méthode vaut pour toute application qui doit écrire dans un cluster MariaDB/Galera sans dépendre d’un seul nœud. Elle reprend le montage du répartiteur srv-ha (MO-3-HAProxy.md), en local. Contexte : Documentation-pfSense.md (étape 48) ; règle de pare-feu : Matrice-de-flux.md (§4.4, règle 4 ter).

Valeurs masquées. Aucun mot de passe n’apparaît ici : <mot-de-passe-…>, à prendre dans Bitwarden.

Dernière mise à jour : 21/10/2026

Sommaire

1 · Le besoin

srv-supervision doit écrire dans le cluster MariaDB/Galera (3 nœuds 10.0.20.10/11/12) : les journaux de toutes les machines, puis la base de Grafana. Si on lui donne l’adresse d’un nœud, la supervision s’arrête dès que ce nœud tombe — alors que le cluster, lui, continue. Il faut un point d’entrée qui suit le cluster, sans donner à toutes les applications l’accès aux trois nœuds.

2 · Théorie : pourquoi un HAProxy local, et pourquoi la bascule

 srv-supervision (10.0.30.15)
 ┌───────────────────────────────────────┐
 │ rsyslog, Grafana ──► 127.0.0.1:3306   │
 │                      HAProxy local ───┼──► srv-mysql-01 (principal)
 └───────────────────────────────────────┘    srv-mysql-02 / 03 (secours)

Principe à retenir — l’application ne connaît qu’une adresse (127.0.0.1) ; c’est l’infrastructure qui décide quel nœud la sert. Changer de nœud ne demande de toucher à aucune application.

3 · L’architecture retenue

4 · Le compte de sonde sur le cluster

Contexte : sur un nœud (srv-mysql-01). Galera recopie le compte sur les autres.

sudo mariadb -e "CREATE USER IF NOT EXISTS 'haproxy_check'@'10.0.30.15';"

Un compte sans mot de passe et sans aucun droit : la sonde a seulement besoin qu’il existe pour que MariaDB réponde. Il est limité à l’adresse de la machine.

Validation — sur un autre nœud :

sudo mariadb -e "SELECT user, host FROM mysql.user WHERE user='haproxy_check';"

une ligne haproxy_check | 10.0.30.15 (et, dans ce lab, celle de srv-ha : 10.0.10.5).

5 · Installer HAProxy et le client MariaDB

sudo apt-get update && sudo apt-get install -y --no-install-recommends haproxy mariadb-client

mariadb-client n’installe que l’outil en ligne de commande (pour les tests et la création des tables), pas de serveur de base.

/usr/sbin/haproxy -v | head -1; systemctl is-active haproxy

HAProxy version 3.0.11… puis active.

haproxy -v seul répond commande introuvable : Debian range haproxy dans /usr/sbin, hors du chemin d’un utilisateur ordinaire (incident H-38).

6 · Tester chaque nœud

Ce test traverse la règle pfSense et fait une vraie connexion avec le compte de sonde (pas de connexion « à moitié ouverte », cf. incident H-23).

for ip in 10.0.20.10 10.0.20.11 10.0.20.12; do mariadb -h $ip -u haproxy_check --connect-timeout=5 --skip-ssl-verify-server-cert -N -e "SELECT @@hostname" || echo "ECHEC $ip"; done

srv-mysql-01, srv-mysql-02, srv-mysql-03.

Sans --skip-ssl-verify-server-cert, le client 11.8 refuse : TLS/SSL error: self-signed certificate. Il vérifie le certificat par défaut, et ne peut pas le faire avec un compte sans mot de passe (incident H-31). L’option est réservée à ce compte de test sans droit ; les comptes à mot de passe s’en passent.

7 · Configurer HAProxy

1. Sauvegarder l’original

sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.orig

2. Ajouter le bloc (ne fait rien s’il est déjà présent ; copie de référence : haproxy-galera.cfg)

grep -q "listen galera" /etc/haproxy/haproxy.cfg || sudo tee -a /etc/haproxy/haproxy.cfg >/dev/null <<'EOF'

#---------------------------------------------------------------------
#  Galera : acces local de srv-supervision (journaux, Grafana)
#  Bascule, PAS de repartition : un principal, deux secours
#---------------------------------------------------------------------
listen galera
    mode tcp
    option tcplog
    bind 127.0.0.1:3306
    timeout client 1h
    timeout server 1h
    option mysql-check user haproxy_check
    server mysql-01 10.0.20.10:3306 check
    server mysql-02 10.0.20.11:3306 check backup
    server mysql-03 10.0.20.12:3306 check backup
EOF

3. Vérifier, puis recharger seulement si c’est valide

grep -c "listen galera" /etc/haproxy/haproxy.cfg && sudo /usr/sbin/haproxy -c -f /etc/haproxy/haproxy.cfg && sudo systemctl reload haproxy && sleep 3 && sudo ss -ltnp | grep 3306

1, puis une écoute 127.0.0.1:3306 par haproxy. (HAProxy 3.0 peut ne rien afficher quand la configuration est valide : la chaîne && qui continue jusqu’au rechargement en est la preuve.)

Validation

mariadb -h 127.0.0.1 -u haproxy_check --skip-ssl-verify-server-cert -N -e "SELECT @@hostname"

srv-mysql-01. Et aucun DOWN dans sudo journalctl -u haproxy --since "10 min ago" (HAProxy n’écrit que les changements d’état).

8 · Les bases et les comptes de l’application

Contexte : sur un nœud ; tout est recopié par Galera. Exemple de la supervision : bases syslog et grafana, trois comptes.

1. Bases et tables (aucun secret) — chaque table doit avoir une clé primaire (Galera l’exige pour répliquer correctement) :

sudo mariadb <<'EOF'
CREATE DATABASE IF NOT EXISTS syslog  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE DATABASE IF NOT EXISTS grafana CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE TABLE IF NOT EXISTS syslog.journaux (
  id         BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  recu_le    DATETIME NOT NULL,
  emis_le    DATETIME NULL,
  hote       VARCHAR(64) NOT NULL,
  programme  VARCHAR(64) NULL,
  facilite   TINYINT UNSIGNED NULL,
  gravite    TINYINT UNSIGNED NULL,
  message    TEXT,
  KEY idx_recu (recu_le),
  KEY idx_hote_recu (hote, recu_le)
) ENGINE=InnoDB;
CREATE TABLE IF NOT EXISTS syslog.journaux_auth LIKE syslog.journaux;
EOF

2. Comptes, dans une session sans historique (le mot de passe ne reste pas écrit sur le serveur) :

sudo env MYSQL_HISTFILE=/dev/null mariadb

Puis, une ligne à la fois (mots de passe générés dans Bitwarden : 24 lettres et chiffres, sans caractère spécial) :

CREATE USER 'rsyslog'@'10.0.30.15' IDENTIFIED BY '<mot-de-passe-rsyslog>';
GRANT INSERT ON syslog.* TO 'rsyslog'@'10.0.30.15';
CREATE USER 'grafana_lecture'@'10.0.30.15' IDENTIFIED BY '<mot-de-passe-grafana_lecture>';
GRANT SELECT ON syslog.* TO 'grafana_lecture'@'10.0.30.15';
CREATE USER 'grafana'@'10.0.30.15' IDENTIFIED BY '<mot-de-passe-grafana>';
GRANT ALL PRIVILEGES ON grafana.* TO 'grafana'@'10.0.30.15';

Moindre privilège — un compte qui écrit ne lit pas, un compte qui lit n’écrit pas. Le vol de l’un ne donne pas les droits de l’autre.

Validation — depuis la machine, par HAProxy (-p sans valeur : le mot de passe est demandé, sans écho ni historique) :

mariadb -h 127.0.0.1 -u rsyslog -p -N -e "SELECT CURRENT_USER(), @@hostname"

[email protected] | srv-mysql-01 — sans option TLS : avec un mot de passe, le client vérifie le certificat lui-même.

9 · Pièges et checklist

 Compte de sonde créé sur un nœud, présent sur un autre
 HAProxy et mariadb-client installés (--no-install-recommends)
 Les 3 nœuds répondent en direct (règle pfSense OK)
 haproxy.cfg.orig gardé ; bloc listen galera présent une seule fois ; haproxy -c OK
 Écoute 127.0.0.1:3306 uniquement ; connexion → srv-mysql-01
 Bases avec clés primaires ; comptes au moindre privilège ; mots de passe dans Bitwarden

La règle à retenir en une phrase : l’application parle à 127.0.0.1, HAProxy choisit le nœud vivant — un seul point d’accès au cluster, une seule règle de pare-feu.