Hi,
this proposition is mainly for Will. Currently we create missing default ifcfg files (i.e. file of devices not activated in dracut or configured by kickstart) in anaconda:
commit e1c287f31dcec4c661272f852e14f5d6925f92d2 Author: Will Woods wwoods@redhat.com Date: Wed Mar 21 20:02:46 2012 -0400
Create default ifcfg-* for each interface (#804504, #804716)
Loader used to create a default ifcfg-* file for each unused network interface, containing DEVICE, HWADDR, UUID, BOOTPROTO=dhcp, etc.
Network.update() populated self.netdevices by reading those files, *skipping any interface that lacked that file*, which caused the vnc traceback in bug #804504.
And without BOOTPROTO=dhcp, "ifup $dev" didn't work post-install, which caused #804716.
(Personally I think "ifup" should fall back to the same defaults as NetworkManager rather than making us write the defaults to a file, but we'll save that for later.)
This has a problem that NetworkManager activates default connections for devices lacking ifcfg file which differs from behaviour in rhel6 and I think we don't want to start to do this.
Perhaps we could run anaconda pre-pivot hook (post pre-pivot/85write-ifcfg.sh) that would take care of missing ifcfg files.
What do you think? Should I try to come up with an anaconda dracut patch?
Also I'd like to bring back functionality of --activate option, but activation of additional devices could be done in anaconda kickstart processing, even though doing that in dracut might be as simple as writing ONBOOT=yes by dracut/ks to ifcfg file.
Radek
On Fri, 2012-06-29 at 13:24 +0200, Radek Vykydal wrote:
Hi,
this proposition is mainly for Will. Currently we create missing default ifcfg files (i.e. file of devices not activated in dracut or configured by kickstart) in anaconda:
[...]
This has a problem that NetworkManager activates default connections for devices lacking ifcfg file which differs from behaviour in rhel6 and I think we don't want to start to do this.
Why not? Why is it our job to maintain policy for when to start network interfaces? And why should that policy differ from the normal system?
Here's a general rule I'm trying to follow for anaconda:
Unless there is an *explicit, documented* use case that requires otherwise, we should use the system defaults.
When the system defaults conflict with current anaconda behavior, yes, that will require behavior changes. But *not all behavior changes are bugs*.
If there's a reason that we *need* to have a *completely different* policy for unconfigured network interfaces inside anaconda from the normal system, that's fine - let's talk about those use cases and figure out the best thing to do.
Also I'd like to bring back functionality of --activate option, but activation of additional devices could be done in anaconda kickstart processing, even though doing that in dracut might be as simple as writing ONBOOT=yes by dracut/ks to ifcfg file.
..or we could add a --no-activate option to override the system default behavior, if the user so chooses?
-w
On 07/17/2012 08:07 PM, Will Woods wrote:
On Fri, 2012-06-29 at 13:24 +0200, Radek Vykydal wrote:
Hi,
this proposition is mainly for Will. Currently we create missing default ifcfg files (i.e. file of devices not activated in dracut or configured by kickstart) in anaconda:
[...]
This has a problem that NetworkManager activates default connections for devices lacking ifcfg file which differs from behaviour in rhel6 and I think we don't want to start to do this.
Why not? Why is it our job to maintain policy for when to start network interfaces? And why should that policy differ from the normal system?
Actually we have been always setting the policy (of which devices should be activated on first boot)for normal system. I think configuration of which devices should be activated after installation is something we need to be able to set/control in installer.
Here's a general rule I'm trying to follow for anaconda:
Unless there is an *explicit, documented* use case that requires otherwise, we should use the system defaults.
When the system defaults conflict with current anaconda behavior, yes, that will require behavior changes. But *not all behavior changes are bugs*.
In this concrete case it is anaconda which is setting the "system defaults" [1]. Our policy (for both normal system and anaconda) has been: don't activate device unless it was activated during installation (using the device, --activate option) or explicitly configured (onboot value in ks, or in GUI) [2].
Can we drop current behaviour?
The rhel (server) realm will require to keep current policy. No matter if we will decide to keep it for Fedora, I am trying to get ready to the pile of BZs asking to bring the behaviour back and make fixing them less painful.
I am not contesting the change of policy, if we want to do it for Fedora, all right. I care to keep *ability* to set some configuration/policy (i.e. set ONBOOT in ifcfg files) and to be able to set it consistently for anaconda and normal system.
If there's a reason that we *need* to have a *completely different* policy for unconfigured network interfaces inside anaconda from the normal system, that's fine - let's talk about those use cases and figure out the best thing to do.
Currently (in noloader) with your patch we are creating default ifcfg files in anaconda. That means they will be there for NM in "normal system", but not for NM in anaconda environment. With my patch, they will be there both for anaconda and normal system - which is step towards unifying the two, not making them different.
You are assuming here the policy of normal system is activating unconfigured devices. There is no such policy, it is just behaviour of NM. I was trying to keep in mind installations without NM, e.g. what minimal install used to be although think NM is becoming part of minimal install so we might not worry about this case.
Also I'd like to bring back functionality of --activate option, but activation of additional devices could be done in anaconda kickstart processing, even though doing that in dracut might be as simple as writing ONBOOT=yes by dracut/ks to ifcfg file.
..or we could add a --no-activate option to override the system default behavior, if the user so chooses?
Sure, --activate fits into our current policy. If we drop/change it to activate everything by default then we'll want --no-activate instead.
There are also some technical issues with not having control over device configuration with ifcfg files [3] (e.g. NM and root on iSCSI), but I will put them aside now.
Radek
[1] for which devices should be activated on first boot
[2] this has been sightly modified in Fedora to ensure activation of some device after reboot
[3] NM doesn't write configuration of auto (missing ifcfg) connections into ifcfg files.
anaconda-devel@lists.stg.fedoraproject.org