|

Apps – MariaDB

ParErwan Guillemard

J’ai toujours préférer les otaries aux dauphins 🙂 Je crois que l’un des mes plus gros choques (et pas phoques, à une lettre prés ça n’a plus le même sens !) de mes études et mon implication dans le monde de l’opensource a été le rachat de MySQL par SUN puis ORACLE.

Je n’ai pas bien compris dans un premier temps pourquoi un géant tel qu’ORACLE avait besoin d’acquérir un « petit » tel que MySQL. Puis après quelques soirées à refaire le monde, à boire plus que de raison et hoqueter des requêtes SQL en fin de soirée que ma petite vertu de la BDD relationnel à disparu.

Commençant à me dire que MySQL deviendrait payant comme ORACLE et donc inaccessible pour ma curiosité et appétit intellectuel, je commençais à planifier d’écouter la compilation intégrale d’Evanescence (fraichement téléchargement sur MegaUpload) sous la douche (habillé naturellement) tout en me lamentant sur mon sort et avenir.

Mais voyez vous, bien que je n’ai rien contre Evanescence, une lueur est apparu dans le néant de mes canalisations. Le fork de MySQL était là devant moi, le Dauphin c’était métamorphosé en Otarie (aussi douce qu’un wapiti), venant rassurer le jeune étudiant que j’étais.

Ouai t’as surtout pris une méga caisse sur Dijon, d’ailleurs t’as terminé dans la fontaine Wilson…

Bon, vous conviendrez que nous distinguons facilement les articles rédigés tard dans la nuit ou tôt le matin.

J’aborde dans cet article, l’installation de MariaDB. Vous me direz qu’il n’y a rien de bien sorcier et pourtant vous ne pouvez pas savoir ô combien je me suis cassé les dents sur l’implémentation de se SGBD sur un système DURCI RHEL avec une partition dédiée. Etant un grand utilisateur des solutions open sources et communautaires, ce billet sera automatiquement déterré lorsque j’aurais besoin de MariaDB.

Prérequis

Installation – Mariadb

Si vous êtes sur un environnement durci, avant de lancer les installations il y a quelques choses à faire, sinon vous allez être marron 🙂

J’ai choisi de réaliser l’installation de Mariadb-server dans sa version 10.6. Et pourquoi pas la version 10.3 ? La majorité des applications que j’utilise ou que j’ai « POC1é » utilise cette version actuellement. Cela ne change pas grand chose, hormis peut-être dans la configuration du daemon et du client avec la variation de certains paramètres et valeurs d’arguments.

Afin de ne pas avoir de problème de version lors de l’installation et bien se limiter à la version 10.6 de notre SGBD, nous allons ajouter un repo.

Créer le fichier mariadb.repo et ajouter les informations suivantes (cf le site officiel, lien).

$ sudo vim /etc/yum.repo.d/mariadb.repo

Relançons un petit update pour récupérer les metadatas du repo Mariadb. Profitez également de ce moment pour mettre à jour votre système. Attention toutefois si le système est durci. Puis installer le package mariadb-server est mysql (vérifier que la source du paquet est bien le repo ajouté précédemment).

$ sudo dnf clean all 
# dnf update
# dnf install mariadb-server mysql

IM-PEC-CA-BLE ! (D’un autre côté c’est pas fou ce que nous venons de faire…). Ajoutons le daemon mariadb-server comme service à lancer automatiquement au démarrage (sinon c’est c*n va falloir le faire manuellement si la bécane va reboot).

$ sudo systemctl enable mariadb

Configuration – Daemon Mariadb

Pour faire simple, le server mariadb dans sa configuration par défaut tourne sur le disque système (dans la partition /var si nous voulons être plus précis). Ce qui n’est absolument pas ce que nous souhaitons puisque comme c’est un SGBD, il est inconservable de laisser ce dernier sur l’une des partitions système. Dédions un disque et montons la partition sous /mnt/databases (si besoin, Je vous invite à parcourir la section déjà documentée dans l’article LINUX – Disk & Part).

Copier les données du répertoire mysql dans le répertoire databases.

$ sudo rsync -av /var/lib/mysql /mnt/databases/

Supprimer le répertoire d’origine ou renommer le si vous êtes frileux (perso j’ai toujours froid).

$ sudo mv /var/lib/mysql /var/lib/mysql.d.ori

Modifier le contenu du fichier de configuration de mysql en ajoutant le contenu suivant.

/!\ Attention à bien adapter les chemins d’accès au répertoire mysql. A vous d’adapter si besoin la configuration selon les performances de votre serveur et des prérequis éditeur relatif à votre application.
$ sudo mv /etc/my.cnf /etc/my.cnf.ori
$ sudo vim /etc/my.cnf
$ sudo chmod 644 /etc/my.cnf
[mysqld]
#datadir=/var/lib/mysql
datadir=/mnt/databases/mysql
#socket=/var/lib/mysql/mysql.sock
socket=/mnt/databases/mysql/mysql.sock
log-bin=mysql-bin
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
innodb_buffer_pool_size = 512M
innodb_log_buffer_size = 512M
key_buffer_size = 512M
key_buffer = 512M
query_cache_size = 256M
query_cache_limit = 4M
query_cache_type = 1
max_allowed_packet = 2048M
max_connections = 300
# # Settings user and group are ignored when systemd is used.
# # If you need to run mysqld under a different user or group,
# # customize your systemd unit file for mariadb according to the
# # instructions in http://fedoraproject.org/wiki/Systemd
#
[mysqld_safe]
log-error=/var/log/mariadb/error.log
pid-file=/var/run/mariadb/mariadb.pidu
max_allowed_packet=2048M
#
#
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]
socket=/mnt/databases/mysql/mysql.sock
#innodb_buffer_pool_size = 512M
#query_cache_size = 32M
#query_cache_limit = 1M
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

C’est bien joli, mais dans notre environnement durci, le changement d’emplacement du répertoire mysql a un impact. Si nous essayons de démarrer le service nous aurons un « petit » message d’erreur. Deux possibilités

  • 🙁 : Désactiver le SELinux
  • 🙂 : Changer le contexte de fichier propre à mysql/mariadb

Le doute m’habite, que choisir ?

Vous avez compris, nous allons redéfinir et relabeliser le contexte de fichier pour le daemon mariadb quant à son nouvel emplacement.

# semanage fcontext -a -t mysqld_db_t "/mnt/databases/mysql(/.*)?"
# restorecon -R /mnt/databases/mysql

Vous noterez que j’ai fait une erreur. Normal car j’ai du retaper la commande suite à une erreur de couche 8… En temps normal, vous n’avez pas de retour si la commande se passe bien. Pour vérifier que tout est bien fonctionnel, démarrer le daemon et vérifier qu’il tourne bien. Vous pouvez aussi reboot la machine.

Si vous n’avez pas reboot la bécane et que vous avez un environnement durci, il y a un autre petit truc à faire 🙂

$ sudo systemctl start mariadb
$ systemctl status mariadb

Sécurisation – Daemon Mariadb

C’est la dernière ligne droite. Il ne nous reste plus qu’à sécuriser le daemon mariadb. Cette sécurisation vise à définir le mot de passe du compte root, nettoyer la BDD de test, les connexions anonymes et potentiellement les comptes root accessibles depuis l’extérieur.

# mariadb-secure-installation -S /mnt/databases/mysql/mysql.sock

Si vous ne précisez pas le -S, la commande ira chercher dans le chemin par défaut (/var/lib/mysql) le fichier mysql.sock. Comme nous avons déplacé le moteur de la base de données, il convient de lui donner le bon chemin.

Ca m’a l’air pas mal cette histoire, et si nous vérifions que c’est bien fonctionnel ?

$ sudo mysql -u root -p

Conclusion

L’installation et configuration réalisées nous garantissent une sécurité quand à la disponibilité de notre système ainsi qu’a l’accès de notre SGBD. D’autres actions restent à réaliser sur la couche système pour durcir d’avantages la sécurité.

La configuration du moteur SQL relève de la plus grande criticitée et nécessite d’être adapter en conséquence selon les performances du chaque serveur. Une mauvaise configuration peut entrainer le crash de la bécane. Il est impératif d’opérer les changements en dehors des heures de production ou dans un environnement de préproduction (c’est un conseil et du vécu).

L’une des grandes questions qui me taraude à sec depuis un moment serait d’étudier le comportement d’une mise à niveau du moteur dans une version supérieure en restant sur un environnement durci dédié et non conteneurisé. Comment cela se comportera t’il ? Quel serait l’impact sur le service ? Serait il plus chronophage que de migrer sur un environnement franchement déployé ? To be continued…

Le mot de la fin :

Je Select une Otarie et JOIN IN un kebab WHERE prix_id = 17€.

Erwan GUILLEMARD

Sources

  1. POC : Proof Of Concept, soit Preuve de Concept pour étudier ou non la faisabilité d’un projet. ↩︎