Assign group membership in a module or conditionally?

[Martin Langhoff]

Scenario - we have modules:
 - our_users: defines all the (virtual) users (sysadmins, support, developers) as members of wheel
 - our_base: gets applied to all nodes
 - our_webserver: defines the apache group

What I want to achieve is: on nodes that use our_webserver (where the apache group exists), any member of wheel should also be in apache.

We tried

   User <| groups == 'wheel' |> {
      groups = ['wheel', 'apache']
   }

but this realizes all virtual users (which breaks other stuff we do), and would not very well if another module was to do this too.

Is there a good way to do this? Either in "our_webserver" -- which I would prefer -- or in our_users (if apache group exists, be a member).

 

m

--
 martin....@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff

[José Luis Ledesma]

I would really like to know what other people may suggest, the only thing that comes to my mind is to make use of tags for your users.

Regards

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACPiFCLtFeMR0RpZ6Aha%3DnZe9Fuu_stAzigOhsvnGHVDewz-xg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Langhoff]

On Friday, March 28, 2014 2:30:31 PM UTC-4, Jose Luis Ledesma wrote:

I would really like to know what other people may suggest, the only thing that comes to my mind is to make use of tags for your users.

How would you do this with tags _without_ realizing virtual users?

m

[José Luis Ledesma]

Realize some of them

User <| groups == 'wheel' and tag== 'web'|> {

      groups = ['wheel', 'apache']
   }

As said i don't really like this option.

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e5d904f8-ce23-4ec3-8488-017e9c6c2317%40googlegroups.com.

[José Luis Ledesma]

Mmmm another option could be set a custom fact that returns all the groups that exista and a user may have, and make use of it defining the virtual resource.

[Martin Langhoff]

On Friday, March 28, 2014 3:08:00 PM UTC-4, Jose Luis Ledesma wrote:

Realize some of them

Right. That does not address my concern, which is the implicit realize.

The rule for which users we realize on our infra are orthogonal to the modules that define functionality; and need to remain so...

m

[jcbollinger]

You can still use tagging to support what you want, provided that you are willing to assign tags everywhere that you realize users.  For example:

# Some random place:
User<| title='alice' |> {
  tag +> 'present'
}
# and similar everywhere else that you realize a User

# Elsewhere:
User <| groups == 'wheel' and tag == 'present' |> {
  groups +> [ 'apache' ]
}


You can also override the parameters of specific users via a collector if you intend them to be present anyway

User <| title == 'adam_the_administrator' |> {
  groups +> [ 'apache' ]
}

.  Or you can override parameters of specific users without realizing them if you to so in a subclass:

class our_web_users inherits our_users {
  # Declared in class 'our_users':
  User['david_the_developer'] {
    groups +> [ 'apache' ]
  }
}

Puppet DSL provides no mechanism, however, for selecting resources via a search expression without realizing all virtual resources among those selected.

Perhaps, however, you could do something clever at the point where you declare the users in the first place.  If class our_users has some kind of visibility of whether the target node is (supposed to be) a web server, then it could initially declare users with the correct groups, so that you don't have to perform any fixup later.  "Some kind of visibility" could be achieved via hiera or with the help of the roles & profiles pattern; there are probably other alternatives as well.


John

[Martin Langhoff]

On Friday, March 28, 2014 3:48:47 PM UTC-4, jcbollinger wrote:

Puppet DSL provides no mechanism, however, for selecting resources via a search expression without realizing all virtual resources among those selected.

This is really awkward for what I see as a "natural" operation. Am I doing something wrong in my setup?

And also... this is funny, but I discovered a change including this syntax had already been rolled out into production, so I thought I would find all the virtual user accounts created. In fact I did not.

Could it be that there are additional conditions that control whether the accounts are realized 

 

Perhaps, however, you could do something clever at the point where you declare the users in the first place.  If class our_users has some kind of visibility of whether the target node is (supposed to be) a web server, then it could initially declare users with the correct groups, so that you don't have to perform any fixup later.  "Some kind of visibility" could be achieved via hiera or with the help of the roles & profiles pattern; there are probably other alternatives as well.

We already use roles/profiles pattern, but without Hiera. So we have our_users module which only declares virtual users, then our_users::some_group subclasses that realize them.

We use site.pp (split per data center) to define what classes apply to a given node. Most of our nodes are identical, so we have "wildcard" regex node definitions. Nodes with specialized roles have a dedicated node stanza.

Not all user accts are everywhere: some have special security req's and can only allow a very restricted set of sysadmins.

It is in this kind of pattern that I'd like to say, in a "profile" module (our_webservers) that all users in wheel also have to be in 'apache'.

cheers,

m

[Martin Langhoff]

On Mon, Mar 31, 2014 at 10:09 AM, Martin Langhoff
<martin....@gmail.com> wrote:
> This is really awkward for what I see as a "natural" operation. Am I doing
> something wrong in my setup?
>
> And also... this is funny, but I discovered a change including this syntax
> had already been rolled out into production, so I thought I would find all
> the virtual user accounts created. In fact I did not.

Ok, I found both the explanation of why this is not creating users in
our env, and I guess a good workaround to this situation.

In our env, virtual users are not realized directly, they are realized
through a "define ssh_user" that manages authorized_keys and assigns
them to wheel.

That layer of indirection _is_ in Puppet's state, but it means that
the virtual user does not have the membership set in the "virtual"
definition.

At some point of the discussion I also lost sight of the
conditionality of the materialization (will only materialize
/matching/ resources) and I was temporarily a bit more anxious than I
should have been.

This is a relief. I still consider resource collectors dangerous, but
usable in clearly defined situations.