Trac et format de date avec Lighttpd

Suite au précédent billet, et poursuivant l’installation/configuration de Trac, je me suis heurté à un petit problème. Le format de date utilisé par défaut a la forme MM/JJ/AA, ce qui est assez pénible pour un usage fréquent. La plupart des documentations parlent d’Apache et de mod_python. Le changement est pourtant facile avec Lighttpd puisqu’il suffit d’ajouter une variable dans la configuration :
# /etc/lighttpd/conf-enabled/10-fastcgi.conf
server.modules += ( « mod_fastcgi » )
fastcgi.server = (
« /trac » =>
(« trac » => (
« socket » => « /tmp/trac-fastcgi.sock »,
« bin-path » => « /usr/share/pyshared/trac/web/fcgi_frontend.py »,
« check-local » => « disable »,
« bin-environment » => (
« TRAC_ENV » => « /var/lib/tracenv »,
« LC_TIME » => « fr_FR »
)
))
)

Trac c'est le bien(tm)

Comme vous le savez je suis rédacteur en chef de GLMF et à ce titre je passe pas mal de mon temps à organiser, traiter, relire, gérer les articles pour chaque numéro. Cela faisait longtemps que je cherchais un outil Web permettant de faciliter ce travail et d’avoir une vue globale mais également détaillée sur l’évolution de l’ensemble et de chaque article. J’ai finalement trouvé ma solution : Trac, le système de suivi de révisions et de gestion de projet.

Destiné, au départ, à la gestion de projet de développement, Trac s’adapte parfaitement à la gestion d’articles pour un magazine. J’avais, fut un temps, essayé DotProject sans grand succès (trop rigide, trop peu adaptable). Hop, petite procédure d’installation rapide sur Debian !

Tout d’abord l’installation du paquet :
% aptitude install trac
On passe ensuite à l’initialisation de l’environnement avec dans l’ordre le repository SVN et l’environnement de gestion de Trac :
% mkdir /var/lib/tracSVN
% svnadmin create /var/lib/tracSVN

% trac-admin /var/lib/tracenv initenv
% chown -R www-data /var/lib/tracenv

% trac-admin /var/lib/tracenv deploy /var/www/trac
Puis on configure Lighttpd :
# /etc/lighttpd/conf-enabled/10-fastcgi.conf

server.modules += ( « mod_fastcgi » )

fastcgi.server = (
« .php » =>
((
« bin-path » => « /usr/bin/php-cgi »,
« socket » => « /tmp/php.socket »,
« max-procs » => 2,
« idle-timeout » => 20,
« bin-environment » => (
« PHP_FCGI_CHILDREN » => « 4 »,
« PHP_FCGI_MAX_REQUESTS » => « 10000 »
),
« bin-copy-environment » => (
« PATH », « SHELL », « USER »
),
« broken-scriptfilename » => « enable »
)),
« /trac » =>
(« trac » => (
« socket » => « /tmp/trac-fastcgi.sock »,
« bin-path » => « /usr/share/pyshared/trac/web/fcgi_frontend.py »,
« check-local » => « disable »,
« bin-environment » => (« TRAC_ENV » => « /var/lib/tracenv »)
))
)
Ici on passe par FastCGI. La configuration intègre le support Trac/Python mais également PHP (pour dokuwiki (oui je préfère doku que le wiki de trac)). On ajoute ensuite l’authentification :
# /etc/lighttpd/conf-enabled/10-auth.conf
server.modules += ( « mod_auth » )
auth.debug = 2

$HTTP[« url »] =~ « ^/trac/ » {
auth.backend = « htpasswd »
auth.backend.htpasswd.userfile = « /var/lib/tracenv/htpasswd.htaccess »
auth.require = (« /trac/login » =>
(« method » => « basic »,
« realm » => « First project »,
« require » => « valid-user »
))
}
On oubli pas de passer le script Python en exécutable pour plaire à Lighttpd :
% chmod +x /usr/share/pyshared/trac/web/fcgi_frontend.py
On finalise l’authentification en ajoutant un utilisateur «admin» à qui on donne les droits adéquates :
% htpasswd -c /var/lib/tracenv/htpasswd.htaccess admin
% chown -R www-data /var/lib/travenv/htpasswd.htaccess
% trac-admin /var/lib/tracenv/ permission add admin TRAC_ADMIN
Ne reste plus qu’à relancer Lighttpd et à pointer le navigateur sur http://localhost/trac. On s’authentifie et bienvenue dans Trac.

Lighttpd, WordPress et upload (HTTP 413)

Petit convi-tips en passant. J’ai basculé dernièrement d’Apache2 vers Lighttpd avec bien plus de facilité que je ne m’y attendais. Bien sûr, il y avait quelques petites choses à changer de ci de là, mais dans l’ensemble mon kimsufi est très heureux de l’économie de mémoire et de charge CPU.

Dernière tuile en date, impossible d’uploader une image dans WordPress. Une erreur HTTP 413 – Request entity too large apparaît dans les logs. Le pauvre Lighttpd ne savait pas quoi faire d’une requête aussi grosse…

Solution : ajouter deux malheureuses lignes dans le fichier de configuration :
server.upload-dirs=(« /tmp »)
server.max-request-size = 5242880
Problème réglé.