Vous n'êtes pas identifié(e).
Pages : 1
2/ J'ai ajouté via l'utilitaire de pgadmin III la ligne suivante au fichier pg_hba.conf :
host all all 192.168.1.22 trust
La machine que je veux connecter étant 192.168.1.22. Pour la méthode j'ai tout essayé : md5, trust, ident sameuser etc.
Il doit falloir rajouter le masque CIDR, la ligne est erronée, ce doit être pour ça qu'elle n'apparait pas dans pgadmin et que le serveur ne démarre pas.
Essaye avec
host all all 192.168.1.22/32 trust
et joue avec la taille du masque pour étendre les connections à ton sous-réseau.
par exemple avec
host all all 192.168.1.0/24 trust
tu donnes accès au serveur à toutes les ips de la forme 192.168.1.x
Reste la sempiternelle question du "qu'est-ce que ça peut bien faire que les utilisateurs voient les autres bases ?". Ceci dit, vous faites comme vous voulez. Deux points supplémentaires :
* il est possible de demander à pgadmin de cacher certaines bases (champ "DB restriction" d'un serveur)... cela étant dit, ça n'empêche pas les utilisateurs de lancer eux-mêmes la requête "SELECT * FROM pg_database" dans l'éditeur de requêtes
* si vous placez 15 instances sur le même serveur, vuos allez avoir plus de mal à configurer la mémoire pour chaque instance.
Car j'ai ouvert un serveur postgis au public avec un login anonyme/anonyme et sur le même serveur j'ai des bdds de mon entreprise, genre une base contacts. Je n'ai pas envie que des gens puissent être "tentés" par des actions de piratage à la vue des noms des bases entreprise. Donc j'aurais deux instances, ça me semble convenable, je n'ai pas de grosses sollicitations sur le sgbd.
hors sujet : mais si ça vous intéresse, voici une solution postgre avec une couche géographique postgis couplée à mapserver, phpmapscript et ajax/javascript :
http://irennes.net/cartogeo.php
la liste des couches stockées dans le serveur :
http://irennes.net/cartoservices.php
et un tuto pour expliquer comment se connecter à ce type de serveur depuis un SIG :
http://irennes.net/cartoservicesdoc.php
Bien à vous et merci de faire vivre la communauté postgre francophone 
Pierre.
hop c fait, la suite pg_* de debian est très pratique, jusque la je faisais tout salement à la main avec des initdb et des pgctl start dans des scripts d'init tous crades. Maintenant c'est bien tout au format debian, nickel.
ok merci
Je pense que la solution va être de clusteriser.
A ce sujet je vois deux pistes.
- Faire un initdb sur une nouvelle base qui accueillera base2 et base3. et faire un pgctl start dessus sur un port <> 5432.
- La deuxième solution que j'ai trouvé sur le web consiste à utiliser pg_creatcluster.
Vous conseilleriez quoi ?
ok, merci de ta réponse Marc.
Bonjour,
J'ai un serveur avec plusieurs bases, disons base1 base2 et base3.
J'ai un role "anonyme" qui peut se connecter à une seule de ces bases : base1. Il n'a que des droits de select sur certains schemas. Mais le probleme c'est que si on se connecte au serveur via pgadmin par exemple avec ce role, on peut également voir les bases base2 et base3. Visuellement elles apparaissent dans les bases du serveur une fois ocnnecté, meme si le role anonyme n'y a pas accès, il les voit tout de meme. Est-ce possible de les cacher ?
Merci à vous,
Pierre.
Bonjour, voici une version moins sale pour mettre à jour des droits de visualisation :
#!/bin/bash
# Le script doit être exécuté en tant que user postgres
# Donne des droits en lecture seule à un utilisateur sur
# les schemas publics d'une base de donnée postgres. Les
# droits sont limités à la visualisation des tables
# publiques de la base ( lecture seule : SELECT ).
USERNAME="mon_user"
DATABASENAME="ma_db"
MAXCONNECTIONS="15"
PSQL="/usr/lib/postgresql/8.3/bin/psql"
# Mise à jour des droits sur les schemas
REQUETE="select n.nspname
from pg_namespace n
where n.nspname <> 'pg_catalog'
and n.nspname <> 'information_schema'
and n.nspname !~ '^pg_toast'
and n.nspname <> 'pg_temp_1';"
for schema in `$PSQL -At -d $DATABASENAME -c "$REQUETE"`
do
$PSQL -a -d $DATABASENAME -c "GRANT USAGE ON SCHEMA $schema TO $USERNAME"
done
# Mise à jour des droits sur les tables
REQUETE="select n.nspname||'.'||c.relname
from pg_class c, pg_namespace n
where c.relnamespace=n.oid
and n.nspname <> 'pg_catalog'
and n.nspname <> 'information_schema'
and n.nspname !~ '^pg_toast'
and c.relkind='r';"
for table in `$PSQL -At -d $DATABASENAME -c "$REQUETE"`
do
$PSQL -a -d $DATABASENAME -c "GRANT SELECT ON TABLE $table TO $USERNAME;"
done
# Nombre de connections autorisées
$PSQL -a -d $DATABASENAME -c "ALTER USER $USERNAME CONNECTION LIMIT $MAXCONNECTIONS;"essaye avec
su postgres -c "/usr/lib/postgresql/8.3/bin/pg_dump -U user -v db | bzip2 -c > /data/backup/db.sql.dump.bz2"
avec le path de ta version de pg vers pg_dump, pas sur que les environnements soient chargés dans cron.
C'est mieux également je pense de l'exécuter en tant que user postgres.
Merci je regarde ça attentivement. Pourquoi est-ce ennuyeux de passer par une vue ? le filtre sur le schema rend les bonnes tables. Sympa le coup du -At ça va m'éviter un paquet de filtres.
J'ai encore du mal avec le langage , quand vous écrivez
from pg_class c
c devient un alias de pg_class ?
ok merci, vu, faut le faire à la mano...
voici donc un script bash qui donne des droits de SELECT à un user pour de multiples tables d'un schéma dans mabase
#!/bin/bash
# update des droits du user anonyme sur le schema mon_shema de mabase
for table in `echo "SELECT relname FROM pg_stat_all_tables WHERE schemaname='mon_shema';" | psql mabase | grep -v "pg_" | grep "^ "`;
do
echo "GRANT SELECT ON TABLE mon_shema.$table TO anonyme;"
echo "GRANT SELECT ON TABLE mon_shema.$table TO anonyme;" | psql mabase
done
# REVOKE
#for table in `echo "SELECT relname FROM pg_stat_all_tables WHERE schemaname='mon_shema';" | psql mabases | grep -v "pg_" | grep "^ "`;
#do
# echo "REVOKE ALL PRIVILEGES ON mon_shema.$table FROM anonyme CASCADE;"
# echo "REVOKE ALL PRIVILEGES ON mon_shema.$table FROM anonyme CASCADE;" | psql mabase
#done
Bonjour,
J'ai installé pg sur un serveur spatialisé par postgis. Tout fonctionne très bien, le serveur rend plusieurs milliers d'objets vectoriels à distance de manière très fluide, c'est génial.
Maintenant je souhaite ouvrir le service au public, c'est là que je bloque, mes connaissances en administration de droits étant nulles.
Ce que je voudrais : créer un utilisateur "anonyme" ayant :
- les droits select et connect sur la base qui s'appelle "ressources_publiques"
- limiter le nombre de connexions simultanées à 10 pour ce role
- mettre fin à la connexion après deux heures d'innactivité pour ce user (est-ce possible ?)
Mais je n'y arrive pas ...
avec pgadmin j'ai crée un role de connexion "anonyme" ça c bon, je peux me connecter à la base, mais je ne vois rien...
j'ai essayé
GRANT SELECT ON DATABASE ressources_publiques TO anonyme
GRANT SELECT ON DATABASE ressources_publiques TO GROUP anonyme
dans psql en tant que user postgres mais ça ne fonctionne pas.
A titre d'information, j'ai deux bases sur le serveur :
la base postgres (celle là à priori le user anonyme n'a pas à y toucher)
la base ressources_publiques
cette dernière contient deux shémas :
- irennes (qui contient les tables georeferencées)
- public (qui contient les fonctions de spatialisation comme le calcul de surface sur les objets etc...)
Je pense que mon pg_hba.conf est bon, j'ai tout ouvert pour tous les users depuis l'ip du poste à partir duquel je me connecte. j'a pas d'erreurs de ce coté là.
Merci de l'aide que vous pouvez m'apporter.
peyo
(pg 8.3.12 sous debian lenny)
Réponse un peu tardive de ma part : je ne suis pas arrivé à faire lancer le serveur postgres par un user normal. J'ai donc modifié mon boot et j'utilise ce subterfuge dans un script d'init :
su postgres -c "/usr/lib/postgresql/8.3/bin/pg_ctl -D /mnt/datas/sigdb start"
en root ça passe.
voilou
peyo.
Bonjour,
voici ma question :
Quelles configs doit on apporter à un systeme debian pour qu'un user normal, peyo par exemple, puisse lancer le serveur postgres ?
Doit on passer par les groupes ? paramétrer sudo ?
Le contexte :
J'utilise Quantum GIS interfacé avec postgres via posgis.
Les données de postgres sont stockées sur une partition cryptée avec cyptsetup et les modules du noyau rellatifs sur de l'ext3. ça fonctionne bien, j'ai pu créer le repository de datas de postgres sur la partition cryptée. Le serveur peut demarrer. Je le vois avec pgadmin. Il faut à quantumgis 4-5 secondes pour afficher 250.000 objets vectoriels dans une vue. C'est très satisfaisant en terme de rapidité pour un portable qui a 5 ans.
Mon probleme c'est que c'est le user peyo qui monte la partition apres s'etre log. postgres ne doit donc pas démarrer avant que la partition cryptée ne soit montée. Donc pas au boot.
Je souhaite pouvoir lancer le serveur postgres à partir d'un commande dont le user 'peyo' aurait les droits.
J'ai rajouté peyo au groupe postgres, marche pas
j'ai utilisé sudo pour pouvoir faire :
sudo /usr/lib/postgresql/8.3/bin/pg_ctl -D /mnt/datas/sigdb start
marche pas, la commande se lance mais après, le user n' a pas les droits sur les reps de /mnt/datas/sigdb/* qui appartiennent tous au user 'postgres'. Il peut pas créer d'id de session ...
Vous avez une idée ?
Pages : 1