Puppet users - Jan 2011 - Virtual resources, account module help.

Hello,

I''m trying to rebuild my accounts module so that will completely
manage users via puppet.  In my env, as much as I would like to, I
cannot use nis or ldap for authentication, so I''m trying to do it the
puppet way, but I seem to be a little stuck.

I would like to maintain a list of users (currently in a csv file
accessed via an extlookup function), then just specify unix groups to
appear on the node.  All users of those groups would be realized and
appear on the target system.

If a user is in more than one group, then I run into a duplicate
resource definition issue, and I can''t quite figure out a better way
to get around it.

I''ve seen the various methods in the mail archive, but those all
appear to have static definitions for the users.  I''m trying to
dynamically create the users resources.

class accounts::users {

  define douser {
      $extlookup_datadir = "/etc/puppet/manifests/extdata"
      $extlookup_precedence = [ "people" ]
      $extuser = extlookup("$name")
      # At this point extuser look like [ "acrews", "1000",
"Adam
Crews", "/bin/bash", "enabled",
"devuser:qauser:group1:group2:group3"
]

      $groups = split($extuser[4], ''[:]'')

      @group {
            "$name":
                 $gid => $extuser[1],
                 $ensure => $extuser[4];
       }

      @user {
            "$name":
                ensure => $extuser[4],
                uid  => $extuser[1],
                groups => [ $groups ],
                 ... (and so on for the user values)
       }
  }

  define dogroup {
      $extlookup_datadir = "/etc/puppet/manifests/extdata"
      $extlookup_precedence = [ "groups" ]
      $extgroup = extlookup("$name")
      # at this point $extgroup is an array of users that are in the
group specified in $name

      douser { [ $extgroup ]: }

  }
}

node foo {
   include accounts::users
   accounts::users::dogroup {["devuser", "qauser"]}
}

So if "acrews" appears in both devuser and qauser, I get
"Duplicate
definition: Accounts::Users::Douser[acrews] is already defined....".
This is obvious to me since the dogroup define is invoked for each of
the groups.  I''m thinking that I need to tag the resources, then
collect and realize them all, but I so far I haven''t found the right
path to make that happen.

Can someone nudge me in the right direction to sort this out?

Thanks
-Adam

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi Adam,

Shame you can''t use LDAP or NIS ;) But anyway...

Let me give you one of my working examples of virtual resources and
hopefully it''ll give you an idea on how to solve your problem.
I''ve
got Yum repos as virtual resources. Now I don''t want every Yum repo on
every server, so I''ve got a ''yum_repo'' class that
declares every Yum
repo in my organisation as virtual resources. Then, any other module
that wants to install something from a EPEL for example can "include
yum_repo" and then "realize yumrepo_epel". Doesn''t
matter how many
classes realize the same Yum repo as it''s only declared virtual once.
However, all my yum repos are declared virtual on every node, even if
they are not used.

What you''re trying to do is declare virtual users more than once which
is why you''re getting an error. You need to have all your users
declared virtual first then allow your modules and classes to ''turn
on'' different groups of people. By the looks of your extlookup your
data source is static enough to do this (I think...). So I''d suggest
something like:

class accounts::users {
  #Get everyone in your organisation
  $everyone = extlookup("everyone")

  #Virtualise everyone!
  virtualise_user { $everyone: }
}

define virtualise_user($username) {
  $extlookup_precedence = [ "people" ]
  $person = $extuser = extlookup($name)
  @user { $username:
    ...
  }
}

define add_groups_of_users($group) {
  $extlookup_precedence = [ "groups" ]
  $extgroup = extlookup($group)
  #"turn on" everyone in this given group.
  #It won''t matter if they''ve already been realized before.
  realize User[$extgroup]
}

Then any class or module that wants to turn on a specific group of
people just needs to declare a ''add_groups_of_users'' and if
there are
overlaps of people in different groups it won''t be a problem.

There''s a possible problem with my example that I haven''t
tested that
has to do with how strict the User type is. Can you declare a User (or
a virtual User) with a group that doesn''t exist (yet)? If not, then
before you virtualise all your users you''ll need to virtualise all
your groups, maybe even "turn on" the group before you "turn
on" the
users.

Another problem with this is that virtual users are described once and
only once. With this model you have to know all your user and group
data before you start realizing them and you can''t change them easily
once that''s done. It is possible to use class inheritance to override
parameters of virtualised resources, but only once. Going by memory
(and this is all untested), but this would result in a multiple
declaration error:

class users {
  @user luke {
    groups = [ "wheel" ],
  }
}
class users::pulse inherits users {
  User["luke"] { groups += "pulse" }
}
class users::blah inherits users {
  User["luke"] { groups += "blah" }
}
include users::pulse
include users::blah

Lastly, what you''re trying to do is complex, especially with
Puppet''s
"declare once" feature. I tried to do a similar thing with adding and
removing root SSH keys for users: having business groups of staff that
any module could arbitrarily ''turn on''. It turned into a
massive
schamozzle of run levels and multiple classes/defines per user. In the
end I just said to myself "this is ridiculous, there''s got to be a
better way", found RIP''s concat module and never looked back :)
That''s
not the best idea with things like /etc/passwd, /etc/shadow and /etc/
group as any software you install (MySQL, Postgtres, etc) has local
users in it which you''d have to try manage, but just proposing there
might be a completely different way of achieving what you want.

Hope that helps,

-Luke

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, Jan 14, 2011 at 2:23 AM, luke.bigum <luke.bigum@fasthosts.co.uk>
wrote:
> Hi Adam,
>
> Shame you can''t use LDAP or NIS ;) But anyway...
>
Yes it makes me sad.  I''d really, really, really like to use ldap but
my hands are tied.

--snip--
>
> Lastly, what you''re trying to do is complex, especially with
Puppet''s
> "declare once" feature. I tried to do a similar thing with adding
and
> removing root SSH keys for users: having business groups of staff that
> any module could arbitrarily ''turn on''. It turned into a
massive
> schamozzle of run levels and multiple classes/defines per user. In the
> end I just said to myself "this is ridiculous, there''s got to
be a
> better way", found RIP''s concat module and never looked back
:) That''s
> not the best idea with things like /etc/passwd, /etc/shadow and /etc/
> group as any software you install (MySQL, Postgtres, etc) has local
> users in it which you''d have to try manage, but just proposing
there
> might be a completely different way of achieving what you want.
>
> Hope that helps,
>
> -Luke
>

For now, I wrote a function that I pass a list of all the groups to.
It will explode that to a list of unique users that I then pass to my
previously mentioned resources.  This seems to be working well so far.

I think that feature request
http://projects.puppetlabs.com/issues/2084 to auto-realize required
resources would further simplify things.

Thank for all the tips. It''s given me a bit more to work on.

-Adam

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.