FAKULTA INFORMAČNÍCH TECHNOLOGIÍ

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV POČÍTAČOVÝCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS SYSTÉM PRO ŘÍZENÍ VIRTUÁLNÍCH SERVERŮ BAKALÁŘSKÁ PRÁCE BACHELOR S THESIS AUTOR PRÁCE AUTHOR DAVID KARBAN BRNO 2008

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV POČÍTAČOVÝCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS SYSTÉM PRO ŘÍZENÍ VIRTUÁLNÍCH SERVERŮ SYSTEM FOR VIRTUAL SERVER ADMINISTRATION BAKALÁŘSKÁ PRÁCE BACHELOR S THESIS AUTOR PRÁCE AUTHOR VEDOUCÍ PRÁCE SUPERVISOR DAVID KARBAN Ing. KAŠPÁREK TOMÁŠ BRNO 2008

Abstrakt S nárůstem výkonu počítačových sestav se rozvíjí trend virtualizace počítačů. Na jednom fyzickém počítači může být virtualizováno i několik samostatných počítačů virtuálních. Toho se využívá v mnoha oblastech, ve vývoji jader operačních systémů, testování nového software, výzkumu chování virů, pro úspory na HW. Na druhé straně se zvyšují nároky na správu takového počítače. Tato práce se zabývá vytvořením systému, který by umožnil zmenšit negativní dopady virtualizace na správu virtuálních počítačů. Cílem práce je vytvořit obecné rozhraní pro ovládání virtualizovaných počítačů s možností přizpůsobení na konkrétní konfigurace. Práce popisuje vývoj takového systému od specifikace požadavků, přes analýzu a návrh aplikace až k její implementaci. Klíčová slova virtualizace, linux-vserver, xml-rpc, ssh, C, mysql, bash Abstract There is coming trend of virtualization on modern computers. One computer may act like host for several guest virtualized computers. This has many advantages, like for kernel development, software testing, virus behaviour testing, saving HW resources. On the other hand, complexity of computer maintenance is growing too. This bachelor thesis describes a system, that can be used for management of many virtual servers and lower the manageability overhead. This work will create a generic control interface for virtualized computers. Interface will be adaptable and extendible. The development of this system is described from specification through analysis to concept and implementation of application. Keywords virtualization, linux-vserver, xml-rpc, ssh, C, mysql, bash Citace David Karban: Systém pro řízení virtuálních serverů, bakalářská práce, Brno, FIT VUT v Brně, 2008

Systém pro řízení virtuálních serverů Prohlášení Prohlašuji, že jsem tuto bakalářskou práci vypracoval samostatně pod vedením pana Ing. Kašpárka Tomáše. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal........................ David Karban 26. ledna 2009 Poděkování Tímto bych chtěl poděkovat panu Ing. Tomášovi Kašpárkovi. Za rady a odbornou pomoc při vedení bakalářské práce. Děkuji také všem těm, co mi poskytli podporu a sílu se do toho pustit. Bez nich by tato práce nikdy nevznikla. c David Karban, 2008. Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů.

Obsah 1 Úvod 3 2 Specifikace požadavků 5 2.1 Problémy vzniklé virtualizací.......................... 5 2.2 Popis služeb.................................... 6 2.3 Funkční požadavky................................ 7 2.4 Nefunkční požadavky............................... 8 3 Analýza 10 3.1 Diagram činností................................. 10 3.2 Datová analýza.................................. 10 3.2.1 Server................................... 10 3.2.2 Služby web a ftp............................. 13 3.2.3 Služba mail................................ 15 3.3 Analýza sít ové části aplikace a komunikačního rozhraní........... 17 3.3.1 Metody RPC............................... 17 3.3.2 Podrobný rozbor metod XML-RPC a SSH............... 18 4 Návrh a implementace 24 4.1 Použité technologie................................ 24 4.1.1 Linux-vserver............................... 24 4.1.2 Jazyk C.................................. 25 4.1.3 Mysql................................... 25 4.1.4 Bash shell................................. 25 4.2 Návrh aplikace.................................. 25 4.2.1 Autentifikace a šifrování......................... 25 4.2.2 Cesta požadavku............................. 25 4.3 Komunikační interface.............................. 26 5 Závěr 29 1

Seznam použitých termínů démon aplikace obsluhující službu, např. webserver guest host virtualizovaný počítač běžící na hostu fyzický počítač, hostitel pro virtuální počítače ovládací konzole aplikace posílající požadavky pomocí RPC RPC vzdálené volání procedur server fyzický nebo virtuální počítač poskytující jednu nebo více služeb VSM Virtual server management 2

Kapitola 1 Úvod S nárůstem výkonu počítačových sestav se začal rozvíjet trend jejich virtualizace, kdy je na jednom fyzickém počítači virtualizováno několik samostatných počítačů. Toho se využívá v mnoha oblastech, například při výzkumu virů, pro úsporu množství fyzických počítačů. Virtualizace se také používá pro zlepšení bezpečnosti umístěním služeb do samostatných virtualizovaných počítačů. Existuje několik metod virtualizace, od izolace procesů, kdy dochází pouze k větší izolaci procesů, až po emulování celé architektury. Každá z metod má odlišnou náročnost a spotřebu systémových zdrojů. Metoda emulace celé architektury je nejnáročnější na systémové zdroje ale dokáže emulovat libovolnou architekturu. Je z virtualizačních metod nejpomalejší, běžné je i 100násobné zpomalení běhu aplikace. Na této metodě pracuje emulátor Bochs 1. Ostatní virtualizační řešení nepodporují libovolné architektury, dokáží virtualizovat pouze hostitelovu architekturu. Metoda plné virtualizace používá předřazenou jednotku (hypervizor). Tato jednotka zachytává instrukce, které je třeba emulovat. Ostatní instrukce jsou prováděny přímo. Operační systém běžící pod hypervizorem nemusí být modifikován. Další používanou metodou je metoda paravirtualizace, která se podobá metodě plné virtualizace. Narozdíl od ní ale spolupracuje s virtualizovaným operačním systémem. Díky této spolupráci je virtualizace rychlejší než u plné virtualizace. Tuto metodu používají například XeN 2, VMware 3. Metoda virtualizace na úrovni operačního systému je ze všech metod nejrychlejší, ale také toho umí nejméně. Pracuje na úrovni operačního systému, v principu jde o rozšířenou izolaci procesů. Tento druh virtualizace podporuje pouze stejný operační systém a stejnou architekturu jako hostitelský systém. Systémy používající tento druh virtualizace jsou například linux-vserver 4 a openvz 5. Při používání virtualizace je třeba odlišit virtualizovaný systém od systému, na kterém běží virtualizace. Pro tyto účely zavádíme pojem host, to je hostitelský počítač a guest, to je virtualizovaný počítač běžící na hostu. Virtualizace s sebou přináší také nevýhody, dochází k ztížení správy počítače, na místo jednoho operačního systému je jich několik, s různou konfigurací a požadavky na ni. Tato 1 http://bochs.sourceforge.net/ 2 http://www.xen.org/ 3 http://www.vmware.com/ 4 http://linux-vserver.org/ 5 http://wiki.openvz.org 3

situace je podobná řešení s větším množstvím počítačů, tzv. clusterem, dochází ke stejnému nárustu složitosti správy a v tomto případě i k nárustu finanční náročnosti. Cílem této práce je zjednodušit správu virtuálních počítačů, vyvinout aplikaci, pomocí které lze spravovat služby a software z jednoho bodu. Použité řešení bude primárně orientováno na platformu GNU/Linux a virtualizační technologii linux-vserver. Řešení bude rozšiřitelné i na jiné virtualizační metody a operační systémy. Použité řešení bude nasazeno na mém webhostingovém serveru. Používám na něm technologii linux-vserver pro izolaci jednotlivých služeb. Na jednom počítači mám 7 virtuálních počítačů. Pro jejich správu je nutné se vždy přihlásit na virtuální počítač a provést požadované operace a toto opakovat pro každý zvlášt. Nasazením řešení dojde k zmenšení nároků na administraci systému. Kapitola 2 popisuje problémy vzniklé nasazením virtualizace a z nich vyvozuje specifikaci požadavků kladených na vyvíjený systém. Požadavky jsou rozepsány na úroveň popisu jednotlivých služeb a procesů nutných k jejich správě. Kapitova 3 popisuje analýzu datové, aplikační a transportní části systému. Kapitola 4 popisuje návrh, použité technologie a způsob implementace aplikace. 4

Kapitola 2 Specifikace požadavků Tato kapitola se zabývá specifikací požadavků kladených na vývoj systému. V první části nastíní problémy vzniklé nasazením virtualizačního řešení. Dále se bude věnovat popisu poskytovaných služeb a atributů které tyto služby potřebují k běhu. Také se zabývá funkčními a nefunkčními požadavky, které určují požadované funkce aplikace. 2.1 Problémy vzniklé virtualizací Správa serveru bez použité virtualizace spočívá v práci přímo na serveru lokálně, stačí jeden účet pro běžnou administraci. Skriptování automatizovaných dávek, jako například registrace nového uživatele, jsou snadné. Tento stav schématicky ukazuje obr. 2.1. Registrace uživatele s webovým prostorem, emailem a jednou databází je proveditelná z jednoho místa. Server (web, ftp, mysql, mail) Administrátor Obrázek 2.1: Schéma administrace před virtualizací Zavedení virtualizace situaci komplikuje, místo jednoho serveru máme serverů několik. Tyto servery sice sdílejí stejný fyzický hardware, ale jsou od sebe navzájem izolovány. To pomáhá zvyšovat zabezpečení, ale na úkor náročnosti správy. Schématické znázornění viz obr. 2.2. Registrace uživatele je narozdíl od předchozího případu náročná, je třeba spustit 3 skripty, jeden na webovém, jeden na mailovém a jeden na mysql virtuálním serveru. Pro zjednodušení administrace je potřeba navrhnout aplikaci, která dokáže provádět úlohy na několika virtuálních serverech zároveň. Například u registrace nového uživatele by byl zadán požadavek na jeho vytvoření jako v případě před zavedením virtualizace, z jednoho místa. Skripty by se ale spustily na jednotlivých virutálních serverech. Schématicky viz obr. 2.3. Problémy vzniklé virtualizací se do značné míry shodují s problémy, které je třeba řešit u clusteru počítačů. U takového systému je také nutné přistupovat k jednotlivým službám zvlášt, Od virtualizovaného řešení se liší hlavně tím, že se jedná o větší množství fyzických počítačů, narozdíl od více virtuálních počítačů na jednom fyzickém. 5

VS1 (web, ftp) VS2 (mysql) Administrátor VS3 (mail) VS4 (web, ftp) Obrázek 2.2: Schéma administrace po nasazení virtualizace Z pohledu správy je u virtualizovaného řešení možné přistupovat na virtuální počítače z hosta, u clusteru je nutné přihlašovat se zvlášt ke každému počítači. Díky přístupu k virtualizovaným počítačům z hostitelského je možné na něm mít pouze jednu aplikaci, která bude spravovat jeho virtuální servery. V případě clusteru by pro každý server musela běžet jedna aplikace. 2.2 Popis služeb Na virtuálních serverech poskytuji služby hostování webových stránek, ftp účtů, mysql účtů a emailů. Webové služby, ftp a mysql jsou rozděleny do tří virtuálních serverů, mail server je jeden. Dále se na serveru vyskytuje virtuální server se službou jabber, testovací virtuální server a jeden uživatelský virtuální server. Systém umožní vytvářet, modifikovat a mazat jednotlivé služby na virtuálních serverech, například uživatelské web účty na webových serverech, mail účty na mail serveru, apod. Webové služby poskytují prostor pro data, která budou zobrazena na internetu. Pro svůj provoz potřebují mít definován prostor pro umístění dat a webovou adresu, na které jsou data přístupná. Webových adres pro přístup na jeden prostor může být více, další adresy krom první se navývají aliasy. Webové služby mohou podporovat skriptování jazykem PHP. Různé webové stránky mohou mít různé požadavky na nastavení PHP, proto je pro ně nutné mít možnost individuálního nastavení. Další možností nastavení webové služby je nastavení zaheslovaného přístupu ke stránkám. Pro toto nastavení je potřeba předat uživatelské jméno, heslo a místo na webu, které má být zašifrováno. Další informace pro nastavení webserveru jsou emailová adresa správce stránek, tato hodnota je nepovinná ale je vhodné ji mít nastavenou, aby bylo možné v případě výpadku stránky zobrazit email, na který je možné o něm informovat. U webových služeb může být také individuální nastavení logování, povolení HTTP autentifikace a nastavení doménového koše, kdy se jakákoliv neexistující poddoména webu automaticky přesměruje na hlavní stránku domény. 6

VS1 (web, ftp) VS2 (mysql) Aplikace Administrátor VS3 (mail) VS4 (web, ftp) Obrázek 2.3: Schéma administrace po nasazení aplikace Ftp služby jsou doplňkem k webovým službám, umožňují nahrávat na server soubory, nebo je mazat. Ke svému provozu potřebují příhlašovací jméno a heslo aby bylo možné autentifikovat uživatele, dále prostor kam lze nahrát soubory. Mysql služby jsou také doplňkem k webovým službám, umožňují udržovat data v relační databázi mysql. Ke svému provozu potřebují přihlašovací jméno a heslo kvůli autorizaci uživatele. Emailové služby poskytují uživateli schránku na emaily, umožňují jejich posílání a příjem. Dále je možné poskytovat tzv. doménový koš, kdy všechny maily poslané na doménu jsou směrovány do jedné určené stránky. K provozu mailové schránky je potřeba přihlašovací jméno a heslo kvůli autorizaci a prostor na uložení mailu. Email je možné přesměrovat na libovolný jiný email. Uživatelské virtuální servery jsou spravovány uživateli. Ti se starají o správu virtuálního serveru sami. Je ovšem potřeba mít i možnost vypnutí, restartu a zapnutí virtuálního serveru, nejen pro uživatelské ale i pro ostatní virtuální servery. 2.3 Funkční požadavky Bez virtualizace by mohla být administrace prováděna pomocí web aplikace přímo na serveru, šlo by o spouštění skriptů lokálně. S virtualizací je situace odlišná, jednotlivé virtuální servery se navzájem nevidí a není možné, aby jeden zasahoval do běhu dalšího. Jednou z možností správy stejným způsobem by bylo mít web aplikaci přístupnou na hostu serveru a z ní provádět spouštění skriptů. Pokud by došlo k rozšíření na více fyzických serverů, musela by být aplikace instalována na každý z nich a pro správu by bylo nutné vždy přistupovat na hosta. Tímto by zmizela výhoda centrálního ovládání. Lepší variantou je mít jedno ovládací rozhraní a na jednotlivých hostech aplikaci schopnou přijímat požadavky na správu. V takovém případě budou veškeré požadavky na správu posílány z jednoho místa a dojde k jejímu usnadnění i v případě velkého růstu obsluhovaných počítačů. Pro efektivní správu je vhodné mít zaznamenány všechny důležité informace, proto bude součásti řešení návrh a implementace databáze. Databáze bude rozdělena na dvě části, 7

jedna část bude umístěna na počítači s ovládacím rozhraním, v ní budou souhrnné informace o serverech, virtuálních serverech a službách na nich provozovaných. Druhá část bude umístěna na virtuálních serverech a bude obsahovat informace nutné pro běh konkrétních služeb. Druhá část databáze by mohla být umístěna také na hostu a být sdílena pro všechny virtuální servery. Toto řešení by zjednodušilo instalaci, ale zhoršilo by bezpečnost provozu, při prolomení služeb na jednom virtuálním serveru by mohlo dojít k útoku na všechny ostatní na hostu skrz databázi. Také je díky virtualizaci možné snadno přenášet jednotlivé virtuální servery mezi fyzickými počítači, v případě databáze umístěné na virtuálním serveru je přenos všech nastavení automatický. V opačném případě by musela být při přesunu virtuálního serveru přenesena také část databáze hosta. Při požadavcích na webové služby je nutné vždy předat její identifikátor, tím je adresa webové služby, která byla použita při jejím vytvoření. Následuje popis dalších parametrů, které je potřeba pro jednotlivé změny služeb. K vytvoření je potřeba jako parametry předat umístění dat služby, identifikátor vlastníka stránek. Při smazání webové služby není třeba zadat dodatečné parametry. Pro nastavení aliasů k webové službě je potřeba poslat v požadavku alias pro nastavení, nebo více aliasů oddělených mezi sebou mezerou. Pokud je požadován vlastní log, doménový koš a nebo podpora pro HTTP autorizaci, je nutné poslat požadavek na jejich aktivaci/deaktivaci který bude obsahovat požadovaný příznak a jeho nový stav. Pro nastavení/změnu konfigurace PHP je nutné poslat typ, jméno a hodnotu konfigurace. Při vymazání nastavení PHP je nutné poslat požadavek na smazání s pravidlem, o které se jedná. Pro zaheslování webového adresáře je potřeba poslat požadavek s uživatelským jménem, heslem a adresářem, který je třeba zaheslovat. Při rušení zaheslování je třeba poslat informace o uživatelském jménu a adresáři. Při požadavku na nastavení/zrušení emailové adresy administrátora stránek je potřeba poslat jen emailovou adresu. Při požadavcích na službu ftp je vždy potřeba identifikace služby, kterou je přihlašovací jméno uživatele na ftp. Pro vytvoření ftp účtu je dále potřeba poslat heslo, identifikátor majitele ftp a domovský adresář pro ftp. Pro smazání ftp účtu není třeba dalších parametrů. Požadavky na mysql jsou bud požadavky na databázi, pak musí obsahovat jméno databáze, nebo jsou to požadavky na uživatele databáze, pak musí obsahovat jméno uživatele. Při požadavku na vytvoření nebo smazání databáze není potřeba dalších parametrů. Při vytvoření nebo smazání uživatele také ne. Při nastavování práv uživatele k databázím je nutné uvést jak jméno databáze, tak jméno uživatele. Při nastavování práv jsou vždy uživateli nastavená plná práva k určené databázi. U mail serveru je stejně jako u ftp serveru nutné zadat přihlašovací jméno uživatele, při vytvoření účtu ale není potřeba zadávat adresář do kterého se budou ukládat maily, ten je vybrán automaticky, je nutné zadat heslo. Požadavek na aktivaci doménového koše potřebuje jako parametr email, na který mají být všechny doručené maily přeposlány. Požadavek na smazání emailové schránky nepotřebuje další parametry. Pro aktivaci přesměrování emailu je nutné zadat email, na který má být schránka přesměrována, pro jeho zrušení není žádný další parametr potřeba. K požadavkům na ovládání virtuálních serverů je potřeba vždy zadat pouze jméno virtuálního serveru. Požadavky jsou na vypnutí, zapnutí a restart virtuálního serveru. 2.4 Nefunkční požadavky Serverová část systému by měla být co nejmenší a nejrychlejší, aby nezabírala zbytečně zdroje serveru. Zároveň by měla být napsána v přenosném jazyce, aby bylo snadné aplikaci 8

portovat na jiné operační systémy. Proto byl jako implementační jazyk zvolen jazyk C, který obě podmínky splňuje. Ovládací konzole bude zpracována jako řádková příkazová aplikace nebo více aplikací, které budou posílat požadavky. To umožní snadné použití aplikace při skriptování a automatizaci úkonů. Jako implementační databáze byla zvolena mysql, která už je na většině virtuálních serverů nainstalována a používána. Pro komunikaci mezi ovládací konzolí a host aplikací jsou zvažovány varianty vzdáleného přístupu přes SSH a nebo použití vzdáleného volání procedur (RPC). Použití SSH by usnadnilo velké množství operací jako autentifikace nebo šifrování. Použití RPC umožňuje naproti tomu vytvořit přístupové rozhraní k posílání požadavků a za něj skrýt konkrétní implementaci jejich provádění na dané platformě. Podrobná analýza vhodného způsobu přenosu požadavků bude provedena v následující kapitole. 9

Kapitola 3 Analýza Následující kapitola se zabývá návrhem systému a jeho jednotlivých částí. Nejprve bude popsána analýza chování a datová část aplikace. Poté bude popsána analýza sít ové části aplikace a komunikačního rozhraní. 3.1 Diagram činností Diagram zobrazený na obrázku 3.1 popisuje možné akce proveditelné v systému. Je to práce s prostorem pro webové stránky, nastavením PHP, mysql databázi, emaily, nastavením virtuálních serverů a ftp. 3.2 Datová analýza Datová analýza popisuje strukturu databázové části aplikace, strukturu tabulek a jejich vzájemné vazby. Analýza je rozdělena do dvou logických celků. V prvním jsou tabulky použité pro uložení vazeb serverů, virtuálních serverů a služeb na nich běžících pro potřeby ovládací konzole. V druhé části jsou popsané tabulky použité pro ukládání stavu jednotlivých služeb, které jsou umístěny přímo na virtuálních serverech. To umožňuje samostatný běh serverů bez závislosti na ovládacím rozhraní. Schéma ovládacích tabulek je vytvořeno dostatečně obecně, aby šlo použít i v situaci kdy by místo virtualizace bylo použito řešení s více počítači. Z toho důvodu nebude, až na nutné výjimky, v následujícím textu rozlišováno mezi serverem a virtuálním serverem a bude použito souhrnné označení server. Hodnota velikosti v tabulkách datových typů označuje počet použitých bajtů. Velikosti atributů pro doménová jména byly převzaty z RFC1035 [6], které definuje maximální velikost domény 255 bajtů. 3.2.1 Server ER diagram pro ovládací rozhraní je schématicky znázorněn na obrázku 3.2. Následující tabulky jsou použity pro ukládání obecných informací o jednotlivých serverech, jako jejich IP adresa, jméno, typy služeb, které na nich jsou dostupné, atd. Server obsahuje záznamy o serverech. Atribut host id umožňuje rozlišení serveru. Ukazujeli na svého otce, je virtuálním serverem. Ukazuje-li sám na sebe je serverem. 10

Zrušit zaheslování Vytvořit Alias Smazat Alias Změnit heslo Vytvořit zaheslování Správa zaheslování Správa aliasů Přidat nastavení Správa php Odebrat nastavení Vytvořit «extend» «extend» «extend» Smazat Webový prostor Smazat příznak (auth, log, koš) Nastavit příznak (auth, log, koš) Zapnout Restartovat Virtuální servery Změnit heslo Vytvořit Email «extend» Přesměrování «extend» Nastavit Zrušit Vypnout Administrátor Smazat Koš Nastavit Zrušit Vytvořit Mysql Ftp «extend» «extend» Změnit heslo Smazat Databáze Uživatel Vytvořit Změnit heslo Vytvořit databázi Smazat databázi Smazat Přiřadit databázi Odřadit od databáze Obrázek 3.1: Use case diagram Název atributu Typ(velikost) Klíč NULL index Význam atributu id int(2) PK NE ANO host id int(2) FK NE ANO Host server. V tabulce server info jsou informace o serveru. Jedná se o jeho hostname a IP adresu. Tyto údaje byly oddělěny do samostatné tabulky aby bylo možné mít na jednom serveru IP adres více. Název atributu Typ(velikost) Klíč NULL index Význam atributu server id int(2) FK NE ANO Cizí klíč do server. hostname varchar(255) NE NE NE Název serveru. IP varchar(64) NE NE NE IP adresa serveru. Záznamy v tabulce service type určují typy služeb na serveru přístupné. Atribut type vyjadřuje druh služby (web, ftp, mail), atribut daemon vyjadřuje aplikaci obsluhující službu 11

Primární klíč id server_info + hostname: string + ip: string * 1 + id: int + host_id * + id 1 server 1 server_service 1 * * service je na serveru * service + name: string je vserver požadavky * service je typu request 1 + value: string + start_time: timestamp + end_time: timestamp service_type + status: int + id: int + type: enum request je typu+ daemon: string * 1 1 Primární klíč id Obrázek 3.2: ER diagram ovládacího rozhraní (apache, lighttpd pro web, postfix, courier pro mail, apod). Tímto je do systému možno přidat další druhy služeb i další aplikace na už existující služby. Název atributu Typ(velikost) Klíč NULL index Význam atributu id int(2) PK NE ANO type enum( web, mail, NE NE NE Název služby. mysql, ftp ) daemon varchar(64) NE NE NE Obsluhující aplikace. Server service určuje jakou službu je možné provádět na jakém serveru. Jde o slabou vazební entitu, která nahrazuje M:N vazbu mezi tabulkami server a service type. Název atributu Typ(velikost) Klíč NULL index Význam atributu server id int(2) FK NE ANO Cizí klíč do server. service type id int(2) FK NE ANO Cizí klíč do service type. Service obsahuje seznam uživatelských účtů na serverech. Atribut name obsahuje informace o jménu uživatelského účtu (např. emailová adresa, adresa web stránek, apod.). Název atributu Typ(velikost) Klíč NULL index Význam atributu server id int(2) FK NE ANO Cizí klíč do server. service type id int(2) FK NE ANO Cizí klíč do service type. name varchar(255) NE NE NE Jméno služby. Request zaznamenává požadavky posílané serverům. Ukládá jeho parametry, dobu zpra- 12

cování a jeho aktuální stav. Atributy start time a end time slouží k záznamu o době provádění požadavku. Status určuje stav provedení požadavku, může nabývat hodnot 0 při provádění došlo k chybě, 1 proveden v pořádku. Název atributu Typ(velikost) Klíč NULL index Význam atributu server id int(2) FK NE ANO Cizí klíč do server. service type id int(2) FK NE ANO Cizí klíč do service type. value text NE NE NE Obsah požadavku. start time timestamp NE NE NE Čas začátku požadavku. end time timestamp NE NE NE Čas konce požadavku. status int(1) NE NE NE 3.2.2 Služby web a ftp ER diagram pro služby ftp a web je schématicky znázorněn na obrázku 3.3. Tyto tabulky jsou používány pro uložení konkrétních informací jako přístupové údaje ke službám, umístění domácího adresáře na serveru, apod. Tabulky jsou umístěny přímo na serverech, které poskytují služby. Primární klíč id ftp + username: string + password: string + uid: int + gid: int + homedir: string + status: int web + id: int + name: string + document_root: string + owner: string + group: string + admin_email: string + has_basket: int + has_log: int + has_auth: int + status: int 1 autentifikace * alias 1 * nastaveni php 1 * web_alias + name: string + status: int web_php + type: enum + name: string + value: string + status: int web_auth + username: string + password: string + auth_realm: string + auth_type: string + service: string + directory: string + status: int Obrázek 3.3: ER diagram databází služeb web a ftp Tabulka ftp obsahuje informace nutné k fungování ftp účtů na serveru. Obsahuje např. jméno uživatele, jeho oprávnění a umístění jeho domovského adresáře. Atributy uid, gid 13

obsahují nastavení vlastníka a skupiny uživatele. Atribut status může nabývat hodnot 0 neaktivní, 1 aktivní. Název atributu Typ(velikost) Klíč NULL index Význam atributu username varchar(64) PK NE ANO Přihlašovací jméno. password char(13) NE NE NE Heslo. uid int(2) NE NE NE UID uživatele. gid int(2) NE NE NE GID uživatele. homedir varchar(384) NE NE NE Domácí adresář. status int(1) NE NE NE Stav ftp. Web obsahuje informace o webech na serveru. Obsahuje např. název webu, email administrátora, umístění domovského adresáře webu. Atribut name je hlavním názvem webu, od něj se odvozují subdomény, např. vutbr.cz je hlavním názvem a subdoména je www, cílová stránka je pak www.vutbr.cz. Atribut name má nastaveno omezení na unikátnost, v tabulce nemůže být více záznamů se stejnou hodnotou atributu name. Atribut admin email je nepovinný, obsahuje emailovou adresu administrátora stránek. Atributy has umožňují nastavit doplňkové funkce. Je-li atribut has basket nastaven na 1, budou veškeré přístupy na neexistující web na doméně přesměrovány na hlavní webovou stránku. Atribut has log umožňuje aktivovat log speciálně pro web, je-li nastaven na 1 má vlastní log soubory. Has auth umožňuje použití HTTP autentifikace. Atribut status může nabývat hodnot 0 neaktivní, 1 aktivní. Název atributu Typ(velikost) Klíč NULL index Význam atributu id int(2) PK NE ANO name varchar(255) NE NE ANO Název domény, unikátni. document root varchar(384) NE NE NE Umístění na disku. owner varchar(64) NE NE NE Vlastník souborů. group varchar(64) NE NE NE Skupina vlastníka. admin email varchar(384) NE ANO NE Email správce. has basket int(1) NE NE NE Doménový koš. has log int(1) NE NE NE Nastavení logování. has auth int(1) NE NE NE Podpora HTTP autorizace. status int(1) NE NE NE Stav služby. V tabulce web alias jsou uloženy další názvy pro web. Tímto způsobem je možné nadefinovat libovolně množství názvů u jednoho webu. Atributy name má omezení na unikátnost, nemůže xistovat více aliasů se stejným jménem. Je možné mít stejný alias u více webů zároveň. Který web je zobrazen rozhoduje nastavení DNS jména. Atribut status může nabývat hodnot 0 neaktivní, 1 aktivní. Název atributu Typ(velikost) Klíč NULL index Význam atributu web id int(2) FK NE ANO Cizí klič do web. name char(255) NE NE ANO Jméno aliasu, unikátní. status int(1) NE NE NE Stav aliasu. Tabulka web php slouží k uložení informací o nastavení PHP webu. Do tabulky se vkládají pouze záznamy odlišné od standardní konfigurace PHP. To umožní nastavit u jednotlivých 14

webů speciální parametry php pokud je to potřeba. PHP umožňuje nastavit parametry typu boolean a ostatní parametry. Pro tato nastavení používají klíčová slova php admin flag a php admin value. Tato dvě slova mohou být v atributu type. Atribut name určuje konkrétní nastavení PHP, které se má upravit. Atribut value určuje na jakou hodnotu má být nastavení změněno. Atribut status může nabývat hodnot 0 neaktivní, 1 aktivní. Nad atributy web id a name je vytvořen unikátní index, nelze mít pro jeden web více nastavení stejného typu. Název atributu Typ(velikost) Klíč NULL index Význam atributu web id int(2) FK NE ANO Cizí klíč do web type enum(, NE NE NE Typ parametru php admin flag ) php admin value ) name vachar(48) NE NE ANO Konfigurační volba. value varchar(256) NE NE NE Nastavená hodnota. status int(1) NE NE NE Stav služby. Web auth ukládá autorizační informace pro přístup k webu. Je používána k uložení hesel a autorizaci uživatelských přístupů do adresářů, nebo k službám typu WebDav, Svn, zobrazení serverových statistik. Je navržena tak at umožní přidat autorizaci na libovolnou službu kterou je nutné na webu zaheslovat. Atribut auth realm určuje oblast působnosti autorizace (je možné mít např. společné heslo pro několik adresářů). Atribut auth type určuje způsob zašifrování jména a hesla, jeho možné hodnoty jsou Basic - jméno a heslo se posílají nešifrovaně, Digest - heslo se před posláním přepočítá algoritmem md5. Atribut service uchovává název služby pro kterou se provádí autorizace, v době psaní práce se jedná pouze o službu heslování přístupu do adresáře. V tomto případě je atribut nastaven na hodnotu dir. Atribut directory obsahuje cestu k zaheslovanému adresáři relativně k atributu document root z tabulky web. V ostatních případech je atribut roven NULL. Nad atributy web id, username, directory je vytvořen unikátní index, nelze mít duplicitní nastavení pro jednoho uživatele na jednom webu. Název atributu Typ(velikost) Klíč NULL index Význam atributu web id int(2) FK NE ANO Cizí klíč do web. username varchar(64) NE NE ANO Přihlašovací jméno. password char(13) NE NE NE Heslo. auth realm varchar(64) NE NE NE Oblast působnosti. auth type varchar(64) NE NE NE Typ šifrování. service varchar(16) NE NE NE Služba k autorizaci. directory varchar(128) NE NE ANO Adresář k zaheslování. status int(1) NE NE NE Stav autorizace. 3.2.3 Služba mail ER diagram pro službu mail je schématicky znázorněn na obrázku 3.4. Tyto tabulky jsou používány pro uložení konkrétních informací jako přístupové údaje ke službám, umístění domácího adresáře na serveru, apod. Tabulky jsou umístěny přímo na serverech, které poskytují služby a jsou vytvořeny pro mail server postfix. Tabulky byly převzaty z manuálnu k instalaci mailového serveru na Gentoo Linux[4]. Ten ukazuje kompletní instalaci mail ser- 15

veru postfix včetně podpory pro virtuální domény. Postupy v něm popsané jsou dostatečně flexibilní pro naše potřeby, byly proto z velké části bez úprav převzaty. Jediné provedené úpravy jsou v nastavení indexů v tabulkách. Mail server postfix rozlišuje lokální a virtuální doručování mailů. Lokální doručování ukládá maily do lokálních systémových účtů serveru, virtuální ukládá maily na místo určené v tabulce users. Primární klíč id virtual alias users + id: int + email: string + clear: string + name: string + uid: int + gid: int + homedir: string + maildir: string + quota: string + postfix: enum Primární klíč id Primární klíč id + id: int + email: string + destination: string transport + id: int + domain: string + destination: enum + id: int + alias: string + destination: string Primární klíč id Obrázek 3.4: ER diagram databází služby mail Tabulka users obsahuje informace o mailech uživatelů. Obsahuje např. jméno uživatele, heslo, umístění adresáře na uložení mailů. Atributy uid, gid obsahují nastavení vlastníka a skupiny uživatele. Atribut homedir ukazuje na domovský adresář uživatele na mailovém serveru, atribut maildir pak na konkrétní schránku s maily. V atributu name je volitelně možné uložit jméno uživatele. Atribut quota není v současné době použit. Atribut postfix může nabývat hodnot y schránka je aktivní, n schránka je neaktivní. Atribut mail má vytvořen unikátní index, nelze mít více záznamů pro stejnou mailovou adresu. Název atributu Typ(velikost) Klíč NULL index Význam atributu id int(2) PK NE ANO email varchar(255) NE NE ANO Mailová adresa, unikátní. clear varchar(128) NE NE NE Heslo. name tinytext NE ANO NE Jméno. uid int(3) NE NE NE UID uživatele. gid int(3) NE NE NE GID uživatele. homedir tinytext NE NE NE Domácí adresář. maildir tinytext NE NE NE Mail adresář. quota tinytext NE ANO NE Nepoužito. postfix enum( y, n ) NE NE NE Stav mailové schránky. Tabulky virtual a alias jsou používány k uložení informací o mail aliasech. Jejich struktura je stejná, liší se použitím. Tabulka alias je použita pro lokální mail aliasy, tabulka virtual pro mail aliasy na virtuálních domény. Obě tabulky mají stejnou strukturu, proto jsou podrobněji rozepsány pouze jednou. Mail aliasy se používají na přesměrování mailu na jednu, nebo více mailových adres. Do atribut email ukládáme informace o mailu který je přesmérován. Atribut destination ukazuje kam má být mail přesměrován, může být přesměrován i na více mail adres. Jednotlivé adresy jsou odděleny mezerou. Mail aliasy se 16

používají také pro nastavení doménového koše. Je-li v atributu mail uvedena celá doména ve tvaru @domena.cz dojde k přesměrování všech mailů dané domény. Atribut mail má vytvořen unikátní index, nelze mít více záznamů pro stejnou mailovou adresu. Název atributu Typ(velikost) Klíč NULL index Význam atributu id int PK NE ANO email varchar(128) NE NE ANO Mailová adresa, unikátní. destination varchar(1024) NE NE NE Cíl přesměrování. Transport ukládá informace potřebné k rozlišení jedná-li se o lokální, nebo virtuální doručování. Je potřebná při doručování příchozích mailů, záznamy v ní určují má-li mail být doručen lokálně, nebo virtuálně. Rozdělení se děje podle domény příchozího mailu. Atribut domain obsahuje domény, které mail server obsluhuje a má vytvořen unikátní index. Atribut destination může nabývat hodnot local: jedná se o lokální doručování, nebo virtual: jedná se o doručování virtuální. Název atributu Typ(velikost) Klíč NULL index Význam atributu id(2) int PK NE ANO domain varchar(128) NE NE ANO Doména, unikátní. destination enum( virtual:, NE NE NE Způsob doručení. local: ) 3.3 Analýza sít ové části aplikace a komunikačního rozhraní Tato kapitola popisuje možné metody vzdáleného volání požadavků. Práce se zabývá spouštěním vzdálených procedur, proto byly vyhledány existující protokoly RPC. Nejprve jsou rozebírány nejznámější metody, jejich obecné vlastnosti a z toho vyplývající použitelnost. Použitelné metody jsou následně rozepsány podrobněji. 3.3.1 Metody RPC XML-RPC XML-RPC [11] je způsob vzdáleného volání procedur, při kterém jsou požadavky kódovány do XML. Protokol používá HTTP jako transportní vrstvu pro přenos dat. Díky použití XML pro přenos dat je snadné posílat různě strukturované požadavky. Protokol je velice jednoduchý a poskytuje dostatečnou flexibilitu pro naše použití. Mezi jeho výhody patří oddělení způsobu volání požadavků od jejich zpracování. Jeho nevýhodou je neexistující autentifikace ani šifrování v návrhu protokolu. SOAP SOAP [7] je následníkem protokolu XML-RPC, přejímá od něj použití XML jako prostředek kódování dat. Narozdíl od XML-RPC dokáže komunikovat také na SMTP protokolu, nejen na HTTP. Server SOAP umožňuje vylistovat služby a jejich parametry. To umožňuje širší použití v případech veřejně přístupných služeb. V takovém případě je zvýšená složitost implementace vyvážena možností definovat co služba poskytuje a jakým způsobem. V našem případě jsou služby pevně specifikované a dané, této možnosti protokolu bychom nevyužili. 17

SSH SSH [2] protokol není narozdíl od ostatních zde zmíněných protokolem pro vzdálené volání procedur, ale nástrojem pro připojování k vzdáleným počítačům a jejich ovládání. Tuto činnost lze do jisté míry zautomatizovat, protokol je sám o sobě šifrovaný a bezpečný a podporuje vzdálené spouštění skriptů. Shrnutí Ze zkoumaných protokolů nejlépe vyhovují protokoly XML-RPC, nebo SSH. Bylo by možné použít i protokol SOAP, kde ovšem nevyužijeme jeho schopnosti poskytování deficice rozhraní. Tím bychom z něj v podstatě udělali protokol XML-RPC. Proto ho v této práci nepoužijeme. Výhodou XML-RPC je krom jednoduchosti a oddělení požadavků od zpracování i mnoho referenčních knihoven které ji implementují[10]. Jeho nevýhodou je neexistující autentifikace a šifrování. SSH protokol má narozdíl od XML-RPC naopak implementovanou jak autentifikaci, tak šifrování, ale neposkytuje oddělení spouštění požadavků od jejich zpracování. Pro posouzení který z těchto dvou protokolů lépe vyhovuje našim požadavkům je potřeba udělat hlubší analýzu. 3.3.2 Podrobný rozbor metod XML-RPC a SSH XML-RPC XML-RPC je velmi rozšířený protokol pro který existuje mnoho dostupných implementací. Funguje na principu posílání XML zpráv pomocí HTTP protokolu. Protokol samotný nemá sám v sobě obsažené žádné autentifikační schéma, ani nedefinuje šifrování. Šifrování lze ovšem docílit o úroveň níže obalením protokolu HTTP do SSL tunel (HTTPS protokol). XML požadavky se posílají pomocí metody POST HTTP protokolu. Příklad poslání XML- RPC požadavku na vytvoření webu www u domény domain.tld na virtuálním serveru web s vlastníkem david : POST /WEBServer HTTP/1.1 Content-Length: 345 Connection: keep-alive X-SESSION-ID: fd422988f6c4f8f3f604e75cac3158c3 Content-Type: text/xml Host: server:1234 <?xml version="1.0" encoding="utf-8"?> <methodcall> <methodname>webserver.add_vhost</methodname> <params> <param> <value>web</value> </param> <param> <value>domain.tld</value> 18

</param> <param> <value>www</value> </param> <param> <value>david</value> </param> </params> </methodcall> Příklad odpovědi po úspěšném provedení požadavku: HTTP/1.1 200 OK Content-Length: 140 Connection: keep-alive Content-Type: text/xml <?xml version="1.0" encoding="utf-8"?> <methodresponse> <params> <param> <value><boolean>1</boolean></value> </param> </params> </methodresponse> V případě neúspěšného požadavku může protokol vrátit chybu včetně jejího popisu, u tohoto příkladu je vidět, že předávané hodnoty mohou být zapouzdřeny do struktur, viz klíčové slovo struct: HTTP/1.1 200 OK Content-Length: 426 Connection: keep-alive Content-Type: text/xml <?xml version="1.0"?> <methodresponse> <fault> <value> <struct> <member> <name>faultcode</name> <value><int>4</int></value> </member> <member> <name>faultstring</name> <value><string>too many parameters.</string></value> </member> </struct> 19

</value> </fault> </methodresponse> Hlavní aplikace bude naprogramována v jazyce C, je výhodné najít a použít už existující xml-rpc knihovnu, místo programování vlastní implementace. Pomocí internetového vyhledávače google byly nalezeni 2 kandidáti, xmlrpc-c [9] a libxr [8]. Knihovna xmlrpc-c je vznikla v roce 2000, prošla bouřlivým vývojem. který se postupně zpomaloval. Z požadovaných funkcí nepodporuje zabezpečený přenos dat pomocí SSL. Podle vyjádření v dokumentaci knihovny, v souboru SECURITY je to možné, ale postup nastavení není zdokumentován a je komplikovaný, cituji: You can solve this problem by using SSL under HTTP. This is possible with Xmlrpc-c, but it s nontrivial to set up and the Xmlrpc-c documentation doesn t tell you how. [1]. Knihovna zprostředkovává programátorovi rozhraní ve tvaru funkcí pro posílání xml-rpc požadavků. Pro její použití je nutné znát její datové typy. Příklad použití knihovny xmlrpc-c, klient posílající xml-rpc požadavek na vytvoření webové služby. /* Define variables for connection */ char * const serverurl = "http://localhost:1234/webserver"; char * const methodname = "add_vhost"; /* Initialize our error-handling environment. */ xmlrpc_env_init(&env); /* Start up our XML-RPC client library. */ xmlrpc_client_init2(&env, XMLRPC_CLIENT_NO_FLAGS, NAME, VERSION, NULL, 0); /* Make the remote procedure call */ result = xmlrpc_client_call(&env, serverurl, methodname, "(ssss)", (xmlrpc_value) "web", (xmlrpc_value) "domain.tld", (xmlrpc_value) "www", (xmlrpc_value) "david"); /* Get our result. */ xmlrpc_read_int(&env, result, &sum); printf("result is %d\n", sum); /* Free result. */ xmlrpc_decref(result); /* Clean up our error-handling environment. */ xmlrpc_env_clean(&env); /* Shutdown our XML-RPC client library. */ xmlrpc_client_cleanup(); Knihovna libxr byla zveřejněna v roce 2006, podporuje SSL šifrování a pro tvorbu rozhraní používá šablony. Při definici rozhraní se vytvoří soubor typu.xdl, ve kterém jsou 20

symbolicky nadefinovány požadavky s jejich parametry. Součástí knihovny je program, xdlcompiler, který vygeneruje z.xdl souboru zdrojové a hlavičkové soubory přímo do jazyka C. Jednotlivé požadavky potom mají tvar volání funkce s názvem požadavku, s parametry normálních C datových typů. Tento způsob definování interface umožňuje programátorovi soustředit se na tvorbu aplikace místo na propojování xml-rpc knihovny s jazykem C. Příklad definice interface pro metodu WEBServer.add vhost v souboru xdl: /* Used namespace*/ namespace WEB; /* Header of interface function */ boolean add_vhost(string vserver, string domain, string name, string owner) <% FILE *fpipe; char *command = malloc(256); if(command == NULL) exit(2); snprintf(command, 255, "/usr/local/bin/mail_add_domain.sh %s %s ", vserver, domain); printf("command = %s\n", command); char line[256]; /* Make call of external script, that do the work */ if(!(fpipe = (FILE*)popen(command,"r"))) { // If fpipe is NULL perror("problems with pipe"); return FALSE; } while(fgets(line, sizeof(line), fpipe)) { printf("%s", line); } pclose(fpipe); return TRUE; %> Po kompilaci programem xdl-compiler jsou vygenerovány soubory s definicí a deklarací funkce: WEBServer add vhost s parametry: gboolean WEBServer_add_vhost(xr_client_conn* _conn, const char* vserver, const char* domain, const char* name, const char* owner GError** _error) V klientském programu následně použijeme následující volání: GError* err = NULL; char* uri = "https://localhost:1234/webserver"; 21

/* Create object for performing client connections */ xr_client_conn* conn = xr_client_new(&err); /* connect to the servlet on the server specified by uri */ xr_client_open(conn, uri, &err); /* add a new web vhost */ WEBServer_add_vhost(conn, "www", "domain.tld", "www", "david", &err); Z obou knihoven byla jako vhodnější shledána knihovna libxr, která umí šifrování a díky xdl souborům je možné soustředit se na funkčnost interface, ne na tvorbu XML-RPC C rozhraní. Chybějící podpora autentifikace by musela být doprogramována. SSH SSH je software pro vzdálený přístup nahrazující dříve používaný telnet, nebo ftp. Narozdíl od nich je ssh protokol šifrovaný, ochrana přenášených dat je zajištěna symetrickým šifrováním. SSH se používá pro přístup na počítače, po přihlášení je možno pracovat na vzdáleném počítači jako na lokálním. Je možné také spouštět dávkové příkazy. SSH má zabudované různé autentifikační mechanismy, například je možné použít dvojici jméno/heslo, nebo autorizaci pomocí veřejného klíče. Pro naše účely je použití jména a hesla nevhodné, protože komplikuje automatizované provádění skriptů. Při každé úloze by bylo nutné zadávat heslo, aby se mohla provést. SSH podporuje i další způsob autentifikace. Autentifikaci pomocí veřejného klíče. Ta spočívá v použití speciálně vygenerovaného klíče, jehož privátní část zůstává na lokálním počítači a jeho veřejná se nahrává na všechny počítače, na které se chceme přihlašovat. V takovémto případě je po zadání uživatelského jména ze serveru poslaná náhodná hodnota zašifrována veřejným klíčem, tuto hodnotu dokáže rozšifrovat pouze příjemce s odpovídajícím privátním klíčem. Tu pak pošle zpět zašifrovanou veřejným klíčem počítače na který se připojuje. Tím dojde k potvrzení komunikace a navázání spojení. Pro zvýšení bezpečnosti může být privátní klíč chráněn takzvanou passphrase, jedná se o heslo kterým je zašifrován sám privátní klíč. Bez něj pak není možné jej použít. Protože bychom se opět dostali do situace, kdy bychom pro automatizované provádění skriptů museli zadávat heslo, byl tvůrci SSH vymyslen a implementován ssh-agent. Jedná se o utilitu, která převezme práci s privátním klíčem a poskytuje jeho výstupy dál démonu SSH. Při inicializaci agenta je potřeba mu zadat passphrase, on načte a dešifruje privátní klíč. Od této chvíle se SSH, vždy když potřebuje ověřit uživatele, ptá agenta. Tímto způsobem lze na serveru nastavit SSH tak, aby bylo nutné zadat passphrase jen jednou, případně jen jednou za určitý interval. Následně je pak možné se vzdáleně připojovat na počítače, kde je potřeba vykonávat požadavky. Při použití SSH by na straně serveru byl potřebný software (sada skriptů, nebo jeden program dělající vše podle parametrů), které by vykonávaly jednotlivé požadavky. K volání software by docházelo pomocí SSH přímo z příkazové řádky ovládacího stroje. Příklad volání požadavku: # Požadavek vytvoří na virtuálním serveru web adresářovou strukturu # a konfiguraci pro web www domény domain.tld # s vlastníkem david 22

:/$ ssh server.tld /usr/local/bin/web_add_vhost web www.domain.tld david Návratová hodnota požadavku je předána jako by bylo provedeno lokální spuštění skriptu z příkazové řádky, všechny výstupy a chyby jsou zpracovány běžným způsobem, výstup je poslán na standardní výstup a chyby na standardní chybový výstup. Shrnutí Vybrat mezi SSH a XML-RPC nebylo snadné, SSH poskytuje výbornou podporu pro autentifikaci, s pomocí XML-RPC lze dobře oddělit zadávání požadavků od jejich zpracování. Rozhodujícím faktorem se stala vlastnost XML-RPC oddělit jednotlivé fáze zpracování požadavku. Díky tomu je možné ze strany ovládací konzole vždy posílat stejné požadavky pro stejnou akci, například při vytvoření webu. Může nastat situace, kdy budeme mít stejnou službu realizovanou na jednom virtuálním serveru pomocí aplikace apache, na druhém pomocí aplikace lighttpd. V případě použití SSH by požadavek na vytvoření vypadal takto: # webserver apache :/$ ssh server.tld /usr/local/bin/web_add_vhost_apache web www.domain.tld david # webserver lighttpd :/$ ssh server.tld /usr/local/bin/web_add_vhost_lighttpd web www.domain.tld david V případě XML-RPC bude z klientské konzole vždy volán požadavek na vytvoření na vytvoření webu a až aplikace na hostu se rozhodne jakou metodu pro vytvoření zvolí. Tato situace je pro nás výhodnější, na různých platformách může být provádění požadavků řešeno různými způsoby. 23

Kapitola 4 Návrh a implementace Řešení bude implementováno jako klient/server aplikace. Serverová část (hostitelská aplikace) bude umístěna na jednotlivých fyzických serverech (hostech) a bude příjimat požadavky od klientské aplikace (ovládací konzole). Přijaté požadavky zpracují lokální skripty. Serverová část aplikace poběží jako démon na pozadí a bude z větší části zajištěna knihovnou libxr. Lokální skripty budou napsány pro interpret shellu Bash, skripty budou vracet výsledek požadavku serverové aplikaci a dále na klienta, kde bude zobrazen. Ovládací konzole bude naprogramována formou utility pro příkazový řádek. Aplikace zpřístupní rozhraní pro posílání požadavků na virtuální servery. Pro uchování informací o serverech a virtuálních serverech a službách na nich běžících bude použita databáze, která poběží na stejném počítači jako klientská aplikace. 4.1 Použité technologie V této kapitole se nachází stručný popis použitých technologií pro implementaci aplikace. 4.1.1 Linux-vserver Virtuální servery jsou postaveny na technologii linux-vserver[5]. Jedná se o virtualizaci na úrovni jádra. Každý aktivní virtuální server a všechn procesy v něm mají přiřazen kontext. Jádro operačního sytému se stará o to aby procesy z jednoho kontextu nemohly jakkoliv ovlivňovat procesy z ostatních kontextů, včetně sít ových rozhraní a namapování disků. Výjimkou je kontext 0, ve kterém jsou umístěny procesy hostitelského serveru a kontext 1, tzv. monitorovací. Ten vidí všechny procesy ze všech kontextů. Každý virtuální server je umístěn v samostatné adresářové struktuře. Při startu virtuálního serveru dochází k vytvoření kontextu a nastavení sít ové izolace. Pokračuje se provedením operace chroot do adresáře se soubory serveru a spuštění falešného procesu init, který se postará o boot virtuálního počítače. Na hostitelském systému lze provést změnu kontextu u běžícího procesu. Tímto způsobem je možné spustit program z hostitelského serveru na virtuálním. Této vlastnosti můžeme výhodně použít. Na hostitelském serveru vytvoříme sadu skriptů, které budou provádět požadavky. Při příchozím požadavku provedeme přepnutí do kontextu virtuálního serveru a v něm požadavek provedeme. Sada skriptů bude pouze jediná a to na hostitelském serveru. Změny se budou dít uvnitř virtuálních serverů. 24

4.1.2 Jazyk C Historie jazyka C sahá až do 70. let 20. století[3]. Jazyk C je nízkoúrovňový jazyk, v dnešní době využívaný převážně k programování nízkoúrovňových aplikací, ovladačů a jader operačního systému. Jazyk je neustále vyvíjen, jeho nejnovější aktuální verze je norma C99 z roku 1999. Díky své nízkoúrovnosti jsou jeho nároky při stejném výsledném produktu menší při vyšší rychlosti výsledného kódu. V serverové i klientské aplikaci použijeme knihovnu libxr, která bude obsluhovat XML-RPC část kódu. Serverová aplikace musí přistupovat do jednotlivých vserverů, z toho důvodu poběží pod uživatelem root. 4.1.3 Mysql Mysql je databázový server používaný hlavně pro svou rychlost a rozšířenost. V našem případě je také už používán na virtuálních serverech pro ukládání dat uživatelů. Množina jeho funkcí není tak rozsáhlá jako například u jiných databázových systémů, ale pro naše účely je dostatečná. 4.1.4 Bash shell Na serverové straně aplikace bude umístěna sada skriptů, které budou vykonávat požadavky serverové aplikace. Tyto skripty jsou psány pro linuxový interpret Bash, ale měly by být použitelné i na dalších shell interpretech. Skripty budou psány odděleně od aplikace. Tento postup byl zvolen, protože nám umožňuje dělat jednoduše změny výkonné části aplikace v případě nutnosti jejího přízpusobení. Modifikované shell skripty se dají okamžitě použít, opravy chyb a přidávání funkčnosti je snadné a rychlé. 4.2 Návrh aplikace V této kapitole jsou rozebrány postupy řešení problémů vzniklých použitím zvolených technologií. Dále je ukázán způsob komunikace při zaslání požadavku a získání odpovědi. 4.2.1 Autentifikace a šifrování Protože protokol XML-RPC nemá vestavěnou autentifikační vrstvu, bude třeba ji doprogramovat. Autentifikace bude implementována ověřením uživatelského jména a hesla při navázání spojení ovládací konzole s host aplikací. Jméno a heslo bude na obou stranách uloženo v konfiguračních souborech s nastavenými právy pro čtení pouze pro uživatele root. V rámci této práce nebudou implementovány mechanismy pro oddělení uživatelských práv, každý autentifikovaný uživatel má práva na zasílání všech požadavků. Autentifikace je platná pouze v rámci aktivního spojení, při vytvoření nového spojení je nutné se opětovně autentifikovat Veškerý datový tok mezi klientem a serverem je šifrován protokolem SSL. 4.2.2 Cesta požadavku Ovládací konzole je zavolána s konkrétním požadavkem. Provede se kontrola vstupních dat. Pokud nevyhovují, vypíše se nápověda k požadavku. V opačném případě se pokračuje, část požadavku musí být jméno virtuálního serveru, na kterém se má zpracovat. S pomocí dat z mysql databáze je nalezen příslušný host a jeho IP adresa. Proběhne navázání spojení a autentifikace. Poté dojde k zaslání požadavku a čekání na odpověd. Host aplikace přepošle 25