Gnu/Linux
#Gnu/Linux
Expérimentation de NBD (Network Block device), ou comment exporter un périphérique type bloc par le réseau
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...
#Gnu/Linux
Mise en place du protocole iscsi (Target Linux/OpenSuse-10.3, Initiator Windows XP Sp2)
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 L’initiator peut être une carte Ethernet spécialisée, munie d’un composant supplémentaire qui va gérer le protocole iSCSI. Cette carte sera appelée un « iSCSI-HBA ». Mais, on peut aussi déployer une solution logicielle pure qui nécessite seulement un driver spécifique dont le rôle sera de traduire les ordres SCSI en paquets réseau. C’est cette solution que nous allons mettre en œuvre dans cet article. La target (cible) est normalement un périphérique de stockage doté d’une interface iSCSI. Qu’est-ce-qu’une interface iSCSI ? Eh bien en fait, les constructeurs proposent, outre la connectivité Fibre Channel, un ou plusieurs ports Ethernet avec support au niveau de l’OS et éventuellement des cartes réseau, du protocole iSCSI. Mais pour ceux qui ne disposent pas d’un tel matériel, nous verrons comme émuler une target avec Linux ! Initiator et target sont considérés comme les nœuds d’un réseau iSCSI. Le driver iSCSI transporte les commandes SCSI sur le réseau plutôt que d’utiliser un bus SCSI directement connecté ou bien une connexion en FC.
Mon protocole de test:
Serveur 1: La target iscsi (opensuse 10.3)
AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ Black Edition (2600Mhz)
2Go ddr2 Crucial Balistic (4-4-4-12)
Carte Mère Asus M3A
1 HDD SAMSUNG HD160JJ pour le systeme
2 HDD Western digital WDC WD1600YS (raid edition) en Raid 0 ----> pour stockage LVM
Lan intégré à la carte Mère chipset Atlansic Gigabit
Serveur 2: L'initiator
Intel Q6600 Quad Core (2400Mhz)
2Go ddr2 Crucial Balistic
Carte mère P5WDH Deluxe
2 HDD hitachi 7200Tpm 250Go T7K500 en Raid0 matériel
Lan Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller
Bref, c'etait juste pour être précis sur le protocole de test....
Lorsque l’initiator souhaite établir une session TCP avec la target, il a besoin de connaître le port TCP de la target. L’association (adresse IP, port TCP) est appelé un « portal ». Il y a donc un portal sur l’initiator et la target. Le port par défaut sur la target est le 3260.
Notons qu’un initiator peut établir plusieurs connexions TCP avec la même cible. L’ensemble de ces connexions définit une « session iSCSI ».
Pour l'installation j'ai été cherché les sources de l'application iscsi-target qui au moment ou j'écris ces lignes est en version 0.4.16
[http://sourceforge.net/project/showfiles.php?group_id=108475&package_id=117141&release_id=585138|http://sourceforge.net/project/showfiles.php?group_id=108475&package_id=117141&release_id=585138|fr]
Après avoir téléchargé iscsi target on l'extrait
xenserver:~ # tar xvfz iscsitarget-0.4.16 xenserver:~ # cd iscsitarget-0.4.16/Il va maintenant falloir compiler et installer le logiciel... Il y a tout de même des prérequis: La target doit avoir un kernel linux au minimum 2.6.16 On doit disposer d'un compilateur gcc, des entetes de notre noyeau et des fichiers d’en-têtes de la bibliothèque OpenSSL. Après ces petites verification on compile et on installe:
xenserver:~/iscsitarget-0.4.16 # make xenserver:~/iscsitarget-0.4.16 # make installOn a donc maintenant: # iscsi_trgt.ko : un module noyau qui émule une cible iSCSI et implémente le protocole ; # un démon ietd (IET = iSCSI Enterprise Target) ; # une commande de contrôle ietadm ; # quelques fichiers de configuration On peut tout de suite crée une target iscsi... Pour cela rien de plus simple: Il faut savoir que les adresses iscsi peut vent avoir 2 formes: Les adresses iSCSI peuvent avoir deux formats (voir [RFCB]) : * Le format iqn (iSCSI Qualified Name) : c’est une chaîne préfixée par « iqn. » et suivie d’une date (au format AAAA-MM), du nom de l’autorité qui a attribué le nom (c’est le nom de domaine à l’envers), puis une chaîne unique qui identifie le nœud. Par exemple : iqn.2007-07.org.zereso:serveur1:123456789ABCDEF.12345. * Le format eui (Enterprise Unique Identifier) : c’est une chaîne préfixée par « eui. » et suivie de 16 chiffres hexadécimaux. Par exemple : eui.00803A4B887A8D05. On va donc aller éditer le fichier ietd.conf
xenserver:~/iscsitarget-0.4.16 # vi /etc/ietd.conf
# iqn.yyyy-mm.[:identifier] # # "yyyy-mm" is the date at which the domain is valid and the identifier # is freely selectable. For further details please check the iSCSI spec. Target iqn.2008-04.lan.appart:storage.disk # Users, who can access this target. The same rules as for discovery # users apply here. # Leave them alone if you don't want to use authentication. #IncomingUser joe secret #OutgoingUser jim 12charpasswd # Logical Unit definition # You must define one logical unit at least. # Block devices, regular files, LVM, and RAID can be offered # to the initiators as a block device. Lun 0 Path=/dev/vg0/luniscsi,Type=blockio # Alias name for this target # Alias Test # various iSCSI parameters # (not all are used right now, see also iSCSI spec for details) #MaxConnections 1 #InitialR2T Yes #ImmediateData No #MaxRecvDataSegmentLength 8192 #MaxXmitDataSegmentLength 8192 #MaxBurstLength 262144 #FirstBurstLength 65536 #DefaultTime2Wait 2 #DefaultTime2Retain 20 #MaxOutstandingR2T 8 #DataPDUInOrder Yes #DataSequenceInOrder Yes #ErrorRecoveryLevel 0 #HeaderDigest CRC32C,None #DataDigest CRC32C,None # various target parameters #Wthreads 8Le fichier parle de lui même j'ai déclaré une cible qui est Target iqn.2008-04.lan.appart:storage.disk et un périhpérique cible en mode bloc appelé une LUN qui est /dev/vg0/luniscsi,Type=blockio Avant de démarrer le demon iscsi-target, je vais quand même créer mon disque puisqu'il n'existe pas encore ;-) Pour cela j'utilise l'excellent systèmes LVM2 Le système de LVM insère des sous-couches entre la partition de disque et votre système de fichier (là où sont vos données). Ces sous-couches vont vous permettre de modifier dynamiquement la taille des systèmes de fichier, sans mettre en péril vos données. Ainsi vous pourrez ajouter, enlever de l'espace disque d'un filesystem à la volée, rajouter un système de fichier... sans modification de la table des partitions. crééons notre disque:
xenserver:~/iscsitarget-0.4.16 # lvcreate -L5G -nluniscsi vg0 Logical volume "luniscsi" created(il faut bien sur avoir préalabement configurer son système disque pour fonctionner avec le systeme lvm2 et creee les volume groups) J'ai donc un volume logique de 5G qui n'est autre que ma LUN qui va pouvoir être exportée sur le réseau vers l'initiator. démarrons alors le demon target iscsi
xenserver:~/iscsitarget-0.4.16 # /etc/init.d/iscsi-target startà partir de là on va pouvoir aller s'occuper de l'initiator... Mais comme on est sérieux on va aller quand même vérifier que nos cilbe sont biens exportées pour cela on va directement regarder dans:
xenserver:~/iscsitarget-0.4.16 # cat /proc/net/iet/volume tid:1 name:iqn.2008-04.lan.appart:storage.disk lun:0 state:0 iotype:blockio iomode:wt path:/dev/vg0/luniscsiOuf on retrouve bien notre target associé à notre lun... Maintenant passons sous Windows... Je mettrais à jour plus tard ce post, pour monter aussi l'initiator sous Gnu/Linux, mais ce n'est pour l'instant pas ma priorité, puisque pour ma part j'utilise que des clients Windows, qui se connectent sur du serveur Gnu/Linux... Sous Windows Xp Sp2 l'initiator isci n'est pas installé par défaut, j'ai installé pour ma part Initiator-2.06 [http://www.microsoft.com/Downloads/details.aspx?familyid=12CB3C1A-15D6-4585-B385-BEFD1319F825&displaylang=en|http://www.microsoft.com/Downloads/details.aspx?familyid=12CB3C1A-15D6-4585-B385-BEFD1319F825&displaylang=en|fr] Uns fois installé on lance l'initiateur iscsi. On ajoute l'ip de notre target
On va voir dans le gestionnaire des disques
Et miracle notre lun est apparu comme un disque à part entière
Après une creation de partition et un formatage en ntfs
Notre LUN iscsi est bien monté sur notre initiator...
On peut maintenant l'utiliser comme les autres disques...
Pour finir mon test, j'ai voulu quand même vérifier le débit de cette lun.
Comme nous l'avons vu plus haut, la lun est basé sur un logical volume crée sur mon raid0 (raid0 logiciel Linux) de deux disques Western Digital WD1600YS
Pour savoir quelles sont les performances de départ, voici un petit dd sur le raid en question
xenserver:~ # dd if=/dev/md0 of=/dev/zero bs=16M 125+0 records in 124+0 records out 2080374784 bytes (2.1 GB) copied, 19.9423 s, 104 MB/sC'est un raid0 sur deux disques qui vont chacun à 63Mo/s en vitesse séquentielle... Cela dépend des tests, en raid0 la vitesse varie entre 100 et 126Mo/s Faisons le test de vitesse sur la lun sous Windows...
On peut voir qu'on monte à environ 60Mo/s sur la Lun, ce qui n'est pas mal mais qui pourrait etre mieux...
En effet le lien réseau entre les deux n'est pas limité...
La preuve avec iperf entre l'initiator et la target
C:\>iperf.exe -w512k -c192.168.1.115 ------------------------------------------------------------ Client connecting to 192.168.1.115, TCP port 5001 TCP window size: 512 KByte ------------------------------------------------------------ [1916] local 192.168.1.100 port 2500 connected with 192.168.1.115 port 5001 [ ID] Interval Transfer Bandwidth [1916] 0.0-10.3 sec 1.10 GBytes 922 Mbits/secOn pourrait tunner notre pile tcp/ip pour atteindre de bien meilleurs résultats, notemment en activant les jumbo Frames (Paquets géants) mais la carte nic intégré à l'asus M3A ne semble pas le supporter... Elle ne supporte pas non plus le TCP Checksum offloader (toe)... les réglages sont donc assez restreints....
#Gnu/Linux
Petit exemple de création de tunnel SSH
Quand on surf en dehors de chez soi, dans un cyber café, ou à partir d'un réseau qu'on ne controle pas, on en oublie aussi souvent la sécurité. Ce post me sert d'aide mémoire pour creer des tunnels SSH en local et en remote afin de pouvoir acceder de facon sécurisé à des services qui ne le sont pas forcément (smtp, pop, imap, ftp, http)...
Si on se met en situation, imaginez vous avez votre pc portable, vous etes sur une connexion que vous ne controlez pas (hotels, cyber café) vous voulez relevez vos mails en imap ou en pop. L'utilisateur lambda se connecterai à son serveur de messagerie directement sans se soucier de la sécurité. Le probleme est que dans un tel réseau vous n'etes jamais sur que quelqun ne "sniff" pas les connexions, il est très facile de sniffer tout ce qui passe sur son réseau pour un admin réseau ou même un petit bricolo... il faut donc savoir que
lorsque vous utilisez des protocoles non sécurisés, vos login et mots de passe circulent en clair sur le réseau... Ce n'est pas très grave quand vous surfez sur le web mais ca l'ai plus si vous rapatriez vos mails, si vous transferer des fichiers sur des ftp etc...
Bref tout cela pour dire que quand les connexions sont assez sensibles, mieux vaut ajouter un peu de sécurité... C'est pourquoi mon but va être de faire passer ces connexions non sécure dans un tunnel sécurisé... pour cela SSH est assez performant...
prenons un exemple simple
La manipulation est simple il faut creer un tunnel ssh entre votre poste client et votre serveur... pour cela vous devez bien sur avoir la main sur votre serveur externe et avoir le serveur SSH lancé et configuré. imaginons que je veuille acceder à mon webmail qui est hebergé sur mon serveur dédié, mais que je ne veux absolument pas qu'on puisse intercepter mes identifiants... sur mon poste client qui est bien sur sous Gnu/Linux je tappe
root@ubuntu:~# ssh -L 3333:localhost:80 info16.fr
Cela signifie qu'un tunnel SSH à été établie en moi et mon serveur info16.fr et que toutes les connexion qui auront lieux sur localhost:3333 de mon poste client sera redirigé PAR LE TUNNEL SSH sur le port 80 de info16.fr
on test:
root@ubuntu:~# ssh -L 3333:localhost:80 info16.fr root@info16.fr's password: Last login: Fri Mar 28 14:59:15 2008 from lmontsouris-152-61-27-191.w80-13.abo.wanadoo.fr Ubuntu 6.06.2 LTS Linux serveur.info16.fr 2.6.24.2-xxxx-std-ipv4-32 #4 SMP Wed Feb 13 16:50:04 CET 2008 i686 GNU/Linux server : 11178 ip : 91.121.31.206 hostname : serveur.info16.fr
sur le poste client il suffit alors de se connecter avec un navigateur sur son adresse de loopback et sur le port 3333 et on passe à travers le tunnel jusque sur le port 80 du serveur info16.fr On vérifie cela avec le fabuleux navigateur lynx
root@ubuntu:~# lynx http://localhost:3333
On obtient alors:
www.info16.fr www.info16.fr FTP Free FTP dedi Blog Webmail appart Webmail info16.fr Decelect%20158.jpg Contact:B@rtounet
On est bien sur le webmail de info16.fr a partir de localhost:3333 et ceci de manière totalement sécurisée
Maintenant je vais vous montrer un exemple encore plus interessant... Utiliser le tunnel SSH avec le mode remote.... Le tunnel sera toujours initié entre mon poste client et mon serveur dédié, mais cette fois l'écoute se fera sur le serveur....
Ceci peut etre très utile... imaginé que vous etes en train de developper un site web en local... sur votre poste... vous souhaitez que des personnes externes puisse y acceder de la toile, mais vous ne voulez pas ou ne pouvez pas ouvrir les ports 80 sur votre firewall et les rediriger sur l'ip de votre poste...
Qu'a cela ne tienne, le tunnel ssh est là pour ca...
je vais initier un tunnel entre mon poste client et mon serveur dédié en mode remote...
ATTENTION, j'ai cherché un moment avant que cette manip fonctionne... par défaut votre serveur dédié se mettra à l'écoute sur 127.0.0.1 ors si onveut que des personnes externes puisse se connecter dessus, il faut que le socket initié par le tunnel ssh sur le serveur dédié soit à l'écoute pour toutes les adresses c'est à dire soit à l'écoute sous 0.0.0.0
Après avoir longtemps parcouru le man de ssh j'ai enfin trouvé la solution. il faut rajouter une option dans le /etc/ssh/sshd_config
il faut donc rajouter
GatewayPorts yes
après cela le serveur écoutera bien sur toutes les adresses...
la commande magique:
root@ubuntu:~# ssh -R 3333:localhost:80 info16.fr
En langage peut etre plus clair... cette commande signifie je veux initier un tunnel ssh tel que quand on se connecte sur le port 3333 de info16.fr on soit automatiquement redirigé ver le port 80 de mon poste (localhost)
on peut vérifier que sur info16.fr l'ecoute se fait bien:
root@serveur:~# netstat -anp | grep 3333 tcp 0 0 0.0.0.0:3333 0.0.0.0:* LISTEN 16075/1
à partir de là n'importe quel personne externe (du moment qu'il n 'y ai pas de regle de pare feu qui bloque le port 3333 de info16.fr) peut se connecter sur http://info16.fr:3333 il sera automatiquement redirigé par le tunnel SSH sur le port 80 de votre poste client qui heberge votre site en construction...
on peut bien sur le faire pour tous les protocole...
Vous voulez que quelqun prenne la main en ssh sur votre poste gnu/linux mais vous ne voulez pas ouvrir de port sur votre pare feu...
la commande est la même...
ssh -R 3333:localhost:22 info16.fr
Je veux initier un tunnel ssh tel que quand on se connecte sur le port 3333 de info16.fr on soit automatiquement redirigé ver le port 22 de mon poste (localhost)
comme je dis pas de betise on test tout de suite si ca marche à partir d'un poste externe n'importe ou sur la toile...
xenserver:~ # ssh -p3333 info16.fr root@info16.fr's password: Last login: Fri Mar 28 16:45:32 2008 from localhost Linux ubuntu 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@ubuntu:~#
on voit bien ici qu'a partir d'un client externe en se connectant au port 3333 de info16.fr on est automatiquement redirigé vers le port 22 du client (ubuntu)
#Gnu/Linux
Compression sous Gnu/Linux en environnement multi-CPU
Si il y a bien quelque chose qui manque sous Linux, c'est le fait de pouvoir profiter d'un vrai outil de compression qui utilise au mieux les nouveaux environnements SMP actuels. Gzip est un excellent outil de compression, mais vous avez dut remarquer qu'il ne fonctionne que sur un CPU... c'est très embetant dans des environnements serveurs ou on a besoin de creer des fichiers compréssés assez rapidement...
En cherchant un petit peu je suis tombé sur l'outil mgzip. Ce projet semble dater un peu mais il à le mérite d'exister...
vous pouvez voir ce projet au http://lemley.net/mgzip.html
Les sources sont disponibles sur http://lemley.net/smp_mgzip_1.2c.tar.gz
Il suffit de le télécharger et de le décompresser dans le dossier de votre choix...
root@serveur:~# tar xvfz smp_mgzip_1.2c.tar.gz smp_mgzip_1.2c/ smp_mgzip_1.2c/README smp_mgzip_1.2c/COPYING smp_mgzip_1.2c/Makefile.in smp_mgzip_1.2c/config.h.in smp_mgzip_1.2c/configure.in smp_mgzip_1.2c/die.c smp_mgzip_1.2c/die.h smp_mgzip_1.2c/get_options.c smp_mgzip_1.2c/mgzip.h smp_mgzip_1.2c/queue.c smp_mgzip_1.2c/queue.h smp_mgzip_1.2c/version.awk smp_mgzip_1.2c/test_suite.sh smp_mgzip_1.2c/configure smp_mgzip_1.2c/Makefile.AIX smp_mgzip_1.2c/Makefile.ALPHA smp_mgzip_1.2c/Makefile.Linux smp_mgzip_1.2c/4g-patch.tar smp_mgzip_1.2c/concat.patch smp_mgzip_1.2c/ChangeLog smp_mgzip_1.2c/mgzip.c
Après cela il faut le compiler.
root@serveur:~/smp_mgzip_1.2c# ./configure --with-zlib=/root/zlib-1.2.3 && make loading cache ./config.cache checking how to run the C preprocessor... (cached) cc -E checking for AIX... no checking for gawk... (cached) gawk checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking whether make sets ${MAKE}... (cached) yes checking for library containing __pthread_create... (cached) no checking for library containing pthread_join... (cached) -lpthread checking for ANSI C header files... (cached) yes checking for unistd.h... (cached) yes checking for zlib.h... (cached) yes checking for gzdopen in -lz... (cached) yes checking whether byte ordering is bigendian... (cached) no checking for working const... (cached) yes checking for vprintf... (cached) yes checking for pthread_delay_np... (cached) no creating ./config.status creating Makefile creating config.h config.h is unchanged gcc -I/root/zlib-1.2.3 -g -O2 -I/root/zlib-1.2.3 -c -o mgzip.o mgzip.c mgzip.c:40: error: 'gz_header' redeclared as different kind of symbol /root/zlib-1.2.3/zlib.h:124: error: previous declaration of 'gz_header' was here mgzip.c: In function 'gzip_worker_thread': mgzip.c:219: warning: pointer targets in passing argument 2 of 'crc32' differ in signedness make: *** mgzip.o Error 1
On remarque tout de suite une erreur qui peut etre corrigé en modifiant le fichier mgzip.c
Editez ce fichier et modifier tous les gz_header de cette maniere : pouet_gz_header (rajout indicatif mettez ce que vous voulez) (faite une recherche de toutes les occurences de gz_header ca ira plus vite) ou encore mieux avec un sed pour remplacer l'occurence gz_header par pouet_gz_header
cat mgzip.c | sed 's/gz_header/pouet_gz_header/' > mgzip2.c && mv mgzip2.c mgzip.c
Une fois le fichier modifié ca devrait mieux compiler...
en effet:
root@serveur:~/smp_mgzip_1.2c# ./configure --with-zlib=/root/zlib-1.2.3 && make loading cache ./config.cache checking how to run the C preprocessor... cc -E checking for AIX... no checking for gawk... gawk checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether make sets ${MAKE}... yes checking for library containing __pthread_create... no checking for library containing pthread_join... -lpthread checking for ANSI C header files... yes checking for unistd.h... yes checking for zlib.h... yes checking for gzdopen in -lz... yes checking whether byte ordering is bigendian... no checking for working const... yes checking for vprintf... yes checking for pthread_delay_np... no updating cache ./config.cache creating ./config.status creating Makefile creating config.h gcc -I/root/zlib-1.2.3 -g -O2 -I/root/zlib-1.2.3 -c -o mgzip.o mgzip.c mgzip.c: In function 'gzip_worker_thread': mgzip.c:219: warning: pointer targets in passing argument 2 of 'crc32' differ in signedness gcc -I/root/zlib-1.2.3 -g -O2 -I/root/zlib-1.2.3 -c -o queue.o queue.c gcc -I/root/zlib-1.2.3 -g -O2 -I/root/zlib-1.2.3 -c -o die.o die.c gcc -I/root/zlib-1.2.3 -g -O2 -I/root/zlib-1.2.3 -c -o get_options.o get_options.c gcc -o mgzip mgzip.o queue.o die.o get_options.o -lz -lpthread -L/root/zlib-1.2.3
On obtient maintenant dans ce dossier le fameux programe mgzip, pour bien faire placer le dans /usr/sbin pour qu'il soit directmeent disponible
Comme j'aime bien finir les billet par un petit test on va quand même verifier l'efficacité de cette commande...
Pour cela ma machine de test sera compsé de: Athlon X2 5000+ Black edition à 2600MHZ 2Go de DDR2 800 Crucial en 44412 MSI K9N Platinum 2 Disk hitachi sata 2 Raid edition 160Go en Raid0 Logiciel
Mon protocle de test est assez simple... Je pars d'un disque de type LVM formaté en ext3 qui contient 2go de données. et je vais compréssé avec gzip et avec mgzip et calculé le temps necessaire à cette compréssion...
Voici le résultat
xenserver:~/testcpu # dd if=/dev/vg0/gziptest bs=16M | gzip -c --fast | dd of=/gziptest.gz bs=16M 128+0 records in 128+0 records out 2147483648 bytes (2.1 GB) copied, 33.7023 s, 63.7 MB/s 0+500 records in 0+500 records out 9401822 bytes (9.4 MB) copied, 33.6445 s, 279 kB/s xenserver:~/testcpu # dd if=/dev/vg0/gziptest bs=16M | mgzip -c -1 -t 64 | dd of=/gziptest.gz bs=16M 128+0 records in 128+0 records out 2147483648 bytes (2.1 GB) copied, 26.2779 s, 81.7 MB/s 0+794 records in 0+794 records out 10075503 bytes (10 MB) copied, 26.314 s, 383 kB/s
on remarque que le mgzip à été un peu plus rapide mais sans aller deux fois plus vite... ce qui théoriquement devrait être le cas... Je cherche encore un outils qui serait plus performant... mailez moi si vous en trouvez un
#Gnu/Linux
Mise en place de virtualHosts sous opensuse 10.3
Quand on installe apache2 de base, on peut bien sur heberger son site à la racine de l'arborescence, mais on est très vite bloqué si on veut creer plusieurs sites avec plusieurs sous domaines...
Ce billet me sert juste d'aide mémoire pour mettre en place les virtualshosts sous suse. Ayant l'habitude de monter des sites sous Ubuntu / Debian la configuration sous suse est légèrement différente.
Pour la mise en place de virtualhosts sous Ubuntu, je vous renvoie vers l'excellent documentation du forum ubuntu-fr http://doc.ubuntu-fr.org/tutoriel/virtualhosts_avec_apache2 Le principe est assez simple grace aux modules sites-available
Après avoir longtemps évolué sous ubuntu/debian quand on passe sous suse on est un peu perdu...
En effet ne cherchez pas l'arborescence du site dans /var/www, elle n'y est pas... dans cette distribution tout se trouve sous /srv/www/htdocs
Je pars du principe que je souhaite 3 hotes virtuels... le tout sur une ip locale 192.168.1.250 1- La racine de mon site qui sera www.appart.lan 2- L'accès à mon webmail qui sera webmail.appart.lan 3- L'accès à un site de test en developpement test1.appart.lan
tout d'abord verifier que les virtual hosts seront biens pris en compte dans /etc/apache2/httpd.conf
### Virtual server configuration ############################################ # # VirtualHost: If you want to maintain multiple domains/hostnames on your # machine you can setup VirtualHost containers for them. Most configurations # use only name-based virtual hosts so the server doesn't need to worry about # IP addresses. This is indicated by the asterisks in the directives below. # # Please see the documentation at # <URL:http://httpd.apache.org/docs-2.2/vhosts/> # for further details before you try to setup virtual hosts. # # You may use the command line option '-S' to verify your virtual host # configuration. # Include /etc/apache2/vhosts.d/*.conf # Note: instead of adding your own configuration here, consider # adding it in your own file (/etc/apache2/httpd.conf.local) # putting its name into APACHE_CONF_INCLUDE_FILES in # /etc/sysconfig/apache2 -- this will make system updates # easier :)
ensuite préciser sur quelle socket (adresse_ip:port) le serveur écoutera dans /etc/apache2/listen.conf definir la derniere ligne comme suit
NameVirtualHost 192.168.1.250:80
Pour finir nous allons définir un dossier de configuration pour tous nos virtualshosts dans /etc/apache2/vhosts.d En effet là ou sous debian on aurait fait un fichier de conf pour chaque virtual hosts, ici sous suse je n'ai réussi à le faire fonctionner qu'en utilisant un seul et unique fichier... C'est peut etre pas plus mal...
j'ai donc créee un fichier mesvirthosts.conf
à l'intérieur tout est explicite:
# ---> Site principal <VirtualHost 192.168.1.250:80> ServerName appart.lan ServerAlias bartounet.no-ip.org DocumentRoot /srv/www/htdocs </VirtualHost> # # ---> Site du sous-domaine "Webmail" <VirtualHost 192.168.1.250:80> ServerName webmail.appart.lan ServerAlias webmail.bartounet.no-ip.org DocumentRoot /srv/www/htdocs/squirrelmail </VirtualHost> # # ---> Site du sous-domaine "test1" <VirtualHost 192.168.1.250:80> ServerName test1.appart.lan ServerAlias test1.bartounet.no-ip.org DocumentRoot /srv/www/htdocs/test1 </VirtualHost>
on définit d'abord sous quel socket sera disponible le virtual host ensuite sous quel domaine local il ser aaccessible, son alias publique et bien sur le chemin dans lequel sera stocké le site en question
bien terminer la configuration par
rcapache2 restart
Vous l'avez compris la racine de mon site sera accessible en passant par www.appart.lan qui pointe vers /srv/www/htdocs mon webmail par webmail.appart.lan qui pointe vers /srv/www/htdocs/squirrelmail mon site test1 par test1.appart.lan /srv/www/htdocs/test1