= Proposal topic =
For many years now, it has been expected that packages in Fedora will work properly with IPv6 ''"out of the box"''. ISTR this has been true since the RHL days, even before Fedora Core.
We last did a 'bombing run' through Fedora packages in about 2006, with the 'tracker' bug [https://bugzilla.redhat.com/show_bug.cgi?id=195271 #195271]. Five years later, I'm '''shocked''' to find that any Fedora package maintainer thinks that it's acceptable for their package not to be IPv6-capable "out of the box".
Unfortunately, the vsftpd package suffers exactly this problem. For a long time it just needed a simple change in its config file — setting the 'listen_ipv6' option to yes would also listen on Legacy IP and everything would fine. A bug ([https://bugzilla.redhat.com/show_bug.cgi?id=450853 #450853]) was filed in 2008 reporting the problem and suggesting that the shipped configuration file be changed, but the bug was never fixed.
I forgot about the bug until recently, since the configuration change had been made locally on my FTP servers and it continued to work fine.
However, on upgrading to Fedora 15 a regression was introduced — the configuration which had been working since 2008 (when I switched to vsftpd, iirc) was broken by a patch which is present in the Fedora package, to make vsftpd use the IPV6_V6ONLY sockopt. This means that you can no longer listen on IPv6 and Legacy IP simultaneously, and have to play complicated tricks; the recommendation seems to be that you run '''two''' instances of the vsftpd dæmon with two separate configurations, but the package '''still''' doesn't support that mode of operation out-of-the-box.
Although it is expected that Fedora packages will work correctly with IPv6, the maintainer evidently does not want vsftpd to conform to Fedora's (unwritten) policy. He says that ''"[https://bugzilla.redhat.com/show_bug.cgi?id=450853#c14 IPv6 will be set by default when the major part of traffic is via IPv6.]"''
I believe the best way to proceed is for FESCo to provide clear guidelines to packagers (and to this packager in particular) that IPv6 '''SHOULD''' be supported out of the box in Fedora packages.
= Overview =
Packaging guidelines should clearly state that Fedora packages '''SHOULD''' support IPv6 connectivity (unless the upstream package is really not capable of it and fixing it is beyond the capabilities of the packager).
= Problem space =
The problem is that Fedora packages seem to be inconsistent. We '''used''' to be able to say, ''"if you use Fedora, everything should Just Work for IPv6"''. But with basic networking dæmons like vsftpd refusing to work properly, that is no longer true. That's a very bad thing.
= Solution Overview =
By fixing the package(s) that are broken :)
For the specific case of vsftpd, I don't mind too much '''how''' it's fixed, as long as it's fixed. Options include: * Using xinetd instead of running as a dæmon at all. * Shipping with two config files and two init scripts; one for IPv6 and one for Legacy IP. * Reverting the IPV6_V6ONLY patch and setting 'listen_ipv6' in the default config file. * The more complicated patches which the package maintainer says he's been working on.
Any of the above would be acceptable, as long as vsftpd (when enabled) is working for '''both''' IPv6 and Legacy IP out of the box in Fedora.
= Active Ingredients =
Package maintainers / Package guidelines are affected by this proposal.
= Owners =
dwmw2
A couple of remmarks to vsftpd/vsftpd.conf:
The man page says "... listen and listen_ipv6 are mutually exclusive."
Why exclusive? Exclusivity provides ability to split trafic between/among NICs. This corresponds to the other supported options of vsftpd:
listen_address listen_address6 listen_port
On the contrary listening both IPv4 and IPv6 is usefull too. Therefore I've prepared a patch that was sent to upstream. Unfortunatelly no reaction about acceptance from upstream. This easy patch obsoletes 'listen_ipv6' and replaces possible values { no, yes } of 'listen' option by { inet, ipv4, ipv6, both }.
There is one more solution to unblock setting 'listen' and 'listen_ipv6' to 'YES' at the same time (currently blocked). Unfortunately this is is not so transparent for users. This change would affect current code the same way as the previous patch.
Replying to [comment:3 jskala]:
A couple of remmarks to vsftpd/vsftpd.conf: The man page says "... listen and listen_ipv6 are mutually exclusive."
That's true, and fine, and until the Fedora package was patched with vsftpd-2.2.2-v6only.patch you could always listen on '''just''' an IPv6 socket and that would accept Legacy IP connections too.
So everything worked as we would expect it to work in Fedora, and all we really needed to do was enable 'listen_ipv6' instead of 'listen' in the default config file.
Why exclusive? Exclusivity provides ability to split trafic between/among NICs. This corresponds to the other supported options of vsftpd: listen_address listen_address6 listen_port
I don't understand why you think the listen/listen_ipv6 options would be needed to provide exclusivity. As you point out, we have the listen_address options for that. If I really wanted two separate dæmons on ftp.infradead.org, I could happily configure one of them with a listen_address of 85.118.1.10 and another one for 2001:770:15f::2. If listening on a specific unicast address instead of :: ''(which is the IPv6 equivalent of 0.0.0.0)'', an IPv6 socket won't accept Legacy IP connections anyway.
There's no need to stop listening IPv6 sockets from accepting Legacy IP connections. I can't see any justification for the patch in the Fedora package.
But really, I don't mind '''how''' the problem is fixed, as long as it '''is''' fixed, and the Fedora package for vsftpd correctly listens on both IPv6 and Legacy IP by default.
That's the point of filing this ticket and asking FESCo for clarification of the expectations; technical discussion of the specific issue at hand should probably live in bugzilla.
FESCo agrees that software SHOULD support both ipv4/ipv6 when such support is available from upstream. Will ask FPC to codify that into the guidelines.
An update has been pushed, but as noted in [https://bugzilla.redhat.com/show_bug.cgi?id=450853#c22 the bug] it doesn't seem to fix the problem. Was it even tested? All you have to do is a clean install of vsftpd, start it, and try to connect to it over IPv6.
I've filed an alternative patch which '''should''' work.
Of course, It was tested. I've removed complained patch. The vsftpd is able to handle IPv4 via IPv6 when the system has assigned IPv6 address.
Now it's in accordance with upstream.
I didn't set listen_ipv6 by default (listen is by default in upstream version) because this would affect all IPv4 users that has no IPv6 address.
The title of the bug is ''vsftpd doesn't listen on IPv6 by default''.
The most basic testing shows that you have not yet fixed the bug.
Please do so, as requested by FESCo. Thanks.
Jan, I would not change this (to modify the default configuration file) on released Fedoras, but on Fedora rawhide please change the default.
(Followup to [https://bugzilla.redhat.com/show_bug.cgi?id=450853#c25 comments 25 & 26] in bugzilla:
Jiri, it's very frustrating when you make comments that don't seem to make sense, then go silent and don't explain them.
If we listen on ::, even on a box which doesn't have IPv6 connectivity, it does still accept connections from Legacy IP clients. Please explain why you think otherwise — and please fix the package somehow.
If for some reason you insist that my suggested fix is broken, despite the fact that I demonstrated it working, then please at least implement one of the alternative fixes that would allow the package to work correctly out of the box..
See updates to https://bugzilla.redhat.com/show_bug.cgi?id=839257
I was pretty annoyed to find out my ftp server was unreachable on ipv6 out of the box. And there was no easy way to just enable it. I've added a patch to the above bug that introduces an "vsftpd6" service that runs of the same vsftpd.conf file. Please consider this fix, or revert the listen behaviour to include v4 and v6
To me, this issue makes me look at other ftp daemons. It's 2012. Software should default to both, and allow config options to disable one or the other.
oops closing again. sorry. Turns out it works fine in fedora, and it's only broken on RHEL
Login to comment on this ticket.