7 emendamenti per salvare il Web

 Articoli Blog  No Responses »
set 302011
 

Torniamo nuovamente sul problema della norma ammazza-blog di cui abbiamo discusso in passato.
Dopo l’evento “la notte della rete” ci sono state delle consultazioni, però comunque non sono stati fatti passi avanti significativi e il pericolo reale di autocensura è comunque rimasto.
In pratica, a causa di questa norma, chiunque può contestare il contenuto di un qualsiasi articolo e chiederne la rettifica; se questa non avviene entro 2 giorni si rischia una multa che può arrivare fino a 12.500,00 Euro!
Sono stati proposti 7 emendamenti alla legge in modo da escludere dall’utilizzo di questa norma i siti personali, però serve l’impegno di tutti per fare opera di convincimento presso i parlamentari.
Pubblichiamo qui di seguito la lettera di Agorà Digitale con tutte le azioni che possiamo fare per aiutare nell’intento.

Ciao Alberto,

Ebbene si’, abbiamo un modo per disinnescare il nuovo tentativo di estendere a tutti i “siti informatici” compresi blog e siti amatoriali, la rigida regolamentazione della carta stampata in particolare relativamente all’obbligo di rettifica.

Firma per chiedere ai tuoi deputati di sostenere gli emendamenti che disinnescano il comma “ammazza-blog”: www.agoradigitale.org/emendamentisalvablog

L’iter del famoso comma “ammazza-blog” è ripreso assieme a quello del ddl intercettazioni in cui è contenuto e, se approvato, prevederà che qualsiasi persona pubblichi testi in rete, anche in modo amatoriale e per ristrette cerchie di amici, possa ricevere una richiesta di rettifica quando tali contenuti siano ritenuti scomodi da qualcuno. In caso di mancata pubblicazione della rettifica entro due giorni, scatterà una sanzione fino a 12.500 euro. Facile ipotizzare la possibilità di utilizzare in modo intimidatorio tale strumento: qualunque cittadino scriva in rete, non avendo un giornale organizzato con struttura legale disposta a difenderlo, sarà certamente spinto ad accettare richieste di rettifica anche se ritiene di aver scritto fatti reali, attuando cosi’ una forma di autocensura per non incorrere nella sanzione.

È fondamentale restare lucidi e assumerci la responsabilità di percorrere tutte le strade che, nel caso di approvazione della legge, quantomeno evitino la desertificazione del web italiano. Cio’ è possibile perchè, assieme all’iter sul provvedimento iniziato alla Camera nel luglio 2010 e poi sospeso in seguito alle forti pressioni contrarie, rientrano in gioco anche tutti gli emendamenti che erano stati presentati oltre un anno fa.

Ebbene 26 parlamentari (qui i nomi) di PD (8), Radicali (6), UDC (5), PDL (3), IDV (2) e Gruppo Misto (2) hanno presentato alla Camera ben 7 diversi emedamenti che in vario modo cercano di limitare ai soli contenuti professionali ed in particolare alle testate registrate la validità del comma incriminato.

Si tratta di un tesoro inestimabile, tanto più per il fatto di avere una caratterizzazione bipartisan. Attorno ad esso abbiamo la possibilità di raccogliere la disponibilità di chi non vuole aggravare l’anomalia informativa italiana.

Qualsiasi parlamentare può, fino al momento della votazione, apporre la sua firma su tutti o solo alcuni di questi emendamenti, se li ritiene condivisibili.

Vogliamo provare a portare gli attuali 26 firmatari verso i 316 della maggioranza necessaria all’approvazione di tali emendamenti alla Camera?

Invieremo a tutti i deputati la richiamesta di modifica assieme a tutte le firme.

Firma e fai girare: www.agoradigitale.org/emendamentisalvablog

Udev e il MAC address delle interfaccie di rete

 Articoli Blog, Linux in generale  No Responses »
ago 182011
 

In linux molto spesso viene utilizzato un demone chiamato udev in grado di rilevare la configurazione hardware del computer e creare dinamicamente i device nella directory /dev.

E’ un demone molto utile e comodo per cui viene installato di default in quasi tutte le distribuzioni Linux.

Tra le peculiarità di udev c’è quella di mantenere una serie di regole persistenti per quanto riguarda storage ed interfacce di rete: riguardo a queste, il device (/dev/ethX) viene associato in maniera persistente al MAC Address della scheda di rete, questo per far si che la configurazione di ethX rimanga sempre associata ad una determinata scheda di rete fisica.

Nella maggior parte di situazioni questo è comodo ed utile, ma ce ne sono altre in cui si ha la necessità di variare questa impostazione.

Ammettiamo di aver creato una VM in VMWare o KVM le cui schede di rete hanno il Mac Address assegnato automaticamente e che si effettui un clone della VM (non un live migration) su un altro server fisico: in questo caso, all’accensione, non si avrà più la rete configurata in quanto le schede di rete precedentemente impostate spariranno e appariranno nuovi device (con il numero identificativo immediatamente successivo a quelle precedentemente configurate) senza configurazione.

Come fare per tornare alla configurazione precedente e funzionante?

La maggior parte delle distribuzioni salva un file all’interno della directory /etc/udev.d/rules.d chiamto XX-persistent-net-rules.conf: è sufficiente cancellare questo file e riavviare il sistema. I device delle nuove schede di rete verranno ricreati usando la precedente configurazione e tutto dovrebbe ripartire regolarmente.

Ieri mi sono trovato però in una situazione analoga con Vyatta, un appliance basato su linux ottimizzato per fungere da router e firewall: in questo caso la directory /etc/udev.d/rules.d/ rimane vuota e bisogna trovare un altro metodo.

Innanzi tutto rimuoviamo lo script vyatta_net_name:

sudo su

cd /lib/udev/
mv ./vyatta_net_name ./vyatta_net_name_backup

Quindi, cosa più importante, aggiungiamo la reguente riga al file /lib/udev/rules.d/75-persistent-net-generator.rules

/lib/udev/rules.d/75-persistent-net-generator.rules
...
ENV{MATCHADDR}==”0*”, ENV{MATCHADDR}=”"

per far si che la configurazione delle schede di rete non venga considerata persistente.

Configuriamo la rete di una istanza su OpenNebula

 Articoli Blog, OpenNebula  No Responses »
mag 172011
 

Per chi è abituato all’utilizzo di sistemi di virtualizzazione classica, si può trovare spiazzato quando affronta per la prima volta il setup di una istanza in un cloud.
Difatti, lavorando direttamente sull’hypervisor, è pratica comune utilizzare un disco virtuale per ogni macchina virtuale contenente tutte le configurazioni specifiche di quella macchina.
Usando sistemi di cloud la cosa non può essere così: difatti chi acquista una istanza in un cloud pretende un setup quasi immediato, cosa che non permetterebbe ai sistemisti di creare una installazione ad-hoc per tale macchina, pertanto si è costretti ad operare in maniera diversa: in un sistema cloud vengono creati uno o più dischi master per le VM (ad esempio un disco con l’istallazione di base di una distribuzione) che vengono “duplicati” alla creazione dell’istanza della VM.
Nella maggior parte dei casi, inoltre, si tende ad utilizzare filesystem evoluti che permettono di creare snapshot dell’immagine master senza dover duplicare fisicamente l’immagine, cosa che rende il processo di provisioning ancora più rapido e migliora l’utilizzo dello spazio all’interno dello storage.
Da una simile premessa, risulta evidente che l’immagine master non può contenere una configurazione specifica per ciascuna delle istanze che vengono create, bensì è necessario che l’immagine all’avvio si “autoconfiguri” in modo da settare automaticamente quelle opzioni univoche che sono necessarie per il corretto funzionamento.
L’esempio più evidente è il settaggio dell’indirizzo IP: non è corretto settare un unico indirizzo IP all’interno della immagine master, bensì è necessario configurare l’immagine master in modo che setti automaticamente un IP univoco all’avvio.
Tale operazione specifica potrebbe essere compiuta attraverso un server DHCP installato all’interno del bridge della rete con le VM; OpenNebula ha però un metodo interno per gestire tutti questi parametri.

Il metodo che andremo a descrivere ora permette di configurare automaticamente l’indirizzo IP della scheda di rete della VM in base a quanto settato nel file di configurazione della VM. L’indirizzo IP verrà estratto in base al MAC Address assegnato alla scheda di rete: questa associazione può essere presente sia all’interno della configurazione del network virtuale associato all’intanza (onevnet per intenderci) sia usando una configurazione statica nella configurazione della VM.
Per eseguire questo setup automatico, è necessario copiare all’interno della directory /etc/init.d dell’istanza alla VM lo script per la propria distribuzione scaricabile da qui.
Quindi, utilizzando il comando ln -s, o qualsiasi altro comando proprio della distribuzione, far partire il comando prima della configurazione della rete: all’avvio dell’istanza, lo script estrarrà l’indirizzo IP assegnato alla VM e creerà il file di configurazione per il setup statico della rete, pronto per essere utilizzato successivamente dallo script di configurazione.

Storage a blocchi con AoE

 Articoli Blog, Linux in generale  No Responses »
apr 042011
 

Quando abbiamo la necessità di collegare uno storage a blocchi ad una batteria di server, ci viene spontaneo soffermarci sul protocollo iSCSI.
Questo protocollo permette di incapsulare le istruzioni SCSI su una connessione IP e promette di raggiungere prestazioni simili a SAN in Fibre Channel ad un costo nettamente inferiore. Il protocollo è largamente diffuso sia sul mondo Linux, sia sul mondo proprietario (VMWare, Windows, ecc).
iSCSI, però, manifesta i sui limiti in caso di intenso traffico in quanto carica la CPU del server durante le operazioni di incapsulamento e decapsulamento dei pacchett SCSI nel/dal pacchetto IP. Quando il traffico aumenta, quindi, per mantenere prestazioni adeguate si rende necessario acquistare costose schede ethernet dedicate in grado di compiere direttamente questa operazione, senza caricare la CPU dello storage.

Se la nostra SAN dovrà servire esclusivamente sistemi Linux, però, c’è una valida alternativa ad iSCSI: AoE.
AoE è l’acronimo di ATA over Ethernet ed è un protocollo concettualmente simile all’iSCSI, però molto più “light”: basti solo pensare che l’intera specifica del protocollo risiede in sole 9 pagine!
AoE è in grado di inviare direttamente i comadi ATA su Ethernet, senza però incapsularli all’interno di un pacchetto IP, pertanto l’overhead del protocollo iSCSI con l’annesso maggior carico della CPU viene scongiurato: le comunicazioni avvengono sfruttando direttamente il MAC Address, pertanto hanno il limite (che non ha iSCSI) di non essere routabili.
In caso di più device all’interno della stessa rete, il protocollo AoE permette di identificarli assegnando due valori: shelf e slot che sono assegnabili liberamente alla creazione del device, ma che concettualmente sono simili all’idea dell’identificativo del disco (shelf) e della partizione (slot).

Qualsiasi distribuzione linux è adatta ad utilizzare questo protocollo: l’introduzione a livello kernel è arrivata già con la release 2.6.11 e due pacchetti (vblade e aoetools) permettono di gestire il protocollo.

Configurazione di uno storage AoE
Sul server che fungerà da storage (in gergo chiamato “target”) è necessario installare il pacchetto vblade che permette di trattare i device AoE analogamente al Coraid Etherdrive. Una volta installato il pacchetto, è necessario esportare il drive; ad esempio:

./vbladed 0 0 eth0 /dev/sda4

Così facendo, esporteremo il disco /dev/sda4 attraverso l’interfaccia di rete eth0 assegnando lo shelf 0 e lo slot 0. Il comando restituirà in output una striga simile alla seguente:

pid 12905: e0.0, 436614507 sectors

Questa indica il PID del processo (12905), il valore di shelf e slot (e0.0) e il numero di settori del disco esportato.

 

Configurazione di un client AoE
Per collegarsi ad un disco esportato attraverso un client linux, innanzi tutto è necessario caricare il modulo del kernel con:

modprobe aoe

Quindi, per montare il disco nello userspace, bisogna installare il paccheto aoetools. Con il seguente comando è possibile eseguire una scansione della rete per identificare i drive AoE e creare automaticamente il device:

aoe-discover;aoe-stat

Seguendo il nostro esempio, troverete un nuovo device in /dev/etherd/e0.0

A questo punto potete formattare il disco e montarlo proprio come se si trattasse di un disco locale:

mkfs.ext3 /dev/etherd/e0.0;mount /dev/etherd/e0.0 /mnt

Per semplicità ho usato ext3, nulla vieta ovviamente di utilizzare un filesystem cluster come ocfs2 o gfs e montare il disco su più client.