---------- Forwarded message ---------- From: philippe L <[EMAIL PROTECTED]> Date: Fri, 6 Aug 2004 10:09:23 +0200 Subject: Re: posgresql 7.2.1 & pg_hba.conf To: "J.Pierre Pourrez" <[EMAIL PROTECTED]>
Bonjour, On Fri, 6 Aug 2004 00:39:45 +0200, J.Pierre Pourrez <[EMAIL PROTECTED]> 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.
