| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
The argument only exists to be used to override/fill in the RRSIG record
of the answer item. Hence actually use it instead of ignore it.
(Not sure how this got lost earlier.)
Fixes: #18714
|
|\
| |
| | |
resolved: don't follow CNAMEs in the stub anymore
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This determines the redirection target from a CNAME or DNAME RR given it
matches some given RR key.
|
| |
| |
| |
| |
| | |
Practically the same comment is a few lines up covering both parts
anyway, let's remove one.
|
| |
| |
| |
| |
| |
| |
| | |
There's no "answer_auxiliary" object anymore, it's all one "answer"
object, and we have per-item flags that tell us which section things are
from, i.e. from the main answer section, or the additional or
authoritative ones.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
CNAME following was broken by 775ae35403f8f3c01b7ac13387fe8aac1759993f
where we'd not properly collect RRs along the CNAME path. Good thing
though is that we don't have to anymore: since we nowadays propagate all
sections of the upstream replies into the cache and back to stub clients
all the information should already be available anyway, and there's no
need for us to collect it.
Fixes: #18690
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before, we only allowed conditionalizing on controllers, not the hierarchy.
This commit extends this to allow a simple check for v1 (i.e. classic or hybrid),
and v2 (full unified).
An alternative approach would be to add a separate Condition for this, but I'm
not too keen on that, considering that v1 is already being deprecrecated
(c.f. 82f3063218).
|
| |
| |
| |
| | |
The permissive bit it not something a specifier might synthetise
|
|\ \
| | |
| | | |
Stop using fstrings
|
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit b0a336a66929ed2a146888178157bf1af5c8598c.
Fixes #18708.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This partially reverts 7857b6e8383f5debab9544ef3abb15a27830fafa.
Debian 9 has python3.5 which does not have f-strings yet.
Partially fixes #18708.
|
| | |
| | |
| | |
| | |
| | |
| | | |
I left the stuff related to [NextHop] out. There are still
patches outstanding, and we can add a comprehensive entry once
things reached the final form.
|
|\ \ \
| |_|/
|/| | |
Allow overriding of fallback hostname through envvar and os-release field
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This follows the addition of DEFAULT_HOSTNAME= in os-release.
The distinction between the value from os-release or the env var and
the compile-time setting is not made in the api: HostnameSource is
"default" is all cases. I think that this level of detail is not needed,
because the users of this mostly care whether the hostname was set by
user configuration or not.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This provides a fairly comprehensible fix for
https://bugzilla.redhat.com/show_bug.cgi?id=1893417.
This adds yet-another level of configuration:
- /etc/hostname
- transient hostname
- $SYSTEMD_DEFAULT_HOSTNAME
- DEFAULT_HOSTNAME is os-release
- -Dfallback-hostname=
- "linux"
It's a lot of layers, but each has it's own justification.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
See https://bugzilla.redhat.com/show_bug.cgi?id=1893417 for the back story:
the fallback hostname matters a lot in certain environments. Right now the only
way to configure the fallback hostname is by recompiling systemd, which is
obviously problematic in case when the fallback hostname shall differ between
different editions of the same distro that share a single compiled rpm.
By making this overridable through an envvar, we're providing an escape hatch
without making this a top-level api. Later on a way to set this through
os-release is added, but I think the approach with the variable is still
useful. It it very convenient for testing, or to override settings only in a
particular service, etc.
|
| | | |
|
| | |
| | |
| | |
| | | |
parse_os_release() will be used basic/hostname-util.c later on.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The motivation is that variants of the same distro that share the same compiled
rpm want to customize various aspects of the system, in particular the
hostname. In some sense the default hostname is part of the identity of the
system, so setting it through os-release makes sense. In particular, instead of
setting a default value in /etc/hostname, the appropriate default can be baked
into the image, leaving /etc/hostname for local overrides only.
Why make this a separate field instead of e.g. using NAME from os-release?
NAME is already used for other purposes, and it seems likely that people want
to set those independently.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
e3820eeaf11f3b4614cbdfbc85675bc16a486e21 did that replacement XDG_CONFIG_HOME, in one
of two places. Let's use ~/.config everywhere.
Quoting https://github.com/systemd/systemd/pull/18704#discussion_r579465254:
> I'd really drop XDG_CONFIG_HOME from the docs. It's confusing enough as it
> is. Where we don't need the indirections we should not confuse people with
> it, in particular as people might then think it's actually a good idea to use
> that env var and redirect things. I'd just show the literal path everywhere,
> even if we internally use the env var.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is useful for various variables that modify process behaviour. This makes
it easy to set it for pid1 without touching the kernel command line. Even for
the *user manager* this also can be convenient for the unprivileged user, who
cannot modify user@.service definition.
Variables that could be set like this include $SD_EVENT_PROFILE_DELAYS,
$SYSTEMD_FALLBACK_HOSTNAME, $SYSTEMD_MEMPOOL, $SYSTMED_RDRAND, etc.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This changes the paths we read user manager config from in two ways:
- split-usr-root paths are dropped. The user manager is a poster boy for
non-early-boot, so reading dropins only from /usr is appropriate.
- we look at ~/.config/systemd/user.conf. Users should be allowed to override
their own config.
As user managers become more and more used, it becomes more important for users
to customize their own daemon. By reading from ~/.config, this is possible
without privileges.
|
| | |
| | |
| | |
| | | |
No functional change as long as only one path is passed.
|
|\ \ \
| |_|/
|/| | |
Set the AA bit in answers for synthetic records & mDNS
|
| | |
| | |
| | |
| | |
| | |
| | | |
This is required by RFC 6762.
Fixes https://github.com/systemd/systemd/issues/17972
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The stub DNS server is authoritative for the RRs we synthesize, such as
localhost, _gateway, and entries from /etc/hosts, and also for trust anchors.
Partially fixes https://github.com/systemd/systemd/issues/17972
|
| | |
| | |
| | |
| | | |
Fixes #18706.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently translated at 24.8% (47 of 189 strings)
Co-authored-by: Frantisek Sumsal <frantisek@sumsal.cz>
Translate-URL: https://translate.fedoraproject.org/projects/systemd/master/sk/
Translation: systemd/main
|
|\ \ \
| | | |
| | | | |
network: introduce Blackhole= setting in [NextHop] section
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
As similar to unreachable type routes, blackhole nexthops do not have
NHA_OID attribute, so they are managed by Manager.
|
|\ \ \ \
| | | | |
| | | | | |
cryptsetup: unescape ID_PART_ENTRY_NAME udev field
|
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes: #18729
|
| |/ / / |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Use strempty as options might not be set, and add the separator
for each option tuple
|
|\ \ \ \
| | | | |
| | | | | |
backlight: trivial cleanups
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| |_|/ / /
|/| | | | |
three documentation fixes
|
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes: #18725
|
| | | | | |
|