* feat: make the server config file mode configurable
/etc/rancher/k3s/config.yaml holds the cluster token. The server and
upgrade roles write it at 0644, so every local account on a server node
can read the credential that joins a node to the cluster.
k3s_server_config_mode sets the mode of that file in both roles. It
defaults to 0644, so behaviour is unchanged unless it is set.
Signed-off-by: Kristofer <kristofer@atlascloud.is>
* docs: describe the server config file contents accurately
/etc/rancher/k3s/config.yaml does not always carry the cluster token. A
first server that lets K3s generate one writes the file without it, so the
file can contain the token rather than always holding it. Correct that
claim in the README, the inventory sample and the role default, and use
the US spelling of "honors".
Signed-off-by: Kristofer <kristofer@atlascloud.is>
* Name the floor the config file mode can be narrowed to
Saying any mode root can read works leaves the reader to work out what
that means in practice. The file is read only by k3s, running as root, so
0600 is the tightest mode that still works.
Signed-off-by: Kristofer <kristofer@atlascloud.is>
* Run the basic integration job with a non-default config file mode
The templated mode was only ever rendered with its default in CI, which
is the one value that cannot tell a working template from a broken one.
The basic inventory sets 0640 and the job reads the mode back off the
installed file.
Signed-off-by: Kristofer <kristofer@atlascloud.is>
---------
Signed-off-by: Kristofer <kristofer@atlascloud.is>
Re-running site.yml with a raised k3s_version replaced the on-disk
binary but left agents and joined servers running the old runtime,
because the install script skips the service start and the roles only
restarted the service on a config change. A version-only bump was
therefore not applied until the services were restarted by hand.
Always restart the k3s service in the server and agent roles on a
site.yml run, so the cluster reliably picks up a new config or runtime
without any logic to detect whether the binary changed. On a
multi-server cluster, run the playbook with --forks=1 so the servers
restart one at a time and the etcd quorum is preserved; document this
in the README.
Keep the dedicated upgrade.yml integration test and add a second
upgrade through site.yml, asserting the running version the kubelet
reports rather than the on-disk binary, so the tests fail if the
restart regresses.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
- Use rancher/systemd-node which doesn't cause k3s to crash
- Expand requirements for testing, ensure deployments become ready at each playbook
- Add logging on failure for debugging
Signed-off-by: Derek Nola <derek.nola@suse.com>
Kris
dependabot[bot]
Derek Nola
Stéphane Este-Gracias
Aleksei Sviridkin
Chris Wayne
Brian Lu
Julien DOCHE
Jeff Geerling