Typically when DHCP server sets MTU it is a lower one. And a lower than usual
MTU is then thus required on said network to have operational networking. This
makes networkd's dhcp client to work in more similar way to other dhcp-clients
(e.g. isc-dhcp). In particular, in a cloud setting, without this default
instances have resulted in timing out talking to cloud metadata source and
failing to provision.
This does not change this default for the Annonymize code path.
For the session identifier, the code is currently slightly stricter, because it
only uses digits and letters, than the description. This should be OK.
Fixes#6745.
The document on the wiki is partially outdated and not very visible. Let's
import the gist of it here. The original text is retained, with only grammar
and stylistic and formatting changes.
The problem was with the tm.tm_isdst that is set to the current environment
value: either DST or not. While the current state is not relevant to the state
in the desired date.
Hence — it should be reset so that the mktime_or_timegm could normalise it
later.
Commit 0e8856d2 (assemble multidevice btrfs volumes without external
tools (#6607)) introduced a call to udevadm. That lives in @rootbindir@,
not @rootlibexecdir@. So fix the path.
We settled on "filename" and "file system", so change a couple of places for
consistency. The exception is when there's an adjective before "file" that
binds more strongly then "name": "password file name", "output file name", etc.
Those cases are left intact.
We want that cryptsetup can cache keys between multiple invocations, and
it does so via the root user's user keyring, hence let's share it among
services.
Replaces: #6286
Usually, it's a good thing that we isolate the kernel session keyring
for the various services and disconnect them from the user keyring.
However, in case of the cryptsetup key caching we actually want that
multiple instances of the cryptsetup service can share the keys in the
root user's user keyring, hence we need to be able to disable this logic
for them.
This adds KeyringMode=inherit|private|shared:
inherit: don't do any keyring magic (this is the default in systemd --user)
private: a private keyring as before (default in systemd --system)
shared: the new setting
Fixes#4871.
The new libmount has two changes relevant for us:
- x-* options are propagated to /run/mount/utab and are visible through
libmount (fixes#4817).
- umount -c now really works (partially solves #6115).
Add Router Advertisement DNS Search List option as specified
in RFC 8106. The search list option uses and identical option
header as the RDNSS option and therefore the option header
structure can be reused.
If systemd is compiled with IDNA support, internationalization
of the provided search domain is applied, after which the search
list is written in wire format into the DNSSL option.
Parse DNS search domains from .network files so that they are included
in Router Advertisement DNSSL options.
DNS search domains are added to the [IPv6PrefixDelegation] section using
the following syntax:
Domains=foo.example.com bar.example.com
If IDNA libraries are enabled in systemd, international domain names
are supported.
That advice is generally apropriate for "user" programs, i.e. programs which
are run interactively and used pipelines and such. But it makes less sense for
daemons to propagate the exit signal. For example, if a process receives a SIGTERM,
it is apropriate for it to exit with 0 code. So let's just delete the whole
paragraph, since this page doesn't seem to be the right place for the longer
discussion which would be required to mention all the caveats and considerations.
Fixes#6415.
This reverts commit 0ffddc6e2c. That
causes a rather severe disruption of D-Bus and other services when e. g.
restarting local-fs.target (as spotted by the "storage" test regression).
Fixes#6834
If two separate log streams are connected to stdout and stderr, let's
make sure $JOURNAL_STREAM points to the latter, as that's the preferred
log destination, and the environment variable has been created in order
to permit services to automatically upgrade from stderr based logging to
native journal logging.
Also, document this behaviour.
Fixes: #6800
When building without veracrypt, gcc warns
../src/cryptsetup/cryptsetup.c:55:13: warning: ‘arg_tcrypt_veracrypt’ defined but not used [-Wunused-variable]
static bool arg_tcrypt_veracrypt = false;
Fix this by conditionalizing the declaration.
Routing Policy rule manipulates rules in the routing policy database control the
route selection algorithm.
This work supports to configure Rule
```
[RoutingPolicyRule]
TypeOfService=0x08
Table=7
From= 192.168.100.18
```
```
ip rule show
0: from all lookup local
0: from 192.168.100.18 tos 0x08 lookup 7
```
V2 changes:
1. Added logic to handle duplicate rules.
2. If rules are changed or deleted and networkd restarted
then those are deleted when networkd restarts next time
V3:
1. Add parse_fwmark_fwmask
Why
---
The advantage of this is that starting sysinit.target from the emergency
shell will no longer kill the emergency shell and lock you out of the
system. Our docs already claimed that emergency.target was useful for
"starting individual units in order to continue the boot process in steps".
This resolves#6509 for my purposes.
Remaining limitation
--------------------
Starting getty.target will still kill the shell, and if you don't have a
root password you will then be locked out at that point. This is relevant
to distributions which patch the sulogin system to permit logins when the
root password is locked. Both Debian and RedHat used to follow this
behaviour! Debian have been discussing what they could replace it with at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806852
So this doesn't quite achieve perfection, but I think it's a worthwhile
change. It should be easier to understand the logic now it doesn't have
such a big hole in it. Repairing the sysinit stage of the boot is the main
reason we have emergency.target. And as discussed in the issue,
sysinit.target gets pulled in implicitly as soon as any DefaultDependencies
service is activated.
How
---
sysinit.target only needs to conflict with emergency.target. It didn't
need to conflict with emergency.service as well. In theory the conflicts
are pointless, we could just change the dependency of sysinit.target on
local-fs.target from Wants to Requires. However, doing so would mean that
when local-fs fails, the screen is flooded with yellow [DEPEND] failures.
That would hinder the poor unfortunate admin, so let's not do that.
There is no additional ordering requirement against emergency. If the
failure happens, the job for sysinit will be cancelled instantly. We don't
need to worry about when sysinit.target and its dependents would be
stopped, because sysinit waits for local-fs before it starts.
emergency.target is still necessarily stopped once we reach sysinit
(you can't express a one-way conflict in pure unit directives).
This is largely cosmetic... though perhaps it symbolizes that you're no
longer in Emergency Mode if System Initialization is successful ;-).
As a secondary advantage, the getty's which conflict on rescue.service now
need to conflict on emergency.service as well. This makes the system more
uniform and simpler to understand.
The only other effect this should have is that
`systemctl start emergency.target` is now practically the same as
`systemctl start rescue.target`. The only units this command will stop are
the conflicting getty units. Neither of those commands should ever be
used. E.g. they will not stop the gdm.service unit on Fedora 26.
