Thread: problem connecting from another host
Running 7.1.2 on Debian Linux/potato (Intel): I'm trying to connect to the
Postgresql database on machine P from machine A. I can, of course, use the
'fpm' database just fine from machine P. TCPIP has been turned on, along
with debugging. The error log shows:
No pg_hba.conf entry for host abc.de.fg.hij, user fpm, database fpm
while in the pg_hba.conf I have an entry:
host fpm abc.de.fg.hij 255.255.255.255 trust
(Initially it wasn't "trust", but first I want to get *some* connection).
There's probably something really stupid going on here, but I haven't yet
figured it out from the old mailing list items, on-line doc's, or Bruce's
book. Could someone please relieve me of another bit of ignorance?
-frank
Frank Miles <fpm@u.washington.edu> writes:
> The error log shows:
> No pg_hba.conf entry for host abc.de.fg.hij, user fpm, database fpm
> while in the pg_hba.conf I have an entry:
> host fpm abc.de.fg.hij 255.255.255.255 trust
> (Initially it wasn't "trust", but first I want to get *some* connection).
That looks fine to me, assuming that "abc.de.fg.hij" actually stands for
the numeric IP (*not* DNS name) of the client machine.
Sometimes people are confused about what IP address they're really
connecting from, if they are running any sort of virtual IP or
multi-interface setup. Might wanna double check it. However, the
error message should show the source IP, so you probably would have
noticed already if that were it.
If you are looking only at the error message returned to the client, try
looking in the postmaster log as well. Sometimes there's extra info
written to the log.
regards, tom lane
On Wed, 13 Jun 2001, Tom Lane wrote:
> Frank Miles <fpm@u.washington.edu> writes:
> > The error log shows:
>
> > No pg_hba.conf entry for host abc.de.fg.hij, user fpm, database fpm
>
> > while in the pg_hba.conf I have an entry:
>
> > host fpm abc.de.fg.hij 255.255.255.255 trust
>
> > (Initially it wasn't "trust", but first I want to get *some* connection).
>
> That looks fine to me, assuming that "abc.de.fg.hij" actually stands for
> the numeric IP (*not* DNS name) of the client machine.
Yes, it's the numerical IP#. It became clear pretty rapidly that the
DNS string wasn't working at all.
> Sometimes people are confused about what IP address they're really
> connecting from, if they are running any sort of virtual IP or
> multi-interface setup. Might wanna double check it. However, the
> error message should show the source IP, so you probably would have
> noticed already if that were it.
That's not the problem. Both machines are properly configured with static
IP's. No ipmasq or NAT. I've also done tcpdumps that confirm the two
systems' trying to establish a connection.
> If you are looking only at the error message returned to the client, try
> looking in the postmaster log as well. Sometimes there's extra info
> written to the log.
The log message shown (sorry for not being clear about it) _is_ from the
database server system's /var/log/postgresql.log .
The only thing I can imagine might be the problem is that client system
doesn't have postgres loaded. I'm trying to access the server via
Python/PyGreSQL. Actually I'm trying to enable access for some Win9x
based systems, again via Python/PyGreSQL. The error message certainly
doesn't make it seem like this should be a problem, but error messages
aren't always correct in their assessment.
I'm mystified. Any further thoughts would be appreciated.
-frank
Frank Miles <fpm@u.washington.edu> writes:
> The only thing I can imagine might be the problem is that client system
> doesn't have postgres loaded.
You don't need the server loaded, only the client libraries. If you
are getting as far as to contact the server, then AFAIK your client
libraries are present and working.
> I'm mystified.
Ditto. If this isn't a postmaster bug, at the very least it's an
inadequate log entry.
It's time to roll out the heavy artillery: I think the next step is to
trace through the postmaster with a debugger and see where and why it's
refusing the connection. Do you want to try that? If not, I'd be
willing to help if you'll grant me access to the server system.
regards, tom lane
On Thu, 14 Jun 2001, Tom Lane wrote:
> Frank Miles <fpm@u.washington.edu> writes:
> > The only thing I can imagine might be the problem is that client system
> > doesn't have postgres loaded.
>
> You don't need the server loaded, only the client libraries. If you
> are getting as far as to contact the server, then AFAIK your client
> libraries are present and working.
>
> > I'm mystified.
>
> Ditto. If this isn't a postmaster bug, at the very least it's an
> inadequate log entry.
>
> It's time to roll out the heavy artillery: I think the next step is to
> trace through the postmaster with a debugger and see where and why it's
> refusing the connection. Do you want to try that? If not, I'd be
> willing to help if you'll grant me access to the server system.
>
> regards, tom lane
The thought suddenly has occurred to me -- the client system that I'm
using *isn't* missing postgresql. It's got an old version on it!
*Really* old -- perhaps predating 6.5.x. Oooppss. Client libraries, huh?
Sounds like it's time to clean that out, replace with new client stuff.
It's weird, though -- a Win9x machine I was initially trying this on
(Python/PyGreSQL again) caused the identical error message to occur.
-frank
Frank Miles <fpm@u.washington.edu> writes:
> The thought suddenly has occurred to me -- the client system that I'm
> using *isn't* missing postgresql. It's got an old version on it!
> *Really* old -- perhaps predating 6.5.x. Oooppss. Client libraries, huh?
> Sounds like it's time to clean that out, replace with new client stuff.
AFAIK the connection protocol should be compatible back to well before
6.3 (which is when I got involved with PG; before that, deponent sayeth
not).
I'd say go for debugging what you have.
regards, tom lane
On Thu, 14 Jun 2001, Tom Lane wrote:
> Frank Miles <fpm@u.washington.edu> writes:
> > The thought suddenly has occurred to me -- the client system that I'm
> > using *isn't* missing postgresql. It's got an old version on it!
> > *Really* old -- perhaps predating 6.5.x. Oooppss. Client libraries, huh?
> > Sounds like it's time to clean that out, replace with new client stuff.
>
> AFAIK the connection protocol should be compatible back to well before
> 6.3 (which is when I got involved with PG; before that, deponent sayeth
> not).
>
> I'd say go for debugging what you have.
Mystery solved. As originally expected, something *stupid*. It turns
out that postgres was reading the pg_hba.conf in /opt/pgsql/data/; I
was editing (and expecting postgres to read) the file in /etc/postgresql.
This confusion is probably due to running a formerly pure Debian system,
but switching some time ago to compiling directly from the Postgresql
sources to avoid having to use the unstable branch of Debian.
Thanks for your help.
-frank
Frank Miles <fpm@u.washington.edu> writes:
> Mystery solved. As originally expected, something *stupid*. It turns
> out that postgres was reading the pg_hba.conf in /opt/pgsql/data/; I
> was editing (and expecting postgres to read) the file in /etc/postgresql.
Ouch. Now that I think about it, you're not the first person to make
this type of error. Seems like it might be a good idea if at
sufficiently high -d levels, the postmaster would spit out to its log
every line read from the config file(s). That would give some way of
detecting that the Wrong Thing is happening. Comments? Does anyone
have a better idea?
regards, tom lane
On Thu, 14 Jun 2001, Tom Lane wrote:
> Frank Miles <fpm@u.washington.edu> writes:
> > Mystery solved. As originally expected, something *stupid*. It turns
> > out that postgres was reading the pg_hba.conf in /opt/pgsql/data/; I
> > was editing (and expecting postgres to read) the file in /etc/postgresql.
>
> Ouch. Now that I think about it, you're not the first person to make
> this type of error. Seems like it might be a good idea if at
> sufficiently high -d levels, the postmaster would spit out to its log
> every line read from the config file(s). That would give some way of
> detecting that the Wrong Thing is happening. Comments? Does anyone
> have a better idea?
As the one just bitten, it sounds great to me. Filenames (including full
path) and relevant environment variable values would be great, too.
-frank
How about it becomes part of 'pg_ctl status'? At the moment it doesn't seem to provide much information given that peopleset most parameters in the conf file(s). It would be nice to see more than just the PID and the commandline paramsthere (eg I don't have any :-). Perhaps its off topic for pg_hba.conf but it would be nice for postgresql.conf info. My 2 cents. cheers, thalis On Thu, 14 Jun 2001, Tom Lane wrote: > Frank Miles <fpm@u.washington.edu> writes: > > Mystery solved. As originally expected, something *stupid*. It turns > > out that postgres was reading the pg_hba.conf in /opt/pgsql/data/; I > > was editing (and expecting postgres to read) the file in /etc/postgresql. > > Ouch. Now that I think about it, you're not the first person to make > this type of error. Seems like it might be a good idea if at > sufficiently high -d levels, the postmaster would spit out to its log > every line read from the config file(s). That would give some way of > detecting that the Wrong Thing is happening. Comments? Does anyone > have a better idea? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
"Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> writes:
> How about it becomes part of 'pg_ctl status'?
How would pg_ctl know what files the postmaster is looking at?
Under conditions of messed-up configuration, pg_ctl is likely
to be just as confused as the DBA is :-(. I'd rather have a way
to get the info from the PM itself.
regards, tom lane
On Thu, 14 Jun 2001, Tom Lane wrote: > "Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> writes: > > How about it becomes part of 'pg_ctl status'? > > How would pg_ctl know what files the postmaster is looking at? > Under conditions of messed-up configuration, pg_ctl is likely > to be just as confused as the DBA is :-(. I'd rather have a way > to get the info from the PM itself. > > regards, tom lane The postmaster knows what conf files it is reading, so have it spew this info in DataDir/postmaster.opts which is anywayread by 'pg_ctl status'. I don't have the big picture in my mind as you probably do, but it is a fast way to do it.Just pass it in CreateOptsFile() of postmaster.c? cheers, thalis
"Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> writes:
> On Thu, 14 Jun 2001, Tom Lane wrote:
>> How would pg_ctl know what files the postmaster is looking at?
>> Under conditions of messed-up configuration, pg_ctl is likely
>> to be just as confused as the DBA is :-(. I'd rather have a way
>> to get the info from the PM itself.
> The postmaster knows what conf files it is reading, so have it spew
> this info in DataDir/postmaster.opts which is anyway read by 'pg_ctl
> status'.
This info would be reliable exactly to the extent that pg_ctl is looking
at the right DataDir. Which was precisely the problem Frank had ;-)
regards, tom lane