| AccueilCalendrierVenir aux réunionsContactsMembresDocumentationsLiens Forbach (57) Metz (57) Ventron (88) BacASable |
MirabellugWikiVServersQu'est ce que c'est ?Le projet VServer est constitué de deux parties :
L'idée de base des vservers, c'est un peu le principe du chroot mais poussé à l'extrème. On isole non seulement le système de fichier, mais également les processus et les ressources systèmes et on supprime toutes possibilités aux processus créés d'utiliser d'autres ressources que celles qui leur auront été affectées. Comment ça marche ?Pour l'isolement des processus et des ressources :A chaque processus tournant sur la machine, le noyau va affecter un paramètre supplémentaire qui est le numéro de contexte.Le principe, c'est que chaque processus n'accède qu'aux ressources qui sont dans le même numéro de contexte. Ainsi deux processus qui tounent sur la même machine mais dans deux contextes différents ne se voient pas, même si ceux-ci appartiennent tous deux à root ! Tous les processus d'un vserver partagent le même numéro de contexte. Pour l'isolement du système de fichier :Ca ressemble fortement au chroot avec quelques améliorations (barrier). Pour l'isolement de la couche réseauLes processus confinés dans un vservers ne peuvent utiliser que le nom de machine et l'addresse IP (alias ou deuxième carte réseau) qui leur ont été affectés au lancement. Les ressources SysV? IPC sont limités aux processus d'un même context. Pour empècher les processus de s'évader ou de faire des bêtisesIci, les utilitaires des vservers vont exploiter les Kernel Capabilities du noyau. Les Kernel Capabilities sont en gros toutes les capacités supplémentaires que possède root (uid 0) par rapport à un autre utilisateur :
Pour une liste détaillée, voir http://www.lids.org/lids-howto/node34.html. Par défaut, un processus root dans un vserver ne conserve que très peu de ces capacités. Essentiellement : CAP_NET_BIND_SERVICE pour pouvoir utiliser des ports privilégiés (inférieurs à 1024).
CAP_CHOWN pour pouvoir changer les propriétaires/groupes d'un fichier. On peut aussi limiter la mémoire, la ressource CPU, et d'autres ressources encore globalement affectés à l'ensemble des processus d'un vserver. Pour éconnomiser la ram et l'espace disqueLes systèmes de fichiers utilisés par les vservers peuvent être unifiés. C'est à dire que les fichiers communs ne seront présents qu'une fois sur le disque (hard link) et par conséquent qu'une fois en mémoire (même inode). Si un des vservers tente de modifier le fichier, ou le fichier sera copié ou l'écriture sera simplement interdite en fonction de la configuration. Tout ceci explique qu'un processus tournant dans un vserver ne consomme strictement aucune ressource supplémentaire par rapport au même processus tournant directement sur l'hôte, contrairement à vmware, boch, ou uml. Avantages- Sauf à exploiter une faille du kernel lui-même, il est impossible de s'échaper d'un vserver. Même certaines failles du kernel peuvent ne pas être exploitables, parceque si la faille permet de devenir root, il faut aussi qu'elle permette de changer de contexte (0, c'est dire celui de l'hôte) pour obtenir les privilèges nécessaires. - Un vserver n'est qu'une arborescence de fichier et un fichier de configuration. C'est donc facilement dupliquable sur la même machine ou sur n'importe quel autre machine même d'architecture assez différente (de même type de CPU). A quoi ça sert ?Si on écoute les concepteurs (notament Jacques Gelinas l'initiateur du projet), ça sert à tout :-) Quelques exemples :
On peut également utiliser les vservers partout où on utilisait chroot avant pour améliorer la sécurité d'un service, faire des essais de cluster, etc ... Le noyau : configuration et compilationLe kernel est en fait la seule partie commune aux vservers. Dans l'exemple ci dessous nous utiliserons un kernel 2.6, le patch étant maintenant considéré comme stable, mais la technique est pratiquement identique pour un 2.4. Nous avons besoin des sources du noyau officiel (ici en 2.6.12.4), des outils de compilation et des librairies classiques (gcc, make, ncurses-devel, etc ...). Une version récente de gcc (v3.3) est conseillée. Nous avons également besoin du patch vserver (ici en v2.0) que l'on peut trouver ( à partir du site officiel ) ici.
cd /usr/src/linux-2.6
bzcat ../patch-2.6.12.4-vs2.0.diff.bz2 | patch -p1
make {|menu|x}config
Dans la catégorie VServer, choisissez les options qui vous conviennent. Je vous conseille pour les premiers essais de ne pas activer les options liées à la sécurité. Ceux-ci apporte une amélioration sensible au niveau de la sécurité et de l'isolement des vservers, mais au prix évidemment d'une certaine complexité d'administration : à tester lorsque les concepts de base des vservers sont bien assimilés. make make install make modules_install Pour supprimer un patch (pour en tester un autre par exemple), il suffit de l'appliquer à l'envers : bzcat ../patch-2.6.12.4-vs2.0.diff.bz2 | patch -p1 -R Les outils de configuration (version developpement)Pour pouvoir utiliser les nouvelles capacités de notre kernel tout neuf, nous aurons besoin du package util-vserver (ici en v0.30.190). Etant sur une base RedHat, j'ai construit le rpm à partir du tarball proposé (le .spec est prévu) : rpmbuild -ta util-vserver-0.30.190.tar.bz2 Il vous manquera certainement quelques outils (librairies, outils xml) pour pouvoir générer le paquet. Regardez le résultat du configure au début de la construction et ajoutez ce qui manque. Au final, nous installerons ces packages : - util-vserver-lib-0.30.190-0 - util-vserver-0.30.190-0 - util-vserver-core-0.30.190-0 - util-vserver-build-0.30.190-0 - util-vserver-sysv-0.30.190-0 La configuration d'un Vserver (version developpement)La configuration d'un vserver se fait dans /etc/vservers/<nom du vserver>/. Elle est composée d'une collection de petits fichiers comprenants très peu de paramètres (souvent un seul). Voir la documentation détaillée de la configuration pour la version de développement. à détailler ... La configuration d'un Vserver (version stable)La configuration d'un vserver se fait dans le fichier /etc/vservers/<nom du vserver>.conf. Elle est très simple à la base : # L'addresse IPROOT qui sera effectée au device IPROOTDEV : IPROOT=10.0.1.2 IPROOTDEV=eth0 # Le hostname du vserver : S_HOSTNAME=myvserver # On démarre le vserver au moment du boot du serveur hôte (lancé par /etc/init.d/ververs) : ONBOOT=yes # "Capabilities" à donner au vserver (le moins possible). # On donnera par exemple CAP_NET_RAW à un vserver hébergeant # un serveur DHCP (cf. broadcast) ou si un processus a besoin de faire des ping. S_CAPS="" # Si vous comprennez ce que ça veut dire, vous pouvez toujours essayer # de changer cette ligne : S_FLAGS="lock nproc" # Applique les limitations de ulimit à l'ensemble du vserver : ULIMIT="-HS -u 100" # Modifie le niveau de priorité (nice) de tous les processus du vserver : S_NICE= # Définit le numéro de priorité pour déterminer l'ordre de lancement # des vservers au boot (pas testé): PRIORITY= Vous pouvez ajouter un script /etc/vservers/<nom du vserver>.sh qui sera appelé avec les options ( pre-start, post-start, pre-stop, post-stop) aux moments du démarrage et de l'arrèt du vserver pour réaliser certaines opérations sur l'hôte (pour plus de détails, voir le Linux Vserver Administration Guide). On supprime ensuite tous les scripts d'initialisation du vserver. Une grosse partie sert à l'initialisation et est inutile dans notre cas (montage / démontage, réseau, clavier, souris, etc ...)
cd /vservers/<vserver>/etc
find rc* -type l -exec rm -f {} \;
On ne reconfigure ensuite que les services que l'on veut réellement. On peut alors lancer le vserver et y entrer : vserver myvserver start vserver myvserver enter Essayer de jouer ensuite avec ifconfig, ps, netstat, etc ... c'est surprenant la première fois ! Le problème du localhostPar défaut, les vservers n'ont pas d'interface localhost (lo), or un certain nombre d'applications en ont pourtant besoin. Il existe pour pas mal d'entre elles des astuces qui permettent de contourner cette limitation, il existe également des astuces plus globales à base de NAT (masquerading) par exemple. Je propose ici une autre solution qui utilise l'interface réseau virtuelle dummy. On commencera d'abord par réduire le masque de l'interface lo de l'hote : de 127.0.0.1/8 à 127.0.0.1/16. On ajoute alors dans /etc/modprobe.conf de l'hôte, une ligne pour déclarer plusieurs interface dummy (ici 5): options dummy numdummies=5 L'option "numdummies" fonctionne avec un kernel 2.6. Il faut peut-être trouver une autre technique avec un kernel 2.4. Il suffit alors de déclarer une interface réseau supplémentaire pour le vserver : dummy1 avec une addresse 127.1.0.1/16. Ce qui peut donner (pour la version stable) : IPROOT="dummy1:127.1.0.1 eth0:10.0.1.3" IPROOTDEV= Pour que l'illusion soit totale, modifiez le fichier /etc/hosts du vserver : %7.1.0.1 localhost Nous voilà maintenant avec un vserver ayant son propre localhost à l'addresse 127.1.0.1. La plupart des applications recherchant le nom "localhost" et non pas l'adresse "127.0.0.1", cela fonctionne parfaitement. === Démarrage automatique des Vservers === Lors du démarrage du serveur le script /etc/init.d/vservers-default vas être lancé pour initialiser et démarrer les vserveurs voulus. Les vservers démarrés ce script sont les vserveurs possédant ##default## dans le fichier /etc/vservers/<vserver>/apps/init/mark Pour le Vserver lila fera la commande suivante : Liens- Le site officiel- Une explication technique des entrailles du système : en, [http://linux-vserver.org/Linux-VServer-Paper-French fr]]. - Configurations pour la version de développement (Conseil : Changer la css ou mettez des lunettes de soleil ! ;-) ) - Virtual private servers and security contexts par Jacques Gélinas lui même. - Les outils vserver sur Savannah.
Il n'y a pas de commentaire sur cette page.
[Afficher commentaires/formulaire]
|