Manage Solaris with Spacewalk und 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.


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 SupportThis change needs the application to be restarted – after the restart the server components required to manage Solaris systems are ready.

# rhn-satellite restart
# 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.


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: 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:

# pkginfo|egrep -i "zlib|openssl|gccruntime"
system      SUNWgccruntime          GCC Runtime libraries
system      SUNWopensslr            OpenSSL Libraries (Root)
system      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:

# 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:

# gzip -d rhn-solaris-bootstrap*.tar.gz
# tar xf rhn-solaris-bootstrap*.tar
# cd rhn-solaris-bootstrap-*
# ls -1
# 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:

solaris11 # crle -l /lib -l /usr/lib -l /usr/local/lib -l /usr/srw/lib -l /opt/redhat/rhn/solaris/lib
solaris10 # crle -l /lib -l /usr/lib -l /usr/local/lib -l /opt/redhat/rhn/solaris/lib
oi # 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:

vi ~/.profile
export PATH
export MANPATH


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):

# 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
# cd /opt/redhat/rhn/solaris/etc/sysconfig/rhn/
# vi up2date


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:

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

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

# 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:

# mkdir -p /opt/redhat/rhn/solaris/etc/sysconfig/rhn/allowed-actions/script
# 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:

# rhn-actions-control --enable-deploy

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

# mkdir -p /opt/redhat/rhn/solaris/etc/sysconfig/rhn/allowed-actions/configfiles
# 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:



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:

# /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

# wget -O - | python
# easy_install Manifold
# #oder:
# wget --no-check-certificate
# tar xfz Manifold-0.2.0.tar.gz ; cd Manifold-0.2.0
# python install

Now it is possible to create the manifest (inputs are bold):

# manifold rhnsd.xml

The service category (example: 'site' or '/application/database') [site]

The name of the service, which follows the service category
   (example: 'myapp') [] rhnsd

The version of the service manifest (example: '1') [1]

The human readable name of the service
   (example: 'My service.') [] Red Hat Network Daemon

Can this service run multiple instances (yes/no) [no] ?

Full path to a config file; leave blank if no config file
  required (example: '/etc/myservice.conf') [] /opt/redhat/rhn/solaris/etc/sysconfig/rhn/up2date

The full command to start the service; may contain
  '%{config_file}' to substitute the configuration file
   (example: '/usr/bin/myservice %{config_file}') [] /opt/redhat/rhn/solaris/usr/sbin/rhnsd --foreground --interval=10 -v

The full command to stop the service; may specify ':kill' to let
  SMF kill the service processes automatically
   (example: '/usr/bin/myservice_ctl stop' or ':kill' to let SMF kill
  the service processes automatically) [:kill]

Choose a process management model:
  'wait'      : long-running process that runs in the foreground (default)
  'contract'  : long-running process that daemonizes or forks itself
                (i.e. start command returns immediately)
  'transient' : short-lived process, performs an action and ends quickly

Does this service depend on the network being ready (yes/no) [yes] ?

Does this service depend on the local filesystems being ready (yes/no) [yes] ?

Should the service be enabled by default (yes/no) [no] ? yes

The user to change to when executing the
  start/stop/refresh methods (example: 'webservd') [] root

The group to change to when executing the
  start/stop/refresh methods (example: 'webservd') [] root

Manifest written to rhnsd.xml
You can validate the XML file with "svccfg validate rhnsd.xml"
And create the SMF service with "svccfg import rhnsd.xml"

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

# wget
# svccfg validate rhnsd.xml
# svccfg import rhnsd.xml

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

# svcadm enable rhnsd
# ps -ef|grep -i rhn
    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:

# wget
# gzip -d webmin-1.680.pkg.gz
# solaris2mpm --select-arch=i386 webmin-1.680.pkg
Opening archive, this may take a while
Writing WSwebmin-1.680-1_PSTAMP_Jamie_Cameron.i386-solaris.mpm
# rhnpush -v --server fqdn-spacewalk.domain.loc --username admin -c solaris-11 *.mpm
Connecting to http://fqdn-spacewalk.domain.loc/APP
Red Hat Network password:
Package WSwebmin-1.680-1_PSTAMP_Jamie_Cameron.i386-solaris.mpm Not Found on RHN Server -- Uploading
Uploading package WSwebmin-1.680-1_PSTAMP_Jamie_Cameron.i386-solaris.mpm
Using 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).



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:

# rhn_check -v
Installing packages [[['WSwebmin', '1.680', '1_PSTAMP_Jamie_Cameron', 'i386-solaris', 'solaris-11'], {}]]
Updating cache...

Computing transaction...
Fetching packages...                                                                                                                                                                                     
-> rhn://solaris-11/WSwebmin/1.680/1_PSTAMP_Jamie_Cameron/i386-solaris/WSwebmin-1.680-1_PSTAMP_Jamie_Cameron.i386-solaris.pkg                                                                 

Committing transaction...
pkgadd -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
Installing WSwebmin

Updating cache...

Package list refresh successful
Doing checkNeedUpdate
Updating cache...

Package list refresh successful

Webmin should be installed and listening on TCP port 10000:

# telnet localhost 10000
Trying ::1...
telnet: connect to address ::1: Connection refused
Connected to localhost.
Escape character is '^]'.

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

Webmin unter Solaris

Webmin unter Solaris


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. 🙂

Sharing is caring

Leave a Reply