Bug 237830

Summary:	blacklisting of ipv6 module
Product:	[Fedora] Fedora	Reporter:	David Woodhouse <dwmw2>
Component:	system-config-network	Assignee:	Harald Hoyer <harald>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	notting, redhat-bugzilla
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-05-03 02:26:38 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	150226

Description David Woodhouse 2007-04-25 15:33:56 UTC

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.

Comment 1 Bill Nottingham 2007-04-25 16:59:55 UTC

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.

Comment 2 David Woodhouse 2007-04-25 17:03:41 UTC

(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.

Comment 3 Bill Nottingham 2007-04-25 17:19:29 UTC

(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.

Comment 4 David Woodhouse 2007-04-25 17:31:54 UTC

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.

Comment 5 Bill Nottingham 2007-04-25 17:47:38 UTC

Having *bootup scripts* modify configuration files at runtime is silly - this
does not belong in initscripts.

Comment 6 David Woodhouse 2007-04-25 20:02:43 UTC

(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.

Comment 7 David Woodhouse 2007-04-26 07:47:42 UTC

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.

Comment 8 David Woodhouse 2007-04-29 10:07:43 UTC

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.