Monitorizarea echipamentelor de telecomunica ții [604989]
Monitorizarea echipamentelor de telecomunica ții
2Capitolul 1. Introducere
1.1. Contextul aplica ției
În prezenta lucrare se va tarata problema monitoriz ării echipamentelor de
telecomunica ții și a prezent ării informa ției care poate ajuta în luarea deciziilor,
depistarea problemelor sau chiar realizarea de pl ăților cu ajutorul acestui instrument.
Monitorizarea acestor echipamente se poate face printr-o re țea local ă sau ele o parte din
ele se pot afla conectate direct la internet, dar informa ția poate fi pus ă la dispozi ția
utilizatorului folosind mediul internet.
Evolu ția rapid ă a tehnicii de calcul a permis marii majorit ăți a oamenilor o
accesibilitate tot mai mare la calculator. Internet-ul este modalitatea prin care oamenii
aflați oriunde pe glob pot comunica și schimba informa ții cu mult ă ușurin ță. Datorit ă
creșterii exponen țiale pe care o au serviciile și num ărul utilizatorilor serviciului internet
apare necesitatea ca o diversitate de servicii și procese s ă poat ă fi comandate și
monitorizate prin intermediul acestuia.
Internet-ul a început cu scopul precis de a servi în cercetare, și înc ă de la
începuturi, dac ă exista o problem ă referitoare la calculatoare pe Internet, sigur se g ăsea
solu ția. De atunci îns ă Internet-ul a evoluat și pentru c ă modalit ățile de a distribui și de a
obține informa ții de pe Internet au crescut. U șurin ța cu care se poate distribui informa ții,
dar mai ales u șurin ța cu care orice utilizator, fie el și novice în ale informaticii, poate
avea acces la respectivele informa ții, a f ăcut din Internet un mediu preferat de foarte
mul ți oameni. Preferin ța acestora a f ăcut ca acesta s ă se dezvolte foarte repede și au
obligat cercet ătorii și firmele s ă gândeasc ă și să implementeze diferite servicii care în
anii de început nici m ăcar nu puteau fi imaginate, începând cu informa ția de tip
multimedia ce este inclus ă în paginile web și pân ă la sisteme avansate de pl ății
electronice, continuând mai recent cu transmiterea de voce prin internet (Voice over IP)
și deci interesul multor companii de telecomunica ții s-a îndreptat spre acest mediu de
transmitere a vocii pentru c ă ofer ă un raport calitate-pre ț convenabil.
1.2. Conturarea domeniului
Acest ă nou ă oportunitate oferit ă de mediul internet a dus la orientarea multor
companii de telecomunica ții spre acest tip de transmitere a informa ției vocale, și cum
era de a șteptat au început s ă apar ă pe pia ță și furnizori de solu ții hardware care s ă
Monitorizarea echipamentelor de telecomunica ții
3îmbun ătățeasc ă și să umple golul existent în cazul tehnologiilor nou ap ărute. Mul ți
dintre furnizorii de solu ții pentru acest ă nou ă tehnologie s-au axat în principal pe
implementarea hardware a unor produse ce realizeaz ă comunica ția și implementeaz ă
diferite tehnologii.
Pentru c ă, în general, operatorii de telecomunica ții mobile nu doresc s ă ofere o
interconectare cu operatorii mai mici de telecomunica ții, mai multe firme au gândit și
implementat echipamente prin care s ă se poat ă realize partea de terminarea a unei
convorbirii. Aceste echipamente sunt denumite în mod generic GSM Gateway-uri și
suport ă în general dou ă standarde GSM, cel de 900 MHz și cel de 1800MHz. Din
firmele care acoper ă acest segment de pia ță s-au avut la dispozi ție echipamente produse
de firmele Mobiline (Ungaria), Teles și WTL (Belgia). Deoarece echipamentele
furnizate de firma Mobiline au o arie mai mare de r ăspândire în cadrul re țelei de
telecomunica ții avute la dispozi ție și datorit ă faptului c ă acestea nu au instrumente
software care s ă ajute la monitorizarea lor s-a încercat g ăsirea unei solu ții care s ă
elimine acest inconvenient.
1.3 Tema propriu-zis ă a aplica ției
S-a încercat g ăsirea unei solu ții practice, și implementarea ei pentru a putea
monitoriza echipamentele produse de c ătre firma Mobiline deoarece acestea au un
procent de aproximativ 75% din echipamentele re țelei de telecomunica ții avute la
disopozi ție care pot fi încadrate în aceast ă categorie. Pentru c ă informa țiile care se vor
prelucra sunt în general confiden țiale și pentru c ă în acest moment accentul cade pe
monitorizarea echipamentelor, aplica ția va rula pe un server aflat într-o re țea privat ă
(intranet) și se va monitoriza doar accesul utilizatorilor din afara re țelei private ce se
conecteaz ă cu ajutorul unui client VPN, deci și monitorizarea routerului de acces (un
router CISCO 3600).
Aplica ția este construit ă din mai multe module separate care comunic ă între ele
cu ajutorul unei baze de date. Utilizatorul stabile ște ce echipament dore ște s ă
monitorizeze, salveaz ă adresa acestuia în baza de date și dup ă câteva minute se va lansa
un proces pe server care va deschide o conexiune la respectivul echipament și va începe
procesul de monitorizare. Modulele care interac ționeaz ă cu utilizatorul sunt realizate în
PHP pentru a putea genera dinamic pagini cu informa ție util ă și a permite interac țiunea
utilizatorului cu baza de date, modulele care colecteaz ă informa țiile de la echipamente
Monitorizarea echipamentelor de telecomunica ții
4sunt realizate în C și ruleaz ă pe o ma șină UNIX, unde ruleaz ă atât serverul de web și
serverul de baze de date.
Datorit ă acestui model de func ționare nu este necesar ă construirea unui
software foarte complicat care s ă realizeze interfa ța dintre proces și utilizator, opera țiile
de citire și scriere într-o baz ă de date sunt cunoscute și foarte bine implementate fiind la
ora actual ă disponibile sisteme de gestiune a bazelor de date (SGBD) complexe care
ofer ă timpi de r ăspuns foarte mici și unelte de dezvoltare, care pot permite dezvoltarea
unui astfel de sistem într-un timp foarte scurt. Pentru SGBD avem de ales între sisteme gratuite care la ora actual ă au ajuns s ă ating ă performan țele unor SGBD-uri comerciale
foarte scumpe sau SGBD-uri pentru care trebuie s ă plătim foarte mul ți bani. Aici apare
o caracteristic ă important ă, aceea a costului sc ăzut. Deoarece scopul
proiectului este de a prezenta o solu ție pentru un proces real am avut de ales între dou ă
dintre cele mai populare SGBD-uri gratuite: MySQL și PostgreSQL (o scurt ă prezentare
a punctelor forte respectiv a punctelor slabe ale fiecaruia, va fi prezentat ă în capitolul 2)
noi optând pentru utilizarea ca și SGBD a MySQL-ului.
Comunicarea dintre utilizator și baza de date se realizeaz ă cu ajutorul unui
server web instalat împreun ă cu suport pentru php (acesta din urm ă facilitând conectarea
la SGBD și oferind o interfa ță de progrmare a bazelor de date extrem de puternic ă și
simplu de folosit). Datele provenite de la echipamente sunt prelucrate cu ajutorul unui program C care permite un timp de r ăspuns și o flexibilitate mai mare (în cazul folosirii
ca SGBD a serverului MySQL acesta ofer ă biblioteci de func ții C pentru conectarea la
bazele de date).
Monitorizarea echipamentelor de telecomunica ții
5Capitolul 2. Concepte teoretice
Aplica ția care s-a propus spre realizare este aceea de monitorizare a unor
echipamente de telecomunica ții prin intermediul internetului/intranetului. Acest lucru
nu reprezint ă o chestiune prea simpl ă și de aceea vom avea nevoie de unele elemente,
care nu apar îns ă la o conducere a unui proces de pe un calculator f ără a folosi în
prealabil internetul.
Pentru ca informa țiile despre starea echipamentelor la un moment dat și
comunicarea dintre utilizatori s ă fie cât mai rapid ă se vor genera pagini HTML
dynamic, în func ție de datele aflate la un momendat în baza de date. Acestea sunt
generate folosind PHP-ul. Pentru stocarea datelor se v-a folosi serverul de baze de date
MySQL.
Interac țiunea dintre serverul de web, Apache, utilizat în aplica ția noastr ă și
serverul de baz ă de date MySQL, precum și paginile dinamice scrise în PHP, și
utilitatea lor în aceast ă aplica ție, vor fi prezentate în cele ce urmeaz ă.
2.1. Serverul de web
Pentru a realiza o astfel de aplica ție, cea mai utilizat ă form ă de implementare
este aceea a realiz ării unei aplica ții client – server. Deci, în cazul de fa ță vom avea
nevoie de folosirea unui server, astfel încât s ă existe posibilitatea comunic ării dintre
utilizatorii care conduc procesele și procesele supuse conducerii, precum și pentru a
salva în baza de date anumite informa ții referitoare la procese. Clien ții vor cere o
conexiune la server, folosind un browser web, iar serverul dup ă ce a realizat conexiunea
și a f ăcut în prealabil autentificarea, va genera un r ăspuns care îi va da posibilitatea
utilizatorului s ă monitorizeze echipamentul sau echipamentele pe care are permisiunea
să le monitorizeze. Browserul de web poate fi de orice tip (IExplorer, Netscape, Mozila
, Opera) deoarece codul HTML generat este conform stadardelor.
Făcând o descriere metaforic ă, server-ul web poate fi comparat cu un chelner
dintr-un restaurant. Chelnerul va fi serverul web, restaurantul va fi mediul în care acesta lucreaz ă (în special sistemul de operare), buc ătăria restaurantului va fi sistemul de
fișiere din care serverul web va alege fi șierele cerute de clien ți. Aceast ă compara ție este
Monitorizarea echipamentelor de telecomunica ții
6posibil ă deoarece și serverul web si chelnerul au acea și func ție principal ă: aceea de a
servi.
Figura 2.1.1 Schema de principiu a func ționării server-ului web
Server-ul web este un program care ruleaz ă pe un calculator, a șteapt ă pe un port
o conexiune TCP venit ă de la un client și serve ște acestuia pagini web folosind
protocolul HTTP .
Server-ul web este un software, un program de sine st ătător, un executabil cu o
func ție bine stabilit ă: accea de a servi la cerere pagini de Internet într-un mod bine
determinat. Acest software poate fi: Apache HTTP Server , Microsoft Internet
Information Services (IIS) , iPlanet Web Server , Roxen WebServer , Zeus WebServer , etc.
Exist ă numeroase alte implement ări de web server, cele numite mai sus ocupând
primele locuri în topul celor mai folosite servere web. Intern, procesul de func ționare al
acestor programe este foarte complex, ele urm ărind în special performan ța, securitatea
și scalabilitatea. Trebuie men ționat c ă o aplica ție de tip web server poate fi scris ă în mai
puțin de 500 linii de cod C. Bineîn țeles aceasta va avea o func ționare foarte limitat ă, dar
va corespunde defini ției de mai sus, aceea de a transmite pagini web (pagini HTML și
imagini) c ătre clien ți. Aplica țiile mature, ca cele enumerate mai sus, dispun de o
multitudine de func ționalit ăți extinse, în jurul lor operând tehnologii precum codurile
externe de generare de pagini PHP, CGI, JSP sau ASP, administrarea sesiunilor de
utilizator de c ătre un server de aplica ții care folose ște Enterprise Java Beans (EJBs) sau
Microsoft Component Object Model (COM+), extensii Microsoft FrontPage, interog ări
Lightweight Directory Access Protocol (LDAP) sau Microsoft Active Directory.
Fiecare server web dispune de un set caracteristic de astfel de tehnologii, care
alături de capacitatea și scalabilitatea sa îl individualizeaz ă printre celelalte produse.
Server
web Script PHP,
CGI, ASP, etc 1. conexiune
TCP/IP
2. cerere HTTP
3. ras puns
HTTP
Clientul (browser web)
Monitorizarea echipamentelor de telecomunica ții
7Alegerea unui server este de aceea puternic influen țată de tehnologia pe care acesta o
suport ă, câștig de cauz ă având de aceea probabil servere proiectate modular cum ar fi
Apache, lider consacrat pe pia ța serverelor web. Acest succes se bazeaz ă în mare parte
pe faptul c ă realizarea de aplica ții suplimentare este influen țată de întreaga comunitate
Open Source precum și datorit ă gratuit ății și extensibilit ății sale. Printre criteriile de
diferen țiere între produsele existente pe pia ță se mai num ără și instalarea, configurarea
și administrarea procesului general de web-serving.
Prin calculatorul pe care va rula serverul trebuie s ă înțelegem platforma pe care
va rula acesta. Platforma este caracterizat ă de hardware-ul și de sistemul de operare pe
care va fi instalat serverul web. Platforma hardware este în general un calculator ale
cărui performan țe încep de la cele mai minimale pân ă la servere de tip mainframe.
Acest calculator va fi cel mai probabil un server dedicat, conectat permanent la o re țea
(Intranet sau Internet). Pentru alegerea tipului de hardware dispunem de o gam ă foarte
largă de sisteme, îns ă un criteriu necesar alegerii este compatibilitatea cu softul ales ca
web server. Asta deoarece serverele web sunt dependente de arhitectura pe care vor rula și mai ales de sistemul de operare instalat pe acea arhitectur ă. De exemplu, IIS ruleaz ă
numai pe Windows, Zeus necesit ă Unix, Roxen și iPlanet ruleaz ă fie pe Unix, fie pe
Windows, Apache se g ăsește ca open-source, putând fi compilat pe o larg ă varietate de
versiuni Unix/Linux, dar se g ăsește și în versiuni precompilate pentru Windows sau
Mac OS X. Capacitatea de a rula pe mai multe tipuri de sisteme de operare le confer ă
acestora o r ăspândire mai larg ă, cu toate c ă performan țele sunt superioare în cazul
rulării pe Unix.
Așadar, între serverul web și sistemul de operare folosit este o leg ătură strâns ă,
alegerea unei configura ții rămânând o problem ă comercial ă. Este evident c ă între
diversele solu ții exist ă diferen țe de pre ț de achizi ție, începând cu 0$ pentru
Apache/Linux pân ă la 4000$ pentru IIS/Windows.
Server-ul web – ca orice aplica ție server – va asculta un port. Acest port este în
mod standard portul 80, acesta fiind cel folosit implicit la introducerea unei adrese
normale de web. Dac ă serverul web a fost configurat s ă asculte alt port, de exemplu
8080, atunci adresa va trebui s ă con țină și num ărul portului la care trebuie s ă se fac ă
(exemplu: http://www.myproiect.ro:8080/
). Folosirea altui port decât 80 poate fi
datorat ă rulării simultane pe aceea și ma șină a mai multor servere web: de exemplu,
Apache poate fi instalat pentru teste pe portul 8080, pe când portul 80 s ă fie folosit de
Monitorizarea echipamentelor de telecomunica ții
8IIS. Odat ă stabilit portul și pornit serverul, un client se poate conecta la serverul web
folosind adresa ma șinii în cauz ă. Aceast ă adres ă se nume ște URL ( Uniform Resource
Locator ) și este folosit ă exclusiv pentru a localiza și determina ma șina gazd ă, protocolul
folosit și fișierul dorit. De exemplu, orice adres ă din spa țiul de adrese românesc are
forma:
[http[s]://]subdomeniu.domeniu.ro [:n][/localizare/fisier]
De asemenea, se poate folosi adresa IP a ma șinii gazd ă în mod direct sau aliasul
localhost dac ă conexiunea se face direct de pe ma șina gazd ă. Datorit ă folosirii
protocolului TCP – protocol orientat pe conexiuni, în care o conexiune se creaz ă la
cerere și se închide de îndat ă ce nu mai este nevoie de ea – conexiunea între client și
serverul web se va termina de îndat ă ce fi șierul a fost trimis de c ătre web-server. Starea
conexiunii, în cazul fi șierelor mai mari decât un pachet TCP, se p ăstreaz ă activ ă atât de
către client, cât și de c ătre server.
În situa ția de fa ță ne putem afla în oricare din urm ătoarele situa ții de accesare a
web-serverelor:
• http://www.uvt.ro/ : cel mai simplu mod de adresare ;
• http://www.myproiect.ro/acces.php : adresarea fi șierului acces.php apar ținând
domeniului myproiect.ro ;
• http://localhost:8080/test/test1.htm : pentru a accesa fi șierul test1.htm din
directorul test de pe mașina local ă prin intermediul serverului care ascult ă pe portul
8080 ;
• https://80.97.33.1/test.php : adresarea securizat ă a fi șierului test.php folosind IP-ul
mașinii gazd ă.
Clientul folosit pentru accesarea serverului web este cel mai probabil un browser
(sau "navigator") web, dar poate fi și alt program capabil s ă se conecteze la un port TCP
(de exemplu: telnet). Browserul web este programul folosit la afi șarea de con ținut web.
Trebuie deci s ă știe s ă interpreteze pagini HTML, s ă afișeze imagini și alte forme de
conținut multimedia, s ă foloseasc ă referin țe (linkuri) etc. Cea mai important ă
caracteristic ă a sa este probabil capacitatea de a se conecta prin protocolul TCP la un
server web. Metoda de conectare am prezentat-o anterior. Mai trebuie men ționat c ă
Monitorizarea echipamentelor de telecomunica ții
9introducerea unei adrese web (de exemplu: http://www.myproiect.ro/fisier.htm ) în
browser, produce urm ătorul lan ț de ac țiuni:
• Browserul determin ă protocolul pe care îl va folosi în dialogul cu serverul web
(http:// = HTTP – HyperText Transfer Protocol ).
• Browserul determin ă adresa web a serverului ( www.myproiect.ro ).
• Browserul determin ă ce anume trebuie s ă cear ă de la serverul web ( fisier.htm ).
• Pe baza adresei web, browserul determin ă adresa IP a ma șinii pe care ruleaz ă
serverul web prin interog ări DNS ( Domain Name Service ).
• Pe baza adresei IP determinat ă anterior, browserul instaureaz ă o conexiune TCP
pe portul specificat în URL sau implicit pe portul 80.
• Browserul trimite o cerere GET c ătre server specificând fi șierul dorit: GET
/fisier.htm .
• Serverul web r ăspunde trimi țând fi șierul dorit sau o eroare corespunz ătoare în
cazul în care trimiterea nu este posibil ă (lipsa fi șierului, drepturi de acces
insuficiente etc.). Aici conexiunea dintre client și server se încheie.
• Browserul analizeaz ă fișierul primit și îl afi șează corespunz ător.
Dup ă cum am mai spus, rolul dedicat al serverului web este acela de a servi
fișiere. În principal aceste fi șiere sunt fi șiere în format HTML, dar nu numai. Serverul
web poate s ă serveasc ă și alte fi șiere: imagini, sunete, anima ții, arhive etc. Fi șierele care
sunt puse la dispozi ția navigatorului se afl ă stocate într-un director v ăzut ca r ădăcină de
către web server (exemplu: C:\Inetpub\wwwroot pentru IIS sau /var/www/html/ pentru
Apache). Acest director se specific ă în configura ția serverului și î n e l s e v o r s t o c a
fișierele și structura de subdirectoare pe care le va folosi serverul web în c ăutarea unui
fișier cerut de c ătre un client ( "buc ătăria restaurantului" ). Servirea unui fi șier se
efectueaz ă dac ă fișierul specificat exist ă, dac ă este accesibil de c ătre serverul web și
dacă drepturile de acces nu interzic acest lucru. În cazul neîndeplinirii uneia dintre
aceste condi ții, serverul va trimite un cod de eroare sau o pagin ă predefinit ă care s ă
informeze despre eroarea ap ărută.
De multe ori, fi șierele pe care trebuie s ă le serveasc ă depind de alte programe
externe de generare de cod (CGI, ASP, JSP, PHP). Fi șierele care necesit ă astfel de
prelucr ări vor fi generate de programul extern, a c ărui rezultat va fi un fi șier HTML nou
creat. Acest fi șier va fi transferat serverului web, pe care acesta poate s ă-l serveasc ă ca
Monitorizarea echipamentelor de telecomunica ții
10pe orice alt fi șier. Acest proces st ă la baza tuturor siturilor dinamice și este absolut
necesar pentru pagini al c ăror con ținut necesit ă modific ări în func ție de anumite criterii.
"Dialogul" dintre client și server se efectueaz ă prin protocolul HTTP, care este
un protocol la nivel de aplica ție. "Transportul" comunica ției dintre client și server se
efectueaz ă folosind protocolul TCP, protocol la nivel de re țea. Protocolul HTTP
define ște modul prin care se în țeleg clientul și serverul. Clientul va trimite o cerere (o
comand ă) HTTP în mod text simplu, (exemplu: GET, POST, HEAD, PUT) prin care
informeaz ă serverul despre ac țiunea pe care vrea s ă o întreprind ă. Dac ă, spre exemplu,
serverul va primi o cerere de tip GET /index.htm , el va r ăspunde cu un status code prin
care informeaz ă browserul despre succesul cererii sau eventualele erori ap ărute (de
exemplu: codul 404 indic ă faptul c ă fișierul specificat în URL nu exist ă, codul 200
indic ă succesul cererii). În caz de succes, serverul va transmite un antet ( header ) către
browser, cu informa ții ca: tipul și versiunea protocolului folosit, limba con ținutului,
dacă este necesar ă salvarea în cache-ul browserului sau nu, tipul con ținutului transmis
(MIME type ), data serverului, numele serverului etc. Dup ă antet, va fi transmis
conținutul fi șierului cerut (în cazul unei cereri HEAD, doar antetul va fi trimis, nu și
conținutul fi șierului).
Datorit ă faptului c ă serverul web are acces direct la fi șiere din sistemul pe care
ruleaz ă, securitatea este un punct de maxim interes și a necesitat multe versiuni ale
serverelor web pentru a ajunge la un anumit nivel de siguran ță. Alt ă problem ă în
procesul de servire a paginilor o reprezint ă viteza și mul țimea de cereri simultane pe
care le poate prelucra serverul, problem ă rezolvabil ă prin m ărirea performan țelor
hardware și prin implementarea software a unor algoritmi optimi și performan ți.
2.2. Pagini dinamice cu PHP
PHP (acronim recursiv petnru "PHP: Hypertext Preprocessor") este un limbaj de
scripting utilizat pe scar ă larg ă, realizat și distribuit în sistem Open Source, ce se
potrive ște produc ției Web și poate fi încapsulat în HTML.
Un script PHP difer ă față de un script scris în alte limbaje cum ar fi Perl sau C
prin faptul c ă în loc de a scrie un program cu o mul țime de comenzi pentru a produce un
Monitorizarea echipamentelor de telecomunica ții
11HTML, se scrie un script HTML ce include cod pentru a realiza aplica ția. Codul PHP
este delimitat de coduri de start și de sfâr șit ce permit intrarea și ie șirea din "modul
PHP".
Diferen ța dintre PHP și JavaScript (de exemplu) este acela c ă PHP este executat
pe server pe când JavaScript este executat pe calculatorul clientului (de navigatorul de
Internet). Dac ă ar exista un script similar cu cel precizat mai sus, pe server, clientul ar
primi doar rezultatele scriptului ce este rulat, f ără a vedea în nici un fel codul din spatele
acestuia. Se poate chiar configura serverul de web ca acesta s ă proceseze toate fi șierele
HTML cu PHP și astfel nu exit ă nici o metod ă ca un utilizator s ă stie de fapt ce exist ă în
fișierele aplica ției.
Unul din principalele avantaje ale folosirii PHP-ului este c ă acesta este foarte
ușor de în țeles și de implementat, dar ofer ă în acela și timp o mul țime de facilit ăți
avansate pentru un programatorul profesionist.
PHP este axat pe partea de scripting ce ruleaz ă pe server, deci poate realiza și
ceea ce face un program CGI, cum ar fi colectarea de date de la formulare, generarea de conținut dinamic sau trimitere și primire de cookie-uri. Dar PHP poate face mult mai
multe.
Exist ă trei domenii principale unde sunt folosite scripturile PHP:
• Scripturi ce ruleaz ă pe server: Acesta este cel mai tradi țional și cel mai
important pentru PHP. Este nevoie de trei lucruri pentru a face sa mearg ă.
Interpretorul PHP (CGI sau modul de server), un server de web și un navigator
de web. Este de asemenea nevoie ca serverul de web s ă fie pornit, cu o
conexiune PHP instalat ă. Se poate accesa rezultatul programelor PHP cu un
navigator print intermediul serverului de web.
• Scripting la linia de comand ă. Se poate face ca PHP s ă ruleze f ără a fi nevoie de
server și de browser, ci doar de interpretorul PHP. Aceast ă metod ă este ideal ă
pentru scripturile ce se vor a fi executate de regul ă folosind cron (respectiv task
scheduler în Windows), sau sarcini simple de procesare a textelor.
• Scrierea de aplica ții: Acestea ruleaz ă pe partea clientului în mod grafic (GUI).
Probabil c ă PHP nu este limbajul cel mai bun de a scrie aplica ții cu ferestre
pentru Windows sau alte sisteme de operare, dar dac ă se cunoa ște PHP foarte
bine și se dore ște folosirea unor facilit ăți avansate a PHP-ului în aplica ția ce
ruleaza pe partea clientului se poate totu și folosi PHP-GTK pentru a scrie astfel
Monitorizarea echipamentelor de telecomunica ții
12de programe. De asemenea exist ă posibilitatea de a scrie aplica ții ce ruleaza pe
platforme diferite folosind aceast ă metod ă. PHP-GTK este o extensie a PHP-
ului, nedisponibil ă în distribu ția principal ă de PHP.
PHP poate fi folosit pe aproape toate marile sisteme de operare, incluzând
Linux, multe variante de Unix (incluzând HP-UX, Solaris și OpenBSD), Microsoft
Windows, Mac OS X, RISC OS, probabil și altele. PHP are deasemenea suport pentru
majoritatea serverelor de web din prezent. Acestea includ serverele Apache, Microsoft
Internet Information Server, Personal Web Server, Netscape și iPlanet, serverul Oreillz
Website Pro, Caudium, Xitami, OmniHTTPd, și multe atele. Pentru majoritatea
serverelor PHP are un modul, iar pentru celelalte suport ă standardul CGI, PHP putând
să lucreze ca un procesor CGI.
Deci, cu PHP, exist ă libertatea de a alege un sistem de operare și un server de
web. Chiar mai mult, exist ă posibilitatea de a alege programarea procedural ă sau
programarea orientat ă obiect, sau ambele. Cu toate acestea, nu orice facilitate a
standardului POO este prezent ă în versiunea curent ă a PHP-ului, multe libr ării de cod și
aplica ții mari (incluzând și libr ăria PEAR) sunt scrise folosind doar cod POO.
Cu PHP nu se limitateaz ă obținerea unui rezultat HTML. Posibilit ățile PHP-ului
includ afi șarea de imagine, fi șiere PDF. Se poate de asemeanea ca rezultatul s ă fie orice
fișier text, cum ar fi XHTML sau orice alte fi șiere XML. PHP poate genera autmoat
aceste fi șiere și să le salveze în sistemul de fi șiere în loc s ă le afi șeze, formând un cache
de partea serverului pentru con ținutul dinamic al aplica ției.
Una dintre cele mai puternice și importante facilit ăți în PHP este suportul s ău
pentru o gam ă larg ă de baze de date. Scrierea une pagini de web ce interac ționeaz ă cu o
bază de date este incredibil de simpl ă. Urm ătoarele baze de date sunt suportate:
Tabelul 2.1. Baze de date pentru care exist ă suport PHP
Adabas D Ingres Oracle (OCI7 și OCI8)
Dbase InterBase Ovrimos
Empress FrontBase PostgreSQL
FilePro (doar citire) mSQL Solid
Hyperwave Direct MS-SQL Sybase
IBM DB2 MySQL Velocis
Informix ODBC Unix dbm
Monitorizarea echipamentelor de telecomunica ții
13De asemenea avem o extensie abstract ă a bazei de date DBX ce permite într-un
mod transparent folosirea oric ărei baze de date ce suport ă aceast ă extensie. Mai mult,
PHP suport ă ODBC (acesta îns ă nefiind gratuit), standardul Open Database Connection,
deci se poate realize conectarea la orice alt ă baz ă de date ce suport ă acest standard
mondial.
PHP are deasemeanea suport pentru a conversa cu alte servicii folosind
protocoale cum ar fi LDAP, IMAP, SNMP, NNTP, POP3, HTTP, COM (pe Windows)
și multe altele. Dintre aceste facilit ăți în przenta lucrare se folose ște protocolul HTTP.
Se poate de asemenea, deschide socket-uri de re țea și să se interac ționeze între aproape
toate limbajele de programare Web. Referitor la interconectare, PHP are suport pentru
instan țierea obiectelor Java și utilizarea lor într-un mod transparent ca obiecte PHP. Se
poate, de asemenea, folosi extensii CORBA pentru a accesa obiecte aflate la distan ță.
PHP are capabilit ăți extrem de folositoare pentru procesarea textului, de la
POSIX Extins sau expresii regulare Perl pân ă la parsarea documentelor XML. Pentru
parsarea și accesarea documentelor XML, suport ăm standardele SAX și DOM. Se poate
folosi extensia noastr ă XSLT pentru a transforma documentele XML.
2.3. Serverul de baze de date MySQL
S-a ales acest tip de server de baze de date deoarece dispune de modalit ăți de
interogare a bazelor de date foarte simple, având în acela și timp un cost sc ăzut și
performan țe ridicate, care se vor prezenta pe parcursul acestui subcapitol .
Când se vorbe ște despre baze de date, fiecare persoan ă percepe altfel aceast ă
noțiune. A șadar trebuie s ă explic ăm aceast ă noțiune: vorbim despre sisteme de gestiune
(sau administrare, sau management) a bazelor de date, adic ă despre soft-uri specializate
pe manevrarea cât mai eficient ă și cât mai sigur ă a unor volume mari de date. Dac ă
excludem din discu ție sistemele desktop și sistemele înglobate (embedded), r ămânem cu
o categorie numit ă generic „servere de baze de date”. În vremurile noastre, acestea sunt
bazate pe modelul rela țional (sau pe derivate ale acestuia), în țelegând un dialect SQL,
sunt extrem de complexe și în acela și timp extrem de scumpe.
În ultima vreme au ap ărut servere de baze de date gratuite, dezvoltate și
furnizate în regim open source . Mai mult, acestea au încetat s ă mai fie curiozit ăți sau
Monitorizarea echipamentelor de telecomunica ții
14experimente exotice și, în unele privin țe, au ajuns s ă fie comparabile cu sistemele
comerciale. R ăspândirea acestor sisteme, de și foarte rapid ă, este relativ limitat ă din
punctul de vedere al utiliz ării: majoritatea instal ărilor sunt furnizate s ă ofere un back-
end pentru internet și intranet. Un alt domeniu în care sistemele gratuite au o ni șă
perfect ă este înv ățământul. Fie c ă este vorba de universit ății, fie c ă este vorba de
autodidac ți, aceste sisteme reprezint ă alegerea fireasc ă (și, uneori, singura posibil ă).
Cele mai r ăspândite sisteme gratuite în momentul de fa ță sunt MySQL și
PostgreSQL. În ultima vreme, rivalitatea dintre ele a atins cotele unui adev ărat „r ăzboi
religios”, comparabil cu cel dintre comunitatea Linux și Microsoft.
Dar, chiar dac ă ambele produse sunt gratuite, alegerea celui mai potrivit server
de baze de date este o decizie important ă, care poate afecta desf ășurarea întregului
proiect. A șadar, este bine s ă fie f ăcută cu calm și în cuno știință de cauz ă.
MySQL a fost pân ă de curând crea ția solitar ă a unui programator pe nume
Michael Widenius, lucrând la firma suedez ă TcX. Prima versiune a ap ărut în 1995 și
avea scopul precis de a furniza un back-end rapid și stabil pentru siteuri Web cu pagini
generate dinamic. În acest scop, proiectul a fost direc ționat în mod preponderent spre
performan ță. Dup ă ce dezvoltarea a trecut la modelul open source (GPL GNU General
Public License), echipa de programatori a crescut iar unele firme comerciale contribuie și ele la dezvoltarea motorului și a unor instrumente adiacente.
Dialectul SQL implementat de MySQL nu respect ă în totalitate standardul ANSI
SQL, lipsind unele func ționalit ăți prev ăzute de standard dar având de asemenea un set
de extensii fa ță de standard.
În aplica ția noastr ă vom avea de-a face cu mai multe tabele și de aceea se vor
face câteva referiri vis-à-vis la modul în care se creeaz ă un tabel și felul în care se face
extragerea datelor din baza de date.
MySQL este foarte comod în faza de creare a bazelor de date, permi țând în
acela și timp și popularea acesteia cu ajutorul unei selec ții:
CREATE TABLE IF NOT EXIST tabel1 (
a TINYTEXT, b TINYTEXT,
) SELECT id, cont FROM bd2.tabel2
WHERE id > 100;
Monitorizarea echipamentelor de telecomunica ții
15 Este de remarcat op țiunea IF NOT EXIST, care va evita apari ția unei erori în
cazul în care tabela tabel1 exist ă deja, a șa cum IF EXIST va evita apari ția unei erori la o
interogare de tipul DROP TABLE. Crearea unei tabele și popularea ei în acela și timp cu ajutorul unei selec ții este
extrem de util ă în foarte multe cazuri. De notat c ă defini țiile câmpurilor specificate în
SELECT sunt ad ăugate la defini ția tabelei, astfel încât (în cazul nostru) tabela tabel1 ca
avea coloanele a ,b, id și cont.
Un alt punct forte al MySQL-ului este implementarea comenzii ALTER TABLE, care extinde în mod copios standardul SQL. Pe lâng ă numeroase clauze
suplimentare, avem posibilitatea s ă folosim mai multe clauze în aceea și comand ă
ALTER TABLE. De exemplu:
Unul dintre punctele slabe ale MySQL-ului vine atunci când este vorba despre
selec ții, și anume: MySQL nu poate face subselec ții. Este f ără îndoial ă una dintre cele
mai mari bile negre ale acestui produs. În unele opera ții suficient de simple aceast ă
deficien ță poate fi dep ășită relativ u șor, de exemplu:
Dar pentru selec ții mai complexe, manualul ne sugereaz ă să folosim tabele
temporare (care îns ă pot deteriora serios performan țele) sau s ă rezolv ăm problema în
limbajul procedural al aplica ției (ceea ce de regul ă se traduce prin înglobarea în selec ție
a rezultatelor subselec ției). ALTER TABLE tabel1
ADD COLUMN c INT DEFAULT 13, MODIFY id int(11) NOT NULL,
ADD PRIMARY KEY(id);
SELECT * FROM tabel1
WHERE id NOT IN
(SELECT id FROM tabel2) Cu subselect:
SELECT tabel1.* FROM tabel1
LEFT JOIN tabel2
ON tabel1.id=tabel2.id
WHERE
ta
bel2.id IS NULL ;Fără subselect (în MySQL):
Monitorizarea echipamentelor de telecomunica ții
16 De notat c ă absen ța subselec țiilor nu se restrânge doar la condi țiile din where, ci
este valabil ă oriunde poate s ă apar ă o selec ție în cadrul altei selec ții. Din nefericire în
MySQL lipsesc nu doar subselec țiile, ci și opera țiile cu seturi (UNION, INTERSECT,
EXCEPT, etc.), fapt care complic ă și mai mult unele opera ții.
A șa numitele „restric ții” (sau „constrângeri” – constraints) au fost mereu un
motiv de ceart ă în lumea bazelor de date rela ționale. Dintre acestea, cea numit ă
FOREIGN KEY este un caz special deoarece ea este menit ă să asigure integritatea
referen țială a unei baze de date (una dintre cele 12 reguli enun țate de Dr. Codd), iar unii
exper ți refuz ă să încadreze un SGBD în categoria rela țional ă dac ă acesta nu
implementeaz ă aceast ă restric ție într-o manier ă declarativ ă.
MySQL nu dispune de aceast ă caracteristic ă, dar permite scrierea clauzelor
foreign key pentru compatibilitate și cu scop explicativ. Mai mult chiar, creatorii lui
MySQL ne explic ă cu non șalan ță în manual c ă aceste chei str ăine reprezint ă o
problem ă și, de fapt, nu avem nevoie de ele niciodat ă.
MySQL nu are no țiunea de view și nici suport pentru tranzac ții aceste lucruri
fiind la rândul lor dezavantaje pentru acest SGBD, dar deoarece în cazul nostru unul dintre cele mai importante lucruri este viteza de r ăspuns la cereri simple și aici MySQL
întrece pân ă și sistemele comerciale. Un alt punct forte este stabilitatea, la care MySQL-
ul exceleaz ă. Date fiind acestea pentru cazul nostru MySQL este o alegere viabil ă și în
func ție de necesit ăți, în implement ările viitoare se poate alege un alt SGBD.
2.4. Apache, PHP și Mysql
Cum func ționeaz ă acest sistem? S ă consider ăm urm ătorul scenariu. Utilizatorul
trimite cerere de conectare c ătre pagina din navigator. Aceast ă cerere este trimis ă către
serverul de web, care la rândul s ău apeleaz ă scriptul PHP. Acesta din urm ă este executat
de c ătre preprocesorul PHP, care extrage datele necesare din baza de date. Rezultatele
sunt apoi grupate și formatate de scriptul PHP și transformate în cod HTML. În fine,
pagina rezultat ă este trimis ă navigatorului, care o afi șează.
Monitorizarea echipamentelor de telecomunica ții
17
Figura 3.4.1 Func ționare sistemului Apache, PHP, MySQL
Să urm ărim acest proces pas cu pas:
• Utilizatorul introduce adresa în fereastra navigatorului, care trimite
cererea pentru pagina http://www.myproiect.ro/test.php ;
• Serverul Apache prime ște cererea pentru test .php și știe c ă fișierele cu
aceast ă extensie sunt prelucrate de preprocesorul PHP, a șa că îi „spune”
acestuia s ă preia execu ția;
• test.php este un script PHP ce con ține comenzi; una dintre aceste
comenzi este de a realiza o conexiune cu baza de date și de a extrage
anumite date; PHP știe cum s ă facă acest lucru ;
• datele cerute sunt extrase din baza de date și sunt formatate de c ătre PHP,
apoi rezultatul este convertit în cod HTML;
• pagina HTML rezultat ă este returnat ă serverului de web Apache;
• Apache transmite pagina de web navigatorului care a ini țiat cererea,
acesta din urm ă afișând-o într-o fereastr ă.
2.5. Programarea folosind procese în Unix
Orice sistem de calcul modern este capabil s ă execute mai multe programe în
acela și timp. Cu toate acestea, în cele mai multe cazuri, unitatea central ă de prelucrare
(CPU) nu poate executa la un moment dat decat un singur program. De aceea, sarcina
de a rula mai multe programe în acela și timp revine sistemului de operare, care trebuie Pagina de web
în browser
Server de web
Apache
PHP Script
PHP
SGBD
MySQL
Monitorizarea echipamentelor de telecomunica ții
18să introduc ă un model prin intermediul caruia execu ția programelor, privit ă din
perspectiva utilizatorului, s ă se desf ăsoare în paralel. Se realizeaz ă, de fapt, un
pseudoparalelism , prin care procesorul este alocat pe rând programelor care trebuie
rulate, câte o cuant ă de timp pentru fiecare, astfel încât din exterior ele par c ă ruleaz ă
efectiv în acela și timp.
Cel mai raspândit model care introduce paralelismul în execu ția programelor
este modelul bazat pe procese . Acest model este cel adoptat de sistemul de operare
Unix.
Un proces este un program secvential î n executie , împreun ă cu zona sa de date,
stivă și, num ărătorul de instructiuni (program counter). Trebuie facuta înc ă de la început
distinc ția dintre proces și program . Un program este, în fond, un șir de instruc țiuni care
trebuie executate de c ătre calculator, în vreme ce un proces este o abstractizare a
programului, specific ă sistemelor de operare. Se poate spune c ă un proces execut ă un
program și că sistemul de operare lucreaz ă cu procese, iar nu cu programe. Procesul
include în plus fa ță de program informa țiile de stare legate de execu ția programului
respectiv (stiva, valorile regi ștrilor CPU etc.). De asemenea, este important de subliniat
faptul c ă un program (ca aplica ție software) poate fi format din mai multe procese care
să ruleze sau nu în paralel.
Orice proces este executat secven țial, iar mai multe procese pot s ă ruleze în
paralel (între ele). De cele mai multe ori, execu ția în paralel se realizeaz ă alocând pe
rând procesorul câte unui proces. De și la un moment dat se execut ă un singur proces, în
decurs de o secund ă, de exemplu, pot fi executate por țiuni din mai multe procese. Din
aceast ă schem ă rezult ă că un proces se poate g ăsi, la un moment dat, în una din
urm ătoarele trei stari [1]:
• în execu ție;
• preg ătit pentru execu ție;
• blocat.
Procesul se g ăseste î n exec țtie atunci când procesorul îi execut ă instruc țiunile.
Preg ătit de execu ție este un proces care, de și ar fi gata s ă iși continue execu ția, este lasat
în a șteptare din cauz ă că un alt proces este în execu ție la momentul respectiv. De
asemenea, un proces poate fi blocat din doua motive: el i și suspend ă execu ția în mod
voit sau procesul efectueaz ă o opera ție în afara procesorului, mare consumatoare de
Monitorizarea echipamentelor de telecomunica ții
19timp (cum e cazul opera țiilor de intrare-ie șire – acestea sunt mai lente și între timp
procesorul ar putea executa p ărți din alte procese).
Din perspectiva programatorului, sistemul de operare UNIX pune la dispozi ție
un mecanism elegant și simplu pentru crearea și utilizarea proceselor.
Orice proces trebuie creat de c ătre un alt proces. Procesul creator este numit
proces p ărinte , iar procesul creat proces fiu . Exist ă o singur ă excep ție de la aceast ă
regul ă, și anume procesul init, care este procesul ini țial, creat la pornirea sistemului de
operare și care este responsabil pentru crearea urm ătoarelor procese. Interpretorul de
comenzi, de exemplu, ruleaz ă și el în interiorul unui proces.
Fiecare proces are un identificator numeric, numit identificator de proces
(process identifier – PID) . Acest identificator este folosit atunci când se face referire la
procesul respectiv, din interiorul programelor sau prin intermediul interpretorului de
comenzi.
Un proces trebuie creat folosind apelul sistem:
pid_t fork()
Prin aceast ă func ție sistem, procesul apelant (p ărintele) creeaz ă un nou proces
(fiul) care va fi o copie fidel ă a părintelui. Noul proces va avea propria lui zon ă de date,
propria lui stiv ă, propriul lui cod executabil, toate fiind copiate de la p ărinte în cele mai
mici detalii. Rezult ă că variabilele fiului vor avea valorile variabilelor p ărintelui în
momentul apelului func ție fork( ) , iar execu ția fiului va continua cu instruc țiunile care
urmeaz ă imediat acestui apel, codul fiului fiind identic cu cel al p ărintelui. Cu toate
acestea, în sistem vor exista din acest moment dou ă procese independente, (de și
identice), cu zone de date și stiv ă distincte. Orice modificare f ăcută, prin urmare, asupra
unei variabile din procesul fiu, va r ămâne invizibil ă procesului parinte și invers.
Procesul fiu va mo șteni de la p ărinte to ți descriptorii de fi șier deschi și de c ătre
acesta, a șa că orice prelucr ări ulterioare în fi șiere vor fi efectuate în punctul în care le-a
lăsat p ărintele.
Deoarece codul p ărintelui și codul fiului sunt identice și pentru c ă aceste procese
vor rula în continuare în paralel, trebuie f ăcută clar distinc ția, în interiorul programului,
între ac țiunile ce vor fi executate de fiu și cele ale p ărintelui. Cu alte cuvinte, este
nevoie de o metod ă care s ă indice care este por țiunea de cod a p ărintelui și care a fiului.
Acest lucru se poate face simplu, folosind valoarea returnat ă de func ția fork( ) .
Ea returneaza:
Monitorizarea echipamentelor de telecomunica ții
20• -1, dac ă opera ția nu s-a putut efectua (eroare)
• 0, în codul fiului
• pid, în codul p ărintelui, unde pid este identificatorul de proces al
fiului nou-creat.
Prin urmare, o posibil ă schem ă de apelare a func ției fork( ) ar fi:
Func ția fork( ) creeaz ă un proces identic cu procesul p ărinte. Pentru a crea un
nou proces care s ă ruleze un program diferit de cel al p ărintelui, aceast ă func ție se va
folosi împreuna cu unul din apelurile sistem de tipul exec( ) : execl( ), execlp( ), execv( ),
execvp( ), execle( ), execve( ) .
Toate aceste func ții primesc ca parametru un nume de fi șier care reprezint ă un
program executabil și realizeaz ă lansarea în execu ție a programului. Programul va fi
lansat atfel încât se va suprascrie codul, datele și stiva procesului care apeleaz ă exec( ),
astfel încât, imediat dup ă acest apel programul ini țial nu va mai exista în memorie.
Procesul va r ămâne, îns ă, identificat prin acela și num ăr (PID) și va mo șteni toate
eventualele redirect ări făcute în prealabil asupra descriptorilor de fi șiere (de exemplu
intrarea și ieșirea standard). De asemenea, el va p ăstra rela ția p ărinte-fiu cu procesul
care a apelat fork( ).
Singura situa ție în care procesul apelant revine din apelul func ției exec( ) este
acela în care opera ția nu a putut fi efectuat ă, caz în care func ția returneaz ă un cod de
eroare (-1).
În consecin ță, lansarea într-un proces separat a unui program de pe disc se face
apelând fork( ) pentru crearea noului proces, dupa care în por țiunea de cod executat ă de
fiu se va apela una din func țiile exec( ) . …
if( ( pid=fork() ) < 0) { perror("Eroare");
exit(1);
} if(pid==0) { /* codul fiului */ … exit(0) } /* codul parintelui */ …
Monitorizarea echipamentelor de telecomunica ții
21 Alte func ții pentru lucru cu procese:
• pid_t getpid() – returneaz ă PID-ul procesului curent
• pid_t getppid() – returneaz ă PID-ul p ărintelui procesului curent
• uid_t getuid() – returneaz ă identificatorul utilizatorului care a lansat
procesul curent
• gid_t getgid() – returneaz ă identificatorul grupului utilizatorului care a
lansat procesul curent
Sistemul de operare UNIX are câteva comenzi foarte utile care se refer ă la
procese:
• ps – afiseaz ă informa ții despre procesele care ruleaz ă în mod curent pe
system;
• kill – semnal proces – trimite un semnal unui proces. De exemplu: kill -9 123
va termina procesul cu num ărul 123;
• killall -semnal nume – trimite semnal c ătre toate procesele cu numele nume
2.6. Particularitati ale proiectarii aplica țiilor distribuite
Proiectarea sistemelor distribuite const ă în descrieri realizate la diverse nivele de
abstractizare. Principiile generale de proiectare ale sistemelor distribuite sunt
identificate astfel:
• Sistemul distribuit este un sistem coordonat
• Proiectarea logica este independenta de arhitectura
• Localizarea datelor este transparenta pentru utilizator, pâna la limitele impuse de
condi țiile de durabilitate.
• Localizarea proceselor este transparent ă pentru utilizator
• Arhitectura fizic ă este constituit ă ca un pachet de servicii
• Cerintele locale sunt mapate pe arhitectura prin intermediul serviciilor
• Conceptele relative la distribuire sunt identificabile în modelul logic
Exist ă o serie de aspecte care diferen țiază proiectarea arhitecturilor distribuite de
alte metodologii de proiectare a sistemelor informatice. Aplica țiile client corect
Monitorizarea echipamentelor de telecomunica ții
22proiectate nu codific ă detalii referitoare la modul și locul în care datele fizice sunt
stocate și administrate și nici nu execut ă operatii low-level asupra datelor.
Principiile proiect ării aplica țiilor distribuite sunt urm ătoarele:
• Conexiuni de re țea – serverul este conectat cu clientul prin intermediul unei
rețele LAN/WAN/MAN. Sistemele distribuite corect proiectate nu consum ă
resurse semnificative pe cablu. În general, interogari SQL scurte sunt transmise
server-ului iar r ăspunsurile transmise de acesta sunt constituite ca seturi de date
de dimensiuni reduse.
• Stații de lucru opera ționale – în arhitecturile distribuite ma șina de calcul client
nu execut ă aplica ții complexe, aplica ția client fiind destinat ă în primul rând
afișării rezultatelor interog ărilor și prelu ării datelor de la utilizator prin
intermediul unei interfe țe vizuale. În concluzie, aceste sta ții de lucru pot fi dotate
cu procesoare de vitez ă scăzută.
• Utilizarea în comun a datelor, procedurilor și hardware-ului – Un sistem
distribuit depinde de comportamentul clien ților, fiecare utilizând în comun cu
serverele acelea și resurse (proceduri de stocare, RAM, capacitatea de re țea, etc).
• Sistemul utilizeaz ă minimal resursele – sistemul este proiectat astfel încat s ă
încarce la nivel minimal resursele, ceea ce permite o dezvoltare ulterioar ă a
sistemului mult mai u șoară.
• Proiectarea maximizeaz ă compromisurile – o aplica ție distribuit ă trebuie s ă
fie proiectat ă astfel încât sa minimize înc ărcarea resurselor, sau s ă evite timpul
de raspuns prea mare, etc, dar în cel mai bun caz ea este proiectat ă astfel încât s ă
echilibreze toate aceste cerin țe.
• Servere inteligente – capacitatea de transmitere a comenzilor sub form ă de
interog ări SQL, și întoarcerea rezultatelor sub form ă de seturi de date îi confer ă
serverului proprietatea de inteligen ță.
• Aplica țiile presupun un server inteligent – deciziile de proiectare a aplica țiilor
distribuite se bazeaz ă pe inteligen ța servere-lor. Clientul presupune, cu alte
cuvinte, c ă server-ul va rezolva toate problemele referitoare la manipularea
fizic ă a datelor, astfel încât lui îi revine doar sarcina de a pune întreb ări
inteligente, și de a afi șa în mod inteligent r ăspunsurile server-ului.
Monitorizarea echipamentelor de telecomunica ții
23Modalitatea de implementare a sistemului proiectat, alegerea arhitecturii, a
tehnologiilor specifice, utilizarea diverselor tipuri de re țele, etc, reprezint ă, în
continuare, decizia arhitectului de sistem.
Cel mai important instrument utilizat în etapa de proiectare este modelul
aplica ție. Rolul s ău const ă în dirijarea procesului de construire a software-ului prin
organizarea si gruparea cerin țelor, prin identificarea modului în care interac ționeaz ă și
se echilibreaz ă seturile de cerin țe. Pe baza unor astfel de modele, proiectarea și apoi
implementarea aplica ției se poate face în condi ții de certitudine în ceea ce prive ște
acoperirea întregii specifica ții a sistemului.
Figura 2.6.1 Etapele de proiectare ale unei aplica ții
Proiectarea conceptual ă transform ă cerin țele utilizatorului într-un format
accesibil nivelului de proiectare logic ă, definind problema și func țiile necesare pentru
rezolvarea ei. Etapa presupune definirea unui num ăr mare de scenarii de utilizare,
destinate identific ării cât mai complete a viziunii clientului asupra aplica ției precum și a
func ționalit ății cerute.
Aceast ă faz ă reprezint ă punctul central al model ării și nu trateaz ă tehnologiile
necesare implement ării sistemului.
În timpul stabilirii cerin țelor pe care o aplica ție trebuie s ă le satisfac ă, este
indicat ă analiza problemelor referitoare la performan ță, mediu, eventuala integrare și
interac țiune cu sistemele existente, protocoale de comunica ție, restric ții hard sau soft,
roluri ale utilizatorilor și drepturi de acces, localizarea datelor și rela ția lor cu clientul,
cerin țe de criptare, integritate și protec ție a datelor.
Proiectarea logic ă define ște entit ățile, atributele, ac țiunile și interac țiunile
dintre entit ăți, fiind de obicei cea mai complex ă etap ă a dezvoltarii aplica ției. Dup ă
identificarea utilizatorilor, a serviciilor de date precum și a componentelor sistemului,
se trece la etapa de construire a componentelor. Este indicat ca primele componente care
Monitorizarea echipamentelor de telecomunica ții
24se implementeaz ă să corespund ă nivelului cel mai de jos al sistemului (accesul la date,
servicii de mesagerie, etc.). Urm ătoarele candidate la implementare sunt serviciile care
sunt cele mai avantajate de plasarea într-un spa țiu de proces, sau calculator separat de
aplica ția client (generare de rapoarte, proceduri complexe de calcul, servicii de fax, etc).
În faza de proiectare fizic ă se iau deciziile referitoare la localizarea aplica țiilor
și a serviciilor peste nodurile sistemului, și corespunz ător acestei plas ări modul în care
componentele vor fi implementate fizic. Regula de baz ă const ă în plasarea fiec ărei
entit ăți la locul în care este utilizat ă (componentele care lucreaza cu bazele de date vor
fi plasate pe serverul de baze de date, cele care valideaza informa țiile utilizatorului vor
fi alocate ma șinii clientului, etc). Exist ă, desigur considera ții suplimentare (constrângeri
de securitate si performan ță) care pot conduce la excep ții de la aceast ă regul ă.
Monitorizarea echipamentelor de telecomunica ții
25Capitolul 3. Specifica țiile aplica ției
Se va încerca implementarea unui aplica ții de monitorizare a echipamentelor
produse de firma Mobiline, ce se încadreaz ă în categoria GSM Gateway, a conexiunilor
VPN, realizate cu ajutorul unui client VPN și a unui router Cisco 3600. Se vor
monitoriza și conexiunile VPN deoarece router-ul este direct conectat la internet și din
motive de securitate este util s ă se cunoasc ă cine, când și grupul din care face parte, se
conecteaz ă în re țeaua noastr ă privat ă. Acest lucur este extrem de important deoarece
aplica ția ce monitorizeaz ă echipamentele produse de firma Mobiline va stoca informa ții
care au un anumit grad de confiden țialitate, stocând informa ții despre convorbirile
telefonice pe care le realizeaz ă un anumit client în decursul unui anumit interval de
timp. De asemenea penetrarea re țelei de c ătre persoane neautorizate poate avea
consecin țe catastrofale pentru o firm ă de telecomunica ții.
Pentru acest lucru nu vom încerca s ă implement ăm în întregime solu ții de tip
client-server ci vom folosi un server de web prin care se va face leg ătura dintre procese
și utilizator. În general în dezvoltarea unei aplica ții sau a unui produs timpul, precum și
costurile sunt resurse critice, de aceea folosirea unui server web instalat cu suport PHP
și MySQL ca SGBD reduce timpul de dezvoltare implicând în acela și timp costuri
pentru achizi ționarea acestora egale cu zero, deci pentru implementarea unei astfel de
solu ții singurele costuri sunt cele aferente echipei care va realiza implementarea
comunic ării utilizator-echipament. Aceste costuri nu vor fi foarte ridicate deoarece
timpul de implementare se reduce foarte mult, aceast ă echip ă nu mai trebuie s ă dezvolte
protocoale de comunica ție ci doar s ă realizeze dou ă interfe țe: una dintre utilizator și
baza de date (aici se pune mare accent pe modul în care vor fi prezentate datele utilizatorului) și o a doua între echipamente și baza de date (aici accentul cade pe
extragerea tuturor informa țiilor care prezint ă importan ță pentru utilizator și stocarea lor
în baza de date).
Deoarece în solu țiile prezentate ca și parte integrant ă folosim un server de web,
Apache, suport pentru scripting, PHP, precum și un server de gestiune a bazelor de date,
MySQL vom acorda cîteva pagini modului de configurare a acestora folosind ca și
system de operare instalat pe server OpenBSD. Am decis s ă includem și aceste
prezent ări deoarece opera ții de configurare se întâmpl ă uneori s ă consume mai mult
timp decât dezvoltarea aplica ției în sine. La ora actul ă este mult mai u șor de g ăsit un
Monitorizarea echipamentelor de telecomunica ții
26programator cu experien ță în C și PHP decât un administrator de re țea care s ă fie
capabil s ă asigure configurarea și între ținerea acestor aplica ții, deci prezentarea acestor
opera ții nu poate decât s ă fie de un real folos în cazul implement ării solu țiilor
prezentate.
3.1. Schema bloc a aplica ției
Pentru o mai bun ă înțelegere a func ționării sistemului s-a realizat reprezentarea
din figura 3.1.1., care cuprinde in principiu blocurile componente ale aplica ției și modul
în care acestea interac ționeaz ă.
Figura 3.1.1. Schema bloc a aplica ției AUTENTIFICARE
PAGINA
ECHIPAMENTROOT GUEST
Lansarea
unui nou
proces de
monitorizaReprezentari grafice și
tabelare ale
informa țiilor despre
convorbiriAdaugare de noi
utilizatori
Și acordarea
drepturilor specificeMonitorizarea
utilizatorilor
Procese ce colecteaz ă datele de la
echipamente
GSM
Gateway
Punjabi GSM
Gateway
FrankfurtGSM
Gateway
Londra Router de
acces …
Monitorizarea echipamentelor de telecomunica ții
27Primul bloc care apare este cel de autentificare, acesta va lua pe decizii pe baza
numelui utilizatorului în ce grup poate s ă îl încadreze și ce func ționalit ăți poate s ă îi
pună la dispozi ție. Avem de a face cu trei tipuri de utilizatori:
• utilizatori cu drepturi de root – ace știa au dreptul s ă monitorizeze toat ă
activitatea din sistem și să defineasc ă noi utilizatori
• utilizatori proprietari de echipamnet – ace știa au dreptul de a monitoriza
doar echipamentele care sunt proprietatea lor, și pot defini noi
echipamente ce vor s ă le monitorizeze
• Utilizatori f ără drepturi – acestor nu li se permite conectarea în sistem
furnizându-li-se un mesaj c ă nu au drept de acces.
3.2. Func țiile sistemului
Aplica ția are menirea de a furniza un mod de acces de la distan ță la echipamente
de telecomunica ții. Pentru acesta aplica ția trebuie s ă aib ă anumite caracteristici și să
implementeze anumite func ționalit ăți.
În primul rând trebuie s ă implementeze comunicarea utilizator-echipament.
Deoarece se dore ște accesul de la distan ță la procese industriale (echipamentele de
telecomunica ții putând fi considerate procese industriale) este necesar ă crearea unei
interfe țe de comunicare între utilizator și proces care s ă îi permit ă utilizatorului
vizualizarea parametrilor procesului într-o manier ă în care acesta s ă nu necesite a fi
instruit și a avea cuno științe tehnice avansate în domeniul calculatoarelor. S ă ne
încipuim ce ar însemna ca utilizatorul s ă aib ă acces la proces prin intermediul unei
sesiuni telnet pe portul 1026 și ar trebui ca odat ă conectat s ă trimit ă câteva zeci de
comenzi pentru a vizualiza parametri de stare în format text și alte câteva zeci de
comenzi pentru a putea comanda procesul. Noi dorim prin modul în care am gândit
aplica ția să elimin ăm astfel de inconveniente, utilizatorul având acces la reprezent ări
grafice ale parametrilor de stare printr-o simpl ă apăsare a unui buton și cum se știe
reprezent ările grafice pot gr ăbi și influen ța luarea deciziilor corecte.
Odat ă realizat ă primul obiectiv apare întrebarea cine are acces în sistem
deoarece nu putem permite oricui acceseaz ă să poat ă accesa informa țiile furnizate și de
aceea se impune implementarea altei func ții importante a sistemului și anume a aceleia
Monitorizarea echipamentelor de telecomunica ții
28de securitate. Pentru acest lucru fiecare utilizator va trebui s ă fie identificat printr-un
nume și o parol ă de acces, precum și implementarea și urm ărirea unor politici de
securitate care s ă monitorizeze încerc ările de conectare frauduloas ă și modul în care
utilizatorii î și folosesc drepturile de acces în sistem și își iau m ăsuri de securitate.
3.3. Interfa ța cu utilizatorul
Dup ă cum am explicat și în paragraful anterior s-a încercat realizarea unei
interfe țe „prietenoase” prin care utilizatorul s ă acceseze informa țiile. Pentru a
implementa o astfel de solu ție s-a ales ca accesul utilizatorului la procese s ă se realizeze
prin intermediul unei interfe țe web, deoarece acesta perimite o flexibilitate destul de
mare și nu necesit ă, în principiu, ca utilizatorul s ă fie instruit în prealabil.
Utilizatorul trebui s ă interac ționeze la accesul în sistem pentru prima dat ă cu
fereastra de dialog folosit ă pentru autentificare, aici el trebui s ă își introduc ă datele dup ă
care el este recunoscut ca fiind utilizator cu drepturi în sistem. Dup ă ce procesul de
autentificare ia sfâr șit utilizatorului i se va afi șa o pagin ă de unde poate alege care din
echipamentele asupra c ărora are drepturii dore ște să îl monitorizeze sau s ă adauge un
nou echipament ce dore ște a fi monitorizat. Aici informa țiile sunt prezentate atît în
form ă tablear ă cât și grafic. Utilizatorul având posibilitatea s ă își aleag ă modul în care
dore ște să vizualizeze parametri de stare.
Monitorizarea echipamentelor de telecomunica ții
293.4. Structuri de baze de date și fișiere
Aplica ția con ține mai multe fi șiere cu cod surs ă o parte sunt procesate cu
ajutorul serverului de web și interpretorului PHP, iar o parte sunt compilate și lansate în
execu ție la intervale de timp bine stabilite cu ajutorul crontab-ului. Pentru a asigura o
bună func ționare a aplica ției acestea trebuie s ă respecte urm ătoarea structur ă de
directoare, pornind din r ădăcina serverului de web:
Figura 3.4.1 Structura de organizare a fi șierelor
În directorul img vor fi stocate imaginile care apar pe paginile utilizatorului și
care sunt folosite pentru a crea o interfa ță „prietenoas ă”. Trebuie acordat ă aten ție
acestor imagini depoarece dat fiind faptul c ă aceste fi șiere vor fi livrate prin intermediul
unei conexiuni web ele trebuie s ă respecte anumite restric ții. Cea mai important ă dintre
restric ții estea cea de dimensiune, pentru a asigura o înc ărcare rapid ă a paginilor f ără a
influen ța func ționarea este indicat ca imaginile s ă nu dep ășeasc ă 50k.
În directorul procese se vor afla aplica țiile ce realizeaz ă conexiune la
echipamente și extrag informa țiile utile.
În directorul root se afl ă fișierele cu cod surs ă care sunt utilizate pentru a realiza
interfa ța cu utilizatorul cu drepturi de root.
În directorul user se afl ă stocate fi șierele ce con țin codul surs ă necesar realiz ări
interfe ței cu utilizatorul proprietar al echipamentului. Aici exist ă și un subdirector
grafice (user/grafice ) în care se vor salva de c ătre serverul de web reprezent ările grafice
cerute de utilizator, acestui director trebuie s ă îi acord ăm aten ție în cazul în care vom
implementa solu ția prezentat ă într-un sistem unix sau linux, deoarece utilizatorul
sistemului de operare www (în unele cazuri httpd sau apache ) trebuie s ă aibă drepturi de
scriere în acest director.
Monitorizarea echipamentelor de telecomunica ții
30Baza de date care asigur ă func ționare sistemului are urm ătoarea structur ă (figura
3.4.2):
Figura 3.4.2. Structura bazei de date
Deoarece MySQL nu permite în versiunile curente folosirea cheilor str ăine
legăturile dintre tabele sunt figurate în scopul de a ar ăta cum interac ționeaz ă între ele
tabelele bazei de date.
3.5. Analiza de risc
Aplica ția ofer ă o serie de avantaje, acestea pot influen ța decizia în ceea ce
prive ște implementarea ei într-un sistem real, dar în acela și timp implic ă și o serie de
riscuri în ceea ce prive ște securitatea și stabilitatea. Dac ă pân ă acum am vorbit în primul
rând despre avantajele acesteia și modului cum acestea por fi implementate și exploatate
ar trebui ca acum s ă acord ăm un scurt spa țiu prezet ării riscurilor pe care le implic ă
aceasta.
Vom porni discu ția despre riscurile implicate de la riscurile pe care trebuie s ă ni
le asum ăm în momentul în care dorim s ă conect ăm un echipament în internet. Odat ă
conectat la re țeau internet acesta este expus atacurilor de diferite tipuri și de aceea este
Monitorizarea echipamentelor de telecomunica ții
31foart important ă, în cazul nostru alegerea sistemului de operare și a serverului de web
care vor fi direct expuse acestor atacuri. În alegerea acestora pe lâng ă faptul c ă trebuie
să alegem produse stabile și testate trebuie de asemnea s ă ne implic ăm în monitorizarea
acestora și abonarea la diferite liste de discu ții care abordeaz ă teme legate de bug-urile
apărute. De exemplu atunci când întrebi un administrator de sistem pe ce fel de sistem
de operare ar trebui s ă instalezi pe un server web și ce server de web s ă folose ști, acesta
îți va recomanda în cele mai multe cazuri ca și sistem de operare s ă folose ști OpenBSD,
iar ca și server web s ă folose ști Apache. Chiar dac ă vei folosi cele mai stabile și „mai
sigure” produse nu ai garan ția că acestea nu î ți vor crea probleme în cazul unor atacuri
(de exemplu OpenBSD 3.1 are un bug în sshd care poate fi exploatat de un hacker astfel
încât s ă obțină drepturi de root pe sistemul respectiv și cu toate c ă a fost unul dintre cele
mai sigure sisteme de operare totu și sistemul poate fi distrus dac ă nu se iau m ăsurile
necesare în prealabil care în cazul exemplului nostru ar fi instalarea unei versiuni mai
noi de ssh).
Deoarece am prezentat patru modele de arhitectur ă a aplica ției trebuie s ă
men ționăm c ă în cazul primelor dou ă modele pe lâng ă problemele de securitate ale
sistemului de operare și serverului web componenta cu riscul cel mai ridicat este totu și
serverul de baze de date. Func ționarea defectuas ă a acestuia poate duce la pierderea
comunic ării cu echipamentele (ceea ce în cazul folosirii infroma țiilor furnizate de
aceast ă aplica ție pentru taxare poate avea efecte dezastruaoase), de aceea în urm ătoarele
modele de arhitectur ă s-a încercat eliminarea acestor inconveniente și au fost utilizate
mai multe servere de baze de date aflate pe echipamente de calcul diferite, iar în cel de-
al patrulea model s-a încercat și implementarea unei solu ții de back-up pentru cazul
defect ării serverului de web.
3.6. Planificaea lucr ărilor
Trebuie realizat ă încă de la început o analiz ă atent ă a necesit ăților hardware de
care va avea nevoie sistemul pentru o func ționare corect ă. În func ție aceste necesit ăți se
pot alege una dintre cele patru modele de arhitectur ă prezentate în paragraful 4.1. În
alegerea arhitecturii trebuie avut în vedere faptul c ă pe parcursul unei singure zile
printr-un echipament de tip GSM Gateway au loc aproximativ 100.000 de convorbiri și
deci necesit ățile de memorie și procesor ale serverului de baze de date cresc pe m ăsură
Monitorizarea echipamentelor de telecomunica ții
32ce num ărul de echipamnete monitorizate cre ște, de asemenea și aplica țiile care
realizeaz ă monitorizarea au la rândul lor necesit ăți de procesor și de conectare la re țea
destul de ridicate, într-o singur ă oră un echipament transmite informa ții despre
convorbiri și parametrii s ăi de stare de aproximativ 2 MB.
Dup ă alegerea modelului de arhitectur ă și a politicilor de securitate trebuie trecut
la instalarea aplica țiilor componente care asigur ă func ționarea sistemului, aici este
vorba de serverul de web Apache, serverul de baze de date MySQL și a PHP-ului
opera ții ce sunt prezentate în capitolul 6.
Urmeaz ă ca apoi realizarea și implementarea aplica țiilor ce colecteaz ă datele de
la echipamente, a interfe ței cu utilizatorul opera ții descrise în capitolul 4 și prezentate în
Anexa 2, precum și realizarea tabelelor componente ale bazei de date (Anexa 1).
Dup ă realizare acestora pa și trebuie acordat ă o foarte mare aten ție pasului de
testare a aplica ției pentru a elimina orice eroare și a interac ționa cu sistemul pentru a
putea observa și corecta situa țiile neprev ăzute în faza de proiectare.
Dup ă terminarea test ării aplica ția trebuie s ă fie dat ă în folosin ță dar în prima
fază utilizatorii trebuie monitoriza ți și trebuie asigurat un serviciu de support pentru ca
aceștia s ă se poat ă adapta cât mai repede și a exploata sistemul în cele mai bune
condi ții.
Monitorizarea echipamentelor de telecomunica ții
33 Capitolul 4. Proiectarea de detaliu
4.1. Arhitectura aplica ției
Aplica ția poate fi configurat ă în mai mule arhitecturi func ționale, în cele ce
urmeaz ă sunt prezentate patru modele de arhitecturi. Primele dou ă sunt func ționale f ără
modific ări asupra codului și a bazelor de date, celelalte dou ă necesit ă mici modific ări, în
principiu aceste modific ări nu au loc asupra codului existent ci presupun extinderea lui
cu noi func ționalit ăți.
Comunicarea dintre procese și utilizator se realizeaz ă cu ajutorul unei baze de
date pentru primele dou ă modele, iar pentru celelalte exist ă mai multe baze de date prin
care se poate realiza comunicarea. În ambele cazuri sunt stocate datele furnizate de
echipamente pe o perioad ă mai lung ă, cu ajutorul acestor date se pot realiza reprezent ări
grafice care s ă ajute în luarea unor decizii și se pot realiza opera ții de plat ă între
operatorii proprietari ai echipamentelor. În cazul implement ării noastre monitorizarea
unui echipament porne ște la maximum un minut de la salvarea datelor despre acesta
(adresa IP și denumirea) în baza de date.
Pentru toate arhitecturile avem nevoie de un singur server de web, instalat cu
suport pentru PHP, deoarece acesta realizeaz ă interfa ța cu utilizatorul și cu ajutorul
codului PHP se pot realiza conexiuni la baze date aflate pe alte servere de baze de date.
În cazul utiliz ării ca și SGBD a MySQL-ului pentru acesta exist ă implementate func ții
de conectare în PHP care asigur ă performan țe ridicate la conectare și realizarea
interog ărilor. De asemenea MySQL-ul ofer ă biblioteci de func ții C pentru conectare
ceea ce d ă posibilitatea ca aplica țiile care preiau datele de la proces și comunic ă cu
acesta s ă poat ă fi scrise în C.
Primele dou ă modele sunt sensibile la atacuri din internet și pot duce la
pierderea controlului asupra monitoriz ării echipamentelor ceea ce este un mare
dezavantaj, în celelalte dou ă modele se pierde pentru un interval de timp monitorizarea
datelor, dar acestea ajung în baza de date și pot fi utilizate mai târziu în opera țiile de
taxare, iar cel de al patrulea mode prezint ă o solu ție de back-up în cazul unor astfel de
atacuri.
Monitorizarea echipamentelor de telecomunica ții
344.1.1. Serverul și procesele aflate pe acel și calculator
Figura 4.1.1 Primul model de arhitectur ă penturu aplica ție
Aceast ă arhitectur ă are avantajul de a fi foarte simpl ă și a nu necesita investi ții
mari în hardware. Serverul de web și serverul de gestiune a bazelor de date se afl ă
instalate pe acela și computer unde ruleaz ă și aplica țiile care realizeaz ă interfa ța dintre
echipamente și baza de date. Dac ă aceste aplica ții necesit ă o putere mare de calcul
atunci cre șterea performan țelor echipamentului hardware pe care acestea ruleaz ă poate
implica trecerea la modelul 2 deoarece în general se dovede ște a fi o solu ție ieftin ă și
viabil ă.
Aplica țiile de interfa țare cu echipamentele stocheaz ă informa țiile despre
convorbiri în SGBD-ul local. De asemenea comenzile de pornire a unui nou proces de monitorizare sunt prelucrate prin intermediul bazei de date locale și a procesului cron de
pe server.
Server Web
Configurat cu
suport PHP
Proces 1
Proces 2
Proces n …Server și
calculator de
proces Utilizato r
Server
BD
Monitorizarea echipamentelor de telecomunica ții
35 Marele dezavantaj al acestei arhitecturi este acela c ă este extrem de sensibil ă la
atacuri din internet, în cazul în care este direct conectat ă la internet. Aceste atacuri nu
numai c ă pot duce la pierderea contactului dintre utilizator și proces, dar pot merge pân ă
la oprirea întregului echipament hardware ceea ce ar duce la pierderea comunic ării cu
echipamentele.
4.1.2. Server și calculatoare de proces
Acest al doilea model este recomandat în cazul în care aplica țiile de interfa ță cu
echipamentul necesit ă o putere de calcul mare, în acest model ele fiind distribuite pe
mai multe calculatoare dedicate (denumite în figura de mai jos, „calculatoare de procces”).
Fiecare calculator de proces realizeaz ă interfa ța cu echipamentul asociat și
realizeaz ă prelucr ările primare asupra datelor pe care le furnizeaz ă acesta, dup ă care se
conecteaz ă la SGBD-ul unde se afl ă baza de date cu parametri de stare ai procesului și
stocheaz ă aceste date. Acest al doilea model este inspirat în special de faptul c ă
respectivele echipamente furnizeaz ă informa ție care nou ă nu ne este în acest moment
utilă și de aceea rularea tuturor aplica țiilor de monitorizare de pe acela și sistem ar
consuma o mare parte din band ă de re țea disponibil ă. De aceea aplica ția care realizeaz ă
comunicarea cu echipamentul se va afla instalat ă pe un calculator aflat în re țeaua local ă
unde se afl ă și acesta conectat, va procesa datele și le va transmite la SGBD în timp real
sau la intervale de timp bine stabilite.
Aceast ă arhitectur ă prezint ă la rândul ei unele dezavantaje, dintre care cel mai
important este aceea și sensibilitate ridicat ă la atacurile provenite din internet, atacuri
care la fel ca și în cazul primei arhitecturi pot duce la întreruperea func ționării
sistemului fapt ce poate avea consecin țe catastrofale. Un alt punct sensibil este faptul c ă
dacă avem nevoie de calculatoare de proces dedicate fiec ărui proces, deci vor cre ște
costurile implicate punerii în func țiune a aplica ției. Odat ă ce are loc cre șterea
echipamentelor ce vor fi monitorizate vom avea de stocat foarte multe informa ții
referitoare la convorbiri în baza de date care poate genera probleme în func ționare. Cu
toate c ă documenta ția aferent ă serverului de baze de date MySQL spune c ă acesta poate
să func ționeze în condi ții optime cu un num ăr de înregistr ări care este de ordinul
milioanelor acest lucru este perfect adev ărat în cazul în care avem de-a face cu aplica ții
de tip eviden ță economic ă sau cataloage de produse pentru c ă în acest caz utilizatorul
Monitorizarea echipamentelor de telecomunica ții
36uman nu va fi afectat de ace ști timpi pe când în cazul unor procese industriale ace ști
timpi devin critici și pot duce la sincope în func ționarea întregului ansamblu, pentru a
evita aceast ă problem ă s-au gândit înc ă dou ă arhitecturi de aplica ții care vor elimina pe
cât posibil aceste neajunsuri.
Figura 4.1.2 Al doilea model de arhitectur ă penturu aplica ție
Distribuirea proceselor nu necesit ă modific ări asupra codului, doar parametri de
conectare la baza de date sunt al ții. Dac ă în primul caz pentru conectare foloseam ca și
adres ă localhost în cadrul scripturilor ce simulau procesele în acest caz vom folosi ca și
adres ă adresa serverului unde se afl ă serverul de baze de date. Ace ști parametri pot fi
stoca ți într-un fi șier de configurare a aplica ției, la pornire acestea citesc ace ști parametri
parametri și vor putea realiza în mod normal conectarea la server.
Calculator
Proces n
Server Web
Configurat cu
suport PHP
…Server Web și
baze de date Utilizato r
Server
BD
Calculator
Proces 1
Calculator
Proces 2
GSM G. 1 GSM G. 2 GSM G. n …
Monitorizarea echipamentelor de telecomunica ții
37Calculatoarele de proces nu este necesar, și nici nu este indicat s ă aibă adrese de
rețea publice. Este recomandat ca ele s ă aib ă adrese IP private și să se afle conectate
într-o re țea privat ă cu serverul, iar acesta s ă aibă dou ă adaptoare de re țea, una cu adres ă
IP public ă și una cu adres ă IP privat ă din aceea și rețea privat ă cu cea a calculatoarelor
de proces. De asemenea se poate folosi un router care s ă realizeze o translatare static ă a
adresei IP private a serverului într-o adres ă IP public ă. Aceste dou ă scenarii de
configurare, în special cel de al doilea nu fac decât s ă sporeasc ă securitatea sistemului
prin protejarea calculatoarelor de proces la atacuri din internet.
Pot fi imaginate politici de securitate de tip firewall, dar acest subiect poate fi el
singur tema unei lucr ări, de aceea nu vom insista foarte mult pe aceast ă tem ă ci vom
prezenta acolo unde consider ăm necesar idei care apoi pot fi extinse în cazul unei
implement ări viitoare.
Monitorizarea echipamentelor de telecomunica ții
384.1.3. Servere de baze de date distribuite
Acest model este mult mai complex și necesit ă mici modific ări aduse aplica ției,
în special distribuirea tabelelor asociate fiec ărui echipament pe mai multe servere de
gestiune a bazelor de date, implementare unui nou tabel care s ă stocheze aceast ă
distribu ție.
Figura 4.1.3. Al treilea model de arhitectur ă a aplica ției
Calculator
Proces n …
Calculator
Proces 1
Calculator
Proces 2
GSM G 1 GSM G 2 GSM G n …
Server Web
Configurat cu
suport PHP Server Web
și baza de
date
autentificare Utilizator
Server BD
autentificare
SGBD
dedicat
procesului 1 SGBD
dedicat
procesului 2SGBD
dedicat
procesului n …
Monitorizarea echipamentelor de telecomunica ții
39Acest model pe lâng ă cre șterea complexit ății, care implic ă și costuri dedicate
echipamentelor hardware asociate, elimit ă în mare parte neajunsurile celorlalte dou ă
modele. În primul rând cre ște gradul de securitate, deoarece în cazul unor atacuri din
internet se pierde doar leg ătura dintre utilizator și informa ție nu și comunicarea dintre
echipamente și baza de date, fapt ceea ce poate asigura buna func ționare a proceselor
până legătura cu utilizatorul se restabile ște. Un alt mare avantaj este acela ca bazele de
date asociate fiec ărui echipament sunt distribuite pe mai multe SGBD-uri ceea ce ne
asigu ă că nu va mai exista o supraînc ărcare a unui SGBD. Ca în orice sistem care aduce
unele avantaje exist ă bineân țeles și unele dezavantaje datorate modului ceva mai
complicat în care se vor realiza extragerile de informa ție necesar ă utilizatorului, fiind
necesare noi tabele care s ă stocheze leg ătura dintre utilizator – SGBD – echipament.
În func ție de complexitatea proceselor care trebuie conduse serverele de baze de
date se pot afla pe calculatorul de proces sau pe calculatoare diferite. Sistemul poate fi
mixt, anumite calculatoare de proces g ăzduiesc atât SGBD-ul cu baza de date asociat ă,
iar pentru altele acestea se afl ă pe dou ă calculatoare diferite. Aceste modific ări nu
afecteaz ă cu nimic func ționarea și nu necesit ă modific ări în software, ci doar
configurarea aplica țiilor ce realizeaz ă interfa ța dintre proces și baza de date cu adresa
SGBD-ului asociat, dac ă se afl ă pe acela și calculator se folose ște localhost , iar dac ă se
află pe calculatoare diferite se vor configura cu adresa IP a calculatorului unde se afl ă
SGBD-ul asociat.
4.1.4. Servere de baze de date distribuite și server web de siguran ță
Acest al patrulea model este cel mai complex dintre toate și pe lâng ă facilit ățile
celui prezentat mai sus (al treilea model) încearc ă să ofere o solu ție pentru cazul unor
atacuri din internet. Pentru aceasta, pe o alt ă conexiune internet cu o adres ă ip public ă
din alt domeniu de adrese, se configureaz ă și instaleaz ă un server de web cu suport PHP
și cu o baz ă de date de autentificare, ce va con ține la rândul ei to ți utilizatorii care au
drepturi în sistem și procesele asociate lor. În cazul unor atacuri asupra primului server
web utilizatorul va avea la dispozi ție un al doilea canal de acces pentru a putea asigura
monitorizarea echipamentelor.
Acest model mai poate oferi de exemplu o solu ți în cazul în care avem de a face
cu un num ăr foarte mare de utilizatori și echipamente. Se poate limita num ărul
utilizatorilor care au acces pe un server, iar ceilal ți vor putea utiliza cel ălalt server.
Monitorizarea echipamentelor de telecomunica ții
40Astfel nici unul dintre cele dou ă servere nu va fi supraânc ărcat și va putea furniza date
utilizatorului în timp mult mai scurt. Acest lucru este important, deoarece în cazul nostru serverul proceseaz ă scripturi PHP care realizeaz ă conexiuni la una sau mai multe
baze de date și deci timpul lui de r ăspuns cre ște considerabil.
Figura 4.1.4. Al patrulea model de arhitectur ă a aplica ției
Calculator
Proces n …
Calculator
Proces 1
Calculator
Proces 2
GSD G 1 GSM G 2 GSM G n …
Server Web
Configurat cu
suport PHP Servere Web
și baze de
date
autentificare Utilizator
Server BD
autentificare
SGBD
dedicat
procesului 1 SGBD
dedicat
procesului 2SGBD
dedicat
procesului n …
Monitorizarea echipamentelor de telecomunica ții
41Interfa ța dintre echipament și bazele de date r ămân nemodificate. Singurele
modific ări care se cer a fi f ăcute sunt de a permite ca modific ările utilizatorilor și
proceselor asociate s ă fie realizate simultan, pentru a permite utilizatorilor și acesul cu
ajutorul celuilalt server, fie c ă acesta va func ționa ca o solu ție de siguran ță sau pentru a
evita supraînc ărcarea.
4.2. Descrierea componentelor
4.2.1. Conectarea și interogarea bazei de date
Comunicarea dintre echipamente și utilizator se realizeaz ă cu ajutorul serverului
de baze de date, pentru a putea reailza aceste comunic ări va trebui s ă realiz ăm o
conexiune la baza de date și să fim capabili s ă interog ăm tabelele acesteia. Pentru
MySQL exist ă func ții implementate care realizeaz ă acest lucru atât în PHP cât și în C.
Vom prezente în contrinuare aceste func ții, pentru PHP și pentru câteva func ții de
asemenea și pentru C, împreun ă cu modul în care le-am utilizat ân cadrul aplica ției
practice (vezi Anexa 2). Pentru a putea realiza interogarea trebuie ca mai întâi s ă avem o conexiune cu
serverul de baze de date deschis ă. Pentru a ini ția o conexiune se folos ște func ția:
• PHP: resource mysql_connect ( [string server [, string username [, string
password [, bool new_link [, int client_flags]]]]])
o server – adresa calculatorului unde se afl ă serverul MySQL,
o username,password – datele utilizatorului care interogheaz ă baza de date,
o new_link – specific ă faptul c ă de fiecare dat ă trebuie deschis ă o nou ă
legătură cu baza de date, parametrul este op țional,
o client_flags – poate lua una din valorile: MYSQL_CLIENT_SSL,
MYSQL_CLIENT_COMPRESS, MYSQL_CLIENT_IGNORE_SPACE
sau MYSQL_CLIENT_INTERACTIVE.
• C: MYSQL *mysql_real_connect(MYSQL *mysql, const char *host, const char
*user, const char *passwd, const char *db, unsigned int port, const char *unix_socket, unsigned int client_flag)
o primul parametru este adresa unei structuri MYSQL care trebuie mai
întâî ini țializat ă cu ajutorul func ției mysql_init,
Monitorizarea echipamentelor de telecomunica ții
42o urm ătorii trei parametrii sunt identici cu cei ai func ției de conectare din
PHP,
o db – reprezint ă baza de date asupra c ăreia dorim s ă realiz ăm interog ări,
o port – reprezint ă protul pe care dorim s ă inițiem conexiunea (în general
0),
o unix_socket – socketul care va trebui folosit,
o client_flags – CLIENT_SSL, CLIENT_COMPRESS,
CLIENT_IGNORE_SPACE sau CLIENT_INTERACTIVE.
Dup ă realizarea conexiuni, cel pu țin în PHP, avem mai multe func ții cu ajutorul
cărora putem interoga baza de date (vezi Anexa 2). Putem mai întâi cu ajutorul unei
func ții să select ăm baza de date curent ă și apoi s ă interog ăm aceast ă baz ă de date cu
ajutorul altei func ții sau s ă realiz ăm am ăndou ă opera țiile cu ajutorul unei singure func ții
prezentate mai jos:
• PHP: resource mysql_db_query ( string database, string query [, resource
link_identifier])
o database – baza de date asupra c ăreia se realizeaz ă interogarea,
o query – va fi textul interog ării,
o link_identifier – o resurs ă de tip conexiune la serverul MySQL creat ă cu
func ția mysql_connect.
• C : int mysql_query(MYSQL *mysql, const char *query)
Dup ă interogarea bazei de date vom avea ca rezultat o resurs ă care con ține datele
returnate dac ă interogarea a fost de tipul SELECT, pentru a putea opera asupra acestor
date trebui s ă le extragem cu ajutorul uneia dintre func țiile:
• array mysql_fetch_array ( resource result [, int result_type])
• array mysql_fetch_row ( resource result)
o acestea vor primi ca parametru rezultatul interog ării și vor returna câte o
linie din rezultat.
Dup ă ce am realizat extragerea datelor din rezultatul interog ării este indicat s ă
eliber ăm aceast ă resurs ă:
• bool mysql_free_result ( resource result)
În final va trebui s ă închidem conexiunea cu ajutorul func ției:
• bool mysql_close ( [resource link_identifier]).
Monitorizarea echipamentelor de telecomunica ții
43
Ultimele func ții au fost prezentate numai pentru PHP, fiind prezentate numai
câteva dintre func țiile pe care acesta le pune la dispozi ție pentru interfa ța cu MySQL,
pentru o mai bun ă înțelegre a func ționării lor vom încerca s ă exemplific ăm pe o bucat ă
de cod.
//realizam conexiunea (serverul MySQL se afl[ pe calculatorul local, userul este
webuser //si nu are parola
$connect=mysql_connect("localhost","webuser","")or die(“Erroare la conectare”);
//Construim intr-un string interogarea $query="insert into combustibil values ('',now(),$cantitatea,'consum');";
//interogam baza de date, deoarece este o interogare de tipul INSERT nu va trebui sa
//realiz ăm prelucrari asupra rezultatului
mysql_db_query("myproc",$query) or die(„Erroare la interogare(insert)”);
//construim o alta interogare, de aceasta data de tip SELECT
$query="select status from procese where name='motor'";
//de aceasta data vom avea nevoie de o resursa care sa stocheza datele interogarii $result=mysql_db_query("myproc",$query) or die(„Erroare la interogare(select)”);
//extragem prima linie din rezultat list($status)=mysql_fetch_row($result);
// am putea folosi de asemenea $row=mysql_fetch_array($result)
4.2.2. Generearea de reperezent ări grafice
Mai întâi s ă facem cuno ștință cu func țiile de manipulare a imaginilor. PHP pune
la dispozi ție o pleiad ă de func ții pentru desenarea de puncte, linii, poligoane, arce de
cerc, pentru controlul culorii și fonturilor, plus posibilitatea de a înc ărca și salva imagini
în popularele formate GIF (Graphics Interchange Format ), PNG (Portable Network
Graphics ) sau JPEG (Joint Picture Experts Group ). Singura cerin ță este s ă fie instalat ă
biblioteca GD în sistem. Pentru gd-1.6 sau versiuni mai vechi se suport ă numai formatul
GIF, iar pentru versiuni mai recente se ofer ă suport pentru formatul PNG. Prelucrarea
fișierelor în formatul JPEG se va putea realiza dac ă este instalat ă biblioteca j peg-6b . În
Monitorizarea echipamentelor de telecomunica ții
44marea majoritate a cazurilor, aceste biblioteci sunt disponibile în orice distribu ție
actual ă de Linux.
Cele mai utile func ții sunt:
• imagecreate() – va crea o imagine de dimensiuni precizate de programator și va
returna un identificator de imagine, similar identificatorului de fi șier (handler )
returnat de primitivele creat() sau open(). Toate celelalte func ții de prelucrare a
imaginilor vor folosi acest identificator (num ăr întreg).
• imagecreatefromgif() – va crea o imagine pornind de la un fi șier în format GIF
care va fi înc ărcat. Func ția va returna un identificator de imagine în caz de
succes sau 0 în caz de eroare.
• imagecreatefrompng() – ca mai sus, dar se va înc ărca o imagine în format PNG.
• imagecreatefromjpeg() – ca mai sus, dar pentru imagini în format JPEG.
• imagesx() – furnizeaz ă lățimea unei imagini (în pixeli).
• imagesy() – furnizeaz ă înălțimea unei imagini (în pixeli).
• getimagesize() – returneaz ă dimensiunea unui fi șier în format GIF, PNG sau
JPEG, plus l ățimea și înălțimea imaginii con ținută de acesta. Func ția nu necesit ă
prezen ța bibliotecii GD.
• imagetypes() – furnizeaz ă ce tipuri de formate grafice sunt suportate de
versiunea PHP care ruleaz ă pe serverul Web.
• imagesetpixel() – va desena un pixel având o anumit ă culoare la coordonatele
precizate. Punctul de coordonate (0, 0) se consider ă a fi în stânga-sus. Culoarea
va fi un întreg desemnând un identificator de culoare returnat de func ția
imagecolorallocate().
• imageline() – va reprezenta un segment de dreapt ă dat de coordonatele a dou ă
puncte, cu o anumit ă culoare. Pentru a desena linii întrerupte se poate utiliza
imagedashedline().
• imagerectangle() – va desena o form ă rectangular ă.
• imagepolygon() – va desena un poligon; coordonatele punctelor vor fi furnizate
prin intermediul unui tablou.
• imagearc() – va desena o elips ă par țială, aceast ă func ție putând fi folosit ă pentru
reprezentarea și arcelor de cerc.
Monitorizarea echipamentelor de telecomunica ții
45• imagechar() – va insera un singur caracter în cadrul imaginii la coordonatele
specificate, utilizându-se familia de fonturi implicit ă (se pot stabili diferite
dimensiuni de reprezentare). Pentru a desena vertical un caracter se poate utiliza
func ția imagecharup().
• imagestring() – va avea aceea și acțiune ca și imagechar(), dar va fi figurat un șir
de caractere, nu doar un unic caracter. Pentru a reprezenta un șir de caractere
scris vertical vom folosi func ția imagestringup().
• imagefill() – reprezint ă o func ție de umplere cu o anumit ă culoare, pornind de la
coordonatele precizate. Alte func ții înrudite cu aceasta sunt
imagefilledrectangle(), imagefilledpolygon() sau imagefilltoborder().
• imagecolorallocate() – va aloca un identificator de culoare pentru imagine,
pornind de la componentele RGB corespunz ătoare (trei întregi între 0 și 255).
Alte func ții utile sunt imagecolorat(), imagecolorset(), imagecolorexact() sau
imagecolorresolve().
• imagecolordeallocate() – este func ția care va elibera un identificator de culoare
alocat în prealabil de func ția imagecolorallocate().
• imagecolortransparent() – va stabili care culoare va fi considerat ă transparent ă
pentru o anumit ă imagine (util ă pentru generarea de GIF-uri transparente).
• imagecolorstotal() – furnizeaz ă num ărul total de culori ale paletei asociate unei
imagini.
• imageinterlace() – seteaz ă sau inhib ă proprietatea de între țesere (interlace) a unei
imagini.
• imagecopy() – va copia o zon ă dintr-o imagine și o va amplasa în cadrul altei
imagini, posibil la alte coordonate. Pentru a modifica și dimensiunile zonei
copiate (efectul resize ) se poate folosi imagecopyresized().
• imagegif() – reprezint ă imaginea desemnat ă de un identificator de imagine la
ieșirea standard (se trimite direct navigatorului Web) sau o salveaz ă într-un fi șier
stocat în sistemul de fi șiere al serverului Web. Implicit, formatul va fi GIF87a.
Dac ă s-a setat proprietatea de transparen ță prin func ția imagecolortransparent(),
imaginea va fi generat ă în format GIF89a.
• imagepng() – ca mai sus, dar se va salva în formatul PNG.
Monitorizarea echipamentelor de telecomunica ții
46• imagejpeg() – ca mai sus, dar se va salva în formatul JPEG (se d ă posibilitatea
programatorului de a stabili și gradul de compresie, cu pierderi, a imaginii
rezultate).
• imagedestroy() – distruge identificatorul de imagine și elibereaz ă zona de
memorie alocat ă informa țiilor despre aceasta.
Folosind o parte dintre func țiile enumerate mai sus am realizat o reprezentare
grafic ă (o histogram ă) a duratei unei convorbiri pentru un anumit interval de timp,
informa țiile fiind în prealabil extrase din baza de date. Codul surs ă al func ției PHP
(folosind marea parte a func țiilor de manipulare grafic ă descrise mai sus) care realizeaz ă
o reprezentare grafic ă a duratei convorbiririlor într-un anumit interval de timp este
urm ătorul:
//histograma duratei convorbirilor
function gsm_time($gsm,$stat_time){
// cream o conexiune la baza de date
$connect=mysql_connect("localhost","root","") or die ("Error on database connection");
$table="gsm".$gsm;
// pregatim valorile de timp pentru care dorim sa realizam reprezentrarea
$curTime=time();
$statTime=$curTime-60*$stat_time;
$sdate=date("Y-m-d",$statTime);
$stime=date("H:i:s",$statTime);
//echo "$sdate $stime";
// generam textul interogarii in functie de timp
if($stat_time<=360){
$query=" select timePart.pTime,count($table.clength) from $table,timePart where";
$query.="($table.clength<=timePart.pTime) and($table.cdate between '$sdate' and curdate()) and ";
$query.="($table.ctime between '$stime' and curtime()) group by timePart.pTime;";
}else{
$query=" select timePart.pTime,count($table.clength) from $table,timePart where";
$query.="($table.clength<=timePart.pTime) and($table.cdate between '$sdate' and curdate()) ";
$query.="group by timePart.pTime;";
}
//introgam baza de date $result=mysql_db_query("jft",$query) or dir("Query error");
$i=0;
$total=0;
//procesam informatiile obtinute (contorizam pe intervale)
while($row=mysql_fetch_array($result)){
$stim[$i]=$row[0];
if($i==0){
$scalls[$i]=$row[1];
}else{
Monitorizarea echipamentelor de telecomunica ții
47 $scalls[$i]=$row[1]-$total;
}
$total=$total+$scalls[$i];
//echo "<br> $i : $scalls[$i] – $total – time: $stim[$i]";
$i++;
}
if($total==0) die("The system was not recive any call in last $stat_time");
//cream reprezentarea
$im=@ImageCreate(800,400) or die("Unable to create the image");
$today=date("Y-m-d-H:i");
$background_color = ImageColorAllocate ($im,255,255,255);
$text_color = ImageColorAllocate ($im,0,0,0);
ImageString($im, 4,150,380,"Time of call from $sdate $stime until $today",$text_color);
$line_color = ImageColorAllocate ($im,0,0,0);
imageline($im,30,350,780,350,$line_color);
imageline($im,30,20,30,350,$line_color);
imageline($im,25,50,35,50,$line_color);
$text_color = ImageColorAllocate ($im,255,0,0);
imagestring($im,2,10,40,$total,$text_color);
$xpart=750/$i;
$ypart=300/($total);
$ylast=350;
$xlast=30;
$line_color = ImageColorAllocate ($im,255,0,0);
$text_color = ImageColorAllocate ($im,0,0,0);
imagestring($im,1,$last,360,"0",$text_color);
for($j=0;$j<$i;$j++){
$ycur=350-$scalls[$j]*$ypart;
//imageline($im,$xlast,$ylast,$xlast,$ycur,$line_color);
imagestring($im,2,$xlast+$xpart/2,$ycur-15,$scalls[$j],$text_color);
$xcur=$xlast+$xpart;
if($stim[$j]==10 or $stim[$j]==1){
$line_color = ImageColorAllocate ($im,255,0,0);
$stim[$j]=$stim[$j]." s";
}else{
if($stim[$j]==60){
$line_color = ImageColorAllocate ($im,0,0,255);
$stim[$j]=$stim[$j]." s";
}else{
if($stim[$j]==36000){
$stim[$j]="10 h";
}else{
$stim[$j]="3 min";
}
$line_color = ImageColorAllocate ($im,0,255,0);
}
}
Monitorizarea echipamentelor de telecomunica ții
48 imagefilledrectangle($im,$xlast,$ycur,$xcur,350,$line_color);
//imageline($im,$xlast,$ycur,$xlast,$ycur,$line_color);
//imageline($im,$xlast,$ycur,$xcur,$ycur,$line_color);
imagestring($im,1,$xcur,360,$stim[$j],$text_color);
$xlast=$xcur;
$ylast=$ycur;
}
imagejpeg($im,"img/stat$today.jpg");
echo"<center><img src='img/stat$today.jpg'></center>";
Imaginea graficului acestor parametri va fi de dimensiuni 800×400, fiind
figurate și axele de coordonate și valorile minime și maxime pe axa Oy. Rezultatul
acestei fun ții este prezentat mai jos (figura 4.2.1).
Figura 4.2.1 Una dintre reprezent ările grafice realizare pentru parametri de stare
Dup ă cum se observ ă în figur ă avem 10857 de convorbiri cu durat ă 0, 153 cu
durata cuprins ă între 0 și 10 secunde, 630 cu durata între 10 secunde și 1 minut, 744 cu
durata cuprins ă între 1 minut și 3 minute și 1781 cu durata de peste 3 minute pe un
interval de 24 de ore.
Unele apeluri de func ții au fost prefixate de simbolul "@" pentru ca mesajele de
eroare s ă nu fie trimise spre afi șare navigatorului. Posibilele mesaje de eroare vor putea
fi consultate prin intermediul variabilei globale $php_errormsg.
Monitorizarea echipamentelor de telecomunica ții
49Dup ă cum am v ăzut din exemplul de mai sus, utilizarea func țiilor de manipulare
grafic ă puse la dispozi ție de PHP nu prezint ă dificult ăți. De dorit ar fi fost ca
programatorul s ă aibă la dispozi ție și altele, pentru a realiza prelucr ări mai sofisticate de
imagini (de exemplu, modificarea unor propriet ăți precum luminozitatea sau contrastul
ori posibilitatea de a realiza rotiri sau alte transform ări). Dar chiar și așa, PHP ofer ă
câteva instrumente folositoare pentru generarea dinamic ă a imaginilor și salvarea
acestora în diferite formate.
4.2.3. Autentificarea
În cazul nostru accesul la informa ție nu este permis oricui ci doar utilizatorilor
care au acest drept. Pentru a realiza acest lucru trebuie implementat un algoritm de
autentificare care s ă restric ționeze sau s ă interzic ă accesul utilizatorilor care nu au
drepturi asupra proceselor (vezi Anexa 2). Se pot imagina și implementa destul de
simplu diferite niveluri de acces care s ă acorde anumite facilit ăți pentru diferi ți
utilizatori sau se pot defini chiar clase de utilizatori care s ă poat ă avea în „coproprietate”
acela și echipamente. Modul în care am implementat autentificarea permite extrem de
simplu definirea claselor de utilizatori, dar în cadrul implement ării am considerat c ă un
singur utilizator este proprietarul unui proces (figura 4.2.2).
Figura 4.2.2. Principiul de autentificare în sistem Nume Utilizator
Parola
Utilizator și
parol ă valid ă Acces la
pagina
echipamentelorDA
Acces la
pagina
„vizitator” NU
Monitorizarea echipamentelor de telecomunica ții
50 Datele utilizatorului, nume, parol ă și procesul asupra c ăruia are drepturi, se afl ă
stocate într-o baz ă de date, procesul de autentificare presupune în fapt realizarea unei
interog ări în baza de date, dac ă rezultatul este nevid vom avea ca și rezultat procesul
asociat, iar dac ă rezultatul este vid însemn ă ca utilizatorul nu are drepturi asupra nici
unui proces (sau c ă a introdus gre șit datele de autentificare) și i se va permite acces doar
în zona dedicat ă „vizitatorilor”. Dac ă p r i v i m î n a d î n c i m e s c h e m a d e
autentificare figurat ă mai sus cuprinde urm ătoarele etape (figura 5.2.2):
• utilizatorul deschide o conexiune cu serverul de web ;
• acesta îi cere datele pentru autentificare ;
• utilizatorul introduce aceste date și le trimite serverului ;
• serverul cu ajutorul unui script PHP realizeaz ă o interogare asupra bazei de date
;
• în func ție de rezultatul interog ării returneaz ă utilizatorului o anumit ă pagin ă .
Figura 4.2.3. Comunicarea dintre utilizator și server pe parcursul autentificarii
În procesul de autentificare în func ție de importan ța informa țiilor se pot impune
anumite politici de securitate care s ă asigure confiden țialitatea informa țiilor de
autentificare transmise între utilizator și server. Dac ă nu doar informa țiile de
autentificare ci și datele este important s ă nu poat ă fi interceptate și vizualizate
principiul de func ționare se schimb ă putând ajunge pân ă la înlocuirea serverului de web
cu un server proiectat în acest scop care s ă cripteze toate informa țiile pe care le schimb ă
cu programul client.
conexiune http
Cerere autentificare
Date autentificare
(utilizator si parola) Server Web
Apache ce
ruleaz ă scrituri
PHP . Interogare in BD cu
datele utilizatorului
Returneaz ă numele
procesului sau NULL
Răspunde cu pagina procesului sau
pagina „vizitatorilor” (pentru NULL) SGBD
MySQL
Monitorizarea echipamentelor de telecomunica ții
514.2.4. Monitorizarea routerului de acces
Programul realizeaz ă supravegherea tuturor conturilor prezente pe un router.
Acesta extrage IP-ul utilizatorului și contul care este folosit. În aceasta privin ță
programul supravegheaz ă doua tipuri de conexiunii:Telnet și VPN (Virtual Private
Network). În ceea ce prive ște conexiuniile telnet acestea ofer ă informa ții despre user și
despre IP-ul de unde acel user s-a autentificat. Spre deosebire de acestea conexiuniile
VPN ofera înc ă o informa ție, și anume grupul de utilizatori din care face parte user-ul.
Aceste informa ții se pot ob ține dac ă un utilizator se conecteaza cu routeul și execut ă
comanda: debug aaa authentication . În urma execut ării acestei comenzi de fiecare dat ă
când un utilizator se conecteaz ă cu routerul vor fi afi șate informa ții privitoare la acesta.
Pentru a face aceste opera ții programul simuleaz ă o conexiune telenet cu rooterul
executa comanda și filtreaz ă tot ceea ce v-a ap ărea în momentul în care un nou utilizator
se conecteaz ă salvând informa ții referitoare la utilizator, la adresa IP și la grupul din
care face parte userul în cazul în care apare o connexiune VPN. Pentru a simula o
conexiune telnet am implementat o connexiune prin socketi pe portul de telnet, respectiv portul 23. În momentul în care se realizeaz ă aceast ă conexiune și este
acceptat ă routerul transmite programului șirul de caractere “user name”. La primirea
acestui string este trimis ă routerului numele utilizatorului. Urmeaz ă verificarea parolei.
Pentru a intra într-un mediu supervisor este necesar ă transmiterea comenzii: enable care
genereaz ă o nou ă autentificare prin parol ă. În urma acestei autentific ări se execut ă
comanda debug aa authentication . Din acest moment tot ce va ap ărea la consol ă va fi
transmis programului. Conectarea la rooter se realizeaz ă prin intermediul func ției
ConnectIt:
int ConnectIt(void){
/*crearea socketului client*/ if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) { fprintf(fp,"\nSocket creation error\n"); return 0;send(sockfd,USER,sizeof(USER),0);
}
/*intializarile variabilei de conectare*/ the_addr.sin_family = AF_INET; /* host byte o(rest = strstr(buf, "create_user"rder */
the_addr.sin_port = htons(PORT); /* short, network byte order */
the_addr.sin_addr.s_addr = inet_addr(IP);
bzero(&(the_addr.sin_zero), 8); /* zero the rest of the struct */ /*conectarea propriuzisa*/ if (connect(sockfd, (struct sockaddr *)&the_addr,sizeof(struct sockaddr)) == -1){ fprintf(fp,"\nConnection to ip error!\n"); return 0; } return 1;
}
Monitorizarea echipamentelor de telecomunica ții
52Dup ă aceasta urmeaz ă transmiterea de meseaje rooterului privitoare la numele
utilizatorului și parol ă. Acestea sunt realizate prin intermediul func ției MsgSending ce
prime ște ca parametru un întreg indicând ce mesaj trebuie transmis.
Exist ă posibilitatea ca un utilizator s ă se conecteze cu rouerul și să anuleze
comanda prin care se suprevegheaz ă ce utilizatori sunt conectati. De aceea este creat un
proces fiu care va executa aceast ă comand ă la un interval de timp stabilit. Pratic
procesul copil transmite comanda iar apoi “doarme” timp de un minut dup ă aceea
executând iar ăși comanda.
Încă o problem ă care poate ap ărea este referitoare la modul cum se face
deosebirea între o conexiune VPN și una Telnet deoarece aceste informa ții sunt
transmise una dup ă alta sau amestecate în cazul în care conexiunile s-au facut în acela și
timp. O conexiune VPN se identific ă prin existenta unui sir de caractere “ ISAKMP-ID-
AUTH ” care apare numai în acest caz. Dac ă nu apare acesta înseamn ă ca avem de a face if(!fork()){
while(1)
{
sleep(600);
send(sockfd,CMDD,sizeof(CMDD),0); }
} void MsgSending(int type){
switch (type){ c a s e 1 : send(sockfd,USER,sizeof(USER),0);
break;
c a s e 2 : send(sockfd,PWD,sizeof(PWD),0);
break;
c a s e 3 :
send(sockfd,CMDE,sizeof(CMDE),0); break; c a s e 4 : send(sockfd,PWDE,sizeof(PWDE),0); break; c a s e 5 : send(sockfd,CMDT,sizeof(CMDT),0);
break;
}
}
Monitorizarea echipamentelor de telecomunica ții
53cu o connexiune Telnet. Func ția care realizeaz ă acest lucru este ScanRcv și este descris ă
în cele ce urmeaz ă:
Dup ă identificarea tipului connexiunii sunt apelate func țiile VpnScan sau
TelnetScan în func ție de ceea ce furnizeaz ă func ția ScanRcv și sunt extrase datele de
către func ția Extract care prime ște ca parametru un flag ce spune pentru ce fel de
connexiune se extrag datele respectiv dac ă este nevoie s ă fie extras și grupul de
utiliztori.
Progamul mai ralizeaz ă o connexiune cu o baza de date MySql și insereaz ă
aceste date pentru o eventual ă vizualizare a acestora. Fucn ția care face connexiunea cu
baza de date este ConnectDB iar dac ă nu se poate realiza aceast ă conexiune atunci
programul se termin ă. Datele sunt introduse în baza de date prin intermediul func ției
InsertData. Aceasta în caz de eroare avertizeaz ă utilizatorul prin intermediul unui fi șier
log.
4.2.5. Monitorizarea GSM Gatewayului produs de firma MOBILIE
În principiu monitorizarea acestui tip de echipament este extrem de simplu de
realizat: trebuie deschis ă o connexiune pe portul 1026 la acel echipament, iar acesta va
începe s ă trimit ă informa ții referitoare la starea sa și la convorbirile care au loc prin
intermediul lui. Aceste informa ții sunt livrate sub form ă de șiruri de caractere ce
trebuiesc prelucrate, nici m ăcar acest lucru neridicând probleme.
Dup ă prima implementarea a acestei p ărți a aplica ției s-a observat faptul c ă dup ă
câteva ore, uneori minute, de func ționare nu se mai primesc date de la echipament dar
conexiunea r ămâne deschis ă. S-a încercat g ăsirea motivului pentru care datele nu mai
ajung la aplica ție și s-a observat faptul c ă la intervale de timp aleatoare echipamentul
respectiv anun ța că nu o s ă mai trimit ă date, fapt ce se și întâmpla, dar cu toate c ă oprea
transmiterea datelor conexiune r ămânea deschis ă. În concluzie, deoarece acest lucru int ScanRcv(){
if (strstr(buf,VPN)) return 1;
if ((rest = strstr(buf, "create_user")) == NULL)
return 0;
if (strstr(buf,TELNET))
return 2; return 0;
}
Monitorizarea echipamentelor de telecomunica ții
54denot ă un bug în implementarea comunic ării în acel echipament s-a încercat contactarea
firmei produc ătoare pentru corectarea acestui bug. Problema a ap ărut abia dup ă ce s-a
contactat firma produc ătoare, deoarece firma produc ătoare trecuse la o alt ă versiune a
echipamentului se stopase dezvoltarea și îmbun ătățirea vechiului model și deci nu se
mai dorea corectare bug-ului dintr-o versiune mai veche. A șa că a trebuit g ăsită o
solu țuie astfel încât s ă se poat ă totu și colecta informa țiile de la respectivul tip de
echipament. Pentru aceasta solu ția a fost crearea unui proces „fiu” care s ă realizeze
conectare și toate prelucr ările asupra datelor furnizate. Dac ă avea loc o blocare a fiului
procesul p ărinte aflat pân ă în acel moment în a șteptare, se trezea, oprea procesul fiu și îl
repornea. Datorit ă acestui fapt îns ă aplica ția nu poate fi utilizat ă în opera țiile de taxare
deoarece ăn momentul în care se reporne ște procesul fiu se pierd câteva convorbiri, deci
pentru opera țiile de taxare ar însemna introducerea unei erori și deci ar duce la pierderea
de bani.
Dup ă conectarea la echipamentul respectiv – serverul, implementat ă cu ajutorul
unui socket (func ția de conectare fiind identic ă celei din paragraful anterior) sunt trimise
informa ții clientului (aplica ția noastr ă) de tipul:
Pentru aplica ție prezint ă interes doar liniile care au particula „ :AOCR ” la
începutul liniei. Aceste linii reprezint ă informa ția furnizat ă pentru o convorbire ce se
încheie și con țin urm ătoarele informa ții separate prin virgul ă:
• num ărul de telefon de unde are loc apelul,
• num ărul de telefon apelat,
• num ărul de telefon apelat + „00” ca și sufix,
• ziua,
• luna,
• ora,
• minutul,
• secunda,
• durata,
• pozi ția careteli sim (num ărul cartelei) :AOCR11,"","899","",0,0,0,0,0,0,5f,0,0,0,81
:STAT01 12,1,0,1,3 :STAT 1,1,0,1,1,0,0,1,0,0,0,1
:STAT 1,2,0,1,0,0,0,0,0,1,2,1
:AOCR11
,"0795874413" ,"411793866548" ,"0041793866548" ,2,8,1,c,2b,65,10,4a,1,4a,90
Monitorizarea echipamentelor de telecomunica ții
55• linia de transmisie prin care a venit cererea de convorbire,
• placa pe care se afl ă cartele sim
• linia de transmisie prin care este transmis ă convorbirea,
• cauza deconect ării.
Dintre aceste informa ții pentru noi au importan ță durata convorbirii, cauza
deconect ării, pozi ția cartelei sim și primele dou ă câmpuri. Data și timpul nu sunt
utilizabile deoarece și aici firma produc ătoare are unele probleme în software-ul care la
dezvoltat. Aceste informa ții se extrag extrem de simplu utilizând func ția strtok, dup ă
care ele sunt stocate în baza de date și afi șate în modul în care utilizatorul dore ște
(capitolul 6 și anexa 2)
Monitorizarea echipamentelor de telecomunica ții
56Capitolul 5. Realizarea și punerea în func țiune
5.1. Instalarea și configurarea serverului de web Apache
Pentru început, vom instala serverul de web Apache. De și instalarea standard
RedHat include și acest server, noi îl vom reinstala ca și exerci țiu.Vom folosi ultima
versiune disponibil ă, pe care o vom desc ărca de la http://httpd.apache.org/.
Dac ă am instalat în prealabil suportul PHP putem folosi acest model de
configurare, acesta este unul din motivele pentru care este indicat ă compilarea
serverului Apache, pentru a crea un modul de server pentru PHP fapt ce poate duce la creșterea performan țelor.
Acum ar trebui s ă avem noul server Apache compilat și instalat cu suport pentru
PHP. Este necesar ă editarea fi șierul de configurare /etc/httpd/httpd.conf (pentru RedHat,
respectiv /var/www/conf/httpd.conf pentru OpenBSD, respectiv c:\cale-spre-apache\conf\httpd.conf pentru familia de siteme de operare Microsoft) dac ă este nevoie
de facilit ăți suplimentare.
Dac ă dorim s ă plas ăm fi șierele în alt ă loca ție decât cea implicit ă putem este
necesar s ă modific ăm directiva DocumentRoot și să dăm calea spre noua loca ție unde se
vor afla paginile web ce urmeaz ă a fi servite. (exemple: microsoft: DocumentRoot
"C:/web/page/proiect" , Linux: DocumentRoot "/home/web” )
Pentru a reporni serverul, acest lucru este necesar dac ă aducem modific ări
fișierului de configurare:
$ apachectl restart
Va apare un mesaj care spune ca serverul a fost restartat. În acest moment ar
trebui s ă ne putem conecta la server folosind orice browser. De asemenea, putem
verifica dac ă procesele httpd ruleaza folosind comanda: ps –ax | grep httpd , care va
trebui s ă returneze informa ții despre proces, dac ă acesta ruleaz ă. $ tar zxvf apache_versiune.tar.gz
$ cd apache_versiune $ ./configure -prefix=/www -activate-module=src/modules/php4/libphp4.a
$ make
$ make install $ cp src/httpd /usr/sbin/httpd
Monitorizarea echipamentelor de telecomunica ții
57Înainte de a trece la urm ătorii pa și este foarte important s ă discut ăm pu țin și
despre securitatea serverului de web deoarece acesta va fi conectat direct la internet, fiind deci direct expus la atacuri din internet. De asemenea o parte din politicile de securitate vor fi implementate pe server și cor necesita modific ări aduse configura ției
acestuia.
În ordinea importan ței, problemele de securitate pot fi împ ărțite astfel:
• Un atacator poate exploata bug-urile (deficien țele) existente într-un server Web
sau din script -uri, ob ținând acces neautorizat la fi șiere vitale din sistem (fi șiere
de parole, fi șiere con ținând surse de script -uri executate pe server și altele) sau
pentru a de ține controlul total asupra sistemului;
• Informa țiile confiden țiale stocate pe serverul Web ( e.g. baze de date, aplica ții
etc.) pot fi distribuite unor persoane neautorizate;
• Punctele vulnerabile necunoscute ale navigatorului pot permite accesarea de
informa ții private stocate pe ma șina clientului.
Din p ăcate, solu țiile utilizate în mod curent nu pot rezolva toate problemele și,
deseori, sunt contradictorii. De exemplu, pentru reducerea riscurilor de interceptare,
multe organiza ții achizi ționeaz ă servere Web considerate sigure, implementând o
pleiad ă de protocoale de criptare, dar aceste servere necesit ă certificate de autentificare
semnate digital care trebuie actualizate periodic.
Furniz ăm în continuare o serie de sfaturi pentru cre șterea nivelului de securitate
a unui server Web (oricare ar fi acesta):
1. Pe cât posibil, un server Web nu trebuie s ă ruleze alte servicii și să nu accepte
conexiuni de la distan ță (dac ă deserve ște un Intranet); preferabil ar fi ca
daemon -ul de po ștă electronic ă să nu fie opera țional;
2. Serverul Web nu trebuie s ă ruleze sub auspicii de super-utilizator (root în
Unix/Linux). La fel, script -urile CGI (Common Gateway Interface) nu trebuie
executate ca root.
3. Fișierele de configurare și modulele serverului nu trebuie stocate pe o parti ție
care poate fi exportat ă prin NFS c ătre alte ma șini.
4. Permisiunile ata șate fi șierelor de configurare ale serverului Web trebuie setate
și monitorizate cu aten ție.
5. Se va limita sau chiar inhiba execu ția directivelor SSI (Server Side Includes).
Monitorizarea echipamentelor de telecomunica ții
586. Script -urile CGI trebuie plasate într-un singur director (de obicei cgi-bin) și
modific ările lor trebuie monitorizate.
7. În cadrul directorului cgi-bin nu se permite accesul nelimitat. Utilizatorii locali
nu trebuie s ă poat ă instala, edita, șterge sau chiar vizualiza script -uri sau fi șiere
de configurare.
8. Autorii scripturilor (CGI, PHP, ASP sau altele) nu trebuie s ă fac ă publice
sursele programelor lor, mai ales dac ă nu sunt în variante finale, deoarece ele
pot con ține puncte vulnerabile neb ănuite sau bug-uri periculoase.
9. Script -urile nu trebuie s ă poat ă fi preluate prin FTP anonim și nici fi șierele de
configurare ale serverului FTP nu trebuie accesate via WWW.
10. Se va interzice plasarea de la distan ță pe serverul Web a fi șierelor de
configurare (e.g. .htaccess în cazul Apache). Fi șierele jurnal ( log-urile) nu
trebuie s ă poat ă fi accesate de utilizatorii ordinari sau de intru și. Hackerii pot
altera sau distruge informa țiile din aceste fi șiere.
11. Alte m ăsuri, mai extreme, pot fi:
• ștergerea tuturor conturilor care nu sunt necesare;
• inhibarea execu ției sau ștergerea compilatoarelor;
• ștergerea programelor utilitare care nu sunt necesare pentru rularea
sistemului de operare sau a serverului Web.
Pentru a asigura servicii HTTP, serverul Apache trebuie s ă fie instalat în sistem
(în mod uzual, fiind vorba de un pachet RPM în Linux sau de un program executabil .exe în Windows), iar daemon -ul httpd pornit. Apache este un sistem modular, alc ătuit
dintr-un server de baz ă și mai multe module, care sunt înc ărcate dinamic într-un mod
similar cu func ționarea modulelor din nucleul Linux.
Ne vom referi în continuare la modalit ățile de configurare ale serverului Apache
în Linux, aceste configur ări sunt valabile și pentru sistemele Unix și cu modificarea
căilor sunt valabile de asemenea și pentru sistemele de operare din familia Microsoft în
ambele cazuri diferind locul unde se afl ă fișierul de configurare. Fi șierul de configurare
principal este httpd.conf și este localizat de obicei în directorul /etc/. Mai exist ă dou ă
fișiere de configurare, access.conf și srm.conf, care au fost îns ă înlăturate începând cu
versiunea 1.3.4.
Fișierul de configurare con ține câte o directiv ă pe fiecare linie, acestea putând fi
continuate pe linia urm ătoare ad ăugând la sfâr șitul acesteia caracterul "\". Comentariile
Monitorizarea echipamentelor de telecomunica ții
59încep cu caracterul "#" (ca în shell -urile Unix). Directivele din fi șierul principal de
configurare se refer ă la configur ări globale ale serverului. Pentru a aplica anumite
aspecte ale serverului doar unei zone din server, directivele trebuie incluse în cadrul secțiunilor <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location> sau
<LocationMatch>. Acest lucru poate fi realizat și prin plasarea unui fi șier denumit
.htaccess în directorul în care se dore ște modificarea comportamentului serverului,
conținând directivele dorite.
De asemenea, Apache ofer ă posibilitatea de a servi mai multe situri Web
simultan, altfel spus, găzduire virtual ă (virtual hosting ). Directivele pot fi specificate în
cadrul sec țiunii <VirtualHost>, caz în care se vor referi doar la un anumit sit.
Administratorul de sistem are, de asemenea, posibilitatea de a configura fi șierele
jurnal Apache. Serverul genereaz ă dou ă jurnale: primul, localizat în genere în
/var/log/httpd/access_conf, înregistreaz ă cererile de accesare primite de c ătre server, iar
al doilea, localizat de obicei în /var/log/httpd/error_log, memoreaz ă erorile ap ărute în
decursul rezolv ării cererilor (pagini inexistente, erori de conexiune etc.).
În anumite cazuri, este necesar s ă se restric ționeze accesul la anumite
documente, prin intermediul autentific ării prin nume de utilizator și parol ă sau în func ție
de adresa calculatorului clientului Web.
Pentru a realiza autentificarea utilizatorilor, vom parcurge doi pa și:
1. Se creeaz ă un fi șier con ținând numele și parolele utilizatorilor care vor avea
acces la anumite date de pe serverul Web (în particular Apache);
2. Se configureaz ă serverul pentru a seta care resurse vor fi protejate și care sunt
utilizatorii având permisiunea acces ării lor, dup ă introducerea unei parole
valide.
Lista utilizatorilor și parolelor asociate va fi memorat ă într-o manier ă similar ă
fișierului /etc/passwd din Unix. Din ra țiuni de securitate, fi șierul con ținând aceast ă listă
nu va fi stocat în directoarele compuse din documente HTML, ci la o loca ție mai sigur ă
(e.g. în directoarele /usr/local/etc/httpd sau /etc/httpd). În exemplele urm ătoare, vom
numi acest fi șier users, iar pentru a-l manipula vom folosi comanda htpasswd prin care
vom ad ăuga/ șterge utilizatorii dori ți.
Deși parolele sunt criptate, fi șierul de autentificare este unul text, care poate fi
ușor exploatat de persoane r ău-voitoare. R ămâne în responsabilitatea administratorului
sistemului s ă seteze permisiunile de rigoare asupra fi șierului și directorului unde rezid ă.
Monitorizarea echipamentelor de telecomunica ții
60Crearea unui fi șier de autentificare se realizeaz ă prin apelul de mai jos (putem
stabili și modul de criptare, de exemplu MD5 cu op țiunea -m sau SHA cu op țiunea -s):
htpasswd -c /etc/httpd/users lucian
Aceast ă linie ne permite s ă asign ăm sau s ă modific ăm parola unui utilizator,
parola fiind solicitat ă de la intrarea standard. Configurarea serverului se poate realiza fie
prin fi șierul httpd.conf, fie prin .htaccess, indicând o zon ă protejat ă, de obicei în func ție
de directoarele dorite a fi accesate pe baz ă de autentificare. Fi șierul .htaccess va fi stocat
în directorul asupra c ăruia dorim s ă modific ăm comportamentul implicit al serverului
Web (plasarea lui într-un anumit director va avea efect asupra tuturor sub-directoarelor acestuia).
Înainte de a modifica maniera de autentificare prin fi șierul .htaccess,
administratorul serverului Apache va specifica în httpd.conf ca autentific ările s ă se
realizeze via .htaccess. Pentru aceasta, vom insera directiva AllowOverride AuthConfig,
iar fi șierul .htaccess poate avea liniile de mai jos:
• AuthName specific ă zona dorit ă a fi protejat ă și oricare resurs ă din aceast ă zon ă
va fi accesat ă prin intermediul unui nume de utilizator permis și o parol ă (putem
crea mai multe zone partajând acelea și nume și parole).
• AuthType desemneaz ă metoda de autentificare folosit ă de protocolul HTTP
(Basic sau metoda, mai sigur ă, Digest; serverul Apache suport ă metoda Digest
prin ad ăugarea unui modul special).
• AuthUserFile indic ă fișierul de autentificare generat de htpasswd. Autentificarea
se poate institui și pe baza grupurilor de utilizatori, folosindu-se AuthGroupFile.
Utilizatorii permi și vor fi da ți dup ă directiva require. Parametrul valid-user
indic ă faptul c ă orice nume de utilizator prezent în fi șierul furnizat de AuthUserFile
poate accesa resursele protejate, dar putem scrie o serie de nume de utilizatori permi și
(e.g. require user lucian dragos care va permite accesul numai utilizatorilor lucian sau
dragos, desigur dup ă ce s-au introdus parolele corecte). AuthName "zon ă restrictiv ă"
AuthType Basic AuthUserFile /etc/httpd/users
re
quire vali d-user
Monitorizarea echipamentelor de telecomunica ții
61De exemplu, pentru a permite accesul în directorul /Web pe baza autentific ării,
vom plasa fi șierul .htaccess urm ător (în /home/httpd/html/Web presupunând c ă
directorul r ădăcină al sitului Web este localizat în /home/httpd/html/):
Atunci când un utilizator va dori s ă viziteze o pagin ă stocat ă în acel director, va
trebui s ă furnizeze un nume și o parol ă de acces (dac ă numele sau parola nu coincid cu
cele din fi șierul /etc/httpd/users, autentificarea va e șua).
Mecanismul este urm ătorul: la primul acces al unei resurse necesitând o
autentificare, serverul va returna codul 401 ("Unauthorized") și va include în antetul
HTTP un câmp WWW-Authenticate care va con ține schema de autentificare ce trebuie
utilizat ă (de exemplu, Basic) și numele zonei protejate (a șa-numitul realm ). Navigatorul
va cere utilizatorului introducerea unui nume și a unei parole și va realiza o cerere c ătre
server, incluzând și câmpul Authorization care va con ține numele schemei de
autentificare (Basic), plus numele și parola furnizate.
Serverul va realiza verificarea pe baza fi șierului de configura ție sau a fi șierului
.htaccess și în caz de succes va expedia resursa cerut ă browserului. Altfel, va fi trimis
din nou codul 401.
În situa ția în care autentificarea s-a soldat cu succes, iar utilizatorul va dori s ă
vizualizeze o alt ă resurs ă apar ținând acelea și zone protejate, atunci serverul va r ăspunde
cu codul 401 și navigatorul va retrimite, de fiecare dat ă, câmpul Authorization.
Atunci când trebuie autentifica ți mai mul ți utilizatori, se poate folosi un fi șier
specificând autentificarea pe baza unui grup de utilizatori (concept similar grupurilor din Unix). Iat ă un exemplu:
Se va permite accesul oricarui utilizator din grupul webgroup sau admin ori
utilizatorului cu numele webadmin.
Un fi șier de grup const ă din linii desemnând grupurile și membrii acestora,
sintaxa general ă fiind:
grup : utiliz1 utiliz2 … utilizN
De exemplu, putem avea: AuthName "MyProcess"
AuthType Basic AuthUserFile /etc/httpd/users
require valid-user
require group webgroup admin
re
quire user webadmin
webgroup: lucian alin popesc u
admin: socrate fanel
Monitorizarea echipamentelor de telecomunica ții
62
O linie nu poate avea mai mult de 8 kilobytes lungime.
În .htaccess fi șierul de grupuri de utilizatori va fi dat prin AuthGroupFile. De
exemplu, .htaccess ar putea con ține:
Dac ă se furnizeaz ă numele unui utilizator care exist ă în cadrul unui grup, dar
căruia nu i s-a asociat nici o parol ă în fi șierul de autentificare a utilizatorilor, atunci acel
utilizator nu va avea acces în zona restrictiv ă.
În situa ți a î n c a r e n u m ărul de utilizatori cre ște destul de mult, se pot utiliza
metode complementare, precum stocarea informa țiilor de autentificare în baze de date:
fișiere DBM (modulul mod_auth_dbm), DB (mod_auth_db), mySQL (prin
mod_auth_mysql) etc. Autentific ările se pot realiza via Kerberos prin utilizarea unor
module adi ționale în cadrul serverului Apache.
Putem restric ționa folosirea metodelor de interogare HTTP prin intermediul
secțiunii <Limit>:
Astfel, autentificarea se poate realiza în func ție de metodele de acces HTTP.
Dac ă require nu apare între <Limit> și </Limit>, protec ția se va aplica la toate
metodele.
În cazul în care dorim s ă limit ăm restric ția doar la metoda POST, vom putea
scrie în .htaccess urm ătoarele:
Numai utilizatorii lucian sau socrate vor putea realiza o cerere prin metoda
POST, al ți utilizatori (neautentifica ți) vor utiliza alte metode ( i.e. GET). Aceast ă AuthName "Numai pentru utilizatorii procesului"
AuthType Basic
AuthUserFile /etc/httpd/users AuthGroupFile /etc/httpd/webgroup require group webgroup require user lucian
<Limit GET POST PUT>
require valid-user </Limit>
AuthName "POST restrictiv"AuthType Basic AuthUserFile /etc/httpd/users
<Limit POST>require user lucian socrate</Limit>
Monitorizarea echipamentelor de telecomunica ții
63manier ă poate fi adoptat ă la restric ționarea accesului la un script CGI (se permite
metoda GET, dar numai anumi ți utilizatori pot folosi POST).
Accesul la resurse (directoare sau fi șiere) se poate face pe baza adresei IP sau a
domeniului clientului care a formulat cererea de acces. În acest caz, se poate include
între <Limit> și </Limit> (în .htaccess sau în fi șierul de configura ție a serverului
Apache) intervalul de valori ale adreselor IP permise. Cererile de la alte adrese vor fi
rejectate.
De exemplu:
Directiva deny stabile ște adresele sau domeniile care nu au permisiunea de acces
la resurse, iar allow define ște adresele sau domeniile de la care clien ții pot accesa
resursele Web. În exemplu, am specificat un set de adrese IP permise. Ordinea de
verificare a restric țiilor de acces este dictat ă de directiva order.
Dup ă cum am v ăzut mai sus, accesul poate fi restric ționat și pe baza adresei IP
sau domeniului calculatorului client. Putem utiliza, în mod combinat, ambele metode.
Dac ă dorim ca accesul s ă se realizeze fie pe baza domeniilor permise, fie folosind
autentificarea prin nume și parol ă, vom include directiva Satisfy any în fi șierul .htaccess
sau în sec țiunile <Directory>, <Location> ori <Files> ale fi șierului de configurare. Dac ă
apar ambele metode de restric ționare (pe baza adreselor clien ților și pe baza
autentific ării), în mod implicit serverul Web impune s ă fie îndeplinite amândou ă.
În unele cazuri ar fi dorit ca, la apari ția unor erori HTTP, vizitatorii s ă fie
redirecta ți spre anumite documente particulare. Implicit, la o eroare, serverul Web va
transmite navigatorului o pagin ă descriind codul și mesajul de eroare. Putem specifica
să fie transmise alte documente clientului, atunci când survin erori de genul 401
("Unauthorized"), 403 ("Forbidden"), 404 ("Not found") sau 500 ("Server Error"). Pentru aceasta, se pot include în .htaccess liniile de mai jos:
Astfel, atunci când un anumit utilizator va cere o resurs ă inexistent ă, serverul va
trimite documentul not_found.html din directorul /Web. <Limit GET POST PUT>
order deny, allow deny from all allow from 193.231.30.0/24 192.168.0.0/16</Limit>
ErrorDocument 401 /Web/not_auth.html
ErrorDocument 404 /Web/not_found.html
Monitorizarea echipamentelor de telecomunica ții
64Putem folosi, în locul unui document local, un anumit URI (Uniform Resource
Identifier) spre care s ă fie redirectat navigatorul. Aceasta ne permite s ă redirect ăm
automat navigatorul atunci când am mutat definitiv o resurs ă la alt URI (sau în alt
director, aflat pe acela și server). Va trebui s ă introducem în vechiul director un fi șier
.htaccess care s ă cuprind ă urm ătoarele:
Exist ă dou ă metode de implementare a g ăzduirii virtuale: prima bazat ă pe nume
și a doua bazat ă pe adrese IP. Ma șinile virtuale bazate pe adres ă utilizeaz ă adresa IP a
conexiunii pentru a determina ma șina virtual ă corect ă. Astfel, pentru fiecare ma șină
trebuie alocat ă o adres ă IP separat ă. În cazul g ăzduirii virtuale bazate pe nume,
determinarea ma șinii virtuale se face pe baza numelui acesteia. Astfel, mai multe ma șini
pot utiliza aceea și adres ă IP.
Găzduirea virtual ă bazat ă pe nume este mai simplu de implementat, și este recomandat ă
utilizarea acesteia. G ăzduirea bazaz ă pe adres ă trebuie utilizat ă doar într-una din
situa țiile:
trebuie suporta ți clien ți HTTP vechi, care nu recunosc ma șinile virtuale;
sunt necesare conexiuni sigure de tip SSL (Secure Socket Layer);
sunt utilizate sisteme de operare care nu pot diferen ția ma șinile decât dac ă au
adrese IP diferite.
Pentru a utiliza serviciul de g ăzduire virtual ă, trebuie mai întâi stabilite adresa IP
și portul pentru serverul care va accepta cereri pentru respectiva ma șină virtual ă, cu
ajutorul directivei NameVirtualHost. În mod normal, se utilizeaz ă toate adresele IP pe
care le utilizeaz ă httpd (vezi directivele BindAddress și Listen), precum și toate
porturile pe care serverul a șteapt ă cereri (vezi directiva Port), folosind valoarea "*". Se
stabile ște apoi un bloc <VirtualHost> … </VirtualHost>. Ca parametru, <VirtualHost>
trebuie s ă primeasc ă aceea și valoare utilizat ă la directiva NameVirtualHost. Blocul
astfel declarat trebuie s ă con țină cel pu țin directivele ServerName, care s ă primeasc ă
drept parametru numele ma șinii virtuale, și DocumentRoot, care s ă specifice în ce
director se afl ă con ținutul respectivei ma șini. Iat ă un exemplu: <Limit GET POST>
deny from all ErrorDocument 403 /un_alt_director/index.html
</Limit>
Monitorizarea echipamentelor de telecomunica ții
65De asemenea, pentru fiecare ma șină virtual ă pot fi stabilite mai multe nume,
utilizând directiva ServerAlias. Astfel, dac ă se introduce declara ția:
ServerAlias myproces.ro *.myproces.ro
cererile pentru ma șinile din domeniul dragos.ro vor fi rezolvate de ma șina virtual ă
www.myproces.ro. Pot fi folosite caracterele wildcard "*" și "?". Evident, și
înregistr ările DNS (Domain Name System) pentru serviciul named trebuie s ă fie corect
configurate pentru ca adresele *.myproces.ro s ă poat ă fi rezolvate.
Pentru utilizarea acestui tip de g ăzduire, ma șina trebuie configurat ă fie pentru a
avea mai multe conexiuni fizice la re țea, fie pentru a avea mai multe interfe țe virtuale,
având adrese IP diferite.
Serverul Apache poate fi configurat în dou ă moduri:
• să execute câte un daemon pentru fiecare ma șină virtual ă. Pentru aceasta, se
utilizeaz ă directiva Listen pentru a stabili ce adres ă IP va fi asociat ă
daemonului;
• să execute un singur daemon pentru toate ma șinile virtuale. Pentru aceasta,
se utilizeaz ă directiva VirtualHost descris ă mai sus.
5.2. Instalarea și configurarea suportului pentru PHP
Dac ă pentru serverul de web Apache și serverul de baze de date MySQL exist ă
distribu ții gata compilate și instalarea lor poate fi redus ă la instalarea acelor distribu ții și
realizarea câtorva modific[ri ]n fi;ierele de configurare, în cazul PHP-ului lucrurile sunt
puțin diferite. Cu toate c ă exist ă distribu ții ale PHP-ului gata compilate pentru
majoritatea sistemelor de operare acestea nu includ toate modulele de care se întâmpl ă
să avem nevoie (de exemplu pentru OpenBSD 3.1 exist ă pachete cu PHP gata compilat
nici unul dintre acestea nu con ține suport atât pentru MySQL cât și pentru gd, deci nu
vom putea folosi aceste pachete care s ă ne permit ă să interog ăm o baz ă de date și să
creăm reprezent ări grafice) singura solu ție care ne r ămâne în acest caz este s ă compil ăm NameVirtualHost *
<VirtualHost *>
ServerName www.myproces.ro
DocumentRoot /usr/web/diploma
</VirtualHost>
Monitorizarea echipamentelor de telecomunica ții
66PHP-ul din sursele puse la dispozi ție la adresa: http://www.php.net/downloads.php.
Pentru a putea realiza reprezent ări grafice trebuie s ă avem o distribu ție de PHP>= 4.1.2
precum și să instal ăm în prealabil și distribu țiile gd, jpeg6b. Dup ă ce am dezarhivat
fișierele surs ă ale distribu ției PHP, schimb ăm directorul curent în directorul unde se afl ă
sursele dup ă care execut ăm urm ătoarele opera ții:
Acest model instaleaz ă PHP-ul ca și modul Apache, dac ă se dore ște și crearea
unui executabil php vor trebui repetate opera țiile de mai sus dar far ă opțiunea –with-
apxs. În general este nevoie de acest executabil pentru scripturi php care ruleaz ă direct
pe server sau care ruleaz ă în crontab (în cazul nostru pentru simularea proceselor).
Dup ă aceea va trebui copiat fi șierul de configurare php.ini în directorul /etc (în
cazul Microsoft acesta se copiaz ă în c:\windows sau c:\winnt ) și realizarea câtorva
modific ări ]n acest fi șier:
• pentru a putea transmite parametri între pagini va trebui setat ă variabila
register_globals pe On (acest lucru îns ă poate crea bre șe de securitate)
• includerea modulelor suplimentare prin setare directorului unde se afl ă acestea
(pentru linux și unix se va utiliza: extension_dir = /usr/lib/apache/extension ,
respectiv extension_dir = c:\calea_spre_php\extensions pentru familia
Microsoft).
shell> ./configure –prefix=/usr –exec-prefix=/usr –bindir=/usr/bin \
–bindir=/usr/sbin –sysconfdir=/etc –datadir=/usr/share \ –includedir=/usr/include –libdir=/usr/lib –libexecdir=/usr/libexec \ –localstatedir=/var –sharedstatedir=/usr/com \ –mandir=/usr/share/man –infodir=/usr/share/info –prefix=/usr \ –with-config-file-path=/etc –disable-debug –enable-pic –disable-rpath \ –enable-inline-optimization –with-apxs=/usr/sbin/apxs \ –with-exec-dir=/usr/bin –with-gd –with-jpeg-dir=/usr –with-png \ –with-regex=system –with-ttf –with-zlib –with-layout=GNU \
–enable-ftp –enable-magic-quotes –enable-safe-mode –enable-sockets \
–enable-track-vars –without-yp –with-mysql=shared –without-unixODBC \ –without-oracle –without-oci8 –without-pspell shell> make shell> make install
Monitorizarea echipamentelor de telecomunica ții
675.3. Instalarea și configurarea serverului de baze de date MySQL
Este nevoie de o distribu ție MySQL, desigur. În func ție de sistemul de operare,
de facilit ățile dorite și de gradul de maturitate cerut pentru MySQL, se poate alege o
distribu ție de pe http://web.mysql.com sau de pe un mirror convenabil. În cazul Red Hat
Linux 8.0, MySQL este oferit împreun ă odat ă cu cd-urile sistemului de operare dar dac ă
se dore ște instalarea unei distribu ții mai noi a serverului de baze de date pentru
instalarea minimal ă a MySQL server sunt necesare urm ătoarele rpm-uri:
• MySQL- versiune .i386.rpm
• MySQL-client- versiune .i386.rpm
• MySQL-devel- versiune. i386.rpm
shell> rpm -i MySQL- versiune _i386.rpm MySQL- client -versiune_i386.rpm
În cazul în care se dore ște instalarea serverului MySQL pe un sistem OpenBSD
3.1 este recomandat s ă se foloseasc ă pachetele pe care acest sistem le ofer ă. Trebuie
acordat ă o oarecare aten ție instal ării deoarece instalarea serverului MySQL ar putea
necesita instalarea și a altor pachete software și mai respectat ă ordinea: mai întâi se va
instala clientul MySQL și abia apoi serverul. Ac țiuni care se vor desf ășura astfel:
shell>pkg_add –vf /cale/mysql-versiune-client.tar.gz
shell>pkg_add –vf /cale/mysql-versiune-server.tar.gz
Pentru a porni la bootarea sistemuli de operare și serverul MySQL este necesar ă
editarea fi șierului /etc/rc.local și ad ăugarea comenzii de pornire a MySQL
(/cale/safe_mysql & ).
La finalul instal ării se afi șează pe consola o cale ( path) și o comand ă pentru
setarea parolei de acces la administrarea serverului MySQL. Pentru instalarea serverului MySQL pe un sistem produs de Microsoft exist ă un
kit de instalare care va realiza instalarea rapid ă a acestuia, este recomandat s ă nu se
modifice directorul în care se va instala serverul, adic ă C:|mysql , dac ă totu și se va dori
ca instalarea s ă fie f ăcută într-un alt director vor trebui aduse modific ări fi șierului de
configurare a MySQL-ului care s ă corespund ă noi loca ții a serverului. Acest fi șier de
configurare va trebui copiat din directorul unde a fost instalat serverul MySQL pe C:\ cu
numele my.cnf . În directorul unde a fost instalat serverul MySQL exist ă mai multe
fișiere de configurare care au implementat dicferite șabloane de configurare pentru
diferite necesit ăți.
Monitorizarea echipamentelor de telecomunica ții
68Doritorii de mai mult control pot desigur alege varianta compil ării din surse.
Pentru acest caz sunt disponibile mai multe op țiuni cu care acesta poate fi configurat,
una dintre ele fiind și alegerea locului unde se vor afla pe disk fi șierele bazelor de date,
fapt care se poate dovedi extrem de important în anumite condi ții.
Modelul folosit de MySQL se bazeaz ă pe username/password, hostname și
privilegii și este similar celui generic folosit de sistemele Unix. Prin privilegii se în țeleg
în cazul MySQL opera țiunile ce vor fi permise asupra bazei/bazelor de date, tabelelor
sau indec șilor, cum sunt de exemplu SELECT, INSERT, UPDATE, DELETE,
CREATE, DROP.
Creăm o baz ă de date:
Acord ăm utilizatorului "user" cu parola "parola" care se conecteaz ă la serverul
MySQL de pe orice ma șina din re țeaua ".retea-sigura.net" dreptul de a face SELECT pe
orice tabele din baza de date "Clienti”:
Folosirea GRANT și REVOKE este semnalat ă serverului imediat și, spre deosebire de
acordarea de privilegii cu UPDATE sau INSERT, nu necesit ă o comand ă ulterioar ă de
tip FLUSH PRIVILEGES, care spune serverului s ă reciteasc ă tabelele de permisiuni.
Pe de alta parte:
ofer ă toate drepturile user-ului "gigi", dar numai de la consola serverului.
Crearea "Clienti" și recitirea tabelelor de privilegii prin FLUSH PRIVILEGES
se poate face și cu myqsladmin . Revocarea privilegiilor acordate se face folosind
explicit REVOKE sau prin scrierea direct ă în tabelele de drepturi (mysql.user,
mysql.db, mysql.host, mysql. tables_priv și mysql.colums_priv).
Pentru o imagine complet ă asupra modului în care func ționeaz ă modelul de
securitate MySQL, este obligatorie citirea cu aten ție a paginilor respective din manual.
mysql>GRANT ALL PRIVILEGES ON Clienti.* TO gigi@localhost
IDENTIFIED BY "parola_lunga'; shell>mysql -u root -p
mysql>create database Clienti; mysql>use Clienti;
mysql>GRANT SELECT ON Clienti.* TO
user@'%.retea-sigura.net" IDENTIFIED BY "parola';
Monitorizarea echipamentelor de telecomunica ții
69Capitolul 6. Utilizarea sistemului
Odat ă pus în func țiune sistemul are avantajul de a fi u șor de folosit și de a nu
necesita preg ătirea utilizatorilor pentru folosirea lui, fiind dezvoltat cu o interfa ță bazat ă
pe web acesta va fi foarte repede în țeles și exploatat de utilizatori. În secolul în care
trăim sunt foarte pu țini cei care nu au avut înc ă contact cu acest tip de prezentare a
informa ției.
Primul pass pe care trebuie s ă îl execute utilizatorul este acela de a se
autentifica, dup ă autentificarea în sistem utilizatorului îi vor fi furnizate informa ții
asupra tuturor echipamentelor asupra c ărora el este proprietar. În cadrul prezent ării ce
urmeaz ă s-a folosit pentru exemplificare utilizatorul root care are drepturi asupra tuturor
echipamentelor. Prima pagin ă furnizat ă acestuia îi d ă posibilitatea s ă aleag ă pentur care
dintre GSM-uri dore ște să afișeze informa ții:
Figura 6.1. Alegerea unui echipament pentru monitorizare
Dup ă ce utilizatorul a ales echipamentul ce dore ște să îl monitorizeze i se va
furniza pagina asociat ă acestuia:
Figura 6.2. Pagina echipamentului
Monitorizarea echipamentelor de telecomunica ții
70Din aceast ă pagin ă utilizatorul poate s ă își aleag ă tipul de reprezentare pe care
dore ște să o vizualizeze și durata de timp pentru care se va genera aceast ă reprezentare.
Avem la dispozi ție dou ă tipuri de grafice:
• Cauza deconect ării într-un interval de timp
Figura 6.3. Histograma cauzelor de deconectare
• Durata convorbirilor într-un interval de timp
Figura 6.4. Histograma duratei unei convorbiri
Dac ă reprezent ările grafice nu sunt suficiente pentru luare a unei decizii mai sunt
disponibile și reprezent ări tabelare a convorbirilor care au avut loc prin acel echipament.
Pentru utilizatorul root mai sunt disponibile și reprezent ări tabelare ale
conexiunilor VPN care se realizeaz ă prin intermediul routerului de acces precum și a
conexiunilor telent care se realizeaz ă la acel router:
Monitorizarea echipamentelor de telecomunica ții
71
Figura 6.5. Informa ții despre conexiunile VPN
Dac ă se dore ște monitorizarea unui nou echipament este disponibil ă o pagin ă
pentru definirea de noi echipamente:
Figura 6.6. Definirea unui nou echipament GSM ce se dore ște a fi monitorizat
Pe viitor se va încerca extinderea aplica ției astfel încât informa țiile statistice
oferite s ă poat ă satisface toate necesit ățile ce pot ap ărea. De asemenea mai este necesar ă
îmbun ătățirea interfe ței grafice, toate aceste neajunsuri urmând a fi îmbun ătățite într-o
versiune urm ătoare a aplica ției.
Monitorizarea echipamentelor de telecomunica ții
72Capitolul 7. Concluzii
Am încercat s ă implement ăm o modalitate de monitorizare de c ătre utilizatori a
echipamentelor de telecomunica ții care s ă poat ă fi implementat ă într-un timp foarte
scurt și să ofere avantajele de a fi ieftin ă, viabil ă, cu un grad accptabil de securitate prin
implementarea modelelor trei și patru. Aceast ă implementare și-a dovedit utilitatea
ajutând la luarea deciziilor în momentul în care echipa ce r ăspunde de aceste
echipamente s-a confruntat cu probleme în ceea ce prive ște buna func ționare a
sistemului de telecomunica ții. De asemenea și-a dovedit utilitatea și pentru echipa
managerial ă care în urma informa țiilor furnizate de aceast ă aplica ție pe parcursul unui
săptămâni a luat decizia de a cre ște num ărul de echipamente de tip GSM Gateway în
India și a reduce num ărul lor în Zurich.
De ce este ieftin ă aceast ă solu ție? Din punctul de vedere al utilizatorului este
ieftin ă pentru c ă acesta nu trebuie s ă achizi ționeze nici un fel de echipament care s ă îi
permit ă conectarea fiindui suficient calculatorul personal și o conexiune internet. Din
punctul de vedere al dezvoltatorului implic ă costuri reduse datorit ă timpului scurt de
implementare și a utiliz ării de module care sunt sub licent ă GPL și deci nu necesi ă
investi ții pentru achizi ționarea lor.
Am folosit serverul web Apache sau serverul MySQL doar pentru faptul c ă
acestea sunt gratuite? Am folosit Apache pentru c ă este cel mai rapid server de la ora
actual ă, pentru c ă spre deosebire de ISS este un server cu un grad ridicat de securitate
(numai în ultimii ani s-au produs pagube de 2.6 miliarde USD datorate infect ării cu
worm-urile CodeRed a hosturlior ce rulau ISS), pentru c ă acesta ruleaz ă sub orice tip de
sistem de operare, nefiind lega ți în acest fel de nici una dintre firmele produc ătoare de
sisteme de operare, pentru c ă este de asemenea cel mai stabil. Am folosit serverul
MySQL pentru vitez ă și complexitatea redus ă a procedurilor de conectare și interogare,
aici îns ă discu ția rămâne deschs ă pentru c ă în cazul MySQL acesta are înc ă unele
probleme ce trebuie rezolvate (integritatea datelor, suport pentru chei str ăine, suport
pentru selecturi imbricate,etc.).
De ce am utilizat PHP? Pentru c ă este cel mai u șor de înv ățat limbaj de script,
pentru c ă este extrem de flexibil, pentru c ă alegând Apache am eliminat alternativa
numit ă ASP și pentru c ă nu am putut apela la limbaje de script ce ruleaz ă pe client
(datorit ă breșelor de securitate pe care le deschid aceste limbaje).
Monitorizarea echipamentelor de telecomunica ții
73Față de alte sisteme acesta ofer ă posibilitatea configur ării în mai multe
arhitecturi în func ție de buget și de complexitatea echipamentelor monitorizate.
Modific ările care trebuie aduse pentru a trece de la o arhitectur ă la alta nu necesit ă mai
mult de o zi de munc ă a unui programator ceea ce conduce la costuri de maximum 160$
(pre țul pe or ă maxim al unui programator în Timi șoara neridicânduse la mai mult de
20$/h).
Monitorizarea echipamentelor de telecomunica ții
74Anexe
Tabelele bazei de date
CREATE DATABASE jft; CREATE TABLE eqtype (id int NOT NULL auto_increment,
type tinytext NOT NULL,obs tinytext,
PRIMARY KEY(id), UNIQUE KEY (type(255)));
CREATE TABLE equip(id int NOT NULL auto_increment, ip tinytext NOT NULL, name tinytext NOT NULL, idt int NOT NULL, location tinytext NOT NULL, PRIMARY KEY(id),UNIQUE KEY(ip(255)),KEY(location(255)));
create table tname (sender tinytext,destination tinytext,
cdate date not null,ctime time not null,clength int not null,
calling_line smallint not null,called_line smallint not null,
simcard smallint not null,disside smallint not null,cause int not null, primary key(cause),key(ctime),key(cdate)); CREATE TABLE connection( id int NOT NULL auto_increment,ide int NOT NULL, ip tinytext NOT NULL,pid int default NULL, PRIMARY KEY(id),UNIQUE KEY(ip(255)),UNIQUE KEY(ide));
CREATE TABLE cause (id int NOT NULL auto_increment,
cause int NOT NULL, description tinytext NOT NULL,
obs tinytext NOT NULL,PRIMARY KEY(id),UNIQUE KEY(cause));
CREATE TABLE telentlog (id int NOT NULL auto_increment, ip tinytext NOT NULL, user tinytext NOT NULL, cdate datetime NOT NULL,PRIMARY KEY(id),UNIQUE KEY(date));
CREATE TABLE vpnlog (id int NOT NULL auto_increment,
ip tinytext NOT NULL, user tinytext NOT NULL,group tinytext NOT NULL,
cdate datetime NOT NULL,PRIMARY KEY(id),UNIQUE KEY(date));
CREATE TABLE users (id int NOT NULL auto_increment,
name tinytext NOT NULL, password tinytext NOT NULL, company datetime NOT NULL,PRIMARY KEY(id),UNIQUE KEY(date));
Monitorizarea echipamentelor de telecomunica ții
75
Bibliografie:
1. Andrew S. Tanenbaum: Modern Operating Systems , Prentice Hall,
1992, pag. 27-31, 279-284
2. www.apache.org
3. www.mysql.com
4. www.php.org
5. www.netreport.ro
6. Florin Forti ș, Viorel Negru, C ălin Șandru: Ini țiere în UNIX, Eubeea,
2001, pag 193-209
7. Lucian Cucu: Noti țe curs, Universitatea de Vest, Curs C 2000 – 2001
8. Ion B ănică: Re țele de comunica ții între calculatoare, Teora, 2000
9. Ioan Jurc ă: Programarea re țelelor de calculatoare, Editura de Vest,
2000
10. Mobiline GSM Gateway Handbook 2002
11. www.mobiline.hu
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Monitorizarea echipamentelor de telecomunica ții [604989] (ID: 604989)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.