gcc has a new warning which caught a bug of int/enum mismatches.
And we would crash on some architectures when built with -D_FORTIFY_SOURCE=3
because of our malloc_usable_size() use.
This should resolve the build failure in F38 mass build.
- Fixes a few different issues (systemd-timesyncd connectivity problems, broken
emoji output on the console, crashes in pid1 unit dependency logic)
- CVE-2022-4415: systemd: coredump not respecting fs.suid_dumpable kernel
setting
As requested in https://github.com/rhinstaller/anaconda/pull/4368#discussion_r1043839809,
so that it's easier to depend on the appropriate package. Once we have the
signed version built, this provides might be dropped. But let's add it at least
for now so that there's a stable name to depend on.
While at it, let's drop ? from %{_isa}. Systemd is always archful.
This file changes rarely, but it does every one in a while. And since we have an
independent copy, we forget to adjust it. We have had already two bugs because
of this. I submitted a PR upstream to include pam_namespace (because that makes
sense for all distros), so the diff between upstream and us now is just the
inclusion of system-auth (which is not upstreamable).
Effectively, the only difference right now is that 'pam_keyinit force revoke'
is included. It was added upstream with the comment:
We want that systemd --user gets its own keyring as usual, even if the
barebones PAM snippet we ship upstream is used. If we don't do this we get
the basic keyring systemd --system sets up for us.
4047e4fb7b got things very wrong.
The trick with "[ $1 -eq 1 ]" doesn't work for transaction triggers
because the argument is not provided by rpm. We need to use a state
file to propagate the information from %post to %posttrans.
... (for details see https://raw.githubusercontent.com/systemd/systemd/v252-rc1/NEWS)
systemd-pcrphase and systemd-measure and initrd-* units are moved to systemd-udev.
systemd-udev should be part of the initrd, and those tools don't make much sense
in systems without hardware (i.e. containers). (systemd-measure could possibly be
useful, but we can always move it back if there's a good reason.)
- Remove swap policy. Default amount of swap (8GB?) is a lot lower than
what we use internally with the swap policy. Which frequently leads to
GNOME getting killed
(e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1941170, and other
BZs not linked here). Internally we use 0.5x-1x size of physical memory
for swap via swapfiles (this will be documented in systemd upstream).
In simple cases of using more memory than is available (but without
memory pressure), the Kernel OOM killer can handle killing the
offending process.
- Expand the memory pressure policy to system.slice, user-.slice, and
all user owned slices. Support for ManagedOOM*= on user services was
added in https://github.com/systemd/systemd/pull/20690 which allows
us to be more fine grained on the pressure monitoring at the user
level. In addition to the system.slice and user-.slice PSI monitoring
this should result in a better systemd-oomd experience for desktop
systems.
Instead, add systemd-pam to pungi-fedora's multilib whitelist:
https://pagure.io/pungi-fedora/pull-request/1113
This should help with flatpak runtime packaging so that we can avoid
having to ship systemd-pam in the flatpak container.
It turns out that with the Obsoletes, dnf will just install the normal
systemd package if systemd-standalone-* is requested. The commit message
for b36512ad8f which added this says I tested
with local package builds (where it works), but not when going through the
full repo with all packages.
I'm adding the Provides instead, so that it's possible to request on or
the other more easily.
I asked on fedora-devel@, and the lone reply was from Matthew Miller
who tried it once when it was introduced and hasn't used it since.
Dropping this removes the last dependency on libgcrypt and libgpg-error
in libsystemd, significantly reducing our installation footprint.
Right now libmicrohttpd is still linked to libgcrypt, so
libsystemd-journal-remote subpackage will pull libgcrypt in.
When -Dversion-tag was initially added in edaa157918,
I used "v" without any comment. But upstream does not use "v", so we have
versions which don't compare directly:
$ build/systemctl --version|head -n1
systemd 251 (251-66-g7e46a5c+)
$ systemctl --version|head -n1
systemd 251 (v251-1.fc37)
And in 3c4f9413a7, when -Dshared-lib-tag= was
introduced, %{version} was replaced by %{version_no_tilde}, again without any
specific comment. For the shared-lib-tag, it makes sense to use _no_tilde,
because it's enough to have non-conflicting file names, and we don't compare
the tags. I guess I wanted both uses to be consistent. But if we substitute
the tilde, we can't do proper comparisons.
I noticed the following issue: with sd-boot installed from git and a
package, upgrades wouldn't work:
Comparing versions: "systemd-boot v251-1.fc37" < "systemd-boot 251-rc1-390-g3603f15
Skipping "/boot/efi/EFI/systemd/systemd-bootx64.efi", since newer boot loader version in place already.
The two changes should make those comparisons work properly in most
cases.
I tested this with 'sudo dnf --installroot=…', with both
systemd+system-udev installed in one transaction, and in two separate
transactions. Users are created as expected in both cases.
$ rpm -qlv systemd |grep -v 'root root'
-rw-rw-r-- 1 root utmp 0 Jan 22 03:38 /run/utmp
-rw-rw---- 1 root utmp 0 Jan 22 03:38 /var/log/btmp
-rw-rw-r-- 1 root utmp 0 Jan 22 03:38 /var/log/lastlog
-rw-rw-r-- 1 root utmp 0 Jan 22 03:38 /var/log/wtmp
drwxr-sr-x 2 root systemd- 0 Jan 22 03:38 /var/log/journal
During installation rpm would log an error that systemd-journal group
is unknown. We create all our users by calling sysusers in the %post
scriptlet, but that is too late. To avoid the warning we could either
add a %pre scriptlet, but that'd require adding a dependency on
shadow-utils for groupadd, since we can't use our own tools before we
are installed. Let's instead create the directory owned by root.root,
and change the group afterwards. The group ownership is for file
ownership, and in the worst case (we don't assign the group or set
mode +s), unprivileged users will not be able to read the logs.
We also use 'utmp' group, but that is provided by setup.rpm and is not
an issue.
https://bugzilla.redhat.com/show_bug.cgi?id=2018913#c24
For https://fedoraproject.org/wiki/Changes/RenameNobodyUser a scriptlet
was introduced with prevents nss-systemd from synthesizing entries for nobody.
Let's remove the scriptlet: very few people upgrade from such old systems,
and even if they do, having a duplicate entry for nobody is annoying
but hardly a big problem.
(The other side of this, support in nss-systemd remains in place.)
This allows deps on the tools used in the scriptlet to be dropped from -libs.
While at it, also drop noop ldconfig scriptlets.
Related to: https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory
Both systemd and resolved nss modules are now enabled by default in
authselect. Users are now expected to use authselect to configure
the system and packages should no longer support non-authselect
configurations.
Resolves: rhbz#2023743
This reverts commit 2afe364ac4.
Unfortunately the build failed on dependencies:
DEBUG util.py:444: Error:
DEBUG util.py:444: Problem: package authselect-libs-1.3.0-1.fc36.x86_64 conflicts with glibc < 2.34.9000-27 provided by glibc-2.34.9000-26.fc36.x86_64
DEBUG util.py:444: - package util-linux-2.37.2-1.fc36.x86_64 requires /etc/pam.d/system-auth, but none of the providers can be installed
DEBUG util.py:444: - package gawk-5.1.1-1.fc36.x86_64 requires libm.so.6()(64bit), but none of the providers can be installed
DEBUG util.py:444: - package gawk-5.1.1-1.fc36.x86_64 requires libm.so.6(GLIBC_2.2.5)(64bit), but none of the providers can be installed
DEBUG util.py:444: - package gawk-5.1.1-1.fc36.x86_64 requires libm.so.6(GLIBC_2.29)(64bit), but none of the providers can be installed
DEBUG util.py:444: - package gawk-5.1.1-1.fc36.x86_64 requires rtld(GNU_HASH), but none of the providers can be installed
DEBUG util.py:444: - package gawk-5.1.1-1.fc36.x86_64 requires libc.so.6(GLIBC_2.34)(64bit), but none of the providers can be installed
DEBUG util.py:444: - conflicting requests
I need to build the package again in rawhide, so this needs to be reverted
for now.
Related to: https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory
Both systemd and resolved nss modules are now enabled by default in
authselect. Users are now expected to use authselect to configure
the system and packages should no longer support non-authselect
configurations.
Resolves: rhbz#2023743
If /etc/resolv.conf pointed to systemd-resolved stub configuration, it
is obvious it would stop working. Compensate it by deleting the link, it
would be created again on installation. Try to pass ownership to NM,
which also provides similar file. Keep it missing otherwise, might be
created by unknown tool on reboot.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
Move systemd-resolved daemon and related tools to its own subpackage.
Keep only nss-resolve in systemd, the service itself is moved to
subpackage. It has quite different functionality than systemd package
and deserves own package.
Still recommend resolved from main package
Keep backward compatibility and still recommend systemd-resolved. Allow
removal, but would be installed by default.
This allows a fairly big dependency chain to be pruned in the future,
now other packages pull in setup:
/usr/bin/groupadd → shadow-utils → setup.
It seems we don't need the setup rpm for anything in minimal installations.
There should be no functional change. Testing will be prudent.
systemd-rpm-macros is small, but it pulls in bash and is always one more package.
It is only useful if the rpm building utilities are there, so let's conditionalize
on that.
This is in preparation for https://src.fedoraproject.org/rpms/systemd/pull-request/52,
splitting out systemd-resolved subpackage. The new package should
be pulled in by comps, but this would create a "flag day", because
the systemd-resolved name is currently unknown. So let's add the
virtual Provides now. Even if the package is never split out, it doesn't
cause any harm.
systemd-cryptsetup and systemd-veritysetup link with libcryptsetup, so
this dependency is already in Requires. (Well, not in bootstrap mode,
but I'm pretty sure we don't want to publish rpms built in bootstrap
mode, so it shouldn't matter.)
There isn't really a one size fits all policy since pressure can change
a lot based on whether you have flash or spinning disks (and your swap
configuration as well). But let's be a bit more conservative here.
