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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Previously, valid_until (or preferred_until for preferred lifetime) was
calculated from lifetime. So, when an upstream interface acquire a
dynamic prefix (e.g. through DHCPv6-PD) with long lifetime, then sd-radv
advertise the same lifetime. It may not be desired for some situations.
Let's make sure '@' is never written as entry ID into any EFI variable,
as we want the ability to add new ids like this later on, with them
resulting in a clear error on older implementations.
mkosi automatically builds for the host distro which seems a much
better default to encourage since dnf won't be installed on any host
system that's not Fedora anyway.
Detection of VirtualBox is accomplished in the existing code by *either* `innotek GmbH`
or `Oracle Corporation` existing in any of:
- /sys/class/dmi/id/product_name
- /sys/class/dmi/id/sys_vendor
- /sys/class/dmi/id/board_vendor
- /sys/class/dmi/id/bios_vendor
With Oracle's physical servers, both `/sys/class/dmi/id/sys_vendor` and
`/sys/class/dmi/id/board_vendor` contain `Oracle Corporation`, so those
servers are detected as `oracle` (VirtualBox).
VirtualBox has the following values in the latest versions:
- /sys/class/dmi/id/product_name: `VirtualBox`
- /sys/class/dmi/id/sys_vendor: `innotek GmbH`
- /sys/class/dmi/id/board_vendor: `Oracle Corporation`
- /sys/class/dmi/id/bios_vendor: `innotek GmbH`
Presumably the existing check for `innotek GmbH` is meant to detect
older versions of VirtualBox, while changing the second checked value
from `Oracle Corporation` to `VirtualBox` will reliably detect later and future
versions.
JSON doesn't have NaN/infinity/-infinity concepts in the spec.
Implementations vary what they do with it. JSON5 + Python simply
generate special words "NAN" and "Inifinity" from it. Others generate
"null" for it.
At this point we never actually want to output this, so let's be
conservative and generate RFC compliant JSON, i.e. convert to null.
One day should JSON5 actually become a thing we can revisit this, but in
that case we should implement things via a flag, and only optinally
process nan/infinity/-infinity.
This patch is extremely simple: whenever accepting a
nan/infinity/-infinity from outside it converts it to NULL. I.e. we
convert on input, not output.
The setting is completely meaningless, as WithoutRA= and UseDelegatedPrefix=
in [DHCPv6] section, and DHCPv6Client= in [IPv6AcceptRA] section control
the behavior.
Previously, when a downstream appears which requests delegated prefix to
be assigned, then possibly restart all DHCPv6 clients for another
interfaces.
This makes networkd always honor the UseDelegatedPrefix= setting, and
not restart DHCPv6 clients.
Previously, the prefix delegation is enabled when at least one
downstream interfaces request it. But, when the DHCPv6 client on the
upstream interface is configured, some downstream interfaces may not
exist yet, nor have .network file assigned.
Also, if a system has thousands of interfaces, then the previous logic
introduce O(n^2) search.
This makes the prefix delegation is always enabled, except when it is
explicitly disabled. Hopefully, that should not break anything, as the
DHCPv6 server should ignore the prefix delegation request if the server
do not have any prefix to delegate.
Newer webcams and video devices have controls only available through
/dev/media* nodes. Make sure they're accessible in the same way as
/dev/video* nodes.
Closes: #21054
When a .network file is updated but its change is not so big, it is not
necessary to first drop all configs and then reassign later again.
This slightly optimize such situation. First foreignize all configs, and
then drop later when it is not requested by the updated .network file.
