FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 06-29-2012, 11:24 AM
Radek Vykydal
 
Default noloader: create default ifcfg files already in dracut

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




_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-11-2012, 12:14 PM
Radek Vykydal
 
Default noloader: create default ifcfg files already in dracut

On 06/29/2012 01:24 PM, Radek Vykydal wrote:


Should I try to come up with an anaconda dracut patch?



Patch sent to anaconda-patches.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-17-2012, 06:07 PM
Will Woods
 
Default noloader: create default ifcfg files already in dracut

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

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-18-2012, 12:03 PM
Radek Vykydal
 
Default noloader: create default ifcfg files already in dracut

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-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 05:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org