vendredi 08 août
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Retourner aux forums || Retourner au forum Programmation.perl

Programmation.perl : LWP: Comportement différent CGI/ligne de commande

Posté par lom (page perso, ) le 06 mars 2007

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.

> Lire le message (12 commentaires, moyenne: 1,8).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

www.google.fr

Posté par NeoX () le 06/03/2007 à 15:17. (lien). Évalué à 1.

tu as essayé en mettant www.google.fr au lieu de simplement google.fr (ou .com d'ailleurs)

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

--
Apprendre par les autres, c'est bien.
Apprendre par soi-meme (RTFM, man, et notre ami google) c'est mieux

  • [^]Re: www.google.fr

    Posté par lom (page perso, ) le 06/03/2007 à 15:26. (lien). Évalué à 1.

    J'avais essayé avec d'autres adresses, et j'ai la même erreur pour toutes, inclus avec www.

    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 () le 07/03/2007 à 06:27. (lien). Évalué à 2.

    En l'occurence, c'est LWP qui génère cette erreure. D'ailleurs comment ferait le serveur pour nous renvoyer un code d'erreure si l'on ne peut pas s'y connecter...

    $ 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 () le 07/03/2007 à 06:34. (lien). Évalué à 4.

      Une autre idée en passant: est-ce que cela fonctionne si tu spécifie directement l'adresse ip dans l'url ? Si oui alors tu n'as qu'à faire la résolution toi-même et reconstruire l'url ensuite.

      • [^]Re: www.google.fr

        Posté par lom (page perso, ) le 07/03/2007 à 09:54. (lien). Évalué à 1.

        Bonne idée le coup de l'adresse ip, mais malheureusement ce n'est pas ça. J'ai exactement la même erreur...

Log

Posté par Lol Zimmerli (Jabber id, page perso, ) le 06/03/2007 à 15:32. (lien). Évalué à 1.

Et si tu regardes du côté du log d'erreur d'apache? Oh, un message d'erreur de perl!

--
En fait, Bernardo n'était pas muet; c'est Zorro qui était sourd.

  • [^]Re: Log

    Posté par lom (page perso, ) le 06/03/2007 à 16:36. (lien). Évalué à 1.

    Effectivement, j'avais oublié de le préciser: rien dans les logs.

    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 d-jo (page perso, ) le 07/03/2007 à 08:54. (lien). Évalué à 4.

Chez moi ça marche.
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 :


utilisateur@bureau:~$ cat /usr/lib/cgi-bin/ns.cgi
#!/bin/bash
nslookup google.fr


Par ailleurs quels sont les droits sur tes cgi :

utilisateur@bureau:~$ ls -l /usr/lib/cgi-bin/
total 8
-rwxr-xr-x 1 www-data www-data 283 2007-03-07 09:30 lwp.pl
-rwxr-xr-x 1 www-data www-data 31 2007-03-07 09:36 ns.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 (page perso, ) le 07/03/2007 à 10:00. (lien). Évalué à 1.

    Hum, piste intéressante...

    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 (page perso, ) le 07/03/2007 à 11:34. (lien). Évalué à 1.

Quelques précisions:

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 () le 07/03/2007 à 11:36. (lien). Évalué à 3.

    Ne serait-ce pas en relation avec SELinux par hasard ?

    • [^]Re: Précisions

      Posté par lom (page perso, ) le 07/03/2007 à 12:19. (lien). Évalué à 1.

      Dans mes bras mon ami, mon frère, lumière de ma vie!

      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.

Revenir en haut de page || Retourner aux forums || Retourner au forum Programmation.perl

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0679s (dont 0.0065 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.