Anaconda has started blacklisting the ipv6.ko module so that it can't even be loaded when root manually runs 'modprobe ipv6. This is not a good thing. The anaconda folks claim that it should do this only when IPv6 doesn't happen to be configured on any of the interfaces configured in the installer (although actually it does it even when IPv6 _is_ configured; bug #237642). But even if anaconda _was_ only doing this when the anaconda folks say it does, it'd still be broken. Because when I later bring up a tunnel or enable IPv6 on the interface, nothing removes the blacklist for me. There's something to be said for blacklisting net-pf-10, so that the module isn't automatically loaded just by apps calling socket(AF_INET6,...). But we should probably leave ipv6.ko un-blacklisted, and load it manually in the initscripts only when it's needed. Either that, or add and remove the blacklist entry in /etc/modprobe.d from the initscripts according to whether IPv6 is configured. Either way, I don't think anaconda should be creating the blacklist at all. If that's the way it's going to be done, then it needs to be handled by initscripts.
Having modprobe rules that read config files every time a module could be loaded is amazingly inefficient for the common case (having IPv6 enabled). If it's disabled and you want to enable it, removing a file is a perfectly acceptable configuration.
(In reply to comment #1) > Having modprobe rules that read config files every time a module could be loaded > is amazingly inefficient for the common case (having IPv6 enabled). Indeed it would be. That's why I'd never suggest such a thing. > If it's disabled and you want to enable it, removing a file is a perfectly > acceptable configuration. If it's disabled and I enable it using system-config-network, having either initscripts or system-config-network (preferably the former, since we shouldn't be _forced_ to use system-config-network) remove the file is a perfectly acceptable configuration. I agree. Having the _user_ remove the file manually, when they had no idea that it existed in the first place, is not acceptable. Hence this bug, which I'm reopening.
(In reply to comment #2) > > If it's disabled and you want to enable it, removing a file is a perfectly > > acceptable configuration. > > If it's disabled and I enable it using system-config-network, having either > initscripts or system-config-network (preferably the former, since we shouldn't > be _forced_ to use system-config-network) remove the file is a perfectly > acceptable configuration. I agree. s-c-network is the place then. If you're enabling ipv6 by hand, you can remove a file by hand, as *disabling the module* is the way to disable ipv6.
It's better to have the blacklist file removed in initscripts rather than system-config-network. There's no reason to force people to use s-c-n when the normal configuration files are perfectly sufficient. But since you seem to be in an unhelpful mood today, reopening and filing against s-c-n (which presumably you just _forgot_ to do?) since although that's a suboptimal fix it's still better than the status quo.
Having *bootup scripts* modify configuration files at runtime is silly - this does not belong in initscripts.
(In reply to comment #5) > Having *bootup scripts* modify configuration files at runtime is silly - this > does not belong in initscripts. It sounds like the removal of NETWORKING_IPv6 from initscripts was a mistake then. Users shouldn't suddenly be expected to look in /etc/modprobe.d for what was rightly _network_ configuration. It wouldn't have taken much joined-up thinking to make NETWORKING_IPv6 work as expected, I'm sure.
If we're expecting that people should only very rarely have to disable IPv6, then making them do it by adding a module blacklist is fine. Removing the support for NETWORKING_IPV6=no from initscripts and from system-config-network makes sense in that context. What _doesn't_ make sense, if that's our aim, is for anaconda to be setting up that blacklist for itself just because the user didn't happen to configure IPv6 within anaconda.... especially given that anaconda doesn't let you set up tunnels and 6to4 anyway. So if we fix that, then the situation seems fine.
This is now fixed in anaconda -- which never disables the module. Now there is consistency across the distribution -- blacklisting the module is an esoteric requirement; something which normal users should never have to do. I don't see a global 'disable IPv6' option in system-config-network -- either using NETWORKING_IPV6 or otherwise, so I think this bug can be closed now.