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 =?iso-8859-15?q?M=E4kitalo?= <t.maekitalo@epgmbh.de> writes:
psql: FATAL: no pg_hba.conf entry for host "::ffff:127.0.0.1", user
"postgres", database "template1"
What platform is this?
It sounds to me like your system is resolving "localhost" as an IPv6
address ...
regards, tom lane
It's a SuSE Linux 8.2-box with the original 2.4.20-kernel.
I get the same error when setting PGHOST to localhost, the real hostname or
the IP-adress of the box. It has nothing to do with the resolver I think.
Tommi Mäkitalo
Am Montag, 1. September 2003 22:49 schrieb Tom Lane:
Show quoted text
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
Tommi =?iso-8859-15?q?M=E4kitalo?= <t.maekitalo@epgmbh.de> writes:
It's a SuSE Linux 8.2-box with the original 2.4.20-kernel.
I get the same error when setting PGHOST to localhost, the real hostname or
the IP-adress of the box. It has nothing to do with the resolver I think.
Hm. I assume things will work after you uncomment the commented-out
IPv6 entries at the bottom of pg_hba.conf.
regards, tom lane
Hi,
that worked for localhost. For remote connections I added:
host all all ::ffff:192.168.41.0/120 trust
and it worked also (I guessed it - I don't know much about IPv6). Is there any
chance to get it work like 7.3? It is no nice experience for new users.
Tommi Mäkitalo
Am Montag, 1. September 2003 23:24 schrieb Tom Lane:
Show quoted text
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
Tommi Mï¿œkitalo wrote:
Hi,
that worked for localhost. For remote connections I added:
host all all ::ffff:192.168.41.0/120 trust
and it worked also (I guessed it - I don't know much about IPv6). Is there any
chance to get it work like 7.3? It is no nice experience for new users.
This isn't really a pgsql problem, but special about SuSE Linux which
enables IPV6 by default. Maybe there should be a warning somewhere that
a growing number of Linux versions might be IPV6 enabled and thus
pg_pba.conf needs to respect this.
Regards,
Andreas
Tommi =?iso-8859-15?q?M=E4kitalo?= <t.maekitalo@epgmbh.de> writes:
For remote connections I added:
host all all ::ffff:192.168.41.0/120 trust
and it worked also (I guessed it - I don't know much about IPv6). Is
there any chance to get it work like 7.3? It is no nice experience for
new users.
Are you saying it does not work with just 192.168.41.0/24 ? That would
be really unfortunate --- it suggests that your kernel pretends that
IPv4 connections are IPv6.
regards, tom lane
Tom Lane wrote:
Tommi =?iso-8859-15?q?M=E4kitalo?= <t.maekitalo@epgmbh.de> writes:
For remote connections I added:
host all all ::ffff:192.168.41.0/120 trust
and it worked also (I guessed it - I don't know much about IPv6). Is
there any chance to get it work like 7.3? It is no nice experience for
new users.Are you saying it does not work with just 192.168.41.0/24 ? That would
be really unfortunate --- it suggests that your kernel pretends that
IPv4 connections are IPv6.
Tom,
we discussed this problem some months ago when I started using 7.4 on
SuSE 8.1. Since 7.4 accepts IPV6, the kernel will always deliver IPV6
addresses, that's why I find most IPV6 problems. While this behaviour
might be irritating, it shouldn't be much of a problem if known.
How about silently creating a IPV6 style host internally for every IPV4
pg_hba.conf entry? It won't make any sense to handle a real IPV4 address
different from an IPV4 address converted to IPV6 address space.
Regards,
Andreas
Quick fix is probably to turn IPv6 off in the kernel unless it's needed
- on my RH box that is as simple as removing a line from
/etc/sysconfig/network and rebooting
Kurt Roeckx knows more about this than I do, but I know when I turned
IPv6 on I had to do something similar to what is below - I seem to
recall we had a discussion about this somewhere. I think we (or at
least I) assumed that folks who turned on IPv6 would be able to figure
this stuff out for themselves. If distributions are starting to ship
with it turned on we may have to revisit that.
There seems to be some IPv6 warts, even though it does work.
cheers
andrew
Tom Lane wrote:
Show quoted text
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
Andreas Pflug <pgadmin@pse-consulting.de> writes:
How about silently creating a IPV6 style host internally for every IPV4
pg_hba.conf entry? It won't make any sense to handle a real IPV4 address
different from an IPV4 address converted to IPV6 address space.
Hmm. I could go for that, if it weren't that there seem to be several
different conventions for embedding IPv4 in IPv6. Should we auto-create
pg_hba.conf entries for all of the possibly equivalent addresses? What
if that creates conflicts?
regards, tom lane
Andreas Pflug wrote:
Tommi M?kitalo wrote:
Hi,
that worked for localhost. For remote connections I added:
host all all ::ffff:192.168.41.0/120 trust
and it worked also (I guessed it - I don't know much about IPv6). Is there any
chance to get it work like 7.3? It is no nice experience for new users.This isn't really a pgsql problem, but special about SuSE Linux which
enables IPV6 by default. Maybe there should be a warning somewhere that
a growing number of Linux versions might be IPV6 enabled and thus
pg_pba.conf needs to respect this.
Ouch --- everything is IPv6. Wow, that is unusual. I assumed that
folks who have OS's that do that will put IPv6 addresses in pg_hba.conf.
I don't see that we should be auto-converting pg_hba.conf to IPv6 if the
kernel thinks everything is IPv6.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
Ouch --- everything is IPv6. Wow, that is unusual. I assumed that
folks who have OS's that do that will put IPv6 addresses in pg_hba.conf.
I think that may be reasonable. What bothers me is that the default
pg_hba.conf will fail to accept localhost connections on such a system.
OTOH older systems will complain if pg_hba.conf contains IPv6 entries.
We may not have much choice but to find a way to configure pg_hba.conf's
localhost entries at initdb time ...
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Ouch --- everything is IPv6. Wow, that is unusual. I assumed that
folks who have OS's that do that will put IPv6 addresses in pg_hba.conf.I think that may be reasonable. What bothers me is that the default
pg_hba.conf will fail to accept localhost connections on such a system.
OTOH older systems will complain if pg_hba.conf contains IPv6 entries.We may not have much choice but to find a way to configure pg_hba.conf's
localhost entries at initdb time ...
Can we allow the IPv6 entries to be in pg_hba.conf but ignore them on
non-IPv6 machines, or allow the connection to fail?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce 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
Attachments:
hba.conf.difftext/plain; name=hba.conf.diffDownload
? 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
...
Show quoted text
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_ASCII
template1 | 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:
Show quoted text
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",
databaseThat'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 of127.0.0.1/32
::ffff:127.0.0.1/128 and
::1/128cheers
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 of127.0.0.1/32
::ffff:127.0.0.1/128 and
::1/128cheers
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 of127.0.0.1/32
::ffff:127.0.0.1/128 and
::1/128cheers
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 of127.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 of127.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 of127.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, Pennsylvania 19073Bruce 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 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
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 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 19073Bruce 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
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 19073Andrew 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
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
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
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 <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
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 19073Robert 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
Import Notes
Reply to msg id not found: 20030905080041.2c90be6f.Robert_Creager@LogicalChaos.org
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, Pennsylvania 19073Andrew 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, Pennsylvania 19073Bruce 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
-------------------------------------------------------------------------
--
Show quoted text
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?
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 19073Hi,
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