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).