Bartounet's Blog

Voilà un petit moment que j’entend parler d’alternative à Apache.
Les articles sur la toile parlent de plus en plus d’un petit nouveau qui est cherokee.

Sans faire un benchmark détaillé, j’ai voulu savoir ce que donnait ce nouveau serveur Web avec une configuration par défaut.
La plupart des serveurs Web des blogger, sont configurés par défauts ou très peu d’options ont été modifiées.
C’est pourquoi j’ai voulu savoir si Cherokee n’était pas trop ridicule face au géant Apache.

Pour faire mes tests, j’ai voulu mettre les serveur sur un pied d’égalité.
J’ai donc crée 2 Machine virtuelles KVM.

Vm Apache2 :
2 Vcpus
512 Mo ram
Disk Logical Volume LVM2 8Go
VIRTIO drivers
OS= Ubuntu Server 9.10 X86_64 uptodate

Vm Cherokee:
2 Vcpus
512 Mo ram
Disk Logical Volume LVM2 8Go
VIRTIO drivers
OS= Ubuntu Server 9.10 X86_64 uptodate

Les deux OS sont rigoureusement identique, puisque c’est un template que j’ai redescendu sur les 2. Les 2 sytèmes sont des copies conformes.

Si ca vous interesse voilà la ligne de commande KVM.

kvm -m 512 -smp 2 -net nic,macaddr=00:16:3a:00:00:02,model=virtio -net tap -drive if=virtio,cache=none,format=raw,media=disk -hda /dev/vg0/kvm -vnc :2 -k fr -localtime -daemonize

Installation de Cherokee sur le serveur 1
apt-get install cherokee
libcherokee-mod-admin
Cela suffit, je ne fais pas de paramétrage.

On obtien donc la version de cherokee contenu dans Karmic
root@ubuntukvm:~# cherokee --version
Cherokee Web Server 0.99.19

Installation de apache2 sur le serveur 2
apt-get install apache2
Cela suffit, je ne fais pas de paramétrage.

On obtien donc la version de Apache2 contenu dans Karmic
root@ubuntukvm:~# apache2 -v
Server version: Apache/2.2.12 (Ubuntu)

Nos 2 serveurs sont installés, l’un avec cherokee 0.99.19 l’autre avec apache 2.2.12

Afin de tester les performances des deux serveurs web avec leur configuration par défaut, je vais utiliser l’utilitaire ab (apache benchmark)

A partir d’un autre poste de mon réseau, j’installe la suite d’outils pour faire les bench.

Avant de commencer, chose importante, je copie le fichier /var/www/index.html du serveur apache, sur le serveur Cherokee.
En effet, la page par défaut de cherokee est beaucoup plus lourde que celle d’apache, si bien que cela aurait faussé nos résultas.

Commencons par le serveur Apache2 (ip=10.0.0.206)

root@laptop:/home/bartounet# ab -n 10000 -c 30 http://10.0.0.206/index.html

Explications des options de ab :
-n Nombre total de requêtes envoyées
-c Nombre de requêtes envoyées en parallèle
-H permet de modifier les entêtes http ce qui permet par exemple d’indiquer au serveur http que apachebench supporte la compression gz.

J’utilise pour des tests rapides les paramètres suivant :
-n 1000 -c 20
Pour des tests lourds :
-n 5000 -c 50
Enfin pour avoir des tests vraiment significatifs :
-n 50000 -c 30
En augmentant massivement le nombre de requêtes on obtient une moyenne du nombre de requêtes par seconde beaucoup plus significative.
( sources:http://dev.petitchevalroux.net/linux/tester-son-serveur-http-linux.159.html)

Voiçi les résultats pour Apache2

Server Software: Apache/2.2.12
Server Hostname: 10.0.0.206
Server Port: 80

Document Path: /index.html
Document Length: 177 bytes

Concurrency Level: 30
Time taken for tests: 19.476 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 4520000 bytes
HTML transferred: 1770000 bytes
Requests per second: 513.45 [#/sec] (mean)
Time per request: 58.428 [ms] (mean)
Time per request: 1.948 [ms] (mean, across all concurrent requests)
Transfer rate: 226.64 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 22 46.1 21 3022
Processing: 2 35 79.0 23 1588
Waiting: 2 33 73.6 23 1568
Total: 5 58 92.4 45 3045

Percentage of the requests served within a certain time (ms)
50% 45
66% 47
75% 48
80% 49
90% 70
95% 135
98% 302
99% 337
100% 3045 (longest request)

Testons maintenant le serveur Cherokee ( ip=10.0.0.204)

root@laptop:/home/bartounet# ab -n 10000 -c 30 http://10.0.0.204/index.html

Voiçi sans plus tarder les résultats:

Server Software: Cherokee/0.99.19
Server Hostname: 10.0.0.204
Server Port: 80

Document Path: /index.html
Document Length: 177 bytes

Concurrency Level: 30
Time taken for tests: 17.133 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 3890000 bytes
HTML transferred: 1770000 bytes
Requests per second: 583.68 [#/sec] (mean)
Time per request: 51.398 [ms] (mean)
Time per request: 1.713 [ms] (mean, across all concurrent requests)
Transfer rate: 221.73 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 27 158.5 18 3025
Processing: 2 24 33.0 20 488
Waiting: 2 23 28.4 19 466
Total: 10 51 161.9 39 3046

Percentage of the requests served within a certain time (ms)
50% 39
66% 42
75% 44
80% 46
90% 49
95% 68
98% 149
99% 307
100% 3046 (longest request)

Déjà à première vue sur ce test, cherokee est plus véloce qu’apache.

Passons au test siege.
Ici les options signifie :

-c : nombre d’utilisateurs
-r : nombre de connexion par chaque utilisateur
-d : délai en seconde de sleep

Ainsi, en lançant siege avec de tels paramètres, je simule la connexion de 100 utilisateurs, exécutant chacun 300 requêtes, espacé de une seconde. Ce qui fait à peu près 30 000 requêtes. ( cf: http://www.tux-planet.fr/benchmark-sur-un-serveur-apache/)

Pour le server cherokee

siege -d1 -r300 -c100 http://10.0.0.204/index.html

Les résultats:

Transactions: 30000 hits
Availability: 100.00 %
Elapsed time: 178.66 secs
Data transferred: 5.06 MB
Response time: 0.02 secs
Transaction rate: 167.92 trans/sec
Throughput: 0.03 MB/sec
Concurrency: 3.28
Successful transactions: 30000
Failed transactions: 0
Longest transaction: 3.03
Shortest transaction: 0.00

Pour apache2 voiçi les résultats:

Transactions: 30000 hits
Availability: 100.00 %
Elapsed time: 187.62 secs
Data transferred: 4.18 MB
Response time: 0.05 secs
Transaction rate: 159.90 trans/sec
Throughput: 0.02 MB/sec
Concurrency: 8.28
Successful transactions: 30000
Failed transactions: 0
Longest transaction: 3.07
Shortest transaction: 0.00

Encore une fois cherokee est plus véloce.

Quand j’aurai le temps de continuerai ce billet en tester les 2 serveurs sur des grosses pages php, telles ques wordpress ou dotclear avec une base Mysql.

Encore une fois je le répète mes tests sont réalisés avec les confurations de Cherokee et d’Apache2 par défaut
Les connaisseurs de l’un ou l’autre des serveurs auront tôt fait de critiquer ces résultats, et ils auront raison car les améliorations que l’ont peut apporter sont nombreuses.

En tous cas, on ne peut pas nier que sur une page html statique légère avec les config par défauts, Cherokee est sensiblement plus performant que Apache.

Juste un petit post pour montrer en quelques lignes les différences d’éfficacités et de rapidité des outils de compressions sous Gnu/Linux

Je fais ce post car j’ai cherché un moment un outil de compréssion qui me permettrait de faire passer mes 700Go de backup dans la nuit. On trouve peu de site sur le net qui disent clairement quel outil utiliser.

Je vais comparer gzip, bzip2, zip, lzop

Mon premier test raest simple , je cherche pour l’instant à faire un test de rapidité.
je compresse un logical volume de 2Go rempli d’environ 10% de données aléatoires et du vide.

-GZIP

dd if=/dev/vg0/testlv bs=1M | gzip –fast | dd of=/root/test.gz bs=1M
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 52.2422 s, 41.1 MB/s
0+8870 records in
0+8870 records out
146155226 bytes (146 MB) copied, 52.2431 s, 2.8 MB/s

la compression à été réalisée en 52.24s avec un taux de compression de 92,87%

************

-BZIP2

# dd if=/dev/vg0/testlv bs=1M | bzip2 –fast | dd of=/root/test.bz2 bs=1M
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 100.699 s, 21.3 MB/s
0+23402 records in
0+23402 records out
138479304 bytes (138 MB) copied, 100.664 s, 1.4 MB/s

la compression à été réalisée en 100.66s avec un taux de compression de 93,26%

***************

-ZIP

t# dd if=/dev/vg0/testlv bs=1M | zip -1 | dd of=/root/test.zip bs=1M
adding: -2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 52.4479 s, 40.9 MB/s
(deflated 93%)
3+3891 records in
3+3891 records out
146155352 bytes (146 MB) copied, 52.4466 s, 2.8 MB/s

la compression à été réalisée en -52.44s avec un taux de compression de 92,87%

************

-LZOP

# dd if=/dev/vg0/testlv bs=1M | lzop –fast | dd of=/root/test.lz bs=1M
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 41.1209 s, 52.2 MB/s
1+7872 records in
1+7872 records out
145436530 bytes (145 MB) copied, 41.1216 s, 3.5 MB/s

la compression à été réalisée en 41.12s avec un taux de compression de 92,91%

Comme on peut le constater lzop est largement plus rapide c’est pourquoi je l’ai choisi, pour réaliser mes backups, sachant que mon facteur limitant etait le temps et non la volumétrie disque…

En revanche ceux qui veulent privilégier l’espace de stockage au détriment de la rapidité s’orienteront plutot vers bzip2

Je disposais depuis un bon moment d’un serveur Dédibox V2.
Ce serveur était vieillissant et très chargé.
Il hebergeait mon blog, mon site perso, un serveur de messagerie, un serveur DNS, un serveur Teamspeak, Jabber et j’en oublie surement.
J’ai donc décidé de migrer sur un serveur plus puissant et de virtualiser l’ensemble.

je me suis tourné vers un serveur Kimsuffi 750G ( 4 Q6600 4x 2.40+ GHz 4 Go et 750Go hdd).
Un serveur largement dimensionné pour remplacer ma dédibox mais qui me permettra de faire pas mal de tests et de provisionner plusieurs serveurs virtuels.

J’ai donc décidé d’installer un serveur Xen ( Dom0 Opensuse 11.1) et d’éclater mon serveur dédibox en 4 Machines virtuelles paravirtualisées sous Ubuntu Server 9.10 64 bits.
J’ai faits ce choix, car j’ai quelques compétences sous Xen et Suse LInux Enterprise mais par contre je préfère administrer des serveurs Ubuntu.

Voiçi un court résumé de mon infra
Excusez moi pour le schéma j’ai pas trop l’habitude de Dia

Commençons par le début:
Sachant que kimsufi ne propose pas par défaut une installation d’OS qui me convenait, j’ai décidé d’installer moi même une Opensuse11.1.
Premier problème ovh a fait le choix d’utiliser encore LILO comme gestionnaire d’armocage..
j’ai donc dut très vite réinstaller un grub afin de pouvoir me lancer dans la net install d’opensuse.

je ne vais pas réécrire ce que j’ai déjà mis dans ce blog. je vous invite à me relire ici.
http://blog.info16.fr/?p=10

Une fois grub installé on peut se lancer dans une net install d’openSuse. Même chose, j’ai déjà écris un article sur la question.
http://blog.info16.fr/?p=31

Durant l’installation pas de problème particulier.
J’ai opté pour le partitionnement suivant:
/boot –> 128 Mo (ext3)
/ –> 16Go (xfs)
swap –>2Go
LVM2 pour le reste ( lvm servira a faire des periphériques blocs pour les DomU) (680Go)

J’ai installé Xen directement, lors du choix des softwares durant l’install.
Je ne m’étend pas trop sur l’installation d’openSuse qui reste sommes toutes assez simple.

Une fois l’installation terminée, n’oubliez pas de paramétrer votre grub pour qu’il boot par défaut sous Xen.

# Modified by YaST2. Last modification on Mon Nov 23 09:55:28 CET 2009
default 0
timeout 8
##YaST – generic_mbr
gfxmenu (hd0,0)/message
##YaST – activate

###Don’t change this comment – YaST2 identifier: Original name: xen###
title Xen — openSUSE 11.1 – 2.6.27.37-0.1
root (hd0,0)
kernel /xen.gz
module /vmlinuz-2.6.27.37-0.1-xen root=/dev/disk/by-id/ata-ST3750640AS_5QD16XRN-part2 resume=/dev/disk/by-id/ata-ST3750640AS_5QD16XRN-part3 splash=silent showopts
module /initrd-2.6.27.37-0.1-xen

###Don’t change this comment – YaST2 identifier: Original name: linux###
title openSUSE 11.1 – 2.6.27.37-0.1
root (hd0,0)
kernel /vmlinuz-2.6.27.37-0.1-default root=/dev/disk/by-id/ata-ST3750640AS_5QD16XRN-part2 resume=/dev/disk/by-id/ata-ST3750640AS_5QD16XRN-part3 splash=silent showopts
initrd /initrd-2.6.27.37-0.1-default

###Don’t change this comment – YaST2 identifier: Original name: failsafe###
title Failsafe — openSUSE 11.1 – 2.6.27.37-0.1
root (hd0,0)
kernel /vmlinuz-2.6.27.37-0.1-default root=/dev/disk/by-id/ata-ST3750640AS_5QD16XRN-part2 showopts ide=nodma apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 x11failsafe
initrd /initrd-2.6.27.37-0.1-default

Une fois rebooté sous Xen il faut commencer par quelques petites modifications.

Tous d’abord je souhaite faire du NAT. En effet n’ayant qu’une adresse IP publique sur ma kimsufi, je dois configurer mes domU avec des ip locale et faire du nat pour qu’elles accèdent à l’exterieur.

Pour commencer, paramétrons Xen pour faire du Nat.
Tout se passe dans le fichier /etc/xen/xend-config.sxp

Pour se faire, changeons les éléments suivants.

(network-script network-nat)

# If you are using only one bridge, the vif-bridge script will discover that,
# so there is no need to specify it explicitly.
#
(vif-script ‘vif-bridge bridge=br0′)

# enable-dom0-ballooning below) and for xm mem-set when applied to dom0.
(dom0-min-mem 512)

# Whether to enable auto-ballooning of dom0 to allow domUs to be created.
# If enable-dom0-ballooning = no, dom0 will never balloon out.
(enable-dom0-ballooning yes)

# In SMP system, dom0 will use dom0-cpus # of CPUS
# If dom0-cpus = 0, dom0 will take all cpus available
(dom0-cpus 0)

# set this to 0.0.0.0
(vnc-listen ‘0.0.0.0′)

# The default password for VNC console on HVM domain.
# Empty string is no authentication.
(vncpasswd  »)

On peut remarquer que j’utilise le script: {network-script network-nat}
Mais par contre j’utilise (vif-script ‘vif-bridge bridge=br0′)

Il faut bien distinguer 2 choses:
- network-script est un script lancé par Xen au démarrage du daemon Xen.
Donc en mettant network-nat, il va mettre en place les règles nat (ip-forwarding, masquerade etc..) necessaires.

-vif-script est le script qui va etre lancé au demarrage des domU. et qui va décider comment va être relié les interfaces réseaux des domU et du Dom0.

Pour ma part j’ai décidé de creer un bridge ( switch virtuel) nommé br0 avec une ip en 192.168.1.254/24 et grace vif-bridge, toutes les interface de mes DomU vont s’attacher à ce bridge.

Pour creer ce fameux bridge on peut utiliser les fichiers directement dans /etc/sysconfig/network, mais le plus simple reste de passer par yast.

On redemarre Xen , on peut vérifier nos deux interfaces réseaux.

linux:~ # ifconfig
br0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet addr:192.168.1.254 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::3c8b:16ff:fe67:b2b7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:425920 errors:0 dropped:0 overruns:0 frame:0
TX packets:476880 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:143058546 (136.4 Mb) TX bytes:233932702 (223.0 Mb)

eth0 Link encap:Ethernet HWaddr 00:1C:C0:FD:69:A3
inet addr:94.x.x.21 Bcast:94.23.236.255 Mask:255.255.255.0
inet6 addr: fe80::21c:c0ff:fefd:69a3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5211844 errors:0 dropped:0 overruns:0 frame:0
TX packets:9516144 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:568921568 (542.5 Mb) TX bytes:13470776595 (12846.7 Mb)
Interrupt:252 Base address:0xc000

Le plus dur reste à faire. préparer notre template de DomU qui nous servira d’image pour toutes nos machines virtuelles.

Tout d’abord la première chose à faire est de récupérer les images iso des distributions que nous allons installer. Pour ma part j’ai opté pour Ubuntu server 9.10 x64 et Opensuse11.1 x64
Les isos sont très vite téléchargées puisque nous avons 100Mbits de bande passante entre le serveur et le net.

Petit rappel il y a deux types de DomU:
Les HVM: Le système va etre totalement émulé et n’est pas conscient d’etre sur un systeme de virtualisation. C’est le plus simple à mettre en place mais le moins performant.

La paravirtualisation: La paravirtualisation permet aux moniteurs de machines virtuelles (MMV) d’être plus simples et aux machines virtuelles fonctionnant dessus d’atteindre un niveau de performance proche du matériel réel. Cependant, les systèmes d’exploitations doivent explicitement être portés afin de fonctionner sur des MMV paravirtualisées. (cf wikipedia)
autrement dit les domU paravirtualisés sont conscients d’etre virtualisés et sont modifiés pour cela. ( Kernel compilé avec les extensions Xen, et drivers block et réseau ). Ce mode est le plus performant.

Pour commencer il faut installer le DomU en HVM.
Je commence par creer le périphérique block qui va héberger la VM.
J’utilise pour cela la souplesse de lvm2.
Mon premier domU sera sur /dev/vg0/lv0 de 16Go

lvcreate -L16G -nlv0 vg0

Je crée un fichier de domU dans /etc/xen/vm

######VM PARAM####
name= »wwwinfo16″
ostype= »linux »
memory=512
vcpus=2
cpu_weight=256
cpu_cap=0
hap=1
apic=1
acpi=1
pae=1
stdvga=0
usb=1
usbdevice= »tablet »
serial= »pty »
timer_mode=1
localtime=1
extid=0
on_crash= »restart »
on_reboot= »restart »
on_poweroff= »destroy »
######HVM#########
builder= »hvm »
device_model= »/usr/lib64/xen/bin/qemu-dm »
kernel= »/usr/lib/xen/boot/hvmloader »
######PVM#########
#builder= »linux »
#bootloader = ‘/usr/lib/xen/boot/domUloader.py’
#bootargs = ‘–entry=hda1:/vmlinuz-xen,/initrd-xen’
#extra= »root=/dev/hda2 vga=0×31a console=tty0″
######DEV#########
vfb=[ 'type=vnc,vncunused=1', ]
disk=[ 'phy:/dev/vg0/lv0,hda,w', 'file:/sotck/ubuntu-9.10.iso,hdc:cdrom,r', ]
vif=[ 'type=ioemu,mac=00:16:3a:11:11:00', ]
boot= »c

J’utilise ce fichier très pratique qui me permet de basculer de hvm en para très facilement en commentant la section HVM ou PVM
On peut regler aussi facilement le nombre de Vcpus, Memoire, disk etc…

On lance alors le domU avec

xm create domU

Si tout se passe bien vous pouvez acceder à l’installation de votre domU directement par vnc.
Le premier domU s’attache au port 5900 le deuxieme au 5901 etc…

Pour le premier domU je peux y acceder par
ippublique:5900

Je ne vais pas détailler l’installation d’un DomU qui est une installation basique.

Une fois installé vous pouvez rebooter votre DomU et profiter de votre serveur en HVM.
J’ai commencé à paramétrer le réseau de mon domU en lui mettant comme ip 192.168.1.1/24 et la passerelle 192.168.1.254 (br0) et comme DNS, le dns de la kimsuffi.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.254
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 213.186.33.99

Cette installation en HVM est valable aussi bien pour un DomU OpenSuse que pour Ubuntu.

C’est sympa de jouer avec les hvm, mais très vite on se rend compte que les performances ne sont pas au rendez vous. en effet les accès disques et réseau consomment énormément de ressources.
Il faut vite passer à la paravirtualisation.

Je suis obligé de scinder ce chapitre en 2 parties:
DomU paravirtualisés sous OpenSuse
DomU paravirtualisés sous Ubuntu/Debian

DomU para OpenSuse11.1

Pour que opensuse puisse etre utilisé en tant que DomU para, il faut installer simplement le kernel-xen, kernel-xen-base, kernel-xen-extra.
Modifier votre grub pour booter sur le kernel Xen et surtout modifier votre fichier de configuration de la vm

######VM PARAM####
name= »wwwinfo16″
ostype= »linux »
memory=512
vcpus=2
cpu_weight=256
cpu_cap=0
hap=1
apic=1
acpi=1
pae=1
stdvga=0
usb=1
usbdevice= »tablet »
serial= »pty »
timer_mode=1
localtime=1
extid=0
on_crash= »restart »
on_reboot= »restart »
on_poweroff= »destroy »
######HVM#########
#builder= »hvm »
#device_model= »/usr/lib64/xen/bin/qemu-dm »
#kernel= »/usr/lib/xen/boot/hvmloader »
######PVM#########
builder= »linux »
bootloader = ‘/usr/lib/xen/boot/domUloader.py’
bootargs = ‘–entry=hda1:/vmlinuz-xen,/initrd-xen’
extra= »root=/dev/hda2 vga=0×31a console=tty0″
######DEV#########
vfb=[ 'type=vnc,vncunused=1', ]
disk=[ 'phy:/dev/vg0/lv0,hda,w', ]
vif=[ 'type=netfront,mac=00:16:3a:11:11:00', ]
boot= »c »

On remarque que j’ai commenté cette fois ci les parametre HVM et décommenté PVM. j’ai aussi ajouté netfront comme type de care réseau.
Ces lignes sont aussi très importantes:
bootargs = ‘–entry=hda1:/vmlinuz-xen,/initrd-xen’ = partition du DomU sur laquelle se trouve votre kernel (/boot) pour moi hda1
extra= »root=/dev/hda2 vga=0×31a console=tty0″ = partition du DomU sur laquelle se trouve votre / pour moi hda2

Faire bien attention que dans /boot dans le domU les liens symbolique
vmlinuz-xen et initrd-xen soit bien créer et pointent bien vers le kernel xen

opensuse11-1:/boot # ls -al
total 25820
drwxr-xr-x 3 root root 4096 2009-11-23 13:52 .
drwxr-xr-x 20 root root 4096 2009-11-28 00:28 ..
-rw——- 1 root root 512 2009-01-06 16:44 backup_mbr
lrwxrwxrwx 1 root root 1 2009-01-06 16:14 boot -> .
-rw-r–r– 1 root root 1236 2009-01-08 02:03 boot.readme
-rw-r–r– 1 root root 90278 2009-10-16 18:29 config-2.6.27.37-0.1-default
-rw-r–r– 1 root root 88176 2009-10-16 17:36 config-2.6.27.37-0.1-xen
drwxr-xr-x 2 root root 4096 2009-11-23 13:53 grub
lrwxrwxrwx 1 root root 28 2009-11-23 13:52 initrd -> initrd-2.6.27.37-0.1-default
-rw-r–r– 1 root root 5626357 2009-11-23 13:52 initrd-2.6.27.37-0.1-default
-rw-r–r– 1 root root 5584838 2009-11-23 13:53 initrd-2.6.27.37-0.1-xen
lrwxrwxrwx 1 root root 24 2009-11-23 13:52 initrd-xen -> initrd-2.6.27.37-0.1-xen
-rw-r–r– 1 root root 442880 2009-01-14 15:33 message
-rw-r–r– 1 root root 157239 2009-10-16 18:45 symsets-2.6.27.37-0.1-default.tar.gz
-rw-r–r– 1 root root 162088 2009-10-16 17:38 symsets-2.6.27.37-0.1-xen.tar.gz
-rw-r–r– 1 root root 406110 2009-10-16 18:43 symtypes-2.6.27.37-0.1-default.gz
-rw-r–r– 1 root root 402218 2009-10-16 17:37 symtypes-2.6.27.37-0.1-xen.gz
-rw-r–r– 1 root root 119804 2009-10-16 18:32 symvers-2.6.27.37-0.1-default.gz
-rw-r–r– 1 root root 119842 2009-10-16 17:37 symvers-2.6.27.37-0.1-xen.gz
-rw-r–r– 1 root root 1423318 2009-10-16 18:05 System.map-2.6.27.37-0.1-default
-rw-r–r– 1 root root 1287397 2009-10-16 17:31 System.map-2.6.27.37-0.1-xen
-rw-r–r– 1 root root 3009484 2009-10-16 18:29 vmlinux-2.6.27.37-0.1-default.gz
-rw-r–r– 1 root root 2681140 2009-10-16 17:36 vmlinux-2.6.27.37-0.1-xen.gz
lrwxrwxrwx 1 root root 29 2009-11-23 13:52 vmlinuz -> vmlinuz-2.6.27.37-0.1-default
-rw-r–r– 1 root root 2541344 2009-10-16 18:05 vmlinuz-2.6.27.37-0.1-default
-rw-r–r– 1 root root 2235478 2009-10-16 17:31 vmlinuz-2.6.27.37-0.1-xen
lrwxrwxrwx 1 root root 25 2009-11-23 13:52 vmlinuz-xen -> vmlinuz-2.6.27.37-0.1-xen

On lance le domU:

L’installation d’un domU Opensuse11-1 para sur un DomU Opensuse11-1 est assez simple.

DomU para Ubuntu Server 9.10

Après de longues heures de recherche, j’ai enfin réussi à faire booter un serveur Ubuntu en paravirtualisé.
Le kernel ubuntu depuis le 2.6.28 etant très peu modifié du kernel Vanilla, il possède en natif les options Xen directement déjà compilé dans le kernel.
De plus on remarque que les pilotes block et réseau de Xen sont aussi présents dans les modules de ubuntu 9.10.

root@bartounet:/# grep -r xen /lib/modules/2.6.31-14-generic/kernel/ | grep front
Binary file /lib/modules/2.6.31-14-generic/kernel/drivers/block/xen-blkfront.ko matches
Binary file /lib/modules/2.6.31-14-generic/kernel/drivers/net/xen-netfront.ko matches

On a donc en natif tout pour faire un DomU paravirtualisé. les options de kernel et les modules.

Commencer par installer votre ubuntu en hvm comme vu plus haut.
une fois le DomU booté en HVM aller tout de suite dans le fstab et modifier les noms de vos disques par /dev/xvd*

Voiçi le fstab modifié:

# /etc/fstab: static file system information.
#
# Use ‘blkid -o value -s UUID’ to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# proc /proc proc defaults 0 0
# / was on /dev/sda2 during installation
/dev/xvda2 / ext4 defaults 0 1
# /boot was on /dev/sda1 during installation
/dev/xvda1 /boot ext3 defaults 0 2
# swap was on /dev/sda3 during installation
/dev/xvda3 none swap sw 0 0
/dev/xvdb1 /home xfs defaults 0 0
/dev/xvdb /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0

j’ai remplacé les occurences de hd en xvd ( /dev/hda1 = /dev/xvda1) etc…

important, n’oubliez pas de creer des liens symbolique pointant vers le kernel en rapport avec votre fichier de conf de domu ( vmlinuz-xen et initrd-xen) mais rien de vous empeche aussi d’indiquer directement le nom complet du kernel dans le fichier de domU

root@wwwinfo16:~# ls -al /boot/ | grep xen
lrwxrwxrwx 1 root root 27 2009-11-25 12:33 initrd-xen -> initrd.img-2.6.31-14-server
lrwxrwxrwx 1 root root 24 2009-11-25 12:33 vmlinuz-xen -> vmlinuz-2.6.31-14-server

Quelques modifications sont à apporter à notre fichier de conf du domU:

linux:~ # vi /etc/xen/vm/wwwinfo16
######VM PARAM####
name= »wwwinfo16″
ostype= »linux »
memory=512
vcpus=2
cpu_weight=256
cpu_cap=0
hap=1
apic=1
acpi=1
pae=1
stdvga=0
usb=1
usbdevice= »tablet »
serial= »pty »
timer_mode=1
localtime=1
extid=0
on_crash= »restart »
on_reboot= »restart »
on_poweroff= »destroy »
######HVM#########
#builder= »hvm »
#device_model= »/usr/lib64/xen/bin/qemu-dm »
#kernel= »/usr/lib/xen/boot/hvmloader »
######PVM#########
builder= »linux »
bootloader = ‘/usr/lib/xen/boot/domUloader.py’
bootargs = ‘–entry=xvda1:/vmlinuz-xen,/initrd-xen’
extra= »root=/dev/xvda2 vga=0×31a console=tty0″
######DEV#########
vfb=[ 'type=vnc,vncunused=1', ]
disk=[ 'phy:/dev/vg0/lv0,xvda,w', ]
vif=[ 'type=netfront,mac=00:16:3a:11:11:00', ]
boot= »c »

Dans le fichiers de conf on modifie aussi les /dev/hda en /dev/xvda
Dans les options de kernel, mais aussi dans les options de disk.
Si vous définissez un lecteur CD-Rom n’oubliez pas non plus de le declarer en xvdc, sinon ça ne bootera pas.

si tout se passe bien relancer votre DomU Ubuntu et il devrait booter.
un petit lspci ne retourne rien, vous êtes bien en paravirtualisé.
Regardez les modules chargés au démarrage sur le domU.

root@wwwinfo16:~# lsmod | grep xen
xen_fbfront 10112 1
fb_sys_fops 2304 1 xen_fbfront
sysimgblt 3168 1 xen_fbfront
sysfillrect 4576 1 xen_fbfront
xen_kbdfront 6176 0
syscopyarea 4224 1 xen_fbfront
xen_netfront 21696 0
xen_blkfront 14340 6

netfront et blkfront sont bien chargés… nous sommes en para.

Un petit test de débit réseau entre le domU et le dom0 finirons ne vous en convaincre..

root@wwwinfo16:/home/ftpuser/anonymous# iperf -w512k -c192.168.1.254 -P2
————————————————————
Client connecting to 192.168.1.254, TCP port 5001
TCP window size: 256 KByte (WARNING: requested 512 KByte)
————————————————————
[ 4] local 192.168.1.1 port 34407 connected with 192.168.1.254 port 5001
[ 3] local 192.168.1.1 port 34406 connected with 192.168.1.254 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 4.95 GBytes 4.25 Gbits/sec
[ 3] 0.0-10.0 sec 2.31 GBytes 1.99 Gbits/sec
[SUM] 0.0-10.0 sec 7.26 GBytes 6.24 Gbits/sec

Plus de 6 Gbits/s c’est pas mal.

Essayons entre 2 DomU Ubuntu-9.10-x86_64 paravirtualisés

root@wwwinfo16:/home/ftpuser/anonymous# iperf -w512k -c192.168.1.2 -P2
————————————————————
Client connecting to 192.168.1.2, TCP port 5001
TCP window size: 256 KByte (WARNING: requested 512 KByte)
————————————————————
[ 4] local 192.168.1.1 port 49034 connected with 192.168.1.2 port 5001
[ 3] local 192.168.1.1 port 49033 connected with 192.168.1.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 3.31 GBytes 2.84 Gbits/sec
[ 3] 0.0-10.0 sec 3.30 GBytes 2.83 Gbits/sec
[SUM] 0.0-10.0 sec 6.61 GBytes 5.67 Gbits/sec

Nos serveurs virtuels on un débit de plus de 5Gbits/s entre eux. Ca laisse de la marge.

Je voulais finir sur le réseau.
C’est souvent ce qu’on a du mal à mettre en place quand on commence sous Xen.
Souvenez vous j’ai utilisez netwok-nat, qui configure le nat au lancement de xen et permet de faire du masquerade.
et vif-bridge bridge=br0 qui permet d’attacher les interfaces virtuelles des domU à notre bridge qui lui utilisera les parametres du kernel pour router.

Il faut savoir que quand on lance un DomU une interface réseau virtuelle est créee automatiquement.
Lorsque c’est une HVM c’est une interface tap
Lorsque c’est un para c’est une interface vif

Sur mon serveur voiçi l’exemple concret.
On peut voir sur le dom0 que j’ai 5 DomU démarrés

linux:~ # xm li
Name ID Mem VCPUs State Time(s)
Domain-0 0 2603 4 r—– 6787.6
chatinfo16 15 128 1 -b—- 28.3
mailinfo16 12 512 2 -b—- 826.7
nsinfo16 14 128 1 -b—- 19.1
susepara 17 128 1 -b—- 83.6
wwwinfo16 7 512 2 -b—- 496.8

en théorie si je dit vrai on devrait donc avoir 5 interfaces vif de créees puisque je n’utilise que des domU paravirtualisés.

Vérifions le:

linux:~ # ifconfig
br0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet addr:192.168.1.254 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::3c8b:16ff:fe67:b2b7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1205797 errors:0 dropped:0 overruns:0 frame:0
TX packets:1268662 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12752893921 (12162.1 Mb) TX bytes:326758032 (311.6 Mb)

eth0 Link encap:Ethernet HWaddr 00:1C:C0:FD:69:A3
inet addr:94.x.x.21 Bcast:94.23.236.255 Mask:255.255.255.0
inet6 addr: fe80::21c:c0ff:fefd:69a3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5321651 errors:0 dropped:0 overruns:0 frame:0
TX packets:9613762 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:621290841 (592.5 Mb) TX bytes:13509616638 (12883.7 Mb)
Interrupt:252 Base address:0xc000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:586 (586.0 b) TX bytes:586 (586.0 b)

vif7.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:1102247 errors:0 dropped:0 overruns:0 frame:0
TX packets:1068448 errors:0 dropped:7 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:26806418112 (25564.5 Mb) TX bytes:79329581 (75.6 Mb)

vif12.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:668903 errors:0 dropped:0 overruns:0 frame:0
TX packets:763612 errors:0 dropped:3 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:66913413 (63.8 Mb) TX bytes:14387030405 (13720.5 Mb)

vif14.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:4815 errors:0 dropped:0 overruns:0 frame:0
TX packets:6801 errors:0 dropped:5 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:563633 (550.4 Kb) TX bytes:1296285 (1.2 Mb)

vif15.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:11409 errors:0 dropped:0 overruns:0 frame:0
TX packets:13668 errors:0 dropped:25 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:2077063 (1.9 Mb) TX bytes:2730964 (2.6 Mb)

vif17.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:1896 errors:0 dropped:0 overruns:0 frame:0
TX packets:3768 errors:0 dropped:81 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:376026 (367.2 Kb) TX bytes:4379048 (4.1 Mb)

Pour qu’elles communiquent sur le réseau, il faut qu’elle soient reliées à mon bridge br0:
Vérifions le:

linux:~ # brctl show
bridge name bridge id STP enabled interfaces
br0 8000.feffffffffff no vif12.0
vif14.0
vif15.0
vif17.0
vif7.0

Les vifs sont bien reliées à br0.
à partir de là elle peuvent communiquer avec le reste de mon réseau.

J’oubliais de parler des règles nat.
Pour l’instant, les domU communiquent avec l’extérieur, par l’intermédiaire de leur passerelle par défaut 192.168.1.254 et du nat sur eth0.
Mais pour l’instant toutes les tentatives de connexions extérieures ( http, ftp, dns, smtp etc…) arrivent sur le dom0, il faudra donc mettre en place des règles iptables pour rediriger les ports vers les bons serveurs (domU)
Par exemple wwwinfo16 est le serveur web, il faudra donc une règle iptable du style:

##Redirection de ports pour les differents services
#######wwwinfo16
$iptables -A PREROUTING -t nat -p tcp -i eth0 –dport 80 -j DNAT –to 192.168.1.1:80

Et ceci pour tous les ports que vous voulez rediriger. C’est un peu fastidieux, mais une fois votre script de règles iptables mis en place cela fonctionne très bien.

Il reste pas mal de chose a faire, comme paramétrer des sauvegardes que je ferais en mode bloc par du simple dd et de la compression lzop. Le tout externalisé sur un ftp.
Faire un template propre pour provisioner autant de domU que je le souhaite grace à une image identique ( dd est mon amis)
Mais le projet est bien avancé, puisque vous lisez à ce jour, cet article sur mon blog qui est hebergé sur wwwinfo16, vous m’envoyez des mails par l’intermédiaire de mailinfo16, le SOA du domaine info16.fr est nsinfo16.

Voilà des jours que j’essaye de faire fonctionner CAS pour une athentification ldap avec active directory, dans un domaine Windows.
Je me fait un petit billet pour ne pas oublier.

Dejà CAS c’est quoi, c’est un outil permettant de faire du SSO.
Il s’agit d’une technique permettant à un utilisateur de ne procéder qu’à une seule authentification pour accéder à plusieurs applications informatiques sécurisées (généralement des sites Web). Souvent dans une entreprise, les utilisateurs sont amenés à s’identifier dans différentes applications (intranet, courrier électronique, forums, agendas, …). Sans solution de SSO, il est nécessaire de s’identifier dans chacune de ces applications avec souvent des identifiants différents.

Il se présente par une interface Web des plus simpliste.
Mais derriere il y a quoi ?
Il s’agit dabord d’installer Tomcat.
Pour mon exemple j’ai installer Tomcat sur une Opensuse11.1 à grand coup de Yast.

L’installation de Tomcat est assez simple avec le gestionaire de paquets, n’oublier pas d’installer le manager et les webapps.

Tomcat se base sur Java, vérifiez bien votre version de java.
si tout c’est bien déroulé, vous devriez avoir accès à tomcat sur

http://votre_server:8080

Afin de pouvoir acceder au manager, il faut creer un compte admin dans le fichier tomcat-users.xml

Sur OpenSuse 11.1 l’installation de Tomcat6 se trouve dans /usr/share/tomcat6

On a donc dans /usr/share/tomcat6/conf/ tomcat-users.xml

<tomcat-users>

<role rolename= »tomcat »/>
<role rolename= »role1″/>
<user username= »tomcat » password= »tomcat » roles= »tomcat »/>
<user username= »both » password= »tomcat » roles= »tomcat,role1″/>
<user username= »role1″ password= »tomcat » roles= »role1″/>
<user username= »admin » password= »pass » roles= »admin,manager »/>
</tomcat-users>

La dernière ligne est celle que j’ai ajoutée pour acceder au manager de tomcat.

Passons maintenant à l’installation de CAS.

Le plus important est d’utiliser CAS Toolbox, j’ai galéré des semaines avec cas-server sans succès alors que j’ai enfin abouti avec cas-toolbox.

Autrement dit c’est un cas packagé qui simplifie la configuration.
On télécharge l’archive sur le site de l’esup
https://sourcesup.cru.fr/frs/?group_id=401&release_id=1461
Pour ma part j’ai testé la 3.3.2-1
On decompresse l’archive et on commence à modifer les fichiers.

TOut d’abord les fichier qu’on va modifier sont build.properties et config.properties

# cp build.sample.properties build.properties
# cp config.sample.properties config.properties

Afin de tester j’ai rapidement monter un controleur de domaine Windows 2003 enterprise sur une machine virtuelle.
Le domaine sera maison.priv
Il est aussi necessaire de creer dans l’Active directory un user qui aura les droit d’interroger l’AD.
Mon user sera ldapview avec le mot de pass motdepasse

Passons à la configuration des ficher CAS

Voiçi le fichiers build.properties

#deploy dir

deploy.path=/usr/share/tomcat6/webapps/cas

#configuration file to use

config.file=${basedir}/config.properties

#config.file=${basedir}/resources/quickstart/quickstart.properties

#use maven dependency offline

#must run on time inline

maven.offline=false

#SVN part to get other update

svnant.update.url=http://subversion.cru.fr/cas-toolbox/tags/3.3.2-1/update.esup/

svnant.repository.user=

svnant.repository.passwd=

svnant.update.path=${basedir}/update.esup

svnant.update.version=HEAD

# do not change after this line

#package configuration

package.name=cas-toolbox

package.version=1

package.build.path=${build.path}/package

#quickstart configruation

#config.file=${basedir}/resources/quickstart/quickstart.properties

quickstart.name=cas-quickstart

quickstart.version=1

quickstart.build.path=${build.path}/quickstart

quickstart.ressource.path=${resources.path}/quickstart

#maven properties

maven.ant.task.version=2.0.9

maven.local.dir=maven-repository

maven.local.repository=${basedir}/build/${maven.local.dir}

maven.package.name=cas-maven-repository

maven.proxy.host=

maven.proxy.port=8080

maven.proxy.username=

maven.proxy.password=

update.path=${basedir}/update

#${basedir}/update.esup

#${basedir}/update.stats

#${basedir}/update.memcache

custom.path=${basedir}/custom

build.path=${basedir}/build

resources.path=${basedir}/resources

cas.build.path=${build.path}/cas

cas.update.webpage.path=${update.path}/webpages

cas.custom.webpage.path=${custom.path}/webpages

cas.update.source.path=${update.path}/source

cas.custom.source.path=${custom.path}/source

quickstart.build.path=${build.path}/quickstart

quickstart.ressource.path=${resources.path}/quickstart

simpleTestHandler.name=

simpleTestHandler.conf=simpletest-auth.xml

ldapHandler.name=cas-server-support-ldap

ldapHandler.conf=ldap-auth.xml

Le config.properties

# Ldap properties

ldap.host.1=ldap://10.0.0.153

ldap.basedn=sAMAccountName=%u,CN=Users,dc=maison,dc=priv

# file authenticate layer

passfile.encode-algo=MD5

passfile.location=classpath:/../usersFile

log.dir=${catalina.home}/logs

#cas host

cas.host=localhost

# cas uri (empty if /)

cas.uri=

# cas port empty (if standard)

cas.port=:8080

#User allow to use services manager (services/manage.html)

security.useradmin=admin

# graphic theme

theme=default

views=default

# auth layer to use

# see build.properties to view all

cas.authHandlers=ldapHandler

Modifier bien sur selon votre configuration.
Enfin on fini par creer une arborescence dans cas-toolbox-3.3.2-1
tell que cas-toolbox-3.3.2-1/custom/webpages/WEB-INF/auth-configuration/
et on va creer un fichier ldap-auth.xml
vi custom/webpages/WEB-INF/auth-configuration/ldap-auth.xml

<?xml version= »1.0″ encoding= »UTF-8″?>
<!–
| deployerConfigContext.xml centralizes into one file some of the declarative configuration that
| all CAS deployers will need to modify.
|
| This file declares some of the Spring-managed JavaBeans that make up a CAS deployment.
| The beans declared in this file are instantiated at context initialization time by the Spring
| ContextLoaderListener declared in web.xml. It finds this file because this
| file is among those declared in the context parameter « contextConfigLocation ».
|
| By far the most common change you will need to make in this file is to change the last bean
| declaration to replace the default SimpleTestUsernamePasswordAuthenticationHandler with
| one implementing your approach for authenticating usernames and passwords.
+–>
<beans xmlns= »http://www.springframework.org/schema/beans »
xmlns:xsi= »http://www.w3.org/2001/XMLSchema-instance »
xmlns:p= »http://www.springframework.org/schema/p »
xsi:schemaLocation= »http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd »>

<!–
| LDAP authentication.
+–>
<bean id= »ldapHandler » class= »org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler »>
<property name= »filter » value= »sAMAccountName=%u » />
<property name= »searchBase » value= »DC=maison,DC=priv » />
<property name= »contextSource » ref= »contextSource » />
<property name= »ignorePartialResultException » value= »yes » />
</bean>

<bean id= »contextSource » class= »org.springframework.ldap.core.support.LdapContextSource »>
<property name= »anonymousReadOnly » value= »false » />
<property name= »password » value= »motdepasse » />

<property name= »pooled » value= »true » />
<property name= »urls »>
<list>
<value>ldap://10.0.0.153:389</value>
</list>
</property>
<property name= »userDn » value= »ldapview » />
<property name= »baseEnvironmentProperties »>
<map>
<!–
<entry>
<key><value>java.naming.security.protocol</value></key>
<value>ssl</value>
</entry>
–>
<entry>
<key><value>java.naming.security.authentication</value></key>
<value>simple</value>
</entry>
</map>
</property>
</bean>
</beans>

On fini enfin en utilisant la commande ant

ant init
qui va builder cas selon votre config

ant deploy qui va aller copier les fichier cas dans le chemin que vous lui avez definit dans build.properties.

Si tout se passe bien vous devriez voir apparaitre un webbaps cas dans le manager de tomcat.
Il devrait démarrer..

et une fois authentifier avec un compte du domaine Active directory

Ca faisait un petit moment que j’en avais marre de dotclear, j’ai donc décidé de migrer l’ensemble de mes articles sous Wordpress.
Je le trouve plus convivial et plus souple.

J’ai un petit laptop Dell avec lequel j’ai beaucoup galéré. Mon but était d’installer une distribution Gnu/Linux sur ce portable, mais j’ai vite été confronté au fait qu’il n’avais ni lecteur CD ni possibilité de booter en usb.

Heureusement il est doté d’une carte réseau supportant nativement le boot par le réseau (pxe). Le but de ce billet est de me faire un petit aide mémoire pour ce type d’installation.

Pour cela il nous faut installer un serveur PXE avec tout le toutim (pxe, tftp, dhcp-server etc …) Après avoir réfléchi un peu, je me suis rappeler qu’un outil faisait cela très bien sans avoir besoin de se prendre la tête: le fameux System Rescue CD.

je m’empresse donc de télécharger la dernière version de cet outil sur le site officiel : http://www.sysresccd.org/

Pour ma part je n’ai pas gracer un CD pour cela. j’ai simplement booter le sysrescuecd a partir d’un DomU Xen. mais vous pouvez très bien le faire en gravant le CD et en bootant sur une machine physique. ou même en utilisant l’outil de virtualisation de votre choix (vmware, virtualbox, qemu et j’en passe).

Une fois le system rescue on vérifie que le serveur on active la carte réseau du serveur et on lui assigne une ip ( en fixe ou en DHCP)

root@sysresccd / % ifconfig eth0

pour ma part j’avais dejà mon serveur dhcp qui tournait.

root@sysresccd / % dhclient eth0

root@sysresccd / % ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:16:3a:11:11:01
inet addr:10.0.0.54 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::216:3aff:fe11:1101/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:52799 errors:0 dropped:0 overruns:0 frame:0
TX packets:68521 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14016982 (13.3 MiB) TX bytes:99265410 (94.6 MiB)
Interrupt:32 Base address:0×2000

Mon serveur à obtenu l’ip 10.0.0.54/24

On modifie maintenant les options su serveur pxe

root@sysresccd / % vi /etc/conf.d/pxebootsrv

# Copyright 2003-2007 Francois Dupoux – www.sysresccd.org
# Distributed under the terms of the GNU General Public License v2

# Config file for /etc/init.d/pxebootsrv
# Have a look at the PXE chapter in the official manual for more details:
# http://www.sysresccd.org/Sysresccd-manual-en_PXE_network_booting

# ————————- README ————————————
# The pxebootsrv service allows to provide a PXE-boot-server for
# SystemRescueCd out of the box. You just need to edit the following
# options and run « /etc/init.d/pxebootsrv restart », and you can boot
# any computer of your local network with PXE.
#
# You must configure these options if the current SystemRescueCd system
# acts as DHCP-server and TFTP-server and HTTP-server. If you keep this
# default behavior you just need to edit these options and start the
# service with « /etc/init.d/pxebootsrv restart ».
# If you don’t want the current system to be the DHCP server, you will have
# to configure everything by hand and it will not be possible to use
# the pxebootsrv service.

# ———————— CONFIGURATION ——————————-
# By default the current systems acts as DHCP and TFTP and HTTP server
# If you want another machine of you network to act as one of those
# you will have to turn the appropriate option yo « no »

# Set to « yes » if you want this machine to act as a DHCP server
PXEBOOTSRV_DODHCPD= »yes »
# Set to « yes » if you want this machine to act as a TFTP server
PXEBOOTSRV_DOTFTPD= »yes »
# Set to « yes » if you want this machine to act as an HTTP server
PXEBOOTSRV_DOHTTPD= »yes »

# Here is a typical PXE-Boot configuration –> update with your settings
PXEBOOTSRV_SUBNET= »10.0.0.0″ # Used only if PXEBOOTSRV_DODHCPD= »yes »
PXEBOOTSRV_NETMASK= »255.255.255.0″ # Used only if PXEBOOTSRV_DODHCPD= »yes »
PXEBOOTSRV_DEFROUTE= »10.0.0.253″ # Used only if PXEBOOTSRV_DODHCPD= »yes »
PXEBOOTSRV_DNS= »10.0.0.253″ # Used only if PXEBOOTSRV_DODHCPD= »yes »
PXEBOOTSRV_DHCPRANGE= »10.0.0.100 10.0.0.110″
PXEBOOTSRV_LOCALIP= »10.0.0.54″
# Keep these values to $PXEBOOTSRV_LOCALIP if the current computer
# acts as TFTP server and HTTP server as well as DHCP server
PXEBOOTSRV_TFTPSERVER= »$PXEBOOTSRV_LOCALIP » # IP address of the TFTP server if PXEBOOTSRV_DODHCPD= »yes »
PXEBOOTSRV_HTTPSERVER= »http://$PXEBOOTSRV_LOCALIP/sysrcd.dat » # download URL

Comme on peut le voir, j’ai modifié le fichier pour coller avec ma config réseau. Et j’ai bien défini une plage dhcp pour mes clients pxe

D’ailleurs Attention, pensez à stopper vos autres serveurs dhcp qui tourne sur votre réseau ( ou du moins sur votre vlan) sinon le client pxe risque d’obtenir un bail dhcp venant d’un autre serveur.

A partir de là notre serveur PXE est prêt pour distribuer une image de SystemRescueCD aux clients PXE.

root@sysresccd / %/etc/init.d/pxebootsrv start

Vous pouvez dejà tester en lançant un client pxe il devrait booter directement sur system rescue CD. (pensez à régler le bios de votre client en conséquence).

Bon c’est pas fini, ce que nous venons de faire peut être très pratique pour utiliser system rescue CD sur un pc sans lecteur CD, afin de faire de la maintenance ( partitionement, backup, deboggage etc…)

Mais ce que je cherche à faire est d’installer une distribution Ubuntu sur mon laptop.

pour cela il suffit simplement de modifier les fichiers du serveur TFTP de system rescue CD en les remplçant par les fichier de netboot de Ubuntu. Vous pouvez les récuperer sur le net, mais pour ma part j’avais télécharger le .iso de Ubuntu sur mon pc. J’ai donc pris les fichiers de netboot directement dessus.

J’ai donc monter mon image iso pour en extraire les fichiers en questions.

opensuse:/ # mount -o loop /media/stock/xubuntu-9.04-alternate-i386.iso /mnt/

Sur le cd les fichiers en questions se trouve dans le repertoire /install/netboot

opensuse:/ # ls /mnt/install/netboot/ pxelinux.0 pxelinux.cfg ubuntu-installer version.info

Revenons sur le serveur PXE sysrescuecd Les fichiers necessaires au boot se situent dans /tftpboot J’ai donc simplement supprimer tout le contenu de /tftpboot

root@sysresccd / %rm -rf /tftpboot/*

et copié les fichier du netboot ubuntu dans ce dossier.

opensuse:/ #scp -r /mnt/install/netboot/* 10.0.0.54:/tftpboot/

et voilà

root@sysresccd /tftpboot % ls pxelinux.0 pxelinux.cfg ubuntu-installer version.info

Notre serveur pxe est prêt.

il ne reste plus qu’a lancer le client lorsque vous booterez sur le serveur, une belle install d’ubuntu va apparaitre.

Il y avait un moment que j’avais pas écris un petit billet. J’en profiste pour faire un petit mémo sur la mise en place d’un forum en cluster sur 2 serveurs dédiés type Dédibox. je dresse rapidement le tableau. Etant beta-testeur Dedibox, j’ai la chance de disposer de pas mal de serveurs dédiés de tests. Je me suis donc amusé à installé un Forum PunBB sur un cluster Actif/Actif répliqué par DRBD, et permettant les écritures concurentes grace au systeme de fichier cluster OCFS2. Un schéma vaut mieux qu’un grand discours.

Comme vous pouvez le constater, je suis parti sur le principe que pour redonder un forum, tel que punbb il faut redonder /var/www et /var/lib/mysql. Il y a pas mal de moyen pour redonder un block device, j’ai otper pour DRBD DRBD (Distributed Replicated Block Device) est un outil qui permet de synchroniser (par réplication) des périphériques de stockage (disque dur, partition, volume logique, etc.) entre deux ordinateurs via le réseau. Cette synchronisation se fait : en temps réel : elle se fait à la volée, pendant que les données sont modifiées de manière transparente : les applications, qui enregistrent leurs données sur le périphérique de stockage répliqué, le font sans même savoir qu’il s’agit d’une unité de stockage spéciale. de manière synchrone ou asynchrone : en fonctionnement synchrone, l’écriture est déclarée terminée lorsque les données sont écrites localement ET que la synchronisation est terminée. En fonctionnement asynchrone, l’écriture est déclarée terminée lorsque les données sont écrites localement (sur le serveur primaire et pas sur le serveur de réplique) uniquement. (cf ubuntu.fr) Plantons le tableau. Je suis parti de deux dédibox XL (raid0 pour le stockage) Mon partitionement:

Node1=
Disk /dev/md0: 131 MB, 131530752 bytes (/boot)
Disk /dev/md1: 42.9 GB, 42935779328 bytes (/)(raid0)
Disk /dev/md2: 952.6 GB, 952684642304 bytes (vg0) (raid0)
Node2=
Disk /dev/md0: 131 MB, 131530752 bytes (/boot)
Disk /dev/md1: 42.9 GB, 42935779328 bytes (/)(raid0)
Disk /dev/md2: 952.6 GB, 952684642304 bytes (vg0) (raid0)
///
On peut déjà apprécier l’éfficacité de Raid logiciel sous linux sur /dev/md2
///
Disk /dev/md2: 952.6 GB, 952684642304 bytes
root@node1:~# dd if=/dev/md2 of=/dev/zero bs=1M iflag=direct
1111+0 records in
1110+0 records out
1163919360 bytes (1,2 GB) copied, 6,55167 s, 178 MB/s

Ca peut aller. Je suis parti d’une distribution Ubuntu 8.04 LTS 64bit kernel 2.6.24-24-server sur les 2 noeuds. – Création des LVM.

root@node1:~# apt-get install lvm2

verifier bien que le module dm_mod est chargé, sinon chargez le

dm_mod 78200 7 dm_mirror,dm_snapshot

root@node1:~# pvcreate /dev/md2

root@node1:~# lvcreate -L2G -nlv0 vg0 Logical volume "lv0" created

root@node1:~# lvcreate -L2G -nlv1 vg0 Logical volume "lv1" created

nos deux Logcial volume sont crées. destinés à contenir respectivement drbd0 et drbd1 soit /var/www et /var/lib/mysql Creer la même arborescence lv sur les 2 noeuds.

• Installation de DRBD

Afin que l’installation de DRBD se passe bien, il faut vérifier quelques petits prérequis. Tout d’abord avoir les outils de compilation.

root@node1:~# apt-get install build-essential

Vérifier aussi d’avoir les sources de votre kernel ou du moins les header.

root@node1:~#apt-get install kernel-headers-$(uname -r) root@node1:~#apt-get install flex

Télécharger les sources de drbd sur le site http://oss.linbit.com/drbd

root@node1:/usr/src# tar xvfz drbd-8.3.1.tar.gz

root@node1:/usr/src# cd drbd-8.3.1 root@node1:/usr/src/drbd-8.3.1# make clean all

Véirifier que tout se compile bien. Installer maintenant DRBD

root@node1:/usr/src#make install -j4 root@node1:/usr/src#make install-tools -j4

attaquons nous au fichier de configuration de drbd situé dans /etc/drbd.conf

common {
protocol C;
startup {
#become-primary-on both;
wfc-timeout 30;
degr-wfc-timeout 30;
}
disk {
on-io-error detach;
no-disk-flushes;
no-md-flushes;
no-disk-barrier;
no-disk-drain;
}
net {
max-buffers 16384;
max-epoch-size 16384;
unplug-watermark 128;
sndbuf-size 8M;
ko-count 6;
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri violently-as0p;
after-sb-2pri violently-as0p;
rr-conflict violently;
}
syncer {
rate 100M;
al-extents 1801;
verify-alg crc32c;
}
}
resource r0 {
on node1 {
device /dev/drbd0;
disk /dev/vg0/lv0;
address 88.191.84.35:7789;
meta-disk internal;
}
on node2 {
device /dev/drbd0;
disk /dev/vg0/lv0;
address 88.191.84.36:7789;
meta-disk internal;
}
}
resource r1 {
on node1 {
device /dev/drbd1;
disk /dev/vg0/lv1;
address 88.191.84.35:7790;
meta-disk internal;
}
on node2 {
device /dev/drbd1;
disk /dev/vg0/lv1;
address 88.191.84.36:7790;
meta-disk internal;
}
}

Pareil sur le node2

root@node2#drbdadm create-md r0 r1

root@node2#drbdadm up r0 r1

Puis nous synchronisons les ressources. Sur le node 1 nous lançons

root@node1#drbdadm — –overwrite-data-of-peer primary r0 r1

On peut alors voir les ressources en cours de synchronisation.

Every 1,0s: cat /proc/drbd
version: 8.3.1 (api:88/proto:86-89)
GIT-hash: fd40f4a8f9104941537d1afc8521e584a6d3003c build by root@sd-15181, 2009-06-21 20:22:50
0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r—-
ns:3157114 nr:98131 dw:1082377 dr:2373543 al:226 bm:133 lo:0 pe:1464 ua:998 ap:1 ep:1 wo:n oos:2027040
[>....................] sync’ed: 3.6% (2027040/2097052)K
finish: 0:05:07 speed: 6,452 (5,832) K/sec
1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r—-
ns:2640518 nr:125231 dw:593569 dr:5326403 al:92 bm:133 lo:0 pe:1472 ua:1006 ap:1 ep:1 wo:n oos:2027760
[>....................] sync’ed: 3.4% (2027760/2097052)K
finish: 0:05:07 speed: 6,448 (5,772) K/sec

On peut remarquer qu’entre les 2 dedibox la synchronisation se fait 11Mo/s on sature le lien 100Mb/s ( rien ne nous empeche de limiter ce débit dans le drbd.conf)

• Passons maintenant à OCFS2.

Si on montait directement nos bases de données et nos sites sur les drbd après les avoir formatés avec un file sytem non clusterisé cela ne fonctionnerait pas. Car le but est que le forum puisque ecrire dans la base des deux cotés que les deux serveurs soient actifs en même temps et aient un accès concurrents au stockage. Pour cela il nous faut un systeme de fichier qui gere les accès concurrents sur un même espace de stockage (es 2 plus connus sont OCFS2 et GFS) installons OCFS2

root@node1#apt-get install ocfs2-tools

On créer le répertoire /etc/ocfs2

root@node1#mkdir /etc/ocfs2

On édite un fichier cluster.conf (identique sur les deux noeuds)

node:
ip_port = 7777
ip_address = 88.191.84.35
number = 0
name = node1
cluster = ocfs2
node:
ip_port = 7777
ip_address = 88.191.84.36
number = 1
name = node2
cluster = ocfs2
cluster:
node_count = 2
name = ocfs2

Changer la valeur “O2CB_ENABLED=false” en “O2CB_ENABLED=true” dans /etc/default/o2cb

On demmarre alors le cluster OCFS2

on peut alors formater nos devices drbd en ocfs2

root@node1#mkfs -t ocfs2 /dev/drbd0

root@node1#mkfs -t ocfs2 /dev/drbd1

Le faire sur un seul noeud suffit puisque drbd à dejà repliqué ce file system de l’autre coté.

Voilà le cluster est prêt à recevoir les données.

Pour ma part j’avais installé lamp avant et j’ai transferé les données sur les nouveaux montages.

root@node1#mount /dev/drbd0 /var/www root@node1#mount /dev/drbd1 /var/lib/mysql

Par contre il est important de désactiver tous les system de cache dans mysql. Car si ocfs2 est capable de gerer la cohérence sur son systeme disk, evidemment il ne peut pas gerer la cohérence entre les caches des deux serveurs Mysql qui tournent en même temps. En tatonnant un peu, j’ai réussi à faire demmarer les deux serveur mysql avec ce fichier de conf.

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# – « /etc/mysql/my.cnf » to set global options,
# – « ~/.my.cnf » to set user-specific options.
#
# One can use all long options that the program supports.
# Run program with –help to get a list of available options and with
# –print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain « # » chars…
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld]
#
# * Basic Settings
#

#innodb_data_home_dir =
#
## Le fichier de donné doivent contenir vos donné et index.
#innodb_data_file_path = /ibdata/ibdata1:2000M;
##
## Utilisez un buffer de taille 50 à 0 % de votre méire serveur
## mais assurez vous sous Linux que l’utilisation totale est inféeure à Go
#set-variable = innodb_buffer_pool_size=1G
#set-variable = innodb_additional_mem_pool_size=20M
#innodb_log_group_home_dir = /dr3/iblogs
##
## innodb_log_arch_dir doit êe le mê que innodb_log_group_home_dir
## (starting from 4.0.6, you can omit it)
#innodb_log_arch_dir = /dr3/iblogs
#set-variable = innodb_log_files_in_group=2
##
## Utilisez un fichier de log de taille 15 % du buffer méire
#set-variable = innodb_log_file_size=250M
#set-variable = innodb_log_buffer_size=8M
##
#innodb_flush_log_at_trx_commit=1
#set-variable = innodb_lock_wait_timeout=50
##
## Démmentez les prochaines lignes, si vous voulez les utiliser
##innodb_flush_method=fdatasync
##set-variable = innodb_thread_concurrency=5
#

#
# * IMPORTANT
# If you make changes to these settings and your system uses apparmor, you may
# also need to also adjust /etc/apparmor.d/usr.sbin.mysqld.
#

user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking = 0
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
#
# * Fine Tuning
#
key_buffer = 0
key_buffer_size = 0
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 0
#max_connections = 100
#table_cache = 64
#thread_concurrency = 10
#
# * Query Cache Configuration
#
query_cache_type = 0
query_cache_limit = 0
query_cache_size = 0
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
log = /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement
#
# Here you can see queries with especially long duration
#log_slow_queries = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
# other settings you may need to change.
#server-id = 1
#log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
#binlog_do_db = include_database_name
#binlog_ignore_db = include_database_name
#
# * BerkeleyDB
#
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
skip-bdb
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
# You might want to disable InnoDB to shrink the mysqld process by circa 100MB.
#skip-innodb
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI « tinyca ».
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer = 0

#
# * NDB Cluster
#
# See /usr/share/doc/mysql-server-*/README.Debian for more information.
#
# The following configuration is read by the NDB Data Nodes (ndbd processes)
# not from the NDB Management Nodes (ndb_mgmd processes).
#
# [MYSQL_CLUSTER]
# ndb-connectstring=127.0.0.1

#
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with ‘.cnf’, otherwise they’ll be ignored.
#
!includedir /etc/mysql/conf.d/

J’ai alors installé le forum PunBB sur un noeud, qui s’est bien sur instantanément répliqué sur l’autre.

Quand j’ai parlé d’équilibrage de charge dans le titre, je l’obtient en utilisant simplement un round robin au niveau DNS. C’est à dire 2 enregistrement A avec le meme nom qui pointent sur les 2 ip de mon cluster.

forum.info16.fr. IN A 88.191.84.35 forum.info16.fr. IN A 88.191.84.36

Ainsi aléatoirement un utilisateur cherchant à se connecter au forum forum.info16.fr sera diriger vers 88.191.84.35 ou 88.191.84.36 Attention on ne gere pas du tout le failover. Si un serveur plante l’utilisateur aura une chance sur 2 d’etre dirigé vers le site innaccessible.

Et même si on essait de gerer le DNS afin qu’il detecte si un serveur est innaccessible et modifie ces enregistrements en conséquence, on ne pourra jamais gérer le cache DNS des clients qui se connectent… Ils auront une ip innaccessible jusqu’au TTL. d’ou l’importance de mettre des TTL bas pour les round robin.

Ce billet me sert de petit aide mémoire pour installer une OpenSure sur un serveur dédié type dédibox… Vous vous demandez peut être ou est la difficulté? Et bien le problème est que Suse ne fait pas partie des distributions installable dans la console de gestion de dédibox. Donc problème, comment installer une distribution quand elle ne fait pas partie du package de l’herbergeur?

Heureusement Novell à penser à tout la Netinstall

Ce dont vous avez besoin pour réaliser une installation par le réseau est de démarrer le noyau d’installation ainsi que le programme d’installation initrd sur la machine distante. Vous avez aussi besoin de connaître l’adresse IP que l’ordinateur aura. Supposons que c’est une adresse IP fixe. Si vous utilisez DHCP, vous pouvez omettre la configuration du réseau. Tout d’abord, copier l’image du noyau et le programme d’installation dans votre répertoire /boot :

Tout d’abord installer une distribution proposée par dédibox par exemple une Debian. Booter sur le systeme installé.

On peut commencer:

Exemple pour la dernière version de développement:

cd /tmp
wget http://mirrors.kernel.org/opensuse/distribution/SL-OSS-factory/inst-source/boot/i386/loader/linux
wget http://mirrors.kernel.org/opensuse/distribution/SL-OSS-factory/inst-source/boot/i386/loader/initrd
cp linux /boot/vmlinuz.install
cp initrd /boot/initrd.install

Vous avez maintenant le kernel et l’initrd qui permette de booter sur un systeme minimum et lancer l’installation par le réseau.

Afin de lancer l’install par le réseau il faut modifier le grub afin de lancer SSH et d’indiquer le chemin réseau de l’install

vim /boot/grub/menu.lst

On rajoute alors les lignes du type:

title Boot — SUSE LINUX DEVEL INSTALL
root (hd0,0)
kernel /boot/vmlinuz.install usessh=1 sshpassword= »pass » install=http://204.152.191.7/opensuse/distribution/SL-OSS-factory/inst-source hostip=192.168.1.1 netmask=255.255.255.0 gateway=192.168.1.254 nameserver=192.168.1.254
initrd /boot/initrd.install

bien sur ceci si votre grub est installé sur la première partition du premier disque (hd0,0) = (sda1) et si votre ip est 192.168.1.1/24 votre passerelle 192.168.1.254 et votre dns 192.168.1.254

Mettre cette entrée en premier afin que le boot se fasse avec ces options. Si tout se passe bien vous devriez bientot pinger a nouveau votre serveur: Il est en train de booter sur le kernel minimal d’installation.

Après quelques minutes vous pourrez vous connecter en SSH sur le serveur

ssh -X 192.168.1.1

-X pour exporter aussi la session graphique. une fois connecté vous pouvez lancer yast.

L’installation peut commencer comme d’habitude

Il y a quelque temps, j’ai fait un petit article sur le protocole isci et l’export de périphérique bloc via ce protocole… J’ai toutefois découvert il y a peu de temps une facon encore plus simple d’exporter un Block device par le réseau : NBD ou network block device

Je vous laisse installer le nbd-server et le nbd-client sur votre distribution préférée… Pour ma part j’ai fait les tests sur une OpenSuse 11 pour le serveur et une Ubuntu Hardy pour le client… Que se soit avec yast ou a coup d’apt-get vous installerez facilement les paquets nbd.

Bref…

Si vous avez lu mon blog en entier, vous savez comment mettre en place LVM2, dont je me suis servi pour faire mes test, c’est tellement pratique de disposer d’un périphérique block avec une simple commande…

Sur le Serveur: Commencons par créer un block device avec LVM2

xenserver:~ # lvcreate -L1G -ndisk vg0 Logical volume "disk" created

Exportons le directement via nbd

xenserver:~ # nbd-server 3000 /dev/vg0/disk

La commande est simple, on demande à nbd-server d’exporter le block-device /dev/vg0/disk via le port 3000

Nous pouvons vérifier que nbd-server écoute bien sur le port 3000 et n’attend plus que la connexion de son client

xenserver:~ # netstat -anp | grep 3000 tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 16358/nbd-server

Passons maintenant au client: Sur Ubuntu j’ai dut installer lvm2, (noter que lvm2 n’est pas du tout indispensable, c’est juste que je le trouve très souple à utiliser pour mes tests, mais rien ne vous empêche de créer des periphérique via losetup et les periphérique /dev/loop) Il a fallut bien sur installer nbd-client et dans la foulée j’ai installé mdadm pour gerer le raid…

Bref, commencons par se connecter au serveur et importons notre block device…

root@bartounet:/media# nbd-client 192.168.1.115 3000 /dev/nbd2 Negotiation: ..size = 1048576KB bs=1024, sz=1048576

Ici on se connecte sur le port 3000 du serveur et on importe le nbd en local sur /deb/nbd2

Voila le tour est joué notre device /dev/nbd2 est vu comme un simple device local de notre systeme, mais est en réalité exporté par le réseau…

Comme j’aime faire quelques petits tests, nous allons pas nous arreter là, je vais tester la vitesse de ce block-device.

Pour cela rien de plus simple, un petit dd va nous permettre de voir la vitesse…

root@bartounet:/media# dd if=/dev/nbd2 of=/dev/zero bs=1M 1024+0 records in 1024+0 records out 1073741824 bytes (1,1 GB) copied, 13,3121 s, 80,7 MB/s

C’est pas mal, je sature presque mon lien réseau, puisque mes deux postes sont réliés via un réseau gigabits donc en théorie pouvant atteindre les 120Mo/s Ceci est un test en lecture sur /dev/nbd2

Pour nous en convaincre un petit iperf entre les deux machines:

root@bartounet:/media# iperf -cxenserver
————————————————————
Client connecting to xenserver, TCP port 5001
TCP window size: 16.0 KByte (default)
————————————————————
[ 3] local 192.168.1.100 port 35157 connected with 192.168.1.115 port 5001
[ 3] 0.0-10.0 sec 1.09 GBytes 936 Mbits/sec

En effet on a bien un lien gigabit entre les deux..

Pour être transparent je souhaite donner les performances disques disponibles pour les deux machines:

Les configs:

Xenserver: AMD Athlon 64 X2 5000+ Black edition à 2600Mhz 2Go DDR2 2 disques sata WDC WD1600YS (raid edition 160Go) en RAID0 logiciel

xenserver:~ # dd if=/dev/md0 of=/dev/zero bs=2M 1260388352 bytes (1.3 GB) copied, 10.4169 s, 121 MB/s

Bartounet: Intel Quad Core Q6600 G0 à 2400Mhz 2Go DDR2 2 disques sata Hitachi T7K500 250Go Raid0 matériel (puce raid Asus P5WDh deluxe)

root@bartounet:/media# dd if=/dev/sda of=/dev/zero bs=2M 616562688 bytes (617 MB) copied, 4,90903 s, 126 MB/s

Pour finir je me suis dit mais pourquoi pas faire un raid entre un block-device local sur BARTOUNET et un block-device nbd.

Pour cela je crée un block-device local sur bartounet toujours à l’aide de lvm2

root@bartounet:/media# lvcreate -L1G -nraid vgxen Logical volume "raid" created

Maintenant nous pouvons creer le périphérique raid avec mdadm

root@bartounet:/media# modprobe raid0
root@bartounet:/media# mdadm –create /dev/md1 –level=0 –raid-device=2 /dev/vgxen/raid /dev/nbd2
mdadm: array /dev/md1 started.

Notre raid est bien monté

root@bartounet:/media# mdadm –detail /dev/md1
/dev/md1:
Version : 00.90.03
Creation Time : Sun Jun 22 19:36:35 2008
Raid Level : raid0
Array Size : 2097024 (2048.22 MiB 2147.35 MB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent

Update Time : Sun Jun 22 19:36:35 2008
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Chunk Size : 64K

UUID : 6b2edcd4:b994fefd:20bc8809:0761db64 (local to host bartounet)
Events : 0.1

Number Major Minor RaidDevice State
0 254 1 0 active sync /dev/vgxen/raid
1 43 2 1 active sync /dev/nbd2

testons tout de suite la vitesse en lecture sur ce raid0 qui je vous rappelle est un raid0 entre un periphérique local /dev/vgxen/raid et un network block device /dev/nbd2 (exporté de Xenserver)

root@bartounet:/media# dd if=/dev/md1 of=/dev/zero 4194048+0 records in 4194048+0 records out 2147352576 bytes (2,1 GB) copied, 12,8236 s, 167 MB/s

Et voila on obtient un périphérique exploitant la vitesse des deux block device ( un local et un réseau) Marrant non ?

Bon la je me suis attaché aux performances mais rien ne vous empeche de faire du mode sécurisé en raid1 ou plus…

Sous le vocable iSCSI (à prononcer i-skeuzi, i-skozi, aïe-skeuzi ou aïe-skozi selon que vous adoptez une prononciation française ou anglophone), se cache un protocole réseau qui encapsule le protocole SCSI dans des paquets TCP. TCP/IP est alors utilisé comme protocole de transport ce qui permet à une machine d’accéder à des périphériques distants connectés à l’infrastructure réseau existante. Le protocole iSCSI (voir RFCA) utilise l’architecture client/serveur, mais possède sa propre terminologie :

le client est appelé « initiator » le serveur est appelé « target »

Je vais essayer dans ce billet de monter une petite Archi entre une Target Linux et un initiator Windows Xp

Lire la suite…