Puppet users - Apr 2010 - Using classes from extnode to define config files?

Hi all,

I''m using cobbler as our external node manager and it''s
working really
well (including deployment of ActiveMQ from RI''s RPMS and Mcollective -
blog post coming soon!) however I''ve run into a problem with exim
configuration files.

We use exim in a number of different configurations depending on the
role of the server (webserver/antivirus/outbound STMP/etc.) and I''d
like
to be able to send the correct config file to the puppet node based upon
the class that is provided by Cobbler
(webserver/antivirusserver/mailserver/etc.). 

Is this possible?  I''m sure it is, I just can''t find the
syntax on the
puppetlabs site to make it work!

If someone can give me help on this, I''ll document it on my blog and
give full credit!

I kind of see it happening as follows:


file { "/etc/exim/exim.conf":
		path => "/etc/exim/exim.conf",
		ensure => present,
		source => "puppet:///modules/exim/exim-$CLASSNAME.conf",
		owner => "exim",
		group => "exim",
		mode => 644,
		require => Package["exim"],
}

but I''m not too sure how to set the value of $CLASSNAME.

Thanks in advance,

Matt

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

> but I''m not too sure how to set the value of $CLASSNAME.
we do something similar:

file{''/etc/exim/exim.conf'':
   source => [
"puppet://$server/modules/site-exim/${fqdn}/exim.conf",
              
"puppet://$server/modules/site-exim/${exim_type}/exim.conf",
               "puppet://$server/modules/site-exim/exim.conf",
               "puppet://$server/modules/exim/exim.conf" ],
   require => Package[''exim''],
   notify => Service[''exim''],
   owner => root, group => mail, mode => 0640;
}

http://git.puppet.immerda.ch/?p=module-exim.git;a=blob;f=manifests/base.pp;h=a0b2d02ca3e1a95b0ddc0b48fa54efb5d2981774;hb=76f594abd5dabffe86bdaeecb99b15bda4b968fc#l13

what we do then is to set per node the variable (or in an external  
node tool called parameter) $exim_type to set it to something like  
''antivirus'', ''webhosting'' or whatever. and
then have in
site-exim/files/antivirus/ the appropriate config file.

btw: we nearly got rid off that, as we started to split the exim  
configuration into different subfiles and including them. We then  
deploy only these include files based on exim_type. This has the  
advantage, that we have only one identical main-exim config and do all  
the tweaks in little files we just include.

cheers pete

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

This will work, but I''d use a selector.   Search for
"selector" in
this document:  http://docs.puppetlabs.com/guides/more_language.html

The reason being, is you could supply a default if no match was found,
rather than it just generating an error.

I would use one to assign a variable to the template name, and just do
template($template_name) as normal, that way you don''t evaluate
template() more than once.

A node can belong to more than one class, so I wouldn''t rely on the
idea of using $CLASSNAME.    (For instance, the external nodes system
could say "I''m a webserver", and "I''m also an
appserver" later.

Since you''re using cobbler, you any --ksmeta variables you set are
available as variables in Puppet.

(Others can see docs on this here:
https://fedorahosted.org/cobbler/wiki/UsingCobblerWithConfigManagementSystem
)

Parameterized classes, coming in the next release, will make this a
lot easier -- though it''s something Cobbler''s going to have to
adapt
to.

--Michael

On Fri, Apr 30, 2010 at 6:10 AM, Peter Meier <peter.meier@immerda.ch>
wrote:
>> but I''m not too sure how to set the value of $CLASSNAME.
>
> we do something similar:
>
> file{''/etc/exim/exim.conf'':
>  source => [
"puppet://$server/modules/site-exim/${fqdn}/exim.conf",
>            
 "puppet://$server/modules/site-exim/${exim_type}/exim.conf",
>              "puppet://$server/modules/site-exim/exim.conf",
>              "puppet://$server/modules/exim/exim.conf" ],
>  require => Package[''exim''],
>  notify => Service[''exim''],
>  owner => root, group => mail, mode => 0640;
> }
>
>
http://git.puppet.immerda.ch/?p=module-exim.git;a=blob;f=manifests/base.pp;h=a0b2d02ca3e1a95b0ddc0b48fa54efb5d2981774;hb=76f594abd5dabffe86bdaeecb99b15bda4b968fc#l13
>
> what we do then is to set per node the variable (or in an external node
tool
> called parameter) $exim_type to set it to something like
''antivirus'',
> ''webhosting'' or whatever. and then have in
site-exim/files/antivirus/ the
> appropriate config file.
>
> btw: we nearly got rid off that, as we started to split the exim
> configuration into different subfiles and including them. We then deploy
> only these include files based on exim_type. This has the advantage, that
we
> have only one identical main-exim config and do all the tweaks in little
> files we just include.
>
> cheers pete
>
> --
> 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.
>
>
-- 
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 Fri, 2010-04-30 at 12:10 +0200, Peter Meier wrote:
> > but I''m not too sure how to set the value of $CLASSNAME.
> 
> we do something similar:
> 
> file{''/etc/exim/exim.conf'':
>    source => [
"puppet://$server/modules/site-exim/${fqdn}/exim.conf",
>               
"puppet://$server/modules/site-exim/${exim_type}/exim.conf",
>                "puppet://$server/modules/site-exim/exim.conf",
>                "puppet://$server/modules/exim/exim.conf" ],
>    require => Package[''exim''],
>    notify => Service[''exim''],
>    owner => root, group => mail, mode => 0640;
> }
> 
>
http://git.puppet.immerda.ch/?p=module-exim.git;a=blob;f=manifests/base.pp;h=a0b2d02ca3e1a95b0ddc0b48fa54efb5d2981774;hb=76f594abd5dabffe86bdaeecb99b15bda4b968fc#l13
> 
> what we do then is to set per node the variable (or in an external  
> node tool called parameter) $exim_type to set it to something like  
> ''antivirus'', ''webhosting'' or whatever.
and then have in
> site-exim/files/antivirus/ the appropriate config file.
> 
> btw: we nearly got rid off that, as we started to split the exim  
> configuration into different subfiles and including them. We then  
> deploy only these include files based on exim_type. This has the  
> advantage, that we have only one identical main-exim config and do all  
> the tweaks in little files we just include.
> 
> cheers pete
> 
Hi Pete,

I''ve decided to go with the following in the end:

==================================# define the config file to use
	if(tagged("webserver")) {
		$filename = "webserver"
	}
	else
	{
		$filename = "smtpserver"
	}


	file { "/etc/exim/exim.conf":
	        path => "/etc/exim/exim.conf",
		ensure => present,
		source => "puppet:///modules/exim/exim-$filename.conf",
		owner => "exim",
		group => "exim",
		mode => 644,
		require => Package["exim"],
	}
======================
Does anyone know how to achieve the above in a "prettier" fashion?

M.

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

>
> Does anyone know how to achieve the above in a "prettier"
fashion?
Thinking about it some more...

Create a baseclass called "exim" and subclasses called
"exim:web" and
"exim:smtp"

Have the class "webserver" include exim:web and the class
"smtpserver"
include "exim:smtp".

--Michael

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

Hi All,

I hope this ends up in the right place, as I haven’t tried posting to the list
in this way before.  In any case,
Michael DeHaan recently proffered this advice:
> > Does anyone know how to achieve the above in a "prettier"
fashion?
>
> Thinking about it some more...
>
> Create a baseclass called "exim" and subclasses called
"exim:web" and
> "exim:smtp"
>
> Have the class "webserver" include exim:web and the class
"smtpserver"
> include "exim:smtp".
Although that likely could be made to work, it seems needlessly brittle to me. 
Each subclass must be careful to not override the base class in a way that is
incompatible with the other subclass, lest nodes that include both subclasses
break.  The door is open for such breakage to occur with a manifest update at
any point in the future, and the nature of the issue makes it a greater than
average risk to slip through QA.

In general, I think Puppet subclassing should be avoided wherever it does not
provide a substantial win over the alternatives.  If one of the alternatives is
including a class instead of extending that class, then including is usually
better.

In particular, if a subclass does not override its base class in some way, then
it can and should be rewritten to include the erstwhile base class instead of
extending it.  As described above, moreover, it is risky for any node to include
two descendents of the same class, therefore any inheritance tree where siblings
are not mutually exclusive should be refactored.

Good manifest design reaps great rewards in maintainability and future
development.


Regards,

John

Email Disclaimer:  www.stjude.org/emaildisclaimer

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