Discussion :

[Invité]

Contexte d'origine :
Problème d'envoi de mails sur une Centos KimSufi release3

J'ai configuré le php.ini pour avoir les logs avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mail.log = /var/log/dossier/mail.log

J'ai lu en parallèle que je pouvais ajouter le paramètre -f à ajouter dans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sendmail_path = /usr/sbin/sendmail -t -i -fMAIL@DOMAINE.EXT

Je l'ai mis en place, et grâce à cela nos mails sortent à nouveau.

Le hic,
J'aurais voulu que les logs m'informent du problème, pour le corriger. Ce n'est pas le cas. J'ai trouvé la solution, par chance.
Les logs des mails ne sont toujours pas écrits dans mail.log. Enfait, ils sont écrits partiellement, il me semble.

J'ai l'impression que quand ce sont des tâches cron qui sont lancées, les logs PHP et MAILS sont bien écrites.

Mais, par contre, quand je tente d'envoyer un formulaire par mail depuis le site web, AUCUN LOG dans mail.log, et pas une seule erreur PHP remontée depuis le site. ( Ca me semble trop beau. )

Apache est lancé en root ... les fichiers logs ont été créé en root également.
Je pense qu'il doit y avoir un soucis à faire comme cela. Je pense que les logs du site ne remontent pas ne sont pas écrits dans les fichiers.
J'aurais besoin de vos conseils.

( Sur développez.net )

[Golgotha]: R-Solidaires> moi je ne pense pas que un fichier de log puisse être partiel. Soit il est là et il est complet, soit il n'existe pas ou plus mis à jour.
Ce que je veux dire finalement c'est que celons moi deux applications ne vont pas écrire dans le même fichier log.

De mon coté, j'ai donc les logs mails que je veux faire fonctionner par php.ini ( récupérer les logs mails du site, par exemple pour une récupération de mot de passe )
J'ai également des logs qui sont enregistrées dans maillog, mais il me semble qu'elles sont moins complètes.

je croyais que php.ini la directive des erreurs des mails, prend en compte toutes les erreurs des mails coté serveur/cron et coté Site Web ? Est-ce que je me trompe ?

Avez-vous des conseils pour lancer apache normalement, donc, pas en root ?
J'ai déjà des utilisateurs présents sur le serveur, comme par exemple l'utilisateur qui contient les données du site. Puis je donner apache a cet utilisateur, sans risques ?

[Golgotha]: R-Solidaires> pour apache, non normalement il ne se lance pas en root. apache est lié plutôt à www-data
Ok mais est ce que www-data correspond pour une Centos ?
[Golgotha]: R-Solidaires> il m'est arrivé de devoir élargir les droits de www-data ( le groupe de apache )
[Golgotha]: R-Solidaires> pour lui donnée les droits d'écriture sur certains répertoire par exemple

J'ai créé un répertoire, dossier, dans var/log/dossier/
Dans ce dossier, j'ai ajouté simplement 2 fichiers. Le fichier log pour php, et le fichier log pour les mails, configurés depuis php.ini
Cela pourrait expliquer que les logs des mails du site, et surement les logs de php, ne soient pas écrites dans leur fichier log respectif ?

[Golgotha]: R-Solidaires> moi si j'ai un conseil c'est ne change rien sauf à donner des droits dans des dossier spécifique à www-data
15:40 [R-Solidaires]: ok, donc je me renseigne deja pour cela.

( A ce moment la, Golgotha pensait que je voulais faire tourner Apache en root, il n'avait pas compris que apache tourne actuellement en root. )

15:47 [R-Solidaires]: -f, c'est pour forcer un mail expediteur. DIRE, salut, c'est moi.
15:47 [R-Solidaires]: Du coup, on a une adresse de retour.
15:48 [R-Solidaires]: Et les mails sortent.
15:48 [R-Solidaires]: Mais, j'ai compris ca en lisant un forum.
15:48 [R-Solidaires]: Ma demarche a été de faire le menage dans le php.ini et m'assurer que tout est ok, et de monter les logs des mails.
15:48 [R-Solidaires]: je voulais finalement avoir une erreur du type :
15:48 [R-Solidaires]: He ho, et ton -f tu le met ou ? Dans le paté ?
15:49 [R-Solidaires]: Mais du coup, parametrer php.ini n'a rien changé, je n'ai toujours pas les logs des mails.
15:49 [R-Solidaires]: je voudrais exploiter la directive de php5.3
15:49 [R-Solidaires]: qui trace mes mails.
15:49 [R-Solidaires]: mais, finalement, ca ne me les trace que sur cron.
15:49 [R-Solidaires]: donc, je vois bien que mon cron travail et sort mes mails, c'est super.
15:50 [R-Solidaires]: Mais .. coté site ... par exemple, recuperation de mot de passe, ce fichier log du php.ini ne me donne rien.
15:50 [R-Solidaires]: J'ai par contre un visu de log dans maillog, mais pas présenté de la même façon que les logs du php.ini ( ce que je préfèrerais )

15:50 [R-Solidaires]: mais je comprend pas pourquoi j'ai 2 logs différents : maillog, et le mail.log ( du php.ini , qui semble parfait pour déboguer, avec la ligne ou se trouve mail(), le nom du fichier et tout cela )

15:51 [R-Solidaires]: du coup j'ai résolu une partie du problème ( l'envoie de mails ), mais je suis toujours aveugle sur les erreurs.

15:52 [R-Solidaires]: et je pense que le fait que apache soit root, c'est pas vraiment très clean.
J'ai aussi créé mes fichiers logs ( suite aux modifs de php.ini ) donc, les fichier log PHP et MAIL, en etant root. Du coup, je pense que les infos coté site, ne peuvent pas etre ecrites ?!!
15:52 [R-Solidaires]: et que seul les infos cron peuvent être écrites ?

enfin en gros je me perd un peu la, et pourtant, si proche du but.

15:52 [R-Solidaires]: je voudrais mes logs, dans mail.log

15:53 [Golgotha]: R-Solidaires> ton cron il est root ?
15:53 [R-Solidaires]: et aussi, passer apache en normal^ et pas en root de folie.
15:53 [R-Solidaires]: oui cron est root.

[Invité]

J'ai testé de passer l'user/group de mes fichiers de logs comme appartenant à apache/apache, mais, lorsque je test le formulaire de récupération de mot de passe, depuis le site, je n'ai toujours pas de logs, dans mail.log

Par contre, j'ai des logs dans maillog, que le mail est bien passé par postfix ( je suppose que maillog est lié à postfix ? ).

Finalement, je n'arrive toujours pas a obtenir des logs sur les mails envoyés depuis le site, en utilisant la directive php.ini 5.3 ( mail.log = /var/log/dossier/mail.log )

[apaul]

Salut,

Oui, sur CentOS, le maillog est le log de Postfix. Tout ce qui passe par lui y est inscrit.

Sinon, comment sais-tu que Apache est lancé en tant que root? Tu peux nous donner le résultat de la commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ps aux | grep -w httpd

Peux tu nous donner le résultat de la commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ls -lRa /var/log/dossier/

[Invité]

Bonjour.

En fait, je dis que Apache est en root, car certainement les choses ont mal été comprises au départ.

L'ancien SysAdmin travaillait avec l'utilisateur root de linux.

De mon côté, j'ai continué de la sorte, sur les conseils de mon collègue.

Entre temps, j'ai fais des mises à jour, et j'ai arrêté puis relancer cron, apache, mysql, postfix, mais en étant logué avec mon utilisateur root.

Voilà pourquoi je dis que apache est en root, si je comprend bien.

Il semble pourtant, qu'il ne faut pas faire ainsi. Je suis a vrai dire embêté et intrigué. Si j'ai bien compris, je dois lancer apache avec un utilisteur linux de base (...)

Surement avons nous déjà un utilisateur de base sur notre serveur Centos.
Par exemple, si je comprend bien, j'ai un utilisateur MachinBidule, qui lui, possède le contenu www de notre site en ligne.
Est ce que je pense mal, et me trompe, si je veux par exemple, utiliser cet utilisateur, pour lancer apache ?

Mes intérogations sont elles claires et compréhensibles ?




Pour la premiere commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 ps aux | grep -w httpd
root      3029  0.0  0.1 136896  7228 ?        SNs  Aug24   0:21 /usr/sbin/httpd
apache    7314  0.0  0.1 137028  6780 ?        SN   16:24   0:00 /usr/sbin/httpd
apache   10789  0.0  0.1 137028  6668 ?        SN   17:00   0:00 /usr/sbin/httpd
apache   14104  0.0  0.1 137028  6584 ?        SN   17:33   0:00 /usr/sbin/httpd
apache   14109  0.0  0.1 137028  6764 ?        SN   17:33   0:00 /usr/sbin/httpd
apache   14688  0.0  0.1 137164  6652 ?        SN   17:39   0:00 /usr/sbin/httpd
apache   14701  0.0  0.1 137028  6584 ?        SN   17:39   0:00 /usr/sbin/httpd
apache   15113  0.0  0.1 137028  6592 ?        SN   17:43   0:00 /usr/sbin/httpd
apache   15116  0.0  0.1 137028  6576 ?        SN   17:43   0:00 /usr/sbin/httpd
apache   15117  0.0  0.1 137028  6616 ?        SN   17:43   0:00 /usr/sbin/httpd
apache   15287  0.0  0.1 137028  6584 ?        SN   17:45   0:00 /usr/sbin/httpd
apache   15374  0.0  0.1 137164  6580 ?        SN   17:46   0:00 /usr/sbin/httpd
apache   15709  0.0  0.1 137028  6584 ?        SN   17:50   0:00 /usr/sbin/httpd
apache   17059  0.0  0.1 137032  6516 ?        SN   18:03   0:00 /usr/sbin/httpd
apache   17061  0.0  0.1 137028  6552 ?        SN   18:03   0:00 /usr/sbin/httpd
apache   17065  0.0  0.1 137028  6580 ?        SN   18:03   0:00 /usr/sbin/httpd
apache   17266  0.0  0.1 137028  6560 ?        SN   18:05   0:00 /usr/sbin/httpd
apache   17267  0.0  0.1 137032  6508 ?        SN   18:05   0:00 /usr/sbin/httpd
apache   17268  0.0  0.1 137028  6580 ?        SN   18:05   0:00 /usr/sbin/httpd
apache   17269  0.0  0.1 137028  6480 ?        SN   18:05   0:00 /usr/sbin/httpd
apache   17271  0.0  0.1 137028  6584 ?        SN   18:05   0:00 /usr/sbin/httpd
apache   17272  0.0  0.1 137028  6564 ?        SN   18:05   0:00 /usr/sbin/httpd
root     17637  0.0  0.0 105364   884 pts/0    S+   18:07   0:00 grep -w httpd

Pour la deuxième commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
ls -lRa /var/log/dossier/
/var/log/dossier/:
total 348
drwxr-xr-x  2 root   root     4096  6 août  03:43 .
drwxr-xr-x 10 root   root    12288 24 août  03:47 ..
-rw-r--r--  1 apache apache 156462 28 août  03:00 error_log.log
-rw-r--r--  1 apache apache 170229 27 août  04:02 mail.log

Voilà. Je vous remercie humblement pour vos conseils qui me sont indispensables pour ne pas stagner sur place. Je veux permettre à notre association d'évoluer afin de pouvoir s'occuper de nos compatriotes, en utilisant des outils bien administrés. Sans vos conseils, c'est notre projet qui est en danger. Merci.

[apaul]

Bonjour,

Je ne vais pas vous faire un cours Linux/Unix car ca serait long (excusez donc si je suis un peu trop rapide dans mes explications)
Pour votre première question, regardez le résultat de la 1ère commande que je vous ai demandée. Elle affiche les processus Apache (qui se nomment httpd sous CentOS) ainsi que l'utilisateur qui les lance.

On voit le premier httpd qui appartient effectivement à root. C'est normal. C'est le processus père (celui qui génère les autres processus) et il a besoin d'être root (par exemple, pour ouvrir le port 80). Par contre, les processus enfants (les autres httpd) appartiennent bien à l'utilisateur "apache", qui est en général un utilisateur avec des droits bien plus limités.

Donc pas d'inquiétude de ce côté! Votre apache tourne bien avec un utilisateur non privilégié, tout va bien.

Ca confirme néanmoins que pour votre 2nde question (les logs) le répertoire /var/log/dossier ainsi que les fichiers qui y sont doivent bien appartenir à l'utilsateur apache. D'après le résultat de la 2nde commande, c'est bien le cas. D'ailleurs, les fichiers qui y se trouvent ne sont pas vides. Ca laisse supposer que PHP y inscrit bien les valeurs que vous souhaitez, non?

Ceci dit, vous pouvez faire un chmod apache:apache /var/log/dossier, car dans l'état actuel des choses, si PHP est bien capable d'écrire dans ces fichiers, il est incapable d'en créer de nouveaux dans ce /var/log/dossier/, ce qui peut être problématique en cas de rotation de logs par exemple.

[Invité]

Donc pas d'inquiétude de ce côté! Votre apache tourne bien avec un utilisateur non privilégié, tout va bien.

Excellente nouvelle.
Mais du coup, je ne comprend pas ce que l'on me dit, je ne dois quand même pas travailler avec l'utilisateur root de linux. Mais de ce fait, avec quel utilisateur faut t'il travailler ? Le " simple " utilisateur qui possède les fichiers du site dans son répertoire www est t'il un bon choix pour utiliser SSH ?

Ca confirme néanmoins que pour votre 2nde question (les logs) le répertoire /var/log/dossier ainsi que les fichiers qui y sont doivent bien appartenir à l'utilsateur apache. D'après le résultat de la 2nde commande, c'est bien le cas. D'ailleurs, les fichiers qui y se trouvent ne sont pas vides. Ca laisse supposer que PHP y inscrit bien les valeurs que vous souhaitez, non?

OUI, mais NON également.
Comme je disais, j'ai uniquement des logs sur les actions lancées via CRON.
Si je fais des actions côté site web, elles ne sont pas loguées.
On voit les heures de connexion, de nuit, il s'agit bien des tâches cron qui tournent.
Pourquoi je n'arrive pas à obtenir des logs dans mail.log, depuis mes actions du site même, en temps que visiteur.

Ceci dit, vous pouvez faire un chmod apache:apache /var/log/dossier, car dans l'état actuel des choses, si PHP est bien capable d'écrire dans ces fichiers, il est incapable d'en créer de nouveaux dans ce /var/log/dossier/, ce qui peut être problématique en cas de rotation de logs par exemple.

Très bien, j'entend le besoin d'écriture, en cas de rotation de logs.

Je reste toujours étonné, et dans l'incompréhension, pour cette directive php5.3 mail.log, qui ne me retourne pas les traces lors d'une simple récupération par mot de passe, depuis le site Web.

Pourtant, ça devrait être logué dans mail.log !

En tout cas, merci déjà pour les confirmations que tu m'as apporté.
Si d'autres personnes peuvent aider apaul, pour que nous puissions comprendre ce qui se passe avec mail.log, par avance, merci.

[apaul]

Mais du coup, je ne comprend pas ce que l'on me dit, je ne dois quand même pas travailler avec l'utilisateur root de linux. Mais de ce fait, avec quel utilisateur faut t'il travailler ? Le " simple " utilisateur qui possède les fichiers du site dans son répertoire www est t'il un bon choix pour utiliser SSH ?

Efectivement, en root on peut faire n'importe quoi, et donc pour éviter les bêtises, on évite de se connecter en tant que tel.
Dans le cadre d'un serveur web, oui, utiliser l'utilisateur proriétaire des fichiers du site est une solution tout à fait envisageable. Il y a tout de même des choses qui ne sont faisables que par root, donc dans ce cas, il faudra faire un "sudo" ou un "su" avant, afin de devenir temporairement root.
Par défaut, seulement root peut redémarrer Apache ou modifier le php.ini par exemple.

OUI, mais NON également.
Comme je disais, j'ai uniquement des logs sur les actions lancées via CRON.
Si je fais des actions côté site web, elles ne sont pas loguées.
On voit les heures de connexion, de nuit, il s'agit bien des tâches cron qui tournent.
Pourquoi je n'arrive pas à obtenir des logs dans mail.log, depuis mes actions du site même, en temps que visiteur.

Ok, au temps pour moi, j'avais lu trop vite.
Donc ca veut dire que Apache ne lit pas le même fichier de conf que le cli (ce qui est tout de même étrange sur une CentOS, sauf modification).
Est-ce que tu peux faire par exemple une page web qui t'affiche les valeurs du php.ini?

Par exemple, un fichier contenant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
<?php
echo ini_get('sendmail_path') .'\n<br/>\n'. ini_get('mail.log').'\n<br/>\n'. ini_get('SMTP') ;
?>

Et voir ce qu'il affiche via un navigateur et éventuellement comparer avec la ligne de commande (php -f ton_fichier.php) pour voir les différences ?

Il est aussi possible que ton site modifie les valeurs du php.ini (avec un ini_set()).

Et un phpinfo() te donne quelle valeur pour l'emplacement du php.ini?

[Invité]

Dans le cadre d'un serveur web, oui, utiliser l'utilisateur propriétaire des fichiers du site est une solution tout à fait envisageable.

Très bien, je commence à mieux comprendre les droits linux, je ne les utilisais pas spécialement quand j'étais en mutualisé. Parfait Merci beaucoup.

Avec un "sudo" ou un "su" on devient un vrai root, avec 100% des actions permises, ou 99,22 % ?

2. Donc ca veut dire que Apache ne lit pas le même fichier de conf que le cli (ce qui est tout de même étrange sur une CentOS, sauf modification).
Est-ce que tu peux faire par exemple une page web qui t'affiche les valeurs du php.ini?

Oui je peux avoir les valeurs du php.ini et d'ailleur, j'ai déjà longuement fouillé la thematique, ça tombe bien.
Il me semble qu'il n'y a qu'un seul php.ini pour php et pour le site web. Il semble que ce ne soit pas le problème. Tu peux me le confirmer je pense.

Je sais que je suis en FastCGI, et j'avais lu cette possibilité de double php.ini
J'avais donc regardé sur le phpinfo() pour justement connaitre l'emplacement du php.ini du site.
De toute façon, si je cherche php.ini sur le serveur avec un locate, je ne trouve que 2 réponses, le php.ini et le php.ini.dist ( je crois ) ( qui est je crois un modèle en exemple. )

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
	# php --ini
	Configuration File (php.ini) Path: /etc
	Loaded Configuration File:         /etc/php.ini
	Scan for additional .ini files in: /etc/php.d

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
	locate php.ini
		/etc/php.ini
		/etc/php.ini.dist
		/usr/share/doc/php-common-5.3.3/php.ini-development
		/usr/share/doc/php-common-5.3.3/php.ini-production

Dans le phpinfo() je lis :
/etc/php.ini
sendmail_path j'ai bien ma valeur : /usr/sbin/sendmail -t -i -fMONMAIL@domaines-solidaires.org
mail.add_x_header est bien à On
mail.log à pour chemin /var/log/phpini/mail.log qui existe bien, puisque cron écrit. Mais depuis le site, une récupération de mot de passe n'écrit pas.

Et voir ce qu'il affiche via un navigateur et éventuellement comparer avec la ligne de commande (php -f ton_fichier.php) pour voir les différences ?
Il est aussi possible que ton site modifie les valeurs du php.ini (avec un ini_set()).
Et un phpinfo() te donne quelle valeur pour l'emplacement du php.ini?

3 questions à la chaîne, eh bien eh bien je t'en remercie
Ca m'aide beaucoup de voir que ta logique s'approche beaucoup de la mienne, et que je ne suis pas totalement hors sujet.

Je vais tenter pour php -f mon_fichier.php
Je te transmet cela dans la soirée ou demain au plus tard.

Je vais également réfléchir à ce que tu m'as rappelé, qu'effectivement je peux très bien être confronté à un ini_set() mais pourquoi alors ça marcherait sous cron et pas sur le site, je ne visualise pas très bien. Je comprend que ça permet d'effacer la configuration de php.ini pour une autre. Mais si tel était le cas, et vu que d'après moi je n'ai qu'un seul fichier ini, ca ne devrait pas avoir d'incidences, le résultat devrait être le même. Toutefois, une personne avertie en vaut 2, et je prendrais garde de vérifier.

Pour l'emplacement, j'ai donc déjà répondu.

Voilà bien pourquoi je reste assé perplexe mais j'espère vraiment que toi ou un autre membre de l'équipe pourra apporter des pistes.
Ce n'est que de l'informatique, et je n'aime pas quand la machine ne fais pas ce que j'attend
Surtout que, toute notre problématique tourne actuellement autour des mails, et du suivi des erreurs.
Mon association serait plus solide pour avancer, avec des retours de logs au bon endroit, avec les bonnes directives.


Ah tiens, j'ai appelé OVH pendant une demie heure en début de semaine.
Merci le sur coût du support, il n'ont rien sur me dire. Bon je comprend, ce n'est pas de la magie que l'on attend.
Le mec m'a dit, des tutos ? Non on a rien, c'est en développement, on utilise Google.
Ok pas de soucis, je connais.
La il tape les mots clés de base du type mail.log directive php.ini ou équivalent.

Il me sort : http://www.howtoforge.com/how-to-log...tect-form-spam
Je regarde rapidement ( très rapidement, je n'ai pas encore lu en fait; )
Je lui dit, humm oui, ça semble être ce que j'ai fais.
Et lui de me dire : vous avez du louper quelque chose.

Très bien Merci OVH Je suis rassuré ....
Sauf que de ce que j'ai lu, je n'ai rien loupé. Je vais donc lire cela.
De votre côté, toute piste est bonne à prendre.


Par avance, merci à toute les personnes qui pourront tenter de m'aider à résoudre ce problème.
Merci encore à toi, apaul, j'espère que tu sera inspiré en lisant ma réponse, car la, pour ma part, hormis les forums, je sèche un peu sur ce problème.

[apaul]

Avec un "sudo" ou un "su" on devient un vrai root, avec 100% des actions permises, ou 99,22 % ?

Pour sudo, ca dépend de ta config dans /etc/sudoers. Le sudo peut très bien te donner accès à une seule commande habituellement réservée à root. Néanmoins, par défaut, c'est souvent du 100% root.

Pour su, c'est du 100%.

Il me semble qu'il n'y a qu'un seul php.ini pour php et pour le site web. Il semble que ce ne soit pas le problème. Tu peux me le confirmer je pense.

Pas obligatoirement. Sur une debian par exemple, ce sont 2 fichiers différents je crois. Par contre, d'après ta config, tu n'as bien qu'un php.ini, donc c'est celui-là.

Je vais également réfléchir à ce que tu m'as rappelé, qu'effectivement je peux très bien être confronté à un ini_set() mais pourquoi alors ça marcherait sous cron et pas sur le site, je ne visualise pas très bien. Je comprend que ça permet d'effacer la configuration de php.ini pour une autre. Mais si tel était le cas, et vu que d'après moi je n'ai qu'un seul fichier ini, ca ne devrait pas avoir d'incidences, le résultat devrait être le même.

En passant par le site, tu as peut-être des sessions activées ou des includes qui ne sont pas pris en compte quand tu lances le script en ligne de commande. Du coup le comportement est différent.

D'ailleurs, question bête, le fichier que tu lances par cron, c'est bien le même qui est utilisé sur ton site, ou ce sont 2 fichiers différents? Parce que le mail.log de php ne note que les appels à la fonction mail(). Il y a d'autres moyens pour envoyer des mails, du coup, si le script lancé par cron utilise mail() mais pas celui du site, ben ca expliquerait le pourquoi du comment.