Re: Connecting to postgresql with pdadmin III - sucess !!!

From: "David M(dot) Gullever" <david(dot)gullever(at)web(dot)de>
To: <pgadmin-support(at)postgresql(dot)org>
Subject: Re: Connecting to postgresql with pdadmin III - sucess !!!
Date: 2012-01-19 18:58:49
Message-ID: 20120119195051.9CAC52CD88@smtp.orange.ug
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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-based authentication - 287
19.2.4.1. Ident Authentication over TCP/IP - 287
19.2.4.2. Ident Authentication over 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

In response to

Responses

Browse pgadmin-support by date

  From Date Subject
Next Message Raymond O'Donnell 2012-01-19 19:42:12 Re: Connecting to postgresql with pdadmin III - sucess !!!
Previous Message Raymond O'Donnell 2012-01-19 14:40:01 Re: Connecting to postgresql with pdadmin III