Alors non je ne vais pas abandonner MariaDB. Ce billet simple et efficace traitera de la SGBD¹ PostgreSQL. Le pourquoi de cet intérêt soudain se justifie par la rupture technologique de nombreux éditeurs du marché vers ce moteur puissant. Ne nous voilons pas la face, ce jour les grands acteurs de BDDs² proposent des versions communautaires qui sont limités en termes de volumétrie et de fonctionnalité. Pour jouir de l’ensemble des fonctionnalités il faut passer à la caisse.

$$$ Bonjour le bandit manchot $$$

Les bases de données étant de plus en plus volumineuse et l’évolution que nous utilisateurs nous en faisons facilite auprès de ces mêmes éditeurs la mise à jour de leurs tarifications. C’est de bonne guerre (ou pas). Ce « ou pas » laisse donc la voie à d’autres alternatives. Plus simple, moins complexes et parfois plus puissante en s’alignant sur le principe de la philosophie OpenSource.

Je laisse une version communautaire, tu passes à la caisse si tu veux un service d’assistance ou de maintenance.

Il y aura toujours chez certains éditeurs quelques fonctionnalités en moins. Toutefois, je pense que c’est dans cette approche et la bonne et je réfléchis à adopter le même principe dans un projet de vie d’une plus grande dimension.

Bref, après cette marche de l’éléphant (sans prendre de LSD³ ou autres acides). Je me fais un petit guide sur PostreSQL 🙂

Avant-Propos

Il me semble important une nouvelle fois de préciser que ce billet portera sur le déploiement d’un environnement PostgreSQL dans sa dernière version stable à ce jour (release 18 en ce mois de grace Octobre 2025). Sur Windows, le déploiement ne m’intéresse pas des masses. Par contre sur un système GNU/LINUX, j’écris un OUI majuscule (gras, italique, souligné rouge !).

Bien que les chiffres ne soient pas réellement suivis, PostgreSQL estime la part d’environnement de production d’environ (lien) :

• 52 % l’usage sur les systèmes GNU/LINUX
• 23% l’usage sur les systèmes Windows

La raison de mon choix est que nous retrouvons un grand nombre d’appliance qui utilise PostgreSQL dans des environnements GNU/UNIX. Donc en tant que SysAdmin il faut bien savoir se positionner 🙂 (franchement, quelle remarque de me*de…).

Je considère que l’environnement sera durci selon les recommandations de l’ANSSI⁴ concernant les systèmes GNU/LINUX et comme d’accoutumé, je pars sur ma distribution RHEL favorite RockyLinux.

Prérequis

• SE :
  • Rocky Linux 9.4 et version ultérieures
• Apps : 
  • PostgreSQL 18.4
• Autres :
  • Non applicable

Théorie

L’implémentation d’un SGBD passe forcément par une réflexion de sa topologie. Nous ne balançons pas une application 1-tiers, on essaie à minima d’adopter une architecture 2-Tiers. Soit 1 serveur Frontend et 1 serveur Backend.

Pour des raisons qui sont évidentes (enfonçage de porte ouverte) une application publiée ne doit pas héberger la BDD. L’application doit être en DMZ⁵ et la BDD dans une autres bulles avec un contrôle des flux entrants et sortants interlans.

M’sieur? Et pour l’identification des flux ? Pour l’attribution des ressources ? Comment on fait ?

Donnez moi un R, un T, un F et un M… RTFM⁶ ! Il suffit encore une fois d’avoir le courage de se palucher le wiki de l’éditeur applicatif. Un peu d’huile de coude n’a jamais fait de mal.

Une fois la topologie bien pensée, passons à l’architecture de notre serveur BDD.

Comme tout SGBD déployé il convient au minima d’implémenter la topologie ci-contre. Soit, un disque dédié au système UNIQUEMENT. Un disque dédié au stockage des données de notre SGBD et en dernier lieu un disque dédié au dump de nos BDDs avec une périodicité définie. J’ajouterai également un quatrième disque quant aux journaux de la BDDs et les journaux de transaction (les fameux transaction logs). Toutefois, ayant une petite infrastructure, je m’octroie le luxe de laisser ces derniers dans le /var/log.

Hardware Requirements

Niveau des ressources là c’est une autre histoire… Si la documentation officielle nous communique les ressources et interopérabilités avec les dépendances tierces, je n’ai malheureusement pas trouvé d’informations sur les ressources matérielles. Dans un sens logique car cela va dépendre de ce que nous souhaitons traiter comme données etc.

J’ai donc décidé d’appliquer de mon plein gré et non sous la contrainte de calquer les recommandations MariaDB (lien). Toutefois, cela fait un peu beaucoup pour moi…

Je partirai donc pour un minimum 2 vCPU et 4 Gio de RAM. Dans l’idéal, je serai je pense sur du 4 vCPU et 8 Gio de RAM. Comme écrit plus haut, tout dépendra de ce que notre application va consommer en termes de traitement. Il faudra alors raisonner en bon père de famille (spéciale dédicasse) et ajuster les ressources afin d’éviter la sur ou sous allocation.

Côté réseau, la documentation nous indique que le port 5432/tcp est le port de communication par défaut. Surprise, nous pouvons changer le port dans le fichier de configuration…

Je pense qu’avec le peu de base énoncée, nous pouvons passer à la pratique.

Pratique

Un dernier point pour faire une magnifique transition entre la théorie et cette partie. Il est à noter que les dépôts officiels des distributions contiennent une version de la solution PostgreSQL. Toutefois, il ne s’agit généralement pas de la dernière version. Il est recommandé d’ajouter le dépôt de l’éditeur et de ne pas utiliser le dépôt système pour PostgreSQL.

Installation

Franchement, je trouve là la démarche super-mega overcool de proposer un webwizard pour définir comment déployer PostgreSQL selon les différents OS⁷ et distributions (nous noterons au passage un excellent usage de la figure de style hyperbolique) (lien).

Je ne vais pas copier bêtement le script proposé. Mais reprendre chacune des lignes. Ce que je trouve admirable, c’est la simplicité du déploiement. Pas besoin d’installer 10k de dépendance en amont et de configurer ces dernières.

1 – Ajout du repo

A partir du lien fournit par le webwizard installer le nouveau repo :

$ sudo dnf install https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

2 – Désactivation du package de la source de distribution

Comme indiqué précédemment, il convient de désactiver la version de postgreSQL contenu dans le repo par défaut. Ainsi, nous aurons une plus grande flexibilité dans le choix de version de nos composants.

A noter que mon système étant durci j’ai été contrait de réaliser l’opération en tant que root.

# dnf -qy module disable postgresql

3 – Installation du Server PostgreSQL

Rien de plus simple, il suffit de faire une petite recherche par précaution puis une installation de notre package.

# dnf search postgresql18-server
# dnf install postgresql18-server

4 – Initialisation et démarrage

Comme tous SGBDs, il convient d’initier la première installation. Puis de s’assurer que le service va être lancer automatiquement au démarrage du système en cas de reboot.

Pour conclure, le traditionnel démarrage de notre daemon.

# /usr/pgsql-18/bin/postgresql-18-setup initdb
# systemctl enable postgresql-18
# systemctl start postgresql-18

Pour le fun, une petite vérification 🙂

Notre daemon PostgreSQL étant déployé, j’arrive toujours à ce point d’application des bonnes pratiques systèmes. C’est là que ça peut être délicat si on se plante dans la configuration car cela peut mener à repartir de zéro. D’où l’importance de lire la documentation encore une fois.

C’est qu’un éléphant ça trompe énormément !

Et voilà comment on casse tout 😀

Déplacement de la BDD Location

Si nous gardons la topologie mis en place ci-haut, il sera nécessaire de déplacer le répertoire data stocké sur /var/lib/pgsql/18/data vers notre répertoire /mnt/database/postgresql/data monté sur notre disque /dev/sdb.

Je ne vais pas mentir, je me suis pris les pieds dans le tapis une fois et j’ai dû restaurer ma VM. Toutefois, les étapes ci-dessous sont bien éprouvées et valide.

1 – Arret du service

La base de la base est donc d’arrêter le service postgresql :

$ sudo systemctl stop postgresql-18.service
$ sudo systemctl status postgresql-18.service

Il est primordiale de s’assurer que le service ne tourne plus.

2 – Création de l’architecture cible

Sur notre partition /dev/sdb1 préalablement configurée et montée sur /mnt/database, nous allons créer et définir les droits et permissions pour autoriser notre compte postgres à accéder à ce dernier.

$ sudo mkdir /mnt/database/postgresql
$ sudo mkdir /mnt/database/postgresql/pg_sock
$ sudo mkdir /mnt/database/postgresql/data
$ sudo chown postgres:postgres /mnt/database/postgresql
$ sudo chmod 755 /mnt/database
$ sudo chmod 700 -R /mnt/database/postgresql

Mais alors pourquoi 700 ? La base de donnée ainsi que l’ensemble des fichiers de ressources doivent être accessible uniquement de l’application par sécurité.

3 – Déplacement des données

Comme j’ai pris l’habitude de faire comme pour MariaDB, je vais copier le contenu du répertoire data puis renommer la source afin d’éviter tous dysfonctionnements.

$ sudo rsync -av /var/lib/pgsql/18/data/ /mnt/database/postgresql/data/
$sudo mv /var/lib/pgsql/18/data /var/lib/pgsql/18/data.ori

Une erreur classique lors de l’usage de la commande rsync reste l’oublie du /. Cela entrainera la copie du répertoire et non de son contenu uniquement. En gros, ça va bégayer dans les chemins (../postgresql/data/data/…).

4 – Modification de la configuration du service

Le service est configuré pour démarrer le daemon sous /var/lib/psql/18. Pour prendre en charge le nouveau chemin, il faut modifier ce dernier. La philosophie et de surcharger la configuration.

Créer le répertoire qui va contenir la surcharge de notre daemon psql :

$ sudo mkdir -p /etc/systemd/system/postgresql-18.service.d

Créer un fichier de surcharge qui va contenir le chemin du répertoire data :

$ sudo tee /etc/systemd/system/postgresql-18.service.d/override.conf > /dev/null <<'EOF'
[Service]
Environment="PGDATA=/mnt/database/postgresql/data/"
EOF

Par acquis de conscience, j’aime vérifier que le fichier est bien présent ainsi que le contenu de ce dernier.

$ sudo cat /etc/systemd/system/postgresql-18.service.d/override.conf

Le daemon ‘system’ a été altéré (puisque j’ai ajouté une configuration) et donc ? Un petit reload des familles pour prendre en compte le changement et zou.

$ sudo systemctl daemon-reload

5 – SELinux

Un étape un peu border avec la sécurité (comme un excès de Delirium un jeudi soir pour oublier une semaine compliqué).

Toutefois, il est important de noter un petit point et non des moindres sur notre fichier /etc/fstab. Il va être nécessaire d’ajouter le contexte sur notre partition et de relabeliser notre point partition.

Editons le fichier avec VIM, VI ou NANO puis modifier la ligne comme ci-dessous en ajoutant au niveau des droits defaults,context=system_u:object_r:postgresql_db_t:s0

Ce qui veut dire en SELinux :

• Defaults : Activation des droits standards
• Context=
  • system_u : Identité SELinux, sans impact concernant notre SGBD
  • object_r : Rôle d’objet de type fichier
  • postgresql_db_t : Match avec le type de données PostgreSQL autorisé par SELinux. Ainsi, SELinux interdit à PostgreSQL d’accéder à des fichiers qui ne sont pas dans le contexte.
  • s0 : Le niveau de sécurité par défaut.

Il sera nécessaire de définir le bon contexte sur notre nouveau répertoire.

$ sudo semanage fcontext -a -t postgresql_db_t "/mnt/database/postgresql(/.*)?"
$ sudo restorecon -Rv /mnt/database/postgresql/

6 – Démarrage du service

Le moment de vérité.

Vais je vomir l’ensemble de mes bières et commander une nouvelle tournée pour noyer mon échec ou commander une nouvelle tournée pour célébrer le succès de cette opération ? 🙂

$ sudo systemctl start postgresql-18
$ sudo systemctl status postgresql-18

Il faut noter que le service fonctionne. Néanmoins, il convient de se demander si nous pouvons requêter notre BDD à la suite de ce changement.

$ sudo -u postgres psql -c "SELECT version();"

Vérifions également que le chemin du PGDATA a bien été pris en compte.

$ sudo -u postgres psql -c "SHOW data_directory;"

Ouf ça fonctionne 🙂

Place à l’étape suivante ! BA-BA-BAR POM POM POM POM

Sécurisation & Configuration

Nous revenons encore et toujours au même point. Qui dit données implique la sensibilité de ces dernières. Aujourd’hui braquer une banque ne rapporte pas grand-chose. Le rapport bénéfices/risques n’est pas bon… Mais braqué des données, utiliser ces dernières et les revendre apporte un bien meilleur rapport en termes de bénéfices / risques.

Donc, je me retrousse les manches car je ne suis pas un manche !

Si du côté MariaDB il existe le fameux mysql_secure_installation, ce n’est malheureusement pas le cas chez PostgreSQL.

Il se pose alors de dresser un inventaire rapide des points que nous souhaitons sécuriser :

1. Mot de passe du compte postgres
2. Restreindre l’accès réseaux
3. Mettre en place une stratégie d’authentification
4. Utiliser des algorithmes de chiffrement fort
5. Supprimer les BDDs inutiles
6. Droits sur les fichiers
7. SELinux
8. Firewall embarqué (même si je préfère le terme embedded)
9. Audit et Journaux d’événements

Ca fait une petite tripoté n’est-il pas ? Naturellement, certains des points ci-haut ont déjà été traité lors du déploiement et du changement d’emplacement de la base de données.

1 – Password Account DB

Comme pour MariaDB (compte root), l’utilisateur postgres ne possède pas de mot de passe. Il convient par sécurité de définir ce dernier afin qu’il ne vienne une idée à un individu malveillant (comme un RSSI ⁸lors d’un audit ou pire un SysDBA⁹) de mettre sa truffe humide dans notre BDD.

$ su - postgres
$ psql -c "alter user postgres with password 'MyP@ssw0rd'"

Il est important de faire un petit clear de l’historique de frappe. Un mot de passe en clair c’est pas cool.

2 – Network Restrictions

Ouvrons le fichier de configuration /mnt/database/postgresql/data/postgresql.conf.

Attention comme indiqué précédemment, il faudra être authentifié en tant qu’utilisateur postgres ou root.

Recherchez la section CONNECTIONS AND AUTHENTIFICATION.

Se pose alors la question, depuis où je peux consulter ma BDDs et sur quel port ? Personnellement, le port je le laisse par défaut soit 5432/tcp. Toutefois, la source, il est bien de spécifier le subnet ou les adresses IPs qui sont autorisé à se connecter à notre SGBD. Naturellement, la valeur ‘*’ est proscrite.

Ce paramétrage va de pair avec la configuration de notre UTM¹⁰ embedded (cf le point plus bas).

3 – Authentification Policies

On va changer de fichier. L’objectif est de définir qui va se connecter à quoi, comment et depuis où.

Direction /mnt/database/postgresql/data/pg_hba.conf

La logique de lecture est la suivante TYPE correspond à la nature de l’authentification (local? hôte ?) pour quelle DATABASE (all ? replication ? db_test ?) pour quel USER (all ? r-one ?) depuis quelle ADDRESS (127.0.0.1/32 ? 0.0.0.0/0 ? 10.36.16.0/24 ?) et par quel METHOD (peer ? scram-sha-256? MD5?).

Il est certain qu’il faut limiter l’usage au maximum du all comme du masque 0.0.0.0/0. Toutefois, il n’y a pas de base les paramètres « implicites » de refus des connexions. C’est donc à implémenter (dernières lignes de la capture d’écran).

On sauvegarde, puis on reload le service.

$ sudo systemctl reload postgresql-18

4 – Suite de chiffrement

Toujours dans le fichier de configuration /mnt/database/postgresql/data/postgresql.conf. Attention comme indiqué précédemment, il faudra être authentifié en tant qu’utilisateur postgres ou root.

Recherchez la section CONNECTIONS AND AUTHENTIFICATION et activez l’algorithme de chiffrement scram-sha-256. Le MD5, nous passons notre tour hein ? Autant allez aux champignons sans capotes, c’est du pareil au même.

5 – Nettoyage des BDDs inutiles

Il est important de lister les bases présentes sur notre SGBD et de supprimer les bases qui ne servent à rien.

$ su - postgres  -c "\l"
$ psql

postgres=#\l
postgres=# DROP DATABASE NAME_BDD;

Attention : Il ne faut en aucun cas supprimer les bases template0 et template1. Ces dernières permettent (pour la 1) de générer les futurs BDDs) et (pour la 0) de regénérer la BDD de modèle.

6 – Permissions et ACLs

Comme expliqué ci haut et pour des raisons évidentes. L’accès aux données doivent être accessible uniquement du compte utilisateur postgres et root. Pas de quoi foutez milles éléphants…

Je glisse toutefois les commandes.

$ sudo chown -R postgres:postgres /mnt/database/postgresql/data
$ sudo chmod 700 /mnt/database/postgresql/data

7 – SELinux <3

Nous retrouvons la commande saisie ci-haut si nous avons modifié le database location.

Ainsi nous définissons le contexte de fichier de type postgresql_db_t à l’ensemble des éléments qui sont situer sous /mnt/database/postgresql. Puis on restore le contexte.

$ sudo semanage fcontext -a -t postgresql_db_t "/mnt/database/postgresql(/.*)?"
$ sudo restorecon -Rv /mnt/database/postgresql/

8 – Firewall

Avant c’était iptables maintenant c’est firewalld ou ufw. Personnellement je reste sur la configuration de firewalld.

Il convient d’autoriser les flux 5432/tcp dans notre firewall si des connexions se font depuis un autre réseau ou une autre machine.

$ sudo firewall-cmd --permanent --add-service=postgresql
$ sudo firewall-cmd --reload

Cela étant, il serait également plus précis de filtrer les connexions entrantes sur un réseau ou une adresse ip uniquement sur le port 5432/tcp.

J’assume cette configuration du fait de mon UTM en amont qui filtre l’ensemble des flux inter-lans.

9 – Logs & Audits

Ouvrons le fichier de configuration /mnt/database/postgresql/data/postgresql.conf. Attention comme indiqué précédemment, il faudra être authentifié en tant qu’utilisateur postgres ou root.

# vim /mnt/database/postgresql/data/postgresql.conf

Se rendre ensuite dans la section REPORTING AND LOGGING. Puis vérifiez que la configuration suivante est active.

Activation de logging_collector sur on afin de récupérer les erreurs sous la forme json ou csv. L’emplacement où va être stocké les journaux. Par défaut celui-ci se trouve dans le répertoire log. Il faudra renseigner si l’emplacement est différent le chemin absolu, le chemin relatif si c’est un cluster. log_directory = ‘log’ Le nom du fichier, par défaut ce dernier est sous le format postgresql-%Y-%m-%d_%H%M%S.log. log_filename = ‘postgresql-%a.log’ Activer la journalisation pour l’ensemble des événements de connexion et de déconnexion. log_connections = on log_disconnections = on En guise de traitement des logs, nous choisirons ddl pour avoir les définitions des commandes utilisés. Attention, l’usage de all peut être dangereux vis à vis des ressources. log_statement = ‘ddl’

Une fois les modifications apportées, n’oubliez pas que notre serveur PostgreSQL à besoin d’être redémarré :

$ sudo systemctl restart postgresql-18

Pour une configuration spécifique comme la gestion de la mémoire allouée, les fonctionnalités et j’en passe. Je pense qu’il est inutile d’aborder cela dans ce billet.

Pourquoi ? Parce que cet aspect-là et intrinsèquement lié aux dépendances des applications qui nécessite le SGBD PostgreSQL.

Premiers Pas

Cette sous partie vise plus à entrevoir les commandes de bases pour instancier une BDD dans le cadre de déploiement d’une application (spoiler Odoo par exemple ?).

Je n’ai pas la prétention de réinventer la roue, il existe la documentation pour cela et je n’ai pas non plus la prétention de devenir SysDBA. J’ai juste envie de faire les choses bien et surtout en suivant la doctrine des 3S, Simple, Standard et Sécurisé (14 ans d’ESN¹¹ ça vous forge un homme !).

Création d’un user

La création d’un utilisateur suit un paradigme différent de MariaDB. La finesse de l’application du contexte d’un utilisateur se fera dans le fichier pg_hba.conf.

$ psql -U postgres

postgres=# CREATE USER user_odoo WITH PASSWORD 'MyPassw0rd';

Création d’une BDD

La création d’une BDD nécessite qu’un utilisateur (de la SGBD naturellement) ait le privilège CREATEDB ou d’utiliser un compte super utilisateur. Cela parait logique mais pas pour tout le monde. La documentation nous rappelle que la création d’une nouvelle base de données sera effectué en réalisant un clone de la BDD template1 (si, le truc qui ne fallait pas supprimer).

postgres=# CREATE DATABASE bdd_odoo;

Toutefois, nous pouvons allez plus loin en définissant le propriétaire de la BDD, le jeu de caractère de la BDD ainsi que la collation locale afin de faciliter le tri des chaines. Par exemple :

postgres=# CREATE DATABASE bdd_odoo_18
			WITH OWNER user_odoo
			ENCODING 'UTF8'
			LC_COLLATE 'fr_FR.UTF-8'
			LC_CTYPE 'fr_FR.UTF-8'
			TEMPLATE template0;

/!\ ARTUNG /!\ Bicyclette et petit vélo !

Il n’est pas impossible que vous tombiez sur une erreur de ce type « invalid LC_COLLATE locale name« . Cela signifie que tu vivras ta vie sans aucun soucis. (Tes vraiment sûre ?) En gros, il manque le fichier de mappage de caractère au niveau système. Soit il n’est pas présent, soit il n’est pas généré.

Afin de vérifier si ce dernier est présent :

$ sudo locale -a | grep fr

Si cela ne retourne rien c’est que le packet ne doit pas être installé. Alors installons le vin diou !

$ sudo dnf install glibc-langpack-fr
$ sudo locale -a | grep fr

Surprise le fichier de mappage est présent ! Si nous rejouons la requête, cela fonctionne.

Attribution des privilèges et rôles

Comme tous systèmes de base de données, un incontournable reste la notion de rôle et de privilège.

Dans la pratique, il convient et je sais que j’enfonce une porte ouverte d’adopter la bonne pratique de créer des rôles et d’affecter les rôles aux utilisateurs. Un rôle sur la BDD en modification, en lecture, superutilisateur ect.

Ainsi et c’est d’une logique implacable, si modification il doit avoir, je ne modifierai QUE le rôle et non utilisateur par utilisateur. MALINX le LYNX…

Rôles

Par défaut, nous retrouvons :

Toujours dans le spoil (parce que je suis un mec underground moi. MOUMOUNIGAN !) je vais créer un rôle pour ODOO qui permettra uniquement de se connecter, de créer une bdd avec un mot de passe.

postgres=# CREATE ROLE r_odoo LOGIN CREATEDB;

Pour attribuer le rôle à un utilisateur (en prenant toujours le cas ODOO avec notre role r_odoo et user_odoo) :

postgres=# GRANT r_odoo TO user_odoo;

Privilèges

La notion de privilèges que ce soit sur la BDD, les tables où les schémas suivent le principe de SQL. Ainsi il suffira d’user des commandes GRANT accompagner de :

• CONNECT ON
• USAGE
• SELECT ON ALL
• SELECT, INSERT, UPDATE, DELETE
• ALTER
• DROP
• …

Il est important de prendre en compte que le propriétaire de la BDD a tous les droits.

Toujours dans notre exemple ODOO, il n’y aura donc pas de privilèges à appliquer.

PostgreSQL Client

Il existe un outil que j’ai découvert à travers un case chez VEEAM pour un problème de protection O365 du nom de pgAdmin. Cette solution officielle est l’outil graphique pour administrer PostrgreSQL.

Je pense important de présenter cette dernière car dans le cas où nous ne nous serions pas SQL native language ou seconde langue. Cela nous permettrait de bien comprendre certains dysfonctionnements ou structures.

L’installation n’est pas en soi bien complexe… Ma grand-mère y arriverait sans difficulté. Toutefois, je glisse le tips…

Certains pourrait dire, oui c’est un PHPMyAdmin. Oui c’est un fait. C’est une IHM¹² en GUI¹³ pour faciliter l’expérience quotidienne.

Pour se connecter, il suffira de renseigner les informations de connexion et de s’assurer au préalable que la politique de communication est bien présente sur notre UTM concernant les flux interlans. Sans oublier de vérifier :

• La configuration du fichier pg_hba.conf est compliante
• Les adresses d’écoutes dans le fichier postgresql.conf ne sont pas restreinte cas localhost et que le bind d’interface est bien configuré. (Le bind c’est l’ip de l’interface du serveur, pas l’adresse ip du client… Je dis ça parce que je vous vois venir hein !)

Et si nous jetions un coup d’œil dans le viseur pour observer nos logs voir si on voit notre pachyderm numérique ?

$ sudo tail -f /mnt/database/postgresql/data/log/postgresql-Wed.log

Impeccable. Tout fonctionne 🙂

Conclusion

Ce billet revient aux prémices des premiers articles rédigés il y a maintenant quasiment deux ans. Quelques choses de simple qui vise à jouer les aides mémoires de ma cafetière qui commence à s’effriter.

Je ne tenais pas à me lancer dans un benchmark de « Est ce que l’otarie et plus fort que l’éléphant ? » cela ne m’intéresse pas le moindre du monde. Toutefois et comme j’ai pu l’aborder en avant propos, le tournant des éditeurs vers la solution PostgreSQL mérite de s’intéresser à cette dernière.

• VEEAM enchaine sa rupture technologique avec Windows (SE¹⁴ et/ou MSSQL) pour RHEL et PostgreSQL
• ODOO qui reste dans la philosophie du libre
• La Société Générale (faut bien renflouer les caisses après le passage de Jérôme KERVIEL… Ok, la blague est mauvaise, mais il fallait la faire. Trop tentante).
• Patrick BALKANY pour gérer son patrimoine non déclaré. Ah non autant pour moi c’est une fake news… Que je suis naïf 🙂

Au delà des deux derniers points douteux, il est bien je pense de se garder deux SGBDs relationnels sous le coude les solutions MariaDB et PostgreSQL. L’implémentation de la couche de sécurité relève d’un défi parfois mais reste nécessaire et plus qu’indispensable de nos jours.

Il manque toutefois un point que je n’ai pas développé ici. La possibilité de sauvegarder une base de manière périodique. J’avais traité le sujet pour MariaDB à la suite d’une connerie de ma part un vendredi aprem sur l’environnement de production. Je pense qu’il serait bien de reprendre ce projet et de l’adapter pour PostgreSQL 🙂

Ca fait un sujet supplémentaire à traiter d’ici la fin d’année. Mais surtout, le levé de voile ayant été fait un poil plus tôt ce billet est le tremplin pour l’implémentation d’ODOO comme mon ERP à venir.

Le mot de la fin :

Egaré dans la base de données infernale, le sysadmin se nomme R-ONE. A la recherche du datalocation, le problème s’appelle la durcification. Avec la solution VEEAM, il a pu rollback super vite. Dérivant à dos d’éléphant, R-ONE arrivera toujours dans l’étang… (faut bien se mouiller un peu qu’ils disaient les anciens)

Erwan GUILLEMARD

Sources

• PostgreSQL Secteur par OS
• PostgreSQL – Main Apps Guide
• PostgreSQL – Download
• PGAdmin – Download
• MariaDB – Hardware Requirements

1. SGBD : Système de Gestion de Base de Données ↩︎
2. BDD : Base De Données ↩︎
3. LSD :  LySergique Diéthylamide ↩︎
4. ANSSI : Agence Nationale de Sécurité des Systèmes d’Informations ↩︎
5. DMZ : Demilitarized Zone ↩︎
6. RTFM : Read The Fuck*ng Manual ↩︎
7. OS : Operating System ↩︎
8. RSSI : Responsable Sécurité des Systèmes d’Informations ↩︎
9. SysDBA : Administrateur des Systèmes de Bases de Données ↩︎
10. UTM : Unified threat management ↩︎
11. ESN : Entreprise des Services Numériques ↩︎
12. IHM : Interface Homme Machine ↩︎
13. GUI : Graphical User Interface ↩︎
14. SE : Système d’Exploitation ↩︎

Mon binôme et moi-même rigolions à quelques blagues potaches de ma part. Tout allait bien. J’enchainais dans notre solution ITSM¹ les requêtes SQL²/OQL³ avec des gros mots comme DROP, DROP CASCADE. (Vous le voyez le drame qui arrive ? Iceberg droit devant !

Attention spoiler, ça ne va pas se terminer avec l’anneau dans le volcan !).

Un collègue passe m’avertir qu’il ne peut plus traiter de ticket. Je me souviens lui avoir répondu avec un aplomb digne d’un politicien que c’était normal. Pourquoi s’arrêter en si bon chemin dans l’exécution de mes requêtes, il n’y a pas de message d’erreur ? Tant que je gagne je joue ! xD

J’ai un peu moins rigolé quand deux minutes montre en main le responsable du centre de service m’a indiqué que s’il y a quelques minutes nos collègues ne pouvaient plus s’assigner de ticket, cette fois si, ils n’existaient même plus et ne pouvaient plus sélectionner leur nom sur l’interface WEBUI⁴.

Pour vous résumer mon état :

Si ça en a le gout, la texture et l’odeur. C’est que s’en est !

Ce n’est pas de moi, mais l’auteur je l’espère se reconnaitra

Avant de poursuivre ce conte digne des frères GRIMM, je souhaite dans cet article vous faire part d’une situation particulière à la limite du critique, de la réflexion pour corriger cette situation et des solutions pour se prémunir d’une potentielle récidive. Chassez le naturel, il revient au goulot…

Prérequis

• SE: RHEL, DEBIAN, UBUNTU
• Apps: bash, crontab, Mariadb/Mysql
• Autres: Au moins une base de données, Apps – MUTT

(Reprise de l’histoire)

Effectivement, j’ai bien « défoncé » quelques tables et jointures. L’application ITSM colonne vertébrale de notre organisation n’est plus fonctionnel. Il est 15h00 et l’ensemble des équipes sont à l’arrêt. Paradoxalement, j’aurai dû continuer de passer des requêtes SQLs car si nous ne pouvions pas traiter les demandes et incidents des utilisateurs, ces derniers pouvaient créer des tickets.

A ce moment, nous avions bien identifié l’origine du dysfonctionnement (1m98, 85 kilos… oui mais pas que). Nous envisagions mes collègues et moi une once d’espoir pour faire machine arrière quant à mes actions sur la base de données.

C’est un peu plus difficile quand j’ai annoncé ne pas avoir noté toutes les requêtes que j’avais exécuté, et que les journaux de logs sont vides.

Pourtant, personne ne doit travailler le vendredi après midi, le vendredi après midi on est bleu. La décision est prise. Il va falloir restaurer la base de données.

Réunion de crise

Récapitulons donc la situation, la production est hors service. Nous ne pouvons pas revenir en arrière, la production continue de tourner et à cette époque nous avions un fonctionnement particulier avec l’un des nos clients pour lequel notre outil ITSM était « master » d’un seconde instance ITSM satellite « slave » avec des synchronisations. Bref, un truc super mais sensible en cas de non respect du cycle de vie des tickets.

En dehors du cas singulier précédent, il faut savoir que dans le fonctionnement de notre organisation, nous avons des engagements de résultats sur le traitements des demandes et incidents (SLA⁵, OLA⁶, SLR⁷ etc).

Revenir en arrière en restaurant la base de données, oui mais sans perdre les tickets et requêtes utilisateurs en cours.

A quelle heure pouvons nous donc restaurer la BDD ? Encore une fois c’est là où le bât blesse. Nous n’avons pas de dump de la base… (Nous voici donc au volant d’une voiture qui roule à vive allure, nous pensons que tout va bien puis que d’un coup nous découvrons que l’assurance n’est pas à jour. Que l’ensemble des témoins du tableau de bord s’allument tous comme un sapin de Noël et que les freins vont surement lâchés.)

Nous décidons de contacter l’éditeur qui malheureusement ne peut rien faire pour nous dans le contexte et arrive à la même conclusion que nous. La restauration en date de la veille et inéluctable.

Nous réalisons toutefois un export de l’ensemble de toutes les requêtes créés, modifiées entre le matin même de 06h00 à 18h00 sur l’environnement ITSM de production ainsi que sur l’environnement ITSM satellite du client, puis coupons les services. De mémoire, cela représentait un volume de 300 tickets environ.

Excès de confiance

Pourquoi cette situation ? Pourquoi ce changement n’a-t-il pas été soumis à un CAB ? Si vous avez pris un peu le temps de lire d’autres articles ou de lire ma présentation, je suis quelqu’un de malchanceux marqué du signe du chat noir ascendant Pierre RICHARD (mais je le vis bien je vous rassure). Nous avions initialement mon collègue et moi pour objectif « d’alléger » notre base de données de production. C’est pourquoi, dans le cadre du contrat de support et d’assistance avec l’éditeur, après une analyse commune, nous avions établit une liste de requête précise.

Toutefois et par prudence, il était impératif de tester sur notre environnement de test/préproduction à ISO périmètre de l’environnement de production les dites requêtes. Chose qui a été réalisé par mes soins sans rencontrer la moindre complication ou dysfonctionnement. Le résultat est positif, tous les voyants sont verts. Pourquoi ne pas appliquer les modifications sur l’environnement de production ?

C’est là, que ça ne va pas. L’environnement de préproduction ne fonctionne pas à ISO périmètre de l’environnement de production. Ce dernier est sans cesse sollicité se qui n’est pas le cas de l’environnement de préprod. (C’est diabolique). Et donc, l’application des requêtes ont générés d’autres erreurs. L’outil ITSM m’a gentiment proposé de corriger les dîtes erreurs. Je suis donc sortie allégrement du contexte de mon changement sans m’en rendre compte.

Je pensais maitriser mes actions et n’ais à aucun moment pensé qu’il s’agissait d’un changement ! Il a suffit d’un excès de confiance. Pour mettre à genoux l’organisation (rien de bien dramatique en soi quand nous voyons aujourd’hui l’impact d’un crypto, ce n’est pas du tout le même impact).

Mais vous savez même si la chat et noir, il a toujours quelques poils blancs dans son pelage 🙂 L’incident tombant un vendredi, il nous reste le week-end pour trouver une solution.

Plan d’actions

C’est incroyable de se dire que l’action d’un individu à impacté l’ensemble des services et nécessité cinq collaborateurs de trois services différents. Néanmoins, personnes n’a été malveillant à mon égard à ma grande surprise. Nous étions une équipe face, un bloc face à l’incident en cours.

Nous avions donc défini le plan d’action suivant :

• Restauration du serveur de base de donnée à la veille dans un environnement isolé
• Réalisation du dump de la base de données
• Exportation de la base de données
• Désactivation de l’appareillage entre l’ITOP master et le satellite (slave)
• Importation de la base de données sur l’environnement de production
• Réalisation des mêmes actions côté ITOP satellite
• Réactivation de l’appareillage entre les deux ITOP
• Reprise des requêtes côté satellite depuis le fichier CSV exporté plus tôt
• Reprise des requêtes côté master depuis le fichier CSV exporté plus tôt

Sur le papier cela sonnait bien. Et pourtant encore nous allions buter sur deux points bêtes. C’est toujours quand nous sommes dans l’embarras (pour ne pas dire dans la m***e) que nous nous rendons compte de la réalité des choses.

• A l’époque, dans une console VMWare (version 5.5 de mémoire) il était ardu de taper certains caractères spécifiques. Nous avons buter pendant 30 minutes pour saisir le caractère « @« .
• Lors de l’import d’un dump existant ITOP, lors de l’application d’un setup il est nécessaire de supprimer l’intégralité d’une table VIEWS. Nous ne le savions pas à l’époque… (J’ai dans mes tablettes un article en cours à ce propos). Nous ne sommes pas SysDBA, mais nous avons tout de même réalisé le STATMENT qui va bien. (Malgré tous ces péripéties, ils t’ont laissé faire du SQL ? Non je vous rassure j’étais sous tutelle 🙂 ).

Reprise des données

La diversité des tickets et les différents paramètres des ces derniers allaient rendre difficile l’automatisation de réimport des requêtes. Il ne suffit pas de reprendre les tickets, il est nécessaire de leurs appliquer un « stimulus » afin que les notifications, SLA, le cycle de vie etc s’appliquent. L’éditeur nous avait prévenu quelques heures auparavant qu’il allait falloir user d’huile de coude.

J’ai eu à cœur d’assumer ma faute et de porter la responsabilité de cet échec. Si mon binôme n’était pas disponible samedi pour m’aider il l’était dimanche. Toutefois, j’ai fait tout ce qui était possible pour qu’il n’ait rien à faire.

Sur les 300 et quelques tickets, il aura dû en traiter une vingtaine et c’est je crois toujours 20 de trop. A grand coup de copier/coller, 270 tickets il faut compter à peu près 19h. (J’ai oublié de préciser que ma femme m’a mis un savon le soir comme quoi il est interdit de faire des changements le vendredi, blablabla. J’ai encore le souvenir de la voir partir le samedi soir avec ces copines et revenir tôt le dimanche matin. Ca fait ne me rajeunit pas).

Dénouement et fin

Le lundi matin, tout était de nouveau fonctionnel. Le week-end a été long et les heures de sommeil rares. Toutefois, « la bêtise » était assumée. Un nombre incalculable de « Je suis désolé », « Veuillez accepter mes excuses » auprès de mes collègues ont eu lieu. Il me semble que cela les a plus agacé que l’incident en lui même. (Effectivement le gars qui se là joue Les 120 journées de Sodome c’est usant).

Le plus beau, restera qu’aucun de nos clients n’a remarqué l’incident et le changement des SLAs de quelques heures. Si quelques interlocuteurs clients l’ont remarqués ils n’ont pas demandés plus de compte que cela.

Un REX⁸ a eu lieu en comité et nous avons su pointer les points qui devaient être améliorer. Le plus gros étant de s’assurer au moins un dump de la base de données entre deux points de sauvegarde. Oui mais comment faire et surtout par où commencer.

Réflexion

A la suite de la petite histoire ci-haut, qui commence mal mais qui se termine plutôt bien. L’une des premières questions que je me suis posé est qu’est ce que propose ITOP ? Est ce que la solution embarque un système de sauvegarde, de dump de base de données ?

La réponse est oui ! Mais ça ne me convient pas !

Mais il est jamais content se type. Il y a des solutions mises en place par l’éditeur dans sa solution et ça ne lui convient pas. Je le vois déjà écrire « Oui je veux pas réinventer la roue, mais… ». Tu serais pas un SysAdmin frustré par hasard ? Qu’est ce qui a ?

Pour le coup le contexte est différent. Si nous reprenons l’architecture 2-tiers (Apps – iTOP), nous avons d’un côté notre serveur web et de l’autre notre serveur de BDD. Jusque là pas de problème.

Ce qui me gène dans l’outil mise à disposition pour COMBODO, c’est que le stockage des dumps se fait du côté où est exécuter la commande mysqldump. Soit côté Front et donc stocké dans le répertoire web itop (/var/www/html/portail.erwanguillemard.com/data/backups/).

En quoi ça te gène ? En réalité il y a plusieurs points.

• Espace disque : Il existe un risque de saturation de l’espace de stockage du serveur web et de la partition /var/. La saturation de la partition (ou du disque) peut (plutôt va) rendre inaccessible le portail web. (Tu connais les hardlinks ?)
• Sécurité : Stocker les dumps de la base de données de production sur le serveur front publié vers l’extérieur représente un risque en cas d’intrusion donc de vulnérabilité et de vol de données dans le pire des cas
• Granularité : Possible uniquement de ne garder que 5 points de rétentions du lundi au vendredi à partir de 23:30.
• Mécanisme : Ce dernier est propre à ITOP est non pas une couche hors de l’application. Que se passe-t-il si le front reboot lors de la tâche de backup ou si le réseau est indisponible, si l’application est indisponible ?

Donc si nous te comprenons bien, la fonctionnalité est naze ? Non, loin de là. Au contraire, je trouve que c’est une excellente fonctionnalité car elle permet pour les petites bases de données de réaliser un dump dans les meilleurs délais et de ne pas avoir à se connecter directement au serveur backend. De plus, il est possible de réaliser une restauration directement depuis le portail ITOP (webui).

C’est à partir de ce constat que j’ai décidé d’écrire ma lettre au Père Noël (ou Saint Nicolas suivant notre situation géographique).

Petit Papa Noël, 

J'ai été bien sage en ce début d'année 2019 même si j'ai fait une petite boulette. Afin de ne pas reproduire cette bêtise, je souhaiterai avoir une solution qui réalise les points suivants :
* Un outil qui réalise 2 dumps par jour ou plus (automatisation)
* Un outil qui envoi un mail en cas de succès ou d'erreur du dump
* Un outil qui puisse avoir une fonctionnalité de dump manuel
* Un outil qui soit GENERIQUE et s'adapte à n'importe quelle base de données MySQL/MariaDB.
* Un outil qui fonctionne sous GNU (RHEL et DEBIAN) en bash.

Merci Père Noël, je t'aime tu es le meilleur.

Bisous, 

Erwan

Hélas, je n’ai toujours pas eu de réponse à ma lettre. A croire que ma « boulette » n’était pas si petite que ça… Ce n’est pas grave…

Allez, on est pas des manches, on se relève les manches et… BANZAÏ !

Merci Groland

Configuration et installation du Script

Bien qu’initialement, l’outil que j’ai développé venait répondre à un besoin professionnel, la version présentée dans cette article a pour seul lien que le contexte et a été développé, testé sur mon temps personnel.

Lecture du script

Comme toujours nous positionnerons le script à la racine du système de notre serveur SGBD dans un répertoire à part avec des droits spécifiques. L’objectif étant de toujours garantir un niveau de sécurité suffisant et d’éviter une escalade potentielle des droits.

J’insiste sur ce point, l’ensemble des actions ci-dessous sont à réaliser sur le serveur backend.

$ sudo mkdir /script
$ sudo mkdir /script/SS_015-LINUX_MYSQL_DUMP-BDD

Editez le fichier ou copiez le fichier suivant : SS_015_E_LINUX_MYSQL_DUMP-BDD.sh

A ce jour le fichier en version E est construit de la manière suivante :

• Les constantes
• Une fonction vérifiant les prérequis
• Une fonction réalisant le dump de la base de données
• Une fonction assurant la rotation des fichiers de dumps suivant le nombre de points de rétention définit
• Une fonction pour préparer le mail
• Une fonction d’envoi de mail
• Une fonction pour forger le mail en html

Je vous propose de parcourir ensemble le script, fonction par fonction. L’objectif étant de partager ce bout de code et peut être pouvoir le soir me coucher en me persuadant que quelques parts, sur le SI d’une organisation ce bout de code, maigre contribution personnel fonctionne… Laissez moi un peu rêver ou alors dites vous que vous m’en vendez (du rêve naturellement) !

1 – Les constantes

Les noms des variables sont normalement explicites. Pour éviter toutes ambiguïtés :

• _modeHTML : Pour avoir des bô rapport en HTML
• _author : Pour afficher dans le rapport le nom du créateur
• _version : Pour la version du script
• _dateRelease : Pour la date du script (dernière modification)
• _mailTo : Contient l’email du destinataire qui va être spamé de mail
• _pathLogRepository : Emplacement où seront stockés les logs à chaque exécution du script.
• _pathLogFile : Nom du fichier de log
• _pathBDDRepository : Emplacement où seront stockées les dumps
• _nbRetention : Nombre de dump à conserver
• _dbName : Nom de la base de données concerné par le traitement
• _dbUser : Nom du compte Mariadb/MySQL qui sera autorisée à réaliser le dump de la BDD
• _dbPassword : Mot de passe du compte renseigné précédemment

2 – Fonction : Check Prérequis

Cette fonction à pour objectif de vérifier et de contrôler que toutes les conditions nécessaires au bon déroulement du script soient présentes.

• Création du répertoire de log si absent
• Création du fichier de log si absent ou différent

• Création du répertoire des dumps 1/2 et 2/2 journalier

Si et seulement si les conditions sont présentes alors le script fera appel à la fonction suivante dumpCreate.

« J’ai une question bête ? C’est quoi ta variable $codeArg et la commande tee ? »

Il est important de se rappeler « il n’y a pas de question bête, il n’y a que des réponses stupides« .

Lorsque j’ai écrit ce bout de code il y a 4 ans, je souhaitais offrir la possibilité de réaliser l’automatisation des dumps mais de garder la possibilité de lancer manuellement un dump sans à avoir à taper la commande mysqldump, le login et le mot de passe.

De ce fait, si nous appelons le script :

• Sans argument : Réalise un dump de la base de données à l’instant T
• Avec argument (MidDay ou MidNight) : Réalise un dump de la base de données dans un répertoire spécifique. A son intérêt si appelé dans une tâche planifiée.

La commande tee offre un avantage car elle permet de retourner l’affichage d’un terminal dans un fichier. Ce qui permet de voir ce qui se passe lors de l’exécution du script et de garder une trace de l’ensemble des actions. D’un côté cela reste plus lourd dans la syntaxe que le traditionnel 2>&1 qui ne gère que le stdout et stderr. Probablement qu’aujourd’hui je ferai différemment.

3 – Fonction : Dump Create

Nous rentrons dans le vif du sujet. Je réalise le dump de la base en deux temps.

• Export du dump .sql
• Compression du dump .sql en .gzip

Toujours en prenant en compte l’argument passé lors de l’appel du script pour positionner le dump dans le bon répertoire. Dans le cas contraire, le dump sera écrit à la racine du répertoire contenant les dumps.

Dans cette fonction, les commandes les plus intéressantes sont bien entendu les commandes mysqldump et gzip.

Pourquoi faire en deux temps alors qu’il est tout à fait possible de réaliser ces deux actions en une seule commande ?

Excellente question pour laquelle je ne me souviens plus pourquoi j’ai fait ça. Peut-être pour le plaisir de chercher midi à quatorze heures que sait où mon côté néophyte ?

Nous précisons l’utilisateur qui va réaliser le dump de la BDD (attention au permission sur la base) ainsi que son mot de passe -u $_dbUser et -p$_dbPassword. L’option –master-data permet de se positionner si une réplication SQL est se place sur la dernière position. L’option –quick est utile dans le cas de BDDs importante. Cela va permettre de récupérer les lignes d’une table, ligne par ligne, plutôt que de récupérer l’intégralité de toutes les lignes et de les garder en mémoire avant de l’écrire. L’option –single-transaction qui est à mon sens l’option la plus importante de notre ligne de commande puisque cette option permet de réaliser le dump de notre base de données à chaud sans verrouiller les tables ni bloquer l’application. Pour faire plus simple, cela permet de garantir la consistance des données de notre DUMP. L’option –verbose est quant à elle compréhensible. Nous indiquons la BDD dont nous souhaitons réaliser le dump $_dbName, redirigeons l’ensemble des flux dans le répertoire adéquate puis l’ensemble des flux dans notre fichier de log.

La compression est plus simple puisque nous appelons la commande gzip en indiquant que nous voulons de la verbe et que nous allons forcer la création de l’archive. Comme pour la commande précédente, nous redirigerons l’ensemble des flux dans notre fichier de log.

Et donc si nous souhaitons faire cette opération en une fois ?

Il suffirait de faire un pipe des deux commandes.

$ sudo /usr/bin/mysqldump -u $_dbUser -p$_dbPassword --master-data --quick --single-transaction --verbose $_dbName > $argDump/`date +"%Y-%m-%d"`-$_dbName.sql 2>>$_pathLogRepository/$_pathLogFile | /bin/gzip -f -v $_pathBDDRepository/`date +"%Y-%m-%d"`-$_dbName.sql 2>>$_pathLogRepository/$_pathLogFile

Je ne l’ai toutefois pas testé. Donc à vérifier, mais il n’y devrait pas avoir de raison que ça ne fonctionne pas.

Il y a toutefois une variation entre le commande présente dans le wiki de COMBODO et ma commande. Je ne précise pas les arguments –opt, –default-character-set=utf8, –-add-drop-database. Pourquoi cette prise de liberté soudaine ?

L’option –opt est activé par défaut et si nous ne référons au manuel mysqldump, cette commande est un raccourcie de plusieurs autres commandes. Dans notre cas et si l’installation de MySQL/MariaDB a été effectué comme dans un précédent article , la question ne se pose pas. A l’inverse, nous ne spécifions pas l’encodage des caractères –-default-character-set. Cela pourrait nous porter préjudice. Néanmoins et par défaut si ce dernier n’est pas spécifier, mysqldump utilisera le type utf8mb4. On ne va pas se mentir, je ne suis pas super à l’aise sur le sujet. Si ce n’est que l’utf8mb4 est plus récent que le format utf8 et prend en charge les emojis etc. Par expérience, tous les dumps que j’ai dû réimporter jusqu’à présent ont été réalisé sans spécifier le type d’encodage utf8. Je n’ai pas constaté d’erreurs ou de dysfonctionnements. Moralité, je vais me mettre au diapason. (D’un côté faut être un peu c*n pour dire j’ai RTFM mais j’ai pas appliqué les recommandations de l’éditeur…).

4 – Fonction : CleanUp Repository

Je vois déjà certains SysAdmins ou Dev se dire « Nan le gazié il est pas sérieux avec son _nbRetention, il a pas osé faire une fonction de rotation de ces fichiers .sql/.gzip ?! » Et bien désolé de vous décevoir, la réponse est bien un énorme OUI, j’ai osé.

Pourquoi ? Simplement pour me demander comment ferai je si je devais me passer de logrotate. Et le cas échéant, j’ai appris quelques choses d’autres et j’ai donc un as dans ma manche si je dois faire une rotation de fichier un jour sans logrotate.

(Comme déjà dit plusieurs fois, il est important de savoir se perdre de temps en temps.)

La commande find permet de lister l’ensemble des éléments sur un critère. Dans notre usage, nous souhaitons lister tous les éléments (fichiers réguliers) d’un des répertoires contenant nos Dumps -type f dont la dernière modification est inférieurs au nombre de point de rétention -mtime +$argNbRetention. (Notons que cela s’exprime en jour donc 5 x 24heures). Les fichiers ne répondant pas au critère sont supprimés -delete.

Je passe mon tour sur les trois dernières fonctions qui sont ennuyeuse au possible et qui pour moi n’apportent aucun intérêt dans le projet. Puisque cela concerne l’envoi d’un mail de notification de succès ou d’échec de l’archivage ou de la réalisation du dump.

Qui dit notification mail, dit serveur de messagerie (Apps – MUTT).

Nous contrôlons les droits sur le fichier afin de s’assurer que ce dernier est bien en 700 pour root:root.

$ sudo ls -ahl /script/SS_015-LINUX_MYSQL_DUMP-BDD

Dans le cas contraire, il sera nécessaire de réaliser les opérations adéquates.

Configuration du cron

Perso, je souhaite avoir un delta de 6 heures maximum en cas de panne et donc (attention largage de gros mots dans deux secondes) dans RTO⁹ de 1 heure ! Généralement, les entreprises travaillant de 8h00 à 18h00 du Lundi au Vendredi, nous allons automatiser nos dumps à 12h30 et à 18h30 sur les mêmes jours. Libre à chacun de faire comme il le souhaite. (Attention toutefois si vous avez des jobs de sauvegardes en parallèle des dumps car les SEs n’aiment pas ça, ni le matériel d’ailleurs les I/O¹⁰ un univers passionnant).

# vim /etc/crontab

Ainsi, chaque Lundi au Vendredi à 12h30 en tant que root, le script stocké sous /script/SS_015-LINUX_MYSQL_DUMP-BDD/SS_015_E_LINUX_MYSQL_DUMP-BDD.sh avec l’argument MidDay viendra générer un dump de la base de données compressée sous l’emplacement de stockage par défaut /midday/. Il sera de même à 18h30 mais avec l’argument MidNight, sous l’emplacement /midgnight/.

Configuration des logs

Si vous avez déjà déployé l’un de mes outils, vous devez déjà avoir la configuration de rotation des logs pour le contenu du répertoire /var/log/ERWAN.

Dans le cas contraire, éditez un fichier de rotation.

$ sudo vim /etc/logrotate.d/rone_scripts

/var/log/ERWAN/SS_015-LINUX_MYSQL_DUMP-BDD.log {
        daily
        rotate 7
        copytruncate
        missingok
        notifempty
}

Configuration de la BDD

Euh… Je veux bien que tu parles de backup, de dump, de SQL toussa toussa. Mais qu’est ce que vient faire la configuration de la BDD dans cet article ?

Je répondrai à cette question par une question me chuchote mon avocat.

On lance le dump avec quel compte, le root ?

Effectivement, vu sous cette angle c’est moche. Qui peut le plus peut le moins. Mais le risque est de ne pas exposer d’avantage notre système et de maitriser autant que faire se peu les utilisateurs et les privilèges qui leurs sont associés.

Alors nous allons créer un compte dédié pour la sauvegarde de nos bases MariaDB/MySQL. (D’ailleurs saviez vous que le Dauphin de MySQL est une dédicace à la fille ainée de son fondateur et qu’à la suite de son rachat par SUN puis ORACLE, il dédiera l’Otarie à sa fille cadette ? Non ? Et bien voilà, nous mourrons moins c*n ce soir).

# mysql -u root -p

[(none)]> CREATE USER `svc.backup`@'localhost' IDENTIFIED BY '5uZ9Bc5KLkIJ0io0Z_Px9';

[(none)]> GRANT LOCK TABLES, SELECT, PROCESS, SHOW VIEW, TRIGGER ON *.* TO 'svc.backup'@'localhost';

[(none)]> FLUSH PRIVILEGES;

Dans les grandes lignes, nous créons notre utilisateur SQL (on pense à changer éventuellement le nom du user et le mot de passe), rien de bien compliqué. Ce qui nous intéresse en revanche se sont les permissions que nous attribuons à notre utilisateur :

• LOCK TABLES : Parce que nous utilisons l’argument single-transaction pour la consistance de la BDD
• SELECT : Pour dump les tables
• PROCESS : Dans le cas où nous viendrions à utiliser l’argument no-tablespaces. Dans notre cas pratique, inutile mais peut-être pas pour d’autres BDDs.
• TRIGGER : Pour dumps les tables TRIGGER de notre BDDs. Comme pour l’option ci-dessous, ça serait dommage de ne sauvegarder qu’un bout de notre BDD. Ca serait comme faire une soirée raclette mais en ne touchant pas au plateau de charcuterie. Aucun intérêt de faire une soirée raclette/dump.
• SHOW VIEW : Pour sauvegarder la table des VIEWS. Dans notre cas, nous les supprimerons si nous devons réaliser un dump de la BDD iTop. Toutefois, nous voulons un backup complet en cas d’avarie.

Allez, fermons notre connexion SQL et passons à l’étape suivante. La princesse Peach nous attend, à moins que ce ne soit Peggy du Muppet Show. Je les confonds toutes les deux.

Configuration du script

Il sera nécessaire avant la configuration du script de dédié un disque pour nos dumps (comme indiqué plus haut). L’une des grandes questions étant oui mais comment définir l’espace de stockage afin de ne pas faire de surallocation de ressources ?

Il est toujours difficile d’apporter une réponse empirique à cette question. J’ai pour habitude de partir sur la formule suivante :

DiskSize (Go) = (BDDSize (Go) * AVG Compression Rate * NBRetentionPoints) * 30 %

Par exemple, si nous partons des données suivantes pour un total de deux jobs automatisés par jour sur 5 jours avec un taux de compressions de 46% et que notre BDD fait 2 Go :

DiskSize (Go) = (2 Go * 0,46 * (2*5)) * 1,3

DiskSize (Go) = 11,96 Go

Il nous faudrait donc un disque dédié de 12 Go. Nous avons prévu une marge de 30% d’espace de stockage afin de ne pas avoir d’alerte relative à notre supervision et saturer notre espace disque. Nous n’avons ainsi pas la nécessité d’étendre tous les deux jours ou quatre matins notre partition.

Attention à l’évolution de notre base de données dans le temps. Si cette dernière « gonfle » rapidement, il sera nécessaire d’engager les actions adéquates.

Optionnellement, si vous réalisez une sauvegarde de votre machine (ce qui est vivement recommandé) par une solution tierce (VEEAM, HYCU etc) vous aurez votre nombre de point de rétention de sauvegarde en dump plus votre notre de point de rétention max définit dans notre script. Cela nous fait une bonne assurance.

Pour la suite, je considère donc que nous avons monté un disque de 12 Go sous /mnt/backup/.

Les droits sur le répertoire /mnt/backup doivent être 700 pour l’utilisateur root:root. N’oublions pas qu’en dehors de la sauvegarde, nous avons un autre backup de notre BDD. Il est donc logique de ne faire confiance à personne d’autre que root.

Editons notre script et modifions les variables suivantes.

$ sudo vim /script/SS_015-LINUX_MYSQL_DUMP-BDD/SS_015_E_LINUX_MYSQL_DUMP-BDD.sh

• _mailTo : préciser l’adresse qui va recevoir les rapports de dump deux fois par jour.
• _pathBDDRepository : préciser le répertoire racine créé précédemment qui va contenir nos sauvegardes /mnt/backup.
• _nbRetention : Le nombre de point que vous avez définit dans notre formule. Vous pouvez l’augmenter ce dernier ou le diminuer à votre guise. Tant que l’espace de stockage arrive à suivre, pas de problème.
• _dbName : Le nom de la database dont nous voulons réaliser le dump.
• _dbUser : Le compte SQL dédié uniquement à la réalisation des dumps.
• _dbPassword : Le mot de passe du compte SQL ci-haut.

Et le reste, pas touche, sauvegarder les modifications.

Bon, plus qu’à tester.

Test, Let’s the Rock of Begins

Afin de vérifier que tout va bien nous allons exécuter un dump manuellement et simuler l’automatisation d’un dump.

# /script/SS_015-LINUX_MYSQL_DUMP-BDD/SS_015_E_LINUX_MYSQL_DUMP-BDD.sh

#/script/SS_015-LINUX_MYSQL_DUMP-BDD/SS_015_E_LINUX_MYSQL_DUMP-BDD.sh MidNight

Normalement si nous avons bien fait les choses, nous devrions avoir dans notre console le retour suivant :

Si nous laissons tourner notre script 24 heures, nous devrions avoir la structure suivante dans notre répertoire /mnt/backup

Nous pourrions supprimer un sous répertoire, ce dernier sera recréé lors de la prochaine exécution du script dans le contrôle des prérequis. 🙂

Au début, je voulais joindre en pj le fichier de log. Mais tant que nous n’avons pas une grosse BDDs ça passe, après c’est plus délicat. Je dois faire des efforts dans ce sens pour mieux gérer la verbosité de mes journaux je crois.

Néanmoins, nous pouvons faire une tour dans le répertoire de log et consulter l’ENSEMBLE de toutes les actions réalisées par le script.

Soit en petit échantillon.

Et pour terminer, le plus important car nous ne sommes pas en permanence sur notre terminal putty, le petit mail nous informant du bon succès des opérations.

GitHub

Le code source ? C’est par là => LIEN (Licence GNU).

Conclusion

Il n’y a rien de pire que l’excès de confiance dans la profession d’AdminSys. A la différence des chirurgiens et autres médecins qui sont en dessus des divinités, l’AdminSys se voit vite revenir à la réalité. Je pense et s’est ce que mes mentors m’ont inculqués, peu importe la tâche nous devons être en permanence vigilant.

C’est avec ce genre de situation que nous prenons pleinement conscience des manquements sur nos systèmes d’informations et qu’il est nécessaire de trouver des solutions palliatives, payantes ou homemade (bancales la plus part du temps mais qui font ce que nous attendons).

Dans mon cas et pour revenir à la situation initiale, je pense avoir répondu à ma problématique d’indisponibilité des données entre deux points de sauvegarde (24h). Mais c’est encore loin d’être parfait. La solution est générique certes, mais elle pourrait tellement être optimisée, factorisée et simplifiée.

Pourtant nous ne sommes pas allés au bout de ce projet. Et j’avoue que j’étais partagé pour aborder ce point. Je traiterai ce dernier dans un autre billet. Mais ce que nous devons garder à l’esprit c’est que nous avons un dump de notre base de données SQL (que ce soit, ITOP, ZABBIX ou autres applications), qu’est ce qui nous dit que le contenu de notre dump est intègre et fiable ? Il faudrait réimporter ce dernier dans un environnement de test et recetter le dump. Ainsi la boucle serait bouclée et nous validerions notre processus de reprise de données à partir d’un dump de bout en bout. Cela viendra s’inscrire dans le PAS¹¹ de notre application, organisation.

Le mot de la fin :

Il était une petite requête, pirouette cacahouète. Il était une petite requête qui a fait une grosse boulette.

Pirouette, pas de caouhète. Vous passez en week end studieux sans apéro…

Erwan GUILLEMARD

Source

• FIND
• GZIP
• ITOP – DataBackup (v3.X)
• ITOP – DataBackup (v2.7.X)
• MYSQLDUMP – master-data
• MYSQLDUMP – quick
• MYSQLDUMP – single-transaction
• MYSQLDUMP – minimum privileges
• TEE

1. ITSM : Information Technology Service Management ↩︎
2. SQL : Structured Query Language ↩︎
3. OQL : Object Query Language ↩︎
4. WEBUI : WEB User Interface ↩︎
5. SLA : Service Level Agreement ↩︎
6. OLA : Operational Level Agreement ↩︎
7. SLR : Service Level Requirement ↩︎
8. REX : Retour d’EXpérience ↩︎
9. RTO : Recovery Time Objective (différent du RPO Recovey Point Objective) ↩︎
10. I/O : Input / Output ↩︎
11. PAS : Plan d’Assurance Sécurité ↩︎

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

• SE : RHEL
• Apps : MariaDB 10.6
• Autres : LINUX – Durcissement GNU, Recommandation ANSSI, LINUX – Disk & Part

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 « POC¹é » 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.

$ 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

• Mariadb – Repo

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