Captains Log

On our sites some of our machines have a nice init-Script called /etc/init.d/setroutes, that sets additional routes needed for correct operation. I always wondered why Sun obviously did not have such a feature built into the Solaris. I can't remember that we've spoken about this issue during the "Solaris 10 for experienced SysAdmins" seminar.
I recently had enough and wondered if there would be any /lib/svc/method that contained the route command. And sure enough, net-init closes with the following lines:
 

#
# Read /etc/inet/static_routes and add each route.
#
if [ -f /etc/inet/static_routes ]; then
        echo "Adding persistent routes:"
        /usr/bin/egrep -v "^(#|$)" /etc/inet/static_routes | while read line; do
                /usr/sbin/route add $line
        done
fi

In other words: Create a file /etc/inet/static_routes, containing a route definition starting after the route add command. E.g. to add a network route, instead of using

# route add -net 192.168.111.0 192.168.111.1

open the part containing

-net 192.168.111.0 192.168.111.1

to /etc/inet/static_routes. And you're set.
 
This file came to my mind today after a colleague asked me today -- and two Sun Engineers afterwards.

Die Paketverwaltung war bisher immer einer der großen Kritikpunkte in Solaris: Zwar gab es Pakete, die auch Abhängigkeite kannten, allerdings war pkgadd nicht in der Lage, aus einem Repository fehlende Pakete nachzuladen. Pkgrm konnte nur anzeigen, welche Pakete von einem zu entfernenden Paket benötigt werden. Einen ganzen Strang automatisch zu entfernen war somit ebenfalls nicht möglich.
OpenSolaris 2008.05 - genauer gesagt Project Indiana enthält das neue Paketierungsverfahren Image Pakaging System (IPS). Benutzer, die den Nevada-Builds folgen, müssen IPS erstmal nachinstallieren. Das ist aber garnicht so schwer. Sun Mitarbeiter Jyri Virkki hat dazu eine kleine Zusamenfassung geschrieben (Englisch). Die eigentliche Installation sieht folgendermaßen aus:

% hg clone ssh://anon@hg.opensolaris.org/hg/pkg/gate
% cd gate/src
% make
% make install
% su
# make link

Danach steht auch dem Nevada-User der Befehl pkg zur Verfügung. pkg ist der zentrale Dreh- und Angelpunkt der Paketverwaltung, hier werden Repositories gepflegt, Pakete installiert, deinstalliert und aktualisiert.
 
Images
Das Image im Namen unterscheidet IPS dabei von anderen Systemen, die ich bisher gesehen habe. So ganz genau weiß ich auch noch nicht, was ich mir unter dem Begriff Image vorstellen soll, bzw. was man genau alles damit anfangen kann. Bevor man mit IPS arbeiten kann, muss man aber eines erstellen, z.B. via

# pkg image-create --full -a opensolaris.org=http://pkg.opensolaris.org /

In diesem Fall wurde ein full image für das System erzeugt.
 
Authorities
Jedes Image ist mit einem Package Depot Server verknüpft, der auch als Authority bezeichnet wird. Das -a im letzten Befehl hat eine solche Authority mit dem Namen opensolaris.org erstellt, wobei http://pkg.opensolaris.org der eigentliche Server ist. Die URL läßt sich übrigens auch im Browser aufrufen, man erhält dann eine Seite mit Status des Repositories sowie eine Liste der enthaltenen Pakete.
Man kann zusätzliche Authorities erstellen, im Falle von opensolaris.org mittels

# pkg set-authority -O http://pkg.opensolaris.org opensolaris.org

Um zu sehen, welche Authorities man angelegt hat, reicht ein einfacher

# pkg authority
UTHORITY                           URL
opensolaris.org (preferred)         http://pkg.opensolaris.org/

 
Pakete suchen
Wenn man erstmal soweit ist, geht in Richtung Paketinstallation. Interessant wäre es jetzt, das Repository durchsuchen zu können. In der Tat steht einem dafür der Befehl pkg search zur Verfügung. Meine Erwartung wäre jetzt gewesen, dass der Befehl nach Paketnamen sucht. IPS durchsucht aber die Pakete nach dem Suchstring. Das kann irritierend sein.
Ausserdem kann pkg sowohl die lokal installierten Pakete durchsuchen, wie auch den entfernten Server. Ersteres ist übrigens die Voreinstellung. Wer also etwas zur Installation sucht, sollte entsprechend vorbereitet sein. Hier mal einige Beispiele:

# pkg search vim
# pkg search -r vim
INDEX      ACTION    VALUE                     PACKAGE
basename   dir       usr/demo/mercurial/vim    pkg:/SUNWmercurial@0.9.5-0.86
basename   dir       usr/demo/mercurial/vim    pkg:/SUNWmercurial@0.9.5-0.79
basename   dir       usr/demo/mercurial/vim    pkg:/SUNWmercurial@0.9.3-0.75
basename   dir       usr/demo/mercurial/vim    pkg:/SUNWmercurial@0.9.5-0.86
basename   file      usr/bin/vim               pkg:/SUNWvim@7.1.145-0.86
basename   file      usr/bin/vim               pkg:/SUNWvim@7.1.145-0.86
basename   file      usr/bin/vim               pkg:/SUNWvim@7.1.145-0.79
basename   dir       usr/demo/mercurial/vim    pkg:/SUNWmercurial@1.0-0.89
basename   file      usr/bin/vim               pkg:/SUNWvim@7.1.284-0.89
basename   dir       usr/demo/mercurial/vim    pkg:/SUNWmercurial@1.0-0.90
basename   file      usr/bin/vim               pkg:/SUNWvim@7.1.284-0.90
basename   dir       usr/demo/mercurial/vim    pkg:/SUNWmercurial@1.0-0.91
basename   file      usr/bin/vim               pkg:/SUNWvim@7.1.284-0.91

Mit dem ersten Befehl habe ich nach vim gesucht, bin aber nicht fündig geworden. Mit -r sucht man im Repository des Servers ("remote"). Hier ist pkg direkt mehrmals fündig geworden. Dabei ist die letzte Spalte interessant: Hier findet sich die FMRI, Fault Management Resource Identifier, ein eindeutige Identifizierung des Pakets mitsamt Namen und Versionsnummer. FMRIs findet man auch an anderer Stelle im Solaris, z.B. die Fehlercodes des SMFs.
 
Pakete listen
Der Suchbefehl taugt also nur wirklich, wenn man nach Paketinhalten sucht oder zufälligerweise nach Paketen sucht, wo der Paketname auch der Name des Binaries ist, das man eigentlich verwenden will. Bei großen Paketen wird das aber unübersichtlich, wer möchte, kann das gerne mit mit "firefox" als Suchbegriff probieren...
Alternativ kann man auch aber den Befehl pkg list verwendet. In seiner Grundfunktion ist der dazu gedacht, die installierten Pakete aufzulisten. Das kann man schon als intuitiv bezeichnen. Die Option -a zeigt dann auch alle Pakete an, und gibt einem somit die Möglichkeit nach dem gewünschten zu greppen:

# pkg list -a |grep vim 
SUNWvim                                       7.1.145-0.79    known      ----
SUNWvim                                       7.1.145-0.86    known      ----
SUNWvim                                       7.1.145-0.86    known      ----
SUNWvim                                       7.1.284-0.89    known      ----
SUNWvim                                       7.1.284-0.90    known      ----
SUNWvim                                       7.1.284-0.91    known      -

Ist zumindest übersichtlicher.
 
Na endlich: Pakete installieren
Hat man sein Paket gefunden, reicht einfacherweise ein pkg install aus, wobei die Option -nv nützlich ist um zu schauen, was alles mit installiert wird:

# pkg install -nv SUNWvim
Before evaluation:                    
UNEVALUATED:
+pkg:/SUNWvim@7.1.284,5.11-0.91:20080613T180507Z

After evaluation:
None -> pkg:/SUNWvim@7.1.284,5.11-0.91:20080613T180507Z
None
 # pkg install SUNWvim
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                    1/1   1300/1300   16.88/16.88 

PHASE                                        ACTIONS
Install Phase                              1345/1345

pkg installiert also immer die aktuellste Version des Paketes.
Man kann übrigens alternativ auch die FMRI aus dem pkg search-Ergebnis nehmen, um eine bestimmte Version zu installieren.

Manchen von uns scheint die Installation eines Compilers wohl nicht zuzumuten sein. Komisch, ich dachte immer die größte Zahl der User da draußen könnte mit den Dingern garnichts anfangen, und würde sie deshalb auch nicht vermissen.
 
Ach es geht um Project Indiana. Eine LiveCD inklusive Installer, also max. 700MB. Wenn ich mal davon ausgehe, das Suns eigener Compiler (SUNWspro) mit einer IDE daher kommt und deshalb installiert um die 1,2GB auf die Waage bringt weiß ich, warum keiner dabei. Dafür bin ich mir ziemlich sicher, daß bei der OpenSolaris Developer Edition einer dabei ist (gcc, um genau zu sein).
 
Achja, und laut laut Projekt hat eine Developer Preview den folgenden Nutzen:

is intended for developers to try, test, and provide feedback.

Das Wörtchen Developer bezeichnet also weniger eine Toolauswahl als vielmehr eine Zielgruppe. Um nicht zu sagen: Diese Software ist für Benutzer nicht zu gebrauchen.
 
Eigentlich komisch, daß Unix-Hackern solche Details entgehen sollten. Oder bin ich hier nur in so eine Linux-basht-alles-Geschichte geraten?

Eine der "großen Neuerungen" von Solaris 10 war sicherlich SVC, der "init.d-Ersatz". Die lieb gewonnen Runlevel-Scripte bringen in aktuellen Systemen eine Reihe von Nachteilen mit sich. So werden sie streng anhand ihrer nummerierten Reihenfolge ausgeführt, ohne dass Abhängigkeiten berücksichtigt werden.
Das bedeutet zum einen, dass kein Nutzen aus SMP-Systemen gezogen werden, weil immer ein Script nach dem anderen ausgeführt wird. Zum anderen muß ein nachfolgendes Script davon ausgehen, dass seine Vorgänger gestartet worden sind, es gibt vernünftige Möglichkeit, Fehler abzufangen.
Wenn also irgendwo ein Fehler aufgetreten ist bootet das System trotzdem weiter und es kommt zu einer ganzen Reihe Folgefehler. Im Ernstfall kann man kaum abschätzen in welchem Zustand ein System dann ist, und was man noch alles machen muß, nachdem der ursprüngliche Fehler behoben ist.
 
Mittlerweile sind eigentlich alle Unixe von den Runlevel-Scripten entweder abgekommen, oder haben Erweiterungen daran vorgenommen, so definieren z.B. BSDs und Gentoo Dependencies.
Einzig Sun ist den Weg aber komplett gegangen und verwendet nur noch ein paar wenige Init-Scripte im "Legacy_Run". Mit einem Ende ist wohl mit Solaris 11 zu erwarten, wenn ich diversen Stimmchen trauen darf.
Statt dessen tritt SVC auf den Plan, welches anhand der einzelnen Abhängigkeitsdefinitionen ganze Bäume erstellt und diese parallel anfahren kann, auch wenn man über Zeitgewinn streiten kann. Andererseits boote ich meine Server nicht so häufig als das ich für einen Streit Energie verschwenden würde. ;-)
 
In SVC sind die alten Runlevel, vor allem rc3 als Solaris Defaultrunlevel als sogenannte "Milestones" aufgeführt. Ein Milestones besteht aus einem Haufen Abhängigkeitsdefinitionen, stellt aber selber keine Dienste zur Verfügung. Beim Booten der Maschine kann man diese Meilensteine - es gibt natürlich auch einen für Singleuser - gezielt anfahren.
Was SVC von den ganzen Alternativen abhebt ist die Tatsache, dass nach meiner Erfahrung nur Solaris 10 in der Lage ist, einen Abbruch wieder korrekt aufzunehmen und damit einen Bootvorgang richtig fortzusetzen. Anders ausgedrückt: Egal was passiert, SVC bietet zu jeder Zeit einen konsistenten Stand des Systems.
 
Kleines Beispiel: Bei der Netzwerk-Konfiguration ist was schief gelaufen und eine Service-IP fehlt z.B. Eine nachgelagerte Apache-Instanz macht darauf aber einen Bind, da die IP aber nicht existiert schlägt der fehl und der Apache wird nicht gestartet.
Mit SVC werden in diesem Falle alle Netzwerkdienste erst garnicht initialisiert. Die grundlegende Netzwerk-Konfiguration wird durch network-physical abgedeckt. Geht die auf failed, werden weder ssh, noch Apache noch sonstwas durch initialisiert.
Spätestens wenn die User anrufen, dass sie sich nicht auf das System konnekten können, kann Admin also hingehen, sieht den Zustand, und kann network-physical fixen.
In dem Moment, wo das passiert ist und der SVC-Service damit in den Status Enabled wechselt, zieht SVC automatisch alle abhängigen Dienste an, ohne das Admin eingreifen muß. Voila...
 
Das ist einer der Gründe, warum ich gerne neue Manifests für Anwendungen schreibe, die wir unter Solaris 10 produktiv nehmen. Dabei offenbaren die Manifests meiner Meinung nach einen Pferdefuß, da es sich hierbei um XML-Dateien handelt.
Ich mag kein XML.
Meiner Meinung nach hat XML bis heute noch nicht bewiesen, daß es das kann, wofür es geschaffen worden ist. Die Import-Funktion, mit der ein neuen Manifest ins SVC-Repository integriert wird, ist da ein gutes Beispiel für. Statt einer ordentlichen Fehlermeldung, weil der Parser irgendwas nicht verstanden hat, kommt nur eine höchst ominöse Meldung a la "es ist ein Fehler aufgetreten".
Aber irgendwas ist ja immer, und ich habe die Hoffnung noch nicht aufgegeben, dass Sun in einer der zukünftigen Versionen dem Parser ein paar ordentliche Meldungen implantieren kann.

Es gibt eine nette Alternative oder auch Ergaenzung zu docs.sun.com. Auf http://www.sun.com/products-n-solutions/hardware/docs/ findet sich Dokumentation zum Thema, einen Link auf Software gibt es auch -- und das ganze ist viel aufgeraeumter als docs.sun.com.

Mag sein, das ich mir noch Kenntnisse, was den Umgang mit Compilern in 64 Bit Modis aneignen muß. Gestern habe ich zumindest einen guten Teil des Tages damit verbracht, Python 2.4.2 als 64 Bit-Binary aufzusetzen.

Deshalb hier die Kurzzusammenfassung meiner Ergebnisse für den gcc, die allgemeingültig sein sollten:

export CFLAGS="-mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1"
export BASECFLAGS=$CFLAGS       # Python-specific
export CXXFLAGS=$CFLAGS
export CPPFLAGS=$CFLAGS
export LDFLAGS="-mcpu=v9 -m64"
export LDDFLAGS="${LDFLAGS} -G"
export PATH=/opt/csw/gcc4/bin:/opt/csw/bin:/usr/sbin:/usr/bin:/usr/ccs/bin
export LD_LIBRARY_PATH=
export LD_LIBRARY_PATH_32=
export LD_LIBRARY_PATH_64=

CFLAGS setzt die benötigten Flags für 64 Bit, BASECFLAGS ist dabei eine Spezialität des Python-Makefiles. Im PATH erkennt man, dass ich gcc4 von blastwave.org verwendet habe. Es ist deshalb ganz wichtig, das /usr/sfw/bin aus dem PATH entfernt wird, weil hier ein gcc3 installiert ist, der bei mir jedoch nicht ordentlich laufen wollte.

Noch einige Anmerkungen zu den blastwave-Paketen:

• gcc3 hat einen Bug. In der ./pyconf.h müssen die Definitionen von XOPEN_SOURCE, XOPEN_SOURCE_EXTENDED und POSIX_SOURCE entfernt werden.
• gcc4 hat einen Bug, hier fehlt ein symbolischer Link, weshalb keine 64 Bit-Binaries gelinkt werden können. Der Bugtracker kennt einen Bug 1405, der eine Lösung enthält. In der Kurzfassung:
  

  cd /opt/csw/gcc4/lib/sparcv9
  ln -s libgcc_s.so.1 libgcc_s.so
  installf CSWgcc4core /opt/csw/gcc4/lib/sparcv9/libgcc_s.so
  installf -f CSWgcc4core