Créer un utilisateur de base de données standard
Il est fortement conseillé, même dans un environnement de test/développement, de ne pas utiliser le super administrateur pour une utilisation courante. Pour cela la première chose à faire après l’installation du serveur est de créer un utilisateur standard. Se connecter au serveur en tant que super administrateur:psql -d postgresUne fois connecté, exécuter:
create user utappli with login encrypted password 'mputappli';Ensuite vérifier la création effective de cet utilisateur:
select * from pg_roles where rolname='utappli';Enfin quitter psql
\qPour tester la connexion de l’utilisateur utappli, exécuter:
psql -h localhost -d postgres -U utappliFournir le mot de passe paramétré: mputappli, quand il sera réclamé. Cet utilisateur et son mot de passe peuvent être utilisés par l’application en développement pour se connecter au serveur.
Créer une base de données
Pour stocker les données de l’application en développement, il y a un besoin de créer une base de données. Pour cela se connecter en tant que super administrateur et exécuter la requête de création d’une base de données dont le propriétaire est utappli:psql -d postgres create database bdappli owner utappli; \q
Créer les tables de données
L’utilisateur utappli étant le propriétaire de la base de données bdappli, il a tous les droits sur cet objet. Par conséquent, on n’a plus besoin de se connecter en tant que super administrateur. Pour créer une table dans la base de donnée qui vient d’être créée, il faut se connecter à cette base de données en tant que utappli et exécuter les requêtes:psql -h localhost -U utappli -d bdappli create schema commerce; create table commerce.produits (id serial, code varchar(12), nom varchar(100)); select * from commerce.produits;La dernière requête SQL exécutée permet de vérifier la création effective de la table. Au cours du développement cette requête permettra de vérifier le contenu géré par le code de l’application. Bien entendu d’autres tables ou schémas peuvent être créés de la même manière.
Se connecter au serveur à partir d’une autre machine
Par défaut, la configuration du serveur ne permet que des connexions à partir de la même machine. Cela peut convenir pour un utilisateur-développeur qui utilise seul son serveur. Si une autre personne, qui utilise donc une autre machine, souhaite utiliser les données de ce serveur elle ne pourra pas. Ce comportement peut être changé par la modification de deux fichiers de configuration. Editer pg_hba.conf:vi /etc/postgresql/10/pgtest/pg_hba.confAjouter la ligne suivante:
host all all 0.0.0.0/0 md5Editer postgresql.conf:
vi /etc/postgresql/10/pgtest/postresql.confRepérer la ligne:
#listen_addresses = 'localhost'Modifier cette ligne, en (enlever le # et remplacer localhost par *):
listen_addresses = '*'Pour tenir compte de ces modifications, redémarrer le serveur:
pg_ctlcluster 10 pgtest restartPour se connecter, la personne distante, doit utiliser la même commande que pour la connexion locale sauf pour le paramètre -h (host):
psql -h xxx.xxx.xxx.xxx -U utappli -d bdapplixxx.xxx.xxx.xxx est l’adresse IP de la machine serveur de base de données, par exemple 192.168.0.1. Pour trouver cette adresse IP, exécuter sur cette machine:
sudo ifconfigRepérer dans la réponse l’adresse qui est mentionnée par le libellé inet. Si cela vous semble compliqué, exécuter:
sudo ifconfig | sed "s/^[ ]*//g" | egrep ^inet | egrep -v "(^inet6|127.0.0.1)" | awk '{ print $2 }'Cette commande doit afficher une seule adresse IP, utilisez la. Si elle affiche plusieurs, c’est que la machine est connectée à plusieurs réseaux (filaire et wifi par exemple). Dans ce cas toutes ces adresses peuvent être utilisées si la machine de connexion est également connectée au même réseau.
Contrôler les requêtes SQL exécutées par l’application
Il est très utile de pouvoir contrôler les requêtes SQL exécutées par le code de l’application en développement, afin de les affiner. Cette faculté de contrôle est plus nécessaire encore s’il s’agit d’une application de type JEE qui s’exécute dans un serveur d’application. Par défaut le serveur PostgreSQL n’inscrit pas dans son fichier de log le texte de ces requêtes. Ce comportement est modifiable par le fichier postgresql.conf. Editer ce fichier et repérer la ligne qui commence par:#log_statement = 'none'Modifier cette ligne, en (enlever # et remplacer none par all):
log_statement = 'all'Pour la prise en compte, recharger les fichiers de configuration par la commande:
pg_ctlcluster 10 pgtest reloadA partir de ce moment, le serveur inscrit dans son fichier de log toutes les requêtes exécutées. Pour tester ce comportement, se connecter et exécuter une requête quelconque:
psql -d postgres select * from pg_roles; \qEnsuite vérifier:
cat ~/pgtest.logLa requête qui vient d’être exécutée doit apparaître à la fin de ce fichier. ]]>