Bonjour tout le monde,
 
J'ai un petit souci sur le serveur de dev sous debian ( que je ne maitrise pas encore vraiment bien )
 
Suite à des mails envoyés par la fonction mail de certaines de mes pages en test qui ne marchaient pas, je suis allé sur le serveur de dev voir les mails en attente ( exim -bp )
Rien de spécial.
Mon collègue regarde deux trois trucs, on fait quelques manips anecdotiques, mais plus rien ne marche niveau envoi mail.
 
Pour résumer:
 
httpd est lancé par l'user nobody
exim4 est lancé par l'user Debian-exim
C'est normalement ce dernier qui crée des spools ( dans /var/spool/exim4/input/ ) et qui les "execute" ensuite.
Le problème, c'est que maintenant, c'est nobody qui crée des spool dans ce répertoire, avec des droits exclusifs pour nobody, et derrière le Debian-exim se voit refuser l'accès lorsqu'il veut traiter le spooler de mail.
 
Bref je ne sais pas vraiment ce qu'on a touché, mais j'ai pas mal de tests de fonctions de mail à faire, et j'avoue qu'avoir tous les mails envoyés par la fonction mail bloqués, c'est pas terrible ...
 
Si quelqu'un a une idée ou un peu de temps à consacrer pour tenter de débugger le truc.
 
A noter que j'ai mis les droits d'écriture à nobody sur le répertoire /var/spool/exim4/ sinon mes fonctions mail() me renvoyaient toutes false.
A noter aussi qu'avant qu'on y fourre notre nez, ça marchait très bien, et plutot que désinstaller / réinstaller, j'aimerai bien comprendre, ça me servira toujours
 
Config php.ini
sendmail_path = /usr/sbin/sendmail -t -i  
( essayé aussi avec /usr/sbin/exim4 -t ( -i etc )
 
Thanks a lot

Il a été stupide de modifier les droits des répertoires d'exim4 car ces répertoires appartiennent à exim et à personne d'autre et en l'occurence surement pas à l'utilisateur nobody qui peut être utiliser par plusieurs processus comme httpd....
Il y a deux méthodes (simples) pour envoyer des mails sur une machine unix :
1) utiliser sendmail  
   exim fournit de base le nécessaire...
2) discuter directement avec le MTA sur le port 25/465/587 (en fonction de la configuration)
 
En conclusion il faut restaurer les droits adéquats sur le répertoire /var/spool/exim4/ , httpd/nobody n'a d'autre rôle que de passer le mail à exim4 par le biais de sendmail/tcp et c'est tout... il n'a pas à écrire directement dans le spool d'exim4.
 
La lecture de la FAQ d'exim4 pourra aider pour la suite http://wiki.exim.org/FAQ

 
Sais tu les valeurs habituelles par défaut du /usr/sbin/exim4 ?
du répertoire /var/spool/exim4 et de ses sous répertoires ?
 
J'arrive vraiment pas à capter ce qu'on a fait pour que plus rien ne marche, mais là je m'enchevètre dans les droits users / groups / permissions ...
J'ai regardé des vieux mails lancés par l'appli web quand elle marchait, c'est bien l'user nobody qui à l'air d'être à la source des mails ( et donc des spools ? ).
 
Merci de l'aide

J'étoffe :
 
Pour info, j'ai installé exim sur un ubuntu qui trainait, config standard, là ça marche nikel ( logique ).
 
Du coup j'essaye d'attribuer les mêmes droits, mais le truc que je comprends pas:
 
Quand tu vas sur une page web sur chacun des serveur qui lance la fonction mail() ( script bateau hello world quoi )
 
Sur le serveur foireux:

 
 
Sur le bon serveur:

 
Du coup derrière j'ai un erreur de permission sur le premier serveur quand l'executable exim ( lancé en daemon par l'utilisateur Debian-exim ) veut traiter le spool.
 
Si jamais ça aide ..

de tête non.
la logique voudrait qu'ils appartiennent à l'utilisateur sous laquelle tourne le daemon exim.
Probablement exim ou debian-exim qui sait..
 
 
 

Lorsque tu ne comprends pas quelque chose il faut :
1) ne pas se précipiter
    notamment en appliquant des «tutoriels » variés et contradictoires sur le net
2) lire la documentation relatif à l'application qui te pose problème
 
3) relire la documentation relatif à l'application
 
4) et concernant les permissions man chmod, man chown
 

le fait que ce soit l'utilisateur nobody qui soit à l'origine des mails est normal :
c'est l'utilisateur sous lequel tourne ton daemon httpd et il faut bien être capable de savoir quel est l'utilisateur unix est à l'origine des mails en cas de problème (spam au hasard) afin de limiter les recherches.
En revanche le fait que l'utilisateur soit à l'origine des mails n'a *strictement* aucun rapport avec le propriétaire des spools d'exim.
Comme dit précédemment httpd se contente de remettre le mail à exim4 par le biais de /usr/bin/sendmail après il ne se préoccupe plus de rien.
Le fait que la fonction mail() de php ne fonctionnait pas correctement est donc lié à un problème intrinsèque à la création du mail et non pas à exim4 ....
 

ls -alh /usr/sbin/exim4 sur le bon serveur :
-rwsr-xr-x 1 root root 852K 2010-01-05 07:32 /usr/sbin/exim4
 
 
Sur le foireux j'ai déjà changé 15 fois les valeurs, mais en mettant les même, ça ne fait pas mieux marcher le schmilblik ..

/var/spool/exim4 doit être ainsi :

Qu'appelles tu changer « 15 fois les valeurs » ?
 

Problème réglé, en appliquant les mêmes droits que sur mon serveur de test
- aux repertoires
- a exim4
ça semble refonctionner
C'est pourtant des trucs que j'ai l'impression d'avoir fait 100 fois depuis 1 semaine ...

J'avais essayé avec root:root:
Debian-exim:mail  
etc etc ...  

man chown est ton ami, notamment le switch -R