WebDAV (diskuse)

[trekker.dk]

Na WebDAV je - minimálně v Apache - nepříjemné to, že se soubory nahrávají pod systémovým uživatelem www-data (obecně pod tím, pod kterým Apache běží) a nejde to změnit. Pokud ten server není jenom datové úložiště, tak to docela vadí.

[Luk]

A co mpm_itk?

[trekker.dk]

No, v dokumentaci hned na začátku píšou, že je to založené na prefork mpm, které na serveru, kde je provoz, AFAIK nepodává úplně nejlepší výsledky.

[pavlix]

Nevím jak v tomto konkrétním případě, ale obecně považuju za jedinou validní alternativu k mpm-itk pustit pro každý jednotlivý subjekt (uživatele) samostatný Apache. To, že někdo umí z Apache vytřískat trochu výkonu navíc je mi většinou naprd, když je cenou za to ztráta možnosti pouštět weby pod různými uživateli.

[trekker.dk]

Nevím, co přesně myslíte souslovím "pouštět weby", ale nestačil by suexec?

[Luk]

Pokud vím, tak byl suexec ve většině případů výkonově horší než mpm_itk.

[trekker.dk]

No, přiznávám se, že jsem to neměřil, ale nezdá se mi to. Bylo by divné, kdyby spuštění nového procesu pro každý request bylo rychlejší než spustit jeden proces a ten nechat vyřídit řádově stovky requestů.

[Luk]

Nový proces pro každý request se vytváří právě u suexec. Jinak může proces Apache vyřídit prakticky libovolný počet požadavků, samozřejmě v závislosti na tom, jak je to nastavené v konfiguraci. U mpm_itk je samozřejmě nepříjemné to, že když si Apache naforkuje procesy pro nějakého uživatele a pak je potřebuje pro jiného uživatele, nemůže je použít. Buď si naforkuje další (pokud je pod limitem pro počet procesů) nebo musí nejdřív ty nevyužité ukončit. Tedy když je uživatelů hodně a požadavky jsou mezi nimi rozložené v zásadě rovnoměrně, může být (ale nemusí!) výkon lepší se suexec, při malém počtu reálně využívaných uživatelů je na tom lépe mpm_itk. Další věcí je, že suexec se týká jen toho, co se po Apachem spouští, kdežto mpm_itk se vztahuje na všechno včetně samotných funkcí Apache.

[trekker.dk]

Nový proces pro každý request se vytváří právě u suexec.

Tak to fakt ne.

Možná se bavíme každý o něčem jiném - já mluvím o nastavení, kdy apache přes suexec spustí program a ten pak běží jako FastCGI server.

Jinak může proces Apache vyřídit prakticky libovolný počet požadavků

Pravda, tohle jsem si zaměnil s CGI - co koukám do dokumentace, tak i prefork režim nechá jeden (pod)proces vyřídit víc požadavků.

Další věcí je, že suexec se týká jen toho, co se po Apachem spouští, kdežto mpm_itk se vztahuje na všechno včetně samotných funkcí Apache.

To je pravda, na druhou stranu ty samotné funkce Apache toho neřeší tolik - přijmout navázané spojení, otevřít soubor, načíst soubor, poslat obsah do toho spojení - na tom není moc co zkazit a i tak se to děje pod neprivilegovaným uživatelem. Za poslední roky přitom nevím o nějaké chybě, která by v tomhle režimu umožňovala vykonat cizí kód nebo aspoň přistoupit k cizím datům.

[Luk]

já mluvím o nastavení, kdy apache přes suexec spustí program a ten pak běží jako FastCGI server

To už je ale trochu něco jiného. Samotný suexec se chová tak, jak jsem popsal.

i prefork režim nechá jeden (pod)proces vyřídit víc požadavků

Může jich vyřídit libovolné množství, pokud se Apache tak nastaví. Při běhu pod více uživateli je tam samozřejmě ten problém, který jsem zmínil. Pokud je k dispozici dost paměti, dá se limit na procesy Apache nastavit vysoko (totéž počet flákajících se procesů, aby je to neukončovalo) a nevzniká zpoždění tím, že by se vytvářely nové procesy.

To je pravda, na druhou stranu ty samotné funkce Apache toho neřeší tolik - přijmout navázané spojení, otevřít soubor, načíst soubor, poslat obsah do toho spojení - na tom není moc co zkazit a i tak se to děje pod neprivilegovaným uživatelem.

Jenže řeč byla o WebDAV, z toho celou dobu vycházím.

[trekker.dk]

No jasně že je řeč o WebDAV, ale v prostředí, kdy ten Apache není jenom datové úložiště, ale webserver (definice slova podle #21). Pokud bych chtěl umožnit nahrávání dat pomocí WebDAV, tak s mod_dav musím obětovat buď výkon (viz níže ten test), nebo ukládání dat různých uživatelů (lidí) pod různými systémovými uživateli. Jedno je horší než druhé a suma sumárum je WebDAV ze hry venku.

[Sten]

Na „pouštění webů“ je spíš PHP-FPM.

[trekker.dk]

Taky možnost, ale všude, kde jsem četl o php-fpm a jak to integrovat do Apache nebo Nginx, taky vždycky psali o "caveat" při přístupu na URL typu /upload/obrazek.jpg/skript.php (obrazek.jpg se předá ke zpracování interpreteru PHP a ten ho vykoná). Jako řešení tam potom vždy psali buď zakázat pathinfo, nebo přidat přepisovací pravidla a kontroly, aby se takový soubor nezpracoval. (Přičemž jak mají dané kontroly vypadat, už bylo dáno jako domácí cvičení laskavému čtenáři.)

S kombinací Apache + suexec + PHP se mi zatím nepovedlo ten caveat reprodukovat. Požadavek na /obrazek.jpg vrací ten obrázek (nebo PHP kód, když se pokoušíme škodit), požadavek na /obrazek.jpg/skript.php vrátí 404.

[pavlix]

Tedy namísto jednoduchého řešení typu mpm-itk, kdy celá obsluha probíhá pod příslušným uid/gid, zvolíme komplikované (a tedy potenciálně děravé), dost možná ještě méně výkonné řešení. Díky, nechci, suexec se mi nelíbil od první chvíle, kdy jsem na něj narazil, považuju ho za velmi pochybné řešení a byl jsem z něj nežťastný do doby, než jsem se prvně seznámil s mpm-itk a od té doby jsem všude rovnou instaloval balík s tímto modulem (a závislostmi) namísto výchozího apache. Nevím, jak takovou prasárnu může vůbec někdo vychvalovat.

[trekker.dk]

Tedy namísto jednoduchého řešení typu mpm-itk, kdy celá obsluha probíhá pod příslušným uid/gid, zvolíme komplikované

Váš názor, nic jiného.

(a tedy potenciálně děravé),

FUD, navíc vycházející z nepravdivého předpokladu

dost možná ještě méně výkonné řešení.

Tak jsem si to lehce otestoval - výchozí instalace Apache, statický obsah (stránka s It works) na localhostu s prefork + itk vs. event nebo worker. Worker cca 6000 req/s, prefork 1000 req/s.

Nevím, jak takovou prasárnu může vůbec někdo vychvalovat.

Asi to bude někdo, komu nastavení suexec nedělá problémy a výsledek bez problémů funguje. Ten někdo se možná podíval do zdrojáku suexec, který je pochopitelný a je z něj naprosto jasně vidět, co to dělá a proč.

[Luk]

Tak jsem si to lehce otestoval - výchozí instalace Apache, statický obsah (stránka s It works) na localhostu s prefork + itk vs. event nebo worker. Worker cca 6000 req/s, prefork 1000 req/s.

To je ale zjevně něco úplně jiného, než o čem tu je řeč. Worker a event nezajistí samy o sobě separaci uživatelů (třeba pro WebDAV, o kterém je tu řeč od počátku), takže tohle porovnání výkonu je nesmysl. Srovnává se nesrovnatelné.

[trekker.dk]

Worker a event nezajistí samy o sobě separaci uživatelů

Ano, to je mi známo, goto #1, první věta.

Kdyby ten webserver byl jenom osobní datové úložiště (tak, jak ho popisuje autor blogu), tak fajn. Na takovém serveru nebude velký provoz. Jenže v konfiguraci, kdy je Apache primárně webserver (čti server poskytující webové stránky webovým prohlížečům, goto #1, druhá věta), už je to něco jiného - tam si pomalý prefork nemůžu dovolit, což potvrzuje i to srovnání.

Jasně, separaci uživatelů worker ani event nezajistí, takže WebDAV je ze hry venku a jsem odkázaný na FTP, SFTP apod.

[pavlix]

Worker a event nezajistí samy o sobě separaci uživatelů (třeba pro WebDAV, o kterém je tu řeč od počátku), takže tohle porovnání výkonu je nesmysl. Srovnává se nesrovnatelné.

+1

[pavlix]

Ne, asi sem budu psát názor někoho jiného :D.

[Petr Tomášek]

Kapico, Kapico! Zase dost velké zjednodušení!

Pro upload souboru na server není WebDAV potřeba. Na to stačí klidně metoda PUT, které je definovaná v rámci HTTP. WebDAV se stará hlavně o zjišťování metainformací o souborech a adresářích (k čemuž např. patří vylistování obsahu adresáře) a taktéž o změnu takovýchto informací (viz metody PROPFIND a PROPPATCH).

Jinak základní podporu pro WebDAV je možné poměrně jednoduše zbastlit i v PHP a to dokonce tak, že jedno URL při přístupem přes normální prohlížeč ukáže nějakou "sexy" stránku např. s výpisem adresáře a přitom přes stejné URL je to dostupné přes WebDAV...

[Aleš Kapica]

No, řekl bych že i přes to zjednodušení jsem dal tomu času víc než dost. Obzvláště, když jde o téma, na kterém dokážou jiní postavit celou svou akademickou kariéru.

[Sten]

Jinak základní podporu pro WebDAV je možné poměrně jednoduše zbastlit i v PHP a to dokonce tak, že jedno URL při přístupem přes normální prohlížeč ukáže nějakou "sexy" stránku např. s výpisem adresáře a přitom přes stejné URL je to dostupné přes WebDAV...

Nebo použijete standardní moduly pro Apache, které udělají totéž

[Petr Tomášek]

Ovšem s tím rozdílem, že vlastní implementací v PHP můžu velmi dobře kontrolovat, co přesně se bude se soubory dít, nebo je dokonce generovat on-the-fly, atd..

[xxx]

No nekteri z nas ten WebDAV na FELu museli pouzivat jako studenti, a ze by to byla tak super vec, to mi uplne neprislo.

Teda ne ze by to nefungovalo, ale bylo zcela zrejme, ze vzhledem k tomu, jak dlouho vyucujicim vzdycky trvalo to spravne zprovoznit, tak aby vsichni meli slozku, kterou maji mit, a prava, ktera maji mit, tak se obavam, ze v administracni privetivosti to melo silne nedostatky.

Coz treba Moodle, ktery se v te dobe zacal sirit, a obcas mi prisel z uzivatelskyho hlediska fakt tragickej (kam se mam sakra zas proklikat), tak tuhle administrativni pripravu mel zrejme lip zmaknutou.

A nebo to proste bylo akorat o nahode.

[Aleš Kapica]

No nekteri z nas ten WebDAV na FELu museli pouzivat jako studenti, a ze by to byla tak super vec, to mi uplne neprislo.

O WebDAV, který jsem provozoval já jde asi těžko. Bylo to čistě provizorní řešení, určené ke sdílení souborů v rámci jedné pracovní skupiny a konfigurace byla vskutku jen základní. Pravděpodobně jde asi o řešení, které bylo donedávna provozované na Katedře počítačů.

Podle toho co mi o něm sdělil kolega byl největší zádrhel ve zbytečně komplikovaném URL a v tom k čemu byl tento sdílený prostor určen.

Nefungovalo to tak, že by měl každý student jeden adresář dostupný přes WebDAV, do kterého by si ukládal svoje soubory, ale zakládal se mu adresář extra pro každý předmět. S tím, že tento adresář byl určen pouze pro odevzdávání souborů souvisejících s předmětem. A jelikož vyučující předmětu k nim musel mít také přístup, tak z toho plynul onen oser s konfigurací práv. A s tím vcelku souhlasím, že to musel být opruz, protože WebDAV nějaké sofistikované nastavení práv vůbec neřeší. Taky se nehodí ani pro uložení uživatelského profilu, protože nelze kupř. pracovat se symlinky. Ovšem pro to, aby měl své každý uživatel dostupné své dokumenty po síti souběžně z různých zařízení, podle mě bohatě stačí.

Coz treba Moodle, ktery se v te dobe zacal sirit, a obcas mi prisel z uzivatelskyho hlediska fakt tragickej (kam se mam sakra zas proklikat), tak tuhle administrativni pripravu mel zrejme lip zmaknutou.

Pokud jde o Moodle, tak že jde o zcela tragický e-learningový systém se nebudu přít. Už jsem se o tom možná tady někde i zmiňoval co vše na něm považuji za špatné - v podstatě to začíná už samotným návrhem aplikace, která nezapře své kořeny v jednoúčelovém bastlu, jehož autor vůbec netušil že se to zvrhne do takového molochu. Bohužel. Stalo se a trend je takový, že s ním bude nutné žít i do budoucna.

[Josef Kufner]

[...], protože nelze kupř. pracovat se symlinky.

Dobré vědět. Doteď jsem si dělal naděje, že by WebDAV šel použít na sdílení dat mezi mými zařízeními, ale chybějící podpora symlinků je na mne příliš omezující.

[Martin Bílý]

Když už tady na to přišla řeč, tak na tehdejším serveru service.felk.cvut.cz byl použit běžný modul mod_dav. Pro autentizaci a autorizaci uživatelů ale existoval domo-robo modul, který pracoval s informacemi uloženými v databázi PostgreSQL. S jeho pomocí bylo možno povolovat přístup pro každého uživatele, ke každému jednotlivému souboru či adresáři některou z tuším šestnácti HTTP (včetně WebDAV) metod. Existoval pojem skupina uživatelů. Existovala dědičnost práv z nadřízeného adresáře. V dobách největší slávy měla největší tabulka s individuálními právy uživatelů něco přes 50 tisíc záznamů.

Problémy působilo především to, že zdaleka ne všechny klientské programy rozdýchávaly situaci, kdy například přečtení souboru bylo povoleno i anonymnímu uživateli, zatímco pro jeho změnu bylo nutné se autentikovat.

Existovala sada scriptů, které zakládaly uživatelské účty, řadily uživatele do skupin, přidělovaly práva do individuálních projektových adresářů automaticky v závislosti na seznamu studentů zapsaných na předmět a v závislosti na profilu předmětu v rámci serveru. Též existovala nadstavba pro správu ad-hoc projektů.

Tolik na doplnění od bývalého admina bývalého serveru.

[brozkeff]

WebDAV využívá i třeba ownCloud, takže pokud nejde o levný hosting za 20 korun měsíčně, ale výkonnější VPSko, tak bych pro jednoduchost možná zvážil i ten owncloud, kde je možnost to napojit na LDAP či AD, nebo vytvářet uživatele a skupiny ručně.