Bug 467865

Summary: Removing NetworkManager kills network
Product: [Fedora] Fedora Reporter: Chris Snook <csnook>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 10CC: dcbw, sub1, wtogami, zing
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-13 08:14:45 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Chris Snook 2008-10-21 08:35:28 EDT
Description of problem:
When NetworkManager is removed, the service is stopped, and any active interfaces are taken down.  This is *extremely* inconvenient when managing systems remotely.

Version-Release number of selected component (if applicable):
F10-snap2, and as far back as the original F9 release

How reproducible:
100%

Steps to Reproduce:
1. Install anything from F9 through F10-snap2 on a headless server with no wireless card.
2. Run yum --security check-update, and see that NetworkManager is a security risk.
3. Since it's a headless server without X or a wireless card, remove NetworkManager to avoid exposure to future security flaws.

Actual results:
1. Network disappears, and remote machine is inaccessible, even after reboot via network PDU.

Expected results:
Network doesn't disappear.

Additional info:
While it's certainly understandable if interfaces managed by NetworkManager go away when it's removed, it's not at all obvious that NetworkManager will be managing interfaces on a headless server.
Comment 1 Bug Zapper 2008-11-25 23:05:11 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Normand Robert 2008-12-04 13:05:21 EST
and on our F 10 i386 system which was yum updated and rebooted minutes ago nis (yp) does not work if the network manager is enabled and nis is needed for authentification on our network.

If Network manager is off nis works and we can ssh to remote computers (dns works fine) but firefox and yum just crash???

Note that the original system-config-network is broken because it writes the GW into the NETMASK field. This appears to have been fixed now.
Comment 3 Normand Robert 2008-12-04 13:08:03 EST
CORRECTION: ssh segfaults as well.

(In reply to comment #2)
> and on our F 10 i386 system which was yum updated and rebooted minutes ago nis
> (yp) does not work if the network manager is enabled and nis is needed for
> authentification on our network.
> 
> If Network manager is off nis works and we can ssh to remote computers (dns
> works fine) but firefox and yum just crash???
> 
> Note that the original system-config-network is broken because it writes the GW
> into the NETMASK field. This appears to have been fixed now.
Comment 4 Dan Williams 2008-12-05 17:55:38 EST
(In reply to comment #2)
> and on our F 10 i386 system which was yum updated and rebooted minutes ago nis
> (yp) does not work if the network manager is enabled and nis is needed for
> authentification on our network.
> 
> If Network manager is off nis works and we can ssh to remote computers (dns
> works fine) but firefox and yum just crash???
> 
> Note that the original system-config-network is broken because it writes the GW
> into the NETMASK field. This appears to have been fixed now.

I don't think that's related to this specific bug.  For NIS, a small dispatcher script is required to be added to NIS packages that will, when NM changes connections, write out the DHCP-provided NIS server and NIS domain name to the correct config files.
Comment 5 Dan Williams 2009-02-13 08:14:45 EST
(In reply to comment #0)
> Additional info:
> While it's certainly understandable if interfaces managed by NetworkManager go
> away when it's removed, it's not at all obvious that NetworkManager will be
> managing interfaces on a headless server.

We're going to have to do some stuff for iSCSI to make NM pick up existing iSCSI config on startup, so we'll probably have to do some corresponding takedown stuff as well.  That work will fix your issue.

*** This bug has been marked as a duplicate of bug 479824 ***