Journal La fin du monde

Posté par  (site web personnel) .
Étiquettes : aucune
13
3
fév.
2010
apche 1.3.42 est sortie[1].

Cette version de maintenance (correction d'un vulnérabilité importante de mod_proxy[2])
est la derrière de la lignée 1.3[1] de ce magnifique serveur http.

Il nous aura rendu bien des services notre apache 1.3. Certains d'entre nous (dont moi) le connaissaient dans
ses moindre recoins, dans ses moindres lignes de code. Comme un compagnon fidèle toujours stable, toujours prévisible dans son comportement.

J'aimais le compiler statiquement avec juste ce qu'il faut, un tout petit binaire mais si puissant, si vite chargé en mémoire.

Avec lui, il y avait toujours une solution élégante pour tout. Malgré ce, ça restait un beau soft bien unix dans l'esprit, avec ses beau process défilant dans le top et d'inavouables patch maison.

Par quoi te remplacerais-je mon vieil ami ? Par l'autre bloatware[3], le petit russe[4] ... je ne sais pas trop.

Je te regrette déjà...

[1] http://www.apache.org/dist/httpd/Announcement1.3.html
[2] http://www.secuobs.com/revue/news/188254.shtml
[3] http://apache.crihan.fr/dist/httpd/httpd-2.2.14.tar.gz
[4] http://wiki.nginx.org/Main

  • # lighttpd ?

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

    T'as déjà testé lighttpd ?
    Je ne l'ai jamais utilisé car il ne gère pas les rewrite de façon simple comme apache/htaccess.
    Mais sinon il semble réputé pour sa vitesse.

    • [^] # Re: lighttpd ?

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

      >Je ne l'ai jamais utilisé car il ne gère pas les rewrite de façon simple comme apache/htaccess.

      Les mêmes causes ont les mêmes effets. Dur de dire au clients, demain vos .htaccess ne marchent plus.

    • [^] # Re: nginx ?

      Posté par  . Évalué à 2.

      Que pensez vous de nginx ?
      http://wiki.nginx.org/Main

      • [^] # Re: nginx ?

        Posté par  . Évalué à 5.

        Nginx est un très bon soft, je l'ai utilisé pour délivrer du contenu statique et dans un pool de reverse proxy ssl et j'en ai été tres satisfait.
        - reverse : certaines choses sont perfectibles, comme la détection de bon fonctionnement des backends qui reste en dessous de celle de Haproxy (qui est un chef d'oeuvre) ou de relayd, mais tu pourras rewriter par exemple
        - web : tu ne retrouveras pas toutes les fonctionnalités fournies par apache et ses nombreux modules mais les perfs seront au rendez-vous

        En bref, il est à essayer, sa configuration est assez simple et la wikidoc est correcte.

  • # Une belle fin...

    Posté par  . Évalué à 10.

    ... que celle de finir sur un numéro de version finissant par 42 !

    • [^] # Re: Une belle fin...

      Posté par  . Évalué à 2.

      La grande question ne serait-elle pas « Où est-ce que tout se finit ? » ?

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Comprend pas ...

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

    Pourquoi dire que c'est la fin alors que des irréductibles l'utilise toujours :
    $ httpd -v
    Server version: Apache/1.3.29 (Unix)

    Je vous rassure cette version est patché et sans faille connu.

    • [^] # Re: Comprend pas ...

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

      J'ai mieux (non patché, bien vulnérable pour faire tourner un truc proprio)

      $ httpd -v
      Server version: Apache/1.3.12 (Unix)
      Server built: Aug 14 2006 22:07:30

      Avec un petit haproxy, ça passe impec :)

      • [^] # Re: Comprend pas ...

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

        En plus tu es légèrement en retard sur les versions à en croire la date de build

        # /usr/lib/apache/bin/httpd -v
        Server version: Apache/1.3.31 (Unix)
        Server built: May 12 2004 19:01:49

        là par contre il s'agit d'un apache non patché sur un unix proprio.

        Concours de celui qui a la moins grosse (version d'apache) ?

      • [^] # Re: Comprend pas ...

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

        Pas mieux au niveau de la version mais avec un build time beaucoup plus vieux :)

        # ./httpd -v
        Server version: Apache/1.3.12 (Unix)
        Server built: Apr 8 2002 16:32:11

    • [^] # Re: Comprend pas ...

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

      >>>$ httpd -v
      >>> Server version: Apache/1.3.29 (Unix)

      >>> Je vous rassure cette version est patché et sans faille connu.

      C'est la version incluse dans OpenBSD c'est ça ?
      J'ai posé la question au sujet d'OpenBSD dans l'article LWN [http://lwn.net/Articles/372558/#Comments] et il m'a été répondu que les devs d'OpenBSD s'étaient arrêtés à la version 1.3.29 parce que les suivantes sont sous licence Apache v2 et qu'ils n'aiment pas cette licence.
      Quelqu'un sait ce qui pose problème dans la licence v2 ?

  • # Cherokee

    Posté par  . Évalué à 2.

    Donnes sa chance à Cherokee :

    http://www.cherokee-project.com/

  • # CommonLisp

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

    Un serveur rapide en CL, c'est parfait !
    http://john.freml.in/teepeedee2-release

    Et le troll qui va avec : http://tech.slashdot.org/article.pl?sid=09/05/25/1553220

  • # apache 1.3 et apache 2.2

    Posté par  . Évalué à 2.

    Quelqu'un pourrait expliquer la différence entre apache 1.3 et apache 2.2 ?

    Pourquoi parler de la fin d'apache1.3 alors qu'apache 2.2 existe ?

    • [^] # Re: apache 1.3 et apache 2.2

      Posté par  . Évalué à 2.

      Probablement pour la même raison que microsoft ou les mainteneurs linux (par exemple) parlent de l'arrêt du support pour Windows 2000 ou le noyau 2.6.x (respectivement...) alors qu'il existe Windows XP/Vista/Seven et le noyau 2.6.y/2.6.z (avec y, z > x)

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: apache 1.3 et apache 2.2

      Posté par  . Évalué à 1.

      Il me semble que la principale différence entre apache 1.3 et 2.2 (outre les modules) c'est la manière de traiter les requêtes HTTP.

      Apache 1.3 faisait un fork pour traiter chaque requête, alors que apache 2.2 peut avoir plusieurs comportement, notamment avec le module mpm-worker, il ne fork plus systématiquement pour traiter chaque requête HTTP, mais je pense qu'il a un pool de thread et de de processus.

      On en avait pas mal entendu parler pour des problèmes d'instabilité potentielle notamment avec php. Parce que comme plusieurs requêtes peuvent être traitées par un même processus, Il suffisait qu'un module de utilisé par php ne soit pas thread safe pour que cela explose en vol. Pour autant, je n'ai jamais rencontré ce problème, donc soit j'utilise que des modules php thread safe, soit je suis loin d'avoir assez de trafic pour que cela pose problème (ce qui est plus probable).

    • [^] # Re: apache 1.3 et apache 2.2

      Posté par  . Évalué à 3.

      Il y en a plusieurs. La principale est que le code a ete "segmente" pour faciliter la portablite et en rendre apache "en kit". D'ailleurs, l'ambition initiale de la branche 2.2 (puis 2.4 et finaliement 3.x) etait aussi de faire d'apache un meta-serveur.
      Pour cela il y'a eu des changement important dans apache 2.x:
      - apache depend de apr (Apache Portable Runtime) qui fourni une couche d'abstraction + les fonctions les plus communement utilisees. apr-util offre une collection d'API "wrappers" (libiconv, memcache, BDB, *SQL).
      - La gestion des requetes est separee en 2 parties:
      1. le MPM qui gere la connexion et "lance" la requete au sain du serveur.
      2. les modules qui la traite (a noter qu'a la base, le traitement HTTP devait etre un module, mais ce dernier est encore trop lie au serveur)

      Ce sont les changements les plus visible.
      Au dela de ca, il y'a une meilleure gestion des hooks (pour l'execution des modules), le support des filtres (par ex pour la compression), le support de "pool" de connexion partages (apr_dbd), le support out of the box de SSL et IPv6 ;), une API flexible pour l'authentification, pour du cache et du proxying.

      et pour apache 2.4 (pour le moment c'est 2.3.x) une API pour la gestion des sessions :)
      et les mpm loadable (avant c'etait en dur)

      • [^] # Re: apache 1.3 et apache 2.2

        Posté par  . Évalué à 1.

        Ce que je ne comprends pas, c'est que certains veulent rester coûte que coûte avec Apache 1.3 alors qu'apache 2.2 existe et devrait être mieux, et qu'ils jugent 2.2 comme un bloatware.

        • [^] # Re: apache 1.3 et apache 2.2

          Posté par  . Évalué à 1.

          parceque le memory fingerprint d'apache 2.2 est "gros" meme avec un MPM threade ?
          apache httpd n'est plus le serveur web le plus rapide et moins gourmand :)

          Mais apache 2.x a gagne en confort applicatif. Au boulot, on avait une douzaine de vieux clous avec apache 1.3.x compile en statique avec des patches et des modules maison.
          Nous sommes passes a apache 2.2 avec event MPM.
          Resultats des courses:
          - Pas de patch pour le support SSL, mod_gzip ou IPv6
          - plus qu'un patch sur les module d'apache d'origine (contre 12 avant)
          - on chaine les modules + facilement
          - pour le logging, plus besoin de se coltiner un patch pour mod_log_config
          - on peut charger un lib apr-util sans avoir a se frapper une compilation

          Et quand on passera a apache 2.4. on reduira encore le nombre de lignes de code maison.
          Bref, c'est un bohneur d'ecrire un module apache :)

          En revanche, le modele 1 threads/process = 1 connexion devient une plaie (d'ou l'interet de coller un haproxy devant).

        • [^] # Re: apache 1.3 et apache 2.2

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

          > Ce que je ne comprends pas, c'est que certains veulent rester coûte que coûte avec Apache 1.3 alors qu'apache 2.2 existe et devrait être mieux, et qu'ils jugent 2.2 comme un bloatware.

          Comme expliqué dans le post plus haut, apache 1.3 et apache 2.2 ne sont pas du tout la même chose.

          apache1.3 "a patchy server" est un petit truc qui se charge en mémoire et fait bien son job et pas plus. En gros tu construis un binaire httpd avec tout ce qui te faut dedant (ssl, php, proxy ...) et ça marche (ni plus ni moins).
          Maintenant si tu veux modifier ton serveur (par exemple mettre à jour php) tu part pour une recompilation. Si tu veux faire quelque chose de pas prévu, il faut soit patcher le code
          soit appeler un autre programme (par exemple j'ai des apache 1.3 qui font reverse proxy vers un haproxy qui balance sur un cluster de mongrel).

          apache2.2 est un gros framework pour construire des serveurs http modulaire ce qui est bien mais pas toujours souhaitable. Car plus groumand en ressources et souvent plus compliqué à déployer.

          Il existe des petits serveurs http comme ligthttpd ou nginx qui sont très performants, modulaires et une excellente alternative à apache 1.3. Le problème majeur qu'ils posent
          est qu'ils ne sont pas compatibles avec apache au niveau de la conf. Donc par exemple les htaccess tout prêt que tu trouves avec les cms ne marchent pas.
          Du coup sans apache 1.3 tu te retrouve à devoir déployer des solutions beaucoup plus complexes et plus lourdes. C'est valable pour un gros site. Mais pas pour plein de petits.

          En plus, l'esprit de apache2.2 est plus éloigné de l'esprit unix : "ne faire qu'une chose mais la faire bien"

          Il fait plein de choses parfois de façon excellente (mod_perl2) parfois de façon navrante (mod_proxy-balancer).

          • [^] # Re: apache 1.3 et apache 2.2

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

            apache2.2 est un gros framework pour construire des serveurs http modulaire ce qui est bien mais pas toujours souhaitable.

            Il existe des petits serveurs http comme ligthttpd ou nginx qui sont très performants, modulaires et une excellente alternative à apache 1.3. Le problème majeur qu'ils posent
            est qu'ils ne sont pas compatibles avec apache au niveau de la conf.

            Et donc eux c'est pas grave qu'ils soient modulaires ?

            par exemple j'ai des apache 1.3 qui font reverse proxy vers un haproxy qui balance sur un cluster de mongrel

            Ah oui, et après c'est les mêmes qui vont troller sur Java et JEE qui est trop lourd avec ses couches d'abstractions :-D

  • # Apache 1.3 bronsonisé

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

    Ça c'est du titre !

Suivre le flux des commentaires

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