It turns out that our man page didn't describe the handling of single-label
names almost at all. This probably adds to the confusion regarding the subject.
So let's first describe what our current implementation is doing.
Quoting https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/:
> Applications and platforms that apply a suffix search list to a single-label
> name are in conformance with IETF standards track RFCs. Furthermore,
> applications and platforms that do not query DNS for a TLD are in conformance
> with IETF standards track recommendations
Current behaviour is in line with that recommendation.
For #13763.
Anyone previously using the UseRoutes=false parameter expected their
dhcp4-provided gateway route to be ignored, as well. However, with
the introduction of the UseGateway= parameter, this is no longer true.
In order to keep backwards compatibility, this sets the UseGateway=
default value to whatever UseRoutes= has been set to.
It's not that I think that "hostname" is vastly superior to "host name". Quite
the opposite — the difference is small, and in some context the two-word version
does fit better. But in the tree, there are ~200 occurrences of the first, and
>1600 of the other, and consistent spelling is more important than any particular
spelling choice.
We use udev to wait for /dev/loopX devices to be fully proped hence we
need an implicit ordering dependency on it, for RootImage= to work
reliably in early boot, too.
Fixes: #14972
Follow-up for f92c8d1c67.
directives.index:
- This index contains 3398 entries in 19 sections, referring to 333 individual
+ This index contains 4316 entries in 19 sections, referring to 333 individual
This is useful to raise the log level for a single transaction or a few,
without affecting other state of the resolved as a restart would.
The log level can only be set, I didn't bother with having the ability
to restore the original as in pid1.
Add manpages.debian.org as a man citeref "project", so we can refer to man
pages hosted there. resolvconf(8) doesn't seem to appear on any of the ones we
currently have defined.
We are doing a trick, where our man page is installed as resolvconf(1), and
we refer the reader to resolvconf(8). This can be pretty confusing, so the
least we can do is to provide a non-broken symlink ;)
v2:
- link to manpages.d.o instead of manpages.ubuntu.com, because debian is the
upstream here, and because with debian we can use /unstable/ as the version,
and ubuntu doesn't seem to have any such shortcut, so the version would need
to be periodically updated.
When someone knows how the whole ecosystem works, this is understandable.
But for someone coming from a system where resolvconf updates /etc/resolv.conf
directly, this can be rather surprising.
For https://bugzilla.redhat.com/show_bug.cgi?id=1815605.
Let's make it optional whether auditing is enabled at journald start-up
or not.
Note that this only controls whether audit is enabled/disabled in the
kernel. Either way we'll still collect the audit data if it is
generated, i.e. if some other tool enables it, we'll collect it.
Fixes: #959
This clarifies some more aspects of `${FOO}` expansions in service
units, mostly trying to answer my own doubts about what happens when
the matching variable is not defined.
This replaces the api export tables with updated versions, and inserts
comments for all "undocumented" items. The slow work of documented them
is left for later ;)
lxml does some formatting changes that are not significant for lxml processing,
but generate spurious difference in the diff (namely: ulinks become one-line,
and double quotes are used instead of single quotes for element attribute
values). This should be a one-time thing: subsequent renegeration should be
idempotent with regards to this.
So far the units there were being documented had only one custom interface.
But for the pid1 case, something more flexibile is needed. So let's add
an annotation in the page what we want to print, and filter in the generator.
As usual, the formatting was fixed and various obvious updates
were done, but nothing major.
I removed documentation of snapshots and related methods though.
The text in the man page provides the justification why I think this is
generally the right thing. An additional reason is that with the previous
commit (to move resolved earlier), since resolved internally implements the
same rules that nss-myhostname does, we'd have this strange inversion where
the priority of external configuration would be different in the "resolve"
path and in the fallback path.