Before, we only allowed conditionalizing on controllers, not the hierarchy.
This commit extends this to allow a simple check for v1 (i.e. classic or hybrid),
and v2 (full unified).
An alternative approach would be to add a separate Condition for this, but I'm
not too keen on that, considering that v1 is already being deprecrecated
(c.f. 82f3063218).
I left the stuff related to [NextHop] out. There are still
patches outstanding, and we can add a comprehensive entry once
things reached the final form.
There's no "answer_auxiliary" object anymore, it's all one "answer"
object, and we have per-item flags that tell us which section things are
from, i.e. from the main answer section, or the additional or
authoritative ones.
CNAME following was broken by 775ae35403f8f3c01b7ac13387fe8aac1759993f
where we'd not properly collect RRs along the CNAME path. Good thing
though is that we don't have to anymore: since we nowadays propagate all
sections of the upstream replies into the cache and back to stub clients
all the information should already be available anyway, and there's no
need for us to collect it.
hostnamed: rename FallbackHostname to DefaultHostname
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.
Allow the fallback hostname to be overriden using an environment variable
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.
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.
manager: read ~/.config/systemd/user.conf in user mode
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.
Tyler Hicks [Sun, 21 Feb 2021 18:53:22 +0000 (12:53 -0600)]
man: correct the unit file directory for attached images
Commit 83f72cd65fb8 ("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.
Yu Watanabe [Thu, 18 Feb 2021 22:02:44 +0000 (07:02 +0900)]
sd-device: do not cache action string for uevent file written by sd_device_set_sysattr_value()
As sd_device_get_sysattr_value() may be already used to read uevent
file. The read value of uevent file may be usually quite different
from the action string.
Yu Watanabe [Thu, 18 Feb 2021 14:22:27 +0000 (23:22 +0900)]
sd-device: ignore error in device_cache_sysattr_value() and propagate original error code
There are three calls of device_cache_sysattr_value(). Two of them are
just caching the value. Hence, let's ignore its failure, and propagate
original error code.
One exception is the last call in sd_device_get_sysattr_value().
Unfortunately, it returns `const char *` instead of `char *`. So,
sd_device object must have the reference of the returned value.
Hence, error in updating the cache by device_cache_sysattr_value()
is critical, and we need to propagate the error in that case.
Yu Watanabe [Thu, 18 Feb 2021 08:25:51 +0000 (17:25 +0900)]
sd-device: move comment about NULL value
It is not intuitive, and I do not know why the function behave so.
But let's keep that behavior for compatibility, as such behavior
may be already used explicitly by callers.
man: split out sd_bus_set_fd() man page from sd_bus_get_fd()
sd_bus_get_fd() and related calls are useful for integrating a bus
connection into arbitrary event loops. But sd_bus_set_fd() is quite a
different beast, it's for using D-Bus over pre-initialized sockets or
pairs of fifos or stuff, i.e. very advanced stuff.
Let's split this man page in two, in order not to confuse things
needlessly.
And while we are at it, let's slightly extend the documentation.
systemctl: don't search in the full argv[0] for the invocation name
argv[0] might be prefixed by a path, and we shouldn't get confused by
that. Hence provide a simple helper call that abstracts the checking
away, which we can use everywhere, and expose the same behaviour, even
if argv[0] is not set.
(While we are at it, port all other multi-call binaries over to the new
helper, too)