Re: [Puppet Users] Re: multiple OS support conventions?
Thanks all, think I had it in my head that a general 'os' module
could do simplify this, but I think you're probably right that handling
in the individual modules is better.
Then I can migrate to multi-platform support module by module,
and there's much less cross-module dependencies involved.
Thanks again!
On Fri, May 14, 2010 at 6:17 PM, donavan dona...@desinc.net wrote:
On May 12, 1:03 am, Rohan McGovern rohan.mcgov...@nokia.com wrote:
I've been doing it like this, for an example module
named baselayout:
modules/baselayout/manifests/init.pp:
import *
class baselayout {
case $operatingsystem {
Darwin: { include baselayout::mac }
OpenSuSE: { include baselayout::suse }
}
}
modules/baselayout/manifests/mac.pp:
class baselayout::mac {
...
}
modules/baselayout/manifests/suse.pp:
class baselayout::suse {
...
}
... etc. I've just started, so there could be problems with this I
haven't hit yet.
+1 on this method. I handle it pretty much the same way. The
difference would be using a modulename::base class for all of the
common setup. Depending on the specific child classes they can then
inherit modulename::base or include it. A simple exmaple can be seen
in the Camp to Camp augeas module[1]. In general I try to avoid using
parameter selectors for this type of customization.
[1]
http://github.com/camptocamp/puppet-augeas/blob/master/manifests/classes/augeas.pp
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: multiple OS support conventions?
On May 12, 1:03 am, Rohan McGovern rohan.mcgov...@nokia.com wrote:
I've been doing it like this, for an example module
named baselayout:
modules/baselayout/manifests/init.pp:
import *
class baselayout {
case $operatingsystem {
Darwin: { include baselayout::mac }
OpenSuSE: { include baselayout::suse }
}
}
modules/baselayout/manifests/mac.pp:
class baselayout::mac {
...
}
modules/baselayout/manifests/suse.pp:
class baselayout::suse {
...
}
... etc. I've just started, so there could be problems with this I
haven't hit yet.
+1 on this method. I handle it pretty much the same way. The
difference would be using a modulename::base class for all of the
common setup. Depending on the specific child classes they can then
inherit modulename::base or include it. A simple exmaple can be seen
in the Camp to Camp augeas module[1]. In general I try to avoid using
parameter selectors for this type of customization.
[1]
http://github.com/camptocamp/puppet-augeas/blob/master/manifests/classes/augeas.pp
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: multiple OS support conventions?
My approach to manage different OS is similar to the ones suggested
before.
With these basic buidelines:
- When differences among OS are rather substancial, include specific
subclasses:
case $operatingsystem {
debian: { include apache::debian }
ubuntu: { include apache::debian }
default: { }
}
- When differences are just packages names, config file paths and so
on, managge differences in a specific params subclass where interla
variables are defined accoring to the OS:
class apache::params {
# Basic settings
$packagename = $operatingsystem ? {
freebsd = apache20,
debian = apache2,
ubuntu = apache2,
default = httpd,
}
$servicename = $operatingsystem ? {
debian = apache2,
ubuntu = apache2,
default = httpd,
}
$username = $operatingsystem ? {
debian = www-data,
ubuntu = www-data,
default = apache,
}
$configfile = $operatingsystem ?{
freebsd = /usr/local/etc/apache20/httpd.conf,
ubuntu = /etc/apache2/apache2.conf,
debian = /etc/apache2/apache2.conf,
default = /etc/httpd/conf/httpd.conf,
}
$configdir = $operatingsystem ?{
freebsd = /usr/local/etc/apache20,
ubuntu = /etc/apache2,
debian = /etc/apache2,
default = /etc/httpd/conf,
}
$documentroot = $operatingsystem ?{
debian = /var/www,
ubuntu = /var/www,
suse= /srv/www,
default = /var/www/html,
}
}
...
In the above examples my default is RedHat/Centos, but it should be
better to explicitely define them.
- Classic Package-Service-ConfigFiles cases are manage in an unique
class:
class apache {
require apache::params
package { apache:
name = ${apache::params::packagename},
ensure = present,
}
service { apache:
name = ${apache::params::servicename},
ensure = running,
enable = true,
pattern = ${apache::params::servicepattern},
hasrestart = true,
hasstatus = true,
require = Package[apache],
subscribe = File[httpd.conf],
}
file { httpd.conf:
# mode = 644, owner = root, group = root,
require = Package[apache],
ensure = present,
path = ${apache::params::configfile},
}
case $operatingsystem {
debian: { include apache::debian }
ubuntu: { include apache::debian }
default: { }
}
if $backup == yes { include apache::backup }
if $monitor == yes { include apache::monitor }
if $firewall == yes { include apache::firewall }
}
- Generally I prefer to avoid defining / setting owners/permissions on
files I leave them to the standards provided byy the relevant
packakes...
My 2c
Al
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
