Wikilivres

« Linux-VServer » : différence entre les versions

Navigation interactive dans l’historique
← Modification précédenteModification suivante →
Contenu supprimé Contenu ajouté
VisuelWikicode
Od1n (discussion | contributions)
8 modifications
m a déplacé Linux VServer vers Linux-VServer : typo "officielle" du nom de l'application
Aucun résumé des modifications
Ligne 1 :
{{fusionner|Linux Vserver|Linux-VServer}}
{{fractionner}}
Bonjour !<br />
Je vous propose dans cet article d'étudier la solution de virtualisation Linux VServer, tant en terme de théorie que de pratique ! N'hésitez pas à me corriger si je me trompe ou à me compléter, puisque ceci ne saurait être un contenu exhaustif --de part le fait même que le projet VServer est encore en cours de réalisation.<br /><P>
 
Cet article se jouera en 2 temps principaux : Concepts et Mise en œuvre.<br />
= Couverture =
Il passera notamment par les points suivants : <br />
- Introduction<br />
- Concepts<br />
- Linux Vserver <br />
- Introduction<br />
- Fonctionnement<br />
- Particularité<br />
- Sécurité<br />
- Limitation<br />
- Mise en oeuvre<br />
- Préparation du noyau<br />
- Création d'un Vserver<br />
- Paramétrage d'un Vserver<br />
- Conclusion<br />
- Bibliographie<br /><br />
 
Here we go !!! :3 <br /><br />
== Introduction ==
 
<P>
Ce document a pour objectif d'étudier tous les aspects de la solution Linux Vserver, de sa description à sa mise en oeuvre, en passant par la comparaison avec d'autres outils de virtualisation comme Xen, UML ou encore QEMU.
 
Dans un premier temps, nous nous contenterons de décrire les concepts de serveur virtuel, et les techniques mises en oeuvre pour gérer ce type d'instance. Ensuite, nous nous attacherons aux caractéristiques propres à la solution Linux Vserver de manière générale, puis nous passerons à la partie pratique, en créant « from scratch » une machine capable de faire tourner plusieurs Vserver de manière totalement sécurisée.(application à Debian Sarge 2.6.14-vs2.0)
 
'''Linux Vserver'''<br /><br />
__TOC__
'''Application à Debian Sarge 2.6.14-vs2.0'''<br /><br />
'''Introduction'''<br /><br />
 
Ce document a pour objectif d'étudier tous les aspects de la solution Linux Vserver, de sa description à sa mise en oeuvre, en passant par la comparaison avec d'autres outils de virtualisation comme Xen, UML ou encore QEMU. <br />
= Concepts et techniques de virtualisation =
Dans un premier temps, je me contenterais de décrire les concepts de serveur virtuel, et les techniques mises en oeuvre pour gérer ce type d'instance. Ensuite, je m'attacherais aux caractéristiques propres à la solution Linux Vserver de manière générale, puis je passerais à la partie pratique, en créant « from scratch » une machine capable de faire tourner plusieurs Vserver de manière totalement sécurisée.<br /><P>
 
== Concepts ==
 
'''Concepts'''
<br />
« Serveur virtuel : serveur n'existant pas vraiment, étant hébergé par un autre serveur. Techniquement, il n'y a qu'une seule machine, mais de l'extérieur, on en voit plusieurs. Cela permet d'économiser sur le matériel, car un site web moyen, par exemple, est bien loin de consommer toutes les ressources d'un ordinateur personnel actuel. » <br />
(http://www.linux-france.org/prj/jargonf/S/serveur_virtuel.html)<br />
Ligne 22 ⟶ 41 :
Comment faire en sorte qu'un hôte ait la capacité de faire tourner plusieurs serveurs virtuels ? Comme dit précédemment, il existe des techniques permettant d'émuler un serveur virtuel. Ce sont les techniques de virtualisation.<br /><P>
 
== '''Techniques de virtualisation'''<br ==/>
D'elles dépendent en grande partie les performances des serveurs virtuel, elles constituent aussi les principales différences entre les solutions existantes sur le marché et qui permettent de gérer des serveurs virtuels.<br />
La virtualisation peut intervenir sur différents niveaux, et c'est là toute la différence avec d'autres systèmes de virtualisation tels que Xen, UML ou OPENVZ.<br />
<P>
 
; Niveau Emulateur : La virtualisation peut être faite via un émulateur, c'est à dire une application qui simule un processeur ou une machine complète. L'émulateur s'occupe entre autre de la traduction dynamique et complète du code. L'émulateur QEMU par exemple, est capable d'utiliser un «accélérateur». Avec cet accélérateur, l'émulation peut tourner à une vitesse respectable (50% d'une vitesse native en théorie). PearPC est lui un émulateur PowerPC, capable de faire fonctionner Mac OS X. Cependant, il reste lent, en effet, une émulation émule la totalité d'une machine, y compris ses composants internes et le processeur. Les émulations sont ainsi généralement lentes (en prenant des machines hôtes et cibles de même génération) ; leur intérêt est essentiellement pour mener des tests.
 
'''Linux Vserver'''<P>
; Niveau Machine : La virtualisation de machine, elle, fonctionne sur le même type de matériel. Il n'y a plus de ce fait d'étape d'émulation de processeur, ce qui permet d'obtenir des performances proches, sinon celles de la machine originale dans les phases de calcul. Néanmoins, un certain nombre de composants ou pilotes de matériel sont virtualisés, dégradant généralement les entrées/sorties, parfois de façon très significative. Cette technologie existe depuis fort longtemps sur de nombreuses architectures. IBM avait déjà introduit ces concepts au milieu des années 1960 et existe toujours dans leurs systèmes actuels (AIX 5L 5.2, OS400). Cette technologie est par contre récente sur les PC, car l'architecture IA-32 n'a pas été prévue pour cela. Des astuces techniques ont dû être trouvées.
 
'''Introduction'''<br />
; Niveau Application : Elle peut avoir lieu au niveau application, l'application fait alors croire qu'il y a plusieurs services (Hôtes virtuels Apache, domaines virtuels Postfix...). Les performances sont en générale excellentes, du fait que l'application fonctionne tout à fait en tant que telle, il n'y a aucune traduction de code, et aucune virtualisation des composants.
 
; Niveau Kernel :
 
Il s'agit d'un partitionnement logique, ou serveur virtuel. Dans ce cas, il n'y a plus aucune émulation. C'est le noyau du système d'exploitation qui fait une isolation entre des machines logiques, tout comme il isole déjà les processus entre eux. Des exemples existent au moins sur FreeBSD (jails) et Solaris 10 (zones). Sous Linux, le projet Linux-vserver représente cette catégorie.
 
= Linux Vserver =
 
== Introduction ==
 
Cette technologie open source est assez récente sous Linux. La version 0.0 date d'octobre 2001. Jacques Gélinas, canadien à l'origine de plusieurs projets bien connus sous Linux (linuxconf, umsdos) a démarré le projet. Cette solution est spécifique à Linux, mais non liée à la plateforme IA-32. Le développement des versions s'est ralenti fin 2002. De nombreuses modifications ont alors fait leur apparition, et le projet s'est transformé en un projet communautaire. Le leader de ce projet est devenu Herbert Poetzl à partir d'octobre 2003. Depuis ce moment de nombreuses évolutions ont vu le jour. La version 1.0 est sortie le 1er novembre 2003, suivie de la version 1.2 le 5 décembre 2003. Cette branche est toujours active pour le noyau Linux 2.4 (version 1.2.10 pour noyau 2.4.29). La version 2.0 est sortie le 7 août 2005 pour le noyau 2.6.12. Cette version apporte de nombreux perfectionnements.
<P>
 
== '''Fonctionnement'''<br ==/>
 
Il s'agit d'une modification du noyau Linux (sous la forme d'un patch, le code n'étant pas actuellement intégré dans le noyau officiel). Ce patch est accompagné d'utilitaires pour configurer le système. Debian intègre depuis la version Sarge les utilitaires de gestion des vservers. L'intégration est donc assez simple. Concrètement, un vserver fonctionne par un système de contexte supplémentaire ajouté à chaque processus. C'est un système de virtualisation léger et peu intrusif.
<br />
 
La machine physique démarre le noyau Linux. Tous les processus lancés par ce noyau (à partir d'init) le sont avec un contexte 0, celui dédié à la machine hôte. Jusque là, tout se comporte strictement comme d'habitude.
<br /><br />
 
 
Le lancement d'un vserver se fait via la commande vserver nom_du_vserver start . Cette commande va lire un fichier de configuration correspondant au serveur virtuel à démarrer. Elle crée un contexte (un numéro dit xid), qui est unique à la machine physique. Ensuite, le processus change de racine (chroot). Les adresses IPv4 du vserver sont créées en tant qu'adresses secondaires de l'interface réseau de la machine physique, puis liées au contexte actuel par des règles de routage internes au noyau Linux. Ensuite la commande vserver se remplace par un processus unique (le programme init , qui est le processus standard de démarrage des UNIX). Ainsi démarre le serveur virtuel.
 
<br /><br />Tous les processus ensuite démarrés par init sont dans le même contexte, et héritent de ses caractéristiques. Le contexte s'applique donc aux processus et aux adresses IP, qui sont ainsi isolés de tout ce qui n'appartient pas au contexte local. Ce sont les seuls éléments virtualisés. Il n'y a pas de virtualisation des couches réseaux ou de stockage. Le vserver se base sur la gestion de “capabilities” du noyau Linux, qui permet de descendre les privilèges d'une tâche (et des tâches héritées), et de limiter les appels systèmes possibles. Et ainsi sécuriser l'ensemble.
 
À<br /><br />A l'intérieur d'un vserver, il est par exemple impossible de manipuler les adresses IP de l'interface, de manipuler iptables , ou encore d'utiliser mknod. Comme un vserver hérite d'une tâche unique, il est possible au lancement du serveur virtuel, de le limiter en nombre de processus, de lui donner une priorité (nice)... Cela est implémenté en interne via la commande ulimit. Il est facile de voir l'état des serveurs sur la machine hôte via la commande vserver-stat
 
La version 2.0 des vservers (disponible sur noyau 2.6 uniquement) permet de limiter plus nettement les ressources entre vservers au niveau du noyau, par exemple l'utilisation processeur (système de seau à jeton).
 
<br />La version 2.0 des vservers (disponible sur noyau 2.6 uniquement) permet de limiter plus nettement les ressources entre vservers au niveau du noyau, par exemple l'utilisation processeur (système de seau à jeton).
<br /><br />
Le pseudo système de fichiers /proc est monté dans les vservers mais masque toute les entrées hors contexte, évitant ainsi des problèmes de sécurité possibles.
<br /><br />
 
Le pseudo système de fichiers /sys n'est par contre pas monté. Il n'est disponible que sur le serveur hôte. La principale limite est qu'il est impossible d'héberger un système autre que Linux puisque le noyau est partagé entre serveur hôte et ses vservers.
<br /><br />
 
Les processus d'un vserver ne sont que des processus standards, juste isolés et bridés sur les appels systèmes qu'ils peuvent utiliser. Les disques ainsi que la mémoire sont également partagés, ce qui permet une forte montée en charge, mais peut aussi compromettre la stabilité de l'intégralité du système, si on n'y prend garde.
<br /><br />
 
La racine d'un vserver se trouve dans un sous-répertoire du serveur maître
/var/lib/vservers/nom_du_vserver.
<br /><br />
 
Pour éviter tout débordement et tout effet de bord, il est souhaitable d'utiliser une partition dédiée pour chaque vserver (voire plusieurs). De cette façon, un vserver ne peut saturer le disque du serveur hôte.
<br /><br />
 
La création de nouveaux vservers peut se faire via une commande vserver build , qui est capable de gérer un certain nombre de distributions, dont DEBIAN (utilisation de la commande deboostrap pour installer un système de base DEBIAN). Quelques corrections sont ensuite apportées au serveur fraîchement installé (essentiellement un /dev quasiment vide), afin de fonctionner au mieux dans un vserver.
<br /><br />
 
Une fois cette commande terminée, un vserver de base est installé. Il peut être sauvegardé pour ensuite servir de patron (sous la forme d'un fichier tar.gz, qu'il suffit de décompresser ensuite, au besoin). Cela permet des déploiements « minute ».
<br /><br />
 
Pour information, un serveur Debian Sarge de base « pèse » environ 180 Mo. Puisque l'objectif est de n'avoir qu'un seul service par serveur virtuel, de très nombreux vservers ne nécessitent réellement jamais plus de 1 à 2 Go de disque. Il est possible d'utiliser des distributions Linux différentes, serveur hôte DEBIAN et vserver Fedora, par exemple. En effet, les librairies ne sont pas partagées, chaque vserver aura son propre jeu de librairies.
<P>
 
== '''Particularité =='''
<br /><br />
 
C'est la performance qui rend les vservers si attractifs. Puisqu'il ne s'agit pas d'un PC virtuel, mais plutôt de "serveurs Linux" virtuels. Cela peut simplement être vu comme un chroot amélioré. Les avantages sont des performances natives (pas de perte mesurable). A part la gestion du contexte, un processus dans un vserver a les mêmes caractéristiques qu'un processus d'une machine Linux standard. La consommation mémoire est légère (la mémoire est mutualisée entre le serveur hôte et les vservers et la mémoire demandée à l'hôte est celle réellement utilisée par les processus du vserver). La possibilité de mutualisation est donc ici très importante ; il est possible de déployer plusieurs dizaines de vservers sur un serveur actuel correctement taillé.
<P>
 
== '''Sécurité =='''
<br /><br />
 
De part les restrictions des appels systèmes que peut utiliser un vserver, un processus en son sein a moins de possibilités que celui d'un serveur standard. S'il y a intrusion dans un vserver, par une faille de sécurité d'un logiciel quelconque, le pirate ne pourra pas écouter les interfaces réseau, ou lancer des commandes comme nmap.
<br />
 
Seul l'hôte à la possibilité de manipuler iptables. Les règles sont très restrictives, et correspondent strictement aux services déployés sur le vserver. Ceux-ci ne peuvent initier des connexions, hors celles nécessaires pour assurer le service. Ainsi un pirate, même root sur un vserver, restera enfermé car il ne pourra pas lancer de connexions vers l'extérieur.
<br />Un démon ssh installé sur un port non standard verra ses paquets refusés par le firewall de l'hôte. Il n'est pas possible d'accéder aux disques physiques de la machine (il est par contre possible d'effacer le volume du serveur virtuel).
 
<br /><br />
Un démon ssh installé sur un port non standard verra ses paquets refusés par le firewall de l'hôte. Il n'est pas possible d'accéder aux disques physiques de la machine (il est par contre possible d'effacer le volume du serveur virtuel).
 
Un risque est constitué par l'escalade de privilège d'un vserver vers le serveur hôte. En effet, les vservers sont basés sur une couche de virtualisation logique assez fine. Par le passé, elle a été contournée une fois. Cet unique bug a été rapidement corrigé (chroot barrier), mais prouve que le concept n'est pas à l'épreuve des balles. Si l'escalade arrive jusqu'à l'hôte, en tant que root, (ou si l'hôte fait tourner des services exploitables), alors la sécurité est mise à mal, puisque le serveur hôte a une vision complète de tous les fichiers des vservers, et peut accéder à chacun des processus de ceux-ci, ainsi que de s'y logguer en tant que root... Il ne s'agit plus cette fois d'un seul serveur piraté, mais de la totalité des vservers hébergés sur cet hôte. Il n'y a cependant actuellement pas de faille de ce type connue.
<br /><br />
 
Enfin, un seul noyau est partagé entre l'hôte et les vservers. Si un bug noyau existe, il peut être utilisé dans ou via un vserver, et provoquer un déni de service pour la machine hôte – et par ricochet – celui des autre vservers hébergés. Cela amène à un autre risque, qui est celui de la panne matérielle ; si la machine est en panne, ce sont tous ses vservers qui le sont. Déployer un vserver est dangereux si des services redondants ne sont pas prévus.
<br />
 
Les précautions conseillées sont les suivantes : Tous les service importants déployés sur des vservers sont redondés. Les vservers co-hébergés sur une même machine hôte sont, autant que possible, avec des catégories d'usage et des contraintes de sécurité proches. Et bien sur, la règle primordiale est de ne faire tourner AUCUN service sur l'hôte à part SSH et les iptables.
<P>
 
== '''Limitations =='''
<br /><br />
 
Chaque médaille a son revers... Vserver a l'inconvénient de ses avantages, c'est à dire sa légèreté. Dans un grand nombre de cas, son fonctionnement est tout à fait satisfaisant. Cependant, le noyau est partagé par toutes les instances de serveurs, et tous les drivers et couches de communication ne sont pas virtualisés ; les conséquences sont multiples :
<br /><br />
 
Certains programmes nécessitant des privilèges élevés, ou manipulant directement le matériel ne pourront fonctionner correctement. Par exemple, le déploiement d'un serveur NFS kernel ne peut se faire qu'au niveau de l'hôte principal. Pas plus que démarrer un serveur X window n'est possible simplement... Dans un hôte il est possible de démarrer un démon NFS en privilège utilisateur5, mais les performances sont moins bonnes.
<br /><br />
 
La mutualisation de la couche réseau peut aussi entraîner des problèmes de routage complexes (un cas est exposé en annexe) et empêche IPv6 de fonctionner.
<br /><br />
 
Dans les déploiements envisagés, certaines de ces limitations sont gênantes. Il a donc été considéré que pour certaines applications, un système de virtualisation plus complet devait être déployé.
 
<P>
 
== '''Mise en Oeuvre =='''
<P>
 
=== '''Introduction ==='''
<br /><br />
 
Pour mettre en place la solution Linux Vserver, il nous faut d'abord rendre une machine hôte capable de faire tourner plusieurs vservers. Nous allons donc détailler la préparation de l'hôte, de la mise en place du patch au status opérationnel de la machine.
<P>
=== '''Préparation du noyau ==='''
<br /><br />
 
On commence par la préparation du kernel. Nous travaillons avec une Debian Sarge.<br />
Première étape : updater la apt database avant l'installation et upgrader les packages installés.
<br />
> apt-get update && apt-get upgrade <br />
<br />
Seconde étape, il nous faut plusieurs outils, qui sont les suivants : <br />
 
# util-vserver, pour gérer les vservers <br />
> apt-get update && apt-get upgrade
# ssh <br />
# ncurses-base et libncurses5-dev, pour pouvoir faire un « make menuconfig » lors de la compilation du noyau.<br />
 
> apt-get install util-vserver ssh ncurses-base libncurses5-dev <br />
Seconde étape, il nous faut plusieurs outils, qui sont les suivants :
<br />
On se retrouve avec les fichiers suivants : <br />
/var/lib/vservers, qui est le répertoire principal pour les fichiers des vservers <br />
/etc/vservers, qui est le répertoire par défaut des fichiers des vservers<br />
/etc/vservers.conf, le fichier de configuration basique de l'outil util-vserver<br />
/usr/sbin/vserver, l'executable pour interagir, démarrer, stopper, construire, ..., entrer dans un vserver <br />
 
/bin/vshelper, un descripteur des fonctions de l'outil<br />
* util-vserver, pour gérer les vservers
/usr/lib/util-vserver, les scripts, fonctions principales.<br />
* ssh
<P>
* ncurses-base et libncurses5-dev, pour pouvoir faire un « make menuconfig » lors de la compilation du noyau.
'''Le kernel'''
 
<br /><br />
> apt-get install util-vserver ssh ncurses-base libncurses5-dev
Nous allons maintenant nous attaquer à la partie noyau.<br />
 
Tout d'abord rapatrier le dernier noyau Debian stable compatible vserver (2.6.12.4) via la commande suivante : <br /><br />
On se retrouve avec les fichiers suivants :
* /var/lib/vservers, qui est le répertoire principal pour les fichiers des vservers
* /etc/vservers, qui est le répertoire par défaut des fichiers des vservers
* /etc/vservers.conf, le fichier de configuration basique de l'outil util-vserver
* /usr/sbin/vserver, l'executable pour interagir, démarrer, stopper, construire, ..., entrer dans un vserver
* /bin/vshelper, un descripteur des fonctions de l'outil
* /usr/lib/util-vserver, les scripts, fonctions principales.
 
=== Le noyau (kernel) ===
 
Nous allons maintenant nous attaquer à la partie noyau. Tout d'abord rapatrier le dernier noyau Debian stable compatible vserver (2.6.12.4) via la commande suivante :
 
> cd /usr/src
> wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.4.tar.gz
 
> cd /usr/src<br />
> wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.4.tar.gz <br />
<br /><br />
Ensuite, le dernier patch stable de http://linux-vserver.org ou de www.13thfloor.at<br />
<br />
> wget http://www.13thfloor.at/vserver/s_rel26/v2.0/patch-2.6.12.4-vs2.0.diff.gz<br />
> gzip -d linux-2.6.12.4.tar.gz <br />
> tar -zxvf linux-2.6.12.4.tar<br />
> gzip -d patch-2.6.12.4-vs2.0.diff.gz<br />
> mv patch-2.6.12.4-vs2.0.diff /usr/src/linux-2.6.12.4<br />
<P>
 
'''Patcher le noyau'''
> wget http://www.13thfloor.at/vserver/s_rel26/v2.0/patch-2.6.12.4-vs2.0.diff.gz<br />
<br /><br />
> gzip -d linux-2.6.12.4.tar.gz <br />
> tar -xvfcd /usr/src/linux-2.6.12.4.tar<br />
> gzip -dcat patch-2.6.12.4-vs2.0.diff.gz | patch -p1 <br />
<br /><br />
> mv patch-2.6.12.4-vs2.0.diff /usr/src/linux-2.6.12.4<br />
Si vous êtes déjà sous une version similaire du noyau (2.6.x), il est préférable de copier la configuration actuelle avant de compiler le noyau. Votre configuration devrait se trouver vers "/boot/config-2.6.x" <br /><br />
 
> cp /boot/config-2.6.X /usr/src/linux-2.6.12.4/.config <br />
 
C'est parti. Vous devez d'abord inclure quelques choses pendant la compilation. Première chose, vous devez être en mesure de compiler sous votre système... Je conseille http://www.howtoforge.com/forums/showthread.php?t=21 si vous n'êtes pas très à l'aise avec cette histoire de compilation.<br /><br />
==== Patcher le noyau ====
 
> make menuconfig <br />
> cd /usr/src/linux-2.6.12.4
Vous pouvez voir une catégorie pour «Linux VServer ». Si elles ne sont pas sélectionnées, activez<br />
> cat patch-2.6.12.4-vs2.0.diff | patch -p1
Enable Legacy kernel API<br />
 
Enable Proc Security<br />
Si vous êtes déjà sous une version similaire du noyau (2.6.x), il est préférable de copier la configuration actuelle avant de compiler le noyau. Votre configuration devrait se trouver vers "/boot/config-2.6.x"
Enable Hard CPU Limits <br />
 
> cp /boot/config-2.6.X /usr/src/linux-2.6.12.4/.config
 
C'est parti. Vous devez d'abord inclure quelques choses pendant la compilation. Première chose, vous devez être en mesure de compiler sous votre système... Je conseille http://www.howtoforge.com/forums/showthread.php?t=21 si vous n'êtes pas très à l'aise avec cette histoire de compilation.
 
> make menuconfig
 
Vous pouvez voir une catégorie pour «Linux VServer ». Si elles ne sont pas sélectionnées, activez
* Enable Legacy kernel API
* Enable Proc Security
* Enable Hard CPU Limits
 
La configuration est prête. Il ne reste plus qu'à compiler le kernel :
 
> make
> make modules_install
> cp .config /boot/config-2.6.12.4-vs2.0
> cp System.map /boot/System.map-2.6.12.4-vs2.0
> cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.12.4-vs2.0
> mkinitrd -o /boot/initrd.img-2.6.12.4-vs2.0 2.6.12.4-vs2.0
 
La configuration est prête. Il ne reste plus qu'à compiler le kernel.<br />
> make<br />
> make modules_install<br />
> cp .config /boot/config-2.6.12.4-vs2.0<br />
> cp System.map /boot/System.map-2.6.12.4-vs2.0<br />
> cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.12.4-vs2.0<br />
> mkinitrd -o /boot/initrd.img-2.6.12.4-vs2.0 2.6.12.4-vs2.0 <br />
<br /><br />
Il faut mettre à jour le menu grub. Editez (pico, nano, vi...) le fichier /boot/grub/menu.lst et ajoutez les lignes suivantes avant les autres entrées. Assurez vous que la ligne "default" est mise à 0
<P>
 
title Vanilla 2.6.12.4-vs2.0<br />
root (hd0,0)<br />
kernel /vmlinuz-2.6.12.4-vs2.0 root=/dev/hda2 ro<br />
initrd /initrd.img-2.6.12.4-vs2.0<br />
savedefault<br />
boot <br />
<P>
 
''Note'' : Sous debian update-grub fait tout le boulot de modification du fichier /boot/grub/menu.lst automatiquement à partir du moment où le noyau est present dans /boot
 
L'hôte est prêt. Il ne reste plus qu'à rebooter pour avoir notre noyau prêt pour supporter vserver.<br />
> reboot <br />
> uname -r<br />
2.6.12.4-vs2.0 <br />
C'est le bon kernel !
<P>
'''Créer un Virtual Server'''<br /><br />
 
La création d'un server virtuel Debian sur un hôte Debian est simple. Voici la syntaxe de la comande :<br />
C'est le bon kernel !
<br />
> vserver <VSERVER_NAME> build <br />
-n <VSERVER_NAME> <br />
--hostname <FQDN> <br />
--interface <NET_DEVICE>:<IP>/<CIDR> <br />
-m debootstrap -- -d <DEBIAN_DISTRO> <br />
 
=== Créer un Virtual Server ===
 
Ici, notre vserver a les informations suivantes : <br />
La création d'un server virtuel Debian sur un hôte Debian est simple. Voici la syntaxe de la commande :
VSERVER_NAME viu <br />
FQDN viu.bux.com <br />
NET_DEVICE eth0 <br />
IP 192.168.1.50 <br />
CIDR 24 (255.255.255.0) <br />
DEBIAN_DISTRO sarge<br />
 
On aura donc : <br />
> vserver <VSERVER_NAME> build
> vserver viu build <br />
-n <VSERVER_NAME>
--hostnamen viu <FQDNbr />
--hostname viu.bux.com <br />
--interface <NET_DEVICE>:<IP>/<CIDR>
--interface eth0:192.168.1.50/24 <br />
-m debootstrap -- -d <DEBIAN_DISTRO>
-m debootstrap -- -d sarge <br />
 
On obtient <br />
Ici, notre vserver a les informations suivantes :
VSERVER_NAME viu
FQDN viu.bux.com
NET_DEVICE eth0
IP 192.168.1.50
CIDR 24 (255.255.255.0)
DEBIAN_DISTRO sarge
 
> ls -lah /var/lib/vservers/viu<br />
On aura donc :
total 80K<br />
> vserver viu build
drwxr-xr-x 20 root root 4.0K Nov 10 08:17 .<br />
-n viu
drwxr-xr-x 4 root root 4.0K Nov 10 08:13 ..<br />
--hostname viu.bux.com
drwxr-xr-x 2 root root 4.0K Nov 10 08:17 bin<br />
--interface eth0:192.168.1.50/24
drwxr-xr-x 2 root root 4.0K Dec 15 2004 boot<br />
-m debootstrap -- -d sarge
drwxr-xr-x 3 root root 4.0K Nov 10 08:13 dev<br />
drwxr-xr-x 37 root root 4.0K Nov 10 08:17 etc<br />
drwxrwsr-x 2 root staff 4.0K Dec 15 2004 home<br />
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 initrd<br />
drwxr-xr-x 7 root root 4.0K Nov 10 08:17 lib<br />
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 media<br />
drwxr-xr-x 2 root root 4.0K Dec 15 2004 mnt<br />
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 opt<br />
drwxr-xr-x 2 root root 4.0K Dec 15 2004 proc<br />
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 root<br />
drwxr-xr-x 2 root root 4.0K Nov 10 08:17 sbin<br />
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 srv<br />
drwxr-xr-x 2 root root 4.0K May 10 2005 sys<br />
drwxrwxrwt 2 root root 4.0K Nov 10 08:17 tmp<br />
drwxr-xr-x 11 root root 4.0K Nov 10 08:16 usr<br />
drwxr-xr-x 13 root root 4.0K Nov 10 08:16 var<br />
 
> ls -lah /etc/vservers/viu<br />
On obtient
total 28K<br />
drwxr-xr-x 5 root root 4.0K Nov 10 08:13 .<br />
drwxr-xr-x 6 root root 4.0K Nov 10 08:13 ..<br />
drwxr-xr-x 4 root root 4.0K Nov 10 08:13 apps<br />
-rw-r--r-- 1 root root 112 Nov 10 08:13 fstab<br />
drwxr-xr-x 3 root root 4.0K Nov 10 08:13 interfaces<br />
-rw-r--r-- 1 root root 5 Nov 10 08:13 name<br />
lrwxrwxrwx 1 root root 22 Nov 10 08:13 run -> /var/run/vservers/viu<br />
drwxr-xr-x 2 root root 4.0K Nov 10 08:13 uts<br />
lrwxrwxrwx 1 root root 37 Nov 10 08:13 vdir -> /etc/vservers/.defaults/vdirbase/viu<br />
 
'''Tips''' : Notez que si vous ommettez la ligne –interface, tout n'est pas perdu, il suffit juste, ultérieurement, de rajouter à la main le répertoire /etc/vservers/viu/interfaces/ et d'y stocker <br /><br />
> ls -lah /var/lib/vservers/viu<br />
- le fichier ip qui contient l'adresse IP du vserver viu (ici 192.168.1.50), <br />
total 80K<br />
- le fichier dev qui contient le nom du périphérique réseau utilisé par le vserver viu (ici eth0) <br />
drwxr-xr-x 20 root root 4.0K Nov 10 08:17 .
- et le fichier prefix qui contient le masque de sous réseau (ici 24), et de restarter le vserver. <br />
drwxr-xr-x 4 root root 4.0K Nov 10 08:13 ..
<br /><br />
drwxr-xr-x 2 root root 4.0K Nov 10 08:17 bin
Si vous n'arrivez toujours pas à pinguer, mettez tout dans le sous répertoire /etc/vservers/viu/interfaces/0/. Selon la distribution, le répertoire .../0/ est le seul considéré ou complétement ignoré.<br /><br />
drwxr-xr-x 2 root root 4.0K Dec 15 2004 boot
drwxr-xr-x 3 root root 4.0K Nov 10 08:13 dev
drwxr-xr-x 37 root root 4.0K Nov 10 08:17 etc
drwxrwsr-x 2 root staff 4.0K Dec 15 2004 home
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 initrd
drwxr-xr-x 7 root root 4.0K Nov 10 08:17 lib
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 media
drwxr-xr-x 2 root root 4.0K Dec 15 2004 mnt
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 opt
drwxr-xr-x 2 root root 4.0K Dec 15 2004 proc
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 root
drwxr-xr-x 2 root root 4.0K Nov 10 08:17 sbin
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 srv
drwxr-xr-x 2 root root 4.0K May 10 2005 sys
drwxrwxrwt 2 root root 4.0K Nov 10 08:17 tmp
drwxr-xr-x 11 root root 4.0K Nov 10 08:16 usr
drwxr-xr-x 13 root root 4.0K Nov 10 08:16 var
 
Maintenant que notre vserver est crée, expérimentons un peu les commandes. La syntaxe pour la commande vserver est la suivante : <br />
<pre>
> vserver <VSERVER_NAME> [ start | stop | restart | enter ] <br />
> ls -lah /etc/vservers/viu
total 28K
drwxr-xr-x 5 root root 4.0K Nov 10 08:13 .
drwxr-xr-x 6 root root 4.0K Nov 10 08:13 ..
drwxr-xr-x 4 root root 4.0K Nov 10 08:13 apps
-rw-r--r-- 1 root root 112 Nov 10 08:13 fstab
drwxr-xr-x 3 root root 4.0K Nov 10 08:13 interfaces
-rw-r--r-- 1 root root 5 Nov 10 08:13 name
lrwxrwxrwx 1 root root 22 Nov 10 08:13 run -> /var/run/vservers/viu
drwxr-xr-x 2 root root 4.0K Nov 10 08:13 uts
lrwxrwxrwx 1 root root 37 Nov 10 08:13 vdir -> /etc/vservers/.defaults/vdirbase/viu
</pre>
 
Donc pour notre viu: <br />
'''Astuce''' : Notez que si vous ommettez la ligne –interface, tout n'est pas perdu, il suffit juste, ultérieurement, de rajouter à la main le répertoire /etc/vservers/viu/interfaces/ et d'y stocker
* le fichier ip qui contient l'adresse IP du vserver viu (ici 192.168.1.50)
* le fichier dev qui contient le nom du périphérique réseau utilisé par le vserver viu (ici eth0)
* et le fichier prefix qui contient le masque de sous réseau (ici 24), et de restarter le vserver.
 
> vserver viu start<br />
Si vous n'arrivez toujours pas à pinguer, mettez tout dans le sous répertoire /etc/vservers/viu/interfaces/0/. Selon la distribution, le répertoire .../0/ est le seul considéré ou complétement ignoré.
Starting system log daemon: syslogd.<br />
Starting kernel log daemon: klogd.<br />
Starting MTA: exim4.<br />
Starting internet superserver: inetd.<br />
Starting deferred execution scheduler: atd.<br />
Starting periodic command scheduler: cron.<br />
 
...> vserver-stat <br />
Maintenant que notre vserver est crée, expérimentons un peu les commandes. La syntaxe pour la commande vserver est la suivante :
 
CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME<br />
> vserver <VSERVER_NAME> [ start | stop | restart | enter ] <br />
0 35 73.4M 5.4K 0m05s21 0m02s33 1m13s00 root server<br />
 
49152 5 11M 967 0m00s00 0m00s00 0m30s52 viu<br />
Donc pour notre viu:
 
<pre>
> vserver viu start
Starting system log daemon: syslogd.
Starting kernel log daemon: klogd.
Starting MTA: exim4.
Starting internet superserver: inetd.
Starting deferred execution scheduler: atd.
Starting periodic command scheduler: cron.
</pre>
 
<pre>
> vserver-stat
 
CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME
0 35 73.4M 5.4K 0m05s21 0m02s33 1m13s00 root server
49152 5 11M 967 0m00s00 0m00s00 0m30s52 viu
</pre>
 
> vserver viu enter<br />
Ligne 295 ⟶ 297 :
On est dans le contexte de viu. Pour sortir de ce contexte et revenir à l'hôte, il faut juste taper "exit".
<P>
 
=== '''Paramétrage du Vserver ==='''
<br /><br />
Maintenant que nous avons notre vserver, il faut pouvoir le brider, c'est à dire limiter ses ressources, son espace disque, sa charge CPU ...<br />
Ligne 412 ⟶ 414 :
BCAP<br />
 
CAP_CHOWN Pouvoir changer la propriété des fichiers et du group<br />
<pre>
CAP_DAC_OVERRIDE <br />
CAP_CHOWN Pouvoir changer la propriété des fichiers et du group
CAP_DAC_READ_SEARCH <br />
CAP_DAC_OVERRIDE
CAP_FOWNER <br />
CAP_DAC_READ_SEARCH
CAP_FSETID <br />
CAP_FOWNER
CAP_KILL Envoie un signal à un processus avec un userID réel ou effectif différent<br />
CAP_FSETID
CAP_SETGID permet setgid(2), setgroups(2), et gids forgés sur socket credentials passing <br />
CAP_KILL Envoie un signal à un processus avec un userID réel ou effectif différent
CAP_SETGID CAP_SETUID permet setgid(2), setgroupsset*uid(2), etand gidsuids forgés sur socket credentials passing <br />
CAP_SETPCAP transfert/enlève n'importe quelle capacité de n'importe quel pid <br />
CAP_SETUID permet set*uid(2), and uids forgés sur socket credentials passing
CAP_LINUX_IMMUTABLE Permet la modification de S_IMMUTABLE et de S_APPEND en attribut de fichier<br />
CAP_SETPCAP transfert/enlève n'importe quelle capacité de n'importe quel pid
CAP_NET_BIND_SERVICE <br />
CAP_LINUX_IMMUTABLE Permet la modification de S_IMMUTABLE et de S_APPEND en attribut de fichier
CAP_NET_BROADCAST Permet le broadcast et l'écoute multicast <br />
CAP_NET_BIND_SERVICE
CAP_NET_ADMIN permet la configuration des interfaces, IP firewall, masquerading, accounting,
CAP_NET_BROADCAST Permet le broadcast et l'écoute multicast
socket debugging, routing tables, bind to any address, enter promiscuous mode,
CAP_NET_ADMIN permet la configuration des interfaces, IP firewall, masquerading, accounting,
socket debuggingmulticasting, routing... tables, bind to any address, enter promiscuous mode,<br />
multicasting, ...
CAP_NET_RAW permet l'usage de RAW et PACKET sockets
CAP_IPC_LOCK
CAP_IPC_OWNER
CAP_SYS_MODULE insert et enlève les modules du kernel
CAP_SYS_RAWIO
CAP_SYS_CHROOT Permet le chroot(2)
CAP_SYS_PTRACE permet ptrace() de n'importe quel processus
CAP_SYS_PACCT
CAP_SYS_ADMIN La liste serait trop longue, ça permet basiquement de faire tout le reste, qui
n'est pas mentionné dans les capabicités.
CAP_SYS_BOOT permet le reboot(2)
CAP_SYS_NICE Permet de soulever une priorité et de paramétrer une priorité sur d'autres
processus, modifiant le scheduling
 
CAP_NET_RAW permet l'usage de RAW et PACKET sockets <br />
CAP_SYS_RESOURCE Permet de dépasser les resource limits, quota, reserved space on fs, ...
CAP_IPC_LOCK <br />
(/etc/vservers/viu/rlimits/)
CAP_IPC_OWNER <br />
CAP_SYS_TIME
CAP_SYS_MODULE insert et enlève les modules du kernel <br />
CAP_SYS_TTY_CONFIG
CAP_SYS_RAWIO <br />
CAP_MKNOD permet d'utiliser les avantages de mknod(2)
CAP_SYS_CHROOT Permet le chroot(2) <br />
CAP_LEASE
CAP_SYS_PTRACE permet ptrace() de n'importe quel processus <br />
CAP_QUOTACTL
CAP_SYS_PACCT <br />
</pre>
 
CAP_SYS_ADMIN La liste serait trop longue, ça permet basiquement de faire tout le reste, qui <br />
n'est pas mentionné dans les capabicités. <br />
CAP_SYS_BOOT permet le reboot(2) <br />
CAP_SYS_NICE Permet de soulever une priorité et de paramétrer une priorité sur d'autres <br />
processus, modifiant le scheduling <br />
 
CAP_SYS_RESOURCE Permet de dépasser les resource limits, quota, reserved space on fs, ... <br />
(/etc/vservers/viu/rlimits/)<br />
CAP_SYS_TIME <br />
CAP_SYS_TTY_CONFIG <br />
CAP_MKNOD permet d'utiliser les avantages de mknod(2) <br />
CAP_LEASE <br />
CAP_QUOTACTL<br />
<P>
 
''''' /etc/vservers/viu/ccapabilities'''''
Ligne 472 ⟶ 475 :
 
Context Caps (vs2.0) <br />
Bit Mask Capability config Description <br />
<pre>
0 0x00000001 SET_UTSNAME utsname Permet de changer les utsnames <br />
Bit Mask Capability config Description
0 0x00000001 SET_UTSNAME utsname 1 0x00000002 SET_RLIMIT rlimit Permet de changer les utsnamesresource limits <br />
8 0x00000100 RAW_ICMP raw_icmp Permet l'ouverture de socket icmp <br />
1 0x00000002 SET_RLIMIT rlimit Permet de changer les resource limits
12 0x00001000 SYSLOG syslog permet l'utilisation de commandes syslog <br />
8 0x00000100 RAW_ICMP raw_icmp Permet l'ouverture de socket icmp
16 0x00010000 SECURE_MOUNT secure_mount Permet le secure mount (loop, ...) <br />
12 0x00001000 SYSLOG syslog permet l'utilisation de commandes syslog
1617 0x00020000 0x00010000 SECURE_MOUNT secure_mount SECURE_REMOUNT secure_remount Permet le secure mountremount (loop,<br ...)/>
18 0x00040000 BINARY_MOUNT binary_mount Permet les mounts de données binaires/réseau<br />
17 0x00020000 SECURE_REMOUNT secure_remount Permet le secure remount
20 0x00100000 QUOTA_CTL quota_ctl Permet quota ioctls dans le contexte du vserver<br />
18 0x00040000 BINARY_MOUNT binary_mount Permet les mounts de données binaires/réseau
20 0x00100000 QUOTA_CTL quota_ctl Permet quota ioctls dans le contexte du vserver
</pre>
 
<P>
Ligne 490 ⟶ 491 :
<br />
(la colonne de gauche définit pour chacune des limites l'option à mettre dans la commande de création de vserver dans le cas où l'on veut tout définir d'un coup. Malheureusement, cette commande ne met l'architecture rlimits correctement en place.)
<P>
 
Limit ProcFS config Unit Description <br />
<pre>
-t CPU cpu s Quantité de temps cpu en seconde <br />
Limit ProcFS config Unit Description
-f FSIZE fsize kb Taille des fichiers crées par le shell <br />
-t CPU cpu s Quantité de temps cpu en seconde
-f FSIZE fsized DATA data kb Taille desd'un fichierssegment créesde pardonnée led'un shellprocessus<br />
-d DATA data s STACK stack kb Taille d'un segment de donnéela d'unpile<br processus/>
-c CORE core kb Taille des fichiers crées par le noyau<br />
-s STACK stack kb Taille de la pile
-m RSS rss page resident set size <br />
-c CORE core kb Taille des fichiers crées par le noyau
-u NPROC nproc int nombre de processus <br />
-m RSS rss page resident set size
-n NOFILE nofile int nombre de file handles <br />
-u NPROC nproc int nombre de processus
-l MEMLOCK memlock page Pages lockées en mémoire<br />
-n NOFILE nofile int nombre de file handles
-v AS/VM as page Page de mémoire virtuelle<br />
-l MEMLOCK memlock page Pages lockées en mémoire
-? LOCKS locks int Verrous du système de fichier<br />
-v AS/VM as page Page de mémoire virtuelle
-? SIGPENDING int pending signals <br />
-? LOCKS locks int Verrous du système de fichier
-p MSGQUEUE MSGQ 512b message queue size <br />
-? SIGPENDING int pending signals
-? NICE int minimum nice level <br />
-p MSGQUEUE MSGQ 512b message queue size
-? RTPRIO int maximum realtime prio <br />
-? NICE int minimum nice level
VLimit <br />
-? RTPRIO int maximum realtime prio
-- NSOCK (16) SOCK int nombre de sockets <br />
VLimit
-- NSOCKOPENFD (1617) SOCK OFD int nombre de file nombre dedescriptors sockets<br />
-- ANON (18) ANON page anonymous memory pages <br />
-- OPENFD (17) OFD int nombre de file descriptors
-- ANONSHMEM (1819) ANON SHM page anonymousshared memory pages <br />
-- SHMEM (19) SHM page shared memory pages
</pre>
 
<br />
Ligne 595 ⟶ 596 :
 
<br /><br /><P>
'''''Conclusion'''''
<br /><br />
La mise en oeuvre de la solution Linux Vserver est assez facile, intuitive, et ne demande pas trop de ressources, ce qui en fait une solution tout à fait convenable. Cependant, il existe plusieurs points noirs à ce projet : <br /><br />
 
- une documentation officielle pas toujours facile à comprendre (il faut lire les log IRC pour trouver une aide quelconque), et ce, malgré le fourmillement d'étude et de patch crées pour prolonger l'outil,<br /><br />
= Conclusion =
 
- des aspects pas encore implémentés (les CCAPS par exemple : le fichier est pris en compte par l'hôte, mais il ne reconnaît aucun des ccaps qui y sont)<br /><br />
La mise en oeuvre de la solution Linux Vserver est assez facile, intuitive, et ne demande pas trop de ressources, ce qui en fait une solution tout à fait convenable. Cependant, il existe plusieurs points noirs à ce projet :
* une documentation officielle pas toujours facile à comprendre (il faut lire les log IRC pour trouver une aide quelconque), et ce, malgré le fourmillement d'étude et de patch crées pour prolonger l'outil,
* des aspects pas encore implémentés (les CCAPS par exemple : le fichier est pris en compte par l'hôte, mais il ne reconnaît aucun des ccaps qui y sont)
* une solution qui passe par le patchage/recompilation du noyau (on pourrait envisager de l'intégrer directement dans un noyau)
 
- une solution qui passe par le patchage/recompilation du noyau (on pourrait envisager de l'intégrer directement dans un noyau)<br /><br />
 
<br /><br /><br /><br />
Si l'on devait comparer Linux Vserver à UML et Xen, il en résulterait les résultats suivants :
<br /><br />
« Nous avons donc été en mesure, grâce à ces méthodes, de comparer trois systèmes de virtualisation : Vserver, UML et Xen. Il s’est révélé que Vserver était le plus léger mais qu’il souffrait de quelques lacunes au niveau de l’équité. Xen, quant à lui, s’est montré assez ”lourd” à l’utilisation : le fait de lancer un noyau par machine virtuelle consomme trop de mémoire. En revanche, il est très complet grâce à un grand nombre de configurations possibles, et très fiable au niveau des performances (linéarité, équité, surcoût du système). Pour finir, UML s’est révélé avoir le même défaut que Xen, sans toutefois posséder les qualités de ce dernier. »<br /><br />
 
Pour plus de renseignements, jetez un coup d'oeil à <br />http://www.lri.fr/~quetier/papiers/renpar2005_vmeter.pdf<br /><br />
« Nous avons donc été en mesure, grâce à ces méthodes, de comparer trois systèmes de virtualisation : Vserver, UML et Xen. Il s’est révélé que Vserver était le plus léger mais qu’il souffrait de quelques lacunes au niveau de l’équité. Xen, quant à lui, s’est montré assez ”lourd” à l’utilisation : le fait de lancer un noyau par machine virtuelle consomme trop de mémoire. En revanche, il est très complet grâce à un grand nombre de configurations possibles, et très fiable au niveau des performances (linéarité, équité, surcoût du système). Pour finir, UML s’est révélé avoir le même défaut que Xen, sans toutefois posséder les qualités de ce dernier. »
 
--Kyan, Mai-Juin 2006
Pour plus de renseignements, jetez un coup d'oeil à http://www.lri.fr/~quetier/papiers/renpar2005_vmeter.pdf
<P>
'''''Bibliographie '''''
<br /><br />
http://linux-vserver.org/ Le site officiel<br />
http://irc.13thfloor.at/LOG/ Les LOGS IRC<br />
http://www.lri.fr/~quetier/papiers/renpar2005_vmeter.pdf L'étude Vserver / Xen / UML<br />
http://lena.franken.de/linux/debian_and_vserver/vserver.html Tutorial / HowTo Vserver<br />
 
== Bibliographie ==
 
* [http://linux-vserverlinuxfr.org/ Le Complément sitepour officiel]Linux<br />
http://www.solucorp.qc.ca/ Quick explanation<br />
* [http://irc.13thfloor.at/LOG/ Les LOGS IRC]
http://www.linuxjournal.com/node/5737/print Linux CAPS : lcap<br />
* [http://www.lri.fr/~quetier/papiers/renpar2005_vmeter.pdf L'étude Vserver / Xen / UML]
<P>
* [http://lena.franken.de/linux/debian_and_vserver/vserver.html Tutorial / HowTo Vserver]
* [http://www.solucorp.qc.ca/ Quick explanation]
* [http://www.linuxjournal.com/node/5737/print Linux CAPS : lcap]
 
[[Catégorie:GNU Linux]]
Récupérée de « https://fr.wikibooks.org/wiki/Linux-VServer »