 |
» |
|
|
 |
In questa sezione è descritto in dettaglio come sono eseguiti gli script di controllo. Dettagli comuni a tutti gli script di controllo |  |
L'agente è eseguito come superutente, gli script di controllo saranno perciò sempre eseguiti come superutente. Utilizzare quindi le precauzioni opportune. Gli script di controllo saranno eseguiti solamente nelle operazioni di installazione, rimozione o controllo del software nella root principale (“/”), oppure nella directory root alternativa. Gli script non saranno mai eseguiti per software nei depot. In ogni script è necessario impostare la sua variabile PATH, utilizzando SW_PATH. Né swinstall né swremove richiedono lo spegnimento del sistema. Gli script di controllo sono in grado di operare correttamente in sistemi a utente singolo inattivi, così come in sistemi multiutente attivi. Devono essere in grado di gestire nel modo corretto programmi in esecuzione che non possono essere rimossi. Per operare con successo, potrebbe essere necessario terminare o avviare dei processi di cui sono proprietari. Gli script di controllo possono essere eseguiti ripetutamente. Se lo script è eseguito più di una volta, in ogni occasione dovrà produrre lo stesso risultato. La seconda esecuzione non deve produrre messaggi di errore, oppure lasciare il sistema in una condizione diversa da quella precedente la sua esecuzione. Lo script deve essere eseguibile dopo il caricamento del suo set di file, senza danneggiare il nuovo set di file con cui è associato. Ad esempio, se è necessario copiare un file da /usr/newconfig in un'altra posizione, per copiarlo utilizzare il comando cpio -p invece di quello cp per spostarlo, oppure controllare la presenza effettiva della versione /usr/newconfig prima di tentarne lo spostamento. (È preferibile utilizzare il comando cpio(1) rispetto a quello cp(1) perché il primo copia le autorizzazioni di modalità, proprietario e gruppo.) Gli script di controllo al termine dell'operazione possono restituire uno dei seguenti valori: SUCCESS (0) – Operazione terminata senza errori e avvisi. ERROR (1) – Operazione terminata con errori gravi. WARNINGS (2) – Operazione terminata con avvisi. REBOOT (12) – Operazione terminata e segnala che è necessario il riavvio del sistema in seguito all'installazione del set di file. Questo valore restituito è valido solo per gli script checkinstall e checkremove per i set di file con l'attributo dynamic_module.
Tutti i messaggi prodotti dagli script di controllo saranno reindirizzati al file di log dell'agente. L'insieme degli script di controllo eseguiti durante una data fase o procedura sarà sempre eseguito nell'ordine di prerequisito; gli script del prodotto/set di file prerequisito saranno eseguiti prima degli script del set di file dipendente. Tutti gli script di controllo sono leggibili dagli altri script di controllo.
Script Checkinstall |  |
Gli script di controllo dell'installazione sono eseguiti durante la fase di analisi della sessione di swinstall. Il percorso dello script eseguito è: $ {SW_CONTROL_DIRECTORY}checkinstall Lo script checkinstall non deve modificare il sistema. Lo script checkinstall stabilisce se è possibile installare il prodotto o il set di file, eseguendo dei controlli ulteriori, oltre a quelli di swinstall. Tra gli esempi possibili di questi controlli c'è il controllo se il prodotto o set di file è correntemente in uso, oppure che il livello di esecuzione del sistema sia corretto. Se si sta utilizzando uno script di richiesta come parte dell'installazione, lo script checkinstall può: Controllare che il file di risposta esista. Prevenire il blocco di swinstall nel caso che: Lo script cerchi di leggere un file di risposta che non esiste, oppure L'installazione o la configurazione dipendano da informazioni che si trovano nel file di risposta.
Nel caso che lo script checkinstall fallisca, il set di file non sarà installato. L'interfaccia interattiva di swinstall notificherà all'utente che lo script checkinstall è fallito. Sarà quindi possibile: diagnosticare il problema, correggerlo ed eseguire nuovamente la fase di analisi; oppure deselezionare il prodotto o set di file. L'interfaccia non interattiva segnalerà all'utente gli errori di checkinstall ed i set di file non saranno installati. Lo script checkinstall è eseguito per le installazioni nella root principale (“/”) o in una root alternativa. Poiché la maggior parte delle azioni di questo script comporta il controllo delle condizioni correnti del sistema attivo, cioè della root principale, potrebbe non essere necessario eseguirle nel caso di installazione del prodotto o set di file in una root alternativa.
Script Preinstall |  |
Gli script di preinstallazione sono eseguiti durante la fase di caricamento della sessione di swinstall. Il percorso dello script eseguito è: $ {SW_CONTROL_DIRECTORY}preinstall Lo script preinstall è eseguito per un prodotto subito prima che siano installati i file di un set. Lo script preinstall deve eseguire delle procedure di preparazione specifiche per i file da installare. La sessione di swinstall proseguirà installando questi file, indipendentemente dal valore restituito dallo script preinstall. Esempi di azioni possibili comprendono la rimozione di file obsoleti (in una situazione di aggiornamento). Lo script preinstall è eseguito per le installazioni nella root principale (“/”) o in una root alternativa. La finalità delle azioni dello script preinstall dovranno riguardare il prodotto stesso, valere a dire i file della directory del prodotto.
Script Postinstall |  |
Gli script di postintallazione sono eseguiti durante la fase di caricamento della sessione di swinstall. Il percorso dello script eseguito è: $ {SW_CONTROL_DIRECTORY}postinstall Lo script postinstall è eseguito per un prodotto subito dopo l'installazione dei file di un set. Lo script postinstall deve eseguire delle procedure specifiche per i file appena installati. La sessione di swinstall proseguirà nel resto della sessione, ad esempio, con la configurazione, indipendentemente dal valore restituito dallo script postinstall. Tra gli esempi di azioni possibili vi è l'aggiunta ai file di sistema di un driver del kernel, oppure lo spostamento di un file da /usr/newconfig nella posizione corretta nel filesystem. Lo script postinstall è eseguito per le installazioni nella root principale (“/”) o in una root alternativa. La finalità delle azioni dello script postinstall dovranno riguardare il prodotto stesso, valere a dire i file della directory del prodotto. La personalizzazione o le procedure di configurazione, che devono essere eseguite per consentire l'uso generalizzato del prodotto o set di file, non devono essere fatte con lo script postinstall, ma da quello configure (descritto oltre).
Script Configure |  |
Gli script di configurazione sono eseguiti durante la fase di configurazione della sessione di swinstall. Nel caso che la sessione di swinstall attivi il riavvio del sistema, SD si attenderà degli script di configurazione all'avvio. Anche il comando swconfig è in grado di eseguire gli script di configurazione. Il percorso dello script eseguito è: $ {SW_CONTROL_DIRECTORY}configure Lo script configure è eseguito solamente per le installazioni nella root principale (“/”). Se nella sessione di swinstall si sceglie di rinviare la configurazione, lo script configure sarà eseguito in una sessione di swconfig, in un momento successivo all'installazione. Lo script configure è eseguito solamente quando il prodotto o set di file è nello stato di installato. Lo script configure è lo strumento principale per spostare un prodotto o set di file dallo stato di installato a quello di configurato. Lo script deve eseguire tutte, o la maggior parte delle azioni necessarie per abilitare l'uso del prodotto o set di file. Lo script configure può utilizzare le informazioni di configurazione fornite dall'utente e raccolte da uno script di richiesta. Quando si aggiorna la versione esistente di prodotto ad una più recente, gli script di configurazione della nuova versione devono eseguire la deconfigurazione o configurazione di quella precedente, operazioni necessarie per configurare la nuova versione. Gli script di deconfigurazione della versione precedente non saranno eseguiti. Gli script di configurazione eseguono azioni dipendenti dall'architettura, poiché saranno sempre eseguiti nel sistema di destinazione dell'installazione. Gli script di configurazione sono lo strumento migliore per la rimozione di file e per aggiornare il database dei prodotti installati, perché il sistema non è in uno stato transitorio, non è cioè un aggiornamento. Lo script configure serve sia con gli aggiornamenti software, sia con le nuove installazioni. Lo script deve inoltre essere in grado di gestire le reinstallazioni e, se è possibile la perdita di dati, comprendere il controllo degli errori.
Script Unconfigure |  |
Gli script di deconfigurazione sono eseguiti durante la fase di deconfigurazione e configurazione della sessione di swremove. Possono anche essere eseguiti dal comando swconfig. Il percorso dello script eseguito è: $ {SW_CONTROL_DIRECTORY}unconfigure Lo script unconfigure è eseguito solamente per il software installato nella root principale (“/”). Lo script unconfigure è rieseguito anche quando il prodotto o set di file è nello stato di configurato. Uno script unconfigure è lo strumento principale per riportare un prodotto o set di file dallo stato di configurato a quello di installato. Lo script deve eseguire tutte, o la maggior parte, delle azioni necessarie per disabilitare l'uso del prodotto o set di file. Uno script di deconfigurazione deve annullare tutte le operazioni di configurazione eseguite dallo script complementare. L'utente dovrebbe essere in grado di configurare, deconfigurare, configurare, ecc., un prodotto o set di file installato, ed alla fine ottenere sempre la stessa configurazione.
Script Verify |  |
Gli script verify sono eseguiti dal comando swverify. Il percorso dello script eseguito è: $ {SW_CONTROL_DIRECTORY}verify Lo script verify non deve modificare il sistema. Uno script di verifica è lo strumento principale per controllare la correttezza e la completezza delle operazioni di configurazione eseguite dallo script configure. Lo script verify è eseguito per le installazioni nella root principale (“/”) o in una root alternativa. Poiché la maggior parte delle azioni di questo script comporta il controllo delle condizioni correnti di un prodotto, o set di file configurato, nella root principale, potrebbe non essere necessario eseguirle nel caso di un prodotto o set di file installato in una directory root alternativa. Una variabile ambientale, SW_IS_COMPATIBLE, può essere d'ausilio allo script verify per stabilire se il software è compatibile con il sistema in cui è installato. Vedere “SW_IS_COMPATIBLE”.
Script Fix |  |
Gli script di correzione sono eseguiti dal comando swverify. Il percorso dello script eseguito è: $ {SW_CONTROL_DIRECTORY}fix È possibile utilizzare uno script fix per risolvere i problemi degli attributi rivelati dallo script verify. Uno script fix è in genere utilizzato per la creazione di directory mancanti, correzione di file modificati (modalità, proprietario, gruppo, maggiore, minore) e per il ripristino di collegamenti simbolici mancanti.
Script Checkremove |  |
Gli script di controllo della rimozione sono eseguiti durante la fase di analisi della sessione di swremove. Il percorso dello script eseguito è: $ {SW_CONTROL_DIRECTORY}checkremove Lo script checkremove non deve modificare il sistema. Lo script checkremove stabilisce se è possibile rimuovere il prodotto o il set di file, eseguendo dei controlli ulteriori a quelli di swremove. Tra gli esempi dei controlli possibili vi è la verifica se il prodotto o set di file è attualmente in uso. Nel caso che lo script checkremove fallisca, nessun set di file del prodotto sarà rimosso. L'interfaccia utente grafica o terminale di swremove notificherà all'utente che lo script checkremove è fallito. Sarà quindi possibile scegliere: diagnosticare il problema, correggerlo ed eseguire nuovamente la fase di analisi; deselezionare il sistema di destinazione in questione; oppure deselezionare il prodotto o set di file. L'interfaccia a riga dei comandi notifica all'utente ogni singolo errore di checkremove, e nessun set di file del prodotto sarà rimosso. Lo script checkremove è eseguito per le installazioni nella root principale (“/”) o in una root alternativa. Poiché la maggior parte delle azioni di questo script comporta il controllo delle condizioni correnti del sistema attivo, cioè della root principale, potrebbe non essere necessario eseguirle nel caso di rimozione del prodotto o set di file da una root alternativa.
Script Preremove |  |
Gli script di prerimozione sono eseguiti durante la fase di rimozione della sessione di swremove. Il percorso dello script eseguito è: $ {SW_CONTROL_DIRECTORY}preremove Tutti gli script preremove sono eseguiti per un prodotto subito prima che siano rimossi i suoi file. Lo script preremove deve eseguire delle procedure di preparazione specifiche per i file da rimuovere. La sessione di swremove proseguirà rimuovendo questi file, indipendentemente dal valore restituito dallo script preremove. Esempi delle azioni possibili comprendono la rimozione dei file creati dallo script postinstall. Lo script preremove è eseguito per le installazioni nella root principale (“/”) o in una root alternativa. La finalità delle azioni dello script preremove dovranno riguardare il prodotto stesso, valere a dire i file della directory del prodotto. L'annullamento delle operazioni di personalizzazione o di deconfigurazione/configurazione, che devono essere eseguite per disabilitare l'uso generalizzato del prodotto o set di file, non devono essere fatte con lo script preremove, ma da quello unconfigure (descritto prima).
Script Postremove |  |
Gli script di postrimozione sono eseguiti durante la fase di rimozione della sessione di swremove. Il percorso dello script eseguito è: $ {SW_CONTROL_DIRECTORY}postremove Tutti gli script postremove sono eseguiti per un prodotto subito dopo la rimozione dei file dei suoi set di file. Lo script postremove deve eseguire delle procedure specifiche per i file appena rimossi. La sessione di swremove proseguirà nel resto della sessione indipendentemente dal valore restituito dallo script postremove. Esempi delle azioni possibili sono: Eliminazione dei file che ancora rimangono dopo il completamento delle operazioni di rimozione di preremove e swremove. Eliminazione delle directory che sono di proprietà del set di file e che sono state svuotate dalla rimozione dei file.
Lo script postremove è eseguito per le installazioni nella root principale (“/”) ed in una root alternativa. La finalità delle azioni dello script postremove dovranno riguardare il prodotto stesso, valere a dire i file della directory del prodotto. L'annullamento delle operazioni di personalizzazione o di deconfigurazione/configurazione, che devono essere eseguite per disabilitare l'uso generalizzato del prodotto o set di file, non devono essere fatte con lo script postremove, ma da quello unconfigure (descritto prima).
Script Request |  |
Gli script di richiesta sono interattivi e richiedono durante le procedure di installazione o di configurazione una risposta da parte dell'utente. Il percorso dello script eseguito è: $ {SW_CONTROL_DIRECTORY}request Gli script di richiesta scrivono le informazioni della risposta in un file, per l'utilizzo in un momento successivo da parte dello script di configurazione o di altri script. È possibile eseguire gli script di richiesta seguendo il comando swask, oppure utilizzando l'opzione ask con swinstall o swconfig, dopo la selezione e prima della fase di analisi. L'impostazione predefinita POSIX per gli script di richiesta è uno script della shell. Lo script della shell deve essere in grado di: Rivolgere domande all'utente. Leggere la risposta dell'utente. Elencare tutte le risposte dell'utente corrente aggiornando lo schermo. Chiedere all'utente di confermare la risposta e proseguire, oppure tornare indietro.
Lo script di richiesta archivia le risposte dell'utente in un file di risposta. Il percorso del file di risposta è accessibile con la variabile ambientale SW_CONTROL_DIRECTORY. Il formato POSIX consigliato per file di risposta è il modello SVR4, con coppie attributo/valore. Le risposte devono essere scritte nel file di risposta nel formato variabile_ambientale=valore, in modo che questi file siano utilizzabili facilmente da altri script di controllo. Quando si utilizza uno script di richiesta per ottenere informazioni sull'installazione, HP consiglia l'utilizzo di uno script checkinstall per controllarne la corretta esecuzione. Lo script checkinstall deve: Controllare che il file di risposta esista. Prevenire il blocco di swinstall nel caso che: Lo script cerchi di leggere un file di risposta che non esiste. L'installazione o la configurazione dipendano da informazioni che si trovano nel file di risposta.
|