Passer au contenu principal

code. grind. sleep.

Catégorie: PostgreSQL

Gestion des utilisateurs pgBouncer avec auth_query

Avec pgBouncer 1.6 sont arrivés deux nouveaux paramètres, auth_user et auth_query, qui permettent de faciliter la gestion du fichier des utilisateurs. Le fichier des utilisateurs contient les couples utilisateur / mot de passe hashé pour s’authentifier à la place de l’utilisateur final sur le serveur PostgreSQL. Il y a deux problèmes majeurs avec ce fichier utilisateur : son maintien fastidieux et le risque de collision entre noms de roles identiques mais avec des mots de passe différents si le même pgBoucner accède à plusieurs instances PostgreSQL.

Confiner PostgreSQL avec SELinux

Remarque

Ce post est partiellement obsolète, avec le passage à systemd.

J’avais déjà expérimenté un peu avec SELinux il y a deux ans sans aller trop loin, parce que j’entendais souvent la phrase “Si on veut de la sécurité, il faut SELinux” et surtout à cause de l’arrivée de l’extension sepgsql dans les modules contrib de PostgreSQL. Ça avait donné une conf pour le Fosdem où finalement, j’ai plus parlé des privilèges classiques que de SELinux.

Oups... des tablespaces imbriqués

Imbriquer des tablespaces n’a pas vraiment de sens dans PostgreSQL surtout si on veut se prendre la tête avec des montages dans tous les sens… Mais bon c’est permis, car PostgreSQL utilise uniquement les liens symboliques dans $PGDATA/pg_tblspc pour accéder au contenu des tablespaces.

Got GUC?

Les paramètres de configuration de PostgreSQL sont appelés GUC ce qui signifie Grand Unified Configuration, c’est le nom de la partie du code qui gère les paramètres de configuration. En gros, ce sont tous les paramètres du fichier postgresql.conf. Ce qui est moins connu et utilisé, c’est la possibilité de configurer ces paramètres à différents niveaux : Fichier postgresql.conf Ligne de commande du postmaster, le processus principal du serveur Base de données Rôle Rôle sur une base de données Session Transaction La précédence des valeurs va en descendant dans la liste, par exemple la valeur d’un paramètre au niveau d’un rôle écrase celle positionnée au niveau de la base de donnée ou la ligne de commande.

Quand PostgreSQL n'a plus d'espace disque à manger

Voilà donc une question intéressante, comment se comporte PostgreSQL face à un système de fichier plein ? Un peu d’expérimentation est nécessaire pour se rassurer… On crée deux systèmes de fichiers de faible taille pour les tests. Le premier stockera PGDATA, ainsi qu’une base de données nommée db_data. Le second sera le tablesapce ts1, dans lequel oncréera une base de données db_ts1. L’objectif est de montrer que seules les transactions modifiant des objets stockés sur des systèmes de fichier plein sont affectées, c’est pourquoi on a besoin de plusieurs tablespaces.

Could not open relation with oid N

On peut parfois trouver cet étrange message d’erreur dans les traces de PostgreSQL (N étant un nombre) ou lors de l’exécution d’une requête : ERROR: could not open relation with OID N Si on recherche ce message dans les mailing-lists du projet, on peut facilement conclure que la base de données est corrompue, qu’il y a des problèmes matériels et que la sécurité des données est en péril. Et bien, ce n’est pas forcément le cas : obtenir ce message peut être tout à fait normal.