L’aggiornamento a SP1 di SLES 11 è relativamente semplice, a parte un paio di passaggi che non sono così evidenti come sarebbe auspicabile, ne particolarmente chiari.
Il riferimento alla documentazione http://www.novell.com/it-it/documentation/sles11/pdfdoc/book_sle_deploym... (cap. 7) e alle release notes, http://www.novell.com/linux/releasenotes/x86_64/SUSE-SLES/11/, è certamente d’aiuto. Purtroppo la traduzione in italiano lascia a desiderare.
L’upgrade inizia con la macchina SMT. Prima è bene completare gli aggiornamenti SLES11 specie le patch
I comandi zypper (per ora l’ultima modalità, fra le tante –rug, yup, zen- per aggiornare e manutenere il software) sono comodi per verificare lo stato e gli aggiornamenti disponibili.
zypper lu lista i vari updates disponibili. zypper up installa le nuove versioni dei pacchetti disponibili. zypper up –t patch installa solo le patch.
Ovviamente le operazioni si riferiscono ai repositories disponibili (zypper lr) che possono essere locali, è il caso dell’uso di SMT, o remoti es. via NCC.
I repositories disponibili dipendono dalla licenza di manutenzione e sono visualizzabili sul sito Novell: NCC -> prodotti -> credenziali speculari.
Sul server SMT è bene applicare gli ultimi aggiornamenti relativi a SMT (SLE11-SMT-Updates).
Il repository per la migrazione a SP1 è SLES11-SP1-Pool al quale è bene aggiungere gli update di SELS11 SP1: SLES11-SP1-Updates.
Per essere disponibili al server SMT, i repositories devono essere scaricati (mirror) e abilitati (staging). Completate queste due fasi gli aggiornamenti e le patch sono disponibili sul server SMT, ma non ancora utilizzabili. Occorre cambiare lo stato dei repositories, nella sezione staging del servizio SMT: prima il repository è da portare nello stato di test e poi messo in produzione.
Ovviamente dopo lo stato di test e prima della fase di produzione, è possibile testare gli aggiornamenti sui server il cui client SMT è stato configurato per accedere agli aggiornamenti in test.
Nella sezione di staging, normalmente è possibile scegliere quali patch abilitare. Scelto il repository, vengono elencati gli aggiornamenti e la possibilità di selezionarli.
Questo non è possibile su alcuni repositories come SLES11-SP1-Pool. E’ logico: l’upgrade a SP1 si applica tutto o non si applica, però nei primi approcci all’uso dell’interfaccia di SMT la cosa non è così evidente (almeno per me).
OK. Applicati le ultime patch di SLES11, al server SMT, scaricati e abilitati i repositories di SLES11 SP1 e relativo update si può iniziare.
La documentazione suggerisce queste manovre per ogni server da migrare a SP1:
zypper ref –s                          -> refresh dei servizi disponibili
zypper up –t patch                  -> applica le ultime patch. Se già applicate, come suggerito, nulla succede
zypper up –t patch                  -> c’è ancora qualcosa?
 
Segue la fase che ritengo in po’ criptica. Pur abilitando il repository SLES11-SP1-Pool lo staging e quant’altro, SLES11-SP1 Pool non è visibile dal client SMT e quindi non applicabile.
Non ho ben capito completamente il meccanismo (se qualcuno lo sa attendo illuminazione), ma la disponibilità dell’upgrade viene registrato in /etc/products.d in files con estensione .prod.
La directory /etc/products.d non esiste in SLES10, evidentemente è una implementazione di SLES11.
Occorre verificare la disponibilità e il nome esatto del prodotto e forzarne l’installazione.
 
grep ‘<product>’ /etc/productes.d/*.prod
ritorna <product>SUSE_SLES-SP1-migraion</product>
zypper in –t product SUSE_SLES-SP1-migration         ->installa il software per l’upgrade a SP1 (?).
suse_register –d 2 –L /root/.suseregister.log                 -> installato il nuovo prodotto (SP1) occorre registrarlo in NCC.
L’opzione –L definisce il file di log, una sbrodolata difficile da leggere, ma è bene averlo. Non ho trovato documentazione per l’opzione –d. Immagino definisca il livello di debug per il log.
zypper ref –s                                -> refresh dei servizi disponibili
Ora SLES11-SP1-Pool è visibile dal client SMT e nei repositories (zypper lr).
E’ bene disabilitare tutti i repositories con vecchi aggiornamenti, patch e lasciare attivi solo quelli relativi a SP1: SLES11-SP1-Pool e SLES11-SP1-Updates
zypper mr --disable repo-vecchi          -> listare i prepositories e disabilitare quelli desiderati.
zypper mr --enable repo-nuovi           -> abilitare SLES11-SP1-Pool e SLES11-SP1-Updates
OK: siamo pronti
zypper dup             -> Applica le SP1! La cosa prende un po’ di tempo, ma va.
reboot -> il reboot è indispensabile

Quando il server riparte, si può verificare la versione
cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 1
E’ bene applicare le patch / aggiornamenti di SP1:
zypper up –t patch