| Age | Commit message (Collapse) | Author |
|---|
|
systemd-networkd.service(8)
|
|
Also remove the equivalent functionality from networkd.
|
|
|
|
|
|
To make sure we don't delay boot on systems where (some) network links are managed by someone else
we don't block if something else has successfully brought up a link.
We will still block until all links we are aware of that are managed by networkd have been
configured, but if no such links exist, and someone else have configured a link sufficiently
that it has a carrier, it may be that the link is ready so we should no longer block.
Note that in all likelyhood the link is not ready (no addresses/routes configured),
so whatever network managment daemon configured it should provide a similar wait-online
service to block network-online.target until it is ready.
The aim is to block as long as we know networking is not fully configured, but no longer. This
will allow systemd-networkd-wait-online.service to be enabled on any system, even if we don't
know whether networkd is the main/only network manager.
Even in the case networking is fully configured by networkd, the default behavior may not be
sufficient: if two links need to be configured, but the first is fully configured before the
second one appears we will assume the network is up. To work around that, we allow specifying
specific devices to wait for before considering the network up.
This unit is enabled by default, just like systemd-networkd, but will only be pulled in if
anyone pulls in network-online.target.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also fix a copy-paste error that broke matching on interface name.
|
|
|
|
That's what we do for all options in the other man pages. It helps
clarifying that these are options that values need to be assigned to.
|
|
|
|
|
|
It should match on the driver of the parent device.
|
|
Also enforce that we don't allow setting the Broadcast for IPv6 addresses.
|
|
|
|
Resolve spotted issues related to missing or extraneous commas, dashes.
|
|
Also limit the range of vlan ids. Other implementations and
documentation use the ranges {0,1}-{4094,4095}, but we use
the one accepted by the kernel: 0-4094.
Reported-by: Oleksii Shevchuk <alxchk@gmail.com>
|
|
Both in the configuration file format and everywhere else in the code.
|
|
These connections are never torn down, even when the DHCP specifications say that
they should be. This is useful/necessary when the rootfs (or another critical fs)
is mounted over this network connection, and dataloss would result if the connection
is lost.
This option defaults to off, but our initrd generator (TBD) will enable it when
applicable.
|
|
|
|
Refactor bridging support to be generic netdev support and extend it to
cover bonding as well.
|
|
|
|
|
|
|
|
Setting UseDNS=no will ignore any received DNS servers.
|
|
These keys are mandatory in [Address]/[Route] sections. Otherwise, we
hit an assert:
ens3: setting addresses
Assertion 'address->family == 2 || address->family == 10' failed at /build/amd64-generic/tmp/portage/sys-apps/systemd-9999-r1/work/systemd-9999/src/network/networkd-address.c:137, function address_configure(). Aborting.
Reported-by: Alex Polvi <alex.polvi@coreos.com>
At the same time make sure Route's Destination and Gateway uses the same address family.
|
|
This reverts commit 4cd1214db6cf4b262e8ce6381bc710091b375c96.
This may still be fixed in the kernel, revert this for now until
we see how it all shakes out.
|
|
|
|
When DEVTYPE is not set for a nic, it means it is a wired/ethernet
device.
|
|
This is a recurring submission and includes corrections to:
- missing words, preposition choice.
- change of /lib to /usr/lib, because that is what most distros are
using as the system-wide location for systemd/udev files.
|
|
|
|
|
|
|
|
This will allow specifying more options per address than the
simple Address= entry in the [Network] section.
Preliminary support for the same functionality for [Route] sections
are added, but not yet hooked up, as more testing is needed.
|
|
This removed the requirement for devices to be tagged with
'systemd-networkd' before they will be visible to networkd.
Still, as by default we don't ship any .network files, network
devices will simply be tracked, but not touched, unless the
admin configures things explicitly.
|
|
|
|
|
