Modules for Solaris

[Al @ Lab42]

I'm considering the opportunity of adding (basic) Solaris support to my modules ( www.example42.com) but before starting I'd like to gather some info about best practices and standards.
I've to admit that I've not a great working Solaris experience, so I actually don't know how people use it, what versions are more used and so on.

So let's begin with few points:

- What version?
I'm tempted to begin only with Solaris 10, in order to avoid too many complications. Question is... does this makes sense? What versions of Solaris are currently most used? Since I believe that the best approach to puppettization is to replicate on new machines the current envrionments  without installing Puppet on existing production servers, does make sense the assumption that people would generally upgrade their older boxes to brand new Solaris 10 setups?
I know that mileage may vary, but whatever better informed opinion is welcomed.

- What packages?
This might become a nightmare... there are different packages repositories, blastwave, openCSW, Sunfreeware... , to make modules that manage the same software from different sources might be a troublesome and I would like to stick to one. Does this makes sense? What's the most used / updated /large package repository out there? Do you use any of these on production environments?

- What package manager?
Can I assume that (almost) everybody uses (in 2011) pkgutil to install software on Solaris? If not, what are the alternatives?

- Existing modules for Solaris?
Has anyone published Puppet modules for Solaris? Can you link them here, for reference and inspiration...

There questions might appear particularly naive to a more experienced Solaris sysadmin but I have to start from some basic points and as usual, "better ask to the experts"...

Thanks for any feedback you might want to leave on these questions and to whatever advice you might give about Puppet on Solaris.

If someone if interested is collaborating on this effort, just contact me....

All the best
Al

[deet]

On Jul 20, 12:06 am, "Al @ Lab42" <lab42...@gmail.com> wrote:
> I'm considering the opportunity of adding (basic) Solaris support to my

Cool. Certainly that will make it easier on Solaris admins new to
puppet.

>
> So let's begin with few points:
>
> - What version?
> I'm tempted to begin only with Solaris 10,

I think initial Solaris 10 support would be the most valuable.
Keep in mind Solaris 11 is going to ship in a few months and I
personally think 10 and 11 will co-exist for years to come.
Additionally what ever you put together for Solaris 10 support would
mostly work on Solaris 9 as well.

>
> - What packages?
> This might become a nightmare...

Solaris admins are used to this nightmare:) We build and version our
own packages with the occasional dip into Steve's Sunfreeware package
repo.

>
> - What package manager?

We use vanilla Solaris package which is wrapped in a define to give us
package version control. Solaris 11 will come with the new IPS
packaging system so that will be another alternative. I could
imagine using IPS and the traditional pkgadd/pkgrm toolset on the same
host to even complicate things more.

> If someone if interested is collaborating on this effort, just contact
> me....

We'd be happy to give you what we have but they are not in
publishable format because of the lacking documentation.
Good luck!
Derek.
>
> All the best
> Al

[Aaron Grewell]

I'm just finishing up adding initial Solaris support to my existing Linux-oriented module set.  I do think a set of modules covering the basics would be helpful.  As a Linux admin learning Solaris trying to understand both the Puppet differences and the OS differences made startup harder.

Solaris Version:
10 64-bit only, both i386 and Sparc

Packages:
Custom packages using pkgadd, Solaris OS packages using pkgutil, OpenCSW using pkgutil.  Most of my difficulties have been around package management, so as far as I'm concerned Solaris 11 and IPS can't happen soon enough.

Module Organization:
The advice I've followed (which seems to have worked well so far) was to move the contents of existing 'myclass' to 'myclass::linux' and add the Solaris functionality as 'myclass::sunos'.  Class 'myclass' becomes a wrapper class which does an 'include myclass::$kernel'.  You may want to use 'myclass::solaris', 'myclass::redhat', etc with $operatingsystem instead but since my Linuxes are all RH-like $kernel is convenient. 

I've created a few defines designed to be shared between Linux and Solaris but since pathing is different for most things and behavior is often different between GNU and Solaris utils it's a pain.  Most of the time splitting at the OS level seems to work better.

Currently doing:
NFS
AutoFS
Swap
Banners
DNS client
NTP
Packages
Sendmail
SSH
Sudo
Syslog
Users
VMware Tools

Future plans:
I'm expecting to have to do Update Release detection since it sometimes brings significant functionality differences.  I haven't gotten into some of the fancier things that are going to require this info yet but there's nothing built into facter (as of 1.5.8) so that'll be fun.

Patching via Patch Check Advanced ( http://www.par.univie.ac.at/solaris/pca/ )

ZFS management (should be pretty easy)

Zone management (less easy)

Network interface mangement (including standalone adapters, IPMP, and link aggregation)

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/yi-nY02p06AJ.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[deet]

> so as far as I'm concerned Solaris 11 and IPS can't happen soon enough.

Keep in mind you can do IPS in Solaris 10 now if you want. You'll
need to install the software and migrate your packages from SYS V
format to IPS which I believe the toolkit provides a script for.
http://wikis.sun.com/display/IpsBestPractices/Downloads



> Future plans:

We've been down the road of your future plans and would be happy to
send you our work. No guarantee they are up to your standards but
happy to share.

> I'm expecting to have to do Update Release detection since it sometimes
> brings significant functionality differences.  I haven't gotten into some of
> the fancier things that are going to require this info yet but there's
> nothing built into facter (as of 1.5.8) so that'll be fun.
>
> Patching via Patch Check Advanced (http://www.par.univie.ac.at/solaris/pca/)
>
> ZFS management (should be pretty easy)
>
> Zone management (less easy)
>
> Network interface mangement (including standalone adapters, IPMP, and link
> aggregation)
>

> On Wed, Jul 20, 2011 at 12:06 AM, Al @ Lab42 <lab42...@gmail.com> wrote:
>
>
>
>
>
>
>
> > I'm considering the opportunity of adding (basic) Solaris support to my

> > modules (www.example42.com) but before starting I'd like to gather some

[Aaron Grewell]

Interesting.  I will definitely take a look at that IPS link, that could make life a lot easier.  I'd love to see what you've done, I'm sure it would help me along as I work to smooth out our Solaris processes.

[Al @ Lab42]

Thank you for the valuable infos, I agree that differences are enough to require a dedicated solaris subclass, to keep changes isolated and don't fiddle with existing classes linux oriented.
The approach:

"Custom packages using pkgadd, Solaris OS packages using pkgutil, OpenCSW using pkgutil."

seems sane to me and flexible enough to manage exotic packages.

Are your modules, Aareon, published somewhere?
I've learnt a lot about Solaris (and its madness :-) just seeing Deet's ones...

Ciao
al

[Al @ Lab42]

On Wednesday, July 20, 2011 5:24:05 PM UTC+2, deet wrote:

On Jul 20, 12:06 am, "Al @ Lab42" <lab4...@gmail.com> wrote:
> I'm considering the opportunity of adding (basic) Solaris support to my

  Cool.  Certainly that will make it easier on Solaris admins new to
puppet.

Hope so. My intention is at least to setup basic system configuration and adding applications management when needed.
 

>
> So let's begin with few points:
>
> - What version?
> I'm tempted to begin only with Solaris 10,

  I think initial Solaris 10 support would be the most valuable.
Keep in mind Solaris 11 is going to ship in a few months and I
personally think 10 and 11 will co-exist for years to come.
Additionally what ever you put together for Solaris 10 support would
mostly work on Solaris 9 as well.

>
> - What packages?
> This might become a nightmare...

Solaris admins are used to this nightmare:)  We build and version our
own packages with the occasional dip into Steve's Sunfreeware package
repo.

>
> - What package manager?

We use vanilla Solaris package which is wrapped in a define to give us
package version control.   Solaris 11 will come with the new IPS
packaging system so that will be another alternative.   I could
imagine using IPS and the traditional pkgadd/pkgrm toolset on the same
host to even complicate things more.



> If someone if interested is collaborating on this effort, just contact
> me....

  We'd be happy to give you what we have but they are not in
publishable format because of the lacking documentation.

Really thanks, for the notes and the modules.
They have been and will be really useful (IMHO you should publish them anyway, whatever the documentation... :-)
 

[John Lyman]

I would be especially interested if anyone has a good way to manage /
etc/system. I am currently using the concat module, but it's not the
best method. I know the "puppet way" would be to use augeas, but I
haven't had any luck compiling it with sun studio and don't want to go
the gcc route for various reasons.

I would also be interested in looking at the pca module. Currently I
have some custom defines for managing patches, but I only feel
comfortable using it for certain patches (i.e. ones that don't require
single-user mode).

I have quite a few solaris-based modules, but I am afraid they are too
site-specific to publish. I do have some custom facts that are
probably generic enough that some people might find useful. zpools,
zpool properties, metadevice rootdev (for /etc/system setting),
solaris release (e.g. returns s10x_u4wos_12b), etc.

As far as packaging, we use a mix of solaris, sunfreeware and pkgsrc.
We are looking to move away from sunfreeware towards 100% pkgsrc. I
modified the default puppet pkgsrc provider to work with solaris/
netbsd and added the ability to update packages. It can be a pain to
compile the binaries for pkgsrc, but once that is done it is a breeze
to manage them. ... and it has the advantage of working on redhat
and other platforms.

[windowsrefund]

>
> - What packages?
> This might become a nightmare... there are different packages repositories,
> blastwave, openCSW, Sunfreeware... , to make modules that manage the same
> software from different sources might be a troublesome and I would like to
> stick to one. Does this makes sense? What's the most used / updated /large
> package repository out there? Do you use any of these on production
> environments?
>

opencsw is the best and Puppet supports it with a native provider.
Trying to use pkgutil would be tricky as there is no native provider
AFAIK. I know someone out there posted something to the list at some
point but that's another story.

> - What package manager?
> Can I assume that (almost) everybody uses (in 2011) pkgutil to install
> software on Solaris? If not, what are the alternatives?
>

Again, puppet already provides a blastwave provider that works
perfectly with opencsw

> - Existing modules for Solaris?
> Has anyone published Puppet modules for Solaris? Can you link them here, for
> reference and inspiration...
>

There really aren't too many things one needs to be concerned about
when adding "solaris" support to a module. The only things that stand
out are file paths and little quirks like needing to unlock a user's
account after creation using passwd -N. Of course, service resources
may want to use the manifest attribute if SMF is to be exploited.
Other than that, a service is a service, a user is a user, etc, etc...

Best,
Adam

[Aaron Grewell]

The pkgutil provider comes with the OpenCSW Puppet package on Solaris in Puppet 2.6, and is in 2.7 by default.  It works quite well.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

[windowsrefund]

On Jul 21, 2:19 pm, Aaron Grewell <aaron.grew...@gmail.com> wrote:
> The pkgutil provider comes with the OpenCSW Puppet package on Solaris in
> Puppet 2.6, and is in 2.7 by default.  It works quite well.
>

Even better. I'm not up on things because I'm fortunate enough to be
migrating my entire footprint over to Debian GNU/Linux :)

[Aaron Grewell]

One thing to note: if you're using pkgutil with Puppet make sure you set 'wgetopts=-nv' in pkgutil.conf or you'll get loads of inexplicable warnings.

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/f8F-qbjkCL0J.

[Mark]

On 21 Jul 2011, at 19:02, John Lyman wrote:

> I would be especially interested if anyone has a good way to manage /
> etc/system. I am currently using the concat module, but it's not the
> best method. I know the "puppet way" would be to use augeas, but I
> haven't had any luck compiling it with sun studio and don't want to go
> the gcc route for various reasons.

Hi John,

Check out the OpenCSW Puppet/Facter/Augeas/ruby-augeas stack.

Older versions are available straight from the opencsw.org main pages,
https://www.opencsw.org/packages/CSWaugeas/ - but I've also built
newer versions, which can be retrieved from the experimental area:

http://buildfarm.opencsw.org/experimental.html#markp

If you want to build your own rather than use the opencsw stack, you
could check out the build source in SVN:

https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/augeas/trunk/

Regards,

--Mark