Let's use the new flag wherever we read key material/passphrases/hashes
off disk, so that people can plug in their own IPC service as backend if
they like, easily.
(My main goal was actually to support this for crypttab key files — i.e.
that you can specify AF_UNIX sockets as third column in crypttab — but
that's harder to implement, since the keys are read via libcryptsetup's
API, not ours.)
967de8face added a note that I found very hard
to understand. Reword it, and also describe how IMPORT and PROGRAM are different
from RUN.
Minor markup adjustements too.
This only sets the environment for user *services*, it has no effect on
sessions, as those get an env block set up by whatever program sets them
up and not systemd.
Now that we make the user/group name resolving available via userdb and
thus nss-systemd, we do not need the UID/GID resolving support in
nss-mymachines anymore. Let's drop it hence.
We keep the module around, since besides UID/GID resolving it also does
hostname resolving, which we care about. (One of those days we should
replace that by some Varlink logic between
nss-resolve/systemd-resolved.service too)
The hooks are kept in the NSS module, but they do not resolve anything
anymore, in order to keep compat at a maximum.
Add support for creating a MACVLAN interface in "source" mode by
specifying Mode=source in the [MACVLAN] section of a .netdev file.
A list of allowed MAC addresses for the corresponding MACVLAN can also
be specified with the SourceMACAddress= option of the [MACVLAN] section.
An example .netdev file:
[NetDev]
Name=macvlan0
Kind=macvlan
MACAddress=02:DE:AD:BE:EF:00
[MACVLAN]
Mode=source
SourceMACAddress=02:AB:AB:AB:AB:01 02:CD:CD:CD:CD:01
SourceMACAddress=02:EF:EF:EF:EF:01
The same keys can also be specified in [MACVTAP] for MACVTAP kinds of
interfaces, with the same semantics.
For users, the square brackets already serve as markup and clearly delineate
the section name from surrounding text. Putting additional markup around that
only adds clutter. Also, we were very inconsistent in using the quotes. Let's
just drop them altogether.
If an entry in fstab uses "x-systemd.automount" option and also asks for
additionnal dependencies via x-systemd.requires or such, then the dependencies
were applied to the automount unit.
But this unlikely to do the right thing and is inconsistent with what's done
for network mounts.
Indeed when an fstab entries has "_netdev,x-systemd.automount" options, the
dependencies against the network requested by "_netdev" are (correctly) applied
to the mount unit only and the automount unit remains ordered against
local-fs.target.
The same logic should be followed when extra deps are specified via the mount
options as automount units should always be ordered against local-fs.target.
Note: in general explicit deps specified via mount options should be used with
care and should be used to specify dependencies on other mount units only as it
can easily create ordering cycles otherwise like it's been seen in
https://github.com/systemd/systemd-stable/issues/69. Mount units (as well as
automount ones) are ordered before local-fs.target by default which is a
low-level target that most other units depend on.
SR-IOV provides the ability to partition a single physical PCI
resource into virtual PCI functions which can then be injected in
to a VM. In the case of network VFs, SR-IOV improves north-south n
etwork performance (that is, traffic with endpoints outside the
host machine) by allowing traffic to bypass the host machine’s network stack.
This allows copying in arbitrary file systems on the block level into
newly created partitions.
Usecase: simple replicating OS installers or OS image builders.
Lennart Poettering