Comme nous l'énoncions, au début de ce chapitre, la prochaine étape concerne l'initialisation du répertoire qui accueillera nos futures bases de données: PGDATA. Pour l'instant, ce répertoire n'existe pas encore. Or avec PostgreSQL, seul le super-utilisateur a le droit de le créer.

Mais alors qui est ce super-utilisateur?

Ce super-utilisateur - comme première propriété - doit être un utilisateur physique de votre machine. Oui mais depuis la version 8.2.1 de PostgreSQL, les programmeurs de PostgreSQL pour des raisons de sécurité (impliquant des failles/fuites de sécurités selon les droits accordés à cet utilisateur sous Linux qui peuvent être dûe à des attaques de requêtes de type "SQL injection" par le réseau ou par une mauvaise utilisation des modules objets chargés dans les bases par de simples utilisateurs etc...) ont imposés que cet utilisateur devait avoir des droits limités sur la machine sur lequel tourne PostgreSQL.

Or, sous Windows, on distingue deux types d'utilisateurs:

Le super-utilisateur - comme seconde propriété - sera donc un utilisateur ayant des droits limités

Oui mais - comme troisième propriété - comme son titre l'indique, il sera le grand manitou, le gourou au sens de PostgreSQL de la secte des utilisateurs de PostgreSQL. Il a le droit de créer des utilisateurs, d'étendre/restreindre leur droit de lecture/modification aux bases de données du serveur. Il aura aussi le droit de leur accorder le droit de créer ou non des bases par exemple, de leur attribuer des mots de passe etc...En un mot, il aura droit de vie/mort sur ses sujets :-)

Mais ici, nous resterons dans la politique dite du "trusting". Je m'explique. Pour la suite du document je vais supposer que vous êtes administrateur sur la machine sur laquelle vous avez installé PostgreSQL et les autres outils. Nous allons demander au super-utilisateur de nous confier ses supers pouvoirs (à vous) et de faire confiance à toute machine du réseau qui se connecterait au serveur PostgreSQL sans demander de mot de passe à sa majesté.

Il ne reste donc plus en première instance qu'à créer ce fameux super-utilisateur.

Sur votre machine, voyez si s'il n'existe pas déjà un utilisateur ayant des droits limités et possédant un mot de passe. Si ce dernier n'existe pas, créez-le. Attention, il est impératif que cet utilisateur ait des droits limités sur la machine et qu'il ait un mot de passe.

Pour faciliter la lecture des futures commandes de ce document, j'appelerais postgres le super-utilisateur de PostgreSQL et david un administrateur sous Windows - qui vous correspondra sous Windows. Sous Windows, postgres et david auront comme mot de passe empr888. Donc, pour récapituler - même si je me répète -, postgres est un utilisateur limité sous Windows et david est administrateur de la machine (vous correspondant) à qui on souhaite conférer les pouvoirs de super-utilisateur de postgres le moment venu. Vos futures commandes seront donc à modifier en fonction des spécifications ici mentionnées. Les lignes de commandes permettant de distinguer les deux fenêtres des utilsateurs commenceront par '# sous david:' (correspondant à votre session) ou bien '# sous postges :' (correspondant à la fenêtre du super-utilisateur que vous aurez plus tard). TOUTES LES COMMANDES SUIVANTES SONT A SAISIR DANS DES FENÊTRES DOS.

root@jenna-edgy:/mnt/sources/postgresql-8.2.0# adduser postgres
Ajout de l'utilisateur « postgres »...
Ajout du nouveau groupe « postgres » (1001).
Ajout du nouvel utilisateur « postgres » (1001) avec le groupe « postgres ».
Création du répertoire personnel « /home/postgres ».
Copie des fichiers depuis « /etc/skel »
Enter new UNIX password:
Retype new UNIX password:
passwd : le mot de passe a été mis à jour avec succès
Modification des informations relatives à l'utilisateur postgres
Entrez la nouvelle valeur ou « Entrée » pour conserver la valeur proposée
        Nom complet []:
        No de bureau []:
        Téléphone professionnel []:
        Téléphone personnel []:
        Autre []:
Ces informations sont-elles correctes [o/N] ? o

Imaginons que nous soyons connectés sous Windows sous la session de david. La prochaine étape va constituer à initialiser le répertoire PGDATA. Ceci se fait en ouvrant normalement une fenêtre DOS sous la session de postgres. Pour éviter de changer de session et accéder plus facilement à cette fenêtre, ceci est possible depuis la session de david.

Pour cela, il faut utiliser la commande runas de Windows. Je sais qu'elle existe sous Windows XP mais je ne garantis pas ici son existence sous Windows 2000. L'obtention de la fenêtre en question se fait en saisissant dans une fenêtre DOS:

# sous david:
runas /user:postgres cmd

Il suffit alors comme demandé de saisir le mot de passe de postgres.

Figure 4.2. Utilisation de la commande runas

Une nouvelle fenêtre DOS appartenant à postgres devrait s'ouvrir. C'est cette fenêtre qui désignera comme nous l'avons dit '# sous postgres' maintenant

Figure 4.3. Nouvelle fenêtre DOS obtenue

Avant la version 7.5 devel de PostgreSQL - version qui n'existe plus aujourd'hui -, l'ancienne façon pour autoriser les connexions TCP/IP était de fournir l'option -o -i à l'outil en ligne de commande pg_ctl. Depuis la version 8.0, cette méthode a été délaissée au profit d'une autre méthode. La manière la plus élégante pour autoriser les connexions TCP/IP est de modifier le paramètre listen_addresses du fichier sous Windows c:\PostgreSQL\8.2.1\data\postgresql.conf, respectivement /usr/local/pgsql/data/postgresql.conf pour GNU/Linux.

Ouvrez ce fichier et remplacez la ligne

#listen_addresses = 'localhost' # what IP interface(s) to listen on; 

par

listen_addresses = '*' # what IP interface(s) to listen on; 

Le démarrage manuel impose que vous devez démarrer PostgreSQL à chaque démarrage physique de votre machine. Pour cela, il faut utiliser l'outil pg_ctl . Si tel est votre choix, pour démarrer PostgreSQL

# sous postgres:
pg_ctl start

Pour arrêter le serveur, il suffit de taper:

# sous postgres:
pg_ctl stop

N'oubliez que si vous choisissez cette méthode, vous devez d'abord saisir la commande donnée avec runas si vous démarrez votre machine depuis votre session habituelle (cd. david ici).

Figure 4.5. Démarrage manuel de PostgreSQL

Figure 4.6. Arrêt manuel de PostgreSQL

Avec cette méthode, vous n'aurez pas besoin de vous soucier de démarrer PostgreSQL à chaque démarrage de votre machine. En effet, nous allons ici procéder à l'installation du service Windows, livré avec PostgreSQL. C'est toujours pg_ctl que nous utiliserons avec l'option register

# sous david:
pg_ctl register -N postgresqlwin32 -U postgres -P empr888

4.6.3.2. Lancer le service

cela se fait en tapant

# sous david:
net start postgresqlwin32

Figure 4.7. Installation et démarrage du service (postgresqlwin32)pour PostgreSQL

Rappel: ces deux états (installation et démarrage) du service ne sont à effectuer qu'une seule fois!

Dans les sources de PostgreSQL, dans le sous-répertoire contrib/start-scripts/, vous trouverez un script nommé linux à partir duquel nous pouvons nous baser pour créer un script qui permettra l'instalaltion du service

#! /bin/sh

# chkconfig: 2345 98 02
# description: PostgreSQL RDBMS

# This is an example of a start/stop script for SysV-style init, such
# as is used on Linux systems.  You should edit some of the variables
# and maybe the 'echo' commands.
#
# Place this file at /etc/init.d/postgresql (or
# /etc/rc.d/init.d/postgresql) and make symlinks to
#   /etc/rc.d/rc0.d/K02postgresql
#   /etc/rc.d/rc1.d/K02postgresql
#   /etc/rc.d/rc2.d/K02postgresql
#   /etc/rc.d/rc3.d/S98postgresql
#   /etc/rc.d/rc4.d/S98postgresql
#   /etc/rc.d/rc5.d/S98postgresql
# Or, if you have chkconfig, simply:
# chkconfig --add postgresql
#
# Proper init scripts on Linux systems normally require setting lock
# and pid files under /var/run as well as reacting to network
# settings, so you should treat this with care.

# Original author:  Ryan Kirkpatrick <pgsql@rkirkpat.net>

# $PostgreSQL: pgsql/contrib/start-scripts/linux,v 1.7 2004/10/01 18:30:21 tgl Exp $

## EDIT FROM HERE

# Installation prefix
prefix=/usr/local/pgsql

# Data directory [  ! ! ! LIGNE A MODIFIER  ! ! !]
PGDATA="/usr/local/pgsql/data"

# Who to run the postmaster as, usually "postgres".  (NOT "root")
PGUSER=postgres

# Where to keep a log file [  ! ! ! LIGNE A MODIFIER - A COMMENTER ! ! !]
#PGLOG="$PGDATA/serverlog"

## STOP EDITING HERE

# Check for echo -n vs echo \c
if echo '\c' | grep -s c >/dev/null 2>&1 ; then
    ECHO_N="echo -n"
    ECHO_C=""
else
    ECHO_N="echo"
    ECHO_C='\c'
fi

# The path that is to be used for the script
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# What to use to start up the postmaster (we do NOT use pg_ctl for this,
# as it adds no value and can cause the postmaster to misrecognize a stale
# lock file)

DAEMON="$prefix/bin/postmaster"

# What to use to shut down the postmaster
PGCTL="$prefix/bin/pg_ctl"

set -e

# Only start if we can find the postmaster.
test -x $DAEMON || exit 0

# Parse command line parameters.
case $1 in
  start)
	$ECHO_N "Starting PostgreSQL: "$ECHO_C
	su - $PGUSER -c "$DAEMON -D '$PGDATA' &" 2>&1
	echo "ok"
	;;
  stop)
	echo -n "Stopping PostgreSQL: "
	su - $PGUSER -c "$PGCTL stop -D '$PGDATA' -s -m fast"
	echo "ok"
	;;
  restart)
	echo -n "Restarting PostgreSQL: "
	su - $PGUSER -c "$PGCTL stop -D '$PGDATA' -s -m fast -w"
	su - $PGUSER -c "$DAEMON -D '$PGDATA' &"  2>&1
	echo "ok"
	;;
  reload)
        echo -n "Reload PostgreSQL: "
        su - $PGUSER -c "$PGCTL reload -D '$PGDATA' -s"
        echo "ok"
        ;;
  status)
	su - $PGUSER -c "$PGCTL status -D '$PGDATA'"
	;;
  *)
	# Print help
	echo "Usage: $0 {start|stop|restart|reload|status}" 1>&2
	exit 1
	;;
esac

exit 0

chmod 744 /etc/init.d/postgresql

update-rc.d postgresql defaults

/etc/init.d/postgresql {start|stop}

Déterminer le jeu de chiffrage IP de votre réseau intranet. Nous allons supposer ici que ce sera 192.168.134.X où X est un numéro quelconque du réseau. Nous allons autoriser toutes les machines du réseau à se connecter au serveur PostgreSQL.

Éditez le fichier c:\PostgreSQL\8.2.1\data\pg_hba.conf et ajoutez la ligne suivante dans ce fichier:

host    all         all         192.168.134.0    255.255.255.0          trust

Le zéro dans la chaine 192.168.134.0 est là pour dire que toute la plage du réseau disponible est autorisée.

host all all 192.168.134.1/12 trust

Il suffit ensuite de redémarrer le serveur en remplaçant le mot-clé 'stop' par 'start'. Autre astuce, au lieu de démarrer le serveur, il suffit normalement de saisir pg_ctl reload pour prendre en compte les modifications apportées à ce fichier.

Du côté client, pour pouvoir se connecter, l'utilisateur pourra par exemple se connecter en précisant juste un nom de super-utilisateur de PostgreSQL du serveur ainsi que son IP:

psql -h SERVEUR_IP -U SERVEUR_USER -d BASE_DE_DONNEES ...

Si par exemple, l'hôte serveur a pour IP 192.168.134.7 et que le nom du super-utilisateur est postgres et qu'on veuille se connecter à la base mabasededonnees

psql -h 192.168.134.7 -U postgres -d mabasededonnees ...

Le but ici est de créer un utilisateur normal - qui n'est pas super-utilisateur - de PostgreSQL. Celui doit pouvoir

Dans l'attente des objectifs ci-dessus, nous savons que postgres et david - voir les sections précédentes - sont super-utilisateurs. Nous appelerons l'utilisateur en question keizer - on reconnait là les fans de Usual Suspects! LOL - et la base à laquelle il se connectera nous l'appelerons testgis. Nous supposerons donc que david a créé cette base, puisque cette base doit être déjà existante.

createuser --help

createuser -D -e -P -E -R -S keizer

createuser -DePERS keizer

david@OLIVIA ~
$createuser -DePERS keizer
Entrez le mot de passe pour le nouvel utilisateur : soze
Entrez-le de nouveau : soze
CREATE ROLE keizer ENCRYPTED PASSWORD 'azer' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;
CREATE ROLE

ALTER USER keizer PASSWORD 'kobayashi';

host    testgis     keizer    0.0.0.0   0.0.0.0     md5

pg_ctl reload

4.8.2.3. Accorder au nouvel utilisateur les droits d'accès aux données déjà existantes dans la base

Pour notre dernier objectif à atteindre, il nous faut rendre keizer propriétaire de la base déjà existante ainsi que des tables déjà existantes. En effet, nous rappelons à cette fin que ces dernières ont été créées par le super-utilisateur david. Ces droits sont accordés en ayant recours aux deux requêtes suivantes. david est donc propriétaire de la base et des tables déjà existantes:

• pour la base testgis:

  ALTER DATABASE testgis OWNER TO keizer

• pour chaque table de la base:

  ALTER TABLE table OWNER TO keizer

Pour connaître les nom des tables contenues dans la base tesgis, on peut utiliser la requête suivante:

SELECT tablename FROM pg_tables WHERE (tablename NOT LIKE 'pg_%')
AND (tablename NOT LIKE 'sql_%')

et tout en sachant que l'on peut exécuter une requête dynamiquement grâce au moniteur interactif psql (voir prochain chapitre) pour exécuter une requête:

psql -d BASE_DE_DONNEES -c "REQUETE"

Il suffit alors d'avoir recours au petit script shell suivant pour effectuer tout le travail demandé côté serveur:

# à copier dans un script par exemple altertable.sh
psql -d testgis -c "ALTER DATABASE testgis OWNER TO keizer"
psql -d testgis -c "`psql -F " " -Atd testgis -c "select 'ALTER TABLE '\
||tablename||' OWNER TO keizer;' from pg_tables where \
(tablename not like 'pg_%') and (tablename not like 'sql_%') order by tablename`"

En effet, la commande

psql -F " " -Atd testgis -c "select 'ALTER TABLE '\
||tablename||' OWNER TO keizer;' from pg_tables where \
(tablename not like 'pg_%') and (tablename not like 'sql_%') order by tablename

renvoit textuellement les requêtes suivantes

ALTER TABLE <nom_de_la_premiere_table> OWNER TO keizer;
ALTER TABLE <nom_de_la_seconde_table> OWNER TO keizer;
ALTER TABLE <nom_de_la_troisieme_table> OWNER TO keizer;
etc...

Copiez ce code dans un script nommé altertable.sh et, depuis MinGW, tapez simplement pour l'exécuter:

altertable.sh

Figure 4.8. Exemple de connexion dans PgAdmin III

Dans le répertoire C:\PostgreSQL\8.2.1\data, nous allons commencer par définir un sous-répertoire pour y stocker nos fichiers de log. Appelons-le data. Pour le créer, utilisez la création de répertoire usuelle sous Windows ou depuis une fenêtre DOS tapez la commande

mkdir C:\PostgreSQL\8.2.1\data\pg_log

mkdir /usr/local/pgsql/data/pg_log

Ouvrez maintenant le fichier postgresql.conf et rendez-vous aux alentours de la ligne 214 et activez les paramètres redirect_stderr, log_directory et log_filename:

...
...
#---------------------------------------------------------------------------
# ERROR REPORTING AND LOGGING
#---------------------------------------------------------------------------

# - Where to Log -

#log_destination = 'stderr'		# Valid values are combinations of 
					# stderr, syslog and eventlog, 
					# depending on platform.

# This is used when logging to stderr:
redirect_stderr = on			# Enable capturing of stderr into log 
					# files

# These are only used if redirect_stderr is on:
log_directory = 'pg_log'		# Directory where log files are written
					# Can be absolute or relative to PGDATA
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # Log file name pattern.
					# Can include strftime() escapes
#log_truncate_on_rotation = off # If on, any existing log file of the same 
					# name as the new log file will be
...
...

Pour aller un peu plus loin, nous allon aussi activer des paramètres supplémentaires qui vont nous permettre de savoir qui a effectué une requête, depuis quelle IP, sur quelle base. Pour celà, rendez-vous de la ligne 298 à la ligne à la ligne 316 pour activer les paramètres log_line_prefix, log_statement et log_hostname comme suit:

log_line_prefix = '[UTILISATEUR=%u HOTE=%h BASE=%d HEURE=%t COMMANDE=%i]'			
					# Special values:
					#   %u = user name
					#   %d = database name
					#   %r = remote host and port
					#   %h = remote host
					#   %p = PID
					#   %t = timestamp (no milliseconds)
					#   %m = timestamp with milliseconds
					#   %i = command tag
					#   %c = session id
					#   %l = session line number
					#   %s = session start timestamp
					#   %x = transaction id
					#   %q = stop here in non-session 
					#        processes
					#   %% = '%'
					# e.g. '<%u%%%d> '
log_statement = 'all'			# none, mod, ddl, all
log_hostname = on

Si vous voulez voir l'intérêt des paramètres activés ici, rallumez donc votre serveur au moins deux fois - en prenant bien sûr qu personne ne soit connecté dessus ;-) -. Regardez le contenu du sous-répertoire data en question. Effectuez quelques requêtes sur le serveur et examinez le contenu du tout dernier fichier de log.