User management by ansible - any ideas ?

[P]

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 ?

[Dick Davies]

You can parameterise roles, maybe that would help.
(http://docs.ansible.com/playbooks_roles.html )

Define all the group memberships in your accounts role
(accounts/defaults/main.yml)
and then in your inventory, load the accounts role into specific hosts
with a list
of the groups you want defined.

> --
> 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 ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/b90ff83b-0e8a-487f-bc00-9132d71bea92%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[P]

While reading this URL I came across the following example:

- hosts: webservers
  roles:
    - common
    - { role: foo_app_instance, dir: '/opt/a',  port: 5000 }
    - { role: foo_app_instance, dir: '/opt/b',  port: 5001 }

Can anyone show me how would the "foo_app_instance" role look like ?

[Rodney Quillo]

I'm using this user role, https://github.com/mivok/ansible-users

Maybe you can take a look at this too. 

[Michael DeHaan]

Basically it could be anything, it would just be able to use variables like {{ port }} in the playbooks or Jinja2 templates.

On Wed, Aug 13, 2014 at 4:37 AM, Rodney Quillo <imc...@gmail.com> wrote:

I'm using this user role, https://github.com/mivok/ansible-users

Maybe you can take a look at this too. 

--

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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/50663b64-9e00-446e-a45d-eddf71056afd%40googlegroups.com.

[Alex Wheeler]

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.

[Michael DeHaan]

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

--

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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/46c0f594-3f1f-4265-9de7-83c99ce10377%40googlegroups.com.

[Alex Wheeler]

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.

[Michael DeHaan]

"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."

Definitely not.

This is where useful things like "with_items" come in, and you can do 

"with_items: myusers".

Thus you can still keep one play that uses a variable to source the list of users, and that variable can come from things like group_vars.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/149b2181-e876-4cc7-9cc1-68e01927972d%40googlegroups.com.

[P]

The problem with this approach is that it requires the servers name to be similar (regex).
In our case the servers name could be totally different so it won't work (perhaps ...)

[Michael DeHaan]

"The problem with this approach is that it requires the servers name to be similar (regex)."

You should use groups.   We recommend this in nearly all cases, hardly anyone is using host patterns matched by regex.

If using cloud services, tags also automatically form groups, which is highly useful, as servers can self-declare what groups they are in.

On Wed, Aug 20, 2014 at 10:43 AM, P <p....@cmcmarkets.com> wrote:

The problem with this approach is that it requires the servers name to be similar (regex).
In our case the servers name could be totally different so it won't work (perhaps ...)

--

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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/6644592e-d1f2-4848-83d8-691a3aa0cecd%40googlegroups.com.