Piccoli furti sul web

L'altro giorno, mentre cercavo su google non ricordo più quale informazione sui thin client, mi sono imbattuto in una frase che mi sembrava di conoscere bene. Ho aperto il link e mi sono trovato davanti ad un mio articolo copiato quasi integralmente sul sito di una società di informatica.Tutto questo, naturalmente, senza essere citato e togliendo l'unica parte che poteva stonare. In pratica il Sig. Enzo Criscione, titolare della Pigreco software, ha pensato bene di appropriarsi del mio testo millantandolo come know how della sua azienda.

Il 1 aprile ho usato la form del suo sito per scrivergli questa mail:

Thin client Lucida LT2610

Mi è stato dato in prova un thin client Lucida LT2610 col quale ho fatto qualche esperimento con Ubuntu e LTSP. Si tratta di un oggetto davvero carino, un piccolo PC dotato di un micro sistema operativo (Linux) in grado di iniziare come client delle sessioni RDP (il terminal server di Microsoft) e Citrix Winframe e Metaframe. Ma, cosa che a noi interessa di più, è in grado di fare il boot direttamente da rete usando il protocolllo PXE, cioè quello che viene usato per avviare un client LTSP.

L'hardware è basato sul processore AMD Geode LX 800 per sistemi embedded. Il sistema è dotato di 64Mb di memoria DOM (Disk on Module Flash Drive) e di 128Mb di RAM. Sono presenti due porte USB 2.0, i jack audio in e audio out, due prese PS2 (mouse e tastiera), la presa ethernet, una seriale e una parallela. Il sistema non ha ventola nè altre parti in movimento. Le sue dimensioni sono di  16.6x4.5x24 cm, per poco più di 600g di peso. Il consumo dichiarato è di 10W.

L'ho provato come client per sistemi LTSP con Ubuntu, prima con la versione 7.10 (Gutsy) che è la versione attualmente stabile, e poi con la 8.04 (Hardy), attualmente in beta e la cui uscita è prevista per il 18 aprile 2008.

Pythonfilter: antispam e antivirus per Courier-mta

Il server di posta Courier-mta è uno dei miei preferiti da tempo. Ne ho alcune installazioni funzionanti da qualche anno e non ho mai avuto problemi o strane sorprese. Trovo la configurazione di tutti i servizi relativamente facile, e apprezzo la sua spartanissima interfaccia web (opzionale) che rende ancora più semplice la configurazione.

Per una delle macchine su cui gira Courier (un vecchio server Debian che passando per vari aggiornamenti adesso è Etch) ero alla ricerca di un sistema per implementare le greylist. Per chi non lo sapesse il sistema delle greylist si basa su un semplicissimo dato di fatto: la maggior parte degli spammatori professionisti usano software appositamente realizzati che, al contrario dei server di posta convenzionali, prevedono un solo tentativo di invio per ogni messaggio. Se il primo invio, per qualsiasi motivo, non avviene correttamente il messaggio non verrà più inviato. Le greylist sfruttano questa peculiarità dei messaggi di spam. Semplificando molto, funzionano restituendo un errore temporaneo ai messaggi provenienti da mittenti sconosciuti. Se il messaggio proviene da un server normale, pochi minuti dopo verrà inviato nuovamente, il mittente finirà in whitelist (non verrà più filtrato) ed il messaggio sarà correttamente processato. Se invece il messaggio proveniva da uno spammatore, semplicemente non arriverà mai più.

La prima volta che ho sentito parlare di greylist e che ho provato a utilizzarle (credo nel 2004, usando l'ottimo ASSP) ho osservato che circa il 90% delle mail non venivano inviate una seconda volta. Decisamente un bel lavoro in meno per il server di posta e per eventuali altri filtri antivirus o antispam!! E da allora la situazione non è cambiata molto, probabilmente perchè la gestione delle code di invio risulta totalmente antieconomica per l'invio di grossi volumi di spam. Ci sono purtroppo alcuni (pochi per fortuna) server normali mal configurati che non effettuano un secondo invio, ma sono regolarmente segnalati in apposite liste disponibili su internet. In tutte le implementazioni di greylist che conosco esiste la possibilità di inserire i loro indirizzi ip manualmente o in automatico tra quelli da non filtrare.

Primoautore: sistema online di certificazione di opere digitali

Da qualche giorno è attivo questo servizio che sicuramente risulterà interessante per tutti coloro che producono "opere di ingegno" e vogliono essere sicuri, per una cifra ragionevole, di poter dimostrare di essere appunto il "Primo Autore" di un'opera.

Riporto testualmente dal sito alcune parti interessanti : "PrimoAutore è un servizio di certificazione temporale che permette di datare in modo certo ed opponibile a terzi opere dell'ingegno, in formato digitale, che siano inedite al fine di poter dimostrare l'esistenza dell'opera in caso di plagio o diffusione illecita in base alla legge sul diritto d'autore.......Possono essere certificati: romanzi, canzoni, racconti, poesie, copioni, trame, soggetti, opere audiovisive, software, banche dati, opere grafiche e, in generale, esemplari di opere dell'ingegno, ovviamente solo in formato digitale."

Sul sito sono presenti dettagliate istruzioni e informazioni di tipo legale. La procedura comunque sembra essere assai semplice.

Io non ho nulla da proteggere, ma se lo avessi una prova la farei. L'idea mi sembra buona.

pulseaudio 0.9.8 per gutsy x86

Visto che non trovavo i pacchetti della nuova versione di pulseaudio (0.9.8) per Ubuntu Gutsy x86, li ho compilati e pacchettizzati a partire dai sorgenti di Debian SID. Ho ricompilato anche libflashsupport (libreria che permette a Flash Player 9.x di funzionare con pulseaudio) dai sorgenti SVN che si trovano qua.

Per chi è pigro e, soprattutto, per poterli ritrovare se ne avrò ancora bisogno li metto qua a disposizione. Gli archivi tar.gz contengono i pacchetti deb.

Librerie e include per pulseaudio.

Pulseaudio, eseguibili e moduli

Libflashsupport

Ltsp su architettura X86_64

In alcuni commenti ad un post precedente si era parlato di LTSP server su architettura a 64 bit. Io, non avendolo mai provato e presumendo complicazioni, sconsigliavo di farlo. Avendo adesso a disposizione una macchina a 64bit ho deciso invece di provare.
Ho installato una versione di Ubuntu Gutsy per AMD64, poi ho creato l'ambiente server per ltsp usando i comandi già descritti in questo post. Dal momento che il server dhcp risiedeva su un'altra macchina della rete ho dovuto semplicemente modificare qualche parametro per indirizzare le richieste di tftp al server giusto. L'unica piccola (ma sostanziale) differenza in tutto il processo è stato il comando per creare l'ambiente chroot dei client: ho infatti usato "sudo ltsp-build-client --arch i386".
Con questa opzione attivata viene infatti costruito un ambiente chroot in grado di far partire i pc con architettura uguale o superiore a i386 (cioè tutti i cosiddetti x86). La scelta è logica poichè i thin client per definizione sono macchine poco potenti e difficilmente vengono costruiti su architetture diverse dalla x86, e comunque all'occorrenza anche un pc con processore X86_64 gira tranquillamente con sistema operativo a 32 bit per i386.
Nella pratica succede che i thin client fanno il boot e avviano i processi di sistema di base a 32 bit nell'ambiente chroot, dopodichè in ambiente grafico (e a questo punto siamo sul server) le applicazioni che vengono lanciate sono a 64 bit. I vantaggi sono evidenti: se vogliamo gestire un numero molto elevato di thin client l'architettura X86_64 è in grado di usare in modo molto più efficiente quantità di memoria ram superiore ai 4Gb. Per una esaustiva discussione sulle differenze tra sistemi a 32 e 64 bit suggerisco di dare un'occhiata qua.

Postfix, Exchange e pipelining

Talvolta da postfix non è possibile inviare posta verso alcuni domini e nei log si trovano dei messaggi abbastanza generici che parlano di "timeout after DATA". In questi casi di solito i problemi vengono attribuiti alla configurazione di alcuni apparati di rete, e come soluzione si suggerisce di agire sulla dimensione degli MTU (Wietse Wenema, creatore di Postfix, in un post su una mailing list suggeriva di usare MTU = 1000, ma ho perso il link) e di disabilitare l'MTU auto discovery (in linux si disabilita con sysctl -w net.ipv4.ip_no_pmtu_disc=1). In altri casi qualcuno suggeriva di agire sui timeout, in postfix ce ne sono parecchi che si possono modificare (per vedere l'attuale configurazione di postfix e avere nel contempo l'elenco dei parametri di configurazione utilizzabili basta digitare "postconf" da linea di comando).

Nel mio caso succedeva che i messaggi solo testo partivano mentre quelli contenenti allegati non ne volevano sapere. Nessuna delle soluzioni suggerite sopra aveva funzionato, il server remoto era un Exchange, si presentava come Microsoft ESMTP Server 6.0.3790.3959. Dopo parecchio tempo speso a cercare la soluzione ho scoperto questo. In pratica alcune versioni di Exchange durante la fase di negoziazione del protocollo millantano di supportare la funzione PIPELINING, mentre invece non è vero: la connessione inizia ma non succede nulla, alla fine del tempo a disposizione la connessione viene chiusa e compare l'errore nei logs.

Occorre quindi dire a postfix di non tenere in considerazione l'opzione pipelining se gli viene proposta da quel particolare server. Ecco come si fa:

Edito il file /etc/postfix/main.cf e aggiungo la riga:

smtp_discard_ehlo_keyword_address_maps = hash:/etc/postfix/ehlo_keywords

Poi edito /etc/postfix/ehlo_keywords in questo modo:

<ip_server_remoto_bacato> pipelining

salvo, chiudo e lancio il comando postmap /etc/postfix/ehlo_keywords

A questo punto "postfix reload" ed il gioco è fatto.