Több mint hat év után új "major" Apache HTTP Server kiadással állt elő az ASF

 ( trey | 2012. február 21., kedd - 17:30 )

Az Apache Software Foundation ma bejelentette, hogy kiadta az Apache HTTP Server 2.4-es kiadását. Az 1996. áprilisa óta az internet No. 1 webszerverének számító Apache HTTP Server éppen 17. születésnapját ünnepli. Az ASF utoljára 2005. december 1-én jelentkezett "major" HTTP Server kiadással, mikor is elérhetővé tette a 2.2-es verziót. Újdonságok a 2.4-es kiadásban:

  • Improved performance (lower resource utilization and better concurrency)
  • Reduced memory usage
  • Asyncronous I/O support
  • Dynamic reverse proxy configuration
  • Performance on par, or better, than pure event-driven Web servers
  • More granular timeout and rate/resource limiting capability
  • More finely-tuned caching support, tailored for high traffic servers and proxies.

A bejelentés elolvasható itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Oszt' különböző UID/GID-del futó virtuális hosztok meg nincsenek?!

Nincs, de van rá peccs ;).

Melyikre gondolsz?

Jó, nem peccs, hanem 3rd party megoldások.

mod_ruid2-t használok, de nem az egyedüli.

Én az ITK MPM-et használom, mert a mod_php-t is támogatja, nem csak a CGI típusú végrehajtást. Sajnos alapvető problémák vannak vele, amiket ugyan sikerült áthidalni, de azért jó lenne, he rendesen meg lenne csinálva.

Ez is mod_php-s. Nekem nem volt bajom vele, de nem is akartam tőle sokat :). Próbáld ki.

En is ezt hasznalom, de eddig nem volt vele gondom.
Erdekelne, hogy nalad mi jott ki?

Na, szóval az a helyzet, hogy az AssignUserId direktívát ki lehet adni virtuális hosztonként, de akár könyvtáranként is. Ha egy adott virtuális hoszt különböző könyvtárait vagy akár egy adott IP-cím különböző (természetesen név alapú) virtuálist hosztjait különböző uid-de vgy gid-del futtatjuk, és egymás után akarjuk ugyanazon a tcp kapcsolaton keresztül elérni, akkor az első setuid után a privilégiumát vesztett http processz nem tud újból usert váltani, és ahelyett, hogy mondjuk tcp reset-tel lezárná a kapcsolatot, 403/forbidden üzenetet ad vissza. Sokat leveleztem erről a fejlesztővel, Steinar H. Gundersonnal, aki azt hitte, hogy megoldotta a problémát, de kiderült hogy mégsem, és bár alapos átszervezéssel tökéletesen meg lehetne oldani ezt az uid/gid ügyet, de biztos, hogy nem fog ennyi energiát belefektetni. Az összes általam kipróbált webböngésző szerencsére olyan hülye, hogy minden új hosztra irányuló kérést új tcp kapcsolaton indít (akkor is, ha az IP cím nem változott közben), ezért a sima titkosítatlan név alapú virtuális hosztok még működnek a jelenlegi körülmények között.

Van azonban egy webszerver, amin kb. 50-60 virtuális weboldalt üzemeltetek, és ezek közül néhány ssl titkosítást igényel. Mivel sem IP címekből, sem tanúsítványokra költhető pénzből nem végtelen a keret, az ssl-es oldalakat név alapú virtuális hosztokon működő átirányításokkal oldom meg a következőképpen:

http://a.intezmeny.hu -> https://www.intezmeny.hu/a
http://b.intezmeny.hu -> https://www.intezmeny.hu/b
http://c.intezmeny.hu -> https://www.intezmeny.hu/c
stb.

Itt ugye az a helyzet, hogy egy ssl-es virtuális hosztot futtat az apache, de az alkönyvtárak/location-ök különböző uid/gid alatt futnak. Mivel tehát az ssl vhost esetében a különböző uid/gid alatti területek azonos név alapú virtuális hoszton vannak, a bamba böngészők rájönnek, hogy új tcp kapcsolat nyitása nélkül lehet ugrani egyikről a másikra, az itk mpm pedig ahelyett, hogy rájönne, hogy képtelen az egyik sima felhasználóról a másikra váltani, és lezárná a tcp kapcsolatot, megpróbál nekifutni a dolognak, de mivel nem éri el az új könyvtát, helytelenül 403/forbidden lesz az eredmény. Persze egy reload a böngészőn megoldhatja a dolgot, de addigra a felhasználó már azt hiszi, nem léezik a tartalom. A legbosszantóbb az egészben, hogy az itk tudja, hogy nem tud váltani, és nem is a tartalom beolvasásán vérzik el, hanem korábban, a .htaccess fájlok végigpásztázásán. Ha jól emlékszem AllowOverride none könyvtárak esetében nem is jelentkezik a probléma, mert a .htaccess-ek olvasása (sőt, lehet, hogy csak stat-elése) utáni fázisban már rájön az itk, hogy nem fog menni a váltás, és zárja a tcp kapcsolatot, majd kilép.

Először két megoldás kínálkozott:

-KeepAlive Off az érintett virtuális hosztokon (MINDEN név alapú virtuális hoszt érintett lenne, ha a böngészők nem lennének ilyen bambák). Ez a módszer túl nagy teljesítényveszteséggel jár.

-A teljes tartalom legyen world readable. Nem elég, ha a wwwrun tudja olvasni, hanem a véletlenszerű uid/gid váltások miatt mindenkinek kellene. Na, ez már tényleg no comment.

Végül mod_proxy segítságável oldottam meg az ilyen kényes helyzeteket, amivel viszont az a baj, hogy a backend virtuális szerverek, nem látják, milyen IP címről jött eredetileg a kérés, így nem működik az ip alapú hozzáférésvezérlés (allow from/deny from, stb.) Az X-Forwarded-For HTTP fejléc alapján történő változóállítgatások segítségével ugyan mégis kivitelezhető az ip alapú hozzáférésvezérlés, de csak a az apache szerver számára. A php és egyéb dinamikus tartalmak persze nem úgy látják a kliens ip címét, ahogy várják, tehát nem tökéletes ez a megoldás sem.

Sőt, már majdnem annyira bonyolult, mint az apache hivatalos megoldási javaslata a problémára, miszerint minden különböző uid/gid alatt futtatandó tartalmat külön szerverpéldánynak kell kiszolgálnia, és a példányok esetleg mod_proxy segítségével futhatnak látszólag azonos ip címen és porton. Mindössze annyival egyszerűbb az általam kidolgozott itk alapú megoldás, hogy csak egy szerverpéldány van. Hátránya viszont, hogy amint lesz olyan webböngésző, ami akkor is képes lesz az azonos ip cím/port páron levő tartalmakat ugyanazon a tcp kapcsolaton keresztül lekérni, ha más hosztnév alatt vannak, akkor bukik az egész rendszer az itk-val egyetemben.

...Van azonban egy webszerver, amin kb. 50-60 virtuális weboldalt üzemeltetek, és ezek közül néhány ssl titkosítást igényel. Mivel sem IP címekből, sem tanúsítványokra költhető pénzből nem végtelen a keret,...

Ajanlom figyelmedbe az SNi-t amit mar minden modern bongeszo tamogat :)

http://en.wikipedia.org/wiki/Server_Name_Indication

Hopp, erről nem is tudtam. Szuper. Köszi.

IE is?

http://en.wikipedia.org/wiki/Server_Name_Indication#No_support írta:
The following combinations do not support SNI:
Client side
* Internet Explorer (any version) on Windows XP
* Safari on Windows XP
* wget[22]as of 2011 has a patch available.
* BlackBerry Browser
* Windows Mobile up to 6.5[23]
* Android default browser on Android 2.x[24] (Fixed in Honeycomb for tablets, targeted for Ice Cream Sandwich for phones)

Ne feledd, XP-ből van még a legtöbb manapság.

Jaja ezt tudom, ez az egyetlen hatranya jelenleg. A kollegat akartam felvilagositani arrol hogy mar nem feltetlenul szivas tobb ssles vhostot csinalni.

az tény.

En inkabb egy wildcard certificate-et javaslok

tompos

De az is csak NSI-vel kombinálva éri el a tökéletes hatást, nem? Csak, hát az a baj, hogy - amint a fentiekből kitűnik - az NSI-t jelenleg nem lehet a gyakorlatban használni.

Nem.

tompos

Mi nem?

Erre valaszoltam:

"De az is csak NSI-vel kombinálva éri el a tökéletes hatást, nem?"

Vagy itt arra gonfolsz, h kulonbozo domaineket felvenni? Akkor akar igy is lehetne. De lehet UCC-t is igenyelni, akar a netlock-tol is. Ebb azert eleg sok wildcard certificate belefer.

A wildcard-nak van egyebkent korlata is, amire erdemes figyelni. Csak 1 szintig ervenyes, tehat a *.aaa.hu nem ervenyes a blabla.ize.aaa.hu-ra.

udv,
tompos

Én meg arra gondoltam, hogy NSI nélkül nem lehet ugyanannak az IP címnek ugyanazon portján több SSL vhostot futtatni, tehát az IP címek véges voltát nem küszöböli ki önmagában a wildcard tanúsítvány, csak NSI-vel együtt.

De igen, ez a lenyeg, h lehet.
Ha egy azonos (vagy UCC eseten veges szamu, de tobb) domain ala tartoznak.

tompos

Én meg arra gondoltam, hogy NSI nélkül nem lehet ugyanannak az IP címnek ugyanazon portján több SSL vhostot futtatni, tehát az IP címek véges voltát nem küszöböli ki önmagában a wildcard tanúsítvány, csak NSI-vel együtt.

Van az
a.domain.hu
b.domain.hu
c.domain.hu
mind ugyanazon az IP címen, rajta egy darab SSL porton egy darab SSL certtel figyelő apache, a cert CN=*.domain.hu névre kiállítva; na ez így működik.

Csak egy fix: SNI mint SNItt.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

mod_rpaf-fal sem azt latjak a belso apache-ok?

> Ha egy adott virtuális hoszt különböző könyvtárait vagy akár egy adott IP-cím különböző
> (természetesen név alapú) virtuálist hosztjait különböző uid-de vgy gid-del futtatjuk, és
> egymás után akarjuk ugyanazon a tcp kapcsolaton keresztül elérni, akkor az első setuid után > a privilégiumát vesztett http processz nem tud újból usert váltani, és ahelyett, hogy
> mondjuk tcp reset-tel lezárná a kapcsolatot, 403/forbidden üzenetet ad vissza. Sokat
> leveleztem erről a fejlesztővel, Steinar H. Gundersonnal, aki azt hitte, hogy megoldotta a
> problémát, de kiderült hogy mégsem, és bár alapos átszervezéssel tökéletesen meg lehetne
> oldani ezt az uid/gid ügyet, de biztos, hogy nem fog ennyi energiát belefektetni.

Azt nem sikerult megoldania, hogy ha vhost valtas, azaz uid valtas van, akkor reset-elje a kapcsolatot?

Ennyi benazas utan miert eri meg megis hasznalni?

t

> Ennyi benazas utan miert eri meg megis hasznalni?

Azért, mert gyors, és még mindig egyszerűbb, mintha minden vhost-nak külön szerverpéldányt indítanék.

> mod_rpaf-fal sem azt latjak a belso apache-ok?

Amilyen hülye vagyok, a mod_rpaf-ról sem hallottam, pedig ez már tényleg tökéletessé tudná tenni az elrendezést. Lehet, hogy kipróbálom. Köszi.

De persze a legjobb az lenne, ha az apache OOB támogatná a hosztonkénti uid/gid-et. Miért nem tudják megcsinálni?!?!?!?!

Végül mod_proxy segítságável oldottam meg az ilyen kényes helyzeteket, amivel viszont az a baj, hogy a backend virtuális szerverek, nem látják, milyen IP címről jött eredetileg a kérés, így nem működik az ip alapú hozzáférésvezérlés (allow from/deny from, stb.) Az X-Forwarded-For HTTP fejléc alapján történő változóállítgatások segítségével ugyan mégis kivitelezhető az ip alapú hozzáférésvezérlés, de csak a az apache szerver számára. A php és egyéb dinamikus tartalmak persze nem úgy látják a kliens ip címét, ahogy várják, tehát nem tökéletes ez a megoldás sem.

Ez talán pont ezt tudja, amit szeretnél:
http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html

Engem is érdekelnének, hogy milyen problémákat tapasztaltál.

Támadt egy érdekes ötletem az itk-s webszerver beüzemelése közben:

Eredetileg minden (virtuális hosztot birtokló) felhasználó ugyanabban a csoportban (users) volt, és at itk FELHASZNÁLÓNÉV:users uid/gid párral futott. A felhasználók home könyvtárain 700 jogosultság volt, hogy ne tudjon egy - mondjuk - rosszindulatú felhasználó átnézegetni egy php paranccsal egy másik felhasználó home könyvtárába az azonos csoporttagsá (users) segítségével.

Később viszont átalakítottam a rendszert minden felhasználó külön - a saját loginnevével megegyező nevű - csoportba került, az itk pedig wwwrun:FELHASZNÁLÓNÉV uid/gid párossal fut. A felhasználói könyvtárakba nem uid, hanem gid alapján engedem be az apache-ot, így továbbra sem tudnak belepofátlankodni egymás könyvtárába, sőt, a saját tartalmukat is csak olvasni tudja a webszerver, mindaddig, amíg nem adnak rá chmod g+w jogot. Így tehát nem csak egymástól, hanem saját maguktól is nagyobb biztonságban vannak a virtuális hosztok tartalmai. Korábban posix acl-ek kiterjedt használatával is próbálkoztam, de a böszme portálmotorok az acl-ekkel nem törődve (vagy azokról nem tudva) stat függvény segítségével nézik, hogy mit tudnak olvasni meg írni, aztán rá-chmod-olnak, átírva a csoportjogosultságot is, ami acl-ek használatakor nem is azt jelenti, amit eredetileg, hanem maszkként funkcionál, szóval összezavarodik minden. Az acl-ekkel tehát csak a gond van ( http://gabucino.be/files/eb7c161dff4203e57934760560517088-102.html ), jobb visszanyúlni a gyökerekhez.

Jelenleg en a te elso megoldasoddal probalkozok, /var/www/domain.com/htdocs, ebbol a domain.com root-owned 0755, hogy a chroot-os sftp ne sirankozzon, a htdocs meg 700-as jogu USER:www owned, hogy senki ne lathasson bele. Egyetlen korlat, hogy a gyokerbe nem tudnak fajlokat feltolteni/letrehozni, igy ha kell, csinalunk oda egy masik mappat, ahova lehet feltolni a cuccokat.

Az SFTP azert valt be, mert igy nincs problema az elfelejtett jelszavakkal. Nem mondom, hogy nem kell neha bitszintig lemenve magyarazni, hogy hogyan lesz oneki privat meg publikus kulcsa, viszont az csak egyszer gond, vegig kell vezetni a winscp beallitasat, utana nincs gond veluk. Ja, es meg biztonsagos is.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Állítólag teljesítményben nagyon sokat javult.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Rá is fért :]

rossz helyre írtam

+1
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/