Puppet users - Dec 2009 - Best practice for modules used for multiple environments

Hi.


Some types of configurations need different parameters depending on which
environment/network the puppet client reside in. An example is DNS
configuration found in /etc/resolv.conf, which may vary depending on which
network the puppet client is on. Another example is LDAP client setup, may
also vary depending on the LDAP server infrastucture.

Is there any best practice on how to deal with these issues? I''m
planning on
creating my own LDAP client module, and could need some advice on how to
solve this multiple environment/network problem. One way might be to define
variables such as "$environment = qass1.example.com" (or
"$environment qass2.example.com" and so forth) in the node definition
for every puppet
client, but maybe there''s smarter ways of doing this.


Best regards,
Kenneth Holter

--

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 might consider using extlookup (http://nephilim.ml.org/~rip/puppet/*
extlookup*.rb)
or if you use foreman, you could define variables in different levels (e.g.
in the domain level, subnet level etc).
cheers,
Ohad

On Thu, Dec 10, 2009 at 7:19 PM, Kenneth Holter
<kenneho.ndu@gmail.com>wrote:
> Hi.
>
>
> Some types of configurations need different parameters depending on which
> environment/network the puppet client reside in. An example is DNS
> configuration found in /etc/resolv.conf, which may vary depending on which
> network the puppet client is on. Another example is LDAP client setup, may
> also vary depending on the LDAP server infrastucture.
>
> Is there any best practice on how to deal with these issues? I''m
planning
> on creating my own LDAP client module, and could need some advice on how to
> solve this multiple environment/network problem. One way might be to define
> variables such as "$environment = qass1.example.com" (or
"$environment > qass2.example.com" and so forth) in the node
definition for every puppet
> client, but maybe there''s smarter ways of doing this.
>
>
> Best regards,
> Kenneth Holter
>
>
>
> --
> 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<puppet-users%2Bunsubscribe@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.

Yeah I have a similar issue as I have to configure SNMP on different clients
and the structure of SNMP (configurations files and service management) is
different and vary from client to client as some clients are running on
Fedora, some on SuSe and some on IBM AIX.

any suggestions and comments are highly appreciated.
Best Regards
Haris Farooque


On Thu, Dec 10, 2009 at 12:19 PM, Kenneth Holter
<kenneho.ndu@gmail.com>wrote:
> Hi.
>
>
> Some types of configurations need different parameters depending on which
> environment/network the puppet client reside in. An example is DNS
> configuration found in /etc/resolv.conf, which may vary depending on which
> network the puppet client is on. Another example is LDAP client setup, may
> also vary depending on the LDAP server infrastucture.
>
> Is there any best practice on how to deal with these issues? I''m
planning
> on creating my own LDAP client module, and could need some advice on how to
> solve this multiple environment/network problem. One way might be to define
> variables such as "$environment = qass1.example.com" (or
"$environment > qass2.example.com" and so forth) in the node
definition for every puppet
> client, but maybe there''s smarter ways of doing this.
>
>
> Best regards,
> Kenneth Holter
>
>
>
> --
> 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<puppet-users%2Bunsubscribe@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.

2009/12/10 M.F.Haris <mfharis@gmail.com>:
> Yeah I have a similar issue as I have to configure SNMP on different
clients
> and the structure of SNMP (configurations files and service management) is
> different and vary from client to client as some clients are running on
> Fedora, some on SuSe and some on IBM AIX.
I''ve been trying to get some modules written for CentOS/RedHat working
on my Ubuntu systems, and wondering the best way to do this myself.  A
good example is the differences between Apache on the two kinds of
system:

Apache runs as ''www'' on the RH systems, and
''www-data'' on the
Debian-ish systems.
The default docroot is different as well - ''/var/www/html'' on
RH and
''/var/www'' on Debian/Ubuntu.

The best solution I can think of at the module level is custom facts -
ideally derived from a source of truth like the apache packages
themselves.

J.
-- 
Julian Simpson
Software Build and Deployment
http://www.build-doctor.com
http://twitter.com/builddoctor

--

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.

> I''ve been trying to get some modules written for CentOS/RedHat
working
> on my Ubuntu systems, and wondering the best way to do this myself.  A
> good example is the differences between Apache on the two kinds of
> system:
>
> Apache runs as ''www'' on the RH systems, and
''www-data'' on the
> Debian-ish systems.
> The default docroot is different as well -
''/var/www/html'' on RH and
> ''/var/www'' on Debian/Ubuntu.
>
> The best solution I can think of at the module level is custom facts -
> ideally derived from a source of truth like the apache packages
> themselves.
I have done that by pretty and/or ugly statements like the following

$vhosts_dir = $operatingsystem ? {
   centos => "$apache::centos::config_dir/vhosts.d",
   gentoo => "$apache::gentoo::config_dir/vhosts.d",
   debian => "$apache::debian::config_dir/vhosts.d",
   ubuntu => "$apache::ubuntu::config_dir/vhosts.d",
   openbsd => "$apache::openbsd::config_dir/vhosts.d",
   default => ''/etc/apache2/vhosts.d'',
}

[1]

so far it works quite well.

cheers pete

[1]  
http://git.puppet.immerda.ch/?p=module-apache.git;a=blob;f=manifests/vhost/file.pp;h=caa649d12dba0d37108eb2878ed824077d93cacf;hb=00c03fcdaad9322c7610437953ee0fb4c009d4b5#l20

--

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.

hello,

----- "Peter Meier" <peter.meier@immerda.ch> wrote:
> $vhosts_dir = $operatingsystem ? {
>    centos => "$apache::centos::config_dir/vhosts.d",
>    gentoo => "$apache::gentoo::config_dir/vhosts.d",
>    debian => "$apache::debian::config_dir/vhosts.d",
>    ubuntu => "$apache::ubuntu::config_dir/vhosts.d",
>    openbsd => "$apache::openbsd::config_dir/vhosts.d",
>    default => ''/etc/apache2/vhosts.d'',
> }
> 
or you can use extlookup[1] to build these maps, and it all just becomes:

$vhosts_dir = extlookup("vhost_dir")

and you can reuse that data source anywhere u need it

http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.php

--

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.

Currently, we handle this by using variables that we set when parsing site.pp. 
We have a directory /etc/puppet/manifests/resources.  In site.pp, we have
''import resources/*'' before we have any node definitions.  One
of the files in the resources directory may be something like sites.pp where we
have something like the following:

case $sitecode {
	"FO": {
		$ldapserver = ''foldap.domain.com''
		$nameserver =
[''192.168.2.2'',''192.168.2.3'']
		$searchpath =
[''domain.com'',''fo.domain.com'']
	}

	"RT": {	
		$ldapserver = ''rtldap.domain.com''
		$nameserver = [''192.24.4.3'',''192.24.4.4'']
		$searchpath =
[''domain.com'',''rt.domain.com'']
	}
}

Then just use the appropriate variable in your module.  We also use this
approach to define site specific (or network specific) virtual resources so in
the modules we just realize all resources of a certain type.

It would be very easy to create an environment for each site/network you have
and then you could define a resources directory for each site/network instead of
having one that''s full of conditionals.

On Dec 10, 2009, at 5:19 AM, Kenneth Holter wrote:
> Hi.
>  
>  
> Some types of configurations need different parameters depending on which
environment/network the puppet client reside in. An example is DNS configuration
found in /etc/resolv.conf, which may vary depending on which network the puppet
client is on. Another example is LDAP client setup, may also vary depending on
the LDAP server infrastucture.
>  
> Is there any best practice on how to deal with these issues? I''m
planning on creating my own LDAP client module, and could need some advice on
how to solve this multiple environment/network problem. One way might be to
define variables such as "$environment = qass1.example.com" (or
"$environment = qass2.example.com" and so forth) in the node
definition for every puppet client, but maybe there''s smarter ways of
doing this.
>  
>  
> Best regards,
> Kenneth Holter
>  
>  
> 
> --
> 
> 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.

I do this exactly the same way, we just use the domainname fact and match
that to the site.  All really depends on the environment of course.

Works perfectly, one thing you might want to stick is a default at the
bottom which either provides a failsafe set of attributes and/or fails so
you can pick it up in a logscraper and alert on it.

 default: {
    161      fail(''FAIL: Unable to determine location.'')
    162   }


-Chris

On Thu, Dec 10, 2009 at 7:25 AM, Carl Caum <carl.caum@gmail.com> wrote:
> Currently, we handle this by using variables that we set when parsing
> site.pp.  We have a directory /etc/puppet/manifests/resources.  In site.pp,
> we have ''import resources/*'' before we have any node
definitions.  One of
> the files in the resources directory may be something like sites.pp where
we
> have something like the following:
>
> case $sitecode {
> "FO": {
> $ldapserver = ''foldap.domain.com''
> $nameserver =
[''192.168.2.2'',''192.168.2.3'']
> $searchpath =
[''domain.com'',''fo.domain.com'']
> }
>
> "RT": {
> $ldapserver = ''rtldap.domain.com''
> $nameserver =
[''192.24.4.3'',''192.24.4.4'']
> $searchpath =
[''domain.com'',''rt.domain.com'']
> }
> }
>
> Then just use the appropriate variable in your module.  We also use this
> approach to define site specific (or network specific) virtual resources so
> in the modules we just realize all resources of a certain type.
>
> It would be very easy to create an environment for each site/network you
> have and then you could define a resources directory for each site/network
> instead of having one that''s full of conditionals.
>
> On Dec 10, 2009, at 5:19 AM, Kenneth Holter wrote:
>
> Hi.
>
>
> Some types of configurations need different parameters depending on which
> environment/network the puppet client reside in. An example is DNS
> configuration found in /etc/resolv.conf, which may vary depending on which
> network the puppet client is on. Another example is LDAP client setup, may
> also vary depending on the LDAP server infrastucture.
>
> Is there any best practice on how to deal with these issues? I''m
planning
> on creating my own LDAP client module, and could need some advice on how to
> solve this multiple environment/network problem. One way might be to define
> variables such as "$environment = qass1.example.com" (or
"$environment > qass2.example.com" and so forth) in the node
definition for every puppet
> client, but maybe there''s smarter ways of doing this.
>
>
> Best regards,
> Kenneth Holter
>
>
>
> --
> 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<puppet-users%2Bunsubscribe@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.

This looks really great. I will definately look into this approach. Thanks
for the tip!


Regards,
Kenneth

On Thu, Dec 10, 2009 at 12:47 PM, Ohad Levy <ohadlevy@gmail.com> wrote:
> You might consider using extlookup (http://nephilim.ml.org/~rip/puppet/*
> extlookup*.rb)
> or if you use foreman, you could define variables in different levels (e.g.
> in the domain level, subnet level etc).
> cheers,
> Ohad
>
>   On Thu, Dec 10, 2009 at 7:19 PM, Kenneth Holter
<kenneho.ndu@gmail.com>wrote:
>
>>   Hi.
>>
>>
>> Some types of configurations need different parameters depending on
which
>> environment/network the puppet client reside in. An example is DNS
>> configuration found in /etc/resolv.conf, which may vary depending on
which
>> network the puppet client is on. Another example is LDAP client setup,
may
>> also vary depending on the LDAP server infrastucture.
>>
>> Is there any best practice on how to deal with these issues?
I''m planning
>> on creating my own LDAP client module, and could need some advice on
how to
>> solve this multiple environment/network problem. One way might be to
define
>> variables such as "$environment = qass1.example.com" (or
"$environment >> qass2.example.com" and so forth) in the node
definition for every puppet
>> client, but maybe there''s smarter ways of doing this.
>>
>>
>> Best regards,
>> Kenneth Holter
>>
>>
>>
>> --
>> 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<puppet-users%2Bunsubscribe@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<puppet-users%2Bunsubscribe@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.