| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Less 568 properly shows urlified strings.
Putative NEWS entry:
* Urlification is now enabled by default even when a pager is used.
Previously it was disabled, because less would not show such markup
properly. This has been fixed in less 568.
Please either upgrade less, or use SYSTEMD_URLIFY=0 to disable the
feature.
|
|
|
|
|
|
(Taken from Michal's #17274 by Lennart, and slightly adjusted)
|
|
Let's a concept of "rate limiting" to event sources: if specific event
sources fire too often in some time interval temporarily take them
offline, and take them back online once the interval passed.
This is a simple scheme of avoiding starvation of event sources if some
event source fires too often.
This introduces the new conceptual states of "offline" and "online" for
event sources: an event source is "online" only when enabled *and* not
ratelimited, and offline in all other cases. An event source that is
online hence has its fds registered in the epoll, its signals in the
signalfd and so on.
|
|
source objects
So far we used these fields to organize the earliest/latest timer event
priority queue. In a follow-up commit we want to introduce ratelimiting
to event sources, at which point we want any kind of event source to be
able to trigger time wakeups, and hence they all need to be included in
the earliest/latest prioqs. Thus, in preparation let's make this
generic.
No change in behaviour, just some shifting around of struct members from
the type-specific to the generic part.
|
|
|
|
sd_event_prepare() invokes callbacks that might drop the last user ref
on our event loop. Let's make sure we keep an explicit ref around it, so
that we won't end up with an invalid pointer. Similar in sd_event_run().
Basically, any function that is publically callable that might end up
invoking callbacks should ref the relevant objects to be protected
against callbacks destroying these objects while we still want to access
them. We did this correctly in sd_event_dispatch() and sd_event_loop(),
but these are not the only ones which are callable from the outside.
|
|
Otherwise it's a bit confusing what this is about: two timestamps.
|
|
earliest/latest prioq
Just some refactoring that makes code prettier, and will come handy
later, because we can reuse these functions at more places.
|
|
Just some simple refactoring, that will make things easier for us later.
But it looks better this way even without the later function reuse.
|
|
|
|
|
|
The comment is pointless, ECC systematically doesn't allow
encryption/decryption directly, only RSA does that. If you want to use
ECC for asymmetric encryption/decryption you have to combine it with key
exchange scheme and symmetric scheme. This all is not a limitation of
the Yubikey, hence don't claim so. It's just how ECC is.
|
|
|
|
Let's move the 3rd way how cryptsetup acquires key files to
read_file_full() too.
Since load_key_file()'s raison d'etre now is just the search path logic,
let's rename the function to find_key_file().
|
|
Previously, we'd load the file with libcryptsetup's calls. Let's do that
in our own, so that we can make use of READ_FULL_FILE_CONNECT_SOCKET,
i.e. read in keys via AF_UNIX sockets, so that people can plug key
providers into our logic.
This provides functionality similar to Debian's keyscript= crypttab
option (see → #3007), as it allows key scripts to be run as socket
activated services, that have stdout connected to the activated socket.
In contrast to traditional keyscript= support this logic runs stuff out
of process however, which is beneficial, since it allows sandboxing and
similar.
|
|
Now that we can read from offsets/with size, let's port the cryptsetup
PKCS#11 key file logic over to read_full_file_full().
|
|
|
|
|
|
|
|
when reading PEM secret key
It's secret data, hence use the appropriate flags.
|
|
We have easy support for this, hence use it for privileged key data.
|
|
|
|
|
|
the cgroup scope
Commit 428a9f6f1d0396b9eacde2b38d667cbe3f15eb55 freed u->pids which is
problematic since the references to this unit in m->watch_pids were no more
removed when the unit was freed.
This patch makes sure to clean all this refs up before freeing u->pids by
calling unit_unwatch_all_pids().
|
|
s/sizeof/ELEMENTSOF/
Bug introduced in 34b87517749caa4142b19eb3c63bdf349fafbc49.
|
|
|
|
|
|
|
|
|
|
Follow-up for 1d370b2c182505ff8033fccbebcc56621d305220.
|
|
This makes an IPv4LL address optional when multiple dynamic
addressing protocols are enabled.
|
|
|
|
|
|
|
|
Fixes #13316.
|
|
So far we only reported major state transitions like failure to acquire
the message. Let's report the initial failure after a few timeouts in
a new event type.
The number of timeouts is hardcoded as 3, since Windows seems to be using
that. I don't think we need to make this configurable out of the box. A
reasonable default may be enough.
|
|
They are not really boolean, because we have both ipv4 and ipv6, but
for each protocol we have either unset, no, and yes.
From https://github.com/systemd/systemd/issues/13316#issuecomment-582906817:
LinkLocalAddressing must be a boolean option, at least for ipv4:
- LinkLocalAddressing=no => no LL at all.
- LinkLocalAddressing=yes + Static Address => invalid configuration, warn and
interpret as LinkLocalAddressing=no, no LL at all.
(we check that during parsing and reject)
- LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the
DHCP one, an LL address must be acquired at start or after a short N
unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a
DHCP address is acquired, drop the LL address. If the DHCP address is lost,
re-adquire a new LL address.
(next patch will move in this direction)
- LinkLocalAddressing=fallback has no reason to exist, because LL address must
always be allocated as a fallback option when using DHCP. Having both DHCP
and LL address at the same time is an RFC violation, so
LinkLocalAdressing=yes correctly implemented is already the "fallback"
behavior. The fallback option must be deprecated and if present in older
configs must be interpreted as LinkLocalAddressing=yes.
(removed)
- And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL
address aren't required to be always set for every IPv6 enabled interface (in
this case, coexisting with static or dynamic address if any)? Shouldn't be
always =yes?
(good question)
This effectively reverts 29e81083bd2fcb2dbf83f67ef358c7d25adf7e9d. There is no
special "fallback" mode now, so the check doesn't make sense anymore.
|
|
|
|
The code was changed in 715cedfbf03a2eb1d4dca5d1b2b876e52a3b652d to allow more than
six attempts and the old description stopped making sense.
|
|
|
|
Coverity CID#1437351. Fixup for f706340979a.
|
|
All otherwise passing Semaphore CI builds are now getting stuck on the
timedated test suite. Let's temporarily skip it until the issue is
resolved.
See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975010
|
|
mappings
On the Dell Inspiron 11 3168 the Fn and Arrow Keys control the Home, End, Page Up and Page Down keys. This commit allows those keys to work correctly.
|
|
Fixes #17736.
|
|
|
|
|
|
|
