Karmic, vecchie schede Radeon e effetti desktop

In molti avranno notato che da un po' di tempo i driver proprietari di Ati (fglrx) non supportano più alcuni modelli di schede video vecchiotte. Per queste schede (io ho una Radeon 9550) funziona bene il driver radeon open source. Tuttavia su Ubuntu Karmic Koala, per quanto la scheda sia correttamente riconosciuta e configurata, risulta impossibile abilitare gli effetti desktop.
Frugando qua e la per la rete ho trovato una soluzione che pare funzionare bene senza troppe complicazioni e, soprattutto, senza dover installare pacchetti dai repository di testing.

La soluzione consiste nella modifica di due files:

1) aprire /etc/xdg/compiz/compiz-manager e aggiungere questa riga:

SKIP_CHECKS="yes"

2) aprire /etc/X1/xorg.conf, cancellare tutto quello che è presente e inserire queste righe:

Section "Device"
Driver "ati"
Identifier "Radeon 9550"
Option "BusType" "PCI"
Option "AccelMethod" "EXA"
Option "MigrationHeuristic" "greedy"
Option "AGPSize" "64"
EndSection

Section "Monitor"
Identifier "Configured Monitor"
EndSection

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Radeon 9550"
DefaultDepth 24
EndSection

Section "Module"
Load "dri"
Load "GLcore"
EndSection

Fonte (parzialmente modificata): http://ubuntuforums.org/showthread.php?p=8263824#post8263824

Ovviamente è valido, anzi consigliato, sostituire 'Radeon 9550' con il modello appropriato.
Applicando solo la prima modifica gli effetti desktop sembrano poter partire ma lo schermo rimane inesorabilmente bianco e non funziona più nulla, applicando anche la seconda invece funziona tutto perfettamente.

Organizzare e ricercare le pagine web (e non solo): Zotero

Vi è mai capitato di ricordarvi che in una tal pagina web avevate trovato un informazione interessante, di averla salvata nei preferiti, e di non riuscire a trovarla lo stesso?

Recentemente mi sono imbattuto in questo: http://www.zotero.org.

E' un plugin per firefox, nato originariamente per archiviare, organizzare e utilizzare le fonti bibliografiche, quindi indirizzato principalmente a studenti e ricercatori. In realtà  può essere usato per archiviare e catalogare qualunque tipo di informazione trovata sul web. Può archiviare intere pagine, o parti di esse, indicizzandone il contenuto, in modo che sia facile poi fare una ricerca. Non viene salvato solo il bookmark della pagina ma una copia dell'intera pagina. In tal modo possono essere recuperate anche informazioni non più presenti sul web.

Possono essere archiviate note scritte a mano e documenti di vario tipo (immagini, pdf etc.). Tutto questo è completato infine dalla possibilità di registrarsi (gratuitamente) sul sito in modo da poter usufruire di uno spazio di archiviazione di 100Mb. In questo modo è possibile archiviare i dati su un server remoto e usare il plugin zotero su diversi pc avendo sempre a disposizione i propri dati perfettamente sincronizzati.

Lo sto provando in questi giorni con l'idea di usarlo al posto dei vari gestori di bookmarks (ormai quasi inutilizzabili per la quantità di pagine salvate) per archiviare le pagine web interessanti e, mi auguro, per trovare rapidamente quello che mi serve. Lo strumento indubbiamente non è semplice come l'aggiunta di un indirizzo ai preferiti ma per il momento sembra davvero un bel salto di qualità.

Rdesktop e numero massimo di connessioni terminal server

Non vi capita mai di connettervi ad un server windows usando rdesktop e trovarvi di fronte a questo messaggio?



Piuttosto fastidioso, significa che ci sono delle connessioni ancora attive e che altre, ahinoi, non se ne possono aprire.
Ebbene: ci si può connettere a quella macchina aggiungendo alla linea di comando di rdesktop l'opzione '-0' che ci connetterà  alla sessione 0 amministrativa del server, che è poi la stessa che si usa in locale. Per esempio con questa riga di comando apriamo una finestra di 1024x768 pixel, con tastiera italiana e forziamo l'uso della sessione 0 amministrativa:

rdesktop -g 1024x768 -k it -0 nome_o_ip_server

In caso ci sia già  qualcuno gia loggato sulla sessione 0 costui verrà buttato fuori senza pietà se si tratta di una connessione remota o messo in lock se è invece locale..
In sostanza questa opzione ricalca l'opzione '/console' che si può dare al client per connessione remota di windows subito dopo al nome del server o all'indirizzo ip.
Ovviamente possono fare il login nella sessione 0 amministrativa solo gli utenti appartenenti al gruppo degli amministratori.
Non è chissà quale scoperta, ma me lo dimentico ogni volta, quindi me lo scrivo :-)

Restricted bash con apparmor

Molto spesso si ha l'esigenza di limitare quello che un utente può fare da una shell Linux. Storicamente su linux esiste il comando rbash (restricted bash) , che dovrebbe permettere di  bloccare gli utenti nella loro home e di consentirgli solo un set limitato di comandi.

Tuttavia molti non ritengono rbash particolarmente sicuro. Apparmor è invece ritenuto decisamente più sicuro, è  più maneggevole e più semplice da configurare.

Voglio riportare qua una semplice ricetta su come usare apparmor per creare una shell che consente ad un utente non privilegiato di utilizzare solo il comando ssh per connettersi a macchine remote, e niente altro. Una volta capite le basi di come procedere l'unico limite su cosa permettere o bloccare è la fantasia.

Cache plugin per wordpress a confronto

Mentre facevo un po' di performance tuning su un server web dedicato all'hosting condiviso mi è venuta la curiosità  di provare alcuni plugin di caching per wordpress. Per chi non lo sapesse i plugin di caching per wordpress a grandi linee fanno in modo di salvare su disco una copia statica delle pagine servite in modo da velocizzare le successive richieste e, nel contempo, ridurre il lavoro che deve compiere il server per eseguire codice php e query sul database.

Nuovo lavoro

E' da tanto tempo che non scrivo più nulla sul blog. Il fatto è che da luglio ho iniziato un nuovo lavoro che fino ad oggi mi ha completamente assorbito. Le energie mentali per scrivere qualcosa qua dentro sono ridotte al lumicino. Ma la situazione si sta assestando, lo shock da cambiamento sta scomparendo e sto rientrando in una dimensione un po' più normale.

Tra non molto credo che ricomincerò a scrivere qualche articoletto tecnico (la carne al fuoco non manca ;-)).

Nel frattempo mi scuso con coloro a cui non ho mai dato risposta. Forse sarò in grado di darne, ma forse anche no.

Ltsp su hardy

Finalmente trovo il tempo di scrivere qualche rapidissimo commento su ltsp su Ubuntu 8.04 (Hardy Heron).

Ad un primo colpo d'occhio ho notato che più schede grafiche vengono riconosciute correttamente e che viene settata la risoluzione corretta anche su monitor wide screen: senza fare niente di particolare mi è partito un thin client con il monitor wide screen correttamente impostato a 1440x900.

Ma tutti i piccoli miglioramenti passano un po' in secondo piano a causa di un serio problema in fase di installazione: il comando ltsp-build-client non va a buon fine e, dopo un po' che lavora, restituisce questo messaggio di errore:

Truffe e registrazione domini

Quattro o cinque anni fa avevo trovato un registrar particolarmente economico per comprarmi un paio di domini a poco. Si chiama (anzi, si chiamava) assurancehosting.com. Fino all'estate scorsa sembrava funzionare tutto abbastanza bene: avevo rinnovato senza problemi una registrazione. Qualche tempo fa mi è arrivata la solita mail che mi avvisava dell'imminente scadenza di un altro dominio. Ho quindi provato ad accedere al sito del registrar per effettuare il rinnovo ma - sorpresa - il sito non esiste più. Al suo posto una delle classiche pagine di parcheggio con link a pubblicità e motori di ricerca.
Ho indagato un po' e tramite whois ho visto che il mio dominio risultava gestito non più da assurancehosting.com ma da enom.com.
Ho pensato (probabilmente sbagliando) di lasciare scadere il dominio in questione, per registrarmelo di nuovo più tardi. E' stato un grave errore. Il dominio in questione risulta adesso gestito da enom.com. La cosa divertente è che una ricerca sui whois convenzionali non riporta nessun cambiamento, lo definisce come scaduto in data 21/4/2008. Invece una ricerca su whois.enom.com aggiunge qualche dettaglio in più: registrazione valida fino al 21/4/2009 (prolungata di un anno), status: "registrar-lock". In sostanza me l'hanno fregato prendendoselo automaticamente alla scadenza. Se lo voglio indietro devo prenderlo tramite afternic.com (di proprietà della stessa enom.com) e devo fare un offerta base di minimo 200$. Non c'è che dire: una bella trovata per fare soldi, non bella ma probabilmente legale.
In qualche forum ho letto di gente che ha decine di domini in questa situazione, e non domini fatti per hobby (che un po' dispiace ma in fondo c'è di peggio), ma nomi di dominio di aziende, le quali sicuramente saranno costrette a sborsare un minimo di 200$ per ogni nome.
Forse dovevo provare a fare un transfer prima che scadesse, cosa che sto provando a fare adesso per il dominio ancora valido. Il problema è che per fare un transfer devi prima pagare colui che sarà il nuovo registrar e poi provare il trasferimento, e io in genere i domini li tengo bloccati, come è giusto che sia.
Adesso sono in attesa del codice per poter procedere al trasferimento verso il nuovo registrar. Si prospettano due scenari:
1) Enom quando ha rilevato i domini registrati col defunto assurance hosting li ha posti in sblocco, chi provvede al trasferimento prima della scadenza può farlo senza problemi. Chi non provvede in tempo se li fa fregare e li deve recuperare a caro prezzo da afternic (che è sempre enom). Manovra da malviventi ma la possibilità te l'hanno data. E chi non lo fa è un pollo. Io lo sono stato per il dominio che ho fatto scadere ma riuscirò a riprendermi il secondo.
2) Enom rileva i domini di assurance hosting e li tiene bloccati. Io non riuscirò a trasferire il mio (buttando via 9$ nel tentativo) e alla sua scadenza se lo vorrò dovrò ricomprarmelo a caro prezzo su afternic. Se così fosse sarebbe davvero da denuncia. Stiamo a vedere.

Squid e autenticazione su ldap

Uno dei commenti al blog degli ultimi giorni mi ha fatto venire in mente una cosa che avevo messo in piedi tempo fa, che funziona molto bene e che può tornare molto utile per gestire/limitare/loggare gli accessi al web da una rete privata. Volevo fare in modo che il proxy server squid effettuasse le autenticazioni su un directory server openldap, ma ricordo di aver trovato qualche difficoltà nel reperire documentazione e di aver sudato non poco prima di riuscire. Quindi, nella speranza che sia utile a qualcuno, riporto qua le 4 righe da inserire in squid.conf per abilitare questa funzionalità.

LTSP tips & tricks

In questo post voglio svelare qualche piccolo trucchetto nell'impostazione del sistema LTSP su Ubuntu Gutsy che ho scoperto sulla mia pelle perdendoci molto tempo e prendendomi molte arrabbiature (e anche purtroppo qualche improperio dai clienti;-)). Alcuni sono farina del mio sacco, altri si scoprono frugando qua e la nel web, dispersi magari in qualche oscuro forum o bug report. Per questo credo sia utile metterli assieme tutti in una volta. Li dividerò in due tipi: quelli che risolvono problemi gravi e quelli che portano semplicemente qualche miglioramento al sistema.

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.

LTSP su Ubuntu Gutsy: sempre più facile

Oggi è il 18 Ottobre, data in cui dovrebbe uscire la release 7.10 di Ubuntu (Gutsy Gibbon). Sul sito di Ubuntu ancora non è comparso nessun annuncio, tuttavia è da parecchie ore che non escono pacchetti aggiornati, quantomeno riguardo al software che uso io, quindi ritengo che i miei pc su cui gira Gutsy possano essere ormai considerati "stabili".

Ho provato a ricreare l'ambiente LTSP server + thin client per verificare eventuali differenze rispetto alla release precedente e, ovviamente, eventuali miglioramenti. Sulla macchina destinata a fare da server (in realtà il mio desktop in ufficio) ho lanciato il comando:

aptitude install ltsp-server ltspfs

e ho accettato di installare le relative dipendenze.

Non ho assolutamente preso in considerazione questo messaggio:

NOTE: you will probably want to add to /etc/exports:
/opt/ltsp *(ro,no_root_squash,async)
and then run:
invoke-rc.d nfs-kernel-server reload

perchè il pacchetto nfs-kernel-server non è installato e non è stato richiesto durante la fase di installazione, si tratta probabilmente di un refuso. Finita l'installazione ho semplicemente lanciato il comando:

ltsp-build-client

e ho aspettato la fine del processo.

Backup su server FTP

Segnalo un utile strumento che serve a mantenere sincronizzati una directory locale e una remota su un server ftp.
Si tratta di FTPSync.pl che, come si intuisce dal nome, è uno script in Perl.

Traduco parte di quanto scritto nel file README,:

"Ftpsync.pl mantiene sincronizzata una gerarchia di directory locali con una gerarchia di directory remote su un server ftp. E' stato inizialmente scritto per automatizzare operazioni di web publishing ma può risultare utile per numerose altre operazioni, come fare un mirror di siti pubblici non troppo grossi, replicare dati e molto altro.

Perchè usare ftpsync.pl invece di mirror, sitecopy ....?

E' vero, ci sono altri progetti simili, alcuni commenti su questi:

rispetto a mirror, ftpsync.pl è in grado di fare anche PUT, non solo GET (se mirror è in grado di fare anche PUT non prendetevela con me, io non ci sono riuscito). Rispetto a sitecopy, ftpsync.pl non ha alcun problema se il sito remoto dopo l'ultima sincronizzazione viene modificato da altri tool o processi. Ftpsync.pl, a meno di problemi di connettività o di bachi, fornisce sempre una sincronizzazione affidabile. Rispetto a tutti e due ftpsync.pl è estremamente leggero."

Aggiornamento a WP 2.3

Lo sapevo che sarebbe potuto succedere. Aggiornando il blog a Wordpress 2.3 mi si è pesantemente sbelinato il tutto. Il tema che avevo faticosamente modificato e adattato non funziona più. Non vengono più riconosciuti i tags e ci sono tutta una serie di altre fastidiose anomalie.

Sono costretto a tornare temporaneamente al tema di default di WP, nel frattempo vedrò di sistemare il vecchio tema oppure, perchè no, metterne uno nuovo.