Hi All,
In both Leap & Tumbleweed we currently have the following logic for choosing which tool manages your network after installation
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
I've noticed an increasing trend that this can lead to confusion.
Many users from other distributions expect NetworkManager on their desktops regardless of whether they are using a laptop or a desktop.
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
There are certainly classes of hardware where NetworkManager might be wanted that will never match "IF laptop" - eg. my personal Inter Compute Stick.
And "IF laptop" is dependant on YaST correctly detecting you're using a laptop, which isn't 100% accurate, so occasionally even laptops might end up with wicked unexpectedly.
I would like to propose a possible solution.
It looks like we should be able to pin the choice of network tool to specific system role.
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
Custom will keep the current "autodetect" behaviour, because we cant be sure that the environment that the user is installing has support for NetworkManager in this case.
Whatever is setup "by default" during installation will be able to be changed in YAST after the installation, just like it is today.
What do we all think? If there is strong support for this idea I think Ludwig is prepared to let me try and slip it in as a late feature for Leap 15, so please let your opinions be heard loudly and quickly either way.
Regards,
Richard
[1] http://paste.opensuse.org/33301696
On 2018-04-10 12:16, Richard Brown wrote:
And "IF laptop" is dependant on YaST correctly detecting you're using a laptop, which isn't 100% accurate, so occasionally even laptops might end up with wicked unexpectedly.
This would be solved by YaST asking for the computer role. I've suggested this for centuries ;-)
On 10/04/18 19:46, Richard Brown wrote:
Hi All,
In both Leap & Tumbleweed we currently have the following logic for choosing which tool manages your network after installation
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
I've noticed an increasing trend that this can lead to confusion.
Many users from other distributions expect NetworkManager on their desktops regardless of whether they are using a laptop or a desktop.
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
There are certainly classes of hardware where NetworkManager might be wanted that will never match "IF laptop" - eg. my personal Inter Compute Stick.
And "IF laptop" is dependant on YaST correctly detecting you're using a laptop, which isn't 100% accurate, so occasionally even laptops might end up with wicked unexpectedly.
I would like to propose a possible solution.
It looks like we should be able to pin the choice of network tool to specific system role.
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
Custom will keep the current "autodetect" behaviour, because we cant be sure that the environment that the user is installing has support for NetworkManager in this case.
Whatever is setup "by default" during installation will be able to be changed in YAST after the installation, just like it is today.
What do we all think? If there is strong support for this idea I think Ludwig is prepared to let me try and slip it in as a late feature for Leap 15, so please let your opinions be heard loudly and quickly either way.
Regards,
Richard
I have also thought about something like this in the past as it makes more sense for all of enlightenment to default to network manager as well, rather then just basing it on a role would it be possible to have a "Network Manager Default" package then we could do it on a pattern or package basis rather then per role, I'd much rather a solution that can fix the issue properly for everything. A downside to that is if not done right it could lead to people being magically swapped from one to the other on tumbleweed which we may not want.
Cheers
On Tuesday, 10 April 2018 12:16 Richard Brown wrote:
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
I don't see much benefit of NetworkManager on a typical desktop machine. IIUC the desire for NetworkManager is mainly for easier management of wi-fi connections. How about using NetworkManager by default if there is a wi-fi device and wicked if not?
Michal Kubeček
On 04/10/2018 01:04 PM, Michal Kubecek wrote:
On Tuesday, 10 April 2018 12:16 Richard Brown wrote:
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
I don't see much benefit of NetworkManager on a typical desktop machine. IIUC the desire for NetworkManager is mainly for easier management of wi-fi connections. How about using NetworkManager by default if there is a wi-fi device and wicked if not?
Well, that leaves still an unpleasant experience to those that add hotplug devices.
I'd claim that users don't care so much what makes their LAN work as long as it works. And IMO wicked isn't any easier to debug if it doesn't work than NM is. So if it simplifies our desktops, I'm all for simplifying by 'roles' (aka desktops).
Greetings, Stephan
Op dinsdag 10 april 2018 13:13:24 CEST schreef Stephan Kulow:
On 04/10/2018 01:04 PM, Michal Kubecek wrote:
On Tuesday, 10 April 2018 12:16 Richard Brown wrote:
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
I don't see much benefit of NetworkManager on a typical desktop machine. IIUC the desire for NetworkManager is mainly for easier management of wi-fi connections. How about using NetworkManager by default if there is a wi-fi device and wicked if not?
Well, that leaves still an unpleasant experience to those that add hotplug devices.
I'd claim that users don't care so much what makes their LAN work as long as it works. And IMO wicked isn't any easier to debug if it doesn't work than NM is. So if it simplifies our desktops, I'm all for simplifying by 'roles' (aka desktops).
Greetings, Stephan
+1 from me.
On 2018-04-10 13:04, Michal Kubecek wrote:
On Tuesday, 10 April 2018 12:16 Richard Brown wrote:
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
I don't see much benefit of NetworkManager on a typical desktop machine. IIUC the desire for NetworkManager is mainly for easier management of wi-fi connections. How about using NetworkManager by default if there is a wi-fi device and wicked if not?
My home server has both ethernet and WiFi hardware.
On Tuesday, 10 April 2018 13:46 Carlos E. R. wrote:
On 2018-04-10 13:04, Michal Kubecek wrote:
On Tuesday, 10 April 2018 12:16 Richard Brown wrote:
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
I don't see much benefit of NetworkManager on a typical desktop machine. IIUC the desire for NetworkManager is mainly for easier management of wi-fi connections. How about using NetworkManager by default if there is a wi-fi device and wicked if not?
My home server has both ethernet and WiFi hardware.
There will always be exceptions, sure, but I wanted to minimize the damage. But it seems inevitable so let's just add another entry to my "distribution defaults to override on all new installations" list.
On the plus side, ending up with NetworkManager was always a nasty surprise when I installed openSUSE on a notebook; if it's going to be default everywhere, I'll be less likely to forget. :-)
Michal Kubeček
On Tue, 2018-04-10 at 14:03 +0200, Michal Kubecek wrote:
On Tuesday, 10 April 2018 13:46 Carlos E. R. wrote:
On 2018-04-10 13:04, Michal Kubecek wrote:
On Tuesday, 10 April 2018 12:16 Richard Brown wrote:
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
I don't see much benefit of NetworkManager on a typical desktop machine. IIUC the desire for NetworkManager is mainly for easier management of wi-fi connections. How about using NetworkManager by default if there is a wi-fi device and wicked if not?
My home server has both ethernet and WiFi hardware.
There will always be exceptions, sure, but I wanted to minimize the damage. But it seems inevitable so let's just add another entry to my "distribution defaults to override on all new installations" list.
Hm. Three of my four boxen are "exceptions", the :) exception being my HP lappy (spectre 360), which has only wi-fi.
-Mike
On 04/10/2018 05:55 AM, Mike Galbraith wrote:
On Tue, 2018-04-10 at 14:03 +0200, Michal Kubecek wrote:
On Tuesday, 10 April 2018 13:46 Carlos E. R. wrote:
My home server has both ethernet and WiFi hardware.
There will always be exceptions, sure, but I wanted to minimize the damage. But it seems inevitable so let's just add another entry to my "distribution defaults to override on all new installations" list.
Hm. Three of my four boxen are "exceptions", the :) exception being my HP lappy (spectre 360), which has only wi-fi.
Starting to look like the "exceptions" are more common than the non-"exceptions". :-D
*ALL* of my machines are running ethernet NIC and WiFi.
Quite often, both are pressed into use at the same time to access two separate LANs on separate routers at the same time for maintenance or administrative purposes.
They also need to be switched off and on at will.
Network Manager makes the best default for me, for my clients, and for anyone else I am volunteering support for.
I like Richard's proposal as a step in the right direction.
On Tue, 2018-04-10 at 17:50 -0700, Fraser_Bell wrote:
Network Manager makes the best default for me, for my clients, and for anyone else I am volunteering support for.
I'm agnostic: both are annoying, just in different ways :)
-Mike
On Wed, 11 Apr 2018 06:12:56 +0200 Mike Galbraith mgalbraith@suse.de wrote:
On Tue, 2018-04-10 at 17:50 -0700, Fraser_Bell wrote:
Network Manager makes the best default for me, for my clients, and for anyone else I am volunteering support for.
I'm agnostic: both are annoying, just in different ways :)
Cannot agree more.
There is some hope that putting effort into improving upstream solution which already exists and is competitive with SUSE solution will provide better product in the long term through synergy with other contributors.
It may not necessarily work out that way, though.
Thanks
Michal
On Wednesday, 11 April 2018 2:50 Fraser_Bell wrote:
On 04/10/2018 05:55 AM, Mike Galbraith wrote:
On Tue, 2018-04-10 at 14:03 +0200, Michal Kubecek wrote:
On Tuesday, 10 April 2018 13:46 Carlos E. R. wrote:
My home server has both ethernet and WiFi hardware.
There will always be exceptions, sure, but I wanted to minimize the damage. But it seems inevitable so let's just add another entry to my "distribution defaults to override on all new installations" list.
Hm. Three of my four boxen are "exceptions", the :) exception being my HP lappy (spectre 360), which has only wi-fi.
Starting to look like the "exceptions" are more common than the non-"exceptions". :-D
Does it?
*ALL* of my machines are running ethernet NIC and WiFi. ... Network Manager makes the best default for me, for my clients, and for anyone else I am volunteering support for.
In other words, you would be perfectly fine with what I proposed.
Michal Kubeček
Fraser_Bell wrote:
On 04/10/2018 05:55 AM, Mike Galbraith wrote:
On Tue, 2018-04-10 at 14:03 +0200, Michal Kubecek wrote:
On Tuesday, 10 April 2018 13:46 Carlos E. R. wrote:
My home server has both ethernet and WiFi hardware.
There will always be exceptions, sure, but I wanted to minimize the damage. But it seems inevitable so let's just add another entry to my "distribution defaults to override on all new installations" list.
Hm. Three of my four boxen are "exceptions", the :) exception being my HP lappy (spectre 360), which has only wi-fi.
Starting to look like the "exceptions" are more common than the non-"exceptions". :-D
*ALL* of my machines are running ethernet NIC and WiFi.
Here (office landscape), only laptops have wifi.
Le mardi 10 avril 2018 à 13:04 +0200, Michal Kubecek a écrit :
On Tuesday, 10 April 2018 12:16 Richard Brown wrote:
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
I don't see much benefit of NetworkManager on a typical desktop machine.
Proper integration in the desktop of VPN start / stop.
Frederic Crozat wrote:
Le mardi 10 avril 2018 à 13:04 +0200, Michal Kubecek a écrit :
On Tuesday, 10 April 2018 12:16 Richard Brown wrote:
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
I don't see much benefit of NetworkManager on a typical desktop machine.
Proper integration in the desktop of VPN start / stop.
Perhaps not of great use to the average desktop user, but yes. How about NFS-mounted shares - last I looked (42.3), it took some work to get those integrated.
On Wed, 11 Apr 2018 18:25:59 +0200 Per Jessen per@computer.org wrote:
Frederic Crozat wrote:
Le mardi 10 avril 2018 à 13:04 +0200, Michal Kubecek a écrit :
On Tuesday, 10 April 2018 12:16 Richard Brown wrote:
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
I don't see much benefit of NetworkManager on a typical desktop machine.
Proper integration in the desktop of VPN start / stop.
Perhaps not of great use to the average desktop user, but yes. How about NFS-mounted shares - last I looked (42.3), it took some work to get those integrated.
Net mounted filesystems don't work with systemd and we are using systemd so you are out of luck here. Get an Evergreen distro for that.
Thanks
Michal
On 12/04/18 09:39, Michal Suchánek wrote:
On Wed, 11 Apr 2018 18:25:59 +0200 Per Jessen per@computer.org wrote:
Frederic Crozat wrote:
Le mardi 10 avril 2018 à 13:04 +0200, Michal Kubecek a écrit :
On Tuesday, 10 April 2018 12:16 Richard Brown wrote:
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
I don't see much benefit of NetworkManager on a typical desktop machine.
Proper integration in the desktop of VPN start / stop.
Perhaps not of great use to the average desktop user, but yes. How about NFS-mounted shares - last I looked (42.3), it took some work to get those integrated.
Net mounted filesystems don't work with systemd and we are using systemd so you are out of luck here. Get an Evergreen distro for that.
Dear Michal
We're using systemd, NFS mounted shares work quite well.
Best regards Per Jessen
On Thu, 12 Apr 2018 21:19:52 +0200 Per Jessen per@computer.org wrote:
On 12/04/18 09:39, Michal Suchánek wrote:
On Wed, 11 Apr 2018 18:25:59 +0200 Per Jessen per@computer.org wrote:
Frederic Crozat wrote:
Le mardi 10 avril 2018 à 13:04 +0200, Michal Kubecek a écrit :
On Tuesday, 10 April 2018 12:16 Richard Brown wrote:
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
I don't see much benefit of NetworkManager on a typical desktop machine.
Proper integration in the desktop of VPN start / stop.
Perhaps not of great use to the average desktop user, but yes. How about NFS-mounted shares - last I looked (42.3), it took some work to get those integrated.
Net mounted filesystems don't work with systemd and we are using systemd so you are out of luck here. Get an Evergreen distro for that.
Dear Michal
We're using systemd, NFS mounted shares work quite well.
Dear Per,
I am using iSCSI root and it does not work with systemd. From what I heard people using network filesystems for filesystems required by system services have same issues. This is not SUSE problem. This is problem of systemd in any distribution.
One thing is that systemd does not have a notion of network service connectivity (ie. ability to reach the server that provides your filesystem). It has only network up and network down.
Even in absence of proper network service dependencies you can mark filesystem in fstab as "network" which is supposed to make it depend on network and prevent systemd from shutting down network while the filesystem is mounted. This does not work. If the filesystem is used by system service unmounting the filesystem times out but the network is shut down nonetheless. It would be much simpler if systemd did not shut down the network at all. Why bother if the system is shut down anyway. Nonetheless it insists and this leads to numerous bugs and in general inability to shut down systems that rely on network filesystems.
Finally the systemd project is really bad with documentation. It uses some kind of object system to represent services, targets, and whatever else there is to enable or disable. Unfortunately, the man page for service would only describe the properties specific to the service object and would not include description of the base object or even clear reference to that description. So wherever you look you see only a fragment of the documentation that is quite useless by itself. Quite stark contrast to sysvinit scripts which were written in shell language which has complete reference, tutorials, etc.
Also in contrast to sysvinit service files where you had to explicitly source each configuration file and script providing utility functions the systemd services are composed of multiple files spread across different places on the filesystem without any clear connection (ie. service redefinition and override files). Again there might be some place in the systemd documentation where detailed description of this is available but it is not described in the man page which describes a service file.
While the documentation is poor it could be saved by distributions adopting systemd providing resources for package maintainers so they can create nice, clean and properly working systemd service files that can serve as examples to others. Alas, distributions including openSUSE ship broken systemd service files which are written without knowledge of systemd design, solve problems in awkward ways and in many cases don't work at all. These then serve as examples to others and the wrong knowledge is perpetuated indefinitely.
This documentation problem probably applies to managing systems that use network dependent filesystems as well.
Thanks
Michal
On 13 April 2018 at 10:51, Michal Suchánek msuchanek@suse.de wrote:
Dear Per,
I am using iSCSI root and it does not work with systemd.
Dear Michal,
Booting from an iSCSI hosted root filesystem is supported in SLE 12, which of course uses systemd.
The wicked enablement for that was implemented in 2014 for SLE 12 GA - https://github.com/openSUSE/wicked/issues/32
It was tested by yours truly. I remember beta customers testing it also. In both cases systemd certainly didn't get in the way.
I'd imagine things still work similarly in Leap 42.x and hopefully Tumbleweed & Leap 15 also.
On Fri, 13 Apr 2018 11:36:56 +0200 Richard Brown RBrownCCB@opensuse.org wrote:
On 13 April 2018 at 10:51, Michal Suchánek msuchanek@suse.de wrote:
Dear Per,
I am using iSCSI root and it does not work with systemd.
Dear Michal,
Booting from an iSCSI hosted root filesystem is supported in SLE 12, which of course uses systemd.
The wicked enablement for that was implemented in 2014 for SLE 12 GA - https://github.com/openSUSE/wicked/issues/32
Indeed, so wicked refuses to shut down the interface even if requested to do so. So the systemd issue is not solved but rather papered over in wicked.
That's the distro benefit for you that people were asking about.
SUSE supports shutting down your system (so long as you use wicked), Debian supports setting up your keyboard layout, Ubuntu comes with decent installer, Arch comes with documentation, etc.
Thanks
Michal
* Michal Suchánek msuchanek@suse.de [04-13-18 08:14]:
On Fri, 13 Apr 2018 11:36:56 +0200 Richard Brown RBrownCCB@opensuse.org wrote:
On 13 April 2018 at 10:51, Michal Suchánek msuchanek@suse.de wrote:
Dear Per,
I am using iSCSI root and it does not work with systemd.
Dear Michal,
Booting from an iSCSI hosted root filesystem is supported in SLE 12, which of course uses systemd.
The wicked enablement for that was implemented in 2014 for SLE 12 GA - https://github.com/openSUSE/wicked/issues/32
Indeed, so wicked refuses to shut down the interface even if requested to do so. So the systemd issue is not solved but rather papered over in wicked.
ifdown wlan0 certainly shuts down the interface and is part of wicked rpm -qf `which ifdown` wicked-service-0.6.47-1.1.x86_64
That's the distro benefit for you that people were asking about.
SUSE supports shutting down your system (so long as you use wicked), Debian supports setting up your keyboard layout, Ubuntu comes with decent installer, Arch comes with documentation, etc.
Thanks
Michal
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 13 Apr 2018 08:18:32 -0400 Patrick Shanahan paka@opensuse.org wrote:
- Michal Suchánek msuchanek@suse.de [04-13-18 08:14]:
On Fri, 13 Apr 2018 11:36:56 +0200 Richard Brown RBrownCCB@opensuse.org wrote:
On 13 April 2018 at 10:51, Michal Suchánek msuchanek@suse.de wrote:
Dear Per,
I am using iSCSI root and it does not work with systemd.
Dear Michal,
Booting from an iSCSI hosted root filesystem is supported in SLE 12, which of course uses systemd.
The wicked enablement for that was implemented in 2014 for SLE 12 GA - https://github.com/openSUSE/wicked/issues/32
Indeed, so wicked refuses to shut down the interface even if requested to do so. So the systemd issue is not solved but rather papered over in wicked.
ifdown wlan0 certainly shuts down the interface and is part of wicked rpm -qf `which ifdown` wicked-service-0.6.47-1.1.x86_64
You haven't read the PR description, have you?
It quite clearly says it adds a flag that prevents shutting down the interface because it is used for your root filesystem.
Of course, it's a gross hack.
Thanks
Michal
* Michal Suchánek msuchanek@suse.de [01-01-70 12:34]:
On Fri, 13 Apr 2018 08:18:32 -0400 Patrick Shanahan paka@opensuse.org wrote:
- Michal Suchánek msuchanek@suse.de [04-13-18 08:14]:
On Fri, 13 Apr 2018 11:36:56 +0200 Richard Brown RBrownCCB@opensuse.org wrote:
On 13 April 2018 at 10:51, Michal Suchánek msuchanek@suse.de wrote:
Dear Per,
I am using iSCSI root and it does not work with systemd.
Dear Michal,
Booting from an iSCSI hosted root filesystem is supported in SLE 12, which of course uses systemd.
The wicked enablement for that was implemented in 2014 for SLE 12 GA - https://github.com/openSUSE/wicked/issues/32
Indeed, so wicked refuses to shut down the interface even if requested to do so. So the systemd issue is not solved but rather papered over in wicked.
ifdown wlan0 certainly shuts down the interface and is part of wicked rpm -qf `which ifdown` wicked-service-0.6.47-1.1.x86_64
You haven't read the PR description, have you?
It quite clearly says it adds a flag that prevents shutting down the interface because it is used for your root filesystem.
Of course, it's a gross hack.
hack or not, I can give myself perms to use ifdown to disconnect my internet connection. so wicked does not refuse to shut down the interface but does require elevation.
Patrick Shanahan wrote:
- Michal Suchánek msuchanek@suse.de [01-01-70 12:34]:
On Fri, 13 Apr 2018 08:18:32 -0400 Patrick Shanahan paka@opensuse.org wrote:
- Michal Suchánek msuchanek@suse.de [04-13-18 08:14]:
On Fri, 13 Apr 2018 11:36:56 +0200 Richard Brown RBrownCCB@opensuse.org wrote:
On 13 April 2018 at 10:51, Michal Suchánek msuchanek@suse.de wrote:
Dear Per,
I am using iSCSI root and it does not work with systemd.
Dear Michal,
Booting from an iSCSI hosted root filesystem is supported in SLE 12, which of course uses systemd.
The wicked enablement for that was implemented in 2014 for SLE 12 GA - https://github.com/openSUSE/wicked/issues/32
Indeed, so wicked refuses to shut down the interface even if requested to do so. So the systemd issue is not solved but rather papered over in wicked.
ifdown wlan0 certainly shuts down the interface and is part of wicked rpm -qf `which ifdown` wicked-service-0.6.47-1.1.x86_64
You haven't read the PR description, have you?
It quite clearly says it adds a flag that prevents shutting down the interface because it is used for your root filesystem.
Of course, it's a gross hack.
hack or not, I can give myself perms to use ifdown to disconnect my internet connection. so wicked does not refuse to shut down the interface but does require elevation.
Patrick, this is about not shutting down the interface during a shutdown of the machine.
On Tue, 10 Apr 2018 12:16:10 +0200 Richard Brown RBrownCCB@opensuse.org wrote:
Hi All,
In both Leap & Tumbleweed we currently have the following logic for choosing which tool manages your network after installation
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
I've noticed an increasing trend that this can lead to confusion.
Many users from other distributions expect NetworkManager on their desktops regardless of whether they are using a laptop or a desktop.
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
There are certainly classes of hardware where NetworkManager might be wanted that will never match "IF laptop" - eg. my personal Inter Compute Stick.
And "IF laptop" is dependant on YaST correctly detecting you're using a laptop, which isn't 100% accurate, so occasionally even laptops might end up with wicked unexpectedly.
I would like to propose a possible solution.
It looks like we should be able to pin the choice of network tool to specific system role.
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
Custom will keep the current "autodetect" behaviour, because we cant be sure that the environment that the user is installing has support for NetworkManager in this case.
Whatever is setup "by default" during installation will be able to be changed in YAST after the installation, just like it is today.
What do we all think? If there is strong support for this idea I think Ludwig is prepared to let me try and slip it in as a late feature for Leap 15, so please let your opinions be heard loudly and quickly either way.
Regards,
Richard
Few notes:
1. it is product specific value. It is driven by control.xml of specific product. Possible values ( as I see in code [1]) is always, laptop and others. For always nm is always used if installation, for laptop only if yast detect laptop and for others it is not used. So if you want to have it always, then just use it.
2. roles can overwrite this value, so it should be quite easy to define for each role its value like richard write and in fact Richard have all knowledge to do it :) [2]
3. do not forget to announce it properly and ideally add to release notes of opensuse, so people do not report it as YaST/Installer bug when you change it.
Thanks
Josef
[1] https://github.com/yast/yast-network/blob/master/src/modules/Lan.rb#L894 [2] https://github.com/yast/skelcd-control-openSUSE/blob/master/control/control....
Hello!
Personally, this idea seems OK, because there is also one problem of Wicked for desktop users: no GUI-applet instead of NM to manage network connections. And even if Wicked is in use, NM GUI-applet is shown in tray in GNOME and XFCE anyway, and this seems meaningless (active NM GUI with NM service OFF). And also this is rather confusing, especially for users, who face with openSUSE at the first time.
Yes, a request for Wicked GUI also exists: [2] https://github.com/openSUSE/wicked/issues/643 , but at this time it is present just as an idea only.
So, idea on NM for desktops and Wicked for servers by default seems OK.
2018-04-10 13:16 GMT+03:00 Richard Brown RBrownCCB@opensuse.org:
Hi All,
In both Leap & Tumbleweed we currently have the following logic for choosing which tool manages your network after installation
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
I've noticed an increasing trend that this can lead to confusion.
Many users from other distributions expect NetworkManager on their desktops regardless of whether they are using a laptop or a desktop.
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
There are certainly classes of hardware where NetworkManager might be wanted that will never match "IF laptop" - eg. my personal Inter Compute Stick.
And "IF laptop" is dependant on YaST correctly detecting you're using a laptop, which isn't 100% accurate, so occasionally even laptops might end up with wicked unexpectedly.
I would like to propose a possible solution.
It looks like we should be able to pin the choice of network tool to specific system role.
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
Custom will keep the current "autodetect" behaviour, because we cant be sure that the environment that the user is installing has support for NetworkManager in this case.
Whatever is setup "by default" during installation will be able to be changed in YAST after the installation, just like it is today.
What do we all think? If there is strong support for this idea I think Ludwig is prepared to let me try and slip it in as a late feature for Leap 15, so please let your opinions be heard loudly and quickly either way.
Regards,
Richard
[1] http://paste.opensuse.org/33301696
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10.04.2018 12:16, Richard Brown wrote:
Hi All,
In both Leap & Tumbleweed we currently have the following logic for choosing which tool manages your network after installation
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
I've noticed an increasing trend that this can lead to confusion.
Many users from other distributions expect NetworkManager on their desktops regardless of whether they are using a laptop or a desktop.
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
There are certainly classes of hardware where NetworkManager might be wanted that will never match "IF laptop" - eg. my personal Inter Compute Stick.
And "IF laptop" is dependant on YaST correctly detecting you're using a laptop, which isn't 100% accurate, so occasionally even laptops might end up with wicked unexpectedly.
I would like to propose a possible solution.
It looks like we should be able to pin the choice of network tool to specific system role.
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
I would like to have this for XFCE, too.
Server & Transactional will always have wicked by default
Custom will keep the current "autodetect" behaviour, because we cant be sure that the environment that the user is installing has support for NetworkManager in this case.
Please provide some mechanism for patterns or similar to influence that decision.
My personal view is that on Desktops NM is not usefull at all, and I'd rate the GNOME behavior a BUG.
That said, if you switch to NM for desktops, at least make sure that the default configuration is that the wired interface is up, whether someone is logged in or not.
Peter Suetterlin composed on 2018-04-10 12:38 (UTC+0100):
My personal view is that on Desktops NM is not usefull at all
+1
On 04/10/2018 01:38 PM, Peter Suetterlin wrote:
That said, if you switch to NM for desktops, at least make sure that the default configuration is that the wired interface is up, whether someone is logged in or not.
That should be part of the acceptance criteria indeed.
Greetings, Stephan
* Peter Suetterlin pit@astro.su.se [04-10-18 07:39]:
My personal view is that on Desktops NM is not usefull at all, and I'd rate the GNOME behavior a BUG.
+1
for *any* dm
On 04/10/2018 06:38 AM, Peter Suetterlin wrote:
My personal view is that on Desktops NM is not usefull at all, and I'd rate the GNOME behavior a BUG.
I must disagree. We have desktop machines that have to be on 2 networks where one of the networks switches subnet addresses for different purposes. NM make that very easy to control.
That said, if you switch to NM for desktops, at least make sure that the default configuration is that the wired interface is up, whether someone is logged in or not.
Count my vote for it as I switch desktop installations to NM as soon as possible anyway.
On Tue, Apr 10, 2018 at 1:16 PM, Richard Brown RBrownCCB@opensuse.org wrote:
Hi All,
In both Leap & Tumbleweed we currently have the following logic for choosing which tool manages your network after installation
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
I've noticed an increasing trend that this can lead to confusion.
Many users from other distributions expect NetworkManager on their desktops regardless of whether they are using a laptop or a desktop.
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
There are certainly classes of hardware where NetworkManager might be wanted that will never match "IF laptop" - eg. my personal Inter Compute Stick.
And "IF laptop" is dependant on YaST correctly detecting you're using a laptop, which isn't 100% accurate, so occasionally even laptops might end up with wicked unexpectedly.
I would like to propose a possible solution.
It looks like we should be able to pin the choice of network tool to specific system role.
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
Custom will keep the current "autodetect" behaviour, because we cant be sure that the environment that the user is installing has support for NetworkManager in this case.
Whatever is setup "by default" during installation will be able to be changed in YAST after the installation, just like it is today.
What do we all think? If there is strong support for this idea I think Ludwig is prepared to let me try and slip it in as a late feature for Leap 15, so please let your opinions be heard loudly and quickly either way.
Regards,
Richard
[1] http://paste.opensuse.org/33301696
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Richard Brown RBrownCCB@opensuse.org [04-10-18 06:18]:
Hi All,
In both Leap & Tumbleweed we currently have the following logic for choosing which tool manages your network after installation
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
I've noticed an increasing trend that this can lead to confusion.
Many users from other distributions expect NetworkManager on their desktops regardless of whether they are using a laptop or a desktop.
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
There are certainly classes of hardware where NetworkManager might be wanted that will never match "IF laptop" - eg. my personal Inter Compute Stick.
And "IF laptop" is dependant on YaST correctly detecting you're using a laptop, which isn't 100% accurate, so occasionally even laptops might end up with wicked unexpectedly.
I would like to propose a possible solution.
It looks like we should be able to pin the choice of network tool to specific system role.
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
Custom will keep the current "autodetect" behaviour, because we cant be sure that the environment that the user is installing has support for NetworkManager in this case.
I perfer a choice on install.
my experience with nm has been less than desirable, sometimes works, usually does not. wicked just works.
On 04/10/2018 02:33 PM, Patrick Shanahan wrote:
I perfer a choice on install.
my experience with nm has been less than desirable, sometimes works, usually does not. wicked just works.
You're free to block NM and pick wicked, but what what other 'choice' you envision? We're talking defaults here.
Greetings, Stephan
* Stephan Kulow coolo@suse.de [04-10-18 08:54]:
On 04/10/2018 02:33 PM, Patrick Shanahan wrote:
I perfer a choice on install.
my experience with nm has been less than desirable, sometimes works, usually does not. wicked just works.
You're free to block NM and pick wicked, but what what other 'choice' you envision? We're talking defaults here.
to choose which of the two just as you get a choice of desktop manager
Am 10.04.2018 um 15:10 schrieb Patrick Shanahan:
- Stephan Kulow coolo@suse.de [04-10-18 08:54]:
On 04/10/2018 02:33 PM, Patrick Shanahan wrote:
I perfer a choice on install.
my experience with nm has been less than desirable, sometimes works, usually does not. wicked just works.
You're free to block NM and pick wicked, but what what other 'choice' you envision? We're talking defaults here.
to choose which of the two just as you get a choice of desktop manager
+1
Stephan Kulow wrote:
On 04/10/2018 02:33 PM, Patrick Shanahan wrote:
I perfer a choice on install.
my experience with nm has been less than desirable, sometimes works, usually does not. wicked just works.
You're free to block NM and pick wicked, but what what other 'choice' you envision? We're talking defaults here.
The main issue with defaults is how easy it is to change things.
I'd definitely also prefer a simple radio button choice at install time over the option to later change it with YaST.
On 10 April 2018 at 15:16, Peter Suetterlin pit@astro.su.se wrote:
Stephan Kulow wrote:
On 04/10/2018 02:33 PM, Patrick Shanahan wrote:
I perfer a choice on install.
my experience with nm has been less than desirable, sometimes works, usually does not. wicked just works.
You're free to block NM and pick wicked, but what what other 'choice' you envision? We're talking defaults here.
The main issue with defaults is how easy it is to change things.
I'd definitely also prefer a simple radio button choice at install time over the option to later change it with YaST.
If people want that, I'm sure people are welcome to contribute that to the YaST team. I'm not interested enough to do it.
As Josef has already pointed out, my proposal to tie NM to specific roles is feasible today based on the code available in YaST already
If people will only accept changing the status quo with a specific UI element toggle, then in my eyes this idea is dead, at least as far as my contributions to the idea and Leap 15 are concerned (I would be surprised if it would be feasible to add something that invasive at this time)
Richard Brown wrote:
On 10 April 2018 at 15:16, Peter Suetterlin pit@astro.su.se wrote:
The main issue with defaults is how easy it is to change things.
I'd definitely also prefer a simple radio button choice at install time over the option to later change it with YaST.
If people want that, I'm sure people are welcome to contribute that to the YaST team. I'm not interested enough to do it.
And I'm not really capable of doing that. I see my role only in bugreporting and expressing my view of things as a suggestion...
As Josef has already pointed out, my proposal to tie NM to specific roles is feasible today based on the code available in YaST already
Good point.
If people will only accept changing the status quo with a specific UI element toggle, then in my eyes this idea is dead,
If you specifically refer to my post, I wouldn't decline your proposal because of that(*). I'd just point out where the shortcommings might be. And as I'm missing the technical knowledge I don't know how easy or difficult it is to iron those out. It might be bloody easy, and just not done because nobody mentioned it. That's why I mention it.
at least as far as my contributions to the idea and Leap 15 are concerned (I would be surprised if it would be feasible to add something that invasive at this time)
I agree on that, if it should still go to 15, that would be the only way. But then it has something of a 'hot fix', and those have the tendency to never get re-done 'properly'. And I think for good user experience an early choice is important, too. Are really enterprise desktops supposed to use NM? Or changed manually after install?
(*) My other point mentioned in another reply, the availability of net connection without someone being logged in, *is* such a showstopper though.
On 10 April 2018 at 15:39, Peter Suetterlin pit@astro.su.se wrote:
at least as far as my contributions to the idea and Leap 15 are concerned (I would be surprised if it would be feasible to add something that invasive at this time)
I agree on that, if it should still go to 15, that would be the only way. But then it has something of a 'hot fix', and those have the tendency to never get re-done 'properly'. And I think for good user experience an early choice is important, too. Are really enterprise desktops supposed to use NM? Or changed manually after install?
SUSE Linux Enterprise Desktop uses NetworkManager by default, in all installations, regardless of laptop or otherwise. So, yes, they're supposed to use NM
(*) My other point mentioned in another reply, the availability of net connection without someone being logged in, *is* such a showstopper though.
The default network manager interfaces connect just fine without a user being logged in. In all my tests, NetworkManager already does this just fine, and already has for quite some time (at least every Leap release to date). Obviously if this doesn't work it would be a bug that needs to be addressed, but I don't think we should assess the feasibility of features we could have today on the possibility of bugs which do not seem to have today.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2018-04-10 at 15:45 +0200, Richard Brown wrote:
On 10 April 2018 at 15:39, Peter Suetterlin <> wrote:
(*) My other point mentioned in another reply, the availability of net connection without someone being logged in, *is* such a showstopper though.
The default network manager interfaces connect just fine without a user being logged in. In all my tests, NetworkManager already does this just fine, and already has for quite some time (at least every Leap release to date). Obviously if this doesn't work it would be a bug that needs to be addressed, but I don't think we should assess the feasibility of features we could have today on the possibility of bugs which do not seem to have today.
Sorry, not true.
I just went to my laptop to do the test in 15.0: I logged out of my session in XFCE, went to the console, used "if addr" and the wlan had lost the IP. I can not post the command output, no network there now.
I know how to make it work (perhaps), but then, that is not the default config.
- -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2018-04-10 at 19:46 +0200, Carlos E. R. wrote:
On Tuesday, 2018-04-10 at 15:45 +0200, Richard Brown wrote:
On 10 April 2018 at 15:39, Peter Suetterlin <> wrote:
(*) My other point mentioned in another reply, the availability of net connection without someone being logged in, *is* such a showstopper though.
The default network manager interfaces connect just fine without a user being logged in. In all my tests, NetworkManager already does this just fine, and already has for quite some time (at least every Leap release to date). Obviously if this doesn't work it would be a bug that needs to be addressed, but I don't think we should assess the feasibility of features we could have today on the possibility of bugs which do not seem to have today.
Sorry, not true.
I just went to my laptop to do the test in 15.0: I logged out of my session in XFCE, went to the console, used "if addr" and the wlan had lost the IP. I can not post the command output, no network there now.
I know how to make it work (perhaps), but then, that is not the default config.
Later I thought to test the cable, so I connected it without login, and it worked. Why this connection works by default and not the other, I don't know; maybe it is related to needing a password.
Then there is the setting "use this connection by other users" or similar wording, which is a manual action that I haven't done in that setup. It then requires the root password to configure.
- -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
Later I thought to test the cable, so I connected it without login, and it worked. Why this connection works by default and not the other, I don't know; maybe it is related to needing a password.
Then there is the setting "use this connection by other users" or similar wording, which is a manual action that I haven't done in that setup. It then requires the root password to configure.
Yes, this is what I thought is causing the connection to be available when no-one is logged in, and I seem to remember that I had to set in myself on the laptop (but that is already quite some time ago, so I might be wrong, and/or it might have changed in the meantime).
Carlos E. R. [11.04.2018 11:16]:
On Tuesday, 2018-04-10 at 19:46 +0200, Carlos E. R. wrote:
On Tuesday, 2018-04-10 at 15:45 +0200, Richard Brown wrote:
On 10 April 2018 at 15:39, Peter Suetterlin <> wrote:
(*) My other point mentioned in another reply, the availability of net connection without someone being logged in, *is* such a showstopper though.
The default network manager interfaces connect just fine without a user being logged in. In all my tests, NetworkManager already does this just fine, and already has for quite some time (at least every Leap release to date). Obviously if this doesn't work it would be a bug that needs to be addressed, but I don't think we should assess the feasibility of features we could have today on the possibility of bugs which do not seem to have today.
Sorry, not true.
I just went to my laptop to do the test in 15.0: I logged out of my session in XFCE, went to the console, used "if addr" and the wlan had lost the IP. I can not post the command output, no network there now.
I know how to make it work (perhaps), but then, that is not the default config.
Later I thought to test the cable, so I connected it without login, and it worked. Why this connection works by default and not the other, I don't know; maybe it is related to needing a password.
Then there is the setting "use this connection by other users" or similar wording, which is a manual action that I haven't done in that setup. It then requires the root password to configure.
Hm. What if I have a disfunctional desktop on the host and can login via console only? Last time I had to do this (as root), I had no network connection. And there was no "cable connect" available at this location, only WLAN.
This was nearly a year ago, and I could not figure out how to activate WLAN from command line with NM. Did the software change in that respect? Of course, without a network connection it is hard to use a search engine in WWW ;)
Werner
On 04/11/2018 01:19 PM, Werner Flamme wrote:
Carlos E. R. [11.04.2018 11:16]:
On Tuesday, 2018-04-10 at 19:46 +0200, Carlos E. R. wrote:
On Tuesday, 2018-04-10 at 15:45 +0200, Richard Brown wrote:
On 10 April 2018 at 15:39, Peter Suetterlin <> wrote:
(*) My other point mentioned in another reply, the availability of net connection without someone being logged in, *is* such a showstopper though.
The default network manager interfaces connect just fine without a user being logged in. In all my tests, NetworkManager already does this just fine, and already has for quite some time (at least every Leap release to date). Obviously if this doesn't work it would be a bug that needs to be addressed, but I don't think we should assess the feasibility of features we could have today on the possibility of bugs which do not seem to have today.
Sorry, not true.
I just went to my laptop to do the test in 15.0: I logged out of my session in XFCE, went to the console, used "if addr" and the wlan had lost the IP. I can not post the command output, no network there now.
I know how to make it work (perhaps), but then, that is not the default config.
Later I thought to test the cable, so I connected it without login, and it worked. Why this connection works by default and not the other, I don't know; maybe it is related to needing a password.
Then there is the setting "use this connection by other users" or similar wording, which is a manual action that I haven't done in that setup. It then requires the root password to configure.
Hm. What if I have a disfunctional desktop on the host and can login via console only? Last time I had to do this (as root), I had no network connection. And there was no "cable connect" available at this location, only WLAN.
This was nearly a year ago, and I could not figure out how to activate WLAN from command line with NM. Did the software change in that respect?
nmtui is my main NM client. It's more agile and responsive that any applet included in the desktops... and it works in good old console. Of course, it doesn't help if nmtui is not installed and you have to configure the network to install it. ;-)
Cheers
Ancor Gonzalez Sosa [11.04.2018 13:25]:
On 04/11/2018 01:19 PM, Werner Flamme wrote:
Hm. What if I have a disfunctional desktop on the host and can login via console only? Last time I had to do this (as root), I had no network connection. And there was no "cable connect" available at this location, only WLAN.
This was nearly a year ago, and I could not figure out how to activate WLAN from command line with NM. Did the software change in that respect?
nmtui is my main NM client. It's more agile and responsive that any applet included in the desktops... and it works in good old console. Of course, it doesn't help if nmtui is not installed and you have to configure the network to install it. ;-)
That's what I found out when googling with my cellphone: a cli exists (I guess I found nmcli), but was not installed on my host. And no second host available and of course no USB stick (or adaptor from mini to standard SD)...
One gets frustrated here ;)
Werner
On 11/04/18 21:04, Werner Flamme wrote:
Ancor Gonzalez Sosa [11.04.2018 13:25]:
On 04/11/2018 01:19 PM, Werner Flamme wrote:
Hm. What if I have a disfunctional desktop on the host and can login via console only? Last time I had to do this (as root), I had no network connection. And there was no "cable connect" available at this location, only WLAN.
This was nearly a year ago, and I could not figure out how to activate WLAN from command line with NM. Did the software change in that respect?
nmtui is my main NM client. It's more agile and responsive that any applet included in the desktops... and it works in good old console. Of course, it doesn't help if nmtui is not installed and you have to configure the network to install it. ;-)
That's what I found out when googling with my cellphone: a cli exists (I guess I found nmcli), but was not installed on my host. And no second host available and of course no USB stick (or adaptor from mini to standard SD)...
One gets frustrated here ;)
Werner
Well making sure nmtui is installed when network manager is isn't exactly a big hard change and also makes sense to me.
Am Mittwoch, 11. April 2018, 23:00:43 schrieb Simon Lees:
Well making sure nmtui is installed when network manager is isn't exactly a big hard change and also makes sense to me.
From my Leap 42.3 system:
$ rpm -qf /usr/bin/nmtui NetworkManager-1.0.12-6.5.x86_64
So it should actually be installed by default (unless that changed in Tumbleweed, which I don't think) ;-)
Back on topic: Both wicked and NetworkManager work fine here, and both do establish the connections on boot.
NetworkManager does default to "user connection" for WiFi (which also means that it will only connect when the user logs in), true, but IIRC that's because of complaints having to supply the root password for setting up the connection. (not different to having to setup the connection via YaST)
Configuring the connection to "Allow all users to connect" and storing the connection key system-wide "fixes" that though, as already mentioned.
I do sense that some users get confused about not having a network management icon by default at all (as is the case in Plasma) or the an error by that icon (as seems to be the case in GNOME e.g.). So probably +0.5 to the proposal from my side.
Kind Regards, Wolfgang
Le mercredi 11 avril 2018 à 11:16 +0200, Carlos E. R. a écrit :
On Tuesday, 2018-04-10 at 19:46 +0200, Carlos E. R. wrote:
On Tuesday, 2018-04-10 at 15:45 +0200, Richard Brown wrote:
On 10 April 2018 at 15:39, Peter Suetterlin <> wrote:
(*) My other point mentioned in another reply, the availability of net connection without someone being logged in, *is* such a showstopper though.
The default network manager interfaces connect just fine without a user being logged in. In all my tests, NetworkManager already does this just fine, and already has for quite some time (at least every Leap release to date). Obviously if this doesn't work it would be a bug that needs to be addressed, but I don't think we should assess the feasibility of features we could have today on the possibility of bugs which do not seem to have today.
Sorry, not true.
I just went to my laptop to do the test in 15.0: I logged out of my session in XFCE, went to the console, used "if addr" and the wlan had lost the IP. I can not post the command output, no network there now.
I know how to make it work (perhaps), but then, that is not the default config.
Later I thought to test the cable, so I connected it without login, and it worked. Why this connection works by default and not the other, I don't know; maybe it is related to needing a password.
Then there is the setting "use this connection by other users" or similar wording, which is a manual action that I haven't done in that setup. It then requires the root password to configure.
And it is expected. Wifi credentials are "personal" by default (they might contain data you don't want to be visible by everybody on the system) and not shared unencryted in /etc/NetworkManager.
If you want to get the wifi credentials available system-wide, you have to do a conscious decision.
On 11/04/18 20:57, Frederic Crozat wrote:
Le mercredi 11 avril 2018 à 11:16 +0200, Carlos E. R. a écrit :
On Tuesday, 2018-04-10 at 19:46 +0200, Carlos E. R. wrote:
On Tuesday, 2018-04-10 at 15:45 +0200, Richard Brown wrote:
On 10 April 2018 at 15:39, Peter Suetterlin <> wrote:
(*) My other point mentioned in another reply, the availability of net connection without someone being logged in, *is* such a showstopper though.
The default network manager interfaces connect just fine without a user being logged in. In all my tests, NetworkManager already does this just fine, and already has for quite some time (at least every Leap release to date). Obviously if this doesn't work it would be a bug that needs to be addressed, but I don't think we should assess the feasibility of features we could have today on the possibility of bugs which do not seem to have today.
Sorry, not true.
I just went to my laptop to do the test in 15.0: I logged out of my session in XFCE, went to the console, used "if addr" and the wlan had lost the IP. I can not post the command output, no network there now.
I know how to make it work (perhaps), but then, that is not the default config.
Later I thought to test the cable, so I connected it without login, and it worked. Why this connection works by default and not the other, I don't know; maybe it is related to needing a password.
Then there is the setting "use this connection by other users" or similar wording, which is a manual action that I haven't done in that setup. It then requires the root password to configure.
And it is expected. Wifi credentials are "personal" by default (they might contain data you don't want to be visible by everybody on the system) and not shared unencryted in /etc/NetworkManager.
If you want to get the wifi credentials available system-wide, you have to do a conscious decision.
I have a polkit file that allows any user in the "network" group to modify the system network settings, which is my way around this issue if others find it useful I don't see why it couldn't go into its own small package.
On 11/04/18 09:33 AM, Simon Lees wrote:
On 11/04/18 20:57, Frederic Crozat wrote:
Le mercredi 11 avril 2018 à 11:16 +0200, Carlos E. R. a écrit :
On Tuesday, 2018-04-10 at 19:46 +0200, Carlos E. R. wrote:
On Tuesday, 2018-04-10 at 15:45 +0200, Richard Brown wrote:
On 10 April 2018 at 15:39, Peter Suetterlin <> wrote:
(*) My other point mentioned in another reply, the availability of net connection without someone being logged in, *is* such a showstopper though.
The default network manager interfaces connect just fine without a user being logged in. In all my tests, NetworkManager already does this just fine, and already has for quite some time (at least every Leap release to date). Obviously if this doesn't work it would be a bug that needs to be addressed, but I don't think we should assess the feasibility of features we could have today on the possibility of bugs which do not seem to have today.
Sorry, not true.
I just went to my laptop to do the test in 15.0: I logged out of my session in XFCE, went to the console, used "if addr" and the wlan had lost the IP. I can not post the command output, no network there now.
I know how to make it work (perhaps), but then, that is not the default config.
Later I thought to test the cable, so I connected it without login, and it worked. Why this connection works by default and not the other, I don't know; maybe it is related to needing a password.
Then there is the setting "use this connection by other users" or similar wording, which is a manual action that I haven't done in that setup. It then requires the root password to configure.
And it is expected. Wifi credentials are "personal" by default (they might contain data you don't want to be visible by everybody on the system) and not shared unencryted in /etc/NetworkManager.
If you want to get the wifi credentials available system-wide, you have to do a conscious decision.
I have a polkit file that allows any user in the "network" group to modify the system network settings, which is my way around this issue if others find it useful I don't see why it couldn't go into its own small package.
+1
I like your idea.
Op woensdag 11 april 2018 15:33:25 CEST schreef Simon Lees:
I have a polkit file that allows any user in the "network" group to modify the system network settings, which is my way around this issue if others find it useful I don't see why it couldn't go into its own small package.
+1
Le mercredi 11 avril 2018 à 23:03 +0930, Simon Lees a écrit :
On 11/04/18 20:57, Frederic Crozat wrote:
Le mercredi 11 avril 2018 à 11:16 +0200, Carlos E. R. a écrit :
On Tuesday, 2018-04-10 at 19:46 +0200, Carlos E. R. wrote:
On Tuesday, 2018-04-10 at 15:45 +0200, Richard Brown wrote:
On 10 April 2018 at 15:39, Peter Suetterlin <> wrote:
(*) My other point mentioned in another reply, the availability of net connection without someone being logged in, *is* such a showstopper though.
The default network manager interfaces connect just fine without a user being logged in. In all my tests, NetworkManager already does this just fine, and already has for quite some time (at least every Leap release to date). Obviously if this doesn't work it would be a bug that needs to be addressed, but I don't think we should assess the feasibility of features we could have today on the possibility of bugs which do not seem to have today.
Sorry, not true.
I just went to my laptop to do the test in 15.0: I logged out of my session in XFCE, went to the console, used "if addr" and the wlan had lost the IP. I can not post the command output, no network there now.
I know how to make it work (perhaps), but then, that is not the default config.
Later I thought to test the cable, so I connected it without login, and it worked. Why this connection works by default and not the other, I don't know; maybe it is related to needing a password.
Then there is the setting "use this connection by other users" or similar wording, which is a manual action that I haven't done in that setup. It then requires the root password to configure.
And it is expected. Wifi credentials are "personal" by default (they might contain data you don't want to be visible by everybody on the system) and not shared unencryted in /etc/NetworkManager.
If you want to get the wifi credentials available system-wide, you have to do a conscious decision.
I have a polkit file that allows any user in the "network" group to modify the system network settings, which is my way around this issue if others find it useful I don't see why it couldn't go into its own small package.
There is no such thing as a "network" group in default install and then, the next question to ask is how to populate it.
On 12/04/18 00:17, Frederic Crozat wrote:
Le mercredi 11 avril 2018 à 23:03 +0930, Simon Lees a écrit :
On 11/04/18 20:57, Frederic Crozat wrote:
Le mercredi 11 avril 2018 à 11:16 +0200, Carlos E. R. a écrit :
On Tuesday, 2018-04-10 at 19:46 +0200, Carlos E. R. wrote:
On Tuesday, 2018-04-10 at 15:45 +0200, Richard Brown wrote:
On 10 April 2018 at 15:39, Peter Suetterlin <> wrote:
> (*) My other point mentioned in another reply, the > availability of net > connection without someone being logged in, *is* such > a > showstopper > though.
The default network manager interfaces connect just fine without a user being logged in. In all my tests, NetworkManager already does this just fine, and already has for quite some time (at least every Leap release to date). Obviously if this doesn't work it would be a bug that needs to be addressed, but I don't think we should assess the feasibility of features we could have today on the possibility of bugs which do not seem to have today.
Sorry, not true.
I just went to my laptop to do the test in 15.0: I logged out of my session in XFCE, went to the console, used "if addr" and the wlan had lost the IP. I can not post the command output, no network there now.
I know how to make it work (perhaps), but then, that is not the default config.
Later I thought to test the cable, so I connected it without login, and it worked. Why this connection works by default and not the other, I don't know; maybe it is related to needing a password.
Then there is the setting "use this connection by other users" or similar wording, which is a manual action that I haven't done in that setup. It then requires the root password to configure.
And it is expected. Wifi credentials are "personal" by default (they might contain data you don't want to be visible by everybody on the system) and not shared unencryted in /etc/NetworkManager.
If you want to get the wifi credentials available system-wide, you have to do a conscious decision.
I have a polkit file that allows any user in the "network" group to modify the system network settings, which is my way around this issue if others find it useful I don't see why it couldn't go into its own small package.
There is no such thing as a "network" group in default install and then, the next question to ask is how to populate it.
The package could create the group so that isn't hard, by default the group would have no users and we would update our documentation to say something along the lines of "If you would like your user to be able to set the system network settings which will also allow your network connection to start at boot up add your user to the 'network' group"
Someone could make a reasonable argument that on tumbleweed atleast adding all users (or atleast the one created in the installer) to the network group would make sense. But i'm not going to argue either way on that adding my user to that group doesn't take long and its something I do shortly after a fresh install anyway.
If anyone is interested here is the rule file below.
tek-top:~ # cat /etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules
polkit.addRule(function(action, subject) { if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) { return polkit.Result.YES; } });
On 12.04.2018 01:08, Simon Lees wrote:
group would have no users and we would update our documentation to say something along the lines of "If you would like your user to be able to set the system network settings which will also allow your network connection to start at boot up
..."WARNING: this will store your network credentials, e.g. your wireless passwords, unencrypted on the disk."
add your user to the 'network' group
On Donnerstag, 12. April 2018 10:38:57 CEST Stefan Seyfried wrote:
On 12.04.2018 01:08, Simon Lees wrote:
group would have no users and we would update our documentation to say something along the lines of "If you would like your user to be able to set the system network settings which will also allow your network connection to start at boot up
..."WARNING: this will store your network credentials, e.g. your wireless passwords, unencrypted on the disk."
add your user to the 'network' group
Which is not true ...
When you create a connection as a system-connection, address settings, DNS, BSSID, SSID and so on will be stored below /etc/NetworkManager/, but this does *not* include the credentials in general.
For ethernet, you typically don't have credentials (you can use 802.1X on wired, but ...)
For wireless, at least the KDE/Plasma NM applet offers three selections: - unencrypted (user session) - encrypted (stored in user KWallet) - unencrypted (system wide)
Each of these settings do state clearly if the password is stored unencrypted. (Sorry, do not have the exact wording at hand.)
You can significantly shorten the time between login and network connection if you use e.g. pam_kwallet5 to open the wallet.
Kind regards,
Stefan
On Apr 12 2018, "Brüns, Stefan" Stefan.Bruens@rwth-aachen.de wrote:
For wireless, at least the KDE/Plasma NM applet offers three selections:
- unencrypted (user session)
- encrypted (stored in user KWallet)
- unencrypted (system wide)
For system connections only the last option is available, for obvious reasons.
Andreas.
On Donnerstag, 12. April 2018 17:36:41 CEST Andreas Schwab wrote:
On Apr 12 2018, "Brüns, Stefan" Stefan.Bruens@rwth-aachen.de wrote:
For wireless, at least the KDE/Plasma NM applet offers three selections:
- unencrypted (user session)
- encrypted (stored in user KWallet)
- unencrypted (system wide)
For system connections only the last option is available, for obvious reasons.
No, its the other way round - for user connections, you can obviously not store it system wide, but for system connections you can choose on which level to store the credential. I have just verified it ...
This is e.g. useful when you deploy a laptop, but provide the credentials independently.
You could also store the credentials e.g. on a smartcard (although this is not implemented AFAIK).
Regards,
Stefan
Peter Suetterlin wrote:
Stephan Kulow wrote:
On 04/10/2018 02:33 PM, Patrick Shanahan wrote:
I perfer a choice on install.
my experience with nm has been less than desirable, sometimes works, usually does not. wicked just works.
You're free to block NM and pick wicked, but what what other 'choice' you envision? We're talking defaults here.
The main issue with defaults is how easy it is to change things.
I'd definitely also prefer a simple radio button choice at install time over the option to later change it with YaST.
+1. A change later will only mean yet another item on my post-install todo list.
On Tuesday 2018-04-10 14:51, Stephan Kulow wrote:
On 04/10/2018 02:33 PM, Patrick Shanahan wrote:
I perfer a choice on install.
my experience with nm has been less than desirable, sometimes works, usually does not. wicked just works.
You're free to block NM and pick wicked, but what what other 'choice' you envision? We're talking defaults here.
systemd-networkd :-p
Am 10.04.2018 um 15:25 schrieb Jan Engelhardt:
systemd-networkd :-p
Is it usable in real-world scenarios nowadays?
It would be really great if we could get rid of that abomination that wicked is and use something that's not SUSE-only...
If only all that work that went into the wicked dead-end would have gone into the development of systemd-networkd...
On Tuesday 2018-04-10 18:33, Stefan Seyfried wrote:
Am 10.04.2018 um 15:25 schrieb Jan Engelhardt:
systemd-networkd :-p
Is it usable in real-world scenarios nowadays?
Sure, works for me. Just keep in mind its usecase is that of ifcfg/wicked, not NetworkManager-esque choose-WiFi-at-will cases.
It would be really great if we could get rid of that abomination that wicked is and use something that's not SUSE-only...
If only all that work that went into the wicked dead-end would have gone into the development of systemd-networkd...
On 10.04.2018 19:01, Jan Engelhardt wrote:
On Tuesday 2018-04-10 18:33, Stefan Seyfried wrote:
Am 10.04.2018 um 15:25 schrieb Jan Engelhardt:
systemd-networkd :-p
Is it usable in real-world scenarios nowadays?
Sure, works for me. Just keep in mind its usecase is that of ifcfg/wicked, not NetworkManager-esque choose-WiFi-at-will cases.
Ok, then we should immediately drop wicked.
Last I heard, systemd-networkd could not handle all kinds of "exotic" interfaces (means: bonding and such) IIRC. If it can do that today, let's get rid of wicked.
On Wednesday, 11 April 2018 9:01 Stefan Seyfried wrote:
On 10.04.2018 19:01, Jan Engelhardt wrote:
On Tuesday 2018-04-10 18:33, Stefan Seyfried wrote:
Am 10.04.2018 um 15:25 schrieb Jan Engelhardt:
systemd-networkd :-p
Is it usable in real-world scenarios nowadays?
Sure, works for me. Just keep in mind its usecase is that of ifcfg/wicked, not NetworkManager-esque choose-WiFi-at-will cases.
Ok, then we should immediately drop wicked.
Last I heard, systemd-networkd could not handle all kinds of "exotic" interfaces (means: bonding and such) IIRC. If it can do that today, let's get rid of wicked.
And... why exactly? So far the only argument you presented (except for strong words like "abomination") was "it's SUSE-only". Should we drop YaST, based on the same logic? Or zypper?
You don't even know if systemd-networkd can actually do everything we use wicked for but you are absolutely sure switching to it would be an improvement?
Michal Kubeček
On Wednesday 2018-04-11 09:29, Michal Kubecek wrote:
You don't even know if systemd-networkd can actually do everything we use wicked for but you are absolutely sure switching to it would be an improvement?
It is of course dependent on the particular administrator which extended features of wicked - or networkd - are considered important and which into their calculation of what consitutes an "overall improvement".
If wicked can make a sandwich, that would be of no value to me, but on the other hand, networkd not requiring three processes running in the background for static address setups (like wicked does) is, which means it sticks out. For me.
+1 to default NetworkManager.
current state of NM is totally different from Hard Begins and becoming de facto standard in Linux desktops. Plus WiFi connections are more common also in normal Desktops :D
Kind Regards, Ondrej
On 11 April 2018 at 09:57, Jan Engelhardt jengelh@inai.de wrote:
On Wednesday 2018-04-11 09:29, Michal Kubecek wrote:
You don't even know if systemd-networkd can actually do everything we use wicked for but you are absolutely sure switching to it would be an improvement?
It is of course dependent on the particular administrator which extended features of wicked - or networkd - are considered important and which into their calculation of what consitutes an "overall improvement".
If wicked can make a sandwich, that would be of no value to me, but on the other hand, networkd not requiring three processes running in the background for static address setups (like wicked does) is, which means it sticks out. For me. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello,
only side notes FYI:
On Apr 11 10:48 Ond?ej Súkup wrote (excerpt):
WiFi connections are more common also in normal Desktops
Since we got smartphone usage inside our private house (did you ever see your children looking sad ? ;-) we have WiFi enabled and since we have WiFi enabled I won't drill more holes through my private house for more and more traditional ethernet cables (unfortunately we don't have a latest greatest house with tons of empty tubes or ethernet cables everywhere just built-in ;-)
FWIW: Our "normal Desktop" computers are actually laptops (those big and fat laptops with a big screen).
Kind Regards Johannes Meixner
On Wednesday, 11 April 2018 12:56 Johannes Meixner wrote:
Hello,
only side notes FYI:
On Apr 11 10:48 Ond?ej Súkup wrote (excerpt):
WiFi connections are more common also in normal Desktops
Since we got smartphone usage inside our private house (did you ever see your children looking sad ? ;-) we have WiFi enabled and since we have WiFi enabled I won't drill more holes through my private house for more and more traditional ethernet cables (unfortunately we don't have a latest greatest house with tons of empty tubes or ethernet cables everywhere just built-in ;-)
FWIW: Our "normal Desktop" computers are actually laptops (those big and fat laptops with a big screen).
Which in fact means that "your normal desktop"
(1) is actually a laptop, so that it ends up with NetworkManager with current installer rules (2) is a desktop, so that it would end up with NetworkManager according to Richard's proposal (3) has wi-fi, so that it would end up with NetworkManager according to my proposal
In other words, with either proposal, nothing changes for "your normal desktop". So what exactly is your point?
Michal Kubeček
Hello,
On Apr 11 13:07 Michal Kubecek wrote (excerpt):
On Wednesday, 11 April 2018 12:56 Johannes Meixner wrote:
On Apr 11 10:48 Ond?ej Súkup wrote (excerpt):
WiFi connections are more common also in normal Desktops
...
Our "normal Desktop" computers are actually laptops (those big and fat laptops with a big screen).
...
what exactly is your point?
I think for the default behaviour for nowadays normal home users WiFi matters most so that there is no need to care about non-WiFi stuff too much.
I think for nowadays normal home users it is basically a showstopper whether or not WiFi always "just works" regardless what specific kind of device they have.
I think for the default behaviour for nowadays normal home users with a non-WiFi computer a DHCP client setup is sufficient (I think this is the default in this case which already "just works") and there is no need to care much about any further networking setup.
If today was Friday I would have added: "simply put: just as that stuff works on Ubuntu" but - unfortunately(?) - today is not yet Friday (the 13.) ;-)
Kind Regards Johannes Meixner
Johannes Meixner wrote:
Hello,
On Apr 11 13:07 Michal Kubecek wrote (excerpt):
On Wednesday, 11 April 2018 12:56 Johannes Meixner wrote:
On Apr 11 10:48 Ond?ej Súkup wrote (excerpt):
WiFi connections are more common also in normal Desktops
...
Our "normal Desktop" computers are actually laptops (those big and fat laptops with a big screen).
...
what exactly is your point?
I think for the default behaviour for nowadays normal home users WiFi matters most so that there is no need to care about non-WiFi stuff too much.
I think the openSUSE defaults ought to be suitable for SOHO users too. Besides, with fixed network, you get gigabit speed.
Am Freitag, 13. April 2018, 11:01:53 CEST schrieb Per Jessen:
Johannes Meixner wrote:
Hello,
On Apr 11 13:07 Michal Kubecek wrote (excerpt):
On Wednesday, 11 April 2018 12:56 Johannes Meixner wrote:
On Apr 11 10:48 Ond?ej Súkup wrote (excerpt):
WiFi connections are more common also in normal Desktops
...
Our "normal Desktop" computers are actually laptops (those big and fat laptops with a big screen).
...
what exactly is your point?
I think for the default behaviour for nowadays normal home users WiFi matters most so that there is no need to care about non-WiFi stuff too much.
I think the openSUSE defaults ought to be suitable for SOHO users too. Besides, with fixed network, you get gigabit speed.
my ~ is on nfs, so +1 +1 +1 +1
still +1 to networkmanager. But please don't start forgetting about ethernet cables.
cheers MH
what exactly is your point?
I think for the default behaviour for nowadays normal home users WiFi matters most so that there is no need to care about non-WiFi stuff too much.
I think the openSUSE defaults ought to be suitable for SOHO users too. Besides, with fixed network, you get gigabit speed.
Both used to work out of the box for years now, provided you use a desktop. NetworkManager covers the cable&wifi use case well.
Ralf Lang wrote:
what exactly is your point?
I think for the default behaviour for nowadays normal home users WiFi matters most so that there is no need to care about non-WiFi stuff too much.
I think the openSUSE defaults ought to be suitable for SOHO users too. Besides, with fixed network, you get gigabit speed.
Both used to work out of the box for years now, provided you use a desktop. NetworkManager covers the cable&wifi use case well.
Does NM work for wifi networks that need to be up regardless of whether a user is logged in? (for remote management for instance).
Am 13.04.2018 um 11:41 schrieb Per Jessen:
Ralf Lang wrote:
what exactly is your point?
I think for the default behaviour for nowadays normal home users WiFi matters most so that there is no need to care about non-WiFi stuff too much.
I think the openSUSE defaults ought to be suitable for SOHO users too. Besides, with fixed network, you get gigabit speed.
Both used to work out of the box for years now, provided you use a desktop. NetworkManager covers the cable&wifi use case well.
Does NM work for wifi networks that need to be up regardless of whether a user is logged in? (for remote management for instance).
Yes, but you need to make it a "system connection", meaning the wpa credentials are saved somewhere under /etc/* instead of /home/uid1000/* and are not encrypted. If that is no issue, it will work.
Michael Ströder [13.04.2018 12:55]:
Ralf Lang wrote:
NetworkManager covers the cable&wifi use case well.
Not really for the cable case: No link detected after suspend/hibernate). I have to restart the whole network stuff (including libvirt stuff) to make ethernet interface work again.
Ciao, Michael.
This behaviour has been reported for WLAN also ;)
Werner
Am 13.04.2018 um 12:55 schrieb Michael Ströder:
Ralf Lang wrote:
NetworkManager covers the cable&wifi use case well.
Not really for the cable case: No link detected after suspend/hibernate). I have to restart the whole network stuff (including libvirt stuff) to make ethernet interface work again.
Ciao, Michael.
Odd, I don't have this. But sounds like a serious issue for this use case.
On 11.04.2018 09:29, Michal Kubecek wrote:
And... why exactly? So far the only argument you presented (except for strong words like "abomination") was "it's SUSE-only". Should we drop YaST, based on the same logic? Or zypper?
YaST, I would not care too much. Zypper? Probably not.
But if all (maybe just all RPM based) distribution would agree on one package management tool, then that would certainly be an improvement.
But for wicked. Well, I was at the openSUSE conference in Prague when it was presented, and it was a typical "we invent something before looking left and right what's already there" thing. Actually I still can remember Olaf's puzzled face when the RedHat developers (there was not only openSUSE conf but some other conferences at the same time at the same venue, and so other distro developers were present) asked "why didn't you work with us to get this into the upcoming systemd-networkd?" and he had to admit that he never looked if there are other projects that do the same. Reminded me of the Old (Y2K) SUSE style of bad NIH syndrome.
The best thing systemd has brought us IMVHO is, that now all distributions are handled more or less the same from a systems administrator point of view. If distributions mess things up, you can fix them easily with systemd unit dropins most of the time. At work, it does not really matter anymore if people want RHEL7 or SLES12 from me, it's just handled the same way.
That's a big plus.
Everyone working on sytemd-networkd instead of its own niche implementation would be almost certainly an improvement for everyone. Alternatively, getting everyone else to adopt and work on wicked would also be an option. But given the history of wicked and the design decisions (XML config files...), I doubt that will ever happen.
You don't even know if systemd-networkd can actually do everything we use wicked for but you are absolutely sure switching to it would be an improvement?
I'm fighting wicked every day. I'm quite sure almost everything would be an improvement ;-)
At home I even use NetworkManager on servers, because it works better for me (with fixed ifcfg-file configuration) than wicked.
Even SUSE Enterprise Products (SOC for example) avoid wicked whenever they can, it seems. But it's getting offtopic here.
Executive summary: I support the default of NetworkManager by default for openSUSE.
Le jeudi 12 avril 2018 à 10:27 +0200, Stefan Seyfried a écrit :
Even SUSE Enterprise Products (SOC for example) avoid wicked whenever they can, it seems.
This is absolutely false. SOC uses wicked and all issues found by SOC team on wicked were reported and fixed by wicked developers.
On 12.04.2018 10:40, Frederic Crozat wrote:
Le jeudi 12 avril 2018 à 10:27 +0200, Stefan Seyfried a écrit :
Even SUSE Enterprise Products (SOC for example) avoid wicked whenever they can, it seems.
This is absolutely false. SOC uses wicked and all issues found by SOC team on wicked were reported and fixed by wicked developers.
Then I'm wondering why I have to fight Chef bugs regarding MTU config, because it does *not* just configure wicked and then use wicked to configure the interface... ;-)
But that's offtopic here and will be discussed in an SR.
Am Donnerstag, 12. April 2018, 10:27:22 CEST schrieb Stefan Seyfried:
Executive summary: I support the default of NetworkManager by default for openSUSE.
#metoo
Cheers MH
* Mathias Homann Mathias.Homann@opensuse.org [04-12-18 04:46]:
Am Donnerstag, 12. April 2018, 10:27:22 CEST schrieb Stefan Seyfried:
Executive summary: I support the default of NetworkManager by default for openSUSE.
#metoo
Cheers MH
I definitely do not.
-1
I've done my best to collate all of your feedback and asses the feedback thusly
For: 17.5 people Against: 3 people (4 if I count Fabian's in person feedback) Unclear (on the fence/both equally bad/talking about adding features not on the table): 9 people
This obviously means there is a majority that support this change.
Due to the high number of unclear feedback though, I wanted to weight people's responses to make sure I looked at this thread from more than one point of view. As this would be a wide-ranging change, I felt a lot of peoples responses weren't very helpful when they were only talking about their own personal usecase and not considering the wider users project. Therefore went through everyone's responses and applied an additional weight of +0.5 for all responders who demonstrated they had considered an opinion beyond their own personal use cases.
In this case, the numbers become: For: 20.5 Against: 4 (or 5 incl. Fabian) Unclear: 11.5
Still showing a clear body of support for this change beyond those who disagree or have a more nuanced view on the topic.
With these numbers in hand, I've just discussed this with Leap & Tumbleweed's release managers and based on their feedback the current plan is
- It'a almost certain that there will be no change on the current behaviour for Leap 15.0; Although we could do it, any late change bring risks. Many of the negative and unclear comments on this thread helped identify the nature of those risks. Even if I am reasonably confident that many of those risks will not apply, I concur that the benefits of this change probably don't justify risking Leap 15 being a smooth and happy release. We've lived for years without this behaviour without major concerns.
- Tumbleweed will likely adopt this change in the coming weeks. I won't be rushing my submission to the changes (I already have changes the transactional server system role on the way and wait to wait for them to land before proposing more). openQA should be enough to ensure that nothing outright breaks, and our ability to tweak, tune, or revert things quickly based on user feedback will mean we can address peoples concerns as/when/if they bear fruit.
- Assuming things go well in Tumbleweed, users can probably expect this behaviour of NM by default for Desktop roles in Leap 15.1
Thanks all for your feedback
On 12 April 2018 at 13:22, Patrick Shanahan paka@opensuse.org wrote:
- Mathias Homann Mathias.Homann@opensuse.org [04-12-18 04:46]:
Am Donnerstag, 12. April 2018, 10:27:22 CEST schrieb Stefan Seyfried:
Executive summary: I support the default of NetworkManager by default for openSUSE.
#metoo
Cheers MH
I definitely do not.
-1
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op donderdag 12 april 2018 15:11:36 CEST schreef Richard Brown:
I've done my best to collate all of your feedback and asses the feedback thusly
For: 17.5 people Against: 3 people (4 if I count Fabian's in person feedback) Unclear (on the fence/both equally bad/talking about adding features not on the table): 9 people
This obviously means there is a majority that support this change.
Due to the high number of unclear feedback though, I wanted to weight people's responses to make sure I looked at this thread from more than one point of view. As this would be a wide-ranging change, I felt a lot of peoples responses weren't very helpful when they were only talking about their own personal usecase and not considering the wider users project. Therefore went through everyone's responses and applied an additional weight of +0.5 for all responders who demonstrated they had considered an opinion beyond their own personal use cases.
In this case, the numbers become: For: 20.5 Against: 4 (or 5 incl. Fabian) Unclear: 11.5
Still showing a clear body of support for this change beyond those who disagree or have a more nuanced view on the topic.
With these numbers in hand, I've just discussed this with Leap & Tumbleweed's release managers and based on their feedback the current plan is
- It'a almost certain that there will be no change on the current
behaviour for Leap 15.0; Although we could do it, any late change bring risks. Many of the negative and unclear comments on this thread helped identify the nature of those risks. Even if I am reasonably confident that many of those risks will not apply, I concur that the benefits of this change probably don't justify risking Leap 15 being a smooth and happy release. We've lived for years without this behaviour without major concerns.
- Tumbleweed will likely adopt this change in the coming weeks. I
won't be rushing my submission to the changes (I already have changes the transactional server system role on the way and wait to wait for them to land before proposing more). openQA should be enough to ensure that nothing outright breaks, and our ability to tweak, tune, or revert things quickly based on user feedback will mean we can address peoples concerns as/when/if they bear fruit.
- Assuming things go well in Tumbleweed, users can probably expect
this behaviour of NM by default for Desktop roles in Leap 15.1
Thanks all for your feedback
Thank you for bringing this up and your efforts so far.
On Thu, 12 Apr 2018 15:11:36 +0200 Richard Brown RBrownCCB@opensuse.org wrote:
I've done my best to collate all of your feedback and asses the feedback thusly
For: 17.5 people Against: 3 people (4 if I count Fabian's in person feedback) Unclear (on the fence/both equally bad/talking about adding features not on the table): 9 people
This obviously means there is a majority that support this change.
Due to the high number of unclear feedback though, I wanted to weight people's responses to make sure I looked at this thread from more than one point of view. As this would be a wide-ranging change, I felt a lot of peoples responses weren't very helpful when they were only talking about their own personal usecase and not considering the wider users project. Therefore went through everyone's responses and applied an additional weight of +0.5 for all responders who demonstrated they had considered an opinion beyond their own personal use cases.
In this case, the numbers become: For: 20.5 Against: 4 (or 5 incl. Fabian) Unclear: 11.5
Still showing a clear body of support for this change beyond those who disagree or have a more nuanced view on the topic.
With these numbers in hand, I've just discussed this with Leap & Tumbleweed's release managers and based on their feedback the current plan is
- It'a almost certain that there will be no change on the current
behaviour for Leap 15.0; Although we could do it, any late change bring risks. Many of the negative and unclear comments on this thread helped identify the nature of those risks. Even if I am reasonably confident that many of those risks will not apply, I concur that the benefits of this change probably don't justify risking Leap 15 being a smooth and happy release. We've lived for years without this behaviour without major concerns.
- Tumbleweed will likely adopt this change in the coming weeks. I
won't be rushing my submission to the changes (I already have changes the transactional server system role on the way and wait to wait for them to land before proposing more). openQA should be enough to ensure that nothing outright breaks, and our ability to tweak, tune, or revert things quickly based on user feedback will mean we can address peoples concerns as/when/if they bear fruit.
- Assuming things go well in Tumbleweed, users can probably expect
this behaviour of NM by default for Desktop roles in Leap 15.1
Thanks all for your feedback
Hi Richard, it makes sense for me to try it first at TW. Especially even if it looks like installer already support changing network manager proposal in roles, we don't try it yet, so you can find bugs. Same can be if there is higher demand for simple network proposal in overview page where people can one-click change from NM to wicked and vice versa. So YaST team will have time to do it before 15.1 if there is high enough interest.
Josef
On 04/12/2018 07:35 AM, Josef Reidinger wrote:
Hi Richard, it makes sense for me to try it first at TW. Especially even if it looks like installer already support changing network manager proposal in roles, we don't try it yet, so you can find bugs. Same can be if there is higher demand for simple network proposal in overview page where people can one-click change from NM to wicked and vice versa. So YaST team will have time to do it before 15.1 if there is high enough interest.
Josef
It seems to me that this is the best approach. I agree with Josef.
On 04/12/2018 06:11 AM, Richard Brown wrote:
I've done my best to collate all of your feedback and asses
Curious. Which of the responders were you referring to with that latter word? ;-)
On 04/12/2018 06:11 AM, Richard Brown wrote:
I've done my best to collate all of your feedback and asses the feedback thusly
For: 17.5 people Against: 3 people (4 if I count Fabian's in person feedback) Unclear (on the fence/both equally bad/talking about adding features not on the table): 9 people
This obviously means there is a majority that support this change.
Due to the high number of unclear feedback though, I wanted to weight people's responses to make sure I looked at this thread from more than one point of view. As this would be a wide-ranging change, I felt a lot of peoples responses weren't very helpful when they were only talking about their own personal usecase and not considering the wider users project.
I think that, as someone else mentioned here, an overwhelming majority of Users, especially New Users, will have their homes set up with wireless rather than a network of Cat5 or Cat6.
This would also include many of the Small Home Businesses.
I think the Network Manager default would serve openSUSE best.
Those who want it otherwise would already have the knowledge required to switch to Wicked or whatever else they prefer.
... and we would probably see a lot fewer "can't get internet" threads on the Forums.
On Thu, Apr 12, 2018 at 12:42:11PM -0700, Fraser_Bell wrote:
I think that, as someone else mentioned here, an overwhelming majority of Users, especially New Users, will have their homes set up with wireless rather than a network of Cat5 or Cat6.
This would also include many of the Small Home Businesses.
I think the Network Manager default would serve openSUSE best.
Once again, I have to remind that these users would get NetworkManager as default with my proposal as well. But apparently nobody is listening so they keep repeating the mantra that most users have wi-fi so that we have to give NetworkManager as default to everyone, including (and that is the difference between Richard's proposal and mine) those with *no* wi-fi device.
Michal Kubeček
Am Donnerstag, 12. April 2018, 21:49:49 CEST schrieb Michal Kubecek:
On Thu, Apr 12, 2018 at 12:42:11PM -0700, Fraser_Bell wrote:
I think that, as someone else mentioned here, an overwhelming majority of Users, especially New Users, will have their homes set up with wireless rather than a network of Cat5 or Cat6.
This would also include many of the Small Home Businesses.
I think the Network Manager default would serve openSUSE best.
Once again, I have to remind that these users would get NetworkManager as default with my proposal as well. But apparently nobody is listening so they keep repeating the mantra that most users have wi-fi so that we have to give NetworkManager as default to everyone, including (and that is the difference between Richard's proposal and mine) those with *no* wi-fi device.
I even prefer NetworkManager for my wired desktop machines, because of better VPNsupport and easy to setup WakeOnLan...
Herbert
On Thursday, 12 April 2018 21:55 Herbert Graeber wrote:
I even prefer NetworkManager for my wired desktop machines, because of better VPNsupport and easy to setup WakeOnLan...
While I can understand setting up VPN with NetworkManager might feel more comfortable for some people (even if I'm not one of them), I would really like to hear how exactly does NetworkManager wake on lan setup easier than writing (e.g.) "wol g" into ETHTOOL_OPTIONS (either with editor or using the YaST module).
Michal Kubeček
On Thu, 12 Apr 2018 21:49:49 +0200 Michal Kubecek mkubecek@suse.cz wrote:
On Thu, Apr 12, 2018 at 12:42:11PM -0700, Fraser_Bell wrote:
I think that, as someone else mentioned here, an overwhelming majority of Users, especially New Users, will have their homes set up with wireless rather than a network of Cat5 or Cat6.
This would also include many of the Small Home Businesses.
I think the Network Manager default would serve openSUSE best.
Once again, I have to remind that these users would get NetworkManager as default with my proposal as well. But apparently nobody is listening so they keep repeating the mantra that most users have wi-fi so that we have to give NetworkManager as default to everyone, including (and that is the difference between Richard's proposal and mine) those with *no* wi-fi device.
And it has been pointed out that it would be quite surprising if the installation behaves differently depending on having your WiFi dongle plugged in at installation time or even on the installation environment having the correct firmware for your WiFi dongle.
If there is a need to choose a default it better be as universal as possible. Then support needs to ask fewer questions to get your problem solved as well.
Thanks
Michal
On Friday, 13 April 2018 10:25 Michal Suchánek wrote:
On Thu, 12 Apr 2018 21:49:49 +0200 Michal Kubecek mkubecek@suse.cz
wrote:
Once again, I have to remind that these users would get NetworkManager as default with my proposal as well. But apparently nobody is listening so they keep repeating the mantra that most users have wi-fi so that we have to give NetworkManager as default to everyone, including (and that is the difference between Richard's proposal and mine) those with *no* wi-fi device.
And it has been pointed out that it would be quite surprising if the installation behaves differently depending on having your WiFi dongle plugged in at installation time or even on the installation environment having the correct firmware for your WiFi dongle.
I really have better things to do than to keep participating in this contest for craziest corner case people can come with (and pretending as convincingly as possible that it's typical use case). After all, the decision has been made already so that it would be futile anyway.
Michal Kubeček
Richard Brown wrote:
[snip]
- It'a almost certain that there will be no change on the current
behaviour for Leap 15.0; Although we could do it, any late change bring risks. Many of the negative and unclear comments on this thread helped identify the nature of those risks. Even if I am reasonably confident that many of those risks will not apply, I concur that the benefits of this change probably don't justify risking Leap 15 being a smooth and happy release. We've lived for years without this behaviour without major concerns.
Richard, thanks for the summing up. I would like to emphasize your last sentence. Evolving the openSUSE defaults to match the typical user case is a good idea, but not critical.
- Assuming things go well in Tumbleweed, users can probably expect
this behaviour of NM by default for Desktop roles in Leap 15.1
It would be nice to have the option to choose wicked/NM during installation, and/or with autoyast.
Per Jessen composed on 2018-04-13 12:04 (UTC+0200):
It would be nice to have the option to choose wicked/NM during installation, and/or with autoyast.
That seemed easy enough to me in yesterday's TW install. I simply tabooed NetworkManager. It seems it ought to be just as easy to taboo Wicked.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday, 2018-04-13 at 12:04 +0200, Per Jessen wrote:
Richard Brown wrote:
- Assuming things go well in Tumbleweed, users can probably expect
this behaviour of NM by default for Desktop roles in Leap 15.1
It would be nice to have the option to choose wicked/NM during installation, and/or with autoyast.
+1
- -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar)
On Thursday, 12 April 2018 10:27 Stefan Seyfried wrote:
On 11.04.2018 09:29, Michal Kubecek wrote:
And... why exactly? So far the only argument you presented (except for strong words like "abomination") was "it's SUSE-only". Should we drop YaST, based on the same logic? Or zypper?
YaST, I would not care too much. Zypper? Probably not.
But if all (maybe just all RPM based) distribution would agree on one package management tool, then that would certainly be an improvement.
If distributions gave up on giving their users something extra (like zypper, YaST, SaX, ...), what would be the point of having different distributions at all? Wallpapers, color schemes, default package selection and perhaps some default settings? I'm afraid that's not enough; after all, these are the things I have to change after every installation anyway.
The reason I'm using openSUSE even if I wholeheartedly hate many decisions of the project in last ~5 years, even if I have my concerns about how the project is governed, is not because the login screen has green background (well, it does not, any more). It's because that something extra: OBS, zypper, YaST (I'm not using it much but it's good to have it when I need to configure something I'm not familiar with, e.g. printing).
Even wicked is one of those reasons. I must admit I was reluctant about it at first and I was genuinely unhappy when I learned it's not going to be an alternative to the traditional scripts but a replacement. But I learned to live with it and I appreciate that it doesn't get in my way if I don't want it to (which is hardly something I could say about systemd-* tools in general). There are bugs, sure, but they are dealt with by competent developers.
But for wicked. Well, I was at the openSUSE conference in Prague when it was presented, and it was a typical "we invent something before looking left and right what's already there" thing. Actually I still can remember Olaf's puzzled face when the RedHat developers (there was not only openSUSE conf but some other conferences at the same time at the same venue, and so other distro developers were present) asked "why didn't you work with us to get this into the upcoming systemd-networkd?"
I guess this "puzzled face" was mostly because at the time, there was not much of systemd-networkd. Not much more than an idea that if the great plan is to replace all system tools by some systemd-something (which is philosophy I totally disagree with), network configuration management shouldn't be an exception. Six years later, wicked has been in use in SLE for 3.5 years and even if, as you claim, everyone else is happily working on systemd-networkd, it's not on par with wicked, not by far.
So... who should be accused of "NIH syndrome" and asked why they insist on developing their own solution rather than joinin the work on existing one?
and he had to admit that he never looked if there are other projects that do the same.
I've been there (chairing the session, actually) and I remember one of the two (don't remember if Olaf or Mariusz) talking about existing tools and explaining why they didn't want to use any of them. And, as I said, systemd-networkd couldn't really be considered "other project" at the moment.
Reminded me of the Old (Y2K) SUSE style of bad NIH syndrome.
As I said above, that's rather problem of systemd-networkd in this case.
You don't even know if systemd-networkd can actually do everything we use wicked for but you are absolutely sure switching to it would be an improvement?
I'm fighting wicked every day. I'm quite sure almost everything would be an improvement ;-)
That's a common mistake. People tend to think that if they dislike something, anything else would be better. In reality, it rarely works like that.
Michal Kubeček
Am 13.04.2018 um 07:37 schrieb Michal Kubecek:
On Thursday, 12 April 2018 10:27 Stefan Seyfried wrote:
On 11.04.2018 09:29, Michal Kubecek wrote:
And... why exactly? So far the only argument you presented (except for strong words like "abomination") was "it's SUSE-only". Should we drop YaST, based on the same logic? Or zypper?
YaST, I would not care too much. Zypper? Probably not.
But if all (maybe just all RPM based) distribution would agree on one package management tool, then that would certainly be an improvement.
If distributions gave up on giving their users something extra (like zypper, YaST, SaX, ...), what would be the point of having different distributions at all?
How is rpm vs deb "something extra"? Both fulfill roughly the same needs offering similar capabilities. Both are really only user friendly with additional higher level tooling (apt-get/aptitude/apt, yum/zypper/yast, desktop UIs). In fact, obs is capable of using both for packaging software and using these packages in image builds. Moreover, an average frontend user does not need to know either format or the underlying architecture. They have a software management frontend (today people call it an app store) and search/click what they want and get it. That's real convenient and tui yast offers similar capability.
People use openSUSE or SLE because it's easy to use and it gets their workload done - be it running a browser fullscreen and forgetting an OS even exists, be it programming, playing virtual switch/router, providing a docker host or a distributed web application platform (db, app server, frontend/loadbalancer, ssl endpoint...)
Being different for the sake of it does not add to that. It's great if you can handle Wifi, VPN, complicated network setups, bonding, teaming, bridges etc. Redhat does that using NetworkManager (though teaming support feels hacky, adding json snippets into config strings or GUI fields). Ubuntu does that using NetworkManager. OpenSUSE does that, in some cases, using NetworkManager. It's great an alternative exists, but it does not have a friendly frontend yet. Same for future options like networkd. For the time being, NetworkManager works least worst ;-) of these options, for GUI users.
On Friday, 13 April 2018 10:33 Ralf Lang wrote:
Am 13.04.2018 um 07:37 schrieb Michal Kubecek:
On Thursday, 12 April 2018 10:27 Stefan Seyfried wrote:
YaST, I would not care too much. Zypper? Probably not.
But if all (maybe just all RPM based) distribution would agree on one package management tool, then that would certainly be an improvement.
If distributions gave up on giving their users something extra (like zypper, YaST, SaX, ...), what would be the point of having different distributions at all?
How is rpm vs deb "something extra"?
I have absolutely no idea what made you think I was talking about rpm vs. deb.
Michal Kubeček
On 04/12/2018 10:37 PM, Michal Kubecek wrote:
The reason I'm using openSUSE even if I wholeheartedly hate many decisions of the project in last ~5 years, even if I have my concerns about how the project is governed,
... which, of course, is why you put up your name and you are running in the current openSUSE Board Elections, right?
;-)
On Fri, 13 Apr 2018 15:21:30 -0700 Fraser_Bell Fraser_Bell@openSUSE.org wrote:
On 04/12/2018 10:37 PM, Michal Kubecek wrote:
The reason I'm using openSUSE even if I wholeheartedly hate many decisions of the project in last ~5 years, even if I have my concerns about how the project is governed,
... which, of course, is why you put up your name and you are running in the current openSUSE Board Elections, right?
;-)
Have you succumbed to the fallacy that anyone can do anything at any time?
As much as not everyone is born a developer not everyone is born a governor. Almost anyone can become one but not immediately. And it comes at a cost.
Thanks
Michal
On 11/04/18 03:01 AM, Stefan Seyfried wrote:
On 10.04.2018 19:01, Jan Engelhardt wrote:
On Tuesday 2018-04-10 18:33, Stefan Seyfried wrote:
Am 10.04.2018 um 15:25 schrieb Jan Engelhardt:
systemd-networkd :-p
Is it usable in real-world scenarios nowadays?
Sure, works for me. Just keep in mind its usecase is that of ifcfg/wicked, not NetworkManager-esque choose-WiFi-at-will cases.
Ok, then we should immediately drop wicked.
Last I heard, systemd-networkd could not handle all kinds of "exotic" interfaces (means: bonding and such) IIRC. If it can do that today, let's get rid of wicked.
The NetworkManager should be up and running before we log on to our laptops/desktops. For me it might take several seconds for my wifi to acquire its address when logged in to my desktop.
Cheers!
Roman
On Mittwoch, 11. April 2018 16:50:21 CEST Roman Bysh wrote:
On 11/04/18 03:01 AM, Stefan Seyfried wrote:
On 10.04.2018 19:01, Jan Engelhardt wrote:
On Tuesday 2018-04-10 18:33, Stefan Seyfried wrote:
Am 10.04.2018 um 15:25 schrieb Jan Engelhardt:
systemd-networkd :-p
Is it usable in real-world scenarios nowadays?
Sure, works for me. Just keep in mind its usecase is that of ifcfg/wicked, not NetworkManager-esque choose-WiFi-at-will cases.>
Ok, then we should immediately drop wicked.
Last I heard, systemd-networkd could not handle all kinds of "exotic" interfaces (means: bonding and such) IIRC. If it can do that today, let's get rid of wicked.
The NetworkManager should be up and running before we log on to our laptops/desktops. For me it might take several seconds for my wifi to acquire its address when logged in to my desktop.
Connection to Wifi network (typically) requires credentials, which are only available *after* you login, as the credentials are protected with your account password.
If you are fine with storing your credentials in clear text, you can select to make the connection available for all users. The connection is brought up even when no user is logged in.
Regards,
Stefan-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/04/18 11:00 AM, Brüns, Stefan wrote:
On Mittwoch, 11. April 2018 16:50:21 CEST Roman Bysh wrote:
On 11/04/18 03:01 AM, Stefan Seyfried wrote:
On 10.04.2018 19:01, Jan Engelhardt wrote:
On Tuesday 2018-04-10 18:33, Stefan Seyfried wrote:
Am 10.04.2018 um 15:25 schrieb Jan Engelhardt:
systemd-networkd :-p
Is it usable in real-world scenarios nowadays?
Sure, works for me. Just keep in mind its usecase is that of ifcfg/wicked, not NetworkManager-esque choose-WiFi-at-will cases.>
Ok, then we should immediately drop wicked.
Last I heard, systemd-networkd could not handle all kinds of "exotic" interfaces (means: bonding and such) IIRC. If it can do that today, let's get rid of wicked.
The NetworkManager should be up and running before we log on to our laptops/desktops. For me it might take several seconds for my wifi to acquire its address when logged in to my desktop.
Connection to Wifi network (typically) requires credentials, which are only available *after* you login, as the credentials are protected with your account password.
If you are fine with storing your credentials in clear text, you can select to make the connection available for all users. The connection is brought up even when no user is logged in.
Regards,
Stefan-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I used Yast to enter my password settings using wpa2-psk. So after a reboot shouldn't that information be ready and NetworkManager be up and running?
Am Mittwoch, 11. April 2018, 17:12:13 CEST schrieb Roman Bysh:
I used Yast to enter my password settings using wpa2-psk. So after a reboot shouldn't that information be ready and NetworkManager be up and running?
YaST only can configure wicked, but not NetworkManager. You need to use the desktop's NM applet to configure NetworkManager.
For the connection to be established during boot already, you need to tick "Allow all users to connect", and the password needs to be stored system-wide ("Store password for all users (not encrypted)" on the "Wi-Fi Security" tab).
Kind Regards, Wolfgang
Am 12.04.2018 um 17:42 schrieb Wolfgang Bauer:
Am Mittwoch, 11. April 2018, 17:12:13 CEST schrieb Roman Bysh:
I used Yast to enter my password settings using wpa2-psk. So after a reboot shouldn't that information be ready and NetworkManager be up and running?
YaST only can configure wicked, but not NetworkManager. You need to use the desktop's NM applet to configure NetworkManager.
Or nmtui / nmcli - both work well without any x/wayland on the system.
-- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Am 12.04.2018 um 17:42 schrieb Wolfgang Bauer:
Am Mittwoch, 11. April 2018, 17:12:13 CEST schrieb Roman Bysh:
I used Yast to enter my password settings using wpa2-psk. So after a reboot shouldn't that information be ready and NetworkManager be up and running?
YaST only can configure wicked, but not NetworkManager. You need to use the desktop's NM applet to configure NetworkManager.
You can also use nmtui, works even better than some of the desktop applets. Additionally, at least for simple wired interface configurations, NM was able to read the YaST configured ifcfg-ethX files just fine last time I looked.
For the connection to be established during boot already, you need to tick "Allow all users to connect", and the password needs to be stored system-wide ("Store password for all users (not encrypted)" on the "Wi-Fi Security" tab).
You just told me in the other mail that this is not true ;-) (it is, of course)
Am Donnerstag, 12. April 2018, 20:08:46 CEST schrieb Stefan Seyfried:
You can also use nmtui, works even better than some of the desktop applets.
Sure, I probably should have written "a NetworkManager frontend", which YaST isn't. But I think that might have been more confusing.
Additionally, at least for simple wired interface configurations, NM was able to read the YaST configured ifcfg-ethX files just fine last time I looked.
No idea. But I'm sure it won't read the keyphrase set with YaST if the connection was setup with NM and configured to store for the user only (as is the default). ;-)
For the connection to be established during boot already, you need to tick
"Allow all users to connect", and the password needs to be stored system-wide ("Store password for all users (not encrypted)" on the "Wi-Fi Security" tab).
You just told me in the other mail that this is not true ;-) (it is, of course)
I definitely did not.
Kind Regards, Wolfgang
Roman Bysh wrote:
On 11/04/18 03:01 AM, Stefan Seyfried wrote:
On 10.04.2018 19:01, Jan Engelhardt wrote:
On Tuesday 2018-04-10 18:33, Stefan Seyfried wrote:
Am 10.04.2018 um 15:25 schrieb Jan Engelhardt:
systemd-networkd :-p
Is it usable in real-world scenarios nowadays?
Sure, works for me. Just keep in mind its usecase is that of ifcfg/wicked, not NetworkManager-esque choose-WiFi-at-will cases.
Ok, then we should immediately drop wicked.
Last I heard, systemd-networkd could not handle all kinds of "exotic" interfaces (means: bonding and such) IIRC. If it can do that today, let's get rid of wicked.
The NetworkManager should be up and running before we log on to our laptops/desktops. For me it might take several seconds for my wifi to acquire its address when logged in to my desktop.
I have one test laptop with NM - I see the same problem, it is most annoying after a resume from hibernation. The only reason I using NM is because of some issue with rfkill that wicked couldn't or doesn't deal with.
* Stefan Seyfried stefan.seyfried@googlemail.com [04-11-18 18:34]:
On 10.04.2018 19:01, Jan Engelhardt wrote:
On Tuesday 2018-04-10 18:33, Stefan Seyfried wrote:
Am 10.04.2018 um 15:25 schrieb Jan Engelhardt:
systemd-networkd :-p
Is it usable in real-world scenarios nowadays?
Sure, works for me. Just keep in mind its usecase is that of ifcfg/wicked, not NetworkManager-esque choose-WiFi-at-will cases.
Ok, then we should immediately drop wicked.
Last I heard, systemd-networkd could not handle all kinds of "exotic" interfaces (means: bonding and such) IIRC. If it can do that today, let's get rid of wicked.
and how do I search for a wifi signal with sysemd-networkd for wicked I use 'yast lan' and nm fails frequently on all my boxes where wicked "just works".
Hey Richard :)
I totally agree, setting NetworkManager is the first or second thing I do when I install openSUSE on my computers or for friends. As you said it's what users expect to see with a "regular" install.
___ Alex aka DarthWound Global Steam Moderator
Le mardi 10 avril 2018 à 12:16 +0200, Richard Brown a écrit :
Hi All,
In both Leap & Tumbleweed we currently have the following logic for choosing which tool manages your network after installation
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
I've noticed an increasing trend that this can lead to confusion.
Many users from other distributions expect NetworkManager on their desktops regardless of whether they are using a laptop or a desktop.
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
There are certainly classes of hardware where NetworkManager might be wanted that will never match "IF laptop" - eg. my personal Inter Compute Stick.
And "IF laptop" is dependant on YaST correctly detecting you're using a laptop, which isn't 100% accurate, so occasionally even laptops might end up with wicked unexpectedly.
I would like to propose a possible solution.
It looks like we should be able to pin the choice of network tool to specific system role.
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
Custom will keep the current "autodetect" behaviour, because we cant be sure that the environment that the user is installing has support for NetworkManager in this case.
Whatever is setup "by default" during installation will be able to be changed in YAST after the installation, just like it is today.
What do we all think? If there is strong support for this idea I think Ludwig is prepared to let me try and slip it in as a late feature for Leap 15, so please let your opinions be heard loudly and quickly either way.
Regards,
Richard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/10/2018 05:16 AM, Richard Brown wrote:
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
Looking through the other replies, I see that one "benefit" of NetworkManager has not been mentioned.
If I have, say, Leap 42.3, Leap 15.0 Beta and Tumbleweed all installed on different partitions (and I do), and they all use "NetworkManager", then my computer will have three different IPv6 addresses, depending on which OS is currently running. And the dns_masq service running on the LAN router will know all three of those. So if I want to SSH into that box from another system on LAN, I can sit back and relax while it times out on two of those IPv6 addresses, before it eventually finds the one that works.
If all three were to use "wicked", life would be boring for they would all have the same IPv6 address (derived partly from MAC address).
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
Clearly, this is a Gnome bug. It is not up to Gnome to decide how the network is managed.
Okay, I'm just giving my two cents. I can live with whatever is adopted. Right now, using "wicked", I am having to statically define the IPv4 address for both Leap 15.0 and Tumbleweed (but not for 42.3). That's reported as bug 1080832, which has not received any loving attention.
Am 10.04.2018 um 19:12 schrieb Neil Rickert:
On 04/10/2018 05:16 AM, Richard Brown wrote:
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
Looking through the other replies, I see that one "benefit" of NetworkManager has not been mentioned.
If I have, say, Leap 42.3, Leap 15.0 Beta and Tumbleweed all installed on different partitions (and I do), and they all use "NetworkManager", then my computer will have three different IPv6 addresses, depending on which OS is currently running. And the dns_masq service running on the LAN router will know all three of those. So if I want to SSH into that box from another system on LAN, I can sit back and relax while it times out on two of those IPv6 addresses, before it eventually finds the one that works.
If all three were to use "wicked", life would be boring for they would all have the same IPv6 address (derived partly from MAC address).
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
Clearly, this is a Gnome bug. It is not up to Gnome to decide how the network is managed.
Okay, I'm just giving my two cents. I can live with whatever is adopted. Right now, using "wicked", I am having to statically define the IPv4 address for both Leap 15.0 and Tumbleweed (but not for 42.3). That's reported as bug 1080832, which has not received any loving attention.
Tumbleweed currently has 82 open bugs related to NetworkManager:
https://bugzilla.opensuse.org/buglist.cgi?bug_status=__open__&content=ne...
Regards, Frank
Citeren Neil Rickert nrickert@ameritech.net:
On 04/10/2018 05:16 AM, Richard Brown wrote:
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
Looking through the other replies, I see that one "benefit" of NetworkManager has not been mentioned.
If I have, say, Leap 42.3, Leap 15.0 Beta and Tumbleweed all installed on different partitions (and I do), and they all use "NetworkManager", then my computer will have three different IPv6 addresses, depending on which OS is currently running. And the dns_masq service running on the LAN router will know all three of those. So if I want to SSH into that box from another system on LAN, I can sit back and relax while it times out on two of those IPv6 addresses, before it eventually finds the one that works.
If all three were to use "wicked", life would be boring for they would all have the same IPv6 address (derived partly from MAC address).
Wicked apparently defaults to using a MAC based IPv6 address and NetworkManager a privacy address (that isn't based on a MAC address). If having a consistent address is important to you, switch privacy off in NetworkManager and you'll get a MAC based IPv6 address too or use DHCPv6 for IPv6 address configuration (supported by both wicked and NetworkManager).
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
Clearly, this is a Gnome bug. It is not up to Gnome to decide how the network is managed.
Okay, I'm just giving my two cents. I can live with whatever is adopted. Right now, using "wicked", I am having to statically define the IPv4 address for both Leap 15.0 and Tumbleweed (but not for 42.3). That's reported as bug 1080832, which has not received any loving attention.
On 04/10/2018 12:31 PM, Arjen de Korte wrote:
Wicked apparently defaults to using a MAC based IPv6 address and NetworkManager a privacy address (that isn't based on a MAC address). If having a consistent address is important to you, switch privacy off in NetworkManager and you'll get a MAC based IPv6 address too or use DHCPv6 for IPv6 address configuration (supported by both wicked and NetworkManager).
Switching privacy off doesn't actually work. With the NetworkManager in Tumbleweed and that in Leap 15.0, you still get a randomly chosen local part of the address, and different for each system.
After turning privacy off, I have to edit the appropriate connection file in "/etc/NetworkManager/system-connections, and change
"stable-privacy" to "eui64"
As for using DHCPv6: If I turn on address allocation in my router, then the result is that with NetworkManager, I get two IPv6 addresses. I get the one that NetworkManager would use without DHCPv6, and I also get the additional address assigned by the router/DHCPv6-server.
Neil Rickert wrote:
As for using DHCPv6: If I turn on address allocation in my router, then the result is that with NetworkManager, I get two IPv6 addresses. I get the one that NetworkManager would use without DHCPv6, and I also get the additional address assigned by the router/DHCPv6-server.
The latter (scope global dynamic) should take priority. The MAC based and the privacy address should both be ignored.
Отправлено с iPhone
10 апр. 2018 г., в 21:12, Neil Rickert nrickert@ameritech.net написал(а):
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
Clearly, this is a Gnome bug. It is not up to Gnome to decide how the network is managed.
Sorry? GNOME supports NM; when NM is not active, GNOME cannot do anything and tells user to use YaST instead. What exactly *is* “the bug” here (and in all capitals as was put initially)? What do you expect GNOME to do? How user not using NM is suddenly GNOME fault in the first place?-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/10/2018 12:49 PM, Andrei Borzenkov wrote:
Clearly, this is a Gnome bug. It is not up to Gnome to decide how the network is managed.
Sorry? GNOME supports NM; when NM is not active, GNOME cannot do anything and tells user to use YaST instead.
Yes, but that is surely an openSUSE modification, rather than what is provided by upstream Gnome. When this behavior of "Settings" first started (I think it was with Gnome 3.26), it gave what was clearly an error message about NetworkManager not running.
Отправлено с iPhone
11 апр. 2018 г., в 5:57, Neil Rickert nrickert@ameritech.net написал(а):
On 04/10/2018 12:49 PM, Andrei Borzenkov wrote:
Clearly, this is a Gnome bug. It is not up to Gnome to decide how the network is managed.
Sorry? GNOME supports NM; when NM is not active, GNOME cannot do anything and tells user to use YaST instead.
Yes, but that is surely an openSUSE modification, rather than what is provided by upstream Gnome. When this behavior of "Settings" first started (I think it was with Gnome 3.26), it gave what was clearly an error message about NetworkManager not running.
So GNOME bug is that it gives error message about NM not running when NM is not running? Again - what exactly it is supposed to do in this case?-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/10/2018 10:49 PM, Andrei Borzenkov wrote:
So GNOME bug is that it gives error message about NM not running when NM is not running? Again - what exactly it is supposed to do in this case?--
Sigh!
I want to turn off the automatic screen lock. So I go into Settings. And it gives me a large in-your-face message about NetworkManager that makes it look as if something is broken on my system.
What it should do is just present me with the list of settings that I can change, and not mention NetworkManager unless I click on the Network settings options.
Richard Brown wrote:
What do we all think? If there is strong support for this idea I think Ludwig is prepared to let me try and slip it in as a late feature for Leap 15, so please let your opinions be heard loudly and quickly either way.
I would vote no. We use NFS on all desktops, including some booting over NFS. My experiments with NetworkManager and NFS have been, well, tiring.
On mercredi, 11 avril 2018 18.13:00 h CEST Per Jessen wrote:
Richard Brown wrote:
What do we all think? If there is strong support for this idea I think Ludwig is prepared to let me try and slip it in as a late feature for Leap 15, so please let your opinions be heard loudly and quickly either way.
I would vote no. We use NFS on all desktops, including some booting over NFS. My experiments with NetworkManager and NFS have been, well, tiring.
Hi Per, did you try with autofs, I'm using it from TW and with ipv4/ipv6 nfs3 & 4 never get a trouble on mount on access ? I don't know how it would extend for mounted at boot but perhaps there's a better deps management ?
Bruno Friedmann wrote:
On mercredi, 11 avril 2018 18.13:00 h CEST Per Jessen wrote:
Richard Brown wrote:
What do we all think? If there is strong support for this idea I think Ludwig is prepared to let me try and slip it in as a late feature for Leap 15, so please let your opinions be heard loudly and quickly either way.
I would vote no. We use NFS on all desktops, including some booting over NFS. My experiments with NetworkManager and NFS have been, well, tiring.
Hi Per, did you try with autofs,
Hi Bruno
no, I haven't tried it - we don't have that many users, having static nfs mounts is fine.
I'm using it from TW and with ipv4/ipv6 nfs3 & 4 never get a trouble on mount on access ? I don't know how it would extend for mounted at boot but perhaps there's a better deps management ?
Mount at boot isn't necessary, the NFS shares are only needed when users are logged in. It could well be done with autofs, maybe that's worth trying. You meant systemd autofs ?
Per Jessen wrote:
Bruno Friedmann wrote:
[snip]
Hi Per, did you try with autofs,
Hi Bruno
no, I haven't tried it - we don't have that many users, having static nfs mounts is fine.
Bruno, thanks for the tip - that seems to be working just fine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: alpine.LSU.2.21.1804131541220.8015@Telcontar.valinor
On Friday, 2018-04-13 at 10:57 +0200, Per Jessen wrote:
El 2018-04-13 a las 10:57 +0200, Per Jessen escribió:
Date: Fri, 13 Apr 2018 10:57:55 +0200 From: Per Jessen per@computer.org Reply-To: OS-fctry opensuse-factory@opensuse.org To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] Re: NFS mounts
Per Jessen wrote:
Bruno Friedmann wrote:
[snip]
Hi Per, did you try with autofs,
Hi Bruno
no, I haven't tried it - we don't have that many users, having static nfs mounts is fine.
Bruno, thanks for the tip - that seems to be working just fine.
Which one are you using? I use systemd autofs for an nfs mount on a machine, works just fine.
- -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: alpine.LSU.2.21.1804131541220.8015@Telcontar.valinor
On Friday, 2018-04-13 at 10:57 +0200, Per Jessen wrote:
El 2018-04-13 a las 10:57 +0200, Per Jessen escribió:
Date: Fri, 13 Apr 2018 10:57:55 +0200 From: Per Jessen per@computer.org Reply-To: OS-fctry opensuse-factory@opensuse.org To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] Re: NFS mounts
Per Jessen wrote:
Bruno Friedmann wrote:
[snip]
Hi Per, did you try with autofs,
Hi Bruno
no, I haven't tried it - we don't have that many users, having static nfs mounts is fine.
Bruno, thanks for the tip - that seems to be working just fine.
Which one are you using? I use systemd autofs for an nfs mount on a machine, works just fine.
Same here.
On 04/13/2018 08:51 AM, Per Jessen wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: alpine.LSU.2.21.1804131541220.8015@Telcontar.valinor
On Friday, 2018-04-13 at 10:57 +0200, Per Jessen wrote:
El 2018-04-13 a las 10:57 +0200, Per Jessen escribió:
Date: Fri, 13 Apr 2018 10:57:55 +0200 From: Per Jessen per@computer.org Reply-To: OS-fctry opensuse-factory@opensuse.org To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] Re: NFS mounts
Per Jessen wrote:
Bruno Friedmann wrote:
[snip]
Hi Per, did you try with autofs,
Hi Bruno
no, I haven't tried it - we don't have that many users, having static nfs mounts is fine.
Bruno, thanks for the tip - that seems to be working just fine.
Which one are you using? I use systemd autofs for an nfs mount on a machine, works just fine.
Same here.
In a section on mounting file systems in a Linux class I'm teaching, the issue of autofs came up. Once I learned how to set it up, I switched a static NFS mount that is only used for backups to systemd autofs. As others have noted, it works well.
Larry
On mardi, 10 avril 2018 12.16:10 h CEST Richard Brown wrote:
Hi All,
In both Leap & Tumbleweed we currently have the following logic for choosing which tool manages your network after installation
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
I've noticed an increasing trend that this can lead to confusion.
Sorry to be in late (if 2 days is :-) I didn't see any words about : install from network. the use case is pxe enabled boot, or installation from booting our installer kernel. Will we manage a boot kernel parameter to pre choose the network engine we will use ? like a net-manager=wicked/nm ? (Which I guess would be also so cool for openqa).
Yast team also should have an easier life, as once connected, we will not drop one to use the other. But then a defaut as to be made before the installer know what would be the object of the installation ?
If that is handled, well I'm ok for the changes, as it propose a sane default and offer choice and freedom.
I share the same feeling about being sad to not have seen a global collaboration around the best of art network component shared and developed by all brilliant people. But still I keep faith in ;-)
On 10 April 2018 at 12:16, Richard Brown RBrownCCB@opensuse.org wrote:
Hi All,
In both Leap & Tumbleweed we currently have the following logic for choosing which tool manages your network after installation
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
I've noticed an increasing trend that this can lead to confusion.
Many users from other distributions expect NetworkManager on their desktops regardless of whether they are using a laptop or a desktop.
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
There are certainly classes of hardware where NetworkManager might be wanted that will never match "IF laptop" - eg. my personal Inter Compute Stick.
And "IF laptop" is dependant on YaST correctly detecting you're using a laptop, which isn't 100% accurate, so occasionally even laptops might end up with wicked unexpectedly.
I would like to propose a possible solution.
It looks like we should be able to pin the choice of network tool to specific system role.
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
Custom will keep the current "autodetect" behaviour, because we cant be sure that the environment that the user is installing has support for NetworkManager in this case.
Whatever is setup "by default" during installation will be able to be changed in YAST after the installation, just like it is today.
What do we all think? If there is strong support for this idea I think Ludwig is prepared to let me try and slip it in as a late feature for Leap 15, so please let your opinions be heard loudly and quickly either way.
Regards,
Richard
Reviving this old thread just to say that after all the feedback on this thread, it's now my intention to implement this soon (probably after Hackweek)
This will mean I hope for it to be available in Tumbleweed & Leap 15 SP1
This change will likely come alongside some cleanup with the installation workflow. The intention is to stop using the openSUSE specific 'Desktop Selection' module in YaST, and instead use the SLE15/Kubic style 'System Role' screen
Practically speaking, users should notice no real functional change. The same 5 options (KDE Desktop, GNOME Desktop, Server & Transactional Server, and Custom) should be offered
But will instead be presented with a menu that will include more help text for each option, describing what each system role does for example. You can see how this works in openSUSE Kubic, which has already moved to this module in it's installation workflow.
Behind the scenes this will give me an excuse to do a major tidy up to the spiders-web which is 'skelcd-control-openSUSE' and remove lots of now obsolete options and references, that no one dares remove because we're all scared of breaking the old installation workflow.
It will also allow the YaST team to stop maintaining all of that unshared openSUSE specific code, and give openSUSE the opportunity to investigate options currently available in SLE, such as having system-roles offered by rpm packages. This is used by SLE to allow SLE modules to add new system role options on the installer. In theory openSUSE could use it so additional repositories could do the same thing. AFAIK there's no plans for anyone to actually make use of this, but I think it's kinda cool so I wanted to mention it here.
Obviously, everything done here will be fully tested and will only be seen by users once it's passed several layers of testing. But if anyone strongly objects, here's your opportunity to persuade me otherwise before I inconveniencing some btrfs datablocks with my xml.
Regards,
Richard
On Thu, 5 Jul 2018 16:20:39 +0200 Richard Brown RBrownCCB@opensuse.org wrote:
On 10 April 2018 at 12:16, Richard Brown RBrownCCB@opensuse.org wrote:
Hi All,
In both Leap & Tumbleweed we currently have the following logic for choosing which tool manages your network after installation
"IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked"
I've noticed an increasing trend that this can lead to confusion.
Many users from other distributions expect NetworkManager on their desktops regardless of whether they are using a laptop or a desktop.
GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1]
There are certainly classes of hardware where NetworkManager might be wanted that will never match "IF laptop" - eg. my personal Inter Compute Stick.
And "IF laptop" is dependant on YaST correctly detecting you're using a laptop, which isn't 100% accurate, so occasionally even laptops might end up with wicked unexpectedly.
I would like to propose a possible solution.
It looks like we should be able to pin the choice of network tool to specific system role.
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
Custom will keep the current "autodetect" behaviour, because we cant be sure that the environment that the user is installing has support for NetworkManager in this case.
Whatever is setup "by default" during installation will be able to be changed in YAST after the installation, just like it is today.
What do we all think? If there is strong support for this idea I think Ludwig is prepared to let me try and slip it in as a late feature for Leap 15, so please let your opinions be heard loudly and quickly either way.
Regards,
Richard
Reviving this old thread just to say that after all the feedback on this thread, it's now my intention to implement this soon (probably after Hackweek)
This will mean I hope for it to be available in Tumbleweed & Leap 15 SP1
This change will likely come alongside some cleanup with the installation workflow. The intention is to stop using the openSUSE specific 'Desktop Selection' module in YaST, and instead use the SLE15/Kubic style 'System Role' screen
Practically speaking, users should notice no real functional change. The same 5 options (KDE Desktop, GNOME Desktop, Server & Transactional Server, and Custom) should be offered
But will instead be presented with a menu that will include more help text for each option, describing what each system role does for example. You can see how this works in openSUSE Kubic, which has already moved to this module in it's installation workflow.
Behind the scenes this will give me an excuse to do a major tidy up to the spiders-web which is 'skelcd-control-openSUSE' and remove lots of now obsolete options and references, that no one dares remove because we're all scared of breaking the old installation workflow.
It will also allow the YaST team to stop maintaining all of that unshared openSUSE specific code, and give openSUSE the opportunity to investigate options currently available in SLE, such as having system-roles offered by rpm packages. This is used by SLE to allow SLE modules to add new system role options on the installer. In theory openSUSE could use it so additional repositories could do the same thing. AFAIK there's no plans for anyone to actually make use of this, but I think it's kinda cool so I wanted to mention it here.
Obviously, everything done here will be fully tested and will only be seen by users once it's passed several layers of testing. But if anyone strongly objects, here's your opportunity to persuade me otherwise before I inconveniencing some btrfs datablocks with my xml.
Regards,
Richard
+1
This seems completely sensible to me. For those who have not been expsoed to SLE15, I like the new installer method with "roles".
Tnanks,
Peter
-
Alex DWS -
Ancor Gonzalez Sosa -
Andreas Schwab -
Andrei Borzenkov -
Andrei Dziahel -
Arjen de Korte -
Bruno Friedmann -
Brüns, Stefan -
Carlos E. R. -
Felix Miata -
Frank Krüger -
Fraser_Bell -
Frederic Crozat -
Herbert Graeber -
Jan Engelhardt -
Johannes Meixner -
Josef Reidinger -
Karl Sinn -
Knurpht ＠ openSUSE -
Larry Finger -
Mathias Homann -
Michael Ströder -
Michal Kubecek -
Michal Suchánek -
Mike Galbraith -
Mikhail Kasimov -
Neil Rickert -
Ondřej Súkup -
Patrick Shanahan -
Per Jessen -
Peter Linnell -
Peter Suetterlin -
Ralf Lang -
Richard Brown -
Richard Tennis -
Roman Bysh -
Simon Lees -
Stefan Brüns
-
Stefan Seyfried -
Stephan Kulow -
Werner Flamme -
Wolfgang Bauer