Maintenance de mod_perl de Apache

Le 10/11/2014 16:00, Francois Lafont a écrit :

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

Bonjour,

Le 13/11/2014 18:40, Jean-Louis Morel a écrit :

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.

Ok, cool, je vois un commit qui date d'il y a 2 jours.

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

Merci Jean-Louis pour cette réponse. Me voilà rassuré. ;)

--
François Lafont

In article <546524f2$0$5107$426a34cc@news.free.fr>,
Francois Lafont <francois.lafont@nospam.invalid> wrote:

Bonjour,

Le 13/11/2014 18:40, Jean-Louis Morel a écrit :

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.

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.

Bonsoir,

Le 14/11/2014 17:57, Marc Espie a écrit :

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.

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 ;)).

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

À (at) Sat, 15 Nov 2014 02:35:52 +0100,
Francois Lafont <francois.lafont@nospam.invalid> écrivait (wrote):

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/>

À (at) Sat, 15 Nov 2014 05:00:50 +0100,
Francois Lafont <francois.lafont@nospam.invalid> écrivait (wrote):

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/>

In article <5466ade4$0$27506$426a74cc@news.free.fr>,
Francois Lafont <francois.lafont@nospam.invalid> wrote:

Bonsoir,

Le 14/11/2014 17:57, Marc Espie a écrit :

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... ;-) )

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".

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.

Le 15/11/2014 12:21, Marc Espie a écrit :

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. ;)

Ben "ca bouge encore", ca me parait assez clair. C'est un peu "tiens, c'est
pas encore mort, mais pas loin".

Ah ok.

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

À (at) Sat, 15 Nov 2014 14:11:58 +0100,
Francois Lafont <francois.lafont@nospam.invalid> écrivait (wrote):

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.

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/>