Apache 2.0 stabiel verklaard

Op apachlabs.org is het heugelijke bericht te vinden dat Apache 2.0.35 is gereleased voor General Availability, de eerste Apache 2.0 die stabiel is verklaard. De Apache-software is de meest gebruikte webserver met een marktaandeel van 54%. Deze versie kent een hogere performance ten opzichte van 1.3, hybrid thread/process mode op elk platform welke ondersteuning biedt aan threads en processes, geïntegreerde SSL en WebDAV support, verbeterde ondersteuning voor HTTP proxy en I/O layering en filtering. Op de download-pagina zijn diverse distributies te vinden. Een overzicht van nieuwe features in Apache 2.0 vind je hier:

This version of Apache is known to work on many versions of Unix, BeOS, OS/2, Windows, and Netware. Because of many of the advancements in Apache 2.0, the initial release of Apache is expected to perform equally well on all supported platforms.

Wij danken rkrythe voor de tip.

Reacties (45)

[Verwijderd]

Stabiel he?

make[2]: Leaving directory `/root/httpd-2.0.35/support'
make[1]: Leaving directory `/root/httpd-2.0.35/support'
make[1]: Entering directory `/root/httpd-2.0.35'
make[1]: *** No rule to make target `modules/so/mod_so.la', needed by `httpd'. Stop.
make[1]: Leaving directory `/root/httpd-2.0.35'
make: *** [all-recursive] Error 1

compilen met --with-module=so is dus af te raden, ff kijken hoe ik dat nu met php ga oplossen

[Bert Grootje]

Standaard compilatie van Apache levert je module support op

./configure && make && make install

Resultaat komt in /urs/local/apache2/ dus je huidige installatie wordt niet overschreven, even op een andere poort zetten dan 80 en je kan rustig aan de boel migreren.

Voor PHP heb je de CVS versie nodig, 4.2.0RC2 werkt niet, en je moet naar Apache 2 verwijzen

./configure --with-apxs2=/usr/local/apache2/bin/apsx && make && make install

[froggie]

Ik wacht ook nog ff op de volgende 2.0 release, dan weet ik zeker dat ik zonder probs over kan gaan. 1.3 draait prima op het moment.

[Verwijderd]

Stabiel he?

De stabiliteit die genoemd wordt heeft betrekking op het runnen van de server, niet op het compileren.

[Verwijderd]

Cool, downloaden dus!

Apache was voor veel mensen altijd een beetje "eng" nog omdat het nog niet stabiel was verklaard.
Nu is de stap naar Apache een stuk kleiner geworden.

edit:
Ik heb het nu dus over Windows gebruikers

[Verwijderd]

Versie 1 is ooit stabiel verklaard. Anders kan je geen versie 1.0 hebben. De Versies 1.x die daarna kwamen waren inderdaad "not stable".

[jochemd]

Ik denk dat de engheid meer te maken heeft met de origine van de naam Apache, "a patchy server", als met het niet stabiel verklaard zijn

[^Mo^]

d'r is nog geen MSI installer.... die wordt echter wel binnenkort uitgebracht... hoop ik

[Verwijderd]

Ja dat is een soort feature van open source lijkt het wel, kom er geregeld tegen die in de instalaltie instructie zetten:

1. start de registry editor
2. doe enge dingen

Niet handig als je een groot publiek wil bereiken

[Verwijderd]

daarnaast kan Apache 2 ook in de kernel draaien wat nog meer snelheid oplevert (maar ook security risks... )

[tex5]

Kan niks vinden over dat ie in de kernel kan draaien op de site van Apache? Waar heb je die info vandaan?

[Verwijderd]

hmm je hebt gelijk, kan er nu ook niks meer over vinden... had dat een tijd geleden ergens gehoord/gelezen... misschien hebben ze het er toch maar uitgekicked ofzo...

[deadinspace]

Volgensmij hebben jullie het over de khttpd, de sterk experimentele kernelspace webserver. Uit de help van menuconfig:

CONFIG_KHTTPD:

The kernel httpd acceleration daemon (kHTTPd) is a (limited) webserver built into the kernel. It is limited since it can only serve files from the file system and cannot deal with executable content such as CGI scripts. Serving files is sped up if you use kHTTPd. If kHTTPd is not able to fulfill a request, it can transparently pass it through to a user space web server such as apache.
Saying "M" here builds the kHTTPd module; this is NOT enough to have a working kHTTPd. For safety reasons, the module has to be activated by doing a "echo 1 > /proc/sys/net/khttpd/start" after inserting the module.
Before using this, read the README in net/khttpd !
The kHTTPd is experimental. Be careful when using it on a production machine. Also note that kHTTPd doesn't support virtual servers yet.

Maar los daarvan is een webserver niet iets wat in de kernel hoort imho. De kernel vervult systeemtaken (dus dingen om het systeem draaiende te houden en om userspace programma's van resources te voorzien), en userspace programma's doen specifieke taken die mensen nodig hebben (zoals webpages serven).
Om nog maar niet te spreken over eventuele gevolgen voor stabiliteit en veiligheid (kbedoel, er is een reden dat je services, inclusief apache, als user draait, en niet als root. En al helemaal niet kernelspace.)

[arcadis]

Dat kon volgens mij via tux van Red Hat. Daarmee draait Apache direct 'in' de kernel. Is wel lastig te configureren trouwens.

[tex5]

Volgens mij is de "Tux" solution meer eentje als in dat dat Tux een front-end voor Apache is/wordt. Dus dat Tux alle hits handeld die die kan (static mostly dus) en als ie een connectie krijgt die die niet snapt dat ie die dan naar Apache stuurt.

Opzich leuk, maar nogal overdreven omslachtig. Apache vink zowiezo nogal omslachtig.

Net ff deze laatste versie getest, met het nieuwe worker thread systeem. Naja, nog steeds __xxx__ nr of processes en veel connecties kan ie ook niet aan (maxte net op 250/300 reqs/sec). Zeus draait er nog steeds rondjes omheen met _1_ process. Welke ook nog is een keer een _degelijke_ interface heeft.

Helaas, Apache is een mooi idee maar ze hadden voor deze versie 2 _iets_ beter naar de huidige concurrentie moeten kijken, ze lopen nu nog steeds ages achter.

"Who wants to control hundreds of children..."

[tex5]

depends! als je een "heavy hitting site" draait kan het heel erg slim zijn om je "static" content op een ander soort server te draaien dan Apache. Apache is er nou eenmaal niet goed voor (nogmaals, voor de "heavy hitting sites").

Een totally secured box met een kernel httpd (whatever brand) die _alleen_ static content served hoeft weinig security problemen op te leveren. De winsten anderzijds zijn _erg_ groot.

Maar opzich, een Zeus, die niet in kernel space draait doet het net zo goed als de "in kernel httpds" dus waarom zou je idd.

[odysseus]

Een totally secured box met een kernel httpd (whatever brand) die _alleen_ static content served hoeft weinig security problemen op te leveren. De winsten anderzijds zijn _erg_ groot.

De winsten van de in-kernel webservers (waarvan Tux en kHTTPd de bekendste zijn) zijn helemaal niet groot. Er zijn op de linux-kernel mailinglist een tijd geleden nogal wat posts over geweest en uiteindelijk bleek de snelheidswinst misschien iets van 2%, waarvan een deel ook nog eens kwam door het gebruik van efficiëntere code en niet door het feit dat het binnen de kernel draaide. De voordelen van het draaien in kernelspace worden vaak schromelijk overdreven.
Daarnaast weet je natuurlijk nooit of het securityproblemen oplevert, static of niet. Dat is nu net het hele probleem van securityproblemen...als 'heavy hitting site' ga je daar niet op gokken.
Stabiliteitsproblemen kan het wel opleveren. Wat ga je doen als dat ding een heleboel aanvragen te verwerken krijgt, waardoor je out-of-memory gaat? Voor normale programma's is er de OOM-killer, maar die kan geen kernelspace-processen afschieten. Het lijkt me niet de bedoeling dat een webserver een complete bak hard laat crashen. Daarnaast is het natuurlijk zoals deadinspace al zegt fundamenteel onjuist om een webserver in kernelspace te laten draaien.

* 786562 odysseus_

[LollieStick]

Hier ben ik het absoluut niet mee eens. Apache (2) heeft geen grafische interface omdat, omdat er zoveel functies in zitten, het alleen maar omslachtiger zal worden. Voor de basisfuncties zijn er vast wel grafische interfaces, maar niet als je alle functies wil gebruiken die er mogelijk zijn.

edit:

moest reactie zijn op TEX

[tex5]

reaktie op linuxuser; errr Zeus? Seriously, this is just as tunable as Apache and so so so so much faster/cleaner.

True dat niet alles onder de graphical interface zit bij Zeus maar toch, managing xxxx nr of servers is echt easier met Zeus, de standaard dingen zijn gewoon op een prof manier geregeld, getuned kan er onder de kap zonder teveel gekloot. Simpele tuneables. Ik snap dat een linuxuser dit niet kan betalen maar dat maakt niet dat het niet "beter" is. Zeus is beter dan Apache, simpel. Of je het kan betalen (uit kan) is een andere vraag...

Apache is misschien deep deep inside meer tuneable (mods etc, not performance) maar dan moet je wel echt hele gekke dingen doen wil dat ook niet met Zeus kunnen. Dingen waar 99% van de internet sites helemaal never nooit niet aan toe komen...

If you had the money what would you choose.. think about it. We lezen tweakers toch ook niet in een .cfg.

[tex5]

reaktie op odysseus_;

VS welke server waren die vergelijkingen, zeker niet vs Apache. 2% is onmogelijk. De kernel servers ala Tux zijn bijna even snel of even snel als Zeus. De andere servers die er zijn, evt. de simpele ala Boa etc halen de Tux/Zeus results never, laat staan Apache. Als de vergelijking vs Zeus was, ok ja.. maar Zeus heeft een prijs...

Security.. Tux bv. geef ik heel wat meer creditability kwa security dan de andere userspace simpele servers ala Boa. Boa is een erg simpel projectje, en zo zijn alle andere userspace servertjes besides Apache. Die zijn zeker niet meer secure dan bv. Tux. Dat het in kernel space draait wil nog niet zeggen dat de andere servertjes die in userspace draaien meer secure zijn.

Stabiliteit.. Geheugen problemen moeten never nooit niet voorkomen. Die komen _niet_ voor op een "heavy hitting site". Als die er wel komen is de admin niet pro en wordt er maar wat aangekloot. De bak plat of de webserver plat maakt niet uit voor het eindresultaat. De site is down, thats the issue. Thats the problem. Of je een simpele reboot moet doen of een userspace server op zijn klote geven maakt niet echt uit.

Waarom zou het fundamenteel onjuist zijn om een webserver (static webserver) in kernelspace te draaien? Omdat we _gewend_ zijn dat het niet zo "hoort"?? Gaan we nu ook al conservative worden op internet? Het netwerk stuff gebeurt toch ook in kernelspace? De packets versturen? Etc etc. Waarom een cache/static webserver ook niet. Een tcp pakketje of een .gif maakt echt niet veel uit.

De perfekte "static" webserver is een OSWebserver. Een OS dat alleen maar de benodigde stuff heeft om static content te serven. Wil je dat ook unsecure en onstabiel noemen? What about the hardcore caching servers? Daar zit echt geen linux of Solaris onder. Dat is pure en 100% dedicated to serving static content.

Ik zeg niet dat kernelspace servers IT are maar gezien de huidige server markt maakt het hier en daar soms best een overweging waard. Als je iets prof doet gebruikt je natuurlijk iets zoals Zeus ofzo.. ga je idd niet kloten. Maar verder, zie ik niet veel problemen met kernelspace servertjes. Zolang de userspace servertjes of heeeeel erg traag zijn (Apache) of heeeeeel erg vage developers/development hebben is een kernelspace server ala Tux zo gek nog niet.

Kijk naar spec.org. De webbenchmarks, welke servers gebruiken ze daar? Kweet het, ze doen het niet om de security, maar daar gaat het daar niet om. Kom jij boa tegen? Kom je apache tegen? Enige servers zijn IIS, Tux en Zeus. IIS omdat sommige nog NT willen promoten (worden waarschijnlijk betaald door MS ). De andere twee zijn dus fifty fifty tussen Tux en Zeus, eentje is kernelspace andere is userspace. De bedrijven die deze tests doen zijn geen kleintjes, dat er toch zoveel met Tux wordt getest geeft toch wat aan. Dat er niet met userspace servertjes ala boa wordt getest zegt natuurlijk ook wat.. die hebben geen performance. En waarschijnlijk nog minder vertrouwen.

[freaky]

Misschien dat je khttpd bedoeld (ik geloof dat ie zo heet) dat is een HTTP server (extremely basic tho') die in de kernel zit. Alle geavanceerdere stuff kun je doorsturen naar je gewone http service (zoals apache dus). Dit is echter niks nieuws :-)

[freaky]

Err... zou niet eens een grafische interface willen :-) misschien een front-end.... maar hou het toch liever bij m'n text filetje. Mijn servers hebben nl helemaal geen mogelijkheid tot een GUI (X is niet geinstalleerd) en dat wens ik zo te houden (minimum installatie, ruimte besparing, extra security, gaat zo maar door)

[freaky]

Vind die 250/300 hits van jou wel erg weinig hoor... Heb zelf nooit dat aantal hits maar ik heb van mensen die het veel doen veel hogere hit aantallen gehoord dan dat bietje......

[tex5]

Ik zei toch dat ik het ook weinig vond?! Maar opzich valt het wel mee hoor, 300reqs/sec is 18.000reqs/min is 25.920.000reqs/day. 25 mil hits per dag dus. Zoveel sites zijn er nou ook weer niet die dat halen hoor. Als je het ff doortrekt naar mbitjes.. stel je hebt als average 2kB per hit dan komt dit rond de 51840MB aan traffic per dag oftewel 4.8Mbit/sec.

Dat trekt Apache dus (depending on the hardware course), _maar_ het mindere is dus dat er dan _xxx_ nr of children op je server aan het spelen zijn. Dat is heel wat minder overzichtelijk dan 1tje!

Graphical interface bedoelde ik een web frond-end mee. Moet nog een webserver meemaken die alleen een X-GUI heeft

[Robin]

Ik denk dan een changelog wel interessant is

http://www.apache.org/dist/httpd/CHANGES_2.0

[Stephan Oudmaijer]

Ik heb hem gisteren nacht gecompiled en geinstalled op windows.. ik kan apache wel runnen maar niet als nt service.. erg irritant dus.. even wachten op de msi installer. tevens werkt mod_jk niet welke tomcat en apache aan elkaar verbind.

[update] alles werkt en ik heb de windows binary draaiend als nt service.

even een paar tips voor mensen die zelf Apache willen bouwen. Nodig:

visual studio 6 + sp5
awk95 (zoek in google, download rename naar awk en zet in windows system dir.)

en bouwen die setup
[/update]

[Robert Pape]

apt-get upgrade

[lintux]

Nou, da's dan eerder 'apt-get install apache2' oid, want Debian stopt Apache 2 voorlopig toch nog in een ander debje.

Trouwens, ik las vandaag op Debian-Devel-Announce dat de release van Woody op 1 mei verwacht wordt. Zow! Ziet er naar uit dat ik dan nog even aan de slag moet, mijn packages zijn nog niet helemaal ideaal..

[odysseus]

Nou, da's dan eerder 'apt-get install apache2' oid, want Debian stopt Apache 2 voorlopig toch nog in een ander debje.
Sterker nog, er zijn nog helemaal geen packages in Debian. Wel heeft er al iemand packages gemaakt die buiten de tree beheerd worden. Voor de geïnteresseerden, dit is de regel voor de sources.list:
deb http://pandora.debian.org/~thom/apache2 ./

Trouwens, ik las vandaag op Debian-Devel-Announce dat de release van Woody op 1 mei verwacht wordt. Zow! Ziet er naar uit dat ik dan nog even aan de slag moet, mijn packages zijn nog niet helemaal ideaal..
Dat is wel rijkelijk laat dan...we zitten al een eeuwigheid in freeze. Ik weet dat dat officieel nog alleen base was, maar om nu nog méér dan een enkele bugfix aan je package te moeten doen voor woody gereleased wordt...
Maar goed, eigenlijk mag ik niet te veel zeggen want ik ben (nog) geen Debian-developer, slechts een fanatiek gebruiker .

[lintux]

Dan heb ik te slordig gelezen op het kanaal, de boel is dus nog niet ge-upload.. :-/ Was eigenlijk de bedoeling dat dit een paar maanden geleden al gedaan zou worden (dan zeker apart), maar toen vonden ze het niet zo policy-compliant..

Mocht Apache2 Woody nog bereiken, dan weet ik erg zeker dat Apache 1.3 ook nog wel een tijdje blijft bestaan.

<offtopic mode=sorry>

> Maar goed, eigenlijk mag ik niet te veel zeggen want ik ben (nog) geen Debian-developer, slechts een fanatiek gebruiker

Kijk, dan mag je ook niet klagen.. >:-P Nah, er zat gewoon nog een vrij stomme bug in de upstream versie (rotix).. Gister ge-upload, dus dat moet nog wel goed komen.

Kan ik me weer gaan richten op andere dingen dan packages beheren..

</offtopic>

[Verwijderd]

Wanneer gaat T.net upgraden?

[CyeZ]

Not Found
The requested URL /bla/ was not found on this server.
-------------------------------------------------------------------------------
Apache/1.3.22 Server at www.tweakers.net Port 80

Ze zijn in ieder geval nog niet geupdate.
Maar ik denk ook dat de meeste bedrijven niet meteen zullen upgraden, die zullen de nieuw 2.0 branch waarschijnlijk eerst een tijdje op interne testservers laten draaien of te kijken of het ook stabiel blijft in combinatie met alle andere software die zo'n bedrijf heeft lopen.

[LollieStick]

Dat zal denk ik nog wel even duren. Deze is net stabiel verklaard, dus met stabiliteit zal het wel goed zitten, maar ik denk dat de veiligheid nog wel wat te wensen over laat.

* 786562 linuxuser

[Firefox]

punt is, heb je het nodig?

Sofar werkt 1.3.x betrouwbaar, is uitontwikkeld, en biedt tot nu toe alles wat TN nodig heeft.

waarom zou je upgraden? Zelf ga ik denk ik wel wat eerste tests draaien, maar dan idd vanuit een aparte dir op een aparte poort.

[itris]

omdat het sneller is en minder geheugen kost.

en hopelijk (ik heb er nog niet naar gekeken) is het ook makkelijker managable en beter/makkelijker te configureren.

Vooral voor drukke servers is dat van belang, die kunnen een klein beetje extra geheugen besparing goed gebruiken.

[ACM]

En firefox geeft inderdaad de redenen al.

Ten eerste is php nog niet (goed?) te compileren voor deze apache.
Ten tweede is dit de eerste "stabiel verklaarde" versie van deze apache branch.
Ten derde zijn er maar weinig praktijk voorbeelden van sites die goed blijken te draaien erop (ik zeg niet dat het niet goed draait, maar er is nog geen/weinig bewijs van).

omdat het sneller is en minder geheugen kost.

Dat is maar relatief. Uiteraard is het sneller, maar geen perfecte integratie met een stabiele php-module is voor T.net funest.
Een reactie een stuk omhoog legt al uit dat php alleen te compileren is met een CVS versie...

Vooral voor drukke servers is dat van belang, die kunnen een klein beetje extra geheugen besparing goed gebruiken.

Dat is zeker waar, maar dan moet het wel gegarandeerd net zo stabiel lopen als apache1.3 al zeker sinds 1.3.12 doet.

[mr_a]

Ik vind het supermooi dat het nu volgens de docs goed werkt op NetWare. Ik heb nog nooit zo'n instabiele zooi meegemaakt als de Netscape Fasttrack server op NW4.11, daar was ik echt niet van overtuigd. Ook Netscape Enterprise 3 op NetWare 5.0 zijn ook allerlei nare dingen fucked up... je kon precies 0 fouten maken in een configfile, als je ergens al een entertje teveel inserte dan was het wachten op *clang* *BOEM* ABEND...
Kon je naar de serverruimte lopen om de server hardhandig uit te zetten want de hele TCP/IP stack van de machine was gaar dus hij werkte niet echt meer. .

Maar dus eens kijken hoe deze werkt, Apache is toch een stuk prettiger webserver!

[Verwijderd]

Waarom stap je niet over op Linux ?

En als authenticatie tegen NDS belangrijk voor je is kan dat volgens mij met zg. PAM/LDAP modules.

[mr_a]

En als authenticatie tegen NDS belangrijk voor je is kan dat volgens mij met zg. PAM/LDAP modules.

En clear text passwords? neu dank u!

[jvreuls]

Hij is echt uit het beta-stadium? Dat is dan idd echt goed nieuws, want op de 2.0 zaten we al een hele tijd te wachten (niet dat 1.3 zo slecht was ).

[Verwijderd]

lekker, maandag maar even apache2 op mn develbak zetten dus

ik meende dat het ook al opschoot met mysql (4 nog steeds in alpha/beta ), en zend is nog flink bezig met hun zend2 engine (dat is dan dus php5). Ik sense een goed jaar voor alle PHP'ers ( en een hoop manual gelees dus weer )