Debian Etch et vserver sur SUN X4100

Installation de vserver sur SUN X4100 avec Debian et LVM

Pourquoi Debian ?

Les SUN X4100 sont dotées d'Opteron AMD64 ainsi que de disques durs scsi.

L'objectif est d'installer un linux minimal hôte des vservers. Le tour des distributions est vite fait : si on élimine toutes les distributions gratuites qui imposent une interface graphique et plein de gadgets inutiles, il reste Debian, Ubuntu Server et Gentoo.

Le choix initial pour des raisons à la fois de stabilité, mais aussi de compétences internes partagées, s'est porté sur une plateforme DEBIAN 4.0 qui fournit un kernel 2.6.18-5.

L'installation de Debian Etch

ATTENTION : (http://blog.postmaster.gr/2006/08/17/install-debiantesting-etch-on-a-sun-x4100/) -le système cherche à monter des disques sdi qui n'existent pas-

Après de nombreux essais infructueux à partir du CD netinst, je me suis décider à graver un DVD1 de la version complète

Pendant l'installation, je choisis le type de partitionnement suivant (il nomme encore les disques sdi pour l'instant):

/boot partition primaire de 100 Mo                (/dev/sdi1)
/swap partition primaire de 2 Go (/dev/sdi2)
/ partition primaire de 4 Go (/dev/sdi3)
le reste : partition primaire de 69 Go pour LVM (/dev/sdi4)

Je précise aussi d'aller chercher sur le réseau les paquets nécessaires (sources france)
(ne rien choisir à l'install, ni serveur de fichier, ni web, ni bdd, ni interface graphique et on obtient un système basique)

A la fin, on reboote et surtout on prie pour qu'il arrive le premier coup à remonter les disques sda en sdi !

Immédiatement, si ça a marché (sinon, je crois qu'il faut rebooter jusqu'à ce que ça passe : loterie), on va corriger à la main la fstab et le grub en tant que root :

cd /etc
cp fstab fstab.old
nano fstab #on remplace tous les sdi en sda et on commente tous les sda qui existaient avant
cd /boot/grub
cp menu.lst menu.lst.old
nano menu.lst #on remplace tous les sdi en sda, y compris dans les lignes commentées par précaution pour le futur

Maintenant, on peut souffler, ça doit redémarrer tout le temps sans problème, mais ce n'est pas fini !

UUID : pour en finir avec les sdx

On va faire en sorte de définitivement se libérer des problèmes de noms de disques en utilisant les UUID.

Pour ce faire, on va générer un UUID unique et l'associer au disque monté dans /dev/sdx.

uuid=`uuidgen`
tune2fs -U $uuid /dev/sda1
Et on réitère pour chaque sdquelque-chose.
Pas besoin de le faire pour le swap qui a déjà son UUID associé à la création.

Vérification (en étant root):

blkid

Ensuite on pense à changer la fstab (encore !) et la conf du grub.

Pour fstab, on remplace les /dev/sda en UUID avec les valeurs créées dans /etc/fstab :

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
#/dev/sda3
UUID=60c5ace7-0024-4401-a3f0-466820f7514e / ext3 defaults,errors=remount-ro 0 1
#/dev/sda1
UUID=355d3bf8-46f4-4e57-a018-a7c8df25eeda /boot ext3 defaults 0 2
#/dev/sda2
UUID=fc0dcd25-eadd-4120-af7a-315b66646fa6 none swap sw 0 0
/dev/hda /media/cdrom0 udf,iso9660 user,noauto 0 0

Pour le grub (/boot/grub/menu.lst), on change (encore) les références à sda en UUID (ne pas faire attention dans l'exemple à ce qui parle déjà de vserver) :

 ...
## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
## kopt_2_6_8=root=/dev/hdc1 ro
## kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=UUID=60c5ace7-0024-4401-a3f0-466820f7514e ro
...
title Debian GNU/Linux, kernel 2.6.18-5-amd64
root (hd0,0)
kernel /vmlinuz-2.6.18-5-amd64 root=UUID=60c5ace7-0024-4401-a3f0-466820f7514e ro
initrd /initrd.img-2.6.18-5-amd64
savedefault

title Debian GNU/Linux, kernel 2.6.18-5-amd64 (single-user mode)
root (hd0,0)
kernel /vmlinuz-2.6.18-5-amd64 root=UUID=60c5ace7-0024-4401-a3f0-466820f7514e ro single
initrd /initrd.img-2.6.18-5-amd64
savedefault

title Debian GNU/Linux, kernel 2.6.18-5-vserver-amd64
root (hd0,0)
kernel /vmlinuz-2.6.18-5-vserver-amd64 root=UUID=60c5ace7-0024-4401-a3f0-466820f7514e ro
initrd /initrd.img-2.6.18-5-vserver-amd64
savedefault

title Debian GNU/Linux, kernel 2.6.18-5-vserver-amd64 (single-user mode)
root (hd0,0)
kernel /vmlinuz-2.6.18-5-vserver-amd64 root=UUID=60c5ace7-0024-4401-a3f0-466820f7514e ro single
initrd /initrd.img-2.6.18-5-vserver-amd64
savedefault

### END DEBIAN AUTOMAGIC KERNELS LIST

La conf réseau

On fait vite la conf réseau du serveur qui était initialement en dhcp

nano /etc/network/interfaces
# on commente toutes les lignes de eth0
# on ajoute :
auto eth0
iface eth0 inet static
address 10.10.23.17
netmask 255.255.255.0
gateway 10.10.23.3
On vérifie que le fichier /etc/resolv.conf contienne bien nos DNS : 195.22.151.50 et 194.199.73.1, au moins.

On valide la modification de la conf réseau :

/etc/init.d/networking force-reload

On pense à ajouter les paramètres du proxy dans notre environnement :

cd
nano .bashrc # ajout des lignes : http_proxy="login:passwd@runcache.univ-reunion.fr:8080/" et export http_proxy
source .bashrc
On commente la source CD dans les dépôts :
nano /etc/apt/source.list
# commenter la ligne du CD
Et on fait la mise à jour du système qui va déclencher une mise à jour du kernel :
apt-get update
apt-get upgrade
A la toute fin, on reboote avec un kernel tout neuf qui, on espère ne devrait plus poser de problème avec les disques.

installation de vserver là dessus

O joie, dans les backports, il existe une version packagée du kernel 2.6.18-5 pour vserver : ici
On installe donc d'abord les pré-requis s'ils n'y sont pas déjà :

apt-get install debconf coreutils e2fsprogs initramfs-tools module-init-tools util-vserver
Puis vserver soi-même :
apt-get install linux-image-2.6.18-5-vserver-amd64
A la fin, on modifie le grub pour qu'il prenne comme entrée par défaut le kernel patché pour vserver
nano /boot/grub/menu.lst
# modification du numéro d'entrée sur la ligne 'default' Attention, ça commence à zéro
Et on reboote.
On peut alors finalement installer les outils pour vserver :
sudo apt-get install -t etch-backports debootstrap util-vserver

Espace pour les vservers : LVM

tiré du tuto http://doc.ubuntu-fr.org/lvm (voir aussi pour changement de taille des LV)

On n'oublie pas d'installer lvm

sudo apt-get install lvm2
On crée un disque physique pour lvm, sans se tromper sous risque de formater la mauvaise partition
/etc/init.d/lvm start
sudo pvcreate /dev/sda4
On crée le volume groupe principal (je le nomme "mainvg") qui contiendra les volumes logiques (un par vserver)
sudo vgcreate mainvg /dev/sda4
On vérifie qu'on a bien fait
sudo vgdisplay mainvg
On crée ensuite le volume logique, par exemple gcc, de 3 go
lvcreate -n gcc -L 3000 mainvg
On le formate et on le monte sur son répertoire
mkfs -t ext3 /dev/mainvg/gcc
mkidr /vservers (si pas déjà fait)
mkdir /vservers/gcc
mount /dev/mainvg/gcc /vservers/gcc
df -h

Comme les plus malins l'auront constaté, j'ai nommé /dev/sda4 dans la création du disque LVM sans m'occuper des UUID. Tout simplement, LVM génére et associe son UUID automatiquement. Nous n'avons pas à nous en soucier et on écrit bien dans la fstab (/etc/fstab) les montages sur LVM sans les UUID. Exemples :

/dev/mapper/mainvg-gcc       /vservers/gcc           ext3    defaults        0       2
/dev/mapper/mainvg-stic /vservers/stic ext3 defaults 0 2
La notation LVM reste toujours la même dans la fstab : /dev/mapper/nomduVolumeGroup-nomduVolume. ATTENTION : si le nom du volume logique contient des tirets, il faut les doubler dans le path de la fstab ex : /dev/mapper/nomduVolumeGroup-Nom--du--Volume--Logique

L'idée par la suite est de créer un LV pour chaque vserver avec une taille adaptée à chacun et de le monter sous /vservers/ .
Maintenant, on va dire à vserver de stocker les serveurs virtuels dans LVM plutôt que son répertoire vdirbase par défaut (nous venons de monter un LV sur /vservers/gcc) :

cd /etc/vservers/.defaults
sudo rm vdirbase
rem: On fait pointer notre répertoire qui hébergerera les vserveurs sur la partition créée à cet effet
sudo ln -s /vservers/ vdirbase

Enfin, création d'un vserver

Maux vieux être root, ou être sûr de http_proxy dans son environnement de sudoer, sinon debootstrap part en sucette :
export http_proxy="http://cri-web.univ.run:8080/"
vserver gcc build -m debootstrap --hostname gcc --interface eth0:10.10.23.19/24 -- -d etch
On peut trouver dans /usr/lib/debootstrap/scripts l'ensemble des distros que debootstrap sait installer directement, sinon il faut passer par une image ou d'autres méthodes (yum, etc) que debootstrap -voir chez vserver : http://linux-vserver.org/Installing_32-bit_Fedora_on_64-bit_Debian
Dès que notre vserver gcc est créé, on pense à faire en sorte qu'il démarre automatiquement aux futurs démarrage de l'hôte :
sudo echo default > /etc/vservers/gcc/apps/init/mark
On fait une copie du sources.list de l'hôte vers le guest
sudo cp /etc/apt/sources.list /vservers/gcc/etc/apt/
On pense tout de suite à dire ssh de l'hôte de ne plus écouter que son IP à lui
sudo nano /etc/ssh/sshd_config
# Mettre l'IP de l'hôte en face de Listen

On démarre la vserver et on entre dedans :

sudo vserver gcc start
sudo vserver gcc enter
A partir de là, on est dans le vserver. Immédiatement, on installe ssh et on le paramètre fissa :
root@gcc# apt-get update
root@gcc# apt-get install ssh
root@gcc# nano /etc/ssh/sshd_config
# Mettre l'IP du guest gcc en face de Listen : 10.10.23.19
Idem, ça peut limiter les dégats (genre conflit d'IP) de déclarer le localhost dans le fichier /etc/hosts
root@gcc# nano /etc/hosts
10.10.23.19 localhost.localdomain localhost # à la place du sempiternel 127.0.0.1
10.10.23.19 gcc.univ.run
Et c'est fini, le guest est accessible comme un serveur à part entière via ssh !

NOTE : chaque vserver monte son /tmp avec une taille limitée par défaut à 16 Mo. Il peut être utile de changer cette valeur (ex : le vserver héberge un Apache qui fait des upload de fichiers). Pour ceci, il convient d'éditer /etc/vserver/VSERVER_NAME/fstab, de changer la taille /tmp (size=500m, par exemple) et de redémarrer le vserver.

Changement de taille

Si on doit changer la taille disque du vserver (aggrandir !), il faut d'abord démonter le volume, retailler le volume logique, le dire au filesystem et remonter le volume. Exemple :

vserver gcc stop
umount /vserver/gcc
fsck /dev/mainvg/gcc
lvresize -L 6g /dev/mainvg/gcc
e2fsck -f /dev/mainvg/gcc
resize2fs /dev/mainvg/gcc
mount /dev/mainvg/gcc /vserver/gcc/
vserver gcc start


IP supplémentaires (aliases) sur un vserver

On peut avoir besoin qu'un vserver possède plusieurs adresses IP, par exemple pour utiliser des certificats SSL différents avec Apache.
Pour ceci, à partir de l'hôte, on procède comme suit :

cp -fr /etc/vservers/nomduvserver/interfaces/0 /etc/vservers/nomduvserver/interfaces/1
echo "IP.QUI.VA.BIEN" > /etc/vservers/nomduvserver/interfaces/1/ip
vserver nomduvserver stop
vserver nomduvserver start


On n'oubliera pas d'ajouter l'entrée de type A correspondante dans le DNS.

Clonage d'un vserver à partir d'un modèle


voir ici : https://sites.google.com/a/bousquie.fr/jerome/Home/debian-etch-et-vserver-sur-sun-x4100/creation-d-un-template-de-vserver

Comments