Nelle note di rilascio è possibile trovare informazioni aggiuntive sulle modifiche apportate rispetto alla release precedente di SUSE Linux Enterprise. Verificare se l'hardware in uso o la configurazione necessitano di considerazioni speciali, quali sono i pacchetti software preferiti che nello specifico hanno subito modifiche considerevoli e quali precauzioni si devono adottare oltre ai consigli generali indicati in questa sezione. Le note di rilascio contengono inoltre informazioni dell'ultimo minuto e problemi noti che non si è fatto in tempo a riportare nel manuale.

La versione attuale delle note di rilascio contenenti le informazioni più recenti su SUSE Linux Enterprise Server sono disponibili online alla pagina http://www.suse.com/doc/sles12/#start.

Prima di eseguire l'aggiornamento, copiare i file di configurazione esistenti su un supporto separato (ad esempio un dispositivo a nastro, un disco rigido rimovibile e così via) per eseguire il backup dei dati. Copiare in particolare i file archiviati in /etc e alcuni file e directory in /var e /opt. Può anche essere opportuno salvare i dati dell'utente contenuti /home (ovvero le directory HOME) su un supporto di backup. Eseguire il backup di questi dati come root. Infatti solo gli utenti root dispongono delle autorizzazioni di lettura per tutti i file locali.

Se in YaST si è selezionata la modalità di installazione Aggiornamento di un sistema esistente, è possibile scegliere di eseguire un backup (del sistema) in un momento successivo. È possibile includere tutti i file modificati e i file della directory /etc/sysconfig. Si tratta tuttavia di un backup parziale in quanto mancano tutte le altre directory importanti indicate sopra. Trovare il backup nella directory /var/adm/backup.

Prima di avviare il processo di aggiornamento, prendere nota della partizione root. Mediante il comando df / è possibile visualizzare l'elenco dei nomi dei dispositivi nella partizione root. Ad esempio, nell'Esempio 7.1, «Visualizzare l'elenco con il comando df -h», la partizione radice da trascrivere è /dev/sda3 (montata come /).

Filesystem     Size  Used Avail Use% Mounted on
/dev/sda3       74G   22G   53G  29% /
tmpfs          506M     0  506M   0% /dev/shm
/dev/sda5      116G  5.8G  111G   5% /home
/dev/sda1       44G    4G   40G   9% /data

I programmi tendono a «crescere» da una versione all'altra. Quindi, prima di effettuare un aggiornamento, controllare lo spazio disponibile sulla partizione mediante il comando df. Se lo spazio disponibile sul disco non è sufficiente, proteggere i dati prima di procedere all'aggiornamento e di ripartizionare il sistema. Non esiste una regola generale in merito allo spazio che deve essere disponibile in ogni partizione. I requisiti di spazio dipendono dal particolare profilo di partizionamento e dal software selezionato.

Se il computer funge da server host per macchine virtuali per KVM o Xen, assicurarsi di spegnere correttamente tutti i guest delle macchine virtuali prima dell'aggiornamento. altrimenti l'accesso ai guest dopo l'aggiornamento potrebbe risultare impossibile.

Per eseguire un aggiornamento online, è necessario che i seguenti requisiti siano soddisfatti. Assicurarsi di leggere anche Sezione 7.3, «Preparazione generale dell'aggiornamento».

Importante: migrazione online completa da eseguire sempre

La migrazione online deve essere completata sempre dall'inizio alla fine. L'interruzione di una migrazione online causerà la corruzione del sistema con impossibilità di recupero.

L'aggiornamento del sistema mediante la migrazione online viene effettuata dal sistema in esecuzione. È necessario solo riavviare una volta il sistema dopo aver completato l'aggiornamento.

7.4.4.1 Requisiti #

Per eseguire un aggiornamento online, è necessario che i seguenti requisiti siano soddisfatti. Assicurarsi di leggere anche Sezione 7.3, «Preparazione generale dell'aggiornamento».

Registrazione del prodotto

Per potersi connettere agli archivi di aggiornamento, è necessario che il prodotto sia registrato. In caso diverso, eseguire il modulo Configurazione di SUSE Customer Center in YaST oppure lo strumento della riga di comando suse_register per avviare la registrazione.

Esecuzione di un aggiornamento online

Assicurarsi che la versione attualmente installata disponga delle patch più recenti. Eseguire un aggiornamento prima della migrazione online. Quando si utilizza un'interfaccia grafica, avviare il modulo Aggiornamento online di YaST o l'applet del programma di aggiornamento. Nella riga di comando, eseguire i seguenti comandi (l'ultimo comando deve essere eseguito due volte):

zypper ref -s
zypper update -t patch
zypper update -t patch

Riavviare il sistema se necessario.

Vedere Chapter 1, YaST Online Update, Administration Guide o Section “Updating Software with Zypper”, Chapter 6, Managing Software with Command Line Tools, Administration Guide. per ulteriori informazioni sugli strumenti di aggiornamento online.

Software di terze parti

se l'impostazione coinvolge software di terze parti o software aggiuntivo, eseguire un test di questa procedura su un altro computer per verificare che le dipendenze non vengano danneggiate dall'aggiornamento;

Importante: migrazione online completa da eseguire sempre

La migrazione online deve essere completata sempre dall'inizio alla fine. L'interruzione di una migrazione online causa la corruzione del sistema con impossibilità di recupero.

7.4.4.2 Migrazione online con YaST Wagon #

Nota

La migrazione online con YaST Wagon è disponibile solo prima di SUSE Linux Enterprise Server 12.

1. Quando tutti i requisiti sono soddisfatti (vedere Sezione 7.4.4.1, «Requisiti»), nell'applet di aggiornamento della barra delle applicazioni verrà visualizzato un messaggio per indicare che l'upgrade di distribuzione è disponibile. Fare clic su di esso per avviare YaST Wagon. In alternativa, dalla riga di comando eseguire /usr/sbin/wagon come radice.

2. Confermare la finestra di dialogo di benvenuto facendo clic su Avanti.

3. Se Wagon rileva che i requisiti non sono soddisfatti (aggiornamenti di manutenzione disponibili ma non ancora installati) verrà eseguito un aggiornamento automatico per il quale potrebbe essere necessario il riavvio. Seguire le istruzioni visualizzate.

4. Scegliere il metodo di aggiornamento nella seguente finestra di dialogo. Scegliere Customer Center per utilizzare la configurazione di default (consigliata).

   Fare clic su URL personalizzato per scegliere manualmente gli archivi del software utilizzati per la migrazione online. Verrà visualizzato un elenco di archivi dal quale sarà possibile abilitare, disabilitare, aggiungere o eliminare manualmente gli archivi. Aggiungere le origini di aggiornamento SP2, che potrebbero essere il supporto di installazione SP2 o gli archivi SP2-Core e SP2-Updates. Fare clic su OK per tornare alla finestra di dialogo Modo di aggiornamento.

   Per rivedere le modifiche apportate alla configurazione dell'archivio causate dal processo di aggiornamento, selezionare Verifica modifiche automatiche archivio.

   Fare clic su Avanti per continuare.

5. Il sistema verrà registrato di nuovo. Durante questo processo, gli archivi SP2-Core e SP2-Updates verranno aggiunti al sistema (vedere Sezione 7.7.2, «Modello di archivio» per ulteriori informazioni). Confermare l'aggiunta degli archivi.

6. Se nella finestra di dialogo Modo di aggiornamento si è selezionato Verifica modifiche automatiche archivio, verrà visualizzato un elenco di archivi dal quale sarà possibile abilitare, disabilitare, aggiungere o eliminare manualmente gli archivi. Procedere con OK al termine dell'operazione.

7. Scegliere il tipo di migrazione:

   Migrazione completa

   Aggiorna tutti i pacchetti al livello SP2 più recente.

   Migrazione minima

   Aggiorna un insieme minimo di pacchetti al livello SP2 più recente.

   Fare clic su Avanzato per selezionare manualmente gli archivi utilizzati per l'upgrade.

   Confermare la selezione.

8. Si apre la schermata Impostazioni upgrade di distribuzione in cui viene presentato un riepilogo della configurazione dell'aggiornamento. Sono disponibili le seguenti sezioni:

   Prodotti aggiuntivi

   Qui è possibile aggiungere i prodotti aggiuntivi di SUSE Linux Enterprise Server o i prodotti di terze parti.

   Opzioni di aggiornamento

   Elenca le azioni che verranno eseguite durante l'aggiornamento. È possibile scegliere se effettuare il download di tutti i pacchetti prima di installarli (default, consigliato) o effettuare il download e scaricare un pacchetto alla volta.

   Pacchetti

   Panoramica statistica dell'aggiornamento.

   Backup

   Impostare le opzioni di backup.

   Fare clic su Avanti e Avvia l'aggiornamento per continuare.

   

   Importante: interruzione della migrazione online

   In questa schermata e in tutte quelle precedenti è possibile interrompere la migrazione online in modo sicuro prima di fare clic su Avvia l'aggiornamento. Fare clic su Interrompi per abbandonare la procedura di aggiornamento e ripristinare lo stato del sistema antecedente all'avvio di YaST Wagon. Seguire le istruzioni visualizzate ed eseguire una nuova registrazione prima di abbandonare Wagon per rimuovere gli archivi SP2 dal sistema.

9. Durante la procedura di aggiornamento vengono eseguiti i seguenti passaggi:

   1. I pacchetti saranno aggiornati.

   2. Il sistema verrà riavviato (premere OK).

   3. Verrà effettuata una nuova registrazione del sistema aggiornato di recente.

10. L'aggiornamento del sistema a Service Pack 2 è stato completato.

In alternativa alla migrazione online (vedere Sezione 7.4.4, «Migrazione online» per i dettagli) è inoltre possibile aggiornare il sistema effettuando l'avvio da un'origine di installazione, come un DVD o un'origine di installazione di rete. L'aggiornamento avrà inizio come una normale installazione.

È possibile ottenere le immagini ISO Service Pack 2 da http://download.suse.com/. Masterizzarle su un DVD o preparare un'origine di installazione di rete come descritto nella Sezione 14.2, «Configurazione del server contenente le origini dell'installazione».

In alternativa al download degli aggiornamenti per ogni singolo sistema client dal server di aggiornamento SUSE, è possibile utilizzare Subscription Management Tool (SMT) per SUSE Linux Enterprise per eseguire la copia speculare degli aggiornamenti in un server locale.

Questo strumento funge da proxy SUSE Customer Center sia per le registrazioni client sia come archivio di aggiornamento del software. La documentazione di SMT disponibile in http://www.suse.com/doc/smt11/ offre una panoramica delle rispettive funzioni, nonché le istruzioni per implementarle.

SUSE Manager è una soluzione server che fornisce aggiornamenti, patch e correzioni per la sicurezza dei client SUSE Linux Enterprise. Viene fornito in dotazione con un set di strumenti e un'interfaccia utente basata su Web per i task di gestione.

La documentazione relativa a SUSE Manager in http://www.suse.com/doc/suse_manager/ offre una panoramica delle funzioni del prodotto, nonché le istruzioni su come configurare server e client.

È possibile eseguire l'upgrade del sistema effettuando l'avvio da un'origine di installazione, sia da un DVD locale sia da un'origine di installazione di rete, come se si eseguisse una nuova installazione. Quindi nella schermata di avvio, selezionare semplicemente "Upgrade" invece di "Installa" per eseguire l'upgrade del sistema.

Per eseguire una migrazione automatica, procedere come indicato di seguito:

Eseguire multi-update. Questo comando esegue zypper in un ambiente chroot e aggiorna l'altro sistema: non importa quale sia attivo. Per default, al momento dell'avvio viene visualizzato il menu di avvio.

Se il sistema, dopo essere aggiornato, ha un boot loader danneggiato, è necessario modificare il flag «Attivo» e impostarlo per la partizione radice dell'altro sistema per avviarlo.

Se il sistema aggiornato non si avvia, per selezionare l'altro sistema è necessario accedere al menu di boot loader.

Per ulteriori informazioni su GRUB 2, vedere Chapter 12, The Boot Loader GRUB 2, Administration Guide.

La partizione radice deve essere montata in base al nome della partizione, all'ID o in un altro modo. Il montaggio in base all'UUID della partizione o all'etichetta non è supportato.

Per ulteriori informazioni, consultare /usr/share/doc/packages/multi-update-tools/README in dotazione con il pacchetto multi-update-tools.

L'intervallo per i livelli di supporto esteso inizia dal decimo anno e termina il tredicesimo anno. Prevedono diagnosi continuata del livello di engineering L3 e correzione reattiva dei bug critici. Questi livelli di supporto eseguono attivamente aggiornamenti di exploit radice locali facoltativi nel kernel o altri exploit radice direttamente eseguibili senza intervento dell'utente. Vengono inoltre supportati l'hardware, i workload e i software stack esistenti con un elenco di esclusione dei pacchetti limitato. Vedere Tabella 7.1, «Aggiornamenti di sicurezza e correzione dei problemi» per una panoramica di quanto descritto.

Il layout dell'archivio corrisponde ai cicli di vita del prodotto. Tabella 7.2, «Layout degli archivi per SUSE Linux Enterprise 11 SP2 e SP3 e per SUSE Linux Enterprise 12» contiene un elenco di tutti gli archivi da SUSE Linux Enterprise 11 SP2 a SUSE Linux Enterprise 12.

zypper repos -u

zypper removerepo SLES11-SP1-Pool SLES11-SP1-Updates \
    SLE11-SP1-Debuginfo-Pool SLE11-SP1-Debuginfo-Updates \
    SLES11-SP2-Core SLES11-SP2-Updates \
    SLE11-SP2-Debuginfo-Core SLES11-SP2-Extension-Store\
    SLE11-SP2-Debuginfo-Updates

zypper addrepo -n SLES11-SP2-Extension-Store \
    https://nu.novell.com/repo/\$RCE/SLES11-SP2-Extension-Store/nu_novell_com:SLES11-SP2-Extension-Store

Gli sviluppatori upstream sono interessati soprattutto all'avanzamento del software che sviluppano. In molti casi, insieme alla correzione dei bug introducono nuove funzioni non ancora testate adeguatamente e che possono comportare l'introduzione di nuovi bug.

Per gli sviluppatori di distribuzione, è importante saper distinguere tra:

Nella maggior parte dei casi, gli sviluppatori di distribuzione non seguono tutte le modifiche upstream dopo il rilascio di un pacchetto. Di solito rimangono fedeli alla versione upstream rilasciata inizialmente e creano patch basate sulle modifiche upstream per correggere i bug. Questa pratica è nota come backporting.

Di norma, gli sviluppatori di distribuzione si limitano a introdurre una versione più recente del software in due casi specifici:

In SUSE viene fatto un ampio uso di backport mentre si cerca di trovare un buon compromesso con le numerose preoccupazioni scaturite dal software aziendale. Tra queste, le principali riguardano:

Una regola generale delle policy prevede che nessuna nuova versione upstream di un pacchetto venga introdotta nei nostri prodotti per aziende. Si tratta tuttavia di una regola non assoluta. Per una classe limitata di pacchetti, in particolare i software antivirus, la sicurezza ha un peso maggiore rispetto all'approccio conservativo, che dal punto di vista del controllo della qualità è preferibile. Per i pacchetti di tale classe, occasionalmente le versioni più recenti vengono introdotte in una versione rilasciata di una linea di prodotti per aziende.

Talvolta anche per altri tipi di pacchetti la scelta volge sull'introduzione di una nuova versione piuttosto che su un backport, soprattutto quando quest'ultimo non è fattibile dal punto di vista economico oppure nel caso in cui i motivi tecnici sono di tale entità per cui è preferibile realizzare una versione nuova.

A causa del backporting, non è possibile confrontare semplicemente i numeri di versione per determinare se un pacchetto SUSE contiene una correzione a un determinato problema o se è stata aggiunta una particolare funzione. Con il backporting, la parte upstream del numero di versione di un pacchetto SUSE indica semplicemente la versione upstream sulla quale si base il pacchetto SUSE. Può contenere correzioni di bug e funzioni non presenti nella release upstream corrispondente, di cui però è stato effettuato il backporting nel pacchetto SUSE.

Un'area particolare in cui tale valore limitato dei numeri di versione quando è coinvolto il backporting può causare problemi con gli strumenti di scansione della sicurezza. Alcuni strumenti di scansione delle vulnerabilità della sicurezza (o particolari prove all'interno di tali strumenti) funzionano solamente sulle informazioni della versione. Tali strumenti/prove sono quindi inclini a generare «falsi positivi» (ad esempio, una parte di software risulta vulnerabile quando di fatto non lo è) quando sono coinvolti i backport. Nella valutazione dei rapporti sugli strumenti di scansione della sicurezza, si dovrebbe indagare sempre se una voce si basa su un numero di versione o su una prova effettiva dell'esistenza reale della vulnerabilità.

Vi sono numerose ubicazioni in cui sono memorizzate le informazioni relative a correzioni di bug e funzioni sottoposti a backport:

È possibile ricercare gli script nella directory /var/lib/YaST2/wagon/hooks/. Il nome dello script previsto è in formato passaggio_seq_prefisso_nome, dove:

/var/lib/YaST2/wagon/hooks/before_package_migration_00_postgresql_backup

Lo script deve restituire il valore di uscita 0. In caso contrario, (viene restituito un valore di uscita diverso da zero) in Wagon viene visualizzato un messaggio di errore ed è possibile riavviare lo script, ignorare l'errore (continuando con altri script) o annullare completamente gli agganci per il passaggio e la fase attuali.

Potenzialmente è possibile eseguire più volte gli script di aggancio (quando si passa da una finestra di dialogo all'altra di Wagon, questo potrebbe riavviarsi o è possibile che alcuni passaggi vengano eseguiti più volte nel workflow di migrazione), quindi gli script devono adeguarsi (possono verificare all'inizio se devono eseguire l'azione oppure se l'azione è già stata compiuta, possono creare un file di indicatori temporaneo o altrimenti risolvere più esecuzioni in modo appropriato).

Alcuni agganci sono facoltativi perché dipendono dai risultati precedenti o dai valori selezionati dall'utente. Si noti che alcuni agganci vengono denominati più volte (ad esempio la registrazione viene denominata prima e dopo la migrazione). Di seguito è riportato un elenco di agganci supportati (nomi di passaggi) nel rispettivo ordine di esecuzione:

Agganci di interruzione speciali che vengono richiamati quando l'utente interrompe la migrazione. È possibile richiamare tali agganci in qualsiasi passaggio del workflow di migrazione, pertanto l'ordine di esecuzione non è assicurato. Questi script devono verificare lo stato attuale se si affidano ai risultati di altri agganci.

Questi agganci vengono richiamati a ogni avvio di Wagon stesso.

L'elenco di agganci è piuttosto grande, ma molti di essi hanno senso solo in casi speciali. Nell'uso normale si dovrebbe dare la preferenza ai seguenti agganci:

Le versioni precedenti di Wagon supportavano solo due script di aggancio: /usr/lib/YaST2/bin/wagon_hook_init e /usr/lib/YaST2/bin/wagon_hook_finish. Il problema consisteva nel fatto che era possibile eseguire un solo script come aggancio ed era impossibile inserire gli agganci direttamente nei pacchetti RPM.

Questi script di aggancio precedenti sono ancora supportati nelle versioni più recenti di Wagon affinché siano compatibili con quelle precedenti, ma si devono utilizzare i nuovi agganci before_init e before_exit al posto di quelli precedenti.