Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je voudrais utiliser pg_dump à partir de ma station locale (192.168.0.36) sur mon serveur (192.168.0.15).
L'objectif final est d'obtenir une sauvegarde d'une base située sur le serveur à partir d'un programme développé en Lazarus sous Windows et sous Linux et exécuté sur la station locale.
Première étape :
PostgreSQL 8.4 est également (pour l'instant) installé sur le 192.168.0.36. Les exe sont dans G:\Wamp\PostgreSQL\bin (Windows 7)
La base, installée sur le serveur (192.168.0.15) , s'intitule basetest, le username est usertest et son password est userpass
chcp 1252
set PSQL="G:\Wamp\PostgreSQL\bin"
%PSQL%\pg_dump --host=192.168.0.15 --username=usertest basetest > c:\test.sql
Cela passe... Mais dans la console, je dois remplir "Mot de passe".
>> Comment règle-t-on ce problème du mot de passe en "interne" à la mySQLdump --password=PASSWD -u USER DATABASE... ?
Méthode préconisée dans les forums : "Sur Microsoft Windows, le fichier est nommé %APPDATA%\postgresql\pgpass.conf (où %APPDATA% fait référence au sous-répertoire Application Data du profile de l'utilisateur"). Ce fichier devra être composé de lignes au format suivant (une ligne par connexion) : nom_hote:port:database:nomutilisateur:motdepasse.
Pour moi, si c'est l'unique réponse, c'est déjà incompréhensible : on parle bien de client/serveur ? Et il faut commencer par aller à la pêche dans un répertoire LOCAL, lire directement des fichiers txt dans lesquels sont écrits EN CLAIR des renseignements contenus par le serveur... la chaine complète d'accès à la base qui plus est ? Et sous Nux, cela serait du même acabit... sans oublier un chmod 0600 ~/.pgpass ?
N'y a-t-il pas une autre méthode propre à PostgreSQL (autre que celle signifiée dans pg_dump --help --> --no-password qui nécessiterait la création d'un utilisateur sans mot de passe qui pourrait accéder à la base) qui ne me semble pas plus sûre que l'autre méthode ?
Il y a évidemment une autre méthode de sauvegarde envisageable par la programmation... bien plus fastidieuse mais cryptable.
Mais enfin si quelqu'un(e) a une autre solution, je suis preneur (cf discussion précédente avec Gleu : "Ou, en effet l'approche de ces lignes de commande est délicate, ou elle ne l'est pas.").
Merci. Cordialement.
Gilles
Dernière modification par Selzig (20/08/2011 21:13:29)
Hors ligne
Vous avez un serveur PostgreSQL (adresse IP 192.168.0.15 dans votre exemple). Il contient vos données, les rôles, leur mots de passe, etc.
Vous avez une autre machine sur laquelle vous avez l'outil pg_dump. Cet outil, pour faire la sauvegarde, doit pouvoir se connecter à PostgreSQL. Pour cela, il a besoin de quelques informations : l'adresse IP de la machine, le numéro de port, le nom de l'utilisateur, le nom de la base de données. Si l'authentification réclame un mot de passe, il faut aussi lui fournir un mot de passe. Donc, à la ligne de commande, vous faites exactement ça. Avec la commande pg_dump ci-dessus, --host permet d'indiquer l'adresse IP, --username le nom, et la base de données en fin. Le numéro de port n'est pas précisé, cela a peu d'importance, il prend celui par défaut. Quant au mot de passe, il serait inacceptable pour des raisons de sécurité de l'indiquer directement sur la ligne de commande. Donc vous avez deux possibilités. La première est de configurer une variable d'environnement (PGPASSWORD si je me rappelle bien). Quand pg_dump est exécuté et que l'authentification réclame un mot de passe, pg_dump commence par vérifier si la variable PGPASSWORD est configurée et si oui, elle utilise sa valeur comme mot de passe. Si PGPASSWORD n'est pas configurée, alors pg_dump peut consulter un fichier pgpass qui contient cette info. Tout ce que vous avez à faire, c'est à configurer PGPASSWORD ou pgpass. Personnellement, j'ai une préférence pour le fichier pgpass mais chacun fait comme il veut. Vous renseignez une fois le fichier et c'est terminé. Le "chmod 0600" permet à ce que personne ne puisse lire ou modifier le fichier en dehors de son propriétaire, ce qui permet de sécuriser cette information.
Guillaume.
Hors ligne
Bonjour,
Merci pour votre réponse. J'avais donc bien compris. Je sais bien que je suis sur un forum d'utilisateurs PostgreSQL mais, si vous le permettez, je vous dirai que je considère cette méthode comme une très mauvaise approche. En cherchant hier soir, j'ai trouvé cet article : http://fossplanet.com/f15/%5Bgeneral%5D … onf-35326/. D'ailleurs même si le fichier était stocké sur le serveur et devait être lu en dur, ce serait tout aussi mauvais car il faudrait ouvrir des droits sur ce répertoire.
Je considère que cela présente un problème de sécurité et également de mise en pratique. Sur chaque station utilisée, il faut générer le fameux fichier... Evidemment, je conçois totalement que cette méthode puisse être considérée comme sûre et pratique, et donne toute satisfaction dans d'autres environnements (ie situations d'accès aux postes notamment) que le mien.
En tout état de cause, je ne comprends pas pourquoi l'équipe de développement n'a pas intégré dans son pg_dump, la possibilité d'utiliser le client/serveur pour questionner la base. En effet, dans la plupart des cas, les bibliothèques nécessaires pour utiliser PGsql devant être installées sur le poste client, la taille de l'exécutable en aurait peu souffert. Je ne considère la solution actuelle "adaptée" que dans un cas : celle où gp_dump est installée sur un poste (serveur) dédié exclusivement à la sauvegarde. Dans ce cas, la présence du fichier est un moindre risque et un moindre soucis d'installation.
Je vous remercie pour votre disponibilité.
Cordialement. Gilles
Dernière modification par Selzig (21/08/2011 08:24:43)
Hors ligne
Je considère que cela présente un problème de sécurité et également de mise en pratique.
Commençons par la sécurité. Le fichier doit ne pouvoir être lu que par son propriétaire. Impeccable en terme de sécurité. L'utilisateur est obligé de connaître son mot de passe pour se connecter. Qu'il ait à le coller dans un fichier que seul lui peut lire et modifier est une très bonne sécurité. Bien meilleur en tout cas que de le coller sur la ligne de commande comme le permet MySQL. En effet, dans le cas du mysqldump, n'importe quelle personne connectée sur la machine peut voir le mot de passe avec un simple "ps -ef" sous Unix et avec le ProcessExplorer sous Windows. Donc PostgreSQL est ici plus sécurisé que MySQL.
Quant à la mise en pratique, il est vrai qu'il faut placer le mot de passe dans un fichier de configuration avec PostgreSQL. Dans le cas de MySQL, vous devez le placer dans le fichier de script. Ce qui revient plus ou moins au même.
En tout état de cause, je ne comprends pas pourquoi l'équipe de développement n'a pas intégré dans son pg_dump, la possibilité d'utiliser le client/serveur pour questionner la base.
C'est le cas et je ne vois pas ce que ça change. C'est au client d'envoyer le mot de passe au serveur. Et le client doit bien le trouver quelque part. Soit l'utilisateur lui fournit, soit il le trouve sur la ligne de commande, soit il le récupère dans un fichier (forcément local, comment aurait-il accès au serveur?). Les développeurs de PostgreSQL ne veulent pas faciliter l'utilisation du mot de passe sur la ligne de commande à cause des problèmes de sécurité que cela comporte. Donc il ne reste que les deux autres solutions.
En effet, dans la plupart des cas, les bibliothèques nécessaires pour utiliser PGsql devant être installées sur le poste client, la taille de l'exécutable en aurait peu souffert.
pg_dump, comme tous les outils PostgreSQL, utilise une bibluiothèque, qui est la libpq. C'est d'ailleurs elle qui est en charge de lire et interprété le fichier pgpass.
Je ne considère la solution actuelle "adaptée" que dans un cas : celle où gp_dump est installée sur un poste (serveur) dédié exclusivement à la sauvegarde. Dans ce cas, la présence du fichier est un moindre risque et un moindre soucis d'installation.
Ce n'est en rien un risque sauf dans votre cas particulier dont on va parler tout de suite après. Le fichier pgpass est une excellente alternative, que ce soit sur un poste serveur ou sur un poste client, comme celui d'un administrateur par exemple.
En cherchant hier soir, j'ai trouvé cet article : http://fossplanet.com/f15/%5Bgeneral%5D … nf-35326/.
C'est en lisant ce thread que je crois avoir compris ce qui vous embêtait. En gros, vous installez des outils sur les postes clients, outils qui accèdent à la base de données. Mais vous ne voulez pas que les utilisateurs puissent eux-même se connecter à la base. Donc je suppose que nom d'utilisateur de la base de données et mot de passe sont soit stockés en dur dans le programme soit écrit chiffrés sur le disque. Peu importe. Mais en effet, dans ce cas, vous ne voulez pas que les utilisateurs puissent accéder à ces informations là pour accéder à la base sans votre outil. Il y a une solution avec pg_dump à laquelle je viens de penser. Vous n'êtes pas obligé de fournir les informations via les options en ligne de commande. Vous pouvez aussi fournir un DSN à l'outil qui vous intéresse. Dans le DSN, vous pouvez placer un certain nombre d'informations, dont le mot de passe. Ce qui pourrait donner ceci :
pg_dump "dbname=postgres user=guillaume password=guillaume"Ce qui va résoudre votre problème. Jusqu'à ce qu'un utilisateur, plus malin que les autres, regarde la liste des processus en cours d'exécution et y voit le mot de passe... (ceci est déjà vrai avec MySQL).
Guillaume.
Hors ligne
Merci pour ces informations.
Bonne fin de WE.
Cordialement. Gilles
Hors ligne
PostgreSQL 8.4 est également (pour l'instant) installé sur le 192.168.0.36. Les exe sont dans G:\Wamp\PostgreSQL\bin (Windows 7)
La base, installée sur le serveur (192.168.0.15) , s'intitule basetest, le username est usertest et son password est userpasschcp 1252 set PSQL="G:\Wamp\PostgreSQL\bin" %PSQL%\pg_dump --host=192.168.0.15 --username=usertest basetest > c:\test.sqlCela passe... Mais dans la console, je dois remplir "Mot de passe".
Il suffit d'ajouter
set PGPASSWORD=userpassdans le script avant l'appel à pg_dump pour éviter la saisie manuelle.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
En effet,
cela fonctionne très bien.
Merci beaucoup Dverite.
Cordialement. Gilles
Hors ligne
Pages : 1