Configuration de PostgreSQL
cluster
clusterpar initdb certains ajustements sont nécessaires :
Host based authentification),
le nom de ce fichier vient de l'acronyme de Host Based Authentification.
Le mécanisme des ACL est présent dans de nombreux systèmes informatiques, on le retrouve par exemple dans les annuaires LDAP ou encore dans les systèmes de fichier UNIX avec les ACL POSIX.
Les sockets
UNIX indiquent un point d'accès via le système de fichiers. le fichier est de type socket et est
préfixé par un s lors d'un ls -la. Le client psql accepte une indication d'adresse de connexion, si
celle-ci correspond à un répertoire, celui-ci sera utilisé pour localiser le fichier de socket
qui devra être de la forme
.s.PGSQL.num_port.
Les adresses IP pourront correspondre à des machines ou à des réseaux. On devra utiliser indifféremment l'une des notation avec masque ou en format CIDR, en IPv4 comme en IPv6.
Il existe un grand nombre de modes d'authentification, certains sont à éviter tel que password qui véhicule en clair les mots de passe sur le réseau. La liste complète est accessible à http://docs.postgresql.fr/current/client-authentication.html
local all +users,test md5 local all all peer host postgres usera 10.0.0.5/32 password host postgres all 10.0.0.0/24 ldap ldap params host all all .exemple.com ident host all all test.mon-domaine.com reject host all all 192.168.0.0/16 ident map=letest host db1,db2 all 0.0.0.0/0 krb5 host all all 127.0.0.1/32 pam host all all ::1/128 trust
Comme l'illustre cet exemple, il est également possible d'indiquer un réseau par son nom de domaine préfixé de . ou une machine par son nom.
Un utilisateur peut être indiqué par son appartenance à un groupe, dans ce cas il sera préfixé par un +. Nous verrons plus tard la gestion des utilisateurs et des rôles pour permettre cette appartenance.
En cas d'authentification via Ldap il faudra fournir les paramètres d'accès à l'annuaire par ldapserver=ip serveur, ldapprefix=le prefixe, ldapsuffix=le suffixe...
Ce mécanisme ne peut être pris en compte que pour les utilisateurs du système d'exploitation, c'est à dire ceux qui seront identifiables par le service d'identification (sous Unix c'est le service auth disponible au port 113/TCP) ou encore par le module d'authentification pam. Le service d'auhentification peut être lancé à partir du paquet oidentd.
Cette technique impose toutefois qu'un utilisateur indique le nom qu'il veut utiliser, en revanche aucune demande d'authentification ne sera réalisée
pour prendre une identité dont la correspondance est assurée par la map
visée dans le fichier pg_ident.conf.
# MAPNAME SYSTEM-USERNAME PG-USERNAME letest /^(.*)@.*$ \1 letest userb usera letest usera usera
psql -h 192.168.8.3 -U usera -p 5432 postgres psql (9.6.1) Saisissez « help » pour l'aide. ...
identifiant postgresla partie gauche de l'adresse.
On remarque que l'utilisateur système test peut se connecter sans mot de passe en tant qu'utilisateur système usera sous réserve qu'il soit déjà authentifié. Ceci aurait également été vrai pour tout autre utilisateur reconnu par PostgreSQL.
En mode ident ce mécanisme n'est opérationnel que si le serveur d'identification est actif, ce qui n'est pas toujours vrai !
Les lignes de ce fichier présentent des variables avec des valeurs associées. Une ligne commençant par # indique un commentaire. Dans la plupart des installations de PostgreSQL l'ensemble des paramètres est présent sous forme de lignes commentées, avec comme valeur associée la valeur utilisée par défaut.
Nos serons amenés à modifier des paramètres dans ce fichier tout au long de cette formation d'administration de PostgreSQL.
clusterpeut être relocalisé par le paramètre data_directory=chemin/vers/cluster.
Les distributions Linux/Debian utilisent cette technique de relocalisation de la configuration en positionnant les arborescences contenant postgresql.conf selon des chemins du type /etc/postgresql/version/main/.
internal | la valeur ne peut être modifiée (parfois en recompilant le système) |
postmaster | la modification exige un redémarrage |
sighup | la modification peut être prise en compte par envoi du signal HUP |
superuser-backend | la modification est prise en compte en début de session uniquement par
le superuser |
superuser | peut être modifiée en session par le superuser |
backend | la modification est prise en compte en début de session par n'importe qui |
user | peut être modifiée en session par n'importe qui |
Pour localiser rapidement le fichier de configuration principal (nommé postgresql.conf) nous disposons du champ config_file (en lecture seule). Aussi les commandes suivantes permettent de localiser tous les éléments de la configuration :
SHOW config_file; config_file ------------------------------------------ /etc/postgresql/9.6/main/postgresql.conf (1 ligne) SHOW data_directory; data_directory ------------------------------ /var/lib/postgresql/9.6/main (1 ligne) SHOW hba_file; hba_file -------------------------------------- /etc/postgresql/9.6/main/pg_hba.conf (1 ligne) SHOW ident_file; ident_file ---------------------------------------- /etc/postgresql/9.6/main/pg_ident.conf (1 ligne)
On voit dans cette configuration que les chemins ont été modifiés (système DEBIAN).
nom de la colonne | description |
---|---|
name | nom du paramètre de configuration |
setting | valeur courante |
unit | unité (si applicable) |
category | section de configuration : log, autovacuum, ... |
short_desc | description courte |
extra_desc | description longue |
context | contexte de mise à jour |
vartype | type de paramètre : bool, enum, integer, real ou string |
source | provenance de la valeur, fichier, session, config... |
min_val | valeur minimale |
max_val | valeur maximale |
enumvals | valeur énumérées permises |
boot_val | valeur de compilation |
reset_val | valeur utilisée après démarrage |
sourcefile | nom du fichier responsable de l'affectation |
sourceline | numéro de la ligne du fichier affectant la variable |
pending_restart | vrai si attente de redémarrage après modification l'exigeant |
La valeur booléenne pending_restart, est positionnée à true
si suite à un rechargement de la configuration
il est remarqué que le paramètre à été modifié par rapport à sa valeur courante, mais que sa prise en compte ne pourra s'effectuer
qu'après un redémarrage du serveur.
ALTER SYSTEM SET max_connections TO 80; ALTER SYSTEM
Suite à l'envoi de cette commande le fichier postgresql.auto.conf aura pour contenu :
# Do not edit this file manually! # It will be overwritten by ALTER SYSTEM command. max_connections = '80'
Pour annuler les modifications réalisées via ALTER SYSTEM il suffit simplement de détruire le fichier postgresql.auto.conf.
La commande pg_ctl -D chemin/vers/cluster reload n'est en réalité qu'un appel de la commande kill -HUP pid_serveur.
Par exemple pour permettre des fonctionnements simultanés de
indépendants il faudra leur préciser des numéros de port TCP différents. Le numéro port est indiqué dans le fichier postgresql.conf situé à priori à la racine du . Par défaut le port 5432 est utilisé.