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/>
--
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 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 <icomfort@rescomp.stanford.edu> 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 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 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?-- 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 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 -- 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 21 Jan 2010, at 7:47 AM, Rob McBroom wrote:> 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, > } > }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. -- Ian Ward Comfort <icomfort@rescomp.stanford.edu> 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 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.