Appendice G Altri requisiti per i package SVR4 (riferimenti)

Questa appendice è destinata agli amministratori di sistema che intendano usare il programma JumpStart personalizzato o Solaris Live Upgrade per installare o rimuovere i package, in particolare i package di terze parti. Le indicazioni qui fornite permettono di eseguire l'installazione JumpStart personalizzata in modo automatico e di non modificare il sistema attualmente in uso, in modo da poter eseguire un aggiornamento con Solaris Live Upgrade.

Requisiti per i package

I seguenti documenti di riferimento forniscono informazioni generali sui requisiti per i package.

• Perché il programma JumpStart personalizzato e Solaris Live Upgrade funzionino correttamente, è necessario che i package siano conformi ai requisiti dello standard SVR4. La Application Packaging Developer's Guide contiene informazioni più specifiche sui requisiti per la creazione dei package e riferimenti sulla terminologia. Vedere in particolare il capitolo: “Advanced Package Creation Techniques” in Application Packaging Developer's Guide

• Per informazioni di riferimento sull'aggiunta e la rimozione dei package e sul file di amministrazione dell'installazione, vedere la sezione “Managing Software (Overview)” in System Administration Guide: Basic Administration. Vedere anche le pagine man dei singoli comandi.

• Per informazioni dettagliate sui comandi citati in questa appendice, vedere le pagine man dircmp(1), fssnap(1M), ps(1) o truss(1).

La Tabella G–1 contiene informazioni riguardanti sia Solaris Live Upgrade che il programma JumpStart personalizzato.

Requisiti per l'ambiente di boot inattivo con il programma JumpStart personalizzato e Solaris Live Upgrade

Un ambiente di boot inattivo è una copia dell'ambiente operativo, non del sistema attualmente in esecuzione. I package utilizzati da Solaris Live Upgrade o dal programma JumpStart personalizzato devono soddisfare i seguenti requisiti:

• Devono consentire un'installazione o un aggiornamento con il programma JumpStart personalizzato senza bisogno dell'interazione dell'utente

• Non devono modificare il sistema attualmente in uso, condizione necessaria per l'uso di Solaris Live Upgrade

Qui di seguito sono elencati i requisiti di conformità per l'ambiente di boot inattivo.

• Perché l'installazione del sistema operativo venga eseguita correttamente, i package devono riconoscere e rispettare gli specificatori dell'ambiente di boot inattivo.

  I package possono includere percorsi assoluti nel file pkgmap (mappa dei package). Questi file, se presenti, vengono scritti in modo relativo all'opzione - R del comando pkgadd. I package che contengono sia percorsi assoluti che percorsi relativi possono essere installati anche in un file system radice (/) alternativo. È necessario anteporre $PKG_INSTALL_ROOT sia ai file con percorso assoluto che a quelli con percorso relativo, in modo che tutti i percorsi vengano risolti correttamente durante l'installazione con pkgadd.

• I package installati con l'opzione -R di pkgadd o quelli rimossi con l'opzione -R di pkgrm non devono modificare il sistema attualmente in uso.

  Gli script procedurali eventualmente inclusi nei package installati con il comando pkgadd e l'opzione -R o in quelli rimossi con il comando pkgrm e l'opzione -R non devono modificare il sistema attualmente in uso. Negli script di installazione eventualmente utilizzati, tutte le directory e i file referenziati devono essere preceduti dalla variabile $PKG_INSTALL_ROOT. Il package deve scrivere tutte le directory e i file con il prefisso $PKG_INSTALL_ROOT. Il package non deve rimuovere le directory che non siano precedute dalla variabile $PKG_INSTALL_ROOT. La Tabella G–2 fornisce alcuni esempi di sintassi corretta per gli script.

  Tabella G–2 Esempi di sintassi per gli script di installazione

  Tipo di script	Sintassi corretta	Sintassi errata
  Frammenti di istruzioni “if” per la Bourne shell	if [ -f ${PKG_INSTALL_ROOT}\ /etc/prodotto.conf ] ; then	if [ -f /etc/prodotto.conf ] ; \ then
  Rimozione di un file	/bin/rm -f ${PKG_INSTALL_ROOT}\ /etc/prodotto.conf	/bin/rm -f /etc/prodotto.conf
  Modifica di un file	echo "test=no"> ${PKG_INSTALL_ROOT}\ /etc/prodotto.conf	echo "test=no"> \ /etc/prodotto.conf

Differenze tra $PKG_INSTALL_ROOT e $BASEDIR

$PKG_INSTALL_ROOT designa la posizione del file system radice (/) del sistema a cui viene aggiunto il package. La posizione viene impostata dall'argomento -R del comando pkgadd. Ad esempio, se viene eseguito il seguente comando, il valore di $PKG_INSTALL_ROOT diventa /a nell'installazione del package.

# pkgadd -R /a SUNWvxvm

$BASEDIR punta alla directory base relativa in cui vengono installati gli oggetti dei package. In questa posizione vengono installati solo oggetti “riposizionabili”, cioè con percorso relativo. Gli oggetti designati con un percorso assoluto nel file pkgmap vengono sempre installati relativamente all'ambiente di boot inattivo, ma non relativamente alla variabile $BASEDIR impostata. I package che non contengono oggetti riposizionabili vengono detti assoluti; in questi package, la variabile $BASEDIR non è definita e non è disponibile per gli script procedurali.

Ad esempio, si supponga che il file pkgmap contenga due righe:

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

E che il file pkginfo contenga una specifica per $BASEDIR:

BASEDIR=/opt

Se il package viene installato con il seguente comando, ls viene installato in /a/opt/sbin/ls, ma ls2 viene installato in /a/sbin/ls2.

# pkgadd -R /a SUNWtest

Requisiti dell'ambiente di boot inattivo per Solaris Live Upgrade

Durante l'uso di Solaris Live Upgrade per la creazione di un nuovo ambiente di boot, osservare le seguenti linee guida.

• Gli script procedurali per la gestione dei package devono essere indipendenti dall'ambiente operativo correntemente attivo. Gli script procedurali definiscono le azioni da eseguire in determinati momenti durante l'installazione o la rimozione dei package. È possibile creare quattro script procedurali con i seguenti nomi predefiniti: preinstall, postinstall, preremove e postremove. Gli script procedurali per la gestione dei package devono essere indipendenti dall'ambiente operativo corrente perché l'uso di Solaris Live Upgrade potrebbe attivare un ambiente di boot inattivo.

  • Questi script non devono avviare o arrestare processi, né devono dipendere dall'output di comandi come ps o truss, che a loro volta dipendono dal sistema operativo e restituiscono informazioni sul sistema correntemente in uso.

  • Gli script procedurali possono invece utilizzare liberamente altri comandi UNIX standard, come expr, cp, ls o altri comandi che facilitano la scrittura degli script per le shell. L'ambiente di boot inattivo non deve tuttavia essere modificato, se non seguendo le regole illustrate nella sezione Requisiti per l'ambiente di boot inattivo con il programma JumpStart personalizzato e Solaris Live Upgrade.

  • Tutti gli script devono essere scritti nella Bourne shell (/bin/sh). La Bourne shell è l'interprete usato dal comando pkgadd per eseguire gli script procedurali.

  • Gli script procedurali dei package non devono richiamare comandi che siano stati aggiunti nelle release 2.6 e successive. Ad esempio, non devono richiamare il comando pgrep. Dopo la release 2.6, molti comandi sono stati arricchiti con l'aggiunta di nuove funzioni. Gli script procedurali per la gestione dei package non devono usare le opzioni dei comandi che non esistevano nella release 2.6. Ad esempio, l'opzione -f del comando umount è stata aggiunta nella versione Solaris 7. Per verificare che un determinato comando o una determinata opzione siano supportati in Solaris 2.6, vedere il Solaris 2.6 Reference Manual AnswerBook su http://docs.sun.com.

• Tutti i package devono superare la verifica con pkgchk. Prima di installare un package di nuova creazione, è necessario verificarlo con il comando seguente.

  # pkgchk -d directory package

  directory

  Specifica il nome della directory in cui si trova il package

  package

  Specifica il nome del package

  Ad esempio, se un package si trova in /export/SUNWvxvm, occorre eseguire il comando seguente.

  # pkgchk -d /export SUNWvxvm

  Il comando non dovrebbe restituire errori.

  I package di nuova creazione devono essere provati con un'installazione in un ambiente di boot inattivo usando l'opzione -R directory di pkgadd. Dopo l'installazione del package, è necessario verificarne la correttezza usando pkgchk, come nell'esempio seguente.

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

  Il comando non dovrebbe restituire errori.

• Inoltre, i package non devono eseguire comandi forniti dal package stesso. Questa condizione ha lo scopo di mantenere la compatibilità dei client diskless e di evitare l'esecuzione di comandi che potrebbero richiedere librerie condivise non ancora installate.

Questi requisiti per la creazione, la modifica e l'eliminazione dei file possono essere verificati usando diversi comandi. Ad esempio, è possibile usare i comandi dircmp o fssnap per verificare il comportamento corretto dei package. Oppure, è possibile usare il comando ps per provare la conformità dei daemon e verificare che nessun daemon venga arrestato o avviato dal package. I comandi truss, pkgadd -v e pkgrm possono verificare la conformità dell'installazione dei package runtime, ma non funzionano in tutte le situazioni. Nell'esempio seguente, il comando truss non considera gli accessi in sola lettura a directory diverse da $TEMPDIR e restituisce solo gli accessi di altro tipo alle directory che non risiedono nell'ambiente di boot inattivo specificato.

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

Per maggiori informazioni sui comandi citati in questa sezione, vedere le pagine man dircmp(1), fssnap(1M), ps(1), truss(1), pkgadd(1M), pkgchk(1M) o pkgrm(1M).

Requisiti per l'aggiornamento con il programma JumpStart personalizzato

La conformità ai requisiti relativi al programma JumpStart personalizzato assicura che i package possano essere aggiunti e rimossi all'interno delle tradizionali utility di installazione di Solaris, vale a dire:

• Il programma JumpStart personalizzato

• Il programma suninstall di Solaris

• Il metodo di installazione Solaris Web Start

Assicura inoltre che i package possano essere inclusi negli aggiornamenti di Solaris. Per soddisfare i requisiti del programma JumpStart personalizzato, i package devono essere conformi anche ai requisiti per l'ambiente di boot inattivo descritti in Requisiti per l'ambiente di boot inattivo con il programma JumpStart personalizzato e Solaris Live Upgrade.

Per un uso efficiente del programma JumpStart personalizzato, i package devono essere aggiunti o rimossi in modo automatico, senza richiedere informazioni all'utente. Per evitare che sia richiesta l'interazione dell'utente, occorre configurare un nuovo file di amministrazione con il comando pkgadd e l'opzione -a. L'opzione -a definisce un file di amministrazione dell'installazione da usare al posto del file predefinito. Usando il file predefinito, è possibile che all'utente vengano richieste esplicitamente alcune informazioni. Per evitare che questo accada, si può creare un file di amministrazione che indichi a pkgadd di tralasciare questi controlli e di installare il package senza la conferma dell'utente. Per maggiori dettagli, vedere le pagine man admin( 4) o pkgadd( 1M).

L'esempio seguente spiega come usare il file di amministrazione per pkgadd.

• Se non viene specificato alcun file di amministrazione, pkgadd utilizza /var/sadm/install/admin/default. L'uso di questo file non esclude l'interazione con l'utente.

  # pkgadd

• Se viene specificato un file di amministrazione relativo, pkgadd cerca il file in /var/sadm/install/admin e lo utilizza. In questo esempio, viene specificato il file di amministrazione relativo nocheck e pkgadd ricerca /var/sadm/install/admin/nocheck.

  # pkgadd -a nocheck

• Se viene specificato un file con percorso assoluto, pkgadd usa il percorso specificato. In questo esempio, pkgadd ricerca in /tmp il file di amministrazione nocheck.

  # pkgadd -a /tmp/nocheck

L'esempio seguente mostra un file di amministrazione dell'installazione che richiede una minima interazione dell'utente con l'utility pkgadd. A meno che il package non richieda più spazio di quello disponibile sul sistema, l'utility pkgadd utilizza questo file e installa il package senza richiedere all'utente altre informazioni.

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