Projekt systemu ewidencji zasobów informatycznych z wykorzystanie oprogramowanie open source

Projekt systemu ewidencji zasobów informatycznych z
wykorzystaniem oprogramowania klasy open-source

W a r s z a w a 2010

Spis treści
Wstęp ................................................................................................................................. 5
1. Charakterystyka systemu ewidencji zasobów informatycznych ..................................... 6
1.1 Inwentaryzacja ........................................................................................................... 6
1.2 Sprzęt ......................................................................................................................... 7
1.3 Oprogramowanie ........................................................................................................ 8
1.4 Analiza wymagań na systemy ewidencji zasobów informatycznych ...................... 10
1.4.1 Funkcjonalne ..................................................................................................... 10
1.4.2 Niefunkcjonalne ................................................................................................ 11
2. Przegląd istniejących rozwiązań klasy open-source do ewidencji zasobów
informatycznych ................................................................................................................. 11
2.1 Oprogramowanie open-source ................................................................................. 11
2.1.1 Odmiany wolnego oprogramowania ................................................................. 12
2.1.2 Najpopularniejsze licencje ................................................................................ 14
2.1.3 Korzyści z użycia wolnego oprogramowania. ................................................. 15
2.2 Przegląd programów open-source ............................................................................ 17
2.2.1 Open-AudIT ...................................................................................................... 18
2.2.2 OCSI ................................................................................................................. 20
2.2.3 GLPI ................................................................................................................. 25
2.2.4 Paglo Crawler ................................................................................................... 27
2.2.5 Zabbix ............................................................................................................... 28
2.2.6 Pulse2 ................................................................................................................ 30
2.2.7 Projekty nierozwijane ....................................................................................... 30
3. Koncepcja wykorzystania i dobór oprogramowania klasy open-source do budowy
systemu ewidencji zasobów informatycznych. ................................................................... 32
3.1 Docelowe przedsiębiorstwo ..................................................................................... 32
3.2 Klasyfikacja użytkowników ..................................................................................... 35
3.3 Wykorzystanie modułów open-source do budowy systemu. .................................... 36
3.4 Struktura systemu. .................................................................................................... 37
3.4.1 Architektura rozproszona .................................................................................. 38
3.4.2 Architektura scentralizowana ............................................................................ 39
3.5 Monitorowanie serwerów ......................................................................................... 41
4. Projekt wybranych elementów systemu ewidencji zasobów informatycznych ............. 43
4.1 GLPI - projekt rozszerzenia do tworzenia listy zakazanego oprogramowania ......... 43
4.2 Projekt architektury sprzętowo systemowej. ............................................................ 45
4.3 Projekt wykorzystania systemu przez grupy pracowników ...................................... 46
5. Implementacja systemu ewidencji zasobów informatycznych ..................................... 48
5.1 OCSI - poprawki do języka polskiego ...................................................................... 48
5.2 Implementacja rozszerzenia dla GLPI ..................................................................... 50
5.3 Instalacja systemu ewidencji .................................................................................... 53
5.3.1 Instalacja i konfiguracja OCSI .......................................................................... 54
5.3.2 Instalacja i konfiguracja GLPI .......................................................................... 55
5.3.3 Instalacja i konfiguracja Zabbix ........................................................................ 58
5.4 Konfiguracja systemu ewidencji dla instytucji o strukturze rozproszonej ................ 58
5.5 Proces inwentaryzacji .............................................................................................. 61
6. Testy .............................................................................................................................. 64

2

6.1 Projekt środowiska testowego ................................................................................. 64
6.2 Inwentaryzacja ......................................................................................................... 65
6.3 Raportowanie ........................................................................................................... 68
6.4 Rozszerzenie „Checker” ........................................................................................... 69
7. Porównanie wytworzonego systemu z rozwiązaniami komercyjnymi .......................... 70
7.1 Porównanie funkcjonalności .................................................................................... 70
7.2 Porównanie kosztów ................................................................................................ 73
Podsumowanie ................................................................................................................. 75
Bibliografia ...................................................................................................................... 76
Spis załączników .............................................................................................................. 77

3

Wstęp

Rozwój przedsiębiorstw i ich informatyzacja powodują , iż obecnie każdy
pracownik wykonując swoją pracę wspomagany jest przez komputer. Firma odpowiada za
komputery swoich pracowników, musi zapewnić ich dostępność, wydajność oraz legalność.
Aby osiągnąć te cele należy odpowiednio reagować na problemy zgłaszane przez
użytkowników, oraz dbać o legalność zainstalowanego oprogramowania. Jednocześnie
utrzymanie struktury informatycznej w firmie niesie za sobą wiele kosztów. Możemy je
minimalizować poprzez trafne decyzje co do zakupu i modernizacji sprzętu. Aby dokonywać
właściwych wyborów musimy posiadać wiedzę na temat wykorzystania sprzętu i
oprogramowania w przedsiębiorstwie. W tym celu tworzone są systemy pomagające
ewidencjonować infrastrukturę informatyczną. Na rynku dostępnych jest wiele systemów
komercyjnych. Wdrożenie takowych systemów w dużych przedsiębiorstwach wiąże się z
bardzo dużymi kosztami, dlatego też warto zainteresować się rozwiązaniami bezpłatnymi,
które nie odbiegają jakościowo od płatnych rozwiązań.
Celem pracy jest przygotowanie systemu który będzie wykorzystywany w
przedsiębiorstwie do ewidencjonowania zasobów informatycznych. System powinien składać
się z komponentów cechujących się dostępnością kodu źródłowego. W pierwszej części
została przedstawiona tematyka inwentaryzacji, oraz wymagania na system wspomagający ją.
Następnie opisana jest idea oprogramowania open-source, jego zalety jak i wady. Zostały
opisane i zbadane pod kątem dostępnych funkcjonalności programy open-source.
Przykładowym przedsiębiorstwem, na podstawie którego przeprowadzono analizę jest ZUS.
Bazując na opisanych rozwiązaniach został zaprojektowany system. Brakujące
funkcjonalności oraz architektura systemu zostały opisane w rozdziale projektowanie.
Następnie wykonano instrukcje wdrożenia systemu oraz implementacje wymaganych
funkcjonalności. Tak wytworzony system został przetestowany w celu sprawdzenie
poprawności działania. Na koniec wykonano porównanie z wiodącymi projektami
komercyjnymi, pod kątem oferowanych możliwości oraz kosztów.

4

1. Charakterystyka systemu ewidencji zasobów informatycznych

1.1 Inwentaryzacja
„Inwentaryzacja (remanent) – spis inwentarza z natury, stan zapasów danej rzeczy w danym
momencie w określonym dniu. Ustalenie rzeczywistego stanu zasobów majątkowych , oraz
źródeł pochodzenia”1. Pojęcie inwentaryzacji wzięte z ekonomi w odniesieniu do ewidencji
zasobów informatycznych tylko ideowo oddaje naturę tego drugiego. Ewidencja zasobów
informatycznych, ma wiele innych aspektów których nie ma po prostu przy inwentaryzacji w
ekonomi. Próba wzięcia przepisu z ekonomi na wykonanie inwentaryzacji nie sprawdzi się w
odniesieniu do informatyki, gdyż specyfika zasobów informatycznych i przydatność ich
spisywania jest bardzo różna i nie wszystko co możemy spisać będzie przydatne do
czegokolwiek w przyszłości. Ewidencja zasobów informatycznych powinna nieść za sobą
przede wszystkim mierzalne korzyści. Według podręcznika do inwentaryzacji1 powinny
istnieć następujące etapy w omawianym procesie:
1. przygotowanie
2. przeprowadzenie
3. rozliczenie
W odniesieniu do omawianej dziedziny taki podział jest przydatny, aczkolwiek etap
przygotowania, powinien być jednorazowy, samo przeprowadzanie i rozliczanie (u nas
raportowanie) wykonywane okresowo przez zautomatyzowany mechanizm. Taki podział jest
bardziej praktyczny, gdyż raz instalujemy oprogramowanie na serwerze do gromadzenia
informacji, a następnie z niego korzystamy monitorując stan w całej firmie. Następnie
podręcznik podaje rodzaje inwentaryzacji
1. pełna okresowa
2. pełna ciągła
3. wyrywkowa okresowa, bądź ciągła
Z tego podziału najbliżej nam będzie do punktu trzeciego (wyrywkowa okresowa, bądź
ciągła). W naszym przypadku możemy przeprowadzać właściwie dwa rodzaje inwentaryzacji:
1. jednorazowa częściowa,
2. okresowa częściowa.

1 D. Małkowska, „Inwentaryzacja od A do Z”, Gdańsk 2007, s.10.

5

Przeprowadzanie pełnej inwentaryzacji zasobów informatycznych, to pojęcie trudne do
zdefiniowania, gdyż trudno określić jak szczegółowo należy spisywać sprzęt: czy należy
liczyć sztuki komputerów osobistych, czy również ich elementy. Warto też zastanowić się czy
warto inwentaryzować wszystkie urządzenia, np. urządzenia peryferyjne(myszy, klawiatury,
głośniki, pen-drive). Oprogramowanie może też nie posiadać funkcjonalności do wykrycia
każdego sprzętu(trudno określić np. jaki model głośników podpięty jest do stacji roboczej).
Dochodzi oczywiście też zbieranie informacji o oprogramowaniu, które działa na
komputerach.
Głównym zadaniem inwentaryzacji w klasycznym ujęciu jest „Ustalenie
rzeczywistego stanu zasobów majątkowych”, czyli policzenie co ile jest warte. W naszym
przypadku takie rozliczenia nie stoją na pierwszym miejscu, choćby dlatego że wartość
sprzętu komputerowego bardzo szybko spada i próba określenia ile wart jest dwuletni zestaw
komputerowy jest bardzo przybliżana. Podręcznik podaje również, iż podstawową metodą
inwentaryzacji jest spis z natury. Jednak nikomu po prostu nie chce się chodzić po pokojach w
firmie i spisywać każdy komputer oddzielnie, poza tym jest to czasochłonne i obarczone
błędem. Mamy tutaj klasyczny przykład użyteczności rozwiązań informatycznych do
zastąpienia procesów powtarzalnych i czasochłonnych. Dlatego też istnieje zapotrzebowanie
na oprogramowanie do inwentaryzacji zasobów informatycznych. W podręczniku znajdziemy
również wiele zasad inwentaryzacji:
• ograniczonego zaufania – dzięki zastosowaniu specjalistycznego oprogramowania, które
zbiera informacje, eliminujemy czynnik ludzki,
• zaskoczenia – użytkownik nie musi wiedzieć, że w danej chwili jego sprzęt jest
poddawany inwentaryzacji (ma to duże znaczenie przy wykrywaniu nieporządnego
oprogramowania bądź treści na komputerze),
• kompleksowości i kompletności – oprogramowanie, które zbiera informacje będzie na
każdym sprzęcie działało tak samo i nie pominie jakiegoś elementu. Oczywiście twórcy
oprogramowania muszą określić co będzie spisywane.

1.2 Sprzęt
Kierując dużym czy mały przedsiębiorstwem możemy napotkać problemy związane z
zarządzaniem sprzętem. Te trudności to m. in. :

6

• sprzęt komputerowy szybko staje się przestarzały, o czym mówi prawo Moora, cytuję:
”optymalna liczba tranzystorów w układzie scalonym podwaja się co 18-24 miesiące.” ,
• wiele podzespołów w różnych konfiguracjach,
• konieczność sprawdzania maszyn z osobna,
• ingerencja w zestawy komputerowe (komputer stacjonarny nie jest jednolitą kostką).
Dzięki oprogramowaniu inwentaryzacyjnemu jesteśmy w stanie radzić sobie z tymi
problemami. Oprogramowanie samodzielnie zbierze automatycznie informacje o wszystkich
podzespołach bez potrzeby podchodzenia do każdej stacji. Dodatkowo posiadamy też
wymierne korzyści z przeprowadzonej inwentaryzacji:
• łatwe odnalezienie zapasowego sprzętu komputerowego,
• rozsądniejsze planowanie wydatków,
• sprawne decyzje dotyczące nieużywanego sprzętu.

1.3 Oprogramowanie
Możemy wskazać następujące trudności związane z oprogramowaniem:
• konieczne pobieranie oprogramowania dla różnych platform sprzętowych(32bit/64bit,
AMD/Intel, Windows/Linux/Mac),
• możliwość samodzielnej instalacji przez użytkowników,
◦ piractwo komputerowe,
▪ P2p,
▪ P2m,
▪ serwisy typu http://rapidshare.com,
◦ wirusy,
◦ niepotrzebne oprogramowanie,
• licencje czasowe na aplikacje,
• wielość systemów operacyjnych.

7

Rys. 1: Popularne dostępne systemy operacyjne na rynku.

8

Jeśli chodzi o korzyści z inwentaryzacji oprogramowania to możemy tutaj wymienić:
• odnawianie i zakup nowych licencji,
• wykrywanie potencjalnych problemów: np. brak miejsca na dysku,
• informacje o niedziałającym oprogramowaniu,
• wykrywanie niepotrzebnych aplikacji (np. Gadu Gadu, p2p),
• łatwiejsze szacowanie kosztu wykorzystywanego oprogramowania (poglądowe
informacje o koszcie oprogramowania, np. koszt licencji na systemy operacyjny firmy
Microsoft, umożliwia szukanie oszczędności),
• wykrywanie oprogramowania bez licencji.
Inwentaryzacja może nam również pomóc w wykryciu programów, które są
niepożądane na komputerach pracowników np. programy które posiadają luki bezpieczeństwa
oraz programy do wymiany nielegalnych plików. Po wykonaniu inwentaryzacji możemy
sprawdzić, czy któraś z zainstalowanych aplikacji jest niepotrzebna bądź też niebezpieczna,
lub też nie mamy na nią licencji.

1.4 Analiza wymagań na systemy ewidencji zasobów informatycznych
Wymagania stawiane przed omawianym systemem możemy podzielić na dwie grupy:
funkcjonalne i niefunkcjonalne.

1.4.1 Funkcjonalne
System powinien:
• dokonywać automatycznego(okresowego) spisu sprzętu oraz elementów
składowych ,
• dokonywać automatycznego(okresowego) spisu oprogramowania na nim
zainstalowanego,
• posiadać możliwość ręcznego wprowadzania informacji o urządzeniach, których nie
da się automatycznie zinwentaryzować,
• obsługiwać systemy w różnych konfiguracjach sprzętowych jak i pod względem
oprogramowania(tj. zbiera informacje o oprogramowaniu zarówno z komputerów z
zainstalowanym systemem operacyjnym z rodziny Windows jak i Linux,
• umożliwiać rozszerzanie jego możliwości, oraz współpracę z innymi systemami(np.
możliwość napisania rozszerzenia zbierającego informacje z urządzeń pod kontrolą
systemu android, Mac OS),

9

• posiadać możliwość ustawiania alertów związanych np. z wygaśnięciem licencji,
• definiować dostawców oprogramowania, tak by w razie wygaśnięcia licencji mieć
kontakt,
• generować raporty sprzętu który jest posiadany,
• generować raporty oprogramowania zainstalowanego,
• umożliwiać wykrywanie aplikacji niepotrzebnych,
• umożliwiać szacowanie kosztów zakupu licencji,
• posiadać możliwość przypisania pracownika do jednostki.

1.4.2 Niefunkcjonalne
System powinien:
• być systemem scentralizowanym,
• łatwo się skalować,
• być udostępnianym na jednej z licencji typu open-source.

10

2. Przegląd istniejących rozwiązań klasy open-source do ewidencji
zasobów informatycznych

2.1 Oprogramowanie open-source
„Wolne Oprogramowanie (ang. free software) - ruch programistów i użytkowników
komputerów zaangażowanych w działania na rzecz wolnego dostępu do oprogramowania przez
ogół użytkowników.”2. Ruch ten istnieje od początku istnienia komputerów i oprogramowania,
kiedyś nie był tak nazywany, gdyż nie istniała potrzeba nazywania go, ponieważ wszystkie
programy były wolne i nikt nie nakładał ograniczeń licencyjnych. Formalizacja ruchu zaczęła się
w latach 80-tych, gdy firmy zaczęły udostępniać tylko pliki wykonywalne programów nie
udostępniając przy tym kodu. Wszystko zaczęło się od osoby Richarda M. Stallman'a, który
mając problemy z drukarką w firmie, brał sterownik do drukarki i go poprawiał, udostępniając
zmiany wszystkim zainteresowanym. W dniu, w którym w firmie pojawiła się nowa drukarka i
stare problemy, chcąc naprawić ją sprawdzonym sposobem, zorientował się, iż producent nie
dostarczył kodu źródłowego do oprogramowania sterującego. Myśląc początkowo, iż jest to
tylko niedopatrzenie, poprosił o takie kody, ale spotkał się z wyraźną odmową. Nie wynikała
ona z braku życzliwości tylko z polityki firmy. W ten sposób uświadomił sobie zjawisko
zamykania kodu. Przyzwyczajony do panującej w jego środowisku dzielenia się
oprogramowaniem, z biegiem lat zaczął formować idee „wolnego oprogramowania”. W roku
1991 wydał pierwszą licencję wolnego oprogramowania GNU Public Licence, której głównym
przesłaniem i celem jest rozprzestrzenianie się wolnego oprogramowania.
Z ruchem open-source wiąże się oczywiście również osoba Trowalda Linusa. W
1991 w Helsinkach , jak mówił z pobudek czysto praktycznych, stworzył pierwszą wersję
systemu Linux. Dzięki temu, iż widział Stallman'a na wykładzie o wolnym oprogramowaniu
opublikował swój kod na licencji GPL. Stało się to w momencie, gdy ruch GPL mozolnie
próbował się dorobić własnego wolnego systemu. Stał się nim Linux.

2.1.1 Odmiany wolnego oprogramowania
Jak to w życiu bywa ludzie mają różne poglądy i nawet jeśli działają we
wspólnym celu, to tworzą się frakcje. Nie inaczej jest z ruchem open-source. Tu rozłam
następuje głównie z przyczyn ideologicznych, oraz w zależności od tego jak bardzo duchowo

2 http://pl.wikipedia.org/wiki/Wolne_oprogramowanie

11

traktują swoja misję. Niektórzy jak Stallman bardzo dosłownie podchodzą do wolności i
przejawia się to we wszystkich dziedzinach ich życia, oponują za całkowitym uwolnieniem
informacji. Dlatego też licencja GPL jest licencją „wirusową”, gdyż program który korzysta
z kodu GPL również musi być na tej samej licencji (zapobiega to wykorzystywaniu kodu
napisanego przez innych i podszywanie się pod, niego, oraz zarabianie na pracy innych). Inni
przedstawiciele ruchu podchodzą trochę bardziej praktycznie, gotowi poświęcić kilka
klauzur prawniczych w imię większej popularyzacji open-source. Stąd też powstało wiele
licencji typu open-source, czyli takich które gwarantują darmowy dostęp do kodu
źródłowego aplikacji. Napawa optymizmem, to iż istnieją inicjatywy typu FLOSS, które
scalają wszystkich zapaleńców i we wspólnym imieniu występują na forum ogólnym.

„Istnieje wyraźna rozbieżność między filozofią free software a open-source. Free software
kładzie główny nacisk na strony moralne i etyczne dostępności oprogramowania, natomiast
open-source podkreśla znaczenie technicznej doskonałości kodu. W praktyce każde
oprogramowanie typu free software jest jednocześnie open-source, ale nie każde
oprogramowanie typu open-source jest zarazem free software (ponieważ pierwotna idea jest
bardziej radykalna, a w ruchu potomnym została w pewnym sensie złagodzona). Ze względu
na istniejące różnice podejścia obu ruchów określa się je nieraz zbiorczym terminem FLOSS
(Free/Libre Open-Source Software), spotykanym głównie w oficjalnych analizach i temu
podobnych dokumentach”.

Open-Source - „Termin ten jest używany przez jego adwokatów z dwóch powodów. Po
pierwsze eliminuje zamieszanie wokół słowa „wolny”, które biznes interpretuje zwykle jako
„o zerowych kosztach”. Po drugie pozwala firmom na rozpatrywanie zagadnienia wolnego
oprogramowania raczej z technicznego niż etycznego punktu widzenia”3.
„Mówiąc <<wolny>>, nie myśl o wolnym, bezpłatnym dostępie do piwa, lecz o wolności
wypowiedzi”4.

3 S. Williams, „W obronie wolności. Krucjata hakera na rzecz wolnego oprogramowania”, s. 35.
4 S. Williams za R. Stallamen , patrz przypis 4, s. 78.

12

2.1.2 Najpopularniejsze licencje

GPL(Gnu Public Licence) - „Celem licencji GNU GPL jest przekazanie użytkownikom
czterech podstawowych wolności:
• wolność uruchamiania programu w dowolnym celu (wolność 0)
• wolność analizowania, jak program działa i dostosowywania go do swoich potrzeb
(wolność 1)
• wolność rozpowszechniania niezmodyfikowanej kopii programu (wolność 2)
• wolność udoskonalania programu i publicznego rozpowszechniania własnych ulepszeń,
dzięki czemu może z nich skorzystać cała społeczność (wolność 3).
Jeżeli program nie gwarantuje użytkownikowi chociaż jednej z powyższych wolności,
wówczas, według FSF, nie może być uznany za Wolne Oprogramowanie”5.
Nic nie stoi na przeszkodzie by firma wykorzystała jakiś program open-source, do budowy
własnego, jednak że jest zobowiązana wynik swojej pracy udostępnić społeczności. Ten
łańcuchowy mechanizm zapewnia żywotność ruchowi.
LGPL (Lesser Gnu Public License) - trochę uboższa wersja licencji GPL, uboższa jeśli
chodzi o idee open-source, gdyż pozwala na włączenie kodu na licencji LGPL do programu
o zamkniętych źródłach. Jest to oczywiście w sprzeczności z głównymi ideami open-source,
gdyż prowadzi do powstawania zamkniętego oprogramowania jeśli jednak firma
programistyczna, która wygrywa przetarg na program i w tym przetargu zastrzeżone są
prawa licencyjne do wytworzonego kodu, to byłaby zmuszona omijać komponenty open-
source. Czyli z jednej strony pozwalamy wykorzystywać naszą prace do tworzenia
zamkniętego oprogramowania a z drugiej strony skazujemy się na zapomnienie. Tak więc
wiele firm wydaje np. frameworki na licencjach innych niż GPL, z tego powodu, aby więcej
programistów mogło skorzystać z ich dorobku, np. Google wydaje freamwork GWT na
licencji Apache.
MIT - „Licencja X11 (powszechnie, ale nieprecyzyjnie nazywana Licencją MIT) to jeden z
najprostszych i najbardziej liberalnych typów licencji. Daje użytkownikom nieograniczone
prawo do używania, kopiowania, modyfikowania i rozpowszechniania (w tym sprzedaży)
oryginalnego lub zmodyfikowanego programu w postaci binarnej lub źródłowej. Jedynym

5 http://pl.wikipedia.org/wiki/Wolne_oprogramowanie

13

wymaganiem jest, by we wszystkich wersjach zachowano warunki licencyjne i informacje o
autorze”6.
Creative Commons - „Licencje Creative Commons (CC) - zestaw licencji, na mocy których
można udostępniać utwory objęte prawami autorskimi. Licencje te są tworzone i
utrzymywane przez organizację Creative Commons. Licencje Creative Commons pozwalają
twórcom utworów zachować własne prawa i jednocześnie dzielić się swoją twórczością z
innymi. Zasada "wszelkie prawa zastrzeżone" zostaje zastąpiona zasadą “pewne prawa
zastrzeżone”. Szacuje się, że na licencjach CC udostępnia się obecnie co najmniej 100
milionów utworów. Licencje CC są w chwili obecnej najpopularniejszymi wolnymi
licencjami stosowanymi do licencjonowania treści innych niż oprogramowanie.”7 (Wikipedia
rozważa publikacje wszystkich treści na licencji CC.) Na przykładzie licencji Creative
Commons widać, iż idee „wolnego oprogramowania” przenikają też do innych dziedzin,
które nie są oprogramowaniem.

2.1.3 Korzyści z użycia wolnego oprogramowania.
Podmiotów, które mogą czerpać korzyści z wolnego oprogramowania jest
bardzo wiele i można je podzielić na dwie grupy: użytkownicy oraz wytwórcy. Cele i
korzyści tych dwóch grup są różne. To co jest korzystne dla jednej grupy przez drugą jest
postrzegane jako wada. Zdarza się, że w obrębie jednej grupy pewne cechy wolnego
oprogramowania są odmiennie odbierane. Użytkownik domowy będzie widział głównie
jego niższą cenę, raczej nie będzie patrzył na idee, więc tych odbiorców można zdobyć
jedynie lepszą funkcjonalnością oraz ceną. Natomiast wielkie korporacje też będą patrzyły
na cenę, aczkolwiek wchodzi tu też aspekt uniezależnienia się od konkretnego dostawcy i
konkretnych rozwiązań. Chroni je to przed windowaniem cen przez wytwórców oraz
przypadkiem, gdy firma dostarczająca oprogramowanie bankrutuje. Jeszcze inną grupę
użytkowników stanowią mniejsi dostawcy na co zwraca uwagę Sam Williams w swojej
książce.
„Wolne oprogramowanie łamiąc potęgę monopolu oprogramowania komercyjnego,
umożliwia bystrym mniejszym dostawcom konkurowanie z wielkimi za pomocą usług i
konsultacji – dwóch najbardziej dochodowych nisz rynku komputerowego.” 8

6 http://pl.wikipedia.org/wiki/Licencja_X11
7 http://pl.wikipedia.org/wiki/Licencje_Creative_Commonshttp://pl.wikipedia.org/wiki/Licencje_Creative_Commons
8 S. Williams., „W obronie wolności. Krucjata hakera na rzecz wolnego oprogramowania”, s. 179.

14

Wytwórcy czyli programiści, firmy produkujące oprogramowanie mogą czerpać garściami z
open-source: konsultacje, wytwarzanie oprogramowania dla firm na licencji open-source,
wsparcie przy wdrożeniach projektów. To czy firmom to na rękę czy nie, to inna sprawa,
jedne firmy, które w unikalności oprogramowania upatrują przewagi nad konkurencją nie
będą tym zainteresowane. Z drugiej strony takie firmy mogą zostać same ze swoim
unikatowym oprogramowaniem, które jednak nie potrafi się łączyć z żadnym innym
programem. Gorzej, gdy firma która dostarczała oprogramowania upadnie i nie będzie miał
kto rozwijać aplikacji, a bez kodów źródłowych firma nic nie zdziała. Drugi rodzaj firm
które postawią na aplikacje które łatwo jest dostosować do własnych potrzeb nie będą
narażone na tego typu wydarzenia. Dodatkowo jest szansa, że inna firma też korzysta z tej
aplikacji i publikuje usprawnienia, które u siebie wprowadziła. Na przykładzie firm
produkujących frameworki do aplikacji, można zauważyć, iż tylko firmy udostępniające
programistom technologie za darmo mogą liczyć na odbiorców. Jeżeli programista ma
wybrać pomiędzy frameworkiem z zamkniętym a otwartym kodem, o porównywalnych
funkcjonalnościach, to wybierze ten drugi, gdyż jeśli natrafi na ograniczenia frameworka, to
będzie mógł go sobie zmodyfikować do swoich potrzeb. Natomiast firmy produkujące
środowiska programistyczne obwarowane licencjami nie wolnościowymi, muszą poświęcać
swoje siły na marketing i próby przekonania kogokolwiek by skorzystał z ich rozwiązań, a
przede wszystkim zapłacił za nie. Dlatego też język PHP jest najpopularniejszym językiem
do tworzenia stron www, a nie ASP, gdyż każdy początkujący programista jest w stanie
zrobić serwis wydając tylko pieniądze na hosting. Dodatkowo wokół oprogramowania
wolnościowego, tworzy zazwyczaj się społeczność ludzi którzy opisują swoje przejścia z
różnymi problemami. Przykładem dobrego frameworka otwarto źródłowego jest Ruby on
Rails, posiadający duże grono użytkowników, gdyż ma dostępny kod źródłowy, a język
Ruby pozwala na modyfikacje wszystkich klas wchodzących w jego skład. Programiści
ROR, udostępniają swoje poprawki w postaci plug-inów. Dzięki temu programista nie
wymyśla koła od początku, tylko szuka czy ktoś nie zrobił czegoś podobnego do koła.
Oprogramowanie open-source ma tą zaletę, iż programiści nie muszą odkrywać
koła na nowo, mogą korzystać ze sprawdzonych pomysłów innych osób. Jest to
niezaprzeczalny argument, który sprawdza się właściwie w każdej dziedzinie nauki.
Minusem jest możliwość wykorzystywania oprogramowania open-source, przez dosłownie
każdego, a więc i kogoś kogo możemy nie lubić, albo też kogoś kto może mieć wobec nas

15

wrogie zamiary. Tak też było z nagłośnioną sprawą wykorzystania przez terrorystów
wolnych programów szyfrujących do przesyłania wiadomości między sobą, co
uniemożliwiło wywiadowi inwigilacje. Wydanie systemu Android przez firmę Google, jako
oprogramowania open-source, przyczyniło się do większego zainteresowania systemem,
który jest w fazie rozwojowej.
Na koniec jedna z porad z książki o czytaniu kodu open-source: „Warto
potraktować korzyści płynące z oprogramowania open-source jako swego rodzaju pożyczkę.
Jest wówczas rzeczą oczywistą, że należy poszukać sposobów jej spłacenia poprzez
przekazanie środowisku open-source czegoś od siebie”9. Do tego zalecenia zastosował się
właściciel firmy Canonical i od kilku lat finansuje tworzenie obecnie najpopularniejszej
dystrybucji Linuksa, Ubuntu.

2.2 Przegląd programów open-source
Nieocenioną stroną podczas wyszukiwania oprogramowania open-source, które
w pewnym chociaż stopniu pokrywałoby się z tematem tej pracy okazał się portal
https://olex.openlogic.com. Przydatnymi informacjami zamieszczonymi na stronie poza
opisem projektu są rodzaj licencji, oraz wykorzystywane języki programowania. Podczas
poszukiwań natrafiamy na programy, które tylko w niewielkim stopniu mogłyby spełniać
wymagania np. skrypty służące tylko do zebrania informacji o sprzęcie. W przypadku gdyby
społeczność nie stworzyła gotowych rozwiązań należało by się zastanowić nad użyciem tego
rodzaju skryptów przy konstruowaniu aplikacji. Rzeczywistość okazuje się jednak bardziej
przychylna i istnieje kilka programów które w sposób bardziej kompleksowy podchodzą do
problemu. Podczas wybierania programów typu open-source warto kierować się kryteriami:
• data ostatniej aktualizacji projektu – gdyż prace nad projektem mogą być już dawno
zaniechane,
• możliwości oferowane przez oprogramowanie,
• technologia wykonania(większość rozwiniętych projektów wykorzystuje PHP i
MySQL),
• dostępność dokumentacji(z tym w projektach open-source jest niekiedy ubogo),
• informacje o wdrożeniach.

9 D. Spinellis, „Czytanie kodu: punkt widzenia twórców oprogramowania open-source”, Helion 2005, s.143.D.
Spinellis, „Czytanie kodu: punkt widzenia twórców oprogramowania open-source”, Helion 2005, s.143.

16

2.2.1 Open-AudIT
Projekt mający na celu dostarczenie pełnego systemu do zbierania informacji o
urządzeniach w sieci, programach zainstalowanych na nich. Współpracuje z systemami typu
Linux oraz Windows. Wykorzystywany głównie w przedsiębiorstwach zatrudniających do
100 pracowników. W konfiguracji wyróżniamy:
• serwer danych – MySQL który przechowuje informacje o obiektach,
• serwer aplikacji – serwer obsługujący PHP (np. Apache i mod_php). Odpowiedzialny
jest za:
◦ przyjmowanie informacji od stacji klienckich, skanowanie sieci w poszukiwaniu
niezidentyfikowanego sprzętu,
◦ dostarczanie panelu administracyjnego,

Rys. 2: Architektura Open-AudIT

17

Rys. 3: Open-AudIT - panel administracyjny

Zbieranie informacji o jednostkach w sieci odbywa się na kilka sposobów:
• dla systemów typu Windows, skrypt audit.vbs który zbiera informacje wykorzystując
WMI, a następnie wysyła je do serwera aplikacji,
• dla systemów typu Linux, należy uruchomić skrypt (audit_linux.sh) w jednostce, którą
chcemy zinwentaryzować,
• aby przeskanować naszą sieć w poszukiwaniu niezidentyfikowanych urządzeń, na
których nie możemy uruchomić skryptów zbierających informacje, używamy pliku
nmap.vbs. Wykorzystywany jest tu program nmap10 na licencji GPL, który służy do
skanowania portów przy pomocy takich technik jak: skanowanie połączeń
TCP(listowanie portów z którymi udaje nawiązać się połączenie), skanowanie SYN,
skanowanie portów UDP.
Skrypty zbierające informacje o maszynach klienckich komunikują się z serwerem aplikacji
przy pomocy protokołu HTTP. Protokół ten jest jak najbardziej odpowiedni, gdyż nie jest on
blokowany w firmach. Dane, przy pomocy żądania POST, wysyłane są do serwera www
który przetwarza je i zapisuje w bazie danych. System komunikacji klient-serwer oparty o
protokół HTTP jest obecnie najpopularniejszy. Tworzenie nowych programów, które chciały
by komunikować się z serwerem, posiadając specyfikację formatu danych jest względnie
proste. Wystarczy wygenerować żądanie POST, czy to za pomocą programu (curl, wget),
czy też przy pomocy bibliotek w wybranych języku programowania. Interesującą
funkcjonalnością jest min. możliwość połączenia z LDAP. Aplikacja oferuje wiele typów
raportów dostarczających informacji o:

10 http://pl.wikipedia.org/wiki/Nmaphttp://pl.wikipedia.org/wiki/Nmap

18

• zinwentaryzowanych komputerach,
• zinwentaryzowanych serwerach,
• występującym oprogramowaniu,
• zainstalowanych poprawkach i „servicePack”,
• kluczach licencyjnych używanych w popularnych programach komercyjnych,
• udostępnionych zasobach sieciowych,
• informacje o użytym miejscu na dysku na poszczególnych komputerach.
Projekt udostępniany jest na licencji GPL, ostania aktualizacja to 2009-04. Do
jego uruchomienia wymagany jest serwer www obsługujący PHP, oraz baza danych MySql.
Instalacje wykonujemy wedle poniższych kroków:
1. Instalacja bazy MySQL oraz serwera www(np. Apache), PHP,
2. Pobieramy pliki aplikacji http://www.open-audit.org/downloads.php ,
3. Rozpakowujemy je do folderu aplikacji www.

sudo unzip OpenAuditReleaseCandidate.09.03.17.zip -d /var/www/.

4. Nadajemy odpowiednie uprawnienia do plików

sudo chmod 646 /var/www/OpenAuditReleaseCandidate

sudo chmod 646 /var/www/OpenAuditReleaseCandidate/audit.config

5. Kończymy instalację w przeglądarce pod adresem:
http://localhost/OpenAuditReleaseCandidate/setup.php

Po konfiguracji pozostaje nam jeszcze edytować plik
/var/www/OpenAuditReleaseCandidate/audit.config ustawiając odpowiednie adresy serwera.

2.2.2 OCSI
Projekt rozwijany głównie przez programistów z Francji. Przeznaczenie
programu to zdecydowanie duże wdrożenia, nie opłaca się go wykorzystywać do
zinwentaryzowania 10 stanowisk. Na stronie projektu znajdują się informacje o
największych wdrożeniach w firmach gdzie zinwentaryzowano powyżej 100 tys.
komputerów.
W konfiguracji wyróżniamy:
• database server – serwer MySQL który przechowuje dane o obiektach,
• communication server – obsługuje komunikacje klientów po protokole HTTP z
serwerem danych, wymagany serwer apache oraz mod_perl,

19

• deployment server – przechowuje konfigurację oprogramowania wgrywanego
na klienty(wymaga HTTPS),
• administration console - udostępnia konsolę administracyjną dostępną z
poziomu przeglądarki, wymagany serwer www z obsługą PHP (np. Apache).

Rys. 4: OCS Inventory – architektura – w opracowaniu http://ocsinventory.org

Dla różnych systemów operacyjnych przygotowane są odpowiednie wersje agentów(obecnie
Windows, Linux, Mac Os). Są to pre-kompilowane aplikacje łatwe do zainstalowania na
maszynie klienckiej. Niektóre systemy Linux posiadają w repozytoriach odpowiednie paczki
(Ubuntu osci-agent). Jest też możliwość wgrania agentów na wiele komputerów hurtowo.
Agenty wysyłają do serwera komunikacyjnego informacje zebrane ze stacji klienckiej, jak i
w przypadku włączenia ipdiscover informacji o urządzeniach znalezionych z sieci lokalnej.
Komunikacja odbywa się przy wykorzystaniu protokołu HTTP. System składa się z
modułów:
• OCS Inventory: Server - składuje dane o obiektach, udostępnia moduł komunikacyjny
oparty na mod_perl, służący do zbierania informacji od agentów. Informacje są wysyłane
po protokole HTTP, również z sieci internet. Dostarcza również komunikacje z innymi

20

aplikacjami opartą o Web serwisy I protokół SOAP. Z tej funkcjonalności korzysta
projekt GLPI.
• OCS Inventory: UNIX Agent - agent przeznaczony na platformy typu UNIX , a więc
obsłużymy nim takie systemy jak Linux, Max Os, Solaris
• OCS Inventory: Windows Agent - agent przeznaczony na komputery z systemem typu
Windows
• OCS Inventory Mobile – agent na platformy mobilne wspierające Java, umożliwia
wykorzystanie na telefonach
• OCS Inventory: OCSReports - moduł konsoli administracyjnej służący do zarządzania
konfiguracją, przeglądania inwentaryzowanych jednostek
• OCS Inventory: deploy tool - pozwala na zdalną instalacje agentów na komputerach z
systemami Windows używając WNI, bądź systemami Unix używając protokołu SSH
• IPDISCOVER – skanowaniem sieci lokalnej w poszukiwaniu urządzeń na których nie
ma bądź też nie można zainstalować agentów, zajmują się wyznaczeni przez nas agenci,
którzy skanują wybraną przez nas sieć do której są podłączeni. Następnie w panelu
administracyjnym możemy opisać tak wykryte urządzenia.

21

Rys. 5: OCS Inventory - schemat działania w opracowaniu http://www.ocsinventory-ng.org

Oferowane funkcjonalności to zbieranie informacji zarówno o sprzęcie jak i
oprogramowaniu zainstalowanym na maszynach w sieci. Dodatkowo mamy możliwość
wgrywania na komputery monitorowane oprogramowania. Służy do tego oddzielny serwer
“Deployment server”.

22

Rys. 6: OCSI - wgrywanie programów

Mimo wielu funkcji i budowy modułowej nie można uznać OSCI za
pełnowartościowy system do ewidencji zasobów informatycznych. Brakuje modułu do
tworzenia zaawansowanych raportów. Można przy pomocy jego zbierać informacje o
komputerach, można w pewnym stopniu nimi zarządzać poprzez Deployment Server, do
dyspozycji mamy wgrywanie na maszyny klienckie skryptów i uruchamianie ich. Jest też
możliwość raportowania stanów, tj informacji o tym jak zakończyło się wgrywanie „paczki”
na poszczególne komputery. Zgromadzone dane możemy właściwie wykorzystać tylko do
tego, aby wydrukować raport, sprawdzić ile sprzętu danego typu mamy na stanie.
Dysponując informacjami o komputerach i oprogramowaniu użytkowników, możemy
szybciej rozwiązywać problemy z nimi związane. Twórcy projektu skupili się na jasnym
celu, którym jest zinwentaryzowanie większości zasobów informatycznych jakie posiadamy
w firmie. W celu zapewnienia pełnej funkcjonalności systemu ewidencjonującego polecają

23

na stronach projektu11 integrację projektem GLPI. Rozwijany jest on przy użyciu takich
technologi jak C (aplikacje agentów na poszczególne platformy), MySql(składowanie
zebranych informacji), PHP(panel administracyjny), PERL(moduł przyjmujący informacje
od agentów). Polska wersja językowa programu jest niedoskonała.

2.2.3 GLPI
W tym projekcie brak modułu zautomatyzowanego inwentaryzowania maszyn,
korzysta on z zasobów OCSI, z którym integruje się wykorzystując web-serwisy i protokół
SOAP. Projekt jest ukierunkowany nie na zbieranie informacji od pojedynczych agentów, a
na przetwarzanie pobranych informacji. Łączony jest on głównie z systemem OCSI, który
służy do zasilania danymi, dodatkowo umożliwia też zasilanie poprzez import plików CSV.
Program posiada możliwość importu danych z aplikacji OCSI (Komputery, Wewnętrznych
urządzeń, Oprogramowanie, Urządzenia zewnętrzne, Monitory, Drukarki, Producenci).
Uzupełnia ją o funkcjonalności,
które w ogólności wykorzystują
zgromadzone do dalszego
przetwarzania, m. in. :
• alerty w przypadku
przekroczenia metryk, czy też
wygaśnięcia licencji, Rys. 7: GLPI- definiowanie hierarchi administracyjnej

• zarządzanie zasobami informatycznymi (również ręczne dodawanie sprzętu),
• helpdesk z wykorzystaniem reguł biznesowych (automatyczne przypisywanie zgłoszeń,
historia zgłoszeń, zarządzanie czasem i i koszty związane ze zgłoszeniem),
• zarządzania kontraktami oraz informacje finansowe (umowy),
• zarządzanie i nadzór dostaw (informacje o dostawcach),
• baza wiedzy/FAQ (najczęściej zadawane pytania),
• statystyki i raporty (informacje handlowe i finansowe, umowy, zgłoszenia, statystyka
sprzętu, eksport PDF),
• zarządzanie rezerwacjami sprzętu,

11 http://ocsinventory.org

24

• zróżnicowane typy użytkowników.
Na uwagę zasługuje też pokaźna liczba
rozszerzeń, obecnie powyżej 50.
Dostarczają one takich funkcjonalności jak:
• zarządzanie zamówieniami,
• graficzna topologia sieci
komputerowych.
Rys. 8: GLPI - dodawanie jednostki manualne
Wszystkie rozszerzenia są pisane według
ustalonego standardu. Ułatwia to nam napisanie własnej funkcjonalności, stosując się do
instrukcji tworzenia nowych rozszerzeń.
Domyślnie po instalacji program nie posiada
żadnych pre-definiowanych list sprzętu ani
oprogramowania. Dzięki temu mamy bardzo
duże możliwości konfiguracji poprzez
tworzenie własnych list.
Program dostępny w polskiej wersji.
Komunikuje się z istniejącymi
katalogami(LDAP, Active Directory, CAS). Rys. 9: GLPI - help desk

Posiada możliwość logowania się poprzez
LDAP12.

12 http://wiki.lemonldap.ow2.org/xwiki/bin/view/NG/DocAppGLPI

25

Rys. 10: Autentyfikacja poprzez LDAP i GLPI

Projekt wykorzystuje: serwer danych (MySQL), serwer aplikacji(PHP), który generuje
interfejs użytkownika. Na stronie programu podane są informacje o wielu wdrożeniach
(wraz z systemem OCSI), największe obsługują ok 95000 komputerów. Ostatnia aktualizacja
projektu to 2009-11.

2.2.4 Paglo Crawler
Projekt należy zaliczyć do projektów komercyjnych, jednakże umieszczono go
w tej kategorii z tej racji, iż producent udostępnia tzw. agenta instalowanego na naszej stacji
roboczej do zbierania danych o urządzeniach w sieci na licencji GPL. Jest to ciekawe
podejście, które łączy w sobie w pełni komercyjny produkt z modułem udostępnionym jako
open-source. Producent zdecydował się na taki ruch, gdyż użytkownik wszystkie informacje
o swoich komputerach powierza firmie. Chcąc zapewnić użytkownika, iż jego dane zostaną
wysłane tylko na serwer producenta, kod agenta w całości można przeglądać. Ułatwia to

26

również pisanie własnych rozszerzeń, które np. będą zbierały określone przez nas
informacje.

Rys. 11: paglo - menu główne. W opracowaniu http://paglo.com

Widać tu również próbę zlecenia innej firmie obsługi inwentaryzacji naszej
firmy. Przy takim podejściu, rozwiązania oparte w dużej mierze, bądź w całości na open-
source mogą przynosić dochody, klient, czyli firma, płaci w tym przypadku tylko za usługę,
jaką jest zbieranie, przechowywanie, zabezpieczenie i udostępnianie informacji. Własne
rozszerzenia możemy pisać wykorzystując język Ruby. Strona projektu to http://paglo.com.

2.2.5 Zabbix
Projekt nie jest zaliczany do tych, które są nastawione na inwentaryzacje
zasobów komputerowych. Jego głównym założeniami jest monitorowanie stanu maszyn i
usług na tych maszynach działających.
Zastanawiając się nad przykładowym przedsiębiorstwem i zasobami jakie w
nim są, zawsze widzimy komputery użytkowników, drukarki, urządzenia sieciowe. Jeśli
jednak zajrzymy do aplikacji z jakich korzysta przecięty pracownik zobaczymy, iż
zazwyczaj są to usługi udostępniane wewnątrz firmy (email, ftp, samba, cms, systemy pracy
grupowej). Wszystkie te usługi jeśli są utrzymywane przez firmę są udostępniane przez

27

jednostki serwerowe. Jedną z najważniejszych cech jakie powinna posiadać taka jednostka

Rys. 12: Zabbix - okno główne. W opracowaniu http://www.zabbix.com/screenshots.php
jest niezawodność, gdyż od tego czy działa serwer np. WWW zależy czy np. działa nasza
strona przyjmowania zamówień. Inwentaryzowanie takich jednostek, ma oczywiście sens,
jednak z racji tego że najbardziej zależy nam na tym czy serwer działa czy nie, potrzebny
nam system, który będzie monitorował na bieżąco działanie takich jednostek i informował
nas w razie ich niedostępności. Zabbix posiada wyżej wymienione właściwości jak również
możliwość monitorowania dostępności stron www, bądź usług internetowych. Zabbix
napisano w technologii: C (serwer zbierający dane, programy agentów), PHP( panel
administracyjny), dane możemy składować w jednej z baz MySql, PostgeSQL, Oracle,
SqlLite. Strona projektu to http://zabbix.com/ .

28

2.2.6 Pulse2
Projekt stworzony przez firmę Mandriva (twórca dystybucji systemu typu Linux
- Mandriva). Dostępne funkcjonalności:
• szybki interfejs zdalnego podłączania się do maszyny klienckiej z wykorzystaniem
protokołu VNC,
• wgrywanie nowych wersji oprogramowania, uaktualnień bezpieczeństwa na maszyny
zarządzane,
• inwentaryzacja sprzętu i oprogramowania.

Rys. 13: Pulse2 w opracowaniu http://pulse2.mandriva.org/wiki/Screenshots

Część serwerowa odpowiedzialna za zbieranie informacji napisana jest w
języku C, panel administracyjny w PHP, natomiast zbierane dane mogą być przechowywane
w jednej z baz: MySql, PostgreSQL, Oracle, SQLite. Strona projektu to
http://pulse2.mandriva.org . Projekt z powodu wczesnej fazy rozwoju oraz niedużej liczby
wdrożeń produkcyjnych, nie jest brany pod uwagę w tej pracy.

2.2.7 Projekty nierozwijane
Lista projektów nierozwijanych:
• WinInventory http://winventory.sf.net/ . Nastawiony na współpracę z systemami klasy
Windows, zbieranie informacji obywa się poprzez uruchomienie skryptu VBScript na
kliencie. Projekt obecnie już nie rozwijany, jest to protoplasta Open-audIT.
• PCInventory http://www.andrioli.com/en/index.php
• phpMyInventory http://sourceforge.net/projects/phpmyinventory/

29

• Asset-tracker http://asset-tracker.sourceforge.net

Podsumowując, istnieją projekty, rozwijane już od kilku lat, które spełniają nasze
założenia funkcjonalne. Nie ma co prawda jednego, który w pełni i kompleksowo obsługiwał
by nasze przedsiębiorstwo, ale jesteśmy w stanie połączyć ze sobą kilka z nich.

30

3.Koncepcja wykorzystania i dobór oprogramowania klasy open-
source do budowy systemu ewidencji zasobów informatycznych.

3.1 Docelowe przedsiębiorstwo
Planując budowę systemu informatycznego warto jest mieć wyobrażenie, gdzie
będzie stosowany (w jakim typie przedsiębiorstwa). Zakładamy, iż nasze wzorcowe
przedsiębiorstwo posiada hierarchiczną strukturę. Posiada oddziały, które znajdują się w
różnych lokalizacjach. Mogą one podlegać innym oddziałom bądź też same nadzorować inne
placówki. Przy takiej strukturze chcemy, aby była możliwość zarządzania i raportowania dla
poszczególnych oddziałów jak całości. Informacje z poszczególnych oddziałów powinny być
zbierane przez nie same, z możliwością raportowania wyżej. W przypadku mniejszych
pododdziałów powinna być możliwość zlecenia zbierania informacji innemu oddziałowi.
Konkretnym przykładem organizacji, która wpasowuje się w przyjęty schemat
jest Zakład Ubezpieczeń Społecznych (ZUS). Obecnie z usług ZUS korzysta 20 mln
klientów. Struktura organizacyjna ZUS-u w liczbach przedstawia się następująco:
Centrala ZUS
• 42 oddziałów ZUS
• 320 jednostek terenowych
• 1 COO (Centralny Ośrodek Obliczeniowy) przy Centrali ZUS
• około 40 000 stanowisk dostępowych
• ponad 800 serwerów

31

Rys. 14: Struktura ZUS

Patrząc na przykładowe przedsiębiorstwo ZUS widzimy ogromną liczbę
stanowisk dostępowych. Przy tak dużej ilości sprzętu komputerowego bardzo trudno jest nim
zarządzać. Należy zapewnić dostępność, niezawodność oraz odpowiednio zabezpieczyć
stanowiska przed uruchomieniem nielegalnego oprogramowania. Jeśli tego nie zrobimy to
prędzej czy później zaobserwujemy spadek wydajności, który będzie konsekwencją
niedostępności sprzętu komputerowego przez jakiś okres lub przydzielenia pracownikom
sprzętu komputerowego nieadekwatnego do wykonywanej pracy przez nich pracy. Tu pojawia
się też problem niekontrolowania kosztów związanych z zasobami informatycznymi. Podczas
analiz finansowych często podejmowane są złe decyzje, gdyż osoby je podejmujące nie mają
odpowiedniej wiedzy na temat tego jak obecnie sprzęt jest wykorzystywany. W przypadku

32

posiadania nielegalnych: programów, czy też plików, narażamy się również na nałożenie kary
przez organy kontroli.
Zarządzanie zasobami informatycznymi jest ciągłym procesem, w którym należy
efektywnie użytkować, następnie modernizować oraz likwidować zasoby mając na uwadze
potrzeby jakie ma organizacja. Proces ten powinien być przede wszystkim: ekonomiczny,
wydajny pod względem technicznym oraz biznesowym. System, który wspomaga ten proces
powinien zawierać dane o użytkowanym sprzęcie komputerowym, jego szczegółowe
parametry techniczne oraz informacje takie jak: lokalizacja sprzętu, osoba do niego
przypisana, jednostka organizacyjna, w której się znajduje. Oprócz tego system powinien
mieć możliwość generowania przydatnych raportów osobom, które są odpowiedzialne za
obszary finansowe, strategiczne podejmowanie decyzji.
Zarządzanie stacjami roboczymi może przysparzać trudności, gdy stanowiska
znajdują się w różnych lokalizacjach, lub też mamy do czynienia z maszynami przestarzałymi
albo w różnych konfiguracjach. Zarządzanie wszystkimi komputerami o zróżnicowanej
konfiguracji, na poziomie centrali organizacji wymaga zebrania informacji o wszystkich
stanowiskach. Dzięki takim informacjom łatwiej jest podjąć trafną decyzję o :
• wymianie przestarzałego sprzętu,
• obniżeniu kosztów użytkowania, poprzez zliczenie kosztów licencji programów,
• określeniu kosztów utrzymania takiego systemu.

Patrząc na strukturę przykładowej orgranizacji (ZUS), widzimy też dużą liczbę
jednostek serwerowych. Maszyny te są jednak (w większości) użytkowane przez
przeszkolonych administratorów, którzy nie powinni mieć problemów z instalacją
programów, czy też ilością miejsca na dysku. Zbieranie informacji o konfiguracji tych maszyn
ma jak najbardziej sens, gdyż dla nich też trzeba planować modernizacje sprzętowe.
Większym jednak problemem przed jakim stoi administrator tych maszyn jest ich dostępność,
gdyż zazwyczaj udostępniają one usługi z których korzystają aplikacje użytkowane przez
zwykłego pracownika. System do ewidencji zasobów informatycznych może wspomagać
monitorowanie takich jednostek. Jednakże zakres funkcji, które pokrywałyby potrzeby
monitorowania, jest obszerny i raczej nieprzydatny w spotkaniu z przeciętnym komputerem
użytkownika końcowego. Dlatego też takie funkcjonalności powinny być wydzielone do
oddzielnego modułu. Również aplikacja agenta, która przy normalnych maszynach raz na

33

jakiś czas sprawdza co jest na niej zainstalowane, bądź też wyszukuje nowe maszyny w sieci
lokalnej nie nadaje się do ciągłego monitorowania różnych paramentów działania serwera.
Należałoby więc zastosować na tych maszynach specjalne wersje agentów nastawione na
zbieranie takich informacji jak:
• dostępność maszyny,
• dostępność udostępnianych usług(bazy danych, aplikacje www, poczta, ftp itp.),
• obciążenie maszyny.

3.2 Klasyfikacja użytkowników
Przyglądając się strukturze organizacji, oraz jej wymaganiom odnośnie systemu
wyodrębniamy w nim 4 grup użytkowników. Podział ról jest zgodny z funkcjami pełnionymi
przez te osoby w przedsiębiorstwie.

Rys. 15: Typy użytkowników

• pracownik – osoba która użytkuje komputer, który jest do niej przypisany. Osoba ta posiada
jedynie dostęp do modułów help-desk(tj. Zgłaszanie problemów) oraz rezerwacje, tj.
wypożyczenia sprzętu, faq tj. dostęp do listy najczęściej zadawanych pytań,
• analityk biznesowy – posiada wszystkie uprawnienia pracownika oraz może sporządzać
raporty dotyczące wykorzystania oprogramowania, sprzętu,

34

• pracownik help-desk – posiada wszystkie uprawnienia pracownika. Dodatkowo
odpowiedzialny jest za przyjmowanie zgłoszeń od pracowników oraz wprowadzanie
urządzeń niezinwentaryzowanych automatycznie,
• administrator – zajmuje się konfiguracją systemu, jest odpowiedzialny za wprowadzanie
ręcznie danych do systemu tj. informacje o sprzęcie, oprogramowaniu, cenach licencji.
Dodatkowo, każdy użytkownik w hierarchii jest przypisany do swojego oddziału.

3.3 Wykorzystanie modułów open-source do budowy systemu.
Na tle dostępnych programów wyróżnia się OCSI. Został wybrany jako
podstawa tworzonego systemu, gdyż z dostępnych projektów o otwartych źródłach:
• dostarcza najwięcej funkcjonalności (jeśli chodzi o sam proces inwentaryzacji), jest
projektem aktywnie rozwijanym,
• jest projektem wykorzystywanym przez innych, na stronie projektu przykłady wdrożeń
w firmach z liczba agentów powyżej 100 tys.,
• dostarcza agentów na platformy Unix I Windows,
• dostępny na licencji GPL,
• składa się z kilku modułów, dzięki czemu mamy większą możliwość skalowalności
systemu.
Interfejs administracyjny OCSI nie dostarcza jednak wszystkich oczekiwanych
funkcjonalności. Stosując się do zaleceń użytkowników tego systemu oraz twórców
natrafiamy na projekt GLPI, który nastawiony jest na przetwarzanie informacji o
zinwentaryzowanych zasobach. Pozwala on na importowanie danych z wielu systemów OCSI.
Komunikacja jest realizowana przy pomocy protokołu SOAP. Wykorzystując ten protokół
względnie szybko jesteśmy w stanie dostosować inny system zbierania danych tak, by
generował dane w zgodnym formacie. Należy użyć w tym celu informacji z pliku w formacie
WSDL, który jest plikiem XML z opisem dostępnych metod oraz formatu danych. Możliwe
jest również zasilanie przy pomocy plików CSV. Dzięki takiemu podejściu możemy w
poszczególnych oddziałach gromadzić informacje przy pomocy OCSI a na poziomie wyżej
możemy zbierać te informacje, następnie wykorzystywać do generowania raportów np. na
potrzeby działu finansowego. Program pozwala na definiowanie hierarchicznej struktury w
organizacji. Dzięki czemu możemy odwzorować naszą organizację i według tej struktury

35

grupować obiekty zinwentaryzowane. Kolejną ogromną zaletą GLPI jest mnogość
utworzonych rozszerzeń (plugin), które dostarczają kolejnych funkcjonalności. Przykładowe:
• Manufacturers Web Imports – pozwala na importowanie danych o cenie, gwarancji,
dacie produkcji wprost ze strony producenta, współpracuje z Dell, HP, Toshiba i Fujitsu-
Siemens. Rozszerzenie bardzo przydane w dużych korporacjach kupujących sprzęt od
jednego z obsługiwanych producentów,
• Reports – dodatkowe raporty,
• Financial Reports – reporty finansowe,
• Network Architecture – przedstawia w postaci graficznej architekturę sieci.
Wybór powyższych aplikacji podyktowany jest głównie ich wysoką funkcjonalnością i
zaawansowanym stadium rozwoju.

3.4 Struktura systemu.
Przeglądając róż programy do ewidencji widać podobny model architektoniczny,
tj. baza danych i aplikacja, do której poprzez protokół http (bądź https) przesyłane są dane
poprzez poszczególnych agentów. Takie podejście wynika z potrzeby zabezpieczenia każdej
jednostki oddzielnie - by ktoś zdalnie nie mógł wykonać czegoś na naszej maszynie.
Zezwolenie programowi na zdalny dostęp do naszej maszyny i przeszukiwanie jej zasobów
jest zbyt niebezpieczne. W związku z tym stosuje się odwrotne podejście polegające na tym,
iż maszyna użytkownika „sama” wysyła informacje do serwera głównego. Dlatego też
dominuje podejście instalacji agentów na maszynach użytkowników.
Chcąc dostosować nasz system do przedstawionego przedsiębiorstwa, należy
uczynić go jak najbardziej modułowym, tak aby w dużych oddziałach skalowalność systemu
nie była problemem. Jednocześnie usługi, takie jak zbieranie informacji powinny być
dostępne poprzez sieć nie tylko wewnętrzną, ale też poprzez sieć WAN z wykorzystaniem
protokołu HTTPS. Musimy też pamiętać o tym, iż nasz system ma działać w konkretnej
organizacji o określonej strukturze hierarchicznej. Korzyści płynące z zastosowania systemu
mogą być wykorzystywane na różnych szczeblach organizacji.

36

3.4.1 Architektura rozproszona
Architektura zakłada, iż każdy z oddziałów sam zajmuje się zbieraniem informacji od swoich
pracowników. Tak zebrane dane przekazuje do centrali. Rozmieszczenie aplikacji ma
miejsce na poszczególnych poziomach:
• lokalnym (jednostek terenowych) - możemy wykorzystać OCSI do wgrywania na
komputery klienckie oprogramowania. Projekt GLPI dodatkowo wykorzystamy do
obsługi help-desku. Tu przede wszystkim znajdzie się oprogramowanie agentów, które
należy zainstalować na każdej jednostce. Dodatkowo należy określić w projekcie
OCSI, które jednostki z agentami będą odpowiedzialne za wykrywanie
niezidentyfikowanych urządzeń,
• oddziału – tu będą znajdować się serwery OCSI, do których będą spływać informacje
od agentów z podległych placówek(terenowych ośrodków przetwarzania),
• centrali – na tym poziomie interesują nas już tylko funkcjonalności raportujące, a więc
GLPI, skonfigurowany tak aby importował dane z oddziałów.

Rys. 16: Architektura rozproszona

37

Zaletą takiego rozmieszczenia aplikacji jest przeniesienie odpowiedzialności za zbieranie
informacji z oddziału na administratorów w nim pracujących. Osoby, które pracują na
miejscu dużo lepiej będą się orientować jakie obciążenie będzie generowane przez oddział,
oraz na których agentach uaktywnić opcje poszukiwania w sieci lokalnej urządzeń
niezidentyfikowanych.

3.4.2 Architektura scentralizowana
Idąc za ogólnych trendem światowym w informatyce należy również przedstawić
możliwości wykorzystania systemu w modelu scentralizowanym. Z tej racji, iż nasza
przykładowa organizacja posiada wiele oddziałów możemy pokusić się o scentralizowanie
systemu, umożliwiając dostęp do niego w sieci WAN. Wtedy każdy agent będzie wysyłał
informacje pod jeden wspólny adres. Systemy OCSI i GLPI będą zgromadzone w centrali.
GLPI będzie zasilany tylko z jednego źródła. Wymaga to oczywiście zastosowania
wydajniejszych maszyn, mimo to sumaryczne koszty utrzymania mogą być niższe. W tym
modelu jak i w poprzednim na poziomie oddziałów również znajdują się maszyny z
zainstalowanymi agentami.

38

Rys. 17: Architektura scentralizowana

Zalety takiej architektury to przede wszystkim możliwość zainstalowania wszystkich aplikacji
serwerowych w środowisku zwirtualizowanym, wykorzystując takie rozwiązania jak:
Vmware, VirtualBox, PROXMOX. Mamy dzięki temu ułatwione zarządzanie oraz obniżenie
kosztów poboru prądu. Zastosowanie takiej architektury jest możliwe głównie dzięki temu, iż
wykorzystywane projekty to aplikacje dostępne z poziomu przeglądarki po protokole
http/https, a więc użytkownik z najniższego oddziału nie powinien mieć problemów z
dostępem do aplikacji (protokoły http/https nie są blokowane w sieciach korporacyjnych).
Do dalszych testów został wybrany model scentralizowany, który dużo łatwiej
jest wdrożyć w przypadku niewielkiego środowiska testowego.

39

3.5 Monitorowanie serwerów
Problem monitorowania dostępności serwerów i usług, które są przez nie
udostępniane jest zbliżony do problemu inwentaryzacji, jego rozwiązania również jest
podobne. Aby sprawdzić jakie są obecne parametry pracy serwera należy wysłać z niego przy
pomocy „agenta” te informacje do aplikacji gromadzącej dane - czyli sytuacja podobna do
inwentaryzacji. Różnicą jest potrzeba posiadania aktualnych informacji. Dlatego też agent do
monitorowania, to kolejny proces uruchomiony w tle na serwerze. Informacje wysyłane są
przez niego dużo częściej. Wysyłanie informacji odbywa się na żądanie serwera
gromadzącego dane. W przypadku środowiska testowego jedna instancja serwera
monitorującego jest wystarczająca. Programy pełniące role agentów są zainstalowane na
serwerach zarówna na poziomie lokalnym, oddziału jak i centrali. Do konsoli
administracyjnej pozwalającej sprawdzić stan serwerów i usług mają dostęp administratorzy.
Serwer Zabbixa posiada również moduł, który wysyła alerty do określonych osób poprzez
dostępne kanały informacji:
• email,
• wiadomości przy wykorzystaniu protokołu sieci XMPP,
• SMS.
Na maszynach serwerowych również przydatne będzie zainstalowanie agentów dla aplikacji
OCSI, gdyż tu również powinniśmy monitorować sprzęt i zainstalowane oprogramowanie.

40

Rys. 18: Architektura systemu ZABBIX

Podsumowując: dzięki połączeniu aplikacji OCSI, GLPI i ZABBIX jesteśmy w stanie
zbudować system w dużej mierze zaspokajający nasze potrzeby. Korzystając tylko z
gotowych projektów nie zapewniamy obsługi wykrywania na komputerach klienckich
oprogramowania, które jest niepożądane. Wersja polska projektu OCSI nie jest kompletna.
Wykorzystując fakt, iż projekty są otwarto źródłowe, w następnym rozdziale postaramy się
uzupełnić je o brakujące funkcjonalności.

41

4.Projekt wybranych elementów systemu ewidencji zasobów
informatycznych

4.1 GLPI - projekt rozszerzenia do tworzenia listy zakazanego
oprogramowania
Przyglądając się założeniom funkcjonalnym możemy zauważyć, iż
zaproponowane rozwiązanie nie w pełni je spełniają. Dzięki temu, iż wykorzystane systemy
udostępniają swój kod źródłowy jesteśmy w stanie napisać potrzebną nam funkcjonalność.
Przykładową funkcjonalnością, której nie znajdujemy w gotowych projektach jest możliwość
wyszukania na komputerach programów, które są przez nas niepożądane. Taka
funkcjonalność może się przydać do wykrywania oprogramowania, które może służyć do
nielegalnej wymiany plików, oprogramowania, które nie jest przydatne pracownikowi w
pracy (gry), oprogramowania na które nie posiadamy licencji.
Moduł o nazwie „checker”, który będzie implementował tą funkcjonalność
będzie realizował następujące funkcje:
• dodawanie oprogramowania do listy oprogramowania niepożądanego,
• przeglądanie listy oprogramowania niepożądanego,
• usuwanie oprogramowania z listy oprogramowania niepożądanego,
• wyszukiwanie komputerów z zainstalowanym oprogramowaniem znajdującym się na liście
oprogramowania niepożądanego.

Na poniższych diagramach (przypadków użycia i diagramie ERD) elementy oznaczone
kolorem niebieskim to elementy istniejące w systemie, natomiast elementy oznaczone
kolorem czerwonym to elementy dodane.

42

Rys. 19: Rozszerzenie checker - przypadki użycia

Przyglądając się strukturze bazy danych projektu GLPI, na podstawie
przypadków użycia widzimy, iż interesują nas tabele odpowiedzialne za listę użytkowników,
a dokładniej za listę komputerów, oraz tabele zawierające informacje o zainstalowanych na
nich programach. Po analizie schematu bazy danych wyodrębniamy następujące obiekty:
• glpi_users – informacje o użytkownikach,
• glpi_computers – informacje o komputerach, oraz do kogo należą,
• glpi_software – informacje o znanym oprogramowaniu,
• glpi_inst_software – informacje o tym jakie programy zainstalowane są na konkretnym
komputerze.

43

Rys. 20: Diagram ERD przedstawiający modifikacje w bazie danych(nowe tabele oznaczone kolorem czerwonym)

Chcąc obsłużyć funkcjonalność listy programów niechcianych, tworzymy tabelę
która będzie przechowywać informacje o programach, oraz jaki status ma to oprogramowanie.
Nasza tabela zgodnie z konwencją narzuconą przez dokumentację do tworzenia rozszerzeń w
GLPI, powinna mieć nazwę glpi_plugin<nazwa_rozszerzenia>[_nazwa_opcjonalna], czyli
glpi_plugins_checker_softwares.

4.2 Projekt architektury sprzętowo systemowej.
Wykorzystując jedną z dwu przedstawionych architektur, zawsze mamy do
czynienia z ścieżką OCSI-agent → OCSI-server → GLPI. Przedstawiona jest ona dokładniej
na poniższym schemacie. Widzimy tu wielokrotne wykorzystanie bazy MySql oraz serwera
aplikacji Apache, również projekt Zabbix może wykorzystywać bazę MySql. W przypadku
mniejszych instalacji systemy mogą być uruchomione na jednej maszynie, oraz korzystać z
jednej instalacji serwera bazy danych i serwera www.

44

Rys. 21: Architektura systemu

Mimo próby informatycznego wsparcia procesu inwentaryzacji pewne
czynności muszą być wykonywane ręcznie. Należy manualnie wprowadzać informacji o
sprzęcie, który nie został zinwentaryzowany do systemu GLPI. Również ręcznie musimy
stworzyć strukturę hierarchiczną przedsiębiorstwa.

4.3 Projekt wykorzystania systemu przez grupy pracowników
Bazując na klasyfikacji użytkowników z rozdziału 3, oraz możliwościach
systemów OCSI i GLPI należy określić z jakich kont mogą korzystać poszczególne grupy
pracowników. Wykorzystanie poszczególnych systemów przez grupy użytkowników zostało
przedstawione na rysunku 29. Większość grup pracowników korzysta wyłącznie z systemu
GLPI, używając kont wraz z odpowiadającymi im uprawnieniami:
• analitycy biznesowi – konta typu „normal”,
• pracownicy – konta typu „post-only” ,
• help-desk – konta typu „tech”.
• grupa pracowników administracyjnych ma dostęp do OCSI i GLPI.

45

Rys. 22: Przypisanie grup użytkowników do poszczególnych systemów

Podsumowując z przedstawionych tu możliwych struktur systemu
(scentralizowana, bądź rozproszona), do dalszych rozważań zostanie przyjęta wersja
scentralizowana. Za ta opcją przemawia mniejsza liczba sprzętu potrzebna do
przeprowadzenia podstawowej instalacji. Projekt rozszerzenia zostanie stworzony w języku
PHP, wedle specyficznych wytycznych zamieszczonych na stronie projektu GLPI.

46

5. Implementacja systemu ewidencji zasobów informatycznych

5.1 OCSI - poprawki do języka polskiego
W przypadku OCSI, nie posiada on dobrej polskiej wersji językowej. W celu jej
poprawienia musimy dowiedzieć się w jaki sposób realizowana jest internacjonalizacja
(obsługa wielu języków). Po krótkim przeglądaniu kodu projektu znajdujemy katalog
plugins/language/polish/. W katalogu tym znajdziemy plik odpowiedzialny za tłumaczenia.
Nie zawiera on wszystkich tłumaczeń, brakujące wpisy skopiujemy z katalogu
plugins/language/english/english.txt. Przy domyślnej instalacji i próbie włączenia obsługi
rodzimego języka otrzymujemy częściową polonizację jednak napisy z polskimi znakami nie
są wyświetlane poprawnie. Problem stanowi tutaj rozbieżność pomiędzy kodowaniem pliku z
napisami (które jest ustawione na ISO-8859-2), a kodowaniem przyjętym na stronie HTML
(ustawione jest UTF-8). Moglibyśmy skonfigurować aplikację w taki sposób, aby strona
HTML była w wyświetlana z użyciem kodowania ISO-8859-2, niestety mogłoby to
spowodować problemy z innymi językami, poza tym wymaga to również od nas dodatkowych
zmian w konfiguracji strony. Najprostszym i najlepszym rozwiązaniem będzie tutaj zmiana
kodowania pliku na uniwersalny UTF-8.
Twórcy OCSI rozwijają swój projekt w serwisie http://launchpad.net , który
wspomaga rozwój rozproszonych projektów open-source. Wykorzystywanym systemem
kontroli wersji jest bazaar, który tak jak git wspomaga rozproszone tworzenie
oprogramowania. Każda nowa funkcjonalność tworzona jest w oddzielnej gałęzi (branch),
która jest tworzona na podstawie głównego kodu(trunk). Wprowadzone zmiany należy
zatwierdzić (bzr commit) i wypchnąć do repozytorium zdalnego (bzr push). Następnie w
serwisie launchpad.net należy zgłosić propozycję dokonania złączenia (merge) naszej gałęzi z
gałęzią rozwojową (trunk). Dalej osoba odpowiedzialna za przeglądanie kodu dołącza (merge)
gałąź rozwojową do gałęzi głównej. Pozwala to na proste i przejrzyste zarządzanie nowymi
funkcjonalnościami. Dzięki temu mamy pewność że do głównego kodu wchodzą tylko te
funkcjonalności, które zostały zaakceptowane przez osoby upoważnione.

47

Rys. 23: bazaar - praca rozproszona. W opracowaniu http://bazaar-vcs.org

W celu rozpoczęcia modyfikacji kodu, musimy zarejestrować się w serwisie
http://launchpad.net, a następnie zainstalować oprogramowanie bazaar.

sudo apt-get install bzr

Pobieramy aktualny kod wersji rozwojowej

bzr branch lp:ocsinventory-ocsreports

#aktualizacja naszego kodu z gałęzią główną

bzr update

Następnie chcąc wprowadzać i publikować nasze zmiany musimy skonfigurować nasze konto
na launchpad.net

#w poleceniach podajemy nasz login i email

#użyty przy rejestracji (morii, piotr.bliszczyk@gmail.com)

bzr launchpad-login morii

bzr whoami "Piotr Bliszczyk <piotr.bliszczyk@gmail.com>"

48

bzr whoami

Po dokonaniu zmian należy je zatwierdzić (commit)

bzr commit -m 'opis wprowadzonych zmian, np. fixes in polish language file'

Teraz pozostaje nam wysłanie (push) zmian do repozytorium zdalnego (repozytorium
zdalnym jest nasza własna prywatna gałąź (branch)), pierwszy raz musimy podać jego
lokalizację.

bzr push lp:~piotr-bliszczyk/ocsinventory-reports/layout_fixes

Możemy teraz zobaczyć zmiany w serwisie, oraz np. zaproponować dołączenie naszych
poprawek do kodu rozwojowego https://code.launchpad.net/~piotr-bliszczyk/ocsinventory-
ocsreports/layout_fixes. Nim zmiany pojawią się w wydaniu stabilnym minie trochę czasu.
Aby dołączyć je już do nasz istniejącej instalacji należy przekopiować plik z tłumaczeniami
na serwer.

scp -r ocsinventory-ocsreports/plugins/language/polish/ ubuntu@ubuntu-server:~/.

sudo cp polish/polish.* /usr/share/ocsinventory-server/ocsreports/languages/.

sudo /etc/init.d/apache2 restart

5.2 Implementacja rozszerzenia dla GLPI
Projekt GLPI rozwijany jest z wykorzystaniem serwisu http://forge.indepnet.net
i systemu kontroli wersji SVN. Projektanci tego systemu dużą wagę przywiązali do
opracowania spójnego i funkcjonalnego api, które może być wykorzystywane przez
rozszerzenia. Przed rozpoczęciem prac warto włączyć tryb debugowania ( http://www.glpi-
project.org/wiki/doku.php?id=en:config:debug). Chcąc zaimplementować interesującą nas
funkcjonalność zapewne wystarczy napisanie rozszerzenia zgodnie z zaleceniami
znajdującymi się na stronie projektu. Instrukcja tworzenia rozszerzeń dostępna jest pod
adresem: https://forge.indepnet.net/wiki/plugins/WikiStart . Na wiki znajdziemy wiele
wytycznych:
• tabele
• nowo tworzone tabele nazywamy wedle schematu
glpi_plugin_<nazwa_rozszerzenia>_XXXX
• jeśli używasz tabl dla list rozwijanych to nazywamy je wedle schematu
glpi_dropdown_plugin_<nazwa rozszerzenia>_XXXX

49

• struktura katalogów
• pliki związane z rozszerzeniem umieszczamy w folderze o nazwie
plugins/<nazwa_rozszerzenie>
• "locales": zawiera pliki tłumaczeń
• wymagane pliki: fr_FR.php / en_GB.php
• "docs": zawiera dokumentację
• pliki: Readme.txt, Lisezmoi.txt, Roadmap.txt, Changelog.txt
• "inc": zawiera pliki z klasami i funkcjami (klasy to np. klasa odpowiadająca za
mapowanie tabeli z bazy danych)
• pliki zawierające funkcje nazywamy wedle schematu:
plugin_<plugin_name>.db.function.php
• pliki zawierające funkcje nazywamy wedle schematu:
plugin_<plugin_name>.db.class.php
• "front": pliki formularzy
• schemat nazw dla plików
• formularze tworzące/edytujące obiekt: plugin_<plugin_name>.<object>.form.php
• formularze wyświetlające obiekt : plugin_<plugin_name>.php
• "pics" : obrazki
• "ajax" : obsługa AJAX np. obsługa „massive actions”
• wymagane pliki w katalogu plugins/<nazwa_rozszerzenia>/
• hook.php – funkcja instalacji/de-instalacji (tworzenie i usuwanie tabel), funkcje
definiujące w jaki sposób rozszerzamy obecne funkcjonalności np. dodawanie nowych
przycisków na stronie oprogramowania
• setup.php – dane o rozszerzeniu/twórcy, sprawdzanie wersji GLPI, sprawdzanie
konfiguracji, określenie położenie rozszerzenia w menu
• opcjonalnie index.php - strona która wyświetli się jako pierwsza
• nazwy funkcji i klas
• dla klas stosujemy notację Camel Case : class Plugin<Plugin_name>Xxxx (np :
PluginExampleDisplay)
• dla funkcji stosujemy notację z podkreśleniami: function
plugin_<plugin_name>_<function> (np. : plugin_example_getType())

50

Podsumowując, należy ściągnąć źródła przykładowego projektu
(https://forge.indepnet.net/tarballs-plugins/example.tar.gz) a następnie rozwijać go. Przy
próbie uruchomienia przykładowego rozszerzenia, instalacja kończy się niepowodzeniem. W
związku z tym jako „wzorcowe rozszerzenie” został użyty plugin „Validation”. Na jego bazie
zostały stworzone:
• funkcje instalacyjne, tworzące potrzebne tabele (plik hook.php):

function plugin_checker_install() {

$query = "CREATE TABLE `glpi_plugin_checker_softwares` (

ID INT NOT NULL AUTO_INCREMENT,

id_software INT NOT NULL,

status VARCHAR(50) NOT NULL DEFAULT 'blacklist',

comments VARCHAR(255),

PRIMARY KEY (`ID`)

) TYPE=MyISAM;";

• funkcje definiujące nowe akcje na zakładce Oprogramowanie

function plugin_checker_MassiveActions($type) {

switch ($type) {

case SOFTWARE_TYPE:

return array(

"plugin_checker_add_to_blacklist"=>"Dodaj do czarnej listy"

• definicja nawigacji w menu (plik setup.php)

function plugin_init_checker() {

$PLUGIN_HOOKS['redirect_page']['checker'] = "front/plugin_checker.checker.php";

$PLUGIN_HOOKS['menu_entry']['checker'] = true;

$PLUGIN_HOOKS['helpdesk_menu_entry']['checker'] = true;

$PLUGIN_HOOKS['submenu_entry']['checker']['search'] = 'index.php';

$PLUGIN_HOOKS['submenu_entry']['checker']['add'] = 'add.php';

Instalacja rozszerzenia polega na skopiowaniu katalogu z gotowym
rozszerzeniem do katalogu produkcyjnego plugins/ projektu GLPI.

51

cd plugins

sudo cp -r checker /var/www/glpi/plugins/.

Następnie na stronie zarządzania dodatkami (Ustawienia → Dodatki
http://localhost/glpi/front/setup.plugins.php) powinniśmy zobaczyć nasze rozszerzenie. Na
tej stronie możemy również odinstalować dodatki.

Rys. 24: Instalacja stworzonego rozszerzenia

Musimy teraz kolejno zainstalować, oraz aktywować nasze rozszerzenie. Nowa
funkcjonalność powinna być dostępna w menu Dodatki → Checker.

5.3 Instalacja systemu ewidencji
Przedstawione instalacja jest instalacja okrojoną i ma na celu pokazanie
konfiguracji, w której mamy do czynienia ze ścieżką przepływu danych OCSI-agent → OCSI-
server → GLPI. Przedstawiona tutaj architektura jest zbliżona do zaproponowanej
architektury scentralizowanej przedstawionej w rozdziale 5.3.1 , tj. zakładamy, iż na jednej
maszynie mamy zainstalowane wszystkie elementy systemu odpowiedzialne za zbieranie
informacji i ich przetwarzanie. Wykorzystane środowisko do przykładowego wdrożenia to
zestaw maszyn zbudowanych w oparciu o system do wirtualizacji VirtualBox firmy SUN,
udostępniany na licencji GPL.

52

Rys. 25: Konfiguracja serwera

Jako serwer aplikacji OCSI i GLPI posłuży nam maszyna z dystrybucją Ubuntu-Serwer 9.10.
Maszyny klienckie to 2 komputery z systemem Ubuntu-Desktop 9.10 oraz 2 komputery
Windows XP, Windows 7.

5.3.1 Instalacja i konfiguracja OCSI
Do instalacji wymagany jest serwer www z obsługą języków PHP, Perl, baza
danych MySql, program nmap. Do działania narzędzia Deploy musimy skonfigurować
obsługę protokołu HTTPS, wykorzystamy do tego własnoręcznie wygenerowany i podpisany
certyfikat.

sudo aptitude update

sudo aptitude install mysql-client #instalacja bazy danych

sudo aptitude install mysql-server

#serwer www, php perl

sudo aptitude install apache2 libapache2-mod-php5 libapache2-mod-perl2 php5-mysql

nmap

#communication server i deployment server

53

sudo aptitude install ocsinventory-server

sudo aptitude install ocsinventory-reports #konsola administracyjna

sudo aptitude install ocsinventory-agent

#konfiguracja narzędzia Deploy

sudo mkdir -p /var/lib/ocsinventory-reports/download

sudo chmod -R o+rw /var/lib/ocsinventory-reports/

#konfiguracja protokołu https w serwerze apache

#wykorzystanie certyfikatu z własnym podpisem

sudo aptitude install ssl-cert

sudo a2enmod ssl

sudo a2ensite default-ssl

sudo make-ssl-cert generate-default-snakeoil --force-overwrite


cd /etc/ssl/certs/

sudo cp ssl-cert-snakeoil.pem cacert.pem

Następnie otwieramy w przeglądarce http://ubuntu-server/ocsreports. Domyślny login i hasło
to: admin/admin.

5.3.2 Instalacja i konfiguracja GLPI
Wymagania systemu to serwer www z obsługą języka PHP oraz baza danych
MySql. Z racji iż oprogramowanie instalujemy na tej samej maszynie co OCSI,
wykorzystamy zainstalowany już serwer Apache oraz stworzymy oddzielny schemat w bazie
danych, o nazwie glpi. Pozostaje nam ściągnięcie najnowszej paczki ze strony projektu,
przekopiowanie plików na katalogu stron www oraz dokończenie instalacji pod adresem
http://ubuntu-server/glpi .

wget http://www.glpi-project.org/IMG/gz/glpi-0.72.3.tar.gz

tar -xzf glpi-0.72.3.tar.gz

sudo cp glpi /var/www/.

sudo chown -R root.root /var/www/glpi

54

# dokańczamy instalacje na http://ubuntu-server/glpi

#zmieniamy parametry których nie spełnia nasza obecna konfiguracja, min limit

przydzielonej pamięci dla skryptu PHP

sudo vim /etc/php5/apache2/php.ini

memory_limit = 64M

#aby zmiany były widoczne musimy zrestartować serwer www


#nadajemy uprawnienia do zapisu do katalogów files i config

sudo chmod -R o+w /var/www/glpi/files

sudo chmod -R o+w /var/www/glpi/config

W konfiguracji połączenia do bazy danych podajemy:

mysql_server: 127.0.0.1

mysql_user: root

mysql_password: ubuntu

database_name: glpi

Jeśli proces instalacji przebiegł pomyślnie powinniśmy otrzymać informacje o domyślnych
użytkownikach w aplikacji

Default logins / passwords are:

* glpi/glpi for the administrator account

* tech/tech for the technician account

Następnie chcemy skonfigurować synchronizację z OCSI, w tym celu logujemy się do
aplikacji na użytkownika admin/admin i w zakładce Ustawienia -> Ustawienia ->

Aktywuj tryb OCSNG aktywujemy obsługę OCSI.

W zakładce Ustawienia -> OCS-inventory podajemy dane dostępowe do systemu
OCSI, w tym miejscu możemy skonfigurować import z wielu systemów OCSI.

55

Rys. 26: GLPI - ustawiania bazy danych OCSI

Przed importem musimy w OCSI przenieść wykryte oprogramowanie z kategorii „NEW” do
„UNCHANGED”, operację wykonujemy wchodząc do zakładki „DICTIONARIES”, dzięki
temu zostanie ono zaimportowane do GLPI.

Rys. 27: OCSI - oprogramowanie

Pozostaje nam już tylko zaimportować dane wchodząc do zakładki Narzędzia -> OCSNG
-> Importuj nowe komputery

Rys. 28: GLPI - import z OCSI

56

5.3.3 Instalacja i konfiguracja Zabbix
Oprogramowanie Zabbix instalujemy na serwerze głównym, wymagany jest tu
serwer aplikacji np. Apache oraz baza danych MySql. Programy monitorujące (zabbix-agent)
instalujemy tylko na serwerach, które chcemy monitorować, podczas tej instalacji musimy
tylko podać adres serwera zabbix. Instalacja oprogramowania na serwerze sprowadza się do
instalacji z gotowych paczek, dostępna wersja to 1.6, jeśli chcemy użyć najnowszej wersji
musimy instalować system ze źródeł. Podczas instalacji podajemy jedynie hasło do bazy
danych.

sudo aptitude install zabbix-server-mysql

sudo aptitude install zabbix-frontend-php

Jeśli po instalacji nadal mamy problemy z połączeniem do bazy, należy sprawdzić plik

/etc/zabbix/dbconfig.php

Jeśli nie mamy poprawnie ustawionej strefy czasowej w konfiguracji Apache, zmieniamy to
poprzez ustawienie date.timezone = „Europe/Warsaw” w pliku konfiguracjnym

sudo vi /etc/php5/apache2/php.ini

Instalacja na maszynach klienckich sprowadza się do zainstalowania paczki zabbix-agent i
modyfikacji pliku /etc/zabbix

sudo aptitude install zabbix-agent

sudo vi /etc/zabbix/zabbix_agent.conf

Pozostaje nam już tylko konfiguracja serwera poprzez panel administracyjny, dostępny pod
adresem http://ubuntu-server/zabbix/ . Domyślny login i hasło to: admin/zabbix. Dodajemy
obserwowanie maszyny na zakładce Configuration → Hosts → Create Host.

5.4 Konfiguracja systemu ewidencji dla instytucji o strukturze
rozproszonej
W celu pełnego wykorzystania możliwości programu GLPI w przedsiębiorstwie
rozległym, przed przystąpieniem do właściwej inwentaryzacji należy odtworzyć strukturę
organizacji w projekcie. W tym celu musimy zdefiniować:

57

• użytkowników wedle grup, które zostały zdefiniowane w rozdziale 4.3,
• oddziały oraz hierarchie pomiędzy nimi,
• lokalizacje tj. spis miast z określeniem przynależności do miast nadrzędnych,
• użytkowników tj. poczynając od pracowników, kończąc na administratorach.
Przed stworzeniem użytkowników powinniśmy zdefiniować grupy do których
będą przypisaniu. Wykonujemy to na zakładce Administracja → Grupy.

Rys. 29: GLPI - definiowanie grup użytkowników

Uzupełniamy listę grup wedle diagramu z rys. 22.

Rys. 30: GLPI - zdefiniowane grupy

Projekt GLPI pozwala na odtworzenie hierarchicznej struktury naszego
przedsiębiorstwa. Oddziały i pododdziały definiujemy jako użytkownik z uprawnieniami
„super-user” w sekcji Administracja → Oddziały. Najpierw dodajemy oddziały wojewódzkie,
a następnie do każdego z nich poszczególne oddziały terenowe.

Rys. 31: GLPI - definiowanie struktury hierarchicznej przedsiębiorstwa

Powinniśmy jeszcze zdefiniować lokalizacje w jakich mogą znajdować się
komputery. Dokonamy tego w zakładce Ustawienia → Listy rozwijane → Lokalizacje.

58

Wprowadzanie tych danych ręcznie przez administratorów jest zadaniem żmudnym, dlatego
należy posłużyć się plikami csv i poleceniem LOAD DATA INFILE w bazie MySql. Tak samo
możemy postąpić w przypadku wprowadzenia pracowników do systemu. Jeśli chcemy
wykonać dodawanie pracowników ręcznie powinniśmy udać się do zakładki Administracja →
Użytkownicy → Dodaj użytkownika.

Rys. 32: GLPI - dodawanie nowego użytkownika

W celu lepszego wykorzystania informacji zgromadzonych w GLPI, możemy
zainstalować dodatkowe rozszerzenia, przykładowym rozszerzeniem jest pakiet z
dodatkowymi raportami - „Reports”. Pobieramy go ze strony projektu (http://plugins.glpi-
project.org/ ) i instalujemy poprzez rozpakowanie do folderu /plugins w katalogu instalacji
programu. Następnie należy aktywować go na zakładce Administracja → Dodatki. Dopiero
po ponownym zalogowaniu w zakładce Narzędzia → Raporty zobaczmy nowe opcje.
Domyślnie wszystkie raporty mogą wykonywać użytkownicy z uprawnieniami super-admin,
możemy to zmienić na zakładce konfiguracji dodatku Administracja → Dodatki → Reports.
Po instalacji dostajemy do dyspozycji nowe rodzaje raportów oraz narzędzie do prostszego
tworzenia własnych raportów, tj. do stworzenia raportu wystarczy nam jeden plik PHP, nie
musimy tworzyć oddzielnego rozszerzenia.

59

Rys. 33: GLPI - dodatkowe raporty

Po zdefiniowaniu wszystkich wymaganych użytkowników oraz poprawnej
konfiguracji połączenia OCSI z GLPI (opis konfiguracji w rozdziale 5.3.2) , możemy
przystąpić do codziennego monitorowania zmian oraz wykonywania okresowych raportów
zbiorczych. Decydując się na wykorzystanie modułu help-desk, powinniśmy poinstruować
użytkowników o parametrach dostępu do niego oraz zasadach i sposobie jego użytkowania.

5.5 Proces inwentaryzacji
Mając zainstalowane systemy składowe możemy przejść do uruchomienia
procesu inwentaryzacji. Mówimy tutaj o procesie, gdyż inwentaryzacja zasobów
informatycznych powinna być działaniem wykonywanym ciągle, bądź też okresowo.
Spowodowane jest to ciągłymi zmianami polegającymi na zakupie sprzętu, wymianie
jednostek przestarzałych, rotacji pracowników, instalacji oprogramowania, użytkowaniem
systemu. W procesie inwentaryzacji możemy wyróżnić następujące etapy:
• instalacja/konfiguracja,
• inwentaryzacja automatyczna,
• inwentaryzacja ręczna,
• raportowanie.
W pierwszym etapie musimy zainstalować oprogramowanie „agentów” na
maszynach klienckich. Należy podjąć decyzję o tym, które maszyny będą miały uaktywnioną
opcję „Ip discover”, tak by zbierały informacje o urządzeniach z sieci lokalnej, na których nie

60

może być zainstalowany „agent”. Instalacje możemy przeprowadzić ręcznie, jednak w
przypadku tak dużej organizacji jak ZUS mija się to z celem. Wykorzystamy więc program
OCS Inventory NG Agent Deployment Tool, służący do zdalnej instalacji agentów na
maszynach klienckich. Program dostępny jest tylko dla systemów klasy Windows, mimo to
możemy uruchomić go także na systemie klasy Linux, wykorzystując projekt WINE
(http://www.winehq.org/). Jest on: „warstwą tłumaczącą (ładującą programy) zdolną
uruchomić Windowsowe aplikacje na Linuksie i innych systemach operacyjnych zgodnych z
POSIXem” (http://www.winehq.org/about/ ). Używając OCS Inventory należy określić zakres IP
komputerów, na których zostanie przeprowadzona instalacja.
Dla komputerów z zainstalowanym systemem typu Windows, pracujących w
domenie, możemy wykorzystać inny sposób instalacji. Należy wykorzystać narzędzia
administracyjne (mechanizm GPO) i zdefiniować skrypt logowania, który uruchomi instalację
agenta.

61

Rys. 35: Ręczne dodawanie
informacji o monitorze

Rys. 34: źródło: http://wiki.ocsinventory-ng.org/index.php/Tools:Packager

Po instalacji i wskazaniu serwera zbierającego dane (w naszym przypadku
ubuntu-server), agent po raz pierwszy wyśle dane. Automatyczne uruchamianie agenta, który
wysyła informacje, odbywa się dzięki programowi cron dla systemów typu Linux. Domyślnie
agent będzie uruchamiany raz dziennie.
Ręczne dodawanie informacji jest realizowane przez system GLPI, w systemie
OCSI moglibyśmy jedynie importować stosowne pliki CSV, aczkolwiek nie jest to
najwygodniejsze rozwiązanie. Do ręcznego dodawania informacji możemy stworzyć
odpowiednie konto, będzie je wykorzystywał pracownik z oddziału lokalnego.

62

Projekt systemu ewidencji zasobów informatycznych z wykorzystanie oprogramowanie open source

Projekt systemu ewidencji zasobów informatycznych z wykorzystanie oprogramowanie open source

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Projekt systemu ewidencji zasobów informatycznych z wykorzystanie oprogramowanie open source

Similar to Projekt systemu ewidencji zasobów informatycznych z wykorzystanie oprogramowanie open source (20)

Projekt systemu ewidencji zasobów informatycznych z wykorzystanie oprogramowanie open source