Home_greyopenFATE - openSUSE feature tracking > #310004
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

have a network configuration solution that is well suitable for servers, network login and quick network detection/setup

Feature state

openSUSE-11.3
Unconfirmed

Description

(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 -> Configuration.

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.

Usecase

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.

Traditional

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.

Discussion


icons/user_comment.png I. C. wrote: (4 years ago)

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 environments

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.

icons/user_comment.png T. S. wrote: (4 years ago)

Humm, i suspected there would be drawbacks. What about integrating both?

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 example.

icons/user_comment.png R. M. wrote: (4 years ago)

Network Manager is default last few releases. 

icons/user_comment.png R. V. wrote: (4 years ago)

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 samba/ldap/radius/etc.

ie the network is needed for authentication, but it will not be started untill after your authentication.

p.s.

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.

icons/user_comment.png R. V. wrote: (4 years ago)

addendum

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 visible.

icons/user_comment.png N. U. wrote: (4 years ago)

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 "desktop".

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.

icons/user_comment.png T. S. wrote: (4 years ago)

for everyone that voted no, please reconsider as described on the updates (see the use case) and updated title and descriptions.

icons/user_comment.png I. C. wrote: (4 years ago)

I think you should start a new feature on this because this new proposal I would say, the opposite of the initial one.

icons/user_comment.png R. V. wrote: (4 years ago)

or edit the topic :P

icons/user_comment.png R. V. wrote: (4 years ago)

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 statements.

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 opensuse.org

   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 network

   wpa/wpa2 keys and the like must be stored in a secure way in the etc dir

   cli tools must be provided to manage those keys/certs yast is not enough think scriptable

   tools

* make it compatible with PAM!!!!

   that way you have all the traditional authentication methods available.

   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 happens.

   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 ldap/samba/radius

* 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 devs)

    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 manager

   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 gateway....it's gone

   turning on the wifi again will not give you the default route back

icons/user_comment.png T. S. wrote: (4 years ago)

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.

icons/user_comment.png R. V. wrote: (4 years ago)

Sounds great

I've adjusted my vote

icons/user_comment.png T. S. wrote: (3 years ago)

Updated the title as requested on previous comments.

icons/user_comment.png N. U. wrote: (3 years ago)

Implementation Details

This propoosal's latest update  moves beyond the "What" into the "How". You're suggesting that NetworkManager should funnel it's control through the traditional network setup.

In theory, requirements should focus mostly on the "What" and hand-wave around the "How". In practice, well....  My biggest objection to NetworkManager right now is it's dependency on D-Bus.  For
reliability , I need to be able to configure network interfaces and bring them up and down without the system
dbus-daemon
running.  Similarly, I need to get DNS resolution going in the face of a hosed
dbus-daemon.

I haven't looked too closely at what NetworkManager actually does.  (In fact, that's a secondary problem I have with NetworkManager:  Code that configures networking needs to have
auditability and then be actually audited.  I haven't audited NetworkManager.  Anyhow...)  My guess is that the NetworkManager developers would point out that it's reasonable for them to absolutely depend on D-Bus IPC given the environment they're targetting.

icons/user_comment.png R. V. wrote: (3 years ago)

Agreed.

shall we add

*must have the same dependecys as the traditional network setup for operation in cli mode?

  if you're spending system resources on a gui, a bit more for a dbus deamon won't hurt

To the what list ?

icons/user_comment.png N. U. wrote: (3 years ago)

"Traditional" dependencies seems like a kinda vagueish requirement to me.

Is
udevd
"traditional"?  Whether it is or not, at this point it seems like a reasonable dependency.

Otoh, I think the basic network setup should continue to support
NFS /usr.  That'd almost be solely for tradition--local storage is pretty cheap these days.  Except that keeping a small root filesystem is still relevant for initramfs images.  It should be possible to bring up the network from a small initramfs.  We just haven't agreed on what utilities belong in a tiny initramfs (and may never agree on that--too much variation).  So the FHS gives us an agreement on what belongs in a "traditional" spinning root filesystem.

icons/user_comment.png R. V. wrote: (3 years ago)

By traditional I mean the tools you iuse on to bring the network interface up or down in the past (and for lotsa people the present).

If the term traditional for some reason made you think I was referring to filesystems, I apologise I should have explained more clearly in my previous posts.

icons/user_comment.png N. U. wrote: (3 years ago)

No, the miscommunication here is my fault:  I was using the filesystems as shorthand to refer to  collections of tools and libraries.

For me, using the
if{up,down}
scripts is almost as immaterial as whether those shell scripts call
ifconfig
and
route
internally or call
/sbin/ip
.  The important point is that they aren't python scripts, and aren't hooked up to PolicyKit via
/usr/lib/libgobject.

Further, there's an accepted rationale behind the use of a limited toolset.  That rationale is laid out at the beginning of Chapter 3 in the Filesystem Hierarchy Standard (FHS) version 2.3.

Unfortunately, even though I just said the rationale is "accepted", I'll acknowledge that underlying that historic rationale is a somewhat outdated set of economic assumptions.  And the FHS isn't gospel handed down for all ages--the reasoning there should be open to re-examination.

Re-examining the limitation of a small toolset on the root filesystem--I think it still makes sense.  Not because I want to NFS-mount /usr,  but because I occasionally want to PXE boot to a NFS root.

Last change: 3 years ago
Voting
Score: -1
  • Negative: 8
  • Neutral: 0
  • Positive: 7
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint