Skip to content

k3s-registry: match the deployed file mode, fix the Docker play - #379

Merged
swares merged 1 commit into
mainfrom
fix/k3s-registry-mode-and-docker
Aug 9, 2026
Merged

k3s-registry: match the deployed file mode, fix the Docker play#379
swares merged 1 commit into
mainfrom
fix/k3s-registry-mode-and-docker

Conversation

@swares

@swares swares commented Aug 9, 2026

Copy link
Copy Markdown
Owner

Follow-up to #378, from running --check against the full fleet.

mode 0600 -> 0644. Content matched on all four configured nodes; the only diff
was the mode. Since the copy notifies "restart k3s", applying it would have
rolled every node in the cluster to tighten permissions on a file that holds no
credentials. If an auth block is ever added here, tighten it in that same commit
and accept the restart then -- permissions are worth a restart when there is a
secret to protect, and not before.

The Docker play could not succeed and would have been harmful if it had. h4-core
runs docker-ce 29.7.1, which depends on containerd.io; the task installed
Ubuntu's docker.io, which depends on containerd, and the two conflict:

containerd.io : Conflicts: containerd

So the task failed every run, and had it succeeded it would have torn out a
working Docker install. Now guarded by a docker --version probe.

xu3-1 dropped from that play. It runs Ubuntu 16.04, whose Python is too old for
ansible-core: every module dies with a SyntaxError on an f-string inside
module_utils/basic.py, before any task logic runs. ignore_unreachable does not
help because the host is reachable -- the module is what breaks. It is already
excluded from Ansible auto-updates; configure it by hand or retire it rather than
having every run report a failure.

opi5pro-1 has been brought into line separately: file created, k3s-agent
restarted, nothing else touched.

Follow-up to #378, from running --check against the full fleet.

mode 0600 -> 0644. Content matched on all four configured nodes; the only diff
was the mode. Since the copy notifies "restart k3s", applying it would have
rolled every node in the cluster to tighten permissions on a file that holds no
credentials. If an auth block is ever added here, tighten it in that same commit
and accept the restart then -- permissions are worth a restart when there is a
secret to protect, and not before.

The Docker play could not succeed and would have been harmful if it had. h4-core
runs docker-ce 29.7.1, which depends on containerd.io; the task installed
Ubuntu's docker.io, which depends on containerd, and the two conflict:

  containerd.io : Conflicts: containerd

So the task failed every run, and had it succeeded it would have torn out a
working Docker install. Now guarded by a docker --version probe.

xu3-1 dropped from that play. It runs Ubuntu 16.04, whose Python is too old for
ansible-core: every module dies with a SyntaxError on an f-string inside
module_utils/basic.py, before any task logic runs. ignore_unreachable does not
help because the host is reachable -- the module is what breaks. It is already
excluded from Ansible auto-updates; configure it by hand or retire it rather than
having every run report a failure.

opi5pro-1 has been brought into line separately: file created, k3s-agent
restarted, nothing else touched.
@swares
swares merged commit e2ec8be into main Aug 9, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant