LE "TIC": UN'ESPERIENZA DIDATTICA CON NANOLINUX (SECONDA PARTE)

Autore: M. Piai
Email:pxam67 at virgilio dot it
Copyright: GNU GPL versione 2 o successive (con alcuni chiarimenti ed eccezioni)

Indice

1   Premessa

In questo articolo intendo presentare concretamente alcune opportunità, difficoltà, accorgimenti tecnici e decisioni operative relative allo scopo di allestire e gestire un laboratorio di informatica per l'insegnamento delle "TIC" (Tecnologie dell'Informazione e della Comunicazione) in un biennio di Liceo Tecnico utilizzando esclusivamente Software Libero, e in particolare la distribuzione «live» denominata nanoLinuxIII di cui ho già parlato in un precedente articolo.

Faccio presente che la mia formazione scolastica e universitaria non è di tipo informatico (sono laureato in Matematica e diplomato al Liceo Scientifico), e che la mia esperienza in campo informatico - relativamente alla didattica - è abbastanza recente, poichè ho iniziato la mia carriera di Docente di Scuola Secondaria nell'insegnamento della matematica. Di conseguenza il presente resoconto non ha pretese di «scientificità» in senso stretto, ma vuole piuttosto essere una più o meno fedele ricostruzione di un'esperienza «sul campo».

2   Le condizioni iniziali

Il compito che mi fu affidato all'inizio del presente anno scolastico (2003/2004) era quello di insegnare i rudimenti dell'informatica a poco più di un centinaio di alunni, distribuiti fra cinque classi, di cui due prime e tre seconde. Come tempi, avevo a disposizione tre ore settimanali complessive.

Senza la minima esitazione, ho pianificato di passare il minimo tempo possibile in aula (teoricamente zero ore!) per privilegiare invece al massimo le attività concrete, pratiche, in laboratorio, sulle macchine. Di conseguenza ho installato il mio «quartier generale» in una delle quattro aule dell'istituto attrezzate a laboratorio di informatica; la dotazione hardware era ed è la seguente:

La situazione software - purtroppo - è quella già descritta in un precedente articolo, con software proprietario che monopolizzava i dischi rigidi delle macchine.

3   Le esigenze fondamentali

La mia esigenza principale era quella di «dare nell'occhio» il minimo indispensabile, pertanto l'idea (anche se giusta e perfettamente legittima) di mettermi garibaldinamente a ripartizionare i dischi fissi delle venti e passa macchine del laboratorio per poi installare il «mio» software (il Software Libero) era da ritenersi impraticabile, anche dal semplice punto di vista dei tempi necessari alla messa a punto, visto che (prevedibilmente) il supporto nell'impresa da parte del personale dell'istituto era da ritenersi nullo (nella migliore delle ipotesi).

Ancora una volta, dunque, la scelta ricadeva in modo naturale sulle distribuzioni «live», utilizzabili cioè direttamente da CD senza la necessità di installazione su disco rigido.

4   La scelta

Nel corso del precedente anno scolastico avevo svolto la mia attività di servizio presso un Istituto Professionale per il Commercio, dove insegnavo (al triennio) Informatica Gestionale ai futuri Operatore della Gestione Aziendale; buona parte dei contenuti impartiti era incentrata sulle tecnologie di supporto ai sistemi informativi aziendali, e quindi sostanzialmente sistemi di gestione per le basi di dati.

Volendo illustrare anche dal punto di vista pratico i moderni sistemi per basi di dati, avevo la necessità di poter utilizzare un buon RDBMS standard, che permettesse facilmente di provare semplici interrogazioni e/o creazioni di basi di dati elementari, utilizzando il linguaggio SQL. Proprio in quei mesi appariva sul sito http://linuxdidattica.org/ l'annuncio della pubblicazione della prima «release» di nanoLinuxIII, e quindi fui piacevolmente sorpreso dall'apprendere che il CD conteneva uno dei migliori RDBMS presenti sul mercato, per la precisione PostgreSQL. Ovviamente conoscevo già l'ottimo lavoro di Daniele Giacomini sui suoi «Appunti di informatica libera», e avevo in particolare apprezzato la parte dedicata proprio ai DBMS, alla quale avevo già attinto per documentarmi in diverse occasioni; ero quindi certo che la scelta di includere l'applicativo PostgreSQL. era stata frutto di un'esperienza e di uno studio non certo superficiali.

nanoLinuxIII era quello che faceva al caso mio! Nei mesi successivi ho portato avanti parallelamente alle lezioni teoriche frontali una serie di attività pratiche su SQL, basate su PostgreSQL, e su basi di dati reperite tramite Internet. Grazie a ciò ho potuto concretamente sperimentare le qualità (e i limiti) della distribuzione, e nel frattempo ho potuto accrescere la mia professionalità essendomi trovato ad affrontare e risolvere decine di problemi pratici e concreti legati alla gestione di un laboratorio usando Software Libero, e una distribuzione «live». Nel frattempo ho avuto modo di contattare Daniele Giacomini e ad instaurare con lui una proficua relazione epistolare, e godere quindi del supporto tecnico dell'autore stesso della distribuzione.

5   La pianificazione

Dunque, all'inizio del corrente anno scolastico, la scelta era stata fatta.

Ora si trattava di pianificare le attività da realizzare, stabilire i passi necessari a creare l'infrastruttura software più idonea allo scopo prendere delle decisioni operative e implementarle.

Come ho già avuto modo di accennare, il bello delle distribuzioni «live» è la possibiltà concreta di sperimentare l'uso del software senza la «traumatizzante» necessità di riorganizzare il partizionamento del disco rigido della macchina sui cui si va ad operare. Se questo è inizialmente un forte vantaggio, alla lunga operare in queste condizioni può essere frustrante, per lo meno in termini del tempo necessario agli utenti per imparare a gestire efficacemente il salvataggio dei dati su floppy e il successivo recupero. Di conseguenza, la principale necessità è stata quella di offrire agli utenti la possibiltà di usufruire di un'infrastruttura stabile per l'archiviazione affidabile dei propri dati.

Venendo da mesi di eperienze con i floppy, si può intuire come qualsiasi passo potessi intraprendere sarebbe stato per forza un progresso, a prescindere dalle scelte implementative che avessi fatto. E, in effetti, ho deciso di procedere per gradi, e realizzare soluzioni al problema via via più sofisticate ed affidabili.

6   Le implementazioni

6.1   Samba

La scuola «offre» al personale e agli utenti una ricca (o per lo meno costosa) infrastruttura telematica basata su serventi proprietari... sarebbe un peccato che andasse sprecata, giusto?

Bene, nanoLinuxIII offre la possibiltà di sfruttare una preesistente infrastruttura proprietaria, poiché include il pacchetto smbclient, il quale si compone di vari strumenti grazie ai quali è possibile accedere a una risorsa condivisa (a condizione, ovviamente, di possedere i privilegi necessari). Ad esempio, al sottoscritto è stata assegnata dall'amministratore di rete della scuola l'utenza mpiai, tramite la quale ho accesso alla risorsa docenti (in pratica una directory offerta dal servente, denominato andrea2003 dal servizio di risoluzione dei nomi proprietario 1) e in particolare alla cartella mpiai:

uindous.jpeg

Ora, se volessi accedere a tale risorsa da una macchina connessa alla rete, non dovrei fare altro che procedere come segue:

ospite3@172.17.1.22:~$ smbclient //andrea2003/docenti -I192.168.1.1 -Upalladio/mpiai -Dmpiai
Password: 
Domain=[PALLADIO] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]
smb: \mpiai\>

La sintassi del comando smbclient prevede di specificare il «nome» del servente //andrea2003, la risorsa condivisa (/docenti), l'utenza eventualmente preceduta dal «dominio» 2 (-Upalladio/mpiai), e (facoltativamente) la directory (-Dmpiai) a cui si intende accedere. Un'altra opzione qui utilizzata (-I192.168.1.1) permette di specificare l'indirizzo IP del servente proprietario; questa opzione è necessaria se la macchina cliente che si sta utilizzando appartiene a una diversa rete IP rispetto al servente (nel nostro caso il cliente ha indirizzo 172.17.1.22, il servente 192.168.1.1).

In caso di identificazione corretta, smbclient mette a disposizione dell'utente un interprete di comandi interattivo, simile a quello offerto dai normali clienti FTP; ad esempio, esiste il comando ls per elencare i file:

smb: \mpiai\> ls
  .                                  DA        0  Fri May  7 10:47:35 2004
  ..                                 DA        0  Fri May  7 10:47:35 2004
  Application Data                    D        0  Wed Oct  1 10:31:18 2003
  bloccob                             D        0  Sun Feb  8 21:13:22 2004
  bloccop                             D        0  Fri Feb  6 12:45:23 2004
  Cookies                            DS        0  Mon Feb 16 12:43:54 2004
  Cronologia                         DS        0  Wed Sep 24 08:24:13 2003
  domanda funzioni obiettivo.doc      A    42496  Thu Apr  1 10:11:48 2004
  oo                                  D        0  Thu Mar 25 16:22:20 2004
  pc23-20040325.tar.gz                A 550266880  Thu Mar 25 16:17:01 2004
  pc23-20040402.tar.gz                A 570019840  Fri Apr  2 16:22:02 2004
  pc23-20040407.tar.gz                A 577269760  Wed Apr  7 14:30:50 2004
  pc23-20040416-home.tar.gz           A 76185600  Fri Apr 16 13:54:00 2004
  pc23-20040423-home.tar.gz           A 82165760  Fri Apr 23 16:06:34 2004
  pc23-20040430-home.tar.gz           A 84674560  Fri Apr 30 13:47:40 2004
  secondaria_2_d1.pdf                     640691  Mon Feb 16 11:28:52 2004
  secondaria_2_d2.pdf                      97403  Mon Feb 16 11:29:02 2004
  temp                                      2022  Tue Feb  3 11:06:35 2004
  testo_ccdn_04.pdf                       363412  Mon Feb 16 11:30:28 2004
  tvspot                              D        0  Mon Feb 16 12:42:27 2004
  USER.DAT                               1552416  Tue Mar 16 15:15:00 2004

                49999 blocks of size 1048576. 17060 blocks available

Ecco una lista completa dei comandi disponibili (ottenuta tramite il comando help):

smb: \mpiai\> help
?              altname        archive        blocksize      cancel         
cd             chmod          chown          del            dir            
du             exit           get            help           history        
lcd            link           lowercase      ls             mask           
md             mget           mkdir          more           mput           
newer          open           print          printmode      prompt         
put            pwd            q              queue          quit           
rd             recurse        reget          rename         reput          
rm             rmdir          setmode        symlink        tar            
tarmode        translate      !

Per ulteriori spiegazioni, man smbclient è nostro amico.

Un altro esempio: supponiamo di voler copiare tutti i file grafici in formato JPEG dalla nostra directory personale alla cartella che ci è stata assegnata nella risorsa proprietaria condivisa, ma prima di voler creare all'interno di tale cartella una sottocartella di nome prova da usare come destinazione effettiva:

smb: \mpiai\> mkdir prova
smb: \mpiai\> cd prova
smb: \mpiai\prova\> mput *.jpg
Put file lamantino.jpg? y
putting file lamantino.jpg as \mpiai\prova\lamantino.jpg (207.9 kb/s) (average 207.9 kb/s)
smb: \mpiai\prova\> ls
  .                                   D        0  Fri May  7 13:28:54 2004
  ..                                  D        0  Fri May  7 13:28:54 2004
  lamantino.jpg                       A    11919  Fri May  7 13:28:54 2004

                49999 blocks of size 1048576. 16925 blocks available

Per terminare una sessione e tornare al consueto interprete dei comandi (in questo caso GNU Bash), si utilizza il comando quit:

smb: \mpiai\prova\> quit
ospite3@172.17.1.22:~$

6.2   FTP

Dopo aver fatto sperimentare agli alunni la possibilità di accedere alle proprie cartelle 3, ho voluto compiere il primo passo di reale «emancipazione» dall'infrastruttura proprietaria dell'istituto (dopo aver notato - peraltro - la poca affidabilità della stessa: spesso la rete si «sedeva», rendendo inaccessibili le risorse condivise, e inoltre sono accaduti alcuni episodi di misteriose «sparizioni» di file dal servente della scuola, con conseguente frustrazione di colleghi e alunni alla disperata ricerca del lavoro perduto; ma sto divagando...). Mi sono dunque «impossessato» di una partizione del disco della macchina «docente», vi ho installato nanoLinuxIII e ho attivato un servizio FTP standard , tramite il quale gli alunni potevano accedere alla possibilità di archiviare i propri lavori di volta in volta a prescindere dalla disponibilità a funzionare dell'infrastruttura proprietaria dell'istituto. L'esperienza fatta con smbclient, ha permesso dunque agli alunni di migrare in modo semi-indolore a questo servizio, vista la forte somiglianza fra le interfacce dei rispettivi clienti.

6.3   SSH

Sulla stessa macchina «docente» (IP 172.17.1.30) ho poi provveduto a creare un utenza per ciascuna classe, con relativa directory personale sotto /home; l'uso di tale utenza si limitava comunque al salvataggio e al recupero dei file, in maniera analoga ai servizi visti in precedenza; lo scopo didattico era quello di far percepire all'alunno come servizi molto differenti potessero offrire opportunità analoghe sotto l'apparenza di interfacce dal comportamento anche fortemente dissimile, in modo da abituarsi a non «dare per scontato» nessun tipo di automatismo.

A titolo di esempio, gli utenti della classe 1^ B potevano usare l'utenza ib sulla macchina 172.17.1.30 per salvare i loro file locali in questo modo:

ospite3@172.17.1.22:~$ scp * ib@172.17.1.30:
....

per potere, in seguito, recuperarli essi procedevano innanzitutto ad elencare i file presenti sulla macchina remota:

ospite3@172.17.1.22:~$ ssh ib@172.17.1.30 "ls"
mario.text  giovanni.html  luigi.pdf  ....
....

e successivamente al recupero del file desiderato:

ospite3@172.17.1.22:~$ scp ib@172.17.1.30:luigi.pdf ~
luigi.pdf                                     100%   25KB 408.6KB/s   00:00
....

6.4   NFS/NIS

Il successivo e fondamentale passo verso la «liberazione» è stato quello di attibuire a ciascun alunno la possibiltà di avere una directory personale stabile pur lavorando da CD. Per ottenere questo risultato, mi sono «impossessato» della seconda macchina del laboratorio che disponeva di un disco rigido abbastanza capace, ho ripartizionato e ho installato anche lì nanoLinuxIII.

Successivamente, ho creato un'utenza per ciascun alunno (più alcune altre di riserva); tale operazione - in generale non difficile - è resa particolarmente comoda da un utilissimo programma di servizio preparato da Daniele Giacomini, denominato nanorc («nanoLinux run command»), il quale permette all'utente di gestire tutta una serie di compiti amministrativi mediante un comodo menù; a dimostrazione della semplicità di tale approccio, la successiva personalizzazione delle parole d'ordine dei singoli alunni è stata «autogestita» dagli stessi (anche se sotto la mia supervisione). Il funzionamento del programma nanorc è intuitico, ma è anche ampiamente documentato <http://a2.swlibero.org/nanolinux_introduzione.html>_.

Ho in seguito attivato il servizio NFS su questa macchina; mediante tale servizio è possibile offrire porzioni specifiche del filesystem per il montaggio da parte di macchine remote; in pratica, ciscuna macchina utilizzata dagli alunni procedeva - all'avvio - a innestare all'interno del filesystem locale la directory /home del servente NFS; da quel momento in poi gli utenti che si registravano avevano a disposizione «localmente» le proprie directory personali che in realtà risiedevano sul servente.

Naturalmente era necessaria anche una procedura di identificazione e registrazione degli utenti sulle varie macchine: a tale scopo ho attivato anche il servizio NIS sulla medesima macchina su cui avevo attivato il servizio NFS. Mediante il NIS, è possibile centralizzare i file /etc/passwd ed /etc/shadow e quindi fare in modo che quando un utente tenta di registrarsi su di una certa macchina, il controllo avvenga in base a tali file gestiti centralmente piuttosto che utilizzando quelli locali (che in pratica permettono solo l'utilizzo delle utenze «anonime» predefinite e immutabili all'interno del CD, fra cui tizio, caio,... e root per l'amministratore).

Faccio notare che per attivare e configurare tali impostantissimi servizi mi è bastata un'infarinatura dei principi base del loro funzionamento, visto che in pratica tutto si può gestire in modo semi-automatico mediante il solito programma nanorc.

Dopo l'attivazione dei servizi NFS e NIS è stato possibile gestire le attività didattiche del laboratorio in modo semplice e praticamente senza sforzi, poichè in pratica gli alunni trovavano ad ogni successiva lezione il proprio lavoro nell'esatto stato in cui l'avevano lasciato, a prescindere da quale macchina utilizzassero. Il fatto di aver centralizzato su di un'unica macchina le varie utenze mi ha poi permesso di amministrare il sistema e di controllare le attività didattiche da quell'unica postazione, la quale fungeva anche da router verso la rete esterna e Internet (purtroppo limitatamente al protocollo HTTP tramite il «blindatissimo» proxy d'istituto); in modo molto semplice ho potuto provvedere alla raccolta periodica degli elaborati dalle varie directory personali degli alunni (in qualità di amministratore), e a controllarne i progressi; a scadenza settimanale ho anche proceduto ad effettuare l'archiviazione di tutte le directory personali, il tutto gestito con un paio di semplici comandi standard in dotazione a nanoLinuxIII.

7   Conclusioni

Come spero di esser riuscito a spiegare, è estremamente semplice realizzare un laboratorio «liberato» da software proprietario, e superare con alcuni semplici accorgimenti le limitazioni intrinseche all'uso di distribuzioni «live» come nanoLinuxIII. È solamente questione di liberarsi da alcuni preconcetti e assuefazioni, aprire la propria mente alla possibilità di imparare alcune cose nuove (non moltissime per la verità) e rimboccarsi le maniche.

In un prossimo articolo cercherò di approfondire alcune questioni prettamente tecniche come: