Re: [HACKERS] IPv6 patch
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
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 [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] IPv6 patch
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] IPv6 patch
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 [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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch
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=enlr=ie=UTF-8threadm=200202221828.g1MISX102055%40candle.pha.pa.usrnum=2prev=/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 [EMAIL PROTECTED] || PGP Key ID: DB3C29FC -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch
Neil Conway [EMAIL PROTECTED] 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 ---(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] IPv6 patch
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] 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 [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/users-lounge/docs/faq.html
Re: [HACKERS] IPv6 patch
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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 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/Makefile7 Jan 2003 15:12:17 - 1.92 --- src/backend/Makefile26 Jan 2003 01:17:32 - *** *** 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.*:::::' \ - $(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 ---(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] IPv6 patch
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch
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 [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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] IPv6 patch
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 [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 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] IPv6 patch
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] www.lando.co.za Tel: 083 399 5822 Fax: 086 1100036
Re: [HACKERS] IPv6 patch
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 [EMAIL PROTECTED] 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
Re: [HACKERS] IPv6 patch
Rocco Altier [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
--On Tuesday, January 07, 2003 11:51:44 -0500 Tom Lane [EMAIL PROTECTED] wrote: Rocco Altier [EMAIL PROTECTED] 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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
Larry Rosenman [EMAIL PROTECTED] 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 ---(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] IPv6 patch
Tom Lane wrote: Rocco Altier [EMAIL PROTECTED] 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 [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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch
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 [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] IPv6 patch
--On Tuesday, January 07, 2003 12:07:05 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] 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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch
Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] 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 [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] IPv6 patch
Bruce Momjian [EMAIL PROTECTED] 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 ---(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] IPv6 patch
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [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] IPv6 patch
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] IPv6 patch
Larry Rosenman wrote: --On Tuesday, January 07, 2003 12:20:31 -0500 Tom Lane [EMAIL PROTECTED] wrote: Bruce Momjian [EMAIL PROTECTED] 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 [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] IPv6 patch
--On Tuesday, January 07, 2003 12:24:41 -0500 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: --On Tuesday, January 07, 2003 12:20:31 -0500 Tom Lane [EMAIL PROTECTED] wrote: Bruce Momjian [EMAIL PROTECTED] 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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] IPv6 patch
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 [EMAIL PROTECTED] ---(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] IPv6 patch
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 [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] IPv6 patch
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
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 [EMAIL PROTECTED] Copeland Computer Consulting ---(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] IPv6 patch
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 [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/users-lounge/docs/faq.html
Re: [HACKERS] IPv6 patch
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? -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch
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 [EMAIL PROTECTED] Copeland Computer Consulting ---(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] IPv6 patch
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 [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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] IPv6 patch
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 [EMAIL PROTECTED] Copeland Computer Consulting ---(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] IPv6 patch
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 [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/users-lounge/docs/faq.html
Re: [HACKERS] IPv6 patch
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 [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
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 [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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] IPv6 patch
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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
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 [EMAIL PROTECTED] 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 [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 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] IPv6 patch
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 [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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch rejected
I didn't read my email this weekend, so I am sorry to be late getting back to you on this. First, let me say I am excited about this patch. Several people have asked for IPv6 support, but you are the first person to actually submit a patch for it. I want to comment on the patch a bit because IPv6 is usually a difficult feature to add, considering the many platforms we support. First, I am running BSD/OS, so I have the bind 8.2.3 Inet routines in my libc. However, I do not have IPv6 enabled in my kernel. Your patch will have to deal with such systems, _and_ platforms that don't support IPv6 at all. It appears the patch does a few things: changes comparison of port-raddr.sa.sa_family == AF_INET to call to a new function isAF_INETx changes inet_aton() call to a new function SockAddr_pton() extensively modifies StreamServerPort adds modifies StreamServerPortSubAFUNIX1/2 modifies connectDBStart To better integrate your patch, I have: reformatted to fit our coding style renamed file v6utils.c to ipv6.c removed 'configure' link code to use Makefile link like md5.c added code to create IPv4 port if IPv6 port creation fails I need to continue reviewing the code and add a configure test to determine if IPv6 can compile on the machine. The fallback to IPv4 should be fine on machines that don't have IPv6 in their kernels. The current patch can be downloaded from: ftp://candle.pha.pa.us/pub/postgresql/mypatches/ipv6 --- Nigel Kukard wrote: Hrmmm, Is the compiling or running of postgresql a problem? if its the compiling we could add #ifdef's maybe to check if we have INET6 support... or even add it to the configure.in, if its running of postgresql which is the problem i have no clue how to get around that. thoughts? On Fri, 6 Dec 2002, Bruce Momjian wrote: I now have the INETv6 patch working using IPv4 on my machine, and I don't have IPv6 enabled in my kernel. Tomorrow, I will review the entire patch for portability issues, then post it so others can test it. I am pretty sure it is going to fail if your machine isn't INET6 aware, which may be many. --- The INETv6 patch was rejected because of this report, and an error on postmaster startup from BSD/OS: LOG: FATAL: StreamServerPort: getaddrinfo2() failed: hostname nor servname provided, or not known Please submit a new patch that addresses these issues. I can work with you to do testing. --- Joe Conway wrote: Bruce Momjian wrote: Fixing now. This just isn't my night --- another patch with a missing file. OK - I can run configure and make now, but I'm getting these warnings: In file included from ../../../../src/include/libpq/libpq.h:22, from printtup.c:20: ../../../../src/include/libpq/v6util.h:3: warning: `struct addrinfo' declared inside parameter list ../../../../src/include/libpq/v6util.h:3: warning: its scope is only this definition or declaration, which is probably not what you want. ../../../../src/include/libpq/v6util.h:5: warning: `struct addrinfo' declared inside parameter list lots of similar warnings to the above -- and: auth.c: In function `ClientAuthentication': auth.c:414: warning: passing arg 1 of `isAF_INETx' from incompatible pointer type gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o crypt.o crypt.c -MMD In file included from ../../../src/include/libpq/libpq.h:22, from crypt.c:24: Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Nigel Kukard (Chief Executive Officer) Lando Technologies Africa (Pty) Ltd [EMAIL PROTECTED] 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
Re: [HACKERS] IPv6 patch rejected
Bruce Momjian [EMAIL PROTECTED] writes: I am pretty sure it is going to fail if your machine isn't INET6 aware, which may be many. That's definitely not gonna do :-( regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch rejected
I now have the INETv6 patch working using IPv4 on my machine, and I don't have IPv6 enabled in my kernel. Tomorrow, I will review the entire patch for portability issues, then post it so others can test it. I am pretty sure it is going to fail if your machine isn't INET6 aware, which may be many. --- The INETv6 patch was rejected because of this report, and an error on postmaster startup from BSD/OS: LOG: FATAL: StreamServerPort: getaddrinfo2() failed: hostname nor servname provided, or not known Please submit a new patch that addresses these issues. I can work with you to do testing. --- Joe Conway wrote: Bruce Momjian wrote: Fixing now. This just isn't my night --- another patch with a missing file. OK - I can run configure and make now, but I'm getting these warnings: In file included from ../../../../src/include/libpq/libpq.h:22, from printtup.c:20: ../../../../src/include/libpq/v6util.h:3: warning: `struct addrinfo' declared inside parameter list ../../../../src/include/libpq/v6util.h:3: warning: its scope is only this definition or declaration, which is probably not what you want. ../../../../src/include/libpq/v6util.h:5: warning: `struct addrinfo' declared inside parameter list lots of similar warnings to the above -- and: auth.c: In function `ClientAuthentication': auth.c:414: warning: passing arg 1 of `isAF_INETx' from incompatible pointer type gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o crypt.o crypt.c -MMD In file included from ../../../src/include/libpq/libpq.h:22, from crypt.c:24: Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Nigel Kukard (Chief Executive Officer) Lando Technologies Africa (Pty) Ltd [EMAIL PROTECTED] 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 [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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
