🐛 bug fix: correct path for .hushlogin of non-root user

[osnabrugge]

This PR is a minor bug fix for the path directory when creating .hushlogin file in the cluster-prepare.yaml playbook.

I would have included another change for the cluster-installation.yaml playbook as ansible currently throws the following error: ERROR! Using 'ansible.builtin.include_role' as a handler is not supported. Sadly, I cannot find a solution as I have tried alternate modules, but it seems that a handler can't be used for some reason. Perhaps it's a quick fix for you as I have just opted to put a reboot task for now?

Main changes:

• ansible/main/playbooks/cluster-prepare.yaml: Modified the cluster-prepare.yaml playbook. (ansible/main/playbooks/cluster-prepare.yaml)

[onedr0p]

Looks like I might have deleted that by mistake, thanks for the fix!

[onedr0p]

I would have included another change for the cluster-installation.yaml playbook as ansible currently throws the following error: ERROR! Using 'ansible.builtin.include_role' as a handler is not supported. Sadly, I cannot find a solution as I have tried alternate modules, but it seems that a handler can't be used for some reason. Perhaps it's a quick fix for you as I have just opted to put a reboot task for now?

I'm so bad, I rarely test the changes I make to Ansible and end up fixing them up the next time I reprovision my cluster :(

Sounds like I'll have something to fix up in the future 😅

[osnabrugge]

I guess you have me for QA for now considering how often I am nuking my cluster 🤣

[onedr0p]

I can probably move that handler to the helm operator task. The task isn't that important but I like being able to disable the k3s helm controller after I'm done with it.

[onedr0p]

Looks like the Ansible team won't budge on this ansible/ansible#20493 (comment)

I have made the proper changes here: a782d7b

[osnabrugge]

I can probably move that handler to the helm operator task. The task isn't that important but I like being able to disable the k3s helm controller after I'm done with it.

I noticed that it is critical that k3s restarts for the containerd tmpl to apply successfully. When I first discovered this handler issue, it was actually due to my own azwi.yaml task failing to run, thus ending the entire cluster-installation.yaml without a restart to k3s services (I dropped your handler and notifies). Spegel ends up having a hissy fit, the tmpl is gone and never applies its updates. Maybe it is worthwhile creating a task for Spegel so it can have its own handler?

Looks like the Ansible team won't budge on this ansible/ansible#20493 (comment)

You see the error message that was given? This is probably a bug 🤦‍♂️

[onedr0p]

Spegel ends up having a hissy fit, the tmpl is gone and never applies its updates. Maybe it is worthwhile creating a task for Spegel so it can have its own handler?

I am not too keen on maintaining this too much as k3s will have embedded support for spegel in the near future. But if it's longer than the "near future" I can circle back on it.

k3s-io/k3s#8977