devel September 2020

devel@lists.fedoraproject.org

239 participants
410 discussions

Disabling Fedora 30 chroots in Copr
by Jakub Kadlcik 23 Nov '20

23 Nov '20

Hello, we have just disabled Fedora 30 chroots in Copr. According to the Fedora wiki [1], Fedora 30 reached the end of its life on 2020-05-26 and therefore we are disabling it in Copr. That effectively means that from this moment, it is no longer possible to submit builds for the following chroots: - fedora-30-x86_64 - fedora-30-i386 - fedora-30-ppc64le - fedora-30-aarch64 - fedora-30-armhfp [1] https://fedoraproject.org/wiki/End_of_life Jakub

4 12

F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)
by Ben Cotton 26 Oct '20

26 Oct '20

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

12 23

F33 beta: where are my Rust packages?
by Artur Frenszek-Iwicki 19 Oct '20

19 Oct '20

I maintain two Rust packages, rust-copydeps [1] and rust-desed [2]. Both were built for F33 ([3], [4]) before it branched off for Rawhide (and submitted to bodhi ([5], [6])). I gave the F33 beta a spin and when I tried "dnf install copydeps desed", I got no matches. Other Rust packages, like rust-exa and rust-ytop, install fine. Was there some change to the Rust packaging process that I missed? If not, why are the packages not available? A.FI. [1] https://src.fedoraproject.org/rpms/rust-copydeps [2] https://src.fedoraproject.org/rpms/rust-desed [3] https://koji.fedoraproject.org/koji/buildinfo?buildID=1572147 [4] https://koji.fedoraproject.org/koji/buildinfo?buildID=1507459 [5] https://bodhi.fedoraproject.org/updates/FEDORA-2020-74b3aa82d5 [6] https://bodhi.fedoraproject.org/updates/FEDORA-2020-2ef745ad6e

5 7

Fedora 33 blocker status
by Ben Cotton 16 Oct '20

16 Oct '20

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

12 24

CPE Weekly: 2020-09-20
by Aoife Moloney 13 Oct '20

13 Oct '20

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_w… 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

3 4

Unresponsive packagers: ekulik, imcleod and lsun
by Pierre-Yves Chibon 13 Oct '20

13 Oct '20

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

8 13

Reproducible builds/bootstrap
by Pablo Greco 09 Oct '20

09 Oct '20

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

8 11

F34 Change proposal: DNS Over TLS (System-Wide Change)
by Ben Cotton 09 Oct '20

09 Oct '20

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 7

sundials-5.4.0 updating
by Antonio T. sagitter 08 Oct '20

08 Oct '20

Hi all. Sundials will be updated to the release 5.4.0 on Rawhide branch in 7 days at least. Probably, i will create a specific side-tag. Sundials 5.4.0 release notes: https://github.com/LLNL/sundials/releases/tag/v5.4.0 Regards. -- --- Antonio Trande Fedora Project mailto: sagitter(a)fedoraproject.org GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/

4 12

Fedora 33 System-Wide Change proposal: systemd-resolved
by Ben Cotton 07 Oct '20

07 Oct '20

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/f4cc5b6ce095bb4233e5… fedora-release presets] to enable systemd-resolved instead of disable it. # systemd-libs currently has [https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8ede… 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

58 388

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel September 2020