FAQ — questions / réponses du TP

Objet. Ce document recueille les questions posées au fil des sessions et les réponses argumentées, sans modifier le TP lui-même. Les décisions qui en découlent ne sont reportées dans les autres livrables que sur demande explicite.

Chaque entrée indique son statut : Réponse (explication seule) · Décision à reporter (validée, en attente d’intégration) · Reportée (intégrée aux livrables).

Dernière mise à jour : 12/11/2026 (relecture : Q1, Q3 et Q6 remises à jour) ; 11/11/2026

Sommaire

Q1 · On abandonne Server 2025 GUI pour du Core — que faut-il changer ?

Question posée. « On laisse tomber le serveur Windows 2025 en interface graphique, on va installer que le Core. Peut-être que l’on peut reprendre l’IP du serveur graphique et changer juste le nom des règles ? »

1 · La réponse courte

2 · Le point bloquant : une installation GUI ne se convertit pas en Core

C’est le seul vrai obstacle, et il vaut la peine d’être compris car il revient souvent en entretien.

Jusqu’à Windows Server 2012 R2, les deux modes étaient deux états d’une même installation. On basculait de l’un à l’autre avec :

Remove-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra   # 2012 R2 uniquement

Depuis Windows Server 2016, Microsoft a supprimé cette possibilité. Le mode d’installation — Server Core ou Desktop Experience — est choisi au moment de l’installation et devient définitif. La documentation Microsoft est explicite : pour changer de mode, il faut réinstaller.

Raison technique : les deux modes ne partagent plus le même jeu de composants de base. Desktop Experience n’est pas « Core + une interface par-dessus », c’est une image différente.

Conséquence pratique : la VM AD-GUI actuelle ne peut pas devenir AD-Core. Deux options, et la seconde est la bonne.

Le fait que AD-GUI ne soit pas encore promue (6.5 toujours ) rend cette décision indolore. Aucun domaine n’existe, aucun objet Active Directory n’est à migrer. Prise aujourd’hui, cette décision coûte une réinstallation ; prise après promotion, elle aurait coûté une démotion, un nettoyage de métadonnées et une recréation de forêt.

3 · Pourquoi l’adresse se reprend sans problème

Une adresse IP n’est « réservée » que par ce qui la mémorise. Inventaire de ce qui connaît 10.0.30.10 aujourd’hui :

Rien ne s’oppose donc à la réutilisation. C’est même préférable : le plan d’adressage reste compact et .10 conserve son sens de « premier serveur du VLAN ».

Un seul réflexe au moment du remplacement : la nouvelle machine aura une MAC et des clés d’hôte différentes pour la même adresse. Si un client a déjà mémorisé l’ancienne, il signalera un changement d’identité. C’est exactement le mécanisme décrit au §3 de MO-4 — et la preuve que les clés d’hôte servent bien à quelque chose.

4 · Côté pare-feu : un seul changement, et aucun renommage

Vérification faite sur l’ensemble des règles : aucune règle pfSense ne mentionne AD-GUI ni AD-Core. Les règles désignent des rôles, pas des machines — c’est précisément l’intérêt des alias, et ça se vérifie ici concrètement.

La seule règle concernée est la règle 3 de l’onglet USERS :

USERS subnets  →  ADM subnets  :  PORTS_DC_AD
« Jonction et authentification domaine sio.internal »

Elle vise ADM subnets et un groupe de ports. Ni l’une ni l’autre ne changent. Son libellé reste exact.

Le seul changement réel : l’alias DC_AD

Firewall → Aliases → IP → DC_AD → retirer la ligne 10.0.30.11 → Save → Apply Changes.

Pourquoi vider 10.0.30.11 plutôt que le laisser « au cas où » : un alias est de la documentation exécutable. Une adresse qui y figure sans machine derrière est une autorisation accordée à personne — inoffensive aujourd’hui, mais qui deviendra une autorisation accordée à la prochaine machine qui prendra cette adresse. C’est le même raisonnement qu’au §12.3 de MO-4 sur les clés oubliées dans un authorized_keys.

5 · Le coût de la décision — et sa résolution déjà planifiée

Le plan initial prévoyait deux contrôleurs de domaine : AD-GUI et AD-Core. En supprimant le serveur graphique, il n’en reste qu’un — temporairement.

   PLAN INITIAL              ÉTAT INTERMÉDIAIRE          CIBLE  (décidée le 01/10)

   AD-GUI  .10               AD-Core-01  .10             AD-Core-01  .10  ◄──┐
   AD-Core .11                     │                            │  réplication
                                   └── défaillance unique       │            │
   2 DC, redondance           1 seul DC                AD-Core-02  .11  ◄──┘

                                                         2 DC, redondance rétablie
                                                         — et deux Core, cohérents

Décision du 01/10 : un second contrôleur de domaine en Server Core est prévu, mais pas tout de suite. La période à un seul DC est donc un état transitoire assumé, pas un choix d’architecture définitif.

Pourquoi c’est une bonne décision, et pas seulement un rattrapage

L’abandon de AD-GUI au profit de deux Core est meilleur que le plan initial, pas équivalent :

Deux DC identiques, c’est aussi ça la haute disponibilité : si les deux nœuds s’administrent et se corrigent de la même façon, la bascule de l’un vers l’autre n’introduit aucune surprise. C’est exactement le raisonnement appliqué aux trois nœuds Galera — configuration identique, un seul 60-galera.cnf à connaître.

La dette, reformulée en conséquence

T-8	Contrôleur de domaine unique — transitoire
Pourquoi	Abandon de AD-GUI au profit du tout-Core ; le second nœud n’est pas encore déployé
Risque	Point de défaillance unique sur l’authentification Kerberos, le DNS interne et les GPO
Mitigation immédiate	Sauvegarde de l’état système du DC ; résolution DNS des VM assurée par pfSense, indépendante de l’AD
Résolution	Planifiée — déploiement de AD-Core-02 en 10.0.30.11, second contrôleur du domaine sio.internal. Échéance non fixée

Une dette datée et planifiée ne se défend pas comme une dette subie. Dire « je sais, c’est prévu, voici l’adresse déjà réservée » montre qu’on pilote son infrastructure.

Conséquence sur 10.0.30.11

L’adresse reste réservée au futur second contrôleur dans le plan d’adressage — avec le suffixe (à créer) du tableau d’adressage.

Mais elle sort quand même de l’alias DC_AD (§4 ci-dessus). Les deux ne se contredisent pas :

	Rôle	Doit-elle y figurer ?
Plan d’adressage	documenter une intention	oui — (à créer)
Alias pfSense	accorder une autorisation	non — tant qu’il n’y a pas de machine

Laisser .11 dans l’alias, c’est ouvrir les ports Active Directory vers la prochaine machine qui prendra cette adresse, quelle qu’elle soit. La remettre le jour du déploiement prend dix secondes — et ces dix secondes font partie de la procédure.

6 · Et ce qu’elle apporte

L’abandon de l’interface graphique n’est pas qu’une simplification :

Le vrai apprentissage est là : administrer un serveur sans le voir. C’est la norme en entreprise, et c’est ce qui distingue un administrateur d’un utilisateur avancé.

7 · Récapitulatif des modifications à reporter (reportées : AD-Core-01 en service, AD-Core-02 reporté sans échéance, dette T-8 ; l’alias DC_AD garde 10.0.30.11 en réserve)

Q2 · Pourquoi 10.0.10.5 devient www.sio.internal ?

Question posée. « Lorsque j’attaque le serveur WordPress via 10.0.10.5, à chaque fois ça me transforme l’adresse IP en nom de domaine. Seulement de mon PC Lenovo je n’ai pas l’accès au domaine. Pourquoi ça fait ça, et que peut-on faire pour avoir accès via l’IP, ou configurer le domaine sur mon PC aussi ? »

1 · Ce n’est pas un bug — c’est WordPress qui fait son travail

Le responsable est une ligne que nous avons écrite nous-mêmes à l’étape 30, dans wp-config.php des deux serveurs web :

define( 'WP_HOME',    'https://www.sio.internal' );
define( 'WP_SITEURL', 'https://www.sio.internal' );

WordPress possède un mécanisme nommé redirection canonique (redirect_canonical). Son principe : un contenu, une seule URL. Si la requête arrive sous une autre forme que l’URL canonique déclarée, WordPress renvoie une redirection permanente 301 vers celle-ci.

2 · Le trajet complet d’une requête vers 10.0.10.5

  1.  Navigateur  ──►  http://10.0.10.5
                       │
  2.  HAProxy :80 ──►  301  « va en HTTPS »          (http-request redirect scheme https)
                       │
  3.  Navigateur  ──►  https://10.0.10.5
                       │
  4.  HAProxy :443      présente le certificat de www.sio.internal
                       → avertissement de sécurité, le nom ne correspond pas
                       │
                       déchiffre, transmet en HTTP à srv-web-0x
                       avec X-Forwarded-Proto: https
                       │
  5.  WordPress        Host demandé  : 10.0.10.5
                       WP_HOME       : www.sio.internal      ← ILS DIFFÈRENT
                       │
                       301  « l'adresse canonique est https://www.sio.internal »
                       │
  6.  Navigateur  ──►  https://www.sio.internal
                       │
                        sur le Lenovo : le nom ne se résout pas

La transformation que tu observes se produit à l’étape 5. Les étapes 1 à 4 fonctionnent parfaitement : l’IP est joignable, c’est WordPress qui refuse de servir le site sous ce nom-là.

La distinction à retenir : « joindre la machine » et « être servi par le site » sont deux choses différentes. Derrière un répartiteur avec terminaison TLS, un site est identifié par son nom — le certificat porte un nom, le Host: HTTP porte un nom, le SNI porte un nom. L’adresse IP n’est qu’un détail de transport.

3 · Pourquoi le Lenovo ne résout pas www.sio.internal

Le nom www.sio.internal n’existe que dans le résolveur de pfSense, sous forme d’un Host Override créé à l’étape 30 :

Services → DNS Resolver → Host Overrides
www.sio.internal  →  10.0.10.5

Le Lenovo joint le laboratoire par Tailscale, qui lui donne la connectivité réseau — mais Tailscale ne lui donne pas le DNS du laboratoire. Il continue d’interroger le résolveur qu’il utilisait avant.

C’est exactement le point ③ du §2.7 de la documentation, vu sous un autre angle : « une machine ne connaît que les noms que son résolveur connaît ». Centraliser le DNS sur pfSense est la bonne décision — encore faut-il que les clients interrogent pfSense.

4 · Les solutions, de la plus rapide à la plus canonique

Solution A — Fichier hosts sur le Lenovo (1 minute, local)

Le plus court chemin. Le fichier hosts est consulté avant le DNS.

PowerShell en administrateur :

Add-Content -Path "$env:SystemRoot\System32\drivers\etc\hosts" -Value "`n10.0.10.5`twww.sio.internal"

Vérification :

Resolve-DnsName www.sio.internal

À connaître : le fichier hosts est le premier endroit où regarder quand un nom se résout « bizarrement » sur une machine. C’est aussi, pour cette raison, une cible classique de détournement.

Solution B — DNS fractionné via Tailscale (la version canonique)

Tailscale sait pousser un résolveur limité à un domaine sur tous les nœuds du tailnet. C’est la réponse propre : le Lenovo interrogera pfSense pour *.sio.internal et uniquement pour ça, en gardant son DNS habituel pour le reste.

   ag-lenovo
      │
      ├── *.sio.internal  ──►  100.84.62.27  (pfSense sur le tailnet)
      │                              └──► Host Override → 10.0.10.5
      │
      └── tout le reste   ──►  DNS habituel de la machine

Deux côtés à configurer — dans cet ordre :

① Côté pfSense — autoriser le tailnet à interroger unbound

C’est l’étape qu’on oublie. Par défaut, le résolveur de pfSense n’accepte les requêtes que des réseaux directement connectés ; la plage Tailscale n’en fait pas partie et les requêtes seraient refusées sans explication.

Services → DNS Resolver → Access Lists → Add

Vérifier aussi, dans l’onglet General Settings, que Network Interfaces vaut All (ou inclut l’interface Tailscale) — sinon unbound n’écoute pas de ce côté.

② Côté Tailscale — déclarer le résolveur fractionné

Admin console → DNS → Nameservers → Add nameserver → Custom

Pourquoi « restrict to search domain » est indispensable. Sans cette case, tout le trafic DNS de tous les nœuds du tailnet partirait vers pfSense. Le Lenovo perdrait la résolution des noms de l’établissement dès que le laboratoire serait éteint. Le DNS fractionné dit : « pour ce domaine-là, ce serveur-là ; pour le reste, ne change rien ».

Vérification :

Resolve-DnsName www.sio.internal

→ doit répondre 10.0.10.5, et https://www.sio.internal doit afficher le site.

Solution C — Forcer l’accès par l’IP (déconseillé)

Techniquement possible en retirant WP_HOME / WP_SITEURL de wp-config.php. À éviter, pour trois raisons qui se cumulent :

1. On réintroduit le problème que l’étape 30 avait réglé : WordPress reconstruirait ses URL depuis l’en-tête Host:, donc différemment selon le point d’entrée — liens, images et feuilles de style finiraient mélangés entre 10.0.10.5 et www.sio.internal.
2. Le certificat porte le nom www.sio.internal : l’accès par IP produira toujours un avertissement de sécurité, quoi qu’on fasse côté WordPress.
3. C’est traiter le symptôme. Le problème n’est pas la redirection — elle est correcte — mais l’absence de résolution de nom sur un poste.

Solution D — Pour un test ponctuel, sans rien configurer

Quand il s’agit juste de vérifier que le site répond, on résout le nom le temps d’une commande :

curl -k --resolve www.sio.internal:443:10.0.10.5 https://www.sio.internal/ -I

--resolve dit à curl : « pour ce nom et ce port, utilise cette adresse ». -k accepte le certificat auto-signé.

C’est l’outil de diagnostic idéal : il permet de tester le répartiteur avant que le DNS soit en place, et de distinguer un problème de résolution d’un problème de service.

5 · Recommandation

Les deux ne s’excluent pas : A débloque tout de suite, B se met en place tranquillement et rend A inutile.

6 · Un piège à connaître avant de tester

Les navigateurs mettent en cache les redirections 301 de façon très agressive, parfois jusqu’à la fin de la session, parfois davantage. Après un changement de configuration, un navigateur peut continuer à rediriger sans même interroger le serveur.

Tester systématiquement en navigation privée, ou vider le cache, avant de conclure que la modification n’a pas fonctionné. Plus d’une heure de diagnostic s’est déjà perdue sur une redirection qui n’existait plus que dans le navigateur.

Q3 · Comment tester le cluster Galera ?

Question posée. « J’aimerais pouvoir faire des tests sur le cluster Galera, et comment faire ? »

1 · Où on en est — trois tests sur six sont déjà faits (au 01/10)

Au 12/11 : les six tests sont faits — 7.10 le 29/10 (WordPress continue, MariaDB arrêté sur le nœud 1), 7.11 le 02/11 (perte de quorum, écritures refusées, étape 58), 7.13 le 30/10 (poste-win11 toujours refusé sur 3306).

Il reste donc trois tests, et ce sont les plus intéressants : le 7.9 prouvait que le cluster réplique, les 7.10 et 7.11 prouvent comment il réagit quand il casse.

La différence entre les deux familles de tests. Un test de fonctionnement montre que l’architecture marche. Un test de défaillance montre qu’on l’a comprise. Le second a infiniment plus de valeur en soutenance — et c’est le seul qui révèle les erreurs de conception.

2 · Avant de commencer — le tableau de bord

Cinq variables suffisent à connaître l’état d’un cluster Galera. À exécuter sur n’importe quel nœud :

sudo mariadb -e "SHOW STATUS WHERE Variable_name IN (
  'wsrep_cluster_size',
  'wsrep_cluster_status',
  'wsrep_local_state_comment',
  'wsrep_connected',
  'wsrep_ready');"

Résultat d’un cluster en bonne santé :

Ne pas confondre cluster_status et local_state_comment. Le premier décrit le groupe (« avons-nous le quorum ? »), le second décrit ce nœud (« suis-je à jour ? »). Un nœud peut être Synced dans un groupe non-Primary : il a les données, mais il n’a pas le droit de s’en servir. C’est toute la subtilité du test 7.11.

Garde cette commande sous la main — tu vas la relancer après chaque étape. Pour aller plus vite, crée un alias sur chaque nœud :

echo "alias gstat='sudo mariadb -e \"SHOW STATUS WHERE Variable_name IN (\\\"wsrep_cluster_size\\\",\\\"wsrep_cluster_status\\\",\\\"wsrep_local_state_comment\\\",\\\"wsrep_ready\\\");\"'" >> ~/.bashrc
source ~/.bashrc

→ gstat suffira ensuite.

3 · Deux précautions avant de casser quelque chose

① Une sauvegarde logique de la base, depuis srv-mysql-01 :

sudo mariadb-dump --single-transaction wp_lab > ~/wp_lab_avant_tests_$(date +%F).sql
ls -lh ~/wp_lab_avant_tests_*.sql

② Choisir le bon moment. Le test 7.11 rend le site indisponible pendant plusieurs minutes — c’est précisément ce qu’il démontre. À ne pas lancer pendant qu’on a besoin de WordPress pour autre chose.

Ouvre trois sessions côte à côte — une par nœud — plus la page de statistiques HAProxy (http://10.0.10.5:8404). Voir les trois états changer en même temps est ce qui fait comprendre le mécanisme. C’est aussi la capture d’écran qui vaut le plus cher dans le dossier.

4 · Test 7.10 — bascule de la base

Ce qu’il prouve : HAProxy détecte la perte du nœud actif et bascule sur un nœud backup, sans que WordPress s’en aperçoive.

Étape 1 — état initial

Sur le poste, ouvrir https://www.sio.internal : le site répond. Sur la page de statistiques HAProxy, la section galera montre mysql-01 UP et les deux autres en backup.

Étape 2 — arrêter le nœud actif

Sur srv-mysql-01 :

sudo systemctl stop mariadb

Étape 3 — observer, dans cet ordre

# depuis srv-mysql-02
sudo mariadb -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

La bascule n’est pas instantanée. HAProxy ne déclare un serveur DOWN qu’après l’échec de sa sonde — par défaut toutes les 2 s. Un rechargement immédiat peut tomber sur une erreur de base de données. Attendre 5 secondes et recharger : c’est le comportement normal d’un répartiteur, pas un défaut. Le noter tel quel dans la documentation.

Étape 4 — remettre le nœud en service

sudo systemctl start mariadb
sudo mariadb -e "SHOW STATUS LIKE 'wsrep_local_state_comment';"

Le nœud revient, rattrape son retard par IST (incrémental — il ne lui manque que quelques transactions, pas toute la base) et repasse Synced. wsrep_cluster_size retourne à 3.

C’est ici qu’on voit l’intérêt de l’IST. Quelques secondes d’arrêt → rattrapage incrémental, quasi instantané. Si on avait vidé /var/lib/mysql, il aurait fallu un SST — copie complète. Les deux mécanismes sont détaillés au §2 de MO-2.

Un point à vérifier en direct

Avec option mysql-check, HAProxy valide la poignée de main MySQL. La question ouverte : détecte-t-il un nœud démarré mais pas encore synchronisé ? Probablement pas — un nœud en train de rattraper accepte la connexion tout en refusant les requêtes.

Si c’est bien ce qu’on observe, cela justifie expérimentalement le passage à clustercheck évoqué dans MO-3 : argument bien plus solide qu’une citation de documentation.

Tranché le 05/11/2026 (étape 62, capture 191) : un nœud mis hors synchronisation par SET GLOBAL wsrep_desync=ON répond toujours (SELECT 1 → 1), donc mysql-check l’aurait gardé. HAProxy contrôle désormais une sonde de synchronisation sur le port 9200 : le nœud est passé DOWN en quelques secondes, puis UP une fois resynchronisé.

5 · Test 7.11 — le quorum

Le test le plus formateur du TP. Il montre qu’un cluster bien conçu refuse délibérément de fonctionner plutôt que de risquer deux moitiés divergentes.

Le raisonnement, avant la manipulation

   3 nœuds, le réseau se coupe en deux :

   ┌─ nœud 1 ─┐          ┌─ nœud 2 ─ nœud 3 ─┐
   │  1 / 3   │    ╳     │       2 / 3       │
   │   33 %   │  coupure │        67 %       │
   └──────────┘          └───────────────────┘
    MINORITÉ                  MAJORITÉ
    → se tait                 → continue

   Si les deux côtés continuaient : écritures divergentes des deux
   côtés, impossibles à réconcilier → SPLIT-BRAIN.

La règle Galera : un groupe ne travaille que s’il détient strictement plus de la moitié des nœuds. C’est aussi la réponse à « pourquoi 3 nœuds et pas 2 » — avec 2 nœuds, chaque moitié en vaut exactement la moitié, aucune n’a la majorité, et la perte d’un seul nœud arrête tout. Un nombre impair est la règle.

La manipulation

Sur srv-mysql-02, puis sur srv-mysql-03 :

sudo systemctl stop mariadb

Puis, sur le survivant srv-mysql-01 :

sudo mariadb -e "SHOW STATUS LIKE 'wsrep_cluster_status';"

Ce qu’on doit observer

Essayer explicitement une lecture et une écriture :

sudo mariadb -e "SELECT COUNT(*) FROM wp_lab.wp_posts;"
sudo mariadb -e "INSERT INTO wp_lab.wp_options (option_name, option_value) VALUES ('test_quorum','x');"

Le point contre-intuitif, et c’est tout le sujet : le nœud 1 a les données. Il est en parfait état de marche. Il refuse quand même — parce qu’il ne peut pas savoir si les deux autres sont morts ou simplement injoignables. S’ils étaient vivants de leur côté et qu’il acceptait des écritures, les deux versions de la base divergeraient irrémédiablement.

Il préfère l’indisponibilité à l’incohérence. C’est un choix d’architecture explicite — le fameux arbitrage du théorème CAP, visible ici en une commande.

Capture obligatoire : wsrep_cluster_status = non-Primary à côté du message ERROR 1047. C’est la capture la plus parlante de tout le TP.

Le retour à la normale

Il suffit de redémarrer un seul des deux nœuds arrêtés — 2 sur 3 rétablissent la majorité :

# sur srv-mysql-02
sudo systemctl start mariadb

Puis vérifier sur le nœud 1 :

sudo mariadb -e "SHOW STATUS LIKE 'wsrep_cluster_status';"   # → Primary

Redémarrer ensuite le nœud 3, et contrôler que wsrep_cluster_size vaut de nouveau 3 sur les trois nœuds. Enfin, effacer la trace du test si l’INSERT était passé :

sudo mariadb -e "DELETE FROM wp_lab.wp_options WHERE option_name='test_quorum';"

Ne pas confondre avec l’arrêt complet du cluster. Ici le nœud 1 n’a jamais été arrêté : la reprise est automatique, il n’y a rien à forcer. C’est seulement quand les trois nœuds sont arrêtés qu’il faut aller lire grastate.dat et son indicateur safe_to_bootstrap pour savoir lequel redémarrer en premier — procédure décrite au §8 de MO-2.

Et surtout : ne pas forcer pc.bootstrap=YES sur le nœud 1 pendant le test. Cette commande dit « considère que tu as le quorum à toi seul ». Elle existe pour les situations de reprise après sinistre, quand on est certain que les autres nœuds sont morts. Utilisée ici, elle fabriquerait exactement le split-brain que le test cherche à démontrer.

6 · Test 7.13 — la non-régression du cloisonnement

Ce qu’il prouve : avoir ajouté trois machines, un répartiteur et quatre ports au plan n’a pas ouvert de brèche. C’est le test qu’on oublie toujours, et celui qui rassure un jury.

Depuis poste-win11, en PowerShell :

Test-NetConnection -ComputerName 10.0.20.10 -Port 3306

Puis, pour la preuve complète, le journal : Status → System Logs → Firewall, filtre sur 10.0.20.10. Un test de blocage sans sa ligne de journal n’est pas une preuve — c’est la règle posée depuis le test 7.3.

Et tant qu’on y est, vérifier aussi le nouveau nœud :

Test-NetConnection -ComputerName 10.0.20.11 -Port 3306

→ également refusé. Les trois nœuds Galera sont couverts par le même cloisonnement.

7 · Ordre conseillé et durée

  1. Sauvegarde logique de wp_lab                            2 min
  2. Tableau de bord sur les 3 nœuds — état initial          2 min   
  3. Test 7.10 — bascule                                     10 min  
  4. Retour à 3 nœuds Synced, vérifié                        3 min
  5. Test 7.11  — quorum                                   15 min  
  6. Retour à 3 nœuds Synced, vérifié                        5 min
  7. Test 7.13 — non-régression + journal pfSense            5 min   

Compter 45 minutes sans se presser. Les captures sont nommées selon la convention habituelle NN-description.png.

La règle du TP s’applique ici comme ailleurs : on ne documente que ce qu’on a vu. Si un test donne autre chose que l’attendu, c’est le résultat observé qui part dans la documentation, avec l’explication. Les trois quarts des incidents du fichier Troubleshooting.md sont nés comme ça.

Q4 · La sauvegarde Proxmox est-elle incrémentale ?

1 · La réponse courte

Non, pas avec vzdump vers un NAS : chaque nuit, chaque VM est recopiée en entier dans une nouvelle archive. Constat du 15/10 : l’archive de srv-web-01 était identique à l’octet à celle de la veille, et le NAS a grossi d’environ 85 Go en une nuit pour 11 VM.

2 · Ce qui le rend incrémental : Proxmox Backup Server

3 · Ce qui a été décidé

Passer à PBS (VM srv-pbs, 10.0.30.13), garder 7 jours de sauvegardes, sans chiffrement côté client. Réalisé et documenté le 15/10 : MO-12, étape 44 de Documentation-pfSense.md.

Q5 · Iowait ou latence disque : quelle différence ?

Question posée. « C’est quoi la différence entre iowait et latence en termes d’interprétation ? Faut-il définir un seuil ? » (28/10, en construisant le bloc « disques » du tableau de production)

Ce qui a été retenu : le tableau affiche la latence, comparable sur toutes les machines ; l’iowait reste interrogeable dans Explore. Seuils : 20 ms (orange) et 50 ms (rouge), repères courants (Microsoft notamment), sur une échelle logarithmique pour qu’un pic de plusieurs secondes n’écrase pas les valeurs normales (1 à 10 ms). Constat : de 100 ms à 1 s du 21 au 24/10 (migration des disques), 1 à 10 ms ensuite.

Q6 · Une nouvelle VM apparaît-elle toute seule dans le tableau de bord ?

Question posée. « Si j’ajoute une VM, avec l’exporteur qui va bien grâce au script, ça s’ajoutera automatiquement au tableau dans chaque bloc ? » (28/10)

ajouter-machine.sh (VM Linux, lancé depuis le bastion) installe node_exporter et rsyslog, puis déclare la machine dans Prometheus avec son nom (host) et sa zone (zone). Ensuite :

VM Windows : installer-windows-exporter.ps1 installe l’exporteur et ouvre le port 9182 pour srv-metriques seulement, mais ne déclare pas la machine : il faut ajouter un fichier de cible dans /etc/prometheus/cibles/windows/.

Depuis le 11/11 (phase 21) : un poste Windows du domaine reçoit l’exporteur par la GPO GPO-Ordi-Poste-Pret, et sa déclaration se fait en une commande depuis le bastion : bash ~/supervision/ajouter-poste-windows.sh <nom> <adresse> (étape 74). Les règles d’alerte sont génériques : le poste est couvert dès qu’il est « up ».

Q7 · Pourquoi le site public de GSB n’a-t-il pas de bandeau de cookies ?

Réponse courte — Parce que la mesure d’audience de ce site entre dans l’exception prévue par la CNIL : elle peut se faire sans consentement si elle reste strictement limitée à la mesure de fréquentation du seul site, avec des réglages précis. Un bandeau n’est donc pas obligatoire ; en échange, le site doit informer les visiteurs et leur donner un moyen simple de refuser.

Les conditions, et ce qui a été fait (détail et preuves : Justification-RGPD-Matomo.md) :

Ce que ça ne couvre pas — un cookie qui servirait à la publicité, à un profil ou à un outil tiers redemanderait un consentement. Et la dispense est à justifier par l’éditeur (c’est l’objet de la justification écrite) : elle n’a pas été validée par un juriste.