docs: add guidance about resolv.conf - #2450
Conversation
| - Another network manager or resolver owns the file under a | ||
| distribution-specific policy. | ||
|
|
||
| NetworkManager and `systemd-resolved` are not alternatives with the same role. |
There was a problem hiding this comment.
I think this is fine as is but if it got much more complex we should probably redirect to more in-depth guidance for a particular OS and/or upstream documentation (esp for NetworkManager)
| - `/etc/resolv.conf` is a symlink to a resolver file generated below | ||
| `/run/systemd/resolve`, normally | ||
| `../run/systemd/resolve/stub-resolv.conf`. | ||
| - The symlink can be created on boot if it was not materialized during the |
There was a problem hiding this comment.
I think this is what we expect to happen.
What we should be calling out here is that because of the /etc/resolv.conf being injected by container runtimes problem bootc actually always masks it (though just with the ostree backend today) see #1167
| A base image may instead have NetworkManager or another service write a | ||
| regular `/etc/resolv.conf`. In that case it should ensure that: |
There was a problem hiding this comment.
Write at runtime not build time, probably worth calling out
| Base image authors should select and document a resolver policy appropriate | ||
| for their distribution. Workloads that depend on particular behavior such as | ||
| `ndots`, timeouts, attempts, caching, or split DNS should be tested against | ||
| that resolver. `bootc` does not translate options between resolver |
There was a problem hiding this comment.
bootc has nothing to do with /etc/resolv.conf other than the special case that we remove it if present in the container image.
I would just include links to the other relevant docs, we don't need to explain resolved vs resolv.conf semantics here.
| A static `/etc/resolv.conf` can be appropriate for a deliberately static | ||
| system, but it is not the default recommendation. It prevents normal dynamic |
There was a problem hiding this comment.
NetworkManager definitely supports configuring the DNS through it statically e.g. for a static IP address, and I think should be the preferred mechanism for systems using NM.
| 1. Explicitly configure the network stack not to own `/etc/resolv.conf`. | ||
| 2. Remove any inherited resolver symlink in a build step using | ||
| `RUN --network=none`. | ||
| 3. Add the intended regular file from build context; do not copy the build |
There was a problem hiding this comment.
I don't think this will work because of the above.
If someone wants to ship a static /etc/resolv.conf in their image, at the current time we probably need to recommend a systemd tmpfiles.d unit that symlinks it, to /usr/lib/resolv.conf or something else.
But again I think this is overall a bad idea, and it's better to configure DNS through the networking system (NM or resolved).
| 4. Treat its contents as machine-local configuration when deciding whether it | ||
| belongs in the reusable image or in provisioning. | ||
|
|
||
| Remember that `/etc` is persistent and uses a three-way merge across bootc |
There was a problem hiding this comment.
Right this is why I think it's better to have it be a link to a file in /run (as systemd-resolved encourages) or a symlink to a file in /usr if it's truly static.
2 participants
No description provided.