SkyMinds ~ by Matt | Page 3 | Formateur et Développeur WordPress

Illustration de deux icônes de serveur de base de données, d'un dossier et d'un ordinateur portable affichant des graphiques, le tout relié par des lignes pointillées sur un fond bleu dégradé. Un grand texte superposé indique "MySQL 8.4 LTS" en orange et blanc, mettant en évidence la migration MySQL 8.4.

Ubuntu Server : migration vers MySQL 8.4 LTS

11 octobre 2025 by Matt Biscay · Lecture: 11 minutes

Voici venu le temps de mettre à jour MySQL 8.0 vers MySQL 8.4 LTS sur notre serveur Ubuntu 24.04 Noble, pour plus de performance, sécurité et stabilité.

Changements clés entre MySQL 8.0 et MySQL 8.4 LTS

Vue d’ensemble

MySQL 8.4 est une version LTS (Long Term Support) donc la cadence des mises à jour est stable, continue, avec peu de ruptures.

Sécurité et authentification

mysql_native_password désactivé par défaut. Le plugin existe encore, mais n’est plus chargé en 8.4. Résultat : les comptes qui l’utilisent échouent à l’authentification jusqu’à ce que vous le réactiviez (temporaire) ou que vous migriez les comptes vers caching_sha2_password.
Paramètres changent : l’ancien default_authentication_plugin est retiré ; utilisez désormais la politique d’authentification actuelle (et migrez les comptes).

Outils et commandes retirés / modifiés

Retirés : mysql_upgrade (mise à niveau du dictionnaire gérée automatiquement au démarrage du serveur) et mysqlpump (préférez mysqldump ou les utilitaires de MySQL Shell).
Terminologie réplication : nettoyage achevé (adieu les anciennes commandes “master”). Utilisez les variantes modernes (SHOW BINARY LOG STATUS, etc.).

InnoDB et perfs (nouveaux défauts)

8.4 affine plusieurs valeurs par défaut pour mieux coller au matériel actuel (I/O, concurrency). Attendez-vous à des valeurs plus agressives pour la capacité I/O et des toggles historiques coupés par défaut (ex. Adaptive Hash Index OFF). Vérifiez vos overrides côté mysqld.cnf.

SQL, DDL & privilèges

Interdiction définitive : AUTO_INCREMENT sur FLOAT/DOUBLE — toléré (déprécié) en 8.0, erreur en 8.4. Corrigez avant de migrer (changez de type ou retirez l’AUTO_INCREMENT).
Nouveaux privilèges plus fins : SET_ANY_DEFINER et ALLOW_NONEXISTENT_DEFINER remplacent l’ancien SET_USER_ID (retiré). Utile pour sécuriser routines/triggers avec DEFINER.

LTS : ce que ça change opérationnellement

Les versions 8.4.x apportent surtout des corrections et des ajustements à faible risque. Les notes de version par point release (8.4.4, 8.4.5, 8.4.6…) détaillent les bugfixes et micro-améliorations.

Checklist de migration de MySQL 8.0 vers MySQL 8.4

1. Audit pré-upgrade

Lisez la page « What’s new in 8.4 since 8.0 » et la section “Changes in MySQL 8.4” pour repérer ce qui casse chez vous (options retirées, syntaxes interdites).
Cherchez AUTO_INCREMENT sur FLOAT/DOUBLE dans votre schéma et corrigez.
Passez un coup d’œil à vos my.cnf : supprimez default_authentication_plugin, autres options dépréciées 8.0, et adaptez si besoin.

2. Authentification (le vrai sujet qui casse les apps)

Option A (transitoire) : réactivez le plugin legacy pour rallumer vite vos apps, puis migrez proprement:

# nano /etc/mysql/mysql.conf.d/mysqld.cnf 

[mysqld]
mysql_native_password=ON Code language: PHP (php)

Redémarrez MySQL, puis planifiez la migration de tous les comptes vers caching_sha2_password.

Option B (propre, recommandée) : migrez chaque compte applicatif :

ALTER USER 'app_user'@'localhost'
  IDENTIFIED WITH caching_sha2_password BY 'MotDePasseSolide!';
FLUSH PRIVILEGES;Code language: JavaScript (javascript)

PHP 8.x et mysqlnd gèrent caching_sha2_password nativement.

3. Réplication & scripts

Mettez à jour scripts et dashboards qui appellent les anciennes commandes “master/slave”. Utilisez SHOW REPLICA STATUS, SHOW BINARY LOG STATUS, etc.

4. Outils & automatisation

Retirez mysql_upgrade de vos playbooks ; le serveur fait le nécessaire au démarrage.
Remplacez mysqlpump si vous l’utilisiez.

5. Post-upgrade

Lisez les notes de votre point release (8.4.x) et surveillez les journaux au premier démarrage.

Bloquer complètement l’énumération des utilisateurs WordPress avec Nginx ou Apache

04 octobre 2025 by Matt Biscay · Lecture: 8 minutes

Lorsque vous gérez un site WordPress, la sécurité doit être une priorité. Parmi les failles les plus méconnues, il existe ce qu’on appelle l’énumération des utilisateurs.

Mais qu’est-ce que c’est exactement ?

En résumé, l’énumération des utilisateurs consiste à découvrir publiquement les noms d’utilisateurs de votre site WordPress. Pourquoi est-ce un problème ? Parce que si un pirate connaît déjà votre nom d’utilisateur, il ne lui reste plus qu’à deviner ou voler le mot de passe. En d’autres termes, c’est comme si vous laissiez la moitié de la clé de votre maison sur la porte.

Comment fonctionne l’énumération des utilisateurs ?

Par défaut, WordPress crée certaines adresses (URLs) qui permettent de révéler les noms d’utilisateurs. Ces URLs sont accessibles à tout le monde sur Internet, même sans être connecté à votre site.

Voici quelques exemples (remplacés par example.com) :

https://example.com/?author=1
https://example.com/author/admin
https://example.com/?author={num:1}
https://example.com/wp-sitemap-users-1.xml
https://example.com/wp-json/wp/v2/users

Si vous ouvrez ces adresses dans votre navigateur, vous risquez de voir apparaître des informations sur vos utilisateurs WordPress (souvent l’administrateur du site). Et vous pouvez imaginer ce que cela représente pour un pirate : un point d’entrée facile.

Pourquoi est-ce dangereux ?

Les pirates peuvent scanner automatiquement ces URLs avec des outils comme WPScan.
Une fois le nom d’utilisateur trouvé, ils peuvent lancer des attaques par force brute pour tester des milliers de mots de passe.
Cela augmente fortement les risques de piratage de votre site.

En clair : si vous laissez l’énumération des utilisateurs active, vous donnez gratuitement une information critique aux attaquants.

Comment envoyer un email à l’administrateur après un redémarrage de serveur

13 septembre 2025 by Matt Biscay · Lecture: 3 minutes

Vous souhaitez être immédiatement informé dès qu’un serveur redémarre ? Que ce soit pour suivre des serveurs de production, détecter des redémarrages inattendus ou simplement valider la disponibilité après une maintenance, recevoir un email automatique est pratique et rassurant.

Dans ce tutoriel, nous allons mettre en place un mécanisme simple, fiable et totalement automatisé sous Linux.

Prérequis

Avant de commencer, assurez-vous de disposer de :

Un serveur Linux avec accès root ou sudo.
Un serveur de mail local ou distant configuré (Postfix, Exim, etc.).
Le paquet mailutils ou équivalent installé pour envoyer des emails depuis la ligne de commande.

Pour installer mailutils sur Debian/Ubuntu :

sudo apt update
sudo apt install mailutils -y

Étape 1 : créer un script d’envoi d’email

Nous allons créer un script simple qui enverra un email à l’administrateur. Il inclura le MOTD (Message of the Day) pour vous donner immédiatement des informations sur le serveur.

Créez le fichier :

sudo nano /home/scripts/send-reboot-email.sh

Ajoutez le contenu suivant :

#!/bin/bash

# Destinataire
TO="admin@example.com"

# Objet de l'email
SUBJECT="Serveur redémarré - $(hostname)"

# Récupération du MOTD dynamique si disponible
if [ -x "$(command -v run-parts)" ] && [ -d /etc/update-motd.d ]; then
    MOTD=$(run-parts /etc/update-motd.d)
elif [ -f /etc/motd ]; then
    MOTD=$(cat /etc/motd)
else
    MOTD="Aucun MOTD disponible"
fi

# Corps de l'email
BODY="Le serveur $(hostname) vient de redémarrer.
Date : $(date)

--- MOTD ---
$MOTD
"

# Envoi de l'email
echo "$BODY" | mail -s "$SUBJECT" "$TO"Code language: PHP (php)

Rendez le script exécutable :

sudo chmod +x /home/scripts/send-reboot-email.sh

Étape 2 : créer un service systemd

Pour exécuter le script automatiquement après un redémarrage et seulement lorsque le serveur de mail est opérationnel, nous allons créer un service systemd.

Créez le fichier de service :

sudo nano /etc/systemd/system/reboot-email.service

Ajoutez le contenu :

[Unit]
Description=Envoyer un email après le redémarrage
After=network.target postfix.service
Requires=postfix.service

[Service]
Type=oneshot
ExecStart=/home/scripts/send-reboot-email.sh
RemainAfterExit=true

[Install]
WantedBy=multi-user.targetCode language: JavaScript (javascript)

Ajustez postfix.service si vous utilisez un autre serveur de mail.

Rechargez systemd et activez le service :

sudo systemctl daemon-reload
sudo systemctl enable reboot-email.serviceCode language: CSS (css)

← Précédent Suivant →

Changements clés entre MySQL 8.0 et MySQL 8.4 LTS

Vue d’ensemble

Sécurité et authentification

Outils et commandes retirés / modifiés

InnoDB et perfs (nouveaux défauts)

SQL, DDL & privilèges

LTS : ce que ça change opérationnellement

Checklist de migration de MySQL 8.0 vers MySQL 8.4

1. Audit pré-upgrade

2. Authentification (le vrai sujet qui casse les apps)

3. Réplication & scripts

4. Outils & automatisation

5. Post-upgrade

Comment fonctionne l’énumération des utilisateurs ?

Pourquoi est-ce dangereux ?

Prérequis

Étape 1 : créer un script d’envoi d’email

Étape 2 : créer un service systemd

Étape 1 : créer un script d’envoi d’email

Étape 2 : créer un service systemd