Feature changed by: Thiago Sayao (sayao) Feature #310004, revision 4 Title: use network manager by default instead of traditional method openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Thiago Sayao (sayao) Description: Use network manager by default instead of traditional method. Network Manager integrates better with the desktop and seems easier to configure (for example, to configure a VPN). I'm not sure about the features the traditional method provides and Network Manager does not, so please, discuss.   Discussion: #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 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. + #2: Thiago Sayao (sayao) (2010-06-27 20:13:17) (reply to #1) + 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. -- openSUSE Feature: https://features.opensuse.org/310004

Feature changed by: Rob Verduijn (robverduijn) Feature #310004, revision 7 Title: use network manager by default instead of traditional method openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Thiago Sayao (sayao) Description: Use network manager by default instead of traditional method. Network Manager integrates better with the desktop and seems easier to configure (for example, to configure a VPN). I'm not sure about the features the traditional method provides and Network Manager does not, so please, discuss.   Discussion: #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 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. #2: Thiago Sayao (sayao) (2010-06-27 20:13:17) (reply to #1) 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. #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 + 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. +   -- openSUSE Feature: https://features.opensuse.org/310004

Feature changed by: Ned Ulbricht (ned_ulbricht) Feature #310004, revision 10 Title: use network manager by default instead of traditional method openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Thiago Sayao (sayao) Description: Use network manager by default instead of traditional method. Network Manager integrates better with the desktop and seems easier to configure (for example, to configure a VPN). I'm not sure about the features the traditional method provides and Network Manager does not, so please, discuss.   Discussion: #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 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. #2: Thiago Sayao (sayao) (2010-06-27 20:13:17) (reply to #1) 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. #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 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.   #5: Rob Verduijn (robverduijn) (2010-07-05 15:38:05) 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. + #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 + "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. +   -- openSUSE Feature: https://features.opensuse.org/310004

Feature changed by: Thiago Sayao (sayao) Feature #310004, revision 12 - Title: use network manager by default instead of traditional method + Title: integrate network manager with traditional method of network + configuration (updated) openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Thiago Sayao (sayao) Description: Use network manager by default instead of traditional method. Network Manager integrates better with the desktop and seems easier to configure (for example, to configure a VPN). I'm not sure about the features the traditional method provides and Network Manager does not, so please, discuss. UPDATE : Since the traditional method is needed on some environments (as listed on the comments) consider the option to integrate NetworkManager and the traditional method so we have the best of both. Discussion: #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 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. #2: Thiago Sayao (sayao) (2010-06-27 20:13:17) (reply to #1) 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. #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 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.   #5: Rob Verduijn (robverduijn) (2010-07-05 15:38:05) 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. #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 "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.   -- openSUSE Feature: https://features.opensuse.org/310004

Feature changed by: Thiago Sayao (sayao) Feature #310004, revision 14 Title: integrate network manager with the traditional method of network configuration (updated) openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Thiago Sayao (sayao) Description: Use network manager by default instead of traditional method. Network Manager integrates better with the desktop and seems easier to configure (for example, to configure a VPN). I'm not sure about the features the traditional method provides and Network Manager does not, so please, discuss. UPDATE : Since the traditional method is needed on some environments (as listed on the comments) consider the option to integrate NetworkManager and the traditional method so we have the best of both. + 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. +   + 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: #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 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. #2: Thiago Sayao (sayao) (2010-06-27 20:13:17) (reply to #1) 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. #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 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.   #5: Rob Verduijn (robverduijn) (2010-07-05 15:38:05) 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. #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 "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.   -- openSUSE Feature: https://features.opensuse.org/310004

Feature changed by: Rob Verduijn (robverduijn) Feature #310004, revision 16 Title: integrate network manager with the traditional method of network configuration (updated) openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Thiago Sayao (sayao) Description: Use network manager by default instead of traditional method. Network Manager integrates better with the desktop and seems easier to configure (for example, to configure a VPN). I'm not sure about the features the traditional method provides and Network Manager does not, so please, discuss. UPDATE : Since the traditional method is needed on some environments (as listed on the comments) consider the option to integrate NetworkManager and the traditional method so we have the best of both. 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.   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: #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 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. #2: Thiago Sayao (sayao) (2010-06-27 20:13:17) (reply to #1) 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. #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 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.   #5: Rob Verduijn (robverduijn) (2010-07-05 15:38:05) 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. #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 "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.   #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 + 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 -- openSUSE Feature: https://features.opensuse.org/310004

Feature changed by: Thiago Sayao (sayao) Feature #310004, revision 18 Title: integrate network manager with the traditional method of network configuration (updated) openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Thiago Sayao (sayao) Description: - Use network manager by default instead of traditional method. Network - Manager integrates better with the desktop and seems easier to - configure (for example, to configure a VPN). - I'm not sure about the features the traditional method provides and - Network Manager does not, so please, discuss. - UPDATE : Since the traditional method is needed on some environments - (as listed on the comments) consider the option to integrate - NetworkManager and the traditional method so we have the best of both. + (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). +   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.   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: #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 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. #2: Thiago Sayao (sayao) (2010-06-27 20:13:17) (reply to #1) 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. #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 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.   #5: Rob Verduijn (robverduijn) (2010-07-05 15:38:05) 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. #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 "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.   #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 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 #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.   -- openSUSE Feature: https://features.opensuse.org/310004

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 Priority Requester: Important Requested by: Thiago Sayao (sayao) 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.   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.   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: #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 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. #2: Thiago Sayao (sayao) (2010-06-27 20:13:17) (reply to #1) 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. #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 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.   #5: Rob Verduijn (robverduijn) (2010-07-05 15:38:05) 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. #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 "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.   #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 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 #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: https://features.opensuse.org/310004

Feature changed by: Rob Verduijn (robverduijn) Feature #310004, revision 22 Title: integrate network manager with the traditional method of network configuration (updated) openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Thiago Sayao (sayao) 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.   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.   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: #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 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. #2: Thiago Sayao (sayao) (2010-06-27 20:13:17) (reply to #1) 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. #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 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.   #5: Rob Verduijn (robverduijn) (2010-07-05 15:38:05) 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. #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 "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.   #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. #11: Ilya Chernykh (ansus) (2010-07-09 14:15:28) (reply to #7) I think you should start a new feature on this because this new proposal I would say, the opposite of the initial one. + #12: Rob Verduijn (robverduijn) (2010-07-09 14:49:53) (reply to #11) + or edit the topic :P #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 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 #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: https://features.opensuse.org/310004

Feature changed by: Ned Ulbricht (ned_ulbricht) Feature #310004, revision 24 Title: have a network configuration solution that is well suitable for servers, network login and quick network detection/setup openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Thiago Sayao (sayao) 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.   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.   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: #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 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. #2: Thiago Sayao (sayao) (2010-06-27 20:13:17) (reply to #1) 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. #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 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.   #5: Rob Verduijn (robverduijn) (2010-07-05 15:38:05) 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. #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 "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.   #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. #11: Ilya Chernykh (ansus) (2010-07-09 14:15:28) (reply to #7) I think you should start a new feature on this because this new proposal I would say, the opposite of the initial one. #12: Rob Verduijn (robverduijn) (2010-07-09 14:49:53) (reply to #11) or edit the topic :P #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 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 #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 #13: Thiago Sayao (sayao) (2010-07-12 15:45:50) Updated the title as requested on previous comments. + #14: Ned Ulbricht (ned_ulbricht) (2010-07-12 17:34:15) + 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. -- openSUSE Feature: https://features.opensuse.org/310004

Feature changed by: Ned Ulbricht (ned_ulbricht) Feature #310004, revision 26 Title: have a network configuration solution that is well suitable for servers, network login and quick network detection/setup openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Thiago Sayao (sayao) 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.   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.   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: #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 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. #2: Thiago Sayao (sayao) (2010-06-27 20:13:17) (reply to #1) 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. #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 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.   #5: Rob Verduijn (robverduijn) (2010-07-05 15:38:05) 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. #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 "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.   #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. #11: Ilya Chernykh (ansus) (2010-07-09 14:15:28) (reply to #7) I think you should start a new feature on this because this new proposal I would say, the opposite of the initial one. #12: Rob Verduijn (robverduijn) (2010-07-09 14:49:53) (reply to #11) or edit the topic :P #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 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 #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 #13: Thiago Sayao (sayao) (2010-07-12 15:45:50) Updated the title as requested on previous comments. #14: Ned Ulbricht (ned_ulbricht) (2010-07-12 17:34:15) 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. #15: Rob Verduijn (robverduijn) (2010-07-12 20:49:43) (reply to #14) 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 ? + #16: Ned Ulbricht (ned_ulbricht) (2010-07-13 01:24:03) (reply to #15) + "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. -- openSUSE Feature: https://features.opensuse.org/310004

Feature changed by: Ned Ulbricht (ned_ulbricht) Feature #310004, revision 28 Title: have a network configuration solution that is well suitable for servers, network login and quick network detection/setup openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Thiago Sayao (sayao) 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.   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.   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: #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 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. #2: Thiago Sayao (sayao) (2010-06-27 20:13:17) (reply to #1) 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. #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 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.   #5: Rob Verduijn (robverduijn) (2010-07-05 15:38:05) 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. #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 "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.   #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. #11: Ilya Chernykh (ansus) (2010-07-09 14:15:28) (reply to #7) I think you should start a new feature on this because this new proposal I would say, the opposite of the initial one. #12: Rob Verduijn (robverduijn) (2010-07-09 14:49:53) (reply to #11) or edit the topic :P #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 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 #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 #13: Thiago Sayao (sayao) (2010-07-12 15:45:50) Updated the title as requested on previous comments. #14: Ned Ulbricht (ned_ulbricht) (2010-07-12 17:34:15) 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. #15: Rob Verduijn (robverduijn) (2010-07-12 20:49:43) (reply to #14) 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 ? #16: Ned Ulbricht (ned_ulbricht) (2010-07-13 01:24:03) (reply to #15) "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. #17: Rob Verduijn (robverduijn) (2010-07-13 08:20:23) (reply to #16) 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. + #18: Ned Ulbricht (ned_ulbricht) (2010-07-13 14:56:12) (reply to #17) + 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. -- openSUSE Feature: https://features.opensuse.org/310004