Installation d'une dedibox en RAID
Un article de Bellinux.
J'avais -nous avions, en wiki- documenté l'installation de la première dedibox de bellinux dans ces Tutoriels.
Sur celle-ci, on avait installé un AlternC complet, afin de servir de service d'hébergement pour Bellinux.
On vient de recevoir la deuxième dedibox, avec deux disques en RAID. On va l'installer avec des vservers pour cloisonner l'accès aux services et ressources entre plusieurs administrateurs de serveur.
Sommaire
|
Objectifs de l'installation
L'idée est que cette Dedibox héberge plusieurs serveurs virtuels en vserver, et que l'un d'entre eux remplace dans les prochains mois l'ancienne Dedi et un autre le serveur de toilettes belvil.net.
Distribution Debian etch
Parmi les distributions proposées pour la dedi la Debian SARGE et la Ubuntu 6.06 supportent à ce jour le RAID. La Debian etch n'est pas listée, à l'installation elle serait sensée supporter nativement le RAID.
Documentation
A ce jour, regarde mes marque-pages:
- sur les vservers
- sur les dedibox
En attendant la Dedibox, j'avais identifié la documentation suivante:
- Ce Debian Etch software RAID1 starts degraded HOWTO et aussi Debian new installation software RAID1 HOWTO (sarge) concernant la configuration du RAID (mais en fait il n'y en a pas trop besoin, la conf du RAID est native dans l'interface web!)
- Pour la configuration du réseau local des vservers, cet exemple d'utilisation de v-servers.
- Du même site, j'avais récemment utilisé ce Debian Anti-Spam Anti-Virus Gateway HOWTO qui s'était avéré utile pour re-configurer l'anti-spam de belvil.net lors de la migration à etch
- Pour les serveurs virtuels ce WikiBook vservers a l'air prometteur.
- et bien sur, on reprendra notre précédente documentation Installation d'un serveur internet.
Installation interface web Dedi et partitionnement
L'interface de configuration de la dedibox permet la configuration des disques RAID.
Lors de la livraison d'une dedibox, le disque A a un partitionnement basique et le disque B n'est pas utilisé. Il faut détruire le partitionnement par défaut, et re-créer les partitions. J'ai fait plusieurs tentatives, et voici finalement le partitionnement que j'ai créé:
Device Type Système de fichiers Point de montage Raid Taille (Mo) /dev/sda1 Primaire ext2 /boot non 256 x /dev/sda2 Primaire ext3 / non 7168 x /dev/sda3 Primaire swap 1536 x /dev/sda4 Etendue 143665 x /dev/sda5 Logique ext3 /var non 3072 x /dev/sda6 Logique ext3 /var/lib/vservers/uralan non 10240 x /dev/sda7 Logique ext3 /var/lib/vservers/uralan/home non 10240 x /dev/sda8 Logique ext3 /var/lib/vservers/uralan/var non 20480 x /dev/sda9 Logique ext3 /mnt/lvm non 99633 x
L'idée est la suivante:
- Les premières partitions sont prévues pour le disque hôte. Celui-ci sera peu utilisé, peut être que 10Go est même exagéré, mais je préfère prendre de la marge. Je ne sépare que le /var, pour borner les logs en cas d'attaque ou chose de ce genre.
- Répartition imaginée en un serveur hôte et plusieurs serveurs virtuels, le premier ayant ses propres partitions, les autres vservers pouvant se répartir le reste, à savoir presque 100Go.
- Le premier belvil aura éventuellement des utilisateurs (moi ;-), d'où un /home, mais j'aimerais bien y penser un AlternC, d'où 20Go de /var
- Pour les autres serveurs, on utilisera des volumes logiques LVM, que l'on peut redimensionner à souhait. Revers de la medaille de LVM: la récupération de données en cas de crash serveur est plus complexe ou hasardeuse.... (Mais on avait envie d'essayer!)
Sur cet espace on montera ensuite d'autres serveurs virtuels:
- un serveur killa (lune, en quechua), pourra servir de DMZ aux autres. On verra son rôle en détail plus loin.
- un serveur pour bellinux, qui sera essentiellement consacré à un alternC: 10Go pour la racine et d'où 30Go pour le /var.
- D'autres autres serveurs .
Parmi mes tentatives plus ou moins fructueuses, la première a été de tenter la configuration RAID au travers de l'interface de la dedibox. Elle est très bien faite: au fur et à mesure que l'on définit les partitions sur le disque /dev/sda, si on lui indique une partition RAID1, il construit son pendant dans le disque /dev/sdb. Cela dit, j'ia l'impression qu'on ne peut créer que des partitions RAID primaires, donc quatre au plus.
Pour ne pas me compliquer la vie lors d'une première tentative, j'ai déroulé les explorations avec un partitionnement nettement plus simple:
Device Type Système de fichiers Point de montage Raid Taille (Mo) /dev/sda1 Primaire ext2 /boot Raid 1 128 /dev/sda2 Primaire ext3 / Raid 1 15360 /dev/sda3 Primaire swap 1024 /dev/sda4 Etendue 136113 /dev/sda5 Logique ext3 /var Raid 1 136113
Dans ce cas, tous les serveurs hôtes auront leur racine en un point /var/lib/vservers/[server] du systèeme de fichiers, mais se partagent une même partition /dev/sda5.
Dans ce cas l'interface web a configuré le disque /dev/hdb en RAID comme suit:
Device Type Système de fichiers Point de montage Raid Taille (Mo) /dev/sdb1 Primaire ext2 /boot Raid 1 128 /dev/sdb2 Primaire ext3 / Raid 1 15360 /dev/sdb3 Primaire ext3 /var Raid 1 136113
Outre le coloisonnement pour mes serveurs principaux ce qui me gênait dans cette configuration était de ne pas avoir deux disques identiques... C'est tout de même ce qui nous avait permis de sauver notre premier serveur qui a craché, le paris-est, serveur virtuel dans sinerj, chez globenet.
Pour revoir la configuration RAID, je suis parti du HOWTO : Debian Etch software RAID1 starts degraded HOWTO.
Configuration correcte du RAID
Synoptique de la configuration du RAID1
Le processus d'installation ne nous a pas encore permis de configurer les disques en RAID1 comme on le souhaitait. On a commencé par installer la dedibox en tournant sur un seul disque (/dev/sda) sans partition en RAID, et on va créer les disques multi-device (array) /dev/mdX en ligne de commande, en suivant ce tutoriel.
Pour cela, on va créer une grappe de disques RAID en commençant par le deuxième disque de la dedibox, /dev/sdb. La table de partitions de ce disque sera crée à partir de celle de notre disque opérationnel, ensuite on la modifiera pour l'adapter au RAID, on créera les partitons/disques virtuels en RAID1 /dev/mdX, mais en leur attachant une seule partition active, sur /dev/sdb.
Ensuite, afin de faire des tâches de bas niveau comme la copie des répertoires montés, nous allons démarrer sur un autre système, le système de secours que porpose l'offre dedibox (sur une machine physique, où on a accès à la console, on peut se débrouiller en passant en mode monoutilisateur, hors tout périphérique). Nous monterons les disques sur des partitions de données, nous copierons le système opérationnel depuis le disque /dev/sda vers les grappes RAID.
Puis il nous faudra modifier le bootloader GRUB, et entrer dans notre système (par un chroot) afin d'installer les nouveaux paramètres de boot sur notre amorçage.
Enfin on redémarre sur les nouveaux disques RAID, et enfin on y ajoute le premier disque comme deuxièmes partiotions du RAID1.
Préparation des paquets
Dans les premières étapes du tutoriel, ce que je retiens, c'est qu'il faut démarrer sur un noyeau et une configuration de boot avec un initramfs. Or, il se trouve que le noyau qu'on va utiliser pour les vservers en dispose. Commençons par installer ce noyau. Le système bien à jour, avec aptitude en interface graphique ou en ligne de commande comme ci-dessous:
# apt-get install linux-image-2.6.18-4-vserver-686
Redémarrons sur ce noyau. Si tu as accès à la console de boot et que ton menu grub s'active, c'est immédiat. Sur les dédi, à ma connaissance, il n'y a pas accès direct à la console, il faut donc configurer grub pour qu'il démarre par défaut sur ce noyau. Pour ce faire, on édite le fichier /boot/grub/menu.lst, la ligne:
default 2
pour qu'elle indique le rang (en partant de la 0ième) de la config de démarrage dans la liste des étiquettes grub, à la fin du fichier. Par exemple, j'ai:
title Debian GNU/Linux, kernel 2.6.21.1dedibox-r7 root (hd0,0) kernel /vmlinuz-2.6.21.1dedibox-r7 root=/dev/md1 ro savedefault title Debian GNU/Linux, kernel 2.6.21.1dedibox-r7 (single-user mode) root (hd0,0) kernel /vmlinuz-2.6.21.1dedibox-r7 root=/dev/md1 ro single savedefault title Debian GNU/Linux, kernel 2.6.18-4-vserver-686 root (hd0,0) kernel /vmlinuz-2.6.18-4-vserver-686 root=/dev/md1 ro initrd /initrd.img-2.6.18-4-vserver-686 savedefault title Debian GNU/Linux, kernel 2.6.18-4-vserver-686 (single-user mode) root (hd0,0) kernel /vmlinuz-2.6.18-4-vserver-686 root=/dev/md1 ro single initrd /initrd.img-2.6.18-4-vserver-686 savedefault
La troisème dans la liste, numéro deux en commençant à compter à 0, est biel la Debian GNU/Linux, kernel 2.6.18-4-vserver-686
Une fois redémarré:
# reboot
tu peux le constater avec:
#> uname -r
On exécute alors la commande suivante pour mettre à jour le système de fichiers ram de boot:
update-initramfs -u
D'autres commandes sont possibles pour mettre à jour ce fichier, par exemple:
mkinitrd -o /boot/initrd.img-2.6.18-4-vserver-686 2.6.18-4-vserver-686
Ou encore en reconfigurant le paquet de gestion des disques raid:
dpkg-reconfigure mdadm
mais attention: il faut que le système soit bien propre au moment de générer ce fichier: disques nécessaires au démarrage bien montés, dossier virtuel /proc monté, etc. , et même certains fichiers de configuration.
Il ne faut pas hésiter à rebooter à chaque modification critique (initrd, grub, ...) de manière à s'assurer que l'étape est correctement franchie.
Création des grappes RAID
Le tutoriel que l'on suit nous suggère de ne monter en RAID que des disques bien propres. En effet, s'ils contiennent quelque chose, surtout des restes de partition RAID, la gestion des grappes multidisque pourrait les prendre pour des partitions de récupération légitimes, et repartir sur ces données. Cependant, la méthode donnée pour netoyyer les disques (mdadm --zero-superblock /dev/sdbX) ne marche pas. Essayons de réaliser l'idée autrement.
'Attention!!!' c'est une opération dangereuse! vérifie 4 fois (au moins) que derrière le of= de la commande tu mets bien le disque inutilisé. Et juste avant de taper enter, vérifie encore qu'il s'agit bien du bon disque (et ainsi successivement...).
Par exemple, avant même de travailler sur les partitions, faisons:
dd if=/dev/zero of=/dev/sdb bs=1M
Attention! Ca peut mettre du temps.
On a alors un disque propre, et on commence par copier y la table de partitions du disque actif:
sfdisk -d /dev/sda | sfdisk /dev/sdb
Ensuite, avec:
cfdisk /dev/sdb
on modifie toutes les partitions en Linux raid autodetect :
cfdisk 2.12r
Disk Drive: /dev/sdb
Size: 160041885696 bytes, 160.0 GB
Heads: 255 Sectors per Track: 63 Cylinders: 19457
Name Flags Part Type FS Type [Label] Size (MB)
---------------------------------------------------------------------------------------------------------------------------
sdb1 Boot, NC Primary Linux raid autodetect 41,13
sdb2 Primary Linux raid autodetect 16105,10
sdb3 Primary Linux raid autodetect 1069,29
sdb5 NC Logical Linux raid autodetect 5362,89
sdb6 NC Logical Linux raid autodetect 10734,00
sdb7 NC Logical Linux raid autodetect 21467,99
sdb8 NC Logical Linux raid autodetect 10734,00
sdb9 NC Logical Linux raid autodetect ~100000
Logical Free Space 41,13
On reboote, les commandes suggérées :
mdadm --zero-superblock /dev/sdbX
ne donnent rien, passons...
On crée les grappes RAID:
mdadm --create /dev/md0 --level=1 --raid-disks=2 missing /dev/sdb1 mdadm --create /dev/md1 --level=1 --raid-disks=2 missing /dev/sdb2 mdadm --create /dev/md2 --level=1 --raid-disks=2 missing /dev/sdb3 mdadm --create /dev/md3 --level=1 --raid-disks=2 missing /dev/sdb5 mdadm --create /dev/md4 --level=1 --raid-disks=2 missing /dev/sdb6 ... mdadm --create /dev/md7 --level=1 --raid-disks=2 missing /dev/sdb9
On crée les filesystem :
mkfs.ext2 /dev/md0 mkfs.ext3 /dev/md1 mkswap /dev/md2 mkfs.ext3 /dev/md3 mkfs.ext3 /dev/md4 ... mkfs.ext3 /dev/md7
On peut alors monter nos nouveaux disques :
mkdir /mnt/md0 mount /dev/md0 /mnt/md0
Modifications de la table des partitions montées
Modifions d'abord la table de montage des filesystems, /etc/fstab. En général je m'en fais deux ou trois copies pour les différentes configurations sur lesquelles je veux booter:
cp /et/fstab /etc/fstab.sda cp /et/fstab /etc/fstab.md_montes cp /et/fstab /etc/fstab.raid
ensuite, lorsque de besoin (et j'ai fait des aller/retour de reboot...) je prends l'un des fstabl:
cp /etc/fstab.raid /et/fstab
La configuration raid est la suivante:
# /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> #/dev/sda3 none swap sw 0 0 /dev/md2 none swap 0 0 /dev/md1 / ext3 defaults,errors=remount-ro 0 1 /dev/md0 /boot ext2 defaults 0 2 /dev/md3 /var ext3 defaults 0 2 /dev/md7 /mnt/lvm ext3 defaults 0 2 /dev/md4 /var/lib/uralan ext3 defaults 0 2 /dev/md6 /var/lib/uralan/home ext3 defaults 0 2 /dev/md5 /var/lib/uralan/var ext3 defaults 0 2
Et une configuration pour démarrer sur /dev/sda et voir les principaux disques /dev/mdX:
# /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> /dev/sda3 none swap sw 0 0 /dev/sda2 / ext3 defaults,errors=remount-ro 0 1 /dev/sda1 /boot ext2 defaults 0 2 /dev/sda9 /mnt/lvm ext3 defaults 0 2 /dev/sda6 /var/lib/uralan ext3 defaults 0 2 /dev/sda8 /var/lib/uralan/home ext3 defaults 0 2 /dev/sda7 /var/lib/uralan/var ext3 defaults 0 2 /dev/sda5 /var ext3 defaults 0 2 /dev/md1 /mnt/md_root ext3 defaults 0 2 /dev/md0 /mnt/md_root/boot ext2 defaults 0 2 /dev/md2 none swap 0 0 /dev/md3 /mnt/md_root/var ext3 defaults 0 2 /dev/md7 /mnt/md_root/mnt/lvm ext3 defaults 0 2 /dev/md4 /mnt/md_root/var/lib/uralan ext3 defaults 0 2 /dev/md5 /mnt/md_root/var/lib/uralan/var ext3 defaults 0 2 /dev/md6 /mnt/md_root/var/lib/uralan/home ext3 defaults 0 2
Modification et clonage du système en mode secours
Attention: en fait, ce qui est décrit ici conduit à un état pas tout à fait stable... Ce tutoriel [[1]] est plus précis. Il faudra revoir notre prose en fonction de cette dernière référence...
On redemarre la dedibox en mode secours. L'interface dedibox nous donne un mot de passe root.
Attention: on n'est plus sur le même système. La connexion en ssh offusque sans doute l'emprunte d'une clé enregistré sur notre client ssh.
Pour passer outre, note le numéro de clé que le serveur offusque:
dani@pelikan:~$ ssh root@buti @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 5f:2b:53:9f:85:92:ee:b2:f9:b6:91:66:d6:0b:5c:e7. Please contact your system administrator. Add correct host key in /home/dani/.ssh/known_hosts to get rid of this message. Offending key in /home/dani/.ssh/known_hosts:12 RSA host key for buti has changed and you have requested strict checking. Host key verification failed.
ici, c'est la clé numéro 12.
édite le fichier des clés de serveur connues:
vi ~/.ssh/known_hosts
va à la ligne incriminée: (tape: 12 G), et efface là (tape dd), enregistre et sors (tape :wq).
il te faudra peut être faire cela un certain nombre de fois...
on se connecte ensuite en ssh:
ssh root@buti.belvil.net
avec le mot de passe root que nous donne l'interface dedibox (ou sinon, de la manière dont tu entres comme utilisateur unique).
Nous allons monter les arborescences comme sur notre futur système hôte:
mkdir /mnt/sda_root mount /dev/sda2 /mnt/sda_root mount /dev/sda1 /mnt/sda_root/boot mount /dev/sda5 /mnt/sda_root/var mkdir /mnt/md_root mount /dev/md1 /mnt/md_root cd /mnt/md_root mkdir boot mkdir var mount /dev/md0 /mnt/md_root/boot mount /dev/md3 /mnt/md_root/var
Et on copie d'une arborescence à l'autre:
rsync -aHv --exclude=/proc/* --exclude=/sys/* --exclude=/dev/* /mnt/sda_root/* /mnt/md_root/ chmod 555 /mnt/md_root/proc
Moins élégant, on peut aussi faire un:
cp -dpR /mnt/sda_root/* /mnt/md_root/
et ensuite effacer le contenu de /mnt/md_root/dev, /mnt/md_root/proc, et /mnt/md_root/sys.
On entre ensuite dans le nouveau système avec un chroot:
chroot /mnt/md_root/ /bin/bash
On va modifier la configuration du bootloader GRUB, après avoir fait une sauvegarde:
cd /boot/grub cp menu.lst menu.lst.sda vi menu.lst
(vi, ou ton éditeur préféré)
Vérifie la ligne:
default 0
et ajoute en premier (en 0ième position) une entrée de boot:
## ## End Default Options ## title Debian GNU/Linux, kernel 2.6.18-4-vserver-686, RAID sur hd1 (sdb) root (hd1,0) kernel /vmlinuz-2.6.18-4-vserver-686 root=/dev/md1 ro initrd /initrd.img-2.6.18-4-vserver-686 savedefault
On peut alors entrer dans grub :
grub
Et enregistrer le masterboot correspondant:
grub> root (hd1,0) grub> setup (hd0)
On peut installer les masterbootsector de l'autre disque en cas de défaillance du premier, ainsi que les masterboot des partitions (je n'ai jamais bien compris avec lequel il vallait mieux travailler...)
grub> setup (hd1) grub> setup (hd0,0) grub> setup (hd1,0) grub> quit
Sors de ton shell chrooté:
exit
Pour la dedibox il faut alors sortir du mode secours, ce qui se pilote depuis l'interface web. Pour un autre serveur, il faudra sans doute juste rebooter:
reboot
L'air de rien c'est le grand moment... On se reconnecte en ssh, après avoir modifié notre .ssh/known_hosts pour qu'il accepte bien la clé ssh de la configuration installée sur le serveur:
ssh root@buti.belvil.net
On doit alors se retrouver dans le système sur les grappes RAID1 montées sur /dev/sdb. Vérifie-le un peu:
mount /dev/md/1 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/md/0 on /boot type ext2 (rw) /dev/md/3 on /var type ext3 (rw) /dev/md/11 on /var/lib/vservers type ext3 (rw)
Dans notre configuration à trois serveurs, il nous faut encore créer les points de montage:
cd /var/lib/vservers/ mkdir killa mkdir belvil mkdir bellinux mount -a mkdir killa/var mkdir belvil/var mkdir belvil/home mkdir bellinux/var mount -a
On a alors bien toutes les partitions:
mount /dev/md1 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/md0 on /boot type ext2 (rw) /dev/md3 on /var type ext3 (rw) /dev/md9 on /serveurs type ext3 (rw) /dev/md7 on /serveurs/bellinux type ext3 (rw) /dev/md8 on /serveurs/bellinux/var type ext3 (rw) /dev/md4 on /serveurs/belvil type ext3 (rw) /dev/md6 on /serveurs/belvil/home type ext3 (rw) /dev/md5 on /serveurs/belvil/var type ext3 (rw) /dev/sda2 on /mnt/sda2 type ext3 (rw)
less /proc/mdstat mdadm --misc -QD /dev/md0
Ajout à la grappe RAID des partitions de /dev/sda
Maintenant que notre serveur boot correctement sur notre deuxième disque, monté en grappes avec une seule unité pour l'instant, il nous reste à ajouter le premier disque comme réplication de partions RAID du deuxième.
Allez, on fait les choses bien, même si le tutoriel qu'on suit ne le dit pas, commençons par nettoyer le disque A:
dd if=/dev/zero of=/dev/sda bs=1M
La copie de tables de partitions ne prend pas... Allez, un reboot ne fait de mal à personne... In fine, j'ai dû repasser en mode de secours: mais rien de plus normal, on a effacé le master boot de /dev/sda!.
En mode de secours (ou monoutilisateur) on copie la table des disques.
sfdisk -d /dev/sdb | sfdisk /dev/sda
et on redéroule la configuration du masterboot avec GRUB, car en mettant à zéro tout le contenu du disque /dev/sda, on a effacé les informations du boot loader.
Cette fos-ci, pas besoin de modifier la table de partitions de /dev/sda, elle est déjà en 'Linux raid autodetect', mais on le vérifie:
cfdisk /dev/sda
On revient en mode normal. Puis ajoute les partitions aux grappes RAID:
mdadm --add /dev/md0 /dev/sda1 mdadm --add /dev/md1 /dev/sda2 mdadm --add /dev/md2 /dev/sda3 mdadm --add /dev/md3 /dev/sda5 mdadm --add /dev/md4 /dev/sda6 mdadm --add /dev/md5 /dev/sda7 mdadm --add /dev/md6 /dev/sda8 mdadm --add /dev/md7 /dev/sda9
On peut voir alors les miroirs raid se constituer:
# watch -n 6 cat /proc/mdstat
Every 6,0s: cat /proc/mdstat Sun Jul 8 20:31:02 2007
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[0] sdb1[1]
128448 blocks [2/2] [UU]
md1 : active raid1 sda2[2] sdb2[1]
15727552 blocks [2/1] [_U]
[==================>..] recovery = 93.7% (14743616/15727552) finish=0.2min speed=60319K/sec
md2 : active raid1 sda3[2] sdb3[1]
1044160 blocks [2/1] [_U]
resync=DELAYED
md3 : active raid1 sda5[2] sdb5[1]
5237120 blocks [2/1] [_U]
resync=DELAYED
...
Volumes logiques et modifiables
Sur la dernière partition on va créer des partitions logiques avec [LVM] de manière à pouvoir en ajouter, supprimer et les redimensionner selon que de besoin.
On prépare les paquets:
apt-get install lvm2
On crée un volume physique (pv) sur la partition:
pvcreate /dev/md7
On crée ensuite le groupe de volumes (vg), auquel on donne un nom, puis on l'active:
vgcreate buti_vg /dev/md7 vgchange -a y buti_vg
A ce groupe de volume correspond un répertoire de dispositif /dev/buti_vg
On crée un volume logique (lv), nommé "killa", de 7 Go, par exemple:
lvcreate -L7000 -nkilla buti_vg
Ce volume logique sera accessible pour formatage et montage au point de montage /dev/buti_vg/killa
A tout moment on peut voir ce qui est défini avec les utilitaires:
vgdisplay lvdisplay
Modifications à la configuration
Installation des paquets pour les vservers
On a déjà anticipé en installant le noyau de la debian etch incluant le patch pour vservers:
linux-image-2.6.18-4-vserver-686
On peut le revérifier avec:
#> uname -r
Il nous manque juste l'outillage des viservers. Le système bien à jour, avec aptitude en interface graphique ou en ligne de commande, comme ci-dessous tu dois installer les paquets suivants:
# apt-get install util-vserver ssh ncurses-base libncurses5 vserver-debiantools
Le premier vserver
Tu es en mesure de construire ton premier serveur virtuel:
vserver belvil build -n belvil --hostname killa.belvil.net
--interface eth0:192.168.44.50/24 -m debootstrap -- -d etch
Ce qui correspond aux valeurs symboliques suivantes:
VSERVER_NAME belvil FQDN killa.belvil.net NET_DEVICE eth0 IP 192.168.44.50 CIDR 24 (255.255.255.0) DEBIAN_DISTRO etch
Tu peux alors démarrer ton vserver:
vserver belvil start
Et y accéder comme administrateur:
vserver belvil enter
(Bien sûr vous sortez avec 'exit').
Enfin, tu peux détruire ton premier essai de vserver:
vserver belvil delete
Préparation du réseau
L'adresse IP que tu as définie ci-dessus est visible depuis le serveur hôte avec des contrôles basiques comme un ping, mais tu ne pourra pas encore y accéder avec un ssh, par exemple, moins encore de l'extérieur du serveur hôte. Dans le serveur virtuel fille, la table de routage est enore similaire au serveur hôte.
Avant de passer à une installation plus poussée, préparons un peu mieux notre réseau pour l'accès distant à nos différents vservers et entre eux. La solutions sera de monter un réseau local dans le serveur hôte, ce dernier servant, grâce iptables, de passerelle/firewall avec de la translation d'adresses.
192.168.44.44
+----------+ IP(s) publique(s) +------------+ |
| Internet |--------------------| passerelle |--------------+------+----- ...
+----------+ 88.191.xxx.xxx +------------+ 192.168.44.1 |
192.168.44.10
Tu peux créer directement les adresses et règles avec ifconfig ou ip, mais allons directement à la définition du réseau dans les fichiers de configuration au démarrage. Dans /etc/network/interfaces, ajouter une adresse IP interne:
auto eth0:0
iface eth0:0 inet static
address 192.168.44.1
netmask 255.255.255.0
network 192.168.44.0
broadcast 192.168.44.255
Il faut aussi autoriser le routage de paquets ('forwarding') au travers du serveur hôte. Dans le temps cela se faisait avec la déclaration ip_forward=yes dans le fichier /etc/network/options, maintenant c'est dans le fichier /etc/sysctl.conf, où il faut dé-commenter la déclaration:
net.ipv4.conf.default.forwarding=1
Redemarrez le réseau:
/etc/init.d/networking restart
vérifie les adresses et les routes du réseau:
ipconfig
et
route
Et/ou encore:
ip addr
commande qui, chez moi, donne grosso modo:
# ip addr
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
inet 88.191.51.247/24 brd 88.191.xxx.xxx scope global eth0
inet 192.168.50.1/24 brd 192.168.44.255 scope global eth0:0
inet 192.168.50.50/24 brd 192.168.44.255 scope global secondary eth0:killa
la dernière ligne n'aparaissant qu'après avoir configuré un premier serveur virtuel, comme indiqué ci-dessous.
et la commande:
ip route
qui, chez moi, donne:
sd-10047:/etc/ssh# ip route 88.191.xxx.0/24 dev eth0 proto kernel scope link src 88.191.xxx.xxx 192.168.44.0/24 dev eth0 proto kernel scope link src 192.168.44.1 default via 88.191.xxx.1 dev eth0
Configurons la translation d'adresses sur les paquets sortants:
/sbin/iptables -t nat -A POSTROUTING -s 192.168.44.0/24 -d ! 192.168.44.0/24 -j SNAT --to-source 88.191.xxx.xxx
Avec la règle ci-dessus, toute initiation d'une connexion udp ou tcp depuis un serveur virtuel avec son adresse virtuelle et s'adressant à la passerelle 192.168.44.1, sera retranscrite sur internet avec l'adresse publique source et un port choisi par le service.
Configurons aussi la translation d'adresses sur un port donné de l'adresse publique vers un serveur virtuel:
/sbin/iptables -I PREROUTING -t nat -p tcp -i eth0 -d 88.191.51.247 -s ! 192.168.50/24 --dport 2022 -j DNAT --to 192.168.44.44:22
Avec cette règle, les demandes de connexion entrante sur l'adresse publique 2022 sont redirigées vers le serveur virtuel qui sera à l'adresse 192.168.44.44, sur le port 22. Nous installerons ainsi le service ssh du serveur virtuel directement accessible depuis internet, à la même adresse IP que notre serveur physique, sur le nouveau port 2022.
/sbin/iptables -I PREROUTING -t nat -p tcp -i eth0 -d 88.191.51.247 -s ! 192.168.50/24 --dport 80 -j DNAT --to 192.168.50.51
Petite vérification:
iptables -L iptables -t nat -L
Voilà notre réseau prêt. Il nous faudra juste aussi automatiser au redémarrage l'ajout de nos règles iptables. Pour cela on peut déjà se créer un répertoire fw/ quelque part et y faire:
iptables-save > iptables.rules
qu'on pourra restituer avec :
iptables-restore < iptables.rules
Rendons cela automatique au demarrage. On copie les règles à un emplacement idoine:
mkdir /usr/local/etc/fw cp iptables-save /usr/local/etc/fw
Dans /etc/network/interfaces on ajoute:
iface eth0:0 inet static
address 192.168.50.1
netmask 255.255.255.0
network 192.168.50.0
broadcast 192.168.50.255
pre-up /etc/network/if-pre-up.d/gateway-start.sh
#pre-down /etc/network/if-post-down.d/gateway-stop.sh
Et on crée le script de démarrage. Dans /etc/network/if-pre-up.d/, gateway-start.sh contient:
#!/bin/bash # # Mise en place des iptables pour transformer # le serveur "principal" en passerelle pour # les v-servers en adresse privee # (/!\ necessite l'ip forwarding actif) # ---> il faudrait tout passer dans un firewall!! (flusher, bof?) # # Creation des regles de translation d'adresse /sbin/iptables -F /sbin/iptables -t nat -F ## on configure à partir des regles sauvegardees iptables-restore < /usr/local/etc/fw/iptables.rules
Spécialisation des demons et services, par serveur
Je crois comprendre que le réseau est un service partagé entre les vservers. Il convient, dans chacun des serveurs, de limiter son utilisation par adresse allouée.
Commençons par le faire sur le serveur hôte pour le service ssh, il conviendra ensuite de le faire pour chacun des serveurs et pour chaque service que l'on veut utiliser. Dans le fichier /etc/ssh/sshd_config il faut ajouter la ligne:
ListenAddress 88.191.51.247
on peut aussi ajouter:
ListenAddress 192.168.44.1
Une installation d'un vserver avec une distribution debian
Revenons à l'installation des serveurs virtuels eux-mêmes.
Juste un détail: bien évidemment, on a tâtonné bien plus que ne le montre ce tutoriel... En particulier, à un moment où un autre, les ajouts d'alias de cartes réseau généraient des choses étranges, ça s'est résolu en redémarrant le seurveur hôte, je ne sais pluss si à ce stade, ou après l'un des prochaines étables. Si ça déraille, essaye! cela vaut la peine de redémarrer de temps en temps. Et dans tous les cas, il faut redémarrer à la fin de l'install, si ce n'est le seurveur complet pour s'assurer que tout 'monte' bien, du moins chacun des services qu'on a configurés pour éviter qu'ils ne s'emmêlent les pédales à la rotation de logs suivante...
L'outillage debian est, paraît-il obsolète, en particulier la commande: newvserver
Donc on reprend:
vserver killa build --hostname killa.belvil.net --interface eth0:192.168.44.44/24 -m dbootstrap -- -d etch
... mais en fait, là, en ayant monté toutes nos partitions, la commande échoue. Zut... La seule manière que je trouve est de démonter les partitions, laisser la commande créer le serveur, et ensuite copier les données:
umount /dev/md5 umount /dev/md4
je relance la commande après.
Là normalement, tu as un serveur opérationnel. Entres dans le serveur:
vserver killa enter
configure le serveur ssh pour qu'il écoute sur la bonne adresse IP. Dans le fichier /etc/ssh/sshd_config il faut ajouter la ligne:
ListenAddress 192.168.44.44
Démarre ou redémarre ssh:
/etc/init.d/ssh restart
Tu peux alors sortir de ton serveur (exit) et y entrer directement en ssh. Depuis le serveur hôte:
ssh user@192.168.44.44
Ou depuis n'importe où sur internet:
ssh root@88.191.xxx.xxx
Il sera préférable de définir des noms de domaine différents par serveur virtuel qui résolvent sur l'adresse publique du serveur hôte. Mieux encore, on pourrait attribuer différentes adresses IP publiques par serveur, mais nous allons essayer de nous débrouiller avec une seule adresse IP.
Voilà où on en est pour l'instant.
Démarrage des serveurs virtuels au boot
Dans l'anciennee méthode de configuration, on aurait réuni tous les paramètres dans un seul fichier /etc/vservers/killa.conf. Dans la nouvelle méthode, les paramètres dont dans différents fichiers de l'arborescence de répertoires sous /etc/vservers/killa/
La construction du vserver y place déjà bon nombre de paramètres (fouille un peu ;-) et on peut en rajouter. Par exemple, si on veut que le serveur démarre automatiquement au boot du serveur hôte, on ajoute:
echo "default" > /etc/vservers/killa/apps/init/mark
Fais un essai de redémarrage. Dans le serveur hôte:
reboot
L'ensemble de l'arborescence du répertoire /etc/vservers est décrite dans la page de la grande fleur.
Et la suite
On essaie maintenant de configurer plusieurs serveurs virtuels avec des rôles ou des attributions spéifiques.
Un serveur fera office de DMZ, assurant la passerelle entrante et sortante pour les différents services présents sur de nombreux serveurs, tels:
- un reverse proxy qui discriminera par hôtes virtuels Apache (VirtualHosts) vers quels serverus vierutels adresser la requête web.
- une passerelle de mail, avec antivirus et antispam, et un relais par domaine vers des serverus virtuels.
Un autre serveur virituel remplacera belvil.net et un autre bellinux.net
Tu peux te référe à ce tutoriel
Quelques tips pour les vservers
L'installation du bind de la distribution debian pose problème: il a besoin de 'capabilities' noyau non disponibles dans un vserver. Il faut le remplacer par une version différement compilée, comme celle disponible ici: http://debian.home-dn.net/
Attention: si vous avez installé une version debian de bind, il faudra la desinstaller totalement, car la référence aux capabilites subsiste dans des fichiers de configuration (comme les scripts de /etc/initd):
apt-get --purge remove bind9
