ZenTech - lighttpd 1.4

Le log qui se voulait plus gros que le boeuf

hr — Thu, 21 Feb 2008 17:52:00 +0100

C'est généralement au moment où on se retrouve avec une partition pleine que l'oubli de la rotation des logs refait surface. C'est ultra-classique et pourtant... Mais nous allons prendre les devants pour que lighty ne soit pas un mangeur d'espace.

Sur FreeBSD, le gestionnaire de rotation de log de base s'appelle newsyslog(8), il est configuré par le fichier /etc/newsyslog.conf (newsyslog.conf(5)). Je suis habitué à logrotate(8) et j'aime bien conserver tous mes fichiers de logs d'activité web, je vais donc faire la même chose avec newsyslog(5). Je souhaite donc faire tourner mes logs tous les jours à minuit, compresser les logs passés et les conserver ad vitam eternam. Ces contraintes donnent l'entrée suivante dans le fichier de configuration :

# lighttpd rotates
/var/log/lighttpd/lighttpd.access.log   www:www   640  366 *   @T00   JC

il faut spécifier un champ de gestion d'appartenance (propriétaire et groupe), lighttpd écrit les logs avec les droits www:www et ils seront déplacés en changeant le propriétaire en root:www.Les fichiers seront créés avec les droits 640, le champ suivant spécifie que les fichiers sont sauvegardés 366 fois avant d'éliminer les fichiers les plus anciens (1 an). Les 2 champs suivant provoquent une rotation à minuit tous les jours. Le dernier champ précise qu'on compresse les archive de log en bzip2 et que le fichier est créé si il n'existe pas.
Le champ 'count' n'est pas exhaustivement décrit dans la page de man, et j'espérais pouvoir utiliser une valeur qui me permettrait d'avoir un nombre infini de fichiers de logs. La lecture du code source m'a confirmé que je ne pouvais pas utiliser le même type de fonctionnement que pour logrotate(8).

Une entrée doit être créée pour chaque fichier de log de chaque vhost.

Un blog bien sous tout rapport

hr — Thu, 14 Feb 2008 16:39:00 +0100

Ce blog est un dotclear 2 installé sur un système FreeBSD et servi par un lighty. J'ai choisi dotclear pour la possibilité de gérer de multiples blogs à partir d'un seul code, wordpress ne donnait pas cette possibilité simplement au moment de mon choix. Mon premier déploiement n'a pas été fait dans les règles FreeBSD, il est temps de remédier à cet insupportable état de fait.

Les applications web sont déployées dans /usr/local/www sous FreeBSD, le contenu des sites se trouve dans /usr/local/www/data.

# cd /usr/local/www
# tar zxvf ~/src/dotclear-2.0-beta7.tar.gz
# mv dotclear dotclear2

Le renommage du répertoire permet d'éviter un conflit dans l'éventualité de l'installation d'un dotclear 1.

Une fois le blog installé, il faut le configurer. La configuration de lighty est très simple, il suffit d'ajouter l'alias suivant pour un blog qui est atteint par http://www.bon.org/blog par exemple :

alias.url += (
        "/blog" => "/usr/local/www/dotclear2"
)

La suite de la configuration a déjà été abordée dans un autre billet.

Finalement la modification est assez mineure et revient uniquement à modifier le chemin d'alias pour tous les blogs hormis celui par défaut et ajouter un alias pour celui-ci.

A chacun sa petite fiche de présence

hr — Sun, 11 Nov 2007 12:52:00 +0100

J'aime bien avoir des logs d'accès séparés par vhost sur mes serveurs, ça permet de simplifier la recherche d'erreur et la construction de statistiques. Comme je gère mes vhosts par un script, j'ai pensé que rajouter la création automatique de logs d'accès serait un plus. C'est toujours ça qui ne sera pas oublié lors de l'ajout d'un nouveau vhost.
Au passage, j'ai rajouté le document-root automatique, les données d'un site virtuel doivent se trouver dans un répertoire du nom de son fichier de configuration.

# ./include_vhost -h
Usage: include_dir [-hptx] [-d docroot_path] [-l log_path] <dir>
    -h      displays this help
    -d      Automatic document-root specification
    -l      Add vhost access logs in log_path
    -p      print the parsed config files and exit (default behaviour)
    -t      test the config files
    -x      specify a lighttpd binary (default /usr/local/sbin/lighttpd)

Si les logs doivent se trouver dans /var/log/lighttpd, que les sites se trouvent dans /usr/local/www/data et que les fichiers de configurations de vhost sont dans /usr/local/etc/lighttpd/vhost.d, on obtient l'appel suivant au script :

./include_vhost -l /var/log/lighttpd -d /usr/local/www/data /usr/local/etc/lighttpd/vhost.d

Au passage, le script change de nom étant donné qu'il se spécialise vraiment dans la gestion de fichiers de configuration d'hôte virtuel.

Pour information, je n'ai pas rajouté les logs d'erreur dans cet automate, pour la simple et bonne raison que la documentation de configuration déconseille de placer plusieurs appels à server.errorlog dans la configuration de lighty.

Et si je racontais ma vie avec lighttpd

hr — Wed, 07 Nov 2007 00:37:00 +0100

La France serait un des pays comptant le plus de blogueurs, il n'y avait donc aucune raison que je fasse exception. Le problème étant que je souhaite séparer mes publications techniques de mes publications "3615 MyLife". Comment donc faire fonctionner 2 blogs avec une seule version du code de dotclear 2.0 et lighty ?

J'ai déjà expliqué, dans un post précédent, comment installer un dotclear 2.0 correctement avec lighty. En repartant de cette configuration, on va faire en sorte de créer un second blog sous l'url http://www.bonz.org/tech/ en utilisant le code placé dans le répertoire /blog/. Sur mon serveur, ce code se trouve dans le répertoire /usr/local/www/data/www.bonz.org/blog/.
L'intérêt d'un tel montage se trouve dans le partage du code du blog, la mise à jour de ce code se fait donc à la fois pour tous les blogs en un seul emplacement. Le partage de la zone publique dans laquelle se trouve les fichiers multimedia et le partage des thèmes. Dans l'ensemble on évite la duplication d'information.

On va commencer par créer un nouveau blog via l'interface d'administration de dc2. Le lien "Blogs" dans la colonne de gauche, permet d'obtenir la liste des blogs gérés par le site. La création d'un nouveau blog se fait par le lien "Créer un nouveau blog", les informations importantes sont l'identifiant et l'adresse du blog, respectivement tech et http://www.bonz.org/tech/. Après avoir sélectionné le nouveau blog dans la liste déroulante du haut, utiliser le lien "about:config" dans les extensions pour obtenir l'accès à certaines variables de configuration. La variable public_url doit avoir la valeur /tech/public et la variable themes_url la valeur /tech/themes. Maintenant que le blog est correctement configuré, on peut passer à la configuration de lighty.

La méthode consiste à créer un alias de lien en premier lieu et de réécrire les adresses ensuite. Pour créer un alias de lien, rien de plus facile.

alias.url += (
        "/tech" => "/usr/local/www/data/www.bonz.org/blog"
)

Je crée un alias entre l'url http://www.bonz.org/tech et le chemin système correspondant au code de mon blog. Je dois maintenant indiquer à dotclear 2 que je veux utiliser le blog dont l'identifiant est "tech".

# Dotclear2 env variable to get the right blog id
$HTTP["url"] =~ "^/tech/" {  
    setenv.add-environment = (
        "DC_BLOG_ID" => "tech"
    )
}

Le code de dotclear embarque un système permettant de passer cette information par une variable d'environnement. Les réécritures se font sur le même principe que celui exposé dans mon billet précédent sur le sujet.

url.rewrite-once += (
    "^/tech/(archive.*)" => "/tech/index.php/$1",
    "^/tech/(category.*)" => "/tech/index.php/$1",
    "^/tech/(feed.*)" => "/tech/index.php/$1",
    "^/tech/(page.*)" => "/tech/index.php/$1",
    "^/tech/(post.*)" => "/tech/index.php/$1",
    "^/tech/(tag.*)" => "/tech/index.php/$1",
    "^/tech/(trackback.*)" => "/tech/index.php/$1"
)

Il faut penser à mettre en place les quelques protections d'accès déjà abordées sur les répertoires sensibles.

La configuration est terminée, après un redémarrage de lighty tout devrait se passer sans encombres!

Je veux bien prendre mais pas de là

hr — Sat, 21 Jul 2007 22:14:00 +0200

C'est toujours autant amusant de jouer avec lighttpd, mais parfois on se trompe dans un fichier de configuration et là, c'est le drame. Mon script include_dir ne permet pas de savoir quel fichier de configuration est brokmut lors de l'utilisation de lighttpd -p -f lighttpd.conf. C'est maintenant chose faite, avec la nouvelle version toujours téléchargeable au même endroit. Au passage, il est passé en license beerware

# ./include_dir -h
Usage: include_dir [-hptx] <dir>
    -h      displays this help
    -p      print the parsed config files and exit (default behaviour)
    -t      test the config files
    -x      specify a lighttpd binary (default /usr/local/sbin/lighttpd)
# ./include_dir -t vhost.d/
>>> Testing vhost.d/www.vhost1.org
Syntax OK
>>> Testing vhost.d/www.vhost2.org
2007-07-21 22:28:47: (configfile.c.833) source: vhost.d/www.vhost2.org line: 3 pos: 21 parser failed somehow near here: (EOL) 
>>> Testing vhost.d/www.vhost3.org
Syntax OK

httpd.zero = enable

hr — Fri, 30 Mar 2007 18:55:00 +0200

Toujours à m'amuser avec asparttpd et je me dis que ce serait sympa de pouvoir utiliser le mécanisme auquel je me suis habitué pour les vhosts. Un dossier vhost.d et un fichier de conf par vhost dans ce répertoire.

Rien de plus facile en fait, grâce à include_shell je lance un script de ma composition, ce script est un bête bout de sh qui inclut tous les fichiers du répertoire donné en argument au script. Ca donne ce genre de chose :

#### vhosts
include_shell "./include_dir vhost.d"

et le script :

#!/bin/sh

# I prefer doing nothing if no dir is given on command line
# that way I do not break anything
if [ "$#" = "0" ]; then
        exit 0
fi

# exclude vim temporary files
# configuration file has to have the vhost domain name
for site in $(ls $1 | grep -v .swp); do
        echo "\$HTTP[\"host\"] == \"$site\" {"
        cat $1/$site
        echo "}"
        echo
done

l'utilisation d'un petit lighttpd -p -f lighttpd.conf permet de s'assurer que tout fonctionne correctement, on remarque également que de cholis commentaires sont ajoutés pour faciliter la lecture. Le script include_dir est présent dans le même répertoire que le fichier de configuration de lighttpd (je sais, c'est sale).

Et si on mangeait light

hr — Fri, 30 Mar 2007 16:54:00 +0200

Il y a toujours un moment dans la vie où on se dit qu'on mange trop lourd et qu'il faudrait faire attention et que j'ai pris du gras de là. il n'y a pas longtemps c'est ma passerelle qui m'a dit ça. Alors hop un p'tit coup de régime, un avis de la part d'un ami diététicien et c'est parti. lighttpd s'installe sans probléme sur un freebsd6.2 (lighttpd-1.4.13_2) et dès le premier démarrage, sans php, HAHAHA la blague.

[root@backdoor ~]# ps ax -o 'user pid %cpu %mem command' -w|grep www
www      36654  0.0  0.7 /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd/lighttpd.conf

A titre de comparaison, le port apache-1.3.37_2 sous freebsd, lancé avec la conf par défaut me donne ça :

[root@backdoor ~]# ps ax -o 'user pid %cpu %mem command' -w|grep www
www      49868  0.0  0.8  2716  2136  ??  S     2:25PM   0:00.01 /usr/local/sbin/httpd
www      49869  0.0  0.8  2716  2136  ??  S     2:25PM   0:00.01 /usr/local/sbin/httpd
www      49870  0.0  0.8  2716  2136  ??  S     2:25PM   0:00.01 /usr/local/sbin/httpd
www      49871  0.0  0.8  2716  2136  ??  S     2:25PM   0:00.01 /usr/local/sbin/httpd
www      49872  0.0  0.8  2716  2136  ??  S     2:25PM   0:00.01 /usr/local/sbin/httpd

La bonne blague donc, il suffit ensuite d'installer php en version FastCgi et de donner le chemin vers le binaire fcgi à lighttpd :

fastcgi.server = ( ".php" => ((
        "bin-path" => "/usr/local/bin/php-cgi",
        "socket" => "/tmp/php.socket")))

Un petit restart et des processus php-cgi apparaissent dans le sillage de notre serveur http sous aspartame.

Dans la foulée je m'installe un dotclear2 et à condition de mettre une petite série de règles de réécriture, je peux même me faire de jolies URL pour les billets.

url.rewrite-once += (
    "^/blog/(archive.*)" => "/blog/index.php/$1",
    "^/blog/(category.*)" => "/blog/index.php/$1",
    "^/blog/(feed.*)" => "/blog/index.php/$1",
    "^/blog/(page.*)" => "/blog/index.php/$1",
    "^/blog/(post.*)" => "/blog/index.php/$1",
    "^/blog/(tag.*)" => "/blog/index.php/$1",
    "^/blog/(trackback.*)" => "/blog/index.php/$1"
)
$HTTP["url"] =~ "/blog/(CHANGELOG|db|inc|cache|plugins)" {
    url.access-deny = ("")
}

Alors pour résumer, un fichier de configuration simpilissime à prendre en main, un système de modules niquel, une empreinte mémoire aussi imposante qu'un PEZ et un système de vhosts que ma mère peut comprendre. Une vraie tuerie, seul bémol, l'absence de système ala .htaccess qui, il faut l'avouer, est carrément convi (mais consommateur à chaque accès).