Info16.fr

Le blog de B@rtounet

Gnu/Linux

#Gnu/Linux

Installation et configuration du Push Mail entre Zimbra OSE via Z-push

ZPUSH-articles Installation  et configuration du Push Mail entre Zimbra OSE via Z-push


Je travaille depuis un moment sur Zimbra.
J'ai remplacé il y à peu mon serveur d'entreprise Lotus Domino par Zimbra NE

Dans sa version NE, Zimbra possède un outil de synchro mobile intégré et très performant donc pas de problème.

Par contre j'utilise aussi la version Zimbra OSE pour mes potes et des associations. C'est pour cela qu'il était pour moi interessant de fournir à mes utilisateurs
une solution de Push-mail performante et gratuite.

C'est pour cela que je me suis penché sur Z-push
Z-Push est une solution Open-Source de Zarafa qui permet de faire du push mail depuis des terminaux mobiles.
Mais aussi la synchro des contacts et des calendriers !
 Z-Push utilise le protocole Microsoft ActiveSync qui est supporté sur un grand nombre de terminaux mobiles (Iphone, Android, Windows Mobile, Maemo, Symbian...)


J'ai effectué mon install sur un DomU Xen routed à base d'un template Ubuntu 10.04 64 bits paravirtualisé






Installation des prérequis:

Installation de apache2, php5 et php-curl openssl
Activation de ssl dans apache a2enmod ssl

Installation de Z-push

Téléchargement de Z-push téléchargé sur http://prdownload.berlios.de/z-push/z-push-1.5.1.tar.gz
Téléchargement du backend Zimbra sur http://sourceforge.net/projects/zimbrabackend/files/Release48/zimbra48.tgz/download

J'ai placé z-push à la racine de mon espace web /var/www

#tar xvfz z-push-1.5.1.tar.gz -C /var/www


J'ai extrait le backend Zimbra zimbra.php dans /var/www/z-push/backend/

#tar xvfz zimbra48.tgz -C /var/www/z-push/backend

Modifications des droits
#chown -R www-data:www-data /var/www/z-push
#chmod 755 /var/www/z-push/state
#chown www-data:www-data /var/www/z-push/state


configuration de Z-push et Apache:

Mon serveur est un DomU Xen dédié nommé push.info16.fr
Il sera accessible en http et https
Penser à activer l'écoute sur les 2 ports 80 et 443 dans /etc/apache/ports.conf

  •           Virtualhost en http ( non ssl): etc/apache2/sites-enabled/default
                  
<VirtualHost *:80>
ServerName push.info16.fr
DocumentRoot /var/www/z-push/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/z-push/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ErrorLog /var/log/apache2/error.log
LogLevel warn
CustomLog /var/log/apache2/ssl_access.log combined
Alias /doc/ "/usr/share/doc/"
<Directory "/usr/share/doc/">
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>
Alias /Microsoft-Server-ActiveSync /var/www/z-push/index.php
php_flag short_open_tag on
php_flag magic_quotes_runtime off
php_flag register_globals off
php_flag magic_quotes_gpc off
</VirtualHost>





  •           Virtualhost en https ( ssl) : /etc/apache2/sites-enabled/ssl

<VirtualHost *:443>
ServerName push.info16.fr
DocumentRoot /var/www/z-push/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/z-push/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ErrorLog /var/log/apache2/error.log
LogLevel warn
CustomLog /var/log/apache2/ssl_access.log combined
Alias /doc/ "/usr/share/doc/"
<Directory "/usr/share/doc/">
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>
Alias /Microsoft-Server-ActiveSync /var/www/z-push/index.php
php_flag short_open_tag on
php_flag magic_quotes_runtime off
php_flag register_globals off
php_flag magic_quotes_gpc off

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache2/ssl/push.crt
SSLCertificateKeyFile /etc/apache2/ssl/push.key
SSLProxyCACertificateFile /etc/apache2/ssl/push.crt

<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

</VirtualHost>

Creation des certificats 2048 bits
#cd /etc/apache2/ssl

#openssl genrsa -out push.key 2048
#openssl req -new -key push.key -out push.csr
#openssl x509 -req -days 365 -in push.csr -signkey push.key -out push.crt



Pensez bien sur à activer les vhosts:
#a2ensite default; a2ensite ssl

Modification de /var/www/z-push/config.php
<?php
/***********************************************
* File : config.php
* Project : Z-Push
* Descr : Main configuration file
*
* Created : 01.10.2007
*
* Copyright 2007 - 2010 Zarafa Deutschland GmbH
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU Affero General Public License, version 3,
* as published by the Free Software Foundation with the following additional
* term according to sec. 7:
*
* According to sec. 7 of the GNU Affero General Public License, version 3,
* the terms of the AGPL are supplemented with the following terms:
*
* "Zarafa" is a registered trademark of Zarafa B.V.
* "Z-Push" is a registered trademark of Zarafa Deutschland GmbH
* The licensing of the Program under the AGPL does not imply a trademark license.
* Therefore any rights, title and interest in our trademarks remain entirely with us.
*
* However, if you propagate an unmodified version of the Program you are
* allowed to use the term "Z-Push" to indicate that you distribute the Program.
* Furthermore you may use our trademarks where it is necessary to indicate
* the intended purpose of a product or service provided you use it in accordance
* with honest practices in industrial or commercial matters.
* If you want to propagate modified versions of the Program under the name "Z-Push",
* you may only do so if you have a written permission by Zarafa Deutschland GmbH
* (to acquire a permission please contact Zarafa at trademark@zarafa.com).
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Affero General Public License for more details.
*
* You should have received a copy of the GNU Affero General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*
* Consult LICENSE file for details
************************************************/
 // Defines the default time zone
 if (function_exists("date_default_timezone_set")){
 date_default_timezone_set("Europe/Paris");
 }

 // Defines the base path on the server, terminated by a slash
 define('BASE_PATH', dirname($_SERVER['SCRIPT_FILENAME']) . "/");

 // Define the include paths
 ini_set('include_path',
 BASE_PATH. "include/" . PATH_SEPARATOR .
 BASE_PATH. PATH_SEPARATOR .
 ini_get('include_path') . PATH_SEPARATOR .
 "/usr/share/php/" . PATH_SEPARATOR .
 "/usr/share/php5/" . PATH_SEPARATOR .
 "/usr/share/pear/");

 define('STATE_DIR', BASE_PATH.'/state');

 // Try to set unlimited timeout
 define('SCRIPT_TIMEOUT', 0);

 //Max size of attachments to display inline. Default is 1MB
 define('MAX_EMBEDDED_SIZE', 1048576);

 // Device Provisioning
 define('PROVISIONING', false);

 // This option allows the 'loose enforcement' of the provisioning policies for older
 // devices which don't support provisioning (like WM 5 and HTC Android Mail) - dw2412 contribution
 // false (default) - Enforce provisioning for all devices
 // true - allow older devices, but enforce policies on devices which support it
 define('LOOSE_PROVISIONING', false);

 // Default conflict preference
 // Some devices allow to set if the server or PIM (mobile)
 // should win in case of a synchronization conflict
 // SYNC_CONFLICT_OVERWRITE_SERVER - Server is overwritten, PIM wins
 // SYNC_CONFLICT_OVERWRITE_PIM - PIM is overwritten, Server wins (default)
 define('SYNC_CONFLICT_DEFAULT', SYNC_CONFLICT_OVERWRITE_PIM);

 // The data providers that we are using (see configuration below)
 $BACKEND_PROVIDER = "BackendZimbra";

 // ************************
 // BackendICS settings
 // ************************

 // Defines the server to which we want to connect
 define('MAPI_SERVER', 'file:///var/run/zarafa');
 
 define('ZIMBRA_URL','https://webmail.info16.fr');
 define('ZIMBRA_USER_DIR','zimbra');
 define('ZIMBRA_SYNC_CONTACT_PICTURES', true);
 define('ZIMBRA_VIRTUAL_CONTACTS',true);
 define('ZIMBRA_VIRTUAL_APPOINTMENTS',true);
 define('ZIMBRA_VIRTUAL_TASKS',true);
 define('ZIMBRA_IGNORE_EMAILED_CONTACTS',true);
 define('ZIMBRA_HTML',false);
 define('IMAP_DEFAULTFROM', '');
 define('IMAP_SENTFOLDER', '');


 
 // ************************
 // BackendIMAP settings
 // ************************

 // Defines the server to which we want to connect
 // recommended to use local servers only
 define('IMAP_SERVER', 'localhost');
 // connecting to default port (143)
 define('IMAP_PORT', 143);
 // best cross-platform compatibility (see http://php.net/imap_open for options)
 define('IMAP_OPTIONS', '/notls/norsh');
 // overwrite the "from" header if it isn't set when sending emails
 // options: 'username' - the username will be set (usefull if your login is equal to your emailaddress)
 // 'domain' - the value of the "domain" field is used
 // '@mydomain.com' - the username is used and the given string will be appended
 define('IMAP_DEFAULTFROM', '');
 // copy outgoing mail to this folder. If not set z-push will try the default folders
 define('IMAP_SENTFOLDER', '');
 // forward messages inline (default off - as attachment)
 define('IMAP_INLINE_FORWARD', false);
 // use imap_mail() to send emails (default) - off uses mail()
 define('IMAP_USE_IMAPMAIL', true);


 // ************************
 // BackendMaildir settings
 // ************************
 define('MAILDIR_BASE', '/tmp');
 define('MAILDIR_SUBDIR', 'Maildir');

 // **********************
 // BackendVCDir settings
 // **********************
 define('VCARDDIR_DIR', '/home/%u/.kde/share/apps/kabc/stdvcf');

 // Alternative backend to perform SEARCH requests (GAL search)
 // if an empty value is used, the default search functionality of the main backend is used
 // use 'SearchLDAP' to search in a LDAP directory (see backend/searchldap/config.php)
 define('SEARCH_PROVIDER', '');

?>

Il ne reste plus qu'a paramétrer un mobile compatible activesync for Exchange à notre serveur Z-push.
  • username = adresse_mail
  • password= votre_mot_de_passe
  • domaine= adresse_mail
  • serveur= push.info16.fr


25 août 2011 4 commentaires

#Gnu/Linux

DomU en mode Nated et Domu en mode routed Xen 4 sur OpenSuse 11.3

info16natroute

Depuis pas mal de temps j'héberge mes différents serveur sur une plateforme de virtualisation Xen ( Gnu/Linux OpenSuse 11.3 )

Plateforme matérielle:

Dedibox QC
  • Serveur Dell® PowerEdge R210
  • CPU: 1x Intel® Xeon® X3450 4x 2.66GH
  • RAM: 8 Go DDR3 ECC
  • HDD: 2 x 1 To SATA2 Raid 0 / Raid 1 HARD
  • LAN: 1 Gbit/sec
Juqu'a maintenant j'utilisait la fonction NAT de Xen pour tout mes domU
Plateforme logicielle:
  • Dom0 Opensuse 11.3 X86_64 Xen 4
  • DomU(s) Ubuntu 10.04 X86_64 Paravirtualisé


Jusqu'a maintenant j'utilisait le nat/pat via des règles iptables pour faire communiquer mes DomU à l'extérieur: 

Ce schéma résume assez bien l'infra que j'ai mise en place:


En effet n'ayant qu'une adresse IP publique , 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

Je ne vais pas refaire l'arcticle que j'ai déjà fait mais en gros de base on modifie 

(network-script network-nat)

(vif-script 'vif-bridge bridge=br0')

Cela va permettre au lancement de Xen de mettre en place les règle nat à savoir le masquerading .
Le script vif-script quant à lui va permettre de rattacher l'interface de chaque DomU au bridge br0 à chaque lancement d'un DomU

Il faut bien sur aussi activer le routage sur le Dom0 afin qu'il puisse faire le routage entre les réseau 192.168.1.0 et l'extérieur.


Un exemple d'un fichier de DomU Linux:

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=0x31a console=tty0"

######DEV#########

vfb=[ 'type=vnc,vncunused=1', ]

disk=[ 'phy:/dev/vg0/lv2,xvda,w', 'phy:/dev/vg0/lv3,xvdb,w', ]

vif=[ 'type=netfront,mac=00:16:3a:11:11:00', ]

boot="c"

Tout ceci fonctionne en sortie sans problème, par contre il faut bien sur gérer les entrée avec iptables, en fonction des ports en écoute sur les différents DomU
Par exemple rediriger tous les flux à destination du port 25 vers l'ip locale 192.168.1.2/24

Voiçi un exemple des règles iptables que j'utilise:

$iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 25 -j DNAT --to 192.168.1.2:25
$iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 2222 -j DNAT --to 192.168.1.2:22
$iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 443 -j DNAT --to 192.168.1.2:443
$iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 7071 -j DNAT --to 192.168.1.2:7071
$iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 993 -j DNAT --to 192.168.1.2:993
$iptables -A PREROUTING -t nat -p udp -i eth0 --dport 993 -j DNAT --to 192.168.1.2:993
$iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 7025 -j DNAT --to 192.168.1.2:7025
$iptables -A PREROUTING -t nat -p udp -i eth0 --dport 7025 -j DNAT --to 192.168.1.2:7025

Cela fonctionne fort bien, si on cherche à joindre mon serveur de mail de l'extérieur, les paquets sont redirigés vers l'ip 192.168.1.2
Si mon serveur de mail veut causer à l'exterieur, il envoit à sa passerelle par défaut qui n'est autre que br0, le tout est routé et masqueradé pour aller à l'extérieur.


Tout cela fonctionnait à merveille, mais un amis m'a demandé, si je pouvais lui héberger son site Web/photo a grande audience sur ma plateforme.
Ce dernier en avait franchement marre du support et des performances de son hebergement mutualisé.

Certes je n'ai pas dit non puisque j'aime les défis.

Comme tout site Web, son site doit écouter sur le port 80, manque de pot j'ai déjà un site Web sur mon DomU wwwinfo16 qui écoute sur ce même port....

Plusieurs alternatives s'offre à moi:

  1. héberger son site sur mon serveur wwwinfo16 , avec la magie des vhosts, cela n'est pas compliqué
  2. Monter un serveur de reverse proxy type nginx et diriger soit tu mon serveur soit sur l'autre en fonction de la demande
  3. Activer une ip failover sur le serveur dedibox et l'attribuer à un DomU particulier qui sera en mode routed avec sa probre adresse IP publique
Comme j'aime les nouvelles expériences j'ai tenté l'option 3...

J'ai décidé de monter un nouveau serveur virtuel dédié au site de mon ami que nous appelerons siteclient qui aura sa propre adresse ip publique et qui utilisera le mode routed de Xen...
Ainsi de l'extérieur ce serveur sera totalement disponible sur cette ip publique ( tous les ports qu'on aura décider d'ouvrir)

On veut en fait faire cela:

routed


Tout cela est bien joli mais par quoi commencer ?

J'ai commencé par louer une adresse ip supplémentaire sur la dédibox afin d'avoir une autre ip publique.
Chez dédibox les routeur cisco sont configurés de telle sorte que chaque IP correspond à une adresse Mac bien particulière.

Autrement dit il faut absolument que mon ip publique failover  soit relié à une adresse mac Virtuelle Xen qui sera l'adresse mac du domU siteclient

La console dedibox est bien faite sur ce point, on choisi son ip publiqe failover et il nous fournisse une adresse mac virtuelle en fonction de notre plateforme de virtualisation.

dedi

On se retrouve avec notre ip et notre mac...

Le problème est que toute ma config est basée sur le nat et vif-bridge...

Il faut donc commencer par modfier le fichier /etc/xen/xend-config.sxp
On commente le network-script car on ne veut plus que les règles nat s'applique au lancement de xen

#(network-script network-nat)

(vif-script 'vif-bridge bridge=br0')

Par contre je laise le vif-script en bridge car je veux tout de même que par défaut mes vm soit attaché au bridge ( en effet la plupart des vm que je crées son en nat)

Dans ce cas comment xen va savoir si il faut faire du nat ou du routed pour les domU ??
Et bien c'est dans le fichier de conf de la vm qu'on va lui indiquer pour le mode routed.

Voici le fichier de conf  de siteclient:

######VM PARAM####

name="siteclient"

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=0x31a console=tty0"

#####PVM-SUSE#####

#builder="linux"

#bootloader = '/usr/lib/xen/boot/domUloader.py'

#bootargs = '--entry=hda1:vmlinuz-xen,initrd-xen'

#root="/dev/hda3"

######DEV#########

vfb=[ 'type=vnc,vncunused=1', ]

vif = ['type=netfront,mac=00:16:3e:00:00:28,script=vif-route,ip=88.190.x.x/32']

disk=[ 'phy:/dev/vg0/lv11,xvda,w','phy:/dev/vg0/lv12,xvdb,w', ]

boot="c"

Grace à cela xen va savoir précisément que la mac de la vm sera 00:16:3e:00:00:28 et qu'il devra router l'ip 88.190.x.x/32

Après avoir préparé votre DomU comme d'habitude avec un template de Ubuntu 10.04, il reste une derniere chose importante à faire, configurer la conf réseau au sein même du domU
Notemment l'ip et la passerelle...

Voici un extrait du fichier /etc/network/interfaces de la vm site client.

auto eth0

iface eth0 inet static

    address 88.190.x.x # votre ip failover 

    netmask 255.255.255.0

    network 88.190.224.0

    broadcast 88.190.224.255


    post-up route add -host 88.190.14.1/32 dev eth0

    post-up route add default gw 88.190.14.1



Attention c'est la que ca se complique, la passerelle de votre domU est en fait la même que votre Dom0 d'ou les post-up pour créer des routes statiques.

Pour finir, il ne faut pas oublier que l'on à commenté le network-nat de Xen par conséquent il va falloir creer des règles iptables afin que nos domU nats fonctionnent toujours:

notemment:

echo 1 > /proc/sys/net/ipv4/ip_forward

$iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j  MASQUERADE

Oui en effet on ne veut plus tout masqueradé.. seulement les paquet en provenance de 192.168.1.0


De même si vous vous souvenez les paquets qui arrivent de l'extérieur à destination de votre ip publique vers le port 80 (failover ou pas d'ailleurs) sont redirigés vers 192.168.1.1

Mais cela n'est plus souhaitable, puisque des paquets à destination de siteclient vont aussi arriver sur le port 80

Iptables doit dont distinguer les 2, c'est pour cela qu'il faut etre plus préçis dans nos règles nat et distinguer a qui sont destiner les paquets, l'ip publique ou l'ip failover:

$iptables -t nat -A PREROUTING -i eth0 -p tcp -d 88.190.14.x --dport 80 -j DNAT --to-destination 192.168.1.1:80 #ip publique

ainsi seul les paquets à destination de mon ip publique de base seront natés vers mon domU web :)



 

27 juillet 2011 Aucun commentaire

#Gnu/Linux

Apache2 VS Cherokee

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.
27 juillet 2011 2 commentaires

#Gnu/Linux

Ajout de route statique par DHCP

J'ai eut besoin récemment d'ajouter des routes statiques sur un ensemble de poste clients. Plutôt que de passer par un script de demarrage, j'ai essayé de faire cela grace au serveur DHCP. Voiçi le fichier dhcpd.conf qui en découle. 

root@web-router:~# cat /etc/dhcp3/dhcpd.conf
default-lease-time 86400;
max-lease-time 86400;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.100.255;
option domain-name "mouthiers.priv";
option ms-classless-static-routes code 249 = array of integer 8;
option ms-classless-static-routes 24, 192, 168, 1, 192, 168, 100, 254,
24, 192, 168, 50, 192, 168, 100, 254;
allow unknown-clients;
option domain-name-servers 192.168.1.213;
option netbios-name-servers 192.168.1.213;
subnet 192.168.100.0 netmask 255.255.255.0 {
 range 192.168.100.1 192.168.100.20;
}
ici on ajoute 2 routes statiques sur le client: pour le réseau 192.168.1.0/24 on passe par la passerelle 192.168.100.254 Pour le réseau 192.168.50.0/24 on passe par la passerelle 192.168.100.254 dans 24, 192, 168, 1, 192, 168, 100, 254, on défini le masque de sous réseau (24), le réseau à joindre, et la passerelle.

27 juillet 2011 4 commentaires

#Gnu/Linux

Comparaison des formats de compressions Gnu/Linux

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**** 

# 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
27 juillet 2011 Aucun commentaire
Fil RSS des articles de cette catégorie