Red Hat Bugzilla – Bug 276681
Install/Enable Network Manager by default
Last modified: 2010-11-10 14:30:48 EST
Network Manager should be installed and enabled by default. This is a valuable
program, but users do not have easy access to it. They have to know it exists,
and how to install and enable optional packages.
Adjusting priority due to our new priority inclusion criteria as outlined in
I don't know if it should go in this BZ or a separate BZ, but the default
Network Manager needs to have tcp keepalive (I believe) set.
In the CSB version of NM, it will keep a VPN open indefinately.
In the stock version of NM, a VPN tunnel loses connectivity after a few minutes.
I have to work around this by opening a terminal window and entering "ping -i 30
<internal VPN node name>"
Hmm, from comment 5 I've confused the matter.
This BZ is to enable NetworkManager by default. I will create a separate BZ for
This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time. This request will be
reviewed for a future Red Hat Enterprise Linux release.
punting to RHEL6 since we're already doing this for F9 and it'll filter down to
RHEL when the time comes.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
Putting as MODIFIED (for client products...)
Is "enabled by default" really required?
NetworkManager just makes life difficult for multi-nic setups, and seems to cause no end of grief. If it were possible to completely remove it from the system without breaking dependencies, we'd do it across the board.
(In reply to comment #16)
> Is "enabled by default" really required?
> NetworkManager just makes life difficult for multi-nic setups, and seems to
> cause no end of grief. If it were possible to completely remove it from the
> system without breaking dependencies, we'd do it across the board.
SOunds like you're using incorrectly. It'll handle multi-nic setups *just fine* as long as you're locking connections to the NIC's MAC address with HWADDR in the ifcfg files.
If you don't do that, then even without NetworkManager stuff will break if you swap NICs around.
Heh, it would be nice if it was that simple. :)
Several of our test lab servers have 3x GbE + 2x IpoIB physical connections, with aliases on the GbE connections. NetworkManager thus far (not including RHEL6 or F13) mixes up the routing sometimes, thereby completely breaking connectivity.
Because of this, it's been far simpler and more practical to set things correctly in the ifcfg scripts, disable NetworkManager from starting, and enable the network init.d script instead. You may feel this is the "old" way of doing things, but it's tried and tested and works well (for us).
I'm not saying it's impossible with some unknown amount of effort to configure NetworkMananger to do the right thing in all instances. It's just not been worth the time to debug when there's more important stuff to do and the tried and tested way works.
to satisfy both sides NetworkManager is enabled by default in client versions (Workstation, Client) and not installed by default in server versions.
not install or not enabled when installed? I thought that the idea was that NetworkManager would always be enabled (initscript on) by default when the rpm was installed. But we just weren't going to make NetworkManager be part of the default install everything bug Workstation and Client variants.
Sorry, my inaccuracy. NM is installed (and enabled) by default in client variants and not installed by default in server variants. The service is enabled after the rpm is installed (POSTIN)
if [ "$1" == "1" ]; then
/sbin/chkconfig --add NetworkManager
/sbin/chkconfig NetworkManager resetpriorities
so it is enabled by default.
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.