
	Accueil Actualité Documentations GentooFR Portage Trucs et Astuces

Accueil du site > Documentations > Système > Virtualisation de serveur avec VServer

Virtualisation de serveur avec VServer

Augmentez la sécurité de vos serveurs par la virtualisation

Publié le mardi 21 mars 2006, mis a jour le samedi 16 décembre 2006, par Francis Hulin-Hubard

Cet introduction a pour but de détailler l’installation de quelques services dans des serveurs virtuels. Il s’inscrit en complément du Guide Gentoo de Linux-VServer disponible sur le site officiel Gentoo

Introduction

Linux Vserver est une solution de virtualisation de serveur que nous pouvons voir comme un "super chroot" dont nous pourrons contrôler toutes les interactions avec le système hôte.

Le but de cet article n’est pas de re-détailler la mise en œuvre de VServer, mais de vous accompagner rapidement dans la démarche de séparation des services sur votre serveur physique. Nous reverons dans un premier temps la préparation du système hôte puis, nous afinerons le modèle téléchargeable depuis les mirroirs Gentoo [1] afin de les adapter à nos besoins. Nous finirons cette introduction par quelques généralités permettant de conserver vos hôtes virtuels à jour.

Préparation de la machine hôte

La préparation de la machine hôte ne présente pas de difficulté particulière, elle se résume en un patch des sources du noyau, recompilation, et enfin installation des paquets nécessaires...

Vous trouverez le patch “patch-2.6.14.4-vs2.1.0.diff” (à l’heure ou j’écris ces lignes) depuis le site Linux-VServer - Linux-VServer [2] ou directement sur le site LINUX-VSERVER - THE 13TH FLOOR [3] (Entrer, puis Virtual Server, 2.6 Releases et Dev Release 2.1.0).

Le patch est prévu pour un kernel 2.6.14.4 donc nous pouvons télécharger les sources appropriées (depuis kernerl.org [4] les décompresser et naturellement les patcher :

$ su -

# cd /usr/src

# wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.4.tar.bz2

# tar xvf linux-2.6.14.4.tar.bz2 # (le "j" n'est plus obligatoire)

# rm linux && ln -s linux-2.6.14.4 linux && cd linux

# patch -p1 < /chemin/vers/patch-2.6.14.4-vs2.1.0.diff

# zcat /proc/config.gz > .config

# make menuconfig

Ajoutez le support de Vserver comme indiqué dans le Guide Gentoo de Linux-VServer [5]

Linux VServer --->

  [ ] Enable Legacy Kernel API

(Ne pas activer !)

  [ ] Disable Legacy Networking Kernel API

(Hautement recommandé.)

  [*] Enable Proc Security

  [*] Enable Hard CPU Limits

        Persistent Inode Context Tagging (UID24/GID24)  --->

  [ ] Tag NFSD User Auth and Files

  [ ] Compile Debugging Code

Puis compilez notre nouveau noyau :

# make -j2 && make modules_install

# cp arch/i386/boot/bzImage /boot/kernel-2.6.14.4-vs2.1.0

L’ajout de ce kernel dans votre grub.conf (ou lilo.conf) suivi d’un redémarrage terminera la partie kernel de cette configuration.

Afin d’utiliser la dernière version des utilitaires de VServeur, ajoutez le dans votre fichier package.keywords avant de "l’emerger"

# echo "sys-cluster/util-vserver ~x86" >> /etc/portage/package.keywords

# emerge util-vserver

Dans la dernière version de util-vserver, plus besoins de "vprocunhide", ajoutez donc simplement vshelper à votre fichier /etc/sysctl.conf afin d’assurer le bon démarrage de vos vservers, préparez le lancement au boot et démarrez Linux-VServer

# echo "kernel.vshelper = /usr/lib/util-vserver/vshelper" > /etc/sysctl.conf

# rc-update add vservers default

# /etc/init.d/vservers start

Pour le moment faisons simple et laissons les paramètres de /etc/vservers.conf aux valeurs initiales.

Notre système est maintenant près à accueillir nos serveurs virtualisé.

Création du modèle

Nous allons maintenant préparer un serveur virtuel type minimal qui sera la base de tous nos futurs serveurs virtualisé. Cet étape triviale commence par le téléchargement du modèle stage2 ou 3 disponible sur les mirroirs dans la partie expérimentale.

# cd

# wget ftp://mirror.ovh.net/gentoo-distfiles/experimental/x86/vserver/2005.1-r1/i686/stage3-i686-2005.1-r1.tar.bz2*

# md5sum --check stage3-i686-2005.1-r1.tar.bz2.md5

stage3-i686-2005.1-r1.tar.bz2 OK

NOTA : Nous pouvons préparer plusieurs machines hôtes (par exemple Un PIII 750 et Athlon xp 1800+) afin de déplacer, en cas de besoins, les serveurs virtuels d’une machine sur l’autre, dans ce cas, la stage2/3 i686, se préte parfaitement à ce jeux...

Créons à présent le premier serveur virtuel que nous nommerons “modèle” et lançons le :

# cd /vservers

# vserver-new --help

Usage: vserver-new <name> <globalopts> <target> [localopts]



  <name>        Name of the new vserver

  <globalopts>  See Global options below

  <target>      See Supported targets below

  [localopts]   Target specific options



Global options:

    --context <id>         Static context ID of <name> (required)

    --hostname <name>      Hostname of <name>

    --interface [<name-suffix>=][<device>:]<ip>[/<mask|prefixlen>]

                           Declare a new network-interface for <name> (this

                           option can be specified multiple times)

    --start                Start the new vserver

    --destroy              Destroy exisiting vserver installation

                            (Use this option if you have seperate

                            fs mounts for each vserver)



Supported targets:

    stage3    Build a new vserver using a stage3 tarball

    clone     Clone an already exisiting vserver

    template  Create a new vserver using a template tarball



Type vserver-new <target> --help for local options

# vserver-new modele --hostname modele --context 1250 --interface eth0:192.168.0.250/255.255.255.0  template ~/stage3-i686-2005.1-r1.tar.bz2

 * Building skeleton configuration ... [ OK ]

 * Unpacking stage3-i686-2005.1-r1.tar.bz2 to /vservers/modele ...

 * Cleaning /var/tmp ... [ OK ]

 * Cleaning /tmp ... [ OK ]

 * Cleaning /var/lib/init.d ... [ OK ]

 * 

 * Please remember to change required settings inside your vserver

 * (hostname, hosts, ip, etc)

 *

Cette commande aura pour effet de créer deux répertoires nommés “modele”, l’un dans “/vservers” l’autre dans “/etc/vservers”. Comme vous vous en doutez, le répertoire “/etc/vservers/modele” contient toutes les données relatives à la configuration de votre server virtuel alors que celui disponible dans “/vservers” contiendra son “corps”.

NOTA : En cas d’erreure du type “Cache-directory ’/var/cache/vservers’ does not exist or is invalid” un simple mkdir /var/cache/vservers aura vite fait de vous débloquer.

Comme noté dans la doc officielle, modifiez les données propres à votre nouvelle machine virtuelle.

# nano /vservsers/modele/etc/conf.d/hostname # et précisez son nom

# nano /vservsers/modele/etc/conf.d/domainname # je vous laisse deviner

# nano /vservsers/modele/etc/hosts

# nano /vservsers/modele/etc/resolv.conf

# echo "export PS1=\"VServer $PS1\"" >> vservsers/modele/etc/profile

Afin de simplifier l’administration de nos machines virtuelles, nous utiliserons pour chacunes d’elles l’arbre portage de la machine hôte de sorte que la mise à jour de l’arbre de l’ensemble des serveurs virtualisés et de leur hôte ne se résume qu’à la synchronisation de cette dernière. Cela va nous permettre également de voir comment monter une partie de l’hôte dans l’un de nos serveurs virtuel. Pour limiter au maximum le pouvoir de nos machines virtuelles, nous ne donnerons les droits qu’en lecture sur “/usr/portage” de l’hôte mais en lecture écriture sur “/usr/portage/disfiles”.

Comme toutes actions sur les serveurs virtuels, le montage des partitions hôtes dans notre environnement est très simple. Il consiste à modifier le fichier “/etc/vservers/modele/fstab” :

# ls /etc/vservers/modele

apps  cache  context  fstab  interfaces  name  run  uts  vdir

# nano /etc/vservers/modele/fstab

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

# shared portage tree

/usr/portage           /usr/portage           none bind,ro 0 0

/usr/portage/distfiles /usr/portage/distfiles none bind,rw 0 0

Nous pouvons désormais lancer le serveur virtuel “modele” et entrer dans le système virtualisé afin de commencer sa « customisation ».

# vserver modele start

# vserver-stat

CTX   PROC    VSZ    RSS  userTIME   sysTIME    UPTIME NAME

0       81 110.4M  49.4M  23h47m57   6h59m15  23d19h17 root server

1250     4   9.1M   4.6M   0m08s99   0m04s53   0m02s17 modele

# vserver modele enter

VServer # ls /usr/portage

app-accessibility ...

VServer # ping www.google.com

PING www.l.google.com (66.102.9.104) 56(84) bytes of data.

64 bytes from 66.102.9.104: icmp_seq=1 ttl=245 time=58.3 ms

64 bytes from 66.102.9.104: icmp_seq=2 ttl=244 time=66.8 ms



--- www.l.google.com ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1005ms

rtt min/avg/max/mdev = 58.372/62.612/66.853/4.247 ms

Nous avons désormais un serveur virtuel standard disposant d’un arbre portage aussi à jours que celui de votre hôte et accédant au web. Débutons maintenant la personalisation de notre système par la modification de la variable USE. Notre objectif étant d’obtenir un serveur minimal, commencer par un “-*” n’est pas ridicule. Nous ajoutons ensuite les seuls keywords que nous serons sûr d’utiliser dans “TOUS” nos serveur virtuels (comme perl par exemple).

VServer # nano /etc/make.conf

CFLAGS="-O2 -march=i686"

CHOST="i686-pc-linux-gnu"

CXXFLAGS="${CFLAGS}"



USE="-* perl"

VServer #

Le système résultant étant de faible taille, nous pouvons en profiter pour le passer en gcc 3.4.x en suivant le HOWTO de gentoo.org [6].

VServer # emerge -uav gcc

VServer # gcc-config i686-pc-linux-gnu-3.4.4

VServer # source /etc/profile

VServer # emerge --oneshot -av libtoolucune originalité, mais le lancement de notre se

VServer # emerge -uvaDN world # pose moins de problème lors du -e

VServer # emerge -eav system

VServer # emerge -eav world

VServer # emerge -aC =sys-devel/gcc-3.3*

VServer # emerge -uvaDN world

Notre "template" étant désormais terminé, nous pouvons créer l’archive qui sera la base de nos futurs machines virtuelles.

VServer # halt

# cd /vservers/modele

# tar cjpvf ~/stage3-gcc3.4.4-vserver.tar.bz2 ./

Afin de gagner un peu de place, nous supprimons la machine de base.

# vserver-new modele --context 1250 --destroy

 * Existing vserver installation will be destroyed!

 * Proceeding in 10 seconds ...

 * Removing existing installation ...

 *   /vservers/modele ... [ ok ]

 *   /etc/vservers/modele ... [ ok ]

 * Missing argument <target>

 * Type vserver-new --help for details

# ls /vservers

(rien)

# ls /etc/vservers/

(rien non plus)

Bien entendu, vous pouvez modifier plus profondément votre machine de base.

Virtualisation des services

Nous disposons maintenant de tous les éléments necessaires à la virtualisation de service sur notre système hôte. Pour ce faire nous installerons donc notre template sur notre serveur, le paramètrerons et installerons enfin les composant utiles.

Prenons l’exmple du légendaire serveur WEB “A patcher” (d’ou son nom Apache) avec l’option traditionnelle PHP5. Nous définirons donc sur notre réseau un server web nomé "webserver" dont l’ip sera “192.168.0.250”. Il résidera sur la passerelle "stargates" (192.168.0.1) qui héberge (pour le moment toutefois) un serveur DNS.

Le déployement du vserver ne pose aucun problème :

# cd /vservers

# vserver-new webserver --hostname webserver --context 1250 --interface eth0:192.168.0.250/255.255.255.0 template ~/stage3-gcc3.4.4-vserver.tar.bz2

 * Building skeleton configuration ... [ OK ]

 * Unpacking stage3-i686-2005.1-r1.tar.bz2 to /vservers/modele ...

 * Cleaning /var/tmp ... [ OK ]

 * Cleaning /tmp ... [ OK ]

 * Cleaning /var/lib/init.d ... [ OK ]

 * 

 * Please remember to change required settings inside your vserver

 * (hostname, hosts, ip, etc)

 * 

# nano /vservsers/webserver/etc/conf.d/hostname # et précisez son nom

# nano /vservsers/webserver/etc/hosts

# nano /etc/vservers/webserver/fstab

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

/usr/portage           /usr/portage           none bind,ro 0 0

/usr/portage/distfiles /usr/portage/distfiles none bind,rw 0 0

# vserver webserver start

# vserver webserver enter

A partir de là, aucune surprise, le serveur virtuel se comporte comme une machine gentoo standard.

VServer # nano /etc/make.conf

CFLAGS="-O2 -march=i686"

CHOST="i686-pc-linux-gnu"

CXXFLAGS="${CFLAGS}"



USE="-* perl apache2 php"

VServer # emerge -uavDN world

VServer # emerge apache2 php

etc...

Je vous laisse alors vous référer aux documentations en ligne sur l’installation d’apache et de PHP pour mettre au point votre serveur Web. Pensez toutefois à modifier l’adresse d’écoute d’apache (Listen 192.168.0.250:80 dans httpd.conf) afin de ne pas accéder au serveur Web depuis n’importe quel adresse... (entre autre l’adresses de “stargates” machine hôte).

Particularités

Parmis les services qu’il est intéressant de virtualiser, nous en trouvons certains nécessitant une interaction forte avec le système ou nécessitant un accés physique à l’hôte. Le point fort de la virtualisation est justement, par défaut, de couper toutes ces liaisons. Afin de passer ce barrage, il est possible d’augmenter le pouvoir d’une machine virtelle en lui ajoutant des “capabilities” qui sont des permissions spéciales définies au coup par coup pour chaque serveurs virtuel. C’est le cas par exemple du service bind qui par défaut necessite de fonctionner sous une identité différente de root et éventuellement d’accéder au “chrooting”.

La mise en place d’un serveur de nom commence traditionnelement par le déploiment d’un nouveau vserver, sa configuration, et l’installation du service lui correspondant. Je vous laisse vous référer à apache ci dessus pour plus de détail.

# cd /vservers

# vserver-new ns --hostname ns --context 1251 --interface eth0:192.168.0.251/255.255.255.0 template ~/stage3-gcc3.4.4-vserver.tar.bz2

[...]

# vserver ns enter

VServer # emerge bind

[...]

La configuration de bind n’est qu’une simple formalité en jettant un coup d’œil au WIKI [7] Gentoo par exemple.

Jusqu’ici, aucune originalité, mais le lancement de notre service échoue.

VServer # /etc/init.d/named start

 * Starting chrooted named ...

named: capset failed: Operation not permitted: please ensure that the capset kernel module is loaded.  see insmod(8)                                      [ !! ]

Après avoir étudié la FAQ du site VServer, nous obtenons la réponse à cet erreur "The bind package expect to have the capability CAP_SYS_RESOURCE". L’ajout d’une tel capabilité ce fait dans le fichier "/etc/vservers/NomServer/bcapabilities" :

# cat > /etc/vservers/ns/bcapabilities

SYS_RESOURCE

^d

# vserver ns restart

# vserver ns enter

VServer # /etc/init.d/named start

VServer #

Vous pouvez maintenant adapter votre configuration de named comme sur une machine physique normale.

NOTA : Si vous souhaitez utiliser le chrooting, pensez à ajouter également les capacités NET_BIND_SERVICE, SYS_ADMIN.

Pour aller plus loin

Qu’est Linux exactement ? c’est avant tout un noyau sur lequel on greffe des "éléments"...

Cette vision semble basique, mais ouvre une quantité de portes phénoménales. Pour plus de précisions sur votre système, je vous renvois vers l’article "Qu’est-ce que Gentoo ?" de Maxime BRUNEL. Grace à linux VServer, nous disposons d’un noyau, celui du système hôte, sur lequel nous pouvons connecter autant de systèmes que nécessaire. Jusqu’à présent, nous avons logiquement connecté à notre noyau Gentoo des systèmes Gentoo, mais cela n’a rien d’obligatoire... Ainsi, il est possible de déployer un VServer Fedora, Mandriva ou debian dans notre Gentoo de la même façon que précédement...