IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We might end up allocating mempools, and when we are unloaded we might
orphan them, thus leaking them. Hence, let's just stick around for good,
so the mempools remain referenced continously and for good, and thus no
memory is leaked (though the memory isn't cleaned up either).
Fixes: #7596
RFC 8080 describes how to use EdDSA keys and signatures in DNSSEC. It
uses the curves Ed25519 and Ed448. Libgcrypt 1.8.1 does not support
Ed448, so only the Ed25519 is supported at the moment. Once Libgcrypt
supports Ed448, support for it can be trivially added to resolve.
The routing policy rule setup logic is moved to the routes setup phase (rather than the addresses setup phase as it is now). Additionally, a call to `link_check_ready` is added to the routing policy rules setup handler. This prevents a race condition with the routes setup handler.
Also give each async handler its own message counter to prevent race conditions when logging successes.
Fixes: #7614
Currently, we accept SERVFAIL after downgrading fully, cache it and move
on. Let's extend this a bit: after downgrading fully, if the SERVFAIL
logic continues to be an issue, then use a different DNS server if there
are any.
Fixes: #7147
On my system the boot and EFI partitions are protected, hence "bootctl
status" can't find the ESP, and then the tool continues with arg_path ==
NULL, which it really should not. Handle these cases, and simply
suppress all output that needs arg_path.
This renames find_esp() to find_esp_and_warn() and tries to normalize its
behaviour:
1. Change the error that is returned when we can't find the ESP to
ENOKEY (from ENOENT). This way the error code can only mean one
thing: that our search loop didn't find a good candidate.
2. Really log about all errors, except for ENOKEY and EACCES, and
document the letter cases.
3. Normalize parameters to the call: separate out the path parameter in
two: an input path and an output path. That way the memory management
is clear: we will access the input parameter only for reading, and
only write out the output parameter, using malloc() memory.
Before the calling convention were quire surprising for internal API
code, as the path parameter had to be malloc() memory and might and
might not have changed.
4. Rename bootctl's find_esp_warn() to acquire_esp(), and make it a
simple wrapper around find_esp_warn(), that basically just adds the
friendly logging for the ENOKEY case. This rework removes double
logging in a number of error cases, as we no longer log here in
anything but ENOKEY, and leave that entirely to find_esp_warn().
5. find_esp_and_warn() now takes a bool flag parameter
"unprivileged_mode", which disables logging in the EACCES case, and
skips privileged validation of the path. This makes the function less
magic, and doesn't hide this internal silencing automatism from the
caller anymore.
With all that in place "bootctl list" and "bootctl status" work properly
(or as good as they can) when I invoke the tools whithout privileges on
my system where /boot is not world-readable
Our CODING_STYLE suggests not comparing with NULL, but relying on C's
downgrade-to-bool feature for that. Fix up some code to match these
guidelines. (This is not comprehensive, the coccinelle output for this
is unfortunately kinda borked)
Failure of systemd to respond on the bus interface was bisected to af6b0ecc
"core: make "taint" string logic a bit more generic and output it at boot".
Failure was presumably caused by trying to append strings to an
unintialized buffer, leading to writing outside the unterminated buffer
and hence undefined behaviour.
The detection of ConditionVirtualisation= relies on the presence of
/proc/xen/capabilities. If the file exists and contains the string
"control_d", the running system is a dom0 and VIRTUALIZATION_NONE should
be set. In case /proc/xen exists, or some sysfs files indicate "xen",
VIRTUALIZATION_XEN should be set to indicate the system is a domU.
With an (old) xenlinux based kernel, /proc/xen/capabilities is always
available and the detection described above works always. But with a
pvops based kernel, xenfs must be mounted on /proc/xen to get
"capabilities". This is done by a proc-xen.mount unit, which is part of
xen.git. Since the mounting happens "late", other units may be scheduled
before "proc-xen.mount". If these other units make use of
"ConditionVirtualisation=", the virtualization detection returns
incorect results. detect_vm() will set VIRTUALIZATION_XEN because "xen"
is found in sysfs. This value will be cached. Once xenfs is mounted, the
next process that runs detect_vm() will get VIRTUALIZATION_NONE.
This misdetection can be fixed by using
/sys/hypervisor/properties/features, which exports the value returned by
the "XENVER_get_features" hypercall. If the bit XENFEAT_dom0 is set, the
domain is the "hardware domain". It is supposed to have permissions to
access all hardware. The used sysfs file is available since v2.6.31.
The commonly used term "dom0" refers to the control domain which runs
the toolstack and has access to all hardware. But the virtualization
host may be configured such that one dedicated domain becomes the
"hardware domain", and another one the "toolstack domain".
This option allows a device path to be specified for the systemd
watchdog (both runtime and shutdown).
If a system requires a watchdog other than /dev/watchdog (pointing to
/dev/watchdog0) to be used to reboot the system, this setting should be
changed to the relevant watchdog device path (e.g. /dev/watchdog1).
Currently systemd hardcodes the use of /dev/watchdog. This is a legacy
chardev that points to watchdog0 in the system.
Modify the watchdog API to allow a different device path to be passed
and stored. Opening the watchdog defaults to /dev/watchdog, maintaining
existing behavior.
It would be nicer to use <footnote> to place the notes directly in the table,
but docbook renders this improperly.
v2:
- also add "RequiredBy=" to the notes section
- remove duplicated paragraph
v3:
- clarify the description
- drop References/ReferenceBy which are only shown in systemd-analyze dump
When another networking daemon or configuration is handling the
uplink connection, systemd-networkd won't have a network configuration
associated with the link, and therefore link->network will be NULL.
An assert will be triggered later on in the code when link->network is
NULL.
It might happen that a DNS-SD service doesn't include local host's
name in its RR keys and still conflicts with a remote service.
In this case try to resolve the conflict by changing name for
this particular service.
As discussed in RFC 6762, Section 8.2 a race condition may
happen when two hosts are probing for the same name simultaniously.
Detect and handle such race conditions.
According to RFC 6762 Section 8.2 "Simultaneous Probe Tiebreaking"
probing queries' Authority Section is populated with proposed
resource records in order to resolve possible race conditions.
From RFC 6762, Section 10.2
"They (the rules about when to set the cache-flush bit) apply to
startup announcements as described in Section 8.3, "Announcing",
and to responses generated as a result of receiving query messages."
So, set the cache-flush bit for mDNS answers except for DNS-SD
service enumerattion PTRs described in RFC 6763, Section 4.1.
According to p5.3 of RFC6762 (Multicast DNS) one mDNS query message
can contain more than one question sections.
Generate answers for all found questions and put them to a reply
message.
Update detect_vm_xen_dom0 to propagate errors in case reading
/proc/xen/capabilites fails. This does not fix any bugs, it just makes
it consistent with other functions called by detect_vm.
