On 20 Jan 2010, at 1:30 PM, Rob McBroom wrote:
I’m sure this has been discussed, but it’s one of those things
that’s impossible to search for because there are a million ways to
ask the question, so forgive me if this is repetitive.
My nodes are all defined externally (in LDAP).
The LDAP entry for each system can have multiple “classification”
attributes. In my mind, these are “groups” or “tags” for the system.
In Puppet’s mind, they are “classes” that it should include in the
manifests.
This works out great most of the time. I can have Puppet do all
sorts of things to systems based on classification(s). But what if I
*don’t* want it to do something?
For instance, what if I want to push puppet.conf to every system as
a rule, but not push it to a system with ‘classification:
puppetmaster’? In the case of Puppet, with the different executables
getting their own sections of the file, I could of course just push
the server’s config file to all the clients without hurting
anything, but that isn’t always an option.
Yeah, this isn't an option if you use storeconfigs, for example -- you
don't want all your clients seeing the db password that your
puppetmaster is using for that. (I still have my puppetmaster manage
its own puppet.conf by cobbling together file fragments, but that's a
separate topic.)
Specifically, I don’t want the bp.conf file to be managed on our new
NetBackup server, but it’s managed by default on every system. There
doesn’t seem to be a way to test multi-valued things like
if (!classes contains ‘backupserver’) {}
I could of course assign a “backupclient” class to the clients and
not the server, but that means giving the same class to 899 out of
900 systems, which is stupid.
Maybe I could set a puppetVar in LDAP for the backup server? But
since the class already identifies it as a backup server, this would
be repeating info in two places, which I can rarely bring myself to
do (and we’d have to remember to add it both places for a variety of
things).
Any ideas? Thanks in advance.
I think a lot of shops do this by creating special "disabling" classes
for those one-off systems. To use your puppetmaster example (untested
pseudocode ahead):
class puppet::client {
file { '/etc/puppet/puppet.conf':
ensure => present,
source => 'puppet:///puppet/configfile',
}
}
class puppet::client::disabled inherits puppet::client {
File['/etc/puppet/puppet.conf'] {
ensure => undef,
source => undef,
}
}
class puppet::server {
include puppet::client::disabled
}
Now it's safe to apply puppet::client to all your nodes, including
your puppetmaster, because the ::disabled class will override the
management of puppet.conf on the puppetmaster (which presumably
includes the puppet::server class).
--
Ian Ward Comfort <[email protected]>
Systems Team Lead, Academic Computing Services, Stanford University
--
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.
