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 Julien04 (site web personnel) . Évalué à 4.
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 Joris Dedieu (site web personnel) . Évalué à 2.
Les mêmes causes ont les mêmes effets. Dur de dire au clients, demain vos .htaccess ne marchent plus.
[^] # Re: nginx ?
Posté par pouille . Évalué à 2.
http://wiki.nginx.org/Main
[^] # Re: nginx ?
Posté par Fabien . Évalué à 5.
- 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 windu.2b . Évalué à 10.
[^] # Re: Une belle fin...
Posté par zebra3 . Évalué à 2.
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 Mr Kapouik (site web personnel) . Évalué à 4.
$ 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 Joris Dedieu (site web personnel) . Évalué à 1.
$ 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 Mr Kapouik (site web personnel) . Évalué à 4.
# /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 yannig (site web personnel) . Évalué à 2.
# ./httpd -v
Server version: Apache/1.3.12 (Unix)
Server built: Apr 8 2002 16:32:11
[^] # Re: Comprend pas ...
Posté par Charles KOPROWSKI (site web personnel) . Évalué à 6.
bash-2.02# /usr/local/apache/bin/httpd -v
Server version: Apache/1.3.0 (Unix)
Server built: Jul 11 1998 20:30:20
[^] # Re: Comprend pas ...
Posté par patrick_g (site web personnel) . Évalué à 6.
>>> 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 ?
[^] # Re: Comprend pas ...
Posté par Nicolas Bernard (site web personnel) . Évalué à 3.
[^] # Re: Comprend pas ...
Posté par herodiade . Évalué à 4.
Theo en parle un brin ici :
http://archives.neohapsis.com/archives/openbsd/2004-06/0477.(...)
Mais d'autres raisons semblent avoir motivé (ou catalysé) le forkage assumé :
- Ils maintenait déjà à cette époque une version largement divergente. Voir par ex:
http://archives.neohapsis.com/archives/openbsd/2004-06/0490.(...)
http://archives.neohapsis.com/archives/openbsd/2004-06/1739.(...)
- Le code d'apache était considéré par certains développeurs OpenBSD comme difficile à auditer du fait des couches d'abstractions que le logiciel utilisait systématiquement pour assurer sa portabilité sur des OS exotiques (type win32, Netware, OS/2 & co).
Les mois qui ont suivi l'annonce du point de non-retour ont d'ailleurs été l'occasion d'une simplification radicale du code d'apache dans le CVS d'OpenBSD (sous l'égide d'Henning Brauer - le mainteneur d'OpenBGPD et l'un des principaux contributeurs de pf).
# Cherokee
Posté par Ririsoft . Évalué à 2.
http://www.cherokee-project.com/
# CommonLisp
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
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 Matthieu . Évalué à 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 2PetitsVerres . Évalué à 2.
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 dems . Évalué à 1.
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 sheldoncooper . Évalué à 3.
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 Matthieu . Évalué à 1.
[^] # Re: apache 1.3 et apache 2.2
Posté par sheldoncooper . Évalué à 1.
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 Joris Dedieu (site web personnel) . Évalué à 1.
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 Sufflope (site web personnel) . Évalué à 2.
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 liberforce (site web personnel) . Évalué à 6.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.