Da Fedora Core 3 al Core 4 – Trouble shooting


Questa non vuol essere la solita guida sul fai questo e fai quello, quindi eccovi un po’ la storia di quel che è successo.
Mono (il server su cui è basato etechs) purtoppo non mi è di facile accesso, è posizionato a circa 30 Km da casa mia in una stanza deumidificata ed a temperatura fissa. Il suo sistema operativo è Linux Fedora, ad inizio anno era la Core 3, per motivi di sopravvivenza sopratutto con MySQL ho voluto fare l’aggiornamento alla core 4.
Avevo 2 possibili strade per farlo:
– andare nella stanza deumidificata ed affrontare l’upgrade
– affettuare l’aggiornamento da remoto con tanto di cero acceso

Per fare l’aggiornamento da remoto però bisogna essere molto preparati a farsi 30 Km di corsa in macchina col server in panne, ad ogni modo la mia scelta è caduta ad una misera e scarna shell tutta nera in ssh comodamente seduto alla mia scrivania.

Ho seguito i passi che indicavo nel HowTo upgrade fedora Core 3 to core 4.
Speravo andasse tutto bene come nel precedente tentativo effettuato a casa. Evidentemente mi sbagliavo, i motivi sono nel non aver considerato Mono come un server, quindi come tale con installazione ben diversa dal solito ambiente desktop ed infine con dipendeze diverse tra i vari pacchetti installati.

Prima di tutto dobbiamo aggiungere un passo tra l’upgrade di yum tramite yum e l’upgrade di tutta la distro.
DObbiamo, prima di lanciare il download di millemila pacchetti, upgradare il kernel alla nuova versione FC4 con questo comando

yum -y update kernel

Ma non è finita, dobbiamo anche rimuovere la versione vecchia del kernel con quest’altro comando

yum remove kernel-2.6.11*FC3*

In questo modo si evita l’errore di dipendenza tra Kernel e Kernel-utils e viceversa.

Una volta lanciato l’upgrade totale globale il server m’ha dato un’altro errore: GPG check Fails
All’inizio ho preso un colpo, pensavo che nemmeno i pacchetti in linea fossero affidabili…. mi sbagliavo, uno degli upgrade effettuati da YUM riguarda il gestore delle GPG pubblic Key che va a riposizione la chiave del nostro server.
questa informazione è scritta nel file /etc/yum.repos.d/fedora.repo dovete andare in cerca della riga

gpgkey=file://etc/pki/rpm-gpg/RPM-GPG-Key-fedora

e sostituirla con

gpgkey=file://etc/pki/rpm-gpg/RPM-GPG-Key

Adesso possiamo continuare l’upgrade :).

Ma i problemi nascono proprio alla fine dell’aggiornamento e si trovano nei server di:
– MySQL
– Apache – php
– Postgres
– Dovecot pop3-imap

MySQL purtroppo non trovava più i database presenti e le relative associazioni utente–>DB per i permessi di accesso. Se avete un backup del DB basta solo che lo ripristiniate e vi ritroverete la versione installata a dovere. Se invece non avete backup validi o essi sono troppo vecchi, cercate all’interno del File system i vostri DB, sono semplicemente spostati dalla loro posizione precedente.
Ricordiamo sempre però che il DB adesso è nella versione 4, quindi è possibile che qualche SQL non dia più gli stessi risultati di prima, ci vuole un po’ di tempo per ricontrollare tutto ma ne vale sempre la pena

Apache – php entrambi in versione nuove rispetto le precedenti, il file php.ini non è più quello, è stato salvato sotto un’altro nome, non vi consiglio di recuperarlo, mancano innumerevoli parametri.
Se avete fatto delle configurazioni perticolari sia di php che di apache è consigliabile ripercorrere le vostre scelte e rifarle a manina, onde evitare dei down di sistema spesso lunghi e fastidiosi.

Postgres similmente a MySQL non vede più i database installati, però a differenza del precedente non ha proprio la possibilità di recuperarli, lo staff di fedora consiglia di fare un backup manuale prima dell’upgrade ed un ripristino manuale dopo, se mi avessero avertito prima lo avrei fatto, ma…. meglio così, ho ripulito il server.
Sembra che la nuova versione di questo server abbia proprio un’altro formato di file per la gestione del DB, completamente incompatibile con la precedente e sembra anche che non abbiano pensato di mantenere la compatibilità verso il basso. un po’ come MS Access nelle sue varie versioni.

Dovecot il demone per la gestione degli accessi pop3 ed imap basa le sue regole di autenticazione su PAM, è necessario quindi tornare ad editare i processi PAM authentication per riallineare alcuni file che, come prima, risultano spostati.

Ad una prima lettura una persona m’ha detto che questo articolo è superficiale, di fatto lo è perchè non ho detto fai questo e fai quello, ma mi piace così perchè è giusto trovare un metodo nelle cose, non fare sempre copia incolla, a volte è bello scoprirle da soli le cose.

Da Fedora Core 3 al Core 4 – Trouble shooting ultima modifica: 2005-11-30T00:00:00+00:00 da Enrico

Comments are closed.