Bug 1417323

Patching or scratch build for iptables-1.6.0 failed.

Created attachment 1245286 [details]
Rebase-helper rebase-helper-debug.log log file.
See for details and report the eventual error to rebase-helper https://github.com/phracek/rebase-helper/issues.

Following patches has been deleted:
['iptables-1.6.0-iptables-apply_mktemp.patch']

twoerner's iptables-1.6.1-1.fc26 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=837909

releng's iptables-1.6.1-2.fc26 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=845017

releng's iptables-1.6.1-3.fc27 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=927103

releng's iptables-1.6.1-4.fc27 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=946570

Latest upstream release: 1.6.2
Current version/release in rawhide: 1.6.1-5.fc28
URL: http://ftp.netfilter.org/pub/iptables/

Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.

Based on the information from anitya:  https://release-monitoring.org/project/1394/

@Thomas, would you object to me pushing this to Rawhide?

(In reply to Michael Cronenworth from comment #9)
> @Thomas, would you object to me pushing this to Rawhide?

I think Phil is actually handling iptables nowadays.

Hi Michael,

(In reply to Michael Cronenworth from comment #9)
> @Thomas, would you object to me pushing this to Rawhide?

No veto from my side. Though I guess nowadays everyone seems to prefer pull-requests. :)

Cheers, Phil

PRs are fine for those without provenpackger, but since I have it I prefer to Just Do It. I'll push it soon. Thanks.

Rawhide + F28 pushed. I can push updates to F26/F27 if you feel it is appropriate.

(In reply to Michael Cronenworth from comment #12)
> PRs are fine for those without provenpackger, but since I have it I prefer
> to Just Do It. I'll push it soon. Thanks.

Thanks for your help!

(In reply to Michael Cronenworth from comment #13)
> Rawhide + F28 pushed. I can push updates to F26/F27 if you feel it is
> appropriate.

Please do as you see fit. In my opinion, it's a mixed blessing: On one hand there are many fixes and improvements in 1.6.2, on the other it introduces at least some nft translations which are not supported by nftables package in F26/F27. Though I guess the latter are minor in comparison to the further.

Thanks, Phil

libnftnl-1.0.9-2.fc27 nftables-0.8.2-2.fc27 iptables-1.6.2-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1c31f1eccd

nftables-0.8.2-2.fc26 iptables-1.6.2-1.fc26 libnftnl-1.0.9-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e3590e7463

iptables-1.6.2-1.fc26, libnftnl-1.0.9-2.fc26, nftables-0.8.2-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e3590e7463

iptables-1.6.2-1.fc27, libnftnl-1.0.9-2.fc27, nftables-0.8.2-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-1c31f1eccd

@Phil,

As reported by other users, and encountering it myself, 1.6.2 introduces a regression with ip6tables. Upon boot the initial flush and loading of rules fails. After logging in the service can be run successfully, but it fails every time during the boot process.

Hi Michael,

(In reply to Michael Cronenworth from comment #19)
> @Phil,
> 
> As reported by other users, and encountering it myself, 1.6.2 introduces a
> regression with ip6tables. Upon boot the initial flush and loading of rules
> fails. After logging in the service can be run successfully, but it fails
> every time during the boot process.

Did you investigate this?

Cheers, Phil

I have not done much investigation. I tried adding a "-w 1" argument to the ip6tables script, but that did not help. Would you have any time to look at it?

Hi Michael,

(In reply to Michael Cronenworth from comment #21)
> I have not done much investigation. I tried adding a "-w 1" argument to the
> ip6tables script, but that did not help. Would you have any time to look at
> it?

This was a parallel startup issue we already saw in RHEL. I released 1.6.2-2 which should fix it, at least I couldn't reproduce the issue anymore.

Thanks, Phil

Perfect! Thanks. Pushing updates now.

iptables-1.6.2-2.fc27 libnftnl-1.0.9-2.fc27 nftables-0.8.2-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1c31f1eccd

iptables-1.6.2-2.fc26 libnftnl-1.0.9-2.fc26 nftables-0.8.2-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e3590e7463

iptables-1.6.2-2.fc26, libnftnl-1.0.9-2.fc26, nftables-0.8.2-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e3590e7463

iptables-1.6.2-2.fc27, libnftnl-1.0.9-2.fc27, nftables-0.8.2-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-1c31f1eccd

@Phil,

A new regression has appeared. There is a race between iptables/ip6tables on /run/xtables.lock. Sometimes the file does not get the correct SELinux context and iptables fails to load.

Failed Boot:
$ ll -Z /run/xtables.lock 
-rw-------. 1 root root system_u:object_r:var_run_t:s0 0 Mar  3 09:45 /run/xtables.lock

Successful Boot:
$ ll -Z /run/xtables.lock 
-rw-------. 1 root root system_u:object_r:iptables_var_run_t:s0 0 Mar  3 09:45 /run/xtables.lock

Hi Michael,

(In reply to Michael Cronenworth from comment #28)
> A new regression has appeared. There is a race between iptables/ip6tables on
> /run/xtables.lock. Sometimes the file does not get the correct SELinux
> context and iptables fails to load.
> 
> Failed Boot:
> $ ll -Z /run/xtables.lock 
> -rw-------. 1 root root system_u:object_r:var_run_t:s0 0 Mar  3 09:45
> /run/xtables.lock
> 
> Successful Boot:
> $ ll -Z /run/xtables.lock 
> -rw-------. 1 root root system_u:object_r:iptables_var_run_t:s0 0 Mar  3
> 09:45 /run/xtables.lock

How did you reproduce this? I tested my changes using an endless loop:

| while true; do systemctl restart iptables ip6tables; done

Do you see the problem on Rawhide or an earlier release? (Thanks BTW for doing
the backports.)

Cheers, Phil

(In reply to Phil Sutter from comment #29)
> How did you reproduce this? I tested my changes using an endless loop:
> 
> | while true; do systemctl restart iptables ip6tables; done

It is at boot time. If your /run/xtables.lock file context is correct at boot your loop will always work. If the file gets the wrong context the loop would always fail.

> Do you see the problem on Rawhide or an earlier release? (Thanks BTW for
> doing
> the backports.)

I'm testing this on Fedora 27. Other F27 users are reporting the same thing. A 'restorecon /run/xtables.lock' command fixes the context. Does the iptables/ip6tables script need to set the context?

@Phil, I believe RHEL ran into this and the SELinux policy was fixed, but I don't have access to view the bug to compare. Can you check out bug 1436904, which links to bug 1376343 and see if the issue is with SELinux?

https://bugzilla.redhat.com/show_bug.cgi?id=1551463

Thanks, liva. The bug is that the SELinux policy has different contexts for the iptables.init and ip6tables.init files. Depending on which script starts first at boot the /run/xtables.lock file gets set with that context.

iptables-1.6.2-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1c31f1eccd

iptables-1.6.2-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-1c31f1eccd

iptables-1.6.2-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-59e87c41b7

iptables-1.6.2-3.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-59e87c41b7

iptables-1.6.2-3.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.