Description of problem: Not sure if this is a "feature" but minimal Fedora installs (which don't include NM) do not start up the default net interface by default. This used to be the case (maybe before the move to upstart??). It is kind of annoying though not sure how best to improve it. Should the minimal include NM? Or could initscripts say be tweaked to bring up the default net interface if NM is not available?
network has not been enabled ever since NM became the default (March 2008); it needs to be manually enabled with current code. To change this would require either a) enabling network by default everywhere (ick) b) changing anaconda to randomly enable network if NM wasn't installed.
I see, thanks. > To change this would require either a) enabling network by default everywhere > (ick) b) changing anaconda to randomly enable network if NM wasn't installed. Would (b) cause problems for NM if it got installed later? IMO it would be nice to have networking enabled by default again, but if it is going to make things too complicated, maybe it is better to keep things as they are?
(In reply to comment #2) > I see, thanks. > > > To change this would require either a) enabling network by default everywhere > > (ick) b) changing anaconda to randomly enable network if NM wasn't installed. > > Would (b) cause problems for NM if it got installed later? No.
So should we move this to anaconda then? :)
Smells like bug #557112 to me.
(In reply to comment #5) > Smells like bug #557112 to me. Yeah similar kind of story. I don't install minimal often enough for this to be a big issue for me... so I live with the status quo even though it seems somewhat annoying. What would be the implication of including some of NM in minimal? Too heavy in terms of bloat? Anyway feel free to do whatever you please with this bug - I just felt I should report it as user feedback.
(In reply to comment #6) > What would be the implication of including some of NM in minimal? > Too heavy in terms of bloat? That is the general complaint of those that like to use 'minimal', yes.
(In reply to comment #1) > To change this would require either a) enabling network by default everywhere > (ick) What is the concern about this solution?
It adds delay and a synchronization point for everyone when it's not required for a majority of cases.
Now that both network and NetworkManager are systemd services I think we could handle this with systemd dependencies, couldn't we? I think systemd has the capability of expressing 'only start service B if service A isn't being started' via its dependencies somehow. So we could ship the network service 'enabled but only if NetworkManager isn't enabled', and that would neatly solve the problem. Rite?
*** Bug 745518 has been marked as a duplicate of this bug. ***
*** Bug 740674 has been marked as a duplicate of this bug. ***
*** Bug 702261 has been marked as a duplicate of this bug. ***
On comment #10, Bill says: <adamw> notting: i thought systemd could express 'start this service but only if this other one isn't started'? <notting> adamw: don't want starting network to preclude starting NM Proposed 'solutions' from 745518: 1) a mechanism to enable network IFF NetworkManager isn't installed. This doesn't exist right now, and would be tricky. 2) enabling network.service in all cases. This isn't doable now due to bug 742840. 3) adding NetworkManager to the minimal install. This would get a *lot* of pushback. Of course, 4) is 'have anaconda enable network.service when installing without NetworkManager'.
(In reply to comment #14) > On comment #10, Bill says: > > <adamw> notting: i thought systemd could express 'start this service but only > if this other one isn't started'? > <notting> adamw: don't want starting network to preclude starting NM > > Proposed 'solutions' from 745518: > > 1) a mechanism to enable network IFF NetworkManager isn't installed. This > doesn't exist right now, and would be tricky. #1 may involve some guessing of what user wants, probably not always correct. If it is done in one of start-up scripts, then it will check every time on boot if network.service should be enabled. And what if user explicitly disables network.service after install? Then we would have to keep state so that we do it one time only. Attempting doing enablement in initstripts' postinstall script - doesn't look promising as well - it doesn't know whether NM is being installed or not. And probably shouldn't know about it at all. > 2) enabling network.service in all cases. This isn't doable now due to bug > 742840. > 3) adding NetworkManager to the minimal install. This would get a *lot* of > pushback. > > Of course, 4) is 'have anaconda enable network.service when installing without > NetworkManager'. I'd opt for #4, anaconda knows that it's doing minimal install (or not installing NetworkManager) so it might be able to enable network.service after packages are installed. And do not forget about adding iptables to minimal install or should I file another bug for that?
*** Bug 769046 has been marked as a duplicate of this bug. ***
I'm adding my vote for #4 here, if that's worth anything... it seems the least complex, while keeping the minimal install minimal. I hit this bug twice in different scenarios where I had no access to a "console" (once in a cloud, once with a remote physical server), and it took some effort to figure out what was wrong. The workaround is simple enough, but this out-of-the-box behavior makes me sad.
My vote is for #4 also.
IMHO, NM should be part of the minimal install, the legacy network-scripts have been obsolescent for years. I don't understand why we keep them in that semi-supported state (e.g. there's no support for WPA or any other networking technology which is less than a decade old, and patches adding WPA support have been explicitly rejected because people should just use NM).
Quite a few people prefer a static, script-managed config for servers, which tend to be wired and have a static IP. There are also still capabilities NM doesn't have: it _still_ can't handle the bridged configuration you need to run a VM host if you want your VM guests to appear on your 'real' network, for instance. You still have to use the network script for that. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
One thing that I think needs to be considered, is not just the "does anaconda or system *start* network/NM"... But the ifcfg-X script which currently has a NM_CONTROLLED=yes/no... Which means if anaconda gets the logic it has to modify those to work. If the config is set yes, and systemd starts network... still no dice. Just a thought as I hit this today with F17Alpha RC2
In the long term it would be probably better to use NetworkManager for network configuration even in minimal. If NM is so bloated, the bloat could be reduced or removed to a plugin.
No, "Just use NM" is not a solution. There are many things NM still does not support. To name a few: lacp, vlans, bridging, multiple route tables -- in short, anything used by enterprise networks. NM has a long way to go before it can replace what 'network' could do years ago.
using NM by default in a minimal install is not at all the same thing as replacing network. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Absolutely true. However, last time I tried, "nmcli" was unable to add a new network, set ssid, set WPA passkey, or setup networking the first time. After you load the GUI and setup an interface, nmcli works fine. Trouble is: min installs do not have a gui to setup networking with. Has nmcli improved to the point that it can now do initial setup, including required wireless configurations without a gui?
AFAIK not yet. Unless you write down the configuration yourself that I didn't try. But with “network”, you actually do that anyway, don't you? There are many things NM still does not “support.” In the long term. So, the only outcome is that: * You cannot remove “network” service right now * You should not mess up with NM IMO the best solution now is to keep the current status quo as “network” may be removed in the future and “minimal” installation users should be capable of overcoming this inconvenience.
(In reply to comment #26) > AFAIK not yet. Unless you write down the configuration yourself that I didn't > try. But with “network”, you actually do that anyway, don't you? I don't think so, by default it's dhcp/nm_controlled ifcfg-ethXX. So in case of minimal install anaconda should make it not nm_controlled and make enable network service in systemd. That just it. > users should be capable of overcoming this inconvenience. I'd object to this. When you test multiple installation, this inconvenience really slows down testing process. So I'd vote for #4 as well. And what the point in keeping broken config and waiting whatever time till NM is capable of doing things. Just fix damn nuisance now using obsolete but working method and replace it WORKING NM option when available.
Understood. So what does it mean for a user who first installs minimal (with “network”) and then installs NetworkManager? Will “network” be running then? “So I'd vote for #4 as well.” So would I.
Pavel: see comment #2 and #3. So let me try and summarize what we've got here, because there's two other relevant bugs: https://bugzilla.redhat.com/show_bug.cgi?id=498207 https://bugzilla.redhat.com/show_bug.cgi?id=804716 #498207 resulted in a change to long-standing behaviour in the F16 release. Up until then, we had never actually brought the network up by default after installation unless you used network repositories during installation. This was considered to be a policy for slightly nebulous security reasons. We finally changed this in F16 so that, if you do an install with NetworkManager included, the network is brought up on the first boot. The relevance of that to this bug is that it suggests a precedent we should follow here: we probably should be doing the same thing in the case of installs without NetworkManager included. The network should be brought up by default in all cases (in the case of a simple DHCP wired connection, obviously). A comment in that bug suggests the reasons this is currently not the case are "'network' service being disabled and BOOTPROTO line missing in eth0 config file". #804716 points up a rather significant change in anaconda behaviour with the 'noloader' code: as of 17.13, anaconda actually no longer spat out ifcfg files at all. Obviously, we need it to start doing so again before we have a whelk's chance in a supernova of getting this to fly. So essentially, this bug now depends on #804716. As far as implementing this goes, as well as making sure anaconda writes out a valid ifcfg file for the wired interface(s), we still need to resolve the problems outlined in the first few comments to this bug. I'm still somehow sure we can solve this with systemd, I'm going to try and talk to Bill about it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Bill: for instance, why can't we just do this? network.service --------------- Conflicts: NetworkManager.service NetworkManager.service ---------------------- Conflicts: network.service After: network.service Doesn't that ensure that, in the problematic case where both are installed and enabled, NetworkManager.service 'wins' and network.service would never fire? systemd resolves out all the dependency logic before ever starting anything, right? It doesn't just iterate through as it goes. I can't figure out what case breaks with the above.
So: let me revise our practical options to three. And because this has randomly triggered my 'this is really crap and we should just damn well fix it' reflex this morning, I strongly intend to actually pick one of these and _do it_ before 17 Final. 1) Do as I proposed in comment #30. Advantages: doesn't require anaconda to do anything crazy and should broadly wind up with the behaviour most people would expect in most installs, doesn't make the minimal package set any bigger (or different, because change is bad etc etc). Disadvantages: there is a valid use case for having both network.service and NetworkManager.service enabled: you want to use each one to handle different interfaces. This is kind of a niche case but it does, apparently, exist, and it's why we have the NM_CONTROLLED parameter in ifcfg files. This approach would make that use case harder, because you'd have to override at least one of the systemd unit files by copying it into /etc and removing the conflicts. Also, we're not 100% sure exactly how Conflicts: works, and if we can use it in such a way that we reliably wind up with NetworkManager 'winning' in the case where both are enabled and conflicting. The systemd man page is pretty confusing on the topic of exactly how Conflicts: works. 2) Have anaconda enable network.service when installing a package set which does not include NetworkManager. Advantages: is probably the smallest possible change from the current setup - doesn't require poking the .service files with possibly unpredictable consequences, or changing the minimal package set. Really it's just getting anaconda to do what everyone who ever did a minimal install did as the #1 command right after installation. Disadvantages: anaconda team don't like it, because they don't think anaconda should do this kind of 'special sauce'; it's more correct for it to be encapsulated in the packaging or comps in some way. 3) Put NetworkManager in core. Advantages: probably the easiest solution to implement, and doesn't have any _engineering_ drawbacks. Makes all our installation cases much more consistent. Disadvantages: people who dislike change are going to hate this one. Note to people who dislike change: you could still remove NetworkManager post-install if you really hate it. Having it in core doesn't preclude that. You could also still exclude it with a kickstart. Makes the minimal install somewhat larger. I am currently testing to see exactly how much bigger NM makes a 'core' installation. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 572054 [details] list of all packages installed in an f16 minimal install via kickstart
Created attachment 572055 [details] df -H after an F16 minimal install and 'yum install fpaste'
Created attachment 572058 [details] list of all packages installed in an f16 minimal install with NM added, via kickstart
Created attachment 572059 [details] df -H after an F16 minimal install with NM added and 'yum install fpaste'
Huh. Those attachments are off. For some reason, http://www.happyassassin.net/extras/ordered_unattended.ks produces an install with NetworkManager installed. No idea why. Will re-do.
Created attachment 572064 [details] list of all packages installed in an f16 minimal install
Created attachment 572065 [details] df after an F16 minimal install
'yum install NetworkManager' on top of a minimal install (why didn't I think of that before?) reports an additional 16 packages, for an additional 3.4MB download size and an additional 9.0M installed size.
Created attachment 572067 [details] list of all packages installed in an f16 minimal install with NM added via yum
Created attachment 572068 [details] df after an F16 minimal install with NM added via yum
The added packages for NM are: +avahi-autoipd-0.6.30-4.fc16.x86_64 +ConsoleKit-0.4.5-1.fc15.x86_64 +ConsoleKit-libs-0.4.5-1.fc15.x86_64 +dbus-glib-0.92-2.fc15.x86_64 +dnsmasq-2.59-4.fc16.x86_64 +libdaemon-0.14-2.fc15.x86_64 +libgudev1-173-3.fc16.x86_64 +libnl-1.1-14.fc16.x86_64 +libpcap-1.1.1-4.fc16.x86_64 +mobile-broadband-provider-info-1.20110218-1.fc16.noarch +ModemManager-0.4.998-1.git20110706.fc16.x86_64 +NetworkManager-0.9.2-1.fc16.x86_64 +NetworkManager-glib-0.9.2-1.fc16.x86_64 +polkit-0.102-3.fc16.x86_64 +ppp-2.4.5-18.fc16.x86_64 +wpa_supplicant-0.7.3-11.fc16.x86_64 For F17+, obviously, we'd lose ConsoleKit from that list. Just this is sufficient to start a DHCP wired connection. No configuration was needed. The df output seems to indicate an actual installed-size difference of 17.4MB compared to an initial minimal install size of 785.6MB, for 2.22%. But I actually compared two different installs because I was being silly. I'll verify that number.
Okay, for F17, here's the details: the size delta is approximately (it's slightly difficult to pin down as when you run yum it dumps files to the hard disk, and stuff) 14MB: 910700 vs. 924912. That's 1.56%. Immediately after installation the installed size is 822928 blocks, 910700 is after a few yum operations and perhaps some other background stuff has written to the disk. The extra packages are: avahi-autoipd dbus-glib dnsmasq libdaemon libgudev1 libnl3 libpcap mobile-broadband-provider-info ModemManager NetworkManager NetworkManager-glib polkit ppp wpa_supplicant for a total of 14. After a fresh install there's 191 packages (entries in rpm -qa, a couple of which may actually be GPG pubkeys), so 14 is a 7.32% increase in the number of packages. :) This was tested with 17 Beta TC1 DVD (since you can't do actual DVD installs with TC2), NetworkManager gets sourced from online repos.
So Bill and I are thinking that the thing to do here may be just to go with putting NM into core. We think we're past the point where that's a reasonable choice. There are still use cases that NM doesn't cover, but fewer and fewer with each release, and really, it's not going to become impossible to use network: the change boils down to 'instead of just enabling the network service, you'll also have to disable the NetworkManager service'. You'll still be able to install without NM via a kickstart if you really must. It's probably an 18 thing rather than a 17 thing at this stage.
http://git.fedorahosted.org/git/?p=comps.git;a=commitdiff;h=a7f19825d325364d5d59107617ddc95bdebcd88b apres ca, le deluge
Adam and Bill, thanks for fixing this long-standing issue. We must trigger Adam's 'this is really crap and we should just damn well fix it' reflex more often :-)
(In reply to comment #43) > Okay, for F17, here's the details: > > the size delta is approximately (it's slightly difficult to pin down as when > you run yum it dumps files to the hard disk, and stuff) 14MB: 910700 vs. > 924912. That's 1.56%. Immediately after installation the installed size is > 822928 blocks, 910700 is after a few yum operations and perhaps some other > background stuff has written to the disk. > > The extra packages are: > > avahi-autoipd > dbus-glib > dnsmasq > libdaemon > libgudev1 > libnl3 > libpcap > mobile-broadband-provider-info > ModemManager > NetworkManager > NetworkManager-glib > polkit > ppp > wpa_supplicant > > for a total of 14. After a fresh install there's 191 packages (entries in rpm > -qa, a couple of which may actually be GPG pubkeys), so 14 is a 7.32% increase > in the number of packages. :) I thought that ModemManager wasn't supposed to be a dependency of NM anymore - it's been added to the dialup group instead: http://lists.fedoraproject.org/pipermail/devel/2012-January/161796.html - so this list should be slightly smaller. But it looks like the ModemManager requires haven't been removed from NetworkManager yet.
(In reply to comment #47) > But it looks like the ModemManager requires haven't been removed from > NetworkManager yet. Bug #809098 for the record.
*** Bug 824809 has been marked as a duplicate of this bug. ***