F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/CompressKernelFirmware
== Summary ==
Compress Kernel Firmwares to reduce on disk size
== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: [mailto:pbrobinson@fedoraproject.org| pbrobinson(a)fedoraproject.org]
== Detailed Description ==
Since the linux 5.3 kernel there has been support for loading firmware
from xz compressed firmware. The upstream linux-firmware respository
is now over 900Mb, not including other kernel firmware that are in
Fedora but come from other sources. By compessing the firmware with
"xz -C crc32", the only option currently supported in the kernel, we
can reduce the ondisk size of the firmware by almost half.
== Benefit to Fedora ==
Reduced on disk size of the firmware used by the kernel.
== Scope ==
* Proposal owners:
** Add support upstream to the linux-firmware copy-firmware script to
compess the firmware and create the symlinks to the compressed
firmware
** Enable the upstream support in the Fedora linux-firmware package to
compress the firmware at build time
** Enable compressing firmware in packages that contain firmware used
by the kernel: eg alsa-sof-firmware, atmel-firmware, zd1211-firmware
** Enable the CONFIG_FW_LOADER_COMPRESS kernel option (long complete)
* Other developers:
** No impact
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
There should be no upgrade impact, the support was added to the
generic firmware loader interface in the kernel.
== How To Test ==
Check devices that need firmware still work. Some devices that need
firmware include:
* GPU drivers such as nvidia, AMD and i915
* Wireless drivers such as those from Intel, Broadcom/Cyprus, TI,
Qualcomm and Marvel
* Wired network interfaces
* Storage drivers
* USB controllers and drivers
== User Experience ==
Generally users should notice little to no difference.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Don't compress kernel firmware
* Contingency deadline: GA
* Blocks release? No.
* Blocks product? No.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
N/A
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
5 months, 3 weeks
The future of legacy BIOS support in Fedora.
by Jóhann B. Guðmundsson
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
it beg the question if now would not be the time to stop supporting
booting in legacy bios mode and move to uefi only supported boot which
has been available on any common intel based x86 platform since atleast
2005.
Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class 3
and above as in it would remove legacy BIOS support from its client and
datacenter platforms by 2020 and one might expect AMD to follow Intel in
this regard.
So Intel platforms produced this year presumably will be unable to run
32-bit operating systems, unable to use related software (at least
natively), and unable to use older hardware, such as RAID HBAs (and
therefore older hard drives that are connected to those HBAs), network
cards, and even graphics cards that lack UEFI-compatible vBIOS (launched
before 2012 – 2013) etc.
This post is just to gather feed back why Fedora should still continue
to support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead.
Share your thoughts and comments on how such move might affect you so
feedback can be collected for the future on why such a change might be
bad, how it might affect the distribution and scope of such change can
be determined for potential system wide proposal.
Regards
Jóhann B.
1.
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
6 months
Fedora 33 blocker status
by Ben Cotton
We've branched, so let's start the weekly blocker status email yayyyyy
Action summary
====================
Accepted blockers
-----------------
1. libreport — abrt-server errors when processing zstd compressed core
dumps produced by systemd-246~rc1-1.fc33 — POST
ACTION: abrt maintainers to make a new release containing the fix
2. resteasy — FreeIPA deployment fails in current Rawhide due to
various issues with Java 11 — NEW
ACTION: resteasy maintainers to diagnose issue and fix or pass the
buck as appropriate
3. sddm — login stuck when changing users repeatedly (log out, log in
a different one) — NEW
ACTION: sddm maintainers to diagnose issue and fix or pass the buck as
appropriate
4. selinux-policy — SELinux is preventing systemd-machine from
'create' accesses on the sock_file io.systemd.Machine. — POST
ACTION: selinux-policy maintainers to make a new release containing the fixes
5. tomcat — FreeIPA server deployment fails in
Fedora-Rawhide-20200714.n.0 — MODIFIED
ACTION: tomcat maintainers to investigate failed upgrade test
Proposed blockers
-----------------
1. gnome-shell — Network manager started stuck when I tries connecting
to VPN (openconnect) after upgrade gnome-shell to 3.37.1-1.fc33
version — NEW
ACTION: gnome-shell maintainers to diagnose issue
2. systemd — systemd-resolved.service not work with DNS server placed
behind VPN (openconnect) — NEW
ACTION: systemd maintainers to diagnose issue
3. udisks2 — zram-setup(a)zram0.service: Failed to load configuration:
No such file or directory — NEW
ACTION: Someone! to figure out why udisks2-zram gets pulled in
Bug-by-bug detail
=============
Accepted blockers
-----------------
1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — POST
abrt-server errors when processing zstd compressed core dumps produced
by systemd-246~rc1-1.fc33
abrt doesn't support core dumps compressed with zstd, which is now
used by systemd. Merged upstream PR uses libarchive to add support for
zstd (and other compression formats):
https://github.com/abrt/libreport/pull/656.
2. resteasy — https://bugzilla.redhat.com/show_bug.cgi?id=1866570 — NEW
FreeIPA deployment fails in current Rawhide due to various issues with Java 11
Deploying FreeIPA fails with a traceback in pki-tomcat. This appears
to be a dependency chain issue that (currently) ends at resteasy via
dogtag-pki. This may not be the last layer in the Java 11 onion.
3. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=1861700 — NEW
login stuck when changing users repeatedly (log out, log in a different one)
This is now a blocker based on a recent approval-in-principle of a
release criterion related to logout and user switching. User processes
linger after logout which blocks logging in when another user has
logged in between the two sessions. Or when the second user logs back
in. Or when a single user logs in repeatedly. Using
KillUserProcesses=Yes helps the first problem, but raises on of its
own. It appears to be a race condition of some kind as the behavior is
not fully consistent.
4. selinux-policy — https://bugzilla.redhat.com/show_bug.cgi?id=1862686 — POST
SELinux is preventing systemd-machine from 'create' accesses on the
sock_file io.systemd.Machine.
librvirt VMs and systemd-machined service fail with AVC denials.
Merged upstream PRs should fix the denials mentioned in this bug:
https://github.com/fedora-selinux/selinux-policy/pull/405 and
https://github.com/fedora-selinux/selinux-policy/pull/407
5. tomcat — https://bugzilla.redhat.com/show_bug.cgi?id=1857043 — MODIFIED
FreeIPA server deployment fails in Fedora-Rawhide-20200714.n.0 due to
pki-tomcat failing to run with "java.lang.ClassNotFoundException:
org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource"
An upstream commit resulted in tomcat-coyote.jar missing packages. A
previous fix (FEDORA-2020-f897a68801) moved the goalposts.
tomcat-9.0.37-3 should fix this. Verification is blocked on BZ1866570,
but Adam's most recent upgrade test still fails with a
ClassNotFoundException for
com.sun.xml.internal.bind.v2.ContextFactory.
Proposed blockers
-----------------
1. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=1830343 — NEW
Network manager started stuck when I tries connecting to VPN
(openconnect) after upgrade gnome-shell to 3.37.1-1.fc33 version
Connecting to an OpenConnect VPN using 2FA hangs after the second
factor is entered. The journal contains an array.toString() message
which may or may not be a red herring (it looks like a deprecation
warning).
2. systemd — https://bugzilla.redhat.com/show_bug.cgi?id=1863041 — NEW
systemd-resolved.service not work with DNS server placed behind VPN
(openconnect)
When connected to an OpenConnect VPN, host name resolution fails.
Manually disabling the systemd-resolved service works around this
issue.
3. udisks2 — https://bugzilla.redhat.com/show_bug.cgi?id=1861463 — NEW
zram-setup(a)zram0.service: Failed to load configuration: No such file
or directory
Installation on armhfp and aarch64 single-board computers fails with
zram-setup errors. It appears to be a conflict betwen udisks2-zram and
zram-generator-defaults. Update FEDORA-2020-e143a283fb renamse the
service unit file to make its origin more obvious. Removing
udisks2-zram fixes the issue, but it's pulled in as a dependency of
something, so that needs to be identified.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
6 months, 1 week
CPE Weekly: 2020-09-20
by Aoife Moloney
Hi Everyone,
Below is this week's CPE weekly for week ending 2020-09-20.
I found that if you want to skip to the hackmd, you can use the view
link https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view and then use the
header bar on your left to skip to either the Fedora or CentOS
updates, whichever interest you.
I'll also be adjusting these updates in the coming weeks to make them
a bit more direct to consume. Thanks for giving me this feedback in
the CPE survey, I want to deliver value to you all, so it's great to
KNOW what you find valuable first hand :)
# CPE Weekly: 2020-08-14
## General Project Updates
As a reminder, below are the projects the CPE team are working on for
the months of July, August & September:
* Data Centre Move - Final Works
* CentOS Stream Phase 3
* Noggin Phase 3
* Packager Workflow Healthcare
* Fedora Messaging Schemas
We have recently held our Q4 planning session and the CPE review team,
Fedora, CentOS and RHEL BU have voted the following projects for
action in Q4, which is the months of October November & December:
* OSBS for aarch64
* Fedora-messaging schemas
We are continuing to work on CentOS Stream and Noggin and took these
projects as confirmed when looking at what other work our team could
realistically complete in the Q4 period, given that there's both
Thanksgiving and Christmas time off to consider, plus any time off our
team wishes to take.
The taiga cards of Noggin, CentOS Stream, OSBS for aarch64 and
fedora-messaging schemas will be updated next week with what our team
hopes to deliver in the next quarter on each of the projects.
Our project board is here (it's just not updated properly - yet)
https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null
### Misc
#### GitLab
Thank you so much to everyone for adding your questions to the doc for
the GitLab AMA session on Thursday 10th September, and for your
attendance on the day during the call.
Here is the full AMA transcript
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session...
however it is a bit confusing to read so we got a few great
suggestions to have dedicted topics like Message Bus and Branching,
etc go out to the devel lists to discuss. I'm happy to start this next
week, but I will collect the questions related to each topic and
propose a cadence to send them out first to discuss, so people dont
miss mails and know the week ending 2nd October will be (for example)
the topic of Group Permissions - What do you think?
GitLab have also agreed to answer the questions, we have asked them to
do so within 2 weeks of the AMA so as soon as this is complete I will
let you know so you can read through them on the hackmd link.
The link is here where we asked you to contribute your questions and I
will be posting answers once we have them underneath
https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
I really appreciate your involvement with this as we begin to dig
deeper into how this might play out next year and what way it should
for everyone's benefit.
## Project Updates
*The below updates are pulled directly from our CPE team call we have
every week.*
## Fedora
### General
* 6 of 8 Beta-blockers have fixes for F33 beta
* New release of fedscm_admin
* FMW mac and windows binaries are signed
### Staging Environment
* About 70% done installing vm’s (27 left out of 88)
* Still need to bring up aarch64/armv7/ppc64le builders
* Databases need syncing
### AAA Replacement
* The team are working on testing Ipsilon in Staging and adding OpenID
Connect Capability
* they are also testing fas2ipa migration script in tiny-stage and improve it
* Add Noggin to tiny-stage environment and test
* The teams kanban board where they track their work can be found here
https://github.com/orgs/fedora-infra/projects/6
### Fedora Messaging Schemas
* This project is on hold until Noggin completes.
* It will be resumed around December timeframe and is part of our Q4
workload to complete
* There is a list of applications that require messaging schemas can
be found here https://hackmd.io/@nilsph/H1i8CAbkP/edit
* There is a readme which contains documentation on messaging schemas,
a cookie-cutter template to create the schema and a definition of Done
for writing a schemas
https://github.com/fedora-infra/fedora-messaging-schemas-issues
* The board they are working from can be viewed here
https://github.com/orgs/fedora-infra/projects/7
### Packager Workflow Healthcare
* The team have been working on more improvements and fixes to the
monitor-gating
* These improvements have led to
* Finding a bug in our testing script
* Improved log messages
* We actually caught a problem! :)
* The data the team have been reviewing have been from April - July
and have already discovered that so far it looks like Pagure, koji and
bodhi work well
* We see some intermittent problems, but nothing too big, mostly
only spikes in runtime
* Fedora CI still looks like a POC, but functional
* Our test-script hitting timeouts/failing 10% of the time
* Gating (greenwave/resultsdb/waiverdb) looks functional, but
relies on CI and doesn't have as much packages going through the
workflow
* A more formal report will be published soon as part of the project
deliverable so keep an eye on their work!
* The teams work is being tracked here
https://teams.fedoraproject.org/project/cpe-cicd/kanban
## CentOS Updates
### CentOS
* Deployed new 4.5.9 openshift cluster for Stream
* The team provisioned EC2 infra for team responsible for
registry.centos.org (we don’t maintain it, so just providing infra,
like Fedora does for Copr)
* They also migrated a bunch of nodes to the new Ansible CI inventory
### CentOS Stream
* Using Openshift cluster for engineering work and will be using it to
deploy & test mbbox in our infra
* Scoping and refining work for October November & December
## Team Info
### Changes to CPE Product Owner Office Hours
Following the feedback received in the CPE survey, I will be reducing
my IRC office hours to once per month.
#### #fedora-meeting-1
* Next Meeting: 2020-10-15 @ 1300 UTC on #fedora-meeting-1
#### #centos-meeting
* Next Meeting: 2020-10-13 @ 1500 UTC on #centos-meeting
## Background:
The Community Platform Engineering group, or CPE for short, is the Red
Hat team combining IT and release engineering from Fedora and CentOS.
Our goal is to keep core servers and services running and maintained,
build releases, and other strategic tasks that need more dedicated
time than volunteers can give.
See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/
As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.
Have a great week!
Aoife
Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
6 months, 1 week
Unresponsive packagers: ekulik, imcleod and lsun
by Pierre-Yves Chibon
Good Morning Everyone,
Since September 5th, we have been emailing daily the following users to notify
that the email they have set in FAS does not correspond to a valid bugzilla
account.
This is a requirement for Fedora packagers.
Does someone know how to contact these people?
ekulik is main admin of modules/pg-semver
ekulik has a bugzilla override on modules/pg-semver
ekulik is maintainer of rpms/abrt
ekulik is maintainer of rpms/abrt-addon-python3
ekulik is maintainer of rpms/abrt-java-connector
ekulik is maintainer of rpms/abrt-server-info-page
ekulik is maintainer of rpms/container-exception-logger
ekulik is maintainer of rpms/gnome-abrt
ekulik is maintainer of rpms/libreport
ekulik is maintainer of rpms/meson
ekulik is maintainer of rpms/pg-semver
ekulik is maintainer of rpms/python-ratelimitingfilter
ekulik is main admin of rpms/python-satyr
ekulik is maintainer of rpms/python-testing.postgresql
ekulik is main admin of rpms/reportd
ekulik is maintainer of rpms/retrace-server
ekulik is maintainer of rpms/satyr
ekulik is maintainer of rpms/will-crash
ekulik is main admin of rpms/winetricks
ekulik has a bugzilla override on rpms/winetricks
imcleod is maintainer of rpms/VMDKstream
imcleod has a bugzilla override on rpms/VMDKstream
imcleod is main admin of rpms/imagefactory
imcleod has a bugzilla override on rpms/imagefactory
imcleod is main admin of rpms/imagefactory-plugins
imcleod has a bugzilla override on rpms/imagefactory-plugins
imcleod is maintainer of rpms/oz
imcleod is maintainer of rpms/python-cloudservers
imcleod is maintainer of rpms/python-prettytable
imcleod is maintainer of rpms/python-psphere
imcleod has a bugzilla override on rpms/python-psphere
imcleod is main admin of rpms/python-pyrax
imcleod has a bugzilla override on rpms/python-pyrax
lsun is main admin of rpms/rshim
lsun has a bugzilla override on rpms/rshim
Thanks for your help,
Pierre
6 months, 1 week
Reproducible builds/bootstrap
by Pablo Greco
I'm starting to work on a project to make Fedora fully reproducible and bootstrappable from scratch.
I know it is a long term plan and still working on the steps, but it would be good to know the current status, if there is an internal interest in this, if someone is already working (or planning to).
Thanks for the info.
Pablo
6 months, 1 week
F34 Change proposal: DNS Over TLS (System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DNS_Over_TLS
== Summary ==
Fedora will attempt to use DNS over TLS (DoT) if supported by
configured DNS servers.
== Owner ==
* Name: [[User:catanzaro|Michael Catanzaro]]
* Email: <mcatanzaro(a)redhat.com>
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: <zbyszek(a)in.waw.pl>
== Detailed Description ==
We will build systemd with `-Ddefault-dns-over-tls=opportunistic` to
protect DNS queries against passive network attackers. An active
network attacker can trivially subvert this protection, but we cannot
make DoT mandatory because other operating systems do not do so and
many (or most?) DNS servers do not support it. DoT will only be used
if the configured DNS server supports it and if it is not blocked by
an active network attacker.
Note that DoT is different from DNS over HTTPS (DoH). In particular,
DoT is not an anti-censorship tool like DoH. It does not look like
regular HTTPS traffic, and it can be blocked by network administrators
if desired, so it should not be a problem for corporate networks.
== Benefit to Fedora ==
DNS queries are encrypted and private by default, if the user's ISP
supports DoT. Most probably don't, but users who manually configure a
custom DNS server (e.g. Cloudflare or Google) will automatically
benefit from DNS over TLS.
== Scope ==
* Proposal owners: change meson flags in systemd.spec
* Other developers: N/A (nothing should be required)
* Release engineering: [https://pagure.io/releng/issue/9772 #9772] (a
check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (nothing should be required)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Nope
== Upgrade/compatibility impact ==
DoT will be enabled automatically on upgrade to F34. If DoT is
unsupported, systemd-resolved will fall back to unencrypted DNS, so
there should be no compatibility impact.
== How To Test ==
Load any website in a web browser. If you succeed, then name
resolution probably works.
Try using `resolvectl query fedoraproject.org` to see that resolvectl
still works.
Bonus points: set your DNS server to 1.1.1.1 or 8.8.8.8, then use
Wireshark to see if your DNS is really encrypted or not.
== User Experience ==
Users should not notice any difference in behavior.
== Dependencies ==
No dependencies.
== Contingency Plan ==
* Contingency mechanism: revert the change
* Contingency deadline: can be done at any time, before F34 beta
freeze would be best
* Blocks release? No
* Blocks product? No
== Documentation ==
See the section `DNSOverTLS=` in the manpage `resolved.conf(5)`
== Release Notes ==
systemd-resolved now enables DNS over TLS (DoT) support by default, in
opportunistic mode. DoT will be used only if supported by your DNS
server, and provides only best-effort encryption to protect against
passive network observers. For compatibility with existing DNS
servers, systemd-resolved will fall back to unencrypted DNS if DoT
does not appear to be supported, reducing the security benefit. If you
wish to manually configure systemd-resolved to prevent fallback to
unencrypted DNS, set `DNSOverTLS=yes` in `/etc/systemd/resolved.conf`.
Note that DoT is different than DNS over HTTPS (DoH) in that it does
not use HTTPS and is therefore easy to distinguish from HTTPS traffic.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
6 months, 2 weeks
Fedora 33 System-Wide Change proposal: systemd-resolved
by Ben Cotton
https://fedoraproject.org/wiki/Changes/systemd-resolved
== Summary ==
Enable systemd-resolved by default. glibc will perform name resolution
using nss-resolve rather than nss-dns.
== Owner ==
* Name: [[User:catanzaro| Michael Catanzaro]]
* Email: <mcatanzaro(a)redhat.com>
== Detailed Description ==
We will enable systemd-resolved by default.
# We will change the
[https://src.fedoraproject.org/rpms/fedora-release/blob/f4cc5b6ce095bb4233...
fedora-release presets] to enable systemd-resolved instead of disable
it.
# systemd-libs currently has
[https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8e...
a %post scriplet] to enable nss-myhostname and nss-systemd by either
(a) modifying authselect's user-nsswitch.conf template, if authselect
is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We
will work with the systemd maintainers to enable nss-resolve here as
well.
# We will work with the authselect maintainers to update authselect's
minimal and nis profiles to enforce nss-resolve. These profiles modify
the hosts line of /etc/resolv.conf. (By default, Fedora uses
authselect's sssd profile, which does not modify the hosts line and
therefore does not have this problem.)
# We will remove our downstream patch to systemd that prevents systemd
from symlinking /etc/resolv.conf to
/run/systemd/resolve/stub-resolv.conf on new installs. For system
upgrades, a systemd-libs %post scriptlet will be used to reassign the
symlink during upgrade. Upon detecting this symlink, NetworkManager
will automatically enable its systemd-resolved support and configure
split DNS as appropriate.
systemd-resolved has been enabled by default in Ubuntu since Ubuntu
16.10, but please note we are doing this differently than Ubuntu has.
Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional
nss-dns provided by glibc upstream, so glibc on Ubuntu continues to
read /etc/resolv.conf, as is traditional. This extra step is not
useful and not recommended by upstream. We want to follow upstream
recommendations in using nss-resolve instead.
If you do not wish to use systemd-resolved, then manual intervention
will be required to disable it:
* Modify /etc/authselect/user-nsswitch.conf and remove `resolve
[!UNAVAIL=return]` from the hosts line. Run `authselect
apply-changes`. (If you have disabled authselect, then edit
/etc/nsswitch.conf directly.)
* Disable and stop systemd-resolved.service.
* Restart the NetworkManager service. NetworkManager will then create
a traditional /etc/resolv.conf. (If you are not using NetworkManager,
you may create your own /etc/resolv.conf.)
== Benefit to Fedora ==
=== Standardization ===
Fedora will continue its history of enabling new systemd-provided
services whenever it makes sense to do so. Standardizing on upstream
systemd services is beneficial to the broader Linux ecosystem in
addition to Fedora, since standardizing reduces behavior differences
between different Linux distributions. Sadly, Fedora is no longer
leading in this area. Ubuntu has enabled systemd-resolved by default
since Ubuntu 16.10, so by the time Fedora 33 is released, we will be
three years behind Ubuntu here.
=== resolvectl ===
`resolvectl` has several useful functions (e.g. `resolvectl status` or
`resolvectl query`) that will be enabled out-of-the-box.
=== Caching ===
systemd-resolved caches DNS queries for a short while. This can
[https://gitlab.gnome.org/GNOME/glib/-/merge_requests/682#note_441846
dramatically] improve performance for applications that do not already
manually cache their own DNS results. (Generally, only web browsers
bother with manually caching DNS results.)
=== Split DNS ===
When systemd-resolved is enabled, users who use multiple VPNs at the
same time will notice that DNS requests are now sent to the correct
DNS server by default. Previously, this scenario would result in
embarrassing "DNS leaks" and, depending on the order that the VPN
connections were established, possible failure to resolve private
resources. These scenarios will now work properly. For example,
consider the scenario of Distrustful Denise, who (quite reasonably)
does not trust her ISP. Denise uses a public VPN service,
public-vpn.example.com, to hide her internet activity from her ISP,
but she also needs to use her employer's corporate VPN,
corporation.example.com, in order to access internal company resources
while working from home. Using the Network panel in System Settings,
Denise has configured her employer's VPN to "use this connection only
for resources on its network." Distrustful Denise expects that her
employer's VPN will receive all traffic for corporation.example.com,
and no other traffic. And while this mostly works in Fedora 32, she
discovers that it does not work properly for DNS:
* If Denise connects to public-vpn.example.com first and
corporation.example.com second, she is unable to access internal
company resources. All DNS requests are sent to
public-vpn.example.com's DNS server, so she is unable to resolve names
for internal company websites.
* If Denise connects to corporation.example.com first and
public-vpn.example.com second, then she is able to access internal
company resources. However, it only works because ''all'' her DNS
requests are sent to corporation.example.com's DNS server. Sadly for
Distrustful Denise, her employer discovers that she has been making
some embarrassing DNS requests that she had expected to go through
public-vpn.example.com instead.
Whichever VPN Denise connects to first receives all DNS requests
because glibc's nss-dns module is not smart enough to split the
requests. /etc/resolv.conf is just a list of DNS servers to try in
order, and NetworkManager has no plausible way to decide which to list
first, because both ways are broken, so it just prefers whichever was
connected first. And if one server fails to respond, then the next
server in the list will be tried, likely resulting in a DNS leak. In
contrast, when systemd-resolved is enabled, it will send each DNS
request only to the correct DNS server. The DNS server that will be
used for each tun interface can be inspected using the resolvectl
tool.
Migrating away from /etc/resolv.conf will also avoid an annoying
footgun with this legacy file: only the first three listed nameservers
are respected. All further nameservers are silently ignored.
NetworkManager adds a warning comment when writing more than three
nameservers to this file, but it cannot do any better than that.
=== DNS over TLS ===
systemd-resolved supports DNS over TLS (different from DNS over
HTTPS). Although this feature will not initially be enabled by
default, using systemd-resolved will enable us to turn on DNS over TLS
in a future Fedora release, providing improved security if the user's
DNS server supports DNS over TLS.
== Scope ==
* Proposal owners: We will update Fedora presets to enable
systemd-resolved by default.
* Other developers: This change requires coordination with the systemd
and authselect maintainers.
* Release engineering: [https://pagure.io/releng/issue/9367 #9367]
* Policies and guidelines: none required
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
systemd-resolved will be enabled automatically when upgrading to
Fedora 33. After upgrade, /etc/resolv.conf will be managed by systemd
and symlinked to /run/systemd/resolve/stub-resolv.conf. '''glibc will
no longer look at /etc/resolv.conf when performing name resolution.'''
Instead, glibc will communicate directly with systemd-resolved via
nss-resolve. systemd adds a large warning comment to the top of
/etc/resolv.conf to warn system administrators that changes to this
file will be ignored; however, scripts that edit this file manually
will break. Because this file is usually managed by NetworkManager,
impact to Fedora users will be limited to users who have manually
disabled NetworkManager; such users are expected to be experienced
system administrators who should be comfortable adapting to the change
(or disabling systemd-resolved).
Any applications that bypass glibc and read /etc/resolv.conf directly
will still work because /etc/resolv.conf will point to
systemd-resolved's stub resolver running on 127.0.0.53. Nevertheless,
/etc/resolv.conf is provided only for compatibility purposes, and
applications should prefer to use either glibc or the systemd-resolved
D-Bus API instead; see systemd-resolved(8) for details.
In short, '''applications that read /etc/resolv.conf will continue to
work as before.''' Applications that write to it will no longer work
as expected, but this only previously worked if NetworkManager is
disabled, a non-default configuration. It remains possible to disable
systemd-resolved if desired. Otherwise, any custom system
administration scripts that manage /etc/resolv.conf will need to be
updated.
=== DNSSEC ===
systemd-resolved's DNSSEC support is known to cause compatibility
problems with certain network access points. Per recommendation from
the systemd developers, we will change the default value of this
setting in Fedora from the upstream default `DNSSEC=allow-downgrade`
to `DNSSEC=no` by building systemd with the build option
`-Ddefault-dnssec=no`. The upstream default attempts to use DNSSEC if
it is working, but automatically disable it otherwise, allowing
man-in-the-middle attackers to disable DNSSEC. Sadly, even the
allow-downgrade setting suffers known compatibility problems. Because
Fedora is not prepared to handle an influx of DNSSEC-related bug
reports, we will disable this feature altogether. We anticipate that
enabling DNSSEC by default will not be possible in the foreseeable
future, or perhaps ever. Instead, enabling DNS over TLS (when
supported by the DNS server) seems likely in the near future.
=== Multicast DNS ===
systemd-resolved's multicast DNS support conflicts with Avahi. Per
recommendation from the systemd developers, we will change the default
value of this setting in Fedora from the upstream default
`MulticastDNS=yes` to `MulticastDNS=resolve`. Multicast DNS resolving
will be enabled, but responding will be disabled. This will require
adding a new systemd build option to control the default value of the
MulticastDNS setting, similar to the existing `default-dnssec` and
`default-dns-over-tls` build options.
== How To Test ==
Load any website in a web browser. If you succeed, then name
resolution probably works.
Try using `resolvectl status` and, for example, `resolvectl query
fedoraproject.org`, to see how they work and sanity-check their
output.
Users who use multiple VPNs at the same time are encouraged to test
DNS in a multiple VPN scenario, to ensure that DNS requests are sent
to the expected DNS server.
== User Experience ==
See the Benefit to Fedora section, above, for direct benefits to users
who use multiple VPNs at the same time.
Users will be able to use the resolvectl tool and the functionality it provides.
/etc/resolv.conf will now be managed by systemd rather than by
NetworkManager. As before, this file must not be modified directly
when it is managed.
== Dependencies ==
In Fedora, /etc/nsswitch.conf is managed by authselect. By default,
authselect uses the sssd profile to generate configuration compatible
with sssd. In this mode of operation, it does not modify the hosts
line in /etc/nsswitch.conf. This is also true if using the winbind
profile instead of the sssd profile. However, authselect's minimal and
nis profiles do modify the hosts line. These authselect profiles must
be updated to enable nss-resolved. If you are using authselect in one
of these modes, it will not be possible to cleanly disable
systemd-resolved because the hosts line in /etc/nsswitch.conf will be
clobbered whenever 'authselect apply-changes' is run. If you wish to
disable systemd-resolved and you are using authselect in one of these
modes, then you should stop using authselect. This is not expected to
cause many problems because virtually all Fedora users will be using
the default sssd profile.
We do not need to directly make any changes to the /etc/nsswitch.conf
shipped by glibc. Changes will be applied in the systemd-libs %post
scriptlet.
== Contingency Plan ==
The contingency plan, in the unlikely event of unexpected problems, is
simply to revert any changes and not enable systemd-resolved.
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
* systemd-resolved is documented in several manpages: resolvectl(1),
resolved.conf(5), nss-resolve(8), systemd-resolved(8).
* [https://wiki.archlinux.org/index.php/Systemd-resolved Arch Wiki
documentation]
* [https://wiki.gnome.org/Projects/NetworkManager/DNS NetworkManager
DNS documentation]
== Release Notes ==
systemd-resolved is now enabled by default. systemd-resolved provides
a system-level DNS cache that can substantially improve performance
for applications that do not cache their own DNS results, allows
correct handling of split DNS scenarios such as when multiple VPNs are
in use, and will allow Fedora to enable DNS over TLS in the future.
/etc/resolv.conf will now be managed by systemd-resolved rather than
by NetworkManager. /etc/resolv.conf will no longer be read when
performing name resolution using glibc; however, it is still provided
for compatibility with applications that manually read this file to
perform name resolution. Writing to /etc/resolv.conf will no longer
work as expected.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
6 months, 2 weeks