On Aug 21, 2008, at 10:27 AM, Chris Lumens wrote:
* Make minimal changes to the current code.
* Bring NetworkManager in and use it starting in stage 1.
* Do not make changes to the NetworkManager related packages as
they are
in Fedora, just use them as is and pull in whatever we need.
* Be able to perform IPv4 installs over HTTP and NFS.
These sound like reasonable goals. Hopefully we can also add some
goals
like:
* Improved wireless support.
* Fixing long-standing bugs like our inability to renew a lease.
* Reducing our number of network configuration UIs.
I should have made it clear that those were the goals of just this
first patch set. The ones you mention are definitely goals, but I
can't really tackle those until I get this stuff in place.
1) Lots of changes to upd-instroot and mk-images. NetworkManager
means
we
also bring in dbus, hal, PolicyKit, functions, network-functions,
and
other support programs called by those programs or scripts.
dhclient
is in there, along with dhclient-script (which uses bash), and
dhcp6c.
It's a truckload of stuff.
How much do you estimate we are growing the initrd (and I guess the
stage2) images by? I see we're having to start more programs now from
init. I assume this increases our memory requirements somewhat. Any
idea how much it's grown?
Replacing libdhcp and friends with dhclient and dhcp6c (and the
support programs they need) changed nothing. However, adding hal,
dbus, and the other things has ballooned up the initrd.img to 44M
uncompressed on i386, 19M compressed.
3) A new function called writeDisabledNetInfo() which writes out
ifcfg
files for every found interface so we disable them by default.
So, writeDisabledNetInfo() disables all discovered network
interfaces by
default, then we go back and enable the ones that the user asks for,
or
that we can successfully bring up via DHCP, or other means?
That's the idea.
* Network configuration information is not carried over to stage 2
yet.
When you are at the post-config step for the network interfaces, it
won't reflect the current state.
This would be the biggest concern I have for fixing before committing
everything.
The stage 2 carryover is the very next thing I wanted to fix up.
Right now it doesn't prevent an installation from continuing, it's
just got the wrong info.
* Any wireless installs. The get_connection() function in loader2/
net.c
provides a loop to attach this kind of stuff. When NM wants more
info,
we can prompt here and continue to wait for it to bring up the link.
No big loss for now - we put up the "allowwireless" hurdle for people
who want to install via wireless, so they know it's not really an
officially supported mechanism. Would definitely be nice to have it
done by release time.
Absolutely. I would like to have a WPA install work by release time.
I don't really have any other specific comments. It's a lot of code,
but the scariest part to me is really the UI flow components. That to
me has always been our biggest problem in loader, not actually
configuring interfaces.
Agreed. Most of the UI stuff will be simplified. NetworkManager will
allow us to only request what it needs rather than asking for
everything up front. The interesting thing in loader is that this
makes things easier. Currently if a user goes back, we have the
bizarre maze of downing an interface but keeping the interface
information, but then requesting for everything again. With
NetworkManager, we can keep it running the whole time and just change
the ifcfg files and tell it what to do over dbus.
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
