I currently do the following
do NOT use sudo: yes in the playbook
for each task that needs sudo, I add sudo: yes, sometimes with sudo_user
however, I see that 50% of my tasks require sudo and it seems a bit repetitive,
is there anyway to do, " with the following tasks, apply sudo: yes"
Mike
Yes, set it on the playbook at the same level as “hosts”.
Sorry, I meant “play”.
This is basically what plays are for. Applying tasks/roles to sets of hosts with common parameters.
A playbook can contain more than one play.
I’m a bit confused on the difference between a play and a playbook
Is a playbook with many plays just
1.) a play that includes other plays as a task
or
2.) a play that adds other plays as a role
?
I have looked in the documentation and while it mentions a playbook consists of plays, it doesn’t show any examples.
Mike
playbook is a list of plays, plays cannot include plays, only tasks or roles
basically,
play is =
playbook =
got it, thanks
I have a play, that also is my top level playbook. It has series of roles, that I need to be executed in a certain order.
One of them I want to be able to turn off sudo, I like roles because it feels similar to OO mixins.
If I do as suggested above to use a play instead of a role.
How can I maintain the order?
Would I have to do something such as the following, in order to have the following order? foo > bar > hello
roles
include bar.yml
roles
I feel plays and roles are really similar. I wonder if plays can act as roles if using the “main” convention.
Or vice versa, where roles can apply sudo and sudo user.
Two seperate plays, one engages sudo, one does not.
The goal of plays is to map groups of hosts and common parameters to the set of roles/tasks they perform or fulfill.
So no, they are not quite the same as roles.
This is one of the challenges I’ve run into with roles. I have a role that I used for deploying a Django app. Some tasks require sudo to root and some require logging in as a regular account (the account that will run the Django app). Specifically it looks like:
I haven’t found an elegant way to express this as a single role. Why I do right now is add “sudo_user” to all of the tasks in the middle, which kinda works (modulo the lack of agent forwarding when sudo’ing to non-root user), but I find this inelegant. But the alternative would be to break it up into three roles, the first and last that run as root, and the middle that runs as the regular user. But that seems even less elegant.
Lorin
On most sudo installs, you can configure sudo to preserve
$SSH_AUTH_SOCK when becoming a non-root user.
This is much simpler when you manage sudoers with ansible, btw.
This doesn’t work when sudo-ing to a non-root user because the user you sudo to doesn’t have read/write access to the socket file pointed to by SSH_AUTH_SOCK. You need to set the access mode on the file correctly for this to work. It’s on my todo list to have ansible do this automatically (https://github.com/lorin/ansible/commit/7aa352d9cac33809273).
Lorin