K soutěži Top Hostingy aneb jednooký hosting králem

Dovolte mi na úvod trochu osobní vzpomínku: Před několika lety jsme provozovali jistý webový server u nejmenovaného poskytovatele (není podstatné, o kterého šlo). Měli jsme službu „dedicated server“ – tedy vlastní server v racku u poskytovatele, dodaný a spravovaný právě poskytovatelem. Vše, co jsme chtěli na serveru upravit, jsme museli řešit přes systém „požadavků“ a „tiketů“. Vytvoření MySQL databáze trvalo pět dnů. Jakákoli změna v nastavení byla na dva týdny. Instalace jakéhokoli SW byla téměř nemyslitelná („to vám přece nebudeme kompilovat!“ a „to vám tam dát nemůžeme, nemáme to ověřené!“).

Když jsme přijeli osobně zeptat se, zda by nemohli alespoň jednu jednoduchou věc povolit (konkrétně jsme potřebovali možnost nastavit si pravidelné volání PHP skriptů via wget), tak jsme se místo diskuse na téma „Jak by to šlo udělat“ dočkali několikaminutových přednášek na téma „proč to NEJDE, proč to NEMOHOU udělat a proč to NEUDĚLAJÍ“. Ano, byl to extrém, i v té době. A to nešlo o žádného garážového poskytovatele, ale o jednoho z největších. 

Poskytovatelé jsou dnes mnohem vstřícnější a takovéhle chování si už nedovolí. Přesto přetrvávají naprosto pozoruhodná omezení, která většina zákazníků bere jako „něco co musí být“, ale často stačí podívat se za hranice, přestat si nalhávat, že jsme na tom „vlastně špičkově“ (technicky možná…) a začít i po našich providerech požadovat to, co je jinde (téměř) standard.

Nechme stranou virtuální servery, dedikované a managed servery a podívejme se na nejčastěji poskytovanou službu, tedy „sdílený webhosting“. Nejčastější model sdíleného webhostingu je LAMP (Linux, Apache, MySQL, PHP). Takovou službu poskytují velcí i malí provideři, téměř každý v několika různých cenových variantách, které se od sebe liší velikostí poskytovaného prostoru či počtem mailových schránek.

Mimochodem, řekněme si na rovinu: Mailové schránky jsou v době poskytovaných služeb jako jsou Google for your Domain či Live Mail u hostingu tak nějak na houby. Ale budiž: Dejme tomu, že je někdo použije. Ale jako zákazník, co chce provozovat, řekněme, PHPkový e-shop, potřebuji velký prostor na disku, a sto padesát mailových schránek, co k tomu dostanu, je mi na nic. Navíc mě zajímají úplně jiné věci.

Více domén? Nechte si zdát…

Nejčastější nešvar českých webhostingů je pravidlo „jeden účet = jedna doména“. Při nejlepší vůli povolí zřídit několik aliasů. Přitom neexistuje technický důvod, proč by nemohlo k jednomu účtu směřovat víc domén, krom důvodů „pohodlnostních“!

Kdysi jsem s jedním poskytovatelem hostingu na toto téma vedl diskusi, a on se mi snažil vysvětlit, že více domén u jednoho účtu by neúměrně zvýšilo zátěž na server. Že takto mají třeba 150 zákazníků na fyzický stroj, těch 150 zákazníků má 150 domén a na nich je 150 projektů. Kdyby jich mohli mít víc, tak by na jeden fyzický stroj připadalo třeba 300 domén, tedy 300 projektů, zátěž by byla mnohem vyšší, takže by museli kupovat další stroj… tedy by klesla „výtěžnost na server“. Proto tedy „co účet, to doména“. Oponoval jsem mu, že například já provozuji asi šest domén, které používají Drupal, a mám je všechny na jednom účtu (Drupal umožňuje na jedné instalaci provozovat víc domén). Tedy že zabírá na disku o (5*velikost Drupalu) míň místa, že je mnohem snazší administrace… Prý jsem extrém a mám s takovými požadavky jít na VPS. 

Přitom není důvod s takovým požadavkem pořizovat vlastní VPS. Víc domén na jednom účtu umí i low-cost hostingy jako Lunarpages, Hostgator či Hostmonster, kde pořídíte účet za stokorunu měsíčně. A nejen to!

Možná se to zákazníkům českých hostingů bude zdát jako sci-fi, ale i u těchto levných služeb je možné použít např. SSH pro vzdálený přístup. Zkuste požádat o vzdálený přístup u některého českého sdíleného hostingu – vsadím se, že odpověď bude „to nejde, z bezpečnostních důvodů“. Tato odpověď ve skutečnosti znamená: My to neumíme udělat bezpečně, takže máte smůlu. Zkuste si udělat takovou primitivní věc, jako zkopírovat na hosting zabalené skripty v jednom .tar.gz souboru a na místě je rozbalit. Někde nabízejí „správce souborů“, který to umí. Pokud ne, tak můžete zkusit použít PHP funkci exec() – pokud není zakázaná.

Informovat zákazníka!

S výše napsaným souvisí otázka informovanosti. Každý hosting se s chutí „prsí“ počtem schránek, velikostí diskového prostoru a neomezenou konektivitou, ale o omezeních (safe mode, .htaccess, zákaz exec() či zakázané ini_set) už neinformují. Přitom si hostingy v ČR v omezeních možností svých serverů téměř libují. Máte téměř stoprocentní jistotu, že to, co si na svém pracovním serveru odladíte, nebude alespoň na jednom z pěti náhodně vybraných hostingů fungovat kvůli nějakým „bezpečnostním omezením“. Problém je v tom, že se málokdy dozvíte předem, jakou zajímavou (ale vždy klíčovou!) drobnost správce zakázal. Většinou to zjistíte až ve chvíli, kdy je hosting zaplacený, je zkopírovaná databáze a jsou přenesené skripty. Přitom by čas, nervy a peníze všech zúčastněných ušetřila prostá věc:

• pro odborníky výpis phpinfo().
• pro laiky navíc podrobně slovně rozepsat omezení.

Pokud se správce bojí, že výpis phpinfo() přinese bezpečnostní riziko, může jej pravidelně generovat staticky.

K větší informovanosti může přispět i možnost „zkušebního účtu“, kdy je např. první týden poskytnut zdarma.

Omezování

Omezení je svrchovaným právem každého hostingu. Obzvlášť v tak konkurenčním prostředí. Fér je to však jen tehdy, pokud o omezeních dá hosting na rovinu vědět. Není třeba je zdůvodňovat nebo omlouvat se za ně, bohatě stačí o nich na rovinu informovat! Pokud se poskytovatel bojí, že informace o tom, jaká omezení aplikuje, jej může konkurenčně znevýhodnit, měl by zkusit přemýšlet, zda není na místě omezení odstranit, či zda je konkurenční výhodou i naštvaný zákazník, který s chutí o omezeních napíše na fóru u konkurence.

Proč vlastně hostingy své služby omezují? Důvody jsou nejčastěji tyto:

• omezení z neznalosti: admin vidí bezpečnostní riziko a neumí ho vyřešit jinak, než zakázáním (důležité) funkce
• omezení socialistické: admin ví nejlépe, co je pro klienty dobré. Zakáže jim sirky, protože by si mohli zapálit vlastní dům
• omezení z čiré blbosti: co dodat, příklady budou následovat
• omezení z bezpečnostních, výkonnostních, obchodních důvodů: proti tomu nelze nic namítat, jen je potřeba odlišit, jestli nejde ve skutečnosti o jeden z předchozích dů­vodů

Adminové dokáží velmi přesvědčivě vysvětlovat, proč zrovna to či ono omezení musí být a je nezbytné. Často se ale stačí zeptat: „Taky to Hostmonster zakazuje?“

A abychom byli trochu konkrétnější, pojďme si ukázat některé příklady omezování serverů. Nebudeme jmenovat konkrétní hostingy, kde se dané omezení vyskytuje – jmenovat jednu či dvě ukázky by bylo nespravedlivé vůči ostatním. Možná stačí uvést, že příklady omezení byly nalezeny mezi oceněnými hostingy. Navíc je potřeba si uvědomit, že následující omezení se na hostinzích často kombinují.

Zákaz funkce ini_set() (nebo jeho aliasu ini_alter())

Velmi rozšířené omezení hostingů v ČR (dva z velmi dobře hodnocených hostingů v soutěži TOP Hostingy právě toto omezení měly či mají). Toto omezení lze zařadit mezi omezení z neznalosti – konkrétně direktiv php_admin_value a php_admin_flag. Toto omezení může způsobit bezpečnostní díru (ironií je, že bývá zdůvodňováno jako omezení z bezpečnostních důvodů) – servery pak bývají náchylné např. na útoky Session Fixation. Navíc komplikuje logování chyb atd.

Zákaz funkce phpinfo()

Toto omezení je spíše rarita, ale například jeden z vítězů TOP Hostingů právě toto omezení má. Takové omezení nelze označit jinak než jako „omezení z nebetyčné blbosti a arogance“, viz sekce „Informovanost“ – pokud si phpinfo() nemůže vypsat ani platící zákazník, tak může jen stěží monitorovat případné změny konfigurace, a využití takového hostingu je značně omezené. Pokud člověk totiž hledá podporu na fórech opensource webových aplikací, obvykle první reakce zní „pošli výpis phpinfo()“. Pokud tohle nejde, je to zásadní chyba a velmi silný důvod takový hosting, kde hází uživatelům zcela zbytečný klacek pod nohy, opustit.

Zákaz allow_url_fopen

V podstatě zakáže přistupovat k datům z jiných serverů (např. funkcí file_get_contents) – což omezí funkce např. čtení RSS či kontroly aktualizací. Toto omezení je typické „omezení socialistické“: co kdyby někdo udělal eval(file_get_con­tents($_GET[‚a­dresa‘]))? Admin chrání uživatele před následky možné blbosti, bohužel následky této „ochrany“ nesou všichni. Pokud je na serveru zároveň povolené cURL (což není výjimka), působí taková ochrana směšně, neboť lze stejného efektu dosáhnout jinak (vzal jsem jim sirky, ale plamenomet nechal). Pro uživatele je to pouze nepříjemnost – musí přepisovat kód.

Pokud na serveru není povolené ani cURL, tak je uživatelova aplikace absolutně odříznuta od okolního světa a lze bez nadsázky říct, že takový hosting je v době Webu 2.0 nepoužitelný.

Zákaz logování chyb

Opět víceméně rarita, přesto se vyskytla u dalšího vítěze soutěže TOP Hostingy. Rovněž jde o omezení z nebetyčné blbosti – hosting je pak vhodný pouze pro hostování statických stránek nebo PHP stránek, na které nikdo nechodí. Na argument, že „na ladění je lokální počítač a na ostrém serveru už žádné chyby být nemohou“, se dá reagovat několika způsoby:

• Otázkou, zda i samotný dotyčný hosting si zakazuje logování případných chyb ve své administraci (pokud ano, nechtěl bych jejich administraci používat, je plná neodhalených chyb)
•  Otázkou, jak odhalit chybu při přenosu přes FTP (chybějící nebo částečně nahraný soubor)

Zákaz nastavení PHP direktiv přes .htaccess

Úzce souvisí se zákazem ini_set(). Některé PHP direktivy totiž nejdou nastavit přes ini_set a je potřeba využít .htaccess. Toto omezení nemusí být nijak zásadní, zpravidla lze vše nastavit v administraci nebo požádáním admina. Pozor: povolené nastavování PHP direktiv přes .htaccess nenahrazuje potřebu ini_set!

Zákaz nastavení pravidel mod_rewrite přes .htaccess

Pokud hosting vyžaduje nastavení pravidel mod_rewrite jen přes httpd.conf, znamená to, že s každou úpravou je potřeba kontaktovat správce. Navíc pravidla v httpd.conf a .htaccess mají hodně odlišný zápis, z čehož vyplývá řada problémů

Safe mode

Toto omezení je z bezpečnostních důvodů (a tedy opodstatněné), ale lze se mu vyhnout například tak, že server místo mod_php bude používat FastCGI. Navíc od PHP 5.3 je safe_mode deprecated, v PHP 6 bude odstraněn.

Opravdu můžeme být spokojeni?

Probrali jsme nejzásadnější omezení, na která můžete u PHP hostingů v ČR narazit, a která mohou způsobit problémy. S velkou částí z nich se můžete setkat i u hostingů, které byly v soutěži TOP Hostingy velmi vysoko hodnocené. Proto je na místě v perexu zmíněné úsloví o jednookých králích. Přitom to, že to jde i jinak, dokazují i velmi laciné zahraniční hostingy.

Nechť zmínění neberou tento článek jako shazování jejich úspěchu, ale jako postrčení kupředu… 

Děkuji Davidu Grudlovi za laskavé odborné vyjádření k technickým omezením.