Franchement je suis un admin auto-didacte, mais ce n'est pas d'hier. Et pourtant j'ai l'impression que je suis toujours aussi incapable quand il s'agit d'installer ou de configurer un de ces softs interfacés sur le web : les fameux cliquodrômes, genre mediawiki ou sympa.

Donc voici mon petit recueil de malheurs, en espérant qu'il fera gagner du temps à certains.

Petit détail, ces réglages concernent un système Debian wheezy (certains sont apparus justement avec cette version), et il y a fort à parier que vous rencontriez d'autres soucis si vous utilisez d'autres distributions ou d'autres versions.

En dernier recours la version non packagée et l'installation à la force du poignet en suivant pas à pas le guide sera peut-être votre planche de salut : c'est plus complexe mais cela permet parfois de voir des détails qui coincent et qu'on ne soupçonnait pas, donc lire la procédure manuelle peut aider.

Notez que si vous en êtes à lire cet article, c'est que c'est déjà la guerre sur votre serveur. Je ne garantis pas que ceci va résoudre vos problèmes (ni que ça ne va pas les empirer). Donc si vous n'avez pas déjà perdu toutes vos données, faites d'abord des backups, et lisez ce qui suit avec prudence, et à vos propres risques.

Aussi : j'utilise un # pour marquer les lignes de commandes quand je suis root, un $ sinon. J'en ai peut-être raté certains, mais en général dans ce genre de situations je suis root tout le temps, ce qui n'est pas une habitude à prendre pour des raisons de sécurité. Mais aussi parce que root ayant toujours le droit, cela peut, justement, vous faire louper…

Souvent ça cloche au niveau des droits. Le soft tourne soit un uid/gid donné, mais cherche à accéder aux données d'un autre soft, dont les droits ne permettent pas l'accès au premier. Classique avec postfix/dovecot, ou amavis, etc. etc. etc.

La méthode bourrin pour s'en assurer c'est de fermer les accès extérieurs à vos services, de faire une archive de la partie de l'arborescence que vous soupçonnez (pour la restaurer correctement ensuite) et de permettre à tout le monde d'accéder à son contenu. Par exemple :

# tar cvfz bidule-svg.tgz bidule/
# chmod -R +rw bidule/
# chmod 777 $(find bidule/ -type d)

Essayer voir ce que ça donne s'il y a du mieux. Ensuite il faut restaurer les droits corrects.

# rm -Rf bidule/
# tar xvfz bidule-svg.tgz

Si le souci semble venir de là, il arrive assez souvent qu'il suffise de rajouter l'uid du premier soft dans le groupe utilisé par le second soft (ci-dessus, bidule).

# adduser uid-du-premier groupe-de-bidule

Ah, sympa ! Sympa ! Comment ne pas remercier au passage les auteurs de cet outil pour leur excellente idée d'utiliser un nom aussi commun, histoire de bien compliquer la tâche au pauvre admin qui est déjà en train de s'arracher les cheveux, et se trouve ainsi bien en galère de faire des requêtes pertinentes dans le moteurs de recherche.

Sympa (packagé) prévoit de fonctionner avec Apache2, mais il ne prévoit pas de lui donner les accès utiles. Vous aurez donc besoin d'ajouter www-data dans le groupe sympa, pour que apache2 puisse accéder aux fichiers de configuration dans /etc/sympa.

La sanction ? Des messages d'erreur du serveur apache qui refuse d'afficher le site. Mais ceci semble aussi pouvoir se manifester par un prétendu mode de maintenance.

# adduser www-data sympa

Au fait, si vous utilisez fastcgi, vous devez éditer le fichier sympa.conf et signaler que vous l'utilisez :

use_fast_cgi   1

Enfin si vous galérez depuis un bon moment, vous avez peut-être déjà tenté de réinstaller le package. Mais avec une base déjà peuplée que vous n'avez pas forcément envie de razer une N-ième fois, dbconfig qui est appelé par les scripts d'installation du package va vous casser les pieds.

Pour vous en sortir, allez mettre les informations qu'il vous redemande (mais pas toujours) dans /etc/dbconfig-common/sympa.conf

Après une restauration ou un upgrade, sympa semble ne pas voir vos listes ? Vous avez pourtant vérifié qu'elles sont présentes dans la base, recopié correctement les archives, repris les définitions, et tenté d'ugrader les tables avec sympa.pl -upgrade !?

Eh bien au lieu de perdre comme moi une journée à pleurer, sachez que sympa ne cherche plus les définitions de ses listes dans le répertoire expl, celui-ci s'appelle désormais list_data. Et donc :

# mv /var/lib/sympa/expl /var/lib/sympa/list_data

Mais Ô rage Ô désespoir, si comme moi après avoir rebooté le serveur vous constatez que sympa a changé d'avis et cherche de nouveau les déclarations de listes dans expl, vous aurez peut-être envie de vous simplifier la vie comme ceci :

# ln -s /var/lib/sympa/list_data /var/lib/sympa/expl

Tout a l'air de fonctionner, et un peu plus tard vous modifiez une config d'apache, vous le relancez (graceful ?) et là… plus aucun site ne se charge. Vérifiez un peu le statut du process apache :

$ps aux | grep apache
root      1845  0.0  0.8  56324  9124 ?        Ss   13:31   0:00 /usr/sbin/apache2 -k start
www-data  3228  0.0  1.0 148224 10372 ?        S    14:27   0:00 /usr/sbin/apache2 -k start
www-data  3230  0.0  0.0      0     0 ?        Z    14:27   0:00 [apache2] <defunct>
www-data  3231  0.0  0.0      0     0 ?        Z    14:27   0:00 [apache2] <defunct>
www-data  3232  0.0  0.0      0     0 ?        Z    14:27   0:00 [apache2] <defunct>
www-data  3233  0.0  0.0      0     0 ?        Z    14:27   0:00 [apache2] <defunct>
www-data  3234  0.0  0.0      0     0 ?        Z    14:27   0:00 [apache2] <defunct>
www-data  3239  0.0  0.0      0     0 ?        Z    14:27   0:00 [apache2] <defunct>

Si dans le log d'erreurs d'apache vous avez aussi un message du genre de celui-là

FastCGI process 3235 still did not exit, terminating forcefully

alors probablement le fast cgi perl qui exécute wwsympa.fcgi tourne avec l'uid de sympa, ce qui fait que apache ne parvient pas à lui envoyer des signaux pour le faire terminer quand il redémarre… et de ce fait ne redémarre pas !

Dans l'immédiat il faut tuer le process :

$ ps ax | grep wwsympa.fcgi
3235 ?        S      0:01 /usr/bin/perl /usr/lib/cgi-bin/sympa/wwsympa.fcgi
3262 pts/0    S+     0:00 grep wwsympa.fcgi
$ sudo kill 3235

Hop, apache2 est décoincé et tous les sites sont de nouveau en ligne.

Mais jusqu'au prochain reload apache seulement, pour permettre désormais à apache d'envoyer des signaux au CGI il faut activer le module suexec d'apache :

# a2enmod suexec

C'est tout pour le moment !

Si vous ne vous en sortez toujours pas, je vous conseille de vous trancher les poignets. On n'en meurt pas, ça fait un peu de repos, et vous rentrerez de l'hopital avec une paire de très pratiques repose-poignets :)