Captains Log (Ich bin der Kapitän meines Lebens -- Segeln auf den Gestaden der Realität) : Rubrik:Solaris
http://cptsalek.twoday.net/
Ich bin der Kapitän meines Lebens -- Segeln auf den Gestaden der Realität
cptsalek
cptsalek
2010-01-27T09:21:24Z
en
hourly
1
2000-01-01T00:00:00Z
Captains Log
http://static.twoday.net/cptsalek/images/icon.jpg
http://cptsalek.twoday.net/
-
Solaris "Hidden feature": /etc/inet/static_routes
http://cptsalek.twoday.net/stories/5079401/
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.<br />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:<br /> <br /><pre>#
# 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
</pre><br />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<br /><pre># route add -net 192.168.111.0 192.168.111.1</pre> open the part containing <pre>-net 192.168.111.0 192.168.111.1</pre> to /etc/inet/static_routes. And you're set.<br /> <br />This file came to my mind today after a colleague asked me today -- and two Sun Engineers afterwards.
cptsalek
Solaris
Copyright © 2008 cptsalek
2008-07-23T13:33:00Z
-
Erste Schritte mit IPS unter OpenSolaris 2008.05
http://cptsalek.twoday.net/stories/5034352/
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.<br />OpenSolaris 2008.05 - genauer gesagt <i>Project Indiana</i> enthält das neue Paketierungsverfahren <i>Image Pakaging System (IPS)</i>. Benutzer, die den <i>Nevada</i>-Builds folgen, müssen IPS erstmal nachinstallieren. Das ist aber garnicht so schwer. Sun Mitarbeiter <a href="http://blogs.sun.com/jyrivirkki/">Jyri Virkki</a> hat dazu eine kleine <a href="http://blogs.sun.com/jyrivirkki/entry/web_stack_package_repository">Zusamenfassung geschrieben</a> (Englisch). Die eigentliche Installation sieht folgendermaßen aus:<br /><pre><span style="font-size:80%">% hg clone <a href="ssh://anon@hg.opensolaris.org/hg/pkg/gate">ssh://anon@hg.opensolaris.org/hg/pkg/gate</a>
% cd gate/src
% make
% make install
% su
# make link</span></pre><br />
Danach steht auch dem Nevada-User der Befehl <span style="font-family:Courier,Helvetica">pkg </span>zur Verfügung. <span style="font-family:Courier,Helvetica">pkg </span> ist der zentrale Dreh- und Angelpunkt der Paketverwaltung, hier werden Repositories gepflegt, Pakete installiert, deinstalliert und aktualisiert.<br /> <br />
<b><u>Images</u></b><br />Das <i>Image</i> 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<br />
<pre><span style="font-size:80%"># pkg image-create --full -a opensolaris.org=http://pkg.opensolaris.org /</span></pre><br />In diesem Fall wurde ein <i>full image</i> für das System erzeugt.<br /> <br />
<b><u>Authorities</u></b><br />Jedes Image ist mit einem <i>Package Depot Server</i> verknüpft, der auch als <i>Authority</i> bezeichnet wird. Das -a im letzten Befehl hat eine solche Authority mit dem Namen <i>opensolaris.org</i> erstellt, wobei <i>http://pkg.opensolaris.org</i> 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.<br />Man kann zusätzliche Authorities erstellen, im Falle von <i>opensolaris.org</i> mittels<br />
<pre><span style="font-size:80%"># pkg set-authority -O <a href="http://pkg.opensolaris.org">http://pkg.opensolaris.org</a> opensolaris.org</span></pre><br />
Um zu sehen, welche Authorities man angelegt hat, reicht ein einfacher
<pre><span style="font-size:80%"># pkg authority
UTHORITY URL
opensolaris.org (preferred) <a href="http://pkg.opensolaris.org/">http://pkg.opensolaris.org/</a>
</span></pre><br /> <br /><b><u>Pakete suchen</u></b><br />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 <span style="font-family:Courier,Helvetica">pkg search </span>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.<br />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:
<pre><span style="font-size:80%"># 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
</span></pre><br />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 <i>FMRI, Fault Management Resource Identifier</i>, ein eindeutige Identifizierung des Pakets mitsamt Namen und Versionsnummer. FMRIs findet man auch an anderer Stelle im Solaris, z.B. die Fehlercodes des SMFs.<br /> <br />
<b><u>Pakete listen</u></b><br />
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...<br />
Alternativ kann man auch aber den Befehl <span style="font-family:Courier,Helvetica">pkg list</span> verwendet. In seiner Grundfunktion ist der dazu gedacht, die installierten Pakete aufzulisten. Das kann man schon als intuitiv bezeichnen. Die Option <span style="font-family:Courier,Helvetica">-a</span> zeigt dann auch alle Pakete an, und gibt einem somit die Möglichkeit nach dem gewünschten zu greppen:
<pre><span style="font-size:80%">
# 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 -
</span></pre><br />
Ist zumindest übersichtlicher.
<br /> <br />
<b><u>Na endlich: Pakete installieren</u></b><br />
Hat man sein Paket gefunden, reicht einfacherweise ein <span style="font-family:Courier,Helvetica">pkg install</span> aus, wobei die Option <span style="font-family:Courier,Helvetica">-nv</span> nützlich ist um zu schauen, was alles mit installiert wird:
<pre><span style="font-size:80%"># 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
</span></pre><br />
pkg installiert also immer die aktuellste Version des Paketes.<br />Man kann übrigens alternativ auch die FMRI aus dem <span style="font-family:Courier,Helvetica">pkg search</span>-Ergebnis nehmen, um eine bestimmte Version zu installieren.
cptsalek
Solaris
Copyright © 2008 cptsalek
2008-07-02T10:34:00Z
-
Schwierig?
http://cptsalek.twoday.net/stories/4887060/
<a href="http://blog.fefe.de/?ts=b6ee1f0d">Manchen von uns</a> 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.<br /> <br />Ach es geht um <i>Project Indiana</i>. 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 <i>OpenSolaris Developer <b>Edition</b></i> einer dabei ist (gcc, um genau zu sein).<br /> <br />Achja, und laut laut Projekt hat eine <i>Developer Preview</i> den folgenden Nutzen:<blockquote>is intended for developers to try, test, and provide feedback.</blockquote><br />Das Wörtchen <i>Developer</i> bezeichnet also weniger eine Toolauswahl als vielmehr eine Zielgruppe. Um nicht zu sagen: Diese Software ist für Benutzer nicht zu gebrauchen.<br /> <br />Eigentlich komisch, daß <i>Unix-Hackern</i> solche Details entgehen sollten. Oder bin ich hier nur in so eine Linux-basht-alles-Geschichte geraten?
cptsalek
Solaris
Copyright © 2008 cptsalek
2008-04-24T21:00:00Z
-
SVC: Wirklich nett gemacht
http://cptsalek.twoday.net/stories/4715930/
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.<br />
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.<br />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.<br /> <br />
Mittlerweile sind eigentlich alle Unixe von den Runlevel-Scripten entweder abgekommen, oder haben Erweiterungen daran vorgenommen, so definieren z.B. BSDs und Gentoo Dependencies.<br />
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.<br />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. ;-)<br /> <br />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.<br />
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.<br /> <br />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.<br />Mit SVC werden in diesem Falle alle Netzwerkdienste erst garnicht initialisiert. Die grundlegende Netzwerk-Konfiguration wird durch <i>network-physical</i> abgedeckt. Geht die auf failed, werden weder ssh, noch Apache noch sonstwas durch initialisiert.<br />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 <i>network-physical</i> fixen.<br />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...<br /> <br />Das ist einer der Gründe, warum ich gerne neue <i>Manifests</i> 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.<br />Ich mag kein XML.<br />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".<br />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.
cptsalek
Solaris
Copyright © 2008 cptsalek
2008-02-18T12:55:00Z
-
Alternative zu docs.sun.com
http://cptsalek.twoday.net/stories/2088773/
Es gibt eine nette Alternative oder auch Ergaenzung zu <a href="http://docs.sun.com">docs.sun.com</a>. Auf <a href="sun.com/products-n-solutions/hardware/docs/">http://www.sun.com/products-n-solutions/hardware/docs/</a> findet sich Dokumentation zum Thema, einen Link auf Software gibt es auch -- und das ganze ist viel aufgeraeumter als docs.sun.com.
cptsalek
Solaris
Copyright © 2006 cptsalek
2006-05-30T08:43:00Z
-
Python für Solaris 64 Bit kompilieren
http://cptsalek.twoday.net/stories/1641547/
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, <a href="http://www.python.org">Python</a> 2.4.2 als 64 Bit-Binary aufzusetzen. <br />
<br />
Deshalb hier die Kurzzusammenfassung meiner Ergebnisse für den <a href="http://gcc.gnu.org">gcc</a>, die allgemeingültig sein sollten:
<pre>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=</pre>
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 <a href="http://www.blastwave.org">blastwave.org</a> verwendet habe. Es ist deshalb ganz wichtig, das <span style="font-family:Courier,Helvetica">/usr/sfw/bin</span> aus dem PATH entfernt wird, weil hier ein gcc3 installiert ist, der bei mir jedoch nicht ordentlich laufen wollte.<br />
<br />
Noch einige Anmerkungen zu den blastwave-Paketen:
<ul><li>gcc3 hat einen Bug. In der ./pyconf.h müssen die Definitionen von XOPEN_SOURCE, XOPEN_SOURCE_EXTENDED und POSIX_SOURCE entfernt werden.</li><li>gcc4 hat einen Bug, hier fehlt ein symbolischer Link, weshalb keine 64 Bit-Binaries gelinkt werden können. Der Bugtracker kennt einen Bug <a href="http://www.blastwave.org/mantis/view_bug_page.php?f_id=0001405">1405</a>, der eine Lösung enthält. In der Kurzfassung:<br /><pre>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</pre></li></ul>
cptsalek
Solaris
Copyright © 2006 cptsalek
2006-03-02T11:35:22Z
find
Search this site:
q
http://cptsalek.twoday.net/search