Di recente, Tiscali è finalmente arrivata a coprire la mia zona in unbundling e così ho finalmente fatto il grande passo: mi sono staccato da mamma Telecom.

Il risparmio è rilevante:

Bolletta Telecom Italia bimestrale: 32€ di canone per la linea base (comprende 1h di urbane e mezz’ora di interurbane), 3€ di servizio Chi è (per visualizzare il numero del chiamante), 40€ di ADSL 8 mega, modem non fornito.

Bolletta Tiscali bimestrale: 30€ di canone comprensivi di: linea base, servizio Chi è gratuito, ADSL 8 Mbit/s, telefonate urbane e interurbane illimitate al solo costo dello scatto alla risposta (15cent), modem incluso.

Il risparmio è di circa 15€ ogni due mesi!

La performance della linea ADSL è di tutto rispetto:

È possibile a richiesta farsi settare su ADSL1, in tal caso la velocità di picco scende a 6Mbit/s, ma la linea viene impostata in fastpath, quindi la latenza media scende a 15 o 20ms.

Una delle preoccupazione più grandi di chi si appresta a abbandonare mamma Telecom è il periodo di buio in cui si rimane isolati dal mondo, durante il passaggio al nuovo operatore in unbundling.

Decido di fare da cavia, visto che nessuno dei miei amici ha ancora percorso questa strada: incurante del pericolo, il giorno 8 Luglio 2009 chiamo il 130 e ordino Tiscali ADSL+Voce (in promozione per 5 mesi a 15€/mese).

L’operatrice si assicura che io sia l’intestatario della linea telefonica e anche della linea ADSL, mi avvisa che di lì a poco avrebbe cominciato a registrare la telefonata, dopodichè procede a elencarmi tutte le principali condizioni del contratto e a chiedermi conferma della loro accettazione. Le informazioni e le condizioni di servizio vengono presentate in maniera molto chiara e precisa.

Molto apprezzabile il fatto che l’operatrice si presenti con nome e cognome e li ripeta in svariate occasioni – provate a farvi dare un nome e cognome o anche solo un numero di matricola da un operatore Telecom, vi riderà in faccia.

Sfruttando la registrazione della telefonata, diventa possibile accelerare la procedura di distacco da Telecom: Tiscali infatti può in questo modo procedere a farne richiesta a Telecom ancora prima di ricevere la documentazione cartacea dall’abbonato.

Alcune ore dopo aver terminato la telefonata, mi arriva via e-mail un messaggio di benvenuto con le mie credenziali Tiscali.

Il 14 luglio, quando ancora non è trascorsa una settimana dalla mia richiesta di passaggio a Tiscali, la mia ADSL Alice smette di funzionare. La portante ADSL c’è ancora ma l’autenticazione non va a buon fine.

La linea voce continua a funzionare regolarmente.

Tre giorni più tardi, il 17 luglio, mi arriva alle 10 del mattino un SMS da Tiscali: “Sta per ricevere il modem ADSL. Lo colleghi alla linea il prima possibile per accelerare la pratica di attivazione”.

Passano un paio d’ore e arriva il corriere con il pacco contenente il modem, un filtro adsl e svariati cavi, nonchè il contratto della mia linea, da rispedire firmato a Tiscali (busta preaffrancata).

Collego il router e senza fare alcuna configurazione aggiuntiva sono online. L’ADSL funziona regolarmente.

Collego un telefono all’uscita VoIP 1 del router e mi accorgo che riesco già a effettuare le telefonate in uscita tramite la rete Tiscali.

Provo la stessa operazione sull’uscita VoIP 2 del router, ma senza successo. La linea VoIP 2 è quella che verrà mappata sul mio ex numero fisso Telecom, che al momento è ancora attivo sulla linea telefonica normale.

La sera del 28 Luglio mi arriva un altro SMS nel quale vengo avvisato da Tiscali che il giorno seguente la procedura di portabilità del mio numero fisso Telecom sarebbe stata completata.

Puntualmente il giorno 29 Luglio provo a chiamare il mio numero Telecom dal cellulare e anzichè squillare il telefono collegato direttamente alla linea telefonica, squilla quello collegato alla linea VoIP 2 del router ADSL.

Provo a effettuare una telefonata dalla linea VoIP 2 e questa volta la telefonata parte correttamente.

Migrazione completata! E il disservizio è stato veramente minimo.

Tutto ok? Proprio tutto no. Un inconveniente c’è e fa di nome: Pirelli Netgate.

Detto in altre parole: il firmware montato sul router fornito da Tiscali è semplicemente pietoso.

Ecco un breve elenco dei problemi da me riscontrati:

• per far crashare il router è sufficiente inviare 3 pacchetti UDP con source port 5060 e destination port 5060. Se, come me, avete un telefono VoIP a valle del router Tiscali, ogni volta che fate una chiamata la connessione a Internet ammutolirà inspiegabilmente dopo pochi secondi. A volte il router si riavvia da solo, a volte no.
• il router è blindato: potete loggarvici come utente non privilegiato (USER/USER), ma non potete cambiare praticamente nulla a parte il port redirect di alcune porte e l’indirizzo ip del router.
• non è possibile cambiare la password dell’utente USER, questo significa che chiunque sulla vostra LAN sia in grado di accedere al router può modificarne la configurazione a piacimento – può quindi anche redirezionare il traffico in ingresso su un indirizzo ip a proprio piacimento.
• la porta 25 in ingresso è bloccata per evitare che vi installiate un server SMTP sul PC.
• molte altre porte >1024 sono bloccate
• non è possibile riavviare il router dall’interfaccia web

Sono qui per rendermi testimone della situazione del centro servizi informatici della facolta’ di ingegneria dell’ Universita’ di Pisa.

* Come avviene l’accesso a Internet per gli studenti?

Nei primi due piani del polo B di ingegneria sono dislocati una quindicina di scatolotti di latta con dentro dei vecchi P233MMX con 64MB di RAM e 4GB di hard disk. Su quattro di questi “punti di accesso” (come vengono formalmente chiamati dal personale del centro) e’ installata una redhat7.2 con tanto di kde. Sugli altri pc invece e’ installato WinNT.
L’accesso al web dalle macchine NT avviene senza alcuna autenticazione tramite un proxy http ed e’ limitato a certi siti, quello dalle redhat invece avviene autenticandosi con num. di matricola e password, ed e’ senza vincoli.

La lista di siti a cui si puo’ accedere via proxy e’ molto contenuta e spesso non tiene conto del fatto che certi siti utilizzano dei sottodomini per certe sezioni: essendo questi domini non presenti in lista non e’ possibile visualizzare tali sezioni e la navigazione sulla maggior parte dei siti elencati risulta impossibile. Forse qualcuno dovrebbe spiegare ai gentili amministratori che esiste una cosa simpatica chiamata squidguard: http://www.squidguard.org
Giusto per la cronaca, nella lista dei siti accessibili non e’ stato inserito nemmeno *.unipi.it ma solo alcuni sottodomini: persino alcuni siti ospitati nella rete di *.unipi.it sono pertanto inaccessibili! Non parliamo delle altre universita’…

Occorre fare anche qualche considerazione sulla scelta dei sistemi operativi e dei software installati sulle macchine:
- Perche’ pagare una licenza di NT quando si sarebbe potuto usare esclusivamente Linux?
- Per quanto riguarda le redhat7.2, che senso ha installare KDE? E soprattutto perche’ non dare la possibilita’ all’utente di scegliere _se_ usare un desktop manager o se accontentarsi di un window manager (magari blackbox, wmaker, icewm) che essendo molto piu’ leggero avrebbe consentito di utilizzare in maniera _umana_ quei PC dalle risorse cosi’ limitate?
- Come si puo’ installare OpenOffice 1.0 su una macchina cosi’ _lenta_? E soprattutto perche’ i documenti della facolta’ vengano ancora distribuiti in formato doc nonostate persino il governo si sia mosso affinche’ cio’ non accada e nonostante la cosa trovi persino l’opposizione di alcuni (pochi! http://www.unipi.it/athenet/05/approfondimenti/approf_domenici-i.html) professori?

So far so good :-P Se fosse tutto qui la situazione non sarebbe del tutto _tragica_. Purtroppo il brutto deve ancora venire.

Ho omesso infatti alcuni dettagli riguardanti i “punti di accesso”:

- A dimostrazione della competenza di chi ha configurato le macchine con redhat, l’unico browser installato e’ netscape 4.7, un browser estremamente obsoleto, di cui e’ cessato persino il mantenimento. Oltre a essere parecchio pesante come browser non permette di visualizzare in maniera decente praticamente qualsiasi sito. Il modo in cui renderizza le pagine e’ semplicemente ridicolo, quasi inguardabile. Perche’ scegliere un browser di questo tipo? Perche’, ancora una volta, non installare almeno due o tre browser (questione di pochi mega) e dare poi la possibilita’ allo studente di scegliere con quale navigare? Eppure di alternative a netscape ne esistono tante, ne cito solo due:
- c’e’ mozilla-firebird, estremamente versatile, leggero, visualizza praticamente tutto
- c’e’ opera, browser multipiattaforma estremamente leggero e distribuito gratuitamente alle universita’ https://secure.bmtmicro.com/opera/student-discount.html

- Altro dettaglio non trascurabile riguarda la mancanza di una JVM sulle redhat, che impedisce quindi di visualizzare i siti che fanno uso di applet java per gestire menu & affini (pessima abitudine, ma tant’e'…)

- Come se non bastasse, sempre a dimostrazione della competenza degli amministratori, sugli scatolotti che contengono le redhat e’ stato appiccicato con del nastro nell’angolo in basso a dx un foglietto con delle istruzioni che spiegano come impostare il mime.type nel proprio browser in modo che i file .pdf vengano aperti automaticamente: forse qualcuno dovrebbe spiegare ancora una volta ai tizi in questione, che le associazioni delle estensioni alle applicazioni puo’ essere fatta in modo centralizzato, non c’era bisogno di appiccicare tanti foglietti e costringere ogni studente a metterlo nelle impostazioni personalizzate della propria home directory, era sufficiente farlo sul file di configurazione globale!

- Infine, c’e’ ancora un piccolo dettaglio insignificante che finora ho tralasciato: la maggior parte dei punti di accesso e’ spenta/non funziona/e’ sprovvista di qualcosa. Premesso che la manutenzione(?) dei punti di accesso avviene il mercoledi’ mattina come viene indicato a grandi caratteri nella bacheca del Centro, tentero’ di fornire un breve elenco di cosa vi potete aspettare entrando al Polo B di ingegneria a Pisa il giovedi’ mattina:

piano terra, 5 scatolotti:
- 1 e’ sempre accesso, lo e’ sempre stato dal primo giorno in cui e’ stato installato, pero’ non ha mai, dico _mai_, funzionato, non e’ mai stata configurata la rete…
- 2 redhat funzionano
- 2 sono perennemente spenti

primo piano, corridoio 1, 8 scatolotti:
- 3 NT funzionano
- 4 NT non funzionano
- 2 redhat funzionano
- 2 redhat non funzionano

primo piano, corridoio 2, 4 scatolotti:
- 2 NT non funzionano e non hanno mai funzionato. Non e’ stata configurata la rete.
- 1 NT funziona, ma la luminosita’ e il colore del monitor sono sballati: vietato usarla salvo subire poi una visita oculistica
- 1 redhat funz/non funz, nel senso che appena ci si logga, lo schermo comincia a accendersi e spegnersi: dopo qualche ciclo di accensione e spegnimento di solito si generano istinti violenti nell’utente che sta cercando di leggere la posta

Per capire la frustrazione che uno studente prova nell’accedere a Internet, considerate che gli studenti di Ingegneria superano le 3000 unita’ e vedere le poche risorse disponibili sprecate in questo modo e’ a dir poco deprimente. Ovviamente riuscire a mettere le mani su uno dei punti di accesso non e’ garanzia di poter accedere al web o alla posta, dato che la connessione va e viene… insomma no, bisogna trovare il PC giusto libero al momento giusto! Se ce la fate, potete accedere a Internet, altrimenti potete pur sempre andare a prendere un caffe’ ai distributori automatici: quelli funzionano sempre benissimo per fortuna! Grazie Merovingio: sei tutti noi! :-D

Il rant potrebbe terminare qua, di materiale gia’ ce n’e’ abbastanza. E invece no. Parliamo ancora di qualcos’altro… ad esempio del “server” studenti.ing.unipi.it.
Beh chiamare “server” questa macchina e’ un po’ esagerato considerato il modo in cui viene gestita. Direi piuttosto che si tratta di un PC che viene di tanto in tanto connesso a Internet per consentire a qualche mail che gira per caso in quel momento su Internet di giungere nella casella di posta di qualche studente.
Tanto per intenderci, nel momento in cui scrivo l’intera *.ing.unipi.it non e’ raggiungibile.
Il cosiddetto “server” e’ una macchina con FreeBSD. L’amministratore ha un concetto strano del termine _upgrade_. Per lui upgrade significa formatta e reinstalla. Per fortuna almeno le home si salvano… mi pare il minimo. Ovviamente per il tempo che intercorre tra formattare e reinstallare il server resta giu’ e non c’e’ nessuna macchina di backup che ne prenda il posto. La storia del server studenti e’ molto lunga… ma non vorrei dilungarmi troppo sulla questione: mi limitero’ a dire che gli studenti + “anziani” hanno visto copie di backup di /etc/master.passwd sparse in /etc con permessi 644 (i.e.: leggibili da qualunque utente), mailbox in /var/mail dei responsabili del Centro sempre con permessi 644. Gia’ che ci siamo ricordiamo anche come fino a 4 anni fa nel foglio consegnato allo studente assieme alla conferma di creazione dell’account venisse consigliato di accedere al server tramite _telnet_ (e non ssh) e come solo in seguito al crack del sistema da parte di una persona esterna all’universita’ si decise di disabilitare il daemon telnet e consigliare l’utilizzo di ssh. Si badi bene, il daemon del telnet non venne disabilitato per l’intrinseca insicurezza di un protocollo in chiaro ma esclusivamente perche’ il telnetd allora installato era vulnerabile a un attacco remoto! Per chiudere in bellezza riguardo al server studenti.ing.unipi.it, occorre ricordare anche il downtime di 4 giorni dovuto al guasto di un harddisk (RAID1/RAID5, questi sconosciuti): certo che gli harddisk sono componenti difficili da reperire… che fortuna che ci abbiano messo solo 4 giorni per riportare tutto online…

In considerazione di tutto questo, mi sento di dare qualche consiglio a chi gestisce le risorse del centro di calcolo di ing.unipi.it:

- Utilizzate macchine diskless per i punti informativi: risparmiano corrente e sono meno soggette a guasti hw, sono gestibili in modo centralizzato, il software si installa una volta sola e non c’e’ bisogno di intervenire sulle singole macchine ogni volta
- Togliete RedHat e KDE e mettete qualcosa di piu’ leggero e piu’ facilmente aggiornabile (Debian, Gentoo). Lo sapete vero in che anno e’ uscita la redhat7.2? E lo sapete in che anno siamo ora?
- Aggiungete qualche browser che non sia netscape4.7… per favore!
- Installate l’ultimo staroffice (e’ gratis per le universita’) sulle macchine Linux e/o cominciate a distribuire i documenti in formato .ps o .pdf
- installate sul server un daemon (i.e. http://spong.sourceforge.net/) che faccia da monitor per tutti i punti informativi per avere sempre sotto controllo quali stanno funzionando e quali no, in modo da poter intervenire tempestivamente nel caso si verifichino problemi
- mettete i dischi di studenti.ing.unipi.it in RAID e tenete il sistema aggiornato con gli ultimi fix di sicurezza!