Category Archives: /me

Decreto Urbani

Ho appena finito di leggere lo speciale di PI sul decreto Urbani e sono veramente sconcertato e impaurito. Stiamo veramente andando verso uno stato di polizia, con il grande fratello che controlla ogni byte che trasferiamo?

Non so proprio cosa pensare dell’obbligo dei provider a controllare e denunciare i propri utenti. BTW, mi piacerebbe proprio capire chi e come, tra gli ISP, sarà in grado di adempiere a quest’obbligo di legge… senza toccare la questione dei costi aggiuntivi enormi per “monitorare” tutta la rete che probabilmente, come al solito, ricadranno sugli utenti finali.

Tutta la mia stima al senatore Fiorello Cortiana che sta’ dimostrando grande attenzione e lucidità nell’affrontare questo problema, come d’altronde sta’ già facendo per tematiche quali il blocco dei brevetti software in Europa o il ruolo del software libero in particolare nella scuola e nella P.A.

Tutti i NAT di Fastweb

Preso dalla curiosità mi sono messo a fare qualche ricerchina su whois. Ecco la lista dai gateway residenziali (sempre che siano stati coerenti nella scelta dei “netname”)

fabio@gnu:~$ for i in `seq -w 1 20`; do whois FASTWEB-RESIDENTIAL-$i -h whois.ripe.net | grep -A 1 inetnum; echo "--------------------"; done
inetnum: 213.140.22.64 - 213.140.22.79
netname: FASTWEB-RESIDENTIAL-01
--------------------
inetnum: 81.208.60.192 - 81.208.60.207
netname: FASTWEB-RESIDENTIAL-02
--------------------
inetnum: 62.101.126.208 - 62.101.126.223
netname: FASTWEB-RESIDENTIAL-03
--------------------
inetnum: 213.140.17.96 - 213.140.17.111
netname: FASTWEB-RESIDENTIAL-04
--------------------
inetnum: 81.208.36.80 - 81.208.36.95
netname: FASTWEB-RESIDENTIAL-05
--------------------
inetnum: 62.101.126.224 - 62.101.126.239
netname: FASTWEB-RESIDENTIAL-06
--------------------
inetnum: 81.208.74.176 - 81.208.74.191
netname: FASTWEB-RESIDENTIAL-07
--------------------
inetnum: 81.208.106.64 - 81.208.106.79
netname: FASTWEB-RESIDENTIAL-08
--------------------
inetnum: 213.140.6.96 - 213.140.6.111
netname: FASTWEB-RESIDENTIAL-09
--------------------
inetnum: 213.140.6.112 - 213.140.6.127
netname: FASTWEB-RESIDENTIAL-10
--------------------
inetnum: 213.156.52.96 - 213.156.52.111
netname: FASTWEB-RESIDENTIAL-11
--------------------
inetnum: 213.156.52.112 - 213.156.52.127
netname: FASTWEB-RESIDENTIAL-12
--------------------
--------------------
--------------------
[...]

FASTWEB NAT

Leggo sul blog di emanu che anche a lui hanno modificato l’ip di NAT su fastweb

Lui è passato il 10/3 da 62.101.126.225 a 81.208.60.192
Io sono passato il 4/12 da 62.101.126.208 a 81.208.60.192 e qualche giorno fa a 213.140.17.96

Tra l’altro siamo anche abbastanza vicini di casa… boh. Evidentemente non hanno le idee chiare :-)

BTW, noto con piacere che almeno il “netname” è stato sistemato. Al 4 dicembre le prime due classi di IP erano registrate con lo stesso nome :-/

fabio@gnu:~$ whois 213.140.17.96
[...]
inetnum: 213.140.17.96 - 213.140.17.111
netname: FASTWEB-RESIDENTIAL-04
descr: Infrastructure for Fastweb's main location
descr: NAT IP addresses for residential customer, public subnet
country: IT

fabio@gnu:~$ whois 81.208.60.192
[...]
inetnum: 81.208.60.192 - 81.208.60.207
netname: FASTWEB-RESIDENTIAL-02
descr: Infrastructure for Fastweb's main location
descr: NAT IP addresses for residential customer, public subnet
country: IT

fabio@gnu:~$ whois 62.101.126.208
[...]
inetnum: 62.101.126.208 - 62.101.126.223
netname: FASTWEB-RESIDENTIAL-03
descr: Infrastructure for Fastweb's main location
descr: NAT IP addresses for residential customer, public subnet
country: IT

Cohiba

Qualche anno fa ho iniziato a fumare la pipa e poi i sigari, nelle occasioni speciali.

Ho appena finito un grandioso Cohiba Esplendido, uno degli ultimi che mi sono rimasti da una scatola da 25 presa a Cuba l’anno scorso. Conservarli in questo clima molto più secco è difficile ma un umidificatore rende possibile il *miracolo*.

Non è una occasione speciale ma sicuramente una buona occasione. Oggi sono rimasto a casa solo (Vivi è in ufficio :-/) e ho avuto tutto il tempo per rilassarmi e gustarmi guesto momento. E’ difficile spiegare a chi non apprezza il *gusto* di un buon sigaro o di un buon bicchiere di whiski o di vino rosso. Io stesso non lo concepivo qualche anno fa… sarà la vecchiaia :-)

esplendidos.jpg

24/3:BS4et@scimmie

Ieri sera riunione della “band” per cercare di chiarire se e come vogliamo suonare insieme. Ne è emersa, come previsto, una visione molto differente sul “fare musica” tra noi musicisti e Ben.
In ogni caso, anche se molto diversi, credo ci sia da parte di tutti un gran rispetto degli altri, e soprattutto la voglia di suonare. Per questo abbiamo deciso di continuare a suonare insieme facendo principalmente cover. L’alternativa poteva essere quella di chiudersi in studio per lavorare su pezzi nostri ma questo avrebbe escluso la possibilità di suonare in giro da qui ad almeno un annetto, tempo necessario per scrivere e “far suonare” una ventina di pezzi.
Quindi cover, liberamente interpretate, con ampio spazio all’improvvisazione.

Già stamattina arriva la notizia che Davide delle scimmie ci vuole per un’altra serata. Ci ha già messo in programma per mercoledi 24 marzo. Wow! Ancora da definire la questione “nome del gruppo”, Ben’so’4et. Siamo in 5 (6 se viene la corista) e ci chiamiamo *quartet*… mah.

We got a ticket to ride

La burocrazia della Telecom è pari forse solo alla sua inefficenza.

Premessa: ieri il nostro beneamato ISP ha fatto flop per ben 4 ore dalle 17 alle 21. (Situazione complicata: un po’ di traffico arrivava e le connessioni ssh aperte non sono cadute ma era quasi impossibile aprire nuove connessioni. IMHO hanno avuto qualche casino con un firewall)

Ecco il bel buco nel grafico del traffico. (La parte non traccciata dipende dal fatto che ieri abbiamo fatto un reboot e ci siamo dimenticati di far ripartire il client LRRD :-/ )

veleno.inter.it-if_eth0-day.png

Ho passato la serata al telefono con l’helpdesk, aspettando tra una chiamata e l’altra di essere contattato da un tecnico per avere perlomeno qualche indicazione sulle tempistiche di risoluzione del problema. Telefonata mai ricevuta.

A problema risolto richiamo per sapere cosa era successo e mi dicono che nel Ticket non é indicato: per saperlo devo aprire un altro ticket!!! Incredibile, ho aperto un’altro ticket.

Beffa finale: stamattina devo mettere in attesa la chiamata dell’helpdesk di telecom che vuole verificare che il problema sia effettivamente rientrato. Ho sotto un’altra chiamata: un altro tizio dell’hd di telecom che mi chiede esattamente la stessa cosa! Verosimilmente si trovava nella stessa stanza del primo.

In definitiva non sappiamo ancora cosa c***o è successo.

Fastweb NAT

Mentre Telecom ci lascia ancora a piedi mi sono accorto che che FW ha cambiato ancora la tipologia della rete:

fabio@gnu:~$ last -100 -i
[...]
fabio pts/0 213.140.17.96 Thu Mar 4 10:02 - 10:18 (00:15)
fabio pts/0 81.208.60.192 Thu Mar 4 00:13 - 00:40 (00:27)
[...]

Analog per VHOST su Picard

Un paio d’ore del pomeriggio dedicate a mettere in piedi uno script per automatizzare le analisi di analog per i vhost su picard.

Lo script genera la lista dei vhost direttamente dai file di log presenti (i cui nomi sono anch’essi generati da macro e quindi affidabili) e su questa lista lancia le analisi.

La configurazione è in gran parte condivisa dai vari vhost in un’unico file ma alcuni valori sono parametrizzati sul nome del vhost, quali il nome dei file log e di output o l’hostname o, ancora, i nomi delle charts.

Le analisi sono poi rese disponibili nello spacename dei singoli vhost con un Alias nella macro che ne genera la configurazione per apache.

Sono soddisfatto soprattutto del fatto che il tutto dovrebbe essere a manutenzione zero: creando un nuovo vhost l’analisi verrà fatta in automatico.

Una volta pensato il tutto realizzare lo script è stato banale, con l’unica incognita di aver scelto di scriverlo in bash che trovo sempre piuttosto ostica (sarà perché ci programmo così poco :-/)

…ora si tratta di affinare un po’ la configurazione per rendere l’analisi più utile possibile.

Sanitizer v1.4.1

Oggi finalmente ho aggiornato il sanitizer sul mail server alla versione 1.4.1 che prevede anche la scansione dei file ZIP. Speriamo in questo modo di tamponare alla valanga di virus che si stanno diffondendo.

Ho anche aggiunto qualche riga al procmailrc per rimediare ad un vecchio bug di procmail… se un filtro muore può capitare che si perda il primo byte del messaggio. In questo modo il “From” diventa “rom” rendendo la mailbox illeggibile. Visto che mi è capitato ultimamente con un paio di utenti:

:0 H
* ! ^From[ ]
* ^rom[ ]
{
LOG="*** Dropped F off From_ header! Fixing up. "
:0 fhw
| sed -e 's/^rom /From /'
}

Rimuovere il Boot Sector

Mi è capitato di dover rimuovere lilo da un portatile dual boot e dato che poi non ricordo mai come si fa’…

per zappare completamente il MBR:
dd if=/dev/zero of=/dev/hda bs=512 count=1

per non cancellare la partition table:
dd if=/dev/zero of=/dev/hda bs=446 count=1

Ovviamente non garantisco nulla… :-)