Česká zemědělská univerzita v Praze
Provozně ekonomická fakulta
Katedra informačního inženýrství
Diplomová práce
Konfigurace Linuxového serveru
Jiří Malák
© 2011 ČZU v Praze
Prohlášení
Prohlašuji, že jsem diplomovou práci na téma Konfigurace Linuxového
serveru vypracoval samostatně pod vedením Ing. Marka Picky a použil jsem jen
literární prameny, které cituji a uvádím v seznamu použité literatury.
V Praze dne: 30.4.2009
…..…...………………
Poděkování
Děkuji vedoucímu diplomové práce panu Ing. Markovi Pickovi za pozornost, kterou
věnoval mé práci, a za jeho odborné rady při vypracování této diplomové práce.
Konfigurace Linuxového serveru
-------------------------------------------------------------------Linux server configuration
Souhrn
Práce se zabývá konfigurací Linuxového serveru vhodného pro malou firmu. Ve své
teoretické části popisuje základní vlastnosti operačního systému Linux a síťové
služby se zvláštním zřetelem na webové služby. V práci jsou navrhnuta doporučení
pro konfiguraci těchto služeb. V praktické části je provedena konfigurace celého
serveru. Na realizovaném serveru jsou provedeny výkonnostní testy webových
služeb. Jsou otestovány různé konfigurace webových serverů. Konfigurace jsou
upraveny na základě provedených testů. Testy se vztahují k rychlosti zpracování
požadavků. Na základě výsledků testů jsou zhodnoceny jednotlivé konfigurace a
stanovena doporučení vhodné konfigurace.
Klíčová slova
Linux, server, konfigurace, web, Apache, Nginx, testy, výkon, služby
Summary
This work is related to configuration of Linux server suitable for small
company. Basic properties of linux system and network services with particular
focus on web services are described in the theoretical part. Recommendations for
configuration of the services are proposed in the work. Configuration of the whole
server is described in the practical part. Performance tests of web services are
accomplished on the experimental servers. Various configurations of web servers are
tested. The configurations are chosen on the basis of the performed tests. The tests
are related to speed of requests processing. Individual configurations are evaluated
and recommendations for suitable configuration are discussed on the basis of test
results.
Keywords
Linux, server, configuration, web, Apache, Nginx, tests, performance, services
6
Obsah
1
Úvod ........................................................................................................ 10
2
Cíl práce a metodika ................................................................................ 12
3
2.1
Cíl práce ........................................................................................... 12
2.2
Metodika .......................................................................................... 12
Operační systém Linux ............................................................................ 14
3.1
Uživatelé .......................................................................................... 14
3.1.1 Řízení přístupu ........................................................................... 15
3.2
Procesy a vlákna ............................................................................... 16
3.2.1 Kontext procesu .......................................................................... 17
3.2.2 Přidělování procesoru ................................................................. 18
3.2.3 Řízení procesů ............................................................................ 18
3.3
Souborový systém ............................................................................ 19
3.3.1 Přístupová práva ......................................................................... 19
4
Síťové služby ........................................................................................... 21
4.1
Základní síťové služby ..................................................................... 21
4.1.1 TCP/IP ........................................................................................ 21
4.1.2 DHCP ......................................................................................... 21
4.1.3 DNS ............................................................................................ 22
4.2
Samba ............................................................................................... 24
4.3
Poštovní server ................................................................................. 25
4.4
Poštovní server Postfix ..................................................................... 26
4.4.1 Zpracování pošty ........................................................................ 27
4.4.2 Nastavení poštovního serveru .................................................... 28
4.4.3 Filtrování obsahu pošty .............................................................. 29
4.4.4 Navrhované řešení ...................................................................... 29
4.5
WWW server .................................................................................... 30
4.6
WWW server Apache ...................................................................... 33
4.6.1 Architektura Apache................................................................... 34
4.6.2 Konfigurace serveru Apache ...................................................... 37
4.6.3 Dynamické generování obsahu .................................................. 39
4.6.4 Zabezpečení ................................................................................ 40
4.6.5 SSL ............................................................................................. 41
4.7
WWW server Nginx ......................................................................... 42
4.7.1 Architektura Nginx ..................................................................... 43
4.7.2 Konfigurace Nginx ..................................................................... 45
7
4.7.3 Dynamické generování obsahu .................................................. 48
4.7.4 Zabezpečení ................................................................................ 48
5
Praktické nastavení serveru ..................................................................... 51
5.1
Bezpečnostní model ......................................................................... 51
5.2
Instalace............................................................................................ 52
5.3
Nastavení TCP/IP ............................................................................. 52
5.4
Nastavení DHCP serveru ISC (4.1.2) .............................................. 54
5.5
Nastavení DNS serveru BIND (9.7.3).............................................. 55
5.6
Nastavení Samba serveru (3.5.3) ..................................................... 57
5.7
Nastavení poštovního serveru .......................................................... 59
5.7.1 Nastavení Postfix (2.7.1) ............................................................ 59
5.7.2 Nastavení Dovecot (1.2.11) ........................................................ 60
5.7.3 Nastavení webové aplikace pro přístup k poště ......................... 62
5.8
Nastavení webového serveru Apache (2.2.15) ................................. 63
5.8.1 Nastavení podpory PHP ............................................................. 65
5.9
Nastavení webového serveru Nginx (0.8.54) ................................... 66
5.9.1 Nastavení podpory PHP ............................................................. 68
6
Hodnocení alternativních konfigurací ..................................................... 70
6.1
Testovací sestavy ............................................................................. 70
6.2
Testovací konfigurace ...................................................................... 70
6.3
Nastavení parametrů......................................................................... 72
6.4
Metodika testování ........................................................................... 73
6.5
Typy testů ......................................................................................... 74
6.5.1 Výkonnostní testy ....................................................................... 74
6.5.2 Statický test (test S1) .................................................................. 75
6.6
Výsledky testů .................................................................................. 75
6.6.1 Test HTTP serverů (test H1) ...................................................... 75
6.6.2 Test HTTP serverů s podporou PHP .......................................... 78
6.6.3 Statický test zdrojů (S1) ............................................................. 82
6.7
Zhodnocení konfigurací ................................................................... 83
7
Závěr ........................................................................................................ 85
8
Seznam použitých zdrojů ........................................................................ 87
9
Přílohy ..................................................................................................... 90
8
Seznam obrázků
Obrázek 1 - Přenos pošty internetem ......................................................................... 25
Obrázek 2 - zpracování zpráv poštovním serverem Postfix ...................................... 27
Obrázek 3 - Zjednodušené schéma komunikace klienta a serveru ............................ 32
Obrázek 4 Architektura Apache ................................................................................ 34
Obrázek 5 - Architektura jádra Apache .................................................................... 35
Obrázek 6 - MPM prefork ......................................................................................... 37
Obrázek 7 - MPM worker .......................................................................................... 37
Obrázek 8 - Nginx a procesy ..................................................................................... 44
Obrázek 9 - Hierarchie konfiguračního souboru nginx.conf ..................................... 47
Obrázek 10 - Vzhled webové aplikace Roundcube ................................................... 62
Seznam tabulek
Tabulka 1 - Podíl WWW serverů leden 2011 ........................................................... 33
Tabulka 2 - Maximálně naměření počet požadavků za sekundu test H1................... 76
Tabulka 3 - Maximálně naměřený počet požadavků za sekundu testy P1 a P2 ........ 78
Tabulka 4 - Využití paměťi v MB při 100 session .................................................... 83
Seznam grafů
Graf 1 - využití CPU v testu H1 ................................................................................ 76
Graf 2 - využití paměti v testu H1 ............................................................................. 77
Graf 3 - průměrná doba odpovědi v testu H1 ............................................................ 77
Graf 4 - využití CPU v testu P1 ................................................................................. 79
Graf 5 - využití paměti v testu P1 .............................................................................. 80
Graf 6 - průměrná doba odpovědi v testu P1 ............................................................. 80
Graf 7 - využití CPU v testu P2 ................................................................................. 81
Graf 8 - využití paměti v testu P2 .............................................................................. 82
Graf 9 - průměrná doba odpovědi v testu P2 ............................................................. 82
9
1 Úvod
Operační systém Linux vznikl z unixového systému Minix. U jeho zrodu stál
Linus Torvald, který oslovil širokou programátorskou veřejnost, aby se podílela na
vývoji jádra operačního systému. Jádro dostalo název Linux a bylo spojeno s
operačním systémem GNU, kterému chybělo jádro zajišťující chod systému. Tímto
spojením vznikl OS GNU(GNU’s Not Unix) /Linux (dále Linux).
V dnešní době však už není vývoj Linuxu pouze v rukou dobrovolníků.
Rozvoj Linuxu je z velké části realizován placenými vývojáři, které zaměstnávají
velké mezinárodní firmy jako například Rad Hat, IBM či Novell.
Vytvoření funkčního operačního systému spojením jádra, ostatních služeb a
aplikací však není jednoduchá věc, proto vznikají tzv. distribuce. Distribuce
umožňují uživatelům snadnou instalaci, přívětivé uživatelské prostředí a výběr
různých aplikačních sad. S rozšířením distribucí vzrostl zájem o tento operační
systém. I přes nárůst zájmu však na desktopech není příliš rozšířen.
Linux je využíván zejména na serverech a to především díky vysoké
výkonnosti, bezpečnosti a spolehlivosti. Další výhodou používání Linuxu na serveru
je jeho finanční dostupnost - je zdarma. Přestože je zdarma, platí větší firmy
využívající Linux, výrobcům distribucí za speciálně upravené distribuce či podporu.
Vzhledem k tomu, že Linux je zdarma, je oblíben u malých firem, které
provozováním Linuxu ušetří na výdajích za nákup licencí. Avšak provozování
vlastního Linuxového serveru klade vyšší nároky na znalosti IT pracovníků.
Tato diplomová práce se věnuje konfiguraci Linuxového serveru pro malou
firmu. Nejdříve jsou popsány základní vlastnosti a chování operačního systému
Linux. Dále se práce zabývá popisem základních služeb poskytovaných interním
serverem v malé firmě. Jedná se o Samba server (náhrada Windows serveru, sdílení
souborových systémů a tiskáren), poštovní server včetně IMAP serveru a webový
server. V další části práce jsou pak jednotlivé služby nastaveny s podrobným
komentářem.
10
S dynamickým rozvojem internetu a zejména webových aplikací, se stávají
webové servery klíčovým prvkem mnoha firem. Proto je tato práce zaměřena na
podrobný popis dvou softwarových implementací webového serveru (Apache a
Nginx). Oba tyto webové servery budou nakonfigurovány a následně podrobeny
výkonnostním testům v prostředí místní sítě.
Téma diplomové práce autor zvolil z důvodu zájmu o operační systém Linux.
Autor se poprvé s tímto operačním systémem seznámil při výuce předmětu Operační
systémy II a zaujal ho zejména svojí dostupností, stabilitou a možností vlastní
modifikace. Autor práce si prohloubil své znalosti a zkušenosti při správě svého
vlastního domácího Linuxového serveru.
11
2 Cíl práce a metodika
2.1 Cíl práce
Cílem práce je popsat konfiguraci serveru pro prostředí malé firmy a
otestování výkonnosti několika implementací webových serverů. V rámci
vymezeného cíle budou nejdříve analyzovány obecné vlastnosti operačního systému
Linux a následně popsány základní síťové služby (DHCP, DNS, Samba server,
poštovní server a webový server), se zaměřením na popis dvou softwarových
implementací webového serveru.
Dále bude realizována implementace poznatků v podobě praktického
nastavení serveru malé firmy se zaměřením na jednotlivé sítové služby. Dále budou
otestovány a zhodnoceny dvě softwarové implementace webových serverů, včetně
několika alternativních konfigurací.
2.2 Metodika
K vypracování diplomové práce budou použity dostupné literární a
internetové zdroje uvedené v seznamu literatury. Teoretická část diplomové práce
vznikne hlavně na základě zahraničních/cizojazyčných dokumentů dostupných na
internetu. Z českých zdrojů bude použita hlavně kniha E.Nemetha, G. Snydera a T.
Heina „Kompletní příručka administrátora“, 2008 a Linux administrace serveru
Apache od Ch. Auldse.
Internetové zdroje budou podrobeny kritickému zhodnocení, protože ne
všechny mají odpovídající validitu. Čerpáno bude i ze starších zdrojů. I přes rychlý
vývoj OS Linux, zůstává základní konfigurace téměř nezměněna.
V první části práce autor nastíní důležité vlastností OS Linux. Uvede zde
obecné vlastnosti a základní principy jako například řízení přístupu či způsob
zpracování programů.
V druhé části autor popíše základní síťové služby, Samba server, poštovní
server a dvě softwarové implementace webového serveru. U každé služby budou
nejdříve uvedena teoretická východiska a následně autorův návrh na jejich
12
implementaci v praktické části. Z důvodů rozsáhlosti tématu se autor nebude věnovat
zabezpečení.
V praktické části autor uvede vlastní konfiguraci serveru pro malou firmu.
Veškeré navržené nastavení bude ověřeno na vlastním serveru, který bude
charakterizován v praktické části práce. Konfigurace serveru bude realizována z
prostředí příkazového řádku. Zhodnocení konfigurací webových serverů bude
provedeno na základě testů, které proběhnou dle stanovené testovací metodiky.
Metodika testování bude popsána v šesté kapitole.
13
3 Operační systém Linux
Operační systém Linux spadá do skupiny Unix systémů. Standardy používané
Unix systémy jsou spravovány konsorciem Open Group, které je držitelem ochranné
známky Unix.
Operační systém Linux je víceúlohový a víceuživatelský. Podporuje různé
32bitové i 64bitové architektury. Proto lze dnes Linux nalézt například v palubních
počítačích automobilů či v myčce na nádobí.
Linux se skládá z jádra a systémových programů. Jádro operačního systému
je vrstva mezi hardwarem a běžícími procesy. Mezi jeho hlavní úkoly patří ovládat
veškerý hardware počítače, spravovat procesy, paměť a řídit přerušení. Systémové
programy slouží k základní práci se systémem a jsou dodávány s operačním
systémem (například interprety příkazů, programy pro podporu síťové komunikace či
programy pro práci se systémy souborů). [1 str. 15]
3.1 Uživatelé
Uživatelé v operačním systému Linux jsou identifikováni uživatelským
jménem. Všem uživatelům systému proto musí být přiděleno jednoznačné
uživatelské jméno.
Interně operační systém Linux používá dva identifikátory - uživatel (UID) a
skupina (GID). Ke každému uživatelskému jménu je přiřazeno unikátní číslo UID
(User ID). Druhým identifikátorem je skupina. Skupiny mají svoje jména a
identifikační čísla podobně jako uživatelé. Identifikační číslo skupiny se označuje
GID (Group ID). Použití UID a GID čísel umožňuje efektivní identifikaci jádrem
operačního systému. [2 str. 132]
Každý uživatel musí být členem alespoň jedné skupiny, a jedna
z uživatelových skupin je vždy nastavena jako výchozí. Tato skupina se používá
například pro vytváření nových souborů a adresářů. [2 str. 133]
V Linuxu obecně existují dva typy uživatelů. První je speciální uživatel root
(superuživatel) a druhým typem jsou ostatní uživatelé (běžní uživatelé).
14
Účet root může být v systému jen jeden, a využívá se pro správu operačního
systému. Dovoluje provádět nastavení a operace, které nejsou dostupné běžným
uživatelům. Root má UID = 0 a může provádět jakékoliv operace v operačním
systému bez omezení. Například má přístup ke všem souborům a procesům bez
ohledu na aktuálně nastavená přístupová práva. Root je také vlastníkem všech
systémových souborů a procesů. [3 str. 95]
Ostatní uživatelé mohou provádět pouze činnosti, na které mají oprávnění, a
pracovat se soubory, ke kterým mají oprávnění. Oprávnění se vyhodnocují
operačním systémem na základě UID a GID. [2 str. 134]
3.1.1 Řízení přístupu
Řízení přístupu zajišťuje jádro operačního systému Linux. Základním
schématem pro řízení přístupu v operačním systému Linux je volitelné řízení
přístupu (DAC - Discretionary Access Control). Volitelnost spočívá v tom, že
přístupová
práva
k objektu
definuje
identifikovaný
subjekt
s příslušnými
oprávněními (většinou vlastník objektu). Největším problémem tohoto přístupu je
možnost, že identifikovaný subjekt špatně nadefinuje přístupová práva, případně
zruší všechna přístupová práva. [4] [5]
DAC definuje základní řízení přístupu k objektům (například soubory,
adresáře, I/O zařízení) v systému. Poskytuje omezení přístupu k objektům na základě
identity subjektů (například uživatele či skupiny), kteří k objektům přistupují.
V případě, že má objekt nadefinována přístupová práva, systém ověří, zda je daný
identifikovaný subjekt splňuje. Pokud přístupová práva identifikovaný subjekt
splňuje, jsou mu povolena operace s objektem podle definovaných práv. [5] [6]
V Linuxu je možné implementovat jiné metody řízení přístupu pomocí
bezpečnostních modulů v jádře (LSM – Linux Security Modules). [4]
Například povinné řízení přístupu (MAC – Mandatory Access Control) či
řízení přístupu rolemi (RBAC – Role Based Access Control).
V případě MAC jsou přístupová práva k objektům definována správcem
systému, a subjekty je nemohou měnit (ani v případě vlastnictví). MAC v Linuxu je
možno realizovat pomocí LSM – SELinux, AppArmor a Tomoyo. [6]
15
RBAC je alternativou k DAC a MAC typům řízení přístupu. V RBAC je
řízení přístupu založeno na rolích, které jsou přiřazeny subjektům v systému
(například manažer, prodavač, správce obsahu webových stránek, atd.). Role mají
jasně definována přístupová práva k objektům v systému. RBAC je možné
implementovat pomocí LSM SELinux. [7]
3.2 Procesy a vlákna
Linux je víceúlohový systém, což znamená, že současně zpracovává více úloh
(procesů). Proces je běžící program, který využívá systémové prostředky. Obecně lze
procesy rozdělit na uživatelské (spuštěné běžným uživatelem) a systémové (spuštěné
automaticky při startu operačního systému či na základě nějaké události). [1 str. 10]
Mezi systémové procesy patří také procesy běžící na pozadí, tzv. démoni
(daemons), kteří vykonávají specifické činnosti. Většina démonů se aktivuje během
spouštění systému a pokračují v činnosti až do svého ukončení. [8 str. 43]
Každý proces běží pod UID a GID určitého uživatele. Přístup je řízen na
základě
přístupových
práv
tohoto
uživatele.
Procesy
jsou
identifikovány
jednoznačným identifikátorem PID (Process ID), který je celé kladné číslo. Při
spuštění dalšího procesu je použito v řadě navazující číslo. V případě, že je proces
ukončen, není jeho číslo znovu použito dokud systém nedojde až na konec
používaného rozsahu čísel. Poté systém začne číslovat od začátku. [1 str. 59]
Při startu systému je spuštěn proces init, který má vždy PID = 1. Všechny
další procesy jsou jeho potomci a jeho ukončení vede k vypnutí systému. Další
procesy vznikají voláním služby systému fork(). Init tedy zavolá službu fork a spustí
další systémové procesy. Po zavolání služby fork() vytvoří systém nový proces, který
je přesnou kopií procesu, jenž službu zavolal, jeho PID je však vždy změněno. [2 str.
94]
Proces, který službu fork() zavolal, se nazývá rodič a nově vzniklý proces je
jeho potomek. Každý proces má také ukazatel PPID (Parent Process ID), který udává
PID rodičovského procesu. V případě, že má být proces řízen jiným programem,
musí potomek použít volání služby exec(), která spustí nový řídící program. [1 str.
58]
16
Vlákno (thread) je instance hlavního procesu (procesu, který vytváří vlákno).
Vlákno nemůže existovat samostatně bez hlavního procesu. Sdílí přidělené
prostředky hlavního procesu s ostatními vlákny tohoto procesu, a je identifikováno
pomocí TID (Thread ID). TID hlavního procesu je rovno PID, a všechna vlákna
hlavního procesu mají stejné PID.
Při spuštění programu se vytvoří hlavní proces, který může spustit další
vlákna pomocí služby clone(). Všechna tato vlákna pak běží nezávisle na sobě
(paralelně), a mohou vykonávat různé části programu. [2 str. 94]
3.2.1 Kontext procesu
Proces má svůj uživatelský a systémový kontext. Uživatelský kontext procesu
je obsah jeho adresového prostoru a uživatelských registrů procesoru. Adresový
prostor se skládá z programového kódu, dat a zásobníku. Programový kód obsahuje
strojové instrukce spuštěného programu, oblast dat pak programem definovaná data.
Lokální proměnné, parametry volání funkcí a návratové adresy se ukládají do
zásobníku. Uživatelský kontext tvoří obsah pracovních a stavových registrů. [1 str.
57]
Systémový kontext procesu jsou informace, které operační systém používá
pro řízení procesů. Například obsah systémových registrů, tabulky paměťových
stránek a systémového zásobníku. Tyto informace jsou uloženy v tabulce procesů a v
uživatelské oblasti (tzv. u-area). [1 str. 57]
Tabulka procesů obsahuje informace, které systém potřebuje mít dostupné i
v případě, že daný proces neběží. Například PID, stav procesu, priorita procesu,
spotřebovaný procesorový čas, pole dosud zaslaných signálů, ukazatel do u-area atd.
Tabulka procesů je neustále přístupná operačnímu systému v hlavní paměti. [1 str.
57]
U-area obsahuje informace, které nemusí být dostupné. Jedná se zejména o
UID a GID, aktuální a kořenový adresář, I/O parametry, tabulku deskriptorů
otevřených souborů a další. [1 str. 57]
17
3.2.2 Přidělování procesoru
V jednu chvíli může být zpracováván pouze jeden proces na jednom
procesoru (CPU – Central Processing Unit). O tom, kterým procesům bude tento
procesor přidělen, rozhoduje plánovač. Procesy jsou vybírány z tabulky procesů, jenž
mohou být spuštěny. Výběr je proveden na základě statické priority pohybující se
v intervalu 0 - 99. Vždy platí, že k běhu je vybrán proces s největší statickou
prioritou. [9]
Pokud je plánovačem vybrán jiný proces ke zpracování, musí operační
systém provést změnu kontextu. Tato změna zahrnuje změnu obsahu u-area a
obnovení obsahu pracovních, stavových a systémových registrů nově zařazeného
procesu. Samotná změna kontextu závisí na architektuře, na které je systém
provozován, a není součástí plánovače. Změna kontextu je většinou velmi časově
náročná, a proto je vhodné se jí vyhýbat. [1 str. 153] [9]
3.2.3 Řízení procesů
Běžící proces lze ovlivnit pomocí signálů. Pokud proces přijme signál, může
nastat jedna ze dvou situací. V případě, že má proces definovanou rutinu pro
zpracování daného signálu, tato rutina se provede. Tomuto postupu se říká
„zachycení signálu“. Pokud rutina není definována, jádro podnikne s procesem
implicitní akci, jenž může být pro každý signál jiná, ať už se jedná o ukončení
procesu, jeho pozastavení nebo odblokování. [2 str. 95]
Proces může signály ignorovat či zablokovat. V prvním případě je signál
ignorován a nemá na proces žádný vliv. Zablokovaný signál je ignorován, avšak je
zařazen do fronty pro dodání. Proces ho může zpracovat později po jeho
odblokování. [2 str. 95]
Některé signály nemohou být zachyceny, blokovány či ignorovány. Jedná se
o signály KILL a STOP. Signál KILL ukončí proces na úrovni operačního systému,
tudíž proces tento signál nikdy neobdrží. Signál STOP zastaví proces až do přijetí
signálu CONT, který obnoví jeho činnost. [2 str. 96]
18
3.3 Souborový systém
Linux,
podobně jako
ostatní
Unixové operační
systémy,
používá
hierarchický souborový systém se stromovou strukturou. V systému existuje pouze
jeden kořenový adresář označený '/'. Další souborové systémy se pak mohou připojit
do kterékoli větve souborového systému. [8 str. 16]
Hlavním účelem souborového systému je efektivně a bezpečně číst/ukládat
data z/do souborů. Většina Linuxových distribucí používá implicitně souborový
systém ext3 / ext4, nabízí však i jiné souborové systémy, jako například ReiserFS,
JFS, XFS, ext2 a síťový souborový systém (NFS). Dále podporuje souborové
systémy ostatních operačních systémů, jako například FAT, NTFS apod. Volba
souborového systému může výrazně ovlivnit výkonnost i bezpečnost celého systému.
[2 str. 108]
3.3.1 Přístupová práva
Každý objekt v Linuxu (soubor, program či spuštěný proces) má nastavena
přístupová práva. Pro soubory tato práva definují, kdo má oprávnění soubory číst,
měnit či spouštět. U spuštěných procesů nebo běžících programů je tím řečeno, kdo
má práva tyto procesy zastavovat či s nimi jinak manipulovat. To, jak jsou přístupová
práva nastavována, závisí na metodě řízení přístupu. Základní metoda řízení přístupu
DAC využívá bitů oprávnění případně bitů setuid, setgid a sticky. [1 str. 78] [2 str.
118]
Bitů oprávnění je devět a určují, které operace mohou subjekty s objekty
provádět a kdo je může provádět. Práva se specifikují pro tři kategorie, a to pro
vlastníka, skupinu a ostatní uživatele. Pro každou kategorii jsou rezervovány 3 bity.
První bit definuje právo číst, druhý bit právo zápisu a třetí bit právo spouštění (v
případě adresáře tento bit znamená právo čtení z adresáře). Jestliže je právo
přiděleno, odpovídající bit se rovná 1, pokud přiděleno není, daný bit je nastaven na
hodnotu 0. [2 str. 118]
Bity setuid a setgid mají svůj význam hlavně u programů a procesů. Jsou
nadstavbou klasických oprávnění (9 bitů), a umožňují řízené předávání přístupových
práv. Oprávnění setuid a setgid má význam hlavně u programů a procesů. V případě,
19
že má program nastavený setuid nebo setgid bit, převezme práva vlastníka (nebo
skupiny) programu, nikoliv toho, kdo jej spustil. To umožňuje například běžnému
uživateli spustit program jako root (změna hesla do systému apod.). [1 str. 79] [2 str.
119]
Root může ovlivnit nastavení výchozího oprávnění objektů. V případě, že
uživatel vytvoří nový objekt, bude automaticky mít rootem definovaná přístupová
práva.
20
4 Síťové služby
4.1 Základní síťové služby
Operační systém Linux podporuje více síťových rozhraní a standardně
používá komunikační protokol TCP/IP (Transmission Control Protocol/Internet
Protocol). Může však používat i další protokoly, například IPX (Internetwork Packet
Exchange) a SPX (Sequenced Packet Exchange).
4.1.1 TCP/IP
Pro konfiguraci síťového rozhraní můžeme použít dva typy nastavení,
statické nebo dynamické. Statické nastavení se provádí použitím příkazů (například
ifconfig či ip) nebo přidáním záznamů do konfiguračních souborů. Dynamické
nastavení používá DHCP (Dynamic Host Configuration Protocol), který umožňuje
automaticky nastavit všechny potřebné konfigurační parametry pro síťovou
komunikaci. [3 str. 359]
Základní konfigurační parametry pro IP protokol jsou IP adresa, síťová
maska, výchozí brána a DNS (Domain Name System) server. [2 str. 321]
4.1.2 DHCP
Dynamické nastavení IP konfigurace síťových rozhraní se provádí pomocí
DHCP protokolu. DHCP protokol automaticky nastavuje síťové konfigurační
parametry. DHCP server přiděluje síťové konfigurační parametry na základě
požadavku klienta, který posílá požadavek serveru při startu systému. [3 str. 360]
DHCP server přiděluje konfigurační parametry na základě MAC adresy
přijatého požadavku. Parametry poskytnuté DHCP serverem se ukládají do interní
databáze a jsou platné na předem stanovenou dobu (tzv. lease time). DHCP server
musí přidělit minimálně IP adresu, dále může přidělit síťovou masku, výchozí bránu
DNS servery a další nakonfigurované parametry. Klient si musí požádat o obnovení
přidělených parametrů před vypršením jejich platnosti. Po vypršení lease time může
být IP adresa přidělena jinému klientovi.
DHCP server musí mít definovaný rozsah IP adres, které může přidělit
klientům. Standardně je IP adresa dynamicky přidělována z tohoto rozsahu.
21
V případě, že je požadována pevná IP adresa pro klienta, je možné konfigurovat
požadovanou IP adresu pro příslušnou MAC adresu klienta. Tím se zajistí, že klient
obdrží vždy stejnou IP adresu. [2 str. 335]
Pro IP konfiguraci síťových rozhraní v naší firmě použijeme dynamickou
konfiguraci pomocí DHCP. DHCP server bude klientům ve firmě poskytovat IP
adresy, masku sítě, výchozí bránu, DNS server a interní doménu. Z důvodu
dostatečného počtu IP adres v síti nastavíme lease time na délku jednoho dne.
Protože pro interní doménu bude použit DNS server, je nutné zajistit
aktualizaci IP adres v příslušné doméně. Bude nutné nakonfigurovat DHCP a DNS
server pro použití DDNS (Dynamic DNS) protokolu, který tuto aktualizaci zajistí.
4.1.3 DNS
DNS se primárně používá pro překlad doménového jména na IP adresu, ale
obecně může poskytovat i další informace svázané s doménovým jménem.
Existují tři druhy jmenných serverů. Primární DNS servery, které jsou
označovány jako autoritativní a jsou na nich uložena veškerá data příslušné domény,
včetně informací o všech subdoménách této domény. Každá doména musí mít svůj
primární DNS server na kterém je uložena konfigurace dané domény. [3 str. 226]
Sekundární DNS servery udržují kopie dat z primárních serverů pro příslušné
domény. Sekundární servery si automaticky aktualizují informace z primárních
serverů buď na základě konfiguračních údajů v doméně, nebo na základě upozornění
z primárního serveru, že došlo ke změně údajů v doméně. [3 str. 226]
Třetím druhem jmenných serverů jsou pomocné servery (caching servery).
Tyto servery nejsou registrovány v žádné doméně a neobsahují žádné konfigurační
soubory, pouze si ukládají odpovědi na dotazy, které jimi prošly, což zvyšuje
rychlost odpovědi a snižuje zatížení ostatních DNS serverů. V současnosti se
v důsledku většího množství dotazů na neexistující údaje používá negativní caching.
Ten ukládá odpovědi typu neexistence domény, serveru, požadovaných dat či
nedostupnost serveru kvůli síťovým problémům. [3 str. 226] [10]
22
Dále se jmenné servery rozdělují na rekurzivní a nerekurzivní. Nerekurzivní
servery vrací odpověď jen v případě, že mají dotaz uložený v cache paměti, případně
pokud jsou autoritativní pro danou doménu. Jinak pošle jen odkaz na autoritativní
server jiné domény. Rekurzivní servery v případě, že neznají odpověď (není
autoritativní pro doménu, na kterou se ptáme), spustí standardní algoritmus pro
vyhledání odpovědi (tj. začne u kořenových DNS serverů a postupuje do nižších
úrovní až k cíli). Klientovi pak pošle až konečný výsledek. [2 str. 431]
Databáze DNS pro určitou doménu obsahuje více souborů, které jsou uloženy
na primárním jmenném serveru domény. Informace v databázi DNS obsahují
zdrojové záznamy (RR – Resource Records). Zdrojové záznamy dělíme na zónové,
základní, bezpečnostní a volitelné. [2 str. 411]
Mezi zónové záznamy patří například záznam SOA a NS. Záznam SOA
(Start Of Authority) určuje jmenný server, který je autoritativním zdrojem informací
pro danou doménu. Záznam SOA je vždy právě jeden, a nachází se vždy na začátku
souboru. NS (Name Server) záznam definuje, které jmenné servery jsou autoritativní
pro danou zónu. [2 str. 412]
Mezi základní záznamy se řadí A, AAAA, PTR a MX záznamy. Záznam A
(IPv4) a AAAA (IPv6) slouží k převodu jména na IP adresu. Typ záznamu PTR
(PoinTeR) slouží k zpětnému překladu IP adresy na jméno. Záznam MX (Mail
Exchange) určuje server, který přijímá poštu pro danou doménu. [2 str. 415]
Bezpečnostní záznamy jsou záznamy typu DS (Delegation Signer), DNSKEY
(DNS public KEY), NSEC (Next SECure) a RRSIG (Resource Record SIGniture).
Tyto záznamy slouží k ověření platnosti údajů o zónách a k ověření jejich integrity
pomocí veřejného klíče. [2 str. 411]
Mezi volitelné záznamy patří například CNAME nebo TXT záznamy.
CNAME (Canonical NAME) záznam nám umožňuje vytvořit alias pro název
jakéhokoliv počítače. Záznam TXT nám umožňuje přidat libovolný text. [2 str. 415]
Předpokládáme použití DNS pro interní síť a pro přístup k internetu. Pro
interní síť použijeme název domény, který nesmí kolidovat s názvy domén
23
používaných v internetu. DNS server musí být nakonfigurován na spolupráci
s DHCP serverem pomocí protokolu DDNS.
Doba života záznamů (TTL – Time To Live) pro interní doménu by měla být
krátká, aby se změny v DNS projevily v co nejkratším čase. V případě, že by byla
doba života záznamů příliš krátká, bude docházet k zvýšenému zatěžování DNS
serveru častými dotazy. Pro případ změny v interním DNS nastavíme hodnotu TTL
na 1 hodinu.
Pro rezoluci internetových jmen je nutné nastavit DNS forwarder, který bude
předávat dotazy z vnitřní sítě na DNS servery v internetu. Vhodné jsou DNS servery
poskytovatele internetového připojení, které jsou obvykle umístěny v jeho páteřní síti
a mají krátkou dobu odezvy z firemní sítě i internetu.
4.2 Samba
Samba je balík aplikací umožňujících komunikaci a výměnu dat mezi
operačními systémy Linux a Microsoft Windows. Samba využívá stejné protokoly
jako operační systémy Windows. Jedná se o protokoly SMB/CIFS (Server Message
Block/Common Internet File System). To umožňuje přistupovat z operačních
systémů Windows na Linuxový server a naopak. [3 str. 337]
Samba nabízí celou řadu možností, například sdílení souborů a tiskáren,
síťový tisk, autentizaci a autorizaci a vyhledávání NetBIOSových (Network Basic
Input Output System) jmen. Může také provádět funkce PDC (Primary Domain
Controller), což je primární doménový řadič v Microsoft sítích, jenž se stará o správu
dané Windows domény. [3 str. 338]
Funkce Samby jsou poskytovány démony smbd a nmbd. Démon smbd
zajišťuje TCP/IP komunikaci, autentizaci a sdílení souborových systémů a tiskových
služeb. Tento démon naslouchá na portu 139 a čeká na požadavky. V případě, že se
uživatel autentizuje, smbd démon spustí svoji novou kopii, která dostane přístupová
práva uživatele, a potom obsluhuje požadavky uživatele. [2 str. 828]
24
Démon nmbd zajišťuje vyhledávání jmen a ohlašování služeb. Lze ho také
nastavit jako WINS (Windows Internet Name Server) server. To znamená, že nmbd
bude odpovídat na příslušné dotazy této služby. [3 str. 339]
Díky odlišnému způsobu šifrování hesel v operačních systémech Windows
nelze použít k ověření soubor /etc/shadow. Proto si systém samba musí vytvořit
vlastní soubor se zašifrovanými hesly. Uživatele a hesla do tohoto souboru přidává
superuživatel pomocí příkazu smbpasswd. Tento příkaz také umožňuje uživatelům
změnit si jejich heslo pro přístup do systému samba. [2 str. 829]
V naší firmě se nepředpokládá využití serveru s operačním systémem
Windows, proto bude Samba sloužit jako primární řadič Windows domény. Dále
bude poskytovat jmenné služby pro NetBIOS síť (WINS) a souborové služby.
4.3 Poštovní server
Linux používá elektronickou poštu založenou na protokolu SMTP (Simple
Mail Transfer Protokol). Protokol SMTP je v podstatě normou pro přenos pošty po
internetu a pouze definuje způsob, jakým se posílají zprávy z jednoho hostitelského
počítače na druhý. Nedefinuje způsob ukládání zpráv či způsob, jakým by měl
poštovní server posílat poštu. Základní schéma přenosu elektronické pošty od
odesílatele k příjemci je zobrazeno na obrázku č. 1. [11]
Obrázek 1 - Přenos pošty internetem
25
Systém elektronické pošty je založen na čtyřech hlavních komponentách:
uživatelská poštovní aplikace MUA (Mail User Agent), aplikace pro přenos pošty
MTA (Mail Transfer Agent), aplikace pro doručení pošty MDA (Mail Delivery
Agent) a přístupová aplikace AA (Access Agent). [2 str. 544]
MUA umožňuje uživatelům vytvářet a číst elektronickou poštu. Při odesílání
pošty MUA předá zprávu k doručení aplikaci MTA.
MTA se stará o doručení zprávy na poštovní server adresáta. Po převzetí
zprávy od MUA doplní hlavičku zprávy o další údaje. Z adresy určí, který počítač je
zodpovědný za přijímání pošty pro danou doménu, následně naváže s tímto
počítačem spojení a zprávu mu odešle. MTA na poštovním serveru adresáta zprávu
zpracuje a předá ji MDA. MDA se postará o doručení zprávy do poštovní schránky
(datových souborů) příjemce. [2 str. 544]
AA umožňuje vzdálené připojení uživatelské aplikace k poštovní schránce na
serveru. Zajišťuje přenos pošty, který se provádí pomocí protokolů POP (Post Office
Protocol) nebo IMAP (Internet Message Access Protocol). [2 str. 545]
4.4 Poštovní server Postfix
Základními vlastnostmi poštovního serveru Postfix jsou modulárnost a
bezpečnost. Na rozdíl od některých jiných poštovních serverů (například sendmail),
které fungují jako jeden proces obsluhující požadavky na posílání i přijímání pošty,
se skládá z několika modulů. Každý modul je zodpovědný za jednu specifickou
činnost a pracuje jako samostatný proces. Díky oddělení jednotlivých procesů je
zajištěna bezpečnost a spolehlivost poštovního serveru. [11]
Postfix je implementován jako hlavní proces (master), který podle potřeby
spouští obslužné démony vykonávající specifické činnosti. [12]
•
smtpd – přijímá SMTP zprávy, zajišťuje kontrolu správnosti a předává
zprávy démonu cleanup.
•
pickup – přebírá lokální zprávy, provádí jejich kontrolu a předává je démonu
cleanup.
26
•
cleanup – zpracovává přijatou zprávu (například přidává chybějící informace
a hlavičky), vkládá ji do fronty přijatých zpráv a informuje démona qmgr o
příchodu nové zprávy.
•
qmgr – klíčový démon pro řízení doručování pošty. Čeká na nové zprávy ve
frontě přijatých zpráv. Způsob doručení určuje démon trivial-rewrite.
•
trivial-rewrite – formátuje adresu příjemce do standardního formátu
(například přidá doménu k lokálním zprávám) a určuje způsob doručení
příjemci (určí doručovacího agenta). [12]
4.4.1 Zpracování pošty
Obrázek 2 - zpracování zpráv poštovním serverem Postfix
Postup zpracování zpráv poštovním serverem Postfix je zobrazen na obrázku
č. 2. Zprávy přijaté ze sítě jsou přijaty démony smtpd (SMTP protokol) nebo qmqpd
(QMQP protokol). Démoni provedou elementární kontroly náležitostí zprávy a
předají zprávu démonu cleanup. Lokálně vytvořené zprávy (pomocí sendmail) se
předají programu postdrop, který zprávy uloží do maildrop fronty. Zprávy jsou
uloženy do maildrop fronty bez ohledu na to, zda Postfix systém běží. Démon
pickup periodicky kontroluje nové zprávy v maildrop frontě a předává je démonu
cleanup. [12]
Démon cleanup zajišťuje kontrolu obsahu hlavičky a doplnění chybějících
údajů. Zprávu předá démonu trivial-rewrite, který má na starosti ověření adresy a
její případnou změnu. Po úpravách adresy trivial-rewrite vrátí zprávu démonu
cleanup, který poštu zařadí do fronty příchozích zpráv a upozorní démona qmgr o
příchodu nové zprávy. [12]
27
Démon qmgr spravuje dva typy front – active a deferred. Active je malá
fronta s právě doručovanými zprávami. Fronta deferred obsahuje zprávy, které není
možné z nějakého dočasného důvodu doručit. Démon qmgr se pokouší znovu
odeslat zprávy ve frontě deferred v určitém časovém intervalu (je řízen pomocí
algoritmu). Qmgr zprávu předá démonovi trivial-rewrite, který rozhodne, jestli je
adresa místní nebo vzdálená a určí způsob doručení zprávy (mail delivery agent).
Trivial-rewrite vrátí zprávu démonu qmgr, který ji předá příslušnému MDA. [12]
Poštovní server Postfix používá následující MDA:
•
smtp – smtp klient Postfixu. Doručuje zprávy, které jsou určeny pro jiné
poštovní servery a stará se o vyhledání cílového poštovního serveru. Také má
na starost vytvoření SMTP zprávy.
•
lmtp – doručuje zprávy pomocí protokolu LMTP (Local Mail Transfer
Protocol)
•
local – doručuje zprávy do lokálních Unixových poštovních schránek na
serveru (tj. pro reálně existující uživatele operačního systému, mají záznam
v souboru /etc/passwd).
•
virual – umožňuje doručení uživatelům, kteří nejsou definovaní v operačním
systému.
•
pipe – je interface, který předává zprávy k dalšímu zpracování. [12]
4.4.2 Nastavení poštovního serveru
Hlavní konfigurační soubor aplikace Postfix je /etc/postfix/main.cf.
Zde se nastavují parametry poštovního serveru, cesty k ostatním součástem aplikace
Postfix, síťové informace a informace o databázi aliasů. [2 str. 636]
Dalším důležitým souborem je /etc/postfix/master.cf, ve kterém
se konfigurují jednotlivé procesy, jež řídící program master obsluhuje. Například se
jedná o ladění výkonu jednotlivých procesů, integraci filtrů na úrovni procesu a
řízení některých mechanizmů ovlivňujících procházející zprávy. [2 str. 636]
Postfix umožňuje použít virtuální poštovní schránky. Virtuální schránky
definujeme v souboru /etc/postfix/virtual.
28
4.4.3 Filtrování obsahu pošty
Filtrováním obsahu pošty se rozumí ochrana proti virům a nevyžádaným
zprávám. Poštovní server Postfix nedisponuje interní filtrací obsahu pošty z námi
definovaného pohledu. Pomocí zabudovaného mechanismu umožňuje pouze
jednoduchou filtraci obsahu na základě prohlížení záhlaví a těla zprávy.
Plnohodnotné filtrování tak, jak bylo definováno, lze realizovat pomocí externích
specializovaných aplikací. [12]
Ochrana proti virům a nevyžádaná pošta mají velmi odlišné požadavky na
kontrolu. Z tohoto důvodu jsou většinou realizovány oddělenými aplikacemi. Postfix
umožňuje snadnou spolupráci s těmito aplikacemi. Pro filtrování obsahu se většinou
používá kombinace několika aplikací. Pro Postfix je možno použít např. kombinaci
Amavis+SpamAssasin+ClamAV.
4.4.4 Navrhované řešení
Uživatelé nebudou pracovat v operačním systému Linux, a proto nebude
konfigurována lokální pošta. Předpokládá se doručování elektronické pošty pomocí
SMTP protokolu. Poštovní server bude obsluhovat internetovou doménu firma.cz.
Předpokladem pro správnou funkci je nezbytný příslušný MX záznam v internetové
doméně firma.cz.
Uživatelé budou přistupovat k poštovním schránkám mailovým klientem
pomocí IMAP protokolu. Alternativně mohou využít webového rozhraní. Pro přístup
k elektronické poště bude využita autentizace účtem Windows domény.
Pro vlastní doručování pošty bude využit poštovní server Postfix. Přístup ke
schránkám bude zajišťovat IMAP server Dovecot. Přístup ke schránkám pomocí
webového prohlížeče bude realizován aplikací Roundcube.
Poštovní schránky budou umístěny v odděleném zabezpečeném prostoru a
budou přístupny pouze speciálnímu uživateli, který bude zajišťovat doručování a
uživatelskou manipulaci se zprávami. Uživatelé nebudou mít přímý přístup ke
schránkám, přístup bude zajištěn pouze pomocí výše uvedených aplikací.
Pro ukládání zpráv do schránek bude použit formát Maildir. V tomto formátu
je každá zpráva uložena jako samostatný soubor s unikátním názvem.
29
Bezpečnost přístupu k poštovním schránkám a odesílání pošty bude zajištěna
autentizací uživatelů. Autentizace bude řešena přes PAM (Pluggable Authentication
Module) rozhraní. Poštovní server Postfix bude využívat SASL (Simple
Authentication and Security Layer) rozhraní k autentizačnímu mechanismu serveru
IMAP.
4.5 WWW server
WWW (World Wide Web) server umožňuje pomocí protokolu HTTP (HyperText Transport Protocol) přenos objektů ke klientovi. Tyto objekty jsou
identifikovány globálními identifikátory, které se nazývají jednotné identifikátory
zdroje – URI (Uniform Resource Identifier). Většinou se jedná o HTML stránky, ale
mohou to být i různá data jako například obrázky, videa, soubory či CSS soubory.
HTTP je bezstavový protokol typu požadavek/odpověď (request/response), a
slouží pro přenos mezi klientem a serverem. Klient je ve většině případů webový
prohlížeč, který komunikuje se serverem pomocí HTTP zpráv. Klient zašle
požadavek obsahující řádek požadavku, hlavičky (které však nemusí být přítomny) a
tělo. Server přijme požadavek, interpretuje ho a zašle odpověď, která obsahuje řádek
odpovědi, hlavičky a tělo obsahující požadovaný objekt. [13]
Řádek požadavku se skládá z metody, která určuje službu požadovanou od
serveru, identifikátoru objektu (ve většině případů URI) a verze protokolu HTTP.
Řádek odpovědi obsahuje verzi HTTP protokolu, status code (kód stavu, což je
třímístné číslo, které informuje o výsledku požadavku, viz Příloha č. 1) a text
popisující status code. [14] [15]
Hlavičky jsou rozděleny do čtyř skupin. Obecné hlavičky jsou použitelné jak
pro požadavky, tak pro odpovědi, ale neaplikují se na přenášený obsah. Hlavičky
požadavku umožňují předat serveru další doplňující informace o požadavku či
klientovi. Hlavičky odpovědi slouží k předání doplňujících informací o odpovědi.
Jedná se o informace, které nemohou být sděleny pomocí status code. Hlavička
objektu popisuje metainformace o objektu přenášeném v těle zprávy. [16]
30
V případě požadavku tělo zprávy obsahuje data zadaná uživatelem. Tato data
jsou posílána na server za účelem zpracování. Tělo odpovědi obsahuje klientem
požadované objekty. [13]
Obsah odpovědi serveru může být generován staticky a to v případě, že je
klientovi odeslán požadovaný soubor uložený na serveru. Obsah odpovědi může být
také vytvořen dynamicky za pomocí aplikací, např. díky rozhraní CGI (Common
Gateway Interface), které umožňuje serveru komunikovat s externími aplikacemi
nebo PHP (PHP: Hypertext Preprocessor), ASP (Active Server Pages) či JSP
(JavaServer Pages). [17]
Protokol HTTP umožňuje dva druhy autentizace klienta – základní a digest.
Tyto způsoby autentizace jsou implementovány ve všech HTTP kompatibilních
www serverech a klientech. [18]
Základní autentizace klienta používá nešifrovanou výměnu ověřovacích
informací (uživatelské jméno a heslo). V případě, že server přijme požadavek na
chráněný obsah, vrátí klientovi odpověď s výzvou k autentizaci. Klient se pokusí
získat ověřovací informace buď přímo od uživatele (výzvou k zadání ověřovacích
informací) či z cache paměti. Ověřovací informace jsou pak ve formě čistého textu
zaslány serveru v hlavičce Authorization nového požadavku. Pokud server obdrží
požadavek s touto hlavičkou, ověří platnost ověřovacích informací a následně
zkontroluje, zda má uživatel k prostředku přístup. [18]
Autentizace digest má stejné schéma jako základní autentizace. Ani tato
metoda nezajišťuje jakékoliv šifrování přenášených dat. Liší se pouze v tom, že heslo
není nikdy posláno sítí. V případě, že klient obdrží odpověď, která ho vybízí
k autentizaci, získá ověřovací údaje od uživatele, a ty pak použije pro výpočet
kontrolních součtů (defaultně pomocí algoritmu MD5). Tyto kontrolní součty jsou
zaslány zpět serveru v novém požadavku. [18]
Protokol HTTP sám o sobě neumožňuje zašifrování přenášených dat mezi
klientem a serverem, ani ověření identity serveru. Z tohoto důvodu vznikl protokol
HTTPS (HyperText Transfer Protocol Secure), který zabraňuje pomocí šifrování
odposlouchávání, neoprávněným úpravám či falšování zpráv. Tento protokol vznikl
31
zkombinováním HTTP a šifrovacího protokolu SSL (Secure Socket Layer), či jeho
následovníka TSL (Transport Layer Security). [19] [2 str. 735]
Protokol SSL je protokolová vrstva ležící mezi transportní vrstvou (TCP/IP) a
aplikační vrstvou (HTTP). Používá jak asymetrické, tak symetrické šifrování. Pro
šifrování přenášeného obsahu používá symetrické šifrování. Asymetrické šifrování se
používá pro ověření serveru a výměnu klíče pro symetrické šifrování dat. Základní
schéma navázání SSL komunikace je zobrazeno na obrázku č. 3. [20 str. 425]
Obrázek 3 - Zjednodušené schéma komunikace klienta a serveru
Aby SSL fungovalo, mají pro svou identifikaci SSL servery digitální
ověřovací
certifikáty.
Tyto
certifikáty
jsou
digitální
soubory
podepsané
důvěryhodným zdrojem neboli CA (Certificate Authority). Digitální certifikáty mají
formát podle standardu X.509 a obsahují veřejný klíč serveru, dobu platnosti
certifikátu, podrobnosti o CA, která ho vydala, informace o držiteli certifikátu a tzv.
wrapper, který uzavírá informace certifikátu a jeho součástí je podpis CA. [2 str.
736] [20 str. 426]
Klient obsahuje seznam důvěryhodných CA a jimi podepsané certifikáty
přijme. Klient tedy může ověřit podpis veřejným klíčem CA a získat veřejný klíč
serveru. S pomocí veřejného klíče serveru může zaslat klíč pro symetrické šifrování
dat. V případě, že klient přijme certifikát od CA, kterou nemá na seznamu, uživatele
na to upozorní. Ten může následně rozhodnout, zda certifikát přijmout nebo ne, a zda
32
CA, která certifikát podepsala, zařadit mezi důvěryhodné nebo ho odmítnou. [2 str.
736]
WWW servery mohou využívat systém virtuálních serverů, což znamená, že
na jednom fyzickém stroji je více webových serverů. Virtualizace není však
z pohledu uživatele patrná. WWW servery se pak rozlišují buď podle doménového
jména, nebo podle IP adresy a portu, na kterém WWW server navazuje spojení. [2
str. 733]
V následujících dvou kapitolách autor popíše dvě softwarové implementace
WWW serveru pro operační systém Linux. Jak vyplývá z tabulky č. 1, nejvíce
používaný WWW server je Apache. Je ovšem nutno poznamenat, že WWW server
Apache je multiplatformní. Z tohoto důvodu nemůžeme předpokládat, že celých 59%
serverů je provozováno na operačním systému Linux. Přesné procentní zastoupení
serverů Apache běžících na Linuxu (případně Unixu) se autorovi nepodařilo zjistit.
Přesto je to v současnosti jeden z nejrozšířenějších WWW serverů a proto si ho autor
vybral jako jeden z dále popisovaných WWW serverů. [21]
Tabulka 1 - Podíl WWW serverů leden 2011
výrobce
počet serverů
zastoupení
(%)
Apache
161,591,44
59.13%
MS
57,392,351
21.00%
Nginx
20,504,634
7.50%
Google
15,112,532
5.53%
lighttpd
1,866,872
0.68%
Zdroj: zpracováno dle February Web Server Survey; news.netcraft.com
Jako druhý WWW server autor zvolil Nginx, který nemá takové procentuální
zastoupení jako ostatní WWW servery, ale je multiplatformní webový server, jehož
obliba neustále roste. Od roku 2007 dokázal získat 7,5% podíl.
4.6 WWW server Apache
Důvodů pro výběr WWW serveru Apache (dále jen Apache) je několik. Jeho
hlavní výhodou je fakt, že je tento server open-source. V kombinaci s operačním
systémem Linux lze získat řešení WWW serveru za minimální náklady.
33
Další výhodou je nezávislost na platformě operačního systému. Apache je
určen pro více operačních systémů. Vedle binárních instalací lze totiž získat i
zdrojový kód, který je možno přeložit pro daný operační systém na dané hardwarové
platformě. Apache je možné provozovat jak na klasických počítačích s procesory
Intel nebo jejich klony, tak i na procesorech RISC, MIPS atd. [22]
Apache
využívá
modulární
strukturu,
což
nabízí
velkou
možnost
rozšiřitelnosti. Po přidání dalších modulů nabízí Apache velké množství dodatečných
funkcí. Základní moduly jsou součástí instalačního balíčku a další lze získat přímo
od vývojářského týmu Apache Software Foundation, případně dalších výrobců. [23]
Apache se hodí pro tvorbu dynamicky generovaného obsahu, a podporuje jak
rozhraní CGI, tak rozhraní pro skriptovací programovací jazyky (prostřednictvím
přídavných modulů). [22]
4.6.1 Architektura Apache
Z následující obrázek (obrázek č. 4.) znázorňuje základní strukturu Apache.
Obrázek 4 Architektura Apache
Jádro
Základem je jádro (obrázek č. 5.), které se stará o základní funkce serveru, tj.
obsluhu požadavků. Implementuje také několik podpůrných funkcí.
34
Obrázek 5 - Architektura jádra Apache
Jádro se skládá z komponent:
•
http_protocol – tato komponenta se stará o přímou HTTP
komunikaci s klientem. Pomocí této komponenty jsou také odesílána
všechna data klientovi. [24]
•
http_main – komponenta starající se o nastartování serveru a údržbu
smyčky která přijímá spojení. Také se stará o obsluhu timeoutů. [24]
•
http_request – obsluhuje zpracování požadavků, předává ve
správném pořadí kontrolu modulům a obsluhuje chybové hlášky. [24]
•
http_core – hlavní komponenta která se zajišťuje většinu základních
funkcí. [25]
•
alloc – spravuje a alokuje zdroje.
•
utilities
–
ostatní
podpůrné
funkce
jako
například
čtení
konfiguračních souborů a řízení informací v nich obsažených, či
podpora virtuálních serverů. [24]
Moduly
Apache podporuje přidávání modulů, které rozšiřují jeho funkcionalitu. Jsou
dvě možnosti jak přidat moduly. Staticky, moduly jsou přidány přímo do kódu
Apache během linkování, nebo mohou být načítány dynamicky na základě
konfigurace.
35
Jak uvádí ADULSE [20 str. 139] doba spouštění Apache s dynamickými
moduly v průměru o 20% delší, než kdyby byly moduly přidány staticky.
APR
APR (Apache Portable Run-Time) zprostředkovává multiplatformní vrstvu a
doplňkové služby. Tato vrstva umožňuje abstrakci operačního systému na sadu
funkcí příbuzných Apache. Proto je možné používat server Apache na široké škále
operačních systémů. Řeší například problémy s alokací paměti, čtením a zápisem
souborů, konverzí znakových sad, udržování datových struktur atd. [26] [27]
MPM
MPM (Multiple-Processing Module) je systémový modul, který poskytuje
rozhraní mezi běžícím Apache serverem a operačním systémem. Instalace serveru
Apache může mít pouze jeden aktivní MPM. Jeho hlavním úkolem je mapovat
požadavky klientů na vlákno či proces, přijímat a obsluhovat požadavky. Také se
stará o optimalizace Apache v závislosti na použitém operačním systému při
zachování efektivity a bezpečnosti. [20 str. 56] [28]
Každý operační systém má svoje vlastní MPM. Výjimkou jsou operační
systémy UNIX, které mají na výběr z 2 MPM prefork a worker. Existují ještě další
3 MPM, ale ty jsou experimentální). [28]
Při standardní instalaci pomocí balíčku je vždy nainstalováno MPM prefork.
Tento modul implementuje víceprocesový jednovláknový model. Vytváření procesů
se provádí větvením procesů (fork). Řídící proces, hlavní httpd proces běží pod
uživatelem root a vytváří sadu dětských procesů, které však již neběží pod tímto
uživatelem. Každý dětský proces je zodpovědný za obsluhu jednoho požadavku
(obrázek č. 6). Apache si rezervuje určitý počet nečinných dětských procesů, které
jsou připraveny pro příjem požadavků. Při velkém počtu požadavků nemusí Apache
vytvářet nové procesy, čímž se zrychlí čas zpracování. [29]
36
Obrázek 6 - MPM prefork
Dalším MPM je worker. Tento modul implementuje hybridní víceprocesový
vícevláknový server. Řídící proces httpd vytvoří sadu dětských procesů. Každý
dětský proces vytvoří sadu vláken (obrázek č. 7). Samotná vlákna pak obsluhují
jednotlivé požadavky. Stejně jako modul prefork, i tento modul si udržuje určitý
počet nečinných vláken, která jsou připravena okamžitě obsloužit požadavky. [30]
Obrázek 7 - MPM worker
4.6.2 Konfigurace serveru Apache
Chování Apache je definováno pomocí souhrnu příkazů, kterým se říká
direktivy. Direktivy jsou instrukce, které neřídí přímo akce serveru, ale specifikují
chování serveru a určují, kde se mají hledat potřebné prostředky. Tyto direktivy mají
přesně vymezený kontext, tj. rozsah platnosti a místo kde mohou být použity. [20 str.
93]
37
Každá direktiva se vztahuje ke konkrétnímu modulu. Direktivy se dělí do
dvou skupin: základní a dodané volitelnými moduly. Základní direktivy jsou vždy
k dispozici, protože jsou zkompilované přímo do jádra Apache. Další direktivy
můžeme použít pouze v případě, že je daný modul přidán do konfigurace serveru (v
případě, že použijeme direktivu modulu, který není dostupný, bude ignorována). [20
str. 93]
Direktivy mohou fungovat ve čtyřech kontextech. Těmi jsou obecný kontext
serveru, kontext kontejneru, kontext virtuálního serveru a kontext .htaccess. [31]
Direktivy fungující v obecném kontextu serveru se používají pro celý server a
v některých případech mají platnost pouze v tomto kontextu (například direktiva
ServerRoot specifikuje, v jakém adresáři se nachází soubory serveru). [20 str.
95] [32]
Kontext kontejneru obsahuje direktivy platící jedině v případě, že jsou
uzavřené
do
jednoho
ze
tří
kontejnerů
<Directory>,
<Files>
či
<Location>.
Direktivy platné pro kontext virtuálního serveru se mohou objevit pouze
v kontejneru <VirtualHost> a specifikují nastavení virtuálních serverů.
Pokud je direktiva v .htaccess kontextu, znamená to, že se může použít
v souborech .htaccess, které se využívají ke změnám v konfiguraci pro
samostatné adresáře. Dle oficiální dokumentace Apache [33] by však soubory
.htaccess měly být využívány pouze v nezbytných případech (například pokud
správce serveru nemůže často měnit konfiguraci), protože zpomalují běh serveru. [20
str. 96] [33]
Pokud je direktiva použita v kontextu, pro který není definována, znemožní
vyřizování požadavků v daném kontextu nebo neumožní nastartování serveru.
Seznam všech dostupných direktiv ve standardní instalaci Apache, včetně jejich
popisu a možného kontextu, je dostupný online1.
1
Seznam direktiv: on-line verze (http://httpd.apache.org/docs/2.2/mod/directives.html)
38
Základní konfigurace
Základním konfiguračním souborem Apache je soubor httpd.conf
uložený v adresáři /etc/apache2. Konfigurační soubor httpd.conf
specifikuje vlastnosti démona httpd. Tento adresář také obsahuje konfigurační
soubory modulů Apache, webových aplikací, virtuálních serverů a klíče pro
šifrované připojení.
Nastavení jednotlivých částí Apache je realizováno v samostatných
konfiguračních souborech, které jsou připojeny do souboru httpd.conf pomocí
příkazu include. Je doporučeno vyhnout se přímým úpravám v tomto souboru a
upravovat pouze příslušné připojené soubory. [2 str. 731]
Soubor http.conf (příloha č. 2) je rozčleněn do tří částí. První část
obsahuje globální nastavení. Do této části jsou například připojeny soubory, které
udávají na jaké IP adrese a portu bude démon poslouchat, výkonnostní parametry,
jaké moduly se mají načíst či nastavení pro chybová hlášení. [20 str. 95]
Druhá část specifikuje nastavení výchozího serveru serveru. V připojeném
souboru default-server.conf je například specifikován adresář, ve kterém
jsou uloženy webové stránky, přístupová práva k těmto souborům, pod jakým
uživatelem bude démon httpd běžet, aliasy a informace o výchozím serveru. [2 str.
732]
Třetí část se týká nastavení virtuálních serverů. Do této části jsou připojeny
všechny soubory z adresáře /etc/apache2/vhosts.d. Je vhodné mít pro
každý virtuální server vlastní transparentně pojmenovaný konfigurační soubor.
Virtuální server v tomto souboru specifikujeme pomocí kontejnerové
direktivy <VirtualHost>. Každá direktiva <VirtualHost> obsahuje definici
jednoho virtuálního serveru. U konfigurace virtuálního serveru záleží na typu
virtuálního hostingu. [2 str. 735]
4.6.3 Dynamické generování obsahu
Apache umožňuje použití celé škály server-side aplikací, které se starají o
dynamické generování obsahu. Základní instalace umožňuje pomocí modulu
39
mod_include použití technologie pro základní skriptování SSI (Server Side
Includes) a nejstarší metodu pro připojování externích aplikací CGI (modul
mod_cgi). Po nainstalování dodatečných modulů také umožňuje podporu FastCGI
(modul
mod_fcgid),
PHP
(modul
mod_php5),
JSP
(pomocí
modulu
mod_proxy_ajp, který komunikuje se serverem Tomcat) a ASP (modul
mod_perl).
4.6.4 Zabezpečení
Moduly sloužící k řízení přístupu se aplikují ve fázi zpracování požadavku,
který má následujících tři fáze:
•
Řízení přístupu – zamítnutí přístupu k požadovanému prostředku na
základě informací obsažených v požadavku HTTP.
•
Autentizace
(ověření)
–
ověření
identity
žadatele
podle
přihlašovacích údajů poskytnutých uživatelem.
•
Autorizace – zjištění, zda má ověřený uživatel oprávnění k přístupu
k požadovaným prostředkům. [20 str. 396]
Přístup na základě původu klienta
Přístup na základě původu klienta je nejjednodušší způsob řízení přístupu. O
tuto funkci se stará modul mod_authz_host. Tento modul působí v průběhu fáze
řízení přístupu a omezuje uživatele na základě hostname, IP adresy či jiných
charakteristik obsažených v HTTP hlavičkách požadavku klienta (například UserAgent). [34]
Tento modul poskytuje tři direktivy a to Allow, Deny a Order, které
mohou být uvedeny pouze v kontextu kontejneru (v souboru httpd.conf), či
.htaccess. Direktiva Allow udává hostitele, kteří mají přístup k prostředkům
v daném kontejneru. Prvním argumentem je vždy slovo from, po kterém následuje
specifikace hostitele. Direktiva deny má stejné argumenty a udává hostitele, jimž je
zakázán přístup k prostředkům na serveru. Order určuje pořadí, ve kterém se
direktivy allow a deny vyhodnocují. [20 str. 397] [34]
40
Také je možné pomocí modulů třetích stran omezit počet souběžných
připojení z jedné IP adresy.
Přístup na základě autentizace uživatele
Tento přístup kombinuje autentizaci uživatele s jeho autorizací, tj. zda má
uživatel právo přistupovat k požadovaným prostředkům. Apache má ve standardní
instalaci
dva
moduly
pro
autentizaci
uživatelů,
jeden
pro
základní
(mod_auth_basic) a jeden pro digest autentizaci (mod_auth_digest). [35]
Těmto
modulům
poskytují
autentizační
služby
tzv.
autentizační
poskytovatelé. Těch existuje několik a každý z nich je reprezentován samostatným
modulem.
Mezi
nejdůležitější
patří
mod_authn_file,
který
umožňuje
autentizaci uživatele na základě vyhledání ověřovacích údajů v souboru. Údaje jsou
zde uloženy formou čistého textu, proto je nutné tento soubor zabezpečit. Modul
mod_authn_dbm umožňuje identifikaci pomocí DBM souborů. DBM soubory
jsou výstupem databázového systému DBM, jenž je součástí operačního systému
Unix. Modul mod_authn_dbd umožňuje autentizaci pomocí vyhledání údajů
v SQL tabulce. [35]
Po úspěšné autentizaci je nutné ověřit, zda je uživatel autorizovaný pro daný
obsah. Tuto autorizaci poskytují následující moduly: mod_authz_groupfile,
mod_authz_owner, mod_authz_user a mod_authz_dbm. První modul
umožňuje autorizaci pomocí skupin. Skupiny (a jejich členové) musí být uvedeny
v souboru či databázi. Modul owner umožňuje autorizaci založenou na vlastnictví
souborů (zadané autentizované uživatelské jméno musí být shodné s vlastníkem
souboru). Modul user poskytuje autorizaci na základě ověření povolených
uživatelů (ti musí být zapsáni v souboru či databázi). Dbm autorizuje skupiny
uživatelů pomocí DBM souborů. [35]
Je velmi důležité správně zabezpečit jakékoliv soubory, které obsahují údaje
o uživatelích, a uložit je mimo volně dostupné adresáře. [35]
4.6.5 SSL
SSL je v Apache implementováno využitím balíku OpenSSL. Tento balík
implementuje sadu nástrojů pro protokoly SSL (verze 2 a 3) a TSL (verze 1).
41
Zároveň také poskytuje kryptografickou knihovnu, která obsahuje funkce
implementující mnoho kryptografických algoritmů. [20 str. 430]
Apache může být rozšířen o SSL pomocí modulu mod_ssl. Tento modul je
součástí standardní instalace. Modul však musí být načten při startu Apache, což je
provedeno záznamem do souboru httpd.conf, do kterého také musíme připojit
direktivou include globální konfigurační soubor SSL ssl-global.conf. Je
nutné nastavit jeden virtuální server, který bude naslouchat na standardním portu
(443) pro SSL komunikaci. [20 str. 439] [36]
Před spuštěním SSL je nutné vygenerovat privátní klíč serveru pomocí
nástroje openssl. Název klíče může být libovolný, ale je vhodné, aby se vázal
k identitě serveru, pro který je generován. Při vytváření privátního klíče musíme
zadat heslo, které se následně použije pro zašifrování klíče. V případě, že server
poskytuje virtuální servery, je nutné vygenerovat každému serveru vlastní. [2 str.
736] [20 str. 433]
Po vygenerování privátního klíče je třeba vytvořit požadavek na podepsání
digitálního certifikátu X.509. K vytvoření potřebujeme privátní klíč serveru a opět
nástroj openssl. Při vytváření budeme dotázáni na heslo k privátnímu klíči,
informace o umístění, jméno společnosti, jméno serveru, email a challenge password
(v případě že zadáme challenge password, bude každý start či restart Apache toto
heslo vyžadovat). Následně musíme nechat podepsat certifikát certifikační autoritou.
Po podepsání uložíme do adresáře /etc/apache2/ssl.crt. [20 str. 434] [36]
4.7 WWW server Nginx
WWW server Nginx (neboli engine x, dále jen Nginx) je zcela zdarma a
nabízí velmi široké spektrum možností. Ne všechny možnosti jsou spojeny pouze
s vyřizováním HTTP požadavků, Nginx může například fungovat i jako emailový
proxy server.
Stejně jako Apache, také Nginx využívá modulární strukturu, což nabízí
velkou možnost rozšiřitelnosti. Přidáním dalších modulů nabízí Nginx velké
množství dalších funkcí. Základní moduly jsou součástí instalačního balíčku a další
moduly lze získat na stránkách vývojářů nginx.org, případně od dalších výrobců.
42
Nginx je kompatibilní s velkým množstvím operačních systémů. V současné
době podporuje Unix systémy FreeBSD a Solaris, veškeré Linuxové systémy
s jádrem verze 2.6 a vyšší, MacOS X a Windows. [37]
V případě instalace Nginx na Unix-like systém je nutné nejdříve nainstalovat
kompilátor jazyka C, knihovnu PCRE (Perl Compatible Regular Expression), která
umožňuje použití regulárních výrazů (příloha č. 2) a knihovnu zlib pro kompresní
algoritmus.
4.7.1 Architektura Nginx
Nginx se podobně jako Apache skládá z jádra a modulů. Využívá
jednovláknovou event-driven architekturu (v případě vícejádrových systémů může
používat vícevláknovou event-driven architekturu). Podstatou jednovláknové
architektury je přiřazení pouze jednoho vlákna pro každý individuální proces. [38]
Event-driven architektura je založená na tzv. non-blocking I/O (Input
/Output). Současně běžící procesy obsluhují události paralelně, přesto jedno spojení
nemůže ovlivnit jiné. Non-blocking I/O umožňuje asynchronní přístup procesů k I/O.
Proces požádá jádro o přístup k I/O a v případě, že data nejsou k dispozici (čeká se
na načtení dat z I/O zařízení), proces pokračuje ve své činnosti, dokud jádro nenačte
požadovaná data z I/O do bufferu a nepošle procesu zprávu o této události (event).
Způsob obsluhy a tvorby událostí určuje použitý operační systém. [39] [40] [41]
To umožňuje v průběhu načítání souboru vytvořit hlavičku HTTP odpovědi
nebo v případě načítání většího souboru obsluhovat další požadavky (dokud nebude
soubor načten, není možné kompletně vyřídit daný požadavek). [41]
43
Architektura procesů v Nginx je znázorněna na obrázku č. 8.
Obrázek 8 - Nginx a procesy
Nginx po startu vytvoří jeden hlavní proces (master) spuštěný pod uživatelem
root. Tento proces nezpracovává požadavky klientů, ale vytváří další, tzv. worker
procesy, jejichž počet je konfigurovatelný. Master proces po vytvoření worker
procesů sleduje jejich činnost, řídí je a v případě, že zaniknou, je znovu vytvoří.
Komunikace mezi těmito procesy je řešena pomocí signálů. [41]
Worker procesy se starají o vyřizování požadavků klientů a udržují s nimi
spojení. Každý worker proces může zpracovávat více požadavků (a to díky eventdriven architektuře). Worker procesy jsou spuštěny pod jiným uživatelským účtem
s omezenými právy. [42 str. 88]
Jádro
Jádro se skládá ze dvou modulů. Dané moduly umožňují základní konfiguraci
a fungování Nginx. Moduly jádra však neobsahují žádné funkce pro obsluhu HTTP
požadavků, aby Nginx mohl fungovat jako HTTP server, musí být přidán
HttpCoreModule. [42 str. 87]
Jádro obsahuje následující moduly:
•
CoreModule – tento modul obstarává základní funkce serveru,
například spouštění serveru, vytváření worker procesů aj. Také
obsahuje direktivy pro nastavení základních funkcí. [42 str. 88]
44
•
EventsModule – specifikuje způsob, kterým Nginx obstarává
připojení. Direktivy poskytované tímto modulem jsou velmi důležité.
Špatné nastavení proměnných u těchto direktiv může mít velký dopad
na výkon Nginx, případně nemusí být spuštěn vůbec. [42 str. 93]
Moduly
Jádro samo o sobě nedokáže vyřizovat HTTP požadavky. Bez dalších modulů
by byl tedy Nginx nepoužitelný. Na rozdíl od serveru Apache mohou být moduly
přidány pouze při kompilaci. V případě instalace z binárních balíčků Nginx obsahuje
pouze základní moduly. [42 str. 59]
Nginx používá moduly následujících typů:
•
Handlery – zajišťují zpracování požadavku a vytváření výstupu.
Jedná se zejména o čtyři následující úkoly – získání umístění
konfiguračního souboru, generování vhodné odpovědi, poslání
hlavičky a poslání těla. [43]
•
Filtry – manipulují s odpověďmi generovanými handlerem. Například
filtr, který nastaví status code 304 (not modified) v hlavičce
požadavku na základě porovnání časových údajů z HTTP hlavičky.
[43]
•
Load-balancery – tento typ modulů se používá pouze v případě, že se
Nginx používá jako reverzní proxy server. Load-balancer převezme
požadavek od handleru a dle seznamu dostupných serverů rozhodne,
kterému serveru ho pošle. [43]
Nginx nepodporuje konfiguraci s využitím dynamicky natahovaných modulů,
což má jak výhody (dynamicky načítané moduly prodlužují dobu spouštění průměrně
o 20%), tak i nevýhody (v případě, že bude správce serveru chtít přidat nový modul,
musí provést kompilaci a instalaci znovu).
4.7.2 Konfigurace Nginx
Konfigurační soubory Nginx se skládají z direktiv. Každá direktiva má svůj
specifický význam a definuje určitou vlastnost serveru. Sada základních direktiv je
45
dodávána s jádrem Nginx. Ovšem každý modul musí obsahovat direktivy, které
definují jeho vlastnosti. [42 str. 80]
Samotné jádro je řízeno čtyřmi následujícími konfiguračními kontexty –
main, server, location a event. Moduly mohou přidat další konfigurační kontexty,
například modul http přidá kontext http. Důležitá vlastnost kontextů je schopnost
dědit vlastnosti nadřazených kontextů. Kontext location dědí vlastnosti kontextu
server, server vlastnosti kontextu http a http dědí z kontextu main. [43] [44]
Direktivy v main kontextu (nebo také root) se použijí ke globálnímu
nastavení celého serveru. Kontext http (http blok) umožňuje nastavení HTTP.
Kontext server (server blok) se vztahuje na direktivy specifikující konkrétního
hostitele či port. Direktivy v kontextu location (location blok), se použijí k nastavení
části serveru, která odpovídá zadanému umístění (například /jirka). Event kontext
(event blok) je speciální případ, protože se chová stejně jako root, tj. nastavuje
globální prostředí, avšak direktivy v tomto kontextu jsou sdružovány do bloku). [43]
Všechny
direktivy
se
sdružují
do
bloků,
jedinou
výjimku
tvoří
direktivy kontextu main, které se do bloku neuzavírají a píší se přímo do
konfiguračního souboru. Kompletní seznam direktiv a kontextů jednotlivých modulů
je dostupný online2 na stránkách výrobce. Blok umožňuje konfiguraci členit do
logické struktury a vypadá následovně: [42 str. 83]
user www www;
http {
sendfile on;
server {
listen 80;
server_name localhost;}
}
2
Sezam direktiv: online verze (http://wiki.nginx.org/Modules)
46
Základní konfigurace
Hlavní konfigurační soubor serveru Nginx je nginx.conf, který nastavuje
chování master procesu – démona nginx. Soubor je při standardní instalaci
z binárního balíčku umístěn v /etc/nginx. V tomto adresáři jsou také uloženy
konfigurační soubory modulů. [45]
Soubor nginx.conf je hierarchicky rozdělen dle kontextů na 4 části
(obrázek č. 9). První část je kořenem (root), tj. konfigurace se provádí přímo do
kořene adresáře a většinou na začátek souboru. Druhou část tvoří bloky služeb
poskytovaných serverem. Třetí částí jsou bloky udávající jednotlivé servery služeb, a
ty musí vždy být součástí bloků služeb. Poslední část je vnořená do bloků server, a
v rámci jednoho bloku server se může vyskytovat více než jednou. [45]
Obrázek 9 - Hierarchie konfiguračního souboru nginx.conf
První částí je globální nastavení serveru – tj. zde mohou být použity direktivy
v kontextu main či event. V této části je například možné nastavit, kolik worker
procesů bude démon nginx spouštět nebo pod jakým uživatelem worker procesy
poběží. Také se v globální části pomocí bloku event specifikuje obsluha
požadavků, například kolik klientů může zároveň obsluhovat jeden worker proces, či
výběr event, modelu tj. jak budou vytvářeny a obsluhovány eventy (pouze v případě
že byl Nginx zkompilován s více event modely). [45] [46]
47
Druhou částí je nastavení služby (http, mail). V této části je nastavováno
výchozí chování pro danou službu. V případě HTTP serveru je blok uvozen
direktivou http a například zde nastavujeme výchozí typ souborů, zda server může
posílat soubory nebo jak dlouho bude server udržovat spojení s klientem. [44] [46]
Třetí část se zabývá nastavením konkrétních serverů (ať již reálných či
virtuálních). Každý server má svůj vlastní blok uvozen direktivou server a je vnořen
do bloku služby, kterou poskytuje (http, mail). Je vhodné tyto servery definovat ve
vlastních souborech, které připojíme do souboru nginx.conf pomocí direktivy
include. V rámci tohoto bloku například konfigurujeme na jaké IP adrese a portu
daný server naslouchá, jméno serveru, nastavení výchozího souboru, který server
poskytne v případě, že v URL není specifikovaný soubor či adresář ve kterém se
nachází soubory, které server poskytuje. [44] [46]
Poslední v hierarchii je část uvozená direktivou location. Tato direktiva
se může vyskytnout pouze v kontextu server a umožňuje specifikovat přesné
nastavení konkrétní části serveru na základě URI (například location /wiki/
pro server nginx.org umožní upřesnit nastavení pro stránku nginx.org/wiki). [20 str.
133]
Direktiva location umožňuje vyhodnocování pomocí regulárních výrazů
(=,~,~*,^~,@). Pokud je definováno více bloků location v rámci jednoho
serveru, nevyhodnocují se podle pořadí v konfiguračním souboru, nýbrž podle sady
pravidel. [42 str. 133]
4.7.3 Dynamické generování obsahu
Nginx také umožňuje použití řady aplikací pro generování dynamického
obsahu. K tomu používá FastCGI rozhraní, které aplikaci předává požadavky pro
zpracování dynamického obsahu. [42 str. 194]
4.7.4 Zabezpečení
Nginx umožňuje omezení přístupu na základě původu uživatele, přístup na
základě autentizace uživatele a také implementuje SSL.
48
Přístup na základě původu uživatele
Modul http_access umožňuje řídit přístup na základě IP adres klientů.
Přináší pouze dvě direktivy allow a deny, které mohou být použity pouze
v kontextu location. Direktiva allow určuje, které IP adresy mohou přistoupit
k danému obsahu. Direktiva deny udává, kterým IP adresám je přístup odmítnut. Na
rozdíl od Apache jsou direktivy vyhodnocovány podle pořadí v konfiguračním
souboru. [42 str. 168]
Další možností jak omezit přístup je pomocí modulů http_limit_zone
či http_limit_req. Tyto moduly umožňují omezit dané zóně počet souběžných
připojení či počet požadavků za určený čas (sekundu či minutu). Pro oba moduly je
nutné nejdříve definovat zónu v konfiguračním souboru nginx.conf. Zónu
definujeme
v kontextu
http
pomocí
direktivy
limit_zone
případně
limit_req_zone. [42 str. 169]
Přístup na základě autentizace uživatele
Nginx implementuje pouze základní autentizaci uživatelů a to modulem
http_auth_basic. Tento modul umožňuje autentizaci i autorizaci a jeho
direktivy auth_basic a auth_basic_user_file se mohou objevit
v kontextech http, server nebo location. Tj. můžeme vyžadovat autentizaci
pro všechny Nginxem poskytované servery, pro konkrétní server nebo jen pro
určitou jeho část. [42 str. 168]
Autorizace je řešena soubory se seznamem uživatelů (a zašifrovaných hesel),
kteří jsou oprávněni přistoupit k danému obsahu. Tyto soubory musí být správně
zabezpečeny.
SSL
Také Nginx využívá k realizaci SSL balík nástrojů OpenSSL. Samotná
podpora SSL Nginx je dána modulem http_ssl, který není základním modulem a
musí být zvolen při kompilaci. Postup vytváření certifikátu a privátního klíče je
stejný jako v případě Apache (což je dáno využíváním stejného balíku nástrojů
OpenSSL). [42 str. 183] [47]
49
Nastavení serveru pro používání SSL je provedeno v konfiguračním souboru
nginx.conf. Zde je nutné nastavit v rámci server kontextu, aby server poslouchal na
portu 443, zapnout SSL direktivou ssl a určit kde se nachází certifikát a privátní
klíč (umístění může být nadefinováno i v kontextu http). [47]
Secure link
Umožňuje uživatelům přístup k obsahu na základě zkontrolování přítomnosti
určité hash hodnoty v URL. Hash je vypočítán pomocí metody MD5. Jako vstup pro
šifrování se používá slovo, které se skládá ze jména souboru a hesla (například
soubor „tajny.doc“ a heslo „jirka“ tvoří pro vytvoření hashe slovo „tajny.docjirka“).
V případě, že URL nebude obsahovat tento řetězec, nezašle server požadovaný
obsah. [42 str. 186]
Secure link je v Nginx implementován modulem http_secure_link a
direktivy mohou být použity jen v kontextu location. Pro určení tajného hesla se
využívá direktiva secure_link_secret.
50
5 Praktické nastavení serveru
Dále popisované nastavení serveru pro malou firmu předpokládá využití
serveru pouze zhruba 50 uživateli. Toto číslo vyplývá z evropské definice malého
podniku (příloha č. 4).
Server bude zajišťovat pouze intranetové služby. Jedinou výjimkou bude
webová aplikace pro přístup k poštovním schránkám. Předpokládá se externí
internetové připojení s externím firewallem a routrem. Z tohoto důvodu autor nebude
řešit zabezpečení. Server bude poskytovat následující služby:
•
DHCP
•
DNS
•
souborový server
•
řadič domény
•
poštovní server
•
webový server
Pro ověření konfigurací bude použit autorův domácí server s následující
hardwarovou konfigurací:
•
Procesor: Intel Core 2 Duo E6750 – 2,67GHz
•
Základní deska: GA-P35-DS4
•
Paměť: 4GB RAM 800MHz DDR3
•
Pevný disk: 100 GB SATA II
5.1 Bezpečnostní model
Model vychází z toho, že uživatelé nebudou přímo pracovat na serveru,
budou pouze využívat služeb poskytovaných tímto serverem. Předpokládá se, že
pracovní stanice budou používat operační systém Windows, a proto server bude
sloužit i jako řadič domény.
Každý uživatel bude mít vlastní účet. Přihlašovací údaje budou využívány
všemi službami, které vyžadují autentizaci. Souborový server vyžaduje nastavení
přístupových práv k souborům a adresářům. Proto je nezbytné, aby každý uživatel
měl založen systémový účet. Tento účet bude využíván i řadičem domény. Heslo
51
uživatele bude udržováno řadičem domény. Uživatelské účty nebudou umožňovat
přihlášení k operačnímu systému Linux (budou zablokovány).
Elektronická pošta bude používat k autorizaci uživatelů uživatelské účty a
hesla poskytované řadičem domény.
5.2 Instalace
Nejprve nainstalujeme zvolenou distribuci operačního systému Linux. Z
důvodů předchozích zkušeností s distribucí OpenSUSE autor zvolil pro tuto práci
právě distribuci OpenSUSE verze 11.3.
Při instalaci je nutné zvolit typ grafického prostředí, souborový systém,
vytvořit heslo k uživatelskému účtu root. Jako grafické rozhraní zvolíme KDE4. Jako
souborový systém zvolíme ext4 a velikosti vytvoříme následovně (takto bude
rozdělen autorův 100GB disk v případě firemního serveru by tyto hodnoty byly
větší).
•
/ (root) - 30GB
•
/home – 65GB
•
/swap – 5GB
Po nainstalování operačního systému provedeme jeho aktualizaci, instalaci
dodatečných aplikací a jejich aktualizaci. Všechny tyto kroky provedeme pomocí
systémového programu zypper, konkrétně příkazy:
zypper update
zypper install název_aplikace
Po instalaci a aktualizaci vytvoříme potřebné uživatelské účty a skupiny.
5.3 Nastavení TCP/IP
Nejdříve nastavíme parametry síťového rozhraní. V našem případě má
nastavovaný server pouze jedno síťové rozhraní. Nastavení IP adresy a masky
provedeme úpravou souboru /etc/sysconfig/network/ifcfg-eth0,
kde změníme následující řádky.
BOOTPROTO='static'
#IP adresa je statická
52
STARTMODE='auto'
#automatický start adapteru
BROADCAST=''
#broadcast adresa je daná maskou
IPADDR='192.168.233.2/24' #nastaveni IP adresy a masky
Jméno
serveru
a
interní
doménu
nastavíme
úpravou
souboru
/etc/HOSTNAME, kam přidáme následující řádek (kde asterix je název serveru
a firma je interní doména).
asterix.firma
Dále pro případ nefunkčního DNS serveru přidáme dva statické záznamy do
souboru /etc/hosts:
127.0.0.1
localhost
192.168.233.2 asterix.firma asterix
Také nastavíme klienta DNS systému (neboli resolver) tím, že přidáme
záznamy dostupných DNS serverech do souboru /etc/resolv.conf.
#výchozí prohledávaná doména
search firma
nameserver 192.168.233.2
#IP adresa DNS serveru
A určíme v souboru /etc/nsswitch.conf jakou službou a v jakém
pořadí bude resolver překládat adresy. Přidáme následující řádek:
hosts: dns files
#nejprve se použije dns systém a pak soubor /etc/hosts
Posledním krokem v nastavení TCP/IP je nastavení výchozí brány. To
provedeme pomocí programu ip:
ip route add default via 192.168.233.1
Funkčnost nastavení ověříme příkazem ping:
ping 192.168.233.1
V případě, že dostaneme následující odpověď je síťové rozhraní nastaveno
správně.
PING 192.168.233.1 (192.168.233.1) 56(84) bytes of data.
64 bytes from 192.168.233.1: icmp_seq=1 ttl=128 time=0.326 ms
53
64 bytes from 192.168.233.1: icmp_seq=2 ttl=128 time=0.144 ms
64 bytes from 192.168.233.1: icmp_seq=3 ttl=128 time=0.136 ms
5.4 Nastavení DHCP serveru ISC (4.1.2)
Konfiguraci démona dhcpd provedeme v souboru /etc/dhcpd.conf.
Zde určíme síť, pro kterou má server přidělovat síťové parametry, a nastavíme síťové
parametry, které bude DHCP server přidělovat. To provedeme následujícím zápisem:
authoritative;
#DHCP je autoritativní
include "/etc/named.d/named.keys";
#klíč pro autentizaci
option netbios-node-type 8;
#nastavení hybridní node tj. nejdříve se
použije k vyhodnocení netbiosových jmen WINS server a v případě nefunkčního serveru
broadcast)
option netbios-name-servers 192.168.233.2;
#adresa WINS serveru
ddns-update-style interim;
#používaná metoda DDNS
ddns-updates on;
#zapnutí DDNS
default-lease-time 86400;
#výchozí doba přidělení adresy
max-lease-time 86400;
# maximální doba přidělení adresy
Subnet 192.168.233.0 netmask 255.255.255.0
{
option domain-name "firma";
#nastavení domény
option domain-name-servers 192.168.233.2;# nastavení DNS serveru
option routers 192.168.233.1;
#IP adresa výchozí brány
range 192.168.233.20 192.168.233.254;
#rozsah přidělovaných IP adres prvních 20 je rezervováno pro případné statické přidělení
zone firma. { primary 192.168.233.2; key dhcpupdater; }
zone 233.168.192.in-addr.arpa. { primary 192.168.233.2; key
dhcpupdater; }
}
#předchozí 2 řádky zajišťují update zónových souborů domény firma
Nyní musíme vygenerovat klíč pro autentizaci změn prováděných DHCP
serverem v DNS záznamech a nastavit mu příslušná přístupová práva.
54
genDDNSkey -f /etc/named.d/named.keys -n dhcpupdater
Spuštění DHCP serveru a automatické spuštění po startu systému zajistíme
příkazy:
service dhcpd start
chkconfig --set dhcpd on
Všechny
serverem
přiřazené
IP
adresy
nalezneme
v souboru
/var/lib/dhcp/db/dhcpd.leases. Obsah souboru po připojení jedné
pracovní stanice do sítě je následující:
lease 192.168.233.254 {
starts 5 2011/03/15 13:08:35;
ends 5 2011/03/16 13:08:35;
cltt 5 2011/04/01 13:08:35;
#poslední transakce klienta
binding state active;
#adresa je aktivní
next binding state free;
#po vypršení bude označena jako volná
hardware ethernet 00:24:e8:a8:09:5f;
uid "\001\000$\350\250\011_";
#identifikátor zaslaný klientem
set ddns-rev-name = "130.233.168.192.in-addr.arpa.";
set ddns-txt = "316aedbd1c7098d96a80f5d62a7820706c";
set ddns-fwd-name = "DellE6400.firma";
#záznamy, které byly předány DNS serveru prostřednictvím DDNS
client-hostname "DellE6400";
5.5 Nastavení DNS serveru BIND (9.7.3)
Nastavení DNS serveru je rozděleno do dvou částí. První částí je konfigurace
démona named a druhou částí je vytvoření souborů s informacemi o doméně.
Nejprve
provedeme
konfiguraci
démona
a
to
úpravou
souboru
/etc/named.conf. Nastavíme předávače v bloku options a zóny (zónu pro
interní a reverzní doménu) kdekoliv mimo tento blok.
forwarders {212.158.128.2;212.158.128.3;};
55
#DNS servery našeho ISP
include "/etc/named.d/named.keys";
#klíče pro autentizaci
zone "firma" IN {
type master;
#server je autoritativní pro tuto doménu
file "zony/firma";
#název souboru pro danou zónu
allow-update { key dhcpupdater; };
#umožnění dynamického update pro tuto zónu klíčem dhcpupdater
};
zone "233.168.192.in-addr.arpa" IN {
type master;
file "zony/233.168.192.in-addr.arpa";
allow-update { key dhcpupdate; };
};
Dalším
krokem
je
vytvoření
233.168.192.in-addr.arpa.
zónových
Soubor
souborů
firma
vytvoříme
a
v adresáři
/var/lib/named/zony/ a je nutno provést změnu vlastníka a skupiny na
uživatele a skupinu named. Obsah souboru /var/lib/named/zony/firma
bude následující:
$TTL 86400
#doba platnosti záznamu 1 den
$ORIGIN .
firma IN SOA
asterix.firma.
root.asterix.firma.(
2011031200 ; seriové číslo záznamu
firma.
10800
; obnova sekundárními servery
3600
; opakování obnovy v případě neúspěchu
604800
; vypršení záznamu na sekundárních serverech
86400 )
; jak dlouho uchovávat negativní odpovědi
IN NS
asterix.firma.
; nastavení DNS serverů pro danou doménu
$ORIGIN firma.
asterix
IN A
192.168.233.2
56
; ostatní hostitelská jména budou dodávána DDNS
Pro reverzní doménu by soubor vypadal podobně. Záznam SOA bude stejný
(název domény bude odpovídat názvu reverzní domény), záznam NS se změní a
A záznamy se změní na PTR záznamy:
NS asterix.firma.
2
PTR asterix.firma.
Nyní zajistíme spuštění a automatické spuštění démona named po startu
systému příkazy:
service dhcpd start
chkconfig --set named on
5.6 Nastavení Samba serveru (3.5.3)
Samba je konfigurována pomocí souboru /etc/samba/smb.conf.
Tento soubor má dvě sekce a to sekci global (uvozenou [global]) a sekci pro
definování sdílených zdrojů (tzv. shares). V sekci pro definování zdrojů může být
libovolný počet shares a jsou uvozeny direktivou [název share]. Obsah
konfiguračního souboru Samba serveru bude následující:
[global]
dos charset = CP852
#nastavení znakové sady
workgroup = FIRMA
#nastavení domény
netbios name = BROUCEK
#NetBIOSové jméno serveru
domain master = Yes
#server bude domain master browser
wins support = Yes
#zapíná WINS server
name resolve order = wins lmhosts hosts bcast
#v jakém pořadí se budou vyhodnocovat NetBIOSová jména
preferred master = Yes
#určení preferovaného serveru
domain logon = Yes
#umožňuje přihlášení do Windows domény
local master = Yes
#umožnění démonu nmbd účastnit se ve volbách local master browser
security = user
57
#ověřování proběhne na základě Linuxových uživatelských účtů
passdb backend = smbpasswd
#k autentizaci uživatelů bude použit soubor smbpasswd
unix password sync = No
#hesla nebudou synchronizována
add machine script = /usr/sbin/useradd
-c 'Samba PC
%m' -g users -d /var/lib/nobody -M -s /bin/false
%m$
add group script = /usr/sbin/groupadd %g
add
user script = /usr/sbin/useradd -c "Uzivatel
Samba" -g users -d /home/%u -s /bin/false %u
add user to group script = /usr/sbin/usermod -A %g
%u
#skripty, které provedou přidání a aktualizaci uživatelů v /etc/passwd
server string = Samba
#název, který se objeví ve jméně sharu
logon path =
#zakázání cestovních profilů
logon home =
#zakázání cestovních profilů pro Win 9x/Me
logon script = scripts\logon.bat %u
#skript který bude vykonán při přihlášení uživatele %u je parametr který bude skriptu předán
[homes]
#nastavení namapování domácího adresáře uživatele
comment = Home Directories
inherit acls = Yes
#zapnutí dědění ACL
path = /home/Samba/%S
#cesta k shares
read only = No
browseable = No
#shares budou viditelné pouze pro daného uživatele
[netlogon]
#definování přihlášení do domény
comment = Network Logon Service
path = /var/lib/samba/netlogon
write list = root
browseable = No
read only = Yes
58
Skript, který se spustí po přihlášení uživatele do systému, zajistí namapování
domácího adresáře z /home/samba/username vypadá následovně:
net use p: \\broucek\%1 /PERSISTENT:no
Přidání uživatelských účtů pro přihlášení na Windows stanice provedeme
programem smbpasswd:
smbpasswd -a jiri_malak
New SMB password:
Retype new SMB password:
Added user jiri_malak.
Nyní
musíme
vytvořit
home
adresář
jiri_malak
v
adresáři
/home/samba/ a nastavit příslušná přístupová práva (700). Automatický start
Samba serveru po spuštění systému zajistíme následujícími příkazy:
chkconfig --set smb on
chkconfig --set nmb on
5.7 Nastavení poštovního serveru
Nastavení poštovního serveru se skládá ze tří částí. Nejdříve nastavíme MTA
Postfix, následně IMAP server Dovecot a nakonec provedeme nastavení webmail
aplikace RoudCube.
5.7.1 Nastavení Postfix (2.7.1)
Nastavení poštovního serveru Postfix se provádí ve dvou konfiguračních
souborech /etc/postfix/main.cf a /etc/postfix/master.cf. Jako
výchozí stav byly vzaty konfigurační soubory vytvořené při instalaci a byly v nich
provedeny následující změny:
Soubor main.cf
myhostname = asterix.firma.cz
append_dot_mydomain = no
#nebude se přidávat .firma k odesílané poště
inet_interfaces = all
59
#Postfix bude přijímat poštu na všech síťových rozhraních
mydomain = firma.cz
myorigin = $mydomain
mydestination = $myhostname, $mydomain
mailbox_transport = dovecot
#program pro doručení lokální pošty
dovecot_destination_recepient_limit = 1
#vyžadováno aplikací dovecot
smtpd_sasl_auth_enable = yes
#zapnutí SASL autentizace na SMTP
smtpd_sasl_type = dovecot
#Postfix SMTP server bude využívat autentizaci pomocí dovecot
smtpd_sasl_path = private/auth #cesta k dovecot auth mechanismu
smtpd_sasl_security_options = noanonymous
#zakáže anonymní přístup
smtpd_recipient_restrictions= reject_unauth_destination
#pokud není pošta pro doménu firma.cz nebude přijmuta
Soubor master.cf
submission
inet
n
-
n
-
-
smtpd
-o smtpd_etrn_restrictions=reject
-o
smtpd_client_restrictions=permit_sasl_authenticated,
reject
-o smtpd_recipient_restriction=permit_mynetworks,reject
#nastavení služby pro odesílání SMTP pošty klienty na portu 587 – klienti musí být
autentizováni přes SASL
5.7.2 Nastavení Dovecot (1.2.11)
Konfigurační soubor IMAP serveru Dovecot dovecot.conf se nachází
v adresáři /etc/dovecot.
protocols = imap
#je použit pouze IMAP
disable_plaintext_auth = no
#umožňění plaintext autentizace
log_path = /var/log/dovecot.log
60
info_log_path = /var/log/dovecot.log
log_timestamp = "%b %d %H:%M:%S "
ssl = no
#pouze lokální přístup – není nutné používat SSL
mail_location = maildir:/home/posta/%u
#umístění poštovních schránek klientů
mail_uid = posta
mail_gid = posta
dotlock_use_excl = yes
#doporučená hodnota
maildir_copy_with_hardlinks = yes
protocol lda {
#doporučená hodnota
#nastavení LDA
postmaster_address = [email protected]
mail_plugin_dir = /usr/lib/dovecot/modules/lda
}
auth default {
#nastavení autentizačního mechanismu
mechanisms = plain
#heslo se předává autentizačnímu mechanismu nekryptované (textová podoba)
passdb pam {
#ověření hesla je realizováno přes PAM
args = dovecot
}
userdb static {
#ověření uživatelů
args
=
uid=posta
allow_all_users=yes }
gid=posta
home=/home/posta/%n
#allow_all_users potlačuje vyhledávání uživatelů pomocí passdb lookupů – není zde seznam
uživatelů
user = root
socket listen {
#uživatel, který se používá během autentizace uživatele
#vytvoření socketu pro autorizaci, který mohou využít i ostatní
aplikace (postfix, LDA)
master {
#ověřování uživatele v userdb
path = /var/run/dovecot/auth-master
mode = 0600
user = posta
61
group = posta
}
client {
#ověření hesla
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}
}
Nyní musíme vytvořit adresáře, ve kterých bude ukládána pošta uživatelů.
Jedná se o adresáře /home/posta/jmeno_prijmeni a těmto adresářům
nastavíme příslušná přístupová práva (700) a změníme vlastníka a skupinu na
uživatele a skupinu posta. Zapnutí Dovecot a automatický start IMAP serveru při
spouštění systému zajistíme příkazy:
service dovecot start
chkconfig --set dovecot on
5.7.3 Nastavení webové aplikace pro přístup k poště
Nastavení webové aplikace Roundcube (0.5.1) vyžaduje funkční HTTP server
s podporou PHP5 a databázi. Veškeré nastavení se provede přes webové rozhraní.
Pro přihlášení uživatele k webové aplikaci je použit IMAP účet. Webová aplikace po
přihlášení vypadá následovně (Obrázek č. 10):
Obrázek 10 - Vzhled webové aplikace Roundcube
62
5.8 Nastavení webového serveru Apache (2.2.15)
Globální
konfiguraci
výchozího
serveru
provedeme
v souboru
/etc/apache2/default-server.conf. Dále je nutné vytvořit jeden
konfigurační soubor pro každý virtuální server. V našem případě budeme mít dva
virtuální servery – jeden s podporou a druhý bez podpory SSL. Tyto soubory jsou
pojmenovány asterix.firma.conf a asterix.firma.ssl.conf a
musí být umístěny v adresáři /etc/apache2/vhost.d.
Do souboru default-server.conf přidáme následující parametry:
NameVirtualHost *:443
#definice virtuálního serveru se SSL
NameVirtualHost *:80
ServerTokens Prod
#odstraní informace o verzi Apache a OS
Obsah souboru asterix.firma je následující:
<VirtualHost *:80>
DocumentRoot /srv/www/htdocs_nossl
#definice kořenu serveru
ServerName asterix.firma
ServerAdmin [email protected]
<Directory "/srv/www/htdocs_nossl">
Options none
#nejsou povoleny žádní dodatečné volby
AllowOverride None
#zakázáno použití souboru .htaccess
Order allow,deny
#nastavení přístupu do adresáře
Allow from all
</Directory>
</VirtualHost>
Soubor asterix.firma.ssl.conf je nastaven takto:
<VirtualHost *:443>
ServerName asterix.firma.ssl
ServerAdmin [email protected]
63
DocumentRoot /srv/www/htdocs_ssl
#v případě že je server spuštěn s podporou SSL uplatní se následují blok
<IfDefine SSL>
SSLCipherSuite
#specifikování šifrovací metody
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+
eNULL
SSLEngine on
#zapnutí SSL
#umístění certifikátů a klíčů
SSLCertificateFile /etc/apache2/ssl.crt/firma.crt
SSLCertificateKeyFile /etc/apache2/ssl.key/firma.key
SSLCACertificatePath /etc/apache2/ssl.crt
SSLCACertificateFile /etc/apache2/ssl.crt/ca.crt
</IfDefine>
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-uncleanshutdown downgrade-1.0 force-response-1.0
#specifické nastavení pro Microsoft Internet Explorer
<Directory "/srv/www/htdocs_ssl">
Options none
AllowOverride None
Order allow,deny
Allow from all
SSLRequireSSL
#vynucuje použití SSL
</Directory>
<Directory "/srv/www/cgi-bin">
SSLOptions +StdEnvVars
SSLRequireSSL
</Directory>
</VirtualHost>
64
Pro použití SSL je nezbytné vygenerovat certifikáty pro server. V našem
případě jsme si vytvořili vlastní certifikační autoritu. Postup vytváření podepsaného
certifikátu serveru je následující:
CA.pl –newca
#vytvoření CA
CA.pl –newreq-nodes
#vytvoření certifikátu a požadavku na podepsání
CA.pl –signreq
#podepsání certifikátu CA
Vygenerované certifikáty a klíče se nakopírujeme do příslušných adresářů v
/etc/apache2.
5.8.1 Nastavení podpory PHP
Apache umožňuje realizovat podporu PHP pomocí dodatečného modulu
(mod_php5) nebo rozhraní CGI (případně FastCGI).
Mod_php5
Modul mod_php5 je vytvářen PHP Group a není součástí standardní
instalace. Po instalaci modulu zajistíme jeho načtení serverem Apache použitím
programu a2enmod:
a2enmod php5
Nastavení modulu je umístěno v konfiguračním souboru php5.conf, který
je umístěn v /etc/apache2/conf.d. Výchozí nastavení tohoto souboru je
zcela postačující pro naše potřeby.
Nastavení samotného PHP provedeme v souboru php.ini který je umístěn
v adresáři /etc/php5/apache2.
FastCGI
V případě že chceme PHP skripty spouštět pomocí FastCGI interface musíme
nainstalovat mod_fcgid který je vyvíjen Apache Software Foundation. Jeho
načtení serverem Apache zajistíme stejným programem jako v případě mod_php5.
Konfiguraci
tohoto
modulu
provedeme
v konfiguračním
souboru
/etc/apache2/conf.d/mod_fcgid:
IdleTimeout 300
#ukončení fcgi aplikace po 300sekundách nečinosti
65
IdleScanInterval 120
#nastavení intervalu pro hledání nečiných aplikací
ErrorScanInterval 3
#nastavení intervalu ukončování aplikací
IPCConnectTimeout 10
#vypršení připojení k fastcgi aplikaci v sekundách
IPCCommTimeout 30
#vypršení komunikace mezi fcgid a aplikací v sekundách
<FilesMatch "\.php$">
#všechny sooubory .php budou spouštěny fastcgi
AddHandler fcgid-script .php
FCGIWrapper /srv/www/cgi-bin/php5 .php
</FilesMatch>
PassHeader Authorization
#umožňuje předání autorizačních údajů pomocí fastcgi
DirectoryIndex index.php4
DirectoryIndex index.php5
DirectoryIndex index.php
Pokud chceme spouštět PHP skripty, musíme povolit spouštění skriptů
v rámci adresáře, kde se nachází. To provedeme direktivou Options a parametrem
ExecCGI. Soubor php.ini je uložen v /etc/php5/fastcgi.
Spuštění serveru Apache a jeho automatické spuštění po startu serveru
zajistíme příkazy:
service apache2 start
chkconfig --set apache2 on
5.9 Nastavení webového serveru Nginx (0.8.54)
Globální
nastavení
serveru
provedeme
v souboru
/etc/nginx/nginx.conf. Pro každý virtuální server rovněž použijeme
samostatný konfigurační soubor v adresáři /etc/nginx/sites.
Soubor nginx.conf
user
nginx;
worker_processes
#uživatel a skupina kterou bude nginx využívat
2;
#nastaveno dle počtu jader
events {
worker_connections
1024; #defaultní hodnota stačí pro většinu případů
66
}
http {
include
mime.types;
default_type
application/octet-stream;
include
fastcgi.conf;
index
index.html index.htm index.php;
#připojení konfigurace fastCGI
fastcgi_index index.php;
sendfile
on;
keepalive_timeout
include
#server bude podporovat odesílání souborů
65;
#doba po kterou bude server udržovat spojení
sites/*.conf;
#připojení konfigurace jednotlivých serverů
}
Soubor asterix.firma.conf
server {
listen
80;
server_name
asterix.firma;
root
/srv/www/htdocs_nossl/;
location ~ \.php$ {
fastcgi_pass
#nastavení zpracování PHP skriptů
127.0.0.1:9000; #adresa a port fcgi rozhraní
}
}
Soubor asterix.firma.ssl.conf
server {
listen
443;
server_name
asterix.firma;
root
/srv/www/htdocs_ssl/;
ssl
on;
#zapnutí ssl
ssl_certificate
/etc/apache2/ssl.crt/firma.crt;
ssl_certificate_key
/etc/apache2/ssl.key/firma.key;
67
ssl_client_certificate /etc/apache2/ssl.crt/firma.crt;
ssl_session_timeout
ssl_protocols
5m;
SSLv2 SSLv3 TLSv1;
ssl_ciphers
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:
+EXP;
ssl_prefer_server_ciphers
on;
#předchozí řádky nastavují SSL
include sites/applications/phpMyAdmin.conf;
include sites/applications/roundcubemail.conf;
#nastavení webových aplikací
location ~ \.php$ {
fastcgi_pass
127.0.0.1:9000;
}
}
5.9.1 Nastavení podpory PHP
Nginx nemá vlastní modul pro podporu PHP. Podpora PHP je řešena pomocí
modulu pro FastCGI rozhraní, který je obsažen ve standardní instalaci. Pro větší
výkonnost a širší možnosti nastavení použijeme PHP-FPM (FastCGI Process
Manager), který zajišťuje správu FastCGI procesů. FastCGI modul implementovaný
v Nginx nastavíme, aby předával parametry PHP-FPM na portu 9000. PHP-FPM
nastavíme v souboru /etc/php5/fpm/php-fpm.conf. Změníme následující
položky:
user = wwwrun
#určení vlastníkaprocesů
group = www
pm.max_children = 40
# maximální počet procesů php-fpm
pm.max_requests = 2000
# maximální počet obsloužených požadavků per proces
Změny
v nastavení
PHP
můžeme
provádět
v souboru
/etc/php5/fpm/php.ini. Spuštění nginx a php-fpm zajistíme následujícími
příkazy:
68
service nginx start
service php-fpm start
chkconfig --set nginx on
chkconfig --set php-fpm on
69
6 Hodnocení alternativních konfigurací
6.1 Testovací sestavy
Pro testování použijeme server následující konfigurace:
•
procesor: Intel Core 2 Duo E6750 2,66GHz
•
operační paměť: 4GB RAM DDR3 800MHz
•
pevný disk: 100GB SATA II
•
operační systém: Linux – OpenSUSE 11.3 (verze jádra: 2.6.34.7)
Klientská stanice využita pro běh testovacího SW má následující konfiguraci:
•
procesor: Intel Core 2 Duo E6750 2,66GHz
•
paměť: 3GB RAM DDR3 800MHz
•
operační systém: Linux – LiveCD – OpenSUSE 11.4 (verze jádra: 2.6.37.1)
Jako testovací software zvolíme programy autobench 2.1.2 a httperf 0.9.0.
K zachycení využívaných systémových zdrojů na serveru použijeme systémový
program sar.
Pro propojení počítačů použijeme 1Gb/s LAN síť s přímým propojením
počítačů.
Na serveru v době testování poběží veškeré výše nakonfigurované služby,
avšak uživatelé je nebudou v průběhu testu využívat.
6.2 Testovací konfigurace
Nastavení testovacích konfigurací bylo popsáno v předchozí kapitole. Účelem
tohoto testu je provést co nejreálnější simulaci. Z tohoto důvodu jsou do všech
konfigurací zahrnuty všechny standardní moduly.
70
K1 - Apache2 verze 2.2.15
•
MPM modul – prefork
•
Standardně zkompilovaný Apache2 s následujícími moduly
o actions, alias, auth_basic, authn_file, authz_default, authz_host,
authz_group, authz_user, autoindex, cgi, dir, env, expires, file,
include, log_config, mime, negotiation, setenvif, ssl, userdir
•
Ostatní moduly – mod_php5
K2 - Apache2 verze 2.2.15
•
MPM modul – worker
•
Standardně zkompilovaný Apache2 s následujícími moduly
o actions, alias, auth_basic, authn_file, authz_default, authz_host,
authz_group, authz_user, autoindex, cgi, dir, env, expires, file,
include, log_config, mime, negotiation, setenvif, ssl, userdir
•
Ostatní moduly – mod_fcgid
K3 Nginx 0.8.54
•
Standardně zkompilovaný Nginx se všemi moduly
o Access, Addition, Auth Basic, Auto Index, Browser, Charset, Dav,
Empty GIF, FastCGI, File-aio, Flv, Geo, Gzip, Gzip_static, Headers,
Image_filter, Index, Ipv6, Limit Requests, Limit Zone, Log, Map,
Memcached, Perl, Pool, Proxy, Random_index, Realip, Referer,
Rewrite, Rtsig, scgi, Secure_link, Select, Split Clients SSI, Ssl, Sub,
Sub_status, Upstream, User ID, uwsgi, X-Accel, Xslt
•
Podpora PHP – php-fpm
71
6.3 Nastavení parametrů
Nejdříve se zaměříme na určení výkonnostních parametrů výše uvedených
konfigurací. V případě webového serveru Apache se jedná o parametry v souboru
server-tuning.conf případně souboru mod_fcgid.conf. Výkonnostní
parametry Nginx jsou umístěny v hlavním konfiguračním souboru nginx.conf.
Nejprve provedeme zátěžový test ve výchozím nastavení. Tento test otestuje,
zda výchozí nastavení vyhovuje pro výkonnostní testy, aby nebyly výsledky
zkresleny nevhodným nastavením. V případě, že se výchozí konfigurace ukáže jako
nevhodná, provedeme modifikaci parametrů a provedeme test znovu.
Na základě sady zátěžových testů upravíme parametry jednotlivých
konfigurací. Touto změnou nastavení odstraníme různé nedostatky výchozího
nastavení. Po úpravách nastavení nesmí docházet k hlášení o nedostatku zdrojů.
Změněné parametry:
Apache2 – prefork
•
MaxClients – maximální počet spuštěných procesů – 250
Apache 2 – worker
•
MaxClients – maximální počet spuštěných vláken worker procesy – 800
•
ThreadsPerChild – maximální počet vláken na jeden worker proces –
200
•
PHP_FCGI_MAX_REQUESTS – udává hodnotu požadavků po kterých se
PHP FastCGI interface ukončí – 0
•
mod_fcgid
o MaxProcessCount – maximální počet fastcgi procesů – 3000
Nginx
72
•
worker_process – počet spuštěných worker procesů (dle počtu
procesorů) – 2
php-fpm
o pm.max_children – maximální počet vytvořených procesů
obsluhujících PHP požadavek – 200
Tyto zjištěné parametry pak použijeme jako výchozí nastavení pro další testy.
6.4 Metodika testování
Testování proběhne v následujících krocích:
1. Inicializace serveru a klienta po restartu
• Server – zjištění aktuální hodnoty systémových zdrojů serveru po restartu,
kontrola zda jsou spuštěny všechny síťové služby, změření využívané
paměti.
• Klient – nastavení testovacích parametrů v programech autobench a
httperf.
2. Nastavení testovací konfigurace (1,2 nebo 3).
• Server – nastavení požadované konfigurace (pro zjednodušení bude použit
skript, viz příloha č. 5), spuštění skriptu pro zaznamenání využití
systémových zdrojů.
3. Spuštění testovacího skriptu s aktuálními testovanými parametry na klientské
stanici.
4. Uložení výsledků testu po jeho dokončení.
• Uložení výsledků na klientovi i serveru
5. Po dokončení testu pokračujeme bodem 1 (sekvence se opakuje pro všechny
testy a konfigurace).
73
6.5 Typy testů
6.5.1 Výkonnostní testy
Při výkonnostních testech budeme simulovat 5000 spojení. V rámci každého
spojení bude zasláno 10 požadavků, tj. 50000 požadavků, měnit se bude pouze počet
požadavků za vteřinu. Klient vždy ponechá serveru 10 sekund na odpověď v případě,
že v tomto čase neobdrží odpověď, bude požadavek prohlášený za nesplněný
(timeout).
Sledované hodnoty pro všechny výkonnostní testy jsou následující:
o Naměřená maximální hodnota počtu vyřízených požadavků za
sekundu
o Průměrná doba odpovědi
o Chybovost
o Využívání zdrojů (CPU a paměť)
HTTP server (test H1)
Pro testování HTTP serveru použijeme testovací HTML stránku o celkové
velikosti 1kB. Tato velikost je kompromisem mezi maximální hodnotou požadavků
za vteřinu a zatížením testovacího klienta. Z průběhu zátěžových testů jsme zjistili,
že výkonnost testovacího systému není dostatečná pro zjištění maximálního možného
počtu obsloužených požadavků za vteřinu. Tento limit je dán zejména rychlostí sítě a
výkonností klienta.
HTTP server s podporou PHP (test P1 a P2)
Testování HTTP serveru s podporou PHP proběhne podobným způsobem
jako testování HTTP serveru. Nejdříve otestujeme 1kB a následně 10kB PHP
stránku. Účelem tohoto testu není testování výkonnosti PHP aplikací ale maximálně
možný počet PHP požadavků za vteřinu obsloužených HTTP serverem s PHP
procesorem. Z tohoto důvodu stránka neobsahuje žádný PHP skript. HTTP
server předá požadavek PHP procesoru a ten ho ihned vrátí zpět (PHP procesor
vytvoří pouze hlavičku a zkopíruje dodaná data).
74
6.5.2 Statický test (test S1)
Tímto testem se pokusíme simulovat běžný provoz na síti v menší firmě.
V tomto testu nejde ani tak o výkon serveru, ale o spotřebu systémových zdrojů
v relativně klidném prostředí. Cílem tohoto testu je zjistit potřebnou paměť při 100
připojených uživatelích (session). Při testování vyjdeme z konstantního počtu session
které budeme udržovat po dobu 5 minut. V rámci session budeme každých 5 sekund
zasílat požadavek na 1kB velkou PHP stránku, abychom udrželi spojení a mohli
změřit celkové nároky na systémové zdroje jednotlivých konfigurací.
Pro tento test upravíme testovací konfigurace. Konkrétně se jedná o parametr
keepalive_timeout. Hodnotu tohoto parametru nastavíme na 15 sekund,
abychom zajistili, že server bude session udržovat po celou dobu testu i v případě
výpadku paketu.
6.6 Výsledky testů
Provedené testy poskytly požadované informace. Nejprve provedeme
vyhodnocení HTTP serverů (test H1), následně HTTP serverů s podporou PHP (test
P1 pro 1kB stránku a P2 pro 10kB stránku) a nakonec vyhodnotíme statický test
(S1). Naměřenou maximální hodnotu počtu vyřízených požadavků a statický test
vyhodnotíme pomocí tabulky. Ostatní sledované hodnoty zaneseme do grafu a
provedeme jejich vyhodnocení.
6.6.1 Test HTTP serverů (test H1)
Při testování HTTP serveru pomocí klasických HTML stránek jsme narazili
na limity. V případě H1 testu limity vyplývají zejména z výkonnostních omezení
klienta
Na následujících grafech (graf č. 1 až č. 3) je patrné, že při zhruba 26 tisících
požadavků za sekundu, dochází ke značnému poklesu využití CPU a narůstá
průměrná doba odpovědi. To je dáno zejména neschopností klienta generovat
požadavky (testovací program dále generuje požadavky, ale klient už nemůže otevřít
další spojení) a neschopností zpracovat příchozí odpovědi. Proto tyto extrémní
hodnoty nebudeme brát v úvahu při vyhodnocování.
75
Maximální naměřená hodnota obsloužených požadavků za sekundu pro
jednotlivé konfigurace je uvedena v tabulce č. 2. Pokud porovnáme tato čísla s grafy
je patrné, že při testování jsme nenarazili na limit HTTP serveru, ale na limity
testovacích podmínek.
Tabulka 2 - Maximálně naměření počet požadavků za sekundu test H1
MAX RQ/s
K1
K2
K3
H1
25960,6
25968,7
25933,5
Z grafu č. 1 vidíme, že při předávání statického obsahu nejméně vytěžuje
procesoru konfigurace číslo 3 (Nginx). Konfigurace číslo jedna (Apache prefork)
vykazuje přibližně stejné nároky na CPU jako konfigurace číslo 2 (Apache worker).
využití CPU (%)
Závislost využití CPU na počtu požadavků za
sekundu - test H1
100
90
80
70
60
50
40
30
20
10
0
K1
K2
K3
Počet požadavků za sekundu
Graf 1 - využití CPU v testu H1
Avšak v případě grafu závislosti využití paměti na počtu požadavků za
sekundu (graf č. 2) je situace zcela jiná. Nginx využívá zhruba o 100MB paměti víc
než Apache worker a o 60MB víc ne Apache prefork. Tedy z hlediska využití paměti
je nejúspornější Apache worker.
76
Využívaná paměť (MB)
Závislost využití paměti na počtu požadavků za
sekundu - test H1
200
150
100
K1
50
K2
K3
0
Počet požadavků za sekundu
Graf 2 - využití paměti v testu H1
Další sledovanou hodnotou je průměrná doba odpovědi. Obecně lze
konstatovat, že doba odpovědi se příliš neliší. Kromě jednoho případu se průměrná
doba odezvy všech serverů pohybovala v rozmezí 0,1-0,5ms. Nejnižších hodnot
dosahoval Nginx avšak jak je patrné z grafu č. 3 při 14000 požadavcích za sekundu
se vyskytl na serveru problém a průměrná doba zpracování vzrostla o 0,8ms.
průměrná doba odpovědi (ms)
Závislost průměrné doby odpovědi na počtu
požadavků za sekundu - test H1
3,5
3
2,5
2
1,5
K1
1
K2
0,5
K3
0
Počet požadavků za sekundu
Graf 3 - průměrná doba odpovědi v testu H1
Sledovaná hodnota chybovosti se v případě testování samotného HTTP
serveru neprojevila – nebyla zaznamenána ani jedna chyba ze strany serveru. V grafu
závislosti počtu chyb na počtu požadavků za sekundu (příloha č. 5) sice chybovost
77
prudce vzrostla, ale byla generována na straně klienta (nebyl schopen zpracovat
odpovědi serveru).
6.6.2 Test HTTP serverů s podporou PHP
Také při testování HTTP serveru s podporou PHP pomocí PHP stránek jsme
narazili na limity. Ovšem v případě testu P1 (1kB velikosti PHP stránky) test proběhl
regulérně, tj. nenarazili jsme na omezení ze strany klienta či sítě.
V případě testu P2 mohlo dojít k omezení ze strany sítě. Objem přenášených
dat (viz příloha č. 6) dosáhl hodnoty 90MB/s (720Mb/s). Tato hodnota sice není limit
1Gb/s sítě, ale nemůžeme předpokládat ideální podmínky. Tudíž nelze vyloučit, že
došlo k plnému vytížení sítě.
Nejprve se podíváme na maximální naměřený počet požadavků za sekundu
(tabulka č. 3). Z tabulky je patrné, že konfigurace číslo jedna je jasným vítězem. A to
jak v obou variantách testu. K3 v případě P1 testu zvládla zhruba o 2 tisíce
požadavků za sekundu víc než konfigurace K2. U P2 testu však K2 zvládla o tisíc
požadavků více než K3.
Tabulka 3 - Maximálně naměřený počet požadavků za sekundu testy P1 a P2
MAX
RQ/s
P1
P2
K1
11990
8992,8
K2
7996,7
5995,3
K3
9789,3
4998,7
78
Test P1
Závislost využití CPU na počtu požadavků za
sekundu - test P1
zatížení CPU (%)
100
80
60
40
K1
20
K2
0
K3
Počet požadavků za sekundu
Graf 4 - využití CPU v testu P1
Z grafu č. 4 je patrné že nejméně zatěžuje procesor konfigurace číslo jedna.
Naopak konfigurace číslo 3 si oproti klasickým HTML stránkám markantně
pohoršila. Dále lze konstatovat, že konfigurace 2 a 3 jsou z hlediska využití CPU
podobné.
V případě využití paměti (graf č. 5) je situace úplně jiná. Konfigurace číslo 2
po dosažení svého maximálního počtu obsloužení požadavků začala alokovat
mnohem více paměti než konfigurace číslo 3. Nejméně paměti spotřebovala
konfigurace číslo 1.
Tento jev je pravděpodobně dán faktem, že konfigurace K2 a K3 využívají
externí PHP interpreter, kterému se požadavky předávají přes FastCGI rozhraní. Tyto
konfigurace tedy musí spouštět mimo vlastních procesů (či vláken) ještě dodatečné
procesy, které se starají o zpracování PHP, což vede ke zvýšeným nárokům na
využití CPU a paměť.
79
využívaná pamět (MB)
Závislost využití paměti na počtu požadavků za
sekundu - test P1
500
400
300
200
K1
100
K2
0
K3
Počet požadavků za sekundu
Graf 5 - využití paměti v testu P1
Průměrná doba odpovědi (graf č. 6) se v případě K1 pohybuje v intervalu 0,30,4ms. To je jen o 0,1ms horší než v případě statické HTML stránky. Také
konfigurace číslo 3 vykazuje, až do svého maxima obsloužených požadavků stabilní
průměrnou dobu odezvy. V případě K2 dochází po dosáhnutí maximálního počtu
obsloužených požadavků k neúměrnému růstu průměrné doby odpovědi. Tento růst
průměrná doba odpovědi (ms)
je zřejmě spojen s nárůstem vyžadované paměti.
Závislost průměrné doby odpovědi na počtu
požadavků za sekundu -test P1
100
80
60
40
K1
20
K2
0
K3
Počet požadavků za sekundu
Graf 6 - průměrná doba odpovědi v testu P1
V testu P1 se již projeví chybovost na straně serveru (viz příloha č. 8). Po
dosáhnutí maximálního počtu obsloužených požadavků u konfigurace č. 2 dochází
k prudkému
nárůstu
chybovosti.
Podobný
průběh
lze
v delším
horizontu
předpokládat i u konfigurace číslo 3.
80
Test P2
Závislost využití CPU na počtu požadavků za
sekundu - test P2
zatížení CPU (%)
100
80
60
40
K1
20
K2
0
K3
Počet požadavků za sekundu
Graf 7 - využití CPU v testu P2
Z grafu č. 7 vidíme, že konfigurace č. 1 zatěžuje CPU nejméně. Konfigurace
2 a 3 jsou z hlediska zatížení CPU podobné.
V případě využití paměti (graf č. 8) je situace podobná jako v případě testu
P1. Z porovnání s grafem č. 4 vyplývá, že velikost stránky nemá významný vliv na
velikost využívané paměti. Nejméně paměti využívala konfigurace číslo 1.
Konfigurace číslo 2 po dosažení svého maximálního počtu obsloužení požadavků
začala alokovat mnohem velké množství paměti. Konfigurace číslo 3 si i po dosažení
maximálního počtu obsloužených požadavků zachovala konstantní růst.
Průměrná doba odpovědi (graf č. 9) před dosažením maxima se u všech
konfigurací pohybuje okolo 0,5ms. Situace je v případě P2 testu velmi podobná
situaci z testu P1. Hlavním rozdílem je kdy nastane rapidní zvýšení průměrné doby
odpovědi. To souvisí s dosažením maximálního možného počtu obsloužených
požadavků.
81
Závislost využití paměti na počtu požadavků za
sekundu - test P2
yužití paměti (MB)
600
500
400
300
K1
200
K2
100
K3
0
Počet požadavků za sekundu
Graf 8 - využití paměti v testu P2
průměrná doba odpovědi (ms)
Závislost průměrmé doby odpovědi na počtu
požadavků za sekundu - test P2
160
140
120
100
80
60
40
20
0
K1
K2
K3
Počet požadavků za sekundu
Graf 9 - průměrná doba odpovědi v testu P2
V testu P2 se ještě více projevuje chybovost (příloha č. 8). Při testu P2 se
jsme narazili i na chybovost konfigurace K1. Stejně jako v případě P1 po dosáhnutí
maximálního
počtu
obsloužených
požadavků
dochází
k prudkému
nárůstu
chybovosti.
6.6.3 Statický test zdrojů (S1)
Ve statickém testu zdrojů (tabulka č. 4) zvítězila konfigurace číslo 2. Při 100
aktivních session spotřebovávala pouze 88,5MB paměti. Nejhůře v testu dopadla
konfigurace číslo 3, která spotřebovávala 121,5MB paměti. Z toho testu lze tedy
82
usoudit, že pro případ konstantního počtu session s relativně malým počtem
požadavků je z hlediska paměti úspornější vícevláknový model Apache worker.
Tabulka 4 - Využití paměťi v MB při 100 session
MB
S1
K1
K2
K3
100,3904 88,48185 121,5349
6.7 Zhodnocení konfigurací
Testování bylo limitováno výkonem testovacího klienta a rychlostí sítě.
Například na začátku testování jsme použili 100Mb/s síťový adaptér který se
okamžitě ukázal jako limitující pro testování a bylo proto nutno přejít na síť 1Gb/s.
Určení maximální počtu obsloužených požadavků za sekundu testovaných
konfigurací pro HTML stránky (bez PHP) je mimo schopnosti námi použité testovací
sestavy. Z tohoto důvodu nejsme schopni stanovit maximálně možný počet
obsloužených požadavků za sekundu testovaných konfigurací. Změření této hodnoty
by vyžadovalo použití více klientů a využití více síťových adaptérů na serveru
(případně rychlejší sítě).
V případě testu P2 byla zvolena velikost stránky 10kB aby nedocházelo
k omezování díky malé propustnosti sítě. Tím jsme zajistili, že datový tok při
maximálního počtu obsloužených požadavků za sekundu byl menší než 750Mb/s.
Test H1 ukázal, že v případě maximálního naměřeného počtu obsloužených
požadavků si jsou všechny tři konfigurace rovny. Proto se při vyhodnocení tohoto
testu zaměříme zejména na využívání systémových zdrojů a průměrné doby
odpovědi. V tomto testu však není jednoznačný vítěz.
Konfigurace číslo jedna zatěžovala CPU nejvíce, průměrná doba odpovědi
byla stejná s konfigurací číslo 2 a v případě využívání paměti obsadila druhé místo.
Konfigurace číslo 2 využívala nejméně paměti a zátěž CPU byla o něco menší než u
konfigurace číslo 1.
Konfigurace číslo 3 zatěžovala CPU nejméně, při maximálním naměřeném
počtu obsloužených požadavků za sekundu zatěžovala CPU o cca 35% méně než
ostatní konfigurace. Ovšem využití paměti bylo zhruba o 100MB větší než v případě
83
konfigurace číslo 2 a o 65MB větší než v případě K1. Průměrná doba odezvy K3
byla zhruba o 0,1 – 0,2ms lepší než u ostatních konfigurací.
Volba konfigurace by tedy záležela na dostupných systémových zdrojích.
V případě nedostatku paměti by bylo vhodné zvolit konfiguraci číslo 2, tj. Apache
s MPM worker. Konfigurace číslo 3 by byla vhodná v případě většího množství
paměti.
V P1 i P2 testu si po všech stranách nejlépe vedla konfigurace číslo 1 tj.
Apache prefork. V těchto testech dokázala obsloužit nejvíc požadavků za sekundu,
s nejmenšími nároky na systémové zdroje a nejmenší průměrnou odezvou. Výsledek
je pravděpodobně dán velmi dobrou integrací s PHP interpretrem.
Z pohledu uvažovaného využití webového serveru (provoz PHP aplikací)
v naší firmě se jeví jako nejvhodnější konfigurace číslo 1 tj. Apache2 s MPM
modulem prefork a modulem mod_php5. Ovšem lze využít jakoukoliv z těchto tří
konfigurací, protože jejich výkon je dostatečný. Reálná výkonost bude dána rychlostí
PHP aplikací.
Konfigurace číslo dvě vykazuje nejmenší nároky na využití paměti. Z tohoto
důvodu je tato konfigurace vhodná zejména pro malé instalace využívající pouze
HTTP server bez PHP.
84
7 Závěr
Cílem diplomové práce bylo navrhnout konfiguraci firemního serveru pro
menší firmu (do 50 uživatelů) a otestování výkonnosti několika implementací
webových serverů.
Autor se zaměřil na konfiguraci sítových služeb. V úvodní teoretické části se
zabýval problematikou jednotlivých služeb. Pokusil se zde za pomoci odborné
literatury definovat všechny důležité služby, které jsou používány ve firemních sítích
a stanovit doporučení pro konfiguraci těchto služeb.
V praktické části je uvedena konfigurace serveru vhodného pro menší firmu.
Byla vybrána distribuce operačního systému Linux openSUSE 11.3.
Konfigurace popisuje nastavení základních sítových služeb, souborového
serveru, řadiče Windows domény, poštovního serveru, IMAP serveru a webového
serveru s podporou PHP a SSL. Pro zjednodušení správy uživatelů je autentizace
řešena centrální databází s využitím řadiče Windows domény. Tento řadič je
realizován aplikací Samba serveru.
Na takto nakonfigurovaném systému byly porovnány dvě softwarové
implementace webového serveru, Apache verze 2 a NGINX verze 0.8. Byly
nastaveny 3 různé konfigurace – Apache s procesovým a vláknovým zpracováním a
Nginx. Dále byly tyto konfigurace porovnávány z hlediska výkonnosti při
simulované zátěži. Byly použity testy samotného HTTP serveru a HTTP serveru
s podporou PHP. Detailní výsledky testu jsou uvedeny v kapitole 6.
Zjištěné výsledky výkonnostních testů ukazují, že výkon testovaných
konfigurací vysoce překračuje běžné potřeby malých firem. Výsledky těchto testů
najdou spíše uplatnění pro webové servery s větším počtem uživatelů (několik set).
Z pohledu uvažovaného využití webového serveru (provoz PHP aplikací)
v naší firmě se jeví jako nejvhodnější Apache2 s MPM modulem prefork a modulem
mod_php5.
85
Výsledkem práce je uvedená konfigurace serveru využívající distribuci
openSUSE Linux, která splňuje typické požadavky malých firem. Před případným
nasazením uvedených konfigurací by nutné řešit otázku bezpečnosti. Ta vzhledem
k omezenému rozsahu této práce není součástí konfigurace.
86
8 Seznam použitých zdrojů
1. VESELÝ, Arnošt. Operační systémy II. Praha : Česká zemědělská univerzita v
Praze, 2008. str. 255. 978-80-213-1553-2.
2. NEMETH, Evi, SNYDER, Garth a HEIN, Trent. LINUX - Kompletní příručka
administrátora. Brno : Computer Press, a.s., 2008. 978-80-251-2410-9.
3. SHAH, Steve a SOYINKA, Wale. Administrace systému Linux. Praha : Grada
Publishing, a.s., 2007. str. 426. 978-80-247-1694-7.
4. SINGH, Arnit. Access Control. Access Control. [Online] 2004. [Citace: 7. 2.
2011.] <http://www.kernelthread.com/publications/security/ac.html>.
5. IBM. Access control: MAC and DAC. [Online] [Citace: 7. 2. 2011.]
<http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/seli
nux/liaaiselinuxmacdac.htm>.
6. FIŠER, Jan. Principy operačních systémů II. [Online] 2007. [Citace: 8. 2. 2011.]
<http://ithil.ujep.cz/workspace/OS-2.pdf>.
7. NIST. ROLE BASED ACCESS CONTROL - FREQUENTLY ASKED
QUESTIONS. NIST.gov - Computer Security Division - Computer Security Resource
Center. [Online] 2007. [Citace: 8. 2. 2011.]
<http://csrc.nist.gov/groups/SNS/rbac/faq.html>.
8. Kolektiv autorů. Linux - dokumentační projekt. Brno : Computer Press a.s., 2008.
str. 787. 978-80-251-1525-1.
9. FIALKA, Michal. Přidělování procesoru procesům a vláknům v Linuxu. Root.cz.
[Online] 2010. [Citace: 12. 2. 2011.] <http://www.root.cz/clanky/pridelovaniprocesoru-procesum-a-vlaknum-v-linuxu/>.
10. Network Working Group. RFC 2308 - Negative Caching of DNS Queries
(DNS NCACHE). [Online] 1998. [Citace: 15. 02. 2011.]
11. NORIS, Ivan. 6. Služby mailového servera. Služby mailového servera. [Online]
2007. [Citace: 17. 2. 2011.] <http://deja-vix.sk/sysadmin/postfix.html>.
12. Postfix.org. Postfix Architecture Overview. [Online] [Citace: 16. 2. 2011.]
<http://www.postfix.org/OVERVIEW.html>.
13. HTTP Message Structure. [Online] [Citace: 18. 2. 2011.]
<http://www.tutorialspoint.com/http/http_messages.htm>.
14. W3C. HTTP/1.1:Request. [Online] 2004. [Citace: 18. 2. 2011.]
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5>.
15. —. HTTP/1.1:Response. [Online] 2004. [Citace: 18. 2. 2011.]
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6>.
16. —. HTTP/1.1: HTTP Message. [Online] 2004. [Citace: 18. 2. 2011.]
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4>.
87
17. Janovský, Dušan. Jak psát web. Programování stránek. [Online] 2004.
<http://www.jakpsatweb.cz/programovani.html>.
18. Network Working Group. RFC 2617. HTTP Authentication: Basic and Digest
Access Authentication. [Online] 1999. [Citace: 18. 2. 2011.]
<http://www.ietf.org/rfc/rfc2617.txt>.
19. RESCROLA, Eric. RFC 2818 - HTTP over TSL. HTTP Over TSL. [Online]
[Citace: 19. 2. 2011.] <tools.ietf.org/html/rfc2818>.
20. AULDS, Charles. Linux - administrace serveru Apache. Praha : Grada
Publishing a.s., 2003. str. 535. 80-247-0640-7.
21. COWNIE, Jennifer. Netcraft. February 2011 Web Server Survey. [Online]
2011. [Citace: 19. 2. 2011.] <http://news.netcraft.com/archives/2011/02/15/february2011-web-server-survey.html>.
22. POŠMURA, Vlastimil. Historie a vývoj Apache. [Online] 2002. [Citace: 20. 2.
2011.]
<http://www.posmura.cz/index.php?option=com_content&view=article&id=86:1historie-a-vyvoj-apache-&catid=55:piruka-administratora&Itemid=62>.
23. The Apache Software Foundation. Module Index - Apache HTTP Server.
[Online] 2011. [Citace: 20. 2. 2011.] <http://httpd.apache.org/docs/2.2/mod/>.
24. DRAGOI, Octavian. The Conceptual Architecture of the Apache Web Server.
[Online] 1999. [Citace: 20. 2. 2011.] <http://www.voneicken.com/courses/ucsbcs290i-wi02/papers/Concept_Apache_Arch.htm>.
25. The Apache Group. Apache Reference: http_core. [Online] [Citace: 20. 2.
2011.] <http://www.apacheref.com/ref/http_core.html>.
26. GROSS, Christian. Working with Open Source. [Online] [Citace: 21. 2. 2011.]
<http://apr.apache.org/apr2_0intro/apr2_0intro.htm>.
27. The Apache Portable Runtime Project. Apache Portable Runtime Utility
1.3.10 Released. [Online] 2010. [Citace: 21. 2. 2011.]
<http://www.apache.org/dist/apr/Announcement1.x.html>.
28. The Apache Software Foundation. Multi-Processing Modules (MPMs).
[Online] 2011. [Citace: 21. 2. 2011.] <http://httpd.apache.org/docs/2.0/mpm.html>.
29. —. prefork - Apache HTTP Server. [Online] 2011. [Citace: 21. 2. 2011.]
<http://httpd.apache.org/docs/2.2/mod/prefork.html>.
30. —. worker - Apache HTTP Server. [Online] 2011. [Citace: 21. 2. 2011.]
<http://httpd.apache.org/docs/2.2/mod/worker.html>.
31. —. Terms Used to Describe Directives. [Online] 2011. [Citace: 23. 2. 2011.]
<http://httpd.apache.org/docs/2.2/mod/directive-dict.html#Context>.
32. —. Directive Index - Apache HTTP Server. [Online] 2011. [Citace: 23. 2. 2011.]
<http://httpd.apache.org/docs/2.2/mod/directives.html>.
88
33. —. Apache Tutorial: .htaccess files - Apache HTTP Server. [Online] 2011.
[Citace: 23. 2. 2011.] <http://httpd.apache.org/docs/2.2/howto/htaccess.html>.
34. —. Apache Module mod_authz_host. [Online] 2011. [Citace: 25. 2. 2011.]
<http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html>.
35. —. Authentication, Authorization and Access Control - Apache HTTP Server.
[Online] 2011. [Citace: 25. 2. 2011.] <httpd.apache.org/docs/2.2/howto/auth.html>.
36. —. SSL/TLS Strong Encryption: FAQ - Apache HTTP Server. [Online] 2011.
[Citace: 26. 2. 2011.] <http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html>.
37. Nginx. [Online] 2010. [Citace: 26. 2. 2011.] <http://nginx.org/en/>.
38. Nginx. Faq. [Online] 2010. [Citace: 28. 2. 2011.] <http://wiki.nginx.org/Faq>.
39. PORTANE, Peter. Demystifying Non-Blocking and Asynchronous I/O (#164).
[Online] 2010. [Citace: 28. 2. 2011.]
<http://us.pycon.org/2010/conference/schedule/event/68/>.
40. Nginx. EvenstModule. [Online] 2010. [Citace: 28. 2. 2010.]
<http://wiki.nginx.org/EventsModule>.
41. ZHU, Joshua. Nginx Internals. [Online] 2009. [Citace: 28. 2. 2010.]
<http://www.slideshare.net/joshzhu/nginx-internals>.
42. NEDELCU, Clément. Nginx HTTP Server. Birmingham : Packt Publishing,
2010.
43. MILLER, Evan. Emiller's Guide to Nginx Module Development. [Online] 2009.
[Citace: 28. 2. 2011.] <http://www.evanmiller.org/nginx-modulesguide.html#components>.
44. FJORDVALD, Martin. Nginx Primer. [Online] 2010. [Citace: 28. 2. 2011.]
<http://blog.martinfjordvald.com/2010/07/nginx-primer>.
45. KLEINMAN, Sam. Basic Nginx Configuration. [Online] 2010. [Citace: 28. 2.
2011.] <http://library.linode.com/web-servers/nginx/configuration/basic>.
46. Nginx. Modules. [Online] 2011. [Citace: 28. 2. 2011.]
<wiki.nginx.ogr/modules>.
47. Igor, SYSOEV. Configuring HTTPS servers. [Online] [Citace: 12. 3. 2011.]
<http://nginx.org/en/docs/http/configuring_https_servers.html>.
89
9 Přílohy
Příloha 1 - Stavové kódy (status code) ...................................................................... 90
Příloha 2 - soubor httpd.conf ..................................................................................... 92
Příloha 3 - regulární výrazy PCRE ............................................................................ 93
Příloha 4 - Definice malého podniku ......................................................................... 94
Příloha 5 - výsledky testu H1 ..................................................................................... 96
Příloha 6 - výsledky testu P1 ..................................................................................... 97
Příloha 7 - výsledky testu P2 ..................................................................................... 98
Příloha 8 - Graf chybovosti testu H1 ....................................................................... 100
Příloha 9 - Graf přenesených dat za sekundu test P2 ............................................... 100
Příloha 10 - Graf chybovosti testu P1 ...................................................................... 101
Příloha 11 - Graf chybovosti testu P2 ...................................................................... 101
Příloha 1 - Stavové kódy (status code)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Informační stavové kódy
100 – Continue – klient může začít posílat data
101 - Switching Protocols – změna protokolu
Stavové kódy o úspěchu vyřízení požadavku
200 – OK – požadavek byl obsloužen bez chyb
201 – Created – výsledkem zpracování požadavku je nově vytvořené URL
202 – Accepted – požadavek byl přijat, ale klient musí počkat na dokončení
203 - Non-Authoritative Information – vrácený obsah není poslán z původního
serveru (který vyřizoval požadavek)
204 - No Content – server zpracoval požadavek, ale výsledkem nevznikla žádná
data, která by se měla zaslat klientovi
205 - Reset Content – server obsloužil požadavek a klient by měl nastavit původní
obsah dokumentu, který způsobil zaslání požadavku
206 - Partial Content – požadavek byl vyřízen, ale výsledek není kompletní stránkou
pouze její částí
Stavové kódy indikující přesměrování
300 - Multiple Choices – požadovaný obsah je dostupný na několika místech,
uživatel si může zvolit umístění a přesměrovat požadavek na toto umístění
301 - Moved Permanently – požadovaný obsah byl trvale přestěhován na novou
adresu
302 – Found - požadovaný obsah se dočasně nachází na jiné adrese, další požadavky
by měly směřovat na původní adresu
303 - See Other – požadovaný obsah je dostupný na jiné adrese
304 - Not Modified - Požadovaný obsah nebyl změněn, používá se, když server
zkontroluje, jestli byl dokument od posledního načtení změněn
305 - Use Proxy – požadavek musí být znovu poslán prostřednictvím proxy uvedené
serverem
90
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
307 - Temporary Redirect – požadovaný obsah byl dočasně přesunut na jinou adresu
Chybové stavové kódy na straně klienta
400 - Bad Request – špatná syntaxe požadavku
401 – Unauthorized – požadavek vyžaduje autentizaci uživatele
402 - Payment Required – stavový kód vyhrazen pro budoucí použití
403 – Forbidden – server rozumí požadavku, ale odmítá ho obsloužit
404 - Not Found – požadovaný obsah neexistuje
405 - Method Not Allowed – metoda požadavku není podporována serverem
406 - Not Acceptable – odpověď serveru není podporována klientem
407 - Proxy Authentication Required – požadavek vyžaduje autentizaci proxy
serverem
408 - Request Time-out – vypršel čas klienta na vytvoření požadavku
409 – Conflict – požadavek nemůže být vyřešen z důvodu konfliktu se současným
stavem obsahu
410 – Gone - požadovaný obsah neexistuje a předpokládá se, že trvale
411 - Length Required – klient v požadavku neudává požadovanou délku obsahu
412 - Precondition Failed – předpoklad v požadavku byl serverem vyhodnocen jako
chybný
413 - Request Entity Too Large – server odmítá vyřídit požadavek, protože
požadovaný obsah je větší než server může zpracovat
414 - Request-URI Too Large – server odmítá vyřídit požadavek, protože URI je
příliš dlouhá
415 - Unsupported Media Type – server nemůže vyřídit požadavek, protože
nepodporuje požadovaný formát
416 - Requested range not satisfiable – v případě že specifikovaný rozsah v hlavičce
požadavku neodpovídá obsahu na serveru
417 - Expectation Failed – server nemůže splnit podmínku v hlavičce požadavku
Chybové stavové kódy na straně serveru
500 - Internal Server Error – při zpracování požadavku se vyskytla neočekávaná
chyba, která zabránila zpracování dotazu
501 - Not Implemented – server nerozpoznal metodu požadavku
502 - Bad Gateway – server fungující jako brána nebo proxy obdržel chybnou
odpověď od serveru, který požadavek zpracovával
503 - Service Unavailable – server nemůže dočasně vyřídit požadavek
504 - Gateway Time-out - server fungující jako brána nebo proxy neobdržel v
odpověď od serveru, který požadavek zpracovával v definovaném čase
505 - HTTP Version not supported – server nepodporuje verzi protokolu
specifikovanou v hlavičce požadavku
Zdroj: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
91
Příloha 2 - soubor httpd.conf
### Global Environment ############################################
Include /etc/apache2/uid.conf
Include /etc/apache2/server-tuning.conf
ErrorLog /var/log/apache2/error_log
Include /etc/apache2/sysconfig.d/loadmodule.conf
Include /etc/apache2/listen.conf
Include /etc/apache2/mod_log_config.conf
Include /etc/apache2/sysconfig.d/global.conf
Include /etc/apache2/mod_status.conf
Include /etc/apache2/mod_info.conf
Include /etc/apache2/mod_usertrack.conf
Include /etc/apache2/mod_autoindex-defaults.conf
TypesConfig /etc/apache2/mime.types
DefaultType text/plain
Include /etc/apache2/mod_mime-defaults.conf
Include /etc/apache2/errors.conf
Include /etc/apache2/ssl-global.conf
<Directory />
Options None
AllowOverride None
Order deny,allow
Deny from all
</Directory>
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>
### 'Main' server configuration ####################################
92
Include /etc/apache2/default-server.conf
Include /etc/apache2/sysconfig.d/include.conf
### Virtual server configuration ###################################
Include /etc/apache2/vhosts.d/*.conf
####################################################################
Příloha 3 - regulární výrazy PCRE
Metaznačky
•
^ – znak za touto metaznačkou musí být na počátku řetězce znaků.
o ^a – všechny řetězce začínající znakem a
•
$ – znak před touto metaznačkou musí být na konci řetězce znaků.
o j$ - všechny řetězce končící znakem j
•
. – jakýkoliv znak.
o Aho. – všechny čtyřpísmenné řetězce začínající Aho
•
[ ] – udává množinu znaků, kterým řetězec musí odpovídat.
o A[a-z] – všechny dvoupísmenné řetězce začínající A a končící
kterýmkoliv znaků z množiny a-z
•
[^ ] – udává množinu znaků, které se nesmí v řetězci vyskytovat.
•
| - udává podmínku nebo
o Ahoj|Nazdar – všechna slova obsahující řetězec Ahoj nebo Nazdar
•
( ) – umožňují sdružování podmínek
o ^(Ahoj|Nazdar)!$ - slova Ahoj! a Nazdar!
•
\ - regulární výraz za tímto znakem nebude vyhodnocen jako regulární výraz
ale jako obyčejný znak
93
Kvantifikátory
•
* - znak před tímto kvantifikátorem se může vyskytovat v libovolném počtu
(včetně 0-krát).
o Ah*oj – všechna slova obsahující řetězec Ahoj s libovolným počtem
h (a to včetně 0)
•
+ - znak před tímto kvantifikátorem se musí vyskytovat jednou a víckrát.
o Ah+oj – všechna slova obsahující řetězec Ahoj s libovolným počtem
h
•
? - znak před tímto kvantifikátorem se musí vyskytovat právě jednou nebo
vůbec.
o Ah?oj – slova Ahoj a Aoj
•
{x} - znak před tímto kvantifikátorem musí být obsažen x-krát.
o Ah{3}oj – slovo Ahhhoj
•
{x, } - znak před tímto kvantifikátorem se musí vyskytovat minimálně x-krát.
o Ah{3,}oj – slova Ahoj, ve kterých se vyskytuje 3 a více h
•
{x,y} - znak před tímto kvantifikátorem se musí vyskytovat v intervalu od x
do y.
o Ah{1,2}oj – slova Ahoj a Ahhoj
Zdroj: [42]
Příloha 4 - Definice malého podniku
Malé podniky jsou vymezeny jako podniky, které zaměstnávají méně než 50
osob a jejichž roční obrat nebo bilanční suma roční rozvahy nepřesahuje 10 milionů
eur.
Počet zaměstnanců
Počet zaměstnanců je rozhodujícím počátečním kritériem k určení, do které
kategorie podnik patří. Vztahuje se na osoby s plným pracovním úvazkem,
částečným pracovním úvazkem a sezónní pracovníky a zahrnuje:
• zaměstnance,
94
• osoby pracující pro podnik v podřízeném postavení, které jsou považovány
za zaměstnance v souladu s vnitrostátním právem,
• vlastníky, kteří řídí společnost,
• společníky zapojené do běžné činnosti podniku, kteří využívají finančních
výhod plynoucích z podniku.
Učni a studenti, kteří jsou zapojeni do odborné přípravy na základě smlouvy o
učňovském nebo odborném vzdělávání, se nezahrnují do počtu zaměstnanců.
Délka mateřské nebo rodičovské dovolené se nezapočítává. Počet
zaměstnanců se vyjadřuje v ročních pracovních jednotkách (RPJ). Kdokoli, kdo byl v
daném podniku nebo jeho jménem zaměstnán na plný pracovní úvazek po celý
sledovaný rok, se počítá jako jedna jednotka. Osoby s částečným pracovním
úvazkem, sezónní pracovníky a osoby, které nepracovaly po celý rok, započtete jako
zlomky jedné jednotky.
Roční obrat a bilanční suma roční rozvahy
Roční obrat se určuje výpočtem příjmů, které váš podnik získal během
daného roku z prodeje a ze služeb po odečtení vyplacených slev. Obrat by neměl
zahrnovat daň z přidané hodnoty (DPH) ani jiné nepřímé daně3. Bilanční suma roční
rozvahy se vztahuje k hodnotě hlavních aktiv vaší společnost4.
Vztahy s jinými podniky
Při sestavování vašich údajů budete muset zjistit, zda je váš podnik nezávislý
(což je zdaleka nejběžnější kategorie), partnerský nebo propojený. Za tímto účelem
musíte vzít v úvahu všechny vztahy, které máte s jinými podniky. Podle kategorie,
do které váš podnik patří, budete pak muset připočíst některé nebo všechny údaje
těchto podniků k vašim údajům. Výpočty pro každý z těchto tří druhů podniků se liší
3
Viz článek 28 směrnice Rady 78/660/EHS ze dne 25. července 1978, založené na čl. 54
odst. 3 písm. g) Smlouvy, o ročních účetních závěrkách některých forem společností, Úřední věstník
L 222, s. 11–31, ze dne 14. srpna 1978
4
Pro více podrobností viz čl. 12 odst. 3 směrnice Rady 78/660/EHS ze dne 25. července
1978, založené na čl. 54 odst. 3 písm. g) Smlouvy, o ročních účetních závěrkách některých forem
společností, Úřední věstník L 222, s. 11–31, ze dne 14. srpna 1978.
95
a budou nakonec určovat, zda splňujete různé stropy zavedené definicí malých a
středních podniků. Podniky, které sestavují konsolidované účetní závěrky nebo které
jsou zahrnuty do účetních závěrek podniku, který je sestavuje, se obvykle považují
za propojené.
Zdroj: Evropská komise
http://ec.europa.eu/enterprise/policies/sme/files/sme_definition/sme_user_guide_cs.p
df
Příloha 5 - výsledky testu H1
K1
req. rate
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
22000
24000
26000
28000
30000
K2
req. rate
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
22000
24000
26000
28000
30000
Data K1
CPU usage
(avg)
9,51
18,49
29,44
38,46
47,60
55,80
59,08
81,17
82,16
85,85
92,25
94,49
90,75
45,12
1,00
Memory
(avg)
563879,38
569518,67
575056,89
580810,00
586104,80
591418,00
597492,00
603314,67
607892,00
612789,33
618276,00
623274,00
628420,00
632806,00
632608,00
Data K2
CPU usage
(avg)
10,14
20,37
30,67
36,18
49,79
58,79
67,59
80,30
81,33
70,33
79,63
93,75
95,24
3,98
0,00
Memory
(avg)
476490,00
481355,38
486672,50
491794,00
497138,40
502163,00
508044,00
513660,00
519094,67
524292,00
529881,33
535900,00
541278,00
543436,00
543424,00
Errors
Net I/O
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
9,90
101,00
2535,20
5069,50
7602,40
10135,80
12670,50
15201,70
17733,20
20263,30
22799,00
25324,90
27844,20
30380,60
32907,10
17831,80
0,00
Errors
Net I/O
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
9,85
101,00
2535,10
5069,30
7602,90
10137,10
12668,30
15198,50
17729,20
20269,80
22798,10
25320,90
27847,30
30389,60
32917,40
17882,60
0,00
response
time(avg)
0,40
0,30
0,30
0,30
0,30
0,20
0,20
0,30
0,30
0,30
0,30
0,30
0,50
1,30
0,00
response
time (avg)
0,40
0,30
0,30
0,20
0,30
0,20
0,20
0,20
0,30
0,20
0,20
0,30
0,60
2,60
0,00
96
K3
req. rate
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
22000
24000
26000
28000
30000
Data K3
CPU usage
(avg)
6,09
12,35
16,55
22,75
30,73
33,85
33,61
49,19
45,63
52,91
58,25
56,88
62,41
4,59
0,25
Memory
(avg)
553142,15
558841,23
564383,00
569647,33
574652,80
579805,00
586476,67
591934,67
597482,67
602530,00
606792,00
612846,67
619408,00
621169,33
621252,00
Errors
Net I/O
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
9,86
101,00
2527,40
5053,90
7580,20
10107,50
12633,20
15155,30
11794,60
20209,30
22728,40
25249,20
27774,50
30298,30
32771,50
8317,50
0,00
response
time (avg)
0,30
0,20
0,20
0,20
0,10
0,10
0,90
0,10
0,10
0,10
0,20
0,30
1,70
3,20
0,00
Příloha 6 - výsledky testu P1
K1
req. rate
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
11000
12000
Data
CPU usage
(avg)
8,64
17,08
25,83
33,62
41,73
51,34
60,04
67,16
76,10
68,15
77,96
71,11
Memory
(avg)
485512,86
491076,00
496883,76
502258,46
506905,20
512433,50
517748,00
522800,67
528249,33
533523,20
538373,00
543886,40
Errors Net I/O
0
0
0
0
0
0
0
0
0
0
0
0
1191,5
2382,7
3573,8
4764,6
5955,1
7145
8335,8
9527,6
10718
11907,5
13096,3
14284,9
Response
time (avg)
0,4
0,4
0,4
0,4
0,4
0,4
0,3
0,3
0,3
0,3
0,3
0,3
K2
CPU usage
(avg)
Memory
(avg)
Errors
Net I/O
Response
time (avg)
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
11000
12000
16,64
26,96
41,78
55,85
69,56
55,58
77,99
87,34
82,69
75,37
88,97
77,03
547700,78
556489,12
561678,82
566185,33
571000,00
587128,67
625105,14
630076,67
707379,00
764787,50
796277,33
839790,29
0
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,45
1,67
2,50
3,18
1197,4
2394,4
3591,2
4787,5
5983,9
5218,5
8376,6
9572,8
7203
6456,9
7843,6
7499
6,5
0,5
0,5
0,5
0,5
4,7
0,4
0,4
60
90,4
85,9
72,6
97
K3
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
11000
12000
CPU usage
(avg)
12,78
28,24
37,56
48,77
63,29
73,64
78,87
82,62
88,90
97,00
56,89
52,83
Memory
(avg)
559704,00
566438,40
571795,06
577471,08
582773,20
588121,50
593742,29
599671,33
605020,67
614074,40
631934,18
636679,20
Errors Net I/O
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,00
0,05
0,83
1226,7
2453
3679,2
4905,1
6130,1
7355,5
8581,3
9806,7
11030,4
12007,2
5778
5565,8
Response time
(avg)
0,5
0,5
0,5
0,5
0,5
0,5
1,2
1,9
1,4
9,7
19,9
25,8
Příloha 7 - výsledky testu P2
1000
CPU usage
(avg)
12,63
2000
25,23
489577,60
0,00
19973,40
0,40
3000
38,52
494935,53
0,00
29958,40
0,30
4000
52,42
500599,67
0,00
39938,40
0,30
5000
63,97
505904,40
0,00
49918,00
0,40
6000
72,21
511182,50
0,00
59885,50
0,40
7000
79,10
517784,00
0,00
69865,40
0,40
8000
86,35
523112,67
0,00
79839,00
0,40
9000
91,29
527932,80
0,00
89813,70
0,50
10000
82,95
540202,00
0,00
62502,20
11,40
11000
55,85
567065,82
0,62
44654,30
19,20
12000
54,02
588930,40
1,62
42229,20
22,10
K1
Memory (avg)
Errors
Net I/O
483573,41
0,00
9988,00
Response
time (avg)
0,40
98
1000
CPU usage
(avg)
21,63
548480,63
0,00
9988,00
Response
time (avg)
6,90
2000
37,88
559834,24
0,00
19973,00
0,50
3000
55,99
565031,53
0,00
29955,00
0,50
4000
68,18
570464,62
0,00
39933,30
0,50
5000
81,64
575822,00
0,00
49909,30
0,60
6000
93,50
581064,00
0,00
59876,70
0,70
7000
70,99
684180,92
1,83
33342,10
136,30
8000
69,12
737750,91
3,15
33319,00
127,10
K2
Memory (avg)
Errors
Net I/O
9000
63,54
785588,00
4,39
31622,20
127,40
10000
57,68
828104,36
6,18
28966,40
138,90
11000
54,59
866258,55
6,42
29304,40
98,40
12000
59,04
915394,40
7,99
28159,60
113,30
Memory (avg)
Errors
Net I/O
559368,24
0,00
10017,40
Response
time (avg)
0,40
1000
CPU usage
(avg)
18,11
2000
32,30
566439,36
0,00
20031,70
0,50
3000
56,65
571690,12
0,00
30042,20
0,50
4000
67,82
577623,67
0,00
40050,70
0,60
5000
78,57
583457,20
0,00
50058,50
0,60
6000
82,67
590715,20
0,00
50070,20
11,10
7000
63,93
609988,62
0,00
38173,50
30,00
8000
63,35
619300,31
0,67
38370,10
27,40
9000
65,60
624612,00
1,81
37075,20
32,60
10000
59,49
628340,36
2,83
35527,10
42,20
11000
59,00
630164,36
3,68
34678,70
33,30
12000
58,64
634321,60
4,51
33873,80
36,90
K3
99
Příloha 8 - Graf chybovosti testu H1
H1 - Graf závislosti chybovosti na počtu
požadavků za sekundu
120
100
Počet chyb
80
60
K1
K2
40
K3
20
0
Počet požadavků za sekundu
Příloha 9 - Graf přenesených dat za sekundu test P2
Přenesená data (MB/s)
Závislost přenesených dat za sekundu
na počtu požadavků za sekundu - test
P2
100
90
80
70
60
50
40
30
20
10
0
K1
K2
K3
Počet požadavků za sekundu
100
Příloha 10 - Graf chybovosti testu P1
Závislost chybovosti na počtu požadavků
za sekundu - test P1
3,5
3
Počet chyb
2,5
2
K1
1,5
K2
K3
1
0,5
0
1000 2000 3000 4000 5000 6000 7000 8000 9000 100001100012000
Počet požadavků za sekundu
Příloha 11 - Graf chybovosti testu P2
Závislost počtu chyb na počtu požadavků
za sekundu - test P2
9
8
7
Počet chyb
6
5
K1
4
K2
3
K3
2
1
0
1000 2000 3000 4000 5000 6000 7000 8000 9000 100001100012000
Počet požadavků za sekundu
101
Download

Česká zemědělská univerzita v Praze Provozně