If you try to handle unlike OSes in the same class you're in for lots of
debugging and logic issues. I agree with Walter, you'll want to
subclass them.
If you name your subclasses according to the results of the built-in
osfamily fact (which should return RedHat for both RHEL and CentOS) you
can do:
class php {
include "php::${::osfamily}"
}
We do RHEL, Oracle Linux, and Solaris in a similar fashion. Each would
then be handled by its own subclass, but the osfamily fact allowed for
sharing configs between like systems.
The other issue we ran into was that Solaris and Linux use different
facts to reflect their major release values. I'm not sure if something
similar would happen with Gentoo or not (hopefully not since it's also
Linux). This also got me thinking about the logic required for choosing
between major releases when they have incompatible changes. It wasn't
strictly necessary, but I wrote a custom fact to make things simpler.
It combines OS and major release into a single fact (with matching
'family' fact) so that like systems can be easily and consistently
grouped in both Puppet and Hiera regardless of which OS I'm using. It
should be pretty straightforward to extend to other systems if you find
it useful.
My main class would look like so:
class php {
include "php::${::os_build_family}"
}
With subclasses:
class php::rhel_5::fpm {
}
class php::rhel_5::cli {
}
class php::rhel_5::mod {
}
And similar subclasses for other OSes. Of course if the code needs to
be shared differently then the kernel, operatingsystem, or osfamily
facts may make more sense.
The os_build/os_build_family custom facts we use are produced in
os_build.rb:
require 'facter'
case Facter.value('operatingsystem')
when 'RedHat'
if Facter.value('operatingsystemrelease')
release = Facter.value('operatingsystemrelease').split('.')[0]
Facter.add('os_build') do
setcode {"rhel_#{release}"}
end
Facter.add('os_build_family') do
setcode {"rhel_#{release}"}
end
end
when 'OracleLinux'
if Facter.value('operatingsystemrelease')
release = Facter.value('operatingsystemrelease').split('.')[0]
Facter.add('os_build') do
setcode {"ol_#{release}"}
end
Facter.add('os_build_family') do
setcode {"rhel_#{release}"}
end
end
when 'Solaris'
if Facter.value('operatingsystemrelease')
release=Facter.value('operatingsystemrelease').split('.')[1]
Facter.add('os_build') do
setcode {"sol_#{release}"}
end
Facter.add('os_build_family') do
setcode {"sol_#{release}"}
end
end
end
On 03/29/2012 05:14 PM, Walter Heck wrote:
> From what I've seen in other modules, the more common way is to do
> something like this:
>
> class php {
> case $::operatingsystem {
> 'Gentoo': {
> include php::gentoo
> }
> /(RedHat|CentOS)/: {
> include php::redhat
> }
> }
>
> And then implement the correct packages and files inside those
> subclasses. You can still have a class called php::fpm which then
> configures fpm, it would have class parameters for the specific file
> paths that change per OS for instance.
>
> good luck,
>
> Walter
>
> On Fri, Mar 30, 2012 at 00:29, Matthias Saou <matth...@saou.eu> wrote:
>> Hi,
>>
>> Before making any further changes to my existing PHP module, I'd like
>> to get a few recommendations from anyone who has already faced this
>> problem...
>>
>> My existing module supports Fedora, RHEL and clones. I'd like to extend
>> support to more distributions, by adding a typical "params" class to it.
>>
>> So far, so good. I've already done it for other modules.
>>
>> *BUT* in the case of PHP, file locations, file splitting and package
>> splitting can be extremely different from one distro to the next.
>>
>> For instance, in the case of Fedora/RHEL we have :
>> * Packages : php-cli, php-fpm, php (for mod_php)
>> * Configurations : /etc/php.ini, /etc/php.d/, /etc/php-fpm.conf,
>> /etc/php-fpm.d/
>>
>> Now in the case of Gentoo (don't ask) :
>> * Package : dev-lang/php (only this one for everything)
>> * Configurations : *lots* such as these :
>> /etc/php/cli-php${php_version}/php.ini
>> /etc/php/fpm-php${php_version}/php.ini
>> /etc/php/fpm-php${php_version}/php-fpm.conf
>> /etc/php/fpm-php${php_version}/ext/
>> /etc/php/fpm-php${php_version}/ext-active/
>>
>> I want to keep my module very flexible : Install only CLI, only FPM,
>> only Apache httpd module or any combination of those three.
>>
>> The first problem I'm facing is with package requirements, where even
>> with virtual resources I'm in a dead end. Not to mention wanting to
>> support "ensure => absent" on any of CLI/FPM/mod when there's a single
>> package for all three will no longer be easy.
>>
>> Right now, I'm going this way :
>> # packages
>> case $::operatingsystem {
>> 'Gentoo': {
>> @package { 'dev-lang/php': ensure => installed }
>> $package_cli = 'dev-lang/php'
>> $package_fpm = 'dev-lang/php'
>> }
>> /(RedHat|CentOS)/: {
>> @package { 'php-cli': ensure => installed }
>> @package { 'php-fpm': ensure => installed }
>> $package_cli = 'php-cli'
>> $package_fpm = 'php-fpm'
>> }
>> }
>>
>> Then I'll be realizing $package_<x> where relevant. Is there any better
>> way to do this?
>>
>> Cheers,
>> Matthias
>>
>> --
>> 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+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-users@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.
