Merge pull request #17998 from mrc0mmand/qemu-drop-trailing-whitespace

test: drop the trailing whitespace from the QEMU version check

Merge pull request #17702 from rnhmjoj/master

Extend $SYSTEMD_COLORS to switch colors mode

Merge pull request #17026 from fw-strlen/nft_16

add networkd/nspawn nftables backend

udev: Extract RAM properties from DMI information

Add memory_id program to set properties about the physical memory
devices in the system. This is useful on machines with removable memory
modules to show how the machine can be upgraded, and on all devices to
detect the actual RAM size, without relying on the OS accessible amount.

Closes: #16651

tree-wide: fix typo

test-login: skip consistency checks when logind is not active

There are two ways in swich sd_login_* functions acquire data:
some are derived from the cgroup path, but others use the data serialized
by logind.

When the tests are executed under Fedora's mock, without systemd-spawn
but instead in a traditional chroot, test-login gets confused:
the "outside" cgroup path is visible, so sd_pid_get_unit() and
sd_pid_get_session() work, but sd_session_is_active() and other functions
that need logind data fail.

Such a buildroot setup is fairly bad, but it can be encountered in the wild, so
let's just skip the tests in that case.

/* Information printed is from the live system */
sd_pid_get_unit(0, …) → "session-237.scope"
sd_pid_get_user_unit(0, …) → "n/a"
sd_pid_get_slice(0, …) → "user-1000.slice"
sd_pid_get_session(0, …) → "237"
sd_pid_get_owner_uid(0, …) → 1000
sd_pid_get_cgroup(0, …) → "/user.slice/user-1000.slice/session-237.scope"
sd_uid_get_display(1000, …) → "(null)"
sd_uid_get_sessions(1000, …) → [0] ""
sd_uid_get_seats(1000, …) → [0] ""
Assertion 'r >= 0' failed at src/libsystemd/sd-login/test-login.c:104, function test_login(). Aborting.

networkd: handle ignoring ll gateway being link ll

In the event where network discovery gets a route with the gateway being
the interfaces local link address, networkd will fail the interface.

systemd-networkd[44319]: br_lan: Configuring route: dst: fdcd:41a4:5559:ec03::/64, src: n/a, gw: fe80::e4da:7eff:fe77:5c5e, prefsrc: n/a, scope: global, table: main, proto: ra, type: unicast
systemd-networkd[44319]: br_lan: Could not set NDisc route or address: Gateway can not be a local address. Invalid argument
systemd-networkd[44319]: br_lan: Failed
systemd-networkd[44319]: br_lan: State changed: configuring -> failed

This patch, instead of allowing the interface to fail, will instead log
the event and skip setting the route.

Merge pull request #17799 from yuwata/oss-fuzz-25353

logs-show: skip non-utf8 name entries

Translated using Weblate (Swedish)

Currently translated at 67.3% (126 of 187 strings)

Co-authored-by: Luna Jernberg <bittin@reimu.nl>
Translate-URL: https://translate.fedoraproject.org/projects/systemd/master/sv/
Translation: systemd/master

tree-wide: fix typo

Merge pull request #17859 from keszybz/hostnamed-export-hostname-origin-and-simplify-logic

Export hostname origin and simplify logic in hostamed

test: s/MUMA/NUMA/

test: drop the trailing whitespace from the QEMU version check

I suspect the original version of the regex was written on a system,
which prints both the QEMU version and the QEMU package version in the
--version output, like Fedora:

$ /bin/qemu-system-x86_64 --version
QEMU emulator version 4.2.1 (qemu-4.2.1-1.fc32)
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers

However, Arch Linux prints only the QEMU version:
$ /bin/qemu-system-x86_64 --version
QEMU emulator version 5.2.0
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers

This causes the awk regex to not match the version string, since there's
no whitespace after it, causing the version check to fail (as well as the
TEST-36-NUMAPOLICY) as well.

Follow-up for 43b49470d1f2808555c07f64cd0a1529b7ddd559.

sd-netlink: routing policy rule port to fib_rule_hdr

resolved: always take a timestamp when first seeing a packet

This is later useful if we want to adjust the TTLs of packets we want to
propagate to clients.

sd-dhcp-client: fix renew/rebind timeout calculation to avoid infinite loop

unfortunately I missed adding the timeout to 'now' which results in
an endless loop of renewal timeouts.

Fixes: 3a23834d6b0da391c1ba9cb79a7d7deea7125f4b

hostnamed,shared/hostname-setup: expose the origin of the current hostname

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.

hostnamed: stop discriminating against "localhost" in /etc/hostname

We would sometimes ignore localhost-style names in /etc/hostname. That is
brittle. If the user configured some hostname, it's most likely because they
want to use that as the hostname. If they don't want to use such a hostname,
they should just not create the config. Everything becomes simples if we just
use the configured hostname as-is.

This behaviour seems to have been a workaround for Anaconda installer and other
tools writing out /etc/hostname with the default of "localhost.localdomain".
Anaconda PR to stop doing that: https://github.com/rhinstaller/anaconda/pull/3040.
That might have been useful as a work-around for other programs misbehaving if
/etc/hostname was not present, but nowadays it's not useful because systemd
mostly controls the hostname and it is perfectly happy without that file.

Apart from making things simpler, this allows users to set a hostname like
"localhost" and have it honoured, if such a whim strikes them.

hostnamed: improve message about static hostname

Changed static hostname to 'n/a' is not very nice.

hostnamed: minor style cleanups

hostnamed: when hostname is set to existing value, suppress notifications

When the hostname is set through network config or such, let's
optimize things a bit by suppressing the logs and dbus notifications.

shared/hostname-setup: leave the terminator byte alone

gethostname(3) says it's unspecified whether the string is properly terminated
when the hostname is too long. We created a buffer with one extra byte, and it
seems the intent was to let that byte serve as terminator even if we get an
unterminated string from gethostname().

shared/hostname-setup: add mode where we check what would be set, without doing

This allows the 'unsafe' mark to be removed from the test.

Move hostname setup logic to new shared/hostname-setup.[ch]

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.

hostnamed: fix return value

hostnamed: expose the fallback-hostname setting as a const dbus property

Various users want to know what the fallback hostname is. Since it was made
configurable in 8146c32b9264a6915d467a5cab1a24311fbede7e, we didn't expose this
nicely.

man/hostnamectl,hostaned,hostname1: adjust the docs to match reality

The semantics were significantly changed in c779a44222161155c039a7fd2fd304c006590ac7
("hostnamed: Fix the way that static and transient host names interact", Feb. 2014),
but when the dbus api documentation was imported much later, it wasn't properly
adjusted to describe those new semantics.

34293dfafd2a81d80727938199769906dab321bd which added systemd.hostname= also
added new behaviour.

Let's ove various bits and pieces around so that they are in more appropriate
places. Drop recommendations to set the hostname for DHCP or mDNS purposes.
Nowadays we expect tools that want to expose some different hostname to the
outside to manage that internally without affecting visible state. Also drop
mentions of DHCP or mDNS directly setting the hostname, since nowadays network
management software is expected to (and does) go through hostnamed.

Also, add a high-level description of semantics. It glosses over the details of
handling of localhost-style names. Later commits will remove this special handling
anyway.

coredumpctl: Add --debugger-args= option

This commit adds the possibility to pass command line options to the
debugger invoked with coredumpctl debug.

Resolves: #9905

Merge pull request #17968 from yuwata/purge-libudev

udev: do not link with libudev

firewall-util-nft: attempt table recreation when add operation fails

When someone runs 'nft flush ruleset' in the same net namespace
this will also tear down the systemd nat table.

Unlike iptables -t nat -F, which will remove all rules added by
the systemd iptables backend, iptables has builtin chains that cannot
be deleted. IOW, the next add operation will 'just work'.

In the nftables case however, the entire table gets removed.

When the systemd nat table is removed by an external entity next
attempt to add a set element will yield -ENOENT.

If this happens, recreate the table, and, if successful, re-do
the add operation.

Note that this doesn't protect against external sabotage such as
a running 'while true; nft flush ruleset;done'. However, there is
nothing that could be done short of extending the kernel to allow
tables to be "frozen" or otherwise tied to a process such as
systemd-networkd.

firewall-util: add nftables backend

Idea is to use a static ruleset, added when the first attempt to
add a masquerade or dnat rule is made.

The alternative would be to add the ruleset when the init function is called.
The disadvantage is that this enables connection tracking and NAT in the kernel
(as the ruleset needs this to work), which comes with some overhead that might
not be needed (no nspawn usage and no IPMasquerade option set).

There is no additional dependency on the 'nft' userspace binary or other libraries.
sd-netlinks nfnetlink backend is used to modify the nftables ruleset.

The commit message/comments still use nft syntax since that is what
users will see when they use the nft tool to list the ruleset.

The added initial skeleton (added on first fw_add_masquerade/local_dnat
call) looks like this:

table ip io.systemd.nat {
        set masq_saddr {
                type ipv4_addr
                flags interval
                elements = { 192.168.59.160/28 }
        }

        map map_port_ipport {
                type inet_proto . inet_service : ipv4_addr . inet_service
                elements = { tcp . 2222 : 192.168.59.169 . 22 }
        }

        chain prerouting {
                type nat hook prerouting priority dstnat + 1; policy accept;
                fib daddr type local dnat ip addr . port to meta l4proto . th dport map @map_port_ipport
        }

        chain output {
                type nat hook output priority -99; policy accept;
                ip daddr != 127.0.0.0/8 oif "lo" dnat ip addr . port to meta l4proto . th dport map @map_port_ipport
        }

        chain postrouting {
                type nat hook postrouting priority srcnat + 1; policy accept;
                ip saddr @masq_saddr masquerade
        }
}

Next calls to fw_add_masquerade/add_local_dnat will then only add/delete the
element/mapping to masq_saddr and map_port_ipport, i.e. the ruleset doesn't
change -- only the set/map content does.

Running test-firewall-util with this backend gives following output
on a parallel 'nft monitor':

$ nft monitor
add table ip io.systemd.nat
add chain ip io.systemd.nat prerouting { type nat hook prerouting priority dstnat + 1; policy accept; }
add chain ip io.systemd.nat output { type nat hook output priority -99; policy accept; }
add chain ip io.systemd.nat postrouting { type nat hook postrouting priority srcnat + 1; policy accept; }
add set ip io.systemd.nat masq_saddr { type ipv4_addr; flags interval; }
add map ip io.systemd.nat map_port_ipport { type inet_proto . inet_service : ipv4_addr . inet_service; }
add rule ip io.systemd.nat prerouting fib daddr type local dnat ip addr . port to meta l4proto . th dport map @map_port_ipport
add rule ip io.systemd.nat output ip daddr != 127.0.0.0/8 fib daddr type local dnat ip addr . port to meta l4proto . th dport map @map_port_ipport
add rule ip io.systemd.nat postrouting ip saddr @masq_saddr masquerade
add element ip io.systemd.nat masq_saddr { 10.1.2.3 }
add element ip io.systemd.nat masq_saddr { 10.0.2.0/28 }
delete element ip io.systemd.nat masq_saddr { 10.0.2.0/28 }
delete element ip io.systemd.nat masq_saddr { 10.1.2.3 }
add element ip io.systemd.nat map_port_ipport { tcp . 4711 : 1.2.3.4 . 815 }
delete element ip io.systemd.nat map_port_ipport { tcp . 4711 : 1.2.3.4 . 815 }
add element ip io.systemd.nat map_port_ipport { tcp . 4711 : 1.2.3.5 . 815 }
delete element ip io.systemd.nat map_port_ipport { tcp . 4711 : 1.2.3.5 . 815 }
CTRL-C

Things not implemented/supported:
1. Change monitoring.  The kernel allows userspace to learn about changes
   made by other clients (using nfnetlink notifications). It would be
   possible to detect when e.g. someone removes the systemd nat table.
   This would need more work.  Its also not clear on how to react to
   external changes -- it doesn't seem like a good idea to just auto-undo
   everthing.
2. 'set masq_saddr' doesn't handle overlaps.
   Example:

   fw_add_masquerade(true, AF_INET, "10.0.0.0" , 16);
   fw_add_masquerade(true, AF_INET, "10.0.0.0" , 8); /* fails */

With the iptables backend the second call works, as it adds an
independent iptables rule.

With the nftables backend, the range 10.0.0.0-10.255.255.255 clashes with
the existing range of 10.0.0.0-10.0.255.255 so 2nd add gets rejected by the
kernel.

This will generate an error message from networkd ("Could not enable IP
masquerading: File exists").

To resolve this it would be needed to either keep track of the added elements
and perform range merging when overlaps are detected.

However, the add erquests are done using the configured network on a
device, so no overlaps should occur in normal setups.

IPv6 support is added in a extra changeset.

Fixes: #13307

sd-netlink: add a read function

Will be used by nftables nfnetlink backend.
It sends a series of netlink messages that form a nftables
update transaction.

The transaction will then generate a series of ack messages
(or an error).

This function will be used to read these acks.

sd-netlink: add sd_netlink_sendv

nftables uses a transaction-based netlink model: one netlink write
comes with multiple messages.

A 'BEGIN' message to tell nf_tables/kernel that a new transaction starts.

Then, one more messages to add/delete tables/chains/rules etc.

Lastly, an END message that commits all changes.

This function will be used to send all the individual messages that should
make up a single transaction as a single write.

sd-netlink: add nfnetlink helper routines

add nfnetlink_nftables helper functions to:
 * open a new nfnetlink socket to kernel
 * add tables, chains, rules, sets and maps
 * delete/flush table
 * add and delete elements from sets/maps

sd-netlink: add nfnetlink/nftables type system

Will be used by upcoming nftables support -- it will use the netlink
interface directly rather than add another library dependency.

linux: import nf_tables and nfnetlink headers from Linux 5.8

Will be used/needed in the upcoming nfnetlink/nftables support.
This follows existing model where kernel uapi headers are cached
locally.

firewall-util: introduce context structure

for planned nft backend we have three choices:

- open/close a new nfnetlink socket for every operation
- keep a nfnetlink socket open internally
- expose a opaque fw_ctx and stash all internal data here.

Originally I opted for the 2nd option, but during review it was
suggested to avoid static storage duration because of perceived
problems with threaded applications.

This adds fw_ctx and new/free functions, then converts the existing api
and nspawn and networkd to use it.

nspawn: pass userdata pointer, not inet_addr union

Next patch will need to pass two pointers to the callback instead
of just the addr mask.  Caller will pass a compound structure, so
make this 'void *userdata' to de-clutter the next patch.

firewall-util: prepare for alternative to iptables backend

In a nutshell:
1. git mv firewall-util.c firewall-util-iptables.c
2. existing external functions gain _iptables_ in their names
3. firewall-util.c provides old function names
4. build system always compiles firewall-util.c,
   firewall-util-iptables.c is conditional instead (libiptc).
5. On first call to any of the 'old' API functions performs
   a probe that should return the preferred backend.

In a future step, can add firewall-util-FOOTYPE.c, add its
probe function to firewall-util.c and then have calls to
fw_add_masq/local_dnat handed to the detected backend.

For now, only iptables backend exists, and no special probing
takes place for it, i.e. when systemd was built with iptables,
that will be used.  If not, requets to add masquerade/dnat will
fail with same error (-EOPNOTSUPP) as before this change.

For reference, the rules added by the libiptc/iptables backend look like this:

for service export (via systemd-nspawn):
[0:0] -A PREROUTING -p tcp -m tcp --dport $exportedport -m addrtype --dst-type LOCAL -j DNAT --to-destination $containerip:$port
[0:0] -A OUTPUT ! -d 127.0.0.0/8 -p tcp -m tcp --dport $exportedport -m addrtype --dst-type LOCAL -j DNAT --to-destination $containerip:$port

for ip masquerade:
[0:0] -A POSTROUTING -s network/prefix -j MASQUERADE

firewall-util: reject NULL source or address with prefixlen 0

Make sure we don't add masquerading rules without a explicitly
specified network range we should be masquerading for.

The only caller aside from test case is
networkd-address.c which never passes a NULL source.

As it also passes the network prefix, that should always be > 0 as well.

This causes expected test failure:
Failed to modify firewall: Invalid argument
Failed to modify firewall: Invalid argument
Failed to modify firewall: Invalid argument
Failed to modify firewall: Protocol not available
Failed to modify firewall: Protocol not available
Failed to modify firewall: Protocol not available
Failed to modify firewall: Protocol not available

The failing test cases are amended to expect failure on
NULL source or prefix instead of success.

network: Allow to configure interface promiscuous mode

test: use modern qemu numa arguments

Upgrading to qemu 5.2 breaks TEST-36-NUMAPOLICY like:
  qemu-system-x86_64: total memory for NUMA nodes (0x0) should
  equal RAM size (0x20000000)

Use the new (as in >=2014) form of memdev in test 36:
 -object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0

Since some target systems are as old as qemu 1.5.3 (CentOS7) but the new
kind to specify was added in qemu 2.1 this needs to add version parsing and
add the argument only when qemu is >=5.2.

Fixes #17986.

Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>

Merge pull request #17967 from poettering/connect-user-bus

add support for "systemctl --user --machine=foobar@.host" for connecting to user bus of user "foobar"

busctl: add a timestamp to the output of the busctl monitor command

Merge pull request #17908 from ddstreet/dhcpv4_rfc2131_intervals

Fix dhcpv4 renew/rebind intervals to match rfc2131

logs-show: refuse data which contain invalid fields

journal: refuse data which contain invalid fields

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25353.

journal: move journal_field_valid() to journal_file.c

basic/term-util: inline colors_enabled function

There is no need to cache colors_enabled because the function
is now simply calling get_color_mode, which is already cached.

tree-wide: avoid direct use of color macros

basic/term-util: extend $SYSTEMD_COLORS

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.

udev: drop license boilerplate

rules: drop broken links

meson: do not link with libudev

udev: drop unnecessary libudev-util.h inclusions

udevadm: drop udev_queue

udev: introduce udev_queue_is_empty() and udev_queue_init()

libudev: fix indentation

libudev: drop unnecessary headers from libudev-util.c

udev: use encode_devnode_name() instead of udev_util_encode_string()

As udev_util_encode_string() is a simple wrapper of
encode_devnode_name().

udev: rename UTIL_LINE_SIZE -> UDEV_LINE_SIZE and friends

This also moves them to udev-util.h

udev: move util_resolve_subsys_kernel() to udev-util.c

udev: move util_replace_chars() to udev-util.c

udev: move util_path_encode() and rename it to escape_path()

udev: move util_replace_whitespace() to udev-util.c

journalctl: don't skip the entries that have the same seqnum

These two judgement can't judge that two entries are repeating fully.
So i think seqnum is needed to make full judgement.

bus-util: improve logging when we can't connect to the bus

Previously, we'd already have explicit logging for the case where
$XDG_RUNTIME_DIR is not set. Let's also add some explicit logging for
the EPERM/ACCESS case. Let's also in both cases suggest the
--machine=<user>@.host syntax.

And while we are at it, let's remove side-effects from the macro.

By checking for both the EPERM/EACCES case and the $XDG_RUNTIME_DIR case
we will now catch both the cases where people use "su" to issue a
"systemctl --user" operation, and those where they (more correctly, but
still not good enough) call "su -".

Fixes: #17901

stdio-bridge: add support for --system and --user

So far, the bridge always acted as if "--system" was used, i.e. would
unconditionally connect to the system bus. Let's add "--user" too, to
connect to the users session bus.

This is mostly for completeness' sake.

I wanted to use this when making sd-bus's ability to connect to other
user's D-Bus busses work, but it didn't exist so far. In the interest of
keeping things compatible the implementation in sd-bus will not use the
new "--user" switch, and instead manually construct the right bus path
via "--path=", but we still should add the proper switches, as
preparation for a brighter future, one day.

man: document new ability to connect to user of container

sd-bus: add API for connecting to a specific user's user bus of a specific container

This is unfortunately harder to implement than it sounds. The user's bus
is bound a to the user's lifecycle after all (i.e. only exists as long
as the user has at least one PAM session), and the path dynamically (at
least theoretically, in practice it's going to be the same always)
generated via $XDG_RUNTIME_DIR in /run/.

To fix this properly, we'll thus go through PAM before connecting to a
user bus. Which is hard since we cannot just link against libpam in the
container, since the container might have been compiled entirely
differently. So our way out is to use systemd-run from outside, which
invokes a transient unit that does PAM from outside, doing so via D-Bus.
Inside the transient unit we then invoke systemd-stdio-bridge which
forwards D-Bus from the user bus to us. The systemd-stdio-bridge makes
up the PAM session and thus we can sure tht the bus exists at least as
long as the bus connection is kept.

Or so say this differently: if you use "systemctl -M lennart@foobar"
now, the bus connection works like this:

        1. sd-bus on the host forks off:

                systemd-run -M foobar -PGq --wait -pUser=lennart -pPAMName=login systemd-stdio-bridge

        2. systemd-run gets a connection to the "foobar" container's
           system bus, and invokes the "systemd-stdio-bridge" binary as
           transient service inside a PAM session for the user "lennart"

        3. The systemd-stdio-bridge then proxies our D-Bus traffic to
           the user bus.

sd-bus (on host) → systemd-run (on host) → systemd-stdio-bridge (in container)

Complicated? Well, to some point yes, but otoh it's actually nice in
various other ways, primarily as it makes the -H and -M codepaths more
alike. In the -H case (i.e. connect to remote host via SSH) a very
similar three steps are used. The only difference is that instead of
"systemd-run" the "ssh" binary is used to invoke the stdio bridge in a
PAM session of some other system. Thus we get similar implementation and
isolation for similar operations.

Fixes: #14580

sd-bus: 'ret' parameter to sd_bus_query_sender_creds() is not optional, check for it

sd-bus: make credential acquisition more graceful

So far when asked for augmented bus credentials and the process was
already gone we'd fail fatally. Let's make this graceful instead, and
never allow augmenting fail due to PID having vanished — unless the
augmenting is the explicit and only purpose of the requested operation.

This should be safe as clients have to explicitly query the acquired
creds anyway and handle if they couldn't be acquired. Moreover we
already handle permission problems gracefully, thus clients must be
ready to deal with missing creds.

This is useful to make selinux authorization work for short-lived client
proceses. PReviously we'd augment creds to have more info to log about
(the selinux decision would not be based on augmented data however,
because that'd be unsafe), and would fail if we couldn't get it. Now,
we'll try to acquire the data, but if we cannot acquire it, we'll still
do the selinux check, except that logging will be more limited.

firstboot: clean-up the copied hostname, not argv[] directly, as that's ugly

hostname-setup: clarify that failures reading /etc/hostname are ignored

hostname-util: flagsify hostname_is_valid(), drop machine_name_is_valid()

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.

hostname-util: explain what 'LDH' is

logs-show: drop redundant validation of machine name

The immediately following container_get_leader() call validate the name
anyway, no need to twice exactly the same way twice immediately after
each other.

machine: drop really old kdbus left-over

The "x-machine-kernel" dbus address has been removed a long time ago,
hence don't generate it either.

sd-bus: use SOCK_CLOEXEC on one more socket

Fix review comments in added debug log.

Fix build warning.

Handle escape characters in interface name

Updated the patch as per review comments.

Detect special character in dbus interface name

Added debug log to detect special character in dbus interface names.
Helps to detect a case mentioned in https://github.com/systemd/systemd/issues/14636

Translated using Weblate (German)

Currently translated at 61.4% (115 of 187 strings)

Co-authored-by: Fabian Affolter <mail@fabian-affolter.ch>
Translate-URL: https://translate.fedoraproject.org/projects/systemd/master/de/
Translation: systemd/master

resolved: create stub-resolv.conf symlink with correct security label

Use symlink_atomic_label() instead of symlink_atomic() as the symlink
may need a different label than the parent directory.

Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>

Merge pull request #17977 from yuwata/namespace-mount-procfs-follow-up

core/namespace: do not ignore non-EPERM mount error

efi: Only use arm flags if supported

Support gcc 8 on arm

Merge pull request #17936 from keszybz/more-nss-logging

Add debug logging for varlink

timesync: Make delaying attempts to contact servers configurable

```
❯ ssh sus@xx.xx.xx.xx
Last login: Sat Nov 14 17:32:08 2020 from 10.104.45.138
 17:36:19 up 0 min,  0 users,  load average: 0.00, 0.00, 0.00
> systemd-analyze blame
Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs
> systemd-analyze blame
43.954s systemd-time-wait-sync.service
 1.969s systemd-networkd-wait-online.service
 1.559s cloud-init-local.service
 1.039s cloud-init.service
  414ms cloud-final.service
  387ms dracut-initqueue.service
  382ms initrd-switch-root.service
  380ms cloud-config.service
  198ms systemd-journal-flush.service
  136ms systemd-udev-trigger.service
  115ms initrd-parse-etc.service
   97ms systemd-timesyncd.service
   84ms systemd-journald.service

```

After made it configurable and set to 5s

```
❯ ssh sus@xx.xx.xx.xx
Last login: Sat Nov 14 18:41:42 2020 from 10.104.45.138
 18:42:36 up 0 min,  0 users,  load average: 0.16, 0.03, 0.01
> systemd-analyze blame
10.450s systemd-time-wait-sync.service
 8.303s systemd-networkd-wait-online.service
 1.621s cloud-init-local.service
 1.068s cloud-init.service
```

test-network: increase wait_online timeout to handle longer dhcpv4 transient timeout

Previous commits changed the dhcpv4 retransmission algorithm to be
slightly slower, changing the amount of time it takes to notify
systemd-networkd that the dhcpv4 configuration has (transiently)
failed from around 14 second up to 28 seconds.

Since the test_dhcp_client_with_ipv4ll_without_dhcp_server test
configures an interface to use dhcpv4 without any operating dhcpv4
server running, it must increase the amount of time it waits for
the test interface to reach degraded state.

sd-dhcp-client: correct retransmission timeout to match RFC

This changes the retransmission timeout algorithm for requests
other than RENEW and REBIND. Previously, the retransmission timeout
started at 2 seconds, then doubling each retransmission up to a max
of 64 seconds. This is changed to match what RFC2131 section 4.1 describes,
which skips the initial 2 second timeout and starts with a 4 second timeout
instead. Note that -1 to +1 seconds of random 'fuzz' is added to each
timeout, in previous and current behavior.

This change is therefore slightly slower than the previous behavior in
attempting retransmissions when no server response is received, since the
first transmission times out in 4 seconds instead of 2.

Since TRANSIENT_FAILURE_ATTEMPTS is set to 3, the previous length of time
before a transient failure was reported back to systemd-networkd was
2 + 4 + 8 = 14 seconds, plus, on average, 3 seconds of random 'fuzz' for
a transient failure timeout between 11 and 17 seconds. Now, since the
first timeout starts at 4, the transient failure will be reported at
4 + 8 + 16 = 28 seconds, again plus 3 random seconds for a transient
failure timeout between 25 and 31 seconds.

Additionally, if MaxAttempts= is set, it will take slightly longer to
reach than with previous behavior.

sd-dhcp-client: correct dhcpv4 renew/rebind retransmit timeouts

Use the request timeout algorithm specified in RFC2131 section 4.4.5 for
handling timed out RENEW and REBIND requests.

This changes behavior, as previously only 2 RENEW and 2 REBIND requests
were sent, no matter how long the lease lifetime. Now, requests are
send according to the RFC, which results in starting with a timeout
of 1/2 the t1 or t2 period, and halving the timeout for each retry
down to a minimum of 60 seconds.

Fixes: #17909

sd-dhcp-client: simplify dhcp4 t1/t2 parsing

The parsing of the dhcpv4 lease lifetime, as well as the t1/t2
times, is simplified by this commit.

This differs from previous behavior; previously, the lease lifetime and
t1/t2 values were modified by random 'fuzz' by subtracting 3, then adding
a random number between 0 and (slightly over) 2 seconds. The resulting
values were therefore always between 1-3 seconds shorter than the value
provided by the server (or the default, in case of t1/t2). Now, as
described in RFC2131, the random 'fuzz' is between -1 and +1 seconds,
meaning the actual t1 and t2 value will be up to 1 second earlier or
later than the server-provided (or default) t1/t2 value.

This also differs in handling the lease lifetime, as described above it
previously was adjusted by the random 'fuzz', but the RFC does not state
that the lease expiration time should be adjusted, so now the code uses
exactly the lease lifetime as provided by the server with no adjustment.

sd-dhcp-client: add RFC2131 retransmission details

RFC2131, providing the details for dhcpv4, has specific retransmission
intervals that it outlines. This adds functions to compute the timeouts
as the RFC describes.

sd-dhcp-client: track dhcp4 t1, t2, expire times

Add fields to dhcp4 client to track t1, t2, and lease expiry times

sd-dhcp-client: don't log timeouts if already expired

Merge pull request #17960 from yuwata/network-log-routing-policy-rule

network: introduce log_routing_policy_rule()

Merge pull request #17959 from yuwata/network-log-address

network: introduce log_address_debug()

Merge pull request #17958 from yuwata/network-route-log

network: introduce log_route_debug()

core: detect_container() may return negative errno