Stop pointing at resolvectl on hosts that do not have it #7

2026-08-06T01:33:31-07:00

dejima-agent commented

2026-08-06 01:33:31 -07:00

Summary generated by LLM agent

Finding the upstream resolver is the one setting in this tool that is
genuinely ambiguous, and every place the docs explain it led the answer with
resolvectl status. That command comes from systemd-resolved, which is not
installed on a plain Debian netinst — which is exactly what proxmox/README.md
walks you through building. So the first thing someone reads, at the moment
they are already unsure which address to use, is a command that does not
exist on the machine they are standing on.

grep nameserver /etc/resolv.conf is the answer on that host. This leads
with it and keeps resolvectl for the case it is actually for: a host running
systemd-resolved, where /etc/resolv.conf reports the 127.0.0.53 stub and
the real servers are only visible behind it. The docs now also say plainly not
to install systemd-resolved in order to run the check — it would bind a stub
resolver on a host whose resolver arrangement this tool is in the middle of
configuring, to answer a question /etc/resolv.conf already answers.

Three sites: README.md's "The upstream resolver" section,
etc/config.example's comment on upstream, and bin/dejima-ci-allowlist's
remedy string for a missing/incorrect upstream.

Testing

Documentation only. install.sh already guarded both of its resolvectl
calls (command -v before the detection call, and the diagnostic listing runs
in a group with 2>/dev/null alongside /etc/resolv.conf), so an absent
resolvectl was never a functional failure — it was a functional non-event
that the prose contradicted. Verified bash -n bin/dejima-ci-allowlist and
re-read the three edited passages; no behavioural change to test.

Found while bootstrapping a real runtime VM built from proxmox/README.md,
where resolvectl was absent.

**Summary generated by LLM agent** Finding the upstream resolver is the one setting in this tool that is genuinely ambiguous, and every place the docs explain it led the answer with `resolvectl status`. That command comes from systemd-resolved, which is not installed on a plain Debian netinst — which is exactly what `proxmox/README.md` walks you through building. So the first thing someone reads, at the moment they are already unsure which address to use, is a command that does not exist on the machine they are standing on. `grep nameserver /etc/resolv.conf` is the answer on that host. This leads with it and keeps `resolvectl` for the case it is actually for: a host running systemd-resolved, where `/etc/resolv.conf` reports the `127.0.0.53` stub and the real servers are only visible behind it. The docs now also say plainly not to install systemd-resolved in order to run the check — it would bind a stub resolver on a host whose resolver arrangement this tool is in the middle of configuring, to answer a question `/etc/resolv.conf` already answers. Three sites: `README.md`'s "The upstream resolver" section, `etc/config.example`'s comment on `upstream`, and `bin/dejima-ci-allowlist`'s remedy string for a missing/incorrect `upstream`. ## Testing Documentation only. `install.sh` already guarded both of its `resolvectl` calls (`command -v` before the detection call, and the diagnostic listing runs in a group with `2>/dev/null` alongside `/etc/resolv.conf`), so an absent `resolvectl` was never a functional failure — it was a functional non-event that the prose contradicted. Verified `bash -n bin/dejima-ci-allowlist` and re-read the three edited passages; no behavioural change to test. Found while bootstrapping a real runtime VM built from `proxmox/README.md`, where `resolvectl` was absent.

dejima-agent added 1 commit 2026-08-06 01:33:32 -07:00

Stop pointing at resolvectl on hosts that do not have it 0c7b5fe718

Finding the upstream resolver is the setting people get wrong, and the docs
led the answer with `resolvectl status`. On a plain Debian install - which is
what proxmox/README.md walks you through building - systemd-resolved is not
installed and neither is that command, so the first thing someone reads when
they are already unsure is a command that does not exist.

`grep nameserver /etc/resolv.conf` is the answer on that machine. Lead with
it, and keep resolvectl for the case it is actually for: a host running
systemd-resolved, where resolv.conf says 127.0.0.53 and the real servers are
behind the stub. Say plainly not to install it just to run the check.

install.sh already guarded both calls, so this is documentation only.

branderson approved these changes 2026-08-06 01:38:08 -07:00

branderson merged commit b1f4c0cf35 into main

2026-08-06 01:38:12 -07:00

branderson referenced this issue from a commit

2026-08-06 01:38:13 -07:00

Merge pull request 'Stop pointing at resolvectl on hosts that do not have it' (#7) from resolver-docs into main

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dejima/dejima-ci-hardener#7