Envoi de mail en console sous une Linux Mandrake ?
19 réponses
Magalie Sirea
Bonjour,
Une eptite question :
J'ai essaye d'envoyer un mail a partir de la console :
mail -v test@test.com (test@test.com est l'adresse de mon correspondant
....)
mais je me suis pris une erreur :
/usr/sbin/sendmail: No such file or directory
en rpm mail, j'ai uniquement procmail et mailx d'installe, pas de sendmail
ou postfix.
Ceux-ci sont ils obligatoires pour envoyer des emails ? Ou alors j'ai pas
mis un paramettre quelques
part qui dit d'utiliser le serveur smtp smtp.mondomaine.com ? (attention je
suis en console only pas de kde)
Car j'ai sur mon reseau un autre serveur disposant lui de Qmail qui s'occupe
de la reception et de l'emission
des courriers. ..
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Il y a peut-etre une erreur de dépendances sur la 10.0;
Faut croire.. Quoi que, il ne soit pas abhérant non plus que packageur considère qu'at a besoin de "mail" non ?
Mais euh, je percute seulement maintenant, mais pourquoi 'at' aurait besoin de la commande 'mail' ? Ce qu'il a besoin c'est d'un MDA ou d'un MTA et très généralement il s'agit du wrapper /usr/sbin/sendmail.
-- TiChou
Dans le message <news:pan.2004.10.08.23.02.35.811560@novazur.fr>,
*Christophe PEREZ* tapota sur f.c.o.l.configuration :
Il y a peut-etre une erreur de dépendances sur la 10.0;
Faut croire..
Quoi que, il ne soit pas abhérant non plus que packageur considère qu'at
a besoin de "mail" non ?
Mais euh, je percute seulement maintenant, mais pourquoi 'at' aurait besoin
de la commande 'mail' ? Ce qu'il a besoin c'est d'un MDA ou d'un MTA et très
généralement il s'agit du wrapper /usr/sbin/sendmail.
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Il y a peut-etre une erreur de dépendances sur la 10.0;
Faut croire.. Quoi que, il ne soit pas abhérant non plus que packageur considère qu'at a besoin de "mail" non ?
Mais euh, je percute seulement maintenant, mais pourquoi 'at' aurait besoin de la commande 'mail' ? Ce qu'il a besoin c'est d'un MDA ou d'un MTA et très généralement il s'agit du wrapper /usr/sbin/sendmail.
-- TiChou
Christophe PEREZ
Le Sat, 09 Oct 2004 01:34:41 +0200, TiChou a écrit:
Mais euh, je percute seulement maintenant, mais pourquoi 'at' aurait besoin de la commande 'mail' ? Ce qu'il a besoin c'est d'un MDA ou d'un MTA et très généralement il s'agit du wrapper /usr/sbin/sendmail.
Ben oui, mais bon, j'en sais rien moi ;-) Je me disais naïvement que le packageur avait trouvé utile de vérifier qu'il y avait impérativement un "mail", et il n'a pas trouvé mieux que d'imposer mailx ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Le Sat, 09 Oct 2004 01:34:41 +0200, TiChou a écrit:
Mais euh, je percute seulement maintenant, mais pourquoi 'at' aurait besoin
de la commande 'mail' ? Ce qu'il a besoin c'est d'un MDA ou d'un MTA et très
généralement il s'agit du wrapper /usr/sbin/sendmail.
Ben oui, mais bon, j'en sais rien moi ;-)
Je me disais naïvement que le packageur avait trouvé utile de vérifier
qu'il y avait impérativement un "mail", et il n'a pas trouvé mieux que
d'imposer mailx ;-)
Le Sat, 09 Oct 2004 01:34:41 +0200, TiChou a écrit:
Mais euh, je percute seulement maintenant, mais pourquoi 'at' aurait besoin de la commande 'mail' ? Ce qu'il a besoin c'est d'un MDA ou d'un MTA et très généralement il s'agit du wrapper /usr/sbin/sendmail.
Ben oui, mais bon, j'en sais rien moi ;-) Je me disais naïvement que le packageur avait trouvé utile de vérifier qu'il y avait impérativement un "mail", et il n'a pas trouvé mieux que d'imposer mailx ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
g.patel
On Fri, 08 Oct 2004 19:02:35 -0400, Christophe PEREZ wrote:
(...dépendances de 'at'...)
mailx <============================== oui, ça ne figure pas dans Mandrake Cooker (10.1)
Je n'ai pas trop envie de regarder le code de 'at' pour comprendre ce qui peut se passer quand il n'a pas d'outil de messagerie. Peut-etre que Mandrake a rajouté un peu de logique pour lui faire traiter avec grace le cas où /bin/mail est absent ? ou bien cette logique était déjà présente et dans ce cas c'est simplement une erreur de paquetage, et donc l'option 'force' de rpm est une bonne solution.
Gerard Patel
On Fri, 08 Oct 2004 19:02:35 -0400, Christophe PEREZ
<christophe.perez_faute@novazur.com> wrote:
(...dépendances de 'at'...)
mailx <==============================
oui, ça ne figure pas dans Mandrake Cooker (10.1)
Je n'ai pas trop envie de regarder le code de 'at' pour
comprendre ce qui peut se passer quand il n'a pas
d'outil de messagerie.
Peut-etre que Mandrake a rajouté un peu de logique pour
lui faire traiter avec grace le cas où /bin/mail est absent ?
ou bien cette logique était déjà présente et dans ce cas
c'est simplement une erreur de paquetage, et donc l'option
'force' de rpm est une bonne solution.
On Fri, 08 Oct 2004 19:02:35 -0400, Christophe PEREZ wrote:
(...dépendances de 'at'...)
mailx <============================== oui, ça ne figure pas dans Mandrake Cooker (10.1)
Je n'ai pas trop envie de regarder le code de 'at' pour comprendre ce qui peut se passer quand il n'a pas d'outil de messagerie. Peut-etre que Mandrake a rajouté un peu de logique pour lui faire traiter avec grace le cas où /bin/mail est absent ? ou bien cette logique était déjà présente et dans ce cas c'est simplement une erreur de paquetage, et donc l'option 'force' de rpm est une bonne solution.
Gerard Patel
Christophe PEREZ
Le Sat, 09 Oct 2004 00:21:42 +0000, gerard patel a écrit:
oui, ça ne figure pas dans Mandrake Cooker (10.1)
J'avais bien compris ;-)
Je n'ai pas trop envie de regarder le code de 'at' pour comprendre ce qui peut se passer quand il n'a pas d'outil de messagerie.
Comme je te comprends...
Peut-etre que Mandrake a rajouté un peu de logique pour lui faire traiter avec grace le cas où /bin/mail est absent ?
Souhaitons le en tout cas.
ou bien cette logique était déjà présente et dans ce cas c'est simplement une erreur de paquetage,
Ça peut arriver, on ne lui en voudra pas pour autant.
et donc l'option 'force' de rpm est une bonne solution.
Bah, je me tâte... D'un côté, ça ne coûte pas grand chose de garder mailx, au risque de devoir penser à refaire le lien vers nail lors de la maj éventuelle. Lien qui devra de toutes les façons être refait si je force et que le prochain package (update) n'est pas comme celui de la cooker...
En tout cas, pas très important tout ça. Pas de quoi fouetter un pingouin ;-)
N'empêche que je suis ravi d'avoir connu nail (merci TiChou).
-- Christophe PEREZ Écrivez moi sans _faute !
Le Sat, 09 Oct 2004 00:21:42 +0000, gerard patel a écrit:
oui, ça ne figure pas dans Mandrake Cooker (10.1)
J'avais bien compris ;-)
Je n'ai pas trop envie de regarder le code de 'at' pour
comprendre ce qui peut se passer quand il n'a pas
d'outil de messagerie.
Comme je te comprends...
Peut-etre que Mandrake a rajouté un peu de logique pour
lui faire traiter avec grace le cas où /bin/mail est absent ?
Souhaitons le en tout cas.
ou bien cette logique était déjà présente et dans ce cas
c'est simplement une erreur de paquetage,
Ça peut arriver, on ne lui en voudra pas pour autant.
et donc l'option 'force' de rpm est une bonne solution.
Bah, je me tâte...
D'un côté, ça ne coûte pas grand chose de garder mailx, au risque de
devoir penser à refaire le lien vers nail lors de la maj éventuelle.
Lien qui devra de toutes les façons être refait si je force et que le
prochain package (update) n'est pas comme celui de la cooker...
En tout cas, pas très important tout ça. Pas de quoi fouetter un
pingouin ;-)
N'empêche que je suis ravi d'avoir connu nail (merci TiChou).
Le Sat, 09 Oct 2004 00:21:42 +0000, gerard patel a écrit:
oui, ça ne figure pas dans Mandrake Cooker (10.1)
J'avais bien compris ;-)
Je n'ai pas trop envie de regarder le code de 'at' pour comprendre ce qui peut se passer quand il n'a pas d'outil de messagerie.
Comme je te comprends...
Peut-etre que Mandrake a rajouté un peu de logique pour lui faire traiter avec grace le cas où /bin/mail est absent ?
Souhaitons le en tout cas.
ou bien cette logique était déjà présente et dans ce cas c'est simplement une erreur de paquetage,
Ça peut arriver, on ne lui en voudra pas pour autant.
et donc l'option 'force' de rpm est une bonne solution.
Bah, je me tâte... D'un côté, ça ne coûte pas grand chose de garder mailx, au risque de devoir penser à refaire le lien vers nail lors de la maj éventuelle. Lien qui devra de toutes les façons être refait si je force et que le prochain package (update) n'est pas comme celui de la cooker...
En tout cas, pas très important tout ça. Pas de quoi fouetter un pingouin ;-)
N'empêche que je suis ravi d'avoir connu nail (merci TiChou).
-- Christophe PEREZ Écrivez moi sans _faute !
TiChou
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Es-tu sûr que ton système de fichier est bien en ext2/ext3 ?
Ben oui ! Le fait que ce soit un montage nfs peut y changer quelque chose ? Il semblerait en tout cas.
Bien sûr ! Si c'est un montage NFS, ça n'est alors plus un système de fichier ext2/3 mais un système de fichier NFS.
Sur mon propre système de fichier, ça fonctionne (mon home est en montage nfs, je l'oublie parfois), bien que ça ne fonctionne pas en user, mais seulement en root :
$ chattr +i fichier chattr: Operation not permitted while setting flags on fichier
man chattr :-)
Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.
Quelle version de noyau ?
2.6.8.1 compilé main ! ;-)
Tu devrais plutôt essayer avec gcc. Certes c'est moins valorisant, mais tellement plus agréable. :-P
-- TiChou
Dans le message <news:pan.2004.10.08.03.16.59.803688@novazur.fr>,
*Christophe PEREZ* tapota sur f.c.o.l.configuration :
Es-tu sûr que ton système de fichier est bien en ext2/ext3 ?
Ben oui !
Le fait que ce soit un montage nfs peut y changer quelque chose ?
Il semblerait en tout cas.
Bien sûr ! Si c'est un montage NFS, ça n'est alors plus un système de
fichier ext2/3 mais un système de fichier NFS.
Sur mon propre système de fichier, ça fonctionne (mon home est en
montage nfs, je l'oublie parfois), bien que ça ne fonctionne pas en user,
mais seulement en root :
$ chattr +i fichier
chattr: Operation not permitted while setting flags on fichier
man chattr :-)
Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE
capability can set or clear this attribute.
Quelle version de noyau ?
2.6.8.1 compilé main ! ;-)
Tu devrais plutôt essayer avec gcc. Certes c'est moins valorisant, mais
tellement plus agréable. :-P
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Es-tu sûr que ton système de fichier est bien en ext2/ext3 ?
Ben oui ! Le fait que ce soit un montage nfs peut y changer quelque chose ? Il semblerait en tout cas.
Bien sûr ! Si c'est un montage NFS, ça n'est alors plus un système de fichier ext2/3 mais un système de fichier NFS.
Sur mon propre système de fichier, ça fonctionne (mon home est en montage nfs, je l'oublie parfois), bien que ça ne fonctionne pas en user, mais seulement en root :
$ chattr +i fichier chattr: Operation not permitted while setting flags on fichier
man chattr :-)
Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.
Quelle version de noyau ?
2.6.8.1 compilé main ! ;-)
Tu devrais plutôt essayer avec gcc. Certes c'est moins valorisant, mais tellement plus agréable. :-P
-- TiChou
Christophe PEREZ
Le Sun, 10 Oct 2004 00:24:32 +0200, TiChou a écrit:
Bien sûr ! Si c'est un montage NFS, ça n'est alors plus un système de fichier ext2/3 mais un système de fichier NFS.
Évidemment pfff....
$ chattr +i fichier chattr: Operation not permitted while setting flags on fichier
man chattr :-)
Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.
Tu devrais plutôt essayer avec gcc. Certes c'est moins valorisant, mais tellement plus agréable. :-P
C'est puissant linux quand même ! Quel temps je vais gagner maintenant. Mais ça fera moins d'effet en société ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Nicolas George
Christophe PEREZ wrote in message :
et comme je ne connais pas le 'CAP_LINUX_IMMUTABLE'...
Les capabilities sont une tentative pour augmenter la granularité des droits sous Linux : au lieu d'avoir soit les droits de root, et pouvoir tout faire, soit aucun droit particulier du tout, il y a différentes catégories de droits : droits de bind()er un port privilégié, changer le propriétaire d'un fichier, verrouiller la mémoire, etc.
Ça n'a jamais pris, on peut se demander pourquoi car c'est une bonne initiative. Je suppose que le manque principal est celui d'attributs de fichiers SET-CAP-* qui fassent l'équivalent des SETUID, et d'outils shell.
Christophe PEREZ wrote in message
<pan.2004.10.10.03.44.00.164281@novazur.fr>:
et comme je ne
connais pas le 'CAP_LINUX_IMMUTABLE'...
Les capabilities sont une tentative pour augmenter la granularité des droits
sous Linux : au lieu d'avoir soit les droits de root, et pouvoir tout faire,
soit aucun droit particulier du tout, il y a différentes catégories de
droits : droits de bind()er un port privilégié, changer le propriétaire d'un
fichier, verrouiller la mémoire, etc.
Ça n'a jamais pris, on peut se demander pourquoi car c'est une bonne
initiative. Je suppose que le manque principal est celui d'attributs de
fichiers SET-CAP-* qui fassent l'équivalent des SETUID, et d'outils shell.
et comme je ne connais pas le 'CAP_LINUX_IMMUTABLE'...
Les capabilities sont une tentative pour augmenter la granularité des droits sous Linux : au lieu d'avoir soit les droits de root, et pouvoir tout faire, soit aucun droit particulier du tout, il y a différentes catégories de droits : droits de bind()er un port privilégié, changer le propriétaire d'un fichier, verrouiller la mémoire, etc.
Ça n'a jamais pris, on peut se demander pourquoi car c'est une bonne initiative. Je suppose que le manque principal est celui d'attributs de fichiers SET-CAP-* qui fassent l'équivalent des SETUID, et d'outils shell.
Christophe PEREZ
Le Sun, 10 Oct 2004 10:27:47 +0000, Nicolas George a écrit:
Les capabilities sont une tentative pour augmenter la granularité des droits sous Linux : au lieu d'avoir soit les droits de root, et pouvoir tout faire, soit aucun droit particulier du tout, il y a différentes catégories de droits : droits de bind()er un port privilégié, changer le propriétaire d'un fichier, verrouiller la mémoire, etc.
Ok, clair, mais concrètement, on "joue" comment avec ?
Ça n'a jamais pris, on peut se demander pourquoi car c'est une bonne initiative. Je suppose que le manque principal est celui d'attributs de fichiers SET-CAP-* qui fassent l'équivalent des SETUID, et d'outils shell.
Ah, c'est sûr que si les outils n'existent pas, ça n'est pas prêt d'être utilisé ;-)
Merci pour les explications.
-- Christophe PEREZ Écrivez moi sans _faute !
Le Sun, 10 Oct 2004 10:27:47 +0000, Nicolas George a écrit:
Les capabilities sont une tentative pour augmenter la granularité des droits
sous Linux : au lieu d'avoir soit les droits de root, et pouvoir tout faire,
soit aucun droit particulier du tout, il y a différentes catégories de
droits : droits de bind()er un port privilégié, changer le propriétaire d'un
fichier, verrouiller la mémoire, etc.
Ok, clair, mais concrètement, on "joue" comment avec ?
Ça n'a jamais pris, on peut se demander pourquoi car c'est une bonne
initiative. Je suppose que le manque principal est celui d'attributs de
fichiers SET-CAP-* qui fassent l'équivalent des SETUID, et d'outils shell.
Ah, c'est sûr que si les outils n'existent pas, ça n'est pas prêt
d'être utilisé ;-)
Le Sun, 10 Oct 2004 10:27:47 +0000, Nicolas George a écrit:
Les capabilities sont une tentative pour augmenter la granularité des droits sous Linux : au lieu d'avoir soit les droits de root, et pouvoir tout faire, soit aucun droit particulier du tout, il y a différentes catégories de droits : droits de bind()er un port privilégié, changer le propriétaire d'un fichier, verrouiller la mémoire, etc.
Ok, clair, mais concrètement, on "joue" comment avec ?
Ça n'a jamais pris, on peut se demander pourquoi car c'est une bonne initiative. Je suppose que le manque principal est celui d'attributs de fichiers SET-CAP-* qui fassent l'équivalent des SETUID, et d'outils shell.
Ah, c'est sûr que si les outils n'existent pas, ça n'est pas prêt d'être utilisé ;-)
