Re: [TECH] choix d'un wiki

[Rémi PALANCHER <remi AT rezib.org>]

Le Tue, 20 Nov 2007 07:54:13 +0100,
Patrice Pillot <patrice.pillot AT teletopie.net> a écrit :

> Je ne peux parler que de ce que je connais. J'ai testé en milieu pro
> comme associatif phpwiki, wikini et dokuwiki. Je n'utilise plus que
> dokuwiki :
> 1) code propre
> 2) documentation très complète et communauté réactive (mais
>    anglophone!) via la lidif
> 3) facilité de la mise à jour ; j'en suis à ma quatrième mise à jour
>    sans jamais aucun problème. C'est à mes yeux un point crucial.
> 4) économie absolue de la sauvegarde qui se fait de la manière la plus
>    simple qui soit : copie/restauration de l'arborescence, point
> barre. Pas besoin de faire des dumps de la BD puis de réimporter le
> dump dans le nouveau déploiement dont il faudra être sûr qu'il
> comporte bien les modifications dans les CSS ou gabarits html, etc.
> 5) facilité/propreté de la gestion des ACL
> 
> Ceci ne veux pas dire qu'on ne peut pas vivre mieux avec d'autres
> wiki. Juste que de mon point de vue d'AS faignant dokuwiki est
> vraiment bien.

Je confirme, je trouve DokuWiki excellent. Cependant, il pose un
problème inhérent aux wikis basés sur les fichiers : il va approprier
tous les fichiers qu'il crée ou qu'il modifie au user du serveur http
(www-data par défaut sur Debian).

Par conséquent, il est compliqué de l'administrer quand on n'a pas les
droits root sur la machine (typiquement sur un serveur mutualisé dans
un public_html).

Pour s'en convaincre :
rm -rf dokuwiki/data/cache

La solution (crade et pas sécurisée) consiste à configurer des masks
de création des répertoires/fichiers très permissifs (options dmode et
fmode) et éventuellement ajouter l'utilisateur dans le groupe www-data.

Si vous en connaissez une autre, je suis preneur ;)

-- 
Rémi PALANCHER
http://rezib.org/

Attachment: signature.asc
Description: PGP signature