012345

}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Vkládán´ı obecnych ´ souboru˚ do XML pˇredpisu automatizovanych ´ testu˚ ˇ A´ PR ACE ´ B AKAL A´ RSK

Pavel Holica

Brno, podzim 2013

Prohlásˇ en´ı ˚ Prohlaˇsuji, zˇ e tato bakalárˇ ská práce je mym ım autorskym ´ puvodn´ ´ d´ılem, které jsem vypracoval samostatnˇe. Vˇsechny zdroje, prameny a literaturu, které jsem pˇri vypracován´ı pouˇz´ıval nebo z nich cˇ erpal, v práci rˇ a´ dnˇe cituji ´ s uveden´ım upln´ eho odkazu na pˇr´ısluˇsny´ zdroj.

Vedouc´ı práce: Mgr. Marek Grác, Ph.D. ii

Podˇekován´ı Rád bych podˇekoval vedouc´ımu práce Mgr. Marku Grácovi, Ph.D. za pevné nervy pˇri veden´ı této práce a za vstˇr´ıcnost. Dále také dˇekuji Bc. Mariánu Ganiˇsinovi za konzultace v technickych ´ oblastech. Také bych rád podˇekoval ´ ˚ e tipy v systému Bc. Michalu Kovaˇr´ıkovi a Mgr. Luboˇsi Kardoˇsovi za ruzn´ Beaker. Nakonec pak také vˇsem, kteˇr´ı trpˇelivˇe provedli korekturu, pˇredevˇs´ım pak Janˇe a Pavle Kratochv´ılovym. ´

iii

Kl´ıcˇ ová slova test, automatizované testován´ı, soubor, XML, dokument, Python, databáze, ´ kodov´ an´ı, data, metadata, parametr

iv

Shrnut´ı Práce je organizována v poˇrad´ı od analyzy ´ problému k jeho postupnému rˇ eˇsen´ı. V prvn´ıch dvou kapitolách je popsán formát XML a systém na spousˇ tˇen´ı automatizovanych ´ testu˚ Beaker [1]. V pˇredposledn´ı kapitole je hlubˇs´ı analyza ´ problému vkládán´ı souboru˚ do pˇredpisu testu a návrh jak soubory do pˇredpisu um´ıstit. V posledn´ı kapitole je pak popsaná samotná implementace v systému Beaker.

v

Obsah 1

2

3

XML . . . . . . . . . . . . . . . . 1.1 Elementy . . . . . . . . . . . 1.2 Atributy . . . . . . . . . . . 1.3 Soubor v XML . . . . . . . . 1.4 Binárn´ı data v XML . . . . . Beaker . . . . . . . . . . . . . . . 2.1 Architektura . . . . . . . . . 2.1.1 Server . . . . . . . . 2.1.2 Labcontroller . . . . 2.1.3 Testovac´ı prostˇred´ı . 2.2 Instalace a konfigurace . . . 2.2.1 Instalace . . . . . . . 2.2.2 Konfigurace sluˇzeb . 2.2.3 Server . . . . . . . . 2.2.4 Labcontroller . . . . 2.2.5 Testovac´ı systémy . . 2.3 Scénárˇ testu . . . . . . . . . 2.3.1 Task . . . . . . . . . 2.3.2 Recipe . . . . . . . . 2.3.3 Recipeset . . . . . . . 2.3.4 Job . . . . . . . . . . Soubory v pˇredpisu testu . . . . 3.1 Data . . . . . . . . . . . . . . ´ 3.1.1 Kodov´ an´ı . . . . . . 3.1.2 Typ souboru . . . . . 3.2 Um´ıstˇen´ı souboru . . . . . . 3.2.1 Relativn´ı cesta . . . . 3.2.2 Absolutn´ı cesta . . . 3.2.3 Aktualizace . . . . . 3.3 Metadata . . . . . . . . . . . 3.3.1 Atributy souboru . . 3.3.2 Pokroˇcilá oprávnˇen´ı

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 4 5 5 5 6 6 6 7 7 8 8 8 9 9 10 10 11 11 12 12 13 13 13 14 15 15 15 15 16 16 17 1

4

3.4 XML Element file . . . . . . . . . . . . . . . . ´ Upravy v Beakeru . . . . . . . . . . . . . . . . . . . 4.1 XML schéma . . . . . . . . . . . . . . . . . . . 4.2 Server . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Databáze . . . . . . . . . . . . . . . . . 4.2.2 Zpracován´ı XML pˇredpisu . . . . . . 4.2.3 Generován´ı XML pˇredpisu . . . . . . 4.3 Testovac´ı prostˇred´ı . . . . . . . . . . . . . . . 4.3.1 Zpracován´ı XML pˇredpisu . . . . . . 4.3.2 Um´ıstˇen´ı souboru na testovac´ı systém 4.3.3 Vytvoˇren´ı souboru s metadaty . . . . 4.3.4 Aktualizace testu . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

17 19 19 20 20 21 22 23 23 24 24 25

2

´ Uvod Bˇehem intenzivn´ıho pouˇz´ıván´ı a vytvárˇ en´ı testu˚ v systému Beaker jsem spoleˇcnˇe s kolegy mnohokrát narazil na omezen´ı tohoto systému v nemoˇz˚ jako parametr celé soubory. Typicky se jednalo o tesnosti pˇredávat testum ty, jejichˇz podstatou bylo pˇreinstalovat operaˇcn´ı systém na testovac´ım systému a pro tuto instalaci bylo potˇreba dodat konfiguraˇcn´ı soubor popi˚ suj´ıc´ı, jakym má byt ´ zpusobem ´ novy´ systém nainstalován a konfigurován. ˚ V jinych pˇr´ıpadech se jednalo o konfiguraˇcn´ı soubory sluˇzeb a nástroju. ´ Tyto situace jsme museli rˇ eˇsit uvnitˇr testu, kde takové soubory byly bud’ souˇca´ st´ı samotného testu, nebo je bylo nutné generovat (pˇr´ıpadnˇe upravovat jiˇz existuj´ıc´ı konfiguraˇcn´ı soubory). Moˇznost pˇredat soubor jako parametr testu vyb´ız´ı k pouˇzit´ı tohoto mechanismu k pˇr´ımému nahrazen´ı souboru na testovac´ım systému souborem pˇredanym, aniˇz by byla od testu ´ ´ celu poˇzadovaná jakákoliv cˇ innost. k tomuto uˇ ˇ Castokr´ at jsme se setkali i s pˇr´ıpadem, kdy bylo nutné provést jednorázovou aktualizaci testu, která nebyla v souladu s bˇezˇ nym ´ testován´ım. I zde by bylo moˇzné vyuˇz´ıt tuto novou vlastnost a pˇr´ımo tak nahradit soubor v testu souborem pˇredanym. ´ Vˇsechny zm´ınˇené pˇr´ıpady lze (a cˇ asto to tak i bylo) rˇ eˇsit pˇredán´ım textového parametru obsahuj´ıc´ıho URL, na kterém se nacházel dany´ soubor. ´ Takové rˇ eˇsen´ı vˇsak vyˇzaduje upravu testu, nen´ı vˇzdy moˇzné a nav´ıc pˇri opˇetovném spuˇstˇen´ı testu s takovym ´ parametrem jiˇz nemus´ı byt ´ tento soubor na daném URL dostupny. ´ Také by bylo moˇzné pˇredávat jako parametr testu soubor, nad kterym ´ je pˇr´ımo provádˇen test. Proto je vhodné umoˇznit pro takovy´ soubor napˇr´ıklad nastaven´ı pˇr´ıstupovych ´ práv pro testy ovˇerˇ uj´ıc´ı, zda lze dany´ soubor pˇrecˇ ´ıst nebo spustit.

3

Kapitola 1

XML XML [2] (extensible markup language) je znaˇckovac´ı jazyk slouˇz´ıc´ı k reprezentaci neprázdné n-árn´ı stromové struktury ve formˇe cˇ itelné cˇ lovˇeku. V tomto jazyce se pouˇz´ıvaj´ı alfanumerické znaky a nˇekolik znaku˚ specia´ ln´ıch (které jsou ovˇsem také souˇca´ st´ı základn´ı znakové sady ASCII). Názvy ˚ podtrˇz´ıtka, pomlˇcky a teˇcky; v XML jsou sloˇzeny z alfanumerickych ´ znaku, nesm´ı zaˇc´ınat cˇ ´ıslem, pomlˇckou, ani teˇckou. Vrcholy jsou v XML oznaˇcovány jako elementy a ohodnocen´ı vrcholu˚ ˇ lze provést pomoc´ı parametru˚ pˇriˇrazenych elementu. XML neumoˇznuje ´ ohodnocovat hrany, coˇz ovˇsem nen´ı u stromové struktury problém, jelikoˇz ohodnocen´ı hrany lze ekvivalentnˇe rˇ eˇsit ohodnocen´ım vrcholu. XML poskytuje v´ıce moˇznost´ı, neˇz je popsáno v této kapitole (napˇr. jmenné prostory), ale ty nejsou pro tuto práci potˇrebné a ani pouˇzitelné.

1.1

Elementy

Element, jakoˇzto vrchol, má svého rodiˇce (s vyjimkou koˇrenového elemen´ tu) a potomky. Rodiˇcem je vˇzdy element a potomky mohou byt ´ elementy, ˇ text, nebo text kombinovany´ s elementy. Posledn´ı zminovan y´ pˇr´ıpad (kombinovany´ obsah) je vhodny´ pro dokumenty obsahuj´ıc´ı strukturovany´ text. V textu se mohou vyskytovat libovolné znaky ze znakové sady dokumentu, kromˇe znaku˚ pouˇz´ıvanych ´ XML (jde o &, > a <). Tyto znaky mus´ı byt ´ vloˇzeny jako XML entity, které jsou reprezentovány sekvenc´ı &n´ azev;, kde název je pojmenován´ı entity. Entitami lze vyjádˇrit libovolny´ znak, a to bud’ názvem, nebo cˇ ´ıslem znaku v pouˇzité znakové sadˇe. Pokud se v textu vy˚ je vhodnˇejˇs´ı text um´ıstit do CDATA [3] sekce, skytuje v´ıce takovych ´ znaku, která je uvozena sekvenc´ı . V této ˚ ze vyskytovat libovolny´ text, ktery´ neobsahuje sekvenci znaku˚ sekci se muˇ pouˇzitou pro ukonˇcen´ı CDATA sekce. 4

1. XML

1.2

Atributy

˚ ze m´ıt libovolné mnoˇzstv´ı atributu, ˚ pˇriˇcemˇz atribut se skládá Element muˇ ˚ ze byt z názvu a hodnoty. Hodnotou atributu pak muˇ ´ témˇerˇ libovolny´ jednoˇra´ dkovy´ rˇ etˇezec znaku˚ ze znakové sady dokumentu (typicky UTF-8 [4]), kde je hodnota ohraniˇcena apostrofy, nebo uvozovkami. V hodnotˇe se nesm´ı vyskytovat tytézˇ znaky, které nejsou povoleny v textu elementu, a také se zde nesm´ı vyskytovat znak pouˇzity´ k ohraniˇcen´ı. Ten lze vˇsak um´ıstit po˚ moc´ı XML entity. Z tˇechto duvod u˚ jsou atributy vhodné pro popis obsahu ´ elementu nebo pro jednoduˇssˇ´ı udaje.

1.3

Soubor v XML

Vzhledem k popsanym ´ vlastnostem XML dokumentu je vhodné soubor um´ıstit do samostatného elementu, kde metadata (název, pˇr´ıstupová práva a jiné atributy) jsou um´ıstˇena v atributu a data souboru v jeho textu. V pˇr´ıpadˇe potˇreby um´ıstˇen´ı komplikovanˇejˇs´ıch metadat souboru lze uvaˇzovat i o rˇ eˇsen´ı, kdy pro kaˇzdá taková metadata je vytvoˇren novy´ element, a data souboru je pak nutné um´ıstit do textu samostatného elementu pojmenovaného data. Tyto nové elementy budou pak potomky elementu reprezentuj´ıc´ıho soubor.

1.4

Binárn´ı data v XML

Aˇckoliv existuje zápis XML dokumentu v binárn´ım formátu, nen´ı tento zápis obvykly´ a bˇezˇ nˇe pouˇz´ıvany. ´ Binárn´ı data nelze pˇr´ımo um´ıstit do XML dokumentu (jedná se totiˇz o textovy´ dokument), lze ovˇsem pˇrevést data ´ ´ souboru na textová data pomoc´ı vhodného kodov´ an´ı a následnˇe tato zakodovaná data vloˇzit do textu elementu.

5

Kapitola 2

Beaker ˚ uloˇzen´ı Beaker je systém pro spouˇstˇen´ı automatickych ´ softwarovych ´ testu, jejich vysledk u˚ a následnou prezentaci. Tento systém je dostupny´ pod li´ cenc´ı GNU GPL 2 a novˇejˇs´ı a je aktivnˇe vyv´ıjen a pouˇz´ıván spoleˇcnost´ı Red Hat a jej´ımi partnery. V souˇcasné dobˇe uvaˇzuje o pouˇzit´ı tohoto systému i komunita organizovaná kolem projektu Fedora, ktery´ je sponzorován spoleˇcnost´ı Red Hat. Tento systém je napsán v programovac´ım jazyce Python [5] s vyuˇzit´ım mnoha rozˇsiˇruj´ıc´ıch knihoven, mezi jinymi také SQLAlchemy [7] a je urˇcen ´ pro bˇeh v prostˇred´ı operaˇcn´ıho systému (dále OS) Red Hat Enterprise Linux 6 (dále RHEL), nebo v jiném kompatibiln´ım OS. Beaker je vytvoˇren jako webová aplikace s XMLRPC [8] rozhran´ım, coˇz poskytuje uˇzivateli moˇznost systém flexibilnˇe pouˇz´ıvat, nezávisle na j´ım preferovaném OS. Pro webové rozhran´ı je pouˇzit Apache web server [9], ve kterém je Beaker spuˇstˇen jako WSGI aplikace [10]. Beaker pouˇz´ıvá pro organizaci dat o testovac´ıch systémech, uˇzivatel´ıch apod. databázovy´ systém MySQL [11].

2.1

Architektura

Systém Beaker je sloˇzen z následuj´ıc´ıch cˇ a´ st´ı: server (dále Server), labcontrollery a testovac´ı prostˇred´ı. Server a labcontroller mohou byt ´ instalovány na jednom systému, v praxi ovˇsem byv´ ´ a labcotrolleru˚ v´ıce a jsou um´ıstˇeny na geograficky rozd´ılnych ´ m´ıstech. 2.1.1 Server ˚ daServer je stˇredovym ´ bodem celého Beakeru. Stará se o databázi testu, ˚ databázi testovac´ıch systému, ˚ autentizaci a autorizaci tabázi labcontrolleru, ˚ pˇr´ıjem poˇzadavku˚ na spuˇstˇen´ı testu, ˚ plánován´ı spuˇstˇen´ı testu, ˚ uˇzivatelu, ˚ Testy jsou v souˇcasné ukládán´ı vysledk u˚ testu˚ a presentaci vysledk u˚ testu. ´ ´ 6

2. B EAKER ˇ ı definovat poˇzadavky dobˇe uloˇzeny v RPM [12] bal´ıcˇ c´ıch, které umoˇznuj´ testu˚ na software i hardware. 2.1.2 Labcontroller Labcontroller má na starosti zdroje softwaru pro instalace, ovládán´ı testovac´ıch stroju˚ a spouˇstˇen´ı testu˚ na testovac´ıch systémech. V aktualn´ı verzi Beakeru to znamená automatizovanou instalaci OS (za pouˇzit´ı kickstart [13] souboru) ze s´ıtˇe, pˇriˇcemˇz labcontroller nastav´ı prostˇred´ı pro s´ıt’ovy´ boot testovaného systému a následnˇe provede potˇrebnou akci pro spuˇstˇen´ı testovaného stroje (typicky pomoc´ı protokolu pro vzdálenou správu). Pro instalaci OS je pouˇzit s´ıt’ovy´ zdroj softwaru definovany´ labcontrollerem (typicky m´ıstn´ı zdroj pro testovac´ı systém). Po instalaci je OS nakonfigurován tak, zˇ e spust´ı testovac´ı prostˇred´ı. Od poˇca´ tku instalace bˇezˇ ´ı tzv. watchdog, ktery´ kontroluje, zda nˇekterá z akc´ı netrvá pˇr´ıliˇs dlouho. Pokud ano, test nebo instalace je ukonˇcena bez moˇznosti pokraˇcovan´ı dalˇs´ım testem. V budoucnu je v plánu nam´ısto nároˇcné instalace pouˇz´ıt takzvané cloudové rˇ eˇsen´ı, kde se rovnou spust´ı virtuáln´ı stroj s jiˇz nainstalovanym ´ OS a provedou se pouze drobné zmˇeny nutné pro spuˇstˇen´ı testovac´ıho prostˇred´ı pro naplánovany´ test. 2.1.3 Testovac´ı prostˇred´ı Testovac´ı prostˇred´ı (nebo také harness) je software bˇezˇ ´ıc´ı na pˇripraveném ´ testovac´ım systému. Jeho ukolem je zprostˇredkovávat komunikace mezi testem a labcontrollerem. Testovac´ı prostˇred´ı nejdˇr´ıve zjist´ı, ktery´ test má byt parametry, poté test nainstaluje, nastav´ı promˇenné ´ spuˇstˇen a s jakymi ´ prostˇred´ı a test spust´ı. Následnˇe mu test sdˇeluje vysledky a prostˇred´ı je ´ pˇredává labcontrolleru. ˚ Testovac´ı prostˇred´ı také poskytuje prostˇredky pro synchronizaci testu, která je potˇrebná pro takzvané multihost testy, tj. testy, které bˇezˇ ´ı na v´ıce ˚ systémech souˇcasnˇe a kde se testuje interakce systému. Posledn´ı funkce, kterou testovac´ı prostˇred´ı poskytuje, je tzv. local watchdog, ktery´ kontroluje, zda test netrvá delˇs´ı dobu, neˇz o sobˇe deklaruje. Pokud ano, tak test ukonˇc´ı a pokraˇcuje spuˇstˇen´ım dalˇs´ıho testu. Local watchdog se liˇs´ı od watchdogu na labcontrolleru t´ım, zˇ e jiˇz má moˇznost ˚ ze tento plnˇe ovládat testovac´ı systém, a tak pˇri selhán´ı jednoho testu muˇ test násilnˇe ukonˇcit a pokraˇcovat testem dalˇs´ım. Pokud ovˇsem z jakéhoko˚ ˚ nefunkˇcn´ımu local watchliv duvodu selˇze testovac´ı prostˇred´ı (at’ uˇz kvuli ˚ ze dog nebo napˇr. problému s pˇredáván´ım vysledk u˚ labcontrolleru) muˇ ´ 7

2. B EAKER watchdog na labcontrolleru ukonˇcit cely´ test.

2.2

Instalace a konfigurace

Projekt Beaker na svych webovych stránkách poskytuje kickstart soubor ´ ´ pro instalaci operaˇcn´ıho systému CentOS [14] 6 spolu s Beakerem a dalˇs´ım poˇzadovanym ´ softwarem. Dále pak poskytuje skripty pro základn´ı konfiguraci Beakeru. Beaker a labcontroller jsou obvykle instalovány jako samostatné systémy vzájemnˇe komunikuj´ıc´ı po s´ıti, lze je vˇsak provozovat na jednom systému souˇcasnˇe a pro vyvoj vlastnost´ı na architektuˇre nezávislych ´ ´ je to naprosto dostaˇcuj´ıc´ı. Toto rˇ eˇsen´ı je popsáno na webu projektu Beaker i s potˇrebnou konfigurac´ı. Bohuˇzel je i pˇri tomto rˇ eˇsen´ı poˇzadováno, aby byl systém um´ıstˇen v s´ıti, nad kterou má uˇzivatel plnou kontrolu, lze vˇsak zvolit i ménˇe nároˇcné rˇ eˇsen´ı, a to za pomoci hardwarové virtualizace, která je dnes jiˇz bˇezˇ nˇe dostupná. Virtualizace (spolu s vlastnostmi linuxového jádra) poskytuje moˇz˚ které mohou tyto s´ıtˇe nost vytvárˇ en´ı virtuáln´ıch s´ıt´ı a virtuáln´ıch stroju, plnˇe spravovat. Lze tak vytvoˇrit virtuáln´ı prostˇred´ı, bl´ızˇ ´ıc´ı se bˇezˇ nému pouˇzit´ı systému Beaker. Tato volba ovˇsem nen´ı na webu projektu Beaker zm´ınˇena a nepoˇc´ıtá se s n´ı.

2.2.1 Instalace Systém Beaker je moˇzné nainstalovat na RHEL 6 nebo CentOS 6 napˇr. za pomoci kickstart souboru dostupného na webu projektu Beaker. Také lze OS nainstalovat manuálnˇe a potˇrebny´ software vˇcetnˇe Beakeru následnˇe doinstalovat. Na systému, kde je Server, je instalován bal´ıcˇ ek beaker-server a na systému s labcontroller je beaker-lab-controller.

2.2.2 Konfigurace sluˇzeb Pro korektn´ı fungován´ı Beakeru je potˇreba, aby byla správnˇe nakonfigurována s´ıt’, s´ıt’ové instalaˇcn´ı zdroje, labcontrollery a testovac´ı systémy. Z pohledu s´ıtˇe je pˇredevs´ım nutné, aby mˇel Server, labcontrollery a testovac´ı ˚ S t´ımto souvis´ı systémy nastaveny FQDN [15] vˇcetnˇe reverzn´ıch záznamu. i pˇridˇelován´ı IP adres pomoc´ı protokolu DHCP [16] a bootován´ı ze s´ıtˇe za pomoci tohoto protokolu a protokolu TFTP [17]. 8

2. B EAKER 2.2.3 Server Pro Server je pˇredevˇs´ım potˇreba vytvoˇrit MySQL databázi a jej´ıho uˇzivatele, které bude Beaker pouˇz´ıvat. Jakmile je databáze pˇripravena, vytvoˇr´ı pˇr´ıkaz beaker-init -u admin -p heslo -e [email protected] ´ ctu s danym tabulky nutné pro provoz a záznam o administrátorském uˇ ´ heslem a e-mailovou adresou. Následnˇe je moˇzné se pˇrihlásit ve webovém rozhran´ı na adrese http://example.com/bkr/login s novˇe vytvoˇrenym ´ ´ ctem. administrátorskym ´ uˇ ˚ Na webu Po pˇrihlásˇ en´ı uˇz zbyv´ ´ a jen nahrán´ı testu˚ do databáze testu. ´ ˚ které jsou urˇceny projektu Beakeru jsou k dispozici ulohy (ve formˇe testu), ´ k základn´ım operac´ım s testovac´ımi systémy. Tyto ulohy jsou: /distribution/install, /distribution/reservesys a ´ /distribution/inventory. Uloha install je puˇstˇena jako prvn´ı po instalaci OS, a provede základn´ı kontrolu, zda instalace probˇehla v poˇra´ d˚ cen´ı systému uˇzivateli nebo pro manuáln´ı kontrolu a diagnosku. Pro zapujˇ ´ ´ tiku probˇehlych reservesys. Posledn´ı základn´ı ulohou ´ testu˚ slouˇz´ı uloha ´ celem je z´ıskán´ı informac´ı o testovac´ım systému, je inventory, jej´ımˇz uˇ ´ ´ u˚ zpˇet do na kterém je tato uloha spuˇstˇena, a následnˇe odeslán´ı tˇechto udaj ´ cely vytvoˇren´ı databáze hardwaru testovac´ıch systému. ˚ Beakeru pro uˇ Posledn´ım krokem je povolen´ı a spuˇstˇen´ı sluˇzby beakerd. 2.2.4 Labcontroller V pˇr´ıpadˇe labcontrolleru je konfigurace jednoduˇssˇ´ı, je potˇreba jej pouze registrovat na Serveru a upravit konfiguraˇcn´ı soubor. Na adrese http://example.com/bkr/labcontrollers/new se pro registraci uvede FQDN, uˇzivatelské jméno, které bude pˇriˇrazeno labcontrolleru, k nˇemu odpov´ıdaj´ıc´ı heslo a email pro labcontroller. V souboru /etc/beaker/labcontroller.conf se nastav´ı URL Serveru (HUB URL), uˇzivatelské jméno a heslo, které bude labcontroller pouˇz´ıvat. Jak bylo vyˇ ´ se zm´ınˇeno, labcontroller má na starosti spouˇstˇen´ı insta˚ ze byt lace na testovac´ıch systémech, a proto muˇ ´ zapotˇreb´ı nastavit adresárˇ , ktery´ pouˇz´ıvá TFTP server (volba TFTP ROOT v konfiguraˇcn´ım souboru). Posledn´ım krokem je povolen´ı spuˇstˇen´ı sluˇzeb beaker-proxy, beaker-watchdog a beaker-provision. Pokud je zˇ a´ douc´ı ukládat záznamy o vysledc´ ıch testu˚ jinde neˇz na labcontrolleru, je potˇreba upravit ´ pˇr´ısluˇsné volby v konfiguraˇcn´ım souboru labcontrolleru a povolit a spustit sluˇzbu beaker-transfer. Jakmile jsou sluˇzby labcontrolleru spuˇstˇeny, je potˇreba pˇridat do labcontrolleru zdroj pro instalaci softwaru a OS, coˇz lze 9

2. B EAKER provést pomoc´ı pˇr´ıkazu beaker-import s argumentem URL, ukazuj´ıc´ım na ˚ instalaˇcn´ı zdroj RHEL, nebo systému pouˇz´ıvaj´ıc´ı stejny´ zpusob instalace, jako je CentOS nebo Fedora.

2.2.5 Testovac´ı systémy Na testovac´ıch systémech samotnych ´ je potˇreba nastavit pouze bootorder tak, zˇ e prvn´ı poloˇzkou bude boot ze s´ıt’ové karty a následnˇe z datového ´ ziˇstˇe (typicky z pevného disku). uloˇ Dále je nutno kaˇzdy´ novy´ testovac´ı systém zaregistrovat na Serveru. Registrace prob´ıhá na adrese http://example.com/bkr/new, kde je potˇreba nastavit název systému, pˇriˇcemˇz názvem je FQDN systému a pouˇz´ıvá ˚ zitou se pro pˇreklad na IP adresu pro nastaven´ı s´ıt’ové instalace. Dalˇs´ı duleˇ volbou je Lab controller, kde se vybere ten labcontroller, ktery´ spravuje s´ıt’ovou instalaci pˇridávaného systému. Posledn´ı volbou tykaj´ ´ ıc´ı se nasta˚ zitá pro vybˇ ven´ı s´ıtˇe je MAC adresa, která je duleˇ ´ er primárn´ı s´ıt’ové karty, kterou má testovac´ı systém pouˇz´ıvat pro instalaci. ˚ Po registraci systému je jeˇstˇe zapotˇreb´ı nastavit zpusob spouˇstˇen´ı testovac´ıho systému. Pro spuˇstˇen´ı podporuje Beaker nejenom bˇezˇ né proto˚ ale také wake on lan pomoc´ı takkoly pro vzdálenou správu serveru, zvaného magic packetu a protokol pro správu virtuáln´ıch systému˚ spravovanych sluˇzbou libvirt. Pro virtuáln´ı systémy jde o poloˇzku virsh, ´ kde se u parametru Power Address nastav´ı qemu+ssh:IP_ADRESA, kde IP ADRESA patˇr´ı systému se sluˇzbou libvirt. Pro Power Login se nastav´ı pˇrihlaˇsovac´ı jméno (vzdáleného) uˇzivatele, ktery´ má oprávnˇen´ı ovládat sluˇzbu libvirt. Posledn´ım krokem je vygenerován´ı SSH kl´ıcˇ e pro ˚ erysprávu (pokud jiˇz neexistuje) a pˇridán´ı veˇrejného kl´ıcˇ e do seznamu duvˇ hodnych ´ pro uˇzivatele na serveru s libvirt sluˇzbou. Operace s SSH kl´ıcˇ i je potˇreba provést pouze jednou pro kaˇzdy´ server provozuj´ıc´ı libvirt ´ u˚ o hardsluˇzbu. Pro otestován´ı konfigurace a nahrán´ı dodateˇcnych udaj ´ ´ waru je vhodné naplánovat ulohu /distribution/inventory.

2.3

Scénárˇ testu

Scénárˇ e testu jsou v systému Beaker definovány pomoc´ı XML stromové struktury, která odpov´ıdá RelaxNG schématu. 10

2. B EAKER 2.3.1 Task Základn´ı jednotkou pˇredpisu testu je test a jeho parametry. Test je specifikován elementem task s XML parametry name a role, kde name je název ´ ´ testu/ulohy a role specifikuje roli ulohy – zda jde o samostatnˇe bˇezˇ ´ıc´ı test, ˚ zité nebo zda jde o server, client, peer nebo jinou roli. Nastaven´ı role je duleˇ ˚ u multihost testu. Parametry testu se nacházej´ı v elementu params, kde je pro kaˇzdy´ parametr pˇr´ıtomen element param s XML atributy name a value. Vˇsechny parametry jsou pˇred spuˇstˇen´ım testu zpracovány, a podle nich jsou nastaveny promˇenné prostˇred´ı. Protoˇze jsou hodnoty tˇechto promˇennych prostˇred´ı ´ urˇceny pomoc´ı XML atributu, nen´ı moˇzné pouˇz´ıt napˇr. v´ıceˇra´ dkové hodnoty, a nelze tak pomoc´ı nich nastavit libovolnou hodnotu.

2.3.2 Recipe Elementy task jsou organizovány v rámci elementu recipe s t´ım, zˇ e jsou ´ jednotlivé ulohy spouˇstˇeny v poˇrad´ı, v jakém jsou pˇr´ıtomny v elementu recipe. Recipe jiˇz specifikuje celou sekvenci cˇ innost´ı, vˇcetnˇe instalace, která je na testovac´ım systému provedena. Pomoc´ı elementu hostRequires lze pomoc´ı sady pravidel specifikovat, ˚ má systém vyhovovat (napˇr. se má jednat o systém jakym ´ poˇzadavkum se cˇ tyˇrmi a v´ıce gigabyty pamˇeti, dvˇema s´ıt’ovymi kartami a dvˇema proce´ sory). V rámci recipe je nutné specifikovat i poˇzadavky na operaˇcn´ı systém v elementu distroRequires (napˇr. zˇ e má test probˇehnout na OS CentOS 5.9 architektury x86 64). Dále lze specifikovat dodateˇcné repozitárˇ e softwaru, které se pouˇzij´ı pˇri instalaci, a seznam bal´ıcˇ ku˚ softwaru, které maj´ı byt ´ nainstalovány. Pro instalaci lze nastavit cely´ pˇredpis automatické instalace ve formátu kickstart souboru, a to v textu elementu kickstart, coˇz je pouˇz´ıváno pro instalaˇcn´ı testy, nebo pro testy vyˇzaduj´ıc´ı specifické nastaven´ı hardwaru. Pokud nen´ı potˇreba specifikovat cely´ pˇredpis, ale pouze jeho cˇ a´ st, lze pouˇz´ıt element ks appends a jeho podelementy ks append, jejichˇz text bude pˇripojen na konec vygenerovaného pˇredpisu pro automatickou instalaci. Pro instalaci jeˇstˇe lze nastavit parametry jádra pˇred instalac´ı pomoc´ı XML atributu kernel options a po instalaci pomoc´ı atributu kernel options post. ´ cePro recipe je také vhodné nastavit XML atribut whiteboard, jehoˇz uˇ ´ lem je popisovat ulohu testu˚ a testovac´ıho systému v rámci pˇredpisu testu. 11

2. B EAKER 2.3.3 Recipeset Aby bylo moˇzné provádˇet takzvané multihost testy, je tˇreba tyto testy svázat do skupiny, která je synchronizována a je u n´ı zajiˇstˇeno, zˇ e budou spusˇ tˇeny na testovac´ıch systémech v rámci jedné lokality, tj. obsluhované jed´ celum ˚ jsou elementy recipe um´ıstˇeny v Recin´ım labcontrollerem. K tˇemto uˇ peset, ktery´ zajiˇstuje splnˇen´ı zm´ınˇenych ´ potˇreb. Pro recipeset lze i definovat ˚ prioritu, která je vzata v potaz pˇri plánován´ı spouˇstˇen´ı testu. 2.3.4 Job Job je koˇrenovym ´ elementem celého pˇredpisu testu a obsahuje jeden nebo ˚ ze a nev´ıce recipeset. Pouˇz´ıvá se ke sdruˇzen´ı testu˚ do sady, která muˇ mus´ı obsahovat synchronizované testy. Testy v elementech recipe, které nevyˇzaduj´ı synchronizaci, je vhodné um´ıstit do samostatnych elementu˚ ´ recipeset, jinak by instalace testovac´ıch systému˚ a samotné testy byly zbyteˇcnˇe zpoˇzdˇeny cˇ ekán´ım na pˇridˇelen´ı testovac´ıch systému pro vˇsechny recipe, na dokonˇcen´ı cˇ asovˇe nároˇcnych instalac´ı na pomalejˇs´ıch systé´ ˚ které spolu nesouvis´ı. mech a na skonˇcen´ı testu, Pro job lze specifikovat pomoc´ı XML elementu retention tag, jak dlouho maj´ı byt testu zaznamenány. Dále lze nastavit i skupinu ´ vysledky ´ uˇzivatelu˚ Beakeru, které takovy´ job náleˇz´ı a jej´ızˇ cˇ lenové maj´ı právo job ruˇsit. Velice vhodné je i nastavit popis jobu v textu elementu whiteboard.

12

Kapitola 3

Soubory v pˇredpisu testu Soubory, jakoˇzto parametry testu, se v Beakeru vázˇ ou na element task v pˇredpisu testu, a proto je vhodné um´ıstit soubor do tohoto elementu, podobnˇe jako jsou zde um´ıstˇeny textové parametry. Bylo by sice moˇzné um´ıstit cely´ soubor vˇcetnˇe metadat do textové infomace, a tedy i do jiˇz pˇr´ıtomného parametru testu, avˇsak takto rˇ eˇseny´ soubor by byl pro uˇzivatele obt´ızˇ nˇe cˇ itelny, ´ souborová data by nebyla logicky jednoznaˇcnˇe oddˇelena od textovych ´ dat a nebyl by plnˇe vyuˇzit potenciál formátu XML.

3.1

Data

Jak jiˇz bylo zm´ınˇeno dˇr´ıve, souborová data nemohou byt ´ obecnˇe pˇr´ımo ´ um´ıstˇena v XML, a proto je potˇreba data zakodovat tak, aby se jednalo o textová data. Pokud uvaˇzujeme o adresárˇ i jako o souboru a o jeho poda˚ dresárˇ´ıch jako jeho obsahu, je nutné tato data nˇejakym sloˇzit do ´ zpusobem takzvaného archivu, indikovat, zˇ e jde o archiv, a pˇri um´ıstˇen´ı na testovac´ı ˚ náleˇzitˇe pˇristoupit. systém k tˇemto datum 3.1.1 Kodov´ ´ an´ı Data, která nelze pˇr´ımo vloˇzit do XML, je nutné pˇrevést do jiného formátu. ˚ ´ ´ Preferovany´ zpusob v prostˇred´ı internetu je Base64 [18] kodov´ an´ı. Toto ko˚ dován´ı je vyuˇz´ıváno pro pˇrenos libovolnych dat pomoc´ı bˇezˇ nych znaku, ´ ´ ’ a t´ım také zajiˇst uje bezproblémovy´ pˇrenos dat na systémech, které by po˚ Tento formát tenciálnˇe mohly m´ıt problém pˇri zpracován´ı urˇcitych ´ znaku. je nav´ıc i d´ıky své známosti a specifickému vzhledu na prvn´ı pohled rozpo´ znatelny´ a pro uˇzivatele jednoduˇse dekodovateln y´ (napˇr. pomoc´ı nástroje Base64 pˇr´ıtomného v kaˇzdé souˇcasné Linuxové distribuci). ´ Protoˇze se v pˇr´ıpadˇe Base64 jedná o bezztrátové kodov´ an´ı (data jsou po ´ ´ dekodov´ an´ı totoˇzná s daty pˇred zakodov´ an´ım) a je znaˇcnˇe omezena abe´ ceda (znaky pˇr´ıpustné pro kodov´ an´ı), mus´ı nutnˇe vznikat i reˇzie, a ta tvoˇr´ı ˚ jednu tˇretinu velikosti puvodn´ ıch dat. 13

ˇ 3. S OUBORY V P REDPISU TESTU ´ Pro textová data je pouˇzito kodov´ an´ı UTF-8, které je pˇrirozené pro XML. Nˇekteré soubory mohou také obsahovat data, která se opakuj´ı, a je tak moˇzné na takové soubory aplikovat kompresn´ı algoritmus a data prostorovˇe optimalizovat, coˇz vede k uˇsetˇren´ı m´ısta pˇri ukládán´ı souborovych ´ dat ’ ˚ pˇri zpracován´ı pˇredpisu v systému Beaker, k menˇs´ım pamˇet ovym ´ nárokum scénárˇ e testu a také k menˇs´ımu mnoˇzstv´ı pˇrenesenych ´ dat po s´ıti pˇri pˇredáván´ı scénárˇ e testovac´ımu prostˇred´ı. Bohuˇzel kompresn´ı algoritmy typicky produkuj´ı binárn´ı data, která je poté nutné pˇrevést do dat textovych. ´ Jsou ovˇsem pˇr´ıpady, kde je tento postup pˇresto vhodny, ´ a to napˇr´ıklad pˇri ˚ ktery´ zarovnává velikost vysledn´ vkládán´ı archivu souboru, eho souboru ´ ˚ ze tak data o velikosti bytu˚ archivovat do na násobek urˇcité jednotky, a muˇ ˚ Následná aplikace komprimaˇcn´ıho algoritmu souboru velikosti kilobytu. ˚ ze velikost dat vrátit na jednotku bytu. ˚ V takovém pˇr´ıpadˇe je uspora ´ muˇ ´ vˇetˇs´ı neˇz prostorová reˇzie Base64 kodov´ an´ı. ´ Protoˇze lze kodov´ an´ı rˇ etˇezit (napˇr. dˇr´ıve zm´ıneny´ archiv je zkompri´ mován a následnˇe zakodov´ an pomoc´ı Base64), je nutné indikovat i celou ´ cel muˇ ˚ ze byt posloupnost. Pro tento uˇ ´ pouˇzit zápis posloupnosti, kde prvky ´ jsou oddˇeleny znakem, ktery´ se nesm´ı nacházet v názvu kodov´ an´ı, napˇr. bˇezˇ nˇe pouˇz´ıvanou cˇ a´ rkou, nebo jinym ´ oddˇelovaˇcem. Jako vhodny´ oddˇeloˇ vaˇc se jev´ı lom´ıtko, které vizuálnˇe znázornuje vrstven´ı.

3.1.2 Typ souboru ˚ souboru pˇriJak jiˇz bylo zm´ınˇeno, v urˇcitych ´ pˇr´ıpadech je nutno k datum ˚ stupovat rozd´ılnym a tento pˇr´ıpad je nutno indikovat. Jedna ´ zpusobem moˇznost, jakou lze tuto informaci podat, je vyuˇzit´ı formátu MIME [19], ktery´ je k tomu pˇr´ımo urˇceny´ a je také bˇezˇ nˇe v internetovych ´ technologi´ıch pouˇz´ıvany. ´ Pro data, která nepotˇrebuj´ı dalˇs´ı zpracován´ı, jsou pouˇzity typy text/plain pro textová data a application/octet-stream pro data binárn´ı. Pro adresárˇ se pouˇz´ıvá vlastn´ı“ typ apllication/x-tar, ktery´ indikuje, zˇ e ” jde o archiv souboru˚ vytvoˇreny´ pomoc´ı nástroje tar. Tento typ nen´ı souˇca´ st´ı ˚ proto je nutno pouˇz´ıt typ vlastn´ı. Vlastn´ı typy standardn´ı sady MIME typu, jsou v MIME definovány tak, zˇ e zaˇc´ınaj´ı na x-. Tento zvoleny´ MIME typ pro archiv je bˇezˇ nˇe pouˇz´ıván v Unixovych ´ prostˇred´ıch a stal se de facto standardn´ım. Dalˇs´ımi typy souboru by mohly byt ´ napˇr´ıklad i symbolické odkazy, kde data jsou cesta na odkazovany´ soubor, nebo URL, kde data mohou byt ´ URL souboru, jehoˇz obsah má byt ´ pˇr´ıtomen ve vysledn´ em souboru. ´ 14

ˇ 3. S OUBORY V P REDPISU TESTU

3.2

Um´ıstˇen´ı souboru

Cesta souboru definuje, v jakém adresárˇ i má byt ´ soubor um´ıstˇen a jak se má ˚ ze slouˇzit nejen jako parametr testu, ale také soubor jmenovat. Soubor muˇ k náhradˇe souboru pˇr´ıtomného na testovac´ım systému, k náhradˇe souboru ´ cely testován´ı nové verze testu, nebo pro rychlou aktualizaci v testu, pro uˇ ´ bez nutnosti trvalé upravy testu. Moˇznost nahradit soubor v testovac´ım ˇ systému umoˇznuje pˇredávat konfiguraˇcn´ı soubory pro software, ktery´ má byt ´ testován, a nen´ı tak nutné pˇredávat vˇsechny podstatné volby v tomto souboru obsaˇzené jako jednotlivé textové parametry testu. Dalˇs´ı vyhodou ´ ˚ ˚ ze je, zˇ e o takto pˇredaném souboru nemus´ı test vubec vˇedˇet, a d´ıky tomu muˇ ´ testu kratˇs´ı. byt ´ i kod

3.2.1 Relativn´ı cesta Soubor lze pˇredat s relativn´ı cestou, tj. cestou, která je vztaˇzena k pracovn´ımu adresárˇ i. Tento adresárˇ je vytvoˇren testovac´ım prostˇred´ım pˇri pˇr´ıpravˇe spuˇstˇen´ı testu a jsou do nˇej vloˇzeny vˇsechny soubory, které maj´ı cestu relativn´ı (vyjma souboru˚ oznaˇcenych ´ jako aktualizaˇcn´ı). V unixovych ´ systémech je taková cesta urˇcena tak, zˇ e zaˇc´ıná libovolnym ´ znakem jinym ´ ˚ neˇz lom´ıtko a stejny´ zpusob je pouˇzit i v tomto rˇ eˇsen´ı.

3.2.2 Absolutn´ı cesta Soubory zaˇc´ınaj´ıc´ı znakem lom´ıtko, tj. soubory s absolutn´ı cestou, jsou um´ıstˇeny do koˇrenového adresárˇ e pod danou cestou. Koˇrenovym ´ adresárˇ em je adresárˇ vytvoˇreny´ testovac´ım prostˇred´ım, takˇze pokud nen´ı soubor oznacˇ en jako aktualizaˇcn´ı, chová se absolutn´ı cesta stejnˇe jako relativn´ı.

3.2.3 Aktualizace ˚ ze byt Soubor muˇ ´ XML atributem update oznaˇcen jako aktualizaˇcn´ı, a v tomto pˇr´ıpadˇe se stává pracovn´ım adresárˇ em adresárˇ , ve kterém je um´ıstˇen test, a koˇrenovym ´ adresárˇ em je koˇrenovy´ adresárˇ testovac´ıho systému. To znamená, zˇ e aktualizaˇcn´ı soubor s relativn´ı cestou je um´ıstˇen do adresárˇ e ˚ ze tak nahradit soubor testu. Pˇri absolutn´ı cestˇe pak muˇ ˚ ze zase testu, a muˇ soubor aktualizovat systémové soubory, napˇr. konfiguraˇcn´ı soubory sluzˇ eb. 15

ˇ 3. S OUBORY V P REDPISU TESTU

3.3

Metadata

K souboru jsou mimo jeho názvu pˇriˇrazena i dalˇs´ı metadata, jako jsou napˇr´ıklad vlastn´ık souboru a pˇr´ıstupová práva. Dále lze také nastavit pokroˇcilá oprávnˇen´ı, pomoc´ı takzvaného Access Control List (ACL). 3.3.1 Atributy souboru Atributy souboru lze nastavit XML atributem attrs. Atributy souboru mohou byt ´ vyuˇzity pro testován´ı nástroju˚ – ovˇerˇ uje se u nich, zda pˇristupuj´ı ˚ korektn´ım zpusobem ˚ ˚ k souborum vzhledem k jejich atributum. Atributy ˚ ze byt muˇ ´ nutné specifikovat i pro urˇcité konfiguraˇcn´ı soubory, u kterych ´ je ´ vyˇzadováno, aby mˇely napˇr. specifická pˇrıstupová práva nebo vlastn´ıka. ˚ Zpusob nastaven´ı atributu˚ pomoc´ı jednoho XML atributu byl zvolen ˚ z duvodu rozˇsiˇritelnosti. Kdyby byl pro kaˇzdy´ atribut samostatny´ XML atribut, bylo by nutné pro novˇe pˇridany´ atribut aktualizovat schéma databáze a zpracován´ı pˇredpisu testu na stranˇe serveru. V pˇr´ıpadˇe jednoho XML atributu obsahuj´ıc´ıho vˇsechny atributy souboru je pouze nutné aktualizovat testovac´ı prostˇred´ı, aby aplikovalo tyto atributy na soubor. Nav´ıc se atributy souboru liˇs´ı v závislosti na operaˇcn´ım systému, a tak pˇri pˇridán´ı ´ podpory pro novy´ operaˇcn´ı systém nen´ı nutna zˇ a´ dná uprava. ˚ ze obsahovat v´ıce ruzn ˚ ych ˚ a tak je poTento XML atribut muˇ ´ atributu, tˇreba definovat oddˇelovaˇc, pomoc´ı kterého lze jednoznaˇcnˇe tyto atributy rozdˇelit. Jelikoˇz jde v podstatˇe o seznam, nab´ız´ı se moˇznost z nˇekolika z ob˚ a to cˇ a´ rka, dvojteˇcka a stˇredn´ık. Dvojteˇcka (u SELinux vyklych ´ oddˇelovaˇcu, [20] atributu) i cˇ a´ rka (u pˇr´ıstupovych ´ práv) se mohou vyskytnout v atributu souboru, a proto je nejvhodnˇejˇs´ı volbou stˇredn´ık. Jakmile je seznam rozdˇelen na jednotlivé atributy, mohou byt ´ tyto atributy ve formátu atribut=hodnota (napˇr. owner=root pro nastaven´ı vlastn´ıka souboru), nebo pˇr´ımo název atributu (napˇr. readonly pro soubor oznaˇceny´ pouze pro cˇ ten´ı). D´ıky této vlastnosti lze pˇredávat jak atributy s hodnotou, tak atributy pravdivostn´ı (atribut je aplikován, nebo pˇr´ıpadnˇe odebrán). Atributy, které lze nastavit souboru jsou: owner, group, mode a selinux. Vˇsechny tyto atributy jsou s hodnotou. Atributy owner a group urˇcuj´ı vlastn´ıka a skupinu souboru, kde hodnotou je název uˇzivatele resp. skupiny nebo cˇ ´ıslo uˇzivatele resp. skupiny. Atributem mode lze urˇcit pˇr´ıstupová práva souboru. Hodnotou pro tento atribut je cˇ ´ıslo zadané v osmicˇ kové soustavˇe akceptované unixovym ´ nástrojem chmod [21] a je i stejnym ´ ˚ zusobem interpretováno. Posledn´ım atributem je selinux, ktery´ urˇcuje 16

ˇ 3. S OUBORY V P REDPISU TESTU selinux kontext [22] pˇriˇrazeny´ souboru. Kontext je dvojteˇckou oddˇelená ´ ˇ Popis technologie SELinux je cˇ tveˇrice, urˇcuj´ıc´ı uˇzivatele, roli, typ a urove n. nad rámec této práce a v´ıce informac´ı je dostupnych na webu ´ http://www.selinuxproject.org/. 3.3.2 Pokroˇcilá oprávnˇen´ı ˚ lze nastavit (pokud to umoˇznuje ˇ Souborum systém souboru˚ pouˇzity´ na testovac´ım systému) i pokroˇcilá oprávnˇen´ı ve formˇe ACL. Tato technika ˇ ˚ a skupinám, neˇz jsou umoˇznuje definovat uprávnˇen´ı i jinym ´ uˇzivatelum ˇ ı nastavit i vychoz´ vlastn´ık a skupina souboru. Jde-li o adresárˇ , umoˇznuj´ ı ´ oprávnˇen´ı, se kterymi bude vytvoˇren kaˇzdy´ novy´ soubor v takovém ad´ ˇ ı nastavit i základn´ı resárˇ i. Pokroˇcilá oprávnˇen´ı ve formˇe ACL umoˇznuj´ pˇr´ıstupová práva souboru. Jako formát pro pokroˇcilá oprávnˇen´ı je pouˇzit formát pouˇz´ıván nástroji getfacl a setfacl [23]. V tomto formátu je kaˇzdy´ záznam na samostatném rˇ a´ dku jako dvojteˇckou oddˇelená trojice nebo cˇ tveˇrice. Prvn´ım (volitelnym) ´ prvkem je indikátor, zda jde o vychoz´ ı nastaven´ı, pro soubory vytvoˇrené ´ v tomto adresárˇ i. Druhym ´ prvkem je urˇcen´ı, zda jde o uˇzivatele, skupinu, cˇ i masku. Tˇret´ı (volitelny) ´ prvek urˇcuje, o jakou skupinu, nebo o jakého uˇzivatele se jedná. V pˇr´ıpadˇe masky je tento prvek prázdny, ´ pro uˇzivatele jde pˇri prázdné hodnotˇe o vlastn´ıka souboru, pro skupinu jde o skupinu souboru. Posledn´ım (ˇctvrtym) prvkem jsou pˇr´ıstupová práva, urˇcuj´ıc´ı prá´ vo ke cˇ ten´ı (r), zápisu (w) a spuˇstˇen´ı (x) u souboru, nebo v pˇr´ıpadˇe adresárˇ e právo ke vstupu do adresárˇ e. Vyhodnocen´ı tˇechto oprávnˇen´ı nen´ı jednoduché, pro zjednoduˇsen´ı se ovˇsem dá rˇ´ıci, zˇ e oprávnˇen´ı se vyhodnocuje od obecnˇejˇs´ıch (práva skupiny souboru) po konkrétn´ı (práva testovaného uˇzivatele v ACL), kde konkrétnˇejˇs´ı oprávnˇen´ı má vˇetˇs´ı váhu. Protoˇze je zápis pokroˇcilych ´ oprávnˇen´ı na ˚ je vhodnˇejˇs´ı tyto udaje ´ v´ıce rˇ a´ dku, um´ıstit do textu samostatného elementu.

3.4

XML Element file

Textové parametry testu jsou reprezentovány elementy param, které jsou um´ıstˇeny v elementu params uvnitˇr elementu task. Navrhované rˇ eˇsen´ı se rˇ´ıd´ı podobnou hierarchi´ı, a to elementy file um´ıstˇeny v elementu files uvnitˇr elementu task. Element file má dále atributy: name, update, type, encoding, attrs. Vˇsechny atributy kromˇe name jsou nepovinné. Atribut name slouˇz´ı k urˇcen´ı názvu a um´ıstˇen´ı souboru. Atribut update slouˇz´ı k indikaci, zda je soubor urˇcen k aktualizaci a má byt ´ um´ıstˇen v ad17

ˇ 3. S OUBORY V P REDPISU TESTU resárˇ i testu, resp. k um´ıstˇen´ı souboru v rámci celé adresárˇ ové struktury testovac´ıho systému. Atribut type urˇcuje, zda maj´ı byt ´ data souboru zpra˚ cována jinym neˇz pˇr´ımym ´ zpusobem ´ um´ıstˇen´ım souboru. Encoding ur˚ ´ cˇ uje, jakym jsou data zakodov´ ana a jakou posloupnost´ı maj´ı byt ´ zpusobem ´ ´ dekodov´ ana. Attrs obsahuje jednotlivé atributy souboru, pˇrednˇe vlastnictv´ı a pˇr´ıstupová práva. Mimo atributy obsahuje element file i elementy data a acl. V elementu data jsou v textu (pˇr´ıpadnˇe uvnitˇr cdata sekce) um´ıstˇena data sou˚ ´ boru. Stejnym jako data (kromˇe kodov´ an´ı) jsou pak uloˇzena po´ zpusobem kroˇcilá oprávnˇen´ı v elementu acl.

18

Kapitola 4

´ Upravy v Beakeru ˚ v systému Beaker, bylo nutné upraAby bylo moˇzné pˇredat soubory testum vit Server, testovac´ı prostˇred´ı a schéma, které kontroluje, zda je XML s pˇredpisem testu ve správném formátu.

4.1

XML schéma

Pro ovˇerˇ en´ı správnosti struktury dokumentu ve formátu XML (tedy i pˇredpisu testu v systému Beaker) slouˇz´ı validaˇcn´ı schéma. Pro validaci XML dokumentu˚ existuje nˇekolik typu˚ schémat. Nejzákladnˇejˇs´ım a nejˇcastˇeji podporovanym ´ je DTD (Document Type Definition) [24], které slouˇz´ı k ovˇerˇ en´ı ˚ pˇriˇcemˇz XML jazyk tvoˇr´ı podsprávnosti struktury SGML dokumentu, mnoˇzinu SGML, takˇze lze pouˇz´ıt DTD i pro validaci XML. Aˇckoliv je DTD sˇ iroce podporované, bylo jiˇz pˇrekonáno, a to napˇr´ıklad schématem RelaxNG [25], které je standardizováno mezinárodnˇe uznávanymi organi´ zacemi ISO i IEC. Systém Beaker pouˇz´ıvá pro ovˇerˇ en´ı správnosti struktury pˇredpisu testu v dokumentu XML právˇe RelaxNG. Vyhodou tohoto formátu schématu ´ je, zˇ e je samo dokumentem XML a je také jednoduˇse srozumitelné. RelaxNG je pouˇz´ıváno jak Serverem, tak i nástroji komunikuj´ıc´ımi se Serverem. Schéma pro validaci pˇredpisu testu bylo nutné upravit tak, aby mohli Server a nástroje akceptovat pˇredpisy testu obsahuj´ıc´ı soubory. Toto schéma ´ se nacház´ı ve zdrojovych systému Beaker v adresárˇ i Common/bkr/ ´ kodech common/schema pod jménem beaker-job.rng. ˚ ze byt Souˇca´ st´ı RelaxNG schématu muˇ ´ i dokumentace a d´ıky tomu je schopno popisovat nejen strukturu dokumentu, ale i vyznam jednotlivych ´ ´ prvku˚ a lze jej pouˇz´ıt k automatizovanému generován´ı dokumentace. Soucˇ a´ st´ı provedenych ´ zmˇen je i tato dokumentace ve validaˇcn´ım schématu. Byl zde pˇridán do elementu task volitelny´ element files, obsahuj´ıc´ı element ˚ Pro element file jsou zde také uvefile o libovolném poˇctu vyskyt u. ´ deny atributy name, update, type, encoding a attrs, pˇriˇcemˇz vˇsechny 19

´ PRAVY V B EAKERU 4. U kromˇe name jsou volitelné a u atributu update jsou vyjmenované platné hodnoty True a False. Souˇca´ st´ı RelaxNG schéma nejsou narozd´ıl od DTD ˚ Dále jsou pak uvedeny definovány vychoz´ ı hodnoty volitelnych ´ ´ atributu. volitelny´ element acl a povinny´ element data, které se mohou vyskytovat v libovolném poˇrad´ı. Pro elementy je nutno definovat poˇrad´ı, narozd´ıl od ˚ u kterych atributu, ´ na poˇrad´ı nezáleˇz´ı.

4.2

Server

Pˇredpis testu je zpracováván Serverem a po zpracován´ı ukládá Server vˇsechny prvky pˇredpisu testu do databáze, aby bylo moˇzné zpˇetnˇe zjistit vˇsechny parametry testu, nebo test opˇetovnˇe spustit za stejnych ´ podm´ınek. 4.2.1 Databáze Aby mohly byt ´ soubory z pˇredpisu testu uloˇzeny do databáze, je nutné pˇrednˇe vytvoˇrit databázové struktury (tabulky v pˇr´ıpadˇe relaˇcn´ı databáze). K tomu je pouˇzita knihovna SQLAlchemy a databázová struktura je definována ve zdrojovém souboru Server/bkr/server/model.py, kde jsou definovány vˇsechny databázové struktury, které server pouˇz´ıvá. Pˇredpis testu nen´ı uloˇzen v jedné ucelené struktuˇre, ale je rozdˇelen na menˇs´ı cˇ a´ sti, které jsou provázány identifikátory. Kaˇzdy´ job, recipeset, recipe i task má pˇridˇeleny´ unikátn´ı identifikátor, v relaˇcn´ıch databázovych ´ systémech oznaˇcovany´ jako primárn´ı kl´ıcˇ . Struktura, která je vázána, obsahuje ciz´ı kl´ıcˇ , jehoˇz hodnotou je primárn´ı kl´ıcˇ struktury, ke které je vázána. D´ıky tomuto rozdˇelen´ı je moˇzno v databázi vytvárˇ et 1:M vazby, ˚ ze byt kde muˇ ´ jedné struktuˇre job pˇriˇrazeno v´ıce struktur recipeset, pro recipeset v´ıce recipe a pro jeden recipe v´ıce struktur task. Protoˇze ˚ ze m´ıt jeden task v´ıce parametru, ˚ je tato vazba pouˇzita i pro parametry muˇ ˚ testu. Stejnym jsou pˇriˇrazeny i soubory ke struktuˇre task ciz´ım ´ zpusobem kl´ıcˇ em recipe task id. Kaˇzdá struktura v databázi by mˇela m´ıt také jednoznaˇcny´ identifikátor ve formˇe primárn´ıho kl´ıcˇ e, a tak má i kaˇzdy´ soubor pˇriˇrazeny´ primárn´ı kl´ıcˇ id. Mimo tyto organizaˇcn´ı prvky, jsou ve struktuˇre souboru pˇr´ıtomny prv˚ a elementum ˚ pouˇzitym ky názvem odpov´ıdaj´ıc´ı atributum ´ u souboru v pˇredpisu testu, a to name, update, type, encoding, attrs, acl a data. Prvky name, type, encoding a attrs jsou typu unicode [26] rˇ etˇezce ˚ Tato velikost byla zvolena podle vzoru oso délce maximáln´ı 255ti znaku. tatn´ıch databázovych ´ struktur systému Beaker, pˇredevˇs´ım pak podle struktury recipe task param, která reprezentuje textové parametry testu. Pr20

´ PRAVY V B EAKERU 4. U vek update slouˇz´ı pro uloˇzen´ı pravdivostn´ı hodnoty, a tak je typu boolean. Pro prvek acl je pouˇzit datovy´ typ unicode o maximáln´ı délce ˚ Vˇetˇs´ı délka je zvolena z toho duvodu, ˚ 2048mi znaku. zˇ e se v tomto prvku ˚ ale tak jejich pˇr´ıstupová oprávnˇen´ı. Pˇri povyskytuj´ı nejen názvy souboru, ´ uˇzit´ı délky 255ti znaku˚ hroz´ı, zˇ e by tato délka nemusela pro tyto udaje postaˇcovat. ˚ zitˇejˇs´ı prvek databázové struktury souboru je prvek Posledn´ı a nejduleˇ ´ data, ktery´ je typu unicode. Velikost tohoto prvku nen´ı na urovni da´ tabáze nijak omezena, maximáln´ı délka je rˇ eˇsena na jiné urovni a nastavuje se v konfiguraˇcn´ım souboru. Pokud by byla maximáln´ı délka uvedena v definici databázové struktury souboru, nebylo by moˇzné flexibilnˇe nastavovat maximáln´ı velikost souboru v závislosti na okolnostech. Definovanou databázovou strukturu souboru bylo také nutno svázat se strukturu task, cˇ ehoˇz je doc´ıleno pomoc´ı nové python tˇr´ıdy RecipeTaskFile (podle vzoru RecipeTaskParam), která je pomoc´ı SQLAlchemy funkce mapper svázána s novˇe vytvoˇrenou databázovou strukturou a také je tato tˇr´ıda pomoc´ı této funkce svázána s tˇr´ıdou RecipeTask reprezentuj´ıc´ı strukturu task. 4.2.2 Zpracován´ı XML pˇredpisu Soubor v pˇredpisu scénárˇ e testu je nutno pˇri pˇrijet´ı na Serveru zpracovat a uloˇzit do databáze. V souboru Server/bkr/server/jobxml.py je do tˇr´ıdy XMLTask pˇridána metoda iter files (opˇet po vzoru zpracován´ı textovych ´ para˚ která je generátorem [27], a jej´ımˇz uˇ ´ celem je proj´ıt vˇsechny elemetru), menty file uvnitˇr elementu files a postupnˇe je pˇredat ve formˇe python objektu˚ tˇr´ıdy XMLFile, která dˇed´ı tˇr´ıdu ElementWrapper. Tato novˇe pˇridaná tˇr´ıda slouˇz´ı k pˇrevodu XML elemetu file na tˇr´ıdu jazyka python ˚ struktury souboru, a to pomoc´ı pˇret´ızˇ ené a transparentn´ı pˇr´ıstup k prvkum metody getattr , která je zavolána, kdyˇz je pˇristupováno k prvku tˇr´ıdy, a jej´ızˇ návratová hodnota je hodnotou poˇzadovaného prvku. ˚ poV této tˇr´ıdˇe jsou pˇr´ıtomny i vychoz´ ı hodnoty jednotlivych ´ ´ prvku, kud nejsou v pˇredpisu testu pˇr´ıtomny. Konstruktor této tˇr´ıdy XMLFile je zdˇedˇeny´ z tˇr´ıdy ElementWrapper a argumentem konstruktoru je XML element file reprezentovany´ objektem tˇr´ıdy Element z knihovny xmltramp [28]. V souboru jobxml.py je také rozˇs´ırˇ ena testovac´ı funkce tak, aby jej´ım vystupem byly i soubory pˇriˇrazené k testu. ´ Pro zpracován´ı struktury recipe (a dalˇs´ıch struktur v n´ı obsaˇzenych) ´ slouˇz´ı v souboru Server/bkr/server/jobs.py metoda 21

´ PRAVY V B EAKERU 4. U handleRecipe tˇr´ıdy Jobs. Do této metody bylo pˇridáno i zpracován´ı a uloˇzen´ı struktury file. Je zde pouˇzita vyˇ ´ se zm´ınˇená metoda iter files. Pˇred vytvoˇren´ım nového záznamu v databázi pro soubor je zkontrolováno, zda velikost souboru nepˇresahuje maximáln´ı velikost, urˇcenou v konfiguraˇcn´ım souboru. Pokud nen´ı v konfiguraˇcn´ım souboru zˇ a´ dná maximáln´ı velikost urˇcena, je nastavena na nulu, cˇ ´ımˇz jsou prakticky zakázány soubory jako parametry testu. Toto chován´ı bylo zvoleno s ohledem na potenciáln´ı pamˇet’ovou nároˇcnost zpracován´ı pˇredpisu testu bez vˇedom´ı uˇzivatelu˚ provozuj´ıc´ıch systém Beaker. Pokud je velikost menˇs´ı neˇz maximáln´ı, je vytvoˇren objekt RecipeTaskFile a následnˇe uloˇzen v databázi pˇriˇrazeny´ k testu, ke kterému je parametrem. 4.2.3 Generován´ı XML pˇredpisu ˇ Systém Beaker umoˇznuje znovu vygenerovat pˇredpis testu jiˇz probˇehlého, a tak bylo nutné pˇridat i opˇetovné generován´ı elementu file z databáˇ ast této funkcionality je pouˇz´ıvána i pro zovych ´ záznamu˚ této struktury. C´ pˇredáván´ı upraveného pˇredpisu testu testovac´ımu prostˇred´ı, které se j´ım ´ následnˇe rˇ´ıd´ı pˇri spouˇstˇen´ı jednotlivych ´ uloh. ˇ Tyto zmˇeny byly provedeny v dˇr´ıve zminovan´ em souboru Server/ bkr/server/model.py a jedná se o tˇr´ıdy RecipeTaskFile a RecipeTask a jejich metody to xml, které slouˇz´ı k vytvoˇren´ı XML elementu obsahovˇe shodného s objektem jazyka Python, na kterém je tato metoda zavolána. Ve tˇr´ıdˇe RecipeTask bylo pouze pˇridáno volán´ı metody to xml, pro kaˇzdy´ objekt tˇr´ıdy RecipeTaskFile pˇriˇrazeny´ testu, a následné vloˇzen´ı XML elementu˚ souboru˚ do elementu files, ktery´ je pˇridán do elemetu task. V metodˇe to xml tˇr´ıdy RecipeTaskFile je vytvoˇren XML element file a jsou mu nastaveny atributy name, update, type, encoding a attrs. Volitelné atributy jsou nastaveny, pouze po˚ kud byly v puvodn´ ım pˇredpisu zadány, a t´ım je zajiˇstˇena shodnost gene˚ rovaného pˇredpisu s pˇredpisem puvodn´ ım. Pro data souboru a pro pokroˇcilá oprávnˇen´ı jsou vytvoˇreny elementy data a acl, v kterych ´ je vytvoˇrena sekce CDATA. Do této sekce jsou následnˇe um´ıstˇena data, resp. pokroˇcilá oprávnˇen´ı. CDATA sekce slouˇz´ı k oznaˇcen´ı cˇ a´ sti textovych ´ dat, která by jinak nemohla byt ´ pˇr´ımo um´ıstˇena v textu elementu, napˇr. text obsahuj´ıc´ı znaky pouˇz´ıvané jazykem XML. Sekce CDATA je pˇri generován´ı pro zjednoduˇsen´ı vytvoˇrena vˇzdy, nezávisle na obsahu dat a na tom, jestli by mohla byt ´ pˇr´ımo pˇr´ıtomna v textovych ´ ˚ datech nebo ne. Pokud nebyla pokroˇcilá oprávnˇen´ı nastavena v puvodn´ ım pˇredpisu testu, nen´ı element acl vytvoˇren ani v generovaném pˇredpisu 22

´ PRAVY V B EAKERU 4. U testu.

4.3

Testovac´ı prostˇred´ı

ˇ ı pˇrijmout, uloˇzit a opˇet vygeneZmˇeny provedené na Serveru umoˇznuj´ rovat pˇredpis testu, je ovˇsem také potˇreba, aby tyto soubory v pˇredpisu testu byly pˇredány testu samotnému. K tomu slouˇz´ı testovac´ı prostˇred´ı, které zpracovává jednotlivé cˇ a´ sti pˇredpisu testu, a podle nich nastavuje promˇenné prostˇred´ı, spouˇst´ı testy a sleduje zda nˇejaky´ test nebˇezˇ ´ı delˇs´ı dobu, neˇz o sobˇe deklaruje. Bylo potˇreba pˇridat zpracován´ı souboru˚ z pˇredpisu testu a um´ıstit je na systém souboru˚ na testovac´ım systému. Tyto zmˇeny byly provedeny v testovac´ım prostˇred´ı Beah [?], které je v systému Beaker pouˇz´ıváno. Lze pouˇz´ıt i jiné testovac´ı prostˇred´ı, ovˇsem v dobˇe implementace nebylo zˇ a´ dné takové prostˇred´ı veˇrejnˇe k dispozici. Vˇsechny zmˇeny provedené v testovac´ım prostˇred´ı Beah byly v souboru backends/beakerlc.py, ktery´ obsahuje ´ pro komunikaci s labcontrollerem. kod 4.3.1 Zpracován´ı XML pˇredpisu Testovac´ı prostˇred´ı má k dispozici identifikátor struktury recipe uloˇzené v databáz´ı a podle nˇej je schopen z´ıskat od labcontrolleru pˇredpis testu s pˇridˇelenymi ´ identifikátory strukturám job, recipeset, recipe a task. Z tˇechto informac´ı je testovac´ı prostˇred´ı schopno extrahovat z pˇredpisu testu strukturu recipe, která obsahuje struktury task, popisuj´ıc´ı testy ˚ které maj´ı byt vˇcetnˇe parametru, ´ na testovac´ım systému provedeny. Bylo nutné upravit zpracován´ı elementu task ve tˇr´ıdˇe TaskParser a soubory (vˇcetnˇe jejich metadat) uloˇzit do atributu objektu této tˇr´ıdy. Veˇskerá data potˇrebná pro spuˇstˇen´ı testu jsou pak dostupná v návratové hodnotˇe metody task data, kam bylo potˇreba informace o souborech také pˇridat. ´ cely zpracován´ı souboru˚ byla v této tˇr´ıdˇe pˇridána metoda get files, Pro uˇ která pomoc´ı DOM [30] API (aplikaˇcn´ı rozhran´ı) z´ıská vˇsechny elementy ´ file pˇriˇrazené k právˇe zpracovávané uloze. Následnˇe pak z´ıská pomoc˚ Pro z´ıskán´ı nymi funkcemi (také vyuˇz´ıvaj´ıc´ımi DOM) hodnoty atributu. ´ textovych ´ dat z elementu byla potˇreba pˇridat pomocná funkce xml cdata, která najde vˇsechny cdata sekce v elementu a spoj´ı je do jednoho textu, kde jsou data spojena znakem nového rˇ a´ dku. Název souboru, dalˇs´ı metadata i data jsou uloˇzena ve struktuˇre dict jazyka python, která slouˇz´ı jako asociované pole (které k indexaci prvku˚ ˚ ze pouˇz´ıt libovolny´ objekt nebo ordináln´ı typ jazyka python). Seznam muˇ 23

´ PRAVY V B EAKERU 4. U ´ vˇsech souboru˚ pˇriˇrazenych je pak vrácen touto metodou. Volán´ı me´ uloze tody get files bylo pˇridáno do metody parse (tézˇ e tˇr´ıdy), kde je seznam zpracovanych ´ souboru˚ uloˇzen do atributu objektu (ktery´ je souˇca´ st´ı návratové hodnoty metody task data). 4.3.2 Um´ıstˇen´ı souboru na testovac´ı systém Pˇr´ıprava spuˇstˇen´ı testu je provedena spuˇstˇen´ım funkce vrácené funkc´ı run task (tato technika je pouˇz´ıvaná knihovnout twisted [31], kterou Beah ´ pouˇz´ıvá). Tato funkce potom má k dispozici udaje vrácené metodou task data tˇr´ıdy TaskParser, jejichˇz souˇca´ st´ı jsou i soubory a jejich metadata. Do funkce run task bylo pˇridáno vytvoˇren´ı dvou doˇcasnych ´ adˇ ˚ ´ ˚ resáru, kde prvn´ı slouˇzı k um´ıstˇen´ı souboru, které jsou parametry testu, a druhy´ adresárˇ pro soubory, které test aktualizuj´ı. V momentˇe, kdy je tato funkce spouˇstˇena, totiˇz nemus´ı byt ´ test jeˇstˇe nainstalovany, ´ a tak jej ani nen´ı moˇzné aktualizovat. Pro soubory ze seznamu z´ıskaného metodou get files je zavolána ´ novˇe pˇridaná funkce extract file, jej´ızˇ ulohou je vytvoˇrit soubor na testovac´ım systému s obsahem a metadaty, které jsou mu pˇredány ve formˇe struktury dict vytvoˇrené funkc´ı get files. Návratovou hodnotou funkce extract file je cesta k novˇe vytvoˇrenému souboru, nebo prázdny´ typ, pokud soubor nebyl vytvoˇren, nebo slouˇz´ı k aktualizaci testu. Toto chován´ı je vhodné pro rozeznán´ı, zda soubor je parametrem testu, a tud´ızˇ o nˇem má byt ´ test informován prostˇrednictv´ım promˇennych ´ prostˇred´ı, nebo se jedná o soubor, ktery´ aktualizuje test (nen´ı t´ım pádem parametrem), nebo sou˚ ˚ ze byt bor nebyl z jakéhokoliv duvodu vytvoˇren (takovy´ soubor také nemuˇ ´ parametrem). Pokud byl takto vytvoˇren alesponˇ jeden soubor, ktery´ je parametrem testu, je nastavena promˇenná prostˇred´ı testu TESTFILES, která obsahuje ˚ cˇ a´ rkami oddˇeleny´ seznam takovych ´ souboru. 4.3.3 Vytvoˇren´ı souboru s metadaty Jak bylo vyˇ ´ se zm´ınˇeno, soubory jsou vytvoˇreny na testovac´ım systému po´ moc´ı funkce extract file. Argumenty této funkce jsou: udaje o souboru (vˇcetnˇe jeho obsahu) reprezentované strukturou dict, adresárˇ kam maj´ı byt ´ um´ıstˇeny soubory, které jsou parametry testu, a adresárˇ , kde maj´ı byt ´ um´ıstˇeny soubory, které maj´ı slouˇzit k aktualizaci testu. Tato funkce nejdˇr´ıve sestav´ı absolutn´ı cestu k souboru podle názvu souboru a informace, zda má soubor slouˇzit k aktualizaci. Pokud soubor ne24

´ PRAVY V B EAKERU 4. U slouˇz´ı k aktualizaci a jeho název je absolutn´ı cestou, jsou poˇca´ teˇcn´ı lom´ıtka ˚ ci cestˇe k adresárˇ i urz cesty odstranˇena, a tato cesta se stává relativn´ı vuˇ ˚ které jsou parametry testu. Jakmile je celá cesta cˇ enému k uloˇzen´ı souboru, sestavena, jsou vytvoˇreny vˇsechny adresárˇ e v této cestˇe, které dosud neexistovaly. V názvu souboru˚ se tak mohou vyskytnout i adresárˇ e. ´ Po vytvoˇren´ı cesty k souboru následuje dekodov´ an´ı dat, která maj´ı byt ´ ´ ´ v tomto souboru. Pˇri dekodov´ an´ı je postupnˇe zpracováván udaj encoding, ´ ktery´ urˇcuje postup, jakym ana. Pokud se v seznamu ´ maj´ı byt ´ data dekodov´ ´ vyskytuje neznámé kodov´ an´ı, je dalˇs´ı zpracováván´ı takového souboru zastaveno a je vrácena prázdná hodnota indikuj´ıc´ı, zˇ e tento soubor nebylo ´ moˇzné vytvoˇrit. Dekodovan´ a data nejsou pˇr´ımo uloˇzena do souboru, ale ˚ ze byt jsou um´ıstˇena v promˇenné, protoˇze vysledn y´ soubor muˇ ´ ´ jiného typu, ktery´ potˇrebuje dodateˇcné zpracován´ı. Vyˇcerpán´ı pamˇeti na testovac´ım systému, by nemˇelo hrozit d´ıky nastaven´ı maximáln´ı velikosti na stranˇe Ser´ veru. V navrhované implementaci se zat´ım nacház´ı pouze moˇznost deko´ dovat data zakodovan´ a do Base64 nebo komprimovaná pomoc´ı gzip [32]. ´ ˚ Po dekodov´ an´ı dat následuje pˇr´ımé uloˇzen´ı souboru na systém souboru, nebo dodateˇcné zpracován´ı v závislosti na typu souboru. Momentálnˇe podporované typy jsou text/plain, application/octet-stream, které indikuj´ı, zˇ e soubor nevyˇzaduje dalˇs´ı zpracován´ı, a application/x-tar, ktery´ indukuje, zˇ e jde o archiv souboru˚ jehoˇz obsah má byt ´ um´ıstˇen do ad˚ ´ resárˇ e daného názvu (puvodnˇ e názvu souboru). Stejnˇe jako u kodov´ an´ı, pokud jde o neznámy´ typ, je dalˇs´ı zpracován´ı zastaveno a je vrácena prázdná hodnota. Po dodateˇcném zpracován´ı souboru, v závislosti na typu, je soubor (pˇr´ıpadnˇe adresárˇ ) pˇr´ıtomen na testovac´ım systému, a je tak moˇzné takovému souboru (nebo adresárˇ i) mˇenit jednotlivé atributy. Jsou tak nejdˇr´ıve aplikována (pokud jsou nastavena) pokroˇcilá oprávnˇen´ı a následnˇe atributy souboru. Mezi (v tomto rˇ eˇsen´ı) podporované atributy patˇr´ı: pˇr´ıstupová oprávnˇen´ı, vlastn´ık souboru, skupina souboru, a selinux kontext. Pokud je zadán neznámy´ atribut, nen´ı takovy´ atribut zpracován a pokraˇcuje se ˚ v aplikaci dalˇs´ıch atributu. Nakonec, pokud se nejednalo o aktualizaˇcn´ı soubor, vrát´ı funkce extract file cestu k novˇe vytvoˇrenému souboru, jinak vrát´ı prázdnou hodnotu. 4.3.4 Aktualizace testu Soubory, které slouˇz´ı k aktualizaci testu, tj. soubory s relativn´ı cestou oznacˇ ené jako aktualizaˇcn´ı, jsou um´ıstˇeny do doˇcasného adresárˇ e pˇri pˇr´ıpravˇe 25

´ PRAVY V B EAKERU 4. U prostˇred´ı a je nutné je um´ıstit do adresárˇ e s testem bezprostˇrednˇe pˇred jeho spuˇstˇen´ım. Beah pro spuˇstˇen´ı testu pouˇz´ıvá shellovy´ script, ktery´ je vytvoˇren pˇred ´ spuˇstˇen´ım testu a obsahuje posledn´ı ukony nutné k pˇr´ıpravˇe testu (vˇcetnˇe samotné instalace testu) a následnˇe i test spust´ı. Obsah tohoto spouˇstˇec´ıho souboru je generován metodou content ve tˇr´ıdˇe RHTSTask. Tuto metodu bylo nutné upravit tak, aby po instalaci testu a jeˇstˇe pˇred jeho spuˇstˇen´ım byly do adresárˇ e testu um´ıstˇeny aktualizaˇcn´ı soubory. Protoˇze byl pˇri um´ıst’ován´ı souboru˚ vytvoˇren adresárˇ urˇceny´ pro soubory, které maj´ı aktualizovat test, a byla také nastavena promˇenná prostˇred´ı, obsahuj´ıc´ı cestu k tomuto adresárˇ i, staˇc´ı pouze pˇresunout vˇsechny soubory z tohoto adresárˇ e do adresárˇ e testu. Pˇri pˇresunu jsou zachovány i dˇr´ıve aplikované atributy, takˇze nen´ı potˇreba dodateˇcnych ´ akc´ı. Po pˇresunu aktualizaˇcn´ıch souboru˚ je tento adresárˇ odstranˇen.

26

Závˇer ˚ a uˇzivatelum ˚ systému Beaker Návrh rˇ eˇsen´ı jsem prezentoval vyvoj´ ´ arˇ um v e-mailové konferenci, kde se prvotnˇe nesetkal s pozitivn´ı odezvou pˇre˚ devˇs´ım z duvodu nepochopen´ı rˇ eˇsené problematiky. Vyvoj´ ´ arˇ i mˇeli také ’ obavy z pamˇet ové nároˇcnosti na stranˇe Serveru, bohuˇzel se vˇsak jedná o návrhovou chybu samotného systému Beaker a pˇri rˇ eˇsen´ı tohoto problému je tato chyba v´ıce citelná. Pˇri implementaci byla (nejenom) z tohoto ˚ ˚ ze duvodu pˇridána volba omezuj´ıc´ı maximáln´ı velikost souboru, coˇz muˇ zm´ırnit tento negativn´ı jev. Pˇri následné prezentaci celého rˇ eˇsen´ı prostˇrednictv´ım systému bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=696641) bylo toto rˇ eˇsen´ı pˇrijato s opˇetovnou poznámkou o pamˇet’ové nároˇcnosti a navrhovaná sada zmˇen je naplánována k zahrnut´ı v budouc´ı verzi systému Beaker.

27

Literatura [1] CALLAGHAN, Dan et al. Beaker [poˇc´ıtaˇcovy´ program]. Verze 0.15.1 Red Hat Inc. 22. 10. 2013 [cit. dne 2. 1. 2014]. Dostupné na: http: //beaker-project.org/releases/beaker-0.15.1.tar.gz. [2] HAROLD, Elliotte Rusty a MEANS, W. Scott. XML v kostce: Pohotová referenˇcn´ı pˇr´ıruˇcka. Prvn´ı vydán´ı. Praha: Computer Press, 2002. 439 s. ISBN 80-7226-712-4. [3] W3C [Editoˇri BRAY, Tim et al]. CDATA Sections. In Extensible Markup Language (XML) 1.0 [online]. Fifth Edition. W3C, 26. 11. 2008, aktualiˇ ast 2.7. Dostupné na: http://www. zace 7. 2. 2013 [cit. dne 2. 1. 2014]. C´ w3.org/TR/2008/REC-xml-20081126/#sec-cdata-sect. [4] YERGEAU, F. UTF-8, a transformation format of ISO 10646 [online]. IETF, listopad 2003 [cit. dne 2. 1. 2014]. Dostupné na: http://tools.ietf. org/html/rfc3629. [5] Python [poˇc´ıtaˇcovy´ program]. Verze 2.4.3. Python Software Foundation, 29. 4. 2006 [cit. dne 2. 1. 2014]. Dostupné na: http://python.org/ download/. [6] Python v2.6.9 documentation [online]. Verze 2.6.9. Python Software Foundation, c1990-2013, aktualizace 29. 10. 2013 [cit. dne 2. 1. 2014]. Dostupné na: http://docs.python.org/2.6/. [7] BAYER, Michael. SQLAlchemy [knihovna jazyka Python]. Verze 0.6.8. Kvˇeten 2012 [cit. dne 2. 1. 2014]. Dostupné na: http://www. sqlalchemy.org/download.html. [8] XMLRPC [online]. Scripting News, c2004-2011. [cit. dne 2. 1. 2014]. Dostupné na: http://xmlrpc.scripting.com/default.html. [9] Apache: HTTP Server Project [poˇc´ıtaˇcovy´ program]. Verze 2.2.15. Apache Software Foundation, c2014. [cit. dne 2. 1. 2014]. Dostupné na: http: //httpd.apache.org/. 28

´ PRAVY V B EAKERU 4. U [10] mod wsgi [poˇc´ıtaˇcovy´ program]. Verze 3.2. DUMPLETON, Graham, duben 2010. [cit. dne 2. 1. 2014]. Dostupné na: http: //code.google.com/p/modwsgi/downloads/detail?name= mod_wsgi-3.2.tar.gz&can=1&q=mod_wsgi-3.2. [11] MySQL [poˇc´ıtaˇcovy´ program]. Verze 5.1.71. Oracle Corporation, c19972013. [cit. dne 2. 1. 2014]. Dostupné na: http://dev.mysql.com/ downloads/mysql/5.1.html. [12] RPM [poˇc´ıtaˇcovy´ program]. Verze 4.8.0. Red Hat, Inc., 8. 1. 2010. [cit. dne 2. 1. 2014]. Dostupné na: http://rpm.org/releases/rpm-4.8. x/rpm-4.8.0.tar.bz2. [13] Kickstart [online]. Fedora Project, aktualizace 16. 12. 2013 [cit. dne 2. 1. 2014]. Dostupné na: http://fedoraproject.org/wiki/ Anaconda/Kickstart. [14] CentOS [operaˇcn´ı systém]. Verze 6.5. The CentOS Team. 1. 12. 2013. [cit. dne 2. 1. 2014]. Dostupné na: http://www.centos.org/modules/ tinycontent/index.php?id=30. [15] Pˇrispˇevatelé Wikipedie, Fully qualified domain name [online], In Wikipedia, The Free Encyclopedia, c2013, Datum posledn´ı revize 19. 12. 2013 [cit. dne 2. 1. 2014]. Dostupné na: http://en.wikipedia.org/w/index.php?title=Fully_ qualified_domain_name&oldid=586812854. [16] DROMS, D. Dynamic Host Configuration Protocol [online]. IETF, duben 1997 [cit. dne 2. 1. 2014]. Dostupné na: http://tools.ietf.org/ html/rfc1350. [17] SOLLINS, K. R. THE TFTP PROTOCOL [online]. IETF, cˇ erven 1981 [cit. dne 2. 1. 2014]. Dostipné na: http://tools.ietf.org/html/ rfc783. [18] JOSEFSSON, S. The Base16, Base32, and Base64 Data Encodings [online]. IETF, cˇ ervenec 2003 [cit. dne 2. 1. 2014]. Dostupné na: http://tools. ietf.org/html/rfc3548. [19] FREED, N., KLENSIN, J. a HANSEN, T. Media Type Specifications and Registration Procedures [online]. IETF, leden 2013 [cit. dne 2. 1. 2014]. Dostupné na: http://tools.ietf.org/html/rfc6838. 29

´ PRAVY V B EAKERU 4. U [20] SELinux Project Wiki [online]. MORRIS, James. [cit. dne 2. 1. 2014]. Dostupné na: http://selinuxproject.org/page/Main_Page. [21] MEYERING, Jim et al. chmod [poˇc´ıtaˇcovy´ program]. Verze 8.4. Free Software Foundation, 13. 1. 2010 [cit. dne 2. 1. 2014]. Dokumentace na: http://pubs.opengroup.org/onlinepubs/ 009695399/utilities/chmod.html Dostupné na: http: //ftp.gnu.org/gnu/coreutils/coreutils-8.4.tar.gz. [22] Security Context. In SELinux Project Wiki [online]. MORRIS, James. [cit. dne 2. 1. 2014]. Dostupné na: http://selinuxproject.org/page/ SELinux_contexts. [23] Nástroje acl [poˇc´ıtaˇcovy´ program]. Verze 2.2.49. GRUENBACHER, Andreas, PHILIPS, Brandon, 20. 11. 2009 [cit. dne 2. 1. 2014]. Dostupné na: http://git.savannah.gnu.org/cgit/acl.git/snapshot/ acl-2.2.49.tar.gz. [24] Pˇrispˇevatelé Wikipedie. Document type definition [online], In Wikipedia, The Free Encyclopedia, c2013, Datum posledn´ı revize 26. 12. 2013 [cit. dne 2. 1. 2014]. Dostupné na: http://en.wikipedia.org/w/index. php?title=Document_type_definition&oldid=587707718. [25] CLARK, James a MURATA, Makoto [editoˇri]. RELAX NG Specification: Committee Specification 3 December 2001 [online]. The Organization for the Advancement of Structured Information Standards, c2001, aktualizace 3. 12. 2001 [cit. dne 2. 1. 2014]. Dostupné na: http://relaxng.org/ spec-20011203.html. [26] Unicode Character Sets. In MySQL Documentation: MySQL Reference Manuals [online]. Verze 5.0. Oracle Corporation, revize 37240 [cit. dne 2. 1. 2014]. Dostupné na: http://dev.mysql.com/doc/refman/5. 0/en/charset-unicode-sets.html. [27] Generators. In Python v2.6.9 documentation [online]. Verze 2.6.9. Python Software Foundation, c1990-2013, aktualizace 29. 10. 2013 [cit. dne 2. 1. 2014]. Dostupné na: http://docs.python.org/2/tutorial/ classes.html#generators. [28] xmltramp [knihovna jazyka Python]. Verze 2.17. SWARTZ, Aaron. 20. 4. 2006 [cit. dne 2. 1. 2014]. Dostupné na: http://www.aaronsw.com/ 2002/xmltramp/. 30

´ PRAVY V B EAKERU 4. U [29] CALLAGHAN, Dan et al. beah [poˇc´ıtaˇcovy´ program]. Verze 0.6.48 Red Hat Inc. 1. 12. 2013 [cit. dne 2. 1. 2014]. Dostupné na: http://git.beaker-project.org/cgit/beah/snapshot/ beah-0.6.48-1.tar.gz. [30] APPARAO, Vidur et al. Document Object Model (DOM) Level 1 Specification. Verze 1.0. W3C, 1. 10. 1998 [cit. dne 2. 1. 2014]. Dostupné na: http://www.w3.org/TR/REC-DOM-Level-1/. [31] Twisted [knihovna jazyka Python]. Verze 8.2.0. LEFKOWITZ, Glyph. 16. 12. 2008 [cit. dne 2. 1. 2014]. Dostupné na: http: //twistedmatrix.com/Releases/Twisted/8.2/Twisted-8. 2.0.tar.bz2. [32] GAILLY, Jean-loup a ADLER, Mark. gzip [poˇc´ıtaˇcovy´ program]. Verze 1.3.12. Free Software Foundation, 13. 4. 2007 [cit. dne 2. 1. 2013]. Dostupné na: http://www.gzip.org/.

31

Pˇr´ılohy •

´ beaker.tar.gz – Archiv se zdrojovymy kody systému Beaker s jiˇz zahr´ nutymi zmˇenami, které jsou pˇredmˇetem této práce. ´

•

´ beah.tar.gz – Archiv se zdrojovymi kody testovac´ıho prostˇred´ı Beah ´ s jiˇz zahrnutymi zmˇenami, které jsou pˇredmˇetem této práce. ´

•

´ beaker.patch – Sada zmˇen ve zdrojovych systému Beaker. ´ kodech

•

´ beah.patch – Sada zmˇen ve zdrojovych testovac´ıho prostˇred´ı ´ kodech Beah.

•

job.xml – Pˇredpis testu obsahuj´ıc´ı ukázky vloˇzenych ´ souboru˚ jako parametru˚ testu.

32

012345

Recommend Documents