Re: [PATCH rhel6-branch 06/11] Add kickstart network --nodefroute option (#638131)

[Radek Vykydal <rvykydal@xxxxxxxxxx>]

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