tag:blogger.com,1999:blog-50445901369273374802024-02-20T07:16:20.776-08:00Zaffa.orgUnknownnoreply@blogger.comBlogger32125tag:blogger.com,1999:blog-5044590136927337480.post-61412373618740300592010-02-04T13:49:00.000-08:002013-09-28T06:41:18.634-07:00Karmic, vecchie schede Radeon e effetti desktopIn 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.<br />
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.<br />
<br />
La soluzione consiste nella modifica di due files:<br />
<br />
1) aprire <code>/etc/xdg/compiz/compiz-manager</code> e aggiungere questa riga:<br />
<br />
<code>SKIP_CHECKS="yes"</code><br />
<br />
2) aprire <code>/etc/X1/xorg.conf</code>, cancellare tutto quello che è presente e inserire queste righe:<br />
<br />
<code>Section "Device"<br />Driver "ati"<br />Identifier "Radeon 9550"<br />Option "BusType" "PCI"<br />Option "AccelMethod" "EXA"<br />Option "MigrationHeuristic" "greedy"<br />Option "AGPSize" "64"<br />EndSection</code><br />
<br />
<code>Section "Monitor"<br />Identifier "Configured Monitor"<br />EndSection</code><br />
<br />
<code>Section "Screen"<br />Identifier "Default Screen"<br />Monitor "Configured Monitor"<br />Device "Radeon 9550"<br />DefaultDepth 24<br />EndSection</code><br />
<br />
<code>Section "Module"<br />Load "dri"<br />Load "GLcore"<br />EndSection</code><br />
<br />
Fonte (parzialmente modificata): <a href="http://ubuntuforums.org/showthread.php?p=8263824#post8263824" target="_blank"> http://ubuntuforums.org/showthread.php?p=8263824#post8263824</a><br />
<br />
Ovviamente è valido, anzi consigliato, sostituire 'Radeon 9550' con il modello appropriato.<br />
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.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-5044590136927337480.post-37489332089010124192010-02-04T07:07:00.000-08:002013-09-28T06:42:36.672-07:00Organizzare e ricercare le pagine web (e non solo): ZoteroVi è 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?<br />
<br />
Recentemente mi sono imbattuto in questo: <a href="http://www.zotero.org/" target="_blank">http://www.zotero.org</a>.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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à. Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5044590136927337480.post-4357146448109805412010-02-04T03:31:00.000-08:002013-09-28T06:43:47.842-07:00Rdesktop e numero massimo di connessioni terminal serverNon vi capita mai di connettervi ad un server windows usando rdesktop e trovarvi di fronte a questo messaggio?<br />
<br />
<a href="http://www.zaffa.org/wp-content/uploads/2010/02/terminal_server_exceeded.png"><img alt="Terminal server exceeded maximum number of allowed connections" class="aligncenter size-full wp-image-97" height="117" src="http://www.zaffa.org/wp-content/uploads/2010/02/terminal_server_exceeded.png" title="Terminal server exceeded maximum number of allowed connections" width="458" /></a><br />
<br />
Piuttosto fastidioso, significa che ci sono delle connessioni ancora attive e che altre, ahinoi, non se ne possono aprire.<br />
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:<br />
<br />
<code>rdesktop -g 1024x768 -k it -0 nome_o_ip_server</code><br />
<br />
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..<br />
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.<br />
Ovviamente possono fare il login nella sessione 0 amministrativa solo gli utenti appartenenti al gruppo degli amministratori.<br />
Non è chissà quale scoperta, ma me lo dimentico ogni volta, quindi me lo scrivo :-)Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-5044590136927337480.post-83596023546331965162010-01-26T02:28:00.000-08:002013-09-28T06:49:44.935-07:00Restricted bash con apparmorMolto spesso si ha l'esigenza di limitare quello che un utente può fare da una shell Linux. Storicamente su linux esiste il comando <a href="http://man.he.net/man1/rbash" target="_blank" title="Man rbash">rbash</a> (restricted bash) , che dovrebbe permettere di bloccare gli utenti nella loro home e di <a href="http://blog.bodhizazen.net/linux/how-to-restrict-access-with-rbash/" target="_blank" title="How to restrict access with rbash">consentirgli solo un set limitato di comandi</a>.<br />
<br />
Tuttavia molti non ritengono rbash particolarmente sicuro. <a href="http://it.wikipedia.org/wiki/AppArmor" target="_blank" title="Apparmor">Apparmor</a> è invece ritenuto decisamente più sicuro, è più maneggevole e più semplice da configurare.<br />
<br />
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.<br />
<br />
<a name='more'></a>Su Ubuntu apparmor viene installato di default (a partire dalla release 8.0.4 - Hardy) quindi è molto probabile che chi usa questa distribuzione ce l'abbia già installato. In caso contrario bisogna accertarsi di avere installati questi pacchetti:<br />
<br />
<code>apparmor apparmor-profiles apparmor-utils</code><br />
<br />
Per gli utenti di altre distribuzioni maggiori informazioni possono essere trovate <a href="http://forge.novell.com/modules/xfmod/project/?apparmor" target="_blank" title="Apparmor homepage">qua</a>.<br />
<br />
Avvertenza: io non mi sono mai abituato all'utilizzo di 'sudo' su Ubuntu, quindi metto sempre una password a root e digito i comandi direttamente dalla shell di root. I comandi riportati di seguito vanno quindi eseguiti come root. Se siete utenti che usano il 'sudo' mettetelo sempre davanti ad ogni comando.<br />
<br />
Per cominciare creiamo un utente (il classico pippo che si usa per fare le prove) e assegnamoli una password:<br />
<br />
<code>useradd -m pippo</code><br />
<code>passwd pippo</code><br />
<br />
Poi creiamo un hard link alla bash (cerchiamo di non chiamarlo rbash per non fare confusione con l'altro sistema):<br />
<br />
<code>ln /bin/bash /bin/bashstrict</code><br />
<br />
Poi facciamo in modo che pippo usi la shell nuova che abbiamo appena creato:<br />
<br />
<code>usermod -s /bin/bashstrict pippo</code><br />
<br />
A questo punto possiamo cominciare a creare una policy di apparmor per la nostra nuova shell:<br />
<br />
<code>aa-genprof /bin/bashstrict</code><br />
<br />
Partirà un wizard in modalità testo. Il sistema chiederà se volete che apparmor si connetta ad un repository di policy. E' una scelta personale, connettersi non costa nulla e non obbliga poi a caricare sul repository le proprie policy personali. Quando compare questa scritta:<br />
<br />
<code>Profiling: /bin/bashstrict</code><br />
<br />
<code>[(S)can system log for SubDomain events] / (F)inish</code><br />
<br />
dovete aprire un'altra shell, loggarvi come utente pippo, eseguire il comando che volete abiltare (ssh <macchina remota>) e solo quello, fare il logout.<br />
<br />
Fatto questo tornate sulla console dove c'era il wizard in attesa e premete S (Scan). Verranno fatte delle domande di questo tipo:<br />
<br />
<code>Reading log entries from /var/log/audit/audit.log.</code><br />
<code>Updating AppArmor profiles in /etc/apparmor.d.</code><br />
<br />
<code>Profile:Â /bin/bashstrict<br />Execute:Â /usr/bin/lesspipe<br />Severity: unknown</code><br />
<br />
<code>[(I)nherit] / (P)rofile / (U)nconfined / (D)eny / Abo(r)t / (F)inish</code><br />
<br />
Se siamo sicuri di aver digitato solo i comandi corretti possiamo senza dubbio scegliere I(nherit) e A(llow) quando viene chiesto.<br />
<br />
Alla fine verrà proposto il salvataggio della policy, che naturalmente accetteremo di buon grado.<br />
Per rendere operativa la policy appena creata è sufficiente digitare:<br />
<br />
<code>aa-enforce bin.bashstrict</code><br />
<br />
Alla fine del processo riproviamo a fare un login come pippo, tralasciamo per un momento i messaggi di errore e proviamo a fare ssh su una macchina remota. Dovrebbe funzionare. proviamo a dare qualunque altro comando. Dovrebbe dare un 'Permission denied'. Se le cose stanno così è tutto a posto.<br />
<br />
L'ultimo problema è quello dei fastidiosi messaggi di errore che compaiono al login. Sono legati alla mancanza dei permessi sui file che utilizza la bash (<code>.bash_profile, .bashrc, .bash_history </code>etc.) oppure a files e programmi invocati da questi files. Per eliminare i messaggi di errore ci sono due strade:<br />
<br />
1) Ridurre all'osso le istruzioni contenute in .bashrc e .bash_profile in modo che da questi non venga richiamato niente altro, e dare i corretti permessi a questi file in apparmor (vedi punto2).<br />
<br />
2) Ripetere tutta la procedura di addestramento (<code>aa-genprof /bin/bashstrict</code> + login di pippo con ssh su macchina remota + salvataggio e attivazione policy) per un po' di volte finchè non scompaiono i messaggi di errore. In effetti ad ogni successivo addestramento vengono aggiunti nuovi permessi fino a che tutti i file necessari al funzionamento della shell sono consentiti.<br />
<br />
Il file che contiene la policy si trova in <code>/etc/apparmor.d/bin.bashstrict</code> e, naturalmente, può essere anche modificato a mano, a patto che si sappia cosa si sta facendo. Per curiosità , il file <code>/etc/apparmor.d/bin.bashstrict</code> creato con la procedura di cui sopra e utilizzando il metodo 2 per far sparire gli errori (4 o 5 ripetizioni dell'addestramento) , si presenta in questo modo:<br />
<br />
<code># Last Modified: Tue Jan 26 09:28:31 2010<br />#include <tunables/global></code><br />
<br />
<code>/bin/bashstrict {<br />#include <abstractions/base><br />#include <abstractions/bash><br />#include <abstractions/nameservice></code><br />
<br />
<code>/bin/lesspipe rix,<br />/bin/sed rix,<br />/bin/uname rix,<br />/dev/tty rw,<br />/etc/bash.bashrc r,<br />/etc/init.d/ r,<br />/etc/profile r,<br />/etc/ssh/ssh_config r,<br />owner /home/*/.bash_history rw,<br />owner /home/*/.bash_logout r,<br />owner /home/*/.bashrc r,<br />owner /home/*/.profile r,<br />owner /home/*/.ssh/known_hosts r,<br />/usr/bin/basename rix,<br />/usr/bin/clear_console rix,<br />/usr/bin/dirname rix,<br />/usr/bin/groups rix,<br />/usr/bin/ssh rix,</code><br />
<br />
<code>}</code>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5044590136927337480.post-25631298113060931882009-08-10T09:17:00.000-07:002013-09-28T07:00:29.778-07:00Cache plugin per wordpress a confrontoMentre 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 <a href="http://www.wordpress.org/" target="_blank">wordpress</a>. 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.<br />
<br />
<a name='more'></a>Ho fatto i test su questo stesso blog (attualmente Wordpress 2.8.3) usando due tra i plugin più diffusi, <a href="http://mnm.uib.es/gallir/wp-cache-2/" target="_blank">wp-cache</a> e <a href="http://ocaoimh.ie/wp-super-cache/" target="_blank">wp super cache</a>, e uno abbastanza recente creato espressamente per lavorare su siti in shared hosting: <a href="http://www.satollo.net/plugins/hyper-cache" target="_blank">Hyper cache</a>. Naturalmente ho verificato anche cosa succede disabilitando tutte le cache.<br />
<br />
Per fare i benchmark ho utilizzato un tool a linea di comando disponibile su tutte le distribuzioni Linux: <a href="http://www.joedog.org/index/siege-home" target="_blank">siege</a>. L'utilizzo è piuttosto semplice: si crea un file di testo (urls.txt) con un elenco di urls del sito da testare (nel mio caso ne ho usate 20) e si lancia il test su queste urls con i parametri adeguati.<br />
<br />
Nel mio caso la linea di comando era questa (con spiegazione dei parametri):<br />
<br />
<code>siege -i -d 30 -c 100 -t 60s -f urls.txt</code><br />
<br />
<i><code>-i, --internet INTERNET user simulation, hits the URLs randomly.<br />-d, --delay=NUM Time DELAY, random delay between 1 and num designed to simulate human activity. Default value is 3<br />-c, --concurrent=NUM CONCURRENT users, default is 10<br />-t, --time=NUMm TIME based testing where "m" is the modifier S, M, or H<br />-f, --file=FILE FILE, change the configuration file to file.</code></i><br />
<br />
In soldoni vengono simulati 100 visitatori contemporanei che visitano le urls presenti nella lista e che richiedono una nuova pagina dopo un tempo variabile da 1 a 30 secondi. La durata del test è di 60 secondi. Di default una richiesta va in timeout se non ottiene risposta dal server dopo 30 secondi.<br />
<br />
I risultati sono stati piuttosto sorprendenti. In breve wp-cache e wp super cache non offrono alcun beneficio rispetto a wordpress pulito senza cache (anzi!!). Al contrario hyper cache da risultati eccellenti: il numero di richieste al secondo soddisfatte (Transaction rate) è circa 3 volte superiore. Di seguito riporto gli output dei benchmark (i test sono stati ripetuti 3 volte per ogni configurazione e qui viene riportato il risultato intermedio):<br />
<br />
<b>No cache:</b><br />
<br />
<code>Transactions: 125 hits<br />Availability: 99.21 %<br />Elapsed time: 59.76 secs<br />Data transferred: 0.98 MB<br />Response time: 18.40 secs<br />Transaction rate: 2.09 trans/sec<br />Throughput: 0.02 MB/sec<br />Concurrency: 38.50<br />Successful transactions: 125<br />Failed transactions: 1<br />Longest transaction: 30.03<br />Shortest transaction: 0.88</code><br />
<br />
<b>wp-cache:</b><br />
<br />
<code>Transactions: 117 hits<br />Availability: 90.70 %<br />Elapsed time: 60.49 secs<br />Data transferred: 0.89 MB<br />Response time: 18.17 secs<br />Transaction rate: 1.93 trans/sec<br />Throughput: 0.01 MB/sec<br />Concurrency: 35.15<br />Successful transactions: 117<br />Failed transactions: 12<br />Longest transaction: 29.90<br />Shortest transaction: 0.92</code><br />
<br />
<b>wp super cache:</b><br />
<br />
<code>Transactions: 116 hits<br />Availability: 94.31 %<br />Elapsed time: 60.29 secs<br />Data transferred: 0.92 MB<br />Response time: 20.17 secs<br />Transaction rate: 1.92 trans/sec<br />Throughput: 0.02 MB/sec<br />Concurrency: 38.82<br />Successful transactions: 116<br />Failed transactions: 7<br />Longest transaction: 31.54<br />Shortest transaction: 0.00</code><br />
<br />
<b>Hyper cache:</b><br />
<br />
<code>Transactions: 359 hits<br />Availability: 100.00 %<br />Elapsed time: 60.15 secs<br />Data transferred: 2.80 MB<br />Response time: 0.12 secs<br />Transaction rate: 5.97 trans/sec<br />Throughput: 0.05 MB/sec<br />Concurrency: 0.71<br />Successful transactions: 359<br />Failed transactions: 0<br />Longest transaction: 2.40<br />Shortest transaction: 0.02</code><br />
<br />
Il load del server è stato costantemente elevato (oltre 30!!) al termine dei test senza cache, con wp-cache e wp super cache, mentre con hyper cache il load non si è praticamente mosso dallo 0,1 solito.<br />
<br />
A scanso di equivoci tutti i test sono stati effettuati verificando su filesystem che i file statici venissero effettivamente scritti dal plugin e svuotando la cache prima di lanciare il test.<br />
<br />
In conclusione hyper cache sembra essere di gran lunga più efficiente rispetto agli altri due, almeno nella mia configurazione. Immagino però che i risultati possano variare in base ad un numero molto elevato di variabili, dalla configurazione del server web e del php fino alla configurazione di worpress e dei plugin medesimi, quindi non pretendo che questi risultati abbiano un valore assoluto. Sta di fatto però che sono rimasto davvero impressionato dal comportamento di hyper cache, tanto da adottarlo in pianta stabile su questo blog (sebbene, lo ammetto, il numero di visitatori non lo renda assolutamente necessario) e da consigliarlo vivamente a tutti coloro che hanno un blog, a maggior ragione se su hosting condiviso. E visto che, ahimè, viviamo in un mondo di sospetti e di veleni, chiarisco che non ho alcun rapporto nè nessuna particolare simpatia/antipatia nei confronti degli autori dei plugin che ho provato ;-)Unknownnoreply@blogger.com8tag:blogger.com,1999:blog-5044590136927337480.post-78522180356296620262008-09-18T08:20:00.000-07:002013-09-28T23:01:25.258-07:00Nuovo lavoroE' 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.<br />
<br />
Tra non molto credo che ricomincerò a scrivere qualche articoletto tecnico (la carne al fuoco non manca ;-)).<br />
<br />
Nel frattempo mi scuso con coloro a cui non ho mai dato risposta. Forse sarò in grado di darne, ma forse anche no.Unknownnoreply@blogger.com7tag:blogger.com,1999:blog-5044590136927337480.post-59806969986753531772008-05-15T15:42:00.000-07:002013-09-28T23:02:31.313-07:00Ltsp su hardyFinalmente trovo il tempo di scrivere qualche rapidissimo commento su ltsp su Ubuntu 8.04 (Hardy Heron).<br />
<br />
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.<br />
<br />
Ma tutti i piccoli miglioramenti passano un po' in secondo piano a causa di un serio problema in fase di installazione: il comando <code>ltsp-build-client</code> non va a buon fine e, dopo un po' che lavora, restituisce questo messaggio di errore:<br />
<br />
<a name='more'></a><br />
<br />
<code>Processing triggers for initramfs-tools ...<br />Using '/usr/share/ldm/themes/edubuntu' to provide 'ldm-theme'.<br />Lettura della lista dei pacchetti in corso... Fatto<br />Generazione dell'albero delle dipendenze in corso<br />Reading state information... Fatto<br />E: Impossibile trovare xubuntu-artwork-usplash<br />errore: installazione client LTSP terminata non normalmente</code><br />
<br />
Il fatto è che il pacchetto <i>xubuntu-artwork-usplash</i> è stato spostato dal repository <i>main</i> a <i>universe</i>. Il comando <code>ltsp-build-client</code> invece di default prende in considerazione solo il <i>main</i>. Da qui l'errore e l'interruzione del processo di creazione dell'immagine.<br />
<br />
Per risolvere il problema occorre dare questo comando in modo da abilitare anche il repository <i>universe</i> durante la creazione dell'immagine del filesystem per i thin client:<br />
<br />
<code>ltsp-build-client --components "main universe"</code><br />
<br />
In questo modo il processo va a buon fine.<br />
<br />
A parte questo particolare nulla è cambiato nel processo di installazione e configurazione rispetto a gutsy.Unknownnoreply@blogger.com15tag:blogger.com,1999:blog-5044590136927337480.post-19633465192768367382008-05-08T05:02:00.000-07:002013-09-28T23:05:44.278-07:00Truffe e registrazione dominiQuattro 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.<br />
Ho indagato un po' e tramite whois ho visto che il mio dominio risultava gestito non più da assurancehosting.com ma da enom.com.<br />
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.<br />
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.<br />
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.<br />
Adesso sono in attesa del codice per poter procedere al trasferimento verso il nuovo registrar. Si prospettano due scenari:<br />
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.<br />
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.Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-5044590136927337480.post-48653197290676380922008-04-09T07:56:00.000-07:002013-09-28T05:50:17.138-07:00Squid e autenticazione su ldapUno 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 <a href="http://www.squid-cache.org/" target="_self">squid</a> effettuasse le autenticazioni su un directory server <a href="http://www.openldap.org/" target="_self">openldap</a>, 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à .<br/><br/><a name='more'></a><br/><br/><code>1 - auth_param basic program /usr/lib/squid/ldap_auth -b ou=People,dc=zaffa,dc=org -f "(&(objectClass=gosaProxyAccount)(uid=%s))" -P -v 3<br/>2 - auth_param basic children 5<br/>3 - auth_param basic realm Squid proxy-caching web server<br/>3 - auth_param basic credentialsttl 2 hours</code><br/><br/>Chiarisco cosa fanno queste righe. Intanto premetto che sto usando <a href="https://oss.gonicus.de/labs/gosa/" target="_blank">GOSA</a>, un framework per la gestione di account su directory ldap. Usando l'interfaccia web di GOSA sono in grado di modificare rapidamente gli account utente e macchina (e un mucchio di altre cose).<br/>Per ogni utente posso decidere se abilitarlo o meno all'uso del proxy (gli utenti non abilitati ovviamente non devono poter navigare senza usare il proxy, altrimenti il marchingegno non ha molto senso). A tutti gli account di utenti abilitati, e solo a loro, viene aggiunta la objectclass "gosaProxyAccount".<br/><br/>La riga 1 quindi significa: fai una autenticazione di base usando il programma <code>/usr/lib/squid/ldap_auth</code>, cerca gli utenti a partire da <code>ou=People,dc=zaffa,dc=org</code> (-b), metti un filtro e utilizza per l'autenticazione solo quelli che presentano la objectclass gosaProxyAccount (-f), usa una connessione ldap persistente (-P), usa il protocollo ldap versione 3 (-v).<br/>A riga 2 si dice di far partire in contemporanea 5 istanze del programma di autenticazione.<br/>La riga 3 serve a inserire le informazioni che diventeranno poi il titolo della form di autenticazione.<br/>Riga 4 definisce la durata della validità delle credenziali fornite.<br/><br/>Non avendo specificato alcun indirizzo viene usato localhost di default, in questo caso quindi squid e ldap risiedono sulla stessa macchina.<br/>Comunque digitando da linea di comando semplicemente <code>/usr/lib/squid/ldap_auth</code> si ottiene una schermata riepilogativa della sintassi e delle opzioni.<br/><br/>Ah ... dimenticavo ... la distribuzione è Ubuntu, ma non credo ci siano molte differenze anche su altri sistemi.Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-5044590136927337480.post-70122713356860987412008-04-09T04:19:00.000-07:002013-09-28T05:50:17.118-07:00LTSP tips & tricksIn 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.<br/><br/><a name='more'></a><br/><br/><em><strong>Soluzioni a problemi gravi:</strong></em><br/><br/><strong>1 - Il problema del syslog</strong><br/><br/>Forse non tutti sanno che quando il demone syslog è abilitato a ricevere i log dalla rete (opzione "-r") esegue una risoluzione inversa per ogni log che gli viene inviato dai client. Già di per se la cosa non è bellissima, poichè in una tale situazione non è difficile effettuare dei <a href="http://it.wikipedia.org/wiki/Denial_of_service">denial of service</a> semplicemente bombardando di richieste il server dns a cui si appoggia il syslogd. A questo si aggiunga che, nella configurazione che ho suggerito in questo blog, è il demone <a href="http://www.thekelleys.org.uk/dnsmasq/doc.html" target="_blank">dnsmasq</a> che si occupa di rilasciare gli indirizzi dhcp e di fornire la risoluzione diretta e inversa per i nomi macchina. In qualche caso può succedere un vero casino (è successo davvero): un client prende l'indirizzo ma NON un nome macchina, quindi la risoluzione inversa non funziona. Il client invia i log al syslog server, il quale per ogni log chiede a dnsmasq la risoluzione inversa. Nel frattempo anche dnsmasq però cerca di scrivere le sue cose in syslog. In questa situazione può succedere che syslog resta appeso in attesa di una risposta da dnsmasq e dnsmasq resta appeso in attesa che syslog gli accetti i log. Morale: non funziona più nulla, il dhcp non rilascia più indirizzi, il dns non risolve più nulla. La rete in breve diventa inutilizzabile. Il problema è anche documentato nelle <a href="http://www.thekelleys.org.uk/dnsmasq/docs/FAQ" target="_blank">faq di dnsmasq</a>. Le possibili soluzioni sono 2:<br/><ul><br/> <li>Aggiungo alla configurazione di dnsmasq (solo dalla versione 2.39) l'opzione "<code>log-async=n</code>" (dove n sta per il numero di righe di log tenute in coda, default=5, max=100).</li><br/> <li>Sostituisco il demone syslog di sistema con un processo dove sia possibile disabilitare la risoluzione inversa: <a href="http://www.balabit.com/support/community/products/" target="_blank">syslog-ng.</a> Sui sistemi basati su debian è sufficiente utilizzare il comando "<code>apt-get install syslog-ng</code>" e automaticamente verrà rimosso il vecchio syslog e installato quello nuovo. Successivamente si edita il file <code>/etc/syslog-ng/syslog.conf</code> e si abilita la ricezione dei log da rete abilitando la riga "<code>#udp();</code>" che di default è quotata. La risoluzione inversa invece è già disabilitata di default. Per finire si lancia "<code>/etc/init.d/syslog-ng restart</code>". Non c'è nemmeno bisogno di far ripartire la macchina.</li><br/></ul><br/>Ovviamente nulla vieta che si implementino ambedue le soluzioni.<br/><br/><strong>2 - Persistenza dei file di swap gestiti dal demone nbdswap</strong><br/><br/>Quando nel file <code>lts.conf</code> è abilitata l'opzione <code>NBD_SWAP=True</code>, per ogni client con memoria RAM inferiore a 48 Mb viene creato un file di swap sul server, gestito dal demone nbdswapd. Il problema è che spesso questi processi non vengono normalmente terminati e tendono ad accumularsi. La soluzione è molto semplice: si aggiunge la riga "<code>nbdswapd: ALL: keepalive</code>" al file <code>/etc/hosts.allow</code>.<br/>In configurazione di default dopo due ore di inattività tutti i processi residui nbdswapd verrano terminati automaticamente.<br/><br/><strong>3 - Persistenza di processi utente</strong><br/><br/>In molti casi sul server restano attivi dei processi di utenti non più loggati. Questo accade ad esempio in caso di crash del thin client. Molte volte è necessario un intervento di un utente con privilegi amministrativi per terminare a mano i processi residui altrimenti l'utente non è più nemmeno in grado di accedere al suo desktop. La soluzione in questo caso si chiama <a href="http://www.morokeni.ch/edubuntu/gnome-watchdog_0.9.2_i386.deb">gnome-watchdog</a>. Una volta installato, il demone controlla che ci sia veramente una sessione attiva e, in caso contrario, fa pulizia dei processi residui. Creando il file vuoto "<code>/etc/check_previous_login</code>" è possibile anche forzare un check al momento del login: se ci sono processi già attivi mentre un utente fa il login compare un avviso attraverso il quale è possibile scegliere di terminare i processi già esistenti. L'unico limite è che gnome-watchdog funziona solo con Gnome (era intuibile). Che sia uno strumento valido lo dimostra il fatto che è già inserito nei repository di Ubuntu 8.04 (Hardy). Consigliata comunque la lettura del README.<br/><br/><strong>4 - Risoluzione dello schermo</strong><br/><br/>Frequentemente all'avvio del thin client viene riconosciuta correttamente la scheda video ma poi non vengono correttamente identificate le frequenze supportate dal monitor. Si ottiene quindi una risoluzione di default di 800x600 senza la possibilità di modificarla.<br/>La soluzione consiste nel ottenere i corretti valori di vsync e hsync del monitor (dalla documentazione o cercando sul web) e inserirli nella sezione dedicata allo specifico thin client nel file <code>lts.conf</code>, in questo modo (esempio usato per monitor Samsung SyncMaster 757p):<br/><br/><code>[mac_address_del_client]<br/>X_HORZSYNC = 30-96<br/>X_VERTREFRESH = 50-160</code><br/><br/>In genere dopo questa aggiunta si torna ad avere la possibilità di impostare tutte le risoluzioni consentite dall'accoppiata scheda video/monitor.<br/><br/><strong><em>Piccoli miglioramenti:</em></strong><br/><br/><strong>5 - irqpoll</strong><br/><br/>Talvolta nei log di sistema compaiono errori di questo tipo generati da qualche client:<br/><br/><code>irq 21: nobody cared!</code><br/><br/>seguiti da uno stack trace. Il più delle volte non succede nulla, ma ho il sospetto che taluni crash improvvisi accaduti ai thin client possano essere legati a questo. L'aggiunta dell'opzione irqpoll al boot dei thin client risolve questo problema a scapito di un lieve scadimento delle prestazioni del thin client stesso. Ma il thin client deve essere innanzitutto stabile, quindi secondo me il gioco vale la candela.<br/>Per aggiungere questa opzione si edita il file <code>/var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default</code> e si aggiunge l'opzione "irqpoll" alla fine della riga in modo da ottenere qualcosa di simile a questo:<br/><br/><code>DEFAULT vmlinuz ro initrd=initrd.img quiet splash irqpoll</code><br/><br/><strong>6 - .gnomerc</strong><br/><br/>Questo non è un suggerimento specifico per ltsp ma vale in realtà per Gnome, lo riporto qua perchè non è sempre documentatissimo e, tempo fa, ci avevo messo un po' a trovarlo.<br/>In pratica in ambiente gnome su Ubuntu le variabili di ambiente non vengono caricate al login dai soliti file <code>.bashrc</code> e <code>.bash_profile</code>, bensì dal file <code>.gnomerc</code>.<br/>E' utile saperlo perchè su una macchina multiutente, come appunto un server LTSP, può essere importante poter settare, per esempio, dei valori di <a href="http://it.wikipedia.org/wiki/Umask" target="_blank">umask</a> diversi dal default in modo da poter utilizzare i privilegi di gruppo oltre a quelli utente (es. "<code>umask 002</code>" fa in modo che i file creati abbiano i permessi settati su 664 - <code>-rw-rw-r--</code> ) e che siano quindi leggibili e modificabili da altri utenti dello stesso gruppo.<br/><br/><strong>7 - Disabilitare ipv6</strong><br/><br/>Può essere utile disabilitare IPV6 per aumentare le prestazioni di rete. Rimando a <a href="http://alexit.wordpress.com/2007/03/03/velocizzare-la-navigazione-in-ubuntu-ipv6-dns-ip-statici/">questo link</a> per le istruzioni su come fare. La particolarità per ltsp è che queste operazioni noi le dobbiamo fare una prima volta sul server e una seconda volta in ambiente chroot*, eseguendo alla fine il comando <code>ltsp-update-image</code>.<br/><br/><strong>8 - Preferenze di firefox</strong><br/><br/>Esiste un sistema per forzare le preferenze di firefox (es. proxy, pipelining etc.) una volta sola e per tutti gli utenti. Nel file <code>/etc/firefox/pref/firefox.js</code> vengono inserite le preferenze che saranno valide di default per tutti gli utenti del sistema.<br/>Per esempio, rifacendosi al punto 7, per disabilitare di default IPV6 in firefox si edita <code>/etc/firefox/pref/firefox.js</code> e si aggiunge questa riga:<br/><br/><code>pref("network.dns.disableIPv6", true);</code><br/><br/><strong>8 - Timezone e ora di sistema<br/></strong><br/><br/>Trovo abbastanza fastidioso avere dei thin client con l'ora diversa dal server. E' un problema di poco conto poichè ci si accorge di questo solamente loggandosi via ssh o via console nel sistema operativo del thin client, mentre l'utente lavora in Gnome utilizzando l'ora del server.<br/>Sistemare l'orario dei thin client è semplice: si entra in ambiente chroot* e si esegue il comando:<br/><br/><code>dpkg-reconfigure tzdata</code><br/><br/>per settare la timezone corretta. Dopodichè per fare in modo che i thin client abbiano lo stesso orario del server si imposta il valore UTC in <code>/etc/default/rcS</code> esattamente come è settato sul server.<br/>Per essere sicuri di avere sempre l'ora giusta in tutta la rete io in genere attivo un servizio ntpd (può risiedere anche sullo stesso ltsp server), sincronizzato su timeserver remoti, mentre per i thin client aggiungo in <code>/etc/rc.local</code> (sempre in ambiente chroot*) le seguenti righe:<br/><br/><code>/usr/sbin/ntpdate <ip del server ntpd><br/>/sbin/hwclock --systohc --localtime</code><br/><br/>prima di <code>exit0</code>, in modo che il thin client faccia una sincronizzazione con il timeserver di rete all'avvio e subito dopo configuri anche l'orologio hardware (RTC).<br/>Ovviamente bisogna ricordarsi alla fine di eseguire <code>ltsp-update-image</code><br/><br/>* <em>Per chi non avesse idea di che cosa è "l'ambiente chroot" rimando ad <a href="http://www.zaffa.org/2007/10/05/ubuntu-ltsp-thin-client-per-piccola-azienda-3/" target="_blank">un precedente post su ltsp</a>.</em>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-5044590136927337480.post-19450233078785343832008-04-04T06:11:00.000-07:002013-09-28T05:50:17.099-07:00Piccoli furti sul webL'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 <a href="http://www.zaffa.org/2007/10/18/ltsp-su-ubuntu-gutsy-sempre-piu-facile" target="_blank">mio articolo</a> copiato quasi integralmente <a href="http://pigreco.no-ip.com/index.php?option=com_content&task=view&id=50&Itemid=9" target="_blank">sul sito di una società di informatica</a>.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.<br/><br/>Il 1 aprile ho usato la form del suo sito per scrivergli questa mail:<br/><br/><a name='more'></a><br/><br/>"<em>Ciao, ho visto che hai bellamente copiato dal mio sito (<a href="http://www.zaffa.org/" target="_blank">http://www.zaffa.org</a>) la parte relativa ai thin client con Ubuntu Gutsy (<a href="http://pigreco.no-ip.com/index.php?option=com_content&task=view&id=50&Itemid=9" target="_blank">http://pigreco.no-ip.com/index.php?option=com_content&task=view&id=50&Itemid=9</a>). Tutto questo senza nemmeno citarmi e facendo sembrare che sia farina del tuo sacco.<br/>Se tengo un blog tecnico dove spiego un po' delle cose che faccio è ovvio che mi fa piacere rendere pubbliche certe cose. Tuttavia il farsi belli con la roba degli altri, come stai facendo tu, mi pare veramente detestabile. Ti invito quindi a rimuovere immediatamente dal tuo sito la parte che hai pedissequamente copiato oppure, in alternativa, a modificare la pagina in maniera che sia inequivocabilmente chiaro chi è l'autore dell'articolo e da dove lo hai preso.</em>"<br/><br/>Lo ammetto: un po' aggressiva e in un brutto italiano, ma ero di fretta e piuttosto irritato.<br/><br/>A tutt'oggi non ho ricevuto risposta.<br/><br/>Sia chiaro: i contenuti del mio sito sono liberamente utilizzabili da chiunque, ma trovo davvero fastidioso che vengano adoperati in questo modo.<br/><br/>E complimenti al Sig. Criscione, continui così e avrà un radioso avvenire professionale nel mondo dell'informatica.<br/><p style="margin-bottom: 0cm;"></p>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-5044590136927337480.post-6931119388045041742008-03-20T10:03:00.000-07:002013-09-28T05:50:17.073-07:00Thin client Lucida LT2610Mi è stato dato in prova un thin client <a href="http://www.lucidatech.com/product/lt2610.htm" target="_blank">Lucida LT2610</a> col quale ho fatto qualche esperimento con <a href="http://www.ubuntulinux.com" target="_blank">Ubuntu</a> e <a href="http://ltsp.org/" target="_blank">LTSP</a>. 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 <a href="http://it.wikipedia.org/wiki/Preboot_Execution_Environment" target="_blank">PXE</a>, cioè quello che viene usato per avviare un client <a href="http://ltsp.org/" target="_blank">LTSP</a>.<br/><br/><a href="http://www.zaffa.org/wp-content/uploads/2008/03/lt2600_large.jpg" title="LT2610"><img src="http://www.zaffa.org/wp-content/uploads/2008/03/lt2600_large.thumbnail.jpg" style="width: 128px; height: 128px" alt="LT2610" width="128" align="left" height="128" /></a>L'hardware è basato sul processore <a href="http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_13022,00.html" target="_blank">AMD Geode LX 800</a> 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.<br/><br/>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.<br/><br/><a name='more'></a><br/><br/><span style="font-size: 10pt"><span style="font-size: 10pt"><strong>Gutsy</strong></span></span><br/><br/>Con Gutsy il Lucida LT2610 non funziona. O meglio, non funziona sull'installazione "liscia". All'avvio, dopo il boot, il sistema operativo viene caricato ma al momento di far partire l'interfaccia grafica il client si blocca completamente e va riavviato manualmente. Il problema è noto ed è descritto in <a href="https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amd/+bug/140051" target="_blank">questo bug report</a>. Per risolvere questo problema occorre installare i pacchetti <em>xserver-xorg-core</em> e <em>xserver-</em><wbr></wbr><em>xorg-video-</em><wbr></wbr><em>amd</em> disponibili <a href="https://launchpad.net/~q-funk/+archive" target="_blank">qua</a>. Il modo più semplice per fare questo è inserire queste due righe (basta anche solo la prima se non siamo interessati ai sorgenti) in <code>/etc/apt/sources.list</code>:<br/><br/><code>deb http://ppa.launchpad.net/q-funk/ubuntu gutsy main<br/>deb-src http://ppa.launchpad.net/q-funk/ubuntu gutsy main</code><br/><br/>e lanciare:<br/><br/><code>apt-get update</code><br/><br/><code>apt-get upgrade</code><br/><br/>Automaticamente i due pacchetti verranno aggiornati con quelli nuovi.<br/><br/>La stessa cosa va fatta anche nell'ambiente chroot, quindi si procede in questo modo:<br/><br/><code>chroot /opt/ltsp/i386</code><br/><br/>si edita il file <code>/etc/apt/sources.list</code> aggiungendo le righe riportate sopra<br/><br/>si lancia <code>apt-get update</code> e <code>apt-get upgrade</code><br/><br/>si esce dall'ambiente chroot (<code>exit</code> o <code>ctrl+d</code>) e si lancia <code>ltsp-update-image</code>.<br/><br/>Una volta installati i pacchetti aggiornati la scheda video del thin client viene correttamente riconosciuta. Con il monitor che ho usato per fare le prove (un Samsung SyncMaster 757p) La schermata di login viene presentata alla risoluzione di 1600x1200 x 85Hz, a 24 bpp. Dall'interno di Gnome ho successivamente regolato senza alcuna difficoltà la risoluzione a 1280x1024. La scheda audio viene correttamente riconosciuta e funzionano correttamente l'audio in uscita e in entrata. Bene funziona anche l'autoriconoscimento delle chiavette usb. Non ho provato le porte seriale e parallela.<br/><br/><strong><span style="font-size: 10pt">Hardy</span></strong><br/><br/>Con Hardy aggiornato al 20/3/2008 il client LT2610 funziona "out of the box". L'ultima versione di Ubuntu contiene infatti tutte le patch e le messe a punto che sono state realizzate ultimamente per i pacchetti <em>xserver-xorg-core</em> e <em>xserver-xorg-video-amd</em>. Va osservato che queste patch NON verranno inserite ufficialmente nei repository di Gutsy, quindi, considerato che Hardy sembra essere già decentemente stabile e che sarà una release LTS (Long Term Support), forse vale la pena di cominciare subito con quest'ultima. Naturalmente funzionano bene anche l'audio e le periferiche di archiviazione collegate alla usb 2.0.<br/><br/>L'unica cosa negativa che ho osservato è stato che non sono riuscito a impostare la risoluzione di 1440x900 per utilizzare un monitor Acer AL1926W wide screen. Con nessuna delle due versioni di Ubuntu che ho provato. Non escludo che si possa comunque fare, perchè ad un certo momento ho desistito e non ho certamente combattuto con questo problema fino a sfiancarmi, però senz'altro, se anche fosse possibile farlo, non è una cosa semplice e immediata.<br/><br/>Per concludere credo che questi piccoli thin client siano delle ottime macchinette. Non avendo ventola nè altre parti in movimento sono silenziosissimi e consumano una frazione di quello che consuma un pc tradizionale. Sono adatti ad essere usati in ambiente LTSP anche se il supporto al chipset AMD Geode LX 800 mi sembra ancora migliorabile. Per il momento, per non incorrere in brutte sorprese, eviterei di collegarli a monitor lcd wide screen, ma resterei al più tradizionale formato 4:3, per il quale i driver supportano tutte le risoluzioni fino al 1600x1200.Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-5044590136927337480.post-33941226803007514542008-03-14T07:06:00.000-07:002013-09-28T05:50:17.065-07:00Pythonfilter: antispam e antivirus per Courier-mtaIl server di posta <a href="http://www.courier-mta.org" target="_blank">Courier-mta</a> è 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.<br/><br/>Per una delle macchine su cui gira <a href="http://www.courier-mta.org" target="_blank">Courier</a> (un vecchio server <a href="http://www.debian.org" target="_blank">Debian</a> che passando per vari aggiornamenti adesso è Etch) ero alla ricerca di un sistema per implementare le <a href="http://projects.puremagic.com/greylisting/whitepaper.html" target="_blank">greylist</a>. Per chi non lo sapesse il sistema delle <a href="http://projects.puremagic.com/greylisting/whitepaper.html" target="_blank">greylist</a> 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ù.<br/><br/>La prima volta che ho sentito parlare di greylist e che ho provato a utilizzarle (credo nel 2004, usando l'ottimo <a href="http://assp.sourceforge.net/" target="_blank">ASSP</a>) 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.<br/><br/><a name='more'></a>Sul vecchio server Debian il sistema antispam (<a href="http://spamprobe.sourceforge.net/" target="_blank">spamprobe</a>, con filtraggio individuale per ogni utente), pur funzionando piuttosto bene come percentuale di identificazione, era ormai costretto a classificare un numero enorme di messaggi, ed i falsi negativi, pur essendo una percentuale esigua rispetto al volume di spam ricevuto, cominciavano ad essere in numero tale da rappresentare un vero fastidio per gli utenti. Il primo effetto è stato quello che gli utenti talvolta, invece di classificare correttamente gli spam nell'apposita cartella, li cancellavano direttamente non permettendo al database dell'antispam di aggiornarsi correttamente. Il risultato finale è stato che il filtro Bayesiano di alcuni utenti negli ultimi tempi, invece di imparare a riconoscere correttamente nuovi tipi di spam perchè segnalati dall'utente medesimo, perdeva sempre più colpi. Ho pensato quindi di "aiutarlo" filtrando tutti i messaggi attraverso il sistema delle greylist. Ma per vari motivi non volevo mettere "davanti" al server di posta un proxy filtrante sul modello di <a href="http://assp.sourceforge.net/" target="_blank">ASSP</a>, volevo qualcosa di semplice che si integrasse con <a href="http://www.courier-mta.org/courierfilter.html" target="_blank">courier ed il suo sistema di filtri</a>.<br/><br/>Così mi sono imbattuto in <a href="http://phantom.dragonsdawn.net/~gordon/courier-patches/courier-pythonfilter/" target="_blank">courier-pythonfilter</a> (o semplicemente pythonfilter) e ho deciso di provarlo. Pythonfilter è un filtro creato per Courier col quale si possono attivare diversi moduli che ampliano le funzionalità del server. Ad esempio, oltre alla funzionalità che stavo cercando - le greylist - sono presenti i moduli per utilizzare <a href="http://www.clamav.net" target="_blank">Clamav</a> e <a href="http://spamassassin.apache.org/" target="_blank">SpamAssassin</a>.<br/><br/>L'installazione è molto semplice. Innanzitutto ci si assicuri di avere installato (su Debian e derivati) il pacchetto <em>python-gdbm</em>. Se si desidera utilizzare anche il filtraggio antivirus con clamav va installato anche <em>python-clamav</em>. <em>python-spf</em> va installato se si desidera usare uno dei moduli che utilizzano il protocollo <a href="http://it.wikipedia.org/wiki/Sender_Policy_Framework" target="_blank">spf</a>.<br/><br/>Si scarica l'ultima versione di pythonfilter, attualmente <a href="http://phantom.dragonsdawn.net/~gordon/courier-patches/courier-pythonfilter/courier-pythonfilter-1.0.tar.gz" target="_blank">courier-pythonfilter-1.0.tar.gz</a>. Si decompime usando <code>tar zxf courier-pythonfilter-1.0.tar.gz</code>. Si entra nella directory courier-pythonfilter-1.0 e si installa digitando questi comandi (da console, come root):<br/><br/><code>python setup.py install</code><br/><br/><code>mkdir /var/state/pythonfilter</code><br/><br/><code>chown daemon:daemon /var/state/pythonfilter</code><br/><br/><code>ln -s /usr/bin/pythonfilter /usr/lib/courier/filters/</code><br/><br/>I file di configurazione sono due:<br/><br/><code>/etc/pythonfilter.conf</code> contiene la lista dei moduli da attivare (di default sono tutti commentati) e <code>/etc/pythonfilter-modules.conf</code>, che contiene le configurazioni particolari per ogni modulo (anche questo tutto commentato poichè i valori di default sono già accettabili).<br/><br/>Abilitati i moduli che si ritengono utili si digita semplicemente:<br/><br/><code>filterctl start pythonfilter</code><br/><br/>Tutto questo senza riavviare nessun servizio :-)<br/><br/>Attualmente ho abilitato i moduli <em>noduplicates</em> (verifica tra gli alias che lo stesso destinatario non sia presente più volte negli header di un messaggio), <em>clamav</em> (che a questo punto sostituisce <a href="http://sourceforge.net/projects/clamcour/" target="_blank">clamcour</a>), <em>auto_whitelist</em> (esamina i messaggi inviati da utenti autenticati e mette automaticamente in whitelist i destinatari), <em>whitelist_relayclients</em> (non filtra i messaggi che provengono da macchine autorizzate al relay), <em>whitelist_auth</em> (mette in whitelist gli utenti autenticati), <em>whitelist_block</em> (metti in whitelist gli indirizzi che hanno un campo BLOCK libero in smtpaccess.dat - vedi "man makesmtpaccess"), <em>greylist</em>, <em>ratelimit</em> (blocca temporaneamente i server da cui provengono troppi messaggi per unità di tempo), <em>whitelist_dnswl</em> (consulta una lista pubblica di mail server ufficiali e mette in whitelist il mittente se corrisponde), <em>whitelist_spf</em> (mette in whitelist il mittente se il controllo del record spf va a buon fine).<br/><br/>Per scaricare una lista dei server che mal digeriscono le greylist e formattarla per l'uso con courier si lancia questo comando:<br/><br/><span style="font-size: 6pt"><code>wget -O - 'http://cvs.puremagic.com/viewcvs/*checkout*/greylisting/schema/whitelist_ip.txt?rev=1.16' \</code></span><br/><br/><span style="font-size: 6pt"><code>| grep '^[[:digit:]]' | sed -e 's/[[:blank:]].*\|$/\tallow,BLOCK/' \</code></span><br/><br/><span style="font-size: 6pt"><code>> /etc/courier/smtpaccess/nogreylisting</code></span><br/><br/>seguito da:<br/><br/><code>makesmtpaccess</code><br/><br/>Però attenzione che se già esiste un file nella directory <code>/etc/courier/smtpaccess</code> sono possibili duplicati e il comando "makesmtpaccess" restituirà un errore di questo genere: <code>"Cannot store record for 127.0.0.1 - duplicate or out of disk space."</code> Occorre rimuovere i duplicati da <code>/etc/courier/smtpaccess/nogreylisting</code> (sono generalmente l'indirizzo di loopback - 127.0.0.1 - e altri indirizzi di classe privata ad essere già presenti in altro file) e rilanciare il comando <code>"makesmtpaccess"</code>. La lista di cui sopra comunque NON contiene alcuni server italiani mal configurati che vanno quindi aggiunti a mano, tra cui i server di Alice che hanno il brutto vizio di perdersi le mail senza avvisare nessuno se la prima trasmissione non è andata a buon fine. Ovviamente questo potrebbe creare seri problemi agli utenti. Per chi fosse interessato a provare questo meccanismo ho preparato il file <a href="http://www.zaffa.org/wp-content/uploads/2008/03/smtp_list_it">smtp_list_it</a> che contiene molti tra i principali server smtp italiani (non necessariamente bacati), già formattata per essere inserita in <code>/etc/courier/smtpaccess</code> assieme alla lista di cui sopra.<br/><br/>Una volta aggiornate le liste e ricaricate in courier usando <code>makesmtpaccess</code> non è necessario riavviare o ricaricare pythonfilter.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5044590136927337480.post-5345342136189568892008-02-25T05:41:00.000-08:002013-09-28T05:50:17.050-07:00Primoautore: sistema online di certificazione di opere digitaliDa qualche giorno è attivo <a href="http://www.primoautore.it" target="_blank">questo servizio</a> 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.<br/><br/>Riporto testualmente dal <a href="http://www.primoautore.it" target="_blank">sito</a> alcune parti interessanti : "<em>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.</em>"<br/><br/>Sul sito sono presenti dettagliate istruzioni e informazioni di tipo legale. La procedura comunque sembra essere assai semplice.<br/><br/>Io non ho nulla da proteggere, ma se lo avessi una prova la farei. L'idea mi sembra buona.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-5044590136927337480.post-73611117033066592042008-01-16T07:15:00.000-08:002013-09-28T05:50:17.032-07:00pulseaudio 0.9.8 per gutsy x86Visto che non trovavo i pacchetti della nuova versione di <a href="http://pulseaudio.org" target="_blank">pulseaudio</a> (0.9.8) per Ubuntu Gutsy x86, li ho compilati e pacchettizzati a partire dai <a href="http://packages.debian.org/sid/pulseaudio" target="_blank">sorgenti di Debian SID</a>. Ho ricompilato anche <a href="http://www.pulseaudio.org/wiki/FlashPlayer9Solution" target="_blank">libflashsupport</a> (libreria che permette a Flash Player 9.x di funzionare con pulseaudio) dai sorgenti SVN che si trovano <a href="http://git.0pointer.de/?p=libflashsupport.git;a=summary" target="_blank">qua</a>.<br/><br/>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.<br/><br/><a href="http://www.zaffa.org/wp-content/uploads/2008/01/libpulse098tar.gz" title="Librerie e include per pulseaudio.">Librerie e include per pulseaudio.</a><br/><br/><a href="http://www.zaffa.org/wp-content/uploads/2008/01/pulseaudio-098tar.gz" title="Pulseaudio, eseguibili e moduli">Pulseaudio, eseguibili e moduli</a><br/><br/><a href="http://www.zaffa.org/wp-content/uploads/2008/01/libflashsupport-svn_11-1_i386.deb" title="Libflashsupport">Libflashsupport</a><br/><br/><a href="http://www.zaffa.org/wp-content/uploads/2008/01/pulseaudio-098tar.gz" title="Pulseaudio, eseguibili e moduli"></a>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-5044590136927337480.post-33539064925750185882007-11-22T06:49:00.000-08:002013-09-28T05:50:16.919-07:00Ltsp su architettura X86_64In alcuni commenti ad <a href="http://www.zaffa.org/2007/06/08/ubuntu-ltsp-thin-client-per-piccola-azienda-2/" target="_blank">un post precedente</a> 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.<br/>Ho installato una versione di Ubuntu Gutsy per AMD64, poi ho creato l'ambiente server per ltsp usando i comandi già descritti in <a href="http://www.zaffa.org/2007/10/18/ltsp-su-ubuntu-gutsy-sempre-piu-facile/" target="_blank">questo post</a>. 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 "<code>sudo ltsp-build-client --arch i386</code>".<br/>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.<br/>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 <a href="http://it.wikipedia.org/wiki/64_bit" target="_blank">qua</a>.<br/><br/><a name='more'></a><br/>Tuttavia non ci sono solo vantaggi, ci sono anche alcuni svantaggi. Attualmente la disponibilità di software per l'architettura a 64 bit si sta ampliando sempre di più ma mancano ancora alcuni applicativi "bloccanti" che scoraggiano l'utilizzatore comune. Ad esempio manca un plugin java per i browser a 64 bit, o meglio, ce ne sono alcuni non rilasciati da <a href="http://java.sun.com" target="_blank">Sun</a>, che a volte funzionano e a volte no, stessa situazione per il <a href="http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash&promoid=BIOW" target="_blank">plugin flash di Adobe</a> che, essendo closed source, viene distribuito in forma compilata a 32 bit. Su Ubuntu 64 bit si riesce comunque a far girare attraverso nspluginwrapper. Esistono in realtà alcuni plugin flash Open source e di uno di questi -<a href="http://swfdec.freedesktop.org">swfdec</a>- scriverò alla fine del post. Altre cose non funzionano bene: ad esempio i bookmark della Goggle Toolbar (una delle cose che uso di più) non vanno. Quindi firefox compilato nativamente per piattaforma a 64 bit può essere usato solo a condizione di poter fare a meno di alcune funzionalità . Sinceramente io non lo userei volentieri. Altrimenti si usa un firefox a 32 bit, che è in grado di far funzionare tutti i plugin e le estensioni senza problemi e con una perdita di prestazioni davvero minima, anzi, direi impercettibile. Istruzioni dettagliate su come installare firefox a 32 bit e relativi plugin si possono trovare <a href="https://help.ubuntu.com/community/AMD64/FirefoxAndPlugins?action=show&redirect=FirefoxAMD64FlashJava" target="_blank">qua</a>. Per inciso la procedura descritta qua sopra funziona benissimo anche per Thunderbird, tranne che ovviamente per la parte di aggiunta dei plugin. In effetti anche thunderbird sembra soffrire di alcuni problemi nella versione a 64 bit: quello che mi ha spinto a provare la versione a 32 bit è stato il non perfetto funzionamento dell'estensione <a href="https://addons.mozilla.org/it/thunderbird/addon/2313" target="_blank">lightning</a>, che uso tantissimo interfacciata al Calendario di Google.<br/><br/>Ma dal momento che si sta lavorando per preparare un ambiente terminal server queste istruzioni non sono sufficienti. Vogliamo anche avere l'audio sui thin client quando guardiamo un filmato su youtube, o no? Per fare questo occorre far parlare il plugin flash a 32 bit del browser con il sistema pulseaudio a 64 bit del server che poi ritrasmetterà il flusso audio al pulseaudio del thin client.<br/>Per permettere all'audio di funzionare correttamente questi sono i pacchetti che occorre installare sul server:<br/><br/><code>ia32-libs libc6-i386 lib32asound2 libesd-alsa0</code><br/><br/>(questi sono tutti pacchetti di librerie di supporto a software a 32 bit), cui seguono i pacchetti del sistema pulseaudio:<br/><br/><code>libao-pulse libpulse-mainloop-glib0 libpulse0 pulseaudio pulseaudio-esound-compat pulseaudio-module-gconf pulseaudio-module-hal pulseaudio-module-x11 pulseaudio-module-zeroconf pulseaudio-utils paman padevchooser paprefs</code><br/><br/>Sarà utile creare un file <code>/etc/asound.conf</code> fatto in questo modo:<br/><br/><code>pcm.!default {<br/>type pulse<br/>}</code><br/><br/><code>ctl.!default {<br/>type pulse<br/>}</code><br/><br/>in modo da impostare pulseaudio come motore sonoro di default per tutto il sistema. Oppure per ogni utente lanciare da linea di comando <code>asoundconf set-pulseaudio</code>.<br/><br/>Dopodichè si modifica il file <code>/usr/local/bin/firefox32</code> in modo che risulti così (l'aggiunta è nella penultima riga): <code><br/>#!/bin/sh<br/>export GTK_PATH=/usr/lib32/gtk-2.0<br/>export PANGO_RC_FILE=/etc/pango32/pangorc<br/>export GDK_PIXBUF_MODULE_FILE=/etc/gtk-2.0/gdk-pixbuf.loaders.32<br/>export FIREFOX_DSP=esd<br/>linux32 /usr/local/firefox32/firefox $@<br/></code><br/><br/>E poi, tocco finale senza il quale non va nulla, scaricate la <a href="http://www.zaffa.org/wp-content/uploads/2007/11/libflashsupport.so" target="_blank">libreria libflashsupport</a> che ho ricompilato con alcune modifiche per permettergli di funzionare in questa configurazione, e salvatela in <code>/usr/lib32</code> dove il plugin flash andrà a cercare le librerie di supporto. Fatto questo il suono delle applicazioni flash che girano in firefox32 si sentiranno anche sui thin client.<br/><br/>Per chi volesse ricompilarsi (o anche pacchettizare) libflashsupport spiego la procedura.<br/>Innanzitutto per poterlo compilare correttamente ci vogliono alcune librerie a 32 bit. Per evitare lunghe e penose installazioni di software a 32 bit su una macchina X86_64 ho raccolto queste librerie in <a href="http://www.zaffa.org/wp-content/uploads/2007/11/lib32audiolib.tgz" target="_blank">questo file</a>, sarà sufficiente scompattare l'archivio e copiare i files in <code>/usr/lib32</code>.<br/><br/>I sorgenti più recenti di libflashsupport <a href="https://svn.revolutionlinux.com/MILLE/XTERM/trunk/libflashsupport/Tarballs/libflashsupport-1.2.tar.bz2" target="_blank">si scaricano qua</a>. Una volta scompattato l'archivio vanno modificate le righe <code>CFLAGS</code> e <code>LIBDIR</code> del Makefile in questo modo:<br/><br/><code>CFLAGS=-fPIC -shared -O2 -Wall -m32<br/>LIBDIR=/usr/lib32</code><br/><br/>a questo punto si può compilare.<br/><br/>Se invece per semplicità si dovesse decidere di lasciare installato il browser a 64 bit così come viene dalla distribuzione e si fosse disposti a rinunciare a qualche funzionalità , esiste comunque un modo per usare sui thin client il <a href="http://swfdec.freedesktop.org" target="_blank">plugin flash opensource swfdec</a> che, a partire dalla versione <a href="http://swfdec.freedesktop.org/download/swfdec/0.5/swfdec-0.5.4.tar.gz" target="_blank">0.5.4</a> ha aggiunto il supporto a pulseaudio. L'opzione di configurazione però non è documentata e ho un po' fatto fatica a trovarla: quando si lancia il comando <code>../configure</code> l'opzione per abilitare pulseaudio è <code>--with-audio=pa</code>. Bisogna anche avere installato il pacchetto libpulse-dev. Per chi non vuole cimentarsi con la compilazione metto a disposizione i pacchetti già pronti per Ubuntu Gutsy AMD64 con pulseaudio già abilitato: <a href="http://www.zaffa.org/wp-content/uploads/2007/11/swfdec_054-1_amd64.deb" target="_blank">swfdec</a>, <a href="http://www.zaffa.org/wp-content/uploads/2007/11/swfdec-gnome_054-1_amd64.deb" target="_blank">swfdec-gnome</a>, <a href="http://www.zaffa.org/wp-content/uploads/2007/11/swfdec-mozilla_054-1_amd64.deb" target="_blank">swfdec-mozilla</a> (su richiesta in breve tempo potrei anche fabbricare dei pacchetti per ubuntu 32bit). Inutile dire che declino qualsiasi responsabilità sul fatto che vadano, non vadano o addirittura facciano dei danni. L'unica cosa che ho testato è che l'audio in uscita dai filmati di youtube funziona bene usando il plugin swfdec-mozilla con pulseaudio. Quindi non accetto reclami, semmai suggerimenti :-)Unknownnoreply@blogger.com23tag:blogger.com,1999:blog-5044590136927337480.post-88896569948531188102007-11-06T09:09:00.000-08:002013-09-28T05:50:16.905-07:00Postfix, Exchange e pipeliningTalvolta da <a href="http://www.postfix.org">postfix</a> non è possibile inviare posta verso alcuni domini e nei log si trovano dei messaggi abbastanza generici che parlano di "timeout after DATA". <a href="http://www.postfix.org/faq.html#timeouts" target="_blank">In questi casi di solito</a> 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 <code>sysctl -w net.ipv4.ip_no_pmtu_disc=1</code>). 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).<br/><br/>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 <a href="http://www.irbs.net/internet/postfix/0302/0564.html" target="_blank">questo</a>. In pratica alcune versioni di Exchange durante la fase di negoziazione del protocollo millantano di supportare la funzione <a href="http://www.faqs.org/rfcs/rfc1854.html" target="_blank">PIPELINING</a>, 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.<br/><br/>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:<br/><br/>Edito il file <code>/etc/postfix/main.cf</code> e aggiungo la riga:<br/><br/><code>smtp_discard_ehlo_keyword_address_maps = hash:/etc/postfix/ehlo_keywords</code><br/><br/>Poi edito /etc/postfix/ehlo_keywords in questo modo:<br/><br/><code><ip_server_remoto_bacato> pipelining</code><br/><br/>salvo, chiudo e lancio il comando <code>postmap /etc/postfix/ehlo_keywords</code><br/><br/>A questo punto "<code>postfix reload</code>" ed il gioco è fatto.<br/><pre></pre>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-5044590136927337480.post-76663436315214702152007-10-18T08:39:00.000-07:002013-09-28T05:50:16.541-07:00LTSP su Ubuntu Gutsy: sempre più facileOggi è il 18 Ottobre, data in cui dovrebbe uscire la release 7.10 di Ubuntu (Gutsy Gibbon). Sul <a href="http://www.ubuntulinux.com" target="_blank">sito di Ubuntu</a> 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".<br/><br/>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:<br/><br/><code>aptitude install ltsp-server ltspfs</code><br/><br/>e ho accettato di installare le relative dipendenze.<br/><br/>Non ho assolutamente preso in considerazione questo messaggio:<br/><br/><code>NOTE: you will probably want to add to /etc/exports:<br/>/opt/ltsp *(ro,no_root_squash,async)<br/>and then run:<br/>invoke-rc.d nfs-kernel-server reload</code><br/><br/>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:<br/><br/><code>ltsp-build-client</code><br/><br/>e ho aspettato la fine del processo.<br/><br/><a name='more'></a><br/>Per quanto riguarda la configurazione del dhcp rimando alla descrizione che ho fatto <a href="http://www.zaffa.org/2007/06/08/ubuntu-ltsp-thin-client-per-piccola-azienda-2/" target="_blank">qua</a>. Sotto questo aspetto non è cambiato nulla. Alla fine della preparazione dell'ambiente client ho semplicemente inserito in un vecchio pc il cdrom per l'avvio dalla rete (preparato come descritto <a href="http://www.zaffa.org/2007/10/05/ubuntu-ltsp-thin-client-per-piccola-azienda-3/" target="_blank">qua</a>) e ho avviato: ha funzionato tutto al primo colpo senza batter ciglio. Tuttavia qualcosa è cambiato, anzi molto, anche se non si nota subito. Innanzitutto il file system principale non viene più fornito ai client via NFS ma viene fornito via nbd-server (Network Block Device server). La particolarità di questo servizio è che viene servito un singolo file immagine che i client sono in grado di montare ed utilizzare come un filesystem completo. Questo rende molto più veloce l'avvio dei thin client. L'aspetto negativo è che ogni volta che si fa una modifica al filesystem dedicato ai thin client (<code>/opt/ltsp/i386/</code> ) bisogna poi lanciare a mano il comando <code>ltsp-update-image</code> per ricereare una nuova immagina aggiornata, e questo porta via qualche minuto.<br/><br/>Il file di configurazione <code>lts.conf</code> è stato spostato fuori dal filesystem virtuale. Si trova adesso (anzi non si trova, lo si crea in caso di bisogno, ma funziona già tutto bene anche senza) nelle directory servite da tftpd, in <code>/var/lib/tftpboot/ltsp/i386</code>, e viene caricato prima che venga caricata l'immagine del filesystem. In questo modo<br/>è possibile fare delle modifiche a <code>lts.conf</code> senza dover ogni volta ricreare l'immagine del file system.<br/><br/>L'audio adesso funziona sui thin client "out of the box", nessuna configurazione particolare, semplicemente va. Sul mio thin client di prova ha funzionato anche l'acquisizione audio via microfono, in maniera nitida e chiara dopo aver alzato i livelli del device "Capture" di Pulse Audio nel mixer, direttamente sul thin client. Questo ovviamente promette molto bene per quanto riguarda la telefonia Voip utilizzando cuffiette e microfoni direttamente attaccati ai thin client. Skype invece ancora non ne vuole sapere, non gli ho dedicato molto tempo ma l'inizio non è stato affatto buono. Per far funzionare correttamente l'audio nelle applicazioni flash, come ad esempio i filmati di youtube, c'è bisogno della libreria <a href="http://pulseaudio.vdbonline.net/libflashsupport/libflashsupport_1.0~2219-1_i386.deb">libflashsupport</a>, è sufficiente installarla avviare firefox e il tutto funziona senza problemi.<br/><br/>Funzionano senza intoppi lettori cd/dvd, floppy e chiavette usb in locale. Non si vedono invece i dischi fissi già presenti nel thin client.<br/><br/>L'impressione generale, dopo un paio d'ore di smanettamenti, è molto positiva. Dopo aver installato i pacchetti necessari al funzionamento del server ltsp l'unica configurazione aggiuntiva che ho fatto è stata l'abilitazione del server x11vnc come descritto <a href="http://www.zaffa.org/2007/10/05/ubuntu-ltsp-thin-client-per-piccola-azienda-3/" target="_blank">qua</a> per poter vedere e interagire con i desktop degli utenti, cosa peraltro non necessaria per un buon funzionamento del sistema. In particolare mi ha colpito l'audio, perfettamente funzionante al primo colpo senza fare nulla.<br/><br/>Nulla da dire, stanno facendo davvero un buon lavoro. Il prossimo passo sarà quello di aggiornare l'ambiente LTSP in produzione alla nuova versione e cercare di verificare nell'uso continuativo quanto di buono ho visto in questa breve prova.Unknownnoreply@blogger.com73tag:blogger.com,1999:blog-5044590136927337480.post-65614837491922612042007-10-12T10:39:00.000-07:002013-09-28T05:50:16.471-07:00Backup su server FTPSegnalo un utile strumento che serve a mantenere sincronizzati una directory locale e una remota su un server ftp.<br/>Si tratta di <a href="http://ftpsync.sourceforge.net/" target="_blank">FTPSync.pl</a> che, come si intuisce dal nome, è uno script in <a href="http://www.perl.org/" target="_blank">Perl</a>.<br/><br/>Traduco parte di quanto scritto nel file <a href="http://ftpsync.sourceforge.net/ftpsync-1.2.33/README" target="_blank">README,</a>:<br/><br/>"<em>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.</em><br/><br/><u><em>Perchè usare ftpsync.pl invece di <a href="http://sunsite.org.uk/packages/mirror/" target="_blank">mirror</a>, <a href="http://www.lyra.org/sitecopy/" target="_blank">sitecopy</a> ....?</em></u><br/><br/><em>E' vero, ci sono altri progetti simili, alcuni commenti su questi:</em><br/><br/><em>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.</em>"<br/><br/><a name='more'></a>Io ero da tempo alla ricerca di uno strumento che mi permettesse di archiviare in maniera automatica una copia delle mie foto su un server ftp, e dal mio punto di vista non posso fare altro che confermare quanto scritto nel <a href="http://ftpsync.sourceforge.net/ftpsync-1.2.33/README" target="_blank">README.</a> Prima di ftpsync.pl ho provato mirror, sitecopy e <a href="http://wput.sourceforge.net/" target="_blank">wput</a> e ho sempre avuto grossi problemi. La sincronizzazione semplicemente non funzionava, o meglio era totalmente inaffidabile, a volte andava, altre no. Da quando ho scoperto ftpsync.pl e dopo averne verificato per un po' il funzionamento finalmente mi sento sicuro e posso mettere in cron il processo di sincronizzazione e dimenticarmene. Sul server remoto ho sempre una copia aggiornata del mio prezioso archivio fotografico ...... in realtà non è che sia davvero prezioso ma perdere anni di fotografie digitali, belle o brutte che siano, per un banale guasto all'hard disk credo che dispiacerebbe a tutti.<br/><br/>Ecco come usarlo: innanzitutto va scompattato il file <a href="http://ftpsync.sourceforge.net/ftpsync-1.2.33.tar.bz2">ftpsync-1.2.33.tar.bz2</a>, (<code>tar jvxf ftpsync-1.2.33.tar.bz2</code>). Dopo aver copiato il file ftpsync.pl dove si desidera sul sistema (io l'ho messo in /usr/local/bin: "<code>sudo cp ./ftpsync-1.2.33/ftpsync.pl /usr/local/bin/</code>" ) e essersi assicurati che sia eseguibile ("<code>sudo chmod +x /usr/local/bin/ftpsync.pl</code>") si può provare a lanciare <code>ftpsync.pl -h</code> per vedere quali opzioni sono disponibili.<br/><br/>L 'output è questo:<br/><br/><code>FTPSync.pl 1.2.33 (2006-10-27)</code><br/><br/><code>ftpsync [ options ] [ localdir remoteURL ]<br/>ftpsync [ options ] [ remoteURL localdir ]<br/>options = [-dfgpqv] [ cfg|ftpuser|ftppasswd|ftpserver|ftpdir=value ... ]<br/>localdir local directory, defaults to ".".<br/>ftpURL full FTP URL, scheme<br/>ftp://[ftpuser[:ftppasswd]@]ftpserver/ftpdir<br/>ftpdir is relative, so double / for absolute paths as well as /<br/>-c | -C like -i, but then prompts whether to actually do work<br/>-d | -D turns debug output (including verbose output) on<br/>-f | -F flat operation, no subdir recursion<br/>-g | -G forces sync direction to GET (remote to local)<br/>-h | -H prints out this help text<br/>-i | -I forces info mode, only telling what would be done<br/>-n | -N no deletion of obsolete files or directories<br/>-l | -L follow local symbolic links as if they were directories<br/>-p | -P forces sync direction to PUT (local to remote)<br/>-q | -Q turnes quiet operation on<br/>-v | -V turnes verbose output on<br/>cfg= read parameters and options from file defined by value.<br/>ftpserver= defines the FTP server, defaults to "localhost".<br/>ftpdir= defines the FTP directory, defaults to "." (/wo '"')<br/>ftpuser= defines the FTP user, defaults to "ftp".<br/>ftppasswd= defines the FTP password, defaults to "anonymous".</code><br/><br/><code>Later mentioned options and parameters overwrite those mentioned earlier.<br/>Command line options and parameters overwrite those in the config file.<br/>Don't use '"', although mentioned default values might motiviate you to.</code><br/><br/>Nella pratica io ho questa esigenza: ho una directory "/home/utente1/Pictures" sul mio pc e voglio sempre averne una copia su un server ftp remoto (ftp.example.com) nella cartella "Backup/Pictures"<br/><br/>Per fare questo posso usare questo comando (tutto sulla stessa riga):<br/><br/><code>/usr/local/bin/ftpsync.pl -p /home/utente1Pictures/ ftpuser=<ftpuser><ftpuser> ftppasswd=<ftppasswd><ftppasswd> ftpdir=/ ftp://ftp.example.com/backup/Pictures</ftppasswd></ftpuser></code><br/><br/>Il parametro -p serve a rendere il trasferimento monodirezionale, da locale al server ftp. In sostanza in caso di differenze fa sempre testo la mia copia locale. E' un po' rischioso, nel senso che se venisse cancellata per sbaglio una directory locale, alla successiva sincronizzazione la stessa directory verrebbe cancellata anche sul server remoto. Quindi bisogna prestare una certa attenzione. Se non avessi impostato questa opzione potrebbe succedere il contrario: se qualcuno facesse una modifica sui file presenti sul server ftp questa verrebbe riportata sul mio pc locale. Dal momento che ftp non è precisamente il protocollo più sicuro del mondo preferisco che sia la mia copia locale quella che comanda. Ma è comunque una questione di scelte personali e di cosa si ha bisogno di fare. E comunque, se possibile, una ulteriore copia su hard disk esterno, dvd o nastro è sempre bene averla.Unknownnoreply@blogger.com11tag:blogger.com,1999:blog-5044590136927337480.post-14353065691638321092007-10-10T08:57:00.000-07:002013-09-28T05:50:16.461-07:00Aggiornamento a WP 2.3Lo sapevo che sarebbe potuto succedere. Aggiornando il blog a <a href="http://www.wordpress.org" target="_blank">Wordpress 2.3</a> mi si è pesantemente sbelinato il tutto. Il <a href="http://cutline.tubetorial.com/" target="_blank">tema</a> 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.<br/><br/>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.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-5044590136927337480.post-17232961540841602152007-10-05T06:03:00.000-07:002013-09-28T05:50:16.323-07:00Ubuntu LTSP - Thin client per piccola azienda (3)In questo terzo e ultimo post sui thin client cerco di spiegare alcuni dettagli di messa a punto e gestione della rete basata su server LTSP e thin client. La documentazione ufficiale su questi argomenti si trova invece <a href="http://help.ubuntu-it.org/7.04/edubuntu/handbook/it/server.html" target="_blank">qua</a>.<br/><br/><strong>Preparazione dei dischi per il boot dalla rete</strong><br/><br/>Non tutti i pc sono in grado di fare il boot direttamente dalla scheda di rete. Anzi, normalmente solo macchine relativamente recenti, diciamo costruite grossomodo dal 2003 in avanti, sono in grado di farlo. Dal momento che uno dei vantaggi dei thin client è proprio quello di poter riciclare pc molti vecchi è assai probabile che sarà necessario preparare un cd o un floppy di avvio che permetta al pc di caricare il sistema operativo dal server ltsp.<br/>Fortunatamente la procedura è molto semplice: grazie a <a href="http://rom-o-matic.net/" target="_blank">rom-o-matic</a> è possibile "fabbricarsi" una immagine di avvio per ogni scheda di rete. Per fare questo bisogna innanzitutto conoscere il tipo di scheda di rete presente nel thin client, e questo in qualche caso potrebbe non essere semplicissimo. In generale, su pc in grado di avviarsi da cd-rom è sufficiente avviare la macchina con una qualunque distribuzione linux live (io mi porto sempre dietro una <a href="http://www.knopper.net/knoppix/index-en.html" target="_blank">Knoppix</a> per ogni evenienza) e usare il comando<br/><br/><code>lspci</code><br/><br/>per identificare in maniera corretta la scheda presente sotto la voce "Ethernet controller". Una volta identificata la scheda, se non si conosce il nome del relativo modulo da caricare è sufficiente fare una rapida ricerca su google mettendo il nome e il modello della scheda trovata assieme alla stringa "linux module" ed in genere tra i primi risultati viene riportato il nome del modulo corretto. Mi sono anche capitati pc ancora più vecchi, dotati solo di unità floppy da 3.5", ma in quel caso erano dotati di una vecchia scheda a 10 Mbit, non idonea per un thin client, e ho quindi dovuto sostituirle con schede a 100Mbit che già conoscevo.<br/>Una volta identificata la scheda e il relativo modulo su rom-o-matic si sceglie dal menu a tendina la voce corretta, il tipo di immagine ("Floppy bootable ROM image" per i floppy o "ISO bootable image without floppy legacy emulation" per i cdrom) e si scarica il file che viene prodotto. Per creare un floppy di avvio si può usare semplicemente il comando:<br/><br/><code>cat <nome_immagine_scaricata>.zdsk > /dev/fd0</code><br/><br/>mentre per il cd-rom basta masterizzare il file .iso.<br/>Un'opzione interessante del rom-o-matic è che molti parametri di rete possono essere predefiniti nell'immagine che si sta creando. Posso per esempio fissare già un indirizzo ip, un gateway di default e parecchi altri parametri. In teoria tutto questo dovrebbe permettere l'avvio e l'utilizzo di un thin client senza aver bisogno di configurare un server dhcp nella rete.<br/><br/><a name='more'></a><br/><strong>Installazione di software per i thin client</strong><br/><br/>I thin client prendono i file necessari al boot via tftp dal server, dopodichè montano le loro partizioni di lavoro via nfs sempre dal server. La partizione di root è rappresentata sul server da <code>/opt/ltsp/i386</code>, cioè dalla directory che è stata preparata all'inizio dell'installazione con il comando<br/><br/><code>ltsp-build-client</code><br/><br/>Anche in questa directory possiamo effettuare le normali operazioni di manutenzione, installazione/disinstallazione, aggiornamento di software etc. Per fare questo bisogna innanzitutto copiare il file <code>/etc/apt/sources.list</code> in <code>/opt/ltsp/i386/apt/</code> in modo da avere gli stessi repository di software; successivamente con il comando:<br/><br/><code>chroot /opt/ltsp/i386</code><br/><br/>si entra in quella directory come se fosse la nostra root. Per finire si monta un filesystem proc con il comando:<br/><br/><code>mount -t proc none /proc</code><br/><br/>A questo punto siamo pronti a lavorare nell'ambiente chroot come se fosse un vero e proprio sistema indipendente. Possiamo usare i classici comandi apt, dpkg etc. per la manutenzione e l'aggiornamento del sistema. Possiamo modificare il file sources.list per gli upgrade di versione. Per uscire dall'ambiente chroot è sufficiente digitare <code>exit</code> o la classica combinazione di tasti Ctrl+d.<br/>Per aggiornare invece il kernel dei thin client seguendo gli eventuali aggiornamenti di Ubuntu si usa il comando:<br/><br/><code>ltsp-update-kernels</code><br/><br/>che automaticamente si occupa di preparare le immagini del kernel aggiornate e di posizionarle al posto giusto nella directory servita da tftp.<br/><br/><strong>Il file di configurazione lts.conf</strong><br/><br/>Il file <code>/opt/ltsp/i386/lts.conf</code> è il file di configurazione dove è possibile definire delle impostazioni generali delle impostazioni particolari per singoli thin client.<br/>La struttura generale del file comprende una sezione [default] nella quale vengono messe le impostazioni generali e delle sezioni particolari (facoltative) per i singoli thin client. Una esaustiva rassegna delle possibili configurazioni che si possono utilizzare è riportata <a href="http://help.ubuntu-it.org/7.04/edubuntu/handbook/it/ltsp-client.html" target="_blank">qua</a>. Rispetto a quanto riportato nella documentazione "ufficiale" ho verificato che qualche volta succede di dover forzare nella configurazione un particolare driver video (<code>XSERVER=<nome_driver></code>) poichè il riconoscimento automatico non ha funzionato. Un'altra considerazione riguarda l'abilitazione del server di swap (NBD_SWAP): per parecchio tempo ho tenuto questa opzione abilitata e non ho osservato problemi anche se a dire il vero non ho notato nemmeno un utilizzo particolare dei file di swap che vengono creati sulla /tmp del server. Infatti <a href="http://www.zaffa.org/2007/06/08/ubuntu-ltsp-thin-client-per-piccola-azienda-2/" target="_blank">qua</a> riportavo uno spezzone di configurazione di lts.conf in cui NBD_SWAP era abilitato. Recentemente invece mi sono imbattuto in un thin client collegato da poco (un vecchio Pentium II a 300Mhz, una primizia), che ad un certo momento ha cominciato a perdere e ricreare la connessione con lo swap di rete provocando la creazione di decine di processi zombie sul server. Sinceramente non ho capito il motivo preciso di questo comportamento (oltretutto accaduto in piena giornata lavorativa, quindi senza la possibilità di stare con calma ad analizzare il problema ma con l'urgenza di ripristinare la piena funzionalità nel minor tempo possibile) ma è bastato mettere NBD_SWAP=False per quel client, far spegnere tutti i client e riavviare il server per riportare la situazione nella norma. Dopo questo episodio ho deciso di disabilitare questa opzione per tutti e non solo tutto funziona egregiamente ma ho l'impressione che il server sia meno impegnato rispetto a prima. Credo quindi che tale opzione vada lasciata disabilitata come da default, perchè in realtà non necessaria e, come ho potuto verificare, potenzialmente dannosa. E poi, parliamoci chiaro, perchè mai dovrebbe servire uno spazio di swap per ogni thin client quando la memoria usata per far girare le applicazioni è quella del server? Saranno ben affari suoi come e quando fare swap su disco.<br/><br/><strong>Periferiche locali</strong><br/><br/>E' possibile utilizzare alcuni tipi di periferiche collegate direttamente ai thin client. La maggior parte delle periferiche di archiviazione di massa (dischi fissi, lettori cd/dvd, chiavette usb etc.) possono essere utilizzate senza problemi. Per poter usare tali periferiche è necessario che siano installati i pacchetti ltspfs, libfuse2 e fuse-utils. Si pone poi <code>LOCALDEV=True</code> in lts.conf e si danno i permessi corretti agli utenti. Per fare questo si può utilizzare il pannello di amministrazione degli utenti di gnome, che nella sezione dei Privilegi Utente riporta una inequivocabile voce "Consentire l'uso di file system FUSE come i device a blocchi LTSP thin client", oppure si può aggiungere a mano l'utente prescelto nel gruppo "fuse" editando il file <code>/etc/group</code>. Anche numerose macchine fotografiche possono essere collegate in questo modo. La regola generale è che se una periferica si può presentare come "block device" allora probabilmente funzionerà . A meno di recenti novità delle quali non sono a conoscenza non è possibile invece masterizzare cd e dvd direttamente sui thin client, mentre in lettura funzionano normalmente. Non ho mai provato invece a collegare delle stampanti direttamente ai thin client poichè ho sempre avuto la possibilità di utilizzare stampanti di rete, ma pare sia possibile farlo.<br/><br/><strong>Audio</strong><br/><br/>La configurazione dell'audio è stata lunga e faticosa, cominciata quando ancora si era alla edgy usando <a href="http://developer.novell.com/wiki/index.php/Edgy/HOWTO:_PulseAudio" target="_blank">queste istruzioni</a>. A partire da Feisty la situazione è decisamente migliorata ed i pacchetti necessari sono tutti già presenti di default nei repository. <a href="http://developer.novell.com/wiki/index.php/Feisty/HOWTO:_PulseAudio" target="_blank">Qua</a> ci sono le istruzioni per Feisty. Come aggiunta personale posso dire che Skype, a dispetto di quanto riportato nei siti linkati prima, non funziona. Non c'è verso, il massimo del risultato che ho ottenuto sono alcuni secondi di funzionamento, dopodichè si pianta inesorabilmente. Se qualcuno dovesse riuscire a farlo funzionare con il demone <a href="http://pulseaudio.org" target="_blank">pulseaudio</a> (non necessariamente su un thin client, non va nemmeno in locale) lo prego anticipatamente di farmi sapere come, perchè sono mesi che ci provo senza successo. Comunque i programmi multimediali più usati (Listen, Rhytmnbox, mplayer, totem etc. etc.) funzionano senza problemi. Per permettere anche al plugin flash di funzionare a dovere in firefox si installa il pacchetto libflashsupport che si trova <a href="http://pulseaudio.vdbonline.net/libflashsupport/libflashsupport_1.0~2219-1_i386.deb">qua</a>. Le cose cambiano invece riguardo all'utilizzo di microfoni. L'intenzione era quella di mettere a punto il sistema per permettere agli utenti l'utilizzo di software di voip direttamente dai thin client. Per il momento l'unico programma che ha parzialmente funzionato è stato kphone, ma il segnale in ambo le direzioni è risultato pessimo, di fatto non utilizzabile, almeno finchè non avrò la possibilitò di fare nuovi test e messe a punto.<br/>Credo che con l'uscita di Gutsy, ormai prossima, alcuni di questi problemi potranno essere risolti.<br/><br/><strong>Gestione e accesso da remoto ai terminali</strong><br/><br/>Installando il pacchetto thin-client-manager-gnome e tutte le sue dipendenze è possibile utilizzare il <a href="http://doc.ubuntu.com/edubuntu/handbook/C/ltsp-tcm.html" target="_blank">pannello di gestione dei thin client</a>. Da questo pannello è possibile fare molte cose, dal mandare messaggi a un utente fino a uccidere o far partire un processo su un thin client. Una delle funzionalità più divertenti è quella di poter visualizzare una miniatura dello schermo su cui stanno lavorando gli utenti. Se questa funzione è decisamente lesiva della privacy degli utenti, abilitandola si ottiene però qualcosa di molto utile: la possibilità di interagire da remoto con l'utente direttamente sul suo desktop. La cosa è assai comoda per fornire supporto agli utenti in caso di bisogno.<br/><br/>La procedura per abilitare il desktop remoto è questa:<br/><br/><code>chroot /opt/ltsp/i386</code><br/><br/><code>mount -t proc none /proc</code><br/><br/><code>apt-get install x11vnc</code><br/><br/><code>logout</code><br/><br/>Poi si edita il file <code>/opt/ltsp/i386/etc/rc.local</code> e si inserisce questa riga:<br/><br/><code>x11vnc -display :6 -forever -loop -shared &</code><br/><br/>prima di <code>exit 0</code>.<br/><br/>Poi ci si assicura che lo script rc.local venga eseguito all'avvio dei thin client, basta dare questi comandi:<br/><br/><code>cd /opt/ltsp/i386/etc/rc2.d</code><br/><code>ln -s ../init.d/rc.local S99rc.local</code><br/><br/>se il link esiste già nessun problema, altrimenti viene creato. In questo modo ogni thin client all'avvio farà partire un demone x11vnc in ascolto sulla porta 5900, al quale sarà possibile collegarsi per la gestione remota del desktop.<br/><br/>Con la prossima versione di Ubuntu, la 7.10 denominata Gutsy Gibbon e la cui final release è <a href="https://wiki.ubuntu.com/GutsyReleaseSchedule" target="_blank">prevista per il 18 Ottobre 2007</a>, verranno introdotti alcuni cambiamenti nel sistema LTSP. Tanto per citarne alcuni tra i più importanti verrà abbandonato NFS in favore di un più efficiente demone nbdrootd, il root filesystem caricato all'avvio dai client sarà rappresentato da un singolo file immagine e cambierà di posizione il file lts.conf per non dover ricreare l'immagine di root ad ogni modifica. Senza dubbio il progetto è vivo e attivo e mi aspetto che vengano anche risolti alcuni dei problemi e delle limitazioni che ancora sono presenti.Unknownnoreply@blogger.com12tag:blogger.com,1999:blog-5044590136927337480.post-87371569711342771622007-10-02T09:36:00.000-07:002013-09-28T05:50:16.429-07:00Samba, Active Directory e permessiDebian 4.0 etch, samba 3.0.24-6etch4 attaccato ad un Domain Controller Win2000 con Active Directory (<a href="http://www.debian-administration.org/articles/340" target="_blank">http://www.debian-administration.org/articles/340</a>).<br/><br/>Era una situazione di semi emergenza, dovevo sostituire al volo un fileserver Win2K deceduto mettendo tutti gli share da un'altra parte, e cosa meglio di una macchina Linux già pronta, sottoutilizzata e con dello spazio libero? Installo samba e gli altri pacchetti necessari, faccio tutta la procedura per attaccarmi a Active Directory, sistemo le configurazioni. Tutto ok tranne una cosa: non c'è verso di fargli riconoscere a dovere i permessi relativi ai gruppi (non gli utenti, solo i gruppi). Di conseguenza non è possibile dare l'accesso agli utenti, se non facendo una sorta di "liberi tutti" o mettendo esplicitamente il nome di ogni singolo utente nella configurazione: ambedue soluzioni improponibili.<br/><br/><a name='more'></a><br/><br/>Succede che la direttiva "<code>valid users =</code>" che in smb.conf serve a definire i permessi a livello utente o di gruppo per ogni share di rete, semplicemente non funziona se si usano i nomi di gruppo recuperati da <a href="http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/winbind.html" target="_blank">winbind</a> dal dominio (ad esempio "domain users"). Ci ho provato in tutti i modi, mettendo e togliendo vari simboli davanti al nome del gruppo, tra cui il classico indicatore di gruppo di samba "@", ho usato virgolette, singoli apici, tutto quello che mi veniva in mente, ma niente. Ho guardato e riguardato il mio file di configurazione alla ricerca di qualche errore, aumentato la quantità di informazioni nei log, cercato documentazione ... pure riavviato la macchina (segno di grave frustrazione per un sistemista *nix). Ma ancora niente: ho solo perso del gran tempo, e in quella situazione non ne avevo più un granchè. Poi ho tentato, più per disperazione che altro, a mettere direttamente il <a href="http://en.wikipedia.org/wiki/Windows_SID" target="_blank">SID</a>, e tutto si è messo a funzionare. Baco? Errore mio nella configurazione? Chi lo sa .... l'importante era farlo andare.<br/><br/>In caso di bisogno per ottenere i SID si usa <a href="http://linux.die.net/man/1/wbinfo" target="_blank">wbinfo</a>, il comando che serve a fare le query direttamente al demone <a href="http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/winbind.html" target="_blank">winbind</a>. Per esempio: voglio ottenere il SID del gruppo "Domain users"? Da linea di comando digito:<br/><br/><code>wbinfo -n "domain users"</code><br/><br/>e ottengo qualcosa che assomiglia a:<br/><br/><u><code>S-1-5-21-1628384568-335560319-1050887974-513</code></u> Domain Group (2)<br/><br/>La parte sottolineata è il SID. In smb.conf la relativa riga di configurazione sarà :<br/><br/><code>valid users = S-1-5-21-1628384568-335560319-1050887974-513</code><br/><br/>Possono essere inseriti più SID separati da virgole e possono essere SID di utenti o di gruppo, funzionano bene allo stesso modo.<br/><br/>Insomma: se samba qualche volta fa le bizze sui permessi quando è connesso a un Active Directory, senza stare a perdere troppo tempo forse vale la pena tentare direttamente con i SID.Unknownnoreply@blogger.com6tag:blogger.com,1999:blog-5044590136927337480.post-87938610328477973752007-08-07T03:42:00.000-07:002013-09-28T05:50:16.415-07:00Apt: gpg error NO_PUBKEYOgni volta che aggiungo o modifico un repository di pacchetti deb su Debian o Ubuntu compare regolarmente un avviso del genere:<br/><br/><code>W: GPG error: http://apt.schmidtke-hb.de feisty Release: Le seguenti firme non sono state verificate perchè la chiave pubblica non è disponibile: NO_PUBKEY 5B638EFECEAE2DE7<br/>W: È consigliabile eseguire apt-get update per correggere questi problemi<br/></code><br/><br/>E ogni volta mi devo andare a ricercare i comandi per importare la chiave pubblica. Basta. <a href="http://sosoriosv.blogspot.com/2007/06/problemas-con-claves-publicas-en-mi.html" target="_blank">Qua</a> ho trovato una semplice e funzionale soluzione. Basta creare uno script fatto in questo modo:<br/><br/><code>#!/bin/bash<br/>until [ -z "$1" ]<br/>do<br/>gpg --keyserver pgpkeys.mit.edu --recv-key $1<br/>gpg --keyserver wwwkeys.eu.pgp.net --recv-key $1<br/>gpg -a --export $1 | sudo apt-key add -<br/>shift<br/>done</code><br/><br/>salvarlo con un nome appropriato (es. get_keys.sh), dargli i permessi di esecuzione (chmod +x get_keys.sh) e lanciarlo (come root o con sudo) in questo modo:<br/><br/><code>./get_geys.sh 5B638EFECEAE2DE7</code><br/><br/>e si otterrà :<br/><br/><code>gpg: richiesta della chiave CEAE2DE7 dal server hkp pgpkeys.mit.edu<br/>gpg: chiave CEAE2DE7: chiave pubblica «Oliver Schmidtke Apt-Repository (Repository Signing Key) <mightymod@schmidtke-hb.de>» importata<br/>gpg: Numero totale esaminato: 1<br/>gpg: importate: 1<br/>OK</mightymod@schmidtke-hb.de></code><br/><br/>Finito, semplice e funzionale.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-5044590136927337480.post-6114818898002443322007-07-30T10:34:00.000-07:002013-09-28T05:50:16.409-07:00QoS e openvpn su DebianUn nostro cliente ha diverse sedi collegate fra loro in vpn. Il software utilizzato per questo scopo è <a href="http://openvpn.net" target="_blank">Openvpn</a> su piattaforma linux (Debian, per la precisione). Le vpn realizzate con questo software sono sicure, stabili, efficienti e, last but not least, semplici da configurare e da gestire. Non a caso dopo che, qualche anno fa, avevo provato vari tipi di vpn per linux (tra cui l'ingestibile e complicatissimo <a href="http://www.freeswan.org" target="_blank">FreeSwan</a>) la scelta era caduta proprio su openvpn. E sinceramente non ho mai avuto modo di pentirmi di questa scelta. Per meglio comprendere il prosieguo di questo articolo suggerisco di dare un'occhiata a grandi linee a come funziona un tunnel con Openvpn.<br/><br/>Recentemente ho avuto bisogno di implementare un servizio di QoS (Quality of Service) tra le due sedi principali per permettere a due apparecchi per videoconferenza di comunicare al meglio fra loro: andava garantita una disponibilità minima di banda alle comunicazioni tra le due due macchine per permettere alla videoconferenza di svolgersi in maniera fluida senza scatti e/o altri disturbi.<br/><br/><a name='more'></a>La situazione della rete era la seguente:<br/><br/>Sede 1 (solo i parametri effettivamente rilevanti):<br/>rete: 192.168.195.0/24<br/>interfaccia esterna firewall: eth0<br/>interfaccia VPN: tun0<br/>porta openvpn su eth0: 5001<br/>macchina videoconferenza: 192.168.195.218<br/><br/>Sede2<br/>rete: 192.168.196.0/24<br/>interfaccia esterna firewall: eth0<br/>interfaccia VPN: tun0<br/>porta openvpn su eth0: 5001<br/>macchina videoconferenza: 192.168.196.25<br/><br/>ambedue le reti collegate ad internet su fibra ottica con banda 10Mbit (cioè 1250 Kb/s nominali).<br/><br/>In sostanza la necessità era quella di isolare e garantire una quantità certa di banda al traffico vpn tra le due sedi, e all'interno del traffico vpn isolare e garantire la banda necessaria al traffico tra le due macchine.<br/><br/>Per documentarmi sono partito dal <a href="http://lartc.org/howto/" target="_blank">Linux Advanced Routing & Traffic Control Howto</a>, ottimo compendio che già avevo consultato quando avevo avuto bisogno di creare delle regole di policy routing. Una lettura della parte riguardante appunto il QoS mi ha fatto ritenere che il sistema di classificazione HTB fosse il più indicato per la mia situazione. Mi sono quindi indirizzato verso <a href="http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm" target="_blank">HTB Linux queuing discipline manual - user guide.</a><br/><br/>I due firewall su cui ho lavorato sono due Debian Sarge con kernel di default 2.6.8-3-686. E' sufficiente installare il pacchetto "iproute" per avere tutto ciò che serve.<br/>Seguendo prima la guida e cercando poi di adattare gli esempi alle mie esigenze ho cominciato a scrivere le regole necessarie ad isolare il traffico vpn dal resto del traffico in uscita sull'interfaccia eth0 sul firewall della rete1:<br/><br/><code>#creo una coda con algoritmo htb sull'interfaccia eth0 e la chiamo "1:"<br/>#default 12 significa che ogni traffico non altrimenti classificato<br/># viene assegnato alla classe 1:12<br/></code><code><br/>tc qdisc add dev eth0 root handle 1: htb default 12<br/></code><code><br/>#Creo la classe root 1:1 (figlia diretta di 1:)<br/>tc class add dev eth0 parent 1: classid 1:1 htb rate 1200kbps ceil 1200kbps<br/></code><code><br/>#creo le altre classi come figlie di 1:1<br/># le classi figlie di una classe root possono scambiarsi e ripartirsi fra loro la banda<br/># diverse classi root invece non possono farlo<br/># per questo creo le classi di cui ho bisogno come figlie di una root<br/># tutto il traffico non altrimenti classificato cade in classe 12<br/># e, quando la banda è satura, ha diritto ad un massimo di 128K/s di banda<br/>tc class add dev eth0 parent 1:1 classid 1:10 htb rate 512kbps ceil 1200kbps<br/>tc class add dev eth0 parent 1:1 classid 1:11 htb rate 256kbps ceil 1200kbps<br/>tc class add dev eth0 parent 1:1 classid 1:12 htb rate 128kbps ceil 1200kbps<br/></code><code><br/># assegno il traffico vpn (porta 5001) alla classe 10<br/># gli garantisco quindi 512 K/s di banda<br/>tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 5001 0xffff match ip sport 5001 0xffff flowid 1:10</code><br/><br/>A questo punto ho creato tre classi di "banda garantita", la 12 (poca banda, dove metto tutto ciò che non classifico), la 11 (un po' più di banda, per adesso non utilizzata, verrà usata per traffico di media importanza) e la 10 (tanta banda garantita, ci metto il traffico tra i due capi della vpn) e ho isolato il traffico vpn dal traffico normale sull'interfaccia eth0 assegnandolo alla classe 10.<br/><br/>Quello che resta da fare è passare sull'interfaccia vpn (tun0) e classificare il traffico anche qua in modo che il traffico tra le due macchine di videoconferenza abbia una certa banda garantita. I primi passaggi sono gli stessi: creo una coda e delle classi di banda:<br/><br/><code>tc qdisc add dev tun0 root handle 1: htb default 12<br/>tc class add dev tun0 parent 1: classid 1:1 htb rate 1200kbps ceil 1200kbps<br/>tc class add dev tun0 parent 1:1 classid 1:10 htb rate 512kbps ceil 1200kbps<br/>tc class add dev tun0 parent 1:1 classid 1:11 htb rate 256kbps ceil 1200kbps<br/>tc class add dev tun0 parent 1:1 classid 1:12 htb rate 128kbps ceil 1200kbps</code><br/><br/>Successivamente creo una regola per identificare il traffico che mi interessa, quello tra le due macchine, ed assegnarlo alla classe 10:<br/><br/><code>tc filter add dev tun2 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.195.218 match ip dst 192.168.196.25 flowid 1:10</code><br/><br/>Fatto questo le regole di classificazione sul primo firewall sono pronte. La cosa simpatica è che in questa configurazione i comandi da dare sul secondo firewall sono esattamente gli stessi tranne l'ultimo, nel quale vanno invertiti gli indirizzi ip delle due macchine.<br/><br/>I comandi per ottenere qualche statistica sul traffico sono:<br/><br/><code>tc -s -d qdisc show dev eth0 # usare tun0 per statistiche sull'altra interfaccia</code><br/><br/>Questo comando fornisce statistiche generali sulla coda abbinata a una interfaccia. Per interpretarle occorre ricordare che <u>overlimits</u> rappresenta il numero di pacchetti che sono stati "ritardati" dalla regola, mentre <u>dropped</u> rappresenta quelli scartati.<br/><br/>Statistiche più dettagliate per le singole classi abbinate ad una coda si visualizzano con:<br/><br/><code>tc -s -d class show dev eth0</code><br/><br/>Chi avrà voglia di leggersi <a href="http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm" target="_blank">HTB Linux queuing discipline manual - user guide</a> (cosa ovviamente consigliatissima) si renderà immediatamente conto che quanto qui sopra descritto rappresenta solo una piccola parte di quanto si può fare con la classificazione dei pacchetti basata su HTB. Tuttavia per le mie attuali esigenze è stato ampiamente sufficiente e sono riuscito a metterlo in piedi in un paio d'ore partendo da una conoscenza abbastanza superficiale dei meccanismi di QoS. Per finire ho fatto alcuni rapidi test "occhimetrici" ed il risultato è davvero notevole: la banda viene gestita e attribuita correttamente a seconda del tipo di traffico ed il risultato è immediatamente visibile quando si tengono sotto controllo diversi tipi di traffico contemporaneamente.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5044590136927337480.post-67504366060575836242007-06-25T18:30:00.000-07:002013-09-28T05:50:16.389-07:00Belkin F8T012 bluetooth adapter su Kubuntu FeistyIl <a href="http://catalog.belkin.com/IWCatProductPage.process?Product_Id=273100" target="_blank">Belkin F8T012</a> è un adattore bluetooth usb dalle buone prestazioni che, a differenza di altri simili prodotti, non viene automaticamente riconosciuto da Feisty. Viene anzi riconosciuto come un'altra periferica (Pegasus II USB Ethernet) e non funziona. Bisogna quindi ricorrere a qualche aggiustamento manuale. Non essendo un patito di piccoli gadget come cellulari e palmari, non avevo mai installato dei dispositivi bluetooth su Linux. Ho comprato questo aggeggio (17 € su <a href="http://www.eprice.it" target="_blank">eprice</a>) più che altro per curiosità e ci sono rimasto un po' male quando ho scoperto che non funzionava "out of the box" con Kubuntu Feisty. Per farlo funzionare e comunicare col mio Nokia 6230i ci ho perso un bel po' di tempo cercando documentazione in rete, che per la verità ho trovato frammentata e tutto sommato incompleta. Scrivo qua come ho fatto un po' come promemoria è un po' perchè magari farà risparmiare un po' di tempo e incazzature ad altri.<br/><br/><a name='more'></a><br/><br/>Non appena collegato l'F8T012 ad una porta usb il sistema in automatico carica il modulo "pegasus". Nei log compare una riga simile a questa:<br/><br/><code>home kernel: [88825.887115] pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver</code><br/><br/>Questo non è il modulo giusto, la periferica non funziona affatto. Bisogna quindi impedire che venga caricato questo modulo. Per fare questo si aggiunge la riga<br/><br/><code>blacklist pegasus</code><br/><br/>al file <code>/etc/modprobe.d/blacklist</code>. Il modulo corretto è invece <code>bcm203x</code> (trovato per tentativi ed errori) che va quindi aggiunto al file <code>/etc/modules</code>. Fatto questo si può scegliere per un riavvio del pc oppure si deve scaricare a mano il modulo pegasus ("<code>modprobe -r pegasus</code>") e caricare il modulo bcm203x ("<code>modprobe bcm203x</code>"), verificando con lsmod che sia stato caricato correttamente.<br/><br/>Adesso va verificata la presenza dei pacchetti necessari a gestire la periferica bluetooth. Tali pacchetti sono: bluetooth, bluez-utils, kdebluetooth. Installati i pacchetti va apportata una piccola modifica al file <code>/etc/bluetooth/hcid.conf</code>. La riga "<code>security user;</code>" va sostituita con "<code>security auto;</code>". Alla riga "<code>passkey "1234";</code>" si può inserire al posto di 1234 la stringa di accesso bluetooth che si desidera e che verrà richiesta dal telefono (attenzione: la tastiera deve essere sbloccata altrimenti non funziona) e dal pc al momento della connessione.<br/><br/>Fatte queste modifiche si ricarica il sistema bluetooth ("<code>/etc/init.d/bluetooth restart</code>") e si avvia il demone kbluetoothd (basta lanciarlo da linea di comando una volta e kde lo riavvierà automaticamente nelle sessioni successive). A questo punto si inserisce la chiavetta nella porta usb e, se tutto è andato bene, dovrebbe comparire questo avviso:<br/><br/><a href="http://www.zaffa.org/2007/06/26/belkin-f8t012-bluetooth-adapter-su-kubuntu-feisty/priferica-trovata/" rel="attachment wp-att-20" title="Priferica trovata"><img src="http://www.zaffa.org/wp-content/uploads/2007/06/bluetooth.miniatura.png" alt="Priferica trovata" /></a><br/><br/>Il sistema è adesso pronto per comunicare con device esterni. Per il mio Nokia 6230i ho usato <a href="http://wammu.eu" target="_blank">wammu,</a> interfaccia grafica scritta in Python per <a href="http://www.gammu.org" target="_blank">gammu</a>, un software di gestione per numerosi modelli di cellulari. Come al solito un semplice "<code>sudo apt-get install wammu</code>" si farà carico di installare il software e tutte le sue dipendenze.<br/><br/>Per configurare wammu e farlo parlare con il telefono, da linea di comando si lancia "<code>sudo hcitool scan</code>", ovviamente dopo aver abilitato il bluetooth sul telefono. Il risultato sarà simile a questo:<br/><br/><a href="http://www.zaffa.org/2007/06/26/belkin-f8t012-bluetooth-adapter-su-kubuntu-feisty/ricerca-periferiche/" rel="attachment wp-att-21" title="Ricerca periferiche"><img src="http://www.zaffa.org/wp-content/uploads/2007/06/bluetooth1.miniatura.png" alt="Ricerca periferiche" /></a><br/><br/>Si annota a questo punto il MAC Address del telefono (00:15:DE:97:80:D0), che servirà per configurare wammu. Si lancia wammu da linea di comando, si aprono le impostazioni e si configura in questo modo:<br/><br/><a href="http://www.zaffa.org/2007/06/26/belkin-f8t012-bluetooth-adapter-su-kubuntu-feisty/impostazioni-wammu/" rel="attachment wp-att-22" title="Impostazioni wammu"><img src="http://www.zaffa.org/wp-content/uploads/2007/06/bluetooth2.miniatura.png" alt="Impostazioni wammu" /></a><br/><br/>mettendo cioè il mac address trovato con hcitool nel campo "periferica". Le impostazioni non dovrebbero cambiare di molto usando altri modelli di cellulare, comunque sul <a href="http://cihar.com/gammu/phonedb/" target="_blank">Gammu phone database</a> si possono trovare i parametri per numerosi modelli di varie marche.<br/><br/>Con wammu si possono manipolare i dati della rubrica, del calendario, i promemoria e si possono inviare e visualizzare sms.<br/><br/>Per visualizzare il filesystem del telefono (foto e filmati sono le cose che credo interessino di più) si apre una finestra di konqueror e si digita nella barra delle url: "<code>sdp://<nome del dispositivo>/</code>" (nel mio caso il dispositivo è "nokia 6230i") per visualizzare le periferiche associate al cellulare:<br/><br/><a href="http://www.zaffa.org/2007/06/26/belkin-f8t012-bluetooth-adapter-su-kubuntu-feisty/periferiche-del-cellulare/" rel="attachment wp-att-23" title="Periferiche del cellulare"><img src="http://www.zaffa.org/wp-content/uploads/2007/06/bluetooth3.miniatura.png" alt="Periferiche del cellulare" /></a><br/><br/>Cliccando sull'icona "Obex file transfer" si accede al file system vero e proprio. Si può comunque accedere al filesystem del telefono direttamente dall'icona di kbluetoothd nella traybar.Unknownnoreply@blogger.com3