Manage Solaris with Spacewalk and Red Hat Satellite

Beside Linux systems also Oracle Solaris hosts can be managed using Spacewalk and Red Hat Satellite - a cool feature that is often forgotten. (Update: since Spacewalk 2.2 from 07/16/2014 this function is "deprecated" which means that it might be removed in one of the following releases)

Bigger companies which are reliant on proprietary Unices due to roadmaps or political reasons might be interested in this force migration purposes. Red Hat takes up the cause of facilitate migrations using this interface. It seems like it was planned to also support other proprietary Unices like IBM AIX or HP-UX - I suppose that because the Red Hat Satellite documentation always mentions an generic "Unix" and not a particular one. Maybe the support was dropped due to the lack of interest - but that's only my personal (and arbitrary) assumption.

Management functions

But - how can SUN / Oracle Solaris systems be managed at all using Spacewalk or Red Hat Satellite?

Basically a Solaris systems acts like a Linux host under Spacewalk and Red Hat Satellite - it is also integrated into system(group) and has a software base channel and optionally also sub-channels available. Unlike Enterprise Linux, Fedora or SUSE channels packages cannot be directly imported or synchronized - a "push" from a Solaris system is necessary. It also necessary to convert downloaded Solaris packages (*.pkg) to MPM archives (*.mpm) before importing them. Amongst others these archives are consisting of the actual software package and additional information like a description.

On conventional Linux systems commands are submitted in almost real-time. For this a server/client software called OSAD (Open Source Architecture Daemon) is used in combination with the XMPP protocol (Jabber). This option is not available on Solaris - it is necessary to use rhnsd (Red Hat Network daemon) which checks in periodic intervals for scheduled tasks. That's not a beautiful solution - but it works.

Remote commands can also be executed as usual. For this additional permissions needs to be assigned like on Linux systems.

Additional limitations are:

  • Remote commands are not always working as expected (depending on architecture and release)
  • Hardware information cannot be obtained (error message: "Invalid function call attempted")
  • Incorrect architectures are displayed while listing installed software packages (SPARC instead of i386)

Official Solaris 8 to 10 (for SPARC and x86) are supported - but I was able to also manage Solaris 11 and OpenIndiana. It should also be possible to also manage the free SunOS distribution OpenSolaris and all derivates that are based on Illumos (OpenIndiana, napp-it, SmartOS, etc.) because they are farther based on the code of Solaris 11.

Preparation

A setting in the backend needs to be done so that Spacewalk or Red Hat Satellite is able to deal with the proprietary Unix. There is a checkbox "Solaris Support" which needs to be selected - you will it beneath Admin > Spacewalk/Satellite Konfiguration > General in the menu:

Solaris Support

This change needs the application to be restarted - after the restart the server components required to manage Solaris systems are ready.

1# rhn-satellite restart
2# spacewalk-service restart

It is a good idea to create a dedicated activation key to make sure that the system can be registered comfortably. A even better idea is to link this key afterwards to a software channel which also needs to be created.

First the channel is created. This is done using the web interface - just navigate to "Channels > Manage Software Channels > create new channel". Enter the following information in the following form:

  • Channel Name: e.g. Solaris 11
  • Channel Label: e.g. solaris-11
  • Parent Channel: None
  • Architecture: i386 Solaris or Sparc Solaris
  • Channel Summary: e.g. "Solaris 11 packages"

Afterwards the activation key is created underneath "Systems > Activation Keys > create new key" using the following settings:

  • Description: e.g. Solaris11-Key
  • Base Channels: e.g. Solaris 11

The generated activation key is used for registrating systems afterwards.

Installation

For management you will need to install some Python tools on the client system - you can find those tools for Spacewalk on the official website: http://spacewalk.redhat.com/solaris. Users of the commercial Satellite Server can retrieve these packages directly from their own system: http://fqdn-satellite.domain.loc/pub/bootstrap.

The packages are divided depending on the Solaris release and architecture - there are packages for Solaris 8 to 10 for SPARC and x86. There is no official tarball for Solaris 11 but I was able to successfully install the Solaris 10 tarball.

Before you start you need to make sure that the Solaris OpenSSL and ZIP libraries and the GCC runtime is installed:

1# pkginfo|egrep -i "zlib|openssl|gccruntime"
2system      SUNWgccruntime          GCC Runtime libraries
3system      SUNWopensslr            OpenSSL Libraries (Root)
4system      SUNWzlib                The Zip compression library

On OpenIndiana systems the GCC runtime package is named gcc-libstdc and can easily be installed using the pkg frontend:

1# pkg install gcc-libstdc

These packages are normally on the official installation media or - for older releases - on OpenCSW.

The tarball is copied using SCP or TFTP (if SSH is not available) to the system and extracted before contained packages are installed:

 1# gzip -d rhn-solaris-bootstrap*.tar.gz
 2# tar xf rhn-solaris-bootstrap*.tar
 3# cd rhn-solaris-bootstrap-*
 4# ls -1
 5README
 6RHATossl-0.9.7a-33.26.rhn.9.sol9.i386.pkg
 7RHATpossl-0.6-1.p24.6.i386.pkg
 8RHATpythn-2.4.1-4.rhn.6.sol10.pkg
 9RHATrcfg-5.1.0-3.pkg
10RHATrcfga-5.1.0-3.pkg
11RHATrcfgc-5.1.0-3.pkg
12RHATrcfgm-5.1.0-3.pkg
13RHATrhnc-5.3.0-21.pkg
14RHATrhnl-1.8-7.p23.pkg
15RHATrpush-5.3.1-5.pkg
16RHATsmart-5.4.1-2.i386.pkg
17SMClibgcc-3.4.1-sol9-intel.pkg
18# for i in *.pkg ; do pkgadd -d $i all; done

Afterwards it is necessary to alter paths for LD shared libraries - this step differs on Solaris 10, 11 and OpenIndiana:

1solaris11 # crle -l /lib -l /usr/lib -l /usr/local/lib -l /usr/srw/lib -l /opt/redhat/rhn/solaris/lib
2solaris10 # crle -l /lib -l /usr/lib -l /usr/local/lib -l /opt/redhat/rhn/solaris/lib
3oi # crle -l /lib -l /usr/lib -l /opt/redhat/rhn/solaris/lib

Already known paths are expanded by a new path (/opt/redhat/rhn/solaris/lib) which contains the crypto, ssl and python libraries.

After that you need to alter your user profile (~/.profile) so that the recently added RHN command are available:

 1$ vi ~/.profile
 2...
 3PATH=$PATH:/opt/redhat/rhn/solaris/bin
 4PATH=$PATH:/opt/redhat/rhn/solaris/usr/bin
 5PATH=$PATH:/opt/redhat/rhn/solaris/usr/sbin
 6MANPATH=$MANPATH:/opt/redhat/rhn/solaris/man
 7export PATH
 8export MANPATH
 9
10ESC ZZ

The next step is to customizing the up2date configuration like on Linux systems. Primarily the Spacewalk / Satellite URL and the SSL certificate path needs to be customized. You can download the SSL certificate from the pub folder of the management system to the client system using wget or tftp (if wget and SSH are not available):

 1# wget --no-check-certificate https://fqdn-satellite.domain.loc/pub/RHN-ORG-TRUSTED-SSL-CERT -O /opt/redhat/rhn/solaris/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
 2# cd /opt/redhat/rhn/solaris/etc/sysconfig/rhn/
 3# vi up2date
 4...
 5noSSLServerURL=http://fqdn-satellite.domain.loc/XMLRPC
 6...
 7serverURL=https://fqdn-satellite.domain.loc/XMLRPC
 8...
 9sslCACert=/opt/redhat/rhn/solaris/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
10
11ESC ZZ

After that the system can be registered. Because the rhn_register command is not available on Solaris you will need to register a system using the previously created activation key:

1# rhnreg_ks --activationkey=x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2 Doing checkNeedUpdate
3 Updating cache...               ######################################## [100%]
4 Updating cache...               ######################################## [100%]
5 Package list refresh successful

To make sure that executing remote commands is possible you need to grant additional rights - using the following command:

1# rhn-actions-control --enable-run

On older Solaris versions the command rhn-actions-control might not be available - in this case the following commands will do the same:

1# mkdir -p /opt/redhat/rhn/solaris/etc/sysconfig/rhn/allowed-actions/script
2# touch /opt/redhat/rhn/solaris/etc/sysconfig/rhn/allowed-actions/script/run

If you're also planning to deploy configuration files to the system you'll need to grant even more rights:

1# rhn-actions-control --enable-deploy

On older Solaris versions you might need to run the following commands:

1# mkdir -p /opt/redhat/rhn/solaris/etc/sysconfig/rhn/allowed-actions/configfiles
2# touch /opt/redhat/rhn/solaris/etc/sysconfig/rhn/allowed-actions/configfiles/all

Afterwards the host is added to the system list and waits for management tasks:

Solaris-Systeme

Service controlling using SMF

To make sure that the host can be controlled using Spacewalk or Red Hat Satellite rhnsd (Red Hat Network Daemon) needs to be running. You can ensure this by typing the following command:

1# /opt/redhat/rhn/solaris/usr/sbin/rhnsd --foreground --interval=10 -v

The parameter --interval is very important in this case - it defines the time interval (in minutes) in which the daemon is checking for pending tasks (e.g. package installation or remote command). I set this value in this case for testing purposes to 10 (= 10 minutes). Depending on your system landscape you might want to change this value.

This solution is not good because you will have to restart the application after every reboot manually - an automatic start would be much more comfortable.

Unlike other Unices Solaris starting from version 10 uses a technology called SMF (Service Management Facility) instead of an conventional Init system. The advantages are:

  • parallel starting of processes, faster boot
  • easier definition of dependencies to other services
  • automatic restart after errors

SMF services are defined using XML documents - the so-called SMF manifest. You can find a whitepaper about creating a manifest for the PostgreSQL database server on the Oracle website. If you're too lazy to read the documentation you might fell in love with the Python tool manifold. Using this tiny helper you can easily create SMF manifests using an assistant.

I used this tool to create SMF manifest. The tool needs some additional Python modules that can be installed easily by using a tool called setuptools. So before installing manifold you should install setuptools (_see also https://pypi.python.org/pypi/setuptools#unix-wget_):

1# wget https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py -O - | python
2# easy_install Manifold
3# #oder:
4# wget --no-check-certificate https://pypi.python.org/packages/source/M/Manifold/Manifold-0.2.0.tar.gz
5# tar xfz Manifold-0.2.0.tar.gz ; cd Manifold-0.2.0
6# python setup.py install

Now it is possible to create the manifest:

 1# manifold rhnsd.xml
 2
 3The service category (example: 'site' or '/application/database') [site]
 4
 5The name of the service, which follows the service category
 6   (example: 'myapp') [] rhnsd
 7
 8The version of the service manifest (example: '1') [1]
 9
10The human readable name of the service
11   (example: 'My service.') [] Red Hat Network Daemon
12
13Can this service run multiple instances (yes/no) [no] ?
14
15Full path to a config file; leave blank if no config file
16  required (example: '/etc/myservice.conf') [] /opt/redhat/rhn/solaris/etc/sysconfig/rhn/up2date
17
18The full command to start the service; may contain
19  '%{config_file}' to substitute the configuration file
20   (example: '/usr/bin/myservice %{config_file}') [] /opt/redhat/rhn/solaris/usr/sbin/rhnsd --foreground --interval=10 -v
21
22The full command to stop the service; may specify ':kill' to let
23  SMF kill the service processes automatically
24   (example: '/usr/bin/myservice_ctl stop' or ':kill' to let SMF kill
25  the service processes automatically) [:kill]
26
27Choose a process management model:
28  'wait'      : long-running process that runs in the foreground (default)
29  'contract'  : long-running process that daemonizes or forks itself
30                (i.e. start command returns immediately)
31  'transient' : short-lived process, performs an action and ends quickly
32   [wait]
33
34Does this service depend on the network being ready (yes/no) [yes] ?
35
36Does this service depend on the local filesystems being ready (yes/no) [yes] ?
37
38Should the service be enabled by default (yes/no) [no] ? yes
39
40The user to change to when executing the
41  start/stop/refresh methods (example: 'webservd') [] root
42
43The group to change to when executing the
44  start/stop/refresh methods (example: 'webservd') [] root
45
46Manifest written to rhnsd.xml
47You can validate the XML file with "svccfg validate rhnsd.xml"
48And create the SMF service with "svccfg import rhnsd.xml"

You can also download my manifest on Github and validate and import it:

1# wget https://raw.githubusercontent.com/stdevel/rhnsd-solman/master/rhnsd.xml
2# svccfg validate rhnsd.xml
3# svccfg import rhnsd.xml

Now the service can be activated - rhnsd is executed instantly (enable means activating and starting!):

1# svcadm enable rhnsd
2# ps -ef|grep -i rhn
3    root  6306    11   0 17:19:32 ?           0:00 /opt/redhat/rhn/solaris/usr/sbin/rhnsd --foreground --interval=10 -v

The service now is now searching for pending tasks every 10 minutes and executes them.

"Pushing" packages

Like mentioned above Solaris software packages need to be converted into MPM packages using solaris2mpm before they can be distributed using Spacewalk or Red Hat Satellite.

The following example demonstrates this task for the web-based management tool Webmin (I found no other simple software that has a still active Solaris support) in Version 1.680. The package is downloaded, converted and uploaded to the management server:

 1# wget http://prdownloads.sourceforge.net/webadmin/webmin-1.680.pkg.gz
 2# gzip -d webmin-1.680.pkg.gz
 3# solaris2mpm --select-arch=i386 webmin-1.680.pkg
 4Opening archive, this may take a while
 5Writing WSwebmin-1.680-1_PSTAMP_Jamie_Cameron.i386-solaris.mpm
 6# rhnpush -v --server fqdn-spacewalk.domain.loc --username admin -c solaris-11 *.mpm
 7Connecting to http://fqdn-spacewalk.domain.loc/APP
 8Red Hat Network password:
 9Package WSwebmin-1.680-1_PSTAMP_Jamie_Cameron.i386-solaris.mpm Not Found on RHN Server -- Uploading
10Uploading package WSwebmin-1.680-1_PSTAMP_Jamie_Cameron.i386-solaris.mpm
11Using POST request

You might want to use the parameter --select-arch because otherwise SPARC packages (--select-arch=sparc) are created always -  such a package cannot be installed on the Intel platform (--select-arch=i386).

Solaris-Pakete

Afterwards the package is ready an can be installed using the web interface. Because of the lack of the OSAD service you need to wait 10 minutes - or start the installation manually by running rhn_check:

 1# rhn_check -v
 2Installing packages [[['WSwebmin', '1.680', '1_PSTAMP_Jamie_Cameron', 'i386-solaris', 'solaris-11'], {}]]
 3Updating cache...
 4
 5Computing transaction...
 6Fetching packages...
 7-> rhn://solaris-11/WSwebmin/1.680/1_PSTAMP_Jamie_Cameron/i386-solaris/WSwebmin-1.680-1_PSTAMP_Jamie_Cameron.i386-solaris.pkg
 8WSwebmin-1.680-1_PSTAMP_Jamie_Cameron.i386-solaris.pkg
 9
10Committing transaction...
11pkgadd -a /opt/redhat/rhn/solaris/var/lib/smart/adminfile -n -d /opt/redhat/rhn/solaris/var/lib/smart/packages/WSwebmin-1.680-1_PSTAMP_Jamie_Cameron.i386-solaris.pkg WSwebmin
12Installing WSwebmin
13
14Updating cache...
15
16Package list refresh successful
17Doing checkNeedUpdate
18Updating cache...
19
20Package list refresh successful

Webmin should be installed and listening on TCP port 10000:

1# telnet localhost 10000
2Trying ::1...
3telnet: connect to address ::1: Connection refused
4Trying 127.0.0.1...
5Connected to localhost.
6Escape character is '^]'.

Having a look at the web browser should also show Webmin:

Webmin unter Solaris

Conclusion

It is possible to comfortably manage several Solaris derivates in the same way like Linux hosts using Spacewalk and Red Hat Satellite. Especially in mixed environments this can help you to reduce the maintenance effort. Packages and configuration files can be managed centrally and deployed time-saving. Even though there are some minor technical limitations (see above) it is possible to manage bigger amounts of Solaris hosts efficiently.

So if you have to manage plenty of Solaris and Linux systems and wan't to reduce the maintenance effort you might want to have a deeper look at the Solaris support of Spacewalk and Red Hat Satellite. 🙂

Translations: