LINUX:MariaDB

De WIKI sur Linux (ADB)
Aller à la navigation Aller à la recherche

→ retour au menu des bases de données relationnelles

But

MariaDB est un gestionnaire de base de données client-serveur utilisant le langage SQL. Il fait suite à MySQL. Il est souvent utilisé au même titre que PostgreSQL, autre gestionnaire de base de données.


Installation

On a besoin d'installer un package qui installera les dépendances nécessaires: 

dnf install mariadb-server


Configuration

Les fichiers de configurations se trouvent dans le répertoire "/etc/my.cnf.d". Parmi ceux-ci, un seul nous intéresse: mariadb-server.cnf".

Par défaut, la base de données se crée dans le répertoire "/var/lib/mysql" mais nous préférons l'installer sur un disque à part. Dans notre cas, nous choisissons le répertoire "/produc/mysql".

Il faut le créer: 

mkdir /produc/mysql

Il faut le faire appartenir à l'utilisateur pour lequel le service est lancé: 

chown -R mysql:mysql /produc/mysql

et les privilèges: 

chmod -R 660 /produc/mysql

Maintenant, il faut modifier le fichier configuration du serveur MariaDB, "/etc/my.cnf.d/mariadb-server.cnf". On modifie ou ajoutons quelques options sous la section "[mysqld]": 

[server]
[mysqld]
# répertoire contenant la base de données
datadir=/produc/mysql
# Socket, PID, journaux: de préférence, ne pas modifier
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
# niveau de journalisation, utile pour Fail2Ban
log-warnings=2
# nécessaire pour OPAC et WATERBEAR
ft_min_word_len = 1
# divers options à adapter en fonction de l'utilisation
sql-mode="NO_ENGINE_SUBSTITUTION"
max_allowed_packet=64M
innodb-log-file-size=256M
character-set-server=utf8
open_files_limit = 10000

L'option "datadir" définit le répertoire où se placera la base de données comme suggéré ci-dessus.


Activation et lancement du service

Le service à lancer est "mariadb.service". La première commande active le service pour qu'à chaque démarrage du serveur, le service se lance. La seconde lance directement le service. La troisième relance le service. 

systemctl enable mariadb.service
systemctl start mariadb.service
systemctl restart mariadb.service


Sécurité

Lors du premier lancement du serveur, la base de données va être initialisée. Attention, si vous introduisez l'option "ft_min_word_len=1" vue ci-dessus, à postériori, vous devrez effectuer une mise à niveau de la base de données, une réindexation.

A ce stade, il n'existe qu'un utilisateur "root" ayant tous les privilèges mais sans mot de passe. Il est primordial de mettre un mot de passe. En outre, il y existe dans certaines configurations de base un schéma de "test" qui est à supprimer.

Exécutez le script Linux suivant: 

mysql_secure_installation

A la majorité des questions de type "Yes or No" (Y/n), on répond "Y" et on donne un mot de passe. Voici un exemple: 

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!
.
In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
haven't set the root password yet, you should just press enter here.
.
Enter current password for root (enter for none):
OK, successfully used password, moving on...
.
Setting the root password or using the unix_socket ensures that nobody
can log into the MariaDB root user without the proper authorisation.
.
You already have your root account protected, so you can safely answer 'n'.
.
Switch to unix_socket authentication [Y/n] n
 ... skipping.
.
You already have your root account protected, so you can safely answer 'n'.
.
Change the root password? [Y/n] y
New password:<MOT_DE_PASSE_ROOT>
Re-enter new password:<MOT_DE_PASSE_ROOT>
Password updated successfully!
Reloading privilege tables..
 ... Success!
.
By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.
.
Remove anonymous users? [Y/n] Y
 ... Success!
.
Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.
.
Disallow root login remotely? [Y/n] Y
 ... Success!
.
By default, MariaDB comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.
.
Remove test database and access to it? [Y/n] Y
 - Dropping test database...
 ... Success!
- Removing privileges on test database...
 ... Success!
.  
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
.
Reload privilege tables now? [Y/n] Y
 ... Success!
.
Cleaning up...
.
All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.
.
Thanks for using MariaDB!

Par ce moyen, on ne peut accéder à la base de données que localement. Mais si on se connecte avec un utilisateur Linux "root" ou "mysql", le mot de passe n'est pas nécessaire. Notons que dans les dernières versions, le schéma "test" n'est pas créé.


Vous pouvez aussi utiliser les commandes de ligne SQL, ce que je préfère.

  • Changer le mot de passe de l'utilisateur "root"; au passage, on lui confirme tous les privilèges.

Voici le script SQL à mettre dans un fichier du nom, par exemple, "user.root.sql": 

alter user 'root'@'localhost' identified by 'MOT_DE_PASSE_ROOT' ;
grant all privileges on *.*   to 'root'@'localhost' with grant option ;
flush privileges ;

On exécute la ligne de commande Linux suivante sans mot de passe car il n'y en a pas encore: 

mysql --user=root < user.root.sql

On remarque derrière le nom d'utilisateur "root", le terme "localhost"; il définit l'étendue du réseau ayant accès à la base de données, le FireWall étant une seconde couche de sécurité. Dans ce cas, l'utilisateur "root" ne peut accéder à la base de données qu'à partir de la même machine. Si au lieu de "localhost", on avait mis "%", cette utilisateur peut se trouver n'importe où sur le réseau ou Internet afin d'accéder à la base de données avec tous les droits.

  • Eliminer l'utilisateur "mysql".

Voici le script SQL à mettre dans un fichier du nom, par exemple, "user.mysql.sql": 

drop user 'mysql'@'localhost' ;
flush privileges ;

On exécute la ligne de commande Linux suivante avec le mot de passe cette fois: 

mysql --user=root --password=MOT_DE_PASSE_ROOT < user.mysql.sql
  • Eliminer le schéma "test" s'il existe.

Voici le script SQL à mettre dans un fichier du nom, par exemple, "drop.test.sql": 

DROP SCHEMA IF EXISTS test ;

On exécute la ligne de commande Linux suivante avec aussi le mot de passe: 

mysql --user=root --password=MOT_DE_PASSE_ROOT < drop.test.sql

Pour connaître le nom des schémas présents dans la base de données, il suffit de consulter la liste des sous-répertoires contenus dans le répertoire racine de la base de données ("/produc/mysql"). Si le sous-répertoire "test" n'existe pas, la commande ci-dessus est inutile. Deux schémas spéciaux ne peuvent être éliminés "mysql" et "performance_schema".

Notons qu'à ce stade, il n'y a rien dans la base de données. Si on fait une mauvaise manipulation, il suffit de recommencer.

  • On commence par arrêter le service mariadb.
  • On efface tout le contenu du répertoire racine de la base de données ("/produc/mysql").
  • On relance le service mariadb.

Tout est réinitialisé.


Cet utilisateur "root" a tous les droits mais il peut être remplacé par un autre. L'utilisation de ce dernier doit être réservé pour des tâches générales de gestion, par exemple pour la gestion de schémas, sauvegarde,...). Pour tout autre action, il faut créer des utilisateurs affectés à une tâche précise; cet utilisateur doit avoir des privilèges juste nécessaires à sa fonction. Par exemple, si une application WEB doit accéder à un schéma, un utilisateur spécifique est créé auquel on ne donne que les droits d'accès nécessaire à ce schéma sur une machine précise; idéalement, il ne devrait pas pouvoir modifier la structure du schéma ni ses privilèges; si cette application n'a qu'un droit de consultation, il n'aura que les droits SQL de type "select". Il est évident qu'une action malveillante venant d'un point quelconque du monde peut potentiellement dégrader ou détruire ce schéma. Il faut essayer au maximum de séparer ces tâches, de protéger les tâches les plus cruciales. Mais on assiste de plus en plus à une complète ouverture dans nombre d'applications.


Configurer le mur de feu ou FireWall

Normalement, on doit désactiver l'accès à distance à cette base de données. En l'état il n'y a pas d'utilisateur configuré pour cela.


Vous pouvez explicitement ajouter une règle au FireWall qui rejette ces demandes d'accès en fonction de la configuration. Normalement une bonne configuration doit tout rejeter sauf ce qui est explicitement permis. Le port par défaut est 3306.

Voici cette règle pour IPTABLES: 

-A INPUT -p tcp -m tcp --dport 3306 -j DROP

Par contre, si on veux y accéder à distance, il faut ajouter un utilisateur adéquat et ajouter une règle au FireWall.

Dans l'exemple, notre LAN permet l'accès; son adressage est 192.168.1.0 avec un masque de 255.255.255.0 ou de 24 bits. Nous utilisons IPTABLES; voici la ligne à ajouter: 

-A INPUT -p tcp -m tcp --dport 3306 -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT


Sauvegarde

Il prendre l'habitude de faire une sauvegarde journalière des schémas importants de la base de données. Ces sauvegardes seront sauvées dans un répertoire, par exemple "/produc/mysql.export" que l'on crée: 

mkdir /produc/mysql.export

Voici un script qui peut effectuer cette tâche que l'on nommera "mysqlsauvegarde.bat" et placé dans le répertoire "/cron/mysql": 

#!/bin/bash
# ***************************************************************************
# A adapter selon votre configuration
# Nom et mot de passe d'accès à la base de donnée
DBUSER=root
DBPW=MOT_DE_PASSE_ROOT
# Répertoire de sauvegarde
CHEMIN=/cron/mysql.export
# Liste des schémas à sauver (exemple pour deux schémas: dbwaterbear et dbwp")
LISTE="dbwaterbear dbwp"
# ***************************************************************************
# Boucle d'exportation pour chaque schéma
for DB in $LISTE
do
# Création d'un script SQL de création complète du schéma et de son contenu
 echo DROP SCHEMA IF EXISTS $DB \;                                     >  $CHEMIN/$DB.sql
 echo " "                                                              >> $CHEMIN/$DB.sql
 /usr/bin/mysqldump --user=$DBUSER --password=$DBPW  --databases  $DB  >> $CHEMIN/$DB.sql
 # Bébut de la partie facultative
 # Création d'un sous-répertoire qui contiendra un fichier texte par table
 if [ ! -d "$CHEMIN/$DB" ]; then
  /usr/bin/mkdir $CHEMIN/$DB
 fi
 /usr/bin/chmod 777 $CHEMIN/$DB
 # Sortie des données sous format texte
 # une ligne par enregistrement avec une tabulation entre chaque champs
 /usr/bin/mysqldump --user=$DBUSER --password=$DBPW  --lock-tables --no-create-info --compact --tab=$CHEMIN/$DB
 rm -f $CHEMIN/$DB/*.sql
 # Fin de la partie facultative
done

La partie facultative n'est pas nécessaire mais peut être utile pour un autre usage, par exemple, pour charger ce fichier dans un tableur (Excel) ou pour une analyse.

Un fichier de type "sql" est créé au nom du schéma.

On fait appel à ce script dans le Cron de Linux. On ajoute les lignes suivantes dans le fichier "/etc/crontab": 

# Sauvegarde mysql
45 23 * * * root /cron/mysql/mysqlsauvegarde.bat > /cron/mysql/mysqlsauvegarde.log

Ici on l'appelle tous les jours pendant la nuit à 23h45.


Cette sauvegarde est une première brique qui doit être intégrée dans processus plus étendu de sauvegarde (backup).


Restauration

Par malheur, il se peut que vous deviez restaurer un schéma suite à un problème majeur ou plus simplement si vous changez de serveur. Le script suivant permet de restaurer le schéma sauvé au point précédent. Par sécurité, on créè un répertoire à part par exemple "/produc/mysql.import": 

mkdir /produc/mysql.import

Quand la restauration survient, on y place le fichier de type SQL sauvé correspondant. 

#!/bin/bash
# La commande "exit" est placée pour éviter toute exécution intempestive
# Mettez cette ligne en commentaire (ajout de #) pour passer outre
exit
# ***************************************************************************
# A adapter selon votre configuration
# Nom et mot de passe d'accès à la base de donnée
DBUSER=root
DBPW=MOT_DE_PASSE_ROOT
# Répertoire où se trouve la sauvegarde à restaurer
CHEMIN=/produc/mysql.import
# Liste des schémas à restaurer (exemple pour deux schémas: dbwaterbear et dbwp")
# décommenter la ligne désirée
#LISTE="dbwaterbear"
#LISTE="dwp"
#LISTE="dbwaterbear dbwp"
# ***************************************************************************
# Boucle de restauration pour chaque schéma
for DB in $LISTE
do
 /usr/bin/mysql --user=$DBUSER --password=$DBPW  < ${CHEMIN}/$DB.sql
done


Création d'un schéma et de son utilisateur principal

De nombreuses applications nécessitent une base de données tel MariaDB. Elles ont besoins d'un schéma et d'un utilisateur principal y ayant tous les droits. Quelques exemples les plus connus: WordPress et MediaWiki (dont WikiPedia).

Nous exposons une méthode sous forme de scripts mais on peut utiliser des interfaces Web pour le faire interactivement tels PHPMyAdmin ou Adminer. Si nous avons à faire cette opération qu'une fois exceptionnellement, ces interfaces Web sont d'une utilisation aisée. Mais lorsqu'on gère un ou plusieurs serveurs hébergeants nombre d'applications, un script est vite multiplié et adapté en fonction des besoins. En outre on a une archive de ce qui a été fait et ces scripts sont utiles lorsqu'on doit refaire rapidement un serveur ou réparer une application suite à un crash ou un re-design.

J'ai très longtemps travaillé sur des serveurs Windows. Windows est la reine des interfaces graphiques; c'est très facile mais ça prend énormément de temps et on ne se souvient pas toujours des modifications apportées dans l'ancien serveur quand on passe à la version suivante sur un nouveau serveur. Un serveur Linux peut être refait complètement en une demi-journée sur base des scripts et des fichiers de configurations sauvés.


Pour la suite, nous prenons l'exemple d'une application MediaWiki qui va utiliser le schéma "dbwiki" avec l'utilisateur "userwiki".


Création du schéma

Pour créer le schéma dans la base de données Mysql, nous nous basons sur les informations suivantes:

  • Nom du schéma: dbwiki
  • Mot de passe de l'utilisateur root (à adapter): MOT_DE_PASSE_ROOT

Ces paramètres peuvent être adaptés à votre guise.


Ensuite il nous faut 2 fichiers.

Le premier fichier que l'on nomme "schema.sql", sert à créer le schéma vide; il élimine un éventuel schéma existant: 

DROP SCHEMA IF EXISTS dbwiki ;
CREATE SCHEMA dbwiki ;


Le second fichier que l'on nomme "import.bat", va créer ce schéma: 

#!/bin/bash
DBUSER=root
DBPW=MOT_DE_PASSE_ROOT
mysql --user=$DBUSER --password=$dbpw < schema.sql

Donnez les droits d'exécution au script Bash: 

chmod 700 import.bat

et exécutez le: 

./import.bat


Dans ce script, on peut ajouter l'initialisation du contenu de ce schéma s'il est nécessaire, par exemple dans le fichier "tables.sql". 

DBSCHEMA=dbwiki
mysql --user=$DBUSER --password=$DBPW -D $DBSCHEMA < tables.sql

Ce fichier peut aussi être une sauvegarde (dump) comme on l'a vu plus haut.


Création de l'utilisateur

Pour créer de l'utilisateur MySql qui permettra à l'application convoitée d'avoir tous les droits sur ce schéma, nous nous basons sur les informations suivantes:

  • Nom du schéma: dbwiki
  • Nom d'utilisateur: userwiki
  • Mot de passe de l'utilisateur userwiki (à adapter): PW_WIKI
  • Mot de passe de l'utilisateur root (à adapter): MOT_DE_PASSE_ROOT

Ces paramètres peuvent être adaptés à votre guise.

On ne donne accès à cet utilisateur à la base de données qu'à ce schéma dbwiki à partir seulement de la machine hôte, locale.


Pour y arriver, on crée 4 fichiers.

Le premier fichier que l'on nomme "dropuser.sql", sert à effacer un utilisateur préexistant: 

drop user 'userwiki'@'localhost' ;
drop user 'userwiki'@'127.0.0.1' ;
drop user 'userwiki'@'::1' ;


Le second que l'on nomme "createuser.sql", permet de créer l'utilisateur: 

create user 'userwiki'@'localhost'      identified by 'PW_WIKI' ;
create user 'userwiki'@'127.0.0.1'      identified by 'PW_WIKI' ;
create user 'userwiki'@'::1'            identified by 'PW_WIKI' ;


Le troisième que l'on nomme "grant.sql", va donner tous les droits sur ce schéma à cet utilisateur: 

grant all privileges on dbwiki.* to 'userwiki'@'localhost';
grant all privileges on dbwiki.* to 'userwiki'@'127.0.0.1';
grant all privileges on dbwiki.* to 'userwiki'@'::1';

Cet utilisateur n'a aucun droit sur les autres schémas ni d'administrer la base de données.


Enfin le dernier que l'on nomme "user.bat", va mettre en oeuvre cet ensemble: 

#!/bin/bash 
DBUSER=root
DBPW=MOT_DE_PASSE_ROOT
mysql --user=$DBUSER --password=$DBPW  < dropuser.sql
mysql --user=$DBUSER --password=$DBPW  < createuser.sql
mysql --user=$DBUSER --password=$DBPW  < grant.sql

Donnez les droits d'exécution au script Bash: 

chmod 700 user.bat

et exécutez le: 

./user.bat


Migration suite à une mise à jour

Si vous effectuez une mise à jour du logiciel MariaDB, il faut exécuter une procédure de mise à niveau de la base de données. Ceci se passe habituellement lors d'une mise à niveau de Linux par exemple en migrant de Fedora 39 vers Fedora 40.


On peut en détecter les symptômes en analysant les journaux de MariaDB "/var/log/mariadb/mariadb.log".

Si on y remarque des messages d'erreurs, un changement de certains paramètres peut résoudre ces problèmes mais la procédure de migration est souvent nécessaire et est recommandée.


La commande à exécuter est la suivante: 

mysql_upgrade --user=root --password=MOT_DE_PASSE_ROOT --force

vous adaptez le mot de passe de l'utilisateur "root" en fonction de votre configuration.




→ retour au menu des bases de données relationnelles

Récupérée de « https://www.adbweb.gslb.eu/wiki/index.php?title=LINUX:MariaDB&oldid=8274 »