Re: Connecting to postgresql with pdadmin III - sucess !!! - Mailing list pgadmin-support
From | David M. Gullever |
---|---|
Subject | Re: Connecting to postgresql with pdadmin III - sucess !!! |
Date | |
Msg-id | 20120119195051.9CAC52CD88@smtp.orange.ug Whole thread Raw |
In response to | Re: Connecting to postgresql with pdadmin III (Dave Page <dpage@pgadmin.org>) |
Responses |
Re: Connecting to postgresql with pdadmin III -
sucess !!!
|
List | pgadmin-support |
Thanks Dave for the reply, Sorry you must think I'm a 24 Carat Moron but since there is no documentation, this is actually becoming interesting - especially since thousands of users before me have started-up with pdadmin apparently without problems. But my thoughts at the moment are as follows... 1. If at the outset I'm simply creating a server (just a name) for my own use in which to put databases at a later date, then this server has initially no relationship with any databases anywhere. That comes later !!! 2. So why the password problems ??? Again the question - is a password mandatory for a "newly created" server. No the password must relate to the user (in my case "postgres") and not the server. 3. But I am then asked for a HOST. So this "server" can only relate to a specific machine and a specific user but NOT a specific postmaster (various versions i.e. various postmasters can run on a single machine at any time so indicating the HOST is NOT unique ???). AND NONE OF THIS IS IN THE DOCUMENTATION !!! 30 years ago my girlfriend was working at DEC (digital equipment corp.) in Munich, writing documentation and as an ICT Instructor I worked with her on various projects. At the time the motto was to write documentation for "den duemmsten anzunehmenden Benutzer" (translated - the thickest user one could reasonably assume). DECs documentation was universally acclaimed as being the "industry best" and they saved themselves a fortune on Telephone Helpdesk services - there was no email at the time. Of course you can never defend yourself from users that think that RTFM doesn't apply to them - but then I don't see myself as that kind of user. On the contrary - being only of average intelligence I rely on good documentation. I wonder how much the flow of mailinglist correspondence could be reduced (thereby reducing the irritation between mailinglist members) if one were to apply DECs approach to documentation to the open source world. I have offered my services but no-one has taken me up on the offer. In any case if all of this were in the documentation. Then I wouldn't be getting on everyone's nerves - incl. my own. To come back to your hint... Because you specified "localhost", pgAdmin is using a tcp/ip connection. psql probably defaulted to a Unix socket, which is typically setup in Postgres to use ident authentication by default. If you replace 'localhost' with the directory containing the Unix socket (typically '/tmp', but it may be different on Debian), then it too should authenticate using ident. Alternatively, modify pg_hba.conf to allow "trust" authentication from localhost, but that's a potential security risk. I am crrently reading through postgres-8.0-A4.pdf 19. Client - 281 19.1. The pg_hba.conf - 281 19.2. Authentication methods - 285 19.2.1. Trust authentication- 285 19.2.2. Password authentication - 286 19.2.3. Kerberos authentication - 286 19.2.4. Ident-basedauthentication - 287 19.2.4.1. Ident Authentication over TCP/IP - 287 19.2.4.2. Ident Authenticationover Local Sockets - 288 19.2.4.3. Ident Maps - 288 The following paragraph nailed down the problem. On your assumption that the default was UNIX sockets, I changed the first line from # Database administrative login by UNIX sockets local all postgres ident sameuser to local all postgres trust And the little bugger did what it was supposed to do. Since the pg_hba.conf records are examined sequentially for each connection attempt, the order of the records is significant. Typically, earlier records will have tight connection match parameters and weaker authentication methods, while later records will have looser match parameters and stronger authentication methods. For example, one might wish to use trust Authentication for local TCP/IP connections but require a password for remote TCP/IP connections. In this case a record specifying trust authentication for connections from 127.0.0.1 would appear before a record specifying password authentication for a wider range of allowed client IP addresses. /tmp offers no idication as to where the default connection method is defined and strangely the pg_ident.conf file is empty Thanks again Dave Regards from sunny Uganda Dragonfish
pgadmin-support by date: