Ayant besoin d'alimenter une partie de mon inn par le biais de suck,
je me retrouve confronté à un problème de droits qui commence à me
gaver sérieusement. L'alimentation du serveur se passe à merveille,
mais lorsqu'il s'agit de faire partir les messages du serveur vers
celui qui est sucké, ça coince au niveau du script Perl qui me retourne
un magnifique : "SERVER cant exec in /usr/local/etc/suck/poster.pl
Permission denied".
A première vue c'est Perl qui n'aime pas le compte news, ou l'inverse,
vue qu'un "su -fm news -c 'perl test.pl'" me retourne le même problème
de droit, alors que pourtant ce n'est pas le script qui risque de poser
des problèmes...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Stephane Catteau
Xavier devait dire quelque chose comme ceci :
[ xavier]$ which perl /usr/bin/perl
Et zut, faux espoir, c'est en écrivant le message que j'ai planté, c'est bien /usr/bin/perl qui est indiqué dans le script. Par contre ça m'a donné une autre idée d'erreur à la con. J'étais tellement obnubilé par le fait que le script ne marchait pas, que je n'avais pas pensé à regarder tout simplement quelles était les droits du dossier dans lequel il se trouvait. Avec un dossier suck en 700 et appartenant à root, ça ne risquait pas de le faire :-( Problème réglé, désolé du dérangement.
Xavier devait dire quelque chose comme ceci :
[xavier@valinor xavier]$ which perl
/usr/bin/perl
Et zut, faux espoir, c'est en écrivant le message que j'ai planté,
c'est bien /usr/bin/perl qui est indiqué dans le script. Par contre ça
m'a donné une autre idée d'erreur à la con. J'étais tellement obnubilé
par le fait que le script ne marchait pas, que je n'avais pas pensé à
regarder tout simplement quelles était les droits du dossier dans
lequel il se trouvait. Avec un dossier suck en 700 et appartenant à
root, ça ne risquait pas de le faire :-(
Problème réglé, désolé du dérangement.
Et zut, faux espoir, c'est en écrivant le message que j'ai planté, c'est bien /usr/bin/perl qui est indiqué dans le script. Par contre ça m'a donné une autre idée d'erreur à la con. J'étais tellement obnubilé par le fait que le script ne marchait pas, que je n'avais pas pensé à regarder tout simplement quelles était les droits du dossier dans lequel il se trouvait. Avec un dossier suck en 700 et appartenant à root, ça ne risquait pas de le faire :-( Problème réglé, désolé du dérangement.
talon
Stephane Catteau wrote:
Essaye newsx, ça marche tout seul, et il n'y a pas de perl.
--
Michel TALON
Stephane Catteau <steph.nospam@sc4x.net> wrote:
Essaye newsx, ça marche tout seul, et il n'y a pas de perl.
Essaye newsx, ça marche tout seul, et il n'y a pas de perl.
--
Michel TALON
Stephane Catteau
Michel Talon n'était pas loin de dire :
Essaye newsx, ça marche tout seul, et il n'y a pas de perl.
Et à première vue pas non plus de possibilité de modification des en-têtes, que ce soit d'une manière globale ou lorsqu'ils contiennent quelque chose de précis. Ce qui le disqualifie dans mon cas.
Pis ça marche très bien suck+inn+Perl, il faut juste ne pas oublier de gérer les droits correctement ;-)
Michel Talon n'était pas loin de dire :
Essaye newsx, ça marche tout seul, et il n'y a pas de perl.
Et à première vue pas non plus de possibilité de modification des
en-têtes, que ce soit d'une manière globale ou lorsqu'ils contiennent
quelque chose de précis. Ce qui le disqualifie dans mon cas.
Pis ça marche très bien suck+inn+Perl, il faut juste ne pas oublier de
gérer les droits correctement ;-)
Essaye newsx, ça marche tout seul, et il n'y a pas de perl.
Et à première vue pas non plus de possibilité de modification des en-têtes, que ce soit d'une manière globale ou lorsqu'ils contiennent quelque chose de précis. Ce qui le disqualifie dans mon cas.
Pis ça marche très bien suck+inn+Perl, il faut juste ne pas oublier de gérer les droits correctement ;-)
