Monitor zátěže serverů

Rozměr: px
Začít zobrazení ze stránky:

Download "Monitor zátěže serverů"

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Diplomová práce Monitor zátěže serverů Marek Fiala Vedoucí práce: Ing. Michal Šoch, Ph.D. Studijní program: Elektrotechnika a informatika, strukturovaný, navazující magisterský Obor: Výpočetní technika Květen 2009

2

3 Poděkování Na tomto místě bych rád poděkoval především vedoucímu práce Ing. Michalovi Šochovi, Ph.D. za cenné rady a připomínky v průběhu zpracování diplomové práce.

4

5 Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne

6

7 Abstrakt Tato diplomová práce popisuje návrh a implementaci systému, který umožňuje zaznamenávat údaje o činnosti operačního systému unix serverů. Součástí práce je také webová aplikace, která umožňuje zobrazovat nasbíraná data ve formě grafů a tyto data statisticky zpracovávat. Abstract This diploma thesis describes the design and implementation of a system that allows to record data about the activity of UNIX servers. A part of the thesis is also a web application that enables to display collected data in graphs and the data can be processed statistically.

8

9 Obsah Seznam obrázků Seznam tabulek Úvod Požadavky na systém Existující systémy HotSaNIC Munin Cacti Analýza a návrh řešení Architektura systému Způsob ukládání naměřených dat Textové / XML / binární soubory Relační databáze RRD databáze Způsob ukládání dat pro Shel-Node Způsob ukládání dat pro Shel-Master Přidávání nových pluginů na měřený server Komunikace mezi Shel-Master a Shel-Node Vlastní protokol SSH XML-RPC / SOAP SNMP Shel-Node Shel-Master Databáze Datové úložiště Stahování dat z měřených serverů Webová aplikace Zobrazování a správa grafů Konfigurace měřených hodnot Přidávání nových pluginů Implementace Volba použitých technologií RRDTool Použité technologie pro Shel-master Použité technologie pro Shel-node Použité technologie na webovou aplikaci Použité technologie Databázový systém Volba vývojového prostředí Volba nástroje pro tvorbu grafů Implementace Shel-node Démon Měřící skripty Datové úložiště Komunikace s Shel-master serverem Konfigurační soubory a logování Shel-node balík pro Debian

10 5.5. Implementace Shel-master Cron tabulka Datové úložiště Stahování dat Změna konfigurace pluginů/senzorů Zend Framework Bootstrap soubor (index.php) Model (model) Řadič (controller) Pohled (view) Implementace webové aplikace Struktura webové aplikace Grafy Autentizace a autorizace uživatelů Informace o stavu systému Další funkce webové aplikace Statistické zpracování naměřených dat Testování Závěr Seznam použité literatury Příloha A. Instalace měřeného serveru Příloha B. Implementace pluginů Příloha C. Databázové schéma Příloha D. Obsah přiloženého CD

11 Seznam obrázků Obr. 1 - Webové rozhraní HotSaNIC Obr. 2 - Webové rozhraní nástroje Munin Obr. 3 - Grafy síťových spojení v Muninu Obr. 4 - Webové rozhraní Cacti Obr. 5 - Ukázka grafů v Cacti Obr. 6 - Architektura systému Obr. 7 - ER model dat. Úložiště Obr. 8 - Komponenty Shel-Node Obr. 9 - Komponenty Shel-Master Obr Schéma databáze pro Shel-Master Obr Proces stahování dat Obr Rozvržení webového rozhraní Obr Uživatelské role a základní případy užití Obr Datový model pro senzory a pluginy Obr Komponenty Shel-Node Obr Změna konfigurace měřeného serveru Obr Komponenty Shel-Master Obr Diagram tříd podpory více komunikačních protokolů Obr Část datového modelu grafů Obr Ukázka grafu využití CPU Obr Ukázka grafu využití webového serveru Apache Obr Definice grafu Obr Stránka serveru Obr Stránka zobrazující stav měření Obr Typický průběh využití CPU u webového serveru Obr Výsledná podoba lineárního proložení Obr Seznam měřených serverů Obr Plugin počet běžících procesů Obr Plugin forks Obr Plugin CPU Obr Plugin Load Obr Plugin obsazení operační paměti Obr Plugin obsazení disku Obr Plugin datového toku na síťových rozhraních Obr. 35 TCP spojení Obr Plugin Apache Obr Plugin dotazy na MySQL databázi Obr. 38 ER model databáze

12 Seznam tabulek Tabulka 1 Odhad množství ukládaných dat na Shel-Node Tabulka 2 Srovnání rychlosti SQL a RRD Tabulka 3 - Datové typy Tabulka 4 - Způsob agregace - consolidation function Tabulka 5 - příkazy login skriptu Tabulka 6 - Debian balík Tabulka 7 - hustota ukládaní dat na centrálním serveru Tabulka 8 - Seznam řadičů

13 1. Úvod Již delší dobu propagují firmy své produkty a služby prostřednictvím Internetu. V dnešní době však vznikají společnosti, pro které znamená Internet jediný zdroj příjmů. Tyto společnosti jsou na dostupnosti svých síťových služeb přímo závislé. Ať už jde o webové stránky, elektronickou poštu, nebo další služby, jsou poskytovány pomocí serverů připojených do sítě Internet. Správná a nepřetržitá funkčnost serverů v režimu 7/24/365 je tedy naprostá nutnost. Zajistit dostupnost služeb má za úkol zpravidla administrátor serveru. K tomu musí mít velmi podrobný přehled o tom, co se na serveru děje a to nejen v danou chvíli, ale především zpětně v rámci určitého časového úseku. Dostatečný zdroj informací o stavu serveru je samozřejmě potřebný také při řešení aktuálního problému. Pokud má administrátor na starost pouze jeden, případně dva servery, obejde se většinou bez dalších speciálních nástrojů. Počet uživatelů Internetu však velmi rychle stoupá a s tím i nároky na hardwarové vybavení serverů. Velké společnosti (Google, Yahoo) zjistili, že se finančně vyplatí nakoupit větší množství neznačkových levných serverů, oproti nákladným a výkonným zařízením renomovaných značek. Díky tomu nespravuje administrátor pouze několik serverů, ale jedná se zpravidla o desítky (u větších společností až stovky) serverů. Při tomto počtu je nezbytné mít centralizovaný nástroj, který bude poskytovat podrobné informace o běhu a stavu jednotlivých spravovaných serverů. Software pro sledování informací o stavu serveru (monitoring) lze rozdělit na dvě samostatné kategorie: 1. Sledování aktuální dostupnosti služeb. 2. Dlouhodobé sledování stavu serveru. Do první kategorie se řadí nástroje, které monitorují především aktuální stav služeb, případně zaznamenávají historii jednotlivých výpadků. Umožňují většinou také zasílání upozornění například pomocí SMS. Do druhé kategorie patří systémy, které sledují dlouhodobě různé parametry běhu systému a tyto informace ukládají k pozdějšímu zpracování (zobrazení grafů). Vzniklo však i několik aplikací, jejichž funkce a možnosti zasahují více či méně do obou výše uvedených kategorií. Tato práce popisuje aplikaci, která spadá do druhé zmiňované kategorie. Systém tedy nebude umožňovat měřit aktuální dostupnost služeb, ani zasílat informace 13

14 v případě výpadku služby. Popisovaný systém má sloužit jako nástroj především pro předcházení problémů při správě serveru a také jako důležitý zdroj informací při jejich řešení. Systém je určen především pro správu většího množství serverů. 14

15 2. Požadavky na systém Cílem této práce je vytvořit aplikaci, která bude umožňovat sledování různých parametrů o běhu unixových serverů to znamená určitým způsobem data na serveru měřit a zaznamenávat. Konkrétně půjde o využití CPU, obsazení operační paměti, počet a typ síťových spojení, okamžité množství přenášených dat, počet běžících procesů, parametry databázového systému a další. Systém by měl umožňovat následující funkcionalitu: Centralizovaná správa Měření serveru musí být snadno ovladatelné a konfigurovatelné a to z jednoho centrálního místa. Odlišný interval měření pro různé veličiny Každá měřitelná veličina má odlišné nároky na interval měření počet procesů čekajících na obsloužení je údaj, který se mění neustále a proto je vhodné jej zaznamenávat častěji, než například volné místo na disku. Minimální požadovaný interval měření je 5 sekund. Přístup k naměřeným datům i při nedostupném měřeném serveru Pokud je měřený server z nějakého důvodu nedostupný (výpadek konektivity, hardwarová porucha), je pro administrátora užitečné, když si může ihned zobrazit grafy o činnosti serveru, zatímco technik v datacentru zajišťuje obnovení dostupnosti serveru. Ošetření výpadku centrálního serveru Pokud dojde k výpadku centrálního serveru, nesmí dojít ke ztrátě dat z jednotlivých měřených serverů. Měření odlišných veličin na jednotlivých serverech Na každém serveru běží různé aplikace a je tedy nutné zaznamenávat různé veličiny. Možnost přidání dalších pluginů Systém by měl obsahovat rozhraní, pro přidávání nových typů měřených veličin bez zásahu do zdrojového kódu aplikace. Dostatečná škálovatelnost Systém je určen jak pro jednotlivce spravující několik serverů, tak i pro webhostingové společnosti, nebo firmy zabývající se pronájmem managed a dedikovaných serverů (v tomto případě se může jednat i o několik stovek serverů). 15

16 Naměřená data bude možné zobrazit ve formě grafů z centrálního serveru pomocí webové aplikace, která bude umožňovat nastavení konkrétních měřených veličin na konkrétních serverech. Požadavky na webovou aplikaci: Hierarchie uživatelů s rozdílnými právy Zobrazení několika veličin v jednom grafu Možnost definovat vlastní grafy Zobrazení dat z více serverů v jednom grafu Upozornit na servery, kde se nesbírají data Zobrazení statistických údajů z naměřených dat 16

17 3. Existující systémy V této kapitole jsou popsány systémy, jejichž funkcionalita více či méně splňuje zadání této práce. Je zde tedy uveden přehled a stručný popis nejpoužívanějších aplikací, které umožňují měření údajů o serveru a zobrazovaní naměřených dat ve formě grafů HotSaNIC HotSaNIC, nebo-li HTML overview to System and Network Information Center je sada skriptů napsaných v Perlu a postavených nad rrdtool 1. Práce na projektu začala již v roce Systém podporuje Linux a částečně i BSD 2. Obr. 1 - Webové rozhraní HotSaNIC 1 RRDTool je nástroj pro práci s časovou řadou dat. Podrobně je popsán v kapitole RRDTool[5]. 2 BSD je odvozenina Unixu pocházející z univerzity v Berkeley. 17

18 Aplikace je napsaná modulárně, lze tedy snadno aktivovat a deaktivovat jednotlivé měřící moduly a vytvářet i moduly vlastní. Další výhodou je vzhledem k ostatním alternativám velmi krátký minimální interval měření a to 10 sekund. Grafy jsou vykreslovány pomocí rrdtool[5]. Nejsou však generovány až při požadavku na zobrazení, ale v pravidelných intervalech cca deseti minut. Webové rozhraní je velmi triviální, slouží pouze pro zobrazení grafů. Na úvodní obrazovce jsou zobrazeny náhledy jednotlivých grafů. Po kliknutí na náhled se zobrazí pod sebou grafy za poslední hodinu, den, týden, měsíc a rok. HotSaNIC patří sice mezi velmi jednoduché nástroje, ale v případě nasazení na jeden či dva servery jej lze bez problémů použít. Vzhledem k absenci centralizovaného rozhraní pro ovládání však není vhodný pro použití na větším množství serverů Munin Munin využívá oproti HotSaNICu master/node architekturu. Master se v pravidelných intervalech připojuje na jednotlivé měřené servery a žádá je o data. Munin je napsaný v Perlu 3 a využívá rrdtool a to jak k ukládání naměřených dat, tak i pro tvorbu výsledných grafů. Výhodou je snadné přidávání dalších měřících pluginů, kterých za dobu existence projektu vzniklo poměrně velké množství. Webové rozhraní je opět velmi jednoduché, zajišťuje pouze zobrazování grafů. Oproti HotSaNICu však umožňuje zobrazovat grafy z více serverů. Nevýhodou je interval měření, který je 5 minut. Grafy se zobrazují za poslední den, týden, měsíc a rok. Následující obrázky ukazují webové rozhraní Muninu. Obr. 2 - Webové rozhraní nástroje Munin 3 Perl je populární skriptovací jazyk [1]. Podrobnější popis tohoto jazyka je uveden v kapitole

19 Obr. 3 - Grafy síťových spojení v Muninu 3.3. Cacti Oproti výše uvedeným systémům je Cacti komplexní nástroj. Aplikace je kompletně napsána v jazyku PHP. Opět se jedná o klient/server architekturu, která umožňuje monitorovat více zařízení a ovládat je pomocí centrálního webového rozhraní. Pro přenos dat z měřených serverů je použit protokol SNMP 4, díky kterému lze snadno monitorovat i síťová zařízení (router, switch), pro které byla původně aplikace vyvinuta. Naměřená data jsou ukládána do RRD souborů, ze kterých jsou pomocí rrdtool generovány grafy. Cacti však využívá pro ukládání dalších informací i SQL databázi. Cacti umožňuje velmi detailní konfiguraci měření. Nejprve je nutné přidat zařízení, které chceme monitorovat a poté přiřadit zdroje dat (Data Sources), ze kterých se poté budou vytvářet grafy. Grafy lze poté přidat do skupiny (Graph Trees). Poměrně složitou konfiguraci jednotlivých částí velmi usnadňují předdefinované šablony (Templates). 4 Protokol SNMP (Simple Network Management Protocol) slouží pro monitorování síťových zařízení. 19

20 Obr. 4 - Webové rozhraní Cacti Mezi další funkce Cacti patří: Možnost vytváření vlastních skriptů pro měření dat. Přednastavené šablony pro grafy, zdroje dat a měřená zařízení. Stromové řazení grafů, které umožňuje vytvářet vlastní hierarchii. Správa uživatelů s rozdílnými úrovněmi oprávnění. Každý uživatel si může definovat svoje vlastní nastavení grafů. Obr. 5 - Ukázka grafů v Cacti Mezi největší výhody Cacti patří propracované webové rozhraní, které umožňuje detailní konfiguraci všech částí systému, dobrá škálovatelnost a rychlé generování grafů. Nevýhodou je, vzhledem k použití protokolu SNMP, dlouhý interval měření (5 minut). 20

21 4. Analýza a návrh řešení V této kapitole je popsán návrh řešení jednotlivých částí systému - tedy architektura systému, způsob ukládání dat, centrální server, měřený server, způsob síťové komunikace a webová aplikace. U každé části jsou probrané různé možnosti řešení včetně jejich výhod a nevýhod. Systém je pojmenován jako Shel. Od tohoto názvu se odvíjí pojmenování jednotlivých komponent (Shel-Master, Shel-Node) Architektura systému Základním požadavkem je centralizované řízení systému. Z toho vyplývá, že veškerá logika musí být uložena na jednom místě, tím je centrální server Shel- Master. Architektura systému je zobrazena na následujícím obrázku. Obr. 6 - Architektura systému Dalším požadavkem je zobrazování grafů i při nedostupném měřeném serveru. Nasbíraná data tedy bude nutné ukládat na centrálním serveru. Nabízejí se tedy dvě možnosti: 1. Data ukládat pouze na centrální server. 2. Data ukládat zároveň na centrální i měřený server. Výhodou prvního způsobu řešení je především jednoduchost. Nenastávají problémy s duplicitou dat a jejich aktualizací. Nevýhodou bude obrovské množství síťových spojení mezi centrálním serverem a měřenými servery, což může výrazně snížit škálovatelnost celého systému. Výhody a nevýhody duplicitního uložení dat jsou opačné jako u prvního způsobu. Další výhodou je, že při výpadku centrálního serveru bude stále možné zaznamenávat naměřená data. 21

22 Vzhledem k požadavkům (dostatečná škálovatelnost a krátký interval měření), je nutné zvolit metodu duplicitního uložení dat. Nasbíraná data na měřeném serveru budou sloužit ke dvěma účelům: a) Dočasná záloha při výpadku hlavního serveru b) Centrální server nemusí stahovat data v reálném čase, ale pouze v určitých intervalech (např. po 5-10 minutách) Z výše uvedených bodů vyplývá, že není nutné uchovávat na měřeném serveru celou historii dat, ale stačí uchovávat pouze data zpětně za několik dní (čas, po který může být centrální server nedostupný) Způsob ukládání naměřených dat Naměřená data tedy bude nutné ukládat na centrální (Shel-Master) i na měřený server (Shel-Node). Nic však nebrání tomu, aby byl způsob uložení dat pro Shel-Master a Shel-Node odlišný. Při ukládání dat postačí pouze dvě hodnoty čas měření (unix timestamp 5 ) a naměřená hodnota. Možností, jak ukládat nasbíraná data, je několik a jsou popsány v následujících odstavcích. Každý způsob má své výhody a nevýhody Textové / XML / binární soubory Výhodou tohoto řešení je, že nebude potřeba instalovat další software. Bude však nutné implementovat rozhraní pro čtení a zápis dat. Jak již bylo uvedeno výše, data na měřeném serveru stačí uchovávat jenom pár dní, proto bude nutné zajistit rotování dat. 5 Unix timestamp je způsob jak uložit datum a čas jako jediné číslo. Jde o počet sekund od :00:00 UTC. 22

23 Relační databáze Oproti textovým souborům nepřináší databáze na první pohled žádné výhody. Opět bude nutné vyřešit rotování dat, navíc databázový systém je pro tento účel zbytečně komplexní a zbytečně by se musel instalovat na systémy, kde není potřeba. Výhodou je snadný výběr dat pomocí jazyka SQL. Kostra ER modelu datového úložiště by mohla vypadat podobně jako na Obr. 7. K uchovávání dat se použijí tři tabulky. Tabulka servers, kde je uložen seznam měřených serverů, tabulka sensors, kde je výčet měřených senzorů (veličin) a poslední tabulka values,, která obsahuje cizí klíče odkazující na tabulku serverů a senzorů a dále čas měření a naměřenou hodnotu. Obr. 7 - ER model dat. Úložiště Předpokládejme, že data jsou ukládána v intervalu pěti sekund. Chceme zobrazit graf v rámci delšího časového úseku a požadujeme jednu hodnotu za 100 sekund (agregace - zprůměrování 20-ti hodnot na jednu). Zároveň požadujeme zobrazení i maximálních a minimálních hodnot. SQL dotaz pro výběr dat by vypadal následovně: SELECT (Time / 100)*100 AS t, AVG(value), MAX(value), MIN(value) FROM time GROUP BY t RRD databáze RRD databáze neboli Round Robin Database jsou speciální soubory, které slouží k uchovávání série časových údajů - tedy to, co potřebujeme. eme. Nevýhodou je opět instalace dalšího software. Ten je však snadno dostupný jak pro Linux, tak i Solaris, AIX a další. 23

24 Data jsou uložena v tzv. Round-robin archivu. V jednom RRD souboru může být těchto archivů několik. Při jeho vytváření se definuje, v jakých intervalech se mají data ukládat (průměrovat). Při zapisování se tato data cyklicky přepisují (odtud název Round-Robin). Pokud tedy nastavíme velikost archivu na 7 dní, vyřeší se tím problém rotování dat. Cyklické přepisování má výhodu v tom, že velikost RRD souboru se od jeho vytvoření v průběhu času nezmění. Pro manipulaci s RRD soubory slouží nástroj rrdtool, který umožňuje vkládání a výběr dat. Vkládání dat do RRD souboru pak vypadá například takto: rrdtool update file.rrd time1:x time2:y time3:z Čtení dat: rrdtool fetch file.rrd AVERAGE resolution start time1 end time Způsob ukládání dat pro Shel-Node Na měřeném serveru se bude jednat o relativně malé množství dat (vzhledem k velikosti pevných disků stovky GB). Doba uchovávání dat Minimální interval měření Velikost časová značky Velikost naměřené hodnoty 7 dní 5s 8B 8B Počet senzorů (veličin) 50 Tabulka 1 Odhad množství ukládaných dat na Shel-Node Pokud budou ukládána data po dobu sedmi dní a minimální interval měření je 5s, jde o cca hodnot pro jednu veličinu. Pro 100 senzorů po 16B vychází celkový zabraný prostor na disku na cca 90MB. Toto číslo je velmi nadsazené, protože u většiny senzorů bude postačovat interval měření desetinásobný. 24

25 Zvolit SQL variantu a instalovat databázový systém na měřený server, který může sloužit pouze jako poštovní nebo webový server, není vhodné řešení. Vzhledem ke snadnosti použití a žádnému omezení bude zvoleno ukládání dat do RRD souborů Způsob ukládání dat pro Shel-Master Na centrálním serveru bude nutné uchovávat obrovské množství dat. Zároveň je nutné zajistit co nejkratší dobu pro ukládání a výběr dat. Pevné disky dosahují velkých kapacit a není problém vytvořit pole o velikosti několika TB. Limitem bude spíše množství dat, které bude nutné zpracovávat a ukládat v reálném čase. Data se budou periodicky (např. v intervalu 5-10 minut) stahovat z měřených serverů na centrální 6. Vezmeme-li v úvahu cca 50 měřených hodnot na server, interval měření od pěti sekund, velikost ukládaných dat 16B a systém bude nasazen v hostingové společnosti, která spravuje cca 200 serverů. Jednoduchým vynásobením výše uvedených čísel dostaneme 72GB dat, které bude nutné ukládat každý měsíc. Na Shel-Master serveru se bude provádět vykreslování grafů a zpracování naměřených dat, proto by se hodila flexibilita jazyka SQL, tedy uložení dat do relační databáze. Vzhledem k tomu, že databázový systém musí při ukládání dat počítat s integritními omezeními, transakcemi a podobně, bude rychlost v porovnání s RRD soubory pravděpodobně mnohem menší. Provedeme tedy výkonnostní srovnání obou přístupů. Pro otestování rychlosti relační databáze byl zvolen open-source databázový systém PostgreSQL. Byla vytvořena tabulka s náhodně vygenerovanými daty o velikosti cca 30 miliónů záznamů 7. 6 Proces stahování dat je podrobně popsán v kapitole Stahování dat z měřených serverů 7 Pro zajímavost spočítání řádků v této tabulce trvalo přes 40 sekund tento údaj však nevypovídá nic o rychlosti výběru dat 25

26 Tabulka 2 Srovnání rychlosti SQL a RRD 8 V tabulce číslo 2 je uveden přehled naměřených časů pro SQL a RRD variantu (měření bylo provedeno 10 krát a výsledné hodnoty jsou vypočteny aritmetickým průměrem). Měřen byl čas vložení 1000 hodnot a výběr dat v časovém úseku dvou hodin. Z výsledků je vidět, že RRD je v operaci insert více než 22 krát rychlejší než SQL varianta. Při výběru dat je RRD cca 4 krát rychlejší. Ve spodní části tabulky jsou pro přehlednost časy převedeny na počet operací za sekundu. 1. Varianta PostgreSQL databázový systém a) Výhody: téměř neomezené možnosti při výběru dat b) Nevýhody: řádově pomalejší vkládání 2. Varianta RRD soubory a) Výhody: rychlost b) Nevýhody: horší možnosti vybírání dat (lze kompenzovat na aplikační úrovni) Pokud vezmeme v úvahu data ukládaná po pěti sekundách, 50 senzorů na server a interval stahování dat na centrální server 5 minut, vychází nutnost uložit 3000 hodnot pro jeden server. V SQL variantě bude trvat uložení cca 30 sekund (dle tabulky č. 2 cca 100 operací za sekundu). To znamená omezení počtu serverů na 10. Z tohoto jednoduchého výpočtu vyplývá, že použití SQL varianty pro ukládání dat je při nasazení systému na větší množství serverů nemožné. 9 Stejně jako pro Shel-Node je tedy zvoleno ukládání dat pro Shel-Master do RRD souborů. 8 Měření bylo prováděno na poměrně starém serveru s HW konfigurací: P4 2,8Ghz, 2GB RAM DDR, PATA disky 9 Tento výpočet je značně zjednodušený průměrný interval měření nebude 5 sekund, ale několikrát vyšší. Měření rychlosti bylo prováděno na poměrně starém HW. Zároveň je však nutné brát zřetel na to, že server není určen pouze k ukládání dat, ale bude také vykreslovat grafy a podobně. 26

27 4.5. Přidávání nových pluginů na měřený server Dle požadavků v úvodní části by měl systém obsahovat rozhraní pro přidávání dalších měřených veličin (pluginů). To lze řešit dvěma způsoby: 1. Kód nového pluginu se nahraje na měřený server a ihned se spustí. 2. Kód už bude na měřeném serveru a pouze se pošle příkaz ke spuštění. Výhodou prvního způsobu je především jednoduchost a možnost okamžitého měření nových veličin. Z bezpečnostního hlediska však nejde o nejvhodnější řešení. Pokud by se někomu podařilo odesílaný kód změnit (Man in the middle 10 ), mohlo by dojít k narušení bezpečnosti, nebo ztrátě dat na měřeného serveru. Výše uvedený bezpečnostní problém řeší druhý způsob. Kód pro měření je již umístěný na měřeném serveru a nemůže ho tedy nikdo změnit. Měřící kódy mohou být součástí zdrojových kódů (Shel-Node) a jejich rozšiřování a aktualizaci zajistí balíčkovací systém, který je dostupný na většině unixových systémů. Integritu měřících kódů zajistí digitální podpis balíku. Nevýhodou je nutnost aktualizovat balík při přidávání nového pluginu. Toto je však obecný koncept, kdy při požadavku na další funkce software se musí provést jeho aktualizace. Z bezpečnostních důvodů bude preferován druhý způsob přidávání pluginů. Bude se tedy zasílat pouze příkaz o zapnutí daného pluginu Komunikace mezi Shel-Master a Shel-Node Komunikaci mezi centrálním a měřeným serverem lze rozdělit do dvou kategorií. Komunikace bude uskutečněna skrze společnou ethernetovou síť. Prvním typem komunikace je žádost centrálního serveru o zaslání nově nasbíraných dat a druhým jsou řídící příkazy, jako je například aktivování měření dalších veličin, zjištění počtu síťových rozhraní nebo nahlédnutí do logovacího souboru. Jakým způsobem tedy zajistit vzájemnou komunikaci? Existuje samozřejmě několik možností, přičemž nic nebrání tomu, aby se data stahovala jiným způsobem, než budou probíhat řídící příkazy. 10 Man in the middle, neboli člověk uprostřed je způsob útoku, kde útočník odposlechne komunikaci mezi účastníky a stane se aktivním prostředníkem. 27

28 Vlastní protokol Řešení komunikace pomocí vlastního protokolu je nejsložitější. Bude nutné zajistit šifrování komunikace a autentizaci. Na měřeném serveru by musela běžet aplikace, která bude například poslouchat na určitém portu a umožní komunikaci s centrálním serverem SSH Protokol SSH přináší mnoho výhod, i když nebyl navržen pro takovýto typ komunikace. SSH je dostupné na všech unixových systémech, nebude tedy nutné instalovat další software. Dále je vyřešeno šifrování a autentizace. Nevýhodou je, že pokud někdo získá přístup na centrální server, dostane tak přístup i na všechny měřené servery XML-RPC / SOAP Nevýhodou je instalace XML-RPC případně SOAP serveru na měřený server. K tomu může posloužit například webový server Apache, ale ne na každém serveru je Apache nainstalován. Také bude nutné vyřešit zabezpečení komunikace SNMP SNMP, neboli Simple Network Management Protocol je protokol, který slouží pro správu a monitorování síťových prvků. Umožňuje zasílat monitorovanému zařízení SNMP dotazy. Zařízení odpoví na základě přijatého OID 11 hodnotou. Vzhledem k požadovanému minimálnímu intervalu a řídících příkazů (zobrazování logovacího souboru) není SNMP příliš vhodné. Z výše uvedených možností komunikačních protokolů bude vybráno SSH. Na každém monitorovaném zařízení bude vytvořen speciální uživatel shel. Přihlašování z centrálního serveru bude zajištěno pomocí RSA klíče. Nevýhodou je shell přístup na měřený server (i když se nejedná o superuživatele). Tuto nevýhodu lze odstranit velmi 11 OID je posloupnost čísel oddělená tečkou, které jednoznačně identifikují měřený parametr. 28

29 jednoduše, a to nastavením tzv. login skriptu 12 místo shellu. Login skript (Command skript) bude umožňovat ovat provedení pouze předem definovaných akcí, jako např. stažení dat, zobrazení logu apod. Tímto způsobem se dá velmi jednoduše výrazně zvýšit bezpečnost komunikace. Případný útočník, který by získal přístup na centrální server, by mohl z jednotlivých serverů maximálně stáhnout naměřená data, případně aktivovat měření dalších pluginů/senzorů. Ať už z důvodu budoucího rozšíření, nebo osobních preferencí správce měřeného serveru, by měl systém umožňovat přidání dalších protokolů pro komunikaci a to jak individuálně ě pro jednotlivé servery, tak i pro daný typ komunikace (stahování dat nebo řídicí příkazy) Shel-Node Úkolem Shel-Node bude v definovaných intervalech měřit informace o činnosti serveru a lokálně je zaznamenávat. Musí také umět zpracovávat příkazy Shel-Master serveru. Tedy poskytnout naměřená data, případně začít/přestat měřit danou veličinu. Komponenty Shel-Node jsou zobrazeny na Obr. 8. Obr. 8 - Komponenty Shel-Node Jak již bylo uvedeno v kapitole 4.3, měřená data se budou lokálně ukládat do RRD souborů. Samotné měření hodnot budou zajišťovat měřící skripty (pool skripty), což bude úsek kódu ve skriptovacím jazyce (např. bash nebo Perl), který zajistí odečítání a ukládání hodnot do RRD souborů. Vzhledem k tomu, že se bude jednat o poměrně velké množství měřených hodnot (50 i více), bude vhodné rozdělit měření na několik nezávislých skriptů. Jeden bude měřit údaje o procesoru a jiný zase o databázi. Výhodou tohoto rozdělení je, že 12 Tento skript se spustí ihned po přihlášení uživatele místo klasického shell interpreteru (např. bash). 29

30 pokud nebude v daném okamžiku možno odečíst údaje např. o databázi (nedostupnost databázového serveru), všechny ostatní data bude možné i nadále zaznamenávat. Měřená data by bylo vhodné určitým způsobem hierarchicky rozdělit. Byla tedy navržena následující struktura. Nejvyšší úrovní bude kategorie pluginů (pro každou bude samostatný měřicí skript), který bude zajišťovat měření např. MySQL databáze. Kategorie pluginů bude rozdělena na pluginy. Příkladem pluginu bude (vzhledem k výše zmíněné MySQL) využití cache nebo počet dotazů za jednotku času. Samotný plugin bude dále rozdělen na senzory. Každý senzor bude představovat jednu měřenou hodnotu. Vzhledem k počtu dotazů bude mezi senzory patřit např. počet update nebo insert dotazů. Výsledkem je tedy následující rozdělení: kategorie pluginů > plugin > senzor. Otázkou tedy zůstává, jakým způsobem zajistit nepřetržitý běh všech pool skriptů. Tento problém lze řešit opět několika způsoby. Je třeba počítat s tím, že se může bezdůvodně ukončit (výše zmíněná nedostupnost databáze apod.). Proto by bylo nevhodné skripty pouze spustit při startu systému. Problém lze vyřešit jedním z následujících způsobu: a) Cron tabulka je Linux/Unix systémový nástroj, který umožňuje spouštět příkazy v předem definovaných intervalech. Je však navržen pro spouštění v minimálním intervalu jedna minuta, což vzhledem k minimálnímu požadovanému intervalu 5s nestačí. I kdyby to však bylo možné, režie při tak malém intervalu spouštění by byla příliš velká. Tento nedostatek lze obejít tím, že skript bude měření provádět ve smyčce, která potrvá určitý interval např. 5 nebo 10 minut. Cron pak zajistí spouštění v tomto intervalu. Zbývá tedy zaručit přesnou dobu běhu skriptu, což lze zajistit odečtením doby samotného měření a dopočítáním času čekání. Cron pak zajistí, že při pádu skriptu bude opět spuštěn. Toto řešení je poměrně jednoduché. b) Démon 13 další možností je použít démona, který zajistí spuštění a nepřetržitý běh všech pool skriptů. Pokud některý ze skriptů neočekávaně skončí, démon zaručí jeho opětovné spuštění. Démon se při svém ukončení postará také o ukončení všech pool skriptů. 13 Démon je označení programu, který je spuštěn obvykle při startu operačního systému a není v přímém kontaktu s uživatelem. Démon běží na pozadí a zpracovává požadavky od systému. 30

31 Jak bylo naznačeno výše, všechny měřící kódy budou uloženy na měřeném serveru a budou součástí balíku a jejich rozšíření bude možné pouze při jeho aktualizaci. Dále bude nutné mít uložené informace o tom, co se na daném serveru má měřit. Na základě těchto dat budou generovány jednotlivé pool skripty. Konkrétní způsob uložení dat a generování skriptů bude popsán v implementační části Shel-Master Shel-Master server bude tvořit jádro celého systému. Bude sloužit jako centrální úložiště nasbíraných dat, dále na něm poběží webová aplikace, pomocí které se bude systém ovládat a bude umožňovat zobrazit nasbíraná data ve formě grafů. Jednotlivé komponenty Shel-Master serveru jsou zobrazeny na následujícím obrázku. Obr. 9 - Komponenty Shel-Master Databáze Důležitou částí Shel-Masteru je databáze. V té bude uložen seznam měřených serverů, seznam pluginů, které jsou aktivovány na jednotlivých serverech, uživatelé a jejich práva, definice jednotlivých grafů a mnoho dalších informací. Zjednodušené schéma databáze je na Obr

32 Obr Schéma databáze pro Shel-Master 14 V tabulce servers je uložen seznam měřených serverů. Ke každému serveru jsou přiřazeny jednotlivé pluginy a senzory, které se na daném serveru měří. V tabulce graphs je definice jednotlivých grafů. Každý graf je definován seznamem senzorů, které zobrazuje, popisky os a rozměry. Další části schématu jsou podrobně rozebrány v kapitole 4.9 Webová aplikace. Ke každému pluginu jsou přiřazeny měřící kódy (tabulka measure_codes). Pro každý operační systém (případně konkrétní verzi jádra) může být měřící kód odlišný. Proto je v databázi uložen i údaj, ke kterému operačnímu systému daný kód patří, dále verze jádra, případně konkrétní typ distribuce. Každý plugin bude mít určitý výchozí (default) měřící kód. Při exportování měřících kódů pro další typ operačního systému by se postupovalo tak, že by se systém pokusil vybrat kódy přesně pro daný typ operačního sytému. Pokud by některé kódy chyběly (například by byly dostupné pro jinou verzi jádra), pokusil by se vybrat výchozí kódy pro daný systém. Pokud by nebyly ani ty, vybral by úplně obecné kódy. Výsledkem výše uvedeného sestupného modelu by byly nejlepší možné dostupné kódy. Ty by se nainstalovaly na měřený server. V případech, kde by měření selhalo, by se kódy upravili pro daný operační systém a přidaly do databáze. Pomocí tohoto postupu by se poměrně snadno rozšiřovala ovala podpora pro další operační systémy. 14 Pro přehlednost jsou zobrazeny pouze jednotlivé tabulky a vztahy mezi nimi, bez jednotlivých atributů. Kompletní schéma je uvedeno v příloze, 32

33 Datové úložiště Data na centrálním serveru se budou ukládat do RRD souborů (viz kapitola 4.4). Vzhledem k počtu měřených serverů a počtu senzorů na server se bude jednat o poměrně velké množství souborů. RRD soubory se tedy rozdělí do složek a to následujícím způsobem: Cesta_k_úložišti/server/kategorie/plugin/senzor.rrd Pro každý senzor tedy bude zvláštní RRD soubor Stahování dat z měřených serverů Data z měřených serverů se budou periodicky stahovat na centrální server. Stahovat se budou pouze nově naměřená data, proto by bylo zbytečné, stahovat celé RRD soubory. Zabalením dat do XML by zbytečně narostl jejich objem, proto bude zvolen vlastní jednoduchý formát, který se bude podobat výstupu příkazu rrdtool fetch. Vzhledem k tomu, že se budou grafy vykreslovat z dat na centrálním serveru, je nutné dodržet relativně krátký interval stahování dat. Dle počtu měřených serverů bude vhodné zvolit cca 1 až 10 minut. Pravidelné spouštění stahování dat zajistí cron. Proces stahování je zobrazen na následujícím obrázku. Nejprve bude nutné načíst z databáze seznam serverů, ze kterých se budou stahovat data. Na daný server se poté odešle seznam senzorů a čas jejich poslední aktualizace. Měřený server na základě těchto údajů vrátí nasbíraná data, ty se poté uloží do centrálního úložiště. 33

34 Obr Proces stahování dat 4.9. Webová aplikace Důležitou částí bude webová aplikace, která představuje výstup celého systému. Rozhraní bude umožňovat provádět tyto akce: a) Zobrazování grafů z naměřených hodnot b) Konfigurace měření na jednotlivých serverech c) Správa grafů d) Správa pluginů ů a měřících kódů Základní rozvržení prvků stránky je na Obr. 12. V levém horním rohu je logo, pod kterým je vodorovně ě umístěné hlavní menu, které určuje rozdělení webu do hlavních sekcí. Pod menu je umístěná tzv. drobečková navigace 15, která umožňuje přejít na jakoukoliv stránku v cestě na jediné kliknutí. Navigace na stránce s konkrétním grafem může vypadat například takto: Hlavní stránka > měřený server > kategorie grafů > konkrétní graf. Na hlavní části stránky budou zobrazeny grafy, případně ě formuláře pro konfiguraci měřených serverů. Na konci stránky bude zobrazena standardní patička. 15 Drobečková navigace znázorňuje pozici aktuální stránky v hierarchii webu nezávisle na cestě, po které se na ni uživatel dostal. 34

35 Obr Rozvržení webového rozhraní I přesto, že výstupem jsou pouze grafy o využití serveru, jsou obecně tato data považována za důvěrná, proto je nutné zajistit autorizaci a autentizaci uživatelů. Každý uživatel by měl mít přístup pouze do těch částí, se kterými bude pracovat. Proto je nutné rozdělit uživatele do skupin, které bývají zpravidla hierarchicky provázané. Na Obr. 13 jsou zobrazené jednotlivé skupiny uživatelů včetně nejdůležitějších jších akcí, které budou typicky vykonávat. Obr Uživatelské role a základní případy užití 35

36 Jsou zde definovány tři typy uživatelů. Prvním typem uživatele je majitel serveru, kterému běží na měřeném serveru služby. Pravděpodobně jde o nějakého manažera. Ten má povoleno pouze zobrazování grafů, případně definici vlastních grafů. Tato skupina by se mohla dále rozdělit na konkrétní uživatele, kteří mají možnosti zobrazovat grafy konkrétních serverů. Další skupinu tvoří administrátoři serverů, kteří mají stejná práva jako manažeři. Dále mohou určovat, jaké pluginy a senzory budou měřeny na jednotlivých serverech a přidávat další měřené servery. Posledním typem uživatele je správce systému. Jeho úkolem bude bezproblémový provoz celého systému a správa uživatelů, dále bude vytvářet nové pluginy a spravovat měřící kódy Zobrazování a správa grafů Naměřené hodnoty z jednotlivých serverů je nutné určitým způsobem interpretovat. K tomu se hodí nejlépe grafy, kde na ose x je vynesen čas a na ose y daná měřená hodnota. V jednom grafu může být zobrazeno více měřených veličin (senzorů), které se odliší barvou. Stejně jako byly jednotlivé pluginy rozděleny do kategorií, budou rozděleny pro přehlednost podobně i grafy. U konkrétního serveru a typu grafu se zobrazí na stránce graf za poslední hodinu, den, týden a rok. Dále bude možnost určit konkrétní časový úsek (od-do) pro zobrazení grafu. Typicky bude definován pro každý plugin jeden graf. Bude zde však možnost definovat další grafy, které budou zobrazovat senzory nezávisle na tom, z jakého jsou pluginu. Grafy pak bude možné přiřadit k vybraným serverům, to umožní zobrazit si v jednom grafu například počet běžících procesů Apache a využití CPU, což může usnadnit analýzu incidentů. Při definici nového grafu bude muset uživatel zadat název grafu, kategorii a případně rozměry. Dále bude muset určit, zda půjde o tzv. Stacked graf. Tedy jestli se dané veličiny v grafu budou překrývat, nebo se budou sčítat a skládat nad sebe. Poté bude muset přiřadit k novému grafu jednotlivé senzory. U každého senzoru definuje barvu, zda se bude jednat pouze o čáru, nebo vyplněnou plochu (Line/Area) a také prioritu senzoru. Priorita určuje pořadí při překreslování jednotlivých senzorů a u stacked grafů pořadí skládání senzorů na sebe. 36

37 Konfigurace měřených hodnot U každého serveru bude možno přímo z webového rozhraní určovat, jaké pluginy resp. senzory se budou měřit. Vzhledem k tomu, že měřící kódy jsou uloženy na měřeném serveru již při instalaci resp. aktualizaci balíku, musí být v databázi u každého serveru uložena verze balíku Shel-node. Poté bude možno přiřadit řadit k serveru pouze ty pluginy, které jsou v dané verzi dostupné. Obr Datový model pro senzory a pluginy Na Obr. 14 je zobrazena část datového modelu, kde je zaznamenáno, co se bude na jednotlivých serverech měřit. Pro každý server bude v databázi uložen seznam senzorů, kde každý senzor patří k právě jednomu pluginu. Dále je nutné mít i informaci o tom, jaké pluginy jsou přiřazeny ke konkrétnímu serveru. Tím vzniká v databázovém modelu cyklus, který bude nutné ošetřit na aplikační úrovni. Vztah mezi pluginem a serverem je nutný kvůli pluginům, kde není předem znám počet senzorů. Jde například o plugin, který měří obsazení jednotlivých oddílů pevného disku, nebo měření datového toku na síťových rozhraních. Při přiřazování takového pluginu k serveru není znám konkrétní počet oddílů nebo síťových rozhraní. Takovéto pluginy budou v textu dále označovány ovány jako tzv. multiple pluginy. Pokud bude chtít uživatel měřit na serveru další veličiny, iny, jednoduše si pomocí formuláře přidá jednotlivé senzory a pluginy a systém se postará o vytvoření RRD souborů na centrálním i měřeném serveru a zajistí vygenerování a spuštění měřících kódů. Celý proces bude detailně popsán v implementační části. 37

38 Přidávání nových pluginů Jak již bylo zmíněno v předchozích kapitolách, jednotlivé měřící kódy jsou uložené přímo na měřeném serveru, kam se nahrají při instalaci, resp. aktualizaci. Aby bylo možné měřící kódy určitým způsobem spravovat, musí být uložené i na centrálním serveru. Pro uložení by stačily obyčejné textové soubory, ale kvůli již zmíněnému systému výběru kódu pro daný operační systém bude mnohem vhodnější uložit kódy přímo do databáze. Konkrétně do tabulky measure_codes, viz Obr. 14. Přidat nový plugin bude možné přímo z webového rozhraní pomocí formuláře. Uživatel bude muset definovat kromě samotného měřícího kódu také kategorii pluginů a periodu měření. Samotný měřící kód musí obsahovat vhodně pojmenované proměnné, které budou uchovávat požadované měřené hodnoty. K nově přidanému pluginu bude poté nutné přidat jednotlivé senzory. U každého senzoru definuje uživatel k jakému pluginu patří a jméno proměnné, která obsahuje požadovanou měřenou hodnotu. Aby bylo možné aplikovat nový plugin na měřený serveru, je nutné aktualizovat instalační balíček, který se poté nainstaluje na měřený server. 38

39 5. Implementace V úvodu této kapitoly je popsána volba programovacího jazyka, databázového systému a vývojového prostředí. Dále je zde popsána na základě předchozí analýzy implementace všech částí systému. Jde o implementaci webové aplikace, centrálního (Shel-Master) a měřeného (Shel-Node) serveru a jejich vzájemné komunikace. Implementace všech částí systému byla odladěná a otestovaná na operačním sytému Debian GNU/Linux, pro který byl také vytvořen instalační balíček Shel-node Volba použitých technologií Volba konkrétní použité technologie (programovacího jazyka) může usnadnit nebo naopak zvýšit náročnost celé implementace. V mnoha případech však bývá volba provedena na základě autorových preferencí. Vzhledem k nasazení systému v unixovém prostředí budou preferovány open source technologie. Systém se skládá z několika relativně nezávislých částí, a proto je nutné zvážit volbu dané technologie pro jednotlivé části zvlášť RRDTool Naměřená data se budou ukládat do RRD souborů, a to jak na měřeném, tak i na centrálním serveru. RRDTool, neboli round-robin database tool je nástroj pro práci s časovou řadou dat [5]. Umožňuje tato data ukládat do speciálních souborů, které se při zápisu cyklicky přepisují. Výhodou tohoto řešení je, že soubory od vytvoření nemění svoji velikost a nemůže tak dojít během provozu k nepředpokládanému zaplnění pevného disku. Nástroj umožňuje nejen data z RRD souborů číst, ale také vykreslovat grafy. Data se ukládají v RRD souborech do tzv. archivů. Každý archiv slouží k ukládání v jiném časovém rozlišení. Například můžeme vytvořit RRD soubor se třemi archivy, který bude uchovávat data za poslední den po 5 sekundách, za poslední měsíc po 60 sekundách a za poslední rok po dnech (86400 sekund). Čas se v RRDTool ukládá jako Unix Timestamp. RRD soubor lze vytvořit pomocí příkazu rrdtool create. Syntaxe příkazu je následující: 39

40 rrdtool create filename [--start -b start time] [--step -s step] [DS:ds-name:DST:dst arguments] [RRA:CF:cf arguments] rrdtool create temperature.rrd --start step=300 DS:temperature:COUNTER:600:U:U RRA:AVERAGE:0.5:1:24 RRA:AVERAGE:0.5:6:10 Výše uvedený příklad vytvoří soubor temperature.rrd. Data se budou ukládat v intervalu 300 sekund. Databáze bude obsahovat jeden zdroj dat, který je pojmenovaný temperature a je typu COUNTER. Jednotlivé typy jsou uvedeny v tabulce číslo 3. Dále jsou vytvořeny dva archivy (RRA - round robin archive). V prvním archivu se ukládají přímé hodnoty (24 vzorků, tj. 24 * 5 minut = 2 hodiny). V druhém se agregují (průměrné hodnoty - AVERAGE, viz tabulka číslo 4) z šesti vzorků (6 * 5 minut = ½ hodiny) a ukládá se 10 hodnot, tedy data za posledních 5 hodin. GAUGE Uchovávání okamžité hodnoty - teplota COUNTER Pro neustále se zvyšující čítače odeslané bajty DERIVE Stejné jako COUNTER, ale bez kontroly přetečení ABSOLUTE Pro COUNTER, který se nuluje při čtení COMPUTE Pro ukládání výsledků výpočtu hodnot z jiných zdrojů dat AVERAGE MIN MAX LAST Tabulka 3 - Datové typy Průměrná hodnota Minimální hodnota Maximální hodnota Poslední hodnota Tabulka 4 - Způsob agregace - consolidation function Pro zápis do RRD souboru slouží příkaz rrdtool update. Zápis naměřené teploty do souboru temperature.rrd v definovaný čas se provede následovně: rrdtool update temperature.rrd :20.3 Pro čtení dat z RRD databáze se používá příkaz rrdtool fetch. Pokud chceme načíst naměřené hodnoty ze souboru temperature.rrd v definovaném intervalu a požadujeme zprůměrovaná data, použijeme níže uvedený příkaz. RRDTool se postará o zvolení nejvhodnějšího archivu pro poskytnutí požadovaných dat. rrdtool fetch temperature.rrd AVERAGE --start end

41 Pro vytváření grafů slouží příkaz rrdtool graph. Níže uvedený příklad vytvoří soubor temparature.png, který zobrazí graf teploty v požadovaném čase. Hodnoty pro vytvoření grafu budou načteny ze souboru temparature.rrd. Teplota bude zobrazena jako zelená čára o tloušťce 2 pixely. rrdtool graph temperature.png --start end DEF:temp=temparature.rrd:temperature:AVERAGE LINE2:temp#FF Použité technologie pro Shel-master Úkolem Shel-master serveru je periodicky stahovat data z měřených serverů a ukládat je do RRD úložiště. Dále musí zajistit veškerou komunikaci s měřeným serverem. Použitý programovací jazyk musí umět pracovat s RRD soubory a komunikovat přes síť s měřeným serverem přes SSH (je nutné počítat do budoucna i s dalšími protokoly jako např. SOAP). RRDTool byl implementován v několika jazycích, většinou jde o skriptovací jazyky. Například bash, perl, php ale i C. Pro implementaci Shel-master serveru byl zvolen Perl. Perl [1] je interpretovaný programovací jazyk, který vytvořil Larry Wall v roce Jazyk byl původně navržen pro zpracování textů a téměř definoval standard pro regulární výrazy. Od verze 5 umožňuje perl také objektově orientované programování. Kolem jazyka vznikla obrovská komunita, rozsáhlá dokumentace a tisíce volně dostupných modulů. Mezi nevýhody patří mnoho způsobů zápisu i základních konstruktů jazyka. Zdrojový kód se pak stává velmi snadno obtížně čitelný Použité technologie pro Shel-node Úkolem Shel-Node je v definovaných intervalech měřit informace o činnosti serveru, zaznamenávat je do RRD souborů a reagovat na příkazy od centrálního serveru. Vzhledem k tomu, že kódy pro měření se generují na základě požadavků od Shel-master serveru, bude vhodné použít skriptovací jazyk. Perl bude v tomto případě opět vyhovovat. 41

42 Použité technologie na webovou aplikaci Při vývoji webových aplikací se používá v součastné době velké množství programovacích jazyků. Mezi nejpoužívanější patří PHP,.NET a J2EE v kombinaci s mnoha dostupnými Frameworky 16. Všechny využívají podobného principu. Na základě požadavku od klienta vygenerují stránku, kterou odešlou ve formě (X)HTML kódu webovému prohlížeči. Pro úpravu vzhledu stránek se používá výhradně CSS..NET není dostupný na unixovém prostředí, zbývá tedy volba mezi PHP a J2EE. Jazyk musí opět umět pracovat s RRD soubory, protože zde bude realizováno generování grafů. RRDTool byl implementován jak v PHP, tak i v Javě. Vzhledem k tomu, že J2EE se hodí spíše pro rozsáhlé systémy, bylo zvoleno PHP, díky obrovskému rozšíření a komunitě. Pro usnadnění práce bude použit Zend Framework [2][3]. Jako webový server je použit Apache. PHP (PHP: Hypertext Preprocessor) je skriptovací jazyk určený pro vytváření dynamických webových stránek. PHP umožňuje pracovat s databázemi, s velkým množstvím internetových protokolů (IMAP, POP3, SMTP), dokáže vytvářet obrázky a PDF soubory. V současné době se používá verze 5, která přinesla kompletní podporu objektově orientovaného programování. Pro PHP bylo napsáno velké množství Frameworků. Mezi nejúspěšnější patří Zend Framework, který pochází přímo od společnosti Zend a podílí se na něm více než 300 vývojářů. Framework je napsaný kompletně metodou objektově orientovaného programování s využíváním návrhových vzorů. Jedná se o tzv. MVC (model-viewcontroll) Framework. MVC je softwarová architektura, která rozděluje datový model aplikace (model), uživatelské rozhraní (view) a řídicí logiku (controll) do tří nezávislých komponent tak, že modifikace některé z nich má minimální vliv na ostatní. K Frameworku je dostupná rozsáhlá dokumentace s příklady. Framework je rozdělen na několik desítek komponent, které lze používat i samostatně. Každá komponenta řeší konkrétní úlohu, která se typicky objevuje ve většině webových aplikací. Například Zend_Db umožňuje komunikaci s databází, Zend_Auth autorizaci uživatelů a Zend_Form snadné odesílání a validaci formulářů. 16 Framework je softwarová struktura, která má za úkol řešit typické problémy, se kterými se vývojář setkává při práci. Vývojář se tak může soustředit více přímo na svoji konkrétní aplikaci. 42

43 Framework řeší například vytváření PDF dokumentů, práci s webovými službami, správu uživatelských oprávnění a jazykovou lokalizaci. Použití Frameworku přináší mnoho výhod. Nejdůležitější výhodou je, že programátorovi odpadá nutnost řešit typické problémy, ale může se zaměřit přímo na svoji konkrétní aplikaci. Pokud programátor používá doporučené postupy a metody, je jeho kód čitelnější a snadno rozšiřitelný. Mezi nevýhody patří počáteční časová investice pro nastudování Frameworku a mírné snížení výkonnosti zpracování skriptů Použité technologie Databázový systém Pro uchování seznamu měřených serverů, pluginů, senzorů, uživatelů systému a dalších informací je nutné použít relační databázový systém. Mezi nejpoužívanější open source databázové systémy pro unixové prostředí patří MySQL, PostgreSQL a Firebird. Popisovaný systém neklade žádné speciální požadavky (jak funkční, tak výkonnostní) na databázový sytém, proto by mohl být zvolen jakýkoliv databázový sytém z výše uvedených. Byl zvolen PostgreSQL Volba vývojového prostředí Implementace Shel-Master i Shel-Node byla realizována pomocí klasického unixového editoru vim. Práce s tímto editorem je sice ze začátku poněkud těžkopádná, ale po zvládnutí nejdůležitějších funkcí se stává práce velmi efektivní, bez nutnosti používat myš. Pro implementaci webové aplikace bylo zvoleno open source vývojové prostředí NetBeans. Toto IDE usnadňuje a urychluje vývoj aplikací vzhledem k obrovskému množství užitečných funkcí a snadnému přehlednému ovládání. NetBeans verze 6.5 má přímo podporu pro PHP, včetně HTML a CSS. Podporou je myšlena zvýrazněná syntaxe a tzv. Code Completion, což je nástroj pro automatické doplňování kódu. Nástroj zobrazí po zadání několika znaků možnosti, které chce uživatel pravděpodobně napsat. Tedy například výčet metod, které lze volat u daného objektu včetně možných parametrů a dokumentace. To je velmi výhodné při používání 43

Popis licencování, nastavení a ovládání replikací - přenosů dat

Popis licencování, nastavení a ovládání replikací - přenosů dat Popis licencování, nastavení a ovládání replikací - přenosů dat Ing. Martin Klinger 1.6.2016 Co jsou replikace? Sdílení dat, tzv. replikace najdou své uplatnění všude tam, kde je potřeba výměna dat v online

Více

VAR-NET INTEGRAL Manuál správce VNI 5.1 VAR-NET INTEGRAL. verze 0.2. Manuál správce VNI 5.1

VAR-NET INTEGRAL Manuál správce VNI 5.1 VAR-NET INTEGRAL. verze 0.2. Manuál správce VNI 5.1 Manuál správce VNI 5.1 verze 0.2 Manuál správce VNI 5.1 VARIANT plus, spol. s.r.o., U Obůrky 5, 674 01 TŘEBÍČ, tel.: 565 659 600 technická linka 565 659 655 (pracovní doba 7:30 15:00) www.variant.cz isb@variant.cz

Více

Databázový systém Matylda

Databázový systém Matylda Databázový systém Matylda Návrh softwarového projektu Vývojový tým Předpokládaný počet řešitelů: 5 Vedoucí: Mgr. Martin Nečaský Ph.D. Motivace V současné době se mnoho nákupů odehrává v internetových obchodech.

Více

Individuální projekt z předmětu webových stránek 2012 - Anketa Jan Livora

Individuální projekt z předmětu webových stránek 2012 - Anketa Jan Livora UŽIVATELSKÁ TECHNICKÁ DOKUMENTACE ANKETA : Individuální projekt z předmětu webových stránek 2012 - Anketa Jan Livora [2ITa] [sk1] 1 Obsah DŮLEŽITÉ UPOZORNĚNÍ!!!... 3 PROHLÁŠENÍ O AUTORSTVÍ:... 3 ANOTACE:...

Více

InTouch 8.0 Subsystém distribuovaných alarmů

InTouch 8.0 Subsystém distribuovaných alarmů InTouch 8.0 Subsystém distribuovaných alarmů Pavel Průša Pantek (CS) s.r.o. Strana 2 Obsah Úvod Úvod Subsystém distribuovaných alarmů Ukládání alarmů do relační databáze Zobrazování, potvrzování a potlačování

Více

LuxRiot uživatelský manuál verze 1.6.12. Uživatelský manuál Verze 1.6.12. -1-2008, Stasa s.r.o.,pokorného 14, 190 00, PRAHA

LuxRiot uživatelský manuál verze 1.6.12. Uživatelský manuál Verze 1.6.12. -1-2008, Stasa s.r.o.,pokorného 14, 190 00, PRAHA Uživatelský manuál Verze 1.6.12-1- 2008, Stasa s.r.o.,pokorného 14, 190 00, PRAHA LuxRiot je softwarový balík, určený pro sledování a ukládání dat z kamer. Umožňuje přijímat data z IP kamer a video serverů

Více

UŽIVATELSKÁ DOKUMENTACE PRO DODAVATELE. Stav ke dni 1. 8. 2013 v. 2.0

UŽIVATELSKÁ DOKUMENTACE PRO DODAVATELE. Stav ke dni 1. 8. 2013 v. 2.0 UŽIVATELSKÁ DOKUMENTACE PRO DODAVATELE Stav ke dni 1. 8. 2013 v. 2.0 Obsah: 1 Úvod... 3 1.1 Definice a zkratky... 4 1.2 Podmínky provozu... 4 1.3 Pokyny k užívání dokumentu... 4 1.4 Obecné informace o

Více

A7B39TUR Testování uživatelského rozhraní. HTC Desire HD. (testování mobilního zařízení) Tomáš Klejna klejntom@fel.cvut.cz

A7B39TUR Testování uživatelského rozhraní. HTC Desire HD. (testování mobilního zařízení) Tomáš Klejna klejntom@fel.cvut.cz A7B39TUR Testování uživatelského rozhraní HTC Desire HD (testování mobilního zařízení) Tomáš Klejna klejntom@fel.cvut.cz 20. 10. 2011 ČVUT v Praze Fakulta elektrotechnická 2 Obsah: Obsah... 2 Popis zařízení...

Více

BankKlient. FAQs. verze 9.50

BankKlient. FAQs. verze 9.50 BankKlient FAQs verze 9.50 2 BankKlient Obsah: Úvod... 3 Instalace BankKlient možné problémy... 3 1. Nejsou instalovány požadované aktualizace systému Windows... 3 2. Instalační program hlásí, že nemáte

Více

Studentská tvůrčí a odborná činnost STOČ 2015

Studentská tvůrčí a odborná činnost STOČ 2015 Studentská tvůrčí a odborná činnost STOČ 2015 PROGRAMOVATELNÝ PRVEK SYSTÉMU INTELIGENTNÍ DOMÁCNOSTI Lukáš SMOLKA Vysoká škola báňská Technická univerzita Ostrava 17. listopadu 15/2172 708 33 Ostrava-Poruba

Více

MLE2 a MLE8. Datalogery událostí

MLE2 a MLE8. Datalogery událostí MLE2 a MLE8 Datalogery událostí Zapisovač počtu pulsů a událostí Návod k obsluze modelů MLE2 MLE8 Doporučujeme vytisknout tento soubor, abyste jej mohli používat, když se budete učit zacházet se zapisovačem.

Více

software Ruční měřicí přístroje Zobrazovače / Regulátory Loggery / EASYBus GDUSB FastView EASYControl net EASYBus Configurator GSOFT 3050 GSOFT 40k

software Ruční měřicí přístroje Zobrazovače / Regulátory Loggery / EASYBus GDUSB FastView EASYControl net EASYBus Configurator GSOFT 3050 GSOFT 40k EBS 20M EBS 60M GMH 3xxx a GMH 5xxx EASYBus a EASYLog TLogg GDUSB 1000 GSOFT 3050 operační systémy Windows XP / 7 98 SE / 7 98 SE / 7 98 SE / 7 XP / 7 XP / 7 XP / 7 možnost použití více rozhraní současně

Více

SYSTÉM PRO KONFIGURACI KOMUNIKAČNÍCH TERMINÁLŮ A VIZUALIZACI STAVOVÝCH DAT Z KOLEJOVÝCH VOZIDEL

SYSTÉM PRO KONFIGURACI KOMUNIKAČNÍCH TERMINÁLŮ A VIZUALIZACI STAVOVÝCH DAT Z KOLEJOVÝCH VOZIDEL SYSTÉM PRO KONFIGURACI KOMUNIKAČNÍCH TERMINÁLŮ A VIZUALIZACI STAVOVÝCH DAT Z KOLEJOVÝCH VOZIDEL SYSTEM FOR CONFIGURATION OF COMMUNICATION TERMINALS AND VISUALIZATION OF STATE INFORMATION FROM RAIL VEHICLES

Více

Instalujeme a zakládáme databázi Oracle Database 11g

Instalujeme a zakládáme databázi Oracle Database 11g KAPITOLA 2 Instalujeme a zakládáme databázi Oracle Database 11g Protože se instalace systému Oracle s každou novou verzí zjednodušuje, stojí uživatel před pokušením otevřít krabici s médii a ihned začít

Více

Měření a vyhodnocování kvality elektrické energie zdroj úspor podniku. Ing. Jaroslav Smetana. Blue Panther s.r.o.

Měření a vyhodnocování kvality elektrické energie zdroj úspor podniku. Ing. Jaroslav Smetana. Blue Panther s.r.o. Měření a vyhodnocování kvality elektrické energie zdroj úspor podniku Ing. Jaroslav Smetana Blue Panther s.r.o. Co je kvalita energie? Vlastnosti elektrické energie - ideální stav: Stabilní frekvence (50

Více

Statistiky sledování televize

Statistiky sledování televize Statistiky sledování televize Semestrální práce (36SEM) ZS 2005/2006 Martin Fiala FEL ČVUT 5.ročník - 2 - Obsah 1. Úvod......4 1.1 Digitální vysílání......4 1.2 Převod přijímaného signálu na lokální síť...4

Více

10. Editor databází dotazy a relace

10. Editor databází dotazy a relace 10. Editor databází dotazy a relace Dotazy Dotazy tvoří velkou samostatnou kapitolu Accessu, která je svým významem téměř stejně důležitá jako oblast návrhu a úpravy tabulek. Svým rozsahem je to ale oblast

Více

Fides Card Reader 2.0.0.8

Fides Card Reader 2.0.0.8 Trade FIDES, a.s. Fides Card Reader 2.0.0.8 (aktualizace - 8/2015) Popis software Manuál technika systému 2 Fides Card Reader 2 Obsah 1 Popis produktu...4 1.1 Úvod...4 2 Instalace software...5 2.1 Nutné

Více

MANUÁL MOBILNÍ APLIKACE GOLEM PRO OPERAČNÍ SYSTÉM ANDROID 4.X A VYŠŠÍ

MANUÁL MOBILNÍ APLIKACE GOLEM PRO OPERAČNÍ SYSTÉM ANDROID 4.X A VYŠŠÍ MANUÁL MOBILNÍ APLIKACE GOLEM PRO OPERAČNÍ SYSTÉM ANDROID 4.X A VYŠŠÍ 1 OBSAH 1.Popis... 3 2.Ovládání aplikace...3 3.Základní pojmy... 3 3.1.Karta...3 3.2.Čtečka...3 3.3.Skupina...3 3.4.Kalendář...3 3.5.Volný

Více

Operační systémy (OS)

Operační systémy (OS) Operační systémy (OS) Operační systém Základní softwarové vybavení Ovládá technické vybavení počítače Tvoří rozhraní mezi aplikačními (uživatelskými) programy a hardwarem organizace přístupu k datům spouštění

Více

MONITORING A ANALÝZA KVALITY ELEKTŘINY

MONITORING A ANALÝZA KVALITY ELEKTŘINY MONITORING A ANALÝZA KVALITY ELEKTŘINY Doc. Ing. Jan Žídek, CSc. Kvalitativní stránka elektřiny dnes hraje čím dál významnější roli. Souvisí to jednak s liberalizací trhu s elektrickou energii a jednak

Více

Statistica, kdo je kdo?

Statistica, kdo je kdo? Statistica, kdo je kdo? Newsletter Statistica ACADEMY Téma: Typy instalací Typ článku: Teorie Někteří z vás používají univerzitní licence, někteří síťové, podnikové atd. V tomto článku Vám představíme,

Více

INTEGRACE IS DO STÁVAJÍCÍ HW A SW ARCHITEKTURY

INTEGRACE IS DO STÁVAJÍCÍ HW A SW ARCHITEKTURY INTEGRACE IS DO STÁVAJÍCÍ HW A SW ARCHITEKTURY Dušan Kajzar Slezská univerzita v Opavě, Filozoficko-přírodovědecká fakulta, Bezručovo nám. 13, 746 00 Opava, e-mail: d.kajzar@c-box.cz Česká pošta, s.p.,

Více

VYUŽITÍ REGIONÁLNÍCH FUNKCÍ A WWW ROZHRANÍ V INTEGROVANÉM KNIHOVNÍM SYSTÉMU KPWINSQL

VYUŽITÍ REGIONÁLNÍCH FUNKCÍ A WWW ROZHRANÍ V INTEGROVANÉM KNIHOVNÍM SYSTÉMU KPWINSQL VYUŽITÍ REGIONÁLNÍCH FUNKCÍ A WWW ROZHRANÍ V INTEGROVANÉM KNIHOVNÍM SYSTÉMU KPWINSQL Petr Štefan Václav Trunec, KP-sys, Čacké 155, Pardubice 1 Úvod Firma KP-SYS spol. s r. o. dodává na náš trh integrované

Více

Zřízení technologického centra ORP Dobruška

Zřízení technologického centra ORP Dobruška Příloha č. Technická specifikace. části zakázky: Zřízení technologického centra ORP Dobruška položka číslo Popis blade chassis pro servery: provedení do racku kapacita minimálně 8x dvouprocesorový blade

Více

MapleCloud a jeho použ ití. Vladimír Žák

MapleCloud a jeho použ ití. Vladimír Žák MapleCloud a jeho použ ití Vladimír Žák Brno, 2015 Obsah 1 Úvod... 4 2 Novinky v MapleCloud pro Maple 2015... 5 3 MapleCloud a registrace... 6 4 Použití MapleCloud přímo z Maple 2015... 7 4.1 Popis jednotlivých

Více

ADMINISTRAČNÍ PŘIRUČKA verze 1.1.19. Strana 2 (celkem 20) Strana 3 (celkem 20) 1. Obsah 1. Obsah...3 2. Úvod...5 2.1. Požadavky na hardware...5 2.2. Požadavky na software...5 2.3. Instalace...5 2.4. Výchozí

Více

Příloha č.2 - Technická specifikace předmětu veřejné zakázky

Příloha č.2 - Technická specifikace předmětu veřejné zakázky Příloha č.2 - Technická specifikace předmětu veřejné zakázky Popis stávajícího řešení u zadavatele Česká centra (dále jen ČC ) provozují 8 fyzických serverů, připojené k local storage. Servery jsou rozděleny

Více

Technická dokumentace veřejné zakázky Systém sběru informací o průjezdu a měření rychlosti vozidel na území Plzeňského kraje

Technická dokumentace veřejné zakázky Systém sběru informací o průjezdu a měření rychlosti vozidel na území Plzeňského kraje Příloha č. 1 Zadávací dokumentace a Smlouvy o dílo Technická dokumentace Technická dokumentace veřejné zakázky Systém sběru informací o průjezdu a měření rychlosti vozidel na území Plzeňského kraje Obsah

Více

ADDAT HEAT Control - Návod k použití - verze 2.07 (firmware 1.44)

ADDAT HEAT Control - Návod k použití - verze 2.07 (firmware 1.44) - ADDAT HEAT Control - Návod k použití - verze 2.07 (firmware 1.44) ADDAT s.r.o. Májová 1126 463 11 Liberec 30 telefon: fax: http: e-mail: 485 102 271 485 114 761 www.addat.cz addat@addat.cz Obsah: 1.

Více

VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika

VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika Napojení e-shopu na obchodní portál aukro.cz bakalářská práce Autor: Josef Vrbata Vedoucí práce: Ing.

Více

Databázové systémy I. 1. přednáška

Databázové systémy I. 1. přednáška Databázové systémy I. 1. přednáška Vyučující a cvičení St 13:00 15:50 Q09 Pavel Turčínek St 16:00 18:50 Q09 Oldřich Faldík Čt 10:00 12:50 Q09 Jan Turčínek Pá 7:00 9:50 Q08 Pavel Turčínek Pá 10:00 12:50

Více

Projekt 7006/2014 SDAT - Sběr dat pro potřeby ČNB. Návrh realizace řešení

Projekt 7006/2014 SDAT - Sběr dat pro potřeby ČNB. Návrh realizace řešení Projekt 7006/2014 SDAT - Sběr dat pro potřeby ČNB Návrh realizace řešení Tento dokument obsahuje informace důvěrného charakteru a informace v něm obsažené jsou vlastnictvím České národní banky. Žádná část

Více

Práce s velkými sestavami

Práce s velkými sestavami Práce s velkými sestavami Číslo publikace spse01650 Práce s velkými sestavami Číslo publikace spse01650 Poznámky a omezení vlastnických práv Tento software a související dokumentace je majetkem společnosti

Více

www.cdc-monitoring.cz

www.cdc-monitoring.cz Monitoring sítí a serverů Dnešní požadavky na výkon ethernetových, wifi nebo jiných sítí, jejich serverů a aktivních prvků jsou velmi striktně nastaveny. Síť musí být koncipována tak, aby byla zaručena

Více

KAPITOLA 3. Architektura aplikací na frameworku Rails. V této kapitole: modely, pohledy, řadiče.

KAPITOLA 3. Architektura aplikací na frameworku Rails. V této kapitole: modely, pohledy, řadiče. KAPITOLA 3 Architektura aplikací na frameworku Rails V této kapitole: modely, pohledy, řadiče. 58 Část I: Začínáme Jedna ze zajímavých vlastností frameworku Rails spočívá v tom, že klade docela závažná

Více

DUM 9 téma: Hostingové služby

DUM 9 téma: Hostingové služby DUM 9 téma: Hostingové služby ze sady: 3 tematický okruh sady: III. Ostatní služby internetu ze šablony: 8 Internet určeno pro: 4. ročník vzdělávací obor: 18-20-M/01 Informační technologie vzdělávací oblast:

Více

Správa linuxového serveru: Zprovoznění Ruby aplikací s RVM, Thin a Nginx

Správa linuxového serveru: Zprovoznění Ruby aplikací s RVM, Thin a Nginx Home» Články» Praxe» Správa linuxového serveru» Správa linuxového serveru: Zprovoznění Ruby... Předchozí kapitola Zpět na obsah Následující kapitola Správa linuxového serveru: Zprovoznění Ruby aplikací

Více

2.1 Obecné parametry 2.1.1 Obecné parametry Rack serveru

2.1 Obecné parametry 2.1.1 Obecné parametry Rack serveru . Obecné parametry.. Obecné parametry Rack serveru Redundantní napájecí zdroje v počtu a výkonu odpovídajícímu specifikovanému řešení. Redundantní ventilátory v počtu odpovídajícímu specifikovanému řešení

Více

Modul EPNO. Téma: Elektronické odesílání evidenčních listů přepravy nebezpečných odpadů

Modul EPNO. Téma: Elektronické odesílání evidenčních listů přepravy nebezpečných odpadů Modul EPNO Téma: Elektronické odesílání evidenčních listů přepravy nebezpečných odpadů Program: EVI 8 Vypracoval: Mgr. Tomáš Čejchan (oddělení Podpora) Revize: 07.03.2014 Tento dokument popisuje funkcionalitu

Více

Manuál administrátora FMS...2

Manuál administrátora FMS...2 Manuál administrátora Manuál administrátora FMS...2 Úvod... 2 Schéma aplikace Form Management System... 2 Úvod do správy FMS... 3 Správa uživatelů... 3 Práva uživatelů a skupin... 3 Zástupci... 4 Avíza

Více

Datalogger Teploty a Vlhkosti

Datalogger Teploty a Vlhkosti Datalogger Teploty a Vlhkosti Uživatelský Návod Úvod Teplotní a Vlhkostní Datalogger je vybaven senzorem o vysoké přesnosti měření teploty a vlhkosti. Tento datalogger má vlastnosti jako je vysoká přesnost,

Více

M I S Y S - W E B. Intranet řešení systému MISYS. Verze 9.00. Příručka uživatele

M I S Y S - W E B. Intranet řešení systému MISYS. Verze 9.00. Příručka uživatele M I S Y S - W E B Intranet řešení systému MISYS Verze 9.00 Příručka uživatele GEPRO s.r.o. Září 2008 Copyright GEPRO s.r.o. 2008 Ochranné známky GEPRO spol. s r.o. KOKEŠ, MISYS Ochranné známky Microsoft

Více

Minebot manuál (v 1.2)

Minebot manuál (v 1.2) Minebot manuál (v 1.2) Pro Váš rychlý start s nástrojem Minebot jsme připravili tohoto stručného průvodce, který by Vám měl být pomocníkem při spuštění a používání služby. Tento stručný průvodce by vám

Více

Přehled systému Microsoft SQL Server. Komu je kniha určena Struktura knihy Nejvhodnější výchozí bod pro čtení knihy Konvence a struktura knihy

Přehled systému Microsoft SQL Server. Komu je kniha určena Struktura knihy Nejvhodnější výchozí bod pro čtení knihy Konvence a struktura knihy Komu je kniha určena Struktura knihy Nejvhodnější výchozí bod pro čtení knihy Konvence a struktura knihy Konvence Další prvky Požadavky na systém Ukázkové databáze Ukázky kódu Použití ukázek kódu Další

Více

Ovladač Fiery Driver pro systém Mac OS

Ovladač Fiery Driver pro systém Mac OS 2016 Electronics For Imaging, Inc. Informace obsažené v této publikaci jsou zahrnuty v Právní oznámení pro tento produkt. 30. května 2016 Obsah Ovladač Fiery Driver pro systém Mac OS Obsah 3...5 Fiery

Více

TEPELNÁ TECHNIKA 1D. Základy práce s aplikací. Verze 3.0.0

TEPELNÁ TECHNIKA 1D. Základy práce s aplikací. Verze 3.0.0 TEPELNÁ TECHNIKA 1D Základy práce s aplikací Verze 3.0.0 OBSAH 1. Přehled verzí aplikace... 5 2. Spuštění aplikace... 8 2.1. Ze stránek www.stavebni-fyzika.cz... 8 2.2. Z jiné aplikace... 8 3. Princip

Více

Katalog služeb a podmínky poskytování provozu

Katalog služeb a podmínky poskytování provozu Příloha č. 1 Servisní smlouvy Katalog služeb a podmínky poskytování provozu Část P2_1 P2_1_Katalog služeb a podmínky poskytování provozu 1 Obsah 1 OBSAH... 2 2 DEFINICE POJMŮ... 3 3 DEFINICE SLUŽEB, KOMPONENT

Více

Uživatelská příručka

Uživatelská příručka Uživatelská příručka PC výkaznictví JASU (program pro zpracování účetního výkaznictví) březen 2012 Dodavatel: MÚZO Praha s.r.o. Politických vězňů 15 P.O.Box 36 111 21 Praha 1 telefon: 224 091 619 fax:

Více

Program pro flexibilní tvorbu evidencí. VIKLAN - Evidence. Uživatelská příručka. pro seznámení se základními možnostmi programu

Program pro flexibilní tvorbu evidencí. VIKLAN - Evidence. Uživatelská příručka. pro seznámení se základními možnostmi programu Program pro flexibilní tvorbu evidencí VIKLAN - Evidence Uživatelská příručka pro seznámení se základními možnostmi programu Vlastimil Kubínek, Ing. Josef Spilka VIKLAN - Evidence Verse 1.11.8.1 Copyright

Více

ZPRACOVÁNÍ NEURČITÝCH ÚDAJŮ V DATABÁZÍCH

ZPRACOVÁNÍ NEURČITÝCH ÚDAJŮ V DATABÁZÍCH 0. Obsah Strana 1 z 12 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA STROJNÍHO INŽENÝRSTVÍ ÚSTAV AUTOMATIZACE A INFORMATIKY FACULTY OF MECHANICAL ENGINEERING INSTITUTE OF AUTOMATION

Více

QuarkXPress 9.5 - soubor ReadMe

QuarkXPress 9.5 - soubor ReadMe QuarkXPress 9.5 - soubor ReadMe OBSAH Obsah QuarkXPress 9.5 - soubor ReadMe...4 Požadavky na systém...5 Požadavky na systém: Mac OS...5 Požadavky na systém: Windows...5 Instalování: Mac OS...7 Provedení

Více

Ulozto.cz. Český server pro sdílení dat na internetu. 1. semestrální práce na předmět Testování uživatelských rozhraní A7B36TUR. zavrekar@fel.cvut.

Ulozto.cz. Český server pro sdílení dat na internetu. 1. semestrální práce na předmět Testování uživatelských rozhraní A7B36TUR. zavrekar@fel.cvut. Ulozto.cz Český server pro sdílení dat na internetu 1. semestrální práce na předmět Testování uživatelských rozhraní A7B36TUR Vypracoval: Kontakt: Karel Zavřel zavrekar@fel.cvut.cz 1 Obsah 1 Úvod... 3

Více

Vývoj, výroba, prodej a montáž docházkových a identifikačních systémů. Docházka 3000 Personalistika

Vývoj, výroba, prodej a montáž docházkových a identifikačních systémů. Docházka 3000 Personalistika BM Software, Němčičky 84, 69107 Němčičky u Břeclavi Vývoj, výroba, prodej a montáž docházkových a identifikačních systémů Tel: 519 430 765, Mobil: 608 447 546 e-mail: bmsoft@seznam.cz web: http://www.dochazka.eu

Více

Univerzita Palackého v Olomouci. Služby spojené s Active Directory

Univerzita Palackého v Olomouci. Služby spojené s Active Directory Moderní učitel CZ.1.07/1.3.00/51.0041 Univerzita Palackého v Olomouci Pedagogická fakulta Služby spojené s Active Directory doc. PhDr. Milan Klement, Ph.D. Olomouc 2015 Publikace vznikla v rámci ESF projektu

Více

E.C.S. řada 900 - nová generace obrat o 360 ( Systém vyvinut ve Florencii v r.2009 )

E.C.S. řada 900 - nová generace obrat o 360 ( Systém vyvinut ve Florencii v r.2009 ) E.C.S. řada 900 - nová generace obrat o 360 ( Systém vyvinut ve Florencii v r.2009 ) Filozofie vývoje nové řady E.C.S. CNC klade důraz především na vyspělou technologii a nadčasový vzhled. Vývoji nového

Více

Workmonitor. Servisní návod. 24. června 2014 w w w. p a p o u c h. c o m

Workmonitor. Servisní návod. 24. června 2014 w w w. p a p o u c h. c o m Servisní návod 24. června 2014 w w w. p a p o u c h. c o m Workmonitor Katalogový list Vytvořen: 18.5.2009 Poslední aktualizace: 24.6 2014 09:20 Počet stran: 11 2014 Adresa: Strašnická 3164/1a 102 00 Praha

Více

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ M. Sysel, I. Pomykacz Univerzita Tomáše Bati ve Zlíně, Fakulta aplikované informatiky Nad Stráněmi 4511, 760 05 Zlín, Česká republika

Více

Obsah přednášky. Představení webu ASP.NET frameworky Relační databáze Objektově-relační mapování Entity framework

Obsah přednášky. Představení webu ASP.NET frameworky Relační databáze Objektově-relační mapování Entity framework Web Jaroslav Nečas Obsah přednášky Představení webu ASP.NET frameworky Relační databáze Objektově-relační mapování Entity framework Co to je web HTTP protokol bezstavový GET POST HEAD Cookies Session HTTPS

Více

MAWIS. Uživatelská dokumentace

MAWIS. Uživatelská dokumentace MAWIS Uživatelská dokumentace Verze 27-11-2008 OBSAH OBSAH... 2 1) O MAPOVÉM SERVERU... 3 2) POTŘEBNÁ NASTAVENÍ... 3 Hardwarové požadavky... 3 Softwarové požadavky... 3 Nastavení Internet Exploreru:...

Více

Management sítí OSI management framework SNMP Komerční diagnostické nástroje Opensource diagnostické nástroje

Management sítí OSI management framework SNMP Komerční diagnostické nástroje Opensource diagnostické nástroje Přednáška č.12 Management sítí OSI management framework SNMP Komerční diagnostické nástroje Opensource diagnostické nástroje Původní LAN o 50 až 100 uživatelů, několik tiskáren, fileserver o relativně

Více

BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS STANISLAV SEHNAL

BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS STANISLAV SEHNAL VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS WEBOVÉ ROZHRANÍ

Více

Fotogalerie pro redakční systém Marwel Obscura v. 2.0

Fotogalerie pro redakční systém Marwel Obscura v. 2.0 Fotogalerie pro redakční systém Marwel Obscura v. 2.0 postupy a doporučení pro práci redaktorů verze manuálu: 1.1 QCM, s. r. o., březen 2011 Podpora: e-mail: podpora@qcm.cz tel.: +420 538 702 705 Obsah

Více

Organizace a zpracování dat I (NDBI007) RNDr. Michal Žemlička, Ph.D.

Organizace a zpracování dat I (NDBI007) RNDr. Michal Žemlička, Ph.D. Úvodní přednáška z Organizace a zpracování dat I (NDBI007) RNDr. Michal Žemlička, Ph.D. Cíl předmětu Obeznámit studenty se základy a specifiky práce se sekundární pamětí. Představit některé specifické

Více

QuarkXPress 9.2 - soubor ReadMe

QuarkXPress 9.2 - soubor ReadMe QuarkXPress 9.2 - soubor ReadMe OBSAH Obsah QuarkXPress 9.2 - soubor ReadMe...4 Požadavky na systém...5 Požadavky na systém: Mac OS...5 Požadavky na systém: Windows...5 Instalování: Mac OS...6 Provedení

Více

Mobilní aplikace Novell Filr Stručný úvod

Mobilní aplikace Novell Filr Stručný úvod Mobilní aplikace Novell Filr Stručný úvod Únor 2016 Podporovaná mobilní zařízení Aplikace Novell Filr je podporována v následujících mobilních zařízeních: Telefony a tablety se systémem ios 8 novějším

Více

Jak nasadit Windows 10 ve škole

Jak nasadit Windows 10 ve škole Jak nasadit ve škole Karel Klatovský PUBLIKOVÁNO: ÚNOR 2016 PRO AKTUÁLNÍ INFORMACE NAVŠTIVTE WEBOVÉ STRÁNKY WWW.MICROSOFT.CZ/SKOLSTVI Obsah Obsah...2 1. Úvod...3 2. Systémové požadavky... 4 3. Příprava

Více

DPH v Exact Globe Next 2013

DPH v Exact Globe Next 2013 DPH v Exact Globe Next 2013 Tento dokument obsahuje komplexní informace týkající se nastavení číselníků v software Exact Globe Next, potřebných pro správné fungování DPH a souhrnného hlášení, včetně změn,

Více

RELAČNÍ DATABÁZOVÉ SYSTÉMY

RELAČNÍ DATABÁZOVÉ SYSTÉMY RELAČNÍ DATABÁZOVÉ SYSTÉMY VÝPIS KONTROLNÍCH OTÁZEK S ODPOVĚDMI: Základní pojmy databázové technologie: 1. Uveďte základní aspekty pro vymezení jednotlivých přístupů ke zpracování hromadných dat: Pro vymezení

Více

AVG_ANTIVIR. Semestrální projekt předmětu Návrh uživatelských rozhraní Julie Partyková, partyjul@fel.cvut.cz Ondřej Mirtes, mirteond@fel.cvut.

AVG_ANTIVIR. Semestrální projekt předmětu Návrh uživatelských rozhraní Julie Partyková, partyjul@fel.cvut.cz Ondřej Mirtes, mirteond@fel.cvut. AVG_ANTIVIR Semestrální projekt předmětu Návrh uživatelských rozhraní Julie Partyková, partyjul@fel.cvut.cz Ondřej Mirtes, mirteond@fel.cvut.cz Zadání Tento projekt se zabývá zpřístupněním uživatelského

Více

KAPITOLA 1 SOCIÁLNÍ SÍTĚ A PHP...17

KAPITOLA 1 SOCIÁLNÍ SÍTĚ A PHP...17 Obsah ÚVODEM..............................................11 Co v této knize najdete................................... 12 Co budete v této knize potřebovat.......................... 13 Pro koho je tato

Více

Veřejné zakázky s.r.o., Praha 6, Bubeneč, Na Hutích 661/9, PSČ 160 00 Tel./fax: 224 318 907, email: sekretariat@zakazkyverejne.cz

Veřejné zakázky s.r.o., Praha 6, Bubeneč, Na Hutích 661/9, PSČ 160 00 Tel./fax: 224 318 907, email: sekretariat@zakazkyverejne.cz Veřejné zakázky s.r.o., Praha 6, Bubeneč, Na Hutích 661/9, PSČ 160 00 Tel./fax: 224 318 907, email: sekretariat@zakazkyverejne.cz V Praze dne 9.4.2014 Věc: Dotazy a odpovědi k zadávací dokumentaci č.2

Více

Úvod do PHP s přihlédnutím k MySQL

Úvod do PHP s přihlédnutím k MySQL Root.cz - Úvod do PHP s přihlédnutím k MySQL Stránka č. 1 z 5 Úvod do PHP s přihlédnutím k MySQL 07.04.2000 Vhodná kombinace PHP a MySQL na dostatečně výkonném serveru poskytuje hodně možností. Hitem poslední

Více

Maturitní témata. Informační a komunikační technologie. Gymnázium, Střední odborná škola a Vyšší odborná škola Ledeč nad Sázavou.

Maturitní témata. Informační a komunikační technologie. Gymnázium, Střední odborná škola a Vyšší odborná škola Ledeč nad Sázavou. Gymnázium, Střední odborná škola a Vyšší odborná škola Ledeč nad Sázavou Maturitní témata předmět Informační a komunikační technologie Dominik Janák 2015 třída 4I Dominik Janák Maturitní otázky Výpočetní

Více

ZÁVĚREČNÁ STUDIJNÍ PRÁCE dokumentace

ZÁVĚREČNÁ STUDIJNÍ PRÁCE dokumentace ZÁVĚREČNÁ STUDIJNÍ PRÁCE dokumentace Dokumentační systém pro Android Marek Kovalčík Obor: Třída: Školní rok: 18-20-M/01 INFORMAČNÍ TECHNOLOGIE se zaměřením na počítačové sítě a programování IT4 2015/2016

Více

Technologie počítačových sítí 5. cvičení

Technologie počítačových sítí 5. cvičení Technologie počítačových sítí 5. cvičení Obsah jedenáctého cvičení Active Directory Active Directory Rekonfigurace síťového rozhraní pro použití v nadřazené doméně - Vyvolání panelu Síťové připojení -

Více

2. přednáška. Databázový přístup k datům (SŘBD) Možnost počítání v dekadické aritmetice - potřeba přesných výpočtů, např.

2. přednáška. Databázový přístup k datům (SŘBD) Možnost počítání v dekadické aritmetice - potřeba přesných výpočtů, např. 2 přednáška 2 října 2012 10:32 Souborově orientované uchování dat Slabý HW Není možné uchovávat "velká data" - maximálně řádově jednotky MB Na každou úlohu samostatná aplikace, která má samostatná data

Více

MATURITNÍ PRÁCE dokumentace

MATURITNÍ PRÁCE dokumentace MATURITNÍ PRÁCE dokumentace Jídelníček SŠIEŘ pro Android Martin Bartoň školní rok: 2012/2013 obor: třída: Počítačové systémy PS4.A ABSTRAKT Práce je zaměřená na problematiku tvorby Android aplikací,

Více

OPERAČNÍ SYSTÉM ZLÍNSKÝ KRAJ. Obchodní akademie, Vyšší odborná škola a Jazyková škola s právem státní jazykové zkoušky Uherské Hradiště

OPERAČNÍ SYSTÉM ZLÍNSKÝ KRAJ. Obchodní akademie, Vyšší odborná škola a Jazyková škola s právem státní jazykové zkoušky Uherské Hradiště OPERAČNÍ SYSTÉM Název školy Obchodní akademie, Vyšší odborná škola a Jazyková škola s právem státní jazykové zkoušky Uherské Hradiště Název DUMu Operační systém Autor Martin Šimůnek Datum 13. 2. 2013 Stupeň

Více

IS pro podporu BOZP na FIT ČVUT

IS pro podporu BOZP na FIT ČVUT IS pro podporu BOZP na FIT ČVUT Závěrečná zpráva pro 2. iteraci 21. dubna 2011 Zadavatel: Ing. Jiří Chludil Řešitelský tým: Jiří Kopecký Jan Kratochvíl Milan Matějček Štefan Pinďák Kristýna Streitová Úvod

Více

Úvod...15. Používané konvence... 16. 1. Seznámení s Outlookem...17

Úvod...15. Používané konvence... 16. 1. Seznámení s Outlookem...17 Obsah Úvod...15 Používané konvence... 16 1. Seznámení s Outlookem...17 1.1 Novinky verze 2003... 17 1.1.1 Navigační podokno...17 1.1.2 Nabídka Přejít...17 1.1.3 Podokno pro čtení...18 1.1.4 Rozložení seznamu

Více

MyIO - webový komunikátor

MyIO - webový komunikátor MyIO - webový komunikátor Technická příručka verze dokumentu 1.0 FW verze modulu 1.4-1 - Obsah 1 MyIO modul... 3 2 Lokální webové rozhraní... 3 2.1 Start, první přihlášení... 3 2.2 Home úvodní strana MyIO...

Více

Uživatelská příručka systému pro administrátory obcí a manuál pro správce portálu

Uživatelská příručka systému pro administrátory obcí a manuál pro správce portálu Softwarová podpora tvorby rozvojových dokumentů obcí Uživatelská příručka systému pro administrátory obcí a manuál pro správce portálu Verze 1.3 Zpracováno v rámci projektu CZ.1.04/4.1.00/62.00008 ELEKTRONICKÁ

Více

DOPLNĚK. Projekt Informační systém základních registrů je spolufinancován Evropskou unií z Evropského fondu pro regionální rozvoj.

DOPLNĚK. Projekt Informační systém základních registrů je spolufinancován Evropskou unií z Evropského fondu pro regionální rozvoj. GLOBÁLNÍ ARCHITEKTURA ZÁKLADNÍCH REGISTRŮ DOPLNĚK Projekt Informační systém základních registrů je spolufinancován Evropskou unií z Evropského fondu pro regionální rozvoj. Obsah 1 Cíle dokumentu...3 2

Více

DATA ARTICLE. AiP Beroun s.r.o.

DATA ARTICLE. AiP Beroun s.r.o. DATA ARTICLE AiP Beroun s.r.o. OBSAH 1 Úvod... 1 2 Vlastnosti Data Article... 1 2.1 Požadavky koncových uživatelů... 1 2.2 Požadavky na zajištění bezpečnosti a důvěryhodnosti obsahu... 1 3 Implementace

Více

Zálohovací zařízení pro repozitář jazykových dat a digitálního materiálu pro jazykový výzkum

Zálohovací zařízení pro repozitář jazykových dat a digitálního materiálu pro jazykový výzkum Příloha č. 2 Zadávací dokumentace Technické specifikace část I. Zálohovací zařízení pro repozitář jazykových dat a digitálního materiálu pro jazykový výzkum Jedná se o dodávku technického vybavení pro

Více

NOVÁ VERZE OBD A JEJÍ VYUŽÍVÁNÍ Ing. Martina Valášková

NOVÁ VERZE OBD A JEJÍ VYUŽÍVÁNÍ Ing. Martina Valášková NOVÁ VERZE OBD A JEJÍ VYUŽÍVÁNÍ Ing. Martina Valášková studijní materiál ke kurzu Odborné publikování, citační etika a autorské právo s podporou ICT Fakulta informatiky a managementu Univerzity Hradec

Více

Technická specifikace vymezené části 1 SERVER

Technická specifikace vymezené části 1 SERVER Technická specifikace vymezené části 1 SERVER 1 Předmět vymezené části 1.1 Předmětem veřejné zakázky je dodávka a moderního a spolehlivého serverového řešení pro potřeby Krajského ředitelství PČR Karlovarského

Více

PŘEVODNÍK SNÍMAČE SIL NA USB PRO ZOBRAZENÍ V PC DSCUSB. KRÁTKÁ PŘÍRUČKA PRO OBSLUHU A KONFIGURACI Revize červenec 2014

PŘEVODNÍK SNÍMAČE SIL NA USB PRO ZOBRAZENÍ V PC DSCUSB. KRÁTKÁ PŘÍRUČKA PRO OBSLUHU A KONFIGURACI Revize červenec 2014 PŘEVODNÍK SNÍMAČE SIL NA USB PRO ZOBRAZENÍ V PC DSCUSB KRÁTKÁ PŘÍRUČKA PRO OBSLUHU A KONFIGURACI Revize červenec spol. s.r.o. Ostrovačice OBSAH 1 ZÁKLADNÍ INFORMACE... 2 1.1 Parametry převodníku DSCUSB...

Více

Uživatelská příručka pro program

Uživatelská příručka pro program NEWARE Uživatelský manuál Uživatelská příručka pro program ve spojení se zabezpečovacím systémem strana 1 Uživatelský manuál NEWARE strana 2 NEWARE Uživatelský manuál Vaše zabezpečovací ústředna DIGIPLEX

Více

2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE

2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE 2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE Studijní cíl Tento blok je věnován základní syntaxi příkazu SELECT, pojmům projekce a restrikce. Stručně zde budou představeny příkazy

Více

Aplikovaná informatika

Aplikovaná informatika Vysoká škola polytechnická Jihlava Katedra elektrotechniky a informatiky Tematické okruhy pro státní závěrečné zkoušky oboru Aplikovaná informatika Tyto okruhy jsou platné pro studenty, kteří započali

Více

Obr. 1 - Seznam smluv

Obr. 1 - Seznam smluv Modul Evidence smluv je určen pro správu smluvních dokumentů na VUT v Brně. S tímto modulem úzce souvisí modul Smluvní partneři, ve kterém se spravují smluvní strany smluvních dokumentů. Pro nastavení

Více

HEIS VÚV V ROCE 2006 Jiří Picek Klíčová slova Hydroekologický informační systém VÚV T.G.M. (HEIS VÚV) je centrálním informačním systémem odborných sekcí ústavu. Jeho hlavním posláním je zajištění zpracování,

Více

Vladimír Mach. @vladimirmach 2. 1. 2013

Vladimír Mach. @vladimirmach 2. 1. 2013 Vladimír Mach @vladimirmach 2. 1. 2013 SQL Server Compact Edition Jednoduchá relační databáze Použití i v malých zařízeních s omezenými zdroji Dříve pod názvem SQL Server Mobile Časté využití při programování

Více

Uživatelský manuál na obsluhu mobilní aplikace CMOB

Uživatelský manuál na obsluhu mobilní aplikace CMOB Uživatelský manuál na obsluhu mobilní aplikace CMOB 1 Obsah 1. Popis aplikace... 3 2. Instalace aplikace na zařízení... 3 3. První spuštění aplikace... 3 4. Úvodní obrazovka aplikace... 3 5. Sekce kamer...

Více

Zásady ochrany osobních údajů

Zásady ochrany osobních údajů Zásady ochrany osobních údajů Naposledy upraveno: 28. června 2016 (zobrazit archivované verze) (Příklady odkazů jsou k dispozici na konci dokumentu.) Naše služby můžete využívat mnoha různými způsoby počínaje

Více

Parametrizace, harmonogram

Parametrizace, harmonogram Parametrizace, harmonogram Modul slouží pro parametrizování informačního systému a pro vytváření časového plánu akademického roku na fakultě. Fakulty si v něm zadávají a specifikují potřebné "časové značky"

Více

ALFIS 2014 komplexní ekonomický systém verze 2014.5

ALFIS 2014 komplexní ekonomický systém verze 2014.5 ALFIS 2014 komplexní ekonomický systém verze 2014.5 Návod na instalaci Fuksa Ladislav Sedlčanská 1327/65 140 00 Praha 4 Tel. 223 010 785, 603 463 137 E-mail alfis@fksoft.cz Web www.alfis.cz, www.fksoft.cz

Více

ÚVOD 3 SEZNÁMENÍ SE SYSTÉMEM 4

ÚVOD 3 SEZNÁMENÍ SE SYSTÉMEM 4 ÚVOD 3 SEZNÁMENÍ SE SYSTÉMEM 4 JEDNODUCHÉ PŘIHLÁŠENÍ 4 ADMINISTRAČNÍ PROSTŘEDÍ 5 PŘEPÍNÁNÍ JAZYKOVÉ VERZE 5 POLOŽKY HORNÍHO MENU 5 DOPLŇKOVÉ POLOŽKY MENU: 6 STROM SE STRÁNKAMI, RUBRIKAMI A ČLÁNKY 7 TITULNÍ

Více