Bug 1586284

Summary:	ifup no longer configures interface firewalld zone
Product:	Red Hat Enterprise Linux 7	Reporter:	Jason Dillaman <jdillama>
Component:	initscripts	Assignee:	David Kaspar // Dee'Kej <deekej>
Status:	CLOSED ERRATA	QA Contact:	Daniel Rusek <drusek>
Severity:	high	Docs Contact:
Priority:	urgent
Version:	7.5	CC:	deekej, drusek, egarver, fkrska, initscripts-maint-list, todoleza
Target Milestone:	rc	Keywords:	Patch, Regression, Reproducer, ZStream
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1588566 (view as bug list)		Environment:
Last Closed:	2018-10-30 10:16:21 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1587904, 1588456
Bug Blocks:	1588566

Description Jason Dillaman 2018-06-05 21:36:49 UTC

Description of problem:
It appears that starting w/ initscripts-9.49.40-2.el7, the call to "firewall-cmd" was replaced w/ a dbus call to configured the firewall zone. 

However, in a non-X installation of RHEL, the "system-config-firewall" package is not installed and it contains the dbus hooks for firewalld. This results in the dbus calls disappearing into the ether. Attempting to install "system-config-firewall" will pull in gtk2.

Version-Release number of selected component (if applicable):
initscripts-9.49.40-2.el7

How reproducible:
100%

Steps to Reproduce:
1. Install RHEL 7.5 w/ network service, (NetworkManager disabled), firewalld, and w/o a graphical environment
2. Add a "ZONE=xyz" line to a "/etc/sysconfig/network-scripts/ifcfg-XYZ" file
3. "ifup XYZ"

Actual results:
The network interface is not placed in the specified zone

Expected results:
The network interface is placed in the specified zone

Additional info:

Comment 2 Jason Dillaman 2018-06-05 21:39:29 UTC

Related to the change from BZ 1497759

Comment 3 David Kaspar // Dee'Kej 2018-06-06 09:35:07 UTC

OK, so fixing this requires the DBus hooks to be installed by default on server installation (which does not contain GUI).

If we add the requirement on 'system-config-firewall' into initscripts, it will pull in the GTK2 as well, which is not desired on server installation.

Therefore, we have to IMHO have a separation of the DBus hooks from the rest of the 'system-config-firewall'. Maybe a new subpackage would be sufficent?

Comment 5 Jason Dillaman 2018-06-06 12:52:04 UTC

Actually, I cannot repeat this on a clean installation of RHEL 7.5, so perhaps something is just wonky w/ my original VM since it's been upgraded since RHEL 7.0. I noticed that 'system-config-firewall' is a dead package in the latest releases but it was still in my yum cache. I'll do a better job root-causing this and will open a new BZ if appropriate.

Comment 6 David Kaspar // Dee'Kej 2018-06-06 13:11:40 UTC

Well, right now during my testing it seems that the dbus-send call does not change anything. I'm unable to set a firewalld zone with this... :-/

Comment 7 Jason Dillaman 2018-06-06 13:31:45 UTC

OK, perhaps I'm not crazy then. If I add "--print-reply" to the "dbus-send" in "ifup-post" it seems to work for me on my old RHEL7 VM; whereas w/o it, upon reboot, I lose the zone settings.

Comment 8 David Kaspar // Dee'Kej 2018-06-06 13:49:29 UTC

(In reply to Jason Dillaman from comment #7)
> OK, perhaps I'm not crazy then. If I add "--print-reply" to the "dbus-send"
> in "ifup-post" it seems to work for me on my old RHEL7 VM; whereas w/o it,
> upon reboot, I lose the zone settings.

Heh, that's exactly what I wanted to write here. Without the '--print-reply' the ZONE does not get configured. If I add the '--print-reply' there into the ifup/ifdown scripts, then it works as intended. That is for sure some strange behaviour from DBus, probably something for another BZ as well.

We have removed the --print-reply suggestion from Eric Garver, since we wanted to be fast as possible and use the "fire & forget" approach (more info in BZ #1497759). However, it also still means you were correct and we indeed have a regression on our hands.

And I have found another bug as well during my search there (luckily its less significant IMHO). The space between 'string:' and "" is causing the DBus call to fail:
https://github.com/fedora-sysv/initscripts/blob/master/network-scripts/ifdown-post#L61

I have lost the notification from Eric about this when I had several notifications on Github... :-/
https://github.com/fedora-sysv/initscripts/pull/132#discussion_r144856715

I'm goint to prepare the pull-request for this to get fixed. Thanks again Jason for your report! :)

Comment 9 David Kaspar // Dee'Kej 2018-06-06 17:23:59 UTC

Pull-request submitted:
https://github.com/fedora-sysv/initscripts/pull/209

Comment 15 Daniel Rusek 2018-07-04 16:03:20 UTC

:: [ 13:34:17 ] :: [   PASS   ] :: Command 'firewall-cmd --zone=home --list-all' (Expected 0, got 0)
:: [ 13:34:17 ] :: [   PASS   ] :: File '/var/tmp/rlRun_LOG.dPufCeDV' should contain 'emac0'

I can confirm that this issue is now fixed.

Comment 17 errata-xmlrpc 2018-10-30 10:16:21 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3131