TCP/IP with 7.4 beta2 broken?

Tommi =?iso-8859-15?q?M=E4kitalo?= <t.maekitalo@epgmbh.de> writes:

psql: FATAL: no pg_hba.conf entry for host "::ffff:127.0.0.1", user
"postgres", database "template1"

What platform is this?

It sounds to me like your system is resolving "localhost" as an IPv6
address ...

regards, tom lane

It's a SuSE Linux 8.2-box with the original 2.4.20-kernel.

I get the same error when setting PGHOST to localhost, the real hostname or
the IP-adress of the box. It has nothing to do with the resolver I think.

Tommi Mäkitalo

Am Montag, 1. September 2003 22:49 schrieb Tom Lane:

Tommi =?iso-8859-15?q?M=E4kitalo?= <t.maekitalo@epgmbh.de> writes:

It's a SuSE Linux 8.2-box with the original 2.4.20-kernel.
I get the same error when setting PGHOST to localhost, the real hostname or
the IP-adress of the box. It has nothing to do with the resolver I think.

Hm. I assume things will work after you uncomment the commented-out
IPv6 entries at the bottom of pg_hba.conf.

regards, tom lane

Hi,

that worked for localhost. For remote connections I added:

host all all ::ffff:192.168.41.0/120 trust

and it worked also (I guessed it - I don't know much about IPv6). Is there any
chance to get it work like 7.3? It is no nice experience for new users.

Tommi Mäkitalo

Am Montag, 1. September 2003 23:24 schrieb Tom Lane:

Tommi Mï¿œkitalo wrote:

Hi,

that worked for localhost. For remote connections I added:

host all all ::ffff:192.168.41.0/120 trust

and it worked also (I guessed it - I don't know much about IPv6). Is there any
chance to get it work like 7.3? It is no nice experience for new users.

This isn't really a pgsql problem, but special about SuSE Linux which
enables IPV6 by default. Maybe there should be a warning somewhere that
a growing number of Linux versions might be IPV6 enabled and thus
pg_pba.conf needs to respect this.

Regards,
Andreas

Tommi =?iso-8859-15?q?M=E4kitalo?= <t.maekitalo@epgmbh.de> writes:

For remote connections I added:
host all all ::ffff:192.168.41.0/120 trust
and it worked also (I guessed it - I don't know much about IPv6). Is
there any chance to get it work like 7.3? It is no nice experience for
new users.

Are you saying it does not work with just 192.168.41.0/24 ? That would
be really unfortunate --- it suggests that your kernel pretends that
IPv4 connections are IPv6.

regards, tom lane

Tom Lane wrote:

Tommi =?iso-8859-15?q?M=E4kitalo?= <t.maekitalo@epgmbh.de> writes:

For remote connections I added:
host all all ::ffff:192.168.41.0/120 trust
and it worked also (I guessed it - I don't know much about IPv6). Is
there any chance to get it work like 7.3? It is no nice experience for
new users.

Are you saying it does not work with just 192.168.41.0/24 ? That would
be really unfortunate --- it suggests that your kernel pretends that
IPv4 connections are IPv6.

Tom,
we discussed this problem some months ago when I started using 7.4 on
SuSE 8.1. Since 7.4 accepts IPV6, the kernel will always deliver IPV6
addresses, that's why I find most IPV6 problems. While this behaviour
might be irritating, it shouldn't be much of a problem if known.

How about silently creating a IPV6 style host internally for every IPV4
pg_hba.conf entry? It won't make any sense to handle a real IPV4 address
different from an IPV4 address converted to IPV6 address space.

Regards,
Andreas

Quick fix is probably to turn IPv6 off in the kernel unless it's needed
- on my RH box that is as simple as removing a line from
/etc/sysconfig/network and rebooting

Kurt Roeckx knows more about this than I do, but I know when I turned
IPv6 on I had to do something similar to what is below - I seem to
recall we had a discussion about this somewhere. I think we (or at
least I) assumed that folks who turned on IPv6 would be able to figure
this stuff out for themselves. If distributions are starting to ship
with it turned on we may have to revisit that.

There seems to be some IPv6 warts, even though it does work.

cheers

andrew

Tom Lane wrote:

Andreas Pflug <pgadmin@pse-consulting.de> writes:

How about silently creating a IPV6 style host internally for every IPV4
pg_hba.conf entry? It won't make any sense to handle a real IPV4 address
different from an IPV4 address converted to IPV6 address space.

Hmm. I could go for that, if it weren't that there seem to be several
different conventions for embedding IPv4 in IPv6. Should we auto-create
pg_hba.conf entries for all of the possibly equivalent addresses? What
if that creates conflicts?

regards, tom lane

Andreas Pflug wrote:

Tommi M?kitalo wrote:

Hi,

that worked for localhost. For remote connections I added:

host all all ::ffff:192.168.41.0/120 trust

and it worked also (I guessed it - I don't know much about IPv6). Is there any
chance to get it work like 7.3? It is no nice experience for new users.

This isn't really a pgsql problem, but special about SuSE Linux which
enables IPV6 by default. Maybe there should be a warning somewhere that
a growing number of Linux versions might be IPV6 enabled and thus
pg_pba.conf needs to respect this.

Ouch --- everything is IPv6. Wow, that is unusual. I assumed that
folks who have OS's that do that will put IPv6 addresses in pg_hba.conf.
I don't see that we should be auto-converting pg_hba.conf to IPv6 if the
kernel thinks everything is IPv6.

-- 
  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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Ouch --- everything is IPv6. Wow, that is unusual. I assumed that
folks who have OS's that do that will put IPv6 addresses in pg_hba.conf.

I think that may be reasonable. What bothers me is that the default
pg_hba.conf will fail to accept localhost connections on such a system.
OTOH older systems will complain if pg_hba.conf contains IPv6 entries.

We may not have much choice but to find a way to configure pg_hba.conf's
localhost entries at initdb time ...

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Ouch --- everything is IPv6. Wow, that is unusual. I assumed that
folks who have OS's that do that will put IPv6 addresses in pg_hba.conf.

I think that may be reasonable. What bothers me is that the default
pg_hba.conf will fail to accept localhost connections on such a system.
OTOH older systems will complain if pg_hba.conf contains IPv6 entries.

We may not have much choice but to find a way to configure pg_hba.conf's
localhost entries at initdb time ...

Can we allow the IPv6 entries to be in pg_hba.conf but ignore them on
non-IPv6 machines, or allow the connection to fail?

-- 
  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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Can we allow the IPv6 entries to be in pg_hba.conf but ignore them on
non-IPv6 machines, or allow the connection to fail?

I don't see a good way yet. The fly in the ointment is that HAVE_IPV6
is set by configure based on the capabilities of userland libraries;
we cannot assume that HAVE_IPV6 means the kernel knows IPv6. But if
we simply suppress failure messages on IPv6 addresses, we are going to
create severe headaches for people who are actually using IPv6.

Ah, the joys of portability :-(

Anyone see a clean solution?

regards, tom lane

Am Dienstag, 2. September 2003 02:30 schrieb Andrew Dunstan:

Quick fix is probably to turn IPv6 off in the kernel unless it's needed
- on my RH box that is as simple as removing a line from
/etc/sysconfig/network and rebooting

Quick fix is to put the right IPv6-adresses into pg_hba.conf, like I did.

The main problem is, that postgresql does not work out of the box.

If it is possible postmaster should do some mapping from IPv4-entries in
pg_hba.conf to IPv6-entries.

Kurt Roeckx knows more about this than I do, but I know when I turned
IPv6 on I had to do something similar to what is below - I seem to
recall we had a discussion about this somewhere. I think we (or at
least I) assumed that folks who turned on IPv6 would be able to figure
this stuff out for themselves. If distributions are starting to ship
with it turned on we may have to revisit that.

I did not switch IPv6 on. It was on after standard installation.

Tommi Mäkitalo

Tom Lane wrote:

Andreas Pflug <pgadmin@pse-consulting.de> writes:

How about silently creating a IPV6 style host internally for every IPV4
pg_hba.conf entry? It won't make any sense to handle a real IPV4 address
different from an IPV4 address converted to IPV6 address space.

Hmm. I could go for that, if it weren't that there seem to be several
different conventions for embedding IPv4 in IPv6. Should we auto-create
pg_hba.conf entries for all of the possibly equivalent addresses?

AFAICS RFC2253 states that an IPV4 node connecting should get the
Address ::ffff:<IPV4addr>, so this should be sufficient.

What if that creates conflicts?

If there's a conflict, it isn't created by this automatic entry, but
revealed because it was already there.
host 192.168.0.0/24
host ::ffff:102.168.0.0/125
This is already a conflict, not getting better or worse if we add
host ::ffff:102.168.0.0/120
as IPV6 duplicate for the first line.

I created a patch to hba.c which uses IPV4 entries as IPV6 entries if
running on a IPV6 system (which is detected from a port coming in as
AF_INET6)

Regards,
Andreas

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Can we allow the IPv6 entries to be in pg_hba.conf but ignore them on
non-IPv6 machines, or allow the connection to fail?

I don't see a good way yet. The fly in the ointment is that HAVE_IPV6
is set by configure based on the capabilities of userland libraries;
we cannot assume that HAVE_IPV6 means the kernel knows IPv6. But if
we simply suppress failure messages on IPv6 addresses, we are going to
create severe headaches for people who are actually using IPv6.

Ah, the joys of portability :-(

Anyone see a clean solution?

How about a 'localhost' keyword which would match the local host
according to whatever ip stack(s) is (are) running? e.g.

localhost all all trust

Then we wouldn't have to play initdb tricks, but we would have to make
postmaster a bit smarter.

Downside is pg_hba.conf seems to be rapidly becoming more complex.

cheers

andrew

Hi,

the patch did not help.

Maybe it would help dumping all pg_hba.conf-etries after generation of
IPv6-adresses.

But there is another problem, which is related. I get a logentry:

LOG: could not bind IPv4 socket: Die Adresse wird bereits verwendet

Sorry - I have errormessages in german - I set LANG to nothing, but it looks
like not at the right place. It says, that the adress is already in use, but
that is not true. Maybe postgres listens at the IPv6-socket first and
therefore the IPv4-socket is also in use.

Tommi Mäkitalo

...

Tommi Maekitalo wrote:

Hi,

the patch did not help.

Strange. Do you get a client side message "hba.conf entry for
::ffff.127.0.0.1 missing"?
On my system the usual 127.0.0.1 255.255.255.255 is correctly converted to
::ffff:127.0.0.1 ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255 and works
fine.
Please check if the code is correctly inserted line 676ff (and you did
make install and restarted, I hope...)

Maybe it would help dumping all pg_hba.conf-etries after generation of
IPv6-adresses.

But there is another problem, which is related. I get a logentry:

LOG: could not bind IPv4 socket: Die Adresse wird bereits verwendet

You can ignore this, I have it too.

Sorry - I have errormessages in german - I set LANG to nothing, but it looks
like not at the right place. It says, that the adress is already in use, but
that is not true. Maybe postgres listens at the IPv6-socket first and
therefore the IPv4-socket is also in use.

Maybe IPV4 shouldn't be tried if an IPV6 socket is already opened, but I
don't know if there are systems that need both sockets to be able to
connect to both clients.

Regards,
Andreas

Hi,

I doublechecked, that the patch applied. And there is a change. It workes for
connections from remote or to the ethernet-address, but not to localhost:

tommi@at31:~ > export PGHOST=localhost
tommi@at31:~ > psql -l
psql: FATAL: no pg_hba.conf entry for host "::1", user "postgres", database
"template1"
tommi@at31:~ > export PGHOST=at31
tommi@at31:~ > psql -l
Liste der Datenbanken
Name | Eigentümer | Kodierung
-----------+------------+-----------
template0 | postgres | SQL_ASCII
template1 | postgres | SQL_ASCII
(2 Zeilen)

tommi@at31:~ >

Tommi Mäkitalo