Migration from wicked to NetworkManager

**phil524** · 27-Jan-2022, 07:45

Hello,

In the openSUSE Release Engineering Meeting 26.01.2022 I see this information

Wicked is phasing out. New installations of Tumbleweed are all done by default using NetworkManager (not only desktop, but also server installs). nmtui is the tool to configure it. Upgraders are not (yet) planned to be migrated away from wicked.

In the more or less short term, I will have to do a migration from my wicked network to NetworkManager.

I have a home server working as a router with a pppoe connection to internet (device eno3), 4 vlans (device eno2) with different devices, and a bridge (for a VM, device eno1).
I run also DNS (bind), DHCP and ntpd servers and use firewalld

The pppoe connection is activated via a service after start of wicked.When pppoe interface starts, it changes the default route using the received IP address from my provider.

Code:

ip route show
default dev ppp0 scope link 
xx.xx.97.36 dev ppp0 proto kernel scope link src 91.176.217.91 
192.168.1.0/24 dev vlan1 proto kernel scope link src 192.168.1.1 
192.168.1.120 via 192.168.1.120 dev br0 
192.168.2.0/24 dev vlan2 proto kernel scope link src 192.168.2.1 
192.168.3.0/24 dev vlan3 proto kernel scope link src 192.168.3.1 
192.168.4.0/24 dev vlan4 proto kernel scope link src 192.168.4.1

My connections are

Code:

# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:12 brd ff:ff:ff:ff:ff:ff
    altname enp2s0f0
3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:13 brd ff:ff:ff:ff:ff:ff
    altname enp2s0f1
4: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:14 brd ff:ff:ff:ff:ff:ff
    altname enp2s0f2
5: eno4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 9c:8e:99:5b:48:15 brd ff:ff:ff:ff:ff:ff
    altname enp2s0f3
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 5a:1a:d5:99:b3:b0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.120/32 scope global br0
       valid_lft forever preferred_lft forever
7: vlan1@eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:13 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global vlan1
       valid_lft forever preferred_lft forever
8: vlan2@eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:13 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.1/24 brd 192.168.2.255 scope global vlan2
       valid_lft forever preferred_lft forever
9: vlan4@eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:13 brd ff:ff:ff:ff:ff:ff
    inet 192.168.4.1/24 brd 192.168.4.255 scope global vlan4
       valid_lft forever preferred_lft forever
10: vlan3@eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:13 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.1/24 brd 192.168.3.255 scope global vlan3
       valid_lft forever preferred_lft forever
11: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet XX.YYY.217.91 peer XX.XX.97.36/32 scope global ppp0
       valid_lft forever preferred_lft forever

I looked for some data about NetworkManager and I think that I can create the connection via the next commands (from man nmcli-examples)
ppp0

Code:

nmcli connection add type pppoe username XXXXXXX@provider password yyyyyy  ifname ppp0 con-name ppp0 pppoe.parent en03
nmcli connection modify ppp0 802.mtu 1492

vlans where x = 1,2,3,4

Code:

nmcli connection add type vlan con-name vlanx dev eno2 id x ip4 192.168.x.0/255 gw4 192.168.x.1

for the bridge br0

Code:

nmcli con add type bridge con-name br0 ifname br0
nmcli con add type ethernet con-name eno1 ifname eno1 master br0

Now my questions:
They suggest using the nmtui program but is it possible setting my configuration with it or is it better to use nmcli?
If I change in Yast the connection type from wicked to NetworkManager, disable the current pppoe.service and try the above commands is it possible going back to wicked type without recreating all the network settings?
How is it working with networkManager and pppoe for the default route?
I'm a bit doubtful about the definition for the bridge. Is it correct?
Should the VM connection work out of the box or do I need some additional configuration?
I want also that the interfaces are active immediately after the boot without login in KDE : Are there additional settings needed therefor?
I have read that NetworkManager use dnsmasq but I'm using named (bind) +dhcpd. Is this a problem? Are there additional settings required?

Many thanks in advance
Philippe

**hcvv** · 27-Jan-2022, 08:04

Just as alternative. Switch from Wicked to systemd.networkd. To me that looks as a very straightforward solution for a "server" like system.

**phil524** · 28-Jan-2022, 01:29

Originally Posted by hcvv

Just as alternative. Switch from Wicked to systemd.networkd. To me that looks as a very straightforward solution for a "server" like system.

Thanks for your answer.

I didn't think to use systemd_networkd and looked in the related man.
At first sight it is not simple and i found less examples than for nmcli.
I'll investigate further and see if I can use it.
If needed i'll come back with my questions

Regards
Philippe

**hcvv** · 28-Jan-2022, 01:48

I do of course not know yor exact situation, but in my situation configuring was easy and it runs ever since I did it (e.g. nothing to do on 15.2 >15.3 upgrade). These are the notes I made so I could easily post again by copy/post:

See this discussion for some background:
et0 not (auto) enabled at boot time no static ip-addresses are assigned starting at post #10.

For documentation of the systemd-networkd service:

Code:

man 8 systemd-networkd

Code:

man 5 systemd.network

=============================

As an example, what I have done (no DHCP, fixed IP-address, etc.).

Create /etc/systemd/network/20-wired.network:

Code:

[Match]
Name=eth0
  
[Network]
Address=10.0.0.254/24
Gateway=10.0.0.138

I assume you understand how to adapt the name of the NIC, the IP-addess/netmask and the gateway address to your situation.

Remove /etc/resolv.conf (It is often a symbolic link) and create a new one:

Code:

search xs4all.nl
nameserver 194.109.6.66
nameserver 194.109.9.99
nameserver 194.109.104.104

You may or many not want to use a search statement there and of course should use the IP-addresses of the nameserver(s) you prefer (maybe your router).

Use YaST > System > Services Manager to switch all services with "wicked" in the name to "Manually" and to switch the systemd-networks service to "On Boot".

Reboot and test.

**karlmistelberger** · 28-Jan-2022, 02:13

Originally Posted by hcvv

As an example, what I have done (no DHCP, fixed IP-address, etc.).

Create /etc/systemd/network/20-wired.network:

Code:

[Match]
Name=eth0
  
[Network]
Address=10.0.0.254/24
Gateway=10.0.0.138

I assume you understand how to adapt the name of the NIC, the IP-addess/netmask and the gateway address to your situation.

Remove /etc/resolv.conf (It is often a symbolic link) and create a new one:

Code:

search xs4all.nl
nameserver 194.109.6.66
nameserver 194.109.9.99
nameserver 194.109.104.104

You may or many not want to use a search statement there and of course should use the IP-addresses of the nameserver(s) you prefer (maybe your router).

Use YaST > System > Services Manager to switch all services with "wicked" in the name to "Manually" and to switch the systemd-networks service to "On Boot".

Reboot and test.

DHCP is even easier:

Code:

i3-4130:~ # cat /etc/systemd/network/wlan.network  
[Match] 
Name=w* 

[Network] 
DHCP=yes 
Domains=fritz.box 
i3-4130:~ #

Resolver:

Code:

i3-4130:~ # ll /etc/resolv.conf 
lrwxrwxrwx 1 root root 32 Jun 19  2021 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf 
i3-4130:~ #

https://en.opensuse.org/Network_Management_With_Systemd

**hcvv** · 28-Jan-2022, 02:32

Karl, thanks for the addition (I assumed that your examples can be found using my link to the old thread in my post above).

About resolving. Can you inform me what that symlink to /run/systemd/resolve/resolv.conf is supposed to do?
In my system:

Code:

boven:/run/systemd # l resolve
ls: cannot access 'resolve': No such file or directory
boven:/run/systemd #

Thus such a link would not be a good idea IMHO, where my good old resolv.conf works already for more then 20 years.

**karlmistelberger** · 28-Jan-2022, 03:23

Originally Posted by hcvv

About resolving. Can you inform me what that symlink to /run/systemd/resolve/resolv.conf is supposed to do?
In my system:

Code:

boven:/run/systemd # l resolve
ls: cannot access 'resolve': No such file or directory
boven:/run/systemd #

systemd-resolved fills in the addresses and the domain:

Code:

i3-4130:~ # systemctl list-unit-files systemd-resolved.service 
UNIT FILE                STATE   VENDOR PRESET
systemd-resolved.service enabled disabled     

1 unit files listed. 
i3-4130:~ # systemctl list-units systemd-resolved.service      
  UNIT                     LOAD   ACTIVE SUB     DESCRIPTION            
  systemd-resolved.service loaded active running Network Name Resolution 

LOAD   = Reflects whether the unit definition was properly loaded. 
ACTIVE = The high-level unit activation state, i.e. generalization of SUB. 
SUB    = The low-level unit activation state, values depend on unit type. 
1 loaded units listed. Pass --all to see loaded but inactive units, too. 
To show all installed unit files use 'systemctl list-unit-files'. 
i3-4130:~ # cat /etc/resolv.conf                               
# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8). 
# Do not edit. 
# 
# This file might be symlinked as /etc/resolv.conf. If you're looking at 
# /etc/resolv.conf and seeing this text, you have followed the symlink. 
# 
# This is a dynamic resolv.conf file for connecting local clients directly to 
# all known uplink DNS servers. This file lists all configured search domains. 
# 
# Third party programs should typically not access this file directly, but only 
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a 
# different way, replace this symlink by a static file or a different symlink. 
# 
# See man:systemd-resolved.service(8) for details about the supported modes of 
# operation for /etc/resolv.conf. 

nameserver 192.168.178.1 
nameserver fd00::a96:d7ff:fee2:d6cf 
search fritz.box 
i3-4130:~ #

Thus such a link would not be a good idea IMHO, where my good old resolv.conf works already for more then 20 years.

Your good old resolv.conf contains static data, which need maintenance. systemd-resolved provides dynamic data and uses Domains from wlan.network. Virtually maintenance-free.

**hcvv** · 28-Jan-2022, 04:09

Originally Posted by karlmistelberger

[/CODE]

Your good old resolv.conf contains static data, which need maintenance. systemd-resolved provides dynamic data and uses Domains from wlan.network. Virtually maintenance-free.

My resolv.conf is the same for at least 17 years. And filling in the same date in that unit file does not really seem an improvement to me. And when I change ISP, I guess I have to change them in my maintenance free unit file the same way as in the real resolv.conf..

**karlmistelberger** · 28-Jan-2022, 05:03

Originally Posted by hcvv

My resolv.conf is the same for at least 17 years. And filling in the same date in that unit file does not really seem an improvement to me. And when I change ISP, I guess I have to change them in my maintenance free unit file the same way as in the real resolv.conf.

When I change the ISP and keep the Fritz!Box I need to change username and password only.
When I replace the Fritz!Box by another model I need to change "Domains" only.
When I move the machine to a different local network I need to change "Domains" only.
When I move to a ipv4-only network I need to change to DHCP=ipv4 only.
...

All changes are made in a single .network file. Link /etc/resolv.conf never changes.

When I change nothing I need not change anything. However assuming no changes will be made for the next 20 years is not a valid assumption. Thus symlinking /etc/resolv.conf to /run/systemd/resolve/resolv.conf is the preferred procedure. When users bring in their machine for maintenance I comment out Domains=TheirDomain and add my Domains=fritz.box if applicable and testing is desirable.

**phil524** · 28-Jan-2022, 09:48

Originally Posted by hcvv

I do of course not know yor exact situation, but in my situation configuring was easy and it runs ever since I did it (e.g. nothing to do on 15.2 >15.3 upgrade). These are the notes I made so I could easily post again by copy/post:

See this discussion for some background:
et0 not (auto) enabled at boot time no static ip-addresses are assigned starting at post #10.

For documentation of the systemd-networkd service:

Code:

man 8 systemd-networkd

Code:

man 5 systemd.network

Thanks , I have also found a post for vlan with systemd-networkd and I created the related files

Code:

cd /etc/systemd/network
# ls -l
total 48
-rw-r--r-- 1 root root  30 janv. 27 18:14 05-br0.netdev
-rw-r--r-- 1 root root  73 janv. 28 16:34 06-br0.network
-rw-r--r-- 1 root root  47 janv. 28 13:39 11-vlan1.netdev
-rw-r--r-- 1 root root  47 janv. 28 13:40 12-vlan2.netdev
-rw-r--r-- 1 root root  47 janv. 28 13:40 13-vlan3.netdev
-rw-r--r-- 1 root root  47 janv. 28 13:41 14-vlan4.netdev
-rw-r--r-- 1 root root 126 janv. 28 13:42 20-eno2vlan.network
-rw-r--r-- 1 root root 133 janv. 28 13:43 21-vlan1.network
-rw-r--r-- 1 root root 133 janv. 28 13:43 22-vlan2.network
-rw-r--r-- 1 root root 133 janv. 28 13:43 23-vlan3.network
-rw-r--r-- 1 root root 133 janv. 28 13:44 24-vlan4.network
-rw-r--r-- 1 root root  62 janv. 28 16:38 30-eno3.network

# cat 11-vlan1.netdev
[NetDev]
Name=vlan1@eno2
Kind=vlan
[VLAN]
Id=1

# cat 21-vlan1.network
[Match]
Name=vlan1@eno2
Type=vlan
[Network]
Description=vlan1 interface
[Address]
Address=192.168.1.1/24
[Route]
Gateway=192.168.1.1

# cat 20-eno2vlan.network
[Match]
Name=eno2
Type=ether
[Network]
LinkLocalAddressing=no
VLAN=vlan1@eno2
VLAN=vlan2@eno2
VLAN=vlan3@eno2
VLAN=vlan4@eno2

Remove /etc/resolv.conf (It is often a symbolic link) and create a new one:

Code:

search xs4all.nl
nameserver 194.109.6.66
nameserver 194.109.9.99
nameserver 194.109.104.104

You may or many not want to use a search statement there and of course should use the IP-addresses of the nameserver(s) you prefer (maybe your router).

My resolv.conf contains

Code:

search pce23.net samdom.pce23.net
nameserver 192.168.1.120
nameserver 195.238.2.21
nameserver 195.238.2.22

AFAIK it is generated from the data entered in YaST network (wicked). Is there something equivalent for systemd-networkd or do I need to do it manually?

Some questions :
1. currently the pppoe connection is started via a service file (after network start) and it uses a configured interface (eno3) defined without IP address see
https://paste.opensuse.org/18770202

My idea is that I must define a 30-eno3.network file with

Code:

# cat 30*
[Match]
Name=eno3
Type=ether
[Network]
LinkLocalAddressing=no

is this ok?

2. the pppoe service file has this setting

Code:

[Unit]
Description=PPP link to %I
After=network-pre.target network.service 
Before=network.target multi-user.target shutdown.target

Are the after and before lines still valid or is there a change needed with systemd-networkd?

Use YaST > System > Services Manager to switch all services with "wicked" in the name to "Manually" and to switch the systemd-networks service to "On Boot".

Reboot and test.

Ok seems easy to come back to wicked if I have problem with systemd-networkd

Many thanks for your help
Philippe

Note: If you didn't migrate your openSUSE account in June 2020, you will need to create a new account with a different email!

NOTE January 2022 - Changes to Gstreamer and Pipewire packages from Packman

Thread: Migration from wicked to NetworkManager

Thread Tools

Display