Ignora collegamenti di spostamento | |
Esci da visualizzazione stampa | |
Guida all'installazione di Oracle Solaris 10 8/11: Solaris Live Upgrade e pianificazione degli aggiornamenti |
Parte I Aggiornamento con Solaris Live Upgrade
1. Informazioni sulla pianificazione dell'installazione di Solaris
2. Solaris Live Upgrade (panoramica)
3. Solaris Live Upgrade (pianificazione)
4. Uso di Solaris Live Upgrade per creare un ambiente di boot (procedure)
5. Aggiornamento con Solaris Live Upgrade (procedure)
6. Ripristino dei guasti: ripristino dell'ambiente di boot originale (procedure)
7. Manutenzione degli ambienti di boot con Solaris Live Upgrade (procedure)
8. Aggiornamento del sistema operativo Oracle Solaris su un sistema con zone non globali
9. Solaris Live Upgrade (esempi)
10. Solaris Live Upgrade (riferimenti sui comandi)
Parte II Aggiornamento e migrazione con Solaris Live Upgrade a un pool root ZFS
11. Solaris Live Upgrade e ZFS (panoramica)
12. Solaris Live Upgrade per ZFS (pianificazione)
13. Creazione di un ambiente di boot per i pool root ZFS
14. Solaris Live Upgrade per ZFS in presenza di zone non globali
A. Soluzione dei problemi (procedure)
B. Altri requisiti per i pacchetti SVR4 (riferimenti)
Prevenzione delle modifiche al sistema operativo
Differenze tra $PKG_INSTALL_ROOT e $BASEDIR
Linee guida per la scrittura degli script
Prevenzione delle interazioni con l'utente durante l'installazione o l'aggiornamento.
Impostazione dei parametri dei pacchetti per le zone
C. Utilizzo dello strumento di analisi delle patch nell'aggiornamento (procedure)
Le indicazioni fornite in questa sezione permettono di mantenere invariato il sistema operativo attualmente in uso.
Perché l'installazione di un sistema operativo si svolga correttamente, è necessario che i pacchetti riconoscano e rispettino i file system root (/) alternativi, ad esempio l'ambiente di boot inattivo di Solaris Live Upgrade.
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 root (/) 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. Questa funzione è disponibile con il metodo JumpStart personalizzato, con Solaris Live Upgrade, con le zone non globali e con i client diskless.
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 B-1 fornisce alcuni esempi di sintassi degli script.
Tabella B-1 Esempi di sintassi per gli script di installazione
|
$PKG_INSTALL_ROOT designa la posizione del file system root (/) 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
Gli script contenenti le procedure da eseguire sui pacchetti devono essere indipendenti dal sistema operativo attualmente in uso, per impedire che quest'ultimo venga modificato. 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.
Tabella B-2 Linee guida per la creazione degli script
|
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.
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 dir_name pkg_name
Specifica il nome del pacchetto
Esempio B-1 Prova di un pacchetto
I pacchetti di nuova creazione devono essere provati con un'installazione in un file system root (/) alternativo 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.
Esempio B-2 Prova di un pacchetto su /export/SUNWvxvm
Se un pacchetto si trova in /export/SUNWvxvm, occorre eseguire il comando seguente.
# pkgchk -d /export SUNWvxvm
Il comando non dovrebbe restituire errori.
Sono inoltre disponibili altri comandi per verificare il pacchetto durante la creazione, la modifica e l'eliminazione dei file. Qui di seguito sono riportati alcuni esempi di questi 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}