Thread: IPv6 patch
I have been working on a patch to implement IPv6 connections. A working patch was supplied by Nigel Kukard about two weeks ago, and I have been improving it. The original patch assumed the system has IPv6 functions, like getaddrinfo(), so the major work was patching it into our existing code that doesn't use IPv6 functions, so systems with/without IPv6 will be able to compile the same code. The patch is at: ftp://candle.pha.pa.us/pub/postgresql/mypatches/ipv6.full It has a configure test to determine if getaddrinfo() exists, and sets a #define and a Makefile variable appropriately. Most of the changes are in backend/libpq/pqcomm.c::StreamServerPort and interfaces/libpq/fe-connect.c::connectDBStart. There are also two new files, ip.c and ip.h, which contain IP-specific support functions. I have done my best to make the code as clear as possible. There are more define tests than I would like, but I am hesitant to split out more of the code into almost duplicate functions for IPv4 and IPv6 functionality. I have tested the code using IPv6 functions, and IPv4 functions. The system also has no IPv6 support in the kernel, so that has also been tested. The patch is about a week away from being applied, but I thought I would post the URL so folks can see where I am going. I am interested in improvements and testing with various configurations. FYI, I am also working with someone on the openprojects IRC channel #ipv6 on an IPv6 data type. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Patch applied. I added a small mention of IPv6 addresses to the pg_hba.conf documentation. Not sure where else to mention it. --------------------------------------------------------------------------- Bruce Momjian wrote: > I have been working on a patch to implement IPv6 connections. A working > patch was supplied by Nigel Kukard about two weeks ago, and I have been > improving it. The original patch assumed the system has IPv6 functions, > like getaddrinfo(), so the major work was patching it into our existing > code that doesn't use IPv6 functions, so systems with/without IPv6 will > be able to compile the same code. > > The patch is at: > > ftp://candle.pha.pa.us/pub/postgresql/mypatches/ipv6.full > > It has a configure test to determine if getaddrinfo() exists, and sets a > #define and a Makefile variable appropriately. Most of the changes are > in backend/libpq/pqcomm.c::StreamServerPort and > interfaces/libpq/fe-connect.c::connectDBStart. There are also two new > files, ip.c and ip.h, which contain IP-specific support functions. > > I have done my best to make the code as clear as possible. There are > more define tests than I would like, but I am hesitant to split out more > of the code into almost duplicate functions for IPv4 and IPv6 > functionality. > > I have tested the code using IPv6 functions, and IPv4 functions. The > system also has no IPv6 support in the kernel, so that has also been > tested. > > The patch is about a week away from being applied, but I thought I would > post the URL so folks can see where I am going. I am interested in > improvements and testing with various configurations. > > FYI, I am also working with someone on the openprojects IRC channel > #ipv6 on an IPv6 data type. > > -- > 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 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian writes: > Patch applied. I added a small mention of IPv6 addresses to the > pg_hba.conf documentation. Not sure where else to mention it. Can this patch please be cleaned up so the code doesn't contain an #ifdef on every other line? I would also like to discuss how IPv6 is handled during the server start and in pg_hba.conf. It seems that we should treat the address families Unix, IPv4, and IPv6 consistenly, which would mean two things: (1) pg_hba.conf entries pertaining to the address family are allowed and present in the default file, no matter whether the address family is used by the server. (2) A socket type is explicitly enabled for the server to use, and if creation fails, server startup fails. It seems that the current code falls back to IPv4 if IPv6 fails. -- Peter Eisentraut peter_e@gmx.net
On Mon, 2003-01-06 at 15:29, Peter Eisentraut wrote: > (2) A socket type is explicitly enabled for the server to use, and if > creation fails, server startup fails. It seems that the current code > falls back to IPv4 if IPv6 fails. IIRC, it allows it to fall back to IPv4 in case it's compiled for IPv6 support but the kernel isn't compiled to support IPv6. If that is the case, admittedly, you seem to have a point. If someone compiles in v6 support and their system doesn't have v6 support and it's been requested via run-time config, it's should fail just like any other. -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Patch applied. I added a small mention of IPv6 addresses to the > > pg_hba.conf documentation. Not sure where else to mention it. > > Can this patch please be cleaned up so the code doesn't contain an #ifdef > on every other line? I posted the patch a week ago, and mentioned this exact problem. Any suggestions? I realized I could break out the parts into IPv4/6 sections, but then I would have duplicate code paths that were identical except for the IPv4/6 calls. Is that the way to go? The major ugliness is in pqcomm.c and fe-connect.c. Add the unix domain socket and SSL defines, and it is a mess. However, the danger of breaking out the code into separate routines is that then we have to keep them consistent if we make any changes. > I would also like to discuss how IPv6 is handled during the server start > and in pg_hba.conf. It seems that we should treat the address families > Unix, IPv4, and IPv6 consistenly, which would mean two things: > > (1) pg_hba.conf entries pertaining to the address family are allowed and > present in the default file, no matter whether the address family is used > by the server. > > (2) A socket type is explicitly enabled for the server to use, and if > creation fails, server startup fails. It seems that the current code > falls back to IPv4 if IPv6 fails. The issue is that right now, there isn't any special IPv6 enabling, except for lines in pg_hba.conf. I think it is fine to add some enabling, but we then have an additional user interface issue. One idea I had was to change tcpip_socket from true/false to true/false/4/6 so you can specify if you want none(false)/4/6/both(true). The original patch author wants this functionality too, so there clearly is a need for this. This doesn't play nice with the -i flag, however. Also, I need help specifying to listen on _just_ IPv4 or IPv6. The way it is coded, you open IPv6 and IPv4 comes along with it. We could add some test that checks _after_ the connection is made and reject IPv4/6, but it would be better to listen _just_ on the IP version specified. I am not sure how to do that, and the #ipv6 IRC channel wasn't clear either. I tried Google but didn't get a clear answer there either. Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6 isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true, but when run, opening an IPV6 server fails and I fall back to IPv4 --- just throwing that out as a data point. What would be our default as shipped? I do think we need some user interface control over IPv6 and IPv4. I just coded it to get it working, and compilable on most platforms, and then we can iron out these issues. If we have an IPv6 enablement, it would allow us to keep the pg_hba.conf IPv6 line, and just ignore it, or throw a warning in the logs, though if it is by default in pg_hba.conf, a warning seems strange. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Greg Copeland wrote: > On Mon, 2003-01-06 at 15:29, Peter Eisentraut wrote: > > (2) A socket type is explicitly enabled for the server to use, and if > > creation fails, server startup fails. It seems that the current code > > falls back to IPv4 if IPv6 fails. > > IIRC, it allows it to fall back to IPv4 in case it's compiled for IPv6 > support but the kernel isn't compiled to support IPv6. If that is the > case, admittedly, you seem to have a point. If someone compiles in v6 > support and their system doesn't have v6 support and it's been requested > via run-time config, it's should fail just like any other. Yes, right now, it is kind of a mystery when it falls back to IPv4. It does print a message in the server logs: LOG: server socket failure: getaddrinfo2() using IPv6: hostname nor servname provided, or not known LOG: IPv6 supportdisabled --- perhaps the kernel does not support IPv6 LOG: IPv4 socket created It appears right at the top because creating the socket is the first thing it does. A good question is once we have a way for the user to control IPv4/6, what do we ship as a default? IPv4-only? Both, and if both, do we fail on a kernel that doesn't have IPv6 enabled? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Mon, 2003-01-06 at 15:43, Bruce Momjian wrote: > Greg Copeland wrote: > > On Mon, 2003-01-06 at 15:29, Peter Eisentraut wrote: > > > (2) A socket type is explicitly enabled for the server to use, and if > > > creation fails, server startup fails. It seems that the current code > > > falls back to IPv4 if IPv6 fails. > > > > IIRC, it allows it to fall back to IPv4 in case it's compiled for IPv6 > > support but the kernel isn't compiled to support IPv6. If that is the > > case, admittedly, you seem to have a point. If someone compiles in v6 > > support and their system doesn't have v6 support and it's been requested > > via run-time config, it's should fail just like any other. > > Yes, right now, it is kind of a mystery when it falls back to IPv4. It > does print a message in the server logs: > > LOG: server socket failure: getaddrinfo2() using IPv6: hostname nor servname provided, or not known > LOG: IPv6 support disabled --- perhaps the kernel does not support IPv6 > LOG: IPv4 socket created > > It appears right at the top because creating the socket is the first > thing it does. A good question is once we have a way for the user to > control IPv4/6, what do we ship as a default? IPv4-only? Both, and if > both, do we fail on a kernel that doesn't have IPv6 enabled? So you're saying that by using the IPv6 address family and you bind to an IPv6 address (or even ANY interface), you still get v4 connections on the same bind/listen/accept sequence? I'm asking because I've never done v6 stuff. Regards, -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
Greg Copeland wrote: > > It appears right at the top because creating the socket is the first > > thing it does. A good question is once we have a way for the user to > > control IPv4/6, what do we ship as a default? IPv4-only? Both, and if > > both, do we fail on a kernel that doesn't have IPv6 enabled? > > So you're saying that by using the IPv6 address family and you bind to > an IPv6 address (or even ANY interface), you still get v4 connections on > the same bind/listen/accept sequence? > > I'm asking because I've never done v6 stuff. Yes, it listens on both. The original author, Nigel, tested in using both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem to indicate that too. What I am not sure how to do is say _only_ IPv4. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote: > Greg Copeland wrote: > > > It appears right at the top because creating the socket is the first > > > thing it does. A good question is once we have a way for the user to > > > control IPv4/6, what do we ship as a default? IPv4-only? Both, and if > > > both, do we fail on a kernel that doesn't have IPv6 enabled? > > > > So you're saying that by using the IPv6 address family and you bind to > > an IPv6 address (or even ANY interface), you still get v4 connections on > > the same bind/listen/accept sequence? > > > > I'm asking because I've never done v6 stuff. > > Yes, it listens on both. The original author, Nigel, tested in using > both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem > to indicate that too. What I am not sure how to do is say _only_ IPv4. Wouldn't you just use an IPv4 address family when creating your socket? -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
Greg Copeland wrote: > On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote: > > Greg Copeland wrote: > > > > It appears right at the top because creating the socket is the first > > > > thing it does. A good question is once we have a way for the user to > > > > control IPv4/6, what do we ship as a default? IPv4-only? Both, and if > > > > both, do we fail on a kernel that doesn't have IPv6 enabled? > > > > > > So you're saying that by using the IPv6 address family and you bind to > > > an IPv6 address (or even ANY interface), you still get v4 connections on > > > the same bind/listen/accept sequence? > > > > > > I'm asking because I've never done v6 stuff. > > > > Yes, it listens on both. The original author, Nigel, tested in using > > both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem > > to indicate that too. What I am not sure how to do is say _only_ IPv4. > > Wouldn't you just use an IPv4 address family when creating your socket? Sorry, I meant only IPv6. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Mon, 2003-01-06 at 16:17, Bruce Momjian wrote: > Greg Copeland wrote: > > On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote: > > > Greg Copeland wrote: > > > > > It appears right at the top because creating the socket is the first > > > > > thing it does. A good question is once we have a way for the user to > > > > > control IPv4/6, what do we ship as a default? IPv4-only? Both, and if > > > > > both, do we fail on a kernel that doesn't have IPv6 enabled? > > > > > > > > So you're saying that by using the IPv6 address family and you bind to > > > > an IPv6 address (or even ANY interface), you still get v4 connections on > > > > the same bind/listen/accept sequence? > > > > > > > > I'm asking because I've never done v6 stuff. > > > > > > Yes, it listens on both. The original author, Nigel, tested in using > > > both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem > > > to indicate that too. What I am not sure how to do is say _only_ IPv4. > > > > Wouldn't you just use an IPv4 address family when creating your socket? > > Sorry, I meant only IPv6. I found this. It seems to imply that you need different sockets to do what you want to do. You might snag a copy of the latest openldap code and look at slapd to see what it's doing. At any rate, here's what I found that pointed me at it: slapd compiled with --enable-ipv6 does only listen to the IPv6 connections. I suspect this is tested on an operating system that receives IPv4 connections to the IPv6 socket as well, although this is not not the case for OpenBSD (nor FreeBSD or NetBSD ,IIRC). slapd needs to listen to both IPv4 and IPv6 on separate sockets. -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
Greg Copeland wrote: > > > > Yes, it listens on both. The original author, Nigel, tested in using > > > > both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem > > > > to indicate that too. What I am not sure how to do is say _only_ IPv4. > > > > > > Wouldn't you just use an IPv4 address family when creating your socket? > > > > Sorry, I meant only IPv6. > > > I found this. It seems to imply that you need different sockets to do > what you want to do. You might snag a copy of the latest openldap code > and look at slapd to see what it's doing. > > At any rate, here's what I found that pointed me at it: > > slapd compiled with --enable-ipv6 does only listen to the IPv6 connections. I > suspect this is tested on an operating system that receives IPv4 connections to > the IPv6 socket as well, although this is not not the case for OpenBSD (nor > FreeBSD or NetBSD ,IIRC). slapd needs to listen to both IPv4 and IPv6 on > separate sockets. I wasn't clear on which OS's supported dual ipv4/6 on the same socket. Nigel is testing on Linux, so he says that works for both on the same socket. Maybe on those other OS's we can do separate sockets on the same port number --- not sure. Now that it is in there various OS's can run tests and we will see. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Mon, 2003-01-06 at 16:40, Bruce Momjian wrote: > Peter Eisentraut wrote: > > Bruce Momjian writes: > The issue is that right now, there isn't any special IPv6 enabling, > except for lines in pg_hba.conf. I think it is fine to add some > enabling, but we then have an additional user interface issue. One idea > I had was to change tcpip_socket from true/false to true/false/4/6 so > you can specify if you want none(false)/4/6/both(true). The original > patch author wants this functionality too, so there clearly is a need > for this. This doesn't play nice with the -i flag, however. > Would there a downside to specifying both (enabling ipv6) on a machine that doesn't support it? If not I'd suggest making -i equivalent to tcp_ip_socket = true. I don't think it's too much to ask people to use the preferred method to obtain maximum functionality. > Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6 > isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true, > but when run, opening an IPV6 server fails and I fall back to IPv4 --- > just throwing that out as a data point. What would be our default as > shipped? If there is no downside to allowing both, probably both. If there is a downside then ipv4, since it much more likely to be the default on OS's for the next release or two. Robert Treat
OK, what do we ship as a default? --------------------------------------------------------------------------- Nigel Kukard wrote: > Sorry i'm not subscribed to hackers, guess i must get soon! > > > Anyway what i think should happen is follows, if in the configuration file > we specify that it must bind to both ie. tcpip_socket = true, the server > should check if first its compiled to support ipv6 (or skip this if we use > #ifdef's) and secondly bind to what WE tell it to. If we specify TRUE it > must try to bind to both. Ok thats the first case, the second case is if > we specify ipv4, ie. tcpip_socket = 4. This should ONLY bind ipv4, not ipv6 > and if there is no ipv4 support on the box it should fail, not fallback. > And finally the third case, if we specify tcpip_socket = 6, we should > again ONLY bind to ipv6, if there is no ipv6 support compiled, or if we > cannot bind to the specific interface we should fail. > > Thats my opinion ;) > > > -Nigel > > > > On 6 Jan 2003, Robert Treat wrote: > > > On Mon, 2003-01-06 at 16:40, Bruce Momjian wrote: > > > Peter Eisentraut wrote: > > > > Bruce Momjian writes: > > > The issue is that right now, there isn't any special IPv6 enabling, > > > except for lines in pg_hba.conf. I think it is fine to add some > > > enabling, but we then have an additional user interface issue. One idea > > > I had was to change tcpip_socket from true/false to true/false/4/6 so > > > you can specify if you want none(false)/4/6/both(true). The original > > > patch author wants this functionality too, so there clearly is a need > > > for this. This doesn't play nice with the -i flag, however. > > > > > > > Would there a downside to specifying both (enabling ipv6) on a machine > > that doesn't support it? If not I'd suggest making -i equivalent to > > tcp_ip_socket = true. I don't think it's too much to ask people to use > > the preferred method to obtain maximum functionality. > > > > > Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6 > > > isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true, > > > but when run, opening an IPV6 server fails and I fall back to IPv4 --- > > > just throwing that out as a data point. What would be our default as > > > shipped? > > > > If there is no downside to allowing both, probably both. If there is a > > downside then ipv4, since it much more likely to be the default on OS's > > for the next release or two. > > > > Robert Treat > > > > > > > > > > -- > > > Nigel Kukard (Chief Executive Officer) > Lando Technologies Africa (Pty) Ltd > nigel@lando.co.za www.lando.co.za > Tel: 083 399 5822 Fax: 086 1100036 > Hoheisen Park Bellville, Cape Town > National Internet Service Provider > > > The best language to use is the language that was designed for > what you want to use it for - 1997 > > > ===================================================================== > > Disclaimer > ---------- > The contents of this message and any attachments are intended > solely for the addressee's use and may be legally privileged and/or > confidential information. This message may not be retained, > distributed, copied or used if you are not he addressee of this > message. If this message was sent to you in error, please notify > the sender immediately by reply e-mail and then destroy the message > and any copies thereof. > > Opinions, conclusions and other information in this message may be > personal to the sender and is not that of Lando Technologies Africa > or any of it's subsideries, associated companies or principals and > is therefore not endorsed by any of the Lando groups of companies. > Due to e-maill communication being insecure, Lando groups of > companies do not guarantee confidentiality, security, accuracy or > performance of the e-mail. Any liability for viruses is excluded > to the fullest extent. > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
You mean ship with only IPv4 enabled, but not IPv6. (Of course, both are enabled in the binary.) But then what does -i do? We currently tell people to use -i. Do we need another postgresql.conf option that says, "If tcpip_socket is enabled, enable IPv6 too"? But that doesn't work if you want _only_ IPv6. The big problem is it doesn't mix with tcpip_socket and -i very well. I am not saying I have a better idea, I am just looking for something clearer. Perhaps we need a separate flag/postgresql.conf option for IPv6 so they can be controlled separately. Have we figured out how to listen on IPv6 only? --------------------------------------------------------------------------- Nigel Kukard wrote: > > IPV4 only should be shipped by default, but disabled as it is at present. > > > On Tue, 7 Jan 2003, Bruce Momjian wrote: > > > > > OK, what do we ship as a default? > > > > --------------------------------------------------------------------------- > > > > Nigel Kukard wrote: > > > Sorry i'm not subscribed to hackers, guess i must get soon! > > > > > > > > > Anyway what i think should happen is follows, if in the configuration file > > > we specify that it must bind to both ie. tcpip_socket = true, the server > > > should check if first its compiled to support ipv6 (or skip this if we use > > > #ifdef's) and secondly bind to what WE tell it to. If we specify TRUE it > > > must try to bind to both. Ok thats the first case, the second case is if > > > we specify ipv4, ie. tcpip_socket = 4. This should ONLY bind ipv4, not ipv6 > > > and if there is no ipv4 support on the box it should fail, not fallback. > > > And finally the third case, if we specify tcpip_socket = 6, we should > > > again ONLY bind to ipv6, if there is no ipv6 support compiled, or if we > > > cannot bind to the specific interface we should fail. > > > > > > Thats my opinion ;) > > > > > > > > > -Nigel > > > > > > > > > > > > On 6 Jan 2003, Robert Treat wrote: > > > > > > > On Mon, 2003-01-06 at 16:40, Bruce Momjian wrote: > > > > > Peter Eisentraut wrote: > > > > > > Bruce Momjian writes: > > > > > The issue is that right now, there isn't any special IPv6 enabling, > > > > > except for lines in pg_hba.conf. I think it is fine to add some > > > > > enabling, but we then have an additional user interface issue. One idea > > > > > I had was to change tcpip_socket from true/false to true/false/4/6 so > > > > > you can specify if you want none(false)/4/6/both(true). The original > > > > > patch author wants this functionality too, so there clearly is a need > > > > > for this. This doesn't play nice with the -i flag, however. > > > > > > > > > > > > > Would there a downside to specifying both (enabling ipv6) on a machine > > > > that doesn't support it? If not I'd suggest making -i equivalent to > > > > tcp_ip_socket = true. I don't think it's too much to ask people to use > > > > the preferred method to obtain maximum functionality. > > > > > > > > > Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6 > > > > > isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true, > > > > > but when run, opening an IPV6 server fails and I fall back to IPv4 --- > > > > > just throwing that out as a data point. What would be our default as > > > > > shipped? > > > > > > > > If there is no downside to allowing both, probably both. If there is a > > > > downside then ipv4, since it much more likely to be the default on OS's > > > > for the next release or two. > > > > > > > > Robert Treat > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Nigel Kukard (Chief Executive Officer) > > > Lando Technologies Africa (Pty) Ltd > > > nigel@lando.co.za www.lando.co.za > > > Tel: 083 399 5822 Fax: 086 1100036 > > > Hoheisen Park Bellville, Cape Town > > > National Internet Service Provider > > > > > > > > > The best language to use is the language that was designed for > > > what you want to use it for - 1997 > > > > > > > > > ===================================================================== > > > > > > Disclaimer > > > ---------- > > > The contents of this message and any attachments are intended > > > solely for the addressee's use and may be legally privileged and/or > > > confidential information. This message may not be retained, > > > distributed, copied or used if you are not he addressee of this > > > message. If this message was sent to you in error, please notify > > > the sender immediately by reply e-mail and then destroy the message > > > and any copies thereof. > > > > > > Opinions, conclusions and other information in this message may be > > > personal to the sender and is not that of Lando Technologies Africa > > > or any of it's subsideries, associated companies or principals and > > > is therefore not endorsed by any of the Lando groups of companies. > > > Due to e-maill communication being insecure, Lando groups of > > > companies do not guarantee confidentiality, security, accuracy or > > > performance of the e-mail. Any liability for viruses is excluded > > > to the fullest extent. > > > > > > > > > > > > -- > > > Nigel Kukard (Chief Executive Officer) > Lando Technologies Africa (Pty) Ltd > nigel@lando.co.za www.lando.co.za > Tel: 083 399 5822 Fax: 086 1100036 > Hoheisen Park Bellville, Cape Town > National Internet Service Provider > > > The best language to use is the language that was designed for > what you want to use it for - 1997 > > > ===================================================================== > > Disclaimer > ---------- > The contents of this message and any attachments are intended > solely for the addressee's use and may be legally privileged and/or > confidential information. This message may not be retained, > distributed, copied or used if you are not he addressee of this > message. If this message was sent to you in error, please notify > the sender immediately by reply e-mail and then destroy the message > and any copies thereof. > > Opinions, conclusions and other information in this message may be > personal to the sender and is not that of Lando Technologies Africa > or any of it's subsideries, associated companies or principals and > is therefore not endorsed by any of the Lando groups of companies. > Due to e-maill communication being insecure, Lando groups of > companies do not guarantee confidentiality, security, accuracy or > performance of the e-mail. Any liability for viruses is excluded > to the fullest extent. > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Another idea is to have the -i take an optional argument. Something where -i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only v6. I am guessing that most people will want to bind to both when they just specify -i, which is what is usually suggested when they want to get the box up and running. If they want do something fancy, like only bind to v6, then they will read the docs and see that they can do that with something like -i6. -rocco On Tue, 7 Jan 2003, Bruce Momjian wrote: > > You mean ship with only IPv4 enabled, but not IPv6. (Of course, both > are enabled in the binary.) But then what does -i do? We currently > tell people to use -i. Do we need another postgresql.conf option that > says, "If tcpip_socket is enabled, enable IPv6 too"? But that doesn't > work if you want _only_ IPv6. > > The big problem is it doesn't mix with tcpip_socket and -i very well. I > am not saying I have a better idea, I am just looking for something > clearer. Perhaps we need a separate flag/postgresql.conf option for > IPv6 so they can be controlled separately. Have we figured out how to > listen on IPv6 only? > > --------------------------------------------------------------------------- > > Nigel Kukard wrote: > > > > IPV4 only should be shipped by default, but disabled as it is at present. > > > > > > On Tue, 7 Jan 2003, Bruce Momjian wrote: > > > > > > > > OK, what do we ship as a default? > > > > > > --------------------------------------------------------------------------- > > > > > > Nigel Kukard wrote: > > > > Sorry i'm not subscribed to hackers, guess i must get soon! > > > > > > > > > > > > Anyway what i think should happen is follows, if in the configuration file > > > > we specify that it must bind to both ie. tcpip_socket = true, the server > > > > should check if first its compiled to support ipv6 (or skip this if we use > > > > #ifdef's) and secondly bind to what WE tell it to. If we specify TRUE it > > > > must try to bind to both. Ok thats the first case, the second case is if > > > > we specify ipv4, ie. tcpip_socket = 4. This should ONLY bind ipv4, not ipv6 > > > > and if there is no ipv4 support on the box it should fail, not fallback. > > > > And finally the third case, if we specify tcpip_socket = 6, we should > > > > again ONLY bind to ipv6, if there is no ipv6 support compiled, or if we > > > > cannot bind to the specific interface we should fail. > > > > > > > > Thats my opinion ;) > > > > > > > > > > > > -Nigel > > > > > > > > > > > > > > > > On 6 Jan 2003, Robert Treat wrote: > > > > > > > > > On Mon, 2003-01-06 at 16:40, Bruce Momjian wrote: > > > > > > Peter Eisentraut wrote: > > > > > > > Bruce Momjian writes: > > > > > > The issue is that right now, there isn't any special IPv6 enabling, > > > > > > except for lines in pg_hba.conf. I think it is fine to add some > > > > > > enabling, but we then have an additional user interface issue. One idea > > > > > > I had was to change tcpip_socket from true/false to true/false/4/6 so > > > > > > you can specify if you want none(false)/4/6/both(true). The original > > > > > > patch author wants this functionality too, so there clearly is a need > > > > > > for this. This doesn't play nice with the -i flag, however. > > > > > > > > > > > > > > > > Would there a downside to specifying both (enabling ipv6) on a machine > > > > > that doesn't support it? If not I'd suggest making -i equivalent to > > > > > tcp_ip_socket = true. I don't think it's too much to ask people to use > > > > > the preferred method to obtain maximum functionality. > > > > > > > > > > > Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6 > > > > > > isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true, > > > > > > but when run, opening an IPV6 server fails and I fall back to IPv4 --- > > > > > > just throwing that out as a data point. What would be our default as > > > > > > shipped? > > > > > > > > > > If there is no downside to allowing both, probably both. If there is a > > > > > downside then ipv4, since it much more likely to be the default on OS's > > > > > for the next release or two. > > > > > > > > > > Robert Treat > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Nigel Kukard (Chief Executive Officer) > > > > Lando Technologies Africa (Pty) Ltd > > > > nigel@lando.co.za www.lando.co.za > > > > Tel: 083 399 5822 Fax: 086 1100036 > > > > Hoheisen Park Bellville, Cape Town > > > > National Internet Service Provider > > > > > > > > > > > > The best language to use is the language that was designed for > > > > what you want to use it for - 1997 > > > > > > > > > > > > ===================================================================== > > > > > > > > Disclaimer > > > > ---------- > > > > The contents of this message and any attachments are intended > > > > solely for the addressee's use and may be legally privileged and/or > > > > confidential information. This message may not be retained, > > > > distributed, copied or used if you are not he addressee of this > > > > message. If this message was sent to you in error, please notify > > > > the sender immediately by reply e-mail and then destroy the message > > > > and any copies thereof. > > > > > > > > Opinions, conclusions and other information in this message may be > > > > personal to the sender and is not that of Lando Technologies Africa > > > > or any of it's subsideries, associated companies or principals and > > > > is therefore not endorsed by any of the Lando groups of companies. > > > > Due to e-maill communication being insecure, Lando groups of > > > > companies do not guarantee confidentiality, security, accuracy or > > > > performance of the e-mail. Any liability for viruses is excluded > > > > to the fullest extent. > > > > > > > > > > > > > > > > > > -- > > > > > > Nigel Kukard (Chief Executive Officer) > > Lando Technologies Africa (Pty) Ltd > > nigel@lando.co.za www.lando.co.za > > Tel: 083 399 5822 Fax: 086 1100036 > > Hoheisen Park Bellville, Cape Town > > National Internet Service Provider > > > > > > The best language to use is the language that was designed for > > what you want to use it for - 1997 > > > > > > ===================================================================== > > > > Disclaimer > > ---------- > > The contents of this message and any attachments are intended > > solely for the addressee's use and may be legally privileged and/or > > confidential information. This message may not be retained, > > distributed, copied or used if you are not he addressee of this > > message. If this message was sent to you in error, please notify > > the sender immediately by reply e-mail and then destroy the message > > and any copies thereof. > > > > Opinions, conclusions and other information in this message may be > > personal to the sender and is not that of Lando Technologies Africa > > or any of it's subsideries, associated companies or principals and > > is therefore not endorsed by any of the Lando groups of companies. > > Due to e-maill communication being insecure, Lando groups of > > companies do not guarantee confidentiality, security, accuracy or > > performance of the e-mail. Any liability for viruses is excluded > > to the fullest extent. > > > > > > -- > 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 6: Have you searched our list archives? > > http://archives.postgresql.org >
Rocco Altier <RoccoA@Routescape.com> writes:
> Another idea is to have the -i take an optional argument. Something where
> -i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only
> v6.
I don't see why we need any such thing. The current behavior of the
postmaster (assuming -i or tcpip_socket is set) is:
1. By default: bind to all IPs on the machine.
2. If virtual_host is set: bind only to that one IP.
It seems to me that in a machine with both v4 and v6 IP addresses, the
natural extension is that the default behavior is to bind to all of
them, or if virtual_host is set then bind to only that one, be it v4 or
v6. (Does the existing patch work with virtual_host identifying a v6
IP? If not, that's certainly a bug.)
No one has offered any scenario in which it's important to bind to only
v4 or only v6 addresses when both are present. In the absence of a
compelling argument why that would be useful, I do not see why we're
worrying. My own thought is that if I wanted to constrain PG to bind
to a subset of a machine's addresses, the extension I'd want is to allow
virtual_host to contain a list of names or IP addresses --- of either
version. Basing it on v4 versus v6 has no payback that I can see.
regards, tom lane
--On Tuesday, January 07, 2003 11:51:44 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Rocco Altier <RoccoA@Routescape.com> writes: >> Another idea is to have the -i take an optional argument. Something >> where -i means bind to both v4 and v6, and -i4 means to only v4, and -i6 >> to only v6. > > I don't see why we need any such thing. The current behavior of the > postmaster (assuming -i or tcpip_socket is set) is: > > 1. By default: bind to all IPs on the machine. > > 2. If virtual_host is set: bind only to that one IP. > > It seems to me that in a machine with both v4 and v6 IP addresses, the > natural extension is that the default behavior is to bind to all of > them, or if virtual_host is set then bind to only that one, be it v4 or > v6. (Does the existing patch work with virtual_host identifying a v6 > IP? If not, that's certainly a bug.) > > No one has offered any scenario in which it's important to bind to only > v4 or only v6 addresses when both are present. In the absence of a > compelling argument why that would be useful, I do not see why we're > worrying. My own thought is that if I wanted to constrain PG to bind > to a subset of a machine's addresses, the extension I'd want is to allow > virtual_host to contain a list of names or IP addresses --- of either > version. Basing it on v4 versus v6 has no payback that I can see. Please make sure that you can handle the situation of a IPv6 API, but no IPv6 stack. (E.G. UnixWare up to at least 7.1.3). > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman <ler@lerctr.org> writes:
> Please make sure that you can handle the situation of a IPv6 API, but no
> IPv6 stack. (E.G. UnixWare up to at least 7.1.3).
Certainly. But that is just an autoconfiguration problem. If a v6 IP
address is available, we should bind to it.
regards, tom lane
Tom Lane wrote: > Rocco Altier <RoccoA@Routescape.com> writes: > > Another idea is to have the -i take an optional argument. Something where > > -i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only > > v6. > > I don't see why we need any such thing. The current behavior of the > postmaster (assuming -i or tcpip_socket is set) is: > > 1. By default: bind to all IPs on the machine. > > 2. If virtual_host is set: bind only to that one IP. > > It seems to me that in a machine with both v4 and v6 IP addresses, the > natural extension is that the default behavior is to bind to all of > them, or if virtual_host is set then bind to only that one, be it v4 or > v6. (Does the existing patch work with virtual_host identifying a v6 > IP? If not, that's certainly a bug.) > > No one has offered any scenario in which it's important to bind to only > v4 or only v6 addresses when both are present. In the absence of a > compelling argument why that would be useful, I do not see why we're > worrying. My own thought is that if I wanted to constrain PG to bind > to a subset of a machine's addresses, the extension I'd want is to allow > virtual_host to contain a list of names or IP addresses --- of either > version. Basing it on v4 versus v6 has no payback that I can see. The issue was that folks didn't like silent fallback to just IPv4 if the code supported IPv6 but it didn't bind to IPv6 for some reason, e.g. kernel doesn't have IPv6 enabled. Right now it puts a message in the server logs, but others wanted some specific way to enable IPv6 and fail if it didn't work. They want something that says "I want IPv6 and I don't want to start if it doesn't start." Right now if we do -i, and tcpip doesn't start, be bomb out. They want that for IPv6, and the tricky part is we can't enable that by default because many systems have the API but no kernel support. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Larry Rosenman wrote: > > No one has offered any scenario in which it's important to bind to only > > v4 or only v6 addresses when both are present. In the absence of a > > compelling argument why that would be useful, I do not see why we're > > worrying. My own thought is that if I wanted to constrain PG to bind > > to a subset of a machine's addresses, the extension I'd want is to allow > > virtual_host to contain a list of names or IP addresses --- of either > > version. Basing it on v4 versus v6 has no payback that I can see. > > Please make sure that you can handle the situation of a IPv6 API, but no > IPv6 > stack. (E.G. UnixWare up to at least 7.1.3). Already done. My BSD/OS is that way in the default kernel configuration too. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
--On Tuesday, January 07, 2003 12:07:05 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Larry Rosenman <ler@lerctr.org> writes: >> Please make sure that you can handle the situation of a IPv6 API, but no >> IPv6 stack. (E.G. UnixWare up to at least 7.1.3). > > Certainly. But that is just an autoconfiguration problem. If a v6 IP > address is available, we should bind to it. Agreed, but I wanted to at least make sure the issue was known. The Apache guys had to put a special check in for UnixWare since we die in a different way. I can show you the patch if y'all want. > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Tom Lane wrote: > Larry Rosenman <ler@lerctr.org> writes: > > Please make sure that you can handle the situation of a IPv6 API, but no > > IPv6 stack. (E.G. UnixWare up to at least 7.1.3). > > Certainly. But that is just an autoconfiguration problem. If a v6 IP > address is available, we should bind to it. We already do. The issue is what way should we give admins to _fail_ if IPv6 doesn't start. Maybe just a postgresql.conf setting, "exit_on_ipv6_failure" or something like that. It unlinks the param to the -i/tcpip_socket functionality. However, it doesn't give us a way to do IPv4 only if the server supports IPv6 too, or to do IPv6 only. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The issue was that folks didn't like silent fallback to just IPv4 if the
> code supported IPv6 but it didn't bind to IPv6 for some reason, e.g.
> kernel doesn't have IPv6 enabled.
Who didn't like it, and what was their rationale? This seems to me to
be equivalent to expecting Postgres to list out every IP address in the
world *except* the ones it was able to bind to. That's silly.
If the system does not support IPv6, there will be no v6 address
available to bind to. It is not going to startle anyone when we do
not bind to an IPv6 address on such a machine.
> Right now it puts a message in the
> server logs, but others wanted some specific way to enable IPv6 and fail
> if it didn't work.
Pure noise, and a useless "feature".
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> We already do. The issue is what way should we give admins to _fail_ if
> IPv6 doesn't start.
What is "IPv6 doesn't start"? Either the machine has IPv6 addresses,
or it doesn't. It is not our job to notify the DBA what the addresses
on his machine are.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > The issue was that folks didn't like silent fallback to just IPv4 if the > > code supported IPv6 but it didn't bind to IPv6 for some reason, e.g. > > kernel doesn't have IPv6 enabled. > > Who didn't like it, and what was their rationale? This seems to me to Peter was the first to mention it. His reasoning was that if IPv6 was working, but then stopped working, the admin would never know on startup because of the IPv4 fallback. > be equivalent to expecting Postgres to list out every IP address in the > world *except* the ones it was able to bind to. That's silly. > > If the system does not support IPv6, there will be no v6 address > available to bind to. It is not going to startle anyone when we do > not bind to an IPv6 address on such a machine. > > > Right now it puts a message in the > > server logs, but others wanted some specific way to enable IPv6 and fail > > if it didn't work. > > Pure noise, and a useless "feature". Again, that info is for the admin so they have some feedback that we aren't using IPv6, even though IPv6 addresses appear in pg_hba.conf (only because we had the IPv6 API). -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
--On Tuesday, January 07, 2003 12:20:31 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: >> We already do. The issue is what way should we give admins to _fail_ if >> IPv6 doesn't start. > > What is "IPv6 doesn't start"? Either the machine has IPv6 addresses, > or it doesn't. It is not our job to notify the DBA what the addresses > on his machine are. In the UnixWare case, you can't even find out if there is an IPv6 address, and the API returns a wierd error, IIRC. > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > We already do. The issue is what way should we give admins to _fail_ if > > IPv6 doesn't start. > > What is "IPv6 doesn't start"? Either the machine has IPv6 addresses, > or it doesn't. It is not our job to notify the DBA what the addresses > on his machine are. You can fight it out with Peter. I have no problem silently falling back to IPv4 if people are happy with that. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Larry Rosenman wrote: > > > --On Tuesday, January 07, 2003 12:20:31 -0500 Tom Lane <tgl@sss.pgh.pa.us> > wrote: > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> We already do. The issue is what way should we give admins to _fail_ if > >> IPv6 doesn't start. > > > > What is "IPv6 doesn't start"? Either the machine has IPv6 addresses, > > or it doesn't. It is not our job to notify the DBA what the addresses > > on his machine are. > In the UnixWare case, you can't even find out if there is an IPv6 address, > and > the API returns a wierd error, IIRC. I don't think we care about how IPv6 fails in our code --- we just fall back to IPv4. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
--On Tuesday, January 07, 2003 12:24:41 -0500 Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Larry Rosenman wrote: >> >> >> --On Tuesday, January 07, 2003 12:20:31 -0500 Tom Lane >> <tgl@sss.pgh.pa.us> wrote: >> >> > Bruce Momjian <pgman@candle.pha.pa.us> writes: >> >> We already do. The issue is what way should we give admins to _fail_ >> >> if IPv6 doesn't start. >> > >> > What is "IPv6 doesn't start"? Either the machine has IPv6 addresses, >> > or it doesn't. It is not our job to notify the DBA what the addresses >> > on his machine are. >> In the UnixWare case, you can't even find out if there is an IPv6 >> address, and >> the API returns a wierd error, IIRC. > > I don't think we care about how IPv6 fails in our code --- we just fall > back to IPv4. Ok, just checking. IIRC, apache2 refused to start BECAUSE of the this return prior to Jeff Trawick's change of the check. If someone wants to try it, I can generate an account. (Peter E. already has one). the machine is finally running a released OS again :-). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Bruce Momjian writes: > Peter was the first to mention it. His reasoning was that if IPv6 was > working, but then stopped working, the admin would never know on startup > because of the IPv4 fallback. My view was that we should treat unix, ipv4, and ipv6 as independent address families each with their own on/off switch (except that unix doesn't have an off switch). Tom's view is that we should treat ipv4 and ipv6 as effectively one address family. That makes sense, too, and it is probably more with the spirit of IPv6. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Peter was the first to mention it. His reasoning was that if IPv6 was > > working, but then stopped working, the admin would never know on startup > > because of the IPv4 fallback. > > My view was that we should treat unix, ipv4, and ipv6 as independent > address families each with their own on/off switch (except that unix > doesn't have an off switch). Tom's view is that we should treat ipv4 and > ipv6 as effectively one address family. That makes sense, too, and it is > probably more with the spirit of IPv6. OK, Peter, to keep you and everyone happy, what changes are your proposing to the existing code, if any. The only current behavior is printing an IPv6 failure for IPv6-enabled backend in the server logs. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian writes: > OK, Peter, to keep you and everyone happy, what changes are your > proposing to the existing code, if any. The only current behavior is > printing an IPv6 failure for IPv6-enabled backend in the server logs. Just bind to all addresses you can find, IPv4 or IPv6. And leave pg_hba.conf alone. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > OK, Peter, to keep you and everyone happy, what changes are your > > proposing to the existing code, if any. The only current behavior is > > printing an IPv6 failure for IPv6-enabled backend in the server logs. > > Just bind to all addresses you can find, IPv4 or IPv6. And leave > pg_hba.conf alone. OK, you mentioned you want to put IPv6 addresses in pg_hba.conf even if the OS doesn't support it. How do others feel about that. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian writes: > OK, you mentioned you want to put IPv6 addresses in pg_hba.conf even if > the OS doesn't support it. How do others feel about that. We do leave the "local" in there even if the OS doesn't support it. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > OK, you mentioned you want to put IPv6 addresses in pg_hba.conf even if > > the OS doesn't support it. How do others feel about that. > > We do leave the "local" in there even if the OS doesn't support it. Good point. I will have the IPv6 be in there all the time. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
OK, at your suggestion, IPv6 addresses will appear in pg_hba.conf, even if we don't support IPv6. However, the server log messages stating an IPv6 socket was not made is only printed if the binary supports IPv6. The message seems to be a compromise between those who wanted a separate IPv6 GUC/flag and those who wanted it to silently fail on IPv6. --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > OK, you mentioned you want to put IPv6 addresses in pg_hba.conf even if > > the OS doesn't support it. How do others feel about that. > > We do leave the "local" in there even if the OS doesn't support it. > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- 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 Index: src/backend/Makefile =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/Makefile,v retrieving revision 1.92 diff -c -c -r1.92 Makefile *** src/backend/Makefile 7 Jan 2003 15:12:17 -0000 1.92 --- src/backend/Makefile 26 Jan 2003 01:17:32 -0000 *************** *** 132,145 **** endif endif $(MAKE) -C catalog install-data - ifdef HAVE_IPV6 $(INSTALL_DATA) $(srcdir)/libpq/pg_hba.conf.sample $(DESTDIR)$(datadir)/pg_hba.conf.sample - else - grep -v '^host.*::1.*ffff:ffff:ffff:ffff:ffff:ffff' \ - $(srcdir)/libpq/pg_hba.conf.sample \ - > $(srcdir)/libpq/pg_hba.conf.sample.no_ipv6 - $(INSTALL_DATA) $(srcdir)/libpq/pg_hba.conf.sample.no_ipv6 $(DESTDIR)$(datadir)/pg_hba.conf.sample - endif $(INSTALL_DATA) $(srcdir)/libpq/pg_service.conf.sample $(DESTDIR)$(datadir)/pg_service.conf.sample $(INSTALL_DATA) $(srcdir)/libpq/pg_ident.conf.sample $(DESTDIR)$(datadir)/pg_ident.conf.sample $(INSTALL_DATA) $(srcdir)/utils/misc/postgresql.conf.sample $(DESTDIR)$(datadir)/postgresql.conf.sample --- 132,138 ---- *************** *** 191,199 **** rm -f postgres$(X) $(POSTGRES_IMP) \ $(top_srcdir)/src/include/parser/parse.h \ $(top_builddir)/src/include/utils/fmgroids.h - ifndef HAVE_IPV6 - rm -f $(srcdir)/libpq/pg_hba.conf.sample.no_ipv6 - endif ifeq ($(PORTNAME), win) rm -f postgres.dll postgres.def libpostgres.a endif --- 184,189 ----
Bruce Momjian writes: > However, the server log messages stating an IPv6 socket was not made is > only printed if the binary supports IPv6. The message seems to be a > compromise between those who wanted a separate IPv6 GUC/flag and those > who wanted it to silently fail on IPv6. I'm not sure. Those who wanted silence don't get any silence and those who wanted a configurable hard failure get neither the configurability nor any failure. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > However, the server log messages stating an IPv6 socket was not made is > > only printed if the binary supports IPv6. The message seems to be a > > compromise between those who wanted a separate IPv6 GUC/flag and those > > who wanted it to silently fail on IPv6. > > I'm not sure. Those who wanted silence don't get any silence and those > who wanted a configurable hard failure get neither the configurability nor > any failure. That is the compromise. Neither gets what they want, but the final solution is closer to each. This is probably the best we can do. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> > > However, the server log messages stating an IPv6 socket was > not made is > > > only printed if the binary supports IPv6. The message seems to be a > > > compromise between those who wanted a separate IPv6 GUC/flag and those > > > who wanted it to silently fail on IPv6. > > > > I'm not sure. Those who wanted silence don't get any silence and those > > who wanted a configurable hard failure get neither the > configurability nor > > any failure. > > That is the compromise. Neither gets what they want, but the final > solution is closer to each. This is probably the best we can do. BTW guys, there was strong demand at Linux.conf.au asking for the 'inet' type to support IPv6 addresses. I've been looking at it a bit, but I'll have to interleave it with my work on phpPgAdmin 3 (which rocks BTW :) ). Chris
Christopher Kings-Lynne wrote: > > > > However, the server log messages stating an IPv6 socket was > > not made is > > > > only printed if the binary supports IPv6. The message seems to be a > > > > compromise between those who wanted a separate IPv6 GUC/flag and those > > > > who wanted it to silently fail on IPv6. > > > > > > I'm not sure. Those who wanted silence don't get any silence and those > > > who wanted a configurable hard failure get neither the > > configurability nor > > > any failure. > > > > That is the compromise. Neither gets what they want, but the final > > solution is closer to each. This is probably the best we can do. > > BTW guys, there was strong demand at Linux.conf.au asking for the 'inet' > type to support IPv6 addresses. I've been looking at it a bit, but I'll > have to interleave it with my work on phpPgAdmin 3 (which rocks BTW :) ). I had someone on the IPv6 IRC channel interested, but haven't seen any patch yet. It isn't that hard to do. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Mon, 2003-01-27 at 20:19, Bruce Momjian wrote: > I had someone on the IPv6 IRC channel interested, but haven't seen any > patch yet. It isn't that hard to do. If we cleanly split the Postgres-specific code from the stuff that's been imported from BIND, shouldn't it be easy to import new versions, and thus get IPv6 support for free? Or at least, that's what I vaguely recall Paul Vixie saying on pgsql-patches a while ago: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=200202221828.g1MISX102055%40candle.pha.pa.us&rnum=2&prev=/groups%3Fq%3Dpaul%2Bvixie%2Bgroup:comp.databases.postgresql.patches%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D200202221828.g1MISX102055%2540candle.pha.pa.us%26rnum%3D2 Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
That is _exactly_ how it has to be done. --------------------------------------------------------------------------- Neil Conway wrote: > On Mon, 2003-01-27 at 20:19, Bruce Momjian wrote: > > I had someone on the IPv6 IRC channel interested, but haven't seen any > > patch yet. It isn't that hard to do. > > If we cleanly split the Postgres-specific code from the stuff that's > been imported from BIND, shouldn't it be easy to import new versions, > and thus get IPv6 support for free? > > Or at least, that's what I vaguely recall Paul Vixie saying on > pgsql-patches a while ago: > > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=200202221828.g1MISX102055%40candle.pha.pa.us&rnum=2&prev=/groups%3Fq%3Dpaul%2Bvixie%2Bgroup:comp.databases.postgresql.patches%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D200202221828.g1MISX102055%2540candle.pha.pa.us%26rnum%3D2 > > Cheers, > > Neil > -- > Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC > > > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Neil Conway <neilc@samurai.com> writes:
> If we cleanly split the Postgres-specific code from the stuff that's
> been imported from BIND, shouldn't it be easy to import new versions,
> and thus get IPv6 support for free?
IIRC, the issue was that we'd painfully hammered out a set of preferred
I/O behaviors for the inet and cidr datatypes, and then hacked up the
code we'd imported from BIND to make it happen. Paul Vixie sent in a
patch that replaced the imported code with v6-aware BIND code ---
thereby reverting those painfully-agreed-to patches. So it got
rejected.
I have no problem with restructuring our I/O behavior as wrappers around
the pristine BIND routines; although privately I doubt it's worth the
trouble. The really interesting part of upgrading to v6 inet support is
going to be obtaining a consensus on how our current I/O behaviors should
translate to v6 addresses. Once we have that, I suspect that slash-and-
burn mods on the BIND code will again be the way to go ;-). It's not
like v6 is going to be replaced in the foreseeable future.
regards, tom lane
Tom Lane wrote: > Neil Conway <neilc@samurai.com> writes: > > If we cleanly split the Postgres-specific code from the stuff that's > > been imported from BIND, shouldn't it be easy to import new versions, > > and thus get IPv6 support for free? > > IIRC, the issue was that we'd painfully hammered out a set of preferred > I/O behaviors for the inet and cidr datatypes, and then hacked up the > code we'd imported from BIND to make it happen. Paul Vixie sent in a > patch that replaced the imported code with v6-aware BIND code --- > thereby reverting those painfully-agreed-to patches. So it got > rejected. > > I have no problem with restructuring our I/O behavior as wrappers around > the pristine BIND routines; although privately I doubt it's worth the > trouble. The really interesting part of upgrading to v6 inet support is > going to be obtaining a consensus on how our current I/O behaviors should > translate to v6 addresses. Once we have that, I suspect that slash-and- > burn mods on the BIND code will again be the way to go ;-). It's not > like v6 is going to be replaced in the foreseeable future. Yes, we need to keep merge the changes we made to the original IPv4 code into IPv6. IPv6 seems to be maturing a little so if we can keep the bind stuff pretty similar and just call it, that would be nice too. Seems someone has to do the legwork and see what is involved. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073