Truedoc

h1. Come creare un ambiente "virtualizzato" con linux-vserver su Lenny

Il supporto per "linux-vserver":http://linux-vserver.org/ è presente in Debian a partire da _Etch_. La tecnologia dei _container_ usata da "linux-vserver":http://linux-vserver.org/, pur non fornendo una macchina virtuale vera e propria, consente però un uso estremamente efficiente delle risorse, permettendo creare una serie di sistemi indipendenti, i _virtual-server_, che girano sotto lo stesso kernel, utilizzando lo stesso filesystem ed un unico stack di rete, che pur non essendo macchine virtuali in senso stretto, nella gestione ordinaria possono essere tranquillamente considerate come tali.

Ovviamente non trattandosi di una tecnologia di virtualizzazione, "linux-vserver":http://linux-vserver.org/ non consente di installare un _virtual-server_ con un sistema operativo diverso, come Windows. Qualora si abbiano di queste esigenze si dovrà ricorrere a tecnologie alternative come Xen o KVM. 

Come accennato "linux-vserver":http://linux-vserver.org/ è supportato a partire da Debian _Etch_, una volta installato il sistema base (queste note fanno riferimento alla versione distribuita con _Lenny_), si dovrà installare il kernel modificato per l'uso di "linux-vserver":http://linux-vserver.org/, con il comando:

<pre>

aptitude install linux-image-vserver-686

</pre>

alternativamente, se la macchina ha più di 2Gb di RAM, si dovrà installare il pacchetto @linux-image-vserver-686@. Per la gestione dei _virtual-server_ si dovranno inoltre installare i pacchetti: 

<pre>

aptitude install util-vserver vserver-debiantools

</pre>

Una volta completata l'installazione si riavvi la macchina con il nuovo kernel (in genere questo avviene automaticamente se si usa GRUB), si potrà verificare che questo è avvenuto correttamente se si otterrà qualcosa del tipo:

<pre>

root@vserver:~# uname -r

2.6.26-1-vserver-686

</pre>

A questo punto il sistema ospite è pronto e si può passare alla creazione dei propri _virtual-server_, se però si effettuano le operazioni via rete usando @ssh@ per collegarsi al sistema ospite è opportuno modificarne la configurazione. Questo è dovuto al fatto che quando si crea un _virtual-server_ e gli si assegna un indirizzo IP in realtà viene comunque usato lo stack TCP/IP della macchina ospite, per cui se su questa esiste un processo che ascolta sull'indirizzo generico (come è il default per @sshd@) questo riceverà tutte le connessioni, anche per gli IP gestiti poi dai vari _virtual-server_.

Per questo motivo, qualora si debbano far operare dei servizi sul sistema ospite, questi vanno configurati in modo da metterli in ascolto esplicitamente sull'indirizzo IP ad essa assegnato. Dato che in una configurazione ordinaria non vi è nessuna necessità di attivare sul sistema ospite altri servizi di rete a parte sshd, ci limiteremo a riportare le istruzioni per la configurazione di quest'ultimo, che è tutto sommato immediata; basta infatti modificare il file @/etc/ssh/sshd_config@ ed impostare esplicitamente una riga con qualcosa del tipo: 

<pre>

ListenAddress 192.168.1.38

</pre>

(usando l'indirizzo IP del sistema _ospite_), dopo di che si potrà riavviare il servizio.

A questo punto si potrà procedere alla creazione dei _virtual-server_, nel caso di Debian a questo scopo ci viene incontro il comando @newvserver@, che altro non è che una interfaccia semplificata al comando @vserver@, per creare un primo virtual server di test si potrà pertanto usare il comando: 

<pre>

newvserver --hostname vtestlenny --domain fi.trl --ip 192.168.1.202/24

</pre>

Il comando utilizza _deboostrap_ per creare un un nuovo _virtual-server_ con nome vtestlenny assengnandogli l'indirizzo IP 192.168.1.202/24, se non si specifica niente altro verrà installata una altra Lenny, ma esistono una serie di opzioni del comando che consentono di modificare il sistema installato, le più importanti delle quali sono riportate nella seguente tabella: 

|_.Opzione     |_.Significato|

| @--dist@     | distribuzione da installare, il default è @lenny@, si può specificare una versione qualunque di Debian |

| @--interface@| interfaccia di rete da usare, il default è @eth0@|

Questo significa che se si vuole installare un server con _Etch_ basterà eseguire al posto del precedente il comando:

<pre>

newvserver --hostname vtestetch --domain fi.trl --ip 192.168.1.203/24 --dist etch

</pre>

Inoltre si può usare il file @/etc/vservers/newvserver-vars@ come file di configurazione per il comando @newvserver@, questo altro non è che un segmento di codice shell dove definire delle opportune variabili, che poi modificano il comportamento del comando.

Come accennato @newvserver@ non è che una interfaccia semplificata al comando @vserver@, il programma di gestione dei _virtual-server_. Con questo si possono creare macchine virtuali in maniera generica, così come cancellarle, copiarle, e compiere ogni tipo di operazione sulle stesse. Il comando ha la sintassi generale: 

<pre>

vserver <nomevserver> <operazione> [opzioni]

</pre>

dove le principali operazioni sono riassunte nella seguente tabella:

|_.Operazione|_.Significato|

|@build@| Crea un nuovo _virtual-server_ |

|@delete@| Rimuove un _virtual-server_ (e cancella i relativi file)|

|@start@| Avvia un _virtual-server_|

|@stop@| Ferma un _virtual-server_ (con uno shutdown)|

|@enter@| Entra in un _virtual-server_|

Si tenga presente che tutti i _virtual-server_ vengono installati sotto @/var/lib/vservers@, in altrettante directory con il nome degli stessi. Se non si dispone di sufficiente spazio su @/var@ sarà necessario usare un link simbolico per portare la suddetta directory su un'altro filesystem.

Si tenga presente che se si vuole che un _virtual-server_ venga automaticamente avviato nella procedura di boot è necessario che sia presente ed installato (come per default) lo script di avvio @util-vserver@, con questo tutto quello che serve è marcare i _virtual-server_ da avviare con qualcosa del tipo: 

<pre>

echo "default" > /etc/vservers/vtestlenny/apps/init/mark

</pre>

Si tenga presente inoltre che alla creazione di un _virtual-server_ viene installato un sistema ridotto ai minimi termini, e predisposto un disco ram di default da 16 Mb su cui viene montata la @/tmp@ del server stesso, qualora questi siano troppo pochi (o non si voglia usare una directory temporanea in RAM) si dovrà modificare l'impostazione in @/etc/vservers/<nome>/fstab@, il cui contenuto di default è:

<pre>

none	/proc		proc	defaults		0 0

none	/tmp		tmpfs	size=16m,mode=1777	0 0

none	/dev/pts	devpts	gid=5,mode=620		0 0

</pre>

togliendo ad esempio la seconda riga.

Una delle caratteristiche più interessanti di "linux-vserver":http://linux-vserver.org/ è la cosiddetta _Unification_ cioè la possibilità, quando si hanno una serie di file identici all'interno dei singoli _virtual-server_ di mantenere sul disco una sola copia attraverso l'uso di speciali hard-link. La versione corrente del sistema consente di identificare detti file tramite un hash. La funzionalità deve però essere abilitata per ciascun virtual-server, nel caso di @vtestetch@ ad esempio questo può essere fatto con il comando @vserver <nome> vhashify@, ma perché questo funzioni deve essere preventivamente creata la directory @/etc/vservers/<nome>/apps/vunify@, altrimenti si avrà un messaggio di errore del tipo: 

<pre>

vserver:~# vserver vtestetch hashify

Failed to initialize unification for vserver

</pre>

inoltre per poter utilizzare il comando il _virtual-server_ deve essere attivo, in sostanza, per ricapitolare, occorrerà che siano stati eseguiti i comandi:

<pre>

mkdir /etc/vservers/vtestetch/apps/vunify

vserver vtestetch start

vserver vtestetch hashify

</pre>

si tenga presente però che questo meccanismo opera creando i link, ma non cancella quelli non più in uso, pertanto se si vuole ripulire il sistema da file non più utilizzati all'interno di nessun virtual-server occorrerà cancellarli manualmente, detti file sono mantenuti nella directory @/var/lib/vservers/.hash/@, per cui sarà sufficiente un comando come: 

<pre>

find /var/lib/vservers/.hash -type f -links 1 -print0 | xargs -0 rm

</pre>

da inserire eventualmente all'interno di un _cron job_.