Solaris Support in Modules - puppet and openssh require puppi, all of which fail to apply...

[Sean Alderman]

I have forked, openssh, puppet and now puppi to try and get these to apply to a solaris box.  At the moment, I'm a little overwhelmed with Puppi, but it appears some work to support solaris has been done in the function of puppi, but not in the puppet module parts.  There are Solaris operatingsystem selectors in extras.pp, but none in params.pp.

When I attempt to apply the puppet module to a solaris box, I get bunches of errors for Solaris Package Source problems.  I intend to fix these and submit pull requests for you to merge if you choose. 

Challenges as I see them:

1. Handling the SUNW package source. There is no grand public repository for Oracle's SUNW packages, so Package Source would be a user drive parameter, or perhaps packages should be deployed from the module's files directory?
   
2. OpenCSW does not provide all of the Example42 dependencies. 
   
3. Choosing the Package Provider based on package, not globally for the module.
4.  How the SUNW root and user packages for a piece of software are managed.  I'm not sure that this isn't more of a Puppet-Users question. Linux = package, Solaris = package(s), provider, source all via parameter driven package resource?
   

I saw you had posted some questions in this regard to the Puppet-Users list a few years ago.  Do you have a recommendation on how to resolve this?...left to my own devices I'll probably choose a poor direction :)

[Alessandro Franceschi]

Solaris support has been introduced in very few modules, and in puppi is still incomplete (mostly because I personally don't find often the occasion to work on it), but any patch or fix on this is very welcomed.

On Tuesday, August 6, 2013 5:13:56 PM UTC+2, Sean Alderman wrote:

I have forked, openssh, puppet and now puppi to try and get these to apply to a solaris box.  At the moment, I'm a little overwhelmed with Puppi, but it appears some work to support solaris has been done in the function of puppi, but not in the puppet module parts.  There are Solaris operatingsystem selectors in extras.pp, but none in params.pp.

When I attempt to apply the puppet module to a solaris box, I get bunches of errors for Solaris Package Source problems.  I intend to fix these and submit pull requests for you to merge if you choose. 

Challenges as I see them:

1. Handling the SUNW package source. There is no grand public repository for Oracle's SUNW packages, so Package Source would be a user drive parameter, or perhaps packages should be deployed from the module's files directory?
   

I would definitively avoid to place packages directly in the file directory, it would make them huge, and generally is not a good idea to provide large binary files directly via the puppetmaster's fileserver.

Still the problem with packages sources in Solaris is real, and somehow in the module I suppose you have to make opinionated decision on which repo source to use (or try to support more of them, but it would make things more complex, see below).

 

2. OpenCSW does not provide all of the Example42 dependencies. 
   
3. Choosing the Package Provider based on package, not globally for the module.
4.  How the SUNW root and user packages for a piece of software are managed.  I'm not sure that this isn't more of a Puppet-Users question. Linux = package, Solaris = package(s), provider, source all via parameter driven package resource?
   

I saw you had posted some questions in this regard to the Puppet-Users list a few years ago.  Do you have a recommendation on how to resolve this?...left to my own devices I'll probably choose a poor direction :)

I still have a poor Solaris experience to give a good answer.
I think the modules should be easy to use (plug and play) and reusable, giving options to allow customizations.
So I suppose you should decide to choose a good and largely used  source/provider  and make the module based on it, eventually adding options to customize and override your default choices.
So, for example adding a parameter like package_provider in each module (leaving it undef for other OS (let Puppet decide) and evaluate in the way you think is more appropriate to manage that package on Solaris (blastwave / pkgutil / pkg / sun / sunfreeware ...).

Eventually add in a separated (and overrideable) dependency class the inclusion of the classes/modules that configure correctly the chosen package repository). 

For various other options which may change according to the "solution" you choose (owners/paths/names...) there should be already most of the parameters available in a standard (42) module.

You can decide to leave to the user with a single parameter which "installation method/provider/source" to use, but this can make the module quite more complex, as the default values of various other parameters would change according to the value of that main one, and you can't place anymore the defaults in the params class, but you have to recalculate them in the main class (giving the current structure of the example42 modules).
An example of what I mean is in this module:
https://github.com/example42/puppet-graylog2
where some parameters (like the path of the configuration dir) which can't be se in params.pp but have to be calculataed in init.pp with such uglyness:

  $real_config_dir = $graylog2::config_dir ? {
    ''      => $graylog2::install ? {
      package => '/etc/graylog2/',
      default => "${graylog2::home}/config/",
    },
    default => $graylog2::config_dir,
  }

So, generally, allowing the user to choose how to install an application (or, for example, which package provider to use  in Solaris, which  may provide packages with different names/paths and so on), makes the code more complex and verbose as you need to manage many other parameters according to the value of the parameters which lets the user decide the installation method (and you need to keep the user's ability to set his own values for these params, hence all the above code for just one of them).

On a side note, you probably have already seen this post, which concentrates on pkgutil and OpenCSW, eventually trying to provide in some other ways the dependencies not provided in OpenCSW. 

A reusable module is not always the best solution, in some cases a quick and custom approach, based on your own setup and needs, can be preferred.

Obviously I can't accept PRs which are not generic enough to be reusable by others, but they can make life harder, at times.

Hope to have given some useful info.

al

[Sean Alderman]

Al,

  Did you leave out a link below in regard to "this post"  ?  I'd like to review it, but I'm not sure what you're referring to.

On Thursday, August 8, 2013 3:58:07 PM UTC-4, Alessandro Franceschi wrote:

<snip>

On a side note, you probably have already seen this post, which concentrates on pkgutil and OpenCSW, eventually trying to provide in some other ways the dependencies not provided in OpenCSW. 

<snip>

[Alessandro Franceschi]

I retry:
http://www.andybotting.com/using-pkgutil-on-solaris-with-puppet-for-easy-package-management
or search puppet solaris pkgutil 
for andybotting.com