Hello,
J'ai un problème bizarre (pour moi en tout cas).
Voila un script perl minimaliste, qui tourne sous apache 1.3:
#!/usr/bin/perl
print "Content-type: text/html\n\n";
require LWP::UserAgent;
my $ua = LWP::UserAgent->new;
my $response = $ua->get("http://google.com");
if ($response->is_success) {
print $response->content; # or whatever
}
else {
print $response->status_line;
}
(désolé pour les - > je ne vois pas comment les afficher dans le code...)
Il se connecte juste à google et affiche la page, sans subtilité aucune.
Ça marche très bien en ligne de commande, mais pas dans apache. J'obtiens l'erreur suivante:
500 Can't connect to google.com:80 (Bad hostname 'google.com').
Je n'ai rien trouvé qui s'apparente à ça sur le web (si ce n'est 2 messages proches de mon problème de la même personne, il y a un bout de temps et sans solution.). Apache est bien configuré (en théorie), en tout cas les autres CGI tournent très bien.
Si quelqu'un a une piste, je lui en serait très reconnaissant.
# www.google.fr
Posté par NeoX . Évalué à 1.
sinon le code erreur 500 c'est qu'il y a une erreur dans la page (du point de vue du serveur)
http://www.lbb.org/fr/services/erreur.php
[^] # Re: www.google.fr
Posté par lom (site web personnel) . Évalué à 1.
Ce qui est étrange, c'est que ça marche parfaitment si je n'exécute pas ce script en tant que CGI sous apache.
C'est probablement une question de variable d'environnement, mais je n'ai pas encore trouvé laquelle...
[^] # Re: www.google.fr
Posté par benja . Évalué à 2.
$ grep "Can't con" -n http.pm
47: die "Can't connect to $host:$port ($@)";
Apparemment le problème viendrait de IO::Socket::INET mais bon je n'ai pas poussé l'investigation plus loin (perl c'est crade). Peut-être faut-il chercher du côté des variables d'environement, une sortie de celles-ci pourrait peut-être réveler une anomalie.
[^] # Re: www.google.fr
Posté par benja . Évalué à 4.
[^] # Re: www.google.fr
Posté par lom (site web personnel) . Évalué à 1.
# Log
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 1.
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: Log
Posté par lom (site web personnel) . Évalué à 1.
Il n'y a pas de message de Perl, parce de son point de vue il n'y a rien: juste la connexion qui échoue, et je récupère moi même cette erreur (response->is_succes).
Mais c'était bien essayé...
# chezmoiçamarche.org
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
Regarde du côté de la conf d'apache.
Par exemple en faisant un cgi avec nslookup, tu peux savoir si il a accès au dns :
Par ailleurs quels sont les droits sur tes cgi :
Enfin (au passage) si tu débute en perl, sache qu'il est important d'utiliser strict dans les scripts. Cela évite bien des erreurs. Il est également préferable d'utiliser use plutôt que require.
[^] # Re: chezmoiçamarche.org
Posté par lom (site web personnel) . Évalué à 1.
ns.cgi marche très bien en ligne de commande, mais voila les logs apache:
net.c:70: socket() failed: Permission denied
net.c:70: socket() failed: Permission denied
(null): can't find either v4 or v6 networking
Premature end of script headers: ns.cgi
En tout cas, ça me donne une piste, merci.
Cheztoicamarche.org avec apache 1.3 ou 2.x?
Sinon merci pour les infos perl... Je ne suis pas un débutant, mais mon boulot actuel est de modifier un ensemble de scripts qui me brûlent les yeux rien qu'à les regarder... Je ne suis même pas sur de mettre ça sur mon CV, tellement j'aurai honte qu'un employeur potentiel regarde de près...
# Précisions
Posté par lom (site web personnel) . Évalué à 1.
le serveur est sous fedora 4, avec apache 2.0.54
Tout va bien sur ma propre machine (debian testing apache 2.2.3)
Il n'y a pas de différences entre les variables d'environement.
Si j'essaye seulement d'ouvrir un socket vers une addresse IP ça plante lors de l'appel 'socket' (permission denied).
SI j'essaye d'ouvrir un socket vers un nom, ça plante lors de l'appel 'inet_aton': no host.
youpi tagada...
[^] # Re: Précisions
Posté par benja . Évalué à 3.
[^] # Re: Précisions
Posté par lom (site web personnel) . Évalué à 1.
Bingo, tu as tout bon.
un 'simple'
setsebool -P httpd_can_network_connect 1
a résolu le problème. Il faut maintenant que je creuse un peu pour voir si je n'ai pas fait de bêtises ou pour voir si je ne peux pas mieux faire...
A ton avis, SELinux pourrait il être aussi la raison pour laquelle apache n'arrive pas à exécuter le script pointé par SSLPassphraseDialog? Il va falloir que je creuse, mais tu m'as donné un très bonne piste.
Merci encore.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.