Bug 1120380

Summary: wicked-managed interface is not assigned any zone in firewalld
Product: [openSUSE] openSUSE Distribution Reporter: Stephan Schöttl <stschoettl>
Component: NetworkAssignee: wicked maintainers <wicked-maintainers>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: rtorreromarijnissen
Version: Leap 15.0   
Target Milestone: ---   
Hardware: x86-64   
OS: SUSE Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: linuxrc expected directory structure for a DUD
DUD applied successfuly

Description Stephan Schöttl 2018-12-28 12:05:50 UTC
I have assigned network inferface eth0 to firewalld zone home. After reboot, the output of "firewall-cmd --get-active-zones" is emtpy. When I restart wickedd with "systemctl restart wickedd.service" the interface is correctly assigned to zone "home". This leads me to believe that wickedd should be started _after_ firewalld.

I have found "After=local-fs.target dbus.service isdn.service rdma.service SuSEfirewall2_init.service" in /usr/lib/systemd/system/wickedd.service and other systemd unit files related to wicked. I believe SuSEfirewall2_init should be replaced with firewalld now that this is the default Suse firewall management system.

Here are the boot messages that show that wickedd and firewalld are being started in parallel and that firewalld is only fully active _after_ most of the wicked processes are running:

journalctl -b | grep Start | egrep 'wicked|firewall'
Dec 27 11:22:35 px200e systemd[1]: Starting firewalld - dynamic firewall daemon...
Dec 27 11:22:35 px200e systemd[1]: Starting wicked AutoIPv4 supplicant service...
Dec 27 11:22:35 px200e systemd[1]: Starting wicked DHCPv4 supplicant service...
Dec 27 11:22:35 px200e systemd[1]: Starting wicked DHCPv6 supplicant service...
Dec 27 11:22:35 px200e systemd[1]: Started wicked DHCPv6 supplicant service.
Dec 27 11:22:35 px200e systemd[1]: Started wicked DHCPv4 supplicant service.
Dec 27 11:22:35 px200e systemd[1]: Started wicked AutoIPv4 supplicant service.
Dec 27 11:22:35 px200e systemd[1]: Starting wicked network management service daemon...
Dec 27 11:22:36 px200e systemd[1]: Started wicked network management service daemon.
Dec 27 11:22:36 px200e systemd[1]: Starting wicked network nanny service...
Dec 27 11:22:36 px200e systemd[1]: Started wicked network nanny service.
Dec 27 11:22:41 px200e systemd[1]: Started firewalld - dynamic firewall daemon.
Dec 27 11:22:41 px200e systemd[1]: Starting wicked managed network interfaces...
Dec 27 11:22:47 px200e systemd[1]: Started wicked managed network interfaces.
Comment 1 Rubén Torrero Marijnissen 2019-01-10 11:02:26 UTC
Hi Stephan,

could you provide more information?

 - the ifcfg-eth0 file (/etc/sysconfig/network/ifcfg-eth0)
 - how did you assign it to the "home" zone? did you use YaST2 for this or did you just alter the zone in the ifcfg- file?
 - did you add the zone in runtime mode or as permanent change?
Comment 2 Rubén Torrero Marijnissen 2019-01-10 11:54:58 UTC
One more thing: could you share what wicked version you are running?
Comment 3 Stephan Schöttl 2019-01-10 18:30:29 UTC
Hello Rubén,

the wicked rpm package version is wicked-service-0.6.52-lp150.2.3.1.x86_64. The ifcfg file has the following contents:

sudo cat /etc/sysconfig/network/ifcfg-eth0
BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.2.17/24'
MTU=''
NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller'
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
IPADDR_0='192.168.2.23/24'
LABEL_0='tine20'
ZONE=home

I did not use YaST2 to assign the zone but edited the ifcfg file directly. The zone was created with firewall-cmd. If I remember correctly then I created the zone in runtime mode and then made it permanent with "firewall-cmd --runtime-to-permanent".
Comment 4 Rubén Torrero Marijnissen 2019-01-11 12:52:44 UTC
Created attachment 794206 [details]
linuxrc expected directory structure for a DUD
Comment 5 Rubén Torrero Marijnissen 2019-01-11 12:55:17 UTC
Created attachment 794207 [details]
DUD applied successfuly
Comment 6 Rubén Torrero Marijnissen 2019-01-11 12:56:52 UTC
Hi,

I repeated the process of applying the DUD myself to identify what might be going wrong and I've made a list of things to check:
 
 - The filesystem for the USB stick should be ext3/4 (I'm using ext4 myself)
 - The directory structure should be the following (attachment in comment 4)
 - Start the installer from the SLE-12-SP4-Server-DVD-x86_64-GM-DVD1.iso file.

When you add the dud=1 to the kernel's cmdline, after a while, you should see the next in linuxrc (attachment in comment 5). I've noticed that when linuxrc is not able to find the dud automatically (in my experience, due to the directory structure being different to what it expects or due to a unrecognized FS), it will prompt and ask for a location, but if everything is OK it should be able to automatically apply it without asking anything.
Comment 7 Rubén Torrero Marijnissen 2019-01-11 12:58:50 UTC
(Dismiss the previous comments, wrong bug)
Comment 8 Rubén Torrero Marijnissen 2019-01-14 12:25:10 UTC
Hi Stephan,

Could you try copying all the /usr/lib/systemd/system/wickedd*.service files to /etc/systemd/system and add there "firewalld" to the end of the After= line to see if this makes it work correctly?
Comment 9 Stephan Schöttl 2019-01-15 06:41:18 UTC
Hello Rubén,

I have already copied wickedd.service and applied the following change:

diff /etc/systemd/system/wickedd.service /usr/lib/systemd/system/wickedd.service 
5c5
< After=local-fs.target dbus.service isdn.service rdma.service firewalld.service
---
> After=local-fs.target dbus.service isdn.service rdma.service SuSEfirewall2_init.service

This seems to solve the issue. I have not tried anything with the other wicked*.service files.

Best regards

Stephan
Comment 10 Rubén Torrero Marijnissen 2020-03-26 16:41:46 UTC
The issue was addressed with PR: https://github.com/openSUSE/wicked/pull/824

The fix was released in wicked 0.6.62 and it should land on Leap 15 on the next MU.

Thanks for reporting.