Sortie de Apache 2.2.0

Posté par  . Modéré par Nÿco.
Étiquettes :
0
2
déc.
2005
Internet
« La fondation Apache Software et le projet Apache HTTP Server sont heureux d'annoncer la sortie de la version 2.2.0 de leur serveur HTTP.

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

  • # Bravo

    Posté par  (site web personnel) . Évalué à 6.

    Bravo pour cette news très détaillée !
    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  . Évalué à 4.

      Je plussoie volontiers, cette news est très complète !

      "et pendant ce temps, (pratiquement) aucun hébergeur n'est encore passé en apache2..."

      • [^] # Re: Bravo

        Posté par  (site web personnel) . Évalué à 7.

        http://www.freezee.org l'a fait !!!

      • [^] # Re: Bravo

        Posté par  . Évalué à 9.

        Nous on l'a fait, mais il faut dire que c'est très différent de la 1.3 (en particulier le comportement sous très forte charge, quand on est expérimenté en 1.3, on se retrouve un véritable bleu en 2.0)... en plus si on suit tous les conseils "ne pas utiliser ceci en production", il ne reste plus beaucoup d'avantages à Apache 2 (je pense à MPM worker en particulier...).

        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  . Évalué à 5.

        <<et pendant ce temps, (pratiquement) aucun hébergeur n'est encore passé en apache2...>>

        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  . Évalué à 2.

        Certes, mais malheureusement PHP 4 n'est pas encore parfaitement stable et est vivement déconseillé avec Apache 2. Je ne crois pas actuellement que le PHP 5 soit très stable sous Apache 2 non plus.

        • [^] # Re: Bravo

          Posté par  . Évalué à -1.

          On peut résumer en disant que PHP n'est pas encore très stable... ça n'a pas grand chose à voir avec Apache !

        • [^] # Re: Bravo

          Posté par  (site web personnel) . Évalué à 6.

          vieille légende.
          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  (site web personnel) . Évalué à -3.

      Merci à skc< pour tous ces XP (qui n'existent pas) qu'il m'a permis de gagner.

      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  (site web personnel) . Évalué à 4.

        Attention, cette fois Shift teste les effets de l'appel au troll. Ne votez pas!

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Bravo

        Posté par  . Évalué à 10.

        J'ai aussi l'impression que le vote pertinent ("d'accord") est utilisé pour récompenser un commentaire qui reflète ce que beaucoup de gens penset et auraient pu dire, qui mérite d'être dit, mais qui n'est pas assez utile pour être répété (et le tien est de ceux-là). Un commentaire peut donc être pertinent sans être intrinsèquement utile, CQFD.

        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  (site web personnel) . Évalué à 1.

          Mes arguments je les ai donné des dizaines de fois :http://linuxfr.org/comments/639781.html#639781

          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  . Évalué à 1.

            c'est bien, tu as fait ton devoir, et depuis longtemps. bravo, et merci.

            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  (site web personnel) . Évalué à 3.

              Je secoue le cocotier parce que j'en ai marre de voir que la documentation sur le système de vote demandée depuis très longtemps n'est toujours pas là.

              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  . Évalué à 6.

                Et si tu t'y mettais.

                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  (site web personnel) . Évalué à 2.

                  Pas de problème. Si je savais comment ça marche ou si on avait accès aux souces de ce site.

                  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  . É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  (site web personnel) . Évalué à 3.

                      Templeet ne fournit pas le système de gestion des votes et des droits de chacun des utilisateurs.

                      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  (site web personnel) . Évalué à 3.

    Je sais que la nouvelle est déjà très détaillée mais une des raisons pour lesquelles j'attendais cette version en mode stable concerne les nombreux correctifs IPv6 et ce notamment sur le proxy_caching (sinon 14 autres correctifs variant du simple fix au patch de sécurité).

    Steph

    • [^] # Re: IPv6

      Posté par  . Évalué à 4.

      Moi la feature de la mort que j'attendais était le mod_proxy_balancer. On va enfin pouvoir se passer de pound/haproxy ! Mais en fait pas vraiment... Le module fait de la balance de charge (la répartition se fait selon deux algo au choix, en fonction du nombre de paquet ou du débit) et sait suivre un cookie de session. Malheureusement son comportement est un peu surprenant : au lieu de balancer les paquets sans modifier le host de la requete HTTP, il utilise ce qu'on définit dans le fichier de conf. Par exemple si on a configuré pour monserveur.com deux workers, 192.168.10.10 et 192.168.10.1, quand il reçoit une requete HTTP pour monserveur.com il fait une requete vers le worker de la forme http://192.168.10.xx ! Pas pratique si on veut faire du virtual hosting derrière. J'espère que ce sera vite corrigé.

      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  . Évalué à 5.

    http://www.openbsd.org/faq/fr/faq1.html#HowAbout
    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  (site web personnel) . Évalué à 9.

      La licence est "allourdie" par une partie sur les brevets logiciels mais ça n'est pas la seule raison du fork. Il semblerait que les développeurs Apache aient aussi rejeté beaucoup de patches des développeurs d'OpenBSD et que ces derniers ont donc décidé qu'il serait plus pratique de forker que de resynchroniser à chaque nouvelle version.

      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:
      Their new license contains more stuff, and we do not accept MORE STUFF in licenses
      Henning Brauer a dit:
      the apache included in OpenBSD has always been modified, to fix a number of scary bugs - that are still present in 1.3.31 (and yes, apache/mod_ssl pplz have been informed about them), I might add. Starting with OpenBSD 3.2 we diverged even further with the chroot & priv-revoke work I did.
      et
      there is a number of serious security problems in apache that we have fixed, and that have been offered them back, and they refused.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: La license d'Apache 2

      Posté par  . Évalué à 10.

      Ça a été expliqué publiquement, tu trouvera les discussions à ce sujet dans les archives de la mailing-list misc@. Entre autres raisons:

      - 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  (site web personnel) . Évalué à 0.

        OK pour Apache car les arguments me semblent solides.
        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  (site web personnel) . Évalué à 2.

          http://www.holland-consulting.net/tech/ocep/#knowninsecure

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: La license d'Apache 2

          Posté par  . Évalué à 5.

          À l'époque Sendmail était le seul MTA évolué et (suffisamment) libre. Je crois qu'Exim n'est devenu une alternative suffisamment évoluée que par la suite (par ailleurs, des devs d' OpenBSD ont expliqué qu'ils le trouvaient très mal conçu et atrocement codé). Postfix et Qmail ne sont pas assez libres selon Theo de Raadt.

          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  (site web personnel) . Évalué à 2.

            merci pour ta réponse.
            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  . Évalué à 3.

              L'URL du fichier de conf a été bouffée.

              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  (site web personnel) . Évalué à 2.

              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 ?
              Oui dans le sens où la grosse majorité des projets libres sont codés de manière très peu rigoureuse (par rapport à OpenBSD).

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: La license d'Apache 2

          Posté par  . Évalué à 0.

          Pour les MTA c'est tres simple: Sendmail est le seul qui reponde aux criteres de license d'OpenBSD.
          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  . Évalué à 2.

            Le spamd d'OpenBSD (à ne pas confondre avec celui de SpamAssassin) est complétement MTA-agnostique.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.