Discussion:
Maintenance de mod_perl de Apache
(trop ancien pour répondre)
Francois Lafont
2014-11-10 15:00:50 UTC
Permalink
Bonjour à tous,

J'ai lu sur IRC que le module "mod_perl" de Apache ne serait plus maintenu
car pas de mainteneur disponible pour ce travail.
Est-ce vrai ? Avez des infos (fiables) sur la question ?

Évidemment, je trouverais ça fort dommage...
Merci d'avance.
--
François Lafont
Jean-Louis Morel
2014-11-13 17:40:49 UTC
Permalink
Post by Francois Lafont
Bonjour à tous,
J'ai lu sur IRC que le module "mod_perl" de Apache ne serait plus maintenu
car pas de mainteneur disponible pour ce travail.
Est-ce vrai ? Avez des infos (fiables) sur la question ?
Évidemment, je trouverais ça fort dommage...
Merci d'avance.
Bonjour,

Non mod_perl n'est pas mort, il bouge encore :

http://svn.apache.org/viewvc/perl/modperl/

Il est vrai que la dernière version 2.0.8 est vieille de 18 mois.
Steve Hay tient absolument à intégrer l'API d'Apache 2.4 dans la version
2.0.9
et ça prend du temps :


http://mail-archives.apache.org/mod_mbox/perl-modperl/201406.mbox/%3CCADED%3DK4ZtRgofAYqVHse1pnA_mJXfEVuo%2B7%2Bux6s-V%2BXJGC0WQ%40mail.gmail.com%3E

On aura peut-être mod_perl 2.0.9 pour Noël !

HTH
--
JLM
http://www.bribes.org/perl
Francois Lafont
2014-11-13 21:39:17 UTC
Permalink
Bonjour,
Post by Jean-Louis Morel
http://svn.apache.org/viewvc/perl/modperl/
Il est vrai que la dernière version 2.0.8 est vieille de 18 mois.
Ok, cool, je vois un commit qui date d'il y a 2 jours.
Post by Jean-Louis Morel
Steve Hay tient absolument à intégrer l'API d'Apache 2.4 dans la version 2.0.9
http://mail-archives.apache.org/mod_mbox/perl-modperl/201406.mbox/%3CCADED%3DK4ZtRgofAYqVHse1pnA_mJXfEVuo%2B7%2Bux6s-V%2BXJGC0WQ%40mail.gmail.com%3E
On aura peut-être mod_perl 2.0.9 pour Noël !
HTH
Merci Jean-Louis pour cette réponse. Me voilà rassuré. ;)
--
François Lafont
Marc Espie
2014-11-14 16:57:22 UTC
Permalink
Post by Jean-Louis Morel
Bonjour,
Post by Jean-Louis Morel
http://svn.apache.org/viewvc/perl/modperl/
Il est vrai que la derniÚre version 2.0.8 est vieille de 18 mois.
En terme de securite, migrer vers quelque chose qui n'integre pas mod_perl
dans apache est une bonne idee (ne serait-ce que parce que c'est deux enormes
base de code, et qu'un pepin dans l'un ne devrait pas pouvoir directement
trasher l'autre).

Le fait que "ca bouge encore, mais beaucoup" veut aussi dire qu'il y aura
tres peu de reactivite concernant de nouvelles failles...

Il y a des tonnes d'alternatives ces jours-ci, a base de fcgi ou autres.

Voir par exemple la doc de perl Dancer pour toutes les facons de faire
tourner une appli dancer.
Francois Lafont
2014-11-15 01:35:52 UTC
Permalink
Bonsoir,
Post by Marc Espie
En terme de securite, migrer vers quelque chose qui n'integre pas mod_perl
dans apache est une bonne idee (ne serait-ce que parce que c'est deux enormes
base de code, et qu'un pepin dans l'un ne devrait pas pouvoir directement
trasher l'autre).
Pas sûr d'avoir compris le sens de cette phrase.
Post by Marc Espie
Le fait que "ca bouge encore, mais beaucoup" veut aussi dire qu'il y aura
tres peu de reactivite concernant de nouvelles failles...
Ah. Je vois pas trop non plus là (le lien logique "ça bouge encore" => "il y
aura très peu de réactivité concernant les failles" m'échappe un peu). Ça
serait pas plutôt « ça bouge encore, mais *pas* beaucoup » ? (auquel cas alors
je comprends ;)).
Post by Marc Espie
Il y a des tonnes d'alternatives ces jours-ci, a base de fcgi ou autres.
Voir par exemple la doc de perl Dancer pour toutes les facons de faire
tourner une appli dancer.
Perso, ce que je trouve intéressant avec mod_perl, c'est le Perl directement
embarqué dans apache (pas de cgi ou de fastcgi) et donc pas de fork et donc
des perfs très élevées.
--
François Lafont
Paul Gaborit
2014-11-15 02:34:17 UTC
Permalink
À (at) Sat, 15 Nov 2014 02:35:52 +0100,
Post by Francois Lafont
Post by Marc Espie
Il y a des tonnes d'alternatives ces jours-ci, a base de fcgi ou autres.
Voir par exemple la doc de perl Dancer pour toutes les facons de
faire tourner une appli dancer.
Perso, ce que je trouve intéressant avec mod_perl, c'est le Perl directement
embarqué dans apache (pas de cgi ou de fastcgi) et donc pas de fork et donc
des perfs très élevées.
FastCGI n'implique pas de fork si ce n'est celui qui crée le processus
initial qui traitera ensuite toutes les requêtes tranmises par le
serveur Web. C'est bien plus simple à mettre en œuvre que mod_perl et ça
s'adapte à plein de serveurs HTTP (pas que Apache). De plus, FastCGI
permet d'héberger plusieurs applications derrière un même serveur Web
sans interaction entre leur code respectif. Autre avantage pour les
performances : on peut hébegrer le processus FastCGI sur une machine
différente du serveur Web.

Le seul avantage de mod_perl par rapport à FCGI, c'est de pouvoir
interagir directement sur le comportement interne d'Apache. Si vous êtes
sûr d'être dans ce cas alors mod_perl s'impose. Sinon, FastCGI est un
bien meilleur choix !

Cerise sur le gateau : FastCGI fonctionne très bien avec Apache 2.4 !
;-)

PS: le seul problème que j'ai rencontré avec l'implémentation actuelle
de FastCGI pour Perl (via Plack et Dancer) est justement l'impossibilité
de forker un processus externe depuis une application FastCGI sans
casser la connexion avec le serveur Web. Pour ceux que ça intéresse,
j'ai un patch qui corrige cela. Je l'ai proposé aux développeurs mais il
a été refusé sans réelles justifications et, à ma connaissance, le bug
est toujours là.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
Francois Lafont
2014-11-15 04:00:50 UTC
Permalink
Post by Paul Gaborit
FastCGI n'implique pas de fork si ce n'est celui qui crée le processus
initial qui traitera ensuite toutes les requêtes tranmises par le
serveur Web. C'est bien plus simple à mettre en œuvre que mod_perl et ça
s'adapte à plein de serveurs HTTP (pas que Apache). De plus, FastCGI
permet d'héberger plusieurs applications derrière un même serveur Web
sans interaction entre leur code respectif. Autre avantage pour les
performances : on peut hébegrer le processus FastCGI sur une machine
différente du serveur Web.
Le seul avantage de mod_perl par rapport à FCGI, c'est de pouvoir
interagir directement sur le comportement interne d'Apache. Si vous êtes
sûr d'être dans ce cas alors mod_perl s'impose.
En l'occurrence je ne suis pas dans ce cas là.
Post by Paul Gaborit
Sinon, FastCGI est un bien meilleur choix !
Mais par exemple avec le mod_perl embarqué dans apache et avec le
paramètre "Apache::Registry" au niveau de apache, les scripts perl
sont compilés puis mis en cache mémoire ce qui entraîne un gain de
rapidité assez important au niveau de l'exécution des scripts perl.
Peut-on avoir cette fonctionnalité également avec du FastCGI ?
--
François Lafont
Paul Gaborit
2014-11-15 09:36:03 UTC
Permalink
À (at) Sat, 15 Nov 2014 05:00:50 +0100,
Post by Francois Lafont
Mais par exemple avec le mod_perl embarqué dans apache et avec le
paramètre "Apache::Registry" au niveau de apache, les scripts perl
sont compilés puis mis en cache mémoire ce qui entraîne un gain de
rapidité assez important au niveau de l'exécution des scripts perl.
Peut-on avoir cette fonctionnalité également avec du FastCGI ?
C'est la fonctionnalité principale de FastCGI : le programme (script)
est chargé en mémoire et initialisé (pour se connecter à une base de
données par exemple) puis il se met en attente des requêtes qui lui
parviendront par le canal de communication *permanent* qui est établi
avec le serveur Web (les communications sur ce canal utilisent le
protocole FastCGI).

Lorsque le serveur Web reçoit une requête concernant cette application,
elle est transmise à l'application qui se réveille, la traite, transmet
le résultat au serveur puis se redort.

Il n'y a donc aucun temps de création de processus, de compilation ou
d'établissement d'un canal de communication lors du traitement d'une
requête.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
Francois Lafont
2014-11-15 12:57:13 UTC
Permalink
Bonjour,
Post by Paul Gaborit
C'est la fonctionnalité principale de FastCGI : le programme (script)
est chargé en mémoire et initialisé (pour se connecter à une base de
données par exemple) puis il se met en attente des requêtes qui lui
parviendront par le canal de communication *permanent* qui est établi
avec le serveur Web (les communications sur ce canal utilisent le
protocole FastCGI).
Lorsque le serveur Web reçoit une requête concernant cette application,
elle est transmise à l'application qui se réveille, la traite, transmet
le résultat au serveur puis se redort.
Il n'y a donc aucun temps de création de processus, de compilation ou
d'établissement d'un canal de communication lors du traitement d'une
requête.
Ok, merci pour ces explications. Effectivement, il semblerait que j'ai
tout intérêt à utiliser FastCGI plutôt que mod_perl dans ce cas.

Merci encore.
--
François Lafont
Francois Lafont
2014-11-15 13:11:58 UTC
Permalink
Post by Paul Gaborit
C'est la fonctionnalité principale de FastCGI : le programme (script)
est chargé en mémoire et initialisé (pour se connecter à une base de
données par exemple) puis il se met en attente des requêtes qui lui
parviendront par le canal de communication *permanent* qui est établi
avec le serveur Web (les communications sur ce canal utilisent le
protocole FastCGI).
Avec mod_perl et "Apache::Registry", comme le script perl est compilé
et mis en cache, à chaque modification du code du script perl je dois
redémarrer le service apache pour qu'une compilation et une mise en cache
de la nouvelle version du script soit effectuée (sinon après la modification
du fichier .pl, apache lance toujours l'ancienne version du script).

Est-ce qu'il en est de même avec FastCGI du coup (étant donné qu'avec cette
techno le script est également compilé et mis en cache) ?
--
François Lafont
Paul Gaborit
2014-11-15 23:48:46 UTC
Permalink
À (at) Sat, 15 Nov 2014 14:11:58 +0100,
Post by Francois Lafont
Avec mod_perl et "Apache::Registry", comme le script perl est compilé
et mis en cache, à chaque modification du code du script perl je dois
redémarrer le service apache pour qu'une compilation et une mise en cache
de la nouvelle version du script soit effectuée (sinon après la modification
du fichier .pl, apache lance toujours l'ancienne version du script).
Certes.
Post by Francois Lafont
Est-ce qu'il en est de même avec FastCGI du coup (étant donné qu'avec cette
techno le script est également compilé et mis en cache) ?
Nul besoin de redémarrer Apache. Il suffit de tuer le processus FastCGI.
Apache le détecte et en relance un autre qui utilisera alors la nouvelle
version du code.

Dans certaines configurations (si le processus est sur une autre machine
ou s'il tourne sous une autre identité), ce n'est plus aussi simple mais
le principe reste le même.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
Francois Lafont
2014-11-16 12:55:25 UTC
Permalink
Bonjour,
Post by Paul Gaborit
Post by Francois Lafont
Est-ce qu'il en est de même avec FastCGI du coup (étant donné qu'avec cette
techno le script est également compilé et mis en cache) ?
Nul besoin de redémarrer Apache. Il suffit de tuer le processus FastCGI.
Apache le détecte et en relance un autre qui utilisera alors la nouvelle
version du code.
Dans certaines configurations (si le processus est sur une autre machine
ou s'il tourne sous une autre identité), ce n'est plus aussi simple mais
le principe reste le même.
Ok, merci pour ces explications Paul.
À+
--
François Lafont
Marc Espie
2014-11-15 11:21:07 UTC
Permalink
Post by Francois Lafont
Bonsoir,
Post by Marc Espie
En terme de securite, migrer vers quelque chose qui n'integre pas mod_perl
dans apache est une bonne idee (ne serait-ce que parce que c'est deux enormes
base de code, et qu'un pepin dans l'un ne devrait pas pouvoir directement
trasher l'autre).
Pas sûr d'avoir compris le sens de cette phrase.
Concept de base en secu: separation des responsabilites. Lorsque tu as une
grosse base de code, tu es sur qu'il y a des bugs dedans. mod_perl, c'est
mettre apache, perl, et la glue dans le meme processus, dans le meme espace
memoire -> tout gros bug dans l'un va impacter tout le reste.

Et je peux te garantir qu'il reste des bugs, et dans apache, et dans perl.
(et presque surement aussi dans mod_perl).

Tu peux aussi faire tourner tout ca avec des "quota" differents (limites
memoire, nombre max de fd, etc)

Avec un fastcgi, tu peux separer perl d'apache. tu peux faire tourner les deux
avec des identites separees. Voire, faire tourner chacun de tes scripts avec
des identites differentes. Donc s'il y a un probleme quelque part, ca ne
tuera pas tout.

(de deux choses l'une: soit tu as de bonnes notions en secu, auxquel cas
tu peux te faire ton propre avis. Soit je te conseille de me faire confiance
la-dessus. C'est un peu mon boulot... ;-) )
Post by Francois Lafont
Post by Marc Espie
Le fait que "ca bouge encore, mais beaucoup" veut aussi dire qu'il y aura
tres peu de reactivite concernant de nouvelles failles...
Ah. Je vois pas trop non plus là (le lien logique "ça bouge encore" => "il y
aura trÚs peu de réactivité concernant les failles" m'échappe un peu). Ça
serait pas plutÎt « ça bouge encore, mais *pas* beaucoup » ? (auquel
cas alors
je comprends ;)).
Ben "ca bouge encore", ca me parait assez clair. C'est un peu "tiens, c'est
pas encore mort, mais pas loin".
Post by Francois Lafont
Post by Marc Espie
Il y a des tonnes d'alternatives ces jours-ci, a base de fcgi ou autres.
Voir par exemple la doc de perl Dancer pour toutes les facons de faire
tourner une appli dancer.
Perso, ce que je trouve intéressant avec mod_perl, c'est le Perl directement
embarqué dans apache (pas de cgi ou de fastcgi) et donc pas de fork et donc
des perfs trÚs élevées.
Et tu as mesure ce que ca donnait avec fastcgi, pour comparer ? parce que
bon, les perfs sont quasi-identiques. Confere ce que disait perl.
Francois Lafont
2014-11-15 13:25:49 UTC
Permalink
Post by Marc Espie
Concept de base en secu: separation des responsabilites. Lorsque tu as une
grosse base de code, tu es sur qu'il y a des bugs dedans. mod_perl, c'est
mettre apache, perl, et la glue dans le meme processus, dans le meme espace
memoire -> tout gros bug dans l'un va impacter tout le reste.
Et je peux te garantir qu'il reste des bugs, et dans apache, et dans perl.
(et presque surement aussi dans mod_perl).
Tu peux aussi faire tourner tout ca avec des "quota" differents (limites
memoire, nombre max de fd, etc)
Avec un fastcgi, tu peux separer perl d'apache. tu peux faire tourner les deux
avec des identites separees. Voire, faire tourner chacun de tes scripts avec
des identites differentes. Donc s'il y a un probleme quelque part, ca ne
tuera pas tout.
(de deux choses l'une: soit tu as de bonnes notions en secu, auxquel cas
tu peux te faire ton propre avis. Soit je te conseille de me faire confiance
la-dessus. C'est un peu mon boulot... ;-) )
Mais je te fais totalement confiance. En plus tes explications sont étayées par
d'arguments qui me semblent très convaincants. ;)
Post by Marc Espie
Ben "ca bouge encore", ca me parait assez clair. C'est un peu "tiens, c'est
pas encore mort, mais pas loin".
Ah ok.
Post by Marc Espie
Et tu as mesure ce que ca donnait avec fastcgi, pour comparer ? parce que
bon, les perfs sont quasi-identiques. Confere ce que disait perl.
Ben non, j'ai jamais comparé. Quand j'ai découvert l'utilisation de mod_perl,
j'ai été vraiment ravi de ses perfs et je ne suis pas allé plus loin. Mais
maintenant, avec tes explications et celles de Paul vous m'avez convaincus ;)
et je tenterai une installation de FastCGI pour voir à l'occasion.

Merci.
--
François Lafont
Continuer la lecture sur narkive:
Loading...