making exceptions

[Rob McBroom]

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.

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.

--
Rob McBroom
<http://www.skurfer.com/>

[Ian Ward Comfort]

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 <icom...@rescomp.stanford.edu>
Systems Team Lead, Academic Computing Services, Stanford University

[Rob McBroom]

On Jan 20, 2010, at 6:29 PM, Ian Ward Comfort wrote:

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

OK. I thought about something like that, but I wasn’t clear on how the inheritance would work. Is there any reason why I couldn’t do this more directly?

class puppet::server inherits puppet::client {

File['/etc/puppet/puppet.conf'] {
ensure => undef,
source => undef,
}
}

Thanks.

--
Rob McBroom
<http://www.skurfer.com/>

Because it screws up the order in which people normally read text.

Original message:

> Why is it bad to top-post your reply?

[Ian Ward Comfort]

You could use just the two classes if you wanted. I prefer *not* to
have my ::server classes inherit from my ::client classes, as a
general rule -- server and client functions are logically distinct,
and for any given service it's possible that I'll one day want to run
a server that isn't a client. I gather this is a fairly common
preference, though not a universal one.

[Derek Yarnell]

On 1/21/10 10:47 AM, Rob McBroom wrote:
> OK. I thought about something like that, but I wasn�t clear on how the inheritance would work. Is there any reason why I couldn�t do this more directly?

>
> class puppet::server inherits puppet::client {
> File['/etc/puppet/puppet.conf'] {
> ensure => undef,
> source => undef,
> }
> }
>
> Thanks.
>
>

I do it even more directly by just doing

class puppet::server inherits puppet {

File['/etc/puppet/puppet.conf'] {
ensure => undef,
source => undef,
}
}

Where then the puppet class is added to everyone and puppet::server is
only added to the puppet server(s). I usually have a default then a opt
out class.

Thanks,
derek

--
---
Derek T. Yarnell
University of Maryland
Institute for Advanced Computer Studies