Apache 2.0 auf Solaris 10

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

daemon handling unter Solaris 10

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.

SOFiSTiK bei lanana registriert

Endlich ist SOFiSTiK bei Linux Assigned Names And Number Authority registriert. Genauer sind die Paketverwaltung (/opt/sofistik) und ein init-daemon (sofistikpsd) registriert.

Die nächste große Major release (version 25) wird dann auf einem LSB aufsetzen – wahrscheinlich LSB 3.2 oder 4.0. Gleichzeitig wird auch eine Paketverwaltung eingeführt, mit der das Updatetool SONAR ebenfalls umgehen kann.

suid-bit und chgrp

Ein kurioses Phänomen tritt bei suid-Programmen auf, wenn jenes mit chgrp einer anderen Gruppe zugewiesen wird. Nach der chgrp Operation wird das suid-bit entfernt!
Dieses Verhalten tritt bei SuSE und RedHat Linux auf. Andere Distributionen hab ich nicht getestet weswegen ich mal davon ausgehe, dass es ein distributionsübergreifender Effekt ist.
Nachvollziehen kann ihn allerdings nicht, denn das suid-bit darf ja nur root oder der owner des binaries setzen. Ein chgrp kann aber auch nur von diesen beiden Identitäten veranlasst werden. Eine mögliche Sicherheitslücke, die hier ev. chgrp schliessen soll, kann ich nicht erkennen.

Sei’s drum. Man muss jedenfalls nach ändern des chgrp das suid-bit nochmals setzen.

VMWare Workstation auf SuSE 10.2

Die letzte verfügbare Version 5.5.3 lies sich auf SuSE 10.2 problemlos installieren.

Allerdings funktioniert das Einbinden von USB – Massenspeicher nicht, da SuSE 10.2 nicht mehr das überholte usbfs zur Verfügung stellt, welches VMWare aber noch benötigt. Ich hoffe, das dies noch in der 5.5 release nachgezogen wird und man nicht gezwungen wird auf die Version 6 upzudaten.

Innerhalb der Workstation lies sich bei mir keine SuSE Installation aufspielen. Alle Installationsversuche von 4 verschiedenen DVD-/CD-Sets schlugen mit CD/DVD Lesefehler auf:

Packet ist auf dem Quellmedium nicht zu finden:...

manchmal noch mit:

Err3: Package .. fails integrity check ...

Man muss dazusagen, dass ein Mediencheck der DVD keine Fehler ergab.

Danach beendete sich die Installationsroutine. Auf einem anderen Rechner traten die gleichen Fehler auf. Auf zwei anderen hingegen (HP – PC und HP Laptop) ging es.

Auf meinem Rechner selber (Fujitsu-Siemens Scaleo) konnte ich schliesslich anstatt einer CD/DVD ein ISO-Image als „CD-Laufwerk“ angeben – mit dem gings selbstverständlich.

Die Erkenntnis ist wohl, dass bei dem Transfer von ca. 2-2.5 GB von DVD auf Festplatte wohl einige optische Laufwerke nicht den Qualitätsansprüchen von Linux genügen.

Java auf linux-ppc

Auch auf dem neuesten Kubuntu Edgy Eft für Linux ppc-arch. funktioniert der GJC (GNU Java) überhaupt nicht. Also wieder Standardmethode.
Ausgehend von dem rpm Paket IBMJava2-JRE-ppc-1.4.2-1.0.ppc.rpm, welches ich mir mal vor längerer Zeit von einer IBM Seite (mit Registrierung) gezogen habe, wird zuerst mal nach deb umgewandelt (Kubuntu/Ubuntu Linux basiert auf Debian).
Nach der Installation muss noch eine magische Umgebungsvariable in ein profile script aufgenommen werden:
export JITC_PROCESSOR_TYPE=6

Falls jemand das Paket oder den Linux benötigt bitte kurz einen Kommentar hinterlassen

Solaris 64bit System (sparc)

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

Sun Solaris 10 als (open)LDAP client

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