Maintenance de mod_perl de Apache
Le
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.
--
François Lafont
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
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
Le 13/11/2014 18:40, Jean-Louis Morel a écrit :
Ok, cool, je vois un commit qui date d'il y a 2 jours.
Merci Jean-Louis pour cette réponse. Me voilà rassuré. ;)
--
François Lafont
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.
Le 14/11/2014 17:57, Marc Espie a écrit :
Pas sûr d'avoir compris le sens de cette phrase.
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 ;)).
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
Francois Lafont
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 - Perl en français -
Francois Lafont
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 - Perl en français -
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... ;-) )
Ben "ca bouge encore", ca me parait assez clair. C'est un peu "tiens, c'est
pas encore mort, mais pas loin".
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.
Mais je te fais totalement confiance. En plus tes explications sont étayées par
d'arguments qui me semblent très convaincants. ;)
Ah ok.
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
Francois Lafont
Certes.
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 - Perl en français -