I''ve been using Puppet very happily for the last 6 months or so to manage our CentOS and RHEL servers. Over the summer I want to knock things up a notch <bam />, and part of that is going to be supporting a wider range of OSes. First on the hit list are likely to be Solaris 10 and Suse (SLES). I know a lot of people do support multiple OSes, just wondered what sort of approach you''ve found works best? Of course at the end of the day it''s a question of ''case $operatingsystem'' statements, but I wondered whether you create a dedicated ''os'' module, or whether you structure each module in a standard way, or something else. Thanks for any pointers. -- 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 05/11/2010 05:45 AM, Dick Davies wrote:> I''ve been using Puppet very happily for the last 6 months > or so to manage our CentOS and RHEL servers. > > Over the summer I want to knock things up a notch<bam />, > and part of that is going to be supporting a wider range of OSes. > First on the hit list are likely to be Solaris 10 and Suse (SLES). > > I know a lot of people do support multiple OSes, just wondered > what sort of approach you''ve found works best? > > > Of course at the end of the day it''s a question of ''case $operatingsystem'' > statements, but I wondered whether you create a dedicated ''os'' module, > or whether you structure each module in a standard way, or something > else. > > Thanks for any pointers. > >Generally if the changes are really profound, I will split a module into os-specific classes inside init.pp using an operatingsystem case statement. If the changes are small I will use selectors in the resources. I also set a bunch of resource defaults in site.pp to make multi-os modules more readable. An example is OpenBSD; there is no root group, so I do this: File { backup => "main", ensure => "present", group => $kernel ? { Linux => "root", OpenBSD => "wheel" }, owner => "root" } -- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode "When the going gets weird, the weird turn pro." -- 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 05/11/2010 05:45 AM, Dick Davies wrote:> I''ve been using Puppet very happily for the last 6 months > or so to manage our CentOS and RHEL servers. > > Over the summer I want to knock things up a notch<bam />, > and part of that is going to be supporting a wider range of OSes. > First on the hit list are likely to be Solaris 10 and Suse (SLES). > > I know a lot of people do support multiple OSes, just wondered > what sort of approach you''ve found works best? > > > Of course at the end of the day it''s a question of ''case $operatingsystem'' > statements, but I wondered whether you create a dedicated ''os'' module, > or whether you structure each module in a standard way, or something > else. > > Thanks for any pointers. > >I forgot to add- the splitting inside init.pp allows for generic includes- like you just say include common, and it gets the os-specific class such as common::solaris through black magic. -- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode "When the going gets weird, the weird turn pro." -- 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 Tuesday 11 May 2010, ext Dick Davies wrote:> I''ve been using Puppet very happily for the last 6 months > or so to manage our CentOS and RHEL servers. > > Over the summer I want to knock things up a notch <bam />, > and part of that is going to be supporting a wider range of OSes. > First on the hit list are likely to be Solaris 10 and Suse > (SLES). > > I know a lot of people do support multiple OSes, just wondered > what sort of approach you''ve found works best? >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. -- Rohan -- 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.
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-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 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-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.
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 <donavan@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-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.