České vysoké učení technické v Praze Fakulta elektrotechnická
Bakalářská práce
Síťový dohlížeč na služby pro ISP Lubomír Svatý
Vedoucí práce: Ing. Zdeněk Muzikář, Csc.
Studijní program: Elektrotechnika a informatika, dobíhající Obor: Výpočetní technika Srpen 2007
2
Poděkování Považuji za svou milou povinnost poděkovat panu Ing. Zdeňkovi Muzikářovi za odborné a organizační vedení při zpracování této práce.
3
4
Prohlášení Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně za pomoci vedoucího bakalářské práce, s použitím citované literatury, ostatních informačních zdrojů a výsledků vlastního šetření. V Praze dne 20.8.2007
….………………... Lubomír Svatý
5
6
Obsah 1. Úvod …...................................................................................................................
5
2. Popis problému, specifikace cíle ............................................................................ 11 3. Návrh řešení …....................................................................................................... 17 4. Vypracování …....................................................................................................... 23 5. Testování …............................................................................................................ 29 6. Závěr …................................................................................................................... 33 7. Seznam literatury a zdrojů ...................................................................................... 35 A. Uživatelská příručka ….......................................................................................... 37 B. Obsah přiloženého CD …....................................................................................... 45
7
8
1
Úvod Pracuji jako správce internetových serverů pro společnost UPC ČR, a.s.
v oddělení internetu. Společnost UPC ČR, a.s. je jedním z předních poskytovatelů internetových služeb v České republice. Zajištění nepřetržité dostupnosti poskytovaných internetových služeb je dnes již standardem. Je mnoho faktorů, které tuto dostupnost ovlivňují nebo můžou narušit, například nestabilita aplikace poskytující službu na straně serveru, porucha hadrware serveru, porucha síťových prvků (přepínače, směrovače, konvertory, ...), porucha vedení. Zajištění co možná nejlepší dostupnosti poskytovaných služeb se v případě výpadku neobejde bez okamžitého zásahu technika informovaného o dané skutečnosti. K mojí práci patří kontrola funkčnosti síťových služeb provozovaných na serverech s operačními systémy Linux a BSD. Jednou z možností takové kontroly může být i manuální kontrola každé služby na všech serverech. Tato možnost je však velmi neefektivní. Automatická kontrola služeb prováděná počítačovým programem s vyhodnocováním jejich stavu výrazně tuto činnost zefektivní. Z tohoto důvodu jsem si vybral jako svoji bakalářskou práci vytvoření právě takového síťového dohlížeče.
9
10
2
Popis problému, specifikace cíle Síťový dohlížeč na služby by měl být schopen tyto služby automaticky
kontrolovat bez zásahů uživatele. Měl by vyhodnocovat stav služeb a provádět oznámení v případě výpadku některé z testovaných služeb, měl by být snadno konfigurovatelný, nenáročný na systémové prostředky. Služby by měl kontrolovat výhradně po síti bez nutnosti instalace podpůrných programů na testovaných systémech a umožňovat testování uživatelské služby pomocí uživatelem definovaného aplikačního protokolu. Podobné programy již existují, například Nagios, jehož internetová domovská adresa je http://www.nagios.org/. Nagios však neumožňuje testování služeb vlastním aplikačním protokolem, je velmi rozsáhlý, náročný a konfiguruje se přes webové rozhraní. Jak je takový počítač se síťovým dohlížečem zapojen v síti? Zapojení znázorňuje obrázek 2.1.
Obrázek 2.1: Zapojení v síti Síťový dohlížeč je nainstalován na serveru určeném k tomuto účelu a protokolem TCP/IP, UDP/IP testuje požadované služby. Je třeba zajistit, aby v případě výpadku
11
zařízení, ke kterému je dohlížeč fyzicky připojen (na obrázku směrovač/přepínač č. 1), nebyly všechny testované služby vyhodnoceny jako neaktivní. Při síťové komunikaci se stává, že některý z datagramů se ztratí. Takové případy musí být také řádně ošetřeny. Ztrátu datagramu při přenosu protokolem UDP musí řešit program, ztrátu datagramu protokolu TCP řeší operační systém nebo síťová karta (odešle ztracená nebo poškozená data znovu). U protokolu TCP hrozí přerušení navázaného spojení. A jaký je význam protokolů IP, TCP a UDP? IP (Internet Protocol) - pracuje na síťové vrstvě. Přenáší datové segmenty po síti na adresy v něm obsažené, nekontroluje však, zda data dorazila v pořádku. TCP (Transmission Control Protocol) - protokol pracuje nad protokolem IP, navazuje spojení a kontroluje, zda jsou došlá data v pořádku. Nejsou-li, vyžádá si opětovné zaslání poškozených dat. V současnosti je to nejpoužívanější protokol. UDP (User Datagram Protocol ) - protokol pracuje také nad protokolem IP, nenavazuje však spojení a nekontroluje, zda datagram k cíli vůbec došel. Je rychlý a méně náročný na hardware, proti těmto přednostem však stojí jedna velká nevýhoda, a tou je jeho nespolehlivost.
12
Přehled základních služeb využívajících protokol TCP/IP ukazuje tabulka 2.1. Port 20 21 23 22
25
80
110
143
443 990 989
Služba FTP (File Transfer Protocol) FTP
FTP určen pro přenos dat
(File Transfer Protocol) Telnet
terminálové relace (Telecomunication Network) SSH zabezpečený telnet, kopírování (Secure Shell) SMTP
souborů předávání e-mailových zpráv
(Simple Mail Transfer
mezi servery a odesílání e-mailů
Protocol) HTTP
od klienta na server
(Hyper Text Transfer
webové stránky
Protocol) POP3
stahování e-mailových zpráv ze
(Post Office Protocol) IMAP 4
serveru ke klientovi manipulace s e-maily přímo na
(Internet Message Access
serveru, bez nutnosti stahování
Protocol 4) HTTPS
přes POP3 zabezpečená verze protokolu
(HTTP Secure)
HTTP zabezpečená verze protokolu
FTPS
993
IMAPS
995
POP3S
5190
Užití přenos dat v aktivním režimu
FTP zabezpečená verze protokolu IMAP zabezpečená verze protokolu
ICQ
POP3 pro přenos dat (zpráv, souborů),
(I Seek You)
dnes velmi požívaný
Tabulka 2.1: Služby protokolu TCP/IP
13
Přehled základních služeb využívajících protokol UDP/IP ukazuje tabulka 2.2. Port 53 69
161
Služba DNS
Užití překlad jmen na IP adresy a naopak
(Domain Name Service) TFTP
a další informace ze jmenných zón přenos krátkých souborů, nemá
(Trivial FTP) SNMP
žádné zabezpečení
(Simple Network Management Protocol)
pro vzdálené nastavování síťových prvků
Tabulka 2.2: Služby protokolu UDP/IP Co jsou to porty u protokolů TCP a UDP? Port je 16 bitové číslo (0-65535), kterým se jednoznačně určuje, ke které službě se chceme připojit. Máme-li například server, který nabízí služby telnet (port 23) a poskytuje webové stránky (portu 80), musíme při komunikaci se serverem nějakým způsobem rozlišit, o kterou službu máme zájem. K tomu využijeme právě číslo portu, které požadovanou službu jednoznačně specifikuje. Číslo portu je informace nesoucí se v TCP/UDP datagramu. O přidělování a registrování portů k službám se stará organizace jménem IANA (http://www.iana.org/). Porty se dělí na tzv. standardní (Well Known Ports), ty IANA přiděluje i registruje a jsou vyčleněné pro procesy operačního systému. Druhou skupinou jsou tzv. registrované (Registered Ports). Tuto skupinu IANA nepřiděluje, ale registruje ji. Tyto porty jsou využívány běžnými programy. Třetí, poslední skupinou jsou tzv. dynamické (Dynamic/Private Ports). Ty jsou určeny pro volné použití, IANA nepřiděluje ani neregistruje jejich použití. Rozdělení portů zobrazuje tabulka 2.3.
14
Skupina Standardní
Rozsah 0 - 1023
(Well Known Ports) Registrované
1024 - 49151
(Registered Ports) Dynamické
49152 - 65535
(Dynamic/Private Ports)
Tabulka 2.3: Rozdělení portů Podrobnější popisy i s příklady protokolů IP, TCP/IP, UDP/IP, portů a IP komunikace lze najít na [1]. Dohlížeč by měl být program fungující v operačních systémech Linux a BSD, nenáročný na systémové prostředky, snadno konfigurovatelný, pracující s protokoly TCP/IP a UDP/IP a měl by zasílat informace o případných výpadcích některé z testovaných služeb. Jak probíhá testování služby (například POP3)? Dohlížeč se pokusí připojit protokolem TCP/IP na port 110 k testovanému vzdálenému serveru (pro lepší představu je to jako vytočit telefonem číslo hlasové schránky). Pokud se připojení podaří (úspěšně se dovoláme do hlasové schránky), server mě přivítá uvítacím hlášením (ve sluchátku se ozve „Dovolali jste se do hlasové schránky“). Uvítací hlášení je vhodné uchovat. Při dalším testu pak může dohlížeč uvítací hlášení porovnat s předchozím a případně rozpoznat, že došlo ke změně služby. Funkce detekce změny služby může být užitečná například pro kontrolu webových stránek. Přijetím uvítání je funkce ověřena a test se může ukončit. Navázané spojení se zpravidla ukončuje zasláním požadavku na ukončení spojení. U aplikačního protokolu POP3 se ukončení provádí zasláním zprávy QUIT, na kterou server odpoví a ukočí sám spojení.
15
Ukázka testu služby POP3: (připojení na server 62.24.64.51, port 110 příkazem telnet) $ telnet 62.24.64.51 110 Trying 62.24.64.51... (úspěšné připojení k 62.24.64.51) Connected to ms2.dkm.cz (62.24.64.51). Escape character is '^]'. (uvítací hlášení) +OK Hello there. (zaslání žádosti o ukončení spojení) QUIT (odpověď na ukončení spojení) +OK Better luck next time. (ukončení spojení ze strany serveru) Connection closed by foreign host.
16
3
Návrh řešení Síťový dohlížeč bude program, který bude provozován na operačních systémech
Linux a FreeBSD. Známe-li již všechny požadavky na aplikaci , musíme se rozhodnout, v jakém programovacím jazyku ji napíšeme. Je samozřejmě nezbytné přihlédnout ke všem požadavkům a také k vlastním znalostem a zkušenostem s programovacími jazyky. Po zvážení všech kladů a záporů jazyků Perl, Python a C jsem došel k závěru, že nejvhodnější bude programovací jazyk C. Jádrem programu bude nekonečná smyčka, která bude v intervalech podle nastavení spouštět vlákna. Vlastní kontrolu služby bude provádět právě vlákno. Jádro programu bude kontrolovat dobu běhu vlákna. Přesáhne-li doba běhu vlákna přednastavený časový limit, bude vlákno ukončeno. Nesmí být spuštěna kontrola pro jednu službu dvakrát, to musí jádro programu ošetřit. Každé vlákno přijme nastavení od jádra programu ve formě ukazatele na datovou strukturu, informace v ní obsažené budou: - IP adresa serveru, na kterém má být služba testována - port služby - protokol, jakým službu testovat - specifikace vlastního aplikačního protokolu - časové údaje o následujícím provedení testu - počet neúspěšných testů v řadě - interval testování (v sekundách), je-li služba funkční - interval testování, je-li služba nefunkční - emailové adresy, kam zasílat informace o změnách stavu služby - text, který vložit do předmětu emailové zprávy - text, který použít jako tělo emailové zprávy - přepínač (Ano/Ne) s informací, že služba je právě testována Vlákno po provedení testu rozhodne o stavu služby. Služba bude v jednom z těchto stavů: funkční, nefunkční, změněná. Právě kvůli detekci stavu změněná je nutno uchovávat data z komunikace předchozího testu služby. Data budou uchovávána jak v datové struktuře v paměti, tak na pevném disku v předem definovaném adresáři.
17
Datová struktura pro uložení komunikace bude obsahovat: - ukazatel na následující část komunikace - délku dat - zdroj dat (odeslaná data, přijatá data) - vlastní data Maximální délku uložených vlastních dat bude možné omezit v globálním nastavení. Omezení maximální délky je vhodné z důvodu ochrany dohlížeče a potažmo celého systému v případě, že útočník podstrčí velké množství dat na testovací server. Jak již bylo zmíněno některé parametry ovlivňující chování dohlížeče bude možné nastavit, parametry ovlivňující chování celého programu včetně všech služeb budeme nazývat globálními parametry. Parametry jsou programy zpravidla přejímány z příkazové řádky nebo z konfiguračního souboru. Parametry z příkazové řádky mají vyšší prioritu. Výpis všech globálních parametrů: - daemonize, určuje, zda program má být spuštěn na pozadí - user, po spuštění nastavit práva programu na tohoto uživatele - init, po startu programu nenačítat komunikaci z pevného disku - threads, maximální počet současně bežících vláken - syslog, v jaké úrovni logovat do logovacího démona syslog (local6.info, …) - store dir, jaký adresář používat k ukládání komunikace z testování - use store, ukládat komunikaci v store dir - pid file, kam uložit číslo procesu programu - config file, odkud číst konfigurační soubor (má význam pouze jako parametr příkazové řádky) - verbose, vypisovat více informací z testování na obrazovku (vhodné pro ladění konfigurace) Nastavení potřebné pro testování služeb bude uloženo v konfiguračním programu. Každá služba bude obsahovat povinné údaje (P) a volitelné (V). Nebude-li zadána hodnota volitelného údaje, bude použita přednastavená hodnota. Některé údaje se stanou povinnými v závislosti na jiných udajích, označme je podmínečně povinné. (PP)
18
Například při testování vlastním aplikačním protokolem UDPL7
(User Defined
Protocol Layer 7) se povinným údajem stane popis vlastního aplikačního protokolu. Výpis povinných, volitelných a podmíněně povinných údajů zobrazuje tabulka 3.1.
Údaj
P/V/PP
Přednastavená
Stručný popis
hodnota
host
P
-
IP adresa nebo hostname serveru
port
V/P
dle protokolu
protokol
P
-
script
PP
-
popis vlastního aplikačního protokolu
separator
V
&
oddělovač použitý při definici UDPL7 (script)
data
V
dle protokolu
check_int
V
120
interval testování služby, je-li služba funkční
fail_int
V
240
interval testování nefunkční služby
fail_count
V
5
číslo portu, u vlastního aplikačního protokolu je to údaj povinný aplikační protokol pro testování (FTP, SMTP, POP3, ...)
textová data, oddělená středníkem, mají mnoho významů, blíže tabulka 3.2.
po kolika neúspěšných testech je služba vyhodnocena jako nefunkční emailové adresy, na které zasílat informace o
email
V
-
změně
stavu
služby,
není-li
vyplněno,
informace se nezasílá e_subj e_text
V V
NSC INFO %host:%port%stat
řetězec pro subject emailu tělo emailové zprávy, %host je nahrazeno hodnotou host, %port hodnotou port a %stat stavem viz popis v uživatelské příručce
Tabulka 3.1: Výpis údajů Informační emaily budou zasílány přes lokální poštovní službu Sendmail. Programu bude také možno zaslat systémový signál SIG HUP a SIG TERM. Při obdržení signálu SIG HUP si program znovu načte konfiguraci testovaných služeb, při signálu SIG TERM se program regulérně ukončí. Obě události dohlížeč zapíše pomocí systémového logování.
19
Vlastnost, kterou programy podobného typu (například v odstavci 2 zmíněný Nagios) nemají, je možnost testovat službu vlastním aplikačním protokolem, dále budeme označovat UDPL7. Způsob definice UDPL7 (v konfiguračním souboru hodnota údaje script) bude objasněna popisem následujícího příkladu (test služby POP3 nadefinováním vlastního aplikačního protokolu UDPL7 i s přihlášením uživatele k poštovní schránce):
USER %data &PASS %data &QUIT & určuje odeslání dat k serveru a to dat USER %data, kde řetězec %data bude nahrazen hodnotou z konfiguračního údaje data, viz tabulka 3.1 a 3.2. Následuje oddělovač a čtení dat ze serveru, oddělovač a poslání dat (PASS %data) serveru, kde %data bude nahrazeno druhým textovým řetězcem z hodnoty údaje data. Následuje oddělovač, čtení dat ze serveru, zaslání dat QUIT serveru, přečtení odpovědi a ukončení spojení, pokud server neukončil sám. Význam údaje data zobrazuje tabulka 3.2. Protokol
Význam
POP3
nemá význam
IMAP
nemá význam
SMTP
hodnota za HELO %data, není-li hodnota %data nastavena bude použita defaultní hodnota domain.com. Více viz literatura [2]
HTTP
žádost o konkrétní stránku HOST: %data, není-li uvedena, bude použita hodnota domain.com. Více viz literatura [2]
FTP
nemá význam
NNTP
nemá význam
DNS
provádí překlad typu A hodnoty data, více viz literatura [2]
UDPL7
postupně nahrazuje řetězce %data v hodnotě údaje script hodnotami údaje data (oddělené středníkem) Tabulka 3.2: Význam údaje data
20
Ukázka konfiguračního souboru (globální nastavení + test 3 služeb): # konfiguracni soubor pro service checker user
tester
# nastavení práv programu na tohoto uživatele
syslog
local7.info # facility a priority, úroveň logování
storedir
/var/db/nsc/
# cesta k adresáři, kam ukládat data # služeb(odeslaná a přijatá data)
pid
/var/db/nsc/nsc.pid
# cesta k souboru, do kterého # uložit pid procesu
threads
32
# maximální počet současně spuštěných vláken
<service>
# začátek nastavení testované služby (test FTP)
host
ftp.dkm.cz
# hostname nebo ip adresa serveru
protocol
FTP
email
[email protected] # email. adresy
# typ testované služby (aplikač. protokol)
# konec testování 1. služby
<service>
# začátek nastavení 2. služby (test DNS)
#
host
62.24.64.2
# hostname nebo ip adresa serveru
protocol
DNS
# test DNS
port
110
# port na serveru, není nutné, port DNS # se určí z definice protokolu
check_int
40
# testovací interval v sekundách # při stavu služby funkční
fail_int
120
# testovací interval v sekundách # při stavu služby nefunkční
fail_count
5
# po 5 nepodařených testech bude služba # označena jako nefunkční
email
[email protected], [email protected]
email_subj
"DNS: %stat"
# předmět emailu
email_text
%host:%port-%stat
# tělo emailu
data
www.dkm.cz
# přelož na A záznam
# konec 2. služby
<service>
# začátek nastavení 3. služby (test UDPL7)
host
62.24.64.39 # hostname nebo ip adresa serveru
port
20203
# port služby na serveru, u UDPL7 povinný
protocol
UDPL7
# User Defined Protocol Layer 7
separator
+
# oddělovač použitý v definici UDPL7
21
script
"akce get & data status +quit +
check_int
10
# testovat každých 10 sekund
fail_int
300
# pokud chyba služby => testovat 300 s
fail_count
25
# pokud chyba služby 25x, označ službu # nefunkční
email
[email protected], [email protected]
email_subj
"%host-$stat"
email_text
"Server %host, port %port, status: %stat"
# subject emailu # text emailu
# konec 3. služby
Program bude chybová a provozní logování
syslog
a
bude
umožňovat
hlášení logovat pomocí systémového
nastavení
local6.info,...).
22
úrovně
logování
(local7.err,
4
Vypracování Program je napsán v jazyce C, jmenuje se NSC – Newman Service Checker a je
šířen zdarma pod GNU GPL licencí (http://gnu.cz/). Program je pro přehlednost rozdělen do několika zdrojových souborů a to: nsc.c, nsc.h, nsc_err.c, check.c, check.h, processconf.c, processconf.h, processconf_err.c. nsc.c: obsahuje vlastní tělo programu, zpracování argumentů, řízení spouštění vláken, ošetření signálů HUP a TERM, provedení démonizace (spuštění procesu na pozadí), změna práv procesu na požadovaného uživatele, zajištění logování, zpracování datových struktur z konfigurace připravené funkcí process_conf (viz níže), funkce na odesílání oznámení o změně stavu služby nsc.h: deklarace datových struktur, tabulek pro kódování/dekódování názvů protokolů, nastavení v konfiguračním souboru, tabulka scriptů pro kontrolu nejběžnějších protokolů (FTP, SMTP, HTTP, POP3, IMAP, DNS, NNTP), nastavení vlastností programu a nastavení přednastavených hodnot: #define DEFAULT_CONFIG "./prg.conf" #define DEFAULT_STORE "/var/db/nsc/" #define DEFAULT_PID "/var/db/nsc/nsc.pid" #define MAX_THREAD_TIME 600 #define MAX_FILE_PATH 1024 #define MAIL_SENDMAIL_PATH "/usr/sbin/sendmail" #define MAIL_FROM_ADDR "[email protected]" #define MAIL_FROM_NAME "NSC" #define MAIL_MAX_LEN 2048
// recomended 2xMAX_CF_ROW from // processconf.h
#define CHECK_INT_TIME 120
// default interval
#define FAIL_INT_TIME 60
// default fail interval
nsc_err.c: funkce, která podle čísla kódu chyby (argument funkce) vrátí ukazatel na textový popis chyby
23
check.c: obsahuje kód vlákna, které provádí test služeb, načtení/uložení komunikace s testovanou službou, ping test pro ověření dostupnosti sítě. Funkce, která je volána jako vlákno se jmenuje check_thread a její deklarace je void *check_thread(void *params), jako parametr přijímá ukazatel na datovou strukturu str_serch: struct str_serch{ struct str_serch *next;
// pointer to the next
struct in_addr host;
// ip addr
unsigned int port;
// service port
unsigned short int proto;
// protokol of service, 1-100 tcp, // 101-200 udp
char *script;
// communication sequence (UDPL7)
char sep;
// separator
time_t check_time;
// timestamp of the next check
time_t thread_start;
// start time of the thread
unsigned int error_count;
// count of unsuccessfull checks
unsigned int check_int;
// check interval in seconds, 0 = // checking of the service is disabled
unsigned int fail_int;
// check every fail_int seconds, if // service is off
unsigned int fail_count;
// if service is off fail_count,
// send info by email char *emails;
// emails addresses, separated by ','
char *message_subj;
// notification text of subj
char *message_body;
// notification text of email body
char *data;
// variable data
struct str_service *service; // ^service communication str unsigned short int active;
// thread is active
pthread_t thread_id;
// thread id
pthread_attr_t attr;
// attributes of thread
unsigned short int init;
// init service => don't or do read // comunication from file
};
Vlákno nevrací žádnou návratovou hodnotu, je vytvořeno jako odloučené. Takové vlákno je automaticky odklizeno systémem a jsou uvolněny všechny jeho zdroje, jakmile vlákno ukončí svou činnost.
24
check.h: nastavení vlákna, které provádí test služeb: #define MAX_SEND_LEN 1024
// send UDP buffer, recommended 1024
#define MAX_RES_LEN 2048
// max response length in bytes to store, // recommended 1024 - 102400
#define RS_TIMEOUT 4
// receive send timeout in seconds, // depends on connection
#define RS_COUNT 2
// count times wait RS_TIMEOUT
#define CONNECT_TIMEOUT 20
// connect timeout in seconds
#define RS_TIMEOUT_UDP 20
// udp timeout
#define MAX_SCRIPT_LEN 1024
// max script length // recommended 1024 - 10240
processconf.c: program pro zpracování konfguračního souboru používá funkci process_conf, jejíž realizace byla předmětem mého semestrálního projektu. Několika větami představím funkci
process_conf.
Funkce pracuje s konfiguračním souborem,
ze kterého si načítá syntaxi pro zpracovávaný soubor. Jde o takový konfigurační soubor konfiguračního (říkejme mu zpracovávaného) souboru. Konfigurační soubor připravují tvůrci programů, zpracovávaný soubor editují uživatelé (pro uživatele je konfiguračním souborem zpracovávaný soubor). Funkce připraví data ze zpracovávaného souboru do datových struktur a ověří jejich správnost. Po zavolání funkce nejdříve zkontroluje konfigurační soubor. Je-li bez chyby, naalokuje první datovou strukturu a postupným zpracováváním zpracovávaného souboru alokuje další datové struktury a plní je daty. Vyskytne-li se chyba ve zpracovávaném souboru, odalokuje veškerou naalokovnou paměť, vypíše na obrazovku informaci o chybě a číslo chyby vrátí jako svoji návratovou hodnotu. Vstupní parametry funkce: char * cc_name
- ukazatel na název konfiguračního souboru
char * c_name
- ukazatel na název zpracovávaného souboru
struct __cc_str **cc_start_d - ukazatel na ukazatel na datovou strukturu,tam funkce uloží ukazatel na první datovou strukturu
25
short int pr
- přepínač, zda strukturovaně vypsat na stdout zpracovaná data z naplněné datové struktury, vhodné pro ladění
Datová struktura stromu záznamů: struct __cc_str{ unsigned int
cc_line; // line number
unsigned short int
cc_layer; // layer
unsigned short int
cc_type; // type of record; 0 - not defined, // 1 - start of block, 2 - end of // block, >= 10 - standard record – see // records table
struct __cc_str
*cc_next;
// pointer to the next record on the
// same layer struct __cc_str
*cc_sub_next;
// pointer to sub block of //records
char
cc_str[MAX_RECORD_NAME+1];
struct __ccval_str *cc_data;
// record name // pointer to struct of data
};
Podrobnější popis včetně zdrojových kódů funkce process_conf jsou na přiloženém CD, viz přílohy. processconf.h: nastavení funkce zpracovávající konfigurační soubor: #define MAX_RECORD_NAME 20
// max length in chars of record name //
(ex. "host_ip ip" - host_ip
// is record name, ip is value) #define MAX_CF_ROW 1024
// max row length in chars // of the config file
processconf_err.h: chybová hlášení funkce process_conf
26
Program provádí, je-li nastaveno, test dostupnosti sítě pomocí ping testu (protokol ICMP). Není-li síť dostupná, test služby je přeskočen bez vyhodnocení změny stavu služby. Provádění ping testu je však možné pouze s právy uživatele root. Více informací o datagramech typu ping a protokolu ICMP lze nalézt na [3]. Události jsou zapisovány pomocí systémového logování syslog a jsou to: - provedena inicializace nové služby - služba změnila svůj stav (funkční, nefunkční, změněná) - test služby byl přeskočen z důvodu chyby připojení zjištěné ping testem - přijat signál HUP nebo TERM - chybová hlášení programu Ladící informace jsou vypisovány na obrazovku. Jejich bližší popis naleznete v odstavci testování. Informace pro překladač jsou uloženy v souboru Makefile. O souboru Makefile a příkazu make naleznete informace na manuálových stránkách viz [4]. Výpis souboru Makefile: CFLAGS = -Wall COMPILER = gcc PROG = nsc CFLAGS+=-pthread all: $(PROG) nsc: processconf.o nsc.o check.o ${COMPILER} ${CFLAGS} processconf.o processconf_err.o nsc.o nsc_err.o check.o -o $(PROG) nsc.o: nsc.c nsc.h nsc_err.c ${COMPILER} ${CFLAGS} nsc.c nsc_err.c -c processconf.o: processconf.c processconf.h processconf_err.c ${COMPILER} ${CFLAGS} processconf.c processconf_err.c -c check.o: check.c check.h nsc.h nsc.c ${COMPILER} ${CFLAGS} check.c -c clean: rm -rf *.o *.gch ${PROG}
27
Programem přijímané přepínače a argumenty zobrazuje tabulka 4.1. Přepínače/Arg.
Význam
-d
program se spustí na pozadí
-h
vypíše stručný popis přijímaných argumentů
-i -p -c soubor -s cesta -t -u uživatel -v
komunikace s testovanou službou nebude načítána z disku, ale služba bude znovu zinicializována bude na obrazovku vypisovat ladící informace, deaktivuje parametr -d cesta ke konfiguračnímu souboru cesta k adresáři, kam ukládat komunikaci s testovanými službami nepoužívat uložiště komunikace testovaných služeb, deaktivuje parametr -s po startu progam změní práva na uživatele vypíše verzi programu Tabulka 4.1: Význam přepínačů a argumentů
28
7
Testování Testování každého softwaru je velmi důležité. Testování pomůže odhalit chyby
jak procesní, tak chyby v kódu programu. Po každé opravě chyby je třeba testování provést znovu. Program musí být odolný také proti chybně zadaným údajům ze strany uživatele programu. V takovém případě by program měl vypsat uživateli chybové hlášení. K testování také patří ověření náročnosti na systémové prostředky. Testování síťového dohlížeče můžeme rozdělit do tří skupin: A: testování programu při čtení konfiguračního souboru a zpracování parametrů B: testování programu při kontrole služeb C: testování náročnosti na systémové prostředky a kontrola logování Testování A: Program byl spuštěn s chybnými přepínači a argumenty, výpis programu je uveden kurzívou. - neplatný přepínač -y ./nsc: invalid option -- y - neexistující uživatel -u nonexists nonexists: no such user - neplatná cesta ke konfiguračnímu souboru ./nsc -c /tmp/nonexists /tmp/nonexists: No such file or directory Program byl spuštěn s těmito správnými přepínači a argumenty: - spusť se na pozadí -d program se spustil na pozadí - použij konfigurační soubor -c ./prg.conf program načetl konfigurační soubor - vypiš verzi programu -v Newman Service Checker, version: 0.1.5.0, [email protected] - nepoužívej úložiště komunikace -t a pro uložiště použij adresář -s /tmp program se spustil a správně deaktivoval přepínač -s - změň svá práva na uživatele -u test program se spustil a změnil svá práva na uživatele test
29
- vypiš stručný popis -h usage: nsc [-dhiptv] [-c configuration file] [-s store dir] [-u user] -d
- daemonize
-h
- print this help
-i
- initialize services
-p
- be verbose, print some information to stdout (see documentation)
-c configuration file - path to configuration file, default is ./prg.conf -s store dir
- path to directrory where store data, default is /var/db/nsc/
-t
- don't use store, flag -s has no effect
-u
- suid to user
-v
- print version
Program byl spuštěn s chybami v konfiguračním souboru jak v globálním nastavení, tak v nastavení testování jednotlivých služeb. Následuje vždy chybný řádek konfiguračního souboru, kurzívou na dalším řádku je výpis hlášení programu: test_host a62.24.64.1 ./prg.conf at line 4: unknown hostname ERROR NUMBER: 50 test
ii yes or no expected on line 5 ./prg.conf at line 5: unknown boolean value(posibilities – yes, no, on, off, 1, 0) ERROR NUMBER: 65
syslog
nonexists.info
./prg.conf at line 8: unknown syslog value, syslog.h(mail.info,daemon.*,...) ERROR NUMBER: 55 threads x32
# max count of threads
./prg.conf at line 11: a number expected ERROR NUMBER: 34
30
<serviceX> ./prg.conf at line 13: unknown block name ERROR NUMBER: 32 email ls@@dkm.cz ./prg.conf at line 24: bad format of email address([email protected]) ERROR NUMBER: 40 port 333321 # port na serveru ./prg.conf at line 15: bad port (port range is 1-65535) protocol
FTPX
./prg.conf at line 16: unknown protocol script
"GR220-*\r*si vytvorte*\n*\n220*\r\n&>QUIT\r\n &
./prg.conf at line 19: unknown script definition, see documentation for details
Dalším z provedených testů byl test s výpisem ladících informací a kontrola obsahu souborů s uloženou komunikací s testovanými službami. Program byl spuštěn s přepínači -c prg.conf -p -i. Soubory z testu jsou na přiloženém CD v adresáři /test/A/. Výpis ladících informací je v souboru ladici_informace.txt. Soubory s komunikací jsou uloženy v podadresáři ulozena_komunikace. Test A proběhl naprosto v pořádku. Testování B: Při testování služeb jsem vyzkoušel tyto protokoly: FTP, SMTP, POP3, IMAP, NNTP, HTTP, DNS a UDPL7 s těmito scripty: "QUIT\r\n &HELO %data\r\n& HELP\r\n & RSET\r\n & QUIT\r\n &
Všechny testy proběhly naprosto v pořádku a program správně určoval stavy služeb, informační zprávy také přicházely naprosto přesně podle změn stavu služeb. Jako kontaktní e-mailové adresy jsem použil běžný e-mailový účet a e-mailový účet u mobilního operátora s nastaveným přeposíláním zpráv na mobilní telefon. Soubory
31
z testu jsou uloženy na přiloženém CD v adresáři /test/B/. Testování proběhlo jak na simulovaných výpadcích, tak na reálných výpadcích během více než měsíčního zkoušení. Test B proběhl naprosto v pořádku. Testování C: Přeložený program pod operačním systémem Mandriva Linux release 2007.1 (Official) for x86_64 překladačem gcc (GCC) 4.1.2 20070302 (4.1.2-1mdv2007.1) má délku 73782 bytů. Paměťová náročnost v nejvyšší míře závisí na množství testovaných služeb a velikosti požadovaných dat určených k porovnávání stavu služeb (nastavení ve zdrojovém souboru check.h, položka MAX_RES_LEN). Program běží k dnešnímu dni více než 40 dní naprosto stabilně. Na procesoru Intel(R) Pentium(R) D CPU 3.00GHz spotřeboval 25 sekund strojového času. Spotřebovává konstantní množství systémových prostředků v závislosti na množství testovaných služeb. Soubory s datem a výpisem příkazu ps jsou uloženy v adresáři /test/C/. Soubor s logy programu log.txt je také uložen v adresáři testu C. Test C proběhl naprosto v pořádku. Program byl testován na těchto operačních systémech: Mandriva Linux release 2007.1 (Official) for x86_64, překladač gcc (GCC) 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1) OpenBSD 3.6 i386, překladač gcc version 2.95.3 20010125 (prerelease, propolice) FreeBSD 4.11-RELEASE-p13 i386, překladač gcc version 2.95.4 20020320 [FreeBSD]
32
6
Závěr Program síťový dohlížeč na služby, který byl předmětem této bakalářské práce,
jsem vytvořil podle požadavku zadání. Nazval jsem jej NSC – Newman Service Checker. Více než měsíční testování a používání programu ukázalo výhody automatické nepřetržité kontroly testovaných služeb. Dalo však také podnět k vylepšení programu, a to umožnit testování dostupnosti připojení pro každou testovanou službu odděleně. Vlastnost, kterou programy stejného typu nemají, je možnost definování vlastního aplikačního protokolu nad protokolem TCP/IP. Díky této vlastnosti a nenáročnosti na systémové prostředky má NSC velmi široké uplatnění pro systémové administrátory v oblasti
internetu. Této vlastnosti využíváme při dohlížení na funkčnost služeb
pracujících s námi navrženými aplikačními protokoly, viz 5. kapitola Testování, test B. Práce na programu do budoucna by se měla týkat již zmíněného vylepšení odděleného testování dostupnosti připojení pro každou službu. Program by mohl být dále rozšířen o generování statistik dostupnosti služeb včetně historie. Změny stavů služeb by byly zapisovány do databáze. Ze záznamů v databázi by byly generovány statistiky buď ve formátu prostého textu nebo přímo webové stránky v HTML kódu včetně grafů s historií dostupnosti služeb. Další vhodná rozšíření programu vzejdou až z delšího praktického používání.
33
34
7
Seznam literatury a zdrojů
[1] Libor Dostálek, Alena Kabelová. Velký průvodce protokoly TCP/IP a systémem DNS. Computer Press, 2. aktualizované vydání, 2000. ISBN 80-7226-323-4. [2] Dokumentace k RFC 821, 2616, 1035, 1039, 3501, 959. http://www.faqs.org/rfcs/. [3] Článek o programování socketů. Sokety a C/C++: program ping. http://www.root.cz/clanky/sokety-a-c-program-ping/. [4] Make - online manuál. http://www.gnu.org/software/make/manual/make.html. [5] Brian W. Kernighan, Dennis M. Ritchie. Programovací jazyk C. Computer Press, a.s., první vydání, 2006. ISBN 80-251-0897-X.
35
36
A
Uživatelská příručka Program NSC slouží k testování síťových služeb na protokolech TCP/IP a
UDP/IP. Program testuje nejpoužívanější protkoly služeb – FTP, HTTP, SMTP, POP3, IMAP, NNTP, DNS. Umožňuje definování vlastního aplikačního (UDPL7) protokolu nad protokolem TCP/IP. Přepínače a argumenty příkazové řádky: Přepínače/Arg.
Význam
-d
program se spustí na pozadí
-h
vypíše stručný popis přijímaných argumentů
-i -p -c soubor -s cesta -t -u uživatel -v
komunikace s testovanou službou nebude načítána z disku, ale služba bude znovu zinicializována bude na obrazovku vypisovat ladící informace, deaktivuje přepínač -d cesta ke konfiguračnímu souboru cesta k adresáři, kam ukládat komunikaci s testovanými službami nepoužívat uložiště komunikace testovaných služeb, deaktivuje parametr -s po startu progam změní práva na uživatele vypíše verzi programu Tabulka A.1: Přepínače a argumenty příkazové řádky
Podrobnější popis vybraných přepínačů: -i
- komunikace s každou testovanou službou je uložena na pevném disku,
při startu programu je tato komunikace načtena do paměti a slouží k porovnávání změn testované služby, přepínač -i říká programu, aby komunikaci znovu inicializoval, data na disku pak budou přepsána daty z nové inicializace služby -p
- program vypíše na obrazovku ladící informace, těmi jsou načtený
konfigurační soubor a výpisy dat během testování služby, viz níže popis ladících informací. Význam přepínače -d použitého současně s přepínačem -p bude deaktivován
37
-c
- umožňuje specifikovat cestu ke konfiguračnímu souboru, přednastavená
hodnota je /etc/nsc.conf -s
- cesta k adresáři, který má program použít pro ukládání komunikace,
přednastavená hodnota je /var/db/nsc -u
- program po startu změní svá práva na jiného uživatele, při používání
ukládání komunikace (parametr -s nastavuje cestu k uložišti) jsou potřebná práva zápisu do uložiště Popis konfiguračního souboru: Konfigurační soubor lze rozdělit na dvě části: globální nastavení a nastavení jednotlivých služeb. Hodnoty přepínačů z příkazové řádky mají výšší prioritu, než nastavení v konfiguračním souboru. Význam globálního nastavení ukazuje tabulka A.2. Nastavení
Význam
test_host
IP adresa nebo hostname zařízení, použito při testování dostupnosti připojení ping testem
test
provádet test? hodnoty – yes/no, on/off, 1/0 (default: NO)
user
změna práv programu na usera (default: nenastaveno)
syslog
facility a priority pro systémové logování (default: daemon.info)
storedir
viz přepínače příkazové řádky, přepínač -s
pid
cesta k souboru, kam uložit pid procesu (default: /var/db/nsc/nsc.pid)
threads
maximální počet současně bežících vláken (default: 0, bez limitu) Tabulka A.2: Globální nastavení
Každá testovaná služba má svoje nastavení, které je vloženo mezi řádky „<service>“ a „“. Význam nastavení služeb ukazuje tabulka A.3.
38
Nastavení
Význam
host
IP adresa nebo hostname
port
port (default: dle protokolu)
protokol
jakým protokolem službu testovat, známé protokoly jsou FTP, HTTP, SMTP, POP3, IMAP, NNTP, DNS, definovatelný protokol UDPL7, popis definování protokolu viz definice UDPL7.
script
definice UDPL7
separator
oddělovač použitý v definici UDPL7
check_int
interval testování služby v sekundách (default: 120s)
fail_int
interval testování nefunkční služby v sekundách (default: 60s)
fail_count
po kolika chybných testech v řadě je služba označena za nefunkční (default: 5)
email
e-mailové adresy oddělené čárkou, na které posílat oznámení o změně stavu služby (default: žádná adresa, oznámení se neposílá)
email_subj předmět oznamovacícho e-mailu (default: „NSC INFO!“) email_text tělo oznamovacího e-mailu (default: %host:%port-%stat) Tabulka A.3: Nastavení služeb V nastavení hodnot email_subj a email_text lze použít proměnné %host, %port a %stat, kde při odesílání e-mailu bude proměnná %host nahrazena IP adresou, proměnná %port portem a proměnná %stat stavem testované služby. Popis ladících informací: Parametr -p říká programu, aby na obrazovku vypsal ladící informace. Ukázka konfiguračního souboru: test_host
62.24.64.1
test
1
syslog
local7.info
storedir
/var/db/nsc/
pid
/var/db/nsc/nsc.pid
threads
32
<service> host
ftp.dkm.cz
39
port
21
protocol
FTP
email
[email protected]
email_subj
"NSC INFO!"
email_text
"Info ze serveru %host, sluzba port %port,
status: %stat" <service> host
62.24.64.33
protocol
UDPL7
port
20202
separator
&
script
">GETSTATUS\n& \n &
check_int
300
fail_int
600
fail_count
10
email
[email protected]
email_subj
"NSC INFO!"
email_text
"Info ze serveru %host:%port - %stat"
S parametrem -p program vypíše nejdříve data z konfiguračního souboru (to zařizuje funkce process_conf). Formát výpisu je následovný: úroveň vnoření | proměnná | kód proměnné - vlastní hodnota proměnné úroveň vnoření – každý začátek nového bloku <service> zvýšuje úroveň, každý konec bloku snižuje úroveň o 1 proměnná – název proměnné, která nabývá hodnot definované uživatelem kód proměnné – kód viz soubor processconf.h vlastní hodnota proměnné – přímo hodnota zadaná uživatelem v konfiguračním souboru
40
Ukázka výpisu: layer| variable
type_code(see processconf.h) - value(could be multiple - see * options)
----------------------------------------------------------0| test_host
15
- 62.24.64.1 0| test 17 - 1 0| syslog
16
- local7.info 0| storedir
12
- /var/db/nsc/ 0| pid
12 - /var/db/nsc/nsc.pid
0| threads
11
- 32 0| <service> 1|
host
15 - ftp.dkm.cz
1|
port
11 - 21
1|
protocol
12 - FTP
1|
email
141 - [email protected]
1|
email_subj
12
- NSC INFO! 1|
email_text
12
- Info ze serveru %host, sluzba port %port, status: %stat 0| 0| <service> 1|
host
15 - 62.24.64.33
1|
protocol
12 - UDPL7
1|
port
11 - 20202
1|
separator
18
- & 1|
script
12
41
- >GETSTATUS\n& \n &
check_int
11
- 300 1|
fail_int
11 - 600
1|
fail_count
11
- 10 1|
email
141 - [email protected]
1|
email_subj
12
- NSC INFO! 1|
email_text
12
- Info ze serveru %host:%port - %stat 0|
Následuje výpis z testování, kde je informace přímo vypsaná vláknem, které provádí test, vypisuje obsah datagramů jak odeslaných tak přijatých, v závorce je uvedena délka dat, následuje dvojtečka a za ní informace o jaká data se jedná – přijatá (R), odeslaná (S), konec testu služby (E). Ukázka výpisu: THREAD MESSAGE: 62.24.64.13:21 - 1187613170 - 0 THREAD MESSAGE: 62.24.64.33:20202 - 1187613170 - 0 ----------BEGIN OF SERVICES---------62.24.64.13:21 SERVICE(907): R-220fffffffffff
ttttttttttt
pppppppp
fffffffffff
ttttttttttt
pppppppppp
ff
tt
pp
ppp
ff
tt
pp
pp
ff
tt
pp
ppp
ffffff
tt
pppppppppp
ffffff
tt
pppppppp
ff
tt
pp
ff
tt
pp
ff
tt
pp
ff
tt
pp
Vitejte na anonymnim serveru ftp.dkm.cz.
42
Pri uploadu si vytvorte prosim adresar, kam nahrajte uploadovana data. K nahranym datum prihrajte prosim textovy popis (popis.txt), kde uvedte, o jaka data se jedna a jejich zarazeni do stromove struktury v adresari /pub. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! NENAHRAVEJTE SEM ZADNY CRACKY, MP3, FILMY A SAMOZREJME SOFTWARE, JEHOZ LICENCNI PODMINKY TO NEDOVOLUJI!!!!!!!!!!!!!!!!!!!!!!!!!!! 220 FTP MRAZIK2 SERVICE(6): S-QUIT SERVICE(14): R-221 Goodbye. SERVICE(0): E ----------END OF SERVICES-----------62.24.64.13:21 ----------BEGIN OF SERVICES---------62.24.64.33:20202 SERVICE(10): S-GETSTATUS SERVICE(23): R-Password: "GETSTATUS" SERVICE(1): SSERVICE(22): R-String: "" STATUS OK SERVICE(0): E ----------END OF SERVICES-----------62.24.64.33:20202
43
44
B
Obsah přiloženého CD
Obrázek B.1: Seznam přiloženého CD
45
Popis adresářů a souborů na přiloženém CD: adresář docs obsahuje tento dokument ve formátu odt a pdf adresář exe obsahuje přeložený program NSC pro operační systém Linux verze amd64 adresář src obsahuje zdrojové soubory programu včetně návodu pro instalaci (soubor README.txt) a souboru s licencí (soubor licence.txt) adresář test obsahuje 3 podadresáře A, B a C, ve kterých jsou uloženy všechny soubory z testování programu rozdělené podle 3 prováděných testů
46
