IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Build option "link-boot-shared" to build a statically linked bootctl and
systemd-bless-boot by using
-Dlink-boot-shared=false
on systems with full systemd stack except bootctl and systemd-bless-boot,
such as CentOS/RHEL 9.
For LTO to work, the linker has to be called with some magic sauce arguments.
And the easiest way to get those is to just let the compiler to the job for us.
Any recent shim will refuse starting an image that does not have an sbat section
and will do so with a generic "Security Violation" message. And it is very easy
to forget passing -Dsbat-distro=auto to meson when creating a fresh build dir.
Adding sbat info when shim is not used or secure boot is disabled does not hurt
anyone, so default to auto. This still ensures to not add auto-detected info in
case we are cross building.
In upstream, we have a linearly-growing list of net-naming-scheme defines;
we add a new one for every release where we make user-visible changes to the
naming scheme.
But the general idea was that downstream distributions could define their
own combinations (or even just their own names for existing combinations),
so provide stability for their users. So far this required patching of the
netif-naming-scheme.c and .h files to add the new lines.
With this patch, patching is not required:
$ meson configure build \
-Dextra-net-naming-schemes=gargoyle=v238+npar_ari+allow_rerenames,gargoyle2=gargoyle+nspawn_long_hash \
-Ddefault-net-naming-scheme=gargoyle2
or even
$ meson configure build \
-Dextra-net-naming-schemes=gargoyle=v238+npar_ari+allow_rerenames,gargoyle2=gargoyle+nspawn_long_hash,latest=v249 \
-Ddefault-net-naming-scheme=gargoyle2
The syntax is a comma-separated list of NAME=name+name+…
This syntax is a bit scary, but any typos result in compilation errors,
so I think it should be OK in practice.
With this approach, we don't allow users to define arbitrary combinations:
what is allowed is still defined at compilation time, so it's up to the
distribution maintainers to provide reasonable combinations. In this regard,
the only difference from status quo is that it's much easier to do (and harder
to do incorrectly, for example by forgetting to add a name to one of the
maps).
We used 'combo' type for the scheme list. For a while we forgot to add
new names, and recently aa0a23ec86 added v241, v243, v245, and v247.
I want to allow defining new values during configuration, which means
that we can't use meson to verify the list of options. So any value is
allowed, but then two tests are added: one that will fail compilation if some
invalid name is given (other than "latest"), and one that converts
DEFAULT_NET_NAMING_SCHEME to a NamingScheme pointer.
Firmware likes to draw the EFI provided cursor in a weird way that
makes it invisible sometimes. This is even more likely to happen
if unusual colors are picked. It also fails to draw attention to the
user by being very small and not blinking.
Additionally, to make it more clear that we are in edit mode, we
now default to inverting the general default color and use that for
our line edit.
Fixes: #19301
Add support for systemd-tpm2 based LUKS2 device activation
via libcryptsetup plugin. This make the feature (tpm2 sealed
LUKS2 keyslot passphrase) usable from both systemd utilities
and cryptsetup cli.
The feature is configured via -Dlibcryptsetup-plugins combo
with default value set to 'auto'. It get's enabled automatically
when cryptsetup 2.4.0 or later is installed in build system.
This closes an important gap: so far we would reexecute the system manager and
restart system services that were configured to do so, but we wouldn't do the
same for user managers or user services.
The scheme used for user managers is very similar to the system one, except
that there can be multiple user managers running, so we query the system
manager to get a list of them, and then tell each one to do the equivalent
operations: daemon-reload, disable --now, set-property Markers=+needs-restart,
reload-or-restart --marked.
The total time that can be spend on this is bounded: we execute the commands in
parallel over user managers and units, and additionally set SYSTEMD_BUS_TIMEOUT
to a lower value (15 s by default). User managers should not have too many
units running, and they should be able to do all those operations very
quickly (<< 1s). The final restart operation may take longer, but it's done
asynchronously, so we only wait for the queuing to happen.
The advantage of doing this synchronously is that we can wait for each step to
happen, and for example daemon-reloads can finish before we execute the service
restarts, etc. We can also order various steps wrt. to the phases in the rpm
transaction.
When this was initially proposed, we discussed a more relaxed scheme with bus
property notifications. Such an approach would be more complex because a bunch
of infrastructure would have to be added to system manager to propagate
appropriate notifications to the user managers, and then the user managers
would have to wait for them. Instead, now there is no new code in the managers,
all new functionality is contained in src/rpm/. The ability to call 'systemctl
--user user@' makes this approach very easy. Also, it would be very hard to
order the user manager steps and the rpm transaction steps.
Note: 'systemctl --user disable' is only called for a user managers that are
running. I don't see a nice way around this, and it shouldn't matter too much:
we'll just leave a dangling symlink in the case where the user enabled the
service manually.
A follow-up for https://bugzilla.redhat.com/show_bug.cgi?id=1792468 and
fa97d2fcf6.
The general idea with users and groups created through sysusers is that an
appropriate number is picked when the allocation is made. The number that is
selected will be different on each system based on the order of creation of
users, installed packages, etc. Since system users and groups are not shared
between installations, this generally is not an issue. But it becomes a problem
for initrd: some file systems are shared between the initrd and the host (/run
and /dev are probably the only ones that matter). If the allocations are
different in the host and the initrd, and files survive switch-root, they will
have wrong ownership.
This makes the gids build-time-configurable for all groups and users where
state may survive the switch from initrd to the host.
In particular, all "hardware access" groups are like this: files in /dev will
be owned by them. Eventually the new udev would change ownership, but there
would be a momemnt where the files were owned by the wrong group. The
allocations are "soft-static" in the language of Fedora packaging guidelines:
the uid/gid will be used if possible, but we'll fall back to a different
one. TTY_GID is the exception, because the number is used directly.
Similarly, the possibility to configure "soft-static" uids is added for daemons
which may usefully run in the initramfs: systemd-network (lease information and
interface state is serialized to /run), systemd-resolve (stub files and
interface state), systemd-timesync (/run/systemd/timesync).
Journal files are owned by the group systemd-journal, and acls are granted
for wheel and adm.
systemd-oom and systemd-coredump are excluded from this patch: I assume that
oomd is not useful in the initrd, and coredump leaves no state (it only creates
a pipe in /run?).
The defaults are not changed: if nothing is configured, dynamic allocation will
be used. I looked at a Debian system, and the numbers are all different than
on Fedora.
For Fedora, see the list of uids and gids at https://pagure.io/setup/blob/master/f/uidgid.
In particular, systemd-network and systemd-resolve got soft-static numbers to
make it easy to transition from a non-host-specific initrd to a host system
already a few years back (https://bugzilla.redhat.com/show_bug.cgi?id=1102002).
I also requested static allocations for sgx, input, render in
https://pagure.io/packaging-committee/issue/1078,
https://pagure.io/setup/pull-request/27.
This ensures that the fuzz test code is also built by default.
It also increases the test coverage a bit. Compiling the tests
*with* sanitizers is painfully slow, so this is not enabled. But
just compiling them sauté is hardly noticable. Running the tests
increases the test count and runtime:
622 tests, 26 s
to
922 tests, 35 s
I think this is acceptable.
Add SBAT support, when -Dsbat-distro value is specified. One can use
-Dsbat-distro=auto for autodetection of all sbat options. Many meson configure
options added to customize SBAT CSV values, but sensible defaults are auto
detected by default. SBAT support is required if shim v15+ is used to load
systemd-boot binary or kernel.efi (Type II BootLoaderSpec).
Fixes#19247
* Add `bpf-framework` feature gate with 'auto', 'true' and 'false' choices
* Add libbpf [0] dependency
* Search for clang llvm-strip and bpftool binaries in compile time to
generate bpf skeleton.
For libbpf [0], make 0.2.0 [1] the minimum required version.
If libbpf is satisfied, set HAVE_LIBBPF config option to 1.
If `bpf-framework` feature gate is set to 'auto', means that whether
bpf feature is enabled or now is defined by the presence of all of
libbpf, clang, llvm and bpftool in build
environment.
With 'auto' all dependencies are optional.
If the gate is set to `true`, make all of the libbpf, clang and llvm
dependencies mandatory.
If it's set to `false`, set `BPF_FRAMEWORK` to false and make libbpf
dependency optional.
libbpf dependency is dynamic followed by the common pattern in systemd.
meson, bpf: add build rule for socket_bind program
By default, systemd installs various sample configuration files
containing commented-out defaults. Systems seeking to minimize the
number of files in /etc may wish to install directories and
configuration files that have semantic effects, but not install not
commented-out sample configuration files.
Turn install-sysconfdir into a multi-valued option, with a "no-samples"
value to skip installing sample-only configuration files.
This change improves integration with distributions using locale-gen to
generate missing locale on-demand, like Debian-based distributions
(Debian/Ubuntu/PureOS/Tanglu/...) and Arch Linux.
We only ever enable new locales for generation, and never disable them.
Furthermore, we only generate UTF-8 locale.
This feature is only used if explicitly enabled at compile-time, and
will also be inert at runtime if the locale-gen binary is missing.
This speeds up the meson install step by half a second
which, given the trivial changes required to add this
option, makes it worth the effort to support this.
Before:
```
‣ Running build script...
[1/418] Generating version.h with a custom command
Installing /root/build/po/be.gmo to /root/dest/usr/share/locale/be/LC_MESSAGES/systemd.mo
Installing /root/build/po/be@latin.gmo to /root/dest/usr/share/locale/be@latin/LC_MESSAGES/systemd.mo
Installing /root/build/po/bg.gmo to /root/dest/usr/share/locale/bg/LC_MESSAGES/systemd.mo
Installing /root/build/po/ca.gmo to /root/dest/usr/share/locale/ca/LC_MESSAGES/systemd.mo
Installing /root/build/po/cs.gmo to /root/dest/usr/share/locale/cs/LC_MESSAGES/systemd.mo
Installing /root/build/po/da.gmo to /root/dest/usr/share/locale/da/LC_MESSAGES/systemd.mo
Installing /root/build/po/de.gmo to /root/dest/usr/share/locale/de/LC_MESSAGES/systemd.mo
Installing /root/build/po/el.gmo to /root/dest/usr/share/locale/el/LC_MESSAGES/systemd.mo
Installing /root/build/po/es.gmo to /root/dest/usr/share/locale/es/LC_MESSAGES/systemd.mo
Installing /root/build/po/fr.gmo to /root/dest/usr/share/locale/fr/LC_MESSAGES/systemd.mo
Installing /root/build/po/gl.gmo to /root/dest/usr/share/locale/gl/LC_MESSAGES/systemd.mo
Installing /root/build/po/hr.gmo to /root/dest/usr/share/locale/hr/LC_MESSAGES/systemd.mo
Installing /root/build/po/hu.gmo to /root/dest/usr/share/locale/hu/LC_MESSAGES/systemd.mo
Installing /root/build/po/id.gmo to /root/dest/usr/share/locale/id/LC_MESSAGES/systemd.mo
Installing /root/build/po/it.gmo to /root/dest/usr/share/locale/it/LC_MESSAGES/systemd.mo
Installing /root/build/po/ja.gmo to /root/dest/usr/share/locale/ja/LC_MESSAGES/systemd.mo
Installing /root/build/po/ko.gmo to /root/dest/usr/share/locale/ko/LC_MESSAGES/systemd.mo
Installing /root/build/po/lt.gmo to /root/dest/usr/share/locale/lt/LC_MESSAGES/systemd.mo
Installing /root/build/po/pl.gmo to /root/dest/usr/share/locale/pl/LC_MESSAGES/systemd.mo
Installing /root/build/po/pt_BR.gmo to /root/dest/usr/share/locale/pt_BR/LC_MESSAGES/systemd.mo
Installing /root/build/po/ro.gmo to /root/dest/usr/share/locale/ro/LC_MESSAGES/systemd.mo
Installing /root/build/po/ru.gmo to /root/dest/usr/share/locale/ru/LC_MESSAGES/systemd.mo
Installing /root/build/po/sk.gmo to /root/dest/usr/share/locale/sk/LC_MESSAGES/systemd.mo
Installing /root/build/po/sr.gmo to /root/dest/usr/share/locale/sr/LC_MESSAGES/systemd.mo
Installing /root/build/po/sv.gmo to /root/dest/usr/share/locale/sv/LC_MESSAGES/systemd.mo
Installing /root/build/po/tr.gmo to /root/dest/usr/share/locale/tr/LC_MESSAGES/systemd.mo
Installing /root/build/po/uk.gmo to /root/dest/usr/share/locale/uk/LC_MESSAGES/systemd.mo
Installing /root/build/po/zh_CN.gmo to /root/dest/usr/share/locale/zh_CN/LC_MESSAGES/systemd.mo
Installing /root/build/po/zh_TW.gmo to /root/dest/usr/share/locale/zh_TW/LC_MESSAGES/systemd.mo
Installing /root/build/po/pa.gmo to /root/dest/usr/share/locale/pa/LC_MESSAGES/systemd.mo
real 0m1.467s
user 0m1.064s
sys 0m0.392s
```
After (with translations disabled):
```
‣ Running build script...
[1/418] Generating version.h with a custom command
real 0m0.925s
user 0m0.622s
sys 0m0.301s
```
Back in 5248e7e1f1 (July 2017) we moved over to
"_gateway", with the old name declared to be temporary measure. Since we're
doing a bunch of changes to resolved now, it seems to be a good moment to make
this simplification and not add support for the compat name in new code.
This is useful for development where overwriting files out side
the configured prefix will affect the host as well as stateless
systems such as NixOS that don't let packages install to /etc but handle
configuration on their own.
Alternative to https://github.com/systemd/systemd/pull/17501
tested with:
$ mkdir inst build && cd build
$ meson \
-Dcreate-log-dirs=false \
-Dsysvrcnd-path=$(realpath ../inst)/etc/rc.d \
-Dsysvinit-path=$(realpath ../inst)/etc/init.d \
-Drootprefix=$(realpath ../inst) \
-Dinstall-sysconfdir=false \
--prefix=$(realpath ../inst) ..
$ ninja install
There are downsides to using fexecve:
when fexecve is used (for normal executables), /proc/pid/status shows Name: 3,
which means that ps -C foobar doesn't work. pidof works, because it checks
/proc/self/cmdline. /proc/self/exe also shows the correct link, but requires
privileges to read. /proc/self/comm also shows "3".
I think this can be considered a kernel deficiency: when O_CLOEXEC is used, this
"3" is completely meaningless. It could be any number. The kernel should use
argv[0] instead, which at least has *some* meaning.
I think the approach with fexecve/execveat is instersting, so let's provide it
as opt-in.
We want to compile the new code in CI without having to explicitly specify
-Doomd=true everywhere. Let's enable it by default, and rely on distros
setting -Dmode=release to not have it enabled by default.
We don't (and shouldn't I think) look at them when determining the type of the
user, but they should be used during user/group allocation. (For example, an
admin may specify SYS_UID_MIN==200 to allow statically numbered users that are
shared with other systems in the range 1–199.)
It makes little sense to make the boundary between systemd and user guids
configurable. Nevertheless, a completely fixed compile-time define is not
enough in two scenarios:
- the systemd_uid_max boundary has moved over time. The default used to be
500 for a long time. Systems which are upgraded over time might have users
in the wrong range, but changing existing systems is complicated and
expensive (offline disks, backups, remote systems, read-only media, etc.)
- systems are used in a heterogenous enviornment, where some vendors pick
one value and others another.
So let's make this boundary overridable using /etc/login.defs.
Fixes#3855, #10184.
This means that the dbus doc consistency checks will be enabled by default,
including in the CI. I think that will work better than current state where
people do not enable them and them follow-up patches for the docs like the
parent commit must be had.
This adds an option to build standalone binaries that do not depend on the
systemd-shared library. This option can be handy to build binaries that can be
useful on a non-systemd system, binaries such as systemd-sysusers and
systemd-tmpfiles have been previously requested, but installing them with all
the required dependencies pulls in too much code that isn't really relevant for
those use cases. The standalone use case is also relevant in containers, where
minimizing the size of the container image is quite relevant.
For now, only `systemd-sysusers` is also built as a standalone binary.
The standalone binaries are installed as `/usr/bin/%{name}.standalone`, the
packaging system is reponsible for renaming those into the correct names
during the packaging step. RPM is able to do so with RemovePathPostfixes:
The default behavior is to build shared binaries only, since this option is
mainly intended for building distribution packages.
Tested that a proper separate binary is built when using this option and
that having it disabled (or using the default Meson configuration) does not
produce a binary for this option.
This generator can be used by desktop environments to launch autostart
applications and services. The feature is an opt-in, triggered by
xdg-desktop-autostart.target being activated.
Also included is the new binary xdg-autostart-condition. This binary is
used as an ExecCondition to test the OnlyShowIn and NotShowIn XDG
desktop file keys. These need to be evaluated against the
XDG_CURRENT_DESKTOP environment variable which may not be known at
generation time.
Co-authored-by: Henri Chain <henri.chain@enioka.com>
The slow-tests= option already enables fuzzers as well, however, this
option can't be used in the "fully sanitized" runs, as certain slow
tests are affected by the performance quite significantly.
This option allows us to enable only fuzzers without the slow tests to
meet the needs of such runs.
