Tag - apache

Entries feed - Comments feed

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. ;-)