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 à 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 à 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.
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
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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 ?
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 ?
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 ?
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.
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.
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.
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.
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.
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.
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) ?
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) ?
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) ?