Bug 1672683 - [ebtables] build option breaks service firewalld
Summary: [ebtables] build option breaks service firewalld
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: ebtables
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa AcceptedBlocker
: 1673625 1674076 (view as bug list)
Depends On:
Blocks: F30BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2019-02-05 16:02 UTC by Joachim Frieben
Modified: 2019-02-22 19:02 UTC (History)
10 users (show)

Fixed In Version: ebtables-2.0.10-31.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-22 19:02:48 UTC
Type: Bug


Attachments (Terms of Use)

Description Joachim Frieben 2019-02-05 16:02:41 UTC
Description of problem:
On current Fedora Rawhide, service firewalld appears to run as expected according to command 'systemctl status firewalld', but the behaviour of command 'firewall-cmd' is weird, e.g. no default zone and no active zone is listed even when a wired interface is active, and the log file /var/log/firewalld gets filled with error messages upon running firewall-cmd, e.g. like:

"2019-02-05 15:19:51 ERROR: '/usr/sbin/ebtables-restore --noflush' failed: Bad table name 'nat'.

2019-02-05 15:19:51 ERROR: '/usr/sbin/ebtables-restore --noflush' failed: Bad table name 'nat'.

2019-02-05 15:19:51 ERROR: COMMAND_FAILED: '/usr/sbin/ebtables-restore --noflush' failed: Bad table name 'nat'.

2019-02-05 15:19:53 ERROR: INVALID_ZONE
2019-02-05 10:30:19 ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore: line 11 failed

2019-02-05 10:30:19 ERROR: '/usr/sbin/ip6tables-restore -w -n' failed: ip6tables-restore: line 11 failed

2019-02-05 10:30:19 ERROR: COMMAND_FAILED: '/usr/sbin/ip6tables-restore -w -n' failed: ip6tables-restore: line 11 failed"

Version-Release number of selected component (if applicable):
firewalld-0.6.3-1.fc30

How reproducible:
Always

Steps to Reproduce:
1. Boot current Fedora Rawhide live media.
2. Query default zone and active zones when wired connection is up.
3. Run 'firewall-cmd set --default-zone public'.

Actual results:
Command 'firewall-cmd' reports errors.

Expected results:
Command 'firewall-cmd' runs as expected.

Additional info:
- Despite the error message, 'firewall-cmd get --default-zone public' no returns "public" but still no active zones.
- Fedora 29 works as expected.

Comment 1 Eric Garver 2019-02-05 16:23:48 UTC
This was also reported on freenode, but I was unable to reproduce. Can you downgrade ebtables and then retry?

Comment 2 Joachim Frieben 2019-02-06 09:37:51 UTC
(In reply to Eric Garver from comment #1)
1. In order to reproduce this issue boot a recent live media, e.g. Fedora-Workstation-Live-x86_64-Rawhide-20190204.n.0, on bare metal or in gnome-boxes. After the GNOME desktop has come up (wired connection activated), log file /var/log/firewalld already shows the following entries:

  .. ERROR: '/usr/sbin/ebtables-restore --noflush' failed: Bad table name 'nat'.
  .. ERROR: '/usr/sbin/ebtables-restore --noflush' failed: Bad table name 'nat'.
  .. ERROR: COMMAND_FAILED: '/usr/sbin/ebtables-restore --noflush' failed: Bad table name 'nat'.
  .. ERROR: INVALID_ZONE
 
2. Downgrading package ebtables from ebtables-2.0.10-29.fc30 to ebtables-2.0.10-28.fc29 and restarting service "firewalld" restores normal operation. The last entry in the corresponding changelog reads:

  "* Mon Jan 21 2019 David Abdurachmanov <david abdurachmanov gmail com> 2.0.10-29
   - Disable --as-needed to resolve segfaults".

Comment 3 Eric Garver 2019-02-07 17:22:04 UTC
*** Bug 1673625 has been marked as a duplicate of this bug. ***

Comment 4 Tom "spot" Callaway 2019-02-07 17:44:25 UTC
I have no idea _why_ reverting to -28 would fix this, but I can confirm that it does.

Searching shows that Ubuntu has this issue open as well:

https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1672276

... which implicate their patch (to disable --as-needed in one place) that we applied in -29.

So I got rid of that patch and simply disabled --as-needed everywhere in ebtables (%undefine _ld_as_needed) and that build works again.

Comment 5 Tom "spot" Callaway 2019-02-07 17:46:05 UTC
Rawhide build with fix: https://koji.fedoraproject.org/koji/taskinfo?taskID=32610662

(keep in mind that rawhide is really slowly tagging builds right now... very slowly)

Comment 6 Tom "spot" Callaway 2019-02-07 18:04:30 UTC
It's built now, please pull it out of koji and confirm that it fixes things for you.

Comment 7 Joachim Frieben 2019-02-07 20:58:22 UTC
Build ebtables-2.0.10-31.fc30 restores normal operation of utility firewall-cmd.

Comment 8 Eric Garver 2019-02-09 21:31:12 UTC
*** Bug 1674076 has been marked as a duplicate of this bug. ***

Comment 9 František Zatloukal 2019-02-12 14:21:27 UTC
Discussed during the 2019-02-11 blocker review meeting: [1]

The decision to classify this bug as an AcceptedBlocker was made:

"accepted as a blocker per Basic criterion "...Supported install-time firewall configuration options must work correctly.""

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2019-02-11/f30-blocker-review.2019-02-11-17.13.log.txt

Comment 10 Adam Williamson 2019-02-22 19:02:48 UTC
All firewall tests passed in last Rawhide compose test in openQA, so closing.


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