Not logged in
Log in now
Create an account
Subscribe to LWN
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
LWN.net Weekly Edition for June 6, 2013
Network Manager and Servers
Posted Mar 2, 2012 14:44 UTC (Fri) by alex (subscriber, #1355)
Posted Mar 2, 2012 17:42 UTC (Fri) by iabervon (subscriber, #722)
Posted Mar 2, 2012 20:14 UTC (Fri) by xtifr (subscriber, #143)
Posted Mar 5, 2012 8:02 UTC (Mon) by drag (subscriber, #31333)
I don't yet, except at home. But I don't see any problem with using it on a server. The reason I don't simply has to do with inertia... have something that works so why bother caring?
But NetworkManager itself is stable and has relatively low overhead.
Networkmanager-dispatcher allows you to create custom scripts to respond to network changes in a similar fashion to ifup/ifdown script. Probably makes it a bit easier in practice, actually, if you want to fully automate everything. It's easy to use that sort of thing to deal with protocols/configurations that NetworkManager doesn't support natively*.
*((not related to servers) so if you run into situations were you Gnome laptop goes to sleep and loses your weird VPN setup is lost every time you close the lid without thinking about it... you can write a script to deal with it proactively instead of trying to figure out how to turn off your power management features. :) )
I expect that for most people the resistance comes from a perception that you need a GUI to manage NetworkManager. A second issue that it is not able to deal with configurations were you don't have a user logged in. Also I expect that the third big perception problem comes from people believing that NetworkManager uses some hidden binary database or format to store it's configurations and you must use weird dbus scripts or whatever to edit configs.
These perceptions are largely false, though, if you configure NetworkManager correctly for a server setup.
I'll deal with the perception issues like so...
1. uses a secret database to store your configurations.
2. requires GUI tools to manage your network connections, or at least terrible command line scripts.
3. requires a user to be logged in to have a network connection.
For issue #1. NetworkManager supports a number of configuration backends which are configured as 'plugins' in /etc/NetworkManager/NetworkManager.conf
The plugins that I am aware of are:
ifupdown --> Supports pre-NM Debian network configs.
ifcfg-rh --> Supports Redhat ifcfg scripts
keyfile --> Uses NetworkManager's native ini-style file format at /etc/NetworkManager/system-connections
Now I don't know about ifupdown support in NetworkManager, but the ifcfg-rh is blatantly terrible. It doesn't support all the same options and many things are interpreted differently then the ifcfg documentation and examples would suggest. On top of that many types of devices NetworkManager supports is incompatible with it. So I recommend disabling ifcfg-rh altogether and using keyfile if you are using NetworkManager in a server.
More documentation and details can be found at:
This is the most relevant documentation:
Here are the connection settings for 0.9 (older versions are similar)
(which is irritatingly difficult to find)
I recommend turn on the keyfile plugin, if it's not enabled, and then configuring some interfaces from the GUI to help get you some examples to help you learn the NM .ini format.
For issue #2 (no commandline/bad command line tools)
Once you get keyfile plugin enabled and got some sample configurations going then playing around with 'nmcli' is what you want:
for current status:
nmcli con status id 'Wired connnection 1'
to bring it down:
nmcli con down id 'Wired connection 1'
to then disconnect the device:
nmcli dev disconnect iface eth0
start it back up:
nmcli con up id 'Wired connection 1'
The principal arguments are going to be nm, con, and dev. Check out the man file.
For issue #3, user required to be logged in...
Check out the 'permissions' setting in the ref-settings page. If that 'permissions=' line is missing or empty in the configuration file for that interface then it should auto start.
In the GUI it's controlled by 'enabled for all users' checkmark in the network configurations dialogs.
The one thing to watch out for, IIRC, is that changes those files are monitored by NetworkManager. So editing them in-place is a bad idea. If you want to edit the configuration files manually, copy them to another directory, edit them, then copy them back. NetworkManager will act on changes to configurations automatically.
What is the advantage for a server to use NetworkManager? If you just have one or two statically configured ethernet devices.. then not much.
But you can control many types of network connections in a uniform and cross distro way in a easily scriptable way...
802.1x network controls (don't confuse with 802.11 wireless..), bluetooth networking, cdma, gsm, ipv4 settings, ipv6 settings, 802.11 mesh networking, ppp connections, serial devices, ppoe, several types of vpns, wimax, 802.3 (ethernet), 802.11 wireless, WEP/WPA-PSK/WPA-EAP settings.
So managing those sorts of devices gains a lot more consistency then in the past.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds