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.
I'm not entirely sure if this is the right form...
Is Conflicts? useful when we have Obsoletes?
Seem to work OK. I tested:
dnf --installroot=... install x86_64/systemd-standalone-sysusers-246.6-2.fc34.x86_64.rpm x86_64/systemd-standalone-tmpfiles-246.6-2.fc34.x86_64.rpm
→ succeeds with a new installation
→ fails if the installroot already had systemd installed
dnf --installroot=... install x86_64/systemd{,-libs,-pam}-246.6-2.fc34.x86_64.rpm noarch/systemd-noarch-246.6-2.fc34.noarch.rpm
→ uninstalls the two standalone packages
These packages include binaries that link to a static version of
libsystemd-shared, so they don't depend on the systemd-libs package at
runtime.
These packages are intended to expose systemd-tmpfiles and systemd-sysusers
to non-systemd systems, such as container images.
Note that static linking only pulls in the small subset of functions from
libsystemd-shared that are actually used by the binaries, so the total size of
a statically linked binary is much smaller than the sum of the shared binary
with the shared library. The resulting binaries on an x86_64 build have 272KB
(tmpfiles) and 180KB (sysusers).
This commit relies on the -Dstandalone-binaries=true build configuration that
was pushed upstream in PR 16061 and released in systemd v246.
We need to disable it by default in resolved so that it doesn't fight
with avahi for the port when both are started up in parallel.
I also moved nss-files before nss-resolve. This is unfortunate because
resolved cached files and with the move, the file will be re-read on each
query. Nevertheless, we want nss-files to have higher priority than nss-mdns
to honour local config. Fortunately, only some people put lots of entries
in /etc/hosts, so the inefficiency incurred by this isn't important for
most users.
nss-myhostname is moved after nss-files, following the change in
upstream recommendations.
error: line 639: Trigger fired by the same package is already defined in spec file: %post libs
It's not clear what rpm is complaining about here, but the two %triggerun's
for the same package seem to be the most likely offender.
I wanted to avoid applying to preset reset twice, alas.
The default line is
> hosts: files dns myhostname
Some people might insert mymachines, most likely as:
> hosts: mymachines files dns myhostname
The scriptlet for nss-mdns inserts mdns before dns:
> hosts: ... files mdns4_minimal [NOTFOUND=return] dns ...
The scriptlet replaces 'files dns myhostname' with
> resolve [!UNAVAIL=return] myhostname files dns
This follows the upstream recommendation. myhostname is ordered earlier
because
a) it's more trustworthy than files or especially dns
b) resolve synthetizes the same answers as myhostname, so it doesn't
make much sense to have myhostname at any other place than directly
after resolve, so that if resolve is not available, we get answers for
the names that myhostname is able to synthesize with the same priority.
See https://fedoraproject.org/wiki/Changes/systemd-resolved.
The acl package is not present in the buildroots when building
in bootstrap mode, but test-acl-util needs /usr/bin/getfacl.
Thus it should be an explicit build-time dependency.
Also only execute the fallback when we're upgrading the RPM package.
Add a comment to indicate the actual bug in systemd v239 we're trying to
fix with this fallback.
Tested: Upgraded from v239 on a machine and confirmed that running
`sudo systemctl status` was working as expected after the upgrade, rather
than failing with "Access denied."
This might be more reliable when upgrading from an older systemd package. The
systemctl call to reexec will occasionally fail with "Access denied" when we
upgrade from a much older version (like 2-3 versions older). However, sending
PID 1 a SIGTERM is documented to be mostly the same and fixes it 100% of the
times.
Signed-off-by: Anita Zhang <the.anitazha@gmail.com>
Signed-off-by: Filipe Brandenburger <filbranden@gmail.com>
0002-Revert-units-set-NoNewPrivileges-for-all-long-runnin.patch was added exactly
a year ago because selinux policy needed to be updated. I think we can drop the
patch now.
Also drop part of 0998-resolved-create-etc-resolv.conf-symlink-at-runtime.patch:
the service runs as unprivileged user, so the creation cannot succeed. The other
part of the patch is kept.
systemd package numbering is completely different than
u2f-hidraw-policy, so I'm using a fixed number. "-40" is supposed to
be sufficiently high so that we stay higher and preserve the upgrade
path even if the package is updated in older releases.
In principle systemd supports building without assertions for production,
but we want the assertions to be enabled to catch as many errors early as possible.
Also, let's remove the obsolete work-around for meson not showing logs. This
is already reverted upstream, but apparently not in the version of macros that
Fedora has.
This makes the package smaller:
-rw-rw-r--. 3840040 Feb 9 14:53 x86_64/systemd-241~rc2-1.fc30.x86_64.rpm
-rw-rw-r--. 3794532 Feb 9 15:58 x86_64/systemd-241~rc2-2.fc30.x86_64.rpm
Important binaries like systemd and libsystemd-shared.so are about
10% smaller.
With input from Pavel Březina.
The guard in install scriptlet was borked. The grep call was supposed
to skip the sed call if the file already had correct contents. But the
condition was always true. Added by me in back in 37de5dfe28 ;(
This was added in da15385b06, November 2016, after
nss-resolve was modified to return a special value. When nss-resolve is added to
new installations, it should be configured in this way already, and we shouldn't
modify configuration. Let's drop this too.
The scriptlet to *add* it was removed in 38d93ea79f,
November 2015. We only care about upgrades from previous two releases, so it is
long overdue to remove this.
We tried this back in 2016 and it didn't go so well, because at
that time, preset-all was badly broken. See
https://bugzilla.redhat.com/show_bug.cgi?id=1363858 for the
history there. It seems that the bugs in preset-all were fixed
quite soon after that, but for whatever reason, the change to
%post was not re-applied (probably it just got forgotten).
We've now run into a bug in Rawhide where dbus-daemon is getting
installed before systemd despite having a dependency that should
make that not happen:
https://bugzilla.redhat.com/show_bug.cgi?id=1647172
this is apparently because there are very complex dependency
loops during initial install that rpm cannot find a single
clearly correct 'answer' for, so it does not always choose to
honor this dependency. We can take a look at breaking up those
loops, but we also figured it can't hurt to resurrect this change
to help with such cases: this way if some service with a preset
*does* happen to get installed before systemd, and so its attempt
to apply the preset in its own %post fails, that will be fixed up
here.
This makes it possible to build RPMs from a git tree using
`rpmbuild --build-in-place --noprep` and have resulting RPMs
that will preserve the override of the PAM config file.
This needs to commit to HAVE_SELINUX being defined (since there
is no longer an m4 step to make that stanza conditional), but
that should be acceptable since the %build step calls Meson
with -Dselinux=true.
Tested:
- Chdir into a checkout of github.com/systemd/systemd tree and run:
$ rpmbuild -bb --build-in-place --noprep \
--define "gitcommit $(git rev-parse HEAD)" \
--define "_sourcedir $HOME/fedorarpms/systemd" \
~/fedorarpms/systemd/systemd.spec
- Inspect the contents of systemd-user in the generated RPM package:
$ rpm2cpio ~/rpmbuild/RPMS/x86_64/systemd-239-3.git99352de.fc29.x86_64.rpm \
| cpio -i --to-stdout --quiet ./etc/pam.d/systemd-user
...
account include system-auth
...
session include system-auth
Existing patches moved to the systemd-stable tarball, with the exception
of 0991-core-fix-resetting-of-Delegate-and-properly-ignore-i.patch,
which was partially reverted upstream and is just removed.
2018-03-06 23:21:31,835 INFO pylorax.dnfhelper: Performing post-installation setup tasks
2018-03-06 23:22:41,901 WARNING pylorax.dnfhelper: Non-fatal POSTTRANS scriptlet failure in rpm package kernel-core
warning: %posttrans(kernel-core-4.16.0-0.rc4.git0.1.fc29.x86_6 scriptlet failed, exit status 1
Please specify the kernel command line in /etc/kernel/cmdline!
Could not determine the kernel command line parameters
/usr/lib/kernel/install.d/90-loaderentry.install: line 53: /proc/cmdline: No such file or directory
GRUB now has BootLoaderSpec support, the user can choose to use this by
setting GRUB_ENABLE_BLSCFG to true in /etc/default/grub. On this setup,
grubby isn't used to generate the kernel modules dependencies, instead
the depmod install script could be used.
But the BLS support in GRUB uses the config snippets that are generated
at build time and included in the kernel package, so the loaderentry
install script shouldn't be executed when using GRUB.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
