Fwd: posgresql 7.2.1 & pg_hba.conf
---------- Forwarded message ----------
From: philippe L <ptilou@gmail.com>
Date: Fri, 6 Aug 2004 10:09:23 +0200
Subject: Re: posgresql 7.2.1 & pg_hba.conf
To: "J.Pierre Pourrez" <jpourrez.antipourriel@free.fr>
Bonjour,
On Fri, 6 Aug 2004 00:39:45 +0200, J.Pierre Pourrez
<jpourrez.antipourriel@free.fr> wrote:
> Le 05/08/04 ? 23:25, philippe L écrivait:
>
> > Je veux pas de PHP, je veux le client ODBC , j'ai pas encore r?ussi a
> > cr?er une BDD, :(
>
> Bon on s'occupera de ton client odbc plus tard.
Je suis d'accord
>
> Pour vÃrifier que ton serveur tourne, on fait un petit coup de "ps"
> bazooka:~# ps ax | grep postgres
> 20404 pts/0 S 0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data
> 20409 pts/0 S 0:00 postgres: stats buffer process
> 20410 pts/0 S 0:00 postgres: stats collector process
>
Il tourne et j'ai bien ses trois lignes !
> On suppose que c'est ok sinon tu montres ton fichier de config.
J'ai joint au courrier la mouture de ce matin qui ne tourne pas, et
j'ai essayer toutes vos proposition , qui renvoi l'erreur du premier
post .
>
> Pour créer unebase Postgres, il faut être un peu plus "ioux" qu'un utilisateur MySQL.
Ok , j'ai envie se qui a de mieux quitte a bruler quelque neurones de
plus (pas trop j'en ai pas beaucoup ;-))
>
[...]
> Si tu as Apache et PHP sur ta machine, tu peux installer phppgadmin.
> Faudra quand mÃme prendre le temps de lire la doc de PostgreSQL. C'est
> un peu fastidieux mais il y a bcp d'infos intÃressantes.
C'est parceque c'est inéressant que je les choisis, je me suis déjà
tapper un pavé sur *racle probleme c'est pas libre et il faut des
machines puissantes
>
> Quel est l'intÃret d'ODBC ? il y a du Windows dans le coin
Oui un W98, (désolé ) Se, que je veux faire, j'ai des fichier de
commande numérique, j'ai 6 donné qui ne bouge pas et j'ai une 7 eme
donnée qui change au cas par cas, qui pourrai avoir un max de 256
colonnes .
j'ai récupérer une imprimente virtuelle, je voudrais que chaque
fichier représente une fiche dans la BDD, avec deux table !
La deuxieme table etant pour la donnée variable, pour plus tard mais
j'y pense déjà, comment reformater le fichier *.prn pour automatiser
le traitement (j'ai penser à perl ou/et python )!
merci de votre aide
Philippe
#
# PostgreSQL HOST-BASED ACCESS (HBA) CONTROL FILE
#
#
# This file controls:
# o which hosts are allowed to connect
# o how users are authenticated on each host
# o databases accessible by each host
#
# It is read on postmaster startup and when the postmaster receives a SIGHUP.
# If you edit the file on a running system, you have to SIGHUP the postmaster
# for the changes to take effect.
#
# Each line is a new record. Records cannot be continued across multiple
# lines. Comments begin with # and continue to the end of the line.
# Blank lines are ignored. A record consists of tokens separated by
# multiple spaces or tabs.
#
# Each record specifies the authentication method to be used for connections
# of a certain type that match a certain set of IP addresses (if relevant
# for the connection type) and a certain database or databases. The
# postmaster finds the first record that matches the connection type,
# client address, and database name, and uses that record to perform client
# authentication. If no record matches, the connection is rejected.
#
# The first token of a record indicates its type. The remainder of the
# record is interpreted based on its type.
#
# Record Types
# ============
#
# There are three types of records:
# o host
# o hostssl
# o local
#
# host
# ----
#
# This record identifies networked hosts that are permitted to connect
# via IP connections.
#
# Format:
#
# host DBNAME IP_ADDRESS ADDRESS_MASK AUTH_TYPE [AUTH_ARGUMENT]
#
# DBNAME can be:
# o the name of a PostgreSQL database
# o "all" to indicate all databases
# o "sameuser" to allow access only to databases with the same
# name as the connecting user
#
# The superuser needs access to the 'template1' database because it is used
# by a variety of PostgreSQL utility commands.
#
# IP_ADDRESS and ADDRESS_MASK are standard dotted decimal IP address and
# mask values. IP addresses can only be specified numerically, not as
# domain or host names.
#
# AUTH_TYPE and AUTH_ARGUMENT are described below.
#
#
# hostssl
# -------
#
# The format of this record is identical to "host".
#
# This record identifies a set of network hosts that are permitted to
# connect to databases over secure SSL IP connections. Note that a "host"
# record will also allow SSL connections. "hostssl" matches *only*
# SSL-secured connections.
#
# This keyword is only available if the server was compiled with SSL
# support enabled.
#
#
# local
# -----
#
# This record identifies the authentication to use when connecting to
# the server via a local UNIX domain socket. UNIX-socket connections are
# allowed only if this record type appears.
#
# Format:
# local DBNAME AUTH_TYPE [AUTH_ARGUMENT]
#
# This format is identical to the "host" record type except the IP_ADDRESS
# and ADDRESS_MASK fields are omitted.
#
#
#
# Authentication Types (AUTH_TYPE)
# ================================
#
# AUTH_TYPE indicates the method used to authenticate users. The username
# is specified in the connection request. A different AUTH_TYPE can be
# specified for each record in the file.
#
# trust: No authentication is done. Any valid username is accepted,
# including the PostgreSQL superuser. This option should
# be used only for hosts where all users are trusted.
#
# password: Authentication is done by matching a password supplied
# in clear by the host. If no AUTH_ARGUMENT is used, the
# password is compared with the user's entry in the
# pg_shadow table.
#
# If AUTH_ARGUMENT is specified, the username is looked up
# in that file in the $PGDATA directory. If the username
# is found but there is no password, the password is looked
# up in pg_shadow. If a password exists in the file, it is
# used instead. These secondary files allow fine-grained
# control over who can access which databases and whether
# a non-default password is required. The same file can be
# used in multiple records for easier administration.
# Password files can be maintained with the pg_passwd(1)
# utility. Remember, these passwords override pg_shadow
# passwords.
#
# md5: Same as "password", but the password is encrypted while
# being sent over the network. This method is preferable to
# "password" except for pre-7.2 clients that don't support it.
# NOTE: md5 can use usernames stored in secondary password
# files but ignores passwords stored there. The pg_shadow
# password will always be used.
#
# crypt: Same as "md5", but uses crypt for pre-7.2 clients. You can
# not store encrypted passwords in pg_shadow if you use this
# method.
#
# ident: For TCP/IP connections, authentication is done by contacting
# the ident server on the client host. Remember, this is
# only as secure as the client machine. On machines that
# support unix-domain socket credentials (currently Linux,
# FreeBSD, NetBSD, and BSD/OS), this method also works for
# "local" connections.
#
# AUTH_ARGUMENT is required: it determines how to map
# remote user names to Postgres user names. The
# AUTH_ARGUMENT is a map name found in the
# $PGDATA/pg_ident.conf file. The connection is accepted
# if that file contains an entry for this map name with
# the ident-supplied username and the requested Postgres
# username. The special map name "sameuser" indicates an
# implied map (not in pg_ident.conf) that maps each ident
# username to the identical PostgreSQL username.
#
# krb4: Kerberos V4 authentication is used. Allowed only for
# TCP/IP connections, not for local UNIX-domain sockets.
#
# krb5: Kerberos V5 authentication is used. Allowed only for
# TCP/IP connections, not for local UNIX-domain sockets.
#
# pam: Authentication is passed off to PAM (PostgreSQL must be
# configured --with-pam), using the default service name
# "postgresql" - you can specify your own service name, by
# setting AUTH_ARGUMENT to the desired service name.
#
# reject: Reject the connection. This is used to reject certain hosts
# that are part of a network specified later in the file.
# To be effective, "reject" must appear before the later
# entries.
#
#
#
# Examples
# ========
#
#
# Allow any user on the local system to connect to any database under any
# username using Unix-domain sockets (the default for local connections):
#TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
local all 127.0.0.1 255.255.255.0 trust all
#postgres all 127.0.0.1 255.0.0.0 trust
host all 127.0.0.1 255.0.0.0 trust all
localhost all trust all
#
# The same using local loopback IP connections:
# TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
# host all 127.0.0.1 255.0.0.0 trust
#
# Allow any user from any host with IP address 192.168.93.x to
# connect to database "template1" as the same username that ident reports
# for the connection (typically his Unix username):
#
# TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
# host template1 192.168.93.0 255.255.255.0 ident sameuser
#
# Allow a user from host 192.168.12.10 to connect to database "template1"
# if the user's password in pg_shadow is correctly supplied:
#
# TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
# host template1 192.168.12.10 255.255.255.255 md5
#
# In the absence of preceding "host" lines, these two lines will reject
# all connection from 192.168.54.1 (since that entry will be matched
# first), but allow Kerberos V5-validated connections from anywhere else
# on the Internet. The zero mask means that no bits of the host IP address
# are considered, so it matches any host:
#
#
# TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
# host all 192.168.54.1 255.255.255.255 reject
# host all 0.0.0.0 0.0.0.0 krb5
#
# Allow users from 192.168.x.x hosts to connect to any database if they
# pass the ident check. For example, if ident says the user is "james" and
# he requests to connect as PostgreSQL user "guest", the connection is
# allowed if there is an entry in $PGDATA/pg_ident.conf with map name
# "phoenix" that says "james" is allowed to connect as "guest":
#
# TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
# host all 192.168.0.0 255.255.0.0 ident phoenix
#
# If these are the only two lines for local connections, they will allow
# local users to connect only to their own databases (database named the
# same as the user name), except for administrators who may connect to
# all databases. The file $PGDATA/admins lists the user names who are
# permitted to connect to all databases. Passwords are required in all
# cases. (If you prefer to use ident authorization, an ident map can
# serve a parallel purpose to the password list file used here.)
#
# TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT
# local sameuser md5
# local all md5 admins
#
# See $PGDATA/pg_ident.conf for more information on Ident maps.
#
#
# Put your actual configuration here
# ----------------------------------
# This default configuration allows any local user to connect as himself
# without a password, either through a Unix socket or through TCP/IP; users
# on other machines are denied access.
#local all all 127.0.0.1 255.0.0.0 trust
#host all all 127.0.0.1 255.0.0.0 trust
#host all 0.0.0.0 0.0.0.0 reject
# If you want to allow non-local connections, you will need to change 'reject'
# to 'crypt' or some other suitable authentication method. (Debian postgresql
# is not built with Kerberos authentication enabled.)
# To allow TCP/IP access, even from localhost, the postmaster must also be
# started with the -i option or the option TCPIP_SOCKET must be set in
# /etc/postgresql/postgresql.conf.
Reply to: