Appendice C Altri requisiti per i package (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.

Il file system radice (/) alternativo rappresenta una copia dell'ambiente operativo, non il sistema attualmente in uso.

Requisiti per i package

Perché il programma JumpStart personalizzato e Solaris Live Upgrade funzionino correttamente, è necessario che i package soddisfino i requisiti imposti da 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 C-1 contiene informazioni riguardanti sia Solaris Live Upgrade che il programma JumpStart personalizzato.

Requisiti per il file system radice (/) alternativo con il programma JumpStart personalizzato e Solaris Live Upgrade

Il file system radice (/) alternativo rappresenta una copia dell'ambiente operativo, non il sistema attualmente in uso. 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 per la conformità del file system radice (/) alternativo.

• Perché l'installazione di un sistema operativo venga eseguita correttamente, i package devono riconoscere e rispettare le specifiche del file system radice (/) alternativo.

  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 C-2 fornisce alcuni esempi di sintassi corretta per gli script.

  Tabella C-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 viene aggiunto ad /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 nel file system radice (/) alternativo, 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 alternativo per Solaris Live Upgrade

Quando si utilizza Solaris Live Upgrade e si crea un nuovo ambiente di boot, è consigliabile seguire le indicazioni qui fornite.

• 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 alternativo.

  • 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. Tuttavia, il file system radice (/) alternativo può essere modificato esclusivamente seguendo le regole descritte nella sezione "Requisiti per il file system radice (/) alternativo 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 per la gestione dei package non devono richiamare comandi che non esistevano nelle release anteriori alla 2.6. 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 è stata introdotta successivamente nel comando umount.

• 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 file system radice (/) alternativo 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 e pkgadd permettono di verificare la correttezza della procedura di installazione dei package in fase di esecuzione, ma il loro utilizzo è soggetto ad alcune restrizioni. Nell'esempio seguente, il comando truss non considera gli accessi in sola lettura a directory diverse da $BASEDIR e restituisce solo gli accessi di altro tipo alle directory che non risiedono nel file system radice (/) alternativo specificato.

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

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

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 Solaris suninstall

• 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 il file system radice (/) alternativo descritti in "Requisiti per il file system radice (/) alternativo 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 con la conferma dell'utente. 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 cerca il file /tmp/nocheck.

  # pkgadd -a /tmp/nocheck

L'esempio seguente mostra un file di amministrazione dell'installazione che impone a pkgadd di non richiedere conferma all'utente prima di installare il package.

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

Per maggiori dettagli, vedere le pagine man admin( 4) o pkgadd( 1M).