Politechnika Opolska

Wielkość: px
Rozpocząć pokaz od strony:

Download "Politechnika Opolska"

Transkrypt

1 Politechnika Opolska Wydział Elektrotechniki, Automatyki i Informatyki Instytut Automatyki i Informatyki PRACA DYPLOMOWA inżynierska Rozproszona biblioteka elektroniczna oparta o platformę LAMP Promotor: dr hab. inż. Jan SADECKI prof. PO Pracę wykonał: Julian HOROSZKIEWICZ Opole, kwiecień 2010

2 ROZPROSZONA BIBLIOTEKA ELEKTRONICZNA OPARTA O PLATFORMĘ LAMP S t r e s z c z e n i e Praca przedstawia teoretyczne i praktyczne aspekty zaprojektowania, implementacji oraz wdrożenia koncepcji rozproszonego systemu zasobów. Na zasoby składają się przechowywane na wszystkich węzłach pliki, opatrzone stosownym zestawem metadanych; standardowych atrybutów oraz informacją na temat stanu synchronizacji plików. Rozważono dwa scenariusze rozproszenia, replikację oraz klaster. Jako przykład zastosowania wybrane zostało repoztorium książek elektronicznych zwane dalej biblioteką. Dokonano analizy oraz projektu systemu z pomocą nowoczesnych narzędzi inżynierii oprogramowania. Ustalono i rozwiązano problemy spójności, koordynacji oraz niezawodności. Uzasadniono wybór platformy, na której zdecydowano się dokonać implementacji. Opisano implementację oraz wdrożenie, a także związane z nią jak i z architekturą oraz platformą aspekty bezpieczeństwa. Wszystko to podsumowane jest dostrzeżonymi wadami oraz zaletami rozwiązania, przedstawiona jest perspektywa dalszego rozwoju oraz utrzymania projektu. DISTRIBUTED LAMP RESOURCES SYSTEM S u m m a r y This project introduces theoretical and practical aspects of design, implementation, deployment and maintainance of distributed resources system. So called resources consist of files distributed through all system nodes, related metadata consisting of standard attributes, fulfilled with information needed for coordination of files synchronization process. There's been considerated two distribution scenarios, replication and clustering. Standard analysis and project were made with the use of modern software engineering instruments. Common distributed systems problems, such as convergence, synchronization and reliability were identified and solved. Also there's been formulated advocacy and argumentation of choosen platform and ideology. Implementation and deployment details were discussed, so as all known implementation, platform and architecture specific security issues. All of this is concluded with revealed vices and virtues of the solution and its policy. Also future development and maintainance perspective has been considered. 2

3 Plan pracy 1. Wstęp, czyli cel i zakres pracy 5 2. Wycinek rzeczywistości 6 3. Scenariusze; architektura sieci 7 4. Platforma GNU/Linux 2. Apache HTTP Server 3. MySQL 4. PHP 1. ViLDeV 5. rsync+ssh 5. Struktura organizacyjna plików Synchronizacja zasobów Zagrożenia wyścigowe Analiza, projekt użytkownicy, grupy 2. diagram przypadków użycia 3. diagram klas 4. diagram komponentów 5. diagramy sekwencji 6. diagramy stanów 7. diagram wdrożenia 9. Implementacja PHP 1. ViLDeV 2. moduły DLRS 3. skrypt kolejkujący synchronizacje plików 4. skrypt do zautomatyzowanego katalogowania zasobów 2. MySQL 10. Bezpieczeństwo Apache HTTP Server 2. PHP 3. MySQL 4. GNU/Linux 5. poufność, uwierzytelnianie, integralność 6. pozostałe 11. Wdrożenie ViLDeV + DLRS 2. MySQL z replikacją 3. SSH+rsync 3

4 12. Rozbudowa, utrzymanie, administracja Licencja Wnioski i uwagi; podsumowanie Bibliografia 100 4

5 1.Wstęp; dlaczego DLRS? DLRS (Distributed LAMP (GNU/Linux Apache MySQL PHP) Resources System) to rozproszony system współdzielenia zasobów. Głównym powodem powstania projektu była potrzeba stworzenia bezpiecznej, rozproszonej bazy danych z książkami elektronicznymi, która automatycznie dba o swoją spójność, a dzięki decentralizacji jest znacznie bardziej niezawodna, odporna na awarie, w tym klęski żywiołowe i ataki DoS (Denial of Service), a także pozwala na rozłożenie pracy związanej z obsługą użytkowników. Dzięki dostępowi poprzez interfejs webowy spełnia również wymogi dostępności i uniwersalności, spełniając jednocześnie pewne cechy sieciowego systemu plików, pozwalając na precyzyjne określanie przywilejów dla wielu różnych zasobów w środowisku wieloużytkownikowym. Dokładna realizacja tego zadania wymagała podjęcia prac na wielu płaszczyznach; programowania rozwiązań web oraz konsolowych, projektowana i programowania baz danych, inżynierii systemów rozproszonych, a również w szerokim stopniu prac administracyjnowdrożeniowych. Poza aspektem praktycznym, wybór tematu był ukierunkowany wyłącznie ideologią oraz osobistym pomysłem na połączenie zagadnień wchodzących w skład zainteresowań i doświadczeń autora. 5

6 2.Wycinek rzeczywistości Na kilku skoordynowanych serwerach nazywanych dalej węzłami funkcjonuje biblioteka elektroniczna, na którą składają się książki w postaci plików w dowolnych formatach i praktycznie dowolnych rozmiarach. Każda z nich może należeć do pewnej kategorii. Baza metadanych opisujących encję książki, zawierających podstawowe informacje na jej temat, bez samych danych jej pliku, utrzymywana i zarządzana jest przez serwer baz danych, zazwyczaj, choć niekoniecznie na tej samej fizycznej czy wirtualnej maszynie. Serwery mogą tworzyć zdecentralizowaną sieć www korzystającą ze zdecentralizowanej sieci serwerów baz danych, zazwyczaj serwer www oraz serwer bazy danych znajdować się bedą na tym samym hoście, przy tymże założeniu utrzymana jest dalsza część pracy. Użytkownik za pomocą przeglądarki łączy się z którymkolwiek z węzłów i dokonuje uwierzytelnienia. Dla estetyki można utworzyć wszystkim po subdomenie we wspólnej domenie, w użytych w projekcie przykładach będą to domeny itathome.pl, n0life.pl. Do dyspozycji użytkownika jest lista aktualnie znajdujących się w systemie książek, wyszukiwarka oraz panel administracyjny do umieszczania, edycji i usuwania plików, jak i interfejs do zarządzania własnym kontem lub także skromną konfiguracją węzłów sieci, jeśli użytkownik ma status administratora węzła. Nowe pliki mogą zostać dodane przez każdego użytkownika należącego do grupy uploaderów oraz administratora. Modularna budowa wybranego systemu webowego pozwala na łatwe rozszerzanie funcjonalności w przyszłości. W wersji bieżącej dostępny jest opcjonalnie między innymi system newsów, który jest integralną częścią wybranego do realizacji zadania systemu web. Spójność pomiędzy węzłami w warstwie bazodanowej jest kontrolowana prze sam system bazodanowy; replikację lub silnik klastrowy. Synchronizacja na poziomie systemu plików na węzłach przebiega asynchronicznie z pomocą osobnego skryptu będącego częścią DLRS, implementującego własny, odporny na awarie algorytm podtrzymywania spójności. 6

7 3. Scenariusze; architektura sieci Z punktu widzenia użytkownika scenariusz jest jeden; może on połączyć się z dowolnym węzłem w systemie, dokonać uwierzytelnienia a następnie wykonywać przewidziane dla niego przypadki użycia, tj. korzystać z zasobów jak też tworzyć własne. Nie ma dla niego znaczenia, jak sytuacja faktycznie rozgrywa się w bazie danych, można więc założyć, że z punktu widzenia użytkownika sieć jest zupełnie zdecentralizowana. Wyjątkiem jest sytuacja, w której przy korzystaniu z wersji replikacyjnej (o czym dalej) nie działa host pełniący rolę węzła głównego (tzw. master, wtedy system dostępny jest tylko do odczytu, niemniej nadal funkcjonuje). Z punktu widzenia administratorów oraz węzłów, pomijając instancje systemu składające się z jednej maszyny (tzw. instalacja standalone, niewymagająca żadnej synchronizacji na poziomie zarówno baz jak i plików), architektura systemu oparta jest o założenie, że każdy z węzłów ma pełną informację na temat węzłów pozostałych. Tyczy się to również informacji o stanie danego zasobu na danym węźle, tj. czy określony plik fizycznie znajduje się na wskazanym węźle, gdyż jeśli nie, oznacza to, że nie zakończył się jeszcze proces jego synchronizacji. Rozproszona baza danych jest traktowana z punktu widzenia użytkowego atomowo, tj. utrzymujemy założenie, że na każdym z węzłów baza danych posiada identyczną zawartość. Do tego potrzebne jest utrzymanie spójności, synchronizacja w zapisie tych samych zasobów i sprostanie zagrożeniom wyścigowym. Z punktu widzenia implementacji, czyli samej bazy danych, jest to zadanie trudne. MySQL wychodzi naprzeciw tym oczekiwaniom oferując takie rozwiązania, jak replikacja oraz klastry, przy czym w różnym stopniu spełniają one wyżej wspomniane wymogi. 3.1 MySQL Cluster Tę funckjonalność oferuje silnik NDB (Network Database), umożliwiający tworzenie zdecentralizowanych klastrów o wysokiej dostępności, nadmiarowości i skalowalności. Technologia ta pozwala na odczyt i zapis do wielu węzłów, transparentnie wykonując synchronizację, transparentnie tolerując awarie oraz przetwarzając zapytania w sposób rozproszony, co znacznie poprawia wydajność przeszukiwania metadanych o zasobach. Bazy oparte o silnik NDB w trakcie pracy mogą być przechowywane wyłącznie w pamięci operacyjnej, aby skrócić czas dostępu do danych. W takiej sytuacji należy jedynie poprawnie wdrożyć instalację klastra, niemniej nie ma potrzeby przejmowania się problemami związanymi bezpośrednio z systemem rozproszonym, można traktować wszystkie dane globalnie, kwestię spójności i zagrożeń wyścigowych pozostawiając do rozwikłania NDB. Nic za darmo. Programista nie musi tworzyć i implementować skomplikowanych algorytmów rozwiązujących te problemy, ale wszystkie węzły muszą spełnić wymóg wzajemnej łączności na szerokości min. 100 Mbps, niemniej gdzie tylko się da, zalecana jest łączność rzędu gigabita na sekundę [mysql-cluster]. To niestety kłóci się z jednym z założeń pozafunkcjonalnych, tj. system ma być zdolny do wdrożenia i zadowalającego działania na węzłach o niskich przepustowościach, zazwyczaj niesymetrycznych łączach dla klientów indywidualnych, rzędu np Mbps. Rysunek nr 1 przedstawia klaster z funkcjonalnego punktu widzenia związanego z przepływem danych. Jak widać jest on wielokierunkowy, sam zaś użytkownik i aplikacja korzystać mogą z dowolnego jego węzła, gwoli wydajności wybierając najmniej obciążony/namniej oddalony 7

8 geograficznie, co można również zautomatyzować, wykonując kolejny krok w stonę tzw. Cloud Computingu. Niebieska linia przerywana prezentuje przepływ danych od użytkownika do systemu (zarówno zapis jak i odczyt na dowolnym węźle). Rys. 3.1 schemat systemu rozproszonego zrealizowanego z pomocą MySQL Cluster z punktu widzenia przepływu danych, aplikacji oraz użytkownika 3.2 Replikacja Drugą wartą rozważenia opcją jest replikacja. Dzięki częściowej rezygnacji z decentralizacji wprowadza znacznie mniejsze wymagania dotyczące dostępności, w tym przepustowości węzłów, gdyż jest asynchroniczna. Replikacja pozwala na tworzenie bazy danych rozproszonej po wielu niezależnych, zazwyczaj fizycznych maszynach, przeważnie ma to na celu poprawić wydajność poprzez zmniejszenie opóźnień wynikających z geograficznego rozlokowania węzłów oraz bezpieczeństwo pod względem nadmiarowości (tj. replikacja, podobnie jak klaster, jednocześnie spełnia rolę sieciowego backupu baz). Jest to scenariusz bardzo podobny do klastra, z pewną zasadniczą różnicą. Główny serwer, nazywany dalej master, jest jedynym węzłem, na którym zachodzą zapisy danych (dodawanie, modyfikacja, usuwanie, czyli operacje DML), które są na bieżąco propagowane do wszystkich podłączonych aktualnie węzłów skonfigurowanych do replikacji, nazywanych dalej slave, przy czym to węzły slave odpowiadają za pobieranie aktualizacji od mastera, nie odwrotnie. Można ustalić nie tylko bazę, którą należy poddać replikacji, ale również pojedyncze tabele. Pierwszą opcją, która pozwala kontrolować to, czy operacje na danej bazie trafiają do bin-loga (a w związku z tym czy podlegają replikacji), jest dyrektywa binlog-do-db oraz binlog-ingnore-db [replication-rules]. Użycie tychże opcji powoduje jednak wyłączenie baz z włączenia w bin-loga, zatem utrudnia ewentualne odzyskanie danych po awarii, co jest drugą kluczową funkcjonalnością oferowaną przez ten mechanizm. Zalecane jest zatem kontrolowanie tej opcji po stronie węzłów slave, z użyciem dyrektyw --replicate-*. W pierwszej kolejności sprawdzane są opcje związane z bazami danych, następnie z tabelami. System powinien być zorganizowany w taki sposób, że wszystkie operacje poza 8

9 wybierającymi dane (SELECT, SHOW), czyli DDL (Data Definition Language) i DML (Data Modification Language) wykonywane na obszarze replikowanych danych jedynie na masterze, węzły slave pobierają je z binarnego loga i automatycznie wykonują u siebie, zaś użytkownicy i aplikacje na węzłach slave korzystają z danych jedynie w trybie odczytu. W przeciwnym wypadku dojdzie do zaburzenia spójności, co jest sprzeczne z ideą replikacji. Niemniej MySQL pozwala na takie zachowania (operacje DDL i DML na replikowanych bazach), pozwala również na ich ograniczenie opcją --read-only, więcej szczegółów w dokumentacji [replication-options-slave]. Zasada działania replikacji oparta jest o wspomniany wyżej log binarny, w którym zapisywane są kolejno wszystkie wydarzenia w bazie, w tym przypadku w bazie mastera. Istnieją różne formaty loga binarnego i odpowiadające im formaty replikacji, zatem wybrany dla danej bazy format musi być spójny pomiędzy wszystkimi węzłami. Do wersji jedynym obsługiwanym formatem loga binarnego, a co za tym idzie, replikacji, jest SBR (Statement Based Replication), polegający na propagowaniu bezpośrednio zapytań SQL z mastera do serwerów slave. RBR (Row Based Replication) opiera się z kolei na zapisie wydarzeń dla każdego z wierszy tabel. Jest on domyślny w wersjach MySQL , zaś od wersji dalszych domyślnie znów jest to SBR. Bazy z silnikiem NDB (czyli logicznie rzecz biorąc MySQL Cluster, rozwiązanie w pełni klastrowe, nie replikacyjne) pracują wyłącznie z formatem RBR. Istnieje również format mieszany (Mixed Based Replication, Mixed Format Replication), w którym format SBR jest domyślny, zaś w przypadku określonych zdarzeń tego wymagających, format jest dynamicznie przestawiany na RBR. Widać tu zatem wyraźną różnicę i idącą za nią we wdrożeniu decyzję, jaką należy podjąć dla danego projektu bazodanowego. Format loga binarnego jest ustalany globalnie, dla całego serwera, jednak może być także oddzielnie określony dla każdej sesji (ustawienie więc istnieje dla każdej sesji aż do jej zakończenia, zatem należy konsekwentnie każdą sesję projektu podlegającego repliakcji rozpoczynać ustawieniem tego samego formatu, jeśli ma się on różnić od tego globalnego (ponadto niejako uniezależnia to od globalnego ustawienia na serwerze)). Za replikacją opartą o wiersze mocno przemawia również fakt, iż w pewnych sytuacjach rozwiązanie SBR (w przypadku widoków, przechowywanych procedur, funkcji) może prowadzić do rozbieżności pomiędzy danymi, różnymi ścieżkami wykonania kodu w procedurach a także naruszenia bezpieczeństwa, gdyż zapytania odczytywane z mastera i wykonywane na węźle slave poprzez proces/wątek przeznaczony do replikacji działają w trybie uprzywilejowanym. W przypadku propagowania faktycznych zmian na wierszach, zamiast przekazywania samych zapytań, sytuacja taka z wyżej wymienionych powodów jest niemożliwa. Po obszerne dane na ten temat replikacji z SBR przy wykorzystaniu procedur i funkcji, szczególnie w aspekcie ich tworzenia w związku z ich determinizmem, odsyłam do dokumentacji [stored-programs-logging]. 3.3 Kompatybilność pomiędzy wersjami Replikacja działa zawsze pomiędzy kolejnymi głównymi seriami MySQL, tj. np. pomiędzy 4.1 i 5.0, jak i 5.0 a 5.1, również kaskadowo, tj. szeregowo (łącząc podłączając 4.1 jako mastera dla 5.0, który z kolei jest masterem dla 5.1, unikając w ten sposób problemów z kompatybilnością, niemniej zazwyczaj obchodzi się i bez pośrednika). Układ ten generalnie nie funkcjonuje dla kierunku odwrotnego, tj. dla masterów o numerach wersji wyższych, niż węzły typu slave (starsze węzły slave nie rozumieją np. nowego formatu loga o zmianach w bazie, na podstawie których dokonywana jest replikacja). 9

10 Rys. 3.2 schemat systemu rozproszonego zrealizowanego z pomocą MySQL Replication z punktu widzenia aplikacji oraz użytkownika Właśnie z tego powodu, że wszelkie metadane uaktualniane mają być bezpośrednio jedynie na węźle master, zmiany dokonywane przez użytkowników na węzłach pozostałych będą w systemie DLRS przezroczyście propagowane do niego z pomocą PHP działającego jako klient MySQL, co prezentuje ciągła niebieska linia na rysunku nr 2 (linia przerywana reprezentuje dane pochodze od użytkownika). Jest to zwykłe zapytanie wykonywane poprzez PHP prawie tak samo, jak w przypadku korzystania z klastra i silnika NDB, z tą różnicą, że specjalnie dla niego otwierane jest oddzielne połączenie MySQL z węzłem master. Sam zaś slave, z którego ta zmiana wyszła, tak jak pozostałe węzły, dokonuje aktualizacji swojej bazy na podstawie dokonanej przez samego siebie zmiany w bazie węzła master, tak jakby została ona wykonana bezpośrednio na węźle master. Jest to główna różnica implementacyjna, jaka występuje pomiędzy wersją DLRS opartą o replikację, a przewidywaną w na przyszłość wersją klastrową. Szczegóły związane z różnicami implementacyjnymi zostały poruszone w rozdziale Zagrożenia wyścigowe. Pozostałe różnice pomiędzy klastrem a replikacją pozostają na poziomie wdrożenia. 3.4 Decyzja, czyli dlaczego replikacja Ze względu na wymagania pozafunckjonalne, mniejszy stopień komplikacji przy wdrożeniu, a także fakt, iż klaster jest rozwiązaniem, które w praktyce jest rozszerzeniem replikacji, jako podstawowy scenariusz wybrano ten, który spełnia bardzo istotne w tej instancji wymagania niefunkcjonalne (niska przepustowość węzłów oraz ograniczony obszar pamięci). Jak wspomniano na końcu poprzedniego akapitu, z punktu widzenia samego systemu DLRS różnica w implementacji jest niewielka, przy czym rozwiązanie klastrowe rozwiązuje również problemy zagrożeń wyścigowych, którym w przypadku scenariusza replikacyjnego należy stawić czoła. Ponadto nic nie stoi na 10

11 przeszkodzie, aby w razie awarii mastera skonfigurować jeden z węzłów slave do jego zastąpienia, a nawet możnaby się pokusić o zautomatyzowanie takiego procesu. Wnikając w szczegóły implementacyjne MySQL Cluster można się przekonać, iż silnik NDB w rzeczywistości stosuje właśnie takie rozwiązanie. Przewidywana jest wersja dla silnika NDB. 11

12 4. Platforma 4.1 GNU/Linux System operacyjny GNU/Linux został wybrany jako naturalne środowisko dla platformy AMP (Apache, MySQL, PHP), stabilne i otwarte, a co za tym idzie wyjątkowo elastyczne, szeroko wspierane oraz relatywnie bezpieczne. Ze względu na jego wieloletnią popularność w zastosowaniach serwerowych, co wynika z uniksowej specyfikacji oraz faktu, że jest wolnodstępny, jego dojrzałość i szerokie wsparcie w Sieci sprawiają, że w coraz większej mierze staje się znakomitym narzędziem do profesjonalnych zastosowań. Niemniej nie można decyzji o platformie odmówić pewnego czynnika personalnego. Każdy element projektu, a także jego idea jest w swej genezie i specyfice najbardziej związana ze środowiskiem GNU/Linux. Ze względu na bliskie pokrewieństwo i elastyczność użytego oprogramowania, nic nie stoi na przeszkodzie, aby do tego zadania zatrudnić inny system uniksopodobny, taki jak OS X czy inne systemy z rodziny BSD. 4.2 Apache HTTP Server Jako serwer www, odgrywający kluczową rolę dla użytkownika, użyty został, ze względu na swoją dojrzałość i szerokie możliwości, Apache HTTP Server w wersji 2.2, niemniej nic nie stoi na przeszkodzie w uruchomieniu tego systemu na np. lighttpd czy nginksie. Tutaj przedstawione są jedynie zalecenia konfiguracyjne dla wygodnie i bezpiecznie działającej instalacji DLRS. Do działania DLRS powinien wystarczyć każdy serwer HTTP ze wsparciem dla PHP. Ze względu na konieczność umożliwienia użytkownikowi, którego prawa będzie posiadać proces serwera, zapisu przynajmniej do katalogu z plikami, zaleca się takie konfiguracje httpd, w których potencjalny złośliwy użytkownik mający konto na tym samym hoście mając do dyspozycji PHP mógłby np. zmodyfikować czy zniszczyć pliki, bądź też uzyskać do nich dostęp omijając ich atrybuty dostępu działające jedynie poprzez DLRS. Wobec tego, poza uruchamianiem w środowisku chroot (rozdział Bezpieczeństwo ), zalecane jest stosowanie rozsądnej konfiguracji PHP (rozdział Bezpieczeństwo ) oraz dedykowanego użytkownika, który nie posiada żadnych innych plików w systemie. Do relizacji projektu konieczna jest tutaj obsługa PHP, do celów głównie kosmetycznych zaś vhosty oraz przepisywanie adresów URL za pomocą modułu mod_rewrite. Jest to najluźniej związany z całym projektem element platformy, należy spodziewać się jego stopniowego wypierania przez wydajniejsze rozwiązania, takie jak lighttpd czy nginx. 4.3 MySQL DLRS jest ściśle związany z używanym oprogramowaniem bazodanowym. Z powodu swojej dojrzałości, bardzo szerokiego wsparcia i obszernej, precyzyjnej dokumentacji, popularności a także nabytego przez autora doświadczenia, do realizacji wybrany został właśnie MySQL. Kolejnym ważnym argumentem przemawiającym za tym oprogramowaniem są oferowane możliwości utworzenia środowiska rozproszonego. Co prawda rozwiązanie takie znane jest już od ośmiu lat w wydaniu Oracle RAC (Real Application Clusters), niemniej trzeba za nie dodatkowo płacić. Również z 12

13 takich względów nie zdecydowano się na, możnaby do niedawna rzecz, konkurencyjną platformę. Godnym uwagi rozwiązaniem mógłby się okazać również PostgreSQL wraz z middleware pgpool [pgpool-projects]. 4.4 PHP W wersji 5 PHP oferuje zaawansowany poziom obiektowości, szerokie wsparcie bazodanowe jak i zestaw wygodnych do manipulacji danymi funkcji, dzięki czemu świetnie nadaje się do budowania automatów generujących zawartość webową, która jest najpowszechniejszym, uniwersalnym oraz wspieranym na większości platform interfejsem dostępu do usług. Ponadto PHP posiada szerokie wsparcie dla HTTP, takie jak dostęp do nagłówków, co pozwala między innymi na obsługę cookies, rozpoznawanie wersji przeglądarki oraz uwierzytelnianie. Obecność biblioteki GD pozwala na dynamiczne generowanie wykresów oraz manipulację plikami graficznymi. W przypadku systemu DLRS wymagana jest możliwość dostępu do powłoki w PHP działającym jako CLI (Command Line Interface). Wymaganie jest to w obecnej architekturze systemu, gdyż konieczne do synchronizacji plików, co oznacza, że systemów składających się z jednej maszyny (tzw. tryb standalone) ten wymóg nie dotyczy. 4.5 ViLDeV System webowy to autorski skrypt ViLDeV, który jest aplikacją typu CMS (Content Management System) posiadającą pewne cechy frameworka. Zawiera między innymi system użytkowników oraz ich uwierzytelniania, parser szablonów, zaawansowany system formularzy z szeregiem udogodnień, zaawansowaną warstwę bazodanową, wsparcie dla treści w wielu językach. Dodatkowo posiada moduł systemu menu, newsów, artykułów, galerii, katalogu linków, komentarzy, wyszukiwarki. Bardzo wielu starań dołożono w kwestii bezpieczeństwa tej aplikacji. Poza automatycznym filtrowaniem wejścia pod kątem ataków SQL injection czy XSS (Cross Site Scripting), system formularzy posiada zabezpieczenia przed atakami CSRF (Cross Site Request Forgery) oraz tzw. floodem, a także automatyczny walidator uploadowanych plików jak i automatyczną weryfikację poprawnośći wprowadzonych danych (więcej o zagrożeniach aplikacji webowych w rozdziale Bezpieczeństwo ). Pełne możliwości tego systemu wykraczają poza wymagania systemu DLRS. Niestety nie jest stworzony z wykorzystaniem powszechnie znanych wzorców projektowych oraz nie spełnia w pełni wzorca MVC (Model View Controller) ze względu na zagnieżdżony gdzieniegdzie w modułach kod html, co wynika z faktu, iż zbudowany został bardzo amatorsko około czterech lt temu, a od tego czasu doczekał się jedynie drobnych modernizacji i nowych modułów. Przy bliższej sposobności planowana jest modernizacja architektury (ViLDeV 2.0) z zastosowaniem wszelkich pasujących wzorców projektowych a także silnika szablonów Smarty. Więcej informacji na temat systemu webowego w rozdziale Implementacja oraz w źródle [vildev]. 4.6 rsync+ssh rsync jest niewielkim, powszechnym narzędziem o sporych możliwościach. Służy do utrzymywania spójności pomiędzy zdalnymi systemami plików. Jego główną zaletą jest obsługa wielu 13

14 metod dostępu do plików, takich jak np. SSH czy FTP. W bieżącej wersji systemu wykonywanie zdalnych operacji na plikach polega na wywołaniu skonfigurowanego wcześniej rsynca poprzez jedną z wbudowanych funkcji PHP oferujących dostęp do powłoki. To wiąże ze sobą konieczność konfiguracji, w której funkcje te nie będą wyłączone. W większości przypadków nie powinno być potrzeby dostarczania funkcji wywołujących polecenia powłoki do PHP działającego dla nieustannie atakowanych aplikacji webowych. Problem można rozwiązać poprzez zmianę sposobu przesyłania plików na niewymagający rsync, np. poprzez wykorzystanie rozszerzenia PHP obsługującego samo SSH. W bieżącej wersji zachowano użycie rsync. Cechą charakterystyczną narzędzia jest umiejętność oszczędnego przesyłania jedynie różnic występujących w synchronizowanych systemach plików. Obsługuje także takie udogodnienia, jak kompresja oraz zdalne wykonywanie poleceń powłoki, co pozwala między innymi na automatyczne tworzenie nowych katalogów do przechowywania plików. Bezpieczeństwo transmisji (uwierzytelnianie, integralność, poufność) zapewniane są poprzez SSH. rsync uruchamiany jest bezpośrednio poprzez skrypt kolejki plików przeznaczonych do synchronizacji. PHP sprawdza wyjście narzędzia uruchamianego kolejno dla każdego z synchronizowanych plików i na tej podstawie zmienia w bazie informacje na temat stanu synchronizacji zasobu. Uwierzytelnianie pomiędzy węzłami przy przesyłaniu plików odbywa się poprzez infrastrukturę kluczy publicznych. 14

15 5. Struktura organizacyjna plików Na cały system składają się dwa główne katalogi. Pierwszy to public_html lub jego odpowiednik, w którym znajdować się będą wszystkie pliki systemu webowego, tj. ViLDeV z modułami DLRS. Z punktu widzenia serwera www jest to lokalizacja DocumentRoot dla dedykowanego pod aplikację vhosta. Drugi natomiast, library/, zawiera po prostu pliki, zwane ogólnie zasobami. Wszystkie metadane, tj. atrybuty książek elektronicznych, takie jak autor, tytuł, wydawnictwo czy kategoria, a przede wszystkim pełna nazwa pliku znajdują się w bazie danych. Sama nazwa pliku nie musi zawierać żadnych atrybutów. Rozdzielenie metadanych od systemu plików znacznie ułatwia zarządzanie, gdyż nie ma dzięki temu potrzeby nakładania jakichkolwiek restrykcji na nazwy plików, gdyż ich przeglądanie oraz wyszukiwanie i tak odbywa się za pośrednictwem systemu webowego. Początkowy pomysł na umieszczanie plików w katalogach odpowiadających kategoriom został porzucony ze względu na komplikacje, które by spowodował przy edycji atrybutów, przy jednoczesnym braku wynikających z tego korzyści, przy właśnie założeniu, że korzystanie z zasobów nie będzie polegać na bezpośrednim przeglądaniu systemu plików. Niemniej, aby zmniejszyć ryzyko wystąpienia problemu związanego z ograniczeniem danego systemu plików, tj. maksymalnej ilości plików w katalogu a także zauważalnego spadku wydajności przy przeszukiwaniu folderu z bardzo dużą ich ilością, celem uniknięcia potencjalnie kłopotliwego rozwiązywania tego problemu na działającej już instalacji, przyjęto następujące założenia dotyczące organizacji katalogów: nazwa pliku nie podlega edycji, co oznacza, że pozostaje w systemie w pierwotnej wersji, takiej, w jakiej został wprowadzony przez uploadera, sam plik zaś ulokowany jest w katalogu o nazwie składającej się z trzech pierwszych znaków jego nazwy, bez rozróżnienia na duże i małe litery. Dzięki temu ryzyko przekroczenia i tak wysokich limitów poszczególnych systemów plików na ilość plików w jednym katalogu zostaje praktycznie zniwelowane. Przykładowo dla popularnego na serwerach systemu plików reiserfs limit ten wynosi cztery miliardy, co przy założeniu, że nazwy plików mogą zaczynać się wyłącznie od liter, bez rozróżniania ich wielkośći, daje wielokrotność 8192 tego limitu. Przy proponowanej strukturze organizacyjnej i założeniu, że alfabet składający się na trzyznakowe nazwy posiada 40 znaków, maksymalna ilość wszystkich utworzonych automatycznie katalogów daje okrągłą liczbę, W związku z powyższym, struktura katalogów dla systemu DLRS przedstawia się, jak następuje: /home/dlrs - katalog domowy projektu /home/dlrs/public_html - system webowy /home/dlrs/library/ - zasoby biblioteki Dla przykładowej listy plików: Applied cryptography 2nd edition.odt Cryptography_Theory_and_Practice.doc handbook of security management.rtf Handbook of applied Cryptography.pdf faktyczne lokalizacje w katalogach mapowane są następująco: /home/dlrs/library/app/applied cryptography 2nd edition.odt 15

16 /home/dlrs/library/cry/cryptography_theory_and_practice.doc /home/dlrs/library/han/handbook of security management.rtf /home/dlrs/library/han/handbook of applied Cryptography.pdf Zważywszy na fakt, że wśród metadanych w bazie przechowywane będą pełne, oryginalne nazwy plików, dla systemu webowego nie będzie stanowić żadnego problemu odwołanie się do nich. Niektóre znaki specjalne powodują utrudnienia w przetwarzaniu nazw przez powłokę oraz rsync, który jest z niej wywoływany. Problemy te zostały jednak w większości rozwiązane (więcej szczegółów w rozdziale Synchronizacja ). 16

17 6. Synchronizacja Szczegóły synchronizacji MySQL zostały przedstawione w rozdziale Scenariusze, architektura sieci. Przebiega praktycznie w sposób automatyczny, tj. węzły typu slave same dbają o to, aby na bieżąco pobierać z mastera informacje o zmianach i stosować je do własnej bazy danych. Głównym problemem, jaki pozostaje rozwikłać jest synchronizacja plików pomiędzy węzłami. Z powodów natury organizacyjnej, wydajnościowej oraz większej uniwersalnośći rozwiązania, pliki trzymane będą w lokalnym systemie plików, nie w bazie (w wersji dla MySQL Cluster byłoby to wręcz niemożliwe, gdyż przewidziana jest duża pojemność systemu, zaś cała zawartość bazy w przypadku korzystania z silnika NDB musi znajdować się w pamięci RAM). Z punktu widzenia użytkownika, metadane o zasobach jak i same zasoby mogą być dodawane na dowolnym z węzłów (pod warunkiem, że działa węzeł master, aby można było dokonać aktualizacji na nim, zachowując spójność). Po pojawieniu się w masterze metadane rzeczywiście poprzez replikację podróżują do węzłów slave. Pliki natomiast są zapisywane lokalnie, fizycznie na maszynie, z której serwerem www użytkownik dokonuje połączenia. Ze względu na fakt, iż rozmiar plików jest praktycznie zawsze znacznie większy od opisujących je metadanych, a co za tym idzie prędkość przesyłania przez ich przez sieć będzie znacznie większa, synchronizacja plików będzie następować ze sporym opóźnieniem w stosunku do metadanych. Aby równomiernie rozłożyć obciążenie z tym związane, a także zachować spójność systemu, na potrzebę systemu opracowany został schemat wzajemnej synchronizacji zasobów oparty o kolejkę plików i wzajemne priorytety synchronizacji pomiędzy hostami, koordynowany z pomocą bazy danych. Nad kolejką plików, których synchronizacja nie została jeszcze spełniona, czuwa działający w tle skrypt PHP, który nieustannie pobiera z bazy informacje o nowododanych plikach a także o tym, które z hostów zakończyły już ich synchronizację. Za sam proces transferu plików przez sieć odpowiada popularne uniksowe narzędzie rsync, którego wywoływanie kontrolowane jest właśnie przez działający w tle skrypt kolejki synchronizacyjnej. Użytkownik, zwany dalej uploaderem, umieszcza nowy zasób na dowolnym z serwerów, za pośrednictwem interfejsu webowego, więc za pośrednictwem PHP. Plik zostaje zaindeksowany w bazie danych (wprowadzane są podstawowe informacje, takie jak tytuł, kategoria, autor, rok wydania, wydawnictwo, rozmiar, nazwa (która może zostać poddana modyfikacji, aby spełnić założenia nazewnictwa), a także opcjonalne atrybuty dostępu). W tym momencie wszystkie aktywne hosty dzięki replikacji wiedzą o nowym zasobie a także o tym, który z nich dokonał już związanej z tym synchronizacji. Rozpoczyna się proces synchronizacji plików za pomocą rsync. Składa się z dwóch etapów. Host, który oryginalnie otrzymał zasób, wywołuje rsync z innym hostem w sieci (tym, dla którego wpis w jego własnej tabeli priorytetów jest najniższy, tj. im niższy priorytet, tym pilniejszy). Efekt pracy rsync jest sprawdzany przez PHP, w zależności od tego podejmowana jest decyzja o dalszej synchronizacji (jeśli wszystko poszło zgodnie z planem, synchronizacja z punktu widzenia danego węzła jest zakończona, gdyż zgodnie z tym założeniem każdy węzeł, z wyjątkiem ostatniego, wykona szeregowo upload plików na kolejny węzeł, co łącznie działać ma jak efekt domino). Dla każdego z serwerów w bazie danych znajduje się wspomniana lista priorytetów synchronizacji z pozostałymi członkami sieci. Gwarantujące objęcie wszystkich węzłów oraz najoptymalniejsze zarazem ustawienie tych parametrów w sposób przedstawiony na rysunku nr

18 Rys. 6.1 schemat rozłożenia wzajemnych priorytetów synchronizacji plików pomiędzy węzłami DLRS Takie rozłożenie jest niezależne od ilości węzłów tego grafu, niemniej instalacja jednej instancji systemu DLRS zalecana jest na od jednej do pięciu maszyn, zgodnie z rekomendacją dla instalacji MySQL Cluster, podobne, acz mniej restrykcyjne zalecenia stosowane są dla MySQL z replikacją. Na rysunku 4 przedstawiono schemat blokowy algorytmu skryptu obsługującego kolejkę plików przeznaczonych do synchronizacji. Do celu generowania grafu wzjemnych priorytetów służy niewielki kawałek kodu SQL, który osadzony jest w wyzwalaczu uruchamianym po każdym dodaniu oraz usunięciu węzła z bazy, co zapewnia zawsze spójny, aktualny graf. Kolejnym ważnym elementem systemu jest działający w tle skrypt PHP odpowiadający za synchronizację plików za pośrednictwem rsync i SSH. Przy każdym dodaniu pliku do systemu, zostaje on zapisany lokalnie na dysku serwera HTTP węzła, z którym użytkownik akurat był połączony. Wraz z plikiem pojawiają się metadane a także dane synchronizacyjne, określające, na jakich fizycznie hostach już znajduje się plik. 18

19 Rys. 6.2 schemat blokowy algorytmu skryptu kolejki synchronizowanych plików Ta informacja jest zapisywana na serwerze master, a jej propagacja ma miejsce do innych węzłów poprzez replikację. Każdy węzeł, jeśli otrzymał nowy zasób, zobowiązany jest przekazać go jednemu innemu węzłowi, chyba, że wszystkie już posiadają dany zasób. To samo tyczy się poleceń usunięcia zasobu z systemu. Na każdym węźle lokalnie odpowiada za to właśnie wspomniany skrypt PHP, 19

20 którego schemat blokowy algorytmu przedstawia rysunek nr 6.2. Informacje o tym, czy dany węzeł posiada zasób oraz czy powinien wykonać jego synchronizację z innym węzłem przetrzymywane są w przeznaczonej do tego tabeli dlrs_sync. Szczegóły związane z implementacją skryptu w rozdziale Implementacja. 6.1 Awarie Oczywiście może dojść do sytuacji, w której jeden z węzłów staje się niedostępny, na przykład w wyniku awarii czy prac konserwacyjnych. Jeśli nie zakończył on swego udziału w procesie synchronizacji, tzn. istnieją zasoby, które nie zostały do niego przesłane, po osiągnięciu zbieżności przez pozostałe węzły, ostatni z zsynchronizowanych serwerów, za pośrednictwem działającego w tle skryptu kolejki synchronizacji będzie usiłował przesłać do niego pliki. Aby próby takie zostały poniechane, administrator posiadający uprawnienia do edycji nieczynnego węzła, tj. administrator w ViLDeV bądź członek grupy dlrs_admins, który jest właścicielem danego hosta bądź ma nadane przez właściciela specjalne uprawnienia, musi ręcznie poprzez panel administracyjny zmienić status serwera na offline. Od tego momentu serwer nie jest widziany przez żadną z instancji skryptu synchronizującego jako jeden z partnerów do synchronizacji, toteż próby przesłania plików z pomocą rsync nie są podejmowane. Proces synchronizacji jest osobny dla każdego z zasobów oraz niezależny od pozostałych. Po usunięciu awarii i ponownym uzyskaniu zbieżności z bazą mastera w procesie replikacji, administrator węzła powinien zmienić z powrotem status maszyny na online, co spowoduje, że ostatni z pozostałych węzłów, któremu nie udało się dokonać synchronizacji, ponownie podejmie tę próbę. Spójność jest zatem automatycznie utrzymywana z niewielkim stopniem ingerencji ze strony administratora, rozważane jest większe zautomatyzowanie tego procesu, poprzez automatyczną zmianę statusu hosta na offline w momencie, gdy jest on niedostępny, pozostawiając kwestię ustalenia statusu online w trybie ręcznym, wychodząc z założenia, że w wypadku awarii administrator i tak musi interweniować, a po włączeniu z powrotem MySQL oraz DLRS niekoniecznie chce, aby węzeł od razu przystąpił do synchronizacji plików. 20

21 7. Zagrożenia wyścigowe Zagrożenia wyścigowe, tzw. race conditions [race-conditions] to rodzaj problemów, jakie występują w środowiskach, w których jednocześnie funkcjonujące procesy są częśćiowo zależne od tych samych obiektów. Może być to sytuacja, w której jakiś obszar danych podlega zmianie, a następnie odczytowi przez ten sam proces. Pomiędzy zapisem a odczytem znajduje się okno czasowe, w którym może dojść do zmiany wskazanego obszaru danych przez inny proces, o czym nie dowie się proces pierwszy, który ułamek sekundy potem dokona odczytu danych, których spójność została właśnie naruszona. Przykładem jest np. doliczenie punktu w grze najpierw przez jeden, a następnie drugi rdzeń procesora, ze względu na błąd w ich synchronizacji, tj. braku zastosowania odpowiedniej blokady. Na jednym procesorze analogiczna sytuacja może dotyczyć chociażby działających jednocześnie różnych procesów i braku dokonania działającego ze skutkiem natychmiastowym zablokownia tej operacji dla innych procesów, tak jak czynią to semafory. Problem zagrożeń wyścigowych jest zatem nieodłącznym zagadnieniem systemów rozproszonych. Główną zaletą rozwiązania MySQL Cluster z punktu widzenia implementacji projektu DLRS jest fakt, iż każdy z serwerów MySQL może być traktowany tak, jakby był jedynym węzłem w sieci, tj. tak, jakby system rozproszony wcale nie istniał. Problem ten rozwiązywany jest więc w sposób transparentny. W przypadku replikacji nie można sobie na to pozwolić, gdyż nie zachodzi obustronna koordynacja działań na rekordach, zaś zmiany propagowane są tylko w jednym kierunku. To zmusza do uniknięcia problemów ze spójnością, takich jak dwie różne wersje tego samego rekordu, poprzez założenie, iż zapisy dokonywane są wyłącznie na węźle master. Ciągnie to za sobą konsekwencje implementacyjne, mianowicie każde zapytanie SQL, które nie rozpoczyna się od słowa SELECT, musi być wykonane na węźle master. W ViLDeV, specjalnie na potrzeby DLRS, opcja ta została zrealizowana poprzez rozpoznanie lokalnego ustawienia, informującego system o tym, czy pełni rolę węzła slave, czy master, następnie, jeśli ustawienie tego wymaga, a zapytanie nie rozpoczyna się od frazy SELECT, klasa odpowiedzialna za wykonywnie zapytań w locie dokonuje połączenia z MySQL węzła master i bezpośrednio tam wykonuje zapytania modyfikujące dane, których efekt następnie powraca zarówno do węzła slave, z którego wyszedł, jak i trafia do pozostałych węzłów slave za sprawą samego mechanizmu replikacji. W przypadku złożonych zestawów zapytań, takich jaki np. występuje przy operacji dodawania nowego węzła do sieci, nadal pozostawia furtkę do zaistnienia chwilowego braku spójności pomiędzy bazą master a slave, w wyniku której powstaną w bazie nieprawidłowe metadane. Sytuacja wygląda następująco: w systemie webowym dowolnego z węzłów dokonywane jest dodanie nowego hosta do tabeli dlrs_hosts, zwykłe polecenie INSERT. Jak wspomniano wyżej, jeśli nie nastąpi to bezpośrednio na węźle master, w locie zostanie wykonane połączenie z tymże właśnie serwerem. Zaraz po dodaniu hosta następuje ponowne zbudowanie grafu wzajemnych priorytetów synchronizacji. W tym celu wykonywane jest zapytanie SELECT na, jak założono, świeżo uaktualnionej o nowy rekord tabeli dlrs_hosts. Zgodnie z powyższym założeniem, SELECT będzie wykonany bezpośrednio na węźle, z którym łączył się administrator dodający hosta, zatem istnieje nikła szansa, że lokalna wersja tabeli zdąży się uaktualnić w wyniku replikacji, co 21

22 doprowadziłoby do zbudowania dokładnie takiego samego grafu priorytetów, jaki istniał przed dodaniem nowego hosta. Problem ten rozwiązano poprzez przeniesienie procedury generowania nowego grafu priorytetów do wyzwalacza nałożonego na tabelę dlrs_hosts, dzięki czemu cała operacja zostanie wykonana na serwerze master. Kolejnym, analogicznym przypadkiem jest sytuacja, w której do zasobów dodano jeden plik. Zostaje on przesłany do kolejnego, wskazanego grafem priorytetów węzła. Informacja o tym zapisana zostaje na węźle master. Istnieje realna szansa, iż zanim węzeł slave, który dokonał wysłania pliku, uaktualni swoją tabelę z metadanymi na temat synchronizacji poprzez replikację, zdąży po raz kolejny pobrać z lokalnej wersji bazy informację o tym, iż danego pliku nadal nie wysłał do żadnego serwera. Nie stwarza to żadnego zagrożenia poza ewentualną, nadmiarową próbą ponownego wysłania pliku do kolejnego węzła. Ze względu na fakt, iż synchronizacja przebiega szeregowo, a nie równolegle, nie istnieje poważniejsze zagrożenie wyścigowe w wypadku replikacji, które mogłoby przejawiać się sytuacją, w której kilka węzłów jednocześnie usiłuje wysłać któryś plik do tego samego serwera, następnie zmieniając informację w bazie, że niejako dokonały synchronizaji z jednym z pozostałych węzłów, co w przypadku powtórzenia się jednego z nich spowodowałoby, iż inny pozostałby bez danego zasobu w ogóle, a jego synchronizacja nigdy by nie nastąpiła. Można powiedzieć, że synchronizacja tego zasobu zostałaby osierocona. Również sprawdzenie, czy dodawany zasób już nie istnieje w systemie, odbywać się musi na węźle master. W przeciwnym wypadku istnieje nikłe, niemniej prawdopodobieństwo, iż w krótkim odstępie czasu do bazy wprowadzony zostanie ten sam zasób z dwóch różnych źródeł, gdyż sprawdzenie pod kątem np. sumy kontrolnej na lokalnym węźle zawiedzie z powodu zbyt dużego czasu osiągania zbieżności. Przy projektowaniu oraz implementacji należało zatem zwrócić uwagę na wymienione wyżej oraz analogiczne problemy, które śmiało można pominąć w wypadku, gdy zamiast replikacji można pozwolić sobie na MySQL Cluster. W tym celu wystarczy wyłączyć odpowiadającą za obsługę systemu replikowanego opcję silnika ViLDeV. 22

23 8. Analiza; projekt Niniejszy rozdział obejmuje analizę strukturalną i behawioralną systemu, ma na celu stworzenie modelu aplikacji pod kątem perspektywy logicznej, wdrożeniowej, implementacyjnej, przypadków użycia a także strukturalnej. Do tego celu zastosowany zostaje język UML (Unified Modeling Language), który powyższe podejście nazywa perspektywą 4+1 [uml-perspektywy]. 8.1 Użytkownicy i grupy Podstawowy podział rozróżnia zwykłych użytkowników oraz administratorów. Podejście jest bardzo proste, administratorzy mają pełną kontrolę nad zasobami, uprawnienia zwykłych użytkowników regulowane są zaś specjalnymi rekordami w stworzonej na ten cel tabeli, cały proces uwierzytelniania i autoryzacji zasobów oferuje wykorzystany do projektu system webowy, ViLDeV. Poza grupą administratorów na potrzeby projektu stworzono dodatkową grupę, mającą możliwość zarządzania informacjami o węzłach sieci oraz częściowej administracji nimi, a także dwie grupy do odseparowania uprawnień związanych z zarządzaniem zasobów od uprawnień pozwalających jedynie na korzystanie z nich. 23

24 Rys. 8.1 diagram przypadków użycia z wyszczególnieniem podstawowych grup użytkowników 8.2 Przypadki użycia Przypadek użycia reprezentuje kompletną funkcję oferowaną tzw. aktorowi przez system. Aktorem jest obiekt nienależący do samego systemu, zazwyczaj jest to użytkownik, niemniej może być to obiekt innego typu, który korzysta z jakiejś funkcji analizowanego systemu. Na rys. 8.1 przedstawione zostały przypadki użycia oferowane przez sam system DLRS, z pominięciem tych standardowo oferowanych przez ViLDeV, takich jak zarządzanie użytkownikami, zmiana języka, używanego szablonu HTML itp. Dostęp do poszczególnych grup przypadków użycia rozłożony jest hierarchicznie, ze stopniowym rozszerzaniem uprawnień. Każdy użytkownik ma prawo dostępu do używania systemu, jeśli należy do stworzonej do tego celu grupy dlrs_readers czy też grupy o wyższych prawach. Reprezentacją najpowszechniejszego użytkownika, o minimalnych uprawnieniach, jest obecny na diagramie aktor Reader. Użytkownik może posiadać status uploadera, co wiąże się również z przynależnością do analogicznej grupy dlrs_uploaders. Daje mu to dodatkowo dostęp do operacji modyfikujących zawartość bazy, tj. przypadków użycia związanych z dodawaniem i edycją zasobów, a także ustalania dla nich praw dostępu. Najwyższe uprawnienia mają administratorzy, oznacza to dostęp do wszystkich przypadków użycia i pełną kontrolę nad każdym 24

25 zasobem. Każdy z zasobów może mieć, podobnie jak pliki w systemach uniksowych, nadaną grupę, jedną z tych, do której należy osoba tworząca zasób. Pozwala to na bardzo precyzyjne określenie, kto ma prawo pełnej kontroli czy też wyłącznie odczytu pliku (toteż można bez problemu nie udzielić dostępu nikomu poza administratorami i właścicielem pliku). W takiej sytuacji użytkownicy administracyjni nadal mają pełną kontrolę, osoby należące do grupy uploaderów mają prawo do przypadków użycia związanych z przeglądaniem zasobów. Użytkownicy należący do grupy czytelników uzyskują dostęp wyłącznie do przypadków użycia związanych z odczytem danych, zaś użytkownicy nienależący do żadnej z grup nie mają prawa korzystać z modułów DLRS w ogóle Scenariusze przypadków użycia nazwa pakietu ReadResource numer 1 poziom ważności tryb przypadku użycia aktorzy krótki opis najwyższy szczegółowy Użytkownik Ten przypadek użycia odpowiada za kluczową funkcjonalność, jaką jest udzielenie użytkownikowi dostępu do pliku. warunki wstępne istnieje wywołanie od użytkownika, które identifykuje jednoznacznie zasób, do którego dostęp chce on uzyskać warunki końcowe użytkownik otrzymuje plik, w przypadku braku dostępu lub braku pliku otrzymuje stosowny komunikat o błędzie główne przepływy zdarzeń użytkownik wydaje żądanie odczytania zasobu system dokonuje autoryzacji system zwraca plik użytkownikowi alternatywne przepływy zdarzeń użytkownik wydaje żądanie odczytania zasobu system wykrywa, że żądanie jest błędne lub wystąpiła inna sytuacja, która uniemożliwia spełnienie żądania system zwraca komunikat o błędzie do użytkownika nazwa pakietu SearchResources numer 2 poziom ważności wysoki 25

26 tryb przypadku użycia aktorzy krótki opis szczegółowy Użytkownik Ten przypadek użycia odpowiada za kluczową funkcjonalność, jaką jest przeszukiwanie bazy pod kątem zasobów spełniających kryteria. warunki wstępne istnieje wywołanie od użytkownika, które identifykuje kryteria, jakie spełnić mają wynikowe zasoby warunki końcowe użytkownik otrzymuje listę odpowiadających kryteriom zasobów główne przepływy zdarzeń użytkownik wydaje żądanie przeszukania zasobów system zwraca żądaną część wyników alternatywne przepływy zdarzeń Użytkownik wydaje żądanie odczytania zasobu system wykrywa, że żądanie jest błędne lub wystąpiła inna sytuacja, która uniemożliwia spełnienie żądania system zwraca komunikat o błędzie do użytkownika nazwa pakietu ListHosts numer 3 poziom ważności tryb przypadku użycia aktorzy krótki opis niski szczegółowy Użytkownik Ten przypadek użycia dostarcza podstawowych informacji o tworzących sieć węzłach. warunki wstępne następuje wywołanie przypadku warunki końcowe użytkownik otrzymuje listę istniejących hostów, a jeśli jest ku termu uprawniony, również dodatkowe związane z nimi informacje, takie jak priorytety synchronizacji plików względem innych hostów oraz informację o stanie kolejki główne przepływy zdarzeń użytkownik wydaje żądanie listy hostów system zwraca informacje o stanie hostów alternatywne przepływy zdarzeń użytkownik wydaje żądanie listy hostów 26

27 system wykrywa, że żądanie jest błędne lub wystąpiła inna sytuacja, która uniemożliwia spełnienie żądania system zwraca komunikat o błędzie do użytkownika nazwa pakietu AddResource numer 4 poziom ważności tryb przypadku użycia aktorzy krótki opis wysoki szczegółowy Uploader Ten przypadek użycia pozwala na dodanie zasobu do bazy. warunki wstępne następuje wysłanie pliku oraz metadanych węzeł master jest dostępny warunki końcowe plik pozostaje zapisany na dysku, metadane wprowadzone do bazy, zaś skrypt kolejki jest gotów rozpocząć proces synchronizacji pliku między węzłami główne przepływy zdarzeń użytkownik wydaje żądanie dodania pliku system zwraca informację o powodzeniu alternatywne przepływy zdarzeń użytkownik wydaje żądanie dodania zasobu system wykrywa, że żądanie jest błędne lub użytkownik nie jest uprawniony do dodawania zasobów system zwraca komunikat o błędzie do użytkownika nazwa pakietu EditResource numer 5 poziom ważności tryb przypadku użycia aktorzy krótki opis średni szczegółowy Uploader Przypadek odpowiada za modyfikację informacji dotyczącej istniejącego już w bazie zasobu, z 27

28 podmianą reprezentującego go pliku włącznie. warunki wstępne następuje wywołanie przypadku węzeł master jest dostępny warunki końcowe użytkownik otrzymuje informację o powodzeniu operacji główne przepływy zdarzeń użytkownik wydaje żądanie edycji zasobu, przesyłając nowe metadane oraz opcjonalnie nowy plik zasobu system zwraca informację o powodzeniu edycji alternatywne przepływy zdarzeń użytkownik wydaje żądanie odczytania zasobu system wykrywa, że żądanie jest błędne lub użytkownik nie jest uprawniony do modyfikacji wskazanego zasobu system zwraca komunikat o błędzie nazwa pakietu DeleteResource numer 6 poziom ważności tryb przypadku użycia aktorzy krótki opis średni szczegółowy Uploader Przypadek realizuje możliwość usunięcia zasobu z bazy. warunki wstępne następuje wywołanie przypadku węzeł master jest dostępny warunki końcowe użytkownik otrzymuje informację o powodzeniu usunięcia główne przepływy zdarzeń użytkownik wydaje żądanie usunięcia zasobu system zwraca informację o powodzeniu usunięcia, usunięty zostaje plik oraz rozpoczęty proces uzyskiwania spójności z pozostałymi serwerami alternatywne przepływy zdarzeń użytkownik wydaje żądanie usunięcia system wykrywa, że żądanie jest błędne lub użytkownik nie jest uprawniony do usunięcia wskazanego zasobu system zwraca komunikat o błędzie 28

29 nazwa pakietu AddHost numer 7 poziom ważności tryb przypadku użycia aktorzy krótki opis niski szczegółowy Administrator Przypadek realizuje możliwość formalnego dołączenia kolejnego węzła do systemu, co spowoduje między innymi zainicjowanie procesu synchronizacji. warunki wstępne następuje wywołanie przypadku węzeł master jest dostępny warunki końcowe Administrator otrzymuje informację o powodzeniu dodania hosta oraz rozpoczęciu procesu uzyskiwania spójności przez system główne przepływy zdarzeń Administrator wysyła metadane o nowym hoście z żądaniem jego dodania system zwraca informację o powodzeniu w dodawaniu hosta, graf wzajemnych priorytetów synchronizacji zostaje przebudowany oraz rozpoczyna się synchronizacja plików nowego węzła alternatywne przepływy zdarzeń użytkownik wydaje żądanie usunięcia system wykrywa, że żądanie jest błędne system zwraca komunikat o błędzie nazwa pakietu EditHost numer 8 poziom ważności tryb przypadku użycia aktorzy krótki opis niski szczegółowy Administrator Przypadek realizuje możliwość edycji informacji o węźle, takich jak nazwa czy adres IP. warunki wstępne następuje wywołanie przypadku węzeł master jest dostępny warunki końcowe Administrator otrzymuje informację o powodzeniu edycji danych o węźle 29

30 główne przepływy zdarzeń Administrator wysyła metadane o nowym hoście z żądaniem jego edycji system modyfikuje informację o hoście system zwraca informację o powodzeniu w edycji danych hosta alternatywne przepływy zdarzeń Administrator wydaje żądanie edycji system wykrywa, że żądanie jest błędne system zwraca komunikat o błędzie nazwa pakietu DeleteHost numer 9 poziom ważności tryb przypadku użycia aktorzy krótki opis niski szczegółowy Administrator Przypadek realizuje możliwość formalnego odłączenia węzła od sieci. warunki wstępne następuje wywołanie przypadku węzeł master jest dostępny warunki końcowe Administrator otrzymuje informację o usunięciu węzła z sieci główne przepływy zdarzeń Administrator wysyła metadane o nowym hoście z żądaniem jego usunięcia system usuwa z bazy metadane o hoście i zasobach na nim rozlokowanych system zwraca informację o powodzeniu usunięcia hosta alternatywne przepływy zdarzeń Administrator wydaje żądanie usunięcia system wykrywa, że żądanie jest błędne system zwraca komunikat o błędzie 30

31 8.3 Diagram klas Rys. 8.2 diagram klas systemu Powyższy diagram przedstawia tylko te najważniejsze z punktu widzenia projektu DLRS klasy. Pominięte zostały pewne mniej istotne, będące szczegółem implementacyjnym samego systemu ViLDeV, takie jak klasa obsługująca zmianę języka, klasa odpowiadająca za warstwę bazodanową, klasa parsera szablonów oraz inne składające się na ten CMS. Wyjątkiem na diagramie są ViLDeV, 31

32 usr_ctrl oraz user, gdyż stanowią one rdzeń systemu z użytkowego punktu widzenia, zawierają operacje związane z obsługą użytkowników, uwierzytelniania oraz autoryzacji. Jedyne dedykowane dla tego projektu moduły reprezentowane są przez klasy obsługi akcji związanych z zasobami, które są bezpośrednio przedmiotem projektu, tj. zasobami biblioteki oraz informacjami o węzłach tworzących system rozproszony. 8.4 Diagram komponentów Rys diagram komponentów przedstawiający strukturę aplikacji od podstawowego interfejsu użytkownika CRUD, poprzez pakiet realizujący właściwe zadanie, DLRS, który z kolei zależny jest kolejno od CMS-a ViLDeV, PHP oraz MySQL Przedstawiony na rysunku nr 8.3 diagram realizuje spojrzenie na powiązania między komponentami z perspektywy systemu DLRS. Każdy z modułów implementuje podstawowy interfejs, nazwany CRUD od podstawowego sposobu podziału metod ze względu na operację, jaką wykonują na 32

33 danych (Create Read Update Delete). Zarówno moduł ResourceManager jak i HostManager implementują te same, podstawowe metody odpowiadające elementarnym operacjom, tj: create add_host, add_resource read show_host, list_hosts, show_resource, list_resources update edit_host, edit_resource delete del_host, del_resource Implementują go również wszystkie pozostałe moduły tego CMS-a. 8.5 Diagramy interakcji Diagramy interakcji przedstawiają przebieg komunikacji pomiędzy obiektami, zazwyczaj tworzy się je dla określonych przypadków użycia [diagramy-interakcji]. Język UML definiuje cztery rodzaje tych diagramów. Są to: diagram sekwencji, komunikacji (w UML 1.0 nazywany jeszcze diagramem interakcji), przeglądu interakcji oraz diagram zależności czasowych Diagramy sekwencji dla podstawowych przypadków użycia Rys. 8.4 diagram sekwencji dla przypadku użycia odczytania zasobu Zamieszczony na rys. 8.4 diagram sekwencji przedstawia przepływ sterowania pomiędzy aktorem reprezentującym zwykłego użytkownika, a modułem obsługującym operacje na zasobach. Elementarne operacje, jakie zachodzą w module, to sprawdzenie poprawności żądania, a następnie sprawdzenie uprawnień do niego w kontekście bieżącego użytkownika. Kolejny diagram jest analogiczny. 33

34 Rys diagram sekwencji dla przypadku użycia przeszukiwania zasobów Rys. 8.6 diagram sekwencji dla przypadku użycia edycji informacji o węźle, tj. hoście Na rys. 8.6 przedstawiono diagram sekwencji dla administracyjnego przypadku użycia służącego do zarządzania hostami. Podobnie, jak w przypadku poprzednich i wszystkich innych przypadków użycia, sprawdzenie poprawności odwołania, autoryzacja a następnie zmiana dokonywana jest na bazie. 34

35 Rys. 8.7 diagram sekwencji dla przypadku użycia dodawania zasobu (AddResource) Na diagramie przedstawionym na rys. 8.7, prezentującym przepływ sterowania pomiędzy obiektami dla przypadku wprowadzania zasobu do bazy, widać większy stopień złożoności w stosunku do diagramów poprzednich. W pierwszej kolejności, rutynowo sprawdzana jest poprawność danych wejściowych oraz przeprowadzana jest autoryzacja. Ze względu na fakt, że wszystkie operacje zapisu odbywają się na masterze za pośrednictwem połączenia klienckiego wykonanego z aktualnie biorącego udział w operacji węzła, do powodzenia tej operacji konieczna jest dostępność tego pierwszego. Wynika to z wspomnianego w rozdziale Scenariusze; architektura sieci; założenia architektonicznego. Zapis następuje zawsze na węźle master, więc warunkiem koniecznym jest jego dostępność. 8.6 Diagramy stanu Diagramy stanu reprezentują kolejne stany, w jakich znajduje się system bądź jego obiekt w trakcie wykonywania danych przypadków użycia, a także przejścia pomiędzy tymi stanami. Kolejne rysunki przedstawiają diagramy stanów dla tych samych przypadków użycia, dla których 35

36 przedstawiono diagramy sekwencji. Bardzo pokrewnym rodzajem diagramów są diagramy czynności, które na pierwszym planie skupiają się na czynnościach, a w planie drugorzędnym na stanach, w jakich system znajduje się pomiędzy przejściami. Ze względu na wyjątkową prostotę systemu diagramy te w tym przypadku są praktycznie tożsame, zatem pominięto tworzenie diagramów czynności. Rys. 8.8 diagram maszyny stanów dla przypadku odczytywania zasobu (ReadResource) Podstawowe stany reprezentują własności w dziedzinie zastosowań. Diagram maszyny stanów na rys. 8.8 prezentuje podstawowe stany systemu i warunki przejść między nimi. Przejście ze stanu początkowego do stanu sprawdzenia, czy wskazany zasób istnieje, następuje gdy dostarczony identyfikator jest liczbą naturalną większą od 0. W zależności od powodzenia tej weryfikacji, następuje 36

37 przejście do stanu końcowego w wyniku błędnego odwołania, lub przejście do stanu analizy uprawnień do poprawnie wskazaznego zasobu. W zależności od ustanowionych praw dostępu dla danego zasobu a także statusu użytkownika określony zostaje stopień uprawnienia, tzw. chmod. Wartość rw oznacza pełną kontrolę (odczyt i zapis), r jedynie odczyt, w przeciwnym wypadku dostęp jest zablokowany. Proces na kolejnym diagramie (rys. 9) przebiega analogicznie, przy czym zawiera on pętlę iterującą po kolejnych rekordach wynikowych, aby dla każdego z osobna podjąć decyzję autoryzacji. Rys. 8.9 diagram maszyny stanów dla przypadku przeszukiwania zasobów (SearchResources) 37

38 8.7 Diagram wdrożenia Diagramy wdrożenia mają za zadanie oddać fizyczne rozlokowanie elementów systemu i powiązania między nimi, toteż znajdują zastosowanie głównie w dużych systemach, w szczególności w systemach rozproszonych. Dla systemu składającego się z jednego komponentu lub kilku ulokowanych na tej samej maszynie nie ma większego sensu tworzenia tychże diagramów. Rys. 8.7 przedstawia przykładowy diagram wdrożenia systemu składającego się z trzech węzłów. Elementy umieszczone wewnątrz nich, tj. oprogramowanie, skompilowane, gotowe do użycia komponenty nazywane są w tych diagramach artefaktami. Linie łączące węzły oznaczają ścieżki komunikacyjne. Rys diagram wdrożenia dla sieci składającej się z trzech węzłów 38

39 9. Implementacja 9.1 MySQL W tej części przedstawiona jest struktura całej składającej się na projekt bazy danych oraz jej obiektów, takich jak widoki, procedury składowane oraz indeksy. Pozostałe tabele (użytkownicy, grupy, kategorie itd.) i związane z nimi obiekty (widoki, procedury, funkcje etc.) nie są bezpośrednio częścią projektu, a standardową architekturą bazodanową dla użytego do tego celu systemu webowego [vildev-mysql]. Rys. 9.1 diagram związków encji ERD (Entity Relationship Diagram) Poniżej przedstawiono część kodu SQL tworzącego obiekty bazy, pomijając nieistotne z punktu widzenia samego DLRS standardowe obiekty CMS-a ViLDeV, związane z obsługą natywnych encji, 39

ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja

ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja ZPKSoft WDoradca 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja 1. Wstęp ZPKSoft WDoradca jest technologią dostępu przeglądarkowego do zasobów systemu ZPKSoft Doradca.

Bardziej szczegółowo

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV Piotr Jarosik, Kamil Jaworski, Dominik Olędzki, Anna Stępień Dokumentacja wstępna TIN Rozproszone repozytorium oparte o WebDAV 1. Wstęp Celem projektu jest zaimplementowanie rozproszonego repozytorium

Bardziej szczegółowo

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie z Seminarium Dyplomowego Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Bardziej szczegółowo

Od czego zacząć przy budowaniu środowisk wysokiej dostępności?

Od czego zacząć przy budowaniu środowisk wysokiej dostępności? Budowanie środowisk wysokiej dostępności w oparciu o nową wersję IDS 11 Artur Wroński IBM Information Management Technical Team Leader artur.wronski@pl.ibm.com Od czego zacząć przy budowaniu środowisk

Bardziej szczegółowo

Autorytatywne serwery DNS w technologii Anycast + IPv6 DNS NOVA. Dlaczego DNS jest tak ważny?

Autorytatywne serwery DNS w technologii Anycast + IPv6 DNS NOVA. Dlaczego DNS jest tak ważny? Autorytatywne serwery DNS w technologii Anycast + IPv6 DNS NOVA Dlaczego DNS jest tak ważny? DNS - System Nazw Domenowych to globalnie rozmieszczona usługa Internetowa. Zapewnia tłumaczenie nazw domen

Bardziej szczegółowo

Bazy danych 2. Wykład 1

Bazy danych 2. Wykład 1 Bazy danych 2 Wykład 1 Sprawy organizacyjne Materiały i listy zadań zamieszczane będą na stronie www.math.uni.opole.pl/~ajasi E-mail: standardowy ajasi@math.uni.opole.pl Sprawy organizacyjne Program wykładu

Bardziej szczegółowo

Plan. Wprowadzenie. Co to jest APEX? Wprowadzenie. Administracja obszarem roboczym

Plan. Wprowadzenie. Co to jest APEX? Wprowadzenie. Administracja obszarem roboczym 1 Wprowadzenie do środowiska Oracle APEX, obszary robocze, użytkownicy Wprowadzenie Plan Administracja obszarem roboczym 2 Wprowadzenie Co to jest APEX? Co to jest APEX? Architektura Środowisko Oracle

Bardziej szczegółowo

Sposoby klastrowania aplikacji webowych w oparciu o rozwiązania OpenSource. Piotr Klimek. piko@piko.homelinux.net

Sposoby klastrowania aplikacji webowych w oparciu o rozwiązania OpenSource. Piotr Klimek. piko@piko.homelinux.net Sposoby klastrowania aplikacji webowych w oparciu o rozwiązania OpenSource Piotr Klimek piko@piko.homelinux.net Agenda Wstęp Po co to wszystko? Warstwa WWW Warstwa SQL Warstwa zasobów dyskowych Podsumowanie

Bardziej szczegółowo

Aplikacje webowe w obliczu ataków internetowych na przykładzie CodeIgniter Framework

Aplikacje webowe w obliczu ataków internetowych na przykładzie CodeIgniter Framework Uniwersytet Zielonogórski Wydział Elektrotechniki, Informatyki i Telekomunikacji Aplikacje webowe w obliczu ataków internetowych na przykładzie CodeIgniter Framework mgr inż. Łukasz Stefanowicz dr inż.

Bardziej szczegółowo

Usługi analityczne budowa kostki analitycznej Część pierwsza.

Usługi analityczne budowa kostki analitycznej Część pierwsza. Usługi analityczne budowa kostki analitycznej Część pierwsza. Wprowadzenie W wielu dziedzinach działalności człowieka analiza zebranych danych jest jednym z najważniejszych mechanizmów podejmowania decyzji.

Bardziej szczegółowo

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Jerzy Brzeziński, Anna Kobusińska, Dariusz Wawrzyniak Instytut Informatyki Politechnika Poznańska Plan prezentacji 1 Architektura

Bardziej szczegółowo

Referat pracy dyplomowej

Referat pracy dyplomowej Referat pracy dyplomowej Temat pracy: Wdrożenie intranetowej platformy zapewniającej organizację danych w dużej firmie na bazie oprogramowania Microsoft SharePoint Autor: Bartosz Lipiec Promotor: dr inż.

Bardziej szczegółowo

I. Informacje ogólne. Jednym z takich systemów jest Mambo.

I. Informacje ogólne. Jednym z takich systemów jest Mambo. MAMBO (CMS) I. Informacje ogólne CMS, Content Management System ("system zarządzania treścią") jest to jedna lub zestaw aplikacji internetowych pozwalających na łatwe utworzenie oraz późniejszą aktualizację

Bardziej szczegółowo

REFERAT O PRACY DYPLOMOWEJ

REFERAT O PRACY DYPLOMOWEJ REFERAT O PRACY DYPLOMOWEJ Temat pracy: Projekt i realizacja elektronicznego dziennika ocen ucznia Autor: Grzegorz Dudek wykonanego w technologii ASP.NET We współczesnym modelu edukacji, coraz powszechniejsze

Bardziej szczegółowo

System kontroli wersji - wprowadzenie. Rzeszów,2 XII 2010

System kontroli wersji - wprowadzenie. Rzeszów,2 XII 2010 System kontroli wersji - wprowadzenie Rzeszów,2 XII 2010 System kontroli wersji System kontroli wersji (ang. version/revision control system) służy do śledzenia zmian głównie w kodzie źródłowym oraz pomocy

Bardziej szczegółowo

2014 Electronics For Imaging. Informacje zawarte w niniejszej publikacji podlegają postanowieniom opisanym w dokumencie Uwagi prawne dotyczącym tego

2014 Electronics For Imaging. Informacje zawarte w niniejszej publikacji podlegają postanowieniom opisanym w dokumencie Uwagi prawne dotyczącym tego 2014 Electronics For Imaging. Informacje zawarte w niniejszej publikacji podlegają postanowieniom opisanym w dokumencie Uwagi prawne dotyczącym tego produktu. 23 czerwca 2014 Spis treści 3 Spis treści...5

Bardziej szczegółowo

System Kancelaris. Zdalny dostęp do danych

System Kancelaris. Zdalny dostęp do danych Kancelaris krok po kroku System Kancelaris Zdalny dostęp do danych Data modyfikacji: 2008-07-10 Z czego składaj adają się systemy informatyczne? System Kancelaris składa się z dwóch części: danych oprogramowania,

Bardziej szczegółowo

Koncepcja wirtualnej pracowni GIS w oparciu o oprogramowanie open source

Koncepcja wirtualnej pracowni GIS w oparciu o oprogramowanie open source Koncepcja wirtualnej pracowni GIS w oparciu o oprogramowanie open source Dr inż. Michał Bednarczyk Uniwersytet Warmińsko-Mazurski w Olsztynie Wydział Geodezji i Gospodarki Przestrzennej Katedra Geodezji

Bardziej szczegółowo

Projektowani Systemów Inf.

Projektowani Systemów Inf. Projektowani Systemów Inf. Wykład VII Bezpieczeństwo Copyrights by Arkadiusz Rzucidło 1 Bezpieczeństwo Bezpieczeństwo związane z danymi Konstrukcja magazynów danych Mechanizmy zapisu i modyfikacji danych

Bardziej szczegółowo

Wykład I. Wprowadzenie do baz danych

Wykład I. Wprowadzenie do baz danych Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles

Bardziej szczegółowo

Bazy danych. Wykład IV SQL - wprowadzenie. Copyrights by Arkadiusz Rzucidło 1

Bazy danych. Wykład IV SQL - wprowadzenie. Copyrights by Arkadiusz Rzucidło 1 Bazy danych Wykład IV SQL - wprowadzenie Copyrights by Arkadiusz Rzucidło 1 Czym jest SQL Język zapytań deklaratywny dostęp do danych Składnia łatwa i naturalna Standardowe narzędzie dostępu do wielu różnych

Bardziej szczegółowo

Instalacja SQL Server Express. Logowanie na stronie Microsoftu

Instalacja SQL Server Express. Logowanie na stronie Microsoftu Instalacja SQL Server Express Logowanie na stronie Microsoftu Wybór wersji do pobrania Pobieranie startuje, przechodzimy do strony z poradami. Wypakowujemy pobrany plik. Otwiera się okno instalacji. Wybieramy

Bardziej szczegółowo

Rok szkolny 2015/16 Sylwester Gieszczyk. Wymagania edukacyjne w technikum. ADMINISTROWANIE BAZAMI DANYCH kl. 4c

Rok szkolny 2015/16 Sylwester Gieszczyk. Wymagania edukacyjne w technikum. ADMINISTROWANIE BAZAMI DANYCH kl. 4c Wymagania edukacyjne w technikum ADMINISTROWANIE BAZAMI DANYCH kl. 4c Lp. 1 2 4 5 Temat Zasady dotyczące zarządzania projektem podczas prac związanych z tworzeniem bazy oraz cykl życiowy bazy Modele tworzenia

Bardziej szczegółowo

Wykonać Ćwiczenie: Active Directory, konfiguracja Podstawowa

Wykonać Ćwiczenie: Active Directory, konfiguracja Podstawowa Wykonać Ćwiczenie: Active Directory, konfiguracja Podstawowa Instalacja roli kontrolera domeny, Aby zainstalować rolę kontrolera domeny, należy uruchomić Zarządzenie tym serwerem, po czym wybrać przycisk

Bardziej szczegółowo

Tomasz Grześ. Systemy zarządzania treścią

Tomasz Grześ. Systemy zarządzania treścią Tomasz Grześ Systemy zarządzania treścią Co to jest CMS? CMS (ang. Content Management System System Zarządzania Treścią) CMS definicje TREŚĆ Dowolny rodzaj informacji cyfrowej. Może to być np. tekst, obraz,

Bardziej szczegółowo

Praca w sieci z serwerem

Praca w sieci z serwerem 11 Praca w sieci z serwerem Systemy Windows zostały zaprojektowane do pracy zarówno w sieci równoprawnej, jak i w sieci z serwerem. Sieć klient-serwer oznacza podłączenie pojedynczego użytkownika z pojedynczej

Bardziej szczegółowo

Jarosław Kuchta Administrowanie Systemami Komputerowymi. Internetowe Usługi Informacyjne

Jarosław Kuchta Administrowanie Systemami Komputerowymi. Internetowe Usługi Informacyjne Jarosław Kuchta Internetowe Usługi Informacyjne Komponenty IIS HTTP.SYS serwer HTTP zarządzanie połączeniami TCP/IP buforowanie odpowiedzi obsługa QoS (Quality of Service) obsługa plików dziennika IIS

Bardziej szczegółowo

KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED

KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED Podręcznik użytkownika Katowice 2010 Producent programu: KAMSOFT S.A. ul. 1 Maja 133 40-235 Katowice Telefon: (0-32) 209-07-05 Fax:

Bardziej szczegółowo

Aplikacje WWW - laboratorium

Aplikacje WWW - laboratorium Aplikacje WWW - laboratorium PHP + bazy danych Celem ćwiczenia jest przygotowanie prostej aplikacji internetowej wykorzystującej technologię PHP. Aplikacja pokazuje takie aspekty, współpraca PHP z bazami

Bardziej szczegółowo

Jednym z najważniejszych zagadnień, z którym może się zetknąć twórca

Jednym z najważniejszych zagadnień, z którym może się zetknąć twórca Uwierzytelnianie w PHP 01 Jednym z najważniejszych zagadnień, z którym może się zetknąć twórca stron internetowych, jest identyfikacja i uwierzytelnienie uprzywilejowanego użytkownika. Od zaprojektowania

Bardziej szczegółowo

Red Hat Network Satellite Server

Red Hat Network Satellite Server Red Hat Network Satellite Server Bogumił Stoiński RHC{E,I,X} B2B Sp. z o.o. 600 017 006 bs@bel.pl Usługa Red Hat Network 2 Usługa Red Hat Network Zintegrowane platforma stworzona do zarządzania systemami

Bardziej szczegółowo

OFFICE 365 + ADFS - POŁĄCZENIE KORZYŚCI ROZWIĄZAŃ CHMUROWYCH I CENTRALNEGO ZARZĄDZANIA

OFFICE 365 + ADFS - POŁĄCZENIE KORZYŚCI ROZWIĄZAŃ CHMUROWYCH I CENTRALNEGO ZARZĄDZANIA Marta Grum, Administrator Systemów Microsoft w Grupie Unity OFFICE 365 + ADFS - POŁĄCZENIE KORZYŚCI ROZWIĄZAŃ CHMUROWYCH I CENTRALNEGO ZARZĄDZANIA Usługa Office365 jest niezbędnym pakietem narzędzi wykorzystywanych

Bardziej szczegółowo

WINDOWS Instalacja serwera WWW na systemie Windows XP, 7, 8.

WINDOWS Instalacja serwera WWW na systemie Windows XP, 7, 8. WINDOWS Instalacja serwera WWW na systemie Windows XP, 7, 8. Gdy już posiadamy serwer i zainstalowany na nim system Windows XP, 7 lub 8 postawienie na nim serwera stron WWW jest bardzo proste. Wystarczy

Bardziej szczegółowo

Deduplikacja danych. Zarządzanie jakością danych podstawowych

Deduplikacja danych. Zarządzanie jakością danych podstawowych Deduplikacja danych Zarządzanie jakością danych podstawowych normalizacja i standaryzacja adresów standaryzacja i walidacja identyfikatorów podstawowa standaryzacja nazw firm deduplikacja danych Deduplication

Bardziej szczegółowo

Currenda EPO Instrukcja Konfiguracji. Wersja dokumentu: 1.3

Currenda EPO Instrukcja Konfiguracji. Wersja dokumentu: 1.3 Currenda EPO Instrukcja Konfiguracji Wersja dokumentu: 1.3 Currenda EPO Instrukcja Konfiguracji - wersja dokumentu 1.3-19.08.2014 Spis treści 1 Wstęp... 4 1.1 Cel dokumentu... 4 1.2 Powiązane dokumenty...

Bardziej szczegółowo

Galileo - encyklopedia internetowa Plan testów

Galileo - encyklopedia internetowa Plan testów Galileo - encyklopedia internetowa Plan testów Sławomir Pawlewicz Alan Pilawa Joanna Sobczyk Matek Sobierajski 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel..........................................

Bardziej szczegółowo

Dokument Detaliczny Projektu

Dokument Detaliczny Projektu Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej

Bardziej szczegółowo

Instrukcja do panelu administracyjnego. do zarządzania kontem FTP WebAs. www.poczta.greenlemon.pl

Instrukcja do panelu administracyjnego. do zarządzania kontem FTP WebAs. www.poczta.greenlemon.pl Instrukcja do panelu administracyjnego do zarządzania kontem FTP WebAs www.poczta.greenlemon.pl Opracowanie: Agencja Mediów Interaktywnych GREEN LEMON Spis treści 1.Wstęp 2.Konfiguracja 3.Konto FTP 4.Domeny

Bardziej szczegółowo

Grzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat

Grzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat Grzegorz Ruciński Warszawska Wyższa Szkoła Informatyki 2011 Promotor dr inż. Paweł Figat Cel i hipoteza pracy Wprowadzenie do tematu Przedstawienie porównywanych rozwiązań Przedstawienie zalet i wad porównywanych

Bardziej szczegółowo

instrukcja INSTALACJI www.piersa.pl APi_proxy

instrukcja INSTALACJI www.piersa.pl APi_proxy instrukcja INSTALACJI 1 1. Instalacja Proces instalacji jest prosty wgrywamy pliki na serwer nadajemy prawa chmod 777 lub 755 dla katalogu w którym znajduje się aplikacja przeważnie będzie to katalog public_html

Bardziej szczegółowo

Xopero Backup Build your private cloud backup environment. Rozpoczęcie pracy

Xopero Backup Build your private cloud backup environment. Rozpoczęcie pracy Xopero Backup Build your private cloud backup environment Rozpoczęcie pracy 07.05.2015 Spis treści Wstęp... 2 Pobierz aplikację Management Center... 2 Przygotuj Xopero do pracy... 3 Zmień hasło administratora...

Bardziej szczegółowo

Wykaz zmian w programie Win Admin Replikator

Wykaz zmian w programie Win Admin Replikator Wykaz zmian w programie Win Admin Replikator Pierwsza wersja programu 1.0.0.0 powstała w czerwcu 2010. kod źródłowy programu zawiera ponad 6 900 wierszy. Modyfikacje/zmiany w wersji 1.0.4.0 (październik

Bardziej szczegółowo

Forum Client - Spring in Swing

Forum Client - Spring in Swing Forum Client - Spring in Swing Paweł Charkowski. 0. Cel projektu Celem projektu jest próba integracji Spring Framework z różnymi technologiami realizacji interfejsu użytkownika, oraz jej ocena. Niniejszy

Bardziej szczegółowo

W dalszej części dokumentu przedstawiamy skrócony opis kluczowych funkcji systemu. Niniejszy dokument nie zawiera opisu technicznego systemu.

W dalszej części dokumentu przedstawiamy skrócony opis kluczowych funkcji systemu. Niniejszy dokument nie zawiera opisu technicznego systemu. 1. Informacje Podstawowe Mediamanager 2.1 jest systemem wspierającym zarządzanie dokumentami elektronicznymi. Podstawowymi funkcjami realizowanymi przez oprogramowanie jest przetrzymywanie, zarządzanie

Bardziej szczegółowo

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r.

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r. ZAPYTANIE OFERTOWE Wrocław, dnia 23.03.2015 r. W związku z realizacją przez Nova Telecom spółka z ograniczoną odpowiedzialnością, projektu pn.: Wdrożenie zintegrowanego systemu klasy B2B, umożliwiającego

Bardziej szczegółowo

Webowy generator wykresów wykorzystujący program gnuplot

Webowy generator wykresów wykorzystujący program gnuplot Uniwersytet Mikołaja Kopernika Wydział Fizyki, Astronomii i Informatyki Stosowanej Marcin Nowak nr albumu: 254118 Praca inżynierska na kierunku informatyka stosowana Webowy generator wykresów wykorzystujący

Bardziej szczegółowo

BMC Control-M Wybrane przypadki zastosowania

BMC Control-M Wybrane przypadki zastosowania Piotr Orlański Mariusz Gajewski CompFort Meridian Polska & BMC Software BMC Control-M Wybrane przypadki zastosowania Warszawa, 11 czerwca 2015 DISASTER RECOVERY Środowisko bankowe Problem: Zorganizowanie

Bardziej szczegółowo

INFORMATYKA Pytania ogólne na egzamin dyplomowy

INFORMATYKA Pytania ogólne na egzamin dyplomowy INFORMATYKA Pytania ogólne na egzamin dyplomowy 1. Wyjaśnić pojęcia problem, algorytm. 2. Podać definicję złożoności czasowej. 3. Podać definicję złożoności pamięciowej. 4. Typy danych w języku C. 5. Instrukcja

Bardziej szczegółowo

4. Podstawowa konfiguracja

4. Podstawowa konfiguracja 4. Podstawowa konfiguracja Po pierwszym zalogowaniu się do urządzenia należy zweryfikować poprawność licencji. Można to zrobić na jednym z widżetów panelu kontrolnego. Wstępną konfigurację można podzielić

Bardziej szczegółowo

Praca w sieci równorzędnej

Praca w sieci równorzędnej Praca w sieci równorzędnej 1. Architektura sieci równorzędnej i klient-serwer Serwer - komputer, który udostępnia zasoby lub usługi. Klient komputer lub urządzenie korzystające z udostępnionych przez serwer

Bardziej szczegółowo

UNIX: architektura i implementacja mechanizmów bezpieczeństwa. Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci

UNIX: architektura i implementacja mechanizmów bezpieczeństwa. Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci UNIX: architektura i implementacja mechanizmów bezpieczeństwa Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci Plan prezentacji: Wprowadzenie do struktury systemów rodziny UNIX

Bardziej szczegółowo

Przepełnienie bufora. SQL Injection Załączenie zewnętrznego kodu XSS. Nabycie uprawnień innego użytkownika/klienta/administratora

Przepełnienie bufora. SQL Injection Załączenie zewnętrznego kodu XSS. Nabycie uprawnień innego użytkownika/klienta/administratora NAUKOWA I AKADEMICKA SIEĆ KOMPUTEROWA Bezpieczeństwo rozwiązań hostingowych Hosting wirtualny - studium przypadku Secure 2008 3 października 2008 Arkadiusz Kalicki, NASK Agenda Zagrożenia Omówienie zabezpieczeń

Bardziej szczegółowo

SYSTEMY OPERACYJNE: STRUKTURY I FUNKCJE (opracowano na podstawie skryptu PP: Królikowski Z., Sajkowski M. 1992: Użytkowanie systemu operacyjnego UNIX)

SYSTEMY OPERACYJNE: STRUKTURY I FUNKCJE (opracowano na podstawie skryptu PP: Królikowski Z., Sajkowski M. 1992: Użytkowanie systemu operacyjnego UNIX) (opracowano na podstawie skryptu PP: Królikowski Z., Sajkowski M. 1992: Użytkowanie systemu operacyjnego UNIX) W informatyce występują ściśle obok siebie dwa pojęcia: sprzęt (ang. hardware) i oprogramowanie

Bardziej szczegółowo

Podstawowe pojęcia dotyczące relacyjnych baz danych. mgr inż. Krzysztof Szałajko

Podstawowe pojęcia dotyczące relacyjnych baz danych. mgr inż. Krzysztof Szałajko Podstawowe pojęcia dotyczące relacyjnych baz danych mgr inż. Krzysztof Szałajko Czym jest baza danych? Co rozumiemy przez dane? Czym jest system zarządzania bazą danych? 2 / 25 Baza danych Baza danych

Bardziej szczegółowo

Dokument Detaliczny Projektu

Dokument Detaliczny Projektu Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej

Bardziej szczegółowo

Usługi sieciowe systemu Linux

Usługi sieciowe systemu Linux Usługi sieciowe systemu Linux 1. Serwer WWW Najpopularniejszym serwerem WWW jest Apache, dostępny dla wielu platform i rozprowadzany w pakietach httpd. Serwer Apache bardzo często jest wykorzystywany do

Bardziej szczegółowo

Bydgoskie Centrum Archiwizacji Cyfrowej sp. z o.o.

Bydgoskie Centrum Archiwizacji Cyfrowej sp. z o.o. STRONA GŁÓWNA ` Usługa earchiwizacja.pl przeznaczona jest zarówno dla osób indywidualnych, jak i firm. Wykorzystuje zasadę przetwarzania danych w chmurze. Pozwala to na dostęp do własnej bazy dokumentów

Bardziej szczegółowo

SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH. info@prointegra.com.pl tel: +48 (032) 730 00 42

SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH. info@prointegra.com.pl tel: +48 (032) 730 00 42 SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH info@prointegra.com.pl tel: +48 (032) 730 00 42 1. WPROWADZENIE... 3 2. KORZYŚCI BIZNESOWE... 4 3. OPIS FUNKCJONALNY VILM... 4 KLUCZOWE FUNKCJE

Bardziej szczegółowo

REFERAT PRACY DYPLOMOWEJ

REFERAT PRACY DYPLOMOWEJ REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany

Bardziej szczegółowo

World Wide Web? rkijanka

World Wide Web? rkijanka World Wide Web? rkijanka World Wide Web? globalny, interaktywny, dynamiczny, wieloplatformowy, rozproszony, graficzny, hipertekstowy - system informacyjny, działający na bazie Internetu. 1.Sieć WWW jest

Bardziej szczegółowo

OPIS PRZEDMIOTU ZAMÓWIENIA

OPIS PRZEDMIOTU ZAMÓWIENIA Lubelskie Centrum Transferu Technologii Politechniki Lubelskiej ul. Nadbystrzycka 36, 20-618 Lublin Tel. 81 538 42 70, fax. 81 538 42 67; e-mail: lctt@pollub.pl OPIS PRZEDMIOTU ZAMÓWIENIA Do realizacji

Bardziej szczegółowo

Wdrożenie modułu płatności eservice. dla systemu Magento 1.4 1.9

Wdrożenie modułu płatności eservice. dla systemu Magento 1.4 1.9 Wdrożenie modułu płatności eservice dla systemu Magento 1.4 1.9 - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie do

Bardziej szczegółowo

AE/ZP-27-16/14. Oprogramowanie do wykonywania kopii zapasowych oraz zarządzania maszynami wirtualnymi

AE/ZP-27-16/14. Oprogramowanie do wykonywania kopii zapasowych oraz zarządzania maszynami wirtualnymi AE/ZP-27-16/14 Załącznik B Oprogramowanie do wykonywania kopii zapasowych oraz zarządzania maszynami wirtualnymi Wykonywanie kopii zapasowych Oprogramowanie do archiwizacji musi współpracować z infrastrukturą

Bardziej szczegółowo

KS-ZSA. Korporacyjne grupy towarowe

KS-ZSA. Korporacyjne grupy towarowe KS-ZSA Korporacyjne grupy towarowe 1. Ustawienia po stronie KS-ZSA Aby rozpocząć pracę z korporacyjnymi grupami towarowymi system KS-ZSA należy odpowiednio skonfigurować KS-ZSA: Uprawnienia: - 61.Admin

Bardziej szczegółowo

Sposób funkcjonowania

Sposób funkcjonowania Stratus Avance został zaprojektowany w sposób, który w przypadku wystąpienia awarii ma zminimalizować czas przestoju i zapobiec utracie danych. Jednocześnie rozwiązanie ma być tanie i łatwe w zarządzaniu.

Bardziej szczegółowo

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce)

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce) emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce) Zastosowanie Rozszerzenie to dedykowane jest sklepom internetowych zbudowanym w oparciu

Bardziej szczegółowo

ZALECENIA DLA MIGRACJI NS-BSD V8 => V9

ZALECENIA DLA MIGRACJI NS-BSD V8 => V9 ZALECENIA DLA MIGRACJI NS-BSD V8 => V9 Wprowadzenie Wersja 9 NS-BSD wprowadza wiele zmian. Zmieniła się koncepcja działania niektórych modułów NETASQ UTM. Sam proces aktualizacji nie jest więc całkowicie

Bardziej szczegółowo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej

Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej Małgorzata Barańska Wydział Informatyki i Zarządzania, Politechnika Wrocławska Beata Laszkiewicz Wydział

Bardziej szczegółowo

FAQ Systemu EKOS. 1. Jakie są wymagania techniczne dla stanowiska wprowadzania ocen?

FAQ Systemu EKOS. 1. Jakie są wymagania techniczne dla stanowiska wprowadzania ocen? 27.06.11 FAQ Systemu EKOS 1. Jakie są wymagania techniczne dla stanowiska wprowadzania ocen? Procedura rejestracji ocen wymaga podpisywania protokołów (w postaci wypełnionych formularzy InfoPath Forms

Bardziej szczegółowo

Instrukcja instalacji i obsługi programu Szpieg 3

Instrukcja instalacji i obsługi programu Szpieg 3 COMPUTER SERVICE CENTER 43-300 Bielsko-Biała ul. Cieszyńska 52 tel. +48 (33) 819 35 86, 819 35 87, 601 550 625 Instrukcja instalacji i obsługi programu Szpieg 3 wersja 0.0.2 123 SERWIS Sp. z o. o. ul.

Bardziej szczegółowo

Bazy danych. Plan wykładu. Rozproszona baza danych. Fragmetaryzacja. Cechy bazy rozproszonej. Replikacje (zalety) Wykład 15: Rozproszone bazy danych

Bazy danych. Plan wykładu. Rozproszona baza danych. Fragmetaryzacja. Cechy bazy rozproszonej. Replikacje (zalety) Wykład 15: Rozproszone bazy danych Plan wykładu Bazy danych Cechy rozproszonej bazy danych Implementacja rozproszonej bazy Wykład 15: Rozproszone bazy danych Małgorzata Krętowska, Agnieszka Oniśko Wydział Informatyki PB Bazy danych (studia

Bardziej szczegółowo

Część I Rozpoczęcie pracy z usługami Reporting Services

Część I Rozpoczęcie pracy z usługami Reporting Services Spis treści Podziękowania... xi Wprowadzenie... xiii Część I Rozpoczęcie pracy z usługami Reporting Services 1 Wprowadzenie do usług Reporting Services... 3 Platforma raportowania... 3 Cykl życia raportu...

Bardziej szczegółowo

16MB - 2GB 2MB - 128MB

16MB - 2GB 2MB - 128MB FAT Wprowadzenie Historia FAT jest jednym z najstarszych spośród obecnie jeszcze używanych systemów plików. Pierwsza wersja (FAT12) powstała w 1980 roku. Wraz z wzrostem rozmiaru dysków i nowymi wymaganiami

Bardziej szczegółowo

Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC

Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC Akademia MetaPack Uniwersytet Zielonogórski Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC Krzysztof Blacha Microsoft Certified Professional Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC Agenda:

Bardziej szczegółowo

Instalacja i konfiguracja Symfonia.Common.Server oraz Symfonia.Common.Forte

Instalacja i konfiguracja Symfonia.Common.Server oraz Symfonia.Common.Forte Instalacja i konfiguracja Symfonia.Common.Server oraz Symfonia.Common.Forte Instalacja Symfonia.Common.Server 0 2 Spis treści Spis treści 2 Instalacja Symfonia.Common.Server 3 Ważne zalecenia... 3 Konfiguracja

Bardziej szczegółowo

Załącznik nr 1. Specyfikacja techniczna portalu internetowego Łódź, 15.10.2012 r.

Załącznik nr 1. Specyfikacja techniczna portalu internetowego Łódź, 15.10.2012 r. Załącznik nr 1. Specyfikacja techniczna portalu internetowego Łódź, 15.10.2012 r. Stworzenie platformy internetowej na potrzeby projektu. 1 Wykonanie portalu internetowego na potrzeby e-usługi, obejmującego

Bardziej szczegółowo

Serwer druku w Windows Server

Serwer druku w Windows Server Serwer druku w Windows Server Ostatnimi czasy coraz większą popularnością cieszą się drukarki sieciowe. Często w domach użytkownicy posiadają więcej niż jedno urządzenie podłączone do sieci, z którego

Bardziej szczegółowo

Budowa i oprogramowanie komputerowych systemów sterowania. Laboratorium 4. Metody wymiany danych w systemach automatyki DDE

Budowa i oprogramowanie komputerowych systemów sterowania. Laboratorium 4. Metody wymiany danych w systemach automatyki DDE Budowa i oprogramowanie komputerowych systemów sterowania Laboratorium 4 Metody wymiany danych w systemach automatyki DDE 1 Wprowadzenie do DDE DDE (ang. Dynamic Data Exchange) - protokół wprowadzony w

Bardziej szczegółowo

dziennik Instrukcja obsługi

dziennik Instrukcja obsługi Ham Radio Deluxe dziennik Instrukcja obsługi Wg. Simon Brown, HB9DRV Tłumaczenie SP4JEU grudzień 22, 2008 Zawartość 3 Wprowadzenie 5 Po co... 5 Główne cechy... 5 baza danych 7 ODBC... 7 Który produkt

Bardziej szczegółowo

Problemy optymalizacji, rozbudowy i integracji systemu Edu wspomagającego e-nauczanie i e-uczenie się w PJWSTK

Problemy optymalizacji, rozbudowy i integracji systemu Edu wspomagającego e-nauczanie i e-uczenie się w PJWSTK Problemy optymalizacji, rozbudowy i integracji systemu Edu wspomagającego e-nauczanie i e-uczenie się w PJWSTK Paweł Lenkiewicz Polsko Japońska Wyższa Szkoła Technik Komputerowych Plan prezentacji PJWSTK

Bardziej szczegółowo

Gerard Frankowski, Zespół Bezpieczeństwa PCSS. Nowoczesne technologie bliżej nas Poznań, 04.03.2010

Gerard Frankowski, Zespół Bezpieczeństwa PCSS. Nowoczesne technologie bliżej nas Poznań, 04.03.2010 Bezpieczeństwo interoperacyjnego hostingu Gerard Frankowski, Zespół Bezpieczeństwa PCSS 4. Konferencja MIC Nowoczesne technologie bliżej nas Poznań, 04.03.2010 1 Agenda Wprowadzenie Zespół Bezpieczeństwa

Bardziej szczegółowo

Aplikacje WWW - laboratorium

Aplikacje WWW - laboratorium Aplikacje WWW - laboratorium PHP + bazy danych Celem ćwiczenia jest przygotowanie prostej aplikacji internetowej wykorzystującej technologię PHP. Aplikacja pokazuje takie aspekty, współpraca PHP z bazami

Bardziej szczegółowo

Bazy Danych. C. J. Date, Wprowadzenie do systemów baz danych, WNT - W-wa, (seria: Klasyka Informatyki), 2000

Bazy Danych. C. J. Date, Wprowadzenie do systemów baz danych, WNT - W-wa, (seria: Klasyka Informatyki), 2000 Bazy Danych LITERATURA C. J. Date, Wprowadzenie do systemów baz danych, WNT - W-wa, (seria: Klasyka Informatyki), 2000 J. D. Ullman, Systemy baz danych, WNT - W-wa, 1998 J. D. Ullman, J. Widom, Podstawowy

Bardziej szczegółowo

ArtPlayer oprogramowanie do odtwarzania plików video sterowane Artnet/DMX V1.0.1

ArtPlayer oprogramowanie do odtwarzania plików video sterowane Artnet/DMX V1.0.1 Instrukcja obsługi ArtPlayer oprogramowanie do odtwarzania plików video sterowane Artnet/DMX V1.0.1 1 ArtPlayer to proste oprogramowanie umożliwiające odtwarzanie plików video i ich wybór poprzez protokół

Bardziej szczegółowo

Dokumentacja systemu NTP rekrut. Autor: Sławomir Miller

Dokumentacja systemu NTP rekrut. Autor: Sławomir Miller Dokumentacja systemu NTP rekrut Autor: Sławomir Miller 1 Spis treści: 1. Wstęp 1.1 Wprowadzenie 1.2 Zakres dokumentu 2. Instalacja 2.1 Wymagania systemowe 2.2 Początek 2.3 Prawa dostępu 2.4 Etapy instalacji

Bardziej szczegółowo

System generacji raportów

System generacji raportów Zalety systemu Czym jest ProReports? prostota instalacji, wieloplatformowość (AIX, Linux, Windows, Solaris), obsługa popularnych formatów (PDF, XLS, RTF, HTML,TXT,XML,CSV), obsługa wielu baz danych, raporty

Bardziej szczegółowo

Firma Informatyczna ASDER. Prezentacja. Serwer danych zdalnych. Przemysław Kroczak ASDER 2012-08-06

Firma Informatyczna ASDER. Prezentacja. Serwer danych zdalnych. Przemysław Kroczak ASDER 2012-08-06 2012 Firma Informatyczna ASDER Prezentacja Serwer danych zdalnych Przemysław Kroczak ASDER 2012-08-06 Szanowni Państwo, Coraz częściej potrzebujemy dostępu do naszych danych będąc w różnych miejscach na

Bardziej szczegółowo

Skanowanie podsieci oraz wykrywanie terminali ABA-X3

Skanowanie podsieci oraz wykrywanie terminali ABA-X3 Skanowanie podsieci oraz wykrywanie terminali ABA-X3 Terminale ABA-X3 od dostarczane od połowy listopada 2010 r. są wyposażane w oprogramowanie umożliwiające skanowanie podsieci w poszukiwaniu aktywnych

Bardziej szczegółowo

Spis treści. 1 Moduł RFID (APA) 3

Spis treści. 1 Moduł RFID (APA) 3 Spis treści 1 Moduł RFID (APA) 3 1.1 Konfigurowanie Modułu RFID..................... 3 1.1.1 Lista elementów Modułu RFID................. 3 1.1.2 Konfiguracja Modułu RFID (APA)............... 4 1.1.2.1

Bardziej szczegółowo

Zmiana treści Specyfikacji Istotnych Warunków Zamówienia.

Zmiana treści Specyfikacji Istotnych Warunków Zamówienia. Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa Śląskiego na lata 2007-2013 ZP.271.1.2013 Czerwionka-Leszczyny

Bardziej szczegółowo

Instalacja programu Warsztat 3 w sieci

Instalacja programu Warsztat 3 w sieci Instalacja programu Warsztat 3 w sieci (proszę uważnie przeczytać do końca) Spis treści 1 Przed instalacją...2 2 Przeprowadzanie po raz pierwszy instalacji sieciowej...3 2.1 Dane umieszczone na jednej

Bardziej szczegółowo

Praca Magisterska "System zdalnego składania ofert kupna i sprzedaży za pośrednictwem Internetu" AUTOR PROMOTOR

Praca Magisterska System zdalnego składania ofert kupna i sprzedaży za pośrednictwem Internetu AUTOR PROMOTOR System Oferta Praca Magisterska Niniejszy system powstał w ramach pracy magisterskiej "System zdalnego składania ofert kupna i sprzedaży za pośrednictwem Internetu". Politechnika Poznańska Wydział Informatyki

Bardziej szczegółowo

SYSTEMY OPERACYJNE I SIECI KOMPUTEROWE

SYSTEMY OPERACYJNE I SIECI KOMPUTEROWE SYSTEMY OPERACYJNE I SIECI KOMPUTEROWE WINDOWS 1 SO i SK/WIN 007 Tryb rzeczywisty i chroniony procesora 2 SO i SK/WIN Wszystkie 32-bitowe procesory (386 i nowsze) mogą pracować w kilku trybach. Tryby pracy

Bardziej szczegółowo

ABA-X3 PXES v. 1.5.0 Podręczna instrukcja administratora. FUNKCJE SIECIOWE Licencja FDL (bez prawa wprowadzania zmian)

ABA-X3 PXES v. 1.5.0 Podręczna instrukcja administratora. FUNKCJE SIECIOWE Licencja FDL (bez prawa wprowadzania zmian) Grupa Ustawienia Sieciowe umożliwia skonfigurowanie podstawowych parametrów terminala: Interfejs ETH0 Umożliwia wybór ustawień podstawowego interfejsu sieciowego. W przypadku wyboru DHCP adres oraz inne

Bardziej szczegółowo

INSTRUKCJA INSTALACJI I KONFIGURACJI APLIKACJI WEBSOFT CEIDG MONITOR

INSTRUKCJA INSTALACJI I KONFIGURACJI APLIKACJI WEBSOFT CEIDG MONITOR INSTRUKCJA INSTALACJI I KONFIGURACJI APLIKACJI WEBSOFT CEIDG MONITOR Producent: Nazwa oprogramowania: Printec Websoft CEIDG Monitor Aktualna wersja: 1.0 Ostatnia aktualizacja: 25.01.2015 Kontakt: biuro@e-printec.com.pl,

Bardziej szczegółowo

Nieustanny rozwój. Tomasz Leśniewski tomasz.lesniewski@netart.pl

Nieustanny rozwój. Tomasz Leśniewski tomasz.lesniewski@netart.pl Nieustanny rozwój Tomasz Leśniewski tomasz.lesniewski@netart.pl Poczta w chmurze? Czy nazwa.pl ma pocztę w chmurze? Biorąc pod uwagę poniższe kryteria, tak: Dla końcowego użytkownika dostępna jest pełnowartościowa

Bardziej szczegółowo