"Module remote_tmp /etc/step-ca/.ansible/tmp did not exist [...]"
strarsis opened this issue · 5 comments
When applying the step_ca role of this collection for the first time:
TASK [maxhoesel.smallstep.step_ca : Initialize CA] *****************************
[WARNING]: Module remote_tmp /etc/step-ca/.ansible/tmp did not exist and was
created with a mode of 0700, this may cause issues when running as another
user. To avoid this, create the remote_tmp dir with the correct permissions
manually
I saw this warning also for other ansible playbooks and roles. Is this something that has to be ensured globally, or should/can this step_ca role/this collection itself ensure that the directory is first created with proper permissions?
Hm, how are you connecting to your CA server? I don't get that message in my CI runs, so I'm not sure where the message is coming from.
If you are connecting to your CA host as an unprivileged user and then use become to run this playbook, the warning might be related to [that(https://docs.ansible.com/ansible/latest/user_guide/become.html#risks-of-becoming-an-unprivileged-user), but I'm honestly not sure.
@maxhoesel: I install it on a Vagrant box (CentOS 7.x) with default vagrant user and become: true.
As become is used and that vagrant user is used to become root, this seems to be indeed related to the warning in the docs.
Yea, it's probably related to that then. By the way, CentOS 7 is not officially supported by this collection, so you might run into more issues down the road. You can check the supported Distributions in the role READMEs
@maxhoesel: CentOS support would be great! Because especially CentOS needs manual steps in contrast to other distributions where packages are available.
I agree that CentOS7 support would be nice to have, but it would be a lot of hassle for a single distribution. Among other things, it still uses Python 2.7, while the modules in this role are written for Python 3.6 (the version available on Ubuntu 16.04, Debian 10, CentOS8, etc.) and has some other oddities that would need special handling.
I only use Debian-based distros personally, so I can't justify the extra effort in supporting a single old distribution that'll be EOL in 2-3 years, when CentOS8 is already supported (and future distros like Rocky/Alma Linux should work fine too).
That said, If someone else wants to put in the work to add support themselves, feel free to let me know!