Otherwise, even if the persistent storage is not ready, the DHCP server
may be started e.g. by unplugging and plugging cable.
Follow-up for 5582b36c38.
Then, we can read the lease file on restart, and the DHCP server will be
able to manage previously assigned addresses.
To save leases in the state directory /var/lib/systemd/network/, this
adds systemd-networkd-dhcp-server.service, and by default
systemd-networkd does not start the DHCP server without the heler
service started.
Closes#29991.
And refuse a link-local address.
With the previous commit, now ServerAddress= can take a null address,
but the config parser refused that. Let's allow that now.
Previously, we periodically search suitable address for DHCP server,
1. when .network file is loaded,
2. when checking if we can configure sd_dhcp_server object,
3. when configuring sd_dhcp_server.
Especially, the step 2 may be triggered several times.
This makes, when .network file is loaded, find a corresponding Address
object, add a new Address object if not found, then save the found or
added Address object. So, it is not necessary to find address again on
configuring sd_dhcp_server object.
We need to find a suitable static address for the DHCP server.
So, all static addresses must be verified before network_adjust_dhcp_server()
is called. For safety, let's call it from network_drop_invalid_addresses().
No functional change, just refactoring and preparation for later
commits.
With the previous change, now Address objects under requesting are not
owned by Link object, hence we need to also search corresponding Address
object in the request queue.
This makes Request object takes hash, compare, free, and process functions.
With this change, the logic in networkd-queue.c can be mostly
independent of the type of the request or the object (e.g. Address) assigned
to the request, and it becomes simpler.
This also renames e.g. request_process_address() -> address_process_request().
Also, this drops type checks such as `assert(req->type == REQUEST_TYPE_ADDRESS)`,
as in the later commits, the function of processing request, e.g.
`address_process_request()`, will be assigned to the Request object when
it is created. And the request type will be used to distinguish and to
avoid deduplicating requests which do not have any assigned objects,
like REQUEST_TYPE_DHCP4_CLIENT. Hence, the type checks in process functions
are mostly not necessary and redundant.
This is mostly cleanups and preparation for later commits, and should
not change any behavior.
Previously, the broadcast address was set to a Address object in
address_section_verify() (or address_acquire()). But, for wireguard
interfaces, we do not use the broadcast address. The .network file may
be assigned to multiple interfaces, hence, we cannot determine if we
should set the broadcast address in address_section_verify().
This makes the broadcast address set in link_request_address().
Then, we set the broadcast address only when we need it.
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
E.g. nexthop requires IFF_UP flag, but the currently stored flag may be
outdated if we called link_down(). This makes such requests pending if
at least one of the flags are updating.
networkd already has all information about routes. It is not necessary
to re-read them by using local_gateways().
This also makes manager_find_uplink() take family.
We recently started making more use of malloc_usable_size() and rely on
it (see the string_erase() story). Given that we don't really support
sytems where malloc_usable_size() cannot be trusted beyond statistics
anyway, let's go fully in and rework GREEDY_REALLOC() on top of it:
instead of passing around and maintaining the currenly allocated size
everywhere, let's just derive it automatically from
malloc_usable_size().
I am mostly after this for the simplicity this brings. It also brings
minor efficiency improvements I guess, but things become so much nicer
to look at if we can avoid these allocation size variables everywhere.
Note that the malloc_usable_size() man page says relying on it wasn't
"good programming practice", but I think it does this for reasons that
don't apply here: the greedy realloc logic specifically doesn't rely on
the returned extra size, beyond the fact that it is equal or larger than
what was requested.
(This commit was supposed to be a quick patch btw, but apparently we use
the greedy realloc stuff quite a bit across the codebase, so this ends
up touching *a*lot* of code.)
Yu Watanabe
Lennart Poettering
Susant SahaniandYu Watanabe
Luca Boccassi
Daan De Meyer
David Tardon
Frantisek Sumsal
Zbigniew Jędrzejewski-Szmek
borna-blazevic