Appendice G Altri requisiti per i pacchetti 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 pacchetti, in particolare i pacchetti 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 pacchetti

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

• Perché il programma JumpStart personalizzato e Solaris Live Upgrade funzionino correttamente, è necessario che i pacchetti siano conformi ai requisiti dello standard SVR4. La Application Packaging Developer's Guide contiene informazioni più specifiche sui requisiti per la creazione dei pacchetti 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 pacchetti 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 pacchetti 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 pacchetti devono riconoscere e rispettare gli specificatori dell'ambiente di boot inattivo.

  I pacchetti possono includere percorsi assoluti nel file pkgmap (mappa dei pacchetti). Questi file, se presenti, vengono scritti in modo relativo all'opzione -R del comando pkgadd. I pacchetti 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 pacchetti 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 pacchetti 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 pacchetto deve scrivere tutte le directory e i file con il prefisso $PKG_INSTALL_ROOT. Il pacchetto 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 pacchetto. 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 pacchetto.

# pkgadd -R /a SUNWvxvm

$BASEDIR punta alla directory base relativa in cui vengono installati gli oggetti dei pacchetti. 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 pacchetti che non contengono oggetti riposizionabili vengono detti assoluti; in questi pacchetti, 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 pacchetto 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 pacchetti 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 pacchetti. È possibile creare quattro script procedurali con i seguenti nomi predefiniti: preinstall, postinstall, preremove e postremove. Gli script procedurali per la gestione dei pacchetti 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 pacchetti non devono richiamare comandi che siano stati aggiunti nelle versioni 2.6 e successive. Ad esempio, non devono richiamare il comando pgrep. Dopo la versione 2.6, molti comandi sono stati arricchiti con l'aggiunta di nuove funzioni. Gli script procedurali per la gestione dei pacchetti non devono usare le opzioni dei comandi che non esistevano nella versione 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 pacchetti devono superare la verifica con pkgchk. Prima di installare un pacchetto di nuova creazione, è necessario verificarlo con il comando seguente.

  # pkgchk -d directory pacchetto

  directory

  Specifica il nome della directory in cui si trova il pacchetto

  pacchetto

  Specifica il nome del pacchetto

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

  # pkgchk -d /export SUNWvxvm

  Il comando non dovrebbe restituire errori.

  I pacchetti 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 pacchetto, è 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 pacchetti non devono eseguire comandi forniti dal pacchetto 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 pacchetti. Oppure, è possibile usare il comando ps per provare la conformità dei daemon e verificare che nessun daemon venga arrestato o avviato dal pacchetto. I comandi truss, pkgadd -v e pkgrm possono verificare la conformità dell'installazione dei pacchetti 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 pacchetti 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 pacchetti possano essere inclusi negli aggiornamenti di Solaris. Per soddisfare i requisiti del programma JumpStart personalizzato, i pacchetti 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 pacchetti 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 pacchetto 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 pacchetto non richieda più spazio di quello disponibile sul sistema, l'utility pkgadd utilizza questo file e installa il pacchetto senza richiedere all'utente altre informazioni.

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