Unable to login as root with a recent Rawhide Fedora Cloud image
by Ondrej Mosnacek
Hi,
When I set up a rawhide cloud image
(Fedora-Cloud-Base-Rawhide-20211217.n.1.x86_64.qcow2 from
download.fedoraproject.org) with a root password using virt-sysprep:
virt-sysprep -a <image> --root-password password:123456
--selinux-relabel [...]
...I am unable to login as root on the console once I boot it. When I
enter "root" in the login prompt, I immediately get "Login incorrect"
(it doesn't even ask for password). With the F35 Cloud image I can
login just fine with the same procedure.
Anyone know if this is an intentional change or a bug? If it's
intentional, what do I need to do to make root login work again? If
it's a bug, any idea which component to report it against?
Thanks,
--
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
2 years, 5 months
Schedule for Monday's FESCo Meeting (2021-12-20)
by Zbigniew Jędrzejewski-Szmek
Following is the list of topics that will be discussed in the
FESCo meeting Monday at 19:00UTC in #fedora-meeting on
irc.libera.chat.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2021-12-20 19:00 UTC'
Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda
= Discussed and Voted in the Ticket =
#2706 F36 Change: PostgreSQL 14
https://pagure.io/fesco/issue/2706
APPROVED (+7,0,-0)
#2707 F36 Change: LXQt 1.0
https://pagure.io/fesco/issue/2707
APPROVED (+6, 0, -0)
#2708 F36 Change: Users are administrators by default in the installer GUI
https://pagure.io/fesco/issue/2708
APPROVED (+7,0,-0)
= Followups =
= New business =
New meeting time
#2711 F36 Change: Enable fs-verity in RPM
https://pagure.io/fesco/issue/2711
#2713 F36 Change: Make Rescue Mode Work With Locked Root
https://pagure.io/fesco/issue/2713
= Open Floor =
For more complete details, please visit each individual
issue. The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda
If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
I'm not convinced that we'll have quorum today, since many people are
already on vacation. No matter if we hold the meeting or not, let's
plan to meet 3/1/2022. In other words, the meeting between X-mas and
New Year is hereby cancelled.
Zbyszek
2 years, 5 months
F36 Change: LLVM 14 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LLVM-14
== Summary ==
Update all llvm sub-projects in Fedora Linux to version 14.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 14, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang13 and llvm13 will be added to ensure that
packages that currently depend on clang and llvm version 13 libraries
will continue to work.
Unlike previous releases, we will no longer be packaging release
candidate builds in Rawhide or F36. Release candidates are not
guaranteed to be ABI compatible with each other, so upgrading from one
release candidate to another (or to the final release) requires
rebuilding all the clang/LLVM library users. This has become very
difficult to coordinate given the increased number of packages using
the clang/LLVM libraries, so we decided to only package the final
release.
We do plan to build release candidate versions into a side-tag for
testing. We will also create an llvm-14 branch in dist-git, so that
we can build the release candidate versions while still being able to
fix bugs and make changes to LLVM 13 in the rawhide branch.
'''Note: we are still discussing with Release Engineering if a branch
+ side-tag will be possible [https://pagure.io/releng/issue/10414
#10414]. If it's not possible, we will use COPR instead.'''
== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.
== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Request an llvm-14 branch in dist-git for each llvm sub-project.
** Request a side-tag.
** Build llvm13 and clang13 compat packages into the side-tag.
** When upstream LLVM project releases version 14.0.0-rc1 (Late
January 2021), package this using the llvm-14 branches and build it
into the side-tag.
*** Repeat process for each release candidate.
** When upstream LLVM project releases version 14.0.0-final (March
2021), package this using the rawhide and f36 branches.
* Other developers:
** Maintainers of packages that depend on clang-libs or llvm-libs will
need to update their spec files to depend on the clang13 and llvm13
compatibility packages if they want to rebuild their package and it
does not work with LLVM 14 yet. The key point here is that spec file
changes are only needed if a package is going to be rebuilt after LLVM
14 is added to Fedora. The compatibility packages will ensure that
already built packages continue to work.
* Release engineering: [https://pagure.io/releng/issue/10414 #10414]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
This change should not impact upgradeability.
== How To Test ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM
14.
== User Experience ==
Users will benefit from new features and bug-fixes in the latest
version of LLVM.
== Dependencies ==
This change can be made without updating any other packages. However,
as mention before, packages that need to use LLVM 13 will need to
update their spec file on their first rebuild after this change.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?): If there are
major problems with LLVM 14, the compatibility package provide a way
for other packages to continue using LLVM 13.
* Contingency deadline: Final Freeze
* Blocks release? No
== Documentation ==
Release notes will be added for this change.
== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 14:
* llvm
* clang
* lld
* lldb
* compiler-rt
* libomp
* llvm-test-suite
* libcxx
* libcxxabi
* python-lit
* flang
* mlir
* polly
* libclc
* llvm-unwind
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 5 months
F36 Change: Make Authselect Mandatory (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory
== Summary ==
This change wants to make authselect required to configure
authentication and identity sources and forcefully update
non-authselect configuration to the sssd authselect profile to
eliminate any existing non-authselect setups.
Even though it will still be possible to manually modify the
configuration, users that require special configuration should create
and use custom authselect profile.
''Authselect is available in Fedora since Fedora 27 and enabled by
default on new installations since Fedora 28. Authconfig compatibility
tool was removed from Fedora 35 as a
[[Changes/RemoveAuthselectCompatPackage|system wide change page]]. It
is now well accepted by the community as well as the package
maintainers. The package maintainers have repeatedly requested to make
authselect mandatory for the users which lead to creation of
[https://bugzilla.redhat.com/show_bug.cgi?id=2000936 this bugzilla].''
== Owner ==
* Name: [[User:pbrezina|Pavel Březina]]
* Email: pbrezina(a)redhat.com
== Detailed Description ==
The following components must be updated to make authselect mandatory:
* authselect
* pam
* glibc
* packages that use it: systemd, ecryptfs, nss-mdns and fingerprint.
Required changes:
# Remove user-nsswitch.conf functionality from authselect
# Move ownership of /etc/nsswitch.conf and /etc/pam.d/{system-auth,
password-auth, smartcard-auth, fingerprint-auth, postlogin} to
authselect from glibc and pam
# Require authselect in pam
# Remove non-authselect support from systemd, ecryptfs, nss-mdns and fingerprint
# Select default profile when authselect is installed
# Select default profile when authselect is upgraded
=== Remove user-nsswitch.conf functionality ===
File /etc/authselect/user-nsswitch.conf was introduced in authselect
to allow partial user modifications of nsswitch.conf without the need
to create a custom authselect profile. The main driver was to enable
modules that are not included in authselect such as systemd-resolved
and nss-mdns.
This however made the situation more confusing to users and it is not
desirable any more if authselect is mandatory.
'''Authselect will drop user-nsswitch.conf functionality and instead
add more nsswitch modules to existing profiles and be more open about
future inclusion requests.'''
=== Own /etc/nsswitch.conf and /etc/pam.d/{system-auth, password-auth,
smartcard-auth, fingerprint-auth, postlogin} instead of glibc and pam
===
File /etc/nsswitch.conf is currently owned by glibc. It will be now
owned by authselect and removed from glibc.
PAM configuration generated by authselect is currently owned by pam.
It will be now owned by authselect and removed from pam.
''Note: that config-util and other will still be owned by pam since
these files are not generated by authselect.''
'''All files that are generated by authselect are now owned by authselect.'''
=== Require authselect in pam ===
The pam package will require authselect. This will tie pam and
authselect together and it will be impossible to uninstall authselect
without uninstalling pam which fundamentally makes authselect a hard
dependency on each system.
'''This step will make it impossible to uninstall authselect, making
it always available to RPM packages.'''
=== Remove non-authselect support from systemd, ecryptfs, nss-mdns and
fingerprint ===
'''Non-authselect configuration support will be dropped in these packages.'''
=== Select default profile when authselect is installed ===
If authselect configuration is not detected and this is a new
installation of authselect it will automatically select the
distribution default authselect profile by calling authselect select
--force with distribution specific parameters.
If existing authselect configuration is detected (perhaps from
previous installation), it will be updated (current behavior).
This makes sure that if authselect is installed (which is always) a
configuration is created.
Select default profile when authselect is upgraded
If authselect is upgraded from an older version and non-authselect
configuration is detected, it will forcefully overwrite it with
distribution defaults by calling authselect select --force with
distribution specific parameters.
This is a one time event so if someone does not want to use
authselect, it remains possible. However, non-authselect
configurations will not be supported by RPM packages mentioned above.
If authselect is upgraded on a system that already is configured by
it, the update process remains the same as it is now.
'''This step will forcefully update existing installations to
authselect configuration. It is a one time event and opt-out is still
possible but no longer supported.
'''
== Benefit to Fedora ==
'''Making authselect mandatory will provide better user and
maintainers experience and significantly reduce risk of breaking
system configuration.'''
The use of authselect-generated configuration is currently optional.
This means that users can uninstall authselect or just opt-out from it
by modifying the PAM and nsswitch.conf manually.
Additionally users that upgrade from pre-authselect systems (Fedora 27
and older) must opt-in to authselect manually, which is not the case
most of the time. Also sometimes an upgrade of a particular package
that did not handle authselect configuration correctly automatically
opted-out its users. Therefore we can split users into four groups:
* Those who are using authselect
* Those who were using authselect but are not anymore due to various
errors in packages
* Those who are not using authselect because they are not aware of it
and upgraded from older Fedora versions thus it was not automatically
enabled
* Those who are not using authselect knowingly
''Fedora is now split into two worlds: those who use authselect and
those who don’t. This however keeps two problems existing. Authselect
was designed to solve them both. But it will be solved only if the use
of authselect is a mandatory requirement.''
=== 1. It is difficult to deliver updates to configurations ===
FIles /etc/nsswitch.conf and /etc/pam.d/* are distributed as
%config(noreplace) which means that they are configuration files and
are only installed if they are not yet present. If they are present
then they are never overwritten with package updates, instead an
*.rpmnew file is created and the update responsibility is left
completely to the user.
It is done this way to prevent overwriting user changes
configurations. But at the same time it means that even configurations
that are not modified by the users can not be changed so we can not
deliver fixes and changes efficiently.
It is only possible through difficult scriptlets. As an example, we
can show this bugzilla where a change in Gnome required an update to
PAM otherwise the user could not authenticate. Delivering the change
was easy with authselect, but difficult for non-authselect systems.
Authselect already knows how the resulting configuration should look
and does not risk overriding user configuration. Making it mandatory
will help distribute important updates to nsswitch and PAM
configuration.
=== 2. Package maintainers wants to enable/disable nsswitch or PAM
modules automatically upon installation/uninstallation ===
Packages that install nsswitch modules (e.g. systemd, nss-mdns) or PAM
modules (e.g. ecryptfs, fprintd) want to enable the module
automatically upon RPM installation to provide a better user
experience. So they use various more or less complex and fragile
scriptlets in %post action of the RPM.
This is usually easier for the nsswitch module, when simple sed works
for most configurations. But it is not really possible for PAM
(because there is high risk of introducing security vulnerabilities or
breaking authentication completely) so the packages used authconfig
and now authselect.
Packages need to detect the current authselect state and either call
authselect when available or fallback to non-authselect scriptlets.
The end results tends to be the same for nsswitch modules but
different for PAM modules where it is either enabled with authselect
or nothing happens.
'''If authselect is made mandatory, packages can only support
authselect configuration which makes the change simple,
straightforward, easier to test and safe.'''
== Scope ==
* Proposal owners:
** authselect maintainers:
*** implement the changes described in "Detailed Description" in all
affected packages
*** open pull requests with the changes against affected packages
* Other developers:
** maintainers of affected packages must accept submitted merge request
* Release engineering: [https://pagure.io/releng/issue/10337 #10337]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
The system will be forcefully configured with authselect, selecting
the default distribution profile (sssd), if non-authselect
configuration is detected. It will will override users configuration.
A backup will be created, users can run 'authselect backup-restore
$id' to restore their configuration when desired.
== How To Test ==
* Authselect must keep working as expected.
* Ownership of the following files is transferred to authselect-libs package
** /etc/pam.d/fingerprint-auth
** /etc/pam.d/password-auth
** /etc/pam.d/postlogin
** /etc/pam.d/smartcard-auth
** /etc/pam.d/system-auth
** /etc/nsswitch.conf
* pam requires authselect
* updating from previous system with non-authselect configuration must
result in applied authselect configuration with sssd profile
* updating from previous system with authselect configuration must
remain intact (besides applying udated profiles)
* installing/removing affected packages (see Detailed Description)
must not break authselect configuration
== User Experience ==
PAM and nsswitch.conf configuration will be automatically updated when changed.
''Note: To request inclusion of a new nsswitch or PAM module in
default authselect profiles, either open an issue on authselect GitHub
project or open a bug against authselect component in Fedora
bugzilla.''
''Note: Users will still be able to create custom profiles to include
modules that are not supported by default authselect profiles.
However, such profiles will have limited update support. It is
possible to create a custom profile with some files as symlinks to
default profiles, those files will receive updates automatically.
However, modified files of the custom profiles still need to be
updated manually and the users are responsible for the update.
''
''Note: Users will still be able to opt-out from authselect, but such
configuration will no longer be updated on upgrades or touched by
package installation.''
== Dependencies ==
This change does not break any packages that depends on authselect.
== Contingency Plan ==
* Contingency mechanism: Revert changes in affected packages.
* Contingency deadline: Beta
* Blocks release? No
== Documentation ==
There is no upstream documentation.
== Release Notes ==
Configuring system authentication and identity sources with authselect
is now mandatory. Systems with non-authselect configuration will be
automatically forcefully upgraded to authselect configuration. Users
that require special configuration are encouraged to create and use
custom authselect profile.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 5 months
F36 Change: Wayland By Default with NVIDIA proprietary Driver
(System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA
== Summary ==
Enable Wayland sessions by default in GDM even with the NVIDIA
proprietary driver.
== Owner ==
* Name: [[User:ofourdan| Olivier Fourdan]]
* Email: <ofourdan(a)redhat.com>
== Detailed Description ==
Recent updates in NVIDIA proprietary driver allow Xwayland to benefit
from hardware acceleration and X11 applications can have their
rendering hardware accelerated.
That allowed to enable Wayland sessions even when the NVIDIA
proprietary driver is used, but keeping Xorg the default in that case.
This proposal is to make Wayland by default with newer versions of the
NVIDIA proprietary driver to remain consistent with other drivers.
GDM already has a set of udev rules which check for the driver and its
version, so this would only require a tweak in the udev rules to make
Wayland session the default with the next version of the NVIDIA driver
[https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/61-gdm.rules.in].
Note that currently Xorg is also preferred in the case of multiple
GPU, this would remain the case with this proposal.
This change is just about changing the default with NVIDIA proprietary
driver on supported configurations, “GNOME on Xorg” still remains an
option, just like with other drivers.
== Benefit to Fedora ==
Fedora has changed to Wayland by default since [[Changes/Login Screen
Over Wayland|Fedora 22]], but the NVIDIA proprietary driver has been
an exception ever since (either because originally Wayland would be
disabled with NVIDIA drivers, or more recently Xorg would be used by
default).
Currently, when first installing Fedora on NVIDIA hardware, users get
Wayland by default with the Open Source "nouveau" driver, with Xorg
being an option in the login screen. If they later decide to enable
the rpmfusion repository and install the NVIDIA proprietary driver,
they get Xorg by default and Wayland as an option.
This change would make the default consistent regardless of the
driver, for single GPU systems.
== Scope ==
* Proposal owners: Tweak the gdm udev rule to enable Wayland with the
NVIDIA proprietary driver above a given version
[https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/61-gdm.rules.in#L7-17]
* Other developers: [[User:Rstrode| Ray Strode]] for reviewing the
changes in the udev rules from GDM
* Release engineering: This change doesn't affect release workflow
* Policies and guidelines: This change doesn't affect packaging guidelines
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No
== Upgrade/compatibility impact ==
== How To Test ==
# Requires an NVIDIA GPU supported by the recent NVIDIA proprietary
driver and `nvidia-drm.modeset=1` set in the kernel command line to
enable KMS [http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/kms.html]
(rpmfusion packages for the NVIDIA driver do that automatically)
# Enable the rpmfusion “nonfree” repository to install the NVIDIA
graphics drivers
[https://docs.fedoraproject.org/en-US/quick-docs/setup_rpmfusion/]
# Install the NVIDIA proprietary driver (and the
`xorg-x11-drv-nvidia-power` package for suspend/resume support - see
[https://rpmfusion.org/Howto/NVIDIA?highlight=%28%5CbCategoryHowto%5Cb%29#...]
and [http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/powerman...]
for more details) from the rpmfusion repository
# Reboot the machine
# Ensure graphical login screen comes up
# Try to log into a "GNOME" session
# Check whether this is a "GNOME on Wayland" session (both `$DISPLAY`
and `$WAYLAND_DISPLAY` are set)
# Log out
# Try to log into a "GNOME on Xorg" session
# Check whether this is a "GNOME on Xorg" session (`$DISPLAY` is set,
`$WAYLAND_DISPLAY` is not set)
== User Experience ==
Users with NVIDIA hardware and NVIDIA proprietary driver installed
will get a Wayland session by default when selecting the "GNOME"
session in the login screen.
== Dependencies ==
This depends on the NVIDIA proprietary driver and its support for Wayland.
Typically, this proposal would change the default in a future version
of the NVIDIA driver which is not released yet.
== Contingency Plan ==
* Contingency mechanism: Revert the default to Xorg for NVIDIA driver
by reverting the changes in the udev rule shipping with GDM
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
NVIDIA's own documentation
[http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/]:
* http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/kms.html
* http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/xwayland...
* http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/gbm.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 5 months