Solaris mit Spacewalk und Red Hat Satellite verwalten

16.05.2014 · 11 min lesen · red-hat-satellite solaris spacewalk suse-manager ·

Mit Spacewalk und Red Hat Satellite lassen sich neben Linux-Systemen auch Oracle Solaris-Hosts verwalten - ein kleines, aber feines Detail, das oft vergessen wird. (Update: seit Spacewalk 2.2 vom 16.07.2014 ist diese Funktion "deprecated" und wird vermutlich in einer der zukünftigen Versionen entfallen)

Größere Firmen, die aufgrund Langzeit-Roadmaps oder politischer Gründe noch auf proprietäre Unices angewiesen sind, dürften sich insbesondere bei Migrationen hierfür interessieren. Red Hat hat sich die Erleichterung von Migrationen mithilfe dieser Schnittstelle auf die Fahne geschrieben. Ursprünglich scheint es geplant gewesen zu sein, auch andere proprietäre Unices, wie z. B. IBM AIX oder HP-UX zu unterstützen - zumindest vermute ich das, weil in der Red Hat Satellite-Dokumentation meistens von einem allgemeinen und keinem bestimmten "Unix" die Rede ist. Aufgrund mangelndem Interesse scheinen diese Pläne wohl nicht weiterverfolgt worden zu sein - aber das ist nur meine persönliche (und unbegründete) Vermutung.

Management-Funktionen

Doch inwiefern lassen sich SUN / Oracle Solaris Systeme überhaupt mit Spacewalk oder Red Hat Satellite verwalten?

Prinzipiell verhält sich ein Solaris-System unter Spacewalk und Red Hat Satellite genau so wie ein Linux-System - es wird ebenso in die System(gruppen)-Liste integriert und verfügt über einen Software-Basiskanal und optional auch mehrere Unterkanäle. Entgegen Enterprise Linux-, Fedora- und SUSE-Kanälen können Software-Pakete jedoch nicht direkt importiert bzw. synchronisiert werden - hier muss ein "Push" von einem Solaris-System erfolgen. Damit heruntergeladene Solaris-Softwarepakete (*.pkg) importiert werden können, müssen diese erst in MPM-Archive (*.mpm) konvertiert werden. Diese Archive enthalten neben dem eigentlichen Software-Paket noch Informationen, wie z. B. eine Beschreibung.

Bei herkömmlichen Linux-Systemen können Kommandos in nahezuer Echtzeit an das System übertragen. Hierfür wird ein Server/Client-Programm namens OSAD (Open Source Architecture Daemon) verwendet, zur Kommunikation dient das XMPP-Protokoll (Jabber). Diese Option besteht unter Solaris nicht, hier muss der rhnsd (Red Hat Network daemon) eingesetzt werden, welcher dann in periodischen Abständen nach ausstehenden Aufgaben fragt. Nicht schön, aber funktioniert.

Remote-Kommandos lassen sich, wie gewohnt ausführen. Hierzu müssen jedoch, wie auch bei Linux-Systemen, die entsprechenden Rechte vergeben werden.

Weitere Einschränkungen sind:

Remote-Kommandos funktionieren nicht immer (abhängig von Architektur und Release)
Hardware-Informationen können nicht bezogen werden (Fehlermeldung: "Invalid function call attempted")
Beim Auflisten installierter Software-Pakete werden oft falsche Architekturen angezeigt (SPARC anstatt i386)

Offiziell werden Solaris 8 bis 10 (für SPARC und x86) unterstützt - ich konnte jedoch auch Solaris 11 und OpenIndiana erfolgreich verwalten. Theoretisch sollten sich demnach auch die freien SunOS-Ableger OpenSolaris und alle auf Illumos basierenden Derivate (OpenIndiana, napp-it, SmartOS, etc.) funktionieren, da sie ebenfalls zumindest entfernt auf dem Code von Solaris 11 aufbauen.

Vorbereitung

Damit Spacewalk bzw. Red Hat Satellite überhaupt mit dem proprietären Unix umgehen kann, muss eine Einstellung im Backend vorgenommen werden. Unterhalb der Menüpunkte Admin > Spacewalk/Satellite Konfiguration > Allgemein befindet sich ein Haken "Solaris Support", der aktiviert werden muss:

Diese Änderung zieht einen Neustart der Applikation nach sich, erst dann steht der Verwaltung von Solaris serverseitig nichts mehr im Wege.

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

Damit das Solaris-System nachher komfortabel registriert werden kann, empfiehlt sich die Erstellung eines dedizierten Aktivierungsschlüssels. Idealerweise verknüpft man diesen Schlüssel auch gleich mit einem Software-Kanal für Solaris, der ebenfalls noch erstellt werden muss.

Zunächst wird der Kanal angelegt, das erfolgt über die Weboberfläche unter der Rubrik "Channels > Software-Channels verwalten > Neuen Channel erstellen". Im daraufhin folgenden Dialoge werden die folgenden Einstellungen vorgenommen:

Channel-Name: z. B. Solaris 11
Channel-Label: z. B. solaris-11
Parent-Channel: keine
Architektur: i386 Solaris oder Sparc Solaris
Channel-Zusammenfassung: z. B. "Solaris 11-Pakete"

Anschließend wird unterhalb "Systeme > Aktivierungs-Schlüssel > Neuen Schlüssel erstellen" ein Aktivierungsschlüssel mit den folgenden Einstellungen erstellt:

Beschreibung: z. B. Solaris11-Key
Basis-Channels: z. B. Solaris 11

Der generierte Aktivierungsschlüssel wird später zur Registrierung verwendet.

Installation

Zur Verwaltung werden auf dem Client-System einige Python-Tools benötigt, die für Spacewalk auf der offiziellen Webseite zu finden sind: http://spacewalk.redhat.com/solaris. Anwender des kommerziellen Satellite Servers finden diese Pakete direkt auf dem eigenen System: http://fqdn-satellite.domain.loc/pub/bootstrap.

Die Pakete sind nach Solaris-Release und Architektur gegliedert, so gibt es Pakete für Solaris 8 bis 10, jeweils SPARC und x86. Für Solaris 11 gibt es keinen offiziellen Tarball, in einem Versuch habe ich erfolgreich den Solaris 10-Tarball verwendet.

Vorab muss jedoch sichergestellt werden, dass die Solaris OpenSSL- und ZIP-Bibliotheken und das GCC-Runtime installiert werden:

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

Auf OpenIndiana-Systemen lautet das Paket für das GCC-Runtime gcc-libstdc und kann einfach per pkg-Frontend nachinstalliert werden:

1# pkg install gcc-libstdc

Diese Pakete befinden sich i.d.R. auf den offiziellen Installationsmedien oder - für ältere Releases - auf OpenCSW.

Den Tarball kopiert man idealerweise per scp oder tftp (falls kein SSH zur Verfügung steht) auf das System und entpackt ihn, damit anschließend die Pakete installiert werden können:

 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

Anschließend müssen die Pfade für LD Shared libraries angepasst werden, dieser Schritt unterscheidet sich zwischen Solaris 10, 11 und 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

Hier werden einfach die schon bekannten Pfade um einen neuen Pfad (/opt/redhat/rhn/solaris/lib) erweitert - hier befinden sich crypto-, ssl- und python-Bibliotheken.

Anschließend muss das Benutzerprofil (~/.profile) angepasst werden, damit die neu hinzugekommenen RHN-Kommandos auch zur Verfügung stehen:

 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

Danach erfolgt, wie auch bei Linux-Systemen, die Anpassung der up2date-Konfiguration. Im Wesentlichen muss hier die URL des Spacewalk- bzw. Satellite-Systems und der Pfad zum SSL-Zertifikat angegeben werden. Das SSL-Zertifikat befindet sich im pub-Ordner des Management-Systems und muss noch mittels wget oder eben tftp (falls wget und SSH nicht zur Verfügung stehen) übertragen werden:

 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

Anschließend kann das System registriert werden. Das Kommando rhn_register steht übrigens unter Solaris nicht zur Verfügung, weswegen das System unter Verwendung des vorab erstellten Aktivierungsschlüssels registriert werden muss:

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

Um die Ausführung von Remote-Befehlen zu ermöglichen, müssen noch bestimmte Rechte vergeben werden - zur Vergabe dieser wird das folgende Kommando verwendet:

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

Bei älteren Solaris-Versionen steht das Kommando rhn-actions-control ggf. nicht zur Verfügung - hier müssen die folgenden Kommandos abgesetzt werden:

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

Sollen auch Konfigurationsdateien auf das System kopiert werden können, müssen auch hierfür noch Befugnisse vergeben werden:

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

Auf älteren Solaris-Versionen helfen im Fehlerfall die folgenden Kommandos:

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

Anschließend taucht der Host in der Systemliste auf und wartet auf Verwaltungsaufgaben:

Servicesteuerung mit SMF

Damit der Host nun auch per Spacewalk bzw. Red Hat Satellite ferngesteuert werden kann, muss rhnsd (Red Hat Network Daemon) aktiv sein.Das lässt sich durch Absetzen des folgenden Kommandos bewerkstelligen:

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

Der Parameter --interval ist hier besonders wichtig, er gibt an, in welchen Zeitabständen (in Minuten) der Daemon nach anstehenden Aufgaben (z. B. Paket-Installation oder Remote-Befehl) gesucht wird. Ich habe das in diesem Beispiel zu Testzwecken auf 10 (= 10 Minuten) gesetzt, je nach Systemlandschaft sollte man diesen Wert jedoch anpassen.

Besonders schön ist diese Lösung jedoch nicht, da man den Dienst nach jedem Neustart manuell starten muss - schöner wäre ein automatischer Start.

Gegenüber anderen Unices verwendet Solaris ab Version 10 anstatt einem konventionellem Init-System eine Technologie namens SMF (Service Management Facility). Hierdurch ergeben sich folgende Vorteile:

Parallelisierung von Startprozessen, schnellerer Boot
einfachere Definition von Abhängigkeiten zu anderen Diensten
automatischer Neustart nach eingetretenen Fehlern

SMF-Dienste werden in der Regel mithilfe von XML-Dokumenten definiert, dem sogenannten SMF Manifest. Auf der Oracle-Webseite findet sich ein Whitepaper zur Erstellung eines Manifests für den PostgreSQL-Datenbankserver. Wer zu faul ist, sich in das Thema einzulesen wird das Python-Tool manifold zu schätzen lernen. Mithilfe des kleinen Helfers lassen sich leicht und schnell SMF-Manifests durch die Verwendung eines Assistenten erstellen.

Genau dieses Tool habe ich auch verwendet, um ein SMF-Manifest zu erstellen. Das Programm benötigt noch einige zusätzlichen Python-Module, die sich dank eines Tools namens setuptools benutzerfreundlich installieren lassen. Vor der Installation von manifold wird also noch setuptools installiert (_siehe auch 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

Nun kann das Manifest wie folgt erstellt werden:

 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"

Alternativ kann mein Manifest auch von Github heruntergeladen, validiert und importiert werden:

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

Nun lässt sich der Dienst wie folgt aktivieren - rhnsd wird sofort gestartet (enable bedeutet hier nicht nur aktivieren, sondern auch starten!):

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

Der Dienst überprüft nun alle 10 Minuten, ob ausstehende Aufgaben anstehen und führt diese aus.

Pakete "pushen"

Wie bereits erwähnt, müssen Solaris-Softwarepakete mittels solaris2mpm erst in ein MPM-Paket konvertiert werden, bevor diese über Spacewalk oder Red Hat Satellite verteilt werden können.

Das folgende Beispiel zeigt einen solchen Vorgang für das Verwaltungstool Webmin (mir ist keine simplere Software mit noch gepflegter Solaris-Unterstützung eingefallen) in der Version 1.680. Das Paket wird heruntergeladen, konvertiert und auf den Management-Server hochgeladen:

 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

Beim Konvertieren des Pakets sollte immer der Schalter --select-arch verwendet werden, da ansonsten immer SPARC-Pakete (--select-arch=sparc) erstellt werden - ein solches Paket kann nicht auf der Intel-Plattform (--select-arch=i386) installiert werden.

Anschließend steht das Paket zur Verfügung und kann wie gewohnt über die Weboberfläche zur Installation freigegeben werden. Aufgrund des fehlendem OSAD-Dienstes muss man nun 10 Minuten warten - oder die Installation manuell über rhn_check starten:

 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 sollte nun installiert sein und auf TCP-Port 10000 lauschen:

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

Ein Blick in den Webbrowser sollte daraufhin auch Webmin anzeigen:

Fazit

Mit Spacewalk und Red Hat Satellite lassen sich zahlreiche Solaris-Derivate komfortabel auf die gleiche Art und Weise wie Linux-Systeme verwalten. Insbesondere in gemischten Systemlandschaften kann das den Wartungsaufwand drastisch verringern. Pakete und Konfigurationsdateien lassen sich zentral verwalten und zeitsparend verteilen. Trotz einiger kleiner technischer Einschränkungen (siehe oben) lassen sich größere Anzahlen von Solaris-Systemen effizient verwalten.

Wer also zahlreiche Solaris- und Linux-Systeme verwaltet und den Verwaltungsaufwand minimieren möchte, sollte sich den Solaris-Support von Spacewalk und Red Hat Satellite genauer anschauen. 🙂