This is an attempt to clean-up the DHCP lease server type code a bit. We
now strictly use the same enum everywhere, and store server info in an
array. Moreover, we use the same nomenclature everywhere.
This only makes the changes in the sd-dhcp code. The networkd code is
untouched so far (but should be fixed up like this too. But it's more
complicated since this would then touch actual settings in .network
files).
Note that this also changes some field names in serialized lease files.
But given that these field names have not been part of a released
version of systemd yet, such a change should be ok.
This is pure renaming/refactoring, shouldn't actually change any
behaviour.
Prompted by the discussions in #15180.
This is a bit more complex than I hoped, since for PID 1 we need to pass
in the synethetic environment block in we generate on demand.
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
kernel >= 4.5 (with commit 32bc201e19) supports
RTA_EXPIRES netlink attribute to set router lifetime. This simply detect
the kernel version (>=4.5) and set the lifetime properly, fallback to
expiring route in userspace for kernel that doesnt support it.
Signed-off-by: Daniel Dao <dqminh89@gmail.com>
networkd previously knew an enum "ResolveSupport" for configuring
per-interface LLMNR support, resolved had a similar enum just called
"Support", with the same value and similar pasers.
Unify this, call the enum ResolveSupport, and port both daemons to it.
In a couple of cases we maintain configuration settings that know an on
and off state, like a boolean, plus some additional states. We generally
parse them as booleans first, and if that fails check for specific
additional values.
This adds a generalized set of macros for parsing such settings, and
ports one use in resolved and another in networkd over to it.
As it turns out the kernel does not support per-interface IPv6 packet
forwarding controls (unlike as it does for IPv4), but only supports a
global option (#1597). Also, the current per-interface management of the
setting isn't really useful, as you want it to propagate to at least one
more interface than the one you configure it on. This created much grief
(#1411, #1808).
Hence, let's roll this logic back and simplify this again, so that we
can expose the same behaviour on IPv4 and IPv6 and things start to work
automatically again for most folks: if a network with this setting set
is set up we propagate the setting into the global setting, but this is
strictly one-way: we never reset it again, and we do nothing for network
interfaces where this setting is not enabled.
Fixes: #1808, #1597.
There are more than enough calls doing string manipulations to deserve
its own files, hence do something about it.
This patch also sorts the #include blocks of all files that needed to be
updated, according to the sorting suggestions from CODING_STYLE. Since
pretty much every file needs our string manipulation functions this
effectively means that most files have sorted #include blocks now.
Also touches a few unrelated include files.
- Rely everywhere that we use abs() on the error code passed in anyway,
thus don't need to explicitly negate what we pass in
- Never attach synthetic error number information to log messages. Only
log about errors we *receive* with the error number we got there,
don't log any synthetic error, that don#t even propagate, but just eat
up.
- Be more careful with attaching exactly the error we get, instead of
errno or unrelated errors randomly.
- Fix one occasion where the error number and line number got swapped.
- Make sure we never tape over OOM issues, or inability to resolve
specifiers
Yu Watanabe