« Benchmarker » son site avec Tsung

Ce blog ne déborde pas d’activité en ce moment, vous l’aurez surement remarqué. J’ai été pas mal occupé d’une part avec mon travail et mon activité en tant que bénévole à la Croix-Rouge et d’autre part mes études. J’essaye de tout concilier au mieux du coup ce blog ne déborde pas d’activité. J’ai cependant pris le temps de réparer le formulaire de contact de ce blog qui ne fonctionnait plus à cause d’un petit changement de VPN. C’est désormais réparé.

Les billets précédents évoquaient l’amélioration de performances d’un site web grâce à un astucieux montage basé sur plusieurs machines virtuelles. Aujourd’hui, nous allons parler de benchmarking de site web.

Quelques rappels

L’expression « benchmarking » est devenue très populaire dans le milieu professionnelle comme de nombreux autres termes anglais cherchant à démontrer un dynamisme et une originalité. Nous parlerons ici que de sa signification originale qui est la mesure de performances.

Sur l’Internet, l’utilisateur ne demande plus rien d’autre que de l’instantané. Si votre site met plus de quelques secondes à s’afficher, l’utilisateur passera probablement son chemin malgré la qualité éventuelle du contenu.

Les outils pour mesurer les performances des sites web ne manquent pas à l’appel. On en trouve de nombreux en ligne et sous forme d’applications. Certains présentent une originalité intéressante alors que d’autres se cantonnent à des fonctionnalités basiques. L’outil le plus connu est probablement « ab » car il est souvent installé en même temps qu’Apache. Cet outil dispose de fonctionnalités intéressantes mais relativement basiques.

Tsung

Comme l’indique le titre, nous allons nous intéresser à Tsung. Il s’agit d’un projet Open Source Français développé par Nicolas Niclausse. Cette application ne se limite pas aux sites web via HTTP mais peut également benchmarker les applications Webdav, SOAP, MySQL, PostgreSQL, LDAP et Jabber/XMPP. La mesure de performances peut se faire d’une seule machine ou de tout un cluster.

Tsung permet de générer et d’exécuter des scénarios de test. Cela signifie qu’il ne se limite à charger une page web selon une fréquence définie. Vous allez pouvoir lui faire naviguer votre site et utiliser diverses fonctionnalités.

Fonctionnement

L’enregistrement de scénarios est très simple. Il vous suffit de lancer le « tsung_recorder » et de le paramétrer en tant que proxy de votre navigateur. Les actions que vous allez ensuite effectuer dans votre navigateur vont être enregistrées. Vous aurez ainsi créé une suite d’actions.

Une fois la suite d’actions créée, il sera nécessaire de paramétrer les informations relatives au scénario,  à savoir l’IP du serveur à tester, la fréquence d’exécution, etc. La documentation de ce projet est claire à l’exception du chapitre sur les fichiers de configuration de scénario. Pour cela, je vous donne un fichier de configuration de scénario complet et fonctionnel qui devrait vous permettre d’y voir un peu plus clair.

Une fois la configuration terminée, il ne vous restera plus qu’à l’exécuter et observer votre serveur travailler.

Analyse des résultats

L’exécution d’un scénario de benchmarking est une chose mais l’interprétation des résultats est essentielle. Tsung a tout prévu pour vous.

Grâce à l’utilitaire « tsung_stats », vous allez pouvoir générer une série de graphiques traduisant les résultats du test. Cet utilitaire prendra même le soin de les mettre en page dans une page web. L’image ci-dessous est un exemple (en version réduite) des graphiques en question. Un fichier vectoriel est également généré si vous souhaitez disposer d’un visuel plus flexible.

Si vous souhaitez comparer les résultats, Tsung met à votre disposition l’outil « tsplot » qui vous génèrera des graphiques comparant les différents tests que vous avez exécuté. L’image ci-dessous est un exemple de graphique généré par tsplot.

Au final, Tsung est un excellent outil permettant de créer simplement des scénarios de benchmarking complexes et de visualiser ces résultats à travers des graphiques clairs. Seul bémol, il ne s’agit pas d’un logiciel particulièrement simple à utiliser car tout se fait en ligne de commande. Cependant, un utilisateur de Linux un peu aguerri devrait pouvoir s’en sortir.

Récit d’une « petite » erreur

Cette journée fut particulièrement mouvementée. Bien évidemment, ce n’était pas prévu et tout s’annonçait paisible tel un Vendredi classique. J’avais prévu deux transferts planifiés de sites dont le transfert avait été minutieusement préparé et répété. Une migration parfaitement classique.

Je me rends compte qu’il est nécessaire de modifier le fichiers de VirtualHost de tous les sites web du serveur Apache. Les Virtualhost sont les fichiers de configuration de site d’Apache. Au lieu de mettre « <Virtualhost IP> », il est nécessaire de mettre « <Virtualhost IP:port> ». Il n’était pas question de tout modifier à la main, il y a plus de 200 fichiers. Par sécurité, j’ai effectué une sauvegarde du répertoire sites-enabled. Dans ce cas, un script était nécessaire. Je code cela rapidement :

for i in `ls -1 .`; do cat $i | sed ‘s/<Virtualhost IP>/<Virtualhost IP:port>/g’ > $i; done

Et là, c’est le drame.

Ce petit script est, hélas, syntaxiquement correct. Il remplace bien les deux chaines de caractère comme je souhaitais qu’il le fasse. Il a été exécuté en root car je travaille toujours en root par simplicité. Si vous regardez de plus près, vous remarquerez qu’il écrit dans le même fichier qu’il lit. Erreur fatale. Ceci signifie la suppression de tous les fichiers du répertoire courant. Tous. Tous les Virtualhost disparus. Quant à la sauvegarde du répertoire sites-enabled ? Inutile car ce sont des liens symboliques.

Houston, we have a problem.

Quelques minutes suffisent pour se rendre compte de l’erreur commise par ce script en apparence anodin. Les sauvegardes, me diriez-vous. J’apprends qu’elles sont en erreur depuis longtemps. Par chance, une copie de la machine virtuelle était présente sur l’ancien serveur VMWare duquelle elle avait été migré avant-hier. La récupération d’une bonne partie des Virtualhost a été possible jusqu’à ce point. Sauf que nous avions transféré 120 sites hier. Cette erreur n’a pas créé d’indisponibilité car Apache mémorise la configuration. Un restart serait par contre fatal.

Il ne reste plus qu’une solution : créer un script à partir de la configuration de l’ancien serveur pour recréer tous les Virtualhost créés hier. Deux heures de développement d’un script pas si simple dans un des langages les plus moches sur Terre : Bash. Une heure de debug du script. Après trois heures de stress intense et d’activité cérébrale, les Virtualhost avaient été recréés. Quelques Virtualhost ont du être récréés à la main car le script n’avait pas fonctionné avec.

Finalement, Apache accepte les Virtualhost créés par mon script. Je suis sauvé.

Je pense qu’il est important de tirer les enseignements de ses erreurs. Dans ce cas, il va falloir que j’apprenne à utiliser sed et à ne plus jamais scripter sur un serveur de production. Nous faisons tous des erreurs et nous devons donc nous assurer que ces erreurs seront inoffensives. Dans ce cas, la protection face à l’erreur a été inutile à cause d’un élément technique dont j’avais parfaitement conscience. Un petit moment d’inattention a suffit pour tout faire basculer.

Au final, il y a deux types d’administrateurs système : ceux qui ont déjà tout cassé à cause d’une erreur de script et ceux qui vont le faire.

Sécuriser un serveur Apache avec PHP : la problématique

Logo PHPLe PHP est un langage web qui permet de faire des sites web dynamiques. Ce qui a fait sa popularité c’est sa simplicité d’utilisation dans la mesure où n’importe qui peut donner 10€ à OVH ou à 1&1 et avoir un espace d’hébergement compatible PHP. C’est souvent le langage de programmation sur lequel démarrent beaucoup de programmeurs autodidactes. Quand on lit ca, on peut se dire « Chouette ! C’est cool PHP on peut programmer simplement pleins de trucs trop biens ! Si je m’y mettais ?! ». D’un coté, c’est pas faux, vous allez nous coder un super site tout moche parcque vous savez pas utiliser Photoshop. D’un autre coté, vous allez surement coder un site bourré de failles de sécurité.

Et oui, les sites PHP sont souvent bourrés de faille car les programmeurs débutants n’ont souvent pas de connaissance en programmation sécurisée. Si c’est vous à titre personnel, vous vous ferez démonter votre site perso et vous irez pleurer mais les conséquences ne seront pas dramatiques. Par contre, si vous vous appelez « Web Agency », « Web Designer » ou tout autre appelation d’origine non controlée vous allez venir vous plaindre à votre hébergeur car il n’a pas sécurisé son serveur alors que c’est votre code qui est pourri. Et ca, ca m’énerve.

Après avoir râlé, il faut quand même admettre que l’hébergeur d’un serveur web peut avoir une responsabilité dans la compromission de votre site web. Ce cas de figure n’est valable que sur un serveur mutualisé.

Vous venez donc de monter votre serveur web tout beau tout neuf sur votre serveur dédié. Vous avez l’agréable sensation d’avoir accompli quelque chose vraiment bien, normal. Ce que vous ne ressentez pas c’est le manque de sécurité total de votre installation. Je vous rassure, on ne ressent ce genre de choses que quand c’est bien trop tard.

Problèmes de droits

Par défaut, Apache exécute tous les sites web ou VirtualHosts avec l’utilisateur par défaut, www-data sur les distributions type Debian ou apache sur les distributions type RHEL. Quand je parle d’exécution, je parle de lecture des fichiers HTML (parfaitement anodin) mais aussi d’exécution de scripts PHP. Cela veut dire que tous les sites ont les mêmes droits en lecture et en écriture, quelque chose du genre 775 avec en propriétaire www-data. Si vous avez bien fait le calcul, cela signifie que rien n’empêche un script PHP d’aller lire/modifier/détruire un fichier d’un autre VirtualHost. Normal, ces fichiers ont les mêmes droits.

Avec ce type de configuration par défaut, n’importe quel client peut aller lire les fichiers d’un autre client pour peu qu’il soit un peu futé. Il va pouvoir y lire des lignes de code mais aussi des identifiants SQL par exemple… Qui dit identifiants SQL dit base de données remplie de données. De quoi y faire un vrai festin.

Problèmes de modification de droits

Vous êtes conscients du problème des droits et vous avez donc créé un utilisateur pour chaque site web avec un uid différent bien évidemment (ne rigolez pas c’est du vécu). Le soucis c’est que chaque utilisateur va avoir la possibilité de faire un « chmod » sur tous les fichiers de son site et donc de tout passer en 777, c’est tellement plus simple.Au final, on revient donc à la situation précédente ou n’importe quel site peut lire/modifier/détruire les fichiers des autres sites.

De plus, vu que le serveur web s’exécute toujours en www-data, vous devez donner les droits d’écriture à www-data si vous voulez que le serveur web puisse écrire. Ceci donne également la possibilité à des scripts PHP d’autres sites d’aller jouer avec tous les fichiers qui sont en écriture pour le serveur web.

Un unique fichier de configuration

Ensuite, lorsque vous installez PHP sur votre distribution préférée, vous avez un seul fichier php.ini qui régit par défaut toutes les variables de PHP pour le serveur. Vous vous faites donc une configuration ultra top sécurisée ou alors vous le laissez par défaut, mais on va supposer la première option. Le seul soucis c’est que vu que vous hébergez pleins de clients, vous avez pleins de demandes différents telles que l’activation du fopen ou register_globals qui sont des failles de sécurité ultra connues. Vous refusez de leur activer ? Ils refusent de vous payer, logique. Donc vous l’activez. Et là, c’est le drame, vous l’avez activé pour 200 sites.

Vous l’aurez bien compris, une installation par défaut d’Apache et PHP est très peu sécurisée dans le cas d’utilisation dans le cadre d’un serveur web mutualisé. Je vous présenterais dans la suite des billets les solutions pour répondre à ces problèmes car il en existe, rassurez-vous.