Category: Solaris

Im Rahmen einer Solaris 10 Installation kann auch der HTTP Server Apache2 installiert werden. Wer allerdings WebDAV mit LDAP-Authentifizierung benötigt, der wird enttäuscht werden. Das seit Version 2.0.41 zum Lieferumfang gehörende mod_auth_ldap Modul ist nicht dabei.
In diesem Fall hilft nur ein manuelles Übersetzen des Apache Webservers.

Das Kommando

pkginfo | grep apch

ergibt, dass zwei Pakete installiert wurden:

• SUNWapch2u (usr)
• SUNWapch2r (root)

Ein

pkgchk -l SUNWapch2u | grep Pathname

ergibt dass der usr-Anteil von Apache nach /usr/apache2 installiert wurde. Der root-Anteil wurde respektive nach /etc/apache2 und /var/apache2 installiert. Theoretische könnte man diese Apache2 Installation auf dem Rechner belassen und zusätzlich eine nach /usr/local installieren – der Übersicht wegen habe ich aber diese Pakete entfernt, habe aber zwei Dateien aus den Paketen nach /tmp kopiert.

• /lib/svc/method/http-apache2
• /var/svc/manifest/network/http-apache2.xml
Die zweite Datei ist das SMF Manifest welches das erste Skript zum Starten/Stoppen des Daemons benötigt.Jetzt kann’s losgehen. Als Vorraussetzungen müssen einige SMC Pakete von hier.Danach den aktuellen tarball herunterladen und auspacken. Es folgt der configure Schritt

./configure --prefix=/usr/local/apache2 --enable-mods-shared=all
--enable-ssl=shared --enable-ssl --with-ssl=/usr/local/ssl
--enable-proxy --enable-proxy-connect --enable-proxy-ftp
--enable-proxy-http --enable-ldap --enable-auth-ldap

Bei meiner, unabsichtlich unvollständigen, Installation lief dies sofort auf einen Fehler:

Checking for C compiler default output file...
configure: error: C compiler cannot create executables

Das Problem ist, dass der von Sunfreeware installierte gcc Compiler alle SUNW Entwicklerpakete benötigt, die normalerweise nach /usr/ccs installiert werden, siehe dazu folgenden Kommentar. Ergänzend muss noch erwähnt werden dass natürlich PATH und LD_LIBRARY_PATH für den make Vorgang um die Entwicklerpfade ergänzt werden müssen.
Danach lief der configure Schritt ohne Probleme, aber make blieb nach einiger Zeit hängen:

util_ldap.c:43:2 #error mod_ldap requires APR-util to have
LDAP support built in

Das Problem ist hier dass die APR (Apache Portable Runtime) entweder schon auf dem Rechner war (bei mir durch svn) oder zuvor durch den autoconfigure Schritt ohne LDAP Support erstellt wurde.
Daher müssen folgende Schritte durchgeführt werden:

1. APR mit LDAP erstellen (bspw. nach /usr/local/apache2-apr)
2. APR-util mit LDAP erstellen (ins gleiche Verzeichnis)
3. Apache2 gegen diese APR linken

Auch diese Schritte sind nochmals hier (Apache Mailinglist) erklärt.
Diese Schritte führten dann endlich zu einem Apache2 Webserver unter /usr/local/apache2

Man könnte den Webserver jetzt schon durch das Startscript apachectl in /usr/local/apache2/bin starten, jedoch sollten wir die zwei am Anfang nach /tmp kopierten Files anpassen, zurückkopieren und unseren Apache2 über das Solaris10 eigene Service Management Facility starten. Im einzelnen war dies

im Skript /lib/svc/method/http-apache2 die Pfade anpassen und ein switch restart einfügen
in /var/svc/manifest/network/http-apache2.xml den Namen im Abschnitt service_bundle auf „http-apache2“ ändern und einen Abschnitt „restart“ einführen

Abschliessend wird dass Manifest geprüft, in das SMF Repository eingefügt und der Dienst gestartet. Die Kommandos lauten

svccfg validate http-apache2.xml

svccfg import http-apache2.xml

svcadm enable svc:/network/http:apache2

In der klassischen System V Welt, d.h. auch unter Linux aber nicht unter Mac OS X, gibt es verschiedene Runlevels zu denen es jeweils ein Unterverzeichnis unterhalb /etc gibt mit Start- und Stopscripten von Diensten.
Startet also der init Prozess (pid 1) auf einem System V UNIX System arbeitet er sukzessive die Startskripte dieser Verzeichnisse ab, wobei zumindest unter Linux einen Nummerierung der Startskripte die Reihenfolge der Abarbeitung festlegt.
Ein nachträglicher Neustart oder das Stoppen ist jederzeit mit solch einem Skript möglich.

Dieses Konzept hat aber mindestens zwei Schwachstellen.

1. Das einfügen eines neuen Dienstes ist aufwändig. Neben dem allg. Start-/Stopskript muss in jedem passenden runlevel Unterverzeichnis ein link gesetzt werden, wobei die Nummerierung oftmals nicht eindeutig sein kann.
2. Es gibt keinen Supervisor über die Dienste der im Fehlerfall eine Aktion auslösen könnte. Normalerweise wird lediglich im log Bereich protokolliert. Eine respawn Direktive kann diese Situation noch leicht verbessern.

Sun führte deshalb die sog. Service Management Facility (SMF) ein:
Die Skripte der SMF basieren auf XML und lösen die /etc/init.d Skripte ab.
Ein Starten (enable) oder Stoppen (disablen) eines Dienstes ist persistent, es überlebt einen reboot des Systems. Daher ist ein seperater Eintrag in einer inittab/runlevel obsolet.
Alle so gestarteten Dienste werden von einer Art Service Masterdaemon überwacht, dem Holderprozess svc.startd . Die Basis hierfür ist ein Contract System bei der ein zu startender Dienst nebem einer klassischen PID auch eine Contract ID (CTID) bekommt, die direkt dem Holder Prozeß unterstellt ist.
Auch Dämonen die von inetd gestartet werden, besitzen einen SMF Eintrag und werden wie ein stand-alone Dienst gestartet – der Prozess Holder ist dann allerdings inetd, der wiedersum svc.startd untersteht.
Alle Laufzeitinformationen werden in einer sqlite Datenbank gehalten, die einerseits effizient arbeitet andererseits eine mögliche Quelle für einen Totalausfall des Systems darstellt.

Folgender genauerer Überblick über die SMF:

• /lib/svc beinhaltet Administrationsprogramme für die SMF sowie unter „method“ auch die Start-/Stopsckripte zum einmaligen einlesen

• /var/svc beinhaltet die eigentlichen XML Servicebeschreibungen (Manifeste). Das Manifest beinhaltet v.a. Abhängigkeiten gegenüber anderen Diensten und Resourcen, das Fehlerhandling sowie die Start-/Stop Anweisungen die wiederum oft auf ein klassisches Skript in /lib/svc/method verweisen

• /etc/svc beinhalet überraschenderweise das sqlite Repository, welches nicht unter /var/svc angesiedelt ist, sowie logs zum repository.

Beschreibung eines Dienstes, das Manifest:

• beinhaltet den Header
• beschreibt Art und Grad der Abhängigkeit von anderen Diensten/Resourcen
• enthält Start-/Stop Methoden (stop meist mittels :kill definiert)
• definiert spezielle Eigenschaften
• Hinweise zu Dokumentationen

Administration von SMF:

• svcs Service Status, listet alle Dienste des Repositories und Ihren Status auf
• svcs -l detaillierte Ausgabe eines Services incl. CTID der Servicename, bzw. der FRMI (Fault Managed Resource Identifier), kann in der Langform, oder in einer verkürzten Form, falls eindeutig möglich, angegeben werden, bspw: svc:/network/ssh oder auch nur ssh
• svcadm enable/disable ein-/auschalten (online/offline) eines Services
• svcadm restart/refresh durchstarten/erneuern (bei leichten Konf.änderungen)
• svcprop liest die Eigenschaften aus dem Manifest aus
• svccfg Sobald ein XML Manifest einmal in das SMF Repository eingelesen ist (svccfg import) ist diese File unerheblich und nur noch das sqlite Repository maßgebend. svccfg ist ein Tool zur Manipulation dieses Repositories.

Interessant scheint mir, dass auf einem UltraSparc IIe Rechner
SunOS Release 5.10 Version Generic 64-bit

die meisten Dateien des Betriebssystem „nur“ 32bit Binaries sind.
# file /usr/bin/ls
/usr/bin/ls: ELF 32-Bit MSB ausführbar SPARC Version 1,..

Interessant vor allem, weil die Solaris10 Variante auf x64 eher 64bit binaries enthält. Auf dieser Plattform gibt es laut SUN eher Performancevorteile durch bessere Register. Der Grund für die 32bit Programme auf UltraSparc ist wohl der Speicher Overhead einer 64bit Applikation der sich leicht negativ auswirkt.
http://developers.sun.com/sunstudio/articles/options.html

Wenn im Netzwerk eine Single-Sign-On Authentifizierung via openLDAP existiert und eine neue Solaris Maschine angebunden werden soll benötigt man dort das ldapclient Kommando.

Zuerst sollte man aber einen genaueren Blick in die Datei

/etc/nsswitch.ldap

werfen. Denn diese Datei wird nach mit dem Aufruf des ldapclient Kommandos nach /etc/nsswitch.conf kopiert. Wenn man bspw. nur Accounts mit openLDAP verwaltet, Hostnamen aber via DNS, dann muss man den Eintrag

hosts: ldap [NOTFOUND=return] files

in

hosts: files dns

ändern. Denn sonst funktioniert bestenfalls keine Hostnamensauflösung mehr, schlechtestenfalls bootet der Rechner gar nicht mehr, falls in /etc/hosts der eigene Rechnername nicht gelistet ist.

Nach dem ändern dieser Datei wird nun das Kommando aufgerufen, dass eine persistente – also einen Neustart überlebende – LDAP Anbindung schafft. Das erste Argument kann init oder manual lauten. „init“ setzt eine automatische Konfiguration voraus, welche im LDAP Repository schon vorhanden ist. Falls nicht kann man diese aber auch mit diesem Befehl erzeugen und im LDAP Server dann einspielen – näheres sagt die manpage über diesen Befehl.

Der andere Weg ist die manuelle Anbindung. Beispielhaft sieht sowas folgendermaßen aus:

ldapclient manual -a „defaultSearchBase=o=myOrganization,c=de“ -a „defaultServerList=ldaphost.mydomain.de“ -a serviceAuthentificationMethod=pam_ldap:tls:simple“

Dieser Befehl schreibt diese Konfiguration dann nach /var/ldap und startet via SMF den ldap/client. Der Befehl

svcs -l ldap/client

sollte dann den Status online ausgeben.

Falls „getent passwd“ oder „getent group“ nicht die gewünschte Anbindung anzeigt, muss ev. mit dem Attribut „serviceSearchDescriptor“ nachgeholfen werden. Nachträgliche Änderungen erfolgen mit ldapclient mod