In hostnamed this is exposed as a dbus property, and in the logs in both
places.
This is of interest to network management software and such: if the fallback
hostname is used, it's not as useful as the real configured thing. Right now
various programs try to guess the source of hostname by looking at the string.
E.g. "localhost" is assumed to be not the real hostname, but "fedora" is. Any
such attempts are bound to fail, because we cannot distinguish "fedora" (a
fallback value set by a distro), from "fedora" (received from reverse dns),
from "fedora" read from /etc/hostname.
/run/systemd/fallback-hostname is written with the fallback hostname when
either pid1 or hostnamed sets the kernel hostname to the fallback value. Why
remember the fallback value and not the transient hostname in /run/hostname
instead?
We have three hostname types: "static", "transient", fallback".
– Distinguishing "static" is easy: the hostname that is set matches what
is in /etc/hostname.
– Distingiushing "transient" and "fallback" is not easy. And the
"transient" hostname may be set outside of pid1+hostnamed. In particular,
it may be set by container manager, some non-systemd tool in the initramfs,
or even by a direct call. All those mechanisms count as "transient". Trying
to get those cases to write /run/hostname is futile. It is much easier to
isolate the "fallback" case which is mostly under our control.
And since the file is only used as a flag to mark the hostname as fallback,
it can be hidden inside of our /run/systemd directory.
For https://bugzilla.redhat.com/show_bug.cgi?id=1892235.
No functional change, just moving a bunch of things around. Before
we needed a rather complicated setup to test hostname_setup(), because
the code was in src/core/. When things are moved to src/shared/
we can just test it as any function.
The test is still "unsafe" because hostname_setup() may modify the
hostname.
This commit extends $SYSTEMD_COLORS to an enum variable (compared to
a simple boolean) which specifies the "colors mode". This means that, in
addition to disabling colors altogether, it's now possible to restrict
the console output to 16 or 256 colors only.
Let's clean up hostname_is_valid() a bit: let's turn the second boolean
argument into a more explanatory flags field, and add a flag that
accepts the special name ".host" as valid. This is useful for the
container logic, where the special hostname ".host" refers to the "root
container", i.e. the host system itself, and can be specified at various
places.
let's also get rid of machine_name_is_valid(). It was just an alias,
which is confusing and even more so now that we have the flags param.
The commit 6f3ac0d517 drops the prefix and
suffix in TAGS= property. But there exists several rules that have like
`TAGS=="*:tag:*"`. So, the property must be always prefixed and suffixed
with ":".
Fixes#17930.
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.
On really old kernels (< 4.14+) a bug in /proc/1/sched handling in the
kernel could be used to determine whether we are running in a PID
namespace. This hasn't worked for a long time, and there's little point
in making things work on old kernels we can't make work on current
kernels, hence let's drop that old cruft.
See: #8153
The BLKID and ELFUTILS strings were present twice. Let's reaarange things so that
each times requires definition in exactly one place.
Also let's sort things a bit:
the "heavy hitters" like PAM/MAC first,
then crypto libs,
then other libs, alphabetically,
compressors,
and external compat integrations.
I think it's useful for users to group similar concepts together to some extent.
For example, when checking what compression is available, it helps a lot to have
them listed together.
FDISK is renamed to LIBFDISK to make it clear that this is about he library and
the executable.
UML runs as a user-process so it can quite easily be ran inside of
another hypervisor, for instance inside a KVM instance. UML passes
through the CPUID from the host machine so in this case detect_vm
incorrectly identifies as running under KVM. So check we are running
a UML kernel first, before we check any other hypervisors.
Resolves: #17754
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
if the source and destination file match in contents and basic file
attributes, don#t rename, but just remove source.
This is a simple way to suppress inotify events + mtime changes when
atomically updating files.
They are not really boolean, because we have both ipv4 and ipv6, but
for each protocol we have either unset, no, and yes.
From https://github.com/systemd/systemd/issues/13316#issuecomment-582906817:
LinkLocalAddressing must be a boolean option, at least for ipv4:
- LinkLocalAddressing=no => no LL at all.
- LinkLocalAddressing=yes + Static Address => invalid configuration, warn and
interpret as LinkLocalAddressing=no, no LL at all.
(we check that during parsing and reject)
- LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the
DHCP one, an LL address must be acquired at start or after a short N
unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a
DHCP address is acquired, drop the LL address. If the DHCP address is lost,
re-adquire a new LL address.
(next patch will move in this direction)
- LinkLocalAddressing=fallback has no reason to exist, because LL address must
always be allocated as a fallback option when using DHCP. Having both DHCP
and LL address at the same time is an RFC violation, so
LinkLocalAdressing=yes correctly implemented is already the "fallback"
behavior. The fallback option must be deprecated and if present in older
configs must be interpreted as LinkLocalAddressing=yes.
(removed)
- And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL
address aren't required to be always set for every IPv6 enabled interface (in
this case, coexisting with static or dynamic address if any)? Shouldn't be
always =yes?
(good question)
This effectively reverts 29e81083bd. There is no
special "fallback" mode now, so the check doesn't make sense anymore.
