VServer

Atouts

on peut "entrer" dans un vserver depuis l'hôte sans passer par login (pas de mot de passe) (vserver monvserver enter)
pas d'émulation, donc rapidité
fonctionne comme un chroot sécurisé - pas besoin d'image disque ou de partition LVM séparée
peut partager des dossiers entre vservers, en lecture seule ou en écriture
une version pour tous les noyaux Linux - pas besoin de régresser à 2.6.18
fonctionne partout, serveurs ou portables (pas besoin de PAE)
très proche d'un noyau classique, pas de comportement bizarre à la Xen (port série, clavier...)
l'hôte peut éventuellement voir tous les processus hébergés, la charge totale, etc. Ce n'est pas juste un vserver parmi les autres.

Inconvénient

pas d'émulation réseau, donc pare-feu centralisé sur l'hôte (pas d'iptables dans les vservers)
configuration mal agencée

Survie

Création:

vserver monvserver build -m debootstrap -- -d etch -m http://mirror/debian

Lister les VServers:

vserver-stat

Entrer dans un VServer:

vserver monvserver enter

(re)Démarrer un VServer:

vserver monvserver stop
vserver monvserver start
vserver monvserver restart

Emplacement physique:

/vservers/monvserver/
/etc/vservers/monvserver/ # configuration

Versions

Il y a deux versions à prendre en compte:

la version du noyau Linux (2.6.2x...)
la version de VServer (stable 2.2.x, experimental 2.3.x)

La synchronisation de ces deux versions fonctionne souvent par à coups, en fonction de la phase de développement (expérimentale ou finalisation) et des changements dans les régions patchées du noyau.

Par exemple, au moment de la release 2.0, la version 2.6.17 était couverte, suivie d'une période sans nouvelle version synchronisée, puis un rattrapage au moment la release 2.2 avec 2.6.19-20 simultanément, puis 2.6.21-22 assez rapidement après les sorties correspondantes du noyau. Depuis plus rien apparemment, sauf si l'on regarde dans http://vserver.13thfloor.at/Experimental/ où l'on voit que la version de développement suit de près les noyaux 2.6.23-25.

Dans l'ensemble, on peut donc faire évoluer son noyau bien en phase avec les noyaux officiels, à condition d'utiliser des versions de développement de temps en temps.

Post-install de base

NAME=monvserver
DOMAIN=mondomaine
cd /etc/vservers/$NAME
echo $NAME > uts/nodename
echo 'default' > apps/init/mark
mkdir interfaces/11
echo 'dummy0' > interfaces/dev
echo '192.168.30.11/32' > interfaces/11/ip
sed -i -e "s/127.0.0.1\tlocalhost/127.0.0.1 $NAME.$DOMAIN $NAME localhost/" /vservers/$NAME/etc/hosts
sed -i -e 's/^root::/root:*:/' /vservers/$NAME/etc/shadow
# Si bind sur le host:
#echo "nameserver 192.168.30.1" > /vservers/$NAME/etc/resolv.conf

Renommer un VServer

Fichiers concernés:

/vservers/monvserver
/etc/vservers/monvserver
/etc/vservers/monvserver/name
/etc/vservers/monvserver/uts/nodename
/etc/vservers/monvserver/cache -> /etc/vservers/.defaults/cachebase/monvserver
/etc/vservers/monvserver/vdir -> /etc/vservers/.defaults/vdirbase/monvserver

Par script:

FROM=download
TO=sftp
vserver $FROM stop
mv /vservers/$FROM /vservers/$TO
mv /etc/vservers/$FROM /etc/vservers/$TO
echo $TO > /etc/vservers/$TO/name
echo $TO > /etc/vservers/$TO/uts/nodename
ln -sf /etc/vservers/.defaults/cachebase/$TO /etc/vservers/$TO/cache
ln -sf /etc/vservers/.defaults/vdirbase/$TO /etc/vservers/$TO/vdir
vserver $TO start

Vous aurez peut-être besoin de modifier également /vservers/$TO/etc/hosts.

Vérifiez enfin vos fstab.remote si vous avez partagé des dossiers entre vservers.

Précis de configuration

context: mettre un identifiant numérique unique pour le vserver
name: le nom dans vserver-stat
lancement automatique au démarrage de l'hôte: echo "default" > apps/init/mark
le hostname du vserver: uts/nodename
autoriser un vserver de sauvegarde (rsync) à utiliser mknod: echo MKNOD >> /etc/vservers/backup/bcapabilities

Optimiser le démarrage

Depuis util-vserver >= 0.30.214, util-vserver optimise le démarrage en supprimant des entrées dans /etc/rc?.d. Attention cependant, cela rend plus difficile de migrer le vserver vers une autre solution de virtualisation.

Si vous souhaitez en profiter pour d'ancien vservers sans les réinstaller, cf. /usr/lib/util-vserver/distributions/debian. Ou plus directement:

NAME=builder
for i in bootlogd checkfs checkroot halt hwclock.sh ifupdown klogd \
         libdevmapper1.02 makedev module-init-tools mountall.sh \
         mountdevsubfs.sh mountnfs.sh mountkernfs.sh mountvirtfs \
         networking reboot setserial single stop-bootlogd \
         stop-bootlogd-single umountfs umountnfs.sh umountroot \
         urandom; do
    vserver "$NAME" exec update-rc.d -f "$i" remove
done

Cette procédure est également à relancer en cas de mise à jour de la distribution (ex: etch->lenny).

Adresses IP privées

Si vous ne disposez que d'un jeu limité d'adresses IP publiques, mais voulez installer plus de vservers, une bonne architecture est d'installer les vservers sur des adresses IP privées (192.168.30.0/24), et de centraliser l'association IP/port publics -> IP/port privés dans le pare-feu, avec un peu de NAT.

PUBLIC_IP=123.123.123.123
# Restrict host/domU IP usage
sed -i -e "s/^#ListenAddress 0.0.0.0/ListenAddress $PUBLIC_IP/" /etc/ssh/sshd_config
invoke-rc.d ssh restart
#same for Exim/Postfix
sed -i -e "s/^QUEUERUNNER=.*/QUEUERUNNER='queueonly'/" /etc/default/exim4
invoke-rc.d exim4 restart

# NAT
cat <<EOF >> /etc/network/firewall.sh
#!/bin/bash
# Clean-up
# Use 'ACCEPT' by default - safer when using '-F' manually
iptables -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

# Table 'nat' clean-up
iptables -t nat -F
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

# Connection sharing with internal servers
iptables -t nat -A POSTROUTING -s 192.168.30.0/24 -d ! 192.168.30.0/24 -j SNAT --to-source $PUBLIC_IP

# Forward services to the appropriate internal server
iptables -t nat -A PREROUTING -d $PUBLIC_IP -p tcp --dport 10022 -j DNAT --to-destination 192.168.30.10:22
iptables -t nat -A OUTPUT     -d $PUBLIC_IP -p tcp --dport 10022 -j DNAT --to-destination 192.168.30.10:22
iptables -t nat -A PREROUTING -d $PUBLIC_IP -p tcp --dport http -j DNAT --to-destination 192.168.30.10
iptables -t nat -A OUTPUT     -d $PUBLIC_IP -p tcp --dport http -j DNAT --to-destination 192.168.30.10
iptables -t nat -A PREROUTING -d $PUBLIC_IP -p tcp --dport domain -j DNAT --to-destination 192.168.30.10
iptables -t nat -A OUTPUT     -d $PUBLIC_IP -p tcp --dport domain -j DNAT --to-destination 192.168.30.10
iptables -t nat -A PREROUTING -d $PUBLIC_IP -p udp --dport domain -j DNAT --to-destination 192.168.30.10
iptables -t nat -A OUTPUT     -d $PUBLIC_IP -p udp --dport domain -j DNAT --to-destination 192.168.30.10
# ...
EOF
chmod 755 /etc/network/firewall.sh
cat <<EOF >> /etc/network/interfaces
pre-up /etc/network/firewall.sh
EOF

# Attribute an IP to a VServer:
cd /etc/vservers/myvserver
cd interfaces
mkdir 12
echo 'eth0' > dev
echo '192.168.30.12/32' > 12/ip

fail2ban pour VServer

Comme les systèmes invités n'ont pas accès au pare-feu, on peut installer fail2ban pour l'ensemble des vservers:

cat <<'EOF' >> /etc/fail2ban/jail.local
[ssh-vservers]

enabled = true
port    = ssh
filter  = sshd
logpath  = /vservers/*/var/log/auth.log
maxretry = 10
EOF

Bootstrap de Fedora

util-vserver devrait pouvoir générer une image minimale de Fedora. En version 0.215, ça plante. J'en ai discuté avec l'auteur qui remet plus facilement en cause Debian que son programme.

# vserver test build -m yum --context 1234 -- -d f7
rpm-fake-resolver: vc_ctx_migrate(): No such process
rpm-fake.so: failed to initialize communication with resolver
# vserver test build -m yum --context 1234 -- -d f7
rpm-fake-resolver: vc_ctx_migrate(): No such process
rpm-fake.so: failed to initialize communication with resolver
# vserver test build -m yum --context 1234 -- -d f7
rpm-fake-resolver: vc_ctx_migrate(): No such process
rpm-fake.so: failed to initialize communication with resolver
# uname -a
Linux dmc 2.6.25-2-vserver-686 #1 SMP Fri Jul 18 19:56:05 UTC 2008 i686 GNU/Linux
# vserver --version
vserver 0.30.215 -- manages the state of vservers
This program is part of util-vserver 0.30.215

J'ai essayé avec différentes versions sur plusieurs machines mais rien n'y fait.

En principe on devrait pouvoir bootstrapper un Fedora en utilisant:

yum --installroot=/vservers/yum-f9 install initscripts

après avoir rajouté les dépôts dans /etc/yum/repos.d Mais:

# yum --installroot=/vservers/yum-f9 install initscripts
core                      100% |=========================| 2.4 kB    00:00     
primary.sqlite.bz2        100% |=========================| 1.4 MB    00:05     
removing mirrorlist with no valid mirrors: /vservers/yum-f9/var/cache/yum/updates/mirrorlist.txt
Error: Cannot retrieve repository metadata (repomd.xml) for repository: updates. Please verify its path and try again

Il paraîtt que l'infrastructure Fedora est en rade en ce moment. On patientera donc un moment avant d'incriminer la solution.

Une autre méthode indépendante qui elle fonctionne et à laquelle le mainteneur de util-vserver ne voit pas d'intérêt est:

rinse --distribution fedora-core-9 --directory /vservers/fedora9

Le seul inconvénient est l'absence de procédure de post-install propre à vserver. Il faut au minimum:

target=/vservers/fedora9
chroot $target bash -c 'cd dev && MAKEDEV std console pty fd'
mkdir $target/dev/pts # necessary?

et d'autres choses à corriger comme éviter de synchroniser l'horloge ou de tenter de communiquer avec initctl.

J'arrête là parce que je perd mon calme en repensant à l'absence de réaction après mes rapports de bugs, mais je note tout ça pour plus tard.

Liens

Homepage
Référence de configuration, dite "flower page"
Index of /Experimental: versions en cours, avec des noyaux plus récents