Hi,
One of my tasks disables root over ssh.
Another creates an ‘app’ user that has sudo powers.
That means that the way to connect to the host changes after the first run.
Is there a smarter way to easily adjust to this new state than manually adding --become and --user command-line options to ansible-playbook on subsequent runs?
several ways:
You could have the first task attempt to ‘connect as root and set the other user’, ignore their failure and continue with rest of play with correct credentials
You could skip the ‘as root’ tasks depending on a passed var
Variation on the above, have the play update host_vars for that host with needs_root=False and have needs_root=True in group_vars/all.yml after updating the machine to not need root.
Another variation, add the host to ‘doesnt_need_root’ group in play
etc.
Thanks for the thoughts Brian.
> You could have the first task attempt to 'connect as root and set
> the other user', ignore their failure and continue with rest of
> play with correct credentials
This is a new idea to me. Obviously some smell around ignoring failures.
> You could skip the 'as root' tasks depending on a passed var
Requires operator knowledge of state.
> Variation on the above, have the play update host_vars for that host
> with needs_root=False and have needs_root=True in group_vars/all.yml
> after updating the machine to not need root.
This is interesting. In effect, I'm keeping knowledge of state on the local machine. Downsides might be - others operators don't have my machine's state knowledge, I've built a non-obvious state mechanism, and some machines in a group may fail, thus the state of the group is not necessarily accurate.
> Another variation, add the host to 'doesnt_need_root' group in play
Interesting idea. Then the inventory sort of becomes a text-based
database, manipulated by plays. Yuck.
Which of these seems cleanest to you? The automatic ones all feel
like complicated mechanisms built on top of Ansible that sort of go against the ideology of Ansible.
~gb
Ansible itself avoids dealing with state, but it can easily use saved state as an input or output current state in a way you can save. You need to either modify the play to deal with finding out the state dynamically or you save state and pass it in.
As to which one is ‘cleanest’ … that is very subjective.