Hi,

I tried 7.4 beta2 and had difficulties setting up TCP/IP with it. It complains 
about mising pg_hba.conf-entry.

After installing and initdb I edited my postgres.conf to enable tcpip 
(tcpip_socket = true) and added a pg_hba.conf-entry like this:

local   all         all                                             trust
host    all         all         192.168.41.0      255.255.255.0     trust
host    all         all         127.0.0.1         255.255.255.255   trust

192.168.41.0/255.255.255.0 is the net we use.
Next I started postmaster and tried to connect via TCP/IP. From the same host 
I set PGHOST to 127.0.0.1 and PGUSER to postgres and tried a psql -l. I got:

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

It looks like postgres tries some IPv6-adresses and failes.

Same with 7.3.4 works just fine.

Tommi Mäkitalo

Mon, 1 Sep 2003 21:59:17 +0200
Tommi =?iso-8859-15?q?M=E4kitalo?= <t.maekitalo@epgmbh.de>
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

Mon, 01 Sep 2003 16:49:04 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TCP/IP with 7.4 beta2 broken? 
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:
> > 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


Mon, 1 Sep 2003 23:01:25 +0200
Tommi =?iso-8859-15?q?M=E4kitalo?= <t.maekitalo@epgmbh.de>
Re: TCP/IP with 7.4 beta2 broken?
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

Mon, 01 Sep 2003 17:24:16 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TCP/IP with 7.4 beta2 broken? 
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 =?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


Tue, 2 Sep 2003 00:10:20 +0200
Tommi =?iso-8859-15?q?M=E4kitalo?= <t.maekitalo@epgmbh.de>
Re: TCP/IP with 7.4 beta2 broken?
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



Tue, 02 Sep 2003 00:15:51 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: TCP/IP with 7.4 beta2 broken?
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

Mon, 01 Sep 2003 19:59:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TCP/IP with 7.4 beta2 broken? 
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




Tue, 02 Sep 2003 02:21:04 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: TCP/IP with 7.4 beta2 broken?

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:

>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
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Don't 'kill -9' the postmaster
>
>  
>


Mon, 01 Sep 2003 20:30:39 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
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

Mon, 01 Sep 2003 22:27:30 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TCP/IP with 7.4 beta2 broken? 
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

Mon, 1 Sep 2003 23:10:44 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: TCP/IP with 7.4 beta2 broken?
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

Mon, 01 Sep 2003 23:34:48 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TCP/IP with 7.4 beta2 broken? 
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

Mon, 1 Sep 2003 23:56:22 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: TCP/IP with 7.4 beta2 broken?
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

Tue, 02 Sep 2003 00:06:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TCP/IP with 7.4 beta2 broken? 

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

Tue, 2 Sep 2003 08:43:12 +0200
Tommi Maekitalo <t.maekitalo@epgmbh.de>
Re: TCP/IP with 7.4 beta2 broken?
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
Tue, 02 Sep 2003 13:40:45 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: TCP/IP with 7.4 beta2 broken?


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


Tue, 02 Sep 2003 07:43:58 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
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

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



Tue, 2 Sep 2003 15:05:55 +0200
Tommi Maekitalo <t.maekitalo@epgmbh.de>
Re: TCP/IP with 7.4 beta2 broken?
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



Tue, 02 Sep 2003 15:58:01 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: TCP/IP with 7.4 beta2 broken?
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



Tue, 2 Sep 2003 16:16:59 +0200
Tommi Maekitalo <t.maekitalo@epgmbh.de>
Re: TCP/IP with 7.4 beta2 broken?
Tommi Maekitalo wrote:

>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 
>
That's ok.
::1 is a pure IPV6 address, so you need a real IPV6 entry for this (it's 
already prepared in the pg_hba.conf sample).

Regards,
Andreas



Tue, 02 Sep 2003 16:43:30 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: TCP/IP with 7.4 beta2 broken?

*nod* but it would be nicer if all loopback interfaces worked by default 
- hence my localhost suggestion, which would match any of

  127.0.0.1/32
  ::ffff:127.0.0.1/128 and
  ::1/128

cheers

andrew

Andreas Pflug wrote:

> Tommi Maekitalo wrote:
>
>> 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
>
> That's ok.
> ::1 is a pure IPV6 address, so you need a real IPV6 entry for this 
> (it's already prepared in the pg_hba.conf sample).
>
> Regards,
> Andreas
>



Tue, 02 Sep 2003 11:24:15 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
Am Dienstag, 2. September 2003 17:24 schrieb Andrew Dunstan:
> *nod* but it would be nicer if all loopback interfaces worked by default
> - hence my localhost suggestion, which would match any of
>
>   127.0.0.1/32
>
>   ::ffff:127.0.0.1/128 and
>   ::1/128
>
> cheers
>
> andrew
>
...
That sounds good. Is it possible to extend lookup that way?

And yes indeed - setting PGHOST to 127.0.0.1 workes but localhost not.

Wed, 3 Sep 2003 08:03:21 +0200
Tommi Maekitalo <t.maekitalo@epgmbh.de>
Re: TCP/IP with 7.4 beta2 broken?
Tommi Maekitalo wrote:

>>*nod* but it would be nicer if all loopback interfaces worked by default
>>- hence my localhost suggestion, which would match any of
>>
>>  127.0.0.1/32
>>
>>  ::ffff:127.0.0.1/128 and
>>  ::1/128
>>
>>cheers
>>
>>andrew
>>
>>    
>>
>...
>That sounds good. Is it possible to extend lookup that way?
>
I'd feel a bit uncomfortable making ::1/128 from 127.0.0.1/32 because 
it's not converting the same address from one format into another, but a 
completely different address.
Extending "local" to accept all local tcpip addresses would fit better.

Regards,
Andreas


Wed, 03 Sep 2003 12:49:44 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: TCP/IP with 7.4 beta2 broken?
Tommi Maekitalo said:
> Am Dienstag, 2. September 2003 17:24 schrieb Andrew Dunstan:
>> *nod* but it would be nicer if all loopback interfaces worked by
>> default - hence my localhost suggestion, which would match any of
>>
>>   127.0.0.1/32
>>
>>   ::ffff:127.0.0.1/128 and
>>   ::1/128
>>
>> cheers
>>
>> andrew
>>
> ...
> That sounds good. Is it possible to extend lookup that way?
>
> And yes indeed - setting PGHOST to 127.0.0.1 workes but localhost not.
>

It wouldn't be a lookup at all. Perhaps 'localhost' is a bad name,
and 'loopback' would be better. The above would be the only addresses that
would match it, and if IPv6 was not configured in only 127.0.0.1 would
match it.

If people think it's a good idea I can probably have a patch for it in
about 2 days.

cheers

andrew



Wed, 3 Sep 2003 06:51:17 -0400 (EDT)
"Andrew Dunstan" <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
Andreas Pflug said:
> Tommi Maekitalo wrote:
>
>>>*nod* but it would be nicer if all loopback interfaces worked by
>>>default - hence my localhost suggestion, which would match any of
>>>
>>>  127.0.0.1/32
>>>
>>>  ::ffff:127.0.0.1/128 and
>>>  ::1/128
>>>
>>...
>>That sounds good. Is it possible to extend lookup that way?
>>
> I'd feel a bit uncomfortable making ::1/128 from 127.0.0.1/32 because
> it's not converting the same address from one format into another, but
> a  completely different address.
> Extending "local" to accept all local tcpip addresses would fit better.
>

I agree. The only automatic mapping in host* lines should be from
p.q.r.s/n to ::ffff:p.q.r.s/n+96. Loopback interfaces are special and
should be treated separately from the general case, which is what I
propose to do.

cheers

andrew





Wed, 3 Sep 2003 07:11:24 -0400 (EDT)
"Andrew Dunstan" <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
Andrew Dunstan wrote:

>Andreas Pflug said:
>  
>
>>Tommi Maekitalo wrote:
>>
>>    
>>
>>>>*nod* but it would be nicer if all loopback interfaces worked by
>>>>default - hence my localhost suggestion, which would match any of
>>>>
>>>> 127.0.0.1/32
>>>>
>>>> ::ffff:127.0.0.1/128 and
>>>> ::1/128
>>>>
>>>>        
>>>>
>>>...
>>>That sounds good. Is it possible to extend lookup that way?
>>>
>>>      
>>>
>>I'd feel a bit uncomfortable making ::1/128 from 127.0.0.1/32 because
>>it's not converting the same address from one format into another, but
>>a  completely different address.
>>Extending "local" to accept all local tcpip addresses would fit better.
>>
>>    
>>
>
>I agree. The only automatic mapping in host* lines should be from
>p.q.r.s/n to ::ffff:p.q.r.s/n+96. Loopback interfaces are special and
>should be treated separately from the general case, which is what I
>propose to do.
>
This doesn't look consistent to me. Local addresses can be all addresses 
that the host's interfaces are currently configured with, loopback is 
nothing special in this sense. The admin can easily do 'ifconfig' to see 
all addresses configured and enter them into pg_hba.conf, because these 
addresses are obvious.

Regards,
Andreas



Wed, 03 Sep 2003 19:12:56 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: TCP/IP with 7.4 beta2 broken?
On Mon, Sep 01, 2003 at 09:59:17PM +0200, Tommi Mï¿½kitalo wrote:
> 
> psql: FATAL:  no pg_hba.conf entry for host "::ffff:127.0.0.1", user 
> "postgres", database "template1"

This is a Linux system that does not have the IPV6_V6ONLY
setsockopt() option.  Linux only has this option since 2.4.21
(pre3).

This means that an IPv6 socket bound to "::" (all addresses) will
listen for both all IPv4 and IPv6 addresses.
If that option exists, it will only listen to all IPv6 addresses.
If the option doesn't exist, it can't bind to the 0.0.0.0 ipv4
socket, because the IPv6 socket already is bound to it.

So all connections you get are, from the application's point of
view, IPv6 connections.

IPv4 connections on an AF_INET6 socket are called IPv4-mapped
IPv6.  It was something they created to make it easier to port
applications to IPv6, but it only makes things worse.


Kurt


Wed, 3 Sep 2003 19:14:08 +0200
Kurt Roeckx <Q@ping.be>
Re: TCP/IP with 7.4 beta2 broken?
Andreas Pflug wrote:

> Andrew Dunstan wrote:
>
>> Andreas Pflug said:
>>  
>>
>>> Tommi Maekitalo wrote:
>>>
>>>   
>>>
>>>>> *nod* but it would be nicer if all loopback interfaces worked by
>>>>> default - hence my localhost suggestion, which would match any of
>>>>>
>>>>> 127.0.0.1/32
>>>>>
>>>>> ::ffff:127.0.0.1/128 and
>>>>> ::1/128
>>>>>
>>>>>       
>>>>
>>>> ...
>>>> That sounds good. Is it possible to extend lookup that way?
>>>>
>>>>     
>>>
>>> I'd feel a bit uncomfortable making ::1/128 from 127.0.0.1/32 because
>>> it's not converting the same address from one format into another, but
>>> a  completely different address.
>>> Extending "local" to accept all local tcpip addresses would fit better.
>>>
>>>   
>>
>>
>> I agree. The only automatic mapping in host* lines should be from
>> p.q.r.s/n to ::ffff:p.q.r.s/n+96. Loopback interfaces are special and
>> should be treated separately from the general case, which is what I
>> propose to do.
>>
> This doesn't look consistent to me. Local addresses can be all 
> addresses that the host's interfaces are currently configured with, 
> loopback is nothing special in this sense. The admin can easily do 
> 'ifconfig' to see all addresses configured and enter them into 
> pg_hba.conf, because these addresses are obvious.


We currently have this in the default pg_hba.conf file:

  host all all 127.0.0.1 255.255.255.255 trust

The idea was to have something which would perform equivalently on IP4 
only, IP4 over IP6 and pure IP6 connections, without breaking the 
postmaster host in any of them.

It is perfectly true that it could be mangled by the administrator - 
this would save him/her having to do so for the default case. In my 
proposal you would replace this default line with:

  loopback all all trust

It's the fact that it is the default that makes it special. Does that 
make things clearer?

cheers

andrew


Wed, 03 Sep 2003 13:33:45 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
Andrew Dunstan wrote:
> > This doesn't look consistent to me. Local addresses can be all 
> > addresses that the host's interfaces are currently configured with, 
> > loopback is nothing special in this sense. The admin can easily do 
> > 'ifconfig' to see all addresses configured and enter them into 
> > pg_hba.conf, because these addresses are obvious.
> 
> 
> We currently have this in the default pg_hba.conf file:
> 
>   host all all 127.0.0.1 255.255.255.255 trust
> 
> The idea was to have something which would perform equivalently on IP4 
> only, IP4 over IP6 and pure IP6 connections, without breaking the 
> postmaster host in any of them.
> 
> It is perfectly true that it could be mangled by the administrator - 
> this would save him/her having to do so for the default case. In my 
> proposal you would replace this default line with:
> 
>   loopback all all trust
> 
> It's the fact that it is the default that makes it special. Does that 
> make things clearer?

We have avoided doing dns lookups from pg_hba.conf, and hence the use of
127.0.0.1 instead of localhost.  Now that we cache pg_hba.conf, we could
consider allowing hostnames in pg_hba.conf.  Is that a TODO?

As for the IPv6 issue --- how prevalent is this problem.  What OS
versions are affected?  Has the user done something special to enable
this?

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

Wed, 3 Sep 2003 14:16:06 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: TCP/IP with 7.4 beta2 broken?
Bruce Momjian wrote:

>Andrew Dunstan wrote:
>  
>
>>We currently have this in the default pg_hba.conf file:
>>
>>  host all all 127.0.0.1 255.255.255.255 trust
>>
>>The idea was to have something which would perform equivalently on IP4 
>>only, IP4 over IP6 and pure IP6 connections, without breaking the 
>>postmaster host in any of them.
>>
>>It is perfectly true that it could be mangled by the administrator - 
>>this would save him/her having to do so for the default case. In my 
>>proposal you would replace this default line with:
>>
>>  loopback all all trust
>>
>>It's the fact that it is the default that makes it special. Does that 
>>make things clearer?
>>    
>>
>
>We have avoided doing dns lookups from pg_hba.conf, and hence the use of
>127.0.0.1 instead of localhost.  Now that we cache pg_hba.conf, we could
>consider allowing hostnames in pg_hba.conf.  Is that a TODO?
>
>As for the IPv6 issue --- how prevalent is this problem.  What OS
>versions are affected?  Has the user done something special to enable
>this?
>
>  
>
These are orthogonal issues. What I have suggested above would work 
purely at the address level, without any name lookup.

Systems (e.g. SUSE) are shipping with IP6 turned on by default - that's 
how this came up in the first place.

DNS lookups were discussed back in May, but there didn't seem to be a 
nice way to do it in conjunction with netmasks, so I didn't proceed with 
it after I did CIDR masks.

If someone can suggest good semantics and there is demand for it I can 
look at it again (or someone else can).

cheers

andrew



Wed, 03 Sep 2003 14:33:02 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
Bruce Momjian wrote:

>We have avoided doing dns lookups from pg_hba.conf, and hence the use of
>127.0.0.1 instead of localhost.  Now that we cache pg_hba.conf, we could
>consider allowing hostnames in pg_hba.conf.  Is that a TODO?
>
Hm. DNS lookup would make postmaster startup last much longer, to have 
all addresses resolved. Usually installations will have only some 
well-known non-volatile networks configured, So I'd opt to not use DNS.

>
>As for the IPv6 issue --- how prevalent is this problem.  What OS
>versions are affected?  Has the user done something special to enable
>this?
>  
>
I can't remember to have opted for a IPV6 installation, so I believe my 
SuSE 8.1installs IPV6 by default now (and 8.2 too). Then I worked quite 
a while with 7.3 as usual, and was quite surprised about that IPV6 stuff 
when upgrading to 7.4.
This will probably be an issue more and more, when machines get IPV6 
enabled (if by mistake, on purpose or default). The proposed patch will 
handle IPV4 clients as usual.

Regards,
Andreas




Wed, 03 Sep 2003 20:37:01 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: TCP/IP with 7.4 beta2 broken?
Hi,

Am Mittwoch, 3. September 2003 20:16 schrieb Bruce Momjian:
...
>
> As for the IPv6 issue --- how prevalent is this problem.  What OS
> versions are affected?  Has the user done something special to enable
> this?

I have a SuSE 8.2 out of the box. I have done nothing with IPv6. I don't even 
know much about IPv6.

Users expect, that it works just after installation. But after following the 
discussion I think, that it is not so much a problem. I have 127.0.0.1 in my 
pg_hba.conf and when I set PGHOST to 127.0.0.1 it workes. If I set PGHOST to 
localhost, it resolves to ::1, wich don't match my pg_hba.conf-entry. The 
error message is somewhat clear and gives the user a good hint, where to look 
for.

I don't like the idea of doing something special with loopback-interfaces. 
Loopback-interfaces are to test the network and tries to handle everything 
like normal networking.

Is it possible to ignore IPv6-entries in pg_hba.conf on non-IPv6-machines? 
Then we could uncomment IPv6 localhost connections by default. Or uncomment 
these entries just on IPv6-machines. But this needs modification of default 
pg_hba.conf depending on OS.


Tommi
-- 
Dr. Eckhardt + Partner GmbH
http://www.epgmbh.de

Thu, 4 Sep 2003 08:42:53 +0200
Tommi Maekitalo <t.maekitalo@epgmbh.de>
Re: TCP/IP with 7.4 beta2 broken?


Tommi Maekitalo wrote:

>Users expect, that it works just after installation. But after following the 
>discussion I think, that it is not so much a problem. I have 127.0.0.1 in my 
>pg_hba.conf and when I set PGHOST to 127.0.0.1 it workes. If I set PGHOST to 
>localhost, it resolves to ::1, wich don't match my pg_hba.conf-entry. The 
>error message is somewhat clear and gives the user a good hint, where to look 
>for.
>  
>
With the patch I submitted yesterday it would just work out of the box 
and no error message. ISTM the default setting should do just that.

>I don't like the idea of doing something special with loopback-interfaces. 
>Loopback-interfaces are to test the network and tries to handle everything 
>like normal networking.
>  
>
Have a look at the patch: 
http://archives.postgresql.org/pgsql-patches/2003-09/msg00010.php

The only "special" thing it does is in deciding if a connection matches 
the rule. Otherwise it is treated exactly the same as any other network 
connection.

>Is it possible to ignore IPv6-entries in pg_hba.conf on non-IPv6-machines? 
>Then we could uncomment IPv6 localhost connections by default. Or uncomment 
>these entries just on IPv6-machines. But this needs modification of default 
>pg_hba.conf depending on OS.
>  
>

Ignoring entries is probably storing up trouble for yourself in the 
future.  Say I mistype "192.168:1.1" on an IP4 only machine and it is 
silently ignored?

Commenting out / uncommenting entries is problematic. The only sane time 
would be to do it at initdb time, ISTM. But what if IP6 is turned on 
after you run initdb? BOOM no work. With my patch you would keep working 
happily :-)

I'm done arguing about this - I'll leave it up to the committers to 
decide what they want to do and move on to something else.

cheers

andrew


Thu, 04 Sep 2003 08:32:52 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
Tom Lane writes:

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

What is the problem?  Is it that a non-IPv6 enabled postmaster is unable
to identify or parse valid IPv6 address specifications?  In that case,
we need to provide some substitute routines.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 4 Sep 2003 19:18:57 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: TCP/IP with 7.4 beta2 broken? 
Peter Eisentraut <peter_e@gmx.net> writes:
>> 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?

> What is the problem?  Is it that a non-IPv6 enabled postmaster is unable
> to identify or parse valid IPv6 address specifications?  In that case,
> we need to provide some substitute routines.

To what purpose?  I think I prefer Andrew Dunstan's approach of allowing
IPv4 syntax in pg_hba.conf to match appropriate IPv6 connections.

			regards, tom lane

Thu, 04 Sep 2003 13:25:36 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TCP/IP with 7.4 beta2 broken? 
On Thu, Sep 04, 2003 at 07:18:57PM +0200, Peter Eisentraut wrote:
> Tom Lane writes:
> 
> > 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.
> 
> What is the problem?  Is it that a non-IPv6 enabled postmaster is unable
> to identify or parse valid IPv6 address specifications?  In that case,
> we need to provide some substitute routines.

Our replacement getaddrinfo can only read IPv4 addresses.

If we need to make it support IPv6 addresses too, we need to
define our own struct sockaddr_in6 and AF_INET6, and always use
our own version and not the one from the system libs if it has
any.

There probably is no need for our getaddrinfo replacement
function to try to resolve to IPv6 addresses, so it shouldn't be
that hard.


Kurt


Thu, 4 Sep 2003 19:32:11 +0200
Kurt Roeckx <Q@ping.be>
Re: TCP/IP with 7.4 beta2 broken?
Tom Lane writes:

> > What is the problem?  Is it that a non-IPv6 enabled postmaster is unable
> > to identify or parse valid IPv6 address specifications?  In that case,
> > we need to provide some substitute routines.
>
> To what purpose?

So we can put ::1 in the default pg_hba.conf and have it work on
IPv6-enabled hosts by default.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 4 Sep 2003 19:50:38 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: TCP/IP with 7.4 beta2 broken? 
Peter Eisentraut wrote:

>Tom Lane writes:
>
>  
>
>>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.
>>    
>>
>
>What is the problem?  Is it that a non-IPv6 enabled postmaster is unable
>to identify or parse valid IPv6 address specifications?  In that case,
>we need to provide some substitute routines.
>
>  
>
Having parsed it what would it do with it? Surely if IP6 isn't 
configured in then having an IP6 address in pg_hba.conf is an error. 
That's why we commented those lines out in the default pg_hba.conf some 
weeks ago.

If Andreas Pflug's patch (with Kurt's caveat) and my patch are applied, 
then I really think there won't be any more difficulties in this area.

cheers

andrew


Thu, 04 Sep 2003 13:53:29 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> >> 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?
> 
> > What is the problem?  Is it that a non-IPv6 enabled postmaster is unable
> > to identify or parse valid IPv6 address specifications?  In that case,
> > we need to provide some substitute routines.
> 
> To what purpose?  I think I prefer Andrew Dunstan's approach of allowing
> IPv4 syntax in pg_hba.conf to match appropriate IPv6 connections.

I am confused.  Andrew Dunstan's approach added a new 'loopback' line
to pg_hba.conf.

Andreas Pflug had the patch that treated IPv4 as 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

Thu, 4 Sep 2003 14:06:55 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: TCP/IP with 7.4 beta2 broken?
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> To what purpose?  I think I prefer Andrew Dunstan's approach of allowing
>> IPv4 syntax in pg_hba.conf to match appropriate IPv6 connections.

> I am confused.  Andrew Dunstan's approach added a new 'loopback' line
> to pg_hba.conf.
> Andreas Pflug had the patch that treated IPv4 as IPv6.

Ah, my mistake.  The patch from Andreas seems like a reasonable thing to
me.

I'm of two minds about 'loopback' --- it's perhaps logically cleaner
than referring to 127.0.0.1, but do we want another special case?
Also, do we really need it if we add Andreas' patch?

			regards, tom lane

Thu, 04 Sep 2003 14:17:43 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TCP/IP with 7.4 beta2 broken? 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> To what purpose?  I think I prefer Andrew Dunstan's approach of allowing
> >> IPv4 syntax in pg_hba.conf to match appropriate IPv6 connections.
> 
> > I am confused.  Andrew Dunstan's approach added a new 'loopback' line
> > to pg_hba.conf.
> > Andreas Pflug had the patch that treated IPv4 as IPv6.
> 
> Ah, my mistake.  The patch from Andreas seems like a reasonable thing to
> me.
> 
> I'm of two minds about 'loopback' --- it's perhaps logically cleaner
> than referring to 127.0.0.1, but do we want another special case?
> Also, do we really need it if we add Andreas' patch?

I agree we don't need yet another pg_hba.conf keyword, and Andreas'
patch handles all IPv4 addresses, not just localhost.

Let me load up the patch queue today so everyone can see where we are
going.

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

Thu, 4 Sep 2003 14:34:59 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: TCP/IP with 7.4 beta2 broken?
Andrew Dunstan writes:

> Having parsed it what would it do with it?

Nothing.

> Surely if IP6 isn't configured in then having an IP6 address in
> pg_hba.conf is an error.

Arguably, but not surely.

> If Andreas Pflug's patch (with Kurt's caveat) and my patch are applied,
> then I really think there won't be any more difficulties in this area.

Ignoring that I don't like one of the submitted patches, this still won't
get us an pg_hba.conf that works out of the box for sites using IPv6.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 4 Sep 2003 20:53:54 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: TCP/IP with 7.4 beta2 broken?
Bruce Momjian wrote:

>Tom Lane wrote:
>  
>
>>Peter Eisentraut <peter_e@gmx.net> writes:
>>    
>>
>>>>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?
>>>>>          
>>>>>
>>>What is the problem?  Is it that a non-IPv6 enabled postmaster is unable
>>>to identify or parse valid IPv6 address specifications?  In that case,
>>>we need to provide some substitute routines.
>>>      
>>>
>>To what purpose?  I think I prefer Andrew Dunstan's approach of allowing
>>IPv4 syntax in pg_hba.conf to match appropriate IPv6 connections.
>>    
>>
>
>I am confused.  Andrew Dunstan's approach added a new 'loopback' line
>to pg_hba.conf.
>
>Andreas Pflug had the patch that treated IPv4 as IPv6.
>
>  
>

There's a lot of confusion around :-) Let me see if I can disentangle 
some of it.

People seem to want two things:
1. if ip4 is being tunneled over ip6 as it is in most Linux 
distributions, match a corresponding 'host*' line with an ip4 address.
2. enable local connections of whatever flavor by default.

Andreas has addressed item 1. I suggested an approach to item 2. The 
only alternative I can see is to allow ip4-only postmasters to recognize 
and silently drop ip6 'host*' lines. I don't like the idea of silently 
ignoring config lines - it seems dangerous to me. Suggestions of having 
initdb or something similar conditionally set the default pg_hba.conf 
also strike me as impractical and fragile.

What Andreas did and what I did are not mutually exclusive - they could 
live happily together.

(now back to wrestling with embedded functions)

cheers

andrew


Thu, 04 Sep 2003 15:13:08 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
Peter Eisentraut wrote:

>Andrew Dunstan writes:
>
>  
>
>>Having parsed it what would it do with it?
>>    
>>
>
>Nothing.
>
>  
>
>>Surely if IP6 isn't configured in then having an IP6 address in
>>pg_hba.conf is an error.
>>    
>>
>
>Arguably, but not surely.
>
>  
>
>>If Andreas Pflug's patch (with Kurt's caveat) and my patch are applied,
>>then I really think there won't be any more difficulties in this area.
>>    
>>
>
>Ignoring that I don't like one of the submitted patches, this still won't
>get us an pg_hba.conf that works out of the box for sites using IPv6.
>
>  
>
Please explain a scenario that wouldn't work out of the box.

cheers

andrew


Thu, 04 Sep 2003 15:28:43 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
Andrew Dunstan <andrew@dunslane.net> writes:
> There's a lot of confusion around :-) Let me see if I can disentangle 
> some of it.

> People seem to want two things:
> 1. if ip4 is being tunneled over ip6 as it is in most Linux 
> distributions, match a corresponding 'host*' line with an ip4 address.
> 2. enable local connections of whatever flavor by default.

Sounds right to me.

> Andreas has addressed item 1. I suggested an approach to item 2. The 
> only alternative I can see is to allow ip4-only postmasters to recognize 
> and silently drop ip6 'host*' lines. I don't like the idea of silently 
> ignoring config lines - it seems dangerous to me. Suggestions of having 
> initdb or something similar conditionally set the default pg_hba.conf 
> also strike me as impractical and fragile.

Bruce and I were just discussing this on the phone.  It seems we have
two basic approaches to problem #2.  Either we hack the postmaster so
that it will swallow IPv6 addresses in pg_hba.conf even without any real
IPv6 support, or we make the default pg_hba.conf contents different.
Neither of these is real pretty, but I am leaning to the second, because
I agree with your feeling that silently ignoring config lines is a bad
idea.

I do not believe that there's anything fragile about having initdb make
this adjustment.  We can arrange for initdb to be aware of the HAVE_IPV6
compilation flag (its value can be inserted when initdb is made from
initdb.sh, the same way some other configuration items are already
inserted into the script).  As far as I can see, HAVE_IPV6 is exactly
what we want to look at to decide whether to put "::1" into pg_hba.conf.
If we HAVE_IPV6, then the postmaster can parse "::1".  Whether the
kernel has IPv6 enabled doesn't matter --- if not, it would only mean
that the postmaster will never actually see a connection from "::1";
so the pg_hba.conf entry will never be matched.  But it won't hurt
anything.  Conversely, if we don't HAVE_IPV6, we can't parse "::1"
... but we don't need to, even if the kernel has IPv6, because such a
postmaster won't try to listen for AF_INET6 connections.

			regards, tom lane

Thu, 04 Sep 2003 21:51:59 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TCP/IP with 7.4 beta2 broken? 


Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>There's a lot of confusion around :-) Let me see if I can disentangle 
>>some of it.
>>    
>>
>
>  
>
>>People seem to want two things:
>>1. if ip4 is being tunneled over ip6 as it is in most Linux 
>>distributions, match a corresponding 'host*' line with an ip4 address.
>>2. enable local connections of whatever flavor by default.
>>    
>>
>
>Sounds right to me.
>
>  
>
>>Andreas has addressed item 1. I suggested an approach to item 2. The 
>>only alternative I can see is to allow ip4-only postmasters to recognize 
>>and silently drop ip6 'host*' lines. I don't like the idea of silently 
>>ignoring config lines - it seems dangerous to me. Suggestions of having 
>>initdb or something similar conditionally set the default pg_hba.conf 
>>also strike me as impractical and fragile.
>>    
>>
>
>Bruce and I were just discussing this on the phone.  It seems we have
>two basic approaches to problem #2.  Either we hack the postmaster so
>that it will swallow IPv6 addresses in pg_hba.conf even without any real
>IPv6 support, or we make the default pg_hba.conf contents different.
>Neither of these is real pretty, but I am leaning to the second, because
>I agree with your feeling that silently ignoring config lines is a bad
>idea.
>
>I do not believe that there's anything fragile about having initdb make
>this adjustment.  We can arrange for initdb to be aware of the HAVE_IPV6
>compilation flag (its value can be inserted when initdb is made from
>initdb.sh, the same way some other configuration items are already
>inserted into the script).  As far as I can see, HAVE_IPV6 is exactly
>what we want to look at to decide whether to put "::1" into pg_hba.conf.
>If we HAVE_IPV6, then the postmaster can parse "::1".  Whether the
>kernel has IPv6 enabled doesn't matter --- if not, it would only mean
>that the postmaster will never actually see a connection from "::1";
>so the pg_hba.conf entry will never be matched.  But it won't hurt
>anything.  Conversely, if we don't HAVE_IPV6, we can't parse "::1"
>... but we don't need to, even if the kernel has IPv6, because such a
>postmaster won't try to listen for AF_INET6 connections.
>
>  
>
OK, now we are getting somewhere. I see that this would work. It's a bit 
ugly, though - with this plan the sample file in both CVS and the 
installation won't necessarily be what actually get put in place. What 
if some clever installer/administrator deliberately alters their 
installed sample file?

Could we get the configure script to do it instead, since it too should 
know about ip6 capability? (I guess then we'd have 
pg_hba.conf.sample.in). That strikes me as being a lot cleaner.

andrew




Fri, 05 Sep 2003 03:16:54 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
Andrew Dunstan <andrew@dunslane.net> writes:
> OK, now we are getting somewhere. I see that this would work. It's a bit 
> ugly, though - with this plan the sample file in both CVS and the 
> installation won't necessarily be what actually get put in place.

Well, like I said, it's not real pretty.  But the same is already true
of postgresql.conf.sample --- initdb edits that.  I don't see that
having it edit pg_hba.conf.sample too is so bad.

> What if some clever installer/administrator deliberately alters their
> installed sample file?

I don't think it would hurt them.  The editing will consist of a sed
script to comment or uncomment the line containg ::1, it wouldn't touch
anything else.

> Could we get the configure script to do it instead, since it too should 
> know about ip6 capability? (I guess then we'd have 
> pg_hba.conf.sample.in). That strikes me as being a lot cleaner.

Bruce and I talked about that alternative too, but we felt that it made
more sense to keep the processing of pg_hba.conf.sample parallel to what
happens to postgresql.conf.sample.  Further down the road we might need
initdb-time checks to decide what to do to the sample file, just as we
already need for postgresql.conf.sample.

			regards, tom lane

Fri, 05 Sep 2003 09:42:31 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TCP/IP with 7.4 beta2 broken? 
Andrew Dunstan wrote:
> >Bruce and I were just discussing this on the phone.  It seems we have
> >two basic approaches to problem #2.  Either we hack the postmaster so
> >that it will swallow IPv6 addresses in pg_hba.conf even without any real
> >IPv6 support, or we make the default pg_hba.conf contents different.
> >Neither of these is real pretty, but I am leaning to the second, because
> >I agree with your feeling that silently ignoring config lines is a bad
> >idea.
> >
> OK, now we are getting somewhere. I see that this would work. It's a bit 
> ugly, though - with this plan the sample file in both CVS and the 
> installation won't necessarily be what actually get put in place. What 
> if some clever installer/administrator deliberately alters their 
> installed sample file?
> 
> Could we get the configure script to do it instead, since it too should 
> know about ip6 capability? (I guess then we'd have 
> pg_hba.conf.sample.in). That strikes me as being a lot cleaner.

I talked to Tom about this, and we clearly can do it as part of the
build process, rather than at initdb.  Tom said postgresql.conf already
doesn't match the sample file because of changes made by initdb, so he
didn't see how pg_hba.conf changing during initdb would be any worse.

I think either way is fine.  I prefer at build, but I can see his point
too.

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

Fri, 5 Sep 2003 10:01:50 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: TCP/IP with 7.4 beta2 broken?
Robert Creager wrote:

>Once upon a time (Fri, 05 Sep 2003 03:16:54 -0400)
>Andrew Dunstan <andrew@dunslane.net> uttered something amazingly similar to:
>
>  
>
>>Could we get the configure script to do it instead, since it too should 
>>know about ip6 capability? (I guess then we'd have 
>>pg_hba.conf.sample.in). That strikes me as being a lot cleaner.
>>
>>    
>>
>
>What about RPM users?
>
>Cheers,
>Rob
>
>  
>
My recollection is that RPM builds use configure, so they would be just 
fine, I think.

The same consideration would apply to using initdb, of course.

But Tom doesn't like it so I guess it's moot.

cheers

andrew


Fri, 05 Sep 2003 11:18:30 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>OK, now we are getting somewhere. I see that this would work. It's a bit 
>>ugly, though - with this plan the sample file in both CVS and the 
>>installation won't necessarily be what actually get put in place.
>>    
>>
>
>Well, like I said, it's not real pretty.  But the same is already true
>of postgresql.conf.sample --- initdb edits that.  I don't see that
>having it edit pg_hba.conf.sample too is so bad.
>
>  
>
>>What if some clever installer/administrator deliberately alters their
>>installed sample file?
>>    
>>
>
>I don't think it would hurt them.  The editing will consist of a sed
>script to comment or uncomment the line containg ::1, it wouldn't touch
>anything else.
>
>  
>
>>Could we get the configure script to do it instead, since it too should 
>>know about ip6 capability? (I guess then we'd have 
>>pg_hba.conf.sample.in). That strikes me as being a lot cleaner.
>>    
>>
>
>Bruce and I talked about that alternative too, but we felt that it made
>more sense to keep the processing of pg_hba.conf.sample parallel to what
>happens to postgresql.conf.sample.  Further down the road we might need
>initdb-time checks to decide what to do to the sample file, just as we
>already need for postgresql.conf.sample.
>
>  
>

OK, having it comment out the line for the non-ip6 case seems safe 
enough. Having it add the line for the ip6 case would be more dangerous 
ISTM.

BTW, who if anyone is rewriting initdb in C? I presume we need that for 
windows so we are not dependent on having a working shell.

andrew



Fri, 05 Sep 2003 13:24:19 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
Andrew Dunstan wrote:
> OK, having it comment out the line for the non-ip6 case seems safe 
> enough. Having it add the line for the ip6 case would be more dangerous 
> ISTM.
> 
> BTW, who if anyone is rewriting initdb in C? I presume we need that for 
> windows so we are not dependent on having a working shell.

initdb rewrite is on my Win32 project page, but no one has offered yet. 
Connx offered their version done against 7.X and that is on the web page
too.

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

Fri, 5 Sep 2003 13:32:53 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: TCP/IP with 7.4 beta2 broken?
Andrew Dunstan <andrew@dunslane.net> writes:
> BTW, who if anyone is rewriting initdb in C? I presume we need that for 
> windows so we are not dependent on having a working shell.

Not me ;-).  Peter replaced a bunch of other scripts with C code for
7.4, but I dunno if he intends to tackle initdb.  Someone will probably
have to, I agree.

			regards, tom lane

Fri, 05 Sep 2003 13:41:16 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TCP/IP with 7.4 beta2 broken? 
Bruce Momjian wrote:

>Andrew Dunstan wrote:
>  
>
>>BTW, who if anyone is rewriting initdb in C? I presume we need that for 
>>windows so we are not dependent on having a working shell.
>>    
>>
>
>initdb rewrite is on my Win32 project page, but no one has offered yet. 
>Connx offered their version done against 7.X and that is on the web page
>too.
>
>  
>
I will have a look at doing it. I suspect even with a leg up from the 
ConnX stuff it might take a little while.

cheers

andrew


Fri, 05 Sep 2003 16:13:20 -0400
Andrew Dunstan <andrew@dunslane.net>
initdb in C

Are all the IPv6 issues resolved in current CVS?

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

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > OK, now we are getting somewhere. I see that this would work. It's a bit 
> > ugly, though - with this plan the sample file in both CVS and the 
> > installation won't necessarily be what actually get put in place.
> 
> Well, like I said, it's not real pretty.  But the same is already true
> of postgresql.conf.sample --- initdb edits that.  I don't see that
> having it edit pg_hba.conf.sample too is so bad.
> 
> > What if some clever installer/administrator deliberately alters their
> > installed sample file?
> 
> I don't think it would hurt them.  The editing will consist of a sed
> script to comment or uncomment the line containg ::1, it wouldn't touch
> anything else.
> 
> > Could we get the configure script to do it instead, since it too should 
> > know about ip6 capability? (I guess then we'd have 
> > pg_hba.conf.sample.in). That strikes me as being a lot cleaner.
> 
> Bruce and I talked about that alternative too, but we felt that it made
> more sense to keep the processing of pg_hba.conf.sample parallel to what
> happens to postgresql.conf.sample.  Further down the road we might need
> initdb-time checks to decide what to do to the sample file, just as we
> already need for postgresql.conf.sample.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

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

Wed, 10 Sep 2003 00:21:09 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: TCP/IP with 7.4 beta2 broken?
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Are all the IPv6 issues resolved in current CVS?

AFAIK, yes ... but I don't run IPv6 here, so I might not be the best
authority on the subject ...

			regards, tom lane

Wed, 10 Sep 2003 00:29:09 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TCP/IP with 7.4 beta2 broken? 
Bruce Momjian said:
>
> Are all the IPv6 issues resolved in current CVS?
>

This one appears to be, at any rate.

cheers

andrew


> -------------------------------------------------------------------------
--
>
> Tom Lane wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>> > OK, now we are getting somewhere. I see that this would work. It's a
>> > bit  ugly, though - with this plan the sample file in both CVS and
>> > the  installation won't necessarily be what actually get put in
>> > place.
>>
>> Well, like I said, it's not real pretty.  But the same is already true
>> of postgresql.conf.sample --- initdb edits that.  I don't see that
>> having it edit pg_hba.conf.sample too is so bad.
>>
>> > What if some clever installer/administrator deliberately alters
>> > their installed sample file?
>>
>> I don't think it would hurt them.  The editing will consist of a sed
>> script to comment or uncomment the line containg ::1, it wouldn't
>> touch anything else.
>>
>> > Could we get the configure script to do it instead, since it too
>> > should  know about ip6 capability? (I guess then we'd have
>> > pg_hba.conf.sample.in). That strikes me as being a lot cleaner.
>>
>> Bruce and I talked about that alternative too, but we felt that it
>> made more sense to keep the processing of pg_hba.conf.sample parallel
>> to what happens to postgresql.conf.sample.  Further down the road we
>> might need initdb-time checks to decide what to do to the sample file,
>> just as we already need for postgresql.conf.sample.
>>
>> 			regards, tom lane
>>
>> ---------------------------(end of
>> broadcast)--------------------------- TIP 4: Don't 'kill -9' the
>> postmaster
>>
>
> --
>  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
>
> ---------------------------(end of
> broadcast)--------------------------- TIP 5: Have you checked our
> extensive FAQ?
>
>               http://www.postgresql.org/docs/faqs/FAQ.html




Wed, 10 Sep 2003 07:09:18 -0400 (EDT)
"Andrew Dunstan" <andrew@dunslane.net>
Re: TCP/IP with 7.4 beta2 broken?
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Are all the IPv6 issues resolved in current CVS?
> 
> AFAIK, yes ... but I don't run IPv6 here, so I might not be the best
> authority on the subject ...

Completed unless more problem reports arrive --- that's great.

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

Wed, 10 Sep 2003 10:37:43 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: TCP/IP with 7.4 beta2 broken?
Hi,

I just checked out the current CVS-version and everything is fine now on my 
SuSE 8.2-box.

I set tcpip_socket in postgresql.conf to true and was able to connect to 
localhost and 127.0.0.1. I added my local IPv4-netaddress to pg_hba.conf and 
was able to connect to my networkadress.

Thank you.


Tommi

Am Mittwoch, 10. September 2003 06:21 schrieb Bruce Momjian:
> Are all the IPv6 issues resolved in current CVS?
>
> ---------------------------------------------------------------------------
>
> Tom Lane wrote:
> > Andrew Dunstan <andrew@dunslane.net> writes:
> > > OK, now we are getting somewhere. I see that this would work. It's a
> > > bit ugly, though - with this plan the sample file in both CVS and the
> > > installation won't necessarily be what actually get put in place.
> >
> > Well, like I said, it's not real pretty.  But the same is already true
> > of postgresql.conf.sample --- initdb edits that.  I don't see that
> > having it edit pg_hba.conf.sample too is so bad.
> >
> > > What if some clever installer/administrator deliberately alters their
> > > installed sample file?
> >
> > I don't think it would hurt them.  The editing will consist of a sed
> > script to comment or uncomment the line containg ::1, it wouldn't touch
> > anything else.
> >
> > > Could we get the configure script to do it instead, since it too should
> > > know about ip6 capability? (I guess then we'd have
> > > pg_hba.conf.sample.in). That strikes me as being a lot cleaner.
> >
> > Bruce and I talked about that alternative too, but we felt that it made
> > more sense to keep the processing of pg_hba.conf.sample parallel to what
> > happens to postgresql.conf.sample.  Further down the road we might need
> > initdb-time checks to decide what to do to the sample file, just as we
> > already need for postgresql.conf.sample.
> >
> > 			regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster

-- 
Dr. Eckhardt + Partner GmbH
http://www.epgmbh.de

Wed, 10 Sep 2003 16:39:16 +0200
Tommi Maekitalo <t.maekitalo@epgmbh.de>
Re: TCP/IP with 7.4 beta2 broken?