Différences entre versions de « VServer »

De Cliss XXI
Sauter à la navigation Sauter à la recherche
imported>SylvainBeucler
imported>SylvainBeucler
m
 
(22 versions intermédiaires par le même utilisateur non affichées)
Ligne 9 : Ligne 9 :
 
* très proche d'un noyau classique, pas de comportement bizarre à la Xen (port série, clavier...)
 
* 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.
 
* 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.
 +
* cache disque global - je ne pense pas que ce soit le cas dans Xen?
  
 
== Inconvénient ==
 
== Inconvénient ==
Ligne 62 : Ligne 63 :
 
# Si bind sur le host:
 
# Si bind sur le host:
 
#echo "nameserver 192.168.30.1" > /vservers/$NAME/etc/resolv.conf
 
#echo "nameserver 192.168.30.1" > /vservers/$NAME/etc/resolv.conf
 +
# Suppression du /tmp en RAM limité à 16Mo - plus de problèmes qu'autre chose
 +
sed -i -e 's,^none\t/tmp,#&,' /etc/vservers/$NAME/fstab
 
</pre>
 
</pre>
 +
 +
Peut servir pour débloquer une mise à jour Lenny: désactiver la relance de klogd (qui ne fonctionne pas dans vserver et est désactivé au démarrage) après sa mise à jour:
 +
ln -nfs /bin/true /var/lib/dpkg/info/klogd.postinst
 +
update-rc.d -f klogd remove
 +
 +
== 32/64 bits ==
 +
 +
* Créer un VServer 32bit sous 64bit: [http://linux-vserver.org/Installing_32-bit_Fedora_on_64-bit_Debian] (essentiellement: export ARCH=i386)
 +
* Lancer un VServer installé en 32bit sous 64bit: aucune manipulation nécessaire, mais on peut en plus spécifier l'architecture machine du vserver dans <code>uts/machine</code> (ex: i686 ou x86_64), de façon à avoir `uname -m` correct.
  
 
== Renommer un VServer ==
 
== Renommer un VServer ==
Ligne 110 : Ligne 122 :
 
           stop-bootlogd-single umountfs umountnfs.sh umountroot \
 
           stop-bootlogd-single umountfs umountnfs.sh umountroot \
 
           urandom; do
 
           urandom; do
     vserver "$NAME" exec update-rc.d -f "$i" remove
+
     #vserver "$NAME" exec update-rc.d -f "$i" remove
 +
    chroot "/vserver/$NAME" update-rc.d -f "$i" remove
 
  done
 
  done
 +
 +
Cette procédure est également à relancer en cas de mise à jour de la distribution (ex: etch->lenny).
  
 
== Adresses IP privées ==
 
== Adresses IP privées ==
Ligne 121 : Ligne 136 :
 
sed -i -e "s/^#ListenAddress 0.0.0.0/ListenAddress $PUBLIC_IP/" /etc/ssh/sshd_config
 
sed -i -e "s/^#ListenAddress 0.0.0.0/ListenAddress $PUBLIC_IP/" /etc/ssh/sshd_config
 
invoke-rc.d ssh restart
 
invoke-rc.d ssh restart
#same for Exim/Postfix
+
# Same for Exim/Postfix
 
sed -i -e "s/^QUEUERUNNER=.*/QUEUERUNNER='queueonly'/" /etc/default/exim4
 
sed -i -e "s/^QUEUERUNNER=.*/QUEUERUNNER='queueonly'/" /etc/default/exim4
 
invoke-rc.d exim4 restart
 
invoke-rc.d exim4 restart
 +
# Same for bind
 +
sed -i -e "s/listen-on-v6 { any; };/listen-on { 127.0.0.1; };/" /etc/bind/named.conf.options
  
 
# NAT
 
# NAT
Ligne 182 : Ligne 199 :
 
EOF
 
EOF
 
</pre>
 
</pre>
 +
 +
== Bootstrap de Fedora ==
 +
 +
util-vserver devrait pouvoir générer une image minimale de Fedora. En version 0.215, ça plante dû à un problème de concurrence, lié à la mise en place d'un environnement d'exécution propre pour yum, ce qui reste un problème ouvert 2008-08-22.
 +
<pre>
 +
# 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 -- -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
 +
</pre>
 +
J'ai essayé avec différentes versions sur plusieurs machines mais rien n'y fait. Le dernier paquet Debian pre-release semble aller mieux au bout de quelques essais, mais plante avec une backtrace Python assez rapidement. Paquet yum à corriger?
 +
 +
En principe on peut bootstrapper une Fedora comme suite:
 +
* Ajouter les dépôts dans <code>/etc/yum/repos.d</code> (attention à ne pas utiliser $releasever: cette valeur est déterminée à partir de la version installée du paquet redhat-release, ce qui ne fonctionne naturellement pas sous Debian)
 +
<pre>
 +
echo <<EOF >> /etc/yum/yum.conf
 +
[fedora]
 +
name=fedora
 +
baseurl=http://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/releases/8/Fedora/i386/os
 +
 +
[updates]
 +
name=updates
 +
baseurl=http://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/updates/8/i386/
 +
EOF
 +
</pre>
 +
* Installer <code>initscripts</code> dans une racine annexe:
 +
yum --installroot=/vservers/yum-f9 install initscripts
 +
On notera qu'un paquet essentiel n'est pas installé: <code>yum</code>:
 +
yum --installroot=/vservers/yum-f9 install yum
 +
Il y a des avertissements concernant des logs de transaction, apparemment sans importance?
 +
Voir également pour fonctionner avec validation GPG (bind-mount $target/etc/pki/ -> /etc/pki ?)
 +
 +
Une autre méthode indépendante qui fonctionne en une ligne:
 +
rinse --distribution fedora-core-9 --directory /vservers/fedora9
 +
Cette méthode s'appuie sur une liste de paquets rpm plutôt que sur yum.
 +
 +
L'inconvénient de ces procédures est l'absence de procédure de post-install propre à vserver. Il faut au minimum:
 +
<pre>
 +
target=/vservers/fedora9
 +
mkdir $target/dev/pts
 +
chroot $target bash -c 'cd dev && MAKEDEV std ptmx'
 +
# If necessary:
 +
#chroot $target bash -c 'cd dev && MAKEDEV console pty fd'
 +
 +
(
 +
  cd $target/etc/rc.d/init.d/;
 +
  ls * | grep -v -E "functions|halt|killall|single|syslog|rsyslog" \
 +
    | xargs -r -n1 chroot $target chkconfig --del;
 +
)
 +
ln -nfs /bin/true $target/sbin/new-kernel-pkg
 +
ln -nfs /bin/true $target/sbin/rhgb-client
 +
cat <<EOF > $target/etc/init.d/halt
 +
#! /bin/bash
 +
exec /sbin/killall5 -15
 +
EOF
 +
# Is it necessary :
 +
#ln -nfs /bin/true $target/etc/rc.d/rc.sysinit
 +
#echo 'NETWORKING=yes' >> $target/etc/sysconfig/network
 +
#cp /dev/null $target/etc/sysctl.conf
 +
#echo "none / none default" > $target/etc/fstab
 +
</pre>
 +
 +
Des erreurs persisteront au démarrage malgré tout. Les ignorer, ou reproduire http://svn.linux-vserver.org/projects/util-vserver/changeset/2719 .
 +
 +
== Compilation noyau ==
 +
 +
Une option intéressante à '''désactiver''': <code>CONFIG_VSERVER_AUTO_SINGLE</code>. Cette option redéfinit une écoute réseau sur 0.0.0.0 en une écoute sur l'IP du vserver (dans le cas où celui-ci n'a qu'une IP). Ceci pose problème dans la mesure où le service n'écoute alors plus sur 127.0.0.1, et notamment nécessite de spécifier une adresse IP (qui est susceptible de changer). Les noyaux Debian ont cette option désactivée.
 +
 +
 +
== Compiler util-vserver depuis les sources ==
 +
 +
Cf. http://linux-vserver.org/Downloads
 +
 +
<pre>
 +
apt-get install build-essential iproute vlan e2fslibs-dev dietlibc-dev libbeecrypt6-dev python-dev util-linux
 +
./configure --sysconfdir=/etc --localstatedir=/var
 +
make
 +
make install
 +
make install-distribution
 +
update-rc.d vprocunhide defaults
 +
update-rc.d vservers-default defaults
 +
</pre>
 +
 +
Pour désinstaller:
 +
make uninstall
 +
 +
Pour nettoyer les mauvaises permissions des pre-releases:
 +
chmod go-w -R .
 +
chown root: -R .
  
 
== Liens ==
 
== Liens ==

Version actuelle datée du 15 mars 2010 à 16:29

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.
  • cache disque global - je ne pense pas que ce soit le cas dans Xen?

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
# Suppression du /tmp en RAM limité à 16Mo - plus de problèmes qu'autre chose
sed -i -e 's,^none\t/tmp,#&,' /etc/vservers/$NAME/fstab

Peut servir pour débloquer une mise à jour Lenny: désactiver la relance de klogd (qui ne fonctionne pas dans vserver et est désactivé au démarrage) après sa mise à jour:

ln -nfs /bin/true /var/lib/dpkg/info/klogd.postinst
update-rc.d -f klogd remove

32/64 bits

  • Créer un VServer 32bit sous 64bit: [1] (essentiellement: export ARCH=i386)
  • Lancer un VServer installé en 32bit sous 64bit: aucune manipulation nécessaire, mais on peut en plus spécifier l'architecture machine du vserver dans uts/machine (ex: i686 ou x86_64), de façon à avoir `uname -m` correct.

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
    chroot "/vserver/$NAME" 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
# Same for bind
sed -i -e "s/listen-on-v6 { any; };/listen-on { 127.0.0.1; };/" /etc/bind/named.conf.options

# 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 dû à un problème de concurrence, lié à la mise en place d'un environnement d'exécution propre pour yum, ce qui reste un problème ouvert 2008-08-22.

# 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 -- -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. Le dernier paquet Debian pre-release semble aller mieux au bout de quelques essais, mais plante avec une backtrace Python assez rapidement. Paquet yum à corriger?

En principe on peut bootstrapper une Fedora comme suite:

  • Ajouter les dépôts dans /etc/yum/repos.d (attention à ne pas utiliser $releasever: cette valeur est déterminée à partir de la version installée du paquet redhat-release, ce qui ne fonctionne naturellement pas sous Debian)
echo <<EOF >> /etc/yum/yum.conf
[fedora]
name=fedora
baseurl=http://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/releases/8/Fedora/i386/os

[updates]
name=updates
baseurl=http://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/updates/8/i386/
EOF
  • Installer initscripts dans une racine annexe:
yum --installroot=/vservers/yum-f9 install initscripts

On notera qu'un paquet essentiel n'est pas installé: yum:

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

Il y a des avertissements concernant des logs de transaction, apparemment sans importance? Voir également pour fonctionner avec validation GPG (bind-mount $target/etc/pki/ -> /etc/pki ?)

Une autre méthode indépendante qui fonctionne en une ligne:

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

Cette méthode s'appuie sur une liste de paquets rpm plutôt que sur yum.

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

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

(
  cd $target/etc/rc.d/init.d/;
  ls * | grep -v -E "functions|halt|killall|single|syslog|rsyslog" \
    | xargs -r -n1 chroot $target chkconfig --del;
)
ln -nfs /bin/true $target/sbin/new-kernel-pkg
ln -nfs /bin/true $target/sbin/rhgb-client
cat <<EOF > $target/etc/init.d/halt
#! /bin/bash
exec /sbin/killall5 -15
EOF
# Is it necessary :
#ln -nfs /bin/true $target/etc/rc.d/rc.sysinit
#echo 'NETWORKING=yes' >> $target/etc/sysconfig/network
#cp /dev/null $target/etc/sysctl.conf
#echo "none / none default" > $target/etc/fstab

Des erreurs persisteront au démarrage malgré tout. Les ignorer, ou reproduire http://svn.linux-vserver.org/projects/util-vserver/changeset/2719 .

Compilation noyau

Une option intéressante à désactiver: CONFIG_VSERVER_AUTO_SINGLE. Cette option redéfinit une écoute réseau sur 0.0.0.0 en une écoute sur l'IP du vserver (dans le cas où celui-ci n'a qu'une IP). Ceci pose problème dans la mesure où le service n'écoute alors plus sur 127.0.0.1, et notamment nécessite de spécifier une adresse IP (qui est susceptible de changer). Les noyaux Debian ont cette option désactivée.


Compiler util-vserver depuis les sources

Cf. http://linux-vserver.org/Downloads

apt-get install build-essential iproute vlan e2fslibs-dev dietlibc-dev libbeecrypt6-dev python-dev util-linux
./configure --sysconfdir=/etc --localstatedir=/var
make
make install
make install-distribution
update-rc.d vprocunhide defaults
update-rc.d vservers-default defaults

Pour désinstaller:

make uninstall

Pour nettoyer les mauvaises permissions des pre-releases:

chmod go-w -R .
chown root: -R .

Liens