}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Aplikace pro správu virtuálních webových serveru˚ na FSS MU ˇ B AKALÁ RSKÁ PRÁCE
Jan Št’astný
Brno, jaro 2012
Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Vedoucí práce: RNDr. Radek Ošlejšek, Ph.D. ii
Podˇekování Dˇekuji vedoucímu práce RNDr. Radkovi Ošlejškovi, Ph.D. za metodickou, pedagogickou a odbornou pomoc a další cenné rady pˇri zpracování mé bakaláˇrské práce.
iii
Shrnutí Cílem práce bylo seznámit se s procesy a postupy, které jsou spojené se správou virtuálních webových serveru˚ na FSS MU. Na základˇe tˇechto poznatku˚ byla navržena a implementována aplikace, která podporuje, zjednodušuje a cˇ ásteˇcnˇe automatizuje vytváˇrení webu˚ na daném serveru.
iv
Klíˇcová slova virtuální webový server, webová aplikace, databáze, analýza, implementace
v
Obsah 1
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Pˇrehled pojmu˚ . . . . . . . . . . . . . . . . . . . 2 Existující infrastruktura . . . . . . . . . . . . . . . . 2.1 Správa virtuálních webových serveru˚ . . . . . 2.1.1 Systémová databáze . . . . . . . . . . . 2.1.2 Databáze virtuálních serveru˚ . . . . . . 3 Analýza požadavku˚ . . . . . . . . . . . . . . . . . . 3.1 Vytvoˇrení virtuálního serveru . . . . . . . . . . 3.1.1 Vytvoˇrení doménového názvu . . . . . 3.1.2 Vytvoˇrení databáze . . . . . . . . . . . . 3.1.3 Zpˇrístupnˇení webového prostoru . . . . 3.2 Úprava virtuálního serveru . . . . . . . . . . . 3.2.1 Pˇridání uživatele mezi správce . . . . . 3.2.2 Odebrání uživatele jako správce . . . . 3.3 Odstranˇení virtuálního serveru . . . . . . . . . 3.3.1 Odebrání doménového názvu . . . . . 3.3.2 Zálohování a odstranˇení databáze . . . 3.3.3 Odstranˇení webového prostoru . . . . . 4 Návrh a implementace . . . . . . . . . . . . . . . . . 4.1 Pokrytí funkcionality . . . . . . . . . . . . . . . 4.1.1 Nezautomatizované procedury . . . . . 4.2 Prezentaˇcní cˇ ást aplikace . . . . . . . . . . . . . 4.2.1 PHP tˇrída Wizard . . . . . . . . . . . . . 4.2.2 jQuery tˇrída Wizard . . . . . . . . . . . 4.3 Použité knihovny . . . . . . . . . . . . . . . . . 4.3.1 jQuery . . . . . . . . . . . . . . . . . . . 4.3.2 jsonwrapper . . . . . . . . . . . . . . . . 4.4 Návrh uživatelského prostˇredí . . . . . . . . . 4.5 Chování aplikace . . . . . . . . . . . . . . . . . 4.5.1 Logování . . . . . . . . . . . . . . . . . . 4.5.2 Reakce na chybu . . . . . . . . . . . . . 4.5.3 Zprávy zasílané uživatelum ˚ . . . . . . . 4.5.4 Zabezpeˇcení aplikace . . . . . . . . . . . 4.5.5 Upozornˇení pˇred významným krokem 4.5.6 Ukonˇcení pruvodce ˚ . . . . . . . . . . . . 4.6 Testování a provoz . . . . . . . . . . . . . . . . 5 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . A Použité knihovny . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 2 4 5 5 6 7 8 8 9 9 12 13 13 14 14 14 15 17 17 18 19 19 19 20 20 22 22 23 23 24 25 25 25 26 26 27 28 29
vi
Kapitola 1
Úvod Server Fakulty sociálních studií Masarykovy univerzity (FSS MU) spravuje velké množství webu. ˚ Jedná se napˇríklad o weby na podporu výuky, osobní stránky studentu˚ nebo elektronické prezentace studentských projektu. ˚ Každý takový web je reprezentován zvláštním virtuálním serverem a musí mít alesponˇ jednoho správce. Správci jednotlivých virtuálních serveru˚ mají pˇrístup k odpovídajícím databázím a webovým prostorum. ˚ Adresa oznaˇcující jednotlivé weby je pak ve tvaru nazev.fss.muni.cz.1 Požadavek na nový web znamená pro správce serveru FSS MU ruˇcní úpravu konfiguraˇcních souboru˚ webového a DNS (Domain Name Service)2 serveru spolu s vytvoˇrením databáze a samozˇrejmˇe také komunikaci s žadatelem o webový prostor. Vlastní proces konfigurace virtuálního serveru není pˇrísnˇe sekvenˇcní, ale jisté posloupnosti kroku˚ je tˇreba dodržet. Zárovenˇ skýtá možnost pouze cˇ ásteˇcné automatizace, protože nˇekteré kroky není bezpeˇcné nebo technicky možné provést v rámci aplikace, která je pˇredmˇetem této práce. Proces úpravy nebo úplného odstranˇení virtuálního serveru je pro webového administrátora obdobnˇe nároˇcný jako jeho vlastní vytvoˇrení, pˇribývá ovšem nutnost zálohy dat. Cílem této práce bylo vytvoˇrit webovou aplikaci, která by celý proces správy virtuálních webových serveru˚ na FSS MU zautomatizovala a zjednodušovala. Jedním z hlavních požadavku˚ bylo webové rozhraní. Jeho souˇcástí mˇel být pruvodce, ˚ který mˇel správce instruovat, jaké kroky je tˇreba uˇcinit pro dokonˇcení úlohy. Pokud operace bylo možné provést v rámci aplikace automaticky, správce mˇel být seznámen s jejich výsledkem. Systém mˇel pˇredat podrobné informace sloužící ke správˇe prezentace také žadateli o webový prostor. Duležitou ˚ cˇ ástí systému byla také možnost konfigurace systému právˇe pˇres webové rozhraní. Text práce je strukturován s ohledem na sestavené modely procesu, ˚ které byly pravidelnˇe konzultovány se správcem serveru FSS MU. Použitou notací je BPMN (Bussiness Process Modeling Notation), jež je vedená skupinou OMG (Object Management Group) jako veˇrejný standard. Komplexní informace o BPMN shrnul jeden z vývojáˇru˚ standardu Bruce Silver v [4]. Aplikace byla vyvíjena pro prostˇredí serveru FSS MU. Provozovaným webovým serverem je Apache verze 2. Databázová platforma je zde MySQL (databázový systém založený na dotazovacím jazyku SQL – Structured Query Language). Systém byl podle požadavku˚ implementován objektovˇe v jazyce PHP verze 5. Duraz ˚ byl bˇehem programování kladen na 1. 2.
Kde nazev odpovídá názvu uvedeného pˇri konfiguraci virtuálního serveru. Služba pro pˇreklad doménových názvu˚ na IP (Internet Protocol) adresy.
1
ˇ ˚ 1.1. P REHLED POJM U uživatelsky pˇrívˇetivé prostˇredí využívající moderních technologií a následující nejnovˇejší vývojové smˇery v oblasti návrhu webových aplikací jako jsou CSS3 (Cascading Style Sheets verze 3), XML (eXtensible Markup Language), AJAX (Asynchronous JavaScript and XML), JavaScript. Aplikace je nainstalována na unixovém systému s webovým serverem Apache2. Správa databázových dat je možná pˇres terminálové spojení nebo prostˇrednictvím webové aplikace phpMyAdmin3 . Pˇrístup k webovému prostoru je nadále rˇ ešen pouze terminálovým spojením, žádné grafické prostˇredí není pˇredmˇetem této práce.
1.1
Pˇrehled pojmu˚
Webadmin Aplikace pro správu virtuálních webových serveru˚ na FSS MU, která je pˇredmˇetem této práce, je dále v textu cˇ asto oznaˇcována jako aplikace Webadmin. Virtuální server Virtuální server (nebo také virtuální hostitel z anglického virtual host) podle [3] oznaˇcuje zpusob ˚ provozu více než jedné webové stránky na jediném zaˇrízení. Virtuální hostitelé mohou být na bázi IP adresy4 (IP-based), kdy každá webová stránka má vlastní IP adresu, nebo na bázi názvu (name-based), kdy na jedné IP adrese bˇeží nˇekolik virtuálních hostitelu. ˚ V pˇrípadˇe IP-based virtuálních serveru˚ je správný hostitel urˇcen na základˇe IP adresy daného spojení. To znamená, že každý hostitel musí mít pˇridˇelenu unikátní IP adresu. Pokud server využívá name-based virtuálních hostitelu, ˚ pak spoléhá na klienta, který 5 mu oznámí název hostitele jako souˇcást HTTP hlaviˇcky. Tímto zpusobem ˚ muže ˚ mnoho ruzných ˚ hostitelu˚ sdílet jednu IP adresu. Na serveru FSS MU se využívá pro vytváˇrení virtuálních webových serveru˚ technika na bázi názvu˚ (name-based virtuální hostitelé), aplikace Webadmin s tím poˇcítá, pokrývá pouze tento zpusob ˚ provozu virtuálních hostitelu. ˚ BPMN BPMN neboli Business Process Modeling Notation je notace pro zachycování podnikových procesu. ˚ Jejím prostˇrednictvím je možné modelovat grafickými prvky situace, které v podniku nastávají. Notace poskytuje prostˇredky pro popis organizace se zamˇerˇ ením na rozdˇelení zodpovˇedností, její strukturu a komunikaˇcní protokoly mezi jejími cˇ ástmi. Specifikace notace neobsahuje žádný návod, jak modely z jednotlivých grafických prvku˚ sestavovat. Absenci metodiky v rámci specifikace BPMN rˇ eší B. Silver v rámci své knihy [4]. 3. 4. 5.
Nástroj psaný v PHP sloužící k správˇe MySQL databází pˇres webové rozhraní. Jednoznaˇcný cˇ íselný identifikátor zaˇrízení v prostˇredí poˇcítaˇcové sítˇe. (Internet Protocol address) Hypertext Transfer Protocol.
2
ˇ ˚ 1.1. P REHLED POJM U Popisuje základní aspekty modelování pomocí této notace. Cílem této publikace je sdˇelit cˇ tenáˇri, jak sestavovat modely BPMN tak, aby byly jednoznaˇcné, pˇresné a srozumitelné. V rámci této práce byla notace využita pro modelování procesu˚ spojených se správou virtuálních webových serveru˚ na FSS MU. Výsledné modely jsou souˇcástí analýzy požadavku˚ v kapitole 3. UML UML neboli Unified Modeling Language je podle [10] univerzální jazyk pro vizuální modelování systému. ˚ Neobsahuje žádnou metodiku, poskytuje pouze grafické prostˇredky k sestavování modelu. ˚ V rámci práce byl využit Diagram pˇrípadu˚ užití (Use case diagram) ke stanovení hranic systému ve fázi shromažd’ování požadavku˚ na systém. Dále Diagram tˇríd (Class diagram) k vytvoˇrení datového modelu systémové databáze. Pro popis prostˇredí, ve kterém byla aplikace nasazena je v práci využit diagram nasazení (Deployment diagram).
3
Kapitola 2
Existující infrastruktura
Obrázek 2.1: Diagram nasazení Popis infrastruktury serveru˚ FSS MU je velmi duležitý ˚ kvuli ˚ pochopení a zachycení procesu, ˚ které se zde ve spojitosti se správou virtuálních webových serveru˚ odehrávají. Nastavení jednotlivých komponent a vztahy mezi nimi významnˇe ovlivnují ˇ oblast pokrytou aplikací, která je pˇredmˇetem této práce. Infrastrukturu popisuje 2.1. Na adrese fsslvt.fss.muni.cz se nachází hlavní server. Na této stanici má každý student a zamˇestnanec fakulty zˇrízený úˇcet pˇrístupný pod urˇcitým uživatelským jménem a tajným heslem. Tyto informace jsou uchovávány na databázovém serveru MySQL verze 5.0.95, jehož adresa je mysql.fss.muni.cz. Fyzické umístˇení databázového serveru je shodné s webovým serverem. Adresa webového serveru je web.fss.muni.cz. Nachází se zde webové prostory a konfiguraˇcní soubory všech virtuálních webových serveru˚ zˇrízených na fakultˇe. Bˇežící platformou je server Apache verze 2. Z hlediska aplikace, která je pˇredmˇetem této práce, je duležitá ˚ informace o podpoˇre skriptování na stranˇe serveru. K dispozici je verze PHP 5.1.6. Webový a databázový server, které jsou fyzicky pˇritomné na stejném zaˇrízení, jsou dále zrcadleny na odlišný stroj. Jejich replikace probíhá z duvodu ˚ zálohování dat, tím dochází ke zvýšení spolehlivosti serveru, kdy v pˇrípadˇe výpadku primárního serveru dojde k pˇrepnutí provozu na server zrcadlový. Pro úspˇešné zpracování adresy požadavku a pˇredání rˇ ízení webovému serveru, který na základˇe tvaru doménového názvu poskytne obsah urˇcitého webového prostoru, je velmi duležité ˚ nastavení DNS serveru. Ten se nachází na serveru hlavním, který, jak již bylo zmínˇeno, bˇeží na adrese fsslvt.fss.muni.cz. Konfiguraˇcní informace pro doménu fss.muni.cz se 4
˚ 2.1. SPRÁVA VIRTUÁLNÍCH WEBOVÝCH SERVER U nachází ve stejnojmenném souboru umístˇeném v adresáˇri /var/named/master/ na hlavním serveru.
2.1
Správa virtuálních webových serveru˚
V této kapitole jsou rozebrány vztahy, které jsou na pozadí procesu˚ spojených se správou virtuálních webových serveru. ˚ 2.1.1 Systémová databáze Server MySQL obsahuje rˇ adu databází. Kromˇe databází jednotlivých webu˚ i nˇekolik systémových databází. Významnou z hlediska této práce je databáze sysauth, která uchovává pˇrístupové údaje, tj. jméno, heslo, skupiny. Obsah této databáze je mapován na systémovou úroven. ˇ Tabulka User obsahuje záznamy o všech uživatelích na serveru. Jednotlivé položky jsou mapovány z hlavního serveru fsslvt.fss.muni.cz. Položky user_name a realname obsahují informace o uživateli. První z nich uvádí uživatelské jméno, které je unikátní v rámci systému. Pod tímto jménem se uživatel pˇrihlašuje na server. Uživatelské jméno také urˇcuje podobu adresy elektronické pošty uživatelu. ˚ Celé jméno uživatele je uloženo v poli realname. Položky shell a status ovlivnují ˇ uživatelovo právo pˇrístupu na webový server (3.1.3). Tabulka Groups shromažd’uje záznamy o všech systémových skupinách na serveru. Její pole gid musí obsahovat hodnotu shodnou s identifikátorem rˇ ádku tabulky. Další významnou položkou je group_name, která uvádí název skupiny. Tabulka User_group je vazební tabulkou zaˇrazující dané uživatele do skupin. Spojení je uskuteˇcnováno ˇ na základˇe identifikátoru˚ obou entit. Z duvod ˚ u˚ mapování databáze na systémovou úrovenˇ uživatelských úˇctu˚ je nutné u každého záznamu v tabulce uvést také název skupiny v poli group_name. Obsah výše uvedených tabulek urˇcuje duležitá ˚ nastavení vztahující se k problematice konfigurace virtuálních webových serveru, ˚ která jsou rozebrána dále v textu.
Obrázek 2.2: Datový model
5
˚ 2.1. SPRÁVA VIRTUÁLNÍCH WEBOVÝCH SERVER U 2.1.2 Databáze virtuálních serveru˚ Ke každému virtuálnímu webovému serveru je vytváˇrena zvláštní databáze. Databázi spolu s virtuálním serverem váže shoda doménového názvu s názvem databáze. Pro pˇrístup k databázi je vytváˇren uživatel jehož jméno je shodné s názvem databáze, heslo je nastavováno náhodné. Napˇríklad pro virtuální webový server s doménovým názvem nova_domena je vytvoˇrena databáze s názvem nova_domena a uživatel se jménem nova_domena. Pro výše uvedené akce poskytuje databázový server MySQL podporu v podobˇe pˇríkazu˚ pro definici dat (Data Definition Statements) a správu databáze (Database Administration Statements). Pˇri sestavování databázových pˇríkazu˚ uvedených v této práci bylo cˇ erpáno z [8]. Puvodnˇ ˚ e byly tyto operace na serveru provádˇeny pomocí nástroje phpMyAdmin1 , který nabízí webové rozhraní pro práci s databází.
1.
Pro více informací navštivte
.
6
Kapitola 3
Analýza požadavku˚ Prvním krokem v cestˇe k vytvoˇrení aplikace byla analýza požadavku˚ na pˇripravovaný systém. V jejím prubˇ ˚ ehu byly stanoveny hranice systému urˇcující funkcionalitu pokrytou aplikací, viz obrázek 3.1. Jediným aktérem je administrátor serveru oznaˇcený jako Admin. Pˇrípady užití Vytvoˇrení virtuálního serveru, Úprava virtuálního serveru a Odstranˇení virtuálního serveru znázornují ˇ akce, které aktér Admin muže ˚ použitím systému Webadmin provést. Zárovenˇ jsou to všechny operace, které jsou se správou virtuálních webových serveru˚ na FSS MU spojené. Jednotlivé pˇrípady užití v rámci systému Webadmin jsou v souladu s požadavkem v zadání práce namodelovány pomocí notace BPMN. Výsledné procesní modely tvoˇrí osnovu dalšího textu, je podle nich tato kapitola strukturována a jejich podrobnosti jsou vysvˇetleny v jejích oddílech. Modely jsou výsledkem rˇ ady setkání s osobou administrátora serveru na FSS MU.
Obrázek 3.1: Webadmin
7
ˇ 3.1. VYTVO RENÍ VIRTUÁLNÍHO SERVERU
3.1
Vytvoˇrení virtuálního serveru
Správce webového serveru na FSS MU po pˇrijetí požadavku na vytvoˇrení nového virtuálního serveru musí provést rˇ adu operací, z nichž nˇekteré musí nastat v pˇrísném poˇradí, jiné mohou být provedeny i paralelnˇe. Omezení na poˇradí kroku˚ jsou zmínˇena dále v oddíle. Schéma procesu je znázornˇeno na obrázku 3.2. Pro úspˇešné vytvoˇrení nového virtuálního webového serveru s urˇcitým doménovým názvem je nutné nastavit DNS server tak, aby daný název rozpoznal, vytvoˇrit databázi a uživatele pro pˇrístup k ní, vytvoˇrit a zpˇrístupnit webový prostor všem správcum ˚ webu. Jednotlivé úkony jsou rozebrány v odpovídajících oddílech níže.
Obrázek 3.2: Vytvoˇrení virtuálního serveru
3.1.1 Vytvoˇrení doménového názvu Aby bylo doménové jméno rˇ ádnˇe rozeznáno, je nutné upravit nastavení DNS serveru. Do jeho konfiguraˇcního souboru se pˇridává záznam, který v reakci na pˇrijatý požadavek kontaktuje adresu webového serveru. Rozšíˇrením konfiguraˇcního souboru na DNS serveru o rˇ ádky name IN CNAME web www.name IN CNAME web
nebo name.fss.muni.cz. IN CNAME web.fss.muni.cz. www.name.fss.muni.cz IN CNAME web.fss.muni.cz.
8
ˇ 3.1. VYTVO RENÍ VIRTUÁLNÍHO SERVERU se oznamuje, že doménový název name má být zpracován webovým serverem, který je na adrese web.fss.muni.cz. Druhý rˇ ádek nastavení je pˇrítomen proto, aby požadavky na name.fss.muni.cz souˇcasnˇe s požadavky na www.name.fss.muni.cz byly zpracovány shodnˇe. Poznámka Pˇredchozí dva konfiguraˇcní záznamy jsou ekvivalentní. V prvním pˇrípadˇe bude k doménovému názvu name pˇriˇrazena cˇ ást fss.muni.cz automaticky. Pro doménový název web, oznaˇcující umístˇení webového serveru, platí výše zmínˇené taktéž. Aby bylo toto chování potlaˇceno, je nutné doménový název ukonˇcit teˇckou, jak je ukázáno v pˇrípadˇe druhém. 3.1.2 Vytvoˇrení databáze K virtuálnímu webovému serveru je vytvoˇrena databáze shodného názvu s doménovým jménem. Pro pˇrístup do databáze je vytvoˇren také uživatel se stejným jménem. Pro vytváˇrený virtuální server s doménovým názvem novy_web je podle pˇredchozích pravidel vytvoˇrena stejnojmenná databáze. Dále je zˇrizován uživatel, je mu nastaveno právo užívání pro všechny databáze a pˇriˇrazeno heslo tajne_heslo. Ve vztahu k právˇe vytvoˇrené databázi má nastavena všechna práva specifikovaná v dokumentaci [8] kromˇe možnosti dalšího pˇridˇelování práv. Pˇríklad 3.1.1 uvádí pˇríkazy, jimiž se jednotlivé akce provádˇejí, v porˇ adí odpovídajícím tomuto odstavci. CREATE DATABASE novy_web; GRANT USAGE ON *.* TO ’novy_web’@’%’ IDENTIFIED BY PASSWORD ’tajne_heslo’; GRANT ALL PRIVILEGES ON ’novy_web’.* TO ’novy_web’@’%’;
Pˇríklad 3.1.1: Vytvoˇrení databáze K vytvoˇrení databáze je nutné, aby uživatel, pod kterým je správce pˇrihlášen, mˇel právo CREATE pro danou databázi. Pro vytvoˇrení uživatele musí mít právo GRANT_OPTION a všechna právˇe udˇelovaná práva. 3.1.3 Zpˇrístupnˇení webového prostoru Tento proces, podrobnˇeji rozpracován na obrázku 3.3, tvoˇrí rˇ ada kroku, ˚ jejichž cílem je vytvoˇrení adresáˇre, nastavení pˇrístupových práv k nˇemu a editace konfigurace webového serveru, aby byl tento adresáˇr považován za webový prostor virtuálního serveru. Jak schéma znázornuje, ˇ není možné jednotlivé úkony provést v libovolném poˇradí. V prubˇ ˚ ehu procesu je nutné dodržet nˇekolik omezení, jež jsou uvedena dále v textu. Povolení pˇrístupu na webový server Jestliže má uživatel být správcem virtuálního serveru, je bezpodmíneˇcnˇe nutné, aby mohl pˇristupovat na webový server. Na webový server mají pˇrístup pouze uživatelé, kteˇrí jsou 9
ˇ 3.1. VYTVO RENÍ VIRTUÁLNÍHO SERVERU
Obrázek 3.3: Zpˇrístupnˇení webového prostoru správci alesponˇ jednoho z virtuálních serveru, ˚ které se zde nacházejí. Implicitnˇe uživatel právo pˇrístupu na webový server nemá. Pokud uživatel, který je zvolený jako správce virtuálního serveru, dosud právo pˇrihlášení na webový server nemˇel, je mu pˇridˇeleno. Povolení pˇrístupu je provedeno úpravou uživatelova záznamu v tabulce User v systémové databázi, jejíž popis je uveden na 2.2. Rozhodujícími hodnotami z pohledu zmínˇeného nastavení jsou položky status a shell. V pˇrípadˇe zakázaného pˇrístupu: •
pole status obsahuje hodnotu "N",
•
pole shell obsahuje hodnotu "/bin/false".
Pokud je pˇrístup povolen: •
pole status obsahuje hodnotu "A",
•
pole shell obsahuje hodnotu "/bin/bash".
Vytvoˇrení skupiny a Pˇridání uživatele do skupiny Ke každému virtuálnímu serveru je zˇrizována skupina se jménem shodným s jeho doménovým názvem. Vytvoˇrení skupiny je duležité ˚ kvuli ˚ shromáždˇení všech správcu˚ virtuálního serveru. Skupiny jsou uloženy v systémové databázi, viz 2.1.1. Každý správce virtuálního serveru musí být cˇ lenem skupiny, která mu odpovídá. Pˇríslušnost uživatele ke skupinˇe je opˇet vyjádˇrena vztahy zachycenými systémovou databází jako v pˇredchozím pˇrípadˇe. 10
ˇ 3.1. VYTVO RENÍ VIRTUÁLNÍHO SERVERU Vytvoˇrení adresáˇre Webový prostor virtuálního serveru pˇredstavuje adresáˇr vytvoˇrený v umístˇení, které je urcˇ eno konfigurací serveru Apache, respektive uvedeno v konfiguraˇcním souboru odpovídajícím danému virtuálnímu serveru. Adresáˇr je vytváˇren na úrovni souborového systému webového serveru. Nastavení pˇrístupových práv Nastavením pˇrístupu k webovému prostoru, který je pˇredstavován adresáˇrem na webovém serveru, je správcum ˚ virtuálního serveru umožnˇena úprava jeho obsahu. Pˇrístupová práva k adresáˇri na webovém serveru se nastaví na hodnotu 2775. Dále se nastaví uživatel a skupina adresáˇre. Jelikož jsou všichni správci shromáždˇeni v jedné skupinˇe, tak je tímto zpusobem ˚ možné upravit pˇrístup k adresáˇri. Požadavkem nutným pro provedení zmˇeny uživatele a skupiny adresáˇre je existence adresáˇre, skupiny a pˇrítomnost alesponˇ jednoho správce virtuálního serveru. Podmínka výbˇeru alesponˇ jednoho správce je podložena nutností upˇresnˇení uživatele u daného adresáˇre. Konfigurace webového serveru Vlastní nastavení virtuálního serveru, tedy mapování požadavku na pˇríslušný virtuální server se provádí vytvoˇrením zvláštního konfiguraˇcního souboru DOM_NAZEV.conf 1 umístˇeného v adresáˇri, který je uveden v konfiguraci serveru Apache. Formát konfiguraˇcního souboru: ServerName DOM_NAZEV.fss.muni.cz ServerAlias www.DOM_NAZEV.fss.muni.cz DOM_NAZEV ServerAdmin [email protected] DocumentRoot /var/www/virthosts/DOM_NAZEV ErrorLog logs/DOM_NAZEV.fss.muni.cz-error_log CustomLog logs/DOM_NAZEV.fss.muni.cz-access_log common ServerName DOM_NAZEV.fss.muni.cz ServerAlias www.DOM_NAZEV.fss.muni.cz DOM_NAZEV ServerAdmin [email protected] DocumentRoot /var/www/virthosts/DOM_NAZEV ErrorLog logs/DOM_NAZEV.fss.muni.cz-error_log CustomLog logs/DOM_NAZEV.fss.muni.cz-access_log common
Pro každý virtuální webový server musí existovat blok s direktivou , která definuje duležitá ˚ nastavení pro daný virtuální server. Úvodní identifikátor bloku obsahuje 1.
Kde DOM_NAZEV odpovídá doménovému názvu virtuálního serveru, který je pˇredmˇetem konfigurace.
11
3.2. ÚPRAVA VIRTUÁLNÍHO SERVERU také specifikaci IP adresy a portu, které jsou na serveru vyhrazeny pro obsluhu virtuálních serveru. ˚ Ve vymezeném oddíle jsou potom definovány jednotlivé položky konfigurace. Obsah parametru ServerName urˇcuje doménový název, který oznaˇcuje daný virtuální webový server. Doménový název uvedený na rˇ ádku ServerAlias je tzv. alias, zástupný název virtuálního webového serveru. Umožnuje ˇ k jedné webové prezentaci pˇristupovat pod více ruznými ˚ názvy. ServerAdmin obsahuje emailovou adresu administrátora serveru. Položka DocumentRoot oznaˇcuje umístˇení adresáˇre, který pˇredstavuje webový prostor virtuálního serveru. ErrorLog a CustomLog jsou soubory pro potˇreby logování. Informace o konfiguraci serveru cˇ erpány z dokumentace [3] a publikace [2]. Webový server se inicializuje pˇri vlastním spuštˇení. Aby došlo k aplikování zmˇen provedených až po startu systému, je nutné server restartovat. Pˇríkazem service httpd reload; se operace provede. Pro úspˇešné restartování je ovšem nutná existence adresáˇre náležícího danému virtuálnímu serveru na webovém serveru. Proto restart Apache musí následovat až po vytvoˇrení adresáˇre.
3.2
Úprava virtuálního serveru
Obrázek 3.4: Editace virtuálního serveru Úprava virtuálního webového serveru se z pohledu aplikace Webadmin odehrává pouze na webovém serveru. Žádné úpravy na databázovém ani na DNS serveru nejsou zmínˇenou aplikací zahrnuty. Bˇehem procesu muže ˚ dojít k pˇridání uživatele k již definovaným správcum, ˚ nebo odebrání uživatele z množiny správcu. ˚ Uvedené situace jsou zachyceny na obrázku 3.4 a rozebrány dále v textu. 12
3.2. ÚPRAVA VIRTUÁLNÍHO SERVERU 3.2.1 Pˇridání uživatele mezi správce Stejnˇe jako v pˇrípadˇe pˇridávání správcu˚ k novému virtuálnímu webovému serveru, tak i pˇri jeho úpravˇe je tˇreba zajistit, aby mˇel uživatel pˇridávaný do množiny správcu˚ pˇrístup na webový server. Následnˇe je možné jej zaˇradit do skupiny, která odpovídá danému virtuálnímu serveru. Proces je popsán na obrázku 3.5. Podrobnosti o zmínˇených opatˇreních jsou uvedeny již v oddíle 3.1.3 v jeho pododdílech „Povolení pˇrístupu na webový server“ a „Vytvoˇrení skupiny a Pˇridání uživatele do skupiny“.
Obrázek 3.5: Pˇridání uživatele mezi správce
3.2.2 Odebrání uživatele jako správce Uživatel muže ˚ také být správcovských privilegií zbaven. Bˇehem operace je ovšem nutné dodržet omezení, která rozhodují, zda je akce pˇrípustná. Proces je znázornˇen na obr. 3.6. Prvním omezením v prubˇ ˚ ehu odebírání uživatele jako správce je ovˇerˇ ování skuteˇcnosti, zda je uživatel jediným správcem virtuálního serveru. Pokud tomu tak je, není možné uživatele správcovství zbavit. Pˇríˇcinou tohoto omezení je nutnost nastavení uživatele adresáˇre, který pˇredstavuje webový prostor domény. S tím souvisí další z významných bodu˚ procesu. Tím je zjištˇení, zda je uživatel, který má být odstranˇen ze skupiny správcu, ˚ vlastníkem adresáˇre na webovém serveru. Vlastnictví adresáˇre významnˇe ovlivnuje ˇ možnost úpravy webového prostoru. Pokud je odebíraný správce nastaven jako vlastník adresáˇre, je nutné nastavit nˇekterého ze zbývajících jako uživatele pro daný adresáˇr. Pokud byly veškeré podmínky zmínˇené v pˇredchozích bodech splnˇeny, je možné odstranit uživatele ze skupiny správcu. ˚ Ze skupiny je uživatel odstranˇen úpravou obsahu systémové databáze popsané v oddíle 2.1.1. Tímto zaniká právo na úpravu adresáˇre náležícího danému virtuálnímu serveru na webovém serveru. Pokud pˇredmˇetný uživatel po odebrání práva na spravování daného virtuálního serveru již není správcem žádného dalšího, je nutné mu odebrat pˇrístup na webový server. Operace je provádˇena podobnˇe jako v pˇrípadˇe povolení pˇrístupu na webový server, viz 3.1.3. 13
ˇ 3.3. ODSTRAN ENÍ VIRTUÁLNÍHO SERVERU
Obrázek 3.6: Odebrání uživatele jako správce
3.3
Odstranˇení virtuálního serveru
Posledním ze zachycovaných scénáˇru˚ je proces odebrání virtuálního serveru. V jeho pru˚ bˇehu je nutné navíc zajistit bezchybné a úplné zálohování jak databáze, tak i webového prostoru náležícího k odstranovanému ˇ virtálnímu webovému serveru. Zálohovaná data má k dispozici webmaster, který je na vyžádání poskytuje zájemcum ˚ z rˇ ad bývalých správcu˚ virtuálního serveru. Celý plán cˇ inností nutných k úspˇešnému dokonˇcení scénáˇre je popsán na obrázku 3.7. 3.3.1 Odebrání doménového názvu Pˇri rušení virtuálního serveru je nutné, aby byl odstranˇen jemu odpovídající záznam z konfigurace DNS serveru. Jedná se o shodný záznam, který byl v procesu vytváˇrení virtuálního serveru do konfiguraˇcního souboru vložen, viz 3.1.1. Odstranˇením daného doménového jména se dosáhne toho, že požadavek na specifickou adresu oznaˇcující konkrétní virtuální server nebude pˇredán webovému serveru a DNS server adresu vyhodnotí jako neexistující. 3.3.2 Zálohování a odstranˇení databáze Vztahy mezi virtuálním serverem a jeho databází jsou popsány v oddíle 2.1.2. Dˇríve, než dojde k odstranˇení databáze, je nutné zaruˇcit, že data v ní uložená nebudou nenávratnˇe ztracena. Zálohování databáze bylo puvodnˇ ˚ e provádˇeno nástroji k tomu urˇce2 nými. Jedním z vhodných kandidátu˚ je mysqldump , který je souˇcástí základní instalace MySQL serveru. Zálohují se všechna data, bez ohledu na jejich význam, který dokáže stejnˇe 2.
14
ˇ 3.3. ODSTRAN ENÍ VIRTUÁLNÍHO SERVERU
Obrázek 3.7: Odstranˇení virtálního webového serveru urˇcit pouze jejich vlastník. Ten má možnost si zálohu své databáze vyžádat u administrátora serveru. Pokud probˇehlo zálohování, je možné pˇristoupit k samotnému odstranˇení databáze, respektive databáze a uživatele sloužícího k pˇrístupu k ní. Syntaxe pˇríkazu˚ na odstranˇení databáze virtuálního serveru s doménovým názvem stary_web, je vysvˇetlena v pˇríkladˇe 3.3.1. DROP DATABASE stary_web; DROP USER stary_web;
Pˇríklad 3.3.1: Odstranˇení databáze Pˇri rušení databáze musí mít uživatel, pod kterým je správce pˇrihlášen, udˇelené právo DROP pro danou databázi, pˇri odstranování ˇ uživatele právo DELETE pro databázi mysql.
3.3.3 Odstranˇení webového prostoru Bˇehem procesu odstranˇení webového prostoru je tˇreba kromˇe zálohování samotných dat ctít také nˇekolik omezení. Celý scénáˇr je popsaný níže s ohledem na obrázek 3.8. Zmínˇené omezující podmínky jsou vysvˇetleny právˇe v popisu scénáˇre. 15
ˇ 3.3. ODSTRAN ENÍ VIRTUÁLNÍHO SERVERU
Obrázek 3.8: Odstranˇení webového prostoru Konfigurace webového serveru Je tˇreba smazat konfiguraˇcní soubor pro odstranovaný ˇ virtuální server. Soubor se nachází v umístˇení, které je pˇredmˇetem konfigurace webového serveru. O pravidlech pro pojmenování a formátu konfiguraˇcního souboru se pojednává již v souvislosti s vytváˇrením virtuálního serveru v sekci 3.1.3. Aby se provedené zmˇeny (odstranˇení konfiguraˇcního souboru) projevily na provozu serveru, je tˇreba restartovat webový server Apache. Zálohování a odstranˇení adresáˇre Pˇred odstranˇením webového prostoru je tˇreba provést jeho zálohu. Webový prostor virtuálního serveru pˇredstavuje adresáˇr umístˇený v souborovém systému webového serveru na adrese urˇcené v jeho konfiguraci. Samotné zálohování se provádí pomocí komprimaˇcního software. Výsledný soubor je pak uložen a pˇripraven, aby mohl být v pˇrípadˇe vyžádání pˇredán bývalému správci serveru. Podmínkou nutnou k úspˇešnému odstranˇení adresáˇre je provedená úprava konfigurace a restart serveru (zmínˇeno v sekci 3.3.3). V opaˇcném pˇrípadˇe by nebylo možné adresáˇr odstranit. Adresáˇr, pokud je zazálohován, je odstranˇen bˇežným systémovým pˇríkazem. Odstranˇení skupiny Pokud je již adresáˇr odstranˇen, je možné odstranit i skupinu, která byla na úrovni souborového systému nastavena jako skupina adresáˇre. Nejprve je ovšem nutné odebrat ze skupiny všechny její cˇ leny a tˇem, kteˇrí již nejsou správci jiného virtuálního serveru, odebrat pˇrístup na webový server. Tato cˇ ást procesu odpovídá, až na jednu vyjímku, opatˇrením zminovaˇ ným již v souvislosti s úpravou virtuálních webových serveru˚ v oddíle 3.2.2. Jedinou zmˇenou je zrušení požadavku na existenci alesponˇ jednoho správce virtuálního serveru.
16
Kapitola 4
Návrh a implementace Aplikace byla podle požadavku implementována v PHP verze 5. Kontrétnˇe byla volena taková rˇ ešení, aby podle [9] vyhovovala pˇresné specifikaci verze uvedené v cˇ ásti 2. V prubˇ ˚ ehu vývoje uživatelského prostˇredí byla využita rˇ ada knihoven. Jejich seznam a popis je uveden v oddíle 4.3. Aplikaˇcní schéma je možné rozdˇelit na dvˇe cˇ ásti. V úvodní cˇ ásti implementace byly vyvinuty prostˇredky, které tvoˇrí prezentaˇcní cˇ ást aplikace. Mezi takové patˇrí zejména implementace pruvodc ˚ u, ˚ díky kterým je možné procházet procesy nastavení virtuálních webových serveru˚ krok za krokem s prubˇ ˚ ežnou kontrolou výsledku˚ dílˇcích operací a s možností zopakování operací v pˇrípadˇe jejich neúspˇechu. O prezentaˇcní cˇ ásti aplikace je uvedeno více v oddíle 4.2. Samotná aplikaˇcní logika, tedy implementace procesu, ˚ jejichž úspˇešné provedení vede k vytvoˇrení, úpravˇe nebo odstranˇení virtuálního webového serveru, vznikala až po dokoncˇ ení implementace vrstvy prezentaˇcní. Detaily spojené se zachycením aplikaˇcní logiky jsou zmínˇeny v sekci 4.1. Aplikace byla vyvíjena iterativním zpusobem. ˚ Této skuteˇcnosti odpovídá i prubˇ ˚ eh testování, které probíhalo od raných fází implementace až po koneˇcné nasazení aplikace Webadmin. Více o testování a provozu aplikace uvádí oddíl 4.6.
4.1
Pokrytí funkcionality
ˇ Cást aplikace pokrývající funkcionalitu modelovanou v kapitole 3 je implementována cˇ istˇe v PHP. Jednotlivé operace jsou vykonávány bud’ jako dotaz do databáze, nebo volání pˇríkazu na webovém serveru. Proces správy virtuálních webových serveru˚ nemohl být aplikací Webadmin úplnˇe zautomatizován. Nˇekteré akce na serveru vyžadují správcovská oprávnˇení, která není možné webové aplikaci poskytnout z duvodu ˚ bezpeˇcnostních rizik. Procedury, jejichž provedení nebylo pˇrípustné, byly nahrazeny výpisem instrukcí, jak má správce serveru dále pokraˇcovat. Pˇrípadnˇe, pokud to bylo možné, bylo ovˇerˇ eno provedení pˇríkazu, ˚ po kterém bylo teprve možné pokraˇcovat v operaci. Pokyny jsou výraznˇe oznaˇceny. Jejich formátování umožnuje ˇ 1 snadné kopírování textového obsahu do schránky . Seznam zminovaných ˇ procedur se nachází v následujícím oddíle. 1.
ˇ Casto oznaˇcováno jako copy & paste.
17
4.1. POKRYTÍ FUNKCIONALITY 4.1.1 Nezautomatizované procedury V rámci jednotlivých scénáˇru˚ se vyskytují i akce, které není možné z ruzných ˚ duvod ˚ u˚ provést v rámci aplikace, která je pˇredmˇetem této práce. V odpovídajících sekcích naleznete jejich seznam. Vytvoˇrení virtuálního serveru •
Vytvoˇrení doménového názvu. V prubˇ ˚ ehu vytváˇrení doménového názvu je nutné upravit konfiguraˇcní soubor nacházející se na DNS serveru, jak je popsáno v sekci 3.1.1. K souboru má pˇrístup pouze uživatel se správcovským oprávnˇením, což je pˇríˇcinou nepokrytí funkcionality v rámci aplikace. Provedení instrukcí poskytnutých uživateli aplikace není ovˇerˇ ováno.
•
Nastavení pˇrístupových práv. Nastavení práv a vlastníka adresáˇre na úrovní souborového systému vyžaduje vyšší pravomoci, než které mohou být serveru Apache pˇridˇeleny. Proceduru popisuje sekce 3.1.3. Provedení zmˇeny vlastníku˚ a pˇrístupových práv adresáˇre jsou ovˇerˇ ovány a jejich splnˇení je podmínkou pro další pokraˇcování v procesu.
•
Restart webového serveru. Úkon muže ˚ provádˇet pouze správce systému. Vykonání restartu není kontrolováno.
Úprava virtuálního serveru •
Nastavení nového vlastníka adresáˇre. Nastavení uživatele u adresáˇre na webovém serveru je možné provádˇet pouze se správcovským oprávnˇením. Podrobnosti procesu jsou projednávány v sekci 3.1.3.
Odstranˇení virtuálního serveru •
Odebrání doménového názvu. Operace je provádˇena úpravou konfiguraˇcního souboru umístˇeného na DNS serveru. Jeho zmˇena je povolena pouze správci systému. Provedení akce není aplikací hlídané.
•
Restart webového serveru. Operaci obnovení serveru Apache muže ˚ provést pouze správce systému. Provedení operace není aplikací kontrolováno.
•
Odstranˇení adresáˇre. Protože byl pˇri vytvoˇrení adresáˇr pˇridˇelen uživateli a skupinˇe správce virtuálního serveru, není možné jej nyní prostˇrednictvím aplikace smazat. Podrobnosti o prubˇ ˚ ehu nastavení vlastníku˚ adresáˇre zminuje ˇ sekce 3.1.3. K akci jsou potˇrebná oprávnˇení správce systému. Odstranˇení adresáˇre je aplikací ovˇerˇ ováno.
18
ˇ ˇ 4.2. PREZENTA CNÍ CÁST APLIKACE
4.2
Prezentaˇcní cˇ ást aplikace
Implementace pruvodc ˚ u, ˚ jejichž procházením uživatel provádí kroky nezbytné ke splnˇení daných úkolu, ˚ je velmi duležitou ˚ souˇcástí prezentaˇcní cˇ ásti aplikace. Aby bylo dosaženo požadovaného chování, je v této fázi využito jak skriptování na stranˇe serveru, tak na stranˇe uživatele. 4.2.1 PHP tˇrída Wizard Srdcem aplikace je tˇrída Wizard. Jedná se o tˇrídu, jež shromažd’uje sekvenci kroku, ˚ objektu˚ typu WizardStep. Nejduleži˚ tˇejší metody tˇrídy: •
addStep. Metoda addStep slouží k pˇridání kroku na konec dosavadního pruvodce. ˚
•
processStep. Metoda spouští akci popisovanou v kroku, jehož pozice je pˇredána metodˇe jako atribut.
•
isEndOfWizard. Rozhoduje, zda pro pozici urˇcenou argumentem funkce ještˇe existuje krok v pruvodci. ˚
Dále obsahuje metody pro získávání informací od samotných kroku, ˚ tedy objektu˚ typu WizardStep. Tyto metody i všechny ostatní naleznete popsané v dokumentaci. Pro každý scénáˇr popsaný v 3 existuje zvláštní skript, který definuje sekvenci kroku, ˚ svˇerˇ í ji objektu typu Wizard a na základˇe parametru˚ pˇredaných skriptu, provádí krok s urcˇ eným poˇradovým cˇ íslem. Výsledek provedení kroku rozhodne, zda je možno pokraˇcovat v pruvodci ˚ nebo je nutné postup zopakovat. PHP tˇrída Wizard je významnˇe provázána se tˇrídou stejného názvu implementovanou pomocí jQuery. Pˇresnˇeji, výše popisované skripty jsou dodavatelem tˇrídy psané v jQuery. 4.2.2 jQuery tˇrída Wizard Ovládání PHP tˇrídy Wizard má na starosti její jmenovec napsaný v jQuery. Pro zjednodušení budu nadále oznaˇcovat jQuery podobu tˇrídy Wizard jako JQWizard. Jedná se o tˇrídu, která mimo jiné udržuje aktuální pozici v rámci pruvodce ˚ a tak umožnuje ˇ navigaci mezi kroky a jejich postupné vykonávání. Pro každý zachycovaný scénáˇr je vytváˇren zvláštní objekt typu JQWizard. Tento objekt má jako atribut umístˇení, ve kterém se nachází PHP skript inicializující daného pruvodce. ˚ Interakce je založena na asynchronním volání skriptu pomocí JQWizard a pˇredání parametru oznaˇcujícího pozici v rámci pruvodce. ˚ Výsledek volání skriptu je uložen do urˇceného elementu v rámci stromu dokumentu a projeví se tak zmˇenou obsahu zobrazované stránky. Nejduležitˇ ˚ ejší metody tˇrídy: •
setProperty, getProperty. Metody sloužící ke správˇe vlastností daného pruvodce. ˚ Takovými vlastnostmi jsou zejména url s adresou skriptu, který má objekt volat, a target definující element v rámci stromu dokumentu. 19
4.3. POUŽITÉ KNIHOVNY •
setParam, getParam. Tyto metody ovládají pˇrístup k promˇenným, které je možné bˇehem prubˇ ˚ ehu pruvodce ˚ ukládat. Je tak umožnˇeno pˇrenášení hodnot mezi separátními voláními PHP skriptu. ˚ Využívané pro ukládání pozice v pruvodci ˚ a duležitých ˚ promˇenných.
•
nextStep. Metoda umožnující ˇ vykonání kroku˚ pruvodce. ˚ Zavolá skript specifikovaný ve vlastnostech objektu a pˇredá mu množinu všech parametru˚ vˇcetnˇe cˇ ísla kroku, který má být vykonán. Výsledek uloží do elementu urˇceného ve vlastnostech. Navýší hodnotu pozice o jedniˇcku.
•
repeatStep. Metoda umožnující ˇ reakci na chybu bˇehem provádˇeného kroku. Její chování je založeno na úpravˇe hodnoty urˇcující pozici v pruvodci. ˚ Metoda repeatStep sníží tuto hodnotu o jedniˇcku, pak zavolá metodu nextStep, tedy krok se zopakuje.
4.3
Použité knihovny
V rámci implementace aplikace podle soudobých trendu˚ byla využita technologie AJAX. Díky ní je možné mˇenit obsah webové stránky aniž by došlo k jejímu obnovení. Tohoto zámˇeru bylo dosaženo využitím javascriptové knihovny jQuery. 4.3.1 jQuery Pod názvem jQuery se podle serveru [5] skrývá rychlá a struˇcná JavaScriptová knihovna, která zjednodušuje procházení HTML dokumentu, zpracování událostí a interakci založenou na technologii Ajax k rychlému vývoji webu. Hlavním duvodem ˚ pro použití jQuery je její podpora širokého spektra webových prohlížeˇcu. ˚ Nestane se tedy, jako pˇri použití bˇežného JavaScriptu, že by se jazyková konstrukce fungující v jednom prohlížeˇci chovala úplnˇe jinak v prohlížeˇci jiné firmy. Dalším duvodem ˚ je pohodlné využití asynchronních volání nabízených knihovnou. Její rozhraní nabízí jak nízkoúrovnové ˇ funkce, které si muže ˚ vývojáˇr upravit podle svého zámˇeru, tak i vysokoúrovnové ˇ rˇ ešení nabízející široké možnosti konfigurace vlastního chování. V neposlení rˇ adˇe je potˇreba zmínit, že na jejím základˇe vznikla již rˇ ada rozšíˇrení, cˇ i zásuvných modulu, ˚ které vývoj webu ještˇe více usnadnují ˇ a zrychlují. Rozšiˇrující knihovny využité v aplikaci, která je pˇredmˇetem této práce jsou uvedeny ve zbytku tohoto oddílu. V aplikaci je využívána jQuery verze 1.7.1. jQuery.Class S rostoucím objemem vytvoˇreného kódu nastane okamžik, kdy je potˇreba dílu udˇelit jistou strukturu, i když to právˇe není zámˇerem samotného jQuery. Knihovna jQuery.Class zavádí do jQuery podporu tˇríd a objektu˚ a tím i možnost použití principu˚ známých z objektovˇe orientovaného pˇrístupu k programování. 20
4.3. POUŽITÉ KNIHOVNY jQuery Form Plugin Cílem rozšíˇrení Form je zjednodušit v jQuery podporu pro asynchronní odesílání HTML formuláˇru. ˚ Nabízí rozhraní vyšší úrovnˇe než samotné jQuery. Tedy práce s ním je pro vývojáˇre snazší. jQuery Address Pokud aplikace zmˇení svuj ˚ stav pomocí skriptování na stranˇe uživatele užitím jQuery, nepromítne se nutnˇe tato zmˇena v adrese, která byla puvodnˇ ˚ e zavolána. Právˇe tento problém rˇ eší rozšíˇrení jQuery Address. Umožnuje ˇ vytvoˇrení virtuální adresy, která popisuje aktuální stav aplikace. Vytvoˇrení takové vazby je ovšem stále odpovˇedností vývojáˇre aplikace, knihovna k tomu poskytuje jen užiteˇcné nástroje. Existence jedineˇcné virtuální adresy popisující stav aplikace má nˇekolik výhod. Tou nejvýraznˇejší je zˇrejmˇe možnost pˇrímé adresace sekce, cˇ ásti webu, o kterou má návštˇevník právˇe zájem, místo pracné navigace pomocí hypertextových odkazu. ˚ Další z výhod je možnost vytvoˇrení tzv. záložky v prohlížeˇci. Nebo napˇríklad navigace v historii navštívených webových stránek pomocí tlaˇcítek lišty webového prohlížeˇce. Aby byl obsah webu pˇrístupný i robotum ˚ vyhledávacích serveru, ˚ je nutné poskytovat obsah dynamicky vytváˇrený pomocí skriptování na stranˇe uživatele i statickým zpusobem. ˚ Zmínˇený problém ale pˇresahuje rámec vytváˇrené aplikace, u které je zájem vyhledávaˇcu˚ spíše nežádoucí. Více o tomto tématu je uvedeno na [1]. jQuery BlockUI Plugin BlockUI zásuvný modul slouží k blokování ovládacích prvku˚ stránky. V aplikaci je toho využito bˇehem provádˇení asynchronních volání pomocí jQuery. Je velmi duležité, ˚ aby se aplikace v momentˇe zahájení operace nacházela v konzistentním stavu. Blokování je provádˇeno na dvou úrovních. Možné je blokování jak celé stránky, tak i jednotlivých dílˇcích elementu. ˚ Funkcionality je využito v knihovnˇe webadmin.loading-control, která vznikla jako souˇcást aplikace Webadmin. jQuery UI Rozšíˇrení jQuery UI již neslouží jenom ke specifikaci funkcionality, nýbrž se zabývá i vizuální podobou rˇ ešení. Nabízí rˇ adu tzv. widgetu, ˚ což jsou grafické komponenty spoleˇcnˇe s kódem, který k nim doplnuje ˇ akce. V rámci aplikace webadmin byly použity dva widgety a to Autocomplete a Accordion. Accordion umožnuje, ˇ aby ve stránce nad sebou bylo nˇekolik sekcí, pˇriˇcemž pouze jedna z nich je plnˇe zobrazená, z ostatních je dostupný jen nadpis. Zmˇena aktuálnˇe zobrazované sekce je provedena kliknutím myší. V pˇrípadˇe Autocomplete se jedná o podporu vyhledávání s prubˇ ˚ ežnou nabídkou vyhovujících pojmu. ˚ Jak uživatel píše do textového pole hledaný pojem, tak se mu v nabídce 21
ˇ 4.4. NÁVRH UŽIVATELSKÉHO PROST REDÍ zobrazují odpovídající položky z poskytnuté množiny dat. Výbˇerem z nabídky dojde k doplnˇení vepsaného rˇ etˇezce na zvolenou hodnotu. V aplikaci je použita verze 1.8.18 s užívanými souˇcástmi. 4.3.2 jsonwrapper Aplikace je koncipována tak, že výkonný kód je napsán v PHP, kdežto prezentaˇcní cˇ ást je provedena pomocí JavaScriptu, konkrétnˇe knihovny jQuery. Z tohoto duvodu ˚ je nezbytnˇe nutné pˇrenášet data pˇredstavující výsledky operací z PHP do JavaScriptu. Za tímto úˇcelem byl vyvinut formát JSON (JavaScript Object Notation). Jak se zminuje ˇ v [6] je JSON „jednoduše cˇ itelný i zapisovatelný cˇ lovˇekem a snadno analyzovatelný i generovatelný strojovˇe“. Dále je „zcela nezávislý na jazyce“. Podle [9] PHP od verze 5.2.0 podporuje formát JSON pomocí funkcí json_encode a jí inverzní json_decode. Jelikož byla aplikace vyvíjena pro prostˇredí s verzí PHP 5.1.6, není možné funkcí využít. Nicménˇe pro povahu aplikace je jimi pokrytá funkcionalita zásadní. Proto vznikl skript jsonwrapper popisovaný na [7]. Mimo jiné v jeho popisu stojí „jsonwrapper implementuje funkci json_encode, pokud chybí, a pokud je pˇrítomna, nechá ji být.“. To znamená, že pˇri pˇrípadném pˇrechodu na novˇejší verzi PHP nebude aplikace závislá na této nouzové implementaci funkce, ale využije se její oficiální podoba.
4.4
Návrh uživatelského prostˇredí
Návrh uživatelského prostˇredí byl veden s ohledem na povahu aplikace Webadmin. Jedná se o administrativní nástroj spíše než o webovou prezentaci. Z tohoto duvodu ˚ byla grafická stránka aplikace rˇ ešena stˇrízlivým vzhledem, maximálním prostorem pro pˇredávané informace a pˇrehlednou strukturou rozvržení tˇela stránky. Popis kompozice grafických detailu˚ uvádí obrázek 4.1. Hlavní nabídka je situována v záhlaví stránky. Obsahuje rozcestník na všechny souˇcásti aplikace. Jednotlivé položky jsou vyvedeny výrazným motivem vyjadˇrujícím nadˇrazenost nabídky všem ostatním. Význam odkazu˚ podtrhují grafické ikony, které jsou souˇcástí jejich popisku. Zobrazení hlavní nabídky je ve všech sekcích stejné. Detailní pohled na nabídku je na obrázku 4.2. Oblast pod navigaˇcní lištou (dále oznaˇcována jako tˇelo stránky) je zcela vyhrazen pro prezentaˇcní potˇreby aplikace. V návrhu rozvržení samotných pruvodc ˚ u˚ byl kladen duraz ˚ na jednotné a výrazné rˇ ešení ovládacích prvku. ˚ Odkazy navigace pruvodcem ˚ jsou opatˇreny grafickými ikonami stejného typu jako v hlavní nabídce. Nicménˇe jejich zvýraznˇení již není takové míry. Navigaˇcní panel pruvodce ˚ je umístˇen v horním pravém rohu tˇela stránky hned pod jeho názvem. Místo pod navigaˇcním panelem je vyhrazeno jako zobrazovací prostor pruvodce. ˚ V jeho tˇele se zobrazují data, jimiž aplikace komunikuje s uživatelem. V podobˇe formátovaného textu, odkazu, ˚ formuláˇrových prvku˚ jsou vymˇenována ˇ data mezi uživatelem a aplikací. Pod zobrazovacím prostorem se nachází oblast se záznamy provozního logu aplikace. 22
4.5. CHOVÁNÍ APLIKACE
Obrázek 4.1: Rozvržení stránky
Obrázek 4.2: Detail hlavní nabídky Vzhled konfiguraˇcní cˇ ásti aplikace je urˇcen hlavnˇe formuláˇrovými prvky, jejich obsah urˇcuje nastavení aplikace. Konfiguraˇcní záznamy jsou rozdˇeleny do nˇekolika oddílu, ˚ které jsou graficky oddˇeleny. V kterékoliv sekci je možné spatˇrit pole nápovˇedy. Jedná se o barevnˇe oznaˇcený element, který slouží jako rádce uživateli. Pˇríklad jeho využití je na obrázku 4.1. Grafické prvky využité v navigaˇcním poli záhlaví stránky i tˇela stránky pochází z jedné sady ikon pro vývojáˇre webových aplikací. Zdroj souboru je uveden v A.
4.5
Chování aplikace
Aplikace Webadmin jakožto administrátoruv ˚ nástroj pro správu virtuálních webových serveru˚ zavádí rˇ adu opatˇrení, která umožnují ˇ korektní dokonˇcení provádˇeného úkonu. Poskytuje také informace v pˇrípadˇe neúspˇešného vykonání operace. 4.5.1 Logování K zachycení výsledku˚ provozu aplikace slouží logovací soubory, jejichž umístˇení je nastaveno v konfiguraci. Záznamy o prubˇ ˚ ehu operací jsou rozdˇeleny podle jejich povahy na provozní a chybové. 23
4.5. CHOVÁNÍ APLIKACE Provozní záznam je otevírán pˇri spuštˇení pruvodce. ˚ V jeho dalším prubˇ ˚ ehu jsou zapisovány zprávy oznamující úspˇešnˇe vykonané akce. Aktuální obsah právˇe provádˇeného pru˚ vodce je prubˇ ˚ ežnˇe zobrazován uživateli. Záznamy se po ukonˇcení pruvodce ˚ neodstranují, ˇ jsou tedy k dispozici v daném souboru pro pozdˇejší procházení. Chybové záznamy jsou vytváˇreny v momentˇe, kdy dojde k chybˇe bˇehem procesu. Pokud všechny operace probˇehnou v rámci pruvodce ˚ v poˇrádku, není chybový záznam vytvoˇren vubec. ˚ V pˇrípadˇe neúspˇešného provedení kroku pruvodce ˚ je poslední chybový záznam vypsán uživateli.
4.5.2 Reakce na chybu Reakce na chybu je velmi duležitou ˚ vlastností aplikace. Již ze schémat uvedených v sekci 3 je zˇrejmé, že rˇ ada kroku˚ je závislá na úspˇešném vykonání jim pˇredcházejících. Stejnˇe tak ke správnému provedení scénáˇru˚ je bezpodmíneˇcnˇe nutné, aby byly všechy kroky provedeny úspˇešnˇe. Z tohoto duvodu ˚ je kontrolována návratová hodnota funkcí a metod vykonávaných v rámci jednotlivých kroku˚ a podle toho odvozován úspˇech cˇ i neúspˇech celé operace. Pokud dojde k chybˇe v jednom kroku, aplikace dovolí uživateli krok zopakovat, aniž by se provádˇený proces pˇrerušil. Jakmile akce uspˇeje, pruvodce ˚ postoupí k provádˇení následujících kroku. ˚ Zmínˇená opatˇrení jsou rˇ ešena jak na úrovni prezentaˇcní cˇ ásti aplikace, tak i v její výpoˇcetní cˇ ásti.
Opatˇrení v rámci aplikaˇcní logiky Kvuli ˚ možnosti opakování volání urˇcitého kroku pˇri chybˇe jeho provádˇení je nutné zajistit, aby významné operace nebyly provedeny vícekrát. Znamená to tedy, že pokud se krok skládá z více operací, z nichž jen cˇ ást uspˇela, tak je pˇri opakování akce nutné, aby ty z nich, které byly provedeny již v pˇredchozím volání, byly rozpoznány a nebyla jejich funkcionalita vykonána znovu. Tato skuteˇcnost je velmi duležitá ˚ zejména v procesu vytváˇrení virtuálních webových serveru. ˚ Proto se v úvodním kroku tohoto pruvodce ˚ ovˇerˇ uje, zda doména, databáze nebo databázový uživatel názvu shodného se zadaným neexistuje. Pokud potom napˇríklad dojde k chybˇe bˇehem vytváˇrení databáze pro doménu se jménem domain_name, v opakovaném prubˇ ˚ ehu staˇcí ovˇerˇ it, zda již existuje databáze s daným jménem, pokud ano, je to databáze z minulého prubˇ ˚ ehu provádˇení kroku a pokraˇcuje se s ní. Tuto záruku je možné vyslovit právˇe na základˇe pˇredpokladu, že v prvním kroku bylo povoleno vytvoˇrení domény s názvem domain_name, což znamená, že puvodnˇ ˚ e doména, databáze ani uživatel databáze s daným jménem neexistovali. Toto tvrzení je dále podpoˇreno faktem, že správa virtuálních webový serveru˚ se po nasazení aplikace provádí pouze jejím prostˇrednictvím. Pˇrípadná nekonzistence v popisovaných vztazích by tedy nebyla vinou aplikace, nýbrž jejím nesprávným užíváním. 24
4.5. CHOVÁNÍ APLIKACE Opatˇrení v rámci prezentaˇcní vrstvy Prezentaˇcní vrstva reaguje na chybu v procesu úpravou navigaˇcního panelu pruvodce ˚ a výpisem chybového logu do jeho zobrazovacího prostoru. Podrobnosti o rozvržení stránky uvádí sekce 4.4. V navigaˇcním panelu je položka oznaˇcující pokraˇcování dalším krokem nahrazena volbou opakování neúspˇešnˇe provedené akce.
4.5.3 Zprávy zasílané uživatelum ˚ Uživatelé jsou o provedených operacích, které se jich pˇrímo týkají, obeznámeni elektronickou poštou. Obsahy zpráv se liší na základˇe procesu, který se právˇe odehrál. Po vytvoˇrení nového virtuálního webového serveru jsou uživatelum, ˚ kteˇrí byli vybráni jako správci domény, pˇredány informace o databázi, zpusobu ˚ pˇrihlášení k ní a pˇrihlašovacích údajích. Dále je obsahem této zprávy informace o pˇrístupu na webový server a pro nˇej potˇrebné informace. V pˇrípadˇe úpravy virtuálního webového serveru jsou rozesílány dva typy zpráv. Novˇe pˇridaným správcum ˚ je odeslána zpráva témˇerˇ totožná se zprávou z vytváˇrení virtuálního serveru. Jediným rozdílem je absence hesla pro pˇrístup k databázi, to již není možné v aplikaci zjistit. Naopak odebíraným uživatelum ˚ je odeslán email s oznámením o zrušení správcovství domény, popˇrípadˇe, pokud již nejsou správci žádné další domény, také o odebrání práva pˇrístupu na webový server. Po zrušení virtuálního webového serveru jsou uživatelé obeznámeni o zálohování databáze a webového prostoru a možnosti vyžádání jejich dat. Dále zpráva zahrnuje informaci o zrušení správcovství domény, pˇrípadnˇe o odebrání pˇrístupu na webový server.
4.5.4 Zabezpeˇcení aplikace Aplikace Webadmin neimplementuje žádné mechanismy zabezpeˇcení. Ošetˇrení bezpeˇcnosti je úkolem uživatele, administrátora serveru.
4.5.5 Upozornˇení pˇred významným krokem Jako prevence pˇred provedením závažné akce nedopatˇrením obsahují pruvodci ˚ potvrzovací mezikroky. Jedná se o funkci, která vypisuje upozornˇení, jaká akce má být provedena a navigaˇcní panel je upraven, aby nedošlo k potvrzení kroku neopatrností uživatele. Položka umožnující ˇ pˇrechod k dalšímu kroku pruvodce ˚ je odstranˇena z pravého okraje navigace, nahrazena je odkazem vyjádˇrení souhlasu s provedením akce, který je umístˇen na levé stranˇe navigaˇcního panelu. Pˇríklad obrazovky s uvedenou úpravou naleznete na obrázku 4.3. Zvolená strategie má za cíl omezení poˇctu nezámˇernˇe provedených akcí na minimum. Zejména zmˇena pozice navigaˇcního symbolu nabourává stereotyp provádˇení akcí v sérii bez rozmyslu. 25
4.6. TESTOVÁNÍ A PROVOZ
Obrázek 4.3: Krok potvrzení akce 4.5.6 Ukonˇcení pruvodce ˚ V momentˇe, kdy byl úspˇešnˇe vykonán poslední krok pruvodce, ˚ aplikace oznámí, že celý proces probˇehl v poˇrádku. Pˇred rˇ ádným ukonˇcením pruvodce ˚ je možné jej pˇrerušit obnovením celé stránky, pˇrechodem do jiné sekce v hlavní nabídce stránky, zavˇrením okna prohlížeˇce. V takovém pˇrípadˇe dojde ke ztrátˇe stavu, ve kterém aplikace byla. Není poté možné na akci navázat a pokraˇcovat v ní. Pˇred uzavˇrením okna prohlížeˇce nebo pˇred obnovením celé stránky vyzývá aplikace uživatele k potvrzení volby.
4.6
Testování a provoz
Aplikace byla vyvíjena iterativním zpusobem. ˚ Její testování probíhalo tedy již od raných fází implementace. V první fázi vývoje, kdy se provádˇela implementace prezentaˇcní cˇ ásti aplikace zmínˇené v oddíle 4.2, byla aplikace testována vývojáˇrem. V pozdˇejších iteracích, kdy byla vyvíjena cˇ ást aplikace pokrývající aplikaˇcní logiku (4.1), bylo testování provádˇeno administrátorem serveru na FSS MU. Duvodem ˚ pˇredání zodpovˇednosti testování administrátorovi serveru byla povaha testované funkcionality. Jednalo se o procesy, které ovlivnovaly ˇ chod serveru. Nˇekteré procesy nutné k dokonˇcení operace, uvedené v oddíle 4.1.1, mohou být provedeny pouze správcem systému. Bˇehem testování administrátorem serveru byly pˇripomínky na funkcionalitu a uživatelské prostˇredí reflektovány v dalších iteracích vývoje aplikace. Aplikace byla testována pˇrímo v provozním prostˇredí. Pro uvedení do provozu nebylo nutné žádných dalších úprav. 26
Kapitola 5
Závˇer Cílem této práce bylo vytvoˇrit aplikaci, která by zjednodušovala a alesponˇ cˇ ásteˇcnˇe zautomatizovala procesy spojené se správou virtuálních webových serveru˚ na FSS MU. V aplikaci Webadmin, která je pˇredmˇetem této práce, byly tyto procesy implementovány. Pro každý scénáˇr použití byl vytvoˇren zvláštní pruvodce, ˚ který uživatele provádí krok za krokem až k úspˇešnému dokonˇcení operace. Vznikl tak administrativní nástroj, který usnadnuje ˇ administrátorovi serveru správu virtuálních serveru. ˚ V úvodních fázích vývoje byly modelovány procesy správy virtuálních webových serveru˚ pomocí notace BPMN. Na základˇe vzniklých procesních modelu˚ byla poté vyvíjena aplikace. Implementaci pˇredcházelo nastudování principu, ˚ které jsou na pozadí konfigurace virtuálních serveru. ˚ Jednalo se o problematiku podpory virtuálních webových serveru˚ platformou Apache 2, práce s MySQL databází, nastavení DNS serveru, správy uživatelských úˇctu˚ na FSS MU. I když nebylo kvuli ˚ této práci nezbytnˇe nutné nastudovat zmínˇené okruhy zevrubnˇe, uˇcinil jsem si pˇredstavu o tom, jaké možnosti která oblast skýtá, jak muže ˚ být rˇ ešena zkoumaná problematika a jaké vztahy mezi komponentami panují na webovém serveru. Vyzkoušel jsem si také vývoj aplikace iterativním zpusobem ˚ s prubˇ ˚ ežnými konzultacemi a testováním. Cennou zkušeností bylo také zjištˇení, jakou formou se v podobných pˇrípadech provádí shromažd’ování požadavku˚ a jakým zpusobem ˚ je lze zachytit. V neposlední rˇ adˇe bylo zajímavé sledovat, jaké jsou povinnosti administrátora serveru ve spojitosti se správou virtuálních webových serveru˚ a vlastnˇe i celého serveru. Aplikace je implementována podle souˇcasných trendu˚ ve vývoji webových aplikací. Zejména využití asynchronního volání pomocí knihovny jQuery dává aplikaci nádech soucˇ asnosti. Využití XHTML a CSS je v dnešní dobˇe již samozˇrejmostí. Volba na knihovnu jQuery padla až v prubˇ ˚ ehu návrhu bez pˇredchozích zkušeností s ní. Pˇrekvapila mˇe svojí jednoduchostí a širokými možnostmi využití.
27
Literatura [1] Google, Inc: Making AJAX Applications Crawlable - Webmasters — Google Developers, Dostupný z , cit.15.4.2012. 4.3.1 [2] Pošmura, V.: Apache: Pˇríruˇcka správce WWW serveru, Computer Press Praha , 2002, ISBN 80-722-6696-9, x, 311 s. 3.1.3 [3] The Apache Software Foundation: Apache Virtual Host documentation - Apache HTTP Server, Dostupný z , cit. 7.5.2012. 1.1, 3.1.3 [4] Silver, B.: BPMN method and style, Cody-Cassidy Press Aptos , c2009, ISBN 9780982368107, xvii, 213 s. 1, 1.1 [5] The jQuery Foundation: jQuery: The Write Less, Do More, JavaScript Library, Dostupný z , cit. 16.4.2012. 4.3.1 [6] Json.org: Úvod do JSON, Dostupný z , cit. 16.4.2012. 4.3.2 [7] Boutell.Com: jsonwrapper: json_encode for earlier versions of PHP 5.x, , cit. 16.4.2012. 4.3.2 [8] Oracle Corporation and/or its affiliates: MySQL :: MySQL 5.0 Reference Manual, Dostupný z , cit. 6.5.2012. 2.1.2, 3.1.2 [9] php.net: PHP: Hypertext Preprocessor, Dostupný z , cit. 16.4.2012. 4, 4.3.2 [10] Arlow, J. a Neustadt, I.: UML 2 a unifikovaný proces vývoje aplikace, Computer Press Brno , 2011, ISBN 978-80-251-1503-9, 567 s. 1.1
28
Pˇríloha A
Použité knihovny JavaScriptové knihovny jQuery http://www.jQuery.com jQuery.Class http://bitovi.com/blog/2010/06/a-simple-powerful-lightweight-class-forjquery.html jQuery Form Plugin http://malsup.com/jquery/form/ jQuery Address Plugin v1.4 http://www.asual.com/jquery/address/ jQuery UI 1.8.18 http://jqueryui.com/
PHP knihovny jsonwrapper http://www.boutell.com/scripts/jsonwrapper.html
Grafické prvky WPZOOM Developer Icon Set http://www.wpzoom.com/wpzoom/new-freebie-wpzoom-developer-icon-set-154free-icons/
29
