I think I get where you are going with the idea of different plays, but they way I understand it, I would need a different play for every user that had different host/group requirements. So, with 100+ users, 70 might need the same access for a given set of hosts (1 play), but there could be 30 that have unique requirements. So, that means 31 plays, and probably logging into some of the servers in question 31 times. Ugh! I am not a huge fan of my creation (it's not clean and elegant, though the line-breaks make it better), other than the fact it is very flexible, and reasonably efficient. I would love to be able to convert it to something more consistent with what the community recommends, but I don't see how to do it without possibly creating a different play for every user.
With my solution, every host is only accessed once, and each user can have a different host regex for each group, and the full definition of what permissions a user has is all in once place. On Thursday, August 14, 2014 7:40:18 AM UTC-4, Michael DeHaan wrote: > > Here's an easier way that avoids the messy Jinja2 in the playbook, which > we as a community like to discourage (it's the reason Ansible templates > don't evaluate into YAML, but are YAML... Jinja2 is intended to be just a > quick way to get variables, unless you are in a template) > > In ansible, a host specification that is a regex starts with "~" > > # hosts endsing in devdomain or qadomain: > > hosts: "~(devdomain.net|qadomain.net)$" > > Thus you can have multiple plays in the playbook > > - hosts: all > roles: > - foo > > - hosts: "~(devdomain.net|qadomain.net)$" > roles: > - setup_my_users > > - hosts: all > tasks: > - # more steps here > > Etc > > > > > > On Wed, Aug 13, 2014 at 10:51 AM, Alex Wheeler <[email protected] > <javascript:>> wrote: > >> Here's how I solved this problem for myself: >> https://gist.github.com/awheeler/a3e4c500f1bb70bd31dd >> You can define groups that users should be members of with a host >> specification that is a regex, so: >> >> users: devdomain.net$ >> >> would say that the user should be in the users group on all hosts with >> ansible_fqdn that end with devdomain.net. >> You can get just as complex as you want: >> >> wheel: ((host1|differenthost2|cluster_nodes[0123])-[0-9]+.proddomain.com| >> devdomain.net|another.devhost.dev)$ >> >> The thing that makes this possible is the fact that you can embed complex >> jinja2 in the middle of an Ansible task, a fact which is not immediately >> apparent. >> >> On Tuesday, August 12, 2014 5:25:06 AM UTC-4, P wrote: >>> >>> I would like to use ansible for our user management (I know there are >>> software for it like LDAP but not for now ...). >>> This is typical definition of users and their groups: >>> >>> Groups and users: >>> >>> - group1 >>> >>> >>> - user1 >>> - user2 >>> >>> >>> - group2 >>> >>> >>> - user1 >>> - user2 >>> - user3 >>> >>> >>> - group3 >>> >>> >>> - user1 >>> - user2 >>> - user3 >>> - user4 >>> >>> The problem I have is that every server is going to have subset of all >>> groups, i.e: >>> >>> >>> - server1 >>> - group1 >>> - group3 >>> - server2 >>> - group3 >>> - server3 >>> - group1 >>> >>> Then there is a request from business/developers/managers/whatever that >>> particular group of users should have access to particular servers so we >>> need to modify ansible config and add e.g. group3 to server3. >>> >>> Is it possible to create a role with a sort of "map" file where I could >>> specify which server will have particular user groups >>> so we could modify this one (!) file, run site.yml and done (the role >>> and its file knows where to create each group). >>> >>> I would like to avoid redundancy in terms of user definitions (error >>> prone) and have just one file with all users defined in it. >>> >>> That way I could include this role in every playbook and it would >>> automatically create (or not) particular group of users >>> on every host. >>> Is it possible to do that ? >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/46c0f594-3f1f-4265-9de7-83c99ce10377%40googlegroups.com >> >> <https://groups.google.com/d/msgid/ansible-project/46c0f594-3f1f-4265-9de7-83c99ce10377%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/149b2181-e876-4cc7-9cc1-68e01927972d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
