Working recovery with locked root user (rescue.service)
by Benjamin Berg
Hi,
so, the other day we had a major regression in the PAM stack[1] that,
unfortunately, ended up hitting rawhide and the Fedora 33 testing (not
stable) repository before being unpushed.
In this case it was easy to work around as SSH was still working fine.
But, it seems that rescue mode requires having a root password set,
which we do not always do during the Fedora install.
So, I think we should have an obvious way for users to enter recovery
mode even with a locked root account.
Currently rescue.service is executing "systemd-sulogin-shell" which in
turn runs "sulogin" (part of util-linux). A workaround is to
set SYSTEMD_SULOGIN_FORCE=1 in rescue.service, but that just disables
authentication entirely.
I suppose to improve this, we would need a kind of "sudologin" that
accepts any user in the "wheel" group. Or maybe some other more rigid
requirement like configuring the first admin user that was created.
Anyone has a good idea on how to solve this?
Benjamin
[1] What happened was that pam_fprintd would crash if you had no
fingerprint reader in the system.
That was an ugly regression that got into a cleanup patch. The
regression only happened if you had *no* fingerprint reader, a scenario
that managed to sneak by both automated and manual testing.
The upstream automated tests have of course been fixed by now:
https://gitlab.freedesktop.org/libfprint/fprintd/-/commit/ca216a32aff07a8...
3 years, 5 months
Trying to setup some tmpfiles handling for podman.
by Daniel Walsh
# /tmp/podman-run-* directory can contain content for Podman containers
that have run
# for many days. This following line prevents systemd from removing this
content.
x /tmp/podman-run-*
D! /run/podman
X! /var/lib/cni/networks/*/last_reserved_ip*
D! /var/lib/cni/networks
Basically we want to make sure the /run/podman and /var/lib/cni/networks
are cleaned up on boot.
BUT we don't want /var/lib/cni/networks/*/last_reserved_ip* to be removed.
This works but is still cleaning up last_reserved_ip.0? What am I doing
wrong?
3 years, 5 months
AArch64 support for container and flatpak builds
by Mark O'Brien
All,
We are very happy to announce that we now have AArch64 support for flatpak
and container fedpkg builds in production!
By default all flatpak and container builds will be built on both
architectures from now on.
Thanks,
Fedora OSBS initiative
3 years, 5 months
local mock builds using "local" repo really slow
by Fabio Valentini
Hi everybody,
Is it just me or have downloads for the "local" repo (using mock with
"--enablerepo local") been really slow for everybody lately? I'm only
getting 50-100 kB/s download speeds for the repo metadata ... don't
worry, I'm only using this repo when I need to test builds against the
latest non-composed packages ....
Download speeds like these make mock builds unbearably slow :(
Typically this adds 10-15 minutes to the dnf step in mock (since it
wants to refresh those caches every time newRepo/f34-build is run in
koji), and since there are two (or three, when using GenBR) of those
steps, builds take an additional 30 minutes or so to complete (on top
of a few minutes of build time, this is really slowing down my
process)
I really don't want to resort to using scratch builds for testing
purposes, as this would only put even more strain on koji, and scratch
builds cannot depend on each other, so they don't work for testing
multi-build updates at all.
Any ideas how I could work around those slow download speeds for the
"local" repo? Or can they be improved again? They've only been this
slow for a few days and it hasn't been a problem earlier.
Fabio
3 years, 5 months