MASS hosting podle mě

6.8.2007 02:53 | Přečteno: 2027× | Linux |

Před půl rokem jsem měl nápad vytvořit jednu aplikaci, ve které by šli naklikat weby. No naklikat zatím nejdou, ale vznikla solidní knihovna, ve které se dá web velmi rychle napsat. To přineslo i požadavek rozjet server, a aby se server zaplatil, tak to chce ho i s někym sdílnout. Celé jsem to postavil na lighttpd, protože mi je tento server velmi sympatický. Problém je, že lighty a mass hosting nejdou moc dohromady a tak si člověk musí trochu pomoct.

Lighttpd je lehký, rychlý, prý i bezpečný a flexibilní webový server. Používá ho například youtube nebo mininova. Svoje kvality na poli "jednoslužbových" strojů dokázal, stejně tak je možné ho používat pro účely uzavřené skupinky lidí, kteří si věří (rodina, malá komunitní síť) nebo se hodí taky na projekty, kde neznámí lidé nemají přístup ke scriptům, protože lighty může běžet pouze pod jedním userem a tak nejdou nastavit práva.

Ale k těm méně šťastným věcem. Konfigurace lighty je velmi flexibilní. Konfigurák nebo jeho část může být výsledem skriptu, je možno nastavit jednoduše rewrite proavidla, mod_redirect funguje též bezvadně a jednoduše a všechno lze hezky zpodmínkovat (nemluvě o hromádce dalších modulů). Také tu je proměnná server.chroot, která spustí server v chrootu. Na první pohled oko webhostera zaplesá, na druhý zjistí, že tato proměnná je "globální", a tak když ji hodíme do podmínky kde je nějaký host, tak se prostě použije nezávisle na té podmínce. To byla před týdnem rána, protože jsem měl napsanou kupku scriptů pro lighty, který by mě teď byly k ničemu. V zoufalství jsem zkoušel i apache, ale jeho konfigurace mi přišla hrozně těžkopádná a nepřímočará, narozdíl od lighty. Apache jsem používal dřív na desktopu a notebooku pro pracovní účely, ale nastavovat něco pro mě je rozdíl od nastavování něčeho pro hromadu lidí pokud chce člověk aspoň trochu klidně spát.

Tento bug či featura je zapsán v bugtrackeru již 2 roky a ani lighty 1.5 nic takového neřeší. Nastavení uživatele, pod kterým je server spušten je též globální a tak ani toto řešení neprojde. Poslední možností je použít mod_proxy. Debian má jednu moc šikovnou utilitku jailer. Ten vytvoří miniroot z debianích balíčků i s jejich závlostmi, a tak máme jen to co potřebujeme. Zminimalizoval jsem si root a jal se testování. Všechno proběhlo ok. Vytvořil jsem miniroot s pythonem, phpkem a pár pythoníma modulama (85MB) a nad tim spustil lighty v chrootu na portu 28001. V lightym na 80tym portu jsem nastavil mod_proxy. Všechno funguje ok a script se ze vnitř nemůže dostat. Všechno jsem ještě pojistil pomocí striktních práv a teď můžu říct, že mám funkční bezpečné řešení na základě lighttpd s vynikající možností škálování služeb. Resp pokud bude někdo potřebovat někde něco speciálního, mám možnost mu to nabídnout aniž bych se musel obávat bezpečnostího rizika, které je u řešení se suphp, právy a podobnými věcmi mnohem větší. PHP nemusí běhat v safemodu a můžu v pohodě pustit pythona, perl, ruby nebo i bash pod CGI.

Tohle řešení vyžadovalo napsat scripty pro startování dalších lightyů, sledování stavu lightyů a generování minirootů z databáze. V databázi je tak uloženo co má user za balíčky a miniroot se z toho může vygenerovat klidně znova a bude stačit zálohovat jen data.

A teď to horší. Každý si asi uvědomil, že to je trochu víc žravější na prostředky než jiná řešení. Určitě se to co tu navrhuju nehodí na hosting, kde bude 10000 domén na jeden stroj, ale pokud má člověk nějakých 50 userů, tak každý z nich má k dispozici luxusní možnosti, za které určitě zaplatí tolik, aby se zaplatil stroj i nějakými bonusy na stroj další. Lighty sám pamět moc nebere a když nastartuje zabírá asi 1.5MB ramky. Miniroot má jak jsem psal 85MB, když se okleští. Pokud lighty běží déle, tak se trochu rozroste, ale není to o moc. Když dnešní servery mají několik GB RAM a stovky GB disky tak nějakejch pár MB je nerozhodí a myslím si, že to za to stojí.

       

Komentáře

[Joseph]

pekne. mozno by to chcelo napisat aj nejaku tu pripadovu studiu. ale je to rozhodne zaujimave riesenie.

[Creckx]

Není to tak úplně celé moje. Našel jsem něco podobného na jedné wiki (link teď nemůžu jako na potvoru najít). Tam pro každýho hosta udělali lokální IP a na to nahodili apache. Já to zjednodušil a nahodil na lighty :) Určitě dám vědět jak to funguje v praxi.

[Daniel Kvasnička ml.]

Co koukam do tveho SVNka, tak Pyweb stale jede na mod_pythonu. Jak to jde dohromady s Lighty?

[Creckx]

ee... možná tam nějakej import z apachích knihoven zůstal, ale jen u nepoužívanejch souborů, jinak je všechno na CGI.

[David Jaša]

Ten chroot/jail je pro všechny ligthty za proxy společný?

[Creckx]

Ne, každý má svůj.

[Messa]

Je ten chroot nutný, pokud uživatel opravdu nemá nějaké speciální požadavky na balíčky nebo nastavení? Také koketuji s myšlenkou pořídit si server (jeden virtuální už mám), ale překvapuje mě, že skoro žádný hosting (ani ty dražší) uživateli nenabídne plný přístup, tedy systémový účet, ssh apod.. To je to nějak nebezpečné nebo jinak nevhodné? Tedy já žádný velký hosting provozovat nehodlám, ale když už u mě bude mít web těch pár známých, je důvod proč jim nedat přístup na shell? (Na druhou stranu ten chroot asi také nebude neprůstřelný.)

Co se webových serverů týče - nejlepší bude asi takový, který si sám napíšeš Ale to je také většinou sci-fi.

[Käyttäjä 11133]

Ale co BSDčkový jail, že...

[Creckx]

Podle mě ano. Mám v /etc/ soubory kde jsou hesla, pak tam mám soubory k databázi, a v nespolední řadě tam mám data uživatelů, kteří nebudou nadšeni z myšlenky sdílet svá data s ostatními. Když bych použil Apache a nastavil práva a na něco zapoměl, tak si to každej jednoduše přečte. Když použiju lighty, tak na práva můžu zapomenout a jediná možnost je chroot nebo si pohrát s fastcgi. Fastcgi mě zas omezí v jiných věcech, takže zůstanu u chrootu :) Nejsem tak zkušený, abych zkoušel něco jiného :)

Co se týče průstřelnosti, tak máš pravdu. Dum8d0g někdě vykopal, že za použití shellu a Cčkovýho kompilátoru je možné se přes něj dostat. Je tu ještě podmínka, že chroot musí být vytvořen rootem a musí být k dispozici /proc. Jenže chroot se nějakým způsobem od roota odpoutá po spuštění, takže tohle taky padá. Sečteno a podtržno, jsem ochoten to risknout :)

[fakenickname]

http://www.bpfh.net/simes/computing/chroot-break.html na en wiki pisou neco o vytvoreni sekundarniho chrootu, kterym se da dostat z primarniho. casto se taky pise o zneuziti /dev, kterym se bezpecnost chrootu rapidne snizuje. je spousta cest, ale nejsou jednoduche. stejne tech 99% script kiddies ani nepoznaji ze je to chroot :)

[Creckx]

Tak dostat se dá přes všechno možný, ale kdo to dá? Už jsme se o tom bavili :)

[phero]

Dostat na system jednu zakernou binarku a pustit ji, je, rekl bych, typicka cinnost script-kiddies kdyz maji shell

[phero]

Tak zajistit bezpečnost chrootu stejně jako hlavního systemu (nikdo nesmí získat roota ) a nedavat do chrootu nic co nepotrebujes (/proc,/dev/) a muzes byt vklidu. Ale jasne virtualizacia vladne ...

[computerman]

jaky mas virtualni server?

[Messa]

Hehe Forpsi, asi nejlevnější co jde sehnat. Zatím je to v poho, akorát rychlost připojení může být omezující.

[computerman]

:) virtual od psu je prave jeden z nejdrazsich

[Messa]

Já vím, že jsem příliš obchodního talentu nepobral, ale můžeš to prosím tě nějak rozvést? Víš snad o něčem levnějším než za tři kila měsíčně (bez DPH)? Pipni znám, ten prosím vynech

[Creckx]

Jemu šlo asi o to, že za dvojnásobek nebo dvoj a půl násobek ceny dostaneš 10ti násobek služeb u jiných providerů.

[Jardík]

To jako chceš říci, že když mám lighttpd + virtuální domény, tak má možnost skript z blog.janevimco.cz se dostat k admin.janevimco.cz? Tak to je pěkná díra, to musím také nějak pořešit ... To mám takto:

/Server
  /Sites
    /admin.janevimco.cz
    /blog.janevimco.cz

A opravdu, když v blog.janevimco.cz dám do php include "../admin.janevimco.cz/tajnahesla.php", tak se to tam opravdu dostane ...

[Creckx]

Jo to je přesně ono :) U PHP se to dá řešit safemodem a openbasedirem. U Python a spol to už je horší.

[xm]

Nazívat safe mode v PHP "řešením" je hodně silné kafe... safe mód je taková zrůdnost, až to není hezké. Naštěstí v PHP 6 už nebude.

Ono řešení je celkem jednoduché - nepoužívat žádné mod_*, ale FastCGI. Je to bezpečnější a flexibilnější řešení a výkonově obdobné (v některých případech dokonce znatelně výkonnější). I to má své mouchy, ale pořád je to milionkrát lepší než hrůza zvaná "Safe Mode".

[Creckx]

Já se nikdy v PHP nehrabal, utek jsem a dal se na pythoní cestu :) Pod fastcgi se chystám rozjet i python a spol, ale zatim mi cgi vyhovuje a musím se soustředit na jiné věci.

[xm]

CGI je nesmírně pomalé. Pro větší věci prakticky nepoužitelné.

[teekey]

ten server (50 users) uz jede a nebo jej teprve chces stavet?

[Creckx]

Všechno je ready.. dělám na mainpage a administraci. Ještě se občas něco změní v MySQL tabulkách, tak tam zatim nepotřebuju moc lidí.

[Josef Kufner]

A nestačilo by, kdyby každý lightppd běžel pod jiným uživatelem a načítal konfiguraci z jeho home? Zbytek by zvládly klasická unixová práva.

[Jardík]

A to vícenásobné spuštění vůbec funguje? Když si totiž jedna instance obsadí port 80, druhá si ho už obsadit nemůže ... a přece nebudu mít každou instanci na jiném portu.

[Creckx]

Každý lighty má svůj port a běží to bezvadně. Mám k nim startovací script a script na kontrolu stavu a tak to je jako kterejkoli jinej dameon. Port se určí při vytváření toho chrootu a nastaví se mod_proxy na lightym, kterej je na 80tce. Všechno funguje v pohodě:)

[Jardík]

A máš k tomu nějaké skripty, konfiguráky ..., že bys nám je mohl ukázat

[Creckx]

Mám, napiš mi na jabber až budeš online.

[Creckx]

Nestačí, protože to lighty nezvládá.

[Josef Kufner]

To mu nemůžeš předhodit jiný konfigurák? Pod jiným uživatelem ho můžeš spustit třeba pomocí su -c.

[Creckx]

Když už spouštim celý lighty pod novym userem, tak tam ten chroot taky fláknu ne? Já mluvil o něčem jinym, ale to asi není moc dobře proveditelné, protože to funguje jinak než apache.

[Josef Kufner]

No, ale když ho jen spustíš pod jiným uživatelem, tak nepotřebuješ chroot a stačí ti jen jedna instalace. Přitom bezpečné to je nakonec stejně -- tak jako tak mu roota dát nemůžeš (dostat se pak z chrootu je na pár příkazů) a jako uživatel nic nenapáchá. Ve výsledku to budeš mít jednodušší a tudíž tam bude méně problémů a chyb.

[Creckx]

Všechno je natolik automatizovaný, že tam na chyby tolik místa neni. Chroot je bezpečnější než všelijaké nastavování práv, o tom není pochyb a mnohem líp se spravuje. Více procesů musí běžet tak jako tak a těch pár MB navíc na disku, kde můžou bejt různý zvrhlosti, které si kdo vymyslí (třeba vlastní scriptovací jazyk nebo upravený python), mě nerozhodí. Ale beru, že to je taky řešení.

[Josef Kufner]

No ono to není jen místo na disku, ale i místo v paměti. Když jsou to na disku dva různé soubory, tak to jsou i dva různé soubory v cache.

Na druhou stranu, když to máš v chrootu, je jednodušší to pak překlopit na nějaký to virtuální udělátko. Pak je ale otázkou, proč zůstávat na půli cesty a do chrootu nepřidat i to jádro rovnou...

[Creckx]

Proč si to mám komplikovat nějakym jádrem? Server sám neni v chrootu. Jen se do chrootu přepíná. Jediný co je na disku vícekrát jsou scriptovací jazyky.