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. ..
On Thu, 07 Oct 2004 10:44:16 +0200, Magalie Sirea wrote:
Bonjour,
Bonjour
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.
C'est bizarre que sur ton systeme il n'y ai pas de MTA (exim, sendmail, qmail ou autre)
Logiquement plein d'utilitaires (dont cron) refusent de s'installer (en RPM) sans un MTA present sur le systeme.
Tu es le seul admin de cet ordinateur ?
Pour discuter entre specialistes des sujets relatifs au serveurs de mail, il y a aussi fr.comp.mail.serveurs. :-)
-- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
TiChou
Dans le message <news:416501db$0$11878$, *Magalie Sirea* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
Une eptite question :
J'ai essaye d'envoyer un mail a partir de la console :
mail -v ( 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 ?
Avec la commande 'mail' standard (paquet mailx), oui, vous avez besoin d'un wrapper '/usr/sbin/sendmail' installé par un quelconque MTA (qmail, postfix, sendmail, ...).
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. ..
Il n'est alors peut être pas utile d'installer un MTA sur votre Mandrake mais de plutôt remplacer la commande 'mail' par le MUA nail qui, comme je le dis souvent, remplacera très avanteugeusement la commande 'mail' standard.
tichou $ ls -l /bin/mail lrwxrwxrwx 1 root root 13 Nov 13 2003 /bin/mail -> /usr/bin/nail
En effet, nail offre la possibilité de définir un serveur mail distant via le fichier /etc/nail.rc en y plaçant la ligne 'set smtp=smtp.votredomaine.com'.
-- TiChou
Dans le message <news:416501db$0$11878$636a15ce@news.free.fr>,
*Magalie Sirea* tapota sur f.c.o.l.configuration :
Bonjour,
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 ?
Avec la commande 'mail' standard (paquet mailx), oui, vous avez besoin d'un
wrapper '/usr/sbin/sendmail' installé par un quelconque MTA (qmail, postfix,
sendmail, ...).
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. ..
Il n'est alors peut être pas utile d'installer un MTA sur votre Mandrake
mais de plutôt remplacer la commande 'mail' par le MUA nail qui, comme je le
dis souvent, remplacera très avanteugeusement la commande 'mail' standard.
tichou@pegase tichou $ ls -l /bin/mail
lrwxrwxrwx 1 root root 13 Nov 13 2003 /bin/mail -> /usr/bin/nail
En effet, nail offre la possibilité de définir un serveur mail distant via
le fichier /etc/nail.rc en y plaçant la ligne 'set
smtp=smtp.votredomaine.com'.
Dans le message <news:416501db$0$11878$, *Magalie Sirea* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
Une eptite question :
J'ai essaye d'envoyer un mail a partir de la console :
mail -v ( 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 ?
Avec la commande 'mail' standard (paquet mailx), oui, vous avez besoin d'un wrapper '/usr/sbin/sendmail' installé par un quelconque MTA (qmail, postfix, sendmail, ...).
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. ..
Il n'est alors peut être pas utile d'installer un MTA sur votre Mandrake mais de plutôt remplacer la commande 'mail' par le MUA nail qui, comme je le dis souvent, remplacera très avanteugeusement la commande 'mail' standard.
tichou $ ls -l /bin/mail lrwxrwxrwx 1 root root 13 Nov 13 2003 /bin/mail -> /usr/bin/nail
En effet, nail offre la possibilité de définir un serveur mail distant via le fichier /etc/nail.rc en y plaçant la ligne 'set smtp=smtp.votredomaine.com'.
-- TiChou
Christophe PEREZ
Le Thu, 07 Oct 2004 13:01:50 +0200, TiChou a écrit:
En effet, nail offre la possibilité de définir un serveur mail distant via le fichier /etc/nail.rc en y plaçant la ligne 'set smtp=smtp.votredomaine.com'.
Super ! Ou comment éviter d'installer postfix sur chaque poste d'un réseau rien que pour relayer les messages de cron ;-)
Par contre, sur la mandrake 10.0 (et les autres aussi j'imagine), impossible de désinstaller (proprement) mailx sans désinstaller at. Je prends un risque si je force ? Une mise à jour de at va un jour me réinstaller mailx et donc m'écraser le lien /bin/mail -> /usr/bin/nail non ?
-- Christophe PEREZ Écrivez moi sans _faute !
Le Thu, 07 Oct 2004 13:01:50 +0200, TiChou a écrit:
En effet, nail offre la possibilité de définir un serveur mail distant via
le fichier /etc/nail.rc en y plaçant la ligne 'set
smtp=smtp.votredomaine.com'.
Super !
Ou comment éviter d'installer postfix sur chaque poste d'un réseau rien
que pour relayer les messages de cron ;-)
Par contre, sur la mandrake 10.0 (et les autres aussi j'imagine),
impossible de désinstaller (proprement) mailx sans désinstaller at.
Je prends un risque si je force ?
Une mise à jour de at va un jour me réinstaller mailx et donc m'écraser
le lien /bin/mail -> /usr/bin/nail non ?
Le Thu, 07 Oct 2004 13:01:50 +0200, TiChou a écrit:
En effet, nail offre la possibilité de définir un serveur mail distant via le fichier /etc/nail.rc en y plaçant la ligne 'set smtp=smtp.votredomaine.com'.
Super ! Ou comment éviter d'installer postfix sur chaque poste d'un réseau rien que pour relayer les messages de cron ;-)
Par contre, sur la mandrake 10.0 (et les autres aussi j'imagine), impossible de désinstaller (proprement) mailx sans désinstaller at. Je prends un risque si je force ? Une mise à jour de at va un jour me réinstaller mailx et donc m'écraser le lien /bin/mail -> /usr/bin/nail non ?
-- Christophe PEREZ Écrivez moi sans _faute !
TiChou
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
En effet, nail offre la possibilité de définir un serveur mail distant via le fichier /etc/nail.rc en y plaçant la ligne 'set smtp=smtp.votredomaine.com'.
Super ! Ou comment éviter d'installer postfix sur chaque poste d'un réseau rien que pour relayer les messages de cron ;-)
N'est ce pas ! :-)
Par contre, sur la mandrake 10.0
Ah...
(et les autres aussi j'imagine),
Nan. ;-)
impossible de désinstaller (proprement) mailx sans désinstaller at. Je prends un risque si je force ?
Non.
Une mise à jour de at va un jour me réinstaller mailx et donc m'écraser le lien /bin/mail -> /usr/bin/nail non ?
C'est là qu'on voit toute la puissance du gestionnaire de paquet de la gentoo car c'est des questions qui ne se posent même pas...
Pour la Mandrake, il faudrait faire un paquet maison de at ou alors faire de /bin/mail un lien hard de /usr/bin/nail et rendre ce fichier immutable (chattr +i).
-- TiChou
Dans le message <news:pan.2004.10.07.18.03.49.411696@novazur.fr>,
*Christophe PEREZ* tapota sur f.c.o.l.configuration :
En effet, nail offre la possibilité de définir un serveur mail distant
via le fichier /etc/nail.rc en y plaçant la ligne
'set smtp=smtp.votredomaine.com'.
Super !
Ou comment éviter d'installer postfix sur chaque poste d'un réseau rien
que pour relayer les messages de cron ;-)
N'est ce pas ! :-)
Par contre, sur la mandrake 10.0
Ah...
(et les autres aussi j'imagine),
Nan. ;-)
impossible de désinstaller (proprement) mailx sans désinstaller at.
Je prends un risque si je force ?
Non.
Une mise à jour de at va un jour me réinstaller mailx et donc m'écraser
le lien /bin/mail -> /usr/bin/nail non ?
C'est là qu'on voit toute la puissance du gestionnaire de paquet de la
gentoo car c'est des questions qui ne se posent même pas...
Pour la Mandrake, il faudrait faire un paquet maison de at ou alors faire de
/bin/mail un lien hard de /usr/bin/nail et rendre ce fichier immutable
(chattr +i).
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
En effet, nail offre la possibilité de définir un serveur mail distant via le fichier /etc/nail.rc en y plaçant la ligne 'set smtp=smtp.votredomaine.com'.
Super ! Ou comment éviter d'installer postfix sur chaque poste d'un réseau rien que pour relayer les messages de cron ;-)
N'est ce pas ! :-)
Par contre, sur la mandrake 10.0
Ah...
(et les autres aussi j'imagine),
Nan. ;-)
impossible de désinstaller (proprement) mailx sans désinstaller at. Je prends un risque si je force ?
Non.
Une mise à jour de at va un jour me réinstaller mailx et donc m'écraser le lien /bin/mail -> /usr/bin/nail non ?
C'est là qu'on voit toute la puissance du gestionnaire de paquet de la gentoo car c'est des questions qui ne se posent même pas...
Pour la Mandrake, il faudrait faire un paquet maison de at ou alors faire de /bin/mail un lien hard de /usr/bin/nail et rendre ce fichier immutable (chattr +i).
-- TiChou
Christophe PEREZ
Le Thu, 07 Oct 2004 22:34:21 +0200, TiChou a écrit:
N'est ce pas ! :-)
Oh oui ! ;-)
Par contre, sur la mandrake 10.0
Ah...
Ouaip.
(et les autres aussi j'imagine),
Nan. ;-)
Je parlais évidemment des autres versions de mandrake.
impossible de désinstaller (proprement) mailx sans désinstaller at. Je prends un risque si je force ?
Non.
Si, quand même, celui indiqué après...
Une mise à jour de at va un jour me réinstaller mailx et donc m'écraser le lien /bin/mail -> /usr/bin/nail non ?
C'est là qu'on voit toute la puissance du gestionnaire de paquet de la gentoo car c'est des questions qui ne se posent même pas...
Oui mais bon ;-)
Pour la Mandrake, il faudrait faire un paquet maison de at
Le problème des update auto restera le même...
ou alors faire de /bin/mail un lien hard de /usr/bin/nail et rendre ce fichier immutable
jusque là, je vois un peu
(chattr +i).
mais là, comprends plus rien du tout.
-- Christophe PEREZ Écrivez moi sans _faute !
Le Thu, 07 Oct 2004 22:34:21 +0200, TiChou a écrit:
N'est ce pas ! :-)
Oh oui ! ;-)
Par contre, sur la mandrake 10.0
Ah...
Ouaip.
(et les autres aussi j'imagine),
Nan. ;-)
Je parlais évidemment des autres versions de mandrake.
impossible de désinstaller (proprement) mailx sans désinstaller at.
Je prends un risque si je force ?
Non.
Si, quand même, celui indiqué après...
Une mise à jour de at va un jour me réinstaller mailx et donc m'écraser
le lien /bin/mail -> /usr/bin/nail non ?
C'est là qu'on voit toute la puissance du gestionnaire de paquet de la
gentoo car c'est des questions qui ne se posent même pas...
Oui mais bon ;-)
Pour la Mandrake, il faudrait faire un paquet maison de at
Le problème des update auto restera le même...
ou alors faire de
/bin/mail un lien hard de /usr/bin/nail et rendre ce fichier immutable
Le Thu, 07 Oct 2004 22:34:21 +0200, TiChou a écrit:
N'est ce pas ! :-)
Oh oui ! ;-)
Par contre, sur la mandrake 10.0
Ah...
Ouaip.
(et les autres aussi j'imagine),
Nan. ;-)
Je parlais évidemment des autres versions de mandrake.
impossible de désinstaller (proprement) mailx sans désinstaller at. Je prends un risque si je force ?
Non.
Si, quand même, celui indiqué après...
Une mise à jour de at va un jour me réinstaller mailx et donc m'écraser le lien /bin/mail -> /usr/bin/nail non ?
C'est là qu'on voit toute la puissance du gestionnaire de paquet de la gentoo car c'est des questions qui ne se posent même pas...
Oui mais bon ;-)
Pour la Mandrake, il faudrait faire un paquet maison de at
Le problème des update auto restera le même...
ou alors faire de /bin/mail un lien hard de /usr/bin/nail et rendre ce fichier immutable
jusque là, je vois un peu
(chattr +i).
mais là, comprends plus rien du tout.
-- Christophe PEREZ Écrivez moi sans _faute !
TiChou
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Par contre, sur la mandrake 10.0
Ah...
Ouaip.
(et les autres aussi j'imagine),
Nan. ;-)
Je parlais évidemment des autres versions de mandrake.
Oups, désolé. :)
Pour la Mandrake, il faudrait faire un paquet maison de at
Le problème des update auto restera le même...
Oui, c'est vrai. C'est là qu'on voit toute la puissance du gestionnaire de paquet de la Gentoo parce que.... oups, je l'ai peut être déjà dit ? :)
ou alors faire de /bin/mail un lien hard de /usr/bin/nail et rendre ce fichier immutable
jusque là, je vois un peu
(chattr +i).
mais là, comprends plus rien du tout.
Hmmm. man chattr ? :-) J'oubliais de dire que cela ne fonctionne que sur un système de fichier ext2 ou ext3. Pour résumer vite fait, 'chattr +i fichier' rend le fichier immutable c'est-à-dire que le système de fichier rend impossible la suppression ou le renommage du fichier, même avec les droits du super utilisateur.
Dans le message <news:pan.2004.10.07.20.52.14.611433@novazur.fr>,
*Christophe PEREZ* tapota sur f.c.o.l.configuration :
Par contre, sur la mandrake 10.0
Ah...
Ouaip.
(et les autres aussi j'imagine),
Nan. ;-)
Je parlais évidemment des autres versions de mandrake.
Oups, désolé. :)
Pour la Mandrake, il faudrait faire un paquet maison de at
Le problème des update auto restera le même...
Oui, c'est vrai. C'est là qu'on voit toute la puissance du gestionnaire de
paquet de la Gentoo parce que.... oups, je l'ai peut être déjà dit ? :)
ou alors faire de
/bin/mail un lien hard de /usr/bin/nail et rendre ce fichier immutable
jusque là, je vois un peu
(chattr +i).
mais là, comprends plus rien du tout.
Hmmm. man chattr ? :-)
J'oubliais de dire que cela ne fonctionne que sur un système de fichier ext2
ou ext3.
Pour résumer vite fait, 'chattr +i fichier' rend le fichier immutable
c'est-à-dire que le système de fichier rend impossible la suppression ou le
renommage du fichier, même avec les droits du super utilisateur.
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Par contre, sur la mandrake 10.0
Ah...
Ouaip.
(et les autres aussi j'imagine),
Nan. ;-)
Je parlais évidemment des autres versions de mandrake.
Oups, désolé. :)
Pour la Mandrake, il faudrait faire un paquet maison de at
Le problème des update auto restera le même...
Oui, c'est vrai. C'est là qu'on voit toute la puissance du gestionnaire de paquet de la Gentoo parce que.... oups, je l'ai peut être déjà dit ? :)
ou alors faire de /bin/mail un lien hard de /usr/bin/nail et rendre ce fichier immutable
jusque là, je vois un peu
(chattr +i).
mais là, comprends plus rien du tout.
Hmmm. man chattr ? :-) J'oubliais de dire que cela ne fonctionne que sur un système de fichier ext2 ou ext3. Pour résumer vite fait, 'chattr +i fichier' rend le fichier immutable c'est-à-dire que le système de fichier rend impossible la suppression ou le renommage du fichier, même avec les droits du super utilisateur.
Le Thu, 07 Oct 2004 23:10:18 +0200, TiChou a écrit:
Oui, c'est vrai. C'est là qu'on voit toute la puissance du gestionnaire de paquet de la Gentoo parce que.... oups, je l'ai peut être déjà dit ? :)
Une seule fois ;-)
Hmmm. man chattr ? :-)
Encore fallait-il même comprendre qu'il s'agissait d'une commande :-)
J'oubliais de dire que cela ne fonctionne que sur un système de fichier ext2 ou ext3.
Ouf ;-)
Pour résumer vite fait, 'chattr +i fichier' rend le fichier immutable c'est-à-dire que le système de fichier rend impossible la suppression ou le renommage du fichier, même avec les droits du super utilisateur.
Jamais entendu parler de ça. Mais ça a l'air bien intéressant. Pourquoi n'y est-il jamais fait référence ?
$ : > fichier $ chattr +i fichier
Il faut une option particulière du noyau ? Chez moi : $ chattr +i fichier chattr: Inappropriate ioctl for device while reading flags on fichier
-- Christophe PEREZ Écrivez moi sans _faute !
Le Thu, 07 Oct 2004 23:10:18 +0200, TiChou a écrit:
Oui, c'est vrai. C'est là qu'on voit toute la puissance du gestionnaire de
paquet de la Gentoo parce que.... oups, je l'ai peut être déjà dit ? :)
Une seule fois ;-)
Hmmm. man chattr ? :-)
Encore fallait-il même comprendre qu'il s'agissait d'une commande :-)
J'oubliais de dire que cela ne fonctionne que sur un système de fichier ext2
ou ext3.
Ouf ;-)
Pour résumer vite fait, 'chattr +i fichier' rend le fichier immutable
c'est-à-dire que le système de fichier rend impossible la suppression ou le
renommage du fichier, même avec les droits du super utilisateur.
Jamais entendu parler de ça.
Mais ça a l'air bien intéressant.
Pourquoi n'y est-il jamais fait référence ?
$ : > fichier
$ chattr +i fichier
Il faut une option particulière du noyau ?
Chez moi :
$ chattr +i fichier
chattr: Inappropriate ioctl for device while reading flags on fichier
Le Thu, 07 Oct 2004 23:10:18 +0200, TiChou a écrit:
Oui, c'est vrai. C'est là qu'on voit toute la puissance du gestionnaire de paquet de la Gentoo parce que.... oups, je l'ai peut être déjà dit ? :)
Une seule fois ;-)
Hmmm. man chattr ? :-)
Encore fallait-il même comprendre qu'il s'agissait d'une commande :-)
J'oubliais de dire que cela ne fonctionne que sur un système de fichier ext2 ou ext3.
Ouf ;-)
Pour résumer vite fait, 'chattr +i fichier' rend le fichier immutable c'est-à-dire que le système de fichier rend impossible la suppression ou le renommage du fichier, même avec les droits du super utilisateur.
Jamais entendu parler de ça. Mais ça a l'air bien intéressant. Pourquoi n'y est-il jamais fait référence ?
$ : > fichier $ chattr +i fichier
Il faut une option particulière du noyau ? Chez moi : $ chattr +i fichier chattr: Inappropriate ioctl for device while reading flags on fichier
-- Christophe PEREZ Écrivez moi sans _faute !
TiChou
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Pour résumer vite fait, 'chattr +i fichier' rend le fichier immutable c'est-à-dire que le système de fichier rend impossible la suppression ou le renommage du fichier, même avec les droits du super utilisateur.
Jamais entendu parler de ça. Mais ça a l'air bien intéressant.
L'attribut 'a' est lui aussi très intéressant.
Pourquoi n'y est-il jamais fait référence ?
Va savoir...
$ : > fichier $ chattr +i fichier
Il faut une option particulière du noyau ?
Non aucune, les attributs font partie intégrante des systèmes de fichiers ext2 et ext3.
Chez moi : $ chattr +i fichier chattr: Inappropriate ioctl for device while reading flags on fichier
Es-tu sûr que ton système de fichier est bien en ext2/ext3 ? Quelle version de noyau ?
-- TiChou
Dans le message <news:pan.2004.10.07.21.49.30.562059@novazur.fr>,
*Christophe PEREZ* tapota sur f.c.o.l.configuration :
Pour résumer vite fait, 'chattr +i fichier' rend le fichier immutable
c'est-à-dire que le système de fichier rend impossible la suppression ou
le renommage du fichier, même avec les droits du super utilisateur.
Jamais entendu parler de ça.
Mais ça a l'air bien intéressant.
L'attribut 'a' est lui aussi très intéressant.
Pourquoi n'y est-il jamais fait référence ?
Va savoir...
$ : > fichier
$ chattr +i fichier
Il faut une option particulière du noyau ?
Non aucune, les attributs font partie intégrante des systèmes de fichiers
ext2 et ext3.
Chez moi :
$ chattr +i fichier
chattr: Inappropriate ioctl for device while reading flags on fichier
Es-tu sûr que ton système de fichier est bien en ext2/ext3 ? Quelle version
de noyau ?
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Pour résumer vite fait, 'chattr +i fichier' rend le fichier immutable c'est-à-dire que le système de fichier rend impossible la suppression ou le renommage du fichier, même avec les droits du super utilisateur.
Jamais entendu parler de ça. Mais ça a l'air bien intéressant.
L'attribut 'a' est lui aussi très intéressant.
Pourquoi n'y est-il jamais fait référence ?
Va savoir...
$ : > fichier $ chattr +i fichier
Il faut une option particulière du noyau ?
Non aucune, les attributs font partie intégrante des systèmes de fichiers ext2 et ext3.
Chez moi : $ chattr +i fichier chattr: Inappropriate ioctl for device while reading flags on fichier
Es-tu sûr que ton système de fichier est bien en ext2/ext3 ? Quelle version de noyau ?
-- TiChou
Christophe PEREZ
Le Fri, 08 Oct 2004 00:41:18 +0200, TiChou a écrit:
L'attribut 'a' est lui aussi très intéressant.
Effectivement. Ceci dit on ne peut pas dire que le man soit d'une structure des plus pratique/lisible ;-)
Pourquoi n'y est-il jamais fait référence ?
Va savoir...
Je vais chercher :-)
Il faut une option particulière du noyau ?
Non aucune, les attributs font partie intégrante des systèmes de fichiers ext2 et ext3.
Ah...
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. 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 $ su Password: # chattr +i fichier # lsattr fichier ----i-------- fichier # exit $ lsattr fichier ----i-------- fichier
Ça doit être une question de droits. Pourtant : $ pwd /sauve_loc $ ls -ld /sauve_loc/ drwxrwxr-x 4 root users 4096 oct 7 23:12 /sauve_loc// $ groups users lp mail uucp games usb audio majaudio wine video
donc, je fais bien partie du groupe users, et les droits sont rwx sur /sauve_loc. Que faut-il donc de plus ?
Quelle version de noyau ?
2.6.8.1 compilé main ! ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Le Fri, 08 Oct 2004 00:41:18 +0200, TiChou a écrit:
L'attribut 'a' est lui aussi très intéressant.
Effectivement.
Ceci dit on ne peut pas dire que le man soit d'une structure des plus
pratique/lisible ;-)
Pourquoi n'y est-il jamais fait référence ?
Va savoir...
Je vais chercher :-)
Il faut une option particulière du noyau ?
Non aucune, les attributs font partie intégrante des systèmes de fichiers
ext2 et ext3.
Ah...
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.
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
$ su
Password:
# chattr +i fichier
# lsattr fichier
----i-------- fichier
# exit
$ lsattr fichier
----i-------- fichier
Ça doit être une question de droits.
Pourtant :
$ pwd
/sauve_loc
$ ls -ld /sauve_loc/
drwxrwxr-x 4 root users 4096 oct 7 23:12 /sauve_loc//
$ groups
users lp mail uucp games usb audio majaudio wine video
donc, je fais bien partie du groupe users, et les droits sont rwx sur
/sauve_loc.
Que faut-il donc de plus ?
Le Fri, 08 Oct 2004 00:41:18 +0200, TiChou a écrit:
L'attribut 'a' est lui aussi très intéressant.
Effectivement. Ceci dit on ne peut pas dire que le man soit d'une structure des plus pratique/lisible ;-)
Pourquoi n'y est-il jamais fait référence ?
Va savoir...
Je vais chercher :-)
Il faut une option particulière du noyau ?
Non aucune, les attributs font partie intégrante des systèmes de fichiers ext2 et ext3.
Ah...
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. 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 $ su Password: # chattr +i fichier # lsattr fichier ----i-------- fichier # exit $ lsattr fichier ----i-------- fichier
Ça doit être une question de droits. Pourtant : $ pwd /sauve_loc $ ls -ld /sauve_loc/ drwxrwxr-x 4 root users 4096 oct 7 23:12 /sauve_loc// $ groups users lp mail uucp games usb audio majaudio wine video
donc, je fais bien partie du groupe users, et les droits sont rwx sur /sauve_loc. Que faut-il donc de plus ?
Quelle version de noyau ?
2.6.8.1 compilé main ! ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
g.patel
On Thu, 07 Oct 2004 14:03:49 -0400, Christophe PEREZ wrote:
(...)
Par contre, sur la mandrake 10.0 (et les autres aussi j'imagine), impossible de désinstaller (proprement) mailx sans désinstaller at.
sur la Cooker :
[ gerard]# urpme mailx
désinstallation de mailx-8.1.1-24mdk.i586 [ gerard]# rpm -qa at at-3.1.8-11mdk
Il y a peut-etre une erreur de dépendances sur la 10.0; que dit 'rpm --q --requires at' ? sur la cooker, il n'y a aucune dépendance sur un programme de messagerie.
Gerard Patel
On Thu, 07 Oct 2004 14:03:49 -0400, Christophe PEREZ
<christophe.perez_faute@novazur.com> wrote:
(...)
Par contre, sur la mandrake 10.0 (et les autres aussi j'imagine),
impossible de désinstaller (proprement) mailx sans désinstaller at.
sur la Cooker :
[root@duron gerard]# urpme mailx
désinstallation de mailx-8.1.1-24mdk.i586
[root@duron gerard]# rpm -qa at
at-3.1.8-11mdk
Il y a peut-etre une erreur de dépendances sur la 10.0;
que dit 'rpm --q --requires at' ? sur la cooker, il n'y a aucune
dépendance sur un programme de messagerie.
On Thu, 07 Oct 2004 14:03:49 -0400, Christophe PEREZ wrote:
(...)
Par contre, sur la mandrake 10.0 (et les autres aussi j'imagine), impossible de désinstaller (proprement) mailx sans désinstaller at.
sur la Cooker :
[ gerard]# urpme mailx
désinstallation de mailx-8.1.1-24mdk.i586 [ gerard]# rpm -qa at at-3.1.8-11mdk
Il y a peut-etre une erreur de dépendances sur la 10.0; que dit 'rpm --q --requires at' ? sur la cooker, il n'y a aucune dépendance sur un programme de messagerie.
