test

Solaris 9 Installationshandbuch

Anhang C Zusätzliche SvR4-Packaging-Anforderungen (Referenz)

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.

Hinweis -

Ein alternatives Root-Dateisystem (/) ist eine Kopie der Betriebssystemumgebung, nicht des zurzeit laufenden Systems.

Übersicht über die Packaging-Voraussetzungen

Damit das benutzerdefinierte JumpStart-Programm und Solaris Live Upgrade ordnungsgemäß funktionieren, müssen Packages den SvR4-Packaging-Anforderungen entsprechen. Im Application Packaging Developer's Guide finden Sie weitere spezifische Informationen zu Packaging-Anforderungen sowie Begriffsdefinitionen, insbesondere im folgenden 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 im 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 für Solaris Live Upgrade oder das benutzerdefinierte JumpStart-Programm relevant sind.

Tabelle C-1 Informationen zu Anforderungen

Installationsverfahren 

Dokumentierte Anforderungen 

Solaris Live Upgrade 

Benutzerdefiniertes JumpStart-Programm 

Anforderungen bezüglich des alternativen Root-Dateisystems (/) für das benutzerdefinierte JumpStart-Programm und Solaris Live Upgrade

Ein alternatives Root-Dateisystem (/) ist eine Kopie der Betriebssystemumgebung, nicht des laufenden Systems. Ein Package, das von Live Upgrade oder dem benutzerdefinierten JumpStart-Programm verwendet werden soll, muss folgenden Anforderungen entsprechen:

Die folgende Liste erläutert die Anforderungen bezüglich der Konformität alternativer Root-Dateisysteme (/).

Unterschiede zwischen $PKG_INSTALL_ROOT ind $BASEDIR - Übersicht

$PKG_INSTALL_ROOT ist der Speicherort des Root-Dateisystems (/) auf dem Rechner, zu dem Sie das Package hinzufügen. Diese Variable wird auf das -R-Argument des Befehls pkgadd gesetzt. Angenommen, der folgende Befehl wird ausgeführt:


# pkgadd -R /a SUNWvxvm

In diesem Fall wird während der Installation des Package $PKG_INSTALL_ROOT dem Verzeichnis /a vorangestellt.

$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 zum alternativen Root-Dateisystem (/) installiert, nicht jedoch relative zum aktuellen $BASEDIR. Wenn ein Package keine verschiebbaren Objekte aufweist, wird das Package als absolutes bzw. nicht verschiebbares Package bezeichnet. $BASEDIR ist nicht definiert und steht Package-Prozedurskripten nicht zur Verfügung.

Angenommen, die Datei pkgmap eines Package 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

Außerdem ist in der Datei pkginfo $BASEDIR definiert:


BASEDIR=/opt

Angenommen, dieses Package wird mit dem folgenden Befehl installiert:


# pkgadd -R /a SUNWtest

ls wird in /a/opt/sbin/ls installiert, aber ls2 wird als /a/sbin/ls2 installiert.

Konformität alternativer Boot-Umgebungen mit Solaris Live Upgrade

Wenn Sie Solaris Live Upgrade verwenden und eine neue Boot-Umgebung erstellen, befolgen Sie die folgenden Richtlinien, um Probleme zu vermeiden.

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 dem Befehl truss und pkgadd 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-$BASEDIR-Zugriffe und zeigt nur die nicht schreibgeschützten Zugriffe auf Pfade an, die nicht im angegebenen alternativen Root-Dateisystem (/) liegen. 


# BASEDIR=/a; export BASEDIR
# truss -t open /usr/sbin/pkgadd -R ${BASEDIR} SUNWvxvm \
2>&1> /dev/null | grep -v O_RDONLY | grep -v \
'open("'${BASEDIR}

Detaillierte Informationen zu den im diesem Abschnitt erwähnten Befehlen finden Sie in den Manpages dircmp(1), fssnap(1M), ps(1) und truss(1).

Konformität von Upgrades mit dem benutzerdefinierten JumpStart-Programm

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:

Die Konformität mit dem benutzerdefinierten JumpStart-Programm stellt außerdem sicher, dass ein Package in Solaris-Upgrades enthalten sein kann. Um mit dem benutzerdefinierten JumpStart-Programm konform zu sein, muss ein Package die Anforderungen bezüglich des alternativen Root-Dateisystems (/) erfüllen, die unter "Anforderungen bezüglich des alternativen Root-Dateisystems (/) für das benutzerdefinierte JumpStart-Programm und Solaris Live Upgrade" erläutert sind.

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. Das folgende Beispiel zeigt, wie Sie eine pkgadd-Administrationsdatei verwenden können.

Im Folgenden sehen Sie ein Beispiel für eine Administrationsdatei, die verhindert, dass pkgadd den Benutzer vor der Installation des Package zur Bestätigung auffordert.

mail=
instance=overwrite
partial=nocheck
runlevel=nocheck
idepend=nocheck
space=nocheck
setuid=nocheck
confiict=nocheck
action=nocheck
basedir=default

Nähere Informationen finden Sie in der Manpage admin(4) oder pkgadd(1M).