Stanca dei maiali. Questo diceva una bella signora che ha l'età della mia mamma a proposito del suo vecchio PC con Windows 98. E i maiali erano le allegoriche icone di AGV Anti-Virus, che oramai dava segnali d'allarme ogni quattro click. Virus, spyware, adware, librerie corrotte o mancanti avevano reso inutilizzabile il sistema operativo, e anche l'harware dava segni di sofferenza. Arriva così il via libera all'acquisto di un nuovo PC, nuovo, ma deputato alle medesime funzioni del vecchio: documenti, posta elettronica, Internet, indirizzario, rete locale.
Opto per l'acquisto di una macchina economica, sotto i 300 Euro, ma composta di un corredo hardware di tutto rispetto: CPU AMD di ultima generazione, 256MB di Ram, hard disk da 40GB, ma non mi capacito che il nuovo sistema operativo faccia crescere il prezzo oltre il 50%.
Un breve ragionamento mi porta a pensare che su questa macchina sia possibile installare GNU/Linux e che le resistenze dell'utente siano superabili con un paio di giorni di assistenza continuativa. Non è però tutto, perché prima ci sono da risolvere dei nodi fondamentali, soprattutto relativi alla posta elettronica, gestita con Eudora, e all'indirizzario, gestito con FileMaker. Per il resto la migrazione è piuttosto semplice: sul vecchio PC era già in uso OpenOffice e i dati tutti memorizzati in comunissimi formati da ufficio.
Eudora è un popolare mail client tra gli utenti Windows, con alcune caratteristiche che lo rendono singolare, fra cui la separazione tra allegati e corpo della mail. Eudora infatti non si attiene allo standard MIME per la memorizzazione degli allegati come testo codificato, ma li memorizza come normali file in una cartella, solitamente
C:\Programmi\Qualcom\Eudora\Attach
separandoli quindi dalla mail box. La stessa cosa avviene per gli allegati inviati, che sono presenti nella mail solo come riferimento assoluto ad una posizione del file system. E' un problema non da poco visto che 1) sembra non esistere un tools che sia in grado di convertire le mail box di Eudora in mail box standard, allegati compresi s'intende, e 2) la presenza degli allegati non è legata a quella della mail, visto che i due elementi possono essere cancellati distintamente.
Il client mail scelto per la migrazione è Thunderbird della Mozilla Foundation. Semplice, veloce, funzionale. La versione per Windows di questo software include un tools di importazione da Eudora (allegati esclusi) che incredibilmente non è incluso nella versione per Linux: ho chiesto sul forum ufficiale il perché, ma non ho avuto risposta. Comunque, il problema è superabile seguendo un HOWTO specifico "Importing from Eudora (Thunderbird)", che suggerisce l'uso di un tools proprietario per Windows, Eudora Rescue utility by Qwerky, che funziona molto bene e rende le mail assolutamente compatibili con Thunderbird.
Non sono riuscito a codificare gli allegati per includerli nelle mailbox e neppure ho trovato nei tanti link qui sopra una soluzione non manuale per farlo. Le mail con allegati all'interno di Thunberbird propongono una dicitura di testo simile a:
Attach: C:\Programmi\Qualcom\Eurora\Attach\nomefile.est
che con uno script Bash ho parsato e trasformato in:
Attach: /home/utente/eudora/attach/nomefile.est
insegnando successivamente all'utente a recuperare manualmente il file attraverso Nautilus, il file manager di Gnome. Una soluzione non certo pulitissima, ma funzionale allo scopo. Identica cosa ho fatto per le mail inviate, anche se qui il percorso del file cambia per ogni mail.
Il prossimo passo è creare una piccola estensione XUL per permettere a Thunderbird di passare trasparentemente al sistema operativo questa informazione, e quindi maneggiare direttamente dal client di posta gli allegati. Non deve essere difficilissimo, ma sono ancora lontano...
L'ultimo passo per migrare la posta elettronica riguarda la conversione del address book che Eudora conserva in un file di testo, nndbase.txt. La conversione di questo file in un normale file CSV non è complessa se si conosce appena un po' di awk e bash scripting, tuttavia il metodo più indolore è quello di utilizzare l'utility apposita di Thuderbird, che però, come già detto, è disponibile solo nella versione per Windows. E' meglio anche dare un okkio al file history.lst che conserva informazioni sui contatti non memorizzati esplicitamente nel address book e che nel caso del mio disordinato utente conteneva più contatti che l'intero address book! Si tratta di un file di testo composto di una singola colonna di mail, l'importazione è quindi banalissima.
Contrariamente ad Eudora, per FileMaker non esiste un software di pari livello su GNU/Linux, bisogna quindi procedere in modo diverso. Molto dipende da quello che FileMaker contiene, dalla complessità delle informazioni e dei database, perché in alcuni casi potrebbe essere difficile migrare questa "piattaforma" verso un'altra soluzione. Nel mio caso sono stato abbastanza fortunato, infatti FileMaker era utilizzato solo per gestire una rubrica di contatti formata da un'unica tabella di database ed una ventina di campi.
Per portare queste informazioni su GNU/Linux mi sono dato un metodo:
Come prima cosa ho esportato i dati in formato CSV da FileMaker. Successivamente ho parsato il file più volte con utility di base come dos2unix, cat -A e sed per ottenere un file ASCII al 100%, visto che dentro quello originale sopravvivevano caratteri binari. Ho anche utilizzato OpenOffice Calc per studiare dentro un ambiente "amico" i dati grezzi.
Da questo ho ottenuto un file CSV standard che ho dato in pasto ad una utility Perl scritta appositamente e basata sul modulo DBI:CSV, attraverso la quale ho potuto manipolare facilmente i dati per eliminare tutto il superfluo e dargli una struttura più logica.
A questo punto con i dati ordinati e puliti ho valutato due possibilità:
Quello che mi ha portato a scegliere per la seconda e più laboriosa ipotesi è stato il fatto che così facendo avrei potuto migrare anche la rubrica degli altri due utenti dello stesso ufficio, uno senza indirizzario e l'altro con una rubrica basata su FileMaker identica a quella su cui stavo ragionando.
Ho così costruito una applicazione LAMP (Linux, Apache, MySQL, PHP) ricalcando la struttura dati mutuata da FileMaker ed inserendola all'interno di un sistema di autenticazioni già esistente che consente ad ogni utente di lavorare indipendentemente sulla propria base dati, ma anche di condividerla in lettura e/o scrittura con gli altri. Rispetto a FileMaker questa soluzione ha molti vantaggi. Innanzitutto gli utenti possono condividere i contatti, cosa che prima non era possibile, inoltre queste informazioni sono centralizzate e soggette alle politiche di backup ed autenticazione del server e non del client, in ultimo sono disponibili sia all'interno della rete locale che all'esterno, via Internet.
Nel merito ho cercato di normalizzare la base dati per farla aderire il più possibile allo standard IMC vCard V3.0, aprendo quindi anche la possibilità che altre rubriche di altri gruppi in rete locale possano migrare facilmente verso questo sistema e arricchendola di funzioni come la ricerca fulltext che la rende di immediato utilizzo.
Ho quindi scritto una seconda utility Perl per la trasformazione dei file CSV ottenuti nelle opportune SQL ed importato i dati all'interno del database.
Il sistema operativo scelto per questa postazione è stato GNU/Linux Debian Sarge appena pochi giorni prima del rilascio come stable. In fase di installazione non si è presentato alcun problema, così come per l'installazione del software necessario, per cui è stato sufficiente un
dpkg --set-selections < linux.my.sistem
comando che consente di clonare una installazione già esistente, in questo caso quello della macchina Debian che fa da "template" per tutti i client desktop.
Per la configurazione della stampa è invece stato sufficiente editare i file
/etc/cups/client.conf /home/utente/.lpoptions
indicando l'indirizzo IP del server di stampa nel primo e il nome della stampante di default nell'altro. Così come è stato sufficiente editare il file
/etc/samba/smb.conf
per permettere all'utente di condividere in rete locale tutto quello che viene posto dentro una directory predefinita all'interno della sua home.
L'importazione del vecchio filesystem è stata banale, è bastato copiare i file dal vecchio disco a quello nuovo per proporre all'utente un nuovo filesystem sotto /home/utente con struttura e date di quello vecchio!
Il passo su cui ho dovuto porre più attenzione, invece, è stata proprio la configurazione del desktop, poiché l'utente al quale era destinato veniva da Windows e non aveva alcuna familiarità con il PC, se non per quelle due o tre applicazioni che utilizzava ogni giorno.
Il già citato Gnome ha fornito l'interfaccia grafica, considerata una delle migliori disponibili al momento, ma differente (almeno a un primo sguardo) da quella di Windows. Ho così organizzato le icone in modo che l'utente potesse aver accesso immediato alle applicazioni più utilizzate, creando un menù alternativo a quello di sistema e quindi semplificando la complessità quasi a quella di un sistema embedded. Ho inoltre settato tutte le applicazioni perché facessero esattamente quello che l'utente si aspetta ponendo il minor numero di domande possibile relativamente a percorsi, formato dei file, applicazioni da utilizzare per l'apertura dei documenti. Ho insomma celato all'utente molta della complessità del sistema, invitandolo a familiarizzare con le risorse a disposizione prima di esplorare il resto.
Valutavo: due giorni di assistenza continuativa. In vero alla sera del primo giorno "la bella signora" aveva già preso confidenza con tutti gli strumenti, sia quelli installati sul proprio PC, sia quelli apparentemente nuovi disponibili sul web server, optando anche per un metodo davvero sano: imparare bene una cosa prima di farne un'altra e comunque affrontare gli argomenti uno per volta, mano a mano che il problema di pone. Un aiuto notevolissimo, sia per la sua memoria, sia per la mia pazienza.
Ho notato che nell'arco di una settimana le domande si riferivano sempre più ad argomenti circostanziati, a richieste di soluzioni e operazioni "avanzate", assolutamente in linea con le domande che ricevo ogni giorno anche dagli utenti Windows. Domande che in due settimane sono diventate rare e sempre più orientate a prendere confidenza con la logica degli strumenti (E' giusto fare così?) piuttosto che al loro mero uso (Come faccio a fare questo?).
L'interattività del sistema le ha dato poi l'occasione di riordinare i documenti e l'indirizzario della posta elettronica, che ormai nell'agonia del vecchio PC erano operazioni lasciate al caso.
A sole tre settimane dall'installazione l'utente lavora in piena autonomia, seppure non abbia conosciuto un solo giorno di stop per la migrazione ed anzi quasi le pare strano accedere ad un servizio senza prima autenticarsi ;-).
Una migrazione completa e senza rimpianti come quella descritta mi è costata 50 ore di lavoro, di cui circa 45 dedicate all'installazione, configurazione, importazione dei dati, ma che include la realizzazione dell'applicazione LAMP, e circa 5 dedicate all'assistenza utente. Si tratta di un tempo lordo, che è comprensivo dello studio necessario alle soluzioni da proporre e a tutti i tentativi fatti in questo senso, oltre al fatto che è stato compresso in un lungo fine settimana da giovedì a domenica, con inevitabili cali di concentrazione.
Da sottolineare poi che in una rete locale dove ogni macchina fa storia a se, sia per quanto riguarda le funzioni che le scelte in materia di software e organizzazione dei dati (e questo è il caso) una migrazione che miri al contempo alla ristrutturazione dei ruoli client/server e ad una rieducazione degli utenti deve per forza confrontarsi con ogni nodo della rete. Diverso il caso di reti in cui già esista una struttura, perché una volta spese queste ore per studiare il caso d'esempio il resto ha bisogno di un tempo (e quindi ha un costo) esponenzialmente inferiore.