}w!"#$%&'()+,-./012345<ya

}w!"#$%&'()+,-./012345<ya MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Vkládání obecných souborů do XML předpisu automatizovaných testů BAKALÁŘSKÁ PRÁCE Pavel Holica Brno, podzim 2013

Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: Mgr. Marek Grác, Ph.D. ii

Poděkování Rád bych poděkoval vedoucímu práce Mgr. Marku Grácovi, Ph.D. za pevné nervy při vedení této práce a za vstřícnost. Dále také děkuji Bc. Mariánu Ganišinovi za konzultace v technických oblastech. Také bych rád poděkoval Bc. Michalu Kovaříkovi a Mgr. Ĺuboši Kardošovi za různé tipy v systému Beaker. Nakonec pak také všem, kteří trpělivě provedli korekturu, především pak Janě a Pavle Kratochvílovým. iii

Klíčová slova test, automatizované testování, soubor, XML, dokument, Python, databáze, kódování, data, metadata, parametr iv

Shrnutí Práce je organizována v pořadí od analýzy problému k jeho postupnému řešení. V prvních dvou kapitolách je popsán formát XML a systém na spouštění automatizovaných testů Beaker [1]. V předposlední kapitole je hlubší analýza problému vkládání souborů do předpisu testu a návrh jak soubory do předpisu umístit. V poslední kapitole je pak popsaná samotná implementace v systému Beaker. v

Obsah 1 XML................................... 4 1.1 Elementy.............................. 4 1.2 Atributy.............................. 5 1.3 Soubor v XML........................... 5 1.4 Binární data v XML........................ 5 2 Beaker.................................. 6 2.1 Architektura............................ 6 2.1.1 Server........................... 6 2.1.2 Labcontroller....................... 7 2.1.3 Testovací prostředí.................... 7 2.2 Instalace a konfigurace...................... 8 2.2.1 Instalace.......................... 8 2.2.2 Konfigurace služeb.................... 8 2.2.3 Server........................... 9 2.2.4 Labcontroller....................... 9 2.2.5 Testovací systémy..................... 10 2.3 Scénář testu............................ 10 2.3.1 Task............................ 11 2.3.2 Recipe........................... 11 2.3.3 Recipeset.......................... 12 2.3.4 Job............................. 12 3 Soubory v předpisu testu....................... 13 3.1 Data................................. 13 3.1.1 Kódování......................... 13 3.1.2 Typ souboru........................ 14 3.2 Umístění souboru......................... 15 3.2.1 Relativní cesta....................... 15 3.2.2 Absolutní cesta...................... 15 3.2.3 Aktualizace........................ 15 3.3 Metadata.............................. 16 3.3.1 Atributy souboru..................... 16 3.3.2 Pokročilá oprávnění................... 17 1

3.4 XML Element file......................... 17 4 Úpravy v Beakeru............................ 19 4.1 XML schéma............................ 19 4.2 Server................................ 20 4.2.1 Databáze.......................... 20 4.2.2 Zpracování XML předpisu............... 21 4.2.3 Generování XML předpisu............... 22 4.3 Testovací prostředí........................ 23 4.3.1 Zpracování XML předpisu............... 23 4.3.2 Umístění souboru na testovací systém......... 24 4.3.3 Vytvoření souboru s metadaty............. 24 4.3.4 Aktualizace testu..................... 25 2

Úvod Během intenzivního používání a vytváření testů v systému Beaker jsem společně s kolegy mnohokrát narazil na omezení tohoto systému v nemožnosti předávat testům jako parametr celé soubory. Typicky se jednalo o testy, jejichž podstatou bylo přeinstalovat operační systém na testovacím systému a pro tuto instalaci bylo potřeba dodat konfigurační soubor popisující, jakým způsobem má být nový systém nainstalován a konfigurován. V jiných případech se jednalo o konfigurační soubory služeb a nástrojů. Tyto situace jsme museli řešit uvnitř testu, kde takové soubory byly bud součástí samotného testu, nebo je bylo nutné generovat (případně upravovat již existující konfigurační soubory). Možnost předat soubor jako parametr testu vybízí k použití tohoto mechanismu k přímému nahrazení souboru na testovacím systému souborem předaným, aniž by byla od testu k tomuto účelu požadovaná jakákoliv činnost. Častokrát jsme se setkali i s případem, kdy bylo nutné provést jednorázovou aktualizaci testu, která nebyla v souladu s běžným testováním. I zde by bylo moˇzné vyuˇzít tuto novou vlastnost a přímo tak nahradit soubor v testu souborem předaným. Všechny zmíněné případy lze (a často to tak i bylo) řešit předáním textového parametru obsahujícího URL, na kterém se nacházel daný soubor. Takové řešení však vyžaduje úpravu testu, není vždy možné a navíc při opětovném spuštění testu s takovým parametrem již nemusí být tento soubor na daném URL dostupný. Také by bylo možné předávat jako parametr testu soubor, nad kterým je přímo prováděn test. Proto je vhodné umožnit pro takový soubor například nastavení přístupových práv pro testy ověřující, zda lze daný soubor přečíst nebo spustit. 3

Kapitola 1 XML XML [2] (extensible markup language) je značkovací jazyk sloužící k reprezentaci neprázdné n-ární stromové struktury ve formě čitelné člověku. V tomto jazyce se používají alfanumerické znaky a několik znaků speciálních (které jsou ovšem také součástí základní znakové sady ASCII). Názvy v XML jsou složeny z alfanumerických znaků, podtržítka, pomlčky a tečky; nesmí začínat číslem, pomlčkou, ani tečkou. Vrcholy jsou v XML označovány jako elementy a ohodnocení vrcholů lze provést pomocí parametrů přiřazených elementu. XML neumožňuje ohodnocovat hrany, což ovšem není u stromové struktury problém, jelikož ohodnocení hrany lze ekvivalentně řešit ohodnocením vrcholu. XML poskytuje více možností, než je popsáno v této kapitole (např. jmenné prostory), ale ty nejsou pro tuto práci potřebné a ani použitelné. 1.1 Elementy Element, jakožto vrchol, má svého rodiče (s výjimkou kořenového elementu) a potomky. Rodičem je vždy element a potomky mohou být elementy, text, nebo text kombinovaný s elementy. Poslední zmiňovaný případ (kombinovaný obsah) je vhodný pro dokumenty obsahující strukturovaný text. V textu se mohou vyskytovat libovolné znaky ze znakové sady dokumentu, kromě znaků používaných XML (jde o &, > a <). Tyto znaky musí být vloženy jako XML entity, které jsou reprezentovány sekvencí &název;, kde název je pojmenování entity. Entitami lze vyjádřit libovolný znak, a to bud názvem, nebo číslem znaku v použité znakové sadě. Pokud se v textu vyskytuje více takových znaků, je vhodnější text umístit do CDATA [3] sekce, která je uvozena sekvencí <![CDATA[ a ukončena sekvencí ]]>. V této sekci se může vyskytovat libovolný text, který neobsahuje sekvenci znaků použitou pro ukončení CDATA sekce. 4

1. XML 1.2 Atributy Element může mít libovolné množství atributů, přičemž atribut se skládá z názvu a hodnoty. Hodnotou atributu pak může být téměř libovolný jednořádkový řetězec znaků ze znakové sady dokumentu (typicky UTF-8 [4]), kde je hodnota ohraničena apostrofy, nebo uvozovkami. V hodnotě se nesmí vyskytovat tytéž znaky, které nejsou povoleny v textu elementu, a také se zde nesmí vyskytovat znak použitý k ohraničení. Ten lze však umístit pomocí XML entity. Z těchto důvodů jsou atributy vhodné pro popis obsahu elementu nebo pro jednodušší údaje. 1.3 Soubor v XML Vzhledem k popsaným vlastnostem XML dokumentu je vhodné soubor umístit do samostatného elementu, kde metadata (název, přístupová práva a jiné atributy) jsou umístěna v atributu a data souboru v jeho textu. V případě potřeby umístění komplikovanějších metadat souboru lze uvažovat i o řešení, kdy pro každá taková metadata je vytvořen nový 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čkoliv existuje zápis XML dokumentu v binárním formátu, není tento zápis obvyklý a běžně používaný. Binární data nelze přímo umístit do XML dokumentu (jedná se totiˇz o textový dokument), lze ovšem převést data souboru na textová data pomocí vhodného kódování a následně tato zakódovaná data vložit do textu elementu. 5

Kapitola 2 Beaker Beaker je systém pro spouštění automatických softwarových testů, uložení jejich výsledků a následnou prezentaci. Tento systém je dostupný pod licencí GNU GPL 2 a novější a je aktivně vyvíjen a používán společností Red Hat a jejími partnery. V současné době uvažuje o použití tohoto systému i komunita organizovaná kolem projektu Fedora, který je sponzorován společností Red Hat. Tento systém je napsán v programovacím jazyce Python [5] s využitím mnoha rozšiřujících knihoven, mezi jinými také SQLAlchemy [7] a je určen pro běh v prostředí operačního systému (dále OS) Red Hat Enterprise Linux 6 (dále RHEL), nebo v jiném kompatibilním OS. Beaker je vytvořen jako webová aplikace s XMLRPC [8] rozhraním, což poskytuje uživateli možnost systém flexibilně používat, nezávisle na jím preferovaném OS. Pro webové rozhraní je použit Apache web server [9], ve kterém je Beaker spuštěn jako WSGI aplikace [10]. Beaker používá pro organizaci dat o testovacích systémech, uživatelích apod. databázový systém MySQL [11]. 2.1 Architektura Systém Beaker je složen z následujících částí: server (dále Server), labcontrollery a testovací prostředí. Server a labcontroller mohou být instalovány na jednom systému, v praxi ovšem bývá labcotrollerů více a jsou umístěny na geograficky rozdílných místech. 2.1.1 Server Server je středovým bodem celého Beakeru. Stará se o databázi testů, databázi labcontrollerů, databázi testovacích systémů, autentizaci a autorizaci uživatelů, příjem požadavků na spuštění testů, plánování spuštění testů, ukládání výsledků testů a presentaci výsledků testů. Testy jsou v současné 6

2. BEAKER době uloženy v RPM [12] balíčcích, které umožňují definovat požadavky testů na software i hardware. 2.1.2 Labcontroller Labcontroller má na starosti zdroje softwaru pro instalace, ovládání testovacích strojů a spouštění testů na testovacích systémech. V aktualní verzi Beakeru to znamená automatizovanou instalaci OS (za použití kickstart [13] souboru) ze sítě, přičemž labcontroller nastaví prostředí pro sít ový boot testovaného systému a následně provede potřebnou akci pro spuštění testovaného stroje (typicky pomocí protokolu pro vzdálenou správu). Pro instalaci OS je použit sít ový zdroj softwaru definovaný labcontrollerem (typicky místní zdroj pro testovací systém). Po instalaci je OS nakonfigurován tak, že spustí testovací prostředí. Od počátku instalace běží tzv. watchdog, který kontroluje, zda některá z akcí netrvá příliš dlouho. Pokud ano, test nebo instalace je ukončena bez moˇznosti pokračovaní dalším testem. V budoucnu je v plánu namísto náročné instalace použít takzvané cloudové řešení, kde se rovnou spustí virtuální stroj s již nainstalovaným OS a provedou se pouze drobné změny nutné pro spuštění testovacího prostředí pro naplánovaný test. 2.1.3 Testovací prostředí Testovací prostředí (nebo také harness) je software běžící na připraveném testovacím systému. Jeho úkolem je zprostředkovávat komunikace mezi testem a labcontrollerem. Testovací prostředí nejdříve zjistí, který test má být spuštěn a s jakými parametry, poté test nainstaluje, nastaví proměnné prostředí a test spustí. Následně mu test sděluje výsledky a prostředí je předává labcontrolleru. Testovací prostředí také poskytuje prostředky pro synchronizaci testů, která je potřebná pro takzvané multihost testy, tj. testy, které běží na více systémech současně a kde se testuje interakce systémů. Poslední funkce, kterou testovací prostředí poskytuje, je tzv. local watchdog, který kontroluje, zda test netrvá delší dobu, než o sobě deklaruje. Pokud ano, tak test ukončí a pokračuje spuštěním dalšího testu. Local watchdog se liší od watchdogu na labcontrolleru tím, že již má možnost plně ovládat testovací systém, a tak při selhání jednoho testu může tento test násilně ukončit a pokračovat testem dalším. Pokud ovšem z jakéhokoliv důvodu selže testovací prostředí (at už kvůli nefunkčnímu local watchdog nebo např. problému s předáváním výsledků labcontrolleru) může 7

2. BEAKER watchdog na labcontrolleru ukončit celý test. 2.2 Instalace a konfigurace Projekt Beaker na svých webových stránkách poskytuje kickstart soubor pro instalaci operačního systému CentOS [14] 6 spolu s Beakerem a dalším požadovaným softwarem. Dále pak poskytuje skripty pro základní konfiguraci Beakeru. Beaker a labcontroller jsou obvykle instalovány jako samostatné systémy vzájemně komunikující po síti, lze je však provozovat na jednom systému současně a pro vývoj vlastností na architektuře nezávislých je to naprosto dostačující. Toto řešení je popsáno na webu projektu Beaker i s potřebnou konfigurací. Bohužel je i při tomto řešení požadováno, aby byl systém umístěn v síti, nad kterou má uživatel plnou kontrolu, lze však zvolit i méně náročné řešení, a to za pomoci hardwarové virtualizace, která je dnes již běžně dostupná. Virtualizace (spolu s vlastnostmi linuxového jádra) poskytuje možnost vytváření virtuálních sítí a virtuálních strojů, které mohou tyto sítě plně spravovat. Lze tak vytvořit virtuální prostředí, blížící se běžnému použití systému Beaker. Tato volba ovšem není na webu projektu Beaker zmíněna a nepočítá se s ní. 2.2.1 Instalace Systém Beaker je možné nainstalovat na RHEL 6 nebo CentOS 6 např. za pomoci kickstart souboru dostupného na webu projektu Beaker. Také lze OS nainstalovat manuálně a potřebný software včetně Beakeru následně doinstalovat. Na systému, kde je Server, je instalován balíč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řeba, aby byla správně nakonfigurována sít, sít ové instalační zdroje, labcontrollery a testovací systémy. Z pohledu sítě je předevsím nutné, aby měl Server, labcontrollery a testovací systémy nastaveny FQDN [15] včetně reverzních záznamů. S tímto souvisí i přidělování IP adres pomocí protokolu DHCP [16] a bootování ze sítě za pomoci tohoto protokolu a protokolu TFTP [17]. 8

2. BEAKER 2.2.3 Server Pro Server je především potřeba vytvořit MySQL databázi a jejího uživatele, které bude Beaker používat. Jakmile je databáze připravena, vytvoří příkaz beaker-init -u admin -p heslo -e admin@example.com tabulky nutné pro provoz a záznam o administrátorském účtu s daným heslem a e-mailovou adresou. Následně je možné se přihlásit ve webovém rozhraní na adrese http://example.com/bkr/login s nově vytvořeným administrátorským účtem. Po přihlášení už zbývá jen nahrání testů do databáze testů. Na webu projektu Beakeru jsou k dispozici úlohy (ve formě testů), které jsou určeny k základním operacím s testovacími systémy. Tyto úlohy jsou: /distribution/install, /distribution/reservesys a /distribution/inventory. Úloha install je puštěna jako první po instalaci OS, a provede základní kontrolu, zda instalace proběhla v pořádku. Pro zapůjčení systému uživateli nebo pro manuální kontrolu a diagnostiku proběhlých testů slouží úloha reservesys. Poslední základní úlohou je inventory, jejímž účelem je získání informací o testovacím systému, na kterém je tato úloha spuštěna, a následně odeslání těchto údajů zpět do Beakeru pro účely vytvoření databáze hardwaru testovacích systémů. Posledním krokem je povolení a spuštění služby beakerd. 2.2.4 Labcontroller V případě labcontrolleru je konfigurace jednodušší, je potřeba jej pouze registrovat na Serveru a upravit konfigurační soubor. Na adrese http://example.com/bkr/labcontrollers/new se pro registraci uvede FQDN, uživatelské jméno, které bude přiřazeno labcontrolleru, k němu odpovídající heslo a email pro labcontroller. V souboru /etc/beaker/labcontroller.conf se nastaví URL Serveru (HUB URL), uživatelské jméno a heslo, které bude labcontroller používat. Jak bylo výše zmíněno, labcontroller má na starosti spouštění instalace na testovacích systémech, a proto může být zapotřebí nastavit adresář, který používá TFTP server (volba TFTP ROOT v konfiguračním souboru). Posledním krokem je povolení spuštění služeb beaker-proxy, beaker-watchdog a beaker-provision. Pokud je žádoucí ukládat záznamy o výsledcích testů jinde než na labcontrolleru, je potřeba upravit příslušné volby v konfiguračním souboru labcontrolleru a povolit a spustit službu beaker-transfer. Jakmile jsou služby labcontrolleru spuštěny, je potřeba přidat do labcontrolleru zdroj pro instalaci softwaru a OS, což lze 9

2. BEAKER provést pomocí příkazu beaker-import s argumentem URL, ukazujícím na instalační zdroj RHEL, nebo systému používající stejný způsob instalace, jako je CentOS nebo Fedora. 2.2.5 Testovací systémy Na testovacích systémech samotných je potřeba nastavit pouze bootorder tak, že první položkou bude boot ze sít ové karty a následně z datového úložiště (typicky z pevného disku). Dále je nutno každý nový testovací systém zaregistrovat na Serveru. Registrace probíhá na adrese http://example.com/bkr/new, kde je potřeba nastavit název systému, přičemž názvem je FQDN systému a používá se pro překlad na IP adresu pro nastavení sít ové instalace. Další důležitou volbou je Lab controller, kde se vybere ten labcontroller, který spravuje sít ovou instalaci přidávaného systému. Poslední volbou týkající se nastavení sítě je MAC adresa, která je důležitá pro výběr primární sít ové karty, kterou má testovací systém používat pro instalaci. Po registraci systému je ještě zapotřebí nastavit způsob spouštění testovacího systému. Pro spuštění podporuje Beaker nejenom běžné protokoly pro vzdálenou správu serverů, ale také wake on lan pomocí takzvaného magic packetu a protokol pro správu virtuálních systémů spravovaných službou libvirt. Pro virtuální systémy jde o položku virsh, kde se u parametru Power Address nastaví qemu+ssh:ip_adresa, kde IP ADRESA patří systému se službou libvirt. Pro Power Login se nastaví přihlašovací jméno (vzdáleného) uživatele, který má oprávnění ovládat službu libvirt. Posledním krokem je vygenerování SSH klíče pro správu (pokud již neexistuje) a přidání veřejného klíče do seznamu důvěryhodných pro uživatele na serveru s libvirt službou. Operace s SSH klíči je potřeba provést pouze jednou pro každý server provozující libvirt službu. Pro otestování konfigurace a nahrání dodatečných údajů o hardwaru je vhodné naplánovat úlohu /distribution/inventory. 2.3 Scénář testu Scénáře testu jsou v systému Beaker definovány pomocí XML stromové struktury, která odpovídá RelaxNG schématu. 10

2. BEAKER 2.3.1 Task Základní jednotkou předpisu testu je test a jeho parametry. Test je specifikován elementem task s XML parametry name a role, kde name je název testu/úlohy a role specifikuje roli úlohy zda jde o samostatně běžící test, nebo zda jde o server, client, peer nebo jinou roli. Nastavení role je důležité u multihost testů. Parametry testu se nacházejí v elementu params, kde je pro každý parametr přítomen element param s XML atributy name a value. Všechny parametry jsou před spuštěním testu zpracovány, a podle nich jsou nastaveny proměnné prostředí. Protože jsou hodnoty těchto proměnných prostředí určeny pomocí XML atributu, není možné použít např. víceřá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, že jsou jednotlivé úlohy spouštěny v pořadí, v jakém jsou přítomny v elementu recipe. Recipe již specifikuje celou sekvenci činností, včetně instalace, která je na testovacím systému provedena. Pomocí elementu hostrequires lze pomocí sady pravidel specifikovat, jakým požadavkům má systém vyhovovat (např. se má jednat o systém se čtyřmi a více gigabyty paměti, dvěma sít ovými kartami a dvěma procesory). V rámci recipe je nutné specifikovat i požadavky na operační systém v elementu distrorequires (např. že má test proběhnout na OS CentOS 5.9 architektury x86 64). Dále lze specifikovat dodatečné repozitáře softwaru, které se použijí při instalaci, a seznam balíčků softwaru, které mají být nainstalovány. Pro instalaci lze nastavit celý předpis automatické instalace ve formátu kickstart souboru, a to v textu elementu kickstart, což je používáno pro instalační testy, nebo pro testy vyžadující specifické nastavení hardwaru. Pokud není potřeba specifikovat celý předpis, ale pouze jeho část, lze použít element ks appends a jeho podelementy ks append, jejichž text bude připojen na konec vygenerovaného předpisu pro automatickou instalaci. Pro instalaci ještě lze nastavit parametry jádra před instalací pomocí XML atributu kernel options a po instalaci pomocí atributu kernel options post. Pro recipe je také vhodné nastavit XML atribut whiteboard, jehož účelem je popisovat úlohu testů a testovacího systému v rámci předpisu testu. 11

2. BEAKER 2.3.3 Recipeset Aby bylo moˇzné provádět takzvané multihost testy, je třeba tyto testy svázat do skupiny, která je synchronizována a je u ní zajištěno, že budou spuštěny na testovacích systémech v rámci jedné lokality, tj. obsluhované jedním labcontrollerem. K těmto účelům jsou elementy recipe umístěny v Recipeset, který zajištuje splnění zmíněných potřeb. Pro recipeset lze i definovat prioritu, která je vzata v potaz při plánování spouštění testů. 2.3.4 Job Job je kořenovým elementem celého předpisu testu a obsahuje jeden nebo více recipeset. Používá se ke sdružení testů do sady, která může a nemusí obsahovat synchronizované testy. Testy v elementech recipe, které nevyˇzadují synchronizaci, je vhodné umístit do samostatných elementů recipeset, jinak by instalace testovacích systémů a samotné testy byly zbytečně zpožděny čekáním na přidělení testovacích systému pro všechny recipe, na dokončení časově náročných instalací na pomalejších systémech a na skončení testů, které spolu nesouvisí. Pro job lze specifikovat pomocí XML elementu retention tag, jak dlouho mají být výsledky testu zaznamenány. Dále lze nastavit i skupinu uživatelů Beakeru, které takový job náleží a jejíž členové mají právo job rušit. Velice vhodné je i nastavit popis jobu v textu elementu whiteboard. 12

Kapitola 3 Soubory v předpisu testu Soubory, jakožto parametry testu, se v Beakeru vážou na element task v předpisu testu, a proto je vhodné umístit soubor do tohoto elementu, podobně jako jsou zde umístěny textové parametry. Bylo by sice možné umístit celý soubor včetně metadat do textové infomace, a tedy i do již přítomného parametru testu, avšak takto řešený soubor by byl pro uživatele obtížně čitelný, souborová data by nebyla logicky jednoznačně oddělena od textových dat a nebyl by plně využit potenciál formátu XML. 3.1 Data Jak již bylo zmíněno dříve, souborová data nemohou být obecně přímo umístěna v XML, a proto je potřeba data zakódovat tak, aby se jednalo o textová data. Pokud uvaˇzujeme o adresáři jako o souboru a o jeho podadresářích jako jeho obsahu, je nutné tato data nějakým způsobem složit do takzvaného archivu, indikovat, že jde o archiv, a při umístění na testovací systém k těmto datům náležitě přistoupit. 3.1.1 Kódování Data, která nelze přímo vložit do XML, je nutné převést do jiného formátu. Preferovaný způsob v prostředí internetu je Base64 [18] kódování. Toto kódování je využíváno pro přenos libovolných dat pomocí běžných znaků, a tím také zajišt uje bezproblémový přenos dat na systémech, které by potenciálně mohly mít problém při zpracování určitých znaků. Tento formát je navíc i díky své známosti a specifickému vzhledu na první pohled rozpoznatelný a pro uživatele jednoduše dekódovatelný (např. pomocí nástroje Base64 přítomného v každé současné Linuxové distribuci). Protože se v případě Base64 jedná o bezztrátové kódování (data jsou po dekódování totožná s daty před zakódováním) a je značně omezena abeceda (znaky přípustné pro kódování), musí nutně vznikat i režie, a ta tvoří jednu třetinu velikosti původních dat. 13

3. SOUBORY V PŘEDPISU TESTU Pro textová data je použito kódování UTF-8, které je přirozené pro XML. Některé soubory mohou také obsahovat data, která se opakují, a je tak možné na takové soubory aplikovat kompresní algoritmus a data prostorově optimalizovat, což vede k ušetření místa při ukládání souborových dat v systému Beaker, k menším pamět ovým nárokům při zpracování předpisu scénáře testu a také k menšímu množství přenesených dat po síti při předávání scénáře testovacímu prostředí. Bohužel kompresní algoritmy typicky produkují binární data, která je poté nutné převést do dat textových. Jsou ovšem případy, kde je tento postup přesto vhodný, a to například při vkládání archivu souborů, který zarovnává velikost výsledného souboru na násobek určité jednotky, a může tak data o velikosti bytů archivovat do souboru velikosti kilobytů. Následná aplikace komprimačního algoritmu může velikost dat vrátit na jednotku bytů. V takovém případě je úspora větší než prostorová režie Base64 kódování. Protože lze kódování řetězit (např. dříve zmínený archiv je zkomprimován a následně zakódován pomocí Base64), je nutné indikovat i celou posloupnost. Pro tento účel může být použit zápis posloupnosti, kde prvky jsou odděleny znakem, který se nesmí nacházet v názvu kódování, např. běžně používanou čárkou, nebo jiným oddělovačem. Jako vhodný oddělovač se jeví lomítko, které vizuálně znázorňuje vrstvení. 3.1.2 Typ souboru Jak jiˇz bylo zmíněno, v určitých případech je nutno k datům souboru přistupovat rozdílným způsobem a tento případ je nutno indikovat. Jedna možnost, jakou lze tuto informaci podat, je využití formátu MIME [19], který je k tomu přímo určený a je také běžně v internetových technologiích používaný. Pro data, která nepotřebují další zpracování, jsou použity typy text/plain pro textová data a application/octet-stream pro data binární. Pro adresář se používá vlastní typ apllication/x-tar, který indikuje, že jde o archiv souborů vytvořený pomocí nástroje tar. Tento typ není součástí standardní sady MIME typů, proto je nutno použít typ vlastní. Vlastní typy jsou v MIME definovány tak, že začínají na x-. Tento zvolený MIME typ pro archiv je běžně používán v Unixových prostředích a stal se de facto standardním. Dalšími typy souboru by mohly být například i symbolické odkazy, kde data jsou cesta na odkazovaný soubor, nebo URL, kde data mohou být URL souboru, jehož obsah má být přítomen ve výsledném souboru. 14

3. SOUBORY V PŘEDPISU TESTU 3.2 Umístění souboru Cesta souboru definuje, v jakém adresáři má být soubor umístěn a jak se má soubor jmenovat. Soubor může sloužit nejen jako parametr testu, ale také k náhradě souboru přítomného na testovacím systému, k náhradě souboru v testu, pro účely testování nové verze testu, nebo pro rychlou aktualizaci bez nutnosti trvalé úpravy testu. Možnost nahradit soubor v testovacím systému umožňuje předávat konfigurační soubory pro software, který má být testován, a není tak nutné předávat všechny podstatné volby v tomto souboru obsaˇzené jako jednotlivé textové parametry testu. Další výhodou je, že o takto předaném souboru nemusí test vůbec vědět, a díky tomu může být i kód testu kratší. 3.2.1 Relativní cesta Soubor lze předat s relativní cestou, tj. cestou, která je vztažena k pracovnímu adresáři. Tento adresář je vytvořen testovacím prostředím při přípravě spuštění testu a jsou do něj vloženy všechny soubory, které mají cestu relativní (vyjma souborů označených jako aktualizační). V unixových systémech je taková cesta určena tak, že začíná libovolným znakem jiným neˇz lomítko a stejný způsob je použit i v tomto řešení. 3.2.2 Absolutní cesta Soubory začínající znakem lomítko, tj. soubory s absolutní cestou, jsou umístěny do kořenového adresáře pod danou cestou. Kořenovým adresářem je adresář vytvořený testovacím prostředím, takže pokud není soubor označen jako aktualizační, chová se absolutní cesta stejně jako relativní. 3.2.3 Aktualizace Soubor může být XML atributem update označen jako aktualizační, a v tomto případě se stává pracovním adresářem adresář, ve kterém je umístěn test, a kořenovým adresářem je kořenový adresář testovacího systému. To znamená, že aktualizační soubor s relativní cestou je umístěn do adresáře testu, a může tak nahradit soubor testu. Při absolutní cestě pak může zase soubor aktualizovat systémové soubory, např. konfigurační soubory služeb. 15

3. SOUBORY V PŘEDPISU TESTU 3.3 Metadata K souboru jsou mimo jeho názvu přiřazena i další metadata, jako jsou například vlastník souboru a přístupová práva. Dále lze také nastavit pokročilá oprávnění, pomocí takzvaného Access Control List (ACL). 3.3.1 Atributy souboru Atributy souboru lze nastavit XML atributem attrs. Atributy souboru mohou být využity pro testování nástrojů ověřuje se u nich, zda přistupují k souborům korektním způsobem vzhledem k jejich atributům. Atributy může být nutné specifikovat i pro určité konfigurační soubory, u kterých je vyžadováno, aby měly např. specifická přístupová práva nebo vlastníka. Způsob nastavení atributů pomocí jednoho XML atributu byl zvolen z důvodu rozšiřitelnosti. Kdyby byl pro každý atribut samostatný XML atribut, bylo by nutné pro nově přidaný atribut aktualizovat schéma databáze a zpracování předpisu testu na straně serveru. V případě jednoho XML atributu obsahujícího všechny atributy souboru je pouze nutné aktualizovat testovací prostředí, aby aplikovalo tyto atributy na soubor. Navíc se atributy souboru liší v závislosti na operačním systému, a tak při přidání podpory pro nový operační systém není nutna žádná úprava. Tento XML atribut může obsahovat více různých atributů, a tak je potřeba definovat oddělovač, pomocí kterého lze jednoznačně tyto atributy rozdělit. Jelikož jde v podstatě o seznam, nabízí se možnost z několika z obvyklých oddělovačů, a to čárka, dvojtečka a středník. Dvojtečka (u SELinux [20] atributu) i čárka (u přístupových práv) se mohou vyskytnout v atributu souboru, a proto je nejvhodnější volbou středník. Jakmile je seznam rozdělen na jednotlivé atributy, mohou být tyto atributy ve formátu atribut=hodnota (např. owner=root pro nastavení vlastníka souboru), nebo přímo název atributu (např. readonly pro soubor označený pouze pro čtení). Díky této vlastnosti lze předávat jak atributy s hodnotou, tak atributy pravdivostní (atribut je aplikován, nebo případně odebrán). Atributy, které lze nastavit souboru jsou: owner, group, mode a selinux. Všechny tyto atributy jsou s hodnotou. Atributy owner a group určují vlastníka a skupinu souboru, kde hodnotou je název uživatele resp. skupiny nebo číslo uživatele resp. skupiny. Atributem mode lze určit přístupová práva souboru. Hodnotou pro tento atribut je číslo zadané v osmičkové soustavě akceptované unixovým nástrojem chmod [21] a je i stejným zůsobem interpretováno. Posledním atributem je selinux, který určuje 16

3. SOUBORY V PŘEDPISU TESTU selinux kontext [22] přiřazený souboru. Kontext je dvojtečkou oddělená čtveřice, určující uživatele, roli, typ a úroveň. Popis technologie SELinux je nad rámec této práce a více informací je dostupných na webu http://www.selinuxproject.org/. 3.3.2 Pokročilá oprávnění Souborům lze nastavit (pokud to umožňuje systém souborů použitý na testovacím systému) i pokročilá oprávnění ve formě ACL. Tato technika umoˇzňuje definovat uprávnění i jiným uživatelům a skupinám, než jsou vlastník a skupina souboru. Jde-li o adresář, umožňují nastavit i výchozí oprávnění, se kterými bude vytvořen každý nový soubor v takovém adresáři. Pokročilá oprávnění ve formě ACL umožňují nastavit i základní přístupová práva souboru. Jako formát pro pokročilá oprávnění je použit formát používán nástroji getfacl a setfacl [23]. V tomto formátu je každý záznam na samostatném řádku jako dvojtečkou oddělená trojice nebo čtveřice. Prvním (volitelným) prvkem je indikátor, zda jde o výchozí nastavení, pro soubory vytvořené v tomto adresáři. Druhým prvkem je určení, zda jde o uživatele, skupinu, či masku. Třetí (volitelný) prvek určuje, o jakou skupinu, nebo o jakého uživatele se jedná. V případě masky je tento prvek prázdný, pro uživatele jde při prázdné hodnotě o vlastníka souboru, pro skupinu jde o skupinu souboru. Posledním (čtvrtým) prvkem jsou přístupová práva, určující právo ke čtení (r), zápisu (w) a spuštění (x) u souboru, nebo v případě adresáře právo ke vstupu do adresáře. Vyhodnocení těchto oprávnění není jednoduché, pro zjednodušení se ovšem dá říci, že oprávnění se vyhodnocuje od obecnějších (práva skupiny souboru) po konkrétní (práva testovaného uživatele v ACL), kde konkrétnější oprávnění má větší váhu. Protože je zápis pokročilých oprávnění na více řádků, je vhodnější tyto údaje umístit do textu samostatného elementu. 3.4 XML Element file Textové parametry testu jsou reprezentovány elementy param, které jsou umístěny v elementu params uvnitř elementu task. Navrhované řešení se řídí podobnou hierarchií, a to elementy file umístěny v elementu files uvnitř elementu task. Element file má dále atributy: name, update, type, encoding, attrs. Všechny atributy kromě name jsou nepovinné. Atribut name slouží k určení názvu a umístění souboru. Atribut update slouží k indikaci, zda je soubor určen k aktualizaci a má být umístěn v ad- 17

3. SOUBORY V PŘEDPISU TESTU resáři testu, resp. k umístění souboru v rámci celé adresářové struktury testovacího systému. Atribut type určuje, zda mají být data souboru zpracována jiným způsobem než přímým umístěním souboru. Encoding určuje, jakým způsobem jsou data zakódována a jakou posloupností mají být dekódována. Attrs obsahuje jednotlivé atributy souboru, předně vlastnictví a přístupová práva. Mimo atributy obsahuje element file i elementy data a acl. V elementu data jsou v textu (případně uvnitř cdata sekce) umístěna data souboru. Stejným způsobem jako data (kromě kódování) jsou pak uložena pokročilá oprávnění v elementu acl. 18

Kapitola 4 Úpravy v Beakeru Aby bylo možné předat soubory testům v systému Beaker, bylo nutné upravit Server, testovací prostředí a schéma, které kontroluje, zda je XML s předpisem testu ve správném formátu. 4.1 XML schéma Pro ověření správnosti struktury dokumentu ve formátu XML (tedy i předpisu testu v systému Beaker) slouží validační schéma. Pro validaci XML dokumentů existuje několik typů schémat. Nejzákladnějším a nejčastěji podporovaným je DTD (Document Type Definition) [24], které slouží k ověření správnosti struktury SGML dokumentů, přičemž XML jazyk tvoří podmnožinu SGML, takže lze použít DTD i pro validaci XML. Ačkoliv je DTD široce podporované, bylo již překonáno, a to například schématem RelaxNG [25], které je standardizováno mezinárodně uznávanými organizacemi ISO i IEC. Systém Beaker používá pro ověření správnosti struktury předpisu testu v dokumentu XML právě RelaxNG. Výhodou tohoto formátu schématu je, že je samo dokumentem XML a je také jednoduše srozumitelné. RelaxNG je používáno jak Serverem, tak i nástroji komunikujícími se Serverem. Schéma pro validaci předpisu testu bylo nutné upravit tak, aby mohli Server a nástroje akceptovat předpisy testu obsahující soubory. Toto schéma se nachází ve zdrojových kódech systému Beaker v adresáři Common/bkr/ common/schema pod jménem beaker-job.rng. Součástí RelaxNG schématu může být i dokumentace a díky tomu je schopno popisovat nejen strukturu dokumentu, ale i význam jednotlivých prvků a lze jej použít k automatizovanému generování dokumentace. Součástí provedených změn je i tato dokumentace ve validačním schématu. Byl zde přidán do elementu task volitelný element files, obsahující element file o libovolném počtu výskytů. Pro element file jsou zde také uvedeny atributy name, update, type, encoding a attrs, přičemž všechny 19

4. ÚPRAVY V BEAKERU kromě name jsou volitelné a u atributu update jsou vyjmenované platné hodnoty True a False. Součástí RelaxNG schéma nejsou narozdíl od DTD definovány výchozí hodnoty volitelných atributů. Dále jsou pak uvedeny volitelný element acl a povinný element data, které se mohou vyskytovat v libovolném pořadí. Pro elementy je nutno definovat pořadí, narozdíl od atributů, u kterých na pořadí nezáleží. 4.2 Server Předpis testu je zpracováván Serverem a po zpracování ukládá Server všechny prvky předpisu testu do databáze, aby bylo možné zpětně zjistit všechny parametry testu, nebo test opětovně spustit za stejných podmínek. 4.2.1 Databáze Aby mohly být soubory z předpisu testu uloženy do databáze, je nutné předně vytvořit databázové struktury (tabulky v případě relační databáze). K tomu je použita knihovna SQLAlchemy a databázová struktura je definována ve zdrojovém souboru Server/bkr/server/model.py, kde jsou definovány všechny databázové struktury, které server používá. Předpis testu není uložen v jedné ucelené struktuře, ale je rozdělen na menší části, které jsou provázány identifikátory. Každý job, recipeset, recipe i task má přidělený unikátní identifikátor, v relačních databázových systémech označovaný jako primární klíč. Struktura, která je vázána, obsahuje cizí klíč, jehož hodnotou je primární klíč struktury, ke které je vázána. Díky tomuto rozdělení je možno v databázi vytvářet 1:M vazby, kde může být jedné struktuře job přiřazeno více struktur recipeset, pro recipeset více recipe a pro jeden recipe více struktur task. Protože může mít jeden task více parametrů, je tato vazba použita i pro parametry testu. Stejným způsobem jsou přiřazeny i soubory ke struktuře task cizím klíčem recipe task id. Každá struktura v databázi by měla mít také jednoznačný identifikátor ve formě primárního klíče, a tak má i každý soubor přiřazený primární klíč id. Mimo tyto organizační prvky, jsou ve struktuře souboru přítomny prvky názvem odpovídající atributům a elementům použitým u souboru v předpisu testu, a to name, update, type, encoding, attrs, acl a data. Prvky name, type, encoding a attrs jsou typu unicode [26] řetězce o délce maximální 255ti znaků. Tato velikost byla zvolena podle vzoru ostatních databázových struktur systému Beaker, především pak podle struktury recipe task param, která reprezentuje textové parametry testu. Pr- 20

4. ÚPRAVY V BEAKERU vek update slouží pro uložení pravdivostní hodnoty, a tak je typu boolean. Pro prvek acl je použit datový typ unicode o maximální délce 2048mi znaků. Větší délka je zvolena z toho důvodu, že se v tomto prvku vyskytují nejen názvy souborů, ale tak jejich přístupová oprávnění. Při použití délky 255ti znaků hrozí, že by tato délka nemusela pro tyto údaje postačovat. Poslední a nejdůležitější prvek databázové struktury souboru je prvek data, který je typu unicode. Velikost tohoto prvku není na úrovni databáze nijak omezena, maximální délka je řešena na jiné úrovni a nastavuje se v konfiguračním souboru. Pokud by byla maximální délka uvedena v definici databázové struktury souboru, nebylo by možné flexibilně nastavovat maximální velikost souboru v závislosti na okolnostech. Definovanou databázovou strukturu souboru bylo také nutno svázat se strukturu task, čehož je docíleno pomocí nové python třídy RecipeTaskFile (podle vzoru RecipeTaskParam), která je pomocí SQLAlchemy funkce mapper svázána s nově vytvořenou databázovou strukturou a také je tato třída pomocí této funkce svázána s třídou RecipeTask reprezentující strukturu task. 4.2.2 Zpracování XML předpisu Soubor v předpisu scénáře testu je nutno při přijetí na Serveru zpracovat a uložit do databáze. V souboru Server/bkr/server/jobxml.py je do třídy XMLTask přidána metoda iter files (opět po vzoru zpracování textových parametrů), která je generátorem [27], a jejímž účelem je projít všechny elementy file uvnitř elementu files a postupně je předat ve formě python objektů třídy XMLFile, která dědí třídu ElementWrapper. Tato nově přidaná třída slouží k převodu XML elemetu file na třídu jazyka python a transparentní přístup k prvkům struktury souboru, a to pomocí přetížené metody getattr, která je zavolána, když je přistupováno k prvku třídy, a jejíž návratová hodnota je hodnotou požadovaného prvku. V této třídě jsou přítomny i výchozí hodnoty jednotlivých prvků, pokud nejsou v předpisu testu přítomny. Konstruktor této třídy XMLFile je zděděný z třídy ElementWrapper a argumentem konstruktoru je XML element file reprezentovaný objektem třídy Element z knihovny xmltramp [28]. V souboru jobxml.py je také rozšířena testovací funkce tak, aby jejím výstupem byly i soubory přiřazené k testu. Pro zpracování struktury recipe (a dalších struktur v ní obsažených) slouˇzí v souboru Server/bkr/server/jobs.py metoda 21

4. ÚPRAVY V BEAKERU handlerecipe třídy Jobs. Do této metody bylo přidáno i zpracování a uložení struktury file. Je zde použita výše zmíněná metoda iter files. Před vytvořením nového záznamu v databázi pro soubor je zkontrolováno, zda velikost souboru nepřesahuje maximální velikost, určenou v konfiguračním souboru. Pokud není v konfiguračním souboru žádná maximální velikost určena, je nastavena na nulu, čímž jsou prakticky zakázány soubory jako parametry testu. Toto chování bylo zvoleno s ohledem na potenciální pamět ovou náročnost zpracování předpisu testu bez vědomí uživatelů provozujících systém Beaker. Pokud je velikost menší než maximální, je vytvořen objekt RecipeTaskFile a následně uložen v databázi přiřazený k testu, ke kterému je parametrem. 4.2.3 Generování XML předpisu Systém Beaker umožňuje znovu vygenerovat předpis testu již proběhlého, a tak bylo nutné přidat i opětovné generování elementu file z databázových záznamů této struktury. Část této funkcionality je používána i pro předávání upraveného předpisu testu testovacímu prostředí, které se jím následně řídí při spouštění jednotlivých úloh. Tyto změny byly provedeny v dříve zmiňovaném souboru Server/ bkr/server/model.py a jedná se o třídy RecipeTaskFile a RecipeTask a jejich metody to xml, které slouží k vytvoření XML elementu obsahově shodného s objektem jazyka Python, na kterém je tato metoda zavolána. Ve třídě RecipeTask bylo pouze přidáno volání metody to xml, pro každý objekt třídy RecipeTaskFile přiřazený testu, a následné vložení XML elementů souborů do elementu files, který je přidán do elemetu task. V metodě to xml třídy RecipeTaskFile je vytvořen XML element file a jsou mu nastaveny atributy name, update, type, encoding a attrs. Volitelné atributy jsou nastaveny, pouze pokud byly v původním předpisu zadány, a tím je zajištěna shodnost generovaného předpisu s předpisem původním. Pro data souboru a pro pokročilá oprávnění jsou vytvořeny elementy data a acl, v kterých je vytvořena sekce CDATA. Do této sekce jsou následně umístěna data, resp. pokročilá oprávnění. CDATA sekce slouží k označení části textových dat, která by jinak nemohla být přímo umístěna v textu elementu, např. text obsahující znaky používané jazykem XML. Sekce CDATA je při generování pro zjednodušení vytvořena vždy, nezávisle na obsahu dat a na tom, jestli by mohla být přímo přítomna v textových datech nebo ne. Pokud nebyla pokročilá oprávnění nastavena v původním předpisu testu, není element acl vytvořen ani v generovaném předpisu 22

4. ÚPRAVY V BEAKERU testu. 4.3 Testovací prostředí Změny provedené na Serveru umožňují přijmout, uložit a opět vygenerovat předpis testu, je ovšem také potřeba, aby tyto soubory v předpisu testu byly předány testu samotnému. K tomu slouží testovací prostředí, které zpracovává jednotlivé části předpisu testu, a podle nich nastavuje proměnné prostředí, spouští testy a sleduje zda nějaký test neběží delší dobu, než o sobě deklaruje. Bylo potřeba přidat zpracování souborů z předpisu testu a umístit je na systém souborů na testovacím systému. Tyto změny byly provedeny v testovacím prostředí Beah [?], které je v systému Beaker používáno. Lze použít i jiné testovací prostředí, ovšem v době implementace nebylo žádné takové prostředí veřejně k dispozici. Všechny změny provedené v testovacím prostředí Beah byly v souboru backends/beakerlc.py, který obsahuje kód pro komunikaci s labcontrollerem. 4.3.1 Zpracování XML předpisu Testovací prostředí má k dispozici identifikátor struktury recipe uložené v databází a podle něj je schopen získat od labcontrolleru předpis testu s přidělenými identifikátory strukturám job, recipeset, recipe a task. Z těchto informací je testovací prostředí schopno extrahovat z předpisu testu strukturu recipe, která obsahuje struktury task, popisující testy včetně parametrů, které mají být na testovacím systému provedeny. Bylo nutné upravit zpracování elementu task ve třídě TaskParser a soubory (včetně jejich metadat) uložit do atributu objektu této třídy. Veškerá data potřebná pro spuštění testu jsou pak dostupná v návratové hodnotě metody task data, kam bylo potřeba informace o souborech také přidat. Pro účely zpracování souborů byla v této třídě přidána metoda get files, která pomocí DOM [30] API (aplikační rozhraní) získá všechny elementy file přiřazené k právě zpracovávané úloze. Následně pak získá pomocnými funkcemi (také využívajícími DOM) hodnoty atributů. Pro získání textových dat z elementu byla potřeba přidat pomocná funkce xml cdata, která najde všechny cdata sekce v elementu a spojí je do jednoho textu, kde jsou data spojena znakem nového řádku. Název souboru, další metadata i data jsou uložena ve struktuře dict jazyka python, která slouží jako asociované pole (které k indexaci prvků může použít libovolný objekt nebo ordinální typ jazyka python). Seznam 23

4. ÚPRAVY V BEAKERU všech souborů přiřazených úloze je pak vrácen touto metodou. Volání metody get files bylo přidáno do metody parse (téže třídy), kde je seznam zpracovaných souborů uložen do atributu objektu (který je součástí návratové hodnoty metody task data). 4.3.2 Umístění souboru na testovací systém Příprava spuštění testu je provedena spuštěním funkce vrácené funkcí run task (tato technika je používaná knihovnout twisted [31], kterou Beah používá). Tato funkce potom má k dispozici údaje vrácené metodou task data třídy TaskParser, jejichž součástí jsou i soubory a jejich metadata. Do funkce run task bylo přidáno vytvoření dvou dočasných adresářů, kde první slouží k umístění souborů, které jsou parametry testu, a druhý adresář pro soubory, které test aktualizují. V momentě, kdy je tato funkce spouštěna, totiž nemusí být test ještě nainstalovaný, a tak jej ani není možné aktualizovat. Pro soubory ze seznamu získaného metodou get files je zavolána nově přidaná funkce extract file, jejíž úlohou je vytvořit soubor na testovacím systému s obsahem a metadaty, které jsou mu předány ve formě struktury dict vytvořené funkcí get files. Návratovou hodnotou funkce extract file je cesta k nově vytvořenému souboru, nebo prázdný typ, pokud soubor nebyl vytvořen, nebo slouží k aktualizaci testu. Toto chování je vhodné pro rozeznání, zda soubor je parametrem testu, a tudíž o něm má být test informován prostřednictvím proměnných prostředí, nebo se jedná o soubor, který aktualizuje test (není tím pádem parametrem), nebo soubor nebyl z jakéhokoliv důvodu vytvořen (takový soubor také nemůže být parametrem). Pokud byl takto vytvořen alespoň jeden soubor, který je parametrem testu, je nastavena proměnná prostředí testu TESTFILES, která obsahuje čárkami oddělený seznam takových souborů. 4.3.3 Vytvoření souboru s metadaty Jak bylo výše zmíněno, soubory jsou vytvořeny na testovacím systému pomocí funkce extract file. Argumenty této funkce jsou: údaje o souboru (včetně jeho obsahu) reprezentované strukturou dict, adresář kam mají být umístěny soubory, které jsou parametry testu, a adresář, kde mají být umístěny soubory, které mají sloužit k aktualizaci testu. Tato funkce nejdříve sestaví absolutní cestu k souboru podle názvu souboru a informace, zda má soubor sloužit k aktualizaci. Pokud soubor ne- 24

4. ÚPRAVY V BEAKERU slouží k aktualizaci a jeho název je absolutní cestou, jsou počáteční lomítka z cesty odstraněna, a tato cesta se stává relativní vůči cestě k adresáři určenému k uložení souborů, které jsou parametry testu. Jakmile je celá cesta sestavena, jsou vytvořeny všechny adresáře v této cestě, které dosud neexistovaly. V názvu souborů se tak mohou vyskytnout i adresáře. Po vytvoření cesty k souboru následuje dekódování dat, která mají být v tomto souboru. Při dekódování je postupně zpracováván údaj encoding, který určuje postup, jakým mají být data dekódována. Pokud se v seznamu vyskytuje neznámé kódování, je další zpracovávání takového souboru zastaveno a je vrácena prázdná hodnota indikující, že tento soubor nebylo možné vytvořit. Dekódovaná data nejsou přímo uložena do souboru, ale jsou umístěna v proměnné, protože výsledný soubor může být jiného typu, který potřebuje dodatečné zpracování. Vyčerpání paměti na testovacím systému, by nemělo hrozit díky nastavení maximální velikosti na straně Serveru. V navrhované implementaci se zatím nachází pouze možnost dekódovat data zakódovaná do Base64 nebo komprimovaná pomocí gzip [32]. Po dekódování dat následuje přímé uložení souboru na systém souborů, nebo dodatečné zpracování v závislosti na typu souboru. Momentálně podporované typy jsou text/plain, application/octet-stream, které indikují, že soubor nevyžaduje další zpracování, a application/x-tar, který indukuje, že jde o archiv souborů jehož obsah má být umístěn do adresáře daného názvu (původně názvu souboru). Stejně jako u kódování, pokud jde o neznámý typ, je další zpracování zastaveno a je vrácena prázdná hodnota. Po dodatečném zpracování souboru, v závislosti na typu, je soubor (případně adresář) přítomen na testovacím systému, a je tak možné takovému souboru (nebo adresáři) měnit jednotlivé atributy. Jsou tak nejdříve aplikována (pokud jsou nastavena) pokročilá oprávnění a následně atributy souboru. Mezi (v tomto řešení) podporované atributy patří: přístupová oprávnění, vlastník souboru, skupina souboru, a selinux kontext. Pokud je zadán neznámý atribut, není takový atribut zpracován a pokračuje se v aplikaci dalších atributů. Nakonec, pokud se nejednalo o aktualizační soubor, vrátí funkce extract file cestu k nově vytvořenému souboru, jinak vrátí prázdnou hodnotu. 4.3.4 Aktualizace testu Soubory, které slouží k aktualizaci testu, tj. soubory s relativní cestou označené jako aktualizační, jsou umístěny do dočasného adresáře při přípravě 25