You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there are a lot of cases where you need to set some combination of ansible_user, galaxy_user, galaxy_privsep_user, galaxy_remote_users, galaxy_become_users, etc. even when you are not using privsep mode.
The goal of all this user manipulation inside the role is to be able to run all the individual features of this role as different users without requiring the use of root, and to support different privilege escalation scenarios such sites where sudo is not possible and root privileges are obtained with ssh -l root instead, deploying on to root squashed NFS, etc., and the fact that we need different privileges for different features in the role. Ansible itself doesn't provide any framework for this, so we've built it into the role.
Ansible has of course rapidly developed in the interim and there may be some new features that would allow us to do this in a better way. We could also consider breaking each bit of functionality into separate roles that are then combined into a collection. Other ideas very much welcome.
The alternative is the way the role used to work: If you want privilege separation or want it to create users for you (requiring root privileges) etc., you call it multiple times with the right combination of become, become_user, remote_user, and the control variables flipped on or off depending on what task(s) you are performing. This is much uglier in my opinion.
Hi @xmaksimus you've asked this question in three places. Please do not cross-post, and please wait longer for a response first. We're all volunteers and this week is a very big event that's causing some delays.
Currently there are a lot of cases where you need to set some combination of
ansible_user
,galaxy_user
,galaxy_privsep_user
,galaxy_remote_users
,galaxy_become_users
, etc. even when you are not using privsep mode.The goal of all this user manipulation inside the role is to be able to run all the individual features of this role as different users without requiring the use of root, and to support different privilege escalation scenarios such sites where
sudo
is not possible and root privileges are obtained withssh -l root
instead, deploying on to root squashed NFS, etc., and the fact that we need different privileges for different features in the role. Ansible itself doesn't provide any framework for this, so we've built it into the role.Ansible has of course rapidly developed in the interim and there may be some new features that would allow us to do this in a better way. We could also consider breaking each bit of functionality into separate roles that are then combined into a collection. Other ideas very much welcome.
The alternative is the way the role used to work: If you want privilege separation or want it to create users for you (requiring root privileges) etc., you call it multiple times with the right combination of
become
,become_user
,remote_user
, and the control variables flipped on or off depending on what task(s) you are performing. This is much uglier in my opinion.#116 and #118 are both related.
The text was updated successfully, but these errors were encountered: