# sudo\_user for roles **URL:** \ **Category:** Ansible Project\ **Created:** [June 6, 2013, 6:41pm UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918 "2013-06-06T18:41:00Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![Bryan\_Larsen](https://avatars.discourse-cdn.com/v4/letter/b/9de053/32.png) [@Bryan\_Larsen](https://forum.ansible.com/u/Bryan_Larsen)\ **Post date:** [June 6, 2013, 6:41pm UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/1 "2013-06-06T18:41:00Z")
just on a whim, I thought I’d try this: - hosts: 127.0.0.1 sudo: yes connection: local vars: (snipped) roles: - setup - { role: worker, sudo\_user: vagrant } - service It didn’t work. No big deal, I can have three copies of the block. Switching from vars to vars\_file will mean fewer repeated lines too. But if you feel like implementing it, a few of us would probably find it convenient. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [June 6, 2013, 9:24pm UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/2 "2013-06-06T21:24:58Z")
Yep, sudo\_user is to be set on the play, not the role. I’m open to patches, but if done, it must also support “sudo: True/False” as well. ---
**Author:** ![Gilles\_Cornu](https://avatars.discourse-cdn.com/v4/letter/g/ecccb3/32.png) [@Gilles\_Cornu](https://forum.ansible.com/u/Gilles_Cornu)\ **Post date:** [June 9, 2013, 9:49am UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/3 "2013-06-09T09:49:17Z")
Sure, I’m interested too! At the moment `sudo_user` is not fully detailed in Ansible Docs, and therefore I put here my experience feedbacks (aiming to maybe propose some “relevant” documentation addition?). About my context: I always connect with a non-root user, and switch between several accounts (root, service accounts, etc). I thus look for good `sudo_user` patterns. So far, I experimented these two possible approaches (and did not find other ones): - split in different plays to switch default user - Advantages: Less repetition; play default `sudo_user` does not overwrite potential `sudo_user` at task level - Drawback: play segmentation may not correspond to logical orchestration of roles; Unlike role `handlers`, role `vars` files imported in previous plays are not implicitly available for subsequent plays.- explicit sudo\_user for each task not executed by “single” default user - Advantages: More control against accidental execution with a “wrong” user; sudo\_user interleaving has no impact on role organisation (e.g. ability to pack everything into a single play definition) - Drawback: Lots of (noisy) `sudo_user` repetition for sequence of tasks executed by the same user After sticking to “play sudo\_user” strategy for a while, I am even more tempted to change to “task sudo\_user” strategy, which is more verbose but less tricky. What are your lessons learnt on this topic? Any recommendation? To summarize: - `sudo_user` at role level sounds like “the” good solution to disadvantages of both variants above. Should `include` also support it? - Bryan are you already working on a patch? Gilles ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [June 9, 2013, 1:26pm UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/4 "2013-06-09T13:26:48Z")
As for play vs task, I think it’s fine if people do either. I’m curious why you think it’s not fully mentioned in the docs, can you give a link to where you think it needs to be talked about more? Or are you saying it’s not shown that you can set it on a task? ---
**Author:** ![Gilles\_Cornu](https://avatars.discourse-cdn.com/v4/letter/g/ecccb3/32.png) [@Gilles\_Cornu](https://forum.ansible.com/u/Gilles_Cornu)\ **Post date:** [June 9, 2013, 10:58pm UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/5 "2013-06-09T22:58:25Z")
Sorry Michael for giving too few details about my documentation critics and wishes. With “not fully detailed”, I had following in mind: - Play sudo\_user is very well explained in [http://ansible.cc/docs/playbooks.html#basics](http://ansible.cc/docs/playbooks.html#basics) - But (as you guessed), I don’t find any place where Task sudo\_user is presented. - It is also not obvious why `sudo_user` (at the moment) only supports variables defined at playbook level (as reported in [GH 1665](https://github.com/ansible/ansible/issues/1665) and other related issues). Ansible documentation is very well written: compact and comprehensive. I think it is also part of “dead simple” style of Ansible, and I like it very much! Even if examples found with help of google or github brought me very fast to the available features, I would like to use my learning path to maybe improve the documentation in meaningful way. For instance, I wonder if we could consider extending things like: - In [Ansible Docs: Glossary](http://ansible.cc/docs/glossary.html): From concept, refer to related YAML elements - I also like the [Cheat Sheet proposal](https://groups.google.com/d/topic/ansible-project/IVUwp9195Ek/discussion): It would also be nice for reverse lookup (e.g. `sudo_user` can be applied to `play` and `task`) Thanks for all your awesome work Michael, and good luck for releasing 1.2 so soon!!! I’ll try my best to contribute to this great project (unfortunately with few time, and few skills). Gilles ---
**Author:** ![Bryan\_Larsen](https://avatars.discourse-cdn.com/v4/letter/b/9de053/32.png) [@Bryan\_Larsen](https://forum.ansible.com/u/Bryan_Larsen)\ **Post date:** [June 10, 2013, 2:30am UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/6 "2013-06-10T02:30:01Z")
>    - Bryan are you already working on a patch? No, I'm not. The workaround of putting several plays in a single playbook works well enough for me. It's awkward, but not awkward enough that I've started working on a patch. Bryan ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [June 10, 2013, 12:20pm UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/7 "2013-06-10T12:20:46Z")
You could just set “sudo\_user” on each task that needed a sudo user too. ---
**Author:** ![David\_Golden](https://avatars.discourse-cdn.com/v4/letter/d/d2c977/32.png) [@David\_Golden](https://forum.ansible.com/u/David_Golden)\ **Post date:** [June 10, 2013, 5:17pm UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/8 "2013-06-10T17:17:05Z")
I've been passing in a role parameter with the user, and then putting sudo\_user on each task. It's clunky but works. I'd be in favor of this change. Overall, I don't think roles are very well defined. It seems like they are intended to be more re-usable than playbooks (and host-agnostic), but they aren't easy to parameterize. Compared to implementing roles as just another task( "action: role name=whatever" ), roles allow more flexible variable definition, but not the other task modifiers like sudo/sudo\_user. If role invocation were more like tasks, the before/after stuff wouldn't be needed, either. (Moving from a linear order to linear within before/during/after phases is a code smell to me.) Happy to chat more about it on Thursday. 🙂 David ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [June 10, 2013, 5:48pm UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/9 "2013-06-10T17:48:57Z")
“Overall, I don’t think roles are very well defined. It seems like they are intended to be more re-usable than playbooks (and host-agnostic), but they aren’t easy to parameterize.” I strongly disagree. Roles _are_ tasks. ---
**Author:** ![Seth\_Vidal](https://avatars.discourse-cdn.com/v4/letter/s/7ba0ec/32.png) [@Seth\_Vidal](https://forum.ansible.com/u/Seth_Vidal)\ **Post date:** [June 10, 2013, 5:53pm UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/10 "2013-06-10T17:53:52Z")
but tasks with local handlers, local files, correct? -sv ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [June 10, 2013, 6:11pm UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/11 "2013-06-10T18:11:35Z")
Yes, they’ve got a lot more on top, what I mean here is they can be parameterized exactly like tasks, in that you can send variables to them. See: [http://www.ansibleworks.com/docs/playbooks.html#roles](http://www.ansibleworks.com/docs/playbooks.html#roles) They clearly have a lot of resemblance to Puppet modules – they were very clearly inspired by that idea, but making them (IMHO) simpler and easier to use. Reusability, encapsulation, simpler pathing, are all benefits. And the example above shows they can be parameterized just like task includes. ---
**Author:** ![David\_Golden](https://avatars.discourse-cdn.com/v4/letter/d/d2c977/32.png) [@David\_Golden](https://forum.ansible.com/u/David_Golden)\ **Post date:** [June 11, 2013, 1:37am UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/12 "2013-06-11T01:37:18Z")
Do they accept all the same parameters and modifiers as tasks? E.g. when, ignore\_errors, with\_items, etc.? My understanding is "no" -- which was the OP about "sudo\_user" not working on a role. This is what I mean when I say "not very well defined". The are \*similar\* to tasks, but they are \*not\* tasks. They have different modifiers and can't be interspersed with other tasks. (E.g. "task", "role", "task", "role") As I said, I think this is a code smell -- because it would make much more sense if one could reason about them and use them identically to tasks, just with a little bit of extra indirection (expanding into a large set of parameterized tasks with local files, templates, handlers, etc.). If 1.3 could find a way to let roles be used within a task list with all the same features, I think that would be a great step towards a more consistent design. David ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [June 11, 2013, 2:32am UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/13 "2013-06-11T02:32:28Z")
with\_items and an include isn’t supported anywhere, we’ve undocumented it for good reason. They are completely tasks. What you are talking about is whether they take some include parameters that the task include line can take, which I’m all in favor of making it take sudo\_user, and someone should send me a patch for it. Lists and roles will never be supported, just as with task includes, you should loop _inside_ the task. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [June 11, 2013, 2:54am UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/14 "2013-06-11T02:54:21Z")
Replying to the rest of this. Rather than mixing roles and tasks, in your case, what you should do is use roles and convert your existing tasks into roles. Roles can contain tasks of course, and also vars\_files and handlers. Then you can place them in any order you like for the task portions. This keeps everything much simpler and self contained, without introducing more syntax. ---
**Author:** ![Gilles\_Cornu](https://avatars.discourse-cdn.com/v4/letter/g/ecccb3/32.png) [@Gilles\_Cornu](https://forum.ansible.com/u/Gilles_Cornu)\ **Post date:** [August 6, 2013, 2:59pm UTC](https://forum.ansible.com/t/sudo-user-for-roles/12918/15 "2013-08-06T14:59:52Z")
Happy to just drop a note to “close” this outdated thread since sudo/sudo\_user will be part of Ansible 1.3. Cool!!! See - [https://groups.google.com/d/topic/ansible-project/Ldp3Kue1m8g/discussion](https://groups.google.com/d/topic/ansible-project/Ldp3Kue1m8g/discussion) - [https://github.com/ansible/ansible/pull/3579](https://github.com/ansible/ansible/pull/3579) - [https://github.com/ansible/ansible/blob/devel/CHANGELOG.md](https://github.com/ansible/ansible/blob/devel/CHANGELOG.md)