Re: Fedora 32 System-Wide Change proposal: Firewalld Default to nftables
On Sat, Dec 28, 2019 at 09:58:50AM -0500, Neal Gompa wrote: > On Mon, Sep 9, 2019 at 3:32 PM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables > > > > == Summary == > > This change will toggle the default firewalld backend from iptables to > > nftables. All of firewalld's primitives will use nftables while direct > > rules continue to use iptables/ebtables. > > > > == Owner == > > * Name: [[User:erig0| Eric Garver]] > > * Email: egar...@redhat.com > > > > > > == Detailed Description == > > Firewalld upstream has used nftables as the default backend for the > > past two minor releases. It is also the default in other distributions > > (e.g. RHEL-8). This change will bring Fedora in line with upstream. > > > > Using nftables bring many advantages. See firewalld's upstream > > [https://firewalld.org/2018/07/nftables-backend blog post]. It also > > highlights a few behavioral changes. > > > > == Benefit to Fedora == > > * Fewer firewall rules (rule consolidation) > > All of firewalld's primitives will use the same underlying firewall > > (nftables) instead of duplicating rules both in iptables and > > ip6tables. In nftables rules can match both IPv4 and IPv6 packets. > > This reduces the number of firewall rules by half. > > * firewalld's rules are namespaced > > With nftables firewalld's rules are isolated to a "firewalld" table. A > > separate firewall (or user) can create its own independent ruleset and > > firewalld will never touch it. > > * Netfilter upstream is focusing on nftables, not iptables > > > > == Scope == > > * Proposal owners: firewalld (erig0, Eric Garver) > > Currently the firewalld package has a Fedora downstream patch to hide > > the nftables backend. The only firewalld change required is to remove > > that patch from the package and rebuild. > > > > * Other developers: libvirt, podman, docker > > ** libvirt > > *** libvirt already cooperates with the firewalld nftables backend. > > The only thing needed is to test/verify. > > ** podman > > *** libvirt already cooperates with the firewalld nftables backend. > > The only thing needed is to test/verify. > > ** docker > > *** Docker currently does not cooperate with the nftables backend. It > > currently side-steps firewalld by injecting its own rules in iptables > > ahead of firewalld's rules. However, with the nftables backend > > firewalld's rule will still be evaluated. Netfilter in the kernel will > > call iptables, then nftables for the same packet. This means > > firewalld/nftables is likely to drop the packet even if docker has > > iptables rules to ACCEPT. > > *** Proposed fix 1: Docker package should provide a firewalld zone > > definition that includes the docker interfaces (e.g. docker0). The > > zone should use the "ACCEPT" policy (firewalld --set-target). This > > will allow docker's traffic to pass through firewalld/nftables. > > Issue 1: If a user has configured a different docker bridge name, > > then they'll have to manually add the bridge to the docker zone (or > > firewalld's trusted zone). > > *** Proposed fix 2: Just like "Proposed fix 1", but instead of adding > > the zone definition to docker we created a "docker-firewalld" (or > > firewalld-docker?) package that has the zone definition. This could be > > installed by default when docker is installed. > > * Policies and guidelines: No updated needed. > > * Trademark approval: N/A (not needed for this Change) > > > > > > == Upgrade/compatibility impact == > > When users are upgraded to firewalld with nftables enabled (f32) all > > their firewall rules will exist in nftables instead of iptables. All > > of firewalld's primitives (zones, services, ports, rich rules, etc.) > > are 100% compatible between backends. > > > > Users of direct rules may need to consider the > > [https://firewalld.org/2018/07/nftables-backend behavioral changes] > > that were announced upstream. Some are also highlighted here: > > > > * direct rules execute before _all_ firewalld rules > > ** This has been requested by users > > * packets dropped in iptables (or direct rules) will never be seen by > > firewalld > > * packets accepted in iptables (or direct rules) are still subject to > > firewalld's rules > > > > == How To Test == > > Testing should mostly be integration based. Firewalld upstream has a > > fairly
Orphaning system-config-firewall
Hi, I am orphaning system-config-firewall. It currently FTBFS and is unmaintained upstream. Migration to firewalld can be done with # firewall-offline-cmd --migrate-system-config-firewall=file Thanks. Eric. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Firewalld v nftables
On Tue, Jun 11, 2019 at 07:14:49AM +1000, Bojan Smojver via devel wrote: > This was patched out, because an official feature was never submitted. > Now that RHEL8 is using that combo, maybe it's time to try again? :-) You are correct. Now that libvirt's integration with firewalld has improved, it's time to try again. We still have time for F31. I plan to release firewalld 0.7.0 this week. After which I'll submit a Fedora Change for the nftables backend. Thanks for bringing it up. Eric. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Review/Merge Request: tcpcrypt: remove broken firewalld integration
On Fri, Mar 03, 2023 at 11:44:03AM -0500, Eric Garver wrote: > On Mon, Feb 27, 2023 at 12:58:12PM -0500, Eric Garver wrote: > > PR: https://src.fedoraproject.org/rpms/tcpcrypt/pull-request/1 > > > > Bugs: > > - https://bugzilla.redhat.com/show_bug.cgi?id=2159838 (f37) > > - https://bugzilla.redhat.com/show_bug.cgi?id=2095227 (f36) > > > > tl;dr The PR removes firewalld support from the tcpcrypt package. This > > integration appears to have never worked. > > > > Please review and merge. I cannot merge it myself. I will open PRs for > > f38, f37, and f36 after the rawhide change gets merged. > > The rawhide PR was merged. > > I opened PRs for f38, f37, and f36 that still need merged. > > f38: https://src.fedoraproject.org/rpms/tcpcrypt/pull-request/2 > f37: https://src.fedoraproject.org/rpms/tcpcrypt/pull-request/3 > f36: https://src.fedoraproject.org/rpms/tcpcrypt/pull-request/4 bump. These are still not merged and causing issues for users. https://bugzilla.redhat.com/show_bug.cgi?id=1716080#c13 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Review/Merge Request: tcpcrypt: remove broken firewalld integration
PR: https://src.fedoraproject.org/rpms/tcpcrypt/pull-request/1 Bugs: - https://bugzilla.redhat.com/show_bug.cgi?id=2159838 (f37) - https://bugzilla.redhat.com/show_bug.cgi?id=2095227 (f36) tl;dr The PR removes firewalld support from the tcpcrypt package. This integration appears to have never worked. Please review and merge. I cannot merge it myself. I will open PRs for f38, f37, and f36 after the rawhide change gets merged. Thanks. Eric. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review/Merge Request: tcpcrypt: remove broken firewalld integration
On Mon, Feb 27, 2023 at 12:58:12PM -0500, Eric Garver wrote: > PR: https://src.fedoraproject.org/rpms/tcpcrypt/pull-request/1 > > Bugs: > - https://bugzilla.redhat.com/show_bug.cgi?id=2159838 (f37) > - https://bugzilla.redhat.com/show_bug.cgi?id=2095227 (f36) > > tl;dr The PR removes firewalld support from the tcpcrypt package. This > integration appears to have never worked. > > Please review and merge. I cannot merge it myself. I will open PRs for > f38, f37, and f36 after the rawhide change gets merged. The rawhide PR was merged. I opened PRs for f38, f37, and f36 that still need merged. f38: https://src.fedoraproject.org/rpms/tcpcrypt/pull-request/2 f37: https://src.fedoraproject.org/rpms/tcpcrypt/pull-request/3 f36: https://src.fedoraproject.org/rpms/tcpcrypt/pull-request/4 Thanks. Eric. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intent to orphan Python 2
On Thu, Apr 05, 2018 at 10:53:03PM +0200, Fabio Valentini wrote: > On Thu, Apr 5, 2018 at 9:06 PM, James Hogarth wrote: > > > > > > On Thu, 5 Apr 2018, 18:28 Matthew Miller, wrote: > >> > >> On Thu, Apr 05, 2018 at 04:03:24PM +, James Hogarth wrote: > >> > > I'm imagining all those dependent packages _also_ moving to that > >> > > module > >> > Sorry Matthew but I can't see that actually happening at all... > >> > > >> > If they are already leaping to drop python2-* way ahead of the proposed > >> > EOL > >> > of 2020 when there is no extra effort to include the subpackage in their > >> > "normal" koiji+bodhi workflow for the main repos... why would they go to > >> > the extra effort of a special split to do that (no longer simple > >> > subpackage) into a module? > >> > >> Yeah, it would make sense where it's a pure-python python 2 lib, but be > >> quite a pain for packages where python 2 bindings are subpackages. > >> > >> -- > >> Matthew Miller > >> > >> Fedora Project Leader > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > > > Heh just saw this one from a comment on Reddit... > > > > https://bugs.launchpad.net/calibre/+bug/1714107 > > > > Unless Nirik does a "maintainer patch" porting the entire code over himself > > I guess no more Calibre in F30 ;) > > > > "I am perfectly capable of maintaining python 2 myself." > Best laugh I had today. > > > But that's beside the point. > I just wanted to throw in something that I don't quite understand > about this thread: > > If I understand correctly, the original proposal was about > - dropping python2 support and sub-packages only in "fedora > 29" or > "fedora >= 29" (see the original mail in this thread), > - starting from leaf packages, so no unmet dependencies are introduced > during the retirement process. > > According to this, the python2 bindings for firewalld shouldn't have > been dropped from f28 at all, because > - there's still something depending on them (ansible support for > firewalld, still uses python2 on f28), and This dependency is not visible via rpm, because it's on the remote side not the controller side where Ansible is installed. i.e. $ repoquery --whatrequires python2-firewall yields nothing. As such, I missed this indirect dependency. It would be nice if there was a way to express this. Correct me if I'm wrong, but won't this be a nuisance in Ansible for some time? If the controller side (regardless of distro) defaults to invoking python2 on the remote then it will fail on f29+. I guess Ansible has knobs to tell it to use python3 on a set of remotes. Alternatively you can install python3-ansible. My point is, restoring the python2-firewall subpackage for f28 will help targets that are f28. But in f29, the package will definitely be gone and we're still "broken" for many controlling distros including older Fedora releases. > - the change was explicitly about f29+ (and not f28, too). I had dropped the python2-firewall subpackage before this thread was started. > > Please correct me if I am wrong. > > If I am correct though, it looks like the rawhide change to remove the > python2 sub-package from firewalld was mistakenly merged from rawhide > into f28, and should be reverted. I'm not an Ansible user so I don't know how painful it is for the python2-firewall subpackage to be gone. If the majority thinks it should be restored, then we'll bring it back. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Fedocal] Reminder meeting : Prioritized bugs and issues
On Wed, May 19, 2021 at 06:18:21AM -0400, Ben Cotton wrote: > On Tue, May 18, 2021 at 7:00 AM wrote: > > > > You are kindly invited to the meeting: > >Prioritized bugs and issues on 2021-05-19 from 11:00:00 to 12:00:00 > > America/Indiana/Indianapolis > >At fedora-meetin...@irc.freenode.net > > > > More information available at: > > https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process > > > > The following bugs are nominated for Prioritized Bug status: > > * Firewalld Panel Applet not working — > https://bugzilla.redhat.com/show_bug.cgi?id=1791860 I cannot attend the 11:00 EDT time slot. > * Akonadi does not start due to DB failure — > https://bugzilla.redhat.com/show_bug.cgi?id=1953675 > > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
