Ho fatto un po’ di test per fare il boot da una chiavetta USB.

Prima di tutto si può lavorare con o senza partition table: nel secondo caso si crea il filesystem direttamente su /dev/sda e con syslinux si rende avviabile. Nessun MBR e nessun problema al boot.

Se si decide di usare la partition table (indispensabile per far vedere la chiavetta ad altri sistemi) allora è necessario installare il MBR. Md mi ha suggerito di usare il pacchetto mbr ma nel mio caso non ha funzionato. Ho trovato però con google chi aveva già avuto (e risolto) il mio stesso problema: la distribuzione spblinux contiene un mbr che ha finalmente funzionato.

dd if=spb2_mbr.sec of=/dev/sda did the work!

Ho anche installato ad un collega con una chiavetta più preziona della mia (128MB invece di 32) la distro damn small linux che praticamente è una knoppix ridotta all’osso per stare su una business card (52Mb) in una versione modificata per usb trovata qui.

Alto link interessante: Installing Debian from an USB memory stick

Almeno per mysql (il client) localhost e 127.0.0.1 sono due cose diverse :-/

Infatti mentre “mysql -h localhost” usa un socket unix, “mysql -h 127.0.0.1” usa un socket IPv4.

Ci ho sbattuto la testa facendo dei test con il Corra su un banale tunnel ssh:
ssh -N -f -L 4406:localhost:3306 mioserver

Tentando di collegarmi: “mysql -h localhost -P 4406 ...”
mi trovavo collegato al daemon sulla mia macchina… usando il socket unix il client non segnala il fatto che il “-P” viene bellamente ignorato :-/

L’unico modo è quindi: “mysql -h 127.0.0.1 -P 4406 ...”

Unica accortezza, se si vuole accedere al server solo tramite tunnel è quindi quella di mettere un bel “bind-address=127.0.0.1” in my.cnf.

Oggi ho avuto il tempo di scrivere qualche riga di perl per provare Geo::IP.

Notevole. Veramente pochi gli ip non identificati e soprattutto infinitamente più veloce che fare un reverse lookup. Non ho misurato i tempi ma per 45milioni di hit (della scorsa settimana) ci ha messo meno di 10 minuti sulla mia workstation!

Inquietanti anche i risultati. Ecco la top 10 (hits/country):
25669160 ITA (Italy)
1805657 CHN (China)
1613418 USA (United States)
1286303 CHE (Switzerland)
1193314 GBR (United Kingdom)
1004171 DEU (Germany)
861986 SWE (Sweden)
806106 FRA (France)
753138 JPN (Japan)
683252 IDN (Indonesia)


Finalmente sono riuscito a configurare l’accesso a internet con il cellulare gprs collegato via bluetooth.

Configurare la porta /dev/rfcomm0 è stato semplice. Il problema era che la connessione veniva abbattuta subito dopo aver inserito il pin sul cellulare… mancava una libreria al programma che gestisce il pin, che oltretutto vuole un display (X11) aperto, percui l’ho riscritto per funzionare in linea di comando.

Il secondo ostacolo è stata sulla sequenza AT, la soluzione che funziona per me:

ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT 'NO DIAL TONE' ABORT 'NO ANSWER' ABORT DELAYED
'' ATZ
OK-AT-OK ATH
OK-AT-OK ATE1
OK-AT-OK AT+CGDCONT=1,"IP","internet.wind","",0,0
OK-AT-OK AT+CGQREQ=1,0,0,0,0,0
OK-AT-OK AT+CGQMIN=1,0,0,0,0,0
OK-AT-OK ATDT*99***1#
CONNECT \d\c


Visto che la macchina che mi hanno promesso per sostituire S2 a breve non arriverà, oggi mi sono deciso a metter mano a postfix sul server in produzione.

Operazione alquanto delicata visto che si trattava di passare da un postfix vecchissimo installato con rpm (s2 è infatti una redhat) all’ultima release stabile (2.0.19) dai sorgenti. Scopo primario dell’upgrade era quello di usare varie nuove funzionalità soprattutto nell’ottica di ridurre spam e virus.

Per fortuna il lavorone a “caldo” sembra non aver dato grossi problemi. Ho dovuto fare un po’ di modifiche alla configurazione e con l’occasione ho riscritto da zero il main.cf

Come si vede dal grafico ora sono molte di più le email rifiutate (rejected) rispetto a quelle bounced. Prima dell’upgrade molte email venivano accettate da postfix per essere poi rifiutate dal sanitizer che gira con procmail. Il carico della macchina è quindi diminuito notevolmente. (Virus e Spam nel grafico non fanno fede)

Mi sono accorto di un piccolo sminchio nello script che lancia analog.
Per calcolare il nome del mese passato usavo ‘1 month ago’ come parametro a “date”, ma lanciato oggi mi da’ come risultato marzo:

fabio@gnu:~$ date --date='1 month ago' +'%Y%m'
200403


Dopo un primo momento di panico mi sono reso conto di dove fosse il problema… marzo ha 31 giorni, febbraio no… il 31 febbraio non esiste… Il problema è che viene contato come marzo!

Cmq, ho trovato la spiegazione in ‘info date’:

The fuzz in units can cause problems with relative items. For
example, `2003-07-31 -1 month' might evaluate to 2003-07-01, because
2003-06-31 is an invalid date. To determine the previous month more
reliably, you can ask for the month before the 15th of the current
month. For example:
$ date -R
Thu, 31 Jul 2003 13:02:39 -0700
$ date –date=”-1 month” +’Last month was %B?’
Last month was July?
$ date –date=”$(date +%Y-%m-15) -1 month” +’Last month was %B!’
Last month was June!

Giornata dal traffico impressionante. La cache che ho configurato su luisito per www funziona ma sicuramente va ottimizzata.

Luisito è una macchinetta molto meno potente di veleno (su cui gira www) ma deve fare solo da proxy+cache. La scelta è riacaduta per vari motivi su Apache2 lasciando al secondo posto squid, ma non è detto che si provi un giorno anche con quest’altro :-)

Attualmente apache2 gira con il mpm_prefork che come in apache(1) esegue un processo per ogni client. E’ stato però introdotto il parametro ServerLimit che costituisce un vincolo per il parametro MaxClients. In questo modo non c’è bisogno di ricompilare apache per avere più di 256 clients (prima l’hard limit era “cablato” nei sorgenti).

In questi ultimi giorni il numero di client supera spesso i 512 e abbiamo impostato il valore a 800. Preso dall’euforia verso mezzogiorno, con più di 40MB di banda smazzati, ho portato il numero di client a 1024. Dopo non molto la macchina era praticamente collassata per le troppe risorse allocate sotto il grosso traffico. Unica soluzione per riuscire a domare la situazione è stata quella di collegarsi al catalyst e fare lo shutdown della porta, solo dopo questa operazione sono riuscito a collegarmi nuovamente a luisito dalla seconda scheda di rete e a rivviare apache2 con un ServerLimit più basso.

BTW, mi sono accorto proprio ieri che con apache2ctl, dopo una modifica di tale parametro, bisogna fare uno stop e poi uno start (TERM); un restart (HUP), o un graceful (USR1) non sono sufficienti.

Mi sono anche deciso ad utilizzare la seconda scheda di rete di luisito per il traffico verso veleno in modo da dividere il traffico (ormai elevato) tra le due interfacce.

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
--------------------
--------------------
--------------------
[...]


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 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


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 :-/ )

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.