Thread: TCP/IP with 7.4 beta2 broken?
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
Tommi Mäkitalo <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 Mäkitalo <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
Tommi Mäkitalo <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 <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
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 Mäkitalo <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 Mäkitalo <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: >Tommi Mäkitalo <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 > > >
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, Pennsylvania19073
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, Pennsylvania19073
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
? hba.conf.diff
Index: hba.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/hba.c,v
retrieving revision 1.111
diff -c -r1.111 hba.c
*** hba.c 4 Aug 2003 02:39:59 -0000 1.111
--- hba.c 2 Sep 2003 11:07:10 -0000
***************
*** 673,708 ****
if (cidr_slash)
*cidr_slash = '/';
! if (file_ip_addr->ai_family != port->raddr.addr.ss_family)
{
! /* Wrong address family. */
freeaddrinfo_all(hints.ai_family, file_ip_addr);
- return;
- }
! /* Get the netmask */
! if (cidr_slash)
{
! if (SockAddr_cidr_mask(&mask, cidr_slash + 1,
! file_ip_addr->ai_family) < 0)
! goto hba_syntax;
}
else
{
! /* Read the mask field. */
! line = lnext(line);
! if (!line)
! goto hba_syntax;
! token = lfirst(line);
!
! ret = getaddrinfo_all(token, NULL, &hints, &file_ip_mask);
! if (ret || !file_ip_mask)
! goto hba_syntax;
!
! mask = (struct sockaddr_storage *) file_ip_mask->ai_addr;
!
! if (file_ip_addr->ai_family != mask->ss_family)
! goto hba_syntax;
}
/* Read the rest of the line. */
--- 673,761 ----
if (cidr_slash)
*cidr_slash = '/';
! if (file_ip_addr->ai_family == AF_INET && port->raddr.addr.ss_family == AF_INET6)
{
! /* port got a IPV6 address, but the current line is IPV4.
! * We'll make a IPV6 entry from this line, to check if by chance the connecting port
! * is a converted IPV4 address. */
!
! char *v6addr=palloc(strlen(token)+8);
! char *v6mask;
!
freeaddrinfo_all(hints.ai_family, file_ip_addr);
! if (cidr_slash)
! *cidr_slash = 0;
! sprintf(v6addr, "::ffff:%s", token);
! if (cidr_slash)
! *cidr_slash = '/';
!
! ret = getaddrinfo_all(v6addr, NULL, &hints, &file_ip_addr);
! if (ret || !file_ip_addr)
! {
! ereport(LOG,
! (errcode(ERRCODE_CONFIG_FILE_ERROR),
! errmsg("could not interpret converted IP address \"%s\" in config file: %s",
! token, gai_strerror(ret))));
! }
! if (cidr_slash)
! {
! v6mask = palloc(20);
! sprintf(v6mask, "%d", atoi(cidr_slash+1)+96);
! if (SockAddr_cidr_mask(&mask, v6mask, file_ip_addr->ai_family) < 0)
! goto hba_syntax;
! }
! else
! {
! line = lnext(line);
! if (!line)
! goto hba_syntax;
! token = lfirst(line);
! v6mask = palloc(strlen(token)+32);
! sprintf(v6mask, "ffff:ffff:ffff:ffff:ffff:ffff:%s", token);
!
! ret = getaddrinfo_all(v6mask, NULL, &hints, &file_ip_mask);
! if (ret || !file_ip_mask)
! goto hba_syntax;
!
! mask = (struct sockaddr_storage *) file_ip_mask->ai_addr;
!
! if (file_ip_addr->ai_family != mask->ss_family)
! goto hba_syntax;
! }
! }
! else if (file_ip_addr->ai_family != port->raddr.addr.ss_family)
{
! /* Wrong address family. */
! freeaddrinfo_all(hints.ai_family, file_ip_addr);
! return;
}
else
{
! /* Get the netmask */
! if (cidr_slash)
! {
! if (SockAddr_cidr_mask(&mask, cidr_slash + 1,
! file_ip_addr->ai_family) < 0)
! goto hba_syntax;
! }
! else
! {
! /* Read the mask field. */
! line = lnext(line);
! if (!line)
! goto hba_syntax;
! token = lfirst(line);
!
! ret = getaddrinfo_all(token, NULL, &hints, &file_ip_mask);
! if (ret || !file_ip_mask)
! goto hba_syntax;
!
! mask = (struct sockaddr_storage *) file_ip_mask->ai_addr;
!
! if (file_ip_addr->ai_family != mask->ss_family)
! goto hba_syntax;
! }
}
/* Read the rest of the line. */
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 ... > > 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
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_ASCIItemplate1 | postgres | SQL_ASCII (2 Zeilen) tommi@at31:~ > Tommi Mäkitalo
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
*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 >
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.
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
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
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
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
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
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
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, Pennsylvania19073
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
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
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
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
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
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
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
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, Pennsylvania19073
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
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
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, Pennsylvania19073
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
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
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
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
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
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
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, Pennsylvania19073
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
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
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
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, Pennsylvania19073
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
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
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, Pennsylvania19073
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
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
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, Pennsylvania19073
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