Puppet users - Mar 2011 - design question: Where to manage Users?

Hi!

My company has been successfully using puppet 2.6 for a month now, and
we are now exploring the possibility of managing users and groups
through puppet (vs LDAP). If we were to implement managing
users/groups for various services (e.g. ''www'' for nginx and
apache),
what would be the best design for this? Should we:

* Write a module that defines virtual user resources. Other modules
would realize them as needed. The "accounts" module would be sourced
in by an included statement in our base template class.
* A file in manifests/  that defines virtual users. This file is
sourced by an include statement in site.pp
* Define user resources within the first module that requires them.
Realize them in other modules if as the need arises. (define the
puppet user in the puppet module. A month later, realize it in the
apache::puppetdashboard module when that gets written)


Are there other implementation ideas that I''m missing? Are you
managing user/groups within puppet? How do you implement them?

-- 
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 Mar 9, 4:05 pm, Liberty Young <libe...@rapleaf.com>
wrote:
> Hi!
>
> My company has been successfully using puppet 2.6 for a month now, and
> we are now exploring the possibility of managing users and groups
> through puppet (vs LDAP). If we were to implement managing
> users/groups for various services (e.g. ''www'' for nginx
and apache),
> what would be the best design for this? Should we:
>
> * Write a module that defines virtual user resources. Other modules
> would realize them as needed. The "accounts" module would be
sourced
> in by an included statement in our base template class.
> * A file in manifests/  that defines virtual users. This file is
> sourced by an include statement in site.pp
> * Define user resources within the first module that requires them.
> Realize them in other modules if as the need arises. (define the
> puppet user in the puppet module. A month later, realize it in the
> apache::puppetdashboard module when that gets written)
>
> Are there other implementation ideas that I''m missing? Are you
> managing user/groups within puppet? How do you implement them?
Everything should be in modules.  The only things of substance under
the top-level manifests/ should be global defaults (maybe) and node
declarations (if not covered by an external node classifier).

There is a significant difference between managing the accounts of
human users and managing the accounts of services.  For human users
managed by Puppet, it makes sense to declare them virtually in some
central place, then realize them on those systems to which they
require access.  I follow that approach, and it works well for me.

You asked about service users, however.  Those are different, partly
because they are not normally expected to confer login privileges, but
mostly because they are associated with specific software on your
systems.  To whatever extent you manage such accounts, you should do
so alongside the services with which they are associated.  Thus, if
the Puppet master is managing itself, then it should manage the
"puppet" user in the same module.

It should be rare that different services have direct dependence on
the same user.  In cases where that occurs, that''s a good sign that
the services should be managed through the same module.  Whether it
then makes sense for the User resource to be declared virtually or
concretely (but in the same module either way) depends on the details
of the relationships.

In other cases, however, it may be that one service depends on another
service, but not directly on the second''s service''s user.  In
that
case, the second service need not know or care about the first
service''s user, and it might or might not be managed via the same
module.

So to summarize:

(1) For the accounts of human users, "write a module that defines
virtual user resources. Other modules would realize them as needed."

(2) *If you manage the accounts of services via Puppet* then define
user resources for system services within the module that requires
them, and merge modules to the extent necessary to avoid multiple
modules depending on the same such users.

HOWEVER, there is another alternative: rely on your system''s package
manager to manage software accounts instead of managing them directly
through Puppet (or LDAP, or NIS, etc.).  Whether that is sufficient
depends largely on your security requirements, but it is by far the
easiest way.  It has the advantage of avoiding multiple management
paths for the same data, with the breakage potential that comes along
with that.


John

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

Jon,
Thanks for the input. I''ll have to talk with my team, but it looks
like keeping those service-users in the package (RPM, in our case) is
the way to go.

On Thu, Mar 10, 2011 at 7:44 AM, jcbollinger <John.Bollinger@stjude.org>
wrote:
>
> On Mar 9, 4:05 pm, Liberty Young <libe...@rapleaf.com> wrote:
>> Hi!
>>
>> My company has been successfully using puppet 2.6 for a month now, and
>> we are now exploring the possibility of managing users and groups
>> through puppet (vs LDAP). If we were to implement managing
>> users/groups for various services (e.g. ''www'' for
nginx and apache),
>> what would be the best design for this? Should we:
>>
>> * Write a module that defines virtual user resources. Other modules
>> would realize them as needed. The "accounts" module would be
sourced
>> in by an included statement in our base template class.
>> * A file in manifests/  that defines virtual users. This file is
>> sourced by an include statement in site.pp
>> * Define user resources within the first module that requires them.
>> Realize them in other modules if as the need arises. (define the
>> puppet user in the puppet module. A month later, realize it in the
>> apache::puppetdashboard module when that gets written)
>>
>> Are there other implementation ideas that I''m missing? Are you
>> managing user/groups within puppet? How do you implement them?
>
> Everything should be in modules.  The only things of substance under
> the top-level manifests/ should be global defaults (maybe) and node
> declarations (if not covered by an external node classifier).
>
> There is a significant difference between managing the accounts of
> human users and managing the accounts of services.  For human users
> managed by Puppet, it makes sense to declare them virtually in some
> central place, then realize them on those systems to which they
> require access.  I follow that approach, and it works well for me.
>
> You asked about service users, however.  Those are different, partly
> because they are not normally expected to confer login privileges, but
> mostly because they are associated with specific software on your
> systems.  To whatever extent you manage such accounts, you should do
> so alongside the services with which they are associated.  Thus, if
> the Puppet master is managing itself, then it should manage the
> "puppet" user in the same module.
>
> It should be rare that different services have direct dependence on
> the same user.  In cases where that occurs, that''s a good sign
that
> the services should be managed through the same module.  Whether it
> then makes sense for the User resource to be declared virtually or
> concretely (but in the same module either way) depends on the details
> of the relationships.
>
> In other cases, however, it may be that one service depends on another
> service, but not directly on the second''s service''s user.
 In that
> case, the second service need not know or care about the first
> service''s user, and it might or might not be managed via the same
> module.
>
> So to summarize:
>
> (1) For the accounts of human users, "write a module that defines
> virtual user resources. Other modules would realize them as needed."
>
> (2) *If you manage the accounts of services via Puppet* then define
> user resources for system services within the module that requires
> them, and merge modules to the extent necessary to avoid multiple
> modules depending on the same such users.
>
> HOWEVER, there is another alternative: rely on your system''s
package
> manager to manage software accounts instead of managing them directly
> through Puppet (or LDAP, or NIS, etc.).  Whether that is sufficient
> depends largely on your security requirements, but it is by far the
> easiest way.  It has the advantage of avoiding multiple management
> paths for the same data, with the breakage potential that comes along
> with that.
>
>
> John
>
> --
> 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.
>
>
-- 
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.