Bug 1586284 - ifup no longer configures interface firewalld zone
Summary: ifup no longer configures interface firewalld zone
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: initscripts
Version: 7.5
Hardware: All
OS: Linux
urgent
high
Target Milestone: rc
: ---
Assignee: David Kaspar [Dee'Kej]
QA Contact: Daniel Rusek
URL:
Whiteboard:
Depends On: 1588456 1587904
Blocks: 1588566
TreeView+ depends on / blocked
 
Reported: 2018-06-05 21:36 UTC by Jason Dillaman
Modified: 2018-10-30 10:16 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1588566 (view as bug list)
Environment:
Last Closed: 2018-10-30 10:16:21 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3131 None None None 2018-10-30 10:16:37 UTC

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


Note You need to log in before you can comment on or make changes to this bug.