== 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: egarver(a)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 already cooperates with the firewalld nftables backend.
The only thing needed is to test/verify.
*** libvirt already cooperates with the firewalld nftables backend.
The only thing needed is to test/verify.
*** 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
== How To Test ==
Testing should mostly be integration based. Firewalld upstream has a
fairly comprehensive testsuite that covers functional testing.
The following are packages known to integrate with firewalld. They
should be tested with the nftables backend.
** verify VMs with different network types (bridged, routed) have
working network access
** newer version of libvirt should create and use a "libvirt"
firewalld zone. Interfaces should be dynamically added to the zone.
** verify podman adds container bridge interface to the "trusted" zone
** verify container still has network access
** known to not work with the firewalld nftables backend out of the box
** verify new package docker-firewalld installs firewalld docker zone
and has "docker0" interface added
** verify container still has network access
** verify the direct rules added to firewalld by fail2ban still block traffic
== User Experience ==
In general users shouldn't notice the change. Occasional a user will
look at the iptables rule that firewalld generates. They'll now have
to look at nftables instead.
== Dependencies ==
* libvirt >= 5.1.0
* CNI >= 0.8.0 (used by podman)
* docker-firewalld (new package)
== Contingency Plan ==
* Contingency mechanism: firewalld maintainer (erig0) will reinstate
the current patch to default to the iptables backend.
* Contingency deadline: beta freeze
== Documentation ==
* [https://firewalld.org/2018/07/nftables-backend Firewalld blog post]
He / Him / His
Fedora Program Manager
Starting a new thread since the old one is hard to navigate at this point.
Modularity is a distribution-level change and requires some mindset
shift from packagers and users alike. I understand the concerns some
people have, feeling it’s something new and half-baked that is being
forced on them.
We’re an open source community and in order to drive innovation, we
need to be able to try new approaches and technologies in the open,
not develop them without any input and hands-on experience behind
closed doors, later serving them on a silver plate. The feedback we’re
getting is extremely valuable, but some of it is too narrowly focused
on one specific problem area and not taking into account the other
aspects, requirements, or goals that we’re pursuing. Our objective is
still to deliver multiple versions, or variants, of our content across
releases or even distributions (think EPEL or CentOS). And it’s a good
The concept of default streams was introduced to make modularity
invisible to anyone who has no interest in alternatives and wants the
system to operate as it historically has. Whether a specific package
is delivered via a module or not shouldn’t matter. (This does not mean
it should be hidden, just that it should have no practical difference
to the system.) This applies to both buildroots and runtime, leaving
the choice of whether to modularize or not to the maintainer.
Obviously, the implementation is falling short in this regard right
now, but we have solutions in development or under design. This
includes making the default streams available in the non-modular
buildroot via Ursa Prime or tracking the module enablement intent in
our software management stack, as Stephen suggested in the original
While these issues are being resolved, we are considering temporarily
disallowing default streams in Fedora. I don’t want to abandon the
idea completely, as doing so reduces the motivation to actually build
modules and reap the benefits they might provide.
Yes, modularity still has some additional development ahead. We need
to improve the software management stack experience; we need to
revisit our release engineering SOPs; we need to stabilize and boost
performance of our infrastructure; and last but not least, we need to
improve the packager experience, providing more features to make the
creation of modules easier, as well as guidance, best practices and
policies that make it easy to collaborate. These changes are similar
to those for other useful but disruptive technologies that Fedora has
successfully introduced in the past.
I do believe we all intend the best, even if we sometimes disagree. We
currently don’t have any other proposal that would fulfill the vision
of our Objective and the needs of our users. The input here helps us
re-focus on the most acute pain points but the manpower and control we
have is also rather limited. If you want to and can help with the
implementation, I’d like to encourage you to do so.
Hello fellow Python packagers. This is an announcement about a new set of RPM
macros you can use to build PEP 517/518 enabled packages, that is Python
packages that have the pyproject.toml file.
The set of macros is designed for modern packaging with dynamic buildrequires in
The macros are in the pyproject-rpm-macros package and you can use them like this:
See the full documentation of the macros:
See example spec files:
(These use setuptools (setup.py), flit and poetry for build backends, but you
cannot tell that from the specfiles - BuildRequires are generated dynamically
from upstream metadata.)
The macros are **provisional**, i.e. their API may be changed upon feedback
received from you.
We are not (yet) interested in a general "update all the Python packages" hunt,
but rather in early adopters.
If you have questions, ask here. We'll gladly extend the docs if something is
If you find bugs, report them in bugzilla or here. Likewise for RFEs.
I'm hoping that this one hasn't been dead for 8 weeks, because all it needs
to get it building again is to disable the gtk-doc generation...
I don't really want to own it, but I have dependent packages, so if no one
else does, I will claim it.
If you want it (or know of some reason it shouldn't be brought back),
please speak up.
Right now, there are two conflicting requirements in Fedora Modularity
that we need to resolve.
1. Once a user has selected a stream, updates should follow that
stream and not introduce incompatiblities. Selected streams should not
be changed without direct action from the user.
2. So far as possible, Modularity should be invisible to those who
don't specifically need it. This means being able to set default
streams so that `yum install package` works for module-provided
Where this becomes an issue is at system-upgrade time (moving from
Fedora 30->31 or continuously tracking Rawhide). Because of
requirement 1, we cannot automatically move users between streams, but
in the case of release upgrades we often want to move to a new default
for the distribution.
The Modularity WG has generally agreed that we want and need to
support behavior of the following use-cases:
Use Case 1:
On Fedora 30, user Alice runs
yum install Foo
The package "Foo" is provided by a module "foo" with a default stream
"v1.0". Because it's available in a default stream, the package is
installed and the module stream "foo:v1.0" is implicitly enabled for
Fedora 31 is released. On Fedora 31, the module "foo" has a new
default stream "v1.1". When upgrading from Fedora 30 to Fedora 31,
Alice expects the package Foo she installed to be upgraded to version
1.1, because that's what would have happened if it was provided as a
package from the non-modular repositories.
Use Case 2:
On Fedora 30, user Bob runs
yum enable foo:v1.0
In this case, the "v1.0" stream of the "foo" module has a dependency
on the "v2.4" stream of the "bar" module. So when enabling "foo:v1.0",
the system also implicitly enables "bar:v2.4".
Fedora 31 is released. On Fedora 31, the module stream "foo:v1.0" now
depends on "bar:v2.5" instead of "bar:v2.4". The user, caring only
about "foo:v1.0" would expect the upgrade to complete, adjusting the
dependencies as needed.
At Flock and other discussions, we've generally come up with a
solution, but it's not yet recorded anywhere. I'm sending it out for
wider input, but this is more or less the solution we intend to run
with, barring someone finding a severe flaw.
What happens today is that once the stream is set, it is fixed and
unchangeable except by user decision. Through discussions with UX
folks, we've more or less come to the decision that the correct
behavior is as follows:
* The user's "intention" should be recorded at the time of module
enablement. Currently, module streams can exist in four states:
"available, enabled, disabled, default". We propose that there should
be two additional states (names TBD) representing implicit enablement.
The state "enabled" would be reserved for any stream that at some
point was enabled by name. For example, a user who runs `yum install
freeipa:DL1` is making a conscious choice to install the DL1 stream of
freeipa. A user who runs `yum install freeipa-client` is instead
saying "give me whatever freeipa-client is the default".
* The state `dep_enabled` would be set whenever a stream becomes
enabled because some other module stream depended on it. This state
must be entered only if the previous state was `default` or
`available`. (We don't want `enabled` or `disabled` streams being able
to transition to this state.)
* The state `default_enabled` would be set whenever a stream becomes
enabled because a transaction pulled in a package from a default
stream, causing it to be enabled. This state must only be entered if
the previous state was `default` or `dep_enabled`. We don't want
`enabled` or `disabled` to be able to transition to `default_enabled`.
If a user requests installation of a package provided by a stream
currently in the `dep_enabled` state, that stream should transition to
the `default_enabled` state (meaning that now the user would expect it
to be treated the same as any other default-enabled stream).
* When running `dnf update`, if a module stream's dependency on
another module changes to another stream, the transaction should cause
that new stream to be enabled (replacing the current stream) if it is
in the `dep_enabled` state.
When running `dnf update` or `dnf system-upgrade`, if the default
stream for a module installed on the system changes and the module's
current state is `default_enabled`, then the transaction should cause
the new default stream to be enabled.
* If stream switching during an update or upgrade would result in
other module dependency issues, that MUST be reported and returned to
This requires some constraints to be placed on default and dependency changes:
* Any stream upgrade such as this must guarantee that any artifacts of
the stream that is exposed as "API" MUST support RPM-level package
upgrades from any previous stream in this stable release. (Example:
"freeipa:DL"1 depends on a the "pki-core:3.8" stream at Fedora 30
launch. Later updates move this to depending on "pki-core:3.9" and
even later "pki-core:3.10". In this case the packages from
"pki-core:3.10" must have a safe upgrade path from both "pki-core:3.8"
and "pki-core:3.9" since we cannot guarantee or force our users to
update regularly and they might miss some of the intermediate ones.
I would like to introduce a plan I call Square 1 
There are two goals to Square 1.
The first is to get, and keep, the core buildroot packages, self-hosting.
The second is to get the list of core buildroot packages as small as possible.
What are the benefits to Square 1?
More stable release and less failed builds.
If we are able to shrink binaries, faster koji builds.
Smoother initial creation of RHEL 9.
What are the milestones to get these benefits?
- Get initial list of "core binaries"
- write/find software that will find binary/source dependencies
- write/find software that will track binary/source dependencies
- write/find/setup automation that finds and tracks binary/source
dependencies, so people can easily see what has changed over time.
- work with package maintainers to trim down binary/source dependencies
-- trimming out "extra" package languages. (ex: perl for a
minor script, when everything is in python.)
-- trimming functionality and/or moving functionality to sub-packages
or separate package.
- integrate these tests into the rawhide gating system, to alert when
new dependencies have been added.
Much of this work overlaps with the Fedora Minimization efforts.
Square 1 hopes to utilize, rather than duplicate, their efforts. And
maybe some tools created for Square 1 can help the minimization
 - Square 1 is at the heart of Ring Zero
 - This has nothing to do with the company or software with a
similar sounding name.
 - The core buildroot is the packages in @buildsys-build, and
everything needed to build those packages.
 - self-hosting is the ability to build all the packages on themselves.
 - Yep, I said it. We're already looking at RHEL 9.
 - https://docs.fedoraproject.org/en-US/minimization/
Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
2.0.0 to libdav1d.so.3.0.0.
I will be updating it next week on F31/32, consumers of these libraries
(ffmpeg, xine-lib, vlc) will need to rebuild their packages.