Network Manager and my 'Use Case'
Hi All I am currently using Wicked for network connection, but very much aware that this appears to be deprecated and likely to be taken out of the next version of Leap, so I have been looking at Network Manager and hit against some issues. I run several machines on a network with a NAS for shared storage. I import a home drive image with NFS to /import/home and soft link several individual user images into /home to allow user logon to a personal environment on each of several computers on the network. So far, so good - it works really well for my small setup for several years across all Leap 15.x. Moreover, a switch between Wicked and Network Manager is sufficiently slick that I can have some user IDs on the laptop only and use available wifi away from home via Network Manager. Problems come when I try to use Network Manager for the setup at home, in that Network Manager is not invoked [by systemd?] at the same point as Wicked is. So that leaves the NFS shares unconnected when the logon screen becomes available [ie the ID's on NFS don't show up] and it appears that Network Manager is more a per user subsystem for which you need to log in in order to get the connections you want. Now, I can work around this by logging in as root and doing 'mount -a' and there appears to be some options in fstab to make this work, so I am not totally stuck. Thus, my question for anyone who has confronted similar: Is there a 'best' or 'recommended ' way to address this issue and get the NFS shares available with Network Manager before the logon screen displays. Thanks in advance, any and all help on this appreciated CR
On Mon, Apr 24, 2023 at 2:05 PM Charles Rinnoch <lists.opensuse-support@difrenchal.scot> wrote:
Problems come when I try to use Network Manager for the setup at home, in that Network Manager is not invoked [by systemd?] at the same point as Wicked is.
It is.
So that leaves the NFS shares unconnected when the logon screen becomes available [ie the ID's on NFS don't show up] and it appears that Network Manager is more a per user subsystem for which you need to log in in order to get the connections you want.
It is not. Wicked is synchronous, its unit completes startup after interfaces have been configured. NetworkManager is asynchronous - when NetworkManager unit completed startup, it just means the daemon was started. Daemon proceeds to establish connections concurrently with any other startup activity. You need to enable NetworkManager-wait-online.service which will delay followup processing until NteworkManager reports it reached online state. NFS mount points automatically order themselves after network-online.target (which will be after NetworkManager-wait-online.service). If you have some custom units that need network on startup, you need to order them after network-online.target manually.
On Monday, 24 April 2023 12:16:27 BST Andrei Borzenkov wrote:
On Mon, Apr 24, 2023 at 2:05 PM Charles Rinnoch
<lists.opensuse-support@difrenchal.scot> wrote:
Problems come when I try to use Network Manager for the setup at home, in that Network Manager is not invoked [by systemd?] at the same point as Wicked is. It is.
So that leaves the NFS shares unconnected when the logon screen becomes available [ie the ID's on NFS don't show up] and it appears that Network Manager is more a per user subsystem for which you need to log in in order to get the connections you want.
It is not.
Wicked is synchronous, its unit completes startup after interfaces have been configured. NetworkManager is asynchronous - when NetworkManager unit completed startup, it just means the daemon was started. Daemon proceeds to establish connections concurrently with any other startup activity.
You need to enable NetworkManager-wait-online.service which will delay followup processing until NteworkManager reports it reached online state. NFS mount points automatically order themselves after network-online.target (which will be after NetworkManager-wait-online.service). If you have some custom units that need network on startup, you need to order them after network-online.target manually.
Thanks Andrei I have not had much need to adjust services [a good thing], but I think I know what I need to do to implement this. For using the laptop away from my network - and NFS shares not available - presumably I can expect to get to my logon screen after a timeout for the NFS not appearing? I'll give this a go later today.
On Monday, 24 April 2023 12:16:27 BST Andrei Borzenkov wrote:
On Mon, Apr 24, 2023 at 2:05 PM Charles Rinnoch
<lists.opensuse-support@difrenchal.scot> wrote:
Problems come when I try to use Network Manager for the setup at home, in that Network Manager is not invoked [by systemd?] at the same point as Wicked is. It is.
Wicked is synchronous, its unit completes startup after interfaces have been configured. NetworkManager is asynchronous - when NetworkManager unit completed startup, it just means the daemon was started. Daemon proceeds to establish connections concurrently with any other startup activity.
You need to enable NetworkManager-wait-online.service which will delay followup processing until NteworkManager reports it reached online state. NFS mount points automatically order themselves after network-online.target (which will be after NetworkManager-wait-online.service). If you have some custom units that need network on startup, you need to order them after network-online.target manually.
Thanks Andrei, but no joy. systemctl status NetworkManager-wait-online.service tells me that this service runs for 4s or so, but systemctl status tells me that the overall status is 'degraded'. systemctl --failed tells me that the unit import-home.mount failed. However, if I run systemctl start import-home.mount then the mount is made successfully - ie I get the sytem running as I want it. This tells me that Network Manager is fundamentally working and I think I have a race condition with the mount being called too soon. I have taken a look at /run/systemd/generator/import-home.mount under both Wicked and NM and they are the same and appear to be regenerated when I use YaST to switch between NM and Wicked. So a race which works out OK under Wicked but not NM? Or something else about NM not being set up right? Overall, as I have said elsewhere, so far I have learned that both NM and Wicked can provide any of my use cases - the differences between the 2 [as far as the user is concerned] relate to the availability and utility of the tools [YaST, nmtui etc] to set them up and how they are set up within systemd. Anyway, appreciative of the help so far and would welcome any more help. Systems are Leap 15.4. Issue manifests on Wireless for laptop and Ethernet for Desktop although conducting investigations on laptop only at the moment. Also my network runs a fixed IP plus a DHCP on network interfaces, although the problem still manifests with fixed IP only on the same subnet as the nfs server. Regards CR
On Tue, 25 Apr 2023, 13:42:59 +0200, Charles Rinnoch wrote:
[...] Anyway, appreciative of the help so far and would welcome any more help. Systems are Leap 15.4. Issue manifests on Wireless for laptop and Ethernet for Desktop although conducting investigations on laptop only at the moment. Also my network runs a fixed IP plus a DHCP on network interfaces, although the problem still manifests with fixed IP only on the same subnet as the nfs server.
Have you ever thought about using autofs for auto-mounting your NFS directories instead of manual/hard mounting?
Regards
CR
HTH, cheers. l8er manfred
On Tue, Apr 25, 2023 at 2:43 PM Charles Rinnoch <lists.opensuse-support@difrenchal.scot> wrote:
Thanks Andrei, but no joy. systemctl status NetworkManager-wait-online.service tells me that this service runs for 4s or so, but systemctl status tells me that the overall status is 'degraded'. systemctl --failed tells me that the unit import-home.mount failed.
Show /etc/fstab Are you using wired or wireless connection? Provide full output of journalctl -b --full --no-pager
On Tuesday, 25 April 2023 12:57:52 BST Andrei Borzenkov wrote:
On Tue, Apr 25, 2023 at 2:43 PM Charles Rinnoch
<lists.opensuse-support@difrenchal.scot> wrote:
Thanks Andrei, but no joy. systemctl status NetworkManager-wait-online.service tells me that this service runs for 4s or so, but systemctl status tells me that the overall status is 'degraded'. systemctl --failed tells me that the unit import-home.mount failed.
Show /etc/fstab
Relevant line: 172.20.20.8:/volume1/home /import/home nfs defaults 0 0 nb mount -a works
Are you using wired or wireless connection?
Wireless on the laptop I am investigating but also on a desktop with a wired connection. Hoping to fix on the laptop [where I have a need to use NM] and tackle the desktop as a separate issue if the solution does not transfer.
Provide full output of
journalctl -b --full --no-pager
There is some where I am supposed to upload this, I believe. Could you remind me please? Regards CR
On Tue, Apr 25, 2023 at 3:21 PM Charles Rinnoch <lists.opensuse-support@difrenchal.scot> wrote:
On Tuesday, 25 April 2023 12:57:52 BST Andrei Borzenkov wrote:
On Tue, Apr 25, 2023 at 2:43 PM Charles Rinnoch
<lists.opensuse-support@difrenchal.scot> wrote:
Thanks Andrei, but no joy. systemctl status NetworkManager-wait-online.service tells me that this service runs for 4s or so, but systemctl status tells me that the overall status is 'degraded'. systemctl --failed tells me that the unit import-home.mount failed.
Show /etc/fstab
Relevant line: 172.20.20.8:/volume1/home /import/home nfs defaults 0 0
nb mount -a works
Are you using wired or wireless connection?
Wireless on the laptop I am investigating but also on a desktop with a wired connection. Hoping to fix on the laptop [where I have a need to use NM] and tackle the desktop as a separate issue if the solution does not transfer.
Provide full output of
journalctl -b --full --no-pager
There is some where I am supposed to upload this, I believe. Could you remind me please?
On 2023-04-25 14:21, Charles Rinnoch wrote:
On Tuesday, 25 April 2023 12:57:52 BST Andrei Borzenkov wrote:
On Tue, Apr 25, 2023 at 2:43 PM Charles Rinnoch
Provide full output of
journalctl -b --full --no-pager
There is some where I am supposed to upload this, I believe. Could you remind me please? journalctl -b --full --no-pager | \ susepaste -n "Charles R" -t "journal output" -e 40320
That outputs on success a link which you paste on the email. The upload remains there for a month (the -e parameter; see "man susepaste" to choose different time) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Tuesday, 25 April 2023 12:57:52 BST Andrei Borzenkov wrote:
On Tue, Apr 25, 2023 at 2:43 PM Charles Rinnoch
<lists.opensuse-support@difrenchal.scot> wrote:
Thanks Andrei, but no joy. systemctl status NetworkManager-wait-online.service tells me that this service runs for 4s or so, but systemctl status tells me that the overall status is 'degraded'. systemctl --failed tells me that the unit import-home.mount failed.
Relevant line: 172.20.20.8:/volume1/home /import/home nfs defaults 0 0 nb mount -a works />/ /> Are you using wired or wireless connection?/ Wireless on the laptop I am investigating but also have the issue on a desktop with a wired connection. Hoping to fix on the laptop [where I have a need to use NM] and tackle the desktop as a separate issue but expecting that the solution will transfer
Provide full output of journalctl -b --full --no-pager
This is at paste.opensuse.org/pastes/840930d8954d Regards CR
On Tue, Apr 25, 2023 at 10:56 PM Charles Rinnoch <lists.opensuse-support@difrenchal.scot> wrote:
NetworkManager-wait-online.service tells me that this service runs for 4s
or so, but systemctl status tells me that the overall status is
'degraded'. systemctl --failed tells me that the unit import-home.mount
failed.
...
Provide full output of journalctl -b --full --no-pager
This is at paste.opensuse.org/pastes/840930d8954d
Well ... NetworkManager-wait-online calls "nm-online -s". According to documentation, it should wait until NetworkManager startup is complete and it sounds like "startup complete" includes activation of connections ... except it does not. Apr 25 20:37:11 smolevo NetworkManager[1079]: <info> [1682451431.7623] manager: startup complete Apr 25 20:37:11 smolevo systemd[1]: Finished Network Manager Wait Online. ... Apr 25 20:37:22 smolevo NetworkManager[1079]: <info> [1682451442.0321] dhcp4 (wlan0): address 172.20.30.40 ... Apr 25 20:37:22 smolevo NetworkManager[1079]: <info> [1682451442.0563] manager: NetworkManager state is now CONNECTED_LOCAL Apr 25 20:37:22 smolevo NetworkManager[1079]: <info> [1682451442.0572] manager: NetworkManager state is now CONNECTED_SITE ... Apr 25 20:37:22 smolevo NetworkManager[1079]: <info> [1682451442.4698] manager: NetworkManager state is now CONNECTED_GLOBAL So the interface gets an IP address ten seconds after NetworkManager startup is complete. I cannot tell whether this is a bug in NetworkManager or something is missing in configuration, but the most straightforward workaround is to wait for the online state, instead of startup. Edit NetworkManager-wait-online.service and remove "-s" from nm-online call. Replace ExecStart=/bin/bash -c "if [ ${NM_ONLINE_TIMEOUT} -gt 0 ]; then /usr/bin/nm-online -s -q --timeout=${NM_ONLINE_TIMEOUT} ; else /bin/true ; fi" with ExecStart=/bin/bash -c "if [ ${NM_ONLINE_TIMEOUT} -gt 0 ]; then /usr/bin/nm-online -q --timeout=${NM_ONLINE_TIMEOUT} ; else /bin/true ; fi"
On Wed, 26 Apr 2023 11:42:34 +0300, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
[...] I cannot tell whether this is a bug in NetworkManager or something is missing in configuration, but the most straightforward workaround is to wait for the online state, instead of startup. Edit NetworkManager-wait-online.service and remove "-s" from nm-online call. Replace
ExecStart=/bin/bash -c "if [ ${NM_ONLINE_TIMEOUT} -gt 0 ]; then /usr/bin/nm-online -s -q --timeout=${NM_ONLINE_TIMEOUT} ; else /bin/true ; fi"
with
ExecStart=/bin/bash -c "if [ ${NM_ONLINE_TIMEOUT} -gt 0 ]; then /usr/bin/nm-online -q --timeout=${NM_ONLINE_TIMEOUT} ; else /bin/true ; fi"
Just a point about shell syntax. The 'else' clause (in both versions) is not needed. The 'if' command would have the same status result without it. The value of the test does not affect the result, only which clause gets executed, and then the last-executed command, if any, within the 'if' determines its result status. If no command is executed, such as when the test is false and there is no else clause, the result of the 'if' is true anyway. (The commands within the 'if' clauses, though, do see the test's result status.) xx> if false ; then echo TRUE ; fi ; echo "($?)" (0) xx> if false ; then echo TRUE ; else echo "($?)" ; fi (1) But for this, I prefer a simpler construct using the complementary test: test ${NM_ONLINE_TIMEOUT} -le 0 \ || /usr/bin/nm-online -q --timeout=${NM_ONLINE_TIMEOUT} -- Robert Webb
On Wednesday, 26 April 2023 09:42:34 BST Andrei Borzenkov wrote:
I cannot tell whether this is a bug in NetworkManager or something is missing in configuration, but the most straightforward workaround is to wait for the online state, instead of startup. Edit NetworkManager-wait-online.service and remove "-s" from nm-online call. Replace
ExecStart=/bin/bash -c "if [ ${NM_ONLINE_TIMEOUT} -gt 0 ]; then /usr/bin/nm-online -s -q --timeout=${NM_ONLINE_TIMEOUT} ; else /bin/true ; fi"
with
ExecStart=/bin/bash -c "if [ ${NM_ONLINE_TIMEOUT} -gt 0 ]; then /usr/bin/nm-online -q --timeout=${NM_ONLINE_TIMEOUT} ; else /bin/true ; fi"
Thanks Andrei. That has fixed it! And thanks to everyone who has contributed. For completeness, I will document some additional info here. A useful resource is: https://doc.opensuse.org/documentation/leap/archive/42.1/reference/html/ book.opensuse.reference/cha.systemd.html That states [section 10.5.1] that systemd service files are located in /usr/ lib/systemd/system but advises to make a local copy for anything to be modified manually in /etc/systemd/system. This takes precedence for execution but is left untouched by system updates. That worked for me. This does not look like a bug in NM to me as the core functionality of NM is fine. It also looks like nm-online is behaving in accordance with its man page with the -s option doing as expected. So I am left thinking that the problem is with NetworkManager-wait-online.service. I would say your workaround, Andrei is actually the required fix, although there may be cases where the -s option is exactly what is required, in which case the solution would be a different *.service module. To fully close this out, should I log this as a bug and if so where? Regards and once again thanks CR
On Wed, Apr 26, 2023 at 3:19 PM Charles Rinnoch <lists.opensuse-support@difrenchal.scot> wrote:
This does not look like a bug in NM to me as the core functionality of NM is fine. It also looks like nm-online is behaving in accordance with its man page with the -s option doing as expected.
Bug as in "NM reaches startup finished state too early without waiting for initial connection activation".
To fully close this out, should I log this as a bug and if so where?
It certainly would not harm, for 15.4 this should go into bugzilla.opensuse.org.
On Wednesday, 26 April 2023 13:30:43 BST Andrei Borzenkov wrote:
On Wed, Apr 26, 2023 at 3:19 PM Charles Rinnoch
<lists.opensuse-support@difrenchal.scot> wrote:
This does not look like a bug in NM to me as the core functionality of NM is fine. It also looks like nm-online is behaving in accordance with its man page with the -s option doing as expected.
Bug as in "NM reaches startup finished state too early without waiting for initial connection activation".
To fully close this out, should I log this as a bug and if so where?
It certainly would not harm, for 15.4 this should go into bugzilla.opensuse.org.
Bugged at https://bugzilla.opensuse.org/show_bug.cgi?id=1210883
On Tuesday, 25 April 2023 12:57:52 BST Andrei Borzenkov wrote:
Provide full output of
journalctl -b --full --no-pager
OK, looking at the log [paste.opensuse.org/pastes/840930d8954d], I can see line 1420: Apr 25 20:37:12 smolevo mount[1310]: mount.nfs: Network is unreachable line 1590: Apr 25 20:37:19 smolevo avahi-daemon[853]: Registering new address record for 172.20.20.35 on wlan0.IPv4. So we don't have an IP address on the network with the nfs share until line 1590, but we try the nfs mount at line 1420. OK, the problem is obvious, the solution not so obvious. Regards CR
Charles Rinnoch composed on 2023-04-24 12:05 (UTC+0100):
Now, I can work around this by logging in as root and doing 'mount -a' and there appears to be some options in fstab to make this work, so I am not totally stuck. Thus, my question for anyone who has confronted similar: Is there a 'best' or 'recommended ' way to address this issue and get the NFS shares available with Network Manager before the logon screen displays.
One need use neither NM nor Wicked.
Thanks in advance, any and all help on this appreciated
Networking system #3 is not available via YaST as yet: systemd-networkd. # systemctl list-unit-files | egrep 'networkd|wicked|kManag' | grep -E 'enabled|solv' systemd-networkd-wait-online.service enabled disabled systemd-networkd.service enabled disabled systemd-networkd.socket enabled disabled # rpm -q NetworkManager # rpm -q wicked wicked-0.6.70-150400.3.3.1.x86_64 # rpm -q systemd-network systemd-network-249.15-150400.8.22.1.x86_64 # l /etc/systemd/network/*k -rw-r--r-- 1 root root 146 Aug 2 2021 /etc/systemd/network/eth0.network # cat /etc/systemd/network/*k [Match] Name=eth0 [Network] Address=192.168.yada/24 DNS=192.168.yada 8.8.4.4 1.0.0.1 Gateway=192.168.yada IPv6AcceptRA=no LinkLocalAddressing=no # # cat /usr/local/bin/zypsei #!/bin/sh zypper --no-refresh se -s -i $* | grep -Ev 'debug|devel|srcp|openSUSE-20' | grep -E 'x86|noarch'| sort # zypsei resolv # /etc/resolv.conf I copy from my LAN server to each distro installation. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Monday, 24 April 2023 15:42:30 BST Felix Miata wrote:
One need use neither NM nor Wicked.
Thanks in advance, any and all help on this appreciated
Networking system #3 is not available via YaST as yet: systemd-networkd.
Is that truly a 3rd option or is it actually a front within systemd for dealing with different options such as NM and Wicked more abstractly? I don't really expect to see systemd get its hands dirty with networking or anything tangible, but I do expect to see it orchestrating the invocation of such things as provided by others. CR
On Tue, 25 Apr 2023, 13:12:35 +0200, Charles Rinnoch wrote:
On Monday, 24 April 2023 15:42:30 BST Felix Miata wrote:
One need use neither NM nor Wicked.
Thanks in advance, any and all help on this appreciated
Networking system #3 is not available via YaST as yet: systemd-networkd.
Is that truly a 3rd option or is it actually a front within systemd for dealing with different options such as NM and Wicked more abstractly? I don't really expect to see systemd get its hands dirty with networking or anything tangible, but I do expect to see it orchestrating the invocation of such things as provided by others.
but it actually does ;) I use systemd-networkd here for my LAN, while NetworkManager is used for *only* WLAN[1]. Works pretty well. One big advantage of systemd-networkd over wicked is that it brings the network bridge I use for libvirt/kvm up much faster than wicked every did.
CR
HTH, cheers. l8er manfred [1]: /etc/NetworkManager/conf.d/myconf.conf: [main] no-auto-default=*,interface-name=br0,interface-name=enp*,interface-name=eth*
On Tue, Apr 25, 2023 at 2:43 PM Manfred Hollstein <mhollstein@t-online.de> wrote:
but it actually does ;) I use systemd-networkd here for my LAN, while NetworkManager is used for *only* WLAN[1].
systemd-networkd is identical to NetworkManager in that it is asynchronous and requires extra service to wait for interface configuration.
On Tue, 25 Apr 2023, 13:59:31 +0200, Andrei Borzenkov wrote:
On Tue, Apr 25, 2023 at 2:43 PM Manfred Hollstein <mhollstein@t-online.de> wrote:
but it actually does ;) I use systemd-networkd here for my LAN, while NetworkManager is used for *only* WLAN[1].
systemd-networkd is identical to NetworkManager in that it is asynchronous and requires extra service to wait for interface configuration.
Sure, but the question was if systemd-networkd is just a layer above NetworkManager or wicked, ie. if it is a truly separate 3rd option.
Charles Rinnoch composed on 2023-04-25 12:12 (UTC+0100):
Felix Miata wrote:
One need use neither NM nor Wicked.
Thanks in advance, any and all help on this appreciated
Networking system #3 is not available via YaST as yet: systemd-networkd.
Is that truly a 3rd option or is it actually a front within systemd for dealing with different options such as NM and Wicked more abstractly? I don't really expect to see systemd get its hands dirty with networking or anything tangible, but I do expect to see it orchestrating the invocation of such things as provided by others.
Systemd-networkd works with both NM and Wicked force uninstalled. Other software requires either NM or Wicked to be installed, which is why to force is required to see that systemd-networkd can stand alone to provide networking. # systemctl list-unit-files | egrep 'networkd|wick|kmanag' | sort systemd-networkd-wait-online.service enabled disabled systemd-networkd.service enabled disabled systemd-networkd.socket enabled disabled wicked.service masked disabled wickedd-auto4.service masked disabled wickedd-dhcp4.service masked disabled wickedd-dhcp6.service masked disabled wickedd-nanny.service masked disabled wickedd-pppd@.service masked disabled wickedd.service masked disabled # rpm -qa | egrep -i 'kmanag|wick|d-net' | sort systemd-network-249.15-150400.8.22.1.x86_64 wicked-0.6.70-150400.3.3.1.x86_64 wicked-service-0.6.70-150400.3.3.1.x86_64 # zypper rm wicked wicked-service Reading installed packages... Resolving package dependencies... The following 47 packages are going to be REMOVED: autoyast2-installation patterns-base-base patterns-base-basesystem patterns-base-enhanced_base patterns-base-x11 patterns-fonts-fonts sysconfig wicked wicked-service yast2 yast2-add-on yast2-auth-client yast2-bootloader yast2-control-center yast2-control-center-qt3 yast2-country yast2-firewall yast2-ftp-server yast2-installation yast2-journal yast2-ldap yast2-mail yast2-metapackage-handler yast2-network yast2-nfs-client yast2-nfs-server yast2-ntp-client yast2-online-update yast2-online-update-frontend yast2-packager yast2-pam yast2-printer yast2-proxy yast2-samba-client yast2-samba-server yast2-scanner yast2-security yast2-services-manager yast2-slp yast2-sound yast2-storage-ng yast2-sudo yast2-sysconfig yast2-tune yast2-update yast2-users yast2-vm The following 5 patterns are going to be REMOVED: base basesystem enhanced_base fonts x11 47 packages to remove. After the operation, 19.5 MiB will be freed. Continue? [y/n/v/...? shows all options] (y): n # -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Andrei Borzenkov composed on 2023-04-25 20:33 (UTC+0300):
Felix Miata wrote:
Systemd-networkd works with both NM and Wicked force uninstalled.
There is no need to remove anything.
Poster I was replying to questioned whether systemd-networkd depended on any other kind of networking software, such as NetworkManager or Wicked: [quote]
Is that truly a 3rd option or is it actually a front within systemd for dealing with different options such as NM and Wicked more abstractly? [/quote]
Systemd-networkd has no such dependence. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2023-04-25 08:49, Felix Miata wrote:
# zypper rm wicked wicked-service Reading installed packages... Resolving package dependencies...
The following 47 packages are going to be REMOVED: autoyast2-installation patterns-base-base patterns-base-basesystem patterns-base-enhanced_base patterns-base-x11 patterns-fonts-fonts sysconfig wicked wicked-service yast2 yast2-add-on yast2-auth-client yast2-bootloader yast2-control-center yast2-control-center-qt3 yast2-country yast2-firewall yast2-ftp-server yast2-installation yast2-journal yast2-ldap yast2-mail yast2-metapackage-handler yast2-network yast2-nfs-client yast2-nfs-server yast2-ntp-client yast2-online-update yast2-online-update-frontend yast2-packager yast2-pam yast2-printer yast2-proxy yast2-samba-client yast2-samba-server yast2-scanner yast2-security yast2-services-manager yast2-slp yast2-sound yast2-storage-ng yast2-sudo yast2-sysconfig yast2-tune yast2-update yast2-users yast2-vm
The following 5 patterns are going to be REMOVED: base basesystem enhanced_base fonts x11
47 packages to remove. After the operation, 19.5 MiB will be freed. Continue? [y/n/v/...? shows all options] (y): n #
Interesting... hadron:~ # zypper rm wicked wicked Reading installed packages... Resolving package dependencies... The following package is going to be REMOVED: wicked 1 package to remove. After the operation, 3.7 MiB will be freed. Continue? [y/n/v/...? shows all options] (y): n Curiously, however... hadron:~ # zypper info --requires wicked-service Loading repository data... Reading installed packages... Information for package wicked-service: --------------------------------------- <snip> Requires : [4] /bin/bash sysconfig >= 0.81.0 /bin/sh wicked = 0.6.70 <<<======= So, I have to wonder just why trying to remove wicked-service looks like it's going to wind up removing the entire OS from the system?!! There are a couple of other questions I could ask about this but this will do for now.
Darryl Gregorash composed on 2023-04-25 13:25 (UTC-0600):
Felix Miata wrote:
# zypper rm wicked wicked-service Reading installed packages... Resolving package dependencies...
The following 47 packages are going to be REMOVED: autoyast2-installation patterns-base-base patterns-base-basesystem patterns-base-enhanced_base patterns-base-x11 patterns-fonts-fonts sysconfig wicked wicked-service yast2 yast2-add-on yast2-auth-client yast2-bootloader yast2-control-center yast2-control-center-qt3 yast2-country yast2-firewall yast2-ftp-server yast2-installation yast2-journal yast2-ldap yast2-mail yast2-metapackage-handler yast2-network yast2-nfs-client yast2-nfs-server yast2-ntp-client yast2-online-update yast2-online-update-frontend yast2-packager yast2-pam yast2-printer yast2-proxy yast2-samba-client yast2-samba-server yast2-scanner yast2-security yast2-services-manager yast2-slp yast2-sound yast2-storage-ng yast2-sudo yast2-sysconfig yast2-tune yast2-update yast2-users yast2-vm
The following 5 patterns are going to be REMOVED: base basesystem enhanced_base fonts x11
47 packages to remove. After the operation, 19.5 MiB will be freed. Continue? [y/n/v/...? shows all options] (y): n # Interesting...
hadron:~ # zypper rm wicked wicked Reading installed packages... Resolving package dependencies...
The following package is going to be REMOVED: wicked
1 package to remove. After the operation, 3.7 MiB will be freed. Continue? [y/n/v/...? shows all options] (y): n
Curiously, however... hadron:~ # zypper info --requires wicked-service Loading repository data... Reading installed packages...
Information for package wicked-service: --------------------------------------- <snip> Requires : [4] /bin/bash sysconfig >= 0.81.0 /bin/sh wicked = 0.6.70 <<<=======
So, I have to wonder just why trying to remove wicked-service looks like it's going to wind up removing the entire OS from the system?!! There are a couple of other questions I could ask about this but this will do for now.
My previous post was from 15.4. TW is on track for retiring wicked, if it hasn't already: # zypper rm wicked-service Reading installed packages... Resolving package dependencies... The following 2 packages are going to be REMOVED: wicked wicked-service 2 packages to remove. After the operation, 3.8 MiB will be freed. Continue? [y/n/v/...? shows all options] (y): y (1/2) Removing wicked-0.6.72-2.2.x86_64 ...............................................................................................................................................[done] (2/2) Removing wicked-service-0.6.72-2.2.x86_64 .......................................................................................................................................[done] # rpm -q NetworkManager package NetworkManager is not installed # rpm -q wicked package wicked is not installed # rpm -q systemd-network systemd-network-253.3-1.1.x86_64 # -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2023-04-25 15:16, Felix Miata wrote:
Darryl Gregorash composed on 2023-04-25 13:25 (UTC-0600):
<snip> My previous post was from 15.4. TW is on track for retiring wicked, if it hasn't already:
If wicked is gone from 15.5, I shall return, asking about how to replace NetworkManager with networkd :D
Darryl Gregorash composed on 2023-04-25 17:34 (UTC-0600):
Felix Miata wrote:
Darryl Gregorash composed on 2023-04-25 13:25 (UTC-0600):
<snip> My previous post was from 15.4. TW is on track for retiring wicked, if it hasn't already:
If wicked is gone from 15.5, I shall return, asking about how to replace NetworkManager with networkd :D
It's still there: # cat /usr/local/bin/zypse #!/bin/sh zypper --no-refresh se -s $* | grep -Ev 'debug|devel|srcp|openSUSE-20' | grep -E 'x86|noarch'| sort # zypse wicked | wicked-nbft | package | 0.6.72-150500.1.1 | x86_64 | OSS i | wicked-service | package | 0.6.72-150500.1.1 | x86_64 | OSS i+ | wicked | package | 0.6.72-150500.1.1 | x86_64 | OSS # That needn't stop you from using systemd-networkd. It's pretty well covered here, assuming you're using eth0, static IP, and know how to build resolv.conf: <https://lists.opensuse.org/archives/list/support@lists.opensuse.org/message/U5JAS2JURUJ5TNFQHVM6Z6ZGB2ULICEA/> -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2023-04-25 22:49, Felix Miata wrote:
Darryl Gregorash composed on 2023-04-25 17:34 (UTC-0600):
Felix Miata wrote:
Darryl Gregorash composed on 2023-04-25 13:25 (UTC-0600):
<snip> My previous post was from 15.4. TW is on track for retiring wicked, if it hasn't already:
If wicked is gone from 15.5, I shall return, asking about how to replace NetworkManager with networkd :D
It's still there: # cat /usr/local/bin/zypse #!/bin/sh zypper --no-refresh se -s $* | grep -Ev 'debug|devel|srcp|openSUSE-20' | grep -E 'x86|noarch'| sort # zypse wicked | wicked-nbft | package | 0.6.72-150500.1.1 | x86_64 | OSS i | wicked-service | package | 0.6.72-150500.1.1 | x86_64 | OSS i+ | wicked | package | 0.6.72-150500.1.1 | x86_64 | OSS # That needn't stop you from using systemd-networkd. It's pretty well covered here, assuming you're using eth0, static IP, and know how to build resolv.conf: <https://lists.opensuse.org/archives/list/support@lists.opensuse.org/message/U5JAS2JURUJ5TNFQHVM6Z6ZGB2ULICEA/>
I have been following this thread, and I marked that message of yours. I have eth0 and can probably figure out how to write a resolv.conf, but static IP I cannot guarantee. M IP probably should not change so long as I remain on my present ISP node, but if I move it will be subject to change -- so I will need to learn how to set this up with DHCP (IPv4 only, my ISP seems unable to figure out IPv6. I think they're going to try handing out single IPs, like they do with IPv4.)
Darryl Gregorash composed on 2023-04-25 23:14 (UTC-0600):
I have been following this thread, and I marked that message of yours. I have eth0 and can probably figure out how to write a resolv.conf, but static IP I cannot guarantee. M IP probably should not change so long as I remain on my present ISP node, but if I move it will be subject to change -- so I will need to learn how to set this up with DHCP (IPv4 only, my ISP seems unable to figure out IPv6. I think they're going to try handing out single IPs, like they do with IPv4.)
If you're like most people in the USA with broadband, your PC is connected to a firewall/router box that connects to a cable modem, either of which either you or the ISP might own; or a combination router/firewall/modem, usually owned by the ISP. What your ISP does only really affects the modem side of a router, so need have nothing to do with how you configure networking on your computers if you own the router, and shouldn't need to if the ISP owns it. Your cable modem uses an IP assigned by the ISP picked up using DHCP. On the LAN side of your router, you can configure however you like, DHCP or not, if you own it, and should be able to do same even if it's owned by the ISP. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Darryl Gregorash composed on 2023-04-25 23:14 (UTC-0600):
I have been following this thread, and I marked that message of yours. I have eth0 and can probably figure out how to write a resolv.conf, but static IP I cannot guarantee. M IP probably should not change so long as I remain on my present ISP node, but if I move it will be subject to change -- so I will need to learn how to set this up with DHCP (IPv4 only, my ISP seems unable to figure out IPv6. I think they're going to try handing out single IPs, like they do with IPv4.)
If you're like most people in the USA with broadband, your PC is connected to a firewall/router box that connects to a cable modem, either of which either you or the ISP might own; or a combination router/firewall/modem, usually owned by the ISP. What your ISP does only really affects the modem side of a router, so need have nothing to do with how you configure networking on your computers if you own the router, and shouldn't need to if the ISP owns it. Your cable modem uses an IP assigned by the ISP picked up using DHCP. On the LAN side of your router, you can configure however you like, DHCP or not, if you own it, and should be able to do same even if it's owned by the ISP. My modem operates as a pass-through device only, and my PC is my router/firewall. I have a small local network, consisting of the PC and my ereader. I enable this only when I need to let the ereader connect to
On 2023-04-25 23:35, Felix Miata wrote: the internet.
On 2023-04-26 07:14, Darryl Gregorash wrote:
On 2023-04-25 22:49, Felix Miata wrote:
Darryl Gregorash composed on 2023-04-25 17:34 (UTC-0600):
Felix Miata wrote:
I have been following this thread, and I marked that message of yours. I have eth0 and can probably figure out how to write a resolv.conf, but static IP I cannot guarantee. M IP probably should not change so long as I remain on my present ISP node, but if I move it will be subject to change -- so I will need to learn how to set this up with DHCP (IPv4 only, my ISP seems unable to figure out IPv6. I think they're going to try handing out single IPs, like they do with IPv4.)
Gosh. And here I was thinking my ISP couldn't be surpassed dumb regarding IPv6 Oh, Network Manager can also handle fixed IPs. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-26 05:27, Carlos E. R. wrote:
On 2023-04-26 07:14, Darryl Gregorash wrote:
On 2023-04-25 22:49, Felix Miata wrote:
Darryl Gregorash composed on 2023-04-25 17:34 (UTC-0600):
Felix Miata wrote:
I have been following this thread, and I marked that message of yours. I have eth0 and can probably figure out how to write a resolv.conf, but static IP I cannot guarantee. M IP probably should not change so long as I remain on my present ISP node, but if I move it will be subject to change -- so I will need to learn how to set this up with DHCP (IPv4 only, my ISP seems unable to figure out IPv6. I think they're going to try handing out single IPs, like they do with IPv4.)
Gosh. And here I was thinking my ISP couldn't be surpassed dumb regarding IPv6
Oh, Network Manager can also handle fixed IPs.
Perhaps I didn't make myself clear. My IP will probably remain the same so long as I live in this neighbourhood. If I move to a different area, my IP is subject to change. But it is still a "dynamic" IP, with a 24 hour lease period. Yeah, whether or not Network Manager can handle static IPs is not my problem. I am doing some shared computing (think SETI@Home), so I want my network available to the system even if I am not logged in. It was not immediately clear to me how to make NM do that, so it went into the trash, replaced by wicked.
On 2023-04-26 20:05, Darryl Gregorash wrote:
On 2023-04-26 05:27, Carlos E. R. wrote:
On 2023-04-26 07:14, Darryl Gregorash wrote:
On 2023-04-25 22:49, Felix Miata wrote:
Darryl Gregorash composed on 2023-04-25 17:34 (UTC-0600):
Felix Miata wrote:
I have been following this thread, and I marked that message of yours. I have eth0 and can probably figure out how to write a resolv.conf, but static IP I cannot guarantee. M IP probably should not change so long as I remain on my present ISP node, but if I move it will be subject to change -- so I will need to learn how to set this up with DHCP (IPv4 only, my ISP seems unable to figure out IPv6. I think they're going to try handing out single IPs, like they do with IPv4.)
Gosh. And here I was thinking my ISP couldn't be surpassed dumb regarding IPv6
Oh, Network Manager can also handle fixed IPs.
Perhaps I didn't make myself clear. My IP will probably remain the same so long as I live in this neighbourhood. If I move to a different area, my IP is subject to change. But it is still a "dynamic" IP, with a 24 hour lease period.
Yeah, whether or not Network Manager can handle static IPs is not my problem. I am doing some shared computing (think SETI@Home), so I want my network available to the system even if I am not logged in. It was not immediately clear to me how to make NM do that, so it went into the trash, replaced by wicked.
Ah, I understand. What I did in those cases, was tell NM, or the XFCE applet, that I needed that connection to be available for all users. It then asked for root's password. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Wednesday, 26 April 2023 05:49:25 BST Felix Miata wrote:
That needn't stop you from using systemd-networkd. It's pretty well covered here, assuming you're using eth0, static IP, and know how to build resolv.conf: <https://lists.opensuse.org/archives/list/support@lists.opensuse.org/messag e/U5JAS2JURUJ5TNFQHVM6Z6ZGB2ULICEA/>
Therein lies 2 problems for me: * I use a static IP and DHCP on each network interface * I expect there to be tools which configure networks without needing to explicitly rebuild resolv.conf Linux gives great freedom, which I appreciate and I like the fact that I can dive into all sorts of config if I so choose. But I have been doing SUSE for over 20 years now, starting with 6.x [apart from a few years when there was only Tumbleweed] and I think we should be expecting a mainstream distribution to be mature to the degree that it has tools to set up things like networking to the full. Linux should be for everyone, not just hardy fools, although I am happy to be a hardy fool if it makes things more accessible to everyone. Unfortunately, while we have a choice [great] of Wicked and Network Manager, neither of these covers both of my use cases and there is the threat of Wicked being deprecated, despite the proposed default of Network Manager [seemingly] not supporting a basic use case of NFS shares being required prior to the first log in screen. I am prepared to work with this to get Network Manager covering this use case or even to work with Wicked to get it to cover mobile usage with wireless with similar ease to NM and I don't want to succumb to a frustrated rant. As such, I am pleased to hear that there is systemd-networkd, [less so if it is actually part of systemd, because it appears to break the abstraction of systemd, but that's an issue for another day]. But these days, any network management package needs to come with support tools for a full range of use cases. Unfortunately [I haven't followed this subthread too closely], for networkd-systemd we seem to be at the level of looking at the issues of conflict between packages? Obviously, there is benefit in resolving that and it does take us closer to having another network management system for everyone, not just the geeks who tweak. Overall, although systemd-networkd might do what I want, given that Wicked is being deprecated, I think that solving my problem using Network Manager offers a much quicker benefit towards Linux for everyone, given that on the more on topic part of the thread with Andrei Borzenkov's requests for information, it is beginning to look like systemd is not correctly setup to schedule nfs mounts and network startup. so we are in reality not far from having a working system with Network Manager. [And like others here, I have long detested Network Manager because in my case, I couldn't easily configure Static IP plus DHCP] Regards CR
On 2023-04-26 09:48, Charles Rinnoch wrote:
On Wednesday, 26 April 2023 05:49:25 BST Felix Miata wrote:
That needn't stop you from using systemd-networkd. It's pretty well covered here, assuming you're using eth0, static IP, and know how to build resolv.conf: <https://lists.opensuse.org/archives/list/support@lists.opensuse.org/messag e/U5JAS2JURUJ5TNFQHVM6Z6ZGB2ULICEA/>
Therein lies 2 problems for me:
* I use a static IP and DHCP on each network interface
* I expect there to be tools which configure networks without needing to explicitly rebuild resolv.conf
We had a long thread recently on handling that file, if you are interested - huh, the thread was split in four: <https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/XXXQONM27PM42NIYKG4SA5YUSLTOBRM4/> <https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/YEF6MT4EDPAUEVGOYUARQAWSBKUTSTT5/> <https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/WUWQXTCFWBIKYNFRQ7W6SBACYA5EOU4Z/> <https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/PXNC3TO2BWKUMRJG3N46KSGWYIYW2KBH/>
Linux gives great freedom, which I appreciate and I like the fact that I can dive into all sorts of config if I so choose. But I have been doing SUSE for over 20 years now, starting with 6.x [apart from a few years when there was only Tumbleweed] and I think we should be expecting a mainstream distribution to be mature to the degree that it has tools to set up things like networking to the full. Linux should be for everyone, not just hardy fools, although I am happy to be a hardy fool if it makes things more accessible to everyone.
Unfortunately, while we have a choice [great] of Wicked and Network Manager, neither of these covers both of my use cases and there is the threat of Wicked being deprecated, despite the proposed default of Network Manager [seemingly] not supporting a basic use case of NFS shares being required prior to the first log in screen. I am prepared to work with this to get Network Manager covering this use case or even to work with Wicked to get it to cover mobile usage with wireless with similar ease to NM and I don't want to succumb to a frustrated rant.
Another way to solve this is to mount the shares on demand. fstab line:
telcontar.valinor:/nfs_share /mnt/nfs nfs noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=300,_netdev,nfsvers=4 0 0
Then Andrei posted today how to coach NM into doing it "right". -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 4/26/23 09:04, Darryl Gregorash wrote:
On 2023-04-25 15:16, Felix Miata wrote:
Darryl Gregorash composed on 2023-04-25 13:25 (UTC-0600):
<snip> My previous post was from 15.4. TW is on track for retiring wicked, if it hasn't already:
If wicked is gone from 15.5, I shall return, asking about how to replace NetworkManager with networkd :D
SUSE won't make a breaking change like that in a service pack so its safe to presume it will be around for the Leap 15.X series but not anything after. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 4/26/23 01:21, Simon Lees wrote:
If wicked is gone from 15.5, I shall return, asking about how to replace NetworkManager with networkd :D
SUSE won't make a breaking change like that in a service pack so its safe to presume it will be around for the Leap 15.X series but not anything after.
Out of curiosity, why is Wicked being dropped? Will NetworkManager be able to completely replace it? If not, what? I'm thinking about configuring server networking with possibly lots of static interfaces, including bonding and jumbo frames. Regards, Lew
On 26.04.2023 18:59, Lew Wolfgang wrote:
On 4/26/23 01:21, Simon Lees wrote:
If wicked is gone from 15.5, I shall return, asking about how to replace NetworkManager with networkd :D
SUSE won't make a breaking change like that in a service pack so its safe to presume it will be around for the Leap 15.X series but not anything after.
Out of curiosity, why is Wicked being dropped? Will NetworkManager be able to completely replace it?
NetworkManager can do everything wicked did and more.
If not, what? I'm thinking about configuring server networking with possibly lots of static interfaces, including bonding and jumbo frames.
Regards, Lew
On 4/27/23 01:29, Lew Wolfgang wrote:
On 4/26/23 01:21, Simon Lees wrote:
If wicked is gone from 15.5, I shall return, asking about how to replace NetworkManager with networkd :D
SUSE won't make a breaking change like that in a service pack so its safe to presume it will be around for the Leap 15.X series but not anything after.
Out of curiosity, why is Wicked being dropped? Will NetworkManager be able to completely replace it? If not, what? I'm thinking about configuring server networking with possibly lots of static interfaces, including bonding and jumbo frames.
Some history, when systemd was first introduced many people especially on servers were using ifup/down but that didn't integrate with systemd, mainly there was no way to start services once the network was up. NetworkManager was still seen as a very heavy weight solution for this and so Wicked was created. Fast forward 10 years and Networking has got more complex containers have become more popular and in the Linux world outside of SUSE people seem to have generally forgotten there concerns around Network Managers resource usage (It might have got better as well) and are now all using it as the default. Where as SUSE based systems are the only ones using Wicked. So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
On 27.04.2023 05:01, Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
This is default if you using NetworkManager (meaning - you need to explicitly set connection option that restricts connection to specific users). If you are using some GUI to configure NetworkManager and this GUI has different defaults - you need to tell what you are using.
On 2023-04-26 22:03, Andrei Borzenkov wrote:
On 27.04.2023 05:01, Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
This is default if you using NetworkManager (meaning - you need to explicitly set connection option that restricts connection to specific users). If you are using some GUI to configure NetworkManager and this GUI has different defaults - you need to tell what you are using. I use YaST to set things up. I saw nothing in there to tell the network services when to start up. I have never seen such a thing in YaST. Perhaps you could explain why the default when setting up wicked is to set up the network during boot. Why would there be different defaults for wicked and for NM?
On Thu, Apr 27, 2023 at 7:57 AM Darryl Gregorash <raven@accesscomm.ca> wrote:
On 2023-04-26 22:03, Andrei Borzenkov wrote:
On 27.04.2023 05:01, Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
This is default if you using NetworkManager (meaning - you need to explicitly set connection option that restricts connection to specific users). If you are using some GUI to configure NetworkManager and this GUI has different defaults - you need to tell what you are using. I use YaST to set things up.
YaST cannot configure NetworkManager.
On 2023-04-27 00:31, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 7:57 AM Darryl Gregorash <raven@accesscomm.ca> wrote:
I use YaST to set things up.
YaST cannot configure NetworkManager. It certainly gives the option to do so.
On Thursday, 27 April 2023 08:08:28 BST Darryl Gregorash wrote:
On 2023-04-27 00:31, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 7:57 AM Darryl Gregorash <raven@accesscomm.ca> wrote:
I use YaST to set things up.
YaST cannot configure NetworkManager.
It certainly gives the option to do so.
YaST will select between NM and Wicked as the active system, but beyond that, another tool is required, eg nmtui
On 2023-04-27 09:08, Darryl Gregorash wrote:
On 2023-04-27 00:31, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 7:57 AM Darryl Gregorash <raven@accesscomm.ca> wrote:
I use YaST to set things up.
YaST cannot configure NetworkManager. It certainly gives the option to do so.
No, it doesn't. You can choose in YaST between wicked and NM. Once you choose NM, YaST says it can not configure it. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-27 04:20, Carlos E. R. wrote:
On 2023-04-27 09:08, Darryl Gregorash wrote:
On 2023-04-27 00:31, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 7:57 AM Darryl Gregorash <raven@accesscomm.ca> wrote:
I use YaST to set things up.
YaST cannot configure NetworkManager. It certainly gives the option to do so.
No, it doesn't.
You can choose in YaST between wicked and NM. Once you choose NM, YaST says it can not configure it. OK, I paid zero attention to it other than to switch from NM to wicked. Of course, YaST cannot configure firewalld either, so why would I expect it to be able to configure the network?
On 2023-04-27 18:46, Darryl Gregorash wrote:
On 2023-04-27 04:20, Carlos E. R. wrote:
On 2023-04-27 09:08, Darryl Gregorash wrote:
On 2023-04-27 00:31, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 7:57 AM Darryl Gregorash <raven@accesscomm.ca> wrote:
I use YaST to set things up.
YaST cannot configure NetworkManager. It certainly gives the option to do so.
No, it doesn't.
You can choose in YaST between wicked and NM. Once you choose NM, YaST says it can not configure it. OK, I paid zero attention to it other than to switch from NM to wicked. Of course, YaST cannot configure firewalld either, so why would I expect it to be able to configure the network?
Because it has been able to configure the network, for decades. It just can't with network manager. Oh, it does configure firewalld, albeit incompletely. I'm not sure this instant if it configured SuSEfirewall2. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-27 11:56, Carlos E. R. wrote:
On 2023-04-27 18:46, Darryl Gregorash wrote:
On 2023-04-27 04:20, Carlos E. R. wrote:
On 2023-04-27 09:08, Darryl Gregorash wrote:
On 2023-04-27 00:31, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 7:57 AM Darryl Gregorash <raven@accesscomm.ca> wrote:
I use YaST to set things up.
YaST cannot configure NetworkManager. It certainly gives the option to do so.
No, it doesn't.
You can choose in YaST between wicked and NM. Once you choose NM, YaST says it can not configure it. OK, I paid zero attention to it other than to switch from NM to wicked. Of course, YaST cannot configure firewalld either, so why would I expect it to be able to configure the network?
Because it has been able to configure the network, for decades. It just can't with network manager.
Yeah, I think I figured that out, Carlos, way back in the 1990s when I first installed SuSE 6.(something) after IBM dumped OS/2 Warp. And if I hadn't back then, then surely I had it figured out when I dumped NM and fully configured wicked, in YaST.
Oh, it does configure firewalld, albeit incompletely. I'm not sure this instant if it configured SuSEfirewall2.
"It does configure firewalld, albeit incompletely." If it cannot _completely_ configure something, then it cannot be said to configure it at all -- configuration implies that, once you are done, you are good to go. At least, that's the meaning of "configuration" in my books.
* Darryl Gregorash <raven@accesscomm.ca> [04-27-23 14:44]:
On 2023-04-27 11:56, Carlos E. R. wrote: ...
Because it has been able to configure the network, for decades. It just can't with network manager.
Yeah, I think I figured that out, Carlos, way back in the 1990s when I first installed SuSE 6.(something) after IBM dumped OS/2 Warp. And if I hadn't back then, then surely I had it figured out when I dumped NM and fully configured wicked, in YaST.
Oh, it does configure firewalld, albeit incompletely. I'm not sure this instant if it configured SuSEfirewall2.
"It does configure firewalld, albeit incompletely." If it cannot _completely_ configure something, then it cannot be said to configure it at all -- configuration implies that, once you are done, you are good to go. At least, that's the meaning of "configuration" in my books.
well, you are rather demanding there. Always there will be edge cases that are not determined worth a programmer's time will not be provided for in many gui configuration apps including yast. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 2023-04-27 13:12, Patrick Shanahan wrote:
* Darryl Gregorash <raven@accesscomm.ca> [04-27-23 14:44]:
On 2023-04-27 11:56, Carlos E. R. wrote: ...
Because it has been able to configure the network, for decades. It just can't with network manager.
Yeah, I think I figured that out, Carlos, way back in the 1990s when I first installed SuSE 6.(something) after IBM dumped OS/2 Warp. And if I hadn't back then, then surely I had it figured out when I dumped NM and fully configured wicked, in YaST.
Oh, it does configure firewalld, albeit incompletely. I'm not sure this instant if it configured SuSEfirewall2.
"It does configure firewalld, albeit incompletely." If it cannot _completely_ configure something, then it cannot be said to configure it at all -- configuration implies that, once you are done, you are good to go. At least, that's the meaning of "configuration" in my books.
well, you are rather demanding there. Always there will be edge cases that are not determined worth a programmer's time will not be provided for in many gui configuration apps including yast.
And here I thought that a system configuration/etc tool would not be considered complete unless it included the capability to fully configure a network. That task hardly seems like an "edge case" to me.
On 4/27/23 11:31, Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
I already documented what I do here https://lists.opensuse.org/archives/list/support@lists.opensuse.org/message/... -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Thu, Apr 27, 2023 at 8:54 AM Simon Lees <sflees@suse.de> wrote:
On 4/27/23 11:31, Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
I already documented what I do here https://lists.opensuse.org/archives/list/support@lists.opensuse.org/message/...
This is unrelated and does not answer the question. At least the KDE applet defaults to user-specific connections. Also, it is possible that desktop applets default to storing connection secrets (wireless in the first place) in the user secrets store (GNOME keyring, KWallet, whatever). Which of course means these secrets are not available until user logged in. But all of this is the specific behavior of specific frontend that configures NetworkManager connection profile and can be changed. NetworkManager itself has no problem activating any connection at boot as long as all necessary information is available at this point. NetworkManager does not require any GUI to be used and can be configured by editing connection profile just like wicked can be configured by editing ifcfg files.
On 4/27/23 16:09, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 8:54 AM Simon Lees <sflees@suse.de> wrote:
On 4/27/23 11:31, Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
I already documented what I do here https://lists.opensuse.org/archives/list/support@lists.opensuse.org/message/...
This is unrelated and does not answer the question.
At least the KDE applet defaults to user-specific connections. Also, it is possible that desktop applets default to storing connection secrets (wireless in the first place) in the user secrets store (GNOME keyring, KWallet, whatever). Which of course means these secrets are not available until user logged in. But all of this is the specific behavior of specific frontend that configures NetworkManager connection profile and can be changed. NetworkManager itself has no problem activating any connection at boot as long as all necessary information is available at this point.
NetworkManager does not require any GUI to be used and can be configured by editing connection profile just like wicked can be configured by editing ifcfg files.
Ahh, but if you read correctly you'll notice that I did mention running nmtui as root which will always do this for all users and its simpler then editing any config. But for what its worth the Gnome Configuration Dialog that is also used by xfce and enlightenment gives you the option of user or system, and with the system config that I always use i've never had issues with it storing the secret in a keyring that needs to be unlocked by a user. So maybe its just KDE that really needs to do better here. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Thu, Apr 27, 2023 at 10:18 AM Simon Lees <sflees@suse.de> wrote:
the Gnome Configuration Dialog that is also used by xfce and enlightenment
GNOME has its own GUI provided by GNOME Shell. At least XFCE is using nm-connection-editor (and corresponding nm-applet) which is not even installed in openSUSE by default when you select GNOME desktop. nm-connection-editor may be seen as the closest thing to "native GUI", still it is a separate project which is not part of NetworkManager itself.
On Thu, Apr 27, 2023 at 10:28 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Thu, Apr 27, 2023 at 10:18 AM Simon Lees <sflees@suse.de> wrote:
the Gnome Configuration Dialog that is also used by xfce and enlightenment
GNOME has its own GUI provided by GNOME Shell. At least XFCE is using nm-connection-editor (and corresponding nm-applet) which is not even installed in openSUSE by default when you select GNOME desktop.
Yes. On Tumbleweed andrei@tumbleweed:~> zypper se --requires-pkg NetworkManager-applet Loading repository data... Reading installed packages... S | Name | Summary | Type --+----------------------------+--------------------------------------------------+-------- | budgie-desktop | GTK3 Desktop Environment | package | cinnamon | GNU/Linux Desktop featuring a traditional layout | package | NetworkManager-applet-lang | Translations for package NetworkManager-applet | package andrei@tumbleweed:~> zypper se --recommends-pkg NetworkManager-applet Loading repository data... Reading installed packages... S | Name | Summary | Type --+--------------------------+----------------------------------+-------- | nmcli-dmenu | Control NetworkManager via dmenu | package | patterns-lxde-lxde | LXDE Desktop Environment | package | patterns-lxqt-lxqt | LXQt Desktop Environment | package | patterns-mate-mate_basis | MATE Base System | package | patterns-xfce-xfce_basis | XFCE Base System | package andrei@tumbleweed:~> Enlightenment does not recommend (nor require) NM applet or connection editor nor NetworkManager itself. Installing enlightenment pattern does not install anything NetworkManager related contrary to installing xfce pattern.
On 4/28/23 17:29, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 10:28 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Thu, Apr 27, 2023 at 10:18 AM Simon Lees <sflees@suse.de> wrote:
the Gnome Configuration Dialog that is also used by xfce and enlightenment
GNOME has its own GUI provided by GNOME Shell. At least XFCE is using nm-connection-editor (and corresponding nm-applet) which is not even installed in openSUSE by default when you select GNOME desktop.
Yes. On Tumbleweed
andrei@tumbleweed:~> zypper se --requires-pkg NetworkManager-applet Loading repository data... Reading installed packages...
S | Name | Summary | Type --+----------------------------+--------------------------------------------------+-------- | budgie-desktop | GTK3 Desktop Environment | package | cinnamon | GNU/Linux Desktop featuring a traditional layout | package | NetworkManager-applet-lang | Translations for package NetworkManager-applet | package andrei@tumbleweed:~> zypper se --recommends-pkg NetworkManager-applet Loading repository data... Reading installed packages...
S | Name | Summary | Type --+--------------------------+----------------------------------+-------- | nmcli-dmenu | Control NetworkManager via dmenu | package | patterns-lxde-lxde | LXDE Desktop Environment | package | patterns-lxqt-lxqt | LXQt Desktop Environment | package | patterns-mate-mate_basis | MATE Base System | package | patterns-xfce-xfce_basis | XFCE Base System | package andrei@tumbleweed:~>
Enlightenment does not recommend (nor require) NM applet or connection editor nor NetworkManager itself. Installing enlightenment pattern does not install anything NetworkManager related contrary to installing xfce pattern.
The Enlightenment package recommends "NetworkManager-appindicator" Which installs "NetworkManager-applet" there was a name change at some point, but its certainly part of the default install. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 27.04.2023 10:18, Simon Lees wrote:
On 4/27/23 16:09, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 8:54 AM Simon Lees <sflees@suse.de> wrote:
On 4/27/23 11:31, Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
I already documented what I do here https://lists.opensuse.org/archives/list/support@lists.opensuse.org/message/...
This is unrelated and does not answer the question.
At least the KDE applet defaults to user-specific connections. Also, it is possible that desktop applets default to storing connection secrets (wireless in the first place) in the user secrets store (GNOME keyring, KWallet, whatever). Which of course means these secrets are not available until user logged in. But all of this is the specific behavior of specific frontend that configures NetworkManager connection profile and can be changed. NetworkManager itself has no problem activating any connection at boot as long as all necessary information is available at this point.
NetworkManager does not require any GUI to be used and can be configured by editing connection profile just like wicked can be configured by editing ifcfg files.
Ahh, but if you read correctly you'll notice that I did mention running nmtui as root which will always do this for all users and its simpler then editing any config. But for what its worth the Gnome Configuration Dialog that is also used by xfce and enlightenment gives you the option of user or system, and with the system config that I always use i've never had issues with it storing the secret in a keyring that needs to be unlocked by a user. So maybe its just KDE that really needs to do better here.
I tested several NM frontends. nmtui defaults to "Available for all users" and does not have option to store secrets per-user nm-connection-editor defaults to "Available to all users" and "Save secrets for all users" GNOME Shell implicitly creates wireless connection when you select visible AP or try hidden AP, the only input is SSID and password. It defaults to "Available to all users" and "Save secrets for all users" KDE Plasma applet defaults to "Available to the current user" and "Save secrets for the current user" If connection is restricted to specific user, NetworkManager does not activate it on boot until user logged in (I was not aware that NM does it automatically. It may explain some issues users had as it could well race with desktop for secrets agent). So of all frontends Plasma applet appears to be the only one defaulting to user specific connection profiles.
On 2023-04-27 20:24, Andrei Borzenkov wrote:
On 27.04.2023 10:18, Simon Lees wrote:
On 4/27/23 16:09, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 8:54 AM Simon Lees <sflees@suse.de> wrote:
On 4/27/23 11:31, Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
...
I tested several NM frontends.
nmtui defaults to "Available for all users" and does not have option to store secrets per-user
nm-connection-editor defaults to "Available to all users" and "Save secrets for all users"
GNOME Shell implicitly creates wireless connection when you select visible AP or try hidden AP, the only input is SSID and password. It defaults to "Available to all users" and "Save secrets for all users"
KDE Plasma applet defaults to "Available to the current user" and "Save secrets for the current user"
If connection is restricted to specific user, NetworkManager does not activate it on boot until user logged in (I was not aware that NM does it automatically. It may explain some issues users had as it could well race with desktop for secrets agent).
So of all frontends Plasma applet appears to be the only one defaulting to user specific connection profiles.
You missed XFCE. AFAIK, it defaults to the current user. There is a tick box for make available for all users, and then it asks for the root password. I just tried a new connection in 15.5. The resulting file is: /etc/NetworkManager/system-connections/connectionname.nmconnection [connection] id=connectionname uuid=... type=wifi interface-name=wlan0 permissions=user:cer:; [wifi] mode=infrastructure ssid=connectionname [wifi-security] auth-alg=open key-mgmt=wpa-psk psk=passwordintheclear [ipv4] method=auto [ipv6] addr-gen-mode=stable-privacy method=auto [proxy] The file is owned by root, but I change the configuration as "me". It did not ask my password to delete it. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 27.04.2023 23:24, Carlos E. R. wrote:
On 2023-04-27 20:24, Andrei Borzenkov wrote:
On 27.04.2023 10:18, Simon Lees wrote:
On 4/27/23 16:09, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 8:54 AM Simon Lees <sflees@suse.de> wrote:
On 4/27/23 11:31, Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
...
I tested several NM frontends.
nmtui defaults to "Available for all users" and does not have option to store secrets per-user
nm-connection-editor defaults to "Available to all users" and "Save secrets for all users"
GNOME Shell implicitly creates wireless connection when you select visible AP or try hidden AP, the only input is SSID and password. It defaults to "Available to all users" and "Save secrets for all users"
KDE Plasma applet defaults to "Available to the current user" and "Save secrets for the current user"
If connection is restricted to specific user, NetworkManager does not activate it on boot until user logged in (I was not aware that NM does it automatically. It may explain some issues users had as it could well race with desktop for secrets agent).
So of all frontends Plasma applet appears to be the only one defaulting to user specific connection profiles.
You missed XFCE.
My Leap 15.4 with Xfce is using nm-connection-editor.
On 2023-04-27 08:39, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 8:54 AM Simon Lees <sflees@suse.de> wrote:
On 4/27/23 11:31, Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
I already documented what I do here https://lists.opensuse.org/archives/list/support@lists.opensuse.org/message/...
This is unrelated and does not answer the question.
At least the KDE applet defaults to user-specific connections. Also, it is possible that desktop applets default to storing connection secrets (wireless in the first place) in the user secrets store (GNOME keyring, KWallet, whatever). Which of course means these secrets are not available until user logged in. But all of this is the specific behavior of specific frontend that configures NetworkManager connection profile and can be changed. NetworkManager itself has no problem activating any connection at boot as long as all necessary information is available at this point.
NetworkManager does not require any GUI to be used and can be configured by editing connection profile just like wicked can be configured by editing ifcfg files.
Then YaST could easily generate those files. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Thu, Apr 27, 2023 at 1:27 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2023-04-27 08:39, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 8:54 AM Simon Lees <sflees@suse.de> wrote:
On 4/27/23 11:31, Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
I already documented what I do here https://lists.opensuse.org/archives/list/support@lists.opensuse.org/message/...
This is unrelated and does not answer the question.
At least the KDE applet defaults to user-specific connections. Also, it is possible that desktop applets default to storing connection secrets (wireless in the first place) in the user secrets store (GNOME keyring, KWallet, whatever). Which of course means these secrets are not available until user logged in. But all of this is the specific behavior of specific frontend that configures NetworkManager connection profile and can be changed. NetworkManager itself has no problem activating any connection at boot as long as all necessary information is available at this point.
NetworkManager does not require any GUI to be used and can be configured by editing connection profile just like wicked can be configured by editing ifcfg files.
Then YaST could easily generate those files.
Installer does generate these files (it creates configuration both for wicked and NetworkManager).
On 2023-04-27 05:32:27 Andrei Borzenkov wrote:
|On Thu, Apr 27, 2023 at 1:27 PM Carlos E. R. | |<robin.listas@telefonica.net> wrote: |> On 2023-04-27 08:39, Andrei Borzenkov wrote: |> > On Thu, Apr 27, 2023 at 8:54 AM Simon Lees <sflees@suse.de> wrote: |> >> On 4/27/23 11:31, Darryl Gregorash wrote: |> >>> On 2023-04-26 19:44, Simon Lees wrote: |> >>>> So dropping Wicked for network manager is just part of SUSE trying |> >>>> to remove unneeded differences between SUSE and other Enterprise |> >>>> distros. |> >>> |> >>> Perhaps you can point me to some useful documentation on how to get |> >>> NM up during boot, rather than when I log in as a user -- preferably |> >>> something that can be fully set up during the upgrade process. |> >> |> >> I already documented what I do here |> >> https://lists.opensuse.org/archives/list/support@lists.opensuse.org/m |> >>essage/LMCTTXZP74K32YSVH47VVJPDQHB2UPPM/ |> > |> > This is unrelated and does not answer the question. |> > |> > At least the KDE applet defaults to user-specific connections. Also, |> > it is possible that desktop applets default to storing connection |> > secrets (wireless in the first place) in the user secrets store (GNOME |> > keyring, KWallet, whatever). Which of course means these secrets are |> > not available until user logged in. But all of this is the specific |> > behavior of specific frontend that configures NetworkManager |> > connection profile and can be changed. NetworkManager itself has no |> > problem activating any connection at boot as long as all necessary |> > information is available at this point. |> > |> > NetworkManager does not require any GUI to be used and can be |> > configured by editing connection profile just like wicked can be |> > configured by editing ifcfg files. |> |> Then YaST could easily generate those files. | |Installer does generate these files (it creates configuration both for |wicked and NetworkManager).
I suppose the YaST maintainers think, "Why reinvent a configuration tool that already exists?" but it would be nice if it at least mentioned that the NetworkManager configuration might need adjusting. I don't see any way to access the Leap 15.5 documentation from openSUSE's web pages. It would be interesting to see what it says about things like storing NM secrets, etc.; 15.4 doc says they are stored in Gnome keyring (even on headless machines? doesn't say), but I don't use Gnome. Does that mean that I will have to enter this info at every boot? Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 (x86_64) Desktop: Trinity R14.0.13
On 2023-04-26 23:54, Simon Lees wrote:
On 4/27/23 11:31, Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
I already documented what I do here https://lists.opensuse.org/archives/list/support@lists.opensuse.org/message/...
I was hoping to see something a tad more complete than a mere mention of nmtui, "... just run nmtui as root from the command line...."
On 2023-04-27 18:50, Darryl Gregorash wrote:
On 2023-04-26 23:54, Simon Lees wrote:
On 4/27/23 11:31, Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
I already documented what I do here https://lists.opensuse.org/archives/list/support@lists.opensuse.org/message/...
I was hoping to see something a tad more complete than a mere mention of nmtui, "... just run nmtui as root from the command line...."
Just try it — it is not the usual command you run in the command line :-) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-27 00:54:21 Simon Lees wrote:
|On 4/27/23 11:31, Darryl Gregorash wrote: |> On 2023-04-26 19:44, Simon Lees wrote: |>> So dropping Wicked for network manager is just part of SUSE trying to |>> remove unneeded differences between SUSE and other Enterprise distros. |> |> Perhaps you can point me to some useful documentation on how to get NM |> up during boot, rather than when I log in as a user -- preferably |> something that can be fully set up during the upgrade process. | |I already documented what I do here |https://lists.opensuse.org/archives/list/support@lists.opensuse.org/messag |e/LMCTTXZP74K32YSVH47VVJPDQHB2UPPM/
I decided to have a look in the Leap documentation to see what it says about NetworkManager. (I hadn't bothered to do so before because wicked "just works".) I was struck by several oddities: 1. 13.4.1.1 Configuring global networking options in Chapter 13. Basic Networking defers discussion of NetworkManager to Chapter 28 in Part IV (Mobile Computers), and the rest of Chapter 13 seems to assume wicked will be used, since all of the configuration directions seem to be directed at YaST. 2. There seems to be an assumption that Gnome will be installed. Just about everything in Chapter 28 relies on the availability of Gnome resources, e.g. Gnome keyring, implying that Gnome must be installed (even on headless machines?). I would expect it to use desktop-agnostic examples like nmtui. Maybe the sections on network management have been rewritten for Leap 15.5, but there seems to be no place to go to download its manuals; the most recent manuals in https://doc.opensuse.org/ are for Leap 15.4. (It would be nice to be able to see the documentation for a release before it goes GA. Maybe an additional tab in https://get.opensuse.org/leap/15.5/ could be added so that those participating in Beta testing could download the documentation?) Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 (x86_64)
On 4/28/23 07:10, J Leslie Turriff wrote:
On 2023-04-27 00:54:21 Simon Lees wrote:
|On 4/27/23 11:31, Darryl Gregorash wrote: |> On 2023-04-26 19:44, Simon Lees wrote: |>> So dropping Wicked for network manager is just part of SUSE trying to |>> remove unneeded differences between SUSE and other Enterprise distros. |> |> Perhaps you can point me to some useful documentation on how to get NM |> up during boot, rather than when I log in as a user -- preferably |> something that can be fully set up during the upgrade process. | |I already documented what I do here |https://lists.opensuse.org/archives/list/support@lists.opensuse.org/messag |e/LMCTTXZP74K32YSVH47VVJPDQHB2UPPM/
I decided to have a look in the Leap documentation to see what it says about NetworkManager. (I hadn't bothered to do so before because wicked "just works".)
I was struck by several oddities: 1. 13.4.1.1 Configuring global networking options in Chapter 13. Basic Networking defers discussion of NetworkManager to Chapter 28 in Part IV (Mobile Computers), and the rest of Chapter 13 seems to assume wicked will be used, since all of the configuration directions seem to be directed at YaST. 2. There seems to be an assumption that Gnome will be installed. Just about everything in Chapter 28 relies on the availability of Gnome resources, e.g. Gnome keyring, implying that Gnome must be installed (even on headless machines?). I would expect it to use desktop-agnostic examples like nmtui.
Maybe the sections on network management have been rewritten for Leap 15.5, but there seems to be no place to go to download its manuals; the most recent manuals in https://doc.opensuse.org/ are for Leap 15.4. (It would be nice to be able to see the documentation for a release before it goes GA. Maybe an additional tab in https://get.opensuse.org/leap/15.5/ could be added so that those participating in Beta testing could download the documentation?)
I doubt it will have changed as wicked is not going away in 15.5 -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 2023-04-27 23:40, J Leslie Turriff wrote:
On 2023-04-27 00:54:21 Simon Lees wrote:
|On 4/27/23 11:31, Darryl Gregorash wrote: |> On 2023-04-26 19:44, Simon Lees wrote: |>> So dropping Wicked for network manager is just part of SUSE trying to |>> remove unneeded differences between SUSE and other Enterprise distros. |> |> Perhaps you can point me to some useful documentation on how to get NM |> up during boot, rather than when I log in as a user -- preferably |> something that can be fully set up during the upgrade process. | |I already documented what I do here |https://lists.opensuse.org/archives/list/support@lists.opensuse.org/messag |e/LMCTTXZP74K32YSVH47VVJPDQHB2UPPM/
I decided to have a look in the Leap documentation to see what it says about NetworkManager. (I hadn't bothered to do so before because wicked "just works".)
I was struck by several oddities: 1. 13.4.1.1 Configuring global networking options in Chapter 13. Basic Networking defers discussion of NetworkManager to Chapter 28 in Part IV (Mobile Computers), and the rest of Chapter 13 seems to assume wicked will be used, since all of the configuration directions seem to be directed at YaST. 2. There seems to be an assumption that Gnome will be installed. Just about everything in Chapter 28 relies on the availability of Gnome resources, e.g. Gnome keyring, implying that Gnome must be installed (even on headless machines?). I would expect it to use desktop-agnostic examples like nmtui.
It is written, I believe, for SLES, which doesn't have KDE. There may be a version of the book modified for openSUSE; but not that much.
Maybe the sections on network management have been rewritten for Leap 15.5, but there seems to be no place to go to download its manuals; the most recent manuals in https://doc.opensuse.org/ are for Leap 15.4. (It would be nice to be able to see the documentation for a release before it goes GA. Maybe an additional tab in https://get.opensuse.org/leap/15.5/ could be added so that those participating in Beta testing could download the documentation?)
No, the book is developed when the writers see the new release and learn its differences. They don't have prior knowledge. Same as us. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 4/28/23 19:47, Carlos E. R. wrote:
On 2023-04-27 23:40, J Leslie Turriff wrote:
On 2023-04-27 00:54:21 Simon Lees wrote:
|On 4/27/23 11:31, Darryl Gregorash wrote: |> On 2023-04-26 19:44, Simon Lees wrote: |>> So dropping Wicked for network manager is just part of SUSE trying to |>> remove unneeded differences between SUSE and other Enterprise distros. |> |> Perhaps you can point me to some useful documentation on how to get NM |> up during boot, rather than when I log in as a user -- preferably |> something that can be fully set up during the upgrade process. | |I already documented what I do here |https://lists.opensuse.org/archives/list/support@lists.opensuse.org/messag |e/LMCTTXZP74K32YSVH47VVJPDQHB2UPPM/
I decided to have a look in the Leap documentation to see what it says about NetworkManager. (I hadn't bothered to do so before because wicked "just works".)
I was struck by several oddities: 1. 13.4.1.1 Configuring global networking options in Chapter 13. Basic Networking defers discussion of NetworkManager to Chapter 28 in Part IV (Mobile Computers), and the rest of Chapter 13 seems to assume wicked will be used, since all of the configuration directions seem to be directed at YaST. 2. There seems to be an assumption that Gnome will be installed. Just about everything in Chapter 28 relies on the availability of Gnome resources, e.g. Gnome keyring, implying that Gnome must be installed (even on headless machines?). I would expect it to use desktop-agnostic examples like nmtui.
It is written, I believe, for SLES, which doesn't have KDE. There may be a version of the book modified for openSUSE; but not that much.
Maybe the sections on network management have been rewritten for Leap 15.5, but there seems to be no place to go to download its manuals; the most recent manuals in https://doc.opensuse.org/ are for Leap 15.4. (It would be nice to be able to see the documentation for a release before it goes GA. Maybe an additional tab in https://get.opensuse.org/leap/15.5/ could be added so that those participating in Beta testing could download the documentation?)
No, the book is developed when the writers see the new release and learn its differences. They don't have prior knowledge. Same as us.
No that documentation is written by the SUSE doc team, who very much have early access and notice (They are already working on all the changes for ALP). There won't be major changes for 15.5 so I doubt there will be significant changes to the docs. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Thursday, 27 April 2023 03:01:55 BST Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
I am configuring NM with nmtui which is a curses type application. It hardly needs documentation, except for the fact of its existence, which is not that well advertised. I have [now] successfully used it to configure wireless, to operate portably on several networks and also wired with fixed IP and DHCP on the one interface. So that covers most ordinary uses short of routing through a machine. CR
On Thursday, 27 April 2023 4:36:30 PM ACST Charles Rinnoch wrote:
On Thursday, 27 April 2023 03:01:55 BST Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
I am configuring NM with nmtui which is a curses type application. It hardly needs documentation, except for the fact of its existence, which is not that well advertised.
I have [now] successfully used it to configure wireless, to operate portably on several networks and also wired with fixed IP and DHCP on the one interface. So that covers most ordinary uses short of routing through a machine.
CR
Hmmm... Root@mako ~ # nmtui If 'nmtui' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf nmtui root@mako ~ # cnf nmtui nmtui: searching ... Warning: incomplete repos found but could not refresh - try to refresh manually, e.g. with 'zypper refresh'. nmtui: command not found root@mako ~ # zypper se NetworkManager Loading repository data... Reading installed packages... [...] | NetworkManager-tui | NetworkManager curses-based UI | package Not very helpful when cnf can't tell me that nmtui should be found in package NetworkManager-tui. Is that worth a bug report (TW btw). Regards, Rodney. -- ================================================================================================================== Rodney Baker rodney.baker@iinet.net.au ==================================================================================================================
On Fri, Apr 28, 2023 at 2:30 PM Rodney Baker <rodney.baker@iinet.net.au> wrote:
On Thursday, 27 April 2023 4:36:30 PM ACST Charles Rinnoch wrote:
On Thursday, 27 April 2023 03:01:55 BST Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
I am configuring NM with nmtui which is a curses type application. It hardly needs documentation, except for the fact of its existence, which is not that well advertised.
I have [now] successfully used it to configure wireless, to operate portably on several networks and also wired with fixed IP and DHCP on the one interface. So that covers most ordinary uses short of routing through a machine.
CR
Hmmm...
Root@mako ~ # nmtui If 'nmtui' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf nmtui root@mako ~ # cnf nmtui nmtui: searching ... Warning: incomplete repos found but could not refresh - try to refresh manually, e.g. with 'zypper refresh'.
Did you do as suggested?
nmtui: command not found
root@mako ~ # zypper se NetworkManager Loading repository data... Reading installed packages...
[...]
| NetworkManager-tui | NetworkManager curses-based UI | package
Not very helpful when cnf can't tell me that nmtui should be found in package NetworkManager-tui.
Is that worth a bug report (TW btw).
andrei@tumbleweed:~> cnf nmtui The program 'nmtui' can be found in the following package: * NetworkManager-tui [ path: /usr/bin/nmtui, repository: zypp (repo-oss) ] Try installing with: sudo zypper install NetworkManager-tui andrei@tumbleweed:~>
On Fri, Apr 28, 2023 at 2:30 PM Rodney Baker <rodney.baker@iinet.net.au> wrote:
On Thursday, 27 April 2023 4:36:30 PM ACST Charles Rinnoch wrote:
On Thursday, 27 April 2023 03:01:55 BST Darryl Gregorash wrote:
On 2023-04-26 19:44, Simon Lees wrote:
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
Perhaps you can point me to some useful documentation on how to get NM up during boot, rather than when I log in as a user -- preferably something that can be fully set up during the upgrade process.
I am configuring NM with nmtui which is a curses type application. It hardly needs documentation, except for the fact of its existence, which is not that well advertised.
I have [now] successfully used it to configure wireless, to operate portably on several networks and also wired with fixed IP and DHCP on the one interface. So that covers most ordinary uses short of routing through a machine.
CR
Hmmm...
Root@mako ~ # nmtui
If 'nmtui' is not a typo you can use command-not-found to lookup the
On Friday, 28 April 2023 9:30:44 PM ACST Andrei Borzenkov wrote: package that contains it, like this:
cnf nmtui
root@mako ~ # cnf nmtui nmtui: searching ... Warning: incomplete repos found but could not refresh - try to refresh manually, e.g. with 'zypper refresh'.
Did you do as suggested?
Yes, of course. In fact, I'd just done a zypper dup and all repos were/are up to date. Even after a zypper ref I get the same message about "incomplete repos found". I have some disabled repos in the list, so that may be the cause. I'll remove them and try again... Nope - still the same.
nmtui: command not found
root@mako ~ # zypper se NetworkManager Loading repository data... Reading installed packages...
[...]
| NetworkManager-tui | NetworkManager curses-based UI | | package> Not very helpful when cnf can't tell me that nmtui should be found in package NetworkManager-tui.
Is that worth a bug report (TW btw).
andrei@tumbleweed:~> cnf nmtui
The program 'nmtui' can be found in the following package: * NetworkManager-tui [ path: /usr/bin/nmtui, repository: zypp (repo-oss) ]
Try installing with: sudo zypper install NetworkManager-tui
andrei@tumbleweed:~>
That's weird - works for you but not for me. Regardless of what I've tried, same error every time. Oh well, looks like it's only broken for me, so no bug report needed. Thanks for checking. -- ================================================================================================================== Rodney Baker rodney.baker@iinet.net.au ==================================================================================================================
On 2023-04-27 03:44, Simon Lees wrote:
On 4/27/23 01:29, Lew Wolfgang wrote:
On 4/26/23 01:21, Simon Lees wrote:
If wicked is gone from 15.5, I shall return, asking about how to replace NetworkManager with networkd :D
Out of curiosity, why is Wicked being dropped? Will NetworkManager be able to completely replace it? If not, what? I'm thinking about configuring server networking with possibly lots of static interfaces, including bonding and jumbo frames.
Some history, when systemd was first introduced many people especially on servers were using ifup/down but that didn't integrate with systemd, mainly there was no way to start services once the network was up. NetworkManager was still seen as a very heavy weight solution for this and so Wicked was created.
Fast forward 10 years and Networking has got more complex containers have become more popular and in the Linux world outside of SUSE people seem to have generally forgotten there concerns around Network Managers resource usage (It might have got better as well) and are now all using it as the default. Where as SUSE based systems are the only ones using Wicked.
So dropping Wicked for network manager is just part of SUSE trying to remove unneeded differences between SUSE and other Enterprise distros.
There are somethings that YaST does that NM doesn't. For example, set up the machine name (and possibly domain name). Perhaps YaST should be improved to handle Network Manager. It is a pain to see YaST wither and die slowly. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-27 12:43, Andrei Borzenkov wrote:
On Thu, Apr 27, 2023 at 1:23 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
There are somethings that YaST does that NM doesn't.
How is it related to "wicked vs. NetworkMananger"? wicked is not YaST.
AFAIK, YaST configures wicked. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
W dniu 24.04.2023 o 13:05, Charles Rinnoch pisze: it appears that Network
Manager is more a per user subsystem for which you need to log in in order to get the connections you want.
It appears like that, because by default connections are limited to users that create them. But you can select an option "All users may connect to this network" (it will ask you for root password) and it should autoconnect without logging in.
On 24.04.2023 17:47, Adam Mizerski wrote:
W dniu 24.04.2023 o 13:05, Charles Rinnoch pisze: it appears that Network
Manager is more a per user subsystem for which you need to log in in order to get the connections you want.
It appears like that, because by default connections are limited to users that create them.
You are talking about KDE Plasma applet, not about NetworkManager.
On 2023-04-24 19:01, Andrei Borzenkov wrote:
On 24.04.2023 17:47, Adam Mizerski wrote:
W dniu 24.04.2023 o 13:05, Charles Rinnoch pisze: it appears that Network
Manager is more a per user subsystem for which you need to log in in order to get the connections you want.
It appears like that, because by default connections are limited to users that create them.
You are talking about KDE Plasma applet, not about NetworkManager.
I believe the NM applet in XFCE does the same. By default new connections belong to the user and don't start till the user logs in. But I have not verified recently when the connection is done. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 24.04.2023 22:08, Carlos E. R. wrote:
On 2023-04-24 19:01, Andrei Borzenkov wrote:
On 24.04.2023 17:47, Adam Mizerski wrote:
W dniu 24.04.2023 o 13:05, Charles Rinnoch pisze: it appears that Network
Manager is more a per user subsystem for which you need to log in in order to get the connections you want.
It appears like that, because by default connections are limited to users that create them.
You are talking about KDE Plasma applet, not about NetworkManager.
I believe the NM applet in XFCE does the same.
No, it defaults to system connections (All users may connect to this network), at least when you create new connection. Of course we may be having different applets ... in any case - everyone hopelessly confuses NetworkManager and GUI used to configure NetworkManager. NetworkManager is a server which does exactly what connection definition contains. Whether some GUI used to configure it defaults to some values for some settings is the feature of this GUI, not of the NetworkManager.
By default new connections belong to the user and don't start till the user logs in. But I have not verified recently when the connection is done.
On 2023-04-24 23:24:37 Andrei Borzenkov wrote:
|On 24.04.2023 22:08, Carlos E. R. wrote: |> On 2023-04-24 19:01, Andrei Borzenkov wrote: |>> On 24.04.2023 17:47, Adam Mizerski wrote: |>>> W dniu 24.04.2023 o 13:05, Charles Rinnoch pisze: |>>> it appears that Network |>>> |>>>> Manager is more a per user subsystem for which you need to log in in |>>>> order to |>>>> get the connections you want. |>>> |>>> It appears like that, because by default connections are limited to |>>> users that create them. |>> |>> You are talking about KDE Plasma applet, not about NetworkManager. |> |> I believe the NM applet in XFCE does the same. | |No, it defaults to system connections (All users may connect to this |network), at least when you create new connection. Of course we may be |having different applets ... | |in any case - everyone hopelessly confuses NetworkManager and GUI used |to configure NetworkManager. NetworkManager is a server which does |exactly what connection definition contains. Whether some GUI used to |configure it defaults to some values for some settings is the feature of |this GUI, not of the NetworkManager. | |> By default new |> connections belong to the user and don't start till the user logs in. |> But I have not verified recently when the connection is done.
See, this is why I quickly abandoned use of Network Manager on my desktop machine: it's too confusing. Wicked (and its predecessor) just works, but Network Manager always seemed to be a sort of on-again, off-again thing that dropped the connection whenever I switched between accounts, etc. I'm really sorry to hear that Wicked has been deprecated. Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 (x86_64)
On Tuesday, 25 April 2023 08:00:29 BST J Leslie Turriff wrote:
See, this is why I quickly abandoned use of Network Manager on my
desktop
machine: it's too confusing. Wicked (and its predecessor) just works, but Network Manager always seemed to be a sort of on-again, off-again thing that dropped the connection whenever I switched between accounts, etc. I'm really sorry to hear that Wicked has been deprecated.
Leslie
I'm sorry too that Wicked is being deprecated. Like you, I find it just works for my desktop fixed network. But Network Manager has shown itself to work better for the mobile use case, connecting ad-hoc into wifi. Wicked was better for DHCP and fixed IP on the same network interface. But the tools to do that for NM are now readily available, eg nmtui. At the base level, it seems to me that there is little to choose between them both - either can probably create any type of connection you want. I have not had problems with NM dropping, but I have had and still have problems setting up the network I want for my desktop use case and Wicked does not do my mobile networking use case so nimbly. The real problem seems to be that neither has the full set of support tools to cover all use cases. Regards CR
On 4/25/23 16:30, J Leslie Turriff wrote:
On 2023-04-24 23:24:37 Andrei Borzenkov wrote:
|On 24.04.2023 22:08, Carlos E. R. wrote: |> On 2023-04-24 19:01, Andrei Borzenkov wrote: |>> On 24.04.2023 17:47, Adam Mizerski wrote: |>>> W dniu 24.04.2023 o 13:05, Charles Rinnoch pisze: |>>> it appears that Network |>>> |>>>> Manager is more a per user subsystem for which you need to log in in |>>>> order to |>>>> get the connections you want. |>>> |>>> It appears like that, because by default connections are limited to |>>> users that create them. |>> |>> You are talking about KDE Plasma applet, not about NetworkManager. |> |> I believe the NM applet in XFCE does the same. | |No, it defaults to system connections (All users may connect to this |network), at least when you create new connection. Of course we may be |having different applets ... | |in any case - everyone hopelessly confuses NetworkManager and GUI used |to configure NetworkManager. NetworkManager is a server which does |exactly what connection definition contains. Whether some GUI used to |configure it defaults to some values for some settings is the feature of |this GUI, not of the NetworkManager. | |> By default new |> connections belong to the user and don't start till the user logs in. |> But I have not verified recently when the connection is done.
See, this is why I quickly abandoned use of Network Manager on my desktop machine: it's too confusing. Wicked (and its predecessor) just works, but Network Manager always seemed to be a sort of on-again, off-again thing that dropped the connection whenever I switched between accounts, etc. I'm really sorry to hear that Wicked has been deprecated.
I have a reasonably simple solution to this that I really should package oneday. Create a network group, add the users you care about along with the following file. Or alternatively if your networks don't change often just run nmtui as root from the command line and configure everything that way. 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; } }); -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
participants (13)
-
Adam Mizerski -
Andrei Borzenkov -
Carlos E. R. -
Charles Rinnoch -
Darryl Gregorash -
Felix Miata -
J Leslie Turriff -
Lew Wolfgang -
Manfred Hollstein -
Patrick Shanahan -
Robert Webb -
Rodney Baker -
Simon Lees