Mailinglist Archive: opensuse-features (328 mails)

< Previous Next >
[openFATE 310004] integrate network manager with the traditional method of network configuration (updated)
  • From: fate_noreply@xxxxxxx
  • Date: Fri, 9 Jul 2010 08:47:02 +0200 (CEST)
  • Message-id: <feature-310004-20@xxxxxxxxxxxxxx>
Feature changed by: Rob Verduijn (robverduijn)
Feature #310004, revision 20
Title: integrate network manager with the traditional method of network
configuration (updated)

openSUSE-11.3: Unconfirmed
Requester: Important

Requested by: Thiago Sayao (sayao)

(This description was updated)
The original proposal was to replace the traditional method of network
configuration by network manager. This idea was not very well accepted
because it has some drawbacks, specially when network is needed before
the desktop is ready and networkmanager is loaded. Also network manager
is not well suitable for servers.
But the actual solution is not well suitable for the average computer
users (excluding experts, geeks, ...). The average computer user does
not know the difference between the common method and the network
manager. This kind of user needs some solution that " just works ".
The average users (like John on the usecase) just wants to have the
network working, does not matter where he is (on a coffee shop, on a
train station, on the airport, at the company or at home). This common
user just wants to click a button (when multiple networks are
available) and select which one to use. Network Manager is better
suitable for this than the traditional method.
So we need a solution that works for either situations: When the
network is needed before the desktop is ready (for servers, network
login, ...) and for easy and quick network detection/setup.
I think this can be archived by integrating both network manager and
the traditional method into one solution. In this integrated solution,
the traditional method would be the "central" method and the network
manager would be an user interface/developer API to communicate with
the "central" method. Like this:
User interface -> Network manager -> Traditional Method ->
This is just an idea of how to do it, but others are accepted. The
feature proposal is to have something that "just works" for the varios
combinations of network environments.
Also, the API part is very important and network manager provides this
for desktop developers to know information about the network (for
example, if the network is connected or not).
Thank you for everyone who contributed on the comments.

Use Case:
Network Manager
John always have his laptop with him and likes to use it on differente
coffe shops, at the airports and at home. He uses network manager for
easier configuration and he is not and "advanced" user.
Chuck is a system administrator and has a linux server with text
(terminal) only (no graphical interfaces). The server obviously stays
on the same place always plugged on the same static network.

#1: Ilya Chernykh (ansus) (2010-06-27 08:57:27)
Bad idea.
1. Network manager cannot restore VPN connections on startup (many
users connect Internet through VPN)
2. Network manager does not remember routes correctly
3. Network manager is compatible with only limited number of desktop
4. Network manager does not keep connection when exiting the session
and logging in another desktop.
- Many other drawbacks. The SUSE standard ifup- based system the most
functional of any other variants so far and easily configured.

#2: Thiago Sayao (sayao) (2010-06-27 20:13:17) (reply to #1)
Humm, i suspected there would be drawbacks. What about integrating
It does not seem right to have two methods of configuring the network,
where one method works better for some things and the other works
better for others. In the best scenario there would be one method there
is the best for everything.
Some gnome apps uses network manager to check if the network is up for

#3: Rajko Matovic (rajko_m) (2010-07-01 05:41:22)
Network Manager is default last few releases. 

#4: Rob Verduijn (robverduijn) (2010-07-05 15:34:04)
My biggest objection to network manager is that when using a laptop the
network is not started until the desktop is visible.
This is a serious problem when you wish to authenticate against
ie the network is needed for authentication, but it will not be started
untill after your authentication.
Last time I checked it is default when using a laptop with a wifi
adapter, when using a wired (no-wifi) desktop I always find traditional
network management installed.

#5: Rob Verduijn (robverduijn) (2010-07-05 15:38:05)
I just saw you could misinterpret my problem.
Let me try again.
My biggest objection to network manager is that when using a wireless
connection on a laptop the network is not started until the desktop is

#6: Ned Ulbricht (ned_ulbricht) (2010-07-05 17:07:58)
Imho, NetworkManager is inappropriate for servers.  Around here,
servers have a static network configuration.  If the network goes down
for any reason, then I've got to bring up a remote serial console to
talk to the box.
"Servers" include general-purpose application/cycle servers for a multi-
user environment:  Iow, something that you might think of as a
I don't care whether the standard install defaults to
NetworkManager.  I can fix that. But I do care about support for a
reliable, locked-down, static network configuration.  Further, I don't
want to see rpm dependencies on NetworkManager--I don't want it
installed on machines where static networking is required.

#7: Thiago Sayao (sayao) (2010-07-07 15:41:28)
for everyone that voted no, please reconsider as described on the
updates (see the use case) and updated title and descriptions.

#8: Rob Verduijn (robverduijn) (2010-07-07 17:24:11)
I don't see what you mean with best of both worlds.
I'm not going for something abstract like " integrate NetworkManager
and the traditional method ".
Experiences teaches people have different interpretations for abstract
Make it clear what you mean by best of both worlds untill then no
Here's my view
* make it possible to deselect network manager during installation
   allow to select the traditional option during installation, no
matter how much improvements
   you create, there will always be people that prefer to use the good
old traditional way
* static default configs manageable from cli and optionally from gui
   I'm talking yast and yast2 (or whatever tool you wish to use)
   a server system is unlikely to have a bluetooth/wifi/usb network
adapter and is also likely to
   run in text mode with no xdm/kde/gnome/whatever-gui installed
   the static config should also be usable for devices that do not
start with eth
   like wifi/usb/bluetooth/irda/whatever
* cli and gui configs/tools must be compatibl
   this is sadly not plain obvious ..... the current network manager
has a cli version to
   takes some effort but you can find it with the rpm search on
   but.... when you first start in runlevel 3 and define a network and
later switch to runlevel 5
   the gui version refuses to work because there is already a network
manager active .....
* config files must be in the etc folder and also human readable
   if the manager needs a binary config make it check for changes
during startup and generate
   it including syntax validation with errors that can be understood
without the
   use of google  (I'm still having sendmail config nightmares)
   ofcourse there may be user configs (see below)
   the exception to the human readable are certs or keys needed for the
   wpa/wpa2 keys and the like must be stored in a secure way in the etc
   cli tools must be provided to manage those keys/certs yast is not
enough think scriptable
* make it compatible with PAM!!!!
   that way you have all the traditional authentication methods
   and it solves a lot of the above mentioned problems
* there are more ways to store passwords/keys/certs than wallet
   make it possible to use those to.
* the network must be able to be up and running before the login
   current network manager on a laptop with only wifi requires the user
to log in to start the
   network, this is a pita when you need to authenticate against
* enable users to connect to different type off networks if needed
    whatever they can think off wifi , usb network cards, modems,
bluetooth, irda or devices that
    you didn't know existed. (ie make it easy to create a plugin for
    give the desktop a nice little icon in the taskbar for them to
click on for this.
    again human readable configs and secure keys/certs storage.
    believe it or not, networks are not limited to a certain desktop
flavor, so do not put the
    configs for this in your favorite desktop manager config dir but in
a more common location in
    the user home dir
* firewall integration
   when a new network device is hot plugged it would be nice to have a
firewall (optional) in
   place when it becomes active.
* make it work properly withe routes (have it do the right thing)
   try this ... use laptop with wifi and wired connection and network
   define wifi lan connection, put wired connection on dhcp.
   disconnect utp cable
   turn off laptop
   turn on laptop
   wait for desktop
   log in and wait for the wifi network to connect
   connect utp
   wait for dhcp to assign ip to wired network card
   turn off wifi
   check the default's gone
   turning on the wifi again will not give you the default route back

#9: Thiago Sayao (sayao) (2010-07-08 01:26:29) (reply to #8)
The intention was to propose something that just works , without the
user having to worry about which method to choose (i think a lot of
users do not know the differences between both methods - i confess i do
not know all the diferences, just the most obvious ones).
So the idea is to have only one configuration method (in the user
perception) and the proposal is to integrate both.
I do not think the user (advanced or not) should select one method or
another. The user should only configure the network. He may have
multiple user interfaces to do that (like gnome/kde/human readable
file) but not two indepentent methods, were one is better for some
things and the other for other things.
To archive that, maybe networkmanager have to be modified or the
"traditional method" or even both. Maybe even a NetworkManager 2.0 that
has the features of both methods.
What do you think?
Thank you.

+ #10: Rob Verduijn (robverduijn) (2010-07-09 08:46:55) (reply to #9)
+ Sounds great
+ I've adjusted my vote

openSUSE Feature:

< Previous Next >
List Navigation
This Thread