Rocky Linux / Installer MariaDB et préparer les comptes applicatifs

Sous Rocky Linux, installez le paquet mariadb-server puis démarrez et activez le service mariadb. Vérifiez ensuite l’authentification administrative et les comptes initiaux, puis créez une base et un compte propres à l’application. Ce guide concerne une nouvelle installation avec les paquets de la distribution ; l’accès distant est une étape optionnelle qui demande aussi des règles réseau et TLS (Transport Layer Security, chiffrement des connexions).

Prévoyez un compte disposant de sudo, une console et une version de MariaDB compatible avec l’application et maintenue par votre fournisseur. Les étapes d’installation de base correspondent au guide MariaDB de Rocky Linux. Une installation existante, un changement de dépôt ou une mise à niveau majeure demandent un plan de sauvegarde et de migration distinct.

Vérifier les versions et les paquets disponibles

cat /etc/rocky-release
dnf info mariadb-server

Vérifiez la version proposée et le dépôt indiqué par dnf info. Sur les versions prenant en charge les modules, dnf module list mariadb affiche aussi les flux disponibles ; cette fonction n’existe pas dans toutes les implémentations de DNF. Choisissez les paquets Rocky ou ceux du dépôt MariaDB officiel selon les besoins de l’application et le cycle de maintenance. Les commandes ci-dessous supposent les paquets Rocky ; ne mélangez pas les paquets serveur de plusieurs dépôts.

Installer et démarrer MariaDB

Installer le paquet serveur

sudo dnf install mariadb-server

Vérifiez les paquets et la version du client. Le numéro retourné par mariadb --version est celui du client, pas une preuve de la version du serveur actif :

rpm -q mariadb-server
mariadb --version

Activer le service

sudo systemctl enable --now mariadb
systemctl status mariadb

Si le démarrage échoue, vérifiez les journaux suivants pour identifier la cause.

sudo journalctl -u mariadb -b --no-pager

Vérifier l'accès administrateur local

sudo env MYSQL_HISTFILE=/dev/null mariadb

Selon le paquet, le compte de base de données root utilise l’authentification unix_socket, qui vérifie l’identité du compte Linux par la connexion locale. Un mot de passe Linux et un mot de passe MariaDB sont distincts. La variable MYSQL_HISTFILE ci-dessus évite d’enregistrer les nouvelles instructions de cette session dans le fichier d’historique du client ; elle n’efface aucun historique antérieur et ne désactive pas les journaux du serveur. Le manuel du client mariadb décrit ce réglage. Dans cette session SQL (Structured Query Language, langage de requête des bases de données), contrôlez la version du serveur et le compte authentifié :

SELECT VERSION(), CURRENT_USER();

Le compte retourné doit correspondre à votre accès administratif, généralement root@localhost. Quittez le client avec exit; avant de revenir aux commandes du shell. Ne supprimez pas les fichiers du répertoire de données pour tenter de réparer une erreur de démarrage.

Configurer la sécurité initiale

sudo mariadb-secure-installation

L’outil propose de retirer les comptes anonymes, les comptes root distants et la base de test. Sur cette installation neuve, examinez chaque invite puis acceptez les suppressions qui correspondent à ces éléments inutiles. Si root utilise déjà unix_socket, conserver cette authentification locale peut éviter un mot de passe administratif supplémentaire. Ne répondez pas mécaniquement Y à toutes les questions : leur ordre et leur contenu dépendent de la version. La documentation de mariadb-secure-installation explique ces différences depuis MariaDB 10.4.

Après l’outil, vérifiez de nouveau que l’accès local administratif fonctionne et examinez la liste des comptes :

sudo env MYSQL_HISTFILE=/dev/null mariadb

SELECT User, Host FROM mysql.user ORDER BY User, Host;

Les lignes sans nom d’utilisateur correspondent aux comptes anonymes. Vérifiez leur absence et les hôtes autorisés pour root ; ne partagez pas une liste de comptes internes sans nécessité. Gardez cette session SQL pour les étapes de création suivantes.

Sur certains paquets, mysql_secure_installation reste le nom de compatibilité disponible. Si mariadb-secure-installation est introuvable, vérifiez l’exécutable fourni et utilisez la documentation de la version installée.

Créer la base de données et le compte de l'application

Créer une base de données

Les noms appdb et appuser supposent ici des objets nouveaux. Si la base ou le compte existe déjà, arrêtez-vous et vérifiez son usage ; ne le remplacez pas pour rejouer l’exemple. Les instructions suivantes s’exécutent dans le client MariaDB, pas directement dans le shell.

CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Le jeu de caractères utf8mb4 permet de stocker les caractères Unicode sur un à quatre octets. La collation choisie définit les règles de comparaison et de tri ; utf8mb4_unicode_ci n’est pas une recommandation universelle. Vérifiez les exigences de l’application et les collations disponibles dans la version utilisée.

Créer un utilisateur local uniquement

CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'replace-with-a-strong-secret';
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'appuser'@'localhost';

Remplacez replace-with-a-strong-secret par un secret unique avant d’exécuter le SQL et conservez-le dans le mécanisme de gestion des secrets de l’application. Ce compte reçoit seulement les droits de lecture et de modification des données de appdb ; il ne peut pas créer les tables nécessaires aux migrations. Prévoyez un rôle de déploiement distinct si l’application en a besoin. La syntaxe officielle de GRANT permet d’adapter ces droits au besoin réel.

Vérifier les autorisations

SHOW GRANTS FOR 'appuser'@'localhost';

SHOW GRANTS doit afficher les quatre privilèges accordés sur appdb.* et aucun privilège global excessif. Les instructions normales CREATE USER et GRANT prennent effet sans ajouter systématiquement FLUSH PRIVILEGES. Ne modifiez pas les tables de privilèges directement. Testez ensuite le compte avec une petite table créée par l’administrateur dans cette nouvelle base :

CREATE TABLE appdb.install_check (id INT PRIMARY KEY, message VARCHAR(100));
INSERT INTO appdb.install_check VALUES (1, 'installation-ok');

Quittez avec exit;, puis ouvrez une connexion locale par socket avec le compte de l’application :

mariadb --protocol=socket --user=appuser --password appdb

SELECT CURRENT_USER(), DATABASE();
SELECT id, message FROM install_check;

Les résultats doivent identifier appuser@localhost, la base appdb et la ligne 1, installation-ok. Le mot de passe est demandé à l’invite. Ce test utilise volontairement un socket local : une connexion TCP vers 127.0.0.1 n’est pas nécessairement associée au même compte Host. Quittez cette session avant de poursuivre dans le shell.

Autoriser l'accès à distance de manière sélective

Vérifier les paramètres d’écoute actuels

Cette partie suppose un client distinct sur un réseau privé ou un VPN (réseau privé virtuel). 192.0.2.20 représente le serveur et 192.0.2.10 le client : ce sont des adresses de documentation à remplacer. Consultez les paramètres du serveur actif et le port d’écoute TCP (Transmission Control Protocol) :

sudo mariadb -e "SHOW GLOBAL VARIABLES WHERE Variable_name IN ('bind_address','port','skip_networking','have_ssl');"
sudo ss -lntp 'sport = :3306' 

Relevez les fichiers réellement chargés par le paquet et leurs inclusions, souvent /etc/my.cnf et /etc/my.cnf.d/. Sauvegardez les fichiers avant d’éditer leurs chemins exacts avec sudoedit. Les options imprimées par un programme lancé séparément ne prouvent pas à elles seules la configuration du service déjà actif ; vérifiez aussi les variables du serveur et la commande de lancement de l’unité systemd.

Choisir l’adresse d’écoute du serveur

Dans un fichier de configuration effectivement chargé par le service, choisissez une adresse réelle de l’interface privée du serveur. La directive suivante remplace la valeur correspondante ; évitez les options contradictoires dans plusieurs fichiers :

[mysqld]
bind-address = 192.0.2.20
skip-networking = 0

bind-address choisit une adresse du serveur, pas celle du client. Avec cette adresse unique, l’écoute TCP sur la boucle locale n’est plus incluse ; l’administration par socket peut rester disponible. skip-networking = 0 permet l’écoute TCP. Consultez le guide de l’accès distant MariaDB pour les différences selon la version.

Préparer TLS avant la connexion distante

Faites préparer un certificat serveur et sa clé privée, ainsi que la chaîne de l’autorité de certification (CA). Le certificat doit correspondre au vrai nom DNS (système de noms de domaine) utilisé par le client. Le nom db.internal.example utilisé plus loin est un exemple à remplacer ; il doit résoudre vers l’interface prévue.

Placez les fichiers dans un emplacement protégé lisible par le service MariaDB. La clé privée doit rester inaccessible aux autres utilisateurs, par exemple avec un propriétaire root, le groupe du service mysql et des permissions 0640, dans un répertoire aux accès adaptés. Conservez des contextes SELinux appropriés. Les chemins suivants sont des exemples absolus à remplacer par ceux des fichiers réellement installés :

[mysqld]
ssl-ca = /etc/my.cnf.d/certificates/ca.pem
ssl-cert = /etc/my.cnf.d/certificates/server-cert.pem
ssl-key = /etc/my.cnf.d/certificates/server-key.pem

Ces options vont dans un fichier serveur chargé, aux côtés des paramètres d’écoute ; ne recréez pas aveuglément un autre fichier contradictoire. Les automatismes TLS diffèrent entre versions. Vérifiez le résultat plutôt que de supposer le chiffrement actif. Le guide TLS de MariaDB présente les options et les différences de version.

Créer le compte distant et restreindre le pare-feu

Ouvrez de nouveau une session administrative locale si vous l’avez quittée : sudo env MYSQL_HISTFILE=/dev/null mariadb. Créez uniquement le compte distant nécessaire, avec un secret distinct remplacé avant exécution. Le couple nom/hôte identifie le compte : appuser@localhost et appuser@192.0.2.10 sont deux comptes séparés. L’adresse doit correspondre à la source vue par MariaDB, après une éventuelle traduction réseau.

CREATE USER 'appuser'@'192.0.2.10' IDENTIFIED BY 'replace-with-a-strong-secret' REQUIRE SSL;
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'appuser'@'192.0.2.10';
SHOW GRANTS FOR 'appuser'@'192.0.2.10';

REQUIRE SSL impose TLS à ce compte, sans exiger un certificat client. La documentation de CREATE USER détaille cette condition. Quittez avec exit;. Avec firewalld actif, vérifiez la zone réellement appliquée avant la commande suivante ; public est un exemple. Auditez les autres règles qui pourraient déjà autoriser des sources plus larges :

sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.10/32" port port="3306" protocol="tcp" accept'

Cette règle n’est ajoutée qu’à l’état actif, pour une adresse IPv4 unique (/32). Les autres équipements et groupes de sécurité doivent autoriser le trajet prévu. Le guide de firewalld sur Rocky Linux explique les zones et les configurations active et permanente. Enregistrez la règle seulement après le test réussi ci-dessous.

Appliquer les paramètres et tester la connexion

Le redémarrage coupe les connexions existantes : planifiez-le. Vérifiez ensuite que le service est actif et écoute sur l’adresse attendue. Si le démarrage échoue, consultez sudo journalctl -u mariadb -n 50 --no-pager, corrigez les chemins, permissions ou options en cause, ou restaurez les lignes sauvegardées. Ne réinitialisez pas la base.

sudo systemctl restart mariadb
sudo systemctl status mariadb
sudo ss -lntp 'sport = :3306'

Depuis le client autorisé, utilisez un client MariaDB compatible avec les options suivantes et le certificat racine de confiance obtenu auprès de votre CA. Remplacez le nom d’hôte et le chemin absolu ; gardez les options de vérification explicites :

mariadb --host=db.internal.example --port=3306 --user=appuser --password \
  --ssl --ssl-ca=/chemin/ca-racine.pem --ssl-verify-server-cert appdb

L’option --password sans valeur demande le secret à l’invite. Ne placez pas le mot de passe dans les arguments du shell. Le certificat doit être accepté par la CA et correspondre au nom du serveur ; si la vérification échoue, corrigez cette cause plutôt que de désactiver le contrôle.

Dans cette session distante, vérifiez le compte effectivement sélectionné, la base et le chiffrement de la session :

SELECT CURRENT_USER(), DATABASE();
SHOW SESSION STATUS LIKE 'Ssl_version';
SHOW SESSION STATUS LIKE 'Ssl_cipher';
SELECT id, message FROM install_check;

Les résultats attendus sont le compte distant correspondant à la source autorisée, appdb, une version TLS et un chiffrement non vides, puis la ligne 1, installation-ok. Dans une session administrative locale, SHOW GLOBAL VARIABLES LIKE 'have_ssl'; doit indiquer YES, mais ce seul indicateur serveur ne prouve pas qu’une session particulière est chiffrée.

Vérifiez qu’une nouvelle connexion depuis une source non autorisée échoue et qu’une tentative sans TLS ne peut pas utiliser le compte distant. Après succès, quittez le client puis, sur le serveur MariaDB, enregistrez uniquement la règle firewalld ajoutée :

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.10/32" port port="3306" protocol="tcp" accept'

La règle active ayant déjà été ajoutée, aucun rechargement n’est nécessaire pour ce test. Pour annuler cet accès, retirez seulement cette règle avec --remove-rich-rule dans l’état actif et, si elle a été enregistrée, avec --permanent. Ne retirez pas une règle préexistante. Le compte distant nouvellement créé peut être supprimé par l’administrateur avec DROP USER 'appuser'@'192.0.2.10';, après arrêt de ses utilisateurs. Restaurez les paramètres d’écoute sauvegardés si vous les abandonnez.

Une fois les tests terminés, l’administrateur peut supprimer uniquement la table d’essai créée ici avec DROP TABLE appdb.install_check;. Gardez la base et les comptes réellement nécessaires à l’application.

Vérifications avant mises à jour et sauvegardes

• Sauvegardez les données avec une méthode cohérente, par exemple un export logique adapté avec mariadb-dump ou une sauvegarde physique préparée avec mariadb-backup ; une copie de fichiers à chaud ne suffit pas. Sauvegardez aussi la configuration et testez la restauration sur un autre système.
• Avant de changer de version majeure, vérifiez les notes de version, les fonctionnalités supprimées et la compatibilité des jeux de caractères et des interclassements.
• Après une mise à jour du paquet, vérifiez la documentation de la version installée pour voir s'il est nécessaire d'exécuter mariadb-upgrade.
• Surveillez l'utilisation du disque, les connexions, les requêtes lentes, l'état de la réplication et les journaux d'erreurs.
• Protégez les identifiants de l'application avec les permissions du fichier de configuration ou un système de gestion des secrets.

Questions fréquemment posées

sudo mariadb fonctionne, mais mariadb -u root -p échoue.

Cela peut être dû au fait que le compte root utilise l'authentification par socket Unix. Vérifiez le plugin d'authentification actuel et, sauf raison spécifique, conservez la méthode d'accès de l'administrateur local.

L'accès externe ne fonctionne pas

Vérifiez bind-address, la valeur Host du compte utilisateur distant, l'état de réception du port 3306, firewalld et les groupes de sécurité cloud dans l'ordre.

Est-il acceptable d'ouvrir le port 3306 à Internet entier ?

Il n'est pas recommandé. Limitez-le à l'adresse fixe du serveur d'application ou au réseau privé, et utilisez VPN, TLS et des comptes à privilèges minimaux simultanément.

Puis-je utiliser mysql_secure_installation ?

Il peut être fourni comme nom de compatibilité, mais le nom actuel dans la documentation MariaDB est mariadb-secure-installation. Vérifiez l'exécutable installé et la documentation de la version.