Importálta az OpenBSD a nginx webszervert a forrásfájába

OpenBSD

Aki régebb óta használja az OpenBSD-t, vagy régebb óta követi annak fejlesztését, az tudhatja, hogy a projekt saját Apache 1.3 forkot tart karban az OpenBSD operációs rendszer forrásfájában (src). Ennek az az oka, hogy az OpenBSD projekt elfogadhatatlannak tartja az "új" Apache licencet (Apache License, Version 2.0). 2004-ben Theo de Raadt kijelentette, hogy ezen licenc alatt kiadott kódok sosem kerülnek be az OpenBSD forrásfába. Így történt, hogy az OpenBSD projekt maradt az Apache 1.3-nál.

Az idők során a projekt számos funkcióval bővítette a saját Apache forkját, például az OpenBSD hozzáadta az IPv6 támogatást. Az erősen patchelt Apache 1.3 eddig jól szolgált, de most megkezdődött a leváltása egy korszerűbb, aktívan fejlesztett, BSD licences webszerverre.

A munka még az elején tart. Nagy Róbert (robert@) a napokban importálta az OpenBSD forrásfájában az nginx 1.0.6-os verzióját. Egyelőre nincs linkelve, így fordításkor nem fordul. Az import célja az, hogy a fejlesztők a forrásfában dolgozhassanak rajta. Róbert megerősítette, hogy a végső cél az, hogy az Apache kikerüljön az OpenBSD forrásfájából és az nginx vegye át annak a helyét.

( suckit | 2011. 09. 25., v – 09:48 )

fejleszthetnenek hozza egy kompatibilitasi modult, amely a leheto legtobb apache legacy cuccot mukodokepesen tartja (pld htaccess, amit eleg sok minden hasznal)
--
zsebHUP-ot használok!

De, artana. A userek csak ne vezereljek a webszervert, vagy vegyenek vps-t ha maguk akarjak uzemeltetni az oldalt. A legtobb ertelmes PHP framework az errordocument-es megoldast is tudja, a tobbi meg igazabol hidegen hagy.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Problem az, hogy user jon, kedvenc PHP-s cucca (amit altalaban persze nem o irt), aztan akarja a .htaccess-t, benne rewrite rule-okkal, errordocument-ekkel, stb stb stb. Es gyakran kiderul, a "webhosting" alatt o "apache httpd hosting"-ot ert (az szamara nem kielegito valasz, hogy mas webszerver is letezik, es a termek neveben nem szerepelt pl az apache sem), vagy hasonlo ...

Sőt, általában nem ért alatta semmit se, csak azt nem érti, hogy miért nem megy az appja. És nem érdekli, hogy mit makog a hosting cég az apacsiról meg az endzsinkszről, hanem átmegy oda, ahol megy az oldala - és nem is kerül többe.

És mellesleg igaza van, nem az Ő dolga, hanem a fejlesztőké, hogy megoldják, hogy az alkalmazás ne csak apache alatt menjen.

A userek csak azt vezérlik hova pakolják a pénzük a szolgáltatásért, azt már te döntöd el kell a pénzük vagy sem. Ha nginx alatt nem fog menni az oldaluk, majd mennek máshova a pénzükkel, mindig lesz apache-ot használó cég. Tehát vagy az nginx oldja meg (a hozzászólások alapján nem fogja), vagy csinálnak valami konvertert (hasonlóról mintha olvastam volna az nginx listán), vagy a fejlesztők foglalkoznak az nginx résszel. De amíg az nginx nyolcada az apache-nak a netcraft szerint, addig szerintem a fejlesztők tesznek az nginx-re. Használtam az nginx-et sokáig, jó cucc, de volt ami nem tetszett, így átléptem a hiawatha programra.

+1
Az nginx készítői pedig azt mondják, hogy ha kell htaccess, akkor valamit rosszul csinálsz... Sose nem is lesz. Amivel tegyük fel, hogy egyetértek, de ezt magyarázzák el a szarabbnál szarabb oldalak, portálmotorok, webáruház motorok készítőinek is. Amik miatt még sokszor a biztonsági beállításokon is engedni kell, mert nem megy.
--
Discover It - Have a lot of fun!

Ez azt jelenti, hogy ha egy lecsupaszitott - ezerfele ficsortol megszabaditott - Apacheot forgatok az lassabb lesz az nginxnel?

A biztonsag teren nem tartod jonak az Apache-ot? A nemregi mod_header bugtol eltekintve nem volt tul sok security bug benne (@core), ami nem kis eredmeny a vilag legtamadottabb webszerveretol.

Ha az apacs es az nginx alap architekturajat es core code meretet osszehasonlitod, akkor eleg valoszinu. Plusz a kodbazis meretevel no a valoszinusege egy sebezhetosegnek is, az h nem hallottal ujabbrol mostanaban az nem jelenti azt, h a fekete piacon peldaul nincs jelen egy 0day formajaban. :)

---
pontscho / fresh!mindworkz

Jaja ezzel tisztaban vagyok, hogy a piacon lehet 0day bug elado. Futolag megneztem, hogy milyen jellegu bugok voltak nginxben es az apacheban az elmult ~2 evben es a benyomasom az volt, hogy lehet, hogy bar tobb a bug a Apacheban de az nginxben sulyosabb hibak voltak (pl directory traversal).

Köszi szépen! Gyakorlatilag az a bajuk, hogy minden request-nél beolvassa a .htaccess állomány(oka)t az apache és ettől lassú lesz. Ezzel szemben az nginx a rewrite dolgait a conf állományban tárolja amit induláskor beolvas, így gyors lesz, már ha ezen az utóbbi fél évben nem változtattak (nginx 0.9 branch elején foglalkoztam vele utoljára).

Nem tudom, hova tegyem, ide irom:

Azert mondjuk ha nagyon akarom, megoldhato, hogy legyen custom konfigra lehetoseg.
Egyszer meg lehet azt csinalni, hogy csinalok egy include fajlt a webgyokerbe, mondjuk .ngaccess fajlnevvel, es beinclude-olom a konfigban, masreszt az egyszerubb rewrite rule-okat le lehet forditani az nginx formatumara is.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Az include oké, csak az apache-nál a webszerver piszkálása nélkül tudod finomítani a htaccess-t, hisz minden kérésnél újra beolvassa a webszerver, míg ezzel a módszerrel az nginx esetén nem megoldható, az induláskor egyszer beolvassa és a szerver piszkálása nélkül nem olvassa újra. De értem a lényegét miért nem szeretik a htaccess-t.

( wladek1 | 2011. 09. 25., v – 13:11 )

Vajon mikor lesz az, amikor vegulis meg is elozi az apacsot az nginx; pl egy netcraft grafikonon?

A ket problema, ami az nginx -et erinti:
-rewrite ruleok es az alap htpasswd nem kompatibilis az apaccsal
-rewrite ruleok felvetelenel reloadolni kell (nincs allowoverride, meg hasonlo); viszont igy nem statol be egy 300 byteos gif -ért egy komplett path -ot; .htaccess -t keresve.
Ezt az r=1 phppistikék nem fogják megérteni (általában ilyen userek hasznalnak .htaccess -t a seobarat urljeikhez, mert keptelenek pl php -n belul routingot hasznalni).

Magam reszerol mast legalabbis nem tapasztaltam...
Megsem: Neha tul megengedo a config fajl szintaxisaival kapcsolatban. server_name nincs lezarva pl, akkor siman felveszi a kovetkezo sort is, amennyiben az szintaktikailag megfelel; szo nelkul, de pl. a gzip types vs. mime types kontextben mar loki a warningot, hogy duplicate mime type, etc.

De ezek apro bugok, amik mellett legalabb kenytelen vagy megtanulni normalisan a szintaxist, ami abszolute nem nehez.