dic 072011
 

OpenERP è uno dei pochi software ERP OpenSource. Gli ERP sono sostanzialmente software gestionali che integrano funzionalità avanzate quali, ad esempio, sistemi di controllo di produzione, CRM, gestione del magazzino e molto altro.
OpenERP è un software stabile (siamo ormai giunti alla versione 6.1), tradotto in numerose lingue e ovviamente c’è una traduzione italiana ufficiale: quindi è un sistema che certamente è utilizzabile in produzione e si adatta agevolmente sia alle piccole aziende sia alle grandi corporate.

Una delle cose che personalmente reputo importanti in OpenERP è l’architettura che sta alla base: OpenERP è un sistema client-server realizzato avendo in mente l’apertura che hanno tutti i software più blasonati.
Il server è solo “il motore” del sistema, è realizzato in Python e si appoggia ad un database PostgreSQL; è possibile comunicare con il server solo attraverso delle API raggiungibili attraverso il protocollo standard XML-RPC.
Per utilizzare queste API, è possibile ovviamente usare delle interfacce installabili sulla propria workstation già pronte: sono tutte realizzate in Python attraverso la libreria PyGTK, sono aperte e funzionano su client Windows, MacOS e Linux. Oltre ai client installabili sul PC, c’è un ottimo client web che è possibile anche installare direttamente sulla stessa macchina ove è installato OpenERP Server.

E’ ovviamente possibile usare direttamente le API e il protocollo XML-RPC per far comunicare la propria applicazione con OpenERP. Ad esempio un ecommerce può sfruttare le API per avere in tempo reale la situazione del magazzino e per generare automaticamente i documenti ed i processi in caso d’ordine. A tal proposito, già esiste un interfacciamento funzionante e collaudato con il software di e-commerce “Magento”.

Essendo un software OpenSource, è aperto anche a funzionalità aggiuntive. Difatti OpenERP ha una architettura modulare ed è già presente un ecosistema di moduli ufficiali e di terze parti, comprese alcune interessanti verticalizzazioni già pronte come quella per le associazioni e per le case d’asta.
Il mio spassionato consiglio, è di non partire con una installazione completa di tutti i moduli, ma di partire con una installazione base e di aggiungere i moduli necessari solo in caso di effettiva esigenza: una installazione complenta, difatti, mette a disposizione una tale quantità di opzioni che è facile perdersi e disorientarsi.

Il capitolo moduli riserva però una sorpresa riguardo al meccanismo di licenza, che è una anomalia nel panorama delle modalità di distribuzione di software OpenSource. OpenERP, come molti altri software, esiste in due versioni: gratuita e a pagamento. Queste due versioni sono identiche, non esiste alcuna funzionalità aggiuntiva nella versione a pagamento ripetto alla versione gratuita.
La differenza riguarda esclusivamente la metodologia di sviluppo dei moduli: se una azienda ha necessità di una particolare funzione che non è presente originariamente nel sistema o in uno dei moduli installati, è possibile contattare una delle aziende certificate per farsi realizzare il modulo che soddisfi le proprie esigenze. Se si sta utilizzando la versione gratuita è obbligatorio rendere disponibile nell’ecosistema il modulo realizzato, altrimenti è possibile mantenerlo “riservato”.

ott 232011
 

I server di oggi vengono comunque normalmente dotati di schede video con parecchi MB di RAM dedicata estremamente veloce che però non sarà mai utilizzata perchè difficilmente si installerà un server Linux con l’interfaccia grafica X.

Perchè non utilizzare questo “ben di Dio” come memoria vera e propria da affiancare alla RAM tradizionale? Innanzi tutto una premessa: Linux già incorpora una memoria chiamata “swap” che non è altro che un’area di disco che subentra in aito della memoria RAM quando questa si satura. L’hard disk del nostro server, però, non potrà mai competere con la RAM quanto a prestazioni, per cui  è importante dotare il nostro server di RAM sufficiente a limitare il più possibile lo swap sul disco che penalizza le prestazioni complessive del nostro server.

In questo articolo vi spiegherò come configurare il nostro server Linux perchè utilizzi la RAM della scheda video come memoria di swap prima di utilizzare lo swap tradizionale su Hard Disk.

Innanzi tutto, verifichiamo quanta video ram abbiamo a disposizione:

lspci -vvv

Tra i vari device che saranno elencati ci sarà la scheda video. Ad esempio:

01:00.0 VGA compatible controller: ATI Technologies Inc NI Whistler [AMD Radeon HD 6600M Series] (prog-if 00 [VGA controller])
	Subsystem: Acer Incorporated [ALI] Device 0513
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Region 0: Memory at b0000000 (64-bit, prefetchable) [size=256M]
	Region 2: Memory at c0300000 (64-bit, non-prefetchable) [size=128K]
	Region 4: I/O ports at 3000 [size=256]
	Expansion ROM at c0340000 [disabled] [size=128K]
	Capabilities: 
	Kernel driver in use: radeon
	Kernel modules: radeon

Dobbiamo trovare la “region” di tipo “prefetchable”, che è normalmente quella più grande (nel mio caso 256MB): memorizziamo l’indirizzo di partenza (b0000000).
Ora dobbiamo fare un po’ di calcoli in esadecimale in quanto è comunque consigliabile non utilizzare l’intera videoram ma lasciarne qualche MB all’inizio in uso alla scheda: a tal proposito utilizzeremo il modulo slram che richiede in input due valori esadecimali: l’indirizzo di partenza e la quantità di ram.
Ad esempio, per quanto riguarda l’indirizzo di partenza, con un totale di 2^28 bytes (256M) videoram, volendo lasciare 2^24 (16M) per le normali funzionalità (probabilmente meno va comunque bene), l’indirizzo iniziale è 2^24 bytes oltre l’indirizzo di partenza (b0000000), quindi b1000000.
La quantità totale sarà calcolata trasformando in esadecimale il valore della vRAM totale – quella assegnata alle normali funzionalità video: nel nostro caso 240 MB -> 251658240 bytes -> F000000.

Ora andiamo a modificare il file /etc/modprobe.d/modprobe.conf per settare i parametri appena calcolati:

/etc/modprobe.d/modprobe.conf
options slram map=VRAM,0xb1000000,+0xF000000

Quindi carichiamo i moduli necessari:

modprobe slram
modprobe mtdblock

Il secondo modulo serve per creare un disco fisico utilizzando una regione mappata dal modulo slram: difatti, una volta caricato il modulo, apparirà un nuovo device /dev/mtdblock0 sul quale creeremo il disco di swap con priorità più elevata rispetto allo swap su hard disk:

mkswap /dev/mtdblock0 && swapon /dev/mtdblock0 -p 10
ott 102011
 

Nel mio lavoro ho spesso la necessità di lavorare contemporaneamente su più server a cui mi connetto tramite terminale con il protocollo SSH.

Una delle cose peggiori che si possono fare in questa situazione, è inserire dei comandi in una shell mentre si è convinti di lavorare su un’altra macchina: potenzialmente si può arrivare a forattare il disco del server sbagliato, anche se la cosa peggiore che a me è capitata è stata semplice un riavvio…

Onde evitare la possibilità che si verifichino simili errori, ho configurato il mio PC di lavoro con delle scorciatoie da desktop attraverso cui connettrmi al server, in grado di settare automaticamente un profilo con colorazione personalizzata.

Vediamo per punti come ho configurato il sisitema:

1) Abilitazione dell’accesso tramite certificato
Sebbene questo passaggio non sia necessario, risulta davvero comodo utilizzare il certificato per collegarsi ai server senza dover quindi ricordarsi una password specifica.
Per far ciò, sul mio pc ho lanciato il comando ssh-keygen per creare una chiave utilizzabile per collegarmi in ssh ai server. Lasciando le impostazioni di default, verrà creato il file .ssh/id_rsa.pub contenente la chiave pubblica da caricare sul server.

a@A:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/a/.ssh/id_rsa):
Created directory '/home/a/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/a/.ssh/id_rsa.
Your public key has been saved in /home/a/.ssh/id_rsa.pub.
The key fingerprint is:
3e:4f:05:79:3a:9f:96:7c:3b:ad:e9:58:37:bc:37:e4 a@A

Quindi, sul server, creiamo la directory .ssh (può già esistere):

a@A:~> ssh b@B mkdir -p .ssh
b@B's password:

e carichiamo la chiave pubblica del nostro server:

a@A:~> cat .ssh/id_rsa.pub | ssh b@B 'cat >> .ssh/authorized_keys'
b@B's password:

A questo punto possiamo collegarci al server tramite ssh senza dover più ricordare la password di accesso, cosa che rende l’operazione di accesso molto più veloce.

2: Creiamo un profilo personalizzato in Terminator
Come già detto in questo articolo, sono un fan di “Terminator”: si tratta di una applicazione simile ad X-Term ma con caratteristiche più evolute. In questo caso utilizzeremo la funzionalità “Profili” per creare una combinazione specifica di colori per l’accesso ssh al nostro server.
Click con il pulsante destro del mouse e scegliamo “Preferenze”.
Quindi andiamo in “Profiles” e click su “Aggiungi” per creare un nuovo profilo che chiameremo come il server (in questo caso “B”).
Infine andiamo in “Colors” e scegliamo “Custom” dal primo menu a tendina. Dalle due palette sottostanti scegliamo un colore di background e uno per il carattere.

3: Creiamo un pulsante di accesso per lanciare il terminale personalizzato
Ora bisogna aggiungere un pulsante al nostro Desktop Manager. Io uso XFCE e ho voluto creare un pannello aggiuntivo in cui inserisco i “lanciatori” per le mie sessioni terminale. La procedura da utilizzare è diversa se si usa Gnome o KDE (o qualsiasi altro DE), quello che conta è il comando da far eseguire al lanciatore:

terminator -p B -e 'ssh b@B'

Ecco che al click sul lanciatore, verrà aperta una nuova finestra di Terminator utilizzando il profilo “B” con i nostri colori personalizzati che eseguirà in automatico all’apertura il comando “ssh b@B” e l’accesso al server avverrà automaticamente grazie alla presenza del certificato.

ott 032011
 

Tra le distribuzioni che ho citato in questo articolo, ne manca una alla quale mi sono avvicinato di recente e che mi sta davvero dando notevoli soddisfazioni: Arch Linux.
Questa distribuzione è concettualmente simile a Gentoo, quindi è una “rolling release”: ciò vuol dire che non si è fermi ad una particolare versione della distribuzione (Debian 5, Debian 6, ecc.) ma un aggiornamento di sistema installerà sempre i pacchetti più aggiornati e non ci sarà mai la necessità di operare una “distro upgrade”.
Al contrario di Gentoo, Arch utilizza di default pacchetti precompilati e li gestisce attraverso il tool di gestione “pacman” che quanto a potenza e funzionalità non ha nulla da invidiare ad “emerge” di Gentoo (e quindi, a mio avviso, è molto più potente di yum/rpm e apt-get/aptitude). Inoltre c’è il comando yaourt per installare i pacchetti da sorgente gestendo in maniera automatica le dipendenze analogamente a ciò che fa emerge in gentoo.
Quanto al sistema di repository dei pacchetti, viene utilizzata una politica molto interessante: non ci sono innumerevoli repository di “proprietà” degli sviluppatori per i pacchetti non ufficiali così come avviene nella maggior parte delle distribuzioni (sia le “classiche”, sia Gentoo), bensì c’è un unico grande repository liberamente accessibile chiamato AUR.
La comunità di sviluppo di Arch è davvero vasta e sul wiki si trovano tutte (ma proprio tutte) le informazioni necessarie per l’utilizzo di praticamente tutti i pacchetti esistenti.
Altra caratteristica particolare di Arch è l’organizzazione dei file di configurazione in etc, molto simile all’impostazione “Vanilla” di Slackware: i demoni di avvio si trovano in /et/rc.d ma non sono presenti le classiche directory per linkare i demoni e avviarli (o fermarli) ad uno specifico runlevel: per tutte le configurazioni di sistema si usa un unico file /etc/rc.conf.
Ultima cosa degna di nota: ho installato Arch per “disperazione” in quanto ho acquistato un nuovo portatile con scheda video ATI HD6650M: tutte le altre distribuzioni provate creavano problemi con i driver ATI OpenSource già all’avvio di X, mentre con i driver Catalyst proprietari appariva il logo “unsupported hardware”; Arch, con i driver ATI Opensource, funziona alla grande e senza aver dovuto fare alcuna configurazione!
Nonostante l’hardware del mio portatile sia decisamente importante (Intel core I7 con 8 GB di RAM), ho installato l’interfaccia grafica Xfce: ho un PC senza fronzoli ma che si avvia velocemente. La potenza di un PC con l’immediatezza di un tablet!

set 182011
 

Btrfs è un filesystem di tipo COW (Copy on Write) sviluppato inizialmente da Oracle e approdato da qualche tempo nel mondo Linux.
Seppur annunciato come il futuro sostituto di ext4, a livello prestazionale non distacca in modo significativo l’ottimo e diffusissimo ext4 (anzi in alcuni casi ext4 è più veloce), però offre alcune funzionalità aggiuntive che lo rendono davvero interessante.
A mio avviso, la funzionalità più interessante introdotta in btrfs è che permette di gestire gli snapshot, funzionalità analoga a ZFS di Solaris.

Cos’è uno snapshot?
Lo snapshot è una “copia storica” di un filesystem, una specie di backup di disaster recovery preso in un determinato istante. Giusto per spiegarlo in parole semplici anche se tecnicamente è più complesso, quando si esegue uno snapshot si ha un volume vuoto sul quale vengono scritte esclusivamente le modifiche successive all’istante in cui si è creato. Questo permette di creare uno snapshot molto velocemente e lo stesso non occuperà lo stesso spazio del volume originale, ma solo lo spazio occupato dalle modifiche. Ovviamente più modifiche vengono inserite (ipoteticamente, più è vecchio lo snapshot) più spazio su disco occuperà lo snapshot.
Per gestire il filesystem btrfs si usa il comando btrfsctl. Per creare un nuovo snapshot si usa il comando:

btrfsctl -s "path snapshot" "path filesystem"

Ad esempio, se abbiamo un volume btrfs montato in /home, possiamo creare uno snapshot con il comando:

btrfsctl -s /home/snapshot.home /home

In questo modo, compatirà una directory /home/snapshot.home contenente lo snapshot di /home.
In btrfs lo snapshot è modificabile per cui sarà possibile modificare sia il contenuto di /home, sia il contenuto di /home/snapshot.home.

I subvolume in btrfs
Esiste una seconda funzionalità di btrfs che può essere associata alla funzionalità di snapshot: i subvolume.
Come già detto, la funzionalità di snapshot si applica solo ad un volume btrfs: come possiamo fare per eseguire lo snapshot di una directory all’interno di un volume btrfs?
Ad esempio ammettiamo di avere il nostro volume btrf montato in /home e di avere all’interno le home directory degli utenti pippo, pluto e paperino… ma di voler creare uno snapshot solo della home directory di pippo.
Per fare questo ci vengono in aiuto i subvolume. Questa funzionalità permette di create dei sotto-volumi virtuali (che si presentano come directory) sui quali sarà possibile agire singolarmente con lo snapshot.
Usando l’esempio precedente, creiamo i subvolume nel volume btrfs /home con:

btrfsctl -S pippo /home
btrfsctl -S pluto /home
btrfsctl -S paperino /home

in modo da avere le tre home directory utente in /home che in realtà sono subvolumi btrfs;
Ora creiamo lo snapshot di /home/pippo con:

btrfsctl -S /home/pippo.snapshot /home/pippo

Un po’ di pulizia
Per cancellare uno snapshot o un subvolume si usa l’opzione -D di btrfsctl. Ad esempio per cancellare lo snapshot di pippo:

btrfsctl -D pippo.snapshot /home

Per cancellare il subvolume di pluto:

btrfsctl -D pluto /home