Solaris mit Spacewalk und Red Hat Satellite verwalten

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:

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

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

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

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

# gzip -d rhn-solaris-bootstrap*.tar.gz
# tar xf rhn-solaris-bootstrap*.tar
# cd rhn-solaris-bootstrap-*
# ls -1
README
RHATossl-0.9.7a-33.26.rhn.9.sol9.i386.pkg
RHATpossl-0.6-1.p24.6.i386.pkg
RHATpythn-2.4.1-4.rhn.6.sol10.pkg
RHATrcfg-5.1.0-3.pkg
RHATrcfga-5.1.0-3.pkg
RHATrcfgc-5.1.0-3.pkg
RHATrcfgm-5.1.0-3.pkg
RHATrhnc-5.3.0-21.pkg
RHATrhnl-1.8-7.p23.pkg
RHATrpush-5.3.1-5.pkg
RHATsmart-5.4.1-2.i386.pkg
SMClibgcc-3.4.1-sol9-intel.pkg
# 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:

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

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:

vi ~/.profile
...
PATH=$PATH:/opt/redhat/rhn/solaris/bin
PATH=$PATH:/opt/redhat/rhn/solaris/usr/bin
PATH=$PATH:/opt/redhat/rhn/solaris/usr/sbin
MANPATH=$MANPATH:/opt/redhat/rhn/solaris/man
export PATH
export MANPATH

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

# 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
...
noSSLServerURL=http://fqdn-satellite.domain.loc/XMLRPC
...
serverURL=https://fqdn-satellite.domain.loc/XMLRPC
...
sslCACert=/opt/redhat/rhn/solaris/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT

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

# rhnreg_ks --activationkey=x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 Doing checkNeedUpdate
 Updating cache...               ######################################## [100%]
 Updating cache...               ######################################## [100%]
 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:

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

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

# rhn-actions-control --enable-deploy

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

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

Solaris-Systeme

Solaris-Systeme

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:

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

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

Nun kann das Manifest wie folgt erstellt werden (Eingaben fett markiert):

# 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
   [wait]

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"

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

# wget https://raw.githubusercontent.com/stdevel/rhnsd-solman/master/rhnsd.xml
# svccfg validate rhnsd.xml
# 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!):

# 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

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:

# wget http://prdownloads.sourceforge.net/webadmin/webmin-1.680.pkg.gz
# 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

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.

Solaris-Pakete

Solaris-Pakete

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:

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

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

Ein Blick in den Webbrowser sollte daraufhin auch Webmin anzeigen:

Webmin unter Solaris

Webmin unter Solaris

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

4 Kommentare Schreibe einen Kommentar

  1. Hallo, ein wunderbarer Beitrag.
    Genau so was suche ich eigentlich. Im Moment bin ich gerade am evaluieren ob das eine valide Lösung ist, für einen meiner Kunden. Optimal wäre zwar das Sun XVM Ops Center. Aber Oracle hat ja den Support für RHEL und CentOS für das OPS Center abgekündigt. Persönlich meine ich jedoch das seint Spacewalk 2.2 über eine Abkündigung des Solaris Supports in Spacewalk nachgedacht wird? Oder habe ich mich da verlesen?
    Interessant wäre natürlich wenn man aus dem Spacewalk raus, ganze Solaris Cluster 3.3 und Liveupgrade pushen könnte. Etwa so in der Art wie hier beschrieben.
    http://unixhaus.de/index.php?/archives/2476-Liveupgrade-Sun-Cluster-3.2-auf-3.3.html

    Noch einen schönen Sonntag. 🙂

    • Hallo BerndH!

      Vielen Dank für das Feedback – freut mich sehr, dass der Artikel gefällt. 🙂

      Du hast völlig Recht, seit Spacewalk 2.2 ist der Solaris-Support „deprecated“ – das bedeutet, das Feature wird vermutlich nicht mehr weiterentwickelt und in zukünftigen Versionen entfallen (diesen Hinweis habe ich mal im Artikel hinzugefügt). Der kommerzielle Ableger, Red Hat Satellite 5.6, wird dieses Feature zumindest bis Ende der Support-Zeit (31.März 2017 – siehe auch hier) beinhalten. Der Solaris-Support ist allerdings, wie Du ja gesehen hast, relativ rudimentär. Einige Dinge würden mir da für den produktiven Einsatz fehlen – z.B. sauber funktionierende Remote-Kommandos und Echtzeitverwaltung. Würde mich interessieren, für welche Lösung Du dich letztendlich entscheidest!

      Beste Grüße und ein schönes Rest-Wochenende,
      Christian!

  2. Hi

    I look for way to get solaris patchs automatically on spacewalk server.

    The aim is to manage our solaris servers via spacewalk,

    Is there a special API ?

    Thanks for help

    • Hi!

      There is a special Perl/Python/Ruby API for automating things – you can find the documentation here: http://www.spacewalkproject.org/documentation/api/2.2/

      But there is no way to automate importing Solaris packages. In my opinion the only way to automate this is to do it like that:

      1.Download patches from the official mirrors on a (dedicated?) Solaris machine (isn’t there a pkg sub-command for that?)
      2.Convert the downloaded patches into mpm files using solaris2mpm
      3.Upload the files using rhnpush

      Steps 2 and 3 can be automated as a cronjob or as a script which is scheduled as remote command using the API mentioned above.

      I hope this helps!

      Best regards,
      Christian.

Schreibe einen Kommentar