Bilaga G Ytterligare krav för SVR4-paketering (Referens)

Den här bilagan riktar sig till systemadministratörer som måste installera och ta bort paket med anpassad JumpStart eller Solaris Live Upgrade, speciellt paket från andra tillverkare. Om de här paketeringskraven följs blir den anpassade JumpStart-installationen icke-interaktiv och systemet som körs för tillfället ändras inte, vilket gör det möjligt att uppgradera med Solaris Live Upgrade.

Paketeringskrav, översikt

Följande dokumentationsreferenser är avsedda som bakgrundsinformation för paketeringskrav.

• För att anpassad JumpStart och Solaris Live Upgrade ska fungera ordentligt måste paketen följa paketeringskraven för SVR4. Application Packaging Developer's Guide innehåller mer detaljerad information om paketeringskrav och termdefinitioner. Läs särskilt följande kapitel:“Advanced Package Creation Techniques” in Application Packaging Developer's Guide

• Om du vill ha grundläggande information om hur du lägger till och tar bort paket och installationsadministrationsfilen, läser du “Managing Software (Overview)” in System Administration Guide: Basic Administration. Läs också relevant direkthjälp (man pages).

• Om du vill ha detaljerad information om kommandon som det refereras till i den här bilagan, läser du i direkthjälpen (man pages), dircmp(1), fssnap(1M), ps(1), eller truss(1).

Tabell G–1 visar information som gäller antingen Solaris Live Upgrade eller anpassad JumpStart i det här dokumentet.

Krav för inaktiv startmiljö för anpassad JumpStart och Solaris Live Upgrade

En inaktiv startmiljö är en kopia av operativmiljön och inte av det system som körs just nu. Ett paket som används av Live Upgrade eller anpassad JumpStart måste följa de här kraven:

• Aktivera en anpassad JumpStart-installation eller -uppgradering utan användarinteraktivitet

• När du använder Solaris Live Upgrade får systemet som körs för tillfället inte ändras

I följande lista förklaras kraven för inaktiva startmiljöer

• Om en installation av ett operativsystem ska lyckas måste paketen känna igen och följa de inaktiva startmiljöangivelsena.

  Paketen kan inkludera absoluta sökvägar i deras pkgmap-fil (paketavbildning). Om de här filerna finns är de skrivna relativt till pkgadd-kommandots - R-alternativ. Paket som innehåller både absoluta och relativa (relokerbara) sökvägar kan också installeras till en alternativ rot (/). $PKG_INSTALL_ROOT läggs till före både absoluta och relokerbara filer så att alla sökvägar löses korrekt när de installeras med pkgadd.

• Paket som installeras med alternativet -R för pkgadd eller som tas bort med alternativet -R för pkgrm får inte ändra det system som körs för tillfället.

  Procedurskript som följer med de paket som installeras med kommandot pkgadd och alternativet -R, eller som tas bort med kommandot pkgrm och alternativet -R, får inte ändra det system som körs för tillfället. Alla installationsskript som du använder måste referera till en katalog eller fil med variabeln $PKG_INSTALL_ROOT som prefix. Paketet måste skriva alla kataloger och filer med prefixet $PKG_INSTALL_ROOT. Paketet får inte ta bort kataloger och filer utan prefixet $PKG_INSTALL_ROOT. Tabell G–2 ger exempel på korrekt skriptsyntax.

  Tabell G–2 Exempel på installationskriptsyntax

  Skriptyp	Korrekt syntax	Inkorrekt syntax
  Bourne-skalet “om” instruktionen fragmenterar	if [ -f ${PKG_INSTALL_ROOT}\ /etc/myproduct.conf ] ; then	if [ -f /etc/myproduct.conf ] ; \ then
  Ta bort en fil	/bin/rm -f ${PKG_INSTALL_ROOT}\ /etc/myproduct.conf	/bin/rm -f /etc/myproduct.conf
  Ändra en fil	echo "test=no" ${PKG_INSTALL_ROOT}\ /etc/myproduct.conf	echo "test=no"> \ /etc/myproduct.conf

Skillnader mellan $PKG_INSTALL_ROOT och $BASEDIR , översikt

$PKG_INSTALL_ROOT är platsen där rotfilssystemet ( /) för datorn som du lägger till paketen på finns. Platsen anges till -R-argumentet för kommandot pkgadd. Om till exempel följande kommando anropas läggs $PKG_INSTALL_ROOT till framför /a under installation av paketet.

# pkgadd -R /a SUNWvxvm

$BASEDIR pekar på den relokerbara baskatalog som relokerbara paketobjekt installeras till. Endast relokerbara objekt installeras här. Icke-relokerbara objekt (de som har absoluta sökvägar i pkgmap-filen) installeras alltid relativt till den inaktiva startmijön (/), men inte relativt till $BASEDIR. Om ett paket inte har några relokerbara objekt, anses paketet vara ett absolut paket (eller icke-relokerbart). $BASEDIR är då odefinierad och inte tillgänglig för paketprocedurskript.

Anta exempelvis att paketets pkgmap-fil har två poster:

1 f none sbin/ls 0555 root sys 3541 12322 1002918510
1 f none /sbin/ls2 0555 root sys 3541 12322 2342423332

Filen pkginfo har en specifikation för $BASEDIR:

BASEDIR=/opt

Om det här paketet installeras med följande kommando installeras ls i /a/opt/sbin/ls, men ls2 installeras som /a/sbin/ls2.

# pkgadd -R /a SUNWtest

Standard för inaktiva startmiljöer för Solaris Live Upgrade

När du använder Solaris Live Upgrade och skapar en ny startmiljö undviker du problem genom att följa de här riktlinjerma.

• Paketprocedurskripten måste vara oberoende av den för tillfället aktiva operativmiljön. Procedurskripten definierar åtgärder som inträffar vid vissa punkter under paketinstallation och -borttagning. Det finns fyra procedurskript som kan skapas med de här fördefinierade namnen: preinstall, postinstall, preremove och postremove. Paketprocedurskripten måste vara oberoende av den för tillfället aktiva operativmiljön, eftersom en växling till en inaktiv startmiljö kan ske om Solaris Live Upgrade används.

  • De här skripten får inte starta eller stoppa några processer eller vara beroende av resultat från kommandon, som exempelvis ps eller truss , som är operativsystemsberoende och rapporterar information om det system som körs för tillfället.

  • Procedurskripten får använda andra standardkommandon för UNIX, som exempelvis expr, cp och ls samt andra kommandon som underlättar skalskript. Men den inaktiva startmiljön får inte ändras utanför de regler som beskrivs i avsnittet, Krav för inaktiv startmiljö för anpassad JumpStart och Solaris Live Upgrade .

  • Alla skript måste skrivas i Bourne-skal (/bin/sh ). Bourne-skal är tolken som används av kommandot pkgadd för att köra procedurskript.

  • Procedurskript för paket får inte anropa kommandon som lades till i version 2.6 eller senare. Paketprocedurskript kan till exempel inte anropa kommandot pgrep. Sedan version 2.6 har många kommandon fått ytterligare funktioner. Paketprocedurskript får inte använda kommandoalternativ som inte fanns i version 2.6. Alternativet -f för umount-kommandot lades till i Solaris 7, till exempel. Information som du kan använda för att verifiera att ett visst kommando eller alternativ stöds i Solaris 2.6 finns i Solaris 2.6 Reference Manual AnswerBook på http://docs.sun.com.

• Alla paket måste genomgå en pkgchk-validering. När ett paket har skapats måste det kontrolleras med följande kommando innan det installeras.

  # pkgchk -d katalognamn paketnamn

  katalognamn

  Anger namnet på den katalog där paketet finns

  paketnamn

  Anger namnet på paketet

  Om ett paket finns i /export/SUNWvxvm, till exempel, utfärdar du följande kommando.

  # pkgchk -d /export SUNWvxvm

  Inga fel visas.

  När ett paket har skapats måste det testas genom att det installeras till en inaktiv startmiljöplats med alternativet -R katalognamn för pkgadd. När paketet har installerats måste det kontrolleras med pkgchk, som i det här exemplet.

  # pkgadd -d . -R /a SUNWvxvm # pkgchk -R /a SUNWvxvm

  Inga fel visas.

• Paket får heller inte köra kommandon som levereras av paketet självt. Skälet är att kompatibilitet med skivlöshet eftersträvas och att kommandon som kräver delade bibliotek som ännu inte är installerade förhindras.

De här kraven för att skapa, ändra och ta bort filer kan verifieras med flera olika kommandon. Kommandona dircmp och fssnap till exempel kan användas för att verifiera att paketen fungerar som de ska. Dessutom kan kommandot ps användas för att testa bakgrundsprogramskompatibilitet genom att kontrollera att bakgrundsprogram inte stoppas eller startas av paketet. Kommandona truss,pkgadd,-v och pkgrm kan testa paketinstallation vid körtid, men de fungerar inte alltid i alla situationer. - I följande exempel tar kommandot truss bort alla skrivskyddade, icke-$TEMPDIR-åtkomst och visar bara icke-skrivskyddad åtkomst till sökvägar som inte ligger inom den alternativa rot (/) som angetts.

# 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}

Utförligare information om de kommandon som det refereras till i det här avsnittet finns i direkthjälpen (man pages) för dircmp(1), fssnap(1M), ps(1), truss(1), pkgadd(1M), pkgchk(1M), or pkgrm(1M).

Uppgraderingskompatibiltet med anpassad JumpStart

Med anpassad JumpStart-kompatibilitet kan du lägga till och ta bort paket medan de är en del av traditionella installationsverktygen för Solaris, som är de följande:

• Anpassad JumpStart

• programmet Solaris suninstall

• Installationsmetoden Solaris Web Start

Med anpassad JumpStart-kompatibilitet kan paketet vara med i Solaris-uppgraderingar. För att ett paket ska vara kompatibelt med programmet anpassad JumpStart måste det också uppfylla kraven för inaktiva startmiljöer som beskrivs i Krav för inaktiv startmiljö för anpassad JumpStart och Solaris Live Upgrade .

Om du vill använda anpassad JumpStart så effektivt som möjligt, måste paket läggas till och tas bort utan att användaren ombeds lämna information. Om du vill undvika användarinteraktion konfigurerar du en ny administrationsfil med kommandot pkgadd och alternativet -a. Alternativet -a definierar en installationsadministrationsfil som ska användas i stället för standardadministrationsfilen. Om du använder standardfilen kan det hända att användaren ombeds lämna mera information. Du kan skapa en administrationsfil som talar om för pkgadd att den ska hoppa över kontrollerna och installera paket utan användarbekräftelse. Om du vill ha detaljerad information läser du direkthjälpen (man pages) admin(4) eller pkgadd(1M).

Följande exempel visar hur du använder administrationsfilen för pkgadd.

• Om det inte finns någon administrationsfil, använder pkgadd /var/sadm/install/admin/default. Om du använder den här filen kan det orsaka användarinteraktion.

  # pkgadd

• Om en relativ administrationsfil finns på kommandoraden, letar pkgadd i /var/sadm/install/admin efter filnamnet och använder det. I det här exemplet heter den relativa administrationsfilen nocheck och pkgadd letar efter /var/sadm/install/admin/nocheck .

  # pkgadd -a nocheck

• Om en absolut fil finns använder pkgadd den. I det här exemplet letar pkgadd efter administrationsfilen nocheck i /tmp.

  # pkgadd -a /tmp/nocheck

Följande är ett exempel på en installationsadministrationsfil som kräver mycket lite användarinteraktion med verktyget pkgadd. Om inte paketet kräver mer utrymme än vad som finns tillgängligt på systemet, använder verktyget pkgadd den här filen och installerar paketet utan att be användaren om information.

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