Обсуждение: pg_hba behavior

Поиск
Список
Период
Сортировка

pg_hba behavior

От
"David Parker"
Дата:
We ran into a problem with pg_hba processing recently when we upgraded
from 7.3.2 to 7.4.5. We use postgres as part of a network appliance that
runs on Solaris 9/intel boxes. 7.4.5 runs fine in our development
environment, but when we deploy it to a production box, we get a
"missing or erroneous pg_hba.conf file" error.

The error in the log is
   "invalid entry in pg_hba.conf file at line 60, token 255.255.255.255"
which corresponds to the default line included with the pg_hba.conf that
gets built:
    host    all         all         127.0.0.1         255.255.255.255
trust

I traced this to hba.c, and it looks like the main diff in this area
between 7.3.2 and 7.4.5 is that the call to getaddrinfo() has been
added. We wrote a quick test program to just call getaddrinfo() passing
it 255.255.255.255, and ran it on our dev and production platforms. On
the dev platform it returns 0, but on our production platform it returns
EAI_NONAME.

The big difference in the platforms is that DNS is not enabled on the
production box - everything is resolved through etc/hosts. I assume this
is the root of the problem.

I realize that, having traced it to getaddrinfo(), this is not *really*
a postgres issue, but I wonder if anybody has run into this before, and
if so what the solution is. It seems that a value of 0.0.0.0 works, but
I want to understand what's going on before I start whacking away at the
pg_hba.conf (or the etc/hosts, for that matter).


-  DAP
======================================================
David Parker    Tazz Networks    (401) 709-5130


Re: pg_hba behavior

От
Bruce Momjian
Дата:
Yes, try 127.0.0.1/32 and remove the netmask.  We supported that in 7.4
and there is some Solaris bug that is triggered if you don't do that.

This is the default in 8.0.

---------------------------------------------------------------------------

David Parker wrote:
> We ran into a problem with pg_hba processing recently when we upgraded
> from 7.3.2 to 7.4.5. We use postgres as part of a network appliance that
> runs on Solaris 9/intel boxes. 7.4.5 runs fine in our development
> environment, but when we deploy it to a production box, we get a
> "missing or erroneous pg_hba.conf file" error.
>
> The error in the log is
>    "invalid entry in pg_hba.conf file at line 60, token 255.255.255.255"
> which corresponds to the default line included with the pg_hba.conf that
> gets built:
>     host    all         all         127.0.0.1         255.255.255.255
> trust
>
> I traced this to hba.c, and it looks like the main diff in this area
> between 7.3.2 and 7.4.5 is that the call to getaddrinfo() has been
> added. We wrote a quick test program to just call getaddrinfo() passing
> it 255.255.255.255, and ran it on our dev and production platforms. On
> the dev platform it returns 0, but on our production platform it returns
> EAI_NONAME.
>
> The big difference in the platforms is that DNS is not enabled on the
> production box - everything is resolved through etc/hosts. I assume this
> is the root of the problem.
>
> I realize that, having traced it to getaddrinfo(), this is not *really*
> a postgres issue, but I wonder if anybody has run into this before, and
> if so what the solution is. It seems that a value of 0.0.0.0 works, but
> I want to understand what's going on before I start whacking away at the
> pg_hba.conf (or the etc/hosts, for that matter).
>
>
> -  DAP
> ======================================================
> David Parker    Tazz Networks    (401) 709-5130
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073