Usare la RAM Video come memoria di swap in Linux

 Linux in generale  3 Responses »
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

Organizziamo gli accessi SSH

 Articoli Blog, Linux in generale  No Responses »
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.

La gestione degli snapshot in btrfs

 Articoli Blog, Linux in generale  No Responses »
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

Installazione di Freeside SelfService

 Articoli Blog, Linux in generale  No Responses »
ago 052011
 

Freeside SelfService è l’interfaccia web per cliente finale che si collega al server freeside in modo da permettere al cliente di poter operare in autonomia sulle configurazioni dei servizi acquistati.
Dato che si tratta di una interfaccia pubblica, gli sviluppatori consigliano di utilizzare un server separato da quello ove risiede Freeside, pertanto in questo howto procederemo alla configurazione di una nuova VM Debian Squeeze.
Partendo da una installazione vanilla, installiamo Apache e mod_perl con:

apt-get install apache2 perl libapache2-mod-perl2 build-essential libexpat1-dev expat

Quindi installiamo i moduli CPAN necessari:

cpan Bundle::CPAN YAML Storable Text::CSV_XS Text::Template Business::CreditCard HTTP::BrowserDetect HTML::Parser Tie::IxHash
cpan HTML::Widgets::SelectLayers Date::Format Number::Format SOAP::Lite

Creiamo l’utente freeside sul server di frontend e assegnamoli una password temporanea:

useradd freeside
passwd freeside

quindi sul server freeside generiamo una chiave rsa per l’utente ed importiamola sul server di frontend:

su - freeside
ssh-keygen
scp .ssh/id_rsa.pub freeside@frontend-server:/home/freeside/.ssh/authorized_keys

A questo punto sul server di frontend possiamo levare la password temporanea per l’utente freeside:

passwd -l freeside

Ora modifichiamo la configurazione di Apache in modo che “giri” con l’utente freeside:

/etc/apache2/envvars
export APACHE_RUN_USER=freeside
export APACHE_RUN_GROUP=freeside

e modifichiamo il virtualhost di apache per poter eseguire i CGI nella directory ove risiederà il selfservice:

 #directory where selfservice .cgi scripts and .html templates are located
 
 AddHandler cgi-script .cgi
 Options +ExecCGI

A questo punto siamo pronti per installare freeside selfservice: innanzi tutto copiamo la direcory /freeside-2.3.0/fs_selfservice dal server di backend sul server selfservice:

(su - freeside)
scp /freeside-2.3.0/fs_selfservice freeside@frontend-server:/home/freeside

Spostiamoci sul server frontend selfservice e, come utente amministratore, compiliamo l’interfaccia selfservice:

cd /home/freeside/fs_selfservice/FS-SelfService/
perl Makefile.PL
make install
mkdir /usr/local/freeside; chown freeside /usr/local/freeside
touch /usr/local/freeside/selfservice_socket; chown freeside /usr/local/freeside/selfservice_socket
chmod 600 /usr/local/freeside/selfservice_socket

A questo punto l’installazione è completata. Non ci resta che riavviare apache sul server selfservice:

/etc/init.d/apache2 restart

e, sul server di backend, modificare lo script /etc/init.d/freeside aggiungendo l’ip del nostro server selfservice e riavviare il servizio:

/etc/init.d/freeside restart

Sia ben chiaro che l’interfaccia selfservice è un “ibrido” in quanto deve essere adattata alle esifenze dell’ISP, però rappresenta un punto di partenza interessante per poter lavorare.
Oltretutto questo non è l’unico metodo per comunicare con il server freeside: difatti, volendo, è possibile accedere al server mediante il protocollo XML-RPC per eseguire direttamente le API. Questa possibilità è molto più efficiente, però le comunicazioni non sono criptate, richiede maggiore programmazione e l’apertura della porta 8080 sul server freeside

Configurazione di un server OpenVPN su Debian Squeeze

 Articoli Blog, Linux in generale  No Responses »
ago 032011
 

OpenVPN è il sistema più semplice per gestire VPN in ambiente Linux. In questo Howto vediamo come configurare un concentratore OpenVPN utilizzando Debian Squeeze. Fortunatamente l’installazione è piuttosto semplice.

Installazione del server
Innanzi tutto installiamo i pacchetti necessari:

apt-get install openvpn udev

OpenVPN mette a disposizione un tool chiamato EasyRSA per creare i certificati per il collegamento. Installiamo il tool e generiamo i certificati per la Certification Authority interna:

cp -R /usr/share/doc/openvpn/examples/easy-rsa/ /etc/openvpn
cd /etc/openvpn/easy-rsa/2.0/
. /etc/openvpn/easy-rsa/2.0/vars
. /etc/openvpn/easy-rsa/2.0/clean-all
. /etc/openvpn/easy-rsa/2.0/build-ca

Quindi generiamo i certificati per il server:

. /etc/openvpn/easy-rsa/2.0/build-key-server server

e per il client:

. /etc/openvpn/easy-rsa/2.0/build-key client1

Inifine generiamo i parametri Diffie Hellman; questa operazione può essere parecchio lunga…

. /etc/openvpn/easy-rsa/2.0/build-dh

A questo punto copiamo i certificati server nella directory corretta:

cd /etc/openvpn/easy-rsa/2.0/keys
cp ca.crt ca.key dh1024.pem server.crt server.key /etc/openvpn

e copiamo sul client i certificati client. I file da copiare sono:

  • ca.crt
  • client1.crt
  • client1.key

Ora copiamo la configurazione del server OpenVPN:

cd /usr/share/doc/openvpn/examples/sample-config-files
gunzip -d server.conf.gz
cp server.conf /etc/openvpn/
/etc/init.d/openvpn start

Attraverso questa configurazione, il server negozierà con il client l’ip del tunnel e creerà l’interfaccia. Se il nostro scopo è quello di creare una connessione punto-punto tra un client ed un server, siamo perfettamente operativi; più avanti vedremo come utilizzare il nostro server OpenVPN per rendere accessibile al client tutta la rete interna.

Configurazione del client OpenVPN
Ovviamente esistono numerosi clien OpenVPN a seconda del sistema operativo che utilizzate. Se usate Linux con l’interfaccia GNOME, l’applet della rete nel quale potete configurare le VPN PPTP può essere utilizzato anche per comandare le VPN OpenVPN: vi serviranno i tre file segnalati prima e, attenzione, nel pannello “Avanzate” ailitate la compressione LZO.
Per MacOS esiste il client Tunnleblick
Per Windows, invece, esiste il client OpenVPN GUI.

Configurazione dell’ip forwarding, del nat e del DNS forwarding
Nel caso in cui vogliate che i vostri client abbiano accesso sia alla rete locale del server, ma anche alla rete Internet attraverso il server, è necessario fare qualche altra configurazione.
Innanzi tutto bisogna abilitare sul server l’IP forwarding ed il nat:

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Per rendere definitive queste modifiche, consiglio di aggiungere le righe qui sopra anche al file /etc/rc.local in modo che siano eseguite ad ogni riavvio del server.
Attraverso il tunnel OpenVPN saremo in grado di raggiungere qualsiasi rete collegata al server, però non è possibile utilizzare DNS esterni, per cui sarà necessario configurare un DNS sul server.
Il metodo più semplice è quello di installare il pacchetto dnsmasq che funge da proxy DNS tra il tunnel OpenVPN e i resolver impostati sul server:

apt-get install dnsmasq

Quindi modifichiamo il file /etc/openvpn/server.conf per far istruire i client che si collegano riguardo le rotte e il DNS:

/etc/openvpn/server.conf
....
push "dhcp-option DNS 10.8.0.1"
push "redirect-gateway def1"

e riavviamo OpenVPN

/etc/init.d/openvpn restart
 Older Entries  Newer Entries