On Mon, Mar 21, 2011 at 01:05:56PM -0700, jcbollinger wrote:
>
> On Mar 21, 1:20 pm, Ashley Gould <[email protected]> wrote:
> > Please forgive my ignorance. I find myself, a linux admin brought
> > up on howtos and books with animals on the cover, suddenly plunged
> > by puppet into a world of developers and computer scientists. Could
> > you explain what is "idempotency" and "support for multiple inclusion"?
>
> Sorry, my bad. The point is that you can include an ordinary class
> multiple times on the same node (multiple inclusion), and the result
> is exactly the same as if that class were included only once
> (idempotency). This can be important in a deep node inheritance
> hierarchy, but it is more commonly important in situations where
> classes include other classes.
>
> For example, a common Puppet idiom is to create a "user" module
> containing a "user::virtual" class in which virtual user resources are
> declared for all system users. Other classes then make decisions
> about which users should actually be present on the system by
> realizing subsets of those users (via Puppet's "realize" function or
> <| |> syntax). In my case, users are assigned to various research
> groups, so I have a class for each group that realizes the users
> associated with that group. But those classes can only work if the
> user::virtual class is included in the node's catalog. It would be
> possible to address that problem by ensuring that each node explicitly
> includes "user::virtual", but that's clunky and subject to breakage.
> Instead, it's better for each class that wants to realize users to
> *itself* include user::virtual, which is possible and completely safe
> provided that user::virtual is not parameterized.
>
> Parameterized classes, on the other hand, can be included only once
> per node, no matter what. This is a substantial limitation on where
> and how such classes can be used.
>
> I hope that helps.
>
This helps bigtime. Thanks to all for the wonderful comments on this
thread. I am much more clear on a lot of things.
I have (for now) solved my issue by using a combination of regular and
param classes and scraping the node inheritance:
class sudoers {
import "rules.pp"
define make_sudoers($default_rules, $extra_rules) {
file { "/tmp/sudoers":
owner => root, group => root, mode => 440,
content => template("sudoers/sudoers.erb"),
notify => Exec["check-sudoers"],
}
exec { "check-sudoers":
command => "/usr/sbin/visudo -cf /tmp/sudoers && \
cp /tmp/sudoers /etc/sudoers",
refreshonly => true,
}
}
make_sudoers {"default":
default_rules => "$rules_unixgroup",
extra_rules => [ "" ],
}
}
class sudoers_extras($rules) inherits sudoers {
Sudoers::Make_sudoers['default'] { extra_rules => $rules }
}
class common {
include "sudoers"
}
node 'sl11lab02-vhost.ucop.edu' {
include "common"
class { sudoers_extras: rules => [ "$rules_aig" ] }
}
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
