Hello,
I have been testing the FC10 beta and the more recent snapshots. The installation package selection and options available in the text-mode installer are really very important to me. I run through the installer literally hundreds of times over the lifetime of a Fedora release and not always can it be kickstarted.
One of the major changes I noted from FC9 to the latest spin of FC10 is the lack of network configuration during the install. Specifically during a "minimal" install whereby all packages are unticked leaving only the '@core' group installed. NetworkManager isn't included in the '@core' group and the defaults set by /etc/sysconfig/network-scripts/ifcfg-ethX prohibit the 'network' service from starting the interfaces in NetworkManager's absence.
e.g. /etc/sysconfig/network-scripts/ifcfg-eth0: DEVICE=eth0 HWADDR=00:1f:d0:88:0a:fd ONBOOT=no NM_CONTROLLED=yes TYPE=Ethernet
Note that NetworkManger has not been installed, yet the ifcfg-eth0 implies that the interface should be NetworkManager controlled. The 'network' services see's "ONBOOT=no" and ignores this interface. So, using a very simple installation-path the system comes up without any network connectivity, the user must manually edit this file changing "ONBOOT=no" to "ONBOOT=yes" and adding the line "BOOTPROTO=dhcp" before restarting the 'network' service.
I raised this as a bug: https://bugzilla.redhat.com/show_bug.cgi?id=468028
After some feedback, I decided to bring the discussion to this mailing list.
I can understand the push for the use of the NetworkManager, however I totally disagree that default installations should be crippled such that they require manual editing of config files ala NetBSD. The way I see it there are two clear solutions:
(1). Include NetworkManager in the '@core' group, such that every install will include NetworkManager and a minimal install as described above will bring the system up with network connectivity.
(2). Add some logic to the installer, if NetworkManager isnt to be installed, adjust the /etc/sysconfig/network-scripts appropriately such that network connectivity comes up after install. However this could be more problematic that I first thought, how many interfaces do you enable? If I have 4 NIC's, 3 not connected do I need to wait for the 'network' service to give up on the other three NIC's before bringing the system up etc.
In my opinion, Fedora is all about the ease of use, in every way from installation to the day-to-day running be it on a laptop, desktop or server-class machine. I believe that if the network configuration has been removed to simplify the installation procedure, it must be replaced with some 'smarts' to restore some of the ease of use of Fedora.
Regards, -- Michael Cutler http://fedoraproject.org/wiki/User:Mcutler
On Tue, 2008-10-28 at 11:31 +0000, Michael Cutler wrote:
(1). Include NetworkManager in the '@core' group, such that every install will include NetworkManager and a minimal install as described above will bring the system up with network connectivity.
And here we have another fun argument about how 'minimal' should the minimal install be! We've chucked yum in @core, might as well chuck NetworkManager too...
On Tue, 2008-10-28 at 09:38 -0700, Jesse Keating wrote:
On Tue, 2008-10-28 at 11:31 +0000, Michael Cutler wrote:
(1). Include NetworkManager in the '@core' group, such that every install will include NetworkManager and a minimal install as described above will bring the system up with network connectivity.
And here we have another fun argument about how 'minimal' should the minimal install be! We've chucked yum in @core, might as well chuck NetworkManager too...
Right, but we still don't turn NM on by default with chkconfig. Which means even if you bring it into @core, your networking still won't work unless you turn NM on post-install manually.
The issue here (IIRC) was that Anaconda won't set up an ifcfg file for you if you don't use network to install, because the network configuration screen got removed as it was mostly redundant for installs where NM is active.
If you're not installing over the network (and thus there's no network configuration to save out) should the "network config" screen come back? Or should anaconda just activate all devices onboot with DHCP? The latter sounds like a loss. If you want stuff set up post-boot without NetworkManager, maybe it's not unreasonable that you have to configure it yourself. What's the difference if that happens post-install or during install?
Dan
On Tue, Oct 28, 2008 at 12:48:48PM -0400, Dan Williams wrote:
If you're not installing over the network (and thus there's no network configuration to save out) should the "network config" screen come back? Or should anaconda just activate all devices onboot with DHCP? The latter sounds like a loss. If you want stuff set up post-boot without NetworkManager, maybe it's not unreasonable that you have to configure it yourself. What's the difference if that happens post-install or during install?
I think it is a perfectly reasonable default to have DHCP enabled by default for all network interfaces, whether NetworkManager is used or not.
On Tue, Oct 28, 2008 at 10:18 AM, Chuck Anderson cra@wpi.edu wrote:
I think it is a perfectly reasonable default to have DHCP enabled by default for all network interfaces, whether NetworkManager is used or not.
Is this solvable with initscript logic? Can the network initscript taste to see if NM is actually installed and if not ignore the NetworkManager=yes flag?
-jef
On Tue, Oct 28, 2008 at 02:18:55PM -0400, Chuck Anderson wrote:
On Tue, Oct 28, 2008 at 12:48:48PM -0400, Dan Williams wrote:
If you're not installing over the network (and thus there's no network configuration to save out) should the "network config" screen come back? Or should anaconda just activate all devices onboot with DHCP? The latter sounds like a loss. If you want stuff set up post-boot without NetworkManager, maybe it's not unreasonable that you have to configure it yourself. What's the difference if that happens post-install or during install?
I think it is a perfectly reasonable default to have DHCP enabled by default for all network interfaces, whether NetworkManager is used or not.
Seriously?
On Tue, Oct 28, 2008 at 12:39:31PM -1000, David Cantrell wrote:
On Tue, Oct 28, 2008 at 02:18:55PM -0400, Chuck Anderson wrote:
I think it is a perfectly reasonable default to have DHCP enabled by default for all network interfaces, whether NetworkManager is used or not.
Seriously?
Yes, why not?
On Tue, Oct 28, 2008 at 06:45:44PM -0400, Chuck Anderson wrote:
On Tue, Oct 28, 2008 at 12:39:31PM -1000, David Cantrell wrote:
On Tue, Oct 28, 2008 at 02:18:55PM -0400, Chuck Anderson wrote:
I think it is a perfectly reasonable default to have DHCP enabled by default for all network interfaces, whether NetworkManager is used or not.
Seriously?
Yes, why not?
Right away I can think of the user with 185 network interfaces complaining about boot up taking too long because he's having to wait for each one to time out.
On Tue, Oct 28, 2008 at 12:47:59PM -1000, David Cantrell wrote:
On Tue, Oct 28, 2008 at 06:45:44PM -0400, Chuck Anderson wrote:
On Tue, Oct 28, 2008 at 12:39:31PM -1000, David Cantrell wrote:
On Tue, Oct 28, 2008 at 02:18:55PM -0400, Chuck Anderson wrote:
I think it is a perfectly reasonable default to have DHCP enabled by default for all network interfaces, whether NetworkManager is used or not.
Seriously?
Yes, why not?
Right away I can think of the user with 185 network interfaces complaining about boot up taking too long because he's having to wait for each one to time out.
What ever happened to the "no link detected" logic?
David Cantrell wrote:
On Tue, Oct 28, 2008 at 06:45:44PM -0400, Chuck Anderson wrote:
On Tue, Oct 28, 2008 at 12:39:31PM -1000, David Cantrell wrote:
On Tue, Oct 28, 2008 at 02:18:55PM -0400, Chuck Anderson wrote:
I think it is a perfectly reasonable default to have DHCP enabled by default for all network interfaces, whether NetworkManager is used or not.
Seriously?
Yes, why not?
Right away I can think of the user with 185 network interfaces complaining about boot up taking too long because he's having to wait for each one to time out.
Assume that only the ones that he wants to use are connected. And that he wants to do the initial install via NFS.
On Tue, Oct 28, 2008 at 12:48:48PM -0400, Dan Williams wrote:
On Tue, 2008-10-28 at 09:38 -0700, Jesse Keating wrote:
On Tue, 2008-10-28 at 11:31 +0000, Michael Cutler wrote:
(1). Include NetworkManager in the '@core' group, such that every install will include NetworkManager and a minimal install as described above will bring the system up with network connectivity.
And here we have another fun argument about how 'minimal' should the minimal install be! We've chucked yum in @core, might as well chuck NetworkManager too...
Right, but we still don't turn NM on by default with chkconfig. Which means even if you bring it into @core, your networking still won't work unless you turn NM on post-install manually.
The issue here (IIRC) was that Anaconda won't set up an ifcfg file for you if you don't use network to install, because the network configuration screen got removed as it was mostly redundant for installs where NM is active.
If you're not installing over the network (and thus there's no network configuration to save out) should the "network config" screen come back? Or should anaconda just activate all devices onboot with DHCP? The latter sounds like a loss. If you want stuff set up post-boot without NetworkManager, maybe it's not unreasonable that you have to configure it yourself. What's the difference if that happens post-install or during install?
This is a good point. I really don't think it's unreasonable to require any of the following:
1) Users have to use NetworkManager to bring up a network interface. 2) Users have to run system-config-network to set up networking. 3) Users have to edit ifcfg-DEVICE files by hand.
Over the past several years, we [anaconda team] has been trying to move as many system configuration screens out of anaconda as we can. Only what we need to ensure the system either (a) installs correctly or (b) reboots and is usable. We're down to:
language keyboard root password timezone hostname boot loader (automatic unless you ask to configure it)
There are some other ideas that we could come up with too. What if firstboot asked you how you want to configure your network interface? As in, exposing the s-c-network UI or something from NetworkManager? Just brainstorming. These really just make what's already there more accessible after an initial install.
Once upon a time, David Cantrell dcantrell@redhat.com said:
This is a good point. I really don't think it's unreasonable to require any of the following:
- Users have to use NetworkManager to bring up a network interface.
- Users have to run system-config-network to set up networking.
- Users have to edit ifcfg-DEVICE files by hand.
Over the past several years, we [anaconda team] has been trying to move as many system configuration screens out of anaconda as we can. Only what we need to ensure the system either (a) installs correctly or (b) reboots and is usable. We're down to:
language keyboard root password timezone hostname boot loader (automatic unless you ask to configure it)
This means you can no longer start an install and SSH in once it is done to perform the rest of configuration. I'll start an install on a computer in another room, and when I can ping its static IP, I can SSH in and work on it (I don't have to walk back and forth, checking on it periodically or do any more configuration at the console). If that is the desired case, then you might as well:
- disable sshd by default - set "PermitRootLogin no" in /etc/ssh/sshd_config by default - remove the SSH opening in the firewall
2008/10/29 David Cantrell dcantrell@redhat.com
On Tue, Oct 28, 2008 at 12:48:48PM -0400, Dan Williams wrote:
On Tue, 2008-10-28 at 09:38 -0700, Jesse Keating wrote:
On Tue, 2008-10-28 at 11:31 +0000, Michael Cutler wrote:
(1). Include NetworkManager in the '@core' group, such that every install will include NetworkManager and a minimal install as described above will bring the system up with network connectivity.
And here we have another fun argument about how 'minimal' should the minimal install be! We've chucked yum in @core, might as well chuck NetworkManager too...
Right, but we still don't turn NM on by default with chkconfig. Which means even if you bring it into @core, your networking still won't work unless you turn NM on post-install manually.
The issue here (IIRC) was that Anaconda won't set up an ifcfg file for you if you don't use network to install, because the network configuration screen got removed as it was mostly redundant for installs where NM is active.
If you're not installing over the network (and thus there's no network configuration to save out) should the "network config" screen come back? Or should anaconda just activate all devices onboot with DHCP? The latter sounds like a loss. If you want stuff set up post-boot without NetworkManager, maybe it's not unreasonable that you have to configure it yourself. What's the difference if that happens post-install or during install?
This is a good point. I really don't think it's unreasonable to require any of the following:
- Users have to use NetworkManager to bring up a network interface.
- Users have to run system-config-network to set up networking.
- Users have to edit ifcfg-DEVICE files by hand.
Over the past several years, we [anaconda team] has been trying to move as many system configuration screens out of anaconda as we can. Only what we need to ensure the system either (a) installs correctly or (b) reboots and is usable. We're down to:
language keyboard root password timezone hostname boot loader (automatic unless you ask to configure it)
There are some other ideas that we could come up with too. What if firstboot asked you how you want to configure your network interface? As in, exposing the s-c-network UI or something from NetworkManager? Just brainstorming. These really just make what's already there more accessible after an initial install.
I would say firstboot is the best place for network configuration, ofcourse unless installed via network. I know a lot of people install Fedora using CD/DVDs and with no initial network connection.
-- David Cantrell dcantrell@redhat.com Red Hat / Honolulu, HI
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- Cheers, Rajeesh
On Tue, Oct 28, 2008 at 11:31:40AM +0000, Michael Cutler wrote:
(1). Include NetworkManager in the '@core' group, such that every install will include NetworkManager and a minimal install as described above will bring the system up with network connectivity.
I'm not opposed to this, but I'm also not opposed to it staying where it is.
(2). Add some logic to the installer, if NetworkManager isnt to be installed, adjust the /etc/sysconfig/network-scripts appropriately such that network connectivity comes up after install. However this could be more problematic that I first thought, how many interfaces do you enable? If I have 4 NIC's, 3 not connected do I need to wait for the 'network' service to give up on the other three NIC's before bringing the system up etc.
I'm not in favor of this. The situation you're describing is exactly why we wanted to get rid of the network configuration screen.
David Cantrell wrote:
On Tue, Oct 28, 2008 at 11:31:40AM +0000, Michael Cutler wrote:
(1). Include NetworkManager in the '@core' group, such that every install will include NetworkManager and a minimal install as described above will bring the system up with network connectivity.
I'm not opposed to this, but I'm also not opposed to it staying where it is.
(2). Add some logic to the installer, if NetworkManager isnt to be installed, adjust the /etc/sysconfig/network-scripts appropriately such that network connectivity comes up after install. However this could be more problematic that I first thought, how many interfaces do you enable? If I have 4 NIC's, 3 not connected do I need to wait for the 'network' service to give up on the other three NIC's before bringing the system up etc.
I'm not in favor of this. The situation you're describing is exactly why we wanted to get rid of the network configuration screen.
Isn't the system already capable of knowing if link is up on an interface and not waiting for dhcp if it isn't connected?
On Tue, 2008-10-28 at 17:51 -0500, Les Mikesell wrote:
David Cantrell wrote:
On Tue, Oct 28, 2008 at 11:31:40AM +0000, Michael Cutler wrote:
(1). Include NetworkManager in the '@core' group, such that every install will include NetworkManager and a minimal install as described above will bring the system up with network connectivity.
I'm not opposed to this, but I'm also not opposed to it staying where it is.
(2). Add some logic to the installer, if NetworkManager isnt to be installed, adjust the /etc/sysconfig/network-scripts appropriately such that network connectivity comes up after install. However this could be more problematic that I first thought, how many interfaces do you enable? If I have 4 NIC's, 3 not connected do I need to wait for the 'network' service to give up on the other three NIC's before bringing the system up etc.
I'm not in favor of this. The situation you're describing is exactly why we wanted to get rid of the network configuration screen.
Isn't the system already capable of knowing if link is up on an interface and not waiting for dhcp if it isn't connected?
No, it depends on the driver. There are some drivers that still do not do link checking (some pcnet32, some ne2000 variants), or if they do, only on a 30 second or 60 second poll (3c59x as of 2 years ago). Maybe we don't care about those drivers.
Dan