OVH Cloud OVH Cloud

Problème de registre avec mod_perl

13 réponses
Avatar
Raphaël 'SurcouF' Bordet
Bonjour,

Depuis aujourd'hui, je constate que l'usage de mod_perl s'est trouvé
modifié sur un serveur web dont j'ai la charge (en cours d'intégration,
quoi): en effet, j'ai ce persistent message d'erreur dans les logs:

[Thu Oct 07 10:55:45 2004] [error] [client 192.168.0.8] Re-register of
content_disposition at
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/Reload.pm
line 144!Compilation failed in require at
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/Reload.pm
line 144.!

La seule référence que Google m'a trouvé se réfère à la date du système,
hors il se trouve que celle-ci a changé dans la semaine (le BIOS se
croyait en 2006 et l'installateur de la RedHat avait suivi...).
Est-ce que cela a-t-il en effet un rapport de cause à effets ?
J'ai beau avoir joué du find /usr/lib/perl5 -type f -exec touch {} \;,
ça n'a rien donné de concluant...

Une idée ?

--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net

3 réponses

1 2
Avatar
Patrick Mevzek
[Fri Oct 08 12:54:28 2004] [error] 459: ModPerl::Registry: /otrs not
found or unable to stat




|..]

Bien que tout appartienne à root, n'importe qui peut les lire et les
exécuter et, donc, à fortieri, apache le peut égalemment.


D'après le code source:
unless (-r $r->my_finfo && -s _) {
$self->log_error("$self->[FILENAME] not found or unable to stat");
return Apache::NOT_FOUND;
}

Le problème semble donc en fait ailleurs: pour une raison X le /otrs du
web n'est pas transcrit en chemin physique, et donc ModPerl ne cherche
pas au bon endroit.

Essayez la même URL mais avec un / à la fin (vu qu'il y a un / à la fin
dans ScriptAlias, mais pas dans le message d'erreur) :
http://www.example.com/otrs/
^

Si c'est ca le problème, alors votre ServerName n'est pas bon.
Vous pouvez aussi corriger en enlevant les slashs finaux dans
ScriptAlias/Alias (des deux côtés).

BTW, je pense qu'on est plus dans un problème de configuration Apache que
(mod)perl là, je vous laisse soin de rediriger.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>



Avatar
Raphaël 'SurcouF' Bordet
Patrick Mevzek wrote:

[Fri Oct 08 12:54:28 2004] [error] 459: ModPerl::Registry: /otrs not
found or unable to stat





|..]


Bien que tout appartienne à root, n'importe qui peut les lire et les
exécuter et, donc, à fortieri, apache le peut égalemment.



D'après le code source:
unless (-r $r->my_finfo && -s _) {
$self->log_error("$self->[FILENAME] not found or unable to stat");
return Apache::NOT_FOUND;
}

Le problème semble donc en fait ailleurs: pour une raison X le /otrs du
web n'est pas transcrit en chemin physique, et donc ModPerl ne cherche
pas au bon endroit.


Voici la partie de configuration exacte:

<VirtualHost otrs.demat.sopragroup.fra>
ServerAdmin
DocumentRoot /
ServerNAme otrs.demat.sopragroup.fra
ErrorLog /var/log/httpd/otrs.demat.sopragroup.fra-error.log
CustomLog
/var/log/httpd/otrs.demat.sopragroup.fra-access.log common

# agent, admin and customer frontend
ScriptAlias /otrs "/opt/otrs/bin/cgi-bin"
Alias /otrs-web "/opt/otrs/var/httpd/htdocs/"

# load all otrs modules
Perlrequire /opt/otrs/scripts/apache2-perl-startup.pl

# Apache::Reload - Reload Perl Modules when Changed on Disk
PerlModule Apache::Reload
PerlInitHandler Apache::Reload
#ReloadDebug on

# set mod_perl2 options
<Location /otrs>
ErrorDocument 403 /otrs/index.pl
SetHandler perl-script
PerlHandler ModPerl::Registry
Options +ExecCGI
PerlOptions +ParseHeaders
</Location>
</VirtualHost>

Essayez la même URL mais avec un / à la fin (vu qu'il y a un / à la fin
dans ScriptAlias, mais pas dans le message d'erreur) :
http://www.example.com/otrs/


Le problème survient que j'ajoute ou pas un slash final.

Si c'est ca le problème, alors votre ServerName n'est pas bon.
Vous pouvez aussi corriger en enlevant les slashs finaux dans
ScriptAlias/Alias (des deux côtés).


Evidemment, cela ne change rien au problème...

BTW, je pense qu'on est plus dans un problème de configuration Apache que
(mod)perl là, je vous laisse soin de rediriger.


Pour l'instant, je ne sais pas encore si ça vient de mod_perl ou d'apache...

--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net




Avatar
Raphaël 'SurcouF' Bordet
Raphaël 'SurcouF' Bordet wrote:
Bonjour,

Depuis aujourd'hui, je constate que l'usage de mod_perl s'est trouvé
modifié sur un serveur web dont j'ai la charge (en cours d'intégration,
quoi): en effet, j'ai ce persistent message d'erreur dans les logs:

[Thu Oct 07 10:55:45 2004] [error] [client 192.168.0.8] Re-register of
content_disposition at
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/Reload.pm
line 144!Compilation failed in require at
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/Reload.pm
line 144.!

La seule référence que Google m'a trouvé se réfère à la date du système,
hors il se trouve que celle-ci a changé dans la semaine (le BIOS se
croyait en 2006 et l'installateur de la RedHat avait suivi...).
Est-ce que cela a-t-il en effet un rapport de cause à effets ?
J'ai beau avoir joué du find /usr/lib/perl5 -type f -exec touch {} ;,
ça n'a rien donné de concluant...


Bien, finalement, on a décidé de se passer de mod_perl, l'application
fonctionne égalemment sans et pour l'usage qu'on projette d'en faire les
améliorations de performances qu'apporteraient mod_perl ne sont ,
finalement, pas primordiales.

Merci à toi, Paul ;-)

--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net

1 2