Last entries

Thu 07 May 2009

Niadomo épisode 3 : installation d'un serveur web et d'un webmail

Ce billet est sous licence Art Libre 1.3.

Après le précédent épisode, nous continuons l'installation de notre serveur d'auto-hébergement. Au programme aujourd'hui :

  • un script pour enregistrer les commandes ;
  • l'installation du serveur web ;
  • l'installation d'un webmail ;
  • accéder à des applications graphiques sur le serveur.

Un ch'tit script pour enregistrer les commandes

Quand on gère à plusieurs un serveur, il est indispensable de garder une trace précise de ce que chacun fait. C'est pour cela que nous avons créé la commande nia-script, à appeler avant de faire toute manipulation sur la machine. Le principe de ce petit shell script est très simple : appeler la commande script en demandant l'enregistrement des commandes dans un fichier nommé d'après la date et l'heure courantes.

Nous créons donc le fichier /usr/local/bin/nia-script qui a le contenu suivant :

#!/bin/sh

nom=$(date +%FT%T)
chemin=/root/nia-scripts
script -t -a 2>$chemin/$nom.time $chemin/$nom.typescript

Les enregistrements de commandes sont faites dans le répertoire /root/nia-scripts/ avec des fichiers de nom du style 2009-05-05T23:14:34.typescript. Nous créons donc ce répertoire de tel sorte que son contenu soit accessible en lecture/écriture uniquement par les membres du groupe adm, c'est à dire les gentils administrateurs bénévoles que nous sommes :

 $ sudo mkdir /root/nia-scripts
 $ sudo chown root:adm /root/nia-scripts
 $ sudo chmod 770 /root/nia-scripts

Après tout ça, avoir de faire quoi que ce soit sur la machine, il suffit de faire..

 $ nia-script

...et toutes les commandes sont maintenant enregistrées.

Installation du serveur web Apache 2

apache_feather.png Pour le serveur web de notre hébergement, nous utilisons très classiquement Apache 2. Nous aurions pu utiliser un autre serveur web plus performant, mais comme nous voulons que chaque hébergé puisse relativement facilement influencer la configuration du serveur relative à son espace personnel, nous pensons que Apache avec ses .htaccess convient bien.

L'installation est on ne peut plus simple :

 $ sudo aptitude install apache2

Petit rappel de la configuration d'Apache 2 dans une Debian :

  • les fichiers qui compose le site web sont dans /var/www/, avec en particulier le fichier /var/www/index.html qui est la page web affichée par le serveur fraichement installé ;
  • les fichiers de configuration spécifique d'Apache doivent être installés dans /etc/apache2/conf.d/ ;
  • les modules disponibles sont visibles dans /etc/apache2/mods-available/ alors que les modules effectivement utilisés par le serveur sont visibles dans /etc/apache2/mods-enabled/ (par des liens symboliques sur les fichiers du répertoire mods-available/) ;
  • de manière similaire, les sites web disponibles sont visibles dans /etc/apache2/sites-available/ alors que les sites web effectivement servis par le serveur sont visibles dans /etc/apache2/sites-enabled/ (par des liens symboliques sur les fichiers du répertoire sites-available/).

Pour activer ou désactiver un module on utilise les commandes a2enmod et a2dismod. De même, pour activer ou désactiver un site on utilise les commandes a2ensite et a2dissite.

Pour améliorer la sécurité de notre serveur, nous décidons de rendre le serveur Apache moins verbeux (il ne donnera plus son numéro de version) et de désactiver certaines commandes inutiles du protocoles HTTP en utilisation courante (TRACE qui peut être utilisé pour des attaques). Pour ce faire nous éditons le fichier de config' après en avoir fait une sauvegarde préalable[1] :

 $ mkdir -p /root/etc/apache2/conf.d/
 $ cp /etc/apache2/conf.d/security /root/etc/apache2/conf.d/security.2009-05-04
 $ sudo vi /etc/apache2/conf.d/security

Et nous modifions son contenu pour avoir la configuration suivante :

 ServerTokens Prod
   :
 ServerSignature Off
   :
 TraceEnable Off

Un petit redémarrage du serveur permet de prendre en compte la configuration :

 $ sudo invoke-rc.d apache2 reload

Une hiérarchie web par utilisateur

Pour faciliter la mise à jour de contenu de nos membres auto-hébergés, nous utilisons une configuration assez classique où le contenu du répertoire ~/public_html/ de l'utilisateur toto est accessible à l'URL http://niadomo.net/~toto/.

Pour réaliser cette configuration, il suffit juste d'activer le module Apache userdir !

 $ sudo /usr/sbin/a2enmod userdir
 $ sudo invoke-rc.d apache2 restart

Et voilà ! ;-)

Serveur web accessible en connexion sécurisée HTTPS

Nous voulons pouvoir accéder de manière sécurisée à notre serveur web, en particulier pour les données sensibles comme le webmail ou les authentification. Nous utilisons pour se faire le module Apache ssl et le site web default-ssl (inactif par défaut). Nous n'avons pas le temps de configurer les redirections de HTTP vers HTTPS (pour éviter les erreurs de manipulation) donc pour l'instant notre serveur web sera accessible uniquement en HTTPS (en désactivant le site web par défaut : default).

 $ sudo /usr/sbin/a2enmod ssl
 $ sudo /usr/sbin/a2ensite default-ssl
 $ sudo /usr/sbin/a2dissite default
 $ sudo invoke-rc.d apache2 restart

Nous vérifions que notre site web est toujours accessible à l'URL https://niadomo.net.

Configuration du webmail SquirrelMail

squirrelmail_logo.png Comme webmail, nous avons décidé d'installer SquirrelMail. Nous aurions préféré RoundCube ou un autre webmail plus moderne mais RoundCube n'est pas disponible comme paquet Debian dans Lenny. Donc nous avons choisi la voie de la facilité. ;-)

L'installation est simple :

 $ sudo aptitude install squirrelmail

La configuration est tout aussi simple :

 $ sudo squirrelmail-configure

Dans le menu de configuration qui apparait, nous choisissons :

  • la configuration pré-réglée pour Dovecot, notre serveur IMAP : choix « D » puis « dovecot », puis « R » pour revenir au menu principal ;
  • nous installons les plugins suivants par le menu « Plugins » :
    • mail_fetch
    • newmail
    • filters
    • message_details
    • squirrelspell
    • calendar
    • administrator
    • spamcop
  • nous configurons pour que le logiciel soit en Français par défaut par le menu « Languages »
    • Default Language: fr_FR
    • Default charset: iso-8859-1

Pour le reste, nous conservons la configuration par défaut. Un petit « S » pour sauvegarder la configuration et « Q » pour quitter l'utilitaire squirrelmail-configure.

Pour que la traduction française fonctionne, il faut que la locale ISO-8859-1 soit disponible. Nous l'ajoutons donc à notre configuration :

 $ sudo dpkg-reconfigure locales

On a choisit d'ajouter toutes les locales françaises :

  • fr_FR
  • fr_FR.UTF-8
  • fr_FR@euro

Il faut ensuite configurer Apache pour qu'il serve maintenant le site SquirrelMail, ce qui se fait avec un simple lien :

 $ sudo ln -s /etc/squirrelmail/apache.conf /etc/apache2/squirrelmail.conf

Une dernière modification de sécurité ! Par défaut, SquirrelMail est accessible à l'URL standard http://niadomo.net/squirrelmail. Pour éviter les attaques trop aisées, nous utilisons une autre URL par défaut, par exemple « monecureuil ». Pour se faire il faut modifier le fichier de configuration Apache de SquirrelMail :

 $ sudo vi /etc/squirrelmail/apache.conf

Et y modifier la première ligne en :

 Alias /monecureuil /usr/share/squirrelmail

Un petit coup de redémarrage d'Apache ...

$ sudo invoke-rc.d apache2 restart

... et normalement notre nouveau webmail est accessible à l'URL http://niadomo.net/monecureuil.

Vérification de la configuration de SquirrelMail

La documentation de SquirrelMail[2] nous indique que l'on peut vérifier en local (c.-à-d. sur le serveur) la configuration de SquirrelMail en accédant à l'URL src/configtest.php :

 $ lynx https://127.0.0.1/monecureuil/src/configtest.php

Ce test nous indique que la configuration PHP5 magic_quotes_gpc doit être désactivée, ce que nous faisons :

 $ sudo vi /etc/php5/apache2/php.ini

Et nous modifions la ligne suivante en Off (au lieu de On) :

 magic_quotes_gpc = Off

Et voilà, nous avons maintenant un serveur web personnel et un webmail sécurisé à disposition ! Alors, c'est si difficile que ça l'auto-hébergement ? ;-)

Configuration pour utiliser une application graphique sur le serveur

Habituellement, sur un serveur, on ne met aucune application graphique et on utilise des éditeurs en mode texte comme vi ou nano pour éditer les fichiers de configuration. Quel que soit le système Unix que vous utiliserez, vous aurez toujours l'éditeur vi[3] à disposition donc il est recommandé de savoir au moins éditer trois lignes avec. ;-)

Mais bon, quand on débute, c'est parfois un peu compliqué donc voici les manipulations à faire pour pouvoir accéder à des applications graphiques (c.-à-d. utilisant le serveur X) sur votre serveur.

En premier lieu, installer le paquet xauth :

 $ sudo aptitude install xauth

Ensuite, lors de votre connexion en ssh sur le serveur, utilisez les options -X pour demander la propagation (forwarding) du terminal graphique X[4] et -C pour la compression :

 ssh -C -X toto@lumturo.niadomo.net

Et voilà, vous pouvez maintenant utiliser l'éditeur graphique qui vous convient, par exemple scite :

 $ sudo aptitude install scite
 $ sudo scite /etc/squirrelmail/apache.conf

Mais je le répète, c'est mieux d'apprendre les rudiments de vi et de se souvenir qu'il a deux modes : le mode qui bippe et le mode où l'on massacre son fichier. :-D

  • MàJ 2009-05-10: Ajout de la licence Art Libre pour ce billet.
  • MàJ 2009-08-18: correction typo.

Notes

[1] Nous utilisons pour l'instant une hiérarchie parallèle de fichiers de configuration dans /root/etc/... Une autre méthode plus robuste avec un gestionnaire de version sera utilisée par la suite.

[2] Documentation du paquet squirrelmail accessible dans /usr/share/doc/squirrelmail/README.Debian.gz.

[3] vi vient de Visual Editor. Ça peut vous surprendre mais vous n'avez jamais utilisé ed. ;-)

[4] Cela suppose que vous avez bien l'option X11Forwarding yes dans le fichier /etc/ssh/sshd_config de votre serveur.

Mon 23 Feb 2009

  • David Mentré
  • Web
  • 5

Serveurs web haute performance

Une remarque de Jean-Marie m'a rappelé que la plupart des sites web actuels sont vraiment lents (un exemple au hasard ? Voyages-sncf.com bien sûr !) alors que nos machines, disques durs et réseaux sont de plus en plus rapides ! La principale cause, comme d'habitude, c'est que l'on utilise de plus en plus de logiciel dynamique et plus ou moins interprété comme du PHP ou du Python. Mais un composant essentiel de la pile web, c'est quand même le serveur web. Et celui que la plupart des gens utilise, Apache (52% de part de marché en janvier 2009), est il faut le dire une vraie bouse. Heureusement, le monde du Libre est formidable : il y a des alternatives ! \o/

La première alternative, c'est lighttpd (prononcer lighty) et c'est celui que j'utilise sur mon serveur web. Subjectivement, c'est vrai qu'il est rapide. Il se lance ou se relance en un clin d'œil et le fichier de configuration a une syntaxe plutôt agréable. Et objectivement, il est rapide d'après des tests faits par Fred sur deux machines identiques. ;-) Malheureusement, sa documentation est plutôt légère : quand je me pose des questions sérieuses sur un module, par exemple l'ordre d'interprétation des règles de ré-écriture d'URL, je ne trouve pas d'information détaillée. Par contre, comme il est utilisé par beaucoup de gros sites pour leurs parties statiques (YouTube, Wikipédia, ...), on peut supposer qu'il est correctement programmé du point de vue sécurité.

L'autre prétendant, c'est nginx. Pour lui, je n'ai pas trop d'expérience. Il fait un peu fouilli puisqu'il fait, en plus de serveur web, mail proxy server. Et j'ai entendu dire qu'il y avait des bugs et que les développeurs étaient plus intéressés à rajouter de nouvelles fonctionnalités qu'à les corriger : un peu embêtant pour un serveur web accessible à la sauvagerie du Wild Wide Web. Mais bon, ce ne sont que des ouïes dire, à vérifier donc.

Le troisième prétendant, petit nouveau dans l'arène, c'est Cherokee, que j'ai découvert grâce aux notes de version de la toute nouvelle Debian Lenny. :-) Cherokee a l'air très sympa (outre son logo ;-) : configuration par une interface web (sécurisée par mot de passe unique et ssh) mais sauvegardée dans un fichier texte, documentation qui a l'air complète, et toutes les fonctionnalités qu'on peut attendre d'un serveur web moderne : équilibrage de charge, ré-écriture d'URL, support de FastCGI et consorts, serveurs virtuels, etc. Et surtout, il est rapide... enfin d'après leurs propres benchmarks. :-) Mais bon, j'envisage à moyen terme de le tester à la place de lighttpd.

Enfin, mon outsider, c'est Ocsigen. Plus qu'un serveur web, c'est un environnement de développement complet, en OCaml, qui est intégré au serveur web. Et depuis la dernière version 3.11 du compilateur OCaml qui permet de charger des modules de code natif dans un programme OCaml, Ocsigen fonctionne en code natif ! Cela veut dire que l'on a un environnement de développement web avec toutes les bonnes propriétés d'OCaml (typage fort à la compilation, y compris sur des requêtes SQL de PostgreSQL, garbage collector performant, beaucoup de bibliothèques, ...) et qui en plus produit du code natif, donc réellement efficace (comme le montre ces tests de Dario Teixeira). Cela me semble la meilleur combinaison pour faire des sites web qui poussent ! Évidemment, il faut programmer en OCaml et surtout se faire à l'environnement d'Ocsigen, ce qui n'est pas aussi simple qu'en PHP par exemple. Mais même en tant que simple serveur web de pages statiques, Ocsigen se compare correctement à lighttpd et Apache, sans toutefois être aussi performant. Et bien sûr, pour les sites dynamiques, il est nettement plus rapide que Ruby (qui certes n'est pas le langage le plus rapide) !

Face à Apache, tous ces serveurs web ont beaucoup d'avantages mais un gros inconvénient : les logiciels web sont tous conçus pour Apache. Donc il faut souvent adapter la configuration du serveur web, notamment dans la gestion des droits d'accès (configuration équivalente aux .htaccess). Rien de bien mortel, mais c'est toujours du travail en plus et on a toujours le risque de faire une erreur.

En tout cas, une chose est sûre, la liberté et la dynamique du Libre nous permet d'avoir des solutions réellement innovantes. Il ne vous reste plus qu'à les utiliser. ;-)

Thu 12 Feb 2009

Critique livre: Ergonomie web

Faire un site web n'est pas une chose simple, faire un bon site web utilisable par son public est encore plus difficile ! Bien souvent, on ne sait pas si quelque chose est mal fait, et si oui comment y remédier. Le livre Ergonomie web d'Amélie Boucher (32 €, ISBN 978-2-212-12158-2) n'est pas la solution miracle mais donne de sérieuses pistes pour arriver à faire un site web réellement fonctionnel.

Le livre est divisé en cinq parties. La première partie est une introduction à l'ergonomie web, avec une rapide présentation des concepts et un détail des dix idées reçues sur l'ergonomie web (règle des trois clics, les internautes sont des idiots, ...).

La deuxième partie détaille plus avant les fondements de l'ergonomie. Tout en restant accessible, Amélie Boucher présente quelques théories et lois à la base de l'ergonomie, comme la loi de Fitts (« une cible est d'autant plus rapide à atteindre qu'elle est proche est grande »), le concept d'affordance (les possibilités d'action suggérées par les caractéristiques d'un objet), etc. Cette deuxième partie détaille ensuite comment prendre en compte les utilisateurs de son site web avec la méthode des personas (des utilisateurs types qui font des actions sur votre site).

La troisième partie est le cœur du livre. Elle commence par un long cinquième chapitre qui donne les douze règles pour optimiser l'ergonomie de son site :

  1. Architecture : le site est bien rangé ;
  2. Organisation visuelle : la page est bien rangée (PDF) ;
  3. Cohérence : le site capitalise sur l'apprentissage interne ;
  4. Conventions : le site capitalise sur l'apprentissage externe ;
  5. Information : le site informe l'internaute et lui répond ;
  6. Compréhension : les mots et les symboles sont choisis minutieusement ;
  7. Assistance : le site aide et dirige l'internaute ;
  8. Gestion des erreurs : le site prévoit que l'internaute se trompe ;
  9. Rapidité : l'internaute ne perd pas son temps ;
  10. Liberté : c'est l'internaute qui commande ;
  11. Accessibilité : un site facile d'accès pour tous ;
  12. Satisfaction de votre internaute.

Chacune de ces règles est abondamment commentée et illustrée, avec des exemples à suivre et à ne pas suivre pris sur des sites web grand public. Ce cinquième chapitre est la colonne vertébrale de l'ouvrage. Si vous n'avez pas le temps de tout lire, lisez celui-ci ! Cette troisième partie se termine par quelques conseils et explications méthodologiques pour l'audit ergonomique.

La quatrième partie aborde l'élaboration concrète d'un site web de A à Z, de la définition des contenus et l'analyse concurrentielle aux zonings et maquettes des écrans.

Enfin, la cinquième partie donne différentes méthodes pour mettre à l'épreuve un site par de vraies utilisateurs, de la méthode de tri des cartes pour organiser un site aux tests utilisateurs.

L'ensemble du livre est d'une lecture agréable. Le contenu ardu est limité à son strict minimum et le livre est bien illustré, facilitant la compréhension des explications bien souvent liées à l'aspect visuel des choses. Les conseils méthodologiques semblent empreints de pragmatisme, reflet d'une utilisation réelle des méthodes expliquées. De nombreuses fois, l'auteur explique ce que l'on peut simplifier et les points à ne surtout pas négliger dans le traitement ergonomique de son site. Évidemment, si on fait un petit site web sur un coin de table, on n'a pas forcément besoin de toutes les méthodologies proposées dans ce livre. Mais avoir en tête les douze règles de l'ergonomie web me semble indispensable. Enfin, le livre donne de nombreuses références, sur le web ou en livre papier, pour aller plus loin.

En résumé, je trouve ce livre vraiment excellent : clair, détaillé, pédagogique. Une lecture obligatoire pour tous ceux qui conçoivent ou participent à l'élaboration d'un site web.

Au passage, je compte lancer une grande souscription : envoyer un exemplaire de ce livre à chaque membre (une centaine de personnes) de la société VSC technologies, auteur du désastre de l'informatique et de l'ergonomie web qu'est Voyages-sncf.com ! ;-)