Page 1 of 3 123 LastLast
Results 1 to 10 of 28

Thread: Migration from wicked to NetworkManager

  1. #1
    Join Date
    Aug 2008
    Location
    Belgium
    Posts
    321

    Default Migration from wicked to NetworkManager

    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
    Tumbleweed (x86_64) Kernel 5.17 with KDE plasma Xorg

  2. #2
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    30,507

    Default Re: Migration from wicked to NetworkManager

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

  3. #3
    Join Date
    Aug 2008
    Location
    Belgium
    Posts
    321

    Default Re: Migration from wicked to NetworkManager

    Quote Originally Posted by hcvv View Post
    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
    Tumbleweed (x86_64) Kernel 5.17 with KDE plasma Xorg

  4. #4
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    30,507

    Default Re: Migration from wicked to NetworkManager

    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.
    Henk van Velden

  5. #5
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    3,707

    Default Re: Migration from wicked to NetworkManager

    Quote Originally Posted by hcvv View Post
    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
    i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), 5600X (2022) openSUSE Tumbleweed, KDE Plasma

  6. #6
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    30,507

    Default Re: Migration from wicked to NetworkManager

    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.
    Henk van Velden

  7. #7
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    3,707

    Default Re: Migration from wicked to NetworkManager

    Quote Originally Posted by hcvv View Post
    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.
    i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), 5600X (2022) openSUSE Tumbleweed, KDE Plasma

  8. #8
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    30,507

    Default Re: Migration from wicked to NetworkManager

    Quote Originally Posted by karlmistelberger View Post
    [/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..
    Henk van Velden

  9. #9
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    3,707

    Default Re: Migration from wicked to NetworkManager

    Quote Originally Posted by hcvv View Post
    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.
    1. When I change the ISP and keep the Fritz!Box I need to change username and password only.
    2. When I replace the Fritz!Box by another model I need to change "Domains" only.
    3. When I move the machine to a different local network I need to change "Domains" only.
    4. When I move to a ipv4-only network I need to change to DHCP=ipv4 only.
    5. ...

    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.
    i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), 5600X (2022) openSUSE Tumbleweed, KDE Plasma

  10. #10
    Join Date
    Aug 2008
    Location
    Belgium
    Posts
    321

    Default Re: Migration from wicked to NetworkManager

    Quote Originally Posted by hcvv View Post
    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
    Tumbleweed (x86_64) Kernel 5.17 with KDE plasma Xorg

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •