Ils considèrent cette version comme la meilleure disponible et encouragent les utilisateurs de toutes les versions précédentes à effectuer la version à jour. » Les nouvelles fonctionnalités depuis la version 2.0 :
Modules principaux:
Authn/Authz
Les mécanismes d'authentification et d'autorisation ont été revus, un module d'alias permet de simplifier grandement certaines configurations.
Caching
Les modules de cache mémoire et disque ont été beaucoup modifiés et sont maintenant d'une qualité considérée comme apte à la production.
Configuration
La structure du fichier de configuration a été simplifiée et modularisée. De nombreuses configurations courantes sont proposées avec l'application et peuvent être facilement activées.
Graceful stop
Les différents mécanismes de répartition des requêtes au sein de l'application (prefork, worker, event MPMs) ont été modifiés afin de permettre un arrêt plus en douceur de l'application. Il est possible de spécifier un délai de grâce pour traiter les requêtes en cours avant l'arrêt.
Proxying
Le nouveau module de proxy permet de faire de la répartition de charge sur plusieurs serveurs (load balancing), le module mod_proxy_ajp permet de s'interfacer avec Tomcat en utilisant le protocole JServ 1.3
Regular Expression Library Updated
La version 5.0 de la librairie d'expressions rationnelles compatible Perl est maintenant inclue (PCRE)
Filter
Un module permet l'ajout dynamique de filtres dans le flux de sortie selon les paramètres de la requête ou de la réponse, ou les variables d'environnement. Ce mécanisme règle les problèmes de dépendances et d'ordonnancement qui existaient dans la version 2.0. (Ceci permet par exemple la compression à la volée des pages HTML dynamiques).
Large File Support
httpd est maintenant compilé avec le support des fichiers de plus de 2 Go sur les unix 32 bits modernes. Les requêtes de plus de 2 Go sont également traitées.
Event MPM
Ce mécanisme expérimental de traitement des requêtes conserve maintenant un thread séparé pour gérer les connexions persistantes (Keep Alive) et les nouvelles connexions. Dans les versions précédentes, il était nécessaire de dédier plus de ressources pour traiter les requêtes persistantes.
SQL Database Support
Un module dédié permet de fournir des connexions et des pools de connexions aux modules qui ont besoin d'accéder à une base de données, leur évitant d'implémenter chacun leur propre mécanisme. (Note: Ceci n'est pas disponible de base aux utilisateurs de Microsoft Windows)
Amélioration de modules existants
Authn/Authz
Les modules d'authentification ont été renommés et étendus. Certains ont été séparés en plusieurs modules afin de permettre une plus grande modularité. Un module gérant des alias a également été ajouté.
mod_authnz_ldap
Le module d'authentification LDAP a été porté et amélioré de la version 2.0 et adapté à la nouvelle organisation de la version 2.2
mod_info
Ajout d'un nouveau paramètre "?config" qui retourne la configuration telle qu'elle est lue par Apache (y compris les noms des fichiers et les numéros de ligne). Le module montre également l'ordre de tous les traitements et les informations de compilation.
mod_ssl
Ajout du support de la RFC 2817 qui permet de transformer une connexion en clair vers une connexion chiffré en TLS.
mod_imagemap
Le module mod_imap a été renommé mod_imagemap pour des raison de clarté. Il gère les zones d'images et non pas le protocole de courrier IMAP.
Amélioration du programme
httpd
L'option de ligne de commande -M permet maintenant de lister tous les modules chargés par la configuration courante. Contrairement à l'option -l, cette liste comprend les modules chargés par mod_so.
httxt2dbm
Un nouveau programme permet de transformer les fichiers texte décrivant des ré-écritures (RewriteMap) en fichier binaire au format dbm pour en améliorer les performances.
Modification des modules de développement
APR 1.0 API
Apache 2.2 utilise maintenant l'API de la Bibliothèque Portable Apache (Apache Portable Runtime APR) en version 1.0 minimum. Toutes les fonctions et symboles déclarés obsolètes dans les versions précédentes de APR et APR-Util ont été supprimés.
Authn/Authz
Organisation des modules d'authentification et d'autorisation:
mod_auth_* -> Modules permettant de traiter les informations d'identification avec le client (en HTTP)
mod_authn_* -> Modules fournissant un mécanisme d'authentification
mod_authz_* -> Modules fournissant un mécanisme d'autorisation
mod_authnz_* -> Modules fournissant à la fois un mécanisme d'autorisation et d'authentification
Connection Error Logging
Une nouvelle fonction, ap_log_error permet de tracer les erreurs relatives à la connexion du client. Ces traces incluent l'adresse IP du client.
Test Configuration Hook Added
Un nouveau mécanisme permet aux modules d'ajouter des tests lorsqu'Apache est lancé en mode de test de la configuration (-t)
Set Threaded MPM's Stacksize
Une directive de configuration ThreadStackSize permet de modifier la taille de la pile des threads de l'application. Ceci permet d'utiliser certains modules de tierce-parties sur des plates-formes ayant une faible taille de pile d'exécution.
Protocol handling for output filters
Par le passé, les filtres étaient responsables de modifier les entêtes de la réponse lorsqu'ils modifiaient le flux de la réponse. Un nouveau module mod_filter peut maintenant traiter cette tâche, simplifiant l'écriture des filtres.
Monitor hook added
Les modules peuvent maintenant demander l'exécution de traitements de maintenance périodiques ou ordonnancés dans le processus parent d'Apache.
Connexion aux bases de données (DBD Framework)
Avec Apache 1.x et 2.0, les modules nécessitant une connexion à une base de données devaient également gérer les connexions. En sus de ré-inventer la roue, ceci pouvait être particulièrement inefficace. Par exemple, lorsque plusieurs modules avaient besoin d'accéder à la même base de données, chacun ouvrait ses propres connexions.
Apache 2.1 et les versions suivantes fournissent une API pour gérer les connexions aux bases de données (y compris des stratégies optimisées pour le fonctionnement en threads et sans threads). La version 1.2 de la librairie APR fourni également des fonctions pour dialoguer avec la base de données.
Les nouveaux modules doivent maintenant utiliser ces interfaces pour toutes les opérations sur les bases de données. Les applications et les modules doivent également être mises à jour pour cela, de manière transparente si possible.
Aller plus loin
- Téléchargement (48 clics)
- Nouvelles fonctionnalités (4 clics)
- Mail d'annonce (6 clics)
# Bravo
Posté par Infernal Quack (site web personnel) . Évalué à 6.
Elle a le mérite de ne pas seulement dire que "Apache 2.2.0 si out" mais décrit aussi particulièrement bien les évolutions.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Bravo
Posté par iznogoud . Évalué à 4.
"et pendant ce temps, (pratiquement) aucun hébergeur n'est encore passé en apache2..."
[^] # Re: Bravo
Posté par Damien Szczyt (site web personnel) . Évalué à 7.
[^] # Re: Bravo
Posté par EdB . Évalué à 10.
[^] # Re: Bravo
Posté par Maxime (site web personnel) . Évalué à 10.
[^] # Re: Bravo
Posté par Sylvain Sauvage . Évalué à 0.
[^] # Re: Bravo
Posté par Christophe BAEGERT . Évalué à 9.
Mais si on ne les suit pas, c'est un peu galère au début, mais une fois que tout est bien configuré, ça arrache tout ! Apache 1.3 est vraiment largué.
[^] # Re: Bravo
Posté par left . Évalué à 5.
Il faut savoir qu'il n'y a pas que Apache lui même qui est important, mais également les modules chargés. Un exemple concret :
les auteurs de mod_php ont longtemps déconseillé l'utilisation de Apache en version 2 car le multithreading pouvait poser des problèmes (contrairement à apache 1.x qui utilisait le fork). Les problèmes en questions ne viennent pas forcément du module mod_php lui même, mais plutôt des dll qui peuvent être chargés par lui, et qui n'ont pas forcément été compilées avec des options compatibles avec une utilisation en multithread.
Je ne connais pas le statut de ceci car je n'utilise pas Apache comme peuvent le faire les hébergeurs, mais c'est un argument fort et important. Jeter la pierre trop vite il ne faut pas ...
[^] # Re: Bravo
Posté par Mr F . Évalué à 2.
[^] # Re: Bravo
Posté par Christophe BAEGERT . Évalué à -1.
[^] # Re: Bravo
Posté par Éric (site web personnel) . Évalué à 6.
En fait PHP n'est pas conseillé sur toute application multi-thread (grosso modo certains trucs planteront).
Le résultat c'est que les modules MPM et PerChild sont déconseillés sur PHP. Le module Préfork marche lui tout à fait, sous Apache 2 comme sous Apache 1.
Les développeurs de PHP disent juste qu'à leur avis Apache 2 n'a aucun intérêt si c'est pour garder prefork et donc qu'il vaut mieux garder apache 1.
Mais si, en prefork, c'est tout à fait stable, depuis pas mal de temps.
[^] # Re: Bravo
Posté par Infernal Quack (site web personnel) . Évalué à -3.
En fait, le "first post" que j'ai fait n'avait que pour but de tester l'effet "first post" qui permet de faire le plein en votes positifs. Comme d'habitude, ça marche nickel.
Comme d'habitude, le vote "pertinent" est utilisé comme un vote "d'accord" alors que mon post était plus "inutile" que "pertinent". Mais merci, grace à ces points positifs, j'aurais encore plus le droits de poster des trucs sur ce site :)
Tout ça pour dire que ce système de vote est merdique. On attends toujours une explication du système avec un lien sur la première page afin d'aider les nouveaux venus.
Désolé skc< d'avoir utilisé ta news pour faire du testing ;)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Bravo
Posté par ZeroHeure . Évalué à 4.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Bravo
Posté par Cali_Mero . Évalué à 10.
Ca m'arrive souvent de pertinenter une personne dont l'avis reflète ce que moi-même j'aurais pu exprimer, par souci de consensualité et de non-redondance. Et je crois qu'on est effectivement nombreux ici à le faire. D'où l'effet first post...
Tout ça pour dire que ce système de vote est merdique.
Aurais-tu oublié tes arguments au vestiaire ? Ce système n'est pas parfait mais il a de la personnalité (collective, en plus). Et c'est pour ça qu'on l'aime quand même.
[^] # Re: Bravo
Posté par Infernal Quack (site web personnel) . Évalué à 1.
Et je m'excuse mais moi je l'aime pas ce système.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Bravo
Posté par Gniarf . Évalué à 1.
maintenant tu abuses et tu pollues. et quand tu dis que tu es "Désolé skc< d'avoir utilisé ta news pour faire du testing", je ne le crois pas un instant...
[^] # Re: Bravo
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Quand à skc, si, je m'en excuse. Et c'est justement parce que je le connais que je me suis permis de faire ça. Je pense savoir qu'il ne va pas en faire une jaunisse :)
Libre à toi d'apprécier ce système mais je pense que tout le monde est d'accord pour qu'au moins une explication de ce système soit disponible via un lien en première page.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Bravo
Posté par golum . Évalué à 6.
Avec le nombre de post que tu ponds par jour , tu trouverais sûrement 5 mn pour t'y consacrer.
:O)
[^] # Re: Bravo
Posté par Infernal Quack (site web personnel) . Évalué à 2.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Bravo
Posté par golum . Évalué à 2. Dernière modification le 04 décembre 2021 à 20:33.
Au boulot
http://www.templeet.org/ (NdM: remplacé en 2021 par un lien archive.org)
[^] # Re: Bravo
Posté par Infernal Quack (site web personnel) . Évalué à 3.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
# IPv6
Posté par FRLinux (site web personnel) . Évalué à 3.
Steph
[^] # Re: IPv6
Posté par Arachne . Évalué à 4.
Sinon, on se tape un troisième connecteur AJP vers Tomcat... Ce serait bien que ça se stabilise, le mod_jk2 ayant été abandonné un peu prématurément. L'inclusion officielle dans Apache devrait aider.
# La license d'Apache 2
Posté par brunoc . Évalué à 5.
http://www.apache.org/licenses/
Chez OpenBSD, ils sont TRES à cheval sur les licenses, et ça contribue à la personnalité du projet ! Et à leurs sens, la license d'Apache 2 n'est pas acceptable. D'où leur choix de se resteindre à Apache 1.3 dont ils maintiennent un fork dans leur distrib. Mais j'admet que j'ai du mal à comprendre, la license Apache 2 est compatible GPL et le projet BSD contient des briques GPL... En quoi la license d'Apache 1 est-elle plus approriée que la license d'Apache 2 dans le cadre du projet OpenBSD ?
Vite, postons chez eux...
[^] # Re: La license d'Apache 2
Posté par Krunch (site web personnel) . Évalué à 9.
Les gens d'OpenBSD préfèrent un truc stable et éprouvé avec une licence très "libérale" à un truc avec plus de fonctionnalités et à la licence plus restrictive (non pas que je considère Apache 2 instable et pas libre, je l'ai jamais utilisé et j'ai pas vraiment essayé de comprendre la partie sur les brevets).
Par ailleurs la nouvelle licence Apache n'est pas compatible avec la GPL et les dernières versions d'Apache 1 sont sous la même licence qu'Apache 2.
http://marc.theaimsgroup.com/?t=108653023100001&r=1&(...)
http://undeadly.org/cgi?action=article&sid=2004060713360(...)
http://www.apache.org/licenses/GPL-compatibility
Theo de Raadt a dit: Henning Brauer a dit: et
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: La license d'Apache 2
Posté par herodiade . Évalué à 10.
- C'est un projet BSD, celà signifie qu'il privilégie les licences les moins contraignantes possible. La licence d'apache 1.3 était très acceptable pour la communauté BSD, mais celle d'apache 2.x impose des contraintes plus strictes (raison aussi de la décision d'abandonner, à peut près à la même époque, XFree86 pour x.org).
- En outre les devs d'Open n'aiment pas les licences longues et compliquées, et préfèrent maintenant les licences à la MIT/X11/ISC (plus facile à comprendre sans ambiguité, surtout pour des non-juristes).
- L'apache inclus dans leur système avant le changement de licence était déjà largement modifié pour sécurisation (révocation des privilège plus stricte, chroot par défaut des processus fils etc.) et convenait suffisament bien au projet et à ses utilisateurs.
- Certainsdeveloppeurs d'OpenBSD attendaient une bonne occasion pour ne plus avoir a suivre l'évolution d'apache (merger les nouvelles versions), pour avoir la latitude de faire de plus grosses modifications dans l'arbre des sources, comme: virer les wrappers ap_* afin de faciliter l'audit et la relecture du code, assainir le traitement des chaines et des signaux etc ... toujours dans l'objectif d'améliorer la sécurité du serveur httpd.
Les résultats concrets sont déjà visibles. Par exemple leur version d'apache n'était pas affectée par la récente faille CAN-2004-0700, ce bug ayant été corrigé bien avant dans l'arbre des sources d'OpenBSD lors d'une série d'audits/renforcements/nettoyages de routine sur le traitement des chaines dans apache (cf. le commit sur ssl_engine_ext.c qui corrige cette faille: revision 1.10, date: 2003/06/01 15:53:41; author: deraadt; "various format string cleanups; tedu ok"). Il y a d'autres exemples de ce type.
Bref, maintenir une fork d'apache 1.3 (sans casser l'API, pour rester compatible avec les modules externes) était la solution la plus pertinente étant donné leurs priorités (préférences pour les logiciels aux licences très permissives, priorité à la sécurité et l' "auditabilité" stricte du codeplutôt qu'aux fonctionnalités amenées par la version 2) de la même façon que de nombreux admins préfèrent apache 1.3 pour sa robustesse éprouvée.
[^] # Re: La license d'Apache 2
Posté par patrick_g (site web personnel) . Évalué à 0.
Par contre pour Sendmail je comprends pas trop.
L'historique de sécurité n'est pas bon, la config est ultra-complexe, le soft est monolithique.
Pourquoi ne pas choisir par défaut un autre MTA (postfix, exim..etc) dont l'historique de sécurité est bien meilleur, la configuration bien plus abordable et l'audit bien plus simple du fait de la conception en multiples modules indépendants ?
[^] # Re: La license d'Apache 2
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: La license d'Apache 2
Posté par herodiade . Évalué à 5.
D'autre part les choses ont aussi beaucoup évolué pour Sendmail: l'équipe de dev était très réceptive aux patchs proposés par l'équipe d'OpenBSD (à contrario de l'équipe d'Apache), et ils ont fait énormément d'efforts pour sécuriser leur logiciel.
Il est maintenant très rare que de nouvelles failles soient découvertes dans Sendmail: la dernière date d'il y a deux ans (faille patchée par Todd C. Miller, de l'équipe d'OpenBSD justement). Les dernières failles découvertes dans Exim sont beaucoup plus récentes en comparaison (au moins deux en 2005). Encore une preuve que l'audit, ça paie :)
De plus un énorme refactoring est dans les tuyaux pour Sendmail X (dans le sens d'une modularisation etc.), actuellement en version alpha.
Quand à la config, elle est maintenant facilitée par un jeu de macros m4 bien fait et assez complet, si bien qu'on peut maintenant considérer le fichier (très simple) sendmail.mc comme le vrai fichier de conf, et ignorer le sendmail.cf. Voir par ex.
http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.sbin/sendm(...)
Bref, il est temps de réviser l'horrible réputation de Sendmail. Surtout si c'est pour lui opposer Exim.
Quoiqu'il en soit, postfix et Exim sont dans les ports (à la différence d'apache 2.0/2.2) et le remplacement de Sendmail est facilité grâce à un jeu de scripts. cf. mailer.conf(5).
Ah si Wietse Venema et IBM plaçaient Postfix sous licence MIT/X11 ou BSD ...
[^] # Re: La license d'Apache 2
Posté par patrick_g (site web personnel) . Évalué à 2.
L'URL du fichier de conf a été bouffée.
Sinon, oui j'avais vu le départ du dev de Sendmail X, mais je pense qu'on perd alors l'expérience et le caractère éprouvé du code actuel.
Je pense que le travail d'audit d'OpenBSD aurait été mieux employé sur Exim...mais licence GPL donc peut-être guerre de religion ?
le fait par les devs OpenBSD de qualifier exim d'"atrocement codé" est-il a rapprocher des commentaires récents de Theo sur la qualité du kernel Linux ? Il semble y avoir un concours de tir aux pigeons en ce moment non ? Enfin...c'est ce qui fait le charme des devs de cet OS !
[^] # Re: La license d'Apache 2
Posté par herodiade . Évalué à 3.
Oops, j'ai fait un copié/collé dans le correcteur d'orthographe de gmail avant de poster, sans faire attention au "(...)ssage" de templeet, et *paf* le lien !
C'était: http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.sbin/sendm(...)
j'avais vu le départ du dev de Sendmail X, mais je pense qu'on perd alors l'expérience et le caractère éprouvé du code actuel.
Pour le recettage du code, c'est assez vrai. Hum, qui va essuyer les platres des premières releases ?
Mais concernant l'expérience, je ne crois pas qu'Eric Allman vas oublier ses 20+ ans de developpement de MTA, (pièges, évolutions, erreurs de design, sécurisation à posteriori ...) du jour au lendemain ;)
mais licence GPL donc peut-être guerre de religion ?
Non, ils considérent la licence de Sendmail comme une GPL-like (c'est d'ailleur pour ça qu'il est dans l'arbo "gnu/" du dépôt cvs d'OpenBSD), donc pas de différence de ce point de vue pour eux.
[^] # Re: La license d'Apache 2
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: La license d'Apache 2
Posté par panda panda . Évalué à 0.
Beaucoup de boulot a ete fourni par le projet OpenBSD sur la securisation du code de sendmail et ils ont developpe pas mal d'outils qui tournent autour (spamd, des milters qui s'integrent avec pf, ...).
Peut etre que Sendmail X les fera changer d'avis mais je n'y crois pas tant que ca pour le moment.
[^] # Re: La license d'Apache 2
Posté par herodiade . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.