Dieser Anhang richtet sich an Systemadministratoren, die mit dem benutzerdefinierten JumpStart-Programm oder Solaris Live Upgrade Packages installieren bzw. entfernen müssen, insbesondere Packages von Drittherstellern. Indem Sie diese Packaging-Anforderungen beachten, können Sie sicherstellen, dass die benutzerdefinierte JumpStart-Installation ohne Benutzereingriffe abläuft. Außerdem verhindern Sie, dass das zurzeit laufende System modifiziert wird, so dass Sie ein Upgrade mit Solaris Live Upgrade ausführen können.
Die folgende Dokumentation liefert Hintergrundinformationen zu den Voraussetzungen für das Packaging.
Damit das benutzerdefinierte JumpStart-Programm und Solaris Live Upgrade ordnungsgemäß funktionieren, müssen Packages den SVR4-Packaging-Anforderungen entsprechen. Spezifischere Informationen zu den Packaging-Anforderungen sowie Begriffsdefinitionen finden Sie im Dokument Application Packaging Developer's Guide. Von besonderem Interesse ist in diesem Zusammenhang das Kapitel: “Advanced Package Creation Techniques” in Application Packaging Developer's Guide
Grundlegende Informationen zum Hinzufügen und Entfernen von Packages und zur Installationsadministrationsdatei finden Sie unter “Managing Software (Overview)” in System Administration Guide: Basic Administration. Schlagen Sie auch in den relevanten Manpages nach.
Detaillierte Informationen zu den in diesem Anhang erwähnten Befehlen finden Sie in den Manpages dircmp(1), fssnap(1M), ps(1) und truss(1).
In Tabelle C–1 sind Informationen aufgeführt, die in diesem Dokument entweder für Solaris Live Upgrade oder das benutzerdefinierte JumpStart-Programm zutreffen.
Tabelle C–1 Informationen zu Anforderungen
Installationsverfahren |
Dokumentierte Anforderungen |
---|---|
Solaris Live-Upgrade |
|
Benutzerdefiniertes JumpStart-Programm |
|
Bei einer inaktiven Boot-Umgebung handelt es sich nicht um das zu dem gegebenen Zeitpunkt laufende System, sondern um eine Kopie des Betriebssystems. Ein Package, das von Live Upgrade oder dem benutzerdefinierten JumpStart-Programm verwendet werden soll, muss folgenden Anforderungen entsprechen:
Ermöglichen einer benutzerdefinierten JumpStart-Installation bzw. eines Upgrades ohne Benutzereingriffe
Keine Modifikation des zurzeit laufenden Systems (dies ist für Solaris Live Upgrade erforderlich)
Die folgende Liste zeigt die Voraussetzungen, die eine inaktive Boot-Umgebung erfüllen muss.
Für eine erfolgreiche Betriebssysteminstallation müssen die Packages Spezifikationen inaktiver Boot-Umgebungen erkennen und fehlerfrei berücksichtigen.
Packages können in der Datei pkgmap (Package-Map) absolute Pfade enthalten. Sind die Dateien vorhanden, werden sie relativ zu dem Verzeichnis geschrieben, das mit der Option -R des Befehls pkgadd angegeben wird. Packages, die absolute und relative (verschiebbare) Pfade enthalten, können ebenfalls in einem alternativen Root-Dateisystem (/) installiert werden. $PKG_INSTALL_ROOT wird absoluten und verschiebbaren Dateien vorangestellt, so dass alle Pfade bei der Installation mit pkgadd korrekt aufgelöst werden.
Packages, die mit dem Befehl pkgadd und der Option -R installiert bzw. mit dem Befehl pkgrm und der Option -R entfernt werden, dürfen das zurzeit laufende System nicht modifizieren.
Prozedurskripte, die in den mit dem Befehl pkgadd und der Option -R installierten bzw. mit dem Befehl pkgrm und der Option -R entfernten Packages enthalten sind, dürfen das zurzeit laufende System nicht modifizieren. Von Ihnen zur Verfügung gestellte Installationsskripten müssen alle Verzeichnisse und Dateien mit vorangestellter $PKG_INSTALL_ROOT-Variable referenzieren. Das Package muss alle Verzeichnisse und Dateien mit dem vorangestellten $PKG_INSTALL_ROOT-Präfix schreiben. Das Package darf keine Verzeichnisse ohne $PKG_INSTALL_ROOT-Präfix entfernen. In Tabelle C–2 sehen Sie Beispiele für die korrekte Skriptsyntax.
Tabelle C–2 Beispiele für Installationskriptsyntax
$PKG_INSTALL_ROOT ist der Speicherort des Root-Dateisystems (/) auf dem Rechner, zu dem Sie das Package hinzufügen. Der Speicherort wird auf das -R-Argument des Befehls pkgadd gesetzt. So wird beispielsweise beim Aufruf des folgenden Befehls $PKG_INSTALL_ROOT während der Package-Installation zu /a.
# pkgadd -R /a SUNWvxvm |
$BASEDIR verweist auf das verschiebbare Basisverzeichnis, in dem verschiebbare Package-Objekte installiert werden. Hier werden nur verschiebbare Objekte installiert. Nicht verschiebbare Objekte (Objekte mit absoluten Pfaden in der Datei pkgmap) werden immer relativ zur inaktiven Boot-Umgebung installiert, nicht jedoch relativ zum aktuellen $BASEDIR. Wenn ein Package keine verschiebbaren Objekte aufweist, wird es als absolutes bzw. nicht verschiebbares Package bezeichnet. $BASEDIR ist nicht definiert und steht Package-Prozedurskripten nicht zur Verfügung.
Angenommen, die Datei pkgmap eines Packages enthält zwei Einträge:
1 f none sbin/ls 0555 root sys 3541 12322 1002918510 1 f none /sbin/ls2 0555 root sys 3541 12322 2342423332 |
In der Datei pkginfo ist $BASEDIR definiert:
BASEDIR=/opt |
Bei Installation dieses Packages mit dem folgenden Befehl wird ls in /a/opt/sbin/ls, aber ls2 als /a/sbin/ls2 installiert.
# pkgadd -R /a SUNWtest |
Wenn Sie Solaris Live Upgrade verwenden und eine neue Boot-Umgebung erstellen, befolgen Sie die folgenden Richtlinien, um Probleme zu vermeiden.
Package-Prozedurskripten müssen vom aktuellen Betriebssystem unabhängig sein. Prozedurskripten definieren Aktionen, die an bestimmten Punkten während der Installation bzw. der Deinstallation von Packages auftreten. Mit diesen vordefinierten Namen können vier Prozedurskripten erstellt werden: preinstall, postinstall, preremove und postremove. Package-Prozedurskripten müssen vom derzeit aktiven Betriebssystem unabhängig sein, da mit Solaris Live Upgrade zu einer inaktiven Boot-Umgebung gewechselt werden kann.
Diese Skripten dürfen keine Prozesse starten oder stoppen und dürfen nicht von der Ausgabe von Befehlen wie ps oder truss abhängig sein, die vom Betriebssystem abhängen und Informationen über das zurzeit laufende System zurückgeben.
In Prozedurskripten können andere Standard-UNIX-Befehle wie expr, cp und ls sowie weitere Befehle verwendet werden, die das Schreiben von Skripten erleichtern. Allerdings darf die inaktive Boot-Umgebung ausschließlich im Rahmen der unter Anforderungen bezüglich der inaktiven Boot-Umgebung für das benutzerdefinierte JumpStart-Programm und Solaris Live Upgrade aufgeführten Regeln geändert werden.
Alle Skripten müssen in der Bourne-Shell (/bin/sh ) geschrieben werden. Die Bourne-Shell wird beim Ausführen von Prozedurskripten vom Befehl pkgadd als Interpreter verwendet.
Prozedurskripten für Packages dürfen Befehle, die ab dem Release 2.6 eingeführt wurden, nicht aufrufen. So dürfen Package-Prozedurskripten zum Beispiel nicht den Befehl pgrep aufrufen. Seit dem Release 2.6 wurden viele Befehle um weitere Funktionen erweitert. Package-Prozedurskripten dürfen keine Befehlsoptionen verwenden, die im Release 2.6 nicht vorhanden sind. Beispielsweise wurde die Option -f des Befehls umount im Solaris 7-Release eingeführt. Wie Sie feststellen können, ob ein bestimmter Befehl oder eine Option im Release 2.6 unterstützt wird, entnehmen Sie bitte dem Dokument Solaris 2.6 Reference Manual AnswerBook unter http://docs.sun.com.
Alle Packages müssen mit pkgchk validiert werden. Nachdem Sie ein Package erstellt haben, müssen Sie es vor der Installation mit dem folgenden Befehl überprüfen:
# pkgchk -d Verz_name Pkg-Name |
Verz_name |
Gibt den Namen des Verzeichnisses an, in dem sich das Package befindet |
Pkg-Name |
Gibt den Namen des Packages an |
Wenn ein Package zum Beispiel in /export/SUNWvxvm gespeichert ist, führen Sie den folgenden Befehl aus:
# pkgchk -d /export SUNWvxvm |
Es sollten keine Fehler angezeigt werden.
Nachdem Sie ein Package erstellt haben, müssen Sie es testen, indem Sie es mit der Option -R Verz_name des Befehls pkgadd in einer inaktiven Boot-Umgebung installieren. Nach der Installation des Packages ist es wie in diesem Beispiel mit dem Befehl pkgchk auf Fehler zu überprüfen.
# pkgadd -d . -R /a SUNWvxvm # pkgchk -R /a SUNWvxvm |
Es sollten keine Fehler angezeigt werden.
Außerdem dürfen Packages keine Befehle ausführen, die vom Package selbst geliefert werden. Dadurch wird die Kompatibilität gewährleistet und sichergestellt, dass keine Befehle ausgeführt werden, für die gemeinsam genutzte Bibliotheken benötigt werden, die noch nicht installiert sind.
Ob die Anforderungen bezüglich des Erstellens, Modifizierens und Löschens von Dateien erfüllt sind, können Sie mit einer Vielzahl von Befehlen prüfen. Mit dem Befehl dircmp und fssnap können Sie zum Beispiel verifizieren, ob sich Packages wie gewünscht verhalten. Mit dem Befehl ps können Sie außerdem die Konformität von Dämonen testen, indem Sie sicherstellen, dass das Package keine Dämonen stoppt oder startet. Mit den Befehlen truss, pkgadd -v und pkgrm können Sie testen, ob die Konformität der Package-Installation zur Laufzeit gegeben ist, doch dies funktioniert möglicherweise nicht in allen Situationen. Im folgenden Beispiel entfernt der Befehl truss alle schreibgeschützten Nicht-$TEMPDIR-Zugriffe und zeigt nur die nicht schreibgeschützten Zugriffe auf Pfade an, die nicht in der angegebenen inaktiven Boot-Umgebung liegen.
# TEMPDIR=/a; export TEMPDIR # truss -t open /usr/sbin/pkgadd -R ${TEMPDIR} SUNWvxvm \ 2>&1> /dev/null | grep -v O_RDONLY | grep -v \ 'open("'${TEMPDIR} |
Ausführliche Informationen über die hier genannten Befehle finden Sie in den Manpages dircmp(1), fssnap(1M), ps(1), truss(1), pkgadd(1M), pkgchk(1M) und pkgrm(1M).
Die Konformität mit dem benutzerdefinierten JumpStart-Programm stellt sicher, dass Packages hinzugefügt und entfernt werden können, wenn sie Teil der folgenden herkömmlichen Solaris-Installationsdienstprogramme sind:
Benutzerdefiniertes JumpStart-Programm
Solaris suninstall-Programm
Installationsverfahren Solaris Web Start
Die Konformität mit dem benutzerdefinierten JumpStart-Programm stellt außerdem sicher, dass ein Package in Solaris-Upgrades enthalten sein kann. Für die Konformität mit dem benutzerdefinierten JumpStart-Programm müssen Packages außerdem die unter Anforderungen bezüglich der inaktiven Boot-Umgebung für das benutzerdefinierte JumpStart-Programm und Solaris Live Upgrade aufgeführten Voraussetzungen für inaktive Boot-Umgebungen erfüllen.
Damit das benutzerdefinierte JumpStart-Programm effizient eingesetzt werden kann, müssen die Packages hinzugefügt und entfernt werden, ohne dass der Benutzer zur Eingabe von Informationen aufgefordert wird. Um Benutzereingriffe zu vermeiden, richten Sie mit dem Befehl pkgadd und der Option -a eine neue Administrationsdatei ein. Die Option -a definiert eine Installationsadministrationsdatei, die anstelle der Standardadministrationsdatei verwendet wird. Bei Verwendung der Standarddatei wird der Benutzer möglicherweise zur Eingabe weiterer Informationen aufgefordert. Sie können eine Administrationsdatei erstellen, in der pkgadd angewiesen wird, diese Abfragen auszulassen und das Package ohne Bestätigung seitens des Benutzers zu installieren. Nähere Informationen finden Sie in den Manpages admin(4) und pkgadd(1M).
Das folgende Beispiel zeigt, wie Sie eine pkgadd-Administrationsdatei verwenden können.
Wenn keine Administrationsdatei zur Verfügung gestellt wird, verwendet pkgadd die Datei /var/sadm/install/admin/default. Dabei werden jedoch möglicherweise Benutzereingriffe erforderlich.
# pkgadd |
Wenn Sie über die Befehlszeile eine relative Administrationsdatei angeben, sucht pkgadd in /var/sadm/install/admin nach dem Dateinamen. In diesem Beispiel lautet der Name der relativen Administrationsdatei nocheck, und pkgadd sucht nach /var/sadm/install/admin/nocheck.
# pkgadd -a nocheck |
Wenn eine absolute Datei angegeben wird, verwendet pkgadd diese. In diesem Beispiel sucht pkgadd in /tmp nach der Administrationsdatei nocheck.
# pkgadd -a /tmp/nocheck |
Sie sehen hier ein Beispiel für eine Installations-Administrationsdatei, die im Zusammenhang mit dem Dienstprogramm pkgadd nur sehr wenig Benutzerinteraktion erfordert. Sofern das Package nicht mehr Festplattenspeicher benötigt, als auf dem System verfügbar ist, greift pkgadd auf diese Datei zu und installiert das Package, ohne den Benutzer zur Eingabe von Informationen aufzufordern.
mail= instance=overwrite partial=nocheck runlevel=nocheck idepend=nocheck space=ask setuid=nocheck confiict=nocheck action=nocheck basedir=default