Si applica a SUSE Linux Enterprise Server 15 SP4

3 Preparazione dell'upgrade #

Prima di iniziare la procedura di upgrade, assicurarsi che il sistema sia preparato correttamente. Tra le altre cose, la preparazione prevede il backup dei dati e il controllo delle note di rilascio. Il seguente capitolo offre indicazioni su questa procedura.

3.1 Assicurarsi che il sistema sia aggiornato #

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

3.2 Lettura delle note di rilascio #

Nelle note di rilascio è presente un elenco di tutte le modifiche, delle nuove funzioni e dei problemi noti. Le note sono disponibili anche nella directory docu del supporto di installazione.

In genere le note di rilascio contengono solo le differenze tra due release consecutive. Se si ignora uno o più Service Pack, controllare anche nelle note di rilascio le informazioni relative al Service Pack ignorato.

Consultare le note di rilascio per verificare se si applica quanto segue:

L'hardware necessita di considerazioni speciali.
Sono state apportate modifiche significative a uno qualsiasi dei pacchetti software attualmente in uso
L'installazione richiede precauzioni speciali.

3.3 Esecuzione di un backup #

Prima dell'upgrade, eseguire un backup dei dati copiando i file di configurazione esistenti in un supporto distinto (ad esempio un dispositivo a nastro, un disco rigido rimovibile e così via). 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 tutti i dati come root. 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.

3.4 Verifica dello spazio su disco disponibile #

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

3.4.1 Verifica dello spazio su disco nei file system diversi da Btrfs #

Per visualizzare lo spazio disponibile su disco, utilizzare il comando df. Come nell'Esempio 3.1, «Visualizzare l'elenco con il comando df -h», la partizione radice è /dev/sda3 (montata come /).

Esempio 3.1: Visualizzare l'elenco con il comando df -h #

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

3.4.2 Verifica dello spazio su disco nei file system Btrfs #

Su un file system Btrfs, l'output di df può essere fuorviante, poiché oltre allo spazio allocato ai dati non elaborati, il file system Btrfs assegna e utilizza spazio anche per i metadati.

Di conseguenza, è possibile che venga visualizzato un messaggio di spazio esaurito nel file system Btrfs, anche se sembra che lo spazio ancora disponibile sia più che sufficiente. In questo caso, tutto lo spazio allocato ai metadati è stato utilizzato. Per dettagli su come verificare lo spazio in uso e disponibile su un file system Btrfs, vedere il Section 1.2.2.3, “Checking for free space”. Per maggiori informazioni, consultare man 8 btrfs-filesystem e https://btrfs.wiki.kernel.org/index.php/FAQ.

Se si utilizza Btrfs per i file system root sul computer, assicurarsi che lo spazio libero sia sufficiente. Verificare lo spazio disponibile su tutte le partizioni montate. Nel caso peggiore, per un upgrade è necessaria la stessa quantità di spazio su disco del file system radice attuale (senza /.snapshot) per un nuovo snapshot.

Sono stati comprovati i seguenti consigli:

Per tutti i file system, incluso Btrfs, è necessario spazio su disco sufficiente per effettuare il download e installare RPM di grandi dimensioni. Lo spazio occupato dagli RPM meno recenti viene liberato soltanto in seguito all'installazione di nuovi RPM.
Per il file system Btrfs con snapshot, è necessaria almeno la stessa quantità di spazio su disco richiesta per l'installazione corrente. È consigliabile avere a disposizione il doppio dello spazio occupato dall'installazione corrente.
Se lo spazio libero non è sufficiente, provare a eliminare gli snapshot precedenti con il comando snapper:
```
# snapper list
      # snapper delete NUMBER
```
Questa soluzione tuttavia potrebbe non funzionare in tutti i casi. Prima della migrazione, la maggior parte degli snapshot occupa una quantità ridotta di spazio.

3.5 Elenco dei pacchetti installati e dei repository #

È possibile 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.

Nota

È 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:
```
# zypper lr -e repositories.bak
```
Creare anche un file denominato installed-software.bak contenente un elenco di tutti i pacchetti installati:
```
# 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:
```
# zypper ar repositories.bak.repo
# 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.

3.6 Disabilitazione dell'estensione LTSS #

Se si esegue l'upgrade di un sistema SUSE Linux Enterprise Server con service pack (LTSS) a una versione ancora coperta da supporto generale, l'upgrade avrà esito negativo e sarà visualizzato l'errore No migration available (Nessuna migrazione disponibile). Ciò si verifica perché zypper migration tenta di migrare tutti i repository, ma ancora non ve n'è alcuno LTSS per la nuova versione.

Per correggere questo problema, disabilitare l'estensione LTSS prima dell'upgrade.

Verificare che l'estensione LTSS sia abilitata:

> sudo SUSEConnect --list-extensions | grep LTSS
SUSE Linux Enterprise Server LTSS 12 SP4 x86_64 (Installed)
Deactivate with: SUSEConnect -d -p SLES-LTSS/12.4/x86_64

Disabilitare l'estensione LTSS con il comando dell'output SUSEConnect riportato sopra:

> sudo SUSEConnect -d -p SLES-LTSS/12.4/x86_64
Deregistered SUSE Linux Enterprise Server LTSS 12 SP4 x86_64
To server: https://scc.suse.com/

Verificare che il repository LTSS non sia più presente con zypper lr.

3.7 Migrazione del database PostgreSQL #

SUSE Linux Enterprise Server 15 SP4 include le versioni 13 e 14 del database PostgreSQL. La versione 14 è quella predefinita, ma viene comunque fornita la versione 13 tramite il modulo Legacy per gli upgrade dalle versioni precedenti di SUSE Linux Enterprise Server.

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 di «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, in /usr/lib/postgresql10/ per la versione 10 e in /usr/lib/postgres13/ per la versione 13. 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 12 alla 13. 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:

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 SP4 ciò significa che occorre installare postgresql13-server e tutti i pacchetti da cui dipende.
- Installare il pacchetto postgresql13-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
```
Interrompere il server PostgreSQL in uno dei seguenti modi:
```
# /usr/sbin/rcpostgresql stop
```
oppure
```
# systemctl stop postgresql.service
```
(a seconda della versione SLE utilizzata come versione iniziale per l'upgrade).

Ridenominare la directory dei dati precedente:

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

Inizializzare la nuova istanza di database manualmente con il comando initdb o in modo automatico avviando e arrestando il server PostgreSQL:
```
# /usr/sbin/rcpostgresql start
# /usr/sbin/rcpostgresql stop
```
oppure
```
# systemctl start postgresql.service
# systemctl stop postgresql.service
```
(a seconda della versione SLE utilizzata come versione iniziale per l'upgrade).
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 copiare i file di configurazione precedenti, in quanto tale operazione può comportare la sovrascrittura delle nuove opzioni, delle nuove impostazioni predefinite e dei commenti modificati.

Avviare il processo di migrazione come utente postgres:

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

Avviare la nuova istanza del database in uno dei seguenti modi:
```
# /usr/sbin/rcpostgresql start
```
oppure
```
# systemctl start postgresql.service
```
(a seconda della versione SLE utilizzata come versione iniziale per l'upgrade).
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.

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

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

Per ulteriori informazioni sull'upgrade dei database o sull'utilizzo di metodi alternativi, come la replica logica, fare riferimento alla documentazione ufficiale di PostgreSQL all'indirizzo https://www.postgresql.org/docs/13/upgrading.html.

3.8 Migrazione del database MySQL o MariaDB #

A partire da SUSE Linux Enterprise 12, SUSE è passato da MySQL a MariaDB. Prima di iniziare un upgrade, si consiglia vivamente di eseguire il backup del database.

Per eseguire la migrazione del database, procedere come segue:

Creare un file di dump:
```
# mysqldump -u root -p --all-databases --add-drop-database > mysql_backup.sql
```
Per default, mysqldump non effettua il dump del database INFORMATION_SCHEMA o performance_schema. Per ulteriori informazioni, fare riferimento a https://mariadb.com/kb/en/mariadb-dumpmysqldump/.
Memorizzare in una posizione sicura il file di dump, il file di configurazione /etc/my.cnf e la directory /etc/mysql/ per analizzarli in seguito (non per l'installazione!).
Eseguire l'upgrade di SUSE Linux Enterprise Server. Dopo l'upgrade, il file di configurazione precedente /etc/my.cnf resta inalterato. È possibile trovare la nuova configurazione nel file /etc/my.cnf.rpmnew.
Configurare il database MariaDB in base alle proprie esigenze. Non utilizzare il file di configurazione e la directory precedenti, utilizzarlo invece come promemoria e adattarlo.
Avviare il server MariaDB:
```
# systemctl start mariadb
```
Se si desidera avviare il server MariaDB a ogni avvio, attivare il servizio:
```
# systemctl enable mariadb
```
Verificare che MariaDB sia in esecuzione connettendolo al database:
```
# mariadb -u root -p
```

3.9 Creare certificati server non MD5 per applicazioni Java #

Come misura di sicurezza, i certificati basati su MD5 non sono più supportati in Java. Se sono presenti certificati creati come MD5, ricrearli seguendo la procedura indicata:

Aprire un terminale ed eseguire il login come root.
Creare una chiave privata:
```
# openssl genrsa -out server.key 1024
```
Se si desidera una chiave più sicura, sostituire 1024 con un numero più alto, ad esempio, 4096.

Creare una richiesta di firma del certificato (CSR):

# openssl req -new -key server.key -out server.csr

Firmare il certificato:

# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Creare il file PEM:

# cat server.key server.crt > server.pem

Spostare i file server.crt, server.csr, server.key e server.pem nelle directory rispettive dove si trovano le chiavi. Per Tomcat, ad esempio, la directory è /etc/tomcat/ssl/.

3.10 Arresto dei guest delle macchine virtuali #

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

3.11 Regolazione della configurazione del client SMT #

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 nella Procedura 3.1. Riavviare quindi il processo di upgrade.

Procedura 3.1: Annullamento della registrazione di un client SUSE Linux Enterprise da un server SMT #

Eseguire il login sul computer client.

Il passaggio seguente dipende dal sistema operativo del client:

Per SUSE Linux Enterprise 11, eseguire i seguenti comandi:

> sudo suse_register -E
> sudo rm -f /etc/SUSEConnect
> sudo rm -rf /etc/zypp/credentials.d/*
> sudo rm -rf /etc/zypp/repos.d/*
> sudo rm -f /etc/zypp/services.d/*
> sudo rm -f /var/cache/SuseRegister/*
> sudo rm -f /etc/suseRegister*
> sudo rm -f /var/cache/SuseRegister/lastzmdconfig.cache
> sudo rm -f /etc/zmd/deviceid
> sudo rm -f /etc/zmd/secret

Per SUSE Linux Enterprise 12, eseguire i seguenti comandi:

> sudo SUSEConnect --de-register
> sudo SUSEConnect --cleanup
> sudo rm -f /etc/SUSEConnect
> sudo rm -rf /etc/zypp/credentials.d/*
> sudo rm -rf /etc/zypp/repos.d/*
> sudo rm -f /etc/zypp/services.d/*

Eseguire il login al server SMT.
Verificare che l'annullamento della registrazione del client sia stato completato visualizzando l'elenco di tutte le registrazioni client:
```
> sudo smt-list-registrations
```
Se il nome host del client risulta ancora nell'output del comando, ottenere l'ID univoco dalla prima colonna (nell'elenco potrebbero essere presenti più ID per il client).
Eliminare la registrazione per il client specificato:
```
> sudo smt-delete-registration -g UNIQUE_ID
```
Se nell'elenco risultano più ID per il client, ripetere il passaggio indicato sopra per ciascun ID univoco.
Verificare che l'annullamento della registrazione del client sia completato eseguendo nuovamente:
```
> sudo smt-list-registrations
```

3.12 Modifiche nei profili AutoYaST da SLE 12 a 15 #

Per ulteriori informazioni su come eseguire la migrazione dei profili AutoYaST, consultare il Appendix D, Differences between AutoYaST profiles in SLE 12 and 15.

3.13 Upgrade di un server SMT (Subscription Management Tool) #

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

3.14 Disabilitazione temporanea del supporto di più versioni del kernel #

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 Section 27.1, “Enabling and configuring multiversion support”.

3.15 Upgrade su IBM Z #

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.6, «Parmfile - Automazione della configurazione del sistema».

3.16 IBM POWER: avvio di un server X #

In SLES 12 per IBM POWER, per impostazione predefinita 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"