$ 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.
From a branding perspective, having the fallback hostname be "fedora" for an OS that is not Fedora Linux is incorrect. Go back to using "localhost" in those cases.
This reverts commit db19323db2.
Paths are adjusted. The condition is inverted to actually check the
right thing.
The test is moved before build to make it easier to see. Meson does
the .in substitutions immediately after configuration, so this should
be easier to see.
All scriptlets to disable services upon final package removal are
removed. Removing rpm from a running system is not allowed by dnf and
would generally result in mayhem. Trying to clean up our enablement
symlinks is not useful. Nobody tests this and it almost certainly was
incomplete.
Only do 'journalctl --update-catalog' if /var is writeable, and remove
suppression of errors from 'journalctl --update-catalog'. It shouldn't
fail, and it it does, we should figure out why.
On upgrades, execute 'journalctl --update-catalog' and
'systemd-tmpfiles --create' in %postun, not %post. This way we won't
look at possibly-about-to-be-removed configuration.
Restart various services upon upgrade: systemd-timedated.service
systemd-timesyncd.service systemd-portabled.service
systemd-homed.service systemd-hostnamed.service
systemd-journald.service systemd-localed.service systemd-userdbd.service.
Not doing this was a bug.
user@.service and systemd-logind.service will need special handling
and are not done in this patch.
Changes for https://fedoraproject.org/wiki/Changes/EnableSystemdOomd.
Backports primarily PR #18361, #18444, and #18401 (#18401 is not merged
at the time of writing this commit) + some minor PRs to handle conflicts.
Creates systemd-oomd-defaults subpackage to install unit drop-ins that
will configure systemd-oomd to monitor and act.
This patch enables support of the following options in
/etc/crypttab:
- no-read-workqueue
- no-write-workqueue
This patch corresponds to the upstream pull request that has been
merged and will be in systemd 248:
https://github.com/systemd/systemd/pull/18062/
Sadly, this does not work.
It seems NM queries resolved for the local IP address and gets "linux"
and sets that as the transient hostname. Resolved has a "fallback hostname"
(that will now again be "fedora"), but it also has a fallback fallback hostname
that is "linux" that it used in reverse dns queries and such. NM gets
the "linux" name and tells hostnamed to use that as the transient hostname.
I don't think this is an improvement, since "linux" is a problematic
as "fedora". So let's revert this for now to avoid pointless churn,
until we figure out a real solution.
Unset fallback-hostname as plenty of applications expected localhost
to mean "default hostname" without ever standardising it (#1892235)
This reverts commit 6eb8bcde28.
DNS questions (which necessarilly include IP addresses) are personally
indentifying information in the sense of GDPR
(https://gdpr.eu/eu-gdpr-personal-data/ explicitly lists IP address as
PII). Sending those packets to Google or Cloudflare is "forwarding"
this PII to them. GDPR says that information which is not enough to
identify individuals still needs to be protected because it may be
combined with other information or processed with improved technology
later. So even though the information in DNS alone it not very big, it
may be interpreted as protected information in various scenarios.
When Fedora is installed by an end-user, they must have the reasonable
expectation that Fedora will contant Fedora servers for updates and
status checks and such. But the case of DNS packets is different,
because the dns servers are not under our control. While most of the
time the information leak through DNS is negligible, we can't rule out
scenarios where it could be considered more important.
Another thing to consider is that ISP and other local internet access
mechanisms are probably worse overall for privacy compared to google and
cloudflare dns servers. Nevertheless, they are more obvious to users and
fit better in the regulatory framework, because there are local laws
that govern them and implicitic or explicit agreements for their use.
Whereas US-based servers are foreign and are covered by different rules.
The fallback DNS servers don't matter most of the time because
NetworkManager will include the servers from a DHCP lease. So
hopefully users will not see any effect from the change done in this
patch. Right now I think it is better to avoid the legal and privacy
risk. If it turns out this change causes noticable problems, we might
want to reconsider. In particular we could use the fallback servers
only in containers and such which are not "personal" machines and there
is no particular person attached to them.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3C4KESHIMZDB6XCFO4EOBEDV4Q2AVVQ5/
I think we could provide a default dns server list more reasonably if
there was some kind of privacy policy published by Fedora and users
could at least learn about those defaults. Sadly, we don't have any
relevant privacy policy (https://pagure.io/Fedora-Council/tickets/issue/53).
There were some things left in the main package that should have
been in the sub package (including networkd.conf). This is an attempt
to make the list of files in the networkd package more correct.
It explicitly tries to leave sytemd-network-generator and the network
targets in the main package.
This way, if one wants to opt-out of resolved, installing a preset
that disables the service is enough. Previously that would only disable
the service, but a dangling symlink would be created.
Zbigniew Jędrzejewski-Szmek
Michael Catanzaro
Fedora Release Engineering
Pavel Březina
Davide Cavalca
Petr Menšík
Kir Kolyshkin
Adam Williamson
Sahana Prasad
Neal Gompa
David Tardon
Anita Zhang
Yu Watanabe
Josh Boyer
Michel Alexandre Salim
Jonathan G. Underwood
Bastien Nocera
Robert Scheck
Dusty Mabe