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