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 > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 01-04-2011, 12:53 PM
Radek Vykydal
 
Default network: using more than one NICs (iSCSI) (#638131, #634016)

With the patch, anaconda should be able to fetch repositories via one
NIC while accessing iSCSI via different NIC (#638131).

These things were needed:

1) Activate more than one device in loader using ks -> changes
in loader and --activate option is added to kickstart network
command so that former behaviour (only configuring additional
devices from ks) is preserved.
2) Support for network --bootproto ibft is added into loader.
(in scope of the bug still writing out values which we read
from ibft in anaconda into ifcfg files, see 4)).
In stage 2 ks - where only device configuration (not activation)
can happen in case the device was not activated with --activate
option in loader - the option would be supported automatically
when we start to write out BOOTPROTO=ibft in loader (see 4) below)
3) way to prevent device activated using ks to grab default route ->
--nodefroute option is added (setting DEFROUTE=no in ifcfg file)
4) Use BOOTROOTO=ibft in ifcfg files (#634016), write out
ip=ibft for dracut. This requires one NM fix:
https://bugzilla.redhat.com/show_bug.cgi?id=665027

This anaconda/kickstart part assumes that:
- BOOTPROTO=ibft works fine in NM:
https://bugzilla.redhat.com/show_bug.cgi?id=479824. It did in
my tests in installer environment, except for the issue mentioned
in 4). I was not able to test post install behavior as I couldn't
get over dracut.
- ip=ibft works in dracut:
https://bugzilla.redhat.com/show_bug.cgi?id=640979
My tests with rhel6 nightly of Dec 20 didn't work. I'll investigate
why.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-05-2011, 02:07 PM
Radek Vykydal
 
Default network: using more than one NICs (iSCSI) (#638131, #634016)

On 01/04/2011 02:53 PM, Radek Vykydal wrote:

With the patch, anaconda should be able to fetch repositories via one
NIC while accessing iSCSI via different NIC (#638131).




To answer good question Chris Lumens posed on #anaconda IRC
concerning reconfiguration of NIC enabled (using cmdline configuration)
to fetch kickstart by kickstart network command:

- In rhel 5.6 we apply the kickstart configuration of first network command,
other network commands only set configuration for post install reboot.

- In rhel 6.0 all network commands only set configuration that is applied
only after reboot.
(There is one issue that devices having ONBOOT=yes set will be brought
up before package installation, when network configuration is written
into ifcfg files. This might cause routing problems, though none has been
reported yet. It is to be handled in separate bug.)

- With the patchset, network commands concerning already activated device
only set post-install configuration - the device is not reconfigured in
installer - same as in 6.0. Other devices having new --activate option
are brought up in loader. (The ONBOOT=yes issue remains as in 6.0)

Do we want to change it back to the 5.6? I'm not against it but I think it
would be better to do it in a separate bug.

I noticed that the patchset is changing behaviour from 5.6 and 6.0 in
the case

when network is not brought up before parsing ks. In 5.6 and 6.0
we would bring network up using first network command, whereas with
this patchset, it would be so only if --activate is present in the first
command. I will fix this so that if network is not up, --activate flag
(lack of it) is ignored and the device is activated.


Radek


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-05-2011, 02:47 PM
Chris Lumens
 
Default network: using more than one NICs (iSCSI) (#638131, #634016)

> - In rhel 5.6 we apply the kickstart configuration of first network command,
> other network commands only set configuration for post install reboot.
>
> - In rhel 6.0 all network commands only set configuration that is applied
> only after reboot.
> (There is one issue that devices having ONBOOT=yes set will be brought
> up before package installation, when network configuration is written
> into ifcfg files. This might cause routing problems, though none has been
> reported yet. It is to be handled in separate bug.)
>
> - With the patchset, network commands concerning already activated device
> only set post-install configuration - the device is not reconfigured in
> installer - same as in 6.0. Other devices having new --activate option
> are brought up in loader. (The ONBOOT=yes issue remains as in 6.0)
>
> Do we want to change it back to the 5.6? I'm not against it but I think it
> would be better to do it in a separate bug.

I don't think we intentionally meant to change the behavior from RHEL 5
to RHEL6. At least, I don't remember us discussing that. However, much
of this networking stuff is very subtle so it's entirely possible it got
changed without us ever knowing.

This concept of the first network command in particular being somehow
magic is especially frustrating. Do we document that behavior anywhere,
or is this just how things have always worked?

With that said, I think reverting back to RHEL 5 behavior is the right
thing to do.

> I noticed that the patchset is changing behaviour from 5.6 and 6.0
> in the case
> when network is not brought up before parsing ks. In 5.6 and 6.0
> we would bring network up using first network command, whereas with
> this patchset, it would be so only if --activate is present in the first
> command. I will fix this so that if network is not up, --activate flag
> (lack of it) is ignored and the device is activated.

I really like the clarity of the --activate option, personally. I'd be
all for us defining the future of the network command as so:

* Any network commands given without --activate will refer just to
post-installation configuration.

* Any network commands given with --activate will refer both to
install-time configuration as well as post-installation.

I think that should be flexible enough to cover all cases.
Unfortunately, getting us in position to do the above in RHEL is
difficult given that we have to have a transition period. We can't just
switch it over, especially not for 6.1.

Also, I can't stress enough how we need to thoroughly document this.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-10-2011, 01:40 PM
Radek Vykydal
 
Default network: using more than one NICs (iSCSI) (#638131, #634016)

On 01/05/2011 04:47 PM, Chris Lumens wrote:

I don't think we intentionally meant to change the behavior from RHEL 5
to RHEL6. At least, I don't remember us discussing that. However, much
of this networking stuff is very subtle so it's entirely possible it got
changed without us ever knowing.



I think so.


This concept of the first network command in particular being somehow
magic is especially frustrating. Do we document that behavior anywhere,
or is this just how things have always worked?



The latter I think, I guess people just didn't use installations
with more than one one devices activated in anaconda.


With that said, I think reverting back to RHEL 5 behavior is the right
thing to do.




Yes, I've opened new bug for it.


I noticed that the patchset is changing behaviour from 5.6 and 6.0
in the case
when network is not brought up before parsing ks. In 5.6 and 6.0
we would bring network up using first network command, whereas with
this patchset, it would be so only if --activate is present in the first
command. I will fix this so that if network is not up, --activate flag
(lack of it) is ignored and the device is activated.




This is fixed in new patchset just sent to a-d-l.


I really like the clarity of the --activate option, personally. I'd be
all for us defining the future of the network command as so:

* Any network commands given without --activate will refer just to
post-installation configuration.

* Any network commands given with --activate will refer both to
install-time configuration as well as post-installation.

I think that should be flexible enough to cover all cases.
Unfortunately, getting us in position to do the above in RHEL is
difficult given that we have to have a transition period. We can't just
switch it over, especially not for 6.1.




I agree. Perhaps we can dare to do it in Fedora?
The thing is that the change can have broad impact
I guess network command in ks can be used very often
and it'd affect significant amount of instances of its use:
- ks not fetched over network
- ks with different network configuration fetched over
network


Also, I can't stress enough how we need to thoroughly document this.




Absolutely.

I sent new version of the patchset to a-d-l. Expected
behaviour is described here:
https://fedoraproject.org/wiki/Anaconda/Network#kickstart

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:47 PM.

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