Catégories
Blog Open-source Web

Le panier du marché libre #6

Sixième édition du marché libre. On prends son petit panier et on va glaner les liens suivants:

Bon week-end à vous !

Catégories
Open-source Planet-libre Reseau Web

Installation automatique de NGinx, PHP-FPM, MemCached sous Debian

Au début du mois nous avons vu ensemble l’installation d’un serveur NGinx sous Ubuntu. Sous Debian,  il faut mettre un peu plus les mains dans le cambouis, en effet il est parfois utile de partir des sources plutôt que des dépôts officiels (notamment au niveau de la présence ou non d’un module).

J’ai donc développé un petit script shell pour automatiser l’installation (ou la mise à jour) d’un serveur Web rapide, léger et performant sous une Debian (Squeeze ou Lenny).

Ce script va effectuer les choses suivantes:

Il est bien sûr possible d’adapter ce script à vos besoins et de l’utiliser comme bon vous semble. Si vous rencontrez des erreurs ou que vous avez en tête des améliorations possibles, merci de laisser un commentaire en bas de ce billet.

Récupération du script

Le script est disponible dans mon GitHub:

NGinxAutoInstall.sh

Vous pouvez également faire ces actions en ligne de commande dans un terminal:

wget https://raw.github.com/nicolargo/debianpostinstall/master/nginxautoinstall.sh

Il faut ensuite le rendre exécutable:

chmod a+x ./nginxautoinstall.sh

Lancement du script

Il faut lancer le script en root (droit d’administration):

su - -c "$PWD/nginxautoinstall.sh"

Si tout se passe correctement, le script devrait afficher:

Validation et test de performances

Votre serveur est maintenant opérationnel, il vous reste à mettre vos page HTML et scripts PHP dans le répertoire /var/www et tester le tout en entrant l’URL suivante dans un navigateur Web: http://@devotreserveur/.

Vous pouvez également tester les performances brutes de votre serveur en utilisant HTTPerf (disponible dans les dépôts Debian). Sur mon serveur de test (VPS Gandi 1 part), j’obtiens les perfos suivantes:

httperf –client=0/1 –server=localhost –port=80 –uri=/ –send-buffer=4096 –recv-buffer=16384 –num-conns=5000 –num-calls=10

Request rate: 6833.4 req/s (0.1 ms/req)

Conclusion

Avec NGinx, on obtient rapidement de très bonnes performances et le couple PHP-FPM, MemCached permet d’avoir une bonne base pour héberger, par exemple, votre blog WordPress (lire l’article sur le sujet dans ce blog).

Je suis bien sur preneur de tous commentaires/remarques sur le script.

Catégories
Blog Open-source Planet-libre Reseau Systeme Web

Sécuriser son blog WordPress #3

WordPress n’a pas forcement bonne presse au niveau de la sécurité. Le coeur PHP du moteur WordPress est pourtant surveillé de très près et les corrections des failles sont assez rapides (voir par  exemple la publication de la version 3.0.4).

Par contre les plugins, qui sont un avantage indéniable de WordPress par rapport aux autres CMS, sont également un talon d’Achille… En effet, WordPress dispose d’une base de plugins impressionnante (plus de 12.700 au moment de l’écriture de ce billet) dont les développeurs sont plus ou moins sensibilisés à la problématique de la sécurité… Ajouter des plugins à votre blog, c’est multiplier les risques au niveau de la sécurité.

Dans ce billet, nous allons voir comment installer puis configurer WordPress pour compliquer la tache des personnes voulant attaquer votre blog.

Je vous rappelle que cet article est découpé en plusieurs billets (vous êtes en train de lire le #3):

Cette série de billets a été co-écrite avec Jérémie Marguerie étudiant à EPITA (merci à lui !).

Partir sur de bonnes bases

Nous allons détailler l’installation, la configuration initiale puis la gestion des mises à jours de WordPress.

    Installation de WordPress

    Personnellement j’utilise sur mon serveur deux versions de WordPress en parallèle.

    La première est celle du blog « de production » (celui que vous êtes en train de lire) utilise la version stable SVN (c’est à dire la 3.0.4 au jour d’aujourd’hui). J’utilise la commande suivante pour effectuer l’installation (dans le répertoire racine de mon serveur Web: /var/www/blog):

    svn co http://core.svn.wordpress.org/branches/3.0/

    La seconde, dite « de validation » me sert pour tester mon blog (thème et plugins) sur les futures versions de WordPress (3.1 par exemple). Elle n’est pas publique, seul les administrateurs peuvent y accéder. Pour installer cette version de WordPress, j’utilise la commande suivante dans un deuxième répertoire de mon serveur Web (/var/www/blogfutur):

    svn co http://core.svn.wordpress.org/trunk/

    Avant de suivre la fameuse installation en 5 minutes de WordPress, je vous conseille de changer le préfixe des tables MySQL en éditant la ligne suivante dans votre fichier de configuration wp-config.php et en remplacant wp_ par une chaine aléatoire (par exemple apvbty_):

    $table_prefix  = ‘apvbty_’;

    Attention, cette manipulation est à faire seulement sur un nouveau blog. En effet, si vous avez déjà une base de donnée SQL existante il faut d’abord changer le nom du préfixe des tables dans MySQL (voir hack en fin de billet) sous peine de ne plus pouvoir accéder à vos données.

    Une fois l’installation de WordPress finalisée, nous allons commencer par fixer les droits au niveau des fichiers dans ces répertoires. En partant sur l’hypothèse ou votre serveur Web tourne sous l’utilisateur www-data et dans le répertoire /var/www/blog, j’utilise les commandes suivantes:

    chown -R www-data:www-data /var/www/blog

    find /var/www/blog -type d -exec chmod 755 {} \;

    find /var/www/blog -type f -exec chmod 644 {} \;

    chmod 640 /var/www/blog/wp-config.php

    find /var/www/blog/wp-content/themes -type d -exec chmod 775 {} \;

    find /var/www/blog/wp-content/themes -type f -exec chmod 664 {} \;

    Pour vous simplifier la vie, je vous conseille de mettre ces commandes dans un script shell afin de pourvoir rapidement les appliquer sur votre arborescence.

    Mise à jour de WordPress

    Comme nous l’avons vu, les développeurs de WordPress sont assez réactifs sur la correction des failles de sécurité. Encore faut-il que vous pensiez à mettre à jour votre instance de WordPress…

    J’utilise un script shell pour mettre à jour WordPress à partir de SVN:

    #!/bin/bash

    # Simple script pour mettre a jour WordPress

    # Test que le script est lance en root

    if [ $EUID -ne 0 ]; then

    echo « Le script doit être lancé en root: # sudo $0″ 1>&2

    exit 1

    fi

    WPPATH= »/var/www/blog »

    echo « 1) Mise a jour de WordPress »

    cd $WPPATH 2>&1 /dev/null

    CURRENTVERSION=`svn info | grep « Revision:  » | awk ‘{ print $2 }’`

    svn update

    rm $WPPATH/wp-admin/install.php

    cd – 2>&1 /dev/null

    echo « 2) Verification des droits des fichiers »

    chown -R www-data:www-data $WPPATH

    find $WPPATH -type d -exec chmod 755 {} \;

    find $WPPATH -type f -exec chmod 644 {} \;

    chmod 640 $WPPATH/wp-config.php

    find $WPPATH/wp-content/themes -type d -exec chmod 775 {} \;

    find $WPPATH/wp-content/themes -type f -exec chmod 664 {} \;

    echo « 3) Fin de la mise a jour »

    echo « En cas de pb: svn update -r$CURRENTVERSION »

    Il est possible de lancer ce script toutes les nuits (par exemple par crontab) pour éviter de se retrouver avec un blog hacké quand vous partez en congés

    Le .htaccess

    Ce fichier qui doit se trouver à la racine de votre site Web, contient des entrées utiles à la sécurité de votre site. Le mien commence par:

    # MAIN

    RewriteEngine On

    ServerSignature Off

    Options All -Indexes

    Options +FollowSymLinks


    # SVN protect

    RewriteRule ^(.*/)?\.svn/ – [F,L]


    # Secure .htaccess

    <Files .htaccess>

    Order Allow,Deny

    Deny from all

    </Files>


    # Secure wp-config.php

    <Files wp-config.php>

    Order Deny,Allow

    Deny from all

    </Files>


    # FILTER REQUEST

    <IfModule mod_rewrite.c>

    RewriteBase /

    RewriteCond %{REQUEST_FILENAME} !-f

    RewriteCond %{REQUEST_FILENAME} !-d

    RewriteRule . /index.php [L]

    </IfModule>

    Certains plugins ajoutent pas mal de chose dans ce fichier (notamment W3 Total Cache, le plugin d’optimisation des performances que j’ai abordé dans ce billet).

    Un peu de bon sens…

    Vous avez donc entre les mains une installation toute propre et sécurisée de WordPress, c’est normalement à partir de ce moment là que les choses se gâtent…

    On commence par l’erreur de base: ne pas utiliser un mot de passe « strong » pour le compte admin. Encore mieux, créer un nouveau compte administrateur et supprimer le compte admin par défaut.

    L’installation des plugins apportent également son lot de failles de sécurité. C’est là qu’il faut se faire violence et n’installer que les plugins indispensables au bon fonctionnement de votre blog. Il faut également veiller à mettre à jour régulièrement vos plugins (l’interface d’administration de WordPress permet de faire cela très simplement).

    Enfin vos thèmes peuvent également fragiliser votre blog en insérant des codes PHP ou JS. Si vous avez les compétences il faut faire un audit de votre thème ou au minimum utiliser des thèmes connus et validés.

    Des plugins pour la sécurité

    Parmis ces plugins, j’en utile trois dédiés à la sécurisation:

    • Secure WordPress permet d’automatiser certaines actions pour sécuriser votre blog.

    • WordPress File Monitor: Surveille les fichiers du moteur WordPress et vous alerte (par mail et/ou directement dans l’interface d’administration de WordPress) en cas de modification.
    • On peut également citer WordPress Security Scan qui permet de faire un audit de votre blog en testant notamment les droits de vos fichiers, les mots de passes, la base de données…

    Quelques hacks en bonus

    Compliquer la tache des attaques par force brute en supprimant l’indicateur (« mauvais mot de passe ») lors d’une tentative de connexion à l’interface d’administration. Il faut juste ajouter la ligne suivante à votre fichier functions.php (thème):

    add_filter(‘login_errors’, create_function(‘$a’, « return null; »));

    Si vous avez une base de données MySQL existante avec le préfixe par défaut (wp_) et que vous souhaitez le changer, il est possible de faire celà directement à la main par une requête MySQL ou alors plus simplement en utilisant le plugin WP-Security-Scan.

    Tester votre WordPress

    Pour tester la sécurité de votre blog, rien ne vaut une simulation d’attaque. Pour celà vous pouvez utiliser le logiciel libre Nikto.

    On commence par installer Nikto sur un PC client sous Ubuntu (qui va simuler l’attaque):

    sudo aptitude install nikto

    Puis on lance le test (remplacer URL par l’URL de votre blog WordPress):

    nikto -h URL

    Le rapport devrait ensuite s’afficher.

    Sources:

    Catégories
    Hardware Open-source Planet-libre Reseau Systeme Web

    Cours d’introduction au « Cloud Computing »

    En début de semaine, j’ai été emmenée à donner un cours d’introduction aux technologies de Cloud Computing à l’école supérieure des ingénieurs de Luminy (ESIL à Marseille). Le sujet étant vaste pour les trois petites heures imparties, j’ai préféré axer mon cours sur certains aspects (notamment les architectures IAAS et l’utilisation de technologies ouvertes et libres).

    Pour ceux que cela intéresse, voici (sous licence « CC By:« ):

    Au passage un grand merci à Philippe Scoffoni pour sa relecture et ses remarques.

    Catégories
    Open-source Planet-libre Web

    Un serveur Jabber en 5 minutes chronos sous Debian/Ubuntu

    Oui je sais c’est un pompage en règle du billet de Cyrille Borne. Mais bon il faut dire que par les temps qui courent c’est une rudement bonne idée que de disposer de son propre serveur Jabber.

    Nous allons donc détailler les étapes d’installation et de configuration d’un serveur Prosody dans sa dernière version (0.7) avec un chiffrement SSL entre les clients et le serveur.

    Pourquoi Prosody et pas Jabber ? Tout simplement car il est bien plus simple et léger à installer (un peu trop usine à gaz). Et puis le titre du billet aurait été moins vendeur: « Un serveur Jabber en 3h45 chronos… ».

    Installation de Prosody

    L’installation de Prosody se fait en utilisant les commandes suivantes:

    echo « deb http://packages.prosody.im/debian stable main » | sudo tee -a /etc/apt/sources.list

    wget http://prosody.im/files/prosody-debian-packages.key -O- | sudo apt-key add –

    sudo aptitude update

    sudo aptitude install prosody

    Sous Ubuntu 10.04, j’ai du en plus installer à la main la librairie LibLua (pour le SSL):

    wget http://prosody.im/downloads/debian/liblua5.1-sec0_0.3.2-2prosody1_i386.deb

    sudo dpkg -i liblua5.1-sec0_0.3.2-2prosody1_i386.deb

    PS: la librairie LibLua est utilisé pour le chiffrement SSL. Le fichier liblua5.1-sec0_0.3.2-2prosody1_amd64.deb doit être utilisé pour les machines sous AMD 64 bits.

    On génère la clés et le certificat SSL:

    cd /etc/prosody/certs/

    sudo openssl req -new -x509 -days 365 -nodes -out « monbeaudomaine.com.cert » -keyout « monbeaudomaine.com.key »

    Configuration de Prosody

    Puis on configure en éditant le fichier /etc/prosody/prosody.cfg.lua:

    sudo vi /etc/prosody/prosody.cfg.lua

    VirtualHost « monbeaudomaine.com »

    ssl = {

    key = « /etc/prosody/certs/monbeaudomaine.com.key »;

    certificate = « /etc/prosody/certs/monbeaudomaine.com.cert »;

    }

    enabled = true;

    On relance Prosody pour prendre en compte la configuration:

    sudo /etc/init.d/prosody restart

    Si vous avez un Firewall sur votre serveur (ce qui est une bonne idée), il faut penser à ouvrir les ports TCP de Jabber en ajoutant les lignes suivantes dans votre script de configuration iptable (/etc/init.d/iptables.sh dans mon cas):

    iptables -A INPUT -p tcp –dport 5222 -j ACCEPT

    iptables -A INPUT -p tcp –dport 5269 -j ACCEPT

    iptables -A OUTPUT -p tcp –dport 5269 -j ACCEPT

    On relance ensuite le Firewall:

    sudo /etc/init.d/iptables.sh

    Puis on vérifie que les règles existent:

    sudo iptables -L | grep xmpp

    ACCEPT tcp — anywhere anywhere tcp dpt:xmpp-client

    ACCEPT tcp — anywhere anywhere tcp dpt:xmpp-server

    ACCEPT tcp — anywhere anywhere tcp dpt:xmpp-server

    Création d’un compte utilisateur Jabber dans Prosody

    On peut ensuite passer à la création d’un utilisateur Jabber:

    sudo prosodyctl adduser monbeauuser@monbeaudomaine.com

    Il faut saisir deux fois le même mot de passe…

    Configuration d’un client Jabber pour utiliser votre serveur Prosody

    Enfin, sur son/ses PC, on configure le client de chat (Pidgin dans mon cas).

    Il faut aller dans le menu Comptes > Gérer les comptes puis cliquer sur le bouton Ajouter:

    Et hop voili !

    Catégories
    Blog Open-source Web

    Le panier du marché libre #5

    Un très bon marché libre cette semaine, glané dans mon flux RSS, mon Twitter et un peu dans Quora que je teste depuis la fin de la semaine dernière.

    D’autres choses importantes de votre coté ?

    Catégories
    Blog Open-source Web

    11 sites pour votre veille technologique sur le libre

    Il y a quelques jours, j’ai poser la question suivante sur Twitter, Identi.ca, facebook et Quora:

     » Quels sont vos principales sources d’informations concernant les logiciels libres (sites, blogs…) ? « 

    Voici un résumé des réponses.

    Les sites spécialisés

    GCU-Squad

    Depuis plus de 10 ans, l’agrégateur de billet GCU Squad arrive encore à trouver des titres décalés 🙂 Une source indispensable pour les sysadmins :).

    >>> http://gcu.info/ <<<

    FramaBlog

    Le blog de Framasoft, LE défenseur des logiciels libres en France.

    >>> http://www.framablog.org/index.php <<<


    LinuxFR

    Le principe de ce site est le suivant. Les utilisateurs proposes des news dans le domaine des logiciels libres. Les news sont validés par une équipe avant publication assurant ainsi une sélection aux petits oignons…

    >>> http://linuxfr.org/ <<<



    Ars Technica

    Site bien connu en Anglais ayant une section open-source. Orienté grand public plutôt que geek acharnés.

    >>> http://arstechnica.com/open-source/ <<<


    Le blog de Philippe Scoffoni

    Même si Philippe est plus connu pour ces billets fleuves et philosophique sur le monde des logiciels libres, il est en plus une très bonne source d’informations pour la combo « Cloud + Open-source ». Un must have dans votre agrégateur RSS.

    >>> http://philippe.scoffoni.net/ <<<


    Webynux

    Le titre de ce blog est « L’actualité du logiciel libre », il ne pouvait pas être absent de ma sélection 🙂

    >>> http://www.webynux.net/ <<<


    NixCraft

    Un site en Anglais sur des « tips & tricks » quotidiens sur les environnements Linux et BSD.

    >>> http://www.cyberciti.biz/ <<<


    Planet-Libre

    Je ne vous fais pas l’affront de vous le présenter…

    >>> http://www.planet-libre.org/ <<<

    Les généralistes

    Numerama

    Porte parole des anti-hadopi. Il aborde également certaines actualités sur le monde des logiciels libres.

    >>> http://www.numerama.com/ <<<


    PC Inpact

    On y parle hard, soft mais aussi libre (en filtrant bien ;))

    >>> http://www.pcinpact.com/ <<<

    ZDNet

    Du sérieux, du posé… Orienté pour les entreprises.

    >>> http://www.zdnet.fr/dossier/open-source.htm <<<

    Catégories
    Open-source Web

    Le panier du marché libre #4

    Premier marché libre de l’année 2011 avec des perles découvertes pendant la pause de noël !

    Et vous, quelles découvertes dans vos bookmarks ?

    Catégories
    Developpement Open-source Planet-libre Reseau Web

    Installation et test de NGinx sous Ubuntu

    NGinx est une des alternative au serveur Web Apache (il est actuellement utilisé par plus de 6% des serveurs Web). Il se targue d’être plus rapide, plus léger et facile à configurer.

    Nous allons vérifier tout cela dans ce billet en détaillant une installation de NGinx 0.8.54 (Stable) sur une machine GNU/Linux (Ubuntu Desktop 10.10) avec en bonus le support FastCGI de PHP et de Perl !

    Installation de NGinx

    On commence par ajouter le dépôt officiel pour la version stable:

    sudo add-apt-repository ppa:nginx/stable

    sudo aptitude update

    Puis on installe la bête (facile non ?):

    sudo aptitude install nginx

    Remarque: si un serveur Web (Apache ou autre) tourne déjà sur votre machine, l’installation de NGinx se passera normalement, par contre il n’arrivera pas à se lancer car le port HTTP par défaut (TCP/80) sera déjà occupé. La solution la plus propre est de configurer NGinx pour qu’il écoute sur un autre port (TCP/81 par exemple) puis faire vos tests en forcant l’utilisation de ce port dans votre navigateur Internet (en ajoutant :81 aux URL). Une fois Nginx validé, il suffira de supprimer l’autre serveur Web de votre machine, puis de reconfigurer Nginx sur le port par défaut (TCP/80).

    Premier contact avec NGinx

    Un script de démarrage nommé nginx a été installé dans le répertoire /etc/init.d. On peut voir la liste des commandes accepté par ce script en saisissant la ligne de commande suivante:

    sudo service nginx

    Usage: nginx {start|stop|restart|reload|force-reload|status|configtest}

    On va donc activer la configuration de test:

    sudo service nginx configtest

    Testing nginx configuration: nginx.

    Puis lancer le serveur:

    sudo service nginx start

    Starting nginx: nginx.

    On ouvre un navigateur sur la même machine puis on entre l’UTL suivante: http://localhost/

    La page suivante devrait s’afficher:

    On peut ensuite arrêter le serveur:

    sudo service nginx stop

    Stopping nginx: nginx.

    Puis passer à l’étape suivante…

    Configuration du serveur NGinx

    Les fichiers de configuration se trouvent dans le répertoire /etc/nginx. Les habitués d’Apache ne seront pas trop perturbés par la structure de l’arborescence de ce répertoire:

     

    drwxr-xr-x 2 root root 4096 2011-01-05 08:26 conf.d/

    -rw-r–r– 1 root root 884 2011-01-05 08:04 fastcgi_params

    -rw-r–r– 1 root root 2258 2011-01-05 08:04 koi-utf

    -rw-r–r– 1 root root 1805 2011-01-05 08:04 koi-win

    -rw-r–r– 1 root root 2066 2011-01-05 08:04 mime.types

    -rw-r–r– 1 root root 1340 2011-01-05 08:04 nginx.conf

    -rw-r–r– 1 root root 465 2011-01-05 08:04 scgi_params

    drwxr-xr-x 2 root root 4096 2011-01-05 10:36 sites-available/

    drwxr-xr-x 2 root root 4096 2011-01-05 10:36 sites-enabled/

    -rw-r–r– 1 root root 497 2011-01-05 08:04 uwsgi_params

    -rw-r–r– 1 root root 3071 2011-01-05 08:04 win-utf

    On y retrouve (entre autres):

    • nginx.conf: le fichier de configuration central
    • conf.d/: un répertoire contenant des fichiers de configuration additionnels
    • sites-available/: répertoire contenant la liste des fichier de configuration des sites disponibles
    • sites-enabled/: répertoire contenant la liste des fichiers de configuration des sites actifs (liens symboliques vers le répertoire site-availables)

    On commence par jeter un coups d’oeil au fichier nginx.conf…. Quel bonheur par rapport à celui d’Apache :).

    On passe ensuite au fichier du site par défaut /etc/nginx/sites-available/default (que l’on a activé tout à l’heure par la commande ‘sudo service nginx configtest’):

    server {

    listen 80

     

    root /usr/share/nginx/www;

    index index.html index.htm;

     

    server_name localhost;

     

    location / {

    try_files $uri $uri/ /index.html;

    }

     

    location /doc {

    root /usr/share;

    autoindex on;

    allow 127.0.0.1;

    deny all;

    }

     

    location /images {

    root /usr/share;

    autoindex off;

    }

     

    }

    On peut donc voir que l’on a un site qui écoute sur le port TCP/80 (listen   80) et sert les pages se trouvant dans le répertoire /usr/share/nginx/www (root /usr/share/nginx/www) à partir de l’URL http://localhost/ (server_name localhost).

    Nous allons nous baser sur cet exemple pour construire un nouveau fichier de configuration propre à nos besoins.

    On commence par créer l’arborescence qui va héberger nos pages (par exemple /home/labo/www). Si le répertoire n’existe pas il faut le créer et lui donner les bons droits:

    mkdir /home/labo/www

    Enfin on édite une page de test:

    # vi /home/labo/www/index.html

    <html><body>Ma page</body></html>

    Ensuite on passe à la création du fichier de configuration du site.

    sudo vi /etc/nginx/sites-available/monsite

    Avec le contenu suivant (à adapter à votre configuration):

    # Mon site a moi

     

    server {

    listen 80;

     

    root /home/labo/www;

    index index.html index.htm;

     

    server_name localhost;

     

    location / {

    # First attempt to serve request as file, then

    # as directory, then fall back to index.html

    try_files $uri $uri/ /index.html;

    }

     

    }

    On supprime le site par defaut et on active le notre:

    cd /etc/nginx/sites-enabled

    sudo rm default

    sudo ln -s ../sites-available/monsite

    On redémarre le serveur Nginx:

    sudo service nginx restart

    Restarting nginx: nginx.

    Puis  on teste la page: http://localhost/

    Pour rendre le site « visible depuis l’extérieur », il faut changer la ligne:

    server_name localhost;

    Puis la remplacer par:

    server_name www.mondomaine.com;

    Il faut bien sur que le nom www.mondomaine.com pointe sur l’adresse IP de votre serveur Nginx…

    Test des performances

    Pour voir ce qu’il a dans le ventre, j’ai installé en Nginx et Apache sur ma machine. Nginx écoutant sur le port TCP/81 et Apache sur le port TCP/80.

    J’ai ensuite utilisé le logiciel httperf (disponible dans les dépôts Ubuntu) pour simuler des requêtes sur le serveur.

    Test du serveur Apache:

    # httperf –client=0/1 –server=localhost –port=80 –uri=/ –send-buffer=4096 –recv-buffer=16384 –num-conns=5000 –num-calls=10

    Request rate: 4284.8 req/s (0.2 ms/req)

    Puis test du serveur NGinx:

    # httperf –client=0/1 –server=localhost –port=81 –uri=/ –send-buffer=4096 –recv-buffer=16384 –num-conns=5000 –num-calls=10

    Request rate: 6332.6 req/s (0.2 ms/req)

    On a donc un gain d’environ 30% en terme de requêtes supportées par le serveur.

     

     

    Request rate / Request number

     

    Support du PHP

    De nos jours, un serveur Web sans support PHP c’est un peu comme un Ferrari avec des roues de 13 pouces. Dans l’optique d’avoir un serveur performant nous allons donc utiliser le module externe PHP FPM (PHP FastCGI) qui s’occupera de l’exécution des scripts PHP dans un processus indépendant de NGinx (merci à cet article qui m’a bien aidé).

    On commence par installer le module:

    sudo add-apt-repository ppa:brianmercer/php

    sudo aptitude update && sudo aptitude install php5-fpm

    Par défaut, le processus PHP-FPM va se mettre en écoute sur le port TCP/9000 et écouté les requêtes venant seulement de la machine locale (localhost).

    Il ne reste plus qu’à modifier le fichier de configuration de votre site pour prendre en compte le langage PHP (fichier /etc/nginx/sites-available/monsite):

    # Mon site a moi

    server {

    listen 80;

    server_name localhost;

    root /home/labo/www;

     

    location / {

    index index.php index.html;

    }

     

    location ~ \.php$ {

    fastcgi_pass 127.0.0.1:9000;

    include /etc/nginx/fastcgi_params;

    fastcgi_index index.php;

    }

    }

    Attention de bien avoir configurer la variable root (« root /home/labo/www » dans mon exemple), sinon vous risquez de tomber sur une erreur 404 lors du passage du script PHP vers le process PHP-FPM.

    On relance ensuite Nginx:

    sudo service nginx restart

    Restarting nginx: nginx.

    Pour tester que le PHP fonctionne bien, le plus simple est de créer un fichier info.php (à mettre à la racine du site /home/labo/www/) contenant:

    <?php

    phpinfo();

    ?>

    Puis de pointer votre navigateur Web vers l’URL: http://localhost/info.php

    La page suivante devrait s’afficher:

    Support de Perl

    Tout comme PHP, nous allons utiliser FastCGI pour exécuter les scripts Perl depuis notre serveur NGinx. Le principe est le même. Un processus (fastcgi-wrapper.pl) va se mettre en écoute sur le port TCP/8999 puis attendre les demandes d’exécution envoyées par NGinx.

    Contrairement à PHP, il n’existe pas (encore) de package Ubuntu permettant d’automatiser l’installation de ce processus. Il faut donc mettre un peu les mains dans le cambouis (merci à ce blog) !

    On commence par installer le module Perl FCGI sur lequel le processus fastcgi-wrapper.pl va se baser:

    sudo perl -MCPAN -e ‘install FCGI’

    On installe le processus fastcgi-wrapper.pl qui va s’occuper de l’exécution  des scripts Perl:

    sudo wget -O /usr/bin/fastcgi-wrapper.pl http://lindev.fr/public/nginx/fastcgi-wrapper.pl

    sudo chmod 755 /usr/bin/fastcgi-wrapper.pl

    La plupart des tutos que j’ai trouvé sur le Net utilise ensuite un script init.d pas très beau à voir (http://lindev.fr/public/nginx/perl-fastcgi). En effet, pour arrêter le processus on a droit à un beau killall -9 perl ! Autant dire que si vous avez d’autres processus Perl en tache de fond de votre serveur cela risque de poser quelques problèmes :). J’ai donc écrit un nouveau script basée sur celui du wrapper PHP.

    On automatise le lancement de ce script au démarrage du serveur:

    sudo wget -O /etc/init.d/perl-fastcgi https://raw.github.com/nicolargo/ubuntupostinstall/master/perl-fastcgi

    sudo chmod 755 /etc/init.d/perl-fastcgi

    sudo update-rc.d perl-fastcgi defaults

    Puis on le lance en tache de fond:

    sudo service perl-fastcgi start

    Il ne reste plus qu’à modifier le fichier de configuration Nginx de votre site pour prendre en compte les scripts Perl:

    # Mon site a moi

    server {

    listen 80;

    server_name localhost;

    root /home/labo/www;

     

    location / {

    index index.php index.html;

    }

     

    location ~ \.php$ {

    fastcgi_pass 127.0.0.1:9000;

    include /etc/nginx/fastcgi_params;

    fastcgi_index index.php;

    }

     

    location ~ \.pl$ {

    fastcgi_pass 127.0.0.1:8999;

    include /etc/nginx/fastcgi_params;

    fastcgi_index index.pl;

    }

    }

    On relance ensuite Nginx:

    sudo service nginx restart

    Restarting nginx: nginx.

    Pour tester que le Perl fonctionne bien, le plus simple est de créer un fichier info.pl (à mettre à la racine du site /home/labo/www/) contenant:

    #!/usr/bin/perl

    print « Content-type: text/html\n\n »;

    print « <html><body>Hello, world.</body></html> »;

    Attention, contrairement au script PHP, les fichier .pl douivent avoir les droits en exécution sous peine de ce trouver devant le message suivant:

    Error: No such CGI app – /home/labo/www/info.pl may not exist or is not executable by this process.

    On doit donc saisir la commande:

    chmod a+x /home/labo/www/info.pl

    Puis de pointer votre navigateur Web vers l’URL: http://localhost/info.pl

    La page suivante devrait s’afficher:

    Optimisation corner !

    On passe maintenant à quelques optimisations que l’on peut ajouter à la configuration de son site (merci à @T1B0).

    On commence par le fait de ne pas loguer les message 404 sur le fichier favicon.ico (histoire de ne pas surcharger ses logs):

    location = /favicon.ico {

    access_log off;

    return 204;

    }

    Ensuite on optimise la durée d’expiration des en-tête des fichiers statiques (pour les caches):

    location ~* ^.+\.(jpg|jpeg|gif|css|png|js|xml)$ {

    expires 30d;

    }

    Pour aller plus loin, vous pouvez également lire ce billet chez K-Tux. (notamment l’utilisation de memcache qui est intégré à NGinx !).

    Conclusion

    Vous avez donc à votre disposition un beau serveur Web NGinx avec le support FastCGI PHP & Perl !

    Elle est pas belle la vie ?

    Catégories
    Blog Open-source Planet-libre Systeme Web

    4 hacks pour extraire des statistiques de WordPress

    C’est le début de l’année et le moment des bilans concernant les statistiques de votre blog. Voici donc un petit billet sur quelques hacks MySQL permettant d’obtenir des statistiques à diffuser vers vos lecteurs ou à garder au chaud !

    Avant tout il faut disposer d’un accès à votre base de donnée MySQL (soit via une interface de type phpMySQL, soit directement via une ligne de commande mysql). Pour avoir vos paramètres de connexion à votre BD WordPress il suffit de regarder le fichier wp-config.php à la racine de votre répertoire Web.

    Voici l’architecture des tables de votre BD WordPress. Je ne suis plus trop un expert en requêtes MySQL (les cours datent de plus de 10 ans maintenant ;)) alors si vous voyez des améliorations dans les requêtes ci-dessous je suis preneur de commentaires.

    Nombre de billets publiés en 2010

    Cette première requête donne le nombre de billets publiés (status= »publish ») sur l’année 2010 (c’est à dire entre le 1er janvier et le 31 décembre 2010).

    mysql> SELECT COUNT(*) FROM wp_posts WHERE post_status= »publish » AND post_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’;

    +———-+

    | COUNT(*) |

    +———-+

    | 161 |

    +———-+

    1 row in set (0.00 sec)

    Nombre de commentaires pour les billets publiés en 2010

    Une requête un peu plus complexe qui somme (SUM) le nombre de commentaires pour les billets 2010.

    mysql> SELECT SUM(comment_count) FROM wp_posts WHERE post_status= »publish » AND post_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’ GROUP BY post_status;

    +——————–+

    | SUM(comment_count) |

    +——————–+

    | 1314 |

    +——————–+

    1 row in set (0.01 sec)

    Liste des 10 billets les plus commentés publiés en 2010

    On continu pas le classement (TOP 10) des nouveaux billets les plus commentés.

    mysql> SELECT post_title,comment_count FROM wp_posts WHERE post_status= »publish » AND post_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’ ORDER BY comment_count DESC LIMIT 0,10;

    +——————————————————————-+—————+

    | post_title | comment_count |

    +——————————————————————-+—————+

    | Configurer VPNTunnel sous Ubuntu | 58 |

    | Installation et test de Flumotion 0.8 | 46 |

    | Script d’installation automatique de Nagios | 42 |

    | Spideroak, un sérieux concurrent à Dropbox | 40 |

    | Utiliser Nmap pour générer vos fichiers de configuration Nagios | 38 |

    | Installation d’un serveur OpenVPN sous Debian/Ubuntu | 36 |

    | 12 étapes pour optimiser les performances de son blog WordPress | 35 |

    | Le blog de Nicolargo a son application IOS | 35 |

    | Tu fais quoi après l’installation de Firefox ? | 26 |

    | MyScreenCast, comment faire du screencast avec GStreamer | 26 |

    +——————————————————————-+—————+

    10 rows in set (0.01 sec)

    Top 10 des lecteurs ayant le plus posté de commentaires sur le blog en 2010

    Enfin une requête un peu plus complexe qui donne le classement des plus gros « commentateurs » sur le blog.

    mysql> SELECT comment_author,COUNT(comment_count) AS F01 FROM wp_comments,wp_posts WHERE comment_approved=1 AND comment_post_ID=ID AND comment_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’ GROUP BY comment_author ORDER BY F01 DESC LIMIT 0,10;+—————-+—–+

    | comment_author | F01 |

    +—————-+—–+

    | NicoLargo | 315 |

    | Albert | 22 |

    | Pierre-Yves | 18 |

    | ninja21a | 18 |

    | Mr Xhark | 15 |

    | Sylvain | 14 |

    | Christophe | 12 |

    | floppy84 | 12 |

    | Nico | 11 |

    | Guillaume | 10 |

    +—————-+—–+

    10 rows in set (0.07 sec)

    Si vous avez d’autres requêtes MySQL dans votre besace et bien faites tourner !