Gentoo Logo

Guida a Linux-VServer con Gentoo

Indice:

1.  Introduzione

Il concetto di Linux-VServer

Il concetto alla base del progetto Linux-VServer è di separare l'ambiente user-space in distinte unità (a volte chiamate Virtual Private Server) in modo che ogni VPS sembri e si comporti come un vero server con i processi in esso contenuti.

Termini utilizzati in questa Guida

Termine Descrizione
Linux-VServer, VServer Linux-VServer è il nome ufficiale del progetto ed è usato in questa Guida con il medesimo significato
virtual server, vserver, guest system Tutti questi termini sono sinonimi e si riferiscono ad una istanza del server (ad esempio un virtual server)
host system, host La macchina fisica che monta Gentoo Linux e che ospita tutti i virtual server
util-vserver Il pacchetto util-vserver contiene tutti i programmi necessari per la manutenzione dei virtual server

2.  Configurazione del sistema host

Installare un VServer kernel

Codice 2.1: Installare vserver-sources

# emerge vserver-sources

Dopo aver installato vserver-sources è il momento di configurarlo usando make menuconfig. Qui sotto viene presentata una configurazione tipica per le versioni 2.1.1 e successive. Se si sta utilizzando la versione 2.0.x alcune opzioni di configurazione potrebbero non essere presenti.

Codice 2.2: Configurare vserver-sources

# cd /usr/src/linux-<VERSIONEKERNEL>-vserver-<VERSIONEVSERVER>
# make menuconfig

Linux VServer --->
(Non abilitare le opzioni legacy)
  [ ] Enable Legacy Kernel API
  [ ] Enable Legacy Networking Kernel API
(Leggere il testo d'aiuto)
  [ ] Remap Source IP Address
  [*] Enable COW Immutable Link Breaking
  [ ] Enable Virtualized Guest Time
  [*] Enable Proc Security
  [*] Enable Hard CPU Limits
  [*]   Avoid idle CPUs by skipping Time
  [*]   Limit the IDLE task
      Persistent Inode Context Tagging (UID24/GID24)  --->
  [ ] Tag NFSD User Auth and Files
  [*] Enable Inode Tag Propagation
  [*] Honor Privacy Aspects of Guests
  [ ] Compile Debugging Code

Nota: Se si usa reiserfs come filesystem, si deve abilitare l'opzione per gli attributi estesi di reiserfs nella configurazione del kernel e successivamente aggiungere attrs nelle opzioni in /etc/fstab.

Codice 2.3: Configurare le opzioni per reiserfs

File systems  --->
  <*> Reiserfs support
  [*]   ReiserFS extended attributes

Codice 2.4: Esempio di fstab con gli attributi estesi attivi

/dev/hdb1 /vservers reiserfs noatime,attrs 0 0

Dopo che il kernel è stato compilato e installato, è necessario aggiornare il bootloader ed infine controllare se il kernel riesce ad avviarsi correttamente.

Codice 2.5: Installare il kernel

(Compilare il kernel)
# make
(Installarlo)
# make modules_install
# cp arch/<arch>/boot/bzImage /boot/kernel-<KERNELVERSION>-vserver-<VSERVERVERSION>
(Modificare la configurazione del boot loader come richiesto e successivamente riavviare:)
# reboot

Configurare l'ambiente ospitante

Per la manutenzione del virtual server è necessario il pacchetto util-vserver il quale contiene tutti gli applicativi necessari e molte funzioni utili.

Codice 2.6: Installare util-vserver

# emerge >=sys-cluster/util-vserver-0.30.212

Si deve eseguire il comando vprocunhide dopo ogni riavvio per impostare correttamente i permessi in /proc per i guest di vserver. Due script di init verranno installati da util-vserver i quali eseguiranno il comando vprocunhide al posto dell'utente e prendendosi in carico la gestione dei server virtuali durante lo spegnimento dell'host.

Codice 2.7: script di init di util-vserver

# rc-update add vprocunhide default
# /etc/init.d/vprocunhide start
# rc-update add util-vserver default
# /etc/init.d/util-vserver start

3.  Creazione di un guest

Scaricare uno stage3 precompilato

Siccome molti comandi relativi all'hardware non sono disponibili all'interno di un server virtuale, esiste una versione modificata di baselayout chiamata baselayout-vserver. Tuttavia, a partire da baselayout-2/openrc, tutte le modifiche necessarie sono state integrate nella versione normale di baselayout, eliminando il bisogno di stage, profili e baselayout vserver separati. L'unico svantaggio (temporaneo) è che baselayout-2/openrc è ancora in fase di testing (~arch) e non ci sono ancora stage con tale versioni di baselayout/openrc disponibili nei mirror.

Appena baselayout-2/openrc diverranno stabile si potrà utilizzare uno stage3 precompilato prendendolo da uno dei mirror di Gentoo. Nel frattempo scaricare uno stage3/4 o un stage gentoo-vserver da qui. Siccome uno stage3 contiene un filesystem completo di root è possibile usare il metodo di creazione da modello di util-server. Tuttavia, questo metodo funziona in modo affidabile solamente da util-vserver-0.30.213_rc5, pertanto assicurarsi di avere installata la giusta versione.

Si deve scegliere un "context ID" per il vserver (si sconsiglia di usare context ID dinamici) nonché le informazioni necessarie sui dispositivi di rete (in questo esempio eth0 è configurata con 192.168.1.253/24 e il "context ID" sarà equivalente agli ultimi due ottetti dell'indirizzo IP del vserver).

Nota: Il context ID dovrebbe essere 1 < ID < 49152.

Usare il metodo di creazione da modello

Per diverso tempo lo stile di init semplice era l'unico stile di init disponibile per Gentoo, per esempio un normale processo di init verrà avviato all'interno del guest, similmente a qualsiasi sistema Unix generico. Tuttavia questo approccio ha alcune controindicazioni:

  • Nessuna possibilità di vedere l'output degli script di init/rc
  • Spreco di risorse per i processi di init inattivi in ciascun guest
  • Conflitti fastidiosi per /etc/inittab

Perciò molti utenti hanno richiesto la re-implementazione dello stile init di gentoo, che era stato abbandonato in quanto era un'implementazione molto sporca e funzionava saltuariamente a causa di altre modifiche introdotte in baselayout da allora. Tuttavia, da util-vserver-0.30.212 lo stile init di gentoo è stato reintrodotto in maniera concisa e diverrà l'impostazione predefinita in futuro.

Nota: Se non c'è nessun valido motivo per usare un processo di init aggiuntivo per ciascun guest o non si sa cosa fare in questo caso, è consigliabile optare per lo stile init di gentoo.

Codice 3.1: Inizio installazione dello stage3

# vserver myguest build \
  --context 1253 \
  --hostname gentoo \
  --interface eth0:192.168.1.253/24 \
  --initstyle gentoo \ (sostituire se necessario)
  -m template -- \
    -d gentoo \
    -t /path/to/stage3-<arch>-<version>.tar.bz2

Nota: Per rendere effettive le configurazioni di rete si deve modificare: /etc/conf.d/hostname, /etc/conf.d/domainname e /etc/hosts all'interno del guest system . Vedere il capitolo 8.b.1 e il capitolo 8.b.4. Il resto delle configurazioni del vserver saranno fatte sul sistema host.

Ora dovrebbe essere possibile avviare ed accedere al vserver usando i comandi seguenti.

Codice 3.2: Testare il virtual server

# vserver myguest start

  OpenRC 0.4.3 is starting up Gentoo Linux (x86_64) [VSERVER]

Press I to enter interactive boot mode

* /proc is already mounted, skipping
* Setting hostname to myguest...                     [ ok ]
* Creating user login records...                     [ ok ]
* Cleaning /var/run...                               [ ok ]
* Wiping /tmp directory...                           [ ok ]
* Updating /etc/mtab...                              [ ok ]
* Initializing random number generator...            [ ok ]
* Starting syslog-ng...                              [ ok ]
* Starting fcron...                                  [ ok ]
* Starting Name Service Cache Daemon...              [ ok ]
* Starting local...                                  [ ok ]
# vserver-stat
CTX   PROC    VSZ    RSS  userTIME   sysTIME    UPTIME NAME
0       90   1.4G 153.4K  14m00s11   6m45s17   2h59m59 root server
1252     2     3M   286    0m00s45   0m00s42   0m02s91 myguest
# vserver myguest enter
# ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:04 init [3]
27637 ?        Ss     0:00 /usr/sbin/syslog-ng
27656 ?        Ss     0:00 /usr/sbin/fcron -c /etc/fcron/fcron.conf
27676 ?        Ssl    0:00 /usr/sbin/nscd
27713 ?        S+     0:00 login
27737 pts/15   Ss     0:00 /bin/bash
27832 pts/15   R+     0:00 ps ax
# logout

4.  Manutenzione semplificata

Avviare i sistemi guest al boot

Si possono avviare, in modo sicuro, i sistemi guest al boot del sistema host. È possibile specificare per ogni sistema guest un contrassegno chiamato MARK. Adesso tutto quello che c'è da fare è assegnare un MARK ad ogni sistema guest tramite la propria configurazione e aggiungere gli script di init appropriati al runlevel default.

Codice 4.1: Configurazione dei MARK per ogni sistema guest

(Ripetere questi comandi per ogni sistema guest da contrassegnare)
# mkdir -p /etc/vservers/myguest/apps/init
# echo "default" > /etc/vservers/myguest/apps/init/mark

Codice 4.2: Aggiungere uno script di init al runlevel default

 # rc-update add vservers.default default
 

Sincronizzare portage

Lo script vesync aiuterà a tenere sincronizzati la cache dei metadata con gli overlay. vemerge permette di usare emerge con i sistemi guest.

Codice 4.3: Esempi

(Sincronizzazione dei metadata per 'myguest')
# vesync myguest
(Sincronizzazione dei metadata per tutti i guest)
# vesync -all
(Sincronizzazione di 'myoverlay' per tutti i guest)
# vesync -all \
  --overlay /usr/local/overlays/myoverlay \
  --overlay-host rsync://rsync.myhost.com/myoverlay \
  --overlay-only
(Installazione di app-editors/vim in 'myguest')
# vemerge myguest app-editors/vim -va

Aggiornamento dei sistemi guest

I sistemi guest, su Gentoo, possono condividere i pacchetti per evitare lunghi tempi di compilazione. Per poter utilizzare la condivisione dei pacchetti è necessario creare una cartella per centralizzare il salvataggio dei pacchetti sul sistema host. Usare /var/cache/vpackages sul sistema host, montandola in /usr/portage/packages per ogni sistema guest.

Codice 4.4: Aggiungere l'opzione bind per il mount

# mkdir -p /var/cache/vpackages
# $EDITOR /etc/vservers/myguest/fstab
(Aggiungere questa linea alla fine del file)
/var/cache/vpackages /usr/portage/packages none bind,rw 0 0

Adesso si può utilizzare vupdateworld per aggiornare tutti i sistemi guest. Il comando è equivalente a qualcosa tipo emerge --deep --update --newuse world ma dipende dalle opzioni passate da riga di comando.

Codice 4.5: esempi con vupdateworld

(Simulare l'aggiornamento per 'myguest')
# vupdateworld myguest -- -vp
(Aggiornamento di 'myguest' usando i pacchetti binari)
# vupdateworld myguest -- -k
(Aggiornamento di tutti i sistemi guest usando i pacchetti binari)
# vupdateworld -all -- -ka

Nota: Per poter ottenere pacchetti binari è necessario utilizzare PORTAGE_BINHOST (vedere man make.conf) oppure impostare FEATURES="buildpkg" in uno o più sistemi guest.

Dopo aver aggiornato con successo i sistemi guest è possibile aggiornare con semplicità i file di configurazione con vdispatch-conf. Questo script permette di usare dispatch-conf con i sistemi guest ereditandone le caratteristiche.

Codice 4.6: esempi con vdispatch-conf

(Aggiornare i file di configurazione di 'myguest')
# vdispatch-conf myguest
(Aggiornare i file di configurazione di tutti i guest system)
# vdispatch-conf -all

Contatti

Si può contattare l'autore o aprire un bug su Bugzilla in caso di problemi.



Stampa

Aggiornato il 3 marzo 2009

Oggetto: In questa guida si impara a installare un semplice server virtuale usando la tecnologia Linux-VServer

Benedikt Boehm
Autore

Shyam Mani
Redazione

Matteo Carli
Traduzione

Davide Cendron
Traduzione

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.