Prima di eseguire la migrazione, leggere il Capitolo 3, Preparazione dell'upgrade.

Importante: gli upgrade tra architetture non sono supportati

Gli upgrade tra architetture, come l'upgrade da una versione a 32 bit di SUSE Linux Enterprise Server a una versione a 64 bit, oppure l'upgrade da un big endian a un little endian non sono supportati.

Nello specifico, l'upgrade da SLE 11 su POWER (big endian) a SLE 15 SP2 su POWER (nuovo: little endian) non è supportato.

Inoltre, poiché SUSE Linux Enterprise 15 SP2 è disponibile solo nella versione a 64 bit, gli upgrade da qualsiasi sistema SUSE Linux Enterprise 11 a 32 bit a SUSE Linux Enterprise 15 SP2 e versioni successive non sono supportati.

Per eseguire un upgrade tra architetture, è necessario eseguire una nuova installazione.

Nota: Service Pack ignorati

L'installazione consecutiva di tutti i Service Pack è il percorso di upgrade più semplice. Per la linea di prodotti SUSE Linux Enterprise 15 (GA e i Service Pack successivi) è possibile ignorare un Service Pack durante l'upgrade. Ad esempio, è possibile eseguire l'upgrade da SLE 15 GA a 15 SP2 o da SLE 15 SP1 a 15 SP3.

Nota: upgrade delle release principali

Si consiglia di eseguire una nuova installazione quando si esegue l'upgrade a una nuova release principale, ad esempio da SUSE Linux Enterprise 12 a SUSE Linux Enterprise 15.

Figura 1.1: Panoramica dei percorsi di upgrade supportati #

 

SUSE supporta i seguenti metodi di upgrade e migrazione. Per ulteriori informazioni sulla terminologia, vedere Sezione 2.1, «Terminologia». Tali metodi sono:

Importante: client SUSE Manager

Se il computer è gestito da SUSE Manager, aggiornarlo come descritto nella documentazione di SUSE Manager. La procedura per la migrazione del client è descritta in SUSE Manager Upgrade Guide (Guida all'upgrade di SUSE Manager), disponibile all'indirizzo https://documentation.suse.com/suma/.

In questa sezione vengono utilizzati diversi termini. Per comprendere le informazioni, leggere le definizioni riportate di seguito:

I cicli di vita dei prodotti SUSE sono i seguenti:

SUSE supporta i Service Pack precedenti per i sei mesi successivi al rilascio del nuovo Service Pack. Figura 2.1, «Release principali e service pack» illustra alcuni degli aspetti indicati.

Figura 2.1: Release principali e service pack #

 

Se è necessario più tempo per progettare, convalidare e testare i piani di upgrade, con Long Term Service Pack Support è possibile estendere il supporto di ulteriori intervalli di 12 mesi, fino ad arrivare a 36 mesi aggiuntivi. In tal modo è possibile disporre di un supporto totale che va da 2 fino a 5 anni su qualsiasi Service Pack. Per informazioni, vedere Figura 2.2, «Supporto a lungo termine per service pack (LTSS)».

Figura 2.2: Supporto a lungo termine per service pack (LTSS) #

 

Per ulteriori informazioni, fare riferimento al https://www.suse.com/products/long-term-service-pack-support/.

Per ulteriori informazioni sul ciclo di vita, sulla frequenza dei rilasci e sul periodo di supporto, fare riferimento a https://www.suse.com/lifecycle.

Per un elenco dei moduli con le rispettive dipendenze e cicli di vita, vedere Article “Modules and Extensions Quick Start”.

SUSE Linux Enterprise Server può verificare regolarmente le modifiche allo stato del supporto di tutti i prodotti installati e inviare il relativo rapporto tramite e-mail in caso di modifiche. Per generare il rapporto, installare zypper-lifecycle-plugin con zypper in zypper-lifecycle-plugin.

Abilitare la generazione di rapporti sul proprio sistema con il comando systemctl:

root # systemctl enable lifecycle-report

Il destinatario e l'oggetto dell'e-mail contenente il rapporto, nonché il suo periodo di generazione possono essere configurati nel file /etc/sysconfig/lifecycle-report con qualsiasi editor di testo. Le impostazioni MAIL_TO e MAIL_SUBJ definiscono il destinatario e l'oggetto dell'e-mail, mentre DAYS imposta l'intervallo di generazione del rapporto.

Nel rapporto sono visualizzate le modifiche allo stato del supporto dopo che queste hanno avuto luogo e non prima. Se la modifica ha luogo subito dopo la generazione dell'ultimo rapporto, si potrebbe dover attendere fino a 14 giorni prima di ricevere la notifica sulla modifica. Tenere presente quanto detto sopra quando si imposta l'opzione DAYS. Modificare le seguenti voci di configurazione in base ai propri requisiti:

MAIL_TO='root@localhost'
MAIL_SUBJ='Lifecycle report'
DAYS=14

Il rapporto più recente è disponibile nel file /var/lib/lifecycle/report. Questo file contiene due sezioni. Nella prima sezione l'utente viene informato in merito alla fine del supporto per i prodotti utilizzati. Nella seconda sezione sono elencati i pacchetti unitamente alle relative date di fine supporto e disponibilità dell'aggiornamento.

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. Con questi livelli di supporto si riceveranno aggiornamenti per exploit radice non facilmente sfruttabili e altri exploit radice direttamente eseguibili senza intervento da parte dell'utente. Vengono inoltre supportati l'hardware, i workload e i software stack esistenti con un elenco di esclusione dei pacchetti limitato. Vedere Tabella 2.1, «Aggiornamenti di sicurezza e correzione dei problemi» per una panoramica di quanto descritto.

In fase di registrazione il sistema riceve archivi dal SUSE Customer Center (vedere https://scc.suse.com/) o da un proxy di registrazione locale come SMT. All'interno del Customer Center, i nomi degli archivi sono associati a URI specifici. Per visualizzare un elenco di tutti gli archivi disponibili nel sistema, utilizzare zypper come indicato di seguito:

root # zypper repos -u

In tal modo si ottiene un elenco di tutti gli archivi disponibili nel sistema. Ogni archivio viene elencato secondo il rispettivo alias, nome e a seconda che sia abilitato e venga aggiornato. L'opzione -u fornisce inoltre l'URI di origine del canale.

Per registrare il computer, eseguire SUSEConnect, ad esempio:

root # SUSEConnect -r REGCODE

Per annullare la registrazione del computer, è possibile utilizzare anche SUSEConnect:

root # SUSEConnect --de-register

Per verificare i prodotti installati localmente e il relativo stato, utilizzare il comando seguente:

root # SUSEConnect -s

Se è necessario identificare la versione di un'installazione SLE, controllare il contenuto del file /etc/os-release.

Con zypper è disponibile un output XML leggibile dal computer:

tux > zypper --no-remote --no-refresh --xmlout --non-interactive products -i
<?xml version='1.0'?>
<stream>
<product-list>
<product name="SLES" version="15" release="0" epoch="0" arch="x86_64" vendor="SUSE" summary="SUSE Linux Enterprise Server 15" repo="@System" productline="sles" registerrelease="" shortname="SLES15" flavor="" isbase="true" installed="true"><endoflife time_t="0" text="0"/><registerflavor/><description>SUSE Linux Enterprise offers [...]</description></product>
</product-list>
</stream>

L'upgrade del sistema è supportato solo dal livello di patch più recente. Assicurarsi che siano installati gli ultimi aggiornamenti del sistema eseguendo zypper patch o avviando il modulo YaST Online-Update.

Nelle note di rilascio è possibile trovare informazioni aggiuntive sulle modifiche apportate rispetto alla release precedente di SUSE Linux Enterprise Server. Controllare le note di rilascio per vedere se:

Le note di rilascio forniscono inoltre informazioni che non si è fatto in tempo a riportare nel manuale. Contengono anche alcune note su problemi noti.

Se si ignora uno o più Service Pack, controllare anche nelle note di rilascio le informazioni relative al Service Pack ignorato. In genere le note di rilascio contengono solo le differenze tra due release consecutive. Se si leggono solo le note di rilascio attuali, si potrebbero perdere importanti modifiche apportate rispetto alla release precedente.

Le attuali note di rilascio online sono disponibili in https://www.suse.com/releasenotes/.

In alternativa, è possibile trovare le note di rilascio nel DVD di installazione alla directory docu.

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. Questo vale soprattutto per i file memorizzati in /etc e per 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.

Spesso è utile salvare un elenco dei pacchetti installati, ad esempio quando si esegue una nuova installazione di una release principale di SLE o si ripristina la versione precedente.

È opportuno sapere che nelle release più recenti di SUSE Linux Enterprise, non tutti i pacchetti installati o gli archivi utilizzati sono disponibili. Alcuni potrebbero essere stati rinominati e altri sostituiti. È inoltre possibile che alcuni pacchetti siano ancora disponibili per poter essere utilizzati quando per default è in uso un altro pacchetto. Pertanto, potrebbe essere necessario apportare manualmente alcune modifiche ai file. A tal fine, è possibile utilizzare un editor di testo.

Creare un file denominato repositories.bak.repo contenente un elenco di tutti gli archivi utilizzati:

root # zypper lr -e repositories.bak

Creare anche un file denominato installed-software.bak contenente un elenco di tutti i pacchetti installati:

root # rpm -qa --queryformat '%{NAME}\n' > installed-software.bak

Eseguire il backup di entrambi i file. È possibile ripristinare gli archivi e i pacchetti installati con i seguenti comandi:

root # zypper ar repositories.bak.repo
root # zypper install $(cat installed-software.bak)

Nota: il numero di pacchetti aumenta con l'aggiornamento a una nuova release principale

Un sistema di cui si è eseguito l'upgrade a una nuova versione principale (SLE X+1) può contenere più pacchetti rispetto al sistema iniziale (SLE X). Contiene anche più pacchetti rispetto a una nuova installazione di SLE X+1 con la stessa selezione di modelli. I motivi di questo comportamento sono i seguenti:

• I pacchetti sono stati suddivisi per consentirne una selezione più granulare. Ad esempio, 37 pacchetti texlive su SLE 11 sono stati suddivisi in più di 3000 pacchetti su SLE 15.

• Quando un pacchetto viene suddiviso in più pacchetti, tutti i nuovi pacchetti vengono installati nell'upgrade, in modo da mantenere le stesse funzionalità della versione precedente. Per una nuova installazione di SLE X+1 è tuttavia possibile che il nuovo default sia di non installare tutti i pacchetti.

• È possibile che i pacchetti esistenti in SLE X siano stati mantenuti ai fini della compatibilità.

• Le dipendenze dei pacchetti e l'ambito dei modelli potrebbero essere stati modificati.

Se si utilizzano certificati basati su MySQL, PostgreSQL o Java MD5 in SUSE Linux Enterprise Server 11 SP4, preparare il sistema come descritto nelle sezioni seguenti.

3.5.2 Migrazione del database PostgreSQL #

 

Con SUSE Linux Enterprise Server 15 SP2 viene fornita una versione più recente del database PostgreSQL. A causa del lavoro richiesto per la migrazione del database, non è disponibile alcun processo di upgrade automatico. Il passaggio da una versione all'altra deve essere pertanto effettuato manualmente.

Il processo di migrazione viene eseguito mediante il comando pg_upgrade, un metodo alternativo al classico dump e ricaricamento. Rispetto al metodo «dump e ricaricamento», pg_upgrade, rende più rapida la migrazione.

I file di programma per ciascuna versione di PostgreSQL vengono memorizzati in directory diverse in base alla versione. Ad esempio, in /usr/lib/postgresql96/ per la versione 9.6 e in /usr/lib/postgresql10/ per la versione 10. Tenere presente che la policy del controllo versioni di PostgreSQL è stata modificata dalla versione principale 9.6 alla versione principale 10. Per informazioni, vedere https://www.postgresql.org/support/versioning/.

Importante: upgrade da SLE 11

Quando si esegue l'upgrade da SLE 11, postgresql94 verrà disinstallato e non sarà possibile utilizzarlo per la migrazione del database a una versione successiva di PostgreSQL. Pertanto, in questo caso assicurarsi di eseguire la migrazione del database PostgreSQL prima di eseguire l'upgrade del sistema.

Nella procedura riportata di seguito è descritta la migrazione del database dalla versione 9.6 alla 10. Quando si utilizza una versione diversa come avvio o destinazione, sostituire i numeri di versione di conseguenza.

Per eseguire la migrazione del database, procedere come segue:

1. Verificare che siano soddisfatte le seguenti condizioni preliminari:

   • Eseguire l'upgrade di tutti i pacchetti della versione precedente di PostgreSQL all'ultima release mediante un aggiornamento di manutenzione.

   • Creare una copia di backup del database esistente.

   • Installare i pacchetti della nuova versione principale di PostgreSQL. Per SLE 15 SP2 questo prevede l'installazione di postgresql10-server e di tutti i pacchetti da cui dipende.

   • Installare il pacchetto postgresql10-contrib contenente il comando pg_upgrade.

   • Verificare che sia disponibile spazio sufficiente nell'area dati di PostgreSQL, che per default è /var/lib/pgsql/data. Se lo spazio è limitato, provare a ridurre le dimensioni con il comando SQL seguente su ciascun database. Questa operazione può richiedere molto tempo:

     VACUUM FULL

2. Interrompere il server PostgreSQL in uno dei seguenti modi:

   root # /usr/sbin/rcpostgresql stop

   oppure

   root # systemctl stop postgresql.service

   (a seconda della versione SLE utilizzata come versione iniziale per l'upgrade).

3. Ridenominare la directory dei dati precedente:

   root # mv /var/lib/pgsql/data /var/lib/pgsql/data.old

4. Inizializzare la nuova istanza di database manualmente con il comando initdb o in modo automatico avviando e arrestando il server PostgreSQL:

   root # /usr/sbin/rcpostgresql start
   root # /usr/sbin/rcpostgresql stop

   oppure

   root # systemctl start postgresql.service
   root # systemctl stop postgresql.service

   (a seconda della versione SLE utilizzata come versione iniziale per l'upgrade).

5. Se i file di configurazione nella versione precedente sono stati modificati, si consiglia di riportare tali modifiche nei nuovi file di configurazione. Questo potrebbe avere un impatto sui file postgresql.auto.conf, postgresql.conf, pg_hba.conf e pg_ident.conf. Le versioni precedenti di questi file si trovano in /var/lib/pgsql/data.old/, mentre le nuove versioni sono disponibili in /var/lib/pgsql/data.

   Non è consigliabile limitarsi a copiare i file di configurazione precedenti, in quanto tale operazione può comportare la sovrascrittura delle nuove opzioni, delle nuove impostazioni di default e dei commenti modificati.

6. Avviare il processo di migrazione come utente postgres:

   root # su - postgres
   postgres > pg_upgrade \
     --old-datadir "/var/lib/pgsql/data.old" \
     --new-datadir "/var/lib/pgsql/data" \
     --old-bindir "/usr/lib/postgresql96/bin/" \
     --new-bindir "/usr/lib/postgresql10/bin/"

7. Avviare la nuova istanza del database in uno dei seguenti modi:

   root # /usr/sbin/rcpostgresql start

   oppure

   root # systemctl start postgresql.service

   (a seconda della versione SLE utilizzata come versione iniziale per l'upgrade).

8. Controllare che la migrazione sia stata eseguita correttamente. L'ambito della prova dipende da caso di utilizzo e non esistono strumenti generici per automatizzare questo passaggio.

9. Rimuovere tutti i pacchetti di PostgreSQL e la directory dei dati precedenti:

   root # zypper search -s postgresql96 | xargs zypper rm -u
   root # rm -rf /var/lib/pgsql/data.old

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.

Se il computer di cui si desidera effettuare l'upgrade è registrato come client di un server SMT, eseguire le seguenti operazioni:

Verificare che la versione dello script clientSetup4SMT.sh sull'host sia aggiornata. clientSetup4SMT.sh dalle versioni precedenti di SMT non è in grado di gestire i client SMT 12. Se si applicano regolarmente patch software sul server SMT, è sempre possibile trovare la versione più recente di clientSetup4SMT.sh in <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh.

Qualora l'upgrade del computer a una versione successiva di SUSE Linux Enterprise Server risultasse impossibile, annullare la registrazione del computer dal server SMT come descritto in Procedura 3.1. Riavviare quindi il processo di upgrade.

I programmi tendono a crescere da una versione all'altra. Quindi, prima di effettuare un aggiornamento, controllare lo spazio disponibile nella partizione. Se si teme di esaurire lo spazio su disco, eseguire il backup dei dati prima di incrementare lo spazio disponibile, ad esempio ridimensionando le partizioni. 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.

Nota: verifica automatica della disponibilità di spazio sufficiente in YaST

Durante la procedura di aggiornamento YaST controlla la quantità di spazio su disco disponibile su disco e visualizza un avviso se vi è la possibilità che l'installazione superi tale valore. In questo caso, l'aggiornamento potrebbe rendere inutilizzabile il sistema. È possibile ignorare l'avviso e continuare con l'aggiornamento solo se si sa esattamente cosa si sta facendo (sulla base dei test eseguiti in precedenza).

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

Per un server sul quale è in esecuzione un SMT, è necessaria una procedura di upgrade speciale. Fare riferimento al Book “Repository Mirroring Tool Guide”, Chapter 2 “Migrate from SMT to RMT” nella Repository Management Tool Guide (in lingua inglese).

SUSE Linux Enterprise Server consente l'installazione di più versioni del kernel, abilitando le impostazioni corrispondenti in /etc/zypp/zypp.conf. Per eseguire l'upgrade di un Service Pack, il supporto di tale funzione deve essere temporaneamente disabilitato e può essere nuovamente abilitato al termine dell'aggiornamento. Per disabilitare il supporto di più versioni, trasformare in commento le righe corrispondenti in /etc/zypp/zypp.conf. Il risultato deve assomigliare a quello riportato di seguito:

#multiversion = provides:multiversion(kernel)
#multiversion.kernels = latest,running

Per riattivare la funzione al termine dell'aggiornamento, rimuovere i segni di commento. Per ulteriori informazioni sul supporto di più versioni, vedere Book “Guida alla distribuzione”, Chapter 21 “Installazione di più versioni del kernel”, Section 21.1 “Abilitazione e configurazione del supporto multiversione”.

Per l'upgrade di un'installazione SUSE Linux Enterprise su IBM Z necessario il parametro del kernel Upgrade=1, ad esempio tramite parmfile. Vedere Sezione 5.4, «Parmfile - Automazione della configurazione del sistema».

In SLES 12 per IBM POWER, per default il display manager è configurato in modo che non venga avviato un server X locale. In SLES 12 SP1 tale impostazione è stata invertita e ora il display manager avvia un server X.

Per evitare problemi durante l'upgrade, l'impostazione di SUSE Linux Enterprise Server non viene modificata automaticamente. Affinché il display manager avvii un server X dopo l'upgrade, modificare come segue l'impostazione DISPLAYMANAGER_STARTS_XSERVER in /etc/sysconfig/displaymanager:

DISPLAYMANAGER_STARTS_XSERVER="yes"

Prima di eseguire l'upgrade del sistema, leggere la Capitolo 3, Preparazione dell'upgrade.

Per eseguire l'upgrade del sistema, effettuare l'avvio da un'origine di installazione, con la stessa procedura che si utilizzerebbe per una nuova installazione. Tuttavia quando viene visualizzata la schermata di avvio, è necessario selezionare Esegui l'upgrade (anziché Installazione). È possibile avviare l'upgrade da:

Di seguito è descritta la procedura di avvio da un DVD, ma è possibile utilizzare anche un altro supporto di installazione locale come un'immagine ISO in un dispositivo di memorizzazione di massa USB. Il supporto e il metodo di avvio da selezionare dipendono dall'architettura del sistema e dalla presenza del BIOS tradizionale o dello UEFI nel computer.

Per avviare un upgrade da un'origine di installazione di rete, verificare che siano soddisfatti i seguenti requisiti:

Prima di eseguire l'upgrade del sistema, leggere la Capitolo 3, Preparazione dell'upgrade. Per eseguire una migrazione automatica, procedere come indicato di seguito:

Nota: SUSE Customer Center e connessione a Internet

Se il sistema di cui si desidera eseguire l'upgrade è registrato in SUSE Customer Center, assicurarsi di disporre di una connessione a Internet durante la procedura seguente.

1. Dopo avere avviato (da un supporto di installazione o dalla rete), selezionare la voce Upgrade nella schermata di avvio.

   

   Avvertimento: una scelta sbagliata può comportare una perdita di dati

   Assicurarsi di selezionare Upgrade in questa fase. Se si seleziona erroneamente Installazione, la partizione dati verrà sovrascritta con una nuova installazione.

   YaST avvia il sistema di installazione.

2. Nella schermata Benvenuti, scegliere Lingua e Tastiera. Fare clic su Avanti per continuare.

   YaST controlla le partizioni per i sistemi SUSE Linux Enterprise già installati.

3. Nella schermata Seleziona per l'aggiornamento selezionare la partizione di cui eseguire l'upgrade e fare clic su Avanti.

4. YaST monta la partizione selezionata e viene visualizzato il contratto di licenza del prodotto di cui è stato eseguito l'upgrade. Accettare la licenza per continuare.

5. Nella schermata Repository usati in precedenza, modificare lo stato dei repository. Tutti i repository vengono rimossi per impostazione predefinita. Se non sono stati aggiunti repository personalizzati, non modificare le impostazioni. I pacchetti per l'upgrade verranno installati dal DVD ed è possibile scegliere di abilitare i repository online predefiniti nel passaggio successivo.

   Se sono presenti repository personalizzati, è possibile scegliere tra due opzioni:

   • Lasciare il repository nello stato Rimosso. Il programma installato da questo repository verrà rimosso durante l'upgrade. Utilizzare questo metodo se non è disponibile nessuna versione del repository corrispondente alla nuova release.

   • Aggiornare e abilitare il repository se corrisponde alla nuova release. Modificarne l'URL facendo clic sul repository nell'elenco, quindi su Modifica. Abilitare il repository selezionando Cambia stato finché non viene impostato su Abilita.

   Non conservare i repository delle release precedenti, poiché il sistema potrebbe essere instabile o non funzionare. Continuare facendo clic su Avanti.

6. Il passaggio successivo dipende dall'avvenuta registrazione o meno del sistema sottoposto ad upgrade in SUSE Customer Center.

   1. Se il sistema non è registrato in SUSE Customer Center, in YaST viene visualizzato un messaggio popup che suggerisce di utilizzare un secondo supporto di installazione, ovvero l'immagine SLE-15-SP2-Full-ARCH-GM-media1.iso.

      Se non si dispone di tale supporto, è impossibile effettuare l'upgrade del sistema senza registrazione.

   2. Se il sistema è registrato in SUSE Customer Center, in YaST vengono visualizzati le destinazioni di migrazione possibili e un riepilogo.

      Selezionare una destinazione di migrazione dall'elenco e fare clic su Avanti per continuare.

7. Nella finestra di dialogo successiva è facoltativamente possibile aggiungere un ulteriore supporto di installazione. Se si dispone di supporti di installazione aggiuntivi, attivare l'opzione Desidero installare un ulteriore prodotto aggiuntivo e specificare il tipo di supporto.

8. Per l'upgrade, rivedere le Impostazioni di installazione.

9. Se le impostazioni sono quelle desiderate, avviare la procedura di installazione e rimozione facendo clic su Aggiorna.

   

   Suggerimento: errore di upgrade sui client SMT

   Se il computer di cui effettuare l'upgrade è un client SMT e l'upgrade risulta impossibile, vedere Procedura 3.1, «Annullamento della registrazione di un client SUSE Linux Enterprise da un server SMT» e ripetere la procedura di upgrade.

10. Al termine del processo di upgrade, eseguire i controlli post-upgrade come descritto in Sezione 4.4.1, «Controlli post-upgrade».

È possibile eseguire automaticamente il processo di upgrade. Per informazioni, vedere Book “AutoYaST Guide”, Chapter 4 “Configuration and Installation Options”, Section 4.10 “Upgrade”.

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. Per ulteriori informazioni su SUSE Manager, vedere https://www.suse.com/products/suse-manager/.

Con SUSE Manager è possibile eseguire un upgrade del sistema. Con la tecnologia AutoYaST integrata, è possibile effettuare upgrade da una versione principale a quella successiva.

Se il computer è gestito da SUSE Manager, aggiornarlo come descritto nella documentazione di SUSE Manager. La procedura per la migrazione del client è descritta in SUSE Manager Upgrade Guide (Guida all'upgrade di SUSE Manager), disponibile all'indirizzo https://documentation.suse.com/suma/.

Quando si esegue l'upgrade di un Service Pack, è necessario modificare la configurazione nel server di registrazione per consentire l'accesso ai nuovi archivi. Se il processo di upgrade viene interrotto o annullato (tramite il ripristino da un backup o da uno snapshot), le informazioni sul server di registrazione sono incoerenti con lo stato del sistema. Questo potrebbe impedire l'accesso agli archivi di aggiornamenti o comportare l'uso di archivi scorretti nel client.

Quando si esegue un rollback tramite Snapper, il sistema invia una notifica al server di registrazione per garantire che durante il processo di avvio venga configurato l'accesso agli archivi corretti. Se il sistema è stato ripristinato con un altro metodo o la comunicazione con il server di registrazione è risultata impossibile, attivare il rollback sul client manualmente. L'attivazione di un rollback manuale può essere eseguita, ad esempio, quando il server non è accessibile a causa di problemi di rete. Per il rollback, eseguire:

tux > sudo snapper rollback

È consigliabile verificare sempre che nel sistema siano configurati gli archivi corretti, soprattutto dopo un aggiornamento del servizio tramite:

tux > sudo zypper ref -s

Questa funzionalità è disponibile nel pacchetto rollback-helper .

Se il sistema non è stato registrato prima dell'upgrade, è possibile farlo in qualsiasi momento utilizzando il modulo Registrazione del prodotto in YaST.

La registrazione dei sistemi comporta i seguenti vantaggi:

SUSE rilascia Service Pack per la famiglia SUSE Linux Enterprise a intervalli regolari. Per semplificare la migrazione a un nuovo Service Pack da parte dei clienti e ridurre al minimo il tempo di inattività, SUSE supporta la migrazione online mentre il sistema è in esecuzione.

A partire da SLE 12 , YaST Wagon è stato sostituito dalla migrazione di YaST (tramite GUI) e dalla migrazione di Zypper (dalla riga di comando). Ciò comporta i vantaggi seguenti:

Avvertimento: migrazione online non supportata per le release principali

La migrazione online è supportata solo per eseguire la migrazione tra Service Pack. La migrazione online non è supportata per eseguire l'upgrade alle nuove versioni principali. Per informazioni, vedere Capitolo 1, Metodi e percorsi di upgrade.

Utilizzare la migrazione offline per eseguire l'upgrade a una nuova release principale. Per informazioni, vedere Capitolo 4, Upgrade offline.

Importante: upgrade dei client SUSE Manager

Se il sistema da sottoporre ad upgrade è un client SUSE Manager, è impossibile eseguire l'upgrade tramite la migrazione online YaST o zypper migration. Seguire invece la procedura per la migrazione del client. Tale procedura è descritta in SUSE Manager Upgrade Guide (Guida all'upgrade di SUSE Manager).

Per eseguire la migrazione di un Service Pack è possibile utilizzare YaST, zypper o AutoYaST.

Prima di iniziare la migrazione di un Service Pack è necessario registrare il sistema in SUSE Customer Center o in un server RMT locale. È possibile utilizzare anche SUSE Manager.

Indipendentemente dal metodo, una migrazione del Service Pack consiste nei seguenti passaggi:

L'elenco delle destinazioni di migrazione dipende dai prodotti installati e registrati. Se è installata un'estensione per cui non è ancora disponibile il nuovo Service Pack, è possibile che non venga resa disponibile alcuna destinazione.

L'elenco delle destinazioni di migrazione disponibili per l'host in uso viene sempre recuperato da SUSE Customer Center e dipende dalle estensioni o dai prodotti installati.

La migrazione di un Service Pack può essere annullata solo in alcune fasi specifiche del processo di migrazione:

Per eseguire la migrazione di un Service Pack con YaST, utilizzare lo strumento Migrazione online. Per default, YaST non installa i pacchetti da un archivio di terze parti. Se un pacchetto è stato installato da un archivio di terze parti, YaST impedisce che il pacchetto venga sostituito con lo stesso pacchetto proveniente da SUSE.

Nota: ridurre la dimensione dell'installazione

Quando si esegue la migrazione di un Service Pack, YaST installa tutti i pacchetti consigliati. Soprattutto nel caso di un'installazione minima personalizzata, questo può aumentare notevolmente la dimensione dell'installazione del sistema.

Per modificare questo comportamento di default e consentire solo i pacchetti necessari, regolare l'opzione solver.onlyRequires in /etc/zypp/zypp.conf.

solver.onlyRequires = true

Modificare inoltre il file /etc/zypp/zypper.conf e l'opzione installRecommends.

installRecommends=false

Questo modifica il comportamento di tutte le operazioni sui pacchetti, come l'installazione di patch o nuovi pacchetti. Per modificare il comportamento di Zypper per una singola chiamata, aggiungere il parametro --no-recommends alla riga di comando.

Per avviare la migrazione di un Service Pack, procedere come segue:

Per eseguire la migrazione di un Service Pack con Zypper, utilizzare lo strumento a riga di comando zypper migration dal pacchetto zypper-migration-plugin.

Nota: ridurre la dimensione dell'installazione

Quando si esegue la migrazione di un Service Pack, YaST installa tutti i pacchetti consigliati. Soprattutto nel caso di un'installazione minima personalizzata, questo può aumentare notevolmente la dimensione dell'installazione del sistema.

Per modificare questo comportamento di default e consentire solo i pacchetti necessari, regolare l'opzione solver.onlyRequires in /etc/zypp/zypp.conf.

solver.onlyRequires = true

Modificare inoltre il file /etc/zypp/zypper.conf e l'opzione installRecommends.

installRecommends=false

Questo modifica il comportamento di tutte le operazioni sui pacchetti, come l'installazione di patch o nuovi pacchetti. Per modificare il comportamento di Zypper per una singola chiamata, aggiungere il parametro --no-recommends alla riga di comando.

Per avviare la migrazione di un Service Pack, procedere come segue:

Se il sistema non è registrato perché non si dispone dell'accesso a Internet o a un server di registrazione, non è possibile eseguire la migrazione a un nuovo Service Pack con la migrazione YaST o zypper migration. In questo caso, è comunque possibile eseguire la migrazione a un nuovo Service Pack con Zypper semplice e alcune interazioni manuali.

Importante: solo per i sistemi non registrati

Questo percorso di migrazione a un nuovo Service Pack è supportato soltanto per i sistemi non registrati che non dispongono dell'accesso a Internet o a un server di registrazione. Questo potrebbe essere ad esempio il caso dei computer che si trovano in reti con protezione speciale. Se si dispone di un sistema registrato, utilizzare la migrazione YaST o Zypper.

Importante: origini di installazione

Per utilizzare questo percorso di migrazione, è necessario fornire le origini di installazione del nuovo Service Pack in una posizione accessibile dal computer di cui si sta eseguendo la migrazione. A questo scopo è ad esempio possibile configurare un server RMT o SLP.

È inoltre necessario che il sistema disponga dell'accesso a un repository di aggiornamento aggiornato della versione del prodotto installata.

Se un Service Pack non è adatto alle proprie esigenze, SUSE Linux Enterprise supporta il ripristino del sistema allo stato precedente l'avvio della migrazione del Service Pack. Il prerequisito è una partizione radice Btrfs con istantanee abilitate (questa è l'impostazione predefinita a partire da SLES 12). Per ulteriori informazioni, vedere Book “Administration Guide”, Chapter 7 “System Recovery and Snapshot Management with Snapper”.

Il sistema viene ripristinato allo stato acquisito immediatamente prima dell'avvio della migrazione del Service Pack.

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. Per ulteriori informazioni su SUSE Manager, vedere https://www.suse.com/products/suse-manager/.

La migrazione SP consente di eseguire la migrazione da un Service Pack (SP) a un altro all'interno di una versione principale (ad esempio, da SLES 15 GA a SLES 15 SP1).

Se il computer è gestito da SUSE Manager, aggiornarlo come descritto nella documentazione di SUSE Manager. La procedura per la migrazione del client è descritta in SUSE Manager Upgrade Guide (Guida all'upgrade di SUSE Manager), disponibile all'indirizzo https://documentation.suse.com/suma/.

È possibile eseguire l'upgrade di un'installazione openSUSE online a SUSE Linux Enterprise Server. La procedura è analoga a quella descritta nella Sezione 5.5, «Upgrade con Zypper», con alcuni passaggi aggiuntivi. Prima di eseguire questa procedura in un sistema di produzione, si consiglia di eseguirla su un sistema di test in cui è replicata la configurazione di produzione.

Per vedere per quali versioni openSUSE Leap è supportata la migrazione, consultare la Sezione 1.1, «Percorsi di upgrade a SLES 15 SP2 supportati».

Avvertimento: non tutti i pacchetti openSUSE possono essere sottoposti a migrazione

Gli archivi openSUSE forniscono più pacchetti rispetto a quelli disponibili in SUSE Linux Enterprise Server. Se si è installato uno di questi pacchetti, dopo la migrazione questo non riceverà più alcun aggiornamento. Per rimuovere questi pacchetti, attenersi alla procedura riportata di seguito.

Assicurarsi che tutti i pacchetti necessari per il sistema siano disponibili nell'archivio SUSE Linux Enterprise Server. È inoltre possibile verificare se i pacchetti sono disponibili nell'archivio SUSE Package Hub. Per informazioni, vedere Book “Guida alla distribuzione”, Chapter 20 “Installazione di moduli, estensioni e prodotti aggiuntivi di terze parti”, Section 20.3 “SUSE Package Hub”.

Per eseguire la migrazione da openSUSE Leap, attenersi alla procedura seguente:

Gli sviluppatori upstream sono interessati soprattutto all'avanzamento del software che sviluppano. Spesso, oltre a correggere i bug, introducono nuove funzioni non ancora testate adeguatamente, che possono determinare l'introduzione di nuovi bug.

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

In genere, gli sviluppatori della 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 ampio uso del backporting, nel tentativo di trovare un giusto equilibrio tra i numerosi problemi correlati al software aziendale, i più importanti dei quali sono:

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 alcuni tipi 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. Questi strumenti e test sono pertanto inclini a generare «falsi positivi» (quando una parte del software viene erroneamente identificata come vulnerabile) quando sono coinvolti i backport. Quando si valutano i rapporti con strumenti di scansione della sicurezza, verificare sempre se una voce si basa su un numero di versione o su un test della vulnerabilità effettivo.

Le informazioni relative a funzioni e correzioni dei bug sottoposte a backporting sono memorizzate in varie ubicazioni: