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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This follows the addition of DEFAULT_HOSTNAME= in os-release.
The distinction between the value from os-release or the env var and
the compile-time setting is not made in the api: HostnameSource is
"default" is all cases. I think that this level of detail is not needed,
because the users of this mostly care whether the hostname was set by
user configuration or not.
This provides a fairly comprehensible fix for
https://bugzilla.redhat.com/show_bug.cgi?id=1893417.
This adds yet-another level of configuration:
- /etc/hostname
- transient hostname
- $SYSTEMD_DEFAULT_HOSTNAME
- DEFAULT_HOSTNAME is os-release
- -Dfallback-hostname=
- "linux"
It's a lot of layers, but each has it's own justification.
See https://bugzilla.redhat.com/show_bug.cgi?id=1893417 for the back story:
the fallback hostname matters a lot in certain environments. Right now the only
way to configure the fallback hostname is by recompiling systemd, which is
obviously problematic in case when the fallback hostname shall differ between
different editions of the same distro that share a single compiled rpm.
By making this overridable through an envvar, we're providing an escape hatch
without making this a top-level api. Later on a way to set this through
os-release is added, but I think the approach with the variable is still
useful. It it very convenient for testing, or to override settings only in a
particular service, etc.
The motivation is that variants of the same distro that share the same compiled
rpm want to customize various aspects of the system, in particular the
hostname. In some sense the default hostname is part of the identity of the
system, so setting it through os-release makes sense. In particular, instead of
setting a default value in /etc/hostname, the appropriate default can be baked
into the image, leaving /etc/hostname for local overrides only.
Why make this a separate field instead of e.g. using NAME from os-release?
NAME is already used for other purposes, and it seems likely that people want
to set those independently.
e3820eeaf1 did that replacement XDG_CONFIG_HOME, in one
of two places. Let's use ~/.config everywhere.
Quoting https://github.com/systemd/systemd/pull/18704#discussion_r579465254:
> I'd really drop XDG_CONFIG_HOME from the docs. It's confusing enough as it
> is. Where we don't need the indirections we should not confuse people with
> it, in particular as people might then think it's actually a good idea to use
> that env var and redirect things. I'd just show the literal path everywhere,
> even if we internally use the env var.
This is useful for various variables that modify process behaviour. This makes
it easy to set it for pid1 without touching the kernel command line. Even for
the *user manager* this also can be convenient for the unprivileged user, who
cannot modify user@.service definition.
Variables that could be set like this include $SD_EVENT_PROFILE_DELAYS,
$SYSTEMD_FALLBACK_HOSTNAME, $SYSTEMD_MEMPOOL, $SYSTMED_RDRAND, etc.
The stub DNS server is authoritative for the RRs we synthesize, such as
localhost, _gateway, and entries from /etc/hosts, and also for trust anchors.
Partially fixes https://github.com/systemd/systemd/issues/17972
This changes the paths we read user manager config from in two ways:
- split-usr-root paths are dropped. The user manager is a poster boy for
non-early-boot, so reading dropins only from /usr is appropriate.
- we look at ~/.config/systemd/user.conf. Users should be allowed to override
their own config.
As user managers become more and more used, it becomes more important for users
to customize their own daemon. By reading from ~/.config, this is possible
without privileges.
This updates the docs about using fdisk/gdisk to make partitions with the right
partition type UUID as defined in the discoverable partitions spec.
Improve wording/grammar/formatting, and reflect that gdisk supports this as
well nowadays; see https://www.rodsbooks.com/gdisk/revisions.html
Commit 83f72cd65f ("man,docs: document the new unit file directory for
attached images") updated the docs and man page with the new unit file
directory for attached images but included a system.attached ->
systemd.attached typo in the man page portion of the change. Fix the
typo to document the correct path.
