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