On Feb 13, 6:59 am, Christian Requena <cre...@googlemail.com> wrote:
> Hello,
>
> I need to expand the membership of a custom system user depending on the
> availability of some group on the target system i.e.
>
>     user {
>      "logger":
>      name => "logger",
>      ensure => "present",
>      groups => ["adm", "wheel", "this _group_ if it exists"],
>      shell => "/bin/bash";
>      }
>
> The "this _group_ if it exists" entry only works, if the group was
> already create.  I need to expand the list of groups depending on the
> availability of some groups like i.e.
>
>    user {
>      "logger":
>      name => "logger",
>      ensure => "present",
>      [ 'mongodv', 'postgres', 'custom', 'www' ].each do | g |
>          g.exist? _groups < g.to_s
>      end
>      groups => _groups
>      shell => "/bin/bash";
>      }
>
> I know that is totally wrong, but I just want to describe what I'm
> aiming to.


If it's only one specific group that you're talking about, then it
would be pretty easy to implement a custom fact that would allow nodes
to inform the master whether they have the group in question.  That
(facts) is THE means by which nodes inform the master about their
current state.

Nevertheless, your general concept is a poor idea, especially if
you're talking about applying it to multiple groups.  The key issue
here is why the master doesn't know whether the node *should* have the
group in question.  If the master knew whether the group should be
there, then not only would Puppet not have to determine dynamically
whether the group *is* there, but it could also manage the group
itself as needed.

In general, it is far better to explicitly tell Puppet your nodes'
intended configuration than to force Puppet to make configuration
decisions based on existing node configuration.  The former is more
stable, easier to write, and easier to maintain, whereas the latter
effectively means splitting your configuration management between
Puppet and one or more external agents.  Splitting management duties
isn't so bad in itself, but when different agents' areas of
responsibility overlap it gets messy fast.


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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to