On at least _some_ Linux kernels (I'm running 2.4.20-gentoo-r9) apache-2.0.49 generates an error regarding an IPv6 address in the installed conf file and fails to start. While disabling IPv6 in apache solves the problem, a better solution is the application of the appended patch which allows apache to actually use IPv6. See the referenced URL for a further discussion of the issue. I posted a comment to bug #32389 on this issue but apparently it was overlooked. While IMHO this ought to be fixed in the distributed gentoo ebuild, anyone wanting to fix the problem w.o. waiting for the fix to come down the pike should see bug #32389 and follow the directions therein, substituting the following patch and "2.0.49" for "2.0.48" wherever appropriate.
Created attachment 27964 [details, diff] This patch fixes the IPv6 problem described above
before I include this patch, does it break kernels that DO have functional IPv6 where apache works with IPv6 already?
I can't answer this since all my gentoo systems run on gentoo-sources of one flavor or another. There are 2.4 kernels patched for enhanced IPv6 performance that apparently don't have the problem, and I understand that 2.6 kernels have substantially improved IPv6 performance, and I don't know if the patch will affect them or not. My understanding, from Fabio Massimo Di Nitto's comments, is that this particular piece of code came upstream to address a BSD issue. If you haven't done so, you might want to review the entire message thread at <http://lists.debian.org/debian-apache/2003/debian-apache-200311/msg00109.html>. I'll email Joey Hess and see if he has an answer to this question, and post any information I get from him.
I wrote Joey Hess about this. Looks like they've gone with this fix in Debian. Here's what he said. "All I know is that after I ran into the problem, our apache maintainer Fabio Massimo Di Nitto <fabbione@fabbione.net> removed the code or whatever, and presumably it's not caused any large problems to leave it out, since I've not noticed him putting it back in. For details, you should probably talk to Fabio." I've written to Fabio but haven't heard back. I'll post if and when I do.
Here's what's done with apache-2.0.48 in Debian testing. This is a patch->patch so it has double indicators. It's from Debian apache2_2.0.48-8.diff.gz +--- build-tree.orig/apache2/server/listen.c 2003-03-31 05:30:52.000000000 +0100 ++++ build-tree/apache2/server/listen.c 2003-11-12 13:39:07.000000000 +0000 +@@ -117,6 +117,7 @@ + return stat; + } + ++#ifndef __linux__ + #if APR_HAVE_IPV6 + if (server->bind_addr->family == APR_INET6) { + stat = apr_socket_opt_set(s, APR_IPV6_V6ONLY, v6only_setting); +@@ -129,8 +130,9 @@ + return stat; + } + } +-#endif +- ++#endif /* APR_HAVE_IPV6 */ ++#endif /* __linux__ */ ++ + /* + * To send data over high bandwidth-delay connections at full + * speed we must force the TCP window to open wide enough to keep the This puts the code in question in a preprocessor conditional block that includes it only if the target system is not Linux, which accomplishes much the same thing as simply patching it out, but leaves the option open of including it on on a non-Linux build. I haven't heard back from Fabio, but it looks as if he's confident enough that the answer to Robin's question is 'no' that he's put it in the Debian mods.
I heard back from Fabio (Debian apache maintiner) on this. Here's his email. Robin, I know you got this but ipv6@gentoo.org may not have it. Date: Mon, 29 Mar 2004 04:46:05 +0200 (CEST) From: Fabio Massimo Di Nitto <fabbione@debian.org> To: fmouse-y43nof@fmp.com Cc: robbat2@gentoo.org Subject: Re: Bug#220334: upgrade hoses apache2, weird ipv6 error message Hi all, On Wed, 24 Mar 2004, Lindsay Haisley wrote: > Fabio, > > In reference to the apache/IPv6 bug about which you corresponded with > Joey Hess last November > (http://lists.debian.org/debian-apache/2003/debian-apache-200311/msg00109.html), > do you know if the problem code cited is specific to BSD, or is it > required for proper operation under any Linux kernels? > > I'm trying to do a bit of follow up on a bug I posted to the Gentoo bug > tracking system, since this problem is still present in apache 2.0.49. > The Gentoo apache build maintainer needs to know if eliminating this > particular section of code might have any negative impact on apache > functionality on other Linux kernels which have improved IPv6 stacks > (e.g. the 2.6 kernels). Any insight on this issue will be appreciated. The problem is a bit more complex to explain than it looks like. The issue is related to the different ways in which linux kernels and bsd kernels handle sockets on ipv6 and ipv4. The BSD kernel in this case is to be considered sane. It's behaviour is to provide indipendent binding for both the protocols. In a few words you need to have 2 sockets to listen, one for ipv6 and one for ipv4 and they are on their own. On Linux the situation is a bit more complicate. Old kernels (iirc prior 2.4.21 when usagi patch was basically merged) were able to listen on ipv6 and ipv4 using one single socket on ipv6. This is still the default on 2.6 but the main difference is that now is user configurable via proc interface (/proc/sys/net/ipv6/bindv6only) so for example if you set that value to 0 (default) than your application will be able to listen on ipv6 and ipv4 using only one socket (that would make that piece of code somehow breaking on linux), and if you set that value to 1 (as in the BSD default) your application will require 2 sockets to listen (and that piece of code would be somehow mandatory). Regarding the specific problem instead I would say that the code in apache2 is correct. On Debian we fixed it using a simple #if #endif wrapper (https://svn.clearairturbulence.org/apache2/trunk/debian/patches/017_fix_ipv6) but i think that would apply easily to gentoo too. Take into account that only a few ipv6 hackers would set that options to 1 since all applications that compiles on linux would expect that to be 0 and most of them would require either reconfiguration or recompilation with some linux specific code commented out (since a lot of them have specific hacks to handle the differnt kernels behavior). I hope this is what you are searching for... in case you need more information let me know. Fabio -- <user> fajita: step one <fajita> Whatever the problem, step one is always to look in the error log. <user> fajita: step two <fajita> When in danger or in doubt, step two is to scream and shout.
This should be fixed in 2.0.49-r1. Thanks for the bug report.
