Rocky Linux / Installer PostgreSQL et configurer les connexions

Sur Rocky Linux, installez PostgreSQL depuis les dépôts de la distribution, initialisez un nouveau cluster puis activez le service postgresql. Pour un accès distant, configurez aussi les adresses d’écoute, l’authentification, le chiffrement TLS (Transport Layer Security) et le pare-feu. Les commandes ci-dessous concernent une nouvelle installation avec les paquets de la distribution ; elles ne constituent pas une procédure de migration d’un serveur existant.

Un cluster PostgreSQL est un ensemble de bases gérées par une même instance de serveur et un même répertoire de données ; ce terme ne signifie pas ici un ensemble de machines. Prévoyez un compte disposant de sudo, une console, un espace disque suffisant et une version majeure compatible avec l’application. Le serveur et les bibliothèques clientes doivent encore être pris en charge. La page officielle des paquets PostgreSQL pour la famille Red Hat distingue les paquets de distribution et le dépôt PGDG, maintenu par le PostgreSQL Global Development Group.

Vérification des versions de PostgreSQL disponibles

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

dnf info indique les paquets accessibles dans les dépôts actifs. Sur une version prenant en charge les modules DNF, dnf module list postgresql permet aussi de voir les flux proposés. L’absence de cette fonction sur une autre version ne signifie pas que PostgreSQL est absent. Choisissez le dépôt et le cycle de maintenance avant l’installation ; les étapes suivantes supposent les paquets Rocky, sans mélange avec les paquets serveur PGDG. Pour PGDG, suivez les instructions correspondant exactement à la version de Rocky et à l’architecture sur la page officielle.

Installation et initialisation de PostgreSQL

Installation du serveur et du client

sudo dnf install postgresql-server postgresql

Vérifiez la version et les paquets installés.

psql --version
rpm -q postgresql-server postgresql

Initialiser le cluster de bases de données

Vérifiez l’aide de l’outil fourni et le répertoire de données prévu avant l’initialisation. Pour les paquets de la distribution, la séquence est généralement la suivante :

sudo postgresql-setup --help

sudo postgresql-setup --initdb

Exécutez cette initialisation une seule fois pour une nouvelle installation dont le répertoire de données est vide. initdb refuse normalement un répertoire non vide : ne supprimez pas ses fichiers pour contourner ce contrôle. Sur un serveur déjà utilisé, identifiez le cluster et ses sauvegardes avant toute intervention ; une mise à niveau majeure demande une procédure distincte.

Démarrer le service et l’activer au démarrage

sudo systemctl enable --now postgresql
systemctl status postgresql

Le service doit apparaître comme actif après son démarrage ; utilisez q pour quitter l’afficheur de statut si nécessaire. Les paquets PGDG peuvent employer un nom tel que postgresql-16 et un outil d’initialisation différent. Contrôlez systemctl list-unit-files 'postgresql*' et la documentation du paquet installé. psql --version décrit le client ; vérifiez aussi la version du serveur une fois connecté avec SELECT version(); dans psql.

Accès local et paramètres de sécurité de base

Ouvrir une session locale comme postgres

sudo -iu postgres psql

La méthode locale peer, lorsqu’elle est configurée, compare le compte du système d’exploitation au rôle demandé dans PostgreSQL. Un rôle est un compte ou un groupe de privilèges de la base. Le compte Linux postgres et le rôle PostgreSQL du même nom ont des mécanismes d’authentification distincts ; définir le mot de passe de l’un ne définit pas celui de l’autre. Les commandes SQL suivantes s’exécutent dans la session psql ouverte ici, pas directement dans le shell.

Définir les mots de passe de manière sécurisée

Dans psql, la méta-commande \password demande le secret sans l’inscrire dans une instruction SQL saisie en clair. Pour une authentification SCRAM (Salted Challenge Response Authentication Mechanism), sélectionnez scram-sha-256 dans cette session avant de définir les mots de passe ; ce choix ne convertit pas les anciens secrets déjà stockés. Vérifiez que les clients sont compatibles avec l’authentification par mot de passe PostgreSQL. Le mot de passe administratif est utile seulement si votre mode d’accès le demande ; l’administration locale par peer peut être conservée.

SET password_encryption = 'scram-sha-256';

\password postgres

Créez un rôle propre à l’application plutôt que d’utiliser le superutilisateur. Dans une nouvelle installation où ces noms n’existent pas encore, exécutez les trois éléments suivants, dans l’ordre. La commande commençant par une barre oblique inversée est une méta-commande de psql, les deux autres sont du SQL :

CREATE ROLE appuser LOGIN;

\password appuser

CREATE DATABASE appdb OWNER appuser;

Les résultats attendus sont CREATE ROLE puis CREATE DATABASE, sans erreur. Ce rôle est propriétaire de sa base, ce qui convient à cet exemple de création ; en production, séparez si nécessaire le rôle de migration du rôle utilisé à l’exécution et accordez seulement les droits requis.

Trouver les fichiers de configuration

SHOW config_file;
SHOW hba_file;
SHOW data_directory;

Relevez ces chemins réels : les fichiers peuvent être placés ailleurs selon le paquet. Quittez ensuite psql avec \q. Avant toute modification, sauvegardez les deux fichiers de configuration dans des copies distinctes, puis ouvrez leurs chemins exacts avec sudoedit. Conservez un accès administratif local pendant les essais et ne remplacez pas les règles locales existantes.

Configurer un accès distant restreint

Choisir les adresses d’écoute

La partie distante est optionnelle. Elle suppose un réseau privé ou un VPN (réseau privé virtuel), un serveur et un client dont vous connaissez les adresses, ainsi qu’un certificat TLS (Transport Layer Security) valide pour le serveur. Les adresses 192.0.2.20 et 192.0.2.10 sont réservées aux exemples de documentation : remplacez-les respectivement par l’adresse réelle du serveur et celle du client autorisé. Dans postgresql.conf, limitez l’écoute à cette interface en conservant au besoin la boucle locale :

listen_addresses = 'localhost,192.0.2.20'

listen_addresses choisit les interfaces du serveur ; il ne choisit pas les clients autorisés. * écoute sur toutes les interfaces disponibles. Ce paramètre nécessite un redémarrage. Consultez la documentation des paramètres de connexion pour votre version.

Préparer le certificat et activer TLS

Faites fournir par votre autorité de certification le certificat du serveur, sa chaîne intermédiaire éventuelle et la clé privée correspondante. Le nom DNS utilisé par le client doit être présent dans le certificat ; db.internal.example ci-dessous est un nom d’exemple à remplacer et à faire résoudre vers le serveur réel. Le client doit posséder le certificat racine de l’autorité de certification (CA), obtenu par un canal de confiance. La délivrance de ces certificats dépend de votre infrastructure et constitue un préalable à cet accès distant.

Pour la disposition standard suivante, placez server.crt et server.key dans le répertoire indiqué par SHOW data_directory. Le certificat doit être lisible par le service ; la clé peut appartenir à postgres avec des permissions 0600. Préservez les contextes SELinux (contrôle d’accès obligatoire du système) appropriés et ne désactivez pas ce contrôle pour contourner un refus. Les noms de fichiers sont relatifs au répertoire de données :

ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'

Ces options vont dans postgresql.conf. La présence d’une règle hostssl n’active pas TLS à elle seule. Le guide TLS du serveur PostgreSQL explique les fichiers, permissions et dispositions alternatives.

Restreindre les clients et l'authentification dans pg_hba.conf

Dans le fichier indiqué par SHOW hba_file, ajoutez les règles suivantes avant d’éventuelles règles réseau générales pour ce couple base/rôle. HBA signifie host-based authentication, authentification fondée sur l’hôte. La première ligne autorise le client IPv4 donné avec TLS et SCRAM ; les deux suivantes refusent les autres connexions TCP à appdb comme appuser, y compris les tentatives sans TLS depuis le client autorisé :

hostssl  appdb  appuser  192.0.2.10/32  scram-sha-256
host     appdb  appuser  0.0.0.0/0      reject
host     appdb  appuser  ::/0           reject

Seule la première règle correspondante est utilisée ; un échec d’authentification ne provoque pas l’essai de la règle suivante. Des autorisations placées plus haut peuvent donc contourner la restriction prévue. Les refus ci-dessus visent ce couple base/rôle ; ils ne ferment pas tous les autres comptes ou bases. Auditez les autres entrées et consultez la documentation de pg_hba.conf. /32 désigne ici une adresse IPv4 unique.

Restreindre les adresses source avec un pare-feu

Avec firewalld actif, identifiez d’abord la zone réellement appliquée à l’interface. public est un exemple à remplacer. Vérifiez aussi les services, ports et autres règles qui pourraient déjà autoriser un accès plus large. TCP (Transmission Control Protocol) utilise par défaut le port 5432 pour PostgreSQL ; adaptez-le si votre serveur est configuré autrement. Le guide de firewalld sur Rocky Linux détaille les zones et la distinction entre état actif et permanent.

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

Cette première commande ajoute une règle à l’état actif. Après les tests de connexion décrits ci-dessous, enregistrez seulement cette règle dans la configuration permanente :

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

La règle permanente ne nécessite pas de rechargement pour cet essai, puisque la même règle est déjà active. Les pare-feux du réseau et les groupes de sécurité du fournisseur cloud doivent également autoriser le seul trajet prévu. N’exposez pas directement le port de la base à tous les réseaux.

Application et vérification des paramètres

Recharger les règles d'authentification

Examinez d’abord les règles du fichier avec la vue suivante. Corrigez toute erreur avant de recharger la configuration. Les valeurs de error doivent être nulles pour les règles valides. La vue décrit le fichier actuel, pas nécessairement les règles déjà chargées, comme le précise le manuel de pg_hba_file_rules :

sudo -iu postgres psql -c 'SELECT line_number, type, database, user_name, address, auth_method, error FROM pg_hba_file_rules;'

sudo -iu postgres psql -c 'SELECT pg_reload_conf();'

La fonction de rechargement renvoie normalement t si le signal a été envoyé ; cela ne prouve pas que tous les paramètres ont été acceptés. Consultez les journaux et testez une nouvelle connexion. Les sessions déjà établies ne suffisent pas à vérifier une nouvelle règle HBA.

Application des paramètres nécessitant un redémarrage

Une modification de listen_addresses exige un redémarrage, qui interrompt les connexions : prévoyez ce créneau. Vérifiez avant cela les chemins et permissions des certificats, les sauvegardes de configuration et les erreurs du fichier HBA. Si le service ne redémarre pas, examinez sudo journalctl -u postgresql -n 50 --no-pager, corrigez ou restaurez seulement les modifications en cause, puis redémarrez le service sans réinitialiser les données.

sudo systemctl restart postgresql
sudo systemctl status postgresql

Test des ports d'écoute et des connexions

sudo ss -lntp 'sport = :5432'

Sur le serveur, ss doit montrer le processus à l’écoute sur l’interface prévue. Depuis le client autorisé, utilisez ensuite un client psql compatible, le vrai nom DNS du serveur et le chemin réel du certificat racine. Le fichier /chemin/ca-racine.crt et le nom DNS ci-dessous sont des repères à remplacer :

psql 'host=db.internal.example port=5432 dbname=appdb user=appuser sslmode=verify-full sslrootcert=/chemin/ca-racine.crt'

Saisissez le mot de passe de appuser à l’invite, sans l’ajouter à la ligne de commande. Dans cette session distante, contrôlez l’identité et le chiffrement :

SELECT current_database(), current_user;
SELECT ssl, version, cipher FROM pg_stat_ssl WHERE pid = pg_backend_pid();

Le premier résultat doit identifier appdb et appuser ; le second doit afficher ssl = t et les paramètres TLS de la connexion. verify-full vérifie à la fois la chaîne de certification et l’identité du serveur, selon la documentation TLS du client libpq. Un mot de passe SCRAM ne chiffre pas à lui seul tout le trafic applicatif.

Vérifiez aussi qu’une nouvelle tentative depuis une source non autorisée échoue et qu’une connexion sans TLS est rejetée. Gardez l’accès administratif local pendant ces essais. Pour retirer uniquement la règle firewalld ajoutée par cet exercice, utilisez la même zone et les mêmes paramètres avec --remove-rich-rule, d’abord dans l’état actif puis avec --permanent si vous l’aviez enregistrée. Ne supprimez pas une règle qui préexistait. Pour annuler les changements PostgreSQL, restaurez les lignes sauvegardées, rechargez HBA et redémarrez si l’adresse d’écoute a changé.

Éléments à préparer avant l'exploitation

• Sauvegardes logiques et physiques régulières et tests de restauration réels
• Plan pour l'application des mises à jour mineures prises en charge
• Rôles à privilèges minimum et rotation des mots de passe par application
• Vérification du certificat TLS et utilisation d'un réseau privé ou VPN
• Surveillance de l'utilisation du disque, du nombre de connexions, de la latence, des points de contrôle et des journaux d'erreurs
• Revue de compatibilité et préparation de procédures séparées avant une mise à jour majeure de version

Les mises à jour majeures de PostgreSQL sont différentes des simples mises à jour de paquet. Planifiez le chemin de mise à niveau officiel selon la version, comme pg_upgrade, la réplication logique, ou le dump et la restauration.

Questions fréquemment posées

Impossible de trouver la commande postgresql-setup

Vérifiez le dépôt installé et les noms des paquets. Les outils d'initialisation et les noms de service peuvent différer entre les paquets par défaut de Rocky et les paquets spécifiques à une version PGDG.

Les connexions externes continuent d'être refusées

Vérifiez listen_addresses, la première règle correspondante dans pg_hba.conf, le port d'écoute du service, firewalld et les groupes de sécurité cloud dans cet ordre.

Est-il acceptable d'autoriser 0.0.0.0/0 dans pg_hba.conf ?

0.0.0.0/0 correspond à toutes les adresses IPv4, sans couvrir IPv6. Une règle d’autorisation aussi large est rarement nécessaire pour un serveur applicatif ; limitez la source réellement prévue. Dans l’exemple de cet article, cette plage est utilisée avec reject, pour refuser les autres tentatives visant le couple base/rôle.

Après avoir modifié les fichiers de configuration, dois-je utiliser reload ou restart ?

Cela dépend de l'élément. pg_hba.conf peut être rechargé, mais listen_addresses nécessite un redémarrage. Vérifiez pg_settings.pending_restart et le contexte dans la documentation officielle.