Hi all,
Per the Fedora Linux 41 schedule [1], we will start a mass rebuild on
2024-07-17 for Fedora 41.
We will be conducting this mass rebuild for the changes listed in:
https://pagure.io/releng/issues?status=Open&tags=mass+rebuild
This mass rebuild will be done in a side tag (f41-rebuild) and merged
when completed.
FTBFS (Fails To Build From Source) bugs will be filed shortly after
the mass rebuild.
Please note that if you need to exclude any packages from the rebuild,
you can use the PKG_SKIP_LIST or add a noautobuild file to the root of
your distgit repository. This will instruct the mass rebuild script to
skip these packages. Previously, some OCaml packages were rebuilt, but
they can now be opted out using this method if required.
If you encounter any bugs or issues in the reporting, please let Releng know.
You can contact us in the #fedora-releng channel on Libera.Chat, the
#releng.org room on Matrix, or emailing our list [2] or file an issue
in pagure [3].
Regards,
Fedora Release Engineering
[1] https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/
Wiki - https://fedoraproject.org/wiki/Changes/EnableDrmPanic
Discussion Thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-enable-drm-panic…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Drm_panic is a new feature in the Linux kernel that displays a panic
screen when a kernel panic occurs. This proposal is to enable
DRM_PANIC in the Fedora kernel, to improve the kernel panic user
experience.
== Owner ==
* Name: [[User:jfalempe| Jocelyn Falempe]], [[User:Javierm| Javier
Martinez Canillas]]
* Email: <jfalempe(a)redhat.com>, <javierm(a)redhat.com>
== Detailed Description ==
When the linux kernel panics in Fedora 40, in most cases, the screen
just freezes.
If you're in a VT console, you'll be able to see the kernel debug
information, but that is pretty hard to understand for users that are
not kernel developers.
With this feature, they will see a message saying the computer has
crashed, and they need to reboot the computer.
Drm_panic has been introduced in kernel v6.10, but is still under
active development.
In order to enable DRM_PANIC, you need to disable VT_CONSOLE in the
kernel, this is to prevent a race condition, that if you are in a VT
console when the panic occurs, both fbcon and drm_panic will write to
the framebuffer at the same time, leading to corrupted output.
https://patchwork.freedesktop.org/series/134831/
The drawback is that tty0 won't show the kernel kmsg, and it can be
harder to debug boot issues. But plymouth already takes care of this,
and can display the boot kmsg when no VT console is present.
https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/224
And the user experience would be better, because plymouth has better
font and color support than fbcon.
Supported drivers are simpledrm, mgag200, ast, (and imx, tidss, on
aarch64). I'm working on nouveau support, and I hope i915 and amdgpu
will add support too.
If the driver is not supported, you won't see the panic screen, but it
won't be worse than what you have today.
Drm panic provides different panic screens. The default is "user"
which will display a simple friendly message telling the user to
reboot the computer. But for kernel developers, you can also set it to
"kmsg", to see the last kmsg lines (so this is equivalent to the
current fbcon). You can select the panic screen in Kconfig, or as a
module parameter (drm.panic_screen=user) or at runtime with "echo -n
kmsg > /sys/module/drm/parameters/panic_screen"
I've also made a proof of concept to add a panic screen with a QR code
with debugging information, which will make it easier for users to
report kernel panic in Fedora. An example can be seen here:
https://github.com/kdj0c/panic_report/issues/1
== Feedback ==
== Benefit to Fedora ==
This change will improve the user experience when a kernel panic occurs.
It's also a first step to switch to userspace console, and being able
to disable CONFIG_VT in the kernel.
VT and fbcon are legacy part of the kernel, that would reduce
maintenance burden if we can disable them, and
It will also reduce CVE impact, as userspace vulnerabilities are
usually less critical.
== Scope ==
* Proposal owners:
Write documentation on how-to debug boot issues without VT_CONSOLE.
Maybe also change the systemd log configuration, so that it default to
writing the log to the console.
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number
I'm unsure if it has impact on the installer.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
I think it perfectly fit the "Fedora is for everyone" goal, as the
current kernel panic (either UI freeze or kmsg output in VT) is not
user-friendly.
== Upgrade/compatibility impact ==
Enabling DRM_PANIC should be transparent to user, but disabling
VT_CONSOLE may have a visible impact.
Fortunately since Fedora 40, plymouth is able to display the kmsg messages.
For non-graphical boot, you can use systemd.log_target=console
systemd.log_level=info and remove rhgb and quiet to see the kernel
boot message.
But this needs to be documented, and communicated, so that users that
debug boot issues, know about this change.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? Y/N
== How To Test ==
Currently the easiest way to test, is to use the simpledrm driver, as
it can run on all hardware. So first blacklist your driver (i915,
amdgpu or nouveau), and then boot and check that you're using
simpledrm.
then you can trigger a kernel panic with:
echo c > /proc/sysrq-trigger
As it will crash your machine, it's also possible to do this in a VM
(so disabling virtio-gpu, or vmwgfx)
Also to check that you can still see the kernel messages at boot, in
the grub menu, remove the "quiet" kernel command argument, and you
should still see the kernel boot messages on the plymouth screen.
== User Experience ==
With DRM panic, users will be notified that their computer crashed,
instead of it being unresponsive.
With v6.10, it's only for a few GPU drivers (simpledrm, mgag200, ast),
but with simpledrm, it will already catch some common kernel panic
cases, like root filesystem not found, or ramdisk corruption.
(simpledrm is used at boot, and is later replaced with
i915/amdgpu/nouveau ...)
It also prepares for future drm panic improvements, like having a kmsg
panic screen, (should be available in v6.11) or also have better
debugging information, using QR code. A test sample is shown at
https://github.com/kdj0c/panic_report/issues/1
== Dependencies ==
The main dependency, is to have a kernel v6.10 or later.
To still see the kernel boot messages, there is also a dependency on
plymouth and systemd, but the versions in F40 are already good.
== Contingency Plan ==
* Contingency mechanism: Revert the kernel configuration changes.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A
== Documentation ==
Kernel Kconfig for DRM_PANIC:
https://elixir.bootlin.com/linux/v6.10-rc7/source/drivers/gpu/drm/Kconfig#L…
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/zstd:chunked
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-default-podman-c…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Modify `podman push`, `buildah push` and `skopeo copy` to default to
creating container images compressed with `zstd:chunked`. Users can
modify `containers.conf` to continue to use the legacy `gzip` image
format.
== Owner ==
* Name: [[User:dwalsh| Daniel J Walsh]]
* Email: dwalsh(a)redhat.com
* Name: [[User:giuseppe| Giuseppe Scrivano]]
* Email: gscrivan(a)redhat.com
== Detailed Description ==
The goal is to speed up the pulling of container images, via using
`zstd:chunked`. `zstd:chunked` format has shown itself to speed up the
pulling of images by as much as 90%. This change has been waiting for
change for over 3 years, waiting for Docker to support the format.
== Feedback ==
It is not possible to directly push container images with both
compression formats. See:
* https://github.com/moby/moby/issues/28394#issuecomment-1822741770
* https://github.com/opencontainers/image-spec/issues/803#issuecomment-745335…
Instead, it should be possible to create a manifest list with
containers in both formats. See the discussion in
https://discussion.fedoraproject.org/t/switch-fedora-container-images-to-su…
for more details.
This change was pushed by mistake to Fedora 41 and Fedora 40 with:
* Fedora 41: https://bodhi.fedoraproject.org/updates/FEDORA-2024-4918af16a3
* Fedora 40: https://bodhi.fedoraproject.org/updates/FEDORA-2024-ab42dd0ffb
This change has been reverted for Fedora 40 in:
* https://bodhi.fedoraproject.org/updates/FEDORA-2024-ebe5c816a1
* https://github.com/coreos/fedora-coreos-tracker/issues/1748
To avoid further disruptions, this change has not been reverted in
Fedora 41 yet. It will be reverted if it is rejected.
This change also impacts all Bootable Container variants of Fedora.
Initial (non-optimized) support for `zstd:chunked` images is available
in rpm-ostree since
[https://github.com/coreos/rpm-ostree/releases/tag/v2024.6 v2024.6].
== Benefit to Fedora ==
Fedora would be the first distribution to support building
`zstd:chunked` format by default. Container engines (Podman, Buildah,
Skopeo, CRI-O) which support the format natively would see a great
speed up in pulling images. Other container engines including Docker
and Containerd would see some speed up do the the compression
algorithms of zstd, but not to the same degree as container engines
with full support.
== Scope ==
* Proposal owners: Dan Walsh, Giuseppe Scrivano
** Switch the default to `zstd:chunked`
* Other developers:
** Test if their containers still work with the new format.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (To Do)
** Verify that the Fedora infra can use `zstd:chunked` container images.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
The following versions of each package have support for `zstd:chunked`:
* podman 5.1
* buildah 1.36
* skopeo 1.15
Moby doesn't support `zstd:chunked` but it handles the container image
as a standard `zstd` layer since Moby 23.0. containerd supports `zstd`
since 1.5.
This change is implemented by updating the
`/usr/share/containers/containers.conf` configuration file to set
`compression_format = "zstd:chunked"` by default.
Users that would like to keep using the existing format can enforce it
with the following commands:
$ sudo install -dm 0755 -o 0 -g 0 /etc/containers/containers.conf.d/
$ echo 'compression_format = "gzip"' | sudo tee
/etc/containers/containers.conf.d/compress-zstd-chunked.conf
== How To Test ==
To test this change, you can create the following config file:
$ sudo install -dm 0755 -o 0 -g 0 /etc/containers/containers.conf.d/
$ echo 'compression_format = "zstd:chunked"' | sudo tee
/etc/containers/containers.conf.d/compress-zstd-chunked.conf
See: https://github.com/containers/common/blob/main/docs/containers.conf.5.md
You can also use the `--compression-format=zstd:chunked` option with
`podman push` or the `--dest-compress-format=zstd:chunked` with
skopeo.
See: https://docs.podman.io/en/latest/markdown/podman-push.1.html
--compression-format=gzip | zstd | zstd:chunked
Specifies the compression format to use. Supported values are: gzip,
zstd and zstd:chunked. The default is gzip unless overridden in the
containers.conf file.
--compression-level=level
Specifies the compression level to use. The value is specific to the
compression algorithm used, e.g. for zstd the accepted
values are in the range 1-20 (inclusive) with a default of 3, while
for gzip it is 1-9 (inclusive) and has a default of 5.
See: https://github.com/containers/skopeo/blob/main/docs/skopeo-copy.1.md
--dest-compress-format format
Specifies the compression format to use. Supported values are: gzip,
zstd and zstd:chunked.
--dest-compress-level format
Specifies the compression level to use. The value is specific to the
compression algorithm used, e.g. for zstd the accepted values are in
the range 1-20 (inclusive), while for gzip it is 1-9 (inclusive).
Then:
* Build and push container images to container registries.
* Inspect them to check that their format is `zstd:chunked`.
* Pull the image back to the host.
* Now make a small change to the image and push it back to the registry.
* Remove the changed image leaving the original image in place.
* Now pull the updated image again.
* You should see a big change in download speed.
* Now attempt to pull the same image with Docker/Moby to make sure the
image works with those container engines.
== User Experience ==
Users should experience a nice improvement in download speeds of
container images that were previously created with `zstd:chunked`.
== Dependencies ==
N/A
== Contingency Plan ==
If we find issues with `zstd:chunked` while turned on in Rawhide, we
can easily reverse direction and go back to the original default
`gzip` format.
All the container images and tags pushed with the `zstd:chunked`
format will have to be pushed again with the `gzip` compression.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Containers are pushed to container registries using the `zstd:chunked` format.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Taskwarrior3
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-taskwarrior-3-se…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Update [https://taskwarrior.org Taskwarrior] to version 3.
== Owner ==
* Name: [[User:Ankursinha| Ankur Sinha "FranciscoD"]]
* Email: ankursinha AT fedoraproject.org
== Detailed Description ==
[https://taskwarrior.org Taskwarrior] is Free and Open Source Software
that manages your TODO list from the command line.
It is flexible, fast, and unobtrusive. It does its job then gets out
of your way.
Taskwarrior version 2 is currently available to Fedora users, and has
been for some time: [https://src.fedoraproject.org/rpms/task task].
[https://github.com/GothenburgBitFactory/taskwarrior/releases/tag/v3.0.0
Taskwarrior version 3] has been recently released, but:
* requires manual migration of user-data to use
* completely changes the mechanism for syncing user data over multiple
machines: it no longer supports [https://src.fedoraproject.org/taskd
Taskserver] and moves to
[https://github.com/GothenburgBitFactory/taskchampion-sync-server
Taskchampion sync server]
Upstream documentation on migrating to Taskwarrior version 3 is
[https://taskwarrior.org/docs/upgrade-3/ here].
Therefore, a traditional package update from Taskwarrior version 2 to
version 3 will not work in this case, since it requires user
intervention and breaks existing user workflows.
This change will include Taskwarrior version 3 in Fedora in a way that
allows users to manually migrate to it, while also providing them the
option to remain on Taskwarrior version 2 as a compat package:
* introduce a task2 compat package in Fedora stable releases
(<code>Fedora <= 40</code>)
* task2 will obsolete <code>task <=2.x</code> in Fedora 39, 40
* update the task package to version 3 in F41
In this way, users currently using task will be seamlessly upgraded to
the task2 package.
When Fedora 41 is released, they will either be able to stay on task2
or manually upgrade to task (v3) after migrating their user data as
required.
(Thanks to Michel and the others on the
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
devel list for suggesting this method]).
== Feedback ==
This was discussed on the
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
devel mailing list], which is where this method of upgrading the
package was suggested.
== Benefit to Fedora ==
Fedora users will be able to use the newest version of the
Taskwarrior, which is what upstream are going to continue maintaining
and improving.
== Scope ==
* Proposal owners:
** create a new compat task2 package in Fedora 39, 40
** update the task package in Fedora 41 to version 3
* Other developers: None
* Release engineering: None (apart from the usual new package creation tasks)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
** the new version of Taskwarrior will make current Fedora users
happy, and perhaps attract new users looking for a good TODO list
manager to Fedora
== Upgrade/compatibility impact ==
Upgrades will not automatically be updated to Taskwarrior version 3.
Users will receive the task2 compat package and will need to manually
update to the version 3 package.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
* no special hardware is required
* on Fedora 39/40, install the task package, use it a few times such
that user config/data files are created
* update system: ensure that task2 is installed and obsoletes the task package
* upgrade to F41 when available: ensure that task2 remains and is not
replaced by task (now version 3)
* back up user data
* manually migrate data as required by upstream before installing task (v3)
* install task (v3) and confirm that it works as expected
== User Experience ==
* Users that use [https://src.fedoraproject.org/taskd taskserver]
should remain on Taskwarrior version 2, since Taskwarrior version 3 no
longer supports it. Taskwarrior version 3 uses
[https://github.com/GothenburgBitFactory/taskchampion-sync-server
Taskchampion sync server] and users will be required to migrate to it.
* Users that use other synchronization methods may upgrade to
Taskwarrior version 3 and take advantage of new features/fixes.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
Upstream documentation on migrating to Taskwarrior version 3 is here:
https://taskwarrior.org/docs/upgrade-3/
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/SelfEncryptingDrivesSupportInAnaconda
Discussion thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-self-encrypting-…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Add optional support for using native hardware encryption on TCG OPAL2
compliant drives when configuring disk encryption in the installer.
== Owner ==
* Name: [[User:vtrefny| Vojtech Trefny]]
* Email: vtrefny AT redhat.com
* Name: [[User:okozina| Ondrej Kozina]]
* Email: okozina AT redhat.com
* Name: [[User:jkonecny| Jiri Konecny]]
* Email: jkonecny AT redhat.com
== Detailed Description ==
Some SATA and NVMe devices support hardware encryption (TCG OPAL2
standard) and with the latest cryptsetup LUKS devices can be
configured to use hardware encryption to encrypt the data either by
itself or together with the existing dm-crypt software encryption.
Support for this feature was added in the latest cryptsetup upstream
release and we'd like to provide an option for users to use this
feature when installing Fedora with disk encryption.
As this is an expert option, it will be available only through the
kickstart interface. The existing --luks-version option which allows
choosing between LUKS1 and LUKS2 versions when configuring device
encryption will be extended to enable using hardware encryption. There
will be two new options to select either hardware encryption only or
hardware encryption in combination with software encryption (analogous
to the `--hw-opal-only` and `--hw-opal` options used when configuring
hardware encryption with `cryptsetup`).
Using hardware encryption only can be beneficial on low-performance
systems where utilising the CPU to encrypt the data when
reading/writing from/to the disk can significantly affect the system's
performance. Using both software and hardware encryption layers
increases the security margin by adding an additional layer of
protection.
Note: We'd like to emphasize that we do not intend to enable this
feature by default, it must be explicitly selected by the user. Using
the option to set up only hardware encryption can be risky as it
places the trust fully in the disk manufacturer's ability to implement
the data encryption in the disk firmware correctly.
== Benefit to Fedora ==
== Scope ==
* Proposal owners:
** This feature is not yet implemented in the upstream so we'll need
to add support for the new LUKS-OPAL format to both the backend
storage libraries (blivet and libblockdev) and the installer itself.
As this is only expanding and existing feature (disk encryption)
already present in the installer, the changes will be relatively small
(especially in the installer itself).
* Other developers:
** No work from other developers should be needed.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
<!-- Does your proposal align with the current Fedora Strategy:
https://discussion.fedoraproject.org/t/fedora-strategy-2028-february-march-…
? It's okay if it doesn't, but it's something to consider -->
== Upgrade/compatibility impact ==
This change will affect only new installations.
== How To Test ==
A special hardware is required for testing -- you need a disk that
supports the OPAL specification. You can check for OPAL support using
the `sedutil-cli` utility (provided by the `sedutil` package), simply
run `sudo sedutil-cli --scan` to scan for OPAL compliant disks.
Because this feature is not configurable from the GUI you need to run
a [[Anaconda/Kickstart|kickstart installation]]. Sample kickstart file
for encrypted automatic partitioning is shown below.
autopart --type=lvm --encrypted --passphrase="passphrase"
--luks-version=luks2-hw-opal --opal-admin-passphrase="..."
(The exact syntax might change, we'll provide more detailed kickstart
files for testing later.)
After the installation check that the correct setup for LUKS was used
by running `sudo cryptsetup luksDump <device>`. Check the `Data
segments` section, it should say either `hw-opal-crypt` for
combination of hardware and software encryption
LUKS header information
Version: 2
...
Data segments:
0: hw-opal-crypt
or `hw-opal` for hardware encryption only
LUKS header information
Version: 2
...
Data segments:
0: hw-opal
(`crypt` is shown for software encryption only which is default behaviour).
== User Experience ==
After the installation users shouldn't notice any differences, the
system will behave in the same way as with "normal" disk encryption.
== Dependencies ==
Following projects needs to be changed for this feature:
[[Anaconda|anaconda]], [[Blivet|blivet]], kickstart, libblockdev. All
necessary changes will be done by the change owners.
cryptsetup with the LUKS-OPAL support is already available in Fedora
41 and no other changes will be needed for the support in the
installer.
Once configured the LUKS-OPAL device works in the same way any other
"normal" LUKS devices work so there is no need to change any other
tools for this feature to work (e.g. unlocking the LUKS-OPAL device
doesn't require special configuration).
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
** No specific contingency plan is needed, we will simply not include
the feature if we fail to implement all the necessary changes in time.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
* cryptsetup 2.7.0 release notes describing the feature:
https://cdn.kernel.org/pub/linux/utils/cryptsetup/v2.7/v2.7.0-ReleaseNotes
* DevConf.cz talk about self-encrypting drives:
https://pretalx.com/devconf-cz-2024/talk/PMLHGN/
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/NetavarkNftablesDefault
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-netavark-nftable…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Netavark should use nftables by default to create/manage the firewall
rules for the Podman containers.
== Owner ==
* Name: [[User:FASAcountName| Paul Holzinger]]
* Email: <pholzing(a)redhat.com>
* Name: Matthew Heon
* Email: <mheon(a)redhat.com>
== Detailed Description ==
Netavark is used by Podman to configure networking for the containers.
It manages interfaces and firewall rules. Currently it uses iptables
by default to create the firewall rules for the containers but it can
also be configured to use nftables (nft). The goal is to switch the
default over to nftables. We also expect a small speed up for the
container start-up times as nftables allows us to batch insert rules
at once which makes it more performant and robust compared to
iptables.
== Feedback ==
== Benefit to Fedora ==
* netavark no longer requires iptables
* all rules are now part of the netavark table so there are less
conflicts with other tools/users who manage firewall rules
* slightly faster container start-up time
== Scope ==
* Proposal owners: Paul Holzinger, Matthew Heon
** Using nftables is already supported in netavark as of version v1.10
(already included in fedora). Set a build option in the specfile to
change the default driver from iptables to nftables
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
The change can be tested by setting the firewall driver to nftables in
containers.conf:
$ sudo mkdir -p /etc/containers/containers.conf.d
$ echo $'[network]\nfirewall_driver="nftables"' | sudo tee
/etc/containers/containers.conf.d/50-netavark-nftables.conf
Changing the firewall driver while you have running containers will
likely cause some conflicting rules so it is best to reboot when this
option is changed.
Now start the containers and make sure the network works as usual. The
rules can be checked with
$ sudo nft list table inet netavark
== User Experience ==
There should no change in behavior for end users unless they manually
messed with the netavark firewall rules.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Keep using iptables as default.
* Contingency deadline: beta freeze
* Blocks release? N/A
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Tomcat10ChangeProposal
Discussion Thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-tomcat-10-1-x-se…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
This change involves upgrading the Apache Tomcat application server
from versions 9.0.x to 10.1.x. This update will enhance the
application server's performance, security, and support for the latest
specifications. The affected packages include tomcat and related
libraries and services that rely on the Tomcat server for web
application deployment and management.
== Owner ==
* Name: [[User:dsoumis| Dimitris Soumis]]
* Email: dsoumis(a)redhat.com
* Name: [[User:csutherl| Coty Sutherland]]
* Email: csutherl(a)redhat.com
* Name: [[User:szappis| Sokratis Zappis]]
* Email: szappis(a)redhat.com
== Detailed Description ==
The proposed migration from Apache Tomcat 9.0.x to 10.1.x in Fedora
releases aims to leverage the improvements and new features
introduced. Tomcat 10.1.x supports the Jakarta EE 10 specification,
which involves a namespace change from javax.* to jakarta.*. This
upgrade will provide better performance, enhanced security features,
and compatibility with modern Java applications. It will impact the
tomcat package and any related libraries and services, requiring
updates to ensure compatibility with the new Jakarta EE namespace and
other changes in Tomcat 10.1.x.
Details of changes introduced in Tomcat 10.1.x:
* Apache Tomcat 10.1.x requires Java 11, or later.
* Specification API Breaking Changes: There is a significant breaking
change between Tomcat 9.0.x and Tomcat 10.1.x. The Java package used
by the specification APIs has changed from javax.* to jakarta.*. It
will be necessary to recompile web applications against the new APIs.
* Other Specification API changes:
** Jakarta Servlet 6.0 API: The Java package has changed from
javax.servlet to jakarta.servlet. A new method,
Cookie.setAttribute(String name, String value) has been added. The
process for decoding and normalizing URIs has been clarified. New
methods and classes have been added to provide access to unique
identifiers for the current request and/or associated connection.
** Jakarta Server Pages 3.1 API: The Java package has changed from
javax.servlet.jsp to jakarta.servlet.jsp. Added an option to raise a
PropertyNotFoundException when an EL expression contains an unknown
identifier.
** Jakarta Expression Language 5.0: The Java package has changed from
javax.el to jakarta.el. The EL API now uses generics where
appropriate. The deprecated MethodExpression.isParmetersProvided()
method has been removed from the API.
** Jakarta WebSocket 2.1: The Java package has changed from
javax.websocket to jakarta.websocket. The packaging of the API JARs
has changed to remove duplicate classes. The server API now has a
dependency on the client API JAR.
** Jakarta Authentication 3.0: The Java package has changed from
javax.security.auth.message to jakarta.security.auth.message.
* Internal Tomcat APIs: Whilst the Tomcat 10 internal API is broadly
compatible with Tomcat 9 there have been many changes at the detail
level and they are not binary compatible. Developers of custom
components that interact with Tomcat's internals should review the
JavaDoc for the relevant API.
* web.xml defaults: conf/web.xml sets the default request and response
character encoding to UTF-8.
* Session management: Session persistence on restart has been disabled
by default. It may be re-enabled globally in conf/context.xml or per
web application.
* HTTP/2: The configuration settings that were duplicated between the
HTTP/1.1 and HTTP/2 connectors have been removed from the HTTP/2
connector which will now inherit them from the associated HTTP/1.1
connector.
* Logging: The logging implementation now only creates log files once
there is something to write to the log files.
* Access Log Patterns: To align with httpd, the %D pattern now logs
request time in microseconds rather than milliseconds. To log request
time in milliseconds, use %{ms}T.
== Feedback ==
No feedback is received.
== Benefit to Fedora ==
This migration ensures that Fedora stays aligned with the latest
standards and best practices in Java-based web server technology. The
enhancements in Tomcat 10.1.x lead to a more robust and secure
application server, providing a stronger foundation for applications
deployed on Fedora. By keeping Fedora's software stack updated, the
distribution maintains its reputation for cutting-edge technology.
Developers will benefit from Tomcat's latest features, improved
support for modern development practices, and better integration with
contemporary tools, making Fedora a more attractive platform for Java
developers. Additionally, staying current with software versions
attracts new contributors and keeps the community engaged. Providing
the latest tools and technologies by default simplifies onboarding and
encourages effective contributions from new participants.
== Scope ==
* Proposal owners: To complete this feature in time for the release,
feature owners need to perform the following tasks:
** Update the tomcat package to the latest 10.1.x version using
upstream sources.
** Ensure that all necessary patches and custom modifications are
applied to maintain compatibility and functionality within the Fedora
ecosystem.
** Update the tomcat-native recommended package to the latest 2.0.x to
ensure compatibility with Tomcat 10.1.x.
This migration is an isolated change, primarily affecting the tomcat
package and does not have an impact on other parts of the
distribution.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with the Fedora Strategy: Yes
== Upgrade/compatibility impact ==
There is a significant breaking change between Tomcat 9.0.x and Tomcat
10.1.x. The Java package used by the specification APIs has changed
from javax.* to jakarta.*. It will be necessary to recompile web
applications against the new APIs. Tomcat can convert an existing web
application from Java EE 8 to Jakarta EE 10 at deployment time using
the Apache Tomcat migration tool for Jakarta EE. To make use of the
feature, the web application should be placed in the Host
legacyAppBase folder (by default named webapps-javaee) and they will
be converted to an equivalent Jakarta EE web application in the Host
appBase folder (by default named webapps). Alternately, the
[https://packages.fedoraproject.org/pkgs/tomcat-jakartaee-migration/tomcat-j…
Apache Tomcat migration tool] for Jakarta EE can be used ahead of time
to benefit from faster deployment time and more precise conversion
configuration options.
When migrating from one major Tomcat version to another (9.0.x ->
10.1.x), users should not copy the configuration files from the old
version to the new version. The recommended approach is to start with
the default configuration of the new version of Apache Tomcat and to
adjust it as necessary.
The Tomcat developers aim for each patch release to be fully backwards
compatible with the previous release. Occasionally, it is necessary to
break backwards compatibility in order to fix a bug. In most cases,
these changes will go unnoticed. This section lists changes that are
not fully backwards compatible and might cause breakage when
upgrading.
* The semantics of the HostConfig.check(String) method have changed.
Rather than marking the application as serviced before calling the
method, the method will mark the application as serviced before
checking resources and then un-mark the application as being serviced
after the checks are complete. If the application is marked as
serviced when the method is called, the method will be a NO-OP.
* As a result of the updated fork of Commons FileUpload now using
java.nio.file.Files, applications using multi-part uploads need to
ensure that the JVM is configured with sufficient direct memory to
store all in progress multi-part uploads.
* The system property org.apache.juli.AsyncLoggerPollInterval is no longer used.
* The default value for the Connector attribute maxParameterCount has
been reduced from 10,000 to 1,000.
* The EL API no longer uses a privileged block to obtain the thread
context class loader unless explicitly configured to do so via the
org.apache.el.GET_CLASSLOADER_USE_PRIVILEGED system property. When
using the EL API within Apache Tomcat this system property does not
need to be set as all calls are already wrapped in a privileged block
further up the stack. It may be required if using the EL API under a
SecurityManager outside of Apache Tomcat.
* The APR connector has been removed. Along with that, APIs that are
not needed for the use of OpenSSL have been removed from the
tomcat-native library.
* Tomcat no longer adds an "Expires" HTTP response header when adding
"Cache-Control: private" due to a CONFIDENTIAL transport-guarantee.
This will likely cause a change in caching behavior for applications
that do not explicitly set their own headers but rely on Tomcat's
previous behavior. If you wish to disable caching, you will need to
configure it explicitly in your application.
== Early Testing (Optional) ==
Early access for the pending change in copr repository:
[https://copr.fedorainfracloud.org/coprs/dsoumis/tomcat/ Development
Tomcat application server]
== How To Test ==
To ensure the successful implementation of the migration from Tomcat
9.0.x to 10.1.x, follow these steps to test the change.
* Ensure your system has the latest Fedora release installed.
* Install the Tomcat package using the following command:
dnf install tomcat
* Develop or obtain a sample web application that uses Jakarta EE APIs.
* Deploy your application by placing your WAR file in the Tomcat
webapps directory:
cp your-application.war /var/lib/tomcat/webapps/
* Start the Tomcat service:
systemctl start tomcat
* Check Tomcat logs to ensure the server is running and the
application has been deployed successfully:
cat /usr/share/tomcat/logs/catalina.*.log
* The Tomcat service should start without errors. You can verify the
status with:
systemctl status tomcat
* The web application should be deployed successfully. You can access
it via a web browser at:
http://localhost:8080/your-application
== User Experience ==
Users will experience better support for modern Java standards as
Tomcat 10.1.x fully supports Jakarta EE 10. This means developers can
leverage the latest APIs and features in their applications, promoting
more efficient and robust application development. Overall, the
upgrade to Tomcat 10.1.x will provide a more powerful, secure, and
developer-friendly environment, enhancing the overall user experience
on Fedora.
== Dependencies ==
Tomcat dependencies:
alsa-lib
apr
copy-jdk-configs
cups-libs
ecj
java-21-openjdk-headless
javapackages-filesystem
javapackages-tools
lksctp-tools
lua
lua-posix
tomcat-el-3.0-api
tomcat-jsp-2.3-api
tomcat-lib
tomcat-servlet-4.0-api
tzdata-java
Tomcat weak dependencies:
tomcat-native
== Contingency Plan ==
Revert the update.
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
[https://tomcat.apache.org/tomcat-10.1-doc/index.html Upstream documentation]
== Release Notes ==
[https://tomcat.apache.org/tomcat-10.1-doc/changelog.html Upstream changelog]
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney