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 Directory

 
 
LinkBack Thread Tools
 
Old 01-10-2011, 03:44 PM
Chris Lumens
 
Default Add kickstart network --nodefroute option (#638131)

> Sets DEFROUTE=no in ifcfg file.
> ---
> isys/iface.c | 1 +
> isys/iface.h | 1 +
> loader/net.c | 12 +++++++++++-
> 3 files changed, 13 insertions(+), 1 deletions(-)

Do you really need the extra option, or can "DEFROUTE=no" be inferred by
"--bootproto=ibft"?

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-11-2011, 08:54 AM
Radek Vykydal
 
Default Add kickstart network --nodefroute option (#638131)

On 01/10/2011 05:44 PM, Chris Lumens wrote:

Sets DEFROUTE=no in ifcfg file.
---
isys/iface.c | 1 +
isys/iface.h | 1 +
loader/net.c | 12 +++++++++++-
3 files changed, 13 insertions(+), 1 deletions(-)


Do you really need the extra option, or can "DEFROUTE=no" be inferred by
"--bootproto=ibft"?




I am hesitating to infer too much in anaconda, if this should
be assumed, NM should do it when updating ifcfg file or
include it into routing policy for this (ibft) kind of devices.

Also the assumption may be not so simple (at least I don't
feel having enough knowledge to impose it) - can there
be configuration where one might want BOOTPROTO=ibft
and DEFROUTE=yes? In case of ibft being the only one device
used, will NM routing policy override DEFROUTE=no because
there is no other active device?

And starting to support more active devices in installer
(and maybe people starting to use it), the option may become
useful for other configurations. It is also present in nm-c-e as
"Routes..." -> "Use this connection only for resources on this network".
Thinking about it, maybe even more general ifcfgsettings= that would
add anything to ifcfg file would be the best.

Radek

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-13-2011, 03:43 PM
Chris Lumens
 
Default Add kickstart network --nodefroute option (#638131)

> Also the assumption may be not so simple (at least I don't
> feel having enough knowledge to impose it) - can there
> be configuration where one might want BOOTPROTO=ibft
> and DEFROUTE=yes? In case of ibft being the only one device
> used, will NM routing policy override DEFROUTE=no because
> there is no other active device?

We'd need to ask someone who knows more about ibft+NM, because I
certainly do not have the answer for this either.

> And starting to support more active devices in installer
> (and maybe people starting to use it), the option may become
> useful for other configurations. It is also present in nm-c-e as
> "Routes..." -> "Use this connection only for resources on this network".

What other sorts of devices are starting to use this mechanism? If
that's the way things are moving, it does make sense to add an option.

> Thinking about it, maybe even more general ifcfgsettings= that would
> add anything to ifcfg file would be the best.

The problem with that is the ifcfg file is KEY=value style, right? Then
you'd have to do --ifcfgsettings=KEY1=value1 --ifcfgsettings=KEY2=value2
and so forth. I don't think you could combine into a single option
because who knows how complex the text of valueN could be.

Seems like more trouble than it's worth to me, at least for now.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-14-2011, 12:44 PM
Radek Vykydal
 
Default Add kickstart network --nodefroute option (#638131)

On 01/13/2011 05:43 PM, Chris Lumens wrote:


Also the assumption may be not so simple (at least I don't
feel having enough knowledge to impose it) - can there
be configuration where one might want BOOTPROTO=ibft
and DEFROUTE=yes? In case of ibft being the only one device
used, will NM routing policy override DEFROUTE=no because
there is no other active device?





I tested it and in this case (one network device with

--bootproto=ibft used), the setting DEFROUTE=no

causes that default route is not set and all IPs

outside device's subnet are not accessible. So we can't

set it automatically.





We'd need to ask someone who knows more about ibft+NM, because I
certainly do not have the answer for this either.




The BOOTPROTO=ibft is in translated into normal static

configuration in ifcfg.rh plugin which reads actual ibft values.

I actually had to patch the plugin so that DEFROUTE option works

for BOOTPROTO=ibft too

(https://bugzilla.redhat.com/show_bug.cgi?id=665027).





And starting to support more active devices in installer
(and maybe people starting to use it), the option may become
useful for other configurations. It is also present in nm-c-e as
"Routes..." -> "Use this connection only for resources on this network".



What other sorts of devices are starting to use this mechanism? If
that's the way things are moving, it does make sense to add an option.





I'm not aware of any. I just mean - if we are giving power to enable

more devices where routing issues like this can come into play,

it is nice to offer also this basic setting.





Thinking about it, maybe even more general ifcfgsettings= that would
add anything to ifcfg file would be the best.



The problem with that is the ifcfg file is KEY=value style, right? Then
you'd have to do --ifcfgsettings=KEY1=value1 --ifcfgsettings=KEY2=value2
and so forth. I don't think you could combine into a single option
because who knows how complex the text of valueN could be.

Seems like more trouble than it's worth to me, at least for now.





For now, I agree, but I'd think about it for Fedora.

Another example (beside DEFROUTE) is IPV4_FAILURE_FATAL=yes

set by default (if ipv4 configuration fails and ipv6 succeeds,

consider device activation as failed) which is a policy not everyone

may want (I have a bug for it). Instead of deciding in anaconda

if we want to follow the NM's/initscript's policy or not, we can

offer possibility to set it using something like --ifcfgsettings.



It'd be quite powerful option (even for workarounds, testing, and

debugging, especially when activating network in loader before

having shell), the question is - can this power strike back to us?

Well, it might also prove to be not so easy to implement.





Radek



_______________________________________________
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 01:32 AM.

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