last update: 21/ August / 2006
Fedora Core 5 - aggiornamento
Quelle che seguono sono alcune note sull'aggiornamento, a Fedora Core 5, di un paio di postazioni di lavoro, con la soluzione di alcuni problemi incontrati. In coda una breve analisi sulla convenienza e sull'opportunità degli aggiornamenti in generale.
Rieccomi ad esaminare la nuova release di Fedora: la Core 5.
Pur avendo più volte sostenuto che non si dovrebbe mai aggiornare un
sistema che funziona (e tornerò sul tema alla fine) mi trovo nella
condizione di dover, periodicamente, testare le nuove release di GNU/Linux
per verificarne le possibilità di utilizzo in ambiente produttivo.
La cavia è, ovviamente, la mia postazione desktop.
Mi aspettavo il peggio in quanto il precedente aggiornamento, come a suo tempo
ho avuto modo di spiegare in un articolo,
era andato bene e quindi per la legge di Murphy , unita alla teoria sulla ciclicità e l'alternanza degli eventi, questa installazione doveva essere una catastrofe.
Non mi aspettavo "abbastanza"...
- Primo intoppo: dopo i consueti test del DVD e della RAM ho avviato l' installazione, che ha pensato bene di andare subito in crash indicando un possibile bug. Leggendo il log delle ultime istruzioni eseguite mi sono accorto che il problema si manifestava per un tentativo di eseguire il mount della partizione Win che ancora mantengo per alcuni applicativi e che viene montata nel file-system Linux per condividere dei files fra i due sistemi operativi.
Non so se tale antipatia abbia fondamenti sensati, comunque ho trovato un rimedio al volo riavviando la versione Linux ancora installata e commentando in /etc/fstab la riga relativa alla partizione in questione. Anticipo fin d' ora che ho ripristinato la riga in questione ad installazione completata senza riscontrare alcun problema successivo.
Riavviando l' installazione quindi è stato possibile procedere. Ho scelto di aggiornare l' installazione esistente (Fedora Core 4) ed il sistema mi ha pronosticato 85 minuti di attività che, dopo un paio di minuti, sono diventati 120. Tutto bene, mi sono dedicato ad altro per un paio d' ore, ma quando sono tornato di fronte al PC ho avuto una sorpresa...
- Secondo intoppo: dopo due ore di installazione il computer mi segnalava di avere ancora 110 minuti di attività da compiere pur avendo installato il 47% dei pacchetti. Ho giustificato la cosa ricordandomi che stavo usando un supporto DVD-RW che , su quel determinato lettore, poteva essere causa della lentezza. Considerando che avevo altro da fare e la pausa pranzo si avvicinava non ho affrontato il problema ed ho lasciato il Pc al suo lavoro.
Dopo altre 2 ore abbondanti il Pc mi indicava ancora 3 minuti mancanti al completamento; trascorsi i quali ha raggiunto il 100% dei pacchetti installati ed ha iniziato una decisa attività di lettura/scrittura (??) sul disco. Ho pensato fosse una chiusura dell'installazione (configurazioni, settaggi, etc.) ed ho lasciato il PC per un altro paio d' ore dopo le quali sembrava si fosse bloccato.
- Terzo intoppo: a quel punto ho deciso di forzare un riavvio del PC scoprendo che il sistema operativo era sì stato aggiornato la vecchia versione era ancora presente. Quasi tutti i pacchetti erano duplicati e non ben funzionanti. Forse non dovevo riavviare il Pc in maniera così drastica!!!
Al mattino successivo ho rieseguito l' installazione lavorando in modalità testo. Non so se per questa scelta, o per il fatto che i pacchetti bene o male erano già stati installati nel sistema, ma l' installazione è durata in tutto 9 minuti. Il sistema risultante è funzionante se si esclude una relativa pesantezza rispetto alla precedente versione. Ho solo dovuto, come le volte precedenti, effettuare delle messe a punto disabilitando i servizi non necessari e quant'altro.
L'aggiornamento della seconda postazione di lavoro ha avuto un percorso leggermente diverso: anche qui si è verificato un intoppo uguale al primo ed il programma di installazione si è bloccato fino a che non ho commentato alcune partizioni in /etc/fstab.
L'installazione della distribuzione eseguita in modalità testo ha richiesto solo 90 minuti. Faccio notare che il PC è solo leggermente più prestante del precedente e, comunque, non abbastanza da giustificare un rapporto 4:1 rispetto al tempo della precedente installazione.
Anche qui, comuque, al termine dell'installazione il computer ha lavorato moltissimo (circa 40 minuti) senza segnalare nulla a video. A scanso equivoci l'ho lasciato lavorare e l'installazione si è conclusa chiedendo un riavvio.
Dopo il riavvio ho avuto immediatamente problemi con Pirut (l'applicativo di gestione dei pacchetti di installazione dei programmi) che non si avviava e con i CD che non venivano più montati.
Per quanto riguarda i CD mi sono reso conto, dopo un ennesimo riavvio, di un messaggio di errore al boot, messaggio che a causa dello scorrimento del testo al boot non viene mostrato per più di un decimo di secondo e, per motivi ignoti, non lascia traccia in nessuno dei files di log (o almeno non sono stato in grado di rintracciarlo). Con un po' di pazienza sono riuscito a leggere l'informazione e capire che l'errore era dato da haldaemon.
Quindi dopo essermi loggato in console come root ho provato ad avviare il servizio manualmente con
service haldaemon start
ed ecco l'errore in tutta la sua evidenza: la riga di avvio del servizio conteneva un parametro sconosciuto del quale non ho trovato traccia nell'altro PC. Dopo una veloce correzione il tutto ha ripreso a funzionare a meno di un piccolo particolare
Come ho avuto modo di spiegare [http://spazioinwind.libero.it/rgnet/articoli/utopia.htm] in un altra occasione Il demone hal si incarica di montare automaticamente i devices. Fino alla precedente versione di Fedora il mount point era /media/cdrom o similare. Probabilmente sono state modificate delle "regole" di hal e udev in quanto ora il mount point sembra essere /media/[etichetta_del_cd].
Quindi a seconda dell'etichetta del CD/DVD il mount point varia. Molto significativo per un utente desktop, un po meno per un utente un po' smaliziato che potrebbe basare degli script riferendosi ad un mount-point predefinito.Se pensate che questa eventualità non vi tocchi tenete presente che alcuni programmi fanno riferimento a mount point predefiniti come /mnt/cdrom o similari e che per farli funzionare spesso è necessario un link simbolico al device. Se però anche il device viene creato al volo...allora potreste avere dei problemi.
Per inciso si possono forzare dei mount point inserendo in /etc/fstab le indicazioni relative come ad esempio:
/dev/hdc /media/cdrom auto pamconsole,exec,noauto,managed 0 0
il problema è che quando hal fa il suo lavoro e riconosce l'inserimento
del cd questo viene montato due volte in due mount-point diversi.
L'icona sul desktop si riferirà a quello montato da hal che però
non permette operazioni di scrittura o espulsione del media. Penso che per
mettere a punto il tutto dovrò investigare un po' sulle regole di hal/udev
e, probabilmente, il posto giusto per avere un buon inizio è
http://fedora.redhat.com/docs/udev/
Verificando un po su internet ho scoperto che il problema di Pirut è
dovuto al fatto che tenta _sempre_ una connessione ad
internet per trovare le informazioni sui pacchetti. Sul primo PC
il problema non era evidente in quanto ha una connessione permanente
ad internet mentre il secondo che è connesso via modem ha presentato
immediatamente il problema. Ho trovato un indicazione su come risolvere il
problema all'indirizzo
http://www.astahost.com/info.php/fix-fedora-5-add-remove-software-problem_t11390.html
in cui viene spiegato come settare un immagine del CD come repository. Avendo a disposizione il DVD con il quale ho eseguito l'installazione ho preferito settare questo come repository,quindi
- ho rimosso tutti i files da /etc/yum.repos.d/ (dopo averli copiati in una cartella sotto /root/)
- ho creato il file fedora-core.repo in /etc/yum.repos.d/
- all'interno del file ho inserito quanto segue:
[CDROM]
name=cdrom
baseurl=file:///media/disk
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
gpgcheck=0
da notare che /media/disk è il mount-point del dvd creato automaticamente da hal/udev per quel DVD
Un grosso problema che ancora parzialmente irrisolto è la nuova modalità di mount degli share smb. Abbandonato il comando smbmount ora al suo posto c'è mount.cifs che non vuole funzionare del tutto correttamente. Non riesco ad utilizzarlo come utente in quanto mi viengono richiesti permessi di root:
mount -t cifs //server/rudi /mnt/rudi_server/
mount: only root can do that
Non riesco ad utilizzarlo come root in quanto mi ritorna un errore:
# mount -t cifs //server/rudi /mnt/rudi_server/ -o user=rudi
Password:
mount error 5 = Input/output error
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
Dopo molte ricerce e test ho capito che il problema è legato alla versione del software che effettua le condivisioni. Riesco quindi a collegarmi a server del tipo Win2003 o SAMBA 3 ma non a vecchie condivisioni SAMBA 2 compatibili che utilizzo attualmente. Questo per il momento è, perlomeno per me, ancora un problema.
Risolti i problemini di base restano le considerazioni sulle novità. Innanzitutto continuo a notare che l'ambiente Gnome è fortemente privilegiato rispetto a KDE che risulta meno rifinito, essendo un utente KDE comincio ad avere la forte impressione che prima o poi dovrò cambiare distribuzione. Molti degli applicativi installati nella barra dei menu di Gnome non sono nemmeno presenti in quello KDE.
In generale, comunque, l'ambiente sembra rispondere abbastanza bene. OpenOffice.org è leggermente più veloce e anche lo startup del sistema sembra leggermente migliorato. Come in precedenza ho rimosso alcuni servizi inutili all'avvio e sicuramente questo aiuta ad aumentare l'efficienza della macchina.
Tutto il supporto per i formati non GPL continua ad essere assente. Non aspettatevi quindi di utilizzare files mp3 o visualizzare DVD con l'installazione di default. Per ovviare a questo e a numerosi altri "problemi" esiste un ottima guida su The Unofficial Fedora FAQ[http://www.fedorafaq.org/] nella quale fra le altre cose viene spiegato in dettaglio:
- come aggiungere fonts TT
- come configurare le schede video 3D
- come installare i vari plugin java e acroread
- come installare il supporto a NTFS, DVD, mp3 e vari altri formati
Rimangono ora le considerazioni sull'opportunità o meno degli aggiornamenti.
Come amministratore di sistema dovrei prendere una posizione rigorosa schierandomi a favore degli aggiornamenti in quanto i bug-fix sono necessari, in particolare se i bachi corretti riguardano problemi di sicurezza. E' altrettanto vero che un buon amministratore di sistema deve essere in grado di garantire la continuità di servizio e quindi impedire che, a causa di un aggiornamento, un sistema di produzione (ovvero con servizi non interrompibili) non funzioni più. La soluzione consiste nell'avere una macchina che sia una copia fedele al 100% di quella da aggiornare e su questa testare l'aggiornamento prima di andare in produzione. Questo non garantisce che sulla macchina principale l'aggiornamento andrà bene (anche se le due macchine sono identiche al 100% la legge di murphy garantisce la possibilità di un inconveniente) ma almeno si ha la sicurezza che se tutto è andato bene sul PC/server di test, mal che vada questo potrà essere un sostituto immediato di quello in produzione.
Va bene! Questa è la teoria, ma vorrei ben vedere quante aziende possiedono una copia fedele del server dedicato al gestionale o similari. La cosa è improponibile se non altro per ragioni di costo.
Prima di proseguire su questi ragionamenti vediamo anche la situazione di un utente desktop. In questo caso solitamente aggiornare è consigliato. Oltre che per corregere i bachi di sicurezza, anche per avere l'ultima versione degli applicativi in modo da ottenere nuove funzionalità e un consolidamento delle precedenti. Chiaramente se il computer viene usato anche per lavoro, è comunque necessario evitare perdite di produttività dovute ad un aggiornamento che blocca il PC o all'incompatibilità di un applicativo con la propria versione precedente o con qualche altro aggiornamento del sistema. Anche qui il rimedio e quello di avere una macchina per simulare il tutto ma non sempre è possibile o economicamente conveniente.
Con queste premesse vediamo di tirare qualche conclusione:
- Se avete un server o un computer, non collegati in alcun modo ad internet, stabili e contenenti dati importanti il mio suggerimento è di evitare gli aggiornamenti, in base al principio per il quale è inutile riparare una cosa che non è rotta.
- Se per contro avete malfunzionamenti su tali apparecchi o vi è una comunicazione espicita di una patch da parte di chi ha creato il programma il suggerimento più ovvio è di aggiornare il programma in questione.
- Nel caso di macchine collegate ad internet il suggerimento doveroso è di applicare tutti i bug-fix e le patch possibili.
A fronte della necessità di aggiornare ribadisco l'opportunità di provare prima in una macchina non critica qualora ne abbiate la possibilità.
Prevedete comunque sempre un piano di "recovery" (recupero) per poter rapidamente ripristinare la funzionalità della macchina interessata ed eseguite SEMPRE un backup (perlomeno dei dati) prima di applicare gli aggiornamenti.
Se avete delle difficolta per creare un backup decende il mio consiglio e di clonare
il disco.Per farlo trovate un ottima utiliti Open Source all'indirizzo
http://www.feyrer.de/g4u/ . Il tool G4U richiede un FTP server e dischi capienti su cui memorizzare le immagini ma può salvarvi da situazioni delicate in caso di crash.
Se avete hardware sufficientemente potente e le competenze tecniche necessarie potete tentare l'utilizzo di macchine virtuali. In questo caso il server o il PC possono contenere sia la macchina virtuale utilizzata quotidianamente sia quella su cui simulare l'aggiornamento. Un ambiente virtuale, inoltre, spazio su disco permettendo, consente di salvare un immagine immediata dell'ambiente in modo da poter recuperare tutto in tempi brevi nel caso di un aggiornamento andato male.
Purtroppo gli emulatori più efficienti sono distribuiti con licenze
commerciali ed i miei esperimenti con
Bochs e
Qemu non hanno dato grandi risultati in termini di prestazioni
Su questi argomenti ed in particolare sugli emulatori sarei felice di avere anche altri punti di vista anche perchè qualcuno potrebbe aver avuto più successo nell'utilizzo di questi strumenti. Scrivetemi pure e chissa che non ne nasca lo spunto per ulteriori considerazioni...
