Poradnik Nt. Migracji Na Wolne Oprogramowanie Na Serwerach I Desktopach

Poradnik nt. migracji na Wolne Oprogramowanie na serwerach i desktopach

wersja 1.0 – lipiec 2003 r.

OpenPoland.org

20 lipca 2004 1

Rzado˛ wy Urzad˛ Koordynacji i Doradztwa ds. Informatyzacji przy Ministerstwie Spraw We- wnetrzn˛ ych Republiki Federalnej Niemiec (KBSt) 2

Szanowni Panstw´ o!

Niniejszy poradnik został przetłumaczony przez osoby wchodzace˛ w skład grupy OpenPoland.org. Pragniemy zaznaczyc,´ ze˙ nasza praca została wykonana nie na zlecenie, lecz za zgoda˛ BMI1. Jednoczesnie´ informujemy, ze˙ tekst niniejszego tłumaczenia udo- stepniamy˛ nieodpłatnie i nie wolno go sprzedawac´ w zadnej˙ postaci. Powyzsze˙ zasady zredagowane zostały w oparciu o uzgodnienia poczynione z BMI jeszcze przed rozpoczeciem˛ prac nad tłumaczeniem. Mamy nadzieje,˛ ze˙ rozwiazania˛ przedstawione w poradniku juz˙ niedługo zyskaja˛ wielu zwolenników, szczególnie wsród´ szerokiego grona osób odpowiedzialnych za funkcjonowanie infrastruktury informatycznej w naszym kraju. Zachecamy˛ Panstwa´ do współpracy nad rozwojem poradnika. Prosimy o zgłaszanie konstruktywnych, krytycznych uwag na adres: [email protected] . Na zakonczenie´ pragniemy podkresli´ c,´ ze˙ nie jestesmy´ organizacja˛ polityczna˛ i tym samym nie popieramy wykorzystywania naszej kampanii na rzecz Wolnego Opro- gramowania do współzawodnictwa politycznego. Zachecamy˛ do owocnej lektury! Grupa OpenPoland.org

1Niemiecki odpowiednik polskiego MSW. Spis tresci´

1 Wprowadzenie 16 1.1 Geneza poradnika ...... 16 1.2 O poradniku ...... 17 1.3 Jak korzystac´ z poradnika? ...... 19 1.4 Wskazówki dla decydentów ...... 21 1.4.1 Podstawowe zalecenia ...... 21 1.4.2 Migracja kontynuacyjna i zastepuj˛ aca˛ ...... 22 1.4.3 Rózne˙ drogi migracji ...... 22 1.4.4 Porównanie alternatywnych rozwiaza˛ n´ ...... 23 1.4.5 Istotne zagadnienia przyszłoscio´ we ...... 24 1.4.6 Korzysci´ ekonomiczne ...... 26

2 Najwazniejsze˙ zagadnienia 28 2.1 Wazne˙ deﬁnicje ...... 28 2.1.1 Open Source, Free Software ...... 28 2.1.2 Oprogramowanie własnoscio´ we ...... 29 2.1.3 Komercyjne oprogramowanie linuksowe ...... 29 2.1.4 Migracja zastepuj˛ aca˛ ...... 29 2.1.5 Migracja kontynuacyjna ...... 30 2.2 Etapy migracji ...... 30 2.2.1 Punkt wyjscia´ - Microsoft Windows ...... 31 2.2.2 Przeglad˛ systemu dla migracji zastepuj˛ acej˛ ...... 34 2.2.3 Przeglad˛ systemu dla migracji kontynuacyjnej ...... 35 2.2.4 Wewnetrzne˛ zalezno˙ sci´ systemu opartego o rozwiazania˛ ﬁrmy Microsoft 36 2.3 Dystrybucje Linuksa ...... 39 2.3.1 Wprowadzenie ...... 39

3 SPIS TRESCI´ 4

2.3.2 Debian GNU/Linux ...... 41 2.3.3 SuSE Linux Distribution ...... 42 2.3.4 Red Hat ...... 43 2.3.5 Certyﬁkaty ...... 44 2.3.6 Wnioski ...... 46 2.4 Licencje ...... 47 2.4.1 GPL ...... 47 2.4.2 Lesser GPL ...... 48 2.4.3 BSD ...... 48 2.5 Zbieranie informacji o projektach ...... 49 2.5.1 Doswiadczenia´ z projektów migracyjnych ...... 50 2.5.2 Opinie ekspertów ...... 53

3 Techniczne opisy migracji 54 3.1 Wprowadzenie ...... 54 3.2 Zarzadzanie˛ plikami ...... 56 3.2.1 Przeglad˛ ...... 56 3.2.2 Windows NT 4 ...... 57 3.2.2.1 Wymagania odnosnie´ funkcjonalnosci´ ...... 57 3.2.2.2 System plików NTFS4 ...... 58 3.2.2.3 Ustawianie praw dostepu˛ ...... 62 3.2.2.4 Uzytko˙ wnicy i znaczenie grup ...... 63 3.2.2.5 Narzedzia˛ ...... 65 3.2.2.6 Protokoły sieciowe ...... 66 3.2.2.7 Zestawianie połaczenia˛ ...... 67 3.2.2.8 Migracja - szczegóły robocze ...... 67 3.2.2.9 Tematy pokrewne ...... 68 3.2.3 Migracja zastepuj˛ aca˛ ...... 68 3.2.3.1 Wprowadzenie ...... 68 3.2.3.2 Generalne porównanie zakresu funkcji poszczególnych serwe- rów plików ...... 69 3.2.3.3 Samba ...... 71 3.2.4 Migracja kontynuacyjna ...... 81 3.2.4.1 Windows 2000 ...... 81 3.2.4.2 Windows 2003 Server ...... 87 SPIS TRESCI´ 5

3.3 Drukowanie ...... 87 3.3.1 Przeglad˛ ...... 87 3.3.2 Wprowadzenie ...... 88 3.3.3 Punkt wyjscia´ - drukowanie pod Windows NT 4 ...... 90 3.3.3.1 LPR / LPD w Windows NT 4.0 ...... 91 3.3.3.2 Inne porty sieciowe ...... 91 3.3.3.3 Bezposrednie´ drukowanie ze stacji roboczej ...... 92 3.3.3.4 Drukowanie poprzez serwer wydruku ...... 92 3.3.3.5 Metoda „Point & Print“ ...... 93 3.3.3.6 Protokoły sieciowe ...... 96 3.3.3.7 Nadawanie praw dostepu˛ ...... 97 3.3.3.8 Narzedzia˛ ...... 97 3.3.3.9 Migracja - szczegóły robocze ...... 97 3.3.4 Migracja zastepuj˛ aca˛ ...... 98 3.3.4.1 Wymagania odnosnie´ funkcjonalnosci´ ...... 99 3.3.4.2 Obsługa standardów wyrózniaj˙ ac˛ ych sie˛ w procesie drukowania 101 3.3.4.3 Integracja w srodo´ wiskach klienckich Windows ...... 104 3.3.4.4 Mozliwo˙ sci´ dostosowawcze 107 3.3.4.5 Jezyki˛ opisu stron ...... 108 3.3.4.6 Techniczna zmiana funkcji sterownika ...... 108 3.3.4.7 Architektury systemu drukowania ...... 110 3.3.5 Migracja kontynuacyjna ...... 111 3.3.5.1 Windows 2000 ...... 111 3.4 Autoryzacja ...... 112 3.4.1 Przeglad˛ ...... 112 3.4.2 Punkt wyjscia´ - Windows NT 4 ...... 114 3.4.2.1 Domeny ...... 114 3.4.2.2 Wiele domen i relacje zaufania ...... 115 3.4.2.3 NT jako usługa katalogowa ...... 116 3.4.2.4 Delegation ...... 117 3.4.2.5 Podstawy sieci ...... 118 3.4.2.6 Replikacja plików ...... 119 3.4.2.7 Narzedzia˛ administracyjne ...... 119 SPIS TRESCI´ 6

3.4.2.8 Zapisywanie haseł ...... 119 3.4.2.9 Mechanizm autoryzacji ...... 120 3.4.2.10 Single Sign On ...... 122 3.4.2.11 Wytyczne ...... 122 3.4.2.12 Auditing ...... 123 3.4.2.13 Smart Card (mocne mechanizmy autoryzacji) ...... 123 3.4.3 Migracja zastepuj˛ aca˛ - Linux, Samba i OpenLDAP ...... 123 3.4.3.1 Autoryzacja z wykorzystaniem Linux / OpenLDAP i Samby . . 124 3.4.3.2 Synchronizacja hasła ...... 124 3.4.3.3 Relacje zaufania ...... 125 3.4.3.4 WINS ...... 125 3.4.3.5 Ograniczenia w stosowaniu OpenLDAP i Samby ...... 125 3.4.3.6 Kombinacja OpenLDAP i Active Directory ...... 126 3.4.3.7 Narzedzia˛ umozliwiaj˙ ace˛ migracje˛ z Windows NT do Samby / OpenLDAP ...... 126 3.4.3.8 PDC i BDCs w jednej domenie Samby ...... 127 3.4.3.9 Samba jako członek domeny Active Directory ...... 127 3.4.3.10 Narzedzia˛ administracyjne ...... 127 3.4.4 Migracja kontynuacyjna ...... 128 3.4.4.1 Windows 2000 ...... 128 3.5 Usługi sieciowe ...... 128 3.5.1 Przeglad˛ ...... 128 3.5.2 Punkt wyjscia´ - usługi sieciowe pod Windows NT ...... 128 3.5.2.1 Windows Internet Name Service (WINS) ...... 129 3.5.2.2 Domain Name System (DNS) ...... 131 3.5.2.3 Dynamic Host Conﬁguration Protocol (DHCP) ...... 133 3.5.3 Migracja zastepuj˛ aca˛ - usługi sieciowe pod Linuksem ...... 135 3.5.3.1 Domain Name System (DNS) ...... 136 3.5.3.2 Dynamic Host Conﬁguration Protocol (DHCP) ...... 137 3.5.3.3 Windows Internet Name Service (WINS) ...... 138 3.5.3.4 Network Time Protocol (NTP) ...... 138 3.5.4 Migracja kontynuacyjna - usługi sieciowe pod Windows 2000 ...... 138 3.5.4.1 WINS ...... 138 3.5.4.2 DNS ...... 138 SPIS TRESCI´ 7

3.5.4.3 DHCP ...... 139 3.6 Kontrola i zarzadzanie˛ systemem ...... 140 3.6.1 Przeglad˛ ...... 140 3.6.2 Punkt wyjscia´ - serwery zarzadzaj˛ ace˛ systemem pod Windows NT 4 . . . 140 3.6.3 Migracja zastepuj˛ aca˛ - Linux ...... 143 3.6.3.1 Administrowanie oprogramowaniem ...... 143 3.6.3.2 Administrowanie siecia˛ ...... 144 3.6.3.3 Administrowanie serwerami ...... 144 3.6.3.4 Systemy złozone˙ ...... 145 3.6.3.5 Wnioski ...... 145 3.6.4 Migracja kontynuacyjna - Windows 2000 ...... 146 3.6.4.1 Microsoft Operations Manager ...... 146 3.6.4.2 Application Center ...... 147 3.7 Usługi katalogowe ...... 148 3.7.1 Przeglad˛ ...... 148 3.7.2 Podstawy ...... 148 3.7.3 Active Directory Service (ADS) ...... 152 3.7.3.1 Nastepca˛ usługi logowania stosowanej w Windows NT 4 . . . 153 3.7.3.2 Mechanizm autoryzacji Kerberos ...... 154 3.7.3.3 Nowosci´ w strukturze ...... 155 3.7.3.4 Przestrzen´ adresowa DNS i infrastruktura ...... 158 3.7.3.5 Usługa katalogowa i jej schemat ...... 168 3.7.3.6 ADS jako podstawa ...... 169 3.7.3.7 Narzedzia˛ administracyjne ...... 169 3.7.3.8 Certyﬁkacja ...... 170 3.7.3.9 Smart Card ...... 170 3.7.4 Migracja zastepuj˛ aca˛ - Samba i Open LDAP ...... 171 3.7.4.1 Wymagania odnosnie´ funkcjonalnosci´ ...... 171 3.7.4.2 Oceniane produkty ...... 171 3.7.4.3 Generalne porównanie zakresu funkcji udostepnian˛ ych przez NTDS, Active Directory i OpenLDAP ...... 172 3.7.4.4 Autoryzacja z wykorzystaniem Linuksa / OpenLDAP i Samby 173 3.7.4.5 Centralne administrowanie informacjami o hostach z wykorzystaniem Linuksa i OpenLDAP ...... 173 SPIS TRESCI´ 8

3.7.4.6 Integracja innych aplikacji ...... 174 3.7.4.7 Narzedzia˛ administracyjne ...... 174 3.7.4.8 Zachowanie podczas pracy i zuzycie˙ zasobów ...... 175 3.7.4.9 Akceptacja uzytko˙ wników ...... 175 3.7.5 Migracja kontynuacyjna - Wprowadzenie do ADS ...... 175 3.7.5.1 Kolejnos´c´ ...... 175 3.7.5.2 Docelowa architektura ...... 176 3.7.5.3 Przeglad˛ wariantów migracji ...... 176 3.7.5.4 Zadania migracyjne ...... 181 3.7.5.5 Active Directory pod katem˛ Windows 2003 ...... 181 3.7.5.6 Active Directory w minimalnej postaci ...... 182 3.8 Middleware - COM, .NET, J2EE ...... 183 3.8.1 Component Object Model (COM) ...... 184 3.8.2 „.NET” ...... 186 3.8.3 Java 2 Enterprise Edition (J2EE) ...... 188 3.9 Web Services ...... 189 3.9.1 Przeglad˛ ...... 189 3.9.2 Podstawy ...... 190 3.9.3 .Net Web-Services ...... 192 3.9.4 J2EE ...... 193 3.10 XML (Extensible Markup Language) ...... 193 3.11 Serwer WWW ...... 195 3.11.1 Przeglad˛ ...... 195 3.11.2 Wprowadzenie ...... 196 3.11.3 Internet Information Server 4.0 ...... 196 3.11.3.1 Aplikacje Web ...... 197 3.11.3.2 Autoryzacja i bezpieczenstwo´ ...... 198 3.11.3.3 Dodatkowe składniki Internet Information Server ...... 199 3.11.4 Migracja zastepuj˛ aca˛ ...... 200 3.11.4.1 Apache ...... 200 3.11.5 Migracja kontynuacyjna ...... 208 3.11.5.1 Internet Information Server 5.0 ...... 208 3.11.5.2 Internet Information Server 6.0 ...... 210 3.12 SharePoint Portal Server ...... 211 SPIS TRESCI´ 9

3.12.1 Przeglad˛ ...... 211 3.12.2 Wprowadzenie ...... 211 3.12.3 Dashboardsite ...... 212 3.12.4 System Zarzadzanie˛ Dokumentami (DMS) ...... 213 3.12.5 Funkcje wyszukiwania ...... 214 3.12.6 Wnioski ...... 214 3.13 Bazy danych ...... 215 3.13.1 Przeglad˛ ...... 215 3.13.2 Wprowadzenie ...... 215 3.13.3 MS SQL Server 7.0 ...... 216 3.13.3.1 Architektura serwera ...... 216 3.13.3.2 Architektura bazy danych ...... 218 3.13.3.3 Składniki klienckie ...... 220 3.13.3.4 Składniki komunikacyjne ...... 221 3.13.3.5 Skalowalnos´c´ ...... 221 3.13.3.6 Nadawanie praw dostepu˛ ...... 222 3.13.3.7 Integracja systemu ...... 222 3.13.3.8 Administrowanie ...... 222 3.13.4 Migracja zastepuj˛ aca˛ ...... 223 3.13.4.1 MySQL ...... 226 3.13.4.2 PostgreSQL ...... 227 3.13.4.3 Firebird ...... 227 3.13.4.4 SAP DB ...... 228 3.13.4.5 Bilans posredni´ ...... 228 3.13.4.6 Wskazówki ...... 229 3.13.4.7 Zalecenia odnosnie´ niezalezno˙ sci´ ...... 230 3.13.5 Migracja kontynuacyjna ...... 230 3.13.5.1 Microsoft SQL Server 2000 ...... 230 3.14 Groupware ...... 232 3.14.1 Przeglad˛ ...... 232 3.14.2 Wprowadzenie ...... 233 3.14.3 Punkt wyjscia´ - Microsoft Exchange 5.5 ...... 234 3.14.3.1 Infrastruktura podstawowa ...... 234 3.14.3.2 Logiczne jednostki struktury ...... 234 SPIS TRESCI´ 10

3.14.3.3 Składniki podstawowe ...... 234 3.14.3.4 Składniki opcjonalne ...... 237 3.14.3.5 Obsługa protokołów ...... 238 3.14.3.6 Warianty produktu ...... 239 3.14.3.7 Funkcjonalnosci´ uzytko˙ wnika ...... 239 3.14.3.8 Komunikacja klient - serwer ...... 240 3.14.3.9 Komunikacja serwer - serwer ...... 240 3.14.3.10 Tematy pokrewne ...... 240 3.14.4 Migracja zastepuj˛ aca˛ ...... 240 3.14.4.1 phpGroupware ...... 241 3.14.4.2 Kroupware ...... 243 3.14.4.3 exchange4linux ...... 247 3.14.4.4 SuSE Linux OpenExchange Server 4 ...... 250 3.14.4.5 Samsung Contact ...... 254 3.14.4.6 Streszczenie ...... 261 3.14.5 Migracja kontynuacyjna ...... 264 3.14.5.1 Exchange 2000 ...... 264 3.14.5.2 Exchange 2003 ...... 267 3.15 Office / Desktop ...... 270 3.15.1 Przeglad˛ ...... 270 3.15.2 Wprowadzenie ...... 271 3.15.3 Punkt wyjscia´ - MS Office ...... 271 3.15.3.1 Funkcjonalnosci´ ...... 272 3.15.3.2 Srodo´ wisko programistyczne MS Office ...... 273 3.15.4 Migracja zastepuj˛ aca˛ ...... 276 3.15.4.1 Wprowadzenie ...... 276 3.15.4.2 Róznice˙ w formacie plików w porównaniu z MS Office . . . . 279 3.15.4.3 Ograniczenia filtrów konwertujac˛ ych (filtrów importu) . . . . . 281 3.15.4.4 Róznice˙ w działaniu ...... 283 3.15.4.5 Wazne˙ kryteria analizy stanu ...... 287 3.15.4.6 Przygotowanie do konwersji ...... 289 3.15.4.7 Konwertowanie ...... 292 3.15.4.8 Integracja zewnetrzn˛ ych aplikacji ...... 296 3.15.4.9 Migracja makr i sterowanie OLE / COM ...... 296 SPIS TRESCI´ 11

3.15.4.10 Srodo´ wisko programowania OOo/SO ...... 297 3.15.4.11 Kompatybilnosć´ z MS Office ...... 298 3.15.5 Migracja kontynuacyjna ...... 299 3.15.5.1 Office 97 do Office XP ...... 300 3.15.5.2 Spojrzenie w kierunku Office 2003 ...... 302 3.15.6 Inne aplikacje desktopowe ...... 303 3.15.6.1 MS Project ...... 304 3.15.6.2 Desktopy ...... 304 3.15.6.3 Menedzery˙ plików ...... 308 3.15.6.4 Przegladarki˛ WWW ...... 308 3.15.6.5 Klient poczty elektronicznej ...... 310 3.15.6.6 Inne narzedzia˛ ...... 311 3.15.7 Integracja aplikacji Windows przy uzyciu˙ klienta linuksowego ...... 312 3.15.7.1 VMware ...... 313 3.15.7.2 Win4Lin ...... 317 3.15.7.3 Citrix Metaframe ...... 325 3.15.7.4 Windows Terminal Server ...... 326 3.15.8 Ocena ...... 328 3.15.8.1 Zastapienie˛ Office 97/2000 ...... 328 3.16 Terminal-Server i Thin Clients ...... 329 3.16.1 Przeglad˛ ...... 329 3.16.2 Wprowadzenie ...... 330 3.16.3 Linux-Terminal-Server-Project ...... 336 3.16.3.1 Rozwiazanie˛ GOto ...... 336 3.16.3.2 Desktop-Server ...... 337 3.16.4 Usługi terminalowe NX ...... 337 3.16.5 Windows Terminal Services i Citrix ...... 338 3.17 High-availability – systemy wysokiej niezawodnosci´ ...... 342 3.17.1 Cele ...... 342 3.17.2 „Pie˛c´ dziewiatek”˛ a rzeczywistosć´ ...... 343 3.17.3 Sposób podejscia´ do problemu ...... 344 3.17.4 Kategorie systemów HA ...... 345 3.17.5 Komercyjne oprogramowanie HA ...... 347 3.17.6 Rozwiazania˛ Open Source dla systemów HA ...... 348 SPIS TRESCI´ 12

3.17.6.1 Podsystemy dysków ...... 348 3.17.6.2 Failover za pomoca˛ heartbeat ...... 349 3.17.6.3 Farmy serwerów ...... 350 3.17.6.4 Application Clustering ...... 351 3.17.6.5 Compute Cluster ...... 351

4 Ocena wydajnosci´ ekonomicznej 352 4.1 Wprowadzenie ...... 352 4.2 Metodologia ...... 354 4.2.1 Analiza kosztów ...... 354 4.2.2 Analiza korzysci´ ...... 355 4.2.3 IT-WiBe 21 ...... 355 4.2.4 Koszty migracji ...... 356 4.2.5 TCO ...... 357 4.2.6 Porównywalnos´c´ ...... 357 4.2.7 Instalacja od podstaw a migracja ...... 359 4.2.8 Obliczanie pełnych kosztów ...... 359 4.3 Wymiar pienie˛zn˙ y (operacyjny) ...... 361 4.3.1 Obszary zastosowan´ ...... 361 4.3.2 Kategorie kosztów ...... 362 4.3.3 Własnosci´ uzytych˙ kategorii podmiotów publicznych ...... 363 4.3.3.1 Małe urzedy˛ ...... 363 4.3.3.2 Urzedy˛ sredniej´ wielkosci´ ...... 364 4.3.3.3 Duze˙ urzedy˛ / centra obliczeniowe ...... 364 4.4 Wymiar strategiczny ...... 365 4.4.1 Spojrzenie makroekonomiczne ...... 365 4.4.2 Spojrzenie mikroekonomiczne ...... 366 4.5 Wyniki oceny wydajnosci´ ekonomicznej ...... 366 4.6 Zalecenia migracyjne oparte na ocenie wydajnosci´ ekonomicznej ...... 368 4.6.1 Migracja pełna ...... 370 4.6.2 Migracja kontynuacyjna ...... 371 4.6.3 Migracja cze˛scio´ wa ...... 372 4.6.3.1 Migracja punktowa ...... 372 4.6.3.2 Migracja cze˛scio´ wa po stronie serwera ...... 373 4.7 Wnioski ...... 374 SPIS TRESCI´ 13

4.8 Nakłady według rózn˙ ych scenariuszy migracji ...... 375 4.8.1 Ogólne załozenia˙ dotyczace˛ nakładów zwiazan˛ ych z migracja˛ ...... 375 4.8.2 Nakłady na migracje˛ z Windows NT do Windows 2000 ...... 377 4.8.3 Nakłady na migracje˛ z Windows NT do Linuksa ...... 381 4.8.4 Nakłady na migracje˛ z Exchange 5.5 do Exchange 2000 ...... 385 4.8.5 Nakłady na migracje˛ z Exchange 5.5 do Samsung Contact ...... 386 4.8.6 Zalecenia odnosnie´ sposobu oceny produktów / grup produktów . . . . . 388 4.8.6.1 Generalne załozenia˙ ...... 388 4.8.6.2 Przykłady według struktury WiBe21 ...... 389 4.8.6.3 Przykład migracji: Messaging / Groupware – duzy˙ urzad˛ . . . 414 4.8.6.4 Przykłady migracji według kategorii kosztów informatyzacji . 415 4.8.6.5 Pełna migracja ...... 416 4.8.6.6 Migracja kontynuacyjna ...... 421 4.8.6.7 Migracja cze˛scio´ wa ...... 426 4.9 Przykładowa ocena koniecznosci´ oraz jakosci´ i strategii migracji ...... 430 4.9.1 Kryteria koniecznosci´ ...... 430 4.9.2 Kryteria jakoscio´ wo - strategiczne ...... 430 4.9.3 Analiza korzysci´ ...... 431

5 Zalecenia migracyjne 440 5.1 Ogólne wyjasnienia´ ...... 440 5.1.1 Droga do podjecia˛ decyzji ...... 440 5.1.2 Ogólne zalecenia ...... 442 5.2 Całkowita „zastepuj˛ aca˛ migracja” ...... 444 5.2.1 Model architektury ...... 445 5.2.1.1 Stacje robocze ...... 448 5.2.1.2 Serwer WWW ...... 449 5.2.1.3 Składowanie plików ...... 449 5.2.1.4 Drukowanie ...... 449 5.2.1.5 Usługi sieciowe ...... 449 5.2.2 Srednie´ i duze˙ urzedy˛ ...... 450 5.2.2.1 Systemy zarzadzania˛ bazami danych ...... 451 5.2.2.2 Groupware ...... 452 5.2.2.3 Usługi katalogowe ...... 452 5.2.2.4 Zarzadzanie˛ systemem ...... 453 SPIS TRESCI´ 14

5.2.3 Specjalizowane urzedy˛ swiadcz´ ace˛ usługi informatyczne ...... 453 5.2.3.1 System zarzadzania˛ bazami danych ...... 454 5.2.3.2 Serwery aplikacji ...... 455 5.2.3.3 Zarzadzanie˛ systemem ...... 455 5.2.4 Małe urzedy˛ ...... 455 5.2.4.1 Systemy zarzadzania˛ bazami danych ...... 456 5.2.4.2 Groupware ...... 457 5.2.4.3 Usługa katalogowa ...... 457 5.2.4.4 Zarzadzanie˛ systemem ...... 457 5.3 Całkowita „kontynuacyjna migracja” ...... 458 5.3.1 Minimalizacja stopnia integracji, zachowanie stopni dowolnosci´ . . . . . 460 5.3.2 Inne scie´ zki˙ migracji ...... 463 5.4 Migracja cze˛scio´ wa ...... 463 5.4.1 Migracja punktowa ...... 463 5.4.2 Cze˛scio´ wa migracja po stronie serwera ...... 465 5.5 Drogi migracji ...... 467 5.5.1 Szybka migracja ...... 467 5.5.2 Łagodna migracja ...... 469 5.5.3 Krytyczne wyznaczniki sukcesu ...... 471 5.5.3.1 Sformułowanie jednoznacznych celów ...... 474 5.5.3.2 Właczenie˛ i ustalenie szczebli kierowniczych i decyzyjnych . . 474 5.5.3.3 Uzyskanie wysokiego stopnia akceptacji srodo´ wiska docelowego wsród´ uzytko˙ wników ...... 476 5.5.3.4 Szkolenia dla uzytko˙ wników i administratorów ...... 477 5.5.3.5 Działania organizacyjne przygotowujace˛ migracje˛ ...... 477 5.5.3.6 Właczenie˛ wybranych pracowników ...... 480 5.5.3.7 Okreslenie´ punktu wyjscia´ ...... 480 5.5.3.8 Spełnienie wymagan´ funkcjonalnych ...... 481 5.5.3.9 Korzystanie z wartosci´ doswiadczaln´ ych ...... 482 5.5.3.10 Planowanie projektu, czasu i zasobów ...... 482 5.5.3.11 Kontrola projektu i kierowanie projektem ...... 483 5.5.3.12 Dokumentowanie i zapewnienie jakosci´ projektu ...... 483 5.5.3.13 Opieka na etapie pracy ...... 485 5.6 Eksperci współpracujac˛ y nad poradnikiem ...... 485 SPIS TRESCI´ 15

5.7 Spis skrótów ...... 488 5.8 Słownik poje˛c´ ...... 501 5.9 Załaczniki˛ ...... 515 5.9.1 Załaczniki˛ dla WiBe ...... 515 5.9.2 Przeglad˛ zalecanych katalogów z kryteriami ...... 515 5.9.3 Główny katalog z kryteriami IT-WiBe21 dla scenariuszy migracji . . . . 516 5.9.3.1 Koszty rozwoju / wdrozenia˙ oraz korzysci´ z rozwoju ...... 517 5.9.3.2 Koszty pracy i korzysci´ z pracy ...... 518 5.9.3.3 Kryterium koniecznosci´ ...... 519 5.9.3.4 Kryteria jakoscio´ wo - strategiczne ...... 520 5.9.3.5 Wskazówki i objasnienia´ ...... 521 5.9.4 Specjalny katalog z kryteriami IT-WiBe21 dla obiektów migracji . . . . . 521 5.9.5 Objasnienie´ kryteriów uzupełniajac˛ ych ...... 525 5.9.5.1 Koszty wdrozenia˙ / korzysci´ z wdrozenia˙ (1.1) ...... 525 5.9.5.2 Powszechnosć´ / dostepno˛ sć´ wykształcenia (4.4.3) ...... 526 5.9.5.3 Powszechnosć´ / dostepno˛ sć´ oprogramowania (4.6) ...... 526 5.9.5.4 Bezpieczenstwo´ informatyczne (4.7) ...... 528 Rozdział 1

Wprowadzenie

„Produkt zastepuje˛ inny produkt wtedy, gdy okazuje sie,˛ ze˙ zacheta˛ do jego uzywa-˙ nia jest silniejsza niz˙ koszty wynikajace˛ z zamiany produktów i gdy przezwycie˛zon˙ y zostanie opór wzgledem˛ zmian. Produkt zastepczy˛ jest atrakcyjny dla odbiorcy wów- czas, gdy oferuje on wyzsz˙ a˛ wartos´c´ od dotychczas uzywane˙ go produktu i nie jest od niego drozszy˙ . “ M.E. Porter

1.1 Geneza poradnika

Trudno znalezć´ lepsze okreslenie´ opisujace˛ istote˛ intensywnej publicznej dyskusji, która toczy sie˛ od pewnego czasu w zwiazku˛ z wykorzystaniem oprogramowania Open Source od tej prostej sentencji wypowiedzianej przez profesora Harvard Business School, a opisujacej˛ podstawy wolnego rynku i konkurencji. Z punktu widzenia konkurencyjnosci´ okret˛ flagowy Open Source jakim jest GNU/Linux juz˙ dawno uzyskał uprzywilejowana˛ pozycje˛ „produktu zastepcze˛ go”. Inne produkty, takie jak MySQL, PostgreSQL czy OpenOffice.org pewnie poda˛zaj˙ a˛ jego sla-´ dami. (Wszystkich, którym brakuje w tym miejscu serwera Apache, pragniemy poinformowac,´ ze˙ zdaniem autorów produkt ten nalezy˙ traktowac´ jak oryginał, a nie jak produkt zastepczy˛ . Jest on wrecz˛ klasykiem OSS). Wolny system operacyjny GNU/Linux jest szczególnym oprogramowaniem, które jako jedno z nielicznych odnotowuje dzisiaj stały wzrost zainteresowania. Obecnie juz˙ ponad 40 procent niemieckich przedsiebiorstw˛ i organizacji wykorzystuje go w procesach produkcyjnych, przy czym jest to tendencja rosnaca.˛ Z uwagi na tak intensywny rozwój oprogramowania Open Source nalezałoby˙ sie˛ spodziewac,´ ze˙ wytłumaczenie tego zjawiska nie bedzie˛ trudne.

16 ROZDZIAŁ 1. WPROWADZENIE 17

Jednak okazuje sie,˛ ze˙ załozenie˙ to nie jest prawdziwe. Wrecz˛ przeciwnie. W branzy˙ informatycznej mało który temat prowadzi do tak kontrowersyjnych dyskusji o zaletach i wadach, jak wykorzystywanie oprogramowania Open Source. Nalezy˙ przy tym zrozumiec,´ ze˙ roczne obroty ze sprzedazy˙ samego systemu operacyjnego Windows wynosza˛ ponad 10 mld. USD, a zatem na toczac˛ a˛ sie˛ dyskusje˛ maja˛ takze˙ wpływ wazne˙ interesy ekonomiczne. Obok wyjatko˛ wosci´ modelu licencji i czesto˛ pojawiajac˛ ych sie˛ pytan´ dotyczac˛ ych jego wpływu na zmiany w branzy˙ informatycznej, dyskutowane sa˛ w jednakowym stopniu własciwo´ sci´ techniczne konkurujac˛ ych ze soba˛produktów oraz ich parametry ekonomiczne. W sumie, siła˛rzeczy, prowadzi to do uzyskania wielowymiarowej, kompleksowej i dajacej˛ sie˛ zinterpretowac´ oceny. Dodatkowe znaczenie ma fakt, ze˙ w konkurencji - Open Source kontra Microsoft - nie chodzi o pojedyncze programy, lecz o niemalze˙ kompletna˛ platforme˛ dajac˛ a˛ duzy˙ wybór oprogramowania. W tej bardzo skomplikowanej sytuacji, na która˛ maja˛ wpływ wielostronne interesy, decydujaca˛ rola przypada obiektywnej i całoscio´ wej analizie. Odpowiednia ocena powinna uwzglednia˛ c´ nie tylko własciwo´ sci´ techniczne oprogramowania, lecz musi sie˛ ona równiez˙ opierac´ o konkretny punkt wyjscia´ dla ewentualnego wdrozenia,˙ w szczególnosci´ o specyﬁczne ﬁnansowe, strukturalno - organizacyjne i polityczne warunki ramowe działalnosci´ administracji publicznej w Niemczech.

1.2 O poradniku

Juz˙ sam tytuł poradnika wskazuje na to, ze˙ zasadnicze decyzje zwiazane˛ z wprowadzaniem oprogramowania Open Source wpisuja˛ sie˛ w „naturalny” cykl zycia˙ komercyjnego oprogramowania Microsoft. Dobrym tego przykładem jest wycofanie wsparcia technicznego dla wcia˛z˙ szeroko rozpowszechnionego systemu operacyjnego Windows NT, którego nastepca˛ wymaga z zasady innego sposobu zarzadzania˛ domenami. Aby odrózni˙ c´ zastepo˛ wanie tego oprogramowania produktami OSS od przejscia´ na produkty Microsoft nastepnej˛ generacji, wprowadzilismy´ pojecie˛ migracji zastepuj˛ acej˛ i migracji kontynuacyjnej. W niniejszym poradniku nie skoncentrowalismy´ sie˛ tylko na sposobach zastapienia˛ juz˙ stosowanego oprogramowania, lecz takze˙ na wskazaniu rozwiaza˛ n´ optymalnie odpowiadajac˛ ych warunkom ekonomicznym. Poradnik migracyjny skierowany jest przede wszystkim do decydentów majac˛ ych wpływ na planowanie i wybór kierunku rozwoju w sektorze informatycznym. Pierwsza cze˛s´c´ (rozdział 2) zajmuje sie˛ przedstawieniem punktu wyjscia´ dla oprogramowa- ROZDZIAŁ 1. WPROWADZENIE 18

nia. Rozstrzyga on o sposobie przeprowadzenia migracji i stanowi przeglad˛ podstawowej architektury oprogramowania Microsoft, jak równiez˙ alternatywnej, opartej na otwartych standardach platformy Open Source. Tak zwana mapa systemu wskazuje przy tym mozliwo˙ sci´ zastapienia˛ produktów pełniac˛ ych okreslone´ funkcje, innymi produktami i rozwiazaniami˛ oraz pokazuje zwiazki˛ pomiedzy˛ poszczególnymi warstwami oprogramowania. Druga cze˛sć´ (rozdziały 3 i 4) jest próba˛ odpowiedzi na pytanie o mozliwo˙ sć´ potencjalnej migracji albo zastosowania całkiem nowych systemów IT oraz infrastruktury informatycznej. Poszczególne zakresy zastosowan´ oprogramowania opisane zostały zarówno z technicznego, jak i z ekonomicznego punktu widzenia. Podczas, gdy pierwszy koncentruje sie˛ na identyfikacji i ocenie rozwiaza˛ n´ alternatywnych dla produktów Microsoft, w rozdziale opisujac˛ ym ocene˛ ekonomiczna˛ chodzi o udzielenie odpowiedzi na pytanie, jaka jest najbardziej oszczedna˛ droga prowadzaca˛ do zamiany oprogramowania. W cze˛sci´ trzeciej (rozdział 5) umiescili´ smy´ zalecenia migracyjne, które odnosza˛ sie˛ do róz-˙ nych struktur administracji. Zalecenia te sa˛ wynikiem otrzymanym na podstawie oceny technicznej i ekonomicznej. Zawieraja˛ one konkretne propozycje dla małych, srednich,´ duzych˙ i specjalizowanych urzedów˛ . Dodatkowo rozwazamy˙ tu zalety i wady rózn˙ ych dróg migracji. Na koncu´ trzeciej cze˛sci´ przedstawione zostały krytyczne wyznaczniki sukcesu migracji. Pomimo, ze˙ zastepo˛ wanie jednego oprogramowania innym nie jest w zasadzie niczym nowym, to jednak rózne˙ doswiadczenia´ wyniesione z projektów wdrozon˙ ych w administracji publicznej wskazuja˛ na koniecznosć´ bardzo starannego zaplanowania i wykonania migracji, gdyz˙ ostateczny sukces takiego przedsie˛wziecia˛ sci´ sle´ wia˛ze˙ sie˛ z przygotowaniem pracowników biorac˛ ych w niej udział. Podczas wielomiesiecznej˛ pracy nad poradnikiem migracyjnym wielokrotnie okazywało sie,˛ ze˙ zagadnienia tu opisane zmieniaja˛sie˛ bardzo szybko i dynamicznie. W czasie prac nad projektem ilosć´ oprogramowania dostepne˛ go pod Linuksem, zarówno tego publikowanego na licencji GPL, jak i komercyjnego, znacznie wzrosła. Podobny wzrost miał miejsce jesli´ chodzi o ilosć´ producentów, którzy zwiazali˛ planowanie swoich strategicznych celów z Linuksem i zaoferowali konkretne produkty lub przynajmniej przystosowali wersje swojego oprogramowania dla otwartego systemu operacyjnego. Oprócz takich duzych˙ firm programistycznych jak SAP, Oracle, Sun czy IBM, z dnia na dzien´ rosnie´ takze˙ oferta małych i srednich´ przedsiebiorstw˛ specjalizujac˛ ych sie˛ w konkretnych aplikacjach i systemach. Taki cieszac˛ y zwolenników Otwartego Oprogramo- wania rozwój, przyczynia sie˛ z jednej strony do osiagania˛ dojrzałosci´ przez oferte˛ OSS, a z drugiej strony powoduje coraz wieksze˛ trudnosci´ podczas wykonywania przegladu˛ aktualnego stanu oprogramowania. ROZDZIAŁ 1. WPROWADZENIE 19

Oczywiscie´ zadaniem samego czytelnika bedzie˛ dostrzezenie˙ własnych korzysci´ w oparciu o wymienione w poradniku zachety˛ . Autorzy niniejszego opracowania maja˛ nadzieje,˛ ze˙ bedzie˛ ono pomocne i zapewni wsparcie kazdemu,˙ kto rozwaza˙ skutki techniczne i ekonomiczne migracji.

1.3 Jak korzystac´ z poradnika?

Czytelnikom poradnika pragniemy wskazac,´ w jaki sposób nalezy˙ korzystac´ z wewnetrznej˛ struktury dokumentu. Mamy nadzieje,˛ ze˙ dzieki˛ niniejszym poradom poruszanie sie˛ po dosć´ obszernym poradniku stanie sie˛ łatwiejsze. Pamietajmy˛ zatem o tym, ze˙ zagadnienia poruszone w poradniku skierowane sa˛ do dwóch grup odbiorców. Pierwsza˛ z nich stanowia˛ decydenci majac˛ y wpływ na planowanie i wybór kierunku rozwoju w sektorze informatycznym, a druga˛osoby odpowiedzialne za działy informatyczne w urzedach,˛ dla których wazna˙ jest szczegółowa techniczna analiza migracji. Zapoznanie sie˛ z ponizszymi˙ wskazówkami zalecamy wszystkim osobom nalez˙ac˛ ym do w/w grup. Bezposrednim´ nawiazaniem˛ do niniejszego rozdziału jest nastepn˛ y rozdział, który skierowany jest specjalnie do decydentów. „Wskazówki dla decydentów” sa˛ zbiorem istotnych spostrzeze˙ n´ oraz zwiezłym˛ opisem doswiadcze´ n´ zebranych w czasie zrealizowanych juz˙ projektów migracyjnych. Czytajac˛ poradnik nie nalezy˙ opuszczac´ czterech pierwszych podrozdziałów rozdziału drugiego. Mieszcza˛ sie˛ w nich bowiem wazne˙ definicje, których poznanie ma istotne znaczenie dla zrozumienia dalszych cze˛sci´ poradnika. W kolejnych rozdziałach opisane zostały składniki systemu lez˙ace˛ u podstaw migracji zastepuj˛ acej˛ i kontynuacyjnej. Jako uzupełnienie dla decydentów, którzy chcieliby zapoznac´ sie˛ z techniczna˛ocena˛ procesu migracji odnoszac˛ a˛sie˛ kazdorazo˙ wo do poszczególnych jego składników, na poczatku˛ rozdziału 3 streszczone zostały cele oraz dokonano oceny uzyskanych wyników. Własciwe´ zestawienie i ocena wyników ekonomicznych miesci´ sie˛ w rozdziale 4.7, natomiast rozdział 5 zawiera odpowiednie ekonomiczne zalecenia dotyczace˛ skutków rózn˙ ych metod migracji. Ocena wydajnosci´ ekonomicznej (rozdział 4) naswietla´ finansowe aspekty projektów migracyjnych i ma szczególne znaczenie dla osób podejmujac˛ ych strategiczne decyzje gospodarcze. W oparciu o rózne˙ scenariusze ocenilismy´ pienie˛zne˙ aspekty mozliwych˙ metod migracji. W celu dogłebne˛ go poznania zalecen´ wazn˙ ych dla urzedów˛ , zachecamy˛ do przeczytania roz- ROZDZIAŁ 1. WPROWADZENIE 20

działu „Zalecenia migracyjne”. Mieszcza˛ sie˛ tu rózne˙ scenariusze migracji1 oraz wskazówki dotyczace˛ zastosowania odpowiedniej kombinacji oprogramowania dla urzedów˛ i instytucji o róznej˙ strukturze2. Opieraja˛ sie˛ one na wynikach dokonanych wczesniej´ ocen technicznych i ekonomicznych. Szczególnie interesujace˛ moga˛ okazac´ sie˛ rozwazania˙ z rozdziału „Krytyczne wyznaczniki sukcesu”, który wskazuje czytelnikom warunki, jakie nalezy˙ spełnic,´ by wdrozenie˙ odpowiedniego projektu zakonczyło´ sie˛ sukcesem. Po zapoznaniu sie˛ z powyzszym,˙ decydenci uzyskaja˛ istotne dla siebie informacje. Jednak zachecamy˛ kazd˙ a˛ z tych osób do przeczytania takze˙ pozostałych rozdziałów niniejszego poradnika. Dla pracowników działów IT interesujace˛ powinny okazac´ sie˛ wszystkie zebrane tu informacje. Poradnik zbudowany jest w taki sposób, ze˙ zaraz po wprowadzeniu mozna˙ przeczytac´ rozdział 2 „Najwazniejsze˙ zagadnienia” przedstawiajac˛ y ogólne informacje stanowiace˛ kompen- dium wiedzy potrzebnej do zrozumienia dalszych cze˛sci´ poradnika. Oprócz, wymienionych juz˙ powyzej,˙ pierwszych czterech podrozdziałów, znajduja˛ sie˛ kolejne, w których opisane zostały rózne˙ dystrybucje GNU/Linuksa, licencje Open Source oraz przede wszystkim wskazówki odnosnie´ danych zebranych na potrzeby poradnika. Szczegółowa ocena techniczna zamieszczona w rozdziale 3 z pewnosci´ a˛ stanowic´ bedzie,˛ wraz ze znajomosci´ a˛ lokalnych wymagan´ i mozliwo˙ sci´ technicznych, najwazniejsze˙ zródło´ informacji, np. udzielajac˛ ym odpowiedzi na nastepuj˛ ace˛ pytania:

◦ Co jest mozliwe,˙ wzglednie˛ gdzie mozna˙ spodziewac´ sie˛ problemów?

◦ Jak mozna˙ poradzic´ sobie ze znanymi problemami lub ich unikna˛c?´

◦ Z jakich funkcjonalnosci´ mozna˙ nadal korzystac´ po migracji, wzglednie˛ gdzie pojawia˛ sie˛ ograniczenia?

◦ itd.

W poszczególnych rozdziałach składniki systemu bed˛ a,˛ za kazdym˙ razem, oceniane z technicznego punktu widzenia. Opisany zostanie techniczny punkt wyjscia´ i nastepnie˛ rózne˙ aspekty migracji zastepuj˛ acej˛ i kontynuacyjnej. Dla czytelników posiadajac˛ ych odpowiednia˛ wiedze˛ techniczna˛ interesujac˛ y moze˙ okazac´ sie˛ przeglad˛ rózn˙ ych technologii. Kazdy˙ zyska mozliwo˙ s´c´ szczegółowego zapoznania sie˛ z przeznaczeniem opisanych tu, rózn˙ ych rozwiaza˛ n´ i produktów. Dla czytelników, którzy dotychczas nie mieli wieksze˛ go kontaktu z technologiami opartymi na

1pełna migracja zastepuj˛ aca,˛ pełna migracja kontynuacyjna i migracja cze˛scio´ wa 2urzedy˛ małe, srednie,´ duze˙ i specjalizowane ROZDZIAŁ 1. WPROWADZENIE 21

Linuksie, szczególnie wazne˙ bed˛ a˛ rozdziały dotyczace˛ migracji zastepuj˛ acej˛ zawierajace˛ rózno-˙ rodne informacje. W rozdziale 5 znalezć´ mozna˙ konkretne zalecenia powstałe w oparciu o oceny techniczne i ekonomiczne zgromadzone we wczesniejszych´ rozdziałach. Przedstawione zostały tu rózne˙ scenariusze przeznaczone dla rózn˙ ych, ze wzgledu˛ na wielkosć´ i zakres wykonywanych zadan,´ urzedów˛ . Czytelnik ma mozliwo˙ sć´ uzyskania precyzyjnej informacji, odpowiednio do swoich potrzeb i konkretnej sytuacji.

1.4 Wskazówki dla decydentów

1.4.1 Podstawowe zalecenia

Zgodnie z tym, co zostało zasygnalizowane juz˙ w poprzednim rozdziale, w poradniku migracyjnym przedstawione zostana˛ dwie podstawowe drogi migracji:

◦ migracja zastepuj˛ aca˛

oraz

◦ migracja kontynuacyjna.

Zasadniczy wynik mozna˙ w tym miejscu z góry przewidziec;´ ilosć´ scenariuszy, w których dla urzedów˛ korzystniejsza jest migracja zastepuj˛ aca˛ z wykorzystaniem produktów Open Source bardzo wzrosła. Z jednej strony wynika to z oceny ekonomicznej, zgodnie z która˛ produkty OSS generalnie skutecznie obnizaj˙ a˛ koszty, natomiast z drugiej strony, z upływem lat, projek- tom migracyjnym toruje droge˛ duza˙ dojrzałosć,´ rozpowszechnienie i kompatybilnosć´ tego typu produktów. To wszystko powoduje obecnie nizsze˙ koszty wdrozenia,˙ niz˙ miałoby to miejsce w przeszłosci.´ Wyniki oceny wydajnosci´ ekonomicznej potwierdzaja˛w szczególnosci,´ ze˙ do znacznych oszczedno˛ sci´ moze˙ prowadzic´ nie tylko rezygnacja w niektórych przypadkach z opłat licencyjnych, ale przede wszystkim konkurencja w dziedzinie systemów operacyjnych i programów biurowych. Wyniki przedstawione w poradniku odnosza˛sie˛ w pierwszym rzedzie˛ do sytuacji ciagle˛ jeszcze panujacej˛ w wiekszo˛ sci´ urzedów˛ , które wyposazone˙ sa˛ w system operacyjny Windows NT 4 oraz współpracujace˛ z nim oprogramowanie, takie jak, np. MS Exchange 5.5, Internet Informa- tion Server 4 oraz MS SQL Server 7. ROZDZIAŁ 1. WPROWADZENIE 22

1.4.2 Migracja kontynuacyjna i zastepuj˛ aca˛

Konfiguracja ta stanowi punkt wyjscia´ dla migracji kontynuacyjnej w srodo´ wisku produktów Microsoft. W niniejszym rozdziale zajmiemy sie˛ ocena˛ mozliwo˙ sci´ zastapienia˛ w/w produktów przez Windows 2000 i oprogramowanie z serii 2000, jak równiez˙ przez Windows XP i Windows 2003. To, ze˙ skoncentrujemy sie˛ na Windows 2000 nie oznacza, ze˙ wszyscy, którzy dokonali juz˙ przejscia´ na Windows 2000 powinni w tym momencie odłozy˙ c´ poradnik na półke.˛ Takze˙ urze-˛ dom stosujac˛ ym juz˙ te˛ technologie˛ przyda sie˛ zarówno znajomosć´ zawartej tu oceny technicznej, jak i wazn˙ ych zalecen.´ Ich przestrzeganie, a takze˙ podjecie˛ zwiazan˛ ych z nimi odpowiednich kro- ków prowadzac˛ ych do redukcji wewnetrzne˛ go stopnia uzaleznienia,˙ ma na celu pozostawienie otwartej drogi dla przyszłych migracji. Te ostatnie zalecenia skierowane sa˛przede wszystkim do urzedów˛ , które własnie´ przeprowadziły migracje˛ na Windows 2000 oraz takich, które chwilowo nie chca˛ odstapi˛ c´ od korzystania z produktów Microsoft lub (z rózn˙ ych powodów musza˛ wcia˛z˙ z nich korzystac).´ Oglad˛ migracji zastepuj˛ acej˛ pokazuje, ze˙ róznorodno˙ sć´ oraz duza˙ ilosć´ rozwiaza˛ n´ sprawia, iz˙ sensowne staje sie˛ rozróznienie˙ omawianych wyników i zalecen.´ Szczególnie istotnymi kryteriami wyboru własciwe´ go rozwiazania˛ sa˛ zakres usług informatycznych, intensywnosć´ ich uzy-˙ wania oraz „Stopien´ wyspecjalizowania” w przypadku urzedów˛ , które same swiadcz´ a˛ usługi informatyczne na rzecz innych urzedów˛ . Oprócz wyboru odpowiednich produktów i własciwych´ konfiguracji, konieczne jest znalezienie prawidłowych scenariuszy migracji. W tym miejscu w poradniku wyrózniono˙ migracje˛ punktowa,˛ szeroka˛ i pełna˛ - w zalezno˙ sci´ od informatycznego „stopnia pokrycia obszaru”. Punktowo, przez zastapienie˛ pojedynczych składników uzywane˙ go systemu, takich jak, np. MS Office Suite albo MS Exchange. Cze˛scio´ wo, przez zastapienie˛ serwera i pozostawienie lub wprowadzenie stacji roboczych z Windows. Całkowicie, przez zasta-˛ pienie wszystkich aplikacji systemu Windows przez oprogramowanie linuksowe. Zalecenia poradnika wskazuja,˛ które z dzisiejszych rozwiaza˛ n´ nalezy˙ preferowac,´ by spełnic´ okreslone´ wymagania urzedu˛ i dostosowac´ system informatyczny do struktury urzedu.˛

1.4.3 Rózne˙ drogi migracji

Wazn˙ a˛ role˛ odgrywa wybór drogi migracji, czyli wybór pomiedzy˛ migracja˛ szybka˛ i łagodna.˛ Jest przy tym rzecza˛ decydujac˛ a,˛ by istniała techniczna mozliwo˙ s´c´ w wysokim stopniu bezproblemowego komponowania i uzywania˙ mieszanych (heterogenicznych) systemów. Dzieki˛ temu urzedy˛ otrzymaja˛ szanse˛ zastepo˛ wania w ramach migracji, pojedynczych składników swojego systemu informatycznego przez oprogramowanie Open Source albo aplikacje komercyjne dzia- ROZDZIAŁ 1. WPROWADZENIE 23

łajace˛ na platformie GNU/Linux. Optymalna˛droge˛ migracji wyznacza wiele czynników. Szybka migracja oznacza (jak mozna˙ wnioskowac´ z samej nazwy) dokonanie pełnej migracji zastepu-˛ jacej˛ za jednym razem. Z punktu widzenia zasad ekonomii ma to sens przede wszystkim tam, gdzie infrastruktura i systemy informatyczne bad˛ z´ to juz˙ zwiazane˛ sa˛ w duzym˙ stopniu z oprogramowaniem uniksowym bad˛ z´ w przypadku urzedów˛ wymagajac˛ ych wprowadzenia wiekszych˛ zmian infrastruktury informatycznej oraz w urzedach˛ z tak zwanym zastojem inwestycyjnym. Z reguły najwiekszy˛ sens ma realizacja łagodnych migracji. Sa˛ one przeprowadzane w jednym do trzech kroków i składaja˛ sie˛ z migracji cze˛scio´ wych i/lub punktowych. Łagodne migracje daja˛ mozliwo˙ s´c´ nadrobienia w miejscu pracy zacofania z zakresu know-how w odniesieniu do nowych technologii oraz stopniowego wdrozenia˙ administratorów i uzytko˙ wników do nowych technologii i oprogramowania. Niezaleznie˙ od wybranej drogi migracji, jesli´ chcemy osiagn˛ a˛c´ konco´ wy sukces, musimy przestrzegac´ tak zwanych krytycznych wyznaczników sukcesu. Zostały one wyszczególnione w zaleceniach. Chodzi m.in. o niezbedne˛ przygotowania, działania słuz˙ace˛ własciwemu´ przekazy- waniu informacji i stworzenie atmosfery akceptacji w kre˛gu uzytko˙ wników, niezbedne˛ szkolenia oraz o zadania na poziomie zarzadzania˛ projektem i ogólna˛ organizacje.˛ Nawet w sytuacji, kiedy niemal dla kazde˙ go zastosowania i wymogu istnieja˛ adekwatne rozwiazania,˛ sama zamiana czegos´ znanego na cos´ nowego zwiazana˛ jest, w wiekszo˛ sci´ przypad- ków, z trudnosciami´ i czesto˛ subiektywnymi „bólami”. Zasadniczo mozna˙ jednak powiedziec,´ ze˙ obydwie drogi migracji niosa˛ ze soba˛wiele nowego zarówno dla projektantów, jak i dla admini- stratorów. To samo dotyczy uzytko˙ wników, przy czym dotyczace˛ ich zmiany nie sa˛ z reguły az˙ tak widoczne.

1.4.4 Porównanie alternatywnych rozwiaza˛ n´

Wiadomo, ze˙ nie wszystkie funkcjonalnosci´ dostarczane przez Windows i inne produkty firmy Microsoft znajduja˛ swoje lustrzane odbicie w oprogramowaniu Open Source bad˛ z´ oprogramowaniu komercyjnym działajac˛ ym w systemie operacyjnym GNU/Linux. Jednakze,˙ jak wykazały doswiadczenia´ uzytko˙ wników obu platform potwierdzone wynikami uzyskanymi podczas przeprowadzonych juz˙ migracji, funkcjonalnosć´ w/w oprogramowana jest porównywalna. Poniewaz˙ w pojedynczych przypadkach moze˙ chodzic´ o specjalne zastosowania i konkretne własciwo´ sci,´ zaleca sie˛ by kazdy˙ urzad˛ dokonał samodzielnej oceny ewentualnych krytycznych odstepstw˛ majac˛ ych wpływ na oczekiwana˛ funkcjonalnosć.´ Odstepstw˛ takich spodziewac´ sie˛ mozna˙ przede wszystkim w obszarze aplikacji biurowych, w szczególnosci´ jesli´ chodzi o integracje˛ tych aplikacji z oprogramowaniem specjalistycznym, jak równiez˙ kompatybilnosci´ podczas ROZDZIAŁ 1. WPROWADZENIE 24

wymiany dokumentów pomiedzy˛ pakietami Microsoft Office i OpenOffice.org lub StarOffice. Problemy kompatybilnosci´ prowadza˛do tego, ze˙ wspólna edycja dokumentów przy wykorzystaniu OpenOffice.org lub StarOffice i MS Office mozliwa˙ jest w bardzo ograniczonym zakresie. W zasadzie wspólna edycja mozliwa˙ jest tylko na poziomie zawartosci.´ Z ocen technicznych wynika, ze˙ istnieja˛ darmowe bad˛ z´ komercyjne zamienniki dla systemu operacyjnego Windows oraz dla usług sieciowych opartych o ten system. Dotyczy to takze˙ desk- topów. Wspomniane zamienniki pracuja˛ pod kontrola˛ GNU/Linux.

◦ Jesli´ chodzi o usługi sieciowe i obsługe˛ srodo´ wisk mieszanych, wazn˙ a˛ role˛ odgrywaja˛ Samba i OpenLDAP oraz CUPS bed˛ ac˛ y innowacyjna˛ i zarazem skuteczna˛ usługa˛ umozli-˙ wiajac˛ a˛ drukowanie w sieci. CUPS spełnia wszystkie wymagania stawiane nowoczesnym, wydajnym i kompleksowym protokołom wydruku. Ilos´c´ programów do zarzadzania˛ siecia˛ opartych o wolne oprogramowanie systematycznie rosnie´ i jest nieustannie udoskona- lana. Ponadto cze˛s´c´ komercyjnych systemów zarzadzania˛ siecia˛ oferowanych dotychczas do współpracy z Windows, jest dostosowywana przez producentów do pracy w srodo´ wisku GNU/Linux.

◦ Rozwiazaniami˛ mogac˛ ymi zastapi˛ c´ MS Exchange jest przede wszystkim wolne oprogramowanie, wykorzystywane zwłaszcza do zastapienia˛ samych serwerów pocztowych. Ta- kim pełnowartoscio´ wym substytutem dajac˛ ym mozliwo˙ s´c´ dalszego korzystania z klienta poczty Outlook jest obecnie, Samsung Contact - dla srednich´ i duzych˙ sieci, a dla mniejszych sieci moze˙ nim byc´ Exchange4Linux.

◦ Jesli´ chodzi o bazy danych, to mozna˙ wybierac´ sposród´ wielu wolnych produktów, np. SAP DB, MySQL i PostgreSQL. Oprócz tego istnieja˛ komercyjne bazy danych Oracle i DB2, które zapewniły juz˙ sobie bardzo dobra˛ opinie˛ odnosnie´ działania w srodo´ wisku Unix/Linux i dlatego nie bed˛ a˛ przez nas oceniane.

Powyzsz˙ a˛ liste˛ mozna˙ by rozszerzyc´ na niemal wszystkie dziedziny zastosowan´ sieciowych i desktopowych. W poradniku opiszemy tylko niektóre z nich, np. systemy wysokiej niezawodnosci´ oraz Thin Clients. Tam, gdzie pojawia˛ sie˛ wazne˙ róznice˙ albo ograniczenia zwiazane˛ z prezentowanymi rozwiazaniami,˛ zostana˛ one wyjasnione.´

1.4.5 Istotne zagadnienia przyszłoscio´ we

Aby zamieszczona tu ocena techniczna nie była pozbawiona perspektywicznego spojrzenia, przedstawiony punkt wyjscia´ oceniany bedzie˛ za kazdym˙ razem pod katem˛ przyszłoscio´ wego ROZDZIAŁ 1. WPROWADZENIE 25

znaczenia składników pełniac˛ ych wiodac˛ a˛ role˛ w nowym oprogramowaniu ﬁrmy Microsoft. Za- licza sie˛ do niego przede wszystkim .NET Framework wraz z jego istotnymi cze˛sciami´ składo- wymi, tj. Web-Services i XML, a takze˙ SharePoint Portal Server. Podsumowujac˛ mozna˙ sformułowac´ nastepuj˛ ace˛ wnioski:

◦ Zarówno .NET-Framework, jak i alternatywna do niego Java/J2EE oferuja˛zasadniczo dwie funkcjonalnosci,´ tj. umozliwiaj˙ a˛ponowne zastosowanie uzywan˙ ych składników oraz realizuja˛ kompatybilnos´c´ pomiedzy˛ platformami i oprogramowaniem.

◦ Mozliwo˙ s´c´ ponownego wykorzystania uzywan˙ ych składników, uzyskana wskutek wykorzystania ich jednakowego modelu (COM+ w przypadku Microsoft oraz JavaBeans w Ja- vie), okreslana´ jest mianem integracji głebokiej˛ wskutek ich powiazania˛ ze srodo´ wiskiem runtime environment (udostepnianie˛ uniwersalnych funkcji) i/lub powiazania˛ z jezykami˛ programowania. Aplikacje stworzone w oparciu o jeden model składników mozna˙ wykorzystywac´ tylko wewnatrz˛ jednej platformy.

◦ XML, jako format wymiany danych i dokumentów, tworzy podstawe˛ w zastosowaniach opartych na technologii Web-Services. Dzieki˛ niezalezno˙ sci´ od konkretnego srodo´ wiska oraz wykorzystywaniu interfejsów dla rózn˙ ych protokołów, mozna˙ ja˛ zastosowac´ do płyt- kiej integracji usług. Usługi oparte na Web-Services moga˛wykraczac´ poza granice wyzna- czane przez platforme,˛ na której sa˛ uruchamiane.

◦ Obecnie nie mozna˙ sformułowac´ generalnego zalecenia dotyczace˛ go wykorzystania ponad platformowego płytkiego modelu integracji. Jest tak ze wzgledu˛ na nierozstrzygniete˛ kwestie bezpieczenstwa´ oferowanego przez aplikacje pracujace˛ w ramach technologii Web- Services. Ocena bezpieczenstwa´ bedzie˛ jednym z głównych punktów podczas dalszych prac nad rozwojem w/w technologii.

◦ Generalne zalecenie dotyczace˛ składników wykorzystywanych do integracji głebokiej˛ , zo- stało sformułowane w zaleceniach standardowych SAGA. W dokumencie tym, ze wzgledu˛ na zachowanie niezalezno˙ sci´ sprzeto˛ wej, wskazuje sie˛ na koniecznos´c´ wykorzystania JSE/J2EE. Odejscie´ od tej zalecanej technologii (np. w kierunku .NET-Framework) dopuszczalne jest tylko w uzasadnionych przypadkach (np. gdy mozliwe˙ jest poczynienie znacznych oszczedno˛ sci).´

◦ Przewiduje sie,˛ ze˙ wykorzystanie XML jako formatu dokumentów, który w zaleceniach SAGA uznany został za „uniwersalny i naczelny standard wymiany danych dla wszystkich ROZDZIAŁ 1. WPROWADZENIE 26

wazn˙ ych systemów informatycznych administrujac˛ ych danymi”, jak równiez˙ wytyczna SAGA odnosnie´ PDF, jako formatu wymiany dokumentów, doprowadzi do znacznego poprawienia (jesli´ nie do całkowitego zlikwidowania problemu) kompatybilnosci´ oprogramowania biurowego pocza˛wszy od MS Ofﬁce 2003.

1.4.6 Korzysci´ ekonomiczne

Główna ocena korzysci´ ekonomicznych przedstawiona w poradniku koncentruje sie˛ wokół dwóch istotnych zagadnien:´

◦ przedstawienia podstawowych wypowiedzi dotyczac˛ ych opłacalnosci´ stosowania produk- tów Open Source oraz

◦ okreslenia´ metod i srodków´ pozwalajac˛ ych na dokonanie oceny wydajnosci´ ekonomicznej pod katem˛ specyﬁcznych potrzeb urzedów˛ oraz oszacowania kosztów migracji zwiazan˛ ych z konkretnymi projektami.

Analiza kosztów migracji oraz własciwe,´ dla przedłozon˙ ych projektów migracji, dokumenty WiBe 21,3 wskazuja˛ na dwie metody obliczania rentownosci´ procesu wymiany oprogramowania. Aby umozliwi˙ c´ łatwiejsze ich zrozumienie, poradnik zawiera przykładowe wyliczenia dla rózn˙ ych scenariuszy wraz z komentarzami. W celu podkreslenia´ szczególnych róznic˙ wynikajac˛ ych z rózn˙ ych dróg migracji, w przykładowych wyliczeniach wykonanych według kryteriów WiBe21, zawarte zostały propozycje wybiórczych kryteriów oceny oraz zalecenia dotyczace˛ analizy przydatnosci.´ Poradnik daje tym samym mozliwo˙ s´c´ przypisania wymiaru ekonomicznego kazdemu˙ projektowi. Podaje on liczby pomocne przy okreslaniu´ rentownosci´ oraz pilnosci´ wdrozenia˙ projektu bad˛ z´ tez˙ wskazuje na jego strategiczne znaczenie. Takze˙ analiza kosztów migracji oferuje szybka˛ i pragmatyczna˛ pomoc dla przygotowania oceny wydajnosci´ ekonomicznej. Na zakonczenie´ nalezy˙ wyraznie´ podkresli´ c,´ ze˙ zwłaszcza wyniki oceny ekonomicznej po- kazały, iz˙ głównym czynnikiem wpływajac˛ ym na podjecie˛ decyzji za lub przeciw migracji zaste-˛ pujacej˛ bedzie˛ stopien´ integracji z systemem Windows i pakietem MS Ofﬁce. Decydujace˛ argumenty ekonomiczne oraz mozliwo˙ sci´ zastosowania migracji zastepuj˛ acej˛ zalez˙a˛ sci´ sle´ od ilosci´

3IT-WiBe 21 – zalecenia odnosnie´ przygotowywania oceny ekonomicznej w administracji publicznej, ze szcze- gólnym uwzglednieniem˛ nakładów na technologie informatyczne, wersja 3.0 - 2001, dokumenty KBSt, tom 52, maj 2001 r. ROZDZIAŁ 1. WPROWADZENIE 27

uzywan˙ ych aplikacji biurowych, zakresu i stopnia skomplikowania stosowanych makr, skryp- tów oraz szablonów, jak równiez˙ od ilosci´ i dostepno˛ sci´ kodu zródło´ wego wykorzystywanych aplikacji specjalistycznych współpracujac˛ ych wyłacznie˛ z Windows. Własnie´ takiej sytuacji poswi´ econe˛ sa˛ zalecenia dotyczace˛ stopniowego zmniejszania uzaleznienia˙ od jednego systemu operacyjnego i podnoszenia kompatybilnosci´ wykorzystywanego oprogramowania. Rozdział 2

Najwazniejsze˙ zagadnienia

2.1 Wazne˙ deﬁnicje

Na co dzien´ uzywan˙ ych jest wiele poje˛c,´ które mimo pozornego podobienstwa,´ wcale nie sa˛toz-˙ same. W niniejszym poradniku sa˛ to miedzy˛ innymi: Oprogramowanie Open Source, Otwarte Oprogramowanie lub Free Software, oprogramowanie własnoscio´ we, oprogramowanie komercyjne i inne. Ponadto w poradniku wprowadzono własne pojecia.˛ Aby lektura poradnika nie prowadziła do powstawania nieporozumien,´ niektóre z w/w poje˛c´ zostały wytłumaczone ponizej.˙

2.1.1 Open Source, Free Software

Pojecia˛ „Open Source Software” i „Free Software” nazywane takze˙ „Otwartym Oprogramowa- niem” stosowane sa˛ w poradniku jako synonimy. Dla uproszczenia oznaczono je skrótem OSS. OSS pozwala kazdemu˙ czytac´ i dowolnie modyfikowac´ kod zródło´ wy. Otwartosć´ ta daje uzytko˙ wnikom mozliwo˙ sć´ samodzielnego uczenia z czytanego kodu, wzglednie˛ dostosowania go do własnych potrzeb. Oprogramowanie udostepniane˛ jest nieodpłatnie dzieki˛ czemu osoby, które z niego korzystaja,˛ nie musza˛ ponosic´ kosztów zwiazan˛ ych z zakupem licencji. Programy OSS wolno kopiowac´ w zmodyfikowanej formie oraz rozpowszechniac.´ Wolnosć´ oprogramowania reguluja˛ i gwarantuja˛ odpowiednie licencje. Najwazniejsze˙ z nich zostały opisane w rozdziale 2.4. OSS nie wolno mylic´ z oprogramowaniem, które wprawdzie udostepniane˛ jest za darmo, ale nie moze˙ byc´ przez uzytko˙ wnika modyfikowane ani dostosowywane do własnych potrzeb, wzglednie˛ takim oprogramowaniem, którego licencja zakazuje stosowania go do celów komer-

28 ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 29

cyjnych.

2.1.2 Oprogramowanie własnoscio´ we

Oprogramowanie własnoscio´ we nie jest oprogramowaniem OSS. Nalezy˙ ono do osoby lub organizacji. Z reguły chodzi w tym przypadku o producenta takiego oprogramowania (prawo własnosci).´ Sposób korzystania z oprogramowania podlega zapisom licencji, które ustalane sa˛ przez własciciela´ oprogramowania. Najcze˛sciej´ zakazuja˛one nieograniczonego powielania, rozpowszechniania i modyﬁkowania. W pewnych przypadkach, gdy spełnione zostana˛ odpowiednie wymagania zapisane w licencji, oprogramowanie takie jest takze˙ udostepniane˛ za darmo.

2.1.3 Komercyjne oprogramowanie linuksowe

Komercyjne oprogramowanie linuksowe (Commercial Linux Software) obejmuje grupe˛ oprogramowania własnoscio´ wego, które moze˙ byc´ stosowane w systemie operacyjnym GNU/Linux. Z reguły odznacza sie˛ ono wykorzystywaniem obowiazuj˛ ac˛ ych standardów i wynikajac˛ a˛ z nich kompatybilnosci´ a,˛ jak równiez˙ dobrze zdeﬁniowanymi interfejsami.

2.1.4 Migracja zastepuj˛ aca˛

W niniejszym poradniku wyróznione˙ zostały dwa główne modele migracji: zastepuj˛ aca˛ i kontynuacyjna. Na czym polegaja˛ róznice˙ pomiedzy˛ nimi? Mianem migracji zastepuj˛ acej˛ okresla´ sie˛ zastapienie˛ aplikacji pracujac˛ ych pod Windows oraz usług swiadczon´ ych przez ten system operacyjny wraz ze wszystkimi bazujac˛ ymi na nim srodo´ wiskami przez oprogramowanie OSS lub komercyjne oprogramowanie linuksowe. Ponizej˙ kilka typowych przykładów:

◦ zastapienie˛ Windows NT przez GNU/Linux

◦ zastapienie˛ MS Ofﬁce przez OpenOfﬁce.org

◦ zastapienie˛ MS SQL Server przez Oracle ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 30

2.1.5 Migracja kontynuacyjna

Pojecie˛ migracji kontynuacyjnej oznacza dalsze wykorzystywanie oprogramowania Microsoft majace˛ na celu osiagni˛ ecie˛ odpowiedniego stopnia kompatybilnosci´ przed zmiana˛ oprogramowania na OSS. W ramach tego typu migracji miesci´ sie,˛ na przykład, zastapienie˛ Windows NT 4 przez Windows 2000, Windows XP albo Windows 2003. Ponizej˙ kilka typowych przykładów:

◦ zastapienie˛ Windows NT 4 przez Windows 2000

◦ zastapienie˛ MS Ofﬁce 97 przez MS Ofﬁce 2003

2.2 Etapy migracji

Wiele urzedów˛ i organizacji stoi obecnie przed podjeciem˛ decyzji dotyczacej˛ rozwoju ich systemu informatycznego i jego składników w najblizszych˙ latach. Koniecznos´c´ dokonania takiego wyboru moze˙ pojawic´ sie˛ z rózn˙ ych powodów:

◦ wygasni´ ecie˛ wsparcia dostarczanego przez producenta rózn˙ ych istotnych produktów

◦ rosnace˛ wymagania techniczne

◦ konsolidacja juz˙ stosowanych systemów i aplikacji

◦ rózne˙ cele strategiczne, np. uniezaleznienie˙ sie˛ od producenta oprogramowania oraz zwiek-˛ szenie kompatybilnosci´

Osoby odpowiedzialne za prawidłowe działanie oprogramowania w urzedach˛ i organizacjach musza˛ odpowiedziec´ na pytanie dotyczace˛ utworzenia własciwej´ bazy dla infrastruktury informatycznej. Dlatego niniejszy poradnik analizuje nastepuj˛ ace˛ podstawowe drogi migracji:

◦ Migracja zastepuj˛ aca˛ z wykorzystaniem GNU/Linux i Oprogramowania Open Source (OSS)

◦ Migracja zastepuj˛ aca˛ z wykorzystaniem GNU/Linux, OSS i komercyjnego oprogramowania linuksowego (COLS)

Migracja kontynuacyjna z wykorzystaniem MS Windows 2000 i kolejnych wersji oraz bazuja-˛ cych na nich systemach i aplikacjach. Dodatkowo nalezy˙ wzia˛c´ pod uwage˛ migracje˛ mieszana,˛ gdyz˙ nie mozna˙ z góry zakładac,´ ze˙ dla wszystkich składników tworzac˛ ych punkt wyjscia´ dla migracji, znajda˛ sie˛ odpowiedniki OSS i COLS. Jest tak zarówno z przyczyn technicznych, jak i ekonomicznych. ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 31

Nie było mozliwe˙ umieszczenie w ramach poradnika wszystkich spostrzeze˙ n´ zwiazan˛ ych z poruszonymi powyzej˙ zagadnieniami. Przyczyna˛ tego jest zarówno rozległosć´ systemów, które nalezałoby˙ poddac´ odpowiedniej ocenie, jak tez˙ kazdorazo˙ we, bardzo specyficzne wymagania poszczególnych urzedów˛ . Dlatego poradnik udziela raczej odpowiedzi na istotne, strategiczne pytania, które zadawane sa˛w jednakowy sposób przez wiekszo˛ sć´ urzedów˛ i w ten sposób pomaga podja˛c´ decyzje.˛

2.2.1 Punkt wyjscia´ - Microsoft Windows

Rysunek 2.1 przedstawia system Microsoft i składniki znajdujace˛ sie˛ w jego otoczeniu. Taka bad˛ z´ podobna struktura wykorzystywana jest w wielu urzedach˛ i organizacjach. Ponizszy˙ rysunek odwzorowuje usługi wraz z modułami - programami, które sa˛ cze˛sci´ a˛ składowa˛ sytuacji przed migracja,˛ bed˛ acej˛ punktem wyjscia´ dla naszej oceny. Na poczatku˛ rozdziału 3 opisana została techniczna ocena kazde˙ go ze składników systemu uwzgledniaj˛ aca˛ ich funkcje i szcze- gólne własciwo´ sci´ pod katem˛ planowanej migracji. Nastepnie˛ wyszczególniono odpowiednie techniczne rozwiazanie˛ lub rozwiazania˛ dla migracji zastepuj˛ acej.˛ W trzecim kroku ocenione zostały sposoby przeprowadzenia migracji kontynuacyjnej, a w czwartym i ostatnim kroku wska- zano, która˛ z dwóch dróg migracji nalezy˙ wybrac.´ ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 32

Rysunek 2.1: Składniki systemu - punkt wyjscia´

Podczas tworzenia niniejszego poradnika konieczne było przyjmowanie w rózn˙ ych miejscach załoze˙ n´ dotyczac˛ ych wielorakiej infrastruktury informatycznej. O ile w ramach przedstawianych tu ocen technicznych i ekonomicznych nie okreslimy´ inaczej, obowiazuj˛ a˛nastepuj˛ ace˛ załozenia.˙

Serwery

Załozyli˙ smy´ , ze˙ punkt wyjscia´ dla migracji w urzedach˛ opiera sie˛ na jednym z dwóch powszech- nych modelów domen NT.

◦ Srodo´ wisko NT z domena,˛ w której odbywa sie˛ zarzadzanie˛ kontami uzytko˙ wników i kontami komputerów.

◦ Srodo´ wisko NT z account domain, która zawiera konta uzytko˙ wników oraz wiele resource domains, które zarzadzaj˛ a˛ kontami komputerów i ufaja˛ account domain.

W srodo´ wisku tym, na bazie Windows NT 4 Server, udostepniane˛ sa˛ rózne˙ usługi infrastrukturalne oraz aplikacje i składniki integrujace.˛ Ponizej˙ wyszczególnione zostały główne usługi infrastrukturalne opisane w poradniku:

◦ logowanie i autoryzacja

◦ zarzadzanie˛ plikami

◦ drukowanie

◦ usługi sieciowe

◦ zarzadzanie˛ systemem

Ze wzgledu˛ na duze˙ rozpowszechnienie w administracji publicznej rózn˙ ych serwerów, w poradniku skoncentrowalismy´ sie˛ na przedstawieniu nastepuj˛ ac˛ ych z nich:

◦ Internet Information Server (IIS) w wersji 4, jako serwer WWW dla sieci Intranet i Internet

◦ Exchange 5.5, jako system Groupware i system Messaging

◦ SQL-Server 7, jako system zarzadzania˛ bazami danych dla wiekszo˛ sci´ aplikacji bazodanowych. ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 33

Do połaczenia˛ i integracji rózn˙ ych usług i aplikacji pod Windows dochodziło dotychczas z reguły na gruncie

◦ Component Object Model (COM) oraz

◦ nalez˙acej˛ do niego usługi Distributed COM (DCOM).

Udostepnienie˛ Windows NT 4 Services moze˙ byc´ realizowana przez dwie rózne˙ wersje systemu operacyjnego:

◦ Windows NT 4 Server

◦ Windows NT 4 Server Enterprise Edition.

Drugi z wymienionych serwerów (Enterprise Edition) umozliwia˙ realizacje˛ usług przez dwa we-˛ zły (serwery) w jednym klastrze.

Klienty i aplikacje

Jesli´ chodzi o oprogramowanie działajace˛ po stronie uzytko˙ wnika, nalezy˙ załozy˙ c,´ ze˙ dominuja-˛ cym systemem operacyjnym bedzie˛ tu Windows NT 4 Workstation. Starsze odmiany Windows, takie jak Windows 95 lub 98, nie były przez nas oceniane. Najwazniejszym˙ oprogramowaniem pracujac˛ ym na bazie w/w systemów jest Microsoft Office Suite. Dlatego oceniona zostanie za- równo wersja 97, jak i biez˙aca˛ wersja 2000 tego oprogramowania. Uzytko˙ wnicy uzywaj˙ a˛ ich podczas wykonywania swoich codziennych zadan.´ Dlatego udostepnia˛ sie˛ im z reguły edytory tekstu, arkusze kalkulacyjne, arkusze prezentacji oraz mozliwo˙ sć´ korzystania z komunikatorów sieciowych bad˛ z´ oprogramowania Groupware umozliwiaj˙ ace˛ go prace˛ grupowa.˛ Oprócz standardowego oprogramowania biurowego, uzywane˙ sa˛ takze˙ róznorodne˙ specjalistyczne aplikacje pracujace˛ pod w/w systemami operacyjnymi. Słuz˙a˛one do wykonywania zadan´ specyficznych dla konkretnego urzedu˛ i czesto˛ sa˛ zintegrowane z Windows-Desktop. W przypadku planowanej migracji wymagana jest ich szczególnie dokładna ocena. Poniewaz˙ zmiany podstawowej infrastruktury informatycznej, moga˛ naruszyc´ podstawy działania tego typu aplikacji, wymagane jest, w zalezno˙ sci´ od ich ilosci´ i stopnia skomplikowania, opracowanie odpowiednich rozwiaza˛ n´ przejscio´ wych. W poradniku przedstawione zostały wybrane propozycje i zalecenia dotyczace˛ własciwe´ go sposobu postepo˛ wania w takiej sytuacji. ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 34

Na koncu´ opisalismy´ jeszcze cały szereg innych standardowych aplikacji i narzedzi˛ (np. menedzerów˙ plików, takze˙ programów słuz˙ac˛ ych do kompresji danych), które udostepniane˛ sa˛ uzytko˙ wnikom podczas wykonywania przez nich codziennych prac. Programy te bed˛ a˛ im takze˙ potrzebne juz˙ po migracji, jako składniki nowego systemu.

2.2.2 Przeglad˛ systemu dla migracji zastepuj˛ acej˛

Rysunek 2.2 przedstawia alternatywne składniki, pracujace˛ na bazie systemu operacyjnego GNU/Linux. Pokazane sa˛ najwazniejsze˙ systemy i aplikacje, które mozna˙ wykorzystac´ do przeprowadzenia migracji zastepuj˛ acej.˛ W ostatniej dekadzie wielu producentów oprogramowania zdecydowało sie˛ na napisanie bad˛ z´ przystosowanie (przeportowanie) swoich produktów w taki sposób, by współpracowały one z Linuksem. Oprócz wielkich ﬁrm z branzy˙ informatycznej, takich jak IBM, SUN czy Oracle, mozna˙ w tym miejscu wspomniec´ takze˙ o licznych mniejszych przedsiebiorstwach˛ zajmujac˛ ych sie˛ dostarczaniem specjalistycznych rozwiaza˛ n´ informatycznych. Produkty te sa˛ na tyle znane z rynku oprogramowania komercyjnego, ze˙ nie wymagaja˛blizsze˙ go omówienia. Poradnik koncentruje sie˛ przede wszystkim na cze˛scio´ wo mniej znanych rozwiazaniach˛ Open Source oraz takich, które dopiero od niedawna mozna˙ wykorzystac´ dla przeprowadzenia migracji zastepuj˛ acej˛ w krytycznych obszarach. Rysunek 2.2 wyraznie´ wskazuje konkretne obszary zastosowan,´ gdzie tego typu rozwiaza-˛ nia sa˛ dostepne˛ jako cos´ wiecej˛ niz˙ tylko alternatywa. Dlatego oceny techniczne wysuwaja˛ na pierwszy plan klasyczne rozwiazania˛ oparte na oprogramowaniu Open Source. Tam, gdzie nie ma jeszcze odpowiednich aplikacji OSS, oceniono rozwiazania˛ wywodzace˛ sie˛ z grupy alternatywnego oprogramowania własnoscio´ wego pracujace˛ go pod GNU/Linux i opartego jednoczesnie´ na otwartych standardach. ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 35

Rysunek 2.2: Składniki systemu - migracja zastepuj˛ aca˛

2.2.3 Przeglad˛ systemu dla migracji kontynuacyjnej

W przypadku migracji kontynuacyjnej najwazniejsz˙ a˛rzecza˛jest zastapienie˛ Windows NT 4 oraz pozostałych współpracujac˛ ych z nim składników systemu, ich nowszymi wersjami. Do tego typu migracji nalezy˙ wykorzystac´ produkty z serii 2000. Odpowiednie zalezno˙ sci´ zostały przedstawione na rysunku . W rozdziale 3 przedstawione zostały charakterystyczne szczegóły techniczne oraz załozenia˙ konieczne do przeprowadzenia migracji, jak równiez˙ wymagane dla uruchomienia poszczegól- nych usług i serwerów srodki´ techniczne. Punktem wyjscia´ dla ponizsze˙ go opisu jest Windows 2000 Server. Nastepnie˛ przeanalizowane i ocenione zostały skutki zmian technicznych i pozostałe nowosci.´ ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 36

Rysunek 2.3: Składniki systemu - migracja kontynuacyjna

Podobnie, jak w przypadku migracji zastepuj˛ acej,˛ oprócz zmian po stronie serwerów, oceniane sa˛ tu takze˙ zmiany zachodzace˛ na desktopach. Róznica˙ polega na tym, ze˙ tym razem w centrum uwagi znajduje sie˛ Ofﬁce XP. Ostatecznie tam, gdzie pozwalaja˛ na to dostepne˛ informacje, oceniono równiez˙ serwery i pakiety biurowe wywodzace˛ sie˛ z serii 2003.

2.2.4 Wewnetrzne˛ zalezno˙ sci´ systemu opartego o rozwiazania˛ ﬁrmy Mi- crosoft

Architektury systemu, które w wiekszo˛ sci´ bazuja˛na produktach Microsoft, wykazuja˛róznie˙ silne wewnetrzne˛ zalezno˙ sci.´ W nastepuj˛ ac˛ ym rozdziale przedstawione zostały niektóre z takich wewnetrzn˛ ych zalezno˙ sci´ wystepuj˛ ac˛ ych w strukturze opartej na produktach Microsoft. Oczywista zalezno˙ sć´ polega na tym, ze˙ aplikacje firmy Microsoft daja˛ sie˛ zainstalowac´ i uzywa˙ c´ tylko w tym jednym systemie operacyjnym. Dotyczy to serwerów, jako tak zwanych produktów Back-Office (czyli MS SQL Server, MS Exchange itd.), jak równiez,˙ poza nielicz- nymi wyjatkami˛ (Office 98 dla MacOS, Internet Explorer 4 dla Uniksa), aplikacji desktopowych (np. MS Office) i oprogramowania klienckiego (np. klienty MS SQL). ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 37

Mówiac˛ ogólnie, w celu zarzadzania˛ kontami uzytko˙ wników i ich autoryzacji oraz weryﬁ- kacji praw dostepu˛ do zasobów, serwery wymagaja˛ administrowania. Microsoft oferuje rózne˙ sposoby administrowania w zalezno˙ sci´ od wykorzystywanej bazy danych uzytko˙ wników. Zo- stały one wymienione ponizej˙ na przykładzie serwera MS SQL Server.

◦ wariant A: administrowanie kontami uzytko˙ wników specyﬁczne dla SQL.

◦ wariant B: Administrowanie w oparciu o lokalna˛ baze˛ danych uzytko˙ wników systemu operacyjnego, w którym pracuje serwer.

◦ wariant C: Administrowanie w oparciu o baze˛ danych uzytko˙ wników wchodzac˛ a˛ w skład struktury domen windowsowych, o ile serwer jest członkiem tej struktury. Pocza˛wszy od ukazania sie˛ Windows NT wariant ten oferowany jest dla niemal wszystkich serwerów Microsoft i umozliwia˙ uzytko˙ wnikowi pracujacemu˛ w czystym srodo´ wisku Microsoft autoryzacje˛ Single Sign On.

◦ wariant D: Wariant, w którym mozna˙ korzystac´ ze sposobów autoryzacji dostarczanych przez innych producentów, nie jest oferowany.

Pocza˛wszy od Windows 2000 Microsoft przeniósł zarzadzanie˛ kontami i autoryzacje˛ uzytko˙ w- ników do usług katalogowych (patrz ponizej)˙ oraz otwartych standardów, takich jak Kerberos i LDAP, jednak bez dopuszczenia obcych rozwiaza˛ n.´ W swiecie´ Windows NT 4.0 mozna˙ zauwazy˙ c´ jeszcze inne zalezno˙ sci´ zwiazane˛ z administrowaniem kontami uzytko˙ wników. Na przykład niemozliwe˙ jest korzystanie z Microsoft Exchange (wersja 4 do 5.5) bez struktury domen Windows NT. Innym przykładem pokazujac˛ ym koniecz- nosć´ korzystania z domen NT jest działanie Cluster Services. To samo dotyczy stworzonej przez Microsoft architektury DCOM (Distributed Component Object Model), której architektura bezpieczenstwa´ zakłada, ze˙ klient i serwer nalez˙a˛ do tej samej struktury domen. DCOM uzywan˙ y jest przez duz˙a˛ ilosć´ aplikacji klient / serwer (firmy Microsoft i innych producentów). Wraz z Windows 2000 Microsoft rozwinał˛ model domen NT do usługi katalogowej Active Directory. W ramach Active Directory nadal obecny jest model domen NT i jego własciwo´ sci.´ Zachowano je ze wzgledu˛ na koniecznosć´ podtrzymania kompatybilnosci´ ze starszymi aplikacjami. Dlatego, np. wprowadzenie mechanizmu autoryzacji Kerberos nie oznacza likwidacji me- ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 38

chanizmu NTLM (NT LAN Manager). Takze˙ czyste srodo´ wiska Windows 2000 nadal uzywaj˙ a˛ NTLM w niektórych miejscach (np. klastry). Równoczesnie´ Active Directory wyposazon˙ y zo- stał w nowe mozliwo˙ sci,´ których albo nie było w swiecie´ Windows bad˛ z´ były wykorzystywane raczej oddzielnie. Z uwagi na funkcjonalnos´c´ wytycznych grup, ich cze˛sci´ były juz˙ znane w Windows NT jako wytyczne systemu, Internet Explorer Administration Kit (IEAK) albo Secu- rity Conﬁguration Editor (SCM). W przeciwienstwie´ do tego, w wytycznych grup zastosowane zostały nowe funkcjonalnosci,´ takie jak wymiana oprogramowania, połaczenie˛ z jednostkami organizacyjnymi, domenami i stanowiskami lub skryptami logowania i wylogowania. Całkowita˛ nowosci´ a˛ w Windows 2000 Active Directory jest integracja takich technologii szyfrowania, jak IPsec albo EFS (Encrypted File System). Aby móc ich uzywa˙ c,´ trzeba zbu- dowac´ infrastrukture˛ kluczy publicznych PKI (Public Key Infrastruktur) zintegrowana˛ z Active Directory. Microsoft rozszerzył takze˙ protokół Kerberos. Ma to umozliwi˙ c´ autoryzacje˛ przez SmartCard. Ponadto Windows 2000 Active Directory koniecznie wymaga serwera nazw (Do- main Name System), którego zadaniem jest tłumaczenie nazw. Minimalne parametry techniczne serwera nazw musza˛ odpowiadac´ własciwo´ sciom´ serwera BIND w wersji 8.2.2 . Windows 2000 posiada wbudowany własny DNS. Pierwszym produktem Microsoft obowiazko˛ wo wymaganym przez Windows 2000 Active Directory jest Exchange 2000. W przeciwienstwie´ do Exchange 5.5., Exchange 2000 nie jest juz˙ wyposazon˙ y we własne usługi katalogowe. Wszystkie informacje uzytko˙ wników poczty elektronicznej wraz z listami adresowymi Exchange 2000 znajduja˛ sie˛ w Active Directory, który trzeba przygotowac´ do integracji z Exchange przez rozszerzenie schematu. Centralna˛role˛ dla Exchange 2000 odgrywa Global Catalog w Active Directory. Jest on wykorzystywany przez Exchange 2000 do wysyłania na zewnatrz˛ zapytan´ ustalajac˛ ych granice domen. Z Global Catalog korzysta takze,˙ np. Outlook 2000. Exchange 2000 wykorzystuje Active Directory nie tylko w trybie odczytu, lecz równiez˙ do zapisu. Dlatego Recipient Update Service z Exchange 2000 moze˙ zapisywac´ swoje wyniki do Active Directory. Narzedzia˛ do zarzadzania˛ kontami pocztowymi uzytko˙ wników sa˛ całkowicie zintegrowane z konsola˛ zarzadzaj˛ ac˛ a˛ „Active Directory - Users and Computers”. Powyzsze˙ zwiazki˛ i zalezno˙ sci´ istniejace˛ pomiedzy˛ pochodzac˛ ymi z Microsoft aplikacjami i samym systemem operacyjnym pokazuja˛ pogłebianie˛ sie˛ procesów integracji wewnatrz˛ w/w systemu operacyjnego. Sytuacja taka wymusza postawienie całego szeregu strategicznych pytan´ zwiazan˛ ych z potencjalnym skorzystaniem z rozwiaza˛ n´ alternatywnych:

◦ W jaki sposób porzucic´ okreslon´ a˛ linie˛ produktów oraz przypisane do niej cykle aktualizacji? ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 39

◦ Jak mozna˙ zminimalizowac´ uzaleznienie˙ od jednej linii produktów i zwiazane˛ go z nia˛ wyposazenia˙ technicznego?

◦ Jakie srodki´ prowadza˛ do zredukowania uzaleznienia˙ od producenta i do zróznico˙ wania systemów oprogramowania?

◦ Czy dla okreslon´ ych składników oprogramowania istnieje wystarczajaco˛ duzo˙ konkuren- cyjnych cenowo substytutów?

Z uwagi na osiagni˛ ety˛ w tzw. miedzyczasie˛ stopien´ zalezno˙ sci´ pomiedzy˛ produktami, odpowiedzi na zadane powyzej˙ pytania mozna˙ udzielic´ z reguły tylko w oparciu o strategiczna˛ decyzje˛ uwzgledniaj˛ ac˛ a˛ koncepcje˛ rozwoju infrastruktury informatycznej w administracji.

2.3 Dystrybucje Linuksa

2.3.1 Wprowadzenie

Przy budowie systemu złozone˙ go z serwerów i klientów mozna˙ skorzystac´ z rozwiaza˛ n´ oferowanych w ramach rózn˙ ych dystrybucji Linuksa. Oprócz systemu operacyjnego GNU/Linux zawieraja˛ one bardzo wiele pakietów z róznorodn˙ ym oprogramowaniem. Nie chodzi tu wyłacznie˛ o oprogramowanie uzywane˙ na desktopach, które z reguły udostepniane˛ jest w wielu odmianach, lecz takze,˙ o serwery WWW, systemy zarzadzania˛ bazami danych, serwery pocztowe, firewalls, serwery posrednicz´ ace,˛ serwery usług katalogowych i duzo˙ wiecej.˛ Ponizej˙ pokrótce przedstawione zostana˛ wybrane dystrybucje oraz ich charakterystyczne cechy. Dystrybucje tworzone i oferowane sa˛ przez najrózniejszych˙ producentów i programistów. Pierwotnie dystrybucje były tworzone i rozwijane z reguły po to, by ułatwic´ uzytko˙ wnikom proces instalacji systemu operacyjnego (kernel) i wybranych programów. Firmy zajmujace˛ sie˛ two- rzeniem dystrybucji opracowały cały szereg rózn˙ ych narzedzi˛ administracyjnych ułatwiajac˛ ych obsługe˛ systemu operacyjnego oraz współpracujace˛ go z nim oprogramowania, którego cze˛sć,´ podobnie jak sam system, udostepniana˛ jest w oparciu o licencje wolnego oprogramowania. Jesli´ klient kupuje dystrybucje,˛ wówczas nie płaci on za system GNU/Linux, lecz za mozli-˙ wosć´ korzystania z zestawu dodatkowych narzedzi,˛ dokumentacji technicznej, instalatorów oraz innych ewentualnych programów stworzonych przez producenta dystrybucji. Celem dystrybucji jest zmniejszenie nakładu prac administracyjnych i organizacyjnych uzytko˙ wnika, gdyz˙ sam ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 40

system operacyjny nie dostarcza własnych rozwiaza˛ n´ tego typu. Wskutek tego system pozostaje otwarty na realizacje˛ rózn˙ ych pomysłów zarzadzania˛ nim. Wraz z kupnem dystrybucji klient otrzymuje na ogół oprócz nosników´ (obecnie jest to kilka płyt CD) kompletna˛ dokumentacje˛ techniczna.˛ W zalezno˙ sci´ od producenta dystrybucji rózni˙ sie˛ ona w swojej objeto˛ sci´ i jakosci,´ jednak zazwyczaj zawiera instrukcje˛ instalacji oraz dalsze informacje dotyczace˛ pracy z systemem. Na płytach CD znajduje sie˛ odpowiednia wersja systemu operacyjnego wraz z licznym innym oprogramowaniem. W oparciu o licencje˛ GNU General Public License (GPL), na której udostepnian˛ ych jest wiele programów pracujac˛ ych pod GNU/Linux, dostarczany jest przez producenta dystrybucji takze˙ kod zródło´ wy takich progra- mów oraz samego systemu operacyjnego. Dzieki˛ temu uzytko˙ wnik jest w stanie, gdy pojawia˛sie˛ jakiekolwiek problemy, samodzielnie ponownie skompilowac´ dowolny program po uprzednim dostosowaniu go do własnych potrzeb. Opisywane tu dystrybucje mozna˙ kupic´ w postaci gotowego zestawu (CD, dokumentacja) albo nieodpłatnie pobrac´ z Internetu. W przypadku kupna klient moze˙ na ogół korzystac´ ze wsparcia technicznego zapewnianego przez producenta dystrybucji. Jesli´ dystrybucja została po- brana z sieci, wówczas nie mozna˙ na to liczyc.´ W przypadku trzech opisanych ponizej˙ dystrybucji, dwie tworzone sa˛przez producentów, a jedna jest zbiorowa˛praca˛społecznosci´ programistów ja˛ rozwijajac˛ ych oraz innych osób pomagajac˛ ych w jej tworzeniu i testowaniu. W przyszłosci´ wazna˙ rola przypadnie kompatybilnosci´ wersji Linuksa i ujednoliceniu po- szczególnych dystrybucji. Aby unikna˛c´ powstawania zbyt duzych˙ róznic˙ pomiedzy˛ nimi, ustalono standardy. Na przykład File System Hierarchy Standard1 w celu zdefiniowania struktury katalogów Linuksa. Twórcy dystrybucji na ogół stosuja˛ sie˛ do powyzsze˙ go standardu. Ponadto File System Hierarchy Standard jest, jako wazna˙ cze˛sć´ składowa wysiłków na rzecz kompatybilnosci,´ standardem Linux Standard Base (LSB)2. Celem Linux Standard Base jest definiowanie standardów prowadzac˛ ych do uzyskania mozliwie˙ szerokiej kompatybilnosci´ wszystkich dystrybucji i zapobiegajac˛ ych powstawaniu rozbiezno˙ sci´ pomiedzy˛ nimi. Standaryzacja ma na celu ułatwienie pracy programistom rozwijajac˛ ym oprogramowanie oraz producentom dystrybucji. Przy zachowaniu obecnego sposobu tworzenia dystrybucji, zgodnego ze standardami LSB, w przyszłosci´ mozliwa˙ stanie sie˛ wymiana oprogramowania bez wzgledu˛ na dystrybucje˛ z której pochodza.˛ Oprócz LSB, w kontekscie´ podejmowanych działan´ na rzecz standaryzacji, trzeba wymienic´

1http://www.pathname.com/fhs/ 2http://www.linuxbase.org ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 41

Free Standard Group3. Tworza˛ ja˛ LSB, Open18N4 (niegdys´ Linux Internationalization Initiative Li18nux) i LANANA (The Linux Assigned Names and Numbers Authority). LANANA administruje nazwami stosowanymi w ramach oprogramowania linuksowego, co ma na celu unikniecie˛ konﬂiktów pomiedzy˛ rózn˙ ymi aplikacjami i sterownikami. Członkami FSG sa˛ Caldera, Compaq, Conectiva, Debian, Dell, Hewlett Packard, Hitachi, IBM, Miracle Linux, The Open Group, Oracle, Red Hat, SCO, Sun, SuSE, Turbolinux, VA Software oraz członkowie społeczno- sci´ programistów Open Source. Wszyscy producenci dystrybucji przedstawionych w poradniku sa˛reprezentowani w FSG. Z lista˛dystrybucji certyﬁkowanych przez LSB mozna˙ zapoznac´ sie˛ w Internecie5. Przy wybieraniu dystrybucji wazn˙ a˛ role˛ odgrywaja˛ z jednej strony wymagania zwiazane˛ z pomoca˛ w administrowaniu oraz wsparcie sprzeto˛ we, a z drugiej warunki ekonomiczno organizacyjne. Przykładami takich kryteriów moze˙ byc´ istnienie kontraktów ramowych albo oferta zawierajaca˛ aplikacje, które zostały specjalnie przystosowanych do potrzeb urzedu.˛ Dystrybucje przedstawione ponizej˙ zostały wybrane ze wzgledu˛ na wysoki stopien´ ich roz- powszechnienia (patrz takze˙ 2.5.1 ).

2.3.2 Debian GNU/Linux

W ramach projektu Debian rozwijany jest, wspólna˛ praca˛ rzeszy programistów, wolny system operacyjny. Charakterystyczna˛ cecha˛ projektu jest rozproszenie twórców Debiana, którzy pochodza˛ z całego swiata.´ Jest to niemal 1.000 osób pracujac˛ ych nieodpłatnie i opiekujac˛ ych sie˛ poszczególnymi pakietami. Istotnym znakiem ﬁrmowym Debiana jest udostepnianie˛ tej dystrybucji na zasadach licencji GPL oraz to, ze˙ moze˙ byc´ ona bez ograniczen´ kopiowana i uzywana˙ w celach komercyjnych. Debiana mozna˙ sci´ agn˛ a˛c´ za darmo z Internetu, jak i kupic.´ Dystrybucja ta nie jest zaliczana do produktów komercyjnych, dlatego przy zakupie płyt CD z Debianem płacimy za koszty transportu oraz wyprodukowania nosników´ . Dystrybucja nie jest rozprowadzana w postaci pudełko- wej, co odróznia˙ ja˛ od niektórych komercyjnych produktów. Rzecza˛ charakterystyczna˛ dla Debiana jest sposób usuwania błedów˛ przez opiekunów dystrybucji. Za posrednictwem´ bug-tracking publikowana jest lista zawierajaca˛ wszystkie istniejace,˛ zgłoszone błedy˛ oraz lista błedów˛ , nad usunieciem˛ których trwaja˛własnie´ prace. Dzieki˛ takiemu

3http://www.freestandards.org 4http://www.openi18n.org 5http://www.opengroup.org/lsb/cert/cert_prodlist.tpl?CALLER=cert_prodlist. tpl ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 42

mechanizmowi zapewnienia bezpieczenstwa´ Debian zaliczany jest do najstabilniejszych, obar- czonych najmniejsza˛ ilosci´ a˛ błedów˛ dystrybucji. Projekt odznacza sie˛ długim cyklem wydawania kolejnych wersji, co gwarantuje tej dystrybucji wysoka˛ jakosć.´ W ten sposób nie dochodzi do wypuszczania na rynek „niedopracowanych” wersji. Jedna˛ z istotnych własciwo´ sci´ Debiana jest własny format pakietów oraz odpowiednie narzedzia˛ słuz˙ace˛ do zarzadzania˛ nim. Ma to te˛ istotna˛ zalete,˛ ze˙ daje mozliwo˙ sć´ łatwego aktuali- zowania zarzadzane˛ go sytemu, jak i pojedynczych programów, bez koniecznosci´ instalowania oprogramowania od poczatku.˛ System zarzadzania˛ pakietami słuzy˙ jednoczesnie´ do wykonywania regularnych aktualizacji systemów polegajac˛ ych na uaktualnieniach w zakresie stabilnosci´ i bezpieczenstwa.´ Wszelka pomoc zwiazana˛ z obsługa˛sytemu i jego rozwojem zapewniona jest poprzez szereg list dyskusyjnych6. Jesli´ takie zródło´ informacji okaze˙ sie˛ byc´ niewystarczajace,˛ zawsze mozna˙ skorzystac´ z usług technicznych licznych komercyjnych firm.

2.3.3 SuSE Linux Distribution

SuSE Linux AG jest jednym z wiekszych˛ miedzynarodo˛ wych producentów dystrybucji. Trady- cyjnie SuSE reprezentowana jest bardzo silnie na rynku niemieckim. Poczatki˛ działalnosci´ w/w spółki zwiazane˛ sa˛ z wprowadzeniem na ten rynek pochodzacej˛ z Holandii dystrybucji Slac- kware7. Dopiero po pewnym czasie SuSE stworzyła własna˛ dystrybucje.˛ Z biegiem lat ﬁrma rozwineła˛ produkty stosowane obecnie w najrózniejszych˙ obszarach IT. Ponizsza˙ tabela przedstawia najwazniejsze˙ własciwo´ sci´ rózn˙ ych dystrybucji.

PRODUKTY PRZEZNACZENIE W pierwszym rzedzie˛ zalecana przez producenta do zastosowan´ desktopowych. Dystrybucje zawieraja˛ duz˙a˛ ilos´c´ pakietów wraz z odpowiednimi narzedziami˛ potrzebnymi do ich instalacji. W Personell - Professional wersji Professional na płytach CD zamieszczone zostały równiez˙ liczne programy przeznaczone na serwery, które mozna˙ wykorzystywac´ w przedsiebiorstwach.˛

6http://www.debian.org/support 7http://www.slackware.org ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 43

SuSE Linux Server przeznaczone sa˛dla wszelkich zastosowan´ informatycznych. Dostepne˛ sa˛ one na wszystkie wazne˙ platformy Enterprise sprzeto˛ we: procesory 32 oraz 64 bitowe ﬁrm AMD i Intel. Ob- sługuja˛ takze˙ cały szereg eSerwerów ﬁrmy IBM, łacznie˛ z mainframe.

Tablica 2.2: SuSE Linux

Dystrybucja SuSE opiera sie˛ na rozwinietym˛ przez amerykansk´ a˛ firme˛ Red Hat systemie zarzadzania˛ pakietami RPM. Z jego pomoca˛ programowanie moze˙ byc´ instalowane oraz dein- stalowane - takze˙ przez osoby trzecie - na ogół bez zadn˙ ych problemów. Doswiadczenie´ uczy jednak, ze˙ niektóre specyficzne dla poszczególnych dystrybucji pakiety nalezy˙ instalowac´ zgodnie z metoda˛ preferowana˛przez ich twórców. Dystrybucje SuSE zawieraja˛ zintegrowany system słuz˙ac˛ y do instalacji i administrowania pakietami o nazwie YaST. Podczas instalacji udostepnia˛ on uzytko˙ wnikom zarówno tryb tekstowy, jak i graficzny. Rózne˙ wersje SuSE przedstawione w powyzszej˙ tabeli rózni˙ a˛sie˛ miedzy˛ soba˛przede wszystkim zalecanym obszarem zastosowan,´ zwiazan˛ ymi z tym mozliwo˙ sciami´ korzystania z pomocy technicznej oraz sposobami licencjonowania, a takze˙ cena.˛ Dla zastosowan´ w obszarze przedsiebiorstw˛ , ze wzgledu˛ na dostepno˛ sć´ oraz skalowalnosć,´ oferowane sa,˛ jako najlepsze, zoptymalizowane rozwiazania,˛ czyli wersja Enterprise. Zintegro- wane tu zostały, na przykład, rozwiazania˛ klastrowe, wieloprocesorowe oraz asynchroniczne I/O. Ponadto obydwie wersje rózni˙ a˛sie˛ od siebie dostepno˛ sci´ a˛pomocy technicznej. W zalezno˙ sci´ od indywidualnych potrzeb klienta mozliwe˙ jest, np. uzyskanie pomocy 24x7, indywidualnych Service Level Agreements i certyfikatów.

2.3.4 Red Hat

Inna˛ komercyjna˛ dystrybucja˛ jest Red Hat. Takze˙ Red Hat oferuje wiele wersji swojej dystrybucji, które przeznaczone sa˛ do realizacji rózn˙ ych zadan´ (patrz takze˙ 2.4). Równiez˙ w tym przypadku producent zastosował własne narzedzia˛ słuz˙ace˛ do zarzadzania˛ pakietami. Pakiety z oprogramowaniem (*.rpm) obsługiwane sa˛za pomoca˛systemu Red Hat Package Management, który umozliwia˙ spójne i komfortowe administrowanie. ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 44

PRODUKTY PRZEZNACZENIE Obie dystrybucje przeznaczone sa˛ przede wszystkim do zastosowan´ na stacjach roboczych, wzglednie˛ moga˛ byc´ serwerami w Red Hat Linux i małych sieciach. Róznica˙ pomiedzy˛ dwoma oferowanymi pro- Red Hat Linux duktami polega głównie na tym, ze˙ charakteryzuje je rózn˙ y zakres Professional dostawy oraz rózn˙ y czas udzielania pomocy technicznej. Wersja Professional zawiera wieksz˛ a˛ ilos´c´ narzedzi˛ do administrowania systemem. Rozwiazanie˛ to przeznaczone jest przede wszystkim dla przedsiebiorstw˛ . Systemy Enterprise posiadaja˛ certyﬁkaty dla całego Enterprise Linux szeregu platform produkowanych przez rózn˙ ych producentów osprzetu˛ i obsługuja,˛ np. systemy klastrowe o wysokiej niezawodnosci.´

Tablica 2.4: Red Hat

Poszczególne produkty rózni˙ a˛ sie˛ od siebie przede wszystkim zalecanym obszarem zastosowania oraz wynikajac˛ ymi z tego mozliwo˙ sciami´ uzyskania pomocy technicznej, sposobem licencjonowania i cena.˛

2.3.5 Certyﬁkaty

W tym miejscu nalezy˙ rozrózni˙ c´ certyﬁkaty osprzetu,˛ oprogramowania oraz certyﬁkaty umiejet-˛ nosci.´

Osprzet˛

W ramach certyfikatów osprzetu˛ przeprowadzana jest procedura polegajaca˛ na jego testowaniu. Po przetestowaniu oprzyrzado˛ wania, przyznawane sa˛ odpowiednie certyfikaty dla poszczegól- nych dystrybucji oraz wersji Linuksa. Sprawdzana jest wydajnosć´ oraz zgodnosć´ działania testo- wanych urzadze˛ n´ z ich specyfikacja˛techniczna.˛ Producenci sprzetu˛ maja˛ mozliwo˙ sć´ certyfikacji swoich produktów dla kazdej˙ dystrybucji. Czesto˛ posiadanie certyfikatu stanowi dla nich, oprócz gwarancji jakosci,´ takze˙ wazn˙ y argument marketingowy. ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 45

Certyfikaty oferuja˛ klientom, szczególnie gdy chodzi o aplikacje i rozwiazania˛ majace˛ strategiczne znaczenie, np. systemy ERP z RAID albo SAN, zwiekszon˛ a˛ pewnosć´ kompatybilnosci´ uzywane˙ go osprzetu˛ i systemu operacyjnego. Dla pózniejszych´ klientów bad˛ z´ uzytko˙ wników certyfikaty moga˛ byc´ decydujac˛ ym czynnikiem przy podejmowaniu decyzji o zakupie.

Oprogramowanie

Certyfikacje˛ oprogramowania przeprowadzaja˛ wszyscy producenci oprogramowania (Indepen- dent Service Vendor). Poszczególni producenci uwiarygadniaja˛ i certyfikuja˛ dystrybucje jako platforme˛ - system operacyjny dla swojego oprogramowania. Przykładem takiego działania sa˛ przedsiebiorstwa˛ SAP oraz Oracle, które certyfikuja˛ SuSE Linux8 Enterprise Server jako platforme˛ dla konkretnych aplikacji. Podobne certyfikaty uzyskuja˛takze˙ producenci dystrybucji Red Hat9. Z reguły procesom tym podlegaja˛ za kazdym˙ razem tylko wersje Enterprise dystrybucji tworzonych przez poszczególnych producentów oprogramowania. Certyfikacja oprogramowania jest dla wielu klientów podstawowym warunkiem wdrozenia˙ danego systemu operacyjnego. Wynika to z tego, ze˙ kupujac˛ produkty z certyfikatem, klienci czesto˛ otrzymuja˛ od producenta oprogramowania, wymagana˛ podczas instalacji i korzystania z dostarczanych aplikacji, pomoc techniczna.˛

Certyﬁkaty umiejetno˛ sci´

Oprócz certyfikatów wydawanych na osprzet˛ i oprogramowanie wymagane sa˛ równiez˙ certyfikaty swiadcz´ ace˛ o poziomie wiedzy specjalistycznej oraz umiejetno˛ sciach´ pracowników. Obecnie istnieja˛ dwa wyrózniaj˙ ace˛ sie,˛ miarodajne programy certyfikacji:

◦ program ﬁrmy Red Hat, Red Hat Certiﬁed Enginner (RHCE)10 oraz

◦ program Linux Professionell Institute (LPI)11

Celami obydwu z nich sa˛ m. in. stworzenie standardów oceny kwaliﬁkacji pracowników. Dla pracodawców certyﬁkacja przedstawia dla nastepuj˛ ace˛ zalety:

8http://www.suse.com/de/business/certifications/certified_software/index. html 9http://www.redhat.com/solutions/migration/applist.html 10http://www.redhat.com/training/rhce/courses/index.html 11http://www.de.lpi.org/ ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 46

◦ pomaga w procesie rekrutacji

◦ zapewnia standardowy sposób oceny kwaliﬁkacji pracowników

Pracownikom lub potencjalnym przyszłym pracownikom certyﬁkaty oferuja:˛

◦ mozliwo˙ s´c´ wykonywania konkretnych zadan´

◦ poswiadczenie´ kwaliﬁkacji

◦ zwiekszenie˛ szansy na rynku pracy.

Zasadniczo obydwa programy certyfikacyjne mozna˙ traktowac´ jako równorzedne,˛ przy czym RHCE ukierunkowany jest bardziej na własna˛ dystrybucje.˛ Przedsiebiorstwo˛ Red Hat zaczeło˛ rozwijac´ program przyznawania certyfikatów jeszcze w czasach, gdy nie istniały programy certyfikacyjne dla systemów opartych na GNU/Linux. Dopiero pózniej´ w społecznosci´ Linuksa rozwina˛ sie˛ program LPI. Jest on neutralny jesli´ chodzi o dystrybucje˛ i producenta oprogramowania.

2.3.6 Wnioski

Uzytko˙ wnicy moga˛ dokonywac´ wyboru sposród´ licznych dystrybucji oraz rózn˙ ych ich wersji. Przy podejmowaniu decyzji wazne˙ jest rozpoznanie i ustalenie koniecznych wymagan.´ Decy- zja o wyborze konkretnej dystrybucji zapasć´ moze˙ tylko w oparciu o kazdorazo˙ we oczekiwania wzgledem˛ dystrybucji bad˛ z´ producenta oraz tzw. warunki ramowe. Jesli,´ np. z braku własnych zasobów ludzkich, niezbedna˛ jest pomoc techniczna producenta, wówczas nalezy˙ w pierwszej kolejnosci´ zastanowic´ sie˛ nad wyborem dystrybucji komercyjnej. Gdy dla konkretnych zastosowan´ wymagane jest oprogramowanie certyfikowane, wówczas na ogół pozostaje tylko oferta firm komercyjnych i wersje Enterprise ich dystrybucji. To, jaki osprzet˛ i oprogramowanie rzeczywiscie´ posiada certyfikaty oraz dla jakiej dystrybucji i wersji, nalezy˙ sprawdzic´ w kazdym˙ osobnym przypadku. Dla uzytko˙ wników, którzy nie sa˛ skazani na komercyjne wersje dystrybucji, stabilna,˛ dobrze przetestowana˛ oraz niezawodna˛ dystrybucja˛ na pewno okaze˙ sie˛ Debian. Jesli´ konieczna tu be-˛ dzie szeroka pomoc techniczna, takze˙ w tym przypadku mozna˙ zwrócic´ sie˛ o pomoc do licznych, istniejac˛ ych na rynku, własciwych´ przedsiebiorstw˛ usługowych. ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 47 2.4 Licencje

W swiecie´ Linuksa istnieje cały szereg rózn˙ ych modelów licencji. Najwazniejsze˙ z nich zostały nazwane i krótko scharakteryzowane ponizej.˙

2.4.1 GPL

Zapewne najbardziej znanym modelem licencji jest General Public License (GPL)12, która zo- stała stworzona przez Free Software Foundation. Zarówno Linux Kernel, jak i wieksza˛ cze˛s´c´ aplikacji linuksowych udostepniane˛ sa˛ na „GPL”, licencji która m. in. gwarantuje udostepnianie˛ kodu zródło´ wego oraz dowolne korzystanie z programów. Aby oprogramowanie objete˛ ta˛ licencja˛ takze˙ w przyszłosci´ pozostało wolne, w GPL dokładnie zapisano wolnosci´ oraz warunki jego stosowania. Poszczególne wolnosci´ i warunki obejmuja:˛

◦ paragraf 0: Wolnos´c´ wykonywania programu w kazdym˙ celu

◦ paragraf 1: Zezwolenie na kopiowanie oraz rozpowszechnianie dosłownych kopii kodu zródło´ wego programu, o ile załaczona˛ jest do nich tres´c´ Copyright i licencja GPL. Wyraznie´ zezwala sie˛ takze˙ na pobieranie opłat za ﬁzyczne tworzenie kopii i inne usługi, np. gwarancyjne.

◦ paragraf 2: Zezwolenie na modyfikowanie i kopiowanie programu oraz rozpowszechnianie jego zmodyfikowanych wersji, o ile zawieraja˛ one informacje o wprowadzonych zmianach, sa˛ bez- płatne i publikowane na tej samej licencji. Wyjatkami˛ sa˛ te cze˛sci´ zmienionego programu, które tworza˛ niezalezn˙ a˛ całosć´ i sa˛ rozpowszechniane oddzielnie.

◦ paragraf 3: Zezwolenie na kopiowanie programu albo opartych na nim wersji w postaci kodu obiekto- wego lub wykonywalnego, o ile dołaczon˛ y jest don´ pełny kod zródło´ wy w postaci nadaja-˛ cej sie˛ do odczytania przez komputer lub pisemna oferta, (wazna˙ przez co najmniej 3 lata), gotowosci´ do przekazania go na z˙adanie.˛

12http://www.gnu.org/licenses/translations.pl.html Oryginał licencji znajduje sie˛ na stronie:http://www.gnu.org/copyleft/gpl.html ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 48

Kolejne paragrafy dotycza˛ przepadku praw wynikajac˛ ych z licencji, rekojmi˛ oraz gwarancji. Ponadto opisane sa˛ w nich konﬂikty z innymi roszczeniami i cały szereg innych zagadnien,´ o których w razie potrzeby mozna˙ przeczytac.´ Dzieki˛ swoim warunkom licencja GPL zapobiega prywatyzacji stworzonego wspólnie oprogramowania i tym samym wyraznie´ wspiera ciagło˛ s´c´ istnienia oraz rozwój Wolnego Oprogra- mowania.

2.4.2 Lesser GPL

GNU Lesser General Public License (LGPL)13 jest alternatywa˛ dla licencji GPL. Pierwotnie powstała ona pod nazwa˛ Library GPL. Licencja LGPL jest w bardzo wielu punktach zbiezna˙ z zamiarami wyrazan˙ ymi w GPL. Takze˙ tu musi istniec´ dowolnosć´ kopiowania, rozpowszechniania i modyfikowania oprogramowania, wzglednie˛ bibliotek. Oprócz tego kod zródło´ wy, równiez˙ ten ze zmodyfikowanych wersji, musi byc´ udostepnian˛ y bez ograniczen.´ Róznica˙ w porównaniu z GPL polega przede wszystkim na tym, ze˙ programy, które nie sa˛ publikowane na licencji GPL lub podobnej, moga˛ uzywa˙ c´ wolnych bibliotek rozprowadzanych na zasadach LGPL i tworzyc´ odrebn˛ a˛ wykonywalna˛ całosć.´ Gdyby w/w biblioteki udostepniane˛ były na licencji GPL, wówczas wykorzystywac´ by je mogły tylko programy publikowane wy- łacznie˛ na GPL. W przeciwienstwie´ do tego licencja LGPL zezwala programistom na tworzenie programów, które nie sa˛ rygorystycznie chronione przez GPL, przy uzyciu˙ wolnych bibliotek. Programy, które uzywaj˙ a˛ bibliotek udostepnian˛ ych na licencji LGPL, moga˛ byc´ rozpowszechniane na dowolnie wybranych warunkach licencjonowania, jednak z zastrzezeniem˙ udostepnie-˛ nia klientowi kodu zródło´ wego bibliotek udostepnian˛ ych na LGPL, co ma na celu umozliwienie˙ mu modyfikacji i ponownego uzycia˙ kodu.

2.4.3 BSD

Licencja BSD14 jest jedna˛z najstarszych wolnych modelów licencji. Powstał on na uniwersytecie Berkeley w celu rozpowszechniania zmodyﬁkowanych wersji Uniksa15. Licencja BSD zezwala na dowolne kopiowania oprogramowania z lub bez własnych mody- ﬁkacji, zarówno w postaci kodu zródło´ wego, jak i/lub binariów pod nastepuj˛ ac˛ ymi warunkami:

13http://www.gnu.org/copyleft/lesser.html 14http://www.opensource.org/licenses/bsd-license.html 15Licencja dotyczyła wyłacznie˛ kodu zródło´ wego stworzonego na uniwersytecie Berkeley. ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 49

Odpowiednie pliki rozpowszechnianego oprogramowania musza˛ zawierac´ tresć´ Copyright oraz licencje˛ BSD. W przypadku rozpowszechniania oprogramowania w formie binarnej, tresć´ Copyright oraz zapisy licencji BSD musza˛ byc´ zawarte w dokumentacji oprogramowania lub innej. Bez posiadania pisemnej zgody nie wolno uzywa˙ c´ w celach reklamowych ani nazwy uniwer- sytetu, ani tez˙ nazwisk autorów. W pierwotnej wersji licencji istniał jeszcze jeden aspekt, tj. we wszystkich materiałach reklamowych mówiac˛ ych o programach rozprowadzanych w oparciu o BSD, musiała znajdowac´ sie˛ nastepuj˛ aca˛ adnotacja: „Niniejszy produkt zawiera oprogramowanie, które zostało stworzone przez Kalifornijski Uniwersytet Berkeley i jego kooperantów”. Klauzula ta została usunieta˛ ze starej licencji, a ostatnia wersja Berkeley jest juz˙ opublikowana w oparciu o nowa˛ licencje.˛ Dla- tego mówi sie˛ zarówno o starej, jak i nowej licencji BSD. BSD nie zawiera ograniczen´ dotyczac˛ ych uzytko˙ wania oraz rozpowszechniania kodu zródło-´ wego bad˛ z´ programów. Wymagane jest jedynie załaczanie˛ do oprogramowania tresci´ Copyright, samej licencji BSD oraz warunków wygasni´ ecia˛ gwarancji. Licencja nie zmusza do udostepnia-˛ nia zmodyfikowanego oprogramowania wraz z kodem zródło´ wym. Dlatego kazda˙ firma progra- mistyczna moze˙ wykorzystac´ w swoim oprogramowaniu kod zródło´ wy oparty o licencje˛ BSD bez koniecznosci´ udostepniania˛ zródeł´ własnego programu. Licencja BSD wia˛ze˙ sie,˛ w porównaniu z wczesniej´ opisanymi licencjami, ze znacznie mniejszymi restrykcjami.

2.5 Zbieranie informacji o projektach

Wyniki przedstawione w poradniku opieraja˛ sie˛ głównie na:

◦ doswiadczeniach´ zdobytych w czasie wdrazania˙ projektów migracyjnych

◦ doswiadczeniach´ zdobytych podczas rozwijania oprogramowania OSS oraz COLS

◦ uwzglednienia˛ know-how ekspertów

◦ badan´ nad mozliwo˙ sciami´ wdrozenia˙ planowanych migracji

◦ szczegółowo opracowanych koncepcjach migracji

◦ literaturze specjalistycznej oraz dokumentacji oprogramowania.

Specjalistyczne informacje wazne˙ dla powstania poradnika zostały zebrane w oparciu o: ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 50

◦ intensywna˛ analize˛ dokumentów

◦ wywiady i ich ocene˛

◦ warsztaty organizowane pod katem˛ konkretnych zagadnien´ oraz

◦ bezposrednie´ zaangazo˙ wanie licznych ekspertów i producentów oprogramowania.

Tres´c´ oraz wnioski wynikajace˛ z powyzszych˙ zródeł´ informacji zostały w poradniku przedstawione tematycznie, w formie pojedynczych zagadnien.´ Jednoczesnie´ zostały one przeanalizowane i ocenione.

2.5.1 Doswiadczenia´ z projektów migracyjnych

Wdrazanie˙ i wykorzystywanie OSS jest obecnie na porzadku˛ dziennym zarówno w administracji publicznej, jak i w przedsiebiorstwach.˛ Duze˙ zainteresowanie tym zagadnieniem doprowadziło juz˙ do powstania całego szeregu projektów migracyjnych, w których opisywane sa˛ najaktual- niejsze doswiadczenia´ i wnioski. Obok czysto technologicznych informacji i doswiadcze´ n,´ projekty te zawieraja˛wazne˙ wnioski na temat krytycznych wyznaczników sukcesu (patrz 5.5.3) oraz oczekiwanych nakładów podczas poszczególnych etapów migracji. W ramach przygotowan´ do badan´ nad sposobami migracji zebrano rózne˙ dokumenty, takie jak dokładne specjalistyczne koncepcje, opisy wydajnosci´ oraz całoscio´ we dokumentacje pro- jektów. Taka dokładna analiza stała sie˛ takze˙ podstawa˛dla powstania poradników nt. przeprowadzania wywiadów zwiazan˛ ych tematycznie z poszczególnymi obszarami badan´ prowadzonych nad projektem. Gromadzenie informacji polegało, na ogół, na przeprowadzaniu wywiadów w urzedach˛ i ﬁr- mach bad˛ z´ wywiadów z administratorami, uzytko˙ wnikami i wdrozenio˙ wcami. Pytania dotyczyły nastepuj˛ ac˛ ych zagadnien:´

◦ sytuacja wyjscio´ wa

◦ strategiczne elementy projektu

◦ motywacja i sposoby wyznaczania celu

◦ krytyczne wyznaczniki sukcesu ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 51

◦ koszty i korzysci´

◦ Lessons Learned

◦ projekty przyszłoscio´ we - rozwój strategii informatycznej

Zostały one uzupełnione szczegółowymi technicznymi pytaniami dotyczac˛ ymi migracji cze˛scio-´ wej, odpowiednio do specyﬁcznych technicznych problemów wystepuj˛ ac˛ ych przy poszczegól- nych projektach. Jesli´ chodzi o projekty migracyjne, to przygotowywanie ich mozliwe˙ jest m. in. w oparciu o doswiadczenia´ wynikajace˛ z projektów pilotazo˙ wych zainicjowanych przez Federalny Urzad˛ ds. Bezpieczenstwa´ w Informatyce (BSI) na zlecenie Ministerstwa Spraw Wewnetrzn˛ ych (BMI). W czasie tworzenia niniejszego poradnika, projekty te były juz˙ w powazn˙ ym stopniu wdrozone˙ i zakonczone´ duzym˙ sukcesem. Z drugiej strony analizowane były projekty pochodzace˛ z administracji publicznej i przedsiebiorstw˛ , w których dokonano migracji w oparciu o ocene˛ ekonomiczna˛ i z których napłyneły˛ informacje oraz doswiadczenia´ z przeprowadzonych migracji. W przypadku wszystkich tych projektów mamy i mielismy´ do czynienia z najrózniejszymi˙ sytuacjami wyjscio´ wymi. Najcze˛sciej´ były to systemy oparte o serwery Windows NT 4, które nalezało˙ zastapi˛ c´ i skonsolidowac.´ Jesli´ chodzi o serwery, istniały takze˙ srodo´ wiska mieszane, składajace˛ sie˛ z Windows NT, Unix i GNU/Linuksa. Po stronie klientów reprezentowane było róznorodne˙ oprogramowanie ze swiata´ Windows - od Windows 95, az˙ do Windows XP. W przewazaj˙ acej˛ cze˛sci´ były to, odpowiednio do obecnego wyposazenia˙ wiekszo˛ sci´ urzedów˛ , stacje robocze Windows NT 4. Takze˙ zakres i rodzaj migracji moze˙ miec´ bardzo wiele wariantów. I tak oprócz zaawansowa- nych całkowitych migracji (serwery i klienty) przeprowadzano migracje˛ wyłacznie˛ na serwerach przy jednoczesnym pozostawieniu na stacjach roboczych systemu Windows NT 4. Mozliwe˙ przy tym było przejecie˛ istniejac˛ ych struktur plików oraz uprawnien´ bez koniecznosci´ wprowadzania zmian na klientach NT odczuwalnych dla uzytko˙ wników. Ponadto w jednym z ocenianych pro- jektów migracyjnych załozyli˙ smy´ , ze˙ migracja ma miejsce wyłacznie˛ na stacjach roboczych, które bed˛ ac˛ klientami linuksowymi sa˛ zintegrowane z istniejac˛ a˛ siecia˛ NT4. Ponadto nie moglismy´ nie wspomniec´ o migracji polegajacej˛ z jednej strony na zainstalowaniu oprogramowania linuksowego na serwerze, a z drugiej strony na zastapieniu˛ dotychczasowych FAT Clients przez Thin Clients. Tam, gdzie konieczne było dalsze korzystanie z aplikacji windowsowych (aplikacje specjalistyczne), dla których na razie nie istnieja˛ wersje linuksowe bad˛ z´ alternatywne oprogramowanie na Linuksa, opisalismy´ zastosowanie terminali i emulatorów. ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 52

Patrzac˛ z technicznego punktu widzenia, moglismy´ korzystac´ z doswiadcze´ n´ migracyjnych zebranych podczas przeprowadzania migracji wazn˙ ych aplikacji oraz usług systemowych takich jak:

◦ migracje baz danych, m. in. migracja bazy danych MS SQL Server do SAP DB z zachowaniem aplikacji Visual Basic po stronie klienta.

◦ migracja usług infrastrukturalnych

◦ zarzadzanie˛ plikami (równiez˙ w systemach heterogenicznych za pomoca˛ Samby)

◦ drukowanie

◦ autoryzacja (wraz z usługami katalogowymi OpenLDAP)

◦ usługi sieciowe

◦ migracja podstawowego oprogramowania biurowego

◦ migracja na serwerach WWW

◦ i inne

Projekty pilotazo˙ we zainicjowane przez BSI zostały wdrozone˙ w nastepuj˛ ac˛ ych urzedach:˛

◦ Federalny Urzad˛ ds. Karteli

◦ Komisja ds. Monopoli

◦ Instytut Hodowli Zwierzat˛ Mariensee

Inne zgromadzone projekty sa˛ w nastepuj˛ ac˛ ych urzedach˛ na etapie planowania, własnie´ sie˛ je wdraza˙ albo zostały juz˙ zrealizowane:

◦ Urzad˛ Pełnomocnika Rzadu˛ ds. Ochrony Danych Osobowych (BfD)

◦ Ministerstwo Administracji (BVA)

◦ BSI

Do tego nalezy˙ jeszcze dodac´ szereg ﬁrm, których projekty z zakresu infrastruktury oraz aplikacji dostarczaja˛ cennych informacji, szczególnie jesli´ chodzi o wdrozenia˙ systemów ERP i DBMS oraz o wykorzystanie technologii Terminal-Server i platform do zarzadzania˛ systemem. ROZDZIAŁ 2. NAJWAZNIEJSZE˙ ZAGADNIENIA 53

2.5.2 Opinie ekspertów

Oprócz oceny doswiadcze´ n´ i wyników otrzymanych z projektów migracyjnych na ostateczna˛ tres´c´ poradnika miały takze˙ wpływ prace prowadzone przez rózn˙ ych ekspertów, zarówno przedstawicieli społecznosci´ OSS oraz usługodawców, jak i komercyjnych producentów oprogramowania. Polegały one głównie na organizowaniu warsztatów, pozyskiwaniu informacji oraz odpowiedzi na pytania techniczne, jak i aktywnym tworzeniu poradnika i zapewnieniu jego jakosci.´ W procesie szukania odpowiedzi na istniejace˛ pytania, szczególnie owocne okazały sie˛ warsztaty organizowane przy współudziale specjalistów. Objeły˛ one nastepuj˛ ace˛ dziedziny:

◦ Migracja z zastosowaniem Samby w heterogenicznym srodo´ wisku składajac˛ ym sie˛ z Li- nuksa i Windows.

◦ Migracja DBMS, dla której punktem wyjscia´ był MS SQL Server 7, prowadzaca˛ do wdrozenia˙ wolnej bazy danych bad˛ z´ systemu bazodanowego pracujace˛ go pod Linuksem.

◦ Migracja Groupware, dla której punktem wyjscia´ był Exchange 5.5 z uwzglednieniem˛ pracy w srodo´ wiskach heterogenicznych i dalszego wykorzystywania MS Outlook.

◦ Migracja na desktopach koncentrujaca˛ sie˛ na zastapieniu˛ pakietu MS Office (Office 97/2000) oprogramowaniem OpenOffice / StarOffice) oraz na zwiazan˛ ym z tym przejeciem˛ dotychczas zgromadzonych szablonów, plików, makr i skryptów.

◦ Wdrozenie˙ usług katalogowych, miedzy innymi wykorzystanie usług katalogowych OpenL- DAP, jako oprogramowania Open Source, takze˙ w połaczeniu˛ z Active Directory w systemach heterogenicznych.

◦ Wykorzystanie WiBe21, jako podstawy do oceny opłacalnosci´ planowanej migracji. Rozdział 3

Techniczne opisy migracji

3.1 Wprowadzenie

W niniejszym rozdziale dokładniejszej ocenie technicznej poddane zostały poszczególne produkty, rozwiazania˛ i usługi wchodzace˛ w skład srodo´ wisk informatycznych przedstawionych na rysunkach w rozdziale 2. Ocenione zostały:

usługi infrastrukturalne

◦ składowanie plików

◦ drukowanie

◦ autoryzacja

◦ usługi sieciowe

Middleware i składniki integrujace˛

◦ usługi katalogowe

◦ Component Object Models

◦ platformy dla Distributed Component Object Model i technologii Web-Services

◦ XML

54 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 55

Serwery ◦ Groupware i Messaging

◦ serwery baz danych

◦ serwery WWW

◦ usługi specjalne

Aplikacje desktopowe wraz z pakietem Ofﬁce Oceny skupiaja˛ sie˛ na technicznych mozliwo˙ sciach´ przejscia´ od poszczególnych produktów ﬁrmy Microsoft do adekwatnych rozwiaza˛ n´ OSS lub COLS. W oparciu o przedstawione w rozdziale 2.1 składniki infrastruktury Windows, przeprowadzona została ich dokładna analiza:

Ustalenie sytuacji wyjsciowej´ ◦ Z jakich wazn˙ ych funkcji mozna˙ korzystac?´

◦ Jakie interfejsy sa˛ bad˛ z´ powinny zostac´ wykorzystane?

◦ Jakie szczególne zachowanie programów zauwazono˙ podczas pracy?

Z jakich alternatywnych rozwiaza˛ n´ OSS bad˛ z´ COLS mozna˙ korzystac?´ ◦ Na czym polegaja˛ róznice˙ w działaniu?

◦ Czy spełnione sa˛ krytyczne wymagania?

◦ Jakie interfejsy sa,˛ wzglednie˛ musza˛ byc´ obsługiwane?

◦ Co nalezy˙ wzia˛c´ pod uwage˛ przy planowaniu migracji, co moze˙ stanowic´ problem i jak rozwiazywa˛ c´ problemy?

◦ Czy istnieje wiele alternatywnych rozwiaza˛ n?´ Dla kogo, ewentualnie w jakim celu korzystac´ z danego alternatywnego rozwiazania?˛

◦ Jak mozna˙ zintegrowac´ alternatywne rozwiazania˛ z systemami heterogenicznymi. Jesli´ jest to konieczne, jak wyglada˛ ich współpraca, szczególnie z systemem Microsoft, kompatybilnos´c?´

◦ Jaki wpływ na tego typu integracje˛ maja˛ przyszłe kierunki rozwoju oprogramowania Mi- crosoft? ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 56

Na czym polega potencjał kontynuacyjnego wykorzystywania produktów Microsoft?

◦ Z jakich dodatkowych funkcji mozna˙ korzystac?´

◦ Na czym polegaja˛ najistotniejsze zmiany?

◦ Czy nowosci´ oraz ewentualne modyﬁkacje spełniaja˛ najwazniejsze˙ wymagania?

◦ Czego nalezy˙ przestrzegac,´ aby zachowac´ niezalezno˙ sci´ systemów?

Wszystkie uwagi koncz´ a˛sie˛ z reguły krótka˛ocena.˛ W przypadku wiekszej˛ ilosci´ alternatywnych rozwiaza˛ n,´ jesli´ ma to sens, komentowane sa˛ takze˙ porównywalne rozwiazania.˛

3.2 Zarzadzanie˛ plikami

3.2.1 Przeglad˛

W wyniku przeprowadzenia szczegółowej technicznej oceny technologii zarzadzania˛ plikami mozna˙ stwierdzic,´ co nastepuje:˛ W przypadku bezposrednie´ go zastapienia˛ serwerów Windows NT przechowujac˛ ych dane, przy zachowaniu stacji roboczych z Windows, srodo´ wisko Open Source ma w pierwszym rze-˛ dzie do zaoferowania serwer Samba. Jego funkcjonalnosć´ podczas obsługi windowsowych stacji roboczych prezentuje sie˛ dosć´ podobnie, jak serwer NT. Dodatkowo Samba jest stale rozwijana nie tylko przez społecznosć´ Open Source, lecz takze˙ przez rosnac˛ a˛ ilosć´ producentów z branzy˙ informatycznej. W zalezno˙ sci´ od zakresu migracji stacji roboczych na Linuksa, w kontekscie´ zarzadzania˛ plikami mozna˙ takze˙ rozwazy˙ c´ alternatywne technologie takie jak NFS i AFS. Sa˛ one rozpowszechnione w sieciach uniksowych, jednak by umozliwi˙ c´ ich integracje˛ z windowsowymi stacjami roboczymi konieczne jest zainstalowanie po stronie klientów specjalnego oprogramowania. Klient NFS dostepn˛ y jest miedzy˛ innymi w Microsoft Windows Services for UNIX (SFU 3.0), natomiast klient AFS jest nieodpłatny i dostepn˛ y jako oprogramowanie Open Source na stronie http://OpenAFS.org OpenAFS.org. Jednakze,˙ by móc zastosowac´ klienty NFS albo AFS w srodo´ wisku windowsowych stacji roboczych, trzeba wprowadzic´ daleko idace,˛ koncepcyjne zmiany, w porównaniu z sytuacja,˛ gdy zarzadzanie˛ plikami odbywa sie˛ z wykorzystaniem Windows NT. Jesli´ podczas modernizacji infrastruktury informatycznej tworzonej w ramach projektu migracyjnego wazn˙ a˛role˛ odgrywa metoda zapewnienia bezpieczenstwa´ za pomoca˛Kerberos, która ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 57

lezy˙ takze˙ u podstaw Active Directory w Windows 2000, wówczas w przypadku kontynuacyjnego korzystania z produktów Windows po stronie klientów, nalezy˙ zmierzac´ w kierunku zastosowania OpenAFS jako alternatywy dla Win2000 jako serwera plików. Do fizycznego zapisywania danych na systemach dyskowych własciwych´ serwerów nadaja˛ sie˛ m.in. systemy plików XFS i EXT3. Obydwa systemy obsługuja˛journaling, kwotowanie oraz nadawanie praw dostepu˛ na poziomie plików i katalogów. Zarówno XFS, jak i EXT3 obsługuja˛ rozszerzone atrybuty plików oraz listy kontroli dostepu˛ POSIX-ACL umozliwiaj˙ ace˛ przyznawanie uprawnien.´ Podczas odwzorowywania Windows-ACL na POSIX-ACL nalezy˙ uwzgledni˛ c´ to, ze˙ straci sie˛ dokładnosć,´ z jaka˛ mozna˙ definiowac´ uprawnienia pod Windows. Nalezy˙ takze˙ sprawdzic,´ jaki wpływ ograniczenia te maja˛ w pojedynczym przypadku oraz czy mozna˙ je zaakceptowac.´

3.2.2 Windows NT 4

3.2.2.1 Wymagania odnosnie´ funkcjonalnosci´

Generalny zakres funkcjonalnosci´ zarzadzania˛ plikami w sieci polega na:

◦ przyjmowaniu (zapisywanie) i dostarczaniu (czytanie) plików

◦ budowaniu i prezentowaniu struktury katalogów

◦ administrowaniu i prezentowaniu meta danych dla katalogów i plików

◦ zmienianiu praw dostepu˛ i ograniczen´ dostepu˛ dla katalogów i plików

◦ blokowaniu dostepu˛ do plików w przypadku konkurencyjnego dostepu˛

Wykorzystywanie Windows NT File Services słuzy˙ w wiekszo˛ sci´ srodo´ wisk do realizacji naste-˛ pujac˛ ych celów:

◦ składowanie plików uzytko˙ wników (katalogi domowe)

◦ składowanie proﬁlów opartych na serwerach, jesli´ na stacjach klienckich trzeba zoptymalizowac´ obsługe˛ mobilnych uzytko˙ wników (roaming user)

◦ składowanie plików nalez˙ac˛ ych do okreslon´ ych grup (katalogi grup), z których moga˛ korzystac´ tylko niektórzy uzytko˙ wnicy (np. z jednego działu) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 58

◦ składowanie plików w bazach danych, do których jednoczesny dostep˛ powinno miec´ wielu uzytko˙ wników (np. bazy danych MS Access z oddzielnym frontendem)

◦ składowanie plików programów (pliki *.exe, *.dll etc. danej aplikacji) w celu unikniecia˛ przechowywania plików na komputerze klienckim.

◦ składowanie systemów baz danych oferujac˛ ych mozliwo˙ s´c´ umieszczania danych uzytko-˙ wych na innym serwerze pod scie´ zk˙ a˛ UNC.

Opisane tu cele wykorzystania, w praktyce bardzo czesto˛ zwiazane˛ sa˛ z rózn˙ ymi technicznymi, konkretnymi wymaganiami, które wyszczególnione zostały w odpowiednich miejscach w kolejnych rozdziałach.

3.2.2.2 System plików NTFS4

System plików NTFS4 jest podstawa˛ składowania i zarzadzania˛ plikami w Windows NT4.

Własciwo´ sci´ NTFS4 posiada miedzy˛ innymi nastepuj˛ ace˛ własciwo´ sci:´

Kazdy˙ katalog i kazdy˙ plik dysponuje tak zwana˛ Access Control List (ACL), która jest zapisywana na pliku bad˛ z´ katalogu. W ACL zapisane sa˛ tak zwane Access Control Entries (ACE), w którym zapisane sa˛ SID kont grup albo uzytko˙ wników oraz ich uprawnienia. Dlatego poprzez ACL mozna˙ przydzielac´ prawa dostepu˛ w sposób szczegółowy i zintegrowany. ACL nalezy˙ podzielic´ na SACL (System Access Control List) oraz DACL (Discretionary Access Control List). W DACL składowane sa˛SIDs grup i uzytko˙ wników, którym wolno albo nie wolno miec´ dostepu˛ do obiektu. W SACL ustala sie,˛ w jaki sposób podsystem bezpieczenstwa´ kontroluje dostep˛ do obiektu. NTFS4 w zasadzie nie obsługuje dziedziczenia; tylko przy tworzeniu nowego pliku prawa katalogu kopiowane sa˛ do ACL danego pliku. Gdy prawa do katalogu sie˛ zmienia,˛ wówczas trzeba osobno wywołac´ przepisanie ich do ACLi mieszczac˛ ych sie˛ w nim plików. Nalezy˙ zwrócic´ uwage˛ na jedna˛szczególna˛ceche:˛ plik znajdujac˛ y sie˛ na scie´ zce˙ UNC \\serwer\zezwolenie-udostepnienie\katalog\podkatalog˛ , moze˙ byc´ czytany przez uzytko˙ wnika, mimo ze˙ katalog „katalog“ tego zakazuje, jednak katalog „podkatalog“ na to zezwala. Nie ma ograniczenia długosci´ scie´ zek.˙ Obsługiwane sa˛ nazwy plików składajace˛ sie˛ maksymalnie z 256 znaków. Teoretycznie znaki te moga˛ byc´ zgodne z Unicode (16 bitów), jednak ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 59

istnieje kilka wyjatków˛ (np. *, \). Dla kazde˙ go katalogu i kazde˙ go pliku zapisywany jest skrót nazwy, który odpowiada konwencji 8.3 i jest automatycznie generowany przez system operacyjny. O ile podczas zapisywania rozrózniana˙ jest pisownia wielka˛ i mała˛ litera,˛ o tyle w przypadku dostepu˛ do pliku nie jest to reguła.˛ Kazdy˙ katalog i kazdy˙ plik dysponuje atrybutami w formie flag (chroniony przed zapisem, archiwalny, systemowy, ukryty i spakowany) oraz czasy: utworzenia, ostatniej zmiany i ostatniego dostepu.˛ Stopien´ kompresji silnie zalezy˙ od zawartosci.´ NTFS obsługuje technologie˛ Multiple Streams, jednak funkcja ta jest dosć´ rzadko wykorzystywana. Multiple Streams musza˛ byc´ wówczas obsługiwane przez kazd˙ a˛ aplikacje,˛ wzglednie˛ byc´ w niej zaprogramowane. Multiple Streams umozliwiaj˙ a˛ miedzy˛ innymi zapisywanie Reso- urce Fork plików Macintosh. Pocza˛wszy od Service Pack 4 w ramach NTFS obsługiwane sa˛ kwoty. Ich przydzielanie i kontrola opiera sie˛ na cechach uzytko˙ wnika i obejmuje cały wolumen (naped˛ logiczny serwera plików). Wskutek tych technicznych ograniczen´ nalezy˙ uznac´ ich zastosowanie w istniejac˛ ych srodo´ wiskach raczej za przypadek szczególny niz˙ za regułe.˛ Maksymalna wielkosci´ plików zarzadzan˛ ych w ramach NTFS4 wynosi 2TB (terabajty). Po- nadto jest ona ograniczona wielkosci´ a˛napedu˛ logicznego. Naped˛ logiczny moze˙ pomiesci´ c´ maksymalnie 2 TB (teoretycznie 16 exabajtów). Rzeczywista ilosć´ danych netto zalezy˙ od wielkosci´ klastra, który został zastosowany podczas formatowania. Ilosć´ plików ograniczona jest do 232 - 1. NTFS umozliwia˙ kontrole˛ zrealizowanych dostepów˛ , wzglednie˛ prób dostepu.˛ W ten sposób mozna,˙ np. zdiagnozowac´ powtarzajace˛ sie,˛ niechciane usuwanie plików. Nosniki´ danych sformatowane dla NTFS sa˛ podczas pracy defragmentowane. W Windows NT4 nie jest wykonywana automatyczna korekta (samoleczenie). Do tego celu nalezy˙ zastosowac´ produkty innych firm.

System uprawnien´ w NTFS Windows zna w sumie 13 uprawnien,´ które moga˛ zostac´ przyznane lub odebrane uzytko˙ wnikowi bad˛ z´ grupie dla obiektu (plik albo katalog) znajdujace˛ go sie˛ w systemie plików.

◦ przeszukiwanie katalogu / wykonywanie pliku

◦ wylistowanie katalogu / czytanie danych

◦ czytanie atrybutów

◦ czytanie rozszerzonych atrybutów ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 60

◦ tworzenie plików / zapisywanie danych

◦ tworzenie katalogów / przyłaczanie˛ danych

◦ przypisywanie atrybutów

◦ przypisywanie rozszerzonych atrybutów

◦ usuwanie podkatalogów / plików

◦ usuwanie

◦ czytanie uprawnien´

◦ zmiana uprawnien´

◦ przejmowanie uprawnien´ własciciela´

Zmiany w prawach dostepu˛ przeprowadzane sa˛ poprzez okno dialogowe Properties i zakładke˛ Security settings. Aby zmniejszyc´ dla przecietne˛ go uzytko˙ wnika stopien´ skomplikowania systemu bezpieczenstwa´ złozone˙ go z 13 sci´ sle´ spokrewnionych praw dostepu,˛ w zakładce tej zde- finiowano gotowe składniki, tak zwane grupy uprawnien,´ które stanowia˛ podstawe˛ wyboru sen- sownej kombinacji pojedynczych uprawnien.´ Dla plików istnieje 5 a dla katalogów szesć´ takich zestawów, które kazdorazo˙ wo mozna˙ uaktywnic´ bad˛ z´ zignorowac.´ Dopiero w oknie dialogowym Privilege entry, które mozna˙ wyswietli´ c´ w ramach Security settings naciskajac˛ kolejne przyciski Extended/Display/Edit, pojawi sie˛ wszystkich 13 uprawnien.´ W dodatku uzyskanie podgladu˛ grup uprawnien´ poprzez Security settings jest bardzo trudne, gdyz˙ ich prezentacja moze˙ bardzo szybko skonczy´ c´ sie˛ komunikatem braku praw dostepu,˛ mimo ze˙ w rzeczywistosci´ posiadamy odpowiednie uprawnienia. I tak, np. z pełnego dostepu,˛ gdy nie jest mozliwe˙ jedynie przypisywanie rozszerzonych atrybutów, powstaje w prostej prezentacji w Security settings obraz profilu uprawnien,´ który zezwala tylko na odczyt i wykonywanie. Poniz-˙ sza tabela pokazuje, jakie kombinacje uprawnien´ tworza˛ poszczególne grupy uprawnien.´ Jesli´ zaledwie jedno uprawnienie z całego przedstawionego ponizej˙ zestawu nie bedzie˛ zaznaczone, wówczas odpowiedni dla konkretnej grupy uprawnien´ checkbox nie zostanie odhaczony.

WINDOWS - GRUPY UPRAWNIEN´ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 61

Pełny Zmiana Odczyt & Wylisto- Odczyt Zapis dostep˛ wykonywanie wanie zawartosci´ katalogu przeszukiwanie katalogu / X X X X wykonywanie pliku wylistowanie katalogów / X X X X X czytanie danych czytanie atrybutów X X X X X czytanie rozszerzonych X X X X X atrybutów tworzenie plików / X X X zapisywanie danych tworzenie katalogów / X X X przyłaczanie˛ danych przypisywanie atrybutów X X X przypisywanie rozsze- X X X rzonych atrybutów usuwanie podkatalogów / X plików usuwanie X X czytanie uprawnien´ X X X X X X zmiana uprawnien´ X

Tablica 3.2: Windows - grupy uprawnien´

Z powodu opisanej niespójnosci,´ w dalszej cze˛sci´ oceniany bedzie˛ jedynie rozszerzony widok okna dialogowego Privilege entry.

System atrybutów Dodatkowo, oprócz administrowania uprawnieniami do plików i katalogów, istnieje jeszcze mozliwo˙ s´c´ zarzadzania˛ tak zwanymi atrybutami oraz rozszerzonymi atrybutami. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 62

NAZWA BIT ZNACZENIE Plik został zmieniony od ostatniego nada- Archiwalny A nie atrybutu. Chroniony przed R Plik jest chroniony przed zapisem. zapisem Ukryty H Plik nie jest pokazywany. Systemowy S Plik jest zarezerwowany dla systemu. Spakowany C Zapisany plik / katalog jest spakowany. Zaszyfrowany E Zapisany plik / katalog jest zaszyfrowany.

Tablica 3.4: Atrybuty w Windows

Kontrola Windows umozliwia˙ rozległa˛kontrole˛ nad plikami i katalogami. Dzieki˛ temu mozna˙ nadzorowac´ wszystkie uprawnienia pojedynczego uzytko˙ wnika lub grupy. Otrzymane w ten sposób informacje zapisywane sa˛ w protokole bezpieczenstwa´ kontrolera domen, wzglednie˛ na poszczególnym komputerze z Windows 2000, o ile w systemie zezwoli sie˛ na tego typu kontrole.˛

3.2.2.3 Ustawianie praw dostepu˛

Ustawianie praw dostepu˛ do plików lub katalogów znajdujac˛ ych sie˛ w sieci realizowane jest w srodo´ wisku Windows NT za pomoca˛ dwóch mechanizmów, którymi sa:˛

◦ odblokowanie dostepu˛ do katalogu (share)

oraz

◦ prawa dostepu˛ NTFS

Aby miec´ dostep˛ do pliku przez siec,´ nalezy˙ otworzyc´ droge˛ do nadrzedne˛ go katalogu. Umoz-˙ liwia to odpowiedni wpis ACL umieszczony w rejestrze. Prawa dostepu˛ do takich zasobów sa˛ stopniowane:

◦ prawo do odczytu ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 63

◦ prawo do zmian oraz

◦ pełny dostep˛

Powyzsze˙ uprawnienia sa˛ absolutne, tzn. moga˛ one ograniczac´ podlegajace˛ im uprawnienia NTFS. Przykład: prawo do odczytu na poziomie zasobu uniemozliwia˙ zapisywanie równiez˙ wtedy, gdy pozwoliłyby na to uprawnienia NTFS. W srodo´ wiskach Windows NT uprawnieniom (wytycznym dotyczac˛ ym uprawnien´ uzytko˙ w- nika) nalezy˙ poswi´ eci˛ c´ szczególna˛uwage,˛ poniewaz˙ moga˛one miec´ znaczenie dla File Services, np. przy „przejmowaniu praw własnosci´ do plików i obiektów“ oraz „zabezpieczaniu plików i katalogów“.

3.2.2.4 Uzytk˙ ownicy i znaczenie grup

Kazdy˙ katalog i kazdy˙ plik przyporzadko˛ wany jest jednemu włascicielo´ wi, którym moze˙ byc´ zarówno grupa, jak i konto uzytko˙ wnika. W normalnym przypadku uzytko˙ wnik, który tworzy dany element, jest jego włascicielem.´ Jesli´ uzytko˙ wnik nalezy˙ do grupy administratora, wówczas ona staje sie˛ włascicielem.´ Przy ustawianiu praw dostepu˛ w srodo´ wisku Windows NT systemowo preferowane jest przyznawanie uprawnien´ grupom. Nadawanie praw kontom poszczególnych uzytko˙ wników powinno odbywac´ sie˛ w ramach systemów plików własciwych´ dla uzytko˙ wnika. Wewnatrz˛ srodo´ wiska Windows NT nalezy˙ wyrózni˙ c´ nastepuj˛ ace˛ grupy:

◦ globalne

◦ lokalne na Member Servers

◦ lokalne na Domain Controllers

Lokalne grupy na kontrolerach domen rózni˙ a˛ sie˛ od tych na Member Servers, gdyz˙ maja˛ one ten sam SID na wszystkich kontrolerach domen danej domeny. Lokalne grupy na Member Servers wolno zagniezd˙ za˙ c´ (Group Nesting) z nastepuj˛ ac˛ ymi grupami:

◦ globalnymi grupami własnej domeny

albo ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 64

◦ globalnymi grupami domen, którym ufa własna domena

Globalne grupy maja˛ konta uzytko˙ wników tylko jako członkowie. W srodo´ wisku domen Windows NT znane sa˛ dwa rózne˙ „klasyczne“ sposoby ustawiania praw dostepu:˛

◦ metoda B-G-L-R Uzytko˙ wnik jest członkiem globalnej grupy. Z kolei ona jest członkiem lokalnej grupy serwera plików. Uprawnienia NTFS ustawione sa˛na ﬁle resource jedynie dla tej lokalnej grupy (patrz rys. 3.1).

◦ metoda B-G-R Uzytko˙ wnik jest członkiem globalnej grupy. Uprawnienia NTFS ustawione sa˛na ﬁle resource jedynie dla tej grupy (patrz rys. 3.2).

Rysunek 3.1: Metoda B-G-L-R ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 65

Rysunek 3.2: Metoda B-G-R

Obydwie metody funkcjonuja˛nie zagrazaj˙ ac˛ bezpieczenstwu´ tylko wtedy, gdy przyporzadko-˛ wanie zasobów oraz lokalnej bad˛ z´ globalnej grupy jest jednoznaczne, czyli gdy grupa przypisana jest wyłacznie˛ dla danego zasobu. Jesli´ File Services realizowane sa˛ przez klaster, wówczas metoda B-G-L-R ma te˛ wade,˛ ze˙ lokalne grupy na serwerach wezło˛ wych nie moga˛ posiadac´ identycznego SIDa. Zaradzic´ temu mozna˙ jedynie konﬁgurujac˛ wezły˛ jako kontrolery domeny albo stosujac˛ metode˛ B-G-R.

3.2.2.5 Narzedzia˛

Do edycji plików i katalogów oraz praw dostepu˛ do nich Windows NT oferuje dos´c´ ograniczony wybór narzedzi:˛

◦ działajace˛ w srodo´ wisku graﬁcznym

– NT Explorer (explorer.exe) – menedzer˙ plików (winﬁle.exe) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 66

◦ działajace˛ z linii polecen´

– cacls – Resource Kit Tools: xcacls, scopy etc.

Dostarczane narzedzia˛ nie oferuja˛ na ogół pełnego, lecz tylko dedykowany zakres funkcji. Najlepszym tego przykładem jest NT Explorer, który nie daje mozliwo˙ sci´ tworzenia uzytko˙ w- nika (jedynie przejecie˛ uzytko˙ wnika) ani tez˙ kopiowania List Kontroli Dostepu˛ (ACLs). Dlatego nalezy˙ załozy˙ c,´ ze˙ administrowanie srodo´ wiskiem NT musi byc´ prowadzone z wykorzystaniem narzedzi˛ dostarczanych przez innych producentów albo za pomoca˛własnych skryptów (np. napisanych w jezyku˛ Perl), których zadaniem jest uproszczenie administrowania albo wykonywanie bardzo specjalnych zadan.´ Skutkiem tego moze˙ byc´ wyswietlanie´ przez NT Explorer struktury uprawnien,´ która bedzie˛ rózni˙ c´ sie˛ od rzeczywiscie´ nadanych praw dostepu.˛

3.2.2.6 Protokoły sieciowe

Komunikacja poprzez siec´ z wykorzystaniem Windows NT File Servers moze˙ opierac´ sie˛ na rózn˙ ych protokołach sieciowych:

◦ TCP / IP

◦ NetBEUI

◦ SPX / IPX

◦ AppleTalk

Obecnos´c´ TCP / IP, NetBEUI oraz SPX / IPX w jednym istniejac˛ ym srodo´ wisku NT nie jest nieprawdopodobne. Zasadniczo przyjmuje sie,˛ ze˙ przyszłoscio´ wym i jedynym wazn˙ ym protoko- łem, który nalezy˙ wspierac´ jest TCP / IP. Z tego powodu w dalszej cze˛sci´ nie bed˛ a˛oceniane takie usługi, jak „Gateway Services for NetWare“ oraz „File and Print Services for Macintosh“. Z punktu widzenia File Services

◦ SMB (Server Message Block) przez NetBT (NetBIOS over TCP/IP) mozna˙ uznac´ za standardowy sposób komunikacji na portach 137/UDP/TCP (nbname), 138/UDP (nbdatagram), 139/TCP (nbsession). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 67

3.2.2.7 Zestawianie połaczenia˛

Z reguły uzytko˙ wnikowi otwiera sie˛ dostep˛ do zasobów zgromadzonych na serwerach plików, w postaci liter przypisanych do napedów˛ . Czesto˛ jest to realizowane poprzez skrypt logowania. Ponadto uzytko˙ wnik ma mozliwo˙ s´c´ „surfowania“ po sieci Windows, tzn. moze˙ klikajac˛ ła-˛ czyc´ sie˛ z zasobami, które sa˛ dla niego wyswietlane´ przez serwer plików za posrednictwem´ napedu˛ sieciowego albo otwierac´ je bezposrednio.´

3.2.2.8 Migracja - szczegóły robocze

Ponizej˙ zostały wypunktowane szczegóły, które moga˛ byc´ krytycznymi elementami migracji.

◦ Niekiedy z punktu widzenia składowania plików uzytko˙ wnika (katalogi domowe) wymagane jest, zeby˙ umieszczane tam dane mogły byc´ czytane tylko przez samego uzytko˙ wnika oraz system operacyjny (np. w celu ochrony przed wirusami). W Windows NT istnieje mozliwo˙ s´c´ skorzystania z konta systemowego.

◦ Składowanie proﬁlów opartych na serwerze podlega podczas odpisywania (writing back) skomplikowanemu procesowi po stronie klienta. Bezbłedn˛ a˛ komunikacje˛ oraz własciw´ a˛ strukture˛ uprawnien´ nalezy˙ zapewnic´ szczególnie w srodo´ wiskach Terminal Server, które bezwzglednie˛ wymagaja˛ proﬁlów opartych na serwerze.

◦ Do plików przypisanych do grup moze˙ miec´ jednoczesny dostep˛ wielu uzytko˙ wników. Wymagane jest przy tym, aby uzytko˙ wnik był informowany o współuzytko˙ waniu danych zasobów. Przykład: uzytko˙ wnik, który, jako drugi, otwiera plik *.doc (Word), otrzymuje komunikat, ze˙ uzytko˙ wnik 1 juz˙ wczesniej´ otworzył ten plik, a on moze˙ otwierac´ dany plik w trybie tylko do odczytu.

◦ Podczas składowania baz danych opartych na plikach, takze˙ plikach *.pst (katalogi osobiste w programie Outlook), musi bezbłednie˛ działac´ funkcja locking.

Czesto˛ nie ma mozliwo˙ sci´ zapewnienia składowania plików programów w sposób całkowicie chroniac˛ y przed zapisem. Wymagane jest w takim przypadku bardzo szczegółowe stopniowanie uprawnien´ (np. zapisywanie, ale nie usuwanie konkretnego pliku).

◦ Tylko nieliczne aplikacje obsługujace˛ systemy baz danych (np. MS SQL) oferuja˛ mozli-˙ wos´c,´ składowania danych uzytko˙ wych na innym serwerze pod scie´ zk˙ a˛ UNC, z tym ze˙ w takim przypadku szczególnie wazne˙ jest zapewnienie bezbłednej˛ komunikacji oraz skła- dowania plików, co wymaga zezwolenia / opinii producenta aplikacji. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 68

3.2.2.9 Tematy pokrewne

File Services realizowane w Windows NT przez produkty innych producentów musza,˛ oprócz składowania plików, spełniac´ w istniejac˛ ych srodo´ wiskach jeszcze inne wazne˙ wymagania.

◦ Ochrona przed wirusami: Ochrona przed wirusami realizowana jest najcze˛sciej´ przez lokalna˛instalacje˛ skanera antywirusowego na samym serwerze plików. Dzieki˛ usłudze zain- stalowanej lokalnie, skanowanie pliku jest mozliwe˙ dopiero przy próbie uzyskania dostepu˛ do niego. Z takiego rozwiazania˛ korzysta wielu producentów oprogramowania antywirusowego. Alternatywna˛mozliwo˙ sci´ a˛jest skanowanie napedów˛ serwera plików poprzez siec´ z innego komputera. Jednak wady takiego rozwiazania˛ sa˛ oczywiste; przejawiaja˛ sie˛ one w postaci powstajace˛ go obcia˛zenia˙ i czasowego opóznienia.´

◦ Kwotowanie: Wbudowane w Windows NT kwotowanie z reguły nie jest wykorzystywane. Aby zakładac´ kwoty na zasoby uzytko˙ wników lub grup, konieczne jest zastosowanie oprogramowania innych producentów.

◦ Zabezpieczanie danych: Wykorzystanie narzedzia˛ NTBACKUP jest raczej rzadko spoty- kane. Z reguły serwery plików działajace˛ w Windows NT sa˛ łaczone˛ w system zabezpieczania danych poprzez zainstalowanie odpowiedniego składnika (agent), który centralnie i jednostkowo zabezpiecza inne systemy docelowe (bazy danych, poczta). W zwiazku˛ z tym wazn˙ ym kryterium jest czas odtwarzania zasobów podczas Desaster Recovery. Cieka- wostka˛ jest fakt, ze˙ za pomoca˛ NTBACKUP mozna˙ zabezpieczac´ takze˙ te dane, które w innym przypadku nie moga˛ byc´ czytane przez wykonujace˛ go.

◦ Archiwizacja: Czesto˛ w ramach zabezpieczania danych wykonywana jest trwała archiwizacja (revision-safe). Ponadto niektóre produkty innych producentów daja˛ mozliwo˙ s´c,´ umieszczania rzadko uzywan˙ ych plików na mniej kosztownych systemach / mediach.

3.2.3 Migracja zastepuj˛ aca˛

3.2.3.1 Wprowadzenie

Biorac˛ pod uwage˛ kwestie˛ zarzadzania˛ plikami, w niniejszym poradniku wyszlismy´ z załozenia,˙ ze˙ centralne miejsce składowania plików znajduje sie˛ przynajmniej na jednym serwerze NT i ze˙ obecnie dostep˛ do plików maja˛klienty windowsowe. Podczas poszukiwan´ odmiennych dróg dla ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 69

przeprowadzenia migracji na produkty inne niz˙ ﬁrmy Microsoft, trzeba rozrózni˙ c´ dwa scenariusze owej migracji. Pierwsza opcja dotyczyłaby tylko rozwiaza˛ n´ stosowanych po stronie serwera, druga natomiast przypadku, w którym inna˛ platforme˛ wprowadza sie˛ równiez˙ na stacje robocze. W przypadku migracji na serwerach trzeba, z uwagi na sposób zarzadzania˛ plikami, wyrózni˙ c´ dwie podstawowe płaszczyzny. Z jednej strony kazdy˙ serwer posiada lokalny system plików, w którym administruje on wszystkimi plikami. Z drugiej strony eksportowany jest przynajmniej jeden podzbiór tych plików poprzez serwer z odpowiednim protokołem sieciowym. Zastapienie˛ Windows NT jako serwera plików wymaga w pierwszej kolejnosci´ przejecia˛ istniejac˛ ych w starym systemie danych i programów przez nowy system. Wia˛ze˙ sie˛ z tym takze˙ odwzorowanie systemu uprawnien´ do autoryzacji dostepu˛ do plików i katalogów oraz dostosowanie pracy systemu, np. sposobu zabezpieczania danych. W drugiej kolejnosci´ chodzi o odtworzenie dotychczasowej funkcjonalnosci,´ bad˛ z´ to z wykorzystaniem istniejac˛ ych stacji klienckich, bad˛ z´ tez˙ przez stworzenie nowej architektury klientów. Ten drugi etap tworzy własciwy´ rdzen´ infrastruktury składowania plików. W centrum oceny znajduja˛sie˛ w szczególnosci´ takie zagadnienia, jak „prawa dostepu˛ do poziomu plików i katalogów“ oraz „podstawowe funkcje składowania plików“. Jesli´ chodzi o zastapienie˛ serwera NT 4.0 w obszarze zarzadzania˛ plikami, pod uwage˛ nalezy˙ wzia˛c´ przede wszystkim nastepuj˛ ace˛ rozwiazania:˛

◦ UNIX/Linux z Samba˛ - odtworzenie składowania plików przez serwer NT

◦ UNIX/Linux z NFS - sieciowe zarzadzanie˛ plikami, tradycyjne dla sieci uniksowych

◦ UNIX/Linux z OpenAFS - sieciowy system plików udostepnion˛ y przez IBM, z autoryzacja˛ Kerberos

Alternatywne sieciowe systemy zarzadzania˛ plikami, które nie wykroczyły poza stadium uni- wersyteckich prac badawczych albo opieraja˛ sie˛ w całosci´ bad˛ z´ cze˛scio´ wo na oprogramowaniu własnoscio´ wym, nie sa˛ oceniane.

3.2.3.2 Generalne porównanie zakresu funkcji poszczególnych serwerów plików

Przy indywidualnym przegladzie˛ alternatywnych sieciowych systemów zarzadzania˛ plikami nalezy˙ takze˙ uwzgledni˛ c´ własciwo´ sci´ podstawowego systemu plików, na którym pracuje serwer. W przypadku serwerów opartych na Linuksie podstawa˛ dla niniejszego porównania jest system plików XFS albo EXT3. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 70

FUNKCJA WINNT WIN2K SAMBA NFS AFS klient windowsowy bez dodatkowego X X X oprogramowania długosć´ nazwy 256 256 256 256 256 pliku (znaki) zestaw znaków Unicode Unicode Unicode ISO-Latin ISO-Latin dla nazwy pliku wyswietlanie´ wielkich X X X X X i małych liter rozróznianie˙ wielkich X X i małych liter kwoty dyskowe X X X X szyfrowanie EFS file-wise po stronie klienta kompresja X X 1 2 maksymalna wielkosć´3 2 TB 2TB 2 TB 9EB4 2GB pliku maksymalna długosć´ dowolna dowolna dowolna dowolna dowolna scie´ zki˙ change journal X propagacja zezwolen´ X w Active Directory rozłozon˙ y system DFS DFS standard standard plików replikacja plików FRS rsync rsync rsync X X X X journaling przez system przez system przez system plików plików plików

1Dostepna˛ jako łata, np. dla systemów plików ext2 i ext3 2Dostepna˛ jako łata, np. dla systemów plików ext2 i ext3 3TB - terabajt 1012, PB - petabajt 1015 EB - exabajt 1018 4NFSv3 x systemem plików XFS ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 71

DACL NTFS POSIX POSIX AFS SACL NTFS moduł Samby typowa autoryzacja NT / LM AD / NT / LM LDAP, NIS / LDAP Kerberos przez . . . PDC Kerberos gdy członek AD, wersja 4 to Kerberos

Tablica 3.6: Porównanie serwerów plików

W przypadku bezposrednie´ go zastapienia˛ serwera Windows NT jako serwera plików, przy zachowaniu klientów windowsowych, pierwszy wybór w obszarze oprogramowania Open So- urce powinien pasć´ na Sambe.˛ Klient windowsowy odbiera Sambe˛ dokładnie tak, jak gdyby był to serwer NT. Samba jest stale rozwijana, nie tylko przez społecznosć´ Open Source, lecz takze˙ przez coraz wieksz˛ a˛ ilosć´ producentów IT. W zalezno˙ sci´ od zakresu migracji na Linuksa po stronie klienta, w strone˛ centrum ocen alternatywnych rozwiaza˛ n´ przesuwaja˛ sie˛ serwery NFS i AFS. Sa˛ one rozpowszechnione w sieciach uniksowych, jednak by umozliwi˙ c´ ich integracje˛ z windowsowymi stacjami roboczymi konieczne jest zainstalowanie po stronie klientów specjalnego oprogramowania. Klient NFS dostepn˛ y jest miedzy˛ innymi w Microsoft Windows Services for UNIX (SFU 3.0), natomiast klient AFS jest nieodpłatny i dostepn˛ y jako oprogramowanie Open Source na stronie http://OpenAFS.org OpenAFS.org. Jednakze,˙ by móc zastosowac´ klienty NFS albo AFS w srodo´ wisku windowsowych stacji roboczych, trzeba wprowadzic´ daleko idace,˛ koncepcyjne zmiany, w porównaniu z sytuacja,˛ gdy zarzadzanie˛ plikami odbywa sie˛ z wykorzystaniem Windows NT. Jesli´ podczas modernizacji infrastruktury informatycznej tworzonej w ramach projektu migracyjnego wazn˙ a˛role˛ odgrywa metoda zapewnienia bezpieczenstwa´ za pomoca˛Kerberos, która lezy˙ takze˙ u podstaw Active Directory w Windows 2000, wówczas w przypadku kontynuacyjnego korzystania z produktów Windows po stronie klientów, nalezy˙ zmierzac´ w kierunku zastosowania OpenAFS jako alternatywy dla Windows 2000 jako serwera plików.

3.2.3.3 Samba

Realizacje˛ zasadniczo rózn˙ ych opcji, tj. centralnego składowania plików dla klientów windowsowych lub dla heterogenicznego srodo´ wiska klientów, mozna˙ oceniac´ równorzednie.˛ Nie ma powodu, by wykluczyc´ jedno bad˛ z´ drugie rozwiazanie.˛ Jesli´ chodzi o sposób stosowania i administrowania, to wszystkie opcje zwiazane˛ sa,˛ w wiekszym˛ lub mniejszym stopniu, z wprowadze- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 72

niem zmian w administrowaniu i stosowaniu. W rozumieniu konserwatywnej migracji kontynuacyjnej, serwery Samba i W2K oparte na SMB / CIFS spełniaja˛załozenie˙ polegajace˛ na najdalej idac˛ ym zachowaniu istniejac˛ ych rozwiaza˛ n.´ W takich obszarach jak składowanie plików, drukowanie i autoryzacja Samba jest z wielu powodów wzorowana na Windows NT. Z punktu widzenia uzytko˙ wników Samba odpowiada w najwiekszym˛ przyblizeniu˙ serwerowi NT. Z drugiej strony administratorzy widza˛ w niej serwer uniksowy. Obsługe˛ Samby nalezy˙ dostosowac´ do filozofii oraz mozliwo˙ sci´ nowego systemu operacyjnego. W2K, jako nastepca˛ NT niesie z soba,˛ z punktu widzenia uzytko˙ wnika, niemal tyle samo zmian w porównaniu z serwerem NT, co Samba. Jednakze˙ dla administratorów zmiany te sa˛ juz˙ wieksze˛ i obejmuja˛ m.in. wprowadzenie Active Directory ze składnikami DNS, LDAP i Kerberos. To, w jakim stopniu zmiana lub rozwój w jednym bad˛ z´ innym kierunku moga˛ byc´ uznane za uproszczenie czy tez˙ zalete,˛ zalezy˙ ostatecznie od zainteresowanych osób. Migracja na Sambe,˛ Linuksa i Open Source otwiera nowe mozliwo˙ sci´ działania. Oprócz wiekszej˛ swobody oraz odpowiedzialnosci´ za swoje decyzje, administrator „zyskuje“, wraz z wykonaniem kroku w kierunku wyzwolenia sie˛ od narzuconych schematów i Best Practices jednego producenta, takze˙ nowe mozliwo˙ sci´ popełniania błedów˛ . Serwer Samba spełnia, podobnie jak serwer NT, wymagania zwiazane˛ z administrowaniem plikami. Uzytko˙ wnicy klientów windowsowych moga˛ równie dobrze sci´ aga˛ c´ swoje profile oraz skrypty logowania z serwera Samba, jak swoje katalogi domowe lub katalogi grup. Na serwerze Samba mozna˙ równiez˙ składowac´ pliki wykonywalne (*.exe) (i je stamtad˛ uruchamiac),´ takie jak pliki bazy danych Access albo inne pliki z mechanizmami blokujac˛ ymi udostepniane˛ jednoczesnie´ wielu uzytko˙ wnikom. W odróznieniu˙ od serwera NT, Samba wykorzystuje wyłacznie˛ protokół sieciowy TCP / IP. Usługi oparte na protokołach SPX / IPX (Novell) oraz AppleTalk (Apple) realizowane sa˛ przez inne serwery Open Source (Mars i Netatalk), które umozliwiaj˙ a˛ prace˛ na wspólnych danych w srodo´ wisku heterogenicznym. Samba nie oferuje implementacji SMB opartej na protokole NetBEUI, ani tez˙ nie obsługuje NetBIOS przez IPX. Po stronie klienta nadal mozna˙ uzywa˙ c´ narzedzi˛ słuz˙ac˛ ych do edycji plików znajdujac˛ ych sie˛ na serwerze plików i do zarzadzania˛ nimi. W szczególnosci´ mozna˙ w tym celu korzystac´ z programów Explorer i File Manager oraz z cacls, xcacls etc. Pocza˛wszy od Samby 3.0 mozna˙ takze˙ nadal uzywa˙ c´ menedzera˙ uzytko˙ wników. W zasadzie mozliwe˙ jest tez˙ zastosowanie menedzera˙ plików, jednak z powodu zwiazane˛ go z tym odwrotu od przejrzystosci´ konfiguracji serwera ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 73

(smb.conf) jest to niezbyt dobre rozwiazanie.˛ Zestawianie połacze˛ n´ do zasobów nadal, tj. bez wprowadzania zmian, mozliwe˙ jest za pomoca˛ skryptów logowania albo przez surfowanie w otoczeniu sieciowym. System uprawnien´ Samby i Linuksa umozliwia˙ zagwarantowanie uprzywilejowanym procesom, takim jak na przykład, skanerowi antywirusowemu na serwerze, lokalnego dostepu˛ do wszystkich plików w rodzimych katalogach uzytko˙ wników i jednoczesnie´ na zezwolenie na taki dostep˛ wyłacznie˛ samemu uzytko˙ wnikowi poprzez naped˛ sieciowy. Serwer Samba nadaje sie˛ takze˙ do zarzadzania˛ plikami i autoryzacji w srodo´ wiskach z windowsowymi serwerami terminali, z tym ze˙ w takim przypadku nie bedzie˛ on obsługiwał specyficznych dla nich rozszerzen´ obiektowych SAM. Obsługa blokad plików (locking zarówno na poziomie pliku, jak tez˙ w Byte-Range) realizowana jest przez Sambe˛ dokładnie tak, jak przez serwer NT. Oznacza to, ze˙ za pomoca˛ Samby mozliwe˙ jest, tak samo jak w przypadku serwera NT, zarówno współdzielenie plików, jak i korzystanie z baz danych opartych na plikach. System operacyjny GNU/Linux oferuje kwotowanie miejsca na dysku (jak tez˙ innych zaso- bów systemowych) i przenosi te˛ funkcje˛ takze˙ na zasoby zarzadzane˛ przez serwer Samba. W Linuksie, dla potrzeb zabezpieczania danych i dokumentowania wersji / archiwizacji, skorzystac´ mozna˙ z wielu rózn˙ ych narzadzi˛ Open Source. Dodatkowo serwery linuksowe mozna˙ bez problemu zintegrowac´ z rozwiazaniami˛ bezpieczenstwa´ oferowanymi przez wiekszo˛ sć´ dostep-˛ nego na rynku oprogramowania. Wysoka˛ niezawodnosć,´ jaka˛ osiagni˛ eto˛ w NT wraz z wydaniem Enterprise Edition dzieki˛ zastosowaniu klastrów, mozna˙ uzyskac´ takze˙ w Sambie w oparciu o shared SCSI albo SAN z IP Failover. Jesli´ porówna sie˛ niektóre analizy mozliwo˙ sci´ 5 wykonane w ostatnich latach, mozna˙ stwierdzic,´ ze˙ nastapiło˛ znaczne zmniejszenie ograniczen´ funkcjonalnosci´ w zastosowaniach Samby. W przyszłosci´ Samba 3.06 umozliwi˙ budowanie zaufanych połacze˛ n´ pomiedzy˛ domenami Master i Resource, czyli implementacje˛ rozwiaza˛ n´ z zakresu obsługi domen stosowanych w Windows NT. Wraz z wersja˛ 3.0 powstanie takze˙ mozliwo˙ sć,´ wykorzystania menedzera˙ uzytko˙ wników do zarzadzania˛ uzytko˙ wnikami, np. w ten sposób bedzie˛ mozna˙ zakładac´ konta nowym uzyt-˙ kownikom. Nadal nie bedzie˛ mozliwo˙ sci´ replikacji pomiedzy˛ kontrolerem domeny Windows i kontrolerem domeny Samby, czyli wewnatrz˛ jednej domeny bedzie˛ mozna˙ uzywa˙ c´ samego kontrolera domeny Windows bad˛ z´ wyłacznie˛ kontrolera domeny Samby. W przypadku, gdy wymagana bedzie˛ integracja usług swiadczon´ ych przez serwer windowsowy z domena˛ Samby, bedzie˛

5Zwłaszcza analize˛ wykonana˛ dla BMI w 2001 r. 6Obecnie dostepna˛ jest wersja beta - jednak została juz˙ ona wdrozona˙ i działa w Federalnym Urzedzie˛ ds. Karteli ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 74

mozna˙ ja˛ uzyskac´ po zintegrowaniu tych usług jako Member Servers. Replikacja SAM w czystym srodo´ wisku kontrolera domeny Samby mozliwa˙ jest przez kombinacje˛ Samby i OpenLDAP. OpenLDAP słuzy˙ Sambie do administrowania grupami oraz uzytko˙ wnikami i oferuje wymagane mechanizmy replikacji.

NTFS XFS EXT3 REISERFS długosć´ nazwy pliku 256 256 256 256 zestaw znaków Unicode ISO-Latin ISO-Latin ISO-Latin dla nazwy pliku wyswietlanie´ wielkich X X X X i małych liter rozróznianie˙ wielkich X X X i małych liter kwoty dyskowe X X X X7 szyfrowanie EFS X8 X9 X10 kompresja X X11 X12 X13 maksymalna wielkosć´ 2 tera 16/64 4 tera14 16/64 pliku tera15 tera16 maksymalna długosć´ dowolna dowolna dowolna dowolna scie´ zki˙ change journal X journaling X X X X

7W niektórych wersjach niepewne. 8Da sie˛ zrealizowac´ dla całych systemów plików lub cze˛scio´ wych drzew za pomoca˛ narzedzi˛ dostepn˛ ych w systemie (crypto-api/loopback i cfs/rpc). 9Patrz szyfrowanie w XFS. 10Patrz szyfrowanie w XFS. 11Za pomoca˛ loopback mozliwa˙ jest kompresja na poziomie systemu plików. 12W we˛zle´ systemu plików ext2/ext3 przewidziany jest atrybut kompresji. Do jadra˛ 2.2 dostepne˛ były łaty dla projektu e2compr, które bazujac˛ na w.w atrybucie pozwalały na kompresje˛ plików za pomoca˛ rózn˙ ych algorytmów. Od jadra˛ 2.4 projekt ten nie jest rozwijany, poniewaz˙ nie ma juz˙ faktycznego zapotrzebowania na kompresje.˛ Za pomoca˛ loopback mozliwa˙ jest kompresja na poziomie systemu plików. 13Patrz kompresja w XFS. 14W zalezno˙ sci´ od architektury - 32 czy 64 bitowa; w kernelu 2.4 ograniczona do 2 tera przez maksymalna˛ wielkosć´ systemu plików. 15W zalezno˙ sci´ od architektury - 32 czy 64 bitowa; teoretyczne maksimum wynosi 9 exabajt; w kernelu 2.4 ograniczona do 2 tera przez maksymalna˛ wielkosć´ systemu plików. 16W zalezno˙ sci´ od architektury - 32 czy 64 bitowa; teoretyczne maksimum wynosi 1 exabajt; w kernelu 2.4 ograniczona do 2 tera przez maksymalna˛ wielkosć´ systemu plików. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 75

ACL DACLs POSIX POSIX ACLs przez ACLs przez rozszerzone rozszerzone atrybuty atrybuty od kolejnej wersji kernela kontrolowanie SACLs X17 X18 X19

Tablica 3.8: Porównanie systemów plików

Porównanie systemów plików

Lokalne składowanie plików przy migracji na klientach Przy ocenianiu sposobu zarzadzania˛ plikami wyszlismy´ z załozenia,˙ ze˙ na klientach nie bed˛ a˛ zapisywane dane uzytko˙ we. W przypadku ewentualnej migracji nalezy˙ postawic´ nowy system o identycznej funkcjonalnosci,´ lecz bez przenoszenia danych znajdujac˛ ych sie˛ na starych klientach. Jesli´ istnieje duza˙ ilos´c´ identycznie wyposazon˙ ych klientów, na których trzeba wykonac´ migracje,˛ nalezy˙ rozwazy˙ c´ prace˛ bezdyskowa˛ wyłacznie˛ w oparciu o sieciowy system plików. Ten szczególny przypadek centralnego, sieciowego składowania plików ma wiele zalet, w szczegól- nosci´ jesli´ chodzi o administrowanie. Zmiany w konﬁguracji klientów wykonuje sie˛ wówczas tylko raz, na serwerze, po czym automatycznie działaja˛ one na wszystkich współpracujac˛ ych z nim klientach. W celu wyboru serwera do pracy z „diskless client“, trzeba przyja˛c´ takie same załozenia,˙ jak w przypadku wyboru serwera (server system) dla centralnego składowania plików w ogóle.

Nadawanie praw dostepu:˛ odwzorowanie proﬁlów uprawnien´ Windows na POSIX ACL Kierowanie prawami dostepu˛ do katalogów i plików za pomoca˛ serwera Samba odpowiada w duzym˙ stopniu załozeniom˙ znanym z NT. Takze˙ w Sambie udostepnia˛ sie˛ w sieci pojedyncze katalogi z systemu plików serwera jako zasoby (shares). Szczegóły nadawania praw dostepu˛

17Kontrolowanie w Linuksie zostało wielokrotnie rozwiniete.˛ Wczesniejszym´ projektem kontroli przestano zajmowac´ sie˛ od poczatku˛ 2000 r. Projekt grsecurity implementuje oparty na procesach system ACL w kernelu (http://www.grsecurity.net/). Z jego pomoca˛ mozliwe˙ jest całkowite kontrolowanie plików i innych aktywnosci´ systemu. 18Patrz kontrolowanie w XFS. 19Patrz kontrolowanie w XFS. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 76

ustalane sa˛ na podstawie uprawnien´ okreslon´ ych w systemie plików uzywan˙ ym po stronie serwera dla kazde˙ go indywidualnie autoryzowanego przez Sambe˛ uzytko˙ wnika. Zasoby (shares) i ich własciwo´ sci´ wynikajace˛ z usytuowania po stronie serwera, takie jak scie´ zka˙ do katalogów, gwarancja anonimowego dostepu˛ i ogólna ochrona przed zapisem, sa˛ w Sambie ustawiane i dokumentowane w jednym pliku konfiguracyjnym, jednoznacznym dla kaz-˙ dej instancji serwera. Edycja w/w pliku konfiguracyjnego moze˙ równiez˙ odbywac´ sie˛ (po odpowiedniej weryfikacji / autoryzacji za pomoca˛ szyfrowanego protokołu HTTPS) poprzez webfrontend. Prawa dostepu˛ do katalogów i plików, w przypadku wszystkich systemów operacyjnych, uzgadniane sa˛w funkcjonalnym składniku systemu operacyjnego - systemie plików. Podczas gdy w przypadku systemu plików FAT nie istniało rozwiazanie˛ problemu włascicieli´ plików w DOS i starszych wersjach Windows, w Uniksie rozróznia˙ sie˛ włascicieli´ i grupy uzytko˙ wników plików od dawna, a w Windows wraz z pojawieniem sie˛ systemu plików NT (NTFS). Access Contrlo Lists (listy kontroli dostepu)˛ reguluja˛ dostep˛ danych uzytko˙ wników do wybranych katalogów i plików. W Uniksie mozliwe˙ jest zdefiniowanie, dla wszystkich plików, przynajmniej nastepuj˛ ac˛ ych uprawnien:´ prawo do odczytu, zapisu i wykonywania przez własciciela,´ grupe˛ włascicieli´ i wszystkich pozostałych uzytko˙ wników sytemu. W przypadku niektórych linuksowych / uniksowych systemów plików mozna˙ narzucic´ dodatkowe ograniczenia albo zagwarantowac´ dodatkowe uprawnienia innym uzytko˙ wnikom, grupom uzytko˙ wników wykorzystujac˛ w tym celu rozszerzone atrybuty oraz POSIX Access Control Lists. Samba jako serwer plików przechowuje swoje pliki w uniksowym systemie plików oraz umozliwia˙ dostep˛ do danych dzieki˛ efektywnym prawom dostepu,˛ którym podlega weryfikowany za kazdym˙ razem uzytko˙ wnik. Serwer Samba moze˙ teoretycznie nakładac´ dodatkowe ograniczenia dostepu˛ wykorzystujac˛ ograniczenia okreslone´ w systemie plików, jednak w zadn˙ ym razie nie moze˙ ich zlekcewazy˙ c.´ Zarówno w przypadku przenoszenia istniejac˛ ych praw dostepu˛ z serwera na klienta, jak tez˙ przy ujawnieniu sie˛ zmian zainicjowanych po stronie klienta, serwer Samba stosuje kanon uprawnien´ systemu plików, w którym składuje on dane uzytko˙ wników i nimi administruje. Dlatego w swiecie´ Uniksa podczas migracji nalezy˙ odwzorowac´ model uprawnien´ z Windows. W dalszych rozdziałach opisalismy´ , w jaki sposób mozna˙ wykonac´ takie odwzorowanie oraz jakie szczegóły i ograniczenia trzeba przy tym wzia˛c´ pod uwaga.˛ Autorzy poradnika wyszli z załozenia,˙ ze˙ system plików w Linuksie obsługuje POSIX-ACL. Obecnie w gre˛ wchodza˛ nastepuj˛ ace˛ systemy plików: XFS, JFS oraz, po nałozeniu˙ łaty, EXT2 i EXT3. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 77

Odwzorowanie NTFS-ACL w linuksowym systemie plików W przypadku odwzorowania windowsowej ACL w linuksowej POSIX ACL system uprawnien´ zredukowany zostaje w takim stopniu, ze˙ obraz uzyskanego odwzorowania odpowiada w znacznym stopniu widokowi najprostszych (Security settings). POSIX ACL zna tylko prawo do odczytu, zapisu i wykonywania. Poza tym POSIX ACL nie rozróznia˙ uprawnien´ takich jak: zapisywanie danych, przyłaczanie˛ danych, zapisywanie atry- butów oraz rozszerzonych atrybutów. Dlatego podczas przenoszenia systemu uprawnien´ Win- dows za pomoca˛ Samby do Uniksa, w uniksowym systemie plików mozna˙ odwzorowac´ tylko kompletne grupy uprawnien´ Windows. Tak samo dzieje sie˛ w odwrotnym kierunku, gdy serwer Samba moze˙ zgłaszac´ klientowi windowsowemu równiez˙ tylko grupy uprawnien.´

UPRAWNIENIA POSIX Odczyt Zapis Wykonywanie przeszukiwanie katalogu / wykonywanie pliku wylistowanie katalogów / X czytanie danych W czytanie atrybutów X (X)20 I czytanie rozszerzonych X N atrybutów D tworzenie plików / X O zapisywanie danych W tworzenie katalogów / X S przyłaczanie˛ danych przypisywanie atrybutów X przypisywanie rozsze- X rzonych atrybutów usuwanie podkatalogów / plików usuwanie czytanie uprawnien´ X X X zmiana uprawnien´

20Jest wyswietlan´ y, ale nie wolno go ustawiac,´ w przeciwnym razie aktywowana zostanie cała grupa „odczyt“. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 78

przejmowanie uprawnien´ własciciela´

Tablica 3.10: Uprawnienia POSIX oraz grupy uprawnien´ Windows

Po stronie uzytko˙ wnika mozna˙ tworzyc´ w windowsowych oknach dialogowych, wykorzystujac˛ kombinacje pasujac˛ ych uprawnien´ NTFS, odpowiednie kombinacje uprawnien´ POSIX. Na- lezy˙ przy tym pamieta˛ c,´ aby wstawianie dodatkowego uprawnienia NTFS z listy windowsowej, spowodowało ustawienie wszystkich uprawnien´ w grupie POSIX, do której nalezy˙ nadawane w ten sposób uprawnienie. Jesli,´ na przykład, dla jakiegos´ pliku, który dotychczas udostepnion˛ y był tylko do odczytu, w oknie dialogowym Privilege entry ustawiona zostania opcja Write attribu- tes, wówczas serwer Samby automatycznie doda uprawnienia dla przypisywania rozszerzonych atrybutów oraz zapisywania i przyłaczania˛ danych. Jesli´ w tym momencie klikniemy OK, wtedy podczas nastepne˛ go otwarcia okna dialogowego natychmiast pojawi sie˛ w nim nowy, znacznie rozszerzony zestaw uprawnien.´ Zaleta˛ takiego rozwiazania˛ jest to, ze˙ opisane powyzej˙ zachowanie serwera Samba nie dopuszcza do błedn˛ ych interpretacji uprawnien´ pokazywanych w prostej prezentacji. W uproszczonej prezentacji ustawien´ bezpieczenstwa´ obraz jest spójny. Mozna˙ tu nadawac´ pojedyncze oraz wspólne prawa do odczytu i zapisu, jak równiez˙ kazdorazo˙ wo w kombinacji z odczyt / wykonywanie. Tego ostatniego, zbiorowego uprawnienia, nie mozna˙ nadawac´ pojedynczo. Uprawnien´ NTFS, takich jak: usuwanie podkatalogów / plików, usuwanie, zmiana uprawnien´ oraz przejmowanie uprawnien´ własciciela´ nie da sie˛ odwzorowac´ w POSIX ACLs i jesli´ zostana˛ nadane, wówczas serwer Samba nie zwróci zadne˙ go rezultatu (w tabeli zaznaczone na zółto).˙ W przypadku ustawienia pełnego dostepu˛ , czyli nadania wszystkich praw: do odczytu, zapisu i wykonywania, takze˙ one zostały zaznaczone jako uprawnienia nadane.

UPRAWNIENIA POSIX Odczyt Zapis Odczyt Odczyt Odczyt, i wykonywanie i zapis zapis i wykonywanie W pełny dostep˛ X ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 79

I zmienianie X N odczyt / wykonywanie X X D wylistowanie X X O zawartosci´ katalogu (tylko dla (tylko dla W (tylko dla katalogów) katalogów) katalogów) S odczyt X X X X zapis X

Tablica 3.12: Uprawnienia POSIX i Windows

Odwzorowanie funkcji dziedziczenia Implementacja POSIX-ACL obsługuje zaledwie dziedziczenie pasywne. Niemozliwe˙ jest odwzorowanie aktywnego dziedziczenia, takiego jak w NTFS.

Odwzorowanie systemu atrybutów Atrybuty, których nie ma w Uniksie mozna˙ odwzorowywac´ na rózne˙ sposoby. Tak naprawde˛ nie trzeba tu ustawiac´ ﬂagi tylko do odczytu, poniewaz˙ istnieje juz˙ ona w tradycyjnym systemie uprawnien´ i jest automatycznie wyswietlana´ dla plików i katalogów składowanych bez prawa do zapisu. Flagi archiwalny, ukryty i systemowy mozna˙ odwzorowac´ za pomoca˛ nieuzywane˙ go przez uniksowy system plików bitu execute. Dlatego mozna˙ o nich powiedziec,´ ze˙ istnieja.˛ Atry- buty spakowany i zaszyfrowany nie dadza˛ sie˛ odwzorowac,´ jednakze˙ mozna˙ skorzystac´ z nich w Uniksie dzieki˛ specjalnym usługom.

Odwzorowanie funkcji kontrolnych System kontroli jest silnie zintegrowany z Windows. W Uniksie mozna˙ go uzyskac´ za pomoca˛ innych mechanizmów. W przypadku serwera Samba jest on realizowany poprzez moduł VFS. W ten sposób na serwerze Samba uzyskuje sie˛ protokółowanie dostepu˛ do plików i ka- talogów. Dotychczas funkcja kontrolna, realizowana na poziomie plików w takiej formie, nie została umieszczona w jadrze˛ Linuksa, mimo ze˙ podjetych˛ zostało wiele prób implementacji i ze˙ w linuksowych systemach plików spełnione sa˛ odpowiednie wymagania dotyczace˛ rozszerzonych atrybutów. W praktyce mozliwo˙ s´c´ ta ma jednak na tyle małe znaczenie, ze˙ wszystkie podejmowane próby konczyły´ sie˛ wskutek braku zainteresowania nimi. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 80

Podsumowanie najwazniejszych˙ skutków zastosowania serwera Samba z POSIX ACLs Jesli´ chodzi o zapis, jako prawo abstrakcyjne, to:

◦ nie ma róznic˙ y pomiedzy˛ prawem do zapisu, a prawem do przyłaczania˛ danych

◦ w przypadku katalogów równiez˙ nie ma róznic˙ y pomiedzy˛ prawem do tworzenia katalo- gów, a prawem do tworzenia plików

◦ nie ma róznic˙ y pomiedzy˛ prawem do zapisywania katalogów bad˛ z´ plików, a prawem do zapisywania atrybutów

Jesli´ chodzi o odczyt, jako prawo abstrakcyjne, to:

◦ nie ma róznic˙ y pomiedzy˛ prawem do odczytu katalogów bad˛ z´ plików a prawem do odczytu atrybutów

Zasadniczo nalezy˙ przyja˛c,´ ze˙ odczyt jest dozwolony zawsze. Generalnie nie sa˛ zaimplementowane mechanizmy kontroli ani dziedziczenia.

Grupy uzytk˙ owników i prawa dostepu˛ Nadawanie praw dostepu˛ grupom odgrywa istotna˛ role˛ w szczególnosci´ w przypadku zaso- bów wspólnie uzywan˙ ych przez grupy robocze. W NT rozrózni˙ c´ nalezy˙ grupy lokalne (serwera) i globalne. Lokalne grupy mozna˙ rozumiec´ jako zdefiniowane aliasy, które wskazuja˛ na jedna˛ lub wiecej˛ grup globalnych. W ten sposób grupy lokalne moga˛ zawierac´ wiele grup globalnych. W Sambie (i ogólnie w srodo´ wisku UNIX/Linux) nie jest mozliwe˙ zagniezd˙ zanie˙ grup. Za pomoca˛Samby mozna˙ tylko przedstawic´ klientom windowsowym oraz Member Servers wszystkie uniksowe grupy w skali 1 : 1 jako grupy globalne. Oczywiscie´ w/w globalne grupy moga˛ na windowsowych Member Servers ponownie wejsć´ do grup lokalnych. Tym samym w dalszym ciagu˛ na tego typu serwerach mozna˙ korzystac´ z metod B-G-L-R i B-G-R, które zostały opisane w rozdziale 3.2.2.4. Na razie na serwerach linuksowych nie planuje sie˛ wprowadzenia rozwiazania˛ opartego na grupach lokalnych, dlatego swoje typowe zastosowanie znajdzie tutaj model B-G-R. Adekwatna˛ funkcjonalnosć´ mozna˙ uzyskac´ za pomoca˛ odpowiedniego business-logic opierajac˛ zarzadzanie˛ grupami na LDAP. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 81

Ocena skutków dla uzytk˙ owników Przy odwzorowywaniu Windows-ACL na POSIX-ACL traci sie˛ stopien´ dokładnosci,´ w jakim mozna˙ modyﬁkowac´ uprawnienia w Windows. Jednak w praktyce, w znakomitej wiekszo˛ sci´ zastosowan,´ wykorzystuje sie˛ tylko o wiele prostszy zestaw uprawnien´ oferowany przez Security settings. Inne, dalej idace˛ uprawnienia, stosowane sa˛jedynie w pojedynczych przypadkach. Szczegól- nie rzadko wykorzystywane jest rozróznianie˙ pomiedzy˛ uprawnieniami atrybutów i plików. Takze˙ korzystanie z przyłaczania˛ danych ma sens zaledwie w niektórych przypadkach. Upraw- nienie to mozna˙ nadawac´ równiez˙ z linii polecen,´ jako rozszerzony atrybut dla wybranych plików w Linuksie, podczas pracy w systemach plików ext2 i ext3. Dzieki˛ scisłemu´ odwzorowaniu nieskomplikowanego modelu uprawnien´ z POSIX ACL, obraz prostych Security settings staje sie˛ bardziej przejrzysty dla przecietne˛ go uzytko˙ wnika. Okreslon´ ych funkcji, takich jak dziedziczenie i kontrola nie da sie˛ odwzorowac.´

3.2.4 Migracja kontynuacyjna

3.2.4.1 Windows 2000

W niniejszym rozdziale przedstawiamy, pod katem˛ oferowanych „File Services“, nastepc˛ e˛ Win- dows NT4, tj. Windows 2000.

Nowe funkcje Wraz z Windows 2000 w obszarze File Services wprowadzono kilka zmian. Główne z nich zostały wyszczególnione ponizej:˙

◦ system plików NTFS5

◦ HSM-API

◦ dziedziczenie

◦ szyfrowanie (EFS)

◦ SMB over Native IP

◦ dynamiczne administrowanie nosnikami´ danych

◦ defragmentacja ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 82

◦ zagniezd˙ zanie˙ grup

◦ Remote Storage

◦ Indexing Service

◦ Distributed Link Tracking

◦ DFS

◦ Ofﬂine Folder

◦ Folder Redirection

W kolejnych paragrafach znalez´c´ mozna˙ szerszy opis wprowadzonych zmian.

System plików NTFS5 System plików NTFS5 oferuje łacznie˛ nastepuj˛ ace˛ ulepszenia:

Przede wszystkim mozliwe˙ jest administrowanie prawami dostepu˛ za pomoca˛ funkcji dziedziczenia. Oznacza to, ze˙ uprawnienia nadane katalogom nadrzedn˛ ym działaja˛ takze˙ w katalogach i plikach podrzedn˛ ych bez koniecznosci´ ich przepisywania (Burn-In). Tym samym pozbyto sie˛ wad zwiazan˛ ych z przepisywaniem (problem obcia˛zenia,˙ usuwania specyﬁcznych uprawnien´ w katalogach podporzadko˛ wanych). NTFS5 oferuje change journal, w którym protokółowane sa˛ zmiany. Nosniki´ danych sformatowane dla NTFS5 dysponuja˛ukrytym katalogiem o nazwie „System Volume Information“, do którego ma dostep˛ wyłacznie˛ system operacyjny i w którym odbywa sie˛ administrowanie dodatkowymi funkcjami. NTFS5 oferuje tak zwany HSM-API (interfejs programowania Hierarchical Storage Mana- gement), z którego moga˛ korzystac´ produkty innych producentów. NTFS5 oferuje mozliwo˙ s´c´ szyfrowania danych. Encrypting File System (EFS) umozliwia˙ uzytko˙ wnikom chronienie danych przed odczytem ich zawartosci´ przez osoby trzecie (w tym administratorów). W sieciach zakładowych wymagane jest przy tym skorzystanie z PKI (Public Key Infrastructure). Integracja kwot w systemie plików została zachowana, jednak nadal podlega ona ograniczeniom z NT4. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 83

Protokoły Windows 2000 obsługuje, podobnie jak miało to miejsce we wczesniejszych´ wersjach tego systemu operacyjnego, rózne˙ protokoły. Nowosci´ a˛ w Windows 2000 jest mozliwo˙ s´c´ wyłaczenia˛ komunikacji przez NetBIOS. Dla File Services oznacza to, ze˙ podczas komunikacji, tzw. „Direct Hosting of SMB Over TCP / IP“ odbywa sie˛ przez port 445.

Administracja nosnikami´ danych Windows 2000 oferuje mozliwo˙ s´c,´ właczenia˛ ﬁzycznych twardych dysków do systemu, bez koniecznosci´ przydzielania napedom˛ liter. Tego typu dynamiczne nosniki´ danych moga˛byc´ wła-˛ czane do tradycyjnych nosników´ danych jako katalogi i udostepniane.˛ Windows 2000 po raz pierwszy dostarcza narzedzie˛ do defragmentacji nosników´ danych.

Zmiany odnosnie´ nadawania praw dostepu˛ W Windows 2000 Active Directory istnieje znacznie wiecej˛ mozliwo˙ sci´ kontrolowania uprawnien,´ gdyz˙ mozna˙ mocniej zagniezd˙ za˙ c´ wiecej˛ typów grup. Zagniezd˙ zanie˙ grup mozliwe˙ jest tylko wtedy, gdy Active Directory uzywan˙ y jest w „Native Mode“. W tym trybie pracy dostepne˛ sa˛ dwa nowe typy grup „Domain Local“ oraz „Universal“. Ponizsza˙ tabela pokazuje mozliwo˙ sci´ zagniezd˙ zania.˙

TYP GRUPY MOZ˙ E MIEC´ NASTE˛PUJAC˛ YCH MOZ˙ E BYC´ CZŁONKIEM. . . CZŁONKÓW. . . grupa globalna uzytko˙ wnik i globalne grupy globalne grupy tej samej tej samej domeny domeny; grupy uniwersalne oraz lokalne grupy domen lokalna grupa uzytko˙ wnik, uniwersalna lokalne grupy domen tej samej domen i globalna grupa kazdej˙ domeny domeny grupy uzytko˙ wnik, globalne lokalne grupy domeny albo uniwersalne i uniwersalne grupy kazdej˙ uniwersalne grupy kazdej˙ domeny domeny

Tablica 3.14: Typy grup ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 84

Oprócz w/w nowych typów grup, w srodo´ wiskach wykorzystujac˛ ych Active Directory i Exchange 2000 nalezy˙ wyrózni˙ c´ grupy bezpieczenstwa´ oraz grupy dystrybucji. W przypadku grup dystrybucji istnieja˛srodo´ wiska Exchange, jednak nie da sie˛ w nich kontrolowac´ File Servi- ces .

Remote Storage Remote Storage jest nowa˛ usługa˛ dostarczana˛ przez Windows 2000. Umozliwia˙ ona składo- wanie długo nieuzywan˙ ych plików na napedach˛ tasmo´ wych w ramach tzw. HSM (Hierarchical Storage Management).

Indeksowanie Indeksowanie mozna˙ opcjonalnie właczy˛ c´ dla folderów plików w celu załozenia˙ indeksu zapisanych danych. Umozliwia˙ on szybsze przeszukiwanie okreslonej´ zawartosci.´ Indeksowanie mozna˙ stosowac´ dla dokumentów:

◦ HTML

◦ tekstowych

◦ Microsoft Ofﬁce 95 lub wyzej˙

◦ Internet Mail oraz News

◦ wszystkich innych dokumentów, dla których dostepne˛ sa˛ ﬁltry dokumentów.

Distributed Links Tracking Serwery plików Windows 2000 umozliwiaj˙ a˛ takie zaprogramowanie aplikacji obsługujac˛ ych linkowanie i osadzanie obiektów, ze˙ podczas przeciagania˛ zlinkowanych obiektów mozliwe˙ jest uzyskiwanie z systemu plików informacji na temat ich aktualnego połozenia˙ w systemie, przy jednoczesnym zachowaniu bezbłednej˛ pracy.

Distributed File System Distributed File System (DFS) udostepnian˛ y był juz˙ w Windows NT 4 poprzez dodatkowo instalowane oprogramowanie na serwerze i po stronie klienta. W przypadku Windows 2000 odpowiednie funkcje zostały, zarówno po stronie serwera jak i klienta, zaimplementowane jako standard oraz dodatkowo rozszerzone. DFS umozliwia˙ to, ze˙ zasoby udostepniane˛ z katalogów ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 85 znajdujac˛ ych sie˛ na rózn˙ ych serwerach, moga˛ byc´ przedstawiane klientowi w postaci podkata- logów pojedynczego zasobu. Dzieki˛ temu oszczedza˛ sie˛ litery alfabetu opisujace˛ napedy˛ , które maja˛ byc´ przyporzadko˛ wane danemu uzytko˙ wnikowi. W Windows 2000 DFS został na tyle rozszerzony o integracje˛ z FRS (File Replication Service), ze˙ zlinkowane zasoby i ich zawartos´c´ moga˛ byc´ replikowane do dalszych zasobów i innych serwerów plików. Jesli´ serwer przestanie pracowac´ i przestanie tym samym udostepnia˛ c´ zasoby, wówczas klient bedzie˛ mógł korzystac´ z replik, bez potrzeby tworzenia nowych połacze˛ n´ sieciowych. W Windows 2000 informacje moga˛ byc´ zapisywane i raplikowane w Active Directory za pomoca˛ drzewa DFS. Dzieki˛ temu klient dysponuje niemal przez cały czas potrzebnymi informacjami o połaczeniach.˛

Zestawianie połaczenia˛ Uzytko˙ wnikowi mozna˙ ułatwic´ poszukiwanie zasobów przez opublikowanie ich w Active Di- rectory.

Offline Folder i Folder Redirection Funkcje „Offline Folder“ i „Folder Redirection“ nie sa˛zasadniczo własciwo´ sciami´ File Servi- ces z Windows 2000, lecz funkcjami klienta (np. Windows 2000 / Professional). Wspomnielismy´ o nich w tym miejscu, poniewaz˙ maja˛ one duze˙ znaczenie, jesli´ chodzi o przechowywanie danych i dlatego, ze˙ funkcje te musza˛ współpracowac´ z serwerem plików. Offline Folder sa˛ jakby nastepcami˛ „Aktówki“ z wczesniejszych´ wersji Windows. Uzytko˙ wnicy korzystajac˛ y, np. z note- booka, moga˛ edytowac´ katalogi i pliki, które zazwyczaj zapisywane sa˛ na serwerze plików, bez połaczenia˛ sieciowego. Gdy tylko zestawione zostanie połaczenie˛ z serwerem plików, nastapi˛ synchronizacja (replikacja) odpowiednich plików. Dla wykonania bezbłednej˛ replikacji, bardzo wazne˙ sa˛ własciwo´ sci´ plików po obu stronach (klient i serwer). Zastosowanie w Windows 2000 funkcji Folder Redirection wynika z mozliwo˙ sci´ znacznego przyrostu wielkosci´ profilów uzytko˙ wnika na stacjach roboczych podczas pracy. Dzieje sie˛ tak, np. wtedy, gdy uzytko˙ wnik zapisuje swoje pliki w „Own files“, które własciwie´ powinny byc´ składowane na serwerze plików. W Windows 2000 mozliwe˙ jest „ukierunkowanie“ profilu uzyt-˙ kownika („Own files“, „Application data“) na scie´ zk˙ e˛ sieciowa˛ katalogów systemowych. Kata- logi te bed˛ a˛ dla uzytko˙ wnika dostepne˛ w przezroczysty´ sposób, jako katalogi lokalne. Poprzez przeciaganie˛ katalogu do serwera plików nalezy˙ zwrócic´ uwage˛ na to, aby zachowane zostały prawa dostepu.˛

Zabezpieczanie danych Narzedzie˛ NTBACKUP dostarczane wraz z Windows zostało zmodyﬁkowane w taki spo- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 86

sób, ze˙ obecnie mozna˙ wykonywac´ kopie bezpieczenstwa´ napedów˛ (lokalnych lub sieciowych). Dzieki˛ temu łatwiej da sie˛ unikna˛c´ stosowania lokalnych napedów˛ tasmo´ wych.

Kolejne wersje systemu Z punktu pojawiania sie˛ nowych wersji nalezy˙ wyrózni˙ c´ nastepuj˛ ace˛ drogi rozwoju:

◦ Windows 2000 Server zastapił˛ Windows NT 4 Server

◦ Windows 2000 Advanced Server zastapił˛ Windows NT 4 Server Enterprise Edition (patrz Cluster Services)

Wraz z Windows 2000 Data Center Server ﬁrma Microsoft po raz pierwszy udostepniła˛ system operacyjny, który moze˙ współpracowac´ wyłacznie˛ ze specjalnym osprzetem˛ i z niewielka˛ grupa˛ producentów. Platforma ta zakłada bardzo szczególna˛ dostepno˛ s´c´ i / lub scenariusze obcia˛zenia˙ (pojemnosci).´ W niniejszym poradniku nie bedzie˛ ona omawiana.

Network Attached Storage (NAS) Niektórzy producenci osprzetu˛ wymyslili,´ we współpracy z ﬁrma˛ Microsoft, tak zwane systemy NAS oparte o Windows 2000. Systemy te sa˛ dedykowane dla File Services i maja˛ zoptymalizowane I/O.

Praktyczne uwagi Ponizej˙ znalez´c´ mozna˙ kilka uwag odnosnie´ przedstawionych wczesniej´ nowosci´ technicznych:

◦ Upowszechnienie EFS z reguły ogranicza sie˛ do zastosowan´ dla komputerów przenosn´ ych, na których wymagana jest ochrona danych przed uszkodzeniem oraz ochrona poufnosci´ danych. Celowos´c´ stosowania EFS jest czesto˛ podwazana˙ z uwagi na koniecznos´c´ korzystania z PKI (takze,˙ gdy jest ona juz˙ oferowana przez Windows 2000 Active Directory), a z drugiej strony ze wzgledu˛ na brak obsługi mechanizmów dostepu˛ opartych na grupach (w celu składowania plików grup na serwerze plików).

◦ Odłaczenie˛ komunikacji przez interfejs NetBIOS nie jest wymagane i z reguły nie robi sie˛ tego, co ma na celu zachowanie kompatybilnosci´ zwrotnej.

◦ Nalezy˙ , w oparciu o nowy system plików, rozwazy˙ c´ stosowanie dotychczasowych narze-˛ dzi do zarzadzania˛ plikami i prawami dostepu.˛ Na przykład NT 4 Explorer nie moze˙ w sensowny sposób przedstawic´ dziedziczenia. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 87

◦ W poszczególnym przypadku nalezy˙ sprawdzic,´ pod katem˛ dalszego korzystania z osprzetu,˛ który był wczesniej´ wykorzystywany przez NT 4, czy konieczne jest wdrozenie˙ Windows 2000. W wiekszo˛ sci´ przypadków trzeba sie˛ liczyc´ z tym, ze˙ konieczne bedzie˛ nabycie nowego osprzetu.˛

3.2.4.2 Windows 2003 Server

W niniejszym rozdziale przedstawiamy, pod katem˛ oferowanych „File Services“, nastepc˛ e˛ Win- dows 2000, tj. Windows 2003 Server (wczesniej´ „NET Server“). Ponizej˙ znajduje sie˛ krótki opis najwazniejszych˙ nowosci,´ które zostały wprowadzone wraz z nowa˛ wersja:˛ Windows 2003 Server bedzie˛ pierwszym systemem operacyjnym ﬁrmy Microsoft obsługu- jac˛ ym takze˙ architekture˛ 64 bitowa.˛ Oﬁcjalna obsługa technologii SAN (Storage Area Networks) zostanie ulepszona do takiego stopnia, ze˙ mozliwe˙ bedzie˛ bootowanie twardych dysków w SAN. EFS umozliwi˙ takze˙ dostep˛ do jednego zasobu wiekszej˛ ilosci´ uzytko˙ wników. Grupy w dalszym ciagu˛ nie bed˛ a˛ uwzgledniane.˛ Pojawi sie˛ nowa funkcja Volume Shadow. Umozliwi˙ ona postrzeganie struktury plików i ka- talogów w okreslon´ ym czasie jako statycznej, dzieki˛ czemu mozliwe˙ bedzie,˛ np. zabezpieczanie danych bez koniecznosci´ zwracania uwagi na otwarte pliki. Z drugiej strony pojawia˛sie˛ nastepu-˛ jace˛ mozliwo˙ sci:´ uzytko˙ wnicy zyskaja˛prawo odtwarzania z „migawki (snapshot)“ przypadkowo usunietych˛ plików bez potrzeby uruchamiania specjalnego trybu odzyskiwania danych. Zostanie uproszczone zarzadzanie˛ systemem odzyskiwania danych (System Recovery).

3.3 Drukowanie

3.3.1 Przeglad˛

Przedstawiona ponizej˙ ocena szczegółów technicznych prowadzi do nastepuj˛ ac˛ ych wniosków: W Linuksie standardowym serwerem wydruku we wszystkich wiekszych˛ dystrybucjach (SuSE, Debian, Red Hat, itd) jest CUPS. Jest to system pracujac˛ y odpowiednio do potrzeb, zarówno w jednolitym srodo´ wisku Linuksowym, jak tez˙ w srodo´ wiskach heterogenicznych, w skład których wchodza˛ stacje klienckie oparte na Windows. Dla tych ostatnich pełnowartoscio´ wym systemem wydruku jest kombinacja CUPS i Samby. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 88

CUPS zapewnia ponad platformowa˛ obsługe˛ zadan´ wydruku dzieki˛ zaimplementowanemu IPP (Internet Printing Protocol). CUPS obsługuje takze˙ wszystkie inne wazne˙ protokoły wydruku takie jak LPR/LPD, Socket / AppSocket, SMB / CIFS oraz MS-RPC (w połaczeniu˛ z Samba).˛ Połaczenie˛ CUPS / Samba umozliwia˙ takze˙ automatyczna˛ instalacje˛ sterowników na klientach windowsowych. Ponadto CUPS oferuje rózne˙ mozliwo˙ sci´ zabezpieczania danych, takze˙ w czasie drukowania. Nalez˙a˛ do nich transmisja szyfrowana przez SSL z wykorzystaniem IPP i weryﬁkacji uzytko˙ w- ników za pomoca˛ LDAP, czy tez˙ w połaczeniu˛ z Samba.˛ Ma to wiele zalet, równiez˙ z uwagi na accounting dostepów˛ do drukarki. Przed rozpoczeciem˛ migracji powinnismy´ w kazdym˙ przypadku sprawdzic,´ czy w/w serwer wydruku współpracuje z naszymi drukarkami. Dotyczy to w szczególnosci´ sytuacji, gdy wydruk ma byc´ realizowany w całosci´ po stronie serwera wydruku, poniewaz˙ w niewielu pojedynczych przypadkach współpraca taka nie jest mozliwa.˙ Klienty Windows 2000 moga˛ drukowac´ poprzez serwer CUPS, takze˙ w przypadku migracji kontynuacyjnej po stronie klientów, gdyz˙ Windows 2000 obsługuje IPP.

3.3.2 Wprowadzenie

Temat „drukowanie“ traktowany jest w swiecie´ informatyki po macoszemu. Dotyczy to wszystkich srodo´ wisk i systemów operacyjnych, tzn. w równym stopniu swiata´ Windows, jak i swiata´ Uniksa / Linuksa. Problemy z wydrukiem sa˛ czest˛ a˛ przyczyna˛ powazn˙ ych strat powodowanych utrata˛ płynnosci´ pracy. Administratorzy poswi´ ecaj˛ a˛ duzo˙ swojego czasu, aby codziennie usuwac´ problemy z drukowaniem. Z drugiej strony drukowanie jest w wielu przypadkach „mission- critical“, która w razie problemów moze˙ zwieksza˛ c´ koszty i przyprawiac´ o duzy˙ ból głowy osoby odpowiedzialne za sprawne działanie systemu. W infrastrukturze drukowania szeroko rozpowszechniły sie˛ „dzikie“ rozwiazania.˛ „Narosłe struktury“ doprowadziły w wielu miejscach do całkowitej niekompatybilnosci.´ Z tego powodu panuje duzy˙ bałagan, jesli´ chodzi o jezyki˛ uzywane˙ do opisu stron (PostScript, PCL, PreScribe, ESC/P, PDF. . . ). To, czesto˛ „wcale nie pokojowe“, współistnienie protokołów wydruku oraz protokołów sieciowych, sprawia wiele problemów: LPR / LPD, HP JetDirect, SMB / MS-RPS itd. Nie ma potrzeby, by migracja serwera wydruku na nowa˛ platforme˛ zachowywała istniejace˛ proporcje w mozliwie˙ dokładnej skali 1 : 1, jednak w obszarze tym mozna˙ wykorzystac´ szanse˛ i usuna˛c´ przy okazji wczesniejsze´ braki. Oprócz braków technicznych równie decydujac˛ a˛ role˛ odgrywa cena. Czesto˛ nie sa˛ znane ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 89 prawdziwe koszty drukowania w ramach organizacji (działu, zakładu, koncernu, urzedu).˛ W tej dziedzinie istnieja˛ powazne˙ potencjalne mozliwo˙ sci´ oszczedzania,˛ które uswiadamiamy´ sobie dopiero wówczas, gdy zobaczymy jednoznaczne dane. Najwazniejszymi˙ kryteriami dla obliczania kosztów sa:˛

◦ ilos´c´ drukarek

◦ zuzycie˙ papieru

◦ ilos´c´ zuzywan˙ ych tonerów / atramentu

◦ zuzycie˙ energii

Przed rozpoczeciem˛ migracji nalezy˙ poznac´ odpowiedzi na nastepuj˛ ace˛ pytania:

◦ Ile jest drukarek w zakładzie pracy?

◦ Jak duze˙ jest zuzycie˙ papieru?

◦ Jak duze˙ jest zuzycie˙ tonerów / atramentu? Ile pieniedzy˛ przeznaczanych jest na nie w ciagu˛ roku?

◦ Jakie sa˛ przyczyny ponoszenia opłat serwisowych (za naprawy, konserwacje)?˛

◦ Jak duzy˙ jest nakład pracy wewnetrzn˛ ych słuzb˙ technicznych?

◦ Ile wynosza˛ opłaty za energie˛ elektryczna˛ wykorzystywana˛ przez drukarki?

◦ Ile kosztuje wydrukowanie jednej strony?

◦ Jak rozkłada sie˛ koszt drukowania na rózn˙ ych typach drukarek?

◦ Czy mozna˙ wydajniej wykorzystac´ dostepne˛ zasoby?

Rzeczywiste pienie˛zne˙ koszty mozna˙ najcze˛sciej´ poznac´ dopiero po wykonaniu odpowiednich kalkulacji. Nakład pracy, który trzeba przy tym ponies´c,´ czesto˛ sie˛ opłaca. Dokładna analiza czynników generujac˛ ych koszty zwróci sie˛ na pewno, poniewaz˙ praktycznie zawsze istnieje moz-˙ liwos´c´ oszczedzania,˛ która amortyzuje sie˛ w ciagu˛ roku. Migracja w obszarze srodo´ wiska drukowania jest cieciem˛ - w czasie jej przygotowywania nalezy˙ wykonac´ odpowiednia˛ analize˛ potrzeb, której wyniki nalezy˙ uwzgledni˛ c´ w planach migracyjnych. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 90

3.3.3 Punkt wyjscia´ - drukowanie pod Windows NT 4

W niniejszym rozdziale przedstawilismy´ sytuacje,˛ która˛ uznalismy´ za punkt wyjscia´ w przypadku wiekszo˛ sci´ istniejac˛ ych srodo´ wisk windowsowych. Przyjeli˛ smy´ załozenie,˙ ze˙ istniejace˛ srodo´ wisko oparte jest na jednym z powszechnie stosowanych modelu domen NT. Ponadto wyszlismy´ z załozenia,˙ ze˙ srodo´ wiska te udostepniaj˛ a˛ Print Services oparte na Windows NT 4 Server. Oprócz tego załozyli˙ smy´ , ze˙ serwery wydruku sa˛ członkiem domeny NT. Enterprise Edition umozliwia˙ obsługe˛ wydruku realizowana˛ przez dwa wezły˛ (serwery) w jednym klastrze. Ustanie pracy jednego z serwerów (jednego wezła)˛ kompensowane jest przeje-˛ ciem jego zadan´ przez pozostały wezeł.˛ Klient „odczuwa“ to - jesli´ w ogóle - przez czas krótszy niz˙ sekunda. Nie mozna˙ przy tym wykluczyc´ utraty aktywnych zadan´ drukowania. Zastosowanie takiego klastra wymaga uzycia˙ specjalnego osprzetu˛ (patrz File Services). Jako komputery - klienty (Print Clients) wzieto˛ pod uwage˛ maszyny wyposazone˙ w:

◦ Windows NT 4 Workstation

◦ Windows 9x

Jako drukarki wzieto˛ pod uwage:˛

◦ drukarki z kartami sieciowymi

◦ printer boxes z podłaczon˛ ymi drukarkami

Ponizszy˙ rysunek pokazuje typowa˛ konstelacje˛ srodo´ wiska wydruku: Niektóre stacje robocze obsługuja˛drukarke˛ podłaczon˛ a˛lokalnie do LPT1 (drukarka lokalna). Inne stacje robocze nie obsługuja˛ bezposrednio´ podłaczon˛ ych drukarek, lecz współpracuja˛ wyłacznie˛ z drukarkami podłaczon˛ ymi do sieci. Wiekszo˛ s´c´ drukarek laserowych mozna˙ wyposazy˙ c´ w karte˛ sieciowa.˛ W przeciwienstwie´ do nich drukarki atramentowe mozna˙ wykorzystac´ do pracy w sieci czesto˛ dopiero po zastosowaniu dodatkowego printer box. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 91

Rysunek 3.3: Srodo´ wisko wydruku

Rysunek pokazuje dwa zasadniczo rózne˙ przepływy danych. Z jednej strony klient wydaje zlecenie wydruku bezposrednio´ przez siec´ na drukarke,˛ a z drugiej strony klient korzysta z „udostepnionej˛ drukarki“ na serwerze wydruku, który ostatecznie przekazuje dane do drukarki. Ponizej˙ opisane zostały rózne˙ metody drukowania oraz ich warianty.

3.3.3.1 LPR / LPD w Windows NT 4.0

Znana z Uniksa technika LPR - LPD (Line Printer Redirector - Line Printer Daemon) znalazła swoje miejsce takze˙ w swiecie´ Windows pocza˛wszy od Windows NT i jest standardem komunikacji pomiedzy˛ serwerem wydruku a drukarka.˛ Zasadniczo technika ta moze˙ byc´ takze˙ stosowana do komunikacji pomiedzy˛ klientem a serwerem albo klientem a drukarka.˛ Podstawowa˛ wada˛ LPR - LPD jest brak obsługi komunikatów zwrotnych drukarki.

3.3.3.2 Inne porty sieciowe

W Windows NT producenci drukarek, których nazwy zostały podane ponizej,˙ zaimplementowali dodatkowe porty, np.

◦ LexMark Mark Vision Print Monitor (Lexmon.dll)

◦ Hewlett-Packard Network Port Print Monitor (Hpmon.dll).

21Microsoft Windows NT 4 Resource Kit ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 92

Niniejsze porty, w przeciwienstwie´ do portu LPR, sa˛ w stanie korzystac´ takze˙ z innych protoko- łów transportu. W powyzszym˙ przypadku obsługiwane sa,˛ np.

◦ DLC

oraz

◦ IPX

Nowe sieciowe porty wydruku z reguły umozliwiaj˙ a˛komunikacje˛ dwukierunkowa˛z drukarkami lub z print boxes.

3.3.3.3 Bezposr´ ednie drukowanie ze stacji roboczej

Bezposrednie´ drukowanie (patrz 3.3, strzałka 1) realizowane jest poprzez LPR / LPD. W tym celu na stacjach roboczych z Windows NT 4 musi byc´ zainstalowany serwer wydruku TCP / IP. Systemy Windows 9x trzeba dodatkowo wyposazy˙ c´ w oprogramowanie innych producentów. Na stacjach roboczych nalezy˙ skonﬁgurowac,´ jako przyłacze,˛ tak zwany port LPR. W tym celu nalezy˙ wpisac´ adres IP albo odpowiednia˛ nazwe˛ hosta (DNS) drukarki docelowej. Nastepnie,˛ na z˙adanie,˛ nalezy˙ wybrac´ model drukarki wraz z odpowiednimi sterownikami. System operacyjny przyjmie informacje˛ o tej drukarce, jako drukarce „lokalnej“. Bezposrednia´ komunikacja klienta z drukarka˛ w Windows NT nie znalazła szerokiego zastosowania ze wzgledu˛ na duzy˙ nakład pracy administracyjnej jaka˛ w tym celu trzeba wykonac´ na urzadzeniach˛ konco´ wych.

3.3.3.4 Drukowanie poprzez serwer wydruku

Drukowanie ze stacji roboczej poprzez serwer wydruku wymaga dwukrotnego przepływu danych.

◦ transmisja danych ze stacji roboczej do serwera (patrz 3.3 , strzałka 2a)

◦ transmisja danych z serwera do drukarki (patrz 3.3, strzałka 2b)

Transmisja danych z serwera do drukarki z reguły opiera sie˛ na LPR / LPD (patrz bezposrednie´ drukowanie ze stacji roboczej, podrozdział 3.3.3.3). Transmisja danych pomiedzy˛ stacja˛ robocza˛ a serwerem wydruku moze˙ byc´ realizowana na rózne˙ sposoby. Aby klient mógł wydawac´ zlecenia wydruku do okreslonej´ drukarki za posrednictwem´ serwera, po stronie serwera musza˛ byc´ spełnione dwa zasadnicze warunki: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 93

◦ drukarka musi byc´ skonﬁgurowana na serwerze wydruku (port LPR, sterowniki wydruku)

◦ drukarka musi byc´ dostepna˛

Udostepnienie˛ drukarki umozliwia˙ w sieciach windowsowych miedzy˛ innymi „surfowanie“ w ustawieniach drukarki po kliknieciu˛ odpowiedniego serwera wydruku. Komunikacja pomiedzy˛ stacja˛ robocza,˛ a serwerem wydruku (udostepnienie˛ drukarki) moze˙ byc´ realizowana na trzy rózne˙ sposoby:

◦ Za pomoca˛ polecenia NET USE mozna˙ przekierowac´ istniejac˛ y port lokalny LPT na udostepnian˛ a˛drukarke˛ (przykład: net use LPT3\\nazwaserwera\nazwaudostepnianejdrukarki).˛ Metoda ta wymaga od uzytko˙ wnika zainstalowania drukarki (sterowników drukarki) na porcie LPT i jej lokalnego skonﬁgurowania. Jest to czesto˛ wymagane, gdy wydruk ma byc´ wykonywany z aplikacji dosowych. Dane wydruku przesyłane sa˛ w formacie RAW, co oznacza, ze˙ moga˛ byc´ one zinterpretowane przez drukarke˛ bezposrednio´ po przesłaniu.

◦ Mozna˙ utworzyc´ nowy port LPR z adresem docelowym serwera wydruku i nazwa˛ udostepnianej˛ drukarki. Dane wydruku równiez˙ w tym przypadku przesyłane sa˛ w formacie RAW.

Za pomoca˛tak zwanej metody „Point & Print“ na stacji roboczej mozna˙ skonﬁgurowac´ drukarke˛ sieciowa.˛ Zaleta˛takiego rozwiazania˛ jest to, ze˙ w idealnym przypadku nie bedzie˛ potrzeby instalacji sterowników i wykonywania recznej˛ konﬁguracji. Dane wydruku przesyłane sa˛w formacie EMF (Enhanced Meta Format). Drukarka nie umie ich zinterpretowac,´ dlatego dane musza˛ zostac´ wczesniej´ przygotowane przez serwer wydruku. Metoda „Point & Print“ została dokładniej opisana w nastepn˛ ym rozdziale.

3.3.3.5 Metoda „Point & Print“

W przypadku komunikacji pomiedzy˛ Print Client i Print Server, Microsoft postawił na proto- kół RPC (Remote Procedure Call) i wdrozył˙ tym samym tak zwana˛ technologie˛ Point & Print. Z jednej strony rozwiazanie˛ to umozliwia˙ przenoszenie sterowników drukarki z serwera na klienta oraz przekazanie ustawien´ drukarki (podawane papieru, standardowe formaty papieru) do klienta, a z drugiej cze˛s´c´ procesu przetwarzania danych (Rendering) przechodzi na serwer, dzieki˛ czemu nastepuje˛ odcia˛zenie˙ klienta. Jest to szczególnie korzystne podczas pracy z Termi- nal Servers. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 94

Poniewaz˙ opisywana technologia Microsoft jest specyﬁczna, ponizej˙ przedstawiony został szczegółowy przebieg całego procesu drukowania. Przyjeli˛ smy´ załozenie,˙ ze˙ zarówno stacje robocze, jak i serwer wydruku korzystaja˛ z Windows NT 4. Jesli´ uzytko˙ wnik doda drukarke˛ sieciowa˛ do swojego srodo´ wisku wydruku, wówczas, jako pierwsze, nastapi˛ zsynchronizowanie sterowników. Klient Windows NT sci´ agnie˛ sterowniki z serwera, jesli´ jednoczesnie´ spełnione zostana˛ nastepuj˛ ace˛ warunki.:

◦ Serwer wydruku uzywa˙ Windows NT

◦ Serwer wydruku posiada odpowiedni sterownik (platforma: x86, Alpha, etc. i wersja: 3.1, 3.5, 4)

◦ Klient NT nie ma sterownika albo ma starsza˛wersje˛ niz˙ ta, która znajduje sie˛ na serwerze.

Po sci´ agni˛ eciu˛ sterownika, nastapi˛ jego instalacja przez klienta. Oznacza ona takze˙ umieszczenie odpowiednich wpisów w lokalnym rejestrze klienta.

Proces drukowania: Ponizszy˙ rysunek (rys. 3.4) przedstawia przebieg całego procesu, a pod rysunkiem znajduje sie˛ jego krótki opis. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 95

Rysunek 3.4: Proces wydruku realizowany metoda˛ „Point & Print“

◦ Krok 1:

Uzytko˙ wnik decyduje sie˛ na wydrukowanie dokumentu z aplikacji windowsowej. Aplikacja wy- wołuje GDI (Graphics Device Interface). GDI ładuje sterowniki wydruku wybranej drukarki. W oparciu o informacje na temat dokumentu pochodzace˛ z aplikacji oraz informacje o sterowniku wydruku nastepuje˛ realizacja pierwszego etapu wydruku, czyli „renderowanie“ dokumentu do formatu EMF. Aplikacja wywołuje lokalny Spooler (Winspool.drv).

◦ Krok 2:

Poniewaz˙ klient uzywa˙ Windows NT, lokalny Spooler (Winspool.drv) wywołuje przez RPC (Remote Procedure Call) Spooler serwera (Spoolss.exe), który z kolei wywołuje swój router (Spoolss.dll) bezposrednio´ przez API. Router „polls“ „Remote printer provider“ (Win32spl.dll) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 96

klienta, ten natomiast, uruchamia przez RPC proces Spoolss.exe na serwerze wydruku, który nastepnie˛ przyjmuje z sieci zlecenie wydruku i zwiazane˛ z nim dane.

◦ Krok 3

Router serwera odbiera zlecenie wydruku w postaci EMF (Enhanced Metafile) i przekazuje je do Local Print Provider. Dane wydruku w formacie EMF sa,˛ w przeciwienstwie´ do formatu RAM, jeszcze dosć´ niezalezne˙ od urzadzenia˛ drukujace˛ go a ich wielkosć´ w wiekszo˛ sci´ przypadków jest niewielka. Pierwsza cze˛sć´ „renderingu“ wykonana została na kliencie, natomiast teraz nastepuje˛ druga cze˛sć,´ która wykonywana jest po stronie serwera wydruku za pomoca˛ Print Processor z Local Print Provider, który zapisuje (spools) wyniki na lokalnym twardym dysku.

◦ Krok 4:

Zapisane w ten sposób zlecenie przekazywane jest do Print Monitor (despooling), który z kolei wywołuje monitor portów. Monitor portów sprawdza, czy i jak działa dwustronna komunikacja drukarki i wysyła odpowiednie dane.

◦ Krok 5:

Drukarka otrzymuje dane, przekształca kazd˙ a˛ strone˛ w bitmape˛ i drukuje je na papierze. Jesli´ w drugim kroku nie ma klienta Windows NT albo jest klient Windows NT, który korzysta z przekierowanego lokalnego połaczenia˛ (net use LPT), wówczas zlecenie wydruku, po całkowitym renderingu po stronie klienta, przesyłane jest w formacie RAW poprzez NETBIOS Redirector do Print-Server Service. Takze˙ w sytuacji, gdy klient uzywa˙ LPR, zlecenie wydruku wysyłane jest w formacie RAW poprzez TCP / IP do LPD serwera wydruku.

3.3.3.6 Protokoły sieciowe

Komunikacja via LPR / LPD ma miejsce wyłacznie˛ z udziałem TCP / IP. W innych przypadkach komunikacja pomiedzy˛ stacja˛ robocza˛ a serwerem wydruku moze˙ opierac´ sie˛ na rózn˙ ych protokołach:

◦ TCP / IP

◦ NetBEUI

◦ SPX/IPX ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 97

Własciwa´ transmisja danych wydruku wymaga:

◦ SMB albo

◦ RPC

3.3.3.7 Nadawanie praw dostepu˛

Prawa dostepu˛ do drukarek sieciowych (zasobów) obsługiwanych przez serwery wydruku w srodo´ wisku Windows NT sa˛nadawane za pomoca˛ serwerów wydruku. Istnieje nastepuj˛ ace˛ stopniowanie praw dostepu˛ do zasobów:

◦ drukowanie

◦ zarzadzenie˛ drukarkami

◦ zarzadzanie˛ dokumentami

3.3.3.8 Narzedzia˛

Narzedzia˛ administracyjne dostepne˛ dla serwerów wydruku w Windows NT ograniczaja˛ sie˛ do zarzadzania˛ zasobami - drukarkami oraz sterownikami drukarek. Administrowanie ustawieniami samych drukarek nie jest mozliwe.˙ Producenci drukarek udostepniaj˛ a˛ dodatkowe narzedzia˛ dla administratorów drukarek (Mar- kVision ﬁrmy LexMark, JetAdmin ﬁrmy HP, etc.). Podobnie, jak w przypadku napedów˛ sieciowych wazne˙ jest automatyczne nawiazanie˛ po- łaczenia˛ z drukarkami podczas logowania uzytko˙ wnika. Mozna˙ je realizowac´ przez skrypt VB albo korzystajac˛ z takich narzedzi˛ jak con2prt.exe. Do przyznawania praw dostepu˛ do zasobów - drukarek mozna˙ wykorzystac´ skrypty (Perl).

3.3.3.9 Migracja - szczegóły robocze

Ustawienia drukarek zalez˙a˛ od kazdej˙ z nich z osobna. Róznice˙ miedzy˛ nimi moga˛ wystapi˛ c´ nawet w przypadku wykorzystywania drukarek tego samego modelu, np. wskutek ich rózne˙ go złozenia˙ albo rózne˙ go wyposazenia.˙ Dlatego podczas ustawiania parametrów drukarek nalezy˙ zwrócic´ uwage˛ na takie elementy jak pamie˛c´ operacyjna, sposób podawania i format papieru. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 98

Drukarki z wieloma podajnikami czesto˛ zasilane sa˛ papierem róznej˙ jakosci.´ Aby ułatwic´ uzytko˙ wnikowi dokonanie prawidłowego wyboru, drukarka jest czesto˛ udostepniana˛ jako dwa rózne˙ zasoby. Wówczas kazdemu˙ z nich mozna˙ zadac´ rózne˙ ustawienia, odpowiednio do standardowo obsługiwanego podajnika. Aby optymalnie obsłuzy˙ c´ uzytko˙ wnika mobilnego, mozna˙ pomysle´ c´ o zestawieniu połacze-˛ nia z drukarkami na podstawie miejsca, w którym znajduje sie˛ komputer. Posłuzy˙ c´ sie˛ przy tym mozna˙ dodatkowymi mechanizmami w skryptach logowania, o ile istnieje mozliwo˙ sć´ odpytywania bazy danych, w której przechowywane sa˛ informacje odnosnie´ przyporzadko˛ wania stacji roboczych i drukarek. Producenci wielu modeli drukarek oferuja˛ własne sterowniki, takze˙ wtedy, gdy znajduja˛ sie˛ juz˙ one w zródłach´ Windows NT. Sterowniki udostepniane˛ przez Microsoft sa˛ sprawdzone, jednak czesto˛ nie maja˛ one takiej ilosci´ opcji, jak sterowniki pochodzace˛ od producentów drukarek (obsługa wielu podajników, duplex). Dlatego ich uzycie˙ moze˙ okazac´ sie˛ konieczne. Producenci czesto˛ dostarczaja˛ swoje sterowniki w postaci dodatkowych plików *.dll. Daje to wieksz˛ a˛ kom- pletnosć´ srodo´ wisku drukowania i wymusza zarzadzanie˛ wyborem sterowników. Istniejace˛ rozwiazania˛ opieraja˛ sie˛ czesto˛ na wyborze pomiedzy˛ postscriptem a PCL. W nie- których srodo´ wiskach stosuje sie˛ takze˙ predefiniowane formularze (forms) i czcionki. W srodo´ wisku Windows NT kazdy˙ uzytko˙ wnik ma, w standardowej konfiguracji, dostep˛ do kazdej˙ udostepnianej˛ drukarki, co czesto˛ jest jednak niechcianym rozwiazaniem.˛ W porównaniu z File Services, przyznawanie uzytko˙ wnikom praw dostepu˛ do zasobów - drukarek jest znacznie trudniejsze.

3.3.4 Migracja zastepuj˛ aca˛

W niniejszym rozdziale załozyli˙ smy´ sytuacje,˛ ze˙ istnieje infrastruktura drukowania, w skład któ- rej wchodzi przynajmniej jeden serwer wydruku bad˛ z´ ze˙ trzeba stworzyc´ taka˛ infrastrukture.˛ Minimum zadan´ przypadajac˛ ych na serwer wydruku bedzie˛ pełnienie roli centralnego Spooling Host, który moze˙ swiadczy´ c´ takze˙ inne usługi. Opisany ponizej˙ sposób migracji zwiazan˛ y jest wyłacznie˛ z jednym systemem, tj. z „Com- mon UNIX Printing System“. Jest tak, gdyz˙ praktycznie we wszystkich systemach uniksowych, zdołał sie˛ on przebic´ na pierwsze miejsce sposród´ innych systemów drukowania. CUPS został niedawno przystosowany równiez˙ do pracy w systemie operacyjnym Mac OS X ﬁrmy Apple. W przypadku Linuksa CUPS jest de facto standardem we wszystkich duzych˙ dystrybucjach (SuSE, Debian, Mandrake, RedHat, itd.). W przypadku, gdy istniejace˛ srodo´ wisko wydruku składa sie˛ z klientów windowsowych, ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 99 które maja˛ dostep˛ do swojego serwera wydruku NT-Print-Server, ocenilismy´ mozliwo˙ sci´ przeprowadzenia migracji po stronie serwera.

3.3.4.1 Wymagania odnosnie´ funkcjonalnosci´

Poniewaz˙ drukowanie jest czesto˛ zadaniem typu „mission critical“, istnieja˛ duze˙ wymagania odnosnie´ infrastruktury technicznej i wewnetrznej˛ organizacji:

◦ niezawodna praca

Nieodzowne jest chocby´ minimalne zabezpieczenie przed awaria;˛ mozliwo˙ s´c´ łatwego zintegrowania rozwiaza˛ n´ zastepczych˛ - gotowos´c´ do pracy (drukowania) musi byc´ zagwarantowana niezaleznie˙ od obecnosci´ specjalistów IT.

◦ wierne odwzorowanie - odpowiednia jakos´c´ wydruku

Kryteriami oceny własciwej´ jakosci´ sa˛ prawidłowe czcionki, graﬁka bez zniekształcen,´ prawdziwe kolory.

◦ jakos´c´ wydruku

Renderowanie powinno odbywac´ sie˛ z minimalna˛ rozdzielczosci´ a.˛

◦ accounting

Nalezy˙ stworzyc´ mozliwo˙ s´c´ kontrolowania kosztów polegajac˛ a˛ na szczegółowym protokołowa- niu wykonywanych zadan.´

◦ kwoty wymaganie majace˛ na celu kontrole˛ kosztów bad˛ z´ ich ograniczenie.

◦ obejscie´ zadan´ drukowania

Nalezy˙ zapewnic´ mozliwo˙ s´c´ bezproblemowego korzystania z drukarki zastepczej,˛ takiego które nie wymaga ponownego przesłania zlecenia wydruku przez klienta (wazne˙ : W wypadku, gdy uzywana˙ jest drukarka zastepcza˛ innego typu, mimo wszystko, powinna ona byc´ w stanie wy- drukowac´ wysłany do niej plik.

◦ ponowienie zadania wydruku ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 100

W srodo´ wisku zapewniajac˛ ym centralne powielanie, czesto˛ wymagane jest ponowne wykonanie zakonczone´ go juz˙ zlecenia drukowania. Aby skorzystac´ z opcji „Printing on Demand“ oraz wtórnego zwiekszenia˛ nakładu, lub w celu unikniecia˛ problemów technicznych (np. blokada papieru / brak pradu)˛ i błedów˛ w obsłudze (np. uzycie˙ papieru o niewłasciwym´ kolorze), nalezy˙ skorzystac´ z funkcji realizujacej˛ powtórny wydruk.

◦ Job History

Historia zadan´ dokumentuje przebieg wszystkich procesów drukowania. Dzieki˛ niej pod koniec roku mozna˙ uzyskac´ liczby wiele mówiace˛ o łacznej˛ ilosci´ zrealizowanych zadan´ wydruku (planowanie budzetu),˙ ich rozłozeniu˙ na poszczególne modele drukarek i miejsca (optymalizacja podziału zasobów) oraz maksymalnym obcia˛zeniu˙ (w którym miejscu maja˛ sens nowe inwesty- cje)

◦ Integracja z rozwiazaniami˛ własnoscio´ wymi

Czesto˛ zachodzi potrzeba przejecia˛ albo zintegrowania „starych“ lub nowych specjalistycznych rozwiaza˛ n.´ Nalez˙ sprawic,´ by było to mozliwe˙ bez wiekszych˛ problemów.

◦ przejrzystos´c´ kosztów i ich kontrola

- z nich nie wolno rezygnowac,´ zarówno podczas przeprowadzania migracji, jak i w pózniejszej´ pracy.

◦ bezpieczenstwo´

Nie mozna˙ dopusci´ c´ do „podsłuchiwania“ zaufanych danych (dotyczy to takze˙ przechwytywania plików przeznaczonych do wydruku).

◦ autoryzacja

Okreslone´ drukarki powinny byc´ udostepniane˛ wyłacznie˛ wyznaczonym grupom uzytko˙ wników, wzglednie˛ pracowac´ z ograniczonymi „zaufanymi“ ustawieniami (1200 dpi w trybie full-screen na papierze fotograﬁcznym) dla okreslon´ ych uzytko˙ wników (albo byc´ całkowicie disabled).

◦ drukowanie „on hold“

Drukowanie przesuniete˛ w czasie lub „nocne“ (automatycznie sterowane batch-jobs). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 101

◦ bez specjalnego oprogramowania umozliwiaj˙ ace˛ go podglad˛

W idealnym przypadku szybki podglad˛ zadan´ oczekujac˛ ych w kolejce wydruku realizowany jest z poziomu przegladarki˛ internetowej. Najlepiej, aby z „kazde˙ go miejsca“ zagwarantowany był dostep˛ do linii polecen.´ Najlepsza sytuacja jest wtedy, gdy nie dotyczy to kazde˙ go, lecz tylko uprawnionych osób.

◦ integracja ze srodo´ wiskami heterogenicznymi

Oprogramowanie realizujace˛ wydruk musi obsługiwac´ wiele protokołów, poniewaz˙ w praktyce nie istnieje ogólnie przyjety˛ standard. Zdolnos´c´ do wszechstronnej współpracy musi dotyczyc´ zarówno komunikacji z klientem (powinien on zachowac´ dowolnos´c´ wyboru protokołu za pomoca˛ którego przesyła dane do drukowania), jak tez˙ komunikacji z drukarka˛ docelowa˛ bad˛ z´ serwerami wydruku typu second-level (które czesto˛ sa˛ „starodawne“ i dlatego wymagaja˛ zachowania odpowiednich konwencji). Dodatkowo musi byc´ zachowana ogólna obsługa przyszłego standardu IPP.

3.3.4.2 Obsługa standardów wyrózniaj˙ acych˛ sie˛22 w procesie drukowania

Korzystajac˛ z zaproponowanych rozwiaza˛ n´ technicznych, nalezy˙ spełnic´ ponizsze˙ wymagania odnosnie´ funkcjonalnosci.´ Wazne˙ jest przy tym da˛zenie˙ do uzyskania otwartosci´ przez konsolidacje˛ z istniejac˛ ymi i uznanymi otwartymi standardami. Jednoczesnie,´ na czas migracji, nalezy˙ zagwarantowac´ wymagane wsparcie dla protokołów uzywan˙ ych wczesniej´ albo protokołów własnoscio´ wych (oraz urzadze˛ n,´ które z nich korzystaja).˛ Bardzo dobrze nadaje sie˛ do tego system wydruku CUPS, system wydruku, który dzieki˛ zaimplementowanemu IPP (Internet Printing Protocol) moze˙ pełnic´ role˛ protokołu ponad platformowego. IPP stosowany jest jako protokół ła-˛ czac˛ y serwery i klienty CUPS z nowoczesnymi drukarkami obsługujac˛ ymi bezposrednie´ wsparcie IPP, jako medium dla komunikacji i transmisji danych. Podczas komunikacji ze starszymi drukarkami albo serwerami wydruku mozna˙ skorzystac´ z modułów CUPS, tak zwanych „Bac- kEnds“. Moduły te umozliwiaj˙ a˛ komunikacje˛ za pomoca˛ innych protokołów. Na rysunku 3.5 przedstawiony został schemat korzystania z protokołów na rózn˙ ych interfejsach. Ich działanie opisalismy´ ponizej.˙

LPR/LPD Tradycyjny protokół słuz˙ac˛ y do transmisji danych wydruku [od klienta do serwera wydruku,

22Standardy otwarte, jak i zamkniete.˛ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 102

z serwera do serwera i z serwera do drukarki docelowej (sieciowej) lub tez˙ z klienta bezposrednio´ do drukarki] ma wiele wad: nie jest szyfrowany, nie jest autoryzowany, nie gwarantuje stabilnej pracy, nie obsługuje dwukierunkowej komunikacji (np. komunikatów zwrotnych z drukarki), brak „własciwe´ go“ standardu (rózne˙ implementacje, które z powodu miejscowego braku kompatybilnosci´ stwarzaja˛ trudnosci).´

IPP Internet Printing Protocol jest internetowym standardem drukowania zarówno w sieci lokalnej (LAN), jak i w sieci rozległej (WAN, Internet). Protokół ten oferuje wszystkie wymagane mozliwo˙ sci´ komunikacji, tj. klient - serwer, serwer - serwer, serwer - drukarka docelowa oraz klient - drukarka docelowa. Ostatnia˛ i jedyna˛ wia˛z˙ac˛ a˛ specyfikacja˛ jest IPP-1.1. Protokół IPP powstał w wyniku prac grupy roboczej (PWG) składajacej˛ sie˛ z przedstawicieli systemów operacyjnych i systemów drukowania oraz producentów oprogramowania z Europy, USA i Japonii. Jego standaryzacji dokonał IETF. Jest on juz˙ obsługiwany przez wszystkie aktualnie dostepne˛ drukarki sieciowe. Jednak dopóki dostepne˛ sa˛ „stare“ urzadzenia˛ oparte na LPR / LPD (które bed˛ a˛sprawne jeszcze przez wiele lat), odpowiednie zmiany nalezy˙ wprowadzac´ tylko tam, gdzie ma to bezposredni´ sens. Wskazówka: Nowsze wersje systemu operacyjnego Windows firmy Microsoft maja˛wbudowana˛ pewnego rodzaju obsługe˛ IPP po stronie klienta (Windows 98SE, Windows ME, Windows 2000, Windows XP) albo mozna˙ je nieodpłatnie przystosowac´ (Windows NT, Windows 95, Win- dows 98). Dzieki˛ temu systemy te moga˛ podczas drukowania „całkiem naturalnie“ korzystac´ z serwera CUPS. Jednakze˙ Microsoft oferuje obecnie tylko implementacje˛ IPP w wersji 1.0, która nigdy nie została uznana przez IETF za „recommended standard“, lecz była jedynie podstawa˛do dyskusji nad pewnym stanem przejscio´ wym, np. nie definiowała wazne˙ go aspektu szyfrowania danych przeznaczonych do wydruku oraz sposobu autoryzacji uzytko˙ wników. Z tego powodu serwer CUPS, w przypadku bezposrednie´ go udostepniania˛ klientowi windowsowemu swoich usług, musi rezygnowac´ z autoryzacji. Jesli´ CUPS stosowany jest wspólnie z Samba,˛ wówczas wymagana, ewentualna autoryzacja klienta windowsowego moze˙ byc´ realizowana dzieki˛ me- chanizmom zaimplementowanym na serwerze plików. Dla srodo´ wisk o wyzszych˙ wymaganiach wzgledem˛ bezpieczenstwa´ przeznaczone sa,˛ dostepne˛ na rynku, komercyjne klienty CUPS dla Windows.

Socket/AppSocket AppSocket (czesto˛ znany pod nazwa˛ „HP Jet Direct“) jest dedykowanym protokołem transmisji danych wydruku. Jest on wydajniejszy i mniej zawodny niz˙ LPR / LPD; umozliwia˙ w ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 103

pewnym stopniu komunikacje˛ dwukierunkowa˛ i jest szybszy. Istnieja˛ zarówno wolne, jak i komercyjne narzedzia˛ administracyjne dla JetDirect słuz˙ace˛ do zarzadzania˛ struktura˛ duzych˙ sieci (np. HP WebJet Admin). Jednakze˙ nie oferuje on ani mozliwo˙ sci´ szyfrowania danych wydruku, ani autoryzacji uzytko˙ wników. Zwrotne komunikaty o stanie drukarki realizowane sa˛w praktyce tylko w kierunku serwer - drukarka lub w przypadku połaczenie˛ bezposrednie´ go w kierunku klient - drukarka.

SMB/CIFS Klienty windowsowe uzywaj˙ a˛ tego protokołu do transmisji danych wydruku do serwera wydruku (albo innych komputerów z Windows, o ile oferuja˛ one „udostepnione“˛ drukarki). Czesto˛ droga od najblizsze˙ go komputera z Windows do drukarki (sieciowej) docelowej musi byc´ ponownie regulowana przez inny protokół (chyba, ze˙ podłaczona˛ jest ona lokalnie - przez interfejs równoległy, USB, FireWire lub interfejs szeregowy).

MS-RPC Klienty windowsowe, pocza˛wszy od NT4, potraﬁa˛ uzywa˙ c´ tego protokołu do transmisji danych wydruku do Windows-Print-Server (od wersji NT4). Za pomoca˛ metod RPC mozna˙ takze˙ wykonywac´ automatyczna˛ instalacje˛ sterowników na klientach, o ile serwer wydruku dysponuje odpowiednimi plikami. („Ładowanie“ sterowników z komputera klienta na serwer wydruku przez administratora równiez˙ opiera sie˛ na RPC). Od czasu, gdy Samba potraﬁ zarzadza˛ c´ SMB / CIFS, mozliwe˙ jest takze˙ wykorzystywanie go przez CUPS.

Obsługa wielu protokołów w CUPS (rysunek pogladowy)˛ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 104

Rysunek 3.5: Drukowanie z CUPS

3.3.4.3 Integracja w sr´ odowiskach klienckich Windows

Wskazówka odnosnie´ integracji CUPS i Samby Obsługa CUPS jest zintegrowana z Samba˛ w optymalny sposób, znacznie lepiej niz˙ inne dostepne˛ uniksowe systemy drukowania. Jest to jedyny system wydruku, który posiada funkcje wbudowane w biblioteke˛ (software-library). Dzieki˛ temu inne programy moga˛ korzystac´ z tych funkcji „linkujac“˛ biblioteke.˛ Własnie´ Samba wykorzystuje te˛ własciwo´ s´c.´ Jest ona domyslnie´ zlinkowana z libcups. Serwer wydruku Samba moze˙ dzieki˛ temu przekazywac´ przychodzace˛ zlecenia wydruku do serwerów wydruku CUPS przez IPP. Moga˛ byc´ one zainstalowane na innych hostach wyznaczonych do obsługi wydruku albo na tym samym serwerze, co Samba. Stosowa- nie IPP odbywa sie˛ tu w całkowicie przejrzysty sposób, zarówno dla administratora, jak i dla uzytko˙ wnika i nie wymaga dalszej konﬁguracji.

SYSTEM OPERACYJNY KLIENTA POŁA˛CZENIE 23Publicznie dostepne˛ na stronie http://www.linuxprinting.org/kpfefle/ Linux-Kongress2002/Tutorial/. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 105

Win98SE dostarczany z IPP (wersja 1.0) Win98 po wyposazeniu˙ w IPP Windows 9x Przez SMB / CIFS (z pomoca˛ Samby) Przez LPR / LPD (wymaga doinstalowania klienta LPR) Po wyposazeniu˙ w IPP Windows NT Przez SMB / CIFS + MS-RPC (z pomoca˛ Samby) Przez LPR / LPD Wbudowany IPP (wersja 1.0) Windows 2000 / XP Przez SMB / CIFS + MS-RPC (z pomoca˛ Samby) Przez LPR / LPD Citrix Metaframe Po wyposazeniu˙ w IPP i Windows Terminal - Server Przez SMB / CIFS + MS-RPC (z pomoca˛ Samby) Przez LPR / LPD GNU/Linux Wbudowane CUPS i IPP Przez LPR / LPD UNIX Po wyposazeniu˙ w CUPS i IPP Przez LPR / LPD IPP wbudowany w NPDS (od wersji Novell 5.0) NetWare Przez SMB / CIFS (z pomoca˛ Samby) Przez LPR / LPD Przez AppleTalk Mac OS 9 Przez LPR / LPD (wymaga doinstalowania klienta LPR) Mac OS X Przez CUPS i IPP wbudowany od wersji Mac OS X 10.2 Przez LPR / LPD (wymaga doinstalowania klienta LPR)

Tablica 3.16: Połaczenie˛ klienta z CUPS

Pobieranie i instalowanie sterowników przez klientów za pomoca˛ „Point and Print“ Kombinacja CUPS i Samby obsługuje automatyczne pobieranie sterowników dla klientów Windows metoda˛ „Point and Print“. W tym celu konﬁguracja Samby musi odwzorowywac´ NT- Print-Server. Zostało to bardzo dokładnie opisane w Samba HOWTO Collection. Uzyskanie od- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 106

powiedniej konﬁguracji nie wymaga duzej˙ ingerencji administratora. Obsługiwane jest równiez˙ sci´ aganie˛ sterowników z maszyny klienta. Sterowniki drukarek gromadzone sa˛na serwerze Samba. Ich automatyczna instalacja na systemach klienckich wykonywana jest w tle, o ile uzytko˙ wnik szuka drukarki w otoczeniu sieciowym po raz pierwszy albo wybiera ja˛ z menu kontekstowego „Connect . . . “ (klikajac˛ prawy przycisk myszy“).

Automatyczna instalacja sterowników za pomoca˛ skryptów logowania Jeszcze wygodniej maja˛uzytko˙ wnicy i administratorzy pracujac˛ y w ramach jednej domeny, jesli´ uzywaj˙ a˛skryptów logowania. Wystarczy utworzyc´ skrypt zawierajac˛ y zaledwie jeden wiersz: rundll32 printui.dll,PrintUIEntry /in /n„\\SAMBASERVERNAME\nazwazasobu-drukarki . Odpowiednia drukarka zostanie automatycznie zainstalowana dla logujace˛ go sie˛ uzytko˙ w- nika (innymi mozliwo˙ sciami´ oferowanymi przez skrypty sa:˛ instalacja wielu drukarek, wyzna- czenie drukarki domyslnej,´ usuwanie zbedn˛ ych kolejek drukowania itd.). Dzieki˛ temu zarzadza-˛ nie sterownikami drukarek jest komfortowe a administratorzy maja˛mniej pracy. Rózn˙ ym grupom uzytko˙ wników mozna˙ w ten sposób, tj. wykorzystujac˛ rózne˙ skrypty logowania, przypisac´ róznie˙ przystosowane srodo´ wiska.

Bezpieczenstwo´ i autoryzacja Jesli´ korzystamy z CUPS, istnieje mozliwo˙ sć´ szyfrowania komunikacji pomiedzy˛ klientem. a serwerem. Gdy stosowany jest protokół IPP, do szyfrowania przesyłanych danych mozna˙ wykorzystac´ SSL 3 albo TLS. Inna mozliwo˙ sć´ spełnienia podwyzszon˙ ych wymagan´ bezpieczenstwa´ polega na zastosowaniu autoryzacji uzytko˙ wników za pomoca˛ LDAP. CUPS obsługuje interfejs LDAP, który mozna˙ wykorzystac´ do kierowania nadawaniem praw dostepu˛ w systemie drukowania. Usługe˛ katalogowa˛ mozna˙ dodatkowo zastosowac´ do skonfigurowania praw dostepu˛ i kwot dla konkretnego uzytko˙ wnika. Klienci Windows na ogół nie autoryzuja˛ sie˛ przez CUPS, lecz przez Sambe.˛ Autoryzacja ta nastepuje˛ automatycznie podczas drukowania przez Sambe,˛ która przejmuje w tym czasie kontrole˛ nad zarzadzaniem˛ prawami dostepu.˛ W takim przypadku trzeba tylko w odpowiedni sposób zapewnic´ serwerowi Samba mozliwo˙ sć´ korzystania z serwera wydruku CUPS (własciwa´ autoryzacja). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 107

Rozgłaszanie drukarek obsługiwanych przez CUPS w LDAP i Active Directory Samba moze˙ wpisywac´ swoje usługi do katalogu LDAP albo do Active Directory. Korzysci´ z tego czerpia˛ oczywiscie´ drukarki obsługiwane przez CUPS, a takze˙ CUPS-Print-Serwer. Moz-˙ liwa jest dalsza rozbudowa integracji ze srodo´ wiskiem AD (albo mocno wzorowanym na nim srodo´ wiskiem LDAP). Najblizsza˙ wersja CUPS, która jest w stanie „sama z siebie“ obsłuzy˙ c´ połaczenie˛ z LDAP znajduje sie˛ juz˙ w zaawansowanej fazie beta.

Niezalezny˙ od platformy dostep˛ przez WWW CUPS posiada „wbudowany“ Web-Interface. Dostep˛ do niego uzyskac´ mozna˙ wywołujac,˛ za pomoca˛ przegladarki˛ internetowej, adres: „http://CUPS-PRINTSERVER:631/“. W ten sposób wszyscy uzytko˙ wnicy moga˛ uzyskac´ dostep˛ do informacji o funkcjach serwera wydruku. Stan- dardowo uzytko˙ wnicy moga˛ kontrolowac´ stan zlecen´ drukowania, przerywac´ je, wznawiac´ oraz ponawiac,´ etc. (w zalezno˙ sci´ od kazdorazo˙ wej konfiguracji). W odniesieniu do drukarek / kolejek drukowania, administratorzy lub pracownicy help-desk, którzy korzystaja˛z Web-Interface, moga˛je zakładac,´ usuwac,´ zmieniac´ konfiguracje,˛ uruchamiac´ i zatrzymywac,´ zamykac´ / otwierac´ oraz równowazy˙ c´ zlecenia wydruku, odkładac´ i ponownie uruchamiac.´ Mozliwo˙ sci´ obsługi drukowania przez Web-Interface mozna˙ ograniczac´ albo rozszerzac´ w zalezno˙ sci´ od konfiguracji serwera CUPS. Web-Interface podlega takim samym zasa- dom kontroli praw dostepu,˛ jak ogólne zasoby CUPS. Kazdy˙ obiekt serwera wydruku (dostep˛ do własnych zlecen´ albo pojedynczych drukarek, dostep˛ do wszystkich drukarek albo wszystkich zlecen´ itd.) mozna˙ wyposazy˙ c´ w rózne˙ prawa dostepu:˛ „Uzytko˙ wnik Kowalski ma prawo administrowac,´ ale tylko wtedy, gdy korzysta z komputerów A albo B“, „Wszystkim uzytko˙ wnikom wolno usuwac´ własne zlecenia wydruku, ale nie cudze“, itd.)

3.3.4.4 Mozliwo˙ sci´ dostosowawcze

Oprócz bezposrednie´ go zestawu funkcji oferowanych przez CUPS system ten mozna˙ prosto i w na rózne˙ sposoby rozszerzyc´ o ﬁltry i BackEnds.

Filtry Wewnetrznie˛ CUPS uzywa˙ systemu plików o modularnej budowie. Pracuje on na otwartych interfejsach. Moze˙ byc´ w kazdej˙ chwili rozszerzony. W tym celu mozna˙ skorzystac´ z dowolnych jezyków˛ skryptowych (Shell, Perl, Python) albo jezyków˛ programowania (C, C++, Java etc.). Za pomoca˛ wrapper-scripts w bardzo łatwy sposób mozna˙ takze˙ włacza˛ c´ własnoscio´ we programy ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 108

w postaci binarnej.

BackEnds Nowe BackEnds mozna˙ „dokowac“´ w prosty sposób. Czasami, gdy istnieje potrzeba dostosowania systemu do specjalnych wymagan´ danego srodo´ wiska (np. automatyczna replikacja okreslon´ ych zlecen´ wydruku w innym dziale, np. w celu składowania listów słuzbo˙ wych w archi- wum), a czasami ze wzgledu˛ na atrakcyjnos´c´ nowosci´ technicznych (Wireless LAN, Bluetooth, FireWire).

3.3.4.5 Jezyki˛ opisu stron

CUPS uzywa˙ do sterowania drukarkami tak zwanych PostScript Printer Descriptions (PPD). Specyfikacja PPD została pierwotnie zdefiniowana przez firme˛ Adobe i jest praktycznie obsłu- giwana przez kazdy˙ system wydruku, który steruje drukarkami postscriptowymi i wykorzystuje ich specyficzne opcje (duplex, wybór zasobnika, perforacja, zszywanie itd.). Tego typu pliki PPD istnieja˛ wraz z CUPS takze˙ dla drukarek, które nie posiadaja˛ własnego interpretera postscriptu. CUPS uzywa˙ tych dobrze zdefiniowanych opisów drukarek podczas definiowania odpowiednich ustawien´ konfiguracyjnych poprzez Web-Frontend albo nakładki konfiguracyjne klientów. Dla drukarek, które nie obsługuja˛postscriptu, serwer CUPS konwertuje dane nadesłane przez klienta uzywaj˙ ac˛ w tym celu tak zwanych „filtrów“. W Linuksie program ghostscript zawiera niezwykle wszechstronne zestawy filtrów umozliwiaj˙ ace˛ konwertowanie z jezyka˛ PostScript do rózn˙ ych, specyficznych dla producentów i urzadze˛ n,´ jezyków˛ . Dopasowana wersja ghostscript jest takze˙ cze˛sci´ a˛ CUPS.

3.3.4.6 Techniczna zmiana funkcji sterownika

Przekształcanie pliku przeznaczonego do wydruku w nadajace˛ sie˛ do wydruku bitmapy, mozne˙ byc´ realizowane na dwa rózne˙ sposoby, tzn:

◦ Funkcje sterownika wykonywane sa˛ w całosci´ po stronie klienta.

Plik do wydruku przygotowywany jest po stronie klienta. Serwer wydruku realizuje jedynie funkcje spooling dla danych wydruku. Sterowniki moga˛ byc´ oferowane klientowi do sci´ agni˛ ecia˛ i automatycznej instalacji.

◦ Przygotowanie danych do wydruku odbywa sie˛ na serwerze wydruku. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 109

Dane wydruku przesyłane sa˛z klientów w do serwera wydruku w formacie PostScript. Na klientach konieczny jest odpowiedni sterownik PostScript, moze˙ on byc´ udostepnian˛ y na serwerze do automatycznej instalacji. Po takim przygotowaniu dane wydruku przesyłane sa˛ z serwera do za- danych drukarek. O ile drukowanie ma nastapi˛ c´ na drukarce, która nie obsługuje PostScript, proces przygotowywania wydruku realizowany jest za pomoca˛ specjalnego oprogramowania (patrz takze˙ 3.3.4.5). Drugi model, w przeciwienstwie´ do pierwszego, oferuje wiecej˛ korzysci:´

◦ automatyczna˛ obsługe˛ wszystkich urzadze˛ n´ postscriptowych wraz ze wszystkimi opcjami drukowania (tak jak w Windows NT).

◦ dodatkowa˛ obsługe˛ ogólnie stosowanych drukarek niepostscriptowych (w zalezno˙ sci´ od zastosowania ghostscript albo innych pakietów sterowników).

◦ automatyczny accounting

Podczas logowania kazdej˙ stronie automatycznie przypisywany jest czas wydruku, nakład, drukarka docelowa, nazwa uzytko˙ wnika, ID-procesu wydruku i IP nadawcy, które moga˛ byc´ wykorzystywane przy pózniejszym´ ocenianiu (kontrola kosztów, statystyki).

◦ kwotowanie

Mozliwo˙ s´c´ ustalania kwot na wykorzystywanie przez uzytko˙ wników danej drukarki (okreslenie´ ilosci´ stron i / oraz ilosci´ danych, które, po przesłaniu przez konkretnego uzytko˙ wnika, maja˛ zostac´ zaakceptowane przez drukarke).˛

◦ funkcje˛ reprint

Zlecenia gotowe do druku przechowywane sa˛ przez pewien czas. Ich realizacja nie wymaga od klienta ponownego szukania z˙adane˛ go pliku, otwierania i przesyłania go. Dotyczy to zarówno pierwszego, jak i ponownego drukowania.

◦ funkcje˛ redirect

Pliki przeznaczone do druku mozna˙ w kazdej˙ chwili przekierowac´ do innej drukarki docelowej (nawet wówczas, gdy pierwotna drukarka była drukarka˛ postscriptowa˛ a nowa nie obsługuje PostScript). Opcje wydruku mozna˙ dostosowac´ do nowego urzadzenia˛ docelowego.

◦ konsolidacja sterowników ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 110

W efekcie konco´ wym wszystkie klienty uzywaj˙ a˛tego samego sterownika Core-PostScript (który jest modyﬁkowany tylko przez plik ASCII, czyli „PPD“). Niniejszy model zawiera nastepuj˛ ace˛ ograniczenia:

◦ wymaga wiekszej˛ ilosci´ zasobów

Centralne przygotowywanie danych wydruku na serwerze wymaga wiecej˛ RAM, lepszej CPU oraz zajmuje wiecej˛ miejsca na twardym dysku (jego ilos´c´ mozna˙ z góry okresli´ c,´ jesli´ tylko znana jest oczekiwana wielos´c´ wydruku.)

Niewielkie ograniczenia w przypadku obsługiwanych modelów drukarek Wprawdzie wiekszo˛ s´c´ stosowanych drukarek jest obsługiwana - jednakze˙ istnieja˛ wyjatki.˛ Liste˛ obsługiwanych modelów i producentów mozna˙ znalez´c´ w bazie danych urzadze˛ n´ na stronie http://Linuxprinting.org.

3.3.4.7 Architektury systemu drukowania

Ponizej˙ nakreslone´ zostały potencjalne architektury wykorzystywane wraz z CUPS, przy czym przy wyborze rózn˙ ych scenariuszy stosowania decydujace˛ znaczenie odegrało uzyskanie zwiek-˛ szonej stabilnosci:´

◦ Serwer:

Kazdy˙ komputer z CUPS komunikujac˛ y sie˛ bezposrednio´ z drukarka,˛ moze˙ oferowac´ funkcje wydruku innym komputerom jako usługe,˛ co znaczy, ze˙ moze˙ on byc´ serwerem CUPS. W tym celu wymagane sa˛ odpowiednie PPDs oraz ﬁltry słuz˙ace˛ do własciwe´ go przygotowywania pli- ków do druku.

◦ Klient:

Kazdy˙ komputer, który przesyła dane wydruku do serwera, jest klientem CUPS. Klient CUPS nie potrzebuje, lokalnie, ﬁltrów ani PPDs. Jesli´ jednak na kliencie maja˛byc´ ustalane opcje wydruku, wówczas PPDs sa˛ automatycznie wysyłane z serwera na klienta.

◦ Zero administration dla natywnych klientów CUPS: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 111

Serwery CUPS rozgłaszaja˛ do klientów znajdujac˛ ych sie˛ wewnatrz˛ sieci informacje o zainstalowanych drukarkach. Dzieki˛ temu klienty wiedza,˛ z której drukarki w sieci moga˛ korzystac.´ Powyzsze˙ informacje przesyłane sa˛ za pomoca˛ UPD-Broadcasting. Alternatywnie klient moze˙ wysyłac´ konkretne zapytania do serwerów (Polling). Polling moze˙ byc´ takze˙ stosowany przez serwery, które sa˛oddzielone za pomoca˛Routera. Serwery, które znajduja˛sie˛ w rózn˙ ych sieciach, mozna˙ skonﬁgurowac´ jako BrowseRelay i pobierac´ dane o dostepn˛ ych drukarkach, a nastepnie˛ przesyłac´ je dalej do klientów własnej domeny Broadcast.

◦ Clustering - zapewnienie ciagło˛ sci´ pracy i ochrona przed Failover:

Dwa albo wiecej˛ serwerów CUPS mozna˙ skonfigurowac´ w taki sposób, aby zapewnic´ ciagło˛ sć´ pracy usług wydruku. Cel ten mozna˙ osiagn˛ a˛c´ konfigurujac˛ serwery z tymi samymi drukarkami i nazwami drukarek. Na serwerach CUPS automatycznie budowane sa˛ wewnetrzne˛ klasy, które składaja˛ sie˛ z drukarek noszac˛ ych te same nazwy. Ten z serwerów, który jako pierwszy gotowy jest do rozpoczecia˛ procesu drukowania, przejmuje zlecenie wydruku nadesłane przez klienta i przesyła je do drukarki. Konfiguracje˛ taka˛ mozna˙ takze˙ ustawic´ recznie˛ przez stworzenie odpowiednich klas, przy czym klasy mozna˙ wówczas utworzyc´ takze˙ z drukarek majac˛ ych rózne˙ nazwy.

3.3.5 Migracja kontynuacyjna

3.3.5.1 Windows 2000

W niniejszym rozdziale przedstawiamy, pod katem˛ oferowanych „Print Services“, nastepc˛ e˛ Win- dows NT4, tj. Windows 2000.

Nowe funkcje Wraz z Windows 2000 w obszarze Print Services wprowadzono kilka zmian. Główne z nich zostały wyszczególnione ponizej:˙

◦ Standard TCP/IP Port Monitor

◦ Internet Printing

◦ Publikowanie w Active Directory

W kolejnych paragrafach znalez´c´ mozna˙ szerszy opis wprowadzonych zmian. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 112

Komunikacja pomiedzy˛ serwerem a drukarka˛ Wraz z Windows 2000 ﬁrma Microsoft wprowadziła SPM (Standard TCP / IP Port Monitor). SPM jest kompatybilny z SNMP. Oprócz SPM istnieje nadal port LPR. SPM oferuje w porów- naniu z LPR mozliwo˙ s´c´ uzyskiwania szczegółowych informacji o stanie. SPM moze˙ korzystac´ z dwóch rózn˙ ych protokołów serwerów wydruku: RAW albo LPR. Standardem dla wiekszo˛ sci´ drukarek jest RAW.

Publikowanie w Active Directory Za pomoca˛Active Directory mozna˙ udostepnia˛ c´ zasób - drukarke˛ (na serwerach Windows NT albo 2000) w taki sposób, ze˙ uzytko˙ wnik nie wie, na którym serwerze zasób ten sie˛ znajduje. Uzytko˙ wnik moze˙ po prostu wydac´ polecenie przeszukiwania AD.

Internet Printing Wraz z Windows 2000 wprowadzono opcje˛ umozliwiaj˙ ac˛ a˛ publikowanie i instalowanie drukarek w sieci WWW.

Sr´ odowiska mieszane Na serwerach Windows NT nie mozna˙ składowac´ sterowników dla klientów Windows 2000 albo XP. W takich srodo´ wiskach sterowniki musza˛ byc´ instalowane oddzielnie. Na serwerach Windows 2000 mozna˙ składowac´ sterowniki dla klientów Windows NT. Jednak transmisja ustawien´ danego urzadzenia˛ moze˙ skonczy´ c´ sie˛ niepowodzeniem w sytuacji, gdy korzysta sie˛ (trzeba skorzystac´) ze sterowników dostarczanych przez producenta urzadzenia.˛ Przy- czyna˛tego jest przejscie´ sterowników drukarek z NT - Kernel Mode - do User Mode w Windows 2000.

Serwery Windows 2003 W czasie, gdy powstawał niniejszy poradnik, nie były znane nowosci´ odrózniaj˙ ace˛ Print Se- rvices z Windows 2003 od tych z Windows 2000.

3.4 Autoryzacja

3.4.1 Przeglad˛

Ponizsze˙ oceny techniczne prowadza˛ do wniosku, ze˙ zarówno w przypadku migracji kontynuacyjnej, jak i zastepuj˛ acej˛ oraz w srodo´ wiskach heterogenicznych mozliwe˙ jest zapewnienie bez- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 113

piecznej autoryzacji uzytko˙ wników i hostów za pomoca˛ dostepne˛ go oprogramowania pomocni- czego. Istotna˛ role˛ w tym procesie odgrywaja˛ Samba oraz OpenLDAP. Samba jako alternatywa dla serwera Windows NT oferuje klientom w srodo´ wisku systemów mieszanych podobna˛ funkcjonalnos´c,´ jak w przypadku głównego kontrolera domeny opartego na NT. Samba, bed˛ ac˛ baza˛ danych kont uzytko˙ wników, moze˙ korzystac´ z Open LDAP jako usługi katalogowej. Z punktu widzenia klientów windowsowych, Samba wraz z OpenLDAP pełni funkcje˛ domeny Windows NT. Jesli´ chodzi o administrowanie informacjami o grupach, hostach i uzytko˙ wnikach Samba realizuje rozwiazanie˛ oparte na usługach katalogowych wraz ze wszystkimi wynikajac˛ ymi z tego zaletami. Na przykład w przypadku wykorzystania powyz-˙ szego rozwiazania,˛ przestaje istniec´ problem skalowalnosci´ znany z Windows NT, który czesto˛ wymaga podziału infrastruktury pomiedzy˛ rózne˙ domeny. Za pomoca˛ Samby mozna˙ ustalac´ stopien´ zaufania pomiedzy˛ rózn˙ ymi domenami. Moz-˙ liwe jest takze˙ stosowanie WINS-Service. Samba 3.0 udostepnia˛ program słuz˙ac˛ y do replikacji WINS. Program ten nie został jeszcze w pełni przetestowany. Aby zachowac´ kompatybilnosci´ Samba obsługuje rozwiazanie˛ oparte na PDC i BDCs. Jednak obsługa powyzszych˙ ogranicza sie˛ do tego, ze˙ serwer Samba widziany jest przez klientów windowsowych, w zalezno˙ sci´ od konﬁ- guracji, jako PDC bad˛ z´ BDC. Sam Samba nie obsługuje replikacji bazy danych SAM pomiedzy˛ PDC i BDC. Jednakze,˙ ze wzgledu˛ na zapisywanie SAM w katalogu LDAP, replikacja SAM moze˙ byc´ realizowana przez OpenLDAP. W przypadku migracji kontynuacyjnej, autoryzacja w srodo´ wiskach systemów mieszanych nie podlega ograniczeniom. Istnieja˛ one na styku technologii Samba / OpenLDAP - Active Di- rectory oraz Samba / OpenLDAP - autoryzacja Kerberos. Nalezy˙ przy tym podkresli´ c,´ ze˙ nie jest mozliwe˙ wykonanie autoryzacji Kerberos z klientów Windows 2000/XP do Samby / OpenLDAP, lecz trzeba w takim przypadku skorzystac´ z proto- kołu NTLM. Dopóki Microsoft bedzie˛ wspierał powyzsze˙ rozwiazanie˛ umozliwiaj˙ ace˛ klientom windowsowym wspomniana˛ integracje,˛ zapewnienie jej nie bedzie˛ stanowic´ problemu. Rozwia-˛ zaniu temu mozna˙ przeciwstawic´ współprace˛ linuksowego serwera Kerberos z domena˛ Active Directory, dzieki˛ czemu mozna,˙ na bazie Linuksa, stworzyc´ jednolity Credential-Management dla Windows i Linuksa. W srodo´ wisku opartym wyłacznie˛ o Linuksa mozna˙ stosowac´ autoryzacje Kerberos. Alter- natywnie mozna˙ takze˙ realizowac´ autoryzacje˛ za pomoca˛ OpenLDAP. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 114

3.4.2 Punkt wyjscia´ - Windows NT 4

Tematem niniejszego podrozdziału jest autoryzacja, wzglednie˛ usługi zgłoszeniowe produktów Microsoft. Zostana˛ tu ocenione miedzy˛ innymi nastepuj˛ ace˛ aspekty:

◦ bazy danych uzytko˙ wników

◦ integracja komputerów i usług sieciowych

◦ autoryzacja

W tym celu nalezy˙ najpierw przeanalizowac,´ pod katem˛ usług zgłoszeniowych, techniczne podstawy srodo´ wiska Windows NT.

3.4.2.1 Domeny

Podstawowa technologia usług zgłoszeniowych w Windows NT oparta jest na jednostce organizacyjnej, tzw. „domenie“. Domena jest jednostka˛ administrujac˛ a,˛ która za pomoca˛ wspólnie uzywanej˙ bazy danych skupia, w jednym kontekscie´ bezpieczenstwa,´ konta uzytko˙ wników i komputerów. Baza danych, o której mowa, to SAM (Security Accounts Manager). Podczas pracy jest ona przechowywana w Registry (baza danych - rejestr) specjalnych systemów serwerów noszac˛ ych nazwe˛ Domain Controllers (kontrolery domen). Oprócz uzytko˙ wników i komputerów w SAM odbywa sie˛ takze˙ zarzadzanie˛ grupami. Kazdy˙ z tych trzech typów obiektów mozna˙ jednoznacznie opisac´ tak zwanym SIDem (Security Identiﬁer), który nie powinien byc´ niepowtarzalny dla wszystkich domen. Kazdemu˙ SIDowi (wzglednie˛ długa konstrukcja liczb) odpowiada jeden SAM-Accountname, która z reguły zbudowana jest maksymalnie z 15 znaków alfanumerycz- nych (dozwolone jest uzycie˙ niektórych znaków specjalnych). SAM-Accountname jest nazwa,˛ której uzytko˙ wnicy uzywaj˙ a˛ do identyﬁkacji. Komputery oparte o:

◦ Windows NT

◦ Windows 2000

◦ Windows XP moga˛ byc´ członkiem jednej domeny. W przeciwienstwie´ do tego dla systemów takich jak, np. Windows 3.11 albo 9x niemozliwe˙ jest utworzenie konta komputera w domenie. Gdy komputer staje członkiem domeny, wówczas w SAM komputera grupy domeny (globalne grupy) staja˛ sie ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 115

członkiem lokalnych grup komputera. Tak oto „przekształca sie“˛ grupa „uzytko˙ wnik domeny“ w członka lokalnej grupy „uzytko˙ wnik“. W ten sposób, np. uzytko˙ wnicy, którzy na komputerze z NT moga˛zalogowac´ sie˛ do domeny, uzyskuja˛lokalny dostep˛ do zasobów uzywane˙ go komputera. Jedna domena wymaga przynajmniej jednego Domain Controller, tak zwanego PDC (Pri- mary Domain Controller). Przechowuje on SAM domeny i tylko on moze˙ zmieniac´ zawartos´c´ SAM. W celu rozłozenia˙ obcia˛zenia˙ i redundancji, w SAM nalezy˙ zastosowac´ tak zwane BDCs (Backup Domain Controllers), które przechowuja˛ kopie˛ SAM i regularnie aktualizuja˛ zmiany w PDC. Zalete˛ jednostki zarzadzaj˛ acej,˛ tj. „domeny“ widac,´ jak na dłoni. Aby uzytko˙ wnicy mogli korzystac´ z lokalnych zasobów albo zasobów znajdujac˛ ych sie˛ w systemach sieciowych, nie trzeba w kazdym˙ systemie zakładac´ konta uzytko˙ wnika, lecz wystarczy tylko załozenie˙ konta uzytko˙ w- nika w SAM domeny. Ochrona zasobów, autoryzacja, realizowana jest oddzielnie na tych systemach, które je udostepniaj˛ a.˛ Uzytko˙ wnicy korzystajac˛ y z Windows 9x, równiez˙ moga˛ logowac´ sie˛ do domeny i tym samym wykorzystywac´ zasoby sieciowe bez koniecznosci´ dodatkowego logowania.

3.4.2.2 Wiele domen i relacje zaufania

Istnieje mozliwo˙ s´c´ łaczenia˛ ze soba˛wielu domen poprzez tzw. relacje zaufania. Dzieki˛ nim moz-˙ liwa jest autoryzacja dostepu˛ do zasobów (np. File Services) takich uzytko˙ wników albo grup, którzy pochodza˛ z innych domen. Głównym celem jest zatem uzyskanie dostepu˛ do zasobów ponad granicami domen. Relacja zaufania pomiedzy˛ domenami NT nie musi byc´ dwukierunkowa (bidirektional); gdy domena A ufa domenie B, to B nie musi ufac´ A. Relacje zaufanie nie sa˛ równiez˙ przechodnie: gdy A ufa B i B ufa C, wtedy A nie musi automatycznie ufac´ C. Jak widac´ kazda˙ relacja zaufania musi byc´ ustawiana osobno. Ponizsze˙ okolicznosci´ doprowadziły do ukształtowania sie˛ sytemu wielu domen w srodo´ wiskach informatycznych:

◦ Czesto˛ powstawały równoległe rozwiazania˛ - wysepki, wewnatrz˛ jednej infrastruktury, które pózniej,´ wskutek wspólnych procesów roboczych, trzeba było łaczy˛ c´ za pomoca˛ relacji zaufania. Dotyczy to takze˙ sytuacji, w której trzeba połaczy˛ c´ dwie infrastruktury.

◦ Granice domen sa˛ granicami bezpieczenstwa:´ administratorzy domeny A nie sa˛ automatycznie administratorami domeny B, której sie˛ ufa albo która komus´ ufa. Lepsza polityka nie odgrywa tu zadnej˙ roli. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 116

◦ Mozliwo˙ s´c´ delegowania zadan,´ która nie ma zalet, została skompensowana przez zastosowanie wielu domen.

◦ Ilos´c´ obiektów (komputery, uzytko˙ wnicy, grupy) w SAM jest ograniczona gdyz˙ SAM przechowywane sa˛ podczas pracy w Registry kontrolerów domeny, których wielkos´c´ takze˙ jest ograniczona. Jedynym sposobem obejscia´ powyzsze˙ go ograniczenia jest rozproszenie obiektów pomiedzy˛ wiele domen.

◦ Skalowanie domeny w silnie rozproszonych, zdecentralizowanych srodo´ wiskach ograniczone jest przez Single Master z PDC, poniewaz˙ wszystkie zmiany w SAM moga˛ byc´ realizowane tylko przez niego.

Powyzsze˙ fakty doprowadziły do powstania rózn˙ ych modeli domen, które miedzy˛ innymi zapro- ponował sam Microsoft:

◦ Single Domain (jedna domena)

◦ Master Domain (wiele domen, z których kazda˙ ufa Master Domain, zazwyczaj domeny zasobów ufaja˛ domenie kont)

◦ Multiple Master Domain (wiele domen zasobów ufa wszystkim (wielu) domenom kont

◦ Complete Trust Domain (kazda˙ domena ufa innym domenom)

3.4.2.3 NT jako usługa katalogowa

W szerokim sensie domeny Windows NT sa˛równiez˙ usługami katalogowymi, poniewaz˙ obiekty uzytko˙ wnika zapisane sa˛ w jednej domenie. Microsoft nazwał taki system NTDS (Windows NT Directory Service). Ilos´c´ atrybutów obiektu uzytko˙ wnika w domenie NT jest wzglednie˛ mała i ogranicza sie˛ raczej do atrybutów oraz własciwo´ sci´ wazn˙ ych z technicznego punktu widzenia. Z tego powodu atrybutów tych nie mozna˙ porównywac´ z usługa˛ katalogowa˛ w oparciu o X.500. Własciwo´ sci´ uzytko˙ wnika obejmuja˛ miedzy˛ innymi:

◦ nazwe˛ uzytko˙ wnika (SAM-Accountname)

◦ pełna˛ nazwe˛ i opis (niewazne˙ z technicznego punktu widzenia)

◦ informacje˛ o koncie (np. konto dezaktywowane, hasło nigdy nie wygasa, termin wygasni´ e-˛ cia konta, typ konta) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 117

◦ członkostwa grup

◦ parametry srodo´ wiska (skrypty logowania, katalog domowy, scie´ zka˙ proﬁlu serwera)

◦ dozwolone godziny logowania, dozwolone komputery klientów

Parametry RAS (Remote Access Service) / dialup: dozwolone, z / bez callback Ponadto zapisywane sa˛ atrybuty, którymi zarzadza˛ system operacyjny, np:

◦ SID

◦ czas ostatniego logowania

◦ etc.

Rozszerzanie o samodzielnie zdeﬁniowane atrybuty nie jest przewidziane. Microsoft wprowa- dzajac˛ „Windows NT 4 Server Terminal Edition“ oraz Citrix Metaframe sam zaimplementował dodatkowe własciwo´ sci´ dla obiektu uzytko˙ wnika (dodatkowe home paths i proﬁle paths oraz inne parametry Citrix). NTDS nie moze˙ miec´ struktury hierarchicznej. Nadawanie uprawnien´ na poziomie atrybutów nie jest mozliwe,˙ a elastyczne nadawanie uprawnien´ obiektom uzytko˙ wnika jest mocno ograniczone.

3.4.2.4 Delegation

Przydzielanie zadan´ administracyjnych wewnatrz˛ domeny NT zredukowane jest do:

◦ korzystania z wbudowanych (Built-In) grup (domen - administratorów, operatorów kont, serwerów, zabezpieczania danych, wydruku i reprodukcji); jest to jednak wariant bardzo mało elastyczny.

◦ instalacji dodatkowych domen

Powyzsze˙ restrykcje, wzglednie˛ wady, zapewne doprowadziły do tego, ze˙ przydzielanie ról oraz ich istniejac˛ y podział odwzorowane sa˛ na aplikacjach opartych na sieci WWW. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 118

3.4.2.5 Podstawy sieci

Domena Windows NT moze˙ opierac´ sie˛ na nastepuj˛ ac˛ ych protokołach transportu

◦ TCP / IP

◦ NetBEUI

◦ SPX / IPX.

W kazdym˙ przypadku wymagany jest interfejs NetBIOS. W sieciach TCP / IP, które dla potrzeb niniejszego poradnika okreslili´ smy´ jako standardowe, do zapewnienia bezbłednej˛ komunikacji konieczne jest przekształcanie nazw NetBIOS (nazwa komputera oraz nazwy uzytko˙ wników i nazwy innego typu, takie jak grupa robocza). Jesli,´ np. uzytko˙ wnik chce zmienic´ swoje hasło w domenie, to musi on znac´ połozenie˙ PDC bad˛ z´ swój adres IP. Przekształcanie nazw NetBIOS moze˙ byc´ realizowana w sieciach windowsowych na rózne˙ sposoby:

◦ przez Broadcast

◦ przez odpytywanie serwera WINS (Windows Internet Name Service) albo

◦ przez wykorzystanie pliku LMHOSTS

Zapewne najelegantszym rozwiazaniem˛ tego zadania jest zastosowanie serwerów WINS. Tylko ten sposób umozliwia˙ realizacje˛ przekształcanie nazw przez podsieci IP, dynamiczne zawartosci´ i minimalizacje˛ Broadcasts. Usługa WINS jest czesto˛ realizowana na kontrolerach domeny. W sieciach windowsowych zaimplementowana jest usługa wyszukiwania komputerów (Browse Service) niezaleznie˙ od wybranego protokołu transportu. Teoretycznie moze˙ ona połaczy˛ c´ (home) wszystkie systemy operacyjne typu Windows. Usługa ta umozliwia˙ przesłanie klientowi wysyła- jacemu˛ pytanie (np. za pomoca˛polecenia „net view“) liste˛ aktywnych komputerów znajdujac˛ ych sie˛ w sieci. Jesli´ ma ona obejmowac´ takze˙ komputery z podsieci IP, wówczas powyzsza˙ usługa musi miec´ dostep˛ do informacji z „Domain Master Browser“ w sieci lokalnej, co jest mozliwe˙ po zastosowaniu WINS. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 119

3.4.2.6 Replikacja plików

Kontrolery domen (PDC, jak tez˙ BDCs) udostepniaj˛ a˛skrypty logowania i ustawienia systemowe w postaci zasobu NETLOGON, które sa˛ odpytywane przez logujac˛ ych sie˛ uzytko˙ wników. Aby uzytko˙ wnik mógł otrzymac´ za kazdym˙ razem te same warunki, zawartos´c´ w/w zasobu powinna byc´ jednakowa dla wszystkich kontrolerów domen w domenie. W tym celu serwery musza˛ wymieniac´ sie˛ informacjami. Tak zwana usługa katalogowej replikacji (LMRepl) zapewnia replikowanie zawartosci´ serwerów eksportujac˛ ych do serwerów im- portujac˛ ych. Zmiany zawartosci´ moga˛ byc´ przeprowadzane tylko na serwerze eksportujac˛ ym.

3.4.2.7 Narzedzia˛ administracyjne

Do administrowania obiektami uzytko˙ wnika, grupami i komputerami, w Windows NT 4 udostepniane˛ sa˛ programy graficzne takie jak menedzer˙ uzytko˙ wnika menedzer˙ serwera. Ponadto wraz z „NT Resource Kit“ dostarczane sa˛ narzedzia,˛ które przewaznie˙ mozna˙ uruchamiac´ z linii polecen´ i z pomoca˛ których mozna˙ stworzyc´ skrypty słuz˙ace˛ do automatycznej administrowania. Ponadto istnieje mozliwo˙ sć´ zarzadzania˛ domena˛ takze˙ poprzez interfejs WWW. Konieczne do tego jest zastosowanie Internet Information Servers (IIS) firmy Microsoft. Pewne braki odpowiednio wygodnych narzedzi˛ zainspirowały innych producentów do za- projektowania własnych narzedzi.˛ Przede wszystkim korzystaja˛ one z APIs dostarczanych przez Windows NT. Sam Microsoft pózniej´ wyprodukował jeszcze Microsoft Management Console (MMC), która została ostatecznie właczona˛ do Windows 2000. Takze˙ pózniej´ Microsoft dostarczył wraz z ADSI (Active Directory Service Interface) interfejs oparty o COM, za pomoca˛ którego mozna˙ administrowac´ równiez˙ domenami Windows NT.

3.4.2.8 Zapisywanie haseł

Hasła uzytko˙ wnika (takze˙ komputerów) zapisywane sa˛ w jednej domenie w SAM kontrolerów domeny. Zapisywane hasło nie jest zapisywane otwartym tekstem, lecz jako wartos´c´ hash. W Windows NT mozna˙ dodatkowo równiez˙ szyfrowac´ SAM (SYSKEY.EXE). Wartosci´ hash haseł tworzone sa˛ rózn˙ ymi metodami, które rozwineły˛ sie˛ zgodnie z ponizszym˙ opisem:

◦ LM (LAN Manager)

◦ NTLM ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 120

◦ NTLMv2

Na systemach NT, które nie sa˛ kontrolerem domen, informacje o uzytko˙ wnikach logujac˛ ych sie˛ na koncu´ sa˛ tymczasowo zapisywane do katalogu, co ma umozliwi˙ c´ logowanie takze˙ wtedy, gdy kontroler domen nie jest dostepn˛ y (typowe dla notebooków). Informacje te sa˛ nastepnie˛ ponownie zapisywane jako wartos´c´ hash.

3.4.2.9 Mechanizm autoryzacji

Autoryzacja w obrebie˛ srodo´ wiska domen NT opiera sie˛ na mechanizmie NTLM. Ocenialismy´ nastepuj˛ ac˛ y scenariusz. Domena zasobów ufa domenie kont. Istnieje działajace˛ srodo´ wisko WINS. Uzytko˙ wnik uruchamia stacje˛ robocza˛ Windows NT, która jest członkiem domeny zasobów. Nastepnie˛ loguje sie˛ do domeny kont. Powyzszy˙ scenariusz zilustrowany zo- stał na rysunku 3.6. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 121

Rysunek 3.6: Scenariusz logowania

Podczas uruchamiania maszyna z Windows NT wysyła, poprzez WINS, pytanie o liste˛ kon- trolerów domen (DCs) domeny zasobów. Jako pierwsze wysyłane jest, poprzez Broadcast, zapytanie Netlogon-Request. Jesli´ DC domen zasobów nie odpowie, wówczas Netlogon-Request wysyłane jest do DCs wspomnianej listy. Z pierwszym DC, który odpowiedział, nastepuje˛ we- ryﬁkacja informacji logowania poprzez tak zwany „Secure Channel“. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 122

Na koncu´ maszyna NT wysyła pytanie do DC domeny zasobów o liste˛ zaufanych domen. Po wybraniu przez uzytko˙ wnika domeny kont z maski logowania oraz podaniu przez niego swojego identyfikatora i hasła, uruchamiany jest proces logowania konta uzytko˙ wnika. Klient NT wysyła informacje logowania do tak zwanej weryfikacji „pass-through validation“ na DC domeny zasobów, który udostepnia˛ maszynie Secure Channel. DC domeny zasobów wysyła zapytanie do DC domeny kont (najpierw lokalne, nastepnie˛ ukierunkowane poprzez Secure Chan- nel). Zweryfikowane informacje logowania zwracane sa˛poprzez DC domeny zasobów do klienta NT. Nastepnie˛ klient otwiera bezposrednie´ połaczenie˛ z DC domeny kont, aby załadowac´ skrypt logowania, ustawienia systemowe albo profil uzytko˙ wnika. Jako uzupełnienie nalezy˙ jeszcze ocenic´ nastepuj˛ ac˛ y proces logowania. Gdy uzytko˙ wnik ła-˛ czy sie˛ z zasobami (np. składowanie plików jako zasób serwera plików, np. net use), serwer plików musi sprawdzic´ informacje logowania kontaktujac˛ sie˛ ponownie z kontrolerami domen.

3.4.2.10 Single Sign On

Rozwiazanie˛ oparte o domeny zastosowane w Windows NT umozliwia˙ cos´ w rodzaju Single Sign On (jednorazowe logowanie) w ramach palety produktów Microsoft. Uzytko˙ wnik loguje sie˛ jeden raz na swojej stacji roboczej z Windows NT i nastepnie˛ uzyskuje dostep,˛ o ile zasoby bad˛ z´ systemy serwera sa˛ członkiem własnej albo zaufanej domeny, do nastepuj˛ ac˛ ych usług:

◦ File Services oraz Print Services

◦ Exchange

◦ SQL

◦ Intranet (Web, Internet Information Server)

. Inni producenci oprogramowania moga˛implementowac´ swoje produkty w taki sposób, ze˙ zachowana zostanie mozliwo˙ s´c´ jednorazowego logowania. Z reguły jednak musza˛ oni udostepnia˛ c´ swoje aplikacje na serwerach Windows NT4, które sa˛ członkami domeny.

3.4.2.11 Wytyczne

W domenach Windows NT mozna˙ zrezygnowac´ z wytycznych mówiac˛ ych o tym,

◦ jak obchodzic´ sie˛ z hasłami (czas wazno˙ sci,´ minimalna długos´c,´ powtarzane, błedne˛ wprowadzenie hasła) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 123

◦ jakie przywileje (uprawnienia uzytko˙ wnika) powinni posiadac´ uzytko˙ wnicy lub grupy (zmiana czasu systemowego, lokalne logowanie, etc.)

3.4.2.12 Auditing

W domenach Windows NT mozna˙ właczy˛ c´ Auditing (kontrole)˛ uzyskanego dostepu,˛ wzglednie˛ podjetych˛ prób uzyskania dostepu.˛ W ten sposób mozna˙ nadzorowac,´ np.

◦ logowanie i wylogowywanie sie˛

◦ korzystanie z uprawnien´ uzytko˙ wnika

◦ administrowanie uzytko˙ wnikami i grupami

◦ zmiany wytycznych bezpieczenstwa´

3.4.2.13 Smart Card (mocne mechanizmy autoryzacji)

Dla Windows NT 4 oraz Windows 9x ukazały sie˛ tak zwane „Smart Card Base Components“, z pomoca˛ których inni producenci moga˛ tworzyc´ aplikacje windowsowe z obsługa˛ Smart Card. Rozwiazania˛ umozliwiaj˙ ace˛ mocna˛ autoryzacje˛ oferowane sa˛ przez innych producentów.

3.4.3 Migracja zastepuj˛ aca˛ - Linux, Samba i OpenLDAP

Przy ocenianiu migracji zastepuj˛ acej˛ nalezy˙ uwzgledni˛ c´ przede wszystkim takze˙ wymagania co do sposobu autoryzacji w srodo´ wiskach mieszanych złozon˙ ych z systemów Linux i Windows. W zwiazku˛ z tym na pierwszy plan wysuwa sie˛ oczywiscie´ wykorzystanie usługi katalogowej, takze˙ w aspekcie Active Directory pocza˛wszy od Windows 2000. Poza tym kombinacja Linuksa, Samby i OpenLDAP obroniła sie˛ jako metoda autoryzacji juz˙ wielokrotnie, na długo przed po- wstaniem Active Directory. Dlatego przejrzysta, oddzielna ocena usługi katalogowej jako usługi integrujacej˛ i jako cze˛sci´ usługi autoryzacji jest prawie niemozliwa.˙ (Obszerna informacja na ten temat znajduje sie˛ w rozdziale 3.7). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 124

3.4.3.1 Autoryzacja z wykorzystaniem Linux / OpenLDAP i Samby

Samba zapewnia klientom windowsowym podobna˛ funkcjonalnos´c´ jak główny kontroler domen oparty na Windows NT (m.in. File Services, Print Services oraz usługi autoryzacji). Samba, jako baza danych kont uzytko˙ wników, moze˙ przy tym odwoływac´ sie˛ do OpenLDAP swiadcz´ acej˛ usługi katalogowe. W tym wzgledzie˛ połaczenie˛ Samba / OpenLDAP stanowi odpowiednik kombinacji domen Windows NT oraz Active Directory. W obydwu przypadkach klient windowsowy widzi domene˛ NT. Jednak jesliby´ spojrzec´ pod katem˛ administrowania informacjami o uzyt-˙ kownikach, grupach i hostach, chodzi o kompletne rozwiazanie˛ oparte na usłudze katalogowej wraz ze wszystkimi wynikajac˛ ymi z tego zaletami. W szczególnosci´ w przypadku rozwiazania˛ opartego o Sambe˛ i OpenLDAP przestaje istniec,´ znany z Windows NT, problem skalowalnosci,´ który czesto˛ wymaga podziału infrastruktury pomiedzy˛ rózne˙ domeny.

3.4.3.2 Synchronizacja hasła

Podczas, gdy dla klientów windowsowych stosowana jest usługa katalogowa Linux / OpenLDAP w połaczeniu˛ z Samba,˛ autoryzacja wspomnianych klientów nastepuje˛ poprzez protokół NTLM. Dlatego w katalogu musza˛ byc´ zapisane te same zaszyfrowane hasła, jak w bazie danych SAM w Windows NT/2000/2003. Dzieki˛ temu jakoscio´ wemu ograniczeniu (brak autoryzacji Kerberos dla klientów Windows 2000 / XP) mozliwe˙ jest zbudowanie pełnowartoscio´ wej usługi autoryzacji dla klientów windowsowych w oparciu o Linuksa, OpenLDAP i Sambe.˛ Problemem wydaje sie˛ tu byc´ uzywanie˙ przez Linuksa innego algorytmu do szyfrowania haseł niz˙ ma ten stosowanych w Windows NT / 2000. Z tego powodu w przypadku stosowania rozwiazania˛ opartego na OpenLDAP i Sambie konieczne jest zapisanie haseł uniksowych oraz windowsowych obok siebie w katalogu LDAP i ich zsynchronizowanie. Z technicznego punktu widzenia nie jest to zaden˙ problem, poniewaz˙ istnieje mozliwo˙ sć´ takiego skonfigurowania Samby, zeby˙ podczas zmiany hasła przez klienta windowsowego, automatycznie zmieniane była takze˙ hasło uniksowe. Powyzsza˙ zasada obowiazuje˛ takze˙ w odwrotnym kierunku, tzn. za pomoca˛ mechanizmu PAM (Pluggable Authentication Module) istnieje mozliwo˙ sć´ takiego ustawienia programów uniksowych, zeby˙ mogły one zmieniac´ hasło w Windows, gdy tylko zmieniane jest ono dla programu uniksowego. Dzieki˛ prawidłowej konfiguracji synchronizacja hasła nie stanowi problemu. Ponadto autoryzacja usług opartych na Uniksie moze˙ byc´ realizowana, podobnie jak w przypadku Active Directory, poprzez Kerberos. Słuz˙a˛ do tego dwie równorzedne˛ implementuje Ker- beros dla Linuksa, tj. „MIT Kerberos“ oraz „Heimdal“. Równiez˙ w przypadku korzystania z Kerberos synchronizacje˛ hasła mozna˙ zagwarantowac´ za pomoca˛wyzej˙ wymienionych mechani- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 125 zmów. (Podobna metoda synchronizacji hasła musi byc´ takze˙ wykorzystywana wewnatrz˛ Active Directory, aby zagwarantowac´ logowanie zarówno poprzez Kerberos, jak i logowanie starszych klientów poprzez NTLM).

3.4.3.3 Relacje zaufania

Samba 3.0 obsługuje relacje zaufania znane z Windows NT. Mozna˙ je ustawiac´ zarówno pomie-˛ dzy domenami Windows i Samby, jak tez˙ pomiedzy˛ dwiema domenami opartymi na Sambie.

3.4.3.4 WINS

Samba ma wbudowana˛ usługe˛ WINS. Wraz z Samba˛ 3.0 dostarczany jest program słuz˙ac˛ y do replikacji WINS. Program ten nie został jednak na razie wystarczajaco˛ przetestowany.

3.4.3.5 Ograniczenia w stosowaniu OpenLDAP i Samby

Jak juz˙ wspomnielismy´ , Samba odpowiada, z punktu widzenia klienta windowsowego, serwerowi opartemu na Windows NT. Oznacza to, ze˙ nie obsługuje ona nowych własciwo´ sci´ zwiaza-˛ nych z administrowaniem klientami windowsowymi, które zostały wprowadzone wraz z Active Directory. W szczególnosci´ brak jest obsługi dla Group Policy Objects (GPOs) i wymiana oprogramowania poprzez Active Directory. W praktyce jednak wystarcza zastepo˛ wanie tych Features innymi technikami.

GPOs Samba obsługuje tak zwane System Policies, dzieki˛ którym mozliwe˙ jest definiowanie ustawien´ rejestrów dla uzytko˙ wnika, grup uzytko˙ wników i komputerów klientów. Poprzez System Policies mozna˙ równiez˙ zadac´ wiekszo˛ sć´ ustawien´ dostepn˛ ych za pomoca˛ GPOs (ograniczenia funkcji interfejsu uzytko˙ wnika Windows, wybór programów wykonywalnych, itd.). Dzieki˛ na- rzedziu˛ „editreg“ dostarczanemu wraz z Samba˛mozliwe˙ jest dynamiczne definiowanie ustawien´ systemowych. Ponadto w srodo´ wisku opartym na Sambie mozna˙ uzywa˙ c´ lokalnych Policies, które zasadniczo umozliwiaj˙ a˛ uzyskanie takich samych ustawien,´ jak z GPOs. Poniewaz˙ lokalne Policies składowane sa˛po prostu w systemie plików, mozna˙ je, po stworzeniu prototypu, w łatwy sposób zsynchronizowac´ z duz˙a˛ ilosci´ a˛ klientów. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 126

Wymiana oprogramowania Funkcje oferowane przez Active Directory, a umozliwiaj˙ ace˛ wymiane˛ oprogramowania ograniczaja˛sie˛ do programów, które dostepne˛ sa˛w formie pakietów MSI. W praktyce wybierane jest najcze˛sciej´ rozwiazanie˛ polegajace˛ na szerokiej wymianie oprogramowania. W tym celu mozna˙ skorzystac´ z całego szeregu rozwiaza˛ n´ komercyjnych, które działaja˛ równiez˙ bez Active Direc- tory, a nawet czesto˛ wykorzystuja˛ Linuksa, jako podstawowy system operacyjny. Samba obsługuje profile oparte na serwerze. Dzieki˛ temu mozliwe˙ jest ustawienie takze˙ pro- filów obowiazko˛ wych, za pomoca˛ których mozna˙ zdefiniowac´ konfiguracje˛ interfejsu uzytko˙ w- nika oraz przypisac´ aplikacje poszczególnym uzytko˙ wnikom. Za pomoca˛skryptów logowania, na klientach windowsowych mozna˙ zdefiniowac´ cały szereg innych ustawien,´ np. dla hostów, grup oraz uzytko˙ wników.

3.4.3.6 Kombinacja OpenLDAP i Active Directory

Tam, gdzie nie mozna˙ zrezygnowac´ z Features oferowanych przez Active Directory, istnieje mozliwo˙ s´c´ replikacji danych uzytko˙ wników i grup z OpenLDAP do Active Directory. Uzytko˙ w- nikami i grupami trzeba wówczas nadal zajmowac´ sie˛ w katalogu OpenLDAP, ale mozna˙ z nich korzystac´ takze˙ w ramach Active Directory, co sprawia, ze˙ wykorzystywane moga˛ byc´ odpowiednie własciwo´ sci´ (takie jak GPOs) przy jednoczesnym administrowaniu z jednego miejsca (Single - Point - of - Administration). Windows moze˙ byc´ przy tym skonﬁgurowany w taki spo- sób, zeby˙ dla obu cze˛sci´ srodo´ wiska wykorzystywany był wspólny (oparty na Linuksie) serwer Kerberos. Wia˛ze˙ sie˛ to jednak z ograniczeniami, które polegaja˛na tym, ze˙ nie bedzie˛ juz˙ mozliwa˙ autoryzacja przez Active Directory / Kerberos systemów opartych na Windows 94/98/NT.

3.4.3.7 Narzedzia˛ umozliwiaj˙ ace˛ migracje˛ z Windows NT do Samby / OpenLDAP

Za pomoca˛ narzedzi,˛ w które wyposazona˙ jest Samba, mozliwe˙ jest sczytanie bazy danych uzytko˙ wników dostepne˛ go, opartego na Windows, kontrolera domen i zapisanie jej do katalogu OpenLDAP. Dzieki˛ takiemu postepo˛ waniu migracja moze˙ byc´ całkowicie przejrzysta dla uzyt-˙ kowników oraz systemów klienckich; nie ma koniecznosci´ wprowadzania klientów od nowa do tworzonej domeny, a uzytko˙ wnicy moga˛nadal uzywa˙ c´ wykorzystywana˛w NT pare˛ login / hasło. Podczas migracji nalezy˙ najpierw usuna˛c´ wszystkie usługi z kontrolerów domen, za wy- jatkiem˛ autoryzacji i przejs´c´ na Member-Servers. W nastepn˛ ym kroku mozna˙ wykonac´ migracje˛ kontrolerów domen opartych na Windows NT na Sambe˛ / OpenLDAP. W czasie migracji mozna˙ dalej uzywa˙ c´ windowsowych Member-Servers, teraz juz˙ w domenie opartej na rozwiaza-˛ niu Samba / OpenLDAP i powoli przechodzic´ na Sambe.˛ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 127

3.4.3.8 PDC i BDCs w jednej domenie Samby

Aby zachowac´ kompatybilnosć´ z domenami Windows NT, Samba obsługuje takze˙ PDC i BDCs. Jednak obsługa powyzszych˙ ogranicza sie˛ do tego, ze˙ serwer Samba widziany jest przez klientów windowsowych, w zalezno˙ sci´ od konfiguracji, jako PDC bad˛ z´ BDC. Sam Samba nie obsługuje replikacji bazy danych SAM pomiedzy˛ PDC i BDC. Jednakze˙ ze wzgledu˛ na zapisywanie SAM w katalogu LDAP, replikacja SAM moze˙ byc´ realizowana przez OpenLDAP. Serwer Samba skonfigurowany jako PDC posiada przy tym zazwyczaj prawo do zapisu na OpenLDAP-Master- Server, dzieki˛ czemu moze˙ on zmieniac´ wpisy w bazie danych uzytko˙ wników. BDCs nalezy˙ skonfigurowac´ w taki sposób, zeby˙ ich dostep˛ do OpenLDAP-Slave-Server, który na ogół działa na tym samym komputerze, co Samba-BDC, ograniczał sie˛ tylko do prawa do odczytu. Jesli´ w takiej sytuacji, poprzez PDC zainicjowana zostanie zmiana wpisów w bazie danych SAM, wów- czas PDC zapisze te˛ zmiane˛ do katalogu LDAP. Stamtad˛ zostanie ona przesłana, po replikacji LDAP, do BDCs, dzieki˛ czemu takze˙ one bed˛ a˛ mogły korzystac´ ze zmienionej bazy danych. Ponadto w domenie Windows NT synchronicznie przechowywana jest zawartosć´ Netlogon- Shares (na którym znajduja˛ sie˛ m.in. Policies i skrypty logowania). W Linuksie mozna˙ to zrealizowac,´ np. za pomoca˛ programu rsync.

3.4.3.9 Samba jako członek domeny Active Directory

Oprócz tego Samba jest w stanie uzywa˙ c´ do autoryzacji, tzw. Kerberos-Tickets serwera Active Directory. Oznacza to, ze˙ Samba, jako pełnowartoscio´ wy Member-Server, moze˙ byc´ stosowana w domenach AD.

3.4.3.10 Narzedzia˛ administracyjne

Uzytko˙ wnikami i grupami w domenie opartej na systemie Samba / OpenLDAP mozna˙ administrowac´ za pomoca˛ narzedzi˛ dostarczanych przez Windows NT (usrmgr.exe). Jednak w takim przypadku nie mozna˙ wykorzystac´ wszystkich szczególnych zalet rozwiazania˛ opartego na usłu- dze katalogowej (np. rózn˙ ych poziomów uprawnien,´ zagniezd˙ zonej˙ struktury katalogów), poniewaz˙ nie sa˛ one obsługiwane przez Features z Windows NT. Narzedzia˛ do zarzadzania˛ OpenL- DAP opisane zostały w rozdziale 3.7.4.7. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 128

3.4.4 Migracja kontynuacyjna

3.4.4.1 Windows 2000

Jesli´ chodzi o usługe˛ logowania, nie mozna˙ przyja˛c,´ ze˙ Windows 2000 jest jedynie „aktualizacja“˛ systemu operacyjnego. Obszerny i skomplikowany jest tu nie tylko proces aktualizacji, wzgled-˛ nie instalacji, lecz mamy w tym przypadku do czynienia takze˙ z zasadnicza˛ zmiana˛ architektury w postaci „Active Directory Service“. W tym miejscu poradnika postanowilismy´ nie przedstawiac´ usługi logowania z Windows 2000 jako osobnego tematu bez uwzglednienia˛ Active Directory oraz usługi katalogowej. Po- dobne problemy wystepuj˛ a,˛ jesli´ chodzi o jasne rozgraniczenie Active Directory jako usługi in- frastrukturalnej od Active Directory jako składnika usługi autoryzacji. W zwiazku˛ z tym postanowilismy´ odesłac´ czytelnika do rozdziału 3.7.5, w którym opisalismy´ nastepc˛ e˛ Windows 2000, tj. Windows Server 2003.

3.5 Usługi sieciowe

3.5.1 Przeglad˛

W wyniku przedstawionych ponizej,˙ szczegółowych ocen technicznych, doszlismy´ do wniosku, ze˙ w przypadku w/w usług nie ma problemów z przeprowadzeniem migracji. Nie nalezy˙ sie˛ ich spodziewac´ ani w srodo´ wisku systemów mieszanych, ani tez˙ w srodo´ wisku homogenicznym (całkowita „zastepuj˛ aca˛ migracja“ lub migracja kontynuacyjna).

3.5.2 Punkt wyjscia´ - usługi sieciowe pod Windows NT

W niniejszym podrozdziale przeanalizowalismy´ nastepuj˛ ace˛ usługi sieciowe:

◦ WINS

◦ DNS

◦ DHCP

Tam, gdzie było to konieczne zaakcentowalismy´ róznice˙ pomiedzy˛ serwerami, a klientami. W szerszym sensie do usług sieciowych mozna˙ zaliczyc´ takze˙ ponizsze˙ usługi:

◦ RAS (Remote Access Service) i Routing ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 129

◦ Web Proxy

◦ SNA Gateway.

Microsoft oferuje w tym obszarze oddzielne serwery lub dodatkowe produkty (np. SNA Server 4.0 albo Proxy Server 2.0), jednak w niniejszym podrozdziale nie zostały one opisane. Zamiast tego zamiescili´ smy´ ponizej˙ krótka˛analize˛ nowosci´ oferowanych przez poszczególne usługi sieciowe zwiazane˛ z wprowadzeniem Windows 2000.

3.5.2.1 Windows Internet Name Service (WINS)

Microsoft Windows Internet Service (WINS) jest usługa,˛ która˛ mozna˙ zainstalowac´ w systemie operacyjnym Windows NT 4 Server. WINS jest usługa˛ zgodna˛ z RFC, umozliwiaj˙ ac˛ a˛ przekształcanie nazw NetBIOS na adres IP i jednoczesnie´ serwerem, który za pomoca˛

◦ Broadcast oraz

◦ lokalnie zapisanego pliku LMHOSTS sprawia, ze˙ przekształcanie nazw staje sie˛ zbedne.˛ WINS umozliwia˙ tym samym przekształcanie nazw NetBIOS poprzez podsieci IP na zewnatrz.˛ WINS mozna˙ uzywa˙ c´ zarówno dynamicznie, jak i statycznie. Pierwszy sposób oznacza, ze˙ klienty WINS moga˛ sie˛ same dynamicznie dopisywac.´ Metoda statyczna polega na tym, ze˙ administratorzy musza˛ wpisywac´ nazwy oraz adresy IP kazde˙ go z nich recznie.˛ WINS zapisuje swoje dane w bazie danych (Jet - Engine, wins.mdb), której zawartosć´ moze˙ ze soba˛ synchronizowac´ wiele serwerów WINS. W tym celu serwery WINS nalezy˙ skonfigurowac´ jako tzw. „Push - Partner“ i / lub Pull - Partner“. Zawartosć´ zapisywana jest zgodnie z zasada˛ Multi-Master, co oznacza, ze˙ kazdy˙ serwer WINS moze˙ dokonywac´ wpisów. Dodatkowo istnieje mozliwo˙ sć´ zastosowania WINS-Proxy. Komputer, który pełni role˛ WINS- Proxy, sam nie obsługuje bazy danych, lecz przyjmuje zapytania od klientów i przekazuje je do pełnowartoscio´ wego serwera WINS. Wszystkie dotychczasowe systemy operacyjne Windows (Windows 9x do Windows XP oraz wszystkie serwerowe systemy operacyjne) moga˛ byc´ klientami WINS. Samego klienta WINS ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 130

mozna˙ skonﬁgurowac´ na podstawie jego, tzw. typu wezła,˛ tak by wiedział czy i jak powinien przekształcac´ nazwy NetBIOS. Przestrzen´ nazw NetBIOS jest płaska i ogranicza sie˛ tylko do nazw komputerów. Obejmuje ona takze˙ nazwy uzytko˙ wników, usługi, nazwy domen Windows albo windowsowych grup roboczych, etc. Ponizsza˙ tabela pokazuje przeglad˛ typów nazw NetBIOS, które mozna˙ identyﬁkowac´ na podstawie 16 bajtowej nazwy NetBIOS. Nalezy˙ rozrózni˙ c´ nazwy jednoznaczne (unikalne) i nazwy grup. Te ostatnie moga˛ byc´ uzy-˙ wane jednoczesnie´ przez wiele komputerów, jak i dodawane. Nastepuj˛ aca˛ tabela przedstawia unikalne oznaczenia.

16 BAJTÓW OZNACZA JEDNOZNACZNIE <00> nazwe˛ NetBIOS komputera. usługe˛ informacyjna˛ zarówno dla komputera, jak i zalogo- <03> wanego uzytko˙ wnika. Domain Master Browser (wyszukiwanie komputerów), <1B> która udostepniana˛ jest przez PDC domeny. <06> usługe˛ RAS (Remote Access Service) na komputerze. <1F> usługe˛ NetDDE na komputerze. komputer - serwer (szczególnie wazne˙ w przypadku zaso- <20> bów katalogowych). <21> komputer z klientem RAS. agenta monitorujace˛ go siec´ (network monitor agent). komputer z tak zwanym „network monitor utility“.

Tablica 3.18: Unikalne oznaczenia nazw NetBIOS

Nastepuj˛ aca˛ tabela pokazuje cechy, które moga˛ byc´ wykorzystywane przez wiele kompute- rów.

16 BAJTÓW OZNACZA WIELOWARTOS´ CIOWO <1C> nazwe˛ domeny. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 131

<1D> nazwe˛ Master Browser. <1E> zwyczajna˛ nazwe˛ grup. <20> specjalna˛ nazwe˛ grup (zwana˛ Internet group). ze˙ zamiast jednych 16 bajtów, mozliwe˙ jest przyłaczenie˛ „_MSBROWSE_,“ do nazwy domeny w celu wskazania domeny innym Master Browser.

Tablica 3.20: Wielowartoscio´ we oznaczenia nazw NetBIOS

3.5.2.2 Domain Name System (DNS)

Domain Name System (DNS) jest usługa,˛ która˛ mozna˙ zainstalowac´ na serwerze Windows NT 4. Obsługuje ona RFCs 1033, 1034, 1035, 1101, 1123, 1183 i 1536 i jest kompatybilna z implementacja˛ Berkeley Internet Name Domain (BIND). DNS z serwera Windows NT 4 obsługuje BIND w wersji 4.9.4. DNS jest standardem sieci Internet, który umozliwia˙ m.in. przekształcanie, wewnatrz˛ hierarchicznej przestrzeni nazw, nazw komputerów na adres IP i odwrotnie (Reverse Lookup). Zasto- sowanie serwera DNS sprawia, ze˙ uzycie˙ lokalnych wpisów w pliku HOSTS staje sie˛ zbedne.˛ W hierarchii przestrzeni nazw mozna˙ zorientowac´ sie˛ dzieki˛ znakowi rozdzielajacemu˛ „.“ uzywanemu˙ podczas zapisywaniu nazw. Tak zwana w pełni kwalifikowana nazwa (Fully Qu- alified Domain Name, FQDN) składa sie˛ z dwóch cze˛sci.´ Pierwsza cze˛sć´ konczy´ sie˛ na pierwszej kropce i oznacza nazwe˛ hosta, a druga cze˛sć´ jest nazwa˛ DNS domeny. Przykład: kompu- ter1.microsoft.com opisuje komputer o nazwie komputer1 w domenie microsoft.com. Nie ma wymogu, aby FQDN składała sie˛ z trzech cze˛sci.´ Znaki, które mozna˙ stosowac´ w FQDN nalez˙a˛ do przedziału od a do z, A do Z oraz znak „–“. Poniewaz˙ DNS jest standardem sieci Internet, nie wolno stosowac´ dowolnych nazw domen. Domeny musza˛ byc´ zarejestrowane w aktualnych narodowych i miedzynarodo˛ wych rejestrach. Jednak, jesli´ przestrzen´ nazw DNS widoczna jest tylko wewnatrz˛ własnej organizacji (przedsie-˛ biorstwa), wówczas mozna˙ stosowac´ takze˙ niezarejestrowane nazwy. Korzystac´ nalezy˙ z takich zarejestrowanych nazw bad˛ z´ stref, które nie sa˛ wykorzystywane w Internecie. W ten sposób unika sie˛ stosowania stref nalez˙ac˛ ych do innych organizacji bad˛ z´ osób. DNS posiada mechanizmy, które umozliwiaj˙ a˛ partycjonowanie podstawowej bazy danych oraz dopasowanie jej do dzielonych srodo´ wisk. Z jednej strony przekształcanie nazw mozna˙ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 132 przypisac´ do konkretnych domen, a z drugiej poprzez utworzenie stref mozliwe˙ jest sterowanie replikacja˛ (transfer stref) oraz sterowanie administrowaniem. Implementacja w Windows NT 4 jest zgodna z BIND 4.9.4 w takim stopniu, ze˙ DNS pracuje wyłacznie˛ statycznie (czyli nie obsługuje dynamicznych wpisów), a zmiany moga˛ byc´ wprowa- dzane tylko na pierwszym serwerze strefy (zasada Single Master). Szczególna˛cecha˛implementacji DNS w Windows NT 4 jest to, ze˙ mozna˙ sprawic,´ by usługa ta dodatkowo wymusiła przydzielanie nazw na serwerze WINS. Oprócz zarzadzania˛ wpisami nazw komputerów, DNS obsługuje jeszcze inne rodzaje wpisów (resource records). Ponizsza˙ tabela pokazuje przeglad˛ typów DNS Resource Record obsługiwa- nych w Windows NT.

TYP WPISU KRÓTKI OPIS wpis adresu (klasyczny wpis dla hosta, któremu trzeba przy- A pisac´ adres IP) AFSDB specjalny wpis dla Andrew File System (AFS) CNAME alias (albo canonical name) specjalny wpis - informacje o osprzecie˛ odpowiednio do HINFO RFC 1700. ISDN wpis dla ISDN (Integrated Services Digital Network) w powiazaniu˛ z typem RT (route through) specjalne wpisy dla skrzynek pocztowych, grup poczto- MB, MG, wych MINFO, MR oraz dla informacji o skrzynkach pocztowych wpis dla mail routing via SMTP (Simple Message Transfer MX Protocol) NS wpis dla serwera DNS (name server) domeny DNS. zarezerwowany adres (pointer resource record), który prze- PTR kształca adres IP w adres hosta The route through resource record speciﬁes an intermediate host that routes packets to a destination host. The RT record RP is used in conjunction with the ISDN and X25 resource records. It is syntactically and semantically similar to the MX record type and is used in much the same way. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 133

SOA wpis dla pierwszego serwera DNS (start of authority) TXT wpis dla informacji tekstowych wpis dla adresu IP serwerów WINS, które maja˛ byc´ dodat- WINS kowo wykorzystane do przekształcania nazw (forward resolution) WINS_R wpis dla Reverse Lookup via serwer WINS WKS wpis dla well-known service X.25 wpis dla adresu X. 121

Tablica 3.22: Przeglad˛ obsługiwanych typów DNS Resource Record

Wszystkie dotychczasowe systemy operacyjne Windows (Windows 9x do Windows XP oraz wszystkie serwerowe systemy operacyjne) moga˛byc´ klientem DNS. Systemy oparte na Windows 2000 i nowszych wersjach tego sytemu obsługuja˛ jako klienty takze˙ dynamiczny DNS (DDNS), który opisalismy´ w rozdziale 3.5.2.3.

3.5.2.3 Dynamic Host Conﬁguration Protocol (DHCP)

DHCP (Dynamic Host Conﬁguration Protocol) jest standardem sieci Internet dla konﬁguracji dynamicznego numeru IP komputerów albo innych urzadze˛ n´ TCP / IP (np. drukarek sieciowych). DHCP opiera sie˛ na RFCs 1533, 1534, 1541 i 1542. Jego implementacja na serwerze Windows NT 4 obsługuje opcje zapisane w RFC 1541. Zostały one umieszczone w ponizszej˙ tabeli. Opcje zaznaczone tłustym drukiem obsługiwane sa˛ przez klientów DHCP do Windows NT 4.

Nr Nazwa opcji Wyjasnienie´ 0 Pad 255 End 1 Subnet mask maska podsieci 2 Time offset 3 Router adres IP standardowego routera (gateway) 4 Time server 5 Name servers ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 134

6 DNS servers adres IP serwera DNS 7 Log servers 8 Cookie servers 9 LPR servers 10 Impress servers 11 Resource Location servers 12 Host name 13 Boot file size 14 Merit dump file 15 Domain name sufiks DNS klienta 16 Swap server 17 Root path 18 Extensions path 19 IP layer forwarding 20 Nonlocal source routing 21 Policy filter masks 22 Max DG reassembly size 23 Default time-to-live 24 Path MTU aging timeout 25 Path MTU plateau table 26 MTU option 27 All subnets are local 28 Broadcast address 29 Perform mask discovery 30 Mask supplier 31 Perform router discovery 32 Router solicitation address 33 Static route 34 Trailer encapsulation 35 ARP cache timeout 36 Ethernet encapsulation 37 Default time-to-live 38 Keepalive interval ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 135

39 Keepalive garbage 40 NIS domain name 41 NIS servers 42 NTP servers 42 Vendor-speciﬁc information 44 WINS / NBT node type adresy IP serwerów WINS 45 NetBIOS over TCP / IP NBDD 46 WINS / NBT node type typ wezła˛ klienta WINS 47 NetBIOS scope ID 48 X Window system font 49 X Window system display 51 lease time czas trwania przydzielania 58 Renewal (T1) time value interwał odswie´ zania˙ 1 59 Rebinding (T2) time value interwał odswie´ zania˙ 64 NIS + Domain Name 65 NIS + Servers 66 Boot Server Host Name 67 Bootﬁle Name 68 Mobile IP Home Agents

Tablica 3.24: Opcje DHCP

Oprócz tego istnieje mozliwo˙ s´c´ uzycia˙ DHCP Relay Agent. Komputer, na którym jest on uruchomiony, sam nie obsługuje bazy danych, lecz przyjmuje zapytania od klientów i przekazuje je do pełnowartoscio´ wego serwera DHCP.

3.5.3 Migracja zastepuj˛ aca˛ - usługi sieciowe pod Linuksem

Usługi tworzace˛ infrastrukture˛ sieci opartej na TCP / IP (DNS, DHCP, NTP, Routin, VPN, Filte- ring) mozna˙ bez wyjatku˛ realizowac´ za pomoca˛Wolnego Oprogramowania. Szeroka dostepno˛ s´c´ w/w usług w postaci OSS wynika z historii rozwoju Internetu, który bed˛ ac˛ ogólnoswiato´ wa˛siecia˛ umozliwiaj˙ ac˛ a˛ wymiane˛ danych odznacza sie˛ tym, ze˙ wszystkie podłaczone˛ do niej komputery rozmawiaja˛ tym samym jezykiem.˛ Jezyk˛ ten składa sie˛ z całej rodziny protokołów noszac˛ ych ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 136

ogólna˛nazwe˛ TCP / IP. Aby komunikacja pomiedzy˛ najrózniejszymi˙ systemami mogła na całym swiecie´ przebiegac´ bez problemów, konieczne jest zgodne „rozumienie jezyka“.˛ Aby uzyskac´ te˛ zgodnosć,´ wiekszo˛ sć´ standardów protokołów internetowych, które zostały formalnie zaakceptowane przez Internet Engineering Task Force (IETF), obsługiwana jest przez Open Source dzieki˛ implementacjom referencji. Opierajac˛ sie˛ na w/w referencjach wszyscy producenci moga,˛ niezaleznie˙ od siebie, rozwijac´ całkowicie kompatybilne oprogramowanie. Protokoły internetowe same sa˛ niezalezne˙ od producentów, bed˛ ac˛ jednoczesnie,´ zarówno w swoich definicjach, jak i w swoich implementacjach Open Source, otwartymi standardami. Ten szczególny charakter proto- kołów internetowych zadecydował o wyróznieniu˙ sie˛ TCP / IP na tle, dostepn˛ ych w tym samym czasie na rynku, własnoscio´ wych protokołów sieciowych. Zachowanie otwartych standardów ma zasadnicze znaczenie takze˙ wtedy, gdy z powodu ograniczonej ilosci´ stosowanych systemów mozliwe˙ jest, w sieci lokalnej, zorientowanie sie˛ co do wymagan´ odnosnie´ kompatybilnosci.´ Szczególnie w przypadku zmian dokonywanych przez producenta, wzglednie˛ rozszerzen´ standardów, istnieje ciagła˛ grozba´ „Vendor Lock-In“; z jednej strony przywiazanie˛ do danego producenta staje sie˛ uzaleznieniem,˙ a z drugiej strony punkt decyzyjny zwiazan˛ y z dalszym rozwojem oraz współpraca˛z innymi systemami przechodzi, przynajmniej w obszarze objetym˛ zmianami, na producenta. Z tego powodu nalezy˙ za kazdym˙ razem sprawdzac,´ czy rozszerzenie standardu przez producenta zapewni obiecane korzysci´ takze˙ w dłuzszej˙ perspektywie. Mimo, ze˙ istniejace˛ od długiego czasu i sprawdzone implementacje referencji nie obsłuz˙a˛kazde˙ go Feature, oferuja˛one gwarancje˛ trwałej kompatybilnosci´ ze wszystkimi systemami sieciowymi.

3.5.3.1 Domain Name System (DNS)

Implementacja˛ referencji standardu Domain Name System zdeﬁniowanego w całym szeregu do- kumentów RFC jest BIND (Berkeley Internet Name Domain), który jest stale rozwijany i utrzy- mywany niezaleznie˙ od producenta przez Internet Software Consortium. Aktualna˛ jego wersja˛ jest 9.2.x, przy czym nadal istnieje i jest utrzymywana przez ISC gała˛z´ 8.3.x, która˛wykorzystuje duza˙ cze˛s´c´ zainstalowanych serwerów DNS. Bind 9 obsługuje miedzy˛ innymi dynamiczny DNS (DDNS), DNSSEC oraz IPv6. Połaczenie˛ BIND 9 z obcymi zródłami´ danych w celu zapewnienia informacji o strefach mozliwe˙ jest z jednej strony poprzez obszerny BackEnd Database Interface, a z drugiej strony istnieje dodatkowy, uproszczony interfejs (SDB), za pomoca˛ którego mozna˙ realizowac´ dostep˛ wyłacznie˛ do odczytu w oparciu o bazy danych LDAP albo SQL. Jednak połaczenia˛ te same w sobie nie sa˛ cze˛sci´ a˛ składowa˛ pakietu oprogramowania BIND. Istnieja˛ zatem, np. jesli´ chodzi o ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 137

połaczenie˛ LDAP, zarówno implementacje SDB, jak i predeﬁniowane klasy obiektów, za pomoca˛ których mozna˙ realizowac´ takie połaczenie.˛ BIND z ISC moze˙ takze˙ pracowac´ pod Windows NT / W2K. BIND obsługuje równiez˙ dynamiczna˛ aktualizacje˛ Service - Records oraz moze˙ swiadczy´ c´ odpowiednie usługi dla serwerów W2K.

3.5.3.2 Dynamic Host Conﬁguration Protocol (DHCP)

ISC rozwija i opiekuje sie˛ takze˙ implementacjami referencji DHCP. Protokół i oprogramowanie maja˛ nastepuj˛ ace˛ zadania bad˛ z´ mozliwo˙ sci:´

◦ automatyczne przydzielanie adresów IP i nazw komputerów klientom. DHCP zezwala za- równo na przydzielanie stałych adresów IP (na podstawie adresu MAC), jak tez˙ dynamiczne przydzielanie wolnego adresu z okreslone´ go zakresu adresów.

◦ automatyczne przekazywanie informacji o infrastrukturze sieci. Na przykład poprzez DHCP mozna˙ centralnie zarzadza˛ c´ i rozdzielac´ pomiedzy˛ wszystkich klientów domene˛ nazw, serwer nazw, Default - Route oraz maske˛ sieci.

◦ Oprócz tego mozliwe˙ jest dostarczanie przez dhcpd duzej˙ ilosci´ zdefiniowanych na stałe, opcjonalnych pól oraz dajac˛ ych sie˛ dowolnie definiowac´ informacji dotyczac˛ ych konfiguracji hosta. DHCPD z ISC moze,˙ miedzy˛ innymi, przekazywac´ wszystkie opcje, które moga˛ byc´ wykorzystane po stronie klientów windowsowych.

◦ Dodatkowo DHCPD moze˙ takze˙ pełnic´ role˛ BOOTPD i przekazywac´ do klienta wszystkie informacje wymagane w przypadku bootowania poprzez siec.´

W odniesieniu do wszystkich informacji wychodzac˛ ych dhcpd z ISC umozliwia˙ zarówno administrowanie indywidualnymi klientami, jak tez˙ zbiorowa˛ konfiguracje˛ klas i podsieci. Ponadto w konfiguracji dhcpd z ISC mozliwe˙ jest warunkowe przekazywanie danych konfiguracyjnych hosta za pomoca˛ instrukcji IF. DHCPD moze˙ byc´ stosowany w konfiguracji Failover zarówno dla Load - Balancing, jak i systemów wysokiej niezawodnosci´ (HA). Wtedy zarzadzane˛ dynamicznie zakresy IP koordyno- wane sa˛ pomiedzy˛ uzupełniajac˛ ymi sie˛ wzajemnie serwerami. Konfiguracja DHCPD z ISC odbywa sie˛ w tradycyjnym uniksowym stylu poprzez wykorzystanie pliku konfiguracyjnego w formacie ASCII. Istnieje łata, która umozliwia˙ dynamiczne sci´ aganie˛ konfiguracji serwera ISC - DHCP z repozytorium LDAP. Implementacja nastepuje˛ zgodnie z IETF Draft opisujac˛ ym schemat LDAP dla DHCP. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 138

3.5.3.3 Windows Internet Name Service (WINS)

Po przeprowadzeniu migracji przekształcanie nazw dla usług i komputerów windowsowych wykonywane jest przez nmbd z pakietu Samba. Z jednej strony tradycyjne w przypadku Windows usługi przegladania˛ oparte na Broadcast moga˛ byc´ swiadczone´ zarówno w postaci klienta, jak tez˙ jako lokalna, albo domenowa Master Browser. Z drugiej zas´ strony nmbd moze,˙ takze˙ jako WINS, koordynowac´ przegladanie˛ poza granicami segmentu sieci, które z reguły zwiazane˛ sa˛ z routerami nie przepuszczajac˛ ymi Broadcasts.

3.5.3.4 Network Time Protocol (NTP)

W przypadku wielu aplikacji sieciowych wymagany jest wysoki stopien´ synchronizacji. Uzy-˙ wajac˛ Network Time Protocol mozna˙ zsynchronizowac´ zegary komputerów w sieci lokalnej z dokładnosci´ a˛ co do mikrosekund. W przypadku stałego połaczenia˛ z Internetem istnieje mozli-˙ wos´c´ synchronizacji czasu referencyjnego z urzedo˛ wym Normal z dokładnosci´ a˛ liczona˛ w mi- lisekundach. Alternatywnie, jako zródła´ odniesienia wskazujace˛ czas Normal, moga˛ posłuzy˙ c´ takze˙ (miedzy˛ innymi) DCF77 i GPS. Implementacja referencji standardu jest stale rozwijana i utrzymywana w ramach Network Time Protocol Project. Oprogramowanie to mozna˙ stosowac´ takze˙ w Windows NT.

3.5.4 Migracja kontynuacyjna - usługi sieciowe pod Windows 2000

W nastepuj˛ ac˛ ych podrozdziałach zamiescili´ smy´ krótki opis nowosci´ zwiazan˛ ych z usługami sieciowymi, które wprowadzone zostały wraz z Windows 2000.

3.5.4.1 WINS

Windows 2000 nie oferuje nowosci´ w architekturze WINS. Ulepszone zostało jedynie zarzadza-˛ nie baza˛ danych WINS.

3.5.4.2 DNS

Wraz z wprowadzeniem Windows 2000 najwieksze˛ zmiany dotkneły˛ usługe˛ DNS. Główna˛ tego przyczyna˛ jest fakt, ze˙ Windows 2000 Active Directory wykorzystuje DNS do naczelnego prze- kształcania nazw bad˛ z´ inaczej mówiac,˛ nie mógłby on działac´ bez DNS. Active Directory wykorzystuje DNS miedzy˛ innymi do odnajdywania usług logowania i wyszukiwania (LDAP Service, Global Catalog Service i Kerberos KDC). Aby móc zapisywac´ usługi, DNS musi obsługiwac´ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 139

tak zwane SRV Records odpowiednio do standardu RFC 2052. Poniewaz˙ dotychczasowy DNS działał statycznie (wpisy trzeba było wprowadzac´ recznie),˛ w Windows 2000 ze wzgledu˛ na docelowa,˛ przyszła˛ rezygnacje z WINS, zaimplementowano rejestracje˛ dynamiczna;˛ komputery moga˛ dynamicznie zapisywac´ swoje A i SRV Records. Powyzsza˙ implementacja jest nastep-˛ stwem RFC 2136 (Dynamic Update). Komputery z Windows 2000 i nowszymi moga˛ same sie˛ rejestrowac´ (jest to realizowane w kliencie DHCP). Windows NT i Windows 9x tego nie potraﬁa˛ i raczej potrzebuja˛ pomocy DHCP z Windows 2000. Dynamiczna rejestracja pociaga˛ za soba˛ zmiane˛ w architekturze dotychczasowej implementacji DNS, zgodnie z która˛ tylko (naczelny) serwer DNS moze˙ zapisywac´ zawartos´c´ stref. Microsoft realizuje zasade˛ Multi - Master poprzez obsługe˛ DNS w ramach Active Directory. Wpisy DNS sa˛ tym samym obiektami bazy danych Active Directory i sa˛ one w ten sposób replikowane. Dynamiczna rejestracja bez integracji z AD nie istnieje. Dynamiczna rejestracja moze˙ byc´ ograniczana za pomoca˛ mechanizmów bezpieczenstwa´ w taki sposób, ze˙ mozliwa˙ jest rejestracja tylko tych komputerów, które moga˛ sie˛ autoryzowac.´ (np. klienty Windows 2000 przynaleznej˙ domeny). Windows 2000 obsługuje tak zwane „Secure Update“ odpowiednio do GSS - API zgodnie z RFC 2078. Realizacja RFCs 2535 (Domain Name System Security Extensions) lub 2137 (Secure Domain Name System Dynamic Update) nie jest mozliwa.˙

3.5.4.3 DHCP

Jesli´ chodzi o DHCP, Windows 2000 oferuje własne, godne uwagi, nowosci.´ W Windows 2000 obsługiwane sa˛ aktualne RFCs 2131 (Dynamic Host Configuration Protocol, wczesniejszy´ RFC 1541) oraz 2132 (DHCP Options and BOOTP Vendor Extensions). Oprócz ulepszonego zarza-˛ dzania obsługiwane sa˛teraz takze˙ Multicast Scopes, opcje uzytko˙ wnika i producenta DHCP, jak tez˙ dynamiczny BOOTP. Inna˛nowosci´ a˛jest integracja DHCP i DNS wewnatrz˛ sieci Windows 2000. Klienty Windows NT 4 lub starsze nie obsługuja˛dynamicznej rejestracji swoich nazw DNS w dynamicznym DNS z Windows 2000. O ile klienci ci pobieraja˛swoja˛konfiguracje˛ IP z Windows 2000 DHCP Server, serwer ten moze˙ przeja˛c´ rejestracje˛ w DNS. Klient DHCP z Windows 2000 moze,˙ jesli´ w jego podsieci znajduje sie˛ serwer DHCP, samodzielnie skonfigurowac´ swój IP. Uzywane˙ sa˛ w tym celu adresy IP sieci klasy B 169.154.0.0 z maska˛ podsieci 255.255.0.0. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 140 3.6 Kontrola i zarzadzanie˛ systemem

3.6.1 Przeglad˛

W niniejszym rozdziale nalezy˙ z góry zauwazy˙ c,´ ze˙ domyslne´ administrowanie odbywa sie˛ w Windows NT w oparciu o dostepne˛ tylko cze˛scio´ wo i bardzo niewyszukane narzedzia˛ do zarzadzania˛ systemem, co sprawia, ze˙ w wielu miejscach trzeba korzystac´ z oferujac˛ ych szero- kie mozliwo˙ sci´ narzedzi˛ dostarczanych przez innych producentów, które cze˛scio´ wo dostepne˛ sa˛ takze˙ dla systemów linuksowych. W Linuksie istnieje, oprócz wielu programów wchodzac˛ ych w skład samego systemu takich jak cron / at, cały szereg produktów COLS oraz rozwiaza˛ n´ OSS przeznaczonych do administrowania systemem. Mamy tu do dyspozycji, np. program Nagios słuz˙ac˛ y do wizualizacji i kontroli usług. Jest to kompleksowy, wysoce zintegrowany system, za pomoca˛ którego mozna˙ wykonac´ wszystkie systemowe zadania administracyjne. Obecnie program ten nie jest rozprowadzany jako OSS. Równiez˙ Microsoft rozszerzył swoja˛ „skrzynke˛ z narzedziami“˛ oferowana˛ wraz z kolejnymi produktami. W tym miejscu nalezy˙ wymienic´ Microsoft Operations Manager oraz Application Center.

3.6.2 Punkt wyjscia´ - serwery zarzadzaj˛ ace˛ systemem pod Windows NT 4

Systems Management Server (SMS) ukazał sie˛ na rynku niedawno, wraz z Windows NT 4. Za ostatnia˛wersje˛ SMS wywodzac˛ a˛sie˛ z tej generacji nalezy˙ uznac´ wersje˛ 1.2. W roku 1999 ukazała sie˛ wersja 2.0. Zakres funkcji w/w wersji został przedstawiony ponizej.˙ SMS integruje wiele podstawowych funkcjonalnosci,´ które dostarczane sa˛ równiez˙ przez innych producentów w postaci porównywalnego, zintegrowanego produktu. Sa˛ nimi:

◦ inwentaryzacja (inventory)

◦ zdalne sterowanie (remote control) oraz

◦ przydzielanie oprogramowania (software distribution)

Aby móc korzystac´ z tego oprogramowania serwerowego potrzebny jest Windows NT Server 4.0, Service Pack 4 albo jego nowsza wersja i Microsoft SQL Server 6.5. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 141

SMS 2.0 moze˙ byc´ stosowany w duzych˙ sieciach wraz z ponad 10.000 klientów. Poniewaz˙ mozna˙ go wpisac´ w windowsowa˛strukture˛ domen, istnieje mozliwo˙ sć´ bardzo dokładnego dozo- wania uprawnien.´ SMS obsługuje takze˙ Novell Netware NDS oraz srodo´ wiska Bindery. SMS 2.0 zawiera funkcje˛ elektronicznego przydzielania oprogramowania, która wykonuje dalece automatyczna˛ instalacje˛ i deinstalacje˛ oprogramowania, bez potrzeby, w idealnym przypadku, wykonywania prac na miejscu, tzn. bez błedów˛ po stronie uzytko˙ wnika. Proces przydzielania oprogramowania moze˙ przebiegac´ w oparciu o z góry ustalone reguły. Administratorzy definiuja˛ konfiguracje˛ oprogramowania poprzez dodawanie bad˛ z´ usuwanie komputerów, uzyt-˙ kowników albo grup uzytko˙ wników z list, zgodnie z wybranymi kryteriami. SMS protokołuje stan instalacji oprogramowania i aktualizacji systemu operacyjnego w taki sposób, ze˙ administratorzy systemu uzyskuja˛ informacje,˛ czy dane oprogramowanie zostało zainstalowane we własciwy´ sposób. SMS instaluje oprogramowanie automatycznie, bez udziału uzytko˙ wnika, przy czym proces instalacji posiada prawa administratora takze˙ wtedy, gdy uzytko˙ wnik komputera zalogowany jest z mniejszymi uprawnieniami. Komputery oparte na NT nie musza˛ byc´ zalogo- wane, co sprawia, ze˙ Feature to nadaje sie˛ do przydzielania oprogramowania poza regularnym czasem pracy. SMS umozliwia˙ przydzielanie oprogramowania dowolnie wskazanym uzytko˙ wnikom, grupom uzytko˙ wników, segmentom sieci TCP / IP i komputerom w zadanym czasie. SMS 2.0 dynamicznie wykrywa cele w/w przydzielania w oparciu o wytyczne grup i moze˙ te wytyczne stosowac´ we wszystkich miejscach. Jesli´ do grupy uzytko˙ wników dołacz˛ a˛nowi uzytko˙ w- nicy, wówczas w oparciu o wytyczna˛ danej grupy, automatycznie wysłane zostanie prawidłowe oprogramowanie. Tak zwane ustrukturyzowane przydzielanie pakietów uwzglednia˛ topologie˛ sieci, co ma zapewnic´ wydajne przydzielanie oprogramowania w przypadku wolnych połacze˛ n.´ Serwery stacjonarne pełnia˛ w takim przypadku role˛ routerów, które przydzielaja˛ oprogramowanie w sposób inteligentny i ustrukturyzowany. Dzieki˛ temu jeden proces przydzielania zawsze uzywa˙ połaczenia˛ WAN tylko raz. SMS 2.0 moze˙ rozsyłac´ oprogramowanie za pomoca˛Courier Sender poprzez CD-ROM albo inne media. Gdy tylko uzytko˙ wnik otrzyma dane medium (np. CD-ROM) i uruchomi je w systemie, zacznie sie˛ zautomatyzowany proces. Tworzenie pakietów oprogramowania mozliwe˙ jest dzieki˛ załaczonemu˛ programowi instalacyjnemu. Umozliwia˙ on administratorom dokonywanie zmian w pakietach instalacyjnych oraz pisanie skryptów w celu tworzenia aplikacji opartych na Windows. Dodatkowo SMS Installer zawiera technologie wrapper wykorzystywane do przydzielania oprogramowania, a takze˙ log function. Instalator uzywa˙ technologii shapshot. SMS 2.0 moze˙ przeprowadzac´ inwentaryzacje˛ osprzetu˛ i oprogramowania. Podczas inwentaryzacji osprzetu˛ opartej na CIM, SMS 2.0 zbiera dane w formacie CIM (Common Informa- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 142

tion Model), który umozliwia˙ SMS dostep˛ do wielu rózn˙ ych zródeł,´ w tym takze˙ do Microsoft Win32, SNMP i DMI. SMS zbiera obszerne dane inwentaryzacyjne, które mozna˙ filtrowac´ za pomoca˛opcji. Inwentaryzacja oprogramowania zbiera dokładne informacje o kazdej˙ aplikacji na kazdym˙ komputerze. SMS 2.0 nie szuka w predefiniowanej bazie danych, lecz w kazdym˙ pliku wykonywalnym na komputerze klienckim według informacji o zasobach i wersjach. Dane inwentaryzacyjne moga˛ byc´ wykorzystane jako podstawa dla przydzielania oprogramowania opartego na regułach. Zdalne sterowanie (Remote Control) umozliwia˙ wykonywanie aplikacji na odległosć,´ komu- nikowanie sie˛ przez okna Chat z uzytko˙ wnikami konco´ wymi, jak równiez˙ ponowne uruchamianie komputerów. Ponadto mozliwe˙ jest sterowanie ekranem, klawiatura˛ i mysza.˛ SMS 2.0 moze,˙ jesli´ chodzi o zarzadzanie˛ siecia,˛ pełnic´ nastepuj˛ ace˛ zadania:

◦ za pomoca˛ SMS mozna˙ wyswietla´ c´ i wizualizowac´ topologie˛ sieci, klientów, jak tez˙ wykorzystywane systemy operacyjne.

◦ SMS tworzy podglad˛ serwerów i urzadze˛ n´ sieciowych, co ma pomóc administratorom systemu podczas zarzadzania˛ siecia˛ i usuwania błedów˛ , np. wykrywane sa˛ niepotrzebne protokoły, podwójnie przydzielone adresy IP oraz niedozwolone próby dostepu˛ z Internetu. Monitor sieci moze˙ automatycznie interpretowac´ znalezione wyniki.

SMS 2.0 oferuje narzedzia˛ do analizy, kontroli i sterowania aplikacjami na serwerach i stacjach roboczych (pomiar oprogramowania). Mozna˙ przy tym w uporzadko˛ wany sposób sledzi´ c´ wykorzystanie oprogramowania według uzytko˙ wników, grupy, stacji roboczej, czasu albo ograniczen´ licencyjnych. Dodatkowo mozna˙ zdefiniowac´ granice kontyngentów albo ustalic,´ z jakich aplikacji nie wolno korzystac.´ Ponadto mozna˙ kontrolowac´ przestrzeganie zasad przez kazde˙ go dowolnego klienta albo serwer. Programy słuz˙ace˛ do pomiaru oprogramowania wykrywaja˛rów- niez˙ róznice˙ wersji i moga˛stwierdzic,´ czy agenci klientów zostali dezaktywowani, co ma na celu zapewnienia szerokiej ochrony przed manipulacjami. Statystyki dotyczace˛ wykorzystania oprogramowania moga˛ posłuzy˙ c´ do planowania licencjonowania oprogramowania i do obejmowania opłatami działów w zalezno˙ sci´ od wykorzystywanych w nich aplikacji (zarzadzanie˛ licencyjne). Kontrola serwera odbywa sie˛ za pomoca˛ HealthMon. HealthMon ustala dane nt. wydajnosci´ procesów działajac˛ ych na serwerach Windows NT i Microsoft BackOffice. Na konsoli HealthMon mozna˙ wprowadzac´ krytyczne wartosci´ progowe albo wartosci´ progowe dla ostrzeze˙ n´ w celu uzyskiwania w czasie rzeczywistym, zdefiniowanych w oparciu o wyjatki,˛ informacji o stanie, które mozna˙ grupowac´ według zasobów na poziomie systemu albo według aplikacji i procesów serwera Microsoft. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 143

3.6.3 Migracja zastepuj˛ aca˛ - Linux

Zarzadzanie˛ systemem w przypadku systemów operacyjnych OSS opiera sie˛ na podstawowej funkcjonalnosci´ sieciowego sytemu operacyjnego skupiajace˛ go wielu uzytko˙ wników. Admini- strator mozne˙ pracowac´ z odległego miejsca na kazdym˙ komputerze z Linuksem albo BSD, obojetnie˛ czy bedzie˛ to klient, czy serwer, w taki sam sposób, jak na lokalnym komputerze. Gra- ficzny interfejs uzytko˙ wnika, dzieki˛ jego systemowemu oddzieleniu od serwera (wyswietlacz,´ klawiatura i mysz) oraz oprogramowaniu klienckiemu, które prezentuje swoje okna i znaki na wyswietlaczu´ lokalnie albo na odległosć´ poprzez połaczenie˛ sieciowe oraz dzieki˛ przyjmowaniu danych z serwera, wspaniale nadaje sie˛ takze,˙ miedzy˛ innymi, do zdalnej obsługi komputerów. Do tego dochodza˛Secure Shell (ssh) i narzedzia˛ z bogato wyposazonej˙ „skrzynki z narzedziami“,˛ takie jak cron / at do zarzadzania˛ zadaniami w czasie oraz pote˛zne˙ interpretatory pracujace˛ z linii polecen,´ Utilities i interpretowane jezyki˛ programowania, które mozna˙ wykorzystywac´ do zaawansowanego automatyzowania zadan´ routine. Aby zdalnie sterowac´ systemami OSS nie jest wymagane dodatkowe oprogramowanie. Do scentralizowanego zarzadzania˛ systemem w sieciach heterogenicznych, takze˙ w systemach OSS, mozna˙ wykorzystywac´ dodatkowe składniki. Na górnym koncu´ skali mozna˙ zintegrowac´ Linuksa z systemem zarzadzania˛ Tivoli albo OpenView. Pomiedzy˛ powyzszymi˙ rozwia-˛ zaniami, których nie zalicza sie˛ do OSS, a prostym zarzadzaniem˛ za pomoca˛narzedzi˛ nalez˙ac˛ ych do sytemu operacyjnego istnieje duza˙ ilosć´ programów, które kazdorazo˙ wo umozliwiaj˙ a˛ wykonywanie okreslon´ ych zadan´ w systemie albo jego automatyzacje.˛

3.6.3.1 Administrowanie oprogramowaniem

Istnieja˛ komercyjne rozwiazania,˛ oferowane przez rózn˙ ych producentów, słuz˙ace˛ do inwentaryzacji, przydzielania i aktualizacji, jak równiez˙ do zarzadzania˛ konﬁguracja˛ składników oprogramowania. Niektóre z tych rozwiaza˛ n´ przeznaczone sa˛ takze˙ dla heterogenicznych systemów z udziałem Windows. Jesli´ chodzi o Wolne Oprogramowanie, nie istnieje gotowe do wykorzystania produkcyjnego, zintegrowane rozwiazanie,˛ w szczególnosci´ dla srodo´ wisk heterogenicznych. Jednak za pomoca˛ narzedzi˛ przeznaczonych do administrowania pakietami (RPM i APT) mozna˙ w bardzo łatwy sposób scentralizowac´ inwentaryzacje˛ oraz przydzielanie bad˛ z´ uaktual- nianie oprogramowania. Do centralnego zarzadzania˛ pakietami wspaniale nadaje sie˛ zwłaszcza system zarzadzania˛ pakietami Debiana, poniewaz˙ pracuja˛ one w oparciu o hierarchie˛ z centralnych repozytoriów i dysponuja˛ bardzo mocnym systemem aktualizacji. W obszarze bezpieczenstwa,´ narzedziem,˛ które nalezy˙ stosowac´ do inwentaryzacji i kontroli oprogramowania jest Tripwire. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 144

3.6.3.2 Administrowanie siecia˛

Jesli´ chodzi o zarzadzanie˛ sieciami TCP / IP, istnieje duzy˙ wybór programów o rózn˙ ych punktach cie˛zko˙ sci.´ Narzedzie˛ do monitoringu „Nagios“ specjalizuje sie˛ w wizualizacji topologii sieci i w kontroli usług, udostepnian˛ ych takze˙ na serwerach z innymi systemami operacyjnymi. Nagios re- aguje, na znalezione błedy˛ albo zachodzace˛ wydarzenia, w oparciu o zadane reguły, np. na podstawie zdefiniowanych wartosci´ progowych. Mozliwe˙ jest przy tym zwiekszanie˛ ilosci´ komuni- katów i właczanie˛ rózn˙ ych kanałów informacyjnych (np. mail albo SMS). Nagios obsługuje Plug-Ins do aktywnej albo pasywnej kontroli najrózniejszych˙ usług i para- metrów systemu. Miedzy˛ innymi kontrolowane moga˛byc´ typowe usługi sieciowe takie jak Web, Mail i LDAP, rózne˙ RDBMS albo Samba. Ponadto istnieja˛ Plug - Ins umozliwiaj˙ ace˛ nadzór nad takimi parametrami systemu, jak obcia˛zenie˙ CPU, ilosć´ wolnego miejsca na dysku, a takze˙ danymi z czujników (temperatura, zasilanie i liczba obrotów wentylatorów). Istnieja˛ mostki do innych systemów takich jak MRTG / RRD oraz umozliwiaj˙ ace˛ wykorzystanie SNMP do monitorowania. Programami wyspecjalizowanymi w monitoringu i analizie ruchu w sieci sa˛ MRTG / RRD. MRTG uzywa˙ Simple Network Management Protocol do zbierania i zapisywania danych o ruchu z najrózniejszych˙ składników sieciowych. Ich ocena i prezentacja graficzna moze˙ byc´ realizowana wewnetrznie˛ przez MRTG albo z zewnatrz˛ za pomoca˛ RRD. MRTG ma do dyspozycji ponad 350 templates słuz˙ac˛ ych do bezposrednie´ go łaczenia˛ najrózniejszych,˙ działajac˛ ych z SNMP składników i usług sieciowych. Innym narzedziem˛ do analizy i wizualizacji ruchu jest NeTraMet, który równiez˙ pracuje z SNMP. Scotty to kolejne narzedzie˛ do wizualizacji i zarzadzania˛ lokalnymi sieciami, pracujac˛ ym takze˙ z SNMP i takze˙ zezwalajac˛ ym na zmiane˛ dostepn˛ ych parametrów SNMP dla odległych składników sieci. W wyszukiwaniu powtarzajac˛ ych sie˛ wzorców, w ruchu sieciowym majac˛ ym na celu wy- krycie prób włamania albo innych podejrzanych działan,´ wyspecjalizował sie˛ Snort. Jako „Li- ghtweight Intrusion Detection System“ jest on wartoscio´ wym składnikiem systemu zarzadzania˛ siecia.˛

3.6.3.3 Administrowanie serwerami

Jesli´ chodzi o administrowanie serwerami, do kontroli i ograniczania zasobów systemowych pojedynczych uzytko˙ wników lub procesów słuz˙a˛ w Linuksie m.in. Ulimits, Quotas i Process ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 145

Accounting. Monitoring usług i lokalnych parametrów systemu wykonywany jest przez przedstawiony w poprzednim podrozdziale program Nagios. Serwery OSS wykorzystuja˛ wspólne API do protokołowania komunikatów poprzez syslogd. Protokołowanie takie pozwala na zorganizowana˛ hierarchicznie, centralna˛ kontrole˛ całej infrastruktury Linux / BSD / UNIX. Takze˙ serwery windowsowe moga˛ zostac´ właczone˛ w centralny system syslog. Do automatycznej oceny zawartosci´ plików logowania wykorzystywanych jest wiele narzedzi˛ i rozwiaza˛ n,´ zarówno opartych na aplikacjach, jak i generowanych. Ich analiza znajduje sie˛ na stronie http://www.counterpane.com/log-analysis.html. Aby przy okazji zarzadzania˛ serwerem zapewnic´ konieczne wyszukiwanie błedów˛ , nalezy˙ skorzystac´ z narzedzi˛ systemowych wykraczajac˛ ych poza regularne usługi protokołowe, a oferujac˛ ych duze˙ mozliwo˙ sci´ analityczne, np. strace, lsof, fuser i netstat.

3.6.3.4 Systemy złozone˙

W zakresie zarzadzania˛ systemem istnieje oprócz Simple Network Management Protocol takze˙ Common Information Model (CIM) wraz z opartym na nim Web Based Enterprise Management (WBEM), które słuz˙a˛do szerszych zastosowan´ podczas standardowego zarzadzania˛ systemem w sieciach heterogenicznych. CIM / WBEM sa,˛ podobnie jak SNMP, opisane w otwartych standardach i dostepne˛ w implementacjach referencji jako Wolne Oprogramowanie. Jednak składniki te wykorzystywane sa˛obecnie raczej w ramach produktów komercyjnych. Praktyczna przydatnos´c´ czystych rozwiaza˛ n´ Open Source w tym obszarze musi sie˛ dopiero wykształcic.´

3.6.3.5 Wnioski

Jesli´ chodzi o zarzadzanie˛ systemem, systemy operacyjne OSS poda˛zaj˙ a˛ sladami´ swojego pier- wowzoru, tj. Uniksa. Jako sieciowe systemy wielu uzytko˙ wników posiadaja˛ one bardzo rózno-˙ rodne funkcje umozliwiaj˙ ace˛ centralne zarzadzanie˛ systemem i w niektórych obszarach moga˛ byc´ wzorem, a nie uzupełniajac˛ a˛ alternatywa˛ dla rozwiaza˛ n´ windowsowych. Migracja oznacza takze˙ zmiany koncepcyjne dla administratorów i w organizacji pracy, które przyczynia˛ sie˛ do zrobienia duzych˙ postepów˛ , w szczególnosci´ jesli´ chodzi o bezpieczenstwo.´ Własnie´ bezpieczenstwo´ i stabilne działanie sa˛ cechami charakterystycznymi dla ogólnie pojetych˛ systemów linuksowych wynikajac˛ ymi takze˙ z systemu zarzadzania.˛ Dla osób, którym powierzone zostanie wdrozenie˙ projektu migracyjnego oznacza on wyrazne´ zmiany. Zarówno mozliwo˙ sci´ analizy, jak tez˙ opcje dostosowania i korekty systemów OSS daja˛ administratorom systemu o wiele wiecej˛ swobody, niz˙ mieli oni w przypadku zamkniete˛ go systemu Windows. Wolnos´c´ te˛ mozna˙ wykorzystac´ w celu uniezaleznienia˙ sie˛ od producentów ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 146

i zewnetrzn˛ ych swiadczenioda´ wców oraz zarazem do podnoszenia kwaliﬁkacji własnych pra- cowników. Przejrzystos´c´ otwartych systemów OSS ułatwia podstawowe i dogłebne˛ zrozumienie funkcji i zalezno˙ sci´ rózn˙ ych składników nowoczesnej infrastruktury informatycznej.

3.6.4 Migracja kontynuacyjna - Windows 2000

3.6.4.1 Microsoft Operations Manager

Microsoft Operations Manager (MOM) opiera sie˛ na oprogramowaniu firmy NetIQ i jesli´ chodzi o kontrole˛ procesów, wydajnosci´ oraz zarzadzanie,˛ pozwala on administrowac´ systemami serwerowymi opartymi na Windows 2000. Obecna˛ wersja˛ Microsoft Operations Manager jest MOM 2000. Oferuje ona nastepuj˛ ace˛ funkcjonalnosci:´ MOM zbiera do centralnego repozytorium zdarzen´ róznorodne˙ informacje o procesach zwia-˛ zanych z działaniem systemu oraz aplikacji pracujac˛ ych w dzielonym srodo´ wisku IT w systemach windowsowych. W ten sposób powstaje dzielone zarzadzanie˛ procesami. Administratorzy moga˛ korzystac´ z przegladu˛ wszystkich zdarzen,´ co daje im wiedze˛ nt. dostepn˛ ych serwerów i usług. W MOM mozna˙ tworzyc´ reguły. W oparciu o rozwiniete˛ reguły system moze˙ automatycznie reagowac´ na napływajace˛ informacje. Dzieje sie˛ tak dzieki˛ predefiniowanemu procesowi opartemu na specjalnym scenariuszu błedów˛ albo wskutek nastapienia˛ konkretnego zdarzenia. Korzystajac˛ z takich reguł MOM moze˙ reagowac´ na okreslone´ wzorce wydarzen´ i procesów, wzglednie˛ wysyłac´ komunikaty ostrzegawcze zdefiniowane przez administratora. Kazd˙ a˛ regułe˛ MOM mozna˙ zdefiniowac´ w taki sposób, by były generowane specjalne ostrzezenia˙ przyporzadko˛ wane odpowiednim stopniom bezpieczenstwa.´ Ostrzezenie˙ moze˙ pojawic´ sie˛ wskutek pojedynczego zdarzenia albo wielu zdarzen´ pochodzac˛ ych z licznych zródeł.´ Administrator ma zawsze mozliwo˙ sć´ przeanalizowania przyczyn ostrzezenia˙ i odpowiednich zdarzen.´ Ponadto moz-˙ liwe jest wywoływanie ostrzeze˙ n,´ wiadomosci´ e - mail, jak równiez˙ Traps stron i Traps SNMP (Simple Network Management Protocol). Za pomoca˛ MOM mozna˙ wprowadzic´ kontrole˛ wydajnosci´ przyłaczon˛ ych systemów. Dodatkowo mozna˙ okresli´ c´ wartosci´ progowe wydajnosci´ i je kontrolowac.´ Poprzez dopasowanie lub dodanie reguł mozna,˙ dla pózniejszych´ referencji albo planowania pojemnosci,´ kontrolowac´ rozwój wydajnosci´ systemu i aplikacji. Oprócz tego mozna˙ ustawic´ lokalne i grupowe wartosci´ progowe, które bed˛ a˛ uruchamiac,´ w reakcji na zmiany wydajnosci´ systemu lub aplikacji, ostrzezenia˙ albo procesy wymagajace˛ interwencji administratora. Portfolio usług, jakimi nalezy˙ zarzadza˛ c´ mozna˙ rozszerzac´ za pomoca˛ Management Packs. Management Packs zawieraja˛ predefiniowane reguły MOM. Kazdy˙ pakiet oferuje reguły dla ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 147

okreslon´ ych aplikacji lub usług. MOM standardowo zawiera Management Pack, za pomoca˛któ- rego mozna˙ zarzadza˛ c´ wszystkimi usługami windowsowymi, w tym takze˙ usługa˛ katalogowa˛ Active Directory oraz usługami informacyjnymi (Internet Information Services, ISS). Dostepne˛ sa˛ równiez˙ inne Management Packs ﬁrmy Microsoft i innych producentów. Microsoft oferuje Management Packs dla nastepuj˛ ac˛ ych produktów:

◦ Exchange 2000 and 5.5

◦ SQL 2000 and 7.0

◦ Commerce Server 2000

◦ Internet Acceleration and Security Server 2000

◦ Host Integration Server 2000

◦ Application Center 2000

◦ Site Server 3.0

◦ Proxy 2.0

◦ SNA 4.0

MOM oferuje mozliwo˙ sć´ przygotowania i przedstawienia zebranych danych w formie raportów. Narzedzie˛ do tworzenia graficznych raportów umozliwia˙ dostep˛ do wczesniej´ wygenerowanych raportów i diagramów. Daja˛ one administratorowi mozliwo˙ sć´ sprawdzania stanu systemów i usług w sieci. Za pomoca˛ Management Packs firmy Microsoft albo innych producentów moz-˙ liwe jest dodanie do systemu dodatkowych raportów. Szczególna˛ cecha˛ MOM jest to, ze˙ moze˙ generowac´ snapshots oparte na HTML dla wszystkich gotowych raportów. Migawki takie mozna˙ nastepnie˛ wyeksportowac´ do serwera WWW, co pozwoli na dostep˛ do nich z poziomu przegla-˛ darek WWW. Do instalacji konieczny jest Windows 2000. Zalecana˛baza˛danych jest MS SQL 2000, jednak mozna˙ takze˙ skorzystac´ z MS Access.

3.6.4.2 Application Center

Microsoft Application Center 2000 jest narzedziem˛ do administrowania i udostepniania˛ wysoko niezawodnych aplikacji WWW, które zostały przygotowane w systemie operacyjnym Microsoft Windows 2000. Application Center 2000 upraszcza administrowanie grupami serwerów. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 148 3.7 Usługi katalogowe

3.7.1 Przeglad˛

Poniewaz˙ usługa katalogowa nie jest, z punktu widzenia sytuacji wyjscio´ wej, cze˛sci´ a˛ składowa˛ Windows NT, ponizsze˙ oceny nie koncentruja˛ sie˛ na zastapieniu˛ bad˛ z´ kontynuacji istniejacej˛ usługi katalogowej. Mimo to usługa katalogowa odgrywa wazn˙ a˛ role,˛ zarówno podczas migracji zastepuj˛ acej,˛ jak i kontynuacyjnej. Wraz z migracja˛ do Windows 2000 oraz w szczególnosci´ w przypadku migracji do Exchange 2000, zastosowanie Active Directory jest niemalze˙ wymu- szone. Skorzystanie z usługi katalogowej podczas migracji zastepuj˛ acej˛ - rozwiazaniem˛ OSS bedzie˛ tu OpenLDAP - niesie ze soba˛ wiele zalet, szczególnie jesli´ chodzi o wygodna˛ realizacje˛ autoryzacji. W zwiazku˛ z tym ponizsza,˙ techniczna ocena jest raczej spojrzeniem wybiegajac˛ ym w przyszłosć´ i przedstawia szczególne cechy kazdorazo˙ wego wprowadzenia usługi katalogowej, wzglednie˛ mozliwo˙ sci´ jej wprowadzenia. Interesujac˛ ym aspektem tego spojrzenia sa:˛ integra- cyjne oddziaływanie Active Directory (AD) oraz mozliwo˙ sć´ przeciwdziałania mu. Podsumowujac˛ mozna˙ stwierdzic,´ ze˙ z AD nalezy˙ korzystac´ w minimalnym zakresie, o ile w ogóle nie mozna˙ z niego zrezygnowac.´ Wieksze˛ wymagania nalezy˙ realizowac´ korzystajac˛ z innych produktów i rozwiaza˛ n,´ np. z Metadirectory. Ponadto jest to własciwy´ moment, by zastanowic´ sie,˛ kiedy obejsć´ AD i zastosowac´ tryb natywny oraz by dokonac´ prawidłowego doboru ewentualnych opcji.

3.7.2 Podstawy

Za pomoca˛ usługi katalogowej mozna˙ udostepnia˛ c´ w sieci dowolne informacje. Usługa katalogowa składa sie˛ zazwyczaj z bazy danych, w której zapisywane sa˛ informacje oraz z protokołu sieciowego, za pomoca˛ którego mozliwe˙ jest odpytywanie i zmiana informacji. Obecnie najcze-˛ sciej´ stosowanym protokołem usług katalogowych jest Lightweight Directory Access Protocol (LDA). LDAP został stworzony, aby w prosty sposób zapewnic´ dostep˛ do usług katalogowych opartych na X.500. Dzisiaj pod pojeciem˛ serwera LDAP rozumie sie˛ najcze˛sciej´ kombinacje˛ bazy danych i implementacji protokołu. LDAP w wersji 3 jest zdeﬁniowany w RFC 2251. Typowa˛ cecha˛ usługi katalogowej jest hierarchiczna struktura przechowywanych informacji, podobnie jak ma to miejsce w systemie plików. Patrzac˛ od samego dołu informacje znajduja˛sie˛ w obiektach, przy czym kazdy˙ obiekt posiada pewna˛ilos´c´ atrybutów, których wartosci´ reprezentuja˛ własciwe´ informacje. Kazdy˙ obiekt moze˙ zawierac´ jednoczesnie´ podobiekty (wraz atrybutami), które moga˛ posiadac´ kolejne podobiekty. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 149

Obiekty w usłudze katalogowej sa˛ osobnymi, jesli´ chodzi o zawartosć,´ jednostkami takimi jak, np. osoby, grupy, komputery, drukarki albo sale konferencyjne w budynku. To, jakie atrybuty moze˙ a jakie musi posiadac´ obiekt, definiowane jest poprzez klasy obiektów danego obiektu. Klasa obiektu wystepuj˛ aca˛ w wielu katalogach moze,˙ np. byc´ oznaczona, jako person i na- kazywac,´ zeby˙ obiekty w tej klasie posiadały przynajmniej atrybut surname (nazwisko) oraz commonName (ogólna nazwa). Dodatkowo zezwala ona na stosowanie opcjonalnych atrybutów, m.in. telephoneNumber (numer telefonu) i description (opis). Klasy obiektów oraz atrybuty zdefiniowane sa˛ w tak zwanym schemacie katalogu. Dzieki˛ mozliwo˙ sci´ przyporzadko˛ wania (takze˙ wtórnego) obiektom wielu klas obiektów, uzyskano duze˙ mozliwo˙ sci´ dostosowawcze oraz moz-˙ liwosć´ zapisywania zwiazan˛ ych ze soba˛ informacji w tym samym miejscu (mianowicie w tym samym obiekcie). Osoba moze˙ posiadac´ wiele wzajemnych, powiazan˛ ych swoja˛ zawartosci´ a,˛ własciwo´ sci,´ które musza˛ byc´ zdefiniowane za pomoca˛rózn˙ ych klas obiektów (rózn˙ ych, przeni- kajac˛ ych sie˛ atrybutów). Oznacza to, ze˙ np. osoba moze˙ byc´ widziana jako uzytko˙ wnik systemów komputerowych, wpis w ksia˛zce˙ telefonicznej, wpis w ksia˛zce˙ adresowej albo partner zycio˙ wy innej osoby. Jesli´ chcielibysmy´ zapisac´ niniejsze własciwo´ sci´ w jednym katalogu, wówczas dla klas własciwo´ sci:´ uzytko˙ wnik, wpis w ksia˛zce˙ telefonicznej, wpis w ksia˛zce˙ adresowej i partner zycio˙ wy musielibysmy´ zdefiniowac´ odpowiednie klasy obiektów wraz z atrybutami. Aby kazda˙ z klas obiektów mogła byc´ sensownie uzywana˙ takze˙ bez innych klas, kazda˙ z nich musiałaby prawdopodobnie posiadac´ atrybuty, które wstepuj˛ a˛równiez˙ w pozostałych wymaganych klasach obiektów, np. nazwisko osoby. Jesli´ klasy obiektów sa˛ powiazane˛ ze soba˛ w jednym obiekcie, wówczas atrybut Name trzeba zapisac´ tylko jeden raz. Mozliwo˙ sć´ korzystania z hierarchicznej struktury katalogów jest zazwyczaj wykorzystywana do odwzorowania w katalogu struktury organizacji. W tym celu stosuje sie˛ najcze˛sciej´ specjalne obiekty, które słuz˙a˛ do strukturyzacji katalogu i odpowiadaja˛ sztucznym albo rzeczywistym jed- nostkom organizacyjnym. Obiekty te czesto˛ uzywaj˙ a˛ klasy organizationalUnit (ou). Poza tym, ze wzgledu˛ na zapewnienie przejrzystosci,´ usługa katalogowa tworzona jest w oparciu o i tak istniejace˛ juz˙ w organizacji przestrzenie nazw DNS. W tym celu wykorzystuje sie˛ klase˛ domain- Component (dc). W praktyce zgrubna struktura tworzona jest najcze˛sciej´ w oparciu o przestrzenie nazw DNS a dokładna struktura za pomoca˛ jednostek organizacyjnych i innych container objects. Za przykład moze˙ posłuzy˙ c´ organizacja majaca˛ swoja˛siedzibe˛ w dwóch miejscach (dzielnica zachodnia i dzielnica wschodnia). Uzywa˙ ona domeny DNS miasto.pl i poddomen dla obydwu siedzib wsch.miasto.pl oraz zach.miasto.pl. Za punkt wyjscia´ dla katalogu organizacja taka mo- głaby uznac´ obiekt „miasto.pl“. Byłby on w LDAP zapisany jako dc=miasto,dc=pl, co miałoby ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 150

oznaczac,´ ze˙ w przypadku podstawowego punktu odniesienia chodzi o typ obiektu składnik domeny (domainComponent, dc), ze˙ obiekt nazywa sie˛ miasto, a podobiekt obiektu nosi nazwe˛ de i jego typem równiez˙ jest składnik domeny. Taki punkt wyjscia´ objałby˛ z kolei dwa nastepne˛ obiekty oznaczone dc=wsch i dc=zach (analogicznie do nazw DNS w/w siedzib). Powyzsze˙ oznaczenia nazywa sie˛ takze˙ wzgledn˛ ymi nazwami obiektów, poniewaz˙ nie wskazuja˛ one jednoznacznie swojego połozenia˙ w hierarchii katalogu. Alternatywnie mozna˙ korzystac´ z nazw jednoznacznych (distinguished Names), za pomoca˛których mozna˙ oznaczyc´ dokładne połozenie˙ obiektów w katalogu. Nazwy takie wygla-˛ dałyby wówczas nastepuj˛ aco:˛ dc=wsch,dc=miasto,dc=pl oraz dc=zach,dc=miasto,dc=pl . Niech w kazdej˙ z dwóch w/w siedzib dana organizacja ma trzy jednostki organizacyjne oznaczone jako produkcja, dystrybucja i kierownictwo. Aby móc odwzorowac´ je w katalogu, dla jednostki organizacyjnej produkcja mieszczacej˛ sie˛ w siedzibie w dzielnicy wschodniej nalezałoby˙ załozy˙ c´ obiekt ou=produktion jako podobiekt dc=wsch (jednoznaczna nazwa: ou=produktion,dc=wsch, dc=miasto,dc=pl). Analogicznie nalezałoby˙ postapi˛ c´ z pozostałymi jednostkami organizacyjnymi mieszczac˛ ymi sie˛ w obydwu siedzibach. Nalezałoby˙ , np. wewnatrz˛ jednostki organizacyjnej produkcja utworzyc´ obiekty takie jak osoby, grupy osób oraz komputery. W celu bardziej przejrzystego kształtowania tworzonej struktury w/w obiekty mozna˙ uporzadko˛ wac´ w containers (na ogół oznacza sie˛ je nazwami albo za pomoca˛commonName, cn) i przypisac´ nastepuj˛ ace˛ oznaczenia: cn=osoby, cn=grupy i cn=komputery. Na koniec nalezałoby˙ utworzyc´ wpisy dla rzeczywistych obiektów znajdujac˛ ych sie˛ w containers. I tak, np. trzeba by w pojemniku załozy˙ c´ naste-˛ pujac˛ y obiekt dla pracownika „Grzegorz Brzeczyszczykie˛ wicz“, zatrudnionego w dziale produkcja w siedzibie znajdujacej˛ sie˛ we wschodniej dzielnicy: cn=ludzie,ou=produkcja,dc=wsch,dc=miasto,dc=pl . Obiekt taki miałby wówczas nazwe:˛ cn=brzeczyszczykie˛ wicz,cn=ludzie,ou=produkcja,dc=wsch,dc=miasto.dc=pl . Oczywiscie´ korzystanie z usługi katalogowej ma sens tylko w przypadku wykorzystywania mozliwie˙ wielu aplikacji. W najlepszym układzie jest ona jedynym zródłem´ informacji zapisanych w sieci. Gdy, np. w sieci jakiejs´ organizacji pracuja,˛ np. serwery oparte na Windows i Uniksie, aplikacja intranetowa oraz Web - Proxy z autoryzacja,˛ wówczas dla poszczególnych systemów trzeba oddzielnie konﬁgurowac´ konta uzytko˙ wników i ich uprawnienia. Wraz z wdrozeniem˙ usługi katalogowej mozliwe˙ staje sie˛ centralne zdeﬁniowanie w usłudze katalogowej kont uzytko˙ wników oraz ich uprawnien´ i zezwolenie innym systemom na korzystanie ze wspólnych danych. Jednoczesnie´ aplikacje z ksia˛zkami˙ adresowymi, np. wbudowanymi w oprogramowanie pocztowe, moga˛ miec´ dostep˛ do wspólnego katalogu i w ten sposób udostepnia˛ c´ adresy e - mail członkom danej organizacji, bez koniecznosci´ ponownego, reczne˛ go wprowadzania danych. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 151

Usługi katalogowe moga˛ takze˙ słuzy˙ c´ do zapisywania haseł (hasła te staja˛ sie˛ zazwyczaj atrybutem obiektów osób albo kont uzytko˙ wników). Takze˙ w ten sposób realizowany jest cel jednorazowego, centralnego przechowywania danych. Hasła zapisane w katalogu trzeba tylko załozy˙ c´ oraz zmienic´ w jednym miejscu i juz˙ mozna˙ z nich korzystac´ we wszystkich systemach i ze wszystkimi aplikacjami, które moga˛ uzywa˙ c´ danego katalogu do autoryzacji. Ponadto hasła zapisane w katalogu moga˛ byc´ wykorzystane w przypadku autoryzacji dostepu˛ do danych w samym katalogu. Przykład zapisywania haseł pokazuje, potrzebe˛ istnienia bardzo szczegółowego systemu dostepu˛ do usługi katalogowej, który okreslałby´ , jakie obiekty i atrybuty i przez jakich uzytko˙ w- ników moga˛ byc´ czytane lub zmieniane. Z tego powodu celowe jest zadanie takich ustawien,´ by hasła mogły byc´ zmieniane tylko przez swoich uzytko˙ wników i administratorów. Oprócz tego musza˛ one móc słuzy˙ c´ swoim uzytko˙ wnikom do autoryzacji. Z drugiej strony, wszystkie inne osoby, które maja˛dostep˛ do katalogu, nie moga˛ miec´ prawa do czytania haseł, nawet wów- czas, jesli´ hasła w katalogu sa˛zaszyfrowane. Jednoczesnie´ dozwolone jest, aby inni uzytko˙ wnicy mogli czytac´ adresy e - mail z obiektów uzytko˙ wników. W takim przypadku rózne˙ przydawki (hasło i adres e - mail) tego samego obiektu (osoba i uzytko˙ wnik) musiałyby byc´ wyposazone˙ w rózne˙ uprawnienia. Dlatego wiekszo˛ sć´ usług katalogowych ma zaimplementowany system Access Controll Lists (ACLs), który mozna˙ porównac´ z ACLs na poziomie systemu plików. Pomimo szerokiego, praktycznego wykorzystania usług katalogowych do autoryzacji, strategie˛ taka˛ nalezy˙ uznac´ za watpliw˛ a.˛ Rozwiazanie˛ tego typu nie daje mozliwo˙ sci´ bezpiecznej implementacji Single Sing On, poniewaz˙ w kazdym˙ systemie i kazdej˙ aplikacji wymagana jest ponowna autoryzacja (w dodatku za pomoca˛ tego samego hasła). Ponadto wiekszo˛ sć´ usług katalogowych nie została napisane w celu udostepniania˛ bezpiecznego mechanizmu autoryzacji, lecz aby móc centralnie gromadzic´ informacje i szybko przesyłac´ je do klientów. Dlatego zamiast w/w metody zalecane jest stosowanie Kerberos. W przypadku wykorzystywania Kerberos nazwy oraz hasła uzytko˙ wników nie sa,˛ podobnie jak jest to na ogół przyjete˛ w innych rozwiazaniach,˛ wysyłane do kazde˙ go serwera, z któ- rego usług moze˙ korzystac´ kazdy˙ uzytko˙ wnik, lecz nastepuje˛ tu jednorazowe zalogowanie go do Key Distribution Center (KDC, nazywane takze˙ kontrolerem domen Kerberos). Po zalogo- waniu uzytko˙ wnik otrzymuje Ticket, który ma zdefiniowany czas wazno˙ sci´ i za pomoca˛ którego mozna˙ autoryzowac´ sie˛ we wszystkich kolejnych usługach. Po upływie terminu wazno˙ sci´ biletu uzytko˙ wnik musi sie˛ ponownie autoryzowac.´ Ze wzgledu˛ na stosowanie Kerberos baza danych haseł musi znajdowac´ sie˛ tylko w szczególnie zaufanych systemach (serwerach Kerberos). Inne systemy nie musza˛ miec´ do niej dostepu.˛ Oprócz tego za pomoca˛ Kerberos - Tickets mozna˙ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 152

implementowac´ Single Sign On, poniewaz˙ bilety wykorzystywane moga˛ byc´ w celu uzyskania dostepu˛ do wszystkich udostepnian˛ ych w sieci usług (o ile odpowiednie aplikacje obsługuja˛ Kerberos). Gdy tylko usługa katalogowa staje sie˛ w organizacji centralna˛ baza˛ danych informacji, staje sie˛ ona szczególnie wazn˙ ym składnikiem sieci, który musi gwarantowac´ bardzo wysoka˛ nieza- wodnosć.´ Dlatego usługi katalogowe obsługuja˛ z reguły procesy replikacji, za pomoca˛ których mozliwe˙ jest przenoszenie całego katalogu i zmian z jednego serwera swiadcz´ ace˛ go usługe˛ katalogowa˛ na inne. Dzieki˛ temu istnieje takze˙ mozliwo˙ sć´ rozkładania obcia˛zenia,˙ gdyz˙ nie wszystkie klienty musza˛ korzystac´ z tego samego serwera usługi katalogowej. Jesli´ chodzi o replikacje,˛ nalezy˙ rozrózni˙ c´ replikacje˛ Master - Slave oraz Multi - Master. W przypadku tej pierwszej zmiany moga˛ byc´ dokonywane tylko na jednym, centralnym Master - Server usługi katalogowej, który nastepnie˛ rozsyła zmiany do pozostałych (Slave - Server). W przypadku zmian zawartosci´ katalogu powstaje wówczas tak zwane waskie˛ gardło, poniewaz˙ mozna˙ je przeprowadzac´ tylko na centralnym serwerze. Jesli´ nastapi˛ jego awaria, wtedy zmiany sa˛niemozliwe˙ az˙ do chwili zmiany konfiguracji i udostepnienia˛ innego serwera jako Master albo ponownego uruchomienia starego Master - Server. Replikacja Multi - Master umozliwia˙ dokonywanie zmian w zawartosci´ usługi katalogowej na wielu serwerach, co rozwiazuje˛ powyzsze˙ problemy. Jednak w przypadku tej replikacji ujaw- niaja˛ sie˛ problemy ze spoistosci´ a˛ w momencie, gdy na rózn˙ ych serwerach przeprowadzane sa˛ sprzeczne ze soba˛ zmiany.

3.7.3 Active Directory Service (ADS)

Celem niniejszego rozdziału jest przedstawienie mozliwie˙ obszernego przegladu˛ technologii „Active Directory Service“. Dlatego opisalismy´ tu główne funkcjonalnosci:´

◦ Directory Service

◦ LDAP

◦ Kerberos

◦ wytyczne grup

◦ Delegation

◦ zarzadzanie˛ certyﬁkatami ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 153

Ponadto przedstawilismy:´

◦ zakres zastosowania

◦ architekture˛ oraz

◦ znaczenie strategiczne.

Innym celem jest wyjasnienie´ róznic˙ y pomiedzy˛ minimalnym a maksymalnym stosowaniem Ac- tive Directory.

3.7.3.1 Nastepca˛ usługi logowania stosowanej w Windows NT 4

Porównujac˛ Active Directory (AD) z usługami logowania z Windows NT, mozna˙ stwierdzic,´ ze˙ jest on ich nastepc˛ a.˛ Jest tak tym bardziej, ze˙ wywołanie installation routine z Windows 2000 na PDC z Windows NT prowadzi bezposrednio´ do utworzenia Active Directory. Jednak błedem˛ w tym miejscu by- łoby myslenie,´ ze˙ tworzenie Active Directory polega tylko na wywołaniu installation routine na pojedynczym serwerze. Aby utworzyc´ AD nalezy˙ miec´ porzadn˛ y pomysł i starannie zaplanowac´ migracje.˛ Podstawowa˛ technologia,˛ na której opieraja˛ sie usługi logowania w Active Directory jest, podobnie jak w Windows NT, jednos´c´ struktury domeny. Domena pozostaje jednostka˛ administracyjna,˛ która za pomoca˛ wspólnie wykorzystywanej bazy danych skupia konta komputerów i uzytko˙ wników we wspólnym kontekscie´ bezpieczenstwa.´ Granica domen jest granica˛ kontekstu bezpieczenstwa´ oraz granica˛ dla replikacji bazy danych uzytko˙ wników. Zachowana została przestrzen´ nazw NetBIOS. Ponadto, podobnie jak w Windows NT, komputery pracujace˛ w oparciu o:

◦ Windows NT

◦ Windows 2000

◦ Windows XP

moga˛ byc´ członkiem domeny. Jesli´ chcemy obsłuzy˙ c´ takie systemy, jak Windows NT i 9x, wówczas nadal musimy zagwarantowac´ bezbłedne˛ przekształcanie nazw NetBIOS (np. za pomoca˛ WINS). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 154

Charakterystyczne dla przeprowadzanej zmiany architektury jest implementacja Active Di- rectory. Wymaga ona infrastruktury DNS, która sprawia, ze˙ konieczny jest nie tylko wybór przestrzeni nazw, lecz takze˙ zastosowanie własciwe´ go serwera DNS. Oczywiscie´ pociaga˛ to za soba˛ dostosowanie istniejace˛ go srodo´ wiska sieciowego TCP / IP. Planowanie migracji oraz mozliwych˙ scenariuszy zostało opisane w jednym z kolejnych roz- działów.

3.7.3.2 Mechanizm autoryzacji Kerberos

W Windows 2000 Active Directory nadal obsługiwany jest mechanizm autoryzacji NTLM. Jest to konieczne chocby´ dla zapewnienia autoryzacji podczas logowania systemów takich jak Win- dows NT lub 9x. Nowosci´ a˛ jest autoryzacja via Kerberos. Systemy Windows 2000 albo XP domyslnie´ korzystaja˛ z Kerberos. Jednak w razie potrzeby mozna˙ je przełaczy˛ c´ takze˙ w tryb autoryzacji NTLM. Systemy takie, jak Windows NT lub 9x nie moga˛nawet po wykorzystaniu obcego oprogramowania wykorzystywac´ Kerberos. DCs Win- dows 2000 komunikuja˛ sie˛ poprzez Kerberos. W Windows 2000 zaimplementowano Kerberos w wersji 5 wraz z rozszerzeniami obsługu- jac˛ ymi autoryzacje˛ poprzez klucze publiczne (public key). Implementacja ta jest zgodna z RFCs 1510 i 1964. Kerberos Key Distribution Center (KDC) jest zintegrowany z kazdym˙ kontrolerem domeny Active Directory i uzywa˙ jego bazy danych uzytko˙ wników. Dla korzystania z Kerberos konieczne jest zachowanie mozliwie˙ niewielkich róznic˙ we wska- zaniach zegarów systemowych współpracujac˛ ych komputerów. W tym celu w Windows 2000 zaimplementowano automatyczna,˛ hierarchiczna˛ synchronizacje˛ czasu komputerów, które sa˛ członkiem tego samego AD. Autoryzacje˛ Kerberos nalezy˙ ocenic´ krytycznie, gdy uzywana˙ jest w sieci NAT (Network Address Translation), poniewaz˙ szyfrowane ładowanie pakietów IP zawiera adresy IP. Kerberos jest metoda˛ bardziej elastyczna˛ i wydajna˛ niz˙ NTLM. W przypadku NTLM, aby autoryzowac´ klienta, serwer aplikacji musiał zawsze łaczy˛ c´ sie˛ z kontrolerem domeny. Za pomoca˛ Kerberos serwer aplikacji moze˙ analizowac´ informacje o logowaniach prezentowane mu przez klienta. W NTLM serwery moga˛ identyfikowac´ klientów, natomiast Kerberos daje takze˙ klientom mozliwo˙ sć´ identyfikacji serwera (mutual authentication). Aby realizowac´ dostep˛ do za- sobów, usługi windowsowe musza˛ naslado´ wac´ klienta (impersonate). NTLM i Kerberos moga˛ dostarczac´ usłudze informacje, przez co moga˛ lokalnie naslado´ wac´ klienta. W przypadku aplikacji dzielonych z Frontend i Backend na rózn˙ ych komputerach, technologia NTLM zawodzi, podczas gdy Kerberos potrafi realizowac´ przezroczyste,´ dwukierunkowe zaufane połaczenia˛ po- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 155

miedzy˛ domenami. Protokół Kerberos składa sie˛ z trzech protokołów. Protokół, poprzez który centrum przydzielania kluczy (Key Distribution Center, KDC) przyznaje klientowi klucz logowania oraz TGT (Ticket Granting Ticket) nazywany jest usługa˛ autoryzacji (Authentication Service Exchange, AS Exchange). Drugi protokół, poprzez który KDC przyznaje klucz na czas trwania usługi oraz Ticket dla usługi nosi nazwe˛ usługi biletowej (Ticket Granting Service, TGS Exchange). Ostatni protokół, poprzez który klient przesyła Ticket do usługi w celu uzyskania dostepu˛ do niej, nazywa sie˛ usługa˛ Client / Server (CS Exchange).

3.7.3.3 Nowosci´ w strukturze

Jak juz˙ wspomnielismy´ , zachowana została jednos´c´ struktury domeny, takze˙ w Active Directory. W Active Directory domene˛ nalezy˙ traktowac,´ jako podstawe˛ całej struktury (forest) i nale- z˙ac˛ ych do niej struktur drzew (tree), które sa˛ hierarchicznie posegregowane w przestrzeni nazw DNS. Poszczególne domeny połaczone˛ sa˛ ze soba˛ poprzez tak zwane dwukierunkowe, przejrzyste Kerberos - Trusts (relacje zaufania). (Relacje zaufania via NTLM znane z Windows NT moga˛ byc´ nadal wykorzystywane.) Jesli´ jest mowa o Active Directory, wówczas chodzi zawsze o cała˛strukture,˛ a nie o pojedyncze drzewa albo domeny. Nastepuj˛ ac˛ y rysunek przedstawia strukture˛ domeny Windows NT, w której za pomoca˛relacji zaufania powiazane˛ sa˛ ze soba˛ dwie domeny kont i pie˛c´ domen zasobów. Microsoft prezentuje domeny Windows 2000 jako trójkaty˛ a domeny Windows NT jako elipsy. Niniejsza konwencja została zaadoptowana na potrzeby niniejszego poradnika. Otrzy- malismy´ zatem nastepuj˛ ac˛ y rysunek: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 156

Rysunek 3.7: Przykład struktury domen NT

Zgodnie z rys 3.7, w Active Directory do pomyslenia´ jest ogólna struktura, która równiez˙ obejmowałaby siedem domen: struktura ogólna obejmuje dwa drzewa o hierarchicznej strukturze domen, które powiazane˛ sa˛ze soba˛za pomoca˛Kerberos - przezroczy´ scie´ (A ufa B i B ufa C, wówczas A ufa takze˙ C) i dwukierunkowo (A ufa B, wówczas B ufa takze˙ A).

Rysunek 3.8: Przykład Windows 2000

Active Directory udostepnian˛ y jest przez kontrolery domen (DCs). Zanika rozróznienie˙ pomiedzy˛ PDC i BDC. Wynika to z nowej architektury, w której kontrolery domen Windows 2000 podporzadko˛ wane zostały zasadzie Multi - Master: wiekszo˛ s´c´ zmian w AD mozna˙ przeprowadzic´ (wpisac)´ na kazdym˙ DC. Zasada Multi - Master nie moze˙ dotyczyc´ wszystkich zmian. Dla- tego istnieja˛ specjalne kontrolery domeny, tak zwane FSMO - Owner (Flexible Single Master Operation). Chodzi tu o: ◦ emulator PDC ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 157

◦ Infrastructure Master

◦ RID Master

◦ Schema Master

◦ Domain Naming Master.

Funkcje te mozna˙ umieszczac´ na specjalnie wybranych kontrolerach domen. Funkcje:

◦ Schema Master (odpowiedzialny za schemat katalogu)

◦ Domain Naming Master (odpowiedzialny w przypadku zmian w przestrzeni nazw) pełnia˛ jednorazowe role wewnatrz˛ ogólnej struktury (forest). Funkcje:

◦ emulator PDC

◦ Infrastructure Master (odpowiedzialny za aktualizacje˛ SIDs oraz Distinguished Names poza granicami domen)

◦ RID Master (odpowiedzialny za przyznawanie RID Pools innym DCs)

sa˛ jednoznaczne w kazdej˙ domenie. Emulator PDC przejmuje wazne˙ funkcje takie jak:

◦ aktualizacja haseł dla Down - Level Clients (NT 4.0, 9x) oraz partnerów Windows NT Backup Domain Controller

◦ zródło´ czasu sieciowego (tylko PDC domeny podstawowej)

◦ usługa głównego wyszukiwania domen (NetBIOS)

Ogólna struktura moze˙ byc´ dodatkowo wzbogacana o punkty centralne (Sites). Miejsca te moga˛ (raczej powinny) byc´ odbiciem ﬁzycznej struktury sieci i łaczy˛ c´ sie˛ za pomoca˛ dostepn˛ ych szerokosci´ pasm z lokalizacjami (Hamburg, Berlin, Bonn, etc.). Głównym celem takiej struktury jest umozliwienie˙ sterowania replikacja˛ pomiedzy˛ kontrolerami domen. Standardowa˛ topologie˛ mozna˙ wybrac´ niezaleznie˙ od struktury domen. Ponizszy˙ rysunek przedstawia przykładowa˛ topologie.˛ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 158

Rysunek 3.9: Przykład struktury punktu centralnego domen oraz ich struktury

Inna˛nowosci´ a,˛ jesli´ chodzi o tworzenie struktury, jest tak zwana struktura OU (OU jest skró- tem od Organizational Unit, jednostka organizacyjna). Opisalismy´ ja˛w rozdziale przedstawiaja-˛ cym usługi katalogowe.

3.7.3.4 Przestrzen´ adresowa DNS i infrastruktura

Windows 2000 Active Directory Service bezwzglednie˛ potrzebuje infrastruktury DNS. Wymaga to udzielenia odpowiedzi na nastepuj˛ ace˛ pytania:

◦ Jaka˛ przestrzen´ nazw DNS powinien otrzymac´ AD?

◦ Jak przestrzen´ nazw powinna sie˛ wpisac´ w istniejac˛ a˛ przestrzen´ nazw DNS?

◦ Kto ma administrowac´ istniejac˛ a˛ przestrzenia˛ nazw?

◦ Na jakiej platformie (system operacyjny: Windows 2000, Unix) ma byc´ udostepnian˛ y DNS?

◦ Jakie odniesienie do przestrzeni nazw NetBIOS nalezy˙ uwzgledni˛ c?´

Znalezienie odpowiedzi na powyzsze˙ pytania jest czesto˛ szczególnie skomplikowane nie tylko ze wzgledu˛ na warunki techniczne, lecz równiez˙ wskutek tła „politycznego“. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 159

Wybór platformy Infrastruktura DNS dla AD wymaga pewnych cech, aby mozliwe˙ było bezproblemowe prze- kształcanie nazw i rejestracja wpisów. Zasadniczo Windows 2000 wraz ze swoja˛ implementacja˛ DNS posiada wszystkie niezbedne˛ własciwo´ sci.´ DNS z Windows 2000 ma m.in. nastepuj˛ ace˛ Features:

◦ Service Records (RFC 2052)

◦ dynamiczny DNS (RFC 2136)

◦ bezpieczny dynamiczny Update

◦ metode˛ Multi - Master wskutek integracji z Active Directory

◦ Integracje˛ WINS.

Konieczna jest obsługa RFC 2052, poniewaz˙ tylko tak mozna˙ dokonywac´ wpisów dla usług w DNS. RFC 2052 obsługiwany jest przez serwery uniksowe pocza˛wszy od BIND 8.1.2. BIND 8.2..1 obsługuje dalsze Features i jest wersja˛ zalecana.˛

Przestrzen´ nazw NetBIOS Jesli´ chodzi o przestrzen´ nazw NetBIOS, nalezy˙ wzia˛c´ pod uwage˛ nastepuj˛ ace˛ aspekty:

◦ Nazwa NetBIOS domeny Windows 2000 (np. RES1) moze˙ w zasadzie rózni˙ c´ sie˛ od naj- nizszej˙ nazwy suﬁksu DNS (jak, np. RES001 od res001.behoerde.de). Jednak odradzamy wybieranie nazw w taki sposób.

◦ Przestrzen´ nazw NetBIOS nie jest dowolna zwłaszcza wtedy, gdy trzeba zaktualizowac´ istniejace˛ domeny NT (patrz Inplace Migration).

Przestrzen´ nazw DNS Podczas formułowania ponizszych˙ ocen wyszlismy´ z załozenia,˙ ze˙ w istniejacej˛ infrastrukturze obecne jest juz˙ srodo´ wisko DNS, które udostepniane˛ jest w oparciu o serwer uniksowy. Jest to dos´c´ ogólny punkt wyjscia.´ Niech nazwa˛ domeny bedzie˛ tu „BEHOERDE.DE“, a istniejaca˛ przestrzen´ nazw BEHOERDE.DE niech bedzie˛ uzywana˙ tylko wewnetrznie.˛ Ponadto przyjeli˛ smy´ , ze˙ w infrastrukturze DNS istnieje wewnetrzna˛ domena Root („kropka“) bad˛ z´ strefa. Ponizszy˙ rysunek nakresla´ punkt wyjscia.´ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 160

Rysunek 3.10: Punkt wyjscia´

W kolejnych podrozdziałach opisalismy´ mozliwe˙ rozwiniecia˛ przestrzeni nazw pod katem˛ Windows 2000 Active Directory. Uwidoczniona tu została złozono˙ s´c´ migracji do ADS i wynikajace˛ z tego długoterminowe zwiazanie˛ sie˛ z ADS.

Domena Master: W2K.BEHOERDE.DE Istniejaca,˛ wewnetrzna˛ przestrzen´ nazw DNS wykorzystywana jest do przyjmowania kolejnych poddomen W2K (jako, ze˙ domena Master = pierwsza domena Active Directory). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 161

Rysunek 3.11: Domena Master: W2K.BEHOERDE.DE

Zaleta˛ powyzszej˙ domeny Master jest to, ze:˙

◦ nie jest tworzone nowe drzewo nazw

◦ zachowane sa˛ istniejace˛ serwery Root

◦ mozna˙ dowolnie wybrac´ platforme˛ usług DNS

◦ wewnetrzna˛ i zewnetrzna˛ przestrzen´ nazw pozostaja˛ oddzielne

Wada˛ takiego rozwiazania˛ jest to, ze:˙

◦ User Principal Name uzytko˙ wnika jest dos´c´ długa ([email protected]. de) bad˛ z´ zawiera 2nd Level Domain

◦ przy powiekszaniu˛ ogólnej struktury (np. dodaniu drzewa DNS ROZWINIECIE.DE)˛ jedno z drzew nie jest 2nd Level Domain (technicznie nie byłoby z tym problemu)

◦ cze˛s´c´ przekształcania nazw zalezy˙ w duzym˙ stopniu od dotychczasowej infrastruktury ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 162

Domena Master: BEHOERDE.DE Istniejaca˛ przestrzen´ nazw DNS wykorzystywana jest do okreslenia´ nazwy domeny Master.

Rysunek 3.12: Domena Master: BEHOERDE.DE

Zaleta˛ powyzszej˙ domeny Master jest to, ze:˙

◦ nie jest tworzone nowe drzewo nazw

◦ zachowane sa˛ istniejace˛ serwery Root

◦ User Principal Name uzytko˙ wnika jest dos´c´ krótka ([email protected])

◦ przy powiekszaniu˛ ogólnej struktury (np. dodaniu drzewa DNS ROZWINIECIE.DE)˛ obydwa drzewa sa˛ 2nd Level Domain

◦ wewnetrzna˛ i zewnetrzna˛ przestrzen´ nazw pozostaja˛ oddzielne

Wada˛ takiego rozwiazania˛ jest to, ze:˙

◦ nie mozna˙ wybrac´ platformy usług DNS

◦ przekształcanie nazw zalezy˙ wyłacznie˛ od dotychczasowej infrastruktury ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 163

Domena Master: NEU.DE Niniejsze rozwiniecie˛ jest niezalezne˙ od dotychczasowej przestrzeni nazw i tworzy nowe wewnetrzne˛ drzewo nazw DNS. Wybrana powyzej˙ nazwa NEU.DE jest jedyna na swiecie´ i oﬁcjal- nie zarejestrowana.

Rysunek 3.13: Domena Master: NEU.DE

Zaleta˛ powyzszej˙ domeny Master jest to, ze:˙

◦ tworzone jest nowe drzewo nazw, dzieki˛ czemu nie sa˛ przejmowane stare obcia˛zenia˙

◦ zachowane sa˛ istniejace˛ serwery Root

◦ mozna˙ wybrac´ platforme˛ usług DNS

◦ User Principal Name uzytko˙ wnika jest dos´c´ krótka ([email protected])

◦ przy powiekszaniu˛ ogólnej struktury (np. dodaniu drzewa DNS ROZWINIECIE.DE)˛ obydwa drzewa sa˛ 2ndLevel Domain

◦ przekształcanie nazw zalezy˙ w małym stopniu od dotychczasowej infrastruktury

◦ wewnetrzna˛ i zewnetrzna˛ przestrzen´ nazw pozostaja˛ oddzielne, odpowiednio do pózniej-´ szych wymagan´ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 164

Wada˛ powyzsze˙ go rozwiazania˛ jest to, ze:˙

◦ tworzone jest nowe drzewo nazw, co powoduje powstawanie nowych struktur i dodatkowych wytycznych

◦ rosnie´ stopien´ skomplikowania ustawien´ DNS oraz nakład pracy administracyjnej.

Master i structure domain: NEU.DE / INTRA.NEU.DE Powyzsze˙ rozwiniecie˛ jest niezalezne˙ od dotychczasowego drzewa nazw i tworzy nowe drzewo nazw DNS. Oprócz 2nd Level Domain NEU.DE tworzona jest dodatkowa poddomena. 2nd Level Domain NEU.DE słuzy˙ wyłacznie˛ jako master domain ogólnej struktury, jako tak zwana domena struktury. Ponizej˙ konta uzytko˙ wników zakładane sa˛ w poddomenie INTRA.

Rysunek 3.14: Domena Master i domena struktury: NEU.DE / INTRA.NEU.DE

Zaleta˛ powyzszej˙ structur domain jest to, ze:˙

◦ tworzone jest nowe drzewo nazw, dzieki˛ czemu nie sa˛ przejmowane stare obcia˛zenia˙

◦ zachowane sa˛ istniejace˛ serwery Root

◦ mozna˙ wybrac´ platforme˛ usług DNS ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 165

◦ przy powiekszaniu˛ ogólnej struktury (np. dodaniu drzewa DNS ROZWINIECIE.DE)˛ obydwa drzewa sa˛ 2nd Level Domain

◦ przy powiekszaniu˛ ilosci´ domen nowe domeny mozna˙ zakotwiczac´ równolegle z domena˛ INTRA.

◦ przekształcanie nazw zalezy˙ w małym stopniu od dotychczasowej infrastruktury

◦ wewnetrzna˛ i zewnetrzna˛ przestrzen´ nazw pozostaja˛oddzielne, odpowiednio do wymagan´ Wada˛ powyzsze˙ go rozwiazania˛ jest to, ze:˙ ◦ w Active Directory instalowane sa˛ dwie domeny

◦ tworzone jest nowe drzewo nazw, co powoduje koniecznos´c´ kontrolowania powstawania nowych struktur i dodatkowych wytycznych

◦ User Principal Name uzytko˙ wnika jest dos´c´ długa ([email protected])

◦ rosnie´ ilos´c´ krzyzo˙ wych połacze˛ n´ oraz stopien´ skomplikowania i nakład pracy administracyjnej.

Master domain: INTRA.BEHOERDE-ONLINE.DE Istniejaca˛ zewnetrzna˛ przestrzen´ nazw DNS wykorzystywana jest do przyjmowania kolejnych domen. Istniejaca˛ przestrzen´ nazw BEHOERDE - ONLINE.DE stosowana była dotychczas tylko zewnetrznie.˛ Nalezy˙ załozy˙ c´ domene˛ INTRA, która bedzie˛ uzywana˙ tylko wewnetrznie.˛ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 166

Rysunek 3.15: Domena Master: INTRA.BEHOERDE-ONLINE.DE

Zaleta˛ powyzszej˙ domeny Master jest to, ze:˙

◦ tworzone jest nowe drzewo nazw, dzieki˛ czemu nie sa˛ przejmowane stare obcia˛zenia˙

◦ zachowane sa˛ istniejace˛ serwery Root

◦ mozna˙ wybrac´ platforme˛ usług DNS

◦ przy powiekszaniu˛ ogólnej struktury (np. dodaniu drzewa DNS ROZWINIECIE.DE)˛ obydwa drzewa sa˛ 2nd Level Domain

◦ przekształcanie nazw zalezy˙ w duzym˙ stopniu od dotychczasowej infrastruktury

Wada˛ powyzsze˙ go rozwiazania˛ jest to, ze:˙

◦ User Principal Name uzytko˙ wnika jest dos´c´ długa ([email protected]. de)

◦ tworzone jest nowe drzewo nazw, co powoduje koniecznos´c´ kontrolowania powstawania nowych struktur i dodatkowych wytycznych

◦ rosnie´ ilos´c´ krzyzo˙ wych połacze˛ n´ oraz stopien´ skomplikowania i nakład pracy administracyjnej

◦ wewnetrzna˛ i zewnetrzna˛ przestrzen´ nazw nie sa˛ juz˙ od siebie niezalezne˙

Domena Master: AMT.LOCAL Niniejszy dodatek jest niezalezn˙ y od dotychczasowej przestrzeni nazw i tworzy nowe wewnetrzne˛ drzewo DNS. Wybrana Top Level Domain LOCAL nie jest obecnie obsługiwana w Internecie. Wybranej powyzej˙ nazwy nie mozna˙ zatem zarejestrowac.´ Zamiast LOCAL mogłaby równiez˙ zostac´ uzyta,˙ chroniona przez RFC 2606 nazwa domeny Top Level, której nigdy nie grozi to, ze˙ zostanie przejeta˛ przez społecznos´c´ internetowa˛ jako Top Level Domain. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 167

Rysunek 3.16: Master domain: AMT.LOCAL

Zaleta˛ powyzszej˙ master domain jest to, ze:˙

◦ tworzone jest nowe drzewo nazw, dzieki˛ czemu nie sa˛ przejmowane stare obcia˛zenia˙

◦ zachowane sa˛ istniejace˛ serwery Root

◦ mozna˙ wybrac´ platforme˛ usług DNS

◦ User Principal Name uzytko˙ wnika jest dos´c´ krótka ([email protected])

◦ przy powiekszaniu˛ ogólnej struktury (np. dodaniu drzewa DNS ROZWINIECIE.DE)˛ obydwa drzewa sa˛ 2nd Level Domain

◦ przekształcanie nazw zalezy˙ w małym stopniu od dotychczasowej infrastruktury

Wada˛ powyzsze˙ go rozwiazania˛ jest to, ze:˙

◦ tworzone jest nowe drzewo nazw, co powoduje koniecznos´c´ kontrolowania powstawania nowych struktur i dodatkowych wytycznych

◦ wewnetrzna˛ i zewnetrzna˛ przestrzen´ nazw zostaja˛ na stałe od siebie oddzielone

◦ rosnie´ ilos´c´ krzyzo˙ wych połacze˛ n´ oraz stopien´ skomplikowania i nakład pracy administracyjnej ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 168

Uwaga!

Wybór przestrzeni nazw DNS staje sie˛ bez porównania trudniejszy, gdy suwerenne administrowanie przestrzenia˛ nazw DNS wykracza poza własne, suwerenne uprawnienia. Czesto˛ w takiej sytuacji nalezy˙ podporzadko˛ wac´ własne zamierzenia nadrzednemu˛ interesowi, co moze˙ spowodowac´ widoczne wydłuzenie˙ sie˛ procesu decyzyjnego.

3.7.3.5 Usługa katalogowa i jej schemat

Wraz z Windows 2000 Active Directory wprowadzono usługe˛ katalogowa,˛ która opiera sie˛ na standardzie X. 500 i która˛ mozna˙ zarzadza˛ c´ poprzez LDAP (Lightweight Directory Access Pro- tocol). Usługa katalogowa wykorzystuje typ bazy danych, który pierwotnie stworzony został dla Mi- crosoft Exchange (Extensible Storage Engine). Zastapił˛ on architekture˛ bazy danych SAM. SAM jest jednak nadal dostepny˛ dla BDCs opartych na NT dopóki Active Directory nie zostanie przełaczony˛ w tak zwany „Native Mode“. W schemacie Active Directory zdefiniowanych jest około 142 klas obiektów (wraz z rozszerzeniami Exchange 2000, HIS oraz ISA: 419), z którym mozna˙ przyporzadko˛ wac´ do 863 atrybutów (wraz z E2K, HIS oraz ISA: 1928). Zasadniczo istnieje mozliwo˙ sć´ rozszerzania niniejszego schematu i przypisywania istnieja-˛ cym klasom nowych atrybutów. W Windows 2000 raz uruchomionych rozszerzen´ schematu nie mozna˙ juz˙ zmienic.´ Mozna˙ je jedynie dezaktywowac.´ Podział Active Directory, wzglednie˛ bazy danych nastepuje˛ w oparciu o jednosć´ struktury domeny. Zatem nie jest mozliwy˙ podział wewnatrz˛ domeny w sensie zdecentralizowanej bazy danych. Replikacja Active Directory bad˛ z´ bazy danych nastepuje˛ pomiedzy˛ kontrolerami domeny (DC). Odbywa sie˛ ona w oparciu o tak zwany Unique Sequence Number (USN), którym mozna˙ zarzadza˛ c´ az˙ do poziomu atrybutów. Dzieki˛ temu replikacja moze˙ byc´ realizowana na poziomie atrybutów. Jesli´ zatem zmienia˛ sie˛ własciwo´ sci´ obiektu, wówczas replikowana bedzie˛ jedynie zmieniona własciwo´ sć,´ a nie cały obiekt. Kazdy˙ DC w Active Directory udostepnia˛ usługe˛ LDAP. Obsługiwana jest LDAP w wersji 3. Za pomoca˛ klienta LDAP mozna˙ przeszukiwac´ i administrowac´ Active Directory. Dzieki˛ Di- stinguished Name istnieje mozliwo˙ sć´ kazdorazo˙ wego czytania i zapisywania obiektu. Ponizej˙ zamiescili´ smy´ przykładowa˛ scie´ zk˙ e:˛ LDAP.LDAP://dc001.behoerde.de/cn=Grzegorz Brzeczyszcz˛ ykiewicz, ou=komórka, ou=dział, dc=behoerde, dc=de. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 169

Nazwa dc001.behoerde.de oznacza, w nomenklaturze DNS, DC (a takze˙ serwer LDAP). Po- danie serwera LDAP jest opcjonalne w przypadku niektórych klientów LDAP, o ile obsługuja˛one tak zwany „serverless binding“. W zasadzie mozna˙ zastosowac´ dowolna˛ implementacje˛ LDAP, np. OpenLDAP bad˛ z´ interfejs programu, taki jak:

◦ ADSI (Active Directory Services Interface (zintegrowany w Windows 2000)

◦ LDIF (LDAP Data Interchange Format)

◦ i inne.

Korzystanie z powyzszych˙ interfejsów jest problematyczne, gdyz:˙

◦ pewne atrybuty albo obiekty sa˛ suwerennie zarzadzane˛ z Active Directory (np. atrybuty SID albo GUID),

◦ pewne atrybuty składaja˛ sie˛ z wartosci´ binarnych albo wartosci´ Hash, których algorytmy deszyfrujace˛ i szyfrujace˛ nie sa˛ znane (np. atrybut userParameters) i mozna˙ je modyﬁko- wac´ tylko spoza LDAP poprzez oddzielne interfejsy (np. Windows Terminal Server API).

◦ Korzystanie z graﬁcznego interfejsu uzytko˙ wnika (MMC) wywołuje oprócz czystego zapisywania atrybutów LDAP dodatkowe procesy (np. podczas okreslania´ katalogu Home jest on zakładany na serwerze plików wraz z odpowiednimi uprawnieniami).

3.7.3.6 ADS jako podstawa

Windows 2000 Active Directory jest niezbedn˛ y dla Exchange 2000. Exchange 2000 odpowiada za rozszerzanie obiektu uzytko˙ wnika i zapisywanie jego własnej konﬁguracji w AD. Nastepuj˛ ace˛ produkty Microsoft wykorzystuja˛ AD do zapisywania swojej konﬁguracji:

◦ Serwer HIS (Host Integration Server)

◦ Server ISA (Internet Security and Acceleration)

3.7.3.7 Narzedzia˛ administracyjne

Wersja serwera Windows 2000 dostarczana jest wraz z całym szeregiem graﬁcznych narzedzi˛ do zarzadzania˛ informacjami, kontami uzytko˙ wników i grup albo konﬁguracja˛DNS, składowanymi standardowo w Active Directory. Ponadto korzystac´ mozna˙ z narzedzi˛ znanych z Windows NT ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 170

działajac˛ ych pod konsola,˛ które umozliwiaj˙ a˛zakładanie, usuwanie i edycje˛ uzytko˙ wników i grup. Jednakze˙ narzedzia˛ te pozwalaja˛ tylko zarzadza˛ c´ cze˛sci´ a˛ informacji o kontach zapisanych w Active Directory. Oprócz tego dostepn˛ y jest konsolowy program ldifde umozliwiaj˙ ac˛ y uzyskiwanie wpisów w katalogach z pliku LDIF (LDAP Data Interchange Format). Łacznie˛ narzedzia˛ administracyjne dostarczane wraz z serwerem Windows 2000 skierowane sa˛ raczej do doswiadczon´ ych administratorów. Prawie nie nadaja˛ sie˛ one do tego, aby osoby słabiej wykształcone wykonywały z ich pomoca˛proste zadania administracyjne, takie jak zakła- danie albo zmiana kont uzytko˙ wników. Dzieki˛ ADSI (Active Directory Service Interface) istnieje interfejs oparty na COM, za pomoca˛ którego mozna˙ zautomatyzowac´ wiele zadan.´

3.7.3.8 Certyﬁkacja

Windows 2000 stworzył mozliwo˙ s´c´ tworzenia tak zwanych PKI (Public Key Infrastructure). Cer- tiﬁcation Authority (CA) mozna˙ zarówno zintegrowac´ w AD, jak i zainstalowac´ oddzielnie. Jesli´ wybrany zostanie wariant integracji w AD, wówczas w wewnetrznej˛ sieci bed˛ a˛ obsługiwane nastepuj˛ ace˛ technologie bezpieczenstwa,´ wzglednie˛ umozliwione˙ zostanie korzystanie z nich:

◦ EFS (Encrypted File System)

◦ IPsec

◦ SmartCard

◦ szyfrowanie i podpisy cyfrowe (e - mail)

◦ i inne.

Przydzielanie bad˛ z´ aktywacja PKI obsługiwane sa˛ przez wytyczne grup. Jednak nie oznacza to, ze˙ oddzielne rozwiazania˛ administracyjne dotyczace˛ zarzadzania˛ kluczami staja˛ sie˛ zbedne.˛

3.7.3.9 Smart Card

Wskutek zbudowania wewnetrzne˛ go PKI autoryzacja uzytko˙ wników moze˙ odbywac´ sie˛ poprzez SmartCard. Zgłoszenia via SmartCard do komputerów Windows 2000 / XP moga˛ byc´ realizowane bez stosowania dodatkowego oprogramowania. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 171

3.7.4 Migracja zastepuj˛ aca˛ - Samba i Open LDAP

3.7.4.1 Wymagania odnosnie´ funkcjonalnosci´

Centralne wymaganie, które ma spełniac´ usługa katalogowa polega na szybkim udostepnianiu˛ informacji w sieci. Ponadto powinna ona oferowac´ nastepuj˛ ace˛ funkcje:

◦ mozliwo˙ s´c´ zmiany informacji udostepnian˛ ych w katalogu

◦ mozliwo˙ s´c´ hierarchicznego uporzadko˛ wania obiektów w katalogu

◦ stosowanie zgodnych ze standardami i rozpowszechnionych schematów w celu zagwarantowania wysokiej kompatybilnosci´ za pomoca˛ mozliwie˙ wielu aplikacji. Mozliwo˙ s´c´ rozszerzania o własne obiekty i schematy.

◦ mozliwo˙ s´c´ autoryzacji uzytko˙ wników oraz integracja z innymi usługami autoryzacji (Ker- beros)

◦ administrowanie prawami dostepu˛

◦ stosowanie otwartych standardów w celu zwiekszenia˛ kompatybilnosci´ mozliwie˙ ze wszystkimi usługami i aplikacjami, które moga˛ korzystac´ z informacji zapisanych w katalogu

◦ obsługa procesu replikacji

◦ stosowanie bezpiecznych protokołów transmisji podczas przekazywania informacji pomie-˛ dzy klientem a usługa˛ katalogowa,˛ jak równiez˙ podczas replikacji.

3.7.4.2 Oceniane produkty

Jesli´ wymagane jest zastapienie˛ domeny Windows NT usługa˛ katalogowa˛ oparta˛ na Microsoft Windows albo Linuksie, wówczas w pierwszej linii nalezy˙ uwzgledni˛ c´ nastepuj˛ ace˛ produkty:

◦ Active Directory z serwerem Windows 2000 / 2003

◦ OpenLDAP i Samba (opcjonalnie z Kerberos) pod Linuksem

Inne usługi katalogowe, takie jak Novell Directory Services albo SunONE, nie sa˛tutaj oceniane, gdyz˙ wymagaja˛ one wprowadzenia dodatkowych produktów i przez to podnosza˛ stopien´ skomplikowania srodo´ wisk IT opartych na Windowsie bad˛ z´ Linuksie. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 172

3.7.4.3 Generalne porównanie zakresu funkcji udostepnianych˛ przez NTDS, Active Di- rectory i OpenLDAP

FUNKCJA WINNT WIN2K / LINUX / ADS OPENLDAP klient bez dodatkowego X X X oprogramowania mozliwo˙ sć´ budowania hierarchicznej X X struktury katalogu rozszerzalnosć´ o własne atrybuty X X i klasy obiektów zestaw znaków dla katalogowanych danych Unicode Unicode Unicode mozliwo˙ sć´ dostepu˛ do katalogu poprzez domysln´ y protokół (LDAP) X X mozliwo˙ sć´ bezpiecznego dostepu˛ poprzez X X LDAP z wykorzystaniem SSL / TLS obsługa protokołu „starttls“ X X obsługa SASL X autoryzacja klientów NT X X poprzez Samba24 poprzez Samba25 autoryzacja klientów linuksowych poprzez poprzez X winbind winbind albo LDAP mozliwo˙ sć´ zintegrowania Kerberos X26 X mozliwo˙ sć´ stosowania niezaleznej˙ / X27 X nadrzednej˛ usługi Kerberos zarzadzanie˛ prawami dostepu˛ (ACLs) X X dla atrybutów i obiektów

24W przypadku wykorzystywania Samby do autoryzacji klientów windowsowych w OpenLDAP, pomiedzy˛ klientem windowsowym a serwerem Samba stosowany jest protokół NT-LAN-Manager. 25W przypadku wykorzystywania Samby do autoryzacji klientów windowsowych w OpenLDAP, pomiedzy˛ klientem windowsowym a serwerem Samba stosowany jest protokół NT-LAN-Manager. 26Kerberos jest na stałe zintegrowany w Active Directory 27Active Directory zezwala na autoryzacje˛ na zewnetrzn˛ ym serwerze Kerberos, jednak wówczas nie mozna˙ wykorzystywac´ domen Active Directory do autoryzacji komputerów opartych o Windows 95 / 98 / Me / NT. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 173

przydzielanie zadan´ administracyjnych X X replikacja Master - Slave X X28 X replikacja Multi - Master X29 X30

Tablica 3.26: Porównanie usług katalogowych

3.7.4.4 Autoryzacja z wykorzystaniem Linuksa / OpenLDAP i Samby

Trudno jest oddzielic´ od siebie temat autoryzacji i usług katalogowych. Poniewaz˙ jednak usługa katalogowa moze˙ pełnic´ wiecej˛ zadan´ niz˙ autoryzacja, a autoryzacja jest usługa˛infrastrukturalna,˛ w rozdziale 3.4 „Autoryzacja“ ocenilismy´ z jednej strony autoryzacje˛ na gruncie Linuksa, Samby i OpenLDAP, a z drugiej strony takze˙ te˛ zwiazan˛ a˛ z Windows i ADS.

3.7.4.5 Centralne administrowanie informacjami o hostach z wykorzystaniem Linuksa i OpenLDAP

Dzieki˛ centralnemu zarzadzaniu˛ informacjami o hostach w katalogu mozliwe˙ staje sie˛ uproszczenie całego szeregu zadan´ administracyjnych. Nalez˙a˛ do nich:

◦ inwentaryzacja dostepne˛ go osprzetu˛

◦ tworzenie i zarzadzanie˛ wpisami nazw DNS

◦ tworzenie i zarzadzanie˛ konﬁguracjami DHCP

◦ dla klientów windowsowych mozna˙ zapisywac´ konta maszyn razem z w/w informacjami

Ponadto informacje te nie musza˛ byc´ przydzielane do komputerów recznie˛ lub w drodze innego postepo˛ wania, lecz moga˛ byc´ dystrybuowane do odpowiednich systemów za pomoca˛ replikacji LDAP. W Linuksie mozna˙ obecnie korzystac´ z całego szeregu programów umozliwiaj˙ ac˛ ych czytanie informacji o hostach bezposrednio´ z katalogu LDAP:

28Active Directory stosuje w „Mixed Mode“ replikacje˛ Maser - Slave pomiedzy˛ DC z Windows 2000 a BDC z Windows NT 4. 29Active Directory stosuje w „Native Mode“ (w którym uzywane˙ sa˛ wyłacznie˛ kontrolery domen oparte na Win- dows 2000 / 2003) replikacje˛ Multi - Master. 30replikacja Multi - Master w OpenLDAP jako eksperymentalna nie jest standardowo właczona˛ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 174

◦ dla standardowego serwera DHCP (ISC DHCPD) istnieje łata, dzieki˛ której mozliwe˙ jest czytanie konﬁguracji DHCP z katalogu LDAP.

◦ http://home.ntelos.net/~masneyb/dhcp-3.0.1rc11-ldap-patch

◦ dla BIND 9 istnieje równiez˙ łata umozliwiaj˙ aca˛ zastapienie˛ przez LDAP plików strefo- wych.

◦ http://www.venaas.no/dns/bind/bind-sdb/

◦ Samba potraﬁ pobierac´ informacje o kontach maszyn bezposrednio´ z katalogu LDAP.

Oprócz tego istnieje cały szereg własnoscio´ wych oraz wolnych programów umozliwiaj˙ ac˛ ych przezroczyste´ pobieranie z katalogu LDAP konﬁguracji serwerów BIND i DHCP.

3.7.4.6 Integracja innych aplikacji

Poza wykorzystywaniem usług katalogowych do centralnego zapisywania informacji o uzyt-˙ kownikach, grupach i hostach, dzieki˛ oferowanej przez nie dostepno˛ sci´ zwieksza˛ sie˛ mozliwo˙ s´c´ korzystania z wielu innych aplikacji. Zrezygnowalismy´ z przedstawienia w tym miejscu pełnej listy aplikacji kompatybilnych z LDAP. Wazna˙ jest jednak wskazówka, ze˙ coraz wiecej˛ aplikacji obsługuje LDAP, nie tylko programy pocztowe Microsoft Outlook i Outlook - Express albo pakiet biurowy OpenOfﬁce. Niniejsze programy moga˛ współpracowac´ zarówno z OpenLDAP, jak i z Active Directory jako usługa˛ katalogowej.

3.7.4.7 Narzedzia˛ administracyjne

Do zarzadzania˛ informacjami zapisanymi w katalogu dostepne˛ sa˛ w Linuksie z jednej strony standardowe narzedzia˛ LDAP (ldapsearch, ldapadd, ldapmodify). Nadaja˛sie˛ one przede wszystkim do zainicjowania katalogu, importu danych, szybkiego przeszukiwania zawartosci´ katalogu oraz do automatycznej edycji katalogu. Takze˙ do zarzadzania˛ uzytko˙ wnikami i grupami udostep-˛ nianych jest kilka konsolowych narzedzi.˛ Wolne, graﬁczne narzedzia˛ dla Linuksa słuz˙ace˛ do opartego na usłudze katalogowej zarza-˛ dzania uzytko˙ wnikami i grupami znajduja˛ sie˛ obecnie w fazie rozwoju (np. directory - administrator: http://diradmin.open-it.org/files.php). Równie wazne˙ sa˛ elastyczne narzedzia˛ WWW do zarzadzania˛ kontami uzytko˙ wników, grup oraz maszyn i innymi obiektami (mailing - lists, wpisy DNS, itd.) wewnatrz˛ usług katalogowych. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 175

Zaleta˛ tego typu rozwiaza˛ n´ jest to, ze˙ mozna˙ z nich korzystac´ z poziomu przegladarki˛ WWW, niezaleznie˙ od serwera, przy czym stosowana jest bezpieczna transmisja danych (SSL / TLS)31.

3.7.4.8 Zachowanie podczas pracy i zuzycie˙ zasobów

Linux i OpenLDAP okazały sie˛ byc´ stabilne oraz wystarczajaco˛ performant w srodo´ wiskach zło- zon˙ ych z ponad 10.000 uzytko˙ wników. W rózn˙ ych testach i duzych˙ instalacjach Samba okazała sie˛ byc´ bardzo pewna, stabilna i w porównaniu z serwerami windowsowymi zasobooszczedna.˛

3.7.4.9 Akceptacja uzytk˙ owników

Usługi katalogowe sa˛ z poczatku˛ niewidoczne dla uzytko˙ wnika konco´ wego i staja˛ sie˛ stopniowo widoczne wraz z przyłaczaniem˛ aplikacji do katalogu. Im wiecej˛ aplikacji korzysta z katalogu, tym wyzsze˙ jest prawdopodobienstwo,´ ze˙ uzytko˙ wnicy bed˛ a˛ spotykac´ spójne dane, co doprowadzi do wzrostu akceptacji. Migracja do Samby / OpenLDAP moze˙ byc´ przezroczysta´ dla uzytko˙ wników i klientów, co sprawi ze˙ nie zauwaz˙a˛ oni zmian wynikajac˛ ych z migracji. Administratorzy odniosa˛ korzysci´ z usługi katalogowej wskutek wprowadzenia administrowania Single Point. Z usługi katalogowej mozna˙ korzystac´ tym lepiej, im lepiej dostepne˛ narze-˛ dzia dopasowane sa˛ do proﬁlu wykształcenia i codziennych zadan´ administratora.

3.7.5 Migracja kontynuacyjna - Wprowadzenie do ADS

Migracja usług logowania z Windows NT 4 do Windows 2000 Active Directory wymaga z re- guły przygotowania oddzielnego rozwiazania˛ i praktycznych testów jeszcze zanim ostatecznie okreslona´ zostanie optymalna droga migracji. W celu przedstawienia obrazu przewidywanych nakładów oraz technicznych warunków kranco´ wych, w nastepuj˛ ac˛ ych rozdziałach wyjasnili´ smy´ pokrótce, jak moze˙ wyglada˛ c´ taka migracja.

3.7.5.1 Kolejnos´c´

Jesli´ chodzi o kolejnos´c,´ istnieje bardzo wiele wariantów migracji z Windows NT do Windows 2000. W zwiazku˛ z tym nie istnieje koniecznos´c´ integrowania najpierw usług logowania a nastepnie˛ klientów lub na odwrót. Nie jest takze˙ wymagane przestawianie wielu klientów Windows NT na zasadzie masowego rollaut. Jedyna˛ rzecza,˛ jaka˛ trzeba miec´ na uwadze jest sytuacja, gdy

31Przykładami sa˛ moduł Webmin (http://www.webmin.com/), idxldapaccounts (http://webmin. idealx.org/) oraz narzedzie˛ wymagajace˛ licencji univention_admin (http://www.univention.de/). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 176

przewiduje sie˛ aktualizacje˛ istniejacej˛ domeny NT (Inplace Upgrade). Wówczas nalezy˙ najpierw dokonac´ aktualizacji PDC tej domeny do Windows 2000. Active Directory rozróznia˙ dwa tryby pracy: Mixed Mode i Native Mode. Do Native Mode mozna˙ przełaczy˛ c´ sie˛ dopiero wówczas, gdy nie ma juz˙ potrzeby zasilania NT BDCs replika˛ SAM. Przełaczenia˛ do Native Mode nie mozna˙ cofna˛c´. Nalezy˙ pamieta˛ c´ o tym, ze˙ Native Mode jest wymagany w przypadku migracji z restrukturyzacja˛ (patrz „Wariant 2: aktualizacja plus restrukturyzacja“ w rozdziale 3.7.5.3). W planowaniu kolejnosci´ istnieje potencjał optymalizacyjny, który nalezy˙ wykorzystac´ odpowiednio do istniejace˛ go srodo´ wiska.

3.7.5.2 Docelowa architektura

Celem powinna byc´ struktura Active Directory z jedna˛ domena˛ bad˛ z´ mozliwie˙ mała˛ ilosci´ a˛ domen. Mała ilos´c´ domen zapewnia z reguły najmniejszy nakład pracy.

Rysunek 3.17: Migracja przez Upgrade albo restrukturyzacje˛

Odpowiada to zaleceniom projektowym ﬁrmy Microsoft, poniewaz˙ Microsoft, jesli´ chodzi o migracje˛ z NT do Windows 2000, przewidział juz˙ duz˙a˛ róznorodno˙ s´c´ dróg migracji oraz wiele mozliwo˙ sci´ restrukturyzacji.

3.7.5.3 Przeglad˛ wariantów migracji

Istnieja˛ nastepuj˛ ace˛ zasadniczo rózne˙ warianty migracji: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 177

◦ czysta aktualizacja (Upgrade): nalezy˙ zachowac´ dotychczasowa˛strukture˛ domen, co oznacza zaktualizowanie wszystkich domen.

◦ aktualizacja (Upgrade) plus restrukturyzacja: nalezy˙ zaktualizowac´ jedna˛ albo wiecej˛ domen. Pozostałe domeny NT nalezy˙ dostosowac´ do nowej struktury.

◦ nowa domena plus restrukturyzacja: domeny nie sa˛aktualizowane czy restrukturyzowane. Migracja (kopiowanie) dotyczy tylko zasobów (danych, drukarek, etc.).

Wariant 1: czysta aktualizacja Czysta aktualizacja (Inplace Upgrade wszystkich domen) oznaczac´ bedzie˛ zachowanie obecnej struktury domen. Mozliwa˙ jest pózniejsza´ restrukturyzacja (tak zwana restrukturyzacja Intra - Forest), jednak nie bez ryzyka (brak Fallback podczas przesuwania kont). Wariant 2: aktualizacja plus restrukturyzacja Aktualizacja lub migracja Inplace zawiera przeniesienie domeny kont do Windows 2000. Na- stepnie˛ odbywa sie˛ tak zwana restrukturyzacja Inter - Forest (oznacza odwzorowanie zasobów domen).

Rysunek 3.18: Migracja ADS – aktualizacja plus restrukturyzacja

Wariant 3: nowa domena plus restrukturyzacja Najpierw nalezy˙ załozy˙ c´ nowa˛ domene,˛ wzglednie˛ nowy AD. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 178

Rysunek 3.19: Migracja ADS - nowa domena plus restrukturyzacja

Konta uzytko˙ wników oraz globalne grupy domeny kont klonowane sa˛do nowej domeny (docelowej) (łacznie˛ z SID-History).

Rysunek 3.20: Migracja ADS - klony uzytko˙ wników i grup ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 179

Zaleta˛ powyzsze˙ go sposobu postepo˛ wania jest to, ze:˙

◦ migracja nie powoduje przerw w pracy uzytko˙ wników

◦ istnieje bardzo dobry Fallback

◦ mozna˙ odsuna˛c´ w czasie nowe przypisanie uprawnien´ (ReACLing); nie jest ono krytyczne, jesli´ chodzi o czas.

Wada˛ jest:

◦ koniecznos´c´ istnienia dodatkowego ADS wraz z osprzetem.˛

Wariant 4: swiat´ równoległy a migracja zasobów Najpierw nalezy˙ załozy˙ c´ nowa˛ domene,˛ wzglednie˛ nowy ADS.

Rysunek 3.21: Migracja ADS - swiat´ równoległy a migracja zasobów

Swiat´ równoległy wypełniany jest nowymi kontami uzytko˙ wników i nowymi grupami. Do- tychczasowe zasoby kopiowane sa˛ do nowego swiata.´ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 180

Rysunek 3.22: Migracja ADS - wypełnianie równoległego swiata´ kontami uzytko˙ wnika oraz grupami

Zaleta˛ powyzsze˙ go rozwiazania˛ jest to, ze:˙

◦ migracja na serwerach nie jest krytyczna, jesli´ chodzi o czas

◦ nie ma historii SID

◦ musza˛ byc´ znane prawa dostepu˛ i nalezy˙ je odwzorowac´ w nowym swiecie´

◦ migracja danych moze˙ oznaczac´ redukcje˛ danych.

Wada˛ jest to, ze:˙

◦ migracja danych wymaga duzych˙ nakładów logistycznych, jesli´ chodzi o wspólny dostep˛

◦ w czasie migracji danych trzeba dysponowac´ dodatkowym osprzetem˛ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 181

3.7.5.4 Zadania migracyjne

Migracja (zastapienie˛ NT) bad˛ z´ tez˙ całkowite wprowadzenie od nowa Windows 2000 Active Directory, wymaga starannego zaplanowania i oceny w srodo´ wiskach testowych. Podczas planowania migracji wymagane jest wykonanie nastepuj˛ ac˛ ych zadan:´

◦ prezentacja istniejacej˛ infrastruktury w formie pisemnej

◦ rozpoznanie wymagan´ zwiazan˛ ych z nowym srodo´ wiskiem

◦ rozpoznanie technicznych oraz organizacyjnych warunków brzegowych

◦ ocena obecnego srodo´ wiska

◦ stworzenie koncepcji przyszłej struktury ogólnej oraz struktury domen

◦ ustalenie przestrzeni nazw DNS oraz przestrzeni nazw NetBIOS

◦ ustalenie punktów centralnych i usytuowanie kontrolerów domeny

◦ stworzenie całoscio´ wej strategii nazw

◦ opracowanie sposobu przyłaczenia˛ do innych usług katalogowych

◦ stworzenie koncepcji struktury OU

◦ stworzenie rozwiazania˛ migracyjnego dla serwera logowania, zasobów, aplikacji i syste- mów stacji roboczych.

3.7.5.5 Active Directory pod katem˛ Windows 2003

Windows 2003 zachowuje zasadnicza˛architekture˛ Active Directory. Istnieje jednak kilka zmian, które wymienilismy´ ponizej:˙

◦ Oprócz dotychczasowych typów (schema, conﬁguration, domain) wprowadzony został dodatkowy typ partycji: Application Partition. Replikowanie tego typu nie jest wymagane wzgledem˛ wszystkich DCs domeny. Dzieki˛ temu mozliwe˙ jest tworzenie własnych partycji dla aplikacji innych producentów, na których mozna˙ składac´ wiecej˛ dynamicznych danych. Takie dynamiczne dane mozna˙ pózniej´ lepiej kontrolowac,´ jesli´ chodzi o proces replikacji. Własnie´ na takiej partycji nalezy˙ składowac´ dane DNS Active Directory zintegrowane w AD. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 182

◦ Przewiduje sie,˛ ze˙ Windows 2003 zaoferuje mozliwo˙ s´c´ tworzenia oddzielnych serwe- rów LDAP bez koniecznosci´ instalowania DC. Takie serwery LDAP (ADAM = Active Directory Application Mode) dysponuja˛ własnym schematem, jednak podporzadko˛ wuja˛ sie˛ usługom logowania AD. Tak wiec˛ powstaje mozliwo˙ s´c´ tworzenia dla aplikacji usług LDAP, bez koniecznosci´ zmian schematu AD.

3.7.5.6 Active Directory w minimalnej postaci

Jak juz˙ wspomnielismy´ , Active Directory oferuje łacznie˛ wiele technologii i funkcjonalnosci,´ które zasadniczo ułatwiaja˛ korzystanie z nowych funkcji i / albo efektywna˛ prace˛ w srodo´ wiskach IT. W takich przypadkach rosnie´ zalezno˙ s´c´ od produktów, wzglednie˛ technologii ﬁrmy Microsoft. Jesli´ nie chcemy, aby tak było, mozemy˙ wyznaczyc´ sobie cel, którym jest minimalne korzystanie z Windows 2000 Active Directory. Ponizej˙ opisalismy´ pokrótce, jak mogłaby wyglada˛ c´ taka konstelacja. Active Directory stosowany w minimalnym zakresie posiada nastepuj˛ ace˛ własciwo´ sci,´ wzgled-˛ nie prace˛ z nim nalezy˙ podporzadko˛ wac´ nastepuj˛ ac˛ ym krokom.

◦ Infrastruktura DNS powinna opierac´ sie˛ nie na Windows 2000, lecz na niezaleznej˙ implementacji, która odpowiada minimalnym wymaganiom. Ewentualnie konieczne bedzie˛ reczne˛ wprowadzanie SRV Records w DNS.

◦ Nalezy˙ zrezygnowac´ z jednej ogólnej struktury. Relacje zaufania pomiedzy˛ domenami nalezy˙ realizowac´ w tradycyjny sposób. Cel: by kazda˙ dotychczasowa domena Windows NT mogła zarzadza˛ c´ swoim własnym schematem we własnej ogólnej strukturze.

◦ Ponadto, jesli´ domeny nie bed˛ a˛pracowac´ w trybie „Native Mode“, wówczas zmniejszy sie˛ „niebezpieczenstwo“´ uzywania˙ zwiazan˛ ych z nim, rozszerzonych grup.

◦ Nalezy˙ takze˙ zrezygnowac´ z budowy struktury OU wewnatrz˛ domen. Cel: by poprzez utworzona˛ strukture˛ umozliwi˙ c´ działanie dodatkowych funkcji, tak aby móc sie˛ „jednak pózniej“´ do nich odwołac.´

◦ W „Default Domain Policy“ nalezy˙ ograniczyc´ stosowanie wytycznych grup do ustawien´ bezpieczenstwa´ (np. hasła (czas wazno˙ sci,´ minimalna długos´c,´ etc.), ustawien´ kontrolnych (Auditing)). Jest to konieczne do adekwatnego zastapienia˛ ustawien´ Windows NT. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 183

◦ Zasadniczo nalezy˙ zrezygnowac´ ze stosowania PKI (Public Key Infrastructure) opartych na AD, która byłaby wymagana, np. dla EFS albo IPsec.

◦ Nalezy˙ zastosowac´ DFS (Distributed File System) oparty na AD Cel: by unikna˛c´ dodatkowych zalezno˙ sci´ powstajac˛ ych w AD wskutek zintegrowanego zapisu.

◦ O ile nie jest wykorzystywany Exchange 2000, nie nalezy˙ uzywa˙ c´ dodatkowych atrybutów obiektów uzytko˙ wnika. Nalezy˙ ograniczyc´ sie˛ do stosowania obligatoryjnych atrybutów. Cel: by AD nie był stosowany jako miejsce zapisu danych osobowych, dzieki˛ czemu zredu- kuje sie˛ mozliwo˙ s´c´ powstawania dalszych zalezno˙ sci´ (np. aplikacje innych producentów, które wysyłaja˛ zapytania o te dane przez LDAP).

◦ Nie nalezy˙ uzywa˙ c´ obiektów kontaktowych w AD. Cel: wskutek nagromadzenia tego typu informacji w AD, zwieksza˛ sie˛ uzaleznienie.˙

◦ Nie nalezy˙ publikowac´ drukarek lub zasobów w Active Directory. Cel: by uzytko˙ wnicy nie przyzwyczaili sie˛ do odnajdywania zasobów w ten sposób. Wskazówka: Wymienione własciwo´ sci´ / kroki z reguły przeszkadzaja˛ w osiagni˛ eciu˛ maksy- malnej wydajnosci,´ która˛ mozna˙ uzyskac´ za pomoca˛ Active Directory. Jest to cena zwiekszonej˛ niezalezno˙ sci.´ W przeciwienstwie´ do tego sensowne jest stosowanie punktów centralnych wewnatrz˛ ADS w celu sterowania procesem replikacji pomiedzy˛ poszczególnymi lokacjami. W przypadku korzystania z Exchange 2000, który ma pracowac´ poza zakresem domen w jednej organizacji Exchange, nie nalezy˙ obchodzic´ uzycia˙ jednej ogólnej struktury, gdyz˙ w przeciwnym razie zabraknie funkcji katalogu globalnego.

3.8 Middleware - COM, .NET, J2EE

Z technicznej oceny wyraznie´ wynika, ze˙ dotychczasowa technologia składników (COM, DCOM) ﬁrmy Microsoft jest wprawdzie nadal stosowana, lecz jednoczesnie´ ma miejsce zmiana technologii zwiazana˛ z wprowadzaniem .NET-Framework. Alternatywna˛ platforma˛ wspomnianej, nowej technologii moze˙ byc´ Java 2 Enterprise Edition (J2EE). Zasadniczymi róznicami˙ pomiedzy˛ tymi dwiema technologiami, które odgrywaja˛ główne role, jesli´ chodzi o oceniane w dalszej cze˛sci´ Web - Services, sa:˛ uzaleznienie˙ od danej platformy, obsługiwane jezyki˛ programowania i ilos´c´ dostawców rozwiaza˛ n.´ Nastepuj˛ aca˛ tabela wskazuje dalsze róznice.˙ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 184

PARAMETRY J2EE .NET ogólnie standard przemysłowy produkt-suite jeden jezyk˛ - wiele jezyków˛ - wielu dostawców jeden dostawca jezyki˛ Java C#, VB, C++, J#, Java i inne . . . model Enterprise JavaBeans .NET (Web) Services; składników COM+ interpreter JRE (Java TM CLR (Common Runtime Environment) Language Runtime) dostawcy BEA, IBM, SUN, Oracle . . . Microsoft system Unix, Windows, Linux, Windows operacyjny OS / 390 . . . przegladarka˛ WWW dowolny, z Java Support dowolny serwer WWW dowolny MS IIS składniki serwera WWW JSP, Servlets ASP.NET dostep˛ do bazy danych JDBC ADO.NET usługa katalogowa dowolny, poprzez JNDI Active Directory

Tablica 3.28: Porównanie J2EE i .NET

3.8.1 Component Object Model (COM)

Podstawa˛wielu technologii stworzonych przez Microsoft jest Component Object Model (COM). Porównywalnymi, zorientowanymi składnikowo technologiami sa˛ CORBA (Common Object Request Broker Architecture) zaprojektowana przez Object Management Group albo Java Be- ans ﬁrmy SUN. COM jest kontynuacja˛ OLE (Object Linking and Embedding), który słuzył˙ w pierwszym rzedzie˛ do tworzenia Compound Documents. COM jest standardem binarnym dla składników i dlatego jest niezalezn˙ y od jezyków˛ programowania. Składniki COM mozna˙ tworzyc´ za pomoca˛ rózn˙ ych jezyków˛ programowania, do których nalez˙a˛ m.in.:

◦ C++ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 185

◦ C

◦ Java

◦ Visual Basic

◦ Delphi.

Jednoczesnie´ w przypadku niektórych z w/w jezyków˛ składniki COM moga˛ byc´ nawet ponownie uzywane.˙ Jedynym wymaganiem wzgledem˛ jezyka˛ programowania jest to, zeby˙ mogły byc´ realizowane struktury instrukcji i by mozliwe˙ było zewnetrzne˛ bad˛ z´ wewnetrzne˛ wywoływanie funkcji za pomoca˛ instrukcji. Jezyki˛ zorientowane obiektowo dostarczaja˛ mechanizmów, które ułatwiaja˛ implementacje˛ składników COM. Najczestsz˛ a˛ forma,˛ w jakiej wystepuj˛ a˛ składniki COM, sa˛ pliki *.dll. Innymi wariantami sa:˛

◦ Dynamic Linking Libraries (*.DLL, *.OCX)

◦ wykonywalne pliki Windows (*.EXE)

◦ klasy Java (*.CLASS)

◦ pliki skryptowe (*.SCT, *.WSC).

Jesli´ chodzi o protokoły transportu, COM oferuje, dzieki˛ usłudze Distributed COM (DCOM), neutralne Middleware umozliwiaj˙ ace˛ korzystanie z odległych składników na innych komputerach. DCOM nalezy˙ do standardu Windows NT. Wywołanie składników na odległych komputerach opiera sie˛ przy tym na Remote Procedure Calls (RPC). Osadzone jest tym samym w warstwie 7 ISO / OSI (Application Layer) i moze˙ w teorii działac´ na rózn˙ ych protokołach transportu (np. TCP / IP, IPX / SPX), a takze˙ na HTTP. Korzystanie z HTTP mozliwe˙ jest za pomoca˛ COM Internet Services (CIS) z IIS w wersji 4, w którym protokół DCOM tunelowany jest przez HTTP. Bezpieczenstwem´ DCOM mozna˙ zarzadza˛ c´ stosujac˛ DCOM Conﬁguration Utility (DCOMCNFG.exe). Narzedzie˛ to słuzy˙ w szczególnosci´ do ustalenia, który wymiar imperso- niﬁkacji nalezy˙ zastosowac,´ czyli do ustalenia zdolnosci´ software routine do zmiany kontekstu uzytko˙ wnika. Stosowanie składników COM mozliwe˙ jest tylko w Windows. Aplikacje, które z nich korzystaja,˛ trzeba dostosowywac´ do przeportowania na inna˛ platforme.˛ Rozszerzeniem COM i DCOM w Windows 2000 jest COM+. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 186

3.8.2 „.NET”

Na poczatku˛ trzeba wyjasni´ c´ kilka centralnych poje˛c´ co rusz wystepuj˛ ac˛ ych w zwiazku˛ z „.NET“. W tym celu przedstawilismy´ ponizej˙ deﬁnicje sformułowane przez Microsoft na stronie http: //www.microsoft.com/germany/themen/net/glossar.htm:

.NET: platforma Microsoft dla XML - Web Services, która łaczy˛ ze soba˛informacje, urza-˛ dzenia i uzytko˙ wników w jeden jednolity i spersonalizowany sposób.

.NET Framework: srodo´ wisko do rozwoju, udostepniania˛ i wykonywania XML - Web Services i innych aplikacji. Składa sie˛ z dwóch głównych składników:

◦ Common Language Runtime

◦ bibliotek klas, jak ASP.NET, ADO.NET i Windows Forms.

.NET My Services: Architektura zorientowana na uzytko˙ wnika i zbiór usług XML, które ułatwiaja˛ integracje˛ izolowanych „wysp plików“. .NET My Services zorientowane sa˛ na uzyt-˙ kownika a nie na okreslone´ urzadzenie,˛ siec´ albo aplikacje.˛

Platforma .NET: składa sie˛ z narzedzi,˛ urzadze˛ n,´ XML - Web Services oraz doswiadcze´ n´ serwera i uzytko˙ wników W dalszej cze˛sci´ dokonalismy´ w pierwszym rzedzie˛ blizszej˙ oceny technologii .NET - Fra- mework, jako rozwiazania˛ Middleware. Jest ono w pewien sposób zblizone˙ do Java Virtual Ma- chine (JVM), poniewaz˙ poprzez instalacje˛ Frameworks (np. w Windows 2000) abstrahuje sie˛ od interfejsów integralnych cze˛sci´ składowych systemu operacyjnego (np. API Win32) i sa˛ one oferowane w na nowo uporzadko˛ wanej formie. Ma to w pierwszym rzedzie˛ wpływ na rozwój aplikacji. Nastepuj˛ ac˛ y rysunek pokazuje składniki Frameworks. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 187

Rysunek 3.23: Składniki .Net-Frameworks

Aplikacje pisane sa˛ w jezyku˛ obsługujac˛ ym „.NET“ i moga˛ odwoływac´ sie˛ do obszernych bibliotek klas „.NET“. „.NET“ Framework obsługuje duz˙a˛ ilos´c´ jezyków˛ programowania. Kaz-˙ dorazowy kompilator tłumaczy kod zródło´ wy na kod wykonywalny (a nie kod maszynowy), który okreslan´ y jest mianem Intermediate Language (IL). Wynikiem niniejszej akcji jest, np. plik EXE. Jesli´ taki plik zostanie załadowany, wówczas jest on przekształcany za pomoca˛ swojego kompilatora JIT (Just - In - Time) z Common Language Runtime (CLR) do kodu maszynowego. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 188

Do tworzenia kodu zródło´ wego Microsoft oferuje:

◦ z jednej strony bezpłatny Software Developer Kit (SDK), który wystarczy juz˙ do tworzenia programów „.NET“.

◦ z drugiej strony Visual Studio .NET, nastepc˛ e˛ dotychczasowego Visual Studio Version 6.

.NET - Framework moze˙ byc´ uzywan˙ y, w przeciwienstwie´ do Java i JVM, tylko dla systemów operacyjnych Microsoft.

3.8.3 Java 2 Enterprise Edition (J2EE)

Java 2 Enterprise Edition obejmuje wiele usług Middleware, które ułatwiaja˛ rozwijanie aplikacji pracujac˛ ych po stronie serwera. Wazn˙ ymi cze˛sciami´ składowymi technologii J2EE sa:˛

◦ Enterprise JavaBeans (EJB) Enterprise - Beans sa˛ składnikami po stronie serwera, które implementuja˛ logiczna˛ strukture˛ aplikacji. Moga˛ sie˛ do nich odwoływac´ klienty. Enterprise - Beans instalowane sa˛ po stronie serwera w EJB - Container. Pojemnik udostepnia˛ im okreslone´ usługi oraz srodo-´ wiska runtime.

◦ Java Naming and Directory Interface (JNDI) Chodzi tu o usługe˛ nazw i usługe˛ katalogowa,˛ która z jednej strony stwarza mozliwo˙ s´c´ odkładania referencji do odległych obiektów – pod okreslon´ a˛ nazwa˛ oraz – w zdeﬁniowanym miejscu (Binding). Z drugiej strony dzieki˛ JNDI mozliwe˙ jest odnajdywanie powiazan˛ ych obiektów poprzez ich nazwy (Lookup).

◦ Java IDL / CORBA Java IDL tworzy interfejs do CORBA, za pomoca˛ Java IDL mozna˙ implementowac´ Java - ORBs.

◦ Java Remote Method Invocation (RMI) i RMI via IIOP (RMI - IIOP) RMI stosowana jest dla dzielonej komunikacji pomiedzy˛ obiektami. Dzieki˛ RMI - IIOP, J2EE jest kompatybilna z CORBA.

Oprócz tego istnieja˛ jeszcze nastepuj˛ ace˛ usługi: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 189

◦ Java Database Connection (JDBC)

◦ Java Message Service (JMS)

◦ Java Servlets / Java Server Pages (JSP)

◦ Java Transaction API (JTA)

◦ Java API for XML (JAXP)

◦ i inne.

Rysunek 3.24 przedstawia model warstwowy J2EE.

Rysunek 3.24: Model warstwowy J2EE

3.9 Web Services

3.9.1 Przeglad˛

Za pomoca˛ technologii Web Services mozna˙ integrowac´ rózne˙ platformy i aplikacje niezaleznie˙ od producenta, w oparciu o standardy. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 190

Zarówno .NET-Framework, jak i J2EE udostepniaj˛ a˛ zintegrowana˛ platforme˛ do rozwoju i wykorzystywania Web-Services. J2EE i .NET nadaja˛ sie˛ do tworzenia aplikacji w jednakowym stopniu. Ich innymi cechami wspólnymi sa:˛

◦ architektura 3-tier

◦ zorientowanie na składniki, optymalizacja dla dzielonych architektur

◦ zorientowanie na siec´

◦ Internet jako centralna infrastruktura

◦ przegladarka˛ WWW, jako nadrzedn˛ y User Interface, „Rich Clients“ jako podrzedn˛ y User Interface.

Róznice˙ pomiedzy˛ obydwiema platformami zostały pokazane juz˙ podczas oceny .NET - Frame- works. Z powodu wyzszej˙ elastycznosci,´ jak tez˙ niezalezno˙ sci´ od producenta czy platformy, nalezy˙ uznac´ pierwszenstwo´ J2EE, co pokrywa sie˛ takze˙ z zaleceniami SAGA32. Jak jednak wyglada˛ kompatybilnosć´ pomiedzy˛ .NET i J2EE? Jesli´ chodzi o Web - Services zachodzi ona, o ile wszyscy przestrzegaja˛ standardów (XML, SOAP, WSDL, UDDI). Jedyna˛ problematyczna˛ rzecza˛ jest wówczas tylko to, ze˙ SOAP w aktualnej wersji 1.1 zezwala jeszcze na bardzo duz˙a˛ dowolnosć,´ co moze˙ prowadzic´ do praktycznej utraty kompatybilnosci.´ Jednak celem Web - Services musi byc´ kompatybilnosć.´ Ma byc´ ona szczególnie zagwarantowana przez SOAP w wersji 1.2.

3.9.2 Podstawy

Web Service to usługa, do której moze˙ odwołac´ sie˛ klient poprzez Internet za pomoca˛ Uniform Resource Locator (URL). Decydujac˛ a˛ rzecza˛ jest przy tym, aby implementacja tej usługi była dla klienta całkowicie przezroczysta.´ Web Service jest „czarna˛ skrzynka“,˛ która˛ mozna˙ postrzegac´ jako okreslon´ a˛ funkcjonalnos´c´ i której mozna˙ uzywa˙ c´ w sposób elastyczny bez znajomosci´ szczegółów implementacji. Web Services udostepniaj˛ a˛ swoje funkcjonalnosci´ swiatu´ zewnetrz-˛ nemu za posrednictwem´ dobrze zdeﬁniowanych interfejsów. Interfejsy te nazywane sa˛takze˙ Web

32Standardy i architektury dla aplikacji e-Government, wersja 1.1, dokumenty KBSt, ISSN 0179-7263, tom 56, luty 2003, http://www.kbst.bund.de/saga. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 191

Service Contract. Contract taki opisany jest za pomoca˛ specjalnie w tym celu zaprojektowanego jezyka,˛ tj. WebService Description Language (WSDL) (chodzi tu o plik XML). Programisci´ moga˛ na tej podstawie łaczy˛ c´ ze soba˛ najrózniejsze˙ usługi i integrowac´ je w jedna˛ kompletna˛ aplikacje.˛ Wyszukiwanie takiej usługi moze˙ odbywac´ sie˛ za pomoca˛ UDDI (Universal Descrip- tion Discovery and Integration). UDDI jest specyfikacja˛ oparta˛ na standardach, słuz˙ac˛ a˛do opisu i wyszukiwania Web Services, a zatem jest ona repozytorium Web Services. W tak zwanym miedzyczasie˛ firmy IBM, Microsoft i inni producenci stworzyli pierwsze implementacje. W przeciwienstwie´ do aktualnych obecnie technologii opartych na składnikach, Web Se- rvices nie wykorzystuja˛ protokołów „specyficznych dla obiektu“, takich jak DCOM, IIOP albo RMI, poniewaz˙ z reguły wymagaja˛one do płynnej pracy korzystania z homogenicznej infrastruktury, jesli´ chodzi o klienta i serwer. Dlatego Web Services działaja˛na innej zasadzie. Opieraja˛sie˛ one na standardach internetowych i wykorzystuja˛ „najmniejszy wspólny mianownik“: HTTP i XML (patrz rozdział 3.10). Za pomoca˛HTML klient wysyła wiadomosć´ opakowana˛w XML do serwera, który odpowiada na zapytanie równiez˙ wiadomosci´ a˛ XML. W ten sposób Web Servi- ces sa˛ całkowicie niezalezne˙ od okreslon´ ych jezyków˛ programowania i platform systemowych. Dopóki obydwie strony bed˛ a˛ uzywały˙ jednolitego formatu wiadomosci´ i bed˛ a˛ sie˛ stosowac´ do wspólnie zdefiniowanej kolejnosci´ wywołan,´ rodzaj implementacji usługi (Web Services) bedzie˛ rzecza˛drugoplanowa.˛ Moze˙ on wyczerpac´ wszelkie mozliwo˙ sci´ platformy, na której jest własnie´ uzywan˙ y. Uogólnieniem powyzszej˙ zasady jest SOAP. Simple Object Access Protokoll definiuje to, w jaki sposób musza˛byc´ zbudowane wiadomosci´ XML i jak musi wyglada˛ c´ kolejnosć´ wywo- łan.´ Dzieki˛ temu najrózniejsze˙ aplikacje, które pracuja˛ na rózn˙ ych platformach, mozna˙ ze soba˛ łaczy˛ c´ i integrowac´ z istniejac˛ ymi rozwiazaniami.˛ Jedynym wymogiem jest to, zeby˙ aplikacje te komunikowały sie˛ ze soba˛poprzez SOAP. Sam SOAP moze˙ nakładac´ sie˛ na rózne˙ protokoły (np. HTTP, SMTP). SOAP jest prostym, nieskomplikowanym mechanizmem słuz˙ac˛ ym do wymiany ustrukturyzowanych i wytypowanych informacji pomiedzy˛ systemami w zdecentralizowanym, dzielonym srodo´ wisku za pomoca˛ XML. SOAP ma jednak wade˛ polegajac˛ a˛ na tym, ze˙ jest dosć´ wolny. Składa sie˛ on z trzech cze˛sci.´ Okładka SOAP (envelope) definiuje Framework dla kazdej˙ wiadomosci.´ Komunikuje ona odbiorcy, jaka˛ tresć´ zawiera wiadomosć,´ do kogo wiadomosć´ jest skierowana i czy chodzi o wiadomosć´ opcjonalna,˛ czy obligatoryjna.˛ Istnieja˛ zasady kodowania; wewnatrz˛ SOAP - Frameworks zasady kodowania okreslaj´ a˛ sposób kodowania danych (np. liczb). XML wykazuje sie˛ zasadami kodowania, które odznaczaja˛sie˛ duz˙a˛elastycznosci´ a.˛ SOAP nie jest tak elastyczny, poniewaz˙ definiowany tu jest ograniczony szereg zasad, co jednak nie ma znaczenia. Za pomoca˛ Web Services mozliwa˙ staje sie˛ realizacja integracji rózn˙ ych platform i aplikacji ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 192

niezaleznie˙ od producentów, w oparciu o standardy. Obydwie technologie, tj. .NET-Framework oraz J2EE udostepniaj˛ a˛ zintegrowana˛ platforme˛ do rozwoju i korzystania z Web - Services.

3.9.3 .Net Web-Services

.NET-Framework (patrz rozdział 3.8.2) obsługuje rozwój profesjonalnych Web Services. Chodzi przy tym przewaznie˙ o nowe wydanie Windows DNA (Distributed interNet Applications Archi- tecture). .NET zawiera własny Service Layer dla Web Services. Ponizszy˙ rysunek (rysunek 3.25) pokazuje zwiazki˛ poszczególnych cze˛sci´ składowych pod katem˛ Web Services.

Rysunek 3.25: Microsoft .NET- Framework ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 193

Przez wprowadzenie technologii ASP.NET, nastepczyni˛ Active Server Pager, zrealizowano nastepuj˛ ace˛ cele:

◦ uzyskano mozliwie˙ proste i zmienne srodo´ wisko programowania

oraz

◦ omawiane Web Services.

Z drugiej strony Visual Studio .NET oferuje mozliwo˙ s´c´ pisania w wzglednie˛ prosty sposób aplikacji (klienckich), które korzystaja˛ z Web Services w oparciu o XML i SOAP. Rdzeniem Web-Services w Windows jest Internet Information Server (IIS) (patrz rozdział 3.11).

3.9.4 J2EE

Architektura J2EE (patrz rozdział 3.8.3) opiera sie˛ na jezyku˛ programowania Java. Jego zaleta˛ jest to, ze˙ programów w nim napisanych mozna˙ uzywa˙ c´ niezaleznie˙ od platformy. Pierwotnie J2EE była architektura˛rozwijana˛dla aplikacji pracujac˛ ych po stronie serwera. Pózniej´ platforma została rozszerzona o obsługa˛ Web Services opartych na XML. Logiczna warstwa biznesowa, która realizowana jest za pomoca˛ składników EJB (Enterprise Java Beans), zawiera procesy biznesowe oraz logike˛ danych. Tworzy ona połaczenie˛ z bazami danych za posrednictwem´ JDBC (Java Database Connectivity) i moze˙ równiez˙ korzystac´ z zewnetrzn˛ ych Web Services. Dostep˛ do aplikacji J2EE mozliwy˙ jest z jednej strony dzieki˛ wykorzystaniu technologii Web Service, przy czym zapytania Web Service edytowane sa˛ przez Servlets. Z drugiej strony niegdysiejsze klienty, tj. aplety albo aplikacje, równolegle do tego, tradycyjnie korzystaja˛z bezposrednie´ go dostepu˛ do składników EJB. Web Browser oraz urzadzenia˛ bezprzewodowe zwiazane˛ sa˛ ze składnikami EJB zazwyczaj poprzez Java Server Pages (JSP). Srodo´ wiska programowania oferowane sa˛ przez rózn˙ ych producentów, takich jak, np. IBM, SUN i BEA.

3.10 XML (Extensible Markup Language)

XML uznawany jest za nowe, uniwersalne rozwiazanie˛ prezentowania danych oraz format wymiany danych. XML nie jest formatem binarnym, lecz zapisywany jest w formie dajace˛ go sie˛ drukowac´ łancucha´ znaków. W porównaniu z HTML (Hypertext Markup Language) XML posiada nastepuj˛ ace˛ zalety: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 194

◦ XML oddziela strukture˛ dokumentu od warstwy prezentacji. XML nie uzywa˙ polecen´ formatowania. Formatowanie musi byc´ zdeﬁniowane poprzez Style Sheet.

◦ w XML istnieje mozliwo˙ s´c´ zdeﬁniowania dowolnych struktur za pomoca˛ własnych ele- mentów i atrybutów.

◦ za pomoca˛parsera XML istnieje mozliwo˙ s´c´ sprawdzania struktury pod katem˛ jej wazno˙ sci´ w oparciu o deﬁnicje˛ struktury.

XML oczekuje tak zwanego „wellformedness“ (własciwe´ go formułowania) osadzonego w regu- łach, np. „nazwy elementów rozrózniaj˙ a˛ pisownie˛ wielka˛ i mała˛ litera“.˛ Dokumenty XML zawieraja˛szczególne elementy, tj. Processing Instructions (PIs), w których mozna˙ zapisywac´ instrukcje dla parsera XML (np. style sheets). Poprzez definicje struktury ustalane sa˛ obowiazuj˛ ace˛ struktury dokumentów XML. Nazy- wane sa˛one takze˙ Vokabular. Definicje struktury moga˛byc´ tworzone za pomoca˛Document Type Definition (DTD) albo schematów XML. Aby jednoznacznie zdefiniowac´ nazwy elementów, mozna˙ zdefiniowac´ przestrzen´ nazw jako XML - Namespace. XSL (Extensible Style Sheet Language) jest jezykiem˛ opartym na XML, słuz˙ac˛ ym do konwersji dokumentów XML do HTML albo innych dokumentów XML. Konwersje˛ XSL wykonuje procesor XSL. XML juz˙ dzisiaj odgrywa duz˙a˛role,˛ a w przyszłosci´ jego rola, jako formatu wymiany danych, bedzie˛ jeszcze wieksza˛ i tym samym stanie sie˛ on istotnym elementem przyszłych aplikacji biurowych (m.in. dostepn˛ ych pakietów biurowych). Zwłaszcza wskutek rozdziału warstwy danych i warstwy prezentacji, XML umozliwia˙ niezalezn˙ a˛od platformy prezentacje˛ wszystkich istnieja-˛ cych danych i przede wszystkim edycje˛ danych (takze˙ tresci´ dokumentów) ponad granicami systemu w taki sposób, ze˙ nikt nie musi sie˛ troszczyc´ o prezentacje.˛ Doprowadzi to w przyszłosci´ w duzym˙ stopniu do wyrazne´ go wzrostu produkcyjnosci´ podczas tworzenia dokumentów. Obecnie uzytko˙ wnicy pakietów biurowych spedzaj˛ a˛ znaczna˛ cze˛sć´ swojego czasu pracy nad opracowy- waniem własciwej´ formy dokumentu, który maja˛ stworzyc.´ Wymagana jest przy tym od uzyt-˙ kowników zdolnosć´ projektowania, pod katem˛ której nie zostali wykształceni. Wskutek tego ukształtowanie dokumentu zajmuje wiecej˛ czasu, niz˙ zadanie bed˛ ace˛ sednem pracy powierzonej pracownikowi administracji. Dzieki˛ oddzieleniu warstwy tresci´ od warstwy prezentacji pracownik administracji bedzie˛ mógł znowu skoncentrowac´ sie˛ na swoich zadaniach i produktywnie wykorzystywac´ swój czas pracy. Prezentacje˛ tresci´ bedzie˛ mozna˙ pozostawic´ odpowiedzialnym ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 195

osobom, które bed˛ a˛ raz, centralnie i w jednolity sposób dla wszystkich ustalac´ i kotwiczyc´ definicje. XML jest równiez˙ dosć´ elastyczny, by mozna˙ go było w kazdej˙ chwili dostosowac´ do nowych potrzeb. Zgodnie z SAGA jezyk˛ XML powinien słuzy˙ c´ jako uniwersalny i naczelny standard wymiany danych we wszystkich wazn˙ ych administracyjnych systemach informacyjnych33. „Nowo tworzone systemy powinny byc´ w stanie wymieniac´ dane w formacie XML. Istniejace˛ systemy nie musza˛ obowiazko˛ wo tego umiec“´ 34. Takze˙ w tym punkcie firmy Microsoft i Sun sa˛ zgodne: XML jest podstawa˛ inteligentnych usług WWW.

3.11 Serwer WWW

3.11.1 Przeglad˛

Jesli´ chodzi o migracje˛ serwera WWW, oprócz kontynuacyjnych produktów Microsoft, takich jak Internet Information Server 5.0 i 6.0, rozwiazaniem˛ alternatywnym jest równiez˙ serwer Apa- che. Nie sa˛znane ograniczenia techniczne, które uniemozliwiałyby˙ korzystanie z serwera Apache. Oferuje on wszystkie funkcjonalnosci´ konieczne dla zastosowan´ produkcyjnych. W rzeczywistosci´ Apache udowodnił swoja˛ przydatnos´c´ w licznych scenariuszach zastosowan.´ W konkretnych przypadkach nalezy˙ jednak dokładnie omówic´ nakłady zwiazane˛ z projektem migracyjnym. W przypadku migracji prostych stron HTML bad˛ z´ aplikacji CGI, nakłady migracyjne z reguły utrzymaja˛ sie˛ w przewidywalnych ramach. W przeciwienstwie´ do tego, migracja aplikacji, w szczególnosci´ słuz˙ac˛ ych do generowania dynamicznych tresci´ w oparciu o technologie˛ ASP, wymaga na ogół nowej implementacji aplikacji, co zwieksza˛ nakłady. Jednak z technicznego punktu widzenia nie stanowi to problemu, poniewaz˙ istnieje do dyspozycji wystarczajaca˛ ilos´c´ alternatywnych technologii, takich jak PHP i JSP. 33Standardy i architektury dla aplikacji e - government, wersja 1.1, dokumenty KBSt, ISSN 0179-7263, tom 56, luty 2003 r., http://www.kbst.bund.de/saga 34Standardy i architektury dla aplikacji e - government, wersja 1.1, dokumenty KBSt, ISSN 0179-7263, tom 56, luty 2003 r., http://www.kbst.bund.de/saga ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 196

3.11.2 Wprowadzenie

Najbardziej znana˛ usługa˛ w Internecie jest World Wide Web (WWW). Jest to klasyczna aplikacja Client - Server, w przypadku której klient w sposób pasywny pobiera informacje z serwera. Podstawa World Wide Web opiera sie˛ na protokole HTTP (Hypertext Transfer Protocol) i jezyku˛ opisu strony HTML (Hypertext Markup Language). Serwer przejmuje zadanie udzielania odpowiedzi na zapytania klienta i przesyłania z˙adan˛ ych tresci.´ Zadaniem serwerów WWW jest takze˙ dostarczanie z˙adan˛ ych dynamicznych tresci,´ np. poprzez aplikacje˛ bazodanowa˛ do systemów klienckich. Za posrednictwem´ okreslon´ ych interfejsów mozliwe˙ jest równiez˙ zlecenie uruchamiania po stronie serwera całych programów oraz wykonywania akcji. Akcje inicjalizowane sa˛ z reguły przez systemy klienckie. Umozliwia˙ to wykonywanie procesów klienta po stronie serwera. Wskutek rozprzestrzeniania sie˛ Internetu bad˛ z´ rozwiaza˛ n´ intranetowych nastapił˛ wzrost wymagan´ wzgledem˛ zadan´ realizowanych przez serwery WWW. Doprowadziło to do powstania rózn˙ ych rozwiaza˛ n´ i programów.

3.11.3 Internet Information Server 4.0

Microsoft Internet Information Server (IIS) jest serwerem plików i aplikacji dla Internetu i Intra- netu. ISS 4.0 jest cze˛sci´ a˛ Windows NT Server 4.0 Option Pack. W oparciu o system operacyjny Windows NT 4.0 za pomoca˛ ISS udostepniane˛ sa˛ podstawowe funkcjonalnosci´ serwera WWW. W celu zapewnienia sukcesywnej współpracy klienta z serwerem obsługiwane sa˛ tu wszystkie wazne˙ protokoły internetowe:

◦ HTTP 1.1

◦ SMTP

◦ NNTP

◦ FTP.

Obsługa HTTP w ISS 4.0 obejmuje nastepuj˛ ace˛ usługi:

◦ Pipelining umozliwia˙ wysyłanie wielu z˙ada˛ n´ klientów zanim nastapi˛ reakcja serwera WWW.

◦ Keep Alives Dzieki˛ utrzymaniu połacze˛ n´ klient - serwer klient moze˙ uzywa˙ c´ dla wielu z˙ada˛ n´ jednego połaczenia˛ albo mniejszej ilosci´ połacze˛ n.´ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 197

◦ HTTP PUT i DELETE umozliwia˙ usuwanie albo udostepnianie˛ plików przez uzytko˙ wników poprzez przegladark˛ e˛ WWW. Obsługa RFC 1867 umozliwia˙ takze˙ sterowanie uploads plików za pomoca˛innych programów.

Obsługa SMTP udostepniana˛ jest poprzez zaimplementowana˛ usługe˛ SMTP - Mail słuz˙ac˛ a˛ do wysyłania i odbierania wiadomosci´ SMTP - Mail. Usługe˛ te˛ mozna˙ stosowac´ do komunikacji pomiedzy˛ serwerem WWW i na przykład klientami. Zintegrowana usługa NNTP (Network News Transport Protocol) umozliwia˙ zakładanie lokalnych grup dyskusyjnych na pojedynczym serwerze. Nie jest mozliwa˙ obsługa Newsfeed ani replikacja.

3.11.3.1 Aplikacje Web

Internet Information Server oferuje nastepuj˛ ace˛ rozszerzenia dla serwera:

◦ programy CGI

◦ aplikacje ISAPI

◦ aplikacje ASP.

Common Gateway Interface (CGI) stwarza mozliwo˙ s´c´ generowania dynamicznych tresci.´ CGI jest interfejsem słuz˙ac˛ ym do wywoływania programów, którymi moze˙ posługiwac´ sie˛ serwer. Pierwotnie CGI zaprojektowane zostało dla srodo´ wisk UNIX i w srodo´ wisku Windows NT wymaga bardzo wielu zasobów systemowych. Programy CGI maje˛ te˛ zalete,˛ ze˙ moga˛ byc´ wykonywane przez niemal kazdy˙ serwer WWW oraz, ze˙ z reguły mozna˙ je łatwo napisac.´ Internet Service Application Programming Interface (ISAPI) jest bezposrednim´ interfejsem do IIS. Poprzez ISAPI mozna˙ odwoływac´ sie˛ do obiektów umieszczonych na serwerze. IIS 4.0 umozliwia,˙ wskutek zastosowania Active Server Pages (ASP), tworzenie dynamicznych stron HTML albo aplikacji WWW. Za pomoca˛ technologii ASP udostepniane˛ jest srodo-´ wisko skryptowe po stronie serwera. Strony ASP sa˛ plikami, które oprócz tradycyjnych znacz- ników HTML moga˛ takze˙ zawierac´ instrukcje skryptowe. Odpowiednie instrukcje skryptowe wykonywane sa˛ na serwerze i wykorzystywane do tworzenia kodu HTML. Dynamiczny i sta- tyczny kod HTML przesyłany jest z powrotem, w formie strony HTML, do przegladarki˛ WWW, która wysłała zapytanie. Stosowanie stron ASP umozliwia˙ kształtowanie interaktywnych tresci´ dla uzytko˙ wników. Za pomoca˛ ASP mozna˙ takze˙ realizowac´ odwoływanie sie˛ do bazy danych. W zwiazku˛ z rozwojem stron WWW ISS 4.0 obsługuje nastepuj˛ ace˛ technologie: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 198

◦ Microsoft Script Debugger umozliwia˙ testowanie aplikacji ASP.

◦ Interfejs programowania COM umozliwia˙ programistom dostep˛ do składników COM, które odwołuja˛ sie˛ do funkcji pro- tokołu ISS.

◦ Java Virtual Machine umozliwia˙ tworzenie i wykonywanie składników Java wewnatrz˛ maszyny wirtualnej.

◦ Obiekty administracyjne ISS umozliwiaj˙ a˛ programistom dostep˛ do składników niezbedn˛ ych do tworzenia programów administrujac˛ ych.

◦ Transakcyjne strony ASP umozliwiaj˙ a˛stronom ASP i wywoływanym przez nie składnikom bycie cze˛sci´ a˛transakcji, która to transakcja musi byc´ jednak zarzadzana˛ przez Microsoft Transaction Server (patrz takze˙ 3.11.3.3).

◦ Izolowanie procesów dzieki˛ tej technologii aplikacje ASP oraz ISAPI (Internet Server - API) moga˛ byc´ wykonywane jako oddzielne procesy. Procesy te wykonywane sa˛ oprócz głównego procesu serwera.

◦ Załaczanie˛ i odłaczanie˛ składników oznacza, ze˙ programisci´ WWW moga˛ włacza˛ c´ albo odłacza˛ c´ dynamiczne składniki aplikacji WWW.

3.11.3.2 Autoryzacja i bezpieczenstwo´

Model bezpieczenstwa´ jest jednakowy dla wszystkich składników serwera NT. W przypadku IIS mozna˙ uzywa˙ c´ takich samych funkcji, jakimi dysponuje serwer plików albo serwer bazy danych. Mozna˙ skorzystac´ z istniejac˛ ych uzytko˙ wników domen i grup w celu nadania ograniczonych i uprawnien.´ IIS korzysta z takiej samej bazy danych katalogów, jak inne serwery Windows NT. Uzytko˙ wnikom mozna˙ umozliwi˙ c´ ograniczony dostep˛ do zasobów sieciowych, takich jak strony HTML, aplikacje WWW oraz pliki. W celu dokładnego przydzielenia uprawnien´ mozna˙ takze˙ skorzystac´ z uprawnien´ systemu plików NTFS. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 199

Zastosowanie Secure Sockets Layer (SSL umozliwia˙ bezpieczna˛wymiane˛ informacji pomie-˛ dzy klientem a serwerem. Istnieje równiez˙ mozliwo˙ sć,´ aby serwery identyfikowały albo autory- zowały klienta a uzytko˙ wnik nie musiał logowac´ sie˛ na serwerze. Zintegrowany Certificate Server oferuje mozliwo˙ sć´ utworzenia instancji certyfikujacej˛ i udostepnienia˛ klientom standardowej certyfikacji X.509

3.11.3.3 Dodatkowe składniki Internet Information Server

Oprócz rdzennych składników ISS Microsoft oferuje dodatkowe składniki w celu rozszerzenia funkcjonalnosci´ serwera WWW. Składniki opisane ponizej˙ sa˛ równiez˙ cze˛sci´ a˛ Windows NT Option Pack. Microsoft Transaction Server (MTS) MTS jest systemem przetwarzajac˛ ym transakcje słuz˙ac˛ ym do rozwoju, implementacji i zarzadza-˛ nia dzielonymi aplikacjami serwera. Przetwarzanie transakcji mozna˙ wykorzystac´ na przykład do realizacji dzielonych aplikacji biznesowych.

Microsoft Script Debugger Microsoft Script Debugger słuzy˙ do wyszukiwania błedów˛ w składni plików ASP. Debugger mozna˙ wykonywac´ w połaczeniu˛ z Internet Explorer i w ten sposób korygowac´ błedy˛ .

Microsoft Index Server Index Server mozna˙ wykorzystywac´ w Internecie i / lub Intranecie jako wyszukiwarke.˛ Serwer moze˙ naznaczac´ teksty zapisanej zawartosci,´ która˛ mozna˙ udostep-˛ niac´ uzytko˙ wnikom do przeszukiwania poprzez formularze WWW. Index Server moze˙ oprócz dokumentów HTML naznaczac´ takze˙ dokumenty Microsoft Word i Microsoft Excel.

Microsoft Message Queue Server Microsoft Message Queue Server (MMQS) pozwala asynchronicznie komunikowac´ ze soba˛programy uzytko˙ we poprzez wysyłanie i odbieranie wiadomosci.´

Microsoft Management Console Microsoft Management Console (MMC) umozliwia˙ zarzadzanie˛ najrózniejszymi˙ zadaniami poprzez rózne˙ sieciowe programy zarzadzaj˛ ace.˛ Admini- strowanie serwerem moze˙ odbywac´ sie˛ za pomoca˛ tak zwanych „Snap - Ins“ wewnatrz˛ konsoli. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 200

3.11.4 Migracja zastepuj˛ aca˛

3.11.4.1 Apache

Aplikacja˛ bardzo czesto˛ stosowana˛ w praktyce w systemach opartych na Linuksie jest serwer Apache. Jest on najcze˛sciej,´ bo az˙ w 60%, wykorzystywanym serwerem WWW35 na swiecie.´ Jest wolno dostepn˛ y i udostepnian˛ y na licencji Apache Software. Serwer Apache jest jednym z odnoszac˛ ych najwieksze˛ sukcesy projektów Open Source Community. Projekt ten rozwinał˛ sie˛ z serwera (National Center for Supercomputing Application, University NCSA Illinois), do któ- rego dodawano coraz wieksz˛ a˛ ilos´c´ łat. („A patchy web server") i który w 1995 roku posłuzył˙ jako podstawa dla pierwszej wersji beta. W tak zwanym miedzyczasie˛ został on przeportowany do niemal wszystkich platform. Serwer Apache jest dzisiaj najbardziej rozpowszechnionym serwerem WWW na platformach Linux / UNIX, jednak działa takze˙ z całym szeregiem innych platform, takich jak Windows NT czy Novell Netware. Pocza˛wszy od wersji 2.0.35 z kwietnia 2002 roku seria 2.0 serwera Apache udostepniana˛ jest jako stabilna i jest zalecana przez developerów do stosowania w celach produkcyjnych. Obecnie oprócz nowej serii 2.0.x dodatkowo nadal utrzymywana jest seria 1.3.x, która aktualnie dostepna˛ jest w wersji 1.3.27. Dzieki˛ zapisom licencyjnym i swojej wysokiej jakosci´ serwer Apache wykorzystywany jest równiez˙ w produktach komercyjnych. IBM dostarcza na przykład Apache w ramach produktów Websphere.

Zakres funkcji Serwer WWW Apache składa sie˛ z rdzenia i duzej˙ ilosci´ modułów, które mozna˙ wkompi- lowac´ bad˛ z´ włacza˛ c´ w zalezno˙ sci´ od kazdorazo˙ wych wymagan.´ Dzieki˛ modularnej budowie zakres funkcji serwera Apache daje sie˛ bardzo łatwo rozszerzac´ i mozna˙ go dopasowywac´ do zmienionych wymagan.´ Normalny zakres dostawy oprogramowania zawiera juz˙ wiele rózn˙ ych modułów, które mozna˙ jeszcze uzupełnic´ o dalsze moduły (np. własne). Moduły Apache sa˛ seg- mentami kodu, które odpowiadaja˛ specyfikacji API Apache i moga˛ byc´ właczane˛ do serwera Apache. Moduły Apache moga˛ byc´ właczane˛ statycznie na stałe albo dynamicznie poprzez plik konfiguracyjny serwera WWW. Taka modularna budowa słuz˙aca˛ rozszerzeniu własciwo´ sci´ serwera WWW niezwykle podnosi elastycznosć´ systemu. Wydajnosć´ i predko˛ sć´ serwera WWW wzrasta, gdy zamiast zewnetrzn˛ ych aplikacji przetwarzane moga˛ byc´ procesy wewnetrzne.˛ Wsród´ wielu modułów znajduja˛sie˛ moduły autoryzacji, bezpieczenstwa´ i skryptów, wzgled-˛

35http://news.netcraft.com/archives/2003/03/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 201

nie interpreterów jezyków˛ programowania, takich jak, np. PHP, Java, Python, Tcl i Perl. Istnieja˛ dwie rózne˙ mozliwo˙ sci´ korzystania z modułów:

◦ podczas statycznej kompilacji moduły moga˛ byc´ na stałe właczone˛ do serwera WWW.

◦ moduły moga˛ byc´ właczane˛ dynamicznie podczas pracy serwera. Ta tak zwana funkcjonalnos´c´ DSO (Dynamic Shared Objects) nie wymaga w przypadku zmiany konﬁgura- cji serwera ponownej kompilacji. Wystarczy ponownie uruchomic´ serwer. Mozliwy˙ jest Graceful-Restart bez przerywania swiadczenia´ usług.

Podczas, gdy wykorzystywane sa˛ rzeczywiscie´ potrzebne moduły, Apache pozostaje mniejszy niz˙ jego standardowa wersja i zajmuje mniej miejsca w pamieci.˛ Jednoczesnie´ mniej modułów oznacza takze˙ mniejsza˛mozliw˙ a˛powierzchnie˛ ataku, dzieki˛ czemu wzrasta bezpieczenstwo´ systemu. Nastepuj˛ aca˛ tabela przedstawia mały wybór dostepn˛ ych modułów.

MODUŁ FUNKCJA Moduły standardowe i dodatkowe mod_cgi Wykonywanie skryptów CGI (Common Gateway Interface). mod_dav Zintegrowana obsługa DAV (HTTP Extensions for Distributed Authoring - Web DAV). Edycja plików i katalogów bezposred-´ nio poprzez HTTP na serwerze WWW. DAV oznacza Distributed Authoring and Versioning. mod_fastcgi Zintegrowana obsługa FastCGI. mod_frontpage Zintegrowana obsługa FrontPage. mod_iserv Zintegrowana obsługa Java Servlet. mod_php3 Zintegrowana obsługa PHP3. mod_php4 Zintegrowana obsługa PHP4. mod_perl Zintegrowana obsługa Perla. mod_alias Udostepnia˛ instrukcje Alias bad˛ z´ Redirect. mod_autoindex Generuje naznaczanie katalogów. mod_include Jest potrzebna dla Server - Sides Includes. mod_mime Zapewnia generowanie odpowiednich MIME - Headers. mod_log_config Potrzebny do prowadzenia jednego albo wielu Logfiles. Istnieje mozliwo˙ sć´ dostosowania tresci´ do odpowiednich potrzeb. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 202

mod_deflate Słuzy˙ do kompresji rózn˙ ych typów danych przed transmisja˛ do przegladarki˛ WWW. Ma sens zwłaszcza w przypadku ograniczonych pasm. Kompresja musi byc´ obsługiwana przez przegladark˛ e.˛ mod_proxy Rozszerza serwer WWW Apache o funkcjonalnosć´ serwera posrednicz´ ace˛ go bad˛ z´ Proxy - Caches. mod_rewrite Umozliwia˙ stosowanie dowiaza˛ n´ wewnetrzn˛ ych i zewnetrzne˛ Re- directs. mod_speling Koryguje błedy˛ uzytko˙ wników w pisowni. mod_ssl Udostepnia˛ protokoły SSL (Secure Sockets Layer) oraz TLS (Transport Layer Security). mod_usertrack Za pomoca˛ HTTP-Cookies protokołowane jest zachowanie uzyt-˙ kowników. mod_vhost_alias Słuzy˙ do masowej konfiguracji wirtualnych hostów, szczególnie interesujace˛ dla Service - Provider. Moduły autoryzacji mod_access Kontrola dostepu˛ w oparciu o nazwy hostów albo adresy IP. mod_auth Słuzy˙ do konfiguracji katalogów bad˛ z´ dokumentów chronionych hasłami. Bardzo prosty wariant modułu autoryzacji. Powinien byc´ stosowany tylko dla małej ilosci´ uzytko˙ wników. mod_auth_digest Autoryzacja uzytko˙ wników za pomoca˛ MD5 Digest Authentica- tion. Transmisja haseł nie odbywa sie˛ w formie czytelnego tekstu. mod_auth-dbm Autoryzacja uzytko˙ wników za pomoca˛ plików Berkeley DB. Ma sens w przypadku zastosowania dla wiekszej˛ ilosci´ uzytko˙ wni- ków. mod_auth_ldap Autoryzacja uzytko˙ wników za pomoca˛ LDAP. mod_auth_kerb Autoryzacja uzytko˙ wników za pomoca˛Kerberos. Obsługuje wersje 4 i 5. mod_auth_notes Autoryzacja uzytko˙ wników za pomoca˛ serwera Lotus Notes. mod_auth_oracle Autoryzacja uzytko˙ wników za pomoca˛ bazy danych Oracle. Ist- nieja˛ takze˙ jeszcze inne moduły, np. dla baz danych MySQL i PostgreSQL. mod_auth_smb Autoryzacja uzytko˙ wnika za pomoca˛serwera SMB (Samba, Win- dows NT). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 203

Tablica 3.30: Moduły Apache

Powyzszy˙ spis dostepn˛ ych modułów nie jest pełny i przedstawia tylko wycinek mozliwo˙ sci´ serwera Apache. Jednak nie wszystkie moduły dla w/w serwera WWW sa˛ dostepne˛ nieodpłatnie. Pojawiaja˛ sie˛ coraz to nowe przedsiebiorstwa˛ oferujace˛ komercyjne natywne moduły Apache. Sa˛ to, np.:

◦ Allaire z Java-Servlet-Engine Macromedia JRun i serwerem aplikacji Macromedia Cold- Fusion,

◦ Sun Microsystems z modułem Active Server Pages.

Tematy pokrewne W celu zintegrowania funkcjonalnosci´ wyszukiwania za pomoca˛ strony WWW, serwer Apa- che mozna˙ uzupełnic´ o odpowiedni program. Do wyboru istnieja˛ rózne˙ jednostki oprogramowania. Ponizej˙ przykładowo opisalismy´ system wyszukiwania HTDig36. HTDig umozliwia˙ indeksowanie całych stron WWW. Program ten tworzy, za pomoca˛ tak zwanego Rebots, indeks wyszukiwania, który mozna˙ odpytywac´ korzystajac˛ z przeznaczonych do tego skryptów CGI. Nastepuj˛ ace˛ punkty oddaja˛ najwazniejsze˙ funkcjonalnosci´ programu:

◦ załozenie˙ indeksu przeszukiwanych maszyn (obejmujace˛ go jedna˛ lub wiecej˛ stron WWW bad˛ z´ obszary strony WWW).

◦ ograniczenie indeksowania dzieki˛ zastosowaniu ﬁltrów. Kryteriami ﬁltrowania moga˛ byc´ typy plików i okreslone´ adresy URL.

◦ dzieki˛ zastosowaniu zewnetrzne˛ go dodatkowego oprogramowania mozna˙ indeksowac´ takze˙ formaty plików (PDF. DOC, itd.).

◦ istnieja˛ liczne mozliwo˙ sci´ odpytywania i mozna˙ korzystac´ z wielu algorytmów wyszukiwania (słowa, cze˛sci´ słów, synonimy, itd.).

◦ za pomoca˛ prostych plików template mozna˙ dostosowywac´ strone˛ wyszukiwania i odpowiednia˛ liste˛ traﬁen.´

◦ wewnatrz˛ wyszukiwanych poje˛c´ obsługiwane sa˛ znaki narodowe.

36http://www.htdig.org/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 204

◦ stosowany Rebot obsługuje standard „Rebot Exclusion“ oraz „Basic - WWW - Authenti- cation“ do indeksowania chronionych tresci.´

HTDig jest rozpowszechniany na licencji GNU General Public Licence (GPL) i tym samym wolno dostepn˛ y.

Administrowanie Konfiguracja zainstalowanego Apache jest zadaniem wzglednie˛ prostym, poniewaz˙ dla wiek-˛ szosci´ konfiguracji wymagana jest tylko zmiana albo dodanie wpisów w dobrze udokumentowanym pliku. Jest to plik tekstowy, który mozna˙ edytowac´ za pomoca˛ edytora tekstu. Dla ad- ministratorów preferujac˛ ych interfejs graficzny istnieje kilka komercyjnych i niekomercyjnych projektów GUI37 Apache .

Migracja W ramach migracji nalezy˙ rozrózni˙ c,´ jakich danych bad˛ z´ tresci´ ma dotyczyc´ migracja. Mozna˙ tu wyszczególnic:´

◦ pliki HTML

◦ programy CGI (Perl, PHP, C, itd.)

◦ moduły programów, które korzystaja˛ z ISAPI (Internet Server Application Programming Interface) serwera Internet Information Server. oraz

◦ Active Server Pages.

Strony HTML Tresci´ statyczne, takze˙ czyste strony HTML, mozna˙ eksportowac´ do nowego serwera WWW bez ich dalszego dopasowywania i moga˛ one, w przypadku migracji do nowego serwera WWW, ewentualnie powodowac´ jedynie minimalne problemy i nakłady.

37patrz takze˙ http://gui.apache.org/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 205

Common Gateway Interface Programy, które stworzone zostały dla Common Gateway Interface (CGI) wykorzystuja˛ rów- niez˙ specyficzny standard CGI. Okresla´ on sposób integracji programów i serwera WWW. Stan- dard ten nie jest specyficzny dla danego jezyka˛ programowania i jest obsługiwany przez serwer WWW. Podczas tworzenia programów CGI skorzystac´ mozna˙ z licznych mozliwo˙ sci.´ Jednym z najbardziej rozpowszechnionych oraz dostosowanych do portów jest jezyk˛ skryptowy Perl. Perl dostepn˛ y jest dla systemów MS - DOS, UNIX / Linux, OS / 2, Macintosh i kazdej˙ wersji Windows. Perl oferuje takze˙ programistom WWW obszerne mozliwo˙ sci´ manipulacji tekstem i danymi. Aplikacje, które napisane zostały w Perlu, mozna˙ bardzo łatwo migrowac´ do Apa- che. Apache zapewnia dzieki˛ modułowi „mod_perl“ pełna˛ implementacja˛ Perla. Ponadto czesto˛ pozwala on uzyskac´ lepsza˛ wydajnosć´ podczas wykonywania w/w skryptów. Moduł Perla wpisuje interpreter Perla w serwer Apache, dzieki˛ czemu aby wykonac´ kod programu nie musi byc´ juz˙ wykonywany oddzielny proces i mozna˙ uzyskac´ znaczny przyrost predko˛ sci.´ W przypadku portowania aplikacji perlowych konieczne jest tylko dokonanie minimalnych zmian w kodzie programu. PHP jest jednym z najszybciej rozprzestrzeniajac˛ ych sie˛ jezyków˛ skryptowych, który odznacza sie˛ bardzo dobra˛obsługa˛rózn˙ ych systemów baz danych oraz wzglednie˛ prosta˛składnia.˛ PHP mozna,˙ podobnie jak Perla, stosowac´ na wielu rózn˙ ych systemach. Aplikacje PHP, które zostały zaprojektowane dla Internet Information Server, mozna˙ przy minimalnym nakładzie przeportowac´ do serwera WWW Apache.

ISAPI Aplikacje korzystajace˛ z ISAPI mozna˙ stosowac´ kontynuacyjnie tylko w przypadku tych ser- werów Apache, które działaja˛w systemie opartym na Windows NT albo Windows 2000. Apache w systemach windowsowych zawiera jako standardowa˛ funkcjonalnosć´ zapewniajac˛ a˛ całkowita˛ kompatybilnosć´ z ISAPI. Aplikacje wymagaja˛ jedynie ponownej kompilacji w nowym srodo´ wisku Apache. Na ogół nie jest wymagana zmiana kodu, jednak nie ma obsługi filtrów ISAPI oraz rozszerzen´ Microsoft dla asynchronicznych operacji na plikach.

ASP Aplikacje oparte na technologii ASP zaprojektowane zostały z reguły w celu generowania dynamicznych tresci´ WWW. Mozna˙ przy tym stosowac´ rózne˙ podstawy:

◦ Visual Basic Script (VBScript)

◦ JScript ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 206

oraz

◦ Active X Data Objects (ADO) dla dostepu˛ do baz danych.

Aby móc wykonywac´ strony ASP na serwerze WWW Apache, potrzebne jest kompletne srodo-´ wisko programowania kompatybilne z Microsoft (VBScript, JScript, ADO). Firma Sun Micro- systems oferuje wraz ze swoim produktem „Sun One Active Server Pages 4.0“38 kompatybilne srodo´ wisko do wykonywania stron ASP wewnatrz˛ serwera WWW Apache. Serwer WWW moze˙ pracowac´ w systemie operacyjnym NT bad˛ z´ w systemie Unix / Linux.

◦ Produkt ten obsługuje:

◦ ASP 3.0

◦ VBScript 5.5

◦ JScript 5.5.

Aby przeprowadzic´ migracje˛ do serwera WWW Apache pracujace˛ go na systemie linuksowym nalezy˙ w pierwszym kroku skopiowac´ wszystkie pliki ASP do nowej platformy docelowej. W kolejnym kroku wewnatrz˛ aplikacji ASP nalezy˙ okresli´ c´ wykorzystywane obiekty COM i zsynchronizowac´ je z obiektami obsługiwanymi w Linuksie. Liczne obiekty obsługiwane sa˛ przez Sun One ASP. Jesli´ potrzebny obiekt nie jest obsługiwany, wówczas istnieje mozliwo˙ sć´ zastosowania dostarczanego COM - to - Java Bridge i zaimplementowania funkcjonalnosci´ za pomoca˛ Java. Dodatkowo nalezy˙ jeszcze sprawdzic´ zmiany pod katem˛ pisowni wielka˛i mała˛litera˛ oraz wersje˛ ASP Engine bad˛ z´ Scripting Engine. Dokładny opis znajduje sie˛ w odpowiedniej dokumentacji. Migracja wymagana w przypadku bazy danych nie jest omawiana w niniejszym podrozdziale. Dokładne informacje na ten temat znalezć´ mozna˙ w rozdziale 3.13, Bazy danych. Oprócz mozliwo˙ sci´ zachowania aplikacji ASP w ich dotychczasowej formie, istnieje oczywiscie´ takze˙ mozliwo˙ sć´ zastosowania alternatywnych technologii. Rozwiazanie˛ takie nasuwa sie,˛ gdy wyraznie´ chcemy uzyskac´ wieksz˛ a˛ niezalezno˙ sć´ od platformy. Nalezy˙ jednak liczyc´ sie˛ wówczas z wiekszymi˛ nakładami migracyjnymi, gdyz˙ realizacja aplikacji w nowej technologii z reguły powoduje zwiekszone˛ nakłady. Jednakze˙ taki proces migracji mozna˙ takze˙ wykorzystac´ do konsolidacji i optymalizacji tresci´ i aplikacji. Prawdziwa˛ alternatywna˛ metoda˛ dla realizacji celów spełnianych przez aplikacje moze˙ byc´ zastosowanie technologii PHP. Ulubiona platforma (LAMP), która szczególnie w ostatnich latach słuzy˙ do generowania tresci´ stron WWW, składa sie˛ z kombinacji:

38patrz takze˙ http://sun.de/Produkte/software/chilisoft/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 207

◦ GNU/Linux

◦ Apache

◦ MySQL

◦ PHP.

Jesli´ chodzi o przekształcanie aplikacji ASP do PHP, pomóc moze˙ ewentualnie ocena tresci´ projektu „ASP - to - PHP“39. Projekt ten udostepnia˛ na swojej stronie domowej konwerter ASP - to - PHP i oferuje wsparcie w ramach listy dyskusyjnej. Oprócz powyzszej˙ mozliwo˙ sci´ mozna˙ takze˙ rozwazy˙ c´ zastosowanie technologii opartej na Java. Aplikacje WWW oparte na Java sa˛ interesujac˛ a˛ alternatywa˛ dla aplikacji WWW opartych na ASP. Obecnie najcze˛sciej´ stosowane aplikacje Java opieraja˛ sie˛ na specyfikacjach Sun Mi- crosystems Java 2 Standard Edition (J2SE) oraz Java 2 Enterprise Edition (J2EE). Technologia Java opierajac˛ sie˛ na standardzie przemysłowym oferuje zalete˛ niezalezno˙ sci´ od platformy. Apli- kacje WWW J2SE pozwalaja˛ na tworzenie dynamicznych tresci´ za pomoca˛ Java Server Pages (JSP) i Java Servlets. Obydwie technologie umozliwiaj˙ a˛ m.in. rozwój osobistych tresci´ i dostep˛ do zewnetrzn˛ ych zródeł´ danych. W celu wykonywania stron JSP i Servletów mozna˙ skorzystac´ z produktu Open source „Tomcat“40. Projekt Tomcat stworzony został w kontekscie´ Apache So- ftware Foundation (ASF). Tomcat oferuje skalowalne srodo´ wisko wykonywania stron JSP oraz Java - Servlets i tym samym jest bardzo dobra˛ alternatywa˛ dla rozwiaza˛ n´ ASP w przypadku aplikacji nie zawierajac˛ ych skomplikowanej logiki biznesowej. Tomcat w wersji 4.x obsługuje specyfikacje Servlet 2.3 i JSP 1.2. W przypadku skomplikowanych scenariuszy aplikacji, które potrzebuja˛ rozszerzonych funkcjonalnosci´ mozna˙ sie˛gna˛c´ po standardy Java 2 Enterprise Edition. Za pomoca˛ tak zwanych Enterprise Java Beans (EJB) mozna˙ realizowac´ aplikacje dla skomplikowanych procesów i reguł biznesowych, które jednoczesnie´ wymagaja˛ dostepu˛ do systemów zewnetrzn˛ ych. Srodo´ wisko J2EE wymaga serwera aplikacji, który przejmie wykonywanie EJB. Serwer aplikacji musi byc´ w stanie zagwarantowac´ zarzadzanie˛ sesja˛ uzytko˙ wników, oferowac´ odpowiednie interfejsy do zewnetrzn˛ ych aplikacji i zapewnic´ konieczna,˛ wysoka˛niezawodnosć´ (Cluster, Load - Balancing, Failover). Oprócz znanych komercyjnych produktów, takich jak, np. IBM Websphere, BEA We- blogic, Oracle Application Server i kilku innych, istnieje takze˙ mozliwo˙ sć´ zastosowanie produktu Open Source. Projekt „JBoss41“ oferuje pełny Java - Applications - Server. Serwer ten obsługuje

39http://asp2php.naken.cc 40http://jakarta.apache.org/tomcat/index.html 41http://www.jboss.org ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 208

specyﬁkacje˛ J2EE, oferuje zintegrowany serwer WWW, JSP Engine i Servlet Engine, obsługe˛ Enterprise Java Beans, ponadto Clustering i liczne dalsze funkcjonalnosci.´ Szczegółowy opis procedur migracji aplikacji ASP do technologii opartych na Java oferuje˛ na przykład takze˙ przedsiebiorstwa˛ SUN42 i Oracle43, dlatego w tym miejscu z niego zrezygnujemy.

3.11.5 Migracja kontynuacyjna

3.11.5.1 Internet Information Server 5.0

Nowosci´ Internet Information Server jest integralna˛ cze˛sci´ a˛ składowa˛ serwera Windows 2000. Kolejna wersja Internet Information Server 4.0 posiada cały szereg nowych funkcjonalnosci.´ Najwazniej-˙ sze nowosci´ zostały przedstawione w ponizszej˙ tabeli:

FUNKCJA OPIS Udostepnianie˛ danych Obsługa standardu WebDAV w celu wspólnej edycji plików i ka- WebDAV talogów bezposrednio´ poprzez HTTP po stronie serwera. Obsługa katalogów WWW. Słuz˙a˛ uzytko˙ wnikom jako tradycyjne katalogi WWW katalogi plików na serwerze WWW i bezposrednio´ zwiazane˛ sa˛ z funkcjonalnosci´ a˛ WebDAV. Umozliwia˙ tworzenie i zarzadzanie˛ tresciami´ WWW za pomoca˛ obsługa Frontpage Microsoft Frontpage. Za pomoca˛ graﬁcznej Frontend administrator moze˙ tworzyc´ i zmieniac´ tresci´ WWW na serwerze. obsługa multiplen web Umozliwia˙ hosting rózn˙ ych stron WWW na jednym serwerze i - sites jednym adresie IP. Umozliwia˙ kompresje˛ HTTP podczas komunikacji pomiedzy˛ ser- kompresja HTTP 1.1 werem WWW i systemami klienta obsługujac˛ ymi kompresje.˛ Ma sens zwłaszcza w przypadku ograniczonej szerokosci´ pasma.

42http://developer.iplanet.com/docs/migration/webserver/IIS_50.pdf 43http://otn.oracle.com/tech/migration/asp/content.html ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 209

„Platform for Internet Content Selection"44 - Rating jest tech- nicznym standardem słuz˙ac˛ ym do wdrazania˙ systemu oceny tresci´ stron WWW wprowadzonym przez konsorcjum W3. PICS ła-˛ PICS Rating czy ocene˛ tresci´ z mozliwo˙ sci´ a˛ ﬁltrowania stron WWW według okreslon´ ych cech. W tym celu nalezy˙ wprowadzic´ w nagłówkach HTML dokumentu kod PICS, który nie jest widoczny w przegla-˛ darce WWW. Aplikacje oparte na WWW XML - Parser w Windows 2000 jest zaimplementowany jako integracja XML składnik COM i udostepnia˛ pełna˛ podstawe˛ XML dla aplikacji. Developerzy moga˛ za pomoca˛ technologii skryptowej rozwijac´ składniki skryptów dla aplikacji WWW moduły COM dajace˛ sie˛ ponownie wykorzy- windowsowych stac.´ okreslanie´ własciwo´ sci´ Za pomoca˛ ASP mozna˙ ustalic´ dokładne własciwo´ sci´ przegla-˛ przegladarki˛ WWW darki WWW systemów klienckich. Administrator moze˙ izolowac´ pojedyncze procesy aplikacji od rozdzielanie procesów procesów głównych i innych procesów aplikacji. Umozliwia˙ dostep˛ do obiektów, własciwo´ sci´ i metod Active Di- rectory Service Interface. Integracja serwera WWW i Active Di- ADSI 2.0 rectory umozliwia˙ przypisanie rózn˙ ych stron WWW na serwerze WWW do okreslon´ ych domen uzytko˙ wników. Administrowanie delegacja zarzadzania˛ Umozliwia˙ przekazanie zadan´ administracyjnych. Umozliwia˙ ograniczenie czasu CPU dla aplikacji albo strony throttling WWW. Dzieki˛ temu mozna˙ zapewnic´ dostepno˛ s´c´ czasu procesora dla innych stron WWW albo aplikacji niesieciowych. Distributed File System to system plików umozliwiaj˙ ac˛ y przezro-´ czyste rozdzielanie plików pomiedzy˛ wiele komputerów. Moze˙ DFS byc´ uzywan˙ y dla dokumentów root w miejscu, w którym w systemie plików składowane sa˛ tresci´ WWW.

44http://www.w3.org/PICS/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 210

Autoryzacja i bezpieczenstwo´ Autoryzacja uzytko˙ wników moze˙ odbywac´ sie˛ za pomoca˛Kerbe- Kerberos ros. Jednak nadal dostepna˛ jest stara metoda logowania do Win- dows za pomoca˛ Windows LAN Manager (NTLM). Zastosowanie SSL 3.0 i TLS (Transport Layer Security) do szy- szyfrowanie frowanej transmisji danych. Umozliwia˙ transmisje˛ zaszyfrowanych haseł wymaganych dla au- autoryzacja Digest toryzacji. ograniczenia domen i Administrator otrzymuje mozliwo˙ sć´ udostepniania˛ bad˛ z´ bloko- IP wania komputerom i domenom dostepu˛ do zawartosci.´ certyfikaty Obsługa certyfikatów klienta i serwera.

Tablica 3.32: Rozszerzone funkcjonalnosci´ Internet Information Server 5.0

3.11.5.2 Internet Information Server 6.0

Do zakresu dostawy Windows Server 2003 nalezy˙ Internet Information Server 6.0 (ISS 6.0), który podczas standardowej instalacji jest poczatko˛ wo całkowicie zablokowany i nie jest automatycznie zintegrowany z systemem. Administrator musi z zewnatrz˛ uruchomic´ proces instalacji serwera oraz aktywowac´ poszczególne jego funkcjonalnosci.´ Z połaczenia˛ nastepuj˛ ac˛ ych technologii z grupy produktów serwera Windows 2003:

◦ Internet Information Server 6.0

◦ ASP.NET

◦ ASP

◦ COM+

◦ Microsoft Message Queuing (MSMQ) powinny byc´ w przyszłosci´ oferowane mozliwo˙ sci´ serwera aplikacji. Na potrzeby tej nowej roli w Internet Information Server zaimplementowanych zostało kilka nowosci,´ których krótki opis znajduje sie˛ ponizej.˙ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 211

Dla uzyskania poprawy w obszarze niezawodnosci´ i skalowalnosci´ wprowadzono zmiany wewnatrz˛ architektury przetwarzania. Dzieki˛ temu błedy˛ moga˛byc´ rozpoznawane automatycznie a w razie potrzeby istnieje mozliwo˙ s´c´ ponownego uruchamiania procesów. Równolegle serwer WWW kolejkowac´ nadchodzace˛ z˙adania.˛ IIS 6.0 jest w stanie prowadzic´ kontrole˛ stanu proce- sów roboczych, aplikacji i stron WWW. Wraz z serwerem Windows 2003 wprowadzony został takze˙ nowy sterownik trybu pracy jadra,˛ którego zadaniem jest optymalizowanie przepływu danych na serwerze WWW. IIS 6.0 mozna˙ zintegrowac´ z framework autoryzacyjnym serwera Windows 2003. Dodat- kowo, mozna˙ korzystac´ z menedzera˙ autoryzacji do prowadzenia akcji delegowania i autoryzacji. Zarzadzanie˛ IIS 6.0 odbywa sie˛ teraz w oparciu o meta XML i umozliwia˙ administratorowi bezposredni´ a˛ edycje˛ konﬁguracji. Nowa jest tu takze˙ integracja ASP.NET i IIS, programistom oferowane sa˛ rozszerzone funkcjonalnosci´ .NET Framework do tworzenia aplikacji. Dla programistów i uzytko˙ wników mozna˙ zastosowac´ standard Unicode realizujac˛ y internacjonalizacje.˛

3.12 SharePoint Portal Server

3.12.1 Przeglad˛

SharePoint Portal Server nie został opisany w poradniku migracyjnym pod katem˛ konkretnej migracji. System ten oceniony został w pierwszym rzedzie˛ ze wzgledu˛ na przyszłe zastosowanie. Podsumowujac,˛ w oparciu o wyniki analizy wymagan´ nalezy˙ stwierdzic,´ ze˙ SharePoint Portal Server moze˙ byc´ jak najbardziej brany pod uwage˛ w ramach ogólnej koncepcji rozwiazania˛ portalowego albo systemu zarzadzania˛ dokumentami.

3.12.2 Wprowadzenie

Wraz z SharePoint Portal Server ﬁrma Microsoft zaoferowała platforme˛ do tworzenia portali WWW o nastepuj˛ ac˛ ych podstawowych funkcjonalnosciach:´

◦ wyszukiwanie

◦ zarzadzanie˛ dokumentami

◦ praca grupowa. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 212

Microsoft stworzył tym samym produkt, który moze˙ spełniac´ klasyczne zadania portalu intrane- towego w obrebie˛ przedsiebiorstwa.˛ Aby stworzyc´ a nastepnie˛ zarzadza˛ c´ tresciami´ w obszarze przedsiebiorstwa˛ SharePoint Portal Server bardzo mocno integruje aplikacje desktopowe (Win- dows - Explorer, aplikacje biurowe, przegladarka˛ internetowa). SharePoint Portal Server jest rozwiazaniem˛ portalowym ze zintegrowanymi funkcjonalnosciami´ wyszukiwania oraz Workﬂow. Jesli´ chodzi o wymagania systemowe, niezbedn˛ y jest tu serwer Microsoft Windows 2000 bad˛ z´ Advanced Server, jak równiez˙ Internet Information Service 5.0 i Simple Mail Transfer Protocol. SharePoint Portal Server nie wymaga Active Directory. Serwer mozna˙ zainstalowac´ do wyboru w Windows NT albo domenie Active Directory. SharePoint Portal Server 2001 oparty jest na systemie bazodanowym WebStorage ﬁrmy Mi- crosoft. Administrowanie serwerem odbywa sie˛ poprzez Microsoft Management Console (MMC). Mozna˙ tu ustalac´ miedzy˛ innymi zakresy robocze, zadania bezpieczenstwa,´ czasy timeout i ustawienia protokołu. W celu zapewnienia bezpiecznej wymiany danych poprzez Internet / Extranet mozna˙ właczy˛ c´ szyfrowanie SSL. Ocena i prezentacja SharePoint Portal Server w tym kontekscie´ ma na celu uwypuklenie pojedynczych aspektów tworzenia portalu.

3.12.3 Dashboardsite

W ramach instalacji SharePoint Portal Server automatycznie tworzony jest portal WWW okreslan´ y mianem Dashboardsite. Uzytko˙ wnikom portalu WWW mozna˙ udostepni˛ c´ nastepuj˛ ace˛ funkcje:

◦ wyszukiwanie

◦ abonament nowych albo zmodyﬁkowanych tresci´

◦ sprawdzanie wpływajac˛ ych i wychodzac˛ ych dokumentów, wraz z numerami wersji

◦ publikowanie dokumentów

Do organizacji i wyswietlania´ informacji Dashboardsite wykorzystuje technologie˛ Digital Dash- board ﬁrmy Microsoft. Digital Dashboard składa sie˛ z tak zwanych Web Parts, które wewnatrz˛ portalu moga˛ przedstawiac´ informacje z zewnetrzn˛ ych i z wewnetrzn˛ ych zródeł.´ Do zewnetrz-˛ nych zródeł´ tresci´ mozna˙ zaliczyc´ inne obszary robocze SharePoint Portal Server, strony intranetowe albo internetowe, hierarchie publicznych katalogów Microsoft Exchange 2000 i Exchange Server 5.5, bazy danych Lotus Notes, lokalne systemy plików oraz sieciowe serwery plików. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 213

Web Parts mozna˙ rozwijac´ samemu albo nabywac´ u innych producentów. Istnieja˛ jednak takze˙ standardowe Web Parts, na przykład słuz˙ace˛ integracji wyjscia´ i wyjscia´ poczty Outlooka, kalendarza i terminów. Dzieki˛ właczeniu˛ Web Parts innych producentów mozna˙ poprzez portal stworzyc´ dostep˛ do kolejnych systemów informacyjnych (SAP, system CAD, system archiwizacji, itd.). Wewnatrz˛ portalu istnieje mozliwo˙ s´c´ przyporzadko˛ wania informacji i dokumentów do po- szczególnych kategorii. Kategorie z kolei moga˛ miec´ hierarchiczna˛ budowe.˛ Wewnatrz˛ Digital Dashboard pojedynczy uzytko˙ wnik moze˙ sterowac´ sposobem uporzadko-˛ wania i prezentacji Web Parts. Dostep˛ do Dashboardsite moze˙ byc´ realizowany z poziomu przegladarki˛ internetowej, np. Microsoft Internet Explorer albo Netscape Navigator. Aby Dashboard- site mogła działac´ w przegladarce˛ WWW musi byc´ właczon˛ y Microsoft JScript albo Netscape Java Script.

Rysunek 3.26: Architektura SharePoint Portal Server

3.12.4 System Zarzadzanie˛ Dokumentami (DMS)

Kolejnym wazn˙ ym elementem SharePoint Portal Server sa˛ zintegrowane funkcjonalnosci´ DMS. Oferowane sa˛ nastepuj˛ ace˛ standardowe funkcje:

45Zródło:´ Einführung in Microsoft SharePoint Portal Server 2001 – Whitepaper März 2001 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 214

◦ zarzadzanie˛ dokumentami

◦ zarzadzanie˛ wersja˛

◦ zezwolenie Workﬂow

◦ sprawdzanie na wejsciu´ i wyjsciu´

◦ proﬁle dokumentów i publikowanie dokumentów

◦ abonamenty.

Edycja dokumentów i zarzadzanie˛ nimi (sprawdzanie na wejsciu´ i wyjsciu)´ sa˛ całkowicie zintegrowane z Microsoft - Ofﬁce - Suite. SharePoint Portal Server oferuje takze˙ mozliwo˙ s´c´ hierarchicznego składowania dokumentów. Odwzorowanie hierarchii odbywa sie˛ z jednej strony w portalu opartym na przegladarce˛ WWW a z drugiej strony poprzez Windows Explorer za pomoca˛ tak zwanych katalogów WWW. Obsługiwane jest równiez˙ tak zwane przekazywanie zezwolen´ dla nowych wersji dokumentów. Dopiero po sprawdzeniu i udostepnieniu˛ nastepuje˛ opublikowanie wersji.

3.12.5 Funkcje wyszukiwania

SharePoint Portal Server oferuje funkcje˛ wyszukiwania dla wszystkich informacji i dokumen- tów w portalu. Indeks wyszukiwarki moze˙ obejmowac´ rózne˙ zródła´ wiedzy (wewnetrzne˛ i zewnetrzne˛ tresci),´ które moga˛ byc´ udostepniane˛ uzytko˙ wnikom w trybie wyszukiwania pełnego tekstu. Uzytko˙ wnikom oferowana jest takze˙ mozliwo˙ sć´ wyszukiwania atrybutowego (profile do- kumentów). Uzytko˙ wnikom pokazywane sa˛ tylko dokumenty z listy trafien,´ do których zalogowany uzytko˙ wnik posiada prawa dostepu.˛ Naznaczanie dokumentów nastepuje˛ poprzez tak zwana IFilter (Index Filter). Jesli´ dokument zostanie nadesłany albo dodane zostana˛zewnetrzne˛ zródła´ tresci,´ wówczas serwer automatycznie rozpozna typ dokumentu i uruchomi odpowiedni IFiltr. Filtry zapewniaja˛ rozpakowanie tresci´ dokumentu, które moga˛byc´ nastepnie˛ dodane do indeksu pełnotekstowego. Obecnie dostepne˛ sa˛ IFiltry m.in. dla formatów DOC, XSL, XML, RTF, PDF, MP3 i ZIP.

3.12.6 Wnioski

Przed wprowadzeniem efektywnej platformy intranetowej na obszarze przedsiebiorstwa˛ konieczna jest rozległa analiza stanu faktycznego i stanu oczekiwanego. Podczas zakładania portalu przedsiebiorstwa˛ bad˛ z´ portalu pracowników niezbedn˛ y jest dokładny, szczegółowy plan. Tylko portale, ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 215

które sa˛ dostosowane do potrzeb pracowników i przedsiebiorstwa˛ bed˛ a˛ nowa˛ platforma˛ dobrze spełniajac˛ a˛ swoje zadanie. Z reguły istniejac˛ ym wymaganiom mozna˙ sprostac´ korzystajac˛ z odpowiednich rozwiaza˛ n´ portalowych (wraz z Content Management albo z systemami zarzadzania˛ dokumentami). Jed- nak nie nalezy˙ zakładac,´ ze˙ powyzsze˙ rozwiazania˛ - dotyczy to takze˙ SharePoint Portal Server - stanowia˛ tak zwane rozwiazanie˛ Out of th Box. Wszystkie systemy nalezy˙ w mniejszym lub wiekszym˛ stopniu dostosowac´ do wczesniej´ zdeﬁniowanych wymagan.´ W zalezno˙ sci´ od oczekiwanych celów moze˙ byc´ konieczne wykonanie obszernych prac programistycznych. Aby wprowadzic´ SharePoint Portal Server potrzeba, tak samo jak w przypadku wprowadzania skomplikowanych rozwiaza˛ n´ archiwistycznych i Workﬂow, duzej˙ kompetencji jesli´ chodzi o analize˛ i kształtowanie procesów biznesowych. W oparciu o wyniki obszernej analizy wymagan´ mozna˙ stwierdzic,´ ze˙ SharePoint Portal Se- rver moze˙ byc´ jak najbardziej brany pod uwage˛ jako mozliwe˙ rozwiazanie.˛

3.13 Bazy danych

3.13.1 Przeglad˛

Ocena techniczna migracji baz danych pokazuje, ze˙ oprócz kontynuacyjnego produktu Micro- soft, którym jest MS SQL Server 2000 korzystac´ mozna˙ z alternatywnych, jak najbardziej adekwatnych odpowiedników bed˛ ac˛ ych rozwiazaniami˛ OSS, co usprawiedliwia przeprowadzenie migracji zastepuj˛ acej.˛ Wazn˙ ymi przedstawicielami rozwiaza˛ n´ OSS sa˛ MySQL, PostgreSQL, Fi- rebird oraz SAP DB. Oprócz tego dostepne˛ sa˛ takze˙ produkty komercyjne, takie jak Oracle i DB2, które równiez˙ były juz˙ wielokrotnie wykorzystywane w urzedach˛ i w zwiazku˛ z tym nie zostały przedstawiane w ponizszej˙ ocenie technicznej. Wymienione rozwiazania˛ OSS oferuja˛rózne˙ funkcjonalnosci,´ dlatego ich przydatnos´c´ nalezy˙ sprawdzac´ pod katem˛ wymagan´ w poszczególnym przypadku. Nalezy˙ podkresli´ c,´ ze˙ wszystkie w/w rozwiazania˛ OSS sa˛ niezalezne˙ od platformy i ze˙ istnieja˛ takze˙ ich wersje windowsowe, które mozna˙ pobrac´ z Internetu. Dlatego niniejsze systemy bazodanowe moga˛ byc´ zastosowane takze˙ w przypadku migracji punktowej.

3.13.2 Wprowadzenie

Do utrzymywania, zarzadzania˛ i zapisywania duzych˙ ilosci´ danych wykorzystuje sie˛ systemy bazodanowe. Systemy bazodanowe zapisuja˛ powiazane˛ ze soba˛ elementy w formularzu danych, ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 216

wzglednie˛ w pogrupowanych wierszach. Pomiedzy˛ tymi strukturami a grupami moga˛ istniec´ zdefiniowane relacje. dzieki˛ zastosowaniu dobrze zaplanowanej i ustrukturyzowanej bazy danych mozna˙ unikna˛c´ nadmiaru danych. Dane z systemu bazodanowego nie sa˛ z reguły bezposrednio´ udostepniane˛ uzytko˙ wnikom. Dostep˛ do nich odbywa sie˛ za posrednictwem´ aplikacji, która odwołuje sie˛ do danych i oferuje je uzytko˙ wnikom w odpowiedniej formie. Aby było to mozliwe˙ musza˛ istniec´ interfejsy pomiedzy˛ systemem bazodanowym a aplikacja.˛ Własciwy´ składnik komunikacyjny zapewnia połaczenie˛ pomiedzy˛ systemami klienckimi i serwerowymi. Aplikacje, które wykonywane sa˛ na systemach klienckich, moga˛ odwoływac´ sie˛ do serwera bazy danych poprzez siec.´ Serwery bazy danych musza˛byc´ w stanie obsługiwac´ wieksz˛ a˛ilosć´ równoległych zapytan´ klienckich. Zadanie serwera polega wówczas na unikaniu problemów logicznych podczas równoległego dostepu˛ systemów klienckich do odczytu i zapisu. Bazy danych składaja˛ sie˛ z reguły z dwóch składników, własciwej´ fizycznej bazy danych oraz z systemu zarzadzania˛ baza˛ danych (DBMS). DBMS spełnia m.in. nastepuj˛ ace˛ zadania:

◦ kontroluje relacje pomiedzy˛ danymi wewnatrz˛ bazy danych

◦ sprawdza i zapewnia prawidłowe zapisywanie danych, ze szczególnym uwzglednieniem˛ zdeﬁniowanych reguł relacji miedzy˛ danymi

◦ odtwarza stałe dane w przypadku błedu˛ systemu albo podobnych zdarzen´

DBMS deﬁniuje takze˙ instrukcje i aplikacje, których trzeba uzy˙ c,´ aby móc pracowac´ z danymi w bazie danych. Najcze˛sciej´ wykorzystywanym jezykiem˛ w systemach bazodanowych jest Struc- tured Query Language (SQL).

3.13.3 MS SQL Server 7.0

Microsoft SQL Server jest relacyjna˛ baza˛ danych Client - Server oparta˛ na SQL. Ten system bazodanowy składa sie˛ z własciwe´ go miejsca zapisu danych i systemu zarzadzania˛ baza˛ danych (DBMS).

3.13.3.1 Architektura serwera

Serwer jest składnikiem MS SQL Server, który przyjmuje instrukcje SQL od klientów i wykonuje odpowiednie akcje. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 217

Polecenia SQL przesyłane sa˛ na poziomie aplikacji z kazde˙ go systemu klienckiego za pomoca˛ protokołu . Poziom ten jest specyﬁczny dla MS SQL Server i okreslan´ y jako Tabular Data Stream (TDS). Obsługiwane sa˛wersje 4.2 i 7.0. Kazdy˙ pakiet tworzony jest dla MS SQL Server przez OLE DB - Provider i sterownik ODBC. Pakiety TDS przesyłane sa˛do serwera bad˛ z´ w kierunku odwrotnym do klienta, za pomoca˛ wykorzystywanego protokołu sieciowego. Open Data Service z MS SQL Server zarzadza˛ pakietami danych i wywołuje odpowiednie funkcje w MS SQL Server.

Rysunek 3.27: Architektura serwera MS SQL Server ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 218

Własciwy´ serwer bazy danych składa sie˛ z dwóch głównych składników, relacyjnego modułu i modułu zapisywania. Obydwa moduły komunikuja˛ sie˛ ze soba˛ poprzez API OLE DB. Funkcje relacyjnego modułu polegaja˛ na analizie polecen´ SQL, optymalizacji planu wykonania oraz wykonywaniu operacji z planu wykonania. Moduł zapisywania spełnia nastepuj˛ ace˛ zadania:

◦ zarzadza˛ plikami i miejscem przeznaczonym do zapisu

◦ zarzadza˛ buforami danych i operacjami wejscia´ / wyjscia´

◦ zarzadza˛ transakcjami i stosowaniem blokad

◦ protokołuje i odtwarza dane

◦ implementuje funkcje usługowe (BACKUP, RESTORE, DBCC oraz masowe kopiowanie).

3.13.3.2 Architektura bazy danych

Tworzenie struktury danych w bazie danych odbywa sie˛ wewnatrz˛ logicznych składników, które z kolei zapisywane sa˛ ﬁzycznie, w formie plików na nosniku´ danych. Podczas pracy z baza˛ danych uzytko˙ wnik bedzie˛ uzywał˙ w pierwszym rzedzie˛ logicznych składników (tablic, Views, Stored Procedures, itd.). Kazda˙ instalacja MS SQL Server udostepnia˛ wiele baz danych. Łacznie˛ istnieja˛cztery systemowe bazy danych i jedna albo wiecej˛ baza danych uzytko˙ wników. Oprócz w/w systemowych baz danych, po instalacji nalezy˙ załozy˙ c´ własciwe´ bazy danych zawartosci.´ Te produkcyjne bazy danych zorganizowane sa˛ w formie rózn˙ ych obiektów. W ponizszej˙ tabeli wymienione zostały najwazniejsze˙ składniki dostepne˛ w MS SQL Server jako obiekty.

SKŁADNIKI WYJAS´ NIENIE Własciwe´ dane bazy danych zapisywane sa˛ w tablicach. Tablice składaja˛ sie˛ z kolumn i wierszy. Wiersze zawieraja˛ kazdorazo˙ we tablice zestawy danych. Dla kolumn mozna˙ ustalac´ typy danych. Defi- niuja˛ one rodzaj danych zapisywanych w kolumnach. typy danych zdefinio- Oprócz typów podstawowych danych serwera MS SQL uzytko˙ w- wane przez uzytko˙ w- nicy moga˛zakładac´ typy danych definiowane przez uzytko˙ wnika. nika ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 219

Widoki sa˛ warstwami zdeﬁniowanymi dla wirtualnej tablicy albo zapisanego zapytania. W bazie danych zapisane sa˛ polecenia SE- LECT, których wynik tworzy tres´c´ wirtualnej tablicy. Widoki peł- nia˛ nastepuj˛ ace˛ funkcje:

◦ Views ograniczaja˛ uzytko˙ wnikom prawa dostepu˛ do okreslon´ ych wierszy albo kolumn w tablicy.

◦ w powiazan˛ y sposób prezentuja˛ kolumny z wielu tablic.

◦ łacz˛ a˛ informacje.

Sa˛ grupa˛ polecen´ Transact - SQL, która skompilowana została pod katem˛ jednego planu wykonania. Stored Procedures pełnia˛ m.in. nastepuj˛ ace˛ funkcje:

◦ implementuja˛ wychodzac˛ a˛ poza ramy program logike˛ programu w celu wykonywania czesto˛ powtarzajac˛ ych sie˛ za- Stored Procedures dan.´

◦ zwiekszaj˛ a˛ wydajnos´c,´ skompilowane Stored Procedures przechowywane sa˛ w Cache.

◦ moga˛ zapobiegac´ dostepo˛ wi do tablic po stronie uzytko˙ w- nika.

Udostepniaj˛ a˛proces zapewnienia integracji bazy danych. Ograni- ograniczenia czenia definiuja˛ reguły pod katem˛ dopuszczalnych wartosci´ wewnatrz˛ kolumny. Zapewniaja˛ kompatybilnosć´ zwrotna,˛ cze˛scio´ wo pełnia˛ te same reguły funkcje, jak ograniczenia CHECK. Słuz˙a˛ do ograniczania wartosci´ w kolumnie. Podaja˛ wartosci,´ które uzywane˙ sa˛ w kolumnie, gdy podczas wartosci´ domyslne´ wstawiania wiersza danych, w kolumnie nie została podana war- tosć.´ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 220

Odpowiadaja˛ szczególnej formie Stored Procedures, sa˛ automa- Trigger tycznie wykonywane, gdy tylko dla tablicy zdeﬁniowane zostało polecenie UPDATE, INSERT albo DELETE. Indeks, który zwiazan˛ y jest z tablica˛ i przyspiesza odpytywanie indeksy tablic wierszy.

Tablica 3.34: Składniki dostepne˛ na serwerze MS SQL jako obiekty

3.13.3.3 Składniki klienckie

Uzytko˙ wnik nie ma bezposrednie´ go dostepu˛ do Microsoft SQL Server. Aby uzyskac´ dostep˛ do danych, nalezy˙ zastosowac´ specjalne aplikacje. Moga˛ to byc:´

◦ programy usługowe serwera MS SQL

◦ programy innych producentów oraz

◦ własne programy stworzone na wewnetrzn˛ y uzytek˙ urzedu.˛

Dostep˛ do MS SQL Server odbywa sie˛ za posrednictwem´ API (Application Programming Inter- face) baz danych składajace˛ go sie˛ z dwóch cze˛sci:´ polecen´ jezyka˛ programowania, które musza˛ byc´ przekazane do bazy danych i zestawu funkcji albo interfejsów zorientowanych obiektowo oraz metod wysyłajac˛ ych instrukcje jezyka˛ programowania do bazy danych i przetwarzajac˛ ych wyniki. Polecen´ jezyka˛ programowania uzywa˙ MS SQL Server Transact - SQL. Obsługiwane sa˛ wszystkie instrukcje Entry Levels z SQL 92 i inne SQL - 92 Features (z Intermediate Level oraz Full Level). Ponadto istnieja˛ jeszcze rozszerzenia Transact - SQL, specyﬁczne dla Microsoftu. MS SQL Server obsługuje dwie główne klasy API baz danych:

◦ OLE DB - Provider wchodzac˛ y w skład systemu obsługuje aplikacje, które zostały napisane z wykorzystaniem OLE DB albo APIs, które uzywaj˙ a˛ OLE DB (np. ActiveX Data Objects (ADO)). Ponadto obsługiwane sa˛obiekty i składniki, które uzywaj˙ a˛OLE DB (np. ActiveX i windowsowe aplikacje DAN).

◦ ODBC - sterownik ten obsługuje aplikacje i składniki, które napisane zostały z wykorzystaniem ODBC.

MS SQL Server obsługuje dodatkowo DB - Library oraz Embedded SQL. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 221

3.13.3.4 Składniki komunikacyjne

Obsługiwanych jest wiele metod komunikacji pomiedzy˛ aplikacjami klienckimi a serwerem. W przypadku komunikacji na jednym komputerze, pomiedzy˛ serwerem a aplikacja˛ nalezy˙ zastosowac´ technologie ponadprocesowe, np. Named Pipes albo Shared Memory. Aplikacje, które pracuja˛ na innym systemie klienckim, uzywaj˙ a˛ sieciowej Interprocess Communication (IPC). IPC oparta jest na API i protokołach sieciowych. Korzystac´ mozna˙ z nastepuj˛ ac˛ ych protokołów:

◦ TCP / IP

◦ Novell IPX / SPX

◦ AppleTalk

◦ Banyan VINES.

3.13.3.5 Skalowalnos´c´

Microsoft SQL Server jest przystosowany do zarzadzania˛ bazami danych, które moga˛ miec´ rozmiar jednego terabajta albo wiekszy˛ . MS SQL Server posiada kilka Features, które zwiekszaj˛ a˛ wydajnosć´ systemu bazodanowego. System bazodanowy obsługuje takze˙ srodo´ wiska VLDB (Very Large Database). Rozmiar baz danych moze˙ wynosic´ jeden terabajt albo wiecej.˛ Za pomoca˛ polecen´ Transact - SQL, takich jak BACKUP i RESTORE mozna˙ zabezpieczac´ dane na wielu mediach oraz tworzyc´ przyrostowe kopie bezpieczenstwa.´ W celu przyspieszenia obsługi zapytan´ z serwerem MS SQL zintegrowany został optyma- lizator zapytan.´ Aby zapewnic´ podział polecen´ SQL dla maszyn wieloprocesorowych, mozna˙ tworzyc´ równoległe plany wykonywania. Serwer MS SQL obsługuje dzielone zapytania. Istnieje mozliwo˙ sć´ wykonywania polecen´ Transact - SQL, które odnosza˛ sie˛ do heterogenicznych zródeł´ danych OLE DB. Podczas wykonywania aktualizacji (zmian), integralnosć´ danych zapewniona jest dzieki˛ temu, ze˙ aktualizacje zawsze koncz´ a˛ sie˛ stałym stanem. Jesli´ nie zostanie on osiagni˛ ety˛ , wówczas nastepuje˛ Rollback i przejscie´ do punktu wyjscia,´ tzn. do poprzedniego stałego stanu. Ponadto mozliwe˙ sa˛ dzielone transakcje. Zarzadzanie˛ transakcjami odbywa sie˛ przy tym za pomoca˛ menedzera˙ transakcji. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 222

3.13.3.6 Nadawanie praw dostepu˛

Serwer MS SQL oferuje dwa rodzaje autoryzacji uzytko˙ wników:

◦ autoryzacja serwera SQL W serwerze MS SQL musza˛ istniec´ odpowiednie konta logowania oraz hasła – nie sa˛ one zwiazane˛ z kontami uzytko˙ wników NT. Logowanie i odpytywanie hasła odbywa sie˛ bezposrednio´ na serwerze SQL.

◦ autoryzacja Windows NT Konta oraz grupy Windows NT nalezy˙ właczy˛ c´ do serwera MS SQL, jednak własciwa´ autoryzacja odbywa sie˛ w domenie NT.

Administrator moze˙ ustalic,´ czy autoryzacja ma sie˛ odbywac´ poprzez Windows NT, czy w trybie mieszanym.

3.13.3.7 Integracja systemu

Serwer MS SQL obsługuje stosowanie uzytko˙ wników Windows NT oraz kont domen. Tym samym dla serwera MS SQL dostepna˛ jest autoryzacja Windows NT. Uzytko˙ wnicy nie sa˛ autory- zowani przez serwer MS SQL. Udostepnia˛ on systemom klienckim zaufane połaczenie.˛ Oprócz integracji autoryzacji uzytko˙ wników NT, serwer MS SQL moze˙ byc´ sci´ sle´ zwiazan˛ y z nastepuj˛ ac˛ ymi usługami:

◦ zapisywanie danych dla Microsoft Internet Information Server, który jest z reguły wykorzystywany do generowania dynamicznych tresci´ WWW opartych na ASP.

◦ zapisywanie danych dla Sites Server, który wykorzystywany jest do zarzadzania˛ stronami WWW.

3.13.3.8 Administrowanie

Do administrowania serwerem MS SQL dostepn˛ ych jest wiele narzedzi:˛

◦ MS SQL Server - Agent umozliwia˙ tworzenie i planowanie zadan,´ które maja˛ byc´ wykonywane jednorazowo albo okresowo. Moga˛ to byc´ ostrzezenia˙ dla administratora w przypadku wystapienia˛ okreslo-´ nych zdarzen´ w systemie. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 223

◦ MS SQL Server Proﬁler umozliwia˙ kontrole˛ oraz analize˛ obcia˛zenia˙ sieci podczas transmisji z serwera i do serwera.

◦ Monitor systemowy serwera MS SQL umozliwia˙ właczenie˛ sie˛ w system monitorowania Windows NT słuz˙ac˛ y do kontroli serwera MS SQL oraz graﬁczna˛ prezentacje.˛

◦ MS SQL Server Enterprise Manager udostepnia˛ Snap - In dla Microsoft Management Console (MMC) w celu umozliwienia˙ zarzadzania˛ serwerem MS SQL.

◦ Asystent optymalizacji indeksu umozliwia˙ analize˛ z wykorzystaniem indeksów polecen´ SQL.

Za pomoca˛ SQL Distributed Management Objects (SQL - DMO) istnieje dodatkowo mozliwo˙ s´c´ właczenia,˛ w ramach aplikacji, zadan´ automatyzujac˛ ych. Zadania powtarzajace˛ sie˛ mozna˙ takze˙ zaimplementowac´ jako zlecenia.

3.13.4 Migracja zastepuj˛ aca˛

Bazy danych, a dokładniej relacyjne systemy zarzadzania˛ bazami danych (RDBMS) nalez˙a˛ do prekursorów zastosowan´ Linuksa w obszarach krytycznych dla przedsiebiorstwa.˛ Juz˙ w 1997 roku Software AG zaoferowała wraz z baza˛danych AdabasD w pełni komercyjny (w swoim czasie certyﬁkowany przez SAP) RDBMS dla Linuksa. W 1998 roku poda˛zyły˙ jej sladem´ Oracle oraz Informix, które w ten sposób wyraznie´ zwiekszyły˛ zaufanie do Linuksa w dziedzinie zastosowan´ profesjonalnych. Kombinacja Linuksa, Apache, MySQL i PHP znana pod akroni- mem LAMP jest, od poczatku˛ komercyjnego wykorzystywania Internetu, jedna˛ z najbardziej lubianych infrastruktur stosowanych do tworzenia sklepów internetowych i dynamicznych stron WWW. Wraz z PostgreSQL, Firebird oraz SAP DB udostepnion˛ y został, takze˙ na licencjach Wolnego Oprogramowania, cały szereg pełnowartoscio´ wych RDBMS obsługujac˛ ych transakcje, triggers oraz Stored Procedures. Jesli´ chodzi linuksowe oprogramowanie Open Source w obszarze baz danych z pewnosci´ a˛ nie brakuje wysokowartoscio´ wych opcji. RDBMS pełnia˛ w ramach strategii migracyjnej o tyle szczególna˛ role,˛ ze˙ zawsze zwiazane˛ sa˛ z aplikacja,˛ której dane zarzadzane˛ sa˛za pomoca˛RDBMS. Tym samym w przypadku zmiany trzeba z jednej strony zmienic´ zasoby danych a z drugiej prawdopodobnie takze˙ aplikacje. W idealnej sytuacji dane organizacji udostepniane˛ sa˛ w znormalizowanej formie (bez nadmiaru) tylko z jednego systemu bazodanowego, a jezyk˛ zapytan´ (SQL), którym aplikacje poro- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 224

zumiewaja˛ sie˛ z baza˛ danych, spełnia standardy. W idealnej sytuacji kazda˙ aplikacja bez proble- mów współpracuje z kazdym˙ RDBMS. Niestety w rzeczywistosci´ okazuje sie,˛ ze˙ w wiekszo˛ sci´ infrastruktur informatycznych trzeba zarzadza˛ c´ wieloma RDBMS z cze˛scio´ wo nadmierna˛ilosci´ a˛ danych zgromadzonych w rózn˙ ych bazach danych. Prowadzi to do tego, ze˙ zapytania o w/w dane kierowane i redagowane sa˛ z rózn˙ ych aplikacji i w rózn˙ ych dialektach SQL przy wykorzystaniu rozszerzen´ oraz interfejsów specyﬁcznych dla danego producenta. Nawet wtedy, gdy połaczenie˛ z baza˛ danych zestawione jest za pomoca˛ standardów ODBC albo JDBC i nie sa˛ uzywane˙ triggers ani Stored Procedures, nalezy˙ podczas migracji bazy danych wymienic´ po stronie klientów sterownik ODBC / JDBC. W odniesieniu do powyzsze˙ go migracja oferuje szanse˛ na konsolidacje˛ struktur oprogramowania i struktur danych, przy czym oczywiscie´ skorzystanie z niej nie jest proste. Niniejsze wstepne˛ przemyslenia´ pokazuja,˛ ze˙ rozwiazania˛ alternatywne dla migracji kontynuacyjnej istnieja˛ tylko w przypadkach, gdy:

◦ RDBMS pracujac˛ y obecnie pod kontrola˛ systemu Windows dostepn˛ y jest takze˙ dla systemu operacyjnego Open Source (np. Oracle dla Linuksa). W takim przypadku system bazodanowy pozostanie systemem komercyjnym. W infrastrukturze serwera opartej na Li- nuksie, z punktu widzenia administratora wynika z takiego wariantu wiele korzysci.´ Jesli´ chodzi o MS - SQL nie przewiduje sie˛ powstania wersji linuksowej.

◦ aplikacje powiazane˛ sa˛ z dotychczasowym RDBMS za pomoca˛ ODBC albo JDBC. W takim przypadku dane moze˙ przeja˛c´ inny system bazodanowy a połaczenia˛ z klientami mozna˙ przekierowac´ wymieniajac˛ sterownik ODBC (na poziomie systemu, na kliencie). Problem stanowia˛tu szczegóły. Jesli´ aplikacja współpracuje z Stored Procedures albo triggers, wówczas trzeba je równiez˙ przeportowac.´ (Mozna˙ to zrobic´ przy okazji, bez zmian w oprogramowaniu klienckim.)

◦ chodzi o aplikacje˛ MS Access przechowujac˛ a˛ dane w postaci plików. W takim przypadku mozna˙ w bardzo łatwy sposób właczy˛ c´ dane do centralnego DBMS i przestawic´ aplikacje˛ Access na interfejs ODBC.

◦ klient dostepn˛ y jest w postaci tekstu zródło´ wego i mozna˙ go dostosowac´ w ramach projektu migracyjnego do nowego RDBMS. Oprócz wymienionych juz˙ czynników (korzystanie z triggers i Stored Procedures), nakład zwiazan˛ y z migracja˛ zalezy˙ tu takze˙ od wykorzystywanych interfejsów programistycznych. Jesli´ połaczenie˛ z baza˛ danych zaimplementowane zostało bezposrednio´ poprzez interfejs producenta (np. wbudowany SQL), wówczas ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 225

nalezy˙ sie˛ liczyc´ ze znacznie wiekszym˛ nakładem, niz˙ w przypadku, gdy pomiedzy˛ wła-˛ czona została płaszczyzna abstrakcji, taka jak ActiveX Data Objects (ADO).

◦ Ostatecznie istnieje jeszcze mozliwo˙ sć´ współpracy z producentem aplikacji i przeprowadzenia migracji bazy danych w ten sposób. Trwałe zwiazanie˛ z okreslon´ ym RDBMS uzna- wane jest, takze˙ przez wielu producentów komercyjnych baz danych, za niekorzystne z punktu widzenia rynku, dlatego mozna˙ wyjsć´ z załozenia,˙ ze˙ gotowosć´ do migracji, szcze- gólnie do RDBMS wywodzace˛ go sie˛ z Open Source, rosnie´ i jest godna zauwazenia.˙

Gdy istnieje mozliwo˙ s´c´ przeprowadzenia migracji systemu bazodanowego, nalezy˙ wybrac´ do- celowy system RDBMS. Przy ocenie mozliwych˙ systemów docelowych w ramach niniejszego poradnika migracyjnego wzieli˛ smy´ pod uwage˛ przede wszystkim bazy danych Open Source. Ponizszy˙ przeglad˛ pokazuje systemy bazodanowe, które sa˛ aktualnie dostepne˛ na licencji Open Source:

BAZA DANYCH WERSJA LICEN- ZAPY- TRANS- STORED CJA TANIE AKCJE PROCS GDBM 1.8.3 GPL Hash www.gnu.org Berkeley DB 4.1.25 BSD Hash X www.sleepycat.com Type SHORE 1.1.1 BSD SDL / www.cs.wisc.edu/shore/ ODL ZOPE 2.6.1 Zope PL DTML www.zope.org mSQL 3.4 Hughes MSQL www.hughes.com.au MySQL 4.0.12 GPL SQL X www.mysql.com PostgreSQL 7.3.2 BSD SQL X (X) www.postgresql.org Firebird 1.5 Inter- SQL X X firebird.sourceforge.net Base PL SAP DB 7.4.03 GPL / SQL X X www.sapdb.org LGPL ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 226

Tablica 3.36: Systemy bazodanowe dostepne˛ na licencji Open Source

Systemy Hash nie sa˛ relacyjne. Jesli´ chodzi o migracje,˛ to w gre˛ wchodza˛ przede wszystkim cztery ostatnie systemy z interfejsem SQL. Ponizej˙ zamiescili´ smy´ charakterystyke˛ tych syste- mów.

3.13.4.1 MySQL

MySQL jest rozwijana i rozpowszechniana przez szwedzka˛ firme˛ o tej samej nazwie. Niniejsza baza danych jest udostepniana˛ na licencji GPL i tym samym jest Wolnym Oprogramowaniem. Poniewaz˙ równiez˙ interfejsy programistyczne udostepniane˛ sa˛ na licencji GPL, zlinkowane z nimi programy takze˙ musza˛ byc´ oparte na tej licencji, o ile sa˛ one rozpowszechniane bad˛ z´ rozprowadzane na zasadach komercyjnych. Alternatywnie MySQL AB oferuje równiez˙ licencje komercyjne, które umozliwiaj˙ a˛korzystanie z MySQL producentom aplikacji komercyjnych, bez wymogu udostepniania˛ przez nich swojego oprogramowania na licencji GPL. MySQL oferuje regularne umowy dotyczace˛ wsparcia i serwisu, szkolen´ oraz doradztwa. Producenci oceniaja˛ ilosć´ zainstalowanych baz danych MySQL na całym swiecie´ na 4 mi- liony. Z najwiekszym˛ powodzeniem jest ona wykorzystywana w połaczeniu˛ z Linuksem, Apache i PHP do tworzenia dynamicznych stron WWW. MySQL moze˙ słuzy˙ c´ do składowania danych z takim samym Frontend (parser SQL) na róz-˙ nych BackEnds. W przypadku wykorzystania innoDB jako BackEnd, MySQL obsługuje takze˙ transakcje. Obecnie MySQL nie oferuje Stored Procedures. Zgodnie z deklaracjami producenta bed˛ a˛ one dostepne˛ pocza˛wszy od wersji 5.0. Ponadto istnieje mozliwo˙ sć´ skompilowania MySQL z obsługa˛ OpenSSL – w takim przypadku klient i serwer komunikuja˛ sie˛ ze soba˛ za pomoca˛ protokołu Secure Socket Layers (SSL) wykorzystujac˛ certyfikaty X.509. W przypadku MySQL składowanie danych odbywa sie˛ zazwyczaj w systemie plików. Struk- tury danych zajmuja˛ przy tym tylko tyle miejsca na dysku, ile rzeczywiscie´ wymagane jest do zapisania tresci.´ Przydzielanie miejsca na dysku dla tablic czy bazy danych nie jest konieczne. Pojedynczy pracujac˛ y serwer bazy danych moze˙ zarzadza˛ c´ dowolna˛ ilosci´ a˛ instancji bazy danych. MySQL jest w sumie bardzo zgrabna i w przypadku kazde˙ go dostepu˛ do odczytu niesły- chanie szybka. Zazwyczaj wykorzystywana jest raczej w przypadku małych i srednich´ zasobów danych oraz dla lekkich aplikacji. Jednakze˙ lista referencji MySQL AB pokazuje, ze˙ ta baza ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 227

danych przeznaczona jest równiez˙ dla duzych˙ aplikacji i duzych˙ zasobów danych i ze˙ jak najbardziej moze˙ mierzyc´ sie˛ ze wszystkimi komercyjnymi systemami bazodanowymi.

3.13.4.2 PostgreSQL

Poczatki˛ PostgreSQL sie˛gaja˛ roku 1986, kiedy to na UCB powstała baza danych Postgres. Jest ona udostepniana˛ na licencji BSD. W 1995 roku odpytywanie bazy danych przestawiono na SQL. PostgreSQL rozwijany jest zgodnie z czysta˛ metoda˛ Open Source przez duz˙a˛ i rozproszona˛ po całym swiecie´ społecznosć.´ W zgodzie z modelem pracy społecznosci´ rózne˙ firmy oferuja˛ dla PostgreSQL swoje produkty i usługi. W przypadku PostgreSQL uzytko˙ wnik moze˙ definiowac´ własne funkcje w wielu rózn˙ ych jezykach˛ programowania, które moga˛ zwracac´ zarówno pojedyncze wartosci,´ jak tez˙ tupels albo nawet całe tablice. Funkcje te oferuje˛ róznorodne˙ mozliwo˙ sci´ w postaci procedur zdefiniowanych dla uzytko˙ wnika. Kolejnym szczególnym rozwiazaniem˛ jest wykorzystanie reguł sie˛gajac˛ ych poza triggers. Dzieki˛ szerokiemu procesowi rozwijania projektu przez społecznosć,´ PostgreSQL jest bardzo funkcjonalna i dopracowana pod katem˛ bezpieczenstwa.´ Wskutek tego PostgreSQL standardowo oferuje mocne szyfrowanie oraz autoryzacje,˛ jak tez˙ przepływ danych w oparciu o certyfikaty X.509. Dane z PostgreSQL przechowywane sa˛ w systemie plików. Alokacja połozenia˙ bazy danych albo tablic nie jest wymagana, istnieje takze˙ pózniejsza´ mozliwo˙ sć´ podziału na rózne˙ obszary zapisu. Serwer bazy danych moze˙ obsługiwac´ wiele instancji bazy danych. PostgreSQL wykorzystuje, podobnie jak Oracle, system podgladu,˛ który w przeciwienstwie´ do tradycyjnego Locking umozliwia˙ Locking bazy danych takze˙ w trakcie pracy przy duzym˙ Performance. Zabezpieczanie danych jest przy tym spójne. PostgreSQL jest jednoczesnie´ zgrabna i bardzo funkcjonalna. Zazwyczaj wykorzystywana jest dla zasobów danych sredniej´ wielkosci.´ Do wysoce zautomatyzowanego transportu danych z MS Access do PostgreSQL mozna˙ posłuzy˙ c´ sie˛ windowsowym narzedziem˛ administracyjnym tworzac˛ ym Wizard migracyjny dla bazy danych Access.

3.13.4.3 Firebird

Firebird powstał w połowie 2000 roku jako samodzielny projekt wywodzac˛ y sie˛ z bazy danych Interbase 6.0 udostepnionej˛ przez ﬁrme˛ Borland na zasadach Open Source. Nad rozwojem tego systemu bazodanowego pracuje mała zaangazo˙ wana społecznos´c.´ Najistotniejsza˛ dokumentacje˛ stanowia˛ pliki PDF przejete˛ po projekcie Interbase. Na razie nie wiadomo, kiedy nastapi˛ ich aktualizacja. W trakcie prac nad rozwojem bazy danych zlikwidowano kilka interfejsów, które ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 228

istnieja˛tylko w bazie danych Interbase. Obecnie Firebird nie moze˙ byc´ jeszcze brany pod uwage˛ jako RDBMS, jesli´ chodzi o zastosowania profesjonalne.

3.13.4.4 SAP DB

SAP DB jest uniwersyteckim projektem badawczym zapoczatko˛ wanym przez Politechnike˛ w Berlinie. Jego poczatki˛ sie˛gaja˛ az˙ roku 1977. W latach 80 - tych system był rozwijany i sprze- dawany przez firme˛ Nixdorf jako DDB/4. Nastepnie˛ został przekazany przez Siemens / Nixdorf do Software AG i był tam rozwijany jako ADABAS D. W 1997 roku firma SAP uzyskała od Software AG pełne prawo realizacji finansowej prawa autorskiego i od tego czasu prowadzi ona prace nad rozwojem projektu pod nazwa˛ SAP DB. W roku 2000 SAP udostepniła˛ w/w baze˛ danych na licencji GPL, jednak bez ograniczenia swoich nakładów przeznaczanych na rozwój projektu. SAP DB oferowana jest przez SAP jako certyfikowana platforma dla niemal wszystkich rozwiaza˛ n´ tej firmy i jest stosowana jako podstawowa technologia we własnych produktach. W zakresie funkcji mieszcza˛ sie˛ oprócz obsługi transakcji takze˙ wsparcie dla triggers oraz Stored Procedures. Główne starania zwiazane˛ z rozwojem, jak tez˙ z zapewnieniem jakosci´ podejmowane sa˛ pod katem˛ funkcjonalnosci´ zastosowan´ rozwiaza˛ n´ SAP. Poniewaz˙ cała logika biznesowa ma miejsce na serwerze aplikacji SAP, system bazodanowy jest w istotnym stopniu wykorzystywany do performantnego dostarczania i zabezpieczania relacyjnych danych. Stored Procedures nie maja˛ tu znaczenia. Z tego punktu widzenia SAP DB brakuje jeszcze wszechstronnosci´ i elastycznosci.´ Do przechowywania danych SAP DB uzywa˙ Volumens, które sa˛tworzone w systemie plików albo na Raw - Devices i które kazdorazo˙ wo w całosci´ alokowane sa˛ do instancji bazy danych. Baza danych jest reorganization - free i moze˙ byc´ zabezpieczana w trakcie pracy bez zakłócen´ Performance. SAP DB nalezy˙ wsród´ baz danych Open Source do wagi cie˛zkiej.˙ Moze˙ byc´ ona celem migracyjnym dla baz danych MS Access tylko w wyjatko˛ wych przypadkach.

3.13.4.5 Bilans posr´ edni

Jesli´ chodzi o Open Source, oferta alternatywnych celów migracyjnych jest róznorodna˙ i atrak- cyjna. Nie mozna˙ podja˛c´ ogólnej, prostej i jednoznacznej decyzji na korzys´c´ takiego lub innego systemu w oparciu o jego charakterystyczne cechy. Wszystkie opisane dotychczas systemy bazodanowe SQL sa˛niezalezne˙ od platformy. Wazne˙ jest, ze˙ wszystkie cztery dostepne˛ sa˛ w Internecie takze˙ w wersjach windowsowych. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 229

Przy szczegółowym porównaniu systemów docelowych, które mozna˙ wzia˛c´ pod uwage˛ w przypadku migracji, konieczne jest zapoznanie sie˛ z dokładnym porównaniem spisów Features przygotowanych pod katem˛ funkcjonalnosci´ faktycznie wykorzystywanych przez system bazodanowy. Dobre porównanie znajduje sie˛ na stronie: http://www.mysql.com/information/ features.html. Niektóre dodatkowe wskazówki zawiera nastepuj˛ aca˛ tabela:

LICENCJA GPL BSD BORLAND PL GPL Dokumentacja innych produ- X X (InterBase) n.a. centów TableSpace unlimited unlimited unlimited unlimited SSL / Network Trafﬁc En- X cryption Kerberos Authentication X ODBC X X X X JDBC X 2.0 3.0 Perl X X X PHP X X X Python X X X group / role concept X X Online Backup X X Backup przyrostowy X rozszerzenie DB space w via LVM via LVM via LVM X trakcie pracy Raw Devices (X) X Namespaces sheme.table owner. table

Tablica 3.38: Zestawienie systemów bazodanowych SQL

3.13.4.6 Wskazówki

Przy imporcie danych z typów danych, które nie sa˛ identyczne w systemie docelowym, istnieje z reguły mozliwo˙ s´c´ nadania odpowiedniemu typowi wieksze˛ go zakresu wartosci.´ Nalezy˙ jednak ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 230

zwrócic´ uwage,˛ zarówno podczas importu danych, jak i podczas przejscia´ na połaczenie˛ ODBC, aby interfejs ODBC posiadał własne rozwiazania˛ i deﬁnicje typów danych.

3.13.4.7 Zalecenia odnosnie´ niezalezno˙ sci´

Na wypadek, gdyby w danej chwili nie było mozliwo˙ sci´ przeprowadzenia migracji zastepuj˛ a-˛ cej, zamiescili´ smy´ ponizej˙ kilka zalecen´ co do sposobu programowania bazy danych, których przestrzeganie ułatwi przyszła˛ migracje.˛

◦ Nalezy˙ zrezygnowac´ z Stored Procedures i rozszerzen´ specyﬁcznych dla producenta. W przypadku, gdy istnieje potrzeba przemieszczenia logiki biznesowej lub funkcjonalnosci´ z klienta na serwer, efekt ten mozna˙ obecnie bardzo dobrze uzyskac´ wykorzystujac˛ 3 - warstwowe architektury. Odpowiednia˛implementacja˛niezalezn˙ a˛od platformy jest tu Java, zarówno dla klienta, jak i dla serwera aplikacji (Tomcat).

◦ Połaczenie˛ z baza˛ danych nalezy˙ zestawic´ za pomoca˛ standardowych interfejsów (ODBC, JDBC) albo nalezy˙ właczy˛ c´ poziom abstrakcji, który mozna,˙ opcjonalnie i bez koniecznosci´ wprowadzania zmian w kodzie programu, przestawic´ na ODBC, JDBC lub inne interfejsy.

◦ Nalezy˙ wyizolowac´ i zmodularyzowac´ Statements SQL w kodzie programu.

3.13.5 Migracja kontynuacyjna

3.13.5.1 Microsoft SQL Server 2000

Wraz z wersja˛MS SQL Server 2000 wprowadzone zostały nowe rozwiazania˛ dotyczace˛ zwłasz- cza funkcjonalnosci´ WWW. Główny punkt rozwoju dotyczył obsługi XML i poprawy skalowalnosci.´ W niniejszym podrozdziale wymienione zostały najwazniejsze˙ funkcjonalnosci.´

Internet i Intranet Najwazniejsze˙ rozszerzenia MS SQL Server 2000 z zakresu rozwiaza˛ n´ internetowych i intranetowych umiescili´ smy´ w ponizszej˙ tabeli.46

FUNKCJA

46Rozszerzone funkcjonalnosci´ Enterprise Edition nie zostały wymienione i mozna˙ o nich poczytac´ w White Papers oraz odpowiednich opisach technicznych. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 231

◦ Obsługa XML, Xpath, XSL oraz HTTP:

◦ Wyswietlanie´ i dostep˛ do relacyjnych danych poprzez zastosowanie widoków XML.

◦ Dostep˛ przez URL i HTTP do danych w Internecie. XML Do generowania zapytan´ mozna˙ wstawic´ szablony w SQL, XML albo Xpath w URLs.

◦ Zwracane moga˛ byc´ wyniki zapytania SELECT w formie XML.

◦ Dokumenty XML moga˛ byc´ edytowane za pomoca˛ Transact - SQL i Stored Procedures.

Umozliwia˙ analize˛ relacyjnych danych i danych OLAP zintegrowany Data- („Online Analytical Processing“) w celu analizowania tren- mining dów i prognoz. obsługa instancji Hosting oddzielnych instancji bazy danych dla aplikacji multiplen albo klientów. bezpieczenstwo´ Obsługa połaczenia˛ SSL i Kerberos

Tablica 3.40: Rozszerzone rozwiazania˛ internetowe i intranetowe obsługiwane przez MS SQL Serwer 2000

Zarzadzanie˛ i rozwój W ponizszej˙ tabeli pokazane zostały najwazniejsze˙ nowosci´ zwiazane˛ z zarzadzaniem˛ i opcjami programowania Microsoft SQL Server 2000.

FUNKCJONALNOS´ CI integracja Active Di- Integracja centralnej usługi katalogowej MS rectory ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 232

Przesuwanie i kopiowanie baz danych i obiektów pomie-˛ asystent kopiowania dzy serwerami. Data Transformation Services umozliwiaj˙ a˛ baz danych i DTS import i eksport kluczy głównych i obcych pomiedzy˛ ob- sługiwanymi produktami bazodanowymi. zdeﬁniowane przez Tworzenie funkcji Transact - SQL wielokrotnego uzytku.˙ uzytko˙ wnika funkcje Zamiast albo po procesie rozszerzone triggers do wykony- oraz nowe triggers wania kodu. Mozna˙ uzywa˙ c´ nowych typów danych (bigint, sql_variant, table) i mozna˙ deﬁniowac´ indeksy w typach kolumn, gdy typy danych, indeksy i dane w kolumnach obliczane sa˛ z innych kolumn. Na po- sortowania ziomie kolumn mozliwe˙ jest sortowanie. Umozliwia˙ to zapisywanie obiektów, które charakteryzuja˛rózne˙ zasady sortowania w tej samej bazie danych. Analysis Services umozliwia˙ rozwijanie rozwiaza˛ n´ OLAP - Analysis Services, wir- Datawarehousing i Datamining. Ich edycje˛ umozliwia˙ edy- tualne Cubes oraz gene- tor wirtualnych Cubes. Za pomoca˛generatora MDX mozna˙ rator MDX tworzyc´ wyrazenia˙ wielowymiarowe.

3.14 Groupware

3.14.1 Przeglad˛

W centrum technicznej oceny migracji usług Groupware i Messaging znajduje sie˛ zarówno zastapienie˛ funkcjonalnosci´ Exchange 5.5 za pomoca˛ rozwiaza˛ n´ alternatywnych, które moga˛ byc´ stosowane w systemach opartych na Linuksie, jak tez˙ kontynuacja z wykorzystaniem Exchange 2000. Jesli´ chodzi o migracje˛ zastepuj˛ ac˛ a,˛ głównym aspektem oceny technicznej jest wykorzystanie heterogenicznych srodo´ wisk systemowych składajac˛ ych sie˛ z linuksowych serwerów i z windowsowych klientów przy dalszym, pełnym zastosowaniu MS Outlook. W wyniku rozwaza˙ n´ dwa z ocenianych rozwiaza˛ n´ okazały sie˛ byc´ szczególnie własciwe,´ gdyz˙ w duzym˙ stopniu spełniaja˛ one wymóg połaczenia˛ w czasie rzeczywistym. Za pomoca˛ połaczenia˛ w czasie rzeczywistym mozna˙ bezkonﬂiktowo korzystac´ z funkcjonalnosci´ grup. W przypadku obydwu rozwiaza˛ n´ chodzi z jednej strony o Samsung Contact bed˛ ac˛ y komercyjnym rozwiazaniem˛ opartym na HPOpenMail, a z drugiej strony o Exchange4Linux. Ten ostatni jest rozwiazaniem˛ złozon˙ ym ze składnika serwera, który jest Wolnym Oprogramowaniem i własci-´ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 233

cielskiego Outlook - Connector, który dostepn˛ y jest jako komercyjny moduł oprogramowania. Exchange4Linux obsłuzy˙ maksymalnie do 500 uzytko˙ wników, jest zatem przeznaczony raczej dla mniejszych urzedów˛ . Samsung Contact nadaje sie˛ zwłaszcza do zastosowan´ w srednich´ i duzych˙ urzedach.˛ Oprócz tego istnieje jeszcze rozwiazanie˛ OSS o nazwie Kroupware, które mozna˙ połaczy˛ c´ z MS Outlook za pomoca˛ komercyjnego Bynari - connector. Dla Kroupware istnieje obecnie ograniczenie polegajace˛ na tym, ze˙ nie ma wystarczajac˛ ych, rzeczywiscie´ roboczych doswiadcze´ n.´ Tam, gdzie nie jest wymagane połaczenie˛ w czasie rzeczywistym, mozna˙ zastosowac´ komercyjny produkt OpenExchange ﬁrmy SuSE. Ponadto przez połaczenie˛ w czasie rzeczywistym mozliwe˙ jest daleko idace˛ zastapienie˛ funkcjonalnosci´ Exchange 5.5. Jedyny wyjatek˛ stanowi tu korzystanie z formularzy, które nie jest mozliwe˙ w przypadku rozpatrywanych rozwiaza˛ n.´ Oprócz zastosowan´ w srodo´ wiskach heterogenicznych, wazn˙ a˛ role˛ odgrywaja˛ takze˙ moz-˙ liwe rozwiazania˛ dla srodo´ wiska czysto linuksowego oraz pytanie o pocztowe oprogramowanie klienckie alternatywne dla MS Outlook. W tym przypadku tylko Samsung Contact udostepnia˛ zintegrowanego klienta, opartego na Java i niezalezne˙ go od platformy. Oprócz tego, w przypadku wszystkich ocenianych rozwiaza˛ n,´ istnieja˛jeszcze klienty WWW, których jednak mozna˙ uzywa˙ c´ z wiekszymi˛ bad˛ z´ mniejszymi funkcjonalnymi ograniczeniami. Nie jest mozliwe˙ korzystanie z nich w trybie ofﬂine. Jednakze˙ z funkcjonalnosci´ poczty korzystac´ mozna˙ za pomoca˛wszystkich klientów obsługujac˛ ych POP3 i IMAP. Jesli´ chodzi o migracje˛ kontynuacyjna˛ do MS Exchange 2000, nalezy˙ przyja˛c,´ ze˙ rozwiaza-˛ nie to mozliwe˙ jest tylko w połaczeniu˛ z zastosowaniem Active Directory. Chodzi przy tym o zasadnicza,˛ strategiczna˛ decyzje,˛ o której pisalismy´ juz˙ w ocenie rozwiaza˛ n´ opartych na AD w rozdziale 3.7.

3.14.2 Wprowadzenie

Zgodnie z tym, co napisalismy´ w rozdziale 2, nalezy˙ załozy˙ c,´ ze˙ w wiekszo˛ sci´ urzedów˛ stosowanym rozwiazaniem˛ Groupware jest Exchange. Dlatego najpierw opisalismy´ punkt wyjscia´ i rozpatrzylismy´ rózne˙ rozwiazania˛ Groupware dla migracji zastepuj˛ acej,˛ które mozna˙ zastosowac´ w linuksowych systemach operacyjnych. Ocenilismy´ zarówno czyste projekty Open Source, jak i produkty komercyjne. Produkty te słuz˙a˛ cze˛scio´ wo rózn˙ ym punktom wyjscia,´ celom i grupom celów. Zasadniczo mozna˙ jednak z góry odrózni˙ c´ czyste rozwiazania˛ klient - serwer oparte na WWW od klasycznych rozwiaza˛ n´ klient - serwer. Ze wzgledu˛ na duz˙a˛ ilos´c´ rózne˙ go oprogramowania nie mozna˙ ocenic´ wszystkich rozwiaza˛ n,´ które sa˛ dostepne˛ na rynku. Rozpatrywane ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 234

rozwiazania˛ wybrane zostały w oparciu o rózne˙ scenariusze wymagan.´ Jesli´ chodzi o migracje˛ kontynuacyjna˛ ocenilismy´ MS Exchange 2000 oraz w niektórych punktach takze˙ MS Exchange 2003.

3.14.3 Punkt wyjscia´ - Microsoft Exchange 5.5

W tym miejscu przedstawione zostały najwazniejsze˙ cechy i funkcjonalnosci´ rozwiazania˛ Gro- upware ﬁrmy Microsoft pod katem˛ wersji 5.5.

3.14.3.1 Infrastruktura podstawowa

Microsoft Exchange Server wymaga, jako podstawy, struktury domen Windows NT 4, która głównie wykorzystywana jest do autoryzacji.

3.14.3.2 Logiczne jednostki struktury

Najwieksz˛ a˛ jednostka˛ struktury Microsoft Exchange Server jest organizacja. Organizacja moze˙ rozciaga˛ c´ sie˛ na wiele domen NT. Ponadto do ustalania struktury w Exchange wykorzystywane sa˛ punkty centralne (Sites). W jednym punkcie centralnym logicznie gromadzona jest grupa serwerów Exchange, które komunikuja˛sie˛ ze soba˛poprzez szybkie połaczenie˛ sieciowe. Serwery Exchange z punktu centralnego bezposrednio´ przesyłaja˛ do siebie poczte˛ i bezposrednio´ replikuja˛ wzajemnie informacje˛ katalogowa.˛ Przekazywanie (Routing) wiadomosci´ pocztowych pomiedzy˛ punktami centralnymi trzeba specjalnie skonﬁgurowac.´ Punkt centralny jest jednostka˛ administracyjna.˛

3.14.3.3 Składniki podstawowe

Microsoft Exchange Server składa sie˛ z nastepuj˛ ac˛ ych podstawowych składników:

◦ katalog Exchange (Directory Service, DS),

◦ Message Transfer Agent (MTA),

◦ pamie˛c´ informacji (Information Store, IS)

oraz

◦ kontrola systemu (System Attendant, SA) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 235

Katalog Exchange zapisuje wszystkie informacje o uzytko˙ wnikach, zasobach i organizacji (dir.edb). Nalez˙a˛ do nich listy zarejestrowanych na serwerze uzytko˙ wników poczty elektronicznej, nazwy i konfiguracje serwerów. Nalezy˙ zwrócic´ uwage˛ na fakt, ze˙ w katalogu zapisywane sa˛ wszelkie informacje o konfiguracji. Pamie˛c´ informacji składa sie z dwóch baz danych, tj. z „Privat Information Store“ (priv.edb) i „Public Information Store“ (pub.edb). „Privat Information Store“ zapisuje wiadomosci´ i za- łaczniki˛ plikowe dla uzytko˙ wników, których skrzynki pocztowe znajduja˛sie˛ na danym serwerze. „Public Information Store“ zapisuje tresć´ kopii publicznych katalogów. Message Transfer Agent (MTA) wysyła wiadomosci´ do innych serwerów, punktów centralnych i systemów zewnetrzn˛ ych. W połaczeniu˛ z katalogiem Exchange MTA decyduje o routingu wiadomosci.´ MTA przekazuje przychodzace˛ wiadomosci´ do pamieci˛ informacji. MTA zajmuje sie˛ takze˙ konwersja˛ wiadomosci´ do innych formatów. Kontrola systemu jest dla serwera Exchange instancja˛ zarzadzaj˛ ac˛ a.˛ Za pomoca˛ tego skład- nika mozna,˙ na przykład, tworzyc´ nowych uzytko˙ wników poczty elektronicznej oraz wykonywac´ zadania kontrolne i serwisowe. Kontrola systemu nadzoruje połaczenia˛ sieciowe z innymi serwerami Exchange i tworzy tablice routingu. Nastepuj˛ aca˛ tabela pokazuje odpowiednie składniki i opisuje w zwiezłej˛ formie ich funkcje.

SKŁADNIKI FUNKCJE

◦ Zarzadzanie˛ informacjami kierowanymi do odbior- ców, listami podziału, serwerami i infrastruktura˛ Messaging.

◦ katalog Katalog moze˙ byc´ wykorzystywany przez inne skład- niki w celu synchronizacji informacji, na przykład do porównania adresów.

◦ Wewnatrz˛ organizacji automatycznie nastepuje˛ replikacja informacji katalogowych wszystkich serwerów. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 236

◦ Jest podstawowym składnikiem infrastruktury komu- nikacyjnej serwera Exchange.

MTA ◦ Przesyła wiadomosci´ do innych serwerów, punktów centralnych i systemów.

◦ Konwertuje formaty dla innych systemów.

◦ Zapisywanie wiadomosci´ wysyłanych do poszczegól- nych uzytko˙ wników.

◦ pamie˛c´ informacji Przetwarzanie i zapisywanie informacji wewnatrz˛ publicznych katalogów.

◦ Prywatne i publiczne informacje przechowywane sa˛ w dwóch oddzielnych bazach danych.

◦ Protokołowanie aktywnosci´ Messaging.

◦ Nadzorowanie połacze˛ n´ pomiedzy˛ serwerami.

◦ Tworzenie tablic routingu.

kontrola systemu ◦ Kontrolowanie replikacji katalogów i usuwanie kon- ﬂiktów.

◦ Protokołowanie rozsyłania wiadomosci.´

◦ Generowanie adresów e - mail dla nowo utworzonych uzytko˙ wników. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 237

Tablica 3.43: Podstawowe składniki Exchange 5.5

3.14.3.4 Składniki opcjonalne

Zakres funkcji serwera Exchange mozna˙ rozszerzyc´ o opcjonalne, modularne składniki, takie jak, np. rózne˙ konektory oraz serwer zarzadzaj˛ ac˛ y kluczami. Konektory (Connectors) przekazuja˛ wiadomosci´ pomiedzy˛ rózn˙ ymi systemami lub punktami centralnymi.

◦ Site Connector i Directory Replication Connector (łaczy˛ punkty centralne w jeden system obejmujac˛ y całe przedsiebiorstwo)˛

◦ Dynamic RAS Connector (łaczy˛ punkty centralne poprzez połaczenia˛ wybierane asynchronicznie)

◦ Internet Mail Service (łaczy˛ z Internetem punkty centralne poprzez SMTP lub system Exchange)

◦ MS Mail Connector i Directory Synchronization (oferuje połaczenie˛ z systemami MS Mail 3.x)

◦ Microsoft Schedule+ Free / Busy Connector

◦ X. 400 Connector (łaczy˛ punkty centralne za pomoca˛ dedykowanego sterowania szeroko- pasmowego albo system Exchange z obcymi systemami X.400

◦ Connector for cc: Mail (łaczy˛ Exchange z systemami Lotus cc:Mail).

Rozrózni˙ c´ mozna˙ konektory wewnetrzne˛ i zewnetrzne.˛ Konektory wewnetrzne˛ łacz˛ a˛ ze soba˛ dwa punkty centralne Exchange i sa˛ w pierwszym rzedzie˛ obiektami logicznymi, które ułatwiaja˛ administrowanie. Konektory zewnetrzne˛ sa˛dodatkowymi składnikami oprogramowania i zapewniaja˛ połaczenie˛ serwera Microsoft Exchange z innymi systemami pocztowymi. Konektory zapewniaja˛ własciw´ a˛ konwersje˛ tresci´ wiadomosci´ i informacji adresowych. Dzieki˛ temu wiadomosci´ z Exchange mozna˙ odczytac´ w obcym systemie a wiadomosci´ obcego systemu moga˛ byc´ czytane przez uzytko˙ wników Microsoft Exchange. Serwer zarzadzaj˛ acy˛ kluczami (Key Management Server, KMS) mozna˙ wykorzystac´ do administrowania kluczami, za pomoca˛ których przesyłane sa˛ szyfrowane wiadomosci´ albo wiadomosci´ opatrzone podpisem cyfrowym. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 238

Dalszym opcjonalnym składnikiem jest Chat - Server. Umozliwia˙ on realizacje˛ tak zwanych „Internet Relay Chats“ (IRC), dzieki˛ którym z kolei mozliwa˙ jest jednoczesna, wzajemna komunikacja duzej˙ ilosci´ uczestników. Pocza˛wszy od wersji 5.5 zaimplementowany został takze˙ tak zwany Server Scripting Se- rvice. Usługa ta zapewnia mozliwo˙ s´c´ umieszczania skryptów napisanych w jezyku˛ skryptowym, takim jak Perl, VB Script albo JScript, w publicznym katalogu. Powyzsza˙ usługa zapewnia wykonywanie programów w wypadku wystapienia˛ okreslon´ ych zdarzen.´ Za pomoca˛skryptów mozna˙ automatyzowac´ zadania.

3.14.3.5 Obsługa protokołów

Exchange obsługuje cały szereg rózn˙ ych protokołów, z których najwazniejsze˙ zostały przedstawione w niniejszym podrozdziale. Simple Mail Transfer Protocol (SMTP) jest standardowym protokołem słuz˙ac˛ ym do przekazywania wiadomosci´ w Internecie. Do dostarczenia wiadomosci´ do nie zawsze połaczon˛ ych komputerów - klientów słuzy˙ pro- tokół POP3. Niniejszy standard zaprojektowany został pod katem˛ wymiany pakietów pomiedzy˛ tylko czasowo połaczon˛ ymi klientami poczty i serwerami pocztowymi. Klienty poczty korzystaja˛ z POP3 podczas czytania wiadomosci.´ Przesyłanie wiadomosci´ odbywa sie˛ za pomoca˛ SMTP. Inne zastosowanie ma standard IMAP4, który obsługiwany jest przez produkty e - mail. Duz˙a˛ siła˛ IMAP4 w porównaniu z POP3 jest zdolnos´c´ wybiórczego sci´ agania˛ wiadomosci´ z serwera. Dzieki˛ temu mozna˙ oddzielnie sci´ aga˛ c´ wiadomosci´ i ewentualnie istniejace˛ załaczniki.˛ Poprzez integracje˛ z HTTP mozna˙ udostepnia˛ c´ w Internecie dokumenty z katalogów publicznych. Jesli´ zastosowany zostanie Microsoft Internet Information Server (IIS) oraz Exchange Server 5.5 uzytko˙ wnicy uzyskaja˛ poprzez Active Server Web Access (OWA) mozliwo˙ s´c´ korzystania z funkcjonalnosci,´ które w innym przypadku byłyby dostepne˛ tylko za pomoca˛ klienta Outlook. Informacje te generowane sa˛ za pomoca˛ Active Server Pages. Tym samym obsługa HTTP jest w pierwszym rzedzie˛ rozszerzeniem Internet Information Server. Z tego tez˙ powodu obsługa HTTP wymaga istnienia Internet Information Server z funkcjonalnosci´ a˛ASP. Uzytko˙ w- nicy moga˛ na przykład przeglada˛ c´ prywatne i publiczne katalogi, wysyłac´ oraz odbierac´ wiadomosci´ pocztowe i korzystac´ z innych funkcji. Jednak pełny zakres funkcji dostepn˛ y jest tylko z serwerem Microsoft Internet Explorer. NNTP zapewnia rozprzestrzenianie sie˛ na całym swiecie´ Newsgroups. Tresci´ Newsgroups przesyłane sa˛poprzez NNTP z serwera do serwera. Exchange Server moze˙ za pomoca˛połaczenia˛ NNTP udostepnia˛ c´ tresci´ Newsgroups w katalogach publicznych. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 239

LDAP umozliwia˙ klientom dostep˛ do informacji katalogowych z katalogu serwera Microsoft Exchange.

3.14.3.6 Warianty produktu

Exchange Server 5.5 wykorzystywany jest w dwóch rózn˙ ych wersjach:

◦ Standard Edition oraz

◦ Enterprise Edition.

Enterprise Edition obsługuje Exchange Cluster z dwoma wezłami˛ w oparciu o Windows NT 4 Enterprise Edition.

3.14.3.7 Funkcjonalnosci´ uzytk˙ ownika

Funkcjonalnosciami,´ z których korzystac´ moze˙ uzytko˙ wnik i które wynikaja˛z posiadania skrzynki pocztowej sa:˛

◦ odbieranie i wysyłanie poczty elektronicznej (e - mail)

◦ zarzadzanie˛ zadaniami

◦ zarzadzanie˛ terminami

◦ listy adresowe (ogólne ksia˛zki˙ adresowe i osobiste kontakty)

◦ prowadzenie notatnika

Za typowe oprogramowanie klienckie uznalismy´ w niniejszym poradniku program Microsoft Outlook. Outlook ukazał sie˛ w wersjach 97 (wersja 8), 98 (wersja 8.5), 2000 (wersja 9) oraz 2002 (wersja 10, XP). Outlook i Exchange oferuja˛mozliwo˙ sć´ zapisywania i edycji danych offline oraz ich synchronizacje˛ w przypadku istniejace˛ go połaczenia˛ sieciowego (klasyczny przypadek dla Notebooks). Sam Outlook jako PIM (Personal Information Manager) oferuje zastosowanie Osobistych Katalogów, które zapisywane sa˛ w formie plików (*.pst). W publicznych katalogach (Public Folder) mozna˙ udostepnia˛ c,´ np. Workflows albo skrzynki pocztowe dla grup. Zastosowanie publicznych katalogów umozliwia˙ wspólne korzystanie z informacji. Uzytko˙ wnicy, którzy posiadaja˛ odpowiednie uprawnienia, moga˛ czytac´ i / lub zapisywac´ informacje zapisane w katalogach. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 240

3.14.3.8 Komunikacja klient - serwer

Komunikacja pomiedzy˛ klientem a serwerem odbywa sie˛ w typowym srodo´ wisku LAN za pomoca˛ klienta Outlook poprzez MAPI (Messaging Application Programming Interface) i tym samym poprzez RPC (Remote Procedure Calls). Dzieki˛ obsłudze SMTP, POP3, IMAP oraz HTTP mozna˙ realizowac´ najrózniejsze˙ scenariusze komunikacji klienta z serwerem.

3.14.3.9 Komunikacja serwer - serwer

Komunikacja pomiedzy˛ serwerami Exchange moze˙ byc´ sterowana za pomoca˛ róznorodn˙ ych ko- nektorów. Jesli´ dwa serwery znajduja˛ sie˛ wewnatrz˛ tego samego punktu centralnego, wówczas komunikuja˛ sie˛ one przez RPC.

3.14.3.10 Tematy pokrewne

Wskutek stosowania systemów poczty elektronicznej istnieje zwiekszone˛ niebezpieczenstwo´ ataku wirusów. W Exchange istnieje mozliwo˙ s´c´ zaimplementowania oprogramowania antywirusowego tworzonego przez innych producentów, jesli´ skorzysta sie˛ z napisanego przez nich antywirusowego API. Wielu producentów oferuje dla srodo´ wisk Exchange integracje˛ rozwiaza˛ n´ umozliwiaj˙ ac˛ ych wysyłanie faksów. Oprogramowanie innych producentów pozwala takze˙ archiwizowac´ poczte˛ elektroniczna˛ albo usuwac´ obiekty pocztowe nie bed˛ ace˛ w uzyciu˙ od dłuzsze˙ go czasu (Hierar- chical Storage Management, HSM).

3.14.4 Migracja zastepuj˛ aca˛

Cel migracji zastepuj˛ acej˛ moze˙ byc´ za kazdym˙ razem inny i zaleze˙ c´ od danego przypadku. Przed przystapieniem˛ do migracji nalezy˙ dokładnie okresli´ c´ rzeczywiste wymagania wzgledem˛ produktu Groupware. Nastepuj˛ aca˛ lista pokazuje przykładowe kryteria wyboru rozwiazania˛ Gro- upware:

◦ Jakie systemy klienckie maja˛ byc´ obsługiwane?

– tylko klienty oparte na WWW – klienty Outlook (obsługa MAPI) – systemy klienckie oparte na Linuksie ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 241

– klienty w systemach heterogenicznych (systemy windowsowe i linuksowe)

◦ Jakie funkcjonalnosci´ Groupware musi wspierac´ nowy system?

◦ Jakie wymagania stawiane sa˛ co do skalowalnosci´ systemu?

◦ itd.

Weryﬁkacja wymagan´ wzgledem˛ nowego produktu Groupware jest niezbedna˛ i nalezy˙ ja˛ przeprowadzic´ przed rozpoczeciem˛ realizacji kazde˙ go projektu.

3.14.4.1 phpGroupware

Reprezentantem czystego rozwiazania˛ opartego na WWW jest udostepniane˛ na licencji GPL oprogramowanie Groupware znane pod nazwa˛ „phpGroupware“47. Generowanie dynamicznie tworzonych tresci´ odbywa sie˛ w oparciu o jezyk˛ skryptowy PHP. Tresci´ udostepniane˛ sa˛ za pomoca˛ serwera WWW. Do zarzadzania˛ danymi i ich przechowywania mozna˙ wykorzystac´ baze˛ danych MySQL. Jako system bazodanowy mozna˙ jednak wybrac´ równiez˙ PostgreSQL, Oracle i Sybase, a do zarzadzania˛ adresami mozna˙ wykorzystac´ katalog LDAP. Równiez˙ autoryzacje˛ uzytko˙ wników mozna˙ realizowac´ za pomoca˛ rózn˙ ych technologii (SQL, SQL_SSL, LSAP, HTTP, NIS, PAM). Aby korzystac´ z poczty elektronicznej mozna˙ zastosowac´ dowolny serwer pocztowy. Musi on obsługiwac´ protokoły SMTP i POP3 / IMAP. Obecnie nie jest mozliwa˙ obsługa proﬁlów nieobecnosci´ oraz reguł ﬁltrowania opartych na serwerze. phpGroupware jest systemem modularnym. Podczas integracji mozna˙ wybierac´ sposród´ róz-˙ nych modułów. Oprócz w/w modułów realizujac˛ ych klasyczne funkcjonalnosci´ Groupware, udostepnian˛ ych jest wiele innych modułów.

MODUŁY FUNKCJA Addressbook Kontakt - Manager Admin Administrowanie Backup Narzedzie˛ zabezpieczajace˛ Kalendarz, wraz z przesyłaniem zaproszen´ i prawami do- Calendar stepu˛ Cdb Kontaktowa baza danych

47http://www.phpgroupware.org/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 242

Email Klient e - mail Forum Forum wiadomosci´ i forum dyskusyjne Projects Zarzadzanie˛ projektem Timetrack Rejestracja czasu ToDo Zarzadzanie˛ zadaniami TTS Trouble Ticket System

Tablica 3.45: Wybór modułów phpGroupware

Powyzsze˙ moduły moga˛byc´ opcjonalnie aktywowane przez administratora. Interfejsy WWW opieraja˛sie˛ na systemie szablonów. Wyrózni˙ c´ mozna˙ trzy typy opisów layout (XML, eTemplates, HTML). Deﬁnicje kolorów, czcionek i pozycjonowanie odbywa sie˛ za pomoca˛ CSS (Cascading Style Sheets). Wewnatrz˛ interfejsów WWW cze˛scio´ wo problematyczne jest stosowanie javascript, poniewaz˙ nie wszystkie przegladarki˛ bezbłednie˛ interpretuja˛ kod javascript. Ponadto jego stosowanie nie jest dozwolone w wielu urzedach˛ ze wzgledu˛ na wymagania bezpieczenstwa.´ Zastosowanie czystego rozwiazania˛ opartego na WWW oferuje wiele zalet:

◦ mozliwy˙ jest dostep˛ poprzez przegladark˛ e,˛ takze˙ bezpieczny dostep˛ z zewnatrz˛ poprzez HTTPS.

◦ nie jest konieczna instalacja specjalnego klienta.

◦ niezalezno˙ s´c´ od systemu operacyjnego daje szczególne korzysci´ w heterogenicznym sro-´ dowisku klienckim:

◦ aktualizacja oprogramowania odbywa sie˛ po stronie serwera.

Oprócz zalet istnieja˛ jednak równiez˙ wady:

◦ niemozliwy˙ jest dostep˛ do danych, gdy uzytko˙ wnicy pracuja˛ w trybie ofﬂine bad˛ z´ gdy nie maja˛ dostepu˛ do odpowiedniej sieci. Stanowi to problem zwłaszcza dla pracowników zewnetrzn˛ ych.

◦ nie istnieje synchronizacja z przenosn´ ymi urzadzeniami˛ konco´ wymi (PDAs). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 243

Podsumowujac˛ trzeba stwierdzic,´ ze˙ przedstawione rozwiazanie˛ nie jest alternatywa˛dla Outlook - Exchange. Jednakze˙ korzystanie z zaprezentowanego produktu Groupware moze˙ byc´ korzystne szczególnie w małych organizacjach, nie wymagajac˛ ych kazdorazo˙ wego sie˛gania do zaawanso- wanych funkcji. Zaleta˛jest jego elastycznos´c´ i mozliwo˙ sci´ dostosowania poszczególnych modu- łów do rzeczywistych potrzeb organizacji. Podobne rozwiazanie˛ oferuje takze˙ PHProjekt. Obydwa projekty udostepniły˛ w Internecie swoje wersje demonstracyjne48, dzieki˛ którym zainteresowani moga˛ ocenic´ proponowany zakres mozliwo˙ sci.´

3.14.4.2 Kroupware

Federalny Urzad˛ ds. Bezpieczenstwa´ w Informatyce (BSI) zlecił konsorcjum ﬁrm stworzenie rozwiazania˛ Groupware bed˛ ace˛ go Wolnym Oprogramowaniem dla potrzeb BSI. Tym samym z oprogramowania tego moga˛ skorzystac´ wszyscy zainteresowani, bez ponoszenia opłat licencyjnych. Celem projektu jest stworzenie ponadplatformowego rozwiazania˛ Groupware, z którego korzystałyby zarówno klienty linuksowe, jak i klienty windowsowe. Funkcjonalnosci´ wymagane przez BSI sa˛ porównywalne z tymi oferowanymi przez połaczenie˛ Outlook / Exchange ﬁrmy Microsoft. System kliencki Outlook ma umiec´ współpracowac´ z nowym serwerem49.

Serwer Centralnym składnikiem jest serwer Kolab, który z kolei odwołuje sie˛ do całego szeregu innych wolnych składników. Poszczególne składniki wymienione zostały w ponizszej˙ tabeli.

SKŁADNIKI ZAKRES FUNKCJI Cyrus IMAP Serwer pocztowy IMAP Cyrus SASL Autoryzacja Cyrus LDAP Zarzadzanie˛ uzytko˙ wnikami Postﬁx Mail - Transfer - Agent (MTA) Apache Serwer WWW dla WebDAV i Webfrontend ProFTP Serwer FTP

Tablica 3.47: Składniki Kolab 48phpGroupware: http://phpgw.de/modules.php?op=modload&name= phpGroupwareDemo&file=index PHProjekt: http://www.phprojekt.com/demo.php 49http://www.kroupware.org/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 244

Kroupware zbudowany jest w oparciu o klasyczny model klient - serwer, który gwarantuje uzytko˙ wnikom asynchroniczne korzystanie z funkcjonalnosci´ Groupware. Bed˛ ac˛ offline maja˛ oni za pomoca˛ oprogramowania klienckiego, np. mozliwo˙ sć´ korzystania z poczty elektronicznej, terminarza i osobistych list zadan.´ Zmiany synchronizowane sa˛ dzieki˛ pózniejszej´ replikacji danych. Projekt Kroupware moze˙ obsługiwac´ do 1500 uzytko˙ wników na jednym serwerze. Jego skalowalnosć´ opiera sie˛ na mozliwo˙ sciach´ klastra IMAPD i OpenLDAP. Instalacja obydwu systemów przewidziana jest w przypadku duzych˙ ilosci´ uzytko˙ wników, co ma umozliwi˙ c´ korzystanie z nich wiekszemu˛ kre˛gowi osób. W przypadku zastosowania produkcyjnego decydujaca˛ jest takze˙ opcja odzyskiwania danych. Architektura całego systemu ułatwia korzystanie z funkcji Recovery. Skrzynki pocztowe odwzorowane sa˛ w systemie plików jako pojedyncze katalogi i oferuja˛ łatwe Restore. Stopien´ skomplikowania zalezy˙ od narzedzi˛ stosowanych do tworzenia kopii bezpieczenstwa.´ Oprócz całych skrzynek pocztowych istnieje takze˙ mozliwo˙ sć´ odtwarzania pojedynczych wiadomosci´ i terminów.

Klienty Dostep˛ do funkcjonalnosci´ poczty elektronicznej i Groupware mozliwy˙ jest zarówno za pomoca˛klientów windowsowych, jak i klientów GNU / Linux. Podczas tworzenia programu wzieto˛ pod uwage˛ klienta Microsoft Outlook 2000. Połaczenie˛ klientów Outlook z serwerem Kolab nastepuje˛ poprzez konektor firmy Bynari. Insight Connector50 firmy Bynari jest odpłatnym, komer- cjalnym produktem i musi byc´ zainstalowany po stronie klientów. Konektor umozliwia˙ wymiane˛ danych kolaboracyjnych pomiedzy˛ serwerem Groupware i klientem Outlook. Z praktyki znane sa˛ jednak problemy ze stabilnym działaniem konektora. W przyszłosci´ alternatywa˛ mógłby byc´ konektor firmy Konsec51. Obecnie prace nad nim znajduja˛ sie˛ jednak jeszcze w fazie beta. Klient GNU/Linux powstał z przystosowanych wersji programów KMail, KOrganizer i innych składników projektu PIM - KDE. Klient ten bardzo dobrze wpisuje sie˛ w interfejs KDE, co pozwala uzytko˙ wnikom na intuicyjna˛ prace.˛ Klient obsługuje protokoły POP3 i disconnected IMAP4. Po stronie klienta obsługiwane jest równiez˙ filtrowanie nadchodzacej˛ poczty elektronicznej (spam, itd.). Ponizej˙ zamiescili´ smy´ liste˛ najwazniejszych˙ funkcjonalnosci´ Groupware. Funkcjonalnosci´ te obsługiwane sa˛ przez obydwa w/w klienty.

◦ odbieranie i wysyłanie poczty elektronicznej

50http://www.bynari.net/index.php?id=7 51http://www.konsec.com/KON/de/konnektor.html ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 245

◦ zarzadzanie˛ kontaktami pojedynczego uzytko˙ wnika

◦ globalna ksia˛zka˙ adresowa

◦ grupowy kalendarz i terminarz

◦ wspólne zasoby (katalogi publiczne)

◦ notatki i listy zadan´

◦ listy wolny / zajety˛

◦ potwierdzenia nieobecnosci´

◦ potwierdzenie przeczytania

◦ synchronizacja Palm PDA

Bezpieczenstwo´ Developerzy zwracali szczególna˛ uwage˛ na integracje˛ standardów bezpieczenstwa.´ Istnieje mozliwo˙ s´c´ całkowicie szyfrowanej komunikacji (SSL / TLS) pomiedzy˛ systemami klienckimi a serwerem. Szyfrowana˛ komunikacje˛ mozna˙ realizowac´ za pomoca:˛

◦ IMAPS

◦ SMTP poprzez TLS

◦ WebDAVS.

Klient linuksowy obsługuje end - to - end security oraz podpisy elektroniczne w oparciu o mie-˛ dzynarodowe standardy (S/MIME, X.509v3), dla których dostepna˛ jest odpowiednia wtyczka52.

Administrowanie Jesli´ chodzi o metody zarzadzania,˛ stworzono specjalne grupy uzytko˙ wników o szczególnych uprawnieniach. Wyrózni˙ c´ mozna˙ nastepuj˛ ace˛ grupy:

◦ administrator

◦ maintainer 52www.gnupg.org/aegypten ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 246

◦ user (uzytko˙ wnik)

Administrowanie moze˙ odbywac´ sie˛ za pomoca˛ Frontendu, w ograniczonym zakresie, odpowiednio do posiadanych uprawnien.´ Proste zadania administracyjne mozna˙ realizowac´ za pomoca˛ interfejsu WWW. W przypadku bardziej skomplikowanych czynnosci´ nalezy˙ dostosowac´ odpowiednie pliki konﬁguracyjne. Poprzez Frontend WWW mozna,˙ na przykład, wykonywac´ nastepuj˛ ace˛ zadania:

◦ zarzadza˛ c´ uzytko˙ wnikami i ksia˛zk˙ a˛ adresowa˛

◦ zarzadza˛ c´ publicznymi katalogami

◦ cze˛scio´ wo administrowac´ serwerem

◦ potwierdzac´ nieobecnos´c.´

Poprzez Frontend WWW mozliwy˙ jest przede wszystkim dostep˛ do usługi katalogowej. Inne działania dostosowujace˛ nalezy˙ wprowadzac´ w odpowiednich składnikach. Pojedynczy uzytko˙ wnicy maja˛ takze˙ mozliwo˙ s´c´ samodzielnego wprowadzania okreslon´ ych zmian. I tak uzytko˙ wnicy moga˛modyﬁkowac´ swoje dane osobowe i na przykład dodawac´ kolejne adresy e - mail.

Migracja Obecnie nie ma jeszcze praktycznych rozwiaza˛ n´ w obszrze projektów migracyjnych: w przypadku migracji istniejac˛ ych danych mozna˙ jednak zasadniczo korzystac´ z nastepuj˛ ac˛ ych mecha- nizmów:

◦ eksport informacji z katalogu za pomoca˛ LDIF oraz dostosowanie danych w oparciu o skrypty.

◦ wiadomosci´ e - mail nalezy˙ przenosic´ do nowego klienta za pomoca˛ POP3

◦ transfer danych w formacie vCard albo iCalender.

Wnioski Obecnie nie mozna˙ jeszcze konkretnie wypowiadac´ sie˛ o przydatnosci´ Kroupware. Brakuje ku temu wymownych doswiadcze´ n´ zebranych w srodo´ wiskach produkcyjnych. W przyszłosci´ Kro- upware bedzie˛ z pewnosci´ a˛ adekwatna˛ podstawa˛ Groupware dla małych i srednich´ organizacji. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 247

Zaleta˛ powyzsze˙ go rozwiazania˛ jest modularna budowa całego systemu, przy tworzeniu którego wykorzystane zostały sprawdzone i skalowalne składniki. Mozliwo˙ s´c´ zarzadzania˛ uzytko˙ wnikami wewnatrz˛ centralnej usługi katalogowej upraszcza zarzadzanie˛ danymi. Usługe˛ katalogowa˛ mozna˙ takze˙ wykorzystywac´ do przechowywania danych dla innych systemów (np. Samba). Dzieki˛ jednoczesnej obsłudze klientów linuksowych i klientów Outlook w/w rozwiazanie˛ szczególnie nadaje sie˛ dla heterogenicznych srodo´ wisk klienckich.

3.14.4.3 exchange4linux

Bill Workgroup Data Exchange Server zaprojektowany został przez developerów z niemieckiego przedsiebiorstwa˛ Neuberger & Hughes GmbH. Serwer ten udostepnian˛ y jest na licencji GPL i jest stale rozwijany. Celem programistów było i jest udostepnienie˛ klientowi Outlook ﬁrmy Microsoft alternatywnego systemu serwerowego. Przyszli uzytko˙ wnicy tego produktu moga˛ skorzystac´ z wielu rozwiaza˛ n´ umozliwiaj˙ ac˛ ych realizacje˛ zadan´ Groupware. Z jednej strony system serwerowy mozna˙ pobrac´ za darmo w postaci pakietów Debiana, a z drugiej strony zamówic´ pełne rozwiazanie˛ rozprowadzane przez Neuberger & Hughes. To ostatnie obejmuje oprócz zintegrowanego systemu Groupware takze˙ oprogramowanie ułatwiajace˛ dostep˛ o nazwie „Easygate“. Easygate udostepnia˛ najwazniejsze˙ usługi infrastrukturalne (DHCP, DNS, serwer plików, serwer proxy, Internet).

Serwer Funkcjonalnosci´ Groupware istnieja˛dzieki˛ współpracy wielu jednostek oprogramowania. Na- stepuj˛ aca˛ tabela zawiera pakiety oprogramowania wymagane do pracy serwera Groupware. Ser- wer powstał w oparciu o jezyk˛ programowania Python i komunikuje sie˛ z klientami Outlook za pomoca˛ Corba (patrz nizej).˙

SKŁADNIKI FUNKCJONALNOS´ CI PostGRSQL Centralne Składowanie danych PyGreSQL Python Interfejs pomiedzy˛ baza˛ danych i serwerem Groupware interface Python 2.1 Jezyk˛ programowania Exchange4linux Serwer Groupware

Tablica 3.49: Składniki Exchange4linux ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 248

Istnieje mozliwo˙ s´c´ zaimplementowania do usługi katalogowej serwera Bill. Nad taka˛ moz-˙ liwosci´ a˛ nalezy˙ sie˛ zastanawiac´ zwłaszcza w połaczeniu˛ z Samba.˛ Mozliwe˙ jest wówczas centralne zarzadzanie˛ uzytko˙ wnikami domen NT i składnikami Groupware. Rozwiazania˛ tego nie mozna˙ jednak zrealizowac,´ jesli´ korzysta sie˛ z pełnego systemu z N & H. W takim przypadku administratorzy musza˛ wprowadzic´ kilka poprawek na serwerze Bill.

Klient Dostep˛ do Bill Workgroup Server odbywa sie˛ za pomoca˛ klientów Outlook. Podstawa˛ dla dostepu˛ klienta do serwera Workgroup jest sterownik Client - MAPI stworzony przez N & H, który nalezy˙ zainstalowac´ po stronie klienta. MAPI - Clients wydaja˛ odpowiednie polecenia Outlooka na serwerze Bill wykorzystujac˛ Corba. MAPI Service Provider N & H jest produktem komercyjnym i jego uzywanie˙ zwiazane˛ jest z zakupem licencji. Serwer ten obsługuje w połaczeniu˛ z Microsoft Outlook - Client nastepuj˛ ace˛ funkcjonalnosci:´

◦ odbieranie i wysyłanie poczty elektronicznej

◦ zarzadzanie˛ adresami poszczególnych uzytko˙ wników

◦ globalna ksia˛zka˙ adresowa

◦ grupowy kalendarz i terminarz

◦ wspólne zasoby

◦ zarzadzanie˛ zadaniami

◦ notatki w prywatnych i publicznych katalogach

◦ funkcja wolny & zajety˛

◦ zaproszenia z mozliwo˙ sci´ a˛ przyjecia˛ albo odmowy

◦ potwierdzenia nieobecnosci´

◦ synchronizacja PDA poprzez Outlook.

Obsługa innych klientów nie jest jeszcze mozliwa.˙ W planie jest jednak ukazanie sie˛ w nastepnej˛ wersji klienta WWW obsługujace˛ go najwazniejsze˙ funkcjonalnosci´ Groupware. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 249

Bezpieczenstwo´ Transmisja danych pomiedzy˛ systemami moze˙ byc´ szyfrowana. Mozna˙ w tym celu korzystac´ ze standardu SSL i TLS. Za pomoca˛ oprogramowania innych producentów mozliwe˙ jest, po stronie serwera, sprawdzanie nadchodzacej˛ poczty pod katem˛ wirusów. Opcje bezpieczenstwa´ uzupełnione sa˛ o wykonywane na serwerze reguły ﬁltrowania, które chronia˛przed niechcianymi wiadomosciami.´ W celu ochrony przed nieuprawnionym dostepem,˛ wewnatrz˛ katalogów publicznych mozna˙ nadawac´ prawa dostepu.˛ Prawa dostepu˛ realizowane sa˛za pomoca˛ tak zwanych Access Controll Lists (ACL). Zapisywanie danych wewnatrz˛ systemu bazodanowego oferuje takze˙ wzglednie˛ prosta˛ moz-˙ liwos´c´ przywracania pojedynczych danych utraconych wskutek ich niezamierzonego usuniecia.˛ Proces ten mozna˙ realizowac´ za pomoca˛ narzedzi˛ dostarczanych wraz z baza˛ danych.

Administrowanie Administrowanie w przypadku zastosowania pełnego rozwiazania˛ odbywa sie˛ za pomoca˛ Frontendu opartego na WWW. W ramach administrowania standardowo wyrózni˙ c´ mozna˙ tylko uzytko˙ wników i administratorów. Dalszy podział nie jest przewidziany. Frontend WWW dostarczany wraz z pełnym rozwiazaniem˛ umozliwia˙ administrowanie zadaniami routine. Bardziej skomplikowane czynnosci´ administracyjne wykonywac´ mozna˙ za pomoca˛ tradycyjnego oprogramowania udostepniane˛ go wraz z Linuksem.

Migracja Jesli´ chodzi o migracje˛ danych, w zalezno˙ sci´ od punktu wyjscia´ mozna˙ zaproponowac´ rózne˙ rozwiazania.˛ W przypadku bardzo małej migracji (mniej wiecej˛ do 10 uzytko˙ wników) zalecane jest sko- piowanie skrzynek pocztowych oraz innych danych do katalogu osobistego w danym systemie klienckim. Dane te mozna˙ pózniej´ zaimportowac´ do skrzynek pocztowych załozon˙ ych w nowym systemie. Tego typu postepo˛ wanie jest bardzo bezpieczne lecz jednoczesnie´ zajmuje tez˙ bardzo duzo˙ czasu. W przypadku migracji obejmujacej˛ do 250 uzytko˙ wników zalecane jest skorzystanie równiez˙ z innych narzedzi.˛ Dane uzytko˙ wników Exchange mozna˙ wyeksportowac´ za pomoca˛ konsoli Exchange Administrator i narzedzia˛ ﬁrmy Microsoft „exmerge.exe“. Informacje o uzyt-˙ kownikach skrzynek pocztowych nalezy˙ zapisac´ w prostym pliku CSV, a zawartos´c´ skrzynek pocztowych mozna˙ zabezpieczyc´ w dowolnie wybranym katalogu w postaci plików PST. Tak samo nalezy˙ takze˙ postapi˛ c´ w przypadku Publicznych Katalogów. Teraz mozna˙ zaimportowac´ pliki CSV do Bill Workgroup Server wykorzystujac˛ narzedzie˛ migracyjne udostepniane˛ przez ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 250

N & H. Nastepnie˛ uzytko˙ wnicy moga˛ za pomoca˛ Outlooka zaimportowac´ do serwera zabezpie- czone skrzynki pocztowe (pliki PST). W przypadku wiekszych˛ projektów migracyjnych istnieja˛ jeszcze inne techniczne mozliwo-˙ sci´ przenoszenia danych, które nalezy˙ sprawdzic´ pod katem˛ konkretnego przypadku.

Wniosek Zaprezentowane rozwiazanie˛ Groupware oferuje bardzo dobra˛ obsługe˛ klientów Outlook, poniewaz˙ wspiera wszystkie wazne˙ funkcjonalnosci´ Groupware i udostepnia˛ je uzytko˙ wnikom. Ni- niejsze rozwiazanie˛ jest obecnie zoptymalizowane dla scenariuszy migracji obejmujac˛ ych kilkuset uzytko˙ wników (maks. 500) i w tych ramach stosowane jest w srodo´ wiskach produkcyjnych.

3.14.4.4 SuSE Linux OpenExchange Server 4

OpenExchange Server 4 jest kontynuacja˛ E-Mail Server 3.1 ﬁrmy SuSE Linux AG. Powyzsze˙ rozwiazanie˛ Groupware ma forme˛ całoscio´ wego rozwiazania˛ i zawiera kompletny system operacyjny, bazy danych, serwer poczty elektronicznej oraz serwer WWW. Technologia tego systemu operacyjnego opiera sie˛ na SuSE Linux Enterprise Server. System ten nie jest pomyslan´ y jako rozszerzenie juz˙ istniejac˛ ych systemów, lecz jest przeznaczony do całkowicie nowej instalacji. Dystrybutor oferuje swoim klientom rozwiazanie˛ All - In - One złozone˙ ze zsynchronizowanych ze soba˛ pakietów.

Serwer W tym miejscu nalezy˙ ocenic´ tylko te pakiety, które sa˛ bezposrednio´ zwiazane˛ z opisywa- nym rozwiazaniem˛ Groupware. Całe rozwiazanie˛ składa sie˛ z rózn˙ ych modularnych jednostek oprogramowania, które spójnie realizuja˛funkcjonalnosci´ poczty elektronicznej i Groupware. Po- nizsza˙ tabela zawiera centralne elementy tego rozwiazania.˛

SKŁADNIKI ZADANIA Postﬁx Mail - Transfer - Agent (MTA) Cyrus IMAPD Realizuje funkcjonalnosci´ IMAP Comﬁre Funkcjonalnosci´ Groupware OpenLDAP Centralna usługa katalogowa do zarzadzania˛ uzytko˙ wnikami Baza danych Postgre- Baza danych do zarzadzania˛ danymi Groupware SQL Apache - Tomcat Realizacja Frontendu WWW (poczta, Groupware) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 251

Tablica 3.51: Centralne składniki OpenExchange Server 4

Szczególna˛ zaleta˛ modularnej architektury jest jej skalowalnos´c´ wynikajaca˛ z przydzielania składników rózn˙ ym systemom. Modularna budowa umozliwia˙ takze˙ elastyczne rozszerzanie istniejac˛ ych systemów. Składniki serwera oferuja˛obszerne funkcjonalnosci´ poczty elektronicznej i Groupware. Uzyt-˙ kownicy moga˛ korzystac´ z rózn˙ ych funkcji:

◦ odbieranie i wysyłanie poczty elektronicznej

◦ zarzadzanie˛ terminami

◦ zarzadzanie˛ adresami

◦ zarzadzanie˛ zadaniami

◦ funkcje notatnika

◦ zarzadzanie˛ dokumentami (kontrola wersji i struktura katalogów)

◦ zarzadzanie˛ projektem

◦ konﬁgurowalna baza danych wiedzy

◦ forum dyskusyjne oparte na grupach.

Korzystanie z funkcjonalnosci´ moze˙ odbywac´ sie˛ w całkowicie poprzez zintegrowana˛ strone˛ portalu WWW.

Klienty Z uwagi na obsługe˛ rózn˙ ych systemów klienckich nalezy˙ rozrózni˙ c´ funkcjonalnos´c´ poczty elektronicznej od funkcjonalnosci´ Groupware. Dostep˛ do pierwszej funkcjonalnosci´ mozna˙ realizowac´ za pomoca˛ wszystkich klientów obsługujac˛ ych POP3 i IMAP. Uzytko˙ wnicy moga˛ dodatkowo odwoływac´ sie˛ do swoich wiadomosci´ e - mail poprzez specjalnie zintegrowane rozwiazanie˛ WWW. Korzystanie z funkcjonalnosci´ Groupware mozna˙ zasadniczo odbywac´ sie˛ na dwa sposoby:

◦ dostep˛ do tresci´ portalu WWW za pomoca˛ przegladarki˛ WWW

◦ ograniczony dostep˛ za pomoca˛ klienta Outlook. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 252

Dzieki˛ wykorzystaniu obszernego interfejsu WWW uzytko˙ wnicy moga˛ odwoływac´ sie˛ do w/w funkcjonalnosci.´ Uzytko˙ wnicy moga˛ korzystac´ z ksia˛zek˙ adresowych opartych na LDAP, moz-˙ liwosci´ przyznawania uprawnien´ i z wyszukiwania, które to funkcje udostepniane˛ sa˛ w postaci modułów. W przypadku stosowania funkcji uzgadniania terminów, po stronie serwera dla kaz-˙ dorazowego przeciagu˛ czasu ma miejsce automatyczna analiza udostepnian˛ ych zasobów. Oferty oparte na stronach WWW umozliwiaj˙ a˛uzytko˙ wnikom korzystanie z rozległych funkcjonalnosci´ grup. Druga mozliwo˙ sć´ dostepu˛ polega na skorzystaniu z klienta Microsoft Outlook. Moze˙ to nastapi˛ c´ tylko w przypadku zastosowania dodatkowego oprogramowania do replikacji, które nalezy˙ zainstalowac´ po stronie klienta. Replikacja ta jest synchronizacja˛ danych na z˙adanie˛ uzytko˙ w- nika, tym samym synchronizacja nie odbywa sie˛ w czasie rzeczywistym, jak ma to miejsce w przypadku konektora. Wspomniane oprogramowanie umozliwia˙ połaczenie˛ nastepuj˛ ac˛ ych dzie- dzin: poczta elektroniczna, kontakty, zadania i osobiste terminy. Jesli´ wystapi˛ a˛ konflikty wów- czas w konkretnym przypadku uzytko˙ wnik musi sam zdecydowac,´ w jaki sposób nalezy˙ je rozwiaza˛ c.´ Replikacja danych realizowana jest za pomoca˛SOAP w połaczeniu˛ z HTTP i umozliwia˙ synchronizacje˛ danych po stronie serwera z danymi bazy danych Outlook. Dzieki˛ zastosowaniu Outlooka istnieje równiez˙ mozliwo˙ sć´ wykonywania replikacji PDA. Interfejs MAPI firmy Microsoft nie jest obsługiwany dla Outlook. Obecnie w Outlooku nie ma mozliwo˙ sci´ tworzenia terminów grup. Wynika to z faktu, ze˙ Outlook nie posiada dodatkowych funkcji serwera OpenExchange, takich jak delegowanie zadan.´ Obecnie nie jest jeszcze obsługiwana takze˙ ksia˛zka˙ adresowa MAPI. Dlatego w dniu dzi- siejszym nie jest mozliwa˙ prawidłowa implementacja czasu rzeczywistego. Jednak zgodnie z informacjami producenta opcja ta jest własnie´ tworzona.

Bezpieczenstwo´ Aby uzyskac´ kodowana˛ transmisje˛ mozna˙ skorzystac´ z OpenSSL. OpenSSL realizuje szyfrowanie danych pomiedzy˛ aplikacjami i składnikami. IMAP i POP3 moga˛ przekazywac´ dane w bezpieczny sposób poprzez tunel SSL a SMTP za pomoca˛ TLS. Aby zwiekszy˛ c´ bezpieczenstwo´ w ruchu poczty mozna˙ dodatkowo zainstalowac´ skaner an- tywirusowy, co ma na celu identyfikacje˛ poczty sprawiajacej˛ problemy oraz przesyłanych wraz z nia˛ załaczników˛ . Domyslnie´ stosowac´ mozna˙ filtr poczty SIEVE słuz˙ac˛ y do sortowania nie- chcianej poczty. Filtr ten umozliwia˙ w razie potrzeby takze˙ ograniczenie rozmiaru wiadomosci´ i korzystanie z innych filtrów, zgodnie z dowolnie zdefiniowanymi kryteriami. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 253

Administrowanie Do wykonywania zadan´ administracyjnych dostarczany jest Frontend oparty na WWW. Admi- nistrator moze˙ decydowac´ o tym, jakie dane wolno uzytko˙ wnikom samodzielnie modyfikowac.´ Uzytko˙ wnicy moga˛ poprzez Frontend WWW zmieniac´ swoje hasło i zapisywac´ swoja˛ nieobec- nosć.´ Dzieki˛ temu opiekunowi systemu zmniejsza sie˛ ilosć´ pracy administracyjnej. Administra- tor moze˙ administrowac´ wykorzystujac˛ jeszcze inne opcje, za pomoca˛których moze˙ on zadawac´ podstawowe ustawienia dla składników Groupware, poczty elektronicznej oraz składników bezpieczenstwa.´ Ponadto podczas zarzadzania˛ systemem stosowac´ mozna˙ tradycyjne srodki´ (polecenia z linii polecen´ i pliki konfiguracyjne).

Migracja Na potrzeby migracji danych z systemu Microsoft Exchange 5.5 do OpenExchange Server 4 firma SuSE Linux AG oferuje specjalne wsparcie. Pracownicy SuSE AG bad˛ z´ jej partnerzy dokonuja˛ na miejscu analizy i tworza˛ w oparciu o nia˛ oferte˛ migracyjna.˛ Na potrzeby migracji wykorzystuje sie˛ z programy firmy Microsoft oraz własne. W ramach migracji przeniesć´ mozna˙ nastepuj˛ ace˛ dane:

◦ listy uzytko˙ wników z odpowiednimi uprawnieniami

◦ lokalnie i globalnie zapisana˛ poczte˛ elektroniczna˛

◦ zadania

◦ kontakty

◦ terminy

◦ notatki.

Dane zwiazane˛ z funkcjonalnosciami,´ których nie obsługuje OpenExchange nie zostana˛ prze- niesione. Do takich funkcji nalez˙a,˛ na przykład, journale, powtarzajace˛ sie˛ zadania, kategorie i podkatalogi uzytko˙ wników.

Wnioski Rozwiazanie˛ Groupware firmy SuSE Linux AG oferuje modularny system Groupware, któ- rego wiekszo˛ sć´ poszczególnych modułów opiera sie˛ na sprawdzonych składnikach Open Source. Jako składnik Groupware zintegrowano komercyjny pakiet „Comfire“, który otwiera uzytko˙ wnikom dostep˛ do szerokich funkcjonalnosci´ Groupware. Dostep˛ uzytko˙ wników do odpowiednich ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 254

informacji Groupware moze˙ odbywac´ sie˛ w oparciu o strone˛ WWW albo za pomoca˛ klienta Outlook. Poprzez strone˛ WWW uzytko˙ wnicy moga˛ odwoływac´ sie˛ do całego portfolio rozwia-˛ zania OpenExchange. Dla klientów Outlook funkcja ta jest jednak ograniczona. Uzytko˙ wnicy nie maja˛ obecnie mozliwo˙ sci´ dostepu˛ do połaczenia˛ w czasie rzeczywistym i równiez˙ nie maja˛ prawdziwej obsługi MAPI. Tym samym uzytko˙ wnikom udostepniana˛ jest jedynie ograniczona funkcjonalnos´c´ Outlook.

3.14.4.5 Samsung Contact

Samsung Contact (SC) jest obszernym rozwiazaniem˛ Groupware zaprojektowanym z mysl´ a˛ o zastosowaniach w przedsiebiorstwach˛ o róznej˙ wielkosci.´ System ten pozwana na zarzadzanie˛ uzytko˙ wnikami na serwerze w liczbie od kilkuset do dziesiatek˛ tysiec˛ y. Funkcjonalnosć´ oprogramowania jest dalece kompatybilna z produktem Exchange firmy Microsoft. Wszystkie składniki serwera dostepne˛ sa˛dla Linuksa (RedHat, SuSE) oraz wiekszo˛ sci´ odmian Uniksa (AIX, HP-UX, Solaris). Takze˙ po stronie klienta obsługiwanych jest wiele systemów operacyjnych. Klient Java SC pracuje zarówno w Linuksie, jak i w Windowsie. Oparty na WWW klient umozliwia˙ dostep˛ z kazdej˙ platformy obsługujacej˛ WWW. Poprzez dostarczany MAPI - Provider mozna˙ w pełni wykorzystywac´ istniejace˛ funkcjonalnosci´ Outlook (98, 2000, XP). Samsung Contact opiera sie˛ na sprawdzonej technologii OpenMail firmy Hewlett - Packard (HP). Przedsiebiorstwo˛ załozone˙ w Korei istnieje na rynku od ponad 15 lat. Samsung SDS po- siadał w listopadzie 2001 roku wszystkie prawa do dalszego rozwijania w/w produktu, jak tez˙ przejał˛ od HP zespół programistów pracujac˛ y nad projektem.

Serwer Podstawowa architektura systemu przedstawiona została na ponizszym˙ rysunku: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 255

Rysunek 3.28: Architektura Samsung Contact

System serwera składa sie˛ z wielu niezalezn˙ ych od siebie składników, które w sensie skalowania horyzontalnego mozna˙ podzielic´ na wiele serwerów. Ponadto w systemie serwera mozliwa˙ jest praca wielu całkowicie niezalezn˙ ych od siebie instancji. Nastepuj˛ aca˛ tabela stanowi przeglad˛ procesów serwera i ich zadan.´

SKŁADNIKI ZAKRES FUNKCJI ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 256

Przekazuje wiadomosć´ do kazdorazo˙ wej usługi niezbednej˛ dla przetworzenia wiadomosci.´ Zawiera ona wykonywanie reguł po Service Router stronie serwera sterujac˛ ych przydzielaniem wiadomosci´ lub auto- matycznym odpowiadaniem na wiadomosci.´ Local Delivery Dostarcza wiadomosć´ do lokalnej skrzynki pocztowej. Słuzy˙ do przekształcania wiadomosci´ do Internet - Mail zgodnego Internet Mail Gateway z MIME. Słuzy˙ do łaczenia˛ klientów poczty elektronicznej poprzez siec.´ Ten rodzaj połaczenia˛ wykorzystywany jest, np. przez MAPI - Remote Client Interface Provider i klientów Java. Chodzi przy tym o połaczenie˛ Single - Socket pomiedzy˛ klientem a procesem serwera. Usługa testowa umozliwiaj˙ aca˛ kontrole˛ Mail - Routings. Gene- Test Service ruje ona prosta˛ odpowiedz´ e - mail. Print Service Umozliwia˙ wydruk poczty elektronicznej po stronie serwera. Słuzy˙ do przetwarzania wiadomosci´ za pomoca˛skryptów po stro- Request Service nie serwera. Daje mozliwo˙ sć´ zarzadzania,˛ np. mailing lists. Directory Synchronisa- Umozliwia˙ synchronizacje˛ katalogów pomiedzy˛ wieloma serwe- tion rami Samsung Contact. Słuzy˙ replikacji Bulletin Boards (Shared Folders) pomiedzy˛ róz-˙ Bulletin Board Service nymi serwerami Samsung Contact. Background Search Se- Słuzy˙ asynchronicznemu wyszukiwaniu informacji w Message - rvice Store. Client Directory Ac- Przygotowuje wpisy centralnych katalogów, aby móc je udostep-˛ cess Service niac,´ np. jako globalna˛ ksia˛zk˙ e˛ adresowa˛ w kliencie Outlook. Application Link Se- Umozliwia˙ przyłaczenie˛ zewnetrzn˛ ych aplikacji, np. Fax - Gate- rvice ways. Udostepnia˛ zawartosć´ skrzynki pocztowej poprzez protokół POP3 Service POP3. omscan Service Słuzy˙ do sprawdzania spójnosci´ Message - Stores. Directory Relay Se- Słuzy˙ do odpytywania katalogów znajdujac˛ ych sie˛ na odległych rvice serwerach Samsung Contact. Container Access Mo- Sprawdza prawa dostepu˛ do Message - Store. nitor ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 257

Słuzy˙ do powiadamiania procesów klienckich o zdarzeniu (np. Notification Service gdy nadchodzi nowa wiadomosć´ albo po odnalezieniu celu przez usługe˛ wyszukiwania. Eksportuje wewnetrzn˛ y katalog poprzez LDAP w wersji 3. Jako LDAP Service serwer LDAP słuzy˙ OpenLDAP. Centralny proces słuz˙ac˛ y bezpiecznemu zarzadzaniu˛ kolejkami Queue Manager wiadomosci.´ Proces wykonywany w tle w celu pozbycia sie˛ usunietych˛ wiado- Item Delete Daemon mosci´ z Message - Store. Udostepnia˛ zawartosć´ skrzynki pocztowej poprzez protokół IMAP Service IMAP. Słuzy˙ do odbierania wiadomosci´ poprzez SMTP. Przed dorecze-˛ niem do skrzynki pocztowej ma miejsce wyszukiwanie adresata w SMTP Relay katalogu. SMTP - Gateway obsługuje mechanizmy antyspamowe i autoryzacje˛ oparta˛ na SASL. Umozliwia˙ odbieranie i wysyłania wiadomosci´ do pagerów bad˛ z´ SMS / Pager Service SMSów.

Tablica 3.53: Składniki Samsung Contact

Jako Mail - Transport - Agent (MTA) domyslnie´ stosowany jest Sendmail. Zasadniczo mozna˙ takze˙ korzystac´ z serwera pocztowego Postﬁx. Serwerem WWW polecanym dla klientów WWW i Frontendu administracyjnego jest Apache. Samsung Contact mozna˙ instalowac´ jako Single - Server albo tez˙ wykonywac´ instalacje˛ dzielona˛ obejmujac˛ a˛ wiele punktów centralnych. Skrzynka pocztowa uzytko˙ wnika jest jednak zawsze przyporzadko˛ wana do jednego wezła˛ serwera. Katalog ten mozna˙ replikowac´ ponad granicami punktów centralnych. Public Shared Folders znane ze srodo´ wiska Microsoft Exchange udostepniane˛ sa˛ w postaci Bulletin Boards (BB). Równiez˙ je mozna˙ replikowac´ ponad granicami punktów centralnych, co stanowi zalete˛ przede wszystkim w przypadku waskopasmo˛ wych połacze˛ n´ pomiedzy˛ dwoma punktami centralnymi. W celu umozliwienia˙ właczania˛ do Groupware zewnetrzn˛ ych aplikacji udostepniono˛ specjalny API oraz Application Link Service. Interfejs ten wykorzystywany jest, np. przez ﬁrme˛ VIPcom (www.vipcomag.de) oraz przez Ferrari (www.ferrari-electronic.de) do ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 258

przyłaczania˛ systemu Unified - Messaging (voice, fax). Jesli´ chodzi o kryterium wysokiej niezawodnosci,´ Samsung Contact jest juz˙ projektem zop- tymalizowanym. Wiekszo˛ sć´ parametrów systemu mozna˙ zmienic´ w trakcie pracy systemu, bez koniecznosci´ ponownego uruchamiania całego systemu. Aby uchronic´ sie˛ przez awaria˛ osprzetu˛ na we˛zle´ pocztowym, radzimy uruchamiac´ system jako klaster HA. Tradycyjnie zalecane jest tu skorzystanie z rozwiazania˛ oferowanego przez firme˛ HP jakim jest HP Service Guard. Zasadni- czo do Samsung Contact mozna˙ dopasowac´ kazde˙ oprogramowanie klastrowe, które umozliwia˙ przejecie˛ wspólnego Storage - Node. (RedHat Advanced Server, Steeleye, Polyserve, Failsafe, Linux Heartbeat).

Klienty Samsung Contact obsługuje szeroka˛ palete˛ klientów. Oprócz MAPI - Provider słuz˙ace˛ go do przyłaczania˛ klientów Microsoft Outlook istnieje jeszcze klient Groupware napisany w Java, jak tez˙ odpowiedni interfejs WWW. Domyslnie´ przyłaczenie˛ klienta odbywa sie˛ poprzez protokół UAL. Chodzi przy tym o prosty protokół Socket, dla którego istnieja˛ otwarte API napisane w C i Java. Samsung MAPI - Provider i klient WWW wykorzystuja˛ API w C, natomiast klient Java korzysta z API w Java. Alternatywnie do klientów Samsunga mozna˙ odwoływac´ sie˛ do zawartosci´ skrzynek pocztowych, jak i do standardowych protokołów POP3 oraz IMAP4. Dlatego do sci´ agania˛ i wysyła- nia poczty elektronicznej mozna˙ stosowac´ dowolnego klienta poczty obsługujace˛ go POP3 albo IMAP (np. Eudora, Evolution, Mozilla, Netscape, Outlook Express, K-Mail). Aby umozliwi˙ c´ dostep˛ do WAP, mozna˙ skorzystac´ z dostosowanej wersji klienta WWW. Korzystanie z klienta Outlook mozliwe˙ jest dzieki˛ implementacji MAPI serwera Samsung Contact. Odwzorowane sa˛ wszystkie istotne funkcjonalnosci´ serwera. Rozwiazanie˛ to zawiera takze˙ wszystkie najwazniejsze˙ Features Groupware. SC umozliwia˙ przyznawanie praw dostepu˛ do poszczególnych katalogów (poczta, terminy, kontakty, zadania) innym uzytko˙ wnikom. Pu- blic Shared Folders, znane ze srodo´ wiska Microsoft Exchange, udostepniane˛ sa˛ w postaci Bul- letin Boards. Obsługiwane jest takze˙ tworzenie reguł po stronie serwera w celu przydzielania nadchodzac˛ ych wiadomosci´ oraz automatyczne tworzenie komunikatu o nieobecnosci.´ W przypadku nieobecnosci´ uzytko˙ wnika mozna˙ zdeﬁniowac´ zastepc˛ e,˛ który w tym okresie czasu otrzyma odpowiednie prawa dostepu.˛ Wyznaczanie spotkan,´ podobnie jak w przypadku Micro- soft Exchange, mozna˙ ułatwic´ sobie za pomoca˛ listy free - busy, która zarzadzana˛ jest w katalogu serwera Samsung Contact. Aby umozliwi˙ c´ zastosowania przenosne,´ zaimplementowano synchronizacje˛ katalogów ofﬂine. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 259

Bezpieczenstwo´ Samsung Contact nie oferuje domyslnie´ szyfrowania wiadomosci.´ Istnieja˛jednak rozwiazania˛ innych producentów, które umozliwiaj˙ a˛ w Outlooku szyfrowanie end - to - end (certyﬁkaty) zgodne z S/MIME (np. Entrust). Szyfrowanie połaczenia˛ pomiedzy˛ klientem i serwerem (POP3 / IMAP) nastepuje˛ poprzez uruchomiony wczesniej´ tunel SSL (stunnel). Autoryzacja uzytko˙ wników realizowana jest za pomoca˛architektury PAM. Wykorzystywana jest ona do administrowania, zarówno przez procesy serwera, jesli´ chodzi o protokoły UAL / IMAP / POP3, jak tez˙ przez narzedzia˛ działajace˛ z linii polecen.´ Oprócz autoryzacji do katalogu Samsung Connect, mozliwa˙ jest takze˙ jeszcze autoryzacja do innych instancji. W chwili obecnej zakres dostawy obejmuje moduły PAM bed˛ ace˛ składnikami autoryzacji kont uniksowych oraz składnikami autoryzacji zewnetrzn˛ ych serwerów Radius i SMB (Samba). Samsung Contact umozliwia˙ szczegółowe ustalenie praw dostepu˛ w przypadku nastepuj˛ ac˛ ych zasobów serwera w formie tak zwanych list kontroli dostepu˛ (ACLs):

◦ Bulletin - Boards (Public Shared Folders)

◦ katalogi

◦ procesy usług

◦ serwer wydruku

◦ skrypty zapytan´

Rozmiar maksymalnego miejsca na dysku wykorzystywanego przez uzytko˙ wnika do zapisywania danych mozna˙ ograniczyc´ poprzez kwotowanie. Do zabezpieczania (Backup) Message - Stores nie jest wymagane specjalne oprogramowanie. Skorzystac´ mozna˙ z kazde˙ go produktu udostepniane˛ go przez system operacyjny, w którym pracuje serwer. Konstrukcja systemu Samsung Contact umozliwia˙ spójne zabezpieczanie w trakcie pracy. Do wykonywania Single User Backup / Restore słuzy˙ narzedzie˛ pracujace˛ z linii polecen.´ Z jego pomoca˛ w prosty sposób mozna˙ przeniesć´ pojedynczego uzytko˙ wnika z jednego wezła˛ pocztowego do drugiego. W celu ochrony przed wirusami, zasadniczo skorzystac´ mozna˙ z kaz-˙ dego antywirusowego Gateway opartego na SMTP (MIME - Sweeper, Trendmicro Viruswall). Oprogramowanie antywirusowe AHN (www.ahnlab.com) jest zintegrowane po stronie serwera. Oprócz ochrony przed wirusami mozna˙ takze,˙ po stronie serwera, filtrowac´ wiadomosci´ pocztowe w oparciu o filtry zdefiniowane przez uzytko˙ wnika. Konfiguracja ich odbywa sie˛ poprzez Frontend WWW. SMTP - Relay obsługuje ochrone˛ antyspamowa˛ zgodnie z RFC 2505. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 260

Administrowanie Administrowac´ wezłami˛ pocztowymi Samsung Contact mozna˙ na dwa rózne˙ sposoby: z jednej strony istnieje prosty Frontend WWW słuz˙ac˛ y do zakładania kont uzytko˙ wników, list przydzielania i wpisów katalogowych, a z drugiej strony istnieje cała masa narzedzi˛ działajac˛ ych z linii polecen,´ umozliwiaj˙ ac˛ ych administrowanie wszelkimi składnikami. Frontend WWW wymyslon´ y został na potrzeby codziennej pracy. Konsolowy interfejs przeznaczony jest w pierwszym rzedzie˛ do zautomatyzowania zadan´ administracyjnych. Administrowac´ systemem moze˙ kazdy˙ uzytko˙ wnik, który posiada uprawnienia administratora. Dodatkowy wpis do katalogu systemowego okresla,´ czy dany uzytko˙ wnik ma byc´ traktowany jak administrator.

Migracja Migracje˛ ze srodo´ wiska Exchange albo Outlook do Samsung Contact przeprowadzic´ mozna˙ na rózne˙ sposoby. Jesli´ ilos´c´ uzytko˙ wników jest przewidywalna (< 100), wówczas mozna˙ pomysle´ c´ o reczn˛ ym przeniesieniu skrzynek pocztowych, terminarzy, kontaktów oraz zadan´ do pliku PST a nastepnie˛ reczn˛ y transfer do struktury katalogu po stronie serwera. W takim przypadku równiez˙ zakładanie skrzynek pocztowych i uzytko˙ wników wykonywane jest recznie.˛ W duzych˙ srodo´ wiskach systemowych, z powodu kosztów oraz wydajnosci,´ reczna˛ migracja nie ma sensu. W tego rodzaju srodo´ wiskach nalezy˙ skorzystac´ z jednego z komercyjnych narze-˛ dzi migracyjnych. W zalezno˙ sci´ od producenta mozna˙ z ich pomoca˛ przeprowadzic´ całkowicie automatyczne przeniesienie wszystkich danych wraz z rekonﬁguracja˛klienta Outlook. Po stronie serwera migracja moze˙ obja˛c´ nastepuj˛ ace˛ informacje.

◦ uzytko˙ wnicy (bez haseł)

◦ wpisy do kalendarza

◦ wpisy katalogowe

◦ Public Distribution Lists

◦ hierarchie˛ katalogów wraz z cała˛ ich zawartosci´ a˛ (wiadomosci´ e - mail, terminy, zadania, kontakty)

◦ Bulletin Boards

◦ reguły oparte na serwerze ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 261

◦ listy kontroli dostepu˛

W przypadku przygotowywania takiej migracji zalecane jest właczenie˛ zewnetrzne˛ go usługo- dawcy posiadajace˛ go odpowiednia˛ ekspertyze.˛

Wnioski Samsung Contact jest pełnowartoscio´ wym zastepnikiem˛ Microsoft Exchange Server, zarówno w przypadku duzych,˙ jak i małych instalacji. Obsługuje on wszystkie funkcjonalnosci´ Gro- upware serwera Exchange. Wyjatek˛ stanowia˛ aplikacje do tworzenia formularzy, jednak nie- którzy producenci podjeli˛ juz˙ odpowiednie prace w tym zakresie. Podstawowa technologia istnieje na rynku juz˙ od ponad 15 lat. Dlatego produkt ten posiada duz˙a˛ ilos´c´ wdroze˙ n,´ do których mozna˙ sie˛ odwołac.´ Najnowsze przejecie˛ przez ﬁrme˛ Samsung zapewnia dalszy rozwój produktu przez najblizsze˙ lata.

3.14.4.6 Streszczenie

Obecnie istnieje kilka rozwiaza˛ n´ Groupware dla Linuksa, które oferuja˛ podobny zakres funkcji, jak ma to miejsce w przypadku Microsoft Exchange. Zasadniczo uwzgledniaj˛ ac˛ istniejace˛ rozwiazania˛ mozna˙ przyja˛c´ dwie rózne˙ strategie: dostep˛ do serwera Groupware z poziomu przegladarki˛ internetowej, dynamiczne przygotowywanie danych na serwerze. dostep˛ do serwera Groupware za pomoca˛ specjalistycznego oprogramowania klienckiego.

PHPGROUP- KROUP- EXCHANGE- SUSE SAMSUNG WARE WARE 4LINUX LINUX CONTACT OPENEX- CHANGE SERVER 4 Obsługa Outlooka połaczenie˛ Połaczenie˛ Połaczenie˛ Replikacja MAPI Outlook za pomoca˛ za pomoca˛ brak syn- Connector Bynari Insight N&H chronizacji nie Connector MAPI Service w czasie rze- Provider czywistym, takiej jak w przypadku ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 262

konektorów globalna ksia˛zka˙ nie tak tak nie tak adresowa MAPI poczta nie tak tak tak tak kontakty nie tak tak tak tak zadania nie tak tak tak tak terminy nie tak tak tak tak Inne systemy klienckie synchroni- tak, za pomoca˛ za pomoca˛ za pomoca˛ zacja Palm - nie za pomoca˛ Outlooka Outlooka Outlooka Pilot klienta KDE i Outlooka Funkcjonalnosci´ Groupware portal WWW tak nie nie tak tak zarzadzanie˛ za pomoca˛ kontaktami tak tak zarzadzania˛ tak tak adresami zarzadzanie˛ tak tak tak tak tak terminami zarzadzanie˛ tak tak tak tak tak zadaniami notatki tak tak tak tak tak

Tablica 3.55: Alternatywne rozwiazania˛ Groupware

Zakres funkcji przedstawionych rozwiaza˛ n´ Groupware wyraznie´ wskazuje na to, ze˙ w chwili obecnej istnieja˛ juz˙ adekwatne produkty linuksowe. Wybór własciwe´ go rozwiazania˛ Groupware zalezy˙ od nastepuj˛ ac˛ ych kryteriów:

◦ korzystanie z klientów Microsoft Outlook

◦ wykorzystanie w heterogenicznych srodo´ wiskach klienckich; jednoczesne stosowanie linuksowych systemów klienckich i klienta Outlook ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 263

◦ wykorzystanie rozwiazania˛ opartego na WWW

◦ stosowanie Outlooka

Aby kontynuacyjnie stosowac´ Outlook jako system kliencki, pierwszoplanowymi rozwiazaniami˛ sa˛ zasadniczo produkty Kroupware, SuSE OpenExchange i Samsung Contact. Brakujace˛ poła-˛ czenie w czasie rzeczywistym SuSE OpenExchange z Outlookiem ogranicza jeszcze obecnie funkcjonalnosć´ tego produktu i stanie sie˛ dla wielu klientów interesujac˛ a˛ alternatywa˛ dopiero wówczas, gdy zaimplementowana zostanie w/w funkcjonalnosć.´ W tej chwili exchange4linux oraz Samsung Contact oferuja˛ lepsza˛ obsługe˛ Outlook. W przyszłosci´ takze˙ Kroupware moze˙ byc´ interesujac˛ a˛ alternatywa,˛ zwłaszcza w srodo´ wiskach heterogenicznych (patrz nizej).˙ Z powodu braku informacji o pracy w srodo´ wiskach produkcyjnych, nie mozna˙ jeszcze w tym miejscu konkretnie wypowiadac´ sie˛ o przydatnosci´ powyzsze˙ go rozwiazania.˛ Dla organizacji skupiajac˛ ych wieluset uzytko˙ wników serwer exchange4linux oferuje stabilna˛platforme˛ Groupware, która sprawdziła sie˛ juz˙ w praktyce. Samsung Contact, który znajduje sie˛ na rynku juz˙ od dłuz-˙ szego czasu i oferuje dobra˛ obsługe˛ Outlooka, jest wiel oferujac˛ a˛ alternatywa,˛ zwłaszcza dla duzych˙ organizacji. Dobra skalowalnosć´ systemu pozwala na wykorzystanie go w organizacjach skupiajac˛ ych wiele dziesiatek˛ tysiec˛ y pracowników. Wraz z przejeciem˛ HP OpenMail przez kon- cern Samsung wyjasniło´ sie˛ takze˙ pytanie53 dotyczace˛ dalszego rozwoju oraz wsparcia technicznego.

Heterogeniczne sr´ odowiska klienckie Organizacje, które wykorzystuja˛ po stronie klienta rózne˙ systemy operacyjne, maja˛ na przy- kład mozliwo˙ sć´ zastosowania Samsung Contact bad˛ z´ w przyszłosci´ Kroupware. Samsung propo- nuje własnego klienta opartego na Java, który oferuje funkcjonalnosci´ Groupware niezaleznie˙ od systemu operacyjnego. Dzieki˛ temu istnieje mozliwo˙ sć´ korzystania w systemach windowsowych z Outlooka i / albo z klienta Java bad˛ z´ w systemach linuksowych tylko z klienta Java. W przy- szłosci´ takze˙ Kroupware bedzie˛ potencjalnym rozwiazaniem˛ dla systemów mieszanych. Dzieki˛ mozliwo˙ sci´ jednoczesnego zastosowania Outlooka i klienta KDE uzytko˙ wnicy moga˛ korzystac´ z funkcjonalnosci´ Groupware, takze˙ w trybie offline.

Rozwiazania˛ oparte o WWW Organizacjom preferujac˛ ym rozwiazania˛ oparte na WWW, bardzo dobry zakres funkcji oferuje udostepnian˛ y na licencji GPL system phpGroupware oraz komercyjny OpenExchange. Ope-

53Patrz takze˙ Studium przydatnosci´ dla ministerstwa z roku 2001. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 264 nExchange umozliwia˙ dodatkowo takze˙ przyłaczenie˛ klientów Outlook, jednak z ograniczeniem zwiazan˛ ym z brakiem połaczenia˛ w czasie rzeczywistym.

3.14.5 Migracja kontynuacyjna

3.14.5.1 Exchange 2000

Nowosci´ W porównaniu z Exchange 5.5, najwazniejsz˙ a˛ zmiana˛ w architekturze, która˛ wprowadzono wraz z ukazaniem sie˛ Exchange 2000 jest przeniesienie usługi katalogowej Exchange do Win- dows 2000 Active Directory (AD). Tym samym Exchange 2000 nie posiada juz˙ własnej usługi katalogowej i wymaga uzywania˙ Active Directory. Ponadto Exchange 2000 nie mozna˙ instalowac´ w serwerach Windows NT, lecz tylko w serwerach Windows 2000. W porównaniu z dotychczasowa˛ jednostka˛ struktury Exchange 5.5 - „punkt centralny“ - miały miejsce nastepuj˛ ace˛ zmiany:

◦ replikacja katalogu wykonywana jest jedynie w Active Directory; wprowadzonych tam punktów centralnych (Sites) nie nalezy˙ mylic´ z punktami centralnymi z Exchange 5.5.

◦ Serwery Exchange tworza,˛ z technicznego punktu widzenia, „grupy administracyjne“

◦ ponadto serwery Exchange podzielone sa˛na grupy routingu, które nie musza˛pokrywac´ sie˛ z „grupami administracyjnymi“.

Poniewaz˙ w serwerze Exchange 2000 nie ma juz˙ usługi katalogowej, wymaga on usługi, która udostepnia˛ globalnemu katalogowi (Global Catalog, GC) obszernych informacji ponad granicami domen. GC moze˙ byc´ udostepnian˛ y tylko w kontrolerach domen z Windows 2000. Zawiera on informacje o wszystkich obiektach ogólnej struktury Windows 2000 (forest), jednakze˙ tylko wybrane atrybuty. Aktualnie klienty (np. Outlook 2000 albo 98 SP2) moga˛ sci´ aga˛ c´ informacje bezposrednio´ z GC. Starsze wersje klientów obsługiwane sa˛ przez serwer Exchange 2000, który jako serwer posrednicz´ ac˛ y przekazuje zapytanie dalej. W przeciwienstwie´ do tego, w Exchange 5.5 kazdy˙ serwer Exchange zawiera usługe˛ katalogowa.˛ W Active Directory listy przydzielania z Exchange 5.5 zastapione˛ zostały grupami e - mail. W AD istnieja˛ czyste grupy przydzielania i grupy zabezpieczania. Grupy zabezpieczania ob- sługuja˛ takze˙ wiadomosci´ pocztowe, dzieki˛ czemu mozna˙ unikna˛c´ redundancji. Jak wiadomo w grupach AD o rózn˙ ych okresach wazno˙ sci´ (widocznosci)´ znajduja˛ sie:˛ domeny (globalna i ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 265

lokalna) oraz grupy uniwersalne (tylko w trybie Native domeny). Jedynie grupy uniwersalne widoczne sa˛ poza granicami domen. W Exchange 2000 projekt nie jest juz˙ determinowany przez model administracyjny srodo-´ wiska Exchange, poniewaz˙ serwer mozna˙ zorganizowac´ oddzielnie, wykorzystujac˛ w tym celu grupy administracyjne i grupy routingu. Podział ten mozliwy˙ jest jednak tylko wówczas, gdy w trybie Native pracuje sam Exchange 2000, tzn. gdy nie sa˛ uzywane˙ inne serwery 5.5. Exchange 2000 oferuje administrowanie zgodne z modelem wytycznych. Model ten umozli-˙ wia administratorom zmienianie opcji grupy obiektów (np. skrzynek pocztowych uzytko˙ wników, serwerów oraz katalogów publicznych) w jednym procesie. Transport pomiedzy˛ serwerami Exchange 2000 odbywa sie˛ teraz poprzez SMTP (Simple Message Transport Protocol). Exchange 5.5 uzywa˙ RPC. SMTP jest juz˙ zintegrowane z Windows 2000, podobnie jak NNTP. Konektor grup routingu z Exchange 2000 zastepuje˛ standardowy konektor. Dostepne˛ sa˛ nastepuj˛ ace˛ konektory:

◦ X.400 Connector (w MTA z Exchange 2000 juz˙ go nie ma)

◦ Microsoft Mail Connector

◦ CC:Mail Connector

◦ Lotus Notes Connector

◦ Novell Groupwise

Dla kazde˙ go serwera Exchange 2000 mozna˙ utworzyc´ do czterech grup zapisu, z których kazda˙ moze˙ posiadac´ do czterech baz danych. Ma to szczególne zalety, jesli´ chodzi o zabezpieczanie i odtwarzanie danych.

◦ Mozliwe˙ jest teraz indeksowanie bazy danych Exchange.

◦ Klastry Exchange moga˛ pracowac´ w trybie „activ - activ“.

◦ Outlook Web Access (OWA) obsługuje teraz WebDAV (Web Distributed Authoring and Versioning), kontynuacje˛ HTTP 1.1. Jesli´ chodzi o OWA zaleta polega na tym, ze˙ serwery Exchange mozna˙ skonﬁgurowac´ jako Frontend i BackEnd, dzieki˛ czemu same serwery OWA nie przechowuja˛ danych.

Ponadto mozna˙ teraz instalowac´ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 266

◦ usługi chat oraz

◦ usługi Instant Messaging.

Dzieki˛ nowemu, oddzielnemu wariantowi produktu, tj. „Exchange 2000 Conferencing Server“, mozna˙ przeprowadzac´ konferencje audio i wideo. Srodo´ wisko programistyczne Exchange 2000 zostało wzbogacone o

◦ ulepszone CDO (Collaboration Data Objects)

◦ rozszerzone mechanizmy Workﬂow

◦ XML

◦ wieksz˛ a˛ integracje˛ IIS (Internet Information Server) i ASP (Active Server Pages).

Uwagi odnosnie´ migracji Migracja z Exchange 5.5 do Exchange 200 jest skomplikowanym procesem, który wymaga intensywnego przygotowania, stworzenia koncepcji, planu migracji oraz testów zblizon˙ ych do warunków produkcyjnych. Niniejszy poradnik nie mozne˙ w pełni zaja˛c´ sie˛ w/w zadaniami, jednak nalezy˙ wskazac´ kilka wazn˙ ych aspektów migracji. Zanim to nastapi,˛ nalezy˙ jeszcze wprowadzic´ kilka deﬁnicji poje˛c.´ Sformułowanie aktualizacja Exchange 2000 oznacza instalacje˛ Exchange 2000 na serwerze Exchange 5.5. Natomiast aktualizacja systemu operacyjnego serwera oznacza instalacje˛ Windows 2000 na serwerze Win- dows NT 4. Z faktu, ze˙ Exchange 2000 mozna˙ stosowac´ tylko wówczas, gdy dostepn˛ y jest Windows 2000 Active Directory, wynikaja˛ m.in. nastepuj˛ ace˛ techniczne warunki brzegowe:

◦ struktura domen Windows 2000 Active Directory ma wiekszy˛ wpływ na Exchange 2000 niz˙ struktura domen w Windows NT na Exchange 5.5. Ogólna struktura (forest) tworzy granice organizacji Exchange, poniewaz˙ jak wiadomo wychodzace˛ poza granice domen informacje Global Catalog (GC) wystepuj˛ a˛ w Ogólnej Strukturze tylko raz.

◦ wybrana struktura OU domen Windows 2000 nie ma zasadniczo wpływu na migracje˛ do Exchange 2000. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 267

◦ wprowadzenie Exchange 2000 wymaga rozszerzenia schematu Active Directory. Rozsze- rzenie to mozna˙ przeprowadzic´ bez koniecznosci´ instalacji samego Exchange 2000 (poje-˛ cie: forestprep). Ponadto dana˛ domene˛ nalezy˙ przygotowac´ (pojecie:˛ domainprep).

◦ model domen Windows 2000 (Native vs Mixed Mode) wpływa na dostepno˛ s´c´ uniwersalnych grup i tym samym widocznos´c´ rozdzielaczy e - mail.

◦ aktualizacja Exchange 2000 moze˙ miec´ miejsce tylko wtedy, gdy wczesniej´ przeprowadzona została aktualizacja systemu operacyjnego. Exchange 2000 nie mozna˙ zainstalowac´ w Windows NT 4. W przeciwienstwie´ do tego, Exchange 5.5 moze˙ pracowac´ z Windows 2000.

◦ aktualizacja systemu operacyjnego serwera Exchange wymaga starannego zbadania (Se- rvice Packs etc.), zwłaszcza wówczas, gdy zainstalowane jest dodatkowe oprogramowanie innych producentów (np. oprogramowanie antywirusowe).

◦ Przed przystapieniem˛ do aktualizacji Exchange 2000, serwery Exchange musza˛byc´ człon- kiem domeny Windows 2000, wzglednie˛ członkiem Ogólnej struktury.

◦ Uzytko˙ wnicy musza˛ logowac´ sie˛ do Active Directory, jesli´ chca˛ bad˛ z´ maja˛ korzystac´ z Exchange 2000.

W ramach niniejszego poradnika nie przedstawilismy´ złozono˙ sci´ całego portfolio scenariuszy migracji (skomplikowane modele domen NT, wiele organizacji Exchange, Exchange w domenach zasobów, Exchange w kontrolerach domen, dzielone punkty centralne, Ogólna Struktura Windows 2000, etc.). Jednak na koncu´ wskazalismy´ narzedzia,˛ które moga˛ ułatwic´ migracje˛ bad˛ z´ współistnienie. Active Directory Connector (ADC) umozliwia˙ replikacje˛ hierarchii obiektów katalogowych z katalogu Exchange Server 5.5 do Active Directory. W zwiazku˛ z tym ADC odgrywa wazn˙ a˛role˛ w przypadku migracji Exchange 5.5 do Exchange 2000. Nalezy˙ zwrócic´ uwage˛ na to, ze˙ istnieja˛ dwie wersje ADCs (CD z Windows 2000 oraz CD z Exchange 2000). Jesli´ chodzi o migracje˛ do Exchange 2000, wazna˙ jest druga z w/w wersji. Domyslna´ replikacja (SRS) umozliwia˙ serwerom Exchange 2000 replikacje˛ konﬁguracji Exchange 5.5.

3.14.5.2 Exchange 2003

Exchange 2003 (Codename: Titanium), nastepca˛ Exchange 2000, ukazał sie˛ w 2003 roku. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 268

Ilos´c´ nowosci´ w porównaniu z Exchange 2000 jest stosunkowo mała. Powodem ukazania sie˛ Exchange 2003 było to, ze˙ wskutek zmian wprowadzonych w Windows 2003 w porówna- niu z Windows 2000, nie mozna˙ było instalowac´ Exchange 2000 na platformie Windows 2003. Oznacza to, ze˙ w Windows 2003 mozna˙ instalowac´ tylko Exchange 200354. Ponizsza˙ matryca kompatybilnosci´ stanowi przeglad˛ rózn˙ ych obsługiwanych kombinacji Exchange 5.5, Exchange 2000, Exchange Server 2003 oraz Windows Server 2003.

INSTALACJA I PRACA OBSŁUGIWANE S´ RODOWISKA EXCHANGE W ACTIVE DIRECTORY Windows Windows Windows 2000 Windows wersja 2000 SP3 Server SP3 Server 2003 Exchange albo 2003 albo w wyzszej˙ w wyzszej˙ Exchange 5.5 tak nie tak tak SP3 Exchange 2000 tak nie tak tak SP2 Exchange tak nie tak tak 2000 SP3 Exchange tak tak tak tak 2003

Tablica 3.57: Matryca kompatybilnosci´ Exchange55

Nastepuj˛ ac˛ y rysunek przedstawia mozliwo˙ sci´ srodo´ wisk mieszanych.

54Deutsches Whitepaper „Microsoft Exchange Server - kompatybilnos´c´ z Windows Server 2003“ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 269

Rysunek 3.29: Mieszane srodo´ wiska Exchange

Do nowosci´ w Exchange 2003 nalez˙a:˛

◦ Outlook Mobile Access (obecnie Microsoft Mobile Information Server 2002) jest cze˛sci´ a˛ Exchange Server 2003. Outlook Mobile Access oferuje uzytko˙ wnikom urzadze˛ n´ przenosn´ ych dostep˛ do ich informacji osobistych.

◦ Exchange Server 2003 umozliwia˙ serwerowi Internet Information Server (ISS wersja 6 z Windows 2003) nowa˛ forme˛ komunikacji pomiedzy˛ Outlookiem i Exchange, okreslan´ a˛ jako „RPC poprzez HTTP“. W ten sposób uzytko˙ wnik Outlook moze˙ bezposrednio´ i bez- piecznie synchronizowac´ swoje dane z Exchange Server 2003 poprzez połaczenie˛ HTTP.

◦ Obsługa klastrów w Windows 2000 Advanced Server jest ograniczona do dwóch wezłów˛ lub do czterech wezłów˛ , gdy wykorzystywany jest Windows 2000 Server DataCenter Edi- tion. Za pomoca˛ Windows 2003 i Exchange 2003 mozna˙ teraz realizowac,´ do wyboru,

56Zródło:´ Deutsches Whitepaper „Microsoft Exchange Server - kompatybilnos´c´ z Windows Server 2003“ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 270

klastry oparte na maksymalnie osmiu´ wezłów˛ z przynajmniej jednym wezłem˛ pasywnym, gdy wykorzystywany jest Exchange serwer 2003 wraz z Windows Serwer 20003 Enter- prise Edition.

◦ Exchange 2003 pracujac˛ y z Windows 2003 uzywa˙ usługi kopiowania cienia wolumenu i umozliwia˙ w ten sposób uzyskiwanie krótszych czasów zabezpieczania i odtwarzania danych w srodo´ wiskach Exchange.

3.15 Ofﬁce / Desktop

3.15.1 Przeglad˛

Jesli´ chodzi o zastapienie˛ MS Office 97 albo Office 2000, jak najbardziej celowe jest odczeka- nie do chwili, az˙ udostepnion˛ y zostanie MS Office 2003 i pojawia˛ sie˛ pierwsze doswiadczenia´ z MS Office 2003, zwłaszcza ze˙ zgodnie z zapowiedziami MS Office 2003 ukaze˙ sie˛ latem 2003 r. Oprócz aspektów wyłacznie˛ zwiazan˛ ych z kosztami, chodzi tu przede wszystkim takze˙ o aspekty techniczne wynikajace˛ ze zmian formatu dokumentu. Wraz z MS Office 2003 Microsoft planuje wypromowac´ XML, jako główny format dokumentów biurowych. Nie mozna˙ przy tym wykluczyc,´ ze˙ istniejace˛ dzisiaj problemy z kompatybilnosci´ a˛ wzgledem˛ alternatywnego rozwiazania˛ OSS OpenOffice.org bad˛ z´ jego komercjalnego odpowiednika StarOffice, zmniejsza˛sie˛ lub ewentualnie w ogóle przestana˛istniec.´ Jesli´ kontrola kompatybilnosci´ wymiany dokumentów MS Of- fice 20003 i OpenOffice 1.1, wzglednie˛ StarOffice 6.1 wypadnie pozytywnie, wówczas nalezy˙ zbadac´ kroki i nakłady zwiazane˛ z przeniesieniem starych dokumentów Office do MS Office 2003. W nastepn˛ ym kroku nalezy˙ skonfrontowac´ je z krokami i nakładami, jakie powszechnie znane sa˛ dzisiaj w przypadku przenoszenia w/w dokumentów do OOo / SO. Dopiero potem nalezy˙ podja˛c´ decyzje˛ o wyborze MS Office 2003 albo pakietu OOo / SO. Zastapienie˛ desktopu Microsoft zalezy˙ ostatecznie w duzej˙ mierze od tego, czy mozna˙ z jednej strony zastapi˛ c´ MS Office przez OOo / SO oraz czy z drugiej strony wymagane aplikacje windowsowe bed˛ a˛ długoterminowo dostepne˛ jako aplikacje linuksowe i jak dobrze mozna˙ je w tzw. miedzyczasie˛ udostepnia˛ c´ jako aplikacje windowsowe. Wymaga to jednak indywidualnego sprawdzenia. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 271

3.15.2 Wprowadzenie

Desktop jest dla uzytko˙ wników widocznym interfejsem, który udostepnia˛ im narzedzia˛ i aplikacje wykorzystywane w codziennej pracy. Na pierwszym planie znajduje sie˛ tu praca z pakietem Microsoft Ofﬁce (MS Ofﬁce). Jednak oprócz niego uzytko˙ wnicy moga˛korzystac´ takze˙ z rózn˙ ych innych standardowych narzedzi,˛ z funkcjonalnosci´ których nie mozna˙ zrezygnowac´ po migracji. Koniec konców´ istnieje jeszcze cały szereg aplikacji specjalistycznych, które sa˛ bardziej lub mniej silnie zintegrowane z desktopem i w przypadku których chodzi czesto˛ o aplikacje windowsowe, które nie bez problemów moga˛ pracowac´ w Linuksie. Z tego powodu nastepuj˛ ac˛ a˛ ocene˛ techniczna˛ podzielilismy´ na pie˛c´ cze˛sci:´

◦ punkt wyjscia´ MS Ofﬁce

◦ migracja zastepuj˛ aca˛ MS Ofﬁce

◦ migracja kontynuacyjna MS Ofﬁce

◦ inne aplikacje desktopowe

◦ aplikacje windowsowe w Linuksie.

3.15.3 Punkt wyjscia´ - MS Ofﬁce

MS Office udostepnian˛ y jest w postaci rózn˙ ych pakietów i wersji. W odróznieniu˙ od systemu operacyjnego nie nalezy˙ tu zakładac,´ ze˙ w wiekszo˛ sci´ urzedów˛ wykorzystuje sie˛ okreslon´ a˛ wersje˛ MS Office. Jednakze˙ mozna˙ wyjsć´ z załozenia,˙ ze˙ wersje˛ poprzedzajac˛ a˛ Microsoft Office 97 wykorzystuje sie˛ juz˙ bardzo rzadko, a Microsoft Office XP nadal jeszcze niezbyt czesto.˛ W przewazaj˙ acej˛ cze˛sci´ urzedów˛ zainstalowany jest Microsoft Office 97 albo 2000. Dlatego bed˛ a˛ one punktem wyjscia´ dla ponizszej˙ oceny migracji. Nowosci´ Microsoft Office XP w porównaniu z Office 2000 dotycza˛ w pierwszym rzedzie˛ interfejsu uzytko˙ wnika oraz pracy grupowej, przy czym cze˛sć´ dodatkowych funkcji w obszarze pracy grupowej pokrywa funkcjonalnosci´ Gro- upware, które zostały zastapione˛ innymi aplikacjami. Microsoft zaciesnia´ w ten sposób obszary Office i SharePoint Services57. Dla codziennej pracy skutkuje to jedynie nieznacznymi zmianami. Dlatego o nowych funkcjonalnosciach´ Office XP wspominamy tylko w wybranych kon- tekstach. 57Szczegóły odnosnie´ nowych Features w porównaniu z wczesniejszymi´ wersjami znajda˛ Panstwo´ na stronie: http://www.microsoft.com/germany/ms/officexp/prof/vergleich.htm ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 272

Oprócz wersji wazn˙ a˛ role˛ w ocenie migracji odgrywaja˛ rózne˙ pakiety Ofﬁce. Pakiety te róz-˙ nia˛ sie˛ od siebie z reguły zawartymi w nich pojedynczymi aplikacjami. Pojedyncze aplikacje

◦ Word

◦ Excel

oraz

◦ PowerPoint

zostały ocenione ponizej,˙ odpowiednio do sposobu migracji

◦ migracja zastepuj˛ aca˛ MS Ofﬁce

oraz

◦ migracja kontynuacyjna MS Ofﬁce,

w oparciu o pakiet Ofﬁce 2000 Professional. Outlook oceniony został w rozdziale 3.11 jako cze˛s´c´ składowa systemów Groupware i Messaging. Access przeanalizowana i oceniona została wraz z migracja˛ baz danych. Internet Explorer i PhotoEditor omówimy w podrozdziale „Inne aplikacje desktopowe“ razem z innymi narzedziami˛ desktopowymi. W tym samym podrozdziale autorzy wspominaja˛ takze˙ pokrótce o MS Project.

3.15.3.1 Funkcjonalnosci´

Z zamieszczenia listy funkcjonalnosci´ programów Word, Excel oraz Power Point musielismy´ w tym miejscu zrezygnowac.´ Zamiast tego w dwóch kolejnych rozdziałach wyszczególnione zo- stały najwazniejsze˙ róznice˙ pomiedzy˛ punktem wyjscia´ a mozliwymi˙ przyszłymi alternatywnymi rozwiazaniami˛ migracyjnymi. Na poczatku˛ nalezy˙ stwierdzic,´ ze˙ intensywne stosowanie specjalistycznego oprogramowania w urzedach˛ jest po cze˛sci´ rozszerzeniem funkcjonalnosci´ MS Office. Z jednej strony oznacza to, ze˙ srodo´ wisko programistyczne dostepne˛ wraz z MS Office wykorzystuje sie˛ w wielu urzedach˛ i innych organizacjach do tworzenia rozwiaza˛ n´ skryptowych, specyficznych dla doku- mentów (makra), co pozwala na zaawansowana˛automatyzacje˛ procesów pracy z MS Office. Jest to wystarczajace˛ do implementacji Workflows wykraczajac˛ ych poza dział. Z drugiej strony w urzedach˛ istnieje szereg zewnetrzn˛ ych rozwiaza˛ n,´ w przypadku których ma miejsce bardziej lub mniej silna integracja z Office. Dlatego ponizej˙ opisalismy´ pokrótce srodo´ wisko programistyczne MS Office. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 273

3.15.3.2 Sr´ odowisko programistyczne MS Ofﬁce

Srodo´ wisko programistyczne Microsoft Ofﬁce opiera sie˛ na jezyku˛ programowania BASIC. W swiecie´ kształtowanym przez Microsoft mówi sie˛ obecnie jezykiem˛ Visual Basic. Niniejsza ro- dzina jezyków˛ obejmuje aktualnie wiele dialektów:

◦ Visual Basic (Visual Studio, pełna wersja)

◦ Visual Basic for Application (VBA)

◦ Visual Basic Scripting Edition (VBS).

Wszystkie składaja˛ sie˛ z tego samego podstawowego słownictwa, jednak rózni˙ je zakres funkcji i srodo´ wisko pracy. Srodo´ wisko programistyczne MS Office zawiera Visual Basic for Application (VBA). Micro- soft udostepnia˛ licencje˛ VBA, dlatego inni producenci moga˛włacza˛ c´ VBA do swoich produktów. Za punkt wyjscia´ w niniejszym poradniku przyjeli˛ smy´ korzystanie z pakietu Office 97. We wczesniejszych´ wersjach udostepniane˛ były rózne˙ srodo´ wiska programistyczne dla poszczegól- nych produktów (Word Basic, Excel VBA, Access Basic). Wraz z Office 97 ujednolicono srodo-´ wisko programistyczne do VBA w wersji 5. Ponizsza˙ tabela pokazuje powiazanie˛ wersji VBA z rózn˙ ymi wersjami Office.

WERSJE OFFICE WERSJE VBA 95 Word Basic, Excel VBA, Access Basic 97 5 2000 6 XP 6.3

Tablica 3.59: Wersje VBA

W nastepuj˛ ac˛ ych paragrafach opiszemy przede wszystkim VBA i specjalnie oddzielimy go od dwóch innych wariantów Visual Basic (pełna wersja i Scripting Edition).

Podstawowe załozenia˙ VBA VBA jest jezykiem˛ interpretowanym, który mozna˙ wykonywac´ tyko w aplikacjach Ofﬁce. VBA opiera sie˛ o COM (Component Object Model), kontynuacje˛ technologii OLE (Object Li- nuking and Embedding). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 274

Office umie nie tylko korzystac´ z obiektów COM, lecz sam takze˙ oferuje obiekty COM. Of- fice 97 dostarcza ponad 550 własnych obiektów COM, Office 2000 ponad 600. Poprzez COM, w pakiecie Office mozna˙ uzywa˙ c´ takze˙ zewnetrzne˛ funkcjonalnosci.´ Za pomoca˛VBA mozliwe˙ jest korzystanie z zewnetrzn˛ ych programów (np. systemu operacyjnego) w formie DLLs (Dynamic Link Libraries)58. Nastepuj˛ ac˛ y rysunek raz jeszcze przedstawia zdolnosć´ VBA do korzystania z funkcjonalnosci.´

Rysunek 3.30: VBA w aplikacji Ofﬁce

Poszczególne elementy VBA dziela˛ sie˛ na:

◦ moduły (moduls)

◦ moduły klas (class moduls)

oraz

◦ formularze (forms).

W modułach znajduje sie˛ „normalny“ kod programu. W modułach klas mozna˙ tworzyc´ własne obiekty, jak tez˙ ich własciwo´ sci´ i metody. Elementy te umozliwiaj˙ a˛rozszerzanie funkcjonalnosci´ dostarczanych przez MS Office, automatyzacje˛ kolejnosci´ wywołan´ funkcji oraz implementowa- nie dodatkowych funkcjonalnosci.´ Rozszerzenia, uzupełnienia i kod automatyzujac˛ y nazywane sa˛ makrami albo skryptami. Aby zintegrowac´ makra z MS Office mozna˙ modyfikowac´ paski menu i przyciski na paskach zadan,´ dzieki˛ czemu uzytko˙ wnik jest w stanie łatwiej je uruchamiac.´ 58W Visual Basic Script (VBS) takie połaczenie˛ nie jest mozliwe.˙ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 275

Specjalne nazwy procedur (np. AutoOpen. AutoNew) oznaczaja˛ kod programu, który jest wykonywany automatycznie podczas otwierania plików Ofﬁce. Czesto˛ korzysta sie˛ z tego w szablonach (Templates), co niesie ze soba˛ zagrozenie˙ tak zwanymi „makrowirusami“. Podsumowujac,˛ makra i skrypty moga˛ byc´ wywoływane w Ofﬁce bad˛ z´ integrowane z nim w nastepuj˛ ac˛ ych formach:

◦ jako Add - In

◦ wewnatrz˛ szablonów (Templates)

◦ jako asystenci (Wizards).

Add Ins mozna˙ jeszcze podzielic´ ze wzgledu˛ na ich zastosowanie na:

◦ COM Add - Ins oraz

◦ aplikacyjne Add - Ins.

COM Add - Ins sa˛ skompilowanymi plikami DLL albo EXE, które mozna˙ tworzyc´ za pomoca˛ Visual Basic (pełna wersja). Add - Ins mozna˙ stosowac´ poza granicami aplikacji. Aplikacyjne Add - Ins tworzy sie˛ za pomoca˛ zintegrowanego srodo´ wiska programistycznego Office i mozna˙ ich uzywa˙ c´ tylko wewnatrz˛ Office. Z Add - Ins nalezy˙ korzystac´ z reguły tam, gdzie kod programu ma byc´ stale dostepn˛ y w aplikacji, tak aby uzytko˙ wnik nie musiał uruchamiac´ szablonów. Nastepuj˛ ac˛ y rysunek raz jeszcze prezentuje mozliwe˙ rozszerzenia w MS Office uzyskiwane za pomoca˛ własnych programów.

Rysunek 3.31: Mozliwe˙ rozszerzenia w Ofﬁce ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 276

Sr´ odowisko programowania Za pomoca˛ VBA w wersji 5 z aplikacjami Ofﬁce zintegrowane zostało jednolite srodo´ wisko programowania. Tak zwane IDE (Integrated Development Enviroment) uruchamiane jest w oddzielnym oknie, ale działa w tym samym obszarze pamieci˛ co aplikacja Ofﬁce. IDE oferuje:

◦ edytor ze sprawdzaniem i kolorowaniem składni

◦ Project Explorer

◦ dodatkowe okno własciwo´ sci´

◦ narzedzia˛ debuggera

◦ Object Browser

◦ warunkowa˛ kompilacje˛

◦ mechanizmy chroniace˛ przed zmienianiem albo kopiowaniem napisanego kodu oraz

◦ IntelliSense (uzupełnianie, wybór metoda˛ Drop - Down, informacja o składni)

Oprócz wspomnianego edytora, do tworzenia prostego kodu programu mozna˙ takze,˙ wewnatrz˛ aplikacji, uzywa˙ c´ Makro - Rekorder.

Zdalne sterowanie Poniewaz˙ sam Ofﬁce składa sie˛ z wielu obiektów COM, mozliwe˙ jest zdalne sterowanie Of- ﬁce, czyli wprowadzenie automatyzacji COM. Do zdalnego sterowania mozna˙ wykorzystywac,´ np. Windows Scripting Host (WSH) albo PerlScript

3.15.4 Migracja zastepuj˛ aca˛

3.15.4.1 Wprowadzenie

Istnieja˛najrózniejsze˙ pakiety oprogramowania biurowego, wzglednie˛ aplikacje (np. edytory tekstu), które sa˛ dostepne˛ dla systemu operacyjnego Linux jako wolne albo własnoscio´ we oprogramowanie. Sa˛ to miedzy˛ innymi: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 277

◦ OpenOfﬁce

◦ StarOfﬁce

◦ Kofﬁce

◦ GnomeOfﬁce

◦ ThinkFreeOfﬁce

◦ i inne.

Jednak rzeczywista˛ alternatywe˛ dla MS Office Suite stanowia,˛ z dzisiejszego punktu widzenia oraz zgodnie z opinia˛ wszystkich ekspertów, pakiety OpenOffice.org (OOo) bad˛ z´ oparty na nim StarOffice (SO). Dlatego w niniejszym poradniku szczegółowo ocenimy tylko te dwa pakiety. OpenOffice dostepn˛ y jest obecnie w wersji 1.0.3. Jego odpowiednikiem jest StarOffice 6.0. Obydwie wersje mozna˙ takze˙ stosowac´ w systemach operacyjnych Windows NT, 2000 i XP. Poniewaz˙ OOo / SO korzystaja˛ we wszystkich systemach operacyjnych z tych samych funkcjonalnosci´ oraz formatów plików, ułatwia to „łagodna“˛ migracje,˛ o ile w pierwszym kroku zaste-˛ powany jest tylko pakiet Office. Nowe wersje 1.1 (OOo) i 6.1 (SO) dostepne˛ sa˛juz˙ w wersji beta, a ich ostateczna wersji ma byc´ udostepniona˛ w lipcu 2003 r.

Róznice˙ pomiedzy˛ OpenOffice a StarOffice Rozwój podstawowej technologii obydwu Office Suites odbywa sie˛ po stronie OpenOffice.org. W roku 2000 firma Sun Microsystems udostepniła˛ kod zródło´ wy ówczesnego pakietu biurowego StarOffice 5.2 i przekształciła go w projekt OpenOffice.org. Projekt OpenOffice.org posiada dwie licencje:˛ GPL i SISL (GNU Public License bad˛ z´ Lesser GNU Public License oraz Sun Industrie Source License). Podwójne licencjonowanie umozliwia˙ z jednej strony tworzenie w oparciu o OpenOffice.org produktów komercyjnych, a z drugiej strony gwarantuje jednolitosć´ specyfikacji API i formatu plików, które sa˛wia˛z˙ace˛ dla OpenOffice.org i wszystkich programów pochodnych. Dla StarOffice firma Sun stworzyła bad˛ z´ dołaczyła˛ dodatkowe składniki oraz opakowanie bed˛ ace˛ profesjonalna˛ gwarancja˛ jakosci,´ obszerna˛ dokumentacje,˛ wsparcie techniczne i oferty szkolen.´ Niektórymi z w/w składników firmy Sun sa:˛

◦ TrueType Fonts, które sa˛ zblizone˙ do czcionek Microsoftu (patrz rys. 3.32)

◦ własne sprawdzanie pisowni i thesaurus, OpenOfﬁce korzysta najcze˛sciej´ z MySpell (LGPL)

◦ dodatkowe szablony i galerie˛ obrazów ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 278

◦ baze˛ danych ADABAS.

Ponadto Sun dostarcza łaty naprawiajace˛ błedy˛ albo poprawiajace˛ bezpieczenstwo´ danej wersji produktu. Dzieki˛ temu obecnie co trzy miesiace˛ pojawia sie˛ dla StarOffice nowy zestaw łat, który poprawia bezpieczenstwo,´ błedy˛ w programach albo filtry importu. W przeciwienstwie´ do tego OpenOffice.org zawiera niniejsze składniki kazdorazo˙ wo tylko w najnowszych wersjach59.

Rysunek 3.32: Fontmapping MS Ofﬁce OOo / SO

W przeciwienstwie´ do uwolnionego OpenOffice.org Suite, StarOffice Suite jest dostepn˛ y wy- łacznie˛ odpłatnie. Wsparcie techniczne dostepne˛ jest z reguły tylko za opłata˛ w obydwu przypadkach. Wsparcie techniczne w przypadku StarOffice uzyskac´ mozna,˙ m.in. bezposrednio´ od firmy Sun a w przypadku OpenOffice.org tylko od innych producentów.

Cze˛sci´ składowe OOo, wzglednie˛ SO OOo i SO składaja˛ sie,˛ tak jak MS Ofﬁce, z rózn˙ ych aplikacji. Nalez˙a˛ do nich:

◦ edytor tekstu (Writer)

◦ arkusz kalkulacyjny (Calc)

◦ edytor prezentacji (Impress)

59Dalsze szczegóły nt. róznic˙ znalez´c´ mozna˙ na stronie http://marketing.openoffice.org/ conference/presentationspdf/thu1500/SOvsOOo.pdf 60Zródło:´ http://SunMicrosystems.com ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 279

◦ edytor formuł matematycznych61 (Math)

◦ edytor graﬁki62 (Draw)

◦ baza danych63 (Adabas)64.

W centrum ponizszych˙ rozwaza˙ n´ znalazły sie˛ jednak tylko trzy pierwsze moduły. Jesli´ chodzi o istotne funkcjonalnosci,´ trzy w/w Office Suites sa˛ takie same, zwłaszcza w przypadku funkcjonalnosci´ wykorzystywanych przez wiekszo˛ sć´ uzytko˙ wników. Wiekszo˛ sć´ uzyt-˙ kowników z reguły uzywa˙ takiego samego, waskie˛ go zestawu funkcji z całego dostepne˛ go zakresu. W nastepuj˛ ac˛ ych rozdziałach dokładnie prezentowane sa˛najwazniejsze˙ róznice˙ pomiedzy˛ MS Office i OOo / SO. Poradnik ogranicza sie˛ przy w pierwszym rzedzie˛ do modułów edytor tekstu, arkusz kalkulacyjny i edytor prezentacji. Mozliwo˙ sci´ zastapienia˛ modułu MS Access przez inny system bazodanowy omówilismy´ blizej˙ w rozdziale 3.13. Inne moduły MS Office Suite i aplikacje desktopu Microsoft opisalismy´ w rozdziale 3.15.6.

3.15.4.2 Róznice˙ w formacie plików w porównaniu z MS Ofﬁce

Kazda˙ wersja Microsoft Office stosuje własny binarny format pliku, w którym w postaci ustrukturyzowanych danych zapisywane sa:˛ tekst, atrybuty, wbudowana grafika, metadane i elementy Layout. W przeciwienstwie´ do tego OpenOffice.org bad˛ z´ StarOffice 6.0 (OOo / SO) uzywa˙ formatu pliku opartego na XML, który zapisuje tresć´ w postaci tekstu, co oznacza, ze˙ mozna˙ go czytac´ i zmieniac´ bez koniecznosci´ wykorzystywania OOo / SO do dekodowania i odczytu. Doku- mentacja w/w formatu jest publicznie udokumentowana i ogólnie dostepna˛ jako cze˛sć´ projektu OpenOffice.org. Format plików OOo / SO oparty na XML zapisuje tresć,´ layout i informacje odnosnie´ formatowania kazde˙ go dokumentu w postaci kompletu XML - Streams albo poddokumentów. Aby uzytko˙ wnik mógł w łatwy sposób korzystac´ z rózn˙ ych dokumentów i XML - Streams – z pominieciem˛ wbudowanych, binarnych grafik i danych obcego pochodzenia (o ile wystepuj˛ a)˛ –, sa˛one pakowane i przechowywane w znanym formacie ZIP. Jednakze˙ nazwy plików tworzonych przez OOo / SO nie otrzymuja˛ rozszerzenia „.zip“, lecz tak jak w MS Office rózne˙ rozszerzenia pochodzace˛ od poszczególnych aplikacji (patrz tab. 3.61).

61Funkcje, jakie oferuje Math, zintegrowane sa˛z Microsoft poprzez własny edytor, który mozna˙ wywołac´ poprzez Wstaw / Obiekt / Nowy / Edytor formuł Microsoft. 62Funkcje, jakie oferuje Draw sa˛ zintegrowane z Microsoft, np. poprzez ikony z paska narzedzio˛ wego. 63Nie wystepuje˛ w OpenOfﬁce.org 64Nie da sie˛ bezposrednio´ porównac´ z Access z Windows. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 280

TYP DOKUMENTU APLIKACJA ROZSZE- APLIKACJA OOO / SO ROZSZE- MS OFFICE RZENIE RZENIE edytor tekstu Word doc / dot Writer sxw / stw arkusz kalkulacyjny Excel xls / xlt Calc sxc / stc edytor prezentacji Power Point ppt / pot Impress sxi / sti

Tablica 3.61: Rozszerzenia plików najwazniejszych˙ aplikacji Ofﬁce

Ponadto w OOo / SO istnieja˛ jeszcze aplikacje Draw i Math, które w MS Ofﬁce sa˛ cze˛sci´ a˛ trzech w/w aplikacji podstawowych i których nie mozna˙ oddzielnie bezposrednio´ przyporzad-˛ kowac.´ Za pomoca˛ Draw mozna˙ tworzyc´ rysunki (sxd / std), za pomoca˛ Math formuły matema- tyczne (sxm / stm). Obiekty Draw i Math mozna˙ takze˙ włacza˛ c´ do innych dokumentów OOo / SO i tam je edytowac.´ Poniewaz˙ dokumenty OOo / SO sa˛ własciwie´ plikami ZIP, mozna˙ je rozpakowywac´ dowolnym programem UNZIP.

Rysunek 3.33: Zawartos´c´ pliku OOo / SO wyswietlana´ w przegladarce˛ plików ZIP.

O ile wbudowana została graﬁka lub obiekty, sa˛ one składowane w katalogu „Pictures“ bad˛ z´ „Objects“. Znajduje sie˛ tu odnosnik´ (href - link) do odpowiednich podporzadko˛ wanych plików. Typowy dokument OOo / SO, który nie zawiera wbudowanych obiektów lub graﬁk, składa sie˛ z 5 XML - Streams: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 281

◦ content.xml Zapisuje główna˛ tresć´ dokumentu, łacznie˛ z tekstem z tabel i elementami graficznymi. O ile jednak istnieje wbudowana grafika lub obiekty, wówczas składowane sa˛one w katalogu Pictures bad˛ z´ Objects i znajduje sie˛ tu odnosnik´ (href - link) do odpowiednich podporzad-˛ kowanych plików.

◦ styles.xml Zapisuje własciwo´ sci,´ atrybuty wszystkich stylów znaków, rozdziałów, stron, obiektów i numerowania, które zostały zastosowane w dokumencie.

◦ meta.xml Zapisuje ogólne informacje o dokumencie, łacznie˛ z tytułem, rodzajem, pozycja,˛ uzyt-˙ kownikiem, czasem ostatniej aktualizacji i inne. Tres´c´ tego pliku odnosi sie˛ do informacji, które podaje sie˛ poprzez maske˛ Plik / Własciwo´ sci.´

◦ settings.xml Zapisuje dla danego dokumentu ustawienia dokumentu i widoku specyﬁczne dla aplikacji oraz zadane własciwo´ sci´ drukarki i opcje drukowania, poziom powiekszenia˛ oraz wielkos´c´ okna.

◦ manifest.xml Zapisuje dodatkowe informacje o plikach XML, takie jak rodzaj MIME i metoda szyfrowania. Podobnie, jak w przypadku plików bitmapowych i plików obiektów, takze˙ ten plik zapisywany jest w swoim własnym katalogu.

Jesli´ dokument zawiera równiez˙ makra, wówczas w pakiecie znajda˛ sie˛ kolejne XML - Stre- ams65.

3.15.4.3 Ograniczenia ﬁltrów konwertujacych˛ (ﬁltrów importu)

Aby umozliwi˙ c´ konwertowanie formatów plików, z OOo / SO zintegrowano rózne˙ konwertery (filtry), które pozwalaja˛otwierac´ i edytowac´ dokumenty MS Office w OOo / SO, a nastepnie˛ zapisywac´ je ponownie jako dokumenty MS Office. Ponadto mozliwy˙ jest takze˙ import szablonów dokumentów MS oraz ich edycja. Pliki mozna˙ zapisywac´ bad˛ z´ to w formacie MS Office 97 / 2000 / XP bad˛ z´ w formacie OOo / SO.

65Dalsze informacje o formacie XML z OOo / SO znalez´c´ mozna˙ na stronie http://xml.openoffice.org (ogólnie), http://xml.openoffice.org/xml_specification_draft.pdf (szczegóły techniczne) i http://xml.openoffice.org/package.html (format pliku Zip). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 282

Ogólnie mówiac˛ jakosć´ konwersji jest akceptowalna, o ile nie mamy do czynienia z dokumentami zawierajac˛ ymi makra i specjalnymi Features formatów. W MS Office Istnieje bowiem pare˛ własciwo´ sci´ layoutu oraz atrybutów formatowania, które w OOo / SO nie sa˛ obsługiwane albo sa˛inaczej traktowane. Wskutek tego, po przeprowadzeniu konwersji, konieczne jest w pewnym stopniu nanoszenie reczn˛ ych korekt umozliwiaj˙ ac˛ ych uzyskanie formatu dokumentu wyjscio´ wego. 100% - owego konwertowania nie mozna˙ oczekiwac´ zwłaszcza w przypadku skomplikowanych i specyficznych własciwo´ sci´ dokumentu, takich jak indeksy, fields, ramki i tabele. Ponadto w niektórych przypadkach, podczas konwersji podstawowych atrybutów i formatowan,´ takich jak krawedzie˛ stron albo odstepy˛ pomiedzy˛ akapitami, moga˛ pojawic´ sie˛ róznice˙ pomie-˛ dzy oryginałem a konwertowanym dokumentem. W nastepuj˛ acej˛ tabeli pokazane zostały własciwo´ sci´ MS Office, które wymagaja˛ reczne˛ go poprawienia automatycznej konwersji.

APLIKACJA WŁAS´ CIWOS´ CI

◦ AutoShapes

◦ Revision marks

◦ Obiekty OLE

◦ Kilka pól kontrolnych i pól formularzy

Microsoft Word ◦ Indeksy

◦ Tabele, ramki oraz formatowanie wielokolumnowe

◦ Hiperlinki i zakładki

◦ Graﬁki WordArt

◦ Animowany tekst ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 283

◦ AutoShapes

◦ Obiekty OLE

◦ Kilka pól kontrolnych i pól formularzy

Microsoft Excel ◦ Tabele Pivot

◦ Nowe typy Chart

◦ Formatowania w zalezno˙ sci´ od tresci´

◦ Niektóre funkcje i formuły

◦ AutoShapes

◦ Odstepy˛ pomiedzy˛ tabulatorami, wierszami i akapitami

Microsoft PowerPoint ◦ Wzorzec graﬁki w tle

◦ Grupy obiektów

◦ Niektóre efekty multimedialne

Tablica 3.63: Własciwo´ sci´ MS Ofﬁce mogace˛ sprawic´ problemy podczas konwersji do OOo / SO

3.15.4.4 Róznice˙ w działaniu

Jesli´ chodzi o zasade˛ działania, nie ma zasadniczych róznic˙ pomiedzy˛ MS Ofﬁce i OOo / SO. Obydwa systemy opieraja˛sie˛ na trójpoziomowej architekturze, która składa sie˛ z samej aplikacji, szablonów dokumentów i dokumentów. Na najnizszym˙ poziomie znajduje sie˛ warstwa aplikacji, która dostarcza narzadzi˛ oraz własciwo´ sci´ potrzebnych do tworzenia dokumentów i szablonów. Na kolejnym poziomie znajduja˛ sie˛ szablony, które moga˛ zawierac´ wiele makr, formatowan´ i ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 284

ustawien´ pomocnych przy tworzeniu nowych dokumentów, które z kolei na najwyzszym˙ poziomie równiez˙ moga˛ zawierac´ kolejne obiekty, makra, formatowania i ustawienia uzytko˙ wnika rozszerzajace˛ funkcjonalnosć´ szablonów. Tym, czym rózni˙ a˛sie˛ obydwa Office Suites sa˛własciwo´ sci´ i funkcje udostepniane˛ przez w/w pakiety biurowe. W wielu przypadkach róznice˙ te mozna˙ przypisac´ projektowi i rózn˙ ym mode- lom obiektów, w oparciu o które powstaja˛niniejsze aplikacje. W przewazaj˙ acej˛ cze˛sci´ w obydwu pakietach istnieja˛ odpowiedniki poszczególnych własciwo´ sci´ i funkcji drugiego produktu. Nastepuj˛ aca˛ tabela (tab. 3.65) prezentuje typy szablonów i formatów z MS Office i z OOo / SO pogrupowane według aplikacji.

Typ MS Word OOo / SO MS OOo / SO MS OOo / SO Writer Excel Calc Power Impress Point domysln´ y normal. hardcoded bOOok.xlt hardcoded blank.pot hardcoded szablon dot sheet.xlt dokumentu szablon szablony szablony dokumentów rózne˙ rózne˙ rózne˙ rózne˙ tresci´ / tresci´ / projektu projektu szablony N/a strona strona / strona / N/a66 szablony formatu arkusz arkusz graﬁki

akapit akapit komórka komórka N/a prezentacja

lista numerowanie znaków67 znaków N/a ramki68 tabela69 tabela

Tablica 3.65: Porównanie dostepn˛ ych typów szablonów i formatów 66PowerPoint dostarcza predefiniowany schemat kolorowej animacji, który obowiazuje˛ dla całej prezentacji. W przeciwienstwie´ do tego, Impress definiuje wyswietlanie´ graficznego obrazu oraz pojedynczych obiektów za pomoca˛ stylów . 67Tylko w MS Office XP. 68Ramki sa˛ wbudowanymi obiektami zamknietymi˛ w niewidocznej formie. 69Tylko w MS Office XP. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 285

W ponizszej˙ tabeli (tab. 3.67) zgromadzone zostały róznice˙ pomiedzy˛ kluczowymi funkcjami. Róznice˙ w działaniu oraz pozostałe róznice˙ zostały obszernie opisane w „StarOfﬁce 6.0 Migration Guide“70.

WŁAS´ CIWOS´ CI UWAGI MS Office dysponuje makrorekorderem. OpenOffice 1.01 i StarOffice 6.0 nie posiada makrorekordera. Jest makrorekorder on przewidziany w nastepnej˛ wersji i zaimplementowany w obecnej wersji beta. OOo / SO z powodu róznic˙ w obydwu modelach obiektu nie ob- sługuje makr VBA. Wszystkie makra VBA przeznaczone do dal- makra oparte na doku- szego uzytku˙ nalezy˙ przekształcic´ (recznie).˛ mentach Dokumenty OOo / SO moga˛ jednak zawierac´ makra napisane we własnym jezyku˛ programowania (StarBasic). Jednak podczas importu lub eksportu makra VBA nie gina.˛ MS Office korzysta z „Escher 3D Graphic - Engine“, który nie jest identyczny z 3D - Engine z OOo / SO. W wyniku tego moga˛ powstawac´ niewielkie róznice˙ w prezentacji obiektów 3D impor- grafika 3D towanych z MS Office. Filtry dostepne˛ w OOo / SO nie obsługuja˛ eksportu obiektów 3D w formacie Escher 3D. OOo / SO i MS wykorzystuja˛ rózne˙ modele tabel, co moze˙ doprowadzic´ do niewielkich róznic˙ podczas ich wyswietlania.´ Na- stepuj˛ ace˛ Features MS nie sa˛ obsługiwane w OOo / SO.

◦ tabela (MS Word) zmiana stron w wierszu ◦ wzorzec tła w komórkach

Wyswietlanie´ ramek moze˙ rózni˙ c´ sie˛ po konwersji, poniewaz˙ OOo / SO nie obsługuje wszystkich typów linii z MS Word. W Word mozna˙ ustawiac´ rózn˙ y format dla znaków z listy i dla formaty znaków tresci´ list. Writer realizuje to poprzez przydzielanie własnego for- (MS Word) matu znaków dla znaków z listy.

70http://uk.sun.com/software/staroffice/pdf/somigrationguide.pdf ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 286

Z reguły odstepy˛ miedzy˛ znakami w Word sa˛ mniejsze niz˙ odstepy˛ miedzy˛ znakami w edytorze Writer. Obydwie aplikacje ko- metryka znaków rzystaja˛ takze˙ z rózn˙ ych jednostek miary przy ustalaniu piono- i odstepów˛ wych odstepów˛ (Word = punkty, OOo / SO = cale). Przez to ilosć´ (MS Word) wierszy w w/w aplikacjach moze˙ byc´ rózna˙ w przypadku tego samego dokumentu. Pojedynczy arkusz w Calc moze˙ zawierac´ maksymalnie 32.000 rozmiar arkusza wierszy. W przeciwienstwie´ do tego limit w Excelu wynosi (MS Excel) 65.535 wierszy. W przypadku importu arkusza Excel mieszcza-˛ cego ponad 32.000 wierszy, Calc dzieli wpisy na wiele arkuszy. Excel obsługuje tabele Pivot słuz˙ace˛ do złozonej˙ analizy danych. W Calc istnieje porównywalne narzedzie˛ „Datapilot“, które po- tabele Pivot siada jednak mniej funkcji i nie obsługuje tworzenia dynamicz- (MS Excel) nych Charts. W przypadku importu dokumentu Excel, w którym znajduje sie˛ wiele tabel Pivot, gina˛ funkcjonalnosci.´ Chart-Engine w Calc nie jest tak wydajny, jak jego odpowiednik typy Chart w Excelu. W Calc71 nie ma odpowiedników dla całego szeregu (MS Excel) typów Chart obsługiwanych w Excelu. W przeciwienstwie´ do Calc, Excel obsługuje funkcje z brakuja-˛ cymi opcjonalnymi parametrami. OOo / SO kwituje to podczas parametry opcjonalne konwersji komunikatem błedu.˛ W przypadku danych funkcji, w miejscu, gdzie brakuje opcjonalnego parametru, trzeba recznie˛ wpisac´ obowiazuj˛ ac˛ a˛ wartosć´ domysln´ a.˛ PowerPoint 2002 wykorzystuje funkcjonalnosć´ Timeline, która umozliwia˙ animacje˛ obiektów w sci´ sle´ okreslon´ ym czasie. W Timeline OOo / SO nie istnieje porównywalny Feature. (MS PowerPoint Ponadto w PowerPoint XP mozna˙ definiowac´ rózne˙ interwały 2002) czasu dla rózn˙ ych obiektów. W aktualnej wersji Impress mozna˙ ustalic´ ustalic´ interwał czasu jedynie dla wszystkich obiektów.

71Szczegóły znalez´c´ mozna˙ w „StarOfﬁce 6.0 Migration Guide“, strona 56 - 69. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 287

Zarówno Writer, jak i Word obsługuja˛ stosowanie tak zwanych „Merge Documents“, chodzi tu o łaczenie,˛ np. arkuszy kalkulacyjnych Excel z dokumentem Word. Funkcjonalnosć´ ta jest nieco Merge Documents inaczej zaimplementowana w edytorze Word niz˙ w edytorze Wri- (MS Word) ter, a dostepne˛ filtry nie obsługuja˛ tej funkcjonalnosci.´ Wpraw- dzie odpowiednie dokumenty sa˛ importowane razem z połaczo-˛ nymi polami, jednak połaczenie˛ z plikiem danych trzeba zesta- wiac´ recznie.˛ Makr utworzonych w MS Office nie mozna˙ wykonywac´ w OOo / SO. W OOo / SO makra te trzeba, o ile po konwersji maja˛byc´ one nadal stosowane, ponownie recznie˛ utworzyc´ albo dostosowac´ do StarBasic. W OOo / SO do tworzenia makr udostepniane˛ jest odpowiednie Makra VBA srodo´ wisko programowania, które mozna˙ wywołac´ poprzez Do- datki / Makra i przyciskiem „Edycja“. Zasadniczo jednak w srodo´ wisku mieszanym (MS Office – OOo / SO) mozna˙ korzystajac˛ z OOo / SO otwierac,´ czytac,´ edytowac´ i zapisywac´ dokumenty MS Office, bez gubienia albo niszczenia istniejac˛ ych makr VBA.

Tablica 3.67: Róznice˙ w kluczowych funkcjonalnosciach´

3.15.4.5 Wazne˙ kryteria analizy stanu

Zanim podjeta˛ zostanie zasadnicza decyzja za lub przeciw migracji, po której bedzie˛ mogło nastapi˛ c´ szczegółowe planowanie, w ramach analizy stanu nalezy˙ sprawdzic:´

◦ co powinno podlegac´ migracji

◦ czy migracja jest mozliwa˙

oraz

◦ jakie nakłady sa˛ z tym zwiazane.˛ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 288

Podczas analizy stanu nalezy˙ zbadac,´ wzglednie˛ usystematyzowac´ dokumenty według nastepu-˛ jac˛ ych kryteriów:

◦ dostepno˛ s´c´ dokumentów

– dokumenty, które ewentualnie trzeba nadal edytowac´ Konwersja tych dokumentów moze˙ miec´ sens. – Dokumenty, które maja˛ byc´ jeszcze co najwyzej˙ czytane Dokumenty te, przynajmniej w przypadku migracji, nalezy˙ zarchiwizowac´ bad˛ z´ przekonwertowac´ do formatu PDF albo mozna˙ rozwazy˙ c´ obydwie te mozliwo˙ s´c.´ Dzieki˛ temu zmniejsza˛ sia˛ nakłady.

◦ stopien´ skomplikowania dokumentów

– proste dokumenty Nie zawieraja˛ one makr, własnoscio´ wej grafiki (jak, np. WordArt), grafiki wektoro- wej, skomplikowanych formatowac´ czy elementów, takich jak przypisy, tabele albo indeksy. Najlepiej jest przekształcac´ je za pomoca˛ konwersji Batch (patrz paragraf „Sposoby konwersji“ w podrozdziale 3.15.4.7). – skomplikowane dokumenty zawieraja˛ one makra, wspólne składniki, formatowania akapitów i stron, własno- scio´ wa˛oraz wektorowa˛grafike,˛ wiele dowiaza˛ n´ symbolicznych i odnosników´ , obiekty OLE, ramki, Text - Boxes, przypisy, aktywne składniki, Form Fields, Formular - Con- trols, formularze czy tabele, słowem cała˛ mase˛ rózn˙ ych formatowan´ i elementów. Dokumenty te wymagaja˛ z reguły dodatkowego planowania i nalezy˙ oceniac´ oraz przenosic´ pojedynczo.

◦ stopien´ skomplikowania szablonów

– proste szablony Proste szablony składaja˛sie˛ z generic text i odpowiedniego formatowania, które słuzy˙ jako punkt wyjscia´ albo zgrubny projekt dla nowych dokumentów. Dobrym tego przykładem sa,˛ np. szablony listów, podstawowe raporty albo protokoły. Dla prostych szablonów dostepne˛ sa˛ takie same opcje konwertowania, jak w przypadku prostych dokumentów. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 289

– skomplikowane szablony Skomplikowane szablony zawieraja˛ Form Fields i makra, które nie zawsze dadza˛ sie˛ przenies´c´ i które trzeba od nowa utworzyc´ za pomoca˛ srodo´ wiska programowania udostepniane˛ go przez OOo / SO albo poddac´ procesowi Reengineering.

Korzystanie z zewnetrzn˛ ych zródeł´ danych

Na ogół trzeba je przyłacza˛ c´ od nowa. Mozna˙ to zrobic´ bez problemu. Do wspomnianych zródeł´ danych zaliczaja˛ sie˛ m.in. bazy danych i dokumenty Excel.

Integracja zewnetrzne˛ go oprogramowania

W tym przypadku z jednej strony nalezy˙ zbadac´ zakres integracji i ilosć´ aplikacji, które maja˛ wzia˛c´ w niej udział, a z drugiej strony nalezy˙ sprawdzic´ dostepno˛ sć´ tekstu zródło´ wego pod ka-˛ tem integracji z OOo / SO. Jesli´ oprogramowanie zewnetrzne˛ komunikuje sie˛ z MS Office dzieki˛ automatyzacji interfejsu OLE / COM, wówczas zamiast MS Office mozna˙ do wspomnianego interfejsu podłaczy˛ c´ OOo / SO. Wywoływane funkcje MS Office nalezy˙ przeniesć´ do odpowiednich wywołan´ OOo / SO.

3.15.4.6 Przygotowanie do konwersji

Jesli´ chodzi o layout, powstawanie wielu róznic˙ widocznych po konwersji, spowodowane jest posługiwaniem sie˛ „niefachowa“˛ technika˛ formatowania. Aby wierniej odtwarzac´ layout dokumentu nalezy˙ , wzglednie˛ nalezało˙ zapewnic´ „prawidłowe“ formatowanie pierwotnego tekstu. Podczas codziennej pracy nalezy˙ stosowac´ sie˛ do nastepuj˛ ac˛ ych wskazówek, takze˙ wtedy, jesli´ w chwili obecnej migracja sie˛ nie odbywa:

◦ zamiast bezposrednie´ go formatowania nalezy˙ korzystac´ z szablonów formatów znaków i akapitów.

◦ nalezy˙ usuwac´ niepotrzebne (twarde) Enter wstawiane pomiedzy˛ pozycje listy w celu uzyskania dodatkowego odstepu˛ pomiedzy˛ poszczególnymi Bullets. Tworza˛one podczas konwersji dodatkowe Bullets bez tresci´ (puste wpisy list).

◦ kolumn tabel nie nalezy˙ tworzyc´ za pomoca˛ wielokrotnych tabulatorów. Nalezy˙ zdeﬁnio- wac´ Tab - Stops w taki sposób, zeby˙ tylko jeden tabulator oddzielał tekst pomiedzy˛ dwiema kolumnami. Alternatywnie przy tworzeniu tabel mozna˙ korzystac´ z Tool. W przypadku korzystania z wielokrotnych tabulatorów moze˙ sie˛ zdarzyc,´ ze˙ tabela po konwersji bedzie˛ „out of range“, gdyz˙ domyslne´ tabulatory obydwu aplikacji sa˛ rózne.˙ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 290

◦ nalezy˙ sprawdzic,´ czy format stron w dokumencie jest identyczny z formatem strony usta- wionym dla drukarki. OOo / SO nie wykonuje automatycznego justowania w celu zapewnienia prawidłowego wydruku.

Dokumenty Excel Wielkos´c´ i stopien´ skomplikowania Spreadsheets wymagaja˛ dokładnego sprawdzenia, jesli´ chodzi o ewentualne wykorzystywanie szczególnych technik formatowania i wewnetrznej˛ warstwy logicznej (formuły, Add - Ins), co ma zagwarantowac´ ich prawidłowe przeniesienie. Doty- czy to w szczególnosci´ Add Ins, takich jak 3rd - Party i Standard Excel. Ponizej˙ pokrótce opisalismy´ i objasnili´ smy´ niektóre z danych obszarów:

◦ Nalezy˙ sprawdzic´ ustawienia zródeł´ danych dla Charts. Zasadniczo Excel jest znacznie bardziej elastyczny niz˙ Calc, jesli´ chodzi o obszar danych Charts. OOo / SO wymaga, np. zeby˙ etykiety zawsze przyporzadko˛ wane były do pierwszego wiersza albo kolumny. Jesli´ tak nie jest, wówczas Charts importowane sa˛ z reguły bez etykiet.

◦ Sprawdzic´ czy dokumenty sa˛ chronione hasłem. Calc nie umie otwierac´ Spreadsheets Excel chronionych hasłem. Dlatego przed konwersja˛ nalezy˙ usuna˛c´ hasło.

◦ Nalezy˙ unikac´ stałych Array w formułach. Calc nie obsługuje w formułach stałych Array w taki sam sposób, jak Excel (np. {1,2;3,4}), lecz tylko zakresy komórek okreslaj´ ace˛ Array (np. {A1:B2}).

◦ Nalezy˙ unikac´ znaków specjalnych w nazwach arkuszy. Excel obsługuje wiecej˛ znaków specjalnych w nazwach arkuszy niz˙ Calc.

◦ Nalezy˙ unikac´ arkuszy zawierajac˛ ych ponad 32.000 zapisanych wierszy i Spreadsheets z ponad 256 arkuszami kalkulacyjnymi, poniewaz˙ Calc obecnie nie obsługuje wiekszej˛ ilosci´ wpisów (patrz takze˙ 3.15.4.3).

◦ Nalezy˙ unikac´ rózn˙ ych ustawien´ Widok dla rózn˙ ych arkuszy kalkulacyjnych obsługiwa- nych przez Excel. W Calc takie ustawienia mozna˙ zadawac´ tylko globalnie dla całego dokumentu.

◦ Nalezy˙ sprawdzic´ wielkos´c´ komórek pod katem˛ tekstu wyrównanego do prawej. Jesli´ ko- mórka bedzie˛ zbyt mała, wówczas tekst nie zostanie przedłuzon˙ y w lewo poza komórke.˛ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 291

Dokumenty PowerPoint Proste prezentacje PowerPoint zazwyczaj mozna˙ bez problemu przenosic´ za pomoca˛ programu Impress. Prezentacje, które korzystaja˛ z rozszerzonych funkcji layout i rozszerzonych efektów, prowadza˛ na ogół do róznej˙ prezentacji w skonwertowanym dokumencie. Kroki wyszczególnione ponizej˙ powinny pomóc w zachowaniu pierwotnego formatu:

◦ nalezy˙ unikac,´ usuna˛c´ albo zmienic´ obiekty - cienie, które nie sa˛ obsługiwane przez Im- press. Impress nie obsługuje wszystkich formatów cieni z PowerPoint. Rysunek (rys. 3.34) przedstawia konwersje˛ cieni z PowerPoint do Impress.

◦ nalezy˙ unikac,´ usuna˛c´ albo zmienic´ atrybuty obiektów, takie jak:

– nakładanie sie˛ trzech kolorów – krawedzie˛ z podwójnych i potrójnych linii – zaokraglone˛ krawedzie.˛

Nie sa˛ one obsługiwane przez Impress. Na potrzeby konwersji nalezy˙ uzyskac:´

– podwójne nakładanie sie˛ kolorów – krawedzie˛ złozone˙ z prostych linii.

Zaokraglone˛ krawedzie˛ bed˛ a˛ automatycznie przekształcane w krawedzie˛ prostokatne.˛

◦ brakujace˛ informacje we własciwo´ sciach´ dokumentów. W Impress, w przeciwienstwie´ do PowerPoint, nie jest zapisywana data ostatniego dostepu.˛ Ponadto własciwo´ sci´ dokumentu PowerPoint nie sa˛ wraz z nim importowane do skonwertowanego dokumentu. Obydwa te braki mozna˙ w razie potrzeby obejs´c´ bad˛ z´ wy- równac´ za pomoca˛ makr.

◦ przypadkowy wybór wielokrotnych efektów przejscia.´ Impress nie obsługuje przypadkowego wyboru, podczas gdy stosowane sa˛ wielokrotne efekty przejscia.´ Wazne˙ jest, aby przed konwersja˛ zmienic´ je w proste efekty. W przeciwnym razie w wyniku kompresji zostana˛ one automatycznie przekształcone w efekty pionowych linii. Ponadto nalezy˙ nadmienic,´ ze˙ w Impress niektóre nazwy efektów przejscia´ moga˛ byc´ inne oraz ze˙ program ten w przypadku niektórych efektów moze˙ sie˛ nieco inaczej zachowywac´ niz˙ PowerPoint. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 292

◦ brakujaca˛ obsługa „rysowania opowiadania“. Impress w przeciwienstwie´ do PowerPoint nie obsługuje „rysowania opowiadania“. W Im- press do kazde˙ go slajdu mozna˙ dołacza˛ c´ własny plik dzwi´ eko˛ wy. Aby móc nadal korzystac´ z rysunków stworzonych w PowerPoint, trzeba je ponownie narysowac,´ albo skonwerto- wac´ metoda˛ Splitting72.

Rysunek 3.34: Obiekty - cienie w PowerPoint i Impress

3.15.4.7 Konwertowanie

Sposoby konwersji Dokumenty MS Ofﬁce mozna˙ konwertowac´ do OOo / SO wykorzystujac˛ konwersje˛ pojedyncza˛ albo konwersje˛ Batch:

◦ konwersja pojedyncza Dokument MS nalezy˙ otworzyc´ w OOo / SO i zapisac´ jako dokument OOo / SO.

◦ konwersja Batch Dane dokumenty nalezy˙ skopiowac´ do odpowiedniego katalogu (nalezy˙ go specjalnie w

72Wiecej˛ informacji znajduje sie˛ w „StarOfﬁce 6.0 Software Migration Guide“, strona 47, „Re-record or split narration“. 73Zródło:´ „StarOfﬁce 6.0 Migration Guide"http://uk.sun.com/software/staroffice/pdf/ somigrationguide.pdf ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 293

tym celu utworzyc).´ Nastepnie˛ korzystajac˛ z funkcji „Plik / Autopilot / Konwerter doku- mentów“ mozna˙ zainicjalizowac´ proces Batch. Najpierw nalezy˙ wybrac´ format zródło´ wy (MS albo OOo / SO) (patrz rys. 3.35), a potem zdeﬁniowac´ czy chodzi o dokumenty, czy o szablony i w jakim katalogu sie˛ one znajduja.˛ Nastepnie˛ nalezy˙ ustalic,´ w jakim katalogu docelowym maja˛ byc´ składowane skonwertowane dokumenty (patrz rys. 3.36). Na koncu´ nalezy˙ przekonwertowac´ wszystkie dokumenty MS z katalogu zródło´ wego i umiesci´ c´ je w katalogu docelowym jako dokumenty OOo / SO.

Rysunek 3.35: Konwerter dokumentów: wybór formatu zródło´ wego ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 294

Rysunek 3.36: Konwerter dokumentów: wybór katalogu zródło´ wego i docelowego

Jak widac´ na rysunku (rys. 5.5.3), konwerter dokumentów potraﬁ rozróznia˙ c´ dokumenty i szablony dokumentów. Istotna róznica˙ polega tu na tym, ze˙ szablon MS Ofﬁce mozna˙ zapisac´ takze˙ jako szablon OOo / SO. To, jaki sposób konwersji jest najkorzystniejszy w okreslonej´ chwili, zalezy˙ od stopnia skomplikowania dokumentów lub szablonów (patrz rozdział 3.15.4.5). Ponadto nalezy˙ blizej˙ ocenic´ kazd˙ a˛ sytuacje,˛ gdy chodzi o konwertowanie makr, sterowania OLE / COM albo integracje˛ zewnetrzn˛ ych aplikacji. Trzeba je wówczas ponownie utworzyc.´

Opcje konwersji W OOo / SO do optymalizowania konwersji pojedynczej i konwersji Batch słuz˙a˛jeszcze Usta- wienia kompatybilnosci´ w Opcjach, z których nalezy˙ skorzystac´74.

Kontrola skonwertowanych dokumentów Po zakonczeniu´ konwersji sensownie jest sprawdzic´ skonwertowane dokumenty pod katem˛ przeniesienia do nich nastepuj˛ ac˛ ych ustawien:´

74Patrz „StarOfﬁce 6.0 Software Migration Guide“, strona 49 - 51 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 295

◦ wielkosci´ znaków

◦ krawedzi˛

◦ tabulatorów

◦ wcie˛c´

◦ długosci´ wierszy (tekst w wierszu)

◦ odległosci´ miedzy˛ wierszami wewnatrz˛ akapitów

◦ odległosci´ pomiedzy˛ akapitami

◦ tabel

◦ nagłówków i stopek

◦ list

◦ graﬁk

Pozostałe działania zwiazane˛ z konwersja˛ Oprócz podstawowej konwersji istniejac˛ ych dokumentów i szablonów, moze˙ ewentualnie pojawic´ sie˛ potrzeba przeniesienia do nowego systemu istniejac˛ ych wpisów autotekstu, jak tez˙ tworzonych przez długi czas słowników uzytko˙ wników. Przekazywanie wpisów autotekstu z istniejac˛ ych szablonów do OOo / SO mozna˙ zautomatyzowac´75. Zarówno MS Ofﬁce, jak i OOo / SO obsługuja˛ tworzenie słowników uzytko˙ wnika i zarza-˛ dzanie nimi. W obydwu aplikacjach słowniki posiadaja˛rozszerzenie „.dic“, jednak nie sa˛ze soba˛ kompatybilne. MS Ofﬁce zapisuje swoje słowniki w postaci zwykłych plików tekstowych, natomiast słowniki w OOo / SO składowane sa˛ w formacie własnoscio´ wym. Na razie nie ma jeszcze mozliwo˙ sci´ automatycznej migracji routine.

75Szczegóły opisane zostały w „StarOfﬁce 6.0 Migration Guide“, strony 69 - 71. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 296

3.15.4.8 Integracja zewnetrznych˛ aplikacji

W kontekscie´ migracji do OOo / SO wazn˙ a˛ role˛ w przypadku zewnetrzn˛ ych aplikacji odgrywa stopien´ zintegrowania z MS Ofﬁce Suite. Wiele stosowanych obecnie w urzedach˛ aplikacji specjalistycznych oraz standardowych została zaprojektowana specjalnie pod katem˛ srodo´ wiska MS Windows i w duzym˙ stopniu korzysta z własnoscio´ wych modułów API Windows, takich jak:

◦ MAPI

◦ COM

◦ DDE

◦ . . .

Stopien´ zintegrowania ze srodo´ wiskiem Windows moze˙ byc´ przy tym całkiem rózn˙ y. Prosta˛ i nie sprawiajac˛ a˛ wiekszych˛ problemów integracja˛ jest korzystanie z interfejsu MAPI w celu komunikowania sie˛ z domysln´ ym klientem poczty elektronicznej z poziomu aplikacji. Z daleko wyzszym˙ stopniem integracji mamy do czynienia, gdy zewnetrzna˛ aplikacja zezwala tylko okreslon´ ym aplikacjom MS bad˛ z´ bezwzglednie˛ wymaga ich stosowania, aby mozliwe˙ było pełne wykorzystanie funkcjonalnosci´ niniejszej aplikacji. Tego typu róznice˙ w stopniu zintegrowania zewnetrzn˛ ych aplikacji z Windows oraz z MS Of- ﬁce Suite wymuszaja˛ dokładne sprawdzenie, czy migracja jest mozliwa˙ z technicznego punktu widzenia i jakie nakłady sa˛ z nia˛ zwiazane.˛ O ile dostepn˛ y jest kod zródło´ wy zewnetrznej˛ aplikacji, nalezy˙ w kazdym˙ przypadku sprawdzic,´ czy mozliwa˙ jest integracja z OOo / SO poprzez udostepnian˛ y przez OOo / SO interfejs UNO76 (Universal Network Objects)77.

3.15.4.9 Migracja makr i sterowanie OLE / COM

Makra i OLE / COM sa˛ intensywnie wykorzystywana˛ metoda˛ słuz˙ac˛ a˛ do rozszerzania funkcjonalnosci´ Office oraz do automatyzacji Office w Windows (patrz podrozdział 3.15.3.2). Obszar zastosowania sie˛ga az˙ do automatyzacji całych Workflows wewnatrz˛ organizacji pomiedzy˛ po- szczególnymi oddziałami. Poniewaz˙ makra i skrypty opieraja˛ sie˛ w pierwszym rzedzie˛ na VBA, nie mozna˙ wykonywac´ ich w OOo / SO. Obecnie nie jest oferowane rozwiazanie˛ umozliwiaj˙ ace˛ automatyczna˛ migracje˛ do OOo / SO. Dlatego migracje˛ istniejac˛ ych makr oraz aplikacji OLE /

76Wiecej˛ informacji o UNO znajduje sie˛ na stronie: http://udk.openoffice.org/common/man/uno. html 77W „StarOfﬁce 6.0 Migration Guide“ na stronie 73 integracja z OOo / OS została nakreslona´ w pieciu˛ krokach. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 297

COM, o ile maja˛ byc´ nadal uzywane,˙ trzeba przeprowadzic´ recznie˛ albo utworzyc´ je od nowa. Wówczas, w zalezno˙ sci´ od ilosci,´ stopnia skomplikowania i jakosci´ dokumentacji, w pewnych okolicznosciach´ nakłady moga˛ byc´ bardzo wysokie, co moze˙ doprowadzic´ takze˙ do powstania znacznych kosztów. Z drugiej jednak strony zyskuje sie˛ wówczas mozliwo˙ s´c´ skonsolidowania makr i aplikacji OLE / COM, jak i nowego ukierunkowania strategii informatycnej w zakresie automatyzacji biura. Wskazówka: Aby w przyszłosci´ nie byc´ uzaleznion˙ ym od okreslone´ go pakietu Ofﬁce, mo- duły wymagane do automatyzacji nalezy˙ zaimplementowac´ jako składniki Java albo C++.

3.15.4.10 Sr´ odowisko programowania OOo/SO

OOo / SO posiada, tak samo jak MS Ofﬁce, własne API78, co oznacza, ze˙ moga˛ wykonywac´ takie same zadania. Zarówno Java, jak i C++ umozliwiaj˙ a˛ ponadto rozwijanie składników, które jako Plug - In moga˛ spełniac´ najrózniejsze˙ zadania wewnatrz˛ OOo / SO.

◦ nowe typy Chart

◦ nowe funkcje Calc

◦ Wizards

◦ dodatkowe funkcje dla uzytko˙ wnika

◦ rozszerzenia StarBasic

StarBasic jest zintegrowanym z OOo / SO, modularnym jezykiem˛ programowania i działa we- dług takich samych zasad, jak VBA. Struktura i składnie obydwu jezyków˛ sa˛ w duzej˙ cze˛sci´ bardzo podobne, dlatego wprawny programista VBA nie bedzie˛ miał wiekszych˛ trudnosci´ przy przenoszeniu makr VBA. Oprócz API, OOo / SO udostepnia,˛ tak jak MS Ofﬁce, własne srodo´ wisko programowania (Integrated Development Environment (IDE)), którego interfejs uzytko˙ wnika jest bardzo zblizon˙ y do srodo´ wiska programisty w MS Ofﬁce79.

78Wszystkie istotne informacje na ten temat znalezć´ mozna˙ pod nastepuj˛ ac˛ ym adresem WWW http://api. openoffice.org/ (dokumentacja online). Specyfikacje˛ interfejsu mozna˙ przeczytac´ na stronie http://udk. openoffice.org/. 79Dalsze wskazówki odnosnie´ postepo˛ wania w srodo´ wisku programistycznym i srodo´ wisku programowania zna- lezć´ mozna˙ w „StarOffice 6.0 Migration Guide“, strony 79 - 90. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 298

3.15.4.11 Kompatybilnos´c´ z MS Ofﬁce

Z poprzedniego rozdziału wyraznie´ wynika, ze˙ nie istnieje 100% - owa kompatybilnosć´ z MS Of- fice. Cóz˙ to oznacza, jesli´ chodzi o wymiane˛ dokumentów pomiedzy˛ uzytko˙ wnikami OOo / SO a uzytko˙ wnikami MS Office? Odpowiedzi na to pytanie nalezy˙ udzielic´ na dwóch płaszczyznach.

1. Nalezy˙ uwzgledni˛ c´ cel, w jakim sa˛ wymieniane dokumenty.

2. Nalezy˙ równiez˙ uwzgledni˛ c´ stopien´ skomplikowania dokumentów, które maja˛byc´ wymieniane.

Wymiana dokumentów odbywa sie˛ z powodów czysto informacyjnych W takim przypadku stopien´ skomplikowania wymienianych dokumentów nie odgrywa zadnej˙ roli. Dokumenty, które maja˛ byc´ wymieniane nalezy˙ przekonwertowac´ do formatu PDF. Kazdy˙ uzytko˙ wnik dysponuje przegladark˛ a˛ plików PDF, a jesli´ tak nie jest, wówczas, mozna˙ ja˛ nie- odpłatnie pobrac´ z Internetu. Stosowanie formatu PDF, jako formatu wymiany dokumentów, zalecane jest niemieckim urzedom˛ juz˙ od dłuzsze˙ go czasu.

Wymiana dokumentów odbywa sie˛ w celu ich wspólnej edycji W takim przypadku stopien´ złozono˙ sci´ dokumentu, zgodnie z tym, co wynika juz˙ z wczesniej-´ szej oceny, odgrywa bardzo wazn˙ a˛ role.˛

1. Jesli´ chodzi o proste dokumenty, wówczas wspólna edycja moze˙ odbywac´ sie˛ bez wiek-˛ szych problemów. Funkcje przetwarzania w OOo / SO i MS Ofﬁce potraﬁa˛ze soba˛współ- pracowac.´

2. Jesli´ jednak chodzi o skomplikowane dokumenty, wówczas podczas ich wspólnej edycji nalezy˙ pogodzic´ sie˛ z wyrazn´ ymi ograniczeniami.

◦ W przypadku przetwarzania tekstu oraz arkuszy kalkulacyjnych, wspólna edycja zalecana jest tylko na poziomie tresci.´ Odpowiedzialnos´c´ za formatowanie nalezy˙ jednoznacznie zdeﬁniowac´ po jednej stronie i wykonac´ formatowanie dopiero po zakonczeniu´ pracy nad tresci´ a.˛ Postepo˛ wanie takie obydwie strony musza˛ ze soba˛ uzgodnic.´

◦ Wskutek róznic˙ w Chart - Engines, takze˙ w arkuszach kalkulacyjnych mozna˙ tworzyc´ Charts dopiero po zakonczeniu´ pracy nad danymi. Jesli´ Charts maja˛byc´ utworzone za pomoca˛Calc, wówczas nalezy˙ przestrzegac´ ograniczen´ dotyczac˛ ych tworzenia etykiet (patrz wyzej).˙ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 299

◦ Nie jest mozliwa˙ wspólna edycja tabel Pivot, poniewaz˙ Calc ich nie obsługuje.

◦ Nie mozna˙ zalecic´ wspólnej edycji skomplikowanych prezentacji.

Jesli´ odbywac´ sie˛ ma wspólna edycja dokumentów pochodzac˛ ych z OOo / SO i z MS Ofﬁce, wówczas nalezy˙ stosowac´ sie˛ do nastepuj˛ ac˛ ych zasad:

◦ Nalezy˙ uzywa˙ c´ zgodnego formatu dokumentów. Jesli´ posługujemy sie˛ OOo i SO koniecznie musimy dostosowac´ sie˛ do formatów MS Office, gdyz˙ w MS Office nie sa˛ dostepne˛ filtry OOo / SO. Jesli´ istnieje format obsługiwany przez obydwa pakiety, taki jak np. RTF, wówczas nalezy˙ go uzywa˙ c.´

◦ Nalezy˙ unikac´ tak zwanej konwersji „Round Trip“.

◦ Formatowanie nalezy˙ wykonywac´ dopiero w ostatnim kroku / ostatniej instancji, poniewaz˙ mapowanie pomiedzy˛ OOo / SO a MS Ofﬁce nie jest realizowane w skali jeden do jednego.

◦ Nie nalezy˙ edytowac´ dokumentów w Mixed - Mode, które

– uzywane˙ sa˛ wspólnie przez wiele osób

– ewentualnie sa˛ jeszcze wyposazone˙ w mechanizmy automatyzacji.

◦ Migracja dokumenty konco´ wych powinna odbywac´ sie˛ w formacie PDF.

3.15.5 Migracja kontynuacyjna

Jesli´ chodzi o migracje˛ kontynuacyjna,˛ nalezy˙ przede wszystkim ocenic´ migracje˛ z Office 97 do Office XP (2002), poniewaz˙ z punktu widzenia migracji, obydwie te wersje istotnie sie˛ od siebie rózni˙ a.˛ W przypadku zastapienia˛ Office 2000 przez Office XP zmiany, na które nalezałoby˙ zwrócic´ uwage,˛ nie sa˛ juz˙ tak znaczne, wzglednie˛ zostały juz˙ zaimplementowane i ocenilismy´ je w opisie migracji z Office 97 do Office XP. Wersji MS Office wczesniejszych´ od Office 97 nie ocenialismy´ . W swoich dokumentach Microsoft odnosi sie˛ do migracji do Office XP80 bad˛ z´ w przypadku prezentacji róznic˙ 81 do wczesniejszych´ wersji, w szczególnosci´ takze˙ do punktu wyjscia,´ jakim jest Office 97. 80Microsoft Office XP Deployment Planing Blueprint, marzec 2001 (XPBluePrint) i „Office XP Migration Blu- eprint“, Jerry Honeycutt, luty 2003 (migrionblueprint) 81„Microsoft Office Version Comparison“ (Compare) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 300

Ponadto konieczne jest krótkie spojrzenie na przewidywane nowosci,´ wynikajace˛ z migracji do Ofﬁce 2003.

3.15.5.1 Ofﬁce 97 do Ofﬁce XP

Konwertowanie istniejacych˛ dokumentów W formatach dokumentów nie pojawiły sie˛ istotne róznice.˙ Mozna˙ je w prosty sposób otwierac´ za pomoca˛ odpowiednich aplikacji wchodzac˛ ych w skład Office XP. Jednakze˙ nie istnieja˛ wiarygodne, doswiadczalne´ dane, które potwierdzaja,˛ ze˙ w takim przypadku bezbłednie˛ działaja˛ wszystkie formatowania, szablony, makra i skrypty. W poszczególnych, udowodnionych przypadkach nie była mozliwa˙ bezproblemowa konwersja dokumentów bad˛ z´ szablonów Office 97. Dokładnie tak samo, jak OOo / SO, równiez˙ Office XP obsługuje konwersje˛ Batch, która˛ mozna˙ przeprowadzic´ za pomoca˛ „asystentów konwersji stosowej“. Oprócz standardowych fil- trów konwersji, Microsoft oferuje jeszcze „Office Konverter Pack“82.

Kompatybilnosć´ z wczesniejszymi´ wersjami Formaty danych z Office 97, 2000 i XP sa˛ kompatybilne. Zasadniczo w kazdej˙ wspomnianej wersji mozna˙ otwierac,´ edytowac´ i ponownie zapisywac´ wszystkie dokumenty. Jednak moze˙ sie˛ zdarzyc,´ ze˙ pojedyncze nowe funkcje i formatowania z Office XP, nie bed˛ a˛ wyswietlane´ w Office 97. Według Whitepaper „Microsoft Office XP an File Sharing in a Heterogeneous Office Environment“ nie sa˛ one niszczone podczas edycji w Office 97 i mozna˙ z nich nadal korzystac´ po nastepn˛ ym otwarciu w Office XP.

Migracja makr, skryptów i integracja zewnetrznych˛ aplikacji Główna trudnosć´ podczas migracji do Office XP dotyczy zmian wewnatrz˛ srodo´ wiska programistycznego Office. Trzeba przy tym zwrócic´ szczególna˛ uwage˛ na zmiane˛ w „Object Model“. Wraz ze zmiana˛ VBA w wersji 5 do wersji 6 (Office 2000) oraz do wersji 6.3 (Office XP) na kompatybilnosć´ wzgledem˛ wczesniejszych´ wersji i tym samym na migracje,˛ główny wpływ wywarła zmiana metody przyłaczania˛ obiektów. Zasadniczo nalezy˙ przyja˛c,´ ze˙ aplikacje Office (makra, skrypty, zewnetrzne˛ aplikacje), które powstały w srodo´ wisku programistycznym Office 97, mozna˙ bez problemów stosowac´ takze˙ w srodo´ wisku Office XP, bez koniecznosci´ dostosowania. Mimo zasadniczo istniejacej˛ kompatybilnosci´ zwrotnej, Microsoft nie wyklucza, ze˙ moga˛ pojawic´ sie˛ wyjatki,˛ które sprawia,˛ ze˙ dostosowanie bedzie˛ wymagane83.

82http://www.microsoft.com/office/ork/xp/appndx/appa09.htm 83„Microsoft Office Resource Kit, Technical Article (whitepaper), Microsoft Office 97 to Microsoft Office XP Migration Issues“ (Xpdelta). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 301

Znacznie bardziej problematyczne moze˙ to byc´ w odwrotnej sytuacji, co oznacza, ze˙ nowe aplikacje napisane dla Office XP z trudem moga˛ byc´ stosowane w srodo´ wisku Office 97. Do- tyczy to takze˙ i w szczególnosci´ makr i nalezy˙ o tym pamieta˛ c,´ gdy wewnatrz˛ organizacji nie przeprowadzono pełnej migracji bad˛ z´ migracja wykonywana jest sukcesywnie i jednoczesnie´ wykorzystywane sa˛ obydwie wersje Office. Wskutek niepewnosci,´ czy mozliwe˙ bedzie˛ dalsze uzywanie˙ wszystkich aplikacji Office, wzglednie˛ czy niezbedne˛ bedzie˛ dostosowywanie aplikacji, powstaje koniecznosć,´ podobnie jak w przypadku migracji zastepuj˛ acej,˛ przeprowadzenia dokładnej analizy stanu istniejac˛ ych makr, skryptów i zewnetrzn˛ ych aplikacji.

Róznice˙ w obszarze funkcjonalnosci´ Jesli´ chodzi o zmiany w funkcjonalnosciach,´ na pierwszy plan wysuwa sie˛ wprowadzenie tak zwanych Smarttags84 i rozszerzonych funkcjonalnosci´ umozliwiaj˙ ac˛ ych wspólna˛edycje,˛ wzgled-˛ nie korzystanie z dokumentów. Smarttags sa˛ rozwiniet˛ a˛ mozliwo˙ sci´ a˛ automatyzacji poprzez kontekstowa˛ obsługe˛ uzytko˙ w- ników. Smarttag wywołuje funkcje˛ w oparciu o wpis (np. z góry zdefiniowane słowo albo znana˛ liczbe).˛ Mozna˙ wyrózni˙ c´ proste Smarttags i Smarttags oparte na COM. Zarzadzanie˛ prostymi Smarttags85 odbywa sie˛ w listach XML, które nalezy˙ składowac´ w centralnie zdefiniowanym miejscu w sieci komputerowej a nastepnie˛ udostepni˛ c´ wszystkim uzytko˙ wnikom. Smarttags86 oparte na COM nalezy˙ stosowac´ jako tak zwane Add - Ins. Jednak nie nalezy˙ upatrywac´ w Smart- tags duzych˙ korzysci.´ Smarttags moga˛z pewnosci´ a˛ułatwic´ prace˛ poczatkuj˛ acemu˛ informujac˛ go w odpowiednim miejscu o dostepn˛ ych funkcjonalnosciach´ i pomagajac˛ podczas formatowania. Jednak równie dobrze moga˛ one całkowicie zdezorientowac´ poczatkuj˛ ace˛ go, gdy nie bedzie˛ on umiał uzywa˙ c´ oferowanych funkcjonalnosci.´ Aby tego unikna˛c,´ podczas migracji konieczne jest dłuzsze˙ szkolenie. W przyszłosci´ Smarttags umozliwi˙ a˛ automatyzacje˛ w obszarze aplikacji, która nie bedzie˛ odpowiadac´ zadnemu˙ otwartemu standardowi i bedzie˛ współpracowac´ wyłacznie˛ z MS Office. Wieksze˛ stosowanie prowadzic´ bedzie˛ ostatecznie do jeszcze wyzszych˙ nakładów w przypadku zastepo˛ wania MS Office bad˛ z´ zapobiegnie migracji z powodów ekonomicznych. W przypadku rozszerzonych funkcjonalnosci,´ do wspólnej edycji i stosowania dokumentów Office wykorzystac´ mozna˙ przede wszystkim tak zwane „SharePoint Team Services“. Nie wolno

84Einführung in Smarttags auf den Microsoft Web - Seiten 85http://www.microsoft.com/germany/ms/officexp/developer/smarttags/ einfuehrung.htm 86http://www.microsoft.com/germany/ms/officexp/developer/smarttags/ comsmarttag.htm ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 302

ich mylic´ z SharePoint Portal Server, który opisany został w rozdziale 3.1287. Na stronie WWW: http://www.microsoft.com/sharepoint/server/evaluation/overview/technologies. asp pokazane zostały istotne róznice˙ i zwiazki.˛ W porównaniu z Portal Server, SharePoint Team Services sa˛ w zasadzie jego wersja˛ Light i nie reprezentuja˛ niczego innego, jak bardzo uproszczone Content - Management. Słuz˙a˛ one do udostepniania˛ przez Internet albo Intranet wspól- nych dokumentów grup roboczych wszystkim członkom grupy roboczej przy wykorzystaniu platformy WWW. Dzieki˛ prostej mozliwo˙ sci´ rozbudowy, SharePoint Team Services szczegól- nie dobrze nadaja˛sie˛ dla małych organizacji i do obsługi grup roboczych Adhoc, obsługiwanych takze˙ za pomoca˛ Internetu poza granicami organizacji. Jednak w takim przypadku nalezy˙ takze˙ uwzgledni˛ c´ ryzyko zwiazane˛ z bezpieczenstwem.´ Własnie´ w tym miejscu autorzy niniejszego poradnika widza˛ najlepsze mozliwo˙ sci´ łatwego, opartego na WWW i XML (oddzielenie tresci´ od warstwy prezentacji) tworzenia i publikowa- nia wspólnych dokumentów w grupach roboczych, niezaleznie˙ od własnoscio´ wych formatów dokumentów. Szczególnie w przypadku współpracy wykraczajacej˛ poza granice organizacji nie nalezy˙ zakładac,´ ze˙ wszyscy korzystaja˛ z takich samych srodków´ . Aby byc´ otwartym na kazd˙ a˛ forme˛ współpracy, nalezy˙ stosowac´ ogólnie uznane standardy, takie jak XML. Wydaje sie,˛ ze˙ racje˛ te˛ uznał takze˙ Microsoft, który chce w przyszłosci,´ pocza˛wszy od Ofﬁce 2003, szerzej wykorzystywac´ wspomniany standard.

3.15.5.2 Spojrzenie w kierunku Ofﬁce 2003

Wraz z Office 2003, który wejdzie na rynek jeszcze tego lata (czerwiec 2003), firma Microsoft chciałaby uczynic´ z XML główny format dokumentów wykorzystywanych w pakiecie Office. Dotychczas dostepne˛ informacje znane sa˛ z informacji o testach wersji beta 2 MS Office 200388 oraz z opisów technicznych i artykułów opublikowanych89 przez Microsoft. Najwiecej˛ informacji dotyczy wykorzystania XML w edytorze Word 2003. Z informacji tych powstaje nastepuj˛ ac˛ y obraz:

◦ Microsoft ukierunkował sie˛ w strone˛ standardu XML z W3C (World Wide Web Consor- tium), jednak zmodyﬁkował go dla swoich celów.

87Na stronie WWW http://www.microsoft.com/sharepoint/server/evaluation/ overview/technologies.asp pokazane zostały istotne róznice˙ i zwiazki.˛ 88http://xml.coverpages.org/microsoftXDocs.html 89Microsoft Ofﬁce Word 2003 Beta 2 Preview (Part 1 of 2), Microsoft Ofﬁce Word 2003 Beta 2 Preview (Part 2 of 2), Beitrag aus TechNet Datenbank i inne. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 303

◦ ten zmodyﬁkowany XML bedzie˛ domysln´ ym formatem plików w Ofﬁce 2003. Oprócz tego bedzie˛ mozna˙ równolegle korzystac´ takze˙ ze starych formatów plików.

◦ dla Word istnieje własny, charakterystyczny schemat XML (Word ML).

◦ pliki Word bedzie˛ mozna˙ zapisywac´ jeszcze w tak zwanym „pure XML“. Uzytko˙ wnik bedzie˛ przy tym informowany, ze˙ plik w takim przypadku moze˙ utracic´ formatowania.

◦ aby otworzyc´ w Word obce dokumenty XML, trzeba jednoczesnie´ udostepni˛ c´ wazn˙ y plik - schemat dla obcego dokumentu.

◦ Obcym dokumentom moga˛ byc´ przypisywane własne Stylesheets (plik XLST).

◦ jednak podczas zapisywania w charakterystycznym formacie XML dla Word, tworzony jest pojedynczy plik, w którym zawiera sie˛ wszystko.

◦ w przypadku Excel 2003 bedzie˛ to wyglada˛ c´ podobnie.

◦ Ofﬁce 2003 wyposazon˙ y jest w parser XML, który zgłasza bład,˛ gdy np. wykorzystywana składnia jest nieprawidłowa, albo dokument nie odpowiada podanemu plikowi - schema- towi.

◦ W sumie, w oparciu o niniejsze informacje nie mozna˙ jeszcze ostatecznie wypowiadac´ sie˛ na temat kompatybilnosci´ zachodzacej˛ pomiedzy˛ „Standard - XML“ i „Microsoft - XML“. Powstaje tu przede wszystkim pytanie o to, jakie skutki bed˛ a˛ miały rozszerzenia XML oferowane przez Microsoft na wymiane˛ dokumentów niezalezn˙ a˛ od platformy i czy Microsoft udostepni˛ swoje rozszerzenia w otwartej formie?

3.15.6 Inne aplikacje desktopowe

Oprócz ocenionych wczesniej´ pakietów biurowych, istnieje jeszcze cały szereg innych aplikacji desktopowych, które stały sie˛ niezbedne˛ podczas codziennej pracy. W nastepn˛ ych podrozdzia- łach przedstawimy pokrótce najwazniejsze˙ fakty dotyczace˛ aplikacji desktopowych oferowanych przez desktop windowsowy i adekwatne, alternatywne aplikacje dostepne˛ na desktopie linuksowym. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 304

3.15.6.1 MS Project

W Linuksie nie istnieja˛porównywalne rozwiazania˛ z Microsoft Project. Wprawdzie istnieje kilka projektów (jak np. Mr. Project90 i Gantt Project91), które nad tym pracuja,˛ jednak obecnie ich funkcjonalnosci´ dalece odbiegaja˛ od tych oferowanych przez MS Project.

3.15.6.2 Desktopy

W wiekszo˛ sci´ dystrybucji Linuksa uzytko˙ wnikom udostepniane˛ sa˛ gotowe desktopy wraz z najwazniejszymi˙ aplikacjami zintegrowanymi w podobny sposób, jak w przypadku desktopu windowsowego. Głównymi przedstawicielami sa˛ tu KDE i GNOME. Graﬁczne interfejsy uzytko˙ wnika desktopów realizowane sa˛ poprzez system X - Window oraz rózne˙ menedzery˙ okien

Dygresja: System X-Window a menedzer˙ okien System X-Window92, nazywany takze˙ „X“, jest systemem okien zdolnym do pracy w sieci, który wykorzystywany jest zwłaszcza w połaczeniu˛ z Uniksem. X działa w oparciu o zasade˛ klient - serwer, przy czym serwer udostepnia˛ zasoby, takie jak ekran, klawiatura i mysz, a klient, którym jest, np. jakis´ program uzytko˙ wy, komunikuje sie˛ z serwerem poprzez protokół X. Serwer i klient moga˛przy tym pracowac´ zarówno na oddzielnych maszynach, jak tez˙ na jednej i tej samej maszynie. W przypadku korzystania z Linuksa na komputerach osobistych jest to reguła.˛ Dzieki˛ umiejetno˛ sci´ pracy sieciowej X nadaje sie˛ szczególnie dobrze do zastosowan´ z Thin Clients. „Look and Feel“ graficznego interfejsu uzytko˙ wnika nie jest ustalane przez sam X, lecz przez kazdorazo˙ wo stosowany „Toolkit“ (np. Xt, Athena Widgets, OSF / Motif, Tk, Qt, Gtk+ itd.) i kazdorazo˙ wy menedzer˙ okien (np. IceWM). Menedzerem˙ okien jest klient X, którego zadanie polega na zarzadzaniu˛ układem, wielkosci´ a˛ itd. okien programów, ich „ozdobnikami“, dostepn˛ ymi kolorowymi tablicami i wieloma innymi elementami. Ze wzgledu˛ na dostepno˛ sć´ duzej˙ ilosci´ menedzerów˙ okien istnieje mozliwo˙ sć´ dowolnego kształtowania desktopu93. Desktopy opisane ponizej˙ posiadaja˛swoje własne menedzery˙ okien.

KDE KDE jest przejrzystym i nowoczesnym srodo´ wiskiem desktopowym przeznaczonym dla li- 90http://mrproject.codefactory.se/ 91http://ganttproject.sourceforge.net/ 92Wiecej˛ informacji znajduje sie˛ na stronie http://www.x.org/ 93http://www.plig.org/xwinman/intro.html ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 305

nuksowych i uniksowych stacji roboczych. KDE jest skrótem od nazwy projektu Open Source „K Desktop Environment“. KDE oferuje podobny „Look and Feel“, jaki wystepuje˛ w przypadku desktopów Windows i Mac (patrz rys. 3.37). Mozna˙ go jednak dostosowywac´ według własnych potrzeb i gustu. (patrz rys. 3.38). Zasadniczo zmienic´ mozna˙ niemal wszystko. Mozna˙ ustawiac´ rózne˙ tematy graﬁczne, ramki i zestawy ikon. Cze˛scio´ wo zalezy˙ to od czekajac˛ ych w tle menedzerów˙ okien, które takze˙ mozna˙ dowolnie wybrac.´ Korzystac´ mozna˙ ze wszystkich menedzerów˙ okien X11R6. Dzieki˛ tym ela- stycznym mozliwo˙ sciom´ kształtowania wygladu˛ mozna˙ stworzyc´ dopasowany, jednolity desktop spełniajac˛ y indywidualne potrzeby urzedu˛ lub działu. Istnieje przy tym mozliwo˙ s´c´ ustawienia wybranego stopnia dowolnosci´ dla uzytko˙ wników, jesli´ chodzi o ustawienia osobiste.

Rysunek 3.37: Desktop KDE – przykład 1

94Zródło:´ http://www.kde.org/screenshots/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 306

Rysunek 3.38: Desktop KDE – przykład 2

KDE dostarcza miedzy˛ innymi własny pakiet biurowy Kofﬁce. Innymi aplikacjami desktopowymi w KDE sa:˛

◦ menedzer˙ plików i przegladarka˛ WWW „Konqueror“ (patrz podrozdział 3.15.6.3 albo 3.15.6.4).

◦ klient poczty elektronicznej „KMail“ (patrz podrozdział 3.15.6.5)

◦ zaprojektowane dla BSI rozwiazanie˛ Groupware o nazwie „Kroupware“ (patrz rozdział 3.14.4.2)

◦ MediaPlayer „Noatun“

Wazne˙ sa˛ takze˙ rózne˙ narzedzia˛ administracyjne i zintegrowane srodo´ wisko programowania. Kompletna˛ dokumentacje˛ znalez´c´ mozna˙ na stronie http://docs.kde.org/. Oprócz tego z poziomu KDE mozna˙ oczywiscie´ równiez˙ korzystac´ z „aplikacji nie KDE“.

95Zródło:´ http://www.kde.org/screenshots/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 307

GNOME GNOME96 jest cze˛sci´ a˛ projektu Open Source GNU97. GNOME to skrót od „GNU Network Object Model Environment". Jesli´ chodzi o layout, GNOME jest tak samo elastyczny, jak KDE (patrz rys. 3.39 i rys. 3.40). Równiez˙ GNOME udostepnia˛ własny pakiet biurowy i srodo´ wisko programowania. Niektórymi ze znanych aplikacji sa:˛

◦ menedzery˙ plików „GNOME Commander“ oraz „Nautilus“ (patrz podrozdział 3.15.6.3)

◦ klient poczty elektronicznej „Balsa“

◦ przegladarka˛ WWW „Galeon“ (patrz podrozdział 3.15.6.4)

◦ program do konwersji „GnomeZip“.

Bardziej szczegółowa, pełna lista aplikacji dostepn˛ ych w GNOME udostepniana˛ jest na stronie http://www.gnome.org/softwaremap/.

Rysunek 3.39: Desktop GNOME – przykład 1

96http://www.gnome.org/ 97http://www.gnu.org/ 98Zródło:´ http://vhost.dulug.duke.edu/~louie/screenshots/2.2/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 308

Rysunek 3.40: Desktop GNOME – przykład 2

3.15.6.3 Menedzery˙ plików

◦ Konqueror

◦ Nautilus

◦ GNOME Midnightcommander

3.15.6.4 Przegladarki˛ WWW

W Linuksie uzytko˙ wnikom udostepnian˛ y jest cały szereg przegladarek˛ WWW, z których mozna˙ wybierac´ według gustu i odpowiednio do potrzeb. Do najwazniejszych˙ z nich nalez˙a:˛

◦ Galeon Galeon100 jest przegladark˛ a˛WWW srodo´ wiska GNOME, która opiera sie˛ na Mozilla Ren- dering Machine „Gecko“. Galeon jest lekka˛ przegladark˛ a˛ wyposazon˙ a˛ w najbardziej niezbedne˛ funkcjonalnosci.´ Jest za to szybki i kompatybilny ze wszystkimi standardami. 99Zródło:´ http://vhost.dulug.duke.edu/~louie/screenshots/2.2/ 100http://galeon.sourceforge.net/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 309

◦ Beonex Communicator Beonex Communicator jest przegladark˛ a˛Open Source udostepnian˛ a˛na licencji GPL. Prze- gladarka˛ ta dostepna˛ jest we wszystkich znanych dystrybucjach Linuksa, jak tez˙ dla innych platform. Beonex Communicator uznawana jest za jedna˛ z najbezpieczniejszych przegla-˛ darek.

◦ Konqueror Konqueror101 jest nie tylko menedzerem˙ plików w KDE (patrz wyzej),˙ lecz mozna˙ go takze˙ wykorzystywac´ jako przegladark˛ e˛ WWW. Konqueror, podobnie jak Explorer na desktopie windowsowym jest w pełni zintegrowany z desktopem KDE. Ponadto Konqueror udostepnian˛ y jest na licencji GPL.

◦ Mozilla Mozilla102 jest przegladark˛ a˛Open Source, której kod zródło´ wy dostepn˛ y jest na licencjach MPL „Mozilla Public License“), NPL („Netscape Public License“), LGPL i GPL, wzgled-˛ nie tak zwanej „potrójnej licencji“103 MPL / LGPL/GPL.

◦ Netscape Netscape w wersji 7.x oparty jest na przegladarce˛ Mozilla i posiada dodatkowe funkcje.

◦ Opera Opera104 jest bardzo szybka˛ przegladark˛ a˛ WWW, która dostepne˛ jest dla całego szeregu platform105. Opera jest produktem komercyjnym i trzeba za nia˛ płacic,´ chyba ze˙ uzyt-˙ kownikowi nie przeszkadza cały szereg zintegrowanych banerów reklamowych. W takim przypadku Opere˛ mozna˙ sci´ agn˛ a˛c´ za darmo z Internetu.

Wszystkie z wymienionych przegladarek˛ sa˛ w duzym˙ stopniu zgodne z HTML 4. Maja˛ one za- równo wady, jak i zalety, np. obsługuje˛ Java i XML. Jak juz˙ wspomnielismy´ , Beonex uwazana˙ jest za przegladark˛ e˛ najbezpieczniejsza,˛ podczas gdy Galeon oraz Opera uchodza˛za przegladarki˛ bardzo szybkie. Ponizsza˙ tabela raz jeszcze prezentuje zebrane cechy przegladarek.˛

101http://www.konqueror.org/ 102http://www.mozilla.org/ 103http://www.mozilla.org/MPL/ 104http://www.opera.com/ 105http://www.opera.com/download/index.dml?custom=yes ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 310

Przegladarka˛ Wersja106 Klient poczty Klient Zgodnos´c´ POP3 / IMAP Wiadomosci´ z HTML 4 Galeon 1.2.10 x Beonex 0.8.2 x / x x x Konqueror 3.3.1107 x Mozilla 1.3 x / x x x Netscape 7.0 x / x x x Opera 7.1 x / x x

Tablica 3.69: Przeglad˛ przegladarek˛ WWW nalez˙ac˛ ych do OSS

3.15.6.5 Klient poczty elektronicznej

Dla desktopu linuksowego istnieja˛ równiez˙ liczne klienty poczty elektronicznej (m. in. takze˙ takie, które sa˛ zintegrowane z przegladarkami˛ WWW). Dwa z nich nalezy˙ wyrózni˙ c,´ dlatego opisalismy´ je ponizej.˙ Jest to KMail i Sylpheed:

KMail (a projekt Ägypten) KMail108 jest klientem poczty zintegrowanym z KDE, jednak moze˙ on pracowac´ takze˙ w kaz-˙ dym innym srodo´ wisku. KMail jest przy tym Wolnym Oprogramowaniem. Oferuje on urzedom˛ istotna˛ zalete˛ w porównaniu z innymi klientami poczty elektronicznej pracujac˛ ymi w Linuksie: Dla KMail istnieje wtyczka umozliwiaj˙ aca˛ szyfrowanie i podpisywanie poczty, która jest zgodna ze SPHINX. Wtyczka napisana została na zlecenie BSI w ramach projektu Open Source o nazwie „Ägypten“109 i jest nadal rozwijana. Zgodnos´c´ ze SPHINX gwarantuje, m.in. uzyskanie kompatybilnosci´ pomiedzy˛ rózn˙ ymi rozwiazaniami˛ zgodnymi ze SPHINX oparta˛ na protokole „TeleTrast e.V. MailTrustT w wersji 2“. Dzieki˛ temu uzytko˙ wnik w biurze moze˙ w ramach PKI za pomoca˛ S / MIME projektu „Ägypten“ wymieniac´ zaszyfrowane i podpisane wiadomosci´ z uzytko˙ wnikami pracujac˛ ymi w innych organizacjach, niezaleznie˙ od tego, czy korzystaja˛ oni, np. z Outlooka z zaimplementowana˛ Secure - Plug - In zgodna˛ ze SPHINX albo z LotusNotes z zaimplementowana˛ MailProtect - Plug - In.

106Stan w momencie powstawania poradnika. 107Wersja KDE 108http://kmail.kde.org/ 109http://www.gnupg.org/aegypten/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 311

Oprócz tego KMail jest takze˙ cze˛sci´ a˛ składowa˛ rozwiazania˛ Groupware znanego pod nazwa˛ „Kroupware“ (patrz podrozdział3.14.4.2). KMail obsługuje nastepuj˛ ace˛ protokoły:

◦ POP3

◦ IMAP

◦ SMTP

◦ SMTP AUTH.

Dla POP3, IMAP i SMTP istnieje takze˙ obsługa SSL / TLS.

Sylpheed Klient poczty elektronicznej Sylpheed110 jest równiez˙ projektem Open Source (GPL) i wart jest uwagi, gdyz˙ dostarcza takiego samego „Look and Feel“, jak Outlook, bed˛ ac˛ jednoczesnie´ szybkim klientem poczty oraz czytnikiem wiadomosci.´ Sylpheed obsługuje nastepuj˛ ace˛ proto- koły:

◦ POP3

◦ APOP

◦ IMAP4

◦ SMTP

◦ SMTP AUTH

◦ NNTP.

3.15.6.6 Inne narzedzia˛

Ponizej˙ wymienilismy´ alternatywne narzedzia˛ nalez˙ace˛ do rozwiaza˛ n´ OSS i pogrupowane we- dług pojedynczych kategorii.

◦ edytor graﬁki

– Gimp http://www.gimp.org/

110http://sylpheed.good-day.net/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 312

◦ odtwarzacze wideo

– MPlayer http://www.mplayerhq.hu/ – XTheater http://xtheater.sourceforge.net/

◦ Odtwarzacze audio

– SnackAmp http://snackamp.sourceforge.net/ – MPEG123 http://www.mpg123.de/ – XMMS http://xmms.org/

◦ programy do kompresji

– gzip http://www.gzip.org/ – karchiver http://perso.wanadoo.fr/coquelle/karchiver/ – gnozip http://www.geocities.com/SiliconValley/9757/gnozip.html – gnochive / gnomera http://gnochive.sourceforge.net/index.html

3.15.7 Integracja aplikacji Windows przy uzyciu˙ klienta linuksowego

W niemal wszystkich urzedach˛ istnieje jedna bad˛ z´ wiele aplikacji specjalistycznych lub aplikacji standardowych, które sa˛ bardzo potrzebne do wypełniania specjalistycznych zadan´ i które dostepne˛ sa˛ niestety tylko w postaci aplikacji windowsowych. Jesli´ nie uda sie˛ udostepni˛ c´ tych aplikacji uzytko˙ wnikom takze˙ pod Linuksem, wówczas skutkiem tego moze˙ byc´ załamanie sie˛ migracji do srodo´ wiska linuksowego. Długofalowym celem migracji musi byc´ równiez˙ ostateczne udostepnienie˛ wspomnianych aplikacji, jako aplikacji linuksowych. W przypadku aplikacji standardowych urzedy˛ skazane sa˛ na polityke˛ producenta oprogramowania, co do której nie da sie˛ na ogół przewidziec,´ kiedy dana aplikacja udostepniona˛ zostanie dla jednej bad˛ z´ drugiej platformy linuksowej. Nalezy˙ miec´ nadzieje,˛ ze˙ dzieki˛ coraz szerszemu wykorzystywaniu Linuksa i Open Source Software (OSS) w urzedach,˛ producenci bed˛ a˛ udostepnia˛ c´ swoje aplikacje w akceptowalnym terminie takze˙ dla tej platformy. W przypadku aplikacji specjalistycznych, które zostały napisane dla jednego bad˛ z´ wielu urze-˛ dów jako aplikacje indywidualne, urzedy˛ musiałyby zamówic´ nowy program niezalezn˙ y od platformy albo zlecic´ przeportowanie istniejacej˛ aplikacji do Linuksa. Jednak cos´ takiego nie moze˙ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 313 miec´ miejsca w przypadku migracji, poniewaz˙ tego typu zamierzenie byłoby niewykonalne za- równo z powodów czasowych, jak równiez˙ ﬁnansowych i nie obroniłoby sie˛ ze wzgledów˛ ekonomicznych. Zatem nalezy˙ znalez´c´ rozwiazanie˛ kompromisowe, które umozliwi˙ urzedom˛ dalsze korzystanie ze wspomnianych aplikacji takze˙ pod Linuksem do czasu, az˙ z ekonomicznego i technicznego punktu widzenia uzasadnione stanie sie˛ wprowadzenie nowego oprogramowania albo przeportowanie starego lub az˙ udostepniona˛ zostanie standardowa aplikacja linuksowa. Od dawna istnieja˛rozwiazania,˛ które umozliwiaj˙ a˛aplikacjom windowsowym prace˛ na linuksowych stacjach roboczych. Produkty te mozna˙ podzielic´ na trzy grupy:

◦ Rozwiazania,˛ które pozwalaja˛ na bezposrednie´ wykonywanie aplikacji windowsowych. Programy te nie wymagaja˛ posiadania licencji Windows. Zaliczaja˛ sie˛ do nich WINE oraz Crossover Ofﬁce.

◦ Rozwiazania,˛ które potraﬁa˛ emulowac´ PC, na którym moze˙ pracowac´ Windows. Dzieki˛ nim na tym samym komputerze osobistym mozliwe˙ jest równoległe korzystanie z aplikacji windowsowych i linuksowych. Zalicza sie˛ do nich VMware, Win4LIN.

◦ Produkty serwerowe, w przypadku których aplikacje windowsowe uruchamiane sa˛na windowsowym serwerze aplikacji a wyswietlane´ na kliencie linuksowym i z niego obsługi- wane: (Citrix, Microsoft Terminal Services).

W kazdym˙ pojedynczym przypadku nalezy˙ dokładnie sprawdzic,´ jakie rozwiazanie˛ najlepiej nadaje sie˛ dla danych aplikacji, wymagan´ i srodo´ wisk. Własciwo´ sci´ wymienionych rozwiaza˛ n,´ jak tez˙ koszty ich stosowania wyraznie´ sie˛ rózni˙ a.˛ Ponizej˙ ocenilismy´ kolejne rozwiazania˛ pod katem˛ ich własciwo´ sci´ technicznych i funkcjonalnosci.´ Szczególnie interesujac˛ y jest tu stopien,´ w jakim poszczególne rozwiazania˛ zintegrowane sa˛ z całym systemem.

3.15.7.1 VMware

Workstation 4 VMware działajace˛ m.in. w systemie operacyjnym GNU / Linux umozliwia˙ uruchamianie innych systemów operacyjnych w maszynie wirtualnej. VMware emuluje przy tym wirtualny komputer posiadajac˛ y:

◦ dyski twarde ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 314

◦ naped˛ dyskietek

◦ rózne˙ interfejsy oraz

◦ inna˛ infrastrukture.˛

Oprogramowanie to umozliwia˙ równoczesna˛ prace˛ systemu emulowanego oraz własciwe´ go systemu komputera (system operacyjny hosta).

Obsługiwane systemy operacyjne

Dzieki˛ całkowitej emulacji komputera, VMware uzyskuje bardzo wysoka˛ kompatybilnos´c´ z wieloma systemami operacyjnymi. Obsługiwane sa˛ nastepuj˛ ace˛ systemy - goscie:´

◦ wszystkie znane systemy operacyjne Microsoft (Windows Server 2003, Windows XP, Windows 2000, Windows NT 4.0, Windows ME, Windows 98, Windows 95, Windows 3.1, MS-DOS 6)

◦ znane dystrybucje Linuksa, łacznie˛ z Red Hat, SuSE i Mandrake

◦ FreeBSD

◦ Novell NetWare 6.0 i 5.1

VMware Workstation 4.0 dostepne˛ jest dla wszystkich wykorzystywanych obecnie dystrybucji Linuksa. Program składa sie˛ z rozszerzenia jadra˛ Linuksa oraz programu uzytko˙ wego. Rozsze- rzenie jadra˛ dostarczane jest wraz z kodem zródło´ wym, dzieki˛ czemu teoretycznie mozliwe˙ jest portowanie dowolnych wersji jadra.˛

Programy wykonywalne

W zalezno˙ sci´ od danego systemu operacyjnego mozliwe˙ jest nieograniczone wykonywanie wiekszo˛ sci´ obsługiwanych programów. Niewielkie ograniczenia istnieja˛jedynie w obszarze pro- gramów multimedialnych. Dlatego VMware Workstation nadaje sie˛ takze˙ zwłaszcza do uruchamiania aplikacji specjalistycznych, jak tez˙ aplikacji biurowych i internetowych. Głównym obszarem zastosowan´ jest ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 315

jednak obecnie rozwój oprogramowania, poniewaz˙ developerzy moga˛testowac´ swoje wieloplat- formowe aplikacje równolegle na jednej i tej samej maszynie, w rózn˙ ych systemach operacyjnych.

Ograniczenia

Pełna emulacja komputera nadal jeszcze stawia duze˙ wymagania wzgledem˛ maszyny, na której odbywa sie˛ emulacja. Dlatego praca wielu programów w VMware jest odczuwalnie wol- niejsza niz˙ na porównywalnym, prawdziwym komputerze.

Stopien´ integracji

VMware pracujace˛ na komputerze z Linuksem, gdzie ma miejsce emulacja, wyswietla´ desktop windowsowy we własnym oknie. Z tego okna mozna˙ wywoływac´ poszczególne aplikacje windowsowe. Wymiana danych pomiedzy˛ Windowsem a Linuksem nastepuj˛ e˛ poprzez emulo- wana˛siec.´ W tym celu konieczne jest ustawienie parametrów Samby podczas instalacji VMware. Ma to umozliwi˙ c´ dostep˛ do katalogu domowego komputera z Linuksem. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 316

111

Rysunek 3.41: Desktop windowsowy w Linuksie emulowany przez VMware

W sumie jednak, integracja z linuksowa˛ stacja˛ robocza˛ jest jedynie elementarna. Ponadto udostepnianie˛ aplikacji windowsowych poprzez desktop windowsowy nalezy˙ oceniac´ jako niezbyt ergonomiczne.

Koszty

VMware jest produktem komercyjnym, za uzywanie˙ którego pobierana jest opłata112. Aby móc uzywa˙ c´ aplikacji windowsowych, trzeba dodatkowo wykupic´ takze˙ licencje Windows. Do tego dochodza˛ jeszcze zwiekszone˛ koszty osprzetu˛ spowodowane wyzszymi˙ wymaganiami sta- wianymi przez VMware. Biorac˛ powyzsze˙ pod uwage˛ nalezy˙ stwierdzic,´ ze˙ udostepnianie˛ aplikacji windowsowych z wykorzystaniem VMware jest dos´c´ drogie.

111Zródło:´ VMware http://www.vmware.com/products/desktop/ws_screens.html 112Blizsze˙ informacje znalez´c´ mozna˙ na stronie http://www.vmware.com/vmwarestore/pricing. html ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 317

Ocena

Prawdziwa siła VMware tkwi raczej w tym, o czym juz˙ wspomnielismy´ , czyli w udostep-˛ nianiu dobrej platformy programistycznej dla aplikacji wieloplatformowych, niz˙ w mozliwo˙ sci´ udostepniania˛ aplikacji windowsowych w Linuksie. Dlatego VMware nalezy˙ wykorzystywac´ w tym celu tylko w wyjatko˛ wych przypadkach.

GSX Server 2.5 VMware GSX Server opiera sie˛ na tej samej technologii, jak VMware Workstation. Za pomoca˛ GSX Server mozna˙ uruchamiac´ wirtualne maszyny jako procesy w tle. Serwerem tym mozna˙ sterowac´ zdalnie spod Windows albo Linuksa, jak równiez˙ mozliwe˙ jest zdalne administrowanie poprzez interfejs WWW oraz specjalny, skryptowy API. Dzieki˛ temu mozna˙ takze˙ jednoczesnie´ uruchamiac,´ na osprzecie˛ ﬁrmy Intel, wiele systemów operacyjnych i konsolidowac´ w ten sposób srodo´ wiska serwera. Jesli´ chodzi o „obsługiwane systemy operacyjne“, „programy wykonywalne“, „ograniczenia“, „stopien´ integracji“, „koszty“ i „ocene“˛ obowiazuj˛ e˛ takie same uwagi, jak w przypadku opisanego wczesniej´ wariantu Workstation113.

3.15.7.2 Win4Lin

Win4Lin 4.0 - Workstation Edition Win4Lin114 umozliwia˙ uruchamianie w Linuksie opartych na DOS wersji Windows 95, 98 oraz ME. Win4Lin nie emuluje przy tym komputera osobistego, tak jak robi to VMware, lecz udostepnia˛ usługi systemowe wymagane przez Windows poprzez szereg modułów jadra.˛ Pliki systemu operacyjnego Windows zmieniane sa˛ podczas instalacji w taki sposób, ze˙ nie musi on juz˙ sam wykonywac´ w/w usług, lecz odwołuje sie˛ do odpowiednich usług swiadczon´ ych przez moduły jadra.˛ Dlatego w Win4Lin aplikacje działaja˛ z reguły znacznie szybciej niz˙ w VMware. W Win4Lin, tak samo jak w VMware, desktop windowsowy udostepnian˛ y jest we własnym oknie. Po starcie programu, otwiera on okno, w którym bootuje sie˛ Windows. Nastepnie˛ uzyt-˙ kownik moze˙ w otwartym oknie uruchamiac´ aplikacje windowsowe i z nimi pracowac´ (patrz rys. 3.42).

113Ceny licencji serwera znajduja˛ sie˛ na stronie http://www.vmware.com/vmwarestore/pricing. html 114Producent Netraverse http://www.trelos.com/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 318

Win4Lin nie stawia takze˙ zadn˙ ych szczególnych wymagan´ sprzeto˛ wych. Oprogramowanie to moze˙ pracowac´ na kazdym˙ współczesnym komputerze osobistym115.

Obsługiwane systemy operacyjne

Win4Lin moze˙ współpracowac´ z kazd˙ a˛ wykorzystywana˛ obecnie dystrybucja Linuksa, o ile uzywa˙ ona jadra˛ z rodziny 2.4.x. Jak juz˙ wspomnielismy´ , za pomoca˛ Win4Lin mozliwe˙ jest uruchamianie nastepuj˛ ac˛ ych wersji Windows116.

◦ 95

◦ 98

◦ ME

Programy wykonywalne

Za pomoca˛ Win4Lin 4.0 mozna˙ z reguły udostepnia˛ c´ na linuksowej stacji roboczej aplikacje biurowe, internetowe a nawet aplikacje bazodanowe.

Ograniczenia

Ponizej˙ wypunktowalismy´ istniejace˛ ograniczenia:

◦ obsługiwane wersje Windows Nalezy˙ tu oczekiwac,´ ze˙ wiele nowych aplikacji wkrótce nie bedzie˛ mogło w nich pracowac.´

◦ łaty modułów windowsowych Nakładanie łat ﬁrmy Microsoft nalezy˙ wykonywac´ ostroznie,˙ gdyz˙ nie mozna˙ wykluczyc,´ ze˙ podczas tego procesu wymienione zostana˛ pliki zmienione przez Win4Lin i system straci swoja˛ stabilnos´c.´

115Wymagania sprzeto˛ we zalecane przez producenta http://www.netraverse.com/products/ win4lin40/requirements.php 116Szczegółowe dane znalez´c´ mozna˙ na stronie http://www.netraverse.com/support/docs/400_ relnotes.html ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 319

◦ udostepniana˛ pamie˛c´ Aplikacjom windowsowym pracujac˛ ym w Win4Lin, od wersji 4.0, mozna˙ udostepni˛ c´ maksymalnie 128 MB pamieci˛ operacyjnej. Pamie˛c´ wirtualna ograniczana jest jedynie przez dostepn˛ a˛ pojemnos´c´ partycji dysku, na której znajduje sie˛ katalog „$HOME/win“ uzytko˙ wników.

◦ obsługa interfejsów Nie sa˛ obsługiwane interfejsy DirectX i USB.

Stopien´ integracji

W Win4Lin, tak samo jak w VMware, desktop windowsowy udostepnian˛ y jest we własnym oknie, w którym mozna˙ wywoływac´ aplikacje windowsowe.

117

Rysunek 3.42: Desktop windowsowy w Linuksie emulowany przez Win4Lin

117Zródło:´ Netraverse http://www.netraverse.com/products/win4lin40/ fullsizescreenshot.jpg ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 320

Wymiana danych pomiedzy˛ aplikacjami linuksowymi i windowsowymi jest jednak łatwiejsza niz˙ w przypadku VMware. Dzieki˛ technice oferowanej przez Win4Lin, katalogi linuksowe moga˛ byc´ prezentowane w postaci napedów˛ . Równiez˙ w tym przypadku nie mozna˙ jednak mówic´ o rzeczywistej integracji poszczegól- nych aplikacji. Po uruchomieniu programu wyswietlane´ jest okno, w którym uzytko˙ wnik widzi bootujac˛ y sie˛ Windows, jeszcze przed umozliwieniem˙ mu uruchamiania aplikacji i pracy z nimi.

Koszty

Win4Lin równiez˙ jest produktem komercyjnym, za który nalezy˙ zapłacic.´ Koszty licencji118 sa˛tu jednak znacznie nizsze˙ niz˙ w przypadku VMware. Do tego dochodza˛jeszcze, tak samo, jak w przypadku VMware, koszty licencji Microsoft. W przypadku obydwu systemów operacyjnych sa˛ to jednak przewidywalne sumy. Dzieki˛ temu praca aplikacji windowsowych w linuksowym emulatorze Win4Lin jest znacznie korzystniejsza niz˙ w emulatorze VMware.

Ocena

Mimo kilku technicznych ograniczen,´ Win4Lin jest obecnie w wielu przypadkach droga,˛ która˛ mozna˙ by poda˛za˙ c,´ a prowadzac˛ a˛ do korzystania z aplikacji windowsowych w Linuksie. Jest tak zwłaszcza w przypadku, gdy dana aplikacja ma byc´ uzywana˙ tylko na niewielu stacjach roboczych. W przypadku, gdy korzystanie z aplikacji przewidziane jest na wielu stacjach roboczych, mozna˙ ewentualnie skorzystac´ z Win4Lin Terminal Server, który pokrótce opisalismy´ w nastepn˛ ym paragraﬁe.

Win4Lin Terminal Server 2.0 W Win4Lin Terminal Server ﬁrma Netraverse wykorzystała własciwo´ sci´ sieciowe protokołu X w celu umozliwienia˙ korzystania z Win4Lin z poziomu innego systemu. Jest to mozliwe,˙ poniewaz˙ wyswietlanie´ okien Win4Lin odbywa sie˛ na desktopie linuksowym własnie´ za pomoca˛ niniejszego protokołu. Win4Lin Terminal Server uruchamia wówczas na serwerze linuksowym oddzielne sesje programu dla kazde˙ go uzytko˙ wnika, który uzywa˙ Win4Lin. Sa˛ one przy tym przenoszone do klien- tów poprzez protokół X.

118Koszty licencji Win4Lin 4.0 Workstation Edition; http://www.digitalriver.com/dr/v2/ec_ Main.Entry?SP=10007&SID=40113&CID=0&CUR=840&DS ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 321

WINE WINE jest wolnym, stale ulepszanym projektem119, który od 1993 roku konsekwentnie zmie- rza do integracji Windowsa z Linuksem na poziomie aplikacji. WINE działa, jesli´ chodzi o udostepnianie˛ aplikacji windowsowych w Linuksie, na innej zasadzie, jak jest to w przypadku rozwiaza˛ n´ opisanych powyzej.˙ WINE jest wolna˛ implementacja˛ windowsowego API pracujac˛ a˛ w Linuksie i X - Windows. Podczas uruchamiania aplikacji windowsowej WINE ładuje ja,˛ tak samo jak robi to Windows, do pamieci˛ operacyjnej komputera, łaczy˛ ja˛z udostepnian˛ ymi wraz z WINE bibliotekami i w ten sposób potraﬁ uruchamiac´ aplikacje w Linuksie. Mimo, ze˙ WINE nie jest emulatorem, postanowilismy´ dokładnie go ocenic.´ Najwiekszym˛ wyzwaniem jest jak najpełniejsze udostepnienie˛ bibliotek windowsowych w postaci wolnych implementacji, co ma na celu umozliwienie˙ pracy w Linuksie jak najwiekszej˛ ilosci´ aplikacji windowsowych. W WINE zaimplementowane zostały juz˙ biblioteki windowsowe z najwazniejszymi˙ funkcjami, dzieki˛ czemu nie ma problemu, gdy uruchamiana aplikacja odwo- łuje sie˛ tylko ze standardowej funkcjonalnosci´ (systemu operacyjnego Windows) i sama wnosi pozostałe funkcje. Sytuacja jest trudniejsza, gdy aplikacja windowsowa korzysta przewaznie˙ z nowych, jeszcze nie zaimplementowanych funkcji bibliotek Windows albo z bibliotek innych aplikacji. W zwiazku˛ z tym nalezy˙ wspomniec´ takze˙ o tym, ze˙ producenci oprogramowania z reguły staraja˛ sie,˛ aby obsługiwało ona równiez˙ starsze wersje Windows i dlatego rzadko wpro- wadzaja˛ nowe Features albo sa˛ one stosowane opcjonalnie, dlatego w praktyce nie musza˛ one koniecznie powodowac´ problemów. W tak zwanym miedzyczasie˛ WINE zaczał˛ obsługiwac´ wiele aplikacji (patrz ponizszy˙ paragraf „Programy wykonywalne“) oraz Features120.

Obsługiwane systemy operacyjne

WINE dostepn˛ y jest praktycznie dla kazde˙ go systemu linuksowego i wchodzi w skład wiek-˛ szosci´ dystrybucji.

Programy wykonywalne

Za pomoca˛ WINE mozna˙ zasadniczo uruchamiac´ wszystkie aplikacje windowsowe, o ile

119Strona domowa projektu WINE http://www.winehq.com/ 120Liste˛ znalez´c´ mozna˙ na stronie http://www.winehq.com/?page=wine_features;winehq= d35c3404fe39283bf96bb1dd54b14c8d ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 322

dostepne˛ sa˛ wymagane biblioteki. Do programów, o których wiadomo, ze˙ moga˛ w taki sposób pracowac´ nalez˙a˛ m.in Win- word. Excel i PowerPoint z pakietów biurowych Ofﬁce 97 i Ofﬁce 2000, jak tez˙ Internet Explo- rer. W poszczególnych przypadkach trzeba wczesniej´ wykonac´ praktyczny test funkcjonalnosci,´ przy czym wczesniej´ nalezy˙ zapoznac´ sie˛ z baza˛ danych aplikacji dostepn˛ a˛ na stronie http: //appdb.winehq.com/.

Ograniczenia

Problem w WINE stanowi, wymagajaca˛ wcia˛z˙ dos´c´ duzej˙ pracy, konﬁguracja programu, która zakłada posiadanie wielu wiadomosci.´

Stopien´ integracji

WINE sprawia, ze˙ aplikacje windowsowe sa˛ optymalnie zintegrowane z desktopem linuksowym. Programy nie sa˛ tu uruchamiane z poziomu ich własnego desktopu, lecz bezposrednio´ za pomoca˛ menedzera˙ okien desktopu linuksowego we własnym oknie X - Window. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 323

121

Rysunek 3.43: Aplikacje windowsowe na desktopie linuksowym emulowane przez WINE

Koszty

W tym przypadku płacic´ trzeba tylko za koszty licencji na uzywanie˙ poszczególnych aplikacji windowsowych. Jednakze˙ w odróznieniu˙ od wczesniej´ omawianych rozwiaza˛ n´ nalezy˙ liczyc´ sie˛ z wieksz˛ a˛ ilosci´ a˛ pracy administracyjnej.

Ocena

Rozwiazanie˛ to ma dwie istotne zalety:

◦ nie trzeba płacic´ za licencje systemu operacyjnego Windows.

◦ nie trzeba uruchamiac´ dodatkowego systemu operacyjnego, który dodatkowo obcia˛załby˙ dostepne˛ zasoby. Teoretycznie aplikacje windowsowe mozna˙ uruchamiac´ tak samo szybko, jak w Windows i wymagaja˛ one tej samej ilosci´ pamieci.˛

121Zródło:´ http://www.winehq.com/?ss=1 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 324

Zatem, o ile WINE udostepnia˛ biblioteki niezbedne˛ dla działania danej aplikacji, nalezy˙ z niego skorzystac´ w pierwszej kolejnosci.´ WINE, jako jedyny, mógłby stworzyc´ mozliwo˙ s´c´ uruchamiania MS Project na desktopach linuksowym, gdyz˙ obecnie nie ma alternatywnej aplikacji dla Linuksa. W bazie danych aplikacji nie mozna˙ jednak znalez´c´ zadne˙ go potwierdzajace˛ go to wpisu.

Crossover Office Crossover Office (CO) jest produktem firmy Code Weavers122. CO opiera sie˛ na WINE i kom- pensuje wade˛ pracochłonnej konfiguracji WINE przez to, ze˙ WINE w CO uzupełniony został o wygodny program instalacyjny i skrypty słuz˙ace˛ do konfiguracji ustawien´ uzytko˙ wników oraz instalacji aplikacji windowsowych.

Programy wykonywalne

Crossover Office obsługuje obecnie Microsoft Word, Excel oraz PowerPoint (z Office 97 i 2000). Inne aplikacje, takie jak Outlook 2000, IE 5.5 oraz Notes R5 pracuja˛ dosć´ stabilnie.

Koszty

Oprócz kosztów zwiazan˛ y z licencjami MS Ofﬁce dochodza˛ jeszcze koszty licencji Crosso- ver Ofﬁce123.

Ocena

Poza tym obowiazuj˛ a˛ takie same opinie, jak w przypadku WINE. Tak wiec,˛ ten kto preferuje wieksz˛ a˛ wygode˛ podczas instalacji i konﬁguracji, powinien skorzystac´ z CO, a nie z WINE.

Crossover Office Server Edition Crossover Office Server Edition umozliwia˙ centralne instalowanie aplikacji windowsowych w serwerze aplikacji opartym na Linuksie i udostepnianie˛ ich stamtad˛ systemom klienckim poprzez protokół X. To z kolei ma te˛ zalete,˛ ze˙ aplikacje windowsowe mozna˙ udostepnia˛ c´ centralnie i centralnie nimi administrowac.´ 122Strona domowa Code Weavers http://www.codeweavers.com/home/. 123Informacja o cenach Crossover Office http://secure.codeweavers.com/store/. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 325

WineX WineX jest odmiana˛ WINE, w przypadku której ﬁrma Transgaming124 skoncentrowała sie˛ na poprawieniu obsługi DirectX. Za pomoca˛WineX mozna˙ uruchamiac´ w Linuksie szereg zbytecz- nych gier windowsowych. Z tego powodu nie bedziemy˛ blizej˙ oceniac´ WineX i wymienilismy´ go tylko ze wzgledu˛ na che˛c´ pełnego przedstawienia tematu. WineX nie jest Wolnym Oprogramowaniem.

3.15.7.3 Citrix Metaframe

Funkcjonalnosci´ opisalismy´ w rozdziale 3.16.5.

Obsługiwane systemy operacyjne

(patrz rozdział 3.16.5)

Programy wykonywalne

Uruchamiac´ mozna˙ wszystkie aplikacje windowsowe, które pracuja˛ w Windows NT albo Windows 2000.

Ograniczenia

Ograniczenia dotyczace˛ wykonywania aplikacji windowsowych istnieja˛ tylko aplikacje obcia˛zone˙ graﬁka˛ (patrz wyzej),˙ których w miare˛ mozliwo˙ sci´ nie nalezy˙ uruchamiac´ za pomoca˛ Citrix Metaframe.

Stopien´ integracji

Tak samo, jak w VMware i Win4Lin, desktop windowsowy otwiera sie˛ we własnym oknie na desktopie linuksowym, w którym uruchamiane bed˛ a˛aplikacje windowsowe. Wymiana danych odbywac´ sie˛ moze˙ tylko poprzez siec.´ Tym samym równiez˙ tutaj mamy do czynienia z małym stopniem integracji.

124Strona domowa ﬁrmy Transgaming http://www.transgaming.com/. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 326

Koszty

Koszty zalez˙a˛ od kazdorazo˙ wego sposobu wykorzystania z˙adane˛ go Metaframe i nalezy˙ je oceniac´ osobno w kazdym˙ przypadku. Zasadniczo składaja˛ sie˛ na nie koszty licencji Citrix oraz łaczne˛ koszty licencji Microsoft.

Ocena

Citrix Metaframe nie jest zalecane jako rozwiazanie˛ udostepniaj˛ ace˛ aplikacje windowsowe na desktopie do czasu gdy bed˛ a˛ one dostepne˛ takze˙ jako aplikacje linuksowe, poniewaz˙ jest przede wszystkim za drogi i zbyt skomplikowany. Citrix Metaframe nalezy˙ jednak wzia˛c´ pod uwage,˛ gdy przewiduje sie˛ istnienie takich aplikacji windowsowych, z których trzeba bedzie˛ korzystac´ długoterminowo. Najwieksz˛ a˛ zaleta˛ Citrix Metaframe jest centralna instalacja i zarzadzanie˛ aplikacjami, jak tez˙ centralne przechowywanie danych. Citrix Metaframe sprawdza sie˛ dobrze równiez˙ w srodo-´ wisku Thin Clients oraz klientów bezdyskowych.

3.15.7.4 Windows Terminal Server

Funkcjonalnosci´ opisalismy´ w rozdziale 3.16.5.

Obsługiwane systemy operacyjne

(patrz rozdział 3.16.5)

Programy wykonywalne

Sa˛ to wszystkie aplikacje windowsowe, które mozna˙ uruchamiac´ w Windows 2000.

Ograniczenia

(patrz rozdział 3.16.5)

Stopien´ integracji ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 327

Taki sam, jak w przypadku Citrix Metaframe.

Koszty

W przeciwienstwie´ do Citrix dochodza˛ tu jeszcze koszty licencji Microsoft.

Ocena

Wariant ten nalezy˙ ocenic´ podobnie jak rozwiazanie˛ Citrix Metaframe, przy czym jest on nieco korzystniejszy. Jednak wada˛ w porównaniu z Citrix Metaframe jest to, ze˙ w przypadku Windows Terminal Servers nie zebrano jeszcze tak szerokich doswiadcze´ n,´ jak z Citrix Meta- frame, zwłaszcza w duzych˙ i skomplikowanych srodo´ wiskach. Jednakze˙ podczas poszukiwan´ rozwiazania˛ samego problemu ma to niewielkie znaczenie.

Podsumowanie VMware, Win4Lin, WINE oraz Crossover Ofﬁce moga˛ byc´ traktowane tylko jak rozwiaza-˛ nia przejscio´ we albo rozwiazanie˛ dla pojedynczych, małych aplikacji pracujac˛ ych na poszcze- gólnych stacjach roboczych. W nieodległym czasie musi powstac´ odpowiednia, niezalezna˙ od platformy aplikacja uruchamiana pod Linuksem. W przeciwnym razie mozna˙ sprawdzic´ czy Citrix Metaframe moze˙ byc´ rozwiazaniem˛ prze- mysłowym, przy czym bedzie˛ to z pewnosci´ a˛ raczej strategiczna decyzja. Zwazywszy˙ na powyzsze˙ warunki mozliwe˙ jest sformułowanie nastepuj˛ ac˛ ych ocen:

◦ W przypadku przewidywalnej ilosci´ aplikacji windowsowych opłaca sie˛ zastosowac´ WINE (w razie potrzeby trzeba ewentualnie dodatkowo, twórczo popracowac).´

◦ Jesli´ istnieje wiele danych aplikacji windowsowych, wówczas istnieje duze˙ prawdopodobienstwo,´ ze˙ nie wszystkie aplikacje bedzie˛ mozna˙ uruchomic´ za pomoca˛ WINE. Dlatego nalezy˙ sprawdzic,´ czy mozliwe˙ jest wykorzystanie Win4Lin (czy aplikacje działaja˛ z Win- dows 95, 98 albo ME).

◦ Jesli´ ilos´c´ danych aplikacji windowsowych jest bardzo duza,˙ wówczas pojawia sie˛ podstawowe pytanie o sens migracji (granice˛ nalezy˙ sprawdzic´ w konkretnym przypadku).

◦ W przyszłosci´ trzeba wesprzec´ powstanie aplikacji niezalezn˙ ych od platformy. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 328

3.15.8 Ocena

W oparciu o wczesniejsze´ spostrzezenia,˙ ocenilismy´ ponizej˙ zastapienie˛ Office 97 bad˛ z´ Office 2000 przez Office XP lub Office 2003 albo przez OOo / SO. Wyniki niniejszych ocen tworza˛ podstawe˛ dla oceny mozliwo˙ sci´ zastapienia˛ desktopu firmy Microsoft desktopem linuksowym.

3.15.8.1 Zastapienie˛ Ofﬁce 97/2000

Migracja do Office XP Nad zasadnosci´ a˛ migracji z Office 97 bad˛ z´ 2000 do Office XP nalezy˙ sie˛ zastanowic´ z naste-˛ pujace˛ go powodu. Migracja wymaga zawsze czasu i nakładów, dlatego odbywa sie˛ ona w kierunku najnowszej oraz najnowoczesniejszej´ techniki, a nie w kierunku wcia˛z˙ dostepnej,˛ starszej techniki. W przypadku Office XP mozna˙ przewidywac,´ ze˙ zostanie on zastapion˛ y jeszcze w roku 2003 przez Of- fice 2003, który wniesie nowsza˛i bardziej innowacyjna˛technike.˛ Jesli´ zgodnie z zapowiedziami, Office 2003 zostanie udostepnion˛ y w pełnej wersji latem 2003, wówczas mozna˙ załozy˙ c,´ ze˙ do poczatku˛ 2004 r. dostepna˛ bedzie˛ wersja wzglednie˛ stabilna i nie zawierajaca˛ błedów˛ .

Migracja do Office 2003 Przeciwko migracji do Office 2003 przemawia, z technicznego punktu widzenia tylko to, ze˙ obecnie nie ma jeszcze doswiadcze´ n´ z zastosowan´ produkcyjnych pakietu Office 2003. Na podstawie silnego da˛zenia˙ w Office 2003 do XML oraz dotychczasowych doswiadcze´ n´ z wersja˛ Beta 2 mozna˙ oczekiwac,´ ze˙ wraz z wprowadzeniem Office 2003 łatwiejsza stanie sie˛ wymiana dokumentów niezalezna˙ od platformy. Samo to jest wystarczajac˛ ym powodem, aby poczekac´ z migracja˛do momentu, gdy Office 2003 ukaze˙ sie˛ jako wzglednie˛ stabilna i bezbłedna˛ wersja oraz az˙ dostepne˛ bed˛ a˛ wyniki z codziennego wykorzystywania tego pakietu biurowego, takze˙ jesli´ chodzi o ponadplatformowa˛ wymiane˛ dokumentów.

Migracja do OOo / SO Migracje˛ do OOo / SO mozna,˙ z dzisiejszego punktu widzenia, zalecic´ tylko wówczas, gdy dokumenty powstajace˛ w urzedzie˛ lub organizacji

◦ nigdy lub rzadko sa˛ wspólnie edytowane z innymi urzedami˛ i organizacjami korzystaja-˛ cymi z MS Ofﬁce (do wersji XP) albo ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 329

◦ sa˛proste, tzn. sa˛to dokumenty bez makr oraz bez szczególnych formatowan´ i jako takie sa˛ wspólnie edytowane przez inne urzedy˛ i organizacje korzystajace˛ z MS Ofﬁce (do wersji XP).

Jesli´ wraz z innymi urzedami˛ i organizacjami czesto˛ tworzone sa˛ skomplikowane dokumenty i w organizacjach tych stosowany jest Office 97, 2000 albo XP, wówczas nalezy˙ spodziewac´ sie,˛ ze˙ współpraca bedzie˛ zbyt skomplikowana i pracochłonna. Migracja do OOo / SO nie jest zalecana z technicznego punktu widzenia równiez˙ wówczas, gdy nie ma mozliwo˙ sci´ zintegrowania z OOo / SO bezwzglednie˛ koniecznych, zewnetrzn˛ ych aplikacji, które sa˛ silnie zintegrowane z MS Office. Poniewaz˙ obecnie nadal nie ma dostatecznych informacji na temat wymiany dokumentów pomiedzy˛ MS Office 2003 a OOo / SO, w przyszłosci´ w wersjach 1.1 i 6.1, wiec˛ na razie nie mozemy˙ sie˛ na ten temat wypowiedziec.´

3.16 Terminal-Server i Thin Clients

3.16.1 Przeglad˛

W projekcie migracyjnym moze˙ znalez´c´ sie˛ decyzja o zastosowaniu Terminal - Servers i Thin Clients. Dlatego ich opis stał sie˛ cze˛sci´ a˛ składowa˛ niniejszego poradnika. Jednak nie jest to klasyczny temat migracyjny, poniewaz˙ z reguły nie wykonuje sie˛ migracji srodo´ wisk Terminal Se- rver. Zastosowanie techniki opisanej ponizej˙ jest w pierwszym rzedzie˛ decyzja˛wewnatrz˛ ogólnej strategii informatycznej kazde˙ go urzedu.˛ Przedstawione rozwiazania˛ powinny jednak umozliwi˙ c´ wglad˛ w całe zagadnienie i wyjasni´ c´ potencjał opisywanej technologii. Prezentujemy technologie, z których mozna˙ korzystac´ w najrózniejszych˙ urzedach:˛

◦ serwery oparte na Linuksie i systemy klienckie z projektem Linux - Terminal - Server.

◦ usługi terminalowe NX z systemami serwerowymi opartymi na Linuksie oraz systemami klienckimi dla Windows i Linuksa.

◦ Windows-Terminal-Server w pierwszym rzedzie˛ z windowsowymi systemami klienckimi

◦ Metaframe ﬁrmy Citrix z rózn˙ ymi systemami klienckimi (DOS, Windows, Unix, Linux, itd.). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 330

Przedstawione systemy oferuja˛ cała˛ game˛ rózn˙ ych technicznych rozwiaza˛ n´ (systemy serwerowe i klienckie) i nalezy˙ je dokładnie ocenic´ w kazdym˙ pojedynczym przypadku. Oprócz róznic˙ i mozliwo˙ sci´ technicznych, systemy te rózni˙ a˛ sie˛ znacznie, takze˙ jesli´ chodzi o modele licencji i koszty.

3.16.2 Wprowadzenie

Administrowanie i opieka nad komputerami pełniac˛ ymi funkcje stacji roboczych jest zadaniem wymagajac˛ ym duzych˙ nakładów osobowych, zwłaszcza wtedy, gdy komputery wyposazone˙ zo- stały w rózn˙ y osprzet˛ i oprogramowanie. Równiez˙ rosnac˛ y stopien´ skomplikowania stosowanego osprzetu˛ i oprogramowania moze˙ powodowac´ wieksz˛ a˛awaryjnos´c´ stacji roboczych i tym samym wymagac´ pracy administracyjnej. Prace zwiazane˛ z opieka˛ nad systemem zostały wyszczegól- nione ponizej:˙

◦ instalacja – ewentualna konﬁguracja na miejscu

◦ dostosowanie do indywidualnych potrzeb

◦ zarzadzanie˛ aktualizacjami oprogramowania – tworzenie oraz opieka nad instalowanymi pakietami i ich przydzielanie.

◦ diagnozowanie oraz usuwanie błedów˛ , wsparcie techniczne

◦ dostarczanie cze˛sci´ zamiennych

W sumie zadania mozna˙ zautomatyzowac´ za pomoca˛ odpowiednich narzedzi˛ administracyjnych bad˛ z´ aplikacji przeznaczonych do zarzadzania˛ systemem. Automatyzacja taka moze˙ zmniejszyc´ konieczna˛ ilos´c´ pracy, jednak nakłady pracy z reguły nadal bed˛ a˛ bardzo wysokie. Ponadto nie kazda˙ organizacja jest w stanie sﬁnansowac´ kupno po cze˛sci´ bardzo drogiego oprogramowania do zarzadzania˛ systemem, zwłaszcza gdy jest to mniejsza organizacja. Stosowanie Terminal - Servers moze˙ znacznie zmniejszyc´ nakreslone´ problemy. Takze˙ w ramach kolejnych projektów migracyjnych nalezałoby˙ zastanowic´ sie˛ nad przyszłym wykorzystaniem Terminal - Servers i odpowiednich Thin Clients. W tradycyjnym zdecentralizowanym srodo´ wisku IT, instalacja i uruchamianie programów nastepuje˛ najcze˛sciej´ na komputerach peł- niac˛ ych role˛ stacji roboczych. Struktura serwerów słuzy˙ przede wszystkim do centralnego zarzadzania˛ danymi, zabezpieczania danych i sterowania prawami dostepu.˛ W przypadku zastosowania rozwiazania˛ Terminal - Server, wydajny komputer bad˛ z´ komputery centralne, tj. własciwe´ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 331

Terminal - Server, zapewniaja˛ dostep˛ z kazde˙ go miejsca do potrzebnych danych i aplikacji. Ter- minal - Servers oferuja˛uzytko˙ wnikom bezposredni´ dostep˛ do graﬁcznego interfejsu uzytko˙ wnika systemu operacyjnego poprzez siec.´ Kazdy˙ uzytko˙ wnik zalogowany do Terminal - Server otrzymuje własna˛ sesje˛ (Session) oraz prawo do korzystania ze wszystkich udostepnian˛ ych zasobów systemu operacyjnego. W przeciwienstwie´ do tradycyjnych zdecentralizowanych architektur stacji roboczych, nie jest to dostep˛ tylko do danych, lecz takze˙ do aplikacji z centralnego serwera. Dostep˛ do aplikacji i danych mieszczac˛ ych sie˛ w Terminal - Server musi sie odbywac´ za posred-´ nictwem specjalnych programów terminalowych bad˛ z´ tak zwanych Thin Clients. Ponizsza˙ tabela przedstawia zalety stosowania Terminal - Servers oraz Thin Clients.

ZALETY OBJAS´ NIENIA System operacyjny i aplikacje przechowywane sa˛ w Terminal - Servers centralnie tylko w prostej formie.

◦ Opieke˛ nad oprogramowaniem mozna˙ teraz sprawowac´ centralnie (łaty, aktualizacje).

◦ Nie sa˛ juz˙ wymagane zadne˙ prace w systemach klienckich.

◦ Opieka nad aplikacjami odbywa sie˛ centralnie, łatwiejsze centralne administro- staje sie˛ diagnozowanie i usuwanie błedów˛ . wanie ◦ Zwieksza˛ sie˛ wydajnos´c´ uzytko˙ wnika i administrowania.

– dzieki˛ uproszczeniu administrowania mozliwe˙ staje sie˛ szybsze udostepnianie˛ aplikacji uzytko˙ wnikom. – dzieki˛ temu, ze˙ nie trzeba juz˙ usuwac´ błedów˛ na miejscu, znacznie zmniejszaja˛sie˛ nakłady administracyjne. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 332

◦ Systemy klienckie wymagaja˛ małych zasobów sprzeto-˛ wych (karta sieciowa, karta graﬁczna, klawiatura, mysz).

zmniejszone wymaga- ◦ Regularna rozbudowa osprzetu˛ klienta zwiazana˛ z rosna-˛ nia sprzeto˛ we cymi wymaganiami systemów operacyjnych i aplikacji, nie jest juz˙ potrzebna.

◦ Istniejac˛ y osprzet˛ moze˙ byc´ dłuzej˙ wykorzystywany.

Wskutek stosowania Thin Clients (bez dysków twardych) dane moga˛ byc´ zapisywane tylko w centralnych serwerach [dotyczy zwiekszone˛ bezpie- to równiez˙ Fat Clients]. W ten sposób w systemach klienckich czenstwo´ zmniejsza sie˛ niebezpieczenstwo´ utraty danych bad˛ z´ manipulacji danymi przez nieupowaznione˙ osoby, wzglednie˛ ich kradziezy˙ , gdyz˙ osoby te nie maja˛ do nich dostepu.˛ Komputery pełniace˛ role˛ stacji roboczych mozna˙ szybko wymienic,´ poniewaz˙ w klientach nie sa˛ juz˙ zapisywane dane osobowe, niezalezno˙ s´c´ od klienta czy tez˙ ustawienia. Jednak przede wszystkim uzytko˙ wnicy maja˛ mozliwo˙ s´c´ dowolnego zmieniania miejsca pracy, bez rezygnowa- nia ze „swojego“ zaufanego srodo´ wiska.

Tablica 3.71: Zalety Terminal - Servers i Thin Clients

Oprócz opisanych powyzej˙ zalet nalezy˙ jednak takze˙ wymienic´ kilka wad, które nalezy˙ wzia˛c´ pod uwage˛ podczas podejmowania decyzji za bad˛ z´ przeciw zastosowaniu Terminal - Servers.

WADY OBJAS´ NIENIE ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 333

W przypadku awarii Terminal - Server przerywane sa˛ sesje uzyt-˙ kowników i nie jest mozliwe˙ ponowne podjecie˛ pracy przed usunieciem˛ błedu˛ po stronie serwera. Mozna˙ to zminimalizowac´ sto- uzaleznienie˙ sujac˛ Serverfarm. W przypadku przerwania sesji uzytko˙ wników moze˙ dojsć´ do utraty danych. Terminal - Servers musza˛dysponowac´ wyraznie´ wiekszymi˛ zasobami, zwłaszcza jesli´ chodzi o pamie˛c.´ Jednak w odniesieniu do zwiekszone˛ wymagania ogólnego zapotrzebowania (serwery i klienty) wielkosć´ wymaga- wzgledem˛ zasobów nych zasobów jest mniejsza, poniewaz˙ okreslone´ operacje wykonywane sa˛przez serwer tylko raz dla wszystkich uzytko˙ wników a nie na kazdym˙ jednym kliencie. Systemy serwerowe i klienckie komunikuja˛ sie˛ ze soba˛ na poziomie sieci, transmitowane sa˛ róznice˙ tresci´ podczas tworzenia obrazu albo instrukcje dla tworzenia obrazu. Okreslone´ aplika- zwiekszon˛ y ruch w cje (programy graficzne, itd.) moga˛ bardzo zwiekszy˛ c´ obcia˛ze-˙ sieci nie sieci. W przypadku innych aplikacji (np. edytorów tekstu) ruch sieciowy moze˙ sie˛ jednak takze˙ zmniejszyc,´ poniewaz˙ podczas zapisywania nie sa˛regularnie transmitowane pliki, lecz tylko zmiany (wpisy z klawiatury i zmiany na ekranie). Na Terminal - Server nie wszystkie aplikacje moga˛bezawaryjnie, pracowac,´ zwłaszcza jesli´ chodzi o aplikacje windowsowe, moga˛ dostosowywanie wyko- istniec´ takie, które podczas pracy otwieraja˛ pliki systemowe do rzystywanych aplikacji zapisu i tym samym sa˛ one zablokowane dla innych uzytko˙ wni- ków. Problemy te mozna˙ czesto˛ rozwiaza˛ c´ dzieki˛ pracy administracyjnej.

Tablica 3.73: Wybrane wady Terminal - Servers i Thin Clients

Połaczenie˛ z Terminal - Servers mozna˙ realizowac´ za pomoca˛ rózn˙ ych typów klientów.

Klienty Fat Chodzi tu o pełnowartoscio´ wa˛ stacje˛ robocza.˛ Dostep˛ do Terminal - Server odbywa sie˛ poprzez specjalne oprogramowanie dla Terminalserver - Client. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 334

Rysunek 3.44: Wykonywanie aplikacji X w kliencie Fat

Thin Clients Chodzi tu o systemy komputerowe złozone˙ z minimalnego wyposazenia.˙ Klienci pobieraja˛ system operacyjny bad˛ z´ to z Flash - EPROM bad˛ z´ bootuja˛ sie˛ poprzez siec´ (pxe, tftp, nfs) (patrz rys. 3.46). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 335

Rysunek 3.45: Uruchamianie aplikacji X i aplikacji windowsowych w Thin Client ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 336

Rysunek 3.46: Bootowanie systemu linuksowego poprzez siec´

Ponizej˙ przedstawilismy´ pokrótce kilka wybranych rozwiaza˛ n´ dla srodo´ wisk terminalowych.

3.16.3 Linux-Terminal-Server-Project

Linux Terminal Server Project (LTSP)125 umozliwia˙ bootowanie systemów klienckich do sys- temów serwerowych dzieki˛ wykorzystaniu wspaniałych mozliwo˙ sci´ dostarczanych przez linuksowy system X - Window. Wymagane aplikacje sa˛ ostatecznie uruchamiane po stronie serwera. Obraz z aplikacji pracujac˛ ych na serwerze przekazywany jest do terminali poprzez protokół X. Konﬁguracja systemu klienckiego realizowana jest za pomoca˛ prostego pliku tekstowego i oferuje cały szereg mozliwo˙ sci,´ pocza˛wszy od korzystania z lokalnych drukarek a skonczywszy´ na lokalnym uruchamianiu programów. Dzieki˛ projektowi LTS mozna˙ korzystac´ z tanich stacji roboczych, jako terminali serwera linuksowego bad˛ z´ uniksowego. Klienci moga˛pracowac´ zarówno w trybie tekstowym, jak i graﬁcznym. Bootowanie systemów klienckich inicjowane jest przez serwer i odbywa sie˛ poprzez siec.´ W tym celu we wszystkich systemach klienckich nalezy˙ zastosowac´ specjalne Boot - ROMS, które mozna˙ umiesci´ c´ w obecnych adapterach sieciowych. Zarzadzanie˛ danymi uzytko˙ wników, wzglednie˛ danymi kont odbywa sie˛ za pomoca˛tradycyjnych narzedzi˛ dostarczanych wraz z GNU / Linux. Ponizej˙ przedstawilismy´ dwa przykłady ilustrujace˛ zastosowanie LTSP.

3.16.3.1 Rozwiazanie˛ GOto

W ramach projektu migracyjnego realizowanego w Zakładzie Hodowli Zwierzat˛ zastosowano rozwiazanie˛ GOto126. Rozwiazanie˛ to stworzyła firma GONICUS i udostepniła˛ jego cze˛sci´ skła- dowe jako Wolne Oprogramowanie. Najwazniejsz˙ a˛róznic˙ a˛ w porównaniu z LTSP jest uproszczone zarzadzanie˛ oparte na LDAP. Cała konfiguracja i profile uzytko˙ wników składowane sa˛ centralnie, po stronie serwera, dzieki˛ zastosowaniu usługi katalogowej LDAP (Lightweight Directory Access Protocol). W zwiazku˛ z tym istnieje gwarancja, ze˙ kazdy˙ uzytko˙ wnik ma dostep˛ do swojego, specjalnego profilu, aplikacji i danych z kazdej˙ stacji roboczej. Administrowanie moze˙ odbywac´ sie˛ poprzez Frontend

125http://www.ltsp.org/ 126http://www.gonicus.de/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 337

WWW o nazwie Gosa. Frontend ten umozliwia˙ dostep˛ do wymaganych struktur LDAP i zarza-˛ dzanie nimi. Obydwa rozwiazania˛ udostepniane˛ sa˛ na licencji GPL. GOto umozliwia˙ takze˙ pełne bootowanie systemów Thin Client poprzez siec,´ z odpowiednich serwerów. Proces bootowania rozszerzony został o standardowy protokół PXE, poniewaz˙ odpowiednie opcje bootowania sa˛ obecnie obsługiwane przez coraz wieksz˛ a˛ ilos´c´ kart sieciowych, wskutek czego w wielu przypadkach nie jest juz˙ wymagane stosowanie Boot - ROM. Oprócz Thin Clients obsługiwane sa˛takze˙ Fat Clients. Zarzadzanie˛ Fat Clients moze˙ odbywac´ sie˛ w taki sam sposób, jak zarzadzanie˛ Thin Clients. Po pierwszym zainstalowaniu Fat Clients mozna˙ je automatycznie uaktualniac.´

3.16.3.2 Desktop-Server

Univention_desktop Server127 jest komercyjnym, zintegrowanym i skalowalnym, opartym na Li- nuksie rozwiazaniem˛ serwerowym z modułem obsługujac˛ ym Thin Clients oraz z rozszerzona˛ wersja˛ usługi katalogowej OpenLDAP jako Backendem słuz˙ac˛ ym do zarzadzania˛ konfiguracja˛ i uzytko˙ wnikami. Jesli´ chodzi o róznic˙ e˛ wzgledem˛ LTSP, to jest ona taka sama, jak w przypadku rozwiaza-˛ nia GOto i polega na tym, ze˙ uruchamianie systemów jest realizowane nie tylko poprzez BO- OTP, lecz takze˙ poprzez PXE. Oprócz tego udostepniane˛ sa˛ specjalne narzedzia˛ do kontroli sesji uzytko˙ wników, dzieki˛ czemu podczas wyłaczania˛ klientów nie powstaja˛ „martwe procesy“. Do- datkowo mozliwy˙ jest dostep˛ do lokalnych urzadze˛ n´ podłaczon˛ ych do Thin Client, takich jak CDROM, Floppy, karta dzwi´ eko˛ wa czy drukarka (administrator moze˙ jednak ograniczyc´ ten dostep).˛ Wspólne zarzadzanie˛ konfiguracja˛ i uzytko˙ wnikami znajduje sie˛ w katalogu LDAP. Ponadto administrowanie wpisuje sie˛ w administrowanie windowsowymi i linuksowymi Fat Clients. Dzieki˛ zintegrowanemu Load - Balancing uzyskiwana jest dobra skalowalnosć´ a w razie potrzeby mozna˙ w prosty sposób zintegrowac´ z systemem dodatkowe serwery bootowania i aplikacji.

3.16.4 Usługi terminalowe NX

Produkt NX ﬁrmy Nomachine128 z Włoch jest dos´c´ nowa˛ technologia˛ serwerów terminalowych oparta˛ na Linuksie. Jest to produkt komercyjny. Po wieloletnim okresie rozwoju oprogramowania, developerom udało sie˛ zaimplementowac´ bardzo wydajny kompresor dla protokołu X -

127http://www.univention.de/ 128http://www.nomachine.com/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 338

Window. Jak wiadomo system X - Window zaprojektowany został tak, ze˙ jest on przezroczysty dla sieci. Oznacza to, ze˙ wyswietlanie´ kazdej˙ aplikacji moze˙ odbywac´ sie˛ na odległym ekranie. Niestety uzywan˙ y protokół nie jest szerokopasmowy. Dlatego dotychczas stosowanie protokołu X - Window miało sens tylko w LAN. Wprawdzie było juz˙ kilka prób, poprawienia jego przydatnosci´ dla WAN za pomoca˛Caching Events i Bitmaps bad˛ z´ poprzez kompresje˛ samego protokołu (Low band X), jednak uzyskane wyniki okazały sie˛ byc´ niewystarczajace.˛ Technologia NX uzyskała, w tzw. miedzyczasie,˛ współczynnik kompresji, który jest porów- nywalny ze współczynnikiem z Citrix. NX - Server pracuje na jednym albo wielu serwerach linuksowych i moze,˙ oprócz protokołu X - Window, wydajnie transmitowac´ do NX - Client takze˙ Microsoft RDP i protokół Frame - Buffer przegladarki˛ VNC. NX - Client moze˙ pracowac´ w Linuksie, Windows, w PDAs iPAC i Zaurus. Oprócz wydajnej transmisji tresci´ ekranu, technologia NX umozliwia˙ takze˙ dostep˛ do lokalnego sytemu plików i przekaz danych audio. Nie jest jeszcze mozliwe˙ przekierowanie interfejsu szeregowego. Jesli´ chodzi o technologie,˛ sytem ten opiera sie˛ w znacznym stopniu na składni- kach Open Source. Wszystkie składniki umozliwiaj˙ ace˛ kompresje˛ sa˛ udostepniane˛ na licencji GPL. Cała komunikacja jest szyfrowana za pomoca˛ tunelu SSH. Podobnie, jak w przypadku Citrix Metaframe mozliwe˙ jest „publikowanie“ tylko okna pojedynczej aplikacji. Dzieki˛ temu mozna˙ bardzo elastycznie integrowac´ swiat´ aplikacji windowsowych i linuksowych. Umozliwia˙ to przekazywanie windowsowych aplikacji na desktop Linuksa albo linuksowych aplikacji na desktop Windowsa. Przez oddzielenie serwera aplikacji i wezłów˛ kompresji uzyskiwana jest zewnetrzna˛ skalowalnos´c.´ Server aplikacji nie jest przy tym dodatkowo obcia˛zan˙ y przez kompresje˛ danych. Nie dochodzi do konﬂiktów pomiedzy˛ wersjami aplikacji i serwerem kompresji. Interesujac˛ y jest model licencji, poniewaz˙ nie zalezy˙ ona od ilosci´ klientów, lecz od ilosci´ we-˛ złów serwera. Dzieki˛ temu cena produktu jest znacznie korzystniejsza od cen innych produktów dostepn˛ ych na rynku.

3.16.5 Windows Terminal Services i Citrix

Cała logika aplikacji udostepniana˛ jest centralnie, z serwera, przez co wymagana szerokosć´ pasma pomiedzy˛ klientem a serwerem wynosi około 10 do 20 kB/s. Dzieki˛ oddzieleniu logiki aplikacji od interfejsu uzytko˙ wnika na Terminal - Servers, podczas odwoływania sie˛ do serwera plików, serwera wydruku, serwera bazy danych, etc., Backbone jest silniej obcia˛zon˙ y w porów- naniu z klasycznymi srodo´ wiskami Client - Server. Główna˛cze˛sci´ a˛składowa˛technologii Terminal - Server sa˛serwery, w których zainstalowane sa˛ aplikacje. Terminal - Server umozliwia˙ równoległy dostep˛ wielu uzytko˙ wników w czasie se- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 339 sji (Sessions), podczas których uzytko˙ wnicy moga˛ uruchamiac´ aplikacje w chronionym obszarze pamieci.˛ Poniewaz˙ nieskonfigurowani uzytko˙ wnicy posiadaja˛ wszystkie uprawnienia, nalezy˙ chronic´ system przed niezamierzonymi bad˛ z´ nieuprawnionymi akcjami ze strony uzytko˙ wników. W tym celu mozna˙ skorzystac´ ze srodków´ znanych z administrowania w NT, takich jak profile oparte na serwerze, stosowanie Policies i ustawien´ NTFS - Security wzgledem˛ plików i katalo- gów, które gwarantuja˛ wymagane bezpieczenstwo.´ Ponadto w srodo´ wisku Terminal - Server szczególna˛ role˛ przypisac´ mozna˙ testom aplikacji, które maja˛ umozliwi˙ c´ przeprowadzenie Server - Sizing. Dlatego nieodzowna jest wiedza o tym,

◦ jaka jest wydajnos´c´ procesora oraz

◦ ile pamieci˛ operacyjnej wymaga aplikacja,

◦ ilu uzytko˙ wników korzysta jednoczesnie´ z danego programu,

◦ czy program jest 16 bitowa˛ aplikacja˛ DOS,

◦ czy aplikacja w ogóle moze˙ pracowac´ w trybie multiuser.

Windows Termina Service oferowana jest dla Windows NT 4 jako oddzielna odmiana produktu („Terminal Server Edition“, TSE). W przypadku Windows 2000 usługa ta miesci´ sie˛ w kazdym˙ jego wariancie. O ile nie uzywa˙ sie˛ Metaframe ﬁrmy Citrix, komunikacja pomiedzy˛ Terminal Server a Ter- minal Server Client realizowana jest poprzez protokół RDP (Remote Desktop Protocol) oparty na numerach IP. Windows NT 4 TSE obsługuje RDP w wersji 4, Windows 2000 rozszerzony RDP 5. Microsoft dostarcza Terminal Server Clients (RDP Clients) dla wszystkich windowsowych systemów operacyjnych (takze˙ 16 bitowych). Inni producenci dostarczaja˛ dodatkowe klienty RDP dla pozostałych runtime environment (np. Java). Wada˛ w przypadku rozwiazania˛ Terminal Server opartego wyłacznie˛ na produktach Micro- soft jest fakt, ze˙ uzytko˙ wnik chce sie˛ połaczy˛ c´ z okreslon´ ym serwerem. Powoduje to komplika- cje, gdy:

◦ serwer nie jest dostepn˛ y albo ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 340

◦ serwer jest przecia˛zon˙ y

Zaradzic´ temu mozna˙ stosujac˛ produkt Metaframe firmy Citrix. Za pomoca˛ Metaframe mozna˙ łaczy˛ c´ logicznie wiele Termina Servers w Serverfarm. Uzytko˙ wnik (klient) nie widzi wówczas pojedynczego serwera, lecz tak zwane rozgłoszone aplikacje, z którymi sie˛ łaczy˛ . O tym, na którym serwerze uruchamia on potem swoje aplikacje, decyduje mechanizm mieszczac˛ y sie˛ w farmie serwerów. W tym miejscu nalezy˙ wyraznie´ stwierdzic,´ ze˙ mimo wszystkich omówionych przykładów powyzsza˙ ocena nie oddaje całej złozono˙ sci´ rozwiazania˛ Citrix, ani jego mozliwo˙ sci.´ Nakre- slili´ smy´ zaledwie podstawowa˛ zasade˛ działania tej technologii. Jednak w tym miejscu jest to całkowicie wystarczajace,˛ aby wskazac´ mozliwo˙ sć´ uruchamiania aplikacji windowsowych na desktopie Linuksa za pomoca˛ Citrix Metaframe. Aby zagwarantowac´ te˛ funkcjonalnosć,´ Mainframe zawiera tak zwany protokół ICA (Inde- pendent Computer Architecture). Wymagany klient ICA istnieje dla

◦ wszystkich systemów operacyjnych Windows

◦ DOS

◦ Java

◦ wielu odmian Uniksa (takze˙ dla Linuksa)

oraz

◦ systemów Handheld

Po stronie serwera, w pierwszym rzedzie˛ obsługiwane sa˛ w/w systemy operacyjne ﬁrmy Micro- soft (Windows NT 4 TSE i Windows 2000). Istnieja˛ jednak takze˙ rozwiazania˛ dla Uniksa (np. Metaframe dla Solaris). Obecnie Metaframe dostarczane jest przez ﬁrme˛ Citrix w dwóch odmianach:

◦ Metaframe 1.8

oraz

◦ Metaframe XP. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 341

Wersje˛ XP nalezy˙ traktowac´ jako wariant strategiczny, poniewaz˙ wersja 1.8 w najblizszej˙ przy- szłosci´ przestanie byc´ wspierana. Metaframe mozna˙ spotkac´ w duzych˙ srodo´ wiskach z duz˙a˛ ilosci´ a˛ serwerów, gdyz˙ srodo´ wiska te wymagaja˛ inteligentnego „Load Management“ (przydzielanie obcia˛zenia).˙ Jesli´ z wielu Terminal Servers stworzona zostanie tak zwana farma serwerów, wówczas mozliwe˙ jest przydzielanie obcia˛zenia˙ poszczególnym serwerom. Nastepuj˛ ac˛ y rysunek pokazuje schemat farmy serwerów pracujacej˛ pod kontrola˛ Metaframe XP.

Rysunek 3.47: Serverfarm pod kontrola˛ Metaframe XP

Przydzielanie obcia˛zenia˙ przyczynia sie˛ do zapewnienia wydajnosci´ i dostepno˛ sci´ aplikacji w całym systemie, poniewaz˙ uzytko˙ wnicy nie sa˛kierowani do serwera, na którym nastapiła˛ awaria. Jesli´ serwery współpracuja˛ z programem oceniajac˛ ym obcia˛zenie,˙ wówczas w Metaframe XP nastepuje˛ przekazanie wyniku z danego serwera do punktu gromadzenia danych (Data Col- lector) i zapamietan˛ y dla nadchodzac˛ ych zapytan.´ Jesli´ udostepniana˛ aplikacja wywoływana jest poprzez klienta ICA, wówczas punkt gromadzenia danych wyszukuje i okresla´ serwer, który w momencie nadejscia´ zapytania posiada najwieksz˛ a˛ wydajnos´c´ i komunikuje to klientowi. Na- stepnie˛ klient łaczy˛ sie˛ z tym serwerem. W przypadku farm serwerów, które na przykład składaja˛ sie˛ z maszyn jedno bad˛ z´ dwupro- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 342

cesorowych, dla odpowiednich serwerów mozna˙ róznie˙ okresla´ c´ zasady przydzielania. Gdy zasada okreslaj´ aca˛ obcia˛zenie˙ dla aplikacji udostepnianej˛ przez maszyne˛ dwuprocesorowa˛ ustala jej pełne obcia˛zenie˙ w przypadku 50 uzytko˙ wników, oznacza to, ze˙ maszyna jednoprocesorowa osiagnie˛ pełne obcia˛zenie˙ juz˙ przy 25 zalogowanych uzytko˙ wnikach. Dzieki˛ takiemu „Tuning“ mozna˙ wyrównywac´ róznice˙ w osprzecie.˛ Jesli´ chodzi o technologie˛ Terminal Server, celowe jest wczesniejsze´ zwrócenie uwagi na nastepuj˛ ace˛ aspekty techniczne:

◦ farmy serwerów wymagaja˛ domeny Windows (logowanie)

◦ farmy serwerów pracuja˛ z chronionymi przez serwer proﬁlami, co ma na celu umozliwie-˙ nie obsługi mobilnych uzytko˙ wników (stabilne File Services)

◦ Windows Terminal Server drukuja˛ poprzez RPC do windowsowych serwerów wydruku, co ma na celu odcia˛zenie˙ Terminal Server

◦ konto uzytko˙ wnika w domenie Windows uzupełniane jest o dodatkowe, specyﬁczne parametry Terminal Server.

◦ nie kazda˙ aplikacja windowsowa umie pracowac´ w Terminal Servers (nalezy˙ to sprawdzic,´ nakład zwiazan˛ y z integracja).˛

3.17 High-availability – systemy wysokiej niezawodnosci´

Aby móc przedstawic´ mozliwo˙ sci´ spełnienia przez Open Source Software wymagan´ wzgledem˛ wysokiej niezawodnosci,´ nalezy˙ najpierw scharakteryzowac´ zakres zadan.´

3.17.1 Cele

Wysoko niezawodne instalacje udostepniaj˛ a˛ usługi w taki sposób, ze˙ w czasie ich awarii parametry takie jak minimalna pojemnosć,´ przepustowosć´ i inne nie moga˛ zejsć´ ponizej˙ okreslon´ ych granic. Jest to wymagane z wielu powodów:

◦ usługi sa˛ niezbedne˛ wewnatrz,˛ np. gdy sa˛one podstawa˛dla działan´ wielu uzytko˙ wników a ich awaria doprowadziłaby do powstania szkód ﬁnansowych.

◦ usługi sa˛ wazne˙ ze wzgledów˛ bezpieczenstwa´ a ich awaria mogłaby zagraza˙ c´ interesom narodowym ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 343

◦ usługi musza˛ byc´ udostepniane˛ obywatelom albo ﬁrmom bezawaryjnie albo w sposób cia-˛ gły.

Wraz z przyjeciem˛ inicjatywy e-Government, Republika Federalna Niemiec postawiła przed soba˛ wyzwanie stworzenia nowoczesnego, wydajnego panstwa.´ Oznacza to z jednej strony, ze˙ stale ma miejsce komunikacja z systemami BackEnd (np. bazami danych) albo ze˙ stale moga˛ napływac´ nowe wnioski, które nie moga˛ zgina˛c.´ Z drugiej strony zwiazane˛ z tym dłuzsze˙ czasy dostepno˛ sci´ usług oznaczaja˛ takze˙ nowe wyzwania wzgledem˛ systemów Frontend. Nie tylko maja˛ zmniejszyc´ sie˛ koszty i czas obsługi, lecz takze˙ wizerunek administracji publicznej moze˙ ulec znacznej poprawie dzieki˛ takim inicjatywom. Jednak niedostepno˛ s´c´ danych usług spowo- dowałaby efekt przeciwny do zakładanego.

3.17.2 „Pie˛c´ dziewiatek”˛ a rzeczywistos´c´

Systemy wysokiej niezawodnosci´ (systemy HA, patrz angielskie wyrazenie˙ high availability) mozna˙ podzielic´ na kategorie, m.in. według procentowego czasu, w którym udostepniaj˛ a˛ one usługi. Co to oznacza dla systemu HA, który ma byc´ udostepnian˛ y przez cała˛dobe,˛ pokazalismy´ w nastepuj˛ acej˛ tabeli:

Maksymalna awaryjnosć´ w Maksymalna awaryjnosć´ w Dostepno˛ sć´ ciagu˛ miesiaca˛ ciagu˛ roku 99,5% 3 godziny, 39 minut 43 godziny 99,7% 2 godziny, 12 minut 26 godzin 99,9% 44 minuty 8 godzin 99,99% 4 minuty 1 godzina 99,999% 5 minut

Tablica 3.75: Wymagania wzgledem˛ systemu HA

Powyzsze,˙ czesto˛ cytowane liczby nie sa˛jednak realistyczne. Wiekszo˛ sć´ umów serwisowych (SLAs, service level agreements) zawiera zdefiniowane czasy konserwacji okreslaj´ ace,˛ jak długo dana usługa bedzie˛ niedostepna.˛ Jednak czas ten nie jest traktowany jako awaria, co znaczy, ze˙ w wiekszo˛ sci´ przypadków wysoka dostepno˛ sć´ okreslana´ jest w oparciu o niezaplanowane awarie. Jako przykład moze˙ posłuzy˙ c´ wymaganie stawiane bazie danych SAP, ze˙ powinna byc´ ona ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 344

dostepna˛ w godzinach urzedo˛ wania biura, tj. od 7.00 do 19.00. Dzieki˛ mozliwo˙ sci´ pracy nad systemem poza wspomnianymi godzinami, mozliwe˙ jest znacznie łatwiejsze i tansze´ spełnienie wymagan,´ niz˙ w nierealnym przypadku okreslaj´ ac˛ ym 5 minutowy czas awarii w ciagu˛ roku przy pracy 24 x 365.

3.17.3 Sposób podejscia´ do problemu

Wysoka˛ niezawodnos´c´ uzyskuje sie˛ chroniac˛ zasoby przed nadmiarem informacji i kontrolujac˛ ich funkcjonalnos´c.´ W przypadku nieprawidłowego zachowania jednego ze składników, inny składnik automatycznie przejmuje swiadczenie´ usługi. W tym momencie dochodzi jednak do naruszenia redundancji albo nawet jej zaniku, dlatego bezzwłocznie nalezy˙ przystapi˛ c´ do prac naprawczych. Systemy HA wymagaja˛ bardzo duze˙ go wsparcia administracyjnego i same z siebie nie bed˛ a˛pracowac.´ Wazn˙ a˛miara˛jakosci´ jest przy tym czas potrzebny na wykonanie naprawy (MTTR, mean time to repair) a nie czas do kolejnego wystapienia˛ błedu˛ (MTBF, mean time between failure).

Redundancja moze˙ wystapi˛ c´ na kazdym˙ poziomie.

POZIOM ABSTRAKCJI srodo´ wisko uzytko˙ wnika bad˛ z´ administratora Disaster Recovery aplikacja Dzielone aplikacje Middleware Clustering system operacyjny Kontrolowanie zasobów, restart, failover Hardware Podwajanie składników

Tablica 3.77: Zestawienie poziomów abstrakcji

Redundancja sprzeto˛ wa w przypadku dysków jest juz˙ dzis´ standardem (mirroring, RAID1; RAID5 obecnie juz˙ sie˛ prawie nie spotyka) i jest dostepna˛ dla wszystkich platform. W przypadku innych składników sprawa jest juz˙ trudniejsza. Redundantnie skonﬁgurowane karty sieciowe sa˛ rzadko obsługiwane. W centrum naszych rozwaza˙ n´ znajduje sie˛ obsługa redundancji sprzeto˛ wej przez system operacyjny. Własnoscio´ we systemy Unix i oczywiscie´ takze˙ Mainframes wykazuja˛ tu znaczne zalety, którym według oceny autorów poradnika systemy Open Source nie bed˛ a˛ w stanie sprostac´ w najblizszym˙ czasie. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 345

Redundancja na poziomie systemu operacyjnego realizowana jest poprzez kontrole˛ zasobów i ich składowania na innym komputerze w przypadku awarii (failover). Niektóre składniki Middleware (np. bazy danych albo monitory transakcji) udostepniaj˛ a˛ mozliwo˙ sć´ traktowania wielu systemów jako jeden system. Niektóre aplikacje tego nie potrzebuja,˛ poniewaz˙ sa˛ przydzielane przez serwer do wielu komputerów, na których pracuja˛ i awaria jednego z nich nie powoduje problemów. Jesli´ wysoka niezawodnosć´ ma byc´ dostepna˛ na jednym poziomie abstrakcji, wówczas teoretycznie jest ona wystarczajaca˛ dla wszystkich nizszych˙ poziomów abstrakcji. W praktyce siła systemu HA i wynikajaca˛ z niej niezawodnosć´ rosnie,´ gdy srodki´ zwiazane˛ z redundancja˛ zastosowane zostana˛ na mozliwie˙ wielu poziomach – ostatecznie błedy˛ moga˛ powstawac´ takze˙ w podsystemie HA, co oznacza, ze˙ musi istniec´ mozliwo˙ sć´ zastapienia˛ go innym redundantnym składnikiem. W koncu´ nie wolno zapomniec´ o najwiekszym˛ zródle´ błedów˛ , którym jest człowiek, tutaj w roli administratora systemu albo programisty. System czesto˛ przejmuje błedy˛ w administrowaniu lub programowaniu. Nastepstwem˛ tego jest obarczenie błedem˛ swiadczon´ ych, redundantnych usług albo składników. Jesli,´ np. wskutek błedu˛ administracyjnego, usunietych˛ zostanie kilkaset GB, wówczas nie pomoze˙ mirroring ani redundancja usług. Dane zostana˛ usuniete˛ ze wszystkich składników. Dlatego dobry Backup i Restore, a w pewnych okolicznosciach´ takze˙ Disaster Recovery w ramach planowania Business Continuity, sa˛ elementarnymi cze˛sciami´ składowymi rozwiazania˛ HA.

3.17.4 Kategorie systemów HA

O ile redundancja zawsze jest podstawowa˛ zasada˛ wysokiej niezawodnosci,´ istnieja˛ rózne˙ sposoby uzyskiwania redundancji:

◦ Failover: Jest to „klasyczna“ architektura systemu HA; dwie do trzech maszyn, który w przypadku awarii danej usługi próbuja˛ja˛najpierw ponownie uruchomic.´ Jesli´ to sie˛ nie uda, wówczas nastepuje˛ transfer usługi do innej maszyny, na której jest ona uruchamiana.

◦ Application Clustering Nieliczne aplikacje, dzieki˛ przystosowaniu do pracy w klastrach, sa˛ w stanie pracowac´ na wielu maszynach w taki sposób, ze˙ wygladaj˛ a˛ one z zewnatrz˛ jak jeden system, w którym w razie awarii pojedynczych maszyn jest ona przezroczyscie´ niwelowana. Najbardziej zna- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 346

nym przykładem wspomnianej architektury jest Oracle 9i z opcja˛Real Application Cluster (RAC).

◦ farmy serwerów Niniejszy sposób postepo˛ wania stał sie˛ popularny zwłaszcza w przypadku serwerów WWW. „Load Balancer“ przydziela nadchodzace˛ Requests wielu maszynom. Metode˛ te˛ mozna˙ przede wszystkim stosowac´ w przypadku usług bez stanu. Czesto˛ uzywana˙ jest ona do realizacji FrontEndu, podczas gdy BackEnds pracuja˛ na urzadzeniu˛ Failover.

◦ Jesli´ chodzi o bazy danych, do Disaster Recovery czesto˛ stosuje sie˛ takze˙ Redo - Log - Shipping. Tworzone sa˛ przy tym Redo - Logs wszystkich transakcji, które nastepnie˛ przesyłane sa˛ do komputera tworzace˛ go Backup, w którym przetwarzanie ich prowadzi równiez˙ do uaktualnienia stanu bazy danych.

Dzieki˛ powyzszemu˙ podziałowi na kategorie mozna˙ ustalic,´ jakie rozwiazania˛ wysokiej niezawodnosci´ istnieja˛ i gdzie sensowne jest wykorzystywanie produktów Open Source.

Rysunek 3.48: Rozwiazania˛ HA

Niedostateczne stosowanie klastrów pracujac˛ ych z niewielka˛ ilosci´ a˛ duzych,˙ całkowicie redundantnie zoptymalizowanych maszyn, spowodowana jest przede wszystkim tym, ze˙ stoso- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 347

wany, specjalistyczny osprzet˛ czesto˛ nie jest w wystarczajac˛ y sposób obsługiwany przez system operacyjny. Open Source Software mozna˙ stosowac´ przede wszystkim w obszarze farm serwerów, najlepiej w systemach bez duzych˙ stanów sesji. Typowymi przedstawicielami sa˛ serwery WWW, E - Mail - Gateways, File Server oraz Print Server. Istnieje mało aplikacji Open Source z serwerami aplikacji. Mozna˙ je tu zastosowac,´ o ile wymagania SLA nie sa˛ bardzo wysokie (np. 99,9% czasu pracy biur lub inne). W takim przypadku wysoka niezawodnos´c´ jest najcze˛sciej´ gwarantowana poprzez architekture˛ Failover. Istnieja˛ jednak takze˙ mozliwo˙ sci´ tworzenia klastrów na poziomie Middleware (np. wykorzystujac˛ JBoss). Wysoko niezawodne bazy danych Open Source nie istnieja.˛ Jednak mozna˙ tu zaplanowac´ wykorzystanie własnoscio´ wego oprogramowania (np. Oracle RAC) w Linuksie i cze˛scio´ wo uzyskac´ w ten sposób znaczne oszczedno˛ sci,´ jesli´ chodzi o koszty osprzetu.˛

3.17.5 Komercyjne oprogramowanie HA

Oprogramowanie HA jest domena˛ swiata´ uniksowego i Mainframe. Windows DataCenter uznawany jest z reguły za niewystarczajace˛ dla aplikacji mission - critical. Na poziomie systemu operacyjnego kazdy˙ z duzych˙ producentów oprogramowania uniksowego udostepnia˛ rozwiazanie˛ HA odpowiadajace˛ architekturze Failover; HP po fuzji z Compaq nawet dwa, jednak wymieniamy tu tylko to, które przetrwało.

IBM HP SUN system operacyjny / pa- AIX HP-UX Solaris kiet HA HACMP MX / Serviceguard Sun Cluster system plików JFS2 HFS UFS z Sun VM klastrowy system pli- tak nie tak ków maksymalna ilos´c´ ma- 32 16 8 szyn obsługa wielu instancji tak tak tak aplikacji partycjonowanie tak tak tak Failover istniejac˛ ych nie tak tak połacze˛ n´ TCP ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 348

Ultra3 SCSI Ultra3 SCSI Ultra3 SCSI technologia zapisu Fiberchannel Fiberchannel Fiberchannel CampusCluster Metrocluster opcje do Disaster Reco- HAGEO Storage Data Ne- Continental Cluster very GeoRM twork Replicator Continous Access XP GUI zintegro- GUI zintegro- administrowanie oddzielny GUI wany z SMIT wany z SUNMC

Tablica 3.79: Przeglad˛ komercyjnego oprogramowania HA

Jak juz˙ wspomnielismy´ , Oracle RAC jest w obszarze baz danych najwazniejsz˙ a˛ mozliwo-˙ sci´ a˛ udostepniania˛ wysokiej niezawodnosci´ takze˙ na poziomie Middleware. Rozwiazanie˛ to jest dostepne˛ dla własnoscio´ wych systemów Unix, Linuksa oraz serwera windowsowego.

3.17.6 Rozwiazania˛ Open Source dla systemów HA

Swiat´ Open Source Tools rozwija sie˛ niesłychanie szybko. Niniejszy podrozdział zawiera przeglad˛ istniejace˛ go oprogramowania Open Source HA, które jest szeroko stosowane i które spraw- dziło sie˛ w wielu instalacjach. Jednak dla konkretnych projektów HA moze˙ to byc´ tylko wskaza- nie potencjalnej przydatnosci.´ W kazdym˙ projekcie trzeba na nowo okresli´ c´ architekture˛ i sprawdzic´ sposób wykorzystania poszczególnych Tools. Autorzy analizy widza˛koniecznosć´ właczenia˛ do kazde˙ go projektu doswiadczon´ ych specjalistów. Wiele z wymienionych ponizej˙ Tools udostepnian˛ ych jest oczywiscie´ takze˙ przez firmy. W Niemczech niemal wszystkie linuksowe Tools udostepnia˛ SuSE. Pomoc techniczna˛ oraz wsparcie podczas tworzenia projekty zapewnia wiele firm, m.in. takze˙ EDS.

3.17.6.1 Podsystemy dysków

Od jadra˛ Linuksa w wersji 2.4, które stosowane jest we wszystkich obecnych dystrybucjach, Linux obsługuje mirroring dysków za pomoca˛Multi - Disk (md) Kernel Moduls. Niniejszy podsystem obsługuje równiez˙ dostep˛ multi - path, tzn. jednoczesne podłaczenie˛ podsystemów dys- ków do rózn˙ ych komputerów. Jest to wymagane dla dysków gromadzac˛ ych dane i aplikacje w ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 349

architekturze Failover. Dyski systemowe musza˛ byc´ podłaczone˛ zawsze dokładnie do jednego komputera. Wraz z LVM pojawił sie˛ funkcjonalny Volume Manager. ext3 stał sie˛ domysln´ ym systemem plików z Journaling (patrz takze˙ rozdział 3.11.4).

3.17.6.2 Failover za pomoca˛ heartbeat

Architektura Failover dla systemów linuksowych moze˙ byc´ realizowana za pomoca˛ heartbeat. heartbeat obsługuje definicje grup zasobów (usługi, systemy plików oraz adresy IP), które w przypadku awarii moga˛ zostac´ uruchomione na innym serwerze. Nastepuje˛ przy tym przejecie˛ istniejac˛ ych stanów sesji. Poniewaz˙ Linux nie obsługuje konfiguracji Multi - Path kart sieciowych, kontrola dostepno˛ sci´ usługi moze˙ byc´ przeprowadzana poprzez rózne˙ kanały komunikacyjne (szeregowo i siec).´ Czesto˛ jest tak, ze˙ w przypadku awarii usługi powinno nastapi˛ c´ automatyczne bootowanie urzadzenia.˛ Najbardziej udokumentowanym rozwiazaniem˛ jest „watchdog“. Jest ono podatne na błedy˛ i prowadzi do zbyt czestych˛ Reboots. W wielu przypadkach lepszy powinien byc´ moduł o nazwie „hangcheck - timer“. Wybór modułu nalezy˙ pozostawic´ doradcom, którzy planuja˛ konkretne zastosowanie architektury HA. Kazdy˙ projekt HA powinien wzia˛c´ pod uwage˛ takze˙ ograniczenia rozwiazania˛ Failover z rodziny Open Source. Nie istnieje klastrowy sytem plików, maksymalna ilosć´ maszyn w klastrze Failover nie powinna byc´ wieksza˛ niz˙ trzy, nie jest obsługiwane logiczne partycjonowanie istniejac˛ ych maszyn (przyporzadko˛ wanie zasobów sprzeto˛ wych, takich jak CPU oraz miejsca na dysku do grup zasobów) oraz brak jest równiez˙ opcji do Disaster Recovery. heartbeat jest czesto˛ stosowanym modułem; projekt Linux - HA przyznaje, ze˙ wspomniany moduł wykorzystywany jest w zastosowaniach produkcyjnych w tysiacach˛ instalacji na całym swiecie.´ Stanowi on rdzen´ rozwiaza˛ n´ HA oferowanych przez przodujac˛ ych producentów oprogramowania linuksowego (SuSE, Conectiva, Mandrake). Jednym ze znanych uzytko˙ wników w Niemczech jest Bayerische Rundfunk, która w oparciu o heartbeat realizuje Olympia - Web - Site 2002 stacji ARD. W biurze Pełnomocnika Rzadu˛ ds. Ochrony Danych Osobowych, w ramach projektu migracyjnego opartego na Heartbeat129, mozliwe˙ było stworzenie niezawodnego systemu wysokiej niezawodnosci.´ Ponizszy˙ rysunek przedstawia zastosowane tam rozwiazanie˛ i jego architekture.˛

129http://linux-ha.org/heartbeat/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 350

Rysunek 3.49: Rozwiazanie˛ oparte o Heartbeat i DRBD

Wykorzystana kombinacja programów składajace˛ sie˛ z Heartbeat i DRBD130 (Distributed Re- plicated Block Device) realizuje rozwiazanie˛ wysokiej niezawodnosci´ dla serwerów plików, ser- werów drukarek, serwerów poczty elektronicznej, serwera WWW, usług domen (DNS, DHCP) oraz usługi katalogowej. Kontrola wezłów˛ serwerów odbywa sie˛ za pomoca˛ Heartbeat. W tym celu maszyny zostały połaczone˛ poprzez Crossover - Ethernet i szeregowy kabel null modem. Gdy aktywny serwer nie jest juz˙ dostepn˛ y ta˛ droga˛ komunikacji, wówczas serwer Failover automatycznie przejmuje wirtualne adresy i odpowiednie usługi. Oprócz wysokiej niezawodnosci,´ dzieki˛ programowi DRBD, uzyskiwany jest mirroring Raid-1 partycji bad˛ z´ logical Volumens. W ten sposób w przypadku awarii aktywnego serwera, drugi serwer ma dostep˛ do zapisanych danych. Zastosowanie DRBD zamiast zewnetrzn˛ ych systemów SAN moze˙ byc´ tansz´ a˛ alternatywa˛ realizujac˛ a˛ okreslone´ scenariusze.

3.17.6.3 Farmy serwerów

Infrastrukture˛ dla serwera farm oferuje Linux Virtual Server (LVS). Load Balancer w Linuksie przydziela nadchodzace˛ Requests do wielu rzeczywistych systemów. Dla uzytko˙ wnika konco-´ wego systemy te nie sa˛ widoczne. Cała instalacja wyglada˛ dla niego, jak jeden duzy˙ serwer. Typowymi przykładami zastosowania sa˛serwery WWW, poczty elektronicznej albo Media - Se- rver. Linux Virtual Server jest czesto˛ stosowany razem z architektura˛Failover dla Load - Balancer. Aby w łatwy sposób połaczy˛ c´ obydwie w/w technologie skorzystac´ mozna˙ z projektu UltraMon- key albo produktu Open Source ﬁrmy Red Hat o nazwie Piranha.

130http://www.complang.tuwien.ac.at/reisner/drbd/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 351

LVS stosowany jest w procesach produkcyjnych wielu ﬁrm. Za pomoca˛ LVS gwarantowana jest wysoka dostepno˛ s´c´ bardzo duzych˙ serwisów WWW: linux.com i sourceforge.net. Real Ne- tworks wykorzystuje LVS w klastrze Media - Servers.

3.17.6.4 Application Clustering

Application Clustering udostepniaj˛ a˛przodujace˛ serwery aplikacji wywodzace˛ sie˛ z rodziny Open Source: Tomcat jest niskopoziomowy serwerem aplikacyjnym, za pomoca˛ którego mozna˙ realizowac´ Java Servlets i Java Server Pages (JSP). Dzieki˛ swojemu Feature słuz˙acemu˛ do rozkładania obcia˛zenia,˙ obsługuje on Application Clustering. Bazy danych Open Source nie oferuja˛ rozwiaza˛ n´ wysokiej niezawodnosci.´ Najcze˛sciej´ jednym z głównych problemów jest brak mozliwo˙ sci´ wykonywania Online - Backup. Jednak dla systemów linuksowych ﬁrma Oracle udostepnia˛ swoja˛ opcje˛ RAC, co pozwala na poczynienie znacznych oszczedno˛ sci´ w obszarze osprzetu˛ i obsługi technicznej.

3.17.6.5 Compute Cluster

Gwoli rzetelnosci´ nalezy˙ w tym miejscu wspomniec´ jeszcze takze˙ o rozwiazaniach˛ HA w ramach High Performance Computing, nawet jesli´ ten obszar zastosowania interesuje administracje˛ publiczna˛ jedynie w ograniczonym stopniu. Beowolf był pierwszym projektem Compute - Cluster dla Linuksa i takze˙ dzis´ jest on nadal najcze˛sciej´ stosowany. Job Scheduling wewnatrz˛ klastra udostepniane˛ jest poprzez Portable Batch System (PBS) albo MAUI Scheduler. Rozdział 4

Ocena wydajnosci´ ekonomicznej

4.1 Wprowadzenie

Jak pokazuje dyskusja nt. dostepn˛ ych na rynku analiz dotyczac˛ ych TCO1, dokonanie oceny ekonomicznej zamierzen´ informatycznych zwiazan˛ ych z wykorzystywaniem produktów OSS i COLS2 jest zasadniczo bardzo trudne i ze wzgledu˛ na czesto˛ wielowymiarowe modele ekonomiczne staje sie˛ zadaniem niemalze˙ nie do rozwiazania.˛ W przypadku analizy obejmujacej˛ wiele zagadnien´ oraz zawierajacej˛ wiele wniosków, która bez watpienia˛ ma miejsce w przypadku porównywania kosztów platform Microsoft i OSS / COLS, do najistotniejszych zadan´ nalezy˙ zestawienie podobienstw´ badanych obiektów, jak tez˙ uwzglednienie˛ prawidłowego zakresu analizy. Wynik waskiej˛ oceny oddzielnych aspektów nie- koniecznie musi przenosic´ sie˛ na ogólny obraz, czego przykładem jest analiza IDC wykonana na zlecenie Microsoft pod tytułem „Windows 2000 vs. Linux for Enterprise Applications“. Po- niewaz˙ powyzsza˙ analiza zajmuje sie˛ zaledwie kosztami serwerów wykonujac˛ ych zadania infrastrukturalne, w przypadku których proporcjonalny udział kosztów licencji w porównaniu do ogólnych kosztów jest inny niz˙ na przykład w przypadku aplikacji klienckich, nie mozna˙ bezposrednio´ uzyskac´ informacji odnosnie´ opłacalnosci´ ekonomicznej w obszarze aplikacji lub desk- topów. Podczas wykonywania analizy konieczne jest takze˙ uwzglednienie˛ struktur uzytko˙ wników. Szczególnie wazna˙ dla oceny ekonomicznej migracji jest wielkos´c´ organizacji oraz rózne˙ wyjscio´ we scenariusze srodo´ wiska informatycznego. Czesto˛ mozna˙ zauwazy˙ c,´ ze˙ w małych urze-˛ dach (na przykład w sektorze komunalnym) infrastruktura zbudowana jest za pomoca˛ prostych

1TCO = Total Cost of Ownership (całkowite koszty posiadania) 2OSS = Open Source Software, COLS = Commercial Linux Software

352 ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 353 srodków´ i aby mogła działac´ nie jest wymagane intensywne kształcenie uzytko˙ wników. Z drugiej strony niezawodne działanie w przypadku infrastruktur centrów obliczeniowych, duzych˙ i / lub specjalizowanych urzedów˛ oraz centrów danych realizujac˛ ych Service Level Agreements wymaga od pracowników wyzsze˙ go poziomu wykształcenia, uregulowan´ organizacyjnych na wypadek awarii i sytuacji kryzysowych, jak równiez˙ czesto˛ innego osprzetu.˛ Biorac˛ pod uwage˛ niniejsze warunki brzegowe, dla dokonania oceny infrastruktury i kosztów konieczne jest spojrzenie wielowymiarowe. Podczas przygotowan´ do oceny kosztów informatyzacji obowiazuje˛ zasada, ze˙ istotnym elementem wzrostu opłacalnosci´ moze˙ byc´ przede wszystkim czynnik ludzki, organizacyjny i racjonalizacja w administracji publicznej. Jednak oprócz tego równiez˙ odpowiednio zaprojektowana strategia informatyczna moze˙ przyczynic´ sie˛ do pod- niesienia opłacalnosci´ ekonomicznej. Na ogólna˛ ocene˛ ekonomiczna˛ informatyzacji silnie wpływa:

◦ stopien´ w jakim korzystne cenowo, standardowe produkty realizuja˛ wymagane funkcje

◦ jakosć,´ mozliwo˙ sć´ rozwoju i mozliwo˙ sć´ wprowadzania zmian w stosowanych standardach, technologiach i produktach

◦ wydajne wprowadzenie systemu i administrowanie nim

◦ płynna integracja składników i systemów z ukierunkowanym pod katem˛ procesów łancu-´ chem powstawania kosztów

◦ dobra (wewnetrzna˛ albo zewnetrzna)˛ organizacja pomocy technicznej, jak równiez˙ duza˙ wiedza (Know - how)

◦ ekonomiczna długos´c´ zycia˙ produktów

◦ koszty i wydajnos´c´ procesów oraz

◦ konkurencja w dziedzinie produktów i usług.

Dopiero optymalne współdziałanie wszystkich powyzszych˙ czynników przez dłuzszy˙ czas, wa- runkuje i wpływa na łaczn˛ a˛ ocene˛ opłacalnosci,´ dlatego uproszczona ocena pojedynczych ko- szów z reguły nie oddaje całosci´ w prawidłowy sposób. Oprócz uzyskania informacji o kosztach i ich porównania, wazn˙ ym aspektem oceny ekonomicznej jest takze˙ ocena mozliwych˙ wartosci´ uzytko˙ wych. Szczególnie w tym obszarze wazn˙ a˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 354

role˛ dla dokonania całoscio´ wej oceny obejmujacej˛ zarówno sytuacje˛ wyjscio´ wa,˛ jak tez˙ sytuacje˛ w przyszłosci,´ odgrywaja˛ strategiczne przemyslenia´ oraz prognozowane zalety. Przykład: Wyzsze˙ koszty pojedynczego składnika moga˛ uzyskac´ lepsza˛ ocene˛ strategiczna˛ wskutek uzyskania niezalezno˙ sci´ od producenta oraz lepszej pozycji przetargowej w przypadku cen licencji na oprogramowanie, co z kolei moze˙ prowadzic´ do wyraznie´ korzystniejszego ogólnego wyniku. Z tych powodów zarówno przedstawiana przez nas metoda, jak i wynik, moga˛słuzy˙ c´ jedynie za pomoc podczas ustalania własnej oceny ekonomicznej oraz podczas formułowania własnej strategii informatyzacji.

4.2 Metodologia

Wprawdzie zasadniczo mozliwe˙ jest funkcjonalne i jakoscio´ we porównanie rózn˙ ych rzeczy, jednak wymaga to analizy kosztów i zysków, w której nalezy˙ przeciwstawic´ oczekiwany wzrost produktywnosci´ oczekiwanym, dodatkowym kosztom. Nie moglismy´ jednak umiesci´ c´ w niniejszym poradniku oceny produkcyjnosci´ w łancuchu´ powstawania kosztów informatyzacji, gdyz˙ nie istnieja˛ odpowiednie neutralne, długookresowe badania, zwłaszcza jesli´ chodzi o administracje˛ publiczna.˛ Prawdopodobnie w oparciu o dzisiej- sze doswiadczenia´ i ze szczególnym uwzglednieniem˛ tego, ze˙ zarówno w przypadku platformy Linux / Unix jak i Microsoft chodzi wyłacznie˛ o produkty tworzone od wielu lat, doprowadziłaby ona do uzyskania wywazone˙ go wyniku. Z tych powodów ocena ekonomiczna zamieszczona w poradniku migracyjnym koncentruje sie˛ na bezposredniej´ analizie kosztów i analizie korzysci.´

4.2.1 Analiza kosztów

Aby obliczyc´ pienie˛zne˙ skutki migracji posłuzyli˙ smy´ sie˛ metoda˛ obliczania wartosci´ kapitału. Jest to metoda dynamiczna i ocenia projekty inwestycyjne według ich wartosci´ kapitałowej, tzn. poprzez zblizone˙ do rzeczywistosci´ zebranie wszystkich strumieni ﬁnansowania zwiazan˛ ych z inwestycja˛ (wpływy i wydatki; wpływajace˛ na budzet˙ i nie wpływajace˛ na budzet),˙ skoncentro- wane we wspólnym punkcie odniesienia. Wpływy i wydatki majace˛ zwiazek˛ z migracja,˛ mozna˙ zaplanowac´ na pie˛c´ lat z góry. Dla przyszłych wartosci´ podalismy´ aktualna,˛ czasowa˛ wartos´c,´ dyskontujac˛ ja˛ w oparciu o stope˛ procentowa˛ ustalona˛ przez Ministerstwo Finansów. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 355

4.2.2 Analiza korzysci´

W przypadku, gdy podczas zastanawiania sie˛ nad decyzja˛ nie mozna˙ wzia˛c´ pod uwage˛ skutków ﬁnansowych, nalezy˙ skorzystac´ z analizy korzysci.´ Ocenia ona pojedynczo i niezaleznie˙ od siebie wazne˙ kryteria celu, by ostatecznie połaczy˛ c´ je w ocene˛ ogólna.˛ Sklasyﬁkowalismy´ tu według skali ocen tak zwane „miekkie“˛ czynniki. Zalecamy, aby ocene˛ wyników uzyskac´ w dwóch krokach:

1. Pierwszenstwo´ maja˛wyniki analizy kosztów. Wskaznik´ rentownosci,´ który wyraza˙ sie˛ dodatnia˛ wartosci´ a˛ kosztów, wynikac´ bedzie˛ z kosztów oraz oszczedno˛ sci´ zwiazan˛ ych z migracja˛ liczonych zgodnie z w/w metoda.˛

2. Z rezultatów analizy korzysci´ wynika wskaznik´ koniecznosci´ i strategia. W ramach projektu migracyjnego nalezy˙ je traktowac´ jako majace˛ mniejsze znaczenie. Ten drugi krok potrzebny jest przede wszystkim w przypadku, gdy z punktu widzenia kosztów ocena ekonomiczna jest niewystarczajaca˛ bad˛ z´ nie dostarcza jednoznacznej odpowiedzi na pytanie o rentownos´c.´ W oparciu o kryteria koniecznosci,´ wzglednie˛ strategii projekt moze˙ w kazdej˙ chwili uzyskac´ wysoki priorytet wykonania, niezaleznie˙ od kryte- riów kosztów.

4.2.3 IT-WiBe 21

W niemieckiej administracji oceny ekonomicznej nalezy˙ dokonac´ zgodnie z przepisami BHO paragraf 7 i według wydanych do nich przepisów wykonawczych, które od 1995 roku uwzgled-˛ niaja˛ przede wszystkim postepo˛ wanie w ramach ekonomiki przedsiebiorstwa.˛ W celu dostosowania w/w przepisów do specjalnych wymagan´ zwiazan˛ ych z informatyzacja,˛ Rzado˛ wy Urzad˛ Koordynacji i Doradztwa ds. Informatyzacji przy Ministerstwie Spraw Wewnetrzn˛ ych Republiki Federalnej Niemiec (KBSt) opracował juz˙ w 1992 roku instrukcje˛ postepo˛ wania pod tytułem „Zalecenia odnosnie´ przygotowywania oceny ekonomicznej w przypadku stosowania systemów informatycznych w administracji publicznej (IT - WiBe)“. W 1997 roku ukazała sie˛ ona w cał- kowicie przeredagowanym brzmieniu. IT - WiBe zawiera trzy główne kroki:

◦ ustalenie wielkosci´ wpływu (selekcja kryteriów)

◦ przenoszenie / ocena danych ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 356

◦ ustalenie wskazników´

Rysunek 4.1: Metodologia IT-WiBe

IT - WiBe jest procedura,˛ w której, inaczej niz˙ w przypadku metodyki TCO, ocena nie jest dokonywana tylko z punktu widzenia kosztów, lecz uwzgledniane˛ sa˛ takze˙ mozliwe˙ oszczedno-˛ sci.´

4.2.4 Koszty migracji

Wprawdzie IT - WiBe zasadniczo dobrze nadaja˛ sie˛ dla przeprowadzenia oceny ekonomicznej projektu, jednak odnoszenie ich do całego modelu jest czesto˛ zbyt skomplikowane i (z braku odpowiednich danych o budzecie)˙ niemozliwe,˙ do analizy róznic˙ y kosztów nalezy˙ zastosowac´ metode˛ uproszczona˛ – matryce˛ kosztów migracji. Ten sposób postepo˛ wania nie obejmuje kosztów i oszczedno˛ sci´ wynikajac˛ ych z wyselekcjo- nowanych kryteriów, lecz łaczy˛ je w kategorie: osprzet˛ , oprogramowanie i obsługa. W katego- riach tych nalezy˙ uja˛c´ piecioletnie˛ koszty zaopatrzenia3 i dalsze koszty, jak równiez˙ mozliwe˙

3Takie obszary kosztów, jak koszty wprowadzenia i dalsze koszty mieszcza˛ w sobie, podobnie jak w przypadku ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 357

oszczedno˛ sci.´ Ogólny widok pokazuje wszystkie lata i kategorie. Ponadto, podobnie jak w przypadku WiBe21, ocena rentownosci´ ustala wartos´c´ kapitału zdyskontowana˛ do punktu odniesienia. Dzieki˛ temu praktycy w urzedach˛ otrzymuja˛ do reki˛ instrument, który umozliwia˙ łatwe i szybkie przygotowanie wolumenu kosztów projektu uwzgledniaj˛ ace˛ go jego dalsze koszty oraz oszczedno˛ sci,´ jak równiez˙ przygotowanie oceny rentownosci´ 4.

4.2.5 TCO

Podstawowa˛ zasada˛ oceny TCO jest podział wszystkich kosztów danego systemu informatycznego na dwie grupy: koszty bezposrednie´ i koszty posrednie.´ Pod pojeciem˛ kosztów bezposrednich´ nalezy˙ rozumiec´ wszystkie koszty, które zapisywane sa˛ w budzecie.˙ Wspólna˛ cecha˛ kosztów bezposrednich´ jest to, ze˙ mozna˙ je zmierzyc´ w jednostkach pienie˛zn˙ ych. Druga˛ duz˙a˛ grupe˛ stanowia˛ koszty posrednie,´ nieujmowane w budzecie.˙ Zalicza sie˛ do nich czasy bezczyn- nosci,´ w których planowo albo poza planem nie mozna˙ uzywa˙ c´ ocenianych systemów. Czasy te mozna˙ zmierzyc,´ jednak nie bezposrednio´ w jednostkach pienie˛zn˙ ych. W tym celu konieczne jest niepodwazalne˙ przeliczenie wypłacanego „nieefektywnie“ uposazenia˙ albo utraconych obrotów. Ponadto do kosztów posrednich´ zalicza sie˛ „bezproduktywna“˛ prace˛ uzytko˙ wników konco´ wych, np. pomaganie samemu sobie, wzajemna pomoc, formalne i nieformalne uczenie sie,˛ zarzadzanie˛ i zabezpieczanie danych, granie, serfowanie i tak dalej. Zasadniczo metoda ta nadaje sie˛ takze˙ do ustalania kosztów migracji. Jednak poniewaz˙ oceniane sa˛tu wyłacznie˛ aspekty zwiazane˛ z kosztami i brak jest analizy rentownosci,´ w której swoje odbicie mogłyby znalez´c´ wszystkie omawiane aspekty kosztów, równiez˙ te z WiBe21 i z matrycy kosztów migracji, w ekonomicznej ocenie migracji ustalenie TCO nie znajduje zastosowania.

4.2.6 Porównywalnos´c´

W celu zagwarantowania porównywalnosci´ rózn˙ ych ocen, ocene˛ ekonomiczna˛ nalezy˙ przeprowadzic´ w dwóch scenariuszach:

◦ migracja pojedynczych lub wielu obiektów5 (migracja cze˛sciowa´ ) w przypadku jasno

oszczedno˛ sci,´ nastepuj˛ ace˛ elementy: infrastruktura serwerów, aplikacje bazodanowe, Messaging / Groupware, aplikacje WWW, Ofﬁce / Desktop i inne. 4Patrz rozdział „Wymiar pienie˛zn˙ y (operacyjny)“, rysunek „Matryca kosztów migracji z kategoriami kosztów i obszarami zastosowan“.´ 5Patrz rozdział 3.17.3 – rozdzielanie obiektów. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 358

dajac˛ ych sie˛ rozdzielic´ produktów albo grup produktów6

◦ całkowita migracja, tzn. migracja całego srodo´ wiska przetwarzania danych – serwerów, klientów, infrastruktury, aplikacji specjalistycznych

Pod pojeciem˛ migracji nalezy˙ zasadniczo rozumiec´ dwie rzeczy:

◦ migracje˛ zastepuj˛ ac˛ a,˛ jako migracje˛ do całkiem nowego srodo´ wiska opartego na Open Source, w którym korzysta sie˛ z Open Source Software (OSS) i / lub Commercial Linux Software (COLS). albo

◦ migracje˛ kontynuacyjna˛ – jako migracje˛ w ramach stosowanych juz˙ produktów do ich nowych wersji

Na potrzeby migracji obiektów migracyjnych nalezy˙ skorzystac´ ze zredukowanego katalogu kry- teriów przygotowanego specjalnie na wypadek migracji cze˛scio´ wej. Katalog ten zawiera kryteria wdrozenia˙ i pracy7. W przypadku całkowitej migracji nalezy˙ stosowac´ ogólne kryteria ocen IT - WiBe. Poniewaz˙ w wielu przypadkach migracja taka dotyczy takze˙ aplikacji specjalistycznych, z reguły oprócz czynnosci´ migracyjnych zwiazan˛ ych z produktami standardowymi, konieczne bed˛ a˛ takze˙ prace programistyczne dotyczace˛ specyficznych aplikacji. Zasady te stosuje sie˛ głównie, gdy mamy do czynienia z „wewnetrzn˛ a“˛ migracja.˛ Jesli´ migracja dotyczy tylko pojedynczych produktów albo grup produktów (takich jak, np. MS Office), wówczas nalezy˙ mówic´ o obiektach migracyjnych i stosowac´ specyficzny katalog kryteriów. Natomiast gdy chodzi o bardziej skomplikowany scenariusz (np. produkty MS dla komunikacji i biura, aplikacje specjalistyczne, etc), wtedy nalezy˙ stosowac´ pełny katalog kryteriów WiBe. Kolejny aspektem jest to, ze˙ porównawcza analiza wydajnosci´ ekonomicznej ma sens tylko w przypadku dajac˛ ych sie˛ porównac´ technicznie i funkcjonalnie alternatywnych rozwiaza˛ n.´ Za porównywalne w sensie poradnika migracyjnego mozna˙ uznac´ nastepuj˛ ace˛ obszary zastosowan´ technologii OSS i Microsoft:

◦ usługi infrastrukturalne

6Przykład: Aplikacje desktopowe jako obiekty migracji zawierajace˛ produkty takie jak: edytor tekstu, arkusz kalkulacyjny i przegladarka˛ WWW. 7Inaczej niz˙ w przypadku ogólnego katalogu kryteriów, usuniete˛ zostały tu kryteria rozwoju i zastapione˛ kryteriami wdrozenia.˙ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 359

– serwer plików – serwer wydruku – serwer logowania – sieci

◦ systemy Groupware i Messaging

◦ pakiety biurowe

◦ serwery baz danych i serwery WWW

Patrzac˛ z dzisiejszego punktu widzenia, bezpieczenstwo´ informatyczne jest jednoznacznie bardziej zagrozone˙ w przypadku systemów windowsowych i obszaru tego nie da sie˛ porównac.´ Nawet przy wiekszych˛ nakładach nie mozna˙ uzyskac´ porównywalnych zabezpieczen´ obydwu systemów, dlatego zrezygnowalismy´ z ekonomicznej oceny obszaru bezpieczenstwa.´

4.2.7 Instalacja od podstaw a migracja

Jesli´ ocena kosztów odbywa sie˛ pod katem˛ wprowadzenia nowych technologii, wówczas zasadniczo nalezy˙ odrózni˙ c´ instalacje˛ od podstaw od migracji procesów i systemów. Obowiazuje˛ przy tym „zasada lenia“ mówiaca˛ o tym, ze˙ wykonanie instalacji od podstaw jest prostsze i tansze,´ niz˙ migracja, w przypadku której trzeba zastapi˛ c´ rózne,˙ po cze˛sci´ historycznie obcia˛zone˙ architektury oraz przenies´c´ dane tak, aby nie doszło do istotnego zakłócenia pracy albo do utraty niegdys´ uzywan˙ ych danych. Poniewaz˙ proces migracji zalezy˙ zasadniczo od punktu wyjscia,´ sformułowanie ogólnie obowiazuj˛ acej,˛ obejmujacej˛ wszystkie koszty zasady, jest prawie niemozliwe.˙ Podczas, gdy migracja w niektórych przypadkach mozliwa˙ jest bez problemów i niemal bez nakładów, istnienie samodzielnie stworzonych aplikacji, które takze˙ trzeba zastapi˛ c,´ przeniesienie starych danych oraz specjalnej struktury uzytko˙ wników i praw dostepu˛ czy innych szczególnych własciwo´ sci´ prowadzi do powstania znacznych nakładów, które nalezy˙ ocenic´ indywidualnie, w zalezno˙ sci´ od urzedu˛ – takze˙ z uwzglednieniem˛ aspektów krytycznych.

4.2.8 Obliczanie pełnych kosztów

Z tych powodów ocena ekonomiczna koncentruje sie˛ na ustaleniu i analizie pełnych kosztów zwiazan˛ ych z głównymi rozwiazaniami˛ alternatywnymi opisanymi w poradniku migracyjnym: ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 360

◦ Open Source Software (OSS)

◦ Commercial Linux Software (COLS)

◦ Microsoft Software (MS)

Wyniki analizy daja˛ zasadniczy poglad˛ na długofalowy rozwój kosztów kazde˙ go z alternatywnych rozwiaza˛ n.´ W celu stworzenia podstawy koniecznej dla podjecia˛ decyzji o migracji, trzeba ostatecznie ogłosic´ koszty migracji. Korzystajac˛ z dobrze obsadzonego, w tzw. miedzyczasie,˛ sektora usług, bez problemu mozna˙ zdobyc´ szacunkowe wyniki bezposrednio´ w formie oferty migracyjnej udostepnianej˛ zarówno przez zewnetrzn˛ ych, jak i wewnetrzn˛ ych usługodawców oraz skonfrontowac´ je ze stwierdzonymi potencjałami. Stosowana przy tym metoda uwzglednia˛ niehomogeniczna˛ strukture˛ i rózn˙ a˛ wielkos´c´ urze-˛ dów poprzez rózne˙ ocenianie danych. Pojedyncze kroki prowadzace˛ do okreslenia´ pełnych kosz- tów poszczególnych alternatywnych rozwiaza˛ n´ przedstawilismy´ ponizej:˙

◦ zdeﬁniowanie obszarów zastosowan,´ które nalezy˙ przeanalizowac´

◦ ustalenie czynników kosztów w analizowanych obszarach zastosowan´

◦ ustalenie wartosci´ czynników kosztów dla:

– małych urzedów˛ – srednich´ urzedów˛ – duzych˙ urzedów˛

◦ ustalenie kosztów zwiazan˛ ych ze srodkami´ racjonalizacyjnymi (narzedzia˛ do zarzadzania˛ systemem)

◦ ustalenie struktury kosztów analizowanych rozwiaza˛ n´ alternatywnych

◦ ustalenie istnienia mozliwo˙ sci´ porównania jakoscio´ wego i technicznego

◦ przeprowadzenie analizy scenariusza w przypadku migracji do:

– OSS Open Source Software – COLS Commercial Linux Software ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 361

W wymiarze czysto pienie˛zn˙ ym bezposredni´ potencjał OSS / COLS wynika przede wszystkim z oszczedno˛ sci´ zwiazan˛ ych z kosztami licencji (dalsze mozliwo˙ sci´ wynikaja˛ z oceny strategicznej). Dlatego wynik oceny ekonomicznej polega na analizie długoterminowych potencjałów poprzez ustalanie kosztów licencji oprogramowania w porównaniu z pełnymi kosztami analizowanych infrastruktur.

4.3 Wymiar pienie˛zny˙ (operacyjny)

4.3.1 Obszary zastosowan´

W celu uzyskania wymownego wyniku, analize˛ nalezy˙ wykonac´ w ogólnym kontekscie´ składa- jac˛ ym sie˛ z wielu obszarów zastosowan.´ Całoscio´ wa ocena analizowanych kosztów obejmie przy tym nastepuj˛ ace˛ obszary:

◦ infrastruktura serwera

– zarzadzanie˛ plikami – drukowanie – logowanie – usługi sieciowe

◦ infrastruktura desktopu

– biuro – WWW

◦ Messaging / Groupware

◦ aplikacje bazodanowe i aplikacje WWW

Powyzsze˙ wyliczenie, mimo tego, ze˙ nie jest kompletne, tworzy wspólny mianownik dla wiek-˛ szosci´ infrastruktur wykorzystywanych w urzedach.˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 362

4.3.2 Kategorie kosztów

Tworzenie mozliwo˙ sci´ porównania kosztów oraz znormalizowanie wyników ich oceny wymaga stworzenia jednoznacznego modelu kosztów obowiazuj˛ ace˛ go dla wszystkich obszarów zastosowan.´ Metoda uzyta˙ w poradniku migracyjnym opiera sie˛ na tym, ze˙ nie jest dokonywana ocena produkcyjnosci´ (patrz rozdział 4.2) ani tez˙ szczególna ocena wpływu awaryjnosci´ na produkcyj- nos´c´ czy koszty Outsourcingu:

◦ osprzet˛

– porównanie wymagan´ odnosnie´ oprzyrzado˛ wania

◦ oprogramowanie

– koszty licencji na oprogramowanie – koszty konserwacji oprogramowania – dodatkowe koszty systemów katalogowych – dodatkowe koszty systemów zarzadzania˛ i bezpieczenstwa´

◦ obsługa

– administrowanie – wsparcie (Support) – opieka nad oprogramowaniem – szkolenie ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 363

Rysunek 4.2: Matryca kosztów migracji z kategoriami kosztów i obszarami zastosowan´

Wskazówka dotyczaca˛ oceny czasu przestoju: Zgodnie z doswiadczeniami´ szczególnie cen- trów obliczeniowych, mozna˙ zasadniczo przyja˛c,´ ze˙ systemy linuksowe w porównaniu z systemami MS Windows sa˛bardziej niezawodne i tym samym mozna˙ załozy˙ c´ pełniejsze wykorzystanie mocy produkcyjnych pod Linuksem8.

4.3.3 Własnosci´ uzytych˙ kategorii podmiotów publicznych

W kolejnych rozdziałach wypunktowane zostały własciwo´ sci´ urzedów˛ rózne˙ go typu. Z powodu duzych˙ róznic˙ w wyposazeniu˙ informatycznym, z którymi mamy tam do czynienia, oraz orgar- nizacji poszczególnych urzedów˛ , ponizszych˙ punktów nalezy˙ postrzegac´ jako zgrubna˛ pomoc wskazujac˛ a˛ wazne˙ kryteria dla własnej analizy.

4.3.3.1 Małe urzedy˛

◦ uzytko˙ wnicy: do 250

◦ osprzet:˛ z reguły mała i tania platforma Intel

8Potwierdza to takze˙ IDC w swoim opracowaniu przygotowanym na zlecenie Microsoft „Windows 2000 vs Linux dla zastosowan´ w przedsiebiorstwach“,˛ 2002 ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 364

◦ Backup i Recovery: tanie mechanizmy archiwizacji danych, wykorzystanie urzadze˛ n´ tasmo´ wych albo systemów RAID

◦ personel: z reguły jeden administrator posiadajac˛ y ogólna˛ specjalizacje,˛ jeden przedstawi- ciel

◦ organizacja obsługi informatycznej: jedna osoba bad˛ z´ grupa, niski stopien´ specjalizacji

◦ bezpieczenstwo´ i niezawodnos´c:´ z reguły wymagania niskie do srednich´

◦ zarzadzanie˛ systemem: pojedyncze narzedzia˛ (MS) albo skrypty (GNU / Linux)

4.3.3.2 Urzedy˛ sr´ edniej wielkosci´

◦ uzytko˙ wnicy: od 250 do 1.000

◦ osprzet:˛ małe i duze˙ systemy oparte na serwerach, platformy RISC oraz Intel, mozliwe˙ takze˙ architektury zdecentralizowane, jak i centralne

◦ Backup i Recovery: w uzyciu˙ dedykowane Backup - Server oraz serwery archiwizujace,˛ reguła˛ jest stosowanie technologii RAID

◦ personel: wielu administratorów pracujac˛ ych codziennie osiem godzin, specjalizacja, gotowos´c´ słuzby˙ awaryjnej

◦ organizacja obsługi informatycznej: dział informatyki

◦ bezpieczenstwo´ i niezawodnos´c:´ z reguły wymagania srednie´ do duzych˙

◦ zarzadzanie˛ systemem: programistyczne narzedzia˛ dedykowane (software distribution tools), Thin Clients, monitorowanie sieci i kontrola systemu

4.3.3.3 Duze˙ urzedy˛ / centra obliczeniowe9

◦ uzytko˙ wnicy: ponad 1.000 (do 10.000)

◦ osprzet:˛ tanie klastry ﬁrmy Intel, duze˙ rozwiazania˛ oparte na serwerach, dzielone architektury, centralne systemy Mainframe

9W konkretnym przypadku nalezy˙ wspólnie potraktowac´ srednie´ oraz duze˙ urzedy˛ i analizowac´ centra obliczeniowe tak, jak gdyby były szczególna˛ forma˛ urzedu.˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 365

◦ Backup i Recovery: centralny serwer Backup- / Disaster - Recovery z oprogramowaniem Roboter albo Jukebox

◦ personel: administratorzy pracujac˛ y osiem godzin dziennie, specjalizacja, gotowos´c´ słuzby˙ awaryjnej

◦ organizacja obsługi informatycznej: centrum obliczeniowe, w konkretnym przypadku lokalne zespoły administratorów

◦ bezpieczenstwo´ i niezawodnos´c:´ wymagania wysokie do bardzo wysokich, stosowanie obszernych rozwiaza˛ n´ SAN

◦ zarzadzenie˛ systemem: dedykowane narzedzia˛ programistyczne (software distribution tools), Thin Clients, monitorowanie sieci i kontrola systemu.

4.4 Wymiar strategiczny

Oprócz bezposredniej,´ pienie˛znej˙ analizy całkowitych kosztów wdrozenia˙ poszczególnych rozwiaza˛ n´ alternatywnych, istnieje takze˙ koniecznos´c´ wykonania i uwzglednienia˛ oceny strategicznej (w terminologi WiBe – wymiar strategiczny). Koniecznos´c´ przeprowadzenia oceny strategicznej wynika z wagi bezposrednich´ skutków czynnika strategicznego jakim jest „uzaleznienie˙ od producenta“. Ocena taka ma swoje znaczenie zarówno z punktu widzenia makro, jak i mikroekonomii.

4.4.1 Spojrzenie makroekonomiczne

W ocenie makroekonomicznej główna˛ role˛ odgrywaja˛ aspekty zwiazane˛ z konkurencyjnosci´ a:˛

◦ lepsza jakos´c´ produktu

◦ nizsze˙ ceny produktu

◦ wyzszy˙ stopien´ innowacyjnosci.´

Pomimo tego, ze˙ z reguły wszyscy producenci oprogramowania przypisuja˛ sobie zarówno wyz-˙ sza˛ jakos´c´ produktu, jak tez˙ innowacyjnos´c´ technologiczna,˛ w rzeczywistosci´ rzadko mozna˙ tak generalizowac.´ Zwłaszcza rozwój World Wide Web pokazuje, ze˙ na przykład Microsoft przez długi czas „przesypiał“ te˛ najwazniejsz˙ a˛ sfere˛ innowacyjnosci´ ostatnich dekad. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 366

Ocena makroekonomiczna ma wprawdzie zasadniczy charakter, jednak odbiorcy poradnika migracyjnego nie moga˛na nia˛bezposrednio´ wpływac´ i dlatego nie została tu dogłebnie˛ przeanalizowana. Monopolistyczna˛ pozycja˛ Microsoftu w dziedzinie systemów operacyjnych zajmuje sie˛ obecnie Komisja Europejska. Na wyniki jej prac i ewentualne wnioski trzeba jeszcze poczekac.´

4.4.2 Spojrzenie mikroekonomiczne

Istotna˛ rzecza˛ dla oceny mikroekonomicznej jest własne uzaleznienie˙ od dostawcy produktów i usług. Mimo, ze˙ tego typu uzaleznienie˙ w duzym˙ stopniu powstaje i uwidacznia sie˛ wskutek istnienia monopoli lub quasi monopoli, zbyt silna zalezno˙ s´c´ od dostawców moze˙ równiez˙ wystapi˛ c´ w warunkach istniejacej˛ konkurencji i prowadzic´ w pewnych okolicznosciach´ do zaistnienia nie- korzystnych warunków ekonomicznych. Z jednej strony polegac´ one moga˛ na wyzszych˙ cenach produktów, zas´ z drugiej na krótszej długosci´ zycia˙ produktów generujacej˛ dodatkowe koszty wdroze˙ n´ w przypadku migracji kontynuacyjnej. W ekstremalnym przypadku uzaleznienie˙ prowadzic´ moze˙ do sytuacji, w których nie ma juz˙ alternatywnych mozliwo˙ sci´ postepo˛ wania mieszczac˛ ych sie˛ w akceptowalnej cenie. W przeciwienstwie´ do powyzsze˙ go, sytuacja oparta na strategiczej równowadze prowadzi do lepszej pozycji przetargowej, która w przypadku pojawienia sie˛ problemów, pozwala sie˛gna˛c´ po rozwia-˛ zania alternatywne.

4.5 Wyniki oceny wydajnosci´ ekonomicznej

Wiekszo˛ s´c´ badan´ poswi´ econ˛ ych niniejszemu zagadnieniu korzysta w swojej metodologii ze stopy kosztów całkowitych i dowodzi słusznosci´ twierdzenia, ze˙ istotna cze˛s´c´ kosztów przypada nie na licencje na oprogramowanie, lecz lezy˙ po stronie wdrozenia˙ i kosztów osobowych zwiazan˛ ych z przygotowaniem obsługi. Jednak wskutek rózn˙ ych załoze˙ n´ – w szczególnosci´ dotyczac˛ ych sposobów administrowania systemami – wyniki w/w badan´ prowadza˛ do sprzecznych wniosków dotyczac˛ ych zalet ekonomicznych niesionych przez rózne˙ rozwiazania˛ alternatywne. Badania faworyzujace˛ platformy Microsoftu przedstawiajace˛ niskie koszty TCO opieraja˛ sie˛ w wiekszo˛ sci´ (jednak nie wyłacznie)˛ na załozeniu˙ mniejszych kosztów przygotowania personelu, które uzyskiwane sa˛ w istocie wskutek nizszych˙ wymagan´ odnosnie´ wykształcenia i tym samym nizszych˙ podstawowych wynagrodzen´ administratorów10. Inna˛ zalete,˛ która wynika juz˙

10Opracowanie ICD: „Windows 2000 vs Linux dla zastosowan´ w przedsiebiorstwach“,˛ 2002 ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 367

jednak z w sumie bardzo dyskusyjnych załoze˙ n,´ upatruje sie˛ w obszarze bezpieczenstwa´ informatycznego, którego implementacja dla platform opartych na produktach Microsoftu wymaga mniejszych nakładów pracy. Do odmiennych całoscio´ wych wniosków prowadza˛badania krytyczne wzgledem˛ produktów Microsoftu. Wprawdzie takze˙ tutaj stwierdza sie˛ róznic˙ e˛ w wynagrodzeniu podstawowym, jest ona jednak z nawiazk˛ a˛ wyrównywana lepsza˛ jakosci´ a˛ administrowania, zwłaszcza w przypadku pracy centrów obliczeniowych. Dlatego badania przedstawione w ramach poradnika migracyjnego wskazuja˛na trzy istotne i rozstrzygajace˛ dla naszych rozwaza˙ n´ czynniki, niezbedne˛ z punktu widzenia oceny wprowadzania Linux / OSS i oceny kosztów TCO tego przedsie˛wziecia.˛

1. Udział kosztów licencyjnych w sumie kosztów

2. Stopien´ specjalizacji rozwazan˙ ych infrastruktur oraz systemów informatycznych

3. Stopien´ automatyzacji rozwazan˙ ych infrastruktur oraz systemów informatycznych

Udział kosztów licencji na oprogramowanie w sumie kosztów systemów oraz procedur informatycznych wynosi pomiedzy˛ 20% a 50%. W przedziale tym miesci´ sie˛ przede wszystkim posredni´ i bezposredni´ potencjał alternatywnych rozwiaza˛ n´ OSS oraz COLS, mierzony w wymiarze czysto pienie˛zn˙ ym, z promesa˛ porównywalnosci´ uzyskiwanych wyników pracy. Oprócz wypowiedzi dotyczacej˛ udziału kosztów licencji na oprogramowanie w sumie kosz- tów ponoszonych na informatyzacje,˛ w procesie ustalania rzeczywistej przestrzeni działania osób dcecydujac˛ ych o informatyzacji pomaga ocena dwóch innych czynników. Pierwszy z nich to indeks kosztów, na które mozna˙ bezposrednio´ wpływac´ a drugi analiza kosztów oddziałujac˛ ych na budzet.˙ Do kosztów, na które mozna˙ bezposrednio´ wpływac´ zalicza sie:˛

1. Koszty uzyskania oprogramowania: głównie poprzez przejscie´ na tansze´ produkty albo uzyskanie nizszych˙ cen w procesie negocjacji

2. Koszty administrowania: głównie poprzez konsolidacje˛ (redukcje˛ ilosci´ produków) oprogramowania albo rezygnacje˛ z uktualizacji

3. Koszty uzyskania osprzetu:˛ poprzez przejscie´ na tansze´ platformy sprzeto˛ we ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 368

4. Koszty administrowania osprzetem:˛ poprzez konsolidacje˛ (redukcje˛ ilosci´ produktów) osprzetu˛ albo wydłuzenie˙ cyklów zycia.˙

W przeciwienstwie´ do oprogramowania i osprzetu,˛ najwiekszy˛ blok wydatków na informatyzacje,˛ tj. koszty osobowe, nie sa˛ liczone do kosztów, na które mozna˙ bezposrednio´ wpływac.´ Wy- nika to przede wszystkim z faktu, ze˙ wprowadzenie i uzytko˙ wanie infrastruktur oraz systemów informatycznych zwiazane˛ jest z podstawowym obcia˛zeniem˙ wynikajac˛ ym w mniejszym stopniu z poszczególnych modeli licencjonowania, lecz raczej z takich czynników jak: intensywnosć´ administrowania, niezawodnosć´ i bezpieczenstwo´ uzytko˙ wanych platform. Redukcja istniejac˛ ych zasobów ludzkich albo ich przeorganizowanie (Outsourcing) i konsolidacja, z reguły nie stanowi szybkiej, alternatywnej drogi postepo˛ wania. W ocenie kosztów informatyzacji, na które mozna˙ bezposrednio´ wpływac´ wyraznie´ widac,´ ze˙ koszty licencji (uzyskania oprogramowania, administrowania, uaktualnien)´ stanowia˛ najwiesz˛ a˛ cze˛sć´ i tym samym pozostawiaja˛ najwieksze˛ pole do działania.

4.6 Zalecenia migracyjne oparte na ocenie wydajnosci´ ekonomicznej

Zalecenia migracyjne dotycza˛ nastepuj˛ ac˛ ych scenariuszy:

◦ migracja pełna (dla duzych,˙ srednich´ i małych urzedów)˛

◦ migracja kontynuacyjna (dla duzych˙ srednich´ i małych urzedów)˛

◦ migracja cze˛scio´ wa (migracja punktowa i po stronie serwera)

W przedstawionych przykładach11 w duzej˙ cze˛sci´ pominieto˛ apsekt osprzetu.˛ Jesli´ posiadany osprzet˛ jest nowy (nie starszy niz˙ 2 - 3 lata), wówczas migracje˛ mozna˙ przeprowadzic´ bez koniecznosci´ jego wymiany. Natomiast w przypadku, gdy osprzet˛ jest starszy, wymagana jest dodatkowa inwestycja bez wzgledu˛ na kierunek migracji (Open Source czy Microsoft)12. W ocenie pienie˛znej˙ podstawe˛ stanowi typowy dla urzedów˛ , piecioletni˛ okres uzytko˙ wania nabytych dóbr. Ponowne inwestowanie spodziewane jest dopiero po tym czasie. Dotyczy to za- równo migracji w kierunku GNU / Linuksa, jak tez˙ migracji kontynuacyjnej (w obszarze pro- duktów Microsoftu). W ciagu˛ czterech lat od zakupu nie sa˛ liczone dalsze koszty.

11Patrz rozdział 4.8.6.2 – 4.8.6.7. 12Dlatego, by zbytnio nie komplikowac´ obliczen,´ przy ocenianiu kosztów migracji zrezygnowano z oceny czynnika oprzyrzado˛ wania. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 369

Tablica 4.2: Porównanie kosztów przypadajac˛ ych na uzytko˙ wników w przypadku migracji pełnej i kontynuacyjnej

U podstaw obliczen´ lez˙a˛ załozenia˙ cenowe specyﬁczne dla urzedów˛ . W istotnej cze˛sci´ w obliczeniach tych uwzgledniono˛ jednorazowe ceny zakupu. Równolegle do tego dla ocenianych produktów liczono koszty dzierza˙ wienia Windows oraz MS Ofﬁce. Porównanie kosztów pełnej i kontynuacyjnej migracji przypadajac˛ ych na uzytko˙ wników wskazuje na jednoznaczne zalety migracji do srodo´ wiska OSS13.

TYP URZE˛DU MIGRACJA PEŁNA MIGRACJA KONTYNUACYJNA mały 50014 ¤ 85015 EUR sredni´ 34016 ¤ 73017 ¤ duzy˙ 18018 ¤ 60019 ¤

Koszty migracji kontynuacyjnej sa˛ około dwa razy wieksze˛ od kosztów pełnej migracji. Mniejsze koszty pełnej migracji wynikaja˛ przede wszystkim z zaoszczedzon˛ ych wydatków na oprogramowanie (pomiedzy˛ 92% a 95% w kazdym˙ z w/w urzedów˛ , tj. od małych do duzych).˙ Natomiast porównanie kosztów osobowych pokazuje, ze˙ ta forma migracji w ocenianych, ma- łych / srednich´ / duzych˙ urzedach˛ jest korzystniejsza odpowiednio o około 14,0% / 6,5% i 2,2 %. Tendencja ta rozwija sie˛ w przypadku obydwu form migracji niemal jednakowo i wykazuje wzrost kosztów wraz ze zmniejszajac˛ a˛ sie˛ wielkosci´ a˛ organizacji!

13Migracja do srodo´ wiska OSS okreslona´ została jako „Migracja pełna“. 14Patrz rozdział „Pełna migracja“, podrozdział „Mała instalacja“ 15Patrz rozdział „Migracja kontynuacyjna“, podrozdział „Mała instalacja“ 16Patrz rozdział „Pełna migracja“, podrozdział „Srednia´ instalacja“ 17Patrz rozdział „Migracja kontynuacyjna“, podrozdział „Srednia´ instalacja“ 18Patrz rozdział „Pełna migracja“, podrozdział „Duza˙ instalacja“ 19Patrz rozdział „Migracja kontynuacyjna“, podrozdział „Duza˙ instalacja“ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 370

Rysunek 4.3: Rozwój kosztów migracji

4.6.1 Migracja pełna

Przykładowe obliczenia zasadniczo pokazuja˛ dominujac˛ y udział kosztów osobowych, który wynosi mniej wiecej˛ 90% (około 97% - 93%). Dla rózne˙ go typu urzedów˛ otrzymujemy nastepuj˛ ac˛ y procentowy rozkład kosztów migracji.

TYP URZE˛DU OPROGRAMOWANIE PERSONEL mały do 7% do 93% sredni´ do 10% do 90% duzy˙ do 13% do 87%

Tablica 4.4: Rozkład kosztów w przypadku „migracji pełnej“ w urzedach˛

Oszczedno˛ sci´ obliczone w niniejszym modelu sa˛ nakładami ponoszonymi kazdorazo˙ wo w przypadku migracji do srodo´ wiska Windows 2000.

TYP URZE˛DU PODSTAWA - ZAKUP (CENA JEDNORAZOWA) ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 371

mały 500 ¤ sredni´ 340 ¤ duzy˙ 180 ¤

Tablica 4.6: Całkowite koszty migracji przypadajace˛ na uzytko˙ wnika w przypadku migracji peł- nej

Pełna migracja w przypadku duzych˙ urzedów˛ oznacza ponadprzecietn˛ y efekt oszczedno-˛ scio´ wy. Oszczedno˛ sci´ w przypadku migracji z Windows NT do Linuksa, w przeciwienstwie´ do migracji do Windows 2000, przekraczaja˛ trzykrotnos´c´ nakładów. Koszty osobowe wynikajace˛ z tej zmiany mieszcza˛sie˛ w porównwalnych rzedach˛ wielkosci,´ zatem duza˙ cze˛s´c´ oszczedno˛ sci´ pochodzi z braku koniecznosci´ poniesienia kosztów licencyjnych. Przedstawione efekty oszczedno˛ scio´ we kaz˙a˛ zastanowic´ sie˛ nad migracja˛ do Open Source. W obszarze srednich´ i małych urzedów˛ mamy do czynienia zasadniczo ze scenariuszem zblizon˙ ym do tego z duzych˙ urzedów˛ . Takze˙ w tym przypadku okazuje sie,˛ ze˙ migracja do Open Source jest ze wszech miar godna polecenia.

4.6.2 Migracja kontynuacyjna

W przypadku tego rodzaju migracji nie mozna˙ zidentyﬁkowac´ i porównac´ oszczedno˛ sci.´ Dlatego ponizej˙ zamieszczamy jedna˛ prezentacje˛ zakresu kosztów zwiazan˛ ych z tym scenariuszem.

TYP URZE˛DU PODSTAWA - ZAKUP PODSTAWA - ZAKUP (CENA JEDNORAZOWA) DZIERZ˙ AWA mały 850 ¤ 1.860 ¤ sredni´ 730 ¤ 1.740 ¤ duzy˙ 600 ¤ 1.600 ¤

20Całkowite koszty migracji zawieraja˛ wszystkie nakłady zwiazane˛ z zamienianymi systemami w ocenianym, piecioletnim˛ przedziale czasu. Wszystkie dane sa˛ danymi przyblizon˙ ymi. 21Całkowite koszty migracji zawieraja˛wszystkie nakłady zwiazane˛ z zamiana˛systemów w ocenianym, pieciolet-˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 372

Tablica 4.8: Całkowite koszty migracji przypadajace˛ na uzytko˙ wnika w przypadku migracji kontynuacyjnej

Wraz ze wzrostem ilosci´ uzytko˙ wników migracja staje sie˛ bardziej opłacalna. W tym przypadku, zgodnie z przedstawionym modelem, przejscie´ z cen zakupu na ceny dzierza˙ wy22 nie opłaca sie.˛

4.6.3 Migracja cze˛scio´ wa

4.6.3.1 Migracja punktowa

Niniejsza forma migracji dotyczy trwałego zastapienia˛ wybranego składnika systemu wewnatrz˛ istniejacej˛ struktury informatycznej. Przykładem migracji cze˛scio´ wej moze˙ byc´ przejscie´ z Exchange 5.5 na Samsung Contact. Migacje˛ te˛ mozna˙ zalecic´ urzedom˛ kazde˙ go typu, z zastrzezeniem,˙ ze˙ w poszczególnym przypadku mozliwe˙ jest zastapienie˛ wymaganych funkcji, poniewaz˙ w przeciwienstwie´ do migracji z wykorzystaniem produktów Microsoftu przedstawia ona wymierne korzysci´ ﬁnansowe23.

TYP URZE˛DU PODSTAWA - ZAKUP (CENA JEDNORAZOWA) mały 99 ¤ sredni´ 153 ¤ duzy˙ 39 ¤

Tablica 4.10: Całkowite koszty migracji przypadajace˛ na uzytko˙ wnika w przypadku migracji punktowej

Z tablicy cen oprogramowania ﬁrmy Samsung wynikaja˛ zaprezentowane powyzej˙ rozpieto-˛ sci´ kosztów migracji przypadajace˛ na uzytko˙ wnika.

nim przedziale czasu. Wszystkie dane sa˛ danymi przyblizon˙ ymi. 22Ceny dzierza˙ wy produktów MS Windows i MS Ofﬁce były znane, stad˛ tez˙ uwaga „W tym przypadku“. 23Kosztom migracji do Samsung Contact przeciwstawiane sa,˛ jako oszczedno˛ sci,´ koszty migracji do Exchange2000. Róznic˙ e˛ stanowia˛ w kazdym˙ przypadku dodatnie wartosci´ kapitału, które wskazuja˛na odpowiednie korzysci´ ﬁnansowe. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 373

TYP URZE˛DU OPROGRAMOWANIE PERSONEL mały do 35% do 65% sredni´ do 21% do 79% duzy˙ do 56% do 44%

Tablica 4.12: Rozłozenie˙ kosztów migracji

Podział kosztów na oprogramowanie i personel waha sie˛ w granicach 50% na 50%. W zalezno˙ sci´ od stopnia zaangazo˙ wania obsługi w procesy migracyjne udział ten moze˙ sie˛ zmieniac.´ Nakład przyjety˛ tu za podstawe˛ jest równy nakładowi koniecznemu dla przeprowadzenia migracji do Exchange 2000. Poniewaz˙ jednak z doswiadczenia´ wynika, ze˙ moze˙ on byc´ nizszy˙ , stad˛ realistyczny udział kosztów osobowych migracji wyniesie raczej mniej niz˙ 50%.

4.6.3.2 Migracja cze˛sciowa´ po stronie serwera

Niniejsza migracja cze˛scio´ wa przeprowadzana po stronie serwera jest cze˛sci´ a˛ migracji pełnej. Jako alternatywa dla pełnej migracji ta forma zastepo˛ wania systemu zapewnia bardzo wysoka˛ wydajnos´c,´ jesli´ chodzi o kryterium pilnosci,´ jakosci´ i strategii, gdyz˙ istotna cze˛s´c´ projektu migracyjnego ma miejsce na serwerze przy uwzglednieniu˛ tychze˙ kryteriów. Koszty kształtuja˛ sie˛ na poziomie około 120 ¤, tj. ponizej˙ kosztów ustalonych w przypadku migracji pełnej (patrz ponizsza˙ tabela „Porównanie kosztów migracji pełnej i migracji po stronie serwera“). Niniejsza alternatywna migracja jest korzystna nie tylko z powodu mniejszych kosztów, lecz takze˙ dzieki˛ temu, ze˙ zapewnia ona łagodne, ledwo zauwazalne˙ i nieodczuwalne przez uzytko˙ w- ników przejscie´ do swiata´ Otwartego Oprogramowania.

TYP URZE˛DU PODSTAWA - ZAKUP (CENA JEDNORAZOWA) mały 370 ¤ sredni´ 220 ¤ duzy˙ 65 ¤ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 374

2425

Tablica 4.14: Całkowite koszty migracji przypadajace˛ na uzytko˙ wnika w przypadku migracji cze˛scio´ wej po stronie serwera.

Koszty migracji dotycza˛tu wprawdzie tylko serwerów, jednak odniesiono je do innych kosz- tów i przeliczono na ilos´c´ uzytko˙ wników pracujac˛ ych w ocenianych typach urzedów˛ .

TYP URZE˛DU MIGRACJA PEŁNA MIGRACJA CZE˛S´ CIOWA UDZIAŁ KLIENTÓW PO STRONIE SERWERA W MIGRACJI PEŁNEJ mały 500 ¤ 370 ¤ 129 ¤ sredni´ 340 ¤ 220 ¤ 120 ¤ duzy˙ 180 ¤ 65 ¤ 116 ¤

Tablica 4.16: Całkowite koszty migracji przypadajace˛ na uzytko˙ wnika w przypadku migracji cze˛scio´ wej po stronie serwera.

Rysunek 4.4: Koszty migracji przypadajace˛ na uzytko˙ wnika

Rozwój kosztów w przypadku szerokiej migracji potwiedza wczesniej´ ustalony trend, czyli zmniejszanie sie˛ ich wraz ze wzrostem wielkosci´ organizacji. W porównaniu z migracja˛ pełna,˛ udział kosztów przypadajac˛ ych na przestawienie stacji klienckich jest wzglednie˛ stały.

4.7 Wnioski

Porównanie ekonomicznych aspektów rózne˙ go rodzaju migracji przemawia jednoznacznie na korzys´c´ migracji cze˛scio´ wej po stronie serwera. Jesli´ urzad˛ zdecyduje sie˛ na zasadnicze przejscie´ z wykorzystywanego systemu na Open Source, wówczas z ekonomicznych powodów zaleca

24Całkowite koszty migracji zawieraja˛ wszystkie nakłady zwiazane˛ z zamienianymi systemami w ocenianym, piecioletnim˛ przedziale czasu. Wszystkie dane sa˛ danymi przyblizon˙ ymi. 25Wszystkie dane sa˛ danymi przyblizon˙ ymi. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 375

sie˛ obranie tej drogi postepo˛ wania. Szeroka migracja po stronie serwera (jako wariant, wzgled-˛ nie wstep˛ do migracji pełnej) poswi´ eca˛ szczególna˛ uwage˛ specyﬁcznym dla urzedów˛ interesom realizowanym po stronie klienta i tym samym przyczynia sie˛ do wydajniejszej i trwałej zmiany platformy informatycznej. Jesli´ urzad˛ zdecyduje sie˛ na pozostanie przy systemach opartych o produkty Microsoftu, wówczas sposób migracji wytyczac´ bedzie˛ migracja kontynuacyjna. Obydwa sposoby postepo˛ wania migracyjnego, tj. migracja pełna, jak tez˙ punktowa, sa˛z ekonomicznych punktów widzenia optymalne. W zalezno˙ sci´ od specjalnych wymagan´ urzedów˛ i / lub podejmowanych tam decyzji, w/w sposoby moga˛ sie˛ okazac´ jak najbardziej własciw´ a˛ droga˛ postepo˛ wania26.

4.8 Nakłady według róznych˙ scenariuszy migracji

4.8.1 Ogólne załozenia˙ dotyczace˛ nakładów zwiazanych˛ z migracja˛

Całkowite koszty ocenianych tu migracji składaja˛ sie˛ zasadniczo z:

◦ koszów osprzetu˛

◦ koszów oprogramowania

◦ kosztów osobowych

W niniejszym rozdziale pokazemy˙ mozliwe˙ zakresy kosztów osobowych i objasnimy´ ich cze-˛ sci´ składowe. Aspekt osprzetu˛ został pominiety˛ 27 a koszty oprogramowania uwzgledniono˛ w poszczególnych przykładach28. Ocena nakładów zamieszczona w niniejszym poradniku moze˙ byc´ tylko zgrubnym szacun- kiem, poniewaz˙ nie jest (nie moze˙ byc)´ dokładnie znany ani punkt wyjscia,´ ani oczekiwany scenariusz migracji. Z tego powodu przykładowo ocenione zostały trzy rózne˙ scenariusze. Przypi- sano je odpowiednio do przedstawionych wczesniej´ trzech przykładowych urzadów˛ 29. W dalszej cze˛sci´ zgrubnie nakreslono´ kazde˙ z tych trzech srodo´ wisk. Dla wszystkich srodo´ wisk przyjeto˛ nastepuj˛ ace˛ załozenia:˙

26W niektórych przypadkach urzad˛ zmuszony jest, np. wskutek korzystania z niedajac˛ ych sie˛ przeportowac´ specjalistycznych aplikacji, do dalszego korzystania z systemów Microsoftu. W innych przypadkach warunki po stronie serwerów i klientów moga˛ wymagac´ migracji w jej pełnej formie. 27Patrz rozdział „Zalecenia migracyjne . . . „ 28Patrz rozdział „Zalecenia odnosnie´ oceny produków / grup produktów“ 29Urzedy˛ małe, srednie´ i duze˙ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 376

◦ migracja po stronie serwerów zachodzi wraz z wymiana˛ osprzetu˛ (nowe serwery)

◦ stacje robocze sa˛urzadzeniami˛ pracujac˛ ymi pod Windows NT 4 (tym samym nie jest brana pod uwage˛ koncepcja grupowych wytycznych dla systemów desktopowych)

◦ dotychczasowe srodo´ wisko jest w „dobrym“ stanie, wzglednie˛ nie chce sie˛ wprowadzac´ Windows 2000 jako pierwszoplanowego systemu w celu odciecia˛ sie˛ od starych obcia˛ze˙ n;´ wobec tego zakłada sie˛ przede wszystkim, ze˙ nie jest odrzucana tak zwana „migracja - inplace“ (aktualizacja istniejacej˛ domeny NT).

◦ istnieje uniwersalny techniczny system zarzadzania,˛ którego narzedzia˛ nadaja˛sie˛ takze˙ dla Windows 2000

◦ istnieje udokumentowany plan pracy, który mozna˙ rozwijac´

◦ całosci´ a˛ srodo´ wisk suwerennie opiekuje sie˛ i odpowiada za nie organizacja, która przewaznie˙ działa centralnie

◦ straty zwiazane˛ z przerwami w pracy wynikajac˛ ymi z wewnetrzn˛ ych, politycznych nie- zgodnosci´ i niedoborów budzeto˙ wych sa˛ minimalne.

Ponadto nalezy˙ wzia˛c´ pod uwage˛ nastepuj˛ ace˛ rozgraniczenia:

◦ migracja stacji roboczych do Windows 2000 / XP nie jest oceniana

◦ migracja z Windows Terminal Services nie jest oceniana

◦ nie nalezy˙ brac´ pod uwage˛ migracji z DFS lub wprowadzenia DFS

◦ nie jest brana pod uwage˛ migracja serwerów aplikacji takich jak: MS Exchange, MS SQL, MS SNA Server, MS Proxy albo aplikacji innych producenów, jak równiez˙ klastry serwe- rów NT (Enterprise Edition) z ewentualnymi zewnetrzn˛ ymi jednostkami pamieci˛ (podsystemy twardych dysków bad˛ z´ SAN)

Oceniany model obejmuje szes´c´ etapów i mozna˙ okresli´ c´ go w kilku punktach:

◦ Warsztat (Kick Off, dopuszczenie konkretnych specjalistycznych działów i gałezi˛ IT, identyﬁkacja wszystkich wazn˙ ych zagadnien,´ okreslenie´ priorytetów, identyﬁkacja obsza- rów decyzyjnych, ustalenie sposób postepo˛ wania i planu projektu, szczegółowe okreslenie´ nakładów, okreslenie´ projektów cze˛scio´ wych i przypisanie ich do grup roboczych) ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 377

◦ Ustalenie stanu faktycznego (srodo´ wisko oplikacji, zalezno˙ sci´ komunikacyjne, infrastruktura sieci, usługi centralne, sposób uzytko˙ wania, przyszłe wymagania)

◦ Ogólna koncepcja (załozonie˙ zeszytu z rozpisanymi obowiazkami,˛ uszczegółowienie planu projektu i zdeﬁniowanie pakietów roboczych , mozliwo˙ sci´ technicznych, zbudowanie sro-´ dowiska integrujace˛ go i testowego, rozrysowanie pozostałego srodo´ wiska produkcyjnego, zintegrowanie aplikacji, wybór osprzetu˛ i jego sposobu jego zastapienia)˛

◦ Dokładna koncepcja (szczegółowe ustalenie zakresu funkcji, integracja z pozostałym sro-´ dowiskiem informatycznym, stworzenie procedur instalacji i przydział oprogramowania, zintegrowanie prac, zaplanowanie Rollout, zaplanowanie pilota, przeszkolenie personelu pracujace˛ go z danymi)

◦ Pilot (Feature Stop, zorganizowanie reprezentatywnej grupy uzytko˙ wników, przeprowadzenie ostatnich testów, uruchomienie UHD (User Help Desk), wykonanie pierwszej sizing - control, porównanie wyników z dokładna˛ koncepcja)˛

◦ Rollout (uruchomienie procesu instalacji, rozmnozenie˙ serwerów, przekazanie informacji uzytko˙ wnikom i ich przeszkolenie, sprawowanie opieki przez zespół wdrazaj˙ ac˛ y projekt, przekazanie systemu do normalnego uzytko˙ wania).

Ponadto nalezy˙ przewidziec´ zarzadzanie˛ projektem.

4.8.2 Nakłady na migracje˛ z Windows NT do Windows 2000

Ponizej˙ przedstawione zostana˛nakłady na migracje,˛ które trzeba ponies´c´ podczas przechodzenia, w nastepuj˛ ac˛ ych obszarach, z Windows NT 4 do Windows 2000:

◦ usługi logowania

◦ usługi sieciowe

◦ zarzadzanie˛ plikami

◦ drukowanie.

Migracje˛ do Windows 200030 razem z Active Directory mozna˙ podzielic´ na rózne˙ etapy zawierajace˛ pakiety działan.´ Ponizsza˙ tabela w punktach przedstawia oceniane scenariusze.

30Migracja z Windows NT do Windows 2000 nazywana jest dalej „migracja˛ kontynuacyjna“.˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 378

KATEGORIA ILOS´ C´ UZ˙ YTKOWNIKÓW PUNKT WYJS´ CIA SCENARIUSZ PROWADZA˛CY

DO CELU

domena NT z jedna domena dwoma kontrolerami Windows 2000 domeny, które dodatkowo jedno stanowisko małe do 250 udostepniaj˛ a˛ WINS, DNS dwa serwery plików i DHCP dwa serwery wydruku jedno stanowiskoo dwa serwery plików dwa serwery wydruku trzy ufajace˛ sobie domeny jedna domena NT kazdorazo˙ wo z kontami Windows 2000 komputerów i uzytko˙ wników trzy stanowiska Kontrolery domen dodatkowo nadal dwa serwery srednie´ powyzej˙ 250 - udostepniaj˛ a˛ WINS, DNS plików i dwa serwery do 1000 trzy stanowiska o podobnej wydruku na kazdym˙ wielkosci´ (ilos´c´ uzytko˙ wniów) stanowisku kazda˙ z trzech domen dysponuje dwoma serwerami plików i dwoma serwerami wydruku 11 domen w modelu jedna domena Single - Muster (1 domena kont Windows 2000 i 10 domen zasobów) dziesie˛c´ stanowisk duze˙ powyzej˙ 1000 Kontrolery domen udostepniaj˛ a˛ nadal dwa serwery dodatkowo WINS, DNS plików i dwa i DHCP serwery wydruku 10 stanowisk na stanowisko 10 domen, kazda˙ z dwoma serwerami plików i dwoma serwerami wydruku

Tablica 4.18: Opis scenariuszy migracji z Windows NT do Windows 2000 ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 379

Scenariusze docelowe dotyczace˛ duzych˙ i srednich´ srodo´ wisk zawe˛zaj˙ a˛ ilos´c´ domen do jednej. We wszystkich trzech srodo´ wiskach przyjeto˛ załozenie,˙ ze˙ aktualizowana jest przynajmniej jedna dotychczasowa domena (Inplace - Upgrade). Załozenie˙ to nalezy˙ traktowac´ jako prototyp pomysłu na migracje˛ i jej cel, oznacza ono jednak uproszczenie scie´ zki˙ migracji wskutek wy- eliminowania dodatkowych nakładów migracyjnych zwiazan˛ ych z kontami uzytko˙ wników (w skrócie: klonowanie, SID-history, przydzielanie nowych uprawnien´ (ReACLing)). Ocenia sie,˛ ze˙ dla rózn˙ ych srodo´ wisk i na rózn˙ ych etapach konieczne sa˛nastepuj˛ ace˛ nakłady liczone w dniach pracy na osobe.˛

NAKŁAD W DNIACH PRACY NA OSOBE˛ S´ RODOWISKO UWAGI etap pakiet działan´ małe srednie´ duze˙

Warsztat 5 10 10 ryczałtem Ustalenie stanu logowanie 2 6 22 2 na domene˛ faktycznego i siec´ pomysł na zarzadzanie˛ 1 5 21 1 na pierwsza˛ domene˛ plikami 2 na kazd˙ a˛ kolejna˛ domene˛ zasobów (ResDom) pomysł na drukowanie 2 6 20 2 na kazd˙ a˛ ResDom 2 na pierwsza˛ domene˛ procedura 2 4 12 1 dla kazdej˙ kolejnej migracyjna domeny zasobów (ResDom) wymagania 1 3 10 1 na stanowisko Ogólna koncepcja zeszyt z obowiazkami˛ 2 4 6 ryczałtem plan projektu 1 3 10 1 na stanowisko budowa srodo´ wiska ryczałtem 2 testowego 3 5 7 plus dodatkowe stanowiska / domeny wybór osprzetu˛ 5 5 5 ryczałtem pomysł na Active 5 na jedna˛ domene˛ docelowa˛ Dokładna koncepcja Directory (razem z 5 8 15 plus 1 na stanowisko usługami sieciowymi pomysł na zarzadzanie˛ 1 11 51 1 na domene˛ docelowa˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 380

plikami plus 5 na dodatkowe ResDom pomysł na drukowanie 3 5 13 ryczałtem 3 plus 1 na dodatkowe ResDom instalacja 3 3 3 ryczałtem procedura ryczałtem 3 migracyjna 3 13 13 plus czynnik poziomu skomplikowania zarzadzanie˛ systemem 4 centralny (backup, ochrona przed 4 8 8 4 niecentralny wirusami, odzyskiwanie danych po awarii, nadzór) pomysł na prace˛ 10 20 40 ryczałtem planowanie 2 6 20 2 na stanowisko Pilot 10 25 25 10 centralny 10 niecentralny Rolluot 5 25 105 5 na piersza˛ domene˛ docelowa˛ 10 na ResDom Suma 70 175 416

Tablica 4.20: Nakłady na personel w przypadku migracji kontynuacyjnej

Do tego nalezy˙ doliczyc´ jeszcze 10% dla wszystkich srodo´ wisk na kierowanie projektem. Przedstawione szacunkowe nakłady nalezy˙ interpretowac´ jako dolne granice. W kazdym˙ z pakietów działan´ mozna˙ zdeﬁniowac´ duze˙ dodatkowe nakłady, jesli´ w zeszycie z obowiazkami˛ wymagania zostana˛ odpowiednio sformułowane albo rozszerzone. Jako przykład podac´ mozna˙ wpis o stworzeniu bad˛ z´ rozwinieciu˛ pomysłu na prace.˛ Wyliczona ilos´c´ dni na osobe˛ dotyczy nakładów wewnetrzn˛ ych i zewnetrzn˛ ych. W przypadku opisanej tu migracji z Windows proporcje wynosza˛ 20% dla nakładów wewnetrzn˛ ych i 80% dla nakładów zewnetrzn˛ ych. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 381

4.8.3 Nakłady na migracje˛ z Windows NT do Linuksa

Nastepuj˛ aca˛ tabela w punktach przedstawia oceniane scenariusze31.

KATEGORIA ILOS´ C´ PUNKT WYJS´ CIA 1 SCENARIUSZ 2 SCENARIUSZ

UZ˙ YTKOWNIKÓW PROWADZA˛CY DO CELU PROWADZA˛CY DO CELU jedna domena z dwoma jedna domena domena - Samba kontrolerami domeny, Windows 2000 jedno stanowisko które udostepniaj˛ a˛ jedno stanowisko dwa serwery plików małe do 250 dodatkowo WINS, DNS dwa serwery plików dwa serwery wydruku i DHCP dwa serwery wydruku jedno stanowisko dwa serwery plików dwa serwery wydruku trzy ufajace˛ sobie jedna domena domena - Samba / LDAP domeny NT kazdorazo˙ wo Windows 2000 trzy stanowiska z kontami komputerów trzy stanowiska nadal dwa serwery i uzytko˙ wników nadal z dwoma plików i dwa serwery Kontrolery domen serwerami plików wydruku na stanowisku udostepniaj˛ a˛ dodatkowo i dwoma serwerami srednie´ powyzej˙ 250 - WINS, DNS i DHCP wydruku na kazdym˙ do 1000 trzy stanowiska o stanowisku podobnej wielkosci´ (ilosci´ uzytko˙ wników) Kazda˙ z trzech domen z dwoma serwerami plików i dwoma serwerami wydruku 11 domen w modelu jedna domena domena - Samba / LDAP Singel - Master Windows 2000 dziesie˛c´ stanowisk (1 domena kont dziesie˛c´ stanowisk nadal dwa serwery i 10 domen zasobów) nadal dwa serwery plików i dwa serwery Kontrolery domen plików i dwa wydruku na stanowisku duze˙ powyzej˙ 1000 udostepniaj˛ a˛ dodatkowo serwery wydruku 31Niniejsza migracja nazywana jest dalej „migracja˛ zastepuj˛ ac˛ a“.˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 382

WINS, DNS i DHCP na stanowisku 10 stanowisk 10 domen, kazda˙ z dwoma serwerami plików i dwoma serwerami wydruku

Tablica 4.22: Opis scenariusza dla migracji z Windows NT do Linuksa

Scenariusze docelowe dotyczace˛ duzych˙ i srednich´ srodo´ wisk zawe˛zaj˙ a˛ ilos´c´ domen do jednej. We wszystkich trzech srodo´ wiskach przyjeto˛ załozenie,˙ ze˙ aktualizowana jest przynajmniej jedna dotychczasowa domena (Inplace - Upgrade). Załozenie˙ to nalezy˙ traktowac´ jako prototyp pomysłu na migracje˛ i jej cel, oznacza ono jednak uproszczenie scie´ zki˙ migracji wskutek wy- eliminowania dodatkowych nakładów migracyjnych zwiazan˛ ych z kontami uzytko˙ wników (w skócie: klonowanie, SID-history, przydzielanie nowych uprawnien´ (ReACLing)). Ocenia sie,˛ ze˙ dla rózn˙ ych srodo´ wisk i na rózn˙ ych etapach konieczne sa˛nastepuj˛ ace˛ nakłady liczone w dniach pracy na osobe.˛

NAKŁAD W DNIACH PRACY NA OSOBE˛ S´ RODOWISKO UWAGI etap pakiet działan´ małe srednie´ duze˙

Warsztat 5 10 10 ryczałtem Ustalenie stanu logowanie 2 6 22 2 na domene˛ faktycznego i siec´ 1 na pierwsza˛ domene˛ pomysł na zarzadzanie˛ 1 5 21 2 na kazd˙ a˛ kolejna˛ plikami domene˛ zasobów (ResDom) Print 2 6 20 2 na kazd˙ a˛ ResDom 2 na pierwsza˛ domene˛ procedura 2 4 12 1 dla kazdej˙ kolejnej migracyjna domeny zasobów (ResDom) wymagania 1 3 10 1 na stanowisko Ogólna koncepcja zeszyt z obowiazkami˛ 2 4 6 ryczałtem plan projektu 1 3 10 1 na stanowisko ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 383

budowa srodo´ wiska ryczałtem 2 testowego 3 5 7 plus dodatkowe stanowiska / domeny wybór osprzetu˛ 5 5 5 dla wszytkich pomysł na OpenLDAP 4 na jedna˛ domene˛ docelowa˛ Dokładna koncepcja Directory (razem z 4 7 14 plus 1 na stanowisko usługami sieciowymi) pomysł na zarzadzanie˛ 1 11 51 1 na domene˛ docelowa˛ plikami plus 5 na dodatkowe ResDom pomysł na drukowanie 3 5 13 ryczałtem 3 plus 1 na dodatkowe ResDom instalacja 3 3 3 ryczałtem ryczałtem 3 plus czynnik poziomu procedura 3 13 13 skomplikowania migracyjna (Spsoby postepo˛ wania sa˛ tutaj mniej standaryzowane niz˙ w przypadku migracji kontynuacyjnej, jednak w porównaniu z koncepca˛ szczegółowa˛ nalezy˙ liczyc´ sie˛ jedynie ze wzglednie˛ małym wzrostem nakładów.) 6 centralny zarzadzanie˛ systemem 6 9 9 3 niecentralny (backup, ochrona przed (trzeba tu uzupełnic´ wirusami, odzyskiwanie rozwiazania˛ pracujace˛ danych po awarii, nadzór) z cze˛sci´ a˛ oprogramowania; wiele z istniejac˛ ych systemów mozna˙ zastosowac´ takze˙ z OSS ryczałtem (W przypadku migracja do ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 384

OSS nalezy˙ sie˛ tu liczyc´ pomysł na prace˛ 15 25 50 wiekszymi˛ nakładami. Z drugiej strony w migracji do OSS nie chodzi o tworzenie nowego pomysłu na prace)˛ planowanie 2 6 20 2 na stanowisko 20 centralny 30 niecentralny (W przypadku migracji do Pilot 15 30 30 OSS nalezy˙ tu oczekiwac´ wyzszych˙ nakładów na integracje˛ składników i przeznaczenia pewnej ich na indywidualny rozwój). 5 na piersza˛ domene˛ docelowa˛ 10 na ResDom 5/10/20 na niepewnos´c´ (Gdy wszystko jest zaplanowane i przetestowane, Rollout 10 35 125 sam Rollout nie wymaga juz˙ duzych˙ nakładów. Jednak czynnik niepewnosci´ jest wiekszy˛ , wzglednie˛ tolerancja błedów˛ jest mniejsza niz˙ w przypadku migracji kontynuacyjnej Suma 86 195 451

Tablica 4.24: Nakłady liczone w dniach na osobe˛ w przypadku migracji zastepuj˛ acej˛

wymagania zostana˛ odpowiednio sformułowane albo rozszerzone. Jako przykład podac´ mozna˙ wpis o stworzeniu bad˛ z´ rozwinieciu˛ pomysłu na prace.˛ Nakłady na tego typu czynnosci´ moga˛ byc´ niemal dowolne.

4.8.4 Nakłady na migracje˛ z Exchange 5.5 do Exchange 2000

Ponizej˙ przedstawione zostały nakłady potrzebne do przeprowadzenia migracji z Microsoft Exchange 5.5 do Exchange 2000. Ocenia sie,˛ ze˙ dla rózn˙ ych srodo´ wisk i na rózn˙ ych etapach konieczne sa˛nastepuj˛ ace˛ nakłady liczone w dniach pracy na osobe.˛

NAKŁAD W DNIACH PRACY NA OSOBE˛ S´ RODOWISKO UWAGI etap pakiet działan´ małe srednie´ duze˙

Warsztat 2 3 3 ryczałtem Ustalenie stanu logowanie 1 1 1 ryczałtem faktycznego i siec´ srodo´ wisko Exchange 1 5 21 1 na organizacje˛ 2 na 2 serwery Exchange procedura migracyjna 2 4 4 ryczałtem wymagania 1 3 3 ryczałtem Ogólna koncepcja zeszyt z obowiazkami˛ 2 4 4 ryczałtem plan projektu 1 3 3 1 centralny 2 niecentralny budowa srodo´ wiska ryczałtem 2 testowego 3 5 7 plus dodatkowe stanowiska / domeny wybór osprzetu˛ 5 5 5 ryczałtem przy klastrach podwoic´ Dokładna koncepcja pomysł na Exchange 5 10 10 5 centralny 5 niecentralny projekt serwera 5 5 5 ryczałtem test ADC 5 10 10 ryczałtem 5 plus 1 na czynnik poziomu skomplikowania ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 386

instalacja 3 3 3 ryczałtem procedura ryczałtem 2 migracyjna 2 12 12 plus czynnik poziomu skomplikowania zarzadzanie˛ systemem 5 centralny (backup, ochrona przed 5 10 10 5 niecentralny wirusami, odzyskiwanie danych po awarii, nadzór) pomysł na prace˛ 10 15 25 ryczałtem planowanie 2 6 20 2 na stanowisko Pilot 5 10 10 5 centralny 5 niecentralny Rolluot 3 9 30 3 na kazdy˙ serwer Exchange Suma 64 121 171

Tablica 4.26: Nakłady liczone w dniach na osobe:˛ Exchange5.5 –> Exchange2000

Do tego nalezy˙ doliczyc´ jeszcze 10% dla wszystkich srodo´ wisk na kierowanie projektem. Wyliczona ilos´c´ dni na osobe˛ dotyczy nakładów wewnetrzn˛ ych i zewnetrzn˛ ych. W przypadku opisanej tu migracji z Exchange proporcje wynosza˛ około 25% dla nakładów wewnetrzn˛ ych i około 75% dla nakładów zewnetrzn˛ ych.

4.8.5 Nakłady na migracje˛ z Exchange 5.5 do Samsung Contact

Ponizej˙ przedstawione zostały nakłady potrzebne do przeprowadzenia migracji z Microsoft Exchange 5.5 do Samsung Contact. Zaprezentowane tu załozenia˙ dotycza˛wszystkich srodo´ wisk (opartych na Samsung Contact).

◦ wszystkie serwery Samsung Contact oparte sa˛ na systemach linuksowych albo systemach Unix OS.

◦ mozliwa˙ jest konsolidacja wielu serwerów MS Exchange. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 387

◦ ilos´c´ uzytko˙ wników zalezy˙ tylko od wydajnosci´ CPU. Nie istnieja˛ ograniczenia rozmiaru skrzynki pocztowej. Dane moga˛ byc´ gromadzone w ilosci´ wielu terabajtów.

◦ nie jest potrzebna migracja do ADS.

◦ system oszczedza˛ zasoby, stad˛ w przypadku migracji mozna˙ nadal korzystac´ z istniejace˛ go osprzetu˛ (Linux).

◦ istnieje mozliwo˙ s´c´ migracji publicznych katalogów, kalendarza i kontaktów.

NAKŁAD W DNIACH PRACY NA OSOBE˛ S´ RODOWISKO UWAGI etap pakiet działan´ małe srednie´ duze˙

Warsztat Ustalenie stanu logowanie 0,2 0,2 0,2 faktycznego i siec´ Srodo´ wisko Exchange 0,2 0,5 1 procedura 0,2 0,5 1 wymagania 0,2 0,5 1 Ogólna koncepcja zeszyt z obowiazkami˛ 1 2 3 plan projektu 0,5 1 1 budowa srodo´ wiska 1 2 5 testowego wybór osprzetu˛ 0,3 0,3 0,5 Dokładna koncepcja pomysł na Contact 0,5 0,3 0,5 projekt serwera test ADC 0,5 0,5 1 procedura instalacyjna 0,5 0,5 1 procedura 0,2 0,3 1 migracyjna zarzadzanie˛ systemem (backup, ochrona przed 1 1 2 wirusami, odzyskiwanie danych po awarii, nadzór) pomysł na prace˛ 1 2 2 planowanie 0,5 0,5 0,5 ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 388

Pilot 1 2 5

Rolluot 2 3 7

Suma 10,8 17,8 34,7

Tablica 4.28: Nakłady liczone w dniach na osobe:˛ Exchange5.5 –> Samsung Contact

4.8.6 Zalecenia odnosnie´ sposobu oceny produktów / grup produktów

4.8.6.1 Generalne załozenia˙

◦ W obliczeniach podanych w przykładowych scenariuszach dla rózn˙ ych obiektów migracji ocenione zostały wyłacznie˛ generatory kosztów i generatory korzysci:´

– koszty osprzetu˛ – koszty oprogramowania – koszty przenoszenia danych (= koszty osobowe)

◦ Na tym tle uznano wszelkie inne wystepuj˛ ace˛ jeszcze koszty za neutralne:

– koszty zapewnienia kompatybilnosci´ – koszty szkolenia – koszty administrowania

◦ Projekty migracyjne sa˛ na ogół wyposazone˙ tylko w niewielki własny potencjał oszczed-˛ noscio´ wy (koszty oprogramowania). Pozwala on jedynie w rzadkich przypadkach wykazac´ rentownos´c´ przedsie˛wziecia.˛ Poniewaz˙ w w tle przedsie˛wziecia˛ migracyjnego zasadniczo znajduje sie˛ wybór pomiedzy˛ migracja˛ wewnatrz˛ platformy Microsoftu albo migracja˛ do platformy OSS, w ponizszych˙ przykładach dokonano „oceny na krzyz“.˙ W tym celu w przypadku migracji do OSS wliczono po stronie oszczedno˛ sci´ niewymagane, porówny- walne nakłady bed˛ ace˛ róznic˙ a˛ przypadajac˛ a˛ na migracje˛ w ramach platformy Microsoft.

◦ W przypadku zewnetrzn˛ ych kosztów osobowych przyjeto˛ sredni´ a˛ dniówke˛ wynoszac˛ a˛ 1.000 ¤. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 389

◦ Za podstawe˛ oceny kosztów osobowych przyjeto˛ informacje dla najwyzszych˙ urzedów˛ fe- deralnych32. Obliczenie kosztów wykonano na podstawie stawki wynagrodzenia poziomu IVa (najwyzsze˙ urzedy˛ federalne, 36,98 ¤na godzine,˛ 462 minuty na dzien.´

◦ Podane przykładowo koszty przypadajace˛ na osobe˛ dla duzych,˙ srednich´ i małych urzedów˛ kazdorazo˙ wo dzielone były w proporcji 80 / 20 na zasoby zewnetrzne˛ i wewnetrzne.˛

◦ Dla oprocentowania przyszłych oszczedno˛ sci´ uzyto˙ stopy procentowej BMF33 (obecnie 6%).

◦ Licencje na oprogramowanie dla urzedów˛ wynosza˛ około 50% z normalnych cenników34. Warunki takie sa˛ powszechnie stosowane przez dostawców

Aby oddzielnie pokazac´ rózne˙ mozliwo˙ sci´ oceny ekonomicznej, zaprezentujemy w nastepu-˛ jac˛ ych przykładach dwie struktury:

◦ struktura WiBe21 oparta na zdeﬁniowanych katalogach kryteriów

◦ struktura katogorii kosztów informatyzacji oparta na trzech głównych blokach kosztów, tj. osprzetu,˛ oprogramowania i osobowych odpowiednio do matrycy kosztów migracji.

4.8.6.2 Przykłady według struktury WiBe21

MIGRACJA Z MICROSOFT WINDOWS NT DO PRZEDMIOT MIGRACJI S´ RODOWISKA OSS – NA KLIENTY I SERWERY LINUKSOWE Przykładowy scenariusz mały urzad,˛ 250 uzytko˙ wników koszty oprogramowania, koszty zastapienia˛ Wyznaczniki sukcesu oprogramowania

32Patrz „Stopy kosztów osobowych dla sporzadzania˛ rachunków kosztów / rachunków wydajnosci´ ekonomicznej“ Federalne Ministerstwo Finansów, 29 pazdziernika´ 2002 r. 33Patrz „Stopy kosztów osobowych . . . “ Federalnego Ministerstwa Finansów z 29 pazdziernika´ 2002 r. 34W pojedynczych przypadkach nalezy˙ liczyc´ sie˛ z innymi cenami, jesli´ trafniej przedstawiaja˛one realna˛sytuacje˛ w urzedach.˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 390

◦ generatorami koszów / korzysci´ sa˛ trzy kryteria

– koszty licencji – koszty zastapienia˛ oprogramowania – koszty szkolenia

◦ Na tym tle uznano wszelkie inne wystepuj˛ ace˛ jeszcze koszty za neutralne i tym samym w przykładowym wyliczeniu wzieto˛ pod uwage˛ tylko w/w generatory kosztów / korzysci.´

◦ W przykład wliczono po stronie oszczed-˛ nosci´ róznic˙ e˛ wynikajac˛ a˛ z nie branych pod uwage˛ nakładów na przejscie´ z MS Windows NT do Linuksa. Dotyczy to licencji na oprogramowanie i kosztów zastapienia˛ oprogramowania. Licencje na oprogramowanie: Po stronie oszczedno˛ sci´ liczono tu licencje˛ na Windowsa jako róznic˙ e˛ w porów- naniu do bezpłatnego Linuksa. Koszty zastapienia˛ oprogramowania: Załozenia˙ Po stronie oszczedno˛ sci´ wpisano róznic˙ e˛ pomiedzy˛ nakładami liczonymi w dniach roboczych na osobe˛ w przypadku migracji wewnatrz˛ platformy Microsoft a migracji do Linuksa. Róznica˙ ta obliczona została na podstawie sredniej,´ zewnetrz-˛ nej stopy kosztów osobowych wynosza-˛ cej 1.000 ¤. Wewnetrzne,˛ zaoszczedzone˛ dni robocze na osobe,˛ rozliczone zostały w oparciu o stopy Federalnego Ministerstwa Finan- sów.

◦ Nakłady na szkolenia uzytko˙ wników sa˛ niemal takie same w przypadku obydwu platform (Windows 2000 i Linux). Dla- tego przedstawianie przykładowego wyliczenia uznano za zbyteczne.

◦ Zaplanowane szkolenia dla dwóch admi- nistratorów, kazdy˙ po 5 dni (łacznie˛ około 2000 ¤razem z podatkiem VAT)

◦ Przyjeto˛ proporcje˛ nakładów zewnetrz-˛ nych i wewnetrzn˛ ych na poziomie 80% (zewnetrzne)˛ oraz 20% (wewenetrzne).˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 391

Break-even Projekt spłaca sie˛ juz˙ w pierwszym roku.

Tablica 4.30: Przykład migracji: infrastruktura serwerów – mały urzad˛

Przykład migracji: infrastruktura serwerów – mały urzad˛

Tablica 4.31: 1 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), mały urzad.˛

Z przedstawionego powyzej˙ przykładu WiBe wynika dodatnia wartos´c´ kapitału przy zało- zeniu,˙ ze˙ zewnetrzne˛ wsparcie migracji nie przekroczy 28 dni roboczych na osobe˛ a konieczne przy tym wsparcie wewnetrzne˛ nie przekroczy 7 dni roboczych na osobe.˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 392

MIGRACJA Z MICROSOFT WINDOWS NT DO PRZEDMIOT MIGRACJI S´ RODOWISKA OSS – NA KLIENTY I SERWERY LINUKSOWE Przykładowy scenariusz sredni´ urzad,˛ 1.000 uzytko˙ wników koszty oprogramowania, koszty zastapienia˛ Wyznaczniki sukcesu oprogramowania ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 393

◦ generatorami koszów / korzysci´ sa˛ trzy kryteria

– koszty licencji – koszty zastapienia˛ oprogramowania – koszty szkolenia

◦ Na tym tle uznano wszelkie inne wystepuj˛ ace˛ jeszcze koszty za neutralne i tym samym w przykładowym wyliczeniu wzieto˛ pod uwage˛ tylko w/w generatory kosztów / korzysci.´

◦ Nakłady na szkolenia uzytko˙ wników sa˛ niemal takie same w przypadku obydwu platform (Windows 2000 i Linux). Dla- tego przedstawianie przykładowego wyliczenia uznano za zbyteczne.

◦ Zaplanowane szkolenia dla 2 administra- torów, kazdy˙ po 5 dni (łacznie˛ około 2000 ¤razem z podatkiem VAT)

◦ Przyjeto˛ proporcje˛ nakładów zewnetrz-˛ nych i wewnetrzn˛ ych na poziomie 80% (zewnetrzne)˛ oraz 20% (wewenetrzne).˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 394

Break-even Projekt spłaca sie˛ juz˙ w pierwszym roku.

Tablica 4.33: Przykład migracji: infrastruktura serwerów – sredni´ urzad˛

Przykład migracji: infrastruktura serwerów – sr´ edni urzad˛

Tablica 4.34: 2 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), sredni´ urzad˛

Z przedstawionego powyzej˙ przykładu WiBe wynika dodatnia wartos´c´ kapitału przy zało- zeniu,˙ ze˙ zewnetrzne˛ wsparcie migracji nie przekroczy 76 dni roboczych na osobe˛ a konieczne przy tym wsparcie wewnetrzne˛ nie przekroczy 19 dni roboczych na osobe.˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 395

MIGRACJA Z MICROSOFT WINDOWS NT DO PRZEDMIOT MIGRACJI S´ RODOWISKA OSS – NA KLIENTY I SERWERY LINUKSOWE Przykładowy scenariusz duzy˙ urzad,˛ 10.000 uzytko˙ wników koszty oprogramowania, koszty zastapienia˛ Wyznaczniki sukcesu oprogramowania ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 396

◦ generatorami koszów / korzysci´ sa˛ trzy kryteria

– koszty licencji – koszty zastapienia˛ oprogramowania – koszty szkolenia

◦ Na tym tle uznano wszelkie inne wystepuj˛ ace˛ jeszcze koszty za neutralne i tym samym w przykładowym wyliczeniu wzieto˛ pod uwage˛ tylko w/w generatory kosztów / korzysci.´

◦ W przykład wliczono po stronie oszczed-˛ nosci´ róznic˙ e˛ wynikajac˛ a˛ z nie branych pod uwage˛ nakładów na przejscie´ z MS Windows NT do Linuksa. Dotyczy to licencji na oprogramowanie i kosztów zastapienia˛ oprogramowania. Licencje na oprogramowanie: Po stronie oszczedno˛ sci´ liczono tu licencje˛ na Windowsa jako róznic˙ e˛ w porów- naniu do bezpłatnego Linuksa. Koszty zastapienia˛ oprogramowani: Załozenia˙ Po stronie oszczedno˛ sci´ wpisano róznic˙ e˛ pomiedzy˛ nakładami liczonymi w dniach roboczych na osobe˛ w przypadku migracji wewnatrz˛ platformy Microsoft a migracji do Linuksa. Róznica˙ ta obliczona została na podstawie sredniej,´ zewnetrz-˛ nej stopy kosztów osobowych wynosza-˛ cej 1.000 EUR. Wewnetrzne,˛ zaoszczedzone˛ dni robocze na osobe,˛ rozliczone zostały w oparciu o stopy Federalnego Ministerstwa Finan- sów.

◦ Nakłady na szkolenia uzytko˙ wników sa˛ niemal takie same w przypadku obydwu platform (Windows 2000 i Linux). Dla- tego przedstawianie przykładowego wyliczenia uznano za zbyteczne.

◦ Zaplanowane szkolenia dla 2 administra- torów, kazdy˙ po 5 dni (łacznie˛ około 2000 ¤razem z podatkiem VAT)

◦ Przyjeto˛ proporcje˛ nakładów zewnetrz-˛ nych i wewnetrzn˛ ych na poziomie 80% (zewnetrzne)˛ oraz 20% (wewenetrzne).˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 397

Break-even Projekt spłaca sie˛ juz˙ w pierwszym roku.

Tablica 4.36: Przykład migracji: infrastruktura serwerów – duzy˙ urzad˛

Przykład migracji: infrastruktura serwerów – duzy˙ urzad˛

Tablica 4.37: 3 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), duzy˙ urzad˛

Z przedstawionego powyzej˙ przykładu WiBe wynika dodatnia wartos´c´ kapitału przy załoze-˙ niu, ze˙ zewnetrzne˛ wsparcie migracji nie przekroczy 248 dni roboczych na osobe˛ a konieczne przy tym wsparcie wewnetrzne˛ nie przekroczy 62 dni roboczych na osobe.˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 398

MIGRACJA Z MICROSOFT OFFICE DO S´ RODO- PRZEDMIOT MIGRACJI WISKA OSS – NA KLIENTY I SERWERY LI- NUKSOWE Z OPENOFFICE.ORG mały urzad˛ do 250 uzytko˙ wników Przykładowe scenariusze sredni´ urzad˛ do 1.000 uzytko˙ wników duzy˙ urzad˛ powyzej˙ 1.000 uzytko˙ wników koszty oprogramowania, koszty zastapienia˛ Wyznaczniki sukcesu oprogramowania ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 399

◦ W przypadku migracji do OpenOfﬁce.org na serwerach i klientach pracuje system operacyjny GNU/Linux.

◦ generatorami koszów / korzysci´ sa˛ trzy kryteria

– koszty licencji – koszty zastapienia˛ oprogramowania – koszty szkolenia

◦ Na tym tle uznano wszelkie inne wystepuj˛ ace˛ jeszcze koszty za neutralne i tym samym w przykładowym wyliczeniu wzieto˛ pod uwage˛ tylko w/w generatory kosztów / korzysci.´

◦ W przykład wliczono po stronie oszczed-˛ nosci´ róznic˙ e˛ wynikajac˛ a˛ z kosztów licencji MS Ofﬁce w porównaniu do bez- płatnego OpenOfﬁce.org.

Załozenia˙ ◦ Nakłady na szkolenia uzytko˙ wników sa˛ niemal takie same w przypadku obydwu platform (Windows 2000 i Linux). Dla- tego przedstawianie przykładowego wyliczenia uznano za zbyteczne.

◦ Zaplanowane szkolenia dla 2 administra- torów, kazdy˙ po 5 dni (łacznie˛ około 2000 ¤razem z podatkiem VAT)

◦ U podstaw obliczanych tu przykładów lez˙a˛ nastepuj˛ ace˛ ilosci´ - załozenia˙ 35: 35Jednolite dla wszytkich typów urzedów˛ – ilos´c´ dokumentów na uzytko˙ wnika 13 – ilos´c´ makr na uzytko˙ wnika 0,07 – czas migracji pojedynczego na dokument 0,2 h – czas migracji pojedynczego makro ∗ mały urzad˛ 0,91 h ∗ sredni´ urzad˛ 5,54 h ∗ duzy˙ urzad˛ 6,94 h ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 400

We wszystkich typach urzedów˛ projekt spłaca Break-even sie˛ juz˙ w pierwszym roku.

Tablica 4.39: Przykłady migracji: Ofﬁce / Client Desktop

Przykłady migracji: Ofﬁce / Client Desktop

Tablica 4.40: Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), mały urzad˛

Obliczen´ w powyzszych˙ przykładach dokonano m.in. po to, aby uzyskac´ górna˛ granice˛ wymaganego czasu na migracje˛ makr. Odpowiednie czasy wskazane w załozeniach˙ pokazuja˛ kaz-˙ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 401

dorazowo te˛ granice.˛ Az˙ do tej wartosci´ nie powstaje c.p.36 ujemna wartosć´ kapitału. Niniejsza ocena stanowi ponadto przeglad˛ nakładów zwiazan˛ ych z migracja˛ wewnatrz˛ platformy Microsoftu. Zostały tu one podliczone po stronie oszczedno˛ sci´ i mozna˙ je odczytac´ z wierszy „wartosć´ kapitału wb (wb = wpływajaca˛ na budzet)“.˙ Nakłady na migracje˛ do OpenOffice.org nie sa˛ w istocie kosztami wpływajac˛ ymi na budzet,˙ poniewaz˙ przeprowadza sie˛ ja˛ za pomoca˛ własnego personelu. Do ocenianych tu nakładów trzeba w kazdym˙ przypadku doliczyc´ wsparcie zewnetrzne,˛ które nalezy˙ zaplanowac´ w przyblizeniu˙ na tym samym poziomie dla obydwu dróg migracji.

Tablica 4.41: Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), mały urzad˛

36c. p. = ceteris paribus; tzn. „w poza tym jednakowych warunkach“; wszystkie inne parametry ramowe i ich zalezno˙ sci´ nie zostały zmienione w niniejszych rózni˙ ac˛ ych sie˛ od siebie przykładach ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 402

Tablica 4.42: Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), sredni´ urzad˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 403

Tablica 4.43: Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), duzy˙ urzad˛

MIGRACJA Z MICROSOFT OFFICE DO S´ RO- PRZEDMIOT MIGRACJI DOWISKA OSS – NA LINUKSOWY OPENOF- FICE.ORG Przykładowy scenariusz sredni´ urzad˛ do 500 uzytko˙ wników Krytyczne wyznaczniki przejecie˛ istniejac˛ ych danych - dokumentów i sukcesu makr ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 404

◦ generatorami koszów / korzysci´ sa˛ trzy kryteria

– koszty licencji – koszty zastapienia˛ oprogramowania

◦ Na tym tle uznano wszelkie inne wystepuj˛ ace˛ jeszcze koszty za neutralne i tym samym w przykładowym wyliczeniu wzieto˛ pod uwage˛ tylko w/w generatory kosztów / korzysci.´

◦ Migrowane obiekty podzielono na dokumenty i makra. Na dokumenty przypa- Załozenia˙ daja˛ z reguły krótkie czasy migracji. Ma- kra wymagaja˛ bardzo rózn˙ ych nakładów czasu, które zalez˙a˛ od stopnia złozono˙ sci´ kazde˙ go makro.

◦ Dla oceny kosztów aplikacji Microsoftu przyjeto˛ sredni´ poziom cen (poziom 2 z 3) umowy ramowej ﬁrmy Microsof z Minsterstwem Spraw Wewnetrzn˛ ych. Nie sa˛ one ponoszone natychmiast w jednej racie, wskutek czego nie brano pod uwage˛ skonta.

◦ Uwzgledniono˛ migracje˛ 35 skomplikowanych makr w całym urzedzie˛ 37.

Rozpieto˛ s´c´ (wartosci´ progowe) krytycznych wyznaczników sukcesu

37Patrz dalsze załozenia˙ odnosnie´ ilosci´ i cen przyjete˛ w obliczonym przykładzie załaczone˛ do prezentacji Break Even. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 405

Przy maksymalnie około 6.500 migrowanych dokumentów i 500 uzytko˙ wnikach (odpowiada Break-even po 3 latach to około 13 obiektom na uzytko˙ wnika) Break- even mozna˙ uzyskac´ po 3 latach. Przy maksymalnie około 12.500 migrowanych dokumentów i 500 uzytko˙ wnikach (odpowiada Break-even po 5 latach to około 25 obiektom na uzytko˙ wnika) oraz 35 makrach w całym urzedzie˛ Break-even mozna˙ uzyskac´ po 5 latach.

Tablica 4.45: Przykłady migracji z Windows / Microsoft Ofﬁce do –> Linux / OpenOfﬁce.org

Przykład migracji z Windows / Microsoft Ofﬁce do –> Linux / OpenOfﬁce.org ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 406

Tablica 4.46: Przykład WiBe: Windows / Ofﬁce do Linux / OpenOfﬁce.org; Break even po 3 latach

W przykładzie tym Break-even nastepuje˛ po trzech latach. Migrowany jest MS Office wraz ze srodo´ wiskiem windowsowym do OpenOffice.org i srodo´ wiska GNU / Linux. Migracja obejmuje 6.500 dokumentów. Na oprogramowanie Open Source nie przypadaja˛ zadne˙ koszty. Odchodza˛ za to coroczne koszty licencji na produkty Microsoftu w wysokosci´ około 160 tys. ¤. Wartosć´ ta zapisana jest w WiBe po stronie oszczedno˛ sci´ i wpływa na budzet.˙ Nakłady na przestawienie oprogramowania ponoszone sa˛własnymi siłami, dlatego koszty w wysokosci´ około 148 tys. ¤nie wpływaja˛ na budzet.˙ Za pomoca˛ niniejszej metody mierzenia wielkosci´ kapitału kwoty przypadajace˛ na dany dzien´ dyskontowane sa˛ o oprocentowanie. Wynikaja˛ z nich trzyletnie oszczedno˛ sci´ (brak kosz- ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 407

tów licencji Microsoftu) wynoszace˛ 142 tys. ¤. Oprocentowanie nakładów migracyjnych prowadzi równolegle do powstania rocznej kwoty około 139 tys. ¤. Jako wartos´c´ kapitału powstaje dodatnia kwota wynoszaca˛ 3.085 ¤. Tym samym przedsie˛wziecie˛ to jest opłacalne. Oceny ryzyka (prawdopodobienstwa´ wystapienia˛ oszczedno˛ sci,´ wzglednie˛ kosztów migracji) mozna˙ tu nie brac´ pod uwage,˛ gdyz˙ oszczedno˛ sci´ sa˛ obecnymi opłatami licencyjnymi, których w przyszłosci´ nie bedzie.˛ Koszty zastapienia˛ oporogramowania przedstawione w postaci czasu wymaganego na migracje˛ zostały raczej zawyzone˙ niz˙ zanizone.˙ Podstawa˛ dla ilosci´ jest jako Best Practice wyliczenie Gartnera38, które dostosowane zostało do wymagan´ administracji publicznej.

Tablica 4.47: Przykład WiBe: Windows / MS Office do Linux / OpenOffice.org; Break even po 5 latach 38Patrz „The Bost and Benefits of Moving to Sun’s StarOffice 6.0“, 1 lipca 2002 r. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 408

W niniejszym przykładzie Break-even uzyskiwany jest po 5 latach. Uzupełniajac˛ przykład dla 3-letniego Break-even nalezy˙ zauwazy˙ c,´ co nastepuje.˛ Do 12.500 została jedynie zwiekszona˛ ilos´c´ migrowanych dokumentów (odpowiada to około 25 dokumentom na uzytko˙ wnika). Czas oceny wydłuzon˙ y został do 5 lat. Systematyka obliczen´ pozostaje taka sama. Po pieciu˛ latach powstaje dodatnia wartos´c´ kapi- tału w wysokosci´ 1.496 ¤. Jesli´ chodzi o ocene˛ ryzyka i podstawe˛ ilosci,´ patrz wyzej.˙

MIGRACJA Z EXCHANGE 5.5 DO S´ RODOWI- PRZEDMIOT MIGRACJI SKA OSS – NA KLIENTY I SERWERY LINUK- SOWE SAMSUNG CONTACT Przykładowy scenariusz mały urzad,˛ 250 uzytko˙ wników koszty oprogramowania, koszty zastapienia˛ Wyznaczniki sukcesu oprogramowania ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 409

◦ generatorami koszów / korzysci´ sa˛ trzy kryteria

– koszty licencji – koszty zastapienia˛ oprogramowania – koszty szkolenia

◦ Na tym tle uznano wszelkie inne wystepuj˛ ace˛ jeszcze koszty za neutralne i tym samym w przykładowym wyliczeniu wzieto˛ pod uwage˛ tylko w/w generatory kosztów / korzysci.´

◦ W przykład wliczono po stronie oszczed-˛ nosci´ róznic˙ e˛ wynikajac˛ a˛ z nie branych pod uwage˛ nakładów na przejscie´ z MS Exchange 5.5 do Exchange 2000. Doty- czy to licencji na oprogramowanie i kosz- tów zastapienia˛ oprogramowania. Licencje na oprogramowanie: Po stronie oszczedno˛ sci´ liczono tu róz-˙ Załozenia˙ nice˛ pomiedzy˛ kosztami licencji Contact a Exchange. Koszty zastapienia˛ oprogramowania: Po stronie oszczedno˛ sci´ wpisano róznic˙ e˛ pomiedzy˛ nakładami liczonymi w dniach roboczych na osobe˛ w przypadku Sam- sung i Microsoft. Róznica˙ ta obliczona została na podstawie sredniej,´ zewnetrz-˛ nej stopy kosztów osobowych wynosza-˛ cej 1.000 ¤.

◦ Nakłady na szkolenia uzytko˙ wników sa˛ niemal takie same w przypadku obydwu platform (Exchange i Contact). Dlatego przedstawianie przykładowego wyliczenia uznano za zbyteczne.

◦ Zaplanowane szkolenia dla 2 administra- torów, kazdy˙ po 5 dni (łacznie˛ około 2.000 ¤razem z podatkiem VAT)

◦ Przyjeto˛ proporcje˛ nakładów zewnetrz-˛ nych i wewnetrzn˛ ych na poziomie 75% (zewnetrzne)˛ oraz 25% (wewenetrzne).˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 410

Na podstawie załoze˙ n´ projekt jawi sie˛ jako wysoce opłacalny. Break-even uzyskuje sie˛ juz˙ w pierwszym roku. Wazn˙ ym czynnikiem sa˛ przy tym oszczedno˛ sci´ na zewnetrzn˛ ym wsparciu wymaganym w przypadku migracji wewnatrz˛ Break-even platformy Microsoft. W oparciu o ocene˛ Best- Case i Worst-Case w ramach dodatniej wartosci´ kapitału powstaje przestrzen´ 5 - 20 dni wymaganego zewnetrzne˛ go wsparcia dla przedstawionej w przykładzie migracji do Samsung.

Tablica 4.49: Przykłady migracji: Messaging / Groupware – mały urzad˛

Przykład migracji: Messaging / Groupware – mały urzad˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 411

Tablica 4.50: Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], mały urzad˛

W powyzszym˙ przykładzie ustalono górna˛granice˛ progowa˛zewnetrzne˛ go wsparcia dla Con- tact w przypadku małych urzedów˛ . Wynosi ona 20 dni roboczych na osobe.˛ Tym samym wartos´c´ kapitału wynoszaca˛ (187) nadal jest dodatnia, co sprawia, ze˙ projekt jest rentowny. Jesli´ konieczne jest mniejsze zewnetrzne˛ wsparcie, wówczas wartos´c´ kapitału rosnie.´ Oceny ryzyka (prawdopodobienstwa´ wystapienia˛ oszczedno˛ sci,´ wzglednie˛ kosztów migracji) mozna˙ tu nie brac´ pod uwage,˛ gdyz˙ oszczedno˛ sci´ sa˛ obecnymi opłatami licencyjnymi, któ- rych w przyszłosci´ nie bedzie.˛ Koszty zastapienia˛ oporogramowania przedstawione w postaci wymaganego czasu zostały raczej zawyzone˙ niz˙ zanizone.˙ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 412

MIGRACJA Z EXCHANGE 5.5 DO S´ RODOWI- PRZEDMIOT MIGRACJI SKA OSS – NA KLIENTY I SERWERY LINUK- SOWE SAMSUNG CONTACT Przykładowy scenariusz sredni´ urzad,˛ 1.000 uzytko˙ wników koszty oprogramowania, koszty zastapienia˛ Wyznaczniki sukcesu oprogramowania Patrz przykłady z „mały urzad“.˛ Dodatkowo: Ilos´c´ administratorów i nakład na ich szkolenie Załozenia˙ nie zmienia sie˛ w zalezno˙ sci´ od ilosci´ uzytko˙ w- ników pozostaja˛ takie same (około 2 x 2.000, ¤liczone z podatkiem VAT). Na podstawie załoze˙ n´ projekt jawi sie˛ jako wysoce opłacalny. Break-even uzyskuje sie˛ juz˙ w pierwszym roku. Najwazniejszym˙ czynnikiem sa˛przy tym oszczedno˛ sci´ na zewnetrzn˛ ym wsparciu wymaganym w przypadku migracji Break-even wewnatrz˛ platformy Microsoft. W oparciu o ocene˛ Best-Case i Worst-Case w ramach dodatniej wartosci´ kapitału powstaje przestrzen´ 10 - 35 dni dla potrzebnego zewnetrzne˛ go wsparcia w przypadku przedstawionej w przykładzie migracji do Samsung.

Tablica 4.52: Przykłady migracji: Messaging / Groupware – sredni´ urzad˛

Przykład migracji: Messaging / Groupware – sr´ edni urzad˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 413

Tablica 4.53: Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], sredni´ urzad˛

W powyzszym˙ przykładzie ustalono górna˛granice˛ progowa˛zewnetrzne˛ go wsparcia dla Con- tact w przypadku srednich´ urzedów˛ . Wynosi ona 34 dni robocze na osobe.˛ Tym samym wartosć´ kapitału wynoszaca˛ (1.102) jest jeszcze dodatnia, co sprawia, ze˙ projekt jest rentowny. Jesli´ za wartosć´ zewnetrzne˛ go wsparcia dla Contact w przypadku srednich´ urzedów˛ przyjmie sie˛ realistyczny wskaznik´ 5 dni, wówczas powstaje naprawde˛ duza˙ dodatnia wartosć´ kapitału, która sygnalizuje dobra˛ rentownosć´ projektu. Oceny ryzyka (prawdopodobienstwa´ wystapienia˛ oszczedno˛ sci,´ wzglednie˛ kosztów migracji) mozna˙ tu nie brac´ pod uwage,˛ gdyz˙ oszczedno˛ sci´ sa˛ obecnymi opłatami licencyjnymi, któ- rych w przyszłosci´ nie bedzie.˛ Koszty zastapienia˛ oporogramowania przedstawione w postaci wymaganego czasu zostały raczej zawyzone˙ niz˙ zanizone.˙ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 414

4.8.6.3 Przykład migracji: Messaging / Groupware – duzy˙ urzad˛

MIGRACJA Z EXCHANGE 5.5 DO S´ RODOWI- PRZEDMIOT MIGRACJI SKA OSS – NA KLIENTY I SERWERY LINUK- SOWE SAMSUNG CONTACT Przykładowy scenariusz duzy˙ urzad,˛ 10.000 uzytko˙ wników koszty oprogramowania, koszty zastapienia˛ Wyznaczniki sukcesu oprogramowania Załozenia˙ Patrz przykłady z „mały i sredni´ urzad“.˛ Na podstawie załoze˙ n,´ do ilosci´ pracowników wynoszacej˛ około 6.200, projekt jawi sie˛ jako opłacalny. Jesli´ wzrosnie´ ilosć´ pracowników i / lub ilosć´ dni zewnetrzne˛ go wsparcia, wówczas Break-even po 1 roku wartosć´ kapitału stanie sie˛ ujemna. Oszczedno-˛ sci´ wynikajace˛ z nie branych pod uwage˛ dni zewnetrze˛ go wsparcia dla Migracji wewnatrz˛ platformy Microsoft równowaz˙a˛ sie˛ tylko do w/w ilosci´ pracowników.

Tablica 4.55: Przykłady migracji: Messaging / Groupware – duzy˙ urzad˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 415

Tablica 4.56: Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], duzy˙ urzad˛

W powyzszym˙ przykładzie załozono˙ wsparcie zewnetrzne˛ dla Contact w wysokosci´ około 17 dni roboczych na osobe.˛ Wynikajace˛ z tego oszczedno˛ sci´ wynosza˛ około 111 dni roboczych na osobe˛ wzgledem˛ usługi Microsoftu. Ilos´c´ uzytko˙ wników ustalono na 10.000. W takich warunkach wyliczenia daja˛ jeszcze dodatnia˛ wartos´c´ kapitału.

4.8.6.4 Przykłady migracji według kategorii kosztów informatyzacji

Obowiazuj˛ a˛ tu takie same załozenia,˙ jakie zostały opisane w rozdziale 4.8.6.1. Obliczenia w przykładach odnosza˛ sie˛ do produktów przedstawionych w ponizszej˙ tabeli. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 416

Tablica 4.57: Typy migracji / produkty

W niniejszym modelu dokonano porównawczej oceny alternatywnych typów migracji przyj- mujac˛ za punkt wyjscia´ aktualne srodo´ wisko. Scenariuszem wyjscio´ wym jest przy tym platforma Microsoftu. Jedynie wariant migracji kontynuacyjnej nie zawiera namacalnych, dajac˛ ych sie˛ obliczyc´ oszczedno˛ sci.´ Wszystkie inne warianty prowadza˛ do całkowitej albo cze˛scio´ wej zmiany platformy i tym samym zawieraja˛w obszarze porównania ich z migracja˛kontynuacyjna˛oszczed-˛ nosci´ w postaci zaoszczedzon˛ ych wydatków. Ceny i warunki zastosowane w przykładowych wyliczeniach zwracaja˛sie˛ w pierwszym roku wdrazania˙ projektu. Poniewaz˙ rachunek opiera sie˛ na cenach zakupu, oszczedno˛ sci´ powstaja˛ równiez˙ tylko w pierwszym roku.

4.8.6.5 Pełna migracja

Pełna migracja oznacza ponadprzecietnie˛ duzy˙ efekt oszczedno˛ scio´ wy w przypadku urzedów˛ kazde˙ go typu. Na przykład migracja z Windows NT do Linuksa daje w przeciwienstwie´ do migracji do Windows 2000 oszczedno˛ sci,´ które wielokrotnie przekraczaja˛ nakłady.

Duza˙ instalacja Koszty osobowe w przypadku zmiany platformy stanowia˛ porównywalny rzad˛ wielkosci,´ dlatego ze˙ wieksza˛ cze˛s´c´ oszczedno˛ sci´ pochodzi ze zbedn˛ ych kosztów licencji. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 417

Rysunek 4.5: Przykład rachunku opłacalnosci´ migracji Windows NT –> Linux, duzy˙ urzad,˛ ocena kosztów projektu

Takze˙ ocena rentownosci´ niniejszego wariantu pokazuje poprzez dodatnia˛ wartos´c´ kapitału opłacalny przebieg przedsie˛wziecia.˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 418

Rysunek 4.6: Przykład rachunku opłacalnosci´ migracji Windows NT –> Linux, duzy˙ urzad,˛ ocena wartosci´ kapitału

Sr´ ednia instalacja W obszarze srednich´ i małych urzedów˛ obowiazuje˛ zasadniczo scenariusz porównywalny ze scenariuszem z duzych˙ urzedów˛ . Takze˙ w tym przypadku migracja do Open Source jawi sie˛ jako bardzo godna polecenia. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 419

Rysunek 4.7: Przykład rachunku opłacalnosci´ migracji Windows NT –> Linux, sredni´ urzad,˛ ocena kosztów projektu

Równiez˙ w tego typu urzedzie˛ z oceny porównawczej rózn˙ ych wariantów migracji wynika dodatnia wartos´c´ kapitału. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 420

Rysunek 4.8: Przykład rachunku opłacalnosci´ migracji Windows NT –> Linux, sredni´ urzad,˛ ocena wartosci´ kapitału

Mała instalacja Obowiazuje˛ tu to samo, co w przykładach dla srednich´ i duzych˙ urzedów˛ . ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 421

Rysunek 4.9: Przykład rachunku opłacalnosci´ migracji Windows NT –> Linux, mały urzad,˛ ocena wartosci´ kapitału

4.8.6.6 Migracja kontynuacyjna

W przypadku tego typu migracji nie mozna˙ zidentyﬁkowac´ ani zbilansowac´ oszczedno˛ sci.´ Dla- tego prezentujemy tylko jeden z woluminów kosztów wynikajac˛ ych ze scenariusza. Zasadniczo za podstawe˛ przyjmuje sie˛ jednorazowe koszty zakupu. Równolegle przedstawiamy wyniki uwzgledniaj˛ ace˛ roczne opłaty za dzierza˙ we˛ uaktualnien´ dla Windows oraz MS Ofﬁce. Kazdorazo˙ wo pokazujemy wyliczenia dla duzych,˙ srednich´ i małych instalacji. Wersja opłat za dzierza˙ we˛ jawi sie˛ we wszystkich wyliczonych wariantach jako znacznie drozsze˙ rozwiazanie˛ (dodatkowe koszty w wysokosci´ około 250 tys. ¤[mała migracja], ponad około 1 miliona ¤[srednia´ migracja], do około 10 milionów ¤[duza˙ migracja]). Taki wzrost kosztów ma miejsce wyłacznie˛ za sprawa˛ odnawianych licencji na oprogramowanie. Wszystkie przedstawione koszty osobowe sa˛ kosztami wsparcia zewnetrzne˛ go.

Duza˙ instalacja ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 422

Rysunek 4.10: Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, duzy˙ urzad˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 423

Rysunek 4.11: Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, duzy˙ urzad,˛ alternatywna dzierza˙ wa Windows / Ofﬁce

Sr´ ednia instalacja

Rysunek 4.12: Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, sredni´ urzad˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 424

Rysunek 4.13: Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, sredni´ urzad,˛ alternatywna dzierza˙ wa Windows / Ofﬁce

Mała instalacja ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 425

Rysunek 4.14: Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, mały urzad˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 426

Rysunek 4.15: Przykład rachunku kosztów projektu migracji Windows NT –> Linux, mały urzad,˛ alternatywna dzierza˙ wa Windows / Ofﬁce

4.8.6.7 Migracja cze˛sciowa´

Punktowa migracja

Rysunek 4.16: Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Contact, duzy˙ urzad˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 427

Rysunek 4.17: Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Contact, sredni´ urzad˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 428

Rysunek 4.18: Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Contact, mały urzad˛

Migracja cze˛sciowa´ po stronie serwera

Rysunek 4.19: Przykład rachunku kosztów projektu migracji Windows NT do Linuksa po stronie serwera, duzy˙ urzad˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 429

Rysunek 4.20: Przykład rachunku kosztów projektu migracji Windows NT do Linuksa po stronie serwera, sredni´ urzad˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 430

Rysunek 4.21: Przykład rachunku kosztów projektu migracji Windows NT do Linuksa po stronie serwera, mały urzad˛

4.9 Przykładowa ocena koniecznosci´ oraz jakosci´ i strategii migracji

Przykładowa ocena obejmuje rachunek koniecznosci´ D (Koniecznosć)´ i jakosci´ czynników strategicznych Q (Jakosć)´ wynikajac˛ y z IT-WiBe 21. Uwzglednia˛ ona generalna˛ sytuacje˛ urzadów˛ i jest zgrubna˛ocena˛obecnej dyskusji dotyczacej˛ systemów alternatywnych. W ogólnych zarysach zebralismy´ argumenty uzasadniajace˛ kazdorazo˙ we wyliczenia. Niniejszy opis został ukierunkowany według stopni spełnienia celu wynikajace˛ go z katalogu kryteriów. Przykładowa ocena koniecznosci´ migracji daje wartosć´ > 59 <. Zatem z tego punktu widzenia mozna˙ generalnie poprzec´ zamiary migracyjne. Przykładowa ocena jakosciowo´ - strategiczna zamiarów migracyjnych daje wartosć´ > 66 <. Tym samym z ocenianych tu punktów widzenia maja˛ one takze˙ sens.

4.9.1 Kryteria koniecznosci´

Niniejsze kryteria (grupa 3 katalogu kryteriów) odnosza˛ sie˛ z jednej strony do koniecznosci´ zastapienia˛ starego systemu a z drugiej strony do przestrzegania przepisów administracyjnych i ustaw.

4.9.2 Kryteria jakoscio´ wo - strategiczne

W grupie 4 katalogu kryteriów wymienione sa˛ kryteria jakoscio´ wo - strategiczne dotyczace˛ zamierzen´ informatycznych. Odnosza˛ sie˛ one do priorytetu tych działan,´ do poprawienia jakosci´ pracy w ramach urzedu˛ i do oddziaływania na pracowników oraz „klientów“ administracji publicznej (otwartos´c´ na obywatela), jak równiez˙ do pokupnosci´ oprogramowania i bezpieczenstwa´ informatycznego. W ten sposób na pierwszym planie nie wystepuje˛ juz˙ stary system, lecz nalezy˙ dokonac´ sprawdzenia zamiaru informatycznego pod katem˛ czynników wymienionych w kryteriach. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 431

4.9.3 Analiza korzysci´

Kryteriów koniecznosci´ oraz jakosci´ / strategii nie mozna˙ sklasyfikowac´ za pomoca˛ analizy pienie˛znej.˙ Zamiast tego tworza˛one cze˛sć´ oceny korzysci.´ Wymaga to jakoscio´ wego opisu wpływu niniejszych kryteriów. Opis taki nalezy˙ z kolei zamienic´ w ocene˛ punktowa˛ kazde˙ go kryterium. Słuzy˙ do tego „skala ocen“ od 0 do 10. Punkty nalezy˙ pomnozy˙ c´ przez kazdorazo˙ wy stopien´ wazno˙ sci´ i zsumowac´ poszczególne obszary kryteriów. Jesli´ uzystkana wartosć´ jest wieksza˛ niz˙ (>) 50, wówczas zamiar informatyczny zwiazan˛ y ze sprawdzonym zakresem nalezy˙ zakwalifikowac´ jako „zalecany do realizacji“. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 432

Rysunek 4.22: Model oceny koniecznosci´ i jakosci´ zamiaru migracyjnego

Poszczególne kryteria opisane zostały w ponizszej˙ tabeli:

POZYCJA KRYTERIUM / OBJAS´ NIENIE WAZ˙ NOS´ C´ / WIBE PUNKTY 3 CZYNNIKI KONIECZNOS´ CI ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 433

3.1 Koniecznos´c´ zastapienia˛ starego systemu W 20 3.1.1 Wsparcie kontynuacji starego sytemu P 8

◦ Wsparcie dla systemu operacyjnego MS Windows NT wygasa z 2003 r.

◦ Nie bedzie˛ juz˙ Service Packs usuwajac˛ ych błedy˛ systemowe wazne˙ dla bezpieczenstwa.´

◦ Nie ma obsługi nowych Features takich jak, np. USB i inne.

3.1 Koniecznos´c´ zastapienia˛ starego systemu W 20 3.1.2 Stabilnos´c´ starego systemu P 7 3.1.2.1 Błedy˛ i awarie („downtime“)

◦ Podatnos´c´ starego systemu na błedy˛ znajduje sie˛ wcia˛z˙ w zakresie, który mozna˙ tolerowac.´

◦ Wskutek zastosowania nowych narzedzi˛ wspoma- gajac˛ ych administrowanie wzrosnie´ podatnos´c´ na błedy˛ , poniewaz˙ programisci´ przechodza˛ na nowe biblioteki, których jednak nie mozna˙ bez problemu zintegrowac´ z architektura˛ Windows NT.

3.1 Koniecznos´c´ zastapinia˛ starego systemu W 20 3.1.2 Stabilnos´c´ starego systemu P 4 3.1.2.2 Problemy z konserwacja,˛ waskie˛ gardło – personel

◦ Wsparcie zewnetrzne˛ dla systemu w przyszłosci´ bedzie˛ sie˛ wcia˛z˙ zmniejszac,´ poniewaz˙ takze˙ producent nie bedzie˛ go juz˙ gwarantowac´ a w tak zwanym miedzyczasie˛ na rynek wprowadzona zostanie kolejna platforma systemu operacyjnego. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 434

3.1 Koniecznos´c´ zastapienia˛ starego systemu W 10 3.1.3 Elastycznos´c´ starego systemu P 8 3.1.3.1 Rozbudowa / poszerzanie granic

◦ Nie bedzie˛ juz˙ implementacji nowych funkcji takich jak, np. obsługa USB, i innych.

◦ Nie bed˛ a˛ juz˙ rozwijane narzedzia˛ zapewniajace˛ współprace˛ z nowymi systemami.

◦ Wskutek zmieniajac˛ ych sie˛ architektur w przy- szłosci´ wystapi˛ a˛ z wieksz˛ a˛ siła˛ problemy z interfejsami do innych systemów informatycznych.

3.1 Koniecznosć´ zastapienia˛ starego systemu W 10 3.1.3 Elastycznosć´ starego systemu P 9 3.1.3.2 Kompatybilnosć,´ problemy z interfejsami aktualnie / w przyszłosci´

◦ Obecne działania dostosowujace˛ stary system wia˛z˙a˛ sie˛ z duzymi˙ nakładami

3.1 Koniecznosć´ zastapienia˛ starego systemu W 20 3.1.3 Elastycznosć´ starego systemu P 3 3.1.3.3 Przyjaznosć´ dla uzytk˙ ownika

◦ Obecnie nie sa˛ zakłócone

Tablica 4.59: Przykład analizy korzysci:´ czynniki koniecznosci´

POZYCJA KRYTERIUM / OBJAS´ NIENIE WAZ˙ NOS´ C´ / WIBE PUNKTY 4 CZYNNIKI JAKOS´ CIOWO - STRATEGICZNE ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 435

4.1 Priorytet zamiaru informatycznego W 5 4.1.2 Wkomponowanie w rozbudowe˛ informatyczna˛ całej P 5 administracji federalnej

◦ Zamiary KBSt w obszarze zastosowania produk- tów Open Source prowadzace˛ w kierunku realnego przekształcenia srodo´ wiska systemowego wraz ze wszystkimi ocenianymi funkcjami (administrowanie, konwersja plików i inne) mozna˙ w przypadku instniejac˛ ych produktów i zalezno˙ sci´ zrealizowac´ tylko warunkowo.

4.1 Priorytet zamiaru informatycznego W 10 4.1.3 Skutki dla partnerów komunikacyjnych P 7

◦ W przeciwienstwie´ do obecnej sytuacji, w ramach ukierunkowania sie˛ na wdrozenie˙ produk- tów OSS tworzona jest idealna podstawa komunikacyjna, która ułatwi komunikacje˛ wykraczajac˛ a˛ poza urzedy˛ .

4.1 Priorytet zamiaru informatycznego W 20 4.1.5 Uzaleznienie˙ od producenta P 8

◦ Wskutek zainstnienia heterogenicznej struktury informatycznej składajacej˛ sie˛ z produktów Mi- crosoft i OSS, wraz z jednoznacznym ukierunko- waniem sie˛ na wdrozenie˙ produków OSS odchodzi sie˛ od daleko idace˛ go uzaleznienia˙ od producenta. ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 436

4.4 Efekty dotyczace˛ pracowników W 5 4.4.1 Atrakcyjnos´c´ warunków pracy P 6 Mozna˙ tu zaobserwowac´ dwa oddzielne efekty:

◦ W obszarze administrowania powstana˛ nakłady wskutek wyraznie´ bardziej wymagajac˛ ych czynnosci´ wynikajac˛ ych z wdrozenia˙ produktów OSS, które wyraznie´ poszerza˛proﬁle kwaliﬁkacji personelu.

◦ W obszarze uzytko˙ wników da˛zy˙ sie˛ do rozwia-˛ zan,´ które umozliwi˙ a˛ wyrazne´ uproszczenie dzisiaj jeszcze po cze˛sci´ bardzo ograniczonej pracy w obszarze biurowego oprogramowania komuni- kacyjnego wykraczajacej˛ poza ramy produktu.

4.4 Efekty dotyczace˛ pracowników W 2 4.4.3 Powszechnos´c´ / dostepno˛ s´c´ wykształcenia P 3

◦ Z uwagi na wykształcenie i doswiadczenie´ wymagane dla obsługi obecnie stosowanych systemów nie ma tu problemów. Za to w przyszłosci,´ w przypadku silniejszego popytu na produkty OSS, moze˙ byc´ trudniej znalez´c´ odpowiednio wykształcony personel. Poniewaz˙ jednak nalezy˙ wyjs´c´ z załoze-˙ nia, ze˙ pracujac˛ y personel jest odpowiednio wy- szkolony, wystapieniem˛ tego efektu w administracji publicznej nie nalezy˙ sie˛ na razie zajmowac.´ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 437

4.5 Efekty zwiazane˛ z dostepno˛ sci´ a˛ dla obywateli W 2 4.5.4 Poprawa wizerunku P 6

◦ Projekty migracyjne powinny słuzy˙ c´ takze˙ integracji swiatów´ serwerów i klientów ze zwykłym dniem dniem pracy.

◦ Stopniowe przejscie´ do srodo´ wiska OSS umozliwi˙ łagodna˛ migracje˛ i pokaze˙ w praktyce, ze˙ moz-˙ liwe jest przeniesienie woli politycznej w kierunku OSS.

◦ W sredniej´ i długiej perspektywie czasu ujawnia˛ sie˛ w całej administracji oraz obywatelom wyrazne´ wartosci´ dodane wynikajace˛ z projektów migracyjnych.

4.6 Powszechnos´c´ / dostepno˛ s´c´ oprogramowania W 5 4.6.1 Stopien´ przenikniecia˛ rynku P 7

◦ Produkty, które nalezy˙ zastosowac´ sa˛ bez problemu dostepne˛ na rynku

4.6 Powszechnos´c´ / dostepno˛ s´c´ oprogramowania W 5 4.6.2 Niezalezne˙ wsparcie P 6

◦ Wsparcie dla wykorzystywanych produktów oferuja˛ oprócz producentów takze˙ liczne niezalezne˙ przedsiebiorstwa˛ ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 438

4.6 Powszechnosć´ / dostepno˛ sć´ oprogramowania W 5 4.6.3 Posiadane certyfikaty na oprogramowanie P 5

◦ Produkty, które nalezy˙ zastosowac´ dysponuja˛wła- sciwymi´ referencjami albo certyﬁkatami

4.6 Powszechnos´c´ / dostepno˛ s´c´ oprogramowania W 5 4.6.4 Dostepne˛ narzedzia˛ do administrowania oprogramo- P 5 waniem

◦ Narzedzia˛ administracyjne dostepne˛ sa˛ w wystarczajac˛ ym stopniu

4.7 Bezpieczenstwo´ informatyczne W 6 4.7.1 Bezpieczenstwo´ komunikacji P 7

◦ Komunikacja z wewnetrzn˛ ymi i zewnetrzn˛ ymi partnerami jest dobrze zagwarantowana

4.7 Bezpieczenstwo´ informatyczne W 6 4.7.2 Bezpieczenstwo´ aplikacji P 6

◦ Aplikacje sa˛ dojrzałe.

4.7 Bezpieczenstwo´ informatyczne W 6 4.7.3 Zabezpieczenie przed awariami P 7

◦ Systemy OSS sa˛ w kazdym˙ przypadku lepiej za- bezpieczone przed awariami ROZDZIAŁ 4. OCENA WYDAJNOSCI´ EKONOMICZNEJ 439

4.7 Bezpieczenstwo´ informatyczne W 6 4.7.4 Zarzadzanie˛ bezpieczenstwem´ P 7

◦ Systemy OSS dysponuja˛ udokumentowanymi i dostepn˛ ymi dla wszystkich zainteresowanych mechanizmami bezpieczenstwa´

4.7 Bezpieczenstwo´ informatyczne W 6 4.7.5 Bezpieczenstwo´ inwestycji i planowania P 8

◦ Inwestycja jest pewna, produkty bed˛ a˛ dostepne˛ takze˙ w przyszłosci´ jeszcze przez typowy dla urze-˛ dów okres pieciu˛ lat. Systemy OSS pracuja˛ stabilnie a budowane w oparciu o nie procesy mozna˙ pewnie planowac.´

Tablica 4.61: Przykład analizy korzysci:´ czynniki jakoscio´ wo - strategiczne Rozdział 5

Zalecenia migracyjne

5.1 Ogólne wyjasnienia´

5.1.1 Droga do podjecia˛ decyzji

O zaleceniu migracji bad˛ z´ kontynuacji decyduja˛wyniki oceny ekonomicznej przygotowanej pod katem˛ długofalowym. Takze˙ wówczas, gdy z technicznego punktu widzenia mozliwe˙ jest bez ograniczen´ wybranie migracji całkowitej albo cze˛scio´ wej, w danych warunkach brzegowych wzgledy˛ ekonomiczne moga˛ sprawic,´ ze˙ w/w drogi migracji bed˛ a˛ mało sensowne. Dlatego ze wzgledu˛ na rózne˙ zwiazki˛ pomiedzy poszczególnymi składnikami oraz systemami infrastruktury informatycznej i swiata´ aplikacji, podczas szukania własciwej´ decyzji trzeba stale uwzlednia˛ c´ perspektywe˛ długofalowa.˛ Przy tym ocena pod katem˛ wprowadzenia oprogramowania Open Source nie rózni˙ sie˛ od zwykłych analiz w branzy˙ informatycznej, np. w kontekscie´ konsolidacji osprzetu˛ i oprogramowania. Strategiami, którymi w równym stopiniu nalezy˙ sie˛ zazwyczaj kierowac´ w administracji publicznej i w gospodarce sa:˛

◦ oparte o otwarte standardy i specyﬁkacje sci´ sle´ dostosowane do siebie platformy systemowe i platformy aplikacji, w razie potrzeby z dodatkowym wykorzystaniem specjalizowanych produktów integrujac˛ ych

◦ oparte o charakterystyczne dla producenta (bez udostepnian˛ ych albo tylko z cze˛scio´ wo udostepnian˛ ymi interfejsami i specyﬁkacjami) sci´ sle´ dostosowane do siebie platformy systemowe i platformy aplikacji, w razie potrzeby z wykorzystaniem produktów integrujac˛ ych od producenta.

440 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 441

◦ rozwiazania˛ wyspowe do punktowego pokrycia procedur specjalistycznych i specjalistycznych aplikacji (przestarzałe).

Poniewaz˙ oprogramowanie Open Source od swojego poczatku˛ zwiazane˛ jest ze stosowaniem otwartych standardów, powstaje dodatkowy szczególny wariant:

◦ oparte o otwarte standardy i specyﬁkacje dostosowane do siebie platformy systemowe i platformy aplikacji z wykorzystaniem otwartego kodu zródło´ wego wielokrotnego uzytku.˙

Podczas, gdy decyzja o punktowym zastosowaniu szeroko dostepne˛ go produktu o otwartym kodzie zródło´ wym, jakim jest np. serwer WWW Apache, moze˙ byc´ z reguły bardzo pragmatyczna i sprawnie podjeta,˛ decyzja dotyczaca,˛ np. wprowadzenia oprogramowania Open Source na całej powierzchni i zastapienia˛ własnoscio´ wych wysp, z uwagi na swoje długofalowe skutki wymaga podejscia´ metodycznego. Składa sie˛ ono z nastepuj˛ ac˛ ych elementarnych kroków:

◦ opracowanie wspólnej strategii informatycznej z uwzglednieniem˛ istniejac˛ ych ﬁnanso- wych, organizacyjnych, uwarunkowanych innowacyjnosci´ a˛ oraz osobowych celów

◦ zdeﬁniowanie przyszłej strategii dla platformy Open Source z uwzglednieniem˛ długoter- minowego rachunku ekonomicznego pod katem˛ zastosowania wolnych i komercyjnych standardowych produktów (model OSS kontra model COLS, patrz rozdział 5.1.2)

◦ ustalenie w katalogu Blueprint wszystkich standardów koniecznych do zabezpieczenia wewnetrznej˛ i zewnetrznej˛ mozliwo˙ sci´ ponownego zastosowania, jak tez˙ kompatybilnosci´

◦ wybór produktów spełniajac˛ ych wymagania

◦ zdeﬁniowanie zamiaru migracyjnego oraz zaplanowanie zwiazan˛ ych z nim czasu i akcji, jak tez˙ zapewnienie ﬁnansowania

W poszczególnych etapach nieniejszego procesu mozna˙ korzystac´ z juz˙ stosowanych w administracji publicznej metod i narzedzi˛ zgodnie z ponizszym˙ rysunkiem. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 442

Rysunek 5.1: Proces decyzyjny prowadzac˛ y do wdrozenia˙ OSS

5.1.2 Ogólne zalecenia

Z uwagi na rózne˙ punkty wyjscia´ (wraz z istnieniem rozwiaza˛ n´ wyspowych) i rózn˙ a˛ jakos´c´ produktu bardzo rzadko mozna˙ ogólnie wypowiadac´ sie˛ o zaletach ekonomicznych w/w strategii platform. Jednak generalnie obowiazuje˛ zasada, ze˙ wraz ze rosnac˛ ym stopniem integracji pro- duktów jednej platformy z wielu powodów rosnie´ łaczna˛ opłacalnos´c:´

◦ wskutek wyzszej˙ produktywnosci,´ w przypadku dobrze (brak awarii systemu) dostosowanych do siebie produktów

◦ wskutek rosnacej˛ mozliwo˙ sci´ ponownego zastosowania składników i rozwiaza˛ n,´ które rozwiniete˛ zostały za pomoca˛ jednakowej technologii Middleware

◦ wskutek oszczedno˛ sci´ w przypadku ujednoliczenia procedur zakupu i konserwacji albo umów kupna i konserwacji.

Ponadto obowiazuje˛ zasada, ze˙ wraz z rosnac˛ ym stopniem standaryzacji opartej na otwartych standardach łaczna˛ opłacalnos´c´ rosnie´ z wielu powodów:

◦ wskutek wprowadzenia konkurencji pomiedzy˛ produktami i rozwiazaniami˛

◦ wskutek mniejszego uzaleznienia˙ od producenta

◦ wskutek powstania w sumie szerszego rynku usług ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 443

Bezpieczenstwo´ inwestycji dla komercyjnych oferentów oprogramowania linuksowego wzrosło zwłaszcza (jednak nie wyłacznie)˛ wskutek przyjecia˛ SAGA (Standardy i Architektury dla Apli- kacji e-Government) i zastosowaniu własnych standardów wewnatrz˛ administracji publicznej. Znajduje to swoje odbicie w rosnacej˛ ofercie oprogramowania zarówno dla składników podstawowych jak i procedur specjalistycznych oraz sprawia, ze˙ mozliwy˙ staje sie˛ jeszcze do niedawna trudny scenariusz pełnej migracji. Wychodzac˛ z powyzsze˙ go załozenia˙ mozna˙ sformułowac´ nastepuj˛ ace˛ podstawowe zalecenia odnosnie´ zastosowania produktów o otwartym kodzie zródło´ wym:

◦ zaleca sie˛ przyjecie˛ kryterium opłacalnosci´ jako obrazu przewodniego całej strategii informatycznej przy umiarkowanym uwzglednieniu˛ czynników innowacyjnosci´ i oraganizacji

◦ zaleca sie˛ wykorzystanie systemu operacyjnego GNU/Linux jako podstawowej platformy informatycznej dla wszystkich obszarów zastosowan,´ w razie gdy adekwatne sa˛ załozenia˙ dotyczace˛ migracji pełnej albo cze˛scio´ wej (patrz rozdział 5.2 i 5.4)

◦ zaleca sie˛ wykorzystanie otwartych standardów uznanych w równym stopniu przez prze- mysł informatyczny i Społecznos´c´ Otwartego Oprogramowania (Open Source Commu- nity) jako podstawy dla dokonania wyboru i integracji oprogramowania w celu unikniecia˛ zewnetrzn˛ ych zalezno˙ sci´ od producenta

◦ zaleca sie˛ przeprowadzenie oceny ekonomicznej pod katem˛ projektu w procesie decyzyjnym zwiazan˛ ym z zastosowaniem otwartych i komercyjnych produktów linuksowych. (patrz rozdział 4).

Zasadniczo przejscie´ na platforme˛ OSS- / COLS moze˙ okazac´ sie˛ ekonomicznie bardziej sen- sownym (opłacalnym) wariantem niz˙ migracja kontynuacyjna do nowej wersji produktów Mi- crosoftu. Odejscie´ od kosztów licencji lub ich redukcja moze˙ w wielu przypadkach prowadzic´ do bezposrednich´ (pienie˛zn˙ ych) oszczedno˛ sci,´ np. w przypadku:

◦ migracji cze˛scio´ wej po stronie serwera, połaczonej˛ z konsolidacja˛ osprzetu˛ i oprogramowania, gdy dostepna˛ jest juz˙ wiedza z zakresu rozwiaza˛ n´ uniksowych (Know-how) oraz systemy uniksowe

◦ punktowego zastapienia˛ członków wczesniejszej´ rodziny Back-Ofﬁce (obecnie .NET En- terprise Server), przykładowo serwerów Exchange albo SQL, zwłaszcza przy duzych˙ i rosnac˛ ych ilosciach´ uzytko˙ wników i zwiekszaj˛ ac˛ ych sie˛ zarazem opłatach licencyjnych ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 444

◦ migracji cze˛scio´ wej po stronie klienta z produktów MS Ofﬁce, gdy nie uniemozliwi˙ ona korzystania ze srodo´ wiska Ofﬁce jako biez˙ace˛ go srodo´ wiska dla makr lub aplikacji

W wielu innych scenariuszach wdroze˙ n,´ aby ocenic´ oszczedno˛ sci´ trzeba wzia˛c´ pod uwage˛ wymiar strategiczny, który został szczegółowo opisany w rozdziale „Ocena wydajnosci´ ekonomicznej“. W razie migracji obecnych platform do swiata´ Linuksa albo do nowej platformy Microsoftu nalezy˙ , z ekonomicznego punktu widzenia, w kazdym˙ przypadku zaplanowac´ nakłady na szkolenia. Poniewaz˙ realnie pojawia˛ sie˛ one w przypadku obydwu alternatywnych typów migracji, ten blok kosztów nalezy˙ oceniac´ dalece neutralnie, jako bezposrednio´ porównywalny. W kazdym˙ przypadku oznacza to, ze˙ dla obydwu alternatyw nalezy˙ uwzgledni˛ c´ koszty migracji istniejac˛ ych aplikacji specjalistycznych1. Poniewaz˙ podstawowe zalecenia nie moga˛ uwzglednia˛ c´ wymagan´ i warunków brzegowych konkretnej sytuacji wyjscio´ wej, dalsze zalecenia odnosza˛ sie˛ do rózn˙ ych scenariuszy. W rozdziale 5.2 opisana została całkowita migracja, w rozdziale 5.3 przedstawione zostały scenariusze dla kontynuacyjnego korzystania z dotychczasowych platform a w rozdziale 5.4 scenariusze dla srodo´ wiska mieszanego (migracja cze˛scio´ wa).

5.2 Całkowita „zastepuj˛ aca˛ migracja”

Zgodnie z załozeniami˙ niniejszego poradnika migracyjnego całkowita migracja ma miejsce wtedy, gdy nastepuje˛ wdrozenie˙ Linuksa jako systemu operacyjnego na poziomie wszystkich składni- ków infrastruktury informatycznej. Z powszechna˛ zamiana˛ systemu operacyjnego zwiazana˛ jest na ogół takze˙ zmiana na poziomie integracji i aplikacji wskutek wykorzystania produktów zgodnych z SAGA, poniewaz˙ zwłaszcza potrzebne do tego produkty Java nie rozpowszechniły sie˛ dotychczas na platformach windowsowych2 w oczekiwany sposób. Przy całkowitej migracji mozna˙ zasadniczo korzystac´ z dwóch wariantów oprogramowania, które czesto˛ stosowane sa˛ razem:

◦ OSS: Otwarte Oprogramowanie (albo Wolne Oprogramowanie)3: oprogramowanie z po-

1Niniejszy blok kosztów nie jest uwzglednian˛ y w ocenie zamieszczonej w poradniku migracyjnym. Z reguły konieczne sa˛ tu bardzo specyficzne analizy w przypadku kazde˙ go urzedu,˛ których nie mozna˙ dostarczyc´ w ramach poradnika. W poszczególnym przypadku zaprezentowane w ocenie ekonomicznej wymiary moga˛ sie˛ zmieniac´ po właczeniu˛ stwierdzonych koszów migracji aplikacji specjalistycznych. 2W tym przypadku koniecznosć´ zastapienia˛ nie dotyczy rozpowszechnionych takze˙ pod Windows aplikacji we- bowych z modelu (L)AMP. 3Patrz definicja z rozdziału 2 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 445

wszechnie dostepn˛ ym kodem zródło´ wym i bezpłatne, rozwijane przez Społecznos´c´ Otwar- tego Oprogramowania

◦ COLS: KOmercyjne Oprogramowanie Linuksowe – „KOOL“: linuksowe oprogramowanie komercyjne o otwartym kodzie zródło´ wym albo własnoscio´ we, jako oferta producentów oprogramowania.

Poniewaz˙ w wielu obszarach administracji intensywnie uzywa˙ sie˛ zarówno rozwinietych˛ we wła- snym zakresie i opertych na Windows procedur specjalistycznych, jak tez˙ opartych na ERP sys- temów zarzadzania˛ aplikacjami, całkowitego pokrycia wymagan´ za pomoca˛ oprogramowania Open Source w dajac˛ ym sie˛ przewidziec´ czasie mozna˙ oczekiwac´ tylko w obszarze infrastruktury. Uwzgledniaj˛ ac˛ wsparcie Linuksa przez dostepno˛ sć´ duzych˙ systemów uzytko˙ wych pochodzac˛ ych od takich producentów jak SAP albo Oracle, zastosowanie komercyjnego oprogramowania oraz rosnac˛ a˛oferte˛ oprogramowania linuksowego nalezy˙ w sumie ocenic´ pozytywnie, jesli´ chodzi o dalszy rozwój platformy Open Source, i liczyc´ sie˛ z jej dalszym rozwojem. Indywidualne wybicie sie˛ mozliwych˙ i zalecanych systemów i architektur oprogramowania rózni˙ sie˛ w zalezno˙ sci´ od intensywnosci´ informatycznej („obcia˛zenia“)˙ i stopnia wyspecjalizowania urzedów˛ . Z jednej strony odgrywaja˛ tu decydujac˛ a˛ role˛ skalowalnosć´ i niezawodnosć´ poszczególnych składników a z drugiej takze˙ nakłady zwiazane˛ z wdrozeniem.˙ Z tych powodów kazdorazo˙ wo wyróznione˙ i ocenione zostały zagadnienia dotyczace˛ duzych˙ oraz srednich´ , jak tez˙ specjalizowanych oraz małych urzedów˛ . Jako wprowadzenie zaprezento- wano najpierw ogólny, gatunkowy model zadan´ infrastrukturalnych.

5.2.1 Model architektury

W przypadku powszechnego zastosowania Linuksa jako platformy dla serwerów i aplikacji klienckich mozna˙ wyrózni˙ c´ – analogicznie do tradycyjnych architektur uniksowych i windowsowych – dwa typy architektur klienckich: Fat Clients i Thin Clients. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 446

Rysunek 5.2: Architektura systemu z linuksowym Fat Client

Konﬁguracja przedstawiona na rysunku 5.2 jest reprezentatywna dla wielofunkcyjnych sys- temów stacji roboczych w zdecentralizowanej architekturze na powszechnie dostepn˛ ym w sprzedazy˙ komputerze osobistym (Fat Client). Serwer spełnia zwykłe zadania infrastrukturalne a ponadto jest serwerem aplikacji w trójwarstwowej architekturze, patrz rysunek. Wybrane składniki pokrywaja˛ m. in. nastepuj˛ ace˛ obszary zadan:´

◦ komputer jako stacja robocza (desktop i Ofﬁce)

◦ Groupware (serwer poczty elektronicznej i kalendarza)

◦ systemy bazodanowe (serwer DBMS)

◦ serwer WWW

◦ składowanie plików (File Server) ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 447

◦ drukowanie (Print Server)

◦ autoryzacja

◦ usługi sieciowe (m. in. serwer DNS & DHCP).

Obszary na rysunku 5.2 zaznaczone graﬁtowa˛ kratka˛ moga˛ byc´ stosowane bez wzgledu˛ na wielkos´c´ i stopien´ wyspecjalizowania kazde˙ go urzedu.˛ Zwyczajne składniki systemu ocenione zo- stały w ponizszych˙ rozdziałach w zalezno˙ sci´ od danego scenariusza ich wykorzystania. Przewi- dziano scenariusze dla:

◦ duzych˙ i srednich´ urzedów˛

◦ specjalizowanych urzedów˛ swiadcz´ ac˛ ych usługi informatyczne

◦ małych urzedów˛ .

Uwaga: w przypadku ocenianych scenariuszy migracji nalezy˙ generalnie uwzgledni˛ c´ kilka ograniczen:´ Oceny techniczne pokazuja,˛ ze˙ z małymi wyjatkami˛ dla wszystkich produktów Microsoftu, które sa˛ cze˛sci´ a˛ składowa˛ analizowanej sytuacji wyjscio´ wej (patrz rozdział 2.2.1), dostepne˛ sa˛ alternatywne rozwiazania˛ OSS bad˛ z´ COLS umozliwiaj˙ ace˛ migracje˛ zastepuj˛ ac˛ a.˛ Krytycznymi punktami sa:˛

◦ kompatybilnosć´ pomiedzy˛ OpenOffice.org / StarOffice a MS Office nie jest pełna. Ma to szczególny wpływ na kazde˙ go uzytko˙ wnika, który musi czesto˛ tworzyc´ z innymi uzyt-˙ kownikami wpólne dokumenty. Jesli´ w takich przypadkach wykorzystywane sa˛ obydwa warianty pakietu Office, wówczas prowadzi to z reguły do problemów z formatowaniem.

◦ Chart-Engine z OpenOfﬁce.org bad˛ z´ ze StarOfﬁce nie wykazuje tych samych mozliwo˙ sci,´ co MS Excel Chart-Engine. Dotyczy to w szczególnosci´ tworzenia Charts w oparciu o tabele Pivot.

◦ nie istnieje jeszcze adekwatna alternatywa dla niektórych produktów takich jak MS-Project lub Visio.

Migracji z produktów Microsoftu do rozwiaza˛ n´ OSS i produktów COLS moga˛ jednak raczej przeszkadzac´ powody ekonomiczne niz˙ funkcjonalne. Dotyczy to zwłaszcza migracji deskto- pów: ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 448

◦ MS Office Zakres i złozono˙ sć´ migrowanych makr, skryptów, szablonów i dokumentów moze˙ sprawic,´ ze˙ przejscie´ na OpenOffice.org albo StarOffice stanie sie˛ nieopłacalne.

◦ MS Ofﬁce Professional Analogiczny problem z konwersja˛ dotyczy MS Access i aplikacji Access, które trzeba zastapi˛ c,´ uzywan˙ ych czesto˛ do automatyzacji prostych procesów.

◦ aplikacje specjalistyczne W zalezno˙ sci´ od stopnia wykorzystania natywnych windowsowych aplikacji specjalistycznych, w niekorzystnym przypadku migracja zastepuj˛ aca˛ moze˙ byc´ niemozliwa˙ do czasu, gdy dostepne˛ bed˛ a˛ alternatywne produkty. (patrz rozdział 5.3). Dotyczy to takze˙ aplikacji tworzonych w oparciu o MS Exchange i wykorzystujac˛ ych go jako runtime environment.

5.2.1.1 Stacje robocze

Praca stacji roboczych odbywa sie˛ w oparciu o Linuksa. W tym miejscu nie mozna˙ zalecic´ okreslonej´ dystrybucji (patrz 0). Decyzje˛ nalezy˙ podja˛c´ dla konkretnego przypadku i w zalezno˙ sci´ od specyficznych wymagan´ danej administracji. Do zastosowan´ w obszarze biura mozna˙ polecic´ zarówno OpenOffice.org, jak i StarOffice. Decyzja odnosnie´ wyboru tego lub innego produktu zalezy˙ od specyficznych wymagan´ danego urzedu.˛ Tak samo jak Microsoft Office, StarOffice i OpenOffice.org oferuja˛ aplikacje niezbedne˛ w codziennej pracy (edytor tekstu, arkusz kalkulacyjny, kreator prezentacji) i pokrywaja˛ wymagania co do funkcjonalnosci.´ Dla produktu COLS, jakim jest StarOffice Suite, firma Sun stworzyła bad˛ z´ zaimplementowała dodatkowe składniki (czcionki TrueType, własne sprawdzanie pisowni, dodatkowe szablony oraz galerie˛ zdje˛c,´ baze˛ danych ADABAS). W przeciwienstwie´ do tego OpenOffice.org jest członkiem rodziny OSS i nie wymaga kosztów licencyjnych. Róznice˙ funkcjonalne i techniczne pomiedzy˛ tymi obydwoma pakietami biurowymi sa˛ marginalne. Kolejnym wazn˙ ym interfejsem dla uzytko˙ wników jest własciwy´ system desktopowy. W dystrybucjach Linuksa zaimplementowane sa˛ na ogół gotowe desktopy, kóre tak samo jak w przypadku desktopu Windows zawieraja˛ najistotniejsze aplikacje. Dwoma najwazniejszymi˙ przedstawicielami systemów desktopowych sa˛ KDE i GNOME. Wybór systemu desktopowego jest w pierwszej kolejnosci´ odpowiedzia˛na pytanie o własny gust i kazdorazo˙ we preferencje wzgledem˛ okreslon´ ych aplikacji. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 449

5.2.1.2 Serwer WWW

Serwer Apache (patrz takze˙ rozdział 3.11.4) jest obecnie miernikiem udostepniania˛ tresci´ w In- ternecie i Intranecie. Elastycznos´c´ uzyskana dzieki˛ modularnej budowie i ilos´c´ dostepn˛ ych mo- dułów uczyniły go czołowym produktem na rynku serwerów WWW. Składnik ten odznacza sie˛ wieloletnim czasem stosowania w duzych˙ produkcyjnych srodo´ wiskach, stabilnosci´ a,˛ pełnymi funkcjami bezpieczenstwa´ i dostepn˛ ym, szerokim, profesjonalnym wsparciem, które mozna˙ sobie dowolnie wybrac.´

5.2.1.3 Składowanie plików

Dla usług zwiazan˛ ych z plikami wewnetrz˛ srodo´ wiska systemowego opartego na Linuksie zalecany jest sprawdzony sieciowy system plików (NFS). Tradycyjnie jest on stosowany w sieciach uniksowych do składowania plików przez siec.´ NFS jest standardowo uzywan˙ ym protokołem, gdy trzeba współdzielic´ katalogi z rózn˙ ych systemów uniksowych. Uzytko˙ wnikom mozna˙ udostepnia˛ c´ potrzebne katalogi za pomoca˛centralnych albo zdecentralizowanych serwerów. Ekspor- towane drzewa katalogów automatycznie przypisywane sa˛ uzytko˙ wnikom pracujac˛ ym na danej stacji roboczej. Do ﬁzycznego zapisywania danych na systemach dysków własciwych´ serwerów zaleca sie˛ skorzystanie z systemów plików XFS i EXT3. Obydwa systemy obsługuja˛ Journaling, kwotowanie i przydzielanie praw dostepu˛ na poziomie katalogu i pliku.

5.2.1.4 Drukowanie

Do udostepniania˛ usług drukowania zaleca sie˛ wyłacznie˛ „Common UNIX Printing System (CUPS)“. Jest on wyrózniaj˙ ac˛ ym sie˛ systemem praktycznie we wszystkich systemach uniksowych i de - facto standardem we wszystkich duzych˙ dystrybucjach (SuSE, Debian, RedHat, itd.). Usługa drukowania CUPS oferuje wszystkie konieczne funkcje do udostepniania˛ infrastruktury wydruku. CUPS obsługuje wiele rózn˙ ych drukarek i jest w stanie udostepnia˛ c´ konkretnym uzyt-˙ kownikom specyﬁczne opcje drukowania. CUPS oparty jest na Internet Printing Protocol, zdeﬁ- niowanym, nowym standardzie wydruku zarówno w sieci lokalnej (LAN), jak i w sieci rozległej (WAN, Internet).

5.2.1.5 Usługi sieciowe

Usługi tworzace˛ infrastrukture˛ dla sieci opartych o protokół TCP/IP sa,˛ z uwagi na swoje uniksowe pochodzenie, standardowo dostepne˛ w ramach oprogramowania Open Source. Do realiza- ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 450

cji Domain Name System zelecana jest implementacja referencji BIND (Berkeley Internet Name Domain), do obsługi DHCP równiez˙ wskazana jest implementacja referencji z Internet Software Consortium.

5.2.2 Sr´ ednie i duze˙ urzedy˛

Srednie´ i duze˙ urzedy˛ odznaczaja˛ sie˛ swoimi szczególnymi architekturami informatycznymi i potrzebuja˛ w niektórych obszarach zastosowan´ innych zalecen´ migracyjnych niz˙ mniejsze pla- cówki. Pocza˛wszy od pewnej wielkosci,´ urzedy˛ dysponuja˛ na ogół zarówno architekturami zde- centralizowanymi, jak tez˙ centralnymi. Pierwsze sa˛najcze˛sciej´ wykorzystywane w urzedach˛ przy procedurach centralnych (ERP, analiza cost / output, itd.). Poszczególnym składnikom systemu, w oparciu o które realizowane sa˛ procedury centralne, stawiane sa˛ szczególnie wysokie wymagania odnosnie´ bezpieczenstwa´ informatycznego, wydajnosci´ i skalowalnosci.´ Wewnetrznie˛ definiowane standardy jakosci´ wymuszaja˛gwarancje˛ wysokiej niezawodnosci´ i intensywnej opieki uzytko˙ wników nad centralnymi składnikami. Wykonanie tego typu zadan´ mozna˙ zagwarantowac´ tylko poprzez intensywne stosowanie platform do zarzadzania˛ systemem, w szczególnosci´ do monitorowania systemu i sieci. Zdecentralizowane architektury wystepuj˛ a˛ w urzedach˛ przede wszystkim w przypadku komunikacji biurowej, edycji dokumentów i specyficznych aplikacji specjalistycznych. Czesto˛ zatem na poziomie działu stosowane sa˛ zdecentralizowane systemy bazodanowe, poczty elektronicznej oraz systemy plików. Systemy te wymagaja˛szczególnych mechanizmów replikacji i zde- centralizowanego administrowania systemem. Do realizacji specyficznych wymagan´ technicznych i wymagan´ zwiazan˛ ych z architektura,˛ oprócz składników wymienionych w rozdziale 5.2.1 zalecane sa˛ zwłaszcza składniki dostosowane do szczególnych wymagan´ duzych˙ srodo´ wisk. Odnosnie´ zalecen´ dotyczac˛ ych oceny ekonomicznej w przypadku migracji zastepuj˛ acej˛ w duzych˙ i srednich´ urzedach˛ patrz rozdział 4.6.1 oraz 4.8.6.5. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 451

Rysunek 5.3: Zalecana architektura IT w duzym˙ urzedzie˛ w przypadku całkowitej „zastepuj˛ acej˛ migracji“

5.2.2.1 Systemy zarzadzania˛ bazami danych

Wymagania wzgledem˛ systemów zarzadzania˛ bazami danych wewnatrz˛ duzych˙ centralnych architektur informatycznych rózni˙ a˛ sie˛ zwłaszcza z uwagi na stabilnosć,´ wydajnosć´ i bezpieczen-´ stwo. Z czystych stystemów bazodanowych nalez˙ac˛ yh do rodziny Open Source, wiekszym˛ urze-˛ dom zaleca sie,˛ ze wzgledu˛ na spełnienie wymagan,´ stosowanie SAP DB. SAP DB była i jest udostepniana˛ przez SAP (patrz rozdział 3.13.4) jako certyfikowana platforma dla systemu R/3 i jego nastepców˛ oraz jest stosowana we własnych produktach jako kluczowa technologia. Zakres funkcji w/w bazy danych obejmuje oprócz obsługi transakcji takze˙ Trigger i Stored Procedures. Jesli´ wymagania sa˛ wieksze,˛ wzglednie˛ potrzebne sa˛ funkcje uzupełniajace,˛ wówczas godne polecenia sa˛standardowe linuksowe produkty komercyjne (COLS). Obecnie wielu producentów oferuje tego typu produkty, m. in. produkty IBM (DB2) albo Oracle. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 452

5.2.2.2 Groupware

Dobrze skalowalnym rozwiazaniem˛ opartym na Linuksie i odpowiednim dla duzych˙ srodo´ wisk jest Samsung Contact (produkt COLS). Z uwagi na swoja˛ architekture,˛ która składa sie˛ z wielu niezalezn˙ ych od siebie komponentów dajac˛ ych sie˛ w mysl´ skalowania horyzontalnego przydzielac´ do rózn˙ ych serwerów, spełnia on szczególne wymagania duzych˙ srodo´ wisk. Oprócz instalacji Single - Server, Samsung Contact obsługuje równiez˙ instalacje˛ dzielona˛ pomiedzy˛ wieloma stanowiskami i tym samym oferuje skalowalne rozwiazanie˛ takze˙ dla dzielonych stanowisk.

5.2.2.3 Usługi katalogowe

Z uwagi na swoja˛ centralna˛ role˛ polegajac˛ a˛ na zapewnieniu wydajnego zarzadzania˛ systemem i bezpieczenstwa´ informatycznego usługi katalogowe odgrywaja˛ decydujac˛ a˛ rola˛ przy integracji aplikacji i systemów z platformami. Wraz z rosnac˛ ym znaczeniem usług autoryzacji przeznaczonych dla aplikacji WWW, jak tez˙ z powodu rosnac˛ ych wymagan´ wzgledem˛ komfortu autoryzacji, znany juz˙ wczesniej´ model Directories (usługi katalogowe) oraz Meta-Directories został uzupełniony o kolejne składniki i przekształcony w całoscio´ wy system nazywany czesto˛ Identity Management (patrz takze˙ poniz-˙ szy rysunek). RYSUNEK DO POPRAWKI

Rysunek 5.4: Obszary zastosowan´ usług katalogowych na przykładzie platformy SunOne

Zasadniczo przy budowaniu usług katalogowych mozna˙ skorzystac´ zarówno z produktów OSS, jak i COLS. Mozna˙ tu wyrózni˙ c´ dwa istotne scenariusze zastosowan:´

1. Realizacja podstawowych funkcji umozliwiaj˙ ac˛ ych autoryzacje˛ oraz zarzadzanie˛ proﬁlami w oparciu o protokół LDAP. W tym przypadku alternatywe˛ OSS jaka˛ jest OpenLDAP nalezy˙ na ogół postrzegac´ jako wystarczajac˛ a˛ i opłacalna.˛

2. Realizacja rozszerzonych funkcji umozliwiaj˙ ac˛ ych zwiekszenie˛ wydajnosci´ zarzadzania,˛ np. poprzez obejmujac˛ a˛wiele aplikacji synchronizacje˛ wykorzystywanych danych lub autoryzacje.˛ ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 453

W tym przypadku mozna˙ generalnie wyjs´c´ z załozenia,˙ ze˙ zastosowanie komercyjnych produktów bedzie˛ korzystniejsza ﬁnansowo od własnego rozwiazania.˛

5.2.2.4 Zarzadzanie˛ systemem

Jesli´ chodzi o spełnienie zwiekszon˛ ych wymagan´ odnosnie´ zarzadzania˛ systemem narzuca sie,˛ np. skorzystanie z produktów Tivoli albo OpenView. Oprócz tych komercyjnych rozwiaza˛ n´ istnieja˛ inne mozliwo˙ sci´ zarzadzania˛ systemem z wykorzystaniem narzedzi˛ wchodzac˛ ych w skład systemu operacyjnego, które wykonuja˛ okreslone´ zadania (patrz rozdział 3.6).

5.2.3 Specjalizowane urzedy˛ swiadcz´ ace˛ usługi informatyczne

Urzedy˛ , które m.in. wystepuj˛ a˛ takze˙ jako specjalizowani dostawcy usług informatycznych w srodo´ wisku administracji, posiadaja˛ z reguły silnie scentralizowane architektury informatyczne. Czesto˛ realizuja˛ one swoje oferty w ramach centrów obliczeniowych oraz centrów danych i swiadcz´ a˛usługi informatyczne dla innych urzedów˛ , np. jako tak zwany „Application Service Pro- vider“ (ASP). Dominujace˛ centralne architektury słuz˙ace˛ realizacji konkretnych procedur specjalistycznych (ERP, . . . ) czesto˛ łacz˛ a˛ sie˛ z bardzo wysokimi wymaganiami odnosnie´ wydajnosci´ i skalowalnosci´ systemów. Dlatego stosuje sie˛ tam czesto˛ wysokowartoscio´ we i po cze˛sci´ drogie systemy oprzyrzado˛ wania przeznaczone do wykonywania automatycznych obliczen,´ np. Storage Area Networks (SAN) do zabezpieczania i archiwizacji danych. Takie specjalizowane urzedy˛ przykładaja˛ duz˙a˛ wage˛ do bezpieczenstwa´ informatycznego, wydajnosci´ i skalowalnosci.´ Zde- ﬁniowane tam standardy jakosci,´ które z reguły potwierdzane sa˛ z kazdym˙ klientem na pismie,´ wymagaja˛ wysokiej niezawodnosci´ systemu i intensywnej opieki uzytko˙ wników. W celu efektywnego zarzadzania˛ systemem stosuje sie˛ specjalne platformy do zarzadzania˛ systemem, które oferuja˛ wysoki stopien´ automatyzacji. Centra obliczeniowe wymagaja˛ dodatkowo efektywnego wsparcia systemu w przypadku First- i Second-Level Support łacznie˛ z rozległym zarzadzaniem˛ problemami. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 454

Rysunek 5.5: Zalecana architektura IT dla specjalizowanego urzedu˛ w przypadku całkowitej „zastepuj˛ acej˛ migracji“

5.2.3.1 System zarzadzania˛ bazami danych

Dla systemów zarzadzania˛ bazami danych obowiazuj˛ a˛ takie same zalecenia jak w rozdziale 5.2.2.1. Centra obliczeniowe wymagaja˛dodatkowo, by systemy dla okreslone´ go osprzetu˛ (SAN) oraz oprogramowanie były certyfikowane, gdyz˙ dopiero wówczas wolno je w nich stosowac.´ Wiele systemów bazodanowych opartych na Linuksie (SAP DB, Oracle, DB2, itd.) posiada juz˙ odpowiednie certyfikaty. Uzytko˙ wnicy centrów obliczeniowych moga˛ dodatkowo korzystac´ z certyfikowanych dystrybucji Linuksa jako podstawowego systemu oparacyjnego dla kazdorazo-˙ wych zastosowan.´ ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 455

5.2.3.2 Serwery aplikacji

Do realizacji skomplikowanych scenariuszy aplikacji czesto˛ stosuje sie˛ serwery aplikacji. W ramach specjalistycznych aplikacji implementuja˛ one skomplikowane procesy i reguły biznesowe jednoczesnie´ udostepniaj˛ ac˛ zewnetrzne˛ systemy. Serwer aplikacji musi byc´ w stanie zagwarantowac´ zarzadzanie˛ sesjami uzytko˙ wników, udostenia˛ c´ odpowiednie interfejsy zewnetrzn˛ ym aplikacjom oraz dysponowac´ koniecznymi, wysoce niezawodnymi rozwiazaniami˛ (Cluster, Load- Balancing, Failover). Oprócz znanych komercyjnych produktów (COLS) takich jak, p. IBM We- bsphere, BEA Weblogic, Oracle Application Server i kilku innych istnieje takze˙ mozliwo˙ s´c´ zastosowania rozwiazania˛ OSS. Projekt „JBoss“ oferuje kompletny Java - Applications - Server na bazie Open Source. Niniejszy serwer aplikacji obsługuje specyﬁkacje˛ J2EE, zawiera zintegrowany serwer WWW, JSP-Engine i Servlet-Engine, oferuje obsługe˛ Enterprise Java Beans i Clastering oraz liczne inne funkcje.

5.2.3.3 Zarzadzanie˛ systemem

W przypadku specjalizowanych urzedów˛ , z uwagi na cze˛scio´ wo porównywalne wymagania, obowiazuj˛ a˛ takie same zalecenia, jak w przypadku duzych˙ i srednich´ urzedów˛ (patrz rozdział).

5.2.4 Małe urzedy˛

Ze wzgledu˛ na swoja˛lokalna˛koncentracje˛ małe urzedy˛ posiadaja˛z reguły centralne architektury informatyczne, które jednak nie maja˛ charakteru centrów obliczeniowych. Duze˙ procedury na ogół wykonywane sa˛ poza własnym urzedem.˛ Zadania takie czesto˛ zlecane sa˛ centrom oblicze- niowym. Zdeﬁniowane standardy jakosci´ obowiazuj˛ ace˛ wewnatrz˛ urzedu˛ nie stawiaja˛ szczegól- nych wymagan,´ jesli´ chodzi o niezawodnos´c´ i opieke˛ uzytko˙ wników (normalne godziny pracy). Do zabezpieczania i archiwizacji danych stosowany jest na ogół standardowy osprzet.˛ Rzadko wykorzystuje sie˛ platformy zarzadzania˛ systemem. Preferuje sie˛ wykonywanie zadan´ za pomoca˛ pojedynczych narzedzi˛ i skryptów. Mniejsze placówki cechuja˛sie˛ małymi do srednich´ wymaganiami wzgledem˛ bezpieczenstwa´ informatycznego, wydajnosci´ i skalowalnosci.´ First i Second- Level Support jest czesto˛ połaczon˛ y i odbywa sie˛ na ogół bez narzedzi˛ obsługujac˛ ych zarzadzanie˛ problemami. Nie jest tak, ze˙ produkty OSS musza˛ byc´ zawsze dostosowane do rozmiaru realizowanych zadan.´ Skalowalne produkty takie jak Samsung Contact albo SunOne Directory Server moga˛ spełnic´ wszystkie wymagania mniejszych urzedów˛ . Nalezy˙ jednak wiedziec´ i zastanowic´ sie˛ nad ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 456

tym, ze˙ duze˙ rozwiazania˛ z reguły wymagaja˛ wiekszych˛ nakładów podczas instalacji i konﬁgu- racji. Odnosnie´ zalecen´ co do oceny ekonomicznej w przypadku migracji zastepuj˛ acej˛ dla duzych˙ i srednich´ urzedów˛ patrz rozdział 4.6.1 i 4.8.6.5.

Rysunek 5.6: Zalecana architektura IT dla małego urzedu˛ w przypadku całkowitej „zastepuj˛ acej˛ migracji“

5.2.4.1 Systemy zarzadzania˛ bazami danych

Oferta alternatywnych systemów bazodanowych Open Source jest bardzo róznorodna.˙ Wszyst- kie systemy baz danych, które szczegółowo ocenione zostały w rozdziale 3.13.4, dobrze nadaja˛ sie˛ do zastosowania w nakreslon´ ych tam ramach. W oparciu o funkcjonalne własciwo´ sci´ nie mozna˙ ogólnie, prosto i jednoznacznie wskazac´ SAP DB, MySQL albo PostgreSQL jako zalecanej bazy danych. Decyzja o wyborze tego bad˛ z´ ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 457

innego systemu bazodanowego musi zapas´c´ osobno w kazdym˙ przypadku, w zalezno˙ sci´ od planowanego srodo´ wiska programistycznego i runtime environment, zwłaszcza w kontekscie´ rozwoju aplikacji WWW i DB z udziałem PHP. Jednak z uwagi na scisł´ a˛ integracje˛ z tym jezykiem˛ programowania optymalnym rozwiazaniem˛ moze˙ byc´ MySQL.

5.2.4.2 Groupware

Oprócz zalecanego w przypadku duzych˙ urzedów˛ Samsung Contact, równiez˙ dla małych placó- wek skorzystanie z niego jest mozliwe.˙ Poza tym rozwiazaniem,˛ jesli´ chodzi o małe do srednie´ organizacje, w przyszłosci´ liczyc´ sie˛ moze˙ z pewnosci´ a˛ takze˙ Kroupware (patrz 3.14.4) stano- wiac˛ y adekwatna˛podstawe˛ pracy grupowej. Zaleta˛tego rozwiazania˛ jest głeboka˛ integracja GNU / Linux - Groupware - Client z desktopem KDE. W przyszłosci´ Kroupware oferowane bedzie˛ na licencji GPL i jako takie, z uwagi na apsekt pienie˛zn˙ y, rozwiazanie˛ to bedzie˛ stanowic´ interesujac˛ a˛ alternatywe.˛ W tym kontekscie´ nalezy˙ wskazac´ na to, ze˙ mozliwe˙ tu bedzie˛ korzystanie z wtyczki Open Source o nazwie „Ägypten“ bed˛ acej˛ narzedziem˛ zgodnym ze SPHINX i słuz˙ac˛ ym do szyfrowania i podpisywania poczty elektronicznej. Urzedy˛ , które ze wzgledu˛ na prace˛ w trybie ofﬂine nie potrzebuja˛rozwiaza˛ n´ umozliwiaj˙ ac˛ ych prace˛ grupowa,˛ moga˛takze˙ korzystac´ z klienta WWW. W takim przypadku mozliwe˙ rozwiazanie˛ stanowi równiez˙ phpGroupware.

5.2.4.3 Usługa katalogowa

Dla urzedu,˛ w którym wazne˙ informacje przekazywane sa˛ poprzez siec,´ zaleca sie˛ zastosowanie usługi katalogowej OSS jaka˛ jest OpenLDAP. Usługa ta moze˙ słuzy˙ c,´ m.in. do administrowania uzyko˙ wnikami, autoryzacji uzytko˙ wników, inwentaryzacji posiadanego osprzetu˛ i innych ustawien´ infrastrukturalnych (wpisy DNS, konﬁguracje DHCP, itd.). OpenLDAP oferuje wszystkie powszechne i konieczne funkcje (patrz rozdział 3.7.4) pełnowartoscio´ wej usługi katalogowej.

5.2.4.4 Zarzadzanie˛ systemem

Dla małych urzedów˛ zalecane jest przede wszystkim zastosowanie obszernych narzedzi˛ dostarczanych wraz z systemem operacyjnym GNU / Linux. Narzedzia˛ te (ssh, cron / at, pote˛zne˙ interpretatory pracujace˛ z linii polecen,´ Utilities i interpretowane jezyki˛ programowania) mozna˙ zaprze˛gna˛c´ do zautomatyzowania pracy Routine. Inne narzedzia˛ i produkty słuz˙ace˛ do administrowania systemem przedstawione zostały w rozdziale 3.6. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 458 5.3 Całkowita „kontynuacyjna migracja”

Całkowicie kontynuacyjna oznacza, ze˙ we wszystkich obszarach zachowana zostaje linia pro- duktów firmy Microsoft. Teoretycznie mozna˙ sobie wyobrazic´ dwie sytuacje wyjscio´ we, które uzasadniaja˛ tego typu migracje.˛ W zadnej˙ z opisanych ponizej˙ sytuacji powody techniczne nie odgrywaja˛jednak decydujacej˛ roli. Z małymi wyjatkami,˛ dla kazde˙ go z ocenianych wymagan´ istnieja˛ alternatywne rozwiaza-˛ nia techniczne, które moga˛ pracowac´ pod kontrola˛ Linuksa. W koncu´ to ekonomiczne powody przyczyniaja˛ sie˛ do realizacji całkowitej „kontynuacyjnej migracji“. Pierwsza z ocenianych tu sytuacji wyjscio´ wych została opisana w rozdziale 2 niniejszego poradnika jako srodo´ wisko systemu Windows NT 4 z Exchange 5.5, MS SQL Server 7, IIS 4 oraz Office 97 bad˛ z´ Office 2000. Jest ona nacechowana juz˙ bardzo wysokim stopniem integracji. Wielkosciami´ okreslaj´ ac˛ ymi stopien´ integracji sa˛ m. in.:

◦ ilos´c´ specjalistycznych procedur dostepn˛ ych tylko jako aplikacje windowsowe

◦ dostepno˛ s´c´ kodu zródło´ wego tych procedur

◦ głeboko˛ s´c´ integracji poszczególnych specjalistycznych procedur, zwłaszcza w srodo´ wisku MS Ofﬁce

◦ zakres wykorzystania specyﬁcznych dla Microsoftu

– srodo´ wisk programistycznych – interfejsów – jezyków˛ programowania

◦ ilosć´ makr i skryptów specyficznych dla MS Office (np. implementacja obejmujac˛ ych wiele działów Workflows).

Nakłady na migracje˛ zastepuj˛ ac˛ a˛ rosna˛ wraz ze wzrostem stopnia integracji. Ostateczna˛ wypowiedz´ na temat, jaki stopien´ integracji uzasadnia przeprowadzenie migracji kontynuacyjnej, mozna˙ sformułowac´ tylko po dokonaniu szczegółowym oceny pojedynczych migrowanych składników w oparciu o wyniki dokłebnej˛ oceny ekonomicznej. W praktyce, wskutek kroczace˛ go rozwoju platformy .NET, zainstnieje z czasem sytuacja wyjscio´ wa, która ujawni tak wysoki stopien´ integracji, przy którym migracja bedzie˛ znacznie ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 459

utrudniona. Takiemu rozwojowi sytuacji mozna˙ zapobiec dzieki˛ przeprowadzeniu we własci-´ wym czasie migracji cze˛scio´ wej (patrz rozdział 5.4).

Rysunek 5.7: Sytuacja wyjscio´ wa dla migracji kontynuacyjnej

Druga z ocenianych sytuacji wyjscio´ wych przedstawia srodo´ wisko informatyczne, w którym juz˙ dokonano pełnej migracji do Windows 2000 i ogólnej implementacji Active Directory (patrz rys. 5.7). Migracja przerpowadzona została całkiem niedawno, np. w roku 2002. W odniesieniu do podstawowego modelu architektury z zalecen´ migracyjnych (5.2.1) oznacza to, ze˙ w optymalnym przypadku mamy do czynienia z nastepuj˛ ac˛ ym modelem:

◦ stacje robocze: klienty Windows 2000 z Ofﬁce 2000

◦ serwer WWW: Internet Information Server 5

◦ serwer baz danych: MS SQL Server 2000

◦ Groupware / Messaging: Exchange 2000

◦ usługa katalogowa: Active Directory Service ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 460

◦ usługi infrastrukturalne: Windows 2000 Server (Advanced Server) (składowanie plików, drukowanie i usługi sieciowe).

Jesli´ pojedyncze elementy niniejszej architektury (jeszcze) nie sa˛ uzywane,˙ wówczas w ramach migracji cze˛scio´ wej mozna˙ w ich miejsce zaproponowac´ adekwatne rozwiazania.˛ Odpowiednie zalecenie na ten temat oraz dalsze wskazówki znajduja˛ sie˛ w rozdziale 5.4. Reguła ochrony inwestycji, w przypadku w/w sytuacji wyjscio´ wej uzasadnia to, zeby˙ znajdujace˛ sie˛ juz˙ w uzyciu˙ składniki nie podlegały migracji zastepuj˛ acej˛ ani cze˛scio´ wej w czasie najblizszych˙ 4 - 5 lat. Ponizej˙ wymienione zostały przyczyny, dla których tego typu sytuacja wyjscio´ wa mimo wszystko jest rozwazana˙ w zaleceniach migracyjnych:

◦ niniejszym urzedom˛ wskazuje sie˛ drogi minimalizacji wspomnianego wyzej˙ stopnia integracji i tym samym zalezno˙ sci´ od produktów Microsoftu.

◦ niniejszym urzedom˛ przekazuje sie˛ ponadto zalecenia odnosnie´ pózniejszej´ drogi migracji, w stopniu jaki jest obecnie mozliwy˙ .

◦ z długofalowego ekonomicznego punktu widzenia migracja kontynuacyjna nie jest szcze- gólnie zalecana, zwłaszcza w kontekscie´ uzalezniania˙ sie˛ od producenta. Migracja kontynuacyjna moze˙ miec´ sens przede wszystkim wówczas, gdy koszty migracji w obszarze specjalistycznych aplikacji opartych na platformie Microsoftu i wymagajac˛ ych przepro- gramowania w przypadku przejscia´ do Open Source, nie wykazuja˛ długofalowej rentownosci´ takiej migracji.

◦ odnosnie´ zalecen´ dotyczac˛ ych oceny ekonomicznej migracji kontynuacyjnej patrz rozdział4.6.2 i 4.8.6.6.

5.3.1 Minimalizacja stopnia integracji, zachowanie stopni dowolnosci´

Jak juz˙ wspomnielismy´ , celem w przypadku migracji kontynuacyjnej i korzystanie z Windows 2000 wraz z Active Directory powinna byc´ redukcja uzaleznienia˙ od produktów Microsoftu, tak by w przyszłosci´ mozna˙ było skorzystac´ ze wszystkich mozliwo˙ sci´ migracji zastepuj˛ acej.˛ Nalezy˙ zatem przestrzegac´ nastepuj˛ ac˛ ych zalecen:´ ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 461

Usłga katalogowa:

◦ wykorzystywanie Active Directory, jesli´ w ogóle, powinno miec´ miejsce tylko jako „Active Directory w minimalnej postaci“ (patrz rozdział 3.7.5).

◦ nie nalezy˙ stosowac´ AD jako zródła´ LDAP dla dodatkowych aplikacji (np. aplikacji webo- wych).

◦ dane osobowe dla AD nalezy˙ pozyskiwac´ z rózn˙ ych zródeł,´ np. przenoszac˛ je albo wypeł- niajac˛ z MetaDirectory.

◦ jesli´ zaplanowano role concept nalezy˙ unikac´ stosowania oprogramowania, które wymaga AD bad˛ z´ w przypadku którego AD jest podstawa˛ działania

Desktop

◦ nie nalezy˙ stosowac´ aplikacji MS Access. W zamian za to preferowane jest korzystanie z centralnej bazy danych oraz aplikacji napisanych, np. w PHP.

◦ sensowne jest zebranie i szczegółowe przeanalizowanie aplikacji VBA oraz ich skonsoli- dowanie, o ile nie zostało to juz˙ zrobione podczas migracji. W miare˛ mozliwo˙ sci´ nalezy˙ unikac´ wprowadzania nowych aplikacji z tego zakresu.

◦ wyboru aplikacji i zlecanie ich rozwoju nalezy˙ dokonywac´ w zgodnosci´ z SAGA (patrz rozdział 3.8).

◦ w miare˛ mozliwo˙ sci´ nie nalezy˙ korzystac´ z aplikacji innych producentów, których programy wymagaja˛do pracy produktów MS Ofﬁce jako jedynego runtime environment. Wy- jatkiem˛ sa˛ tu specjalistyczne aplikacje, jesli´ przejscio´ wo nie istnieja˛ dla nich rozwiazania˛ alternatywne.

◦ nalezy˙ sukcesywnie zastepo˛ wac´ aplikacje (specjalistyczne) wymagajace˛ do pracy produk- tów MS Ofﬁce.

Składowanie plików

◦ odtworzenie struktur uprawnien´ nalezy˙ wykonac´ za pomoca˛ skryptów (np. Perl). W przypadku pracy w srodo´ wisku graﬁcznym konieczne jest szczegółowe i pełne udokumento- wanie wszystkich ustawien´ konﬁguracyjnych. Poniewaz˙ z uwagi na znane ludzkie słabosci´ nie zawsze mozna˙ to zagwarantowac,´ lepsza˛ droga˛ jest skorzystanie ze skryptów. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 462

◦ jesli´ nie ma potrzeby uzywania˙ lokalnych grup, to nie nalezy˙ ich uzywa˙ c.´

Groupware / Messaging

◦ serwery Exchange 2000 nie powinny byc´ stosowane jako centralne Mail - Router. Za- miast nich nalezy˙ skorzystac´ z produktów OSS (np. Postﬁx, Sendmail), co ma na celu pozostawienie otwartej mozliwo˙ sci´ na równoległe korzystanie z wielu systemów poczty elektronicznej.

◦ w publicznych katalogach Exchange nie nalezy˙ stosowac´ aplikacji.

Aplikacje WWW

◦ ze wzgledu˛ na zgodnos´c´ z SAGA i dostepno˛ s´c´ rózn˙ ych alternatywnych rozwiaza˛ n´ nie nalezy˙ stosowac´ produków Microsoftu (patrz rozdział 3.9)

◦ nalezy˙ unikac´ autoryzacji domen stosujac˛ dodatkowy poziom autoryzacji. Dodatkowe ha- sło mozna˙ z reguły zaakceptowac´ i przede wszystkim uzasadnic´ z punktu widzenia bezpieczenstwa.´ W wyjatko˛ wych sytuacjach mozna˙ skorzystac´ z rózn˙ ych produktów OSS.

Zarzadzanie˛ systemem

◦ nalezy˙ zastosowac´ produkty innych producentów, którzy wspieraja˛ takze˙ rozwiazania˛ linuksowe (np. Tivoli).

Middleware

◦ jesli´ chodzi o srodo´ wisko programistyczne, w celu zwiekszenia˛ mozliwo˙ sci´ wielokrotnego wykorzystania kodu, nalezy˙ preferowac´ głebok˛ a˛ integracje˛ ze standardami zgodnymi z SAGA.

◦ w celu komunikacji i wymiany danych z zewnetrzn˛ ymi systemami nalezy˙ stosowac´ technologie˛ XML i Web Service (jesli´ pozwalaja˛ na to wzgledy˛ bezpieczenstwa,´ patrz rozdziały 4 i 5). ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 463

5.3.2 Inne scie´ zki˙ migracji

Jesli´ chodzi o dalsza˛ migracje,˛ nalezy˙ najpierw rozpatrzec´ migracje˛ na stacjach roboczych do Windows XP. Takze˙ tu obowiazuje˛ reguła ochrony inwestycji. Ze wzgledu˛ na nia,˛ w przypadku opisanej powyzej˙ sytuacji wyjscio´ wej, migracja na stacjach roboczych do Windows XP moze˙ nie byc´ zalecana. Jesli´ uwzgledni˛ sie˛ zasade˛ ochrony inwestycji, wówczas kolejna migracja powinna odbyc´ sie˛ najwczesniej´ po upływie 4 - 5 lat. Jesli´ zatem poprzedniej migracji dokonano w 2001 roku, wówczas nastepna˛ moze˙ odbyc´ sie˛ najwczesniej´ w roku 2005. Szczególnie urzedy˛ , które wczesniej´ postapiły˛ zgodnie z zaleceniami dotyczac˛ ymi minimalizacji uzaleznienia˙ od produktów Mi- crosoftu, musza˛ koniecznie sprawdzic´ czy w swoich technicznych i ekonomicznych warunkach powinny przeprowadzic´ migracje˛ zastepuj˛ ac˛ a˛ czy kontynuacyjna.˛ To samo dotyczy wszystkich innych urzedów˛ , które znajduja˛ sie˛ w takiej samej sytuacji wyjscio´ wej.

5.4 Migracja cze˛scio´ wa

5.4.1 Migracja punktowa

Migracja punktowa polega na trwałym zastapieniu˛ składnika systemu bed˛ ace˛ go produktem Mi- crosoftu przez rozwiazanie˛ OSS bad˛ z´ COLS, podczas gdy pozostała migracja jest migracja˛ kontynuacyjna.˛ W niniejszym rozdziale przedstawione zostały sensowne i wykonalne migracje punktowe. Najwazniejsz˙ a˛ migracja˛ punktowa˛ jest przy tym zastapienie˛ Exchange 5.5. Powodem takiego zastapienia˛ jest to, ze˙ Microsoft na dzien´ dzisiejszy wstrzymuje (Mainstream)4 Support dla Exchange 5.5. Alternatyna˛ oferowana˛ przez Microsoft w ramach migracji kontynuacyjnej jest Exchange 2000. Jednak migracja kontynuacyjna do Exchange 2000 dla wielu urzedów˛ nie wchodzi w rachube,˛ poniewaz˙ rozwiazanie˛ to wymusza zastosowanie Active Directory. Za pomoca˛ Exchange 2000 Microsoft przeniósł wewnetrzn˛ a˛ usługe˛ katalogowa˛ z Exchange 5.5 na zewnatrz,˛ skutkiem czego było stworznie Active Directory, który stał sie˛ centrum swiata´ opartego na Windows 2000. Dlatego Exchange 2000 moze˙ pracowac´ tylko z serwerem Windows 2000 lub jego nastepcami.˛ W zwiazku˛ z tym wiele urzedów˛ jest powaznie˙ zainteresowanych alternatywnym rozwiaza-˛ niem Groupware / Messaging, które zaoferuje podobny albo taki sam zakres funkcji, nie obsłu- gujac˛ ym AD i umozliwiaj˙ ac˛ ym dalsze korzytanie z klientów MS Outlook.

4http://support.microsoft.com/default.aspx?scid=fh;en-us;lifesrvr ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 464

Do dyspozycji jest wiele rózn˙ ych rozwiaza˛ n´ alternatywnych (patrz takze˙ ponizszy˙ rysunek). W przypadku wyzszych˙ wymagan´ wzgledem˛ kompatybilnosci nalezy˙ przede wszystkim rozwazy˙ c´ dwa rozwiazania˛ dla rózn˙ ych wymagan:´

◦ Samsung Contact

◦ Exchange4Linux

W obydwu przypadkach dzieki˛ dobremu połaczniu˛ MAPI mozna˙ kontynuowac´ korzystanie z Outlook-Client w ramach jego najistotniejszych funkcji. Dokładniejsze oceny techniczne i po- równanie funkcjonalnosci´ w/w rozwiaza˛ n´ znalez´c´ mozna˙ w rozdziale 3 („Techniczne opisy migracji“). Model rachunku ekonomicznego w przypadku migracji do Samsung Contact znajduje sie˛ w rozdziale „Ocena wydajnosci´ ekonomicznej“ (patrz rozdział 4).

Rysunek 5.8: Rózne˙ warianty zastapienia˛ Exchange w przypadku migracji cze˛scio´ wej

Samsung Contact, dokładnie tak jak Exchange, nie jest produktem OSS lecz nalezy˙ do kategorii własnoscio´ wego oprogramowania COLS. Migracja do Samsung Contact została juz˙ oceniona w zaleceniach dotyczac˛ ych całkowitej „zastepuj˛ acej˛ migracji“ (patrz rozdział 3.14.4). ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 465

Samsung Contact nadaje sie˛ zwłaszcza do duzych˙ specjalizowanych urzedów˛ stawiajac˛ ych szcze- gólne wymagania odnosnie´ skalowalnosci´ i bezawaryjnosci.´ Dla urzedów˛ do 500 uzytko˙ wników mozna˙ równiez˙ polecic´ tansze´ rozwiazanie˛ jakim jest Exchange4Linux. Jest to w istocie produkt OSS. Serwer dostepn˛ y jest jako Wolne Oprogramo- wanie, jedynie MAPI - Connector jest własnoscio´ wy i trzeba za niego zapłacic.´ Blizsze˙ informacje w rozdziale 3.14.4. W przypadku obydwu rozwiaza˛ n´ po stronie serwera potrzebny jest system operacyjny GNU / Linux. Przeprowadzenie migracji punktowej oferuje cały szereg korzysci:´

◦ bardziej przejrzysty i dajac˛ y sie˛ dobrze zaplanowac´ zakres migracji. Konieczne dostosowania mieszcza˛sie˛ w ograniczonych ramach, co jest istotna˛zaleta˛podczas planowania i kierowania projektem.

◦ istnieje mozliwo˙ s´c´ stopniowego jednoczesnego rozwijania pomysłów na prace˛ i zbieranie doswiadcze´ n´ oraz budowania platformy opartej o nowy system operacyjny.

◦ nakłady na szkolenia ponoszone sa˛ tylko na wykształconych juz˙ w danym kierunku admi- nistratorów. Doszkalani administratorzy moga˛ takze˙ posłuzy˙ c´ w dziale informatyki jako osoby przekazujace˛ innym swoja˛ wiedze.˛

W kontekscie´ Groupware i Messaging trzeba w tym miejscu zauwazy˙ c,´ ze˙ w przypadkach, gdzie potrzebne sa˛ funkcje Groupware, wyłaczna˛ migracja funkcji poczty elektronicznej staje sie˛ znacznie łatwiejsza˛ do wykonania. W rzeczy samej jest to rozwiazanie˛ juz˙ wielokrotnie wy- próbowane i preferowane. Kolejna mozliwo˙ sć´ migracji punktowej polega na zastapieniu˛ MS Office przez OpenOf- fice.org albo StarOffice. Nalezy˙ przy tym wzia˛c´ pod uwage˛ opisane juz˙ ograniczenia a zwłasz- cza takze˙ konsekwencje ekonomiczne. Migracja pakietu Office została juz˙ oceniona w rozdziale „Całkowita > >zastepuj˛ aca˛ migracja< <“ (5.2). Odnosnie´ zalecen´ wynikajac˛ ych z oceny ekonomicznej w przypadku migracji punktowej patrz rozdziały 4.6.3.1 i 5.4.

5.4.2 Cze˛scio´ wa migracja po stronie serwera

W nieniejszym rozdziale, na przykładzie szerokiej migracji po stronie serwera, prezentowany jest sensowny i godny polecenia scenariusz cze˛scio´ wej migracji po stronie serwera. Jako sytuacje˛ wyjscio´ wa˛ dla tej migracji przyjeto˛ srodo´ wisko Windows NT opisane w rozdziale 2.2.1. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 466

Zasadniczo w przypadku szerokiej migracji po stronie serwera swoje zastosowanie znajduja˛ zalecenia z całkowitej migracji (patrz rozdział 5. Róznice˙ wynikaja˛ z faktu, ze˙ strona klientów nadal składa sie˛ z systemów windowsowych. O zaleceniach dla:

◦ systemu baz danych,

◦ serwera WWW

◦ i usług sieciowych

mozna˙ przeczytac´ takze˙ w rozdziale 5. Główny wymóg wzgledem˛ migracji po stronie serwera dotyczy bezawaryjnej współpracy linuksowych serwerów z windowsowymi klientami po przeprowadzeniu migracji. Najwazniej-˙ szym zadaniem podczas samej migracji jest zastapienie˛ sposobu składowania plików, drukowania, usług sieciowych i usług logowania oraz migracja istniejac˛ ych struktur plików, uprawnien,´ jak tez˙ przeniesienie danych konﬁguracyjnych. W ramach oceny ekonomicznej okazuje sie,˛ ze˙ około 65% - 80% kosztów projektu zapisac´ mozna˙ po stronie oszczedno˛ sci.´ Dodatkowe nakłady lez˙ace˛ powyzej˙ tych wskazników´ wynikaja˛ w istocie z kosztów osobowych zwiazan˛ ych z pracami migracyjnymi. Dla tego typu migracji oznacza to, ze˙ z reguły nie da sie˛ przedstawic´ bezposredniej´ pienie˛znej˙ korzysci´ w porównaniu z migracja˛ kontynuacyjna.˛ O wiele bardziej o przyjeciu˛ projektu decydowac´ tu bed˛ a˛ miekkie˛ czynniki wyrazone˙ w formie kryteriów, takich jak koniecznos´c´ i strategia. O zaleceniach wynikajac˛ ych z oceny ekonomicznej w przypadku szerokiej migracji mozna˙ przeczytac´ w rozdziale 4.6.3.2 i 5.4.

Zarzadzanie˛ uzytk˙ ownikami i autoryzacja W celu zastapienia˛ kontrolera domen Windows NT 4.0 zaleca sie˛ skorzystanie z linuksowego serwera Samba w połaczeniu˛ z OpenLDAP. Współ- pracujaca˛ z Linuksem Samba umie całkowicie zastapi˛ c´ kontroler domen Windows. Szczególnie dotyczy to najnowszej Samby od wersji 3.0, która została juz˙ sukcesywnie przetestowana w projekcie migracyjnymi Federalnego Urzedu˛ ds. Karteli. Oferuje ona niemal nieograniczona˛ moz-˙ liwos´c´ połaczenia˛ klientów Windows 2000 z klientami Windows XP. Blizsze˙ informacje na ten temat znalez´c´ mozna˙ w technicznych opisach migracji w rozdziale 3.

Zarzadzanie˛ plikami i drukowanie Zgodnie z tym, co zostało juz˙ powiedziane, w przypadku zarzadzania˛ plikami, tylko Samba zapewnia bezawaryjne połaczenie˛ klientów windowsowych. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 467

Samba jest w stanie odwzorowac´ pod Linuksem serwer plików oparty na Windows NT. Uzyt-˙ kownicy klientów windowsowych moga˛ równie dobrze korzystac´ ze swoich proﬁlów i skryptów logowania znajdujac˛ ych sie˛ na serwerze Samba, jak ze swoich katalogów domowych oraz grupowych. Jesli´ chodzi o ﬁzyczny zapis danych na systemach dysków własciwych´ serwerów zaleca sie˛ korzytanie z systemów plików XFS i EXT3. Obydwa systemy plików (patrz 3.11.4) obsługuja˛ POSIX-ACL, Journaling i kwotowanie. Drukowanie powinno odbywac´ sie˛ za posrednictwem´ CUPS w połaczeniu˛ z Samba,˛ z która˛ CUPS jest optymalnie zintegrowany.

5.5 Drogi migracji

5.5.1 Szybka migracja

W niniejszym rozdziale przedstawione zostały powody uzasadniajace˛ przeprowadznie szybkiej migracji oraz przeanalizowano systuacje wyjscio´ we, w przypadku których zalecana jest tego typu migracja. Szybka migracja jest przeciwienstwem´ łagodnej migracji. Obydwie wspomniane drogi migracji maja˛ na celu doprowadzenie do całkowitej „zastepuj˛ acej˛ migracji“, to znaczy, ze˙ w przypadku obydwu dróg celem jest dojscie´ do linuksowego systemu operacyjnego. Szybkiej migracji nie cechuje, wbrew temu co sugeruje jej nazwa, szybkosć´ migrowania, lecz to, ze˙ migracje˛ te˛ wykonuje sie˛ w jednym kroku, w przejrzystych, precyzyjnie okreslon´ ych ramach czasowych. Szybka migracja ma zdefiniowany poczatek˛ (data rozpoczecia)˛ i zdefiniowany koniec (data zakonczenia).´ Wraz z koncem´ przypada poczatek˛ pełnej pracy w czystym linuksowym srodo´ wisku informatycznym. Przeprowadzenie szybkiej migracji stawia wysokie, a nawet bardzo wysokie wymagania wzgledem:˛

◦ organizacji projektu

◦ organizacji danego urzedu˛

◦ techniki

◦ ﬁnansowania

◦ administratorów ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 468

◦ uzytko˙ wników

Szczególnie nie wolno przy tym nie docenic´ wymagan´ dotyczac˛ ych administratorów i uzytko˙ w- ników. Ma to tym wieksze˛ znaczenie, im mniejszy dostep˛ maja˛ oni do wiedzy o nowym srodo-´ wisku informatycznym. Z drugiej strony zaleta˛ szybkiej migracji jest to, ze˙ administratorzy nie musza˛sie˛ przez dłuzszy˙ czas zajmowac´ dwoma rózn˙ ymi kierunkami IT. Moga˛oni we wzglednie˛ krótkim czasie (odpowienim do wymagan´ projektu) skoncentrowac´ sie˛ na nowym systemie. Inna˛ wazn˙ a˛ rzecza˛ jest to, ze˙ w krótkim okresie czasu dostepne˛ musi byc´ wymagane finan- sowanie. O tym kiedy i ile srodków´ finansowych nalezy˙ udostepni˛ c´ decyduje zakres i przede wszystkim stopien´ skomplikowania oraz róznorodno˙ sć´ aplikacji i systemów przeznaczonych do migracji. Aspekt ten współdecyduje o mozliwo˙ sci´ przeprowadzenia szybkiej migracji. Wysokie wymagania co do organizacji urzedu˛ koncentruja˛ sie˛ z jednej strony na dokształce- niu pracowników, którzy bed˛ a˛ dalej musieli sprostac´ swoim codziennym obowiazkom.˛ Oznacza to, ze˙ koniecznie nalezy˙ da˛zy˙ c´ do minimalizacji zakłócen´ w pracy urzedu.˛ Z drugiej strony musi byc´ zachowana biez˙aca˛ praca systemów informatycznych. Szczególnie migracja całego srodo-´ wiska serwerów stawia przed wszystkimi jej uczestnikami wysokie wymagania, gdyz˙ migracji pojedynczych usług nie da sie˛ dowolnie podzielic,´ administratorzy musza˛ zagwarantowac´ bie- z˙ac˛ a˛ prace˛ i jednoczesnie´ musza˛ zostac´ wdrozeni˙ do pracy z nowymi systemami. Niniejszym wymogom mozna˙ sprostac´ dzieki˛ własciwemu´ Rollout oraz pomysłom na migracje.˛ Mozna˙ to zrobic´ tworzac˛ takze˙ rówonległe srodo´ wisko informatyczne, jednak zwieksza˛ to wymagania techniczne i powoduje dodatkowe koszty. Z uwagi na wspomniane wysokie wymogi powstaje oczywiscie´ pytanie czy szybka migracja ma w ogóle sens, wzglednie˛ dla kogo ma ona sens i komu mozna˙ ja˛ polecic?´ Ponizej˙ wymienione zostały powody uzasadniajace˛ szybka˛ migracje:˛

◦ istnieje przymus migracji, co znaczy, ze˙ na przykład konczy´ sie˛ wsparcie dla starego systemu.

◦ intensywne, ale za to tylko jednorazowe a nie stopniowe, wieloletnie konfrontowanie ad- ministratorów i uzytko˙ wników z nowosciami.´

◦ administratorzy nie musza˛ przez długi czas pracowac´ w skomplikowanych heterogenicznych swiatach.´

Na jakich warunkach i dla kogo szybka migracja ma sens? ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 469

Jesli´ srodo´ wisko systemowe jest przejrzyste i nie jest ponad miare˛ „zawikłane“, wówczas warunek szybkiej migracji jest dobrze spełniony. Oznacza to, ze˙ aby spełnic´ zadania trzeba zastosowac´ tylko niektóre aplikacje i usługi. Nie musi przy tym chodzic´ jedynie o małe i proste w swojej strukturze urzedy˛ i organizacje. Dotyczy to na przykład takze˙ urzedów˛ i organizacji zajmujac˛ ych sie˛ bezpieczenstwem,´ w przypadku których wieksza˛ cze˛sć´ uzytko˙ wników wyposazona˙ jest w niewiele duzych˙ specjalistycznych aplikacji, gdyz˙ sa˛one najcze˛sciej´ zgromadzone na serwerze i tam wykonuja˛ przewazaj˙ ac˛ a˛ cze˛sć´ zadan.´ Dotyczy to jednak takze˙ małych oraz srednich´ urzedów˛ o niewielkiej liczbie specjalistycznych aplikacji, korzystajac˛ ych ze standartowej komunikacji biurowej i z MS Office w zakresie mało skomplikowanych dokumentów i szablonów (np. Urzad˛ Antymonopolowy). Kolejny dobry warunek dla szybkiej migracji spełniaja˛ urzedy˛ , w których administratorzy dysponuja˛ juz˙ konieczna˛ wiedza,˛ np. gdy zajmowali sie˛ w wolnym czasie systemami linuksowymi albo gdy wykorzystywane sa˛juz˙ pojedyncze linuksowe aplikacje i usługi (np. Mail Server pracujac˛ y pod Linuksem). Jesli´ do tego jeszcze współpracownicy wykazuja˛niezbedn˛ a˛otwartosć´ na nowosci´ i zainteresowanie Linuksem, sa˛ to wówczas równiez˙ warunki do przeprowadzenia szybkiej migracji.

5.5.2 Łagodna migracja

W niniejszym rozdziale opisane zostały powody i drogi łagodnej migracji. Jednak cóz˙ tak wła- sciwie´ oznacza pojecie˛ „łagodna migracja“? Jest to droga migracji, w przypadku której ustalony jest cel, jednak ramy czasowe okreslone´ sa˛ jedynie zgrubnie a poszczególne składniki migracji przewidziane sa˛ w oparciu o przedstawiony wyzej˙ model architektury. Powody wyboru drogi łagodnej migracji staja˛ sie˛ jasne, gdy spojrzymy na wymagania i uza- sadnienia szybkiej migracji:

◦ w urzedach˛ i placówkach dysponujac˛ ych małym budzetem˙ mozna˙ dostosowac´ wymagane koszty do stanu budzetu.˙

◦ mozna˙ sukcesywnie uzupełniac´ brakujac˛ a˛ wiedze˛ i w ten sposób oszczedza˛ c´ koszty. W przypadku łagodnej migracji mozna˙ wybierac´ pojedyncze składniki. Przeszkoleni przy tym administratorzy słuz˙a˛jako osoby przekazujace˛ swoja˛wiedze˛ innym osobom, dzieki˛ czemu w przypadku migracji kolejnych składników dysponuja˛ one juz˙ wiekszym˛ Know-how.

◦ mozna˙ stopniowo usuwac´ istniejace˛ przeciwnosci´ i rozwiewac´ uprzedzenia.

◦ złozone˙ struktury informatyczne mozna˙ rozbierac´ kawałek po kawałku. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 470

Ponizszy˙ rysunek pokazuje, w jaki sposób mogłaby wyglada˛ c´ łagodna migracja.

Rysunek 5.9: Łagodna migracja

Na poczatku˛ jako cel migracji nalezy˙ wybrac´ składnik, który daje sie˛ łatwo wyodrebni˛ c.´ W powyzszym˙ przykładzie jest to serwer DBMS. Nie chodzi tu o migraje˛ aplikacji bazodanowej, lecz o załozenie˙ równoległego DBMS. Nalezy˙ dysponowac´ podstawowa˛ wiedza˛ na temat tego serwera. Najpózniej´ z chwila˛ rozpoczecia˛ pierwszej migracji, a mianowicie migracji serwera WWW, z reguły potrzebny bedzie˛ serwer DBMS. Directory Server jest samodzielnym skład- nikiem, ale moze˙ byc´ ewentualnie stosowany w połaczeniu˛ z serwerem WWW i warunkowac´ migracje˛ Groupware. Nastepnie˛ wykonywana jest migracja zarzadzania˛ plikami i zastapienie˛ usług sieciowych. Na koncu´ migrowany jest desktop, po uprzednim, równoległym do migracji składników, przeprowadzeniu w tle migracji wszystkich aplikacji specjalistycznych i biurowych. W przypadku łagodnej migracji nie mozna˙ dowolnie wymieniac´ składników zwiazan˛ ych z poszczególnymi krokami; to, co jest ze soba˛ zwiazane,˛ powinno takim pozostac.´ Inna˛ wazn˙ a˛ rzecza˛ jest ustalenie realnej daty zakonczenia,´ tak by proces nie rozciagał˛ sie˛ zbytnio w czasie. Czas realizacji musi jednak uwzglenia˛ c´ złozono˙ s´c´ opieki i konserwacji a tym samym nakłady na prace˛ administratorów. Poniewaz˙ nakład zwiazan˛ y z administrowaniem w róznorodn˙ ym srodo-´ wisku informatycznym jest wyzszy˙ niz˙ w srodo´ wisku jednorodnym, cały proces migracji, takze˙ w przypadku łagodnej migracji, nie powinien przekroczyc´ 2 - 3 etapu zamiany oprogramowania ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 471

w łaczn˛ ym przewidywalnym horyzoncie czasowym.

Rysunek 5.10: Etapy zamiany oprogramowania w przypadku łagodnej migracji

Rysunek 5.10 pokazuje trzy etapy migracji. Po stronie serwera, w srodo´ wisku heterogenicznym, mozna˙ wykonac´ wzglednie˛ daleko idac˛ a˛ migracje˛ przede wszystkim korzytajac˛ z Samby, Terminalservices a takze˙ z mozliwo˙ sci´ kontynuacyjnego stosowania Outlooka jako klienta Gro- upware i Messaging. Dopiero na samym koncu,´ gdy wszystkie aplikacje specjalistyczne i biurowe przejda˛ rów- noległa˛ migracje,˛ mozna˙ rozpocza˛c´ migracje˛ desktopów, czyli migracje˛ po stronie klienta. W stopniu, w którym umozliwia˙ to zamiana oprogramowania specjalistycznego i biurowego, mozna˙ nawet zastanowic´ sie˛ nad skorzystaniem w kroku posrednim´ z przejscia´ na kliencie windowsowym z MS Office do OpenOffice.org albo StarOffice.

5.5.3 Krytyczne wyznaczniki sukcesu

Projekty migracyjne sa˛ z reguły skomplikowanymi i wielowarstwowymi operacjami. Dotyczy to zarówno całkowitych migracji (klienty i serwery), jak tez˙ cze˛scio´ wego (serwery) albo tylko ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 472 punktowego zastapienia˛ oprogramowania. Ponizszy˙ rysunek pokazuje wieloetapowy proces migracji w jego pojedynczych aspektach.

Rysunek 5.11: Model stopniowego procesu migracji

Aby mozna˙ było doprowadzic´ projekty migracyjne jako projekty informatyczne w ogólnosci´ i jako projekty innowacyjne w szczególnosci´ do szcze˛sliwe´ go konca,´ nalezy˙ z góry zdeﬁniowac´ krytyczne wyznaczniki sukcesu oraz dokonac´ ich oceny. Dla wszystkich uczestników sukces projektu migracyjnego ma miejsce dopiero wówczas, gdy osiagni˛ ety˛ zostanie zakładany cel bad˛ z´ wynik w zaplanowanych, wzglednie˛ uzgodnionych ramach czasowym i budzeto˙ wych. Wyrózni˙ c´ tu mozna˙ tak zwane czynniki miekkie,˛ których wkład jest nie do przecenienia w ostatecznym osiagni˛ eciu˛ sukcesu. Zalicza sie˛ do nich na przykład zadowolenie pracowników, bezawaryjna˛komunikacje˛ i tym samym unikanie bad˛ z´ redukcje˛ porazek,˙ frustracji oraz podwój- nej pracy, jak równiez˙ uzasadniony potrzebami wybór i naturalnie takze˙ akceptacje˛ nowego sro-´ dowiska informatycznego przez uzytko˙ wników. Niezaleznie˙ od wielkosci´ urzedu˛ i niezaleznie˙ od tego czy chodzi o migracje˛ zastepuj˛ ac˛ a˛czy kontynuacyjna,˛ z punktu widzenia autorów do osiagni˛ ecia˛ trwałego sukcesu projektu migracyjnego przyczyniaja˛ sie˛ wymienione ponizej˙ parametry. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 473

◦ sformułowanie jednoznacznych celów projektu migracyjnego

◦ właczenie˛ i ustalenie pozycji kierowniczych i decyzyjnych

◦ wczesne poinformowanie i właczenie˛ grup docelowych / pracowników

◦ uzyskanie wysokiego stopnia akceptacji srodo´ wiska docelowego wsród´ uzytko˙ wników

◦ strukturalne zaplanowanie czasu, projektu i zasobów oraz kontroli projektu

◦ działania organizacyjne przygotowujace˛ migracje˛ i wykształcenie wykwaliﬁkowanego ze- społu wdrazaj˙ ace˛ go projekt

◦ szczegółowe ustalenie sytuacji docelowej ze zdeﬁniowanymi funkcjonalnymi wymaganiami

◦ optymalny wybór produktów i usług

◦ najblizsze˙ i pózniejsze´ szkolenia

◦ zarzadzanie˛ jakosci´ a˛ i dokumentacja˛

Z wyznaczników sukcesu wynika, ze˙ projekty migracyjne nie koncz´ a˛sie˛ z chwila˛zakupu i zaimplementowania odpowiednich składników. Zarówno przed migracja˛ oraz w trakcie własciwych´ procesów migracyjnych, jak tez˙ w czasie pózniejszych˙ prac nalezy˙ uwzglenia˛ c´ daleko idace˛ zalezno˙ sci´ i czynnosci.´ W sumie projekty migracyjne mozna˙ uznac´ za zakonczone´ sukcesem i opłacalne tylko wtedy, gdy obok minimalizacji biez˙ac˛ ych kosztów umozliwi˙ a˛ one przynajmniej sprawniejsze wykonywanie zadan´ dzieki˛ nowoczesnej, zintegrowanej i funkcjonalnie ukierunkowanej informacji oraz komunikacji a takze˙ doprowadza˛ do ogólnego wzrostu elastycznosci,´ wydajnosci´ i gotowosci´ podczas realizacji obecnych i przyszłych zadan.´ Dalsze cele takie jak osiagni˛ ecie˛ niezalezno-˙ sci´ od producenta i / lub od platformy sa˛ centralnymi aspektami, które patrzac˛ dalekowzrocznie musza˛ sprostac´ wymaganiom oceny ekonomicznej. W nastepn˛ ych rozdziałach dokładniej opisano najistotniejsze kryteria sukcesu zdeﬁniowane dla projektów migracyjnych. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 474

5.5.3.1 Sformułowanie jednoznacznych celów

Podstawa˛kazde˙ go sukcesu projektu jest sformułowanie jednoznacznych celów. Nalezy˙ przy tym rozrózni˙ c´ strategiczne cele zarzadzania˛ (poziom motywacji) i cele na poziomie migracji serwe- rów (poziom widzialny). Nalezy˙ okresli´ c,´ dlaczego migracja powinna w ogóle miec´ miejsce a w nastepn˛ ym kroku, co chce sie˛ dzieki˛ niej uzyskac.´ Osobom, na które migracja bedzie˛ oddziaływac,´ kierownictwu urzedu˛ i niezbedn˛ ym wyko- nawcom, nalezy˙ przed rozpoczeciem˛ realizacji projektu otwarcie wskazac´ własciwy´ cel zamiaru migracyjnego. Takie sformułowanie celu tworzy podstawe˛ dla wszystkich dalszych działan,´ tak samo dla ukształtowania projektu i wyboru docelowego oprogramowania, jak i dla wyboru wewnetrzn˛ ych i zewnetrzn˛ ych wykonawców. Osiagni˛ ecie˛ pewnej niezalezno˙ sci´ od producenta bad˛ z´ platformy jest przy tym raczej ogólnym, ewentualnie nadrzedn˛ ym celem. Specyﬁcznymi dla urzedu˛ mogłyby byc´ na przykład nastepuj˛ ace˛ szczegółowe dane docelowe odnosnie´ migracji serwerów:

◦ migracja serwerów bez dostosowania i zamiany oprogramowania po stronie klientów (pełne przejecie˛ danych, proﬁlów uzytko˙ wników, struktur plików i katalogów z istniejac˛ ymi prawami dostepu)˛

◦ pełne zastapienie˛ oprogramowania po stronie klientów (równorzedne˛ zastapienie˛ aplikacji i funkcji oraz integracja z istniejac˛ a˛w urzedzie˛ siecia˛komputerowa˛bez wpływania na nia)˛

◦ migracja danych i struktur danych z zachowaniem aplikacji bazodanowych (odpowiedni wybór wolnych systemów bazodanowych)

◦ wymiana istniejac˛ ych aplikacji na stacjach roboczych za pomoca˛równorzedn˛ ych aplikacji (wprowadzenie łatwego w obsłudze, centralnego zarzadzania˛ systemem; uwzglednienie˛ składników bezpieczenstwa´ informatycznego odpowiednio do Bund Online 2005, np. PKI, autoryzacja poprzez certyﬁkat i cechy biometryczne)

◦ stworzenie adekwatnego systemu zastepcze˛ go dla zarzadzania˛ uzytko˙ wnikami i logowania

◦ bezawaryjna konwersja szablonów

5.5.3.2 Właczenie˛ i ustalenie szczebli kierowniczych i decyzyjnych

Szczebel kierowniczy i decyzyjny to kazdy˙ poziom, na którym podejmowane sa˛ kluczowe decyzje dotyczace˛ projektu migracyjnego bez bezposrednie´ go aktywnego udziału w projekcie. Z ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 475

drugiej strony kierownictwo projektu ma obowiazek˛ przygotowywania sprawozdan.´ Jaki dokład- nie to bedzie˛ poziom, zalezy˙ od specyﬁcznej sytuacji i priorytetu projektu w urzedzie.˛ Rola szczebla kierowniczego w sukcesie projektu jest czesto˛ niedoceniana. Jak pokazuje doswiadczenie,´ panuje zamiast tego przekonanie, ze˙ szczebel kierowniczy „nic albo bardzo mało rozumie, jesli´ chodzi o technike˛ informatyczna˛i komunikacyjna“.˛ Jednoczesnie´ insynuuje sie,˛ ze˙ kierownictwo urzedu˛ głównie „tylko“ zainteresowane jest tym, by otrzymac´ „działajac˛ y i opła- calny system“. Takie załozenie˙ jest jednak nieproduktywne. Szczebel kierowniczy i decyzyjny jest odpowiedzialny raczej za wytyczanie celów projektu migracyjnego dla urzedu˛ niz˙ za tworzenie i realizacje˛ samego przedsie˛wziecia.˛ Wynikaja˛ z tego kompetencje wprowadzania zmian w kontrakcie, wzglednie˛ nowych zapisów, które z reguły nalez˙a˛ do kierownictwa urzedu.˛ Projekt migracyjny musi najpierw w ogóle zostac´ uruchomiony. W tym celu konieczne jest, aby szczebel decyzyjny w oparciu o rozpoznane braki bad˛ z´ konkretne cele projektu (np. uniezaleznienie˙ sie˛ od producenta i platformy), wzglednie˛ rozpoznanie potrzeb na podstawie wymagan´ oddelegowanych pracowników sformułowało zlecenie projektu.

Komunikacja projektu jako decyzja kierownictwa Szczebel kierowniczy przyczynia sie˛ istotnie do sukcesu projektu przekazujac˛ wszystkim osobom zaangazo˙ wanym w projekt oraz pozostałym pracownikom informacje˛ o tym, ze˙ popiera ono projekt i na wszystkich etapach jego rozwoju bedzie˛ go nie tylko tolerowac´ ale takze˙ wspierac.´

Aktywne i zawczasu informowanie osób pracujacych˛ przy projekcie Kolejnym jednoznacznym i głównym zadaniem kierownictwa, które zaczyna sie˛ juz˙ na etapie przygotowywania projektu migracyjnego i które trzeba uwzgledni˛ c´ jest odpowiedzialnos´c´ za komunikacje˛ pomiedzy˛ pracownikami oraz motywowanie pracowników. Kierowanie odbywa sie˛ dzieki˛ komunikowaniu i z tego wzgledu˛ styl kierowania oraz komunikowania sa˛ ze soba˛ nierozerwalnie zwiazane˛ i wymagaja˛ szczególnie wysokich społecznych umiejetno˛ sci.´ Chodzi w tym o to, aby dla wszystkich osób zatrudnionych przy projekcie, jak i pozostałych osób uczestniczac˛ ych w migracji była ona przejrzysta. Nalezy˙ tu wymienic´ zarówno te obszary, w których zachodza˛ zmiany, jak tez˙ takie, które pozostana˛niezmienione. (Przykładowo na bazie istniejace˛ go pomysłu na prace˛ mozna˙ dokładnie opisac´ planowane zmiany oraz niezmienne elementy). Ponadto do informowania nalezy˙ wykorzystywac´ rózne˙ kanały komunikacyjne w ramach ogólnych konferencji, rozmów z pracownikami, warsztatów albo okólników bad˛ z´ ogłoszen,´ jak tez˙ Intranetu (unikniecie˛ plotek). Zawczasu nalezy˙ tworzyc´ mozliwo˙ sci´ reagowania na pytania i watpliwo˛ sci,´ ale takze˙ obawy i strach zatrudnionych dotyczace˛ zmian. Równiez˙ zawczasu nalezy˙ w cały proces właczy˛ c´ przedstawicielstwa rózn˙ ych osób i gremiów. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 476

Udostepnienie˛ potrzebnych sr´ odków finansowych Szczebel kierowniczy musi upewnic´ sie,˛ ze˙ juz˙ przed rozpoczeciem˛ realizacji projektu mozna˙ dysponowac´ wymaganymi srodkami´ finan- sowymi (na zakup rzeczy i opłacenie ludzi) przypadajac˛ ymi na poszczególne pakiety działan´ i na osoby biorace˛ udział w projekcie. Oprócz samych kosztów inwestycji i licencji doliczyc´ tu trzeba na przykład koszty szkolen´ a w razie potrzeby takze˙ koszty zewnetrzne˛ go doradztwa i wsparcia projektu, jak tez˙ wewnetrzne˛ koszty osobowe. Ponadto potrzebne srodki´ finansowe nalezy˙ w danym przypadku dostosowac´ do postepów˛ prac nad projektem.

Odbiór wyników czastk˛ owych i koncowych´ Pomiedzy˛ szczeblem decyzyjnym, kierownic- twem projektu i członkami grup pracujac˛ ych nad projektem istnieje jasny podział zadan.´ Szcze- bel decyzyjny musi, na podstawie dokumentów przygotowanych przez grupe˛ realizujac˛ a˛projekt, podejmowac´ kluczowe decyzje na koncu´ poszczególnych etapów projektu i brac´ za nie odpowiedzialnos´c.´ W danym przypadku wskutek zmiany okolicznosci´ konieczna moze˙ byc´ modyﬁkacja przyjetych˛ strategicznych celów.

5.5.3.3 Uzyskanie wysokiego stopnia akceptacji sr´ odowiska docelowego wsród´ uzytk˙ ow- ników

Projekty migracyjne moga˛ zakonczy´ c´ sie˛ sukcesem i miec´ sens na poziomie pracowników tylko wtedy, gdy jasno zdefiniowana zostanie widoczna korzysć´ oraz gdy zostanie ona przedstawiona jako sensowna i konieczna. Korzysć´ taka wynika ze zdefiniowania celu. Takze˙ osoby zatrudnione przy projekcie migracyjnym powinny byc´ przekonane o jego zaletach, aby mogły go wprowadzac´ i wspierac´ na terenie cze˛sci´ bad˛ z´ całego urzedu.˛ Jednoczesnie´ nalezy˙ przy tym jasno poinformowac´ o granicach dla Open Source i zaznaczyc,´ dlaczego wy- brano droge˛ przejscia´ na Open Source. Celem powyzszych˙ czynnosci´ jest zapewnienie wysokiego stopnia akceptacji migracji i w konsekwencji duzej˙ motywacji oraz zadowolenia osób biorac˛ ych w niej udział. Nalezy˙ unikna˛c´ sytuacji, w której niezadowoleni (niedoinformowani, niezmotywowani albo wskutek braku odpowiedniego szkolenia niewykwalifikowani) uczestnicy projektu migracyjnego zagroz˙a˛ jego sukcesowi i w danym przypadku ogłosza˛porazki.˙ Patrzac˛ długofalowo moze˙ to miec´ w sumie ne- gatywny wpływ na skutecznosć´ i wydajnosć´ urzedu.˛ Aby móc w razie potrzeby dokonac´ korekty, osoby odpowiedzialne za konsekwentne informowanie o przebiegu projektu powinny poza speł- nianiem tego „obowiazku“˛ dokonac´ takze˙ „wyboru“ stałego sposobu kontroli poziomu sukcesu mierzonego zadowoleniem pracowników. Stworzenie koncepcji i trwałe wdrozenie˙ wynikajac˛ ych z niej działan´ jest wprawdzie przede ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 477

wszystkim zadaniem kierownictwa, jednak moze˙ byc´ ona tworzona tylko wspólnie z pracownikami i oczywiscie´ stale ulepszana. W danym przypadku na poczatku˛ sensowne moze˙ tu byc´ skorzystnie z zewnetrzne˛ go wsparcia, doradztwa i couchingu.

5.5.3.4 Szkolenia dla uzytk˙ owników i administratorów

W obszarze szkolen´ nalezy˙ z jednej strony zawczasu zintegrowac´ administratorów a niedługo potem takze˙ przyszłych uzytko˙ wników. Nalezy˙ stworzyc´ koncepcje˛ szkolenia grup docelowych uwzgledniaj˛ ac˛ a˛ zarówno posiadane umiejetno˛ sci,´ doswiadczenie´ i kwaliﬁkacje, jak tez˙ przy- szłe wykorzystanie składników w miejscu pracy. Zawiera ona takze˙ zapoznanie uzytko˙ wników z miejscem pracy oraz dalsze szkolenie, szczególnie administratorów i opiekunów uzytko˙ wników, w obszarze oprogramowania Open Source. Ponadto zaleca sie˛ aktywne właczanie˛ do pomysłów na szkolenie doswiadcze´ n´ z projektów pilotazo˙ wych albo innych projektów migracyjnych na zasadzie Lessons Learned. Kolejnymi konkretnymi działaniami sa:˛ przygotowanie srodo´ wisk testowych i symulacyjnych, cwicze´ n´ na wypadek awarii, backupu i recovery. Jest to tym wazniejsze˙ w sytuacji, gdy nie dysponuje sie˛ doswiadczeniami,´ wstepn˛ a˛ wiedza˛ albo jest ona bardzo mała i po migracji nie ma byc´ juz˙ biez˙ace˛ go bad˛ z´ dorazne´ go zewnetrzne˛ go wsparcia.

5.5.3.5 Działania organizacyjne przygotowujace˛ migracje˛

Utworzenie grupy pracujacej˛ nad projektem Z reguły projekty migracyjne nie sa˛ wykonywane przez jedna˛osobe,˛ lecz jest w nie zaangazo˙ wanych wiecej˛ osób. Aby sukcesem zakonczy´ c´ migracje˛ powinny one działac´ w ograniczonych ramach czasowych i zmierzac´ do jasno zde- ﬁniowanego celu. Wymagania te sa˛ klasycznymi cechami pracy nad projektem, które nalezy˙ uzupełnic´ o odpowiednia˛ dla projektu forme˛ organizacyjna˛5. Opierajac˛ sie˛ na tym nalezy˙ sprawdzic´ czy i w jakim stopniu dotychczasowa struktura, która jak wynika z doswiadcze´ n´ ukierunkowana jest pod katem˛ procesu, bedzie˛ przydatna, to znaczy ma forme˛ organizacyjna˛ adekwatna˛ do projektu. W razie potrzeby nalezy˙ czasowo zmienic´ organizacyjne warunki brzegowe i wyodrebni˛ c´ z organizacyjnych struktur urzedu˛ osoby biorace˛ udział w projekcie. Nalezy˙ przy tym, w ramach przygotowan,´ wypracowac´ z udziałem w/w osób i okresli´ c´ procesy robocze, punkty wspólne, produkty i zasoby. Obowiazuje˛ przy tym zasada, ze:˙

◦ struktura organizacyjna projektu jest wazniejsza˙ niz˙ struktura organizacyjna urzedu˛

5Ministerstwo Spraw Wewnetrzn˛ ych, Handbuch für Organisationsuntersuchnungen in der Bundesverwaltung, Bonn, 5 Auﬂ. 1988, S. 23 ff. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 478

◦ nalezy˙ jasno rozgraniczyc´ zadania i zakresy odpowiedzialnosci´

◦ nalezy˙ czasowo zredukowac´ albo przenies´c´ czynnosci´ Routine

◦ nalezy˙ ustalic´ drogi komunikacji i przekazywania sprawozdan´

Wszelkie plany i kroki nalezy˙ oceniac´ na tyle krytycznie, na ile z organizacyjnego punktu widzenia przyczyniaja˛ sie˛ one do osiagni˛ ecia˛ celu projektu. W watpliwych˛ przypadkach nalezy˙ preferowac´ takie działania, które niosa˛ ze soba˛ wiekszy˛ potencjał.

Skład grupy pracujacej˛ nad projektem Sukces projektu jest wiekszy˛ bad˛ z´ mniejszy w zalezno˙ sci´ od kierownictwa porojektu oraz składu grypy, która nad nim pracuje. Zły wybór moze˙ doprowadzic,´ takze˙ w przypadku, gdy pozostałe załozenia˙ sa˛ korzystne, do uzyskania niedosta- tecznego wyniku projektu, podczas gdy dobra obsada osobowa wypracowac´ moze,˙ nawet przy słabych warunkach brzegowych, wcia˛z˙ akceptowalne wyniki. Zaprzecza to gdzieniegdzie gło- szonej opini, ze˙ „nie ma ludzi nie zastapion˛ ych“. Kierownictwo projektu: Kierownik projektu ponosi całkowita˛ odpowiedzialnos´c´ za projekt. Koordynuje, organizuje i komunikuje wszystkie prace zwiazane˛ z projektem, co ma na celu jego specjalistyczne, terminowe i mieszczace˛ sie˛ w kosztach zakonczenie.´ Kierownik jest odpowiedzialny za wytyczanie zadan´ i kontrole˛ realizacji krótkoterminowych i długoterminowych celów. (w razie potrzeby takze˙ za przygotowywanie raportów dla nadzorujacej˛ komisji). W zalezno˙ sci´ od wielkosci´ urzedu˛ i charakteru zamiaru migracyjnego sensowne moze˙ okazac´ sie˛ mianowanie jeszcze jednej osoby oprócz kierownika projektu, która przejełaby˛ cze˛s´c´ jego zadan.´ Grupa pracujaca˛ nad projektem: Wypracowanie tresci´ projektu, wzglednie˛ realizacja pojedynczych etapów i stopni procesu migracyjnego wykonywane sa˛ przez członków grupy pracujacej˛ nad projektem. Przede wszystkim zalicza sie˛ do nich grupe˛ administratorów. Moga˛ do niej dołaczy˛ c´ wybrani uzytko˙ wnicy i w razie potrzeby osoby trzecie z zewnatrz˛ (doradcy w zakresie Know-how i sposobu pracy).

Właczanie˛ zewnetrznych˛ doradców Równiez˙ w urzedach˛ rosnie´ wsparcie ze strony zewnetrz-˛ nego doradztwa w dziedzinie wdrazania˙ projektów. Powody korzystania z tej formy pomocy to:

◦ profesjonalna, neutralna i obiektywna analiza problemu

◦ wydajne czasowo, zaplanowane zarzadzanie˛ projektem ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 479

◦ biez˙aca˛ komunikacja dotyczaca˛ projektu ze skuteczna˛kontrola˛postepu˛ prac i ich wyników

◦ przekonujace,˛ dobrze przygotowane prowadzenie spotkan,´ prezentacji i dokumentacji wy- ników)

◦ transfer wiedzy w zakresie przygotowania i przeprowadzenia skomplikowanych projektów informatycznych bad˛ z´ migracyjnych

Ustalenie formy organizacyjnej odpowiadajacej˛ potrzebom projektu Własciw´ a˛ dla projektu migracyjnego forme˛ organizacyjna˛nalezy˙ okresli´ c´ w zalezno˙ sci´ od zakresu migracji i wielkosci´ urzedu.˛ Organizacja projektu jest przy tym organizacja˛ równoległa,˛ która nie wchodzi w skład istniejacej˛ struktury organizacyjnej a jej istnienie ograniczone jest do czasu trwania projektu. W zalezno˙ sci´ od zadan´ i celów zaleca sie˛ skorzystanie z jednej z trzech wymienionych ponizej˙ mozliwo˙ sci´ organizacyjnych: liniowa organizacja projektu: Pracownicy zwiazani˛ z projektem zostaja˛ wyodrebnieni˛ z istniejacej˛ struktury organizacyjnej i tworza˛ własna˛ jednostke˛ organizacyjna˛ kierowana˛ przez kierownika projektu. Prowadzi to do wiekszej˛ identyfikacji z projektem, na którym pracownicy moga˛ sie˛ w pełni skoncentrowac.´ Jednoczesnie´ wystapi˛ brak wspomnianych pracowników w ich dziale, co moze˙ doprowadzic´ do rózne˙ go rozłozenia˙ sie˛ obcia˛ze˙ n´ (przecia˛zenia)˙ personelu. Forma organizacji liniowej powinna byc´ stosowana w przypadku obszernych i trudnych projek- tów. sztabowa organizacja projektu: Projekt kierowany jest przez koordynatora, który nie ma for- malnych pełnomoctnictw do podejmowania decyzji i przez to posiada ograniczone mozliwo˙ sci.´ Osoby pracujace˛ nad projektem pozostaja˛w swoich działach i spotykaja˛sie˛ tylko na zwiazan˛ ych z nim posiedzeniach, co sprawia, ze˙ sztabowa organizacja projektu jest podatna na zakłócenia i nieefektywnosć.´ Zaletami tego typu organizacji jest mały koszt (trzeba tylko znalezć´ koordynatora) i elastyczne obcia˛zenie˙ pracowników (praca nad projektem i w dziale). Ponadto mozna˙ jednoczesnie´ przeprowadzac´ wiele projektów. Generalnie niniejsza forma organizacyjna nadaje sie˛ tylko dla mniejszych projektów, poniewaz˙ w przeciwnym razie koszty koordynacji i uzgodnien´ sa˛ zbyt wysokie. matrycowa organizacja projektu: W przypadku tego typu organizacji oprócz istniejacej,˛ hierarchicznej struktury wprowadza sie˛ poziome kompetencje decyzyjne. Pracownicy podlegaja˛ kierownikowi projektu, jesli´ chodzi o kwestie wazne˙ dla projektu, ale osobowo i dyscyplinarnie nadal podlegaja˛ liniowo swoim przełozon˙ ym. Projekty tego typu sa˛ skomplikowane i wymagaja˛ wysokich nakładów na koordynacje.˛ ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 480

Ich zalety polegaja˛ na tym, ze˙ wymagane zasoby absorbowane sa˛ tylko w razie potrzeby. Kierownik projektu jest tutaj, w przeciwienstwie´ do sztabowej organizacji projektu, wyposazon˙ y w kompetencje decyzyjne i pełnomocnictwa do wydawania polecen.´ Wady wynikaja˛z tego, ze˙ osoby pracujace˛ nad projektem sa˛„sługami dwóch panów“. Zwłasz- cza w przypadku realizacji wielu projektów moga˛ wystapi˛ c´ konﬂikty o zasoby albo wynikajace˛ ze sprzecznych polecen.´

Zestawienie i ocena organizacyjnych form projektu procesów migracyjnych W celach orientacyjnych zwiazan˛ ych z wyborem własciwej´ formy organizacyjnej projektu moze˙ posłu- zy˙ c´ niniejsza tabela. Konieczne jest jednak dostosowanie dla konkretnego urzedu.˛

CAŁKOWITA MIGRACJA CZE˛S´ CIOWA MIGRACJA PUNKTOWA MIGRACJA

mały urzad˛ oraganizacja liniowa organizacja sztabowa organizacja sztabowa sredni´ urzad˛ organizacja liniowa organizacja matrycowa organizacja matrycowa duzy˙ urzad˛ organizacja liniowa organizacja liniowo - matrycowa organizacja matrycowa

Tablica 5.1: Propozycja: zestawienie form organizacyjnych projektu

mały urzad:˛ do 300 pracowników; sredni´ urzad:˛ do 1.000 pracowników; duzy˙ urzad:˛ od 1.000 pracowników

5.5.3.6 Właczenie˛ wybranych pracowników

W ramach przygotowywania projektu nalezy˙ , w zalezno˙ sci´ od stopnia skomplikowania zamiaru migracyjnego, podja˛c´ decyzje˛ organizacyjna˛ odnosnie´ tego, które grupy uzytko˙ wników aktyw- nie właczy˛ c´ do projektu, wzglednie˛ tylko poinformowac.´ Proces wprowadzania zmian dotyka pracowników w stopniu zalez˙ac˛ ym od tego czy chodzi o migracje˛ całkowita,˛ cze˛scio´ wa˛ albo punktowa.˛ Jesli,´ na przykład, w ramach cze˛scio´ wej migracji wymieniane jest oprogramowanie na serwerach, wówczas na ogół wystarczy przekazanie uzytko˙ wnikom informacji i nie jest konieczne aktywne właczenie˛ ich w ten proces. Jednak, gdy chodzi o migracje˛ oprogramowania biurowego, wtedy konieczny jest aktywny udział uzytko˙ wników objetych˛ migracja˛ i zapewnienie im opieki.

5.5.3.7 Okreslenie´ punktu wyjscia´

Kolejnym głównym wyznacznikiem sukcesu jest dokładne ustalenie sytuacji wyjscio´ wej. Z re- guły wia˛ze˙ sie˛ to z duzymi˙ nakładami, wymaga zasobów ludzkich i odpowiedniej ilosci´ czasu. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 481

Jednak zbyt dokładna znajomos´c´ szczegółów dokumentów albo aplikacji bazodanowych przeszkadza bad˛ z´ opóznia´ w danym przypadku wprowadzanie korekt podczas procesu migracyjnego albo juz˙ podczas przygotowan´ do migracji opóznia´ wdrozenie˙ odpowiedniego postepo˛ wania, wzglednie˛ podjecie˛ adekwatnych kroków. Okreslenie´ punktu wyjscia´ jest podstawa˛ umozliwia-˙ jac˛ a˛ sformułowanie wymagan´ wzgledem˛ systemów docelowych. Wazn˙ ymi elementami, których stan nalezy˙ ocenic´ sa˛ m.in.:

◦ bazy danych i struktury danych

◦ dokumenty i formaty dokumentów

◦ aplikacje i ich interfejsy

◦ dostepne˛ funkcje

◦ dostepno˛ s´c´ danych i aplikacji

◦ braki i problemy

◦ . . .

5.5.3.8 Spełnienie wymagan´ funkcjonalnych

Oprogramowanie docelowe powinno (w duzym˙ stopniu) zastapi˛ c´ istniejace˛ funkcje i wymagania. Musi ono w razie potrzeby wytrzymac´ miarodajne próby. Trudno byłoby zaakceptowac´ pogor- szenie pracy w porównaniu z sytuacja˛ wyjscio´ wa.˛ Do stwierdzenia wymagan´ co do funkcjonowania słuzy˙ przede wszystkim opis sytuacji wyjscio´ wej. Ponadto w ramach przeprowadzonej zawczasu ankiety nalezy˙ zebrac´ konkretne zapo- trzebowanie i wymagania wobec poszczególnych składników, zarówno z punktu widzenia uzyt-˙ kownika, jak i administratora, sprawdzic´ je i zestawic´ w postaci listy wymgan´ lub priorytetów. Niniejsze postepo˛ wanie zawiera takze˙ krytyczna˛ ocene˛ dotyczac˛ a˛ przydatnosci´ i sensownosci´ istniejac˛ ych juz˙ funkcji. Szczególnie nalezy˙ przeanalizowac´ krytyczne uwagi dotyczace˛ brakuja-˛ cych albo niepełnych funkcji i umiesci´ c´ je w kryteriach wyboru. W zalezno˙ sci´ od stopnia krytyki, brakujace˛ funkcje moga˛ doprowadzic´ do zmniejszenia akceptacji uzytko˙ wników. Na tej podstawie mozna˙ tworzyc´ porównania ze składnikami oprogramowania do wyboru, co w nastepn˛ ym kroku ma na celu wybranie oprogramowania docelowego odpowiadajace˛ go potrzebom. Całkowity sukces projektu musi dac´ sie˛ zmierzyc´ stopniem realizacji poszczególnych wymagan.´ ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 482

5.5.3.9 Korzystanie z wartosci´ doswiadczalnych´

Istotnym wyznacznikiem sukcesu jest równiez˙ wykorzystanie wartosci´ doswiadczaln´ ych w kontekscie´ migracji do Linuksa. Jest tak tym bardziej, ze˙ dotychczas (przestarzałe) istniało wzgled-˛ nie mało wartosci´ doswiadczaln´ ych w tym obszarze. Korzystanie z aktywnych doswiadcze´ n´ z projektu pilotazo˙ wego bad˛ z´ innych projektów migracyjnych i właczenie˛ ich do planowanego projektu oraz zamierzen´ przyniesie w jednakowym stopniu korzysci´ zarówno administratorom, jak i uzytko˙ wnikom. Mozna˙ tu polecic´ na przykład załozenie˙ bazy danych projektu.

5.5.3.10 Planowanie projektu, czasu i zasobów

W przypadku migracji z oprogramowania Microsoftu do okreslon´ ych srodo´ wisk systemowych oprogramowania Open Source, obowiazuj˛ a˛ metody klasycznej pracy nad projektem. Plan projektu: Poczatkiem˛ prac nad projektem jest stworzenie planu projektu, w którym opisana zostanie droga do celu zrozumiała dla osób trzecich. Plan projektu musi zawierac´ przynajmniej informacje odnosnie´ terminu, zasobów rzeczowych i ludzkich, właczenia˛ zewnetrzn˛ ych wykonawców, poszczególnych kroków i kosztów. Jednoczesnie´ tworzy on podstawe˛ dla kierowania projektem. W ramach planu projektu nalezy˙ opracowac,´

kto organizacja projektu kiedy terminy jak wykonac´ struktura projektu co wykonac´ zadania robic,´ w celu kalkulacja kosztów szybko i bezpieczenie strategia projektu sukces projektu wczesniej´ uzgodnione zlecenie

Wypracowane wyniki nalezy˙ udokumentowac´ w ksiedze˛ projektu. rozkład czasu: Poprzez planowanie przebiegu i czasu realizacji projektu nastepuje˛ jego daleko idac˛ y podział. Taki wia˛z˙ac˛ y plan wykonania projektu słuzy˙ umozliwieniu˙ przyjecia˛ reali- stycznego terminarza dla poszczególnych pakietów działan.´ Rozkład czasu wykonania projektu kieruje sie˛ według zawartej w zleceniu dacie jego zakonczenia.´ Nalezy˙ w nim równiez˙ okresli´ c´ poczatek,˛ etapy i koniec poszczególnych pakietów działan.´ Stworzenie planu projektu stworzy w przyszłosci´ podstawe˛ dla efektywnego kierowania projektem i sprawowania nad nim kontroli. plan nakładów, wzglednie˛ zasobów: W ramach przewidywania nakładów nalezy˙ sformuło- ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 483 wac´ wypowiedzi odnosnie´ tego, jaka ilos´c´ pracy (nakłady liczone w dniach roboczych na osobe)˛ oraz konieczne zasoby przewidywane sa˛ jako niezbedne˛ dla uzyskania uzgodnionego rezultatu. Nalezy˙ przy tym rozrózni˙ c´ nakłady (zalezne˙ od tresci´ pracy) i czas trwania (zalezn˙ y od intensywnosci´ pracy). W planach bad˛ z´ ocenach poszczególnych nakładów nalezy˙ kazdorazo˙ wo uja˛c´ nastepuj˛ ace˛ koszty:

◦ koszty osobowe (zasoby ludzkie pomnozone˙ przez stope˛ rozrachunkowa)˛

◦ właczenie˛ społecznosci´ w procesy migracji do srodo´ wisk Open Source

◦ zasoby na stworzenie i prace˛ srodo´ wisk testowych

◦ koszty materiału (zuzyte˙ materiały - koszty papieru i wydruku)

◦ koszty urzadze˛ n´ (urzadzenie˛ albo oprogramowanie, które trzeba ewentualnie zakupic)´

◦ pozostałe koszty (koszty podrózy˙ , usługi zewnetrzne).˛

◦ koszty nabycia i koszty licencji

◦ koszty konserwacji, opieki i szkolen´

5.5.3.11 Kontrola projektu i kierowanie projektem

Kontrola realizacji projektu jest wazn˙ a˛cze˛sci´ a˛składowa˛organizacji projektu. Zadania kontrolne nie ograniczaja˛sie˛ tylko do nadzoru kosztów i terminów. Własnie´ w kontekscie´ projektów informatycznych Controlling nie jest kontrola˛ w sensie czynnosci´ oceniajac˛ ych czynnosci´ przeszłe, lecz pełni on funkcje˛ zapobiegwcza˛ polegajac˛ a˛ na reagowaniu we własciwym´ czasie, gdy tylko rozpoznane zostana˛ odstepstwa˛ od wartosci´ zakładanych. Ma to na celu zagwarantowanie osia-˛ gniecia˛ celów projektu takich jak: jakos´c´ produktu konco´ wego, termin przekazania do uzytku˙ oraz koszty pracy nad projektem.

5.5.3.12 Dokumentowanie i zapewnienie jakosci´ projektu

Juz˙ podczas wykonywania projektu i przede wszystkim po jego zakonczeniu´ trzeba na kazdym˙ etapie zapewnic´ przejrzystos´c´ poszczególnych kroków takze˙ dla osób trzecich, które nie biora˛ udziału w procesie migracyjnym. Jest to warunkiem koniecznym dla pózniejszej´ prawidłowej opieki nad systemem. Dokumentacje˛ mozna˙ przygotowywac´ z wykorzystaniem nastepuj˛ ac˛ ych mediów: ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 484

◦ podreczniki˛ konﬁguracji

◦ podreczniki˛ pracy

◦ dokumetacja szkolen´

◦ spisy stanu

◦ podrecznik˛ projektu

◦ protokoły / sprawozdania nt. stanu

◦ sprawozdania odnosnie´ zapewnienia jakosci´ bad˛ z´ sprawozdania kontrolne

◦ dokumentacja konco´ wa

Oprócz kontroli i oceny projektowanego systemu, sprawozdanie kontrolne musi takze˙ zawierac´ analizy mozliwych˙ błedów˛ i ocene˛ skutków ich wystapienia˛ na kazdym˙ etapie projektu. Wspo- mniane analizy błedów˛ musza˛ byc´ tak samo udokumentowane, jak wszystkie inne prace nad projektem Wynacznikiem sukcesu w obszarze zapewnienia jakosci´ okazała sie˛ np. w projektach pilotazo˙ wych budowa srodo´ wisk testowych. W przypadku duzych˙ projektów wszystkie czynnosci´ prowadzace˛ do zapewnienia jakosci´ tworza˛ odrebn˛ y obszar zadan.´ W zalezno˙ sci´ od zakresu projektu i kwaliﬁkacji personelu moze˙ go nadzorowac´ kierownik projektu albo, w pewnych warunkach, kontroler projektu. Nastepuj˛ ac˛ y rysunek przedstawia wewnetrzne˛ kroki majace˛ na celu kontrole˛ jakosci:´

Rysunek 5.12: Etapy kontroli jakosci´

◦ na koncu´ poszczególnych kroków bad˛ z´ etapów projektu kontroler jakosci´ powinien przygotowac´ wymagane listy kontrolne i metody kontroli. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 485

◦ jesli´ wynik kontroli jakosci´ wypadnie pozytywnie, wówczas oznacza to zezwolenie na przejscie´ do nastepne˛ go kroku przewidzianego w projekcie. Jesli´ wynik nie odpowiada zdeﬁniowanym wymganiam jakoscio´ wym, wtedy nalezy˙ powrócic´ do pracy nad zle´ oce- nionym zadaniem. Braki nalezy˙ konkretnie i szczegółowo zdeﬁniowac´ i umiesci´ c´ w protokole kontrolnym. Na koncu´ trzeba ustalic´ termin ponownej kontroli i wpisac´ go do planu projektu.

5.5.3.13 Opieka na etapie pracy

Kolejnym warunkiem trwałego sukcesu migracji jest opieka administratorów mieszczaca˛ sie˛ w umiarkowanych granicach. Jednak ogólnie obowiazuj˛ acej˛ wartosci´ bed˛ ac˛ a˛ miara˛ takiego zaangazo˙ wania nie mozna˙ w tym miejscu podac.´ Wazn˙ a˛ rzecza˛ jest, by natychmiast reagowac,´ gdy zaistnieje ku temu odpowiednia potrzeba. Z uwagi na brakujac˛ y Routine w otoczeniu migracji, takze˙ na etapie rozpoczynania pracy z nowymi zadaniami nalezy˙ zapewnic,´ szczególnie administratorom, opieke˛ osób z zewnatrz˛ dostarczajac˛ ych potrzebna˛ wiedze˛ bad˛ z´ wsparcie. Wazne˙ jest to zwłaszcza wtedy, gdy osoby biorace˛ udział w migracji nie miały dotychczas doswiadczenia´ lub posiadały niewielkie doswiadczenie´ z systemami (GNU / Linux, OSS). Obecnos´c´ na miejscu osób przekazujac˛ ych wiedze˛ byłaby w kazdym˙ razie korzystna˛ opcja.˛

5.6 Eksperci współpracujacy˛ nad poradnikiem6

Frank Gamerdinger, jako specjalista od pakietów biurowych OpenOfﬁce.org oraz StarOfﬁce, współtworzył ocene˛ techniczna˛ migracji programów biurowych. Peter Ganten wyspecjalizował sie˛ w zagadnieniach usługi katalogowe, migracja z domen opartych na Windows NT do Samby i OpenLDAP pracujac˛ ych pod Linuksem oraz w dziedzinie Thin Clients i integracji aplikacji windowsowych na desktopie Linuksa. Współtworzył odpowiednie podrozdziały poradnika. Sebastian Hetze jest autorem takich podrozdziałów poradnika, jak bazy danych, składowa- nie plików, zarzadzanie˛ siecia˛ i zarzadzanie˛ systemem. Specjalizuje sie˛ w bazach danych oraz składowaniu plików w Linuksie, jak tez˙ formatach wymiany danych. Volker Lendecke jest członkiem zespołu developerów Samby. W zwiazku˛ z tym wniósł on cenne uwagi do technicznej oceny usług infrastrukturalnych, tj. składowania plików, autoryzacji

6Wymienieni w kolejnosci´ alfabetycznej. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 486

i drukowania. Michael Meskes specjalizuje sie˛ w DBMS, zwłaszcza w PostgreSQL. Wniósł odpowiednie uwagi do oceny technicznej w tym zakresie. Kurt Pfeiﬂe wyspecjalizował sie˛ w zagadnieniu integracji drukowania w sieci rozległej w srodo´ wiskach heterogenicznych i jako autor tworzył techniczna˛ocene˛ usług drukowania. Dr. Klaus Schmidt jest ekspertem ds. infrastruktury informatycznej i rozwoju produktu. Szczególnie specjalizuje sie˛ w rozwiazaniach˛ dla systemów wysokiej niezawodnosci.´ Współ- tworzył odpowiednie podrozdziały poradnika. Sebastian Stöcker wyspecjalizował sie˛ w infrastrukturach Microsoftu i architekturach systemowych i napisał istotne cze˛sci´ oceny technicznej zwiazane˛ ze składnikami Microsoftu. Thomas Uhl zajmuje sie˛ integracja˛ otwartych systemów, szczególnie w ramach Open So- urce. Jest autorem oceny technicznej rozwiaza˛ n´ opartych na Groupware i terminalach.

Osoby, które w jakikolwiek sposób przyczyniły sie˛ do powstania polskiej wersji poradnika migracyjnego7

Krzysztof Binas´ Aleksander Cynarski Grzegorz Artur Daszuta Maciej Jan Głowacki Maciej Hanski´ Radosław Janeczko Paweł Jastrzabek˛ Wojciech Kaczmarek8 Przemysław Klawitter Konrad Komada Piotr Kubiak Wojciech Kus´

7Wymienione w kolejnosci´ alfabetycznej. 8Przepraszam wszystkie osoby zainteresowane polska˛ wersja˛ jezyko˛ wa˛ poradnika za opóznienie´ w jej opubli- kowaniu. Prace˛ oraz czas poswi´ econ˛ y przeze mnie na potrzeby niniejszego tłumaczenia dedykuje˛ głodnym polskim dzieciom. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 487

Janusz Makówka Mikołaj Marczynski´ Paweł Najnigier Norbert Orłowski Sergiusz Pawłowicz Marcin Przybyła Bartosz Sawicki Tomasz Jakub Skrynnyk Ewa Smagacz Łukasz Spychalski Grzegorz Sulima Jarosław Zachwieja ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 488

5.7 Spis skrótów

ACE Access Control Entries

ACL Access Control List

AD Active Directory

ADAM Active Directory Application Mode

ADC Active Directory Connector

ADO ActiveX Data Objects

ADS Active Directory Service

ADSI Active Directory Service Interface

AFS Andrew File System

API Application Programming Interface

APOP Authenticated Post Ofﬁce Protocol

APT Advanced Package Tool

ASCII American Standard Code for Information Interchange

ASF Apache Software Foundation

ASP Active Server Pages

BB Bulletin Boards

BDC Backup Domain Controller

BfD Urzad˛ Pełnomocnika Rzadu˛ ds. Ochrony Danych Osobowych

BHO dyscyplina budzeto˙ wa

BIND Berkeley Internet Name Domain

BMI Ministerstwo Spraw Wewnetrzn˛ ych Republiki Federalnej Niemiec

BSD Berkeley Software Distribution ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 489

BSI Krajowy Urzad˛ ds. Bezpieczenstwa´ Informatycznego

BVA Ministerstwo Administracji Republiki Federalnej Niemiec

CA Certiﬁcation Authority

CDO Collaboration Data Objects

CGI Common Gateway Interface

CIFS Common Internet File System

CIM Common Information Model

CIS COM Internet Service

CLR Common Language Runtime cn commonName

CO Crossover Ofﬁce

COM Component Object Models

COM+ Component Object Models

CORBA Common Objects Request Broker Architecture

COLS Commercial Linux Software

CPU Central Processing Unit

CSS Cascading Style Sheets

CUPS Common UNIX Printing System

DACL Discretionary Access Control List

DAV Distributed Authoring and Versioning

DBMS System zarzadzania˛ bazami danych dc domain Component

DCOM Distributed Component Object Models

DDE Dynamic Data Exchange ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 490

DDNS Dynamic DNS

DFS Distributed File System

DHCP Dynamic Host Conﬁguration Protocol

DLC Data Link Control

DLL Dynamic Link Libraries

DMS System zarzadzania˛ dokumentami

DNS Domain Name Server

DNSSEC Domain Name System Security

DRBD Distributed Replicated Block Device

DS Directory Service

DSO Dynamic Shared Objects

DTD Document Type Deﬁnition

DTS Data Transformation Services

E2K Exchange 2000

EFS Encrypting File System

EJB Enterprise Java Beans

EMF Enhanced Meta Format

ESC/P Epson Printer Language

EXT2 Extendend Filesysten Version 2

EXT3 Extended Filesystem Version 3

FAT File Allocation Table

FQDN Full Qualiﬁed Domain Name

FRS File Replication Service ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 491

FSG Free Standard Group

FSMO Flexible Single Master Operation

FTP File Transfer Protocol

GC Global Catalog

GDI Graphics Device Interface

GNOME GNU Network Object Model Environment

GNU GNU’s Not UNIX

GPL General/Gnu Public License

GPOs Group Policy Objects

GPS Global Positioning System

GUID Global Unique Identiﬁer

HACMP High Availability Cluster Management Protocol

HD Harddisk

HIS Host Integration Server

HP Hewlett-Packard

HSM Hierarchical Storage Management

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

HTTPS Hyper-Text Transfer Protocol Secure

ICA Independent Computing Architecture

IDE Integrated Development Enviroment

IEAK Internet Explorer Administration Kit

IETF Internet Engineering Task Force ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 492

IIOP Internet Inter-ORB Protocol

IIS Internet Information Server

IMAP4 Internet Mail Access Protocol 4

IMAPS Internet Mail Access Protocol Secure

IPC Interprocess Communication

IPP Internet Printing Protocol

Ipsec Internet Protocol Security Protocol

IPv6 IP Version 6

IPX Internet Packet Exchange

IRC Internet Relay Chats

IS Information Store

ISA Internet Security and Acceleration

ISAPI Internet Service Application Programming Interface

ISC Internet Software Consortium

IT-WiBe zalecenia odnosnie´ przygotowywania oceny ekonomicznej w administracji publicznej, ze szczególnym uwzglednieniem˛ nakładów na technologie informatyczne

J2EE Java 2 Enterprise Edition

J2SE Java 2 Standard Edition

JAXP Java API for XML

JDBC Java Database Connection

JFS Journaled File System

JIT Just In Time

JMC Java Message Service ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 493

JNDI Java Naming and Directory Interface

JRE Java Runtime Environment

JRMI Java Remote Methode Invocation

JSP Java Server Pages

JTA Java Transaction API

JVM Java Virtual Machine

KBSt Rzado˛ wy Urzad˛ Koordynacji i Doradztwa ds. Informatyzacji przy Ministerstwie Spraw Wewnetrzn˛ ych Republiki Federalnej Niemiec

KDC Key Distribution Center

KDE K Desktop Environment

KMS Key Management Server

LAMP Linux, Apache, MySQL, PHP

LAN Local Area Network

LANANA Linux Assigned Names and Numbers Authority

LDAP Lightweight Directory Access Protocol

LDIF LDAP Data Interchange Format

LGPL Lesser General Public License

Li18nux Linux Internationalization Initiative

LM LAN Manager

LMRepl Replikacja katalogów

LPD Line Printing Daemon

LPI Linux Professional Institute

LPR Line Printing Redirector ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 494

LSB Linux Standard Base

LTSP Linux Terminal Server Project

LVM Logical Volume Manager

LVS Linux Virtual Server

MAC Media Access Control

MAPI Messaging Application Programming Interface

MDX Message Digest X

MLP Message/Multilayer Link Protocol

MMC Microsoft Management Console

MMQS Microsoft Message Queue Server

MOM Microsoft Operation Manager

MPL Mozilla Public License

MRTG/RRD Multi Router Trafﬁc Grapher/Round Robin Database

MS Microsoft

MSMQ Microsoft Message Queuing

MSPS Microsoft Proprietary Standards

MTA Message Transfer Agent

MTBF Mean Time Between Failure

MTS Microsoft Transaction Server

MTTR Mean Time To Repair

NAS Network Attached Storage

NAT Network Address Translation

NCSA National Center for Supercomputing Application ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 495

NetBEUI NetBIOS Extended User Interface

NetBIOS Network Basic Input and Output System

NetBT NetBIOS over TCP/IP

NFS Network File System

NIS Network Information Service

NNTP Network News Transport Protocol

NPL Netscape Public License

NTDS NT Directory Service

NTFS NT File System

NTFS4 NT File System 4

NTFS5 New Technology File System 5

NTLM Windows NT LAN Manager

NTLMv2 Windows NT LAN Manager Version 2

NTP Network Time Protocol

ODBC Open Database Connectivity

OLAP Online Analytical Processing

OLE Object Linking and Embedding

OMG Object Management Group

OOo OpenOfﬁce.org

OOo/SO Open Ofﬁce.org/StarOfﬁce

OpenLDAP Usługa katalogowa

OSI Open Systems Interconnection

OSOS Open Standards mit Open Source ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 496

OSS Open Source Software

OU Organizational Unit

OWA Outlook Web Access

PAM Pluggable Authentication Module

PBS Portable Batch System

PCL Printer Control Language

PDA Personal Digital Assistant

PDC Primary Domain Controller

PDF Portable Document Format

Perl Practical Extraction and Report Language

PHP PHP Hypertext Pre-processor

PIM Personal Information Manager

PKI Public Key Infrastructure

POP3 Post Ofﬁce Protocol Version 3

POSIX Portable Operating System Interface for UNIX

PPD PostScript Printer Descriptions

PT Personentage

RAC Real Application Cluster

RAID Redundant Array of Inexpensive/Independent Discs

RAM Random Access Machine/Memory

RAS Remote Access Service

RAW Read After Write

RDBMS System Zarzadzania˛ Relacyjna˛ Baza˛ Danych ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 497

RDP Remote Desktop Protocol

ReiserFS Reiser File System

RFCs Request for Comments

RHCE Red Hat Certiﬁed Engineer

RID Relative Identiﬁer

RISC Reduced Instruction Set Computer

RPC Remote Procedure Calls

RPM Red Hat Packet Management

S/MIME Secure MIME (Multipurpose Internet Mail Extensions)

SA System Attendant

SACL System Access Control List

SAGA Standardy i Architektury dla Aplikacji e-Government

SAM Security Accounts Manager

SAN Storage Area Network

SASL Simple Authentication and Security Layer

SC Samsung Contact

SCM Security Conﬁguration Manager

SCSI Small Computer System Interface

SFU Service for UNIX

SID Security Identiﬁer

SISL Sun Industry Source License

SLAs Service Level Agreements

SMB Server Message Block ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 498

SMS Short Message Service

SMS System Management Server

SMTP Simple Mail Transfer Protocol

SNA Storage Network Attached

SNMP Simple Network Management Protocol

SO StarOfﬁce

SOAP Simple Object Access Protocol

SPM Standard TCP/IP Port Monitor

SPX Sequenced Packet Exchange

SQL Structured Query Language

SQL-DMO SQL Distributed Management Objects

SRS Standard Replication Service

SSH Secure Shell

SSL Secure Sockets Layer

SSL/TLS Secure Sockets Layer / Transport Layer Security

SW Software

TB Terabajt

TCL Tool Command Language

TCO Total Costs of Ownership

TCP/IP Transmission Control Protocol / Internet Protocol

TDS Tabular Data Stream

TGS Ticket Granting Service

TGT Ticket Granting Ticket ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 499

TTS Trouble Ticket System

UDDI Universal Description, Discovery and Integration

UDP User Datagram Protocol

UHD User Help Desks

UNC Uniform Naming Convention

UNO Universal Network Objects

URL Uniform Resource Location

USB Universal Serial Bus

USN Unique Sequence Number

VBA Visual Basic for Applications

VBS Visual Basic Scripting Edition

VBScript Visual Basic Script

VFS Virtual File System

VLDB Very Large Database

VPN Virtual Private Network

W2K Windows 2000

W3C World Wide Web Consortiums

WAP Wireless Application Protocol

WBEM Web Based Enterprise Management

WebDAVS Web Document Authoring And Versioning

WINS Windows Internet Name Service

WSDL Web-Services Description Language

WSH Windows Scripting Host WWW World Wide Web ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 500

XFS Extended File System

XSL Extensible Style Sheet Language

XML Extensible Markup Language

YaST Yet another Setup Tool ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 501

5.8 Słownik poje˛c´

ADO ADO oznacza Active Data Objects. Sa˛to wysokopoziomowe interfejsy (np. z Visual Basic) słuz˙ace˛ do ogólnego odwoływania sie˛ do danych ﬁrmy Micro- soft poprzez OLE DB Provider (np. do SQL Server, ODBC, Oracle, Active Directory Service, i innych). ADO zawiera obiekty słuz˙ace˛ do tworzenia po- łaczenia˛ ze zródłem´ danych w celu wykonywania operacji odczytu, uaktualnienia, zapisu i usuwania.

ACL Access Control List jest lista˛ uprawnien´ dostepu.˛ Na podstawie niniejszych list odbywa sie˛ sterowanie dostepem˛ do zasobów systemu informatycznego. Na podstawie ACLs system decyduje o tym, jaki dostep˛ do zasobów, np. do katalogu przydzielic´ uzytko˙ wnikowi.

ActiveX Pojecie˛ zbiorowe oznaczajace˛ technologie˛ wprowadzona˛ przez Microsoft, która umozliwia˙ umieszczanie (inter)aktywnych tresci´ na stronach WWW. Przegladarka˛ pobiera z serwera cze˛sci´ programu ActiveX i wykonuje je na komputerze uzytko˙ wnika. Technologia ActiveX stworzona została przez Mi- crosoft jako alternatywa dla apletów Java.

API Application Programming Interface (zdeﬁniowany interfejs programistyczny, którego mozna˙ uzywa˙ c´ do integracji i rozszerzania)

ASP Oznacza „Active Server Pages“; jest rozwiazaniem˛ Microsoftu słuz˙ac˛ ym do generowania po stronie serwera dynamicznych stron WWW (np. za pomoca˛ JavaScript, Visual Basic Script), patrz takze˙ JSP.

C# Obiektowy jezyk˛ programowania zaprojektowany przez Microsoft w oparciu o C i C++. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 502

CGI Common Gateway Interface jest pierwotnym wariantem interfejsów serwera. Praktycznie kazdy˙ dzisiejszy serwer WWW obsługuje ten interfejs. Aplikacje pracujace˛ poprzez CGI mozna˙ tworzyc´ w rózn˙ ych jezykach˛ programowania. Oprócz jezyków˛ interpretowanych, takich jak, np. Perl, stosowac´ mozna˙ takze˙ skompilowane aplikacje napisane w C albo w C++.

COM Component Object Model jest standardem oprogramowania ﬁrmy Microsoft, za pomoca˛ którego mozna˙ realizowac´ komunikacje˛ pomiedzy˛ procesami i programami. COM deﬁniuje dodatkowo interfejs obiektowy, poprzez który program albo składnik oprogramowania udostepnia˛ usługi.

CORBA CORBA oznacza Common Object Request Broker Architecture i zaprojektowana została w celu umozliwienia˙ komunikacji pomiedzy˛ aplikacjami niezaleznej˙ od miejsca, platformy oraz implementacji. CORBA jest otwartym standardem zdeﬁniowanym przez Object Management Group (OMG).

DCOM Distributed Component Object Model jest wariantem standardu COM ﬁrmy Microsoft. Za pomoca˛DCOM mozna˙ poprzez siec´ udostepni˛ c´ dzielone usługi oprogramowania. DCOM wykorzystuje RPC (Remote Procedure Calls), co poprzez wymiane˛ informacji umozliwia˙ wywoływanie funkcji na innym komputerze.

DDE Dynamic Data Exchange jest technika˛ stosowana˛ w Windowsie, która umoz-˙ liwia programom uzytko˙ wym wymiane˛ danych. Sama wymiana danych odbywa sie˛ dynamicznie. Gdy pliki połaczone˛ za pomoca˛ DDE zostana˛ zmienione, automatycznie nastepuje˛ przekazanie zmiany do wszystkich plików komunikujac˛ ych sie˛ ze zmienionym plikiem.

DHCP Dynamic Host Conﬁguration Protocol tworzy podstawe˛ dynamicznego przydzielania adresów IP. Klient DHCP otrzymuje dynamicznie, z centralnego serwera DHCP, adres IP. Oprócz adresów IP do klienta przekazywane moga˛ byc´ jeszcze inne parametry konﬁguracyjne. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 503

DNS Domain Name System jest systemem zbudowanym hierarchicznie słuz˙ac˛ ym do przydzielania nazw dla komputerów podłaczon˛ ych do Internetu / Intranetu.

DTD Deﬁnicje typu dokumentu w formalny sposób ustalaja˛ strukture˛ dokumentu XML. Okreslaj´ a˛ one składnie˛ obowiazuj˛ ac˛ a˛ dla danego typu dokumentu (a tym samym takze˙ dla okreslone´ go formatu danych).

Emulacja Zdolnos´c´ systemu, wzglednie˛ programu do naslado´ wania sposobu pracy systemu komputerowego za pomoca˛ osprzetu˛ bad˛ z´ oprogramowania.

Failover Jest specyﬁcznym rodzajem pracy osprzetu˛ bad˛ z´ oprogramowania, np. bazy danych, serwera albo sieci, które skonﬁgurowane sa˛w taki sposób, ze˙ w przypadku przejscio´ wego ustania pracy systemu, nastepuje˛ automatyczne przeje-˛ cie swiadczonej´ przez nie usługi przez system spełniajac˛ y podobne albo takie same funkcje.

HTML Hypertext Markup Language – otwarty standard bad˛ z´ format pliku słuz˙ac˛ y do prezentowania tresci´ w Internecie albo Intranecie.

HTTP Standard słuz˙ac˛ y do elektronicznej interakcji podczas transmisji dokumentów WWW do Internetu.

IMAP Za pomoca˛ Internet Mail Access Protocol mozna˙ zarzadza˛ c´ skrzynkami poczty elektronicznej. W przeciwienstwie´ do POP3, IMAP administruje poczta˛ na serwerze. Podczas właczania˛ programu pocztowego standardowo sci´ agane˛ sa˛tylko nagłówki wiadomosci´ (nadawca, temat i czas dostarczenia). W tym momencie adresat moze˙ wybrac´ dowolne wiadomosci´ i sci´ agn˛ a˛c´ ich pełna˛ tres´c.´ Poczta, która˛ chcemy pozostawic´ na serwerze moze˙ byc´ odkła- dana do oddzielnych katalogów.

IPsec Standard sieciowych systemów bezpieczenstwa,´ który przede wszystkim nadaje sie˛ do implementacji VPNs, jak tez˙ do zdalnego dostepu˛ do prywatnych sieci poprzez połaczenia˛ dial - up. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 504

IPv6 To nowa wersja 6 protokołu internetowego (IP), w przypadku której adresy IP powinny składac´ sie˛ ze 128 zamiast 32 bitów, jak ma to miejsce w przypadku IPv4. Dzieki˛ temu stworzono, miedzy˛ innymi, wieksz˛ a˛ przestrzen´ adresowa˛ dla stron WWW.

IPX Standard transmisji danych zdeﬁniowany przez ﬁrme˛ Novell.

Java Obiektowy jezyk˛ programowania stworzony przez SUN Microsystems, który uzywan˙ y jest przede wszystkim w obszarze technologii internetowej. Teksty zródło´ we tłumaczone sa˛ do niezalezne˙ go od platformy kodu posrednie´ go za pomoca˛tak zwanego kompilatora. Moze˙ byc´ on wykonywany przez własciwy´ interpreter na dowolnym komputerze. Dzieki˛ temu programy Java moga˛ pracowac´ na wszystkich platformach, dla których istnieje odpowiedni interpreter.

Java Beans Java Beans sa˛ składnikami oprogramowania wielokrotnego uzytku,˙ które po- wstały w technologii Java.

Java Script Jezyk˛ skryptowy zdeﬁniowany pierwotnie przez ﬁrme˛ Netscape słuz˙ac˛ y do łaczenia˛ kodu programu ze statycznymi stronami HTML. Z reguły wykonanie kodu nastepuje˛ w przegladarce˛ uzytko˙ wnika.

JDBC Java Database Connectivity oferuje mechanizm umozliwiaj˙ ac˛ y komunikacje˛ z istniejac˛ ymi bazami danych. Sterowniki tworza˛ interfejs pomiedzy˛ programem Java i baza˛ danych.

JSP JavaServer-Pages sa˛plikami HTML zawierajac˛ ymi kod programu napisany w Java, który po przekształceniu w serwlety za pomoca˛ silnika JSP, moze˙ byc´ wykonywany po stronie serwera WWW.

LAMP Platforma Open Source oparta na Linuksie, Apache, MySQL i PHP bad˛ z´ Perlu albo Pythonie słuz˙aca˛ programistom WWW do tworzenia aplikacji WWW. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 505

LDAP Lightweight Directory Access Protocol (X.509) jest uproszczona˛wersja˛DAP (X.500). Za pomoca˛ LDAP realizowany jest dostep˛ do usług katalogowych, które mozna˙ odpytywac´ pod katem,˛ np. cech uzytko˙ wników.

Makro Połaczone˛ pojedyncze instrukcje bad˛ z´ szereg polecen´ i procesów, które mozna˙ przechowywac´ i zapisywac.´ Gdy wywołane zostaje makro, wówczas nastepuje˛ automatyczne wykonanie procesów i akcji w odpowiedniej kolejnosci.´

MP3 Standardowy format skompresowanych plików audio, który zaprojektowany został w ramach MPEG przez Fraunhofer - Institut i rozpowszechnił sie˛ przede wszystkim w Internecie.

MTA Składnik oprogramowana odpowiedzialny za rozdzielanie poczty elektronicznej pomiedzy˛ rózne˙ systemy komputerowe. MTA odbiera wiadomosci´ za- równo z innych MTA, jak tez˙ z MUA i kieruje je do odpowiednich uzytko˙ w- ników.

MUA Mail User Agent jest programem umozliwiaj˙ ac˛ ym uzytko˙ wnikowi dostep˛ do wiadomosci´ elektronicznych, ich wyswietlanie,´ czytanie, edycje˛ oraz zarza-˛ dzanie nimi.

.NET Platforma dla Web Services ﬁrmy Microsoft opartych na XML. Zadaniem platformy jest łaczenie˛ w jednolity i spersonalizowany sposób informacji, urzadze˛ n´ i uzytko˙ wników.

NTP Network Time Protocol słuzy˙ do synchronizacji poprzez siec´ zegarów pracujac˛ ych w rózn˙ ych komputerach. NTP umozliwia˙ ustawienie czasu kompute- rów z dokładnosci´ a˛ co do milisekundy, co jest bardzo wazne˙ dla procesów wykonywanych jednoczesnie´ przez wiele komputerów.

ODBC Standardowe postepo˛ wanie polegajace˛ na zapewnieniu dostepu˛ do baz danych. Na przykład aplikacje moga˛ odwoływac´ sie˛ do rózne˙ go rodzaju baz danych za pomoca˛ ODBC. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 506

OLE OLE oznacza „Object Linking and Embedding“ i jest metoda˛ wspólnego korzystania z informacji. Informacje te moga˛byc´ dostepne˛ w rózn˙ ych formatach i utworzone za pomoca˛ rózn˙ ych aplikacji. Dane z dokumentu zródło´ wego ła-˛ czone sa˛ z dokumentem docelowym bad˛ z´ sa˛ one do niego właczane.˛ Gdy w dokumencie docelowym nastapi˛ zaznaczenie właczon˛ ych danych, wówczas otwarta zostanie aplikacja, z której one pochodza,˛ co ma na celu umozliwienie˙ edycji danych w ich pierwotnym srodo´ wisku za pomoca˛niezbedn˛ ych funkcji. Mówi sie˛ takze˙ o „OLE Compound Documents“.

OSI Miedzynarodo˛ wy standard wymiany danych w sieciach. OSI reprezentuje siedem warstw, które kazdorazo˙ wo opisuja˛ poszczególne procesy komunikacyjne.

PDF Ponadplatformowy format dokumentów ﬁrmy Adobe Systems, za pomoca˛ którego mozna˙ tworzyc´ i prezentowac´ dokumenty złozone˙ z tekstów, rysun- ków i graﬁk.

Perl Practical Extraction and Raport Language jest wolnodostepn˛ ym jezykiem˛ programowania, który szczególnie czesto˛ wykorzystywany jest do tworzenia skryptów CGI. Dzieki˛ róznorodn˙ ym mozliwo˙ sci´ a,˛ zwłaszcza jesli´ chodzi o edycje˛ ciagów˛ znaków, programy napisane w Perlu słuz˙a˛takze˙ czesto˛ do wykonywania administracyjnych zadan´ routine.

PHP Jezyk˛ skryptowy po stronie serwera słuz˙ac˛ y do tworzenia dynamicznych tresci´ WWW w oparciu o baze˛ danych.

POP3 W przypadku pracy z Post Ofﬁce Protocol w wersji 3 lokalny program pocztowy (klient) sci´ aga˛ po uruchomieniu cała˛ nowa˛ poczte˛ z serwera WWW do lokalnego komputera. Zazwyczaj klient skonﬁgurowany jest w taki sposób, ze˙ po sci´ agni˛ eciu˛ poczta jest usuwana z serwera.

POSIX Standard interfejsów oparty na Uniksie, zgodny z IEEE. Przede wszystkim obsługuje wszystkie odmiany Uniksa. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 507

PostScript Jezyk˛ opisu strony stworzony przez ﬁrme˛ Adobe do sterowania drukarkami. Drukarki postscriptowe otrzymuja˛polecenia wydruku z kazde˙ go programu w formie standardowego szeregu instrukcji. Sa˛ one interpretowane przez odpowiednia˛ drukarke˛ i wykonywane w procesie drukowania.

RAS Jest oznaczeniem Microsoftu dla udostepniania˛ usług dial - up wewnatrz˛ systemu operacyjnego Microsoft.

RDBMS W systemie zarzadzania˛ relacyjna˛ baza˛ danych informacje zgromadzone w bazie danych znajduja˛ sie˛ w tabelach, które powiazane˛ sa˛ wzajemnymi rela- cjami utworzonymi zgodnie z modelem relacyjnym.

Server Proces, program albo komputer słuz˙ac˛ y do przetwarzania z˙ada˛ n´ klienta bad˛ z´ do udostepniania˛ usług, z których korzysta klient.

SQL Jest standardowym jezykiem˛ zapytan´ wysyłanych do relacyjnych baz danych.

SSH Protokół bad˛ z´ odpowiednia jego implementacja (systemy Unix / Linux), który gwarantuje bezpieczny dostep˛ do komputerów podłaczon˛ ych do sieci. Im- plementacja ta oferuje bezpieczna˛ transmisje˛ danych z wykorzystaniem bezpiecznych połacze˛ n.´

SSL Technologia szyfrowania zaprojektowana przez ﬁrme˛ Netscape oraz proto- kół do bezpiecznej komunikacji bad˛ z´ bezpiecznego przesyłania dokumentów pomiedzy˛ przegladarkami˛ a serwerami WWW.

TCP/IP Zestaw protokołów sieciowych wykorzystywanych wewnatrz˛ sieci w celu udostepnienia˛ uzytko˙ wnikowi szeregu usług. TCP (Transmission Control Pro- tocol) oraz IP (Internet Protocol) oferuja˛ podstawy budowania pojedynczych pakietów danych, ich przesyłania i dostarczania. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 508

UNO UNO jest modelem składników, który tworzy kompatybilnosć´ pomiedzy˛ roz-˙ nymi jezykami˛ programowania, rózn˙ ymi modelami obiektowymi, rózn˙ ymi architekturami maszyn i rózn˙ ymi procesami. Kompatybilnosć´ ta moze˙ wy- stepo˛ wac´ w LAN albo za posrednictwem´ Internetu. UNO rozwijany jest przez społecznosć´ OpenOffice razem z laboratoriami programistycznymi Sun Microsystems. Podstawowe biblioteki UNO sa˛ niezalezne˙ od OpenOffice i Star Office i mozna˙ je stosowac´ jako Framework dla innych aplikacji. UNO jest wolny i udostepnian˛ y na licencji LGPL. Obecnie Java, C i C++ obsłu- giwane sa˛ w Windowsie, Linuksie i Solaris (patrz takze˙ http://udk. openoffice.org/common-/man/uno.html).

URL Uniform Resource Locator opisuje jednoznaczny adres w World Wide Web, np. „http://openpoland.org“.

VBA Visual Basic for Applications

W3C Konsorcjum World Wide Web koordynuje rozwój WWW oraz standaryzacje˛ HTML, XML i ich pochodnych.

WebDAV Web-based Distributed Authoring and Versioning jest rozszerzeniem Hyper- text Transfer Protocol (HTTP) i oferuje standardowa˛ obsługe˛ asynchronicz- nego, kolaboracyjnego tworzenia tresci´ poprzez Internet bad˛ z´ Intranet.

WINS System Microsoft do przekształcania nazw wewnatrz˛ sieci (nazwy sieciowe <–> adresy IP).

XML Specyﬁkacja do deﬁniowania jezyków˛ słuz˙ac˛ ych do formatowania dokumen- tów. XML oferuje scisłe´ rozdzielenie tresci´ od warstwy logicznej.

XLST Jezyk˛ zalecany przez W3C do tworzenia dokumentów stylów, które w oparciu o reguły przekształcaja˛ struktury XML w inne struktury XML, np. w jezyk˛ opisu stron taki jak HTML. Spis tablic

2.2 SuSE Linux ...... 43 2.4 Red Hat ...... 44

3.2 Windows - grupy uprawnien´ ...... 61 3.4 Atrybuty w Windows ...... 62 3.6 Porównanie serwerów plików ...... 71 3.8 Porównanie systemów plików ...... 75 3.10 Uprawnienia POSIX oraz grupy uprawnien´ Windows ...... 78 3.12 Uprawnienia POSIX i Windows ...... 79 3.14 Typy grup ...... 83 3.16 Połaczenie˛ klienta z CUPS ...... 105 3.18 Unikalne oznaczenia nazw NetBIOS ...... 130 3.20 Wielowartoscio´ we oznaczenia nazw NetBIOS ...... 131 3.22 Przeglad˛ obsługiwanych typów DNS Resource Record ...... 133 3.24 Opcje DHCP ...... 135 3.26 Porównanie usług katalogowych ...... 173 3.28 Porównanie J2EE i .NET ...... 184 3.30 Moduły Apache ...... 203 3.32 Rozszerzone funkcjonalnosci´ Internet Information Server 5.0 ...... 210 3.34 Składniki dostepne˛ na serwerze MS SQL jako obiekty ...... 220 3.36 Systemy bazodanowe dostepne˛ na licencji Open Source ...... 226 3.38 Zestawienie systemów bazodanowych SQL ...... 229 3.40 Rozszerzone rozwiazania˛ internetowe i intranetowe obsługiwane przez MS SQL Serwer 2000 ...... 231 3.43 Podstawowe składniki Exchange 5.5 ...... 237 3.45 Wybór modułów phpGroupware ...... 242

509 SPIS TABLIC 510

3.47 Składniki Kolab ...... 243 3.49 Składniki Exchange4linux ...... 247 3.51 Centralne składniki OpenExchange Server 4 ...... 251 3.53 Składniki Samsung Contact ...... 257 3.55 Alternatywne rozwiazania˛ Groupware ...... 262 3.57 Matryca kompatybilnosci´ Exchange ...... 268 3.59 Wersje VBA ...... 273 3.61 Rozszerzenia plików najwazniejszych˙ aplikacji Ofﬁce ...... 280 3.63 Własciwo´ sci´ MS Ofﬁce mogace˛ sprawic´ problemy podczas konwersji do OOo / SO ...... 283 3.65 Porównanie dostepn˛ ych typów szablonów i formatów ...... 284 3.67 Róznice˙ w kluczowych funkcjonalnosciach´ ...... 287 3.69 Przeglad˛ przegladarek˛ WWW nalez˙ac˛ ych do OSS ...... 310 3.71 Zalety Terminal - Servers i Thin Clients ...... 332 3.73 Wybrane wady Terminal - Servers i Thin Clients ...... 333 3.75 Wymagania wzgledem˛ systemu HA ...... 343 3.77 Zestawienie poziomów abstrakcji ...... 344 3.79 Przeglad˛ komercyjnego oprogramowania HA ...... 348

4.2 Porównanie kosztów przypadajac˛ ych na uzytko˙ wników w przypadku migracji pełnej i kontynuacyjnej ...... 369 4.4 Rozkład kosztów w przypadku „migracji pełnej“ w urzedach˛ ...... 370 4.6 Całkowite koszty migracji przypadajace˛ na uzytko˙ wnika w przypadku migracji pełnej ...... 371 4.8 Całkowite koszty migracji przypadajace˛ na uzytko˙ wnika w przypadku migracji kontynuacyjnej ...... 372 4.10 Całkowite koszty migracji przypadajace˛ na uzytko˙ wnika w przypadku migracji punktowej ...... 372 4.12 Rozłozenie˙ kosztów migracji ...... 373 4.14 Całkowite koszty migracji przypadajace˛ na uzytko˙ wnika w przypadku migracji cze˛scio´ wej po stronie serwera...... 374 4.16 Całkowite koszty migracji przypadajace˛ na uzytko˙ wnika w przypadku migracji cze˛scio´ wej po stronie serwera...... 374 4.18 Opis scenariuszy migracji z Windows NT do Windows 2000 ...... 378 4.20 Nakłady na personel w przypadku migracji kontynuacyjnej ...... 380 SPIS TABLIC 511

4.22 Opis scenariusza dla migracji z Windows NT do Linuksa ...... 382 4.24 Nakłady liczone w dniach na osobe˛ w przypadku migracji zastepuj˛ acej˛ ...... 384 4.26 Nakłady liczone w dniach na osobe:˛ Exchange5.5 –> Exchange2000 ...... 386 4.28 Nakłady liczone w dniach na osobe:˛ Exchange5.5 –> Samsung Contact . . . . . 388 4.30 Przykład migracji: infrastruktura serwerów – mały urzad˛ ...... 391 4.31 1 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), mały urzad.˛ . 391 4.33 Przykład migracji: infrastruktura serwerów – sredni´ urzad˛ ...... 394 4.34 2 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), sredni´ urzad˛ . 394 4.36 Przykład migracji: infrastruktura serwerów – duzy˙ urzad˛ ...... 397 4.37 3 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), duzy˙ urzad˛ . . 397 4.39 Przykłady migracji: Office / Client Desktop ...... 400 4.40 Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), mały urzad˛ 400 4.41 Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), mały urzad˛ 401 4.42 Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), sredni´ urzad˛ 402 4.43 Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), duzy˙ urzad˛ 403 4.45 Przykłady migracji z Windows / Microsoft Office do –> Linux / OpenOffice.org . 405 4.46 Przykład WiBe: Windows / Office do Linux / OpenOffice.org; Break even po 3 latach ...... 406 4.47 Przykład WiBe: Windows / MS Office do Linux / OpenOffice.org; Break even po 5 latach ...... 407 4.49 Przykłady migracji: Messaging / Groupware – mały urzad˛ ...... 410 4.50 Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], mały urzad˛ 411 4.52 Przykłady migracji: Messaging / Groupware – sredni´ urzad˛ ...... 412 4.53 Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], sredni´ urzad˛ 413 4.55 Przykłady migracji: Messaging / Groupware – duzy˙ urzad˛ ...... 414 4.56 Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], duzy˙ urzad˛ . 415 4.57 Typy migracji / produkty ...... 416 4.59 Przykład analizy korzysci:´ czynniki koniecznosci´ ...... 434 4.61 Przykład analizy korzysci:´ czynniki jakoscio´ wo - strategiczne ...... 439

5.1 Propozycja: zestawienie form organizacyjnych projektu ...... 480 Spis rysunków

2.1 Składniki systemu - punkt wyjscia´ ...... 32 2.2 Składniki systemu - migracja zastepuj˛ aca˛ ...... 35 2.3 Składniki systemu - migracja kontynuacyjna ...... 36

3.1 Metoda B-G-L-R ...... 64 3.2 Metoda B-G-R ...... 65 3.3 Srodo´ wisko wydruku ...... 91 3.4 Proces wydruku realizowany metoda˛ „Point & Print“ ...... 95 3.5 Drukowanie z CUPS ...... 104 3.6 Scenariusz logowania ...... 121 3.7 Przykład struktury domen NT ...... 156 3.8 Przykład Windows 2000 ...... 156 3.9 Przykład struktury punktu centralnego domen oraz ich struktury ...... 158 3.10 Punkt wyjscia´ ...... 160 3.11 Domena Master: W2K.BEHOERDE.DE ...... 161 3.12 Domena Master: BEHOERDE.DE ...... 162 3.13 Domena Master: NEU.DE ...... 163 3.14 Domena Master i domena struktury: NEU.DE / INTRA.NEU.DE ...... 164 3.15 Domena Master: INTRA.BEHOERDE-ONLINE.DE ...... 166 3.16 Master domain: AMT.LOCAL ...... 167 3.17 Migracja przez Upgrade albo restrukturyzacje˛ ...... 176 3.18 Migracja ADS – aktualizacja plus restrukturyzacja ...... 177 3.19 Migracja ADS - nowa domena plus restrukturyzacja ...... 178 3.20 Migracja ADS - klony uzytko˙ wników i grup ...... 178 3.21 Migracja ADS - swiat´ równoległy a migracja zasobów ...... 179

512 SPIS RYSUNKÓW 513

3.22 Migracja ADS - wypełnianie równoległego swiata´ kontami uzytko˙ wnika oraz grupami ...... 180 3.23 Składniki .Net-Frameworks ...... 187 3.24 Model warstwowy J2EE ...... 189 3.25 Microsoft .NET- Framework ...... 192 3.26 Architektura SharePoint Portal Server ...... 213 3.27 Architektura serwera MS SQL Server ...... 217 3.28 Architektura Samsung Contact ...... 255 3.29 Mieszane srodo´ wiska Exchange ...... 269 3.30 VBA w aplikacji Office ...... 274 3.31 Mozliwe˙ rozszerzenia w Office ...... 275 3.32 Fontmapping MS Office OOo / SO ...... 278 3.33 Zawartosć´ pliku OOo / SO wyswietlana´ w przegladarce˛ plików ZIP...... 280 3.34 Obiekty - cienie w PowerPoint i Impress ...... 292 3.35 Konwerter dokumentów: wybór formatu zródło´ wego ...... 293 3.36 Konwerter dokumentów: wybór katalogu zródło´ wego i docelowego ...... 294 3.37 Desktop KDE – przykład 1 ...... 305 3.38 Desktop KDE – przykład 2 ...... 306 3.39 Desktop GNOME – przykład 1 ...... 307 3.40 Desktop GNOME – przykład 2 ...... 308 3.41 Desktop windowsowy w Linuksie emulowany przez VMware ...... 316 3.42 Desktop windowsowy w Linuksie emulowany przez Win4Lin ...... 319 3.43 Aplikacje windowsowe na desktopie linuksowym emulowane przez WINE . . . . 323 3.44 Wykonywanie aplikacji X w kliencie Fat ...... 334 3.45 Uruchamianie aplikacji X i aplikacji windowsowych w Thin Client ...... 335 3.46 Bootowanie systemu linuksowego poprzez siec´ ...... 336 3.47 Serverfarm pod kontrola˛ Metaframe XP ...... 341 3.48 Rozwiazania˛ HA ...... 346 3.49 Rozwiazanie˛ oparte o Heartbeat i DRBD ...... 350

4.1 Metodologia IT-WiBe ...... 356 4.2 Matryca kosztów migracji z kategoriami kosztów i obszarami zastosowan´ . . . . 363 4.3 Rozwój kosztów migracji ...... 370 4.4 Koszty migracji przypadajace˛ na uzytko˙ wnika ...... 374 SPIS RYSUNKÓW 514

4.5 Przykład rachunku opłacalnosci´ migracji Windows NT –> Linux, duzy˙ urzad,˛ ocena kosztów projektu ...... 417 4.6 Przykład rachunku opłacalnosci´ migracji Windows NT –> Linux, duzy˙ urzad,˛ ocena wartosci´ kapitału ...... 418 4.7 Przykład rachunku opłacalnosci´ migracji Windows NT –> Linux, sredni´ urzad,˛ ocena kosztów projektu ...... 419 4.8 Przykład rachunku opłacalnosci´ migracji Windows NT –> Linux, sredni´ urzad,˛ ocena wartosci´ kapitału ...... 420 4.9 Przykład rachunku opłacalnosci´ migracji Windows NT –> Linux, mały urzad,˛ ocena wartosci´ kapitału ...... 421 4.10 Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, duzy˙ urzad˛ ...... 422 4.11 Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, duzy˙ urzad,˛ alternatywna dzierza˙ wa Windows / Office ...... 423 4.12 Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, sredni´ urzad˛ ...... 423 4.13 Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, sredni´ urzad,˛ alternatywna dzierza˙ wa Windows / Office ...... 424 4.14 Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, mały urzad˛ ...... 425 4.15 Przykład rachunku kosztów projektu migracji Windows NT –> Linux, mały urzad,˛ alternatywna dzierza˙ wa Windows / Office ...... 426 4.16 Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Con- tact, duzy˙ urzad˛ ...... 426 4.17 Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Con- tact, sredni´ urzad˛ ...... 427 4.18 Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Con- tact, mały urzad˛ ...... 428 4.19 Przykład rachunku kosztów projektu migracji Windows NT do Linuksa po stronie serwera, duzy˙ urzad˛ ...... 428 4.20 Przykład rachunku kosztów projektu migracji Windows NT do Linuksa po stronie serwera, sredni´ urzad˛ ...... 429 4.21 Przykład rachunku kosztów projektu migracji Windows NT do Linuksa po stronie serwera, mały urzad˛ ...... 430 SPIS RYSUNKÓW 515

4.22 Model oceny koniecznosci´ i jakosci´ zamiaru migracyjnego ...... 432

5.1 Proces decyzyjny prowadzac˛ y do wdrozenia˙ OSS ...... 442 5.2 Architektura systemu z linuksowym Fat Client ...... 446 5.3 Zalecana architektura IT w duzym˙ urzedzie˛ w przypadku całkowitej „zastepuj˛ a-˛ cej migracji“ ...... 451 5.4 Obszary zastosowan´ usług katalogowych na przykładzie platformy SunOne . . . 452 5.5 Zalecana architektura IT dla specjalizowanego urzedu˛ w przypadku całkowitej „zastepuj˛ acej˛ migracji“ ...... 454 5.6 Zalecana architektura IT dla małego urzedu˛ w przypadku całkowitej „zastepuj˛ a-˛ cej migracji“ ...... 456 5.7 Sytuacja wyjscio´ wa dla migracji kontynuacyjnej ...... 459 5.8 Rózne˙ warianty zastapienia˛ Exchange w przypadku migracji cze˛scio´ wej . . . . . 464 5.9 Łagodna migracja ...... 470 5.10 Etapy zamiany oprogramowania w przypadku łagodnej migracji ...... 471 5.11 Model stopniowego procesu migracji ...... 472 5.12 Etapy kontroli jakosci´ ...... 484

5.9 Załaczniki˛

5.9.1 Załaczniki˛ dla WiBe

5.9.2 Przeglad˛ zalecanych katalogów z kryteriami

◦ Główny katalog kryteriów IT-WiBe21 dla scenariuszy migracyjnych opracowany przez doradztwo projektowe i organizacyjne dr Peter Röthing, „Zalecenia odnosnie´ przygotowywania oceny ekonomicznej w administracji publicznej, ze szczególnym uwzglednieniem˛ nakładów na technologie informatyczne“, wersja 3.0 - 2001, wydane przez KBSt, Mini- sterstwo Spraw Wewnetrzn˛ ych, pisma KBSt, ISSN 0179-7263, tom 52, maj 2001 r.

◦ Specjalny katalog kryteriów IT-WiBe21 dla realizacji uaktualnien´ systemów informatycznych oraz zamierzen´ migracyjnych opracowany przez doradztwo projektowe i orgranizacyjne dr Peter Röthig oraz prof. dr Detlef Leipelt, FH panstwa´ dla administracji publicznej – wskazówki i zalecenia – dla realizacji uaktualnien´ systemów informatycnych bad˛ z´ zamierzen´ migracyjnych na podstawie IT - WiBe - 97, wydane przez KBSt, Minister- stwo Spraw Wewnetrzn˛ ych, pisma KBSt ISSN 0179-7263, list 04/2000, listopad 2000 SPIS RYSUNKÓW 516

◦ Specjalny katalog kryteriów IT-WiBe21 dla obiektów migracji, stworzony w marcu 2003 r. w wyniku selekcji oraz uzupełnienia głównego katalogu kryteriów, podczas warsz- tatów w Ministerstwie Spraw Wewnetrzn˛ ych, we współpracy z pracownikami BSI, BVA oraz C_sar

5.9.3 Główny katalog z kryteriami IT-WiBe21 dla scenariuszy migracji

Na ponizszych˙ stronach katalogu, przedstawione zostały wszystkie kryteria:

◦ kryteria według WiBe21 dla kompletnych scenariuszy migracyjnych (kolor granatowy)

◦ kryteria, które mozna˙ pomina˛c´ dla obiektów migracji (kolor pomaranczo´ wy)9

◦ dodatkowe kryteria dla projektów migracyjnych zamieszczone w WiBe21 (kolor niebieski)

Niniejszy podział opiera sie˛ na WiBe21:

1. 1. Koszty rozwoju i wdrazania˙ oraz korzysci´ z rozwoju

2. 2. Koszty wykorzystania przemysłowego oraz korzysci´ z wykorzystania przemysłowego

3. 3. Kryteria koniecznosci´

4. 4. Kryteria jakoscio´ wo - strategiczne

5. Wskazówki i objasnienia´

9Patrz katalog specjalnych kryteriów dla obiektów migracji SPIS RYSUNKÓW 517

5.9.3.1 Koszty rozwoju / wdrozenia˙ oraz korzysci´ z rozwoju SPIS RYSUNKÓW 518

5.9.3.2 Koszty pracy i korzysci´ z pracy SPIS RYSUNKÓW 519

Wskazówka odnosnie´ kosztów pracy / korzysci´ z pracy: Wszystkie pozycje zawieraja˛ przykładowe informacje odnosnie´ kosztów i korzysci,´ tak jak w punktach 2.1.1 i 2.4.4 . Nie zostały tu one zaprezentowane z braku miejsca.

5.9.3.3 Kryterium koniecznosci´ SPIS RYSUNKÓW 520

5.9.3.4 Kryteria jakosciowo´ - strategiczne SPIS RYSUNKÓW 521

5.9.3.5 Wskazówki i objasnienia´

5.9.4 Specjalny katalog z kryteriami IT-WiBe21 dla obiektów migracji

POZYCJA NAZWA KRYTERIÓW 1 koszty rozwoju oprogramowania / koszty wdrozenia˙ oraz korzysci´ z rozwoju oprogramowania / korzysci´ z wdrozenia˙ 1.1 koszty rozwoju / wdrozenia˙ nowej procedury informatycznej 1.1.1 koszty planowania i wdrozenia˙ / rozwoju 1.1.1.1 koszty osobowe (własnego personelu) 1.1.1.2 koszty doradztwa zewnetrzne˛ go 1.1.1.3 koszty systemu 1.1.2 koszty osprzetu˛ 1.1.2.1 host / serwer, praca sieciowa 1.1.2.1.1 stacje robocze 1.1.2.1.2 koszty oprogramowania 1.1.2.2 koszty rozwoju bad˛ z´ nabycia oprogramowania SPIS RYSUNKÓW 522

1.1.2.2.1 koszty dostosowania oprogramowania i / lub interfejsów 1.1.2.2.3 koszty oceniania, certyﬁkacji i zabezpieczenia jakosci´ 1.1.2.3 koszty instalacji 1.1.2.3.4 koszty osobowe przypadajace˛ na instalacje˛ sytemu 1.1.3 koszty wdrozenia˙ systemu 1.1.3.1 test(y) systemu i integracji 1.1.3.2 koszty instalacji systemu 1.1.3.3 przeniesienie danych 1.1.3.4 pierwsze szkolenie uzytko˙ wników i specjalistycznego personelu IT 1.1.3.5 koszty wdrozenia˙ do pracy uzytko˙ wników i specjalistycznego personelu IT 2 koszty pracy i korzysci´ z pracy 2.1 biez˙ace˛ koszty rzeczowe / oszczedno˛ sci´ na kosztach rzeczowych 2.1.2 (procentowe) koszty hostów, serwerów i sieci 2.1.2.1 biez˙ace˛ koszty dzieki˛ odejsciu´ procedury informatycznej NOWE 2.1.2.2 biez˙ace˛ oszczedno˛ sci´ dzieki˛ odejsciu´ procedury informatycznej STARE 2.1.3 (procentowe) koszty stacji roboczych 2.1.3.1 biez˙ace˛ koszty dzieki˛ odejsciu´ procedury informatycznej NOWE 2.2 biez˙ace˛ koszty rzeczowe / oszczedno˛ sci´ wynikajace˛ z bie- z˙ac˛ ych kosztów rzeczowych 2.2.2 (procentowe) koszty na stacje robocze 2.2.2.1 biez˙ace˛ koszty dzieki˛ odejsciu´ procedury informatycznej NOWE 2.2.2.2 biez˙ace˛ koszty osobowe / oszczedno˛ sci´ wynikajace˛ z biez˙a-˛ cych kosztów osobowych 2.2.3 opieka nad systemem i administracja systemem 2.2.3.1 biez˙ace˛ koszty dzieki˛ odejsciu´ procedury informatycznej NOWE SPIS RYSUNKÓW 523

2.2.3.2 biez˙ace˛ korzysci´ dzieki˛ odejsciu´ procedury informatycznej STARE 2.3 biez˙ace˛ koszty / oszczedno˛ sci´ podczas konserwacji / opieki nad systemem 2.3.1 konserwacja / opieka nad osprzetem˛ 2.3.1.1 biez˙ace˛ koszty dzieki˛ odejsciu´ procedury informatycznej NOWE 2.3.1.2 biez˙ace˛ korzysci´ dzieki˛ odejscio´ procedury informatycznej STARE 2.3.2 konserwacja / uaktualnienie oprogramowania 2.3.2.1 biez˙ace˛ koszty dzieki˛ odejsciu´ procedury informatycznej NOWE 2.3.2.2 biez˙ace˛ korzysci´ dzieki˛ odejscio´ procedury informatycznej STARE 2.3.3 koszty zastepo˛ wania / uzupełniania 2.3.3.1 biez˙ace˛ koszty dzieki˛ odejsciu´ procedury informatycznej NOWE 2.3.3.2 biez˙ace˛ korzysci´ dzieki˛ odejscio´ procedury informatycznej STARE 2.4 pozostałe biez˙ace˛ koszty i oszczedno˛ sci´ 2.4.2 koszty towarzyszace˛ go zewnetrzne˛ go doradztwa 2.4.2.1 biez˙ace˛ koszty dzieki˛ odejsci´ procedury informatycznej NOWE 2.4.2.2 biez˙ace˛ korzysci´ dzieki˛ odejsciu´ procedury informatycnej STARE 2.4.4 pozostałe biez˙ace˛ koszty i korzysci´ 2.4.4.1 biez˙ace˛ koszty dzieki˛ odejsciu´ procedury informatycznej NOWE 2.4.4.2 biez˙ace˛ korzysci´ dzieki˛ odejsciu´ procedury informatycznej STARE

3 Kryteria koniecznosci´ 3.1 koniecznos´c´ zastapienia˛ starego systemu SPIS RYSUNKÓW 524

3.1.1 wsparcie - kontynuacja starego systemu 3.1.2 stabilnosć´ starego systemu 3.1.2.1 błedy˛ i awarie („downtime“) 3.1.2.2 problemy z konserwacja,˛ personel – waskie˛ gardło 3.1.3 elastycznosć´ starego systemu 3.1.3.1 rozbudowa / poszerzenie granic 3.1.3.2 kompatybilnosć,´ problemy z interfejsami aktualnie / w przyszłosci´ 3.1.3.3 przyjaznosć´ dla uzytko˙ wnika 3.2 zachowanie przepisów i praw urzedo˛ wych 3.2.1 zachowanie zapisów ustawowych 3.2.2 spełnienie kryteriów bezpieczenstwa´ i ochrona danych 3.2.3 prawidłowosć´ przebiegu prac 3.2.4 spełnienie zadan´ i zalecen´

4 kryteria jakosciowo´ - strategiczne 4.1 priorytet zamiaru informatycznego 4.1.1 znaczenie wewnatrz˛ informatycznej koncepcji ramowej 4.1.2 wkomponowanie w rozbudowe˛ informatyczna˛ całej administracji federalnej 4.1.3 skutki dla rozmówców 4.1.4 charakter projektu pilotazo˙ wego 4.1.5 niezalezno˙ s´c´ od producenta 4.2 wzrost jakosci´ podczas wykonywania specjalistycznych zadan´ 4.2.1 podniesienie wydajnosci´ podczas wykonywania zadan´ 4.2.2 przyspieszenie przebiegu i procesów prac 4.3 sterowanie informacja˛ na poziomie administracyjno - poli- tycznym 4.3.1 udostepnienie˛ informacji dla decydentów i kontrola 4.3.2 wsparcie procesu decyzyjnego / procesu kierowania 4.4 efekty dotyczace˛ pracowników 4.4.1 atrakcyjnos´c´ warunków pracy SPIS RYSUNKÓW 525

4.4.2 zapewnienie kwalifikacji / rozszerzenie kwalifikacji 4.4.3 powszechnosć´ / dostepno˛ sć´ wykształcenia 4.5 efekty bliskosci´ dla obywatela 4.5.4 poprawa wizerunku 4.6 powszechnosć´ / dostepno˛ sć´ oprogramowania 4.6.1 stopien´ przenikniecia˛ rynku 4.6.2 niezalezne˙ wsparcie 4.6.3 posiadane certyfikaty na oprogramowanie 4.6.4 narzedzia˛ do administrowania oprogramowaniem 4.7 bezepieczenstwo´ informatyczne 4.7.1 bezpieczenstwo´ komunikacji 4.7.2 bezpieczenstwo´ aplikacji 4.7.3 zabezpieczenie przed awaria˛ 4.7.4 zarzadzanie˛ bezpieczenstwem´ 4.7.5 bezpieczenstwo´ inwestycji i planowania

5.9.5 Objasnienie´ kryteriów uzupełniajacych˛

Ponizej˙ przedstawione zostały kryteria, które w ramach istniejace˛ go WiBE 21 wersja 3.0 oraz uzupełniajac˛ ych wskazówek i zalecen´ z roku 2000 (patrz wyzej)˙ zostały dodane10 do ocen ekonomicznych projektów migracji znanych juz˙ z dotychczasowych kryteriów. Dane usystematyzo- wane zostały według danych zapisanych w WiBe21 i dołaczone˛ w nawiasach „()“ za nazwa.˛

5.9.5.1 Koszty wdrozenia˙ / korzysci´ z wdrozenia˙ (1.1)

Podczas migracji całego srodo´ wiska projekty migracyjne obejmuja˛takze˙ specjalistyczne aplikacje, w przypadku których trzeba stworzyc´ nowe programy albo wymagane jest przeprogramowa- nie. Czynnosci´ te nalezy˙ wykazac´ w „kosztach rozwoju“. Podczas migracji obiektów migracyjnych koszty rozwoju z reguły nie wystepuj˛ a,˛ ale wystapi˛ a˛ koszty wdrozenia.˙ Aby to podkresli´ c,´ rozszerzono kryterium „koszty rozwoju“ o pojecie˛ „koszty wdrozenia˙ 11“.

10Patrz „Specjalny katalog kryteriów IT-WiBe21 dla projektów migracyjnych“, stworzony we współpracy BMI, BSI, BVA i C_sar. 11Patrz pozycje kryterium: 1., 1.1 oraz 1.1.1 SPIS RYSUNKÓW 526

5.9.5.2 Powszechnosć´ / dostepno˛ sć´ wykształcenia (4.4.3) Nieniejsze kryterium ukierunkowane jest na powszechosć´ wykształcenia i dostepno˛ sć´ odpowiedniego personelu. Znaczenie tego kryterium nalezy˙ oceniac´ jakoscio´ wo.

Powszechnos´c´ / dostepno˛ s´c´ (wy)kształcenia

0 2 4 6 8 10

personel z personel jest personel jest do- personel jest do- personel jest pra- wymagana wy- wymaganym dostepn˛ y, jednak stepn˛ y, kształce- stepn˛ y w ograni- wie niedostepn˛ y, kształcenie nie wykształceniem kształcenie ofe- nie jest przewaz-˙ czonym zakresie, wiedze˛ mozna˙ jest dostepne˛ na jest dostepn˛ y na rowane jest tylko nie organizowane kształcenie trzeba przekazac´ tylko rynku a kształ- rynku; wykształ- w kilku centrach w ramach urzedu˛ zorganizowac´ w w ograniczonym cenie nie jest cenie pokrywa ramach urzedu˛ zakresie oferowane wszystkie obszary

5.9.5.3 Powszechnos´c´ / dostepno˛ s´c´ oprogramowania (4.6) Stopien´ przenikniecia˛ rynku (4.6.1) Nalezy˙ tu ocenic´ udział w rynku, jaki posiada oprogramowanie, które ma byc´ zastosowane. W przypadku znikomej albo niepewnej obecnosci´ na rynku, istnieje niebezpieczenstwo,´ ze˙ oprogramowanie, wzglednie˛ jego dalszy rozwój zostana˛ wstrzymane. Ponadto dobre przenikanie rynku swiadczy´ o wysokiej akceptacji12 bad˛ z´ o intensywnym korzystywaniu z oprogramownia przez uzytko˙ wników, z czego mozna˙ wywnioskowac´ jego rozwój.

Przenikanie rynku

0 2 4 6 8 10

produkt jest ofe- produkt jest produkt jest ofe- produkt jest produkt jest ofe- produkt nie jest rowany wszedzie˛ oferowany tylko rowany regional- oferowany w rowany tylko in- juz˙ oferowany przez wybranych nie pojedynczych dywidualnie dystrybutorów miejscach

Niezalezne˙ wsparcie (4.6.2) Niniejsze kryterium zajmuje sie˛ mozliwo˙ sci´ a˛ otrzymania dla oprogramowania, które ma byc´

12Akceptacja nie zawsze jest najwazniejsza.˙ Polityka biznesowa wymusza w rózn˙ ych przypadkach decyzje na korzys´c´ lepiej zoptymalizowanych albo bardziej opłacalnych systemów. SPIS RYSUNKÓW 527

zastosowane, wsparcia ze strony istniejac˛ ych na rynku, niezalezn˙ ych przedsiebiorstw˛ . W oparciu o zasade˛ ochrony inwestycji zapewni to mozliwo˙ s´c´ dalszego korzystania z oprogramowania, nawet gdy producent nie bedzie˛ juz˙ w stanie kontynuowac´ wsparcia.

Niezalezne˙ wsparcie

0 2 4 6 8 10

wsparcie ofe- wsparcie ofero- wsparcie ofe- wsparcie ofe- wsparcie ofe- wsparcie nie jest rowane jest wane jest tylko rowane jest rowane jest w rowane jest (juz)˙ oferowane wszedzie˛ przez wybranych regionalnie pojedynczych indywidualnie dystrybutorów miejscach

Posiadane certyfikaty na oprogramowanie (4.6.3) Za pomoca˛ tego kryterium nalezy˙ szukac´ odpowiedzi na pytanie czy oprogramowanie, które ma byc´ zastosowane odpowiada wymaganiom prawnym bad˛ z´ specyficznym dla urzedu˛ lub branzy˙ , czy tez˙ moze˙ trzeba je samemu stworzyc.´ W pierwszym przypadku o certyfikaty troszczy sie˛ producent / dostawca, w zwiazku˛ z tym nie przewiduje sie˛ ponoszenia kosztów własnych. W drukim przypadku trzeba samemu uzyskac´ biez˙ace˛ certyfikaty, aby zagwarantowac´ zwykłe pokrycie pro- cesów biznesowych. W takiej sytuacji powstaja˛ koszty własne, które mozna˙ obliczyc´ ryczałtem.

Posiadane certyﬁkaty na oprogramowanie

0 2 4 6 8 10

oprogramowanie oprogramowanie oprogramowanie oprogramowanie oprogramowanie oprogramowanie posiada cer- posiada certy- posiada jednora- posiada cze-˛ posiada szczat-˛ nie posiada tyfikat, który fikat, który nie zowy certyfikat scio´ wa˛ certyfika- kowa˛ certyfikacje˛ certyfikatu, nie jest regularnie jest regularnie cje˛ lub tylko zalece- mozna˙ go tez˙ odnawiany odnawiany nia zdobyc´

Dostepno˛ s´c´ narzedzi˛ do administrowania oprogramowaniem (4.6.4) Administrowanie oprgramowaniem, które ma byc´ zastosowane, okazuje sie˛ w niektórych przypadkach mało wygodne a nawet trudne. W niniejszym kryterium nalezy˙ przeanalizowac´ narze-˛ dzia, które przejmuja˛ albo wspieraja˛ zarzadzanie˛ tabelami i podstawowymi danymi. Za pomoca˛ odpowiednio inteligentnych narzedzi˛ mozna˙ zwiekszy˛ c´ zakres i jakos´c´ administrowania oraz zoptymalizowac´ stosowanie zasobów.

Dostepno˛ s´c´ narzedzi˛ do administrowania oprogramowaniem

0 2 4 6 8 10 SPIS RYSUNKÓW 528

na rynku ist- narzedzia˛ do narzedzia˛ do narzedzia˛ do narzedzia˛ do narzedzia˛ do nieje dos´c´13 administrowania administrowania administrowa- administrowania administrowania narzedzi˛ do dostepne˛ sa˛ dostepne˛ sa˛ tylko nia sa˛ ledwo nalezy˙ tworzyc´ nie sa˛ dostepne˛ administrowania warunkowo sporadycznie niedostepne˛ indywidualnie i nie mozna˙ ich oprogramowa- indywidualnie niem stworzyc´

5.9.5.4 Bezpieczenstwo´ informatyczne (4.7)

„Bezpieczenstwo“´ wpisuje sie˛ po cze˛sci´ w kryteria koniecznosci´ (patrz „downtime“ albo „Ochrona i bezpieczenstwo´ danych“). W tym miejscu nalezy˙ wrócic´ do tego tematu, jednak tym razem z punktu widzenia strategicznego i jakoscio´ wego oraz nalezy˙ wskazac´ na udział zarzadzania.˛

Bezpieczenstwo´ komunikacji (4.7.1) Za pomoca˛ nieniejszego kryterium nalezy˙ sprawdzac´ bezpieczenstwo´ wewnetrznej˛ i przede wszystkim zewnetrznej˛ komunikacji. Jak zabezpieczona jest transmisja danych? Czy stosowane sa˛ bezpieczne protokoły? Czy istnieje zabezpieczenie transmisji, kontrola dostepu,˛ itd.?

Bezpieczenstwo´ komunikacji

0 2 4 6 8 10

niezagrozone˙ prawie niezagro- troche˛ zagrozone,˙ przecietnie˛ ponadprzecietnie˛ bardzo silnie za- zone˙ w granicach tole- zagrozone,˙ zagrozone,˙ grozone,˙ nie da- rancji zakłócenia ucia˛zliwo˙ sci´ jace˛ sie˛ tolerowac´

Bezpieczenstwo´ aplikacji (4.7.2) Czy oprogramowanie jest sprawdzone pod katem˛ bezpieczenstwa´ informatycznego? Na ile jest ono podatne na ataki z zewnatrz,˛ wirusy itd.? Czy oprogramowanie ma budowe˛ modularna˛ (rozdział systemu od aplikacji, minimalizacja ilosci´ aplikacji do koniecznych funkcji)? Czy istnieja˛ procedury kontroli dostepu?˛

Bezpieczenstwo´ aplikacji

0 2 4 6 8 10

13Dos´c´ oznacza, ze˙ narzedzia˛ oferowane sa˛ przez wiele niezalezn˙ ych przedsiebiorstw˛ SPIS RYSUNKÓW 529

Zabezpieczenie przed awaria˛ (4.7.3) Jak silnie na bezpieczenstwo´ pracy wpływaja˛ awarie systemu? Czy istnieja˛ odpowiednie Re- covery - Routinen?

Zabezpieczenie przed awaria˛

0 2 4 6 8 10

Zarzadzanie˛ bezpieczenstwem´ (4.7.4) Czy istnieje zarzadzanie˛ bezpieczenstwem?´ Czy istnieje pomysł na bezpieczenstwo,´ który jest znany wszystkim? Czy istnieje opisany proces kontroli bezpieczenstwa´ oraz jego dokumentacja?

Zarzadzanie˛ bezpieczenstwem´

0 2 4 6 8 10

istnieje w przewazaj˙ acej˛ cze˛scio´ wo istnieje tylko istnieja˛ zaledwie nie istnieje cze˛sci´ istnieje istnieje miejscami sporadyczne slady´

Bezpieczenstwo´ inwestycji i planowania (4.7.5) Niniejsze kryterium zajmuje sie˛ suma˛wpływów wszystkich wczesniej´ przedstawionych, waz-˙ nych kryteriów bezpieczenstwa´ i wskazuje czy inwestycja i zwiazane˛ z nia˛ plany sa˛ nadal uzasadnione.

Bezpieczenstwo´ inwestycji i planowania

0 2 4 6 8 10

niezagrozone˙ prawie niezagro- troche˛ zagrozone,˙ przecietnie˛ ponadprzecietnie˛ bardzo silnie za- zone˙ w granicach tole- zagrozone,˙ zagrozone,˙ grozone,˙ nie dajace˛ rancji zakłócenia ucia˛zliwo˙ sci´ sie˛ tolerowac´