linux user group brescia

immagine del castello

Archivio della mailing list

Upgrade sistema (solo info preliminari)

Luca Giuzzi giuzzi a dmf.bs.unicatt.it
Mer 7 Feb 2001 10:48:24 UTC
Il problema dell'upgrade e' che dipende strettamente dalla distribuzione
 piuttosto che dal kernel `linux' (o bsd, o hurd o quello che si vuole).
Distinguiamo due casi:
 1) applicazione di patches
 2) upgrade globale di sistema.

Il caso 1 e' quello piu' tranquillo e quasi (ripeto: QUASI) automatico
 per tutte le distribuzioni. Osserviamo che le patches dovrebbero SOLAMENTE
 risolvere problemi noti (di sicurezza o stabilita') e non introdurre nuove
 funzionalita'... in particolare una upgrade del kernel da 2.2 a 2.4
 NON e' una patch.
 Le patches per un server VANNO  (non e' una raccomandazione, e' una
 regola) seguite dal system administrator... altrimenti i problemi
 sono garantiti. Fortunatamente sistemi tipo apt o rpm consentono di
 automatizzare quasi completamente l'operazione (non conosco up2date e non
 l'ho mai usato... si tratta, in pratica, di un ftp+rpm pero').
 Una nota: la applicazione di patches e' prevista da tutti i sistemi e
 utilizza formati vari. La cosa `carina' e' che in fase di installazione
 il sistema identifica files di configurazione modificati (tramite un
 checksum) e chiede cosa si vuol fare(debian)/li preserva (rh... il file
 nuovo e' un .rpmorig)/li sostituisce (rpm... file nuovo=.rpmsave).

L'upgrade globale di sistema, come detto nel documento citato e'
 "una brutta bestia". Innanzitutto una premessa: NON E' POSSIBILE
 fra distribuzioni diverse, anche se il formato dei pacchetti e' lo stesso
 (ad es. SuSE, RH e Mandrake usano tutte e 3 pacchetti in formato .rpm
  ma non e' possibile fare una upgrade automatica dall'una all'altra.
  In effetti non e' molto furbo nemmeno installare gli rpm di RH sotto
  SuSE o viceversa... le dipendenze sono diverse).
 L'upgrade di una distribuzione puo' essere relativamente facile o un
  incubo a seconda di come e' disegnato il sistema dei pacchetti e del
  numero di bachi all'interno dell'installer (RH7.0 ne aveva, per la
  cronaca). Il punto essenziale e' che si tratta di una installazione di
  un nuovo sistema operativo e, sebbene non fatta ex-novo, non ci sono
  garanzie che (ad es.) il vecchio hardware sia ancora supportato
  piuttosto che il comando `ls' si comporti al medesimo modo
  [la faccenda hw si riferisce soprattutto ai moduli `solo binari' per
   alcune periferiche... d'altro canto e' anche vero che esistono schede
   video supportate solamente da XF3 piuttosto che XF4].
 Ci possono essere alcune comode regole per mantenere un controllo della
  consistenza del sistema (ad es. tenere copia dei files modificati da
   qualche parte nella partizione /usr/local; installare i pacchetti
   nuovi sotto /opt e creare links simbolici opportuni; fare un 
   backup periodico di /etc e /var/nomepaccheti) ma dipendono 
   da come il sistemista si sente a suo agio e non ci sono regole fisse.
  In un mondo ideale tutto verrebbe gestito in automatico dal meccanismo
   di aggiornamento... in realta' le cose sono un po' diverse.
 [d'altro canto un server deve essere solitamente `patch-ato' piuttosto
  che reinstallato, se funziona... i passaggi SunOS/solaris o
  OSF1/Digital Unix/Tru64 non sono stati indolori, anzi... 
  non credo che una upgrade da windows95 a NT4 consenta di mantenere i
  files di configurazione...]

Ciao,
 lg 



Maggiori informazioni sulla lista Lug