Il tuo server linux personale

Se quello che hai sempre cercato e' avere il tuo personalissimo server linux up and running 24 ore su 24, SliceHost e' l'opzione giusta per te.

Questa meravigliosa azienda americana (in Italia purtroppo certe cose ce le sogniamo alla grande!) ha sviluppato un sistema automatico con interfaccia web in grado di fornirti in tempo reale per pochi dollari al mese una tua personalissima macchina virtuale con cui potrai realizzare e gestire il tuo server linux in tutta tranquillita'.
Banda e connettivita' internazionale a internet non sono un problema e potrai scegliere tra vari tagli di offerte pronte per te.

Se sei interessato, dai un'occhiata al sito https://manage.slicehost.com/customers/new?referrer=af57db3020e04bb27352e271753a7a18 e affiliati anche tu.

Avrai la possibilita' di scegliere la distribuzione linux che piu' ti aggrada e il tuo server linux personale sara' in piedi in pochi secondi.

Noi di TuxWeb lo stiamo utilizzando con successo per gestire i siti internet di alcuni nostri clienti.

Ciao, Dino - http://www.tuxweb.it/

DynaBlast, and your access_log give you something

If you want an access_log scanner written in C that check for you every IP address that exceed a given number of hits in the last given time period, then DynaBlast is a tool that make sense for you.

This tool, released as usual in GPLv2, can be spawned every minute in crontab without the risk of having two instances running: we make use of a lock mechanism.
It has a fast mode that can skip already parsed line from a consecutive scan, so each time it runs, it play very fast.

In stdout you'll get the scanning result. Ex:

blacklisted:10.248.220.43
blacklisted:23.212.121.165

You can download DynaBlast from here: http://www.tuxweb.it/?section=progetti/dynablast

Ciao, Dino.

Scandalo, the fast and Simple clamdscan mail frontend

Hi people.
I'm now talking about a simple GPLv2, C written, small program that work as a very fast clamdscan antivirus frontend.

Scandalo can take a mail on standard input and parse it from viruses, piping it to clamdscan.
It then get the virus status from clamdscan and put a mail header called "X-Virus-Ret" returning the virus scanner status.
It also put a mail header called "X-Virus-stream" returning the first virus name found (if any).

You can then setup a rule on your (say, maildrop) mail filter to pipe the incoming mail to scandalo, and another rule to check the return scanned mail header for viruses.
If a virus was found, you can drop the mail, or put it into a .Virus maildir.

If you have any question, I'm the developer of scandalo.
Scandalo - http://www.tuxweb.it/?section=progetti/scandalo&

Write me a note at dino@tuxweb.it.

Ciao, Dino.

Per un buon mailserver

Chiunque ha, o abbia provato ad avere un proprio mailserver per spedire mail in uscita ha potuto costatare personalmente che moltissimi mailserver dall'altra parte del filo hanno dei sistemi di blacklist per cercare di combattere lo spam, e che presto o tardi finiscono con il bloccare temporaneamente il nostro IP, o peggio mandare le nostre mail nella cartella Spam del destinatario.

Sebbene non esista un capitolato standard, dopo qualche anno di combattimento con le mail ho potuto stilare una serie di buone regole per cercare di attenuare la problematica.

Io utilizzo da anni Courier MTA (http://www.courier-mta.org/) e mi trovo veramente bene, ad ogni modo le seguenti regole valgono per qualsiasi mailserver.

Attenendosi alle seguenti regole, sara' possibile inviare tante mail senza troppi problemi.

1) utilizza NECESSARIAMENTE un IP statico per inviare le mail
2) crea un Reverse PTR record sul DNS per il tuo IP e chiamalo mail.tuodominio.it
3) crea un A record chiamato mail.tuodominio.it sul DNS che punta all'IP
4) crea un MX record per accettare le mail in ingresso/ritorno e fallo puntare a mail.tuodominio.it
5) crea sul DNS il TXT record per il Sender Policy Framework e crea regole che abilitano a spedire posta dal tuo dominio solo dall'IP del mailserver
6) fai utilizzare al tuo MTA una connessione di rete stabile, e soprattutto un DNS stabile e veloce!!
7) crea sul server SMTP un account postmaster@tuodominio.it
8) disabilita il relaying per il tuo mailserver. Se lo devi abilitare, crea degli utenti abilitati al relaying con password robuste e abilita SSL sul server SMTP
9) fai uscire dall'IP del tuo MTA solo le mail originate dal tuo mailserver. Se ad esempio c'e' un Firewall che fa source NAT in uscita, fai in modo di aprire la porta di destinazione 25 sul firewall verso internet solo ai pacchetti provenienti dal mailserver. Se hai nella tua rete altri client SMTP che creano mail in uscita spegnili, o falli passare necessariamente in relaying per il tuo MTA
10) utilizza se possibile accorgimenti atti a sopprimere i Delivery Status Notification per le mail in ingresso, come ad esempio ritornare errore subito durante la ricezione della mail se un utente non siste o la mail viene bloccata
11) utilizza un sistema antispam come spamassassin e abilita le blacklist IP basate su DNS per tutte le mail in ingresso
12) imposta il tuo "Helo" message sul mailserver affinche' si esponga sempre come "mail.tuodominio.it"
13) se possibile, per le mail in relaying, configura il tuo mailserver per strippare i "Delivered to" headers. In questo modo gli altri mailserver crederanno che la mail in relaying e' stata generata dal tuo mailserver.
14) se possibile, quando spedisci le mail, utilizza sempre come mittente un account esistente che corrisponda ad un dominio gestito dal tuo mailserver
15) evita se possibile account non esistenti del tipo "no-replay@tuodominio.it". Nel caso ti servisse, crea l'account e scarta tutte le mail in ingresso buttandole in "/dev/null"

Queste regole sono secondo me un buon modo per evitare di finire velocemente nelle miliardi di blacklist in giro per il mondo.

Mi raccomando, scrivetemi a dino@tuxweb.it e fatemi sapere se funziona, o mandatemi i vostri suggerimenti con altre regole e io le integrero'.

Ciao, Dino.
http://www.tuxweb.it/

Oracle alert log block parser in bash/ksh

A volte puo' essere necessario analizzare i file alert log di oracle. Molto spesso ci si rende conto che il formato di log prodotto non e' molto leggibile. Vi e' mai capitato?
Io credo di si. A tal proposito, cioe' proprio per cercare di rendere piu' facilmente leggibile il file alert log, e per avere a disposizione in modo rapido un determinato blocco del file di log ho scritto un semplice script ksh (funzia sia su Linux che HP-UX, e molto probabilmente anche su SunOS).

Lo rilascio a disposizione per tutti. Usatelo nei termini della licenza GPLv2!!

Ciao, Dino.

Lo script: http://www.tuxweb.it/scripts/alertlogblockalalyzer.sh

SliceHost versus VPS

Cari amici, oggi voglio portarvi la mia esperienza su due provider che permettono di creare via WEB e per pochi soldi una macchina virtuale personale.

- http://www.slicehost.com/
- http://www.vps.net/

Per chi non li conoscesse, e' possibile avere un proprio server virtuale con RAM, CPU, DISCHI e IP dedicati con tanto di interfaccia di amministrazione WEB (per accensione, riavvio, spegnimento dela VM), una virtual console web based, e accesso via SSH con password di root.

Dopo aver testato approfonditamente i due provider, vi enuncio il mio verdetto a riguardo: SliceHost batte VPS per 10 a 0.

Elenco brevemente i motivi:

1) Il sito di SliceHost e l'interfaccia di gestione sono molto veloci e snelli, quello di VPS invece sono estremamente lenti e macchinosi

2) Ad ogni comando impartito all'interfaccia di gestione, SliceHost risponde in tempo reale e fornisce feedback all'utente sul tempo stimato, mentre VPS riporta una fastidiosissima e inutile dicitura (This VPS is currently running a task) che rimane fissa per molti minuti prima di eseguire il comando impartito e rende impossibile impartire qualsiasi ulteriore comando

3) La console di amministrazione di VPS non funziona correttamente su firefox, mentre quella di SliceHost funziona alla grandissima

4) Slicehost esegue i comandi in tempo reale, VPS rende di fatto indisponibile la macchina virtuale per numerosi minuti in caso di reboot, spegnimento o accensione della VM

5) Su slicehost ho la macchina in piedi da piu' di 2 anni senza un periodo minimo di downtime. Su VPS, dopo meno di 15 giorni il filesystem "/" si e' corrotto e sono stati riportati errori di I/O error che hanno reso la macchina virtuale inservibile e non ripristinabile

6) Slicehost fornisce un set di API per l'amministrazione remota delle slice (virtual machine), oltre che una semplice applicazione di amministrazione che gira su Android e IPhone, ovviamente VPS questo non lo fornisce

7) Slicehost fornisce la possibilita' di avere IP privati e banda cumulabile se si comprano piu' virtual machine, cosa non disponibile su VPS

8) La risposta ai Trouble Ticket su slicehost e' velocissima e molto precisa, mentre su VPS sono lentissimi, anche se abbastanza precisi

9) Utilizzando Slicehost si nota subito un senso di professionalita' che utilizzando VPS non ho notato, forse dovuto al fatto che hanno dei tecnici molto forti, l'interfaccia web funziona e tutto gira liscio, mentre su VPS si ha un senso di pesantezza generale del sistema.

10) Ultimo punto, forse quello meno importante, Slicehost utilizza un meccanismo di Referral per i nuovi clienti. Anche se questo non porta benefici reali, e' sicuramente una cosa carina.

Ah, dimenticavo. Per chi fosse interessato:

https://manage.slicehost.com/customers/new?referrer=af57db3020e04bb27352e271753a7a18

Ciao, Dino,

Come utilizzare openssl per creare una CA

Ciao gente.
Oggi ho avuto necessita' di creare un ente certificatore con openssl.

I passaggi che ho eseguito sono questi:

# Generazione della chiave privata dell'ente certificatore
openssl genrsa -des3 -out ca.key 4096
# Generazione del certificato dell'ente certificatore
openssl req -new -x509 -days 9999 -key ca.key -out ca.crt

# Creazione della chiave privata del server
openssl genrsa -out server.key 2048
# Generazione del CSR del server
openssl req -new -key server.key -out server.csr
# Creazione del certificato server e firma con il certificato dell'ente certificatore
openssl x509 -req -in server.csr -out server.crt -sha1 -CA ca.crt -CAkey ca.key -CAcreateserial -days 1365

# Creazione della chiave privata del client da autenticare
openssl genrsa -des3 -out user.key 1024
# Generazione del CSR del client
openssl req -new -key user.key -out user.csr
# Creazione del certificato client e firma con il certificato dell'ente certificatore
openssl x509 -req -in user.csr -out user.crt -sha1 -CA ca.crt -CAkey ca.key -CAcreateserial -days 1365
# Conversione in formato PKCS#12
openssl pkcs12 -export -in user.crt -inkey user.key -name "Nome e cognome" -out user.p12

Se avete domande chiedete.
Ciao, Dino.

Android G1 americano brandizzato T-Mobile importato in italia? Bollette pazze!!

Ieri sono stato contattato dall'amministrazione dell'azienda per cui lavoro chiedendomi se avevo attivato un abbonamento SMS simile a quelli del famoso gattino Virgola. Ovviamente la risposta e' stata no.

Il motivo della domanda e' scaturito da un numero estremamente alto di SMS trovati nella bolletta aziendale Vodafone che il mio nuovissimo Android G1 brandizzato T-Mobile US e importato dagli Stati Uniti ha spedito a mia insaputa ad un misterioso numero: il "453".

Cercando sul web ho trovato piu' di un paio di link che delucidavano la situazione, ne riporto un paio:

- http://forum.xda-developers.com/showthread.php?t=444114
- http://forum.xda-developers.com/showthread.php?t=454209

In sostanza, i costosi sms vengono spediti a intervalli regolari all'insaputa dell'utente per colpa di un servizio auto partente presente nel firmware ufficiale T-Mobile US, ospitato nei cellulari americani.

Mentre questo negli States non e' un problema in quanto T-Mobile non fattura agli utenti questo tipo di SMS, per noi italiani il problema esiste e come, arrivando a consumare piu' di 180 euro al mese per servizi mai utilizzati, e soprattutto senza il bene placido del proprietario.

Questo servizio (per servizio si intende un programma informatico che gira in background, non che per noi sia un servizio utile!! ndr) si chiama "com.tmobile.myfaves".

MyFaves e' in sostanza un piano tariffario americano di T-Mobile che permette di telefonare in tutto il mondo a tariffe particolari, e in piu' permette di condividere testo, immagini, ringtone, e quant'altro.

Ovviamente nel firmware ufficiale di Android risulta impossibile disattivare il servizio e quindi l'invio indesiderato di SMS.

L'unico modo per ora e' installare sul telefono un firmware non ufficiale che non contenga l'applicazione MyFaves.
Io ho risolto installando il firmware JesusFreke's 1.51 EU basato sulla release Android CRB43. Incollo sotto il link da cui potete scaricare il software:

- http://jf.andblogs.net/2009/05/24/jfv151-images-are-out/

Le operazioni per flashare questo firmware non sono proprio banali e necessitano di un minimo di conoscenze informatiche, dipendono dalla versione del priorio firmware Android attualmente installato sul telefono e sono potenzialmente rischiose. Il rischio infatti e' quello di far diventare il proprio telefono un mattoncino, quindi inservibile. Tuttavia l'operazione non e' molto lunga e in un paio di ore se tutto viene fatto bene si dovrebbe risolvere.

Sto scrivendo una mini guida con i passaggi che ho personalmente eseguito e la pubblichero' molto presto su queste pagine.

Per ora, ciaux!!

dAm2K -- Dino Ciuffetti - dino at tuxweb dot it

TuxWeb S.r.l.
http://www.tuxweb.it/

Debian BUG #513916 solved!!

Hey people, yesterday I have filed my first debian bug!
It was debian bug #513916, and today I have submitted the solving patch. I didn't write any code line, I just reverted php CVS commit with the solving lines and created the patch... but that's too cool!! :-)

May be the debian php package mantainer will release a new package version with that patch...

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513916
Ciao, Dino.

Buon anno!

Tantissimi auguri a tutti voi per un meraviglioso ottimo 2009!