Let's suppress repeated stub queries coming in, to minimize resource
usage. Many DNS clients are pretty aggressive regarding repeating DNS
requests, hence let's find them and suppress the follow-ups should we
need more time to fulfill the queries.
Luca Boccassi [Sun, 14 Feb 2021 19:29:42 +0000 (19:29 +0000)]
test: install binaries from local d/control file
The source package in the apt cache might be older than the
packaging from salsa.debian.org/systemd-team/systemd so it might not
list all the current binary packages.
This is currently the case for systemd-timesyncd, so TEST-30 fails.
Simply grep the control file rather than using apt-cache when iterating
over the packages contents.
This lists numerical signal values:
$ systemctl --signal list
SIGNAL NAME
1 SIGHUP
2 SIGINT
3 SIGQUIT
...
62 SIGRTMIN+28
63 SIGRTMIN+29
64 SIGRTMIN+30
This is useful when trying to kill e.g. systemd with a specific signal number
using kill. kill doesn't accept our fancy signal names like RTMIN+4, so one
would have to calculate that value somehow. Doing
systemctl --signal list | grep -F RTMIN+4
is a nice way of doing that.
resolved: refuse sending packets to our own stub listeners
A previous commit made sure that when one of our own packets is looped
back to us, we ignore it. But let's go one step further, and refuse
operation if we notice the server we talk to is our own. This way we
won't generate unnecessary traffic and can return a cleaner error.
Let's be more precise in naming this function, after all this doesn#t
actually check if the packet is really ours, but just that the source IP
address is a local one. Hence name it that way.
(This is preparation to add a helper that checks if packet belongs to
local transaction later on)
Let's add some overflow checks. Also, if 0 records are reserved, use
this as indication that a copy shall be done and do not grow the answer
beyond the current size.
resolved: gracefully handle with packets with too large RR count
Apparently, there are plenty routers in place that report an incorrect
RR count in the packets: they declare more RRs than are actually
included.
Let's accept these responses, but let's downgrade them to baseline, i.e.
let's suppress OPT in this case: if they don't even get the RR count
right, let's operate on the absolute baseline, and not bother with
anything fancier such as EDNS.
Prompted-by: https://github.com/systemd/systemd/issues/12841#issuecomment-724063973 Fixes: #3980
Most likely fixes: #12841
units: turn off DNSSEC validation when timesyncd resolves hostnames
We have a chicken and egg problem: validation of DNSSEC signatures
doesn't work without a correct clock, but to set the correct clock we
need to contact NTP servers which requires resolving a hostname, which
would normally require DNSSEC validation.
Let's break the cycle by excluding NTP hostname resolution from
validation for now.
Of course, this leaves NTP traffic unprotected. To cover that we need
NTPSEC support, which we can add later.
core: slightly improve error message on load errors
Let's be a bit more helpful when refusing jobs on units that failed to
load properly. We already have explicit D-Bus errors for the error
conditions that are common and expected (such as "not found"), but for
the rest we so far generate a fairly cryptic message.
Let's try to be friendlier towards users and suggest what to do on such
errors.
Yu Watanabe [Fri, 12 Feb 2021 05:44:42 +0000 (14:44 +0900)]
network: address: do not set IFA_F_PERMANENT flag
The flag is automatically set by kernel when the valid lifetime is
infinite. Note that the flag in netlink message for IPv4 address is
ignored. See set_ifa_lifetime() in kernel's net/ipv4/devinet.c.
But the flag is honored for IPv6 address. And if the flag is set with
finite valid lifetime, the address will not removed automatically by
the kernel.
Yu Watanabe [Thu, 11 Feb 2021 17:56:43 +0000 (02:56 +0900)]
network: address: also set IFA_FLAGS on remove
If an address is assigned with IFA_F_MANAGETEMPADDR, then the flag must
be also set on remove. Otherwise, temporary addresses will not be
removed. See also inet6_rtm_deladdr() in kernel's net/ipv6/addrconf.c.
The helper checks if the UEFI firmware is hooked up to a TPM2 chip. This
is useful to know in trusted boot scenarios, in particular during early
boot in auto-enroll scenarios where we want to know whether TPM2 is
available or not, and the Linux drivers are not loaded yet, and where it
might or not be worth waiting for it.
fsck: make sure we don't read an unitialized variable
This use on %n was completely unnecessary: fprintf returns the number of
characters written. And the issue was that if fprintf failed for whatever
reason, it would not process the %n and m would be unitialized. Rework the
code a bit to simplify it.
Coverity says:
CID 1446387 (#1 of 1): Bad bit shift operation (BAD_SHIFT)
8. negative_shift: In expression 1U << (int)cmd, shifting by a negative amount
has undefined behavior. The shift amount, cmd, is -22.
I don't think there's any issue, unless we forget to set token->data
appropriately. Let's add an assert.
Vinnie Magro [Fri, 29 Jan 2021 00:24:34 +0000 (16:24 -0800)]
networkd: add UseFQDN option for DHCPv6
Similar to DHCPv4's UseHostname option, add a UseFQDN config option in
[DHCPv6] to set the system's transient hostname if the FQDN option is
set in the DHCPv6 response from the server.
Let's use uint32_t everywhere to maintain the seqno, since that's what
the kernel does. Prviously in the reply_callback logic we used 64bit,
for no apparent reason.
Using 32bit also provides us with the benefit that we can avoid using
uint64_hash_ops, and can use trivial_hash_ops instead for the reply
hashmap, so that we can store the seqno in the key pointer directly.
While we are at it, let's make sure we never run into serial collisions
internally (32bit is a lot, but not that much), and let's put a limit on
outstanding serials, to catch programming errors.
I don't think it's realistic to operate without /proc/. Hence, let's
make this explicit.
If one day someone finds a way to do what we need without /proc/ we can
certainly drop this check again, but for now I think it's a lot
friendlier to users to make this explicitly early on instead continuing
to run and then not do what we need to do, oftentimes failing in cryptic
ways.
After all, invoking the tool without /proc/ is not an error that was
specific to some of the lines we process, but it's systematic error that
will show its ugly face in many codepaths down the line.
core: improve log message when unit deactivates cleanly
Whenever a unit deactivates sucessfully we so far generated a message
"unit xyz: succeeded". This is a bit confusing, since various unit types
cannot really "succeed", e.g. a device unit can't really "suceed", not
can a swap unit. In particular in the latter case people would probably
assume that a swap unit that "suceeded" would actually mean a swap was
active now, but the opposite is actually true.
Let's improve this by saying "Deactivated successfully", which hopefully
clears this up.
(I thought about saying "terminated" or "completed" or "finished" or so
instead, but that too doesn#t make sense if you think about unit types
like swaps or devices.)
projects / thirdparty / systemd.git / log
