Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Bruce Momjian said: Are all the IPv6 issues resolved in current CVS? This one appears to be, at any rate. cheers andrew - -- Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Hi, I just checked out the current CVS-version and everything is fine now on my SuSE 8.2-box. I set tcpip_socket in postgresql.conf to true and was able to connect to localhost and 127.0.0.1. I added my local IPv4-netaddress to pg_hba.conf and was able to connect to my networkadress. Thank you. Tommi Am Mittwoch, 10. September 2003 06:21 schrieb Bruce Momjian: Are all the IPv6 issues resolved in current CVS? --- Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Are all the IPv6 issues resolved in current CVS? --- Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Andrew Dunstan wrote: Bruce and I were just discussing this on the phone. It seems we have two basic approaches to problem #2. Either we hack the postmaster so that it will swallow IPv6 addresses in pg_hba.conf even without any real IPv6 support, or we make the default pg_hba.conf contents different. Neither of these is real pretty, but I am leaning to the second, because I agree with your feeling that silently ignoring config lines is a bad idea. OK, now we are getting somewhere. I see that this would work. It's a bit ugly, though - with this plan the sample file in both CVS and the installation won't necessarily be what actually get put in place. What if some clever installer/administrator deliberately alters their installed sample file? Could we get the configure script to do it instead, since it too should know about ip6 capability? (I guess then we'd have pg_hba.conf.sample.in). That strikes me as being a lot cleaner. I talked to Tom about this, and we clearly can do it as part of the build process, rather than at initdb. Tom said postgresql.conf already doesn't match the sample file because of changes made by initdb, so he didn't see how pg_hba.conf changing during initdb would be any worse. I think either way is fine. I prefer at build, but I can see his point too. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 8: explain analyze is your friend
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Andrew Dunstan [EMAIL PROTECTED] 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
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Robert Creager wrote: Once upon a time (Fri, 05 Sep 2003 03:16:54 -0400) Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Andrew Dunstan wrote: OK, having it comment out the line for the non-ip6 case seems safe enough. Having it add the line for the ip6 case would be more dangerous ISTM. BTW, who if anyone is rewriting initdb in C? I presume we need that for windows so we are not dependent on having a working shell. initdb rewrite is on my Win32 project page, but no one has offered yet. Connx offered their version done against 7.X and that is on the web page too. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Hi, Am Mittwoch, 3. September 2003 20:16 schrieb Bruce Momjian: ... As for the IPv6 issue --- how prevalent is this problem. What OS versions are affected? Has the user done something special to enable this? I have a SuSE 8.2 out of the box. I have done nothing with IPv6. I don't even know much about IPv6. Users expect, that it works just after installation. But after following the discussion I think, that it is not so much a problem. I have 127.0.0.1 in my pg_hba.conf and when I set PGHOST to 127.0.0.1 it workes. If I set PGHOST to localhost, it resolves to ::1, wich don't match my pg_hba.conf-entry. The error message is somewhat clear and gives the user a good hint, where to look for. I don't like the idea of doing something special with loopback-interfaces. Loopback-interfaces are to test the network and tries to handle everything like normal networking. Is it possible to ignore IPv6-entries in pg_hba.conf on non-IPv6-machines? Then we could uncomment IPv6 localhost connections by default. Or uncomment these entries just on IPv6-machines. But this needs modification of default pg_hba.conf depending on OS. Tommi -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tommi Maekitalo wrote: Users expect, that it works just after installation. But after following the discussion I think, that it is not so much a problem. I have 127.0.0.1 in my pg_hba.conf and when I set PGHOST to 127.0.0.1 it workes. If I set PGHOST to localhost, it resolves to ::1, wich don't match my pg_hba.conf-entry. The error message is somewhat clear and gives the user a good hint, where to look for. With the patch I submitted yesterday it would just work out of the box and no error message. ISTM the default setting should do just that. I don't like the idea of doing something special with loopback-interfaces. Loopback-interfaces are to test the network and tries to handle everything like normal networking. Have a look at the patch: http://archives.postgresql.org/pgsql-patches/2003-09/msg00010.php The only special thing it does is in deciding if a connection matches the rule. Otherwise it is treated exactly the same as any other network connection. Is it possible to ignore IPv6-entries in pg_hba.conf on non-IPv6-machines? Then we could uncomment IPv6 localhost connections by default. Or uncomment these entries just on IPv6-machines. But this needs modification of default pg_hba.conf depending on OS. Ignoring entries is probably storing up trouble for yourself in the future. Say I mistype 192.168:1.1 on an IP4 only machine and it is silently ignored? Commenting out / uncommenting entries is problematic. The only sane time would be to do it at initdb time, ISTM. But what if IP6 is turned on after you run initdb? BOOM no work. With my patch you would keep working happily :-) I'm done arguing about this - I'll leave it up to the committers to decide what they want to do and move on to something else. cheers andrew ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane writes: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Peter Eisentraut [EMAIL PROTECTED] writes: Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
On Thu, Sep 04, 2003 at 07:18:57PM +0200, Peter Eisentraut wrote: Tom Lane writes: Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Peter Eisentraut wrote: Tom Lane writes: Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane writes: What is the problem? Is it that a non-IPv6 enabled postmaster is unable to identify or parse valid IPv6 address specifications? In that case, we need to provide some substitute routines. To what purpose? So we can put ::1 in the default pg_hba.conf and have it work on IPv6-enabled hosts by default. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Peter Eisentraut wrote: Andrew Dunstan writes: Having parsed it what would it do with it? Nothing. Surely if IP6 isn't configured in then having an IP6 address in pg_hba.conf is an error. Arguably, but not surely. If Andreas Pflug's patch (with Kurt's caveat) and my patch are applied, then I really think there won't be any more difficulties in this area. Ignoring that I don't like one of the submitted patches, this still won't get us an pg_hba.conf that works out of the box for sites using IPv6. Please explain a scenario that wouldn't work out of the box. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Andrew Dunstan writes: Having parsed it what would it do with it? Nothing. Surely if IP6 isn't configured in then having an IP6 address in pg_hba.conf is an error. Arguably, but not surely. If Andreas Pflug's patch (with Kurt's caveat) and my patch are applied, then I really think there won't be any more difficulties in this area. Ignoring that I don't like one of the submitted patches, this still won't get us an pg_hba.conf that works out of the box for sites using IPv6. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Am Dienstag, 2. September 2003 17:24 schrieb Andrew Dunstan: *nod* but it would be nicer if all loopback interfaces worked by default - hence my localhost suggestion, which would match any of 127.0.0.1/32 :::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. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tommi Maekitalo wrote: *nod* but it would be nicer if all loopback interfaces worked by default - hence my localhost suggestion, which would match any of 127.0.0.1/32 :::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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tommi Maekitalo said: Am Dienstag, 2. September 2003 17:24 schrieb Andrew Dunstan: *nod* but it would be nicer if all loopback interfaces worked by default - hence my localhost suggestion, which would match any of 127.0.0.1/32 :::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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Andreas Pflug said: Tommi Maekitalo wrote: *nod* but it would be nicer if all loopback interfaces worked by default - hence my localhost suggestion, which would match any of 127.0.0.1/32 :::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 :::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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Andrew Dunstan wrote: Andreas Pflug said: Tommi Maekitalo wrote: *nod* but it would be nicer if all loopback interfaces worked by default - hence my localhost suggestion, which would match any of 127.0.0.1/32 :::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 :::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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
On Mon, Sep 01, 2003 at 09:59:17PM +0200, Tommi Mäkitalo wrote: psql: FATAL: no pg_hba.conf entry for host :::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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Andreas Pflug wrote: Andrew Dunstan wrote: Andreas Pflug said: Tommi Maekitalo wrote: *nod* but it would be nicer if all loopback interfaces worked by default - hence my localhost suggestion, which would match any of 127.0.0.1/32 :::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 :::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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Andrew Dunstan wrote: This doesn't look consistent to me. Local addresses can be all addresses that the host's interfaces are currently configured with, loopback is nothing special in this sense. The admin can easily do 'ifconfig' to see all addresses configured and enter them into pg_hba.conf, because these addresses are obvious. We currently have this in the default pg_hba.conf file: host all all 127.0.0.1 255.255.255.255 trust The idea was to have something which would perform equivalently on IP4 only, IP4 over IP6 and pure IP6 connections, without breaking the postmaster host in any of them. It is perfectly true that it could be mangled by the administrator - this would save him/her having to do so for the default case. In my proposal you would replace this default line with: loopback all all trust It's the fact that it is the default that makes it special. Does that make things clearer? We have avoided doing dns lookups from pg_hba.conf, and hence the use of 127.0.0.1 instead of localhost. Now that we cache pg_hba.conf, we could consider allowing hostnames in pg_hba.conf. Is that a TODO? As for the IPv6 issue --- how prevalent is this problem. What OS versions are affected? Has the user done something special to enable this? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Bruce Momjian wrote: Andrew Dunstan wrote: We currently have this in the default pg_hba.conf file: host all all 127.0.0.1 255.255.255.255 trust The idea was to have something which would perform equivalently on IP4 only, IP4 over IP6 and pure IP6 connections, without breaking the postmaster host in any of them. It is perfectly true that it could be mangled by the administrator - this would save him/her having to do so for the default case. In my proposal you would replace this default line with: loopback all all trust It's the fact that it is the default that makes it special. Does that make things clearer? We have avoided doing dns lookups from pg_hba.conf, and hence the use of 127.0.0.1 instead of localhost. Now that we cache pg_hba.conf, we could consider allowing hostnames in pg_hba.conf. Is that a TODO? As for the IPv6 issue --- how prevalent is this problem. What OS versions are affected? Has the user done something special to enable this? These are orthogonal issues. What I have suggested above would work purely at the address level, without any name lookup. Systems (e.g. SUSE) are shipping with IP6 turned on by default - that's how this came up in the first place. DNS lookups were discussed back in May, but there didn't seem to be a nice way to do it in conjunction with netmasks, so I didn't proceed with it after I did CIDR masks. If someone can suggest good semantics and there is demand for it I can look at it again (or someone else can). cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Bruce Momjian wrote: We have avoided doing dns lookups from pg_hba.conf, and hence the use of 127.0.0.1 instead of localhost. Now that we cache pg_hba.conf, we could consider allowing hostnames in pg_hba.conf. Is that a TODO? Hm. DNS lookup would make postmaster startup last much longer, to have all addresses resolved. Usually installations will have only some well-known non-volatile networks configured, So I'd opt to not use DNS. As for the IPv6 issue --- how prevalent is this problem. What OS versions are affected? Has the user done something special to enable this? I can't remember to have opted for a IPV6 installation, so I believe my SuSE 8.1installs IPV6 by default now (and 8.2 too). Then I worked quite a while with 7.3 as usual, and was quite surprised about that IPV6 stuff when upgrading to 7.4. This will probably be an issue more and more, when machines get IPV6 enabled (if by mistake, on purpose or default). The proposed patch will handle IPV4 clients as usual. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tommi =?iso-8859-15?q?M=E4kitalo?= [EMAIL PROTECTED] writes: For remote connections I added: host all all :::192.168.41.0/120trust 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
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane wrote: Tommi =?iso-8859-15?q?M=E4kitalo?= [EMAIL PROTECTED] writes: For remote connections I added: host all all :::192.168.41.0/120trust 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Quick fix is probably to turn IPv6 off in the kernel unless it's needed - on my RH box that is as simple as removing a line from /etc/sysconfig/network and rebooting Kurt Roeckx knows more about this than I do, but I know when I turned IPv6 on I had to do something similar to what is below - I seem to recall we had a discussion about this somewhere. I think we (or at least I) assumed that folks who turned on IPv6 would be able to figure this stuff out for themselves. If distributions are starting to ship with it turned on we may have to revisit that. There seems to be some IPv6 warts, even though it does work. cheers andrew Tom Lane wrote: Tommi =?iso-8859-15?q?M=E4kitalo?= [EMAIL PROTECTED] writes: For remote connections I added: host all all :::192.168.41.0/120trust 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Andreas Pflug [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Am Dienstag, 2. September 2003 02:30 schrieb Andrew Dunstan: Quick fix is probably to turn IPv6 off in the kernel unless it's needed - on my RH box that is as simple as removing a line from /etc/sysconfig/network and rebooting Quick fix is to put the right IPv6-adresses into pg_hba.conf, like I did. The main problem is, that postgresql does not work out of the box. If it is possible postmaster should do some mapping from IPv4-entries in pg_hba.conf to IPv6-entries. Kurt Roeckx knows more about this than I do, but I know when I turned IPv6 on I had to do something similar to what is below - I seem to recall we had a discussion about this somewhere. I think we (or at least I) assumed that folks who turned on IPv6 would be able to figure this stuff out for themselves. If distributions are starting to ship with it turned on we may have to revisit that. I did not switch IPv6 on. It was on after standard installation. Tommi Mäkitalo ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] 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 :::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 :::102.168.0.0/125
This is already a conflict, not getting better or worse if we add
host :::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 - 1.111
--- hba.c 2 Sep 2003 11:07:10 -
***
*** 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, :::%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,
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Hi, the patch did not help. Maybe it would help dumping all pg_hba.conf-etries after generation of IPv6-adresses. But there is another problem, which is related. I get a logentry: LOG: could not bind IPv4 socket: Die Adresse wird bereits verwendet Sorry - I have errormessages in german - I set LANG to nothing, but it looks like not at the right place. It says, that the adress is already in use, but that is not true. Maybe postgres listens at the IPv6-socket first and therefore the IPv4-socket is also in use. Tommi Mäkitalo ... I created a patch to hba.c which uses IPV4 entries as IPV6 entries if running on a IPV6 system (which is detected from a port coming in as AF_INET6) Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tommi Maekitalo wrote: Hi, the patch did not help. Strange. Do you get a client side message hba.conf entry for ::.127.0.0.1 missing? On my system the usual 127.0.0.1 255.255.255.255 is correctly converted to :::127.0.0.1 ::::::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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Hi, I doublechecked, that the patch applied. And there is a change. It workes for connections from remote or to the ethernet-address, but not to localhost: [EMAIL PROTECTED]:~ export PGHOST=localhost [EMAIL PROTECTED]:~ psql -l psql: FATAL: no pg_hba.conf entry for host ::1, user postgres, database template1 [EMAIL PROTECTED]:~ export PGHOST=at31 [EMAIL PROTECTED]:~ psql -l Liste der Datenbanken Name| Eigentümer | Kodierung ---++--- template0 | postgres | SQL_ASCII template1 | postgres | SQL_ASCII (2 Zeilen) [EMAIL PROTECTED]:~ Tommi Mäkitalo ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tommi Maekitalo wrote: Hi, I doublechecked, that the patch applied. And there is a change. It workes for connections from remote or to the ethernet-address, but not to localhost: [EMAIL PROTECTED]:~ export PGHOST=localhost [EMAIL PROTECTED]:~ 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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
*nod* but it would be nicer if all loopback interfaces worked by default - hence my localhost suggestion, which would match any of 127.0.0.1/32 :::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: [EMAIL PROTECTED]:~ export PGHOST=localhost [EMAIL PROTECTED]:~ 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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] 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 hostall all 192.168.41.0 255.255.255.0 trust hostall 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 :::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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tommi =?iso-8859-15?q?M=E4kitalo?= [EMAIL PROTECTED] writes: psql: FATAL: no pg_hba.conf entry for host :::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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
It's a SuSE Linux 8.2-box with the original 2.4.20-kernel. I get the same error when setting PGHOST to localhost, the real hostname or the IP-adress of the box. It has nothing to do with the resolver I think. Tommi Mäkitalo Am Montag, 1. September 2003 22:49 schrieb Tom Lane: Tommi =?iso-8859-15?q?M=E4kitalo?= [EMAIL PROTECTED] writes: psql: FATAL: no pg_hba.conf entry for host :::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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tommi =?iso-8859-15?q?M=E4kitalo?= [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Hi, that worked for localhost. For remote connections I added: host all all :::192.168.41.0/120trust and it worked also (I guessed it - I don't know much about IPv6). Is there any chance to get it work like 7.3? It is no nice experience for new users. Tommi Mäkitalo Am Montag, 1. September 2003 23:24 schrieb Tom Lane: Tommi =?iso-8859-15?q?M=E4kitalo?= [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tommi Mäkitalo wrote: Hi, that worked for localhost. For remote connections I added: host all all :::192.168.41.0/120trust 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
