Vyplatí se jít na školení Jakuba Vrány?

Prapůvodně měl být na tomto místě ohlas na školení Jakuba Vrány Konfigurace a výkonnost MySQL. Chtěl jsem psát o tom, že ačkoliv mě Jakub dopředu varoval, že téma konfigurace MySQL není gór moc kůl, obavy se ukázaly jako liché, neboť prakticky každou vlastnost demonstroval na živých příkladech a tím držel posluchače ve střehu. Jako skvělý prezentační nástroj se přitom ukázal Adminer. Až jsem měl pocit, že si ho vyrobil speciálně k tomu účelu, protože s phpMyAdminem by tak ladně demonstrovat některé rysy MySQL nešlo. No a pak tu mám několik drobností, které bych školení vytkl, nicméně…

…Nicméně hlubší rozbor tohoto konkrétního školení vynechám. Jednak proto, že ho Jakub aktuálně nenabízí. (Přesněji řečeno nabízí řadu jiných školení a máte poslední šanci se na ně přihlásit, první z nich je totiž už zítra). A také proto, že více čtenářů bude zajímat odpověď na úvodní otázku.

Začnu obecně: aby pro vás školení mělo přínos, musí dojít k určité konjunkci hvězd:

• přednášející musí tématu výborně rozumět
• přednášející musí umět školit
• přednášející musí mít školení dobře připravené
• a vy si musíte vybrat správný kurz (a ptát se)

Že neříkám nic objevného? Kéž by. Divili byste se, kolik firem posílá lidi na školení k pánům nikdy-jste-o-mně-neslyšeli, jsem-o-kapitolu-před-vámi nebo říkají-mi-uspavač-hadů. Není lepší jít na doopravdické školení? Obzvlášť pikantní je, když se na takovém doopravdickém školení objeví osoba ze známé-školící-firmy, aby se to naučila, bo za týden to sama školí 

Jak je na tom Jakub Vrána, jsou jeho školení doopravická? Nepopiratelně je významná osobnost PHP scény, jeho jméno najdete dokonce v dokumentaci. Navíc disponuje schopností přednášet, jeho výklad je srozumitelný a působí přirozeně. A když jsem z něj ve svých školitelských začátcích mámil know-how, shodli jsme se na tom, že jednomu kurzu věnujeme téměř rok příprav. Splňuje tedy všechny tři body. Čtvrtý už je na vás. Když ho splníte, tak vězte, že se školení rozhodně vyplatí.

---

Při psaní tohoto článku zemřelo jen zanedbatelné množství zvířat a žádný Davídek nebyl podplacen.

Jak funguje zálohování disků „za chodu“

Na zálohování jsem si pořídil úžasný prográmek Drive SnapShot. Umí zálohovat celé disky, má pouhých 160kB a funguje nejen pod Windows , ale i pod DOS. Což se náramně hodí, pokud potřebujeme obnovit zhroucené Windows. A hlavně: umí provádět rozdílové zálohování, archívy šifrovat (AES, 128bit) a poté je mountovat jako další disk! Vřele doporučuji vyzkoušet.

Tento prográmek (stejně jako jemu podobné: Norton Ghost, Acronis True Image) dokáže uložit přesný obraz disku, jaký existoval v okamžiku spuštění. Vždycky mě ale zajímalo, jak zálohování on-fly vlastně funguje. Vždyť celá operace nějakou chvíli trvá. Od minut až po hodiny. Přesto program vytvoří přesný obraz disku, ať už s ním během zálohování dělám cokoliv. Jak je to možné?

Vše se točí kolem vyspělých operačních systémů na bázi NT. Tedy třeba Windows Vista, nikoliv však zastaralých 95/98. Při spuštění zálohování přikáže aplikace operačnímu systému, aby uložil všechna data, která si drží v paměti, na disk. Poté se napojí na diskový ovladač, aby mohla monitorovat každý přístup na disk. A zahájí kopírování pěkně sektor za sektorem.

Jakmile se objeví požadavek na zápis na disk, a to v místě, které ještě nebylo zálohované, tak tento sektor přednostně zazálohuje a pak teprve zápis povolí.

V tom je celý trik. Jakmile odstartujeme zálohování, můžeme na disku jakkoliv řádit, instalovat či mazat programy, chytit virus. Záloha bude vždy obsahovat konzistentní podobu disku v okamžiku spuštění. Chytré, co?

Proč opustit Subversion (SVN)

Řada projektů opouští populární verzovací systém Subversion a přechází na jiný. Jaké jsou důvody?

K používání Subversion (SVN) mě přiměl kdosi v počátcích vývoje Texy. Do té doby jsem „verzoval“ archivováním složky s kódem do RARu před každým větším zásahem. A něco sofistikovanějšího by bodlo. Veřejnému repositáři jsem odolával, protože mi připadalo, jako by mi někdo koukal při programování pod prsty. Zkusil jsem proto lokální SVN server s už tehdy skvělým GUI TortoiseSVN a rychle si na nový styl práce zvykl.

Teprve mnohem později jsem začal používat veřejné SVN. Pokud si odmyslím nezpochybnitelné komunitní výhody, jako je spolupráce více vývojářů a přidaný rozměr pro chápání kódu (čas), nepřineslo to z hlediska jednotlivce nic pozitivního. Nešlo pracovat offline, dříve okamžité operace trvaly dlouhé sekundy. Jakákoliv chyba byla navždy zvěčněna v historii repositáře. Zjistil jsem, že během vývoje dílčích částí zase verzuji RARem a Subversion mi přestal pomáhat.

Oči mi otevřel až Karmi, když mi ukázal, že kromě centralizovaných repositářů, jako je SVN, existují i distribuované (DVCS), které všechny zmíněné problémy řeší. Jsou umístěny lokálně s celou historií, takže nepotřebují internet a reagují bleskově. Lze v nich zkušebně rozvíjet několik vývojových cest. Ty slepé smažete, správnou pustíte na „centrální“ repositář. Úžasné! A tím výčet výhod nekončí.

Přejít na distribuovaný verzovací systém mi vyplynulo jako nutnost.

Jaký distribuovaný systém zvolit?

Karmi propaguje Git, který současné úložiště mých projektů Google Code nepodporuje. Nabízí však alternativu v podobě systému Mercurial (HG). Kromě těchto dvou je ještě slyšet o Bazaar. Který z nich zvolit? Jak se liší?

Pustil jsem se do důkladné rešerše a zjistil, že dobrat se odpovědi není vůbec snadné. Protože Subversion ve prospěch distribuovaných systémů opouští čím dál více projektů (jen PHP nyní slavně přešlo na SVN, hehehe), narazil jsem na tyto analýzy:

• Chosing a distributed VCS for the Python
• Analysis of Git and Mercurial by Google

Z obou je cítit bezradnost a ačkoliv volba padla na Mercurial, důvody nesouvisí s objektivní kvalitou systémů. Navíc za poslední půl rok se hodně změnilo a zmíněná absence GUI pro Windows v případě Gitu je dnes naopak jeho předností (tj. už má skvělé GUI).

Z dalších úvah jsem vyřadil nejmladší a nejméně populární Bazaar a podíval se zblízka na Git s Mercurialem.

Git

• obrovský a komplexní projekt (možná až zmatený a nesrozumitelný)
• umožňuje zasahovat do historie, mazat slepé větve
• domovem je mu Linux, na Windows to není úplně ono
• napsaný v C a shell skriptech
• import i export SVN včetně historie
• hosting: Github.com (mnohem lepší než Google Code)
• GUI nástroj: TortoiseGit (vypadá přesně jako TortoiseSVN) a GIT Cheetah
• dokumentace (český překlad, začátečníkům nesrozumitelná)
• cheat sheet

Mercurial

• malý a chytrý (ovládáním podobný SVN)
• nelze zasahovat do historie
• výborně funguje na všech platformách
• napsaný především v Pythonu
• import SVN včetně historie
• hosting: Bitbucket.org (mnohem lepší než Google Code)
• GUI nástroj: TortoiseHg (jen se vzdáleně blíží TortoiseSVN)
• dokumentace (anglická, ale čtivá a srozumitelná)
• cheat sheet

Na rozpacích

Od začátku mi byl sympatičtější Mercurial, protože mám raději malé, šikovné a promyšlené věci, než molochy (nejen ve frameworcích). Lépe funguje na Windows (import SVN repositáře je 70× rychlejší než na Git). Podporuje jej Google Code.

Jenže svět je složitější. Příklad: Mercurial má srozumitelnější příkazovou řádku, podobnou té v SVN. Jenže stejně ho budu ovládat pomocí GUI. Tam naopak (dnes) vede TortoiseGit, který jako by z oka vypadl TortoiseSVN, zatímco TortoiseHg je hodně jiný a slabší. Ale tím, že je jiný, umožňuje commitovat tzv. hunks. Což se mi skutečně často hodí. Nicméně s distribuovaným repositářem přichází jiný styl práce – budu i poté potřeboval hunks?

Mercurial čísluje revize, Git používá 40 místný hash. Preferuju samozřejmě číslo, ale není to jen pozůstatek SVN uvažování?

A tak by se dalo pokračovat dále. Nejsem zatím schopen říct, který ze systémů více vyhovuje mým potřebám. Jediná možnost je oběma věnovat několik dní času a zkusit s nimi pracovat. Co však můžu říct s naprostou jistotou je, že SVN chci opustit.

Jak penetrují mladí chlapci?

Mladí chlapci se musejí vymezovat proti autoritám. Mají to v popisu práce. V diskusi neváhají nedostatek zkušeností nahradit sebejistotou a drzostí. Fakt hloupé to začíná být ve chvíli, kdy vlastně jen nahrazují.

Martin Klubal alias Emkei, administrátor serveru Soom.cz, se poměrně ostře pustil do Jakuba Vrány pod článkem o bezpečnostním auditu serveru Na volné noze. Na věci je pikantní, že Martin Klubal je Jakubův konkurent, neboť provozuje službu Pentester komerčně nabízející bezpečnostní audity webových aplikací.

Obdivuju Jakuba, s jakou trpělivostí se nechal penetrovat mladistvým script kiddie, já bych ho asi smazal hned v zárodku. Jakub je v tomto směru až hyperkorektní a jsem přesvědčen, že si tak poškozuje své jméno. Když totiž diskusi přečte neodborník, nemusí mu být úplně zřejmé, kdo je tady vlastně za diletanta. Čtenář potřebuje vodítko a proto vznikl tento článek.

Takže vězte: Martin Klubal alias Emkei je úplně mimo. Patří do sorty tzv. „bezpečnostních odborníků“, kteří tohoto sice hodně načetli, jenže při čtení vůbec nepřemýšleli. Vědí o spoustě útoků, ale nemají páru o technickém pozadí a neví, jak jim skutečně čelit. Na argumenty nejsou schopni reagovat jinak, než odkazováním na (dle jejich názoru) autoritativní zdroje, tedy v tom lepším případě, v tom horším se uchylují k osobním útokům. Dokážou však udělat výborný první dojem a ohromit množstvím znalostí. Že jsou jejich rady kontraproduktivní, se nemusí hned zjistit.

Emkei script

Ale zpět k diskusi. Emkei upozorňuje na útok upload null byte, který prý souvisí s nastavením direktivy magic_quotes_gpc a prý znemožňuje kontrolu nahraného obrázku na základě jeho přípony. Diskuse poté kráčí ve výše popsaných šlépějích, takže o upload null byte útoku nebo direktivě magic_quotes_gpc se od něj nedozvíme vůbec nic, zato se dočteme, že Jakub je blázen, stahovačný (sic!), líný hlupák a tak vůbec ;)

V jedné chvíli však Emkei neprozřetelně utrousí moudra a podělí se o kus PHP kódu. Ten by měl demostrovat zmíněný null byte útok, vtipné však je, že prakticky na každém řádku je nějaká chyba. Od méně závažných po naprosto fatální bezpečnostní díru:

if (strtolower(substr($HTTP_POST_FILES['obrazek']['name'], -4, 4)) == ".jpg") {
        $path= "upload/".urldecode($HTTP_POST_FILES['obrazek']['name']);
        if($ufile != none) {
                if(move_uploaded_file($HTTP_POST_FILES['obrazek']['tmp_name'], $path))
                        echo "Obrazek byl uspesne nahran na server";
                else
                        echo "Obrazek se nepodarilo nahrat na server";
        }
} else
        echo "Neplatny format obrazku";

Jen bodově:

• pole $HTTP_POST_FILES bylo zavrženo už v roce 2001, jeho použití mě docela překvapilo
• neověřuje existenci prvku $HTTP_POST_FILES['obrazek']['name'] a může tak generovat neošetřené E_NOTICE
• neověřuje, že prvek $HTTP_POST_FILES['obrazek']['name'] je řetězec a může tak generovat neošetřené E_NOTICE (viz <input type="file" name="obrazek[]">)
• urldecode() nemá v kódu co dělat. Pokud budete uploadovat soubor nazvaný třeba 70%absinth.jpg, na straně serveru byste dostali 70«sinth.jpg
• urldecode() je místo, kde se zcela uměle vytváří díra „upload null byte“
• podmínka if($ufile != none) pracuje s nedefinovanou proměnnou $ufile a nedefinovanou konstantou none
• kód neřeší situaci, kdy $ufile == none, ať už je tím myšleno cokoliv
• ke složce upload přistupuje relativně, takže se může chovat velmi nepředvídatelně
• ale hlavně: dovoluje přepsat jakýkoliv jpg na webovém serveru, tedy i mimo adresář pro upload! (např. %2e%2e%2fobr.jpg)
• kvůli uměle vytvořené „upload null byte“ díře dovoluje přepsat jakýkoliv soubor na webu (např. .htaccess%00.jpg)

Všechny tři řádky obsahující konstrukci echo se zdají být bez problému. Gratulujeme!

Na závěr bych Martinovi vzkázal jeho vlastní slova: chtel bych videt hlupaky, co ti za to tvoje bezpecnostni skoleni plati bezmala 5 000,– Kc. venuj se dal php a neprodavej lidem falesny pocit bezpeci v podobe amaterskych bezpecnostnich auditu… A firmám, které Pentester uvádí ve svých referencích (např. Webnode, Web4ce) doporučuji, aby si nechaly udělat audit také jinde.

Orgasmy PHP 5.3 nevítají

Přichází trošku jako opozdilec, pro kterého včera večer byla přichystána velkolepá oslava, ale dnes už se hosté rozešli domů. Před rokem a půl byl internet plný článků o klíčových novinkách v PHP 5.3, po neustálém odkládání termínů a méně příjemných změnách nadšení vychladlo.

5 – 4 – 3 – 2 – 1 DOWNLOAD!

Jaké jsou novinky? Podstatné. Vezmu to podle důležitosti:

• podpora jmenných prostorů, oddělovačem je zpětné lomítko (Nette\Web\Html)
• late static binding, statické metody konečně ví, nad kterou třídou jsou volány
• lambda funkce a uzávěry (nakonec bez podpory $this), metoda __invoke
• overloading pro statické metody via __callStatic()
• vylepšený garbage collection, který si poradí s cyklickými referencemi
• výjimky mohou odkazovat na předchůdce, getPrevious()
• nativní driver pro komunikaci MySQL a PHP (z pohledu programátora se API nemění)
• nová rozšíření ext/sqlite3, ext/phar (článek), ext/intl, ext/fileinfo, ext/enchant
• rozšíření syntaxe o zkrácený ternární operátor ?:, NOWDOC a goto (ajáj)
• magická konstanta __DIR__ nahrazující mantru dirname(__FILE__)
• obrovská řada drobných změn u stávajících funkcí (velmi podrobně u Jakuba)
• rozšířeny schopnosti parseru php.ini (ale omezena flexibilita INI parseru jako takového)
• odstraněn zend.ze1_compa­tibility_mode

To klíčové přijde v následujících týdnech: jak rychle se PHP 5.3 rozšíří? Vzhledem k tomu, že bylo vyvíjeno jako přirozený nástupce řady 5.2 bez zpětně nekompatibilních změn, šance na brzké rozšíření rozhodně má. Nicméně si myslím, že hostéři budou čekat, až vyjde následující setinková verze. Jako když se u Windows čekává na první service pack.

Historie jim přitom dává za pravdu:

• PHP 5.0.0, které vyšlo s rozdílem 14 dní právě před pěti lety, bylo použitelné cca od verze 5.0.3.
• PHP 5.1.0 existovalo pouhé 4 dny a bylo nahrazeno 5.1.1, za dva týdny 5.1.2.
• PHP 5.2.0 bylo opět případem zabugované verze, kde smutnou roli sehrál Debian.

(Totiž Debian Etch má tuto verzi předinstalovanou a nepochopitelný konzervatismus správců vede k tomu, že odmítají PHP updatovat, bo „jen to, co je v Debianu, je stabilní.“)

Přeji PHP 5.3 rychlý a úspěšný nástup do světa!