plik pdf
Transkrypt
plik pdf
Poradnik nt. migracji na Wolne Oprogramowanie na serwerach i desktopach wersja 1.0 – lipiec 2003 r. OpenPoland.org 20 lipca 2004 1 Rzadowy ˛ Urzad ˛ Koordynacji i Doradztwa ds. Informatyzacji przy Ministerstwie Spraw Wewn˛etrznych Republiki Federalnej Niemiec (KBSt) 2 Szanowni Państwo! Niniejszy poradnik został przetłumaczony przez osoby wchodzace ˛ w skład grupy OpenPoland.org. Pragniemy zaznaczyć, że nasza praca została wykonana nie na zlecenie, lecz za zgoda˛ BMI1 . Jednocześnie informujemy, że tekst niniejszego tłumaczenia udost˛epniamy nieodpłatnie i nie wolno go sprzedawać w żadnej postaci. Powyższe zasady zredagowane zostały w oparciu o uzgodnienia poczynione z BMI jeszcze przed rozpocz˛eciem prac nad tłumaczeniem. Mamy nadziej˛e, że rozwiazania ˛ przedstawione w poradniku już niedługo zyskaja˛ wielu zwolenników, szczególnie wśród szerokiego grona osób odpowiedzialnych za funkcjonowanie infrastruktury informatycznej w naszym kraju. Zach˛ecamy Państwa do współpracy nad rozwojem poradnika. Prosimy o zgłaszanie konstruktywnych, krytycznych uwag na adres: [email protected] . Na zakończenie pragniemy podkreślić, że nie jesteśmy organizacja˛ polityczna˛ i tym samym nie popieramy wykorzystywania naszej kampanii na rzecz Wolnego Oprogramowania do współzawodnictwa politycznego. Zach˛ecamy do owocnej lektury! Grupa OpenPoland.org 1 Niemiecki odpowiednik polskiego MSW. Spis treści 1 2 Wprowadzenie 16 1.1 Geneza poradnika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2 O poradniku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.3 Jak korzystać z poradnika? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.4 Wskazówki dla decydentów . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.4.1 Podstawowe zalecenia . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.4.2 Migracja kontynuacyjna i zast˛epujaca ˛ . . . . . . . . . . . . . . . . . . . 22 1.4.3 1.4.4 Różne drogi migracji . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Porównanie alternatywnych rozwiazań ˛ . . . . . . . . . . . . . . . . . . 23 1.4.5 Istotne zagadnienia przyszłościowe . . . . . . . . . . . . . . . . . . . . 24 1.4.6 Korzyści ekonomiczne . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Najważniejsze zagadnienia 2.1 2.2 2.3 28 Ważne definicje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.1.1 2.1.2 Open Source, Free Software . . . . . . . . . . . . . . . . . . . . . . . . 28 Oprogramowanie własnościowe . . . . . . . . . . . . . . . . . . . . . . 29 2.1.3 Komercyjne oprogramowanie linuksowe . . . . . . . . . . . . . . . . . . 29 2.1.4 2.1.5 Migracja zast˛epujaca ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Migracja kontynuacyjna . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Etapy migracji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.2.1 Punkt wyjścia - Microsoft Windows . . . . . . . . . . . . . . . . . . . . 31 2.2.2 2.2.3 Przeglad ˛ systemu dla migracji zast˛epujacej ˛ . . . . . . . . . . . . . . . . 34 Przeglad ˛ systemu dla migracji kontynuacyjnej . . . . . . . . . . . . . . . 35 2.2.4 Wewn˛etrzne zależności systemu opartego o rozwiazania ˛ firmy Microsoft 36 Dystrybucje Linuksa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.3.1 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3 SPIS TREŚCI 4 2.3.2 Debian GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.3.3 SuSE Linux Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.3.4 2.3.5 Red Hat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Certyfikaty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.3.6 Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.4 Licencje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.4.1 GPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.4.2 2.5 3 Lesser GPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.4.3 BSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Zbieranie informacji o projektach . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.5.1 Doświadczenia z projektów migracyjnych . . . . . . . . . . . . . . . . . 50 2.5.2 Opinie ekspertów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Techniczne opisy migracji 54 3.1 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.2 Zarzadzanie ˛ plikami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.2.1 Przeglad ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.2.2 3.2.3 Windows NT 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.2.2.1 3.2.2.2 Wymagania odnośnie funkcjonalności . . . . . . . . . . . . . 57 System plików NTFS4 . . . . . . . . . . . . . . . . . . . . . 58 3.2.2.3 Ustawianie praw dost˛epu . . . . . . . . . . . . . . . . . . . . 62 3.2.2.4 Użytkownicy i znaczenie grup . . . . . . . . . . . . . . . . . . 63 3.2.2.5 3.2.2.6 Narz˛edzia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Protokoły sieciowe . . . . . . . . . . . . . . . . . . . . . . . 66 3.2.2.7 Zestawianie połaczenia ˛ . . . . . . . . . . . . . . . . . . . . . 67 3.2.2.8 3.2.2.9 Migracja - szczegóły robocze . . . . . . . . . . . . . . . . . . 67 Tematy pokrewne . . . . . . . . . . . . . . . . . . . . . . . . 68 Migracja zast˛epujaca ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.2.3.1 3.2.3.2 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Generalne porównanie zakresu funkcji poszczególnych serwerów plików . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.2.3.3 3.2.4 Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Migracja kontynuacyjna . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.2.4.1 Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.2.4.2 Windows 2003 Server . . . . . . . . . . . . . . . . . . . . . . 87 SPIS TREŚCI 3.3 5 Drukowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 3.3.1 Przeglad ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 3.3.2 3.3.3 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Punkt wyjścia - drukowanie pod Windows NT 4 . . . . . . . . . . . . . . 90 3.3.4 3.3.5 3.3.3.1 LPR / LPD w Windows NT 4.0 . . . . . . . . . . . . . . . . . 91 3.3.3.2 3.3.3.3 Inne porty sieciowe . . . . . . . . . . . . . . . . . . . . . . . 91 Bezpośrednie drukowanie ze stacji roboczej . . . . . . . . . . 92 3.3.3.4 Drukowanie poprzez serwer wydruku . . . . . . . . . . . . . . 92 3.3.3.5 3.3.3.6 Metoda „Point & Print“ . . . . . . . . . . . . . . . . . . . . . 93 Protokoły sieciowe . . . . . . . . . . . . . . . . . . . . . . . 96 3.3.3.7 Nadawanie praw dost˛epu . . . . . . . . . . . . . . . . . . . . 97 3.3.3.8 3.3.3.9 Narz˛edzia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Migracja - szczegóły robocze . . . . . . . . . . . . . . . . . . 97 Migracja zast˛epujaca ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 3.3.4.1 Wymagania odnośnie funkcjonalności . . . . . . . . . . . . . 99 3.3.4.2 3.3.4.3 Obsługa standardów wyróżniajacych ˛ si˛e w procesie drukowania 101 Integracja w środowiskach klienckich Windows . . . . . . . . 104 3.3.4.4 Możliwości dostosowawcze 3.3.4.5 107 J˛ezyki opisu stron . . . . . . . . . . . . . . . . . . . . . . . . 108 3.3.4.6 Techniczna zmiana funkcji sterownika . . . . . . . . . . . . . 108 3.3.4.7 Architektury systemu drukowania . . . . . . . . . . . . . . . . 110 Migracja kontynuacyjna . . . . . . . . . . . . . . . . . . . . . . . . . . 111 3.3.5.1 3.4 Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Autoryzacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 3.4.1 3.4.2 Przeglad ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Punkt wyjścia - Windows NT 4 . . . . . . . . . . . . . . . . . . . . . . 114 3.4.2.1 Domeny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 3.4.2.2 3.4.2.3 Wiele domen i relacje zaufania . . . . . . . . . . . . . . . . . 115 NT jako usługa katalogowa . . . . . . . . . . . . . . . . . . . 116 3.4.2.4 Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 3.4.2.5 3.4.2.6 Podstawy sieci . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Replikacja plików . . . . . . . . . . . . . . . . . . . . . . . . 119 3.4.2.7 Narz˛edzia administracyjne . . . . . . . . . . . . . . . . . . . 119 SPIS TREŚCI 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.3 3.4.2.13 Smart Card (mocne mechanizmy autoryzacji) . . . . . . . . . 123 Migracja zast˛epujaca ˛ - Linux, Samba i OpenLDAP . . . . . . . . . . . . 123 3.4.3.1 Autoryzacja z wykorzystaniem Linux / OpenLDAP i Samby . . 124 3.4.3.2 3.4.3.3 Synchronizacja hasła . . . . . . . . . . . . . . . . . . . . . . 124 Relacje zaufania . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.4.3.4 WINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.4.3.5 3.4.3.6 Ograniczenia w stosowaniu OpenLDAP i Samby . . . . . . . . 125 Kombinacja OpenLDAP i Active Directory . . . . . . . . . . . 126 3.4.3.7 Narz˛edzia umożliwiajace ˛ migracj˛e z Windows NT do Samby / OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 3.4.3.8 3.4.3.9 PDC i BDCs w jednej domenie Samby . . . . . . . . . . . . . 127 Samba jako członek domeny Active Directory . . . . . . . . . 127 3.4.3.10 Narz˛edzia administracyjne . . . . . . . . . . . . . . . . . . . 127 3.4.4 3.5 Migracja kontynuacyjna . . . . . . . . . . . . . . . . . . . . . . . . . . 128 3.4.4.1 Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Usługi sieciowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 3.5.1 3.5.2 3.5.3 3.5.4 Przeglad ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Punkt wyjścia - 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 Configuration Protocol (DHCP) . . . . . . . . . 133 Migracja zast˛epujaca ˛ - usługi sieciowe pod Linuksem . . . . . . . . . . . 135 3.5.3.1 Domain Name System (DNS) . . . . . . . . . . . . . . . . . . 136 3.5.3.2 3.5.3.3 Dynamic Host Configuration Protocol (DHCP) . . . . . . . . . 137 Windows Internet Name Service (WINS) . . . . . . . . . . . . 138 3.5.3.4 Network Time Protocol (NTP) . . . . . . . . . . . . . . . . . 138 Migracja kontynuacyjna - usługi sieciowe pod Windows 2000 . . . . . . 138 3.5.4.1 WINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 3.5.4.2 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 SPIS TREŚCI 7 3.5.4.3 3.6 Kontrola i zarzadzanie ˛ systemem . . . . . . . . . . . . . . . . . . . . . . . . . . 140 3.6.1 3.6.2 Przeglad ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Punkt wyjścia - serwery zarzadzaj ˛ ace ˛ systemem pod Windows NT 4 . . . 140 3.6.3 Migracja zast˛epujaca ˛ - Linux . . . . . . . . . . . . . . . . . . . . . . . . 143 3.6.4 3.6.3.1 3.6.3.2 Administrowanie oprogramowaniem . . . . . . . . . . . . . . 143 Administrowanie siecia˛ . . . . . . . . . . . . . . . . . . . . . 144 3.6.3.3 Administrowanie serwerami . . . . . . . . . . . . . . . . . . . 144 3.6.3.4 3.6.3.5 Systemy złożone . . . . . . . . . . . . . . . . . . . . . . . . . 145 Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Migracja kontynuacyjna - Windows 2000 . . . . . . . . . . . . . . . . . 146 3.6.4.1 3.6.4.2 3.7 DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Microsoft Operations Manager . . . . . . . . . . . . . . . . . 146 Application Center . . . . . . . . . . . . . . . . . . . . . . . . 147 Usługi katalogowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 3.7.1 Przeglad ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 3.7.2 3.7.3 Podstawy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Active Directory Service (ADS) . . . . . . . . . . . . . . . . . . . . . . 152 3.7.4 3.7.3.1 Nast˛epca usługi logowania stosowanej w Windows NT 4 . . . 153 3.7.3.2 3.7.3.3 Mechanizm autoryzacji Kerberos . . . . . . . . . . . . . . . . 154 Nowości w strukturze . . . . . . . . . . . . . . . . . . . . . . 155 3.7.3.4 Przestrzeń adresowa DNS i infrastruktura . . . . . . . . . . . . 158 3.7.3.5 3.7.3.6 Usługa katalogowa i jej schemat . . . . . . . . . . . . . . . . 168 ADS jako podstawa . . . . . . . . . . . . . . . . . . . . . . . 169 3.7.3.7 Narz˛edzia administracyjne . . . . . . . . . . . . . . . . . . . 169 3.7.3.8 Certyfikacja . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 3.7.3.9 Smart Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Migracja zast˛epujaca ˛ - Samba i Open LDAP . . . . . . . . . . . . . . . 171 3.7.4.1 Wymagania odnośnie funkcjonalności . . . . . . . . . . . . . 171 3.7.4.2 3.7.4.3 Oceniane produkty . . . . . . . . . . . . . . . . . . . . . . . . 171 Generalne porównanie zakresu funkcji udost˛epnianych przez NTDS, Active Directory i OpenLDAP . . . . . . . . . . . . . 172 3.7.4.4 3.7.4.5 Autoryzacja z wykorzystaniem Linuksa / OpenLDAP i Samby 173 Centralne administrowanie informacjami o hostach z wykorzystaniem Linuksa i OpenLDAP . . . . . . . . . . . . . . . . 173 SPIS TREŚCI 3.7.5 3.8 3.9 8 3.7.4.6 Integracja innych aplikacji . . . . . . . . . . . . . . . . . . . . 174 3.7.4.7 Narz˛edzia administracyjne . . . . . . . . . . . . . . . . . . . 174 3.7.4.8 3.7.4.9 Zachowanie podczas pracy i zużycie zasobów . . . . . . . . . 175 Akceptacja użytkowników . . . . . . . . . . . . . . . . . . . 175 Migracja kontynuacyjna - Wprowadzenie do ADS . . . . . . . . . . . . 175 3.7.5.1 3.7.5.2 Kolejność . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Docelowa architektura . . . . . . . . . . . . . . . . . . . . . . 176 3.7.5.3 Przeglad ˛ wariantów migracji . . . . . . . . . . . . . . . . . . 176 3.7.5.4 3.7.5.5 Zadania migracyjne . . . . . . . . . . . . . . . . . . . . . . . 181 Active Directory pod katem ˛ Windows 2003 . . . . . . . . . . 181 3.7.5.6 Active Directory w minimalnej postaci . . . . . . . . . . . . . 182 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 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 3.9.1 Przeglad ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 3.9.2 Podstawy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 3.9.3 3.9.4 .Net Web-Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 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 bezpieczeństwo . . . . . . . . . . . . . . . . . . 198 3.11.3.3 Dodatkowe składniki Internet Information Server . . . . . . . 199 3.11.4 Migracja zast˛epujaca ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 TREŚCI 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 Skalowalność . . . . . . . . . . . . . . . . . . . . . . . . . . 221 3.13.3.6 Nadawanie praw dost˛epu . . . . . . . . . . . . . . . . . . . . 222 3.13.3.7 Integracja systemu . . . . . . . . . . . . . . . . . . . . . . . . 222 3.13.3.8 Administrowanie . . . . . . . . . . . . . . . . . . . . . . . . 222 3.13.4 Migracja zast˛epujaca ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 pośredni . . . . . . . . . . . . . . . . . . . . . . . . . 228 3.13.4.6 Wskazówki . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 3.13.4.7 Zalecenia odnośnie niezależności . . . . . . . . . . . . . . . . 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 wyjścia - Microsoft Exchange 5.5 . . . . . . . . . . . . . . . . . . 234 3.14.3.1 Infrastruktura podstawowa . . . . . . . . . . . . . . . . . . . 234 3.14.3.2 Logiczne jednostki struktury . . . . . . . . . . . . . . . . . . 234 SPIS TREŚCI 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 Funkcjonalności użytkownika . . . . . . . . . . . . . . . . . . 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 zast˛epujaca ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 wyjścia - MS Office . . . . . . . . . . . . . . . . . . . . . . . . . 271 3.15.3.1 Funkcjonalności . . . . . . . . . . . . . . . . . . . . . . . . . 272 3.15.3.2 Środowisko programistyczne MS Office . . . . . . . . . . . . 273 3.15.4 Migracja zast˛epujaca ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 3.15.4.1 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . 276 3.15.4.2 Różnice w formacie plików w porównaniu z MS Office . . . . 279 3.15.4.3 Ograniczenia filtrów konwertujacych ˛ (filtrów importu) . . . . . 281 3.15.4.4 Różnice w działaniu . . . . . . . . . . . . . . . . . . . . . . . 283 3.15.4.5 Ważne kryteria analizy stanu . . . . . . . . . . . . . . . . . . 287 3.15.4.6 Przygotowanie do konwersji . . . . . . . . . . . . . . . . . . . 289 3.15.4.7 Konwertowanie . . . . . . . . . . . . . . . . . . . . . . . . . 292 3.15.4.8 Integracja zewn˛etrznych aplikacji . . . . . . . . . . . . . . . . 296 3.15.4.9 Migracja makr i sterowanie OLE / COM . . . . . . . . . . . . 296 SPIS TREŚCI 11 3.15.4.10 Środowisko programowania OOo/SO . . . . . . . . . . . . . . 297 3.15.4.11 Kompatybilność 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 Menedżery plików . . . . . . . . . . . . . . . . . . . . . . . . 308 3.15.6.4 Przegladarki ˛ WWW . . . . . . . . . . . . . . . . . . . . . . . 308 3.15.6.5 Klient poczty elektronicznej . . . . . . . . . . . . . . . . . . . 310 3.15.6.6 Inne narz˛edzia . . . . . . . . . . . . . . . . . . . . . . . . . . 311 3.15.7 Integracja aplikacji Windows przy użyciu 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 niezawodności . . . . . . . . . . . . . . . 342 3.17.1 Cele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 3.17.2 „Pi˛eć dziewiatek” ˛ a rzeczywistość . . . . . . . . . . . . . . . . . . . . . 343 3.17.3 Sposób podejścia 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 TREŚCI 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 wydajności ekonomicznej 352 4.1 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 4.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 4.3 4.4 4.2.1 4.2.2 Analiza kosztów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Analiza korzyści . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 4.2.3 IT-WiBe 21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 4.2.4 4.2.5 Koszty migracji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 TCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 4.2.6 Porównywalność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 4.2.7 4.2.8 Instalacja od podstaw a migracja . . . . . . . . . . . . . . . . . . . . . . 359 Obliczanie pełnych kosztów . . . . . . . . . . . . . . . . . . . . . . . . 359 Wymiar pieni˛eżny (operacyjny) . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 4.3.1 4.3.2 Obszary zastosowań . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 Kategorie kosztów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 4.3.3 Własności użytych kategorii podmiotów publicznych . . . . . . . . . . . 363 4.3.3.1 Małe urz˛edy . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 4.3.3.2 4.3.3.3 Urz˛edy średniej wielkości . . . . . . . . . . . . . . . . . . . . 364 Duże urz˛edy / centra obliczeniowe . . . . . . . . . . . . . . . 364 Wymiar strategiczny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 4.4.1 4.4.2 Spojrzenie makroekonomiczne . . . . . . . . . . . . . . . . . . . . . . . 365 Spojrzenie mikroekonomiczne . . . . . . . . . . . . . . . . . . . . . . . 366 4.5 Wyniki oceny wydajności ekonomicznej . . . . . . . . . . . . . . . . . . . . . . 366 4.6 Zalecenia migracyjne oparte na ocenie wydajności ekonomicznej . . . . . . . . . 368 4.6.1 Migracja pełna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 4.6.2 Migracja kontynuacyjna . . . . . . . . . . . . . . . . . . . . . . . . . . 371 4.6.3 Migracja cz˛eściowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 4.6.3.1 4.6.3.2 4.7 Migracja punktowa . . . . . . . . . . . . . . . . . . . . . . . 372 Migracja cz˛eściowa po stronie serwera . . . . . . . . . . . . . 373 Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 SPIS TREŚCI 4.8 4.9 5 13 Nakłady według różnych scenariuszy migracji . . . . . . . . . . . . . . . . . . . 375 4.8.1 Ogólne założenia dotyczace ˛ nakładów zwiazanych ˛ z migracja˛ . . . . . . 375 4.8.2 4.8.3 Nakłady na migracj˛e z Windows NT do Windows 2000 . . . . . . . . . . 377 Nakłady na migracj˛e z Windows NT do Linuksa . . . . . . . . . . . . . 381 4.8.4 Nakłady na migracj˛e z Exchange 5.5 do Exchange 2000 . . . . . . . . . 385 4.8.5 4.8.6 Nakłady na migracj˛e z Exchange 5.5 do Samsung Contact . . . . . . . . 386 Zalecenia odnośnie sposobu oceny produktów / grup produktów . . . . . 388 4.8.6.1 Generalne założenia . . . . . . . . . . . . . . . . . . . . . . . 388 4.8.6.2 4.8.6.3 Przykłady według struktury WiBe21 . . . . . . . . . . . . . . 389 Przykład migracji: Messaging / Groupware – duży urzad ˛ . . . 414 4.8.6.4 Przykłady migracji według kategorii kosztów informatyzacji . 415 4.8.6.5 4.8.6.6 Pełna migracja . . . . . . . . . . . . . . . . . . . . . . . . . . 416 Migracja kontynuacyjna . . . . . . . . . . . . . . . . . . . . . 421 4.8.6.7 Migracja cz˛eściowa . . . . . . . . . . . . . . . . . . . . . . . 426 Przykładowa ocena konieczności oraz jakości i strategii migracji . . . . . . . . . 430 4.9.1 4.9.2 Kryteria konieczności . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 Kryteria jakościowo - strategiczne . . . . . . . . . . . . . . . . . . . . . 430 4.9.3 Analiza korzyści . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 Zalecenia migracyjne 5.1 Ogólne wyjaśnienia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 5.1.1 5.2 440 Droga do podj˛ecia decyzji . . . . . . . . . . . . . . . . . . . . . . . . . 440 5.1.2 Ogólne zalecenia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442 Całkowita „zast˛epujaca ˛ migracja” . . . . . . . . . . . . . . . . . . . . . . . . . 444 5.2.1 5.2.2 Model architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 5.2.1.1 5.2.1.2 Stacje robocze . . . . . . . . . . . . . . . . . . . . . . . . . . 448 Serwer WWW . . . . . . . . . . . . . . . . . . . . . . . . . . 449 5.2.1.3 Składowanie plików . . . . . . . . . . . . . . . . . . . . . . . 449 5.2.1.4 5.2.1.5 Drukowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 Usługi sieciowe . . . . . . . . . . . . . . . . . . . . . . . . . 449 Średnie i duże urz˛edy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 5.2.2.1 Systemy zarzadzania ˛ bazami danych . . . . . . . . . . . . . . 451 5.2.2.2 5.2.2.3 Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 Usługi katalogowe . . . . . . . . . . . . . . . . . . . . . . . . 452 5.2.2.4 Zarzadzanie ˛ systemem . . . . . . . . . . . . . . . . . . . . . . 453 SPIS TREŚCI 14 5.2.3 Specjalizowane urz˛edy świadczace ˛ usługi informatyczne . . . . . . . . . 453 5.2.4 5.3 5.5 System zarzadzania ˛ bazami danych . . . . . . . . . . . . . . . 454 5.2.3.2 5.2.3.3 Serwery aplikacji . . . . . . . . . . . . . . . . . . . . . . . . 455 Zarzadzanie ˛ systemem . . . . . . . . . . . . . . . . . . . . . . 455 Małe urz˛edy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 5.2.4.1 5.2.4.2 Systemy zarzadzania ˛ bazami danych . . . . . . . . . . . . . . 456 Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 5.2.4.3 Usługa katalogowa . . . . . . . . . . . . . . . . . . . . . . . 457 5.2.4.4 Zarzadzanie ˛ systemem . . . . . . . . . . . . . . . . . . . . . . 457 Całkowita „kontynuacyjna migracja” . . . . . . . . . . . . . . . . . . . . . . . . 458 5.3.1 5.4 5.2.3.1 Minimalizacja stopnia integracji, zachowanie stopni dowolności . . . . . 460 5.3.2 Inne ścieżki migracji . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 Migracja cz˛eściowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 5.4.1 Migracja punktowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 5.4.2 Cz˛eściowa migracja po stronie serwera . . . . . . . . . . . . . . . . . . 465 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 środowiska docelowego wśród użytkowników . . . . . . . . . . . . . . . . . . . 476 5.5.3.4 Szkolenia dla użytkowników i administratorów . . . . . . . . . 477 5.5.3.5 Działania organizacyjne przygotowujace ˛ migracj˛e . . . . . . . 477 5.5.3.6 5.5.3.7 Właczenie ˛ wybranych pracowników . . . . . . . . . . . . . . 480 Określenie punktu wyjścia . . . . . . . . . . . . . . . . . . . 480 5.5.3.8 Spełnienie wymagań funkcjonalnych . . . . . . . . . . . . . . 481 5.5.3.9 Korzystanie z wartości doświadczalnych . . . . . . . . . . . . 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 jakości projektu . . . . . . . . 483 5.5.3.13 Opieka na etapie pracy . . . . . . . . . . . . . . . . . . . . . 485 5.6 Eksperci współpracujacy ˛ nad poradnikiem . . . . . . . . . . . . . . . . . . . . . 485 SPIS TREŚCI 15 5.7 Spis skrótów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 5.8 Słownik poj˛eć . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 / wdrożenia oraz korzyści z rozwoju . . . . . . 517 5.9.4 5.9.5 5.9.3.2 Koszty pracy i korzyści z pracy . . . . . . . . . . . . . . . . . 518 5.9.3.3 5.9.3.4 Kryterium konieczności . . . . . . . . . . . . . . . . . . . . . 519 Kryteria jakościowo - strategiczne . . . . . . . . . . . . . . . 520 5.9.3.5 Wskazówki i objaśnienia . . . . . . . . . . . . . . . . . . . . 521 Specjalny katalog z kryteriami IT-WiBe21 dla obiektów migracji . . . . . 521 Objaśnienie kryteriów uzupełniajacych ˛ . . . . . . . . . . . . . . . . . . 525 5.9.5.1 Koszty wdrożenia / korzyści z wdrożenia (1.1) . . . . . . . . . 525 5.9.5.2 Powszechność / dost˛epność wykształcenia (4.4.3) . . . . . . . 526 5.9.5.3 5.9.5.4 Powszechność / dost˛epność oprogramowania (4.6) . . . . . . . 526 Bezpieczeństwo informatyczne (4.7) . . . . . . . . . . . . . . 528 Rozdział 1 Wprowadzenie „Produkt zast˛epuje inny produkt wtedy, gdy okazuje si˛e, że zach˛eta do jego używania jest silniejsza niż koszty wynikajace ˛ z zamiany produktów i gdy przezwyci˛eżony zostanie opór wzgl˛edem zmian. Produkt zast˛epczy jest atrakcyjny dla odbiorcy wówczas, gdy oferuje on wyższa˛ wartość od dotychczas używanego produktu i nie jest od niego droższy. “ M.E. Porter 1.1 Geneza poradnika Trudno znaleźć lepsze określenie opisujace ˛ istot˛e intensywnej publicznej dyskusji, która toczy si˛e 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 konkurencyjności okr˛et flagowy Open Source jakim jest GNU/Linux już dawno uzyskał uprzywilejowana˛ pozycj˛e „produktu zast˛epczego”. Inne produkty, takie jak MySQL, PostgreSQL czy OpenOffice.org pewnie podażaj ˛ a˛ jego śladami. (Wszystkich, którym brakuje w tym miejscu serwera Apache, pragniemy poinformować, że zdaniem autorów produkt ten należy traktować jak oryginał, a nie jak produkt zast˛epczy. Jest on wr˛ecz klasykiem OSS). Wolny system operacyjny GNU/Linux jest szczególnym oprogramowaniem, które jako jedno z nielicznych odnotowuje dzisiaj stały wzrost zainteresowania. Obecnie już ponad 40 procent niemieckich przedsi˛ebiorstw i organizacji wykorzystuje go w procesach produkcyjnych, przy czym jest to tendencja rosnaca. ˛ Z uwagi na tak intensywny rozwój oprogramowania Open Source należałoby si˛e spodziewać, że wytłumaczenie tego zjawiska nie b˛edzie trudne. 16 ROZDZIAŁ 1. WPROWADZENIE 17 Jednak okazuje si˛e, że założenie to nie jest prawdziwe. Wr˛ecz przeciwnie. W branży informatycznej mało który temat prowadzi do tak kontrowersyjnych dyskusji o zaletach i wadach, jak wykorzystywanie oprogramowania Open Source. Należy przy tym zrozumieć, że roczne obroty ze sprzedaży samego systemu operacyjnego Windows wynosza˛ ponad 10 mld. USD, a zatem na toczac ˛ a˛ si˛e dyskusj˛e maja˛ także wpływ ważne interesy ekonomiczne. Obok wyjatkowości ˛ modelu licencji i cz˛esto pojawiajacych ˛ si˛e pytań dotyczacych ˛ jego wpływu na zmiany w branży informatycznej, dyskutowane sa˛ w jednakowym stopniu właściwości techniczne konkurujacych ˛ ze soba˛ produktów oraz ich parametry ekonomiczne. W sumie, siła˛ rzeczy, prowadzi to do uzyskania wielowymiarowej, kompleksowej i dajacej ˛ si˛e zinterpretować oceny. Dodatkowe znaczenie ma fakt, że w konkurencji - Open Source kontra Microsoft - nie chodzi o pojedyncze programy, lecz o niemalże kompletna˛ platform˛e dajac ˛ a˛ duży wybór oprogramowania. W tej bardzo skomplikowanej sytuacji, na która˛ maja˛ wpływ wielostronne interesy, decydujaca ˛ rola przypada obiektywnej i całościowej analizie. Odpowiednia ocena powinna uwzgl˛edniać nie tylko właściwości techniczne oprogramowania, lecz musi si˛e ona również opierać o konkretny punkt wyjścia dla ewentualnego wdrożenia, w szczególności o specyficzne finansowe, strukturalno - organizacyjne i polityczne warunki ramowe działalności administracji publicznej w Niemczech. 1.2 O poradniku Już sam tytuł poradnika wskazuje na to, że zasadnicze decyzje zwiazane ˛ z wprowadzaniem oprogramowania Open Source wpisuja˛ si˛e w „naturalny” cykl życia komercyjnego oprogramowania Microsoft. Dobrym tego przykładem jest wycofanie wsparcia technicznego dla wciaż ˛ szeroko rozpowszechnionego systemu operacyjnego Windows NT, którego nast˛epca wymaga z zasady innego sposobu zarzadzania ˛ domenami. Aby odróżnić zast˛epowanie tego oprogramowania produktami OSS od przejścia na produkty Microsoft nast˛epnej generacji, wprowadziliśmy poj˛ecie migracji zast˛epujacej ˛ i migracji kontynuacyjnej. W niniejszym poradniku nie skoncentrowaliśmy si˛e tylko na sposobach zastapienia ˛ już stosowanego oprogramowania, lecz także na wskazaniu rozwiazań ˛ optymalnie odpowiadajacych ˛ warunkom ekonomicznym. Poradnik migracyjny skierowany jest przede wszystkim do decydentów majacych ˛ wpływ na planowanie i wybór kierunku rozwoju w sektorze informatycznym. Pierwsza cz˛eść (rozdział 2) zajmuje si˛e przedstawieniem punktu wyjścia dla oprogramowa- ROZDZIAŁ 1. WPROWADZENIE 18 nia. Rozstrzyga on o sposobie przeprowadzenia migracji i stanowi przeglad ˛ podstawowej architektury oprogramowania Microsoft, jak również alternatywnej, opartej na otwartych standardach platformy Open Source. Tak zwana mapa systemu wskazuje przy tym możliwości zastapienia ˛ produktów pełniacych ˛ określone funkcje, innymi produktami i rozwiazaniami ˛ oraz pokazuje zwiazki ˛ pomi˛edzy poszczególnymi warstwami oprogramowania. Druga cz˛eść (rozdziały 3 i 4) jest próba˛ odpowiedzi na pytanie o możliwość potencjalnej migracji albo zastosowania całkiem nowych systemów IT oraz infrastruktury informatycznej. Poszczególne zakresy zastosowań oprogramowania opisane zostały zarówno z technicznego, jak i z ekonomicznego punktu widzenia. Podczas, gdy pierwszy koncentruje si˛e na identyfikacji i ocenie rozwiazań ˛ alternatywnych dla produktów Microsoft, w rozdziale opisujacym ˛ ocen˛e ekonomiczna˛ chodzi o udzielenie odpowiedzi na pytanie, jaka jest najbardziej oszcz˛edna droga prowadzaca ˛ do zamiany oprogramowania. W cz˛eści trzeciej (rozdział 5) umieściliśmy zalecenia migracyjne, które odnosza˛ si˛e do różnych struktur administracji. Zalecenia te sa˛ wynikiem otrzymanym na podstawie oceny technicznej i ekonomicznej. Zawieraja˛ one konkretne propozycje dla małych, średnich, dużych i specjalizowanych urz˛edów. Dodatkowo rozważamy tu zalety i wady różnych dróg migracji. Na końcu trzeciej cz˛eści przedstawione zostały krytyczne wyznaczniki sukcesu migracji. Pomimo, że zast˛epowanie jednego oprogramowania innym nie jest w zasadzie niczym nowym, to jednak różne doświadczenia wyniesione z projektów wdrożonych w administracji publicznej wskazuja˛ na konieczność bardzo starannego zaplanowania i wykonania migracji, gdyż ostateczny sukces takiego przedsi˛ewzi˛ecia ściśle wiaże ˛ si˛e z przygotowaniem pracowników bioracych ˛ w niej udział. Podczas wielomiesi˛ecznej pracy nad poradnikiem migracyjnym wielokrotnie okazywało si˛e, że zagadnienia tu opisane zmieniaja˛ si˛e bardzo szybko i dynamicznie. W czasie prac nad projektem ilość oprogramowania dost˛epnego pod Linuksem, zarówno tego publikowanego na licencji GPL, jak i komercyjnego, znacznie wzrosła. Podobny wzrost miał miejsce jeśli chodzi o ilość 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 dużych firm programistycznych jak SAP, Oracle, Sun czy IBM, z dnia na dzień rośnie także oferta małych i średnich przedsi˛ebiorstw specjalizujacych ˛ si˛e w konkretnych aplikacjach i systemach. Taki cieszacy ˛ zwolenników Otwartego Oprogramowania rozwój, przyczynia si˛e z jednej strony do osiagania ˛ dojrzałości przez ofert˛e OSS, a z drugiej strony powoduje coraz wi˛eksze trudności podczas wykonywania przegladu ˛ aktualnego stanu oprogramowania. ROZDZIAŁ 1. WPROWADZENIE 19 Oczywiście zadaniem samego czytelnika b˛edzie dostrzeżenie własnych korzyści w oparciu o wymienione w poradniku zach˛ety. Autorzy niniejszego opracowania maja˛ nadziej˛e, że b˛edzie ono pomocne i zapewni wsparcie każdemu, kto rozważa skutki techniczne i ekonomiczne migracji. 1.3 Jak korzystać z poradnika? Czytelnikom poradnika pragniemy wskazać, w jaki sposób należy korzystać z wewn˛etrznej struktury dokumentu. Mamy nadziej˛e, że dzi˛eki niniejszym poradom poruszanie si˛e po dość obszernym poradniku stanie si˛e łatwiejsze. Pami˛etajmy zatem o tym, że zagadnienia poruszone w poradniku skierowane sa˛ do dwóch grup odbiorców. Pierwsza˛ z nich stanowia˛ decydenci majacy ˛ wpływ na planowanie i wybór kierunku rozwoju w sektorze informatycznym, a druga˛ osoby odpowiedzialne za działy informatyczne w urz˛edach, dla których ważna jest szczegółowa techniczna analiza migracji. Zapoznanie si˛e z poniższymi wskazówkami zalecamy wszystkim osobom należacym ˛ do w/w grup. Bezpośrednim nawiazaniem ˛ do niniejszego rozdziału jest nast˛epny rozdział, który skierowany jest specjalnie do decydentów. „Wskazówki dla decydentów” sa˛ zbiorem istotnych spostrzeżeń oraz zwi˛ezłym opisem doświadczeń zebranych w czasie zrealizowanych już projektów migracyjnych. Czytajac ˛ poradnik nie należy opuszczać czterech pierwszych podrozdziałów rozdziału drugiego. Mieszcza˛ si˛e w nich bowiem ważne definicje, których poznanie ma istotne znaczenie dla zrozumienia dalszych cz˛eści poradnika. W kolejnych rozdziałach opisane zostały składniki systemu leżace ˛ u podstaw migracji zast˛epujacej ˛ i kontynuacyjnej. Jako uzupełnienie dla decydentów, którzy chcieliby zapoznać si˛e z techniczna˛ ocena˛ procesu migracji odnoszac ˛ a˛ si˛e każdorazowo do poszczególnych jego składników, na poczatku ˛ rozdziału 3 streszczone zostały cele oraz dokonano oceny uzyskanych wyników. Właściwe zestawienie i ocena wyników ekonomicznych mieści si˛e w rozdziale 4.7, natomiast rozdział 5 zawiera odpowiednie ekonomiczne zalecenia dotyczace ˛ skutków różnych metod migracji. Ocena wydajności ekonomicznej (rozdział 4) naświetla finansowe aspekty projektów migracyjnych i ma szczególne znaczenie dla osób podejmujacych ˛ strategiczne decyzje gospodarcze. W oparciu o różne scenariusze oceniliśmy pieni˛eżne aspekty możliwych metod migracji. W celu dogł˛ebnego poznania zaleceń ważnych dla urz˛edów, zach˛ecamy do przeczytania roz- ROZDZIAŁ 1. WPROWADZENIE 20 działu „Zalecenia migracyjne”. Mieszcza˛ si˛e tu różne scenariusze migracji 1 oraz wskazówki dotyczace ˛ zastosowania odpowiedniej kombinacji oprogramowania dla urz˛edów i instytucji o różnej strukturze2. Opieraja˛ si˛e one na wynikach dokonanych wcześniej ocen technicznych i ekonomicznych. Szczególnie interesujace ˛ moga˛ okazać si˛e rozważania z rozdziału „Krytyczne wyznaczniki sukcesu”, który wskazuje czytelnikom warunki, jakie należy spełnić, by wdrożenie odpowiedniego projektu zakończyło si˛e sukcesem. Po zapoznaniu si˛e z powyższym, decydenci uzyskaja˛ istotne dla siebie informacje. Jednak zach˛ecamy każda˛ z tych osób do przeczytania także pozostałych rozdziałów niniejszego poradnika. Dla pracowników działów IT interesujace ˛ powinny okazać si˛e wszystkie zebrane tu informacje. Poradnik zbudowany jest w taki sposób, że zaraz po wprowadzeniu można przeczytać rozdział 2 „Najważniejsze zagadnienia” przedstawiajacy ˛ ogólne informacje stanowiace ˛ kompendium wiedzy potrzebnej do zrozumienia dalszych cz˛eści poradnika. Oprócz, wymienionych już powyżej, pierwszych czterech podrozdziałów, znajduja˛ si˛e kolejne, w których opisane zostały różne dystrybucje GNU/Linuksa, licencje Open Source oraz przede wszystkim wskazówki odnośnie danych zebranych na potrzeby poradnika. Szczegółowa ocena techniczna zamieszczona w rozdziale 3 z pewnościa˛ stanowić b˛edzie, wraz ze znajomościa˛ lokalnych wymagań i możliwości technicznych, najważniejsze źródło informacji, np. udzielajacym ˛ odpowiedzi na nast˛epujace ˛ pytania: ◦ Co jest możliwe, wzgl˛ednie gdzie można spodziewać si˛e problemów? ◦ Jak można poradzić sobie ze znanymi problemami lub ich uniknać? ˛ ◦ Z jakich funkcjonalności można nadal korzystać po migracji, wzgl˛ednie gdzie pojawia˛ si˛e ograniczenia? ◦ itd. W poszczególnych rozdziałach składniki systemu b˛eda,˛ za każdym razem, oceniane z technicznego punktu widzenia. Opisany zostanie techniczny punkt wyjścia i nast˛epnie różne aspekty migracji zast˛epujacej ˛ i kontynuacyjnej. Dla czytelników posiadajacych ˛ odpowiednia˛ wiedz˛e techniczna˛ interesujacy ˛ może okazać si˛e przeglad ˛ różnych technologii. Każdy zyska możliwość szczegółowego zapoznania si˛e z przeznaczeniem opisanych tu, różnych rozwiazań ˛ i produktów. Dla czytelników, którzy dotychczas nie mieli wi˛ekszego kontaktu z technologiami opartymi na 1 2 pełna migracja zast˛epujaca, ˛ pełna migracja kontynuacyjna i migracja cz˛eściowa urz˛edy małe, średnie, duże i specjalizowane ROZDZIAŁ 1. WPROWADZENIE 21 Linuksie, szczególnie ważne b˛eda˛ rozdziały dotyczace ˛ migracji zast˛epujacej ˛ zawierajace ˛ różnorodne informacje. W rozdziale 5 znaleźć można konkretne zalecenia powstałe w oparciu o oceny techniczne i ekonomiczne zgromadzone we wcześniejszych rozdziałach. Przedstawione zostały tu różne scenariusze przeznaczone dla różnych, ze wzgl˛edu na wielkość i zakres wykonywanych zadań, urz˛edów. Czytelnik ma możliwość 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 już w poprzednim rozdziale, w poradniku migracyjnym przedstawione zostana˛ dwie podstawowe drogi migracji: ◦ migracja zast˛epujaca ˛ oraz ◦ migracja kontynuacyjna. Zasadniczy wynik można w tym miejscu z góry przewidzieć; ilość scenariuszy, w których dla urz˛edów korzystniejsza jest migracja zast˛epujaca ˛ 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 obniżaja˛ koszty, natomiast z drugiej strony, z upływem lat, projektom migracyjnym toruje drog˛e duża dojrzałość, rozpowszechnienie i kompatybilność tego typu produktów. To wszystko powoduje obecnie niższe koszty wdrożenia, niż miałoby to miejsce w przeszłości. Wyniki oceny wydajności ekonomicznej potwierdzaja˛ w szczególności, że do znacznych oszcz˛edności może prowadzić 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˛ si˛e w pierwszym rz˛edzie do sytuacji ciagle ˛ jeszcze panujacej ˛ w wi˛ekszości urz˛edów, które wyposażone sa˛ w system operacyjny Windows NT 4 oraz współpracujace ˛ z nim oprogramowanie, takie jak, np. MS Exchange 5.5, Internet Information Server 4 oraz MS SQL Server 7. ROZDZIAŁ 1. WPROWADZENIE 22 1.4.2 Migracja kontynuacyjna i zast˛epujaca ˛ Konfiguracja ta stanowi punkt wyjścia dla migracji kontynuacyjnej w środowisku produktów Microsoft. W niniejszym rozdziale zajmiemy si˛e ocena˛ możliwości zastapienia ˛ w/w produktów przez Windows 2000 i oprogramowanie z serii 2000, jak również przez Windows XP i Windows 2003. To, że skoncentrujemy si˛e na Windows 2000 nie oznacza, że wszyscy, którzy dokonali już przejścia na Windows 2000 powinni w tym momencie odłożyć poradnik na półk˛e. Także urz˛edom stosujacym ˛ już t˛e technologi˛e przyda si˛e zarówno znajomość zawartej tu oceny technicznej, jak i ważnych zaleceń. Ich przestrzeganie, a także podj˛ecie zwiazanych ˛ z nimi odpowiednich kroków prowadzacych ˛ do redukcji wewn˛etrznego stopnia uzależnienia, ma na celu pozostawienie otwartej drogi dla przyszłych migracji. Te ostatnie zalecenia skierowane sa˛ przede wszystkim do urz˛edów, które właśnie przeprowadziły migracj˛e na Windows 2000 oraz takich, które chwilowo nie chca˛ odstapić ˛ od korzystania z produktów Microsoft lub (z różnych powodów musza˛ wciaż ˛ z nich korzystać). Oglad ˛ migracji zast˛epujacej ˛ pokazuje, że różnorodność oraz duża ilość rozwiazań ˛ sprawia, iż sensowne staje si˛e rozróżnienie omawianych wyników i zaleceń. Szczególnie istotnymi kryteriami wyboru właściwego rozwiazania ˛ sa˛ zakres usług informatycznych, intensywność ich używania oraz „Stopień wyspecjalizowania” w przypadku urz˛edów, które same świadcza˛ usługi informatyczne na rzecz innych urz˛edów. Oprócz wyboru odpowiednich produktów i właściwych konfiguracji, konieczne jest znalezienie prawidłowych scenariuszy migracji. W tym miejscu w poradniku wyróżniono migracj˛e punktowa, ˛ szeroka˛ i pełna˛ - w zależności od informatycznego „stopnia pokrycia obszaru”. Punktowo, przez zastapienie ˛ pojedynczych składników używanego systemu, takich jak, np. MS Office Suite albo MS Exchange. Cz˛eściowo, 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ń ˛ należy preferować, by spełnić określone wymagania urz˛edu i dostosować system informatyczny do struktury urz˛edu. 1.4.3 Różne drogi migracji Ważna˛ rol˛e odgrywa wybór drogi migracji, czyli wybór pomi˛edzy migracja˛ szybka˛ i łagodna.˛ Jest przy tym rzecza˛ decydujac ˛ a,˛ by istniała techniczna możliwość w wysokim stopniu bezproblemowego komponowania i używania mieszanych (heterogenicznych) systemów. Dzi˛eki temu urz˛edy otrzymaja˛ szans˛e zast˛epowania 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˛ drog˛e migracji wyznacza wiele czynników. Szybka migracja oznacza (jak można wnioskować z samej nazwy) dokonanie pełnej migracji zast˛epujacej ˛ za jednym razem. Z punktu widzenia zasad ekonomii ma to sens przede wszystkim tam, gdzie infrastruktura i systemy informatyczne badź ˛ to już zwiazane ˛ sa˛ w dużym stopniu z oprogramowaniem uniksowym badź ˛ w przypadku urz˛edów wymagajacych ˛ wprowadzenia wi˛ekszych zmian infrastruktury informatycznej oraz w urz˛edach z tak zwanym zastojem inwestycyjnym. Z reguły najwi˛ekszy sens ma realizacja łagodnych migracji. Sa˛ one przeprowadzane w jednym do trzech kroków i składaja˛ si˛e z migracji cz˛eściowych i/lub punktowych. Łagodne migracje daja˛ możliwość nadrobienia w miejscu pracy zacofania z zakresu know-how w odniesieniu do nowych technologii oraz stopniowego wdrożenia administratorów i użytkowników do nowych technologii i oprogramowania. Niezależnie od wybranej drogi migracji, jeśli chcemy osiagn ˛ ać ˛ końcowy sukces, musimy przestrzegać tak zwanych krytycznych wyznaczników sukcesu. Zostały one wyszczególnione w zaleceniach. Chodzi m.in. o niezb˛edne przygotowania, działania służace ˛ właściwemu przekazywaniu informacji i stworzenie atmosfery akceptacji w kr˛egu użytkowników, niezb˛edne szkolenia oraz o zadania na poziomie zarzadzania ˛ projektem i ogólna˛ organizacj˛e. Nawet w sytuacji, kiedy niemal dla każdego zastosowania i wymogu istnieja˛ adekwatne rozwiazania, ˛ sama zamiana czegoś znanego na coś nowego zwiazana ˛ jest, w wi˛ekszości przypadków, z trudnościami i cz˛esto subiektywnymi „bólami”. Zasadniczo można jednak powiedzieć, że obydwie drogi migracji niosa˛ ze soba˛ wiele nowego zarówno dla projektantów, jak i dla administratorów. To samo dotyczy użytkowników, przy czym dotyczace ˛ ich zmiany nie sa˛ z reguły aż tak widoczne. 1.4.4 Porównanie alternatywnych rozwiaza ˛ ń Wiadomo, że nie wszystkie funkcjonalności dostarczane przez Windows i inne produkty firmy Microsoft znajduja˛ swoje lustrzane odbicie w oprogramowaniu Open Source badź ˛ oprogramowaniu komercyjnym działajacym ˛ w systemie operacyjnym GNU/Linux. Jednakże, jak wykazały doświadczenia użytkowników obu platform potwierdzone wynikami uzyskanymi podczas przeprowadzonych już migracji, funkcjonalność w/w oprogramowana jest porównywalna. Ponieważ w pojedynczych przypadkach może chodzić o specjalne zastosowania i konkretne właściwości, zaleca si˛e by każdy urzad ˛ dokonał samodzielnej oceny ewentualnych krytycznych odst˛epstw majacych ˛ wpływ na oczekiwana˛ funkcjonalność. Odst˛epstw takich spodziewać si˛e można przede wszystkim w obszarze aplikacji biurowych, w szczególności jeśli chodzi o integracj˛e tych aplikacji z oprogramowaniem specjalistycznym, jak również kompatybilności podczas ROZDZIAŁ 1. WPROWADZENIE 24 wymiany dokumentów pomi˛edzy pakietami Microsoft Office i OpenOffice.org lub StarOffice. Problemy kompatybilności prowadza˛ do tego, że wspólna edycja dokumentów przy wykorzystaniu OpenOffice.org lub StarOffice i MS Office możliwa jest w bardzo ograniczonym zakresie. W zasadzie wspólna edycja możliwa jest tylko na poziomie zawartości. Z ocen technicznych wynika, że istnieja˛ darmowe badź ˛ komercyjne zamienniki dla systemu operacyjnego Windows oraz dla usług sieciowych opartych o ten system. Dotyczy to także desktopów. Wspomniane zamienniki pracuja˛ pod kontrola˛ GNU/Linux. ◦ Jeśli chodzi o usługi sieciowe i obsług˛e środowisk mieszanych, ważna˛ rol˛e odgrywaja˛ Samba i OpenLDAP oraz CUPS b˛edacy ˛ innowacyjna˛ i zarazem skuteczna˛ usługa˛ umożliwiajac ˛ a˛ drukowanie w sieci. CUPS spełnia wszystkie wymagania stawiane nowoczesnym, wydajnym i kompleksowym protokołom wydruku. Ilość programów do zarzadzania ˛ siecia˛ opartych o wolne oprogramowanie systematycznie rośnie i jest nieustannie udoskonalana. Ponadto cz˛eść komercyjnych systemów zarzadzania ˛ siecia˛ oferowanych dotychczas do współpracy z Windows, jest dostosowywana przez producentów do pracy w środowisku GNU/Linux. ◦ Rozwiazaniami ˛ mogacymi ˛ zastapić ˛ MS Exchange jest przede wszystkim wolne oprogramowanie, wykorzystywane zwłaszcza do zastapienia ˛ samych serwerów pocztowych. Takim pełnowartościowym substytutem dajacym ˛ możliwość dalszego korzystania z klienta poczty Outlook jest obecnie, Samsung Contact - dla średnich i dużych sieci, a dla mniejszych sieci może nim być Exchange4Linux. ◦ Jeśli chodzi o bazy danych, to można wybierać spośró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 już sobie bardzo dobra˛ opini˛e odnośnie działania w środowisku Unix/Linux i dlatego nie b˛eda˛ przez nas oceniane. Powyższa˛ list˛e można by rozszerzyć na niemal wszystkie dziedziny zastosowań sieciowych i desktopowych. W poradniku opiszemy tylko niektóre z nich, np. systemy wysokiej niezawodności oraz Thin Clients. Tam, gdzie pojawia˛ si˛e ważne różnice albo ograniczenia zwiazane ˛ z prezentowanymi rozwiazaniami, ˛ zostana˛ one wyjaśnione. 1.4.5 Istotne zagadnienia przyszłościowe Aby zamieszczona tu ocena techniczna nie była pozbawiona perspektywicznego spojrzenia, przedstawiony punkt wyjścia oceniany b˛edzie za każdym razem pod katem ˛ przyszłościowego ROZDZIAŁ 1. WPROWADZENIE 25 znaczenia składników pełniacych ˛ wiodac ˛ a˛ rol˛e w nowym oprogramowaniu firmy Microsoft. Zalicza si˛e do niego przede wszystkim .NET Framework wraz z jego istotnymi cz˛eściami składowymi, tj. Web-Services i XML, a także SharePoint Portal Server. Podsumowujac ˛ można sformułować nast˛epujace ˛ wnioski: ◦ Zarówno .NET-Framework, jak i alternatywna do niego Java/J2EE oferuja˛ zasadniczo dwie funkcjonalności, tj. umożliwiaja˛ ponowne zastosowanie używanych składników oraz realizuja˛ kompatybilność pomi˛edzy platformami i oprogramowaniem. ◦ Możliwość ponownego wykorzystania używanych składników, uzyskana wskutek wykorzystania ich jednakowego modelu (COM+ w przypadku Microsoft oraz JavaBeans w Javie), określana jest mianem integracji gł˛ebokiej wskutek ich powiazania ˛ ze środowiskiem runtime environment (udost˛epnianie uniwersalnych funkcji) i/lub powiazania ˛ z j˛ezykami programowania. Aplikacje stworzone w oparciu o jeden model składników można wykorzystywać tylko wewnatrz ˛ jednej platformy. ◦ XML, jako format wymiany danych i dokumentów, tworzy podstaw˛e w zastosowaniach opartych na technologii Web-Services. Dzi˛eki niezależności od konkretnego środowiska oraz wykorzystywaniu interfejsów dla różnych protokołów, można ja˛ zastosować do płytkiej integracji usług. Usługi oparte na Web-Services moga˛ wykraczać poza granice wyznaczane przez platform˛e, na której sa˛ uruchamiane. ◦ Obecnie nie można sformułować generalnego zalecenia dotyczacego ˛ wykorzystania ponad platformowego płytkiego modelu integracji. Jest tak ze wzgl˛edu na nierozstrzygni˛ete kwestie bezpieczeństwa oferowanego przez aplikacje pracujace ˛ w ramach technologii WebServices. Ocena bezpieczeństwa b˛edzie 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, zostało sformułowane w zaleceniach standardowych SAGA. W dokumencie tym, ze wzgl˛edu na zachowanie niezależności sprz˛etowej, wskazuje si˛e na konieczność wykorzystania JSE/J2EE. Odejście od tej zalecanej technologii (np. w kierunku .NET-Framework) dopuszczalne jest tylko w uzasadnionych przypadkach (np. gdy możliwe jest poczynienie znacznych oszcz˛edności). ◦ Przewiduje si˛e, że 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 ważnych systemów informatycznych administrujacych ˛ danymi”, jak również wytyczna SAGA odnośnie PDF, jako formatu wymiany dokumentów, doprowadzi do znacznego poprawienia (jeśli nie do całkowitego zlikwidowania problemu) kompatybilności oprogramowania biurowego poczawszy ˛ od MS Office 2003. 1.4.6 Korzyści ekonomiczne Główna ocena korzyści ekonomicznych przedstawiona w poradniku koncentruje si˛e wokół dwóch istotnych zagadnień: ◦ przedstawienia podstawowych wypowiedzi dotyczacych ˛ opłacalności stosowania produktów Open Source oraz ◦ określenia metod i środków pozwalajacych ˛ na dokonanie oceny wydajności ekonomicznej pod katem ˛ specyficznych potrzeb urz˛edów oraz oszacowania kosztów migracji zwiazanych ˛ z konkretnymi projektami. Analiza kosztów migracji oraz właściwe, dla przedłożonych projektów migracji, dokumenty WiBe 21,3 wskazuja˛ na dwie metody obliczania rentowności procesu wymiany oprogramowania. Aby umożliwić łatwiejsze ich zrozumienie, poradnik zawiera przykładowe wyliczenia dla różnych scenariuszy wraz z komentarzami. W celu podkreślenia szczególnych różnic wynikajacych ˛ z różnych 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 przydatności. Poradnik daje tym samym możliwość przypisania wymiaru ekonomicznego każdemu projektowi. Podaje on liczby pomocne przy określaniu rentowności oraz pilności wdrożenia projektu badź ˛ też wskazuje na jego strategiczne znaczenie. Także analiza kosztów migracji oferuje szybka˛ i pragmatyczna˛ pomoc dla przygotowania oceny wydajności ekonomicznej. Na zakończenie należy wyraźnie podkreślić, że zwłaszcza wyniki oceny ekonomicznej pokazały, iż głównym czynnikiem wpływajacym ˛ na podj˛ecie decyzji za lub przeciw migracji zast˛epujacej ˛ b˛edzie stopień integracji z systemem Windows i pakietem MS Office. Decydujace ˛ argumenty ekonomiczne oraz możliwości zastosowania migracji zast˛epujacej ˛ zależa˛ ściśle od ilości 3 IT-WiBe 21 – zalecenia odnośnie przygotowywania oceny ekonomicznej w administracji publicznej, ze szczególnym uwzgl˛ednieniem nakładów na technologie informatyczne, wersja 3.0 - 2001, dokumenty KBSt, tom 52, maj 2001 r. ROZDZIAŁ 1. WPROWADZENIE 27 używanych aplikacji biurowych, zakresu i stopnia skomplikowania stosowanych makr, skryptów oraz szablonów, jak również od ilości i dost˛epności kodu źródłowego wykorzystywanych aplikacji specjalistycznych współpracujacych ˛ wyłacznie ˛ z Windows. Właśnie takiej sytuacji poświ˛econe sa˛ zalecenia dotyczace ˛ stopniowego zmniejszania uzależnienia od jednego systemu operacyjnego i podnoszenia kompatybilności wykorzystywanego oprogramowania. Rozdział 2 Najważniejsze zagadnienia 2.1 Ważne definicje Na co dzień używanych jest wiele poj˛eć, które mimo pozornego podobieństwa, wcale nie sa˛ tożsame. W niniejszym poradniku sa˛ to mi˛edzy innymi: Oprogramowanie Open Source, Otwarte Oprogramowanie lub Free Software, oprogramowanie własnościowe, oprogramowanie komercyjne i inne. Ponadto w poradniku wprowadzono własne poj˛ecia. Aby lektura poradnika nie prowadziła do powstawania nieporozumień, niektóre z w/w poj˛eć zostały wytłumaczone poniżej. 2.1.1 Open Source, Free Software Poj˛ecia „Open Source Software” i „Free Software” nazywane także „Otwartym Oprogramowaniem” stosowane sa˛ w poradniku jako synonimy. Dla uproszczenia oznaczono je skrótem OSS. OSS pozwala każdemu czytać i dowolnie modyfikować kod źródłowy. Otwartość ta daje użytkownikom możliwość samodzielnego uczenia z czytanego kodu, wzgl˛ednie dostosowania go do własnych potrzeb. Oprogramowanie udost˛epniane jest nieodpłatnie dzi˛eki czemu osoby, które z niego korzystaja, ˛ nie musza˛ ponosić kosztów zwiazanych ˛ z zakupem licencji. Programy OSS wolno kopiować w zmodyfikowanej formie oraz rozpowszechniać. Wolność oprogramowania reguluja˛ i gwarantuja˛ odpowiednie licencje. Najważniejsze z nich zostały opisane w rozdziale 2.4. OSS nie wolno mylić z oprogramowaniem, które wprawdzie udost˛epniane jest za darmo, ale nie może być przez użytkownika modyfikowane ani dostosowywane do własnych potrzeb, wzgl˛ednie takim oprogramowaniem, którego licencja zakazuje stosowania go do celów komer28 ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 29 cyjnych. 2.1.2 Oprogramowanie własnościowe Oprogramowanie własnościowe nie jest oprogramowaniem OSS. Należy ono do osoby lub organizacji. Z reguły chodzi w tym przypadku o producenta takiego oprogramowania (prawo własności). Sposób korzystania z oprogramowania podlega zapisom licencji, które ustalane sa˛ przez właściciela oprogramowania. Najcz˛eściej zakazuja˛ one nieograniczonego powielania, rozpowszechniania i modyfikowania. W pewnych przypadkach, gdy spełnione zostana˛ odpowiednie wymagania zapisane w licencji, oprogramowanie takie jest także udost˛epniane za darmo. 2.1.3 Komercyjne oprogramowanie linuksowe Komercyjne oprogramowanie linuksowe (Commercial Linux Software) obejmuje grup˛e oprogramowania własnościowego, które może być stosowane w systemie operacyjnym GNU/Linux. Z reguły odznacza si˛e ono wykorzystywaniem obowiazuj ˛ acych ˛ standardów i wynikajac ˛ a˛ z nich kompatybilnościa, ˛ jak również dobrze zdefiniowanymi interfejsami. 2.1.4 Migracja zast˛epujaca ˛ W niniejszym poradniku wyróżnione zostały dwa główne modele migracji: zast˛epujaca ˛ i kontynuacyjna. Na czym polegaja˛ różnice pomi˛edzy nimi? Mianem migracji zast˛epujacej ˛ określa si˛e zastapienie ˛ aplikacji pracujacych ˛ pod Windows oraz usług świadczonych przez ten system operacyjny wraz ze wszystkimi bazujacymi ˛ na nim środowiskami przez oprogramowanie OSS lub komercyjne oprogramowanie linuksowe. Poniżej kilka typowych przykładów: ◦ zastapienie ˛ Windows NT przez GNU/Linux ◦ zastapienie ˛ MS Office przez OpenOffice.org ◦ zastapienie ˛ MS SQL Server przez Oracle ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 30 2.1.5 Migracja kontynuacyjna Poj˛ecie migracji kontynuacyjnej oznacza dalsze wykorzystywanie oprogramowania Microsoft majace ˛ na celu osiagni˛ ˛ ecie odpowiedniego stopnia kompatybilności przed zmiana˛ oprogramowania na OSS. W ramach tego typu migracji mieści si˛e, na przykład, zastapienie ˛ Windows NT 4 przez Windows 2000, Windows XP albo Windows 2003. Poniżej kilka typowych przykładów: ◦ zastapienie ˛ Windows NT 4 przez Windows 2000 ◦ zastapienie ˛ MS Office 97 przez MS Office 2003 2.2 Etapy migracji Wiele urz˛edów i organizacji stoi obecnie przed podj˛eciem decyzji dotyczacej ˛ rozwoju ich systemu informatycznego i jego składników w najbliższych latach. Konieczność dokonania takiego wyboru może pojawić si˛e z różnych powodów: ◦ wygaśni˛ecie wsparcia dostarczanego przez producenta różnych istotnych produktów ◦ rosnace ˛ wymagania techniczne ◦ konsolidacja już stosowanych systemów i aplikacji ◦ różne cele strategiczne, np. uniezależnienie si˛e od producenta oprogramowania oraz zwi˛ekszenie kompatybilności Osoby odpowiedzialne za prawidłowe działanie oprogramowania w urz˛edach i organizacjach musza˛ odpowiedzieć na pytanie dotyczace ˛ utworzenia właściwej bazy dla infrastruktury informatycznej. Dlatego niniejszy poradnik analizuje nast˛epujace ˛ podstawowe drogi migracji: ◦ Migracja zast˛epujaca ˛ z wykorzystaniem GNU/Linux i Oprogramowania Open Source (OSS) ◦ Migracja zast˛epujaca ˛ 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 należy wziać ˛ pod uwag˛e migracj˛e mieszana,˛ gdyż nie można z góry zakładać, że dla wszystkich składników tworzacych ˛ punkt wyjścia dla migracji, znajda˛ si˛e odpowiedniki OSS i COLS. Jest tak zarówno z przyczyn technicznych, jak i ekonomicznych. ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 31 Nie było możliwe umieszczenie w ramach poradnika wszystkich spostrzeżeń zwiazanych ˛ z poruszonymi powyżej zagadnieniami. Przyczyna˛ tego jest zarówno rozległość systemów, które należałoby poddać odpowiedniej ocenie, jak też każdorazowe, bardzo specyficzne wymagania poszczególnych urz˛edów. Dlatego poradnik udziela raczej odpowiedzi na istotne, strategiczne pytania, które zadawane sa˛ w jednakowy sposób przez wi˛ekszość urz˛edów i w ten sposób pomaga podjać ˛ decyzj˛e. 2.2.1 Punkt wyjścia - Microsoft Windows Rysunek 2.1 przedstawia system Microsoft i składniki znajdujace ˛ si˛e w jego otoczeniu. Taka badź ˛ podobna struktura wykorzystywana jest w wielu urz˛edach i organizacjach. Poniższy rysunek odwzorowuje usługi wraz z modułami - programami, które sa˛ cz˛eścia˛ składowa˛ sytuacji przed migracja,˛ b˛edacej ˛ punktem wyjścia dla naszej oceny. Na poczatku ˛ rozdziału 3 opisana została techniczna ocena każdego ze składników systemu uwzgl˛edniajaca ˛ ich funkcje i szczególne właściwości pod katem ˛ planowanej migracji. Nast˛epnie wyszczególniono odpowiednie techniczne rozwiazanie ˛ lub rozwiazania ˛ dla migracji zast˛epujacej. ˛ W trzecim kroku ocenione zostały sposoby przeprowadzenia migracji kontynuacyjnej, a w czwartym i ostatnim kroku wskazano, która˛ z dwóch dróg migracji należy wybrać. ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 32 Rysunek 2.1: Składniki systemu - punkt wyjścia Podczas tworzenia niniejszego poradnika konieczne było przyjmowanie w różnych miejscach założeń dotyczacych ˛ wielorakiej infrastruktury informatycznej. O ile w ramach przedstawianych tu ocen technicznych i ekonomicznych nie określimy inaczej, obowiazuj ˛ a˛ nast˛epujace ˛ założenia. Serwery Założyliśmy, że punkt wyjścia dla migracji w urz˛edach opiera si˛e na jednym z dwóch powszechnych modelów domen NT. ◦ Środowisko NT z domena,˛ w której odbywa si˛e zarzadzanie ˛ kontami użytkowników i kontami komputerów. ◦ Środowisko NT z account domain, która zawiera konta użytkowników oraz wiele resource domains, które zarzadzaj ˛ a˛ kontami komputerów i ufaja˛ account domain. W środowisku tym, na bazie Windows NT 4 Server, udost˛epniane sa˛ różne usługi infrastrukturalne oraz aplikacje i składniki integrujace. ˛ Poniżej wyszczególnione zostały główne usługi infrastrukturalne opisane w poradniku: ◦ logowanie i autoryzacja ◦ zarzadzanie ˛ plikami ◦ drukowanie ◦ usługi sieciowe ◦ zarzadzanie ˛ systemem Ze wzgl˛edu na duże rozpowszechnienie w administracji publicznej różnych serwerów, w poradniku skoncentrowaliśmy si˛e na przedstawieniu nast˛epujacych ˛ 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 wi˛ekszości aplikacji bazodanowych. ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 33 Do połaczenia ˛ i integracji różnych usług i aplikacji pod Windows dochodziło dotychczas z reguły na gruncie ◦ Component Object Model (COM) oraz ◦ należacej ˛ do niego usługi Distributed COM (DCOM). Udost˛epnienie Windows NT 4 Services może być realizowana przez dwie różne wersje systemu operacyjnego: ◦ Windows NT 4 Server ◦ Windows NT 4 Server Enterprise Edition. Drugi z wymienionych serwerów (Enterprise Edition) umożliwia realizacj˛e usług przez dwa w˛ezły (serwery) w jednym klastrze. Klienty i aplikacje Jeśli chodzi o oprogramowanie działajace ˛ po stronie użytkownika, należy założyć, że dominuja˛ cym systemem operacyjnym b˛edzie tu Windows NT 4 Workstation. Starsze odmiany Windows, takie jak Windows 95 lub 98, nie były przez nas oceniane. Najważniejszym oprogramowaniem pracujacym ˛ na bazie w/w systemów jest Microsoft Office Suite. Dlatego oceniona zostanie zarówno wersja 97, jak i bieżaca ˛ wersja 2000 tego oprogramowania. Użytkownicy używaja˛ ich podczas wykonywania swoich codziennych zadań. Dlatego udost˛epnia si˛e im z reguły edytory tekstu, arkusze kalkulacyjne, arkusze prezentacji oraz możliwość korzystania z komunikatorów sieciowych badź ˛ oprogramowania Groupware umożliwiajacego ˛ prac˛e grupowa. ˛ Oprócz standardowego oprogramowania biurowego, używane sa˛ także różnorodne specjalistyczne aplikacje pracujace ˛ pod w/w systemami operacyjnymi. Służa˛ one do wykonywania zadań specyficznych dla konkretnego urz˛edu i cz˛esto sa˛ zintegrowane z Windows-Desktop. W przypadku planowanej migracji wymagana jest ich szczególnie dokładna ocena. Ponieważ zmiany podstawowej infrastruktury informatycznej, moga˛ naruszyć podstawy działania tego typu aplikacji, wymagane jest, w zależności od ich ilości i stopnia skomplikowania, opracowanie odpowiednich rozwiazań ˛ przejściowych. W poradniku przedstawione zostały wybrane propozycje i zalecenia dotyczace ˛ właściwego sposobu post˛epowania w takiej sytuacji. ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 34 Na końcu opisaliśmy jeszcze cały szereg innych standardowych aplikacji i narz˛edzi (np. menedżerów plików, także programów służacych ˛ do kompresji danych), które udost˛epniane sa˛ użytkownikom podczas wykonywania przez nich codziennych prac. Programy te b˛eda˛ im także potrzebne już po migracji, jako składniki nowego systemu. 2.2.2 Przeglad ˛ systemu dla migracji zast˛epujacej ˛ Rysunek 2.2 przedstawia alternatywne składniki, pracujace ˛ na bazie systemu operacyjnego GNU/Linux. Pokazane sa˛ najważniejsze systemy i aplikacje, które można wykorzystać do przeprowadzenia migracji zast˛epujacej. ˛ W ostatniej dekadzie wielu producentów oprogramowania zdecydowało si˛e na napisanie badź ˛ przystosowanie (przeportowanie) swoich produktów w taki sposób, by współpracowały one z Linuksem. Oprócz wielkich firm z branży informatycznej, takich jak IBM, SUN czy Oracle, można w tym miejscu wspomnieć także o licznych mniejszych przedsi˛ebiorstwach zajmujacych ˛ si˛e dostarczaniem specjalistycznych rozwiazań ˛ informatycznych. Produkty te sa˛ na tyle znane z rynku oprogramowania komercyjnego, że nie wymagaja˛ bliższego omówienia. Poradnik koncentruje si˛e przede wszystkim na cz˛eściowo mniej znanych rozwiazaniach ˛ Open Source oraz takich, które dopiero od niedawna można wykorzystać dla przeprowadzenia migracji zast˛epujacej ˛ w krytycznych obszarach. Rysunek 2.2 wyraźnie wskazuje konkretne obszary zastosowań, gdzie tego typu rozwiaza˛ nia sa˛ dost˛epne jako coś wi˛ecej niż 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 ˛ si˛e z grupy alternatywnego oprogramowania własnościowego pracujacego ˛ pod GNU/Linux i opartego jednocześnie na otwartych standardach. ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 35 Rysunek 2.2: Składniki systemu - migracja zast˛epujaca ˛ 2.2.3 Przeglad ˛ systemu dla migracji kontynuacyjnej W przypadku migracji kontynuacyjnej najważniejsza˛ rzecza˛ jest zastapienie ˛ Windows NT 4 oraz pozostałych współpracujacych ˛ z nim składników systemu, ich nowszymi wersjami. Do tego typu migracji należy wykorzystać produkty z serii 2000. Odpowiednie zależności zostały przedstawione na rysunku . W rozdziale 3 przedstawione zostały charakterystyczne szczegóły techniczne oraz założenia konieczne do przeprowadzenia migracji, jak również wymagane dla uruchomienia poszczególnych usług i serwerów środki techniczne. Punktem wyjścia dla poniższego opisu jest Windows 2000 Server. Nast˛epnie przeanalizowane i ocenione zostały skutki zmian technicznych i pozostałe nowości. ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 36 Rysunek 2.3: Składniki systemu - migracja kontynuacyjna Podobnie, jak w przypadku migracji zast˛epujacej, ˛ oprócz zmian po stronie serwerów, oceniane sa˛ tu także zmiany zachodzace ˛ na desktopach. Różnica polega na tym, że tym razem w centrum uwagi znajduje si˛e Office XP. Ostatecznie tam, gdzie pozwalaja˛ na to dost˛epne informacje, oceniono również serwery i pakiety biurowe wywodzace ˛ si˛e z serii 2003. 2.2.4 Wewn˛etrzne zależności systemu opartego o rozwiazania ˛ firmy Microsoft Architektury systemu, które w wi˛ekszości bazuja˛ na produktach Microsoft, wykazuja˛ różnie silne wewn˛etrzne zależności. W nast˛epujacym ˛ rozdziale przedstawione zostały niektóre z takich wewn˛etrznych zależności wyst˛epujacych ˛ w strukturze opartej na produktach Microsoft. Oczywista zależność polega na tym, że aplikacje firmy Microsoft daja˛ si˛e zainstalować i używać 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ównież, poza nielicznymi wyjatkami ˛ (Office 98 dla MacOS, Internet Explorer 4 dla Uniksa), aplikacji desktopowych (np. MS Office) i oprogramowania klienckiego (np. klienty MS SQL). ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 37 Mówiac ˛ ogólnie, w celu zarzadzania ˛ kontami użytkowników i ich autoryzacji oraz weryfikacji praw dost˛epu do zasobów, serwery wymagaja˛ administrowania. Microsoft oferuje różne sposoby administrowania w zależności od wykorzystywanej bazy danych użytkowników. Zostały one wymienione poniżej na przykładzie serwera MS SQL Server. ◦ wariant A: administrowanie kontami użytkowników specyficzne dla SQL. ◦ wariant B: Administrowanie w oparciu o lokalna˛ baz˛e danych użytkowników systemu operacyjnego, w którym pracuje serwer. ◦ wariant C: Administrowanie w oparciu o baz˛e danych użytkowników wchodzac ˛ a˛ w skład struktury domen windowsowych, o ile serwer jest członkiem tej struktury. Poczawszy ˛ od ukazania si˛e Windows NT wariant ten oferowany jest dla niemal wszystkich serwerów Microsoft i umożliwia użytkownikowi pracujacemu ˛ w czystym środowisku Microsoft autoryzacj˛e Single Sign On. ◦ wariant D: Wariant, w którym można korzystać ze sposobów autoryzacji dostarczanych przez innych producentów, nie jest oferowany. Poczawszy ˛ od Windows 2000 Microsoft przeniósł zarzadzanie ˛ kontami i autoryzacj˛e użytkowników do usług katalogowych (patrz poniżej) oraz otwartych standardów, takich jak Kerberos i LDAP, jednak bez dopuszczenia obcych rozwiazań. ˛ W świecie Windows NT 4.0 można zauważyć jeszcze inne zależności zwiazane ˛ z administrowaniem kontami użytkowników. Na przykład niemożliwe jest korzystanie z Microsoft Exchange (wersja 4 do 5.5) bez struktury domen Windows NT. Innym przykładem pokazujacym ˛ konieczność korzystania z domen NT jest działanie Cluster Services. To samo dotyczy stworzonej przez Microsoft architektury DCOM (Distributed Component Object Model), której architektura bezpieczeństwa zakłada, że klient i serwer należa˛ do tej samej struktury domen. DCOM używany jest przez duża˛ ilość 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łaściwości. Zachowano je ze wzgl˛edu na konieczność podtrzymania kompatybilności ze starszymi aplikacjami. Dlatego, np. wprowadzenie mechanizmu autoryzacji Kerberos nie oznacza likwidacji me- ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 38 chanizmu NTLM (NT LAN Manager). Także czyste środowiska Windows 2000 nadal używaja˛ NTLM w niektórych miejscach (np. klastry). Równocześnie Active Directory wyposażony został w nowe możliwości, których albo nie było w świecie Windows badź ˛ były wykorzystywane raczej oddzielnie. Z uwagi na funkcjonalność wytycznych grup, ich cz˛eści były już znane w Windows NT jako wytyczne systemu, Internet Explorer Administration Kit (IEAK) albo Security Configuration Editor (SCM). W przeciwieństwie do tego, w wytycznych grup zastosowane zostały nowe funkcjonalności, takie jak wymiana oprogramowania, połaczenie ˛ z jednostkami organizacyjnymi, domenami i stanowiskami lub skryptami logowania i wylogowania. Całkowita˛ nowościa˛ w Windows 2000 Active Directory jest integracja takich technologii szyfrowania, jak IPsec albo EFS (Encrypted File System). Aby móc ich używać, trzeba zbudować infrastruktur˛e kluczy publicznych PKI (Public Key Infrastruktur) zintegrowana˛ z Active Directory. Microsoft rozszerzył także protokół Kerberos. Ma to umożliwić autoryzacj˛e przez SmartCard. Ponadto Windows 2000 Active Directory koniecznie wymaga serwera nazw (Domain Name System), którego zadaniem jest tłumaczenie nazw. Minimalne parametry techniczne serwera nazw musza˛ odpowiadać właściwościom serwera BIND w wersji 8.2.2 . Windows 2000 posiada wbudowany własny DNS. Pierwszym produktem Microsoft obowiazkowo ˛ wymaganym przez Windows 2000 Active Directory jest Exchange 2000. W przeciwieństwie do Exchange 5.5., Exchange 2000 nie jest już wyposażony we własne usługi katalogowe. Wszystkie informacje użytkowników poczty elektronicznej wraz z listami adresowymi Exchange 2000 znajduja˛ si˛e w Active Directory, który trzeba przygotować do integracji z Exchange przez rozszerzenie schematu. Centralna˛ rol˛e dla Exchange 2000 odgrywa Global Catalog w Active Directory. Jest on wykorzystywany przez Exchange 2000 do wysyłania na zewnatrz ˛ zapytań ustalajacych ˛ granice domen. Z Global Catalog korzysta także, np. Outlook 2000. Exchange 2000 wykorzystuje Active Directory nie tylko w trybie odczytu, lecz również do zapisu. Dlatego Recipient Update Service z Exchange 2000 może zapisywać swoje wyniki do Active Directory. Narz˛edzia do zarzadzania ˛ kontami pocztowymi użytkowników sa˛ całkowicie zintegrowane z konsola˛ zarzadzaj ˛ ac ˛ a˛ „Active Directory - Users and Computers”. Powyższe zwiazki ˛ i zależności istniejace ˛ pomi˛edzy pochodzacymi ˛ z Microsoft aplikacjami i samym systemem operacyjnym pokazuja˛ pogł˛ebianie si˛e procesów integracji wewnatrz ˛ w/w systemu operacyjnego. Sytuacja taka wymusza postawienie całego szeregu strategicznych pytań zwiazanych ˛ z potencjalnym skorzystaniem z rozwiazań ˛ alternatywnych: ◦ W jaki sposób porzucić określona˛ lini˛e produktów oraz przypisane do niej cykle aktualizacji? ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 39 ◦ Jak można zminimalizować uzależnienie od jednej linii produktów i zwiazanego ˛ z nia˛ wyposażenia technicznego? ◦ Jakie środki prowadza˛ do zredukowania uzależnienia od producenta i do zróżnicowania systemów oprogramowania? ◦ Czy dla określonych składników oprogramowania istnieje wystarczajaco ˛ dużo konkurencyjnych cenowo substytutów? Z uwagi na osiagni˛ ˛ ety w tzw. mi˛edzyczasie stopień zależności pomi˛edzy produktami, odpowiedzi na zadane powyżej pytania można udzielić z reguły tylko w oparciu o strategiczna˛ decyzj˛e uwzgl˛edniajac ˛ a˛ koncepcj˛e rozwoju infrastruktury informatycznej w administracji. 2.3 Dystrybucje Linuksa 2.3.1 Wprowadzenie Przy budowie systemu złożonego z serwerów i klientów można skorzystać z rozwiazań ˛ oferowanych w ramach różnych dystrybucji Linuksa. Oprócz systemu operacyjnego GNU/Linux zawieraja˛ one bardzo wiele pakietów z różnorodnym oprogramowaniem. Nie chodzi tu wyłacznie ˛ o oprogramowanie używane na desktopach, które z reguły udost˛epniane jest w wielu odmianach, lecz także, o serwery WWW, systemy zarzadzania ˛ bazami danych, serwery pocztowe, firewalls, serwery pośredniczace, ˛ serwery usług katalogowych i dużo wi˛ecej. Poniżej pokrótce przedstawione zostana˛ wybrane dystrybucje oraz ich charakterystyczne cechy. Dystrybucje tworzone i oferowane sa˛ przez najróżniejszych producentów i programistów. Pierwotnie dystrybucje były tworzone i rozwijane z reguły po to, by ułatwić użytkownikom proces instalacji systemu operacyjnego (kernel) i wybranych programów. Firmy zajmujace ˛ si˛e tworzeniem dystrybucji opracowały cały szereg różnych narz˛edzi administracyjnych ułatwiajacych ˛ obsług˛e systemu operacyjnego oraz współpracujacego ˛ z nim oprogramowania, którego cz˛eść, podobnie jak sam system, udost˛epniana jest w oparciu o licencje wolnego oprogramowania. Jeśli klient kupuje dystrybucj˛e, wówczas nie płaci on za system GNU/Linux, lecz za możliwość korzystania z zestawu dodatkowych narz˛edzi, dokumentacji technicznej, instalatorów oraz innych ewentualnych programów stworzonych przez producenta dystrybucji. Celem dystrybucji jest zmniejszenie nakładu prac administracyjnych i organizacyjnych użytkownika, gdyż sam ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 40 system operacyjny nie dostarcza własnych rozwiazań ˛ tego typu. Wskutek tego system pozostaje otwarty na realizacj˛e różnych pomysłów zarzadzania ˛ nim. Wraz z kupnem dystrybucji klient otrzymuje na ogół oprócz nośników (obecnie jest to kilka płyt CD) kompletna˛ dokumentacj˛e techniczna.˛ W zależności od producenta dystrybucji różni si˛e ona w swojej obj˛etości i jakości, jednak zazwyczaj zawiera instrukcj˛e instalacji oraz dalsze informacje dotyczace ˛ pracy z systemem. Na płytach CD znajduje si˛e odpowiednia wersja systemu operacyjnego wraz z licznym innym oprogramowaniem. W oparciu o licencj˛e GNU General Public License (GPL), na której udost˛epnianych jest wiele programów pracujacych ˛ pod GNU/Linux, dostarczany jest przez producenta dystrybucji także kod źródłowy takich programów oraz samego systemu operacyjnego. Dzi˛eki temu użytkownik jest w stanie, gdy pojawia˛ si˛e jakiekolwiek problemy, samodzielnie ponownie skompilować dowolny program po uprzednim dostosowaniu go do własnych potrzeb. Opisywane tu dystrybucje można kupić w postaci gotowego zestawu (CD, dokumentacja) albo nieodpłatnie pobrać z Internetu. W przypadku kupna klient może na ogół korzystać ze wsparcia technicznego zapewnianego przez producenta dystrybucji. Jeśli dystrybucja została pobrana z sieci, wówczas nie można na to liczyć. W przypadku trzech opisanych poniżej dystrybucji, dwie tworzone sa˛ przez producentów, a jedna jest zbiorowa˛ praca˛ społeczności programistów ja˛ rozwijajacych ˛ oraz innych osób pomagajacych ˛ w jej tworzeniu i testowaniu. W przyszłości ważna rola przypadnie kompatybilności wersji Linuksa i ujednoliceniu poszczególnych dystrybucji. Aby uniknać ˛ powstawania zbyt dużych różnic pomi˛edzy nimi, ustalono standardy. Na przykład File System Hierarchy Standard1 w celu zdefiniowania struktury katalogów Linuksa. Twórcy dystrybucji na ogół stosuja˛ si˛e do powyższego standardu. Ponadto File System Hierarchy Standard jest, jako ważna cz˛eść składowa wysiłków na rzecz kompatybilności, standardem Linux Standard Base (LSB)2. Celem Linux Standard Base jest definiowanie standardów prowadzacych ˛ do uzyskania możliwie szerokiej kompatybilności wszystkich dystrybucji i zapobiegajacych ˛ powstawaniu rozbieżności pomi˛edzy nimi. Standaryzacja ma na celu ułatwienie pracy programistom rozwijajacym ˛ oprogramowanie oraz producentom dystrybucji. Przy zachowaniu obecnego sposobu tworzenia dystrybucji, zgodnego ze standardami LSB, w przyszłości możliwa stanie si˛e wymiana oprogramowania bez wzgl˛edu na dystrybucj˛e z której pochodza.˛ Oprócz LSB, w kontekście podejmowanych działań na rzecz standaryzacji, trzeba wymienić 1 2 http://www.pathname.com/fhs/ http://www.linuxbase.org ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 41 Free Standard Group3. Tworza˛ ja˛ LSB, Open18N4 (niegdyś 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 unikni˛ecie konfliktów pomi˛edzy różnymi 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ści programistów Open Source. Wszyscy producenci dystrybucji przedstawionych w poradniku sa˛ reprezentowani w FSG. Z lista˛ dystrybucji certyfikowanych przez LSB można zapoznać si˛e w Internecie5. Przy wybieraniu dystrybucji ważna˛ rol˛e odgrywaja˛ z jednej strony wymagania zwiazane ˛ z pomoca˛ w administrowaniu oraz wsparcie sprz˛etowe, a z drugiej warunki ekonomiczno organizacyjne. Przykładami takich kryteriów może być istnienie kontraktów ramowych albo oferta zawierajaca ˛ aplikacje, które zostały specjalnie przystosowanych do potrzeb urz˛edu. Dystrybucje przedstawione poniżej zostały wybrane ze wzgl˛edu na wysoki stopień ich rozpowszechnienia (patrz także 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 świata. Jest to niemal 1.000 osób pracujacych ˛ nieodpłatnie i opiekujacych ˛ si˛e poszczególnymi pakietami. Istotnym znakiem firmowym Debiana jest udost˛epnianie tej dystrybucji na zasadach licencji GPL oraz to, że może być ona bez ograniczeń kopiowana i używana w celach komercyjnych. Debiana można ściagn ˛ ać ˛ za darmo z Internetu, jak i kupić. Dystrybucja ta nie jest zaliczana do produktów komercyjnych, dlatego przy zakupie płyt CD z Debianem płacimy za koszty transportu oraz wyprodukowania nośników. Dystrybucja nie jest rozprowadzana w postaci pudełkowej, co odróżnia ja˛ od niektórych komercyjnych produktów. Rzecza˛ charakterystyczna˛ dla Debiana jest sposób usuwania bł˛edów przez opiekunów dystrybucji. Za pośrednictwem bug-tracking publikowana jest lista zawierajaca ˛ wszystkie istniejace, ˛ zgłoszone bł˛edy oraz lista bł˛edów, nad usuni˛eciem których trwaja˛ właśnie prace. Dzi˛eki takiemu 3 http://www.freestandards.org http://www.openi18n.org 5 http://www.opengroup.org/lsb/cert/cert_prodlist.tpl?CALLER=cert_prodlist. tpl 4 ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 42 mechanizmowi zapewnienia bezpieczeństwa Debian zaliczany jest do najstabilniejszych, obarczonych najmniejsza˛ ilościa˛ bł˛edów dystrybucji. Projekt odznacza si˛e długim cyklem wydawania kolejnych wersji, co gwarantuje tej dystrybucji wysoka˛ jakość. W ten sposób nie dochodzi do wypuszczania na rynek „niedopracowanych” wersji. Jedna˛ z istotnych właściwości Debiana jest własny format pakietów oraz odpowiednie narz˛edzia służace ˛ do zarzadzania ˛ nim. Ma to t˛e istotna˛ zalet˛e, że daje możliwość łatwego aktualizowania zarzadzanego ˛ sytemu, jak i pojedynczych programów, bez konieczności instalowania oprogramowania od poczatku. ˛ System zarzadzania ˛ pakietami służy jednocześnie do wykonywania regularnych aktualizacji systemów polegajacych ˛ na uaktualnieniach w zakresie stabilności i bezpieczeństwa. Wszelka pomoc zwiazana ˛ z obsługa˛ sytemu i jego rozwojem zapewniona jest poprzez szereg list dyskusyjnych6 . Jeśli takie źródło informacji okaże si˛e być niewystarczajace, ˛ zawsze można skorzystać z usług technicznych licznych komercyjnych firm. 2.3.3 SuSE Linux Distribution SuSE Linux AG jest jednym z wi˛ekszych mi˛edzynarodowych producentów dystrybucji. Tradycyjnie SuSE reprezentowana jest bardzo silnie na rynku niemieckim. Poczatki ˛ działalności w/w spółki zwiazane ˛ sa˛ z wprowadzeniem na ten rynek pochodzacej ˛ z Holandii dystrybucji Slac7 kware . Dopiero po pewnym czasie SuSE stworzyła własna˛ dystrybucj˛e. Z biegiem lat firma rozwin˛eła produkty stosowane obecnie w najróżniejszych obszarach IT. Poniższa tabela przedstawia najważniejsze właściwości różnych dystrybucji. P RODUKTY P RZEZNACZENIE W pierwszym rz˛edzie zalecana przez producenta do zastosowań desktopowych. Dystrybucje zawieraja˛ duża˛ ilość pakietów wraz Personell - Professional z odpowiednimi narz˛edziami potrzebnymi do ich instalacji. W wersji Professional na płytach CD zamieszczone zostały również liczne programy przeznaczone na serwery, które można wykorzystywać w przedsi˛ebiorstwach. 6 7 http://www.debian.org/support http://www.slackware.org ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 43 SuSE Linux Server przeznaczone sa˛ dla wszelkich zastosowań informatycznych. Dost˛epne sa˛ one na wszystkie ważne platformy Enterprise sprz˛etowe: procesory 32 oraz 64 bitowe firm AMD i Intel. Obsługuja˛ także cały szereg eSerwerów firmy IBM, łacznie ˛ z mainframe. Tablica 2.2: SuSE Linux Dystrybucja SuSE opiera si˛e na rozwini˛etym przez amerykańska˛ firm˛e Red Hat systemie zarzadzania ˛ pakietami RPM. Z jego pomoca˛ programowanie może być instalowane oraz deinstalowane - także przez osoby trzecie - na ogół bez żadnych problemów. Doświadczenie uczy jednak, że niektóre specyficzne dla poszczególnych dystrybucji pakiety należy instalować zgodnie z metoda˛ preferowana˛ przez ich twórców. Dystrybucje SuSE zawieraja˛ zintegrowany system służacy ˛ do instalacji i administrowania pakietami o nazwie YaST. Podczas instalacji udost˛epnia on użytkownikom zarówno tryb tekstowy, jak i graficzny. Różne wersje SuSE przedstawione w powyższej tabeli różnia˛ si˛e mi˛edzy soba˛ przede wszystkim zalecanym obszarem zastosowań, zwiazanymi ˛ z tym możliwościami korzystania z pomocy technicznej oraz sposobami licencjonowania, a także cena.˛ Dla zastosowań w obszarze przedsi˛ebiorstw, ze wzgl˛edu na dost˛epność oraz skalowalność, oferowane sa,˛ jako najlepsze, zoptymalizowane rozwiazania, ˛ czyli wersja Enterprise. Zintegrowane tu zostały, na przykład, rozwiazania ˛ klastrowe, wieloprocesorowe oraz asynchroniczne I/O. Ponadto obydwie wersje różnia˛ si˛e od siebie dost˛epnościa˛ pomocy technicznej. W zależności od indywidualnych potrzeb klienta możliwe jest, np. uzyskanie pomocy 24x7, indywidualnych Service Level Agreements i certyfikatów. 2.3.4 Red Hat Inna˛ komercyjna˛ dystrybucja˛ jest Red Hat. Także Red Hat oferuje wiele wersji swojej dystrybucji, które przeznaczone sa˛ do realizacji różnych zadań (patrz także 2.4). Również w tym przypadku producent zastosował własne narz˛edzia służace ˛ do zarzadzania ˛ pakietami. Pakiety z oprogramowaniem (*.rpm) obsługiwane sa˛ za pomoca˛ systemu Red Hat Package Management, który umożliwia spójne i komfortowe administrowanie. ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA P RODUKTY 44 P RZEZNACZENIE Obie dystrybucje przeznaczone sa˛ przede wszystkim do zastosowań na stacjach roboczych, wzgl˛ednie moga˛ być serwerami w Red Hat Linux i Red Hat Linux małych sieciach. Różnica pomi˛edzy dwoma oferowanymi produktami polega głównie na tym, że charakteryzuje je różny zakres Professional dostawy oraz różny czas udzielania pomocy technicznej. Wersja Professional zawiera wi˛eksza˛ ilość narz˛edzi do administrowania systemem. Rozwiazanie ˛ to przeznaczone jest przede wszystkim dla przedsi˛ebiorstw. Systemy Enterprise posiadaja˛ certyfikaty dla całego Enterprise Linux szeregu platform produkowanych przez różnych producentów osprz˛etu i obsługuja,˛ np. systemy klastrowe o wysokiej niezawodności. Tablica 2.4: Red Hat Poszczególne produkty różnia˛ si˛e od siebie przede wszystkim zalecanym obszarem zastosowania oraz wynikajacymi ˛ z tego możliwościami uzyskania pomocy technicznej, sposobem licencjonowania i cena.˛ 2.3.5 Certyfikaty W tym miejscu należy rozróżnić certyfikaty osprz˛etu, oprogramowania oraz certyfikaty umiej˛etności. Osprz˛et W ramach certyfikatów osprz˛etu przeprowadzana jest procedura polegajaca ˛ na jego testowaniu. Po przetestowaniu oprzyrzadowania, ˛ przyznawane sa˛ odpowiednie certyfikaty dla poszczególnych dystrybucji oraz wersji Linuksa. Sprawdzana jest wydajność oraz zgodność działania testowanych urzadzeń ˛ z ich specyfikacja˛ techniczna.˛ Producenci sprz˛etu maja˛ możliwość certyfikacji swoich produktów dla każdej dystrybucji. Cz˛esto posiadanie certyfikatu stanowi dla nich, oprócz gwarancji jakości, także ważny argument marketingowy. ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 45 Certyfikaty oferuja˛ klientom, szczególnie gdy chodzi o aplikacje i rozwiazania ˛ majace ˛ strategiczne znaczenie, np. systemy ERP z RAID albo SAN, zwi˛ekszona˛ pewność kompatybilności używanego osprz˛etu i systemu operacyjnego. Dla późniejszych klientów badź ˛ użytkowników certyfikaty moga˛ być decydujacym ˛ czynnikiem przy podejmowaniu decyzji o zakupie. Oprogramowanie Certyfikacj˛e oprogramowania przeprowadzaja˛ wszyscy producenci oprogramowania (Independent Service Vendor). Poszczególni producenci uwiarygadniaja˛ i certyfikuja˛ dystrybucje jako platform˛e - system operacyjny dla swojego oprogramowania. Przykładem takiego działania sa˛ przedsi˛ebiorstwa SAP oraz Oracle, które certyfikuja˛ SuSE Linux8 Enterprise Server jako platform˛e dla konkretnych aplikacji. Podobne certyfikaty uzyskuja˛ także producenci dystrybucji Red Hat9 . Z reguły procesom tym podlegaja˛ za każdym razem tylko wersje Enterprise dystrybucji tworzonych przez poszczególnych producentów oprogramowania. Certyfikacja oprogramowania jest dla wielu klientów podstawowym warunkiem wdrożenia danego systemu operacyjnego. Wynika to z tego, że kupujac ˛ produkty z certyfikatem, klienci cz˛esto otrzymuja˛ od producenta oprogramowania, wymagana˛ podczas instalacji i korzystania z dostarczanych aplikacji, pomoc techniczna.˛ Certyfikaty umiej˛etności Oprócz certyfikatów wydawanych na osprz˛et i oprogramowanie wymagane sa˛ również certyfikaty świadczace ˛ o poziomie wiedzy specjalistycznej oraz umiej˛etnościach pracowników. Obecnie istnieja˛ dwa wyróżniajace ˛ si˛e, miarodajne programy certyfikacji: ◦ program firmy Red Hat, Red Hat Certified Enginner (RHCE)10 oraz ◦ program Linux Professionell Institute (LPI)11 Celami obydwu z nich sa˛ m. in. stworzenie standardów oceny kwalifikacji pracowników. Dla pracodawców certyfikacja przedstawia dla nast˛epujace ˛ zalety: 8 http://www.suse.com/de/business/certifications/certified_software/index. html 9 http://www.redhat.com/solutions/migration/applist.html 10 http://www.redhat.com/training/rhce/courses/index.html 11 http://www.de.lpi.org/ ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 46 ◦ pomaga w procesie rekrutacji ◦ zapewnia standardowy sposób oceny kwalifikacji pracowników Pracownikom lub potencjalnym przyszłym pracownikom certyfikaty oferuja: ˛ ◦ możliwość wykonywania konkretnych zadań ◦ poświadczenie kwalifikacji ◦ zwi˛ekszenie szansy na rynku pracy. Zasadniczo obydwa programy certyfikacyjne można traktować jako równorz˛edne, przy czym RHCE ukierunkowany jest bardziej na własna˛ dystrybucj˛e. Przedsi˛ebiorstwo Red Hat zacz˛eło rozwijać program przyznawania certyfikatów jeszcze w czasach, gdy nie istniały programy certyfikacyjne dla systemów opartych na GNU/Linux. Dopiero później w społeczności Linuksa rozwina˛ si˛e program LPI. Jest on neutralny jeśli chodzi o dystrybucj˛e i producenta oprogramowania. 2.3.6 Wnioski Użytkownicy moga˛ dokonywać wyboru spośród licznych dystrybucji oraz różnych ich wersji. Przy podejmowaniu decyzji ważne jest rozpoznanie i ustalenie koniecznych wymagań. Decyzja o wyborze konkretnej dystrybucji zapaść może tylko w oparciu o każdorazowe oczekiwania wzgl˛edem dystrybucji badź ˛ producenta oraz tzw. warunki ramowe. Jeśli, np. z braku własnych zasobów ludzkich, niezb˛edna jest pomoc techniczna producenta, wówczas należy w pierwszej kolejności zastanowić si˛e nad wyborem dystrybucji komercyjnej. Gdy dla konkretnych zastosowań wymagane jest oprogramowanie certyfikowane, wówczas na ogół pozostaje tylko oferta firm komercyjnych i wersje Enterprise ich dystrybucji. To, jaki osprz˛et i oprogramowanie rzeczywiście posiada certyfikaty oraz dla jakiej dystrybucji i wersji, należy sprawdzić w każdym osobnym przypadku. Dla użytkowników, którzy nie sa˛ skazani na komercyjne wersje dystrybucji, stabilna,˛ dobrze przetestowana˛ oraz niezawodna˛ dystrybucja˛ na pewno okaże si˛e Debian. Jeśli konieczna tu b˛edzie szeroka pomoc techniczna, także w tym przypadku można zwrócić si˛e o pomoc do licznych, istniejacych ˛ na rynku, właściwych przedsi˛ebiorstw usługowych. ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 47 2.4 Licencje W świecie Linuksa istnieje cały szereg różnych modelów licencji. Najważniejsze z nich zostały nazwane i krótko scharakteryzowane poniżej. 2.4.1 GPL Zapewne najbardziej znanym modelem licencji jest General Public License (GPL) 12, która została stworzona przez Free Software Foundation. Zarówno Linux Kernel, jak i wi˛eksza cz˛eść aplikacji linuksowych udost˛epniane sa˛ na „GPL”, licencji która m. in. gwarantuje udost˛epnianie kodu źródłowego oraz dowolne korzystanie z programów. Aby oprogramowanie obj˛ete ta˛ licencja˛ także w przyszłości pozostało wolne, w GPL dokładnie zapisano wolności oraz warunki jego stosowania. Poszczególne wolności i warunki obejmuja: ˛ ◦ paragraf 0: Wolność wykonywania programu w każdym celu ◦ paragraf 1: Zezwolenie na kopiowanie oraz rozpowszechnianie dosłownych kopii kodu źródłowego programu, o ile załaczona ˛ jest do nich treść Copyright i licencja GPL. Wyraźnie zezwala si˛e także na pobieranie opłat za fizyczne 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˛ bezpłatne i publikowane na tej samej licencji. Wyjatkami ˛ sa˛ te cz˛eści zmienionego programu, które tworza˛ niezależna˛ całość i sa˛ rozpowszechniane oddzielnie. ◦ paragraf 3: Zezwolenie na kopiowanie programu albo opartych na nim wersji w postaci kodu obiektowego lub wykonywalnego, o ile dołaczony ˛ jest doń pełny kod źródłowy w postaci nadaja˛ cej si˛e do odczytania przez komputer lub pisemna oferta, (ważna przez co najmniej 3 lata), gotowości do przekazania go na żadanie. ˛ 12 http://www.gnu.org/licenses/translations.pl.html Oryginał licencji znajduje si˛e na stronie:http://www.gnu.org/copyleft/gpl.html ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 48 Kolejne paragrafy dotycza˛ przepadku praw wynikajacych ˛ z licencji, r˛ekojmi oraz gwarancji. Ponadto opisane sa˛ w nich konflikty z innymi roszczeniami i cały szereg innych zagadnień, o których w razie potrzeby można przeczytać. Dzi˛eki swoim warunkom licencja GPL zapobiega prywatyzacji stworzonego wspólnie oprogramowania i tym samym wyraźnie wspiera ciagłość ˛ istnienia oraz rozwój Wolnego Oprogramowania. 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 zbieżna z zamiarami wyrażanymi w GPL. Także tu musi istnieć dowolność kopiowania, rozpowszechniania i modyfikowania oprogramowania, wzgl˛ednie bibliotek. Oprócz tego kod źródłowy, również ten ze zmodyfikowanych wersji, musi być udost˛epniany bez ograniczeń. Różnica w porównaniu z GPL polega przede wszystkim na tym, że programy, które nie sa˛ publikowane na licencji GPL lub podobnej, moga˛ używać wolnych bibliotek rozprowadzanych na zasadach LGPL i tworzyć odr˛ebna˛ wykonywalna˛ całość. Gdyby w/w biblioteki udost˛epniane były na licencji GPL, wówczas wykorzystywać by je mogły tylko programy publikowane wyłacznie ˛ na GPL. W przeciwieństwie do tego licencja LGPL zezwala programistom na tworzenie programów, które nie sa˛ rygorystycznie chronione przez GPL, przy użyciu wolnych bibliotek. Programy, które używaja˛ bibliotek udost˛epnianych na licencji LGPL, moga˛ być rozpowszechniane na dowolnie wybranych warunkach licencjonowania, jednak z zastrzeżeniem udost˛epnienia klientowi kodu źródłowego bibliotek udost˛epnianych na LGPL, co ma na celu umożliwienie mu modyfikacji i ponownego użycia kodu. 2.4.3 BSD Licencja BSD14 jest jedna˛ z najstarszych wolnych modelów licencji. Powstał on na uniwersytecie Berkeley w celu rozpowszechniania zmodyfikowanych wersji Uniksa 15. Licencja BSD zezwala na dowolne kopiowania oprogramowania z lub bez własnych modyfikacji, zarówno w postaci kodu źródłowego, jak i/lub binariów pod nast˛epujacymi ˛ warunkami: 13 http://www.gnu.org/copyleft/lesser.html http://www.opensource.org/licenses/bsd-license.html 15 Licencja dotyczyła wyłacznie ˛ kodu źródłowego stworzonego na uniwersytecie Berkeley. 14 ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 49 Odpowiednie pliki rozpowszechnianego oprogramowania musza˛ zawierać treść Copyright oraz licencj˛e BSD. W przypadku rozpowszechniania oprogramowania w formie binarnej, treść Copyright oraz zapisy licencji BSD musza˛ być zawarte w dokumentacji oprogramowania lub innej. Bez posiadania pisemnej zgody nie wolno używać w celach reklamowych ani nazwy uniwersytetu, ani też nazwisk autorów. W pierwotnej wersji licencji istniał jeszcze jeden aspekt, tj. we wszystkich materiałach reklamowych mówiacych ˛ o programach rozprowadzanych w oparciu o BSD, musiała znajdować si˛e nast˛epujaca ˛ adnotacja: „Niniejszy produkt zawiera oprogramowanie, które zostało stworzone przez Kalifornijski Uniwersytet Berkeley i jego kooperantów”. Klauzula ta została usuni˛eta ze starej licencji, a ostatnia wersja Berkeley jest już opublikowana w oparciu o nowa˛ licencj˛e. Dlatego mówi si˛e zarówno o starej, jak i nowej licencji BSD. BSD nie zawiera ograniczeń dotyczacych ˛ użytkowania oraz rozpowszechniania kodu źródłowego badź ˛ programów. Wymagane jest jedynie załaczanie ˛ do oprogramowania treści Copyright, samej licencji BSD oraz warunków wygaśni˛ecia gwarancji. Licencja nie zmusza do udost˛epniania zmodyfikowanego oprogramowania wraz z kodem źródłowym. Dlatego każda firma programistyczna może wykorzystać w swoim oprogramowaniu kod źródłowy oparty o licencj˛e BSD bez konieczności udost˛epniania źródeł własnego programu. Licencja BSD wiaże ˛ si˛e, w porównaniu z wcześniej opisanymi licencjami, ze znacznie mniejszymi restrykcjami. 2.5 Zbieranie informacji o projektach Wyniki przedstawione w poradniku opieraja˛ si˛e głównie na: ◦ doświadczeniach zdobytych w czasie wdrażania projektów migracyjnych ◦ doświadczeniach zdobytych podczas rozwijania oprogramowania OSS oraz COLS ◦ uwzgl˛ednienia know-how ekspertów ◦ badań nad możliwościami wdrożenia planowanych migracji ◦ szczegółowo opracowanych koncepcjach migracji ◦ literaturze specjalistycznej oraz dokumentacji oprogramowania. Specjalistyczne informacje ważne dla powstania poradnika zostały zebrane w oparciu o: ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 50 ◦ intensywna˛ analiz˛e dokumentów ◦ wywiady i ich ocen˛e ◦ warsztaty organizowane pod katem ˛ konkretnych zagadnień oraz ◦ bezpośrednie zaangażowanie licznych ekspertów i producentów oprogramowania. Treść oraz wnioski wynikajace ˛ z powyższych źródeł informacji zostały w poradniku przedstawione tematycznie, w formie pojedynczych zagadnień. Jednocześnie zostały one przeanalizowane i ocenione. 2.5.1 Doświadczenia z projektów migracyjnych Wdrażanie i wykorzystywanie OSS jest obecnie na porzadku ˛ dziennym zarówno w administracji publicznej, jak i w przedsi˛ebiorstwach. Duże zainteresowanie tym zagadnieniem doprowadziło już do powstania całego szeregu projektów migracyjnych, w których opisywane sa˛ najaktualniejsze doświadczenia i wnioski. Obok czysto technologicznych informacji i doświadczeń, projekty te zawieraja˛ ważne wnioski na temat krytycznych wyznaczników sukcesu (patrz 5.5.3) oraz oczekiwanych nakładów podczas poszczególnych etapów migracji. W ramach przygotowań do badań nad sposobami migracji zebrano różne dokumenty, takie jak dokładne specjalistyczne koncepcje, opisy wydajności oraz całościowe dokumentacje projektów. Taka dokładna analiza stała si˛e także podstawa˛ dla powstania poradników nt. przeprowadzania wywiadów zwiazanych ˛ tematycznie z poszczególnymi obszarami badań prowadzonych nad projektem. Gromadzenie informacji polegało, na ogół, na przeprowadzaniu wywiadów w urz˛edach i firmach badź ˛ wywiadów z administratorami, użytkownikami i wdrożeniowcami. Pytania dotyczyły nast˛epujacych ˛ zagadnień: ◦ sytuacja wyjściowa ◦ strategiczne elementy projektu ◦ motywacja i sposoby wyznaczania celu ◦ krytyczne wyznaczniki sukcesu ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 51 ◦ koszty i korzyści ◦ Lessons Learned ◦ projekty przyszłościowe - rozwój strategii informatycznej Zostały one uzupełnione szczegółowymi technicznymi pytaniami dotyczacymi ˛ migracji cz˛eściowej, odpowiednio do specyficznych technicznych problemów wyst˛epujacych ˛ przy poszczególnych projektach. Jeśli chodzi o projekty migracyjne, to przygotowywanie ich możliwe jest m. in. w oparciu o doświadczenia wynikajace ˛ z projektów pilotażowych zainicjowanych przez Federalny Urzad ˛ ds. Bezpieczeństwa w Informatyce (BSI) na zlecenie Ministerstwa Spraw Wewn˛etrznych (BMI). W czasie tworzenia niniejszego poradnika, projekty te były już w poważnym stopniu wdrożone i zakończone dużym sukcesem. Z drugiej strony analizowane były projekty pochodzace ˛ z administracji publicznej i przedsi˛ebiorstw, w których dokonano migracji w oparciu o ocen˛e ekonomiczna˛ i z których napłyn˛eły informacje oraz doświadczenia z przeprowadzonych migracji. W przypadku wszystkich tych projektów mamy i mieliśmy do czynienia z najróżniejszymi sytuacjami wyjściowymi. Najcz˛eściej były to systemy oparte o serwery Windows NT 4, które należało zastapić ˛ i skonsolidować. Jeśli chodzi o serwery, istniały także środowiska mieszane, składajace ˛ si˛e z Windows NT, Unix i GNU/Linuksa. Po stronie klientów reprezentowane było różnorodne oprogramowanie ze świata Windows - od Windows 95, aż do Windows XP. W przeważajacej ˛ cz˛eści były to, odpowiednio do obecnego wyposażenia wi˛ekszości urz˛edów, stacje robocze Windows NT 4. Także zakres i rodzaj migracji może mieć bardzo wiele wariantów. I tak oprócz zaawansowanych całkowitych migracji (serwery i klienty) przeprowadzano migracj˛e wyłacznie ˛ na serwerach przy jednoczesnym pozostawieniu na stacjach roboczych systemu Windows NT 4. Możliwe przy tym było przej˛ecie istniejacych ˛ struktur plików oraz uprawnień bez konieczności wprowadzania zmian na klientach NT odczuwalnych dla użytkowników. Ponadto w jednym z ocenianych projektów migracyjnych założyliśmy, że migracja ma miejsce wyłacznie ˛ na stacjach roboczych, które b˛edac ˛ klientami linuksowymi sa˛ zintegrowane z istniejac ˛ a˛ siecia˛ NT4. Ponadto nie mogliśmy nie wspomnieć 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ź ˛ alternatywne oprogramowanie na Linuksa, opisaliśmy zastosowanie terminali i emulatorów. ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 52 Patrzac ˛ z technicznego punktu widzenia, mogliśmy korzystać z doświadczeń migracyjnych zebranych podczas przeprowadzania migracji ważnych 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ównież 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 pilotażowe zainicjowane przez BSI zostały wdrożone w nast˛epujacych ˛ urz˛edach: ◦ Federalny Urzad ˛ ds. Karteli ◦ Komisja ds. Monopoli ◦ Instytut Hodowli Zwierzat ˛ Mariensee Inne zgromadzone projekty sa˛ w nast˛epujacych ˛ urz˛edach na etapie planowania, właśnie si˛e je wdraża albo zostały już zrealizowane: ◦ Urzad ˛ Pełnomocnika Rzadu ˛ ds. Ochrony Danych Osobowych (BfD) ◦ Ministerstwo Administracji (BVA) ◦ BSI Do tego należy jeszcze dodać szereg firm, których projekty z zakresu infrastruktury oraz aplikacji dostarczaja˛ cennych informacji, szczególnie jeśli chodzi o wdrożenia systemów ERP i DBMS oraz o wykorzystanie technologii Terminal-Server i platform do zarzadzania ˛ systemem. ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA 53 2.5.2 Opinie ekspertów Oprócz oceny doświadczeń i wyników otrzymanych z projektów migracyjnych na ostateczna˛ treść poradnika miały także wpływ prace prowadzone przez różnych ekspertów, zarówno przedstawicieli społeczności 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 jakości. W procesie szukania odpowiedzi na istniejace ˛ pytania, szczególnie owocne okazały si˛e warsztaty organizowane przy współudziale specjalistów. Obj˛eły one nast˛epujace ˛ dziedziny: ◦ Migracja z zastosowaniem Samby w heterogenicznym środowisku składajacym ˛ si˛e z Linuksa i Windows. ◦ Migracja DBMS, dla której punktem wyjścia był MS SQL Server 7, prowadzaca ˛ do wdrożenia wolnej bazy danych badź ˛ systemu bazodanowego pracujacego ˛ pod Linuksem. ◦ Migracja Groupware, dla której punktem wyjścia był Exchange 5.5 z uwzgl˛ednieniem pracy w środowiskach heterogenicznych i dalszego wykorzystywania MS Outlook. ◦ Migracja na desktopach koncentrujaca ˛ si˛e na zastapieniu ˛ pakietu MS Office (Office 97/2000) oprogramowaniem OpenOffice / StarOffice) oraz na zwiazanym ˛ z tym przej˛eciem dotychczas zgromadzonych szablonów, plików, makr i skryptów. ◦ Wdrożenie usług katalogowych, miedzy innymi wykorzystanie usług katalogowych OpenLDAP, jako oprogramowania Open Source, także w połaczeniu ˛ z Active Directory w systemach heterogenicznych. ◦ Wykorzystanie WiBe21, jako podstawy do oceny opłacalności 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 środowisk 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 Office Oceny skupiaja˛ si˛e na technicznych możliwościach przejścia od poszczególnych produktów firmy Microsoft do adekwatnych rozwiazań ˛ OSS lub COLS. W oparciu o przedstawione w rozdziale 2.1 składniki infrastruktury Windows, przeprowadzona została ich dokładna analiza: Ustalenie sytuacji wyjściowej ◦ Z jakich ważnych funkcji można korzystać? ◦ Jakie interfejsy sa˛ badź ˛ powinny zostać wykorzystane? ◦ Jakie szczególne zachowanie programów zauważono podczas pracy? Z jakich alternatywnych rozwiaza ˛ ń OSS badź ˛ COLS można korzystać? ◦ Na czym polegaja˛ różnice w działaniu? ◦ Czy spełnione sa˛ krytyczne wymagania? ◦ Jakie interfejsy sa,˛ wzgl˛ednie musza˛ być obsługiwane? ◦ Co należy wziać ˛ pod uwag˛e przy planowaniu migracji, co może stanowić problem i jak rozwiazywać ˛ problemy? ◦ Czy istnieje wiele alternatywnych rozwiazań? ˛ Dla kogo, ewentualnie w jakim celu korzystać z danego alternatywnego rozwiazania? ˛ ◦ Jak można zintegrować alternatywne rozwiazania ˛ z systemami heterogenicznymi. Jeśli jest to konieczne, jak wyglada ˛ ich współpraca, szczególnie z systemem Microsoft, kompatybilność? ◦ Jaki wpływ na tego typu integracj˛e maja˛ przyszłe kierunki rozwoju oprogramowania Microsoft? ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 56 Na czym polega potencjał kontynuacyjnego wykorzystywania produktów Microsoft? ◦ Z jakich dodatkowych funkcji można korzystać? ◦ Na czym polegaja˛ najistotniejsze zmiany? ◦ Czy nowości oraz ewentualne modyfikacje spełniaja˛ najważniejsze wymagania? ◦ Czego należy przestrzegać, aby zachować niezależności systemów? Wszystkie uwagi kończa˛ si˛e z reguły krótka˛ ocena.˛ W przypadku wi˛ekszej ilości alternatywnych rozwiazań, ˛ jeśli ma to sens, komentowane sa˛ także porównywalne rozwiazania. ˛ 3.2 Zarzadzanie ˛ plikami 3.2.1 Przeglad ˛ W wyniku przeprowadzenia szczegółowej technicznej oceny technologii zarzadzania ˛ plikami można stwierdzić, co nast˛epuje: W przypadku bezpośredniego zastapienia ˛ serwerów Windows NT przechowujacych ˛ dane, przy zachowaniu stacji roboczych z Windows, środowisko Open Source ma w pierwszym rz˛edzie do zaoferowania serwer Samba. Jego funkcjonalność podczas obsługi windowsowych stacji roboczych prezentuje si˛e dość podobnie, jak serwer NT. Dodatkowo Samba jest stale rozwijana nie tylko przez społeczność Open Source, lecz także przez rosnac ˛ a˛ ilość producentów z branży informatycznej. W zależności od zakresu migracji stacji roboczych na Linuksa, w kontekście zarzadzania ˛ plikami można także rozważyć alternatywne technologie takie jak NFS i AFS. Sa˛ one rozpowszechnione w sieciach uniksowych, jednak by umożliwić ich integracj˛e z windowsowymi stacjami roboczymi konieczne jest zainstalowanie po stronie klientów specjalnego oprogramowania. Klient NFS dost˛epny jest mi˛edzy innymi w Microsoft Windows Services for UNIX (SFU 3.0), natomiast klient AFS jest nieodpłatny i dost˛epny jako oprogramowanie Open Source na stronie http://OpenAFS.org OpenAFS.org. Jednakże, by móc zastosować klienty NFS albo AFS w środowisku windowsowych stacji roboczych, trzeba wprowadzić daleko idace, ˛ koncepcyjne zmiany, w porównaniu z sytuacja,˛ gdy zarzadzanie ˛ plikami odbywa si˛e z wykorzystaniem Windows NT. Jeśli podczas modernizacji infrastruktury informatycznej tworzonej w ramach projektu migracyjnego ważna˛ rol˛e odgrywa metoda zapewnienia bezpieczeństwa za pomoca˛ Kerberos, która ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 57 leży także u podstaw Active Directory w Windows 2000, wówczas w przypadku kontynuacyjnego korzystania z produktów Windows po stronie klientów, należy zmierzać w kierunku zastosowania OpenAFS jako alternatywy dla Win2000 jako serwera plików. Do fizycznego zapisywania danych na systemach dyskowych właściwych serwerów nadaja˛ si˛e m.in. systemy plików XFS i EXT3. Obydwa systemy obsługuja˛ journaling, kwotowanie oraz nadawanie praw dost˛epu na poziomie plików i katalogów. Zarówno XFS, jak i EXT3 obsługuja˛ rozszerzone atrybuty plików oraz listy kontroli dost˛epu POSIX-ACL umożliwiajace ˛ przyznawanie uprawnień. Podczas odwzorowywania Windows-ACL na POSIX-ACL należy uwzgl˛ednić to, że straci si˛e dokładność, z jaka˛ można definiować uprawnienia pod Windows. Należy także sprawdzić, jaki wpływ ograniczenia te maja˛ w pojedynczym przypadku oraz czy można je zaakceptować. 3.2.2 Windows NT 4 3.2.2.1 Wymagania odnośnie funkcjonalności Generalny zakres funkcjonalności 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 dost˛epu i ograniczeń dost˛epu dla katalogów i plików ◦ blokowaniu dost˛epu do plików w przypadku konkurencyjnego dost˛epu Wykorzystywanie Windows NT File Services służy w wi˛ekszości środowisk do realizacji nast˛epujacych ˛ celów: ◦ składowanie plików użytkowników (katalogi domowe) ◦ składowanie profilów opartych na serwerach, jeśli na stacjach klienckich trzeba zoptymalizować obsług˛e mobilnych użytkowników (roaming user) ◦ składowanie plików należacych ˛ do określonych grup (katalogi grup), z których moga˛ korzystać tylko niektórzy użytkownicy (np. z jednego działu) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 58 ◦ składowanie plików w bazach danych, do których jednoczesny dost˛ep powinno mieć wielu użytkowników (np. bazy danych MS Access z oddzielnym frontendem) ◦ składowanie plików programów (pliki *.exe, *.dll etc. danej aplikacji) w celu unikni˛ecia przechowywania plików na komputerze klienckim. ◦ składowanie systemów baz danych oferujacych ˛ możliwość umieszczania danych użytkowych na innym serwerze pod ścieżka˛ UNC. Opisane tu cele wykorzystania, w praktyce bardzo cz˛esto zwiazane ˛ sa˛ z różnymi 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łaściwości NTFS4 posiada mi˛edzy innymi nast˛epujace ˛ właściwości: Każdy katalog i każdy plik dysponuje tak zwana˛ Access Control List (ACL), która jest zapisywana na pliku badź ˛ katalogu. W ACL zapisane sa˛ tak zwane Access Control Entries (ACE), w którym zapisane sa˛ SID kont grup albo użytkowników oraz ich uprawnienia. Dlatego poprzez ACL można przydzielać prawa dost˛epu w sposób szczegółowy i zintegrowany. ACL należy podzielić na SACL (System Access Control List) oraz DACL (Discretionary Access Control List). W DACL składowane sa˛ SIDs grup i użytkowników, którym wolno albo nie wolno mieć dost˛epu do obiektu. W SACL ustala si˛e, w jaki sposób podsystem bezpieczeństwa kontroluje dost˛ep 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 si˛e zmienia,˛ wówczas trzeba osobno wywołać przepisanie ich do ACLi mieszczacych ˛ si˛e w nim plików. Należy zwrócić uwag˛e na jedna˛ szczególna˛ cech˛e: plik znajdujacy ˛ si˛e na ścieżce UNC \\serwer\zezwolenie-udost˛epnienie\katalo może być czytany przez użytkownika, mimo że katalog „katalog“ tego zakazuje, jednak katalog „podkatalog“ na to zezwala. Nie ma ograniczenia długości ścieżek. Obsługiwane sa˛ nazwy plików składajace ˛ si˛e maksymalnie z 256 znaków. Teoretycznie znaki te moga˛ być zgodne z Unicode (16 bitów), jednak ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 59 istnieje kilka wyjatków ˛ (np. *, \). Dla każdego katalogu i każdego pliku zapisywany jest skrót nazwy, który odpowiada konwencji 8.3 i jest automatycznie generowany przez system operacyjny. O ile podczas zapisywania rozróżniana jest pisownia wielka˛ i mała˛ litera,˛ o tyle w przypadku dost˛epu do pliku nie jest to reguła.˛ Każdy katalog i każdy plik dysponuje atrybutami w formie flag (chroniony przed zapisem, archiwalny, systemowy, ukryty i spakowany) oraz czasy: utworzenia, ostatniej zmiany i ostatniego dost˛epu. Stopień kompresji silnie zależy od zawartości. NTFS obsługuje technologi˛e Multiple Streams, jednak funkcja ta jest dość rzadko wykorzystywana. Multiple Streams musza˛ być wówczas obsługiwane przez każda˛ aplikacj˛e, wzgl˛ednie być w niej zaprogramowane. Multiple Streams umożliwiaja˛ mi˛edzy innymi zapisywanie Resource Fork plików Macintosh. Poczawszy ˛ od Service Pack 4 w ramach NTFS obsługiwane sa˛ kwoty. Ich przydzielanie i kontrola opiera si˛e na cechach użytkownika i obejmuje cały wolumen (nap˛ed logiczny serwera plików). Wskutek tych technicznych ograniczeń należy uznać ich zastosowanie w istniejacych ˛ środowiskach raczej za przypadek szczególny niż za reguł˛e. Maksymalna wielkości plików zarzadzanych ˛ w ramach NTFS4 wynosi 2TB (terabajty). Ponadto jest ona ograniczona wielkościa˛ nap˛edu logicznego. Nap˛ed logiczny może pomieścić maksymalnie 2 TB (teoretycznie 16 exabajtów). Rzeczywista ilość danych netto zależy od wielkości klastra, który został zastosowany podczas formatowania. Ilość plików ograniczona jest do 2 32 1. NTFS umożliwia kontrol˛e zrealizowanych dost˛epów, wzgl˛ednie prób dost˛epu. W ten sposób można, np. zdiagnozować powtarzajace ˛ si˛e, niechciane usuwanie plików. Nośniki danych sformatowane dla NTFS sa˛ podczas pracy defragmentowane. W Windows NT4 nie jest wykonywana automatyczna korekta (samoleczenie). Do tego celu należy zastosować produkty innych firm. System uprawnień w NTFS Windows zna w sumie 13 uprawnień, które moga˛ zostać przyznane lub odebrane użytkownikowi badź ˛ grupie dla obiektu (plik albo katalog) znajdujacego ˛ si˛e 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 uprawnień ◦ zmiana uprawnień ◦ przejmowanie uprawnień właściciela Zmiany w prawach dost˛epu przeprowadzane sa˛ poprzez okno dialogowe Properties i zakładk˛e Security settings. Aby zmniejszyć dla przeci˛etnego użytkownika stopień skomplikowania systemu bezpieczeństwa złożonego z 13 ściśle spokrewnionych praw dost˛epu, w zakładce tej zdefiniowano gotowe składniki, tak zwane grupy uprawnień, które stanowia˛ podstaw˛e wyboru sensownej kombinacji pojedynczych uprawnień. Dla plików istnieje 5 a dla katalogów sześć takich zestawów, które każdorazowo można uaktywnić badź ˛ zignorować. Dopiero w oknie dialogowym Privilege entry, które można wyświetlić w ramach Security settings naciskajac ˛ kolejne przyciski Extended/Display/Edit, pojawi si˛e wszystkich 13 uprawnień. W dodatku uzyskanie podgladu ˛ grup uprawnień poprzez Security settings jest bardzo trudne, gdyż ich prezentacja może bardzo szybko skończyć si˛e komunikatem braku praw dost˛epu, mimo że w rzeczywistości posiadamy odpowiednie uprawnienia. I tak, np. z pełnego dost˛epu, gdy nie jest możliwe jedynie przypisywanie rozszerzonych atrybutów, powstaje w prostej prezentacji w Security settings obraz profilu uprawnień, który zezwala tylko na odczyt i wykonywanie. Poniższa tabela pokazuje, jakie kombinacje uprawnień tworza˛ poszczególne grupy uprawnień. Jeśli zaledwie jedno uprawnienie z całego przedstawionego poniżej zestawu nie b˛edzie zaznaczone, wówczas odpowiedni dla konkretnej grupy uprawnień checkbox nie zostanie odhaczony. W INDOWS - GRUPY UPRAWNIE Ń ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI Pełny Zmiana dost˛ep 61 Odczyt & Wylisto- wykony- wanie wanie zawartości Odczyt Zapis katalogu przeszukiwanie katalogu / X X X X X X X X X czytanie atrybutów X X X X X czytanie rozszerzonych X X X X X X X X X X X przypisywanie atrybutów X X X przypisywanie rozsze- X X X wykonywanie pliku wylistowanie katalogów / czytanie danych atrybutów tworzenie plików / zapisywanie danych tworzenie katalogów / przyłaczanie ˛ danych rzonych atrybutów usuwanie podkatalogów / X plików usuwanie X X czytanie uprawnień X X zmiana uprawnień X X X X X Tablica 3.2: Windows - grupy uprawnień Z powodu opisanej niespójności, w dalszej cz˛eści oceniany b˛edzie jedynie rozszerzony widok okna dialogowego Privilege entry. System atrybutów Dodatkowo, oprócz administrowania uprawnieniami do plików i katalogów, istnieje jeszcze możliwość zarzadzania ˛ tak zwanymi atrybutami oraz rozszerzonymi atrybutami. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI NAZWA B IT 62 Z NACZENIE Plik został zmieniony od ostatniego nada- Archiwalny A Chroniony przed R Plik jest chroniony przed 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. nie atrybutu. zapisem Tablica 3.4: Atrybuty w Windows Kontrola Windows umożliwia rozległa˛ kontrol˛e nad plikami i katalogami. Dzi˛eki temu można nadzorować wszystkie uprawnienia pojedynczego użytkownika lub grupy. Otrzymane w ten sposób informacje zapisywane sa˛ w protokole bezpieczeństwa kontrolera domen, wzgl˛ednie na poszczególnym komputerze z Windows 2000, o ile w systemie zezwoli si˛e na tego typu kontrol˛e. 3.2.2.3 Ustawianie praw dost˛epu Ustawianie praw dost˛epu do plików lub katalogów znajdujacych ˛ si˛e w sieci realizowane jest w środowisku Windows NT za pomoca˛ dwóch mechanizmów, którymi sa: ˛ ◦ odblokowanie dost˛epu do katalogu (share) oraz ◦ prawa dost˛epu NTFS Aby mieć dost˛ep do pliku przez sieć, należy otworzyć drog˛e do nadrz˛ednego katalogu. Umożliwia to odpowiedni wpis ACL umieszczony w rejestrze. Prawa dost˛epu do takich zasobów sa˛ stopniowane: ◦ prawo do odczytu ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 63 ◦ prawo do zmian oraz ◦ pełny dost˛ep Powyższe uprawnienia sa˛ absolutne, tzn. moga˛ one ograniczać podlegajace ˛ im uprawnienia NTFS. Przykład: prawo do odczytu na poziomie zasobu uniemożliwia zapisywanie również wtedy, gdy pozwoliłyby na to uprawnienia NTFS. W środowiskach Windows NT uprawnieniom (wytycznym dotyczacym ˛ uprawnień użytkownika) należy poświ˛ecić szczególna˛ uwag˛e, ponieważ moga˛ one mieć znaczenie dla File Services, np. przy „przejmowaniu praw własności do plików i obiektów“ oraz „zabezpieczaniu plików i katalogów“. 3.2.2.4 Użytkownicy i znaczenie grup Każdy katalog i każdy plik przyporzadkowany ˛ jest jednemu właścicielowi, którym może być zarówno grupa, jak i konto użytkownika. W normalnym przypadku użytkownik, który tworzy dany element, jest jego właścicielem. Jeśli użytkownik należy do grupy administratora, wówczas ona staje si˛e właścicielem. Przy ustawianiu praw dost˛epu w środowisku Windows NT systemowo preferowane jest przyznawanie uprawnień grupom. Nadawanie praw kontom poszczególnych użytkowników powinno odbywać si˛e w ramach systemów plików właściwych dla użytkownika. Wewnatrz ˛ środowiska Windows NT należy wyróżnić nast˛epujace ˛ grupy: ◦ globalne ◦ lokalne na Member Servers ◦ lokalne na Domain Controllers Lokalne grupy na kontrolerach domen różnia˛ si˛e od tych na Member Servers, gdyż maja˛ one ten sam SID na wszystkich kontrolerach domen danej domeny. Lokalne grupy na Member Servers wolno zagnieżdżać (Group Nesting) z nast˛epujacymi ˛ 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 użytkowników tylko jako członkowie. W środowisku domen Windows NT znane sa˛ dwa różne „klasyczne“ sposoby ustawiania praw dost˛epu: ◦ metoda B-G-L-R Użytkownik jest członkiem globalnej grupy. Z kolei ona jest członkiem lokalnej grupy serwera plików. Uprawnienia NTFS ustawione sa˛ na file resource jedynie dla tej lokalnej grupy (patrz rys. 3.1). ◦ metoda B-G-R Użytkownik jest członkiem globalnej grupy. Uprawnienia NTFS ustawione sa˛ na file 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 zagrażajac ˛ bezpieczeństwu tylko wtedy, gdy przyporzadko˛ wanie zasobów oraz lokalnej badź ˛ globalnej grupy jest jednoznaczne, czyli gdy grupa przypisana jest wyłacznie ˛ dla danego zasobu. Jeśli File Services realizowane sa˛ przez klaster, wówczas metoda B-G-L-R ma t˛e wad˛e, że lokalne grupy na serwerach w˛ezłowych nie moga˛ posiadać identycznego SIDa. Zaradzić temu można jedynie konfigurujac ˛ w˛ezły jako kontrolery domeny albo stosujac ˛ metod˛e B-G-R. 3.2.2.5 Narz˛edzia Do edycji plików i katalogów oraz praw dost˛epu do nich Windows NT oferuje dość ograniczony wybór narz˛edzi: ◦ działajace ˛ w środowisku graficznym – NT Explorer (explorer.exe) – menedżer plików (winfile.exe) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 66 ◦ działajace ˛ z linii poleceń – cacls – Resource Kit Tools: xcacls, scopy etc. Dostarczane narz˛edzia nie oferuja˛ na ogół pełnego, lecz tylko dedykowany zakres funkcji. Najlepszym tego przykładem jest NT Explorer, który nie daje możliwości tworzenia użytkownika (jedynie przej˛ecie użytkownika) ani też kopiowania List Kontroli Dost˛epu (ACLs). Dlatego należy założyć, że administrowanie środowiskiem NT musi być prowadzone z wykorzystaniem narz˛edzi dostarczanych przez innych producentów albo za pomoca˛ własnych skryptów (np. napisanych w j˛ezyku Perl), których zadaniem jest uproszczenie administrowania albo wykonywanie bardzo specjalnych zadań. Skutkiem tego może być wyświetlanie przez NT Explorer struktury uprawnień, która b˛edzie różnić si˛e od rzeczywiście nadanych praw dost˛epu. 3.2.2.6 Protokoły sieciowe Komunikacja poprzez sieć z wykorzystaniem Windows NT File Servers może opierać si˛e na różnych protokołach sieciowych: ◦ TCP / IP ◦ NetBEUI ◦ SPX / IPX ◦ AppleTalk Obecność TCP / IP, NetBEUI oraz SPX / IPX w jednym istniejacym ˛ środowisku NT nie jest nieprawdopodobne. Zasadniczo przyjmuje si˛e, że przyszłościowym i jedynym ważnym protokołem, który należy wspierać jest TCP / IP. Z tego powodu w dalszej cz˛eści nie b˛eda˛ 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) można uznać za standardowy sposób komunikacji na portach 137/UDP/TCP (nbname), 138/UDP (nbdatagram), 139/TCP (nbsession). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.2.2.7 67 Zestawianie połaczenia ˛ Z reguły użytkownikowi otwiera si˛e dost˛ep do zasobów zgromadzonych na serwerach plików, w postaci liter przypisanych do nap˛edów. Cz˛esto jest to realizowane poprzez skrypt logowania. Ponadto użytkownik ma możliwość „surfowania“ po sieci Windows, tzn. może klikajac ˛ ła˛ czyć si˛e z zasobami, które sa˛ dla niego wyświetlane przez serwer plików za pośrednictwem nap˛edu sieciowego albo otwierać je bezpośrednio. 3.2.2.8 Migracja - szczegóły robocze Poniżej zostały wypunktowane szczegóły, które moga˛ być krytycznymi elementami migracji. ◦ Niekiedy z punktu widzenia składowania plików użytkownika (katalogi domowe) wymagane jest, żeby umieszczane tam dane mogły być czytane tylko przez samego użytkownika oraz system operacyjny (np. w celu ochrony przed wirusami). W Windows NT istnieje możliwość skorzystania z konta systemowego. ◦ Składowanie profilów opartych na serwerze podlega podczas odpisywania (writing back) skomplikowanemu procesowi po stronie klienta. Bezbł˛edna˛ komunikacj˛e oraz właściwa˛ struktur˛e uprawnień należy zapewnić szczególnie w środowiskach Terminal Server, które bezwzgl˛ednie wymagaja˛ profilów opartych na serwerze. ◦ Do plików przypisanych do grup może mieć jednoczesny dost˛ep wielu użytkowników. Wymagane jest przy tym, aby użytkownik był informowany o współużytkowaniu danych zasobów. Przykład: użytkownik, który, jako drugi, otwiera plik *.doc (Word), otrzymuje komunikat, że użytkownik 1 już wcześniej otworzył ten plik, a on może otwierać dany plik w trybie tylko do odczytu. ◦ Podczas składowania baz danych opartych na plikach, także plikach *.pst (katalogi osobiste w programie Outlook), musi bezbł˛ednie działać funkcja locking. Cz˛esto nie ma możliwości zapewnienia składowania plików programów w sposób całkowicie chroniacy ˛ przed zapisem. Wymagane jest w takim przypadku bardzo szczegółowe stopniowanie uprawnień (np. zapisywanie, ale nie usuwanie konkretnego pliku). ◦ Tylko nieliczne aplikacje obsługujace ˛ systemy baz danych (np. MS SQL) oferuja˛ możliwość, składowania danych użytkowych na innym serwerze pod ścieżka˛ UNC, z tym że w takim przypadku szczególnie ważne jest zapewnienie bezbł˛ednej komunikacji oraz składowania plików, co wymaga zezwolenia / opinii producenta aplikacji. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.2.2.9 68 Tematy pokrewne File Services realizowane w Windows NT przez produkty innych producentów musza,˛ oprócz składowania plików, spełniać w istniejacych ˛ środowiskach jeszcze inne ważne wymagania. ◦ Ochrona przed wirusami: Ochrona przed wirusami realizowana jest najcz˛eściej przez lokalna˛ instalacj˛e skanera antywirusowego na samym serwerze plików. Dzi˛eki usłudze zainstalowanej lokalnie, skanowanie pliku jest możliwe dopiero przy próbie uzyskania dost˛epu do niego. Z takiego rozwiazania ˛ korzysta wielu producentów oprogramowania antywirusowego. Alternatywna˛ możliwościa˛ jest skanowanie nap˛edów serwera plików poprzez sieć z innego komputera. Jednak wady takiego rozwiazania ˛ sa˛ oczywiste; przejawiaja˛ si˛e one w postaci powstajacego ˛ obciażenia ˛ i czasowego opóźnienia. ◦ Kwotowanie: Wbudowane w Windows NT kwotowanie z reguły nie jest wykorzystywane. Aby zakładać kwoty na zasoby użytkowników lub grup, konieczne jest zastosowanie oprogramowania innych producentów. ◦ Zabezpieczanie danych: Wykorzystanie narz˛edzia NTBACKUP jest raczej rzadko spotykane. 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 ważnym kryterium jest czas odtwarzania zasobów podczas Desaster Recovery. Ciekawostka˛ jest fakt, że za pomoca˛ NTBACKUP można zabezpieczać także te dane, które w innym przypadku nie moga˛ być czytane przez wykonujacego. ˛ ◦ Archiwizacja: Cz˛esto w ramach zabezpieczania danych wykonywana jest trwała archiwizacja (revision-safe). Ponadto niektóre produkty innych producentów daja˛ możliwość, umieszczania rzadko używanych plików na mniej kosztownych systemach / mediach. 3.2.3 Migracja zast˛epujaca ˛ 3.2.3.1 Wprowadzenie Biorac ˛ pod uwag˛e kwesti˛e zarzadzania ˛ plikami, w niniejszym poradniku wyszliśmy z założenia, że centralne miejsce składowania plików znajduje si˛e przynajmniej na jednym serwerze NT i że obecnie dost˛ep do plików maja˛ klienty windowsowe. Podczas poszukiwań odmiennych dróg dla ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 69 przeprowadzenia migracji na produkty inne niż firmy Microsoft, trzeba rozróżnić dwa scenariusze owej migracji. Pierwsza opcja dotyczyłaby tylko rozwiazań ˛ stosowanych po stronie serwera, druga natomiast przypadku, w którym inna˛ platform˛e wprowadza si˛e również na stacje robocze. W przypadku migracji na serwerach trzeba, z uwagi na sposób zarzadzania ˛ plikami, wyróżnić dwie podstawowe płaszczyzny. Z jednej strony każdy 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 kolejności przej˛ecia istniejacych ˛ w starym systemie danych i programów przez nowy system. Wiaże ˛ si˛e z tym także odwzorowanie systemu uprawnień do autoryzacji dost˛epu do plików i katalogów oraz dostosowanie pracy systemu, np. sposobu zabezpieczania danych. W drugiej kolejności chodzi o odtworzenie dotychczasowej funkcjonalności, badź ˛ to z wykorzystaniem istniejacych ˛ stacji klienckich, badź ˛ też przez stworzenie nowej architektury klientów. Ten drugi etap tworzy właściwy rdzeń infrastruktury składowania plików. W centrum oceny znajduja˛ si˛e w szczególności takie zagadnienia, jak „prawa dost˛epu do poziomu plików i katalogów“ oraz „podstawowe funkcje składowania plików“. Jeśli chodzi o zastapienie ˛ serwera NT 4.0 w obszarze zarzadzania ˛ plikami, pod uwag˛e należy wziać ˛ przede wszystkim nast˛epujace ˛ 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 udost˛epniony przez IBM, z autoryzacja˛ Kerberos Alternatywne sieciowe systemy zarzadzania ˛ plikami, które nie wykroczyły poza stadium uniwersyteckich prac badawczych albo opieraja˛ si˛e w całości badź ˛ cz˛eściowo na oprogramowaniu własnościowym, 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 należy także uwzgl˛ednić właściwości 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 F UNKCJA 70 W IN NT W IN 2 K S AMBA NFS AFS X X X 256 256 256 256 256 Unicode Unicode Unicode ISO-Latin ISO-Latin X X X X X X X X X klient windowsowy bez dodatkowego oprogramowania długość nazwy pliku (znaki) zestaw znaków dla nazwy pliku wyświetlanie wielkich i małych liter rozróżnianie wielkich i małych liter kwoty dyskowe X X szyfrowanie EFS file-wise po stronie klienta kompresja X X 1 2 maksymalna wielkość3 2 TB 2TB 2 TB 9EB4 2GB dowolna dowolna dowolna dowolna dowolna DFS DFS standard standard FRS rsync rsync rsync X X X X przez system przez system przez system plików plików plików pliku maksymalna długość ścieżki change journal X propagacja zezwoleń X w Active Directory rozłożony system plików replikacja plików journaling Dost˛epna jako łata, np. dla systemów plików ext2 i ext3 Dost˛epna jako łata, np. dla systemów plików ext2 i ext3 3 TB - terabajt 1012, PB - petabajt 1015 EB - exabajt 1018 4 NFSv3 x systemem plików XFS 1 2 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 71 DACL NTFS POSIX SACL NTFS moduł Samby typowa autoryzacja NT / LM AD / NT / LM LDAP, przez . . . PDC Kerberos gdy członek AD, POSIX AFS NIS / LDAP Kerberos wersja 4 to Kerberos Tablica 3.6: Porównanie serwerów plików W przypadku bezpośredniego zastapienia ˛ serwera Windows NT jako serwera plików, przy zachowaniu klientów windowsowych, pierwszy wybór w obszarze oprogramowania Open Source powinien paść na Samb˛e. Klient windowsowy odbiera Samb˛e dokładnie tak, jak gdyby był to serwer NT. Samba jest stale rozwijana, nie tylko przez społeczność Open Source, lecz także przez coraz wi˛eksza˛ ilość producentów IT. W zależności od zakresu migracji na Linuksa po stronie klienta, w stron˛e centrum ocen alternatywnych rozwiazań ˛ przesuwaja˛ si˛e serwery NFS i AFS. Sa˛ one rozpowszechnione w sieciach uniksowych, jednak by umożliwić ich integracj˛e z windowsowymi stacjami roboczymi konieczne jest zainstalowanie po stronie klientów specjalnego oprogramowania. Klient NFS dost˛epny jest mi˛edzy innymi w Microsoft Windows Services for UNIX (SFU 3.0), natomiast klient AFS jest nieodpłatny i dost˛epny jako oprogramowanie Open Source na stronie http://OpenAFS.org OpenAFS.org. Jednakże, by móc zastosować klienty NFS albo AFS w środowisku windowsowych stacji roboczych, trzeba wprowadzić daleko idace, ˛ koncepcyjne zmiany, w porównaniu z sytuacja,˛ gdy zarzadzanie ˛ plikami odbywa si˛e z wykorzystaniem Windows NT. Jeśli podczas modernizacji infrastruktury informatycznej tworzonej w ramach projektu migracyjnego ważna˛ rol˛e odgrywa metoda zapewnienia bezpieczeństwa za pomoca˛ Kerberos, która leży także u podstaw Active Directory w Windows 2000, wówczas w przypadku kontynuacyjnego korzystania z produktów Windows po stronie klientów, należy zmierzać w kierunku zastosowania OpenAFS jako alternatywy dla Windows 2000 jako serwera plików. 3.2.3.3 Samba Realizacj˛e zasadniczo różnych opcji, tj. centralnego składowania plików dla klientów windowsowych lub dla heterogenicznego środowiska klientów, można oceniać równorz˛ednie. Nie ma powodu, by wykluczyć jedno badź ˛ drugie rozwiazanie. ˛ Jeśli chodzi o sposób stosowania i administrowania, to wszystkie opcje zwiazane ˛ sa,˛ w wi˛ekszym 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łożenie polegajace ˛ na najdalej idacym ˛ zachowaniu istniejacych ˛ rozwiazań. ˛ W takich obszarach jak składowanie plików, drukowanie i autoryzacja Samba jest z wielu powodów wzorowana na Windows NT. Z punktu widzenia użytkowników Samba odpowiada w najwi˛ekszym przybliżeniu serwerowi NT. Z drugiej strony administratorzy widza˛ w niej serwer uniksowy. Obsług˛e Samby należy dostosować do filozofii oraz możliwości nowego systemu operacyjnego. W2K, jako nast˛epca NT niesie z soba,˛ z punktu widzenia użytkownika, niemal tyle samo zmian w porównaniu z serwerem NT, co Samba. Jednakże dla administratorów zmiany te sa˛ już wi˛eksze 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ź ˛ innym kierunku moga˛ być uznane za uproszczenie czy też zalet˛e, zależy ostatecznie od zainteresowanych osób. Migracja na Samb˛e, Linuksa i Open Source otwiera nowe możliwości działania. Oprócz wi˛ekszej swobody oraz odpowiedzialności za swoje decyzje, administrator „zyskuje“, wraz z wykonaniem kroku w kierunku wyzwolenia si˛e od narzuconych schematów i Best Practices jednego producenta, także nowe możliwości popełniania bł˛edów. Serwer Samba spełnia, podobnie jak serwer NT, wymagania zwiazane ˛ z administrowaniem plikami. Użytkownicy klientów windowsowych moga˛ równie dobrze ściagać ˛ swoje profile oraz skrypty logowania z serwera Samba, jak swoje katalogi domowe lub katalogi grup. Na serwerze Samba można również składować pliki wykonywalne (*.exe) (i je stamtad ˛ uruchamiać), takie jak pliki bazy danych Access albo inne pliki z mechanizmami blokujacymi ˛ udost˛epniane jednocześnie wielu użytkownikom. W odróżnieniu 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 umożliwiaja˛ prac˛e na wspólnych danych w środowisku heterogenicznym. Samba nie oferuje implementacji SMB opartej na protokole NetBEUI, ani też nie obsługuje NetBIOS przez IPX. Po stronie klienta nadal można używać narz˛edzi służacych ˛ do edycji plików znajdujacych ˛ si˛e na serwerze plików i do zarzadzania ˛ nimi. W szczególności można w tym celu korzystać z programów Explorer i File Manager oraz z cacls, xcacls etc. Poczawszy ˛ od Samby 3.0 można także nadal używać menedżera użytkowników. W zasadzie możliwe jest też zastosowanie menedżera plików, jednak z powodu zwiazanego ˛ z tym odwrotu od przejrzystości konfiguracji serwera ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 73 (smb.conf) jest to niezbyt dobre rozwiazanie. ˛ Zestawianie połaczeń ˛ do zasobów nadal, tj. bez wprowadzania zmian, możliwe jest za pomoca˛ skryptów logowania albo przez surfowanie w otoczeniu sieciowym. System uprawnień Samby i Linuksa umożliwia zagwarantowanie uprzywilejowanym procesom, takim jak na przykład, skanerowi antywirusowemu na serwerze, lokalnego dost˛epu do wszystkich plików w rodzimych katalogach użytkowników i jednocześnie na zezwolenie na taki dost˛ep wyłacznie ˛ samemu użytkownikowi poprzez nap˛ed sieciowy. Serwer Samba nadaje si˛e także do zarzadzania ˛ plikami i autoryzacji w środowiskach z windowsowymi serwerami terminali, z tym że w takim przypadku nie b˛edzie on obsługiwał specyficznych dla nich rozszerzeń obiektowych SAM. Obsługa blokad plików (locking zarówno na poziomie pliku, jak też w Byte-Range) realizowana jest przez Samb˛e dokładnie tak, jak przez serwer NT. Oznacza to, że za pomoca˛ Samby możliwe 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 też innych zasobów systemowych) i przenosi t˛e funkcj˛e także na zasoby zarzadzane ˛ przez serwer Samba. W Linuksie, dla potrzeb zabezpieczania danych i dokumentowania wersji / archiwizacji, skorzystać można z wielu różnych narzadzi ˛ Open Source. Dodatkowo serwery linuksowe można bez problemu zintegrować z rozwiazaniami ˛ bezpieczeństwa oferowanymi przez wi˛ekszość dost˛epnego na rynku oprogramowania. Wysoka˛ niezawodność, jaka˛ osiagni˛ ˛ eto w NT wraz z wydaniem Enterprise Edition dzi˛eki zastosowaniu klastrów, można uzyskać także w Sambie w oparciu o shared SCSI albo SAN z IP Failover. Jeśli porówna si˛e niektóre analizy możliwości5 wykonane w ostatnich latach, można stwierdzić, że nastapiło ˛ znaczne zmniejszenie ograniczeń funkcjonalności w zastosowaniach Samby. W przyszłości Samba 3.06 umożliwi budowanie zaufanych połaczeń ˛ pomi˛edzy domenami Master i Resource, czyli implementacj˛e rozwiazań ˛ z zakresu obsługi domen stosowanych w Windows NT. Wraz z wersja˛ 3.0 powstanie także możliwość, wykorzystania menedżera użytkowników do zarzadzania ˛ użytkownikami, np. w ten sposób b˛edzie można zakładać konta nowym użytkownikom. Nadal nie b˛edzie możliwości replikacji pomi˛edzy kontrolerem domeny Windows i kontrolerem domeny Samby, czyli wewnatrz ˛ jednej domeny b˛edzie można używać samego kontrolera domeny Windows badź ˛ wyłacznie ˛ kontrolera domeny Samby. W przypadku, gdy wymagana b˛edzie integracja usług świadczonych przez serwer windowsowy z domena˛ Samby, b˛edzie 5 6 Zwłaszcza analiz˛e wykonana˛ dla BMI w 2001 r. Obecnie dost˛epna jest wersja beta - jednak została już ona wdrożona i działa w Federalnym Urz˛edzie ds. Karteli ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 74 można ja˛ uzyskać po zintegrowaniu tych usług jako Member Servers. Replikacja SAM w czystym środowisku kontrolera domeny Samby możliwa jest przez kombinacj˛e Samby i OpenLDAP. OpenLDAP służy Sambie do administrowania grupami oraz użytkownikami i oferuje wymagane mechanizmy replikacji. NTFS XFS EXT3 R EISER FS długość nazwy pliku 256 256 256 256 zestaw znaków Unicode ISO-Latin ISO-Latin ISO-Latin X X X X X X X dla nazwy pliku wyświetlanie wielkich i małych liter rozróżnianie wielkich i małych liter kwoty dyskowe X X X X7 szyfrowanie EFS X8 X9 X10 kompresja X X11 X12 X13 maksymalna wielkość pliku 2 tera 16/64 tera15 4 tera14 16/64 tera16 maksymalna długość ścieżki dowolna dowolna dowolna dowolna X X change journal journaling 7 X X X W niektórych wersjach niepewne. Da si˛e zrealizować dla całych systemów plików lub cz˛eściowych drzew za pomoca˛ narz˛edzi dost˛epnych w systemie (crypto-api/loopback i cfs/rpc). 9 Patrz szyfrowanie w XFS. 10 Patrz szyfrowanie w XFS. 11 Za pomoca˛ loopback możliwa jest kompresja na poziomie systemu plików. 12 W w˛eźle systemu plików ext2/ext3 przewidziany jest atrybut kompresji. Do jadra ˛ 2.2 dost˛epne były łaty dla projektu e2compr, które bazujac ˛ na w.w atrybucie pozwalały na kompresj˛e plików za pomoca˛ różnych algorytmów. Od jadra ˛ 2.4 projekt ten nie jest rozwijany, ponieważ nie ma już faktycznego zapotrzebowania na kompresj˛e. Za pomoca˛ loopback możliwa jest kompresja na poziomie systemu plików. 13 Patrz kompresja w XFS. 14 W zależności od architektury - 32 czy 64 bitowa; w kernelu 2.4 ograniczona do 2 tera przez maksymalna˛ wielkość systemu plików. 15 W zależności od architektury - 32 czy 64 bitowa; teoretyczne maksimum wynosi 9 exabajt; w kernelu 2.4 ograniczona do 2 tera przez maksymalna˛ wielkość systemu plików. 16 W zależności od architektury - 32 czy 64 bitowa; teoretyczne maksimum wynosi 1 exabajt; w kernelu 2.4 ograniczona do 2 tera przez maksymalna˛ wielkość systemu plików. 8 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI ACL DACLs 75 POSIX POSIX ACLs przez ACLs przez rozszerzone rozszerzone atrybuty atrybuty od kolejnej wersji kernela kontrolowanie SACLs X 17 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 wyszliśmy z założenia, że na klientach nie b˛eda˛ zapisywane dane użytkowe. W przypadku ewentualnej migracji należy postawić nowy system o identycznej funkcjonalności, lecz bez przenoszenia danych znajdujacych ˛ si˛e na starych klientach. Jeśli istnieje duża ilość identycznie wyposażonych klientów, na których trzeba wykonać migracj˛e, należy rozważyć prac˛e 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ólności jeśli chodzi o administrowanie. Zmiany w konfiguracji klientów wykonuje si˛e wówczas tylko raz, na serwerze, po czym automatycznie działaja˛ one na wszystkich współpracujacych ˛ z nim klientach. W celu wyboru serwera do pracy z „diskless client“, trzeba przyjać ˛ takie same założenia, jak w przypadku wyboru serwera (server system) dla centralnego składowania plików w ogóle. Nadawanie praw dost˛epu: odwzorowanie profilów uprawnień Windows na POSIX ACL Kierowanie prawami dost˛epu do katalogów i plików za pomoca˛ serwera Samba odpowiada w dużym stopniu założeniom znanym z NT. Także w Sambie udost˛epnia si˛e w sieci pojedyncze katalogi z systemu plików serwera jako zasoby (shares). Szczegóły nadawania praw dost˛epu 17 Kontrolowanie w Linuksie zostało wielokrotnie rozwini˛ete. Wcześniejszym projektem kontroli przestano zajmować si˛e od poczatku ˛ 2000 r. Projekt grsecurity implementuje oparty na procesach system ACL w kernelu (http://www.grsecurity.net/). Z jego pomoca˛ możliwe jest całkowite kontrolowanie plików i innych aktywności systemu. 18 Patrz kontrolowanie w XFS. 19 Patrz kontrolowanie w XFS. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 76 ustalane sa˛ na podstawie uprawnień określonych w systemie plików używanym po stronie serwera dla każdego indywidualnie autoryzowanego przez Samb˛e użytkownika. Zasoby (shares) i ich właściwości wynikajace ˛ z usytuowania po stronie serwera, takie jak ścieżka do katalogów, gwarancja anonimowego dost˛epu i ogólna ochrona przed zapisem, sa˛ w Sambie ustawiane i dokumentowane w jednym pliku konfiguracyjnym, jednoznacznym dla każdej instancji serwera. Edycja w/w pliku konfiguracyjnego może również odbywać si˛e (po odpowiedniej weryfikacji / autoryzacji za pomoca˛ szyfrowanego protokołu HTTPS) poprzez webfrontend. Prawa dost˛epu 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łaścicieli plików w DOS i starszych wersjach Windows, w Uniksie rozróżnia si˛e właścicieli i grupy użytkowników plików od dawna, a w Windows wraz z pojawieniem si˛e systemu plików NT (NTFS). Access Contrlo Lists (listy kontroli dost˛epu) reguluja˛ dost˛ep danych użytkowników do wybranych katalogów i plików. W Uniksie możliwe jest zdefiniowanie, dla wszystkich plików, przynajmniej nast˛epujacych ˛ uprawnień: prawo do odczytu, zapisu i wykonywania przez właściciela, grup˛e właścicieli i wszystkich pozostałych użytkowników sytemu. W przypadku niektórych linuksowych / uniksowych systemów plików można narzucić dodatkowe ograniczenia albo zagwarantować dodatkowe uprawnienia innym użytkownikom, grupom użytkownikó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 umożliwia dost˛ep do danych dzi˛eki efektywnym prawom dost˛epu, którym podlega weryfikowany za każdym razem użytkownik. Serwer Samba może teoretycznie nakładać dodatkowe ograniczenia dost˛epu wykorzystujac ˛ ograniczenia określone w systemie plików, jednak w żadnym razie nie może ich zlekceważyć. Zarówno w przypadku przenoszenia istniejacych ˛ praw dost˛epu z serwera na klienta, jak też przy ujawnieniu si˛e zmian zainicjowanych po stronie klienta, serwer Samba stosuje kanon uprawnień systemu plików, w którym składuje on dane użytkowników i nimi administruje. Dlatego w świecie Uniksa podczas migracji należy odwzorować model uprawnień z Windows. W dalszych rozdziałach opisaliśmy, w jaki sposób można wykonać takie odwzorowanie oraz jakie szczegóły i ograniczenia trzeba przy tym wziać ˛ pod uwaga.˛ Autorzy poradnika wyszli z założenia, że system plików w Linuksie obsługuje POSIX-ACL. Obecnie w gr˛e wchodza˛ nast˛epujace ˛ systemy plików: XFS, JFS oraz, po nałożeniu ł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 uprawnień zredukowany zostaje w takim stopniu, że 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óżnia uprawnień takich jak: zapisywanie danych, przyłaczanie ˛ danych, zapisywanie atrybutów oraz rozszerzonych atrybutów. Dlatego podczas przenoszenia systemu uprawnień Windows za pomoca˛ Samby do Uniksa, w uniksowym systemie plików można odwzorować tylko kompletne grupy uprawnień Windows. Tak samo dzieje si˛e w odwrotnym kierunku, gdy serwer Samba może zgłaszać klientowi windowsowemu również tylko grupy uprawnień. U PRAWNIENIA POSIX Odczyt Zapis Wykonywanie przeszukiwanie katalogu / wykonywanie pliku wylistowanie katalogów / czytanie danych X czytanie atrybutów X I czytanie rozszerzonych X N atrybutów D tworzenie plików / O zapisywanie danych W tworzenie katalogów / S przyłaczanie ˛ danych W (X)20 X X przypisywanie atrybutów X przypisywanie rozszerzonych atrybutów X usuwanie podkatalogów / plików usuwanie czytanie uprawnień X zmiana uprawnień 20 Jest wyświetlany, ale nie wolno go ustawiać, w przeciwnym razie aktywowana zostanie cała grupa „odczyt“. X X ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 78 przejmowanie uprawnień właściciela Tablica 3.10: Uprawnienia POSIX oraz grupy uprawnień Windows Po stronie użytkownika można tworzyć w windowsowych oknach dialogowych, wykorzystujac ˛ kombinacje pasujacych ˛ uprawnień NTFS, odpowiednie kombinacje uprawnień POSIX. Należy przy tym pami˛etać, aby wstawianie dodatkowego uprawnienia NTFS z listy windowsowej, spowodowało ustawienie wszystkich uprawnień w grupie POSIX, do której należy nadawane w ten sposób uprawnienie. Jeśli, na przykład, dla jakiegoś pliku, który dotychczas udost˛epniony był tylko do odczytu, w oknie dialogowym Privilege entry ustawiona zostania opcja Write attributes, wówczas serwer Samby automatycznie doda uprawnienia dla przypisywania rozszerzonych atrybutów oraz zapisywania i przyłaczania ˛ danych. Jeśli w tym momencie klikniemy OK, wtedy podczas nast˛epnego otwarcia okna dialogowego natychmiast pojawi si˛e w nim nowy, znacznie rozszerzony zestaw uprawnień. Zaleta˛ takiego rozwiazania ˛ jest to, że opisane powyżej zachowanie serwera Samba nie dopuszcza do bł˛ednych interpretacji uprawnień pokazywanych w prostej prezentacji. W uproszczonej prezentacji ustawień bezpieczeństwa obraz jest spójny. Można tu nadawać pojedyncze oraz wspólne prawa do odczytu i zapisu, jak również każdorazowo w kombinacji z odczyt / wykonywanie. Tego ostatniego, zbiorowego uprawnienia, nie można nadawać pojedynczo. Uprawnień NTFS, takich jak: usuwanie podkatalogów / plików, usuwanie, zmiana uprawnień oraz przejmowanie uprawnień właściciela nie da si˛e odwzorować w POSIX ACLs i jeśli zostana˛ nadane, wówczas serwer Samba nie zwróci żadnego rezultatu (w tabeli zaznaczone na żółto). W przypadku ustawienia pełnego dost˛epu, czyli nadania wszystkich praw: do odczytu, zapisu i wykonywania, także one zostały zaznaczone jako uprawnienia nadane. U PRAWNIENIA POSIX Odczyt W pełny dost˛ep Zapis Odczyt Odczyt Odczyt, i wykonywanie i zapis zapis i wykonywanie X ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 79 I zmienianie N odczyt / wykonywanie X X D wylistowanie X X O zawartości katalogu (tylko dla (tylko dla W (tylko dla katalogów) katalogów) katalogów) S odczyt X X zapis X X X X Tablica 3.12: Uprawnienia POSIX i Windows Odwzorowanie funkcji dziedziczenia Implementacja POSIX-ACL obsługuje zaledwie dziedziczenie pasywne. Niemożliwe jest odwzorowanie aktywnego dziedziczenia, takiego jak w NTFS. Odwzorowanie systemu atrybutów Atrybuty, których nie ma w Uniksie można odwzorowywać na różne sposoby. Tak naprawd˛e nie trzeba tu ustawiać flagi tylko do odczytu, ponieważ istnieje już ona w tradycyjnym systemie uprawnień i jest automatycznie wyświetlana dla plików i katalogów składowanych bez prawa do zapisu. Flagi archiwalny, ukryty i systemowy można odwzorować za pomoca˛ nieużywanego przez uniksowy system plików bitu execute. Dlatego można o nich powiedzieć, że istnieja.˛ Atrybuty spakowany i zaszyfrowany nie dadza˛ si˛e odwzorować, jednakże można skorzystać z nich w Uniksie dzi˛eki specjalnym usługom. Odwzorowanie funkcji kontrolnych System kontroli jest silnie zintegrowany z Windows. W Uniksie można go uzyskać za pomoca˛ innych mechanizmów. W przypadku serwera Samba jest on realizowany poprzez moduł VFS. W ten sposób na serwerze Samba uzyskuje si˛e protokółowanie dost˛epu do plików i katalogów. Dotychczas funkcja kontrolna, realizowana na poziomie plików w takiej formie, nie została umieszczona w jadrze ˛ Linuksa, mimo że podj˛etych zostało wiele prób implementacji i że w linuksowych systemach plików spełnione sa˛ odpowiednie wymagania dotyczace ˛ rozszerzonych atrybutów. W praktyce możliwość ta ma jednak na tyle małe znaczenie, że wszystkie podejmowane próby kończyły si˛e wskutek braku zainteresowania nimi. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 80 Podsumowanie najważniejszych skutków zastosowania serwera Samba z POSIX ACLs Jeśli chodzi o zapis, jako prawo abstrakcyjne, to: ◦ nie ma różnicy pomi˛edzy prawem do zapisu, a prawem do przyłaczania ˛ danych ◦ w przypadku katalogów również nie ma różnicy pomi˛edzy prawem do tworzenia katalogów, a prawem do tworzenia plików ◦ nie ma różnicy pomi˛edzy prawem do zapisywania katalogów badź ˛ plików, a prawem do zapisywania atrybutów Jeśli chodzi o odczyt, jako prawo abstrakcyjne, to: ◦ nie ma różnicy pomi˛edzy prawem do odczytu katalogów badź ˛ plików a prawem do odczytu atrybutów Zasadniczo należy przyjać, ˛ że odczyt jest dozwolony zawsze. Generalnie nie sa˛ zaimplementowane mechanizmy kontroli ani dziedziczenia. Grupy użytkowników i prawa dost˛epu Nadawanie praw dost˛epu grupom odgrywa istotna˛ rol˛e w szczególności w przypadku zasobów wspólnie używanych przez grupy robocze. W NT rozróżnić należy grupy lokalne (serwera) i globalne. Lokalne grupy można rozumieć jako zdefiniowane aliasy, które wskazuja˛ na jedna˛ lub wi˛ecej grup globalnych. W ten sposób grupy lokalne moga˛ zawierać wiele grup globalnych. W Sambie (i ogólnie w środowisku UNIX/Linux) nie jest możliwe zagnieżdżanie grup. Za pomoca˛ Samby można tylko przedstawić klientom windowsowym oraz Member Servers wszystkie uniksowe grupy w skali 1 : 1 jako grupy globalne. Oczywiście w/w globalne grupy moga˛ na windowsowych Member Servers ponownie wejść do grup lokalnych. Tym samym w dalszym ciagu ˛ na tego typu serwerach można korzystać 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 si˛e wprowadzenia rozwiazania ˛ opartego na grupach lokalnych, dlatego swoje typowe zastosowanie znajdzie tutaj model B-G-R. Adekwatna˛ funkcjonalność można uzyskać za pomoca˛ odpowiedniego business-logic opierajac ˛ zarzadzanie ˛ grupami na LDAP. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 81 Ocena skutków dla użytkowników Przy odwzorowywaniu Windows-ACL na POSIX-ACL traci si˛e stopień dokładności, w jakim można modyfikować uprawnienia w Windows. Jednak w praktyce, w znakomitej wi˛ekszości zastosowań, wykorzystuje si˛e tylko o wiele prostszy zestaw uprawnień oferowany przez Security settings. Inne, dalej idace ˛ uprawnienia, stosowane sa˛ jedynie w pojedynczych przypadkach. Szczególnie rzadko wykorzystywane jest rozróżnianie pomi˛edzy uprawnieniami atrybutów i plików. Także korzystanie z przyłaczania ˛ danych ma sens zaledwie w niektórych przypadkach. Uprawnienie to można nadawać również z linii poleceń, jako rozszerzony atrybut dla wybranych plików w Linuksie, podczas pracy w systemach plików ext2 i ext3. Dzi˛eki ścisłemu odwzorowaniu nieskomplikowanego modelu uprawnień z POSIX ACL, obraz prostych Security settings staje si˛e bardziej przejrzysty dla przeci˛etnego użytkownika. Określonych funkcji, takich jak dziedziczenie i kontrola nie da si˛e odwzorować. 3.2.4 Migracja kontynuacyjna 3.2.4.1 Windows 2000 W niniejszym rozdziale przedstawiamy, pod katem ˛ oferowanych „File Services“, nast˛epc˛e Windows 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 poniżej: ◦ system plików NTFS5 ◦ HSM-API ◦ dziedziczenie ◦ szyfrowanie (EFS) ◦ SMB over Native IP ◦ dynamiczne administrowanie nośnikami danych ◦ defragmentacja ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 82 ◦ zagnieżdżanie grup ◦ Remote Storage ◦ Indexing Service ◦ Distributed Link Tracking ◦ DFS ◦ Offline Folder ◦ Folder Redirection W kolejnych paragrafach znaleźć można szerszy opis wprowadzonych zmian. System plików NTFS5 System plików NTFS5 oferuje łacznie ˛ nast˛epujace ˛ ulepszenia: Przede wszystkim możliwe jest administrowanie prawami dost˛epu za pomoca˛ funkcji dziedziczenia. Oznacza to, że uprawnienia nadane katalogom nadrz˛ednym działaja˛ także w katalogach i plikach podrz˛ednych bez konieczności ich przepisywania (Burn-In). Tym samym pozbyto si˛e wad zwiazanych ˛ z przepisywaniem (problem obciażenia, ˛ usuwania specyficznych uprawnień w katalogach podporzadkowanych). ˛ NTFS5 oferuje change journal, w którym protokółowane sa˛ zmiany. Nośniki danych sformatowane dla NTFS5 dysponuja˛ ukrytym katalogiem o nazwie „System Volume Information“, do którego ma dost˛ep wyłacznie ˛ system operacyjny i w którym odbywa si˛e administrowanie dodatkowymi funkcjami. NTFS5 oferuje tak zwany HSM-API (interfejs programowania Hierarchical Storage Management), z którego moga˛ korzystać produkty innych producentów. NTFS5 oferuje możliwość szyfrowania danych. Encrypting File System (EFS) umożliwia użytkownikom chronienie danych przed odczytem ich zawartości 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 wcześniejszych wersjach tego systemu operacyjnego, różne protokoły. Nowościa˛ w Windows 2000 jest możliwość wyłaczenia ˛ komunikacji przez NetBIOS. Dla File Services oznacza to, że podczas komunikacji, tzw. „Direct Hosting of SMB Over TCP / IP“ odbywa si˛e przez port 445. Administracja nośnikami danych Windows 2000 oferuje możliwość, właczenia ˛ fizycznych twardych dysków do systemu, bez konieczności przydzielania nap˛edom liter. Tego typu dynamiczne nośniki danych moga˛ być wła˛ czane do tradycyjnych nośników danych jako katalogi i udost˛epniane. Windows 2000 po raz pierwszy dostarcza narz˛edzie do defragmentacji nośników danych. Zmiany odnośnie nadawania praw dost˛epu W Windows 2000 Active Directory istnieje znacznie wi˛ecej możliwości kontrolowania uprawnień, gdyż można mocniej zagnieżdżać wi˛ecej typów grup. Zagnieżdżanie grup możliwe jest tylko wtedy, gdy Active Directory używany jest w „Native Mode“. W tym trybie pracy dost˛epne sa˛ dwa nowe typy grup „Domain Local“ oraz „Universal“. Poniższa tabela pokazuje możliwości zagnieżdżania. T YP GRUPY MO ŻE MIE Ć NAST EPUJ ˛ ACYCH ˛ MO ŻE BY Ć CZŁONKIEM . . . CZŁONKÓW . . . grupa globalna użytkownik i globalne grupy tej samej domeny globalne grupy tej samej domeny; grupy uniwersalne oraz lokalne grupy domen lokalna grupa użytkownik, uniwersalna lokalne grupy domen tej samej domen i globalna grupa każdej domeny domeny grupy użytkownik, globalne lokalne grupy domeny albo uniwersalne i uniwersalne grupy każdej domeny uniwersalne grupy każdej domeny Tablica 3.14: Typy grup ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 84 Oprócz w/w nowych typów grup, w środowiskach wykorzystujacych ˛ Active Directory i Exchange 2000 należy wyróżnić grupy bezpieczeństwa oraz grupy dystrybucji. W przypadku grup dystrybucji istnieja˛ środowiska Exchange, jednak nie da si˛e w nich kontrolować File Services . Remote Storage Remote Storage jest nowa˛ usługa˛ dostarczana˛ przez Windows 2000. Umożliwia ona składowanie długo nieużywanych plików na nap˛edach taśmowych w ramach tzw. HSM (Hierarchical Storage Management). Indeksowanie Indeksowanie można opcjonalnie właczyć ˛ dla folderów plików w celu założenia indeksu zapisanych danych. Umożliwia on szybsze przeszukiwanie określonej zawartości. Indeksowanie można stosować dla dokumentów: ◦ HTML ◦ tekstowych ◦ Microsoft Office 95 lub wyżej ◦ Internet Mail oraz News ◦ wszystkich innych dokumentów, dla których dost˛epne sa˛ filtry dokumentów. Distributed Links Tracking Serwery plików Windows 2000 umożliwiaja˛ takie zaprogramowanie aplikacji obsługujacych ˛ linkowanie i osadzanie obiektów, że podczas przeciagania ˛ zlinkowanych obiektów możliwe jest uzyskiwanie z systemu plików informacji na temat ich aktualnego położenia w systemie, przy jednoczesnym zachowaniu bezbł˛ednej pracy. Distributed File System Distributed File System (DFS) udost˛epniany był już 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 umożliwia to, że zasoby udost˛epniane z katalogów ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 85 znajdujacych ˛ si˛e na różnych serwerach, moga˛ być przedstawiane klientowi w postaci podkatalogów pojedynczego zasobu. Dzi˛eki temu oszcz˛edza si˛e litery alfabetu opisujace ˛ nap˛edy, które maja˛ być przyporzadkowane ˛ danemu użytkownikowi. W Windows 2000 DFS został na tyle rozszerzony o integracj˛e z FRS (File Replication Service), że zlinkowane zasoby i ich zawartość moga˛ być replikowane do dalszych zasobów i innych serwerów plików. Jeśli serwer przestanie pracować i przestanie tym samym udost˛epniać zasoby, wówczas klient b˛edzie mógł korzystać z replik, bez potrzeby tworzenia nowych połaczeń ˛ sieciowych. W Windows 2000 informacje moga˛ być zapisywane i raplikowane w Active Directory za pomoca˛ drzewa DFS. Dzi˛eki temu klient dysponuje niemal przez cały czas potrzebnymi informacjami o połaczeniach. ˛ Zestawianie połaczenia ˛ Użytkownikowi można ułatwić poszukiwanie zasobów przez opublikowanie ich w Active Directory. Offline Folder i Folder Redirection Funkcje „Offline Folder“ i „Folder Redirection“ nie sa˛ zasadniczo właściwościami File Services z Windows 2000, lecz funkcjami klienta (np. Windows 2000 / Professional). Wspomnieliśmy o nich w tym miejscu, ponieważ maja˛ one duże znaczenie, jeśli chodzi o przechowywanie danych i dlatego, że funkcje te musza˛ współpracować z serwerem plików. Offline Folder sa˛ jakby nast˛epcami „Aktówki“ z wcześniejszych wersji Windows. Użytkownicy korzystajacy, ˛ np. z notebooka, moga˛ edytować 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 ważne sa˛ właściwości plików po obu stronach (klient i serwer). Zastosowanie w Windows 2000 funkcji Folder Redirection wynika z możliwości znacznego przyrostu wielkości profilów użytkownika na stacjach roboczych podczas pracy. Dzieje si˛e tak, np. wtedy, gdy użytkownik zapisuje swoje pliki w „Own files“, które właściwie powinny być składowane na serwerze plików. W Windows 2000 możliwe jest „ukierunkowanie“ profilu użytkownika („Own files“, „Application data“) na ścieżk˛e sieciowa˛ katalogów systemowych. Katalogi te b˛eda˛ dla użytkownika dost˛epne w przeźroczysty sposób, jako katalogi lokalne. Poprzez przeciaganie ˛ katalogu do serwera plików należy zwrócić uwag˛e na to, aby zachowane zostały prawa dost˛epu. Zabezpieczanie danych Narz˛edzie NTBACKUP dostarczane wraz z Windows zostało zmodyfikowane w taki spo- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 86 sób, że obecnie można wykonywać kopie bezpieczeństwa nap˛edów (lokalnych lub sieciowych). Dzi˛eki temu łatwiej da si˛e uniknać ˛ stosowania lokalnych nap˛edów taśmowych. Kolejne wersje systemu Z punktu pojawiania si˛e nowych wersji należy wyróżnić nast˛epujace ˛ 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 firma Microsoft po raz pierwszy udost˛epniła system operacyjny, który może współpracować wyłacznie ˛ ze specjalnym osprz˛etem i z niewielka˛ grupa˛ producentów. Platforma ta zakłada bardzo szczególna˛ dost˛epność i / lub scenariusze obciażenia ˛ (pojemności). W niniejszym poradniku nie b˛edzie ona omawiana. Network Attached Storage (NAS) Niektórzy producenci osprz˛etu wymyślili, we współpracy z firma˛ Microsoft, tak zwane systemy NAS oparte o Windows 2000. Systemy te sa˛ dedykowane dla File Services i maja˛ zoptymalizowane I/O. Praktyczne uwagi Poniżej znaleźć można kilka uwag odnośnie przedstawionych wcześniej nowości technicznych: ◦ Upowszechnienie EFS z reguły ogranicza si˛e do zastosowań dla komputerów przenośnych, na których wymagana jest ochrona danych przed uszkodzeniem oraz ochrona poufności danych. Celowość stosowania EFS jest cz˛esto podważana z uwagi na konieczność korzystania z PKI (także, gdy jest ona już oferowana przez Windows 2000 Active Directory), a z drugiej strony ze wzgl˛edu na brak obsługi mechanizmów dost˛epu 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 si˛e tego, co ma na celu zachowanie kompatybilności zwrotnej. ◦ Należy, w oparciu o nowy system plików, rozważyć stosowanie dotychczasowych narz˛edzi do zarzadzania ˛ plikami i prawami dost˛epu. Na przykład NT 4 Explorer nie może w sensowny sposób przedstawić dziedziczenia. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 87 ◦ W poszczególnym przypadku należy sprawdzić, pod katem ˛ dalszego korzystania z osprz˛etu, który był wcześniej wykorzystywany przez NT 4, czy konieczne jest wdrożenie Windows 2000. W wi˛ekszości przypadków trzeba si˛e liczyć z tym, że konieczne b˛edzie nabycie nowego osprz˛etu. 3.2.4.2 Windows 2003 Server W niniejszym rozdziale przedstawiamy, pod katem ˛ oferowanych „File Services“, nast˛epc˛e Windows 2000, tj. Windows 2003 Server (wcześniej „NET Server“). Poniżej znajduje si˛e krótki opis najważniejszych nowości, które zostały wprowadzone wraz z nowa˛ wersja: ˛ Windows 2003 Server b˛edzie pierwszym systemem operacyjnym firmy Microsoft obsługujacym ˛ także architektur˛e 64 bitowa. ˛ Oficjalna obsługa technologii SAN (Storage Area Networks) zostanie ulepszona do takiego stopnia, że możliwe b˛edzie bootowanie twardych dysków w SAN. EFS umożliwi także dost˛ep do jednego zasobu wi˛ekszej ilości użytkowników. Grupy w dalszym ciagu ˛ nie b˛eda˛ uwzgl˛edniane. Pojawi si˛e nowa funkcja Volume Shadow. Umożliwi ona postrzeganie struktury plików i katalogów w określonym czasie jako statycznej, dzi˛eki czemu możliwe b˛edzie, np. zabezpieczanie danych bez konieczności zwracania uwagi na otwarte pliki. Z drugiej strony pojawia˛ si˛e nast˛epujace ˛ możliwości: użytkownicy zyskaja˛ prawo odtwarzania z „migawki (snapshot)“ przypadkowo usuni˛etych 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 poniżej ocena szczegółów technicznych prowadzi do nast˛epujacych ˛ wniosków: W Linuksie standardowym serwerem wydruku we wszystkich wi˛ekszych dystrybucjach (SuSE, Debian, Red Hat, itd) jest CUPS. Jest to system pracujacy ˛ odpowiednio do potrzeb, zarówno w jednolitym środowisku Linuksowym, jak też w środowiskach heterogenicznych, w skład których wchodza˛ stacje klienckie oparte na Windows. Dla tych ostatnich pełnowartościowym systemem wydruku jest kombinacja CUPS i Samby. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 88 CUPS zapewnia ponad platformowa˛ obsług˛e zadań wydruku dzi˛eki zaimplementowanemu IPP (Internet Printing Protocol). CUPS obsługuje także wszystkie inne ważne protokoły wydruku takie jak LPR/LPD, Socket / AppSocket, SMB / CIFS oraz MS-RPC (w połaczeniu ˛ z Samba). ˛ Połaczenie ˛ CUPS / Samba umożliwia także automatyczna˛ instalacj˛e sterowników na klientach windowsowych. Ponadto CUPS oferuje różne możliwości zabezpieczania danych, także w czasie drukowania. Należa˛ do nich transmisja szyfrowana przez SSL z wykorzystaniem IPP i weryfikacji użytkowników za pomoca˛ LDAP, czy też w połaczeniu ˛ z Samba.˛ Ma to wiele zalet, również z uwagi na accounting dost˛epów do drukarki. Przed rozpocz˛eciem migracji powinniśmy w każdym przypadku sprawdzić, czy w/w serwer wydruku współpracuje z naszymi drukarkami. Dotyczy to w szczególności sytuacji, gdy wydruk ma być realizowany w całości po stronie serwera wydruku, ponieważ w niewielu pojedynczych przypadkach współpraca taka nie jest możliwa. Klienty Windows 2000 moga˛ drukować poprzez serwer CUPS, także w przypadku migracji kontynuacyjnej po stronie klientów, gdyż Windows 2000 obsługuje IPP. 3.3.2 Wprowadzenie Temat „drukowanie“ traktowany jest w świecie informatyki po macoszemu. Dotyczy to wszystkich środowisk i systemów operacyjnych, tzn. w równym stopniu świata Windows, jak i świata Uniksa / Linuksa. Problemy z wydrukiem sa˛ cz˛esta˛ przyczyna˛ poważnych strat powodowanych utrata˛ płynności pracy. Administratorzy poświ˛ecaja˛ dużo swojego czasu, aby codziennie usuwać problemy z drukowaniem. Z drugiej strony drukowanie jest w wielu przypadkach „missioncritical“, która w razie problemów może zwi˛ekszać koszty i przyprawiać o duży ból głowy osoby odpowiedzialne za sprawne działanie systemu. W infrastrukturze drukowania szeroko rozpowszechniły si˛e „dzikie“ rozwiazania. ˛ „Narosłe struktury“ doprowadziły w wielu miejscach do całkowitej niekompatybilności. Z tego powodu panuje duży bałagan, jeśli chodzi o j˛ezyki używane do opisu stron (PostScript, PCL, PreScribe, ESC/P, PDF. . . ). To, cz˛esto „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˛ platform˛e zachowywała istniejace ˛ proporcje w możliwie dokładnej skali 1 : 1, jednak w obszarze tym można wykorzystać szans˛e i usunać ˛ przy okazji wcześniejsze braki. Oprócz braków technicznych równie decydujac ˛ a˛ rol˛e odgrywa cena. Cz˛esto nie sa˛ znane ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 89 prawdziwe koszty drukowania w ramach organizacji (działu, zakładu, koncernu, urz˛edu). W tej dziedzinie istnieja˛ poważne potencjalne możliwości oszcz˛edzania, które uświadamiamy sobie dopiero wówczas, gdy zobaczymy jednoznaczne dane. Najważniejszymi kryteriami dla obliczania kosztów sa: ˛ ◦ ilość drukarek ◦ zużycie papieru ◦ ilość zużywanych tonerów / atramentu ◦ zużycie energii Przed rozpocz˛eciem migracji należy poznać odpowiedzi na nast˛epujace ˛ pytania: ◦ Ile jest drukarek w zakładzie pracy? ◦ Jak duże jest zużycie papieru? ◦ Jak duże jest zużycie tonerów / atramentu? Ile pieni˛edzy przeznaczanych jest na nie w ciagu ˛ roku? ◦ Jakie sa˛ przyczyny ponoszenia opłat serwisowych (za naprawy, konserwacj˛e)? ◦ Jak duży jest nakład pracy wewn˛etrznych służb technicznych? ◦ Ile wynosza˛ opłaty za energi˛e elektryczna˛ wykorzystywana˛ przez drukarki? ◦ Ile kosztuje wydrukowanie jednej strony? ◦ Jak rozkłada si˛e koszt drukowania na różnych typach drukarek? ◦ Czy można wydajniej wykorzystać dost˛epne zasoby? Rzeczywiste pieni˛eżne koszty można najcz˛eściej poznać dopiero po wykonaniu odpowiednich kalkulacji. Nakład pracy, który trzeba przy tym ponieść, cz˛esto si˛e opłaca. Dokładna analiza czynników generujacych ˛ koszty zwróci si˛e na pewno, ponieważ praktycznie zawsze istnieje możliwość oszcz˛edzania, która amortyzuje si˛e w ciagu ˛ roku. Migracja w obszarze środowiska drukowania jest ci˛eciem - w czasie jej przygotowywania należy wykonać odpowiednia˛ analiz˛e potrzeb, której wyniki należy uwzgl˛ednić w planach migracyjnych. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 90 3.3.3 Punkt wyjścia - drukowanie pod Windows NT 4 W niniejszym rozdziale przedstawiliśmy sytuacj˛e, która˛ uznaliśmy za punkt wyjścia w przypadku wi˛ekszości istniejacych ˛ środowisk windowsowych. Przyj˛eliśmy założenie, że istniejace ˛ środowisko oparte jest na jednym z powszechnie stosowanych modelu domen NT. Ponadto wyszliśmy z założenia, że środowiska te udost˛epniaja˛ Print Services oparte na Windows NT 4 Server. Oprócz tego założyliśmy, że serwery wydruku sa˛ członkiem domeny NT. Enterprise Edition umożliwia obsług˛e wydruku realizowana˛ przez dwa w˛ezły (serwery) w jednym klastrze. Ustanie pracy jednego z serwerów (jednego w˛ezła) kompensowane jest przej˛eciem jego zadań przez pozostały w˛ezeł. Klient „odczuwa“ to - jeśli w ogóle - przez czas krótszy niż sekunda. Nie można przy tym wykluczyć utraty aktywnych zadań drukowania. Zastosowanie takiego klastra wymaga użycia specjalnego osprz˛etu (patrz File Services). Jako komputery - klienty (Print Clients) wzi˛eto pod uwag˛e maszyny wyposażone w: ◦ Windows NT 4 Workstation ◦ Windows 9x Jako drukarki wzi˛eto pod uwag˛e: ◦ drukarki z kartami sieciowymi ◦ printer boxes z podłaczonymi ˛ drukarkami Poniższy rysunek pokazuje typowa˛ konstelacj˛e środowiska wydruku: Niektóre stacje robocze obsługuja˛ drukark˛e podłaczon ˛ a˛ lokalnie do LPT1 (drukarka lokalna). Inne stacje robocze nie obsługuja˛ bezpośrednio podłaczonych ˛ drukarek, lecz współpracuja˛ wyłacznie ˛ z drukarkami podłaczonymi ˛ do sieci. Wi˛ekszość drukarek laserowych można wyposażyć w kart˛e sieciowa.˛ W przeciwieństwie do nich drukarki atramentowe można wykorzystać do pracy w sieci cz˛esto dopiero po zastosowaniu dodatkowego printer box. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 91 21 Rysunek 3.3: Środowisko wydruku Rysunek pokazuje dwa zasadniczo różne przepływy danych. Z jednej strony klient wydaje zlecenie wydruku bezpośrednio przez sieć na drukark˛e, a z drugiej strony klient korzysta z „udost˛epnionej drukarki“ na serwerze wydruku, który ostatecznie przekazuje dane do drukarki. Poniżej opisane zostały różne 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 także w świecie Windows poczawszy ˛ od Windows NT i jest standardem komunikacji pomi˛edzy serwerem wydruku a drukarka.˛ Zasadniczo technika ta może być także stosowana do komunikacji pomi˛edzy 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 poniżej, zaimplementowali dodatkowe porty, np. ◦ LexMark Mark Vision Print Monitor (Lexmon.dll) ◦ Hewlett-Packard Network Port Print Monitor (Hpmon.dll). 21 Microsoft Windows NT 4 Resource Kit ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 92 Niniejsze porty, w przeciwieństwie do portu LPR, sa˛ w stanie korzystać także z innych protokołów transportu. W powyższym przypadku obsługiwane sa,˛ np. ◦ DLC oraz ◦ IPX Nowe sieciowe porty wydruku z reguły umożliwiaja˛ komunikacj˛e dwukierunkowa˛ z drukarkami lub z print boxes. 3.3.3.3 Bezpośrednie drukowanie ze stacji roboczej Bezpośrednie drukowanie (patrz 3.3, strzałka 1) realizowane jest poprzez LPR / LPD. W tym celu na stacjach roboczych z Windows NT 4 musi być zainstalowany serwer wydruku TCP / IP. Systemy Windows 9x trzeba dodatkowo wyposażyć w oprogramowanie innych producentów. Na stacjach roboczych należy skonfigurować, jako przyłacze, ˛ tak zwany port LPR. W tym celu należy wpisać adres IP albo odpowiednia˛ nazw˛e hosta (DNS) drukarki docelowej. Nast˛epnie, na żadanie, ˛ należy wybrać model drukarki wraz z odpowiednimi sterownikami. System operacyjny przyjmie informacj˛e o tej drukarce, jako drukarce „lokalnej“. Bezpośrednia komunikacja klienta z drukarka˛ w Windows NT nie znalazła szerokiego zastosowania ze wzgl˛edu na duży nakład pracy administracyjnej jaka˛ w tym celu trzeba wykonać na urzadzeniach ˛ końcowych. 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 si˛e na LPR / LPD (patrz bezpośrednie drukowanie ze stacji roboczej, podrozdział 3.3.3.3). Transmisja danych pomi˛edzy stacja˛ robocza˛ a serwerem wydruku może być realizowana na różne sposoby. Aby klient mógł wydawać zlecenia wydruku do określonej drukarki za pośrednictwem serwera, po stronie serwera musza˛ być spełnione dwa zasadnicze warunki: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 93 ◦ drukarka musi być skonfigurowana na serwerze wydruku (port LPR, sterowniki wydruku) ◦ drukarka musi być dost˛epna Udost˛epnienie drukarki umożliwia w sieciach windowsowych mi˛edzy innymi „surfowanie“ w ustawieniach drukarki po klikni˛eciu odpowiedniego serwera wydruku. Komunikacja pomi˛edzy stacja˛ robocza,˛ a serwerem wydruku (udost˛epnienie drukarki) może być realizowana na trzy różne sposoby: ◦ Za pomoca˛ polecenia NET USE można przekierować istniejacy ˛ port lokalny LPT na udost˛epniana˛ drukark˛e (przykład: net use LPT3\\nazwaserwera\nazwaudost˛epnianejdrukarki). Metoda ta wymaga od użytkownika zainstalowania drukarki (sterowników drukarki) na porcie LPT i jej lokalnego skonfigurowania. Jest to cz˛esto wymagane, gdy wydruk ma być wykonywany z aplikacji dosowych. Dane wydruku przesyłane sa˛ w formacie RAW, co oznacza, że moga˛ być one zinterpretowane przez drukark˛e bezpośrednio po przesłaniu. ◦ Można utworzyć nowy port LPR z adresem docelowym serwera wydruku i nazwa˛ udost˛epnianej drukarki. Dane wydruku również w tym przypadku przesyłane sa˛ w formacie RAW. Za pomoca˛ tak zwanej metody „Point & Print“ na stacji roboczej można skonfigurować drukark˛e sieciowa.˛ Zaleta˛ takiego rozwiazania ˛ jest to, że w idealnym przypadku nie b˛edzie potrzeby instalacji sterowników i wykonywania r˛ecznej konfiguracji. Dane wydruku przesyłane sa˛ w formacie EMF (Enhanced Meta Format). Drukarka nie umie ich zinterpretować, dlatego dane musza˛ zostać wcześniej przygotowane przez serwer wydruku. Metoda „Point & Print“ została dokładniej opisana w nast˛epnym rozdziale. 3.3.3.5 Metoda „Point & Print“ W przypadku komunikacji pomi˛edzy Print Client i Print Server, Microsoft postawił na protokół RPC (Remote Procedure Call) i wdrożył tym samym tak zwana˛ technologi˛e Point & Print. Z jednej strony rozwiazanie ˛ to umożliwia przenoszenie sterowników drukarki z serwera na klienta oraz przekazanie ustawień drukarki (podawane papieru, standardowe formaty papieru) do klienta, a z drugiej cz˛eść procesu przetwarzania danych (Rendering) przechodzi na serwer, dzi˛eki czemu nast˛epuje odciażenie ˛ klienta. Jest to szczególnie korzystne podczas pracy z Terminal Servers. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 94 Ponieważ opisywana technologia Microsoft jest specyficzna, poniżej przedstawiony został szczegółowy przebieg całego procesu drukowania. Przyj˛eliśmy założenie, że zarówno stacje robocze, jak i serwer wydruku korzystaja˛ z Windows NT 4. Jeśli użytkownik doda drukark˛e sieciowa˛ do swojego środowisku wydruku, wówczas, jako pierwsze, nastapi ˛ zsynchronizowanie sterowników. Klient Windows NT ściagnie ˛ sterowniki z serwera, jeśli jednocześnie spełnione zostana˛ nast˛epujace ˛ warunki.: ◦ Serwer wydruku używa 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˛ wersj˛e niż ta, która znajduje si˛e na serwerze. Po ściagni˛ ˛ eciu sterownika, nastapi ˛ jego instalacja przez klienta. Oznacza ona także umieszczenie odpowiednich wpisów w lokalnym rejestrze klienta. Proces drukowania: Poniższy rysunek (rys. 3.4) przedstawia przebieg całego procesu, a pod rysunkiem znajduje si˛e jego krótki opis. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 95 Rysunek 3.4: Proces wydruku realizowany metoda˛ „Point & Print“ ◦ Krok 1: Użytkownik decyduje si˛e na wydrukowanie dokumentu z aplikacji windowsowej. Aplikacja wywoł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 nast˛epuje realizacja pierwszego etapu wydruku, czyli „renderowanie“ dokumentu do formatu EMF. Aplikacja wywołuje lokalny Spooler (Winspool.drv). ◦ Krok 2: Ponieważ klient używa 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) bezpośrednio 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 nast˛epnie 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 przeciwieństwie do formatu RAM, jeszcze dość niezależne od urzadzenia ˛ drukujacego ˛ a ich wielkość w wi˛ekszości przypadków jest niewielka. Pierwsza cz˛eść „renderingu“ wykonana została na kliencie, natomiast teraz nast˛epuje druga cz˛eść, 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 każda˛ stron˛e w bitmap˛e i drukuje je na papierze. Jeśli 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. Także w sytuacji, gdy klient używa 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 pomi˛edzy stacja˛ robocza˛ a serwerem wydruku może opierać si˛e na różnych protokołach: ◦ TCP / IP ◦ NetBEUI ◦ SPX/IPX ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 97 Właściwa transmisja danych wydruku wymaga: ◦ SMB albo ◦ RPC 3.3.3.7 Nadawanie praw dost˛epu Prawa dost˛epu do drukarek sieciowych (zasobów) obsługiwanych przez serwery wydruku w środowisku Windows NT sa˛ nadawane za pomoca˛ serwerów wydruku. Istnieje nast˛epujace ˛ stopniowanie praw dost˛epu do zasobów: ◦ drukowanie ◦ zarzadzenie ˛ drukarkami ◦ zarzadzanie ˛ dokumentami 3.3.3.8 Narz˛edzia Narz˛edzia administracyjne dost˛epne dla serwerów wydruku w Windows NT ograniczaja˛ si˛e do zarzadzania ˛ zasobami - drukarkami oraz sterownikami drukarek. Administrowanie ustawieniami samych drukarek nie jest możliwe. Producenci drukarek udost˛epniaja˛ dodatkowe narz˛edzia dla administratorów drukarek (MarkVision firmy LexMark, JetAdmin firmy HP, etc.). Podobnie, jak w przypadku nap˛edów sieciowych ważne jest automatyczne nawiazanie ˛ połaczenia ˛ z drukarkami podczas logowania użytkownika. Można je realizować przez skrypt VB albo korzystajac ˛ z takich narz˛edzi jak con2prt.exe. Do przyznawania praw dost˛epu do zasobów - drukarek można wykorzystać skrypty (Perl). 3.3.3.9 Migracja - szczegóły robocze Ustawienia drukarek zależa˛ od każdej z nich z osobna. Różnice mi˛edzy nimi moga˛ wystapić ˛ nawet w przypadku wykorzystywania drukarek tego samego modelu, np. wskutek ich różnego złożenia albo różnego wyposażenia. Dlatego podczas ustawiania parametrów drukarek należy zwrócić uwag˛e na takie elementy jak pami˛eć operacyjna, sposób podawania i format papieru. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 98 Drukarki z wieloma podajnikami cz˛esto zasilane sa˛ papierem różnej jakości. Aby ułatwić użytkownikowi dokonanie prawidłowego wyboru, drukarka jest cz˛esto udost˛epniana jako dwa różne zasoby. Wówczas każdemu z nich można zadać różne ustawienia, odpowiednio do standardowo obsługiwanego podajnika. Aby optymalnie obsłużyć użytkownika mobilnego, można pomyśleć o zestawieniu połacze˛ nia z drukarkami na podstawie miejsca, w którym znajduje si˛e komputer. Posłużyć si˛e przy tym można dodatkowymi mechanizmami w skryptach logowania, o ile istnieje możliwość odpytywania bazy danych, w której przechowywane sa˛ informacje odnośnie przyporzadkowania ˛ stacji roboczych i drukarek. Producenci wielu modeli drukarek oferuja˛ własne sterowniki, także wtedy, gdy znajduja˛ si˛e już one w źródłach Windows NT. Sterowniki udost˛epniane przez Microsoft sa˛ sprawdzone, jednak cz˛esto nie maja˛ one takiej ilości opcji, jak sterowniki pochodzace ˛ od producentów drukarek (obsługa wielu podajników, duplex). Dlatego ich użycie może okazać si˛e konieczne. Producenci cz˛esto dostarczaja˛ swoje sterowniki w postaci dodatkowych plików *.dll. Daje to wi˛eksza˛ kompletność środowisku drukowania i wymusza zarzadzanie ˛ wyborem sterowników. Istniejace ˛ rozwiazania ˛ opieraja˛ si˛e cz˛esto na wyborze pomi˛edzy postscriptem a PCL. W niektórych środowiskach stosuje si˛e także predefiniowane formularze (forms) i czcionki. W środowisku Windows NT każdy użytkownik ma, w standardowej konfiguracji, dost˛ep do każdej udost˛epnianej drukarki, co cz˛esto jest jednak niechcianym rozwiazaniem. ˛ W porównaniu z File Services, przyznawanie użytkownikom praw dost˛epu do zasobów - drukarek jest znacznie trudniejsze. 3.3.4 Migracja zast˛epujaca ˛ W niniejszym rozdziale założyliśmy sytuacj˛e, że istnieje infrastruktura drukowania, w skład której wchodzi przynajmniej jeden serwer wydruku badź ˛ że trzeba stworzyć taka˛ infrastruktur˛e. Minimum zadań przypadajacych ˛ na serwer wydruku b˛edzie pełnienie roli centralnego Spooling Host, który może świadczyć także inne usługi. Opisany poniżej sposób migracji zwiazany ˛ jest wyłacznie ˛ z jednym systemem, tj. z „Common UNIX Printing System“. Jest tak, gdyż praktycznie we wszystkich systemach uniksowych, zdołał si˛e on przebić na pierwsze miejsce spośród innych systemów drukowania. CUPS został niedawno przystosowany również do pracy w systemie operacyjnym Mac OS X firmy Apple. W przypadku Linuksa CUPS jest de facto standardem we wszystkich dużych dystrybucjach (SuSE, Debian, Mandrake, RedHat, itd.). W przypadku, gdy istniejace ˛ środowisko wydruku składa si˛e z klientów windowsowych, ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 99 które maja˛ dost˛ep do swojego serwera wydruku NT-Print-Server, oceniliśmy możliwości przeprowadzenia migracji po stronie serwera. 3.3.4.1 Wymagania odnośnie funkcjonalności Ponieważ drukowanie jest cz˛esto zadaniem typu „mission critical“, istnieja˛ duże wymagania odnośnie infrastruktury technicznej i wewn˛etrznej organizacji: ◦ niezawodna praca Nieodzowne jest choćby minimalne zabezpieczenie przed awaria; ˛ możliwość łatwego zintegrowania rozwiazań ˛ zast˛epczych - gotowość do pracy (drukowania) musi być zagwarantowana niezależnie od obecności specjalistów IT. ◦ wierne odwzorowanie - odpowiednia jakość wydruku Kryteriami oceny właściwej jakości sa˛ prawidłowe czcionki, grafika bez zniekształceń, prawdziwe kolory. ◦ jakość wydruku Renderowanie powinno odbywać si˛e z minimalna˛ rozdzielczościa.˛ ◦ accounting Należy stworzyć możliwość kontrolowania kosztów polegajac ˛ a˛ na szczegółowym protokołowaniu wykonywanych zadań. ◦ kwoty wymaganie majace ˛ na celu kontrol˛e kosztów badź ˛ ich ograniczenie. ◦ obejście zadań drukowania Należy zapewnić możliwość bezproblemowego korzystania z drukarki zast˛epczej, takiego które nie wymaga ponownego przesłania zlecenia wydruku przez klienta (ważne: W wypadku, gdy używana jest drukarka zast˛epcza innego typu, mimo wszystko, powinna ona być w stanie wydrukować wysłany do niej plik. ◦ ponowienie zadania wydruku ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 100 W środowisku zapewniajacym ˛ centralne powielanie, cz˛esto wymagane jest ponowne wykonanie zakończonego już zlecenia drukowania. Aby skorzystać z opcji „Printing on Demand“ oraz wtórnego zwi˛ekszenia nakładu, lub w celu unikni˛ecia problemów technicznych (np. blokada papieru / brak pradu) ˛ i bł˛edów w obsłudze (np. użycie papieru o niewłaściwym kolorze), należy skorzystać z funkcji realizujacej ˛ powtórny wydruk. ◦ Job History Historia zadań dokumentuje przebieg wszystkich procesów drukowania. Dzi˛eki niej pod koniec roku można uzyskać liczby wiele mówiace ˛ o łacznej ˛ ilości zrealizowanych zadań wydruku (planowanie budżetu), ich rozłożeniu na poszczególne modele drukarek i miejsca (optymalizacja podziału zasobów) oraz maksymalnym obciażeniu ˛ (w którym miejscu maja˛ sens nowe inwestycje) ◦ Integracja z rozwiazaniami ˛ własnościowymi Cz˛esto zachodzi potrzeba przej˛ecia albo zintegrowania „starych“ lub nowych specjalistycznych rozwiazań. ˛ Należ sprawić, by było to możliwe bez wi˛ekszych problemów. ◦ przejrzystość kosztów i ich kontrola - z nich nie wolno rezygnować, zarówno podczas przeprowadzania migracji, jak i w późniejszej pracy. ◦ bezpieczeństwo Nie można dopuścić do „podsłuchiwania“ zaufanych danych (dotyczy to także przechwytywania plików przeznaczonych do wydruku). ◦ autoryzacja Określone drukarki powinny być udost˛epniane wyłacznie ˛ wyznaczonym grupom użytkowników, wzgl˛ednie pracować z ograniczonymi „zaufanymi“ ustawieniami (1200 dpi w trybie full-screen na papierze fotograficznym) dla określonych użytkowników (albo być całkowicie disabled). ◦ drukowanie „on hold“ Drukowanie przesuni˛ete w czasie lub „nocne“ (automatycznie sterowane batch-jobs). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 101 ◦ bez specjalnego oprogramowania umożliwiajacego ˛ podglad ˛ W idealnym przypadku szybki podglad ˛ zadań oczekujacych ˛ w kolejce wydruku realizowany jest z poziomu przegladarki ˛ internetowej. Najlepiej, aby z „każdego miejsca“ zagwarantowany był dost˛ep do linii poleceń. Najlepsza sytuacja jest wtedy, gdy nie dotyczy to każdego, lecz tylko uprawnionych osób. ◦ integracja ze środowiskami heterogenicznymi Oprogramowanie realizujace ˛ wydruk musi obsługiwać wiele protokołów, ponieważ w praktyce nie istnieje ogólnie przyj˛ety standard. Zdolność do wszechstronnej współpracy musi dotyczyć zarówno komunikacji z klientem (powinien on zachować dowolność wyboru protokołu za pomoca˛ którego przesyła dane do drukowania), jak też komunikacji z drukarka˛ docelowa˛ badź ˛ serwerami wydruku typu second-level (które cz˛esto sa˛ „starodawne“ i dlatego wymagaja˛ zachowania odpowiednich konwencji). Dodatkowo musi być zachowana ogólna obsługa przyszłego standardu IPP. 3.3.4.2 Obsługa standardów wyróżniajacych ˛ si˛e22 w procesie drukowania Korzystajac ˛ z zaproponowanych rozwiazań ˛ technicznych, należy spełnić poniższe wymagania odnośnie funkcjonalności. Ważne jest przy tym dażenie ˛ do uzyskania otwartości przez konsolidacj˛e z istniejacymi ˛ i uznanymi otwartymi standardami. Jednocześnie, na czas migracji, należy zagwarantować wymagane wsparcie dla protokołów używanych wcześniej albo protokołów własnościowych (oraz urzadzeń, ˛ które z nich korzystaja). ˛ Bardzo dobrze nadaje si˛e do tego system wydruku CUPS, system wydruku, który dzi˛eki zaimplementowanemu IPP (Internet Printing Protocol) może pełnić rol˛e protokołu ponad platformowego. IPP stosowany jest jako protokół ła˛ czacy ˛ serwery i klienty CUPS z nowoczesnymi drukarkami obsługujacymi ˛ bezpośrednie wsparcie IPP, jako medium dla komunikacji i transmisji danych. Podczas komunikacji ze starszymi drukarkami albo serwerami wydruku można skorzystać z modułów CUPS, tak zwanych „BackEnds“. Moduły te umożliwiaja˛ komunikacj˛e za pomoca˛ innych protokołów. Na rysunku 3.5 przedstawiony został schemat korzystania z protokołów na różnych interfejsach. Ich działanie opisaliśmy poniżej. LPR/LPD Tradycyjny protokół służacy ˛ do transmisji danych wydruku [od klienta do serwera wydruku, 22 Standardy otwarte, jak i zamkni˛ete. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 102 z serwera do serwera i z serwera do drukarki docelowej (sieciowej) lub też z klienta bezpośrednio 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łaściwego“ standardu (różne implementacje, które z powodu miejscowego braku kompatybilności stwarzaja˛ trudności). 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 możliwości komunikacji, tj. klient - serwer, serwer - serwer, serwer - drukarka docelowa oraz klient - drukarka docelowa. Ostatnia˛ i jedyna˛ wiaż ˛ ac ˛ a˛ specyfikacja˛ jest IPP-1.1. Protokół IPP powstał w wyniku prac grupy roboczej (PWG) składajacej ˛ si˛e z przedstawicieli systemów operacyjnych i systemów drukowania oraz producentów oprogramowania z Europy, USA i Japonii. Jego standaryzacji dokonał IETF. Jest on już obsługiwany przez wszystkie aktualnie dost˛epne drukarki sieciowe. Jednak dopóki dost˛epne sa˛ „stare“ urzadzenia ˛ oparte na LPR / LPD (które b˛eda˛ sprawne jeszcze przez wiele lat), odpowiednie zmiany należy wprowadzać tylko tam, gdzie ma to bezpośredni sens. Wskazówka: Nowsze wersje systemu operacyjnego Windows firmy Microsoft maja˛ wbudowana˛ pewnego rodzaju obsług˛e IPP po stronie klienta (Windows 98SE, Windows ME, Windows 2000, Windows XP) albo można je nieodpłatnie przystosować (Windows NT, Windows 95, Windows 98). Dzi˛eki temu systemy te moga˛ podczas drukowania „całkiem naturalnie“ korzystać z serwera CUPS. Jednakże Microsoft oferuje obecnie tylko implementacj˛e 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 przejściowym, np. nie definiowała ważnego aspektu szyfrowania danych przeznaczonych do wydruku oraz sposobu autoryzacji użytkowników. Z tego powodu serwer CUPS, w przypadku bezpośredniego udost˛epniania klientowi windowsowemu swoich usług, musi rezygnować z autoryzacji. Jeśli CUPS stosowany jest wspólnie z Samba,˛ wówczas wymagana, ewentualna autoryzacja klienta windowsowego może być realizowana dzi˛eki mechanizmom zaimplementowanym na serwerze plików. Dla środowisk o wyższych wymaganiach wzgl˛edem bezpieczeństwa przeznaczone sa,˛ dost˛epne na rynku, komercyjne klienty CUPS dla Windows. Socket/AppSocket AppSocket (cz˛esto znany pod nazwa˛ „HP Jet Direct“) jest dedykowanym protokołem transmisji danych wydruku. Jest on wydajniejszy i mniej zawodny niż LPR / LPD; umożliwia w ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 103 pewnym stopniu komunikacj˛e dwukierunkowa˛ i jest szybszy. Istnieja˛ zarówno wolne, jak i komercyjne narz˛edzia administracyjne dla JetDirect służace ˛ do zarzadzania ˛ struktura˛ dużych sieci (np. HP WebJet Admin). Jednakże nie oferuje on ani możliwości szyfrowania danych wydruku, ani autoryzacji użytkowników. Zwrotne komunikaty o stanie drukarki realizowane sa˛ w praktyce tylko w kierunku serwer - drukarka lub w przypadku połaczenie ˛ bezpośredniego w kierunku klient - drukarka. SMB/CIFS Klienty windowsowe używaja˛ tego protokołu do transmisji danych wydruku do serwera wydruku (albo innych komputerów z Windows, o ile oferuja˛ one „udost˛epnione“ drukarki). Cz˛esto droga od najbliższego komputera z Windows do drukarki (sieciowej) docelowej musi być ponownie regulowana przez inny protokół (chyba, że podłaczona ˛ jest ona lokalnie - przez interfejs równoległy, USB, FireWire lub interfejs szeregowy). MS-RPC Klienty windowsowe, poczawszy ˛ od NT4, potrafia˛ używać tego protokołu do transmisji danych wydruku do Windows-Print-Server (od wersji NT4). Za pomoca˛ metod RPC można także wykonywać automatyczna˛ instalacj˛e sterowników na klientach, o ile serwer wydruku dysponuje odpowiednimi plikami. („Ładowanie“ sterowników z komputera klienta na serwer wydruku przez administratora również opiera si˛e na RPC). Od czasu, gdy Samba potrafi zarzadzać ˛ SMB / CIFS, możliwe jest także wykorzystywanie go przez CUPS. Obsługa wielu protokołów w CUPS (rysunek pogladowy) ˛ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 104 23 Rysunek 3.5: Drukowanie z CUPS 3.3.4.3 Integracja w środowiskach klienckich Windows Wskazówka odnośnie integracji CUPS i Samby Obsługa CUPS jest zintegrowana z Samba˛ w optymalny sposób, znacznie lepiej niż inne dost˛epne uniksowe systemy drukowania. Jest to jedyny system wydruku, który posiada funkcje wbudowane w bibliotek˛e (software-library). Dzi˛eki temu inne programy moga˛ korzystać z tych funkcji „linkujac“ ˛ bibliotek˛e. Właśnie Samba wykorzystuje t˛e właściwość. Jest ona domyślnie zlinkowana z libcups. Serwer wydruku Samba może dzi˛eki temu przekazywać przychodzace ˛ zlecenia wydruku do serwerów wydruku CUPS przez IPP. Moga˛ być one zainstalowane na innych hostach wyznaczonych do obsługi wydruku albo na tym samym serwerze, co Samba. Stosowanie IPP odbywa si˛e tu w całkowicie przejrzysty sposób, zarówno dla administratora, jak i dla użytkownika i nie wymaga dalszej konfiguracji. S YSTEM 23 P OŁ ACZENIE ˛ OPERACYJNY KLIENTA Publicznie dost˛epne na Linux-Kongress2002/Tutorial/. stronie http://www.linuxprinting.org/kpfefle/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 105 Win98SE dostarczany z IPP (wersja 1.0) Win98 po wyposażeniu w IPP Windows 9x Przez SMB / CIFS (z pomoca˛ Samby) Przez LPR / LPD (wymaga doinstalowania klienta LPR) Po wyposażeniu 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 wyposażeniu 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 wyposażeniu 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 konfiguracja Samby musi odwzorowywać NTPrint-Server. Zostało to bardzo dokładnie opisane w Samba HOWTO Collection. Uzyskanie od- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 106 powiedniej konfiguracji nie wymaga dużej ingerencji administratora. Obsługiwane jest również ściaganie ˛ sterowników z maszyny klienta. Sterowniki drukarek gromadzone sa˛ na serwerze Samba. Ich automatyczna instalacja na systemach klienckich wykonywana jest w tle, o ile użytkownik 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˛ użytkownicy i administratorzy pracujacy ˛ w ramach jednej domeny, jeśli używaja˛ skryptów logowania. Wystarczy utworzyć skrypt zawierajacy ˛ zaledwie jeden wiersz: rundll32 printui.dll,PrintUIEntry /in /n„\\SAMBASERVERNAME\nazwazasobu-drukarki . Odpowiednia drukarka zostanie automatycznie zainstalowana dla logujacego ˛ si˛e użytkownika (innymi możliwościami oferowanymi przez skrypty sa: ˛ instalacja wielu drukarek, wyznaczenie drukarki domyślnej, usuwanie zb˛ednych kolejek drukowania itd.). Dzi˛eki temu zarzadza˛ nie sterownikami drukarek jest komfortowe a administratorzy maja˛ mniej pracy. Różnym grupom użytkowników można w ten sposób, tj. wykorzystujac ˛ różne skrypty logowania, przypisać różnie przystosowane środowiska. Bezpieczeństwo i autoryzacja Jeśli korzystamy z CUPS, istnieje możliwość szyfrowania komunikacji pomi˛edzy klientem. a serwerem. Gdy stosowany jest protokół IPP, do szyfrowania przesyłanych danych można wykorzystać SSL 3 albo TLS. Inna możliwość spełnienia podwyższonych wymagań bezpieczeństwa polega na zastosowaniu autoryzacji użytkowników za pomoca˛ LDAP. CUPS obsługuje interfejs LDAP, który można wykorzystać do kierowania nadawaniem praw dost˛epu w systemie drukowania. Usług˛e katalogowa˛ można dodatkowo zastosować do skonfigurowania praw dost˛epu i kwot dla konkretnego użytkownika. Klienci Windows na ogół nie autoryzuja˛ si˛e przez CUPS, lecz przez Samb˛e. Autoryzacja ta nast˛epuje automatycznie podczas drukowania przez Samb˛e, która przejmuje w tym czasie kontrol˛e nad zarzadzaniem ˛ prawami dost˛epu. W takim przypadku trzeba tylko w odpowiedni sposób zapewnić serwerowi Samba możliwość korzystania z serwera wydruku CUPS (właściwa autoryzacja). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 107 Rozgłaszanie drukarek obsługiwanych przez CUPS w LDAP i Active Directory Samba może wpisywać swoje usługi do katalogu LDAP albo do Active Directory. Korzyści z tego czerpia˛ oczywiście drukarki obsługiwane przez CUPS, a także CUPS-Print-Serwer. Możliwa jest dalsza rozbudowa integracji ze środowiskiem AD (albo mocno wzorowanym na nim środowiskiem LDAP). Najbliższa wersja CUPS, która jest w stanie „sama z siebie“ obsłużyć połaczenie ˛ z LDAP znajduje si˛e już w zaawansowanej fazie beta. Niezależny od platformy dost˛ep przez WWW CUPS posiada „wbudowany“ Web-Interface. Dost˛ep do niego uzyskać można wywołujac, ˛ za pomoca˛ przegladarki ˛ internetowej, adres: „http://CUPS-PRINTSERVER:631/“. W ten sposób wszyscy użytkownicy moga˛ uzyskać dost˛ep do informacji o funkcjach serwera wydruku. Standardowo użytkownicy moga˛ kontrolować stan zleceń drukowania, przerywać je, wznawiać oraz ponawiać, etc. (w zależności od każdorazowej konfiguracji). W odniesieniu do drukarek / kolejek drukowania, administratorzy lub pracownicy help-desk, którzy korzystaja˛ z Web-Interface, moga˛ je zakładać, usuwać, zmieniać konfiguracj˛e, uruchamiać i zatrzymywać, zamykać / otwierać oraz równoważyć zlecenia wydruku, odkładać i ponownie uruchamiać. Możliwości obsługi drukowania przez Web-Interface można ograniczać albo rozszerzać w zależności od konfiguracji serwera CUPS. Web-Interface podlega takim samym zasadom kontroli praw dost˛epu, jak ogólne zasoby CUPS. Każdy obiekt serwera wydruku (dost˛ep do własnych zleceń albo pojedynczych drukarek, dost˛ep do wszystkich drukarek albo wszystkich zleceń itd.) można wyposażyć w różne prawa dost˛epu: „Użytkownik Kowalski ma prawo administrować, ale tylko wtedy, gdy korzysta z komputerów A albo B“, „Wszystkim użytkownikom wolno usuwać własne zlecenia wydruku, ale nie cudze“, itd.) 3.3.4.4 Możliwości dostosowawcze Oprócz bezpośredniego zestawu funkcji oferowanych przez CUPS system ten można prosto i w na różne sposoby rozszerzyć o filtry i BackEnds. Filtry Wewn˛etrznie CUPS używa systemu plików o modularnej budowie. Pracuje on na otwartych interfejsach. Może być w każdej chwili rozszerzony. W tym celu można skorzystać z dowolnych j˛ezyków skryptowych (Shell, Perl, Python) albo j˛ezyków programowania (C, C++, Java etc.). Za pomoca˛ wrapper-scripts w bardzo łatwy sposób można także właczać ˛ własnościowe programy ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 108 w postaci binarnej. BackEnds Nowe BackEnds można „dokować“ w prosty sposób. Czasami, gdy istnieje potrzeba dostosowania systemu do specjalnych wymagań danego środowiska (np. automatyczna replikacja określonych zleceń wydruku w innym dziale, np. w celu składowania listów służbowych w archiwum), a czasami ze wzgl˛edu na atrakcyjność nowości technicznych (Wireless LAN, Bluetooth, FireWire). 3.3.4.5 J˛ezyki opisu stron CUPS używa do sterowania drukarkami tak zwanych PostScript Printer Descriptions (PPD). Specyfikacja PPD została pierwotnie zdefiniowana przez firm˛e Adobe i jest praktycznie obsługiwana przez każdy 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 także dla drukarek, które nie posiadaja˛ własnego interpretera postscriptu. CUPS używa tych dobrze zdefiniowanych opisów drukarek podczas definiowania odpowiednich ustawień 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 używajac ˛ w tym celu tak zwanych „filtrów“. W Linuksie program ghostscript zawiera niezwykle wszechstronne zestawy filtrów umożliwiajace ˛ konwertowanie z j˛ezyka PostScript do różnych, specyficznych dla producentów i urzadzeń, ˛ j˛ezyków. Dopasowana wersja ghostscript jest także cz˛eścia˛ CUPS. 3.3.4.6 Techniczna zmiana funkcji sterownika Przekształcanie pliku przeznaczonego do wydruku w nadajace ˛ si˛e do wydruku bitmapy, możne być realizowane na dwa różne sposoby, tzn: ◦ Funkcje sterownika wykonywane sa˛ w całości po stronie klienta. Plik do wydruku przygotowywany jest po stronie klienta. Serwer wydruku realizuje jedynie funkcje spooling dla danych wydruku. Sterowniki moga˛ być oferowane klientowi do ściagni˛ ˛ ecia i automatycznej instalacji. ◦ Przygotowanie danych do wydruku odbywa si˛e 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, może on być udost˛epniany na serwerze do automatycznej instalacji. Po takim przygotowaniu dane wydruku przesyłane sa˛ z serwera do zadanych drukarek. O ile drukowanie ma nastapić ˛ na drukarce, która nie obsługuje PostScript, proces przygotowywania wydruku realizowany jest za pomoca˛ specjalnego oprogramowania (patrz także 3.3.4.5). Drugi model, w przeciwieństwie do pierwszego, oferuje wi˛ecej korzyści: ◦ automatyczna˛ obsług˛e wszystkich urzadzeń ˛ postscriptowych wraz ze wszystkimi opcjami drukowania (tak jak w Windows NT). ◦ dodatkowa˛ obsług˛e ogólnie stosowanych drukarek niepostscriptowych (w zależności od zastosowania ghostscript albo innych pakietów sterowników). ◦ automatyczny accounting Podczas logowania każdej stronie automatycznie przypisywany jest czas wydruku, nakład, drukarka docelowa, nazwa użytkownika, ID-procesu wydruku i IP nadawcy, które moga˛ być wykorzystywane przy późniejszym ocenianiu (kontrola kosztów, statystyki). ◦ kwotowanie Możliwość ustalania kwot na wykorzystywanie przez użytkowników danej drukarki (określenie ilości stron i / oraz ilości danych, które, po przesłaniu przez konkretnego użytkownika, maja˛ zostać zaakceptowane przez drukark˛e). ◦ funkcj˛e reprint Zlecenia gotowe do druku przechowywane sa˛ przez pewien czas. Ich realizacja nie wymaga od klienta ponownego szukania żadanego ˛ pliku, otwierania i przesyłania go. Dotyczy to zarówno pierwszego, jak i ponownego drukowania. ◦ funkcj˛e redirect Pliki przeznaczone do druku można w każdej chwili przekierować do innej drukarki docelowej (nawet wówczas, gdy pierwotna drukarka była drukarka˛ postscriptowa˛ a nowa nie obsługuje PostScript). Opcje wydruku można dostosować do nowego urzadzenia ˛ docelowego. ◦ konsolidacja sterowników ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 110 W efekcie końcowym wszystkie klienty używaja˛ tego samego sterownika Core-PostScript (który jest modyfikowany tylko przez plik ASCII, czyli „PPD“). Niniejszy model zawiera nast˛epujace ˛ ograniczenia: ◦ wymaga wi˛ekszej ilości zasobów Centralne przygotowywanie danych wydruku na serwerze wymaga wi˛ecej RAM, lepszej CPU oraz zajmuje wi˛ecej miejsca na twardym dysku (jego ilość można z góry określić, jeśli tylko znana jest oczekiwana wielość wydruku.) Niewielkie ograniczenia w przypadku obsługiwanych modelów drukarek Wprawdzie wi˛ekszość stosowanych drukarek jest obsługiwana - jednakże istnieja˛ wyjatki. ˛ List˛e obsługiwanych modelów i producentów można znaleźć w bazie danych urzadzeń ˛ na stronie http://Linuxprinting.org. 3.3.4.7 Architektury systemu drukowania Poniżej nakreślone zostały potencjalne architektury wykorzystywane wraz z CUPS, przy czym przy wyborze różnych scenariuszy stosowania decydujace ˛ znaczenie odegrało uzyskanie zwi˛ekszonej stabilności: ◦ Serwer: Każdy komputer z CUPS komunikujacy ˛ si˛e bezpośrednio z drukarka, ˛ może oferować funkcje wydruku innym komputerom jako usług˛e, co znaczy, że może on być serwerem CUPS. W tym celu wymagane sa˛ odpowiednie PPDs oraz filtry służace ˛ do właściwego przygotowywania plików do druku. ◦ Klient: Każdy komputer, który przesyła dane wydruku do serwera, jest klientem CUPS. Klient CUPS nie potrzebuje, lokalnie, filtrów ani PPDs. Jeśli jednak na kliencie maja˛ być 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 znajdujacych ˛ si˛e wewnatrz ˛ sieci informacje o zainstalowanych drukarkach. Dzi˛eki temu klienty wiedza,˛ z której drukarki w sieci moga˛ korzystać. Powyższe informacje przesyłane sa˛ za pomoca˛ UPD-Broadcasting. Alternatywnie klient może wysyłać konkretne zapytania do serwerów (Polling). Polling może być także stosowany przez serwery, które sa˛ oddzielone za pomoca˛ Routera. Serwery, które znajduja˛ si˛e w różnych sieciach, można skonfigurować jako BrowseRelay i pobierać dane o dost˛epnych drukarkach, a nast˛epnie przesyłać je dalej do klientów własnej domeny Broadcast. ◦ Clustering - zapewnienie ciagłości ˛ pracy i ochrona przed Failover: Dwa albo wi˛ecej serwerów CUPS można skonfigurować w taki sposób, aby zapewnić ciagłość ˛ pracy usług wydruku. Cel ten można osiagn ˛ ać ˛ konfigurujac ˛ serwery z tymi samymi drukarkami i nazwami drukarek. Na serwerach CUPS automatycznie budowane sa˛ wewn˛etrzne klasy, które składaja˛ si˛e z drukarek noszacych ˛ te same nazwy. Ten z serwerów, który jako pierwszy gotowy jest do rozpocz˛ecia procesu drukowania, przejmuje zlecenie wydruku nadesłane przez klienta i przesyła je do drukarki. Konfiguracj˛e taka˛ można także ustawić r˛ecznie przez stworzenie odpowiednich klas, przy czym klasy można wówczas utworzyć także z drukarek majacych ˛ różne nazwy. 3.3.5 Migracja kontynuacyjna 3.3.5.1 Windows 2000 W niniejszym rozdziale przedstawiamy, pod katem ˛ oferowanych „Print Services“, nast˛epc˛e Windows 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 poniżej: ◦ Standard TCP/IP Port Monitor ◦ Internet Printing ◦ Publikowanie w Active Directory W kolejnych paragrafach znaleźć można szerszy opis wprowadzonych zmian. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 112 Komunikacja pomi˛edzy serwerem a drukarka˛ Wraz z Windows 2000 firma 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ównaniu z LPR możliwość uzyskiwania szczegółowych informacji o stanie. SPM może korzystać z dwóch różnych protokołów serwerów wydruku: RAW albo LPR. Standardem dla wi˛ekszości drukarek jest RAW. Publikowanie w Active Directory Za pomoca˛ Active Directory można udost˛epniać zasób - drukark˛e (na serwerach Windows NT albo 2000) w taki sposób, że użytkownik nie wie, na którym serwerze zasób ten si˛e znajduje. Użytkownik może po prostu wydać polecenie przeszukiwania AD. Internet Printing Wraz z Windows 2000 wprowadzono opcj˛e umożliwiajac ˛ a˛ publikowanie i instalowanie drukarek w sieci WWW. Środowiska mieszane Na serwerach Windows NT nie można składować sterowników dla klientów Windows 2000 albo XP. W takich środowiskach sterowniki musza˛ być instalowane oddzielnie. Na serwerach Windows 2000 można składować sterowniki dla klientów Windows NT. Jednak transmisja ustawień danego urzadzenia ˛ może skończyć si˛e niepowodzeniem w sytuacji, gdy korzysta si˛e (trzeba skorzystać) ze sterowników dostarczanych przez producenta urzadzenia. ˛ Przyczyna˛ tego jest przejście 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 nowości odróżniajace ˛ Print Services z Windows 2003 od tych z Windows 2000. 3.4 Autoryzacja 3.4.1 Przeglad ˛ Poniższe oceny techniczne prowadza˛ do wniosku, że zarówno w przypadku migracji kontynuacyjnej, jak i zast˛epujacej ˛ oraz w środowiskach heterogenicznych możliwe jest zapewnienie bez- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 113 piecznej autoryzacji użytkowników i hostów za pomoca˛ dost˛epnego oprogramowania pomocniczego. Istotna˛ rol˛e w tym procesie odgrywaja˛ Samba oraz OpenLDAP. Samba jako alternatywa dla serwera Windows NT oferuje klientom w środowisku systemów mieszanych podobna˛ funkcjonalność, jak w przypadku głównego kontrolera domeny opartego na NT. Samba, b˛edac ˛ baza˛ danych kont użytkowników, może korzystać z Open LDAP jako usługi katalogowej. Z punktu widzenia klientów windowsowych, Samba wraz z OpenLDAP pełni funkcj˛e domeny Windows NT. Jeśli chodzi o administrowanie informacjami o grupach, hostach i użytkownikach Samba realizuje rozwiazanie ˛ oparte na usługach katalogowych wraz ze wszystkimi wynikajacymi ˛ z tego zaletami. Na przykład w przypadku wykorzystania powyższego rozwiazania, ˛ przestaje istnieć problem skalowalności znany z Windows NT, który cz˛esto wymaga podziału infrastruktury pomi˛edzy różne domeny. Za pomoca˛ Samby można ustalać stopień zaufania pomi˛edzy różnymi domenami. Możliwe jest także stosowanie WINS-Service. Samba 3.0 udost˛epnia program służacy ˛ do replikacji WINS. Program ten nie został jeszcze w pełni przetestowany. Aby zachować kompatybilności Samba obsługuje rozwiazanie ˛ oparte na PDC i BDCs. Jednak obsługa powyższych ogranicza si˛e do tego, że serwer Samba widziany jest przez klientów windowsowych, w zależności od konfiguracji, jako PDC badź ˛ BDC. Sam Samba nie obsługuje replikacji bazy danych SAM pomi˛edzy PDC i BDC. Jednakże, ze wzgl˛edu na zapisywanie SAM w katalogu LDAP, replikacja SAM może być realizowana przez OpenLDAP. W przypadku migracji kontynuacyjnej, autoryzacja w środowiskach systemów mieszanych nie podlega ograniczeniom. Istnieja˛ one na styku technologii Samba / OpenLDAP - Active Directory oraz Samba / OpenLDAP - autoryzacja Kerberos. Należy przy tym podkreślić, że nie jest możliwe wykonanie autoryzacji Kerberos z klientów Windows 2000/XP do Samby / OpenLDAP, lecz trzeba w takim przypadku skorzystać z protokołu NTLM. Dopóki Microsoft b˛edzie wspierał powyższe rozwiazanie ˛ umożliwiajace ˛ klientom windowsowym wspomniana˛ integracj˛e, zapewnienie jej nie b˛edzie stanowić problemu. Rozwia˛ zaniu temu można przeciwstawić współprac˛e linuksowego serwera Kerberos z domena˛ Active Directory, dzi˛eki czemu można, na bazie Linuksa, stworzyć jednolity Credential-Management dla Windows i Linuksa. W środowisku opartym wyłacznie ˛ o Linuksa można stosować autoryzacje Kerberos. Alternatywnie można także realizować autoryzacj˛e za pomoca˛ OpenLDAP. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 114 3.4.2 Punkt wyjścia - Windows NT 4 Tematem niniejszego podrozdziału jest autoryzacja, wzgl˛ednie usługi zgłoszeniowe produktów Microsoft. Zostana˛ tu ocenione mi˛edzy innymi nast˛epujace ˛ aspekty: ◦ bazy danych użytkowników ◦ integracja komputerów i usług sieciowych ◦ autoryzacja W tym celu należy najpierw przeanalizować, pod katem ˛ usług zgłoszeniowych, techniczne podstawy środowiska 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 używanej bazy danych skupia, w jednym kontekście bezpieczeństwa, konta użytkownikó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 noszacych ˛ nazw˛e Domain Controllers (kontrolery domen). Oprócz użytkowników i komputerów w SAM odbywa si˛e także zarzadzanie ˛ grupami. Każdy z tych trzech typów obiektów można jednoznacznie opisać tak zwanym SIDem (Security Identifier), który nie powinien być niepowtarzalny dla wszystkich domen. Każdemu SIDowi (wzgl˛ednie długa konstrukcja liczb) odpowiada jeden SAM-Accountname, która z reguły zbudowana jest maksymalnie z 15 znaków alfanumerycznych (dozwolone jest użycie niektórych znaków specjalnych). SAM-Accountname jest nazwa,˛ której użytkownicy używaja˛ do identyfikacji. Komputery oparte o: ◦ Windows NT ◦ Windows 2000 ◦ Windows XP moga˛ być członkiem jednej domeny. W przeciwieństwie do tego dla systemów takich jak, np. Windows 3.11 albo 9x niemożliwe 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 si˛e“ grupa „użytkownik domeny“ w członka lokalnej grupy „użytkownik“. W ten sposób, np. użytkownicy, którzy na komputerze z NT moga˛ zalogować si˛e do domeny, uzyskuja˛ lokalny dost˛ep do zasobów używanego komputera. Jedna domena wymaga przynajmniej jednego Domain Controller, tak zwanego PDC (Primary Domain Controller). Przechowuje on SAM domeny i tylko on może zmieniać zawartość SAM. W celu rozłożenia obciażenia ˛ i redundancji, w SAM należy zastosować tak zwane BDCs (Backup Domain Controllers), które przechowuja˛ kopi˛e SAM i regularnie aktualizuja˛ zmiany w PDC. Zalet˛e jednostki zarzadzaj ˛ acej, ˛ tj. „domeny“ widać, jak na dłoni. Aby użytkownicy mogli korzystać z lokalnych zasobów albo zasobów znajdujacych ˛ si˛e w systemach sieciowych, nie trzeba w każdym systemie zakładać konta użytkownika, lecz wystarczy tylko założenie konta użytkownika w SAM domeny. Ochrona zasobów, autoryzacja, realizowana jest oddzielnie na tych systemach, które je udost˛epniaja.˛ Użytkownicy korzystajacy ˛ z Windows 9x, również moga˛ logować si˛e do domeny i tym samym wykorzystywać zasoby sieciowe bez konieczności dodatkowego logowania. 3.4.2.2 Wiele domen i relacje zaufania Istnieje możliwość łaczenia ˛ ze soba˛ wielu domen poprzez tzw. relacje zaufania. Dzi˛eki nim możliwa jest autoryzacja dost˛epu do zasobów (np. File Services) takich użytkowników albo grup, którzy pochodza˛ z innych domen. Głównym celem jest zatem uzyskanie dost˛epu do zasobów ponad granicami domen. Relacja zaufania pomi˛edzy domenami NT nie musi być dwukierunkowa (bidirektional); gdy domena A ufa domenie B, to B nie musi ufać A. Relacje zaufanie nie sa˛ również przechodnie: gdy A ufa B i B ufa C, wtedy A nie musi automatycznie ufać C. Jak widać każda relacja zaufania musi być ustawiana osobno. Poniższe okoliczności doprowadziły do ukształtowania si˛e sytemu wielu domen w środowiskach informatycznych: ◦ Cz˛esto powstawały równoległe rozwiazania ˛ - wysepki, wewnatrz ˛ jednej infrastruktury, które później, wskutek wspólnych procesów roboczych, trzeba było łaczyć ˛ za pomoca˛ relacji zaufania. Dotyczy to także sytuacji, w której trzeba połaczyć ˛ dwie infrastruktury. ◦ Granice domen sa˛ granicami bezpieczeństwa: administratorzy domeny A nie sa˛ automatycznie administratorami domeny B, której si˛e ufa albo która komuś ufa. Lepsza polityka nie odgrywa tu żadnej roli. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 116 ◦ Możliwość delegowania zadań, która nie ma zalet, została skompensowana przez zastosowanie wielu domen. ◦ Ilość obiektów (komputery, użytkownicy, grupy) w SAM jest ograniczona gdyż SAM przechowywane sa˛ podczas pracy w Registry kontrolerów domeny, których wielkość także jest ograniczona. Jedynym sposobem obejścia powyższego ograniczenia jest rozproszenie obiektów pomi˛edzy wiele domen. ◦ Skalowanie domeny w silnie rozproszonych, zdecentralizowanych środowiskach ograniczone jest przez Single Master z PDC, ponieważ wszystkie zmiany w SAM moga˛ być realizowane tylko przez niego. Powyższe fakty doprowadziły do powstania różnych modeli domen, które mi˛edzy innymi zaproponował sam Microsoft: ◦ Single Domain (jedna domena) ◦ Master Domain (wiele domen, z których każda 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 (każda domena ufa innym domenom) 3.4.2.3 NT jako usługa katalogowa W szerokim sensie domeny Windows NT sa˛ również usługami katalogowymi, ponieważ obiekty użytkownika zapisane sa˛ w jednej domenie. Microsoft nazwał taki system NTDS (Windows NT Directory Service). Ilość atrybutów obiektu użytkownika w domenie NT jest wzgl˛ednie mała i ogranicza si˛e raczej do atrybutów oraz właściwości ważnych z technicznego punktu widzenia. Z tego powodu atrybutów tych nie można porównywać z usługa˛ katalogowa˛ w oparciu o X.500. Właściwości użytkownika obejmuja˛ mi˛edzy innymi: ◦ nazw˛e użytkownika (SAM-Accountname) ◦ pełna˛ nazw˛e i opis (nieważne z technicznego punktu widzenia) ◦ informacj˛e o koncie (np. konto dezaktywowane, hasło nigdy nie wygasa, termin wygaśni˛ecia konta, typ konta) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 117 ◦ członkostwa grup ◦ parametry środowiska (skrypty logowania, katalog domowy, ścieżka profilu 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 zdefiniowane atrybuty nie jest przewidziane. Microsoft wprowadzajac ˛ „Windows NT 4 Server Terminal Edition“ oraz Citrix Metaframe sam zaimplementował dodatkowe właściwości dla obiektu użytkownika (dodatkowe home paths i profile paths oraz inne parametry Citrix). NTDS nie może mieć struktury hierarchicznej. Nadawanie uprawnień na poziomie atrybutów nie jest możliwe, a elastyczne nadawanie uprawnień obiektom użytkownika jest mocno ograniczone. 3.4.2.4 Delegation Przydzielanie zadań 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 Powyższe restrykcje, wzgl˛ednie wady, zapewne doprowadziły do tego, że przydzielanie ról oraz ich istniejacy ˛ podział odwzorowane sa˛ na aplikacjach opartych na sieci WWW. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.4.2.5 118 Podstawy sieci Domena Windows NT może opierać si˛e na nast˛epujacych ˛ protokołach transportu ◦ TCP / IP ◦ NetBEUI ◦ SPX / IPX. W każdym przypadku wymagany jest interfejs NetBIOS. W sieciach TCP / IP, które dla potrzeb niniejszego poradnika określiliśmy jako standardowe, do zapewnienia bezbł˛ednej komunikacji konieczne jest przekształcanie nazw NetBIOS (nazwa komputera oraz nazwy użytkowników i nazwy innego typu, takie jak grupa robocza). Jeśli, np. użytkownik chce zmienić swoje hasło w domenie, to musi on znać położenie PDC badź ˛ swój adres IP. Przekształcanie nazw NetBIOS może być realizowana w sieciach windowsowych na różne 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 umożliwia realizacj˛e przekształcanie nazw przez podsieci IP, dynamiczne zawartości i minimalizacj˛e Broadcasts. Usługa WINS jest cz˛esto realizowana na kontrolerach domeny. W sieciach windowsowych zaimplementowana jest usługa wyszukiwania komputerów (Browse Service) niezależnie od wybranego protokołu transportu. Teoretycznie może ona połaczyć ˛ (home) wszystkie systemy operacyjne typu Windows. Usługa ta umożliwia przesłanie klientowi wysyłajacemu ˛ pytanie (np. za pomoca˛ polecenia „net view“) list˛e aktywnych komputerów znajdujacych ˛ si˛e w sieci. Jeśli ma ona obejmować także komputery z podsieci IP, wówczas powyższa usługa musi mieć dost˛ep do informacji z „Domain Master Browser“ w sieci lokalnej, co jest możliwe po zastosowaniu WINS. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.4.2.6 119 Replikacja plików Kontrolery domen (PDC, jak też BDCs) udost˛epniaja˛ skrypty logowania i ustawienia systemowe w postaci zasobu NETLOGON, które sa˛ odpytywane przez logujacych ˛ si˛e użytkowników. Aby użytkownik mógł otrzymać za każdym razem te same warunki, zawartość w/w zasobu powinna być jednakowa dla wszystkich kontrolerów domen w domenie. W tym celu serwery musza˛ wymieniać si˛e informacjami. Tak zwana usługa katalogowej replikacji (LMRepl) zapewnia replikowanie zawartości serwerów eksportujacych ˛ do serwerów importujacych. ˛ Zmiany zawartości moga˛ być przeprowadzane tylko na serwerze eksportujacym. ˛ 3.4.2.7 Narz˛edzia administracyjne Do administrowania obiektami użytkownika, grupami i komputerami, w Windows NT 4 udost˛epniane sa˛ programy graficzne takie jak menedżer użytkownika menedżer serwera. Ponadto wraz z „NT Resource Kit“ dostarczane sa˛ narz˛edzia, które przeważnie można uruchamiać z linii poleceń i z pomoca˛ których można stworzyć skrypty służace ˛ do automatycznej administrowania. Ponadto istnieje możliwość zarzadzania ˛ domena˛ także poprzez interfejs WWW. Konieczne do tego jest zastosowanie Internet Information Servers (IIS) firmy Microsoft. Pewne braki odpowiednio wygodnych narz˛edzi zainspirowały innych producentów do zaprojektowania własnych narz˛edzi. Przede wszystkim korzystaja˛ one z APIs dostarczanych przez Windows NT. Sam Microsoft później wyprodukował jeszcze Microsoft Management Console (MMC), która została ostatecznie właczona ˛ do Windows 2000. Także później Microsoft dostarczył wraz z ADSI (Active Directory Service Interface) interfejs oparty o COM, za pomoca˛ którego można administrować również domenami Windows NT. 3.4.2.8 Zapisywanie haseł Hasła użytkownika (także komputerów) zapisywane sa˛ w jednej domenie w SAM kontrolerów domeny. Zapisywane hasło nie jest zapisywane otwartym tekstem, lecz jako wartość hash. W Windows NT można dodatkowo również szyfrować SAM (SYSKEY.EXE). Wartości hash haseł tworzone sa˛ różnymi metodami, które rozwin˛eły si˛e zgodnie z poniższym opisem: ◦ LM (LAN Manager) ◦ NTLM ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 120 ◦ NTLMv2 Na systemach NT, które nie sa˛ kontrolerem domen, informacje o użytkownikach logujacych ˛ si˛e na końcu sa˛ tymczasowo zapisywane do katalogu, co ma umożliwić logowanie także wtedy, gdy kontroler domen nie jest dost˛epny (typowe dla notebooków). Informacje te sa˛ nast˛epnie ponownie zapisywane jako wartość hash. 3.4.2.9 Mechanizm autoryzacji Autoryzacja w obr˛ebie środowiska domen NT opiera si˛e na mechanizmie NTLM. Ocenialiśmy nast˛epujacy ˛ scenariusz. Domena zasobów ufa domenie kont. Istnieje działajace ˛ środowisko WINS. Użytkownik uruchamia stacj˛e robocza˛ Windows NT, która jest członkiem domeny zasobów. Nast˛epnie loguje si˛e do domeny kont. Powyższy scenariusz zilustrowany został 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 list˛e kontrolerów domen (DCs) domeny zasobów. Jako pierwsze wysyłane jest, poprzez Broadcast, zapytanie Netlogon-Request. Jeśli DC domen zasobów nie odpowie, wówczas Netlogon-Request wysyłane jest do DCs wspomnianej listy. Z pierwszym DC, który odpowiedział, nast˛epuje weryfikacja informacji logowania poprzez tak zwany „Secure Channel“. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 122 Na końcu maszyna NT wysyła pytanie do DC domeny zasobów o list˛e zaufanych domen. Po wybraniu przez użytkownika domeny kont z maski logowania oraz podaniu przez niego swojego identyfikatora i hasła, uruchamiany jest proces logowania konta użytkownika. Klient NT wysyła informacje logowania do tak zwanej weryfikacji „pass-through validation“ na DC domeny zasobów, który udost˛epnia maszynie Secure Channel. DC domeny zasobów wysyła zapytanie do DC domeny kont (najpierw lokalne, nast˛epnie ukierunkowane poprzez Secure Channel). Zweryfikowane informacje logowania zwracane sa˛ poprzez DC domeny zasobów do klienta NT. Nast˛epnie klient otwiera bezpośrednie połaczenie ˛ z DC domeny kont, aby załadować skrypt logowania, ustawienia systemowe albo profil użytkownika. Jako uzupełnienie należy jeszcze ocenić nast˛epujacy ˛ proces logowania. Gdy użytkownik ła˛ czy si˛e z zasobami (np. składowanie plików jako zasób serwera plików, np. net use), serwer plików musi sprawdzić informacje logowania kontaktujac ˛ si˛e ponownie z kontrolerami domen. 3.4.2.10 Single Sign On Rozwiazanie ˛ oparte o domeny zastosowane w Windows NT umożliwia coś w rodzaju Single Sign On (jednorazowe logowanie) w ramach palety produktów Microsoft. Użytkownik loguje si˛e jeden raz na swojej stacji roboczej z Windows NT i nast˛epnie uzyskuje dost˛ep, o ile zasoby badź ˛ systemy serwera sa˛ członkiem własnej albo zaufanej domeny, do nast˛epujacych ˛ usług: ◦ File Services oraz Print Services ◦ Exchange ◦ SQL ◦ Intranet (Web, Internet Information Server) . Inni producenci oprogramowania moga˛ implementować swoje produkty w taki sposób, że zachowana zostanie możliwość jednorazowego logowania. Z reguły jednak musza˛ oni udost˛epniać swoje aplikacje na serwerach Windows NT4, które sa˛ członkami domeny. 3.4.2.11 Wytyczne W domenach Windows NT można zrezygnować z wytycznych mówiacych ˛ o tym, ◦ jak obchodzić si˛e z hasłami (czas ważności, minimalna długość, powtarzane, bł˛edne wprowadzenie hasła) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 123 ◦ jakie przywileje (uprawnienia użytkownika) powinni posiadać użytkownicy lub grupy (zmiana czasu systemowego, lokalne logowanie, etc.) 3.4.2.12 Auditing W domenach Windows NT można właczyć ˛ Auditing (kontrol˛e) uzyskanego dost˛epu, wzgl˛ednie podj˛etych prób uzyskania dost˛epu. W ten sposób można nadzorować, np. ◦ logowanie i wylogowywanie si˛e ◦ korzystanie z uprawnień użytkownika ◦ administrowanie użytkownikami i grupami ◦ zmiany wytycznych bezpieczeństwa . 3.4.2.13 Smart Card (mocne mechanizmy autoryzacji) Dla Windows NT 4 oraz Windows 9x ukazały si˛e tak zwane „Smart Card Base Components“, z pomoca˛ których inni producenci moga˛ tworzyć aplikacje windowsowe z obsługa˛ Smart Card. Rozwiazania ˛ umożliwiajace ˛ mocna˛ autoryzacj˛e oferowane sa˛ przez innych producentów. 3.4.3 Migracja zast˛epujaca ˛ - Linux, Samba i OpenLDAP Przy ocenianiu migracji zast˛epujacej ˛ należy uwzgl˛ednić przede wszystkim także wymagania co do sposobu autoryzacji w środowiskach mieszanych złożonych z systemów Linux i Windows. W zwiazku ˛ z tym na pierwszy plan wysuwa si˛e oczywiście wykorzystanie usługi katalogowej, także w aspekcie Active Directory poczawszy ˛ od Windows 2000. Poza tym kombinacja Linuksa, Samby i OpenLDAP obroniła si˛e jako metoda autoryzacji już wielokrotnie, na długo przed powstaniem Active Directory. Dlatego przejrzysta, oddzielna ocena usługi katalogowej jako usługi integrujacej ˛ i jako cz˛eści usługi autoryzacji jest prawie niemożliwa. (Obszerna informacja na ten temat znajduje si˛e w rozdziale 3.7). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.4.3.1 124 Autoryzacja z wykorzystaniem Linux / OpenLDAP i Samby Samba zapewnia klientom windowsowym podobna˛ funkcjonalność jak główny kontroler domen oparty na Windows NT (m.in. File Services, Print Services oraz usługi autoryzacji). Samba, jako baza danych kont użytkowników, może przy tym odwoływać si˛e do OpenLDAP świadczacej ˛ usługi katalogowe. W tym wzgl˛edzie połaczenie ˛ Samba / OpenLDAP stanowi odpowiednik kombinacji domen Windows NT oraz Active Directory. W obydwu przypadkach klient windowsowy widzi domen˛e NT. Jednak jeśliby spojrzeć pod katem ˛ administrowania informacjami o użytkownikach, grupach i hostach, chodzi o kompletne rozwiazanie ˛ oparte na usłudze katalogowej wraz ze wszystkimi wynikajacymi ˛ z tego zaletami. W szczególności w przypadku rozwiazania ˛ opartego o Samb˛e i OpenLDAP przestaje istnieć, znany z Windows NT, problem skalowalności, który cz˛esto wymaga podziału infrastruktury pomi˛edzy różne 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 nast˛epuje poprzez protokół NTLM. Dlatego w katalogu musza˛ być zapisane te same zaszyfrowane hasła, jak w bazie danych SAM w Windows NT/2000/2003. Dzi˛eki temu jakościowemu ograniczeniu (brak autoryzacji Kerberos dla klientów Windows 2000 / XP) możliwe jest zbudowanie pełnowartościowej usługi autoryzacji dla klientów windowsowych w oparciu o Linuksa, OpenLDAP i Samb˛e. Problemem wydaje si˛e tu być używanie przez Linuksa innego algorytmu do szyfrowania haseł niż 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 żaden problem, ponieważ istnieje możliwość takiego skonfigurowania Samby, żeby podczas zmiany hasła przez klienta windowsowego, automatycznie zmieniane była także hasło uniksowe. Powyższa zasada obowiazuje ˛ także w odwrotnym kierunku, tzn. za pomoca˛ mechanizmu PAM (Pluggable Authentication Module) istnieje możliwość takiego ustawienia programów uniksowych, żeby mogły one zmieniać hasło w Windows, gdy tylko zmieniane jest ono dla programu uniksowego. Dzi˛eki prawidłowej konfiguracji synchronizacja hasła nie stanowi problemu. Ponadto autoryzacja usług opartych na Uniksie może być realizowana, podobnie jak w przypadku Active Directory, poprzez Kerberos. Służa˛ do tego dwie równorz˛edne implementuje Kerberos dla Linuksa, tj. „MIT Kerberos“ oraz „Heimdal“. Również w przypadku korzystania z Kerberos synchronizacj˛e hasła można zagwarantować za pomoca˛ wyżej wymienionych mechani- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 125 zmów. (Podobna metoda synchronizacji hasła musi być także wykorzystywana wewnatrz ˛ Active Directory, aby zagwarantować 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. Można je ustawiać zarówno pomi˛edzy domenami Windows i Samby, jak też pomi˛edzy dwiema domenami opartymi na Sambie. 3.4.3.4 WINS Samba ma wbudowana˛ usług˛e WINS. Wraz z Samba˛ 3.0 dostarczany jest program służacy ˛ do replikacji WINS. Program ten nie został jednak na razie wystarczajaco ˛ przetestowany. 3.4.3.5 Ograniczenia w stosowaniu OpenLDAP i Samby Jak już wspomnieliśmy, Samba odpowiada, z punktu widzenia klienta windowsowego, serwerowi opartemu na Windows NT. Oznacza to, że nie obsługuje ona nowych właściwości zwiaza˛ nych z administrowaniem klientami windowsowymi, które zostały wprowadzone wraz z Active Directory. W szczególności brak jest obsługi dla Group Policy Objects (GPOs) i wymiana oprogramowania poprzez Active Directory. W praktyce jednak wystarcza zast˛epowanie tych Features innymi technikami. GPOs Samba obsługuje tak zwane System Policies, dzi˛eki którym możliwe jest definiowanie ustawień rejestrów dla użytkownika, grup użytkowników i komputerów klientów. Poprzez System Policies można również zadać wi˛ekszość ustawień dost˛epnych za pomoca˛ GPOs (ograniczenia funkcji interfejsu użytkownika Windows, wybór programów wykonywalnych, itd.). Dzi˛eki narz˛edziu „editreg“ dostarczanemu wraz z Samba˛ możliwe jest dynamiczne definiowanie ustawień systemowych. Ponadto w środowisku opartym na Sambie można używać lokalnych Policies, które zasadniczo umożliwiaja˛ uzyskanie takich samych ustawień, jak z GPOs. Ponieważ lokalne Policies składowane sa˛ po prostu w systemie plików, można je, po stworzeniu prototypu, w łatwy sposób zsynchronizować z duża˛ ilościa˛ klientów. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 126 Wymiana oprogramowania Funkcje oferowane przez Active Directory, a umożliwiajace ˛ wymian˛e oprogramowania ograniczaja˛ si˛e do programów, które dost˛epne sa˛ w formie pakietów MSI. W praktyce wybierane jest najcz˛eściej rozwiazanie ˛ polegajace ˛ na szerokiej wymianie oprogramowania. W tym celu można skorzystać z całego szeregu rozwiazań ˛ komercyjnych, które działaja˛ również bez Active Directory, a nawet cz˛esto wykorzystuja˛ Linuksa, jako podstawowy system operacyjny. Samba obsługuje profile oparte na serwerze. Dzi˛eki temu możliwe jest ustawienie także profilów obowiazkowych, ˛ za pomoca˛ których można zdefiniować konfiguracj˛e interfejsu użytkownika oraz przypisać aplikacje poszczególnym użytkownikom. Za pomoca˛ skryptów logowania, na klientach windowsowych można zdefiniować cały szereg innych ustawień, np. dla hostów, grup oraz użytkowników. 3.4.3.6 Kombinacja OpenLDAP i Active Directory Tam, gdzie nie można zrezygnować z Features oferowanych przez Active Directory, istnieje możliwość replikacji danych użytkowników i grup z OpenLDAP do Active Directory. Użytkownikami i grupami trzeba wówczas nadal zajmować si˛e w katalogu OpenLDAP, ale można z nich korzystać także w ramach Active Directory, co sprawia, że wykorzystywane moga˛ być odpowiednie właściwości (takie jak GPOs) przy jednoczesnym administrowaniu z jednego miejsca (Single - Point - of - Administration). Windows może być przy tym skonfigurowany w taki sposób, żeby dla obu cz˛eści środowiska wykorzystywany był wspólny (oparty na Linuksie) serwer Kerberos. Wiaże ˛ si˛e to jednak z ograniczeniami, które polegaja˛ na tym, że nie b˛edzie już możliwa autoryzacja przez Active Directory / Kerberos systemów opartych na Windows 94/98/NT. 3.4.3.7 Narz˛edzia umożliwiajace ˛ migracj˛e z Windows NT do Samby / OpenLDAP Za pomoca˛ narz˛edzi, w które wyposażona jest Samba, możliwe jest sczytanie bazy danych użytkowników dost˛epnego, opartego na Windows, kontrolera domen i zapisanie jej do katalogu OpenLDAP. Dzi˛eki takiemu post˛epowaniu migracja może być całkowicie przejrzysta dla użytkowników oraz systemów klienckich; nie ma konieczności wprowadzania klientów od nowa do tworzonej domeny, a użytkownicy moga˛ nadal używać wykorzystywana˛ w NT par˛e login / hasło. Podczas migracji należy najpierw usunać ˛ wszystkie usługi z kontrolerów domen, za wyjatkiem ˛ autoryzacji i przejść na Member-Servers. W nast˛epnym kroku można wykonać migracj˛e kontrolerów domen opartych na Windows NT na Samb˛e / OpenLDAP. W czasie migracji można dalej używać windowsowych Member-Servers, teraz już w domenie opartej na rozwiaza˛ niu Samba / OpenLDAP i powoli przechodzić na Samb˛e. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.4.3.8 127 PDC i BDCs w jednej domenie Samby Aby zachować kompatybilność z domenami Windows NT, Samba obsługuje także PDC i BDCs. Jednak obsługa powyższych ogranicza si˛e do tego, że serwer Samba widziany jest przez klientów windowsowych, w zależności od konfiguracji, jako PDC badź ˛ BDC. Sam Samba nie obsługuje replikacji bazy danych SAM pomi˛edzy PDC i BDC. Jednakże ze wzgl˛edu na zapisywanie SAM w katalogu LDAP, replikacja SAM może być realizowana przez OpenLDAP. Serwer Samba skonfigurowany jako PDC posiada przy tym zazwyczaj prawo do zapisu na OpenLDAP-MasterServer, dzi˛eki czemu może on zmieniać wpisy w bazie danych użytkowników. BDCs należy skonfigurować w taki sposób, żeby ich dost˛ep do OpenLDAP-Slave-Server, który na ogół działa na tym samym komputerze, co Samba-BDC, ograniczał si˛e tylko do prawa do odczytu. Jeśli w takiej sytuacji, poprzez PDC zainicjowana zostanie zmiana wpisów w bazie danych SAM, wówczas PDC zapisze t˛e zmian˛e do katalogu LDAP. Stamtad ˛ zostanie ona przesłana, po replikacji LDAP, do BDCs, dzi˛eki czemu także one b˛eda˛ mogły korzystać ze zmienionej bazy danych. Ponadto w domenie Windows NT synchronicznie przechowywana jest zawartość NetlogonShares (na którym znajduja˛ si˛e m.in. Policies i skrypty logowania). W Linuksie można to zrealizować, np. za pomoca˛ programu rsync. 3.4.3.9 Samba jako członek domeny Active Directory Oprócz tego Samba jest w stanie używać do autoryzacji, tzw. Kerberos-Tickets serwera Active Directory. Oznacza to, że Samba, jako pełnowartościowy Member-Server, może być stosowana w domenach AD. 3.4.3.10 Narz˛edzia administracyjne Użytkownikami i grupami w domenie opartej na systemie Samba / OpenLDAP można administrować za pomoca˛ narz˛edzi dostarczanych przez Windows NT (usrmgr.exe). Jednak w takim przypadku nie można wykorzystać wszystkich szczególnych zalet rozwiazania ˛ opartego na usłudze katalogowej (np. różnych poziomów uprawnień, zagnieżdżonej struktury katalogów), ponieważ nie sa˛ one obsługiwane przez Features z Windows NT. Narz˛edzia do zarzadzania ˛ OpenLDAP 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 Jeśli chodzi o usług˛e logowania, nie można przyjać, ˛ że Windows 2000 jest jedynie „aktualizacja“ ˛ systemu operacyjnego. Obszerny i skomplikowany jest tu nie tylko proces aktualizacji, wzgl˛ednie instalacji, lecz mamy w tym przypadku do czynienia także z zasadnicza˛ zmiana˛ architektury w postaci „Active Directory Service“. W tym miejscu poradnika postanowiliśmy nie przedstawiać usługi logowania z Windows 2000 jako osobnego tematu bez uwzgl˛ednienia Active Directory oraz usługi katalogowej. Podobne problemy wyst˛epuja,˛ jeśli chodzi o jasne rozgraniczenie Active Directory jako usługi infrastrukturalnej od Active Directory jako składnika usługi autoryzacji. W zwiazku ˛ z tym postanowiliśmy odesłać czytelnika do rozdziału 3.7.5, w którym opisaliśmy nast˛epc˛e Windows 2000, tj. Windows Server 2003. 3.5 Usługi sieciowe 3.5.1 Przeglad ˛ W wyniku przedstawionych poniżej, szczegółowych ocen technicznych, doszliśmy do wniosku, że w przypadku w/w usług nie ma problemów z przeprowadzeniem migracji. Nie należy si˛e ich spodziewać ani w środowisku systemów mieszanych, ani też w środowisku homogenicznym (całkowita „zast˛epujaca ˛ migracja“ lub migracja kontynuacyjna). 3.5.2 Punkt wyjścia - usługi sieciowe pod Windows NT W niniejszym podrozdziale przeanalizowaliśmy nast˛epujace ˛ usługi sieciowe: ◦ WINS ◦ DNS ◦ DHCP Tam, gdzie było to konieczne zaakcentowaliśmy różnice pomi˛edzy serwerami, a klientami. W szerszym sensie do usług sieciowych można zaliczyć także poniższe 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 zamieściliśmy poniżej krótka˛ analiz˛e nowości 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˛ można zainstalować w systemie operacyjnym Windows NT 4 Server. WINS jest usługa˛ zgodna˛ z RFC, umożliwiajac ˛ a˛ przekształcanie nazw NetBIOS na adres IP i jednocześnie serwerem, który za pomoca˛ ◦ Broadcast oraz ◦ lokalnie zapisanego pliku LMHOSTS sprawia, że przekształcanie nazw staje si˛e zb˛edne. WINS umożliwia tym samym przekształcanie nazw NetBIOS poprzez podsieci IP na zewnatrz. ˛ WINS można używać zarówno dynamicznie, jak i statycznie. Pierwszy sposób oznacza, że klienty WINS moga˛ si˛e same dynamicznie dopisywać. Metoda statyczna polega na tym, że administratorzy musza˛ wpisywać nazwy oraz adresy IP każdego z nich r˛ecznie. WINS zapisuje swoje dane w bazie danych (Jet - Engine, wins.mdb), której zawartość może ze soba˛ synchronizować wiele serwerów WINS. W tym celu serwery WINS należy skonfigurować jako tzw. „Push - Partner“ i / lub Pull - Partner“. Zawartość zapisywana jest zgodnie z zasada˛ Multi-Master, co oznacza, że każdy serwer WINS może dokonywać wpisów. Dodatkowo istnieje możliwość zastosowania WINS-Proxy. Komputer, który pełni rol˛e WINSProxy, sam nie obsługuje bazy danych, lecz przyjmuje zapytania od klientów i przekazuje je do pełnowartościowego serwera WINS. Wszystkie dotychczasowe systemy operacyjne Windows (Windows 9x do Windows XP oraz wszystkie serwerowe systemy operacyjne) moga˛ być klientami WINS. Samego klienta WINS ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 130 można skonfigurować na podstawie jego, tzw. typu w˛ezła, tak by wiedział czy i jak powinien przekształcać nazwy NetBIOS. Przestrzeń nazw NetBIOS jest płaska i ogranicza si˛e tylko do nazw komputerów. Obejmuje ona także nazwy użytkowników, usługi, nazwy domen Windows albo windowsowych grup roboczych, etc. Poniższa tabela pokazuje przeglad ˛ typów nazw NetBIOS, które można identyfikować na podstawie 16 bajtowej nazwy NetBIOS. Należy rozróżnić nazwy jednoznaczne (unikalne) i nazwy grup. Te ostatnie moga˛ być używane jednocześnie przez wiele komputerów, jak i dodawane. Nast˛epujaca ˛ tabela przedstawia unikalne oznaczenia. 16 BAJTÓW OZNACZA JEDNOZNACZNIE <00> nazw˛e NetBIOS komputera. <03> usług˛e informacyjna˛ zarówno dla komputera, jak i zalogowanego użytkownika. <1B> Domain Master Browser (wyszukiwanie komputerów), która udost˛epniana jest przez PDC domeny. <06> usług˛e RAS (Remote Access Service) na komputerze. <1F> usług˛e NetDDE na komputerze. <20> komputer - serwer (szczególnie ważne w przypadku zasobów katalogowych). <21> komputer z klientem RAS. <BE> agenta monitorujacego ˛ sieć (network monitor agent). <BF> komputer z tak zwanym „network monitor utility“. Tablica 3.18: Unikalne oznaczenia nazw NetBIOS Nast˛epujaca ˛ tabela pokazuje cechy, które moga˛ być wykorzystywane przez wiele komputerów. 16 BAJTÓW <1C> OZNACZA WIELOWARTO ŚCIOWO nazw˛e domeny. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI <1D> nazw˛e Master Browser. <1E> zwyczajna˛ nazw˛e grup. <20> specjalna˛ nazw˛e grup (zwana˛ Internet group). 131 że zamiast jednych 16 bajtów, możliwe jest przyłaczenie ˛ „_MSBROWSE_,“ do nazwy domeny w celu wskazania domeny innym Master Browser. Tablica 3.20: Wielowartościowe oznaczenia nazw NetBIOS 3.5.2.2 Domain Name System (DNS) Domain Name System (DNS) jest usługa,˛ która˛ można zainstalować 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 umożliwia m.in. przekształcanie, wewnatrz ˛ hierarchicznej przestrzeni nazw, nazw komputerów na adres IP i odwrotnie (Reverse Lookup). Zastosowanie serwera DNS sprawia, że użycie lokalnych wpisów w pliku HOSTS staje si˛e zb˛edne. W hierarchii przestrzeni nazw można zorientować si˛e dzi˛eki znakowi rozdzielajacemu ˛ „.“ używanemu podczas zapisywaniu nazw. Tak zwana w pełni kwalifikowana nazwa (Fully Qualified Domain Name, FQDN) składa si˛e z dwóch cz˛eści. Pierwsza cz˛eść kończy si˛e na pierwszej kropce i oznacza nazw˛e hosta, a druga cz˛eść jest nazwa˛ DNS domeny. Przykład: komputer1.microsoft.com opisuje komputer o nazwie komputer1 w domenie microsoft.com. Nie ma wymogu, aby FQDN składała si˛e z trzech cz˛eści. Znaki, które można stosować w FQDN należa˛ do przedziału od a do z, A do Z oraz znak „–“. Ponieważ DNS jest standardem sieci Internet, nie wolno stosować dowolnych nazw domen. Domeny musza˛ być zarejestrowane w aktualnych narodowych i mi˛edzynarodowych rejestrach. Jednak, jeśli przestrzeń nazw DNS widoczna jest tylko wewnatrz ˛ własnej organizacji (przedsi˛ebiorstwa), wówczas można stosować także niezarejestrowane nazwy. Korzystać należy z takich zarejestrowanych nazw badź ˛ stref, które nie sa˛ wykorzystywane w Internecie. W ten sposób unika si˛e stosowania stref należacych ˛ do innych organizacji badź ˛ osób. DNS posiada mechanizmy, które umożliwiaja˛ partycjonowanie podstawowej bazy danych oraz dopasowanie jej do dzielonych środowisk. Z jednej strony przekształcanie nazw można ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 132 przypisać do konkretnych domen, a z drugiej poprzez utworzenie stref możliwe jest sterowanie replikacja˛ (transfer stref) oraz sterowanie administrowaniem. Implementacja w Windows NT 4 jest zgodna z BIND 4.9.4 w takim stopniu, że DNS pracuje wyłacznie ˛ statycznie (czyli nie obsługuje dynamicznych wpisów), a zmiany moga˛ być wprowadzane tylko na pierwszym serwerze strefy (zasada Single Master). Szczególna˛ cecha˛ implementacji DNS w Windows NT 4 jest to, że można sprawić, 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). Poniższa tabela pokazuje przeglad ˛ typów DNS Resource Record obsługiwanych w Windows NT. T YP WPISU K RÓTKI OPIS A wpis adresu (klasyczny wpis dla hosta, któremu trzeba przypisać adres IP) AFSDB specjalny wpis dla Andrew File System (AFS) CNAME alias (albo canonical name) HINFO ISDN specjalny wpis - informacje o osprz˛ecie odpowiednio do RFC 1700. wpis dla ISDN (Integrated Services Digital Network) w powiazaniu ˛ z typem RT (route through) MB, MG, specjalne wpisy dla skrzynek pocztowych, grup pocztowych MINFO, MR oraz dla informacji o skrzynkach pocztowych MX wpis dla mail routing via SMTP (Simple Message Transfer Protocol) NS wpis dla serwera DNS (name server) domeny DNS. PTR zarezerwowany adres (pointer resource record), który przekształca adres IP w adres hosta The route through resource record specifies 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˛ być 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˛ być klientem DNS. Systemy oparte na Windows 2000 i nowszych wersjach tego sytemu obsługuja˛ jako klienty także dynamiczny DNS (DDNS), który opisaliśmy w rozdziale 3.5.2.3. 3.5.2.3 Dynamic Host Configuration Protocol (DHCP) DHCP (Dynamic Host Configuration Protocol) jest standardem sieci Internet dla konfiguracji dynamicznego numeru IP komputerów albo innych urzadzeń ˛ TCP / IP (np. drukarek sieciowych). DHCP opiera si˛e 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 poniższej tabeli. Opcje zaznaczone tłustym drukiem obsługiwane sa˛ przez klientów DHCP do Windows NT 4. Nr Nazwa opcji 0 Pad 255 End 1 Subnet mask 2 Time offset 3 Router 4 Time server 5 Name servers Wyjaśnienie maska podsieci adres IP standardowego routera (gateway) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 6 DNS servers 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 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 134 adres IP serwera DNS sufiks DNS klienta ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 135 39 Keepalive garbage 40 NIS domain name 41 NIS servers 42 NTP servers 42 Vendor-specific information 44 WINS / NBT node type 45 NetBIOS over TCP / IP NBDD 46 WINS / NBT node type 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ł odświeżania 1 59 Rebinding (T2) time value interwał odświeżania 64 NIS + Domain Name 65 NIS + Servers 66 Boot Server Host Name 67 Bootfile Name 68 Mobile IP Home Agents adresy IP serwerów WINS typ w˛ezła klienta WINS Tablica 3.24: Opcje DHCP Oprócz tego istnieje możliwość użycia 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łnowartościowego serwera DHCP. 3.5.3 Migracja zast˛epujaca ˛ - usługi sieciowe pod Linuksem Usługi tworzace ˛ infrastruktur˛e sieci opartej na TCP / IP (DNS, DHCP, NTP, Routin, VPN, Filtering) można bez wyjatku ˛ realizować za pomoca˛ Wolnego Oprogramowania. Szeroka dost˛epność w/w usług w postaci OSS wynika z historii rozwoju Internetu, który b˛edac ˛ ogólnoświatowa˛ siecia˛ umożliwiajac ˛ a˛ wymian˛e danych odznacza si˛e tym, że wszystkie podłaczone ˛ do niej komputery rozmawiaja˛ tym samym j˛ezykiem. J˛ezyk ten składa si˛e z całej rodziny protokołów noszacych ˛ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 136 ogólna˛ nazw˛e TCP / IP. Aby komunikacja pomi˛edzy najróżniejszymi systemami mogła na całym świecie przebiegać bez problemów, konieczne jest zgodne „rozumienie j˛ezyka“. Aby uzyskać t˛e zgodność, wi˛ekszość standardów protokołów internetowych, które zostały formalnie zaakceptowane przez Internet Engineering Task Force (IETF), obsługiwana jest przez Open Source dzi˛eki implementacjom referencji. Opierajac ˛ si˛e na w/w referencjach wszyscy producenci moga,˛ niezależnie od siebie, rozwijać całkowicie kompatybilne oprogramowanie. Protokoły internetowe same sa˛ niezależne od producentów, b˛edac ˛ jednocześnie, zarówno w swoich definicjach, jak i w swoich implementacjach Open Source, otwartymi standardami. Ten szczególny charakter protokołów internetowych zadecydował o wyróżnieniu si˛e TCP / IP na tle, dost˛epnych w tym samym czasie na rynku, własnościowych protokołów sieciowych. Zachowanie otwartych standardów ma zasadnicze znaczenie także wtedy, gdy z powodu ograniczonej ilości stosowanych systemów możliwe jest, w sieci lokalnej, zorientowanie si˛e co do wymagań odnośnie kompatybilności. Szczególnie w przypadku zmian dokonywanych przez producenta, wzgl˛ednie rozszerzeń standardów, istnieje ciagła ˛ groźba „Vendor Lock-In“; z jednej strony przywiazanie ˛ do danego producenta staje si˛e uzależnieniem, a z drugiej strony punkt decyzyjny zwiazany ˛ z dalszym rozwojem oraz współpraca˛ z innymi systemami przechodzi, przynajmniej w obszarze obj˛etym zmianami, na producenta. Z tego powodu należy za każdym razem sprawdzać, czy rozszerzenie standardu przez producenta zapewni obiecane korzyści także w dłuższej perspektywie. Mimo, że istniejace ˛ od długiego czasu i sprawdzone implementacje referencji nie obsłuża˛ każdego Feature, oferuja˛ one gwarancj˛e trwałej kompatybilności ze wszystkimi systemami sieciowymi. 3.5.3.1 Domain Name System (DNS) Implementacja˛ referencji standardu Domain Name System zdefiniowanego w całym szeregu dokumentów RFC jest BIND (Berkeley Internet Name Domain), który jest stale rozwijany i utrzymywany niezależnie od producenta przez Internet Software Consortium. Aktualna˛ jego wersja˛ jest 9.2.x, przy czym nadal istnieje i jest utrzymywana przez ISC gałaź ˛ 8.3.x, która˛ wykorzystuje duża cz˛eść zainstalowanych serwerów DNS. Bind 9 obsługuje mi˛edzy innymi dynamiczny DNS (DDNS), DNSSEC oraz IPv6. Połaczenie ˛ BIND 9 z obcymi źródłami danych w celu zapewnienia informacji o strefach możliwe jest z jednej strony poprzez obszerny BackEnd Database Interface, a z drugiej strony istnieje dodatkowy, uproszczony interfejs (SDB), za pomoca˛ którego można realizować dost˛ep wyłacznie ˛ do odczytu w oparciu o bazy danych LDAP albo SQL. Jednak połaczenia ˛ te same w sobie nie sa˛ cz˛eścia˛ składowa˛ pakietu oprogramowania BIND. Istnieja˛ zatem, np. jeśli chodzi o ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 137 połaczenie ˛ LDAP, zarówno implementacje SDB, jak i predefiniowane klasy obiektów, za pomoca˛ których można realizować takie połaczenie. ˛ BIND z ISC może także pracować pod Windows NT / W2K. BIND obsługuje również dynamiczna˛ aktualizacj˛e Service - Records oraz może świadczyć odpowiednie usługi dla serwerów W2K. 3.5.3.2 Dynamic Host Configuration Protocol (DHCP) ISC rozwija i opiekuje si˛e także implementacjami referencji DHCP. Protokół i oprogramowanie maja˛ nast˛epujace ˛ zadania badź ˛ możliwości: ◦ automatyczne przydzielanie adresów IP i nazw komputerów klientom. DHCP zezwala zarówno na przydzielanie stałych adresów IP (na podstawie adresu MAC), jak też dynamiczne przydzielanie wolnego adresu z określonego zakresu adresów. ◦ automatyczne przekazywanie informacji o infrastrukturze sieci. Na przykład poprzez DHCP można centralnie zarzadzać ˛ i rozdzielać pomi˛edzy wszystkich klientów domen˛e nazw, serwer nazw, Default - Route oraz mask˛e sieci. ◦ Oprócz tego możliwe jest dostarczanie przez dhcpd dużej ilości zdefiniowanych na stałe, opcjonalnych pól oraz dajacych ˛ si˛e dowolnie definiować informacji dotyczacych ˛ konfiguracji hosta. DHCPD z ISC może, mi˛edzy innymi, przekazywać wszystkie opcje, które moga˛ być wykorzystane po stronie klientów windowsowych. ◦ Dodatkowo DHCPD może także pełnić rol˛e BOOTPD i przekazywać do klienta wszystkie informacje wymagane w przypadku bootowania poprzez sieć. W odniesieniu do wszystkich informacji wychodzacych ˛ dhcpd z ISC umożliwia zarówno administrowanie indywidualnymi klientami, jak też zbiorowa˛ konfiguracj˛e klas i podsieci. Ponadto w konfiguracji dhcpd z ISC możliwe jest warunkowe przekazywanie danych konfiguracyjnych hosta za pomoca˛ instrukcji IF. DHCPD może być stosowany w konfiguracji Failover zarówno dla Load - Balancing, jak i systemów wysokiej niezawodności (HA). Wtedy zarzadzane ˛ dynamicznie zakresy IP koordynowane sa˛ pomi˛edzy uzupełniajacymi ˛ si˛e wzajemnie serwerami. Konfiguracja DHCPD z ISC odbywa si˛e w tradycyjnym uniksowym stylu poprzez wykorzystanie pliku konfiguracyjnego w formacie ASCII. Istnieje łata, która umożliwia dynamiczne ściaganie ˛ konfiguracji serwera ISC - DHCP z repozytorium LDAP. Implementacja nast˛epuje zgodnie z IETF Draft opisujacym ˛ schemat LDAP dla DHCP. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.5.3.3 138 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˛ być świadczone zarówno w postaci klienta, jak też jako lokalna, albo domenowa Master Browser. Z drugiej zaś strony nmbd może, także jako WINS, koordynować przegladanie ˛ poza granicami segmentu sieci, które z reguły zwiazane ˛ sa˛ z routerami nie przepuszczajacymi ˛ Broadcasts. 3.5.3.4 Network Time Protocol (NTP) W przypadku wielu aplikacji sieciowych wymagany jest wysoki stopień synchronizacji. Używajac ˛ Network Time Protocol można zsynchronizować zegary komputerów w sieci lokalnej z dokładnościa˛ co do mikrosekund. W przypadku stałego połaczenia ˛ z Internetem istnieje możliwość synchronizacji czasu referencyjnego z urz˛edowym Normal z dokładnościa˛ liczona˛ w milisekundach. Alternatywnie, jako źródła odniesienia wskazujace ˛ czas Normal, moga˛ posłużyć także (mi˛edzy innymi) DCF77 i GPS. Implementacja referencji standardu jest stale rozwijana i utrzymywana w ramach Network Time Protocol Project. Oprogramowanie to można stosować także w Windows NT. 3.5.4 Migracja kontynuacyjna - usługi sieciowe pod Windows 2000 W nast˛epujacych ˛ podrozdziałach zamieściliśmy krótki opis nowości zwiazanych ˛ z usługami sieciowymi, które wprowadzone zostały wraz z Windows 2000. 3.5.4.1 WINS Windows 2000 nie oferuje nowości w architekturze WINS. Ulepszone zostało jedynie zarzadza˛ nie baza˛ danych WINS. 3.5.4.2 DNS Wraz z wprowadzeniem Windows 2000 najwi˛eksze zmiany dotkn˛eły usług˛e DNS. Główna˛ tego przyczyna˛ jest fakt, że Windows 2000 Active Directory wykorzystuje DNS do naczelnego przekształcania nazw badź ˛ inaczej mówiac, ˛ nie mógłby on działać bez DNS. Active Directory wykorzystuje DNS mi˛edzy innymi do odnajdywania usług logowania i wyszukiwania (LDAP Service, Global Catalog Service i Kerberos KDC). Aby móc zapisywać usługi, DNS musi obsługiwać ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 139 tak zwane SRV Records odpowiednio do standardu RFC 2052. Ponieważ dotychczasowy DNS działał statycznie (wpisy trzeba było wprowadzać r˛ecznie), w Windows 2000 ze wzgl˛edu na docelowa,˛ przyszła˛ rezygnacje z WINS, zaimplementowano rejestracj˛e dynamiczna; ˛ komputery moga˛ dynamicznie zapisywać swoje A i SRV Records. Powyższa implementacja jest nast˛epstwem RFC 2136 (Dynamic Update). Komputery z Windows 2000 i nowszymi moga˛ same si˛e rejestrować (jest to realizowane w kliencie DHCP). Windows NT i Windows 9x tego nie potrafia˛ i raczej potrzebuja˛ pomocy DHCP z Windows 2000. Dynamiczna rejestracja pociaga ˛ za soba˛ zmian˛e w architekturze dotychczasowej implementacji DNS, zgodnie z która˛ tylko (naczelny) serwer DNS może zapisywać zawartość stref. Microsoft realizuje zasad˛e Multi - Master poprzez obsług˛e 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 może być ograniczana za pomoca˛ mechanizmów bezpieczeństwa w taki sposób, że możliwa jest rejestracja tylko tych komputerów, które moga˛ si˛e autoryzować. (np. klienty Windows 2000 przynależnej 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 możliwa. 3.5.4.3 DHCP Jeśli chodzi o DHCP, Windows 2000 oferuje własne, godne uwagi, nowości. W Windows 2000 obsługiwane sa˛ aktualne RFCs 2131 (Dynamic Host Configuration Protocol, wcześniejszy RFC 1541) oraz 2132 (DHCP Options and BOOTP Vendor Extensions). Oprócz ulepszonego zarza˛ dzania obsługiwane sa˛ teraz także Multicast Scopes, opcje użytkownika i producenta DHCP, jak też dynamiczny BOOTP. Inna˛ nowościa˛ 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˛ konfiguracj˛e IP z Windows 2000 DHCP Server, serwer ten może przejać ˛ rejestracj˛e w DNS. Klient DHCP z Windows 2000 może, jeśli w jego podsieci znajduje si˛e serwer DHCP, samodzielnie skonfigurować swój IP. Używane 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 należy z góry zauważyć, że domyślne administrowanie odbywa si˛e w Windows NT w oparciu o dost˛epne tylko cz˛eściowo i bardzo niewyszukane narz˛edzia do zarzadzania ˛ systemem, co sprawia, że w wielu miejscach trzeba korzystać z oferujacych ˛ szerokie możliwości narz˛edzi dostarczanych przez innych producentów, które cz˛eściowo dost˛epne sa˛ także dla systemów linuksowych. W Linuksie istnieje, oprócz wielu programów wchodzacych ˛ w skład samego systemu takich jak cron / at, cały szereg produktów COLS oraz rozwiazań ˛ OSS przeznaczonych do administrowania systemem. Mamy tu do dyspozycji, np. program Nagios służacy ˛ do wizualizacji i kontroli usług. Jest to kompleksowy, wysoce zintegrowany system, za pomoca˛ którego można wykonać wszystkie systemowe zadania administracyjne. Obecnie program ten nie jest rozprowadzany jako OSS. Również Microsoft rozszerzył swoja˛ „skrzynk˛e z narz˛edziami“ oferowana˛ wraz z kolejnymi produktami. W tym miejscu należy wymienić Microsoft Operations Manager oraz Application Center. 3.6.2 Punkt wyjścia - serwery zarzadzaj ˛ ace ˛ systemem pod Windows NT 4 Systems Management Server (SMS) ukazał si˛e na rynku niedawno, wraz z Windows NT 4. Za ostatnia˛ wersj˛e SMS wywodzac ˛ a˛ si˛e z tej generacji należy uznać wersj˛e 1.2. W roku 1999 ukazała si˛e wersja 2.0. Zakres funkcji w/w wersji został przedstawiony poniżej. SMS integruje wiele podstawowych funkcjonalności, które dostarczane sa˛ również 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 korzystać 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 może być stosowany w dużych sieciach wraz z ponad 10.000 klientów. Ponieważ można go wpisać w windowsowa˛ struktur˛e domen, istnieje możliwość bardzo dokładnego dozowania uprawnień. SMS obsługuje także Novell Netware NDS oraz środowiska Bindery. SMS 2.0 zawiera funkcj˛e elektronicznego przydzielania oprogramowania, która wykonuje dalece automatyczna˛ instalacj˛e i deinstalacj˛e oprogramowania, bez potrzeby, w idealnym przypadku, wykonywania prac na miejscu, tzn. bez bł˛edów po stronie użytkownika. Proces przydzielania oprogramowania może przebiegać w oparciu o z góry ustalone reguły. Administratorzy definiuja˛ konfiguracj˛e oprogramowania poprzez dodawanie badź ˛ usuwanie komputerów, użytkowników albo grup użytkowników z list, zgodnie z wybranymi kryteriami. SMS protokołuje stan instalacji oprogramowania i aktualizacji systemu operacyjnego w taki sposób, że administratorzy systemu uzyskuja˛ informacj˛e, czy dane oprogramowanie zostało zainstalowane we właściwy sposób. SMS instaluje oprogramowanie automatycznie, bez udziału użytkownika, przy czym proces instalacji posiada prawa administratora także wtedy, gdy użytkownik komputera zalogowany jest z mniejszymi uprawnieniami. Komputery oparte na NT nie musza˛ być zalogowane, co sprawia, że Feature to nadaje si˛e do przydzielania oprogramowania poza regularnym czasem pracy. SMS umożliwia przydzielanie oprogramowania dowolnie wskazanym użytkownikom, grupom użytkownikó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 może te wytyczne stosować we wszystkich miejscach. Jeśli do grupy użytkowników dołacz ˛ a˛ nowi użytkownicy, wówczas w oparciu o wytyczna˛ danej grupy, automatycznie wysłane zostanie prawidłowe oprogramowanie. Tak zwane ustrukturyzowane przydzielanie pakietów uwzgl˛ednia topologi˛e sieci, co ma zapewnić wydajne przydzielanie oprogramowania w przypadku wolnych połaczeń. ˛ Serwery stacjonarne pełnia˛ w takim przypadku rol˛e routerów, które przydzielaja˛ oprogramowanie w sposób inteligentny i ustrukturyzowany. Dzi˛eki temu jeden proces przydzielania zawsze używa połaczenia ˛ WAN tylko raz. SMS 2.0 może rozsyłać oprogramowanie za pomoca˛ Courier Sender poprzez CD-ROM albo inne media. Gdy tylko użytkownik otrzyma dane medium (np. CD-ROM) i uruchomi je w systemie, zacznie si˛e zautomatyzowany proces. Tworzenie pakietów oprogramowania możliwe jest dzi˛eki załaczonemu ˛ programowi instalacyjnemu. Umożliwia 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 także log function. Instalator używa technologii shapshot. SMS 2.0 może przeprowadzać inwentaryzacj˛e osprz˛etu i oprogramowania. Podczas inwentaryzacji osprz˛etu opartej na CIM, SMS 2.0 zbiera dane w formacie CIM (Common Informa- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 142 tion Model), który umożliwia SMS dost˛ep do wielu różnych źródeł, w tym także do Microsoft Win32, SNMP i DMI. SMS zbiera obszerne dane inwentaryzacyjne, które można filtrować za pomoca˛ opcji. Inwentaryzacja oprogramowania zbiera dokładne informacje o każdej aplikacji na każdym komputerze. SMS 2.0 nie szuka w predefiniowanej bazie danych, lecz w każdym pliku wykonywalnym na komputerze klienckim według informacji o zasobach i wersjach. Dane inwentaryzacyjne moga˛ być wykorzystane jako podstawa dla przydzielania oprogramowania opartego na regułach. Zdalne sterowanie (Remote Control) umożliwia wykonywanie aplikacji na odległość, komunikowanie si˛e przez okna Chat z użytkownikami końcowymi, jak również ponowne uruchamianie komputerów. Ponadto możliwe jest sterowanie ekranem, klawiatura˛ i mysza.˛ SMS 2.0 może, jeśli chodzi o zarzadzanie ˛ siecia,˛ pełnić nast˛epujace ˛ zadania: ◦ za pomoca˛ SMS można wyświetlać i wizualizować topologi˛e sieci, klientów, jak też wykorzystywane systemy operacyjne. ◦ SMS tworzy podglad ˛ serwerów i urzadzeń ˛ 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 dost˛epu z Internetu. Monitor sieci może automatycznie interpretować znalezione wyniki. SMS 2.0 oferuje narz˛edzia do analizy, kontroli i sterowania aplikacjami na serwerach i stacjach roboczych (pomiar oprogramowania). Można przy tym w uporzadkowany ˛ sposób śledzić wykorzystanie oprogramowania według użytkowników, grupy, stacji roboczej, czasu albo ograniczeń licencyjnych. Dodatkowo można zdefiniować granice kontyngentów albo ustalić, z jakich aplikacji nie wolno korzystać. Ponadto można kontrolować przestrzeganie zasad przez każdego dowolnego klienta albo serwer. Programy służace ˛ do pomiaru oprogramowania wykrywaja˛ również różnice wersji i moga˛ stwierdzić, czy agenci klientów zostali dezaktywowani, co ma na celu zapewnienia szerokiej ochrony przed manipulacjami. Statystyki dotyczace ˛ wykorzystania oprogramowania moga˛ posłużyć do planowania licencjonowania oprogramowania i do obejmowania opłatami działów w zależności od wykorzystywanych w nich aplikacji (zarzadzanie ˛ licencyjne). Kontrola serwera odbywa si˛e za pomoca˛ HealthMon. HealthMon ustala dane nt. wydajności procesów działajacych ˛ na serwerach Windows NT i Microsoft BackOffice. Na konsoli HealthMon można wprowadzać krytyczne wartości progowe albo wartości progowe dla ostrzeżeń w celu uzyskiwania w czasie rzeczywistym, zdefiniowanych w oparciu o wyjatki, ˛ informacji o stanie, które można grupować 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 zast˛epujaca ˛ - Linux Zarzadzanie ˛ systemem w przypadku systemów operacyjnych OSS opiera si˛e na podstawowej funkcjonalności sieciowego sytemu operacyjnego skupiajacego ˛ wielu użytkowników. Administrator możne pracować z odległego miejsca na każdym komputerze z Linuksem albo BSD, oboj˛etnie czy b˛edzie to klient, czy serwer, w taki sam sposób, jak na lokalnym komputerze. Graficzny interfejs użytkownika, dzi˛eki jego systemowemu oddzieleniu od serwera (wyświetlacz, klawiatura i mysz) oraz oprogramowaniu klienckiemu, które prezentuje swoje okna i znaki na wyświetlaczu lokalnie albo na odległość poprzez połaczenie ˛ sieciowe oraz dzi˛eki przyjmowaniu danych z serwera, wspaniale nadaje si˛e także, mi˛edzy innymi, do zdalnej obsługi komputerów. Do tego dochodza˛ Secure Shell (ssh) i narz˛edzia z bogato wyposażonej „skrzynki z narz˛edziami“, takie jak cron / at do zarzadzania ˛ zadaniami w czasie oraz pot˛eżne interpretatory pracujace ˛ z linii poleceń, Utilities i interpretowane j˛ezyki programowania, które można wykorzystywać do zaawansowanego automatyzowania zadań routine. Aby zdalnie sterować systemami OSS nie jest wymagane dodatkowe oprogramowanie. Do scentralizowanego zarzadzania ˛ systemem w sieciach heterogenicznych, także w systemach OSS, można wykorzystywać dodatkowe składniki. Na górnym końcu skali można zintegrować Linuksa z systemem zarzadzania ˛ Tivoli albo OpenView. Pomi˛edzy powyższymi rozwia˛ zaniami, których nie zalicza si˛e do OSS, a prostym zarzadzaniem ˛ za pomoca˛ narz˛edzi należacych ˛ do sytemu operacyjnego istnieje duża ilość programów, które każdorazowo umożliwiaja˛ wykonywanie określonych zadań w systemie albo jego automatyzacj˛e. 3.6.3.1 Administrowanie oprogramowaniem Istnieja˛ komercyjne rozwiazania, ˛ oferowane przez różnych producentów, służace ˛ do inwentaryzacji, przydzielania i aktualizacji, jak również do zarzadzania ˛ konfiguracja˛ składników oprogramowania. Niektóre z tych rozwiazań ˛ przeznaczone sa˛ także dla heterogenicznych systemów z udziałem Windows. Jeśli chodzi o Wolne Oprogramowanie, nie istnieje gotowe do wykorzystania produkcyjnego, zintegrowane rozwiazanie, ˛ w szczególności dla środowisk heterogenicznych. Jednak za pomoca˛ narz˛edzi przeznaczonych do administrowania pakietami (RPM i APT) można w bardzo łatwy sposób scentralizować inwentaryzacj˛e oraz przydzielanie badź ˛ uaktualnianie oprogramowania. Do centralnego zarzadzania ˛ pakietami wspaniale nadaje si˛e zwłaszcza system zarzadzania ˛ pakietami Debiana, ponieważ pracuja˛ one w oparciu o hierarchi˛e z centralnych repozytoriów i dysponuja˛ bardzo mocnym systemem aktualizacji. W obszarze bezpieczeństwa, narz˛edziem, które należy stosować do inwentaryzacji i kontroli oprogramowania jest Tripwire. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.6.3.2 144 Administrowanie siecia˛ Jeśli chodzi o zarzadzanie ˛ sieciami TCP / IP, istnieje duży wybór programów o różnych punktach ci˛eżkości. Narz˛edzie do monitoringu „Nagios“ specjalizuje si˛e w wizualizacji topologii sieci i w kontroli usług, udost˛epnianych także na serwerach z innymi systemami operacyjnymi. Nagios reaguje, na znalezione bł˛edy albo zachodzace ˛ wydarzenia, w oparciu o zadane reguły, np. na podstawie zdefiniowanych wartości progowych. Możliwe jest przy tym zwi˛ekszanie ilości komunikatów i właczanie ˛ różnych kanałów informacyjnych (np. mail albo SMS). Nagios obsługuje Plug-Ins do aktywnej albo pasywnej kontroli najróżniejszych usług i parametrów systemu. Mi˛edzy innymi kontrolowane moga˛ być typowe usługi sieciowe takie jak Web, Mail i LDAP, różne RDBMS albo Samba. Ponadto istnieja˛ Plug - Ins umożliwiajace ˛ nadzór nad takimi parametrami systemu, jak obciażenie ˛ CPU, ilość wolnego miejsca na dysku, a także danymi z czujników (temperatura, zasilanie i liczba obrotów wentylatorów). Istnieja˛ mostki do innych systemów takich jak MRTG / RRD oraz umożliwiajace ˛ wykorzystanie SNMP do monitorowania. Programami wyspecjalizowanymi w monitoringu i analizie ruchu w sieci sa˛ MRTG / RRD. MRTG używa Simple Network Management Protocol do zbierania i zapisywania danych o ruchu z najróżniejszych składników sieciowych. Ich ocena i prezentacja graficzna może być realizowana wewn˛etrznie przez MRTG albo z zewnatrz ˛ za pomoca˛ RRD. MRTG ma do dyspozycji ponad 350 templates służacych ˛ do bezpośredniego łaczenia ˛ najróżniejszych, działajacych ˛ z SNMP składników i usług sieciowych. Innym narz˛edziem do analizy i wizualizacji ruchu jest NeTraMet, który również pracuje z SNMP. Scotty to kolejne narz˛edzie do wizualizacji i zarzadzania ˛ lokalnymi sieciami, pracujacym ˛ także z SNMP i także zezwalajacym ˛ na zmian˛e dost˛epnych parametrów SNMP dla odległych składników sieci. W wyszukiwaniu powtarzajacych ˛ si˛e wzorców, w ruchu sieciowym majacym ˛ na celu wykrycie prób włamania albo innych podejrzanych działań, wyspecjalizował si˛e Snort. Jako „Lightweight Intrusion Detection System“ jest on wartościowym składnikiem systemu zarzadzania ˛ siecia.˛ 3.6.3.3 Administrowanie serwerami Jeśli chodzi o administrowanie serwerami, do kontroli i ograniczania zasobów systemowych pojedynczych użytkowników lub procesów służ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˛ kontrol˛e całej infrastruktury Linux / BSD / UNIX. Także serwery windowsowe moga˛ zostać właczone ˛ w centralny system syslog. Do automatycznej oceny zawartości plików logowania wykorzystywanych jest wiele narz˛edzi i rozwiazań, ˛ zarówno opartych na aplikacjach, jak i generowanych. Ich analiza znajduje si˛e na stronie http://www.counterpane.com/log-analysis.html. Aby przy okazji zarzadzania ˛ serwerem zapewnić konieczne wyszukiwanie bł˛edów, należy skorzystać z narz˛edzi systemowych wykraczajacych ˛ poza regularne usługi protokołowe, a oferujacych ˛ duże możliwości analityczne, np. strace, lsof, fuser i netstat. 3.6.3.4 Systemy złożone W zakresie zarzadzania ˛ systemem istnieje oprócz Simple Network Management Protocol także Common Information Model (CIM) wraz z opartym na nim Web Based Enterprise Management (WBEM), które służa˛ do szerszych zastosowań podczas standardowego zarzadzania ˛ systemem w sieciach heterogenicznych. CIM / WBEM sa,˛ podobnie jak SNMP, opisane w otwartych standardach i dost˛epne w implementacjach referencji jako Wolne Oprogramowanie. Jednak składniki te wykorzystywane sa˛ obecnie raczej w ramach produktów komercyjnych. Praktyczna przydatność czystych rozwiazań ˛ Open Source w tym obszarze musi si˛e dopiero wykształcić. 3.6.3.5 Wnioski Jeśli chodzi o zarzadzanie ˛ systemem, systemy operacyjne OSS podażaj ˛ a˛ śladami swojego pierwowzoru, tj. Uniksa. Jako sieciowe systemy wielu użytkowników posiadaja˛ one bardzo różnorodne funkcje umożliwiajace ˛ centralne zarzadzanie ˛ systemem i w niektórych obszarach moga˛ być wzorem, a nie uzupełniajac ˛ a˛ alternatywa˛ dla rozwiazań ˛ windowsowych. Migracja oznacza także zmiany koncepcyjne dla administratorów i w organizacji pracy, które przyczynia˛ si˛e do zrobienia dużych post˛epów, w szczególności jeśli chodzi o bezpieczeństwo. Właśnie bezpieczeństwo i stabilne działanie sa˛ cechami charakterystycznymi dla ogólnie poj˛etych systemów linuksowych wynikajacymi ˛ także z systemu zarzadzania. ˛ Dla osób, którym powierzone zostanie wdrożenie projektu migracyjnego oznacza on wyraźne zmiany. Zarówno możliwości analizy, jak też opcje dostosowania i korekty systemów OSS daja˛ administratorom systemu o wiele wi˛ecej swobody, niż mieli oni w przypadku zamkni˛etego systemu Windows. Wolność t˛e można wykorzystać w celu uniezależnienia si˛e od producentów ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 146 i zewn˛etrznych świadczeniodawców oraz zarazem do podnoszenia kwalifikacji własnych pracowników. Przejrzystość otwartych systemów OSS ułatwia podstawowe i dogł˛ebne zrozumienie funkcji i zależności różnych 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 si˛e na oprogramowaniu firmy NetIQ i jeśli chodzi o kontrol˛e procesów, wydajności oraz zarzadzanie, ˛ pozwala on administrować systemami serwerowymi opartymi na Windows 2000. Obecna˛ wersja˛ Microsoft Operations Manager jest MOM 2000. Oferuje ona nast˛epujace ˛ funkcjonalności: MOM zbiera do centralnego repozytorium zdarzeń różnorodne informacje o procesach zwia˛ zanych z działaniem systemu oraz aplikacji pracujacych ˛ w dzielonym środowisku IT w systemach windowsowych. W ten sposób powstaje dzielone zarzadzanie ˛ procesami. Administratorzy moga˛ korzystać z przegladu ˛ wszystkich zdarzeń, co daje im wiedz˛e nt. dost˛epnych serwerów i usług. W MOM można tworzyć reguły. W oparciu o rozwini˛ete reguły system może automatycznie reagować na napływajace ˛ informacje. Dzieje si˛e tak dzi˛eki predefiniowanemu procesowi opartemu na specjalnym scenariuszu bł˛edów albo wskutek nastapienia ˛ konkretnego zdarzenia. Korzystajac ˛ z takich reguł MOM może reagować na określone wzorce wydarzeń i procesów, wzgl˛ednie wysyłać komunikaty ostrzegawcze zdefiniowane przez administratora. Każda˛ reguł˛e MOM można zdefiniować w taki sposób, by były generowane specjalne ostrzeżenia przyporzadkowane ˛ odpowiednim stopniom bezpieczeństwa. Ostrzeżenie może pojawić si˛e wskutek pojedynczego zdarzenia albo wielu zdarzeń pochodzacych ˛ z licznych źródeł. Administrator ma zawsze możliwość przeanalizowania przyczyn ostrzeżenia i odpowiednich zdarzeń. Ponadto możliwe jest wywoływanie ostrzeżeń, wiadomości e - mail, jak również Traps stron i Traps SNMP (Simple Network Management Protocol). Za pomoca˛ MOM można wprowadzić kontrol˛e wydajności przyłaczonych ˛ systemów. Dodatkowo można określić wartości progowe wydajności i je kontrolować. Poprzez dopasowanie lub dodanie reguł można, dla późniejszych referencji albo planowania pojemności, kontrolować rozwój wydajności systemu i aplikacji. Oprócz tego można ustawić lokalne i grupowe wartości progowe, które b˛eda˛ uruchamiać, w reakcji na zmiany wydajności systemu lub aplikacji, ostrzeżenia albo procesy wymagajace ˛ interwencji administratora. Portfolio usług, jakimi należy zarzadzać ˛ można rozszerzać za pomoca˛ Management Packs. Management Packs zawieraja˛ predefiniowane reguły MOM. Każdy pakiet oferuje reguły dla ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 147 określonych aplikacji lub usług. MOM standardowo zawiera Management Pack, za pomoca˛ którego można zarzadzać ˛ wszystkimi usługami windowsowymi, w tym także usługa˛ katalogowa˛ Active Directory oraz usługami informacyjnymi (Internet Information Services, ISS). Dost˛epne sa˛ również inne Management Packs firmy Microsoft i innych producentów. Microsoft oferuje Management Packs dla nast˛epujacych ˛ 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 możliwość przygotowania i przedstawienia zebranych danych w formie raportów. Narz˛edzie do tworzenia graficznych raportów umożliwia dost˛ep do wcześniej wygenerowanych raportów i diagramów. Daja˛ one administratorowi możliwość sprawdzania stanu systemów i usług w sieci. Za pomoca˛ Management Packs firmy Microsoft albo innych producentów możliwe jest dodanie do systemu dodatkowych raportów. Szczególna˛ cecha˛ MOM jest to, że może generować snapshots oparte na HTML dla wszystkich gotowych raportów. Migawki takie można nast˛epnie wyeksportować do serwera WWW, co pozwoli na dost˛ep do nich z poziomu przegla˛ darek WWW. Do instalacji konieczny jest Windows 2000. Zalecana˛ baza˛ danych jest MS SQL 2000, jednak można także skorzystać z MS Access. 3.6.4.2 Application Center Microsoft Application Center 2000 jest narz˛edziem do administrowania i udost˛epniania 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 ˛ Ponieważ usługa katalogowa nie jest, z punktu widzenia sytuacji wyjściowej, cz˛eścia˛ składowa˛ Windows NT, poniższe oceny nie koncentruja˛ si˛e na zastapieniu ˛ badź ˛ kontynuacji istniejacej ˛ usługi katalogowej. Mimo to usługa katalogowa odgrywa ważna˛ rol˛e, zarówno podczas migracji zast˛epujacej, ˛ jak i kontynuacyjnej. Wraz z migracja˛ do Windows 2000 oraz w szczególności w przypadku migracji do Exchange 2000, zastosowanie Active Directory jest niemalże wymuszone. Skorzystanie z usługi katalogowej podczas migracji zast˛epujacej ˛ - rozwiazaniem ˛ OSS b˛edzie tu OpenLDAP - niesie ze soba˛ wiele zalet, szczególnie jeśli chodzi o wygodna˛ realizacj˛e autoryzacji. W zwiazku ˛ z tym poniższa, techniczna ocena jest raczej spojrzeniem wybiegajacym ˛ w przyszłość i przedstawia szczególne cechy każdorazowego wprowadzenia usługi katalogowej, wzgl˛ednie możliwości jej wprowadzenia. Interesujacym ˛ aspektem tego spojrzenia sa: ˛ integracyjne oddziaływanie Active Directory (AD) oraz możliwość przeciwdziałania mu. Podsumowujac ˛ można stwierdzić, że z AD należy korzystać w minimalnym zakresie, o ile w ogóle nie można z niego zrezygnować. Wi˛eksze wymagania należy realizować korzystajac ˛ z innych produktów i rozwiazań, ˛ np. z Metadirectory. Ponadto jest to właściwy moment, by zastanowić si˛e, kiedy obejść AD i zastosować tryb natywny oraz by dokonać prawidłowego doboru ewentualnych opcji. 3.7.2 Podstawy Za pomoca˛ usługi katalogowej można udost˛epniać w sieci dowolne informacje. Usługa katalogowa składa si˛e zazwyczaj z bazy danych, w której zapisywane sa˛ informacje oraz z protokołu sieciowego, za pomoca˛ którego możliwe jest odpytywanie i zmiana informacji. Obecnie najcz˛eściej stosowanym protokołem usług katalogowych jest Lightweight Directory Access Protocol (LDA). LDAP został stworzony, aby w prosty sposób zapewnić dost˛ep do usług katalogowych opartych na X.500. Dzisiaj pod poj˛eciem serwera LDAP rozumie si˛e najcz˛eściej kombinacj˛e bazy danych i implementacji protokołu. LDAP w wersji 3 jest zdefiniowany 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˛ si˛e w obiektach, przy czym każdy obiekt posiada pewna˛ ilość atrybutów, których wartości reprezentuja˛ właściwe informacje. Każdy obiekt może zawierać jednocześnie podobiekty (wraz atrybutami), które moga˛ posiadać kolejne podobiekty. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 149 Obiekty w usłudze katalogowej sa˛ osobnymi, jeśli chodzi o zawartość, jednostkami takimi jak, np. osoby, grupy, komputery, drukarki albo sale konferencyjne w budynku. To, jakie atrybuty może a jakie musi posiadać obiekt, definiowane jest poprzez klasy obiektów danego obiektu. Klasa obiektu wyst˛epujaca ˛ w wielu katalogach może, np. być oznaczona, jako person i nakazywać, żeby 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. Dzi˛eki możliwości przyporzadkowania ˛ (także wtórnego) obiektom wielu klas obiektów, uzyskano duże możliwości dostosowawcze oraz możliwość zapisywania zwiazanych ˛ ze soba˛ informacji w tym samym miejscu (mianowicie w tym samym obiekcie). Osoba może posiadać wiele wzajemnych, powiazanych ˛ swoja˛ zawartościa,˛ właściwości, które musza˛ być zdefiniowane za pomoca˛ różnych klas obiektów (różnych, przenikajacych ˛ si˛e atrybutów). Oznacza to, że np. osoba może być widziana jako użytkownik systemów komputerowych, wpis w ksiażce ˛ telefonicznej, wpis w ksiażce ˛ adresowej albo partner życiowy innej osoby. Jeśli chcielibyśmy zapisać niniejsze właściwości w jednym katalogu, wówczas dla klas właściwości: użytkownik, wpis w ksiażce ˛ telefonicznej, wpis w ksiażce ˛ adresowej i partner życiowy musielibyśmy zdefiniować odpowiednie klasy obiektów wraz z atrybutami. Aby każda z klas obiektów mogła być sensownie używana także bez innych klas, każda z nich musiałaby prawdopodobnie posiadać atrybuty, które wst˛epuja˛ również w pozostałych wymaganych klasach obiektów, np. nazwisko osoby. Jeśli klasy obiektów sa˛ powiazane ˛ ze soba˛ w jednym obiekcie, wówczas atrybut Name trzeba zapisać tylko jeden raz. Możliwość korzystania z hierarchicznej struktury katalogów jest zazwyczaj wykorzystywana do odwzorowania w katalogu struktury organizacji. W tym celu stosuje si˛e najcz˛eściej specjalne obiekty, które służa˛ do strukturyzacji katalogu i odpowiadaja˛ sztucznym albo rzeczywistym jednostkom organizacyjnym. Obiekty te cz˛esto używaja˛ klasy organizationalUnit (ou). Poza tym, ze wzgl˛edu na zapewnienie przejrzystości, usługa katalogowa tworzona jest w oparciu o i tak istniejace ˛ już w organizacji przestrzenie nazw DNS. W tym celu wykorzystuje si˛e klas˛e domainComponent (dc). W praktyce zgrubna struktura tworzona jest najcz˛eściej w oparciu o przestrzenie nazw DNS a dokładna struktura za pomoca˛ jednostek organizacyjnych i innych container objects. Za przykład może posłużyć organizacja majaca ˛ swoja˛ siedzib˛e w dwóch miejscach (dzielnica zachodnia i dzielnica wschodnia). Używa ona domeny DNS miasto.pl i poddomen dla obydwu siedzib wsch.miasto.pl oraz zach.miasto.pl. Za punkt wyjścia dla katalogu organizacja taka mogłaby uznać obiekt „miasto.pl“. Byłby on w LDAP zapisany jako dc=miasto,dc=pl, co miałoby ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 150 oznaczać, że w przypadku podstawowego punktu odniesienia chodzi o typ obiektu składnik domeny (domainComponent, dc), że obiekt nazywa si˛e miasto, a podobiekt obiektu nosi nazw˛e de i jego typem również jest składnik domeny. Taki punkt wyjścia objałby ˛ z kolei dwa nast˛epne obiekty oznaczone dc=wsch i dc=zach (analogicznie do nazw DNS w/w siedzib). Powyższe oznaczenia nazywa si˛e także wzgl˛ednymi nazwami obiektów, ponieważ nie wskazuja˛ one jednoznacznie swojego położenia w hierarchii katalogu. Alternatywnie można korzystać z nazw jednoznacznych (distinguished Names), za pomoca˛ których można oznaczyć dokładne położenie obiektów w katalogu. Nazwy takie wygla˛ dałyby wówczas nast˛epujaco: ˛ dc=wsch,dc=miasto,dc=pl oraz dc=zach,dc=miasto,dc=pl . Niech w każdej z dwóch w/w siedzib dana organizacja ma trzy jednostki organizacyjne oznaczone jako produkcja, dystrybucja i kierownictwo. Aby móc odwzorować je w katalogu, dla jednostki organizacyjnej produkcja mieszczacej ˛ si˛e w siedzibie w dzielnicy wschodniej należałoby założyć obiekt ou=produktion jako podobiekt dc=wsch (jednoznaczna nazwa: ou=produktion,dc=wsch, dc=miasto,dc=pl). Analogicznie należałoby postapić ˛ z pozostałymi jednostkami organizacyjnymi mieszczacymi ˛ si˛e w obydwu siedzibach. Należałoby, np. wewnatrz ˛ jednostki organizacyjnej produkcja utworzyć obiekty takie jak osoby, grupy osób oraz komputery. W celu bardziej przejrzystego kształtowania tworzonej struktury w/w obiekty można uporzadkować ˛ w containers (na ogół oznacza si˛e je nazwami albo za pomoca˛ commonName, cn) i przypisać nast˛epujace ˛ oznaczenia: cn=osoby, cn=grupy i cn=komputery. Na koniec należałoby utworzyć wpisy dla rzeczywistych obiektów znajdujacych ˛ si˛e w containers. I tak, np. trzeba by w pojemniku założyć nast˛epujacy ˛ obiekt dla pracownika „Grzegorz Brz˛eczyszczykiewicz“, zatrudnionego w dziale produkcja w siedzibie znajdujacej ˛ si˛e we wschodniej dzielnicy: cn=ludzie,ou=produkcja,dc=wsch,dc=miasto,dc=pl . Obiekt taki miałby wówczas nazw˛e: cn=brz˛eczyszczykiewicz,cn=ludzie,ou=produkcja,dc=wsch,dc=miasto.dc= Oczywiście korzystanie z usługi katalogowej ma sens tylko w przypadku wykorzystywania możliwie wielu aplikacji. W najlepszym układzie jest ona jedynym źródłem informacji zapisanych w sieci. Gdy, np. w sieci jakiejś 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 konfigurować konta użytkowników i ich uprawnienia. Wraz z wdrożeniem usługi katalogowej możliwe staje si˛e centralne zdefiniowanie w usłudze katalogowej kont użytkowników oraz ich uprawnień i zezwolenie innym systemom na korzystanie ze wspólnych danych. Jednocześnie aplikacje z ksiażkami ˛ adresowymi, np. wbudowanymi w oprogramowanie pocztowe, moga˛ mieć dost˛ep do wspólnego katalogu i w ten sposób udost˛epniać adresy e - mail członkom danej organizacji, bez konieczności ponownego, r˛ecznego wprowadzania danych. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 151 Usługi katalogowe moga˛ także służyć do zapisywania haseł (hasła te staja˛ si˛e zazwyczaj atrybutem obiektów osób albo kont użytkowników). Także w ten sposób realizowany jest cel jednorazowego, centralnego przechowywania danych. Hasła zapisane w katalogu trzeba tylko założyć oraz zmienić w jednym miejscu i już można z nich korzystać we wszystkich systemach i ze wszystkimi aplikacjami, które moga˛ używać danego katalogu do autoryzacji. Ponadto hasła zapisane w katalogu moga˛ być wykorzystane w przypadku autoryzacji dost˛epu do danych w samym katalogu. Przykład zapisywania haseł pokazuje, potrzeb˛e istnienia bardzo szczegółowego systemu dost˛epu do usługi katalogowej, który określałby, jakie obiekty i atrybuty i przez jakich użytkowników moga˛ być czytane lub zmieniane. Z tego powodu celowe jest zadanie takich ustawień, by hasła mogły być zmieniane tylko przez swoich użytkowników i administratorów. Oprócz tego musza˛ one móc służyć swoim użytkownikom do autoryzacji. Z drugiej strony, wszystkie inne osoby, które maja˛ dost˛ep do katalogu, nie moga˛ mieć prawa do czytania haseł, nawet wówczas, jeśli hasła w katalogu sa˛ zaszyfrowane. Jednocześnie dozwolone jest, aby inni użytkownicy mogli czytać adresy e - mail z obiektów użytkowników. W takim przypadku różne przydawki (hasło i adres e - mail) tego samego obiektu (osoba i użytkownik) musiałyby być wyposażone w różne uprawnienia. Dlatego wi˛ekszość usług katalogowych ma zaimplementowany system Access Controll Lists (ACLs), który można porównać z ACLs na poziomie systemu plików. Pomimo szerokiego, praktycznego wykorzystania usług katalogowych do autoryzacji, strategi˛e taka˛ należy uznać za watpliw ˛ a. ˛ Rozwiazanie ˛ tego typu nie daje możliwości bezpiecznej implementacji Single Sing On, ponieważ w każdym systemie i każdej aplikacji wymagana jest ponowna autoryzacja (w dodatku za pomoca˛ tego samego hasła). Ponadto wi˛ekszość usług katalogowych nie została napisane w celu udost˛epniania bezpiecznego mechanizmu autoryzacji, lecz aby móc centralnie gromadzić informacje i szybko przesyłać je do klientów. Dlatego zamiast w/w metody zalecane jest stosowanie Kerberos. W przypadku wykorzystywania Kerberos nazwy oraz hasła użytkowników nie sa,˛ podobnie jak jest to na ogół przyj˛ete w innych rozwiazaniach, ˛ wysyłane do każdego serwera, z którego usług może korzystać każdy użytkownik, lecz nast˛epuje tu jednorazowe zalogowanie go do Key Distribution Center (KDC, nazywane także kontrolerem domen Kerberos). Po zalogowaniu użytkownik otrzymuje Ticket, który ma zdefiniowany czas ważności i za pomoca˛ którego można autoryzować si˛e we wszystkich kolejnych usługach. Po upływie terminu ważności biletu użytkownik musi si˛e ponownie autoryzować. Ze wzgl˛edu na stosowanie Kerberos baza danych haseł musi znajdować si˛e tylko w szczególnie zaufanych systemach (serwerach Kerberos). Inne systemy nie musza˛ mieć do niej dost˛epu. Oprócz tego za pomoca˛ Kerberos - Tickets można ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 152 implementować Single Sign On, ponieważ bilety wykorzystywane moga˛ być w celu uzyskania dost˛epu do wszystkich udost˛epnianych w sieci usług (o ile odpowiednie aplikacje obsługuja˛ Kerberos). Gdy tylko usługa katalogowa staje si˛e w organizacji centralna˛ baza˛ danych informacji, staje si˛e ona szczególnie ważnym składnikiem sieci, który musi gwarantować bardzo wysoka˛ niezawodność. Dlatego usługi katalogowe obsługuja˛ z reguły procesy replikacji, za pomoca˛ których możliwe jest przenoszenie całego katalogu i zmian z jednego serwera świadczacego ˛ usług˛e katalogowa˛ na inne. Dzi˛eki temu istnieje także możliwość rozkładania obciażenia, ˛ gdyż nie wszystkie klienty musza˛ korzystać z tego samego serwera usługi katalogowej. Jeśli chodzi o replikacj˛e, należy rozróżnić replikacj˛e Master - Slave oraz Multi - Master. W przypadku tej pierwszej zmiany moga˛ być dokonywane tylko na jednym, centralnym Master Server usługi katalogowej, który nast˛epnie rozsyła zmiany do pozostałych (Slave - Server). W przypadku zmian zawartości katalogu powstaje wówczas tak zwane waskie ˛ gardło, ponieważ można je przeprowadzać tylko na centralnym serwerze. Jeśli nastapi ˛ jego awaria, wtedy zmiany sa˛ niemożliwe aż do chwili zmiany konfiguracji i udost˛epnienia innego serwera jako Master albo ponownego uruchomienia starego Master - Server. Replikacja Multi - Master umożliwia dokonywanie zmian w zawartości usługi katalogowej na wielu serwerach, co rozwiazuje ˛ powyższe problemy. Jednak w przypadku tej replikacji ujawniaja˛ si˛e problemy ze spoistościa˛ w momencie, gdy na różnych serwerach przeprowadzane sa˛ sprzeczne ze soba˛ zmiany. 3.7.3 Active Directory Service (ADS) Celem niniejszego rozdziału jest przedstawienie możliwie obszernego przegladu ˛ technologii „Active Directory Service“. Dlatego opisaliśmy tu główne funkcjonalności: ◦ Directory Service ◦ LDAP ◦ Kerberos ◦ wytyczne grup ◦ Delegation ◦ zarzadzanie ˛ certyfikatami ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 153 Ponadto przedstawiliśmy: ◦ zakres zastosowania ◦ architektur˛e oraz ◦ znaczenie strategiczne. Innym celem jest wyjaśnienie różnicy pomi˛edzy minimalnym a maksymalnym stosowaniem Active Directory. 3.7.3.1 Nast˛epca usługi logowania stosowanej w Windows NT 4 Porównujac ˛ Active Directory (AD) z usługami logowania z Windows NT, można stwierdzić, że jest on ich nast˛epca.˛ Jest tak tym bardziej, że wywołanie installation routine z Windows 2000 na PDC z Windows NT prowadzi bezpośrednio do utworzenia Active Directory. Jednak bł˛edem w tym miejscu byłoby myślenie, że tworzenie Active Directory polega tylko na wywołaniu installation routine na pojedynczym serwerze. Aby utworzyć AD należy mieć porzadny ˛ pomysł i starannie zaplanować migracj˛e. Podstawowa˛ technologia,˛ na której opieraja˛ sie usługi logowania w Active Directory jest, podobnie jak w Windows NT, jedność struktury domeny. Domena pozostaje jednostka˛ administracyjna,˛ która za pomoca˛ wspólnie wykorzystywanej bazy danych skupia konta komputerów i użytkowników we wspólnym kontekście bezpieczeństwa. Granica domen jest granica˛ kontekstu bezpieczeństwa oraz granica˛ dla replikacji bazy danych użytkowników. Zachowana została przestrzeń nazw NetBIOS. Ponadto, podobnie jak w Windows NT, komputery pracujace ˛ w oparciu o: ◦ Windows NT ◦ Windows 2000 ◦ Windows XP moga˛ być członkiem domeny. Jeśli chcemy obsłużyć takie systemy, jak Windows NT i 9x, wówczas nadal musimy zagwarantować bezbł˛edne przekształcanie nazw NetBIOS (np. za pomoca˛ WINS). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 154 Charakterystyczne dla przeprowadzanej zmiany architektury jest implementacja Active Directory. Wymaga ona infrastruktury DNS, która sprawia, że konieczny jest nie tylko wybór przestrzeni nazw, lecz także zastosowanie właściwego serwera DNS. Oczywiście pociaga ˛ to za soba˛ dostosowanie istniejacego ˛ środowiska sieciowego TCP / IP. Planowanie migracji oraz możliwych scenariuszy zostało opisane w jednym z kolejnych rozdziałów. 3.7.3.2 Mechanizm autoryzacji Kerberos W Windows 2000 Active Directory nadal obsługiwany jest mechanizm autoryzacji NTLM. Jest to konieczne choćby dla zapewnienia autoryzacji podczas logowania systemów takich jak Windows NT lub 9x. Nowościa˛ jest autoryzacja via Kerberos. Systemy Windows 2000 albo XP domyślnie korzystaja˛ z Kerberos. Jednak w razie potrzeby można je przełaczyć ˛ także w tryb autoryzacji NTLM. Systemy takie, jak Windows NT lub 9x nie moga˛ nawet po wykorzystaniu obcego oprogramowania wykorzystywać Kerberos. DCs Windows 2000 komunikuja˛ si˛e poprzez Kerberos. W Windows 2000 zaimplementowano Kerberos w wersji 5 wraz z rozszerzeniami obsługujacymi ˛ autoryzacj˛e poprzez klucze publiczne (public key). Implementacja ta jest zgodna z RFCs 1510 i 1964. Kerberos Key Distribution Center (KDC) jest zintegrowany z każdym kontrolerem domeny Active Directory i używa jego bazy danych użytkowników. Dla korzystania z Kerberos konieczne jest zachowanie możliwie niewielkich różnic we wskazaniach zegarów systemowych współpracujacych ˛ komputerów. W tym celu w Windows 2000 zaimplementowano automatyczna,˛ hierarchiczna˛ synchronizacj˛e czasu komputerów, które sa˛ członkiem tego samego AD. Autoryzacj˛e Kerberos należy ocenić krytycznie, gdy używana jest w sieci NAT (Network Address Translation), ponieważ szyfrowane ładowanie pakietów IP zawiera adresy IP. Kerberos jest metoda˛ bardziej elastyczna˛ i wydajna˛ niż NTLM. W przypadku NTLM, aby autoryzować klienta, serwer aplikacji musiał zawsze łaczyć ˛ si˛e z kontrolerem domeny. Za pomoca˛ Kerberos serwer aplikacji może analizować informacje o logowaniach prezentowane mu przez klienta. W NTLM serwery moga˛ identyfikować klientów, natomiast Kerberos daje także klientom możliwość identyfikacji serwera (mutual authentication). Aby realizować dost˛ep do zasobów, usługi windowsowe musza˛ naśladować klienta (impersonate). NTLM i Kerberos moga˛ dostarczać usłudze informacje, przez co moga˛ lokalnie naśladować klienta. W przypadku aplikacji dzielonych z Frontend i Backend na różnych komputerach, technologia NTLM zawodzi, podczas gdy Kerberos potrafi realizować przeźroczyste, dwukierunkowe zaufane połaczenia ˛ po- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 155 mi˛edzy domenami. Protokół Kerberos składa si˛e 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 nazw˛e usługi biletowej (Ticket Granting Service, TGS Exchange). Ostatni protokół, poprzez który klient przesyła Ticket do usługi w celu uzyskania dost˛epu do niej, nazywa si˛e usługa˛ Client / Server (CS Exchange). 3.7.3.3 Nowości w strukturze Jak już wspomnieliśmy, zachowana została jedność struktury domeny, także w Active Directory. W Active Directory domen˛e należy traktować, jako podstaw˛e całej struktury (forest) i należacych ˛ 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˛ być nadal wykorzystywane.) Jeśli jest mowa o Active Directory, wówczas chodzi zawsze o cała˛ struktur˛e, a nie o pojedyncze drzewa albo domeny. Nast˛epujacy ˛ rysunek przedstawia struktur˛e domeny Windows NT, w której za pomoca˛ relacji zaufania powiazane ˛ sa˛ ze soba˛ dwie domeny kont i pi˛eć 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. Otrzymaliśmy zatem nast˛epujacy ˛ rysunek: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 156 Rysunek 3.7: Przykład struktury domen NT Zgodnie z rys 3.7, w Active Directory do pomyślenia jest ogólna struktura, która również obejmowałaby siedem domen: struktura ogólna obejmuje dwa drzewa o hierarchicznej strukturze domen, które powiazane ˛ sa˛ ze soba˛ za pomoca˛ Kerberos - przeźroczyście (A ufa B i B ufa C, wówczas A ufa także C) i dwukierunkowo (A ufa B, wówczas B ufa także A). Rysunek 3.8: Przykład Windows 2000 Active Directory udost˛epniany jest przez kontrolery domen (DCs). Zanika rozróżnienie pomi˛edzy PDC i BDC. Wynika to z nowej architektury, w której kontrolery domen Windows 2000 podporzadkowane ˛ zostały zasadzie Multi - Master: wi˛ekszość zmian w AD można przeprowadzić (wpisać) na każdym DC. Zasada Multi - Master nie może dotyczyć wszystkich zmian. Dlatego 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 można umieszczać 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 aktualizacj˛e SIDs oraz Distinguished Names poza granicami domen) ◦ RID Master (odpowiedzialny za przyznawanie RID Pools innym DCs) sa˛ jednoznaczne w każdej domenie. Emulator PDC przejmuje ważne funkcje takie jak: ◦ aktualizacja haseł dla Down - Level Clients (NT 4.0, 9x) oraz partnerów Windows NT Backup Domain Controller ◦ źródło czasu sieciowego (tylko PDC domeny podstawowej) ◦ usługa głównego wyszukiwania domen (NetBIOS) Ogólna struktura może być dodatkowo wzbogacana o punkty centralne (Sites). Miejsca te moga˛ (raczej powinny) być odbiciem fizycznej struktury sieci i łaczyć ˛ si˛e za pomoca˛ dost˛epnych szerokości pasm z lokalizacjami (Hamburg, Berlin, Bonn, etc.). Głównym celem takiej struktury jest umożliwienie sterowania replikacja˛ pomi˛edzy kontrolerami domen. Standardowa˛ topologi˛e można wybrać niezależnie od struktury domen. Poniższy rysunek przedstawia przykładowa˛ topologi˛e. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 158 Rysunek 3.9: Przykład struktury punktu centralnego domen oraz ich struktury Inna˛ nowościa,˛ jeśli chodzi o tworzenie struktury, jest tak zwana struktura OU (OU jest skrótem od Organizational Unit, jednostka organizacyjna). Opisaliśmy ja˛ w rozdziale przedstawiaja˛ cym usługi katalogowe. 3.7.3.4 Przestrzeń adresowa DNS i infrastruktura Windows 2000 Active Directory Service bezwzgl˛ednie potrzebuje infrastruktury DNS. Wymaga to udzielenia odpowiedzi na nast˛epujace ˛ pytania: ◦ Jaka˛ przestrzeń nazw DNS powinien otrzymać AD? ◦ Jak przestrzeń nazw powinna si˛e wpisać w istniejac ˛ a˛ przestrzeń nazw DNS? ◦ Kto ma administrować istniejac ˛ a˛ przestrzenia˛ nazw? ◦ Na jakiej platformie (system operacyjny: Windows 2000, Unix) ma być udost˛epniany DNS? ◦ Jakie odniesienie do przestrzeni nazw NetBIOS należy uwzgl˛ednić? Znalezienie odpowiedzi na powyższe pytania jest cz˛esto szczególnie skomplikowane nie tylko ze wzgl˛edu na warunki techniczne, lecz również wskutek tła „politycznego“. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 159 Wybór platformy Infrastruktura DNS dla AD wymaga pewnych cech, aby możliwe było bezproblemowe przekształcanie nazw i rejestracja wpisów. Zasadniczo Windows 2000 wraz ze swoja˛ implementacja˛ DNS posiada wszystkie niezb˛edne właściwości. DNS z Windows 2000 ma m.in. nast˛epujace ˛ Features: ◦ Service Records (RFC 2052) ◦ dynamiczny DNS (RFC 2136) ◦ bezpieczny dynamiczny Update ◦ metod˛e Multi - Master wskutek integracji z Active Directory ◦ Integracj˛e WINS. Konieczna jest obsługa RFC 2052, ponieważ tylko tak można dokonywać wpisów dla usług w DNS. RFC 2052 obsługiwany jest przez serwery uniksowe poczawszy ˛ od BIND 8.1.2. BIND 8.2..1 obsługuje dalsze Features i jest wersja˛ zalecana.˛ Przestrzeń nazw NetBIOS Jeśli chodzi o przestrzeń nazw NetBIOS, należy wziać ˛ pod uwag˛e nast˛epujace ˛ aspekty: ◦ Nazwa NetBIOS domeny Windows 2000 (np. RES1) może w zasadzie różnić si˛e od najniższej nazwy sufiksu DNS (jak, np. RES001 od res001.behoerde.de). Jednak odradzamy wybieranie nazw w taki sposób. ◦ Przestrzeń nazw NetBIOS nie jest dowolna zwłaszcza wtedy, gdy trzeba zaktualizować istniejace ˛ domeny NT (patrz Inplace Migration). Przestrzeń nazw DNS Podczas formułowania poniższych ocen wyszliśmy z założenia, że w istniejacej ˛ infrastrukturze obecne jest już środowisko DNS, które udost˛epniane jest w oparciu o serwer uniksowy. Jest to dość ogólny punkt wyjścia. Niech nazwa˛ domeny b˛edzie tu „BEHOERDE.DE“, a istniejaca ˛ przestrzeń nazw BEHOERDE.DE niech b˛edzie używana tylko wewn˛etrznie. Ponadto przyj˛eliśmy, że w infrastrukturze DNS istnieje wewn˛etrzna domena Root („kropka“) badź ˛ strefa. Poniższy rysunek nakreśla punkt wyjścia. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 160 Rysunek 3.10: Punkt wyjścia W kolejnych podrozdziałach opisaliśmy możliwe rozwini˛ecia przestrzeni nazw pod katem ˛ Windows 2000 Active Directory. Uwidoczniona tu została złożoność migracji do ADS i wynikajace ˛ z tego długoterminowe zwiazanie ˛ si˛e z ADS. Domena Master: W2K.BEHOERDE.DE Istniejaca, ˛ wewn˛etrzna przestrzeń nazw DNS wykorzystywana jest do przyjmowania kolejnych poddomen W2K (jako, że domena Master = pierwsza domena Active Directory). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 161 Rysunek 3.11: Domena Master: W2K.BEHOERDE.DE Zaleta˛ powyższej domeny Master jest to, że: ◦ nie jest tworzone nowe drzewo nazw ◦ zachowane sa˛ istniejace ˛ serwery Root ◦ można dowolnie wybrać platform˛e usług DNS ◦ wewn˛etrzna i zewn˛etrzna przestrzeń nazw pozostaja˛ oddzielne Wada˛ takiego rozwiazania ˛ jest to, że: ◦ User Principal Name użytkownika jest dość długa ([email protected]. de) badź ˛ zawiera 2nd Level Domain ◦ przy powi˛ekszaniu ogólnej struktury (np. dodaniu drzewa DNS ROZWINIECIE.DE) ˛ jedno nd z drzew nie jest 2 Level Domain (technicznie nie byłoby z tym problemu) ◦ cz˛eść przekształcania nazw zależy w dużym stopniu od dotychczasowej infrastruktury ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 162 Domena Master: BEHOERDE.DE Istniejaca ˛ przestrzeń nazw DNS wykorzystywana jest do określenia nazwy domeny Master. Rysunek 3.12: Domena Master: BEHOERDE.DE Zaleta˛ powyższej domeny Master jest to, że: ◦ nie jest tworzone nowe drzewo nazw ◦ zachowane sa˛ istniejace ˛ serwery Root ◦ User Principal Name użytkownika jest dość krótka ([email protected]) ◦ przy powi˛ekszaniu ogólnej struktury (np. dodaniu drzewa DNS ROZWINIECIE.DE) ˛ obydwa drzewa sa˛ 2nd Level Domain ◦ wewn˛etrzna i zewn˛etrzna przestrzeń nazw pozostaja˛ oddzielne Wada˛ takiego rozwiazania ˛ jest to, że: ◦ nie można wybrać platformy usług DNS ◦ przekształcanie nazw zależy wyłacznie ˛ od dotychczasowej infrastruktury ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 163 Domena Master: NEU.DE Niniejsze rozwini˛ecie jest niezależne od dotychczasowej przestrzeni nazw i tworzy nowe wewn˛etrzne drzewo nazw DNS. Wybrana powyżej nazwa NEU.DE jest jedyna na świecie i oficjalnie zarejestrowana. Rysunek 3.13: Domena Master: NEU.DE Zaleta˛ powyższej domeny Master jest to, że: ◦ tworzone jest nowe drzewo nazw, dzi˛eki czemu nie sa˛ przejmowane stare obciażenia ˛ ◦ zachowane sa˛ istniejace ˛ serwery Root ◦ można wybrać platform˛e usług DNS ◦ User Principal Name użytkownika jest dość krótka ([email protected]) ◦ przy powi˛ekszaniu ogólnej struktury (np. dodaniu drzewa DNS ROZWINIECIE.DE) ˛ obynd dwa drzewa sa˛ 2 Level Domain ◦ przekształcanie nazw zależy w małym stopniu od dotychczasowej infrastruktury ◦ wewn˛etrzna i zewn˛etrzna przestrzeń nazw pozostaja˛ oddzielne, odpowiednio do późniejszych wymagań ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 164 Wada˛ powyższego rozwiazania ˛ jest to, że: ◦ tworzone jest nowe drzewo nazw, co powoduje powstawanie nowych struktur i dodatkowych wytycznych ◦ rośnie stopień skomplikowania ustawień DNS oraz nakład pracy administracyjnej. Master i structure domain: NEU.DE / INTRA.NEU.DE Powyższe rozwini˛ecie jest niezależne 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łuży wyłacznie ˛ jako master domain ogólnej struktury, jako tak zwana domena struktury. Poniżej konta użytkowników zakładane sa˛ w poddomenie INTRA. Rysunek 3.14: Domena Master i domena struktury: NEU.DE / INTRA.NEU.DE Zaleta˛ powyższej structur domain jest to, że: ◦ tworzone jest nowe drzewo nazw, dzi˛eki czemu nie sa˛ przejmowane stare obciażenia ˛ ◦ zachowane sa˛ istniejace ˛ serwery Root ◦ można wybrać platform˛e usług DNS ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 165 ◦ przy powi˛ekszaniu ogólnej struktury (np. dodaniu drzewa DNS ROZWINIECIE.DE) ˛ obydwa drzewa sa˛ 2nd Level Domain ◦ przy powi˛ekszaniu ilości domen nowe domeny można zakotwiczać równolegle z domena˛ INTRA. ◦ przekształcanie nazw zależy w małym stopniu od dotychczasowej infrastruktury ◦ wewn˛etrzna i zewn˛etrzna przestrzeń nazw pozostaja˛ oddzielne, odpowiednio do wymagań Wada˛ powyższego rozwiazania ˛ jest to, że: ◦ w Active Directory instalowane sa˛ dwie domeny ◦ tworzone jest nowe drzewo nazw, co powoduje konieczność kontrolowania powstawania nowych struktur i dodatkowych wytycznych ◦ User Principal Name użytkownika jest dość długa ([email protected]) ◦ rośnie ilość krzyżowych połaczeń ˛ oraz stopień skomplikowania i nakład pracy administracyjnej. Master domain: INTRA.BEHOERDE-ONLINE.DE Istniejaca ˛ zewn˛etrzna przestrzeń nazw DNS wykorzystywana jest do przyjmowania kolejnych domen. Istniejaca ˛ przestrzeń nazw BEHOERDE - ONLINE.DE stosowana była dotychczas tylko zewn˛etrznie. Należy założyć domen˛e INTRA, która b˛edzie używana tylko wewn˛etrznie. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 166 Rysunek 3.15: Domena Master: INTRA.BEHOERDE-ONLINE.DE Zaleta˛ powyższej domeny Master jest to, że: ◦ tworzone jest nowe drzewo nazw, dzi˛eki czemu nie sa˛ przejmowane stare obciażenia ˛ ◦ zachowane sa˛ istniejace ˛ serwery Root ◦ można wybrać platform˛e usług DNS ◦ przy powi˛ekszaniu ogólnej struktury (np. dodaniu drzewa DNS ROZWINIECIE.DE) ˛ obydwa drzewa sa˛ 2nd Level Domain ◦ przekształcanie nazw zależy w dużym stopniu od dotychczasowej infrastruktury Wada˛ powyższego rozwiazania ˛ jest to, że: ◦ User Principal Name użytkownika jest dość długa ([email protected]. de) ◦ tworzone jest nowe drzewo nazw, co powoduje konieczność kontrolowania powstawania nowych struktur i dodatkowych wytycznych ◦ rośnie ilość krzyżowych połaczeń ˛ oraz stopień skomplikowania i nakład pracy administracyjnej ◦ wewn˛etrzna i zewn˛etrzna przestrzeń nazw nie sa˛ już od siebie niezależne Domena Master: AMT.LOCAL Niniejszy dodatek jest niezależny od dotychczasowej przestrzeni nazw i tworzy nowe wewn˛etrzne drzewo DNS. Wybrana Top Level Domain LOCAL nie jest obecnie obsługiwana w Internecie. Wybranej powyżej nazwy nie można zatem zarejestrować. Zamiast LOCAL mogłaby również zostać użyta, chroniona przez RFC 2606 nazwa domeny Top Level, której nigdy nie grozi to, że zostanie przej˛eta przez społeczność internetowa˛ jako Top Level Domain. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 167 Rysunek 3.16: Master domain: AMT.LOCAL Zaleta˛ powyższej master domain jest to, że: ◦ tworzone jest nowe drzewo nazw, dzi˛eki czemu nie sa˛ przejmowane stare obciażenia ˛ ◦ zachowane sa˛ istniejace ˛ serwery Root ◦ można wybrać platform˛e usług DNS ◦ User Principal Name użytkownika jest dość krótka ([email protected]) ◦ przy powi˛ekszaniu ogólnej struktury (np. dodaniu drzewa DNS ROZWINIECIE.DE) ˛ obydwa drzewa sa˛ 2nd Level Domain ◦ przekształcanie nazw zależy w małym stopniu od dotychczasowej infrastruktury Wada˛ powyższego rozwiazania ˛ jest to, że: ◦ tworzone jest nowe drzewo nazw, co powoduje konieczność kontrolowania powstawania nowych struktur i dodatkowych wytycznych ◦ wewn˛etrzna i zewn˛etrzna przestrzeń nazw zostaja˛ na stałe od siebie oddzielone ◦ rośnie ilość krzyżowych połaczeń ˛ oraz stopień skomplikowania i nakład pracy administracyjnej ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 168 Uwaga! Wybór przestrzeni nazw DNS staje si˛e bez porównania trudniejszy, gdy suwerenne administrowanie przestrzenia˛ nazw DNS wykracza poza własne, suwerenne uprawnienia. Cz˛esto w takiej sytuacji należy podporzadkować ˛ własne zamierzenia nadrz˛ednemu interesowi, co może spowodować widoczne wydłużenie si˛e procesu decyzyjnego. 3.7.3.5 Usługa katalogowa i jej schemat Wraz z Windows 2000 Active Directory wprowadzono usług˛e katalogowa,˛ która opiera si˛e na standardzie X. 500 i która˛ można zarzadzać ˛ poprzez LDAP (Lightweight Directory Access Protocol). Usługa katalogowa wykorzystuje typ bazy danych, który pierwotnie stworzony został dla Microsoft Exchange (Extensible Storage Engine). Zastapił ˛ on architektur˛e bazy danych SAM. SAM jest jednak nadal dost˛epny 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 można przyporzadkować ˛ do 863 atrybutów (wraz z E2K, HIS oraz ISA: 1928). Zasadniczo istnieje możliwość rozszerzania niniejszego schematu i przypisywania istnieja˛ cym klasom nowych atrybutów. W Windows 2000 raz uruchomionych rozszerze ń schematu nie można już zmienić. Można je jedynie dezaktywować. Podział Active Directory, wzgl˛ednie bazy danych nast˛epuje w oparciu o jedność struktury domeny. Zatem nie jest możliwy podział wewnatrz ˛ domeny w sensie zdecentralizowanej bazy danych. Replikacja Active Directory badź ˛ bazy danych nast˛epuje pomi˛edzy kontrolerami domeny (DC). Odbywa si˛e ona w oparciu o tak zwany Unique Sequence Number (USN), którym można zarzadzać ˛ aż do poziomu atrybutów. Dzi˛eki temu replikacja może być realizowana na poziomie atrybutów. Jeśli zatem zmienia˛ si˛e właściwości obiektu, wówczas replikowana b˛edzie jedynie zmieniona właściwość, a nie cały obiekt. Każdy DC w Active Directory udost˛epnia usług˛e LDAP. Obsługiwana jest LDAP w wersji 3. Za pomoca˛ klienta LDAP można przeszukiwać i administrować Active Directory. Dzi˛eki Distinguished Name istnieje możliwość każdorazowego czytania i zapisywania obiektu. Poniżej zamieściliśmy przykładowa˛ ścieżk˛e: LDAP.LDAP://dc001.behoerde.de/cn=Grzegorz Brz˛eczyszczykiewicz, 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 także serwer LDAP). Podanie serwera LDAP jest opcjonalne w przypadku niektórych klientów LDAP, o ile obsługuja˛ one tak zwany „serverless binding“. W zasadzie można zastosować dowolna˛ implementacj˛e LDAP, np. OpenLDAP badź ˛ interfejs programu, taki jak: ◦ ADSI (Active Directory Services Interface (zintegrowany w Windows 2000) ◦ LDIF (LDAP Data Interchange Format) ◦ i inne. Korzystanie z powyższych interfejsów jest problematyczne, gdyż: ◦ pewne atrybuty albo obiekty sa˛ suwerennie zarzadzane ˛ z Active Directory (np. atrybuty SID albo GUID), ◦ pewne atrybuty składaja˛ si˛e z wartości binarnych albo wartości Hash, których algorytmy deszyfrujace ˛ i szyfrujace ˛ nie sa˛ znane (np. atrybut userParameters) i można je modyfikować tylko spoza LDAP poprzez oddzielne interfejsy (np. Windows Terminal Server API). ◦ Korzystanie z graficznego interfejsu użytkownika (MMC) wywołuje oprócz czystego zapisywania atrybutów LDAP dodatkowe procesy (np. podczas określania 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 niezb˛edny dla Exchange 2000. Exchange 2000 odpowiada za rozszerzanie obiektu użytkownika i zapisywanie jego własnej konfiguracji w AD. Nast˛epujace ˛ produkty Microsoft wykorzystuja˛ AD do zapisywania swojej konfiguracji: ◦ Serwer HIS (Host Integration Server) ◦ Server ISA (Internet Security and Acceleration) 3.7.3.7 Narz˛edzia administracyjne Wersja serwera Windows 2000 dostarczana jest wraz z całym szeregiem graficznych narz˛edzi do zarzadzania ˛ informacjami, kontami użytkowników i grup albo konfiguracja˛ DNS, składowanymi standardowo w Active Directory. Ponadto korzystać można z narz˛edzi znanych z Windows NT ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 170 działajacych ˛ pod konsola,˛ które umożliwiaja˛ zakładanie, usuwanie i edycj˛e użytkowników i grup. Jednakże narz˛edzia te pozwalaja˛ tylko zarzadzać ˛ cz˛eścia˛ informacji o kontach zapisanych w Active Directory. Oprócz tego dost˛epny jest konsolowy program ldifde umożliwiajacy ˛ uzyskiwanie wpisów w katalogach z pliku LDIF (LDAP Data Interchange Format). Łacznie ˛ narz˛edzia administracyjne dostarczane wraz z serwerem Windows 2000 skierowane sa˛ raczej do doświadczonych administratorów. Prawie nie nadaja˛ si˛e one do tego, aby osoby słabiej wykształcone wykonywały z ich pomoca˛ proste zadania administracyjne, takie jak zakładanie albo zmiana kont użytkowników. Dzi˛eki ADSI (Active Directory Service Interface) istnieje interfejs oparty na COM, za pomoca˛ którego można zautomatyzować wiele zadań. 3.7.3.8 Certyfikacja Windows 2000 stworzył możliwość tworzenia tak zwanych PKI (Public Key Infrastructure). Certification Authority (CA) można zarówno zintegrować w AD, jak i zainstalować oddzielnie. Jeśli wybrany zostanie wariant integracji w AD, wówczas w wewn˛etrznej sieci b˛eda˛ obsługiwane nast˛epujace ˛ technologie bezpieczeństwa, wzgl˛ednie umożliwione zostanie korzystanie z nich: ◦ EFS (Encrypted File System) ◦ IPsec ◦ SmartCard ◦ szyfrowanie i podpisy cyfrowe (e - mail) ◦ i inne. Przydzielanie badź ˛ aktywacja PKI obsługiwane sa˛ przez wytyczne grup. Jednak nie oznacza to, że oddzielne rozwiazania ˛ administracyjne dotyczace ˛ zarzadzania ˛ kluczami staja˛ si˛e zb˛edne. 3.7.3.9 Smart Card Wskutek zbudowania wewn˛etrznego PKI autoryzacja użytkowników może odbywać si˛e poprzez SmartCard. Zgłoszenia via SmartCard do komputerów Windows 2000 / XP moga˛ być realizowane bez stosowania dodatkowego oprogramowania. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 171 3.7.4 Migracja zast˛epujaca ˛ - Samba i Open LDAP 3.7.4.1 Wymagania odnośnie funkcjonalności Centralne wymaganie, które ma spełniać usługa katalogowa polega na szybkim udost˛epnianiu informacji w sieci. Ponadto powinna ona oferować nast˛epujace ˛ funkcje: ◦ możliwość zmiany informacji udost˛epnianych w katalogu ◦ możliwość hierarchicznego uporzadkowania ˛ obiektów w katalogu ◦ stosowanie zgodnych ze standardami i rozpowszechnionych schematów w celu zagwarantowania wysokiej kompatybilności za pomoca˛ możliwie wielu aplikacji. Możliwość rozszerzania o własne obiekty i schematy. ◦ możliwość autoryzacji użytkowników oraz integracja z innymi usługami autoryzacji (Kerberos) ◦ administrowanie prawami dost˛epu ◦ stosowanie otwartych standardów w celu zwi˛ekszenia kompatybilności możliwie ze wszystkimi usługami i aplikacjami, które moga˛ korzystać z informacji zapisanych w katalogu ◦ obsługa procesu replikacji ◦ stosowanie bezpiecznych protokołów transmisji podczas przekazywania informacji pomi˛edzy klientem a usługa˛ katalogowa, ˛ jak również podczas replikacji. 3.7.4.2 Oceniane produkty Jeśli wymagane jest zastapienie ˛ domeny Windows NT usługa˛ katalogowa˛ oparta˛ na Microsoft Windows albo Linuksie, wówczas w pierwszej linii należy uwzgl˛ednić nast˛epujace ˛ 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, gdyż wymagaja˛ one wprowadzenia dodatkowych produktów i przez to podnosza˛ stopień skomplikowania środowisk IT opartych na Windowsie badź ˛ Linuksie. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.7.4.3 172 Generalne porównanie zakresu funkcji udost˛epnianych przez NTDS, Active Directory i OpenLDAP F UNKCJA W IN 2K / L INUX / ADS O PEN LDAP X X X X X X Unicode Unicode domyślny protokół (LDAP) X X możliwość bezpiecznego dost˛epu poprzez X X X X klient bez dodatkowego W IN NT X oprogramowania możliwość budowania hierarchicznej struktury katalogu rozszerzalność o własne atrybuty i klasy obiektów zestaw znaków dla katalogowanych danych Unicode możliwość dost˛epu do katalogu poprzez LDAP z wykorzystaniem SSL / TLS obsługa protokołu „starttls“ obsługa SASL X autoryzacja klientów NT X X poprzez Samba24 poprzez Samba25 autoryzacja klientów linuksowych poprzez winbind poprzez winbind X albo LDAP możliwość zintegrowania Kerberos X26 X możliwość stosowania niezależnej / nadrz˛ednej usługi Kerberos 27 X zarzadzanie ˛ prawami dost˛epu (ACLs) dla atrybutów i obiektów 24 X X X W przypadku wykorzystywania Samby do autoryzacji klientów windowsowych w OpenLDAP, pomi˛edzy klientem windowsowym a serwerem Samba stosowany jest protokół NT-LAN-Manager. 25 W przypadku wykorzystywania Samby do autoryzacji klientów windowsowych w OpenLDAP, pomi˛edzy klientem windowsowym a serwerem Samba stosowany jest protokół NT-LAN-Manager. 26 Kerberos jest na stałe zintegrowany w Active Directory 27 Active Directory zezwala na autoryzacj˛e na zewn˛etrznym serwerze Kerberos, jednak wówczas nie można wykorzystywać domen Active Directory do autoryzacji komputerów opartych o Windows 95 / 98 / Me / NT. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 173 przydzielanie zadań administracyjnych replikacja Master - Slave X X replikacja Multi - Master X 28 X29 X X X30 Tablica 3.26: Porównanie usług katalogowych 3.7.4.4 Autoryzacja z wykorzystaniem Linuksa / OpenLDAP i Samby Trudno jest oddzielić od siebie temat autoryzacji i usług katalogowych. Ponieważ jednak usługa katalogowa może pełnić wi˛ecej zadań niż autoryzacja, a autoryzacja jest usługa˛ infrastrukturalna, ˛ w rozdziale 3.4 „Autoryzacja“ oceniliśmy z jednej strony autoryzacj˛e na gruncie Linuksa, Samby i OpenLDAP, a z drugiej strony także t˛e zwiazan ˛ a˛ z Windows i ADS. 3.7.4.5 Centralne administrowanie informacjami o hostach z wykorzystaniem Linuksa i OpenLDAP Dzi˛eki centralnemu zarzadzaniu ˛ informacjami o hostach w katalogu możliwe staje si˛e uproszczenie całego szeregu zadań administracyjnych. Należa˛ do nich: ◦ inwentaryzacja dost˛epnego osprz˛etu ◦ tworzenie i zarzadzanie ˛ wpisami nazw DNS ◦ tworzenie i zarzadzanie ˛ konfiguracjami DHCP ◦ dla klientów windowsowych można zapisywać konta maszyn razem z w/w informacjami Ponadto informacje te nie musza˛ być przydzielane do komputerów r˛ecznie lub w drodze innego post˛epowania, lecz moga˛ być dystrybuowane do odpowiednich systemów za pomoca˛ replikacji LDAP. W Linuksie można obecnie korzystać z całego szeregu programów umożliwiajacych ˛ czytanie informacji o hostach bezpośrednio z katalogu LDAP: 28 Active Directory stosuje w „Mixed Mode“ replikacj˛e Maser - Slave pomi˛edzy DC z Windows 2000 a BDC z Windows NT 4. 29 Active Directory stosuje w „Native Mode“ (w którym używane sa˛ wyłacznie ˛ kontrolery domen oparte na Windows 2000 / 2003) replikacj˛e Multi - Master. 30 replikacja 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, dzi˛eki której możliwe jest czytanie konfiguracji DHCP z katalogu LDAP. ◦ http://home.ntelos.net/~masneyb/dhcp-3.0.1rc11-ldap-patch ◦ dla BIND 9 istnieje również łata umożliwiajaca ˛ zastapienie ˛ przez LDAP plików strefowych. ◦ http://www.venaas.no/dns/bind/bind-sdb/ ◦ Samba potrafi pobierać informacje o kontach maszyn bezpośrednio z katalogu LDAP. Oprócz tego istnieje cały szereg własnościowych oraz wolnych programów umożliwiajacych ˛ przeźroczyste pobieranie z katalogu LDAP konfiguracji serwerów BIND i DHCP. 3.7.4.6 Integracja innych aplikacji Poza wykorzystywaniem usług katalogowych do centralnego zapisywania informacji o użytkownikach, grupach i hostach, dzi˛eki oferowanej przez nie dost˛epności zwi˛eksza si˛e możliwość korzystania z wielu innych aplikacji. Zrezygnowaliśmy z przedstawienia w tym miejscu pełnej listy aplikacji kompatybilnych z LDAP. Ważna jest jednak wskazówka, że coraz wi˛ecej aplikacji obsługuje LDAP, nie tylko programy pocztowe Microsoft Outlook i Outlook - Express albo pakiet biurowy OpenOffice. Niniejsze programy moga˛ współpracować zarówno z OpenLDAP, jak i z Active Directory jako usługa˛ katalogowej. 3.7.4.7 Narz˛edzia administracyjne Do zarzadzania ˛ informacjami zapisanymi w katalogu dost˛epne sa˛ w Linuksie z jednej strony standardowe narz˛edzia LDAP (ldapsearch, ldapadd, ldapmodify). Nadaja˛ si˛e one przede wszystkim do zainicjowania katalogu, importu danych, szybkiego przeszukiwania zawartości katalogu oraz do automatycznej edycji katalogu. Także do zarzadzania ˛ użytkownikami i grupami udost˛epnianych jest kilka konsolowych narz˛edzi. Wolne, graficzne narz˛edzia dla Linuksa służace ˛ do opartego na usłudze katalogowej zarza˛ dzania użytkownikami i grupami znajduja˛ si˛e obecnie w fazie rozwoju (np. directory - administrator: http://diradmin.open-it.org/files.php). Równie ważne sa˛ elastyczne narz˛edzia WWW do zarzadzania ˛ kontami użytkownikó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ń ˛ jest to, że można z nich korzystać z poziomu przegladarki ˛ WWW, niezależnie od serwera, przy czym stosowana jest bezpieczna transmisja danych (SSL / TLS) 31 . 3.7.4.8 Zachowanie podczas pracy i zużycie zasobów Linux i OpenLDAP okazały si˛e być stabilne oraz wystarczajaco ˛ performant w środowiskach złożonych z ponad 10.000 użytkowników. W różnych testach i dużych instalacjach Samba okazała si˛e być bardzo pewna, stabilna i w porównaniu z serwerami windowsowymi zasobooszcz˛edna. 3.7.4.9 Akceptacja użytkowników Usługi katalogowe sa˛ z poczatku ˛ niewidoczne dla użytkownika końcowego i staja˛ si˛e stopniowo widoczne wraz z przyłaczaniem ˛ aplikacji do katalogu. Im wi˛ecej aplikacji korzysta z katalogu, tym wyższe jest prawdopodobieństwo, że użytkownicy b˛eda˛ spotykać spójne dane, co doprowadzi do wzrostu akceptacji. Migracja do Samby / OpenLDAP może być przeźroczysta dla użytkowników i klientów, co sprawi że nie zauważa˛ oni zmian wynikajacych ˛ z migracji. Administratorzy odniosa˛ korzyści z usługi katalogowej wskutek wprowadzenia administrowania Single Point. Z usługi katalogowej można korzystać tym lepiej, im lepiej dost˛epne narz˛edzia dopasowane sa˛ do profilu wykształcenia i codziennych zadań administratora. 3.7.5 Migracja kontynuacyjna - Wprowadzenie do ADS Migracja usług logowania z Windows NT 4 do Windows 2000 Active Directory wymaga z reguły przygotowania oddzielnego rozwiazania ˛ i praktycznych testów jeszcze zanim ostatecznie określona zostanie optymalna droga migracji. W celu przedstawienia obrazu przewidywanych nakładów oraz technicznych warunków krańcowych, w nast˛epujacych ˛ rozdziałach wyjaśniliśmy pokrótce, jak może wygladać ˛ taka migracja. 3.7.5.1 Kolejność Jeśli chodzi o kolejność, istnieje bardzo wiele wariantów migracji z Windows NT do Windows 2000. W zwiazku ˛ z tym nie istnieje konieczność integrowania najpierw usług logowania a nast˛epnie klientów lub na odwrót. Nie jest także wymagane przestawianie wielu klientów Windows NT na zasadzie masowego rollaut. Jedyna˛ rzecza,˛ jaka˛ trzeba mieć na uwadze jest sytuacja, gdy 31 Przykładami sa˛ moduł Webmin (http://www.webmin.com/), idxldapaccounts (http://webmin. idealx.org/) oraz narz˛edzie wymagajace ˛ licencji univention_admin (http://www.univention.de/). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 176 przewiduje si˛e aktualizacj˛e istniejacej ˛ domeny NT (Inplace Upgrade). Wówczas należy najpierw dokonać aktualizacji PDC tej domeny do Windows 2000. Active Directory rozróżnia dwa tryby pracy: Mixed Mode i Native Mode. Do Native Mode można przełaczyć ˛ si˛e dopiero wówczas, gdy nie ma już potrzeby zasilania NT BDCs replika˛ SAM. Przełaczenia ˛ do Native Mode nie można cofnać. ˛ Należy pami˛etać o tym, że Native Mode jest wymagany w przypadku migracji z restrukturyzacja˛ (patrz „Wariant 2: aktualizacja plus restrukturyzacja“ w rozdziale 3.7.5.3). W planowaniu kolejności istnieje potencjał optymalizacyjny, który należy wykorzystać odpowiednio do istniejacego ˛ środowiska. 3.7.5.2 Docelowa architektura Celem powinna być struktura Active Directory z jedna˛ domena˛ badź ˛ możliwie mała˛ ilościa˛ domen. Mała ilość domen zapewnia z reguły najmniejszy nakład pracy. Rysunek 3.17: Migracja przez Upgrade albo restrukturyzacj˛e Odpowiada to zaleceniom projektowym firmy Microsoft, ponieważ Microsoft, jeśli chodzi o migracj˛e z NT do Windows 2000, przewidział już duża˛ różnorodność dróg migracji oraz wiele możliwości restrukturyzacji. 3.7.5.3 Przeglad ˛ wariantów migracji Istnieja˛ nast˛epujace ˛ zasadniczo różne warianty migracji: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 177 ◦ czysta aktualizacja (Upgrade): należy zachować dotychczasowa˛ struktur˛e domen, co oznacza zaktualizowanie wszystkich domen. ◦ aktualizacja (Upgrade) plus restrukturyzacja: należy zaktualizować jedna˛ albo wi˛ecej domen. Pozostałe domeny NT należy dostosować 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) oznaczać b˛edzie zachowanie obecnej struktury domen. Możliwa jest późniejsza 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. Nast˛epnie odbywa si˛e 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 należy założyć nowa˛ domen˛e, wzgl˛ednie nowy AD. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 178 Rysunek 3.19: Migracja ADS - nowa domena plus restrukturyzacja Konta użytkowników oraz globalne grupy domeny kont klonowane sa˛ do nowej domeny (docelowej) (łacznie ˛ z SID-History). Rysunek 3.20: Migracja ADS - klony użytkowników i grup ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 179 Zaleta˛ powyższego sposobu post˛epowania jest to, że: ◦ migracja nie powoduje przerw w pracy użytkowników ◦ istnieje bardzo dobry Fallback ◦ można odsunać ˛ w czasie nowe przypisanie uprawnień (ReACLing); nie jest ono krytyczne, jeśli chodzi o czas. Wada˛ jest: ◦ konieczność istnienia dodatkowego ADS wraz z osprz˛etem. Wariant 4: świat równoległy a migracja zasobów Najpierw należy założyć nowa˛ domen˛e, wzgl˛ednie nowy ADS. Rysunek 3.21: Migracja ADS - świat równoległy a migracja zasobów Świat równoległy wypełniany jest nowymi kontami użytkowników i nowymi grupami. Dotychczasowe zasoby kopiowane sa˛ do nowego świata. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 180 Rysunek 3.22: Migracja ADS - wypełnianie równoległego świata kontami użytkownika oraz grupami Zaleta˛ powyższego rozwiazania ˛ jest to, że: ◦ migracja na serwerach nie jest krytyczna, jeśli chodzi o czas ◦ nie ma historii SID ◦ musza˛ być znane prawa dost˛epu i należy je odwzorować w nowym świecie ◦ migracja danych może oznaczać redukcj˛e danych. Wada˛ jest to, że: ◦ migracja danych wymaga dużych nakładów logistycznych, jeśli chodzi o wspólny dost˛ep ◦ w czasie migracji danych trzeba dysponować dodatkowym osprz˛etem ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.7.5.4 181 Zadania migracyjne Migracja (zastapienie ˛ NT) badź ˛ też całkowite wprowadzenie od nowa Windows 2000 Active Directory, wymaga starannego zaplanowania i oceny w środowiskach testowych. Podczas planowania migracji wymagane jest wykonanie nast˛epujacych ˛ zadań: ◦ prezentacja istniejacej ˛ infrastruktury w formie pisemnej ◦ rozpoznanie wymagań zwiazanych ˛ z nowym środowiskiem ◦ rozpoznanie technicznych oraz organizacyjnych warunków brzegowych ◦ ocena obecnego środowiska ◦ 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łościowej 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 systemów stacji roboczych. 3.7.5.5 Active Directory pod katem ˛ Windows 2003 Windows 2003 zachowuje zasadnicza˛ architektur˛e Active Directory. Istnieje jednak kilka zmian, które wymieniliśmy poniżej: ◦ Oprócz dotychczasowych typów (schema, configuration, domain) wprowadzony został dodatkowy typ partycji: Application Partition. Replikowanie tego typu nie jest wymagane wzgl˛edem wszystkich DCs domeny. Dzi˛eki temu możliwe jest tworzenie własnych partycji dla aplikacji innych producentów, na których można składać wi˛ecej dynamicznych danych. Takie dynamiczne dane można później lepiej kontrolować, jeśli chodzi o proces replikacji. Właśnie na takiej partycji należy składować dane DNS Active Directory zintegrowane w AD. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 182 ◦ Przewiduje si˛e, że Windows 2003 zaoferuje możliwość tworzenia oddzielnych serwerów LDAP bez konieczności instalowania DC. Takie serwery LDAP (ADAM = Active Directory Application Mode) dysponuja˛ własnym schematem, jednak podporzadkowuj ˛ a˛ si˛e usługom logowania AD. Tak wi˛ec powstaje możliwość tworzenia dla aplikacji usług LDAP, bez konieczności zmian schematu AD. 3.7.5.6 Active Directory w minimalnej postaci Jak już wspomnieliśmy, Active Directory oferuje łacznie ˛ wiele technologii i funkcjonalności, które zasadniczo ułatwiaja˛ korzystanie z nowych funkcji i / albo efektywna˛ prac˛e w środowiskach IT. W takich przypadkach rośnie zależność od produktów, wzgl˛ednie technologii firmy Microsoft. Jeśli nie chcemy, aby tak było, możemy wyznaczyć sobie cel, którym jest minimalne korzystanie z Windows 2000 Active Directory. Poniżej opisaliśmy pokrótce, jak mogłaby wygladać ˛ taka konstelacja. Active Directory stosowany w minimalnym zakresie posiada nast˛epujace ˛ właściwości, wzgl˛ednie prac˛e z nim należy podporzadkować ˛ nast˛epujacym ˛ krokom. ◦ Infrastruktura DNS powinna opierać si˛e nie na Windows 2000, lecz na niezależnej implementacji, która odpowiada minimalnym wymaganiom. Ewentualnie konieczne b˛edzie r˛eczne wprowadzanie SRV Records w DNS. ◦ Należy zrezygnować z jednej ogólnej struktury. Relacje zaufania pomi˛edzy domenami należy realizować w tradycyjny sposób. Cel: by każda dotychczasowa domena Windows NT mogła zarzadzać ˛ swoim własnym schematem we własnej ogólnej strukturze. ◦ Ponadto, jeśli domeny nie b˛eda˛ pracować w trybie „Native Mode“, wówczas zmniejszy si˛e „niebezpieczeństwo“ używania zwiazanych ˛ z nim, rozszerzonych grup. ◦ Należy także zrezygnować z budowy struktury OU wewnatrz ˛ domen. Cel: by poprzez utworzona˛ struktur˛e umożliwić działanie dodatkowych funkcji, tak aby móc si˛e „jednak później“ do nich odwołać. ◦ W „Default Domain Policy“ należy ograniczyć stosowanie wytycznych grup do ustawień bezpieczeństwa (np. hasła (czas ważności, minimalna długość, etc.), ustawień kontrolnych (Auditing)). Jest to konieczne do adekwatnego zastapienia ˛ ustawień Windows NT. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 183 ◦ Zasadniczo należy zrezygnować ze stosowania PKI (Public Key Infrastructure) opartych na AD, która byłaby wymagana, np. dla EFS albo IPsec. ◦ Należy zastosować DFS (Distributed File System) oparty na AD Cel: by uniknać ˛ dodatkowych zależności powstajacych ˛ w AD wskutek zintegrowanego zapisu. ◦ O ile nie jest wykorzystywany Exchange 2000, nie należy używać dodatkowych atrybutów obiektów użytkownika. Należy ograniczyć si˛e do stosowania obligatoryjnych atrybutów. Cel: by AD nie był stosowany jako miejsce zapisu danych osobowych, dzi˛eki czemu zredukuje si˛e możliwość powstawania dalszych zależności (np. aplikacje innych producentów, które wysyłaja˛ zapytania o te dane przez LDAP). ◦ Nie należy używać obiektów kontaktowych w AD. Cel: wskutek nagromadzenia tego typu informacji w AD, zwi˛eksza si˛e uzależnienie. ◦ Nie należy publikować drukarek lub zasobów w Active Directory. Cel: by użytkownicy nie przyzwyczaili si˛e do odnajdywania zasobów w ten sposób. Wskazówka: Wymienione właściwości / kroki z reguły przeszkadzaja˛ w osiagni˛ ˛ eciu maksymalnej wydajności, która˛ można uzyskać za pomoca˛ Active Directory. Jest to cena zwi˛ekszonej niezależności. W przeciwieństwie do tego sensowne jest stosowanie punktów centralnych wewnatrz ˛ ADS w celu sterowania procesem replikacji pomi˛edzy poszczególnymi lokacjami. W przypadku korzystania z Exchange 2000, który ma pracować poza zakresem domen w jednej organizacji Exchange, nie należy obchodzić użycia jednej ogólnej struktury, gdyż w przeciwnym razie zabraknie funkcji katalogu globalnego. 3.8 Middleware - COM, .NET, J2EE Z technicznej oceny wyraźnie wynika, że dotychczasowa technologia składników (COM, DCOM) firmy Microsoft jest wprawdzie nadal stosowana, lecz jednocześnie ma miejsce zmiana technologii zwiazana ˛ z wprowadzaniem .NET-Framework. Alternatywna˛ platforma˛ wspomnianej, nowej technologii może być Java 2 Enterprise Edition (J2EE). Zasadniczymi różnicami pomi˛edzy tymi dwiema technologiami, które odgrywaja˛ główne role, jeśli chodzi o oceniane w dalszej cz˛eści Web - Services, sa: ˛ uzależnienie od danej platformy, obsługiwane j˛ezyki programowania i ilość dostawców rozwiazań. ˛ Nast˛epujaca ˛ tabela wskazuje dalsze różnice. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 184 PARAMETRY J2EE .NET ogólnie standard przemysłowy jeden j˛ezyk - produkt-suite wiele j˛ezyków - wielu dostawców jeden dostawca Java C#, VB, C++, J#, j˛ezyki Java i inne . . . model składników Enterprise JavaBeans .NET (Web) Services; COM+ interpreter JRE (Java TM Runtime Environment) CLR (Common 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 dost˛ep 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 Beans firmy SUN. COM jest kontynuacja˛ OLE (Object Linking and Embedding), który służył w pierwszym rz˛edzie do tworzenia Compound Documents. COM jest standardem binarnym dla składników i dlatego jest niezależny od j˛ezyków programowania. Składniki COM można tworzyć za pomoca˛ różnych j˛ezyków programowania, do których należa˛ m.in.: ◦ C++ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 185 ◦ C ◦ Java ◦ Visual Basic ◦ Delphi. Jednocześnie w przypadku niektórych z w/w j˛ezyków składniki COM moga˛ być nawet ponownie używane. Jedynym wymaganiem wzgl˛edem j˛ezyka programowania jest to, żeby mogły być realizowane struktury instrukcji i by możliwe było zewn˛etrzne badź ˛ wewn˛etrzne wywoływanie funkcji za pomoca˛ instrukcji. J˛ezyki zorientowane obiektowo dostarczaja˛ mechanizmów, które ułatwiaja˛ implementacj˛e składników COM. Najcz˛estsza˛ forma, ˛ w jakiej wyst˛epuja˛ 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). Jeśli chodzi o protokoły transportu, COM oferuje, dzi˛eki usłudze Distributed COM (DCOM), neutralne Middleware umożliwiajace ˛ korzystanie z odległych składników na innych komputerach. DCOM należy do standardu Windows NT. Wywołanie składników na odległych komputerach opiera si˛e przy tym na Remote Procedure Calls (RPC). Osadzone jest tym samym w warstwie 7 ISO / OSI (Application Layer) i może w teorii działać na różnych protokołach transportu (np. TCP / IP, IPX / SPX), a także na HTTP. Korzystanie z HTTP możliwe jest za pomoca˛ COM Internet Services (CIS) z IIS w wersji 4, w którym protokół DCOM tunelowany jest przez HTTP. Bezpieczeństwem DCOM można zarzadzać ˛ stosujac ˛ DCOM Configuration Utility (DCOMCNFG.exe). Narz˛edzie to służy w szczególności do ustalenia, który wymiar impersonifikacji należy zastosować, czyli do ustalenia zdolności software routine do zmiany kontekstu użytkownika. Stosowanie składników COM możliwe jest tylko w Windows. Aplikacje, które z nich korzystaja,˛ trzeba dostosowywać do przeportowania na inna˛ platform˛e. Rozszerzeniem COM i DCOM w Windows 2000 jest COM+. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 186 3.8.2 „.NET” Na poczatku ˛ trzeba wyjaśnić kilka centralnych poj˛eć co rusz wyst˛epujacych ˛ w zwiazku ˛ z „.NET“. W tym celu przedstawiliśmy poniżej definicje 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 użytkowników w jeden jednolity i spersonalizowany sposób. .NET Framework: środowisko do rozwoju, udost˛epniania i wykonywania XML - Web Services i innych aplikacji. Składa si˛e 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 użytkownika i zbiór usług XML, które ułatwiaja˛ integracj˛e izolowanych „wysp plików“. .NET My Services zorientowane sa˛ na użytkownika a nie na określone urzadzenie, ˛ sieć albo aplikacj˛e. Platforma .NET: składa si˛e z narz˛edzi, urzadzeń, ˛ XML - Web Services oraz doświadczeń serwera i użytkowników W dalszej cz˛eści dokonaliśmy w pierwszym rz˛edzie bliższej oceny technologii .NET - Framework, jako rozwiazania ˛ Middleware. Jest ono w pewien sposób zbliżone do Java Virtual Machine (JVM), ponieważ poprzez instalacj˛e Frameworks (np. w Windows 2000) abstrahuje si˛e od interfejsów integralnych cz˛eści składowych systemu operacyjnego (np. API Win32) i sa˛ one oferowane w na nowo uporzadkowanej ˛ formie. Ma to w pierwszym rz˛edzie wpływ na rozwój aplikacji. Nast˛epujacy ˛ rysunek pokazuje składniki Frameworks. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 187 Rysunek 3.23: Składniki .Net-Frameworks Aplikacje pisane sa˛ w j˛ezyku obsługujacym ˛ „.NET“ i moga˛ odwoływać si˛e do obszernych bibliotek klas „.NET“. „.NET“ Framework obsługuje duża˛ ilość j˛ezyków programowania. Każdorazowy kompilator tłumaczy kod źródłowy na kod wykonywalny (a nie kod maszynowy), który określany jest mianem Intermediate Language (IL). Wynikiem niniejszej akcji jest, np. plik EXE. Jeśli 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 źródłowego Microsoft oferuje: ◦ z jednej strony bezpłatny Software Developer Kit (SDK), który wystarczy już do tworzenia programów „.NET“. ◦ z drugiej strony Visual Studio .NET, nast˛epc˛e dotychczasowego Visual Studio Version 6. .NET - Framework może być używany, w przeciwieństwie 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 pracujacych ˛ po stronie serwera. Ważnymi cz˛eściami składowymi technologii J2EE sa: ˛ ◦ Enterprise JavaBeans (EJB) Enterprise - Beans sa˛ składnikami po stronie serwera, które implementuja˛ logiczna˛ struktur˛e aplikacji. Moga˛ si˛e do nich odwoływać klienty. Enterprise - Beans instalowane sa˛ po stronie serwera w EJB - Container. Pojemnik udost˛epnia im określone usługi oraz środowiska runtime. ◦ Java Naming and Directory Interface (JNDI) Chodzi tu o usług˛e nazw i usług˛e katalogowa, ˛ która z jednej strony stwarza możliwość odkładania referencji do odległych obiektów – pod określona˛ nazwa˛ oraz – w zdefiniowanym miejscu (Binding). Z drugiej strony dzi˛eki JNDI możliwe jest odnajdywanie powiazanych ˛ obiektów poprzez ich nazwy (Lookup). ◦ Java IDL / CORBA Java IDL tworzy interfejs do CORBA, za pomoca˛ Java IDL można implementować Java ORBs. ◦ Java Remote Method Invocation (RMI) i RMI via IIOP (RMI - IIOP) RMI stosowana jest dla dzielonej komunikacji pomi˛edzy obiektami. Dzi˛eki RMI - IIOP, J2EE jest kompatybilna z CORBA. Oprócz tego istnieja˛ jeszcze nast˛epujace ˛ 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 można integrować różne platformy i aplikacje niezależnie od producenta, w oparciu o standardy. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 190 Zarówno .NET-Framework, jak i J2EE udost˛epniaja˛ zintegrowana˛ platform˛e do rozwoju i wykorzystywania Web-Services. J2EE i .NET nadaja˛ si˛e 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 sieć ◦ Internet jako centralna infrastruktura ◦ przegladarka ˛ WWW, jako nadrz˛edny User Interface, „Rich Clients“ jako podrz˛edny User Interface. Różnice pomi˛edzy obydwiema platformami zostały pokazane już podczas oceny .NET - Frameworks. Z powodu wyższej elastyczności, jak też niezależności od producenta czy platformy, należy uznać pierwszeństwo J2EE, co pokrywa si˛e także z zaleceniami SAGA 32. Jak jednak wyglada ˛ kompatybilność pomi˛edzy .NET i J2EE? Jeśli chodzi o Web - Services zachodzi ona, o ile wszyscy przestrzegaja˛ standardów (XML, SOAP, WSDL, UDDI). Jedyna˛ problematyczna˛ rzecza˛ jest wówczas tylko to, że SOAP w aktualnej wersji 1.1 zezwala jeszcze na bardzo duża˛ dowolność, co może prowadzić do praktycznej utraty kompatybilności. Jednak celem Web - Services musi być kompatybilność. Ma być ona szczególnie zagwarantowana przez SOAP w wersji 1.2. 3.9.2 Podstawy Web Service to usługa, do której może odwołać si˛e 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 przeźroczysta. Web Service jest „czarna˛ skrzynka“, ˛ która˛ można postrzegać jako określona˛ funkcjonalność i której można używać w sposób elastyczny bez znajomości szczegółów implementacji. Web Services udost˛epniaja˛ swoje funkcjonalności światu zewn˛etrznemu za pośrednictwem dobrze zdefiniowanych interfejsów. Interfejsy te nazywane sa˛ także Web 32 Standardy 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 j˛ezyka, tj. WebService Description Language (WSDL) (chodzi tu o plik XML). Programiści moga˛ na tej podstawie łaczyć ˛ ze soba˛ najróżniejsze usługi i integrować je w jedna˛ kompletna˛ aplikacj˛e. Wyszukiwanie takiej usługi może odbywać si˛e za pomoca˛ UDDI (Universal Description Discovery and Integration). UDDI jest specyfikacja˛ oparta˛ na standardach, służac ˛ a˛ do opisu i wyszukiwania Web Services, a zatem jest ona repozytorium Web Services. W tak zwanym mi˛edzyczasie firmy IBM, Microsoft i inni producenci stworzyli pierwsze implementacje. W przeciwieństwie do aktualnych obecnie technologii opartych na składnikach, Web Services nie wykorzystuja˛ protokołów „specyficznych dla obiektu“, takich jak DCOM, IIOP albo RMI, ponieważ z reguły wymagaja˛ one do płynnej pracy korzystania z homogenicznej infrastruktury, jeśli chodzi o klienta i serwer. Dlatego Web Services działaja˛ na innej zasadzie. Opieraja˛ si˛e one na standardach internetowych i wykorzystuja˛ „najmniejszy wspólny mianownik“: HTTP i XML (patrz rozdział 3.10). Za pomoca˛ HTML klient wysyła wiadomość opakowana˛ w XML do serwera, który odpowiada na zapytanie również wiadomościa˛ XML. W ten sposób Web Services sa˛ całkowicie niezależne od określonych j˛ezyków programowania i platform systemowych. Dopóki obydwie strony b˛eda˛ używały jednolitego formatu wiadomości i b˛eda˛ si˛e stosować do wspólnie zdefiniowanej kolejności wywołań, rodzaj implementacji usługi (Web Services) b˛edzie rzecza˛ drugoplanowa. ˛ Może on wyczerpać wszelkie możliwości platformy, na której jest właśnie używany. Uogólnieniem powyższej zasady jest SOAP. Simple Object Access Protokoll definiuje to, w jaki sposób musza˛ być zbudowane wiadomości XML i jak musi wygladać ˛ kolejność wywołań. Dzi˛eki temu najróżniejsze aplikacje, które pracuja˛ na różnych platformach, można ze soba˛ łaczyć ˛ i integrować z istniejacymi ˛ rozwiazaniami. ˛ Jedynym wymogiem jest to, żeby aplikacje te komunikowały si˛e ze soba˛ poprzez SOAP. Sam SOAP może nakładać si˛e na różne protokoły (np. HTTP, SMTP). SOAP jest prostym, nieskomplikowanym mechanizmem służacym ˛ do wymiany ustrukturyzowanych i wytypowanych informacji pomi˛edzy systemami w zdecentralizowanym, dzielonym środowisku za pomoca˛ XML. SOAP ma jednak wad˛e polegajac ˛ a˛ na tym, że jest dość wolny. Składa si˛e on z trzech cz˛eści. Okładka SOAP (envelope) definiuje Framework dla każdej wiadomości. Komunikuje ona odbiorcy, jaka˛ treść zawiera wiadomość, do kogo wiadomość jest skierowana i czy chodzi o wiadomość opcjonalna,˛ czy obligatoryjna. ˛ Istnieja˛ zasady kodowania; wewnatrz ˛ SOAP - Frameworks zasady kodowania określaja˛ sposób kodowania danych (np. liczb). XML wykazuje si˛e zasadami kodowania, które odznaczaja˛ si˛e duża˛ elastycznościa.˛ SOAP nie jest tak elastyczny, ponieważ definiowany tu jest ograniczony szereg zasad, co jednak nie ma znaczenia. Za pomoca˛ Web Services możliwa staje si˛e realizacja integracji różnych platform i aplikacji ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 192 niezależnie od producentów, w oparciu o standardy. Obydwie technologie, tj. .NET-Framework oraz J2EE udost˛epniaja˛ zintegrowana˛ platform˛e 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 przeważnie o nowe wydanie Windows DNA (Distributed interNet Applications Architecture). .NET zawiera własny Service Layer dla Web Services. Poniższy rysunek (rysunek 3.25) pokazuje zwiazki ˛ poszczególnych cz˛eści składowych pod katem ˛ Web Services. Rysunek 3.25: Microsoft .NET- Framework ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 193 Przez wprowadzenie technologii ASP.NET, nast˛epczyni Active Server Pager, zrealizowano nast˛epujace ˛ cele: ◦ uzyskano możliwie proste i zmienne środowisko programowania oraz ◦ omawiane Web Services. Z drugiej strony Visual Studio .NET oferuje możliwość pisania w wzgl˛ednie 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 si˛e na j˛ezyku programowania Java. Jego zaleta˛ jest to, że programów w nim napisanych można używać niezależnie od platformy. Pierwotnie J2EE była architektura˛ rozwijana˛ dla aplikacji pracujacych ˛ po stronie serwera. Później 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 logik˛e danych. Tworzy ona połaczenie ˛ z bazami danych za pośrednictwem JDBC (Java Database Connectivity) i może również korzystać z zewn˛etrznych Web Services. Dost˛ep do aplikacji J2EE możliwy jest z jednej strony dzi˛eki 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 bezpośredniego dost˛epu do składników EJB. Web Browser oraz urzadzenia ˛ bezprzewodowe zwiazane ˛ sa˛ ze składnikami EJB zazwyczaj poprzez Java Server Pages (JSP). Środowiska programowania oferowane sa˛ przez różnych 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 dajacego ˛ si˛e drukować łańcucha znaków. W porównaniu z HTML (Hypertext Markup Language) XML posiada nast˛epujace ˛ zalety: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 194 ◦ XML oddziela struktur˛e dokumentu od warstwy prezentacji. XML nie używa poleceń formatowania. Formatowanie musi być zdefiniowane poprzez Style Sheet. ◦ w XML istnieje możliwość zdefiniowania dowolnych struktur za pomoca˛ własnych elementów i atrybutów. ◦ za pomoca˛ parsera XML istnieje możliwość sprawdzania struktury pod katem ˛ jej ważności w oparciu o definicj˛e struktury. XML oczekuje tak zwanego „wellformedness“ (właściwego formułowania) osadzonego w regułach, np. „nazwy elementów rozróżniaja˛ pisowni˛e wielka˛ i mała˛ litera“. ˛ Dokumenty XML zawieraja˛ szczególne elementy, tj. Processing Instructions (PIs), w których można zapisywać instrukcje dla parsera XML (np. style sheets). Poprzez definicje struktury ustalane sa˛ obowiazuj ˛ ace ˛ struktury dokumentów XML. Nazywane sa˛ one także Vokabular. Definicje struktury moga˛ być tworzone za pomoca˛ Document Type Definition (DTD) albo schematów XML. Aby jednoznacznie zdefiniować nazwy elementów, można zdefiniować przestrzeń nazw jako XML - Namespace. XSL (Extensible Style Sheet Language) jest j˛ezykiem opartym na XML, służacym ˛ do konwersji dokumentów XML do HTML albo innych dokumentów XML. Konwersj˛e XSL wykonuje procesor XSL. XML już dzisiaj odgrywa duża˛ rol˛e, a w przyszłości jego rola, jako formatu wymiany danych, b˛edzie jeszcze wi˛eksza i tym samym stanie si˛e on istotnym elementem przyszłych aplikacji biurowych (m.in. dost˛epnych pakietów biurowych). Zwłaszcza wskutek rozdziału warstwy danych i warstwy prezentacji, XML umożliwia niezależna˛ od platformy prezentacj˛e wszystkich istnieja˛ cych danych i przede wszystkim edycj˛e danych (także treści dokumentów) ponad granicami systemu w taki sposób, że nikt nie musi si˛e troszczyć o prezentacj˛e. Doprowadzi to w przyszłości w dużym stopniu do wyraźnego wzrostu produkcyjności podczas tworzenia dokumentów. Obecnie użytkownicy pakietów biurowych sp˛edzaja˛ znaczna˛ cz˛eść swojego czasu pracy nad opracowywaniem właściwej formy dokumentu, który maja˛ stworzyć. Wymagana jest przy tym od użytkowników zdolność projektowania, pod katem ˛ której nie zostali wykształceni. Wskutek tego ukształtowanie dokumentu zajmuje wi˛ecej czasu, niż zadanie b˛edace ˛ sednem pracy powierzonej pracownikowi administracji. Dzi˛eki oddzieleniu warstwy treści od warstwy prezentacji pracownik administracji b˛edzie mógł znowu skoncentrować si˛e na swoich zadaniach i produktywnie wykorzystywać swój czas pracy. Prezentacj˛e treści b˛edzie można pozostawić odpowiedzialnym ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 195 osobom, które b˛eda˛ raz, centralnie i w jednolity sposób dla wszystkich ustalać i kotwiczyć definicje. XML jest również dość elastyczny, by można go było w każdej chwili dostosować do nowych potrzeb. Zgodnie z SAGA j˛ezyk XML powinien służyć jako uniwersalny i naczelny standard wymiany danych we wszystkich ważnych administracyjnych systemach informacyjnych 33. „Nowo tworzone systemy powinny być w stanie wymieniać dane w formacie XML. Istniejace ˛ systemy nie musza˛ obowiazkowo ˛ tego umieć“34. Także w tym punkcie firmy Microsoft i Sun sa˛ zgodne: XML jest podstawa˛ inteligentnych usług WWW. 3.11 Serwer WWW 3.11.1 Przeglad ˛ Jeśli chodzi o migracj˛e serwera WWW, oprócz kontynuacyjnych produktów Microsoft, takich jak Internet Information Server 5.0 i 6.0, rozwiazaniem ˛ alternatywnym jest również serwer Apache. Nie sa˛ znane ograniczenia techniczne, które uniemożliwiałyby korzystanie z serwera Apache. Oferuje on wszystkie funkcjonalności konieczne dla zastosowań produkcyjnych. W rzeczywistości Apache udowodnił swoja˛ przydatność w licznych scenariuszach zastosowań. W konkretnych przypadkach należy jednak dokładnie omówić nakłady zwiazane ˛ z projektem migracyjnym. W przypadku migracji prostych stron HTML badź ˛ aplikacji CGI, nakłady migracyjne z reguły utrzymaja˛ si˛e w przewidywalnych ramach. W przeciwieństwie do tego, migracja aplikacji, w szczególności służacych ˛ do generowania dynamicznych treści w oparciu o technologi˛e ASP, wymaga na ogół nowej implementacji aplikacji, co zwi˛eksza nakłady. Jednak z technicznego punktu widzenia nie stanowi to problemu, ponieważ istnieje do dyspozycji wystarczajaca ˛ ilość alternatywnych technologii, takich jak PHP i JSP. 33 Standardy 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 34 Standardy 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 si˛e na protokole HTTP (Hypertext Transfer Protocol) i j˛ezyku opisu strony HTML (Hypertext Markup Language). Serwer przejmuje zadanie udzielania odpowiedzi na zapytania klienta i przesyłania żadanych ˛ treści. Zadaniem serwerów WWW jest także dostarczanie żadanych ˛ dynamicznych treści, np. poprzez aplikacj˛e bazodanowa˛ do systemów klienckich. Za pośrednictwem określonych interfejsów możliwe jest również zlecenie uruchamiania po stronie serwera całych programów oraz wykonywania akcji. Akcje inicjalizowane sa˛ z reguły przez systemy klienckie. Umożliwia to wykonywanie procesów klienta po stronie serwera. Wskutek rozprzestrzeniania si˛e Internetu badź ˛ rozwiazań ˛ intranetowych nastapił ˛ wzrost wymagań wzgl˛edem zadań realizowanych przez serwery WWW. Doprowadziło to do powstania różnych rozwiazań ˛ 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 Intranetu. ISS 4.0 jest cz˛eścia˛ Windows NT Server 4.0 Option Pack. W oparciu o system operacyjny Windows NT 4.0 za pomoca˛ ISS udost˛epniane sa˛ podstawowe funkcjonalności serwera WWW. W celu zapewnienia sukcesywnej współpracy klienta z serwerem obsługiwane sa˛ tu wszystkie ważne protokoły internetowe: ◦ HTTP 1.1 ◦ SMTP ◦ NNTP ◦ FTP. Obsługa HTTP w ISS 4.0 obejmuje nast˛epujace ˛ usługi: ◦ Pipelining umożliwia wysyłanie wielu żadań ˛ klientów zanim nastapi ˛ reakcja serwera WWW. ◦ Keep Alives Dzi˛eki utrzymaniu połaczeń ˛ klient - serwer klient może używać dla wielu żadań ˛ jednego połaczenia ˛ albo mniejszej ilości połaczeń. ˛ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 197 ◦ HTTP PUT i DELETE umożliwia usuwanie albo udost˛epnianie plików przez użytkowników poprzez przegladark˛ ˛ e WWW. Obsługa RFC 1867 umożliwia także sterowanie uploads plików za pomoca˛ innych programów. Obsługa SMTP udost˛epniana jest poprzez zaimplementowana˛ usług˛e SMTP - Mail służac ˛ a˛ do wysyłania i odbierania wiadomości SMTP - Mail. Usług˛e t˛e można stosować do komunikacji pomi˛edzy serwerem WWW i na przykład klientami. Zintegrowana usługa NNTP (Network News Transport Protocol) umożliwia zakładanie lokalnych grup dyskusyjnych na pojedynczym serwerze. Nie jest możliwa obsługa Newsfeed ani replikacja. 3.11.3.1 Aplikacje Web Internet Information Server oferuje nast˛epujace ˛ rozszerzenia dla serwera: ◦ programy CGI ◦ aplikacje ISAPI ◦ aplikacje ASP. Common Gateway Interface (CGI) stwarza możliwość generowania dynamicznych treści. CGI jest interfejsem służacym ˛ do wywoływania programów, którymi może posługiwać si˛e serwer. Pierwotnie CGI zaprojektowane zostało dla środowisk UNIX i w środowisku Windows NT wymaga bardzo wielu zasobów systemowych. Programy CGI maj˛e t˛e zalet˛e, że moga˛ być wykonywane przez niemal każdy serwer WWW oraz, że z reguły można je łatwo napisać. Internet Service Application Programming Interface (ISAPI) jest bezpośrednim interfejsem do IIS. Poprzez ISAPI można odwoływać si˛e do obiektów umieszczonych na serwerze. IIS 4.0 umożliwia, wskutek zastosowania Active Server Pages (ASP), tworzenie dynamicznych stron HTML albo aplikacji WWW. Za pomoca˛ technologii ASP udost˛epniane jest środowisko skryptowe po stronie serwera. Strony ASP sa˛ plikami, które oprócz tradycyjnych znaczników HTML moga˛ także zawierać instrukcje skryptowe. Odpowiednie instrukcje skryptowe wykonywane sa˛ na serwerze i wykorzystywane do tworzenia kodu HTML. Dynamiczny i statyczny kod HTML przesyłany jest z powrotem, w formie strony HTML, do przegladarki ˛ WWW, która wysłała zapytanie. Stosowanie stron ASP umożliwia kształtowanie interaktywnych treści dla użytkowników. Za pomoca˛ ASP można także realizować odwoływanie si˛e do bazy danych. W zwiazku ˛ z rozwojem stron WWW ISS 4.0 obsługuje nast˛epujace ˛ technologie: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 198 ◦ Microsoft Script Debugger umożliwia testowanie aplikacji ASP. ◦ Interfejs programowania COM umożliwia programistom dost˛ep do składników COM, które odwołuja˛ si˛e do funkcji protokołu ISS. ◦ Java Virtual Machine umożliwia tworzenie i wykonywanie składników Java wewnatrz ˛ maszyny wirtualnej. ◦ Obiekty administracyjne ISS umożliwiaja˛ programistom dost˛ep do składników niezb˛ednych do tworzenia programów administrujacych. ˛ ◦ Transakcyjne strony ASP umożliwiaja˛ stronom ASP i wywoływanym przez nie składnikom bycie cz˛eścia˛ transakcji, która to transakcja musi być jednak zarzadzana ˛ przez Microsoft Transaction Server (patrz także 3.11.3.3). ◦ Izolowanie procesów dzi˛eki tej technologii aplikacje ASP oraz ISAPI (Internet Server - API) moga˛ być wykonywane jako oddzielne procesy. Procesy te wykonywane sa˛ oprócz głównego procesu serwera. ◦ Załaczanie ˛ i odłaczanie ˛ składników oznacza, że programiści WWW moga˛ właczać ˛ albo odłaczać ˛ dynamiczne składniki aplikacji WWW. 3.11.3.2 Autoryzacja i bezpieczeństwo Model bezpieczeństwa jest jednakowy dla wszystkich składników serwera NT. W przypadku IIS można używać takich samych funkcji, jakimi dysponuje serwer plików albo serwer bazy danych. Można skorzystać z istniejacych ˛ użytkowników domen i grup w celu nadania ograniczonych i uprawnień. IIS korzysta z takiej samej bazy danych katalogów, jak inne serwery Windows NT. Użytkownikom można umożliwić ograniczony dost˛ep do zasobów sieciowych, takich jak strony HTML, aplikacje WWW oraz pliki. W celu dokładnego przydzielenia uprawnień można także skorzystać z uprawnień systemu plików NTFS. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 199 Zastosowanie Secure Sockets Layer (SSL umożliwia bezpieczna˛ wymian˛e informacji pomi˛edzy klientem a serwerem. Istnieje również możliwość, aby serwery identyfikowały albo autoryzowały klienta a użytkownik nie musiał logować si˛e na serwerze. Zintegrowany Certificate Server oferuje możliwość utworzenia instancji certyfikujacej ˛ i udost˛epnienia 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 funkcjonalności serwera WWW. Składniki opisane poniżej sa˛ również cz˛eścia˛ Windows NT Option Pack. Microsoft Transaction Server (MTS) MTS jest systemem przetwarzajacym ˛ transakcje służacym ˛ do rozwoju, implementacji i zarzadza˛ nia dzielonymi aplikacjami serwera. Przetwarzanie transakcji można wykorzystać na przykład do realizacji dzielonych aplikacji biznesowych. Microsoft Script Debugger Microsoft Script Debugger służy do wyszukiwania bł˛edów w składni plików ASP. Debugger można wykonywać w połaczeniu ˛ z Internet Explorer i w ten sposób korygować bł˛edy. Microsoft Index Server Index Server można wykorzystywać w Internecie i / lub Intranecie jako wyszukiwark˛e. Serwer może naznaczać teksty zapisanej zawartości, która˛ można udost˛epniać użytkownikom do przeszukiwania poprzez formularze WWW. Index Server może oprócz dokumentów HTML naznaczać także dokumenty Microsoft Word i Microsoft Excel. Microsoft Message Queue Server Microsoft Message Queue Server (MMQS) pozwala asynchronicznie komunikować ze soba˛ programy użytkowe poprzez wysyłanie i odbieranie wiadomości. Microsoft Management Console Microsoft Management Console (MMC) umożliwia zarzadzanie ˛ najróżniejszymi zadaniami poprzez różne sieciowe programy zarzadzaj ˛ ace. ˛ Administrowanie serwerem może odbywać si˛e za pomoca˛ tak zwanych „Snap - Ins“ wewnatrz ˛ konsoli. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 200 3.11.4 Migracja zast˛epujaca ˛ 3.11.4.1 Apache Aplikacja˛ bardzo cz˛esto stosowana˛ w praktyce w systemach opartych na Linuksie jest serwer Apache. Jest on najcz˛eściej, bo aż w 60%, wykorzystywanym serwerem WWW 35 na świecie. Jest wolno dost˛epny i udost˛epniany na licencji Apache Software. Serwer Apache jest jednym z odnoszacych ˛ najwi˛eksze sukcesy projektów Open Source Community. Projekt ten rozwinał ˛ si˛e z serwera (National Center for Supercomputing Application, University NCSA Illinois), do którego dodawano coraz wi˛eksza˛ ilość łat. („A patchy web server") i który w 1995 roku posłużył jako podstawa dla pierwszej wersji beta. W tak zwanym mi˛edzyczasie został on przeportowany do niemal wszystkich platform. Serwer Apache jest dzisiaj najbardziej rozpowszechnionym serwerem WWW na platformach Linux / UNIX, jednak działa także z całym szeregiem innych platform, takich jak Windows NT czy Novell Netware. Poczawszy ˛ od wersji 2.0.35 z kwietnia 2002 roku seria 2.0 serwera Apache udost˛epniana 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 dost˛epna jest w wersji 1.3.27. Dzi˛eki zapisom licencyjnym i swojej wysokiej jakości serwer Apache wykorzystywany jest również w produktach komercyjnych. IBM dostarcza na przykład Apache w ramach produktów Websphere. Zakres funkcji Serwer WWW Apache składa si˛e z rdzenia i dużej ilości modułów, które można wkompilować badź ˛ właczać ˛ w zależności od każdorazowych wymagań. Dzi˛eki modularnej budowie zakres funkcji serwera Apache daje si˛e bardzo łatwo rozszerzać i można go dopasowywać do zmienionych wymagań. Normalny zakres dostawy oprogramowania zawiera już wiele różnych modułów, które można jeszcze uzupełnić o dalsze moduły (np. własne). Moduły Apache sa˛ segmentami kodu, które odpowiadaja˛ specyfikacji API Apache i moga˛ być właczane ˛ do serwera Apache. Moduły Apache moga˛ być właczane ˛ statycznie na stałe albo dynamicznie poprzez plik konfiguracyjny serwera WWW. Taka modularna budowa służaca ˛ rozszerzeniu właściwości serwera WWW niezwykle podnosi elastyczność systemu. Wydajność i pr˛edkość serwera WWW wzrasta, gdy zamiast zewn˛etrznych aplikacji przetwarzane moga˛ być procesy wewn˛etrzne. Wśród wielu modułów znajduja˛ si˛e moduły autoryzacji, bezpieczeństwa i skryptów, wzgl˛ed35 http://news.netcraft.com/archives/2003/03/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 201 nie interpreterów j˛ezyków programowania, takich jak, np. PHP, Java, Python, Tcl i Perl. Istnieja˛ dwie różne możliwości korzystania z modułów: ◦ podczas statycznej kompilacji moduły moga˛ być na stałe właczone ˛ do serwera WWW. ◦ moduły moga˛ być właczane ˛ dynamicznie podczas pracy serwera. Ta tak zwana funkcjonalność DSO (Dynamic Shared Objects) nie wymaga w przypadku zmiany konfiguracji serwera ponownej kompilacji. Wystarczy ponownie uruchomić serwer. Możliwy jest Graceful-Restart bez przerywania świadczenia usług. Podczas, gdy wykorzystywane sa˛ rzeczywiście potrzebne moduły, Apache pozostaje mniejszy niż jego standardowa wersja i zajmuje mniej miejsca w pami˛eci. Jednocześnie mniej modułów oznacza także mniejsza˛ możliwa˛ powierzchni˛e ataku, dzi˛eki czemu wzrasta bezpieczeństwo systemu. Nast˛epujaca ˛ tabela przedstawia mały wybór dost˛epnych modułów. M ODUŁ F UNKCJA 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 bezpośrednio poprzez HTTP na serwerze WWW. DAV oznacza Distributed Authoring and Versioning. mod_fastcgi mod_frontpage Zintegrowana obsługa FastCGI. 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 Udost˛epnia instrukcje Alias badź ˛ Redirect. mod_autoindex mod_include mod_mime mod_log_config Generuje naznaczanie katalogów. Jest potrzebna dla Server - Sides Includes. Zapewnia generowanie odpowiednich MIME - Headers. Potrzebny do prowadzenia jednego albo wielu Logfiles. Istnieje możliwość dostosowania treści do odpowiednich potrzeb. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI mod_deflate 202 Służy do kompresji różnych typów danych przed transmisja˛ do przegladarki ˛ WWW. Ma sens zwłaszcza w przypadku ograniczonych pasm. Kompresja musi być obsługiwana przez przegladark˛ ˛ e. mod_proxy Rozszerza serwer WWW Apache o funkcjonalność serwera pośredniczacego ˛ badź ˛ Proxy - Caches. mod_rewrite Umożliwia stosowanie dowiazań ˛ wewn˛etrznych i zewn˛etrzne Redirects. mod_speling Koryguje bł˛edy użytkowników w pisowni. mod_ssl Udost˛epnia protokoły SSL (Secure Sockets Layer) oraz TLS (Transport Layer Security). mod_usertrack Za pomoca˛ HTTP-Cookies protokołowane jest zachowanie użytkowników. mod_vhost_alias Służy do masowej konfiguracji wirtualnych hostów, szczególnie interesujace ˛ dla Service - Provider. Moduły autoryzacji mod_access mod_auth Kontrola dost˛epu w oparciu o nazwy hostów albo adresy IP. Służy do konfiguracji katalogów badź ˛ dokumentów chronionych hasłami. Bardzo prosty wariant modułu autoryzacji. Powinien być stosowany tylko dla małej ilości użytkowników. mod_auth_digest Autoryzacja użytkowników za pomoca˛ MD5 Digest Authentication. Transmisja haseł nie odbywa si˛e w formie czytelnego tekstu. mod_auth-dbm Autoryzacja użytkowników za pomoca˛ plików Berkeley DB. Ma sens w przypadku zastosowania dla wi˛ekszej ilości użytkowników. mod_auth_ldap Autoryzacja użytkowników za pomoca˛ LDAP. mod_auth_kerb Autoryzacja użytkowników za pomoca˛ Kerberos. Obsługuje wersje 4 i 5. mod_auth_notes Autoryzacja użytkowników za pomoca˛ serwera Lotus Notes. mod_auth_oracle Autoryzacja użytkowników za pomoca˛ bazy danych Oracle. Istnieja˛ także jeszcze inne moduły, np. dla baz danych MySQL i PostgreSQL. mod_auth_smb Autoryzacja użytkownika za pomoca˛ serwera SMB (Samba, Windows NT). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 203 Tablica 3.30: Moduły Apache Powyższy spis dost˛epnych modułów nie jest pełny i przedstawia tylko wycinek możliwości serwera Apache. Jednak nie wszystkie moduły dla w/w serwera WWW sa˛ dost˛epne nieodpłatnie. Pojawiaja˛ si˛e coraz to nowe przedsi˛ebiorstwa oferujace ˛ komercyjne natywne moduły Apache. Sa˛ to, np.: ◦ Allaire z Java-Servlet-Engine Macromedia JRun i serwerem aplikacji Macromedia ColdFusion, ◦ Sun Microsystems z modułem Active Server Pages. Tematy pokrewne W celu zintegrowania funkcjonalności wyszukiwania za pomoca˛ strony WWW, serwer Apache można uzupełnić o odpowiedni program. Do wyboru istnieja˛ różne jednostki oprogramowania. Poniżej przykładowo opisaliśmy system wyszukiwania HTDig 36. HTDig umożliwia indeksowanie całych stron WWW. Program ten tworzy, za pomoca˛ tak zwanego Rebots, indeks wyszukiwania, który można odpytywać korzystajac ˛ z przeznaczonych do tego skryptów CGI. Nast˛epujace ˛ punkty oddaja˛ najważniejsze funkcjonalności programu: ◦ założenie indeksu przeszukiwanych maszyn (obejmujacego ˛ jedna˛ lub wi˛ecej stron WWW badź ˛ obszary strony WWW). ◦ ograniczenie indeksowania dzi˛eki zastosowaniu filtrów. Kryteriami filtrowania moga˛ być typy plików i określone adresy URL. ◦ dzi˛eki zastosowaniu zewn˛etrznego dodatkowego oprogramowania można indeksować także formaty plików (PDF. DOC, itd.). ◦ istnieja˛ liczne możliwości odpytywania i można korzystać z wielu algorytmów wyszukiwania (słowa, cz˛eści słów, synonimy, itd.). ◦ za pomoca˛ prostych plików template można dostosowywać stron˛e wyszukiwania i odpowiednia˛ list˛e trafień. ◦ wewnatrz ˛ wyszukiwanych poj˛eć obsługiwane sa˛ znaki narodowe. 36 http://www.htdig.org/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 204 ◦ stosowany Rebot obsługuje standard „Rebot Exclusion“ oraz „Basic - WWW - Authentication“ do indeksowania chronionych treści. HTDig jest rozpowszechniany na licencji GNU General Public Licence (GPL) i tym samym wolno dost˛epny. Administrowanie Konfiguracja zainstalowanego Apache jest zadaniem wzgl˛ednie prostym, ponieważ dla wi˛ekszości konfiguracji wymagana jest tylko zmiana albo dodanie wpisów w dobrze udokumentowanym pliku. Jest to plik tekstowy, który można edytować za pomoca˛ edytora tekstu. Dla administratorów preferujacych ˛ interfejs graficzny istnieje kilka komercyjnych i niekomercyjnych 37 projektów GUI Apache . Migracja W ramach migracji należy rozróżnić, jakich danych badź ˛ treści ma dotyczyć migracja. Można tu wyszczególnić: ◦ 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 Treści statyczne, także czyste strony HTML, można eksportować do nowego serwera WWW bez ich dalszego dopasowywania i moga˛ one, w przypadku migracji do nowego serwera WWW, ewentualnie powodować jedynie minimalne problemy i nakłady. 37 patrz także 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ównież specyficzny standard CGI. Określa on sposób integracji programów i serwera WWW. Standard ten nie jest specyficzny dla danego j˛ezyka programowania i jest obsługiwany przez serwer WWW. Podczas tworzenia programów CGI skorzystać można z licznych możliwości. Jednym z najbardziej rozpowszechnionych oraz dostosowanych do portów jest j˛ezyk skryptowy Perl. Perl dost˛epny jest dla systemów MS - DOS, UNIX / Linux, OS / 2, Macintosh i każdej wersji Windows. Perl oferuje także programistom WWW obszerne możliwości manipulacji tekstem i danymi. Aplikacje, które napisane zostały w Perlu, można bardzo łatwo migrować do Apache. Apache zapewnia dzi˛eki modułowi „mod_perl“ pełna˛ implementacja˛ Perla. Ponadto cz˛esto pozwala on uzyskać lepsza˛ wydajność podczas wykonywania w/w skryptów. Moduł Perla wpisuje interpreter Perla w serwer Apache, dzi˛eki czemu aby wykonać kod programu nie musi być już wykonywany oddzielny proces i można uzyskać znaczny przyrost pr˛edkości. W przypadku portowania aplikacji perlowych konieczne jest tylko dokonanie minimalnych zmian w kodzie programu. PHP jest jednym z najszybciej rozprzestrzeniajacych ˛ si˛e j˛ezyków skryptowych, który odznacza si˛e bardzo dobra˛ obsługa˛ różnych systemów baz danych oraz wzgl˛ednie prosta˛ składnia.˛ PHP można, podobnie jak Perla, stosować na wielu różnych systemach. Aplikacje PHP, które zostały zaprojektowane dla Internet Information Server, można przy minimalnym nakładzie przeportować do serwera WWW Apache. ISAPI Aplikacje korzystajace ˛ z ISAPI można stosować kontynuacyjnie tylko w przypadku tych serwerów Apache, które działaja˛ w systemie opartym na Windows NT albo Windows 2000. Apache w systemach windowsowych zawiera jako standardowa˛ funkcjonalność zapewniajac ˛ a˛ całkowita˛ kompatybilność z ISAPI. Aplikacje wymagaja˛ jedynie ponownej kompilacji w nowym środowisku Apache. Na ogół nie jest wymagana zmiana kodu, jednak nie ma obsługi filtrów ISAPI oraz rozszerzeń Microsoft dla asynchronicznych operacji na plikach. ASP Aplikacje oparte na technologii ASP zaprojektowane zostały z reguły w celu generowania dynamicznych treści WWW. Można przy tym stosować różne podstawy: ◦ Visual Basic Script (VBScript) ◦ JScript ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 206 oraz ◦ Active X Data Objects (ADO) dla dost˛epu do baz danych. Aby móc wykonywać strony ASP na serwerze WWW Apache, potrzebne jest kompletne środowisko programowania kompatybilne z Microsoft (VBScript, JScript, ADO). Firma Sun Microsystems oferuje wraz ze swoim produktem „Sun One Active Server Pages 4.0“ 38 kompatybilne środowisko do wykonywania stron ASP wewnatrz ˛ serwera WWW Apache. Serwer WWW może pracować w systemie operacyjnym NT badź ˛ w systemie Unix / Linux. ◦ Produkt ten obsługuje: ◦ ASP 3.0 ◦ VBScript 5.5 ◦ JScript 5.5. Aby przeprowadzić migracj˛e do serwera WWW Apache pracujacego ˛ na systemie linuksowym należy w pierwszym kroku skopiować wszystkie pliki ASP do nowej platformy docelowej. W kolejnym kroku wewnatrz ˛ aplikacji ASP należy określić wykorzystywane obiekty COM i zsynchronizować je z obiektami obsługiwanymi w Linuksie. Liczne obiekty obsługiwane sa˛ przez Sun One ASP. Jeśli potrzebny obiekt nie jest obsługiwany, wówczas istnieje możliwość zastosowania dostarczanego COM - to - Java Bridge i zaimplementowania funkcjonalności za pomoca˛ Java. Dodatkowo należy jeszcze sprawdzić zmiany pod katem ˛ pisowni wielka˛ i mała˛ litera˛ oraz wersj˛e ASP Engine badź ˛ Scripting Engine. Dokładny opis znajduje si˛e w odpowiedniej dokumentacji. Migracja wymagana w przypadku bazy danych nie jest omawiana w niniejszym podrozdziale. Dokładne informacje na ten temat znaleźć można w rozdziale 3.13, Bazy danych. Oprócz możliwości zachowania aplikacji ASP w ich dotychczasowej formie, istnieje oczywiście także możliwość zastosowania alternatywnych technologii. Rozwiazanie ˛ takie nasuwa si˛e, gdy wyraźnie chcemy uzyskać wi˛eksza˛ niezależność od platformy. Należy jednak liczyć si˛e wówczas z wi˛ekszymi nakładami migracyjnymi, gdyż realizacja aplikacji w nowej technologii z reguły powoduje zwi˛ekszone nakłady. Jednakże taki proces migracji można także wykorzystać do konsolidacji i optymalizacji treści i aplikacji. Prawdziwa˛ alternatywna˛ metoda˛ dla realizacji celów spełnianych przez aplikacje może być zastosowanie technologii PHP. Ulubiona platforma (LAMP), która szczególnie w ostatnich latach służy do generowania treści stron WWW, składa si˛e z kombinacji: 38 patrz także http://sun.de/Produkte/software/chilisoft/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 207 ◦ GNU/Linux ◦ Apache ◦ MySQL ◦ PHP. Jeśli chodzi o przekształcanie aplikacji ASP do PHP, pomóc może ewentualnie ocena treści projektu „ASP - to - PHP“39. Projekt ten udost˛epnia na swojej stronie domowej konwerter ASP - to - PHP i oferuje wsparcie w ramach listy dyskusyjnej. Oprócz powyższej możliwości można także rozważyć zastosowanie technologii opartej na Java. Aplikacje WWW oparte na Java sa˛ interesujac ˛ a˛ alternatywa˛ dla aplikacji WWW opartych na ASP. Obecnie najcz˛eściej stosowane aplikacje Java opieraja˛ si˛e na specyfikacjach Sun Microsystems Java 2 Standard Edition (J2SE) oraz Java 2 Enterprise Edition (J2EE). Technologia Java opierajac ˛ si˛e na standardzie przemysłowym oferuje zalet˛e niezależności od platformy. Aplikacje WWW J2SE pozwalaja˛ na tworzenie dynamicznych treści za pomoca˛ Java Server Pages (JSP) i Java Servlets. Obydwie technologie umożliwiaja˛ m.in. rozwój osobistych treści i dost˛ep do zewn˛etrznych źródeł danych. W celu wykonywania stron JSP i Servletów można skorzystać z produktu Open source „Tomcat“40 . Projekt Tomcat stworzony został w kontekście Apache Software Foundation (ASF). Tomcat oferuje skalowalne środowisko wykonywania stron JSP oraz Java - Servlets i tym samym jest bardzo dobra˛ alternatywa˛ dla rozwiazań ˛ ASP w przypadku aplikacji nie zawierajacych ˛ 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 funkcjonalności można si˛egnać ˛ po standardy Java 2 Enterprise Edition. Za pomoca˛ tak zwanych Enterprise Java Beans (EJB) można realizować aplikacje dla skomplikowanych procesów i reguł biznesowych, które jednocześnie wymagaja˛ dost˛epu do systemów zewn˛etrznych. Środowisko J2EE wymaga serwera aplikacji, który przejmie wykonywanie EJB. Serwer aplikacji musi być w stanie zagwarantować zarzadzanie ˛ sesja˛ użytkowników, oferować odpowiednie interfejsy do zewn˛etrznych aplikacji i zapewnić konieczna, ˛ wysoka˛ niezawodność (Cluster, Load - Balancing, Failover). Oprócz znanych komercyjnych produktów, takich jak, np. IBM Websphere, BEA Weblogic, Oracle Application Server i kilku innych, istnieje także możliwość zastosowanie produktu Open Source. Projekt „JBoss41 “ oferuje pełny Java - Applications - Server. Serwer ten obsługuje 39 http://asp2php.naken.cc http://jakarta.apache.org/tomcat/index.html 41 http://www.jboss.org 40 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 208 specyfikacj˛e J2EE, oferuje zintegrowany serwer WWW, JSP Engine i Servlet Engine, obsług˛e Enterprise Java Beans, ponadto Clustering i liczne dalsze funkcjonalności. Szczegółowy opis procedur migracji aplikacji ASP do technologii opartych na Java oferuj˛e na przykład także przedsi˛ebiorstwa SUN42 i Oracle43, dlatego w tym miejscu z niego zrezygnujemy. 3.11.5 Migracja kontynuacyjna 3.11.5.1 Internet Information Server 5.0 Nowości Internet Information Server jest integralna˛ cz˛eścia˛ składowa˛ serwera Windows 2000. Kolejna wersja Internet Information Server 4.0 posiada cały szereg nowych funkcjonalności. Najważniejsze nowości zostały przedstawione w poniższej tabeli: F UNKCJA O PIS Udost˛epnianie danych WebDAV katalogi WWW Obsługa standardu WebDAV w celu wspólnej edycji plików i katalogów bezpośrednio poprzez HTTP po stronie serwera. Obsługa katalogów WWW. Służa˛ użytkownikom jako tradycyjne katalogi plików na serwerze WWW i bezpośrednio zwiazane ˛ sa˛ z funkcjonalnościa˛ WebDAV. obsługa Frontpage Umożliwia tworzenie i zarzadzanie ˛ treściami WWW za pomoca˛ Microsoft Frontpage. Za pomoca˛ graficznej Frontend administrator może tworzyć i zmieniać treści WWW na serwerze. obsługa multiplen web Umożliwia hosting różnych stron WWW na jednym serwerze i - sites jednym adresie IP. Umożliwia kompresj˛e HTTP podczas komunikacji pomi˛edzy ser- kompresja HTTP 1.1 werem WWW i systemami klienta obsługujacymi ˛ kompresj˛e. Ma sens zwłaszcza w przypadku ograniczonej szerokości pasma. 42 43 http://developer.iplanet.com/docs/migration/webserver/IIS_50.pdf http://otn.oracle.com/tech/migration/asp/content.html ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 209 „Platform for Internet Content Selection"44 - Rating jest technicznym standardem służacym ˛ do wdrażania systemu oceny treści stron WWW wprowadzonym przez konsorcjum W3. PICS ła˛ PICS Rating czy ocen˛e treści z możliwościa˛ filtrowania stron WWW według określonych cech. W tym celu należy wprowadzić w nagłówkach HTML dokumentu kod PICS, który nie jest widoczny w przegla˛ darce WWW. Aplikacje oparte na WWW integracja XML składniki skryptów XML - Parser w Windows 2000 jest zaimplementowany jako składnik COM i udost˛epnia pełna˛ podstaw˛e XML dla aplikacji. Developerzy moga˛ za pomoca˛ technologii skryptowej rozwijać windowsowych dla aplikacji WWW moduły COM dajace ˛ si˛e ponownie wykorzystać. określanie właściwości Za pomoca˛ ASP można ustalić dokładne właściwości przegla˛ przegladarki ˛ WWW darki WWW systemów klienckich. rozdzielanie procesów Administrator może izolować pojedyncze procesy aplikacji od procesów głównych i innych procesów aplikacji. Umożliwia dost˛ep do obiektów, właściwości i metod Active Di- ADSI 2.0 rectory Service Interface. Integracja serwera WWW i Active Directory umożliwia przypisanie różnych stron WWW na serwerze WWW do określonych domen użytkowników. Administrowanie delegacja zarzadzania ˛ Umożliwia przekazanie zadań administracyjnych. Umożliwia ograniczenie czasu CPU dla aplikacji albo strony throttling DFS WWW. Dzi˛eki temu można zapewnić dost˛epność czasu procesora dla innych stron WWW albo aplikacji niesieciowych. Distributed File System to system plików umożliwiajacy ˛ przeźroczyste rozdzielanie plików pomi˛edzy wiele komputerów. Może być używany dla dokumentów root w miejscu, w którym w systemie plików składowane sa˛ treści WWW. 44 http://www.w3.org/PICS/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 210 Autoryzacja i bezpieczeństwo Autoryzacja użytkowników może odbywać si˛e za pomoca˛ KerbeKerberos ros. Jednak nadal dost˛epna jest stara metoda logowania do Windows za pomoca˛ Windows LAN Manager (NTLM). szyfrowanie autoryzacja Digest Zastosowanie SSL 3.0 i TLS (Transport Layer Security) do szyfrowanej transmisji danych. Umożliwia transmisj˛e zaszyfrowanych haseł wymaganych dla autoryzacji. ograniczenia domen i Administrator otrzymuje możliwość udost˛epniania badź ˛ bloko- IP wania komputerom i domenom dost˛epu do zawartości. certyfikaty Obsługa certyfikatów klienta i serwera. Tablica 3.32: Rozszerzone funkcjonalności Internet Information Server 5.0 3.11.5.2 Internet Information Server 6.0 Do zakresu dostawy Windows Server 2003 należy Internet Information Server 6.0 (ISS 6.0), który podczas standardowej instalacji jest poczatkowo ˛ całkowicie zablokowany i nie jest automatycznie zintegrowany z systemem. Administrator musi z zewnatrz ˛ uruchomić proces instalacji serwera oraz aktywować poszczególne jego funkcjonalności. Z połaczenia ˛ nast˛epujacych ˛ technologii z grupy produktów serwera Windows 2003: ◦ Internet Information Server 6.0 ◦ ASP.NET ◦ ASP ◦ COM+ ◦ Microsoft Message Queuing (MSMQ) powinny być w przyszłości oferowane możliwości serwera aplikacji. Na potrzeby tej nowej roli w Internet Information Server zaimplementowanych zostało kilka nowości, których krótki opis znajduje si˛e poniżej. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 211 Dla uzyskania poprawy w obszarze niezawodności i skalowalności wprowadzono zmiany wewnatrz ˛ architektury przetwarzania. Dzi˛eki temu bł˛edy moga˛ być rozpoznawane automatycznie a w razie potrzeby istnieje możliwość ponownego uruchamiania procesów. Równolegle serwer WWW kolejkować nadchodzace ˛ żadania. ˛ IIS 6.0 jest w stanie prowadzić kontrol˛e stanu procesów roboczych, aplikacji i stron WWW. Wraz z serwerem Windows 2003 wprowadzony został także nowy sterownik trybu pracy jadra, ˛ którego zadaniem jest optymalizowanie przepływu danych na serwerze WWW. IIS 6.0 można zintegrować z framework autoryzacyjnym serwera Windows 2003. Dodatkowo, można korzystać z menedżera autoryzacji do prowadzenia akcji delegowania i autoryzacji. Zarzadzanie ˛ IIS 6.0 odbywa si˛e teraz w oparciu o meta XML i umożliwia administratorowi bezpośrednia˛ edycj˛e konfiguracji. Nowa jest tu także integracja ASP.NET i IIS, programistom oferowane sa˛ rozszerzone funkcjonalności .NET Framework do tworzenia aplikacji. Dla programistów i użytkowników można zastosować standard Unicode realizujacy ˛ internacjonalizacj˛e. 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 rz˛edzie ze wzgl˛edu na przyszłe zastosowanie. Podsumowujac, ˛ w oparciu o wyniki analizy wymagań należy stwierdzić, że SharePoint Portal Server może być jak najbardziej brany pod uwag˛e w ramach ogólnej koncepcji rozwiazania ˛ portalowego albo systemu zarzadzania ˛ dokumentami. 3.12.2 Wprowadzenie Wraz z SharePoint Portal Server firma Microsoft zaoferowała platform˛e do tworzenia portali WWW o nast˛epujacych ˛ podstawowych funkcjonalnościach: ◦ wyszukiwanie ◦ zarzadzanie ˛ dokumentami ◦ praca grupowa. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 212 Microsoft stworzył tym samym produkt, który może spełniać klasyczne zadania portalu intranetowego w obr˛ebie przedsi˛ebiorstwa. Aby stworzyć a nast˛epnie zarzadzać ˛ treściami w obszarze przedsi˛ebiorstwa SharePoint Portal Server bardzo mocno integruje aplikacje desktopowe (Windows - Explorer, aplikacje biurowe, przegladarka ˛ internetowa). SharePoint Portal Server jest rozwiazaniem ˛ portalowym ze zintegrowanymi funkcjonalnościami wyszukiwania oraz Workflow. Jeśli chodzi o wymagania systemowe, niezb˛edny jest tu serwer Microsoft Windows 2000 badź ˛ Advanced Server, jak również Internet Information Service 5.0 i Simple Mail Transfer Protocol. SharePoint Portal Server nie wymaga Active Directory. Serwer można zainstalować do wyboru w Windows NT albo domenie Active Directory. SharePoint Portal Server 2001 oparty jest na systemie bazodanowym WebStorage firmy Microsoft. Administrowanie serwerem odbywa si˛e poprzez Microsoft Management Console (MMC). Można tu ustalać mi˛edzy innymi zakresy robocze, zadania bezpieczeństwa, czasy timeout i ustawienia protokołu. W celu zapewnienia bezpiecznej wymiany danych poprzez Internet / Extranet można właczyć ˛ szyfrowanie SSL. Ocena i prezentacja SharePoint Portal Server w tym kontekście ma na celu uwypuklenie pojedynczych aspektów tworzenia portalu. 3.12.3 Dashboardsite W ramach instalacji SharePoint Portal Server automatycznie tworzony jest portal WWW określany mianem Dashboardsite. Użytkownikom portalu WWW można udost˛epnić nast˛epujace ˛ funkcje: ◦ wyszukiwanie ◦ abonament nowych albo zmodyfikowanych treści ◦ sprawdzanie wpływajacych ˛ i wychodzacych ˛ dokumentów, wraz z numerami wersji ◦ publikowanie dokumentów Do organizacji i wyświetlania informacji Dashboardsite wykorzystuje technologi˛e Digital Dashboard firmy Microsoft. Digital Dashboard składa si˛e z tak zwanych Web Parts, które wewnatrz ˛ portalu moga˛ przedstawiać informacje z zewn˛etrznych i z wewn˛etrznych źródeł. Do zewn˛etrznych źródeł treści można zaliczyć 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 można rozwijać samemu albo nabywać u innych producentów. Istnieja˛ jednak także standardowe Web Parts, na przykład służace ˛ integracji wyjścia i wyjścia poczty Outlooka, kalendarza i terminów. Dzi˛eki właczeniu ˛ Web Parts innych producentów można poprzez portal stworzyć dost˛ep do kolejnych systemów informacyjnych (SAP, system CAD, system archiwizacji, itd.). Wewnatrz ˛ portalu istnieje możliwość przyporzadkowania ˛ informacji i dokumentów do poszczególnych kategorii. Kategorie z kolei moga˛ mieć hierarchiczna˛ budow˛e. Wewnatrz ˛ Digital Dashboard pojedynczy użytkownik może sterować sposobem uporzadko˛ wania i prezentacji Web Parts. Dost˛ep do Dashboardsite może być realizowany z poziomu przegladarki ˛ internetowej, np. Microsoft Internet Explorer albo Netscape Navigator. Aby Dashboardsite mogła działać w przegladarce ˛ WWW musi być właczony ˛ Microsoft JScript albo Netscape Java Script. 45 Rysunek 3.26: Architektura SharePoint Portal Server 3.12.4 System Zarzadzanie ˛ Dokumentami (DMS) Kolejnym ważnym elementem SharePoint Portal Server sa˛ zintegrowane funkcjonalności DMS. Oferowane sa˛ nast˛epujace ˛ standardowe funkcje: 45 Źró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 Workflow ◦ sprawdzanie na wejściu i wyjściu ◦ profile dokumentów i publikowanie dokumentów ◦ abonamenty. Edycja dokumentów i zarzadzanie ˛ nimi (sprawdzanie na wejściu i wyjściu) sa˛ całkowicie zintegrowane z Microsoft - Office - Suite. SharePoint Portal Server oferuje także możliwość hierarchicznego składowania dokumentów. Odwzorowanie hierarchii odbywa si˛e 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ównież tak zwane przekazywanie zezwoleń dla nowych wersji dokumentów. Dopiero po sprawdzeniu i udost˛epnieniu nast˛epuje opublikowanie wersji. 3.12.5 Funkcje wyszukiwania SharePoint Portal Server oferuje funkcj˛e wyszukiwania dla wszystkich informacji i dokumentów w portalu. Indeks wyszukiwarki może obejmować różne źródła wiedzy (wewn˛etrzne i zewn˛etrzne treści), które moga˛ być udost˛epniane użytkownikom w trybie wyszukiwania pełnego tekstu. Użytkownikom oferowana jest także możliwość wyszukiwania atrybutowego (profile dokumentów). Użytkownikom pokazywane sa˛ tylko dokumenty z listy trafień, do których zalogowany użytkownik posiada prawa dost˛epu. Naznaczanie dokumentów nast˛epuje poprzez tak zwana IFilter (Index Filter). Jeśli dokument zostanie nadesłany albo dodane zostana˛ zewn˛etrzne źródła treści, wówczas serwer automatycznie rozpozna typ dokumentu i uruchomi odpowiedni IFiltr. Filtry zapewniaja˛ rozpakowanie treści dokumentu, które moga˛ być nast˛epnie dodane do indeksu pełnotekstowego. Obecnie dost˛epne 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 przedsi˛ebiorstwa konieczna jest rozległa analiza stanu faktycznego i stanu oczekiwanego. Podczas zakładania portalu przedsi˛ebiorstwa badź ˛ portalu pracowników niezb˛edny jest dokładny, szczegółowy plan. Tylko portale, ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 215 które sa˛ dostosowane do potrzeb pracowników i przedsi˛ebiorstwa b˛eda˛ nowa˛ platforma˛ dobrze spełniajac ˛ a˛ swoje zadanie. Z reguły istniejacym ˛ wymaganiom można sprostać korzystajac ˛ z odpowiednich rozwiazań ˛ portalowych (wraz z Content Management albo z systemami zarzadzania ˛ dokumentami). Jednak nie należy zakładać, że powyższe rozwiazania ˛ - dotyczy to także SharePoint Portal Server - stanowia˛ tak zwane rozwiazanie ˛ Out of th Box. Wszystkie systemy należy w mniejszym lub wi˛ekszym stopniu dostosować do wcześniej zdefiniowanych wymagań. W zależności od oczekiwanych celów może być konieczne wykonanie obszernych prac programistycznych. Aby wprowadzić SharePoint Portal Server potrzeba, tak samo jak w przypadku wprowadzania skomplikowanych rozwiazań ˛ archiwistycznych i Workflow, dużej kompetencji jeśli chodzi o analiz˛e i kształtowanie procesów biznesowych. W oparciu o wyniki obszernej analizy wymagań można stwierdzić, że SharePoint Portal Server może być jak najbardziej brany pod uwag˛e jako możliwe rozwiazanie. ˛ 3.13 Bazy danych 3.13.1 Przeglad ˛ Ocena techniczna migracji baz danych pokazuje, że oprócz kontynuacyjnego produktu Microsoft, którym jest MS SQL Server 2000 korzystać można z alternatywnych, jak najbardziej adekwatnych odpowiedników b˛edacych ˛ rozwiazaniami ˛ OSS, co usprawiedliwia przeprowadzenie migracji zast˛epujacej. ˛ Ważnymi przedstawicielami rozwiazań ˛ OSS sa˛ MySQL, PostgreSQL, Firebird oraz SAP DB. Oprócz tego dost˛epne sa˛ także produkty komercyjne, takie jak Oracle i DB2, które również były już wielokrotnie wykorzystywane w urz˛edach i w zwiazku ˛ z tym nie zostały przedstawiane w poniższej ocenie technicznej. Wymienione rozwiazania ˛ OSS oferuja˛ różne funkcjonalności, dlatego ich przydatność należy sprawdzać pod katem ˛ wymagań w poszczególnym przypadku. Należy podkreślić, że wszystkie w/w rozwiazania ˛ OSS sa˛ niezależne od platformy i że istnieja˛ także ich wersje windowsowe, które można pobrać z Internetu. Dlatego niniejsze systemy bazodanowe moga˛ być zastosowane także w przypadku migracji punktowej. 3.13.2 Wprowadzenie Do utrzymywania, zarzadzania ˛ i zapisywania dużych ilości danych wykorzystuje si˛e systemy bazodanowe. Systemy bazodanowe zapisuja˛ powiazane ˛ ze soba˛ elementy w formularzu danych, ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 216 wzgl˛ednie w pogrupowanych wierszach. Pomi˛edzy tymi strukturami a grupami moga˛ istnieć zdefiniowane relacje. dzi˛eki zastosowaniu dobrze zaplanowanej i ustrukturyzowanej bazy danych można uniknać ˛ nadmiaru danych. Dane z systemu bazodanowego nie sa˛ z reguły bezpośrednio udost˛epniane użytkownikom. Dost˛ep do nich odbywa si˛e za pośrednictwem aplikacji, która odwołuje si˛e do danych i oferuje je użytkownikom w odpowiedniej formie. Aby było to możliwe musza˛ istnieć interfejsy pomi˛edzy systemem bazodanowym a aplikacja.˛ Właściwy składnik komunikacyjny zapewnia połaczenie ˛ pomi˛edzy systemami klienckimi i serwerowymi. Aplikacje, które wykonywane sa˛ na systemach klienckich, moga˛ odwoływać si˛e do serwera bazy danych poprzez sieć. Serwery bazy danych musza˛ być w stanie obsługiwać wi˛eksza˛ ilość równoległych zapytań klienckich. Zadanie serwera polega wówczas na unikaniu problemów logicznych podczas równoległego dost˛epu systemów klienckich do odczytu i zapisu. Bazy danych składaja˛ si˛e z reguły z dwóch składników, właściwej fizycznej bazy danych oraz z systemu zarzadzania ˛ baza˛ danych (DBMS). DBMS spełnia m.in. nast˛epujace ˛ zadania: ◦ kontroluje relacje pomi˛edzy danymi wewnatrz ˛ bazy danych ◦ sprawdza i zapewnia prawidłowe zapisywanie danych, ze szczególnym uwzgl˛ednieniem zdefiniowanych reguł relacji mi˛edzy danymi ◦ odtwarza stałe dane w przypadku bł˛edu systemu albo podobnych zdarzeń DBMS definiuje także instrukcje i aplikacje, których trzeba użyć, aby móc pracować z danymi w bazie danych. Najcz˛eściej wykorzystywanym j˛ezykiem w systemach bazodanowych jest Structured 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 si˛e z właściwego 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 każdego systemu klienckiego za pomoca˛ protokołu . Poziom ten jest specyficzny dla MS SQL Server i określany jako Tabular Data Stream (TDS). Obsługiwane sa˛ wersje 4.2 i 7.0. Każdy pakiet tworzony jest dla MS SQL Server przez OLE DB - Provider i sterownik ODBC. Pakiety TDS przesyłane sa˛ do serwera badź ˛ 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łaściwy serwer bazy danych składa si˛e z dwóch głównych składników, relacyjnego modułu i modułu zapisywania. Obydwa moduły komunikuja˛ si˛e ze soba˛ poprzez API OLE DB. Funkcje relacyjnego modułu polegaja˛ na analizie poleceń SQL, optymalizacji planu wykonania oraz wykonywaniu operacji z planu wykonania. Moduł zapisywania spełnia nast˛epujace ˛ zadania: ◦ zarzadza ˛ plikami i miejscem przeznaczonym do zapisu ◦ zarzadza ˛ buforami danych i operacjami wejścia / wyjścia ◦ 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 si˛e wewnatrz ˛ logicznych składników, które z kolei zapisywane sa˛ fizycznie, w formie plików na nośniku danych. Podczas pracy z baza˛ danych użytkownik b˛edzie używał w pierwszym rz˛edzie logicznych składników (tablic, Views, Stored Procedures, itd.). Każda instalacja MS SQL Server udost˛epnia wiele baz danych. Łacznie ˛ istnieja˛ cztery systemowe bazy danych i jedna albo wi˛ecej baza danych użytkowników. Oprócz w/w systemowych baz danych, po instalacji należy założyć właściwe bazy danych zawartości. Te produkcyjne bazy danych zorganizowane sa˛ w formie różnych obiektów. W poniższej tabeli wymienione zostały najważniejsze składniki dost˛epne w MS SQL Server jako obiekty. S KŁADNIKI W YJA ŚNIENIE Właściwe dane bazy danych zapisywane sa˛ w tablicach. Tablice tablice typy danych zdefiniowane przez użytkownika składaja˛ si˛e z kolumn i wierszy. Wiersze zawieraja˛ każdorazowe zestawy danych. Dla kolumn można ustalać typy danych. Definiuja˛ one rodzaj danych zapisywanych w kolumnach. Oprócz typów podstawowych danych serwera MS SQL użytkownicy moga˛ zakładać typy danych definiowane przez użytkownika. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 219 Widoki sa˛ warstwami zdefiniowanymi dla wirtualnej tablicy albo zapisanego zapytania. W bazie danych zapisane sa˛ polecenia SELECT, których wynik tworzy treść wirtualnej tablicy. Widoki pełnia˛ nast˛epujace ˛ funkcje: Views ◦ ograniczaja˛ użytkownikom prawa dost˛epu do określonych wierszy albo kolumn w tablicy. ◦ w powiazany ˛ sposób prezentuja˛ kolumny z wielu tablic. ◦ łacz ˛ a˛ informacje. Sa˛ grupa˛ poleceń Transact - SQL, która skompilowana została pod katem ˛ jednego planu wykonania. Stored Procedures pełnia˛ m.in. nast˛epujace ˛ funkcje: ◦ implementuja˛ wychodzac ˛ a˛ poza ramy program logik˛e programu w celu wykonywania cz˛esto powtarzajacych ˛ si˛e zadań. Stored Procedures ◦ zwi˛ekszaja˛ wydajność, skompilowane Stored Procedures przechowywane sa˛ w Cache. ◦ moga˛ zapobiegać dost˛epowi do tablic po stronie użytkownika. ograniczenia Udost˛epniaja˛ proces zapewnienia integracji bazy danych. Ograniczenia definiuja˛ reguły pod katem ˛ dopuszczalnych wartości wewnatrz ˛ kolumny. Zapewniaja˛ kompatybilność zwrotna,˛ cz˛eściowo pełnia˛ te same reguły funkcje, jak ograniczenia CHECK. Służa˛ do ograniczania wartości w kolumnie. Podaja˛ wartości, które używane sa˛ w kolumnie, gdy podczas wartości domyślne wstawiania wiersza danych, w kolumnie nie została podana wartość. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 220 Odpowiadaja˛ szczególnej formie Stored Procedures, sa˛ automaTrigger tycznie wykonywane, gdy tylko dla tablicy zdefiniowane zostało polecenie UPDATE, INSERT albo DELETE. indeksy tablic Indeks, który zwiazany ˛ jest z tablica˛ i przyspiesza odpytywanie wierszy. Tablica 3.34: Składniki dost˛epne na serwerze MS SQL jako obiekty 3.13.3.3 Składniki klienckie Użytkownik nie ma bezpośredniego dost˛epu do Microsoft SQL Server. Aby uzyskać dost˛ep do danych, należy zastosować specjalne aplikacje. Moga˛ to być: ◦ programy usługowe serwera MS SQL ◦ programy innych producentów oraz ◦ własne programy stworzone na wewn˛etrzny użytek urz˛edu. Dost˛ep do MS SQL Server odbywa si˛e za pośrednictwem API (Application Programming Interface) baz danych składajacego ˛ si˛e z dwóch cz˛eści: poleceń j˛ezyka programowania, które musza˛ być przekazane do bazy danych i zestawu funkcji albo interfejsów zorientowanych obiektowo oraz metod wysyłajacych ˛ instrukcje j˛ezyka programowania do bazy danych i przetwarzajacych ˛ wyniki. Poleceń j˛ezyka programowania używa 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, specyficzne dla Microsoftu. MS SQL Server obsługuje dwie główne klasy API baz danych: ◦ OLE DB - Provider wchodzacy ˛ w skład systemu obsługuje aplikacje, które zostały napisane z wykorzystaniem OLE DB albo APIs, które używaja˛ OLE DB (np. ActiveX Data Objects (ADO)). Ponadto obsługiwane sa˛ obiekty i składniki, które używaja˛ 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 3.13.3.4 221 Składniki komunikacyjne Obsługiwanych jest wiele metod komunikacji pomi˛edzy aplikacjami klienckimi a serwerem. W przypadku komunikacji na jednym komputerze, pomi˛edzy serwerem a aplikacja˛ należy zastosować technologie ponadprocesowe, np. Named Pipes albo Shared Memory. Aplikacje, które pracuja˛ na innym systemie klienckim, używaja˛ sieciowej Interprocess Communication (IPC). IPC oparta jest na API i protokołach sieciowych. Korzystać można z nast˛epujacych ˛ protokołów: ◦ TCP / IP ◦ Novell IPX / SPX ◦ AppleTalk ◦ Banyan VINES. 3.13.3.5 Skalowalność Microsoft SQL Server jest przystosowany do zarzadzania ˛ bazami danych, które moga˛ mieć rozmiar jednego terabajta albo wi˛ekszy. MS SQL Server posiada kilka Features, które zwi˛ekszaja˛ wydajność systemu bazodanowego. System bazodanowy obsługuje także środowiska VLDB (Very Large Database). Rozmiar baz danych może wynosić jeden terabajt albo wi˛ecej. Za pomoca˛ poleceń Transact - SQL, takich jak BACKUP i RESTORE można zabezpieczać dane na wielu mediach oraz tworzyć przyrostowe kopie bezpieczeństwa. W celu przyspieszenia obsługi zapytań z serwerem MS SQL zintegrowany został optymalizator zapytań. Aby zapewnić podział poleceń SQL dla maszyn wieloprocesorowych, można tworzyć równoległe plany wykonywania. Serwer MS SQL obsługuje dzielone zapytania. Istnieje możliwość wykonywania poleceń Transact - SQL, które odnosza˛ si˛e do heterogenicznych źródeł danych OLE DB. Podczas wykonywania aktualizacji (zmian), integralność danych zapewniona jest dzi˛eki temu, że aktualizacje zawsze kończa˛ si˛e stałym stanem. Jeśli nie zostanie on osiagni˛ ˛ ety, wówczas nast˛epuje Rollback i przejście do punktu wyjścia, tzn. do poprzedniego stałego stanu. Ponadto możliwe sa˛ dzielone transakcje. Zarzadzanie ˛ transakcjami odbywa si˛e przy tym za pomoca˛ menedżera transakcji. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.13.3.6 222 Nadawanie praw dost˛epu Serwer MS SQL oferuje dwa rodzaje autoryzacji użytkowników: ◦ autoryzacja serwera SQL W serwerze MS SQL musza˛ istnieć odpowiednie konta logowania oraz hasła – nie sa˛ one zwiazane ˛ z kontami użytkowników NT. Logowanie i odpytywanie hasła odbywa si˛e bezpośrednio na serwerze SQL. ◦ autoryzacja Windows NT Konta oraz grupy Windows NT należy właczyć ˛ do serwera MS SQL, jednak właściwa autoryzacja odbywa si˛e w domenie NT. Administrator może ustalić, czy autoryzacja ma si˛e odbywać poprzez Windows NT, czy w trybie mieszanym. 3.13.3.7 Integracja systemu Serwer MS SQL obsługuje stosowanie użytkowników Windows NT oraz kont domen. Tym samym dla serwera MS SQL dost˛epna jest autoryzacja Windows NT. Użytkownicy nie sa˛ autoryzowani przez serwer MS SQL. Udost˛epnia on systemom klienckim zaufane połaczenie. ˛ Oprócz integracji autoryzacji użytkowników NT, serwer MS SQL może być ściśle zwiazany ˛ z nast˛epujacymi ˛ usługami: ◦ zapisywanie danych dla Microsoft Internet Information Server, który jest z reguły wykorzystywany do generowania dynamicznych treści 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 dost˛epnych jest wiele narz˛edzi: ◦ MS SQL Server - Agent umożliwia tworzenie i planowanie zadań, które maja˛ być wykonywane jednorazowo albo okresowo. Moga˛ to być ostrzeżenia dla administratora w przypadku wystapienia ˛ określonych zdarzeń w systemie. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 223 ◦ MS SQL Server Profiler umożliwia kontrol˛e oraz analiz˛e obciażenia ˛ sieci podczas transmisji z serwera i do serwera. ◦ Monitor systemowy serwera MS SQL umożliwia właczenie ˛ si˛e w system monitorowania Windows NT służacy ˛ do kontroli serwera MS SQL oraz graficzna˛ prezentacj˛e. ◦ MS SQL Server Enterprise Manager udost˛epnia Snap - In dla Microsoft Management Console (MMC) w celu umożliwienia zarzadzania ˛ serwerem MS SQL. ◦ Asystent optymalizacji indeksu umożliwia analiz˛e z wykorzystaniem indeksów poleceń SQL. Za pomoca˛ SQL Distributed Management Objects (SQL - DMO) istnieje dodatkowo możliwość właczenia, ˛ w ramach aplikacji, zadań automatyzujacych. ˛ Zadania powtarzajace ˛ si˛e można także zaimplementować jako zlecenia. 3.13.4 Migracja zast˛epujaca ˛ Bazy danych, a dokładniej relacyjne systemy zarzadzania ˛ bazami danych (RDBMS) należa˛ do prekursorów zastosowań Linuksa w obszarach krytycznych dla przedsi˛ebiorstwa. Już w 1997 roku Software AG zaoferowała wraz z baza˛ danych AdabasD w pełni komercyjny (w swoim czasie certyfikowany przez SAP) RDBMS dla Linuksa. W 1998 roku podażyły ˛ jej śladem Oracle oraz Informix, które w ten sposób wyraźnie zwi˛ekszyły zaufanie do Linuksa w dziedzinie zastosowań profesjonalnych. Kombinacja Linuksa, Apache, MySQL i PHP znana pod akronimem 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 udost˛epniony został, także na licencjach Wolnego Oprogramowania, cały szereg pełnowartościowych RDBMS obsługujacych ˛ transakcje, triggers oraz Stored Procedures. Jeśli chodzi linuksowe oprogramowanie Open Source w obszarze baz danych z pewnościa˛ nie brakuje wysokowartościowych opcji. RDBMS pełnia˛ w ramach strategii migracyjnej o tyle szczególna˛ rol˛e, że zawsze zwiazane ˛ sa˛ z aplikacja,˛ której dane zarzadzane ˛ sa˛ za pomoca˛ RDBMS. Tym samym w przypadku zmiany trzeba z jednej strony zmienić zasoby danych a z drugiej prawdopodobnie także aplikacje. W idealnej sytuacji dane organizacji udost˛epniane sa˛ w znormalizowanej formie (bez nadmiaru) tylko z jednego systemu bazodanowego, a j˛ezyk zapytań (SQL), którym aplikacje poro- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 224 zumiewaja˛ si˛e z baza˛ danych, spełnia standardy. W idealnej sytuacji każda aplikacja bez problemów współpracuje z każdym RDBMS. Niestety w rzeczywistości okazuje si˛e, że w wi˛ekszości infrastruktur informatycznych trzeba zarzadzać ˛ wieloma RDBMS z cz˛eściowo nadmierna˛ ilościa˛ danych zgromadzonych w różnych bazach danych. Prowadzi to do tego, że zapytania o w/w dane kierowane i redagowane sa˛ z różnych aplikacji i w różnych dialektach SQL przy wykorzystaniu rozszerzeń oraz interfejsów specyficznych dla danego producenta. Nawet wtedy, gdy połaczenie ˛ z baza˛ danych zestawione jest za pomoca˛ standardów ODBC albo JDBC i nie sa˛ używane triggers ani Stored Procedures, należy podczas migracji bazy danych wymienić po stronie klientów sterownik ODBC / JDBC. W odniesieniu do powyższego migracja oferuje szans˛e na konsolidacj˛e struktur oprogramowania i struktur danych, przy czym oczywiście skorzystanie z niej nie jest proste. Niniejsze wst˛epne przemyślenia pokazuja,˛ że rozwiazania ˛ alternatywne dla migracji kontynuacyjnej istnieja˛ tylko w przypadkach, gdy: ◦ RDBMS pracujacy ˛ obecnie pod kontrola˛ systemu Windows dost˛epny jest także dla systemu operacyjnego Open Source (np. Oracle dla Linuksa). W takim przypadku system bazodanowy pozostanie systemem komercyjnym. W infrastrukturze serwera opartej na Linuksie, z punktu widzenia administratora wynika z takiego wariantu wiele korzyści. Jeśli chodzi o MS - SQL nie przewiduje si˛e powstania wersji linuksowej. ◦ aplikacje powiazane ˛ sa˛ z dotychczasowym RDBMS za pomoca˛ ODBC albo JDBC. W takim przypadku dane może przejać ˛ inny system bazodanowy a połaczenia ˛ z klientami można przekierować wymieniajac ˛ sterownik ODBC (na poziomie systemu, na kliencie). Problem stanowia˛ tu szczegóły. Jeśli aplikacja współpracuje z Stored Procedures albo triggers, wówczas trzeba je również przeportować. (Można to zrobić przy okazji, bez zmian w oprogramowaniu klienckim.) ◦ chodzi o aplikacj˛e MS Access przechowujac ˛ a˛ dane w postaci plików. W takim przypadku można w bardzo łatwy sposób właczyć ˛ dane do centralnego DBMS i przestawić aplikacj˛e Access na interfejs ODBC. ◦ klient dost˛epny jest w postaci tekstu źródłowego i można go dostosować w ramach projektu migracyjnego do nowego RDBMS. Oprócz wymienionych już czynników (korzystanie z triggers i Stored Procedures), nakład zwiazany ˛ z migracja˛ zależy tu także od wykorzystywanych interfejsów programistycznych. Jeśli połaczenie ˛ z baza˛ danych zaimplementowane zostało bezpośrednio poprzez interfejs producenta (np. wbudowany SQL), wówczas ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 225 należy si˛e liczyć ze znacznie wi˛ekszym nakładem, niż w przypadku, gdy pomi˛edzy wła˛ czona została płaszczyzna abstrakcji, taka jak ActiveX Data Objects (ADO). ◦ Ostatecznie istnieje jeszcze możliwość współpracy z producentem aplikacji i przeprowadzenia migracji bazy danych w ten sposób. Trwałe zwiazanie ˛ z określonym RDBMS uznawane jest, także przez wielu producentów komercyjnych baz danych, za niekorzystne z punktu widzenia rynku, dlatego można wyjść z założenia, że gotowość do migracji, szczególnie do RDBMS wywodzacego ˛ si˛e z Open Source, rośnie i jest godna zauważenia. Gdy istnieje możliwość przeprowadzenia migracji systemu bazodanowego, należy wybrać docelowy system RDBMS. Przy ocenie możliwych systemów docelowych w ramach niniejszego poradnika migracyjnego wzi˛eliśmy pod uwag˛e przede wszystkim bazy danych Open Source. Poniższy przeglad ˛ pokazuje systemy bazodanowe, które sa˛ aktualnie dost˛epne na licencji Open Source: BAZA DANYCH W ERSJA L ICEN - Z APY- T RANS - CJA TANIE AKCJE S TORED P ROCS GDBM www.gnu.org 1.8.3 GPL Hash Berkeley DB www.sleepycat.com 4.1.25 BSD Type Hash SHORE www.cs.wisc.edu/shore/ 1.1.1 BSD SDL / ODL ZOPE www.zope.org 2.6.1 Zope PL DTML mSQL www.hughes.com.au 3.4 Hughes MSQL MySQL 4.0.12 GPL SQL X 7.3.2 BSD SQL X (X) 1.5 Inter- SQL X X SQL X X X www.mysql.com PostgreSQL www.postgresql.org Firebird Base PL firebird.sourceforge.net SAP DB www.sapdb.org 7.4.03 GPL / LGPL ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 226 Tablica 3.36: Systemy bazodanowe dost˛epne na licencji Open Source Systemy Hash nie sa˛ relacyjne. Jeśli chodzi o migracj˛e, to w gr˛e wchodza˛ przede wszystkim cztery ostatnie systemy z interfejsem SQL. Poniżej zamieściliśmy charakterystyk˛e tych systemów. 3.13.4.1 MySQL MySQL jest rozwijana i rozpowszechniana przez szwedzka˛ firm˛e o tej samej nazwie. Niniejsza baza danych jest udost˛epniana na licencji GPL i tym samym jest Wolnym Oprogramowaniem. Ponieważ również interfejsy programistyczne udost˛epniane sa˛ na licencji GPL, zlinkowane z nimi programy także musza˛ być oparte na tej licencji, o ile sa˛ one rozpowszechniane badź ˛ rozprowadzane na zasadach komercyjnych. Alternatywnie MySQL AB oferuje również licencje komercyjne, które umożliwiaja˛ korzystanie z MySQL producentom aplikacji komercyjnych, bez wymogu udost˛epniania przez nich swojego oprogramowania na licencji GPL. MySQL oferuje regularne umowy dotyczace ˛ wsparcia i serwisu, szkoleń oraz doradztwa. Producenci oceniaja˛ ilość zainstalowanych baz danych MySQL na całym świecie na 4 miliony. Z najwi˛ekszym powodzeniem jest ona wykorzystywana w połaczeniu ˛ z Linuksem, Apache i PHP do tworzenia dynamicznych stron WWW. MySQL może służyć do składowania danych z takim samym Frontend (parser SQL) na różnych BackEnds. W przypadku wykorzystania innoDB jako BackEnd, MySQL obsługuje także transakcje. Obecnie MySQL nie oferuje Stored Procedures. Zgodnie z deklaracjami producenta b˛eda˛ one dost˛epne poczawszy ˛ od wersji 5.0. Ponadto istnieje możliwość skompilowania MySQL z obsługa˛ OpenSSL – w takim przypadku klient i serwer komunikuja˛ si˛e ze soba˛ za pomoca˛ protokołu Secure Socket Layers (SSL) wykorzystujac ˛ certyfikaty X.509. W przypadku MySQL składowanie danych odbywa si˛e zazwyczaj w systemie plików. Struktury danych zajmuja˛ przy tym tylko tyle miejsca na dysku, ile rzeczywiście wymagane jest do zapisania treści. Przydzielanie miejsca na dysku dla tablic czy bazy danych nie jest konieczne. Pojedynczy pracujacy ˛ serwer bazy danych może zarzadzać ˛ dowolna˛ ilościa˛ instancji bazy danych. MySQL jest w sumie bardzo zgrabna i w przypadku każdego dost˛epu do odczytu niesłychanie szybka. Zazwyczaj wykorzystywana jest raczej w przypadku małych i średnich zasobów danych oraz dla lekkich aplikacji. Jednakże lista referencji MySQL AB pokazuje, że ta baza ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 227 danych przeznaczona jest również dla dużych aplikacji i dużych zasobów danych i że jak najbardziej może mierzyć si˛e ze wszystkimi komercyjnymi systemami bazodanowymi. 3.13.4.2 PostgreSQL Poczatki ˛ PostgreSQL si˛egaja˛ roku 1986, kiedy to na UCB powstała baza danych Postgres. Jest ona udost˛epniana na licencji BSD. W 1995 roku odpytywanie bazy danych przestawiono na SQL. PostgreSQL rozwijany jest zgodnie z czysta˛ metoda˛ Open Source przez duża˛ i rozproszona˛ po całym świecie społeczność. W zgodzie z modelem pracy społeczności różne firmy oferuja˛ dla PostgreSQL swoje produkty i usługi. W przypadku PostgreSQL użytkownik może definiować własne funkcje w wielu różnych j˛ezykach programowania, które moga˛ zwracać zarówno pojedyncze wartości, jak też tupels albo nawet całe tablice. Funkcje te oferuj˛e różnorodne możliwości w postaci procedur zdefiniowanych dla użytkownika. Kolejnym szczególnym rozwiazaniem ˛ jest wykorzystanie reguł si˛egajacych ˛ poza triggers. Dzi˛eki szerokiemu procesowi rozwijania projektu przez społeczność, PostgreSQL jest bardzo funkcjonalna i dopracowana pod katem ˛ bezpieczeństwa. Wskutek tego PostgreSQL standardowo oferuje mocne szyfrowanie oraz autoryzacj˛e, jak też przepływ danych w oparciu o certyfikaty X.509. Dane z PostgreSQL przechowywane sa˛ w systemie plików. Alokacja położenia bazy danych albo tablic nie jest wymagana, istnieje także późniejsza możliwość podziału na różne obszary zapisu. Serwer bazy danych może obsługiwać wiele instancji bazy danych. PostgreSQL wykorzystuje, podobnie jak Oracle, system podgladu, ˛ który w przeciwieństwie do tradycyjnego Locking umożliwia Locking bazy danych także w trakcie pracy przy dużym Performance. Zabezpieczanie danych jest przy tym spójne. PostgreSQL jest jednocześnie zgrabna i bardzo funkcjonalna. Zazwyczaj wykorzystywana jest dla zasobów danych średniej wielkości. Do wysoce zautomatyzowanego transportu danych z MS Access do PostgreSQL można posłużyć si˛e windowsowym narz˛edziem administracyjnym tworzacym ˛ Wizard migracyjny dla bazy danych Access. 3.13.4.3 Firebird Firebird powstał w połowie 2000 roku jako samodzielny projekt wywodzacy ˛ si˛e z bazy danych Interbase 6.0 udost˛epnionej przez firm˛e Borland na zasadach Open Source. Nad rozwojem tego systemu bazodanowego pracuje mała zaangażowana społeczność. Najistotniejsza˛ dokumentacj˛e stanowia˛ pliki PDF przej˛ete 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 może być jeszcze brany pod uwag˛e jako RDBMS, jeśli chodzi o zastosowania profesjonalne. 3.13.4.4 SAP DB SAP DB jest uniwersyteckim projektem badawczym zapoczatkowanym ˛ przez Politechnik˛e w Berlinie. Jego poczatki ˛ si˛egaja˛ aż roku 1977. W latach 80 - tych system był rozwijany i sprzedawany przez firm˛e Nixdorf jako DDB/4. Nast˛epnie 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 udost˛epniła w/w baz˛e 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ń ˛ tej firmy i jest stosowana jako podstawowa technologia we własnych produktach. W zakresie funkcji mieszcza˛ si˛e oprócz obsługi transakcji także wsparcie dla triggers oraz Stored Procedures. Główne starania zwiazane ˛ z rozwojem, jak też z zapewnieniem jakości podejmowane sa˛ pod katem ˛ funkcjonalności zastosowań rozwiazań ˛ SAP. Ponieważ 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 wszechstronności i elastyczności. Do przechowywania danych SAP DB używa Volumens, które sa˛ tworzone w systemie plików albo na Raw - Devices i które każdorazowo w całości alokowane sa˛ do instancji bazy danych. Baza danych jest reorganization - free i może być zabezpieczana w trakcie pracy bez zakłóceń Performance. SAP DB należy wśród baz danych Open Source do wagi ci˛eżkiej. Może być ona celem migracyjnym dla baz danych MS Access tylko w wyjatkowych ˛ przypadkach. 3.13.4.5 Bilans pośredni Jeśli chodzi o Open Source, oferta alternatywnych celów migracyjnych jest różnorodna i atrakcyjna. Nie można podjać ˛ ogólnej, prostej i jednoznacznej decyzji na korzyść takiego lub innego systemu w oparciu o jego charakterystyczne cechy. Wszystkie opisane dotychczas systemy bazodanowe SQL sa˛ niezależne od platformy. Ważne jest, że wszystkie cztery dost˛epne sa˛ w Internecie także w wersjach windowsowych. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 229 Przy szczegółowym porównaniu systemów docelowych, które można wziać ˛ pod uwag˛e w przypadku migracji, konieczne jest zapoznanie si˛e z dokładnym porównaniem spisów Features przygotowanych pod katem ˛ funkcjonalności faktycznie wykorzystywanych przez system bazodanowy. Dobre porównanie znajduje si˛e na stronie: http://www.mysql.com/information/ features.html. Niektóre dodatkowe wskazówki zawiera nast˛epujaca ˛ tabela: L ICENCJA Dokumentacja innych producentów TableSpace GPL BSD B ORLAND PL GPL X X (InterBase) n.a. unlimited unlimited unlimited unlimited X X SSL / Network Traffic Encryption X Kerberos Authentication X ODBC 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 X Backup przyrostowy rozszerzenie DB space w trakcie pracy via LVM via LVM via LVM (X) Raw Devices X sheme.table Namespaces X 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 możliwość nadania odpowiedniemu typowi wi˛ekszego zakresu wartości. Należy jednak ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 230 zwrócić uwag˛e, zarówno podczas importu danych, jak i podczas przejścia na połaczenie ˛ ODBC, aby interfejs ODBC posiadał własne rozwiazania ˛ i definicje typów danych. 3.13.4.7 Zalecenia odnośnie niezależności Na wypadek, gdyby w danej chwili nie było możliwości przeprowadzenia migracji zast˛epuja˛ cej, zamieściliśmy poniżej kilka zaleceń co do sposobu programowania bazy danych, których przestrzeganie ułatwi przyszła˛ migracj˛e. ◦ Należy zrezygnować z Stored Procedures i rozszerzeń specyficznych dla producenta. W przypadku, gdy istnieje potrzeba przemieszczenia logiki biznesowej lub funkcjonalności z klienta na serwer, efekt ten można obecnie bardzo dobrze uzyskać wykorzystujac ˛ 3warstwowe architektury. Odpowiednia˛ implementacja˛ niezależna˛ od platformy jest tu Java, zarówno dla klienta, jak i dla serwera aplikacji (Tomcat). ◦ Połaczenie ˛ z baza˛ danych należy zestawić za pomoca˛ standardowych interfejsów (ODBC, JDBC) albo należy właczyć ˛ poziom abstrakcji, który można, opcjonalnie i bez konieczności wprowadzania zmian w kodzie programu, przestawić na ODBC, JDBC lub inne interfejsy. ◦ Należy wyizolować i zmodularyzować 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łaszcza funkcjonalności WWW. Główny punkt rozwoju dotyczył obsługi XML i poprawy skalowalności. W niniejszym podrozdziale wymienione zostały najważniejsze funkcjonalności. Internet i Intranet Najważniejsze rozszerzenia MS SQL Server 2000 z zakresu rozwiazań ˛ internetowych i intranetowych umieściliśmy w poniższej tabeli.46 F UNKCJA 46 Rozszerzone funkcjonalności Enterprise Edition nie zostały wymienione i można o nich poczytać w White Papers oraz odpowiednich opisach technicznych. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 231 ◦ Obsługa XML, Xpath, XSL oraz HTTP: ◦ Wyświetlanie i dost˛ep do relacyjnych danych poprzez zastosowanie widoków XML. ◦ Dost˛ep przez URL i HTTP do danych w Internecie. Do generowania zapytań można wstawić szablony w XML SQL, XML albo Xpath w URLs. ◦ Zwracane moga˛ być wyniki zapytania SELECT w formie XML. ◦ Dokumenty XML moga˛ być edytowane za pomoca˛ Transact - SQL i Stored Procedures. zintegrowany Datamining obsługa multiplen instancji bezpieczeństwo Umożliwia analiz˛e relacyjnych danych i danych OLAP („Online Analytical Processing“) w celu analizowania trendów i prognoz. Hosting oddzielnych instancji bazy danych dla aplikacji albo klientów. 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 poniższej tabeli pokazane zostały najważniejsze nowości zwiazane ˛ z zarzadzaniem ˛ i opcjami programowania Microsoft SQL Server 2000. F UNKCJONALNO ŚCI integracja Active Directory Integracja centralnej usługi katalogowej MS ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 232 Przesuwanie i kopiowanie baz danych i obiektów pomi˛easystent kopiowania baz danych i DTS dzy serwerami. Data Transformation Services umożliwiaja˛ import i eksport kluczy głównych i obcych pomi˛edzy obsługiwanymi produktami bazodanowymi. zdefiniowane przez Tworzenie funkcji Transact - SQL wielokrotnego użytku. użytkownika funkcje oraz nowe triggers Zamiast albo po procesie rozszerzone triggers do wykonywania kodu. Można używać nowych typów danych (bigint, sql_variant, table) i można definiować indeksy w typach kolumn, gdy typy danych, indeksy i dane w kolumnach obliczane sa˛ z innych kolumn. Na po- sortowania ziomie kolumn możliwe jest sortowanie. Umożliwia to zapisywanie obiektów, które charakteryzuja˛ różne zasady sortowania w tej samej bazie danych. Analysis Services, wirtualne Cubes oraz generator MDX Analysis Services umożliwia rozwijanie rozwiazań ˛ OLAP Datawarehousing i Datamining. Ich edycj˛e umożliwia edytor wirtualnych Cubes. Za pomoca˛ generatora MDX można tworzyć wyrażenia wielowymiarowe. 3.14 Groupware 3.14.1 Przeglad ˛ W centrum technicznej oceny migracji usług Groupware i Messaging znajduje si˛e zarówno zastapienie ˛ funkcjonalności Exchange 5.5 za pomoca˛ rozwiazań ˛ alternatywnych, które moga˛ być stosowane w systemach opartych na Linuksie, jak też kontynuacja z wykorzystaniem Exchange 2000. Jeśli chodzi o migracj˛e zast˛epujac ˛ a,˛ głównym aspektem oceny technicznej jest wykorzystanie heterogenicznych środowisk systemowych składajacych ˛ si˛e z linuksowych serwerów i z windowsowych klientów przy dalszym, pełnym zastosowaniu MS Outlook. W wyniku rozważań dwa z ocenianych rozwiazań ˛ okazały si˛e być szczególnie właściwe, gdyż w dużym stopniu spełniaja˛ one wymóg połaczenia ˛ w czasie rzeczywistym. Za pomoca˛ połaczenia ˛ w czasie rzeczywistym można bezkonfliktowo korzystać z funkcjonalności grup. W przypadku obydwu rozwiazań ˛ chodzi z jednej strony o Samsung Contact b˛edacy ˛ komercyjnym rozwiazaniem ˛ opartym na HPOpenMail, a z drugiej strony o Exchange4Linux. Ten ostatni jest rozwiazaniem ˛ złożonym ze składnika serwera, który jest Wolnym Oprogramowaniem i właści- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 233 cielskiego Outlook - Connector, który dost˛epny jest jako komercyjny moduł oprogramowania. Exchange4Linux obsłuży maksymalnie do 500 użytkowników, jest zatem przeznaczony raczej dla mniejszych urz˛edów. Samsung Contact nadaje si˛e zwłaszcza do zastosowań w średnich i dużych urz˛edach. Oprócz tego istnieje jeszcze rozwiazanie ˛ OSS o nazwie Kroupware, które można połaczyć ˛ z MS Outlook za pomoca˛ komercyjnego Bynari - connector. Dla Kroupware istnieje obecnie ograniczenie polegajace ˛ na tym, że nie ma wystarczajacych, ˛ rzeczywiście roboczych doświadczeń. Tam, gdzie nie jest wymagane połaczenie ˛ w czasie rzeczywistym, można zastosować komercyjny produkt OpenExchange firmy SuSE. Ponadto przez połaczenie ˛ w czasie rzeczywistym możliwe jest daleko idace ˛ zastapienie ˛ funkcjonalności Exchange 5.5. Jedyny wyjatek ˛ stanowi tu korzystanie z formularzy, które nie jest możliwe w przypadku rozpatrywanych rozwiazań. ˛ Oprócz zastosowań w środowiskach heterogenicznych, ważna˛ rol˛e odgrywaja˛ także możliwe rozwiazania ˛ dla środowiska czysto linuksowego oraz pytanie o pocztowe oprogramowanie klienckie alternatywne dla MS Outlook. W tym przypadku tylko Samsung Contact udost˛epnia zintegrowanego klienta, opartego na Java i niezależnego od platformy. Oprócz tego, w przypadku wszystkich ocenianych rozwiazań, ˛ istnieja˛ jeszcze klienty WWW, których jednak można używać z wi˛ekszymi badź ˛ mniejszymi funkcjonalnymi ograniczeniami. Nie jest możliwe korzystanie z nich w trybie offline. Jednakże z funkcjonalności poczty korzystać można za pomoca˛ wszystkich klientów obsługujacych ˛ POP3 i IMAP. Jeśli chodzi o migracj˛e kontynuacyjna˛ do MS Exchange 2000, należy przyjać, ˛ że rozwiaza˛ nie to możliwe jest tylko w połaczeniu ˛ z zastosowaniem Active Directory. Chodzi przy tym o zasadnicza,˛ strategiczna˛ decyzj˛e, o której pisaliśmy już w ocenie rozwiazań ˛ opartych na AD w rozdziale 3.7. 3.14.2 Wprowadzenie Zgodnie z tym, co napisaliśmy w rozdziale 2, należy założyć, że w wi˛ekszości urz˛edów stosowanym rozwiazaniem ˛ Groupware jest Exchange. Dlatego najpierw opisaliśmy punkt wyjścia i rozpatrzyliśmy różne rozwiazania ˛ Groupware dla migracji zast˛epujacej, ˛ które można zastosować w linuksowych systemach operacyjnych. Oceniliśmy zarówno czyste projekty Open Source, jak i produkty komercyjne. Produkty te służa˛ cz˛eściowo różnym punktom wyjścia, celom i grupom celów. Zasadniczo można jednak z góry odróżnić czyste rozwiazania ˛ klient - serwer oparte na WWW od klasycznych rozwiazań ˛ klient - serwer. Ze wzgl˛edu na duża˛ ilość różnego oprogramowania nie można ocenić wszystkich rozwiazań, ˛ które sa˛ dost˛epne na rynku. Rozpatrywane ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 234 rozwiazania ˛ wybrane zostały w oparciu o różne scenariusze wymagań. Jeśli chodzi o migracj˛e kontynuacyjna˛ oceniliśmy MS Exchange 2000 oraz w niektórych punktach także MS Exchange 2003. 3.14.3 Punkt wyjścia - Microsoft Exchange 5.5 W tym miejscu przedstawione zostały najważniejsze cechy i funkcjonalności rozwiazania ˛ Groupware firmy 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 Najwi˛eksza˛ jednostka˛ struktury Microsoft Exchange Server jest organizacja. Organizacja może rozciagać ˛ si˛e 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˛ si˛e ze soba˛ poprzez szybkie połaczenie ˛ sieciowe. Serwery Exchange z punktu centralnego bezpośrednio przesyłaja˛ do siebie poczt˛e i bezpośrednio replikuja˛ wzajemnie informacj˛e katalogowa. ˛ Przekazywanie (Routing) wiadomości pocztowych pomi˛edzy punktami centralnymi trzeba specjalnie skonfigurować. Punkt centralny jest jednostka˛ administracyjna. ˛ 3.14.3.3 Składniki podstawowe Microsoft Exchange Server składa si˛e z nast˛epujacych ˛ podstawowych składników: ◦ katalog Exchange (Directory Service, DS), ◦ Message Transfer Agent (MTA), ◦ pami˛eć informacji (Information Store, IS) oraz ◦ kontrola systemu (System Attendant, SA) ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 235 Katalog Exchange zapisuje wszystkie informacje o użytkownikach, zasobach i organizacji (dir.edb). Należa˛ do nich listy zarejestrowanych na serwerze użytkowników poczty elektronicznej, nazwy i konfiguracje serwerów. Należy zwrócić uwag˛e na fakt, że w katalogu zapisywane sa˛ wszelkie informacje o konfiguracji. Pami˛eć 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 wiadomości i załaczniki ˛ plikowe dla użytkowników, których skrzynki pocztowe znajduja˛ si˛e na danym serwerze. „Public Information Store“ zapisuje treść kopii publicznych katalogów. Message Transfer Agent (MTA) wysyła wiadomości do innych serwerów, punktów centralnych i systemów zewn˛etrznych. W połaczeniu ˛ z katalogiem Exchange MTA decyduje o routingu wiadomości. MTA przekazuje przychodzace ˛ wiadomości do pami˛eci informacji. MTA zajmuje si˛e także konwersja˛ wiadomości do innych formatów. Kontrola systemu jest dla serwera Exchange instancja˛ zarzadzaj ˛ ac ˛ a.˛ Za pomoca˛ tego składnika można, na przykład, tworzyć nowych użytkowników poczty elektronicznej oraz wykonywać zadania kontrolne i serwisowe. Kontrola systemu nadzoruje połaczenia ˛ sieciowe z innymi serwerami Exchange i tworzy tablice routingu. Nast˛epujaca ˛ tabela pokazuje odpowiednie składniki i opisuje w zwi˛ezłej formie ich funkcje. S KŁADNIKI F UNKCJE ◦ Zarzadzanie ˛ informacjami kierowanymi do odbiorców, listami podziału, serwerami i infrastruktura˛ Messaging. katalog ◦ Katalog może być wykorzystywany przez inne składniki w celu synchronizacji informacji, na przykład do porównania adresów. ◦ Wewnatrz ˛ organizacji automatycznie nast˛epuje replikacja informacji katalogowych wszystkich serwerów. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI ◦ Jest podstawowym składnikiem infrastruktury komunikacyjnej serwera Exchange. MTA ◦ Przesyła wiadomości do innych serwerów, punktów centralnych i systemów. ◦ Konwertuje formaty dla innych systemów. ◦ Zapisywanie wiadomości wysyłanych do poszczególnych użytkowników. pami˛eć informacji ◦ Przetwarzanie i zapisywanie informacji wewnatrz ˛ publicznych katalogów. ◦ Prywatne i publiczne informacje przechowywane sa˛ w dwóch oddzielnych bazach danych. ◦ Protokołowanie aktywności Messaging. ◦ Nadzorowanie połaczeń ˛ pomi˛edzy serwerami. ◦ Tworzenie tablic routingu. kontrola systemu ◦ Kontrolowanie replikacji katalogów i usuwanie konfliktów. ◦ Protokołowanie rozsyłania wiadomości. ◦ Generowanie adresów e - mail dla nowo utworzonych użytkowników. 236 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 można rozszerzyć o opcjonalne, modularne składniki, takie jak, np. różne konektory oraz serwer zarzadzaj ˛ acy ˛ kluczami. Konektory (Connectors) przekazuja˛ wiadomości pomi˛edzy różnymi systemami lub punktami centralnymi. ◦ Site Connector i Directory Replication Connector (łaczy ˛ punkty centralne w jeden system obejmujacy ˛ całe przedsi˛ebiorstwo) ◦ 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 szerokopasmowego albo system Exchange z obcymi systemami X.400 ◦ Connector for cc: Mail (łaczy ˛ Exchange z systemami Lotus cc:Mail). Rozróżnić można konektory wewn˛etrzne i zewn˛etrzne. Konektory wewn˛etrzne łacz ˛ a˛ ze soba˛ dwa punkty centralne Exchange i sa˛ w pierwszym rz˛edzie obiektami logicznymi, które ułatwiaja˛ administrowanie. Konektory zewn˛etrzne sa˛ dodatkowymi składnikami oprogramowania i zapewniaja˛ połaczenie ˛ serwera Microsoft Exchange z innymi systemami pocztowymi. Konektory zapewniaja˛ właściwa˛ konwersj˛e treści wiadomości i informacji adresowych. Dzi˛eki temu wiadomości z Exchange można odczytać w obcym systemie a wiadomości obcego systemu moga˛ być czytane przez użytkowników Microsoft Exchange. Serwer zarzadzaj ˛ acy ˛ kluczami (Key Management Server, KMS) można wykorzystać do administrowania kluczami, za pomoca˛ których przesyłane sa˛ szyfrowane wiadomości albo wiadomości opatrzone podpisem cyfrowym. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 238 Dalszym opcjonalnym składnikiem jest Chat - Server. Umożliwia on realizacj˛e tak zwanych „Internet Relay Chats“ (IRC), dzi˛eki którym z kolei możliwa jest jednoczesna, wzajemna komunikacja dużej ilości uczestników. Poczawszy ˛ od wersji 5.5 zaimplementowany został także tak zwany Server Scripting Service. Usługa ta zapewnia możliwość umieszczania skryptów napisanych w j˛ezyku skryptowym, takim jak Perl, VB Script albo JScript, w publicznym katalogu. Powyższa usługa zapewnia wykonywanie programów w wypadku wystapienia ˛ określonych zdarzeń. Za pomoca˛ skryptów można automatyzować zadania. 3.14.3.5 Obsługa protokołów Exchange obsługuje cały szereg różnych protokołów, z których najważniejsze zostały przedstawione w niniejszym podrozdziale. Simple Mail Transfer Protocol (SMTP) jest standardowym protokołem służacym ˛ do przekazywania wiadomości w Internecie. Do dostarczenia wiadomości do nie zawsze połaczonych ˛ komputerów - klientów służy protokół POP3. Niniejszy standard zaprojektowany został pod katem ˛ wymiany pakietów pomi˛edzy tylko czasowo połaczonymi ˛ klientami poczty i serwerami pocztowymi. Klienty poczty korzystaja˛ z POP3 podczas czytania wiadomości. Przesyłanie wiadomości odbywa si˛e za pomoca˛ SMTP. Inne zastosowanie ma standard IMAP4, który obsługiwany jest przez produkty e - mail. Duża˛ siła˛ IMAP4 w porównaniu z POP3 jest zdolność wybiórczego ściagania ˛ wiadomości z serwera. Dzi˛eki temu można oddzielnie ściagać ˛ wiadomości i ewentualnie istniejace ˛ załaczniki. ˛ Poprzez integracj˛e z HTTP można udost˛epniać w Internecie dokumenty z katalogów publicznych. Jeśli zastosowany zostanie Microsoft Internet Information Server (IIS) oraz Exchange Server 5.5 użytkownicy uzyskaja˛ poprzez Active Server Web Access (OWA) możliwość korzystania z funkcjonalności, które w innym przypadku byłyby dost˛epne tylko za pomoca˛ klienta Outlook. Informacje te generowane sa˛ za pomoca˛ Active Server Pages. Tym samym obsługa HTTP jest w pierwszym rz˛edzie rozszerzeniem Internet Information Server. Z tego też powodu obsługa HTTP wymaga istnienia Internet Information Server z funkcjonalnościa˛ ASP. Użytkownicy moga˛ na przykład przegladać ˛ prywatne i publiczne katalogi, wysyłać oraz odbierać wiadomości pocztowe i korzystać z innych funkcji. Jednak pełny zakres funkcji dost˛epny jest tylko z serwerem Microsoft Internet Explorer. NNTP zapewnia rozprzestrzenianie si˛e na całym świecie Newsgroups. Treści Newsgroups przesyłane sa˛ poprzez NNTP z serwera do serwera. Exchange Server może za pomoca˛ połaczenia ˛ NNTP udost˛epniać treści Newsgroups w katalogach publicznych. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 239 LDAP umożliwia klientom dost˛ep do informacji katalogowych z katalogu serwera Microsoft Exchange. 3.14.3.6 Warianty produktu Exchange Server 5.5 wykorzystywany jest w dwóch różnych wersjach: ◦ Standard Edition oraz ◦ Enterprise Edition. Enterprise Edition obsługuje Exchange Cluster z dwoma w˛ezłami w oparciu o Windows NT 4 Enterprise Edition. 3.14.3.7 Funkcjonalności użytkownika Funkcjonalnościami, z których korzystać może użytkownik 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żki ˛ adresowe i osobiste kontakty) ◦ prowadzenie notatnika Za typowe oprogramowanie klienckie uznaliśmy w niniejszym poradniku program Microsoft Outlook. Outlook ukazał si˛e w wersjach 97 (wersja 8), 98 (wersja 8.5), 2000 (wersja 9) oraz 2002 (wersja 10, XP). Outlook i Exchange oferuja˛ możliwość zapisywania i edycji danych offline oraz ich synchronizacj˛e w przypadku istniejacego ˛ 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) można udost˛epniać, np. Workflows albo skrzynki pocztowe dla grup. Zastosowanie publicznych katalogów umożliwia wspólne korzystanie z informacji. Użytkownicy, którzy posiadaja˛ odpowiednie uprawnienia, moga˛ czytać i / lub zapisywać informacje zapisane w katalogach. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.14.3.8 240 Komunikacja klient - serwer Komunikacja pomi˛edzy klientem a serwerem odbywa si˛e w typowym środowisku LAN za pomoca˛ klienta Outlook poprzez MAPI (Messaging Application Programming Interface) i tym samym poprzez RPC (Remote Procedure Calls). Dzi˛eki obsłudze SMTP, POP3, IMAP oraz HTTP można realizować najróżniejsze scenariusze komunikacji klienta z serwerem. 3.14.3.9 Komunikacja serwer - serwer Komunikacja pomi˛edzy serwerami Exchange może być sterowana za pomoca˛ różnorodnych konektorów. Jeśli dwa serwery znajduja˛ si˛e wewnatrz ˛ tego samego punktu centralnego, wówczas komunikuja˛ si˛e one przez RPC. 3.14.3.10 Tematy pokrewne Wskutek stosowania systemów poczty elektronicznej istnieje zwi˛ekszone niebezpieczeństwo ataku wirusów. W Exchange istnieje możliwość zaimplementowania oprogramowania antywirusowego tworzonego przez innych producentów, jeśli skorzysta si˛e z napisanego przez nich antywirusowego API. Wielu producentów oferuje dla środowisk Exchange integracj˛e rozwiazań ˛ umożliwiajacych ˛ wysyłanie faksów. Oprogramowanie innych producentów pozwala także archiwizować poczt˛e elektroniczna˛ albo usuwać obiekty pocztowe nie b˛edace ˛ w użyciu od dłuższego czasu (Hierarchical Storage Management, HSM). 3.14.4 Migracja zast˛epujaca ˛ Cel migracji zast˛epujacej ˛ może być za każdym razem inny i zależeć od danego przypadku. Przed przystapieniem ˛ do migracji należy dokładnie określić rzeczywiste wymagania wzgl˛edem produktu Groupware. Nast˛epujaca ˛ lista pokazuje przykładowe kryteria wyboru rozwiazania ˛ Groupware: ◦ Jakie systemy klienckie maja˛ być 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 funkcjonalności Groupware musi wspierać nowy system? ◦ Jakie wymagania stawiane sa˛ co do skalowalności systemu? ◦ itd. Weryfikacja wymagań wzgl˛edem nowego produktu Groupware jest niezb˛edna i należy ja˛ przeprowadzić przed rozpocz˛eciem realizacji każdego projektu. 3.14.4.1 phpGroupware Reprezentantem czystego rozwiazania ˛ opartego na WWW jest udost˛epniane na licencji GPL oprogramowanie Groupware znane pod nazwa˛ „phpGroupware“ 47. Generowanie dynamicznie tworzonych treści odbywa si˛e w oparciu o j˛ezyk skryptowy PHP. Treści udost˛epniane sa˛ za pomoca˛ serwera WWW. Do zarzadzania ˛ danymi i ich przechowywania można wykorzystać baz˛e danych MySQL. Jako system bazodanowy można jednak wybrać również PostgreSQL, Oracle i Sybase, a do zarzadzania ˛ adresami można wykorzystać katalog LDAP. Również autoryzacj˛e użytkowników można realizować za pomoca˛ różnych technologii (SQL, SQL_SSL, LSAP, HTTP, NIS, PAM). Aby korzystać z poczty elektronicznej można zastosować dowolny serwer pocztowy. Musi on obsługiwać protokoły SMTP i POP3 / IMAP. Obecnie nie jest możliwa obsługa profilów nieobecności oraz reguł filtrowania opartych na serwerze. phpGroupware jest systemem modularnym. Podczas integracji można wybierać spośród różnych modułów. Oprócz w/w modułów realizujacych ˛ klasyczne funkcjonalności Groupware, udost˛epnianych jest wiele innych modułów. M ODUŁY F UNKCJA Addressbook Kontakt - Manager Admin Administrowanie Backup Narz˛edzie zabezpieczajace ˛ Calendar Cdb 47 Kalendarz, wraz z przesyłaniem zaproszeń i prawami dost˛epu Kontaktowa baza danych http://www.phpgroupware.org/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI Email Klient e - mail Forum Forum wiadomości i forum dyskusyjne Projects Zarzadzanie ˛ projektem Timetrack Rejestracja czasu ToDo Zarzadzanie ˛ zadaniami TTS Trouble Ticket System 242 Tablica 3.45: Wybór modułów phpGroupware Powyższe moduły moga˛ być opcjonalnie aktywowane przez administratora. Interfejsy WWW opieraja˛ si˛e na systemie szablonów. Wyróżnić można trzy typy opisów layout (XML, eTemplates, HTML). Definicje kolorów, czcionek i pozycjonowanie odbywa si˛e za pomoca˛ CSS (Cascading Style Sheets). Wewnatrz ˛ interfejsów WWW cz˛eściowo problematyczne jest stosowanie javascript, ponieważ nie wszystkie przegladarki ˛ bezbł˛ednie interpretuja˛ kod javascript. Ponadto jego stosowanie nie jest dozwolone w wielu urz˛edach ze wzgl˛edu na wymagania bezpieczeństwa. Zastosowanie czystego rozwiazania ˛ opartego na WWW oferuje wiele zalet: ◦ możliwy jest dost˛ep poprzez przegladark˛ ˛ e, także bezpieczny dost˛ep z zewnatrz ˛ poprzez HTTPS. ◦ nie jest konieczna instalacja specjalnego klienta. ◦ niezależność od systemu operacyjnego daje szczególne korzyści w heterogenicznym środowisku klienckim: ◦ aktualizacja oprogramowania odbywa si˛e po stronie serwera. Oprócz zalet istnieja˛ jednak również wady: ◦ niemożliwy jest dost˛ep do danych, gdy użytkownicy pracuja˛ w trybie offline badź ˛ gdy nie maja˛ dost˛epu do odpowiedniej sieci. Stanowi to problem zwłaszcza dla pracowników zewn˛etrznych. ◦ nie istnieje synchronizacja z przenośnymi urzadzeniami ˛ końcowymi (PDAs). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 243 Podsumowujac ˛ trzeba stwierdzić, że przedstawione rozwiazanie ˛ nie jest alternatywa˛ dla Outlook - Exchange. Jednakże korzystanie z zaprezentowanego produktu Groupware może być korzystne szczególnie w małych organizacjach, nie wymagajacych ˛ każdorazowego si˛egania do zaawansowanych funkcji. Zaleta˛ jest jego elastyczność i możliwości dostosowania poszczególnych modułów do rzeczywistych potrzeb organizacji. Podobne rozwiazanie ˛ oferuje także PHProjekt. Obydwa projekty udost˛epniły w Internecie swoje wersje demonstracyjne 48, dzi˛eki którym zainteresowani moga˛ ocenić proponowany zakres możliwości. 3.14.4.2 Kroupware Federalny Urzad ˛ ds. Bezpieczeństwa w Informatyce (BSI) zlecił konsorcjum firm stworzenie rozwiazania ˛ Groupware b˛edacego ˛ Wolnym Oprogramowaniem dla potrzeb BSI. Tym samym z oprogramowania tego moga˛ skorzystać 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. Funkcjonalności wymagane przez BSI sa˛ porównywalne z tymi oferowanymi przez połaczenie ˛ Outlook / Exchange firmy Microsoft. System kliencki Outlook ma umieć współpracować z nowym serwerem 49. Serwer Centralnym składnikiem jest serwer Kolab, który z kolei odwołuje si˛e do całego szeregu innych wolnych składników. Poszczególne składniki wymienione zostały w poniższej tabeli. S KŁADNIKI Z AKRES FUNKCJI Cyrus IMAP Serwer pocztowy IMAP Cyrus SASL Autoryzacja Cyrus LDAP Zarzadzanie ˛ użytkownikami Postfix Mail - Transfer - Agent (MTA) Apache Serwer WWW dla WebDAV i Webfrontend ProFTP Serwer FTP Tablica 3.47: Składniki Kolab 48 phpGroupware: http://phpgw.de/modules.php?op=modload&name= phpGroupwareDemo&file=index PHProjekt: http://www.phprojekt.com/demo.php 49 http://www.kroupware.org/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 244 Kroupware zbudowany jest w oparciu o klasyczny model klient - serwer, który gwarantuje użytkownikom asynchroniczne korzystanie z funkcjonalności Groupware. B˛edac ˛ offline maja˛ oni za pomoca˛ oprogramowania klienckiego, np. możliwość korzystania z poczty elektronicznej, terminarza i osobistych list zadań. Zmiany synchronizowane sa˛ dzi˛eki późniejszej replikacji danych. Projekt Kroupware może obsługiwać do 1500 użytkowników na jednym serwerze. Jego skalowalność opiera si˛e na możliwościach klastra IMAPD i OpenLDAP. Instalacja obydwu systemów przewidziana jest w przypadku dużych ilości użytkowników, co ma umożliwić korzystanie z nich wi˛ekszemu kr˛egowi osób. W przypadku zastosowania produkcyjnego decydujaca ˛ jest także 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. Stopień skomplikowania zależy od narz˛edzi stosowanych do tworzenia kopii bezpieczeństwa. Oprócz całych skrzynek pocztowych istnieje także możliwość odtwarzania pojedynczych wiadomości i terminów. Klienty Dost˛ep do funkcjonalności poczty elektronicznej i Groupware możliwy jest zarówno za pomoca˛ klientów windowsowych, jak i klientów GNU / Linux. Podczas tworzenia programu wzi˛eto pod uwag˛e klienta Microsoft Outlook 2000. Połaczenie ˛ klientów Outlook z serwerem Kolab nast˛epuje poprzez konektor firmy Bynari. Insight Connector50 firmy Bynari jest odpłatnym, komercjalnym produktem i musi być zainstalowany po stronie klientów. Konektor umożliwia wymian˛e danych kolaboracyjnych pomi˛edzy serwerem Groupware i klientem Outlook. Z praktyki znane sa˛ jednak problemy ze stabilnym działaniem konektora. W przyszłości alternatywa˛ mógłby być konektor firmy Konsec 51 . Obecnie prace nad nim znajduja˛ si˛e 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 si˛e w interfejs KDE, co pozwala użytkownikom na intuicyjna˛ prac˛e. Klient obsługuje protokoły POP3 i disconnected IMAP4. Po stronie klienta obsługiwane jest również filtrowanie nadchodzacej ˛ poczty elektronicznej (spam, itd.). Poniżej zamieściliśmy list˛e najważniejszych funkcjonalności Groupware. Funkcjonalności te obsługiwane sa˛ przez obydwa w/w klienty. ◦ odbieranie i wysyłanie poczty elektronicznej 50 51 http://www.bynari.net/index.php?id=7 http://www.konsec.com/KON/de/konnektor.html ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 245 ◦ zarzadzanie ˛ kontaktami pojedynczego użytkownika ◦ globalna ksiażka ˛ adresowa ◦ grupowy kalendarz i terminarz ◦ wspólne zasoby (katalogi publiczne) ◦ notatki i listy zadań ◦ listy wolny / zaj˛ety ◦ potwierdzenia nieobecności ◦ potwierdzenie przeczytania ◦ synchronizacja Palm PDA Bezpieczeństwo Developerzy zwracali szczególna˛ uwag˛e na integracj˛e standardów bezpieczeństwa. Istnieje możliwość całkowicie szyfrowanej komunikacji (SSL / TLS) pomi˛edzy systemami klienckimi a serwerem. Szyfrowana˛ komunikacj˛e można realizować za pomoca: ˛ ◦ IMAPS ◦ SMTP poprzez TLS ◦ WebDAVS. Klient linuksowy obsługuje end - to - end security oraz podpisy elektroniczne w oparciu o mi˛edzynarodowe standardy (S/MIME, X.509v3), dla których dost˛epna jest odpowiednia wtyczka 52 . Administrowanie Jeśli chodzi o metody zarzadzania, ˛ stworzono specjalne grupy użytkowników o szczególnych uprawnieniach. Wyróżnić można nast˛epujace ˛ grupy: ◦ administrator ◦ maintainer 52 www.gnupg.org/aegypten ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 246 ◦ user (użytkownik) Administrowanie może odbywać si˛e za pomoca˛ Frontendu, w ograniczonym zakresie, odpowiednio do posiadanych uprawnień. Proste zadania administracyjne można realizować za pomoca˛ interfejsu WWW. W przypadku bardziej skomplikowanych czynności należy dostosować odpowiednie pliki konfiguracyjne. Poprzez Frontend WWW można, na przykład, wykonywać nast˛epujace ˛ zadania: ◦ zarzadzać ˛ użytkownikami i ksiażk ˛ a˛ adresowa˛ ◦ zarzadzać ˛ publicznymi katalogami ◦ cz˛eściowo administrować serwerem ◦ potwierdzać nieobecność. Poprzez Frontend WWW możliwy jest przede wszystkim dost˛ep do usługi katalogowej. Inne działania dostosowujace ˛ należy wprowadzać w odpowiednich składnikach. Pojedynczy użytkownicy maja˛ także możliwość samodzielnego wprowadzania określonych zmian. I tak użytkownicy moga˛ modyfikować swoje dane osobowe i na przykład dodawać kolejne adresy e - mail. Migracja Obecnie nie ma jeszcze praktycznych rozwiazań ˛ w obszrze projektów migracyjnych: w przypadku migracji istniejacych ˛ danych można jednak zasadniczo korzystać z nast˛epujacych ˛ mechanizmów: ◦ eksport informacji z katalogu za pomoca˛ LDIF oraz dostosowanie danych w oparciu o skrypty. ◦ wiadomości e - mail należy przenosić do nowego klienta za pomoca˛ POP3 ◦ transfer danych w formacie vCard albo iCalender. Wnioski Obecnie nie można jeszcze konkretnie wypowiadać si˛e o przydatności Kroupware. Brakuje ku temu wymownych doświadczeń zebranych w środowiskach produkcyjnych. W przyszłości Kroupware b˛edzie z pewnościa˛ adekwatna˛ podstawa˛ Groupware dla małych i średnich organizacji. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 247 Zaleta˛ powyższego rozwiazania ˛ jest modularna budowa całego systemu, przy tworzeniu którego wykorzystane zostały sprawdzone i skalowalne składniki. Możliwość zarzadzania ˛ użytkownikami wewnatrz ˛ centralnej usługi katalogowej upraszcza zarzadzanie ˛ danymi. Usług˛e katalogowa˛ można także wykorzystywać do przechowywania danych dla innych systemów (np. Samba). Dzi˛eki jednoczesnej obsłudze klientów linuksowych i klientów Outlook w/w rozwiazanie ˛ szczególnie nadaje si˛e dla heterogenicznych środowisk klienckich. 3.14.4.3 exchange4linux Bill Workgroup Data Exchange Server zaprojektowany został przez developerów z niemieckiego przedsi˛ebiorstwa Neuberger & Hughes GmbH. Serwer ten udost˛epniany jest na licencji GPL i jest stale rozwijany. Celem programistów było i jest udost˛epnienie klientowi Outlook firmy Microsoft alternatywnego systemu serwerowego. Przyszli użytkownicy tego produktu moga˛ skorzystać z wielu rozwiazań ˛ umożliwiajacych ˛ realizacj˛e zadań Groupware. Z jednej strony system serwerowy można pobrać za darmo w postaci pakietów Debiana, a z drugiej strony zamówić pełne rozwiazanie ˛ rozprowadzane przez Neuberger & Hughes. To ostatnie obejmuje oprócz zintegrowanego systemu Groupware także oprogramowanie ułatwiajace ˛ dost˛ep o nazwie „Easygate“. Easygate udost˛epnia najważniejsze usługi infrastrukturalne (DHCP, DNS, serwer plików, serwer proxy, Internet). Serwer Funkcjonalności Groupware istnieja˛ dzi˛eki współpracy wielu jednostek oprogramowania. Nast˛epujaca ˛ tabela zawiera pakiety oprogramowania wymagane do pracy serwera Groupware. Serwer powstał w oparciu o j˛ezyk programowania Python i komunikuje si˛e z klientami Outlook za pomoca˛ Corba (patrz niżej). S KŁADNIKI F UNKCJONALNO ŚCI PostGRSQL Centralne Składowanie danych PyGreSQL Python interface Interfejs pomi˛edzy baza˛ danych i serwerem Groupware Python 2.1 J˛ezyk programowania Exchange4linux Serwer Groupware Tablica 3.49: Składniki Exchange4linux ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 248 Istnieje możliwość zaimplementowania do usługi katalogowej serwera Bill. Nad taka˛ możliwościa˛ należy si˛e zastanawiać zwłaszcza w połaczeniu ˛ z Samba.˛ Możliwe jest wówczas centralne zarzadzanie ˛ użytkownikami domen NT i składnikami Groupware. Rozwiazania ˛ tego nie można jednak zrealizować, jeśli korzysta si˛e z pełnego systemu z N & H. W takim przypadku administratorzy musza˛ wprowadzić kilka poprawek na serwerze Bill. Klient Dost˛ep do Bill Workgroup Server odbywa si˛e za pomoca˛ klientów Outlook. Podstawa˛ dla dost˛epu klienta do serwera Workgroup jest sterownik Client - MAPI stworzony przez N & H, który należy zainstalować po stronie klienta. MAPI - Clients wydaja˛ odpowiednie polecenia Outlooka na serwerze Bill wykorzystujac ˛ Corba. MAPI Service Provider N & H jest produktem komercyjnym i jego używanie zwiazane ˛ jest z zakupem licencji. Serwer ten obsługuje w połaczeniu ˛ z Microsoft Outlook - Client nast˛epujace ˛ funkcjonalności: ◦ odbieranie i wysyłanie poczty elektronicznej ◦ zarzadzanie ˛ adresami poszczególnych użytkowników ◦ globalna ksiażka ˛ adresowa ◦ grupowy kalendarz i terminarz ◦ wspólne zasoby ◦ zarzadzanie ˛ zadaniami ◦ notatki w prywatnych i publicznych katalogach ◦ funkcja wolny & zaj˛ety ◦ zaproszenia z możliwościa˛ przyj˛ecia albo odmowy ◦ potwierdzenia nieobecności ◦ synchronizacja PDA poprzez Outlook. Obsługa innych klientów nie jest jeszcze możliwa. W planie jest jednak ukazanie si˛e w nast˛epnej wersji klienta WWW obsługujacego ˛ najważniejsze funkcjonalności Groupware. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 249 Bezpieczeństwo Transmisja danych pomi˛edzy systemami może być szyfrowana. Można w tym celu korzystać ze standardu SSL i TLS. Za pomoca˛ oprogramowania innych producentów możliwe jest, po stronie serwera, sprawdzanie nadchodzacej ˛ poczty pod katem ˛ wirusów. Opcje bezpieczeństwa uzupełnione sa˛ o wykonywane na serwerze reguły filtrowania, które chronia˛ przed niechcianymi wiadomościami. W celu ochrony przed nieuprawnionym dost˛epem, wewnatrz ˛ katalogów publicznych można nadawać prawa dost˛epu. Prawa dost˛epu realizowane sa˛ za pomoca˛ tak zwanych Access Controll Lists (ACL). Zapisywanie danych wewnatrz ˛ systemu bazodanowego oferuje także wzgl˛ednie prosta˛ możliwość przywracania pojedynczych danych utraconych wskutek ich niezamierzonego usuni˛ecia. Proces ten można realizować za pomoca˛ narz˛edzi dostarczanych wraz z baza˛ danych. Administrowanie Administrowanie w przypadku zastosowania pełnego rozwiazania ˛ odbywa si˛e za pomoca˛ Frontendu opartego na WWW. W ramach administrowania standardowo wyróżnić można tylko użytkowników i administratorów. Dalszy podział nie jest przewidziany. Frontend WWW dostarczany wraz z pełnym rozwiazaniem ˛ umożliwia administrowanie zadaniami routine. Bardziej skomplikowane czynności administracyjne wykonywać można za pomoca˛ tradycyjnego oprogramowania udost˛epnianego wraz z Linuksem. Migracja Jeśli chodzi o migracj˛e danych, w zależności od punktu wyjścia można zaproponować różne rozwiazania. ˛ W przypadku bardzo małej migracji (mniej wi˛ecej do 10 użytkowników) zalecane jest skopiowanie skrzynek pocztowych oraz innych danych do katalogu osobistego w danym systemie klienckim. Dane te można później zaimportować do skrzynek pocztowych założonych w nowym systemie. Tego typu post˛epowanie jest bardzo bezpieczne lecz jednocześnie zajmuje też bardzo dużo czasu. W przypadku migracji obejmujacej ˛ do 250 użytkowników zalecane jest skorzystanie również z innych narz˛edzi. Dane użytkowników Exchange można wyeksportować za pomoca˛ konsoli Exchange Administrator i narz˛edzia firmy Microsoft „exmerge.exe“. Informacje o użytkownikach skrzynek pocztowych należy zapisać w prostym pliku CSV, a zawartość skrzynek pocztowych można zabezpieczyć w dowolnie wybranym katalogu w postaci plików PST. Tak samo należy także postapić ˛ w przypadku Publicznych Katalogów. Teraz można zaimportować pliki CSV do Bill Workgroup Server wykorzystujac ˛ narz˛edzie migracyjne udost˛epniane przez ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 250 N & H. Nast˛epnie użytkownicy moga˛ za pomoca˛ Outlooka zaimportować do serwera zabezpieczone skrzynki pocztowe (pliki PST). W przypadku wi˛ekszych projektów migracyjnych istnieja˛ jeszcze inne techniczne możliwości przenoszenia danych, które należy sprawdzić pod katem ˛ konkretnego przypadku. Wniosek Zaprezentowane rozwiazanie ˛ Groupware oferuje bardzo dobra˛ obsług˛e klientów Outlook, ponieważ wspiera wszystkie ważne funkcjonalności Groupware i udost˛epnia je użytkownikom. Niniejsze rozwiazanie ˛ jest obecnie zoptymalizowane dla scenariuszy migracji obejmujacych ˛ kilkuset użytkowników (maks. 500) i w tych ramach stosowane jest w środowiskach produkcyjnych. 3.14.4.4 SuSE Linux OpenExchange Server 4 OpenExchange Server 4 jest kontynuacja˛ E-Mail Server 3.1 firmy SuSE Linux AG. Powyższe rozwiazanie ˛ Groupware ma form˛e całościowego rozwiazania ˛ i zawiera kompletny system operacyjny, bazy danych, serwer poczty elektronicznej oraz serwer WWW. Technologia tego systemu operacyjnego opiera si˛e na SuSE Linux Enterprise Server. System ten nie jest pomyślany jako rozszerzenie już istniejacych ˛ systemów, lecz jest przeznaczony do całkowicie nowej instalacji. Dystrybutor oferuje swoim klientom rozwiazanie ˛ All - In - One złożone ze zsynchronizowanych ze soba˛ pakietów. Serwer W tym miejscu należy ocenić tylko te pakiety, które sa˛ bezpośrednio zwiazane ˛ z opisywanym rozwiazaniem ˛ Groupware. Całe rozwiazanie ˛ składa si˛e z różnych modularnych jednostek oprogramowania, które spójnie realizuja˛ funkcjonalności poczty elektronicznej i Groupware. Poniższa tabela zawiera centralne elementy tego rozwiazania. ˛ S KŁADNIKI Z ADANIA Postfix Mail - Transfer - Agent (MTA) Cyrus IMAPD Realizuje funkcjonalności IMAP Comfire Funkcjonalności Groupware OpenLDAP Centralna usługa katalogowa do zarzadzania ˛ użytkownikami Baza danych PostgreSQL Baza danych do zarzadzania ˛ danymi Groupware 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 skalowalność wynikajaca ˛ z przydzielania składników różnym systemom. Modularna budowa umożliwia także elastyczne rozszerzanie istniejacych ˛ systemów. Składniki serwera oferuja˛ obszerne funkcjonalności poczty elektronicznej i Groupware. Użytkownicy moga˛ korzystać z różnych 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 ◦ konfigurowalna baza danych wiedzy ◦ forum dyskusyjne oparte na grupach. Korzystanie z funkcjonalności może odbywać si˛e w całkowicie poprzez zintegrowana˛ stron˛e portalu WWW. Klienty Z uwagi na obsług˛e różnych systemów klienckich należy rozróżnić funkcjonalność poczty elektronicznej od funkcjonalności Groupware. Dost˛ep do pierwszej funkcjonalności można realizować za pomoca˛ wszystkich klientów obsługujacych ˛ POP3 i IMAP. Użytkownicy moga˛ dodatkowo odwoływać si˛e do swoich wiadomości e - mail poprzez specjalnie zintegrowane rozwiazanie ˛ WWW. Korzystanie z funkcjonalności Groupware można zasadniczo odbywać si˛e na dwa sposoby: ◦ dost˛ep do treści portalu WWW za pomoca˛ przegladarki ˛ WWW ◦ ograniczony dost˛ep za pomoca˛ klienta Outlook. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 252 Dzi˛eki wykorzystaniu obszernego interfejsu WWW użytkownicy moga˛ odwoływać si˛e do w/w funkcjonalności. Użytkownicy moga˛ korzystać z ksiażek ˛ adresowych opartych na LDAP, możliwości przyznawania uprawnień i z wyszukiwania, które to funkcje udost˛epniane sa˛ w postaci modułów. W przypadku stosowania funkcji uzgadniania terminów, po stronie serwera dla każdorazowego przeciagu ˛ czasu ma miejsce automatyczna analiza udost˛epnianych zasobów. Oferty oparte na stronach WWW umożliwiaja˛ użytkownikom korzystanie z rozległych funkcjonalności grup. Druga możliwość dost˛epu polega na skorzystaniu z klienta Microsoft Outlook. Może to nastapić ˛ tylko w przypadku zastosowania dodatkowego oprogramowania do replikacji, które należy zainstalować po stronie klienta. Replikacja ta jest synchronizacja˛ danych na żadanie ˛ użytkownika, tym samym synchronizacja nie odbywa si˛e w czasie rzeczywistym, jak ma to miejsce w przypadku konektora. Wspomniane oprogramowanie umożliwia połaczenie ˛ nast˛epujacych ˛ dziedzin: poczta elektroniczna, kontakty, zadania i osobiste terminy. Jeśli wystapi ˛ a˛ konflikty wówczas w konkretnym przypadku użytkownik musi sam zdecydować, w jaki sposób należy je rozwiazać. ˛ Replikacja danych realizowana jest za pomoca˛ SOAP w połaczeniu ˛ z HTTP i umożliwia synchronizacj˛e danych po stronie serwera z danymi bazy danych Outlook. Dzi˛eki zastosowaniu Outlooka istnieje również możliwość wykonywania replikacji PDA. Interfejs MAPI firmy Microsoft nie jest obsługiwany dla Outlook. Obecnie w Outlooku nie ma możliwości tworzenia terminów grup. Wynika to z faktu, że Outlook nie posiada dodatkowych funkcji serwera OpenExchange, takich jak delegowanie zadań. Obecnie nie jest jeszcze obsługiwana także ksiażka ˛ adresowa MAPI. Dlatego w dniu dzisiejszym nie jest możliwa prawidłowa implementacja czasu rzeczywistego. Jednak zgodnie z informacjami producenta opcja ta jest właśnie tworzona. Bezpieczeństwo Aby uzyskać kodowana˛ transmisj˛e można skorzystać z OpenSSL. OpenSSL realizuje szyfrowanie danych pomi˛edzy aplikacjami i składnikami. IMAP i POP3 moga˛ przekazywać dane w bezpieczny sposób poprzez tunel SSL a SMTP za pomoca˛ TLS. Aby zwi˛ekszyć bezpieczeństwo w ruchu poczty można dodatkowo zainstalować skaner antywirusowy, co ma na celu identyfikacj˛e poczty sprawiajacej ˛ problemy oraz przesyłanych wraz z nia˛ załaczników. ˛ Domyślnie stosować można filtr poczty SIEVE służacy ˛ do sortowania niechcianej poczty. Filtr ten umożliwia w razie potrzeby także ograniczenie rozmiaru wiadomości i korzystanie z innych filtrów, zgodnie z dowolnie zdefiniowanymi kryteriami. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 253 Administrowanie Do wykonywania zadań administracyjnych dostarczany jest Frontend oparty na WWW. Administrator może decydować o tym, jakie dane wolno użytkownikom samodzielnie modyfikować. Użytkownicy moga˛ poprzez Frontend WWW zmieniać swoje hasło i zapisywać swoja˛ nieobecność. Dzi˛eki temu opiekunowi systemu zmniejsza si˛e ilość pracy administracyjnej. Administrator może administrować wykorzystujac ˛ jeszcze inne opcje, za pomoca˛ których może on zadawać podstawowe ustawienia dla składników Groupware, poczty elektronicznej oraz składników bezpieczeństwa. Ponadto podczas zarzadzania ˛ systemem stosować można tradycyjne środki (polecenia z linii poleceń 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ź ˛ jej partnerzy dokonuja˛ na miejscu analizy i tworza˛ w oparciu o nia˛ ofert˛e migracyjna.˛ Na potrzeby migracji wykorzystuje si˛e z programy firmy Microsoft oraz własne. W ramach migracji przenieść można nast˛epujace ˛ dane: ◦ listy użytkowników z odpowiednimi uprawnieniami ◦ lokalnie i globalnie zapisana˛ poczt˛e elektroniczna˛ ◦ zadania ◦ kontakty ◦ terminy ◦ notatki. Dane zwiazane ˛ z funkcjonalnościami, których nie obsługuje OpenExchange nie zostana˛ przeniesione. Do takich funkcji należa,˛ na przykład, journale, powtarzajace ˛ si˛e zadania, kategorie i podkatalogi użytkowników. Wnioski Rozwiazanie ˛ Groupware firmy SuSE Linux AG oferuje modularny system Groupware, którego wi˛ekszość poszczególnych modułów opiera si˛e na sprawdzonych składnikach Open Source. Jako składnik Groupware zintegrowano komercyjny pakiet „Comfire“, który otwiera użytkownikom dost˛ep do szerokich funkcjonalności Groupware. Dost˛ep użytkowników do odpowiednich ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 254 informacji Groupware może odbywać si˛e w oparciu o stron˛e WWW albo za pomoca˛ klienta Outlook. Poprzez stron˛e WWW użytkownicy moga˛ odwoływać si˛e do całego portfolio rozwia˛ zania OpenExchange. Dla klientów Outlook funkcja ta jest jednak ograniczona. Użytkownicy nie maja˛ obecnie możliwości dost˛epu do połaczenia ˛ w czasie rzeczywistym i również nie maja˛ prawdziwej obsługi MAPI. Tym samym użytkownikom udost˛epniana jest jedynie ograniczona funkcjonalność Outlook. 3.14.4.5 Samsung Contact Samsung Contact (SC) jest obszernym rozwiazaniem ˛ Groupware zaprojektowanym z myśla˛ o zastosowaniach w przedsi˛ebiorstwach o różnej wielkości. System ten pozwana na zarzadzanie ˛ użytkownikami na serwerze w liczbie od kilkuset do dziesiatek ˛ tysi˛ecy. Funkcjonalność oprogramowania jest dalece kompatybilna z produktem Exchange firmy Microsoft. Wszystkie składniki serwera dost˛epne sa˛ dla Linuksa (RedHat, SuSE) oraz wi˛ekszości odmian Uniksa (AIX, HP-UX, Solaris). Także 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 umożliwia dost˛ep z każdej platformy obsługujacej ˛ WWW. Poprzez dostarczany MAPI - Provider można w pełni wykorzystywać istniejace ˛ funkcjonalności Outlook (98, 2000, XP). Samsung Contact opiera si˛e na sprawdzonej technologii OpenMail firmy Hewlett - Packard (HP). Przedsi˛ebiorstwo założone w Korei istnieje na rynku od ponad 15 lat. Samsung SDS posiadał w listopadzie 2001 roku wszystkie prawa do dalszego rozwijania w/w produktu, jak też przejał ˛ od HP zespół programistów pracujacy ˛ nad projektem. Serwer Podstawowa architektura systemu przedstawiona została na poniższym rysunku: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 255 Rysunek 3.28: Architektura Samsung Contact System serwera składa si˛e z wielu niezależnych od siebie składników, które w sensie skalowania horyzontalnego można podzielić na wiele serwerów. Ponadto w systemie serwera możliwa jest praca wielu całkowicie niezależnych od siebie instancji. Nast˛epujaca ˛ tabela stanowi przeglad ˛ procesów serwera i ich zadań. S KŁADNIKI Z AKRES FUNKCJI ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 256 Przekazuje wiadomość do każdorazowej usługi niezb˛ednej dla przetworzenia wiadomości. Zawiera ona wykonywanie reguł po Service Router stronie serwera sterujacych ˛ przydzielaniem wiadomości lub automatycznym odpowiadaniem na wiadomości. Local Delivery Dostarcza wiadomość do lokalnej skrzynki pocztowej. Internet Mail Gateway Służy do przekształcania wiadomości do Internet - Mail zgodnego z MIME. Remote Client Interface Służy do łaczenia ˛ klientów poczty elektronicznej poprzez sieć. Ten rodzaj połaczenia ˛ wykorzystywany jest, np. przez MAPI Provider i klientów Java. Chodzi przy tym o połaczenie ˛ Single Socket pomi˛edzy klientem a procesem serwera. Usługa testowa umożliwiajaca ˛ kontrol˛e Mail - Routings. Gene- Test Service ruje ona prosta˛ odpowiedź e - mail. Print Service Umożliwia wydruk poczty elektronicznej po stronie serwera. Służy do przetwarzania wiadomości za pomoca˛ skryptów po stro- Request Service nie serwera. Daje możliwość zarzadzania, ˛ np. mailing lists. Directory Synchronisa- Umożliwia synchronizacj˛e katalogów pomi˛edzy wieloma serwe- tion rami Samsung Contact. Bulletin Board Service Służy replikacji Bulletin Boards (Shared Folders) pomi˛edzy różnymi serwerami Samsung Contact. Background Search Se- Służy asynchronicznemu wyszukiwaniu informacji w Message - rvice Store. Client Directory Ac- Przygotowuje wpisy centralnych katalogów, aby móc je udost˛ep- cess Service niać, np. jako globalna˛ ksiażk˛ ˛ e adresowa˛ w kliencie Outlook. Application Link Se- Umożliwia przyłaczenie ˛ zewn˛etrznych aplikacji, np. Fax - Gate- rvice ways. Udost˛epnia zawartość skrzynki pocztowej poprzez protokół POP3 Service POP3. omscan Service Directory Relay Służy do sprawdzania spójności Message - Stores. Se- rvice Container Access Monitor Służy do odpytywania katalogów znajdujacych ˛ si˛e na odległych serwerach Samsung Contact. Sprawdza prawa dost˛epu do Message - Store. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 257 Służy do powiadamiania procesów klienckich o zdarzeniu (np. Notification Service gdy nadchodzi nowa wiadomość albo po odnalezieniu celu przez usług˛e wyszukiwania. LDAP Service Queue Manager Item Delete Daemon IMAP Service Eksportuje wewn˛etrzny katalog poprzez LDAP w wersji 3. Jako serwer LDAP służy OpenLDAP. Centralny proces służacy ˛ bezpiecznemu zarzadzaniu ˛ kolejkami wiadomości. Proces wykonywany w tle w celu pozbycia si˛e usuni˛etych wiadomości z Message - Store. Udost˛epnia zawartość skrzynki pocztowej poprzez protokół IMAP. Służy do odbierania wiadomości poprzez SMTP. Przed dor˛ecze- SMTP Relay SMS / Pager Service niem do skrzynki pocztowej ma miejsce wyszukiwanie adresata w katalogu. SMTP - Gateway obsługuje mechanizmy antyspamowe i autoryzacj˛e oparta˛ na SASL. Umożliwia odbieranie i wysyłania wiadomości do pagerów badź ˛ SMSów. Tablica 3.53: Składniki Samsung Contact Jako Mail - Transport - Agent (MTA) domyślnie stosowany jest Sendmail. Zasadniczo można także korzystać z serwera pocztowego Postfix. Serwerem WWW polecanym dla klientów WWW i Frontendu administracyjnego jest Apache. Samsung Contact można instalować jako Single - Server albo też wykonywać instalacj˛e dzielona˛ obejmujac ˛ a˛ wiele punktów centralnych. Skrzynka pocztowa użytkownika jest jednak zawsze przyporzadkowana ˛ do jednego w˛ezła serwera. Katalog ten można replikować ponad granicami punktów centralnych. Public Shared Folders znane ze środowiska Microsoft Exchange udost˛epniane sa˛ w postaci Bulletin Boards (BB). Również je można replikować ponad granicami punktów centralnych, co stanowi zalet˛e przede wszystkim w przypadku waskopasmowych ˛ połaczeń ˛ pomi˛edzy dwoma punktami centralnymi. W celu umożliwienia właczania ˛ do Groupware zewn˛etrznych aplikacji udost˛epniono specjalny API oraz Application Link Service. Interfejs ten wykorzystywany jest, np. przez firm˛e 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). Jeśli chodzi o kryterium wysokiej niezawodności, Samsung Contact jest już projektem zoptymalizowanym. Wi˛ekszość parametrów systemu można zmienić w trakcie pracy systemu, bez konieczności ponownego uruchamiania całego systemu. Aby uchronić si˛e przez awaria˛ osprz˛etu na w˛eźle pocztowym, radzimy uruchamiać system jako klaster HA. Tradycyjnie zalecane jest tu skorzystanie z rozwiazania ˛ oferowanego przez firm˛e HP jakim jest HP Service Guard. Zasadniczo do Samsung Contact można dopasować każde oprogramowanie klastrowe, które umożliwia przej˛ecie wspólnego Storage - Node. (RedHat Advanced Server, Steeleye, Polyserve, Failsafe, Linux Heartbeat). Klienty Samsung Contact obsługuje szeroka˛ palet˛e klientów. Oprócz MAPI - Provider służacego ˛ do przyłaczania ˛ klientów Microsoft Outlook istnieje jeszcze klient Groupware napisany w Java, jak też odpowiedni interfejs WWW. Domyślnie przyłaczenie ˛ klienta odbywa si˛e 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 można odwoływać si˛e do zawartości skrzynek pocztowych, jak i do standardowych protokołów POP3 oraz IMAP4. Dlatego do ściagania ˛ i wysyłania poczty elektronicznej można stosować dowolnego klienta poczty obsługujacego ˛ POP3 albo IMAP (np. Eudora, Evolution, Mozilla, Netscape, Outlook Express, K-Mail). Aby umożliwić dost˛ep do WAP, można skorzystać z dostosowanej wersji klienta WWW. Korzystanie z klienta Outlook możliwe jest dzi˛eki implementacji MAPI serwera Samsung Contact. Odwzorowane sa˛ wszystkie istotne funkcjonalności serwera. Rozwiazanie ˛ to zawiera także wszystkie najważniejsze Features Groupware. SC umożliwia przyznawanie praw dost˛epu do poszczególnych katalogów (poczta, terminy, kontakty, zadania) innym użytkownikom. Public Shared Folders, znane ze środowiska Microsoft Exchange, udost˛epniane sa˛ w postaci Bulletin Boards. Obsługiwane jest także tworzenie reguł po stronie serwera w celu przydzielania nadchodzacych ˛ wiadomości oraz automatyczne tworzenie komunikatu o nieobecności. W przypadku nieobecności użytkownika można zdefiniować zast˛epc˛e, który w tym okresie czasu otrzyma odpowiednie prawa dost˛epu. Wyznaczanie spotkań, podobnie jak w przypadku Microsoft Exchange, można ułatwić sobie za pomoca˛ listy free - busy, która zarzadzana ˛ jest w katalogu serwera Samsung Contact. Aby umożliwić zastosowania przenośne, zaimplementowano synchronizacj˛e katalogów offline. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 259 Bezpieczeństwo Samsung Contact nie oferuje domyślnie szyfrowania wiadomości. Istnieja˛ jednak rozwiazania ˛ innych producentów, które umożliwiaja˛ w Outlooku szyfrowanie end - to - end (certyfikaty) zgodne z S/MIME (np. Entrust). Szyfrowanie połaczenia ˛ pomi˛edzy klientem i serwerem (POP3 / IMAP) nast˛epuje poprzez uruchomiony wcześniej tunel SSL (stunnel). Autoryzacja użytkowników realizowana jest za pomoca˛ architektury PAM. Wykorzystywana jest ona do administrowania, zarówno przez procesy serwera, jeśli chodzi o protokoły UAL / IMAP / POP3, jak też przez narz˛edzia działajace ˛ z linii poleceń. Oprócz autoryzacji do katalogu Samsung Connect, możliwa jest także jeszcze autoryzacja do innych instancji. W chwili obecnej zakres dostawy obejmuje moduły PAM b˛edace ˛ składnikami autoryzacji kont uniksowych oraz składnikami autoryzacji zewn˛etrznych serwerów Radius i SMB (Samba). Samsung Contact umożliwia szczegółowe ustalenie praw dost˛epu w przypadku nast˛epujacych ˛ zasobów serwera w formie tak zwanych list kontroli dost˛epu (ACLs): ◦ Bulletin - Boards (Public Shared Folders) ◦ katalogi ◦ procesy usług ◦ serwer wydruku ◦ skrypty zapytań Rozmiar maksymalnego miejsca na dysku wykorzystywanego przez użytkownika do zapisywania danych można ograniczyć poprzez kwotowanie. Do zabezpieczania (Backup) Message - Stores nie jest wymagane specjalne oprogramowanie. Skorzystać można z każdego produktu udost˛epnianego przez system operacyjny, w którym pracuje serwer. Konstrukcja systemu Samsung Contact umożliwia spójne zabezpieczanie w trakcie pracy. Do wykonywania Single User Backup / Restore służy narz˛edzie pracujace ˛ z linii poleceń. Z jego pomoca˛ w prosty sposób można przenieść pojedynczego użytkownika z jednego w˛ezła pocztowego do drugiego. W celu ochrony przed wirusami, zasadniczo skorzystać można z każ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 można także, po stronie serwera, filtrować wiadomości pocztowe w oparciu o filtry zdefiniowane przez użytkownika. Konfiguracja ich odbywa si˛e poprzez Frontend WWW. SMTP - Relay obsługuje ochron˛e antyspamowa˛ zgodnie z RFC 2505. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 260 Administrowanie Administrować w˛ezłami pocztowymi Samsung Contact można na dwa różne sposoby: z jednej strony istnieje prosty Frontend WWW służacy ˛ do zakładania kont użytkowników, list przydzielania i wpisów katalogowych, a z drugiej strony istnieje cała masa narz˛edzi działajacych ˛ z linii poleceń, umożliwiajacych ˛ administrowanie wszelkimi składnikami. Frontend WWW wymyślony został na potrzeby codziennej pracy. Konsolowy interfejs przeznaczony jest w pierwszym rz˛edzie do zautomatyzowania zadań administracyjnych. Administrować systemem może każdy użytkownik, który posiada uprawnienia administratora. Dodatkowy wpis do katalogu systemowego określa, czy dany użytkownik ma być traktowany jak administrator. Migracja Migracj˛e ze środowiska Exchange albo Outlook do Samsung Contact przeprowadzić można na różne sposoby. Jeśli ilość użytkowników jest przewidywalna (< 100), wówczas można pomyśleć o r˛ecznym przeniesieniu skrzynek pocztowych, terminarzy, kontaktów oraz zadań do pliku PST a nast˛epnie r˛eczny transfer do struktury katalogu po stronie serwera. W takim przypadku również zakładanie skrzynek pocztowych i użytkowników wykonywane jest r˛ecznie. W dużych środowiskach systemowych, z powodu kosztów oraz wydajności, r˛eczna migracja nie ma sensu. W tego rodzaju środowiskach należy skorzystać z jednego z komercyjnych narz˛edzi migracyjnych. W zależności od producenta można z ich pomoca˛ przeprowadzić całkowicie automatyczne przeniesienie wszystkich danych wraz z rekonfiguracja˛ klienta Outlook. Po stronie serwera migracja może objać ˛ nast˛epujace ˛ informacje. ◦ użytkownicy (bez haseł) ◦ wpisy do kalendarza ◦ wpisy katalogowe ◦ Public Distribution Lists ◦ hierarchi˛e katalogów wraz z cała˛ ich zawartościa˛ (wiadomości e - mail, terminy, zadania, kontakty) ◦ Bulletin Boards ◦ reguły oparte na serwerze ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 261 ◦ listy kontroli dost˛epu W przypadku przygotowywania takiej migracji zalecane jest właczenie ˛ zewn˛etrznego usługodawcy posiadajacego ˛ odpowiednia˛ ekspertyz˛e. Wnioski Samsung Contact jest pełnowartościowym zast˛epnikiem Microsoft Exchange Server, zarówno w przypadku dużych, jak i małych instalacji. Obsługuje on wszystkie funkcjonalności Groupware serwera Exchange. Wyjatek ˛ stanowia˛ aplikacje do tworzenia formularzy, jednak niektórzy producenci podj˛eli już odpowiednie prace w tym zakresie. Podstawowa technologia istnieje na rynku już od ponad 15 lat. Dlatego produkt ten posiada duża˛ ilość wdrożeń, do których można si˛e odwołać. Najnowsze przej˛ecie przez firm˛e Samsung zapewnia dalszy rozwój produktu przez najbliższe lata. 3.14.4.6 Streszczenie Obecnie istnieje kilka rozwiazań ˛ Groupware dla Linuksa, które oferuja˛ podobny zakres funkcji, jak ma to miejsce w przypadku Microsoft Exchange. Zasadniczo uwzgl˛edniajac ˛ istniejace ˛ rozwiazania ˛ można przyjać ˛ dwie różne strategie: dost˛ep do serwera Groupware z poziomu przegladarki ˛ internetowej, dynamiczne przygotowywanie danych na serwerze. dost˛ep do serwera Groupware za pomoca˛ specjalistycznego oprogramowania klienckiego. PHP G ROUP - K ROUP - EXCHANGE - S U SE S AMSUNG WARE WARE 4 LINUX L INUX C ONTACT O PEN E X CHANGE S ERVER 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 Connector MAPI Service w czasie rze- Provider czywistym, nie takiej jak w przypadku ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 262 konektorów globalna ksiażka ˛ nie tak tak nie tak 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 tak, za pomoca˛ za pomoca˛ za pomoca˛ za pomoca˛ Outlooka Outlooka Outlooka nie tak tak tak tak adresowa MAPI synchronizacja Palm - nie Pilot klienta KDE i Outlooka Funkcjonalności Groupware portal WWW tak nie zarzadzanie ˛ kontaktami za pomoca˛ tak tak zarzadzania ˛ adresami zarzadzanie ˛ tak tak tak tak tak tak tak tak tak tak tak tak tak tak tak terminami zarzadzanie ˛ zadaniami notatki Tablica 3.55: Alternatywne rozwiazania ˛ Groupware Zakres funkcji przedstawionych rozwiazań ˛ Groupware wyraźnie wskazuje na to, że w chwili obecnej istnieja˛ już adekwatne produkty linuksowe. Wybór właściwego rozwiazania ˛ Groupware zależy od nast˛epujacych ˛ kryteriów: ◦ korzystanie z klientów Microsoft Outlook ◦ wykorzystanie w heterogenicznych środowiskach 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 stosować 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 funkcjonalność tego produktu i stanie si˛e dla wielu klientów interesujac ˛ a˛ alternatywa˛ dopiero wówczas, gdy zaimplementowana zostanie w/w funkcjonalność. W tej chwili exchange4linux oraz Samsung Contact oferuja˛ lepsza˛ obsług˛e Outlook. W przyszłości także Kroupware może być interesujac ˛ a˛ alternatywa, ˛ zwłaszcza w środowiskach heterogenicznych (patrz niżej). Z powodu braku informacji o pracy w środowiskach produkcyjnych, nie można jeszcze w tym miejscu konkretnie wypowiadać si˛e o przydatności powyższego rozwiazania. ˛ Dla organizacji skupiajacych ˛ wieluset użytkowników serwer exchange4linux oferuje stabilna˛ platform˛e Groupware, która sprawdziła si˛e już w praktyce. Samsung Contact, który znajduje si˛e na rynku już od dłuższego czasu i oferuje dobra˛ obsług˛e Outlooka, jest wiel oferujac ˛ a˛ alternatywa, ˛ zwłaszcza dla dużych organizacji. Dobra skalowalność systemu pozwala na wykorzystanie go w organizacjach skupiajacych ˛ wiele dziesiatek ˛ tysi˛ecy pracowników. Wraz z przej˛eciem HP OpenMail przez koncern Samsung wyjaśniło si˛e także pytanie53 dotyczace ˛ dalszego rozwoju oraz wsparcia technicznego. Heterogeniczne środowiska klienckie Organizacje, które wykorzystuja˛ po stronie klienta różne systemy operacyjne, maja˛ na przykład możliwość zastosowania Samsung Contact badź ˛ w przyszłości Kroupware. Samsung proponuje własnego klienta opartego na Java, który oferuje funkcjonalności Groupware niezależnie od systemu operacyjnego. Dzi˛eki temu istnieje możliwość korzystania w systemach windowsowych z Outlooka i / albo z klienta Java badź ˛ w systemach linuksowych tylko z klienta Java. W przyszłości także Kroupware b˛edzie potencjalnym rozwiazaniem ˛ dla systemów mieszanych. Dzi˛eki możliwości jednoczesnego zastosowania Outlooka i klienta KDE użytkownicy moga˛ korzystać z funkcjonalności Groupware, także w trybie offline. Rozwiazania ˛ oparte o WWW Organizacjom preferujacym ˛ rozwiazania ˛ oparte na WWW, bardzo dobry zakres funkcji oferuje udost˛epniany na licencji GPL system phpGroupware oraz komercyjny OpenExchange. Ope53 Patrz także Studium przydatności dla ministerstwa z roku 2001. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 264 nExchange umożliwia dodatkowo także przyłaczenie ˛ klientów Outlook, jednak z ograniczeniem zwiazanym ˛ z brakiem połaczenia ˛ w czasie rzeczywistym. 3.14.5 Migracja kontynuacyjna 3.14.5.1 Exchange 2000 Nowości W porównaniu z Exchange 5.5, najważniejsza˛ zmiana˛ w architekturze, która˛ wprowadzono wraz z ukazaniem si˛e Exchange 2000 jest przeniesienie usługi katalogowej Exchange do Windows 2000 Active Directory (AD). Tym samym Exchange 2000 nie posiada już własnej usługi katalogowej i wymaga używania Active Directory. Ponadto Exchange 2000 nie można instalować 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 nast˛epujace ˛ zmiany: ◦ replikacja katalogu wykonywana jest jedynie w Active Directory; wprowadzonych tam punktów centralnych (Sites) nie należy mylić 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˛ pokrywać si˛e z „grupami administracyjnymi“. Ponieważ w serwerze Exchange 2000 nie ma już usługi katalogowej, wymaga on usługi, która udost˛epnia globalnemu katalogowi (Global Catalog, GC) obszernych informacji ponad granicami domen. GC może być udost˛epniany tylko w kontrolerach domen z Windows 2000. Zawiera on informacje o wszystkich obiektach ogólnej struktury Windows 2000 (forest), jednakże tylko wybrane atrybuty. Aktualnie klienty (np. Outlook 2000 albo 98 SP2) moga˛ ściagać ˛ informacje bezpośrednio z GC. Starsze wersje klientów obsługiwane sa˛ przez serwer Exchange 2000, który jako serwer pośredniczacy ˛ przekazuje zapytanie dalej. W przeciwieństwie do tego, w Exchange 5.5 każdy serwer Exchange zawiera usług˛e 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 obsługuja˛ także wiadomości pocztowe, dzi˛eki czemu można uniknać ˛ redundancji. Jak wiadomo w grupach AD o różnych okresach ważności (widoczności) znajduja˛ si˛e: 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 już determinowany przez model administracyjny środowiska Exchange, ponieważ serwer można zorganizować oddzielnie, wykorzystujac ˛ w tym celu grupy administracyjne i grupy routingu. Podział ten możliwy jest jednak tylko wówczas, gdy w trybie Native pracuje sam Exchange 2000, tzn. gdy nie sa˛ używane inne serwery 5.5. Exchange 2000 oferuje administrowanie zgodne z modelem wytycznych. Model ten umożliwia administratorom zmienianie opcji grupy obiektów (np. skrzynek pocztowych użytkowników, serwerów oraz katalogów publicznych) w jednym procesie. Transport pomi˛edzy serwerami Exchange 2000 odbywa si˛e teraz poprzez SMTP (Simple Message Transport Protocol). Exchange 5.5 używa RPC. SMTP jest już zintegrowane z Windows 2000, podobnie jak NNTP. Konektor grup routingu z Exchange 2000 zast˛epuje standardowy konektor. Dost˛epne sa˛ nast˛epujace ˛ konektory: ◦ X.400 Connector (w MTA z Exchange 2000 już go nie ma) ◦ Microsoft Mail Connector ◦ CC:Mail Connector ◦ Lotus Notes Connector ◦ Novell Groupwise Dla każdego serwera Exchange 2000 można utworzyć do czterech grup zapisu, z których każda może posiadać do czterech baz danych. Ma to szczególne zalety, jeśli chodzi o zabezpieczanie i odtwarzanie danych. ◦ Możliwe jest teraz indeksowanie bazy danych Exchange. ◦ Klastry Exchange moga˛ pracować w trybie „activ - activ“. ◦ Outlook Web Access (OWA) obsługuje teraz WebDAV (Web Distributed Authoring and Versioning), kontynuacj˛e HTTP 1.1. Jeśli chodzi o OWA zaleta polega na tym, że serwery Exchange można skonfigurować jako Frontend i BackEnd, dzi˛eki czemu same serwery OWA nie przechowuja˛ danych. Ponadto można teraz instalować ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 266 ◦ usługi chat oraz ◦ usługi Instant Messaging. Dzi˛eki nowemu, oddzielnemu wariantowi produktu, tj. „Exchange 2000 Conferencing Server“, można przeprowadzać konferencje audio i wideo. Środowisko programistyczne Exchange 2000 zostało wzbogacone o ◦ ulepszone CDO (Collaboration Data Objects) ◦ rozszerzone mechanizmy Workflow ◦ XML ◦ wi˛eksza˛ integracj˛e IIS (Internet Information Server) i ASP (Active Server Pages). Uwagi odnośnie migracji Migracja z Exchange 5.5 do Exchange 200 jest skomplikowanym procesem, który wymaga intensywnego przygotowania, stworzenia koncepcji, planu migracji oraz testów zbliżonych do warunków produkcyjnych. Niniejszy poradnik nie możne w pełni zajać ˛ si˛e w/w zadaniami, jednak należy wskazać kilka ważnych aspektów migracji. Zanim to nastapi, ˛ należy jeszcze wprowadzić kilka definicji poj˛eć. Sformułowanie aktualizacja Exchange 2000 oznacza instalacj˛e Exchange 2000 na serwerze Exchange 5.5. Natomiast aktualizacja systemu operacyjnego serwera oznacza instalacj˛e Windows 2000 na serwerze Windows NT 4. Z faktu, że Exchange 2000 można stosować tylko wówczas, gdy dost˛epny jest Windows 2000 Active Directory, wynikaja˛ m.in. nast˛epujace ˛ techniczne warunki brzegowe: ◦ struktura domen Windows 2000 Active Directory ma wi˛ekszy wpływ na Exchange 2000 niż struktura domen w Windows NT na Exchange 5.5. Ogólna struktura (forest) tworzy granice organizacji Exchange, ponieważ jak wiadomo wychodzace ˛ poza granice domen informacje Global Catalog (GC) wyst˛epuja˛ w Ogólnej Strukturze tylko raz. ◦ wybrana struktura OU domen Windows 2000 nie ma zasadniczo wpływu na migracj˛e do Exchange 2000. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 267 ◦ wprowadzenie Exchange 2000 wymaga rozszerzenia schematu Active Directory. Rozszerzenie to można przeprowadzić bez konieczności instalacji samego Exchange 2000 (poj˛ecie: forestprep). Ponadto dana˛ domen˛e należy przygotować (poj˛ecie: domainprep). ◦ model domen Windows 2000 (Native vs Mixed Mode) wpływa na dost˛epność uniwersalnych grup i tym samym widoczność rozdzielaczy e - mail. ◦ aktualizacja Exchange 2000 może mieć miejsce tylko wtedy, gdy wcześniej przeprowadzona została aktualizacja systemu operacyjnego. Exchange 2000 nie można zainstalować w Windows NT 4. W przeciwieństwie do tego, Exchange 5.5 może pracować z Windows 2000. ◦ aktualizacja systemu operacyjnego serwera Exchange wymaga starannego zbadania (Service 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˛ być członkiem domeny Windows 2000, wzgl˛ednie członkiem Ogólnej struktury. ◦ Użytkownicy musza˛ logować si˛e do Active Directory, jeśli chca˛ badź ˛ maja˛ korzystać z Exchange 2000. W ramach niniejszego poradnika nie przedstawiliśmy złożoności 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 końcu wskazaliśmy narz˛edzia, które moga˛ ułatwić migracj˛e badź ˛ współistnienie. Active Directory Connector (ADC) umożliwia replikacj˛e hierarchii obiektów katalogowych z katalogu Exchange Server 5.5 do Active Directory. W zwiazku ˛ z tym ADC odgrywa ważna˛ rol˛e w przypadku migracji Exchange 5.5 do Exchange 2000. Należy zwrócić uwag˛e na to, że istnieja˛ dwie wersje ADCs (CD z Windows 2000 oraz CD z Exchange 2000). Jeśli chodzi o migracj˛e do Exchange 2000, ważna jest druga z w/w wersji. Domyślna replikacja (SRS) umożliwia serwerom Exchange 2000 replikacj˛e konfiguracji Exchange 5.5. 3.14.5.2 Exchange 2003 Exchange 2003 (Codename: Titanium), nast˛epca Exchange 2000, ukazał si˛e w 2003 roku. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 268 Ilość nowości w porównaniu z Exchange 2000 jest stosunkowo mała. Powodem ukazania si˛e Exchange 2003 było to, że wskutek zmian wprowadzonych w Windows 2003 w porównaniu z Windows 2000, nie można było instalować Exchange 2000 na platformie Windows 2003. Oznacza to, że w Windows 2003 można instalować tylko Exchange 2003 54. Poniższa matryca kompatybilności stanowi przeglad ˛ różnych obsługiwanych kombinacji Exchange 5.5, Exchange 2000, Exchange Server 2003 oraz Windows Server 2003. I NSTALACJA wersja Exchange PRACA O BSŁUGIWANE ŚRODOWISKA E XCHANGE W ACTIVE D IRECTORY Windows Windows Windows 2000 Windows 2000 SP3 albo Server 2003 SP3 albo Server 2003 I w wyższej w wyższej Exchange 5.5 SP3 tak nie tak tak Exchange 2000 SP2 tak nie tak tak Exchange 2000 SP3 tak nie tak tak Exchange 2003 tak tak tak tak Tablica 3.57: Matryca kompatybilności Exchange55 Nast˛epujacy ˛ rysunek przedstawia możliwości środowisk mieszanych. 54 Deutsches Whitepaper „Microsoft Exchange Server - kompatybilność z Windows Server 2003“ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 269 56 Rysunek 3.29: Mieszane środowiska Exchange Do nowości w Exchange 2003 należa: ˛ ◦ Outlook Mobile Access (obecnie Microsoft Mobile Information Server 2002) jest cz˛eścia˛ Exchange Server 2003. Outlook Mobile Access oferuje użytkownikom urzadzeń ˛ przenośnych dost˛ep do ich informacji osobistych. ◦ Exchange Server 2003 umożliwia serwerowi Internet Information Server (ISS wersja 6 z Windows 2003) nowa˛ form˛e komunikacji pomi˛edzy Outlookiem i Exchange, określana˛ jako „RPC poprzez HTTP“. W ten sposób użytkownik Outlook może bezpośrednio i bezpiecznie synchronizować swoje dane z Exchange Server 2003 poprzez połaczenie ˛ HTTP. ◦ Obsługa klastrów w Windows 2000 Advanced Server jest ograniczona do dwóch w˛ezłów lub do czterech w˛ezłów, gdy wykorzystywany jest Windows 2000 Server DataCenter Edition. Za pomoca˛ Windows 2003 i Exchange 2003 można teraz realizować, do wyboru, 56 Źródło: Deutsches Whitepaper „Microsoft Exchange Server - kompatybilność z Windows Server 2003“ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 270 klastry oparte na maksymalnie ośmiu w˛ezłów z przynajmniej jednym w˛ezłem pasywnym, gdy wykorzystywany jest Exchange serwer 2003 wraz z Windows Serwer 20003 Enterprise Edition. ◦ Exchange 2003 pracujacy ˛ z Windows 2003 używa usługi kopiowania cienia wolumenu i umożliwia w ten sposób uzyskiwanie krótszych czasów zabezpieczania i odtwarzania danych w środowiskach Exchange. 3.15 Office / Desktop 3.15.1 Przeglad ˛ Jeśli chodzi o zastapienie ˛ MS Office 97 albo Office 2000, jak najbardziej celowe jest odczekanie do chwili, aż udost˛epniony zostanie MS Office 2003 i pojawia˛ si˛e pierwsze doświadczenia z MS Office 2003, zwłaszcza że zgodnie z zapowiedziami MS Office 2003 ukaże si˛e latem 2003 r. Oprócz aspektów wyłacznie ˛ zwiazanych ˛ z kosztami, chodzi tu przede wszystkim także o aspekty techniczne wynikajace ˛ ze zmian formatu dokumentu. Wraz z MS Office 2003 Microsoft planuje wypromować XML, jako główny format dokumentów biurowych. Nie można przy tym wykluczyć, że istniejace ˛ dzisiaj problemy z kompatybilnościa˛ wzgl˛edem alternatywnego rozwiazania ˛ OSS OpenOffice.org badź ˛ jego komercjalnego odpowiednika StarOffice, zmniejsza˛ si˛e lub ewentualnie w ogóle przestana˛ istnieć. Jeśli kontrola kompatybilności wymiany dokumentów MS Office 20003 i OpenOffice 1.1, wzgl˛ednie StarOffice 6.1 wypadnie pozytywnie, wówczas należy zbadać kroki i nakłady zwiazane ˛ z przeniesieniem starych dokumentów Office do MS Office 2003. W nast˛epnym kroku należy skonfrontować je z krokami i nakładami, jakie powszechnie znane sa˛ dzisiaj w przypadku przenoszenia w/w dokumentów do OOo / SO. Dopiero potem należy podjać ˛ decyzj˛e o wyborze MS Office 2003 albo pakietu OOo / SO. Zastapienie ˛ desktopu Microsoft zależy ostatecznie w dużej mierze od tego, czy można z jednej strony zastapić ˛ MS Office przez OOo / SO oraz czy z drugiej strony wymagane aplikacje windowsowe b˛eda˛ długoterminowo dost˛epne jako aplikacje linuksowe i jak dobrze można je w tzw. mi˛edzyczasie udost˛epniać jako aplikacje windowsowe. Wymaga to jednak indywidualnego sprawdzenia. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 271 3.15.2 Wprowadzenie Desktop jest dla użytkowników widocznym interfejsem, który udost˛epnia im narz˛edzia i aplikacje wykorzystywane w codziennej pracy. Na pierwszym planie znajduje si˛e tu praca z pakietem Microsoft Office (MS Office). Jednak oprócz niego użytkownicy moga˛ korzystać także z różnych innych standardowych narz˛edzi, z funkcjonalności których nie można zrezygnować po migracji. Koniec końców istnieje jeszcze cały szereg aplikacji specjalistycznych, które sa˛ bardziej lub mniej silnie zintegrowane z desktopem i w przypadku których chodzi cz˛esto o aplikacje windowsowe, które nie bez problemów moga˛ pracować w Linuksie. Z tego powodu nast˛epujac ˛ a˛ ocen˛e techniczna˛ podzieliliśmy na pi˛eć cz˛eści: ◦ punkt wyjścia MS Office ◦ migracja zast˛epujaca ˛ MS Office ◦ migracja kontynuacyjna MS Office ◦ inne aplikacje desktopowe ◦ aplikacje windowsowe w Linuksie. 3.15.3 Punkt wyjścia - MS Office MS Office udost˛epniany jest w postaci różnych pakietów i wersji. W odróżnieniu od systemu operacyjnego nie należy tu zakładać, że w wi˛ekszości urz˛edów wykorzystuje si˛e określona˛ wersj˛e MS Office. Jednakże można wyjść z założenia, że wersj˛e poprzedzajac ˛ a˛ Microsoft Office 97 wykorzystuje si˛e już bardzo rzadko, a Microsoft Office XP nadal jeszcze niezbyt cz˛esto. W przeważajacej ˛ cz˛eści urz˛edów zainstalowany jest Microsoft Office 97 albo 2000. Dlatego b˛eda˛ one punktem wyjścia dla poniższej oceny migracji. Nowości Microsoft Office XP w porównaniu z Office 2000 dotycza˛ w pierwszym rz˛edzie interfejsu użytkownika oraz pracy grupowej, przy czym cz˛eść dodatkowych funkcji w obszarze pracy grupowej pokrywa funkcjonalności Groupware, które zostały zastapione ˛ innymi aplikacjami. Microsoft zacieśnia w ten sposób obszary Office i SharePoint Services57. Dla codziennej pracy skutkuje to jedynie nieznacznymi zmianami. Dlatego o nowych funkcjonalnościach Office XP wspominamy tylko w wybranych kontekstach. 57 Szczegóły odnośnie nowych Features w porównaniu z wcześniejszymi wersjami znajda˛ Państwo na stronie: http://www.microsoft.com/germany/ms/officexp/prof/vergleich.htm ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 272 Oprócz wersji ważna˛ rol˛e w ocenie migracji odgrywaja˛ różne pakiety Office. Pakiety te różnia˛ si˛e od siebie z reguły zawartymi w nich pojedynczymi aplikacjami. Pojedyncze aplikacje ◦ Word ◦ Excel oraz ◦ PowerPoint zostały ocenione poniżej, odpowiednio do sposobu migracji ◦ migracja zast˛epujaca ˛ MS Office oraz ◦ migracja kontynuacyjna MS Office, w oparciu o pakiet Office 2000 Professional. Outlook oceniony został w rozdziale 3.11 jako cz˛eść 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 narz˛edziami desktopowymi. W tym samym podrozdziale autorzy wspominaja˛ także pokrótce o MS Project. 3.15.3.1 Funkcjonalności Z zamieszczenia listy funkcjonalności programów Word, Excel oraz Power Point musieliśmy w tym miejscu zrezygnować. Zamiast tego w dwóch kolejnych rozdziałach wyszczególnione zostały najważniejsze różnice pomi˛edzy punktem wyjścia a możliwymi przyszłymi alternatywnymi rozwiazaniami ˛ migracyjnymi. Na poczatku ˛ należy stwierdzić, że intensywne stosowanie specjalistycznego oprogramowania w urz˛edach jest po cz˛eści rozszerzeniem funkcjonalności MS Office. Z jednej strony oznacza to, że środowisko programistyczne dost˛epne wraz z MS Office wykorzystuje si˛e w wielu urz˛edach i innych organizacjach do tworzenia rozwiazań ˛ skryptowych, specyficznych dla dokumentów (makra), co pozwala na zaawansowana˛ automatyzacj˛e procesów pracy z MS Office. Jest to wystarczajace ˛ do implementacji Workflows wykraczajacych ˛ poza dział. Z drugiej strony w urz˛edach istnieje szereg zewn˛etrznych rozwiazań, ˛ w przypadku których ma miejsce bardziej lub mniej silna integracja z Office. Dlatego poniżej opisaliśmy pokrótce środowisko programistyczne MS Office. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.15.3.2 273 Środowisko programistyczne MS Office Środowisko programistyczne Microsoft Office opiera si˛e na j˛ezyku programowania BASIC. W świecie kształtowanym przez Microsoft mówi si˛e obecnie j˛ezykiem Visual Basic. Niniejsza rodzina j˛ezykó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˛ si˛e z tego samego podstawowego słownictwa, jednak różni je zakres funkcji i środowisko pracy. Środowisko programistyczne MS Office zawiera Visual Basic for Application (VBA). Microsoft udost˛epnia licencj˛e VBA, dlatego inni producenci moga˛ właczać ˛ VBA do swoich produktów. Za punkt wyjścia w niniejszym poradniku przyj˛eliśmy korzystanie z pakietu Office 97. We wcześniejszych wersjach udost˛epniane były różne środowiska programistyczne dla poszczególnych produktów (Word Basic, Excel VBA, Access Basic). Wraz z Office 97 ujednolicono środowisko programistyczne do VBA w wersji 5. Poniższa tabela pokazuje powiazanie ˛ wersji VBA z różnymi wersjami Office. W ERSJE O FFICE 95 97 2000 XP W ERSJE VBA Word Basic, Excel VBA, Access Basic 5 6 6.3 Tablica 3.59: Wersje VBA W nast˛epujacych ˛ 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łożenia VBA VBA jest j˛ezykiem interpretowanym, który można wykonywać tyko w aplikacjach Office. VBA opiera si˛e o COM (Component Object Model), kontynuacj˛e technologii OLE (Object Linuking and Embedding). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 274 Office umie nie tylko korzystać z obiektów COM, lecz sam także oferuje obiekty COM. Office 97 dostarcza ponad 550 własnych obiektów COM, Office 2000 ponad 600. Poprzez COM, w pakiecie Office można używać także zewn˛etrzne funkcjonalności. Za pomoca˛ VBA możliwe jest korzystanie z zewn˛etrznych programów (np. systemu operacyjnego) w formie DLLs (Dynamic Link Libraries)58. Nast˛epujacy ˛ rysunek raz jeszcze przedstawia zdolność VBA do korzystania z funkcjonalności. Rysunek 3.30: VBA w aplikacji Office Poszczególne elementy VBA dziela˛ si˛e na: ◦ moduły (moduls) ◦ moduły klas (class moduls) oraz ◦ formularze (forms). W modułach znajduje si˛e „normalny“ kod programu. W modułach klas można tworzyć własne obiekty, jak też ich właściwości i metody. Elementy te umożliwiaja˛ rozszerzanie funkcjonalności dostarczanych przez MS Office, automatyzacj˛e kolejności wywołań funkcji oraz implementowanie dodatkowych funkcjonalności. Rozszerzenia, uzupełnienia i kod automatyzujacy ˛ nazywane sa˛ makrami albo skryptami. Aby zintegrować makra z MS Office można modyfikować paski menu i przyciski na paskach zadań, dzi˛eki czemu użytkownik jest w stanie łatwiej je uruchamiać. 58 W Visual Basic Script (VBS) takie połaczenie ˛ nie jest możliwe. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 275 Specjalne nazwy procedur (np. AutoOpen. AutoNew) oznaczaja˛ kod programu, który jest wykonywany automatycznie podczas otwierania plików Office. Cz˛esto korzysta si˛e z tego w szablonach (Templates), co niesie ze soba˛ zagrożenie tak zwanymi „makrowirusami“. Podsumowujac, ˛ makra i skrypty moga˛ być wywoływane w Office badź ˛ integrowane z nim w nast˛epujacych ˛ formach: ◦ jako Add - In ◦ wewnatrz ˛ szablonów (Templates) ◦ jako asystenci (Wizards). Add Ins można jeszcze podzielić ze wzgl˛edu na ich zastosowanie na: ◦ COM Add - Ins oraz ◦ aplikacyjne Add - Ins. COM Add - Ins sa˛ skompilowanymi plikami DLL albo EXE, które można tworzyć za pomoca˛ Visual Basic (pełna wersja). Add - Ins można stosować poza granicami aplikacji. Aplikacyjne Add - Ins tworzy si˛e za pomoca˛ zintegrowanego środowiska programistycznego Office i można ich używać tylko wewnatrz ˛ Office. Z Add - Ins należy korzystać z reguły tam, gdzie kod programu ma być stale dost˛epny w aplikacji, tak aby użytkownik nie musiał uruchamiać szablonów. Nast˛epujacy ˛ rysunek raz jeszcze prezentuje możliwe rozszerzenia w MS Office uzyskiwane za pomoca˛ własnych programów. Rysunek 3.31: Możliwe rozszerzenia w Office ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 276 Środowisko programowania Za pomoca˛ VBA w wersji 5 z aplikacjami Office zintegrowane zostało jednolite środowisko programowania. Tak zwane IDE (Integrated Development Enviroment) uruchamiane jest w oddzielnym oknie, ale działa w tym samym obszarze pami˛eci co aplikacja Office. IDE oferuje: ◦ edytor ze sprawdzaniem i kolorowaniem składni ◦ Project Explorer ◦ dodatkowe okno właściwości ◦ narz˛edzia debuggera ◦ Object Browser ◦ warunkowa˛ kompilacj˛e ◦ 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 można także, wewnatrz ˛ aplikacji, używać Makro - Rekorder. Zdalne sterowanie Ponieważ sam Office składa si˛e z wielu obiektów COM, możliwe jest zdalne sterowanie Office, czyli wprowadzenie automatyzacji COM. Do zdalnego sterowania można wykorzystywać, np. Windows Scripting Host (WSH) albo PerlScript 3.15.4 Migracja zast˛epujaca ˛ 3.15.4.1 Wprowadzenie Istnieja˛ najróżniejsze pakiety oprogramowania biurowego, wzgl˛ednie aplikacje (np. edytory tekstu), które sa˛ dost˛epne dla systemu operacyjnego Linux jako wolne albo własnościowe oprogramowanie. Sa˛ to mi˛edzy innymi: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 277 ◦ OpenOffice ◦ StarOffice ◦ Koffice ◦ GnomeOffice ◦ ThinkFreeOffice ◦ i inne. Jednak rzeczywista˛ alternatyw˛e dla MS Office Suite stanowia,˛ z dzisiejszego punktu widzenia oraz zgodnie z opinia˛ wszystkich ekspertów, pakiety OpenOffice.org (OOo) badź ˛ oparty na nim StarOffice (SO). Dlatego w niniejszym poradniku szczegółowo ocenimy tylko te dwa pakiety. OpenOffice dost˛epny jest obecnie w wersji 1.0.3. Jego odpowiednikiem jest StarOffice 6.0. Obydwie wersje można także stosować w systemach operacyjnych Windows NT, 2000 i XP. Ponieważ OOo / SO korzystaja˛ we wszystkich systemach operacyjnych z tych samych funkcjonalności oraz formatów plików, ułatwia to „łagodna“ ˛ migracj˛e, o ile w pierwszym kroku zast˛epowany jest tylko pakiet Office. Nowe wersje 1.1 (OOo) i 6.1 (SO) dost˛epne sa˛ już w wersji beta, a ich ostateczna wersji ma być udost˛epniona w lipcu 2003 r. Różnice pomi˛edzy OpenOffice a StarOffice Rozwój podstawowej technologii obydwu Office Suites odbywa si˛e po stronie OpenOffice.org. W roku 2000 firma Sun Microsystems udost˛epniła kod źródłowy ówczesnego pakietu biurowego StarOffice 5.2 i przekształciła go w projekt OpenOffice.org. Projekt OpenOffice.org posiada dwie licencj˛e: GPL i SISL (GNU Public License badź ˛ Lesser GNU Public License oraz Sun Industrie Source License). Podwójne licencjonowanie umożliwia z jednej strony tworzenie w oparciu o OpenOffice.org produktów komercyjnych, a z drugiej strony gwarantuje jednolitość specyfikacji API i formatu plików, które sa˛ wiaż ˛ ace ˛ dla OpenOffice.org i wszystkich programów pochodnych. Dla StarOffice firma Sun stworzyła badź ˛ dołaczyła ˛ dodatkowe składniki oraz opakowanie b˛edace ˛ profesjonalna˛ gwarancja˛ jakości, obszerna˛ dokumentacj˛e, wsparcie techniczne i oferty szkoleń. Niektórymi z w/w składników firmy Sun sa: ˛ ◦ TrueType Fonts, które sa˛ zbliżone do czcionek Microsoftu (patrz rys. 3.32) ◦ własne sprawdzanie pisowni i thesaurus, OpenOffice korzysta najcz˛eściej z MySpell (LGPL) ◦ dodatkowe szablony i galeri˛e obrazów ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 278 ◦ baz˛e danych ADABAS. Ponadto Sun dostarcza łaty naprawiajace ˛ bł˛edy albo poprawiajace ˛ bezpieczeństwo danej wersji produktu. Dzi˛eki temu obecnie co trzy miesiace ˛ pojawia si˛e dla StarOffice nowy zestaw łat, który poprawia bezpieczeństwo, bł˛edy w programach albo filtry importu. W przeciwieństwie do tego OpenOffice.org zawiera niniejsze składniki każdorazowo tylko w najnowszych wersjach 59. 60 Rysunek 3.32: Fontmapping MS Office OOo / SO W przeciwieństwie do uwolnionego OpenOffice.org Suite, StarOffice Suite jest dost˛epny wyłacznie ˛ odpłatnie. Wsparcie techniczne dost˛epne jest z reguły tylko za opłata˛ w obydwu przypadkach. Wsparcie techniczne w przypadku StarOffice uzyskać można, m.in. bezpośrednio od firmy Sun a w przypadku OpenOffice.org tylko od innych producentów. Cz˛eści składowe OOo, wzgl˛ednie SO OOo i SO składaja˛ si˛e, tak jak MS Office, z różnych aplikacji. Należa˛ do nich: ◦ edytor tekstu (Writer) ◦ arkusz kalkulacyjny (Calc) ◦ edytor prezentacji (Impress) 59 Dalsze szczegóły nt. różnic znaleźć można na stronie http://marketing.openoffice.org/ conference/presentationspdf/thu1500/SOvsOOo.pdf 60 Źródło: http://SunMicrosystems.com ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 279 ◦ edytor formuł matematycznych61 (Math) ◦ edytor grafiki62 (Draw) ◦ baza danych63 (Adabas)64. W centrum poniższych rozważań znalazły si˛e jednak tylko trzy pierwsze moduły. Jeśli chodzi o istotne funkcjonalności, trzy w/w Office Suites sa˛ takie same, zwłaszcza w przypadku funkcjonalności wykorzystywanych przez wi˛ekszość użytkowników. Wi˛ekszość użytkowników z reguły używa takiego samego, waskiego ˛ zestawu funkcji z całego dost˛epnego zakresu. W nast˛epujacych ˛ rozdziałach dokładnie prezentowane sa˛ najważniejsze różnice pomi˛edzy MS Office i OOo / SO. Poradnik ogranicza si˛e przy w pierwszym rz˛edzie do modułów edytor tekstu, arkusz kalkulacyjny i edytor prezentacji. Możliwości zastapienia ˛ modułu MS Access przez inny system bazodanowy omówiliśmy bliżej w rozdziale 3.13. Inne moduły MS Office Suite i aplikacje desktopu Microsoft opisaliśmy w rozdziale 3.15.6. 3.15.4.2 Różnice w formacie plików w porównaniu z MS Office Każda 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 przeciwieństwie do tego OpenOffice.org badź ˛ StarOffice 6.0 (OOo / SO) używa formatu pliku opartego na XML, który zapisuje treść w postaci tekstu, co oznacza, że można go czytać i zmieniać bez konieczności wykorzystywania OOo / SO do dekodowania i odczytu. Dokumentacja w/w formatu jest publicznie udokumentowana i ogólnie dost˛epna jako cz˛eść projektu OpenOffice.org. Format plików OOo / SO oparty na XML zapisuje treść, layout i informacje odnośnie formatowania każdego dokumentu w postaci kompletu XML - Streams albo poddokumentów. Aby użytkownik mógł w łatwy sposób korzystać z różnych dokumentów i XML - Streams – z pomini˛eciem wbudowanych, binarnych grafik i danych obcego pochodzenia (o ile wyst˛epuja) ˛ –, sa˛ one pakowane i przechowywane w znanym formacie ZIP. Jednakże nazwy plików tworzonych przez OOo / SO nie otrzymuja˛ rozszerzenia „.zip“, lecz tak jak w MS Office różne rozszerzenia pochodzace ˛ od poszczególnych aplikacji (patrz tab. 3.61). 61 Funkcje, jakie oferuje Math, zintegrowane sa˛ z Microsoft poprzez własny edytor, który można wywołać poprzez Wstaw / Obiekt / Nowy / Edytor formuł Microsoft. 62 Funkcje, jakie oferuje Draw sa˛ zintegrowane z Microsoft, np. poprzez ikony z paska narz˛edziowego. 63 Nie wyst˛epuje w OpenOffice.org 64 Nie da si˛e bezpośrednio porównać z Access z Windows. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI T YP 280 A PLIKACJA ROZSZE - MS O FFICE 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 DOKUMENTU A PLIKACJA OO O / SO ROZSZE RZENIE Tablica 3.61: Rozszerzenia plików najważniejszych aplikacji Office Ponadto w OOo / SO istnieja˛ jeszcze aplikacje Draw i Math, które w MS Office sa˛ cz˛eścia˛ trzech w/w aplikacji podstawowych i których nie można oddzielnie bezpośrednio przyporzad˛ kować. Za pomoca˛ Draw można tworzyć rysunki (sxd / std), za pomoca˛ Math formuły matematyczne (sxm / stm). Obiekty Draw i Math można także właczać ˛ do innych dokumentów OOo / SO i tam je edytować. Ponieważ dokumenty OOo / SO sa˛ właściwie plikami ZIP, można je rozpakowywać dowolnym programem UNZIP. Rysunek 3.33: Zawartość pliku OOo / SO wyświetlana w przegladarce ˛ plików ZIP. O ile wbudowana została grafika lub obiekty, sa˛ one składowane w katalogu „Pictures“ badź ˛ „Objects“. Znajduje si˛e tu odnośnik (href - link) do odpowiednich podporzadkowanych ˛ plików. Typowy dokument OOo / SO, który nie zawiera wbudowanych obiektów lub grafik, składa si˛e z 5 XML - Streams: ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 281 ◦ content.xml Zapisuje główna˛ treść 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ź ˛ Objects i znajduje si˛e tu odnośnik (href - link) do odpowiednich podporzad˛ kowanych plików. ◦ styles.xml Zapisuje właściwości, 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,˛ użytkownikiem, czasem ostatniej aktualizacji i inne. Treść tego pliku odnosi si˛e do informacji, które podaje si˛e poprzez mask˛e Plik / Właściwości. ◦ settings.xml Zapisuje dla danego dokumentu ustawienia dokumentu i widoku specyficzne dla aplikacji oraz zadane właściwości drukarki i opcje drukowania, poziom powi˛ekszenia oraz wielkość 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, także ten plik zapisywany jest w swoim własnym katalogu. Jeśli dokument zawiera również makra, wówczas w pakiecie znajda˛ si˛e kolejne XML - Streams65 . 3.15.4.3 Ograniczenia filtrów konwertujacych ˛ (filtrów importu) Aby umożliwić konwertowanie formatów plików, z OOo / SO zintegrowano różne konwertery (filtry), które pozwalaja˛ otwierać i edytować dokumenty MS Office w OOo / SO, a nast˛epnie zapisywać je ponownie jako dokumenty MS Office. Ponadto możliwy jest także import szablonów dokumentów MS oraz ich edycja. Pliki można zapisywać badź ˛ to w formacie MS Office 97 / 2000 / XP badź ˛ w formacie OOo / SO. 65 Dalsze informacje o formacie XML z OOo / SO znaleźć można 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 ˛ jakość konwersji jest akceptowalna, o ile nie mamy do czynienia z dokumentami zawierajacymi ˛ makra i specjalnymi Features formatów. W MS Office Istnieje bowiem par˛e właściwości 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 r˛ecznych korekt umożliwiajacych ˛ uzyskanie formatu dokumentu wyjściowego. 100% - owego konwertowania nie można oczekiwać zwłaszcza w przypadku skomplikowanych i specyficznych właściwości dokumentu, takich jak indeksy, fields, ramki i tabele. Ponadto w niektórych przypadkach, podczas konwersji podstawowych atrybutów i formatowań, takich jak kraw˛edzie stron albo odst˛epy pomi˛edzy akapitami, moga˛ pojawić si˛e różnice pomi˛edzy oryginałem a konwertowanym dokumentem. W nast˛epujacej ˛ tabeli pokazane zostały właściwości MS Office, które wymagaja˛ r˛ecznego poprawienia automatycznej konwersji. A PLIKACJA W ŁA ŚCIWO Ś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 ◦ Grafiki 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 zależności od treści ◦ Niektóre funkcje i formuły ◦ AutoShapes ◦ Odst˛epy pomi˛edzy tabulatorami, wierszami i akapitami Microsoft PowerPoint ◦ Wzorzec grafiki w tle ◦ Grupy obiektów ◦ Niektóre efekty multimedialne Tablica 3.63: Właściwości MS Office mogace ˛ sprawić problemy podczas konwersji do OOo / SO 3.15.4.4 Różnice w działaniu Jeśli chodzi o zasad˛e działania, nie ma zasadniczych różnic pomi˛edzy MS Office i OOo / SO. Obydwa systemy opieraja˛ si˛e na trójpoziomowej architekturze, która składa si˛e z samej aplikacji, szablonów dokumentów i dokumentów. Na najniższym poziomie znajduje si˛e warstwa aplikacji, która dostarcza narzadzi ˛ oraz właściwości potrzebnych do tworzenia dokumentów i szablonów. Na kolejnym poziomie znajduja˛ si˛e szablony, które moga˛ zawierać wiele makr, formatowań i ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 284 ustawień pomocnych przy tworzeniu nowych dokumentów, które z kolei na najwyższym poziomie również moga˛ zawierać kolejne obiekty, makra, formatowania i ustawienia użytkownika rozszerzajace ˛ funkcjonalność szablonów. Tym, czym różnia˛ si˛e obydwa Office Suites sa˛ właściwości i funkcje udost˛epniane przez w/w pakiety biurowe. W wielu przypadkach różnice te można przypisać projektowi i różnym modelom obiektów, w oparciu o które powstaja˛ niniejsze aplikacje. W przeważajacej ˛ cz˛eści w obydwu pakietach istnieja˛ odpowiedniki poszczególnych właściwości i funkcji drugiego produktu. Nast˛epujaca ˛ 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 domyślny normal. szablon dot hardcoded bOOok.xlt hardcoded blank.pot hardcoded szablony szablony treści / treści / projektu projektu sheet.xlt dokumentu szablon dokumentów szablony różne różne N/a strona formatu akapit akapit lista numerowanie 67 znaków różne różne strona / strona / arkusz arkusz komórka komórka N/a 66 szablony grafiki N/a prezentacja znaków N/a ramki68 tabela69 tabela Tablica 3.65: Porównanie dost˛epnych typów szablonów i formatów PowerPoint dostarcza predefiniowany schemat kolorowej animacji, który obowiazuje ˛ dla całej prezentacji. W przeciwieństwie do tego, Impress definiuje wyświetlanie graficznego obrazu oraz pojedynczych obiektów za pomoca˛ stylów . 67 Tylko w MS Office XP. 68 Ramki sa˛ wbudowanymi obiektami zamkni˛etymi w niewidocznej formie. 69 Tylko w MS Office XP. 66 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 285 W poniższej tabeli (tab. 3.67) zgromadzone zostały różnice pomi˛edzy kluczowymi funkcjami. Różnice w działaniu oraz pozostałe różnice zostały obszernie opisane w „StarOffice 6.0 Migration Guide“70. W ŁA ŚCIWO ŚCI U WAGI MS Office dysponuje makrorekorderem. makrorekorder OpenOffice 1.01 i StarOffice 6.0 nie posiada makrorekordera. Jest on przewidziany w nast˛epnej wersji i zaimplementowany w obecnej wersji beta. OOo / SO z powodu różnic w obydwu modelach obiektu nie obsługuje makr VBA. Wszystkie makra VBA przeznaczone do dal- makra oparte na dokumentach szego użytku należy przekształcić (r˛ecznie). Dokumenty OOo / SO moga˛ jednak zawierać makra napisane we własnym j˛ezyku 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˛ grafika 3D powstawać niewielkie różnice w prezentacji obiektów 3D importowanych z MS Office. Filtry dost˛epne w OOo / SO nie obsługuja˛ eksportu obiektów 3D w formacie Escher 3D. OOo / SO i MS wykorzystuja˛ różne modele tabel, co może doprowadzić do niewielkich różnic podczas ich wyświetlania. Nast˛epujace ˛ Features MS nie sa˛ obsługiwane w OOo / SO. tabela (MS Word) ◦ zmiana stron w wierszu ◦ wzorzec tła w komórkach Wyświetlanie ramek może różnić si˛e po konwersji, ponieważ OOo / SO nie obsługuje wszystkich typów linii z MS Word. formaty znaków (MS Word) 70 W Word można ustawiać różny format dla znaków z listy i dla treści list. Writer realizuje to poprzez przydzielanie własnego formatu znaków dla znaków z listy. http://uk.sun.com/software/staroffice/pdf/somigrationguide.pdf ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 286 Z reguły odst˛epy mi˛edzy znakami w Word sa˛ mniejsze niż odmetryka znaków i odst˛epów (MS Word) st˛epy mi˛edzy znakami w edytorze Writer. Obydwie aplikacje korzystaja˛ także z różnych jednostek miary przy ustalaniu pionowych odst˛epów (Word = punkty, OOo / SO = cale). Przez to ilość wierszy w w/w aplikacjach może być różna w przypadku tego samego dokumentu. Pojedynczy arkusz w Calc może zawierać maksymalnie 32.000 rozmiar arkusza wierszy. W przeciwieństwie 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łużace ˛ do złożonej analizy danych. W Calc istnieje porównywalne narz˛edzie „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 si˛e wiele tabel Pivot, gina˛ funkcjonalności. typy Chart (MS Excel) Chart-Engine w Calc nie jest tak wydajny, jak jego odpowiednik w Excelu. W Calc71 nie ma odpowiedników dla całego szeregu typów Chart obsługiwanych w Excelu. W przeciwieństwie 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 r˛ecznie wpisać obowiazuj ˛ ac ˛ a˛ wartość domyślna.˛ PowerPoint 2002 wykorzystuje funkcjonalność Timeline, która Timeline (MS PowerPoint 2002) umożliwia animacj˛e obiektów w ściśle określonym czasie. W OOo / SO nie istnieje porównywalny Feature. Ponadto w PowerPoint XP można definiować różne interwały czasu dla różnych obiektów. W aktualnej wersji Impress można ustalić ustalić interwał czasu jedynie dla wszystkich obiektów. 71 Szczegóły znaleźć można w „StarOffice 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. Funkcjonalność ta jest nieco Merge Documents (MS Word) inaczej zaimplementowana w edytorze Word niż w edytorze Writer, a dost˛epne filtry nie obsługuja˛ tej funkcjonalności. Wprawdzie odpowiednie dokumenty sa˛ importowane razem z połaczo˛ nymi polami, jednak połaczenie ˛ z plikiem danych trzeba zestawiać r˛ecznie. Makr utworzonych w MS Office nie można wykonywać w OOo / SO. W OOo / SO makra te trzeba, o ile po konwersji maja˛ być one nadal stosowane, ponownie r˛ecznie utworzyć albo dostosować do StarBasic. W OOo / SO do tworzenia makr udost˛epniane jest odpowiednie Makra VBA środowisko programowania, które można wywołać poprzez Dodatki / Makra i przyciskiem „Edycja“. Zasadniczo jednak w środowisku mieszanym (MS Office – OOo / SO) można korzystajac ˛ z OOo / SO otwierać, czytać, edytować i zapisywać dokumenty MS Office, bez gubienia albo niszczenia istniejacych ˛ makr VBA. Tablica 3.67: Różnice w kluczowych funkcjonalnościach 3.15.4.5 Ważne kryteria analizy stanu Zanim podj˛eta zostanie zasadnicza decyzja za lub przeciw migracji, po której b˛edzie mogło nastapić ˛ szczegółowe planowanie, w ramach analizy stanu należy sprawdzić: ◦ co powinno podlegać migracji ◦ czy migracja jest możliwa oraz ◦ jakie nakłady sa˛ z tym zwiazane. ˛ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 288 Podczas analizy stanu należy zbadać, wzgl˛ednie usystematyzować dokumenty według nast˛epujacych ˛ kryteriów: ◦ dost˛epność dokumentów – dokumenty, które ewentualnie trzeba nadal edytować Konwersja tych dokumentów może mieć sens. – Dokumenty, które maja˛ być jeszcze co najwyżej czytane Dokumenty te, przynajmniej w przypadku migracji, należy zarchiwizować badź ˛ przekonwertować do formatu PDF albo można rozważyć obydwie te możliwość. Dzi˛eki temu zmniejsza˛ sia˛ nakłady. ◦ stopień skomplikowania dokumentów – proste dokumenty Nie zawieraja˛ one makr, własnościowej grafiki (jak, np. WordArt), grafiki wektorowej, skomplikowanych formatować czy elementów, takich jak przypisy, tabele albo indeksy. Najlepiej jest przekształcać 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ściowa˛ oraz wektorowa˛ grafik˛e, wiele dowiazań ˛ symbolicznych i odnośników, obiekty OLE, ramki, Text - Boxes, przypisy, aktywne składniki, Form Fields, Formular - Controls, formularze czy tabele, słowem cała˛ mas˛e różnych formatowań i elementów. Dokumenty te wymagaja˛ z reguły dodatkowego planowania i należy oceniać oraz przenosić pojedynczo. ◦ stopień skomplikowania szablonów – proste szablony Proste szablony składaja˛ si˛e z generic text i odpowiedniego formatowania, które służy jako punkt wyjścia 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 dost˛epne 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˛ si˛e przenieść i które trzeba od nowa utworzyć za pomoca˛ środowiska programowania udost˛epnianego przez OOo / SO albo poddać procesowi Reengineering. Korzystanie z zewn˛etrznych źródeł danych Na ogół trzeba je przyłaczać ˛ od nowa. Można to zrobić bez problemu. Do wspomnianych źródeł danych zaliczaja˛ si˛e m.in. bazy danych i dokumenty Excel. Integracja zewn˛etrznego oprogramowania W tym przypadku z jednej strony należy zbadać zakres integracji i ilość aplikacji, które maja˛ wziać ˛ w niej udział, a z drugiej strony należy sprawdzić dost˛epność tekstu źródłowego pod ka˛ tem integracji z OOo / SO. Jeśli oprogramowanie zewn˛etrzne komunikuje si˛e z MS Office dzi˛eki automatyzacji interfejsu OLE / COM, wówczas zamiast MS Office można do wspomnianego interfejsu podłaczyć ˛ OOo / SO. Wywoływane funkcje MS Office należy przenieść do odpowiednich wywołań OOo / SO. 3.15.4.6 Przygotowanie do konwersji Jeśli chodzi o layout, powstawanie wielu różnic widocznych po konwersji, spowodowane jest posługiwaniem si˛e „niefachowa“ ˛ technika˛ formatowania. Aby wierniej odtwarzać layout dokumentu należy, wzgl˛ednie należało zapewnić „prawidłowe“ formatowanie pierwotnego tekstu. Podczas codziennej pracy należy stosować si˛e do nast˛epujacych ˛ wskazówek, także wtedy, jeśli w chwili obecnej migracja si˛e nie odbywa: ◦ zamiast bezpośredniego formatowania należy korzystać z szablonów formatów znaków i akapitów. ◦ należy usuwać niepotrzebne (twarde) Enter wstawiane pomi˛edzy pozycje listy w celu uzyskania dodatkowego odst˛epu pomi˛edzy poszczególnymi Bullets. Tworza˛ one podczas konwersji dodatkowe Bullets bez treści (puste wpisy list). ◦ kolumn tabel nie należy tworzyć za pomoca˛ wielokrotnych tabulatorów. Należy zdefiniować Tab - Stops w taki sposób, żeby tylko jeden tabulator oddzielał tekst pomi˛edzy dwiema kolumnami. Alternatywnie przy tworzeniu tabel można korzystać z Tool. W przypadku korzystania z wielokrotnych tabulatorów może si˛e zdarzyć, że tabela po konwersji b˛edzie „out of range“, gdyż domyślne tabulatory obydwu aplikacji sa˛ różne. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 290 ◦ należy sprawdzić, czy format stron w dokumencie jest identyczny z formatem strony ustawionym dla drukarki. OOo / SO nie wykonuje automatycznego justowania w celu zapewnienia prawidłowego wydruku. Dokumenty Excel Wielkość i stopień skomplikowania Spreadsheets wymagaja˛ dokładnego sprawdzenia, jeśli chodzi o ewentualne wykorzystywanie szczególnych technik formatowania i wewn˛etrznej warstwy logicznej (formuły, Add - Ins), co ma zagwarantować ich prawidłowe przeniesienie. Dotyczy to w szczególności Add Ins, takich jak 3rd - Party i Standard Excel. Poniżej pokrótce opisaliśmy i objaśniliśmy niektóre z danych obszarów: ◦ Należy sprawdzić ustawienia źródeł danych dla Charts. Zasadniczo Excel jest znacznie bardziej elastyczny niż Calc, jeśli chodzi o obszar danych Charts. OOo / SO wymaga, np. żeby etykiety zawsze przyporzadkowane ˛ były do pierwszego wiersza albo kolumny. Jeśli tak nie jest, wówczas Charts importowane sa˛ z reguły bez etykiet. ◦ Sprawdzić czy dokumenty sa˛ chronione hasłem. Calc nie umie otwierać Spreadsheets Excel chronionych hasłem. Dlatego przed konwersja˛ należy usunać ˛ hasło. ◦ Należy unikać 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 określajace ˛ Array (np. {A1:B2}). ◦ Należy unikać znaków specjalnych w nazwach arkuszy. Excel obsługuje wi˛ecej znaków specjalnych w nazwach arkuszy niż Calc. ◦ Należy unikać arkuszy zawierajacych ˛ ponad 32.000 zapisanych wierszy i Spreadsheets z ponad 256 arkuszami kalkulacyjnymi, ponieważ Calc obecnie nie obsługuje wi˛ekszej ilości wpisów (patrz także 3.15.4.3). ◦ Należy unikać różnych ustawień Widok dla różnych arkuszy kalkulacyjnych obsługiwanych przez Excel. W Calc takie ustawienia można zadawać tylko globalnie dla całego dokumentu. ◦ Należy sprawdzić wielkość komórek pod katem ˛ tekstu wyrównanego do prawej. Jeśli komórka b˛edzie zbyt mała, wówczas tekst nie zostanie przedłużony w lewo poza komórk˛e. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 291 Dokumenty PowerPoint Proste prezentacje PowerPoint zazwyczaj można bez problemu przenosić za pomoca˛ programu Impress. Prezentacje, które korzystaja˛ z rozszerzonych funkcji layout i rozszerzonych efektów, prowadza˛ na ogół do różnej prezentacji w skonwertowanym dokumencie. Kroki wyszczególnione poniżej powinny pomóc w zachowaniu pierwotnego formatu: ◦ należy unikać, usunać ˛ albo zmienić obiekty - cienie, które nie sa˛ obsługiwane przez Impress. Impress nie obsługuje wszystkich formatów cieni z PowerPoint. Rysunek (rys. 3.34) przedstawia konwersj˛e cieni z PowerPoint do Impress. ◦ należy unikać, usunać ˛ albo zmienić atrybuty obiektów, takie jak: – nakładanie si˛e trzech kolorów – kraw˛edzie z podwójnych i potrójnych linii – zaokraglone ˛ kraw˛edzie. Nie sa˛ one obsługiwane przez Impress. Na potrzeby konwersji należy uzyskać: – podwójne nakładanie si˛e kolorów – kraw˛edzie złożone z prostych linii. Zaokraglone ˛ kraw˛edzie b˛eda˛ automatycznie przekształcane w kraw˛edzie prostokatne. ˛ ◦ brakujace ˛ informacje we właściwościach dokumentów. W Impress, w przeciwieństwie do PowerPoint, nie jest zapisywana data ostatniego dost˛epu. Ponadto właściwości dokumentu PowerPoint nie sa˛ wraz z nim importowane do skonwertowanego dokumentu. Obydwa te braki można w razie potrzeby obejść badź ˛ wyrównać za pomoca˛ makr. ◦ przypadkowy wybór wielokrotnych efektów przejścia. Impress nie obsługuje przypadkowego wyboru, podczas gdy stosowane sa˛ wielokrotne efekty przejścia. Ważne jest, aby przed konwersja˛ zmienić je w proste efekty. W przeciwnym razie w wyniku kompresji zostana˛ one automatycznie przekształcone w efekty pionowych linii. Ponadto należy nadmienić, że w Impress niektóre nazwy efektów przejścia moga˛ być inne oraz że program ten w przypadku niektórych efektów może si˛e nieco inaczej zachowywać niż PowerPoint. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 292 ◦ brakujaca ˛ obsługa „rysowania opowiadania“. Impress w przeciwieństwie do PowerPoint nie obsługuje „rysowania opowiadania“. W Impress do każdego slajdu można dołaczać ˛ własny plik dźwi˛ekowy. Aby móc nadal korzystać z rysunków stworzonych w PowerPoint, trzeba je ponownie narysować, albo skonwertować metoda˛ Splitting72. 73 Rysunek 3.34: Obiekty - cienie w PowerPoint i Impress 3.15.4.7 Konwertowanie Sposoby konwersji Dokumenty MS Office można konwertować do OOo / SO wykorzystujac ˛ konwersj˛e pojedyncza˛ albo konwersj˛e Batch: ◦ konwersja pojedyncza Dokument MS należy otworzyć w OOo / SO i zapisać jako dokument OOo / SO. ◦ konwersja Batch Dane dokumenty należy skopiować do odpowiedniego katalogu (należy go specjalnie w 72 Wi˛ecej informacji znajduje si˛e w „StarOffice 6.0 Software Migration Guide“, strona 47, „Re-record or split narration“. 73 Źródło: „StarOffice 6.0 Migration Guide"http://uk.sun.com/software/staroffice/pdf/ somigrationguide.pdf ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 293 tym celu utworzyć). Nast˛epnie korzystajac ˛ z funkcji „Plik / Autopilot / Konwerter dokumentów“ można zainicjalizować proces Batch. Najpierw należy wybrać format źródłowy (MS albo OOo / SO) (patrz rys. 3.35), a potem zdefiniować czy chodzi o dokumenty, czy o szablony i w jakim katalogu si˛e one znajduja.˛ Nast˛epnie należy ustalić, w jakim katalogu docelowym maja˛ być składowane skonwertowane dokumenty (patrz rys. 3.36). Na końcu należy przekonwertować wszystkie dokumenty MS z katalogu źródłowego i umieścić je w katalogu docelowym jako dokumenty OOo / SO. Rysunek 3.35: Konwerter dokumentów: wybór formatu źródłowego ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 294 Rysunek 3.36: Konwerter dokumentów: wybór katalogu źródłowego i docelowego Jak widać na rysunku (rys. 5.5.3), konwerter dokumentów potrafi rozróżniać dokumenty i szablony dokumentów. Istotna różnica polega tu na tym, że szablon MS Office można zapisać także jako szablon OOo / SO. To, jaki sposób konwersji jest najkorzystniejszy w określonej chwili, zależy od stopnia skomplikowania dokumentów lub szablonów (patrz rozdział 3.15.4.5). Ponadto należy bliżej ocenić każda˛ sytuacj˛e, gdy chodzi o konwertowanie makr, sterowania OLE / COM albo integracj˛e zewn˛etrznych aplikacji. Trzeba je wówczas ponownie utworzyć. Opcje konwersji W OOo / SO do optymalizowania konwersji pojedynczej i konwersji Batch służa˛ jeszcze Ustawienia kompatybilności w Opcjach, z których należy skorzystać 74. Kontrola skonwertowanych dokumentów Po zakończeniu konwersji sensownie jest sprawdzić skonwertowane dokumenty pod katem ˛ przeniesienia do nich nast˛epujacych ˛ ustawień: 74 Patrz „StarOffice 6.0 Software Migration Guide“, strona 49 - 51 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 295 ◦ wielkości znaków ◦ kraw˛edzi ◦ tabulatorów ◦ wci˛eć ◦ długości wierszy (tekst w wierszu) ◦ odległości mi˛edzy wierszami wewnatrz ˛ akapitów ◦ odległości pomi˛edzy akapitami ◦ tabel ◦ nagłówków i stopek ◦ list ◦ grafik Pozostałe działania zwiazane ˛ z konwersja˛ Oprócz podstawowej konwersji istniejacych ˛ dokumentów i szablonów, może ewentualnie pojawić si˛e potrzeba przeniesienia do nowego systemu istniejacych ˛ wpisów autotekstu, jak też tworzonych przez długi czas słowników użytkowników. Przekazywanie wpisów autotekstu z istniejacych ˛ szablonów do OOo / SO można zautoma75 tyzować . Zarówno MS Office, jak i OOo / SO obsługuja˛ tworzenie słowników użytkownika i zarza˛ dzanie nimi. W obydwu aplikacjach słowniki posiadaja˛ rozszerzenie „.dic“, jednak nie sa˛ ze soba˛ kompatybilne. MS Office zapisuje swoje słowniki w postaci zwykłych plików tekstowych, natomiast słowniki w OOo / SO składowane sa˛ w formacie własnościowym. Na razie nie ma jeszcze możliwości automatycznej migracji routine. 75 Szczegóły opisane zostały w „StarOffice 6.0 Migration Guide“, strony 69 - 71. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.15.4.8 296 Integracja zewn˛etrznych aplikacji W kontekście migracji do OOo / SO ważna˛ rol˛e w przypadku zewn˛etrznych aplikacji odgrywa stopień zintegrowania z MS Office Suite. Wiele stosowanych obecnie w urz˛edach aplikacji specjalistycznych oraz standardowych została zaprojektowana specjalnie pod katem ˛ środowiska MS Windows i w dużym stopniu korzysta z własnościowych modułów API Windows, takich jak: ◦ MAPI ◦ COM ◦ DDE ◦ ... Stopień zintegrowania ze środowiskiem Windows może być przy tym całkiem różny. Prosta˛ i nie sprawiajac ˛ a˛ wi˛ekszych problemów integracja˛ jest korzystanie z interfejsu MAPI w celu komunikowania si˛e z domyślnym klientem poczty elektronicznej z poziomu aplikacji. Z daleko wyższym stopniem integracji mamy do czynienia, gdy zewn˛etrzna aplikacja zezwala tylko określonym aplikacjom MS badź ˛ bezwzgl˛ednie wymaga ich stosowania, aby możliwe było pełne wykorzystanie funkcjonalności niniejszej aplikacji. Tego typu różnice w stopniu zintegrowania zewn˛etrznych aplikacji z Windows oraz z MS Office Suite wymuszaja˛ dokładne sprawdzenie, czy migracja jest możliwa z technicznego punktu widzenia i jakie nakłady sa˛ z nia˛ zwiazane. ˛ O ile dost˛epny jest kod źródłowy zewn˛etrznej aplikacji, należy w każdym przypadku sprawdzić, czy możliwa jest integracja z OOo / SO poprzez udost˛epniany 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łużac ˛ a˛ do rozszerzania funkcjonalności Office oraz do automatyzacji Office w Windows (patrz podrozdział 3.15.3.2). Obszar zastosowania si˛ega aż do automatyzacji całych Workflows wewnatrz ˛ organizacji pomi˛edzy poszczególnymi oddziałami. Ponieważ makra i skrypty opieraja˛ si˛e w pierwszym rz˛edzie na VBA, nie można wykonywać ich w OOo / SO. Obecnie nie jest oferowane rozwiazanie ˛ umożliwiajace ˛ automatyczna˛ migracj˛e do OOo / SO. Dlatego migracj˛e istniejacych ˛ makr oraz aplikacji OLE / 76 Wi˛ecej informacji o UNO znajduje si˛e na stronie: http://udk.openoffice.org/common/man/uno. html 77 W „StarOffice 6.0 Migration Guide“ na stronie 73 integracja z OOo / OS została nakreślona w pi˛eciu krokach. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 297 COM, o ile maja˛ być nadal używane, trzeba przeprowadzić r˛ecznie albo utworzyć je od nowa. Wówczas, w zależności od ilości, stopnia skomplikowania i jakości dokumentacji, w pewnych okolicznościach nakłady moga˛ być bardzo wysokie, co może doprowadzić także do powstania znacznych kosztów. Z drugiej jednak strony zyskuje si˛e wówczas możliwość skonsolidowania makr i aplikacji OLE / COM, jak i nowego ukierunkowania strategii informatycnej w zakresie automatyzacji biura. Wskazówka: Aby w przyszłości nie być uzależnionym od określonego pakietu Office, moduły wymagane do automatyzacji należy zaimplementować jako składniki Java albo C++. 3.15.4.10 Środowisko programowania OOo/SO OOo / SO posiada, tak samo jak MS Office, własne API78, co oznacza, że moga˛ wykonywać takie same zadania. Zarówno Java, jak i C++ umożliwiaja˛ ponadto rozwijanie składników, które jako Plug - In moga˛ spełniać najróżniejsze zadania wewnatrz ˛ OOo / SO. ◦ nowe typy Chart ◦ nowe funkcje Calc ◦ Wizards ◦ dodatkowe funkcje dla użytkownika ◦ rozszerzenia StarBasic StarBasic jest zintegrowanym z OOo / SO, modularnym j˛ezykiem programowania i działa według takich samych zasad, jak VBA. Struktura i składnie obydwu j˛ezyków sa˛ w dużej cz˛eści bardzo podobne, dlatego wprawny programista VBA nie b˛edzie miał wi˛ekszych trudności przy przenoszeniu makr VBA. Oprócz API, OOo / SO udost˛epnia, tak jak MS Office, własne środowisko programowania (Integrated Development Environment (IDE)), którego interfejs użytkownika jest bardzo zbliżony do środowiska programisty w MS Office79. 78 Wszystkie istotne informacje na ten temat znaleźć można pod nast˛epujacym ˛ adresem WWW http://api. openoffice.org/ (dokumentacja online). Specyfikacj˛e interfejsu można przeczytać na stronie http://udk. openoffice.org/. 79 Dalsze wskazówki odnośnie post˛epowania w środowisku programistycznym i środowisku programowania znaleźć można w „StarOffice 6.0 Migration Guide“, strony 79 - 90. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.15.4.11 298 Kompatybilność z MS Office Z poprzedniego rozdziału wyraźnie wynika, że nie istnieje 100% - owa kompatybilność z MS Office. Cóż to oznacza, jeśli chodzi o wymian˛e dokumentów pomi˛edzy użytkownikami OOo / SO a użytkownikami MS Office? Odpowiedzi na to pytanie należy udzielić na dwóch płaszczyznach. 1. Należy uwzgl˛ednić cel, w jakim sa˛ wymieniane dokumenty. 2. Należy również uwzgl˛ednić stopień skomplikowania dokumentów, które maja˛ być wymieniane. Wymiana dokumentów odbywa si˛e z powodów czysto informacyjnych W takim przypadku stopień skomplikowania wymienianych dokumentów nie odgrywa żadnej roli. Dokumenty, które maja˛ być wymieniane należy przekonwertować do formatu PDF. Każdy użytkownik dysponuje przegladark ˛ a˛ plików PDF, a jeśli tak nie jest, wówczas, można ja˛ nieodpłatnie pobrać z Internetu. Stosowanie formatu PDF, jako formatu wymiany dokumentów, zalecane jest niemieckim urz˛edom już od dłuższego czasu. Wymiana dokumentów odbywa si˛e w celu ich wspólnej edycji W takim przypadku stopień złożoności dokumentu, zgodnie z tym, co wynika już z wcześniejszej oceny, odgrywa bardzo ważna˛ rol˛e. 1. Jeśli chodzi o proste dokumenty, wówczas wspólna edycja może odbywać si˛e bez wi˛ekszych problemów. Funkcje przetwarzania w OOo / SO i MS Office potrafia˛ ze soba˛ współpracować. 2. Jeśli jednak chodzi o skomplikowane dokumenty, wówczas podczas ich wspólnej edycji należy pogodzić si˛e z wyraźnymi ograniczeniami. ◦ W przypadku przetwarzania tekstu oraz arkuszy kalkulacyjnych, wspólna edycja zalecana jest tylko na poziomie treści. Odpowiedzialność za formatowanie należy jednoznacznie zdefiniować po jednej stronie i wykonać formatowanie dopiero po zakończeniu pracy nad treścia.˛ Post˛epowanie takie obydwie strony musza˛ ze soba˛ uzgodnić. ◦ Wskutek różnic w Chart - Engines, także w arkuszach kalkulacyjnych można tworzyć Charts dopiero po zakończeniu pracy nad danymi. Jeśli Charts maja˛ być utworzone za pomoca˛ Calc, wówczas należy przestrzegać ograniczeń dotyczacych ˛ tworzenia etykiet (patrz wyżej). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 299 ◦ Nie jest możliwa wspólna edycja tabel Pivot, ponieważ Calc ich nie obsługuje. ◦ Nie można zalecić wspólnej edycji skomplikowanych prezentacji. Jeśli odbywać si˛e ma wspólna edycja dokumentów pochodzacych ˛ z OOo / SO i z MS Office, wówczas należy stosować si˛e do nast˛epujacych ˛ zasad: ◦ Należy używać zgodnego formatu dokumentów. Jeśli posługujemy si˛e OOo i SO koniecznie musimy dostosować si˛e do formatów MS Office, gdyż w MS Office nie sa˛ dost˛epne filtry OOo / SO. Jeśli istnieje format obsługiwany przez obydwa pakiety, taki jak np. RTF, wówczas należy go używać. ◦ Należy unikać tak zwanej konwersji „Round Trip“. ◦ Formatowanie należy wykonywać dopiero w ostatnim kroku / ostatniej instancji, ponieważ mapowanie pomi˛edzy OOo / SO a MS Office nie jest realizowane w skali jeden do jednego. ◦ Nie należy edytować dokumentów w Mixed - Mode, które – używane sa˛ wspólnie przez wiele osób i – ewentualnie sa˛ jeszcze wyposażone w mechanizmy automatyzacji. ◦ Migracja dokumenty końcowych powinna odbywać si˛e w formacie PDF. 3.15.5 Migracja kontynuacyjna Jeśli chodzi o migracj˛e kontynuacyjna,˛ należy przede wszystkim ocenić migracj˛e z Office 97 do Office XP (2002), ponieważ z punktu widzenia migracji, obydwie te wersje istotnie si˛e od siebie różnia.˛ W przypadku zastapienia ˛ Office 2000 przez Office XP zmiany, na które należałoby zwrócić uwag˛e, nie sa˛ już tak znaczne, wzgl˛ednie zostały już zaimplementowane i oceniliśmy je w opisie migracji z Office 97 do Office XP. Wersji MS Office wcześniejszych od Office 97 nie ocenialiśmy. W swoich dokumentach Microsoft odnosi si˛e do migracji do Office XP 80 badź ˛ w przypadku prezentacji różnic81 do wcześniejszych wersji, w szczególności także do punktu wyjścia, jakim jest Office 97. 80 Microsoft Office XP Deployment Planing Blueprint, marzec 2001 (XPBluePrint) i „Office XP Migration Blueprint“, 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 nowości, wynikajace ˛ z migracji do Office 2003. 3.15.5.1 Office 97 do Office XP Konwertowanie istniejacych ˛ dokumentów W formatach dokumentów nie pojawiły si˛e istotne różnice. Można je w prosty sposób otwierać za pomoca˛ odpowiednich aplikacji wchodzacych ˛ w skład Office XP. Jednakże nie istnieja˛ wiarygodne, doświadczalne dane, które potwierdzaja,˛ że w takim przypadku bezbł˛ednie działaja˛ wszystkie formatowania, szablony, makra i skrypty. W poszczególnych, udowodnionych przypadkach nie była możliwa bezproblemowa konwersja dokumentów badź ˛ szablonów Office 97. Dokładnie tak samo, jak OOo / SO, również Office XP obsługuje konwersj˛e Batch, która˛ można przeprowadzić za pomoca˛ „asystentów konwersji stosowej“. Oprócz standardowych filtrów konwersji, Microsoft oferuje jeszcze „Office Konverter Pack“82 . Kompatybilność z wcześniejszymi wersjami Formaty danych z Office 97, 2000 i XP sa˛ kompatybilne. Zasadniczo w każdej wspomnianej wersji można otwierać, edytować i ponownie zapisywać wszystkie dokumenty. Jednak może si˛e zdarzyć, że pojedyncze nowe funkcje i formatowania z Office XP, nie b˛eda˛ wyświetlane 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 można z nich nadal korzystać po nast˛epnym otwarciu w Office XP. Migracja makr, skryptów i integracja zewn˛etrznych aplikacji Główna trudność podczas migracji do Office XP dotyczy zmian wewnatrz ˛ środowiska programistycznego Office. Trzeba przy tym zwrócić szczególna˛ uwag˛e na zmian˛e w „Object Model“. Wraz ze zmiana˛ VBA w wersji 5 do wersji 6 (Office 2000) oraz do wersji 6.3 (Office XP) na kompatybilność wzgl˛edem wcześniejszych wersji i tym samym na migracj˛e, główny wpływ wywarła zmiana metody przyłaczania ˛ obiektów. Zasadniczo należy przyjać, ˛ że aplikacje Office (makra, skrypty, zewn˛etrzne aplikacje), które powstały w środowisku programistycznym Office 97, można bez problemów stosować także w środowisku Office XP, bez konieczności dostosowania. Mimo zasadniczo istniejacej ˛ kompatybilności zwrotnej, Microsoft nie wyklucza, że moga˛ pojawić si˛e wyjatki, ˛ które sprawia,˛ że dostosowanie b˛edzie wymagane 83. 82 http://www.microsoft.com/office/ork/xp/appndx/appa09.htm „Microsoft Office Resource Kit, Technical Article (whitepaper), Microsoft Office 97 to Microsoft Office XP Migration Issues“ (Xpdelta). 83 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 301 Znacznie bardziej problematyczne może to być w odwrotnej sytuacji, co oznacza, że nowe aplikacje napisane dla Office XP z trudem moga˛ być stosowane w środowisku Office 97. Dotyczy to także i w szczególności makr i należy o tym pami˛etać, gdy wewnatrz ˛ organizacji nie przeprowadzono pełnej migracji badź ˛ migracja wykonywana jest sukcesywnie i jednocześnie wykorzystywane sa˛ obydwie wersje Office. Wskutek niepewności, czy możliwe b˛edzie dalsze używanie wszystkich aplikacji Office, wzgl˛ednie czy niezb˛edne b˛edzie dostosowywanie aplikacji, powstaje konieczność, podobnie jak w przypadku migracji zast˛epujacej, ˛ przeprowadzenia dokładnej analizy stanu istniejacych ˛ makr, skryptów i zewn˛etrznych aplikacji. Różnice w obszarze funkcjonalności Jeśli chodzi o zmiany w funkcjonalnościach, na pierwszy plan wysuwa si˛e wprowadzenie tak zwanych Smarttags84 i rozszerzonych funkcjonalności umożliwiajacych ˛ wspólna˛ edycj˛e, wzgl˛ednie korzystanie z dokumentów. Smarttags sa˛ rozwini˛eta˛ możliwościa˛ automatyzacji poprzez kontekstowa˛ obsług˛e użytkowników. Smarttag wywołuje funkcj˛e w oparciu o wpis (np. z góry zdefiniowane słowo albo znana˛ liczb˛e). Można wyróżnić proste Smarttags i Smarttags oparte na COM. Zarzadzanie ˛ prostymi Smarttags85 odbywa si˛e w listach XML, które należy składować w centralnie zdefiniowanym miejscu w sieci komputerowej a nast˛epnie udost˛epnić wszystkim użytkownikom. Smarttags 86 oparte na COM należy stosować jako tak zwane Add - Ins. Jednak nie należy upatrywać w Smarttags dużych korzyści. Smarttags moga˛ z pewnościa˛ ułatwić prac˛e poczatkuj ˛ acemu ˛ informujac ˛ go w odpowiednim miejscu o dost˛epnych funkcjonalnościach i pomagajac ˛ podczas formatowania. Jednak równie dobrze moga˛ one całkowicie zdezorientować poczatkuj ˛ acego, ˛ gdy nie b˛edzie on umiał używać oferowanych funkcjonalności. Aby tego uniknać, ˛ podczas migracji konieczne jest dłuższe szkolenie. W przyszłości Smarttags umożliwia˛ automatyzacj˛e w obszarze aplikacji, która nie b˛edzie odpowiadać żadnemu otwartemu standardowi i b˛edzie współpracować wyłacznie ˛ z MS Office. Wi˛eksze stosowanie prowadzić b˛edzie ostatecznie do jeszcze wyższych nakładów w przypadku zast˛epowania MS Office badź ˛ zapobiegnie migracji z powodów ekonomicznych. W przypadku rozszerzonych funkcjonalności, do wspólnej edycji i stosowania dokumentów Office wykorzystać można przede wszystkim tak zwane „SharePoint Team Services“. Nie wolno 84 Einführung in Smarttags auf den Microsoft Web - Seiten http://www.microsoft.com/germany/ms/officexp/developer/smarttags/ einfuehrung.htm 86 http://www.microsoft.com/germany/ms/officexp/developer/smarttags/ comsmarttag.htm 85 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 302 ich mylić z SharePoint Portal Server, który opisany został w rozdziale 3.12 87. Na stronie WWW: http://www.microsoft.com/sharepoint/server/evaluation/overview/technologi asp pokazane zostały istotne różnice 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łuża˛ one do udost˛epniania przez Internet albo Intranet wspólnych dokumentów grup roboczych wszystkim członkom grupy roboczej przy wykorzystaniu platformy WWW. Dzi˛eki prostej możliwości rozbudowy, SharePoint Team Services szczególnie dobrze nadaja˛ si˛e dla małych organizacji i do obsługi grup roboczych Adhoc, obsługiwanych także za pomoca˛ Internetu poza granicami organizacji. Jednak w takim przypadku należy także uwzgl˛ednić ryzyko zwiazane ˛ z bezpieczeństwem. Właśnie w tym miejscu autorzy niniejszego poradnika widza˛ najlepsze możliwości łatwego, opartego na WWW i XML (oddzielenie treści od warstwy prezentacji) tworzenia i publikowania wspólnych dokumentów w grupach roboczych, niezależnie od własnościowych formatów dokumentów. Szczególnie w przypadku współpracy wykraczajacej ˛ poza granice organizacji nie należy zakładać, że wszyscy korzystaja˛ z takich samych środków. Aby być otwartym na każda˛ form˛e współpracy, należy stosować ogólnie uznane standardy, takie jak XML. Wydaje si˛e, że racj˛e t˛e uznał także Microsoft, który chce w przyszłości, poczawszy ˛ od Office 2003, szerzej wykorzystywać wspomniany standard. 3.15.5.2 Spojrzenie w kierunku Office 2003 Wraz z Office 2003, który wejdzie na rynek jeszcze tego lata (czerwiec 2003), firma Microsoft chciałaby uczynić z XML główny format dokumentów wykorzystywanych w pakiecie Office. Dotychczas dost˛epne informacje znane sa˛ z informacji o testach wersji beta 2 MS Office 2003 88 oraz z opisów technicznych i artykułów opublikowanych89 przez Microsoft. Najwi˛ecej informacji dotyczy wykorzystania XML w edytorze Word 2003. Z informacji tych powstaje nast˛epujacy ˛ obraz: ◦ Microsoft ukierunkował si˛e w stron˛e standardu XML z W3C (World Wide Web Consortium), jednak zmodyfikował go dla swoich celów. 87 Na stronie WWW http://www.microsoft.com/sharepoint/server/evaluation/ overview/technologies.asp pokazane zostały istotne różnice i zwiazki. ˛ 88 http://xml.coverpages.org/microsoftXDocs.html 89 Microsoft Office Word 2003 Beta 2 Preview (Part 1 of 2), Microsoft Office Word 2003 Beta 2 Preview (Part 2 of 2), Beitrag aus TechNet Datenbank i inne. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 303 ◦ ten zmodyfikowany XML b˛edzie domyślnym formatem plików w Office 2003. Oprócz tego b˛edzie można równolegle korzystać także ze starych formatów plików. ◦ dla Word istnieje własny, charakterystyczny schemat XML (Word ML). ◦ pliki Word b˛edzie można zapisywać jeszcze w tak zwanym „pure XML“. Użytkownik b˛edzie przy tym informowany, że plik w takim przypadku może utracić formatowania. ◦ aby otworzyć w Word obce dokumenty XML, trzeba jednocześnie udost˛epnić ważny plik - schemat dla obcego dokumentu. ◦ Obcym dokumentom moga˛ być przypisywane własne Stylesheets (plik XLST). ◦ jednak podczas zapisywania w charakterystycznym formacie XML dla Word, tworzony jest pojedynczy plik, w którym zawiera si˛e wszystko. ◦ w przypadku Excel 2003 b˛edzie to wygladać ˛ podobnie. ◦ Office 2003 wyposażony jest w parser XML, który zgłasza bład, ˛ gdy np. wykorzystywana składnia jest nieprawidłowa, albo dokument nie odpowiada podanemu plikowi - schematowi. ◦ W sumie, w oparciu o niniejsze informacje nie można jeszcze ostatecznie wypowiadać si˛e na temat kompatybilności zachodzacej ˛ pomi˛edzy „Standard - XML“ i „Microsoft XML“. Powstaje tu przede wszystkim pytanie o to, jakie skutki b˛eda˛ miały rozszerzenia XML oferowane przez Microsoft na wymian˛e dokumentów niezależna˛ od platformy i czy Microsoft udost˛epni swoje rozszerzenia w otwartej formie? 3.15.6 Inne aplikacje desktopowe Oprócz ocenionych wcześniej pakietów biurowych, istnieje jeszcze cały szereg innych aplikacji desktopowych, które stały si˛e niezb˛edne podczas codziennej pracy. W nast˛epnych podrozdziałach przedstawimy pokrótce najważniejsze fakty dotyczace ˛ aplikacji desktopowych oferowanych przez desktop windowsowy i adekwatne, alternatywne aplikacje dost˛epne na desktopie linuksowym. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 3.15.6.1 304 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 funkcjonalności dalece odbiegaja˛ od tych oferowanych przez MS Project. 3.15.6.2 Desktopy W wi˛ekszości dystrybucji Linuksa użytkownikom udost˛epniane sa˛ gotowe desktopy wraz z najważniejszymi aplikacjami zintegrowanymi w podobny sposób, jak w przypadku desktopu windowsowego. Głównymi przedstawicielami sa˛ tu KDE i GNOME. Graficzne interfejsy użytkownika desktopów realizowane sa˛ poprzez system X - Window oraz różne menedżery okien Dygresja: System X-Window a menedżer okien System X-Window92, nazywany także „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 zasad˛e klient - serwer, przy czym serwer udost˛epnia zasoby, takie jak ekran, klawiatura i mysz, a klient, którym jest, np. jakiś program użytkowy, komunikuje si˛e z serwerem poprzez protokół X. Serwer i klient moga˛ przy tym pracować zarówno na oddzielnych maszynach, jak też na jednej i tej samej maszynie. W przypadku korzystania z Linuksa na komputerach osobistych jest to reguła.˛ Dzi˛eki umiej˛etności pracy sieciowej X nadaje si˛e szczególnie dobrze do zastosowań z Thin Clients. „Look and Feel“ graficznego interfejsu użytkownika nie jest ustalane przez sam X, lecz przez każdorazowo stosowany „Toolkit“ (np. Xt, Athena Widgets, OSF / Motif, Tk, Qt, Gtk+ itd.) i każdorazowy menedżer okien (np. IceWM). Menedżerem okien jest klient X, którego zadanie polega na zarzadzaniu ˛ układem, wielkościa˛ itd. okien programów, ich „ozdobnikami“, dost˛epnymi kolorowymi tablicami i wieloma innymi elementami. Ze wzgl˛edu na dost˛epność dużej ilości menedżerów okien istnieje możliwość dowolnego kształtowania desktopu93. Desktopy opisane poniżej posiadaja˛ swoje własne menedżery okien. KDE KDE jest przejrzystym i nowoczesnym środowiskiem desktopowym przeznaczonym dla li90 http://mrproject.codefactory.se/ http://ganttproject.sourceforge.net/ 92 Wi˛ecej informacji znajduje si˛e na stronie http://www.x.org/ 93 http://www.plig.org/xwinman/intro.html 91 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 wyst˛epuje w przypadku desktopów Windows i Mac (patrz rys. 3.37). Można go jednak dostosowywać według własnych potrzeb i gustu. (patrz rys. 3.38). Zasadniczo zmienić można niemal wszystko. Można ustawiać różne tematy graficzne, ramki i zestawy ikon. Cz˛eściowo zależy to od czekajacych ˛ w tle menedżerów okien, które także można dowolnie wybrać. Korzystać można ze wszystkich menedżerów okien X11R6. Dzi˛eki tym elastycznym możliwościom kształtowania wygladu ˛ można stworzyć dopasowany, jednolity desktop spełniajacy ˛ indywidualne potrzeby urz˛edu lub działu. Istnieje przy tym możliwość ustawienia wybranego stopnia dowolności dla użytkowników, jeśli chodzi o ustawienia osobiste. 94 Rysunek 3.37: Desktop KDE – przykład 1 94 Źródło: http://www.kde.org/screenshots/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 306 95 Rysunek 3.38: Desktop KDE – przykład 2 KDE dostarcza mi˛edzy innymi własny pakiet biurowy Koffice. Innymi aplikacjami desktopowymi w KDE sa: ˛ ◦ menedżer 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“ Ważne sa˛ także różne narz˛edzia administracyjne i zintegrowane środowisko programowania. Kompletna˛ dokumentacj˛e znaleźć można na stronie http://docs.kde.org/. Oprócz tego z poziomu KDE można oczywiście również korzystać z „aplikacji nie KDE“. 95 Źródło: http://www.kde.org/screenshots/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 307 GNOME GNOME96 jest cz˛eścia˛ projektu Open Source GNU97. GNOME to skrót od „GNU Network Object Model Environment". Jeśli chodzi o layout, GNOME jest tak samo elastyczny, jak KDE (patrz rys. 3.39 i rys. 3.40). Również GNOME udost˛epnia własny pakiet biurowy i środowisko programowania. Niektórymi ze znanych aplikacji sa: ˛ ◦ menedżery 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 dost˛epnych w GNOME udost˛epniana jest na stronie http://www.gnome.org/softwaremap/. 98 Rysunek 3.39: Desktop GNOME – przykład 1 96 http://www.gnome.org/ http://www.gnu.org/ 98 Źródło: http://vhost.dulug.duke.edu/~louie/screenshots/2.2/ 97 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 308 99 Rysunek 3.40: Desktop GNOME – przykład 2 3.15.6.3 Menedżery plików ◦ Konqueror ◦ Nautilus ◦ GNOME Midnightcommander 3.15.6.4 Przegladarki ˛ WWW W Linuksie użytkownikom udost˛epniany jest cały szereg przegladarek ˛ WWW, z których można wybierać według gustu i odpowiednio do potrzeb. Do najważniejszych z nich należa: ˛ ◦ Galeon Galeon100 jest przegladark ˛ a˛ WWW środowiska GNOME, która opiera si˛e na Mozilla Rendering Machine „Gecko“. Galeon jest lekka˛ przegladark ˛ a˛ wyposażona˛ w najbardziej niezb˛edne funkcjonalności. Jest za to szybki i kompatybilny ze wszystkimi standardami. 99 100 Źródło: http://vhost.dulug.duke.edu/~louie/screenshots/2.2/ http://galeon.sourceforge.net/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 309 ◦ Beonex Communicator Beonex Communicator jest przegladark ˛ a˛ Open Source udost˛epniana˛ na licencji GPL. Przegladarka ˛ ta dost˛epna jest we wszystkich znanych dystrybucjach Linuksa, jak też dla innych platform. Beonex Communicator uznawana jest za jedna˛ z najbezpieczniejszych przegla˛ darek. ◦ Konqueror Konqueror101 jest nie tylko menedżerem plików w KDE (patrz wyżej), lecz można go także wykorzystywać jako przegladark˛ ˛ e WWW. Konqueror, podobnie jak Explorer na desktopie windowsowym jest w pełni zintegrowany z desktopem KDE. Ponadto Konqueror udost˛epniany jest na licencji GPL. ◦ Mozilla Mozilla102 jest przegladark ˛ a˛ Open Source, której kod źródłowy dost˛epny jest na licencjach MPL „Mozilla Public License“), NPL („Netscape Public License“), LGPL i GPL, wzgl˛ednie 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 dost˛epne jest dla całego szeregu platform105. Opera jest produktem komercyjnym i trzeba za nia˛ płacić, chyba że użytkownikowi nie przeszkadza cały szereg zintegrowanych banerów reklamowych. W takim przypadku Oper˛e można ściagn ˛ ać ˛ za darmo z Internetu. Wszystkie z wymienionych przegladarek ˛ sa˛ w dużym stopniu zgodne z HTML 4. Maja˛ one zarówno wady, jak i zalety, np. obsługuj˛e Java i XML. Jak już wspomnieliśmy, Beonex uważana jest za przegladark˛ ˛ e najbezpieczniejsza,˛ podczas gdy Galeon oraz Opera uchodza˛ za przegladarki ˛ bardzo szybkie. Poniższa tabela raz jeszcze prezentuje zebrane cechy przegladarek. ˛ 101 http://www.konqueror.org/ http://www.mozilla.org/ 103 http://www.mozilla.org/MPL/ 104 http://www.opera.com/ 105 http://www.opera.com/download/index.dml?custom=yes 102 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI Przegladarka ˛ Wersja106 Galeon 1.2.10 Beonex 0.8.2 Konqueror 3.3.1 310 Klient poczty Klient Zgodność POP3 / IMAP Wiadomości z HTML 4 x x/x x 107 x 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 należacych ˛ do OSS 3.15.6.5 Klient poczty elektronicznej Dla desktopu linuksowego istnieja˛ również liczne klienty poczty elektronicznej (m. in. także takie, które sa˛ zintegrowane z przegladarkami ˛ WWW). Dwa z nich należy wyróżnić, dlatego opisaliśmy je poniżej. Jest to KMail i Sylpheed: KMail (a projekt Ägypten) KMail108 jest klientem poczty zintegrowanym z KDE, jednak może on pracować także w każdym innym środowisku. KMail jest przy tym Wolnym Oprogramowaniem. Oferuje on urz˛edom istotna˛ zalet˛e w porównaniu z innymi klientami poczty elektronicznej pracujacymi ˛ w Linuksie: Dla KMail istnieje wtyczka umożliwiajaca ˛ 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. Zgodność ze SPHINX gwarantuje, m.in. uzyskanie kompatybilności pomi˛edzy różnymi rozwiazaniami ˛ zgodnymi ze SPHINX oparta˛ na protokole „TeleTrast e.V. MailTrustT w wersji 2“. Dzi˛eki temu użytkownik w biurze może w ramach PKI za pomoca˛ S / MIME projektu „Ägypten“ wymieniać zaszyfrowane i podpisane wiadomości z użytkownikami pracujacymi ˛ w innych organizacjach, niezależnie od tego, czy korzystaja˛ oni, np. z Outlooka z zaimplementowana˛ Secure - Plug - In zgodna˛ ze SPHINX albo z LotusNotes z zaimplementowana˛ MailProtect - Plug - In. 106 Stan w momencie powstawania poradnika. Wersja KDE 108 http://kmail.kde.org/ 109 http://www.gnupg.org/aegypten/ 107 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 311 Oprócz tego KMail jest także cz˛eścia˛ składowa˛ rozwiazania ˛ Groupware znanego pod nazwa˛ „Kroupware“ (patrz podrozdział3.14.4.2). KMail obsługuje nast˛epujace ˛ protokoły: ◦ POP3 ◦ IMAP ◦ SMTP ◦ SMTP AUTH. Dla POP3, IMAP i SMTP istnieje także obsługa SSL / TLS. Sylpheed Klient poczty elektronicznej Sylpheed110 jest również projektem Open Source (GPL) i wart jest uwagi, gdyż dostarcza takiego samego „Look and Feel“, jak Outlook, b˛edac ˛ jednocześnie szybkim klientem poczty oraz czytnikiem wiadomości. Sylpheed obsługuje nast˛epujace ˛ protokoły: ◦ POP3 ◦ APOP ◦ IMAP4 ◦ SMTP ◦ SMTP AUTH ◦ NNTP. 3.15.6.6 Inne narz˛edzia Poniżej wymieniliśmy alternatywne narz˛edzia należace ˛ do rozwiazań ˛ OSS i pogrupowane według pojedynczych kategorii. ◦ edytor grafiki – Gimp http://www.gimp.org/ 110 http://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 użyciu klienta linuksowego W niemal wszystkich urz˛edach istnieje jedna badź ˛ wiele aplikacji specjalistycznych lub aplikacji standardowych, które sa˛ bardzo potrzebne do wypełniania specjalistycznych zadań i które dost˛epne sa˛ niestety tylko w postaci aplikacji windowsowych. Jeśli nie uda si˛e udost˛epnić tych aplikacji użytkownikom także pod Linuksem, wówczas skutkiem tego może być załamanie si˛e migracji do środowiska linuksowego. Długofalowym celem migracji musi być również ostateczne udost˛epnienie wspomnianych aplikacji, jako aplikacji linuksowych. W przypadku aplikacji standardowych urz˛edy skazane sa˛ na polityk˛e producenta oprogramowania, co do której nie da si˛e na ogół przewidzieć, kiedy dana aplikacja udost˛epniona zostanie dla jednej badź ˛ drugiej platformy linuksowej. Należy mieć nadziej˛e, że dzi˛eki coraz szerszemu wykorzystywaniu Linuksa i Open Source Software (OSS) w urz˛edach, producenci b˛eda˛ udost˛epniać swoje aplikacje w akceptowalnym terminie także dla tej platformy. W przypadku aplikacji specjalistycznych, które zostały napisane dla jednego badź ˛ wielu urz˛edów jako aplikacje indywidualne, urz˛edy musiałyby zamówić nowy program niezależny od platformy albo zlecić przeportowanie istniejacej ˛ aplikacji do Linuksa. Jednak coś takiego nie może ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 313 mieć miejsca w przypadku migracji, ponieważ tego typu zamierzenie byłoby niewykonalne zarówno z powodów czasowych, jak również finansowych i nie obroniłoby si˛e ze wzgl˛edów ekonomicznych. Zatem należy znaleźć rozwiazanie ˛ kompromisowe, które umożliwi urz˛edom dalsze korzystanie ze wspomnianych aplikacji także pod Linuksem do czasu, aż z ekonomicznego i technicznego punktu widzenia uzasadnione stanie si˛e wprowadzenie nowego oprogramowania albo przeportowanie starego lub aż udost˛epniona zostanie standardowa aplikacja linuksowa. Od dawna istnieja˛ rozwiazania, ˛ które umożliwiaja˛ aplikacjom windowsowym prac˛e na linuksowych stacjach roboczych. Produkty te można podzielić na trzy grupy: ◦ Rozwiazania, ˛ które pozwalaja˛ na bezpośrednie wykonywanie aplikacji windowsowych. Programy te nie wymagaja˛ posiadania licencji Windows. Zaliczaja˛ si˛e do nich WINE oraz Crossover Office. ◦ Rozwiazania, ˛ które potrafia˛ emulować PC, na którym może pracować Windows. Dzi˛eki nim na tym samym komputerze osobistym możliwe jest równoległe korzystanie z aplikacji windowsowych i linuksowych. Zalicza si˛e do nich VMware, Win4LIN. ◦ Produkty serwerowe, w przypadku których aplikacje windowsowe uruchamiane sa˛ na windowsowym serwerze aplikacji a wyświetlane na kliencie linuksowym i z niego obsługiwane: (Citrix, Microsoft Terminal Services). W każdym pojedynczym przypadku należy dokładnie sprawdzić, jakie rozwiazanie ˛ najlepiej nadaje si˛e dla danych aplikacji, wymagań i środowisk. Właściwości wymienionych rozwiazań, ˛ jak też koszty ich stosowania wyraźnie si˛e różnia.˛ Poniżej oceniliśmy kolejne rozwiazania ˛ pod katem ˛ ich właściwości technicznych i funkcjonalności. Szczególnie interesujacy ˛ jest tu stopień, 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 umożliwia uruchamianie innych systemów operacyjnych w maszynie wirtualnej. VMware emuluje przy tym wirtualny komputer posiadajacy: ˛ ◦ dyski twarde ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 314 ◦ nap˛ed dyskietek ◦ różne interfejsy oraz ◦ inna˛ infrastruktur˛e. Oprogramowanie to umożliwia równoczesna˛ prac˛e systemu emulowanego oraz właściwego systemu komputera (system operacyjny hosta). Obsługiwane systemy operacyjne Dzi˛eki całkowitej emulacji komputera, VMware uzyskuje bardzo wysoka˛ kompatybilność z wieloma systemami operacyjnymi. Obsługiwane sa˛ nast˛epujace ˛ systemy - goście: ◦ 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 dost˛epne jest dla wszystkich wykorzystywanych obecnie dystrybucji Linuksa. Program składa si˛e z rozszerzenia jadra ˛ Linuksa oraz programu użytkowego. Rozszerzenie jadra ˛ dostarczane jest wraz z kodem źródłowym, dzi˛eki czemu teoretycznie możliwe jest portowanie dowolnych wersji jadra. ˛ Programy wykonywalne W zależności od danego systemu operacyjnego możliwe jest nieograniczone wykonywanie wi˛ekszości obsługiwanych programów. Niewielkie ograniczenia istnieja˛ jedynie w obszarze programów multimedialnych. Dlatego VMware Workstation nadaje si˛e także zwłaszcza do uruchamiania aplikacji specjalistycznych, jak też aplikacji biurowych i internetowych. Głównym obszarem zastosowań jest ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 315 jednak obecnie rozwój oprogramowania, ponieważ developerzy moga˛ testować swoje wieloplatformowe aplikacje równolegle na jednej i tej samej maszynie, w różnych systemach operacyjnych. Ograniczenia Pełna emulacja komputera nadal jeszcze stawia duże wymagania wzgl˛edem maszyny, na której odbywa si˛e emulacja. Dlatego praca wielu programów w VMware jest odczuwalnie wolniejsza niż na porównywalnym, prawdziwym komputerze. Stopień integracji VMware pracujace ˛ na komputerze z Linuksem, gdzie ma miejsce emulacja, wyświetla desktop windowsowy we własnym oknie. Z tego okna można wywoływać poszczególne aplikacje windowsowe. Wymiana danych pomi˛edzy Windowsem a Linuksem nast˛epuj˛e poprzez emulowana˛ sieć. W tym celu konieczne jest ustawienie parametrów Samby podczas instalacji VMware. Ma to umożliwić dost˛ep 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 udost˛epnianie aplikacji windowsowych poprzez desktop windowsowy należy oceniać jako niezbyt ergonomiczne. Koszty VMware jest produktem komercyjnym, za używanie którego pobierana jest opłata 112. Aby móc używać aplikacji windowsowych, trzeba dodatkowo wykupić także licencje Windows. Do tego dochodza˛ jeszcze zwi˛ekszone koszty osprz˛etu spowodowane wyższymi wymaganiami stawianymi przez VMware. Biorac ˛ powyższe pod uwag˛e należy stwierdzić, że udost˛epnianie aplikacji windowsowych z wykorzystaniem VMware jest dość drogie. 111 Źródło: VMware http://www.vmware.com/products/desktop/ws_screens.html Bliższe informacje znaleźć można na stronie http://www.vmware.com/vmwarestore/pricing. html 112 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 317 Ocena Prawdziwa siła VMware tkwi raczej w tym, o czym już wspomnieliśmy, czyli w udost˛epnianiu dobrej platformy programistycznej dla aplikacji wieloplatformowych, niż w możliwości udost˛epniania aplikacji windowsowych w Linuksie. Dlatego VMware należy wykorzystywać w tym celu tylko w wyjatkowych ˛ przypadkach. GSX Server 2.5 VMware GSX Server opiera si˛e na tej samej technologii, jak VMware Workstation. Za pomoca˛ GSX Server można uruchamiać wirtualne maszyny jako procesy w tle. Serwerem tym można sterować zdalnie spod Windows albo Linuksa, jak również możliwe jest zdalne administrowanie poprzez interfejs WWW oraz specjalny, skryptowy API. Dzi˛eki temu można także jednocześnie uruchamiać, na osprz˛ecie firmy Intel, wiele systemów operacyjnych i konsolidować w ten sposób środowiska serwera. Jeśli chodzi o „obsługiwane systemy operacyjne“, „programy wykonywalne“, „ograniczenia“, „stopień integracji“, „koszty“ i „ocen˛e“ obowiazuj˛ ˛ e takie same uwagi, jak w przypadku opisanego wcześniej wariantu Workstation113. 3.15.7.2 Win4Lin Win4Lin 4.0 - Workstation Edition Win4Lin114 umożliwia 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 udost˛epnia usługi systemowe wymagane przez Windows poprzez szereg modułów jadra. ˛ Pliki systemu operacyjnego Windows zmieniane sa˛ podczas instalacji w taki sposób, że nie musi on już sam wykonywać w/w usług, lecz odwołuje si˛e do odpowiednich usług świadczonych przez moduły jadra. ˛ Dlatego w Win4Lin aplikacje działaja˛ z reguły znacznie szybciej niż w VMware. W Win4Lin, tak samo jak w VMware, desktop windowsowy udost˛epniany jest we własnym oknie. Po starcie programu, otwiera on okno, w którym bootuje si˛e Windows. Nast˛epnie użytkownik może w otwartym oknie uruchamiać aplikacje windowsowe i z nimi pracować (patrz rys. 3.42). 113 Ceny licencji serwera znajduja˛ si˛e na stronie http://www.vmware.com/vmwarestore/pricing. html 114 Producent Netraverse http://www.trelos.com/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 318 Win4Lin nie stawia także żadnych szczególnych wymagań sprz˛etowych. Oprogramowanie to może pracować na każdym współczesnym komputerze osobistym 115. Obsługiwane systemy operacyjne Win4Lin może współpracować z każda˛ wykorzystywana˛ obecnie dystrybucja Linuksa, o ile używa ona jadra ˛ z rodziny 2.4.x. Jak już wspomnieliśmy, za pomoca˛ Win4Lin możliwe jest uruchamianie nast˛epujacych ˛ wersji Windows116. ◦ 95 ◦ 98 ◦ ME Programy wykonywalne Za pomoca˛ Win4Lin 4.0 można z reguły udost˛epniać na linuksowej stacji roboczej aplikacje biurowe, internetowe a nawet aplikacje bazodanowe. Ograniczenia Poniżej wypunktowaliśmy istniejace ˛ ograniczenia: ◦ obsługiwane wersje Windows Należy tu oczekiwać, że wiele nowych aplikacji wkrótce nie b˛edzie mogło w nich pracować. ◦ łaty modułów windowsowych Nakładanie łat firmy Microsoft należy wykonywać ostrożnie, gdyż nie można wykluczyć, że podczas tego procesu wymienione zostana˛ pliki zmienione przez Win4Lin i system straci swoja˛ stabilność. 115 Wymagania sprz˛etowe zalecane przez producenta http://www.netraverse.com/products/ win4lin40/requirements.php 116 Szczegółowe dane znaleźć można na stronie http://www.netraverse.com/support/docs/400_ relnotes.html ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 319 ◦ udost˛epniana pami˛eć Aplikacjom windowsowym pracujacym ˛ w Win4Lin, od wersji 4.0, można udost˛epnić maksymalnie 128 MB pami˛eci operacyjnej. Pami˛eć wirtualna ograniczana jest jedynie przez dost˛epna˛ pojemność partycji dysku, na której znajduje si˛e katalog „$HOME/win“ użytkowników. ◦ obsługa interfejsów Nie sa˛ obsługiwane interfejsy DirectX i USB. Stopień integracji W Win4Lin, tak samo jak w VMware, desktop windowsowy udost˛epniany jest we własnym oknie, w którym można wywoływać aplikacje windowsowe. 117 Rysunek 3.42: Desktop windowsowy w Linuksie emulowany przez Win4Lin 117 Źródło: Netraverse fullsizescreenshot.jpg http://www.netraverse.com/products/win4lin40/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 320 Wymiana danych pomi˛edzy aplikacjami linuksowymi i windowsowymi jest jednak łatwiejsza niż w przypadku VMware. Dzi˛eki technice oferowanej przez Win4Lin, katalogi linuksowe moga˛ być prezentowane w postaci nap˛edów. Również w tym przypadku nie można jednak mówić o rzeczywistej integracji poszczególnych aplikacji. Po uruchomieniu programu wyświetlane jest okno, w którym użytkownik widzi bootujacy ˛ si˛e Windows, jeszcze przed umożliwieniem mu uruchamiania aplikacji i pracy z nimi. Koszty Win4Lin również jest produktem komercyjnym, za który należy zapłacić. Koszty licencji 118 sa˛ tu jednak znacznie niższe niż 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. Dzi˛eki temu praca aplikacji windowsowych w linuksowym emulatorze Win4Lin jest znacznie korzystniejsza niż w emulatorze VMware. Ocena Mimo kilku technicznych ograniczeń, Win4Lin jest obecnie w wielu przypadkach droga, ˛ która˛ można by podażać, ˛ a prowadzac ˛ a˛ do korzystania z aplikacji windowsowych w Linuksie. Jest tak zwłaszcza w przypadku, gdy dana aplikacja ma być używana tylko na niewielu stacjach roboczych. W przypadku, gdy korzystanie z aplikacji przewidziane jest na wielu stacjach roboczych, można ewentualnie skorzystać z Win4Lin Terminal Server, który pokrótce opisaliśmy w nast˛epnym paragrafie. Win4Lin Terminal Server 2.0 W Win4Lin Terminal Server firma Netraverse wykorzystała właściwości sieciowe protokołu X w celu umożliwienia korzystania z Win4Lin z poziomu innego systemu. Jest to możliwe, ponieważ wyświetlanie okien Win4Lin odbywa si˛e na desktopie linuksowym właśnie za pomoca˛ niniejszego protokołu. Win4Lin Terminal Server uruchamia wówczas na serwerze linuksowym oddzielne sesje programu dla każdego użytkownika, który używa Win4Lin. Sa˛ one przy tym przenoszone do klientów poprzez protokół X. 118 Koszty 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 zmierza do integracji Windowsa z Linuksem na poziomie aplikacji. WINE działa, jeśli chodzi o udost˛epnianie aplikacji windowsowych w Linuksie, na innej zasadzie, jak jest to w przypadku rozwiazań ˛ opisanych powyżej. 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 pami˛eci operacyjnej komputera, łaczy ˛ ja˛ z udost˛epnianymi wraz z WINE bibliotekami i w ten sposób potrafi uruchamiać aplikacje w Linuksie. Mimo, że WINE nie jest emulatorem, postanowiliśmy dokładnie go ocenić. Najwi˛ekszym wyzwaniem jest jak najpełniejsze udost˛epnienie bibliotek windowsowych w postaci wolnych implementacji, co ma na celu umożliwienie pracy w Linuksie jak najwi˛ekszej ilości aplikacji windowsowych. W WINE zaimplementowane zostały już biblioteki windowsowe z najważniejszymi funkcjami, dzi˛eki czemu nie ma problemu, gdy uruchamiana aplikacja odwołuje si˛e tylko ze standardowej funkcjonalności (systemu operacyjnego Windows) i sama wnosi pozostałe funkcje. Sytuacja jest trudniejsza, gdy aplikacja windowsowa korzysta przeważnie z nowych, jeszcze nie zaimplementowanych funkcji bibliotek Windows albo z bibliotek innych aplikacji. W zwiazku ˛ z tym należy wspomnieć także o tym, że producenci oprogramowania z reguły staraja˛ si˛e, aby obsługiwało ona również starsze wersje Windows i dlatego rzadko wprowadzaja˛ nowe Features albo sa˛ one stosowane opcjonalnie, dlatego w praktyce nie musza˛ one koniecznie powodować problemów. W tak zwanym mi˛edzyczasie WINE zaczał ˛ obsługiwać wiele aplikacji (patrz poniższy paragraf „Programy wykonywalne“) oraz Features120. Obsługiwane systemy operacyjne WINE dost˛epny jest praktycznie dla każdego systemu linuksowego i wchodzi w skład wi˛ekszości dystrybucji. Programy wykonywalne Za pomoca˛ WINE można zasadniczo uruchamiać wszystkie aplikacje windowsowe, o ile 119 Strona domowa projektu WINE http://www.winehq.com/ List˛e znaleźć można na stronie http://www.winehq.com/?page=wine_features;winehq= d35c3404fe39283bf96bb1dd54b14c8d 120 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 322 dost˛epne sa˛ wymagane biblioteki. Do programów, o których wiadomo, że moga˛ w taki sposób pracować należa˛ m.in Winword. Excel i PowerPoint z pakietów biurowych Office 97 i Office 2000, jak też Internet Explorer. W poszczególnych przypadkach trzeba wcześniej wykonać praktyczny test funkcjonalności, przy czym wcześniej należy zapoznać si˛e z baza˛ danych aplikacji dost˛epna˛ na stronie http: //appdb.winehq.com/. Ograniczenia Problem w WINE stanowi, wymagajaca ˛ wciaż ˛ dość dużej pracy, konfiguracja programu, która zakłada posiadanie wielu wiadomości. Stopień integracji WINE sprawia, że aplikacje windowsowe sa˛ optymalnie zintegrowane z desktopem linuksowym. Programy nie sa˛ tu uruchamiane z poziomu ich własnego desktopu, lecz bezpośrednio za pomoca˛ menedżera 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łacić trzeba tylko za koszty licencji na używanie poszczególnych aplikacji windowsowych. Jednakże w odróżnieniu od wcześniej omawianych rozwiazań ˛ należy liczyć si˛e z wi˛eksza˛ ilościa˛ pracy administracyjnej. Ocena Rozwiazanie ˛ to ma dwie istotne zalety: ◦ nie trzeba płacić za licencje systemu operacyjnego Windows. ◦ nie trzeba uruchamiać dodatkowego systemu operacyjnego, który dodatkowo obciażałby ˛ dost˛epne zasoby. Teoretycznie aplikacje windowsowe można uruchamiać tak samo szybko, jak w Windows i wymagaja˛ one tej samej ilości pami˛eci. 121 Źródło: http://www.winehq.com/?ss=1 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 324 Zatem, o ile WINE udost˛epnia biblioteki niezb˛edne dla działania danej aplikacji, należy z niego skorzystać w pierwszej kolejności. WINE, jako jedyny, mógłby stworzyć możliwość uruchamiania MS Project na desktopach linuksowym, gdyż obecnie nie ma alternatywnej aplikacji dla Linuksa. W bazie danych aplikacji nie można jednak znaleźć żadnego potwierdzajacego ˛ to wpisu. Crossover Office Crossover Office (CO) jest produktem firmy Code Weavers122. CO opiera si˛e na WINE i kompensuje wad˛e pracochłonnej konfiguracji WINE przez to, że WINE w CO uzupełniony został o wygodny program instalacyjny i skrypty służace ˛ do konfiguracji ustawień użytkownikó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˛ dość stabilnie. Koszty Oprócz kosztów zwiazany ˛ z licencjami MS Office dochodza˛ jeszcze koszty licencji Crosso123 ver Office . Ocena Poza tym obowiazuj ˛ a˛ takie same opinie, jak w przypadku WINE. Tak wi˛ec, ten kto preferuje wi˛eksza˛ wygod˛e podczas instalacji i konfiguracji, powinien skorzystać z CO, a nie z WINE. Crossover Office Server Edition Crossover Office Server Edition umożliwia centralne instalowanie aplikacji windowsowych w serwerze aplikacji opartym na Linuksie i udost˛epnianie ich stamtad ˛ systemom klienckim poprzez protokół X. To z kolei ma t˛e zalet˛e, że aplikacje windowsowe można udost˛epniać centralnie i centralnie nimi administrować. 122 123 Strona domowa Code Weavers http://www.codeweavers.com/home/. Informacja o cenach Crossover Office http://secure.codeweavers.com/store/. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 325 WineX WineX jest odmiana˛ WINE, w przypadku której firma Transgaming 124 skoncentrowała si˛e na poprawieniu obsługi DirectX. Za pomoca˛ WineX można uruchamiać w Linuksie szereg zbytecznych gier windowsowych. Z tego powodu nie b˛edziemy bliżej oceniać WineX i wymieniliśmy go tylko ze wzgl˛edu na ch˛eć pełnego przedstawienia tematu. WineX nie jest Wolnym Oprogramowaniem. 3.15.7.3 Citrix Metaframe Funkcjonalności opisaliśmy w rozdziale 3.16.5. Obsługiwane systemy operacyjne (patrz rozdział 3.16.5) Programy wykonywalne Uruchamiać można wszystkie aplikacje windowsowe, które pracuja˛ w Windows NT albo Windows 2000. Ograniczenia Ograniczenia dotyczace ˛ wykonywania aplikacji windowsowych istnieja˛ tylko aplikacje obciażone ˛ grafika˛ (patrz wyżej), których w miar˛e możliwości nie należy uruchamiać za pomoca˛ Citrix Metaframe. Stopień integracji Tak samo, jak w VMware i Win4Lin, desktop windowsowy otwiera si˛e we własnym oknie na desktopie linuksowym, w którym uruchamiane b˛eda˛ aplikacje windowsowe. Wymiana danych odbywać si˛e może tylko poprzez sieć. Tym samym również tutaj mamy do czynienia z małym stopniem integracji. 124 Strona domowa firmy Transgaming http://www.transgaming.com/. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 326 Koszty Koszty zależa˛ od każdorazowego sposobu wykorzystania żadanego ˛ Metaframe i należy je oceniać osobno w każdym przypadku. Zasadniczo składaja˛ si˛e na nie koszty licencji Citrix oraz łaczne ˛ koszty licencji Microsoft. Ocena Citrix Metaframe nie jest zalecane jako rozwiazanie ˛ udost˛epniajace ˛ aplikacje windowsowe na desktopie do czasu gdy b˛eda˛ one dost˛epne także jako aplikacje linuksowe, ponieważ jest przede wszystkim za drogi i zbyt skomplikowany. Citrix Metaframe należy jednak wziać ˛ pod uwag˛e, gdy przewiduje si˛e istnienie takich aplikacji windowsowych, z których trzeba b˛edzie korzystać długoterminowo. Najwi˛eksza˛ zaleta˛ Citrix Metaframe jest centralna instalacja i zarzadzanie ˛ aplikacjami, jak też centralne przechowywanie danych. Citrix Metaframe sprawdza si˛e dobrze również w środowisku Thin Clients oraz klientów bezdyskowych. 3.15.7.4 Windows Terminal Server Funkcjonalności opisaliśmy w rozdziale 3.16.5. Obsługiwane systemy operacyjne (patrz rozdział 3.16.5) Programy wykonywalne Sa˛ to wszystkie aplikacje windowsowe, które można uruchamiać w Windows 2000. Ograniczenia (patrz rozdział 3.16.5) Stopień integracji ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 327 Taki sam, jak w przypadku Citrix Metaframe. Koszty W przeciwieństwie do Citrix dochodza˛ tu jeszcze koszty licencji Microsoft. Ocena Wariant ten należy ocenić podobnie jak rozwiazanie ˛ Citrix Metaframe, przy czym jest on nieco korzystniejszy. Jednak wada˛ w porównaniu z Citrix Metaframe jest to, że w przypadku Windows Terminal Servers nie zebrano jeszcze tak szerokich doświadczeń, jak z Citrix Metaframe, zwłaszcza w dużych i skomplikowanych środowiskach. Jednakże podczas poszukiwań rozwiazania ˛ samego problemu ma to niewielkie znaczenie. Podsumowanie VMware, Win4Lin, WINE oraz Crossover Office moga˛ być traktowane tylko jak rozwiaza˛ nia przejściowe albo rozwiazanie ˛ dla pojedynczych, małych aplikacji pracujacych ˛ na poszczególnych stacjach roboczych. W nieodległym czasie musi powstać odpowiednia, niezależna od platformy aplikacja uruchamiana pod Linuksem. W przeciwnym razie można sprawdzić czy Citrix Metaframe może być rozwiazaniem ˛ przemysłowym, przy czym b˛edzie to z pewnościa˛ raczej strategiczna decyzja. Zważywszy na powyższe warunki możliwe jest sformułowanie nast˛epujacych ˛ ocen: ◦ W przypadku przewidywalnej ilości aplikacji windowsowych opłaca si˛e zastosować WINE (w razie potrzeby trzeba ewentualnie dodatkowo, twórczo popracować). ◦ Jeśli istnieje wiele danych aplikacji windowsowych, wówczas istnieje duże prawdopodobieństwo, że nie wszystkie aplikacje b˛edzie można uruchomić za pomoca˛ WINE. Dlatego należy sprawdzić, czy możliwe jest wykorzystanie Win4Lin (czy aplikacje działaja˛ z Windows 95, 98 albo ME). ◦ Jeśli ilość danych aplikacji windowsowych jest bardzo duża, wówczas pojawia si˛e podstawowe pytanie o sens migracji (granic˛e należy sprawdzić w konkretnym przypadku). ◦ W przyszłości trzeba wesprzeć powstanie aplikacji niezależnych od platformy. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 328 3.15.8 Ocena W oparciu o wcześniejsze spostrzeżenia, oceniliśmy poniżej zastapienie ˛ Office 97 badź ˛ Office 2000 przez Office XP lub Office 2003 albo przez OOo / SO. Wyniki niniejszych ocen tworza˛ podstaw˛e dla oceny możliwości zastapienia ˛ desktopu firmy Microsoft desktopem linuksowym. 3.15.8.1 Zastapienie ˛ Office 97/2000 Migracja do Office XP Nad zasadnościa˛ migracji z Office 97 badź ˛ 2000 do Office XP należy si˛e zastanowić z nast˛epujacego ˛ powodu. Migracja wymaga zawsze czasu i nakładów, dlatego odbywa si˛e ona w kierunku najnowszej oraz najnowocześniejszej techniki, a nie w kierunku wciaż ˛ dost˛epnej, starszej techniki. W przypadku Office XP można przewidywać, że zostanie on zastapiony ˛ jeszcze w roku 2003 przez Office 2003, który wniesie nowsza˛ i bardziej innowacyjna˛ technik˛e. Jeśli zgodnie z zapowiedziami, Office 2003 zostanie udost˛epniony w pełnej wersji latem 2003, wówczas można założyć, że do poczatku ˛ 2004 r. dost˛epna b˛edzie wersja wzgl˛ednie stabilna i nie zawierajaca ˛ bł˛edów. Migracja do Office 2003 Przeciwko migracji do Office 2003 przemawia, z technicznego punktu widzenia tylko to, że obecnie nie ma jeszcze doświadczeń z zastosowań produkcyjnych pakietu Office 2003. Na podstawie silnego dażenia ˛ w Office 2003 do XML oraz dotychczasowych doświadczeń z wersja˛ Beta 2 można oczekiwać, że wraz z wprowadzeniem Office 2003 łatwiejsza stanie si˛e wymiana dokumentów niezależna od platformy. Samo to jest wystarczajacym ˛ powodem, aby poczekać z migracja˛ do momentu, gdy Office 2003 ukaże si˛e jako wzgl˛ednie stabilna i bezbł˛edna wersja oraz aż dost˛epne b˛eda˛ wyniki z codziennego wykorzystywania tego pakietu biurowego, także jeśli chodzi o ponadplatformowa˛ wymian˛e dokumentów. Migracja do OOo / SO Migracj˛e do OOo / SO można, z dzisiejszego punktu widzenia, zalecić tylko wówczas, gdy dokumenty powstajace ˛ w urz˛edzie lub organizacji ◦ nigdy lub rzadko sa˛ wspólnie edytowane z innymi urz˛edami i organizacjami korzystaja˛ cymi z MS Office (do wersji XP) albo ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 329 ◦ sa˛ proste, tzn. sa˛ to dokumenty bez makr oraz bez szczególnych formatowań i jako takie sa˛ wspólnie edytowane przez inne urz˛edy i organizacje korzystajace ˛ z MS Office (do wersji XP). Jeśli wraz z innymi urz˛edami i organizacjami cz˛esto tworzone sa˛ skomplikowane dokumenty i w organizacjach tych stosowany jest Office 97, 2000 albo XP, wówczas należy spodziewać si˛e, że współpraca b˛edzie zbyt skomplikowana i pracochłonna. Migracja do OOo / SO nie jest zalecana z technicznego punktu widzenia również wówczas, gdy nie ma możliwości zintegrowania z OOo / SO bezwzgl˛ednie koniecznych, zewn˛etrznych aplikacji, które sa˛ silnie zintegrowane z MS Office. Ponieważ obecnie nadal nie ma dostatecznych informacji na temat wymiany dokumentów pomi˛edzy MS Office 2003 a OOo / SO, w przyszłości w wersjach 1.1 i 6.1, wi˛ec na razie nie możemy si˛e na ten temat wypowiedzieć. 3.16 Terminal-Server i Thin Clients 3.16.1 Przeglad ˛ W projekcie migracyjnym może znaleźć si˛e decyzja o zastosowaniu Terminal - Servers i Thin Clients. Dlatego ich opis stał si˛e cz˛eścia˛ składowa˛ niniejszego poradnika. Jednak nie jest to klasyczny temat migracyjny, ponieważ z reguły nie wykonuje si˛e migracji środowisk Terminal Server. Zastosowanie techniki opisanej poniżej jest w pierwszym rz˛edzie decyzja˛ wewnatrz ˛ ogólnej strategii informatycznej każdego urz˛edu. Przedstawione rozwiazania ˛ powinny jednak umożliwić wglad ˛ w całe zagadnienie i wyjaśnić potencjał opisywanej technologii. Prezentujemy technologie, z których można korzystać w najróżniejszych urz˛edach: ◦ 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 rz˛edzie z windowsowymi systemami klienckimi ◦ Metaframe firmy Citrix z różnymi systemami klienckimi (DOS, Windows, Unix, Linux, itd.). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 330 Przedstawione systemy oferuja˛ cała˛ gam˛e różnych technicznych rozwiazań ˛ (systemy serwerowe i klienckie) i należy je dokładnie ocenić w każdym pojedynczym przypadku. Oprócz różnic i możliwości technicznych, systemy te różnia˛ si˛e znacznie, także jeśli chodzi o modele licencji i koszty. 3.16.2 Wprowadzenie Administrowanie i opieka nad komputerami pełniacymi ˛ funkcje stacji roboczych jest zadaniem wymagajacym ˛ dużych nakładów osobowych, zwłaszcza wtedy, gdy komputery wyposażone zostały w różny osprz˛et i oprogramowanie. Również rosnacy ˛ stopień skomplikowania stosowanego osprz˛etu i oprogramowania może powodować wi˛eksza˛ awaryjność stacji roboczych i tym samym wymagać pracy administracyjnej. Prace zwiazane ˛ z opieka˛ nad systemem zostały wyszczególnione poniżej: ◦ instalacja – ewentualna konfiguracja 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 cz˛eści zamiennych W sumie zadania można zautomatyzować za pomoca˛ odpowiednich narz˛edzi administracyjnych badź ˛ aplikacji przeznaczonych do zarzadzania ˛ systemem. Automatyzacja taka może zmniejszyć konieczna˛ ilość pracy, jednak nakłady pracy z reguły nadal b˛eda˛ bardzo wysokie. Ponadto nie każda organizacja jest w stanie sfinansować kupno po cz˛eści bardzo drogiego oprogramowania do zarzadzania ˛ systemem, zwłaszcza gdy jest to mniejsza organizacja. Stosowanie Terminal - Servers może znacznie zmniejszyć nakreślone problemy. Także w ramach kolejnych projektów migracyjnych należałoby zastanowić si˛e nad przyszłym wykorzystaniem Terminal - Servers i odpowiednich Thin Clients. W tradycyjnym zdecentralizowanym środowisku IT, instalacja i uruchamianie programów nast˛epuje najcz˛eściej na komputerach pełniacych ˛ rol˛e stacji roboczych. Struktura serwerów służy przede wszystkim do centralnego zarzadzania ˛ danymi, zabezpieczania danych i sterowania prawami dost˛epu. W przypadku zastosowania rozwiazania ˛ Terminal - Server, wydajny komputer badź ˛ komputery centralne, tj. właściwe ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 331 Terminal - Server, zapewniaja˛ dost˛ep z każdego miejsca do potrzebnych danych i aplikacji. Terminal - Servers oferuja˛ użytkownikom bezpośredni dost˛ep do graficznego interfejsu użytkownika systemu operacyjnego poprzez sieć. Każdy użytkownik zalogowany do Terminal - Server otrzymuje własna˛ sesj˛e (Session) oraz prawo do korzystania ze wszystkich udost˛epnianych zasobów systemu operacyjnego. W przeciwieństwie do tradycyjnych zdecentralizowanych architektur stacji roboczych, nie jest to dost˛ep tylko do danych, lecz także do aplikacji z centralnego serwera. Dost˛ep do aplikacji i danych mieszczacych ˛ si˛e w Terminal - Server musi sie odbywać za pośrednictwem specjalnych programów terminalowych badź ˛ tak zwanych Thin Clients. Poniższa tabela przedstawia zalety stosowania Terminal - Servers oraz Thin Clients. Z ALETY O BJA ŚNIENIA System operacyjny i aplikacje przechowywane sa˛ w Terminal Servers centralnie tylko w prostej formie. ◦ Opiek˛e nad oprogramowaniem można teraz sprawować centralnie (łaty, aktualizacje). ◦ Nie sa˛ już wymagane żadne prace w systemach klienckich. ◦ Opieka nad aplikacjami odbywa si˛e centralnie, łatwiejsze centralne wanie administro- staje si˛e diagnozowanie i usuwanie bł˛edów. ◦ Zwi˛eksza si˛e wydajność użytkownika i administrowania. – dzi˛eki uproszczeniu administrowania możliwe staje si˛e szybsze udost˛epnianie aplikacji użytkownikom. – dzi˛eki temu, że nie trzeba już usuwać bł˛edów na miejscu, znacznie zmniejszaja˛ si˛e nakłady administracyjne. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 332 ◦ Systemy klienckie wymagaja˛ małych zasobów sprz˛etowych (karta sieciowa, karta graficzna, klawiatura, mysz). zmniejszone wymagania sprz˛etowe ◦ Regularna rozbudowa osprz˛etu klienta zwiazana ˛ z rosna˛ cymi wymaganiami systemów operacyjnych i aplikacji, nie jest już potrzebna. ◦ Istniejacy ˛ osprz˛et może być dłużej wykorzystywany. Wskutek stosowania Thin Clients (bez dysków twardych) dane moga˛ być zapisywane tylko w centralnych serwerach [dotyczy zwi˛ekszone czeństwo bezpie- to również Fat Clients]. W ten sposób w systemach klienckich zmniejsza si˛e niebezpieczeństwo utraty danych badź ˛ manipulacji danymi przez nieupoważnione osoby, wzgl˛ednie ich kradzieży, gdyż osoby te nie maja˛ do nich dost˛epu. Komputery pełniace ˛ rol˛e stacji roboczych można szybko wymie- niezależność od klienta nić, ponieważ w klientach nie sa˛ już zapisywane dane osobowe, czy też ustawienia. Jednak przede wszystkim użytkownicy maja˛ możliwość dowolnego zmieniania miejsca pracy, bez rezygnowania ze „swojego“ zaufanego środowiska. Tablica 3.71: Zalety Terminal - Servers i Thin Clients Oprócz opisanych powyżej zalet należy jednak także wymienić kilka wad, które należy wziać ˛ pod uwag˛e podczas podejmowania decyzji za badź ˛ przeciw zastosowaniu Terminal - Servers. WADY O BJA ŚNIENIE ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 333 W przypadku awarii Terminal - Server przerywane sa˛ sesje użytkowników i nie jest możliwe ponowne podj˛ecie pracy przed usuni˛eciem bł˛edu po stronie serwera. Można to zminimalizować sto- uzależnienie sujac ˛ Serverfarm. W przypadku przerwania sesji użytkowników może dojść do utraty danych. Terminal - Servers musza˛ dysponować wyraźnie wi˛ekszymi zasobami, zwłaszcza jeśli chodzi o pami˛eć. Jednak w odniesieniu do zwi˛ekszone wymagania wzgl˛edem zasobów ogólnego zapotrzebowania (serwery i klienty) wielkość wymaganych zasobów jest mniejsza, ponieważ określone operacje wykonywane sa˛ przez serwer tylko raz dla wszystkich użytkowników a nie na każdym jednym kliencie. Systemy serwerowe i klienckie komunikuja˛ si˛e ze soba˛ na poziomie sieci, transmitowane sa˛ różnice treści podczas tworzenia obrazu albo instrukcje dla tworzenia obrazu. Określone aplika- zwi˛ekszony ruch w cje (programy graficzne, itd.) moga˛ bardzo zwi˛ekszyć obciaże˛ nie sieci. W przypadku innych aplikacji (np. edytorów tekstu) sieci ruch sieciowy może si˛e jednak także zmniejszyć, ponieważ 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, pracować, zwłaszcza jeśli chodzi o aplikacje windowsowe, moga˛ dostosowywanie wykorzystywanych aplikacji istnieć takie, które podczas pracy otwieraja˛ pliki systemowe do zapisu i tym samym sa˛ one zablokowane dla innych użytkowników. Problemy te można cz˛esto rozwiazać ˛ dzi˛eki pracy administracyjnej. Tablica 3.73: Wybrane wady Terminal - Servers i Thin Clients Połaczenie ˛ z Terminal - Servers można realizować za pomoca˛ różnych typów klientów. Klienty Fat Chodzi tu o pełnowartościowa˛ stacj˛e robocza.˛ Dost˛ep do Terminal - Server odbywa si˛e 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łożone z minimalnego wyposażenia. Klienci pobieraja˛ system operacyjny badź ˛ to z Flash - EPROM badź ˛ bootuja˛ si˛e poprzez sieć (pxe, tftp, nfs) (patrz rys. 3.46). ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI Rysunek 3.45: Uruchamianie aplikacji X i aplikacji windowsowych w Thin Client 335 ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 336 Rysunek 3.46: Bootowanie systemu linuksowego poprzez sieć Poniżej przedstawiliśmy pokrótce kilka wybranych rozwiazań ˛ dla środowisk terminalowych. 3.16.3 Linux-Terminal-Server-Project Linux Terminal Server Project (LTSP)125 umożliwia bootowanie systemów klienckich do systemów serwerowych dzi˛eki wykorzystaniu wspaniałych możliwości dostarczanych przez linuksowy system X - Window. Wymagane aplikacje sa˛ ostatecznie uruchamiane po stronie serwera. Obraz z aplikacji pracujacych ˛ na serwerze przekazywany jest do terminali poprzez protokół X. Konfiguracja systemu klienckiego realizowana jest za pomoca˛ prostego pliku tekstowego i oferuje cały szereg możliwości, poczawszy ˛ od korzystania z lokalnych drukarek a skończywszy na lokalnym uruchamianiu programów. Dzi˛eki projektowi LTS można korzystać z tanich stacji roboczych, jako terminali serwera linuksowego badź ˛ uniksowego. Klienci moga˛ pracować zarówno w trybie tekstowym, jak i graficznym. Bootowanie systemów klienckich inicjowane jest przez serwer i odbywa si˛e poprzez sieć. W tym celu we wszystkich systemach klienckich należy zastosować specjalne Boot - ROMS, które można umieścić w obecnych adapterach sieciowych. Zarzadzanie ˛ danymi użytkowników, wzgl˛ednie danymi kont odbywa si˛e za pomoca˛ tradycyjnych narz˛edzi dostarczanych wraz z GNU / Linux. Poniżej przedstawiliśmy 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 udost˛epniła jego cz˛eści składowe jako Wolne Oprogramowanie. Najważniejsza˛ różnica˛ w porównaniu z LTSP jest uproszczone zarzadzanie ˛ oparte na LDAP. Cała konfiguracja i profile użytkowników składowane sa˛ centralnie, po stronie serwera, dzi˛eki zastosowaniu usługi katalogowej LDAP (Lightweight Directory Access Protocol). W zwiazku ˛ z tym istnieje gwarancja, że każdy użytkownik ma dost˛ep do swojego, specjalnego profilu, aplikacji i danych z każdej stacji roboczej. Administrowanie może odbywać si˛e poprzez Frontend 125 126 http://www.ltsp.org/ http://www.gonicus.de/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 337 WWW o nazwie Gosa. Frontend ten umożliwia dost˛ep do wymaganych struktur LDAP i zarza˛ dzanie nimi. Obydwa rozwiazania ˛ udost˛epniane sa˛ na licencji GPL. GOto umożliwia także pełne bootowanie systemów Thin Client poprzez sieć, z odpowiednich serwerów. Proces bootowania rozszerzony został o standardowy protokół PXE, ponieważ odpowiednie opcje bootowania sa˛ obecnie obsługiwane przez coraz wi˛eksza˛ ilość kart sieciowych, wskutek czego w wielu przypadkach nie jest już wymagane stosowanie Boot - ROM. Oprócz Thin Clients obsługiwane sa˛ także Fat Clients. Zarzadzanie ˛ Fat Clients może odbywać si˛e w taki sam sposób, jak zarzadzanie ˛ Thin Clients. Po pierwszym zainstalowaniu Fat Clients można je automatycznie uaktualniać. 3.16.3.2 Desktop-Server Univention_desktop Server127 jest komercyjnym, zintegrowanym i skalowalnym, opartym na Linuksie rozwiazaniem ˛ serwerowym z modułem obsługujacym ˛ Thin Clients oraz z rozszerzona˛ wersja˛ usługi katalogowej OpenLDAP jako Backendem służacym ˛ do zarzadzania ˛ konfiguracja˛ i użytkownikami. Jeśli chodzi o różnic˛e wzgl˛edem LTSP, to jest ona taka sama, jak w przypadku rozwiaza˛ nia GOto i polega na tym, że uruchamianie systemów jest realizowane nie tylko poprzez BOOTP, lecz także poprzez PXE. Oprócz tego udost˛epniane sa˛ specjalne narz˛edzia do kontroli sesji użytkowników, dzi˛eki czemu podczas wyłaczania ˛ klientów nie powstaja˛ „martwe procesy“. Dodatkowo możliwy jest dost˛ep do lokalnych urzadzeń ˛ podłaczonych ˛ do Thin Client, takich jak CDROM, Floppy, karta dźwi˛ekowa czy drukarka (administrator może jednak ograniczyć ten dost˛ep). Wspólne zarzadzanie ˛ konfiguracja˛ i użytkownikami znajduje si˛e w katalogu LDAP. Ponadto administrowanie wpisuje si˛e w administrowanie windowsowymi i linuksowymi Fat Clients. Dzi˛eki zintegrowanemu Load - Balancing uzyskiwana jest dobra skalowalność a w razie potrzeby można w prosty sposób zintegrować z systemem dodatkowe serwery bootowania i aplikacji. 3.16.4 Usługi terminalowe NX Produkt NX firmy Nomachine128 z Włoch jest dość nowa˛ technologia˛ serwerów terminalowych oparta˛ na Linuksie. Jest to produkt komercyjny. Po wieloletnim okresie rozwoju oprogramowania, developerom udało si˛e zaimplementować bardzo wydajny kompresor dla protokołu X 127 128 http://www.univention.de/ http://www.nomachine.com/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 338 Window. Jak wiadomo system X - Window zaprojektowany został tak, że jest on przezroczysty dla sieci. Oznacza to, że wyświetlanie każdej aplikacji może odbywać si˛e na odległym ekranie. Niestety używany protokół nie jest szerokopasmowy. Dlatego dotychczas stosowanie protokołu X - Window miało sens tylko w LAN. Wprawdzie było już kilka prób, poprawienia jego przydatności dla WAN za pomoca˛ Caching Events i Bitmaps badź ˛ poprzez kompresj˛e samego protokołu (Low band X), jednak uzyskane wyniki okazały si˛e być niewystarczajace. ˛ Technologia NX uzyskała, w tzw. mi˛edzyczasie, współczynnik kompresji, który jest porównywalny ze współczynnikiem z Citrix. NX - Server pracuje na jednym albo wielu serwerach linuksowych i może, oprócz protokołu X - Window, wydajnie transmitować do NX - Client także Microsoft RDP i protokół Frame - Buffer przegladarki ˛ VNC. NX - Client może pracować w Linuksie, Windows, w PDAs iPAC i Zaurus. Oprócz wydajnej transmisji treści ekranu, technologia NX umożliwia także dost˛ep do lokalnego sytemu plików i przekaz danych audio. Nie jest jeszcze możliwe przekierowanie interfejsu szeregowego. Jeśli chodzi o technologi˛e, sytem ten opiera si˛e w znacznym stopniu na składnikach Open Source. Wszystkie składniki umożliwiajace ˛ kompresj˛e sa˛ udost˛epniane na licencji GPL. Cała komunikacja jest szyfrowana za pomoca˛ tunelu SSH. Podobnie, jak w przypadku Citrix Metaframe możliwe jest „publikowanie“ tylko okna pojedynczej aplikacji. Dzi˛eki temu można bardzo elastycznie integrować świat aplikacji windowsowych i linuksowych. Umożliwia to przekazywanie windowsowych aplikacji na desktop Linuksa albo linuksowych aplikacji na desktop Windowsa. Przez oddzielenie serwera aplikacji i w˛ezłów kompresji uzyskiwana jest zewn˛etrzna skalowalność. Server aplikacji nie jest przy tym dodatkowo obciażany ˛ przez kompresj˛e danych. Nie dochodzi do konfliktów pomi˛edzy wersjami aplikacji i serwerem kompresji. Interesujacy ˛ jest model licencji, ponieważ nie zależy ona od ilości klientów, lecz od ilości w˛ezłów serwera. Dzi˛eki temu cena produktu jest znacznie korzystniejsza od cen innych produktów dost˛epnych na rynku. 3.16.5 Windows Terminal Services i Citrix Cała logika aplikacji udost˛epniana jest centralnie, z serwera, przez co wymagana szerokość pasma pomi˛edzy klientem a serwerem wynosi około 10 do 20 kB/s. Dzi˛eki oddzieleniu logiki aplikacji od interfejsu użytkownika na Terminal - Servers, podczas odwoływania si˛e do serwera plików, serwera wydruku, serwera bazy danych, etc., Backbone jest silniej obciażony ˛ w porównaniu z klasycznymi środowiskami Client - Server. Główna˛ cz˛eścia˛ składowa˛ technologii Terminal - Server sa˛ serwery, w których zainstalowane sa˛ aplikacje. Terminal - Server umożliwia równoległy dost˛ep wielu użytkowników w czasie se- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 339 sji (Sessions), podczas których użytkownicy moga˛ uruchamiać aplikacje w chronionym obszarze pami˛eci. Ponieważ nieskonfigurowani użytkownicy posiadaja˛ wszystkie uprawnienia, należy chronić system przed niezamierzonymi badź ˛ nieuprawnionymi akcjami ze strony użytkowników. W tym celu można skorzystać ze środków znanych z administrowania w NT, takich jak profile oparte na serwerze, stosowanie Policies i ustawień NTFS - Security wzgl˛edem plików i katalogów, które gwarantuja˛ wymagane bezpieczeństwo. Ponadto w środowisku Terminal - Server szczególna˛ rol˛e przypisać można testom aplikacji, które maja˛ umożliwić przeprowadzenie Server - Sizing. Dlatego nieodzowna jest wiedza o tym, ◦ jaka jest wydajność procesora oraz ◦ ile pami˛eci operacyjnej wymaga aplikacja, ◦ ilu użytkowników korzysta jednocześnie z danego programu, ◦ czy program jest 16 bitowa˛ aplikacja˛ DOS, ◦ czy aplikacja w ogóle może pracować 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 mieści si˛e w każdym jego wariancie. O ile nie używa si˛e Metaframe firmy Citrix, komunikacja pomi˛edzy Terminal Server a Terminal 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 (także 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 Microsoft jest fakt, że użytkownik chce si˛e połaczyć ˛ z określonym serwerem. Powoduje to komplikacje, gdy: ◦ serwer nie jest dost˛epny albo ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 340 ◦ serwer jest przeciażony ˛ Zaradzić temu można stosujac ˛ produkt Metaframe firmy Citrix. Za pomoca˛ Metaframe można łaczyć ˛ logicznie wiele Termina Servers w Serverfarm. Użytkownik (klient) nie widzi wówczas pojedynczego serwera, lecz tak zwane rozgłoszone aplikacje, z którymi si˛e łaczy. ˛ O tym, na którym serwerze uruchamia on potem swoje aplikacje, decyduje mechanizm mieszczacy ˛ si˛e w farmie serwerów. W tym miejscu należy wyraźnie stwierdzić, że mimo wszystkich omówionych przykładów powyższa ocena nie oddaje całej złożoności rozwiazania ˛ Citrix, ani jego możliwości. Nakreśliliśmy zaledwie podstawowa˛ zasad˛e działania tej technologii. Jednak w tym miejscu jest to całkowicie wystarczajace, ˛ aby wskazać możliwość uruchamiania aplikacji windowsowych na desktopie Linuksa za pomoca˛ Citrix Metaframe. Aby zagwarantować t˛e funkcjonalność, Mainframe zawiera tak zwany protokół ICA (Independent Computer Architecture). Wymagany klient ICA istnieje dla ◦ wszystkich systemów operacyjnych Windows ◦ DOS ◦ Java ◦ wielu odmian Uniksa (także dla Linuksa) oraz ◦ systemów Handheld Po stronie serwera, w pierwszym rz˛edzie obsługiwane sa˛ w/w systemy operacyjne firmy Microsoft (Windows NT 4 TSE i Windows 2000). Istnieja˛ jednak także rozwiazania ˛ dla Uniksa (np. Metaframe dla Solaris). Obecnie Metaframe dostarczane jest przez firm˛e Citrix w dwóch odmianach: ◦ Metaframe 1.8 oraz ◦ Metaframe XP. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 341 Wersj˛e XP należy traktować jako wariant strategiczny, ponieważ wersja 1.8 w najbliższej przyszłości przestanie być wspierana. Metaframe można spotkać w dużych środowiskach z duża˛ ilościa˛ serwerów, gdyż środowiska te wymagaja˛ inteligentnego „Load Management“ (przydzielanie obciażenia). ˛ Jeśli z wielu Terminal Servers stworzona zostanie tak zwana farma serwerów, wówczas możliwe jest przydzielanie obciażenia ˛ poszczególnym serwerom. Nast˛epujacy ˛ rysunek pokazuje schemat farmy serwerów pracujacej ˛ pod kontrola˛ Metaframe XP. Rysunek 3.47: Serverfarm pod kontrola˛ Metaframe XP Przydzielanie obciażenia ˛ przyczynia si˛e do zapewnienia wydajności i dost˛epności aplikacji w całym systemie, ponieważ użytkownicy nie sa˛ kierowani do serwera, na którym nastapiła ˛ awaria. Jeśli serwery współpracuja˛ z programem oceniajacym ˛ obciażenie, ˛ wówczas w Metaframe XP nast˛epuje przekazanie wyniku z danego serwera do punktu gromadzenia danych (Data Collector) i zapami˛etany dla nadchodzacych ˛ zapytań. Jeśli udost˛epniana aplikacja wywoływana jest poprzez klienta ICA, wówczas punkt gromadzenia danych wyszukuje i określa serwer, który w momencie nadejścia zapytania posiada najwi˛eksza˛ wydajność i komunikuje to klientowi. Nast˛epnie klient łaczy ˛ si˛e z tym serwerem. W przypadku farm serwerów, które na przykład składaja˛ si˛e z maszyn jedno badź ˛ dwupro- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 342 cesorowych, dla odpowiednich serwerów można różnie określać zasady przydzielania. Gdy zasada określajaca ˛ obciażenie ˛ dla aplikacji udost˛epnianej przez maszyn˛e dwuprocesorowa˛ ustala jej pełne obciażenie ˛ w przypadku 50 użytkowników, oznacza to, że maszyna jednoprocesorowa osiagnie ˛ pełne obciażenie ˛ już przy 25 zalogowanych użytkownikach. Dzi˛eki takiemu „Tuning“ można wyrównywać różnice w osprz˛ecie. Jeśli chodzi o technologi˛e Terminal Server, celowe jest wcześniejsze zwrócenie uwagi na nast˛epujace ˛ aspekty techniczne: ◦ farmy serwerów wymagaja˛ domeny Windows (logowanie) ◦ farmy serwerów pracuja˛ z chronionymi przez serwer profilami, co ma na celu umożliwienie obsługi mobilnych użytkowników (stabilne File Services) ◦ Windows Terminal Server drukuja˛ poprzez RPC do windowsowych serwerów wydruku, co ma na celu odciażenie ˛ Terminal Server ◦ konto użytkownika w domenie Windows uzupełniane jest o dodatkowe, specyficzne parametry Terminal Server. ◦ nie każda aplikacja windowsowa umie pracować w Terminal Servers (należy to sprawdzić, nakład zwiazany ˛ z integracja). ˛ 3.17 High-availability – systemy wysokiej niezawodności Aby móc przedstawić możliwości spełnienia przez Open Source Software wymagań wzgl˛edem wysokiej niezawodności, należy najpierw scharakteryzować zakres zadań. 3.17.1 Cele Wysoko niezawodne instalacje udost˛epniaja˛ usługi w taki sposób, że w czasie ich awarii parametry takie jak minimalna pojemność, przepustowość i inne nie moga˛ zejść poniżej określonych granic. Jest to wymagane z wielu powodów: ◦ usługi sa˛ niezb˛edne wewnatrz, ˛ np. gdy sa˛ one podstawa˛ dla działań wielu użytkowników a ich awaria doprowadziłaby do powstania szkód finansowych. ◦ usługi sa˛ ważne ze wzgl˛edów bezpieczeństwa a ich awaria mogłaby zagrażać interesom narodowym ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 343 ◦ usługi musza˛ być udost˛epniane obywatelom albo firmom bezawaryjnie albo w sposób cia˛ gły. Wraz z przyj˛eciem inicjatywy e-Government, Republika Federalna Niemiec postawiła przed soba˛ wyzwanie stworzenia nowoczesnego, wydajnego państwa. Oznacza to z jednej strony, że stale ma miejsce komunikacja z systemami BackEnd (np. bazami danych) albo że stale moga˛ napływać nowe wnioski, które nie moga˛ zginać. ˛ Z drugiej strony zwiazane ˛ z tym dłuższe czasy dost˛epności usług oznaczaja˛ także nowe wyzwania wzgl˛edem systemów Frontend. Nie tylko maja˛ zmniejszyć si˛e koszty i czas obsługi, lecz także wizerunek administracji publicznej może ulec znacznej poprawie dzi˛eki takim inicjatywom. Jednak niedost˛epność danych usług spowodowałaby efekt przeciwny do zakładanego. 3.17.2 „Pi˛eć dziewiatek” ˛ a rzeczywistość Systemy wysokiej niezawodności (systemy HA, patrz angielskie wyrażenie high availability) można podzielić na kategorie, m.in. według procentowego czasu, w którym udost˛epniaja˛ one usługi. Co to oznacza dla systemu HA, który ma być udost˛epniany przez cała˛ dob˛e, pokazaliśmy w nast˛epujacej ˛ tabeli: Maksymalna awaryjność w Maksymalna awaryjność w 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 Dost˛epność 99,999% 5 minut Tablica 3.75: Wymagania wzgl˛edem systemu HA Powyższe, cz˛esto cytowane liczby nie sa˛ jednak realistyczne. Wi˛ekszość umów serwisowych (SLAs, service level agreements) zawiera zdefiniowane czasy konserwacji określajace, ˛ jak długo dana usługa b˛edzie niedost˛epna. Jednak czas ten nie jest traktowany jako awaria, co znaczy, że w wi˛ekszości przypadków wysoka dost˛epność określana jest w oparciu o niezaplanowane awarie. Jako przykład może posłużyć wymaganie stawiane bazie danych SAP, że powinna być ona ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 344 dost˛epna w godzinach urz˛edowania biura, tj. od 7.00 do 19.00. Dzi˛eki możliwości pracy nad systemem poza wspomnianymi godzinami, możliwe jest znacznie łatwiejsze i tańsze spełnienie wymagań, niż w nierealnym przypadku określajacym ˛ 5 minutowy czas awarii w ciagu ˛ roku przy pracy 24 x 365. 3.17.3 Sposób podejścia do problemu Wysoka˛ niezawodność uzyskuje si˛e chroniac ˛ zasoby przed nadmiarem informacji i kontrolujac ˛ ich funkcjonalność. W przypadku nieprawidłowego zachowania jednego ze składników, inny składnik automatycznie przejmuje świadczenie usługi. W tym momencie dochodzi jednak do naruszenia redundancji albo nawet jej zaniku, dlatego bezzwłocznie należy przystapić ˛ do prac naprawczych. Systemy HA wymagaja˛ bardzo dużego wsparcia administracyjnego i same z siebie nie b˛eda˛ pracować. Ważna˛ miara˛ jakości 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 może wystapić ˛ na każdym poziomie. P OZIOM ABSTRAKCJI środowisko użytkownika badź ˛ 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 sprz˛etowa w przypadku dysków jest już dziś standardem (mirroring, RAID1; RAID5 obecnie już si˛e prawie nie spotyka) i jest dost˛epna dla wszystkich platform. W przypadku innych składników sprawa jest już trudniejsza. Redundantnie skonfigurowane karty sieciowe sa˛ rzadko obsługiwane. W centrum naszych rozważań znajduje si˛e obsługa redundancji sprz˛etowej przez system operacyjny. Własnościowe systemy Unix i oczywiście także Mainframes wykazuja˛ tu znaczne zalety, którym według oceny autorów poradnika systemy Open Source nie b˛eda˛ w stanie sprostać w najbliższym czasie. ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 345 Redundancja na poziomie systemu operacyjnego realizowana jest poprzez kontrol˛e zasobów i ich składowania na innym komputerze w przypadku awarii (failover). Niektóre składniki Middleware (np. bazy danych albo monitory transakcji) udost˛epniaja˛ możliwość traktowania wielu systemów jako jeden system. Niektóre aplikacje tego nie potrzebuja,˛ ponieważ sa˛ przydzielane przez serwer do wielu komputerów, na których pracuja˛ i awaria jednego z nich nie powoduje problemów. Jeśli wysoka niezawodność ma być dost˛epna na jednym poziomie abstrakcji, wówczas teoretycznie jest ona wystarczajaca ˛ dla wszystkich niższych poziomów abstrakcji. W praktyce siła systemu HA i wynikajaca ˛ z niej niezawodność rośnie, gdy środki zwiazane ˛ z redundancja˛ zastosowane zostana˛ na możliwie wielu poziomach – ostatecznie bł˛edy moga˛ powstawać także w podsystemie HA, co oznacza, że musi istnieć możliwość zastapienia ˛ go innym redundantnym składnikiem. W końcu nie wolno zapomnieć o najwi˛ekszym źródle bł˛edów, którym jest człowiek, tutaj w roli administratora systemu albo programisty. System cz˛esto przejmuje bł˛edy w administrowaniu lub programowaniu. Nast˛epstwem tego jest obarczenie bł˛edem świadczonych, redundantnych usług albo składników. Jeśli, np. wskutek bł˛edu administracyjnego, usuni˛etych zostanie kilkaset GB, wówczas nie pomoże mirroring ani redundancja usług. Dane zostana˛ usuni˛ete ze wszystkich składników. Dlatego dobry Backup i Restore, a w pewnych okolicznościach także Disaster Recovery w ramach planowania Business Continuity, sa˛ elementarnymi cz˛eściami składowymi rozwiazania ˛ HA. 3.17.4 Kategorie systemów HA O ile redundancja zawsze jest podstawowa˛ zasada˛ wysokiej niezawodności, istnieja˛ różne 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 uruchomić. Jeśli to si˛e nie uda, wówczas nast˛epuje transfer usługi do innej maszyny, na której jest ona uruchamiana. ◦ Application Clustering Nieliczne aplikacje, dzi˛eki przystosowaniu do pracy w klastrach, sa˛ w stanie pracować na wielu maszynach w taki sposób, że wygladaj ˛ a˛ one z zewnatrz ˛ jak jeden system, w którym w razie awarii pojedynczych maszyn jest ona przezroczyście 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 post˛epowania stał si˛e popularny zwłaszcza w przypadku serwerów WWW. „Load Balancer“ przydziela nadchodzace ˛ Requests wielu maszynom. Metod˛e t˛e można przede wszystkim stosować w przypadku usług bez stanu. Cz˛esto używana jest ona do realizacji FrontEndu, podczas gdy BackEnds pracuja˛ na urzadzeniu ˛ Failover. ◦ Jeśli chodzi o bazy danych, do Disaster Recovery cz˛esto stosuje si˛e także Redo - Log - Shipping. Tworzone sa˛ przy tym Redo - Logs wszystkich transakcji, które nast˛epnie przesyłane sa˛ do komputera tworzacego ˛ Backup, w którym przetwarzanie ich prowadzi również do uaktualnienia stanu bazy danych. Dzi˛eki powyższemu podziałowi na kategorie można ustalić, jakie rozwiazania ˛ wysokiej niezawodności istnieja˛ i gdzie sensowne jest wykorzystywanie produktów Open Source. Rysunek 3.48: Rozwiazania ˛ HA Niedostateczne stosowanie klastrów pracujacych ˛ z niewielka˛ ilościa˛ dużych, całkowicie redundantnie zoptymalizowanych maszyn, spowodowana jest przede wszystkim tym, że stoso- ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 347 wany, specjalistyczny osprz˛et cz˛esto nie jest w wystarczajacy ˛ sposób obsługiwany przez system operacyjny. Open Source Software można stosować przede wszystkim w obszarze farm serwerów, najlepiej w systemach bez dużych 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. Można je tu zastosować, o ile wymagania SLA nie sa˛ bardzo wysokie (np. 99,9% czasu pracy biur lub inne). W takim przypadku wysoka niezawodność jest najcz˛eściej gwarantowana poprzez architektur˛e Failover. Istnieja˛ jednak także możliwości tworzenia klastrów na poziomie Middleware (np. wykorzystujac ˛ JBoss). Wysoko niezawodne bazy danych Open Source nie istnieja.˛ Jednak można tu zaplanować wykorzystanie własnościowego oprogramowania (np. Oracle RAC) w Linuksie i cz˛eściowo uzyskać w ten sposób znaczne oszcz˛edności, jeśli chodzi o koszty osprz˛etu. 3.17.5 Komercyjne oprogramowanie HA Oprogramowanie HA jest domena˛ świata uniksowego i Mainframe. Windows DataCenter uznawany jest z reguły za niewystarczajace ˛ dla aplikacji mission - critical. Na poziomie systemu operacyjnego każdy z dużych producentów oprogramowania uniksowego udost˛epnia rozwiazanie ˛ HA odpowiadajace ˛ architekturze Failover; HP po fuzji z Compaq nawet dwa, jednak wymieniamy tu tylko to, które przetrwało. IBM HP S UN system operacyjny / pakiet HA AIX HACMP HP-UX MX / Serviceguard Solaris Sun Cluster system plików JFS2 HFS UFS z Sun VM klastrowy system plików tak nie tak maksymalna ilość maszyn 32 16 8 obsługa wielu instancji aplikacji tak tak tak partycjonowanie tak tak tak Failover istniejacych ˛ połaczeń ˛ TCP nie tak tak ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI technologia zapisu 348 Ultra3 SCSI Ultra3 SCSI Ultra3 SCSI Fiberchannel Fiberchannel Fiberchannel CampusCluster opcje do Disaster Recovery HAGEO GeoRM administrowanie GUI zintegrowany z SMIT Metrocluster Continental Cluster Continous Access XP oddzielny GUI Storage Data Network Replicator GUI zintegrowany z SUNMC Tablica 3.79: Przeglad ˛ komercyjnego oprogramowania HA Jak już wspomnieliśmy, Oracle RAC jest w obszarze baz danych najważniejsza˛ możliwościa˛ udost˛epniania wysokiej niezawodności także na poziomie Middleware. Rozwiazanie ˛ to jest dost˛epne dla własnościowych systemów Unix, Linuksa oraz serwera windowsowego. 3.17.6 Rozwiazania ˛ Open Source dla systemów HA Świat Open Source Tools rozwija si˛e niesłychanie szybko. Niniejszy podrozdział zawiera przeglad ˛ istniejacego ˛ oprogramowania Open Source HA, które jest szeroko stosowane i które sprawdziło si˛e w wielu instalacjach. Jednak dla konkretnych projektów HA może to być tylko wskazanie potencjalnej przydatności. W każdym projekcie trzeba na nowo określić architektur˛e i sprawdzić sposób wykorzystania poszczególnych Tools. Autorzy analizy widza˛ konieczność właczenia ˛ do każdego projektu doświadczonych specjalistów. Wiele z wymienionych poniżej Tools udost˛epnianych jest oczywiście także przez firmy. W Niemczech niemal wszystkie linuksowe Tools udost˛epnia SuSE. Pomoc techniczna˛ oraz wsparcie podczas tworzenia projekty zapewnia wiele firm, m.in. także 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ównież dost˛ep multi - path, tzn. jednoczesne podłaczenie ˛ podsystemów dysków do różnych komputerów. Jest to wymagane dla dysków gromadzacych ˛ dane i aplikacje w ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 349 architekturze Failover. Dyski systemowe musza˛ być podłaczone ˛ zawsze dokładnie do jednego komputera. Wraz z LVM pojawił si˛e funkcjonalny Volume Manager. ext3 stał si˛e domyślnym systemem plików z Journaling (patrz także rozdział 3.11.4). 3.17.6.2 Failover za pomoca˛ heartbeat Architektura Failover dla systemów linuksowych może być 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˛ zostać uruchomione na innym serwerze. Nast˛epuje przy tym przej˛ecie istniejacych ˛ stanów sesji. Ponieważ Linux nie obsługuje konfiguracji Multi - Path kart sieciowych, kontrola dost˛epności usługi może być przeprowadzana poprzez różne kanały komunikacyjne (szeregowo i sieć). Cz˛esto jest tak, że w przypadku awarii usługi powinno nastapić ˛ automatyczne bootowanie urzadzenia. ˛ Najbardziej udokumentowanym rozwiazaniem ˛ jest „watchdog“. Jest ono podatne na bł˛edy i prowadzi do zbyt cz˛estych Reboots. W wielu przypadkach lepszy powinien być moduł o nazwie „hangcheck - timer“. Wybór modułu należy pozostawić doradcom, którzy planuja˛ konkretne zastosowanie architektury HA. Każdy projekt HA powinien wziać ˛ pod uwag˛e także ograniczenia rozwiazania ˛ Failover z rodziny Open Source. Nie istnieje klastrowy sytem plików, maksymalna ilość maszyn w klastrze Failover nie powinna być wi˛eksza niż trzy, nie jest obsługiwane logiczne partycjonowanie istniejacych ˛ maszyn (przyporzadkowanie ˛ zasobów sprz˛etowych, takich jak CPU oraz miejsca na dysku do grup zasobów) oraz brak jest również opcji do Disaster Recovery. heartbeat jest cz˛esto stosowanym modułem; projekt Linux - HA przyznaje, że wspomniany moduł wykorzystywany jest w zastosowaniach produkcyjnych w tysiacach ˛ instalacji na całym świecie. Stanowi on rdzeń rozwiazań ˛ HA oferowanych przez przodujacych ˛ producentów oprogramowania linuksowego (SuSE, Conectiva, Mandrake). Jednym ze znanych użytkownikó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, możliwe było stworzenie niezawodnego systemu wysokiej niezawodności. Poniższy rysunek przedstawia zastosowane tam rozwiazanie ˛ i jego architektur˛e. 129 http://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 ˛ si˛e z Heartbeat i DRBD 130 (Distributed Replicated Block Device) realizuje rozwiazanie ˛ wysokiej niezawodności dla serwerów plików, serwerów drukarek, serwerów poczty elektronicznej, serwera WWW, usług domen (DNS, DHCP) oraz usługi katalogowej. Kontrola w˛ezłów serwerów odbywa si˛e za pomoca˛ Heartbeat. W tym celu maszyny zostały połaczone ˛ poprzez Crossover - Ethernet i szeregowy kabel null modem. Gdy aktywny serwer nie jest już dost˛epny ta˛ droga˛ komunikacji, wówczas serwer Failover automatycznie przejmuje wirtualne adresy i odpowiednie usługi. Oprócz wysokiej niezawodności, dzi˛eki programowi DRBD, uzyskiwany jest mirroring Raid-1 partycji badź ˛ logical Volumens. W ten sposób w przypadku awarii aktywnego serwera, drugi serwer ma dost˛ep do zapisanych danych. Zastosowanie DRBD zamiast zewn˛etrznych systemów SAN może być tańsza˛ alternatywa˛ realizujac ˛ a˛ określone scenariusze. 3.17.6.3 Farmy serwerów Infrastruktur˛e dla serwera farm oferuje Linux Virtual Server (LVS). Load Balancer w Linuksie przydziela nadchodzace ˛ Requests do wielu rzeczywistych systemów. Dla użytkownika końcowego systemy te nie sa˛ widoczne. Cała instalacja wyglada ˛ dla niego, jak jeden duży serwer. Typowymi przykładami zastosowania sa˛ serwery WWW, poczty elektronicznej albo Media - Server. Linux Virtual Server jest cz˛esto stosowany razem z architektura˛ Failover dla Load - Balancer. Aby w łatwy sposób połaczyć ˛ obydwie w/w technologie skorzystać można z projektu UltraMonkey albo produktu Open Source firmy Red Hat o nazwie Piranha. 130 http://www.complang.tuwien.ac.at/reisner/drbd/ ROZDZIAŁ 3. TECHNICZNE OPISY MIGRACJI 351 LVS stosowany jest w procesach produkcyjnych wielu firm. Za pomoca˛ LVS gwarantowana jest wysoka dost˛epność bardzo dużych serwisów WWW: linux.com i sourceforge.net. Real Networks wykorzystuje LVS w klastrze Media - Servers. 3.17.6.4 Application Clustering Application Clustering udost˛epniaja˛ przodujace ˛ serwery aplikacji wywodzace ˛ si˛e z rodziny Open Source: Tomcat jest niskopoziomowy serwerem aplikacyjnym, za pomoca˛ którego można realizować Java Servlets i Java Server Pages (JSP). Dzi˛eki swojemu Feature służacemu ˛ do rozkładania obciażenia, ˛ obsługuje on Application Clustering. Bazy danych Open Source nie oferuja˛ rozwiazań ˛ wysokiej niezawodności. Najcz˛eściej jednym z głównych problemów jest brak możliwości wykonywania Online - Backup. Jednak dla systemów linuksowych firma Oracle udost˛epnia swoja˛ opcj˛e RAC, co pozwala na poczynienie znacznych oszcz˛edności w obszarze osprz˛etu i obsługi technicznej. 3.17.6.5 Compute Cluster Gwoli rzetelności należy w tym miejscu wspomnieć jeszcze także o rozwiazaniach ˛ HA w ramach High Performance Computing, nawet jeśli ten obszar zastosowania interesuje administracj˛e publiczna˛ jedynie w ograniczonym stopniu. Beowolf był pierwszym projektem Compute - Cluster dla Linuksa i także dziś jest on nadal najcz˛eściej stosowany. Job Scheduling wewnatrz ˛ klastra udost˛epniane jest poprzez Portable Batch System (PBS) albo MAUI Scheduler. Rozdział 4 Ocena wydajności ekonomicznej 4.1 Wprowadzenie Jak pokazuje dyskusja nt. dost˛epnych na rynku analiz dotyczacych ˛ TCO 1 , dokonanie oceny ekonomicznej zamierzeń informatycznych zwiazanych ˛ z wykorzystywaniem produktów OSS i COLS2 jest zasadniczo bardzo trudne i ze wzgl˛edu na cz˛esto wielowymiarowe modele ekonomiczne staje si˛e zadaniem niemalże nie do rozwiazania. ˛ W przypadku analizy obejmujacej ˛ wiele zagadnień oraz zawierajacej ˛ wiele wniosków, która bez watpienia ˛ ma miejsce w przypadku porównywania kosztów platform Microsoft i OSS / COLS, do najistotniejszych zadań należy zestawienie podobieństw badanych obiektów, jak też uwzgl˛ednienie prawidłowego zakresu analizy. Wynik waskiej ˛ oceny oddzielnych aspektów niekoniecznie musi przenosić si˛e na ogólny obraz, czego przykładem jest analiza IDC wykonana na zlecenie Microsoft pod tytułem „Windows 2000 vs. Linux for Enterprise Applications“. Ponieważ powyższa analiza zajmuje si˛e zaledwie kosztami serwerów wykonujacych ˛ zadania infrastrukturalne, w przypadku których proporcjonalny udział kosztów licencji w porównaniu do ogólnych kosztów jest inny niż na przykład w przypadku aplikacji klienckich, nie można bezpośrednio uzyskać informacji odnośnie opłacalności ekonomicznej w obszarze aplikacji lub desktopów. Podczas wykonywania analizy konieczne jest także uwzgl˛ednienie struktur użytkowników. Szczególnie ważna dla oceny ekonomicznej migracji jest wielkość organizacji oraz różne wyjściowe scenariusze środowiska informatycznego. Cz˛esto można zauważyć, że w małych urz˛edach (na przykład w sektorze komunalnym) infrastruktura zbudowana jest za pomoca˛ prostych 1 2 TCO = Total Cost of Ownership (całkowite koszty posiadania) OSS = Open Source Software, COLS = Commercial Linux Software 352 ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 353 środków i aby mogła działać nie jest wymagane intensywne kształcenie użytkowników. Z drugiej strony niezawodne działanie w przypadku infrastruktur centrów obliczeniowych, dużych i / lub specjalizowanych urz˛edów oraz centrów danych realizujacych ˛ Service Level Agreements wymaga od pracowników wyższego poziomu wykształcenia, uregulowań organizacyjnych na wypadek awarii i sytuacji kryzysowych, jak również cz˛esto innego osprz˛etu. Biorac ˛ pod uwag˛e niniejsze warunki brzegowe, dla dokonania oceny infrastruktury i kosztów konieczne jest spojrzenie wielowymiarowe. Podczas przygotowań do oceny kosztów informatyzacji obowiazuje ˛ zasada, że istotnym elementem wzrostu opłacalności może być przede wszystkim czynnik ludzki, organizacyjny i racjonalizacja w administracji publicznej. Jednak oprócz tego również odpowiednio zaprojektowana strategia informatyczna może przyczynić si˛e do podniesienia opłacalności ekonomicznej. Na ogólna˛ ocen˛e ekonomiczna˛ informatyzacji silnie wpływa: ◦ stopień w jakim korzystne cenowo, standardowe produkty realizuja˛ wymagane funkcje ◦ jakość, możliwość rozwoju i możliwość 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 łańcuchem powstawania kosztów ◦ dobra (wewn˛etrzna albo zewn˛etrzna) organizacja pomocy technicznej, jak również duża wiedza (Know - how) ◦ ekonomiczna długość życia produktów ◦ koszty i wydajność procesów oraz ◦ konkurencja w dziedzinie produktów i usług. Dopiero optymalne współdziałanie wszystkich powyższych czynników przez dłuższy czas, warunkuje i wpływa na łaczn ˛ a˛ ocen˛e opłacalności, dlatego uproszczona ocena pojedynczych koszów z reguły nie oddaje całości w prawidłowy sposób. Oprócz uzyskania informacji o kosztach i ich porównania, ważnym aspektem oceny ekonomicznej jest także ocena możliwych wartości użytkowych. Szczególnie w tym obszarze ważna˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 354 rol˛e dla dokonania całościowej oceny obejmujacej ˛ zarówno sytuacj˛e wyjściowa,˛ jak też sytuacj˛e w przyszłości, odgrywaja˛ strategiczne przemyślenia oraz prognozowane zalety. Przykład: Wyższe koszty pojedynczego składnika moga˛ uzyskać lepsza˛ ocen˛e strategiczna˛ wskutek uzyskania niezależności od producenta oraz lepszej pozycji przetargowej w przypadku cen licencji na oprogramowanie, co z kolei może prowadzić do wyraźnie korzystniejszego ogólnego wyniku. Z tych powodów zarówno przedstawiana przez nas metoda, jak i wynik, moga˛ służyć jedynie za pomoc podczas ustalania własnej oceny ekonomicznej oraz podczas formułowania własnej strategii informatyzacji. 4.2 Metodologia Wprawdzie zasadniczo możliwe jest funkcjonalne i jakościowe porównanie różnych rzeczy, jednak wymaga to analizy kosztów i zysków, w której należy przeciwstawić oczekiwany wzrost produktywności oczekiwanym, dodatkowym kosztom. Nie mogliśmy jednak umieścić w niniejszym poradniku oceny produkcyjności w łańcuchu powstawania kosztów informatyzacji, gdyż nie istnieja˛ odpowiednie neutralne, długookresowe badania, zwłaszcza jeśli chodzi o administracj˛e publiczna.˛ Prawdopodobnie w oparciu o dzisiejsze doświadczenia i ze szczególnym uwzgl˛ednieniem tego, że zarówno w przypadku platformy Linux / Unix jak i Microsoft chodzi wyłacznie ˛ o produkty tworzone od wielu lat, doprowadziłaby ona do uzyskania wyważonego wyniku. Z tych powodów ocena ekonomiczna zamieszczona w poradniku migracyjnym koncentruje si˛e na bezpośredniej analizie kosztów i analizie korzyści. 4.2.1 Analiza kosztów Aby obliczyć pieni˛eżne skutki migracji posłużyliśmy si˛e metoda˛ obliczania wartości kapitału. Jest to metoda dynamiczna i ocenia projekty inwestycyjne według ich wartości kapitałowej, tzn. poprzez zbliżone do rzeczywistości zebranie wszystkich strumieni finansowania zwiazanych ˛ z inwestycja˛ (wpływy i wydatki; wpływajace ˛ na budżet i nie wpływajace ˛ na budżet), skoncentrowane we wspólnym punkcie odniesienia. Wpływy i wydatki majace ˛ zwiazek ˛ z migracja,˛ można zaplanować na pi˛eć lat z góry. Dla przyszłych wartości podaliśmy aktualna,˛ czasowa˛ wartość, dyskontujac ˛ ja˛ w oparciu o stop˛e procentowa˛ ustalona˛ przez Ministerstwo Finansów. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 355 4.2.2 Analiza korzyści W przypadku, gdy podczas zastanawiania si˛e nad decyzja˛ nie można wziać ˛ pod uwag˛e skutków finansowych, należy skorzystać z analizy korzyści. Ocenia ona pojedynczo i niezależnie od siebie ważne kryteria celu, by ostatecznie połaczyć ˛ je w ocen˛e ogólna.˛ Sklasyfikowaliśmy tu według skali ocen tak zwane „mi˛ekkie“ czynniki. Zalecamy, aby ocen˛e wyników uzyskać w dwóch krokach: 1. Pierwszeństwo maja˛ wyniki analizy kosztów. Wskaźnik rentowności, który wyraża si˛e dodatnia˛ wartościa˛ kosztów, wynikać b˛edzie z kosztów oraz oszcz˛edności zwiazanych ˛ z migracja˛ liczonych zgodnie z w/w metoda.˛ 2. Z rezultatów analizy korzyści wynika wskaźnik konieczności i strategia. W ramach projektu migracyjnego należy je traktować jako majace ˛ mniejsze znaczenie. Ten drugi krok potrzebny jest przede wszystkim w przypadku, gdy z punktu widzenia kosztów ocena ekonomiczna jest niewystarczajaca ˛ badź ˛ nie dostarcza jednoznacznej odpowiedzi na pytanie o rentowność. W oparciu o kryteria konieczności, wzgl˛ednie strategii projekt może w każdej chwili uzyskać wysoki priorytet wykonania, niezależnie od kryteriów kosztów. 4.2.3 IT-WiBe 21 W niemieckiej administracji oceny ekonomicznej należy dokonać zgodnie z przepisami BHO paragraf 7 i według wydanych do nich przepisów wykonawczych, które od 1995 roku uwzgl˛edniaja˛ przede wszystkim post˛epowanie w ramach ekonomiki przedsi˛ebiorstwa. W celu dostosowania w/w przepisów do specjalnych wymagań zwiazanych ˛ z informatyzacja, ˛ Rzadowy ˛ Urzad ˛ Koordynacji i Doradztwa ds. Informatyzacji przy Ministerstwie Spraw Wewn˛etrznych Republiki Federalnej Niemiec (KBSt) opracował już w 1992 roku instrukcj˛e post˛epowania pod tytułem „Zalecenia odnośnie przygotowywania oceny ekonomicznej w przypadku stosowania systemów informatycznych w administracji publicznej (IT - WiBe)“. W 1997 roku ukazała si˛e ona w całkowicie przeredagowanym brzmieniu. IT - WiBe zawiera trzy główne kroki: ◦ ustalenie wielkości wpływu (selekcja kryteriów) ◦ przenoszenie / ocena danych ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 356 ◦ ustalenie wskaźników Rysunek 4.1: Metodologia IT-WiBe IT - WiBe jest procedura,˛ w której, inaczej niż w przypadku metodyki TCO, ocena nie jest dokonywana tylko z punktu widzenia kosztów, lecz uwzgl˛edniane sa˛ także możliwe oszcz˛edności. 4.2.4 Koszty migracji Wprawdzie IT - WiBe zasadniczo dobrze nadaja˛ si˛e dla przeprowadzenia oceny ekonomicznej projektu, jednak odnoszenie ich do całego modelu jest cz˛esto zbyt skomplikowane i (z braku odpowiednich danych o budżecie) niemożliwe, do analizy różnicy kosztów należy zastosować metod˛e uproszczona˛ – matryc˛e kosztów migracji. Ten sposób post˛epowania nie obejmuje kosztów i oszcz˛edności wynikajacych ˛ z wyselekcjonowanych kryteriów, lecz łaczy ˛ je w kategorie: osprz˛et, oprogramowanie i obsługa. W kategoriach tych należy ujać ˛ pi˛ecioletnie koszty zaopatrzenia3 i dalsze koszty, jak również możliwe 3 Takie obszary kosztów, jak koszty wprowadzenia i dalsze koszty mieszcza˛ w sobie, podobnie jak w przypadku ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 357 oszcz˛edności. Ogólny widok pokazuje wszystkie lata i kategorie. Ponadto, podobnie jak w przypadku WiBe21, ocena rentowności ustala wartość kapitału zdyskontowana˛ do punktu odniesienia. Dzi˛eki temu praktycy w urz˛edach otrzymuja˛ do r˛eki instrument, który umożliwia łatwe i szybkie przygotowanie wolumenu kosztów projektu uwzgl˛edniajacego ˛ jego dalsze koszty oraz oszcz˛edności, jak również przygotowanie oceny rentowności 4. 4.2.5 TCO Podstawowa˛ zasada˛ oceny TCO jest podział wszystkich kosztów danego systemu informatycznego na dwie grupy: koszty bezpośrednie i koszty pośrednie. Pod poj˛eciem kosztów bezpośrednich należy rozumieć wszystkie koszty, które zapisywane sa˛ w budżecie. Wspólna˛ cecha˛ kosztów bezpośrednich jest to, że można je zmierzyć w jednostkach pieni˛eżnych. Druga˛ duża˛ grup˛e stanowia˛ koszty pośrednie, nieujmowane w budżecie. Zalicza si˛e do nich czasy bezczynności, w których planowo albo poza planem nie można używać ocenianych systemów. Czasy te można zmierzyć, jednak nie bezpośrednio w jednostkach pieni˛eżnych. W tym celu konieczne jest niepodważalne przeliczenie wypłacanego „nieefektywnie“ uposażenia albo utraconych obrotów. Ponadto do kosztów pośrednich zalicza si˛e „bezproduktywna“ ˛ prac˛e użytkowników końcowych, np. pomaganie samemu sobie, wzajemna pomoc, formalne i nieformalne uczenie si˛e, zarzadzanie ˛ i zabezpieczanie danych, granie, serfowanie i tak dalej. Zasadniczo metoda ta nadaje si˛e także do ustalania kosztów migracji. Jednak ponieważ oceniane sa˛ tu wyłacznie ˛ aspekty zwiazane ˛ z kosztami i brak jest analizy rentowności, w której swoje odbicie mogłyby znaleźć wszystkie omawiane aspekty kosztów, również te z WiBe21 i z matrycy kosztów migracji, w ekonomicznej ocenie migracji ustalenie TCO nie znajduje zastosowania. 4.2.6 Porównywalność W celu zagwarantowania porównywalności różnych ocen, ocen˛e ekonomiczna˛ należy przeprowadzić w dwóch scenariuszach: ◦ migracja pojedynczych lub wielu obiektów5 (migracja cz˛eściowa) w przypadku jasno oszcz˛edności, nast˛epujace ˛ elementy: infrastruktura serwerów, aplikacje bazodanowe, Messaging / Groupware, aplikacje WWW, Office / Desktop i inne. 4 Patrz rozdział „Wymiar pieni˛eżny (operacyjny)“, rysunek „Matryca kosztów migracji z kategoriami kosztów i obszarami zastosowań“. 5 Patrz rozdział 3.17.3 – rozdzielanie obiektów. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 358 dajacych ˛ si˛e rozdzielić produktów albo grup produktów6 ◦ całkowita migracja, tzn. migracja całego środowiska przetwarzania danych – serwerów, klientów, infrastruktury, aplikacji specjalistycznych Pod poj˛eciem migracji należy zasadniczo rozumieć dwie rzeczy: ◦ migracj˛e zast˛epujac ˛ a,˛ jako migracj˛e do całkiem nowego środowiska opartego na Open Source, w którym korzysta si˛e z Open Source Software (OSS) i / lub Commercial Linux Software (COLS). albo ◦ migracj˛e kontynuacyjna˛ – jako migracj˛e w ramach stosowanych już produktów do ich nowych wersji Na potrzeby migracji obiektów migracyjnych należy skorzystać ze zredukowanego katalogu kryteriów przygotowanego specjalnie na wypadek migracji cz˛eściowej. Katalog ten zawiera kryteria wdrożenia i pracy7 . W przypadku całkowitej migracji należy stosować ogólne kryteria ocen IT - WiBe. Ponieważ w wielu przypadkach migracja taka dotyczy także aplikacji specjalistycznych, z reguły oprócz czynności migracyjnych zwiazanych ˛ z produktami standardowymi, konieczne b˛eda˛ także prace programistyczne dotyczace ˛ specyficznych aplikacji. Zasady te stosuje si˛e głównie, gdy mamy do czynienia z „wewn˛etrzna“ ˛ migracja.˛ Jeśli migracja dotyczy tylko pojedynczych produktów albo grup produktów (takich jak, np. MS Office), wówczas należy mówić o obiektach migracyjnych i stosować specyficzny katalog kryteriów. Natomiast gdy chodzi o bardziej skomplikowany scenariusz (np. produkty MS dla komunikacji i biura, aplikacje specjalistyczne, etc), wtedy należy stosować pełny katalog kryteriów WiBe. Kolejny aspektem jest to, że porównawcza analiza wydajności ekonomicznej ma sens tylko w przypadku dajacych ˛ si˛e porównać technicznie i funkcjonalnie alternatywnych rozwiazań. ˛ Za porównywalne w sensie poradnika migracyjnego można uznać nast˛epujace ˛ obszary zastosowań technologii OSS i Microsoft: ◦ usługi infrastrukturalne 6 Przykład: Aplikacje desktopowe jako obiekty migracji zawierajace ˛ produkty takie jak: edytor tekstu, arkusz kalkulacyjny i przegladarka ˛ WWW. 7 Inaczej niż w przypadku ogólnego katalogu kryteriów, usuni˛ete zostały tu kryteria rozwoju i zastapione ˛ kryteriami wdrożenia. ROZDZIAŁ 4. OCENA WYDAJNOŚCI 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, bezpieczeństwo informatyczne jest jednoznacznie bardziej zagrożone w przypadku systemów windowsowych i obszaru tego nie da si˛e porównać. Nawet przy wi˛ekszych nakładach nie można uzyskać porównywalnych zabezpieczeń obydwu systemów, dlatego zrezygnowaliśmy z ekonomicznej oceny obszaru bezpieczeństwa. 4.2.7 Instalacja od podstaw a migracja Jeśli ocena kosztów odbywa si˛e pod katem ˛ wprowadzenia nowych technologii, wówczas zasadniczo należy odróżnić instalacj˛e od podstaw od migracji procesów i systemów. Obowiazuje ˛ przy tym „zasada lenia“ mówiaca ˛ o tym, że wykonanie instalacji od podstaw jest prostsze i tańsze, niż migracja, w przypadku której trzeba zastapić ˛ różne, po cz˛eści historycznie obciażone ˛ architektury oraz przenieść dane tak, aby nie doszło do istotnego zakłócenia pracy albo do utraty niegdyś używanych danych. Ponieważ proces migracji zależy zasadniczo od punktu wyjścia, sformułowanie ogólnie obowiazuj ˛ acej, ˛ obejmujacej ˛ wszystkie koszty zasady, jest prawie niemożliwe. Podczas, gdy migracja w niektórych przypadkach możliwa jest bez problemów i niemal bez nakładów, istnienie samodzielnie stworzonych aplikacji, które także trzeba zastapić, ˛ przeniesienie starych danych oraz specjalnej struktury użytkowników i praw dost˛epu czy innych szczególnych właściwości prowadzi do powstania znacznych nakładów, które należy ocenić indywidualnie, w zależności od urz˛edu – także z uwzgl˛ednieniem aspektów krytycznych. 4.2.8 Obliczanie pełnych kosztów Z tych powodów ocena ekonomiczna koncentruje si˛e na ustaleniu i analizie pełnych kosztów zwiazanych ˛ z głównymi rozwiazaniami ˛ alternatywnymi opisanymi w poradniku migracyjnym: ROZDZIAŁ 4. OCENA WYDAJNOŚCI 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 każdego z alternatywnych rozwiazań. ˛ W celu stworzenia podstawy koniecznej dla podj˛ecia decyzji o migracji, trzeba ostatecznie ogłosić koszty migracji. Korzystajac ˛ z dobrze obsadzonego, w tzw. mi˛edzyczasie, sektora usług, bez problemu można zdobyć szacunkowe wyniki bezpośrednio w formie oferty migracyjnej udost˛epnianej zarówno przez zewn˛etrznych, jak i wewn˛etrznych usługodawców oraz skonfrontować je ze stwierdzonymi potencjałami. Stosowana przy tym metoda uwzgl˛ednia niehomogeniczna˛ struktur˛e i różna˛ wielkość urz˛edów poprzez różne ocenianie danych. Pojedyncze kroki prowadzace ˛ do określenia pełnych kosztów poszczególnych alternatywnych rozwiazań ˛ przedstawiliśmy poniżej: ◦ zdefiniowanie obszarów zastosowań, które należy przeanalizować ◦ ustalenie czynników kosztów w analizowanych obszarach zastosowań ◦ ustalenie wartości czynników kosztów dla: – małych urz˛edów – średnich urz˛edów – dużych urz˛edów ◦ ustalenie kosztów zwiazanych ˛ ze środkami racjonalizacyjnymi (narz˛edzia do zarzadzania ˛ systemem) ◦ ustalenie struktury kosztów analizowanych rozwiazań ˛ alternatywnych ◦ ustalenie istnienia możliwości porównania jakościowego i technicznego ◦ przeprowadzenie analizy scenariusza w przypadku migracji do: – OSS Open Source Software – COLS Commercial Linux Software ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 361 W wymiarze czysto pieni˛eżnym bezpośredni potencjał OSS / COLS wynika przede wszystkim z oszcz˛edności zwiazanych ˛ z kosztami licencji (dalsze możliwości 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 pieni˛eżny (operacyjny) 4.3.1 Obszary zastosowań W celu uzyskania wymownego wyniku, analiz˛e należy wykonać w ogólnym kontekście składajacym ˛ si˛e z wielu obszarów zastosowań. Całościowa ocena analizowanych kosztów obejmie przy tym nast˛epujace ˛ obszary: ◦ infrastruktura serwera – zarzadzanie ˛ plikami – drukowanie – logowanie – usługi sieciowe ◦ infrastruktura desktopu – biuro – WWW ◦ Messaging / Groupware ◦ aplikacje bazodanowe i aplikacje WWW Powyższe wyliczenie, mimo tego, że nie jest kompletne, tworzy wspólny mianownik dla wi˛ekszości infrastruktur wykorzystywanych w urz˛edach. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 362 4.3.2 Kategorie kosztów Tworzenie możliwości porównania kosztów oraz znormalizowanie wyników ich oceny wymaga stworzenia jednoznacznego modelu kosztów obowiazuj ˛ acego ˛ dla wszystkich obszarów zastosowań. Metoda użyta w poradniku migracyjnym opiera si˛e na tym, że nie jest dokonywana ocena produkcyjności (patrz rozdział 4.2) ani też szczególna ocena wpływu awaryjności na produkcyjność czy koszty Outsourcingu: ◦ osprz˛et – porównanie wymagań odnośnie oprzyrzadowania ˛ ◦ oprogramowanie – koszty licencji na oprogramowanie – koszty konserwacji oprogramowania – dodatkowe koszty systemów katalogowych – dodatkowe koszty systemów zarzadzania ˛ i bezpieczeństwa ◦ obsługa – administrowanie – wsparcie (Support) – opieka nad oprogramowaniem – szkolenie ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 363 Rysunek 4.2: Matryca kosztów migracji z kategoriami kosztów i obszarami zastosowań Wskazówka dotyczaca ˛ oceny czasu przestoju: Zgodnie z doświadczeniami szczególnie centrów obliczeniowych, można zasadniczo przyjać, ˛ że systemy linuksowe w porównaniu z systemami MS Windows sa˛ bardziej niezawodne i tym samym można założyć pełniejsze wykorzystanie mocy produkcyjnych pod Linuksem8 . 4.3.3 Własności użytych kategorii podmiotów publicznych W kolejnych rozdziałach wypunktowane zostały właściwości urz˛edów różnego typu. Z powodu dużych różnic w wyposażeniu informatycznym, z którymi mamy tam do czynienia, oraz orgarnizacji poszczególnych urz˛edów, poniższych punktów należy postrzegać jako zgrubna˛ pomoc wskazujac ˛ a˛ ważne kryteria dla własnej analizy. 4.3.3.1 Małe urz˛edy ◦ użytkownicy: do 250 ◦ osprz˛et: z reguły mała i tania platforma Intel 8 Potwierdza to także IDC w swoim opracowaniu przygotowanym na zlecenie Microsoft „Windows 2000 vs Linux dla zastosowań w przedsi˛ebiorstwach“, 2002 ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 364 ◦ Backup i Recovery: tanie mechanizmy archiwizacji danych, wykorzystanie urzadzeń ˛ taśmowych albo systemów RAID ◦ personel: z reguły jeden administrator posiadajacy ˛ ogólna˛ specjalizacj˛e, jeden przedstawiciel ◦ organizacja obsługi informatycznej: jedna osoba badź ˛ grupa, niski stopień specjalizacji ◦ bezpieczeństwo i niezawodność: z reguły wymagania niskie do średnich ◦ zarzadzanie ˛ systemem: pojedyncze narz˛edzia (MS) albo skrypty (GNU / Linux) 4.3.3.2 Urz˛edy średniej wielkości ◦ użytkownicy: od 250 do 1.000 ◦ osprz˛et: małe i duże systemy oparte na serwerach, platformy RISC oraz Intel, możliwe także architektury zdecentralizowane, jak i centralne ◦ Backup i Recovery: w użyciu dedykowane Backup - Server oraz serwery archiwizujace, ˛ reguła˛ jest stosowanie technologii RAID ◦ personel: wielu administratorów pracujacych ˛ codziennie osiem godzin, specjalizacja, gotowość służby awaryjnej ◦ organizacja obsługi informatycznej: dział informatyki ◦ bezpieczeństwo i niezawodność: z reguły wymagania średnie do dużych ◦ zarzadzanie ˛ systemem: programistyczne narz˛edzia dedykowane (software distribution tools), Thin Clients, monitorowanie sieci i kontrola systemu 4.3.3.3 Duże urz˛edy / centra obliczeniowe9 ◦ użytkownicy: ponad 1.000 (do 10.000) ◦ osprz˛et: tanie klastry firmy Intel, duże rozwiazania ˛ oparte na serwerach, dzielone architektury, centralne systemy Mainframe 9 W konkretnym przypadku należy wspólnie potraktować średnie oraz duże urz˛edy i analizować centra obliczeniowe tak, jak gdyby były szczególna˛ forma˛ urz˛edu. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 365 ◦ Backup i Recovery: centralny serwer Backup- / Disaster - Recovery z oprogramowaniem Roboter albo Jukebox ◦ personel: administratorzy pracujacy ˛ osiem godzin dziennie, specjalizacja, gotowość służby awaryjnej ◦ organizacja obsługi informatycznej: centrum obliczeniowe, w konkretnym przypadku lokalne zespoły administratorów ◦ bezpieczeństwo i niezawodność: wymagania wysokie do bardzo wysokich, stosowanie obszernych rozwiazań ˛ SAN ◦ zarzadzenie ˛ systemem: dedykowane narz˛edzia programistyczne (software distribution tools), Thin Clients, monitorowanie sieci i kontrola systemu. 4.4 Wymiar strategiczny Oprócz bezpośredniej, pieni˛eżnej analizy całkowitych kosztów wdrożenia poszczególnych rozwiazań ˛ alternatywnych, istnieje także konieczność wykonania i uwzgl˛ednienia oceny strategicznej (w terminologi WiBe – wymiar strategiczny). Konieczność przeprowadzenia oceny strategicznej wynika z wagi bezpośrednich skutków czynnika strategicznego jakim jest „uzależnienie 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˛ rol˛e odgrywaja˛ aspekty zwiazane ˛ z konkurencyjnościa: ˛ ◦ lepsza jakość produktu ◦ niższe ceny produktu ◦ wyższy stopień innowacyjności. Pomimo tego, że z reguły wszyscy producenci oprogramowania przypisuja˛ sobie zarówno wyższa˛ jakość produktu, jak też innowacyjność technologiczna,˛ w rzeczywistości rzadko można tak generalizować. Zwłaszcza rozwój World Wide Web pokazuje, że na przykład Microsoft przez długi czas „przesypiał“ t˛e najważniejsza˛ sfer˛e innowacyjności ostatnich dekad. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 366 Ocena makroekonomiczna ma wprawdzie zasadniczy charakter, jednak odbiorcy poradnika migracyjnego nie moga˛ na nia˛ bezpośrednio wpływać i dlatego nie została tu dogł˛ebnie przeanalizowana. Monopolistyczna˛ pozycja˛ Microsoftu w dziedzinie systemów operacyjnych zajmuje si˛e obecnie Komisja Europejska. Na wyniki jej prac i ewentualne wnioski trzeba jeszcze poczekać. 4.4.2 Spojrzenie mikroekonomiczne Istotna˛ rzecza˛ dla oceny mikroekonomicznej jest własne uzależnienie od dostawcy produktów i usług. Mimo, że tego typu uzależnienie w dużym stopniu powstaje i uwidacznia si˛e wskutek istnienia monopoli lub quasi monopoli, zbyt silna zależność od dostawców może również wystapić ˛ w warunkach istniejacej ˛ konkurencji i prowadzić w pewnych okolicznościach do zaistnienia niekorzystnych warunków ekonomicznych. Z jednej strony polegać one moga˛ na wyższych cenach produktów, zaś z drugiej na krótszej długości życia produktów generujacej ˛ dodatkowe koszty wdrożeń w przypadku migracji kontynuacyjnej. W ekstremalnym przypadku uzależnienie prowadzić może do sytuacji, w których nie ma już alternatywnych możliwości post˛epowania mieszczacych ˛ si˛e w akceptowalnej cenie. W przeciwieństwie do powyższego, sytuacja oparta na strategiczej równowadze prowadzi do lepszej pozycji przetargowej, która w przypadku pojawienia si˛e problemów, pozwala si˛egnać ˛ po rozwia˛ zania alternatywne. 4.5 Wyniki oceny wydajności ekonomicznej Wi˛ekszość badań poświ˛econych niniejszemu zagadnieniu korzysta w swojej metodologii ze stopy kosztów całkowitych i dowodzi słuszności twierdzenia, że istotna cz˛eść kosztów przypada nie na licencje na oprogramowanie, lecz leży po stronie wdrożenia i kosztów osobowych zwiazanych ˛ z przygotowaniem obsługi. Jednak wskutek różnych założeń – w szczególności dotyczacych ˛ sposobów administrowania systemami – wyniki w/w badań prowadza˛ do sprzecznych wniosków dotyczacych ˛ zalet ekonomicznych niesionych przez różne rozwiazania ˛ alternatywne. Badania faworyzujace ˛ platformy Microsoftu przedstawiajace ˛ niskie koszty TCO opieraja˛ si˛e w wi˛ekszości (jednak nie wyłacznie) ˛ na założeniu mniejszych kosztów przygotowania personelu, które uzyskiwane sa˛ w istocie wskutek niższych wymagań odnośnie wykształcenia i tym samym niższych podstawowych wynagrodzeń administratorów 10. Inna˛ zalet˛e, która wynika już 10 Opracowanie ICD: „Windows 2000 vs Linux dla zastosowań w przedsi˛ebiorstwach“, 2002 ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 367 jednak z w sumie bardzo dyskusyjnych założeń, upatruje si˛e w obszarze bezpieczeństwa informatycznego, którego implementacja dla platform opartych na produktach Microsoftu wymaga mniejszych nakładów pracy. Do odmiennych całościowych wniosków prowadza˛ badania krytyczne wzgl˛edem produktów Microsoftu. Wprawdzie także tutaj stwierdza si˛e różnic˛e w wynagrodzeniu podstawowym, jest ona jednak z nawiazk ˛ a˛ wyrównywana lepsza˛ jakościa˛ administrowania, zwłaszcza w przypadku pracy centrów obliczeniowych. Dlatego badania przedstawione w ramach poradnika migracyjnego wskazuja˛ na trzy istotne i rozstrzygajace ˛ dla naszych rozważań czynniki, niezb˛edne z punktu widzenia oceny wprowadzania Linux / OSS i oceny kosztów TCO tego przedsi˛ewzi˛ecia. 1. Udział kosztów licencyjnych w sumie kosztów 2. Stopień specjalizacji rozważanych infrastruktur oraz systemów informatycznych 3. Stopień automatyzacji rozważanych infrastruktur oraz systemów informatycznych Udział kosztów licencji na oprogramowanie w sumie kosztów systemów oraz procedur informatycznych wynosi pomi˛edzy 20% a 50%. W przedziale tym mieści si˛e przede wszystkim pośredni i bezpośredni potencjał alternatywnych rozwiazań ˛ OSS oraz COLS, mierzony w wymiarze czysto pieni˛eżnym, z promesa˛ porównywalności uzyskiwanych wyników pracy. Oprócz wypowiedzi dotyczacej ˛ udziału kosztów licencji na oprogramowanie w sumie kosztów ponoszonych na informatyzacj˛e, w procesie ustalania rzeczywistej przestrzeni działania osób dcecydujacych ˛ o informatyzacji pomaga ocena dwóch innych czynników. Pierwszy z nich to indeks kosztów, na które można bezpośrednio wpływać a drugi analiza kosztów oddziałujacych ˛ na budżet. Do kosztów, na które można bezpośrednio wpływać zalicza si˛e: 1. Koszty uzyskania oprogramowania: głównie poprzez przejście na tańsze produkty albo uzyskanie niższych cen w procesie negocjacji 2. Koszty administrowania: głównie poprzez konsolidacj˛e (redukcj˛e ilości produków) oprogramowania albo rezygnacj˛e z uktualizacji 3. Koszty uzyskania osprz˛etu: poprzez przejście na tańsze platformy sprz˛etowe ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 368 4. Koszty administrowania osprz˛etem: poprzez konsolidacj˛e (redukcj˛e ilości produktów) osprz˛etu albo wydłużenie cyklów życia. W przeciwieństwie do oprogramowania i osprz˛etu, najwi˛ekszy blok wydatków na informatyzacj˛e, tj. koszty osobowe, nie sa˛ liczone do kosztów, na które można bezpośrednio wpływać. Wynika to przede wszystkim z faktu, że wprowadzenie i użytkowanie infrastruktur oraz systemów informatycznych zwiazane ˛ jest z podstawowym obciażeniem ˛ wynikajacym ˛ w mniejszym stopniu z poszczególnych modeli licencjonowania, lecz raczej z takich czynników jak: intensywność administrowania, niezawodność i bezpieczeństwo użytkowanych platform. Redukcja istniejacych ˛ zasobów ludzkich albo ich przeorganizowanie (Outsourcing) i konsolidacja, z reguły nie stanowi szybkiej, alternatywnej drogi post˛epowania. W ocenie kosztów informatyzacji, na które można bezpośrednio wpływać wyraźnie widać, że koszty licencji (uzyskania oprogramowania, administrowania, uaktualnień) stanowia˛ najwi˛esza˛ cz˛eść i tym samym pozostawiaja˛ najwi˛eksze pole do działania. 4.6 Zalecenia migracyjne oparte na ocenie wydajności ekonomicznej Zalecenia migracyjne dotycza˛ nast˛epujacych ˛ scenariuszy: ◦ migracja pełna (dla dużych, średnich i małych urz˛edów) ◦ migracja kontynuacyjna (dla dużych średnich i małych urz˛edów) ◦ migracja cz˛eściowa (migracja punktowa i po stronie serwera) W przedstawionych przykładach11 w dużej cz˛eści pomini˛eto apsekt osprz˛etu. Jeśli posiadany osprz˛et jest nowy (nie starszy niż 2 - 3 lata), wówczas migracj˛e można przeprowadzić bez konieczności jego wymiany. Natomiast w przypadku, gdy osprz˛et jest starszy, wymagana jest dodatkowa inwestycja bez wzgl˛edu na kierunek migracji (Open Source czy Microsoft) 12. W ocenie pieni˛eżnej podstaw˛e stanowi typowy dla urz˛edów, pi˛ecioletni okres użytkowania nabytych dóbr. Ponowne inwestowanie spodziewane jest dopiero po tym czasie. Dotyczy to zarówno migracji w kierunku GNU / Linuksa, jak też migracji kontynuacyjnej (w obszarze produktów Microsoftu). W ciagu ˛ czterech lat od zakupu nie sa˛ liczone dalsze koszty. 11 Patrz rozdział 4.8.6.2 – 4.8.6.7. Dlatego, by zbytnio nie komplikować obliczeń, przy ocenianiu kosztów migracji zrezygnowano z oceny czynnika oprzyrzadowania. ˛ 12 ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 369 Tablica 4.2: Porównanie kosztów przypadajacych ˛ na użytkowników w przypadku migracji pełnej i kontynuacyjnej U podstaw obliczeń leża˛ założenia cenowe specyficzne dla urz˛edów. W istotnej cz˛eści w obliczeniach tych uwzgl˛edniono jednorazowe ceny zakupu. Równolegle do tego dla ocenianych produktów liczono koszty dzierżawienia Windows oraz MS Office. Porównanie kosztów pełnej i kontynuacyjnej migracji przypadajacych ˛ na użytkowników wskazuje na jednoznaczne zalety migracji do środowiska OSS13. T YP URZ EDU ˛ M IGRACJA PEŁNA M IGRACJA KONTYNUACYJNA mały 50014 ¤ 85015 EUR średni 34016 ¤ 73017 ¤ duży 18018 ¤ 60019 ¤ Koszty migracji kontynuacyjnej sa˛ około dwa razy wi˛eksze od kosztów pełnej migracji. Mniejsze koszty pełnej migracji wynikaja˛ przede wszystkim z zaoszcz˛edzonych wydatków na oprogramowanie (pomi˛edzy 92% a 95% w każdym z w/w urz˛edów, tj. od małych do dużych). Natomiast porównanie kosztów osobowych pokazuje, że ta forma migracji w ocenianych, małych / średnich / dużych urz˛edach jest korzystniejsza odpowiednio o około 14,0% / 6,5% i 2,2 %. Tendencja ta rozwija si˛e w przypadku obydwu form migracji niemal jednakowo i wykazuje wzrost kosztów wraz ze zmniejszajac ˛ a˛ si˛e wielkościa˛ organizacji! 13 Migracja do środowiska OSS określona została jako „Migracja pełna“. Patrz rozdział „Pełna migracja“, podrozdział „Mała instalacja“ 15 Patrz rozdział „Migracja kontynuacyjna“, podrozdział „Mała instalacja“ 16 Patrz rozdział „Pełna migracja“, podrozdział „Średnia instalacja“ 17 Patrz rozdział „Migracja kontynuacyjna“, podrozdział „Średnia instalacja“ 18 Patrz rozdział „Pełna migracja“, podrozdział „Duża instalacja“ 19 Patrz rozdział „Migracja kontynuacyjna“, podrozdział „Duża instalacja“ 14 ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 370 Rysunek 4.3: Rozwój kosztów migracji 4.6.1 Migracja pełna Przykładowe obliczenia zasadniczo pokazuja˛ dominujacy ˛ udział kosztów osobowych, który wynosi mniej wi˛ecej 90% (około 97% - 93%). Dla różnego typu urz˛edów otrzymujemy nast˛epujacy ˛ procentowy rozkład kosztów migracji. T YP O PROGRAMOWANIE P ERSONEL mały do 7% do 93% średni do 10% do 90% duży do 13% do 87% URZ EDU ˛ Tablica 4.4: Rozkład kosztów w przypadku „migracji pełnej“ w urz˛edach Oszcz˛edności obliczone w niniejszym modelu sa˛ nakładami ponoszonymi każdorazowo w przypadku migracji do środowiska Windows 2000. T YP URZ EDU ˛ PODSTAWA ( CENA - ZAKUP JEDNORAZOWA ) ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ mały 500 ¤ średni 340 ¤ duży 180 ¤ 371 20 Tablica 4.6: Całkowite koszty migracji przypadajace ˛ na użytkownika w przypadku migracji pełnej Pełna migracja w przypadku dużych urz˛edów oznacza ponadprzeci˛etny efekt oszcz˛ednościowy. Oszcz˛edności w przypadku migracji z Windows NT do Linuksa, w przeciwieństwie do migracji do Windows 2000, przekraczaja˛ trzykrotność nakładów. Koszty osobowe wynikajace ˛ z tej zmiany mieszcza˛ si˛e w porównwalnych rz˛edach wielkości, zatem duża cz˛eść oszcz˛edności pochodzi z braku konieczności poniesienia kosztów licencyjnych. Przedstawione efekty oszcz˛ednościowe każa˛ zastanowić si˛e nad migracja˛ do Open Source. W obszarze średnich i małych urz˛edów mamy do czynienia zasadniczo ze scenariuszem zbliżonym do tego z dużych urz˛edów. Także w tym przypadku okazuje si˛e, że migracja do Open Source jest ze wszech miar godna polecenia. 4.6.2 Migracja kontynuacyjna W przypadku tego rodzaju migracji nie można zidentyfikować i porównać oszcz˛edności. Dlatego poniżej zamieszczamy jedna˛ prezentacj˛e zakresu kosztów zwiazanych ˛ z tym scenariuszem. T YP URZ EDU ˛ P ODSTAWA ( CENA ZAKUP JEDNORAZOWA ) P ODSTAWA - ZAKUP DZIER ŻAWA mały 850 ¤ 1.860 ¤ średni 730 ¤ 1.740 ¤ duży 600 ¤ 1.600 ¤ 21 20 Całkowite koszty migracji zawieraja˛ wszystkie nakłady zwiazane ˛ z zamienianymi systemami w ocenianym, pi˛ecioletnim przedziale czasu. Wszystkie dane sa˛ danymi przybliżonymi. 21 Całkowite koszty migracji zawieraja˛ wszystkie nakłady zwiazane ˛ z zamiana˛ systemów w ocenianym, pi˛eciolet- ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 372 Tablica 4.8: Całkowite koszty migracji przypadajace ˛ na użytkownika w przypadku migracji kontynuacyjnej Wraz ze wzrostem ilości użytkowników migracja staje si˛e bardziej opłacalna. W tym przypadku, zgodnie z przedstawionym modelem, przejście z cen zakupu na ceny dzierżawy 22 nie opłaca si˛e. 4.6.3 Migracja cz˛eściowa 4.6.3.1 Migracja punktowa Niniejsza forma migracji dotyczy trwałego zastapienia ˛ wybranego składnika systemu wewnatrz ˛ istniejacej ˛ struktury informatycznej. Przykładem migracji cz˛eściowej może być przejście z Exchange 5.5 na Samsung Contact. Migacj˛e t˛e można zalecić urz˛edom każdego typu, z zastrzeżeniem, że w poszczególnym przypadku możliwe jest zastapienie ˛ wymaganych funkcji, ponieważ w przeciwieństwie do migracji z wykorzystaniem produktów Microsoftu przedstawia ona wymierne korzyści finansowe23. T YP URZ EDU ˛ P ODSTAWA - ZAKUP ( CENA JEDNORAZOWA ) mały 99 ¤ średni 153 ¤ duży 39 ¤ Tablica 4.10: Całkowite koszty migracji przypadajace ˛ na użytkownika w przypadku migracji punktowej Z tablicy cen oprogramowania firmy Samsung wynikaja˛ zaprezentowane powyżej rozpi˛etości kosztów migracji przypadajace ˛ na użytkownika. nim przedziale czasu. Wszystkie dane sa˛ danymi przybliżonymi. 22 Ceny dzierżawy produktów MS Windows i MS Office były znane, stad ˛ też uwaga „W tym przypadku“. 23 Kosztom migracji do Samsung Contact przeciwstawiane sa,˛ jako oszcz˛edności, koszty migracji do Exchange2000. Różnic˛e stanowia˛ w każdym przypadku dodatnie wartości kapitału, które wskazuja˛ na odpowiednie korzyści finansowe. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ T YP 373 O PROGRAMOWANIE P ERSONEL mały do 35% do 65% średni do 21% do 79% duży do 56% do 44% URZ EDU ˛ Tablica 4.12: Rozłożenie kosztów migracji Podział kosztów na oprogramowanie i personel waha si˛e w granicach 50% na 50%. W zależności od stopnia zaangażowania obsługi w procesy migracyjne udział ten może si˛e zmieniać. Nakład przyj˛ety tu za podstaw˛e jest równy nakładowi koniecznemu dla przeprowadzenia migracji do Exchange 2000. Ponieważ jednak z doświadczenia wynika, że może on być niższy, stad ˛ realistyczny udział kosztów osobowych migracji wyniesie raczej mniej niż 50%. 4.6.3.2 Migracja cz˛eściowa po stronie serwera Niniejsza migracja cz˛eściowa przeprowadzana po stronie serwera jest cz˛eścia˛ migracji pełnej. Jako alternatywa dla pełnej migracji ta forma zast˛epowania systemu zapewnia bardzo wysoka˛ wydajność, jeśli chodzi o kryterium pilności, jakości i strategii, gdyż istotna cz˛eść projektu migracyjnego ma miejsce na serwerze przy uwzgl˛ednieniu tychże kryteriów. Koszty kształtuja˛ si˛e na poziomie około 120 ¤, tj. poniżej kosztów ustalonych w przypadku migracji pełnej (patrz poniższa 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 także dzi˛eki temu, że zapewnia ona łagodne, ledwo zauważalne i nieodczuwalne przez użytkowników przejście do świata Otwartego Oprogramowania. T YP URZ EDU ˛ P ODSTAWA - ZAKUP ( CENA JEDNORAZOWA ) mały 370 ¤ średni 220 ¤ duży 65 ¤ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 374 2425 Tablica 4.14: Całkowite koszty migracji przypadajace ˛ na użytkownika w przypadku migracji cz˛eściowej po stronie serwera. Koszty migracji dotycza˛ tu wprawdzie tylko serwerów, jednak odniesiono je do innych kosztów i przeliczono na ilość użytkowników pracujacych ˛ w ocenianych typach urz˛edów. T YP URZ EDU ˛ M IGRACJA PEŁNA M IGRACJA CZ E˛ŚCIOWA U DZIAŁ KLIENTÓW PO STRONIE SERWERA W MIGRACJI PEŁNEJ mały 500 ¤ 370 ¤ 129 ¤ średni 340 ¤ 220 ¤ 120 ¤ duży 180 ¤ 65 ¤ 116 ¤ Tablica 4.16: Całkowite koszty migracji przypadajace ˛ na użytkownika w przypadku migracji cz˛eściowej po stronie serwera. Rysunek 4.4: Koszty migracji przypadajace ˛ na użytkownika Rozwój kosztów w przypadku szerokiej migracji potwiedza wcześniej ustalony trend, czyli zmniejszanie si˛e ich wraz ze wzrostem wielkości organizacji. W porównaniu z migracja˛ pełna,˛ udział kosztów przypadajacych ˛ na przestawienie stacji klienckich jest wzgl˛ednie stały. 4.7 Wnioski Porównanie ekonomicznych aspektów różnego rodzaju migracji przemawia jednoznacznie na korzyść migracji cz˛eściowej po stronie serwera. Jeśli urzad ˛ zdecyduje si˛e na zasadnicze przejście z wykorzystywanego systemu na Open Source, wówczas z ekonomicznych powodów zaleca 24 Całkowite koszty migracji zawieraja˛ wszystkie nakłady zwiazane ˛ z zamienianymi systemami w ocenianym, pi˛ecioletnim przedziale czasu. Wszystkie dane sa˛ danymi przybliżonymi. 25 Wszystkie dane sa˛ danymi przybliżonymi. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 375 si˛e obranie tej drogi post˛epowania. Szeroka migracja po stronie serwera (jako wariant, wzgl˛ednie wst˛ep do migracji pełnej) poświ˛eca szczególna˛ uwag˛e specyficznym dla urz˛edów interesom realizowanym po stronie klienta i tym samym przyczynia si˛e do wydajniejszej i trwałej zmiany platformy informatycznej. Jeśli urzad ˛ zdecyduje si˛e na pozostanie przy systemach opartych o produkty Microsoftu, wówczas sposób migracji wytyczać b˛edzie migracja kontynuacyjna. Obydwa sposoby post˛epowania migracyjnego, tj. migracja pełna, jak też punktowa, sa˛ z ekonomicznych punktów widzenia optymalne. W zależności od specjalnych wymagań urz˛edów i / lub podejmowanych tam decyzji, w/w sposoby moga˛ si˛e okazać jak najbardziej właściwa˛ droga˛ post˛epowania26. 4.8 Nakłady według różnych scenariuszy migracji 4.8.1 Ogólne założenia dotyczace ˛ nakładów zwiazanych ˛ z migracja˛ Całkowite koszty ocenianych tu migracji składaja˛ si˛e zasadniczo z: ◦ koszów osprz˛etu ◦ koszów oprogramowania ◦ kosztów osobowych W niniejszym rozdziale pokażemy możliwe zakresy kosztów osobowych i objaśnimy ich cz˛eści składowe. Aspekt osprz˛etu został pomini˛ety27 a koszty oprogramowania uwzgl˛edniono w poszczególnych przykładach28. Ocena nakładów zamieszczona w niniejszym poradniku może być tylko zgrubnym szacunkiem, ponieważ nie jest (nie może być) dokładnie znany ani punkt wyjścia, ani oczekiwany scenariusz migracji. Z tego powodu przykładowo ocenione zostały trzy różne scenariusze. Przypi29 sano je odpowiednio do przedstawionych wcześniej trzech przykładowych urzadów ˛ . W dalszej cz˛eści zgrubnie nakreślono każde z tych trzech środowisk. Dla wszystkich środowisk przyj˛eto nast˛epujace ˛ założenia: 26 W niektórych przypadkach urzad ˛ zmuszony jest, np. wskutek korzystania z niedajacych ˛ si˛e przeportować specjalistycznych aplikacji, do dalszego korzystania z systemów Microsoftu. W innych przypadkach warunki po stronie serwerów i klientów moga˛ wymagać migracji w jej pełnej formie. 27 Patrz rozdział „Zalecenia migracyjne . . . „ 28 Patrz rozdział „Zalecenia odnośnie oceny produków / grup produktów“ 29 Urz˛edy małe, średnie i duże ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 376 ◦ migracja po stronie serwerów zachodzi wraz z wymiana˛ osprz˛etu (nowe serwery) ◦ stacje robocze sa˛ urzadzeniami ˛ pracujacymi ˛ pod Windows NT 4 (tym samym nie jest brana pod uwag˛e koncepcja grupowych wytycznych dla systemów desktopowych) ◦ dotychczasowe środowisko jest w „dobrym“ stanie, wzgl˛ednie nie chce si˛e wprowadzać Windows 2000 jako pierwszoplanowego systemu w celu odci˛ecia si˛e od starych obciażeń; ˛ wobec tego zakłada si˛e przede wszystkim, że nie jest odrzucana tak zwana „migracja inplace“ (aktualizacja istniejacej ˛ domeny NT). ◦ istnieje uniwersalny techniczny system zarzadzania, ˛ którego narz˛edzia nadaja˛ si˛e także dla Windows 2000 ◦ istnieje udokumentowany plan pracy, który można rozwijać ◦ całościa˛ środowisk suwerennie opiekuje si˛e i odpowiada za nie organizacja, która przeważnie działa centralnie ◦ straty zwiazane ˛ z przerwami w pracy wynikajacymi ˛ z wewn˛etrznych, politycznych niezgodności i niedoborów budżetowych sa˛ minimalne. Ponadto należy wziać ˛ pod uwag˛e nast˛epujace ˛ rozgraniczenia: ◦ migracja stacji roboczych do Windows 2000 / XP nie jest oceniana ◦ migracja z Windows Terminal Services nie jest oceniana ◦ nie należy brać pod uwag˛e migracji z DFS lub wprowadzenia DFS ◦ nie jest brana pod uwag˛e migracja serwerów aplikacji takich jak: MS Exchange, MS SQL, MS SNA Server, MS Proxy albo aplikacji innych producenów, jak również klastry serwerów NT (Enterprise Edition) z ewentualnymi zewn˛etrznymi jednostkami pami˛eci (podsystemy twardych dysków badź ˛ SAN) Oceniany model obejmuje sześć etapów i można określić go w kilku punktach: ◦ Warsztat (Kick Off, dopuszczenie konkretnych specjalistycznych działów i gał˛ezi IT, identyfikacja wszystkich ważnych zagadnień, określenie priorytetów, identyfikacja obszarów decyzyjnych, ustalenie sposób post˛epowania i planu projektu, szczegółowe określenie nakładów, określenie projektów cz˛eściowych i przypisanie ich do grup roboczych) ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 377 ◦ Ustalenie stanu faktycznego (środowisko oplikacji, zależności komunikacyjne, infrastruktura sieci, usługi centralne, sposób użytkowania, przyszłe wymagania) ◦ Ogólna koncepcja (założonie zeszytu z rozpisanymi obowiazkami, ˛ uszczegółowienie planu projektu i zdefiniowanie pakietów roboczych , możliwości technicznych, zbudowanie środowiska integrujacego ˛ i testowego, rozrysowanie pozostałego środowiska produkcyjnego, zintegrowanie aplikacji, wybór osprz˛etu i jego sposobu jego zastapienia) ˛ ◦ Dokładna koncepcja (szczegółowe ustalenie zakresu funkcji, integracja z pozostałym środowiskiem informatycznym, stworzenie procedur instalacji i przydział oprogramowania, zintegrowanie prac, zaplanowanie Rollout, zaplanowanie pilota, przeszkolenie personelu pracujacego ˛ z danymi) ◦ Pilot (Feature Stop, zorganizowanie reprezentatywnej grupy użytkownikó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, rozmnożenie serwerów, przekazanie informacji użytkownikom i ich przeszkolenie, sprawowanie opieki przez zespół wdrażajacy ˛ projekt, przekazanie systemu do normalnego użytkowania). Ponadto należy przewidzieć zarzadzanie ˛ projektem. 4.8.2 Nakłady na migracj˛e z Windows NT do Windows 2000 Poniżej przedstawione zostana˛ nakłady na migracj˛e, które trzeba ponieść podczas przechodzenia, w nast˛epujacych ˛ obszarach, z Windows NT 4 do Windows 2000: ◦ usługi logowania ◦ usługi sieciowe ◦ zarzadzanie ˛ plikami ◦ drukowanie. Migracj˛e do Windows 200030 razem z Active Directory można podzielić na różne etapy zawierajace ˛ pakiety działań. Poniższa tabela w punktach przedstawia oceniane scenariusze. 30 Migracja z Windows NT do Windows 2000 nazywana jest dalej „migracja˛ kontynuacyjna“. ˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ K ATEGORIA I LO Ś Ć U ŻYTKOWNIKÓW P UNKT WYJ ŚCIA 378 S CENARIUSZ PROWADZ ACY ˛ DO CELU małe do 250 domena NT z jedna domena dwoma kontrolerami Windows 2000 domeny, które dodatkowo jedno stanowisko udost˛epniaja˛ WINS, DNS dwa serwery plików i DHCP dwa serwery wydruku jedno stanowiskoo dwa serwery plików dwa serwery wydruku średnie trzy ufajace ˛ sobie domeny jedna domena NT każdorazowo z kontami Windows 2000 komputerów i użytkowników trzy stanowiska Kontrolery domen dodatkowo nadal dwa serwery powyżej 250 - udost˛epniaja˛ WINS, DNS plików i dwa serwery do 1000 trzy stanowiska o podobnej wydruku na każdym wielkości (ilość użytkowniów) stanowisku każda z trzech domen dysponuje dwoma serwerami plików i dwoma serwerami wydruku duże powyżej 1000 11 domen w modelu jedna domena Single - Muster (1 domena kont Windows 2000 i 10 domen zasobów) dziesi˛eć stanowisk Kontrolery domen udost˛epniaja˛ nadal dwa serwery dodatkowo WINS, DNS plików i dwa i DHCP serwery wydruku 10 stanowisk na stanowisko 10 domen, każda z dwoma serwerami plików i dwoma serwerami wydruku Tablica 4.18: Opis scenariuszy migracji z Windows NT do Windows 2000 ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 379 Scenariusze docelowe dotyczace ˛ dużych i średnich środowisk zaw˛eżaja˛ ilość domen do jednej. We wszystkich trzech środowiskach przyj˛eto założenie, że aktualizowana jest przynajmniej jedna dotychczasowa domena (Inplace - Upgrade). Założenie to należy traktować jako prototyp pomysłu na migracj˛e i jej cel, oznacza ono jednak uproszczenie ścieżki migracji wskutek wyeliminowania dodatkowych nakładów migracyjnych zwiazanych ˛ z kontami użytkowników (w skrócie: klonowanie, SID-history, przydzielanie nowych uprawnień (ReACLing)). Ocenia si˛e, że dla różnych środowisk i na różnych etapach konieczne sa˛ nast˛epujace ˛ nakłady liczone w dniach pracy na osob˛e. NAKŁAD W DNIACH etap pakiet działań Warsztat Ustalenie stanu logowanie faktycznego i sieć pomysł na zarzadzanie ˛ U WAGI Ś RODOWISKO PRACY NA OSOB E˛ małe średnie duże 5 10 10 ryczałtem 2 6 22 2 na domen˛e 1 5 21 1 na pierwsza˛ domen˛e plikami 2 na każda˛ kolejna˛ domen˛e zasobów (ResDom) pomysł na drukowanie 2 6 20 2 na każda˛ ResDom 2 na pierwsza˛ domen˛e procedura 2 4 12 migracyjna Ogólna koncepcja 1 dla każdej kolejnej domeny zasobów (ResDom) wymagania 1 3 10 1 na stanowisko zeszyt z obowiazkami ˛ 2 4 6 ryczałtem plan projektu 1 3 10 1 na stanowisko budowa środowiska testowego ryczałtem 2 3 5 7 plus dodatkowe stanowiska / domeny wybór osprz˛etu 5 5 5 pomysł na Active Dokładna koncepcja Directory (razem z ryczałtem 5 na jedna˛ domen˛e docelowa˛ 5 8 15 plus 1 na stanowisko 1 11 51 1 na domen˛e docelowa˛ usługami sieciowymi pomysł na zarzadzanie ˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 380 plikami pomysł na drukowanie plus 5 na dodatkowe ResDom 3 5 13 ryczałtem 3 plus 1 na dodatkowe ResDom instalacja 3 3 3 procedura migracyjna ryczałtem ryczałtem 3 3 13 13 plus czynnik poziomu skomplikowania zarzadzanie ˛ systemem (backup, ochrona przed 4 centralny 4 8 8 4 niecentralny pomysł na prac˛e 10 20 40 ryczałtem planowanie 2 6 20 2 na stanowisko 10 25 25 10 centralny wirusami, odzyskiwanie danych po awarii, nadzór) Pilot 10 niecentralny Rolluot 5 25 105 5 na piersza˛ domen˛e docelowa˛ 10 na ResDom Suma 70 175 416 Tablica 4.20: Nakłady na personel w przypadku migracji kontynuacyjnej Do tego należy doliczyć jeszcze 10% dla wszystkich środowisk na kierowanie projektem. Przedstawione szacunkowe nakłady należy interpretować jako dolne granice. W każdym z pakietów działań można zdefiniować duże dodatkowe nakłady, jeśli w zeszycie z obowiazkami ˛ wymagania zostana˛ odpowiednio sformułowane albo rozszerzone. Jako przykład podać można wpis o stworzeniu badź ˛ rozwini˛eciu pomysłu na prac˛e. Wyliczona ilość dni na osob˛e dotyczy nakładów wewn˛etrznych i zewn˛etrznych. W przypadku opisanej tu migracji z Windows proporcje wynosza˛ 20% dla nakładów wewn˛etrznych i 80% dla nakładów zewn˛etrznych. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 381 4.8.3 Nakłady na migracj˛e z Windows NT do Linuksa Nast˛epujaca ˛ tabela w punktach przedstawia oceniane scenariusze 31 . KATEGORIA ILO Ś Ć PUNKT WYJ ŚCIA U ŻYTKOWNIKÓW małe do 250 1 SCENARIUSZ 2 SCENARIUSZ PROWADZ ACY ˛ DO CELU PROWADZ ACY ˛ DO CELU jedna domena z dwoma jedna domena domena - Samba kontrolerami domeny, Windows 2000 jedno stanowisko które udost˛epniaja˛ jedno stanowisko dwa serwery plików dodatkowo WINS, DNS dwa serwery plików dwa serwery wydruku i DHCP dwa serwery wydruku jedno stanowisko dwa serwery plików dwa serwery wydruku średnie trzy ufajace ˛ sobie jedna domena domena - Samba / LDAP domeny NT każdorazowo Windows 2000 trzy stanowiska z kontami komputerów trzy stanowiska nadal dwa serwery i użytkowników nadal z dwoma plików i dwa serwery Kontrolery domen serwerami plików wydruku na stanowisku udost˛epniaja˛ dodatkowo i dwoma serwerami powyżej 250 - WINS, DNS i DHCP wydruku na każdym do 1000 trzy stanowiska o stanowisku podobnej wielkości (ilości użytkowników) Każda z trzech domen z dwoma serwerami plików i dwoma serwerami wydruku duże 31 powyżej 1000 11 domen w modelu jedna domena domena - Samba / LDAP Singel - Master Windows 2000 dziesi˛eć stanowisk (1 domena kont dziesi˛eć 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 udost˛epniaja˛ dodatkowo serwery wydruku Niniejsza migracja nazywana jest dalej „migracja˛ zast˛epujac ˛ a“. ˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ WINS, DNS i DHCP 382 na stanowisku 10 stanowisk 10 domen, każda z dwoma serwerami plików i dwoma serwerami wydruku Tablica 4.22: Opis scenariusza dla migracji z Windows NT do Linuksa Scenariusze docelowe dotyczace ˛ dużych i średnich środowisk zaw˛eżaja˛ ilość domen do jednej. We wszystkich trzech środowiskach przyj˛eto założenie, że aktualizowana jest przynajmniej jedna dotychczasowa domena (Inplace - Upgrade). Założenie to należy traktować jako prototyp pomysłu na migracj˛e i jej cel, oznacza ono jednak uproszczenie ścieżki migracji wskutek wyeliminowania dodatkowych nakładów migracyjnych zwiazanych ˛ z kontami użytkowników (w skócie: klonowanie, SID-history, przydzielanie nowych uprawnień (ReACLing)). Ocenia si˛e, że dla różnych środowisk i na różnych etapach konieczne sa˛ nast˛epujace ˛ nakłady liczone w dniach pracy na osob˛e. NAKŁAD W DNIACH etap Ś RODOWISKO PRACY NA OSOB E˛ pakiet działań Warsztat Ustalenie stanu logowanie faktycznego i sieć U WAGI małe średnie duże 5 10 10 ryczałtem 2 6 22 2 na domen˛e 1 na pierwsza˛ domen˛e pomysł na zarzadzanie ˛ 1 5 21 plikami Print 2 na każda˛ kolejna˛ domen˛e zasobów (ResDom) 2 6 20 2 na każda˛ ResDom 2 na pierwsza˛ domen˛e procedura 2 4 12 migracyjna Ogólna koncepcja 1 dla każdej kolejnej domeny zasobów (ResDom) wymagania 1 3 10 1 na stanowisko zeszyt z obowiazkami ˛ 2 4 6 ryczałtem plan projektu 1 3 10 1 na stanowisko ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 383 budowa środowiska testowego ryczałtem 2 3 5 7 plus dodatkowe stanowiska / domeny wybór osprz˛etu 5 5 5 pomysł na OpenLDAP Dokładna koncepcja Directory (razem z dla wszytkich 4 na jedna˛ domen˛e docelowa˛ 4 7 14 plus 1 na stanowisko 1 11 51 1 na domen˛e docelowa˛ usługami sieciowymi) pomysł na zarzadzanie ˛ plikami pomysł na drukowanie plus 5 na dodatkowe ResDom 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 migracyjna skomplikowania (Spsoby post˛epowania sa˛ tutaj mniej standaryzowane niż w przypadku migracji kontynuacyjnej, jednak w porównaniu z koncepca˛ szczegółowa˛ należy liczyć si˛e jedynie ze wzgl˛ednie małym wzrostem nakładów.) 6 centralny zarzadzanie ˛ systemem 6 9 9 3 niecentralny (backup, ochrona przed (trzeba tu uzupełnić wirusami, odzyskiwanie rozwiazania ˛ pracujace ˛ danych po awarii, nadzór) z cz˛eścia˛ oprogramowania; wiele z istniejacych ˛ systemów można zastosować także z OSS ryczałtem (W przypadku migracja do ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 384 OSS należy si˛e tu liczyć pomysł na prac˛e 15 25 50 wi˛ekszymi nakładami. Z drugiej strony w migracji do OSS nie chodzi o tworzenie nowego pomysłu na prac˛e) planowanie 2 6 20 2 na stanowisko 20 centralny 30 niecentralny (W przypadku migracji do Pilot 15 30 30 OSS należy tu oczekiwać wyższych nakładów na integracj˛e składników i przeznaczenia pewnej ich na indywidualny rozwój). 5 na piersza˛ domen˛e docelowa˛ 10 na ResDom 5/10/20 na niepewność (Gdy wszystko jest zaplanowane i przetestowane, Rollout 10 35 125 sam Rollout nie wymaga już dużych nakładów. Jednak czynnik niepewności jest wi˛ekszy, wzgl˛ednie tolerancja bł˛edów jest mniejsza niż w przypadku migracji kontynuacyjnej Suma 86 195 451 Tablica 4.24: Nakłady liczone w dniach na osob˛e w przypadku migracji zast˛epujacej ˛ Do tego należy doliczyć jeszcze 10% dla wszystkich środowisk na kierowanie projektem. Przedstawione szacunkowe nakłady należy interpretować jako dolne granice. W każdym z pakietów działań można zdefiniować duże dodatkowe nakłady, jeśli w zeszycie z obowiazkami ˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 385 wymagania zostana˛ odpowiednio sformułowane albo rozszerzone. Jako przykład podać można wpis o stworzeniu badź ˛ rozwini˛eciu pomysłu na prac˛e. Nakłady na tego typu czynności moga˛ być niemal dowolne. 4.8.4 Nakłady na migracj˛e z Exchange 5.5 do Exchange 2000 Poniżej przedstawione zostały nakłady potrzebne do przeprowadzenia migracji z Microsoft Exchange 5.5 do Exchange 2000. Ocenia si˛e, że dla różnych środowisk i na różnych etapach konieczne sa˛ nast˛epujace ˛ nakłady liczone w dniach pracy na osob˛e. NAKŁAD W DNIACH etap pakiet działań Warsztat Ustalenie stanu logowanie faktycznego i sieć środowisko Exchange U WAGI Ś RODOWISKO PRACY NA OSOB E˛ małe średnie duże 2 3 3 ryczałtem 1 1 1 ryczałtem 1 5 21 1 na organizacj˛e 2 na 2 serwery Exchange Ogólna koncepcja procedura migracyjna 2 4 4 ryczałtem wymagania 1 3 3 ryczałtem zeszyt z obowiazkami ˛ 2 4 4 ryczałtem plan projektu 1 3 3 1 centralny 2 niecentralny budowa środowiska testowego ryczałtem 2 3 5 7 plus dodatkowe stanowiska / domeny wybór osprz˛etu 5 5 5 ryczałtem przy klastrach podwoić 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 WYDAJNOŚCI EKONOMICZNEJ instalacja 3 3 386 3 procedura migracyjna ryczałtem ryczałtem 2 2 12 12 plus czynnik poziomu skomplikowania zarzadzanie ˛ systemem (backup, ochrona przed 5 centralny 5 10 10 5 niecentralny pomysł na prac˛e 10 15 25 ryczałtem planowanie 2 6 20 2 na stanowisko 5 10 10 5 centralny wirusami, odzyskiwanie danych po awarii, nadzór) Pilot 5 niecentralny Rolluot 3 9 30 3 na każdy serwer Exchange Suma 64 121 171 Tablica 4.26: Nakłady liczone w dniach na osob˛e: Exchange5.5 –> Exchange2000 Do tego należy doliczyć jeszcze 10% dla wszystkich środowisk na kierowanie projektem. Wyliczona ilość dni na osob˛e dotyczy nakładów wewn˛etrznych i zewn˛etrznych. W przypadku opisanej tu migracji z Exchange proporcje wynosza˛ około 25% dla nakładów wewn˛etrznych i około 75% dla nakładów zewn˛etrznych. 4.8.5 Nakłady na migracj˛e z Exchange 5.5 do Samsung Contact Poniżej przedstawione zostały nakłady potrzebne do przeprowadzenia migracji z Microsoft Exchange 5.5 do Samsung Contact. Zaprezentowane tu założenia dotycza˛ wszystkich środowisk (opartych na Samsung Contact). ◦ wszystkie serwery Samsung Contact oparte sa˛ na systemach linuksowych albo systemach Unix OS. ◦ możliwa jest konsolidacja wielu serwerów MS Exchange. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 387 ◦ ilość użytkowników zależy tylko od wydajności CPU. Nie istnieja˛ ograniczenia rozmiaru skrzynki pocztowej. Dane moga˛ być gromadzone w ilości wielu terabajtów. ◦ nie jest potrzebna migracja do ADS. ◦ system oszcz˛edza zasoby, stad ˛ w przypadku migracji można nadal korzystać z istniejacego ˛ osprz˛etu (Linux). ◦ istnieje możliwość migracji publicznych katalogów, kalendarza i kontaktów. NAKŁAD W DNIACH etap Ś RODOWISKO PRACY NA OSOB E˛ U WAGI pakiet działań małe średnie duże Ustalenie stanu logowanie 0,2 0,2 0,2 faktycznego i sieć Środowisko Exchange 0,2 0,5 1 procedura 0,2 0,5 1 wymagania 0,2 0,5 1 zeszyt z obowiazkami ˛ 1 2 3 plan projektu 0,5 1 1 budowa środowiska 1 2 5 wybór osprz˛etu 0,3 0,3 0,5 pomysł na Contact 0,5 0,3 0,5 test ADC 0,5 0,5 1 procedura instalacyjna 0,5 0,5 1 procedura 0,2 0,3 1 1 1 2 pomysł na prac˛e 1 2 2 planowanie 0,5 0,5 0,5 Warsztat Ogólna koncepcja testowego Dokładna koncepcja projekt serwera migracyjna zarzadzanie ˛ systemem (backup, ochrona przed wirusami, odzyskiwanie danych po awarii, nadzór) ROZDZIAŁ 4. OCENA WYDAJNOŚCI 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 osob˛e: Exchange5.5 –> Samsung Contact 4.8.6 Zalecenia odnośnie sposobu oceny produktów / grup produktów 4.8.6.1 Generalne założenia ◦ W obliczeniach podanych w przykładowych scenariuszach dla różnych obiektów migracji ocenione zostały wyłacznie ˛ generatory kosztów i generatory korzyści: – koszty osprz˛etu – koszty oprogramowania – koszty przenoszenia danych (= koszty osobowe) ◦ Na tym tle uznano wszelkie inne wyst˛epujace ˛ jeszcze koszty za neutralne: – koszty zapewnienia kompatybilności – koszty szkolenia – koszty administrowania ◦ Projekty migracyjne sa˛ na ogół wyposażone tylko w niewielki własny potencjał oszcz˛ednościowy (koszty oprogramowania). Pozwala on jedynie w rzadkich przypadkach wykazać rentowność przedsi˛ewzi˛ecia. Ponieważ w w tle przedsi˛ewzi˛ecia migracyjnego zasadniczo znajduje si˛e wybór pomi˛edzy migracja˛ wewnatrz ˛ platformy Microsoftu albo migracja˛ do platformy OSS, w poniższych przykładach dokonano „oceny na krzyż“. W tym celu w przypadku migracji do OSS wliczono po stronie oszcz˛edności niewymagane, porównywalne nakłady b˛edace ˛ różnica˛ przypadajac ˛ a˛ na migracj˛e w ramach platformy Microsoft. ◦ W przypadku zewn˛etrznych kosztów osobowych przyj˛eto średnia˛ dniówk˛e wynoszac ˛ a˛ 1.000 ¤. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 389 ◦ Za podstaw˛e oceny kosztów osobowych przyj˛eto informacje dla najwyższych urz˛edów federalnych32. Obliczenie kosztów wykonano na podstawie stawki wynagrodzenia poziomu IVa (najwyższe urz˛edy federalne, 36,98 ¤na godzin˛e, 462 minuty na dzień. ◦ Podane przykładowo koszty przypadajace ˛ na osob˛e dla dużych, średnich i małych urz˛edów każdorazowo dzielone były w proporcji 80 / 20 na zasoby zewn˛etrzne i wewn˛etrzne. ◦ Dla oprocentowania przyszłych oszcz˛edności użyto stopy procentowej BMF 33 (obecnie 6%). ◦ Licencje na oprogramowanie dla urz˛edów wynosza˛ około 50% z normalnych cenników 34. Warunki takie sa˛ powszechnie stosowane przez dostawców Aby oddzielnie pokazać różne możliwości oceny ekonomicznej, zaprezentujemy w nast˛epujacych ˛ przykładach dwie struktury: ◦ struktura WiBe21 oparta na zdefiniowanych katalogach kryteriów ◦ struktura katogorii kosztów informatyzacji oparta na trzech głównych blokach kosztów, tj. osprz˛etu, oprogramowania i osobowych odpowiednio do matrycy kosztów migracji. 4.8.6.2 Przykłady według struktury WiBe21 M IGRACJA P RZEDMIOT MIGRACJI Z ŚRODOWISKA M ICROSOFT W INDOWS NT OSS – NA KLIENTY DO I SERWERY LINUKSOWE 32 Przykładowy scenariusz mały urzad, ˛ 250 użytkowników Wyznaczniki sukcesu koszty oprogramowania, koszty zastapienia ˛ oprogramowania Patrz „Stopy kosztów osobowych dla sporzadzania ˛ rachunków kosztów / rachunków wydajności ekonomicznej“ Federalne Ministerstwo Finansów, 29 października 2002 r. 33 Patrz „Stopy kosztów osobowych . . . “ Federalnego Ministerstwa Finansów z 29 października 2002 r. 34 W pojedynczych przypadkach należy liczyć si˛e z innymi cenami, jeśli trafniej przedstawiaja˛ one realna˛ sytuacj˛e w urz˛edach. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ ◦ generatorami koszów / korzyści sa˛ trzy kryteria – koszty licencji – koszty zastapienia ˛ oprogramowania – koszty szkolenia ◦ Na tym tle uznano wszelkie inne wyst˛epujace ˛ jeszcze koszty za neutralne i tym samym w przykładowym wyliczeniu wzi˛eto pod uwag˛e tylko w/w generatory kosztów / korzyści. ◦ W przykład wliczono po stronie oszcz˛edności różnic˛e wynikajac ˛ a˛ z nie branych pod uwag˛e nakładów na przejście z MS Windows NT do Linuksa. Dotyczy to licencji na oprogramowanie i kosztów zastapienia ˛ oprogramowania. Licencje na oprogramowanie: Po stronie oszcz˛edności liczono tu licencj˛e na Windowsa jako różnic˛e w porównaniu do bezpłatnego Linuksa. Założenia Koszty zastapienia ˛ oprogramowania: Po stronie oszcz˛edności wpisano różnic˛e pomi˛edzy nakładami liczonymi w dniach roboczych na osob˛e w przypadku migracji wewnatrz ˛ platformy Microsoft a migracji do Linuksa. Różnica ta obliczona została na podstawie średniej, zewn˛etrznej stopy kosztów osobowych wynosza˛ cej 1.000 ¤. Wewn˛etrzne, zaoszcz˛edzone dni robocze na osob˛e, rozliczone zostały w oparciu o stopy Federalnego Ministerstwa Finansów. ◦ Nakłady na szkolenia użytkowników sa˛ 390 ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ Break-even 391 Projekt spłaca si˛e już 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 powyżej przykładu WiBe wynika dodatnia wartość kapitału przy założeniu, że zewn˛etrzne wsparcie migracji nie przekroczy 28 dni roboczych na osob˛e a konieczne przy tym wsparcie wewn˛etrzne nie przekroczy 7 dni roboczych na osob˛e. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ M IGRACJA P RZEDMIOT MIGRACJI Z ŚRODOWISKA 392 M ICROSOFT W INDOWS NT OSS – NA KLIENTY DO I SERWERY LINUKSOWE Przykładowy scenariusz Wyznaczniki sukcesu średni urzad, ˛ 1.000 użytkowników koszty oprogramowania, koszty zastapienia ˛ oprogramowania ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ ◦ generatorami koszów / korzyści sa˛ trzy kryteria – koszty licencji – koszty zastapienia ˛ oprogramowania – koszty szkolenia ◦ Na tym tle uznano wszelkie inne wyst˛epujace ˛ jeszcze koszty za neutralne i tym samym w przykładowym wyliczeniu wzi˛eto pod uwag˛e tylko w/w generatory kosztów / korzyści. ◦ W przykład wliczono po stronie oszcz˛edności różnic˛e wynikajac ˛ a˛ z nie branych pod uwag˛e nakładów na przejście z MS Windows NT do Linuksa. Dotyczy to licencji na oprogramowanie i kosztów zastapienia ˛ oprogramowania. Licencje na oprogramowanie: Po stronie oszcz˛edności liczono tu licencj˛e na Windowsa jako różnic˛e w porównaniu do bezpłatnego Linuksa. Założenia Koszty zastapienia ˛ oprogramowania: Po stronie oszcz˛edności wpisano różnic˛e pomi˛edzy nakładami liczonymi w dniach roboczych na osob˛e w przypadku migracji wewnatrz ˛ platformy Microsoft a migracji do Linuksa. Różnica ta obliczona została na podstawie średniej, zewn˛etrznej stopy kosztów osobowych wynosza˛ cej 1.000 ¤. Wewn˛etrzne, zaoszcz˛edzone dni robocze na osob˛e, rozliczone zostały w oparciu o stopy Federalnego Ministerstwa Finansów. ◦ Nakłady na szkolenia użytkowników sa˛ 393 ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ Break-even 394 Projekt spłaca si˛e już w pierwszym roku. Tablica 4.33: Przykład migracji: infrastruktura serwerów – średni urzad ˛ Przykład migracji: infrastruktura serwerów – średni urzad ˛ Tablica 4.34: 2 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), średni urzad ˛ Z przedstawionego powyżej przykładu WiBe wynika dodatnia wartość kapitału przy założeniu, że zewn˛etrzne wsparcie migracji nie przekroczy 76 dni roboczych na osob˛e a konieczne przy tym wsparcie wewn˛etrzne nie przekroczy 19 dni roboczych na osob˛e. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ M IGRACJA P RZEDMIOT MIGRACJI Z ŚRODOWISKA 395 M ICROSOFT W INDOWS NT OSS – NA KLIENTY DO I SERWERY LINUKSOWE Przykładowy scenariusz Wyznaczniki sukcesu duży urzad, ˛ 10.000 użytkowników koszty oprogramowania, koszty zastapienia ˛ oprogramowania ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ ◦ generatorami koszów / korzyści sa˛ trzy kryteria – koszty licencji – koszty zastapienia ˛ oprogramowania – koszty szkolenia ◦ Na tym tle uznano wszelkie inne wyst˛epujace ˛ jeszcze koszty za neutralne i tym samym w przykładowym wyliczeniu wzi˛eto pod uwag˛e tylko w/w generatory kosztów / korzyści. ◦ W przykład wliczono po stronie oszcz˛edności różnic˛e wynikajac ˛ a˛ z nie branych pod uwag˛e nakładów na przejście z MS Windows NT do Linuksa. Dotyczy to licencji na oprogramowanie i kosztów zastapienia ˛ oprogramowania. Licencje na oprogramowanie: Po stronie oszcz˛edności liczono tu licencj˛e na Windowsa jako różnic˛e w porównaniu do bezpłatnego Linuksa. Założenia Koszty zastapienia ˛ oprogramowani: Po stronie oszcz˛edności wpisano różnic˛e pomi˛edzy nakładami liczonymi w dniach roboczych na osob˛e w przypadku migracji wewnatrz ˛ platformy Microsoft a migracji do Linuksa. Różnica ta obliczona została na podstawie średniej, zewn˛etrznej stopy kosztów osobowych wynosza˛ cej 1.000 EUR. Wewn˛etrzne, zaoszcz˛edzone dni robocze na osob˛e, rozliczone zostały w oparciu o stopy Federalnego Ministerstwa Finansów. ◦ Nakłady na szkolenia użytkowników sa˛ 396 ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ Break-even 397 Projekt spłaca si˛e już w pierwszym roku. Tablica 4.36: Przykład migracji: infrastruktura serwerów – duży urzad ˛ Przykład migracji: infrastruktura serwerów – duży urzad ˛ Tablica 4.37: 3 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), duży urzad ˛ Z przedstawionego powyżej przykładu WiBe wynika dodatnia wartość kapitału przy założeniu, że zewn˛etrzne wsparcie migracji nie przekroczy 248 dni roboczych na osob˛e a konieczne przy tym wsparcie wewn˛etrzne nie przekroczy 62 dni roboczych na osob˛e. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ M IGRACJA P RZEDMIOT MIGRACJI WISKA Z M ICROSOFT O FFICE OSS – NUKSOWE Z 398 DO ŚRODO - NA KLIENTY I SERWERY LI - O PEN O FFICE . ORG mały urzad ˛ do 250 użytkowników Przykładowe scenariusze średni urzad ˛ do 1.000 użytkowników duży urzad ˛ powyżej 1.000 użytkowników Wyznaczniki sukcesu koszty oprogramowania, koszty zastapienia ˛ oprogramowania ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ ◦ W przypadku migracji do OpenOffice.org na serwerach i klientach pracuje system operacyjny GNU/Linux. ◦ generatorami koszów / korzyści sa˛ trzy kryteria – koszty licencji – koszty zastapienia ˛ oprogramowania – koszty szkolenia ◦ Na tym tle uznano wszelkie inne wyst˛epujace ˛ jeszcze koszty za neutralne i tym samym w przykładowym wyliczeniu wzi˛eto pod uwag˛e tylko w/w generatory kosztów / korzyści. ◦ W przykład wliczono po stronie oszcz˛edności różnic˛e wynikajac ˛ a˛ z kosztów licencji MS Office w porównaniu do bezpłatnego OpenOffice.org. Założenia ◦ Nakłady na szkolenia użytkowników sa˛ niemal takie same w przypadku obydwu platform (Windows 2000 i Linux). Dlatego przedstawianie przykładowego wyliczenia uznano za zbyteczne. ◦ Zaplanowane szkolenia dla 2 administratorów, każdy po 5 dni (łacznie ˛ około 2000 ¤razem z podatkiem VAT) ◦ U podstaw obliczanych tu przykładów leża˛ nast˛epujace ˛ ilości - założenia35 : 35 Jednolite dla wszytkich typów urz˛edów – ilość dokumentów na użytkownika 13 – ilość makr na użytkownika 0,07 – czas migracji pojedynczego na dokument 0,2 h 399 ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ Break-even 400 We wszystkich typach urz˛edów projekt spłaca si˛e już w pierwszym roku. Tablica 4.39: Przykłady migracji: Office / Client Desktop Przykłady migracji: Office / Client Desktop Tablica 4.40: Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), mały urzad ˛ Obliczeń w powyższych przykładach dokonano m.in. po to, aby uzyskać górna˛ granic˛e wymaganego czasu na migracj˛e makr. Odpowiednie czasy wskazane w założeniach pokazuja˛ każ- ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 401 dorazowo t˛e granic˛e. Aż do tej wartości nie powstaje c.p.36 ujemna wartość kapitału. Niniejsza ocena stanowi ponadto przeglad ˛ nakładów zwiazanych ˛ z migracja˛ wewnatrz ˛ platformy Microsoftu. Zostały tu one podliczone po stronie oszcz˛edności i można je odczytać z wierszy „wartość kapitału wb (wb = wpływajaca ˛ na budżet)“. Nakłady na migracj˛e do OpenOffice.org nie sa˛ w istocie kosztami wpływajacymi ˛ na budżet, ponieważ przeprowadza si˛e ja˛ za pomoca˛ własnego personelu. Do ocenianych tu nakładów trzeba w każdym przypadku doliczyć wsparcie zewn˛etrzne, które należy zaplanować w przybliżeniu 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 ˛ 36 c. p. = ceteris paribus; tzn. „w poza tym jednakowych warunkach“; wszystkie inne parametry ramowe i ich zależności nie zostały zmienione w niniejszych różniacych ˛ si˛e od siebie przykładach ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 402 Tablica 4.42: Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), średni urzad ˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 403 Tablica 4.43: Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), duży urzad ˛ M IGRACJA P RZEDMIOT MIGRACJI DOWISKA Z M ICROSOFT O FFICE OSS – NA LINUKSOWY DO ŚRO - O PEN O F - FICE . ORG Przykładowy scenariusz średni urzad ˛ do 500 użytkowników Krytyczne sukcesu przej˛ecie istniejacych ˛ danych - dokumentów i makr wyznaczniki ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 404 ◦ generatorami koszów / korzyści sa˛ trzy kryteria – koszty licencji – koszty zastapienia ˛ oprogramowania ◦ Na tym tle uznano wszelkie inne wyst˛epujace ˛ jeszcze koszty za neutralne i tym samym w przykładowym wyliczeniu wzi˛eto pod uwag˛e tylko w/w generatory kosztów / korzyści. ◦ Migrowane obiekty podzielono na dokuZałożenia menty i makra. Na dokumenty przypadaja˛ z reguły krótkie czasy migracji. Makra wymagaja˛ bardzo różnych nakładów czasu, które zależa˛ od stopnia złożoności każdego makro. ◦ Dla oceny kosztów aplikacji Microsoftu przyj˛eto średni poziom cen (poziom 2 z 3) umowy ramowej firmy Microsof z Minsterstwem Spraw Wewn˛etrznych. Nie sa˛ one ponoszone natychmiast w jednej racie, wskutek czego nie brano pod uwag˛e skonta. ◦ Uwzgl˛edniono migracj˛e 35 skomplikowanych makr w całym urz˛edzie37. Rozpi˛etość (wartości 37 progowe) krytycznych wyznaczników sukcesu Patrz dalsze założenia odnośnie ilości i cen przyj˛ete w obliczonym przykładzie załaczone ˛ do prezentacji Break Even. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 405 Przy maksymalnie około 6.500 migrowanych Break-even po 3 latach dokumentów i 500 użytkownikach (odpowiada to około 13 obiektom na użytkownika) Breakeven można uzyskać po 3 latach. Przy maksymalnie około 12.500 migrowanych Break-even po 5 latach dokumentów i 500 użytkownikach (odpowiada to około 25 obiektom na użytkownika) oraz 35 makrach w całym urz˛edzie Break-even można uzyskać po 5 latach. Tablica 4.45: Przykłady migracji z Windows / Microsoft Office do –> Linux / OpenOffice.org Przykład migracji z Windows / Microsoft Office do –> Linux / OpenOffice.org ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 406 Tablica 4.46: Przykład WiBe: Windows / Office do Linux / OpenOffice.org; Break even po 3 latach W przykładzie tym Break-even nast˛epuje po trzech latach. Migrowany jest MS Office wraz ze środowiskiem windowsowym do OpenOffice.org i środowiska GNU / Linux. Migracja obejmuje 6.500 dokumentów. Na oprogramowanie Open Source nie przypadaja˛ żadne koszty. Odchodza˛ za to coroczne koszty licencji na produkty Microsoftu w wysokości około 160 tys. ¤. Wartość ta zapisana jest w WiBe po stronie oszcz˛edności i wpływa na budżet. Nakłady na przestawienie oprogramowania ponoszone sa˛ własnymi siłami, dlatego koszty w wysokości około 148 tys. ¤nie wpływaja˛ na budżet. Za pomoca˛ niniejszej metody mierzenia wielkości kapitału kwoty przypadajace ˛ na dany dzień dyskontowane sa˛ o oprocentowanie. Wynikaja˛ z nich trzyletnie oszcz˛edności (brak kosz- ROZDZIAŁ 4. OCENA WYDAJNOŚCI 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 wartość kapitału powstaje dodatnia kwota wynoszaca ˛ 3.085 ¤. Tym samym przedsi˛ewzi˛ecie to jest opłacalne. Oceny ryzyka (prawdopodobieństwa wystapienia ˛ oszcz˛edności, wzgl˛ednie kosztów migracji) można tu nie brać pod uwag˛e, gdyż oszcz˛edności sa˛ obecnymi opłatami licencyjnymi, których w przyszłości nie b˛edzie. Koszty zastapienia ˛ oporogramowania przedstawione w postaci czasu wymaganego na migracj˛e zostały raczej zawyżone niż zaniżone. Podstawa˛ dla ilości jest jako Best Practice wyliczenie Gartnera38, które dostosowane zostało do wymagań administracji publicznej. Tablica 4.47: Przykład WiBe: Windows / MS Office do Linux / OpenOffice.org; Break even po 5 latach 38 Patrz „The Bost and Benefits of Moving to Sun’s StarOffice 6.0“, 1 lipca 2002 r. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 408 W niniejszym przykładzie Break-even uzyskiwany jest po 5 latach. Uzupełniajac ˛ przykład dla 3-letniego Break-even należy zauważyć, co nast˛epuje. Do 12.500 została jedynie zwi˛ekszona ilość migrowanych dokumentów (odpowiada to około 25 dokumentom na użytkownika). Czas oceny wydłużony został do 5 lat. Systematyka obliczeń pozostaje taka sama. Po pi˛eciu latach powstaje dodatnia wartość kapitału w wysokości 1.496 ¤. Jeśli chodzi o ocen˛e ryzyka i podstaw˛e ilości, patrz wyżej. P RZEDMIOT MIGRACJI M IGRACJA Z E XCHANGE 5.5 DO ŚRODOWI SKA OSS – NA KLIENTY I SERWERY LINUK SOWE Przykładowy scenariusz Wyznaczniki sukcesu S AMSUNG CONTACT mały urzad, ˛ 250 użytkowników koszty oprogramowania, koszty zastapienia ˛ oprogramowania ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ ◦ generatorami koszów / korzyści sa˛ trzy kryteria – koszty licencji – koszty zastapienia ˛ oprogramowania – koszty szkolenia ◦ Na tym tle uznano wszelkie inne wyst˛epujace ˛ jeszcze koszty za neutralne i tym samym w przykładowym wyliczeniu wzi˛eto pod uwag˛e tylko w/w generatory kosztów / korzyści. ◦ W przykład wliczono po stronie oszcz˛edności różnic˛e wynikajac ˛ a˛ z nie branych pod uwag˛e nakładów na przejście z MS Exchange 5.5 do Exchange 2000. Dotyczy to licencji na oprogramowanie i kosztów zastapienia ˛ oprogramowania. Licencje na oprogramowanie: Po stronie oszcz˛edności liczono tu różZałożenia nic˛e pomi˛edzy kosztami licencji Contact a Exchange. Koszty zastapienia ˛ oprogramowania: Po stronie oszcz˛edności wpisano różnic˛e pomi˛edzy nakładami liczonymi w dniach roboczych na osob˛e w przypadku Samsung i Microsoft. Różnica ta obliczona została na podstawie średniej, zewn˛etrznej stopy kosztów osobowych wynosza˛ cej 1.000 ¤. ◦ Nakłady na szkolenia użytkownikó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- 409 ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ Na podstawie założeń projekt jawi si˛e jako wysoce opłacalny. Break-even uzyskuje si˛e już w pierwszym roku. Ważnym czynnikiem sa˛ przy Break-even tym oszcz˛edności na zewn˛etrznym wsparciu wymaganym w przypadku migracji wewnatrz ˛ platformy Microsoft. W oparciu o ocen˛e BestCase i Worst-Case w ramach dodatniej wartości kapitału powstaje przestrzeń 5 - 20 dni wymaganego zewn˛etrznego 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 ˛ 410 ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 411 Tablica 4.50: Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], mały urzad ˛ W powyższym przykładzie ustalono górna˛ granic˛e progowa˛ zewn˛etrznego wsparcia dla Contact w przypadku małych urz˛edów. Wynosi ona 20 dni roboczych na osob˛e. Tym samym wartość kapitału wynoszaca ˛ (187) nadal jest dodatnia, co sprawia, że projekt jest rentowny. Jeśli konieczne jest mniejsze zewn˛etrzne wsparcie, wówczas wartość kapitału rośnie. Oceny ryzyka (prawdopodobieństwa wystapienia ˛ oszcz˛edności, wzgl˛ednie kosztów migracji) można tu nie brać pod uwag˛e, gdyż oszcz˛edności sa˛ obecnymi opłatami licencyjnymi, których w przyszłości nie b˛edzie. Koszty zastapienia ˛ oporogramowania przedstawione w postaci wymaganego czasu zostały raczej zawyżone niż zaniżone. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ M IGRACJA P RZEDMIOT MIGRACJI SKA OSS – SOWE Przykładowy scenariusz Wyznaczniki sukcesu Z E XCHANGE 5.5 412 DO ŚRODOWI - NA KLIENTY I SERWERY LINUK - S AMSUNG CONTACT średni urzad, ˛ 1.000 użytkowników koszty oprogramowania, koszty zastapienia ˛ oprogramowania Patrz przykłady z „mały urzad“. ˛ Założenia Dodatkowo: Ilość administratorów i nakład na ich szkolenie nie zmienia si˛e w zależności od ilości użytkowników pozostaja˛ takie same (około 2 x 2.000, ¤liczone z podatkiem VAT). Na podstawie założeń projekt jawi si˛e jako wysoce opłacalny. Break-even uzyskuje si˛e już w pierwszym roku. Najważniejszym czynnikiem sa˛ przy tym oszcz˛edności na zewn˛etrznym Break-even wsparciu wymaganym w przypadku migracji wewnatrz ˛ platformy Microsoft. W oparciu o ocen˛e Best-Case i Worst-Case w ramach dodatniej wartości kapitału powstaje przestrzeń 10 35 dni dla potrzebnego zewn˛etrznego wsparcia w przypadku przedstawionej w przykładzie migracji do Samsung. Tablica 4.52: Przykłady migracji: Messaging / Groupware – średni urzad ˛ Przykład migracji: Messaging / Groupware – średni urzad ˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 413 Tablica 4.53: Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], średni urzad ˛ W powyższym przykładzie ustalono górna˛ granic˛e progowa˛ zewn˛etrznego wsparcia dla Contact w przypadku średnich urz˛edów. Wynosi ona 34 dni robocze na osob˛e. Tym samym wartość kapitału wynoszaca ˛ (1.102) jest jeszcze dodatnia, co sprawia, że projekt jest rentowny. Jeśli za wartość zewn˛etrznego wsparcia dla Contact w przypadku średnich urz˛edów przyjmie si˛e realistyczny wskaźnik 5 dni, wówczas powstaje naprawd˛e duża dodatnia wartość kapitału, która sygnalizuje dobra˛ rentowność projektu. Oceny ryzyka (prawdopodobieństwa wystapienia ˛ oszcz˛edności, wzgl˛ednie kosztów migracji) można tu nie brać pod uwag˛e, gdyż oszcz˛edności sa˛ obecnymi opłatami licencyjnymi, których w przyszłości nie b˛edzie. Koszty zastapienia ˛ oporogramowania przedstawione w postaci wymaganego czasu zostały raczej zawyżone niż zaniżone. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 4.8.6.3 Przykład migracji: Messaging / Groupware – duży urzad ˛ P RZEDMIOT MIGRACJI M IGRACJA Z E XCHANGE 5.5 DO ŚRODOWI SKA OSS – NA KLIENTY I SERWERY LINUK SOWE Przykładowy scenariusz Wyznaczniki sukcesu Założenia S AMSUNG CONTACT duży urzad, ˛ 10.000 użytkowników koszty oprogramowania, koszty zastapienia ˛ oprogramowania Patrz przykłady z „mały i średni urzad“. ˛ Na podstawie założeń, do ilości pracowników wynoszacej ˛ około 6.200, projekt jawi si˛e jako opłacalny. Jeśli wzrośnie ilość pracowników i / lub ilość dni zewn˛etrznego wsparcia, wówczas Break-even po 1 roku wartość kapitału stanie si˛e ujemna. Oszcz˛edności wynikajace ˛ z nie branych pod uwag˛e dni zewn˛etrzego wsparcia dla Migracji wewnatrz ˛ platformy Microsoft równoważa˛ si˛e tylko do w/w ilości pracowników. Tablica 4.55: Przykłady migracji: Messaging / Groupware – duży urzad ˛ 414 ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 415 Tablica 4.56: Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], duży urzad ˛ W powyższym przykładzie założono wsparcie zewn˛etrzne dla Contact w wysokości około 17 dni roboczych na osob˛e. Wynikajace ˛ z tego oszcz˛edności wynosza˛ około 111 dni roboczych na osob˛e wzgl˛edem usługi Microsoftu. Ilość użytkowników ustalono na 10.000. W takich warunkach wyliczenia daja˛ jeszcze dodatnia˛ wartość kapitału. 4.8.6.4 Przykłady migracji według kategorii kosztów informatyzacji Obowiazuj ˛ a˛ tu takie same założenia, jakie zostały opisane w rozdziale 4.8.6.1. Obliczenia w przykładach odnosza˛ si˛e do produktów przedstawionych w poniższej tabeli. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 416 Tablica 4.57: Typy migracji / produkty W niniejszym modelu dokonano porównawczej oceny alternatywnych typów migracji przyjmujac ˛ za punkt wyjścia aktualne środowisko. Scenariuszem wyjściowym jest przy tym platforma Microsoftu. Jedynie wariant migracji kontynuacyjnej nie zawiera namacalnych, dajacych ˛ si˛e obliczyć oszcz˛edności. Wszystkie inne warianty prowadza˛ do całkowitej albo cz˛eściowej zmiany platformy i tym samym zawieraja˛ w obszarze porównania ich z migracja˛ kontynuacyjna˛ oszcz˛edności w postaci zaoszcz˛edzonych wydatków. Ceny i warunki zastosowane w przykładowych wyliczeniach zwracaja˛ si˛e w pierwszym roku wdrażania projektu. Ponieważ rachunek opiera si˛e na cenach zakupu, oszcz˛edności powstaja˛ również tylko w pierwszym roku. 4.8.6.5 Pełna migracja Pełna migracja oznacza ponadprzeci˛etnie duży efekt oszcz˛ednościowy w przypadku urz˛edów każdego typu. Na przykład migracja z Windows NT do Linuksa daje w przeciwieństwie do migracji do Windows 2000 oszcz˛edności, które wielokrotnie przekraczaja˛ nakłady. Duża instalacja Koszty osobowe w przypadku zmiany platformy stanowia˛ porównywalny rzad ˛ wielkości, dlatego że wi˛eksza cz˛eść oszcz˛edności pochodzi ze zb˛ednych kosztów licencji. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 417 Rysunek 4.5: Przykład rachunku opłacalności migracji Windows NT –> Linux, duży urzad, ˛ ocena kosztów projektu Także ocena rentowności niniejszego wariantu pokazuje poprzez dodatnia˛ wartość kapitału opłacalny przebieg przedsi˛ewzi˛ecia. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 418 Rysunek 4.6: Przykład rachunku opłacalności migracji Windows NT –> Linux, duży urzad, ˛ ocena wartości kapitału Średnia instalacja W obszarze średnich i małych urz˛edów obowiazuje ˛ zasadniczo scenariusz porównywalny ze scenariuszem z dużych urz˛edów. Także w tym przypadku migracja do Open Source jawi si˛e jako bardzo godna polecenia. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 419 Rysunek 4.7: Przykład rachunku opłacalności migracji Windows NT –> Linux, średni urzad, ˛ ocena kosztów projektu Również w tego typu urz˛edzie z oceny porównawczej różnych wariantów migracji wynika dodatnia wartość kapitału. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 420 Rysunek 4.8: Przykład rachunku opłacalności migracji Windows NT –> Linux, średni urzad, ˛ ocena wartości kapitału Mała instalacja Obowiazuje ˛ tu to samo, co w przykładach dla średnich i dużych urz˛edów. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 421 Rysunek 4.9: Przykład rachunku opłacalności migracji Windows NT –> Linux, mały urzad, ˛ ocena wartości kapitału 4.8.6.6 Migracja kontynuacyjna W przypadku tego typu migracji nie można zidentyfikować ani zbilansować oszcz˛edności. Dlatego prezentujemy tylko jeden z woluminów kosztów wynikajacych ˛ ze scenariusza. Zasadniczo za podstaw˛e przyjmuje si˛e jednorazowe koszty zakupu. Równolegle przedstawiamy wyniki uwzgl˛edniajace ˛ roczne opłaty za dzierżaw˛e uaktualnień dla Windows oraz MS Office. Każdorazowo pokazujemy wyliczenia dla dużych, średnich i małych instalacji. Wersja opłat za dzierżaw˛e jawi si˛e we wszystkich wyliczonych wariantach jako znacznie droższe rozwiazanie ˛ (dodatkowe koszty w wysokości około 250 tys. ¤[mała migracja], ponad około 1 miliona ¤[średnia migracja], do około 10 milionów ¤[duża migracja]). Taki wzrost kosztów ma miejsce wyłacznie ˛ za sprawa˛ odnawianych licencji na oprogramowanie. Wszystkie przedstawione koszty osobowe sa˛ kosztami wsparcia zewn˛etrznego. Duża instalacja ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 422 Rysunek 4.10: Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, duży urzad ˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 423 Rysunek 4.11: Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, duży urzad, ˛ alternatywna dzierżawa Windows / Office Średnia instalacja Rysunek 4.12: Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, średni urzad ˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 424 Rysunek 4.13: Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, średni urzad, ˛ alternatywna dzierżawa Windows / Office Mała instalacja ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 425 Rysunek 4.14: Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, mały urzad ˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 426 Rysunek 4.15: Przykład rachunku kosztów projektu migracji Windows NT –> Linux, mały urzad, ˛ alternatywna dzierżawa Windows / Office 4.8.6.7 Migracja cz˛eściowa Punktowa migracja Rysunek 4.16: Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Contact, duży urzad ˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 427 Rysunek 4.17: Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Contact, średni urzad ˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 428 Rysunek 4.18: Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Contact, mały urzad ˛ Migracja cz˛eściowa po stronie serwera Rysunek 4.19: Przykład rachunku kosztów projektu migracji Windows NT do Linuksa po stronie serwera, duży urzad ˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 429 Rysunek 4.20: Przykład rachunku kosztów projektu migracji Windows NT do Linuksa po stronie serwera, średni urzad ˛ ROZDZIAŁ 4. OCENA WYDAJNOŚCI 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 konieczności oraz jakości i strategii migracji Przykładowa ocena obejmuje rachunek konieczności D (Konieczność) i jakości czynników strategicznych Q (Jakość) wynikajacy ˛ z IT-WiBe 21. Uwzgl˛ednia ona generalna˛ sytuacj˛e urzadów ˛ i jest zgrubna˛ ocena˛ obecnej dyskusji dotyczacej ˛ systemów alternatywnych. W ogólnych zarysach zebraliśmy argumenty uzasadniajace ˛ każdorazowe wyliczenia. Niniejszy opis został ukierunkowany według stopni spełnienia celu wynikajacego ˛ z katalogu kryteriów. Przykładowa ocena konieczności migracji daje wartość > 59 <. Zatem z tego punktu widzenia można generalnie poprzeć zamiary migracyjne. Przykładowa ocena jakościowo - strategiczna zamiarów migracyjnych daje wartość > 66 <. Tym samym z ocenianych tu punktów widzenia maja˛ one także sens. 4.9.1 Kryteria konieczności Niniejsze kryteria (grupa 3 katalogu kryteriów) odnosza˛ si˛e z jednej strony do konieczności zastapienia ˛ starego systemu a z drugiej strony do przestrzegania przepisów administracyjnych i ustaw. 4.9.2 Kryteria jakościowo - strategiczne W grupie 4 katalogu kryteriów wymienione sa˛ kryteria jakościowo - strategiczne dotyczace ˛ zamierzeń informatycznych. Odnosza˛ si˛e one do priorytetu tych działań, do poprawienia jakości pracy w ramach urz˛edu i do oddziaływania na pracowników oraz „klientów“ administracji publicznej (otwartość na obywatela), jak również do pokupności oprogramowania i bezpieczeństwa informatycznego. W ten sposób na pierwszym planie nie wyst˛epuje już stary system, lecz należy dokonać sprawdzenia zamiaru informatycznego pod katem ˛ czynników wymienionych w kryteriach. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 431 4.9.3 Analiza korzyści Kryteriów konieczności oraz jakości / strategii nie można sklasyfikować za pomoca˛ analizy pieni˛eżnej. Zamiast tego tworza˛ one cz˛eść oceny korzyści. Wymaga to jakościowego opisu wpływu niniejszych kryteriów. Opis taki należy z kolei zamienić w ocen˛e punktowa˛ każdego kryterium. Służy do tego „skala ocen“ od 0 do 10. Punkty należy pomnożyć przez każdorazowy stopień ważności i zsumować poszczególne obszary kryteriów. Jeśli uzystkana wartość jest wi˛eksza niż (>) 50, wówczas zamiar informatyczny zwiazany ˛ ze sprawdzonym zakresem należy zakwalifikować jako „zalecany do realizacji“. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 432 Rysunek 4.22: Model oceny konieczności i jakości zamiaru migracyjnego Poszczególne kryteria opisane zostały w poniższej tabeli: P OZYCJA WIBE 3 K RYTERIUM / OBJA ŚNIENIE WA ŻNO Ś Ć / PUNKTY CZYNNIKI KONIECZNO ŚCI ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 433 3.1 Konieczność zastapienia ˛ starego systemu W 20 3.1.1 Wsparcie kontynuacji starego sytemu P8 ◦ Wsparcie dla systemu operacyjnego MS Windows NT wygasa z 2003 r. ◦ Nie b˛edzie już Service Packs usuwajacych ˛ bł˛edy systemowe ważne dla bezpieczeństwa. ◦ Nie ma obsługi nowych Features takich jak, np. USB i inne. 3.1 Konieczność zastapienia ˛ starego systemu W 20 3.1.2 Stabilność starego systemu P7 3.1.2.1 Bł˛edy i awarie („downtime“) ◦ Podatność starego systemu na bł˛edy znajduje si˛e wciaż ˛ w zakresie, który można tolerować. ◦ Wskutek zastosowania nowych narz˛edzi wspomagajacych ˛ administrowanie wzrośnie podatność na bł˛edy, ponieważ programiści przechodza˛ na nowe biblioteki, których jednak nie można bez problemu zintegrować z architektura˛ Windows NT. 3.1 Konieczność zastapinia ˛ starego systemu W 20 3.1.2 Stabilność starego systemu P4 3.1.2.2 Problemy z konserwacja,˛ waskie ˛ gardło – personel ◦ Wsparcie zewn˛etrzne dla systemu w przyszłości b˛edzie si˛e wciaż ˛ zmniejszać, ponieważ także producent nie b˛edzie go już gwarantować a w tak zwanym mi˛edzyczasie na rynek wprowadzona zostanie kolejna platforma systemu operacyjnego. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 434 3.1 Konieczność zastapienia ˛ starego systemu W 10 3.1.3 Elastyczność starego systemu P8 3.1.3.1 Rozbudowa / poszerzanie granic ◦ Nie b˛edzie już implementacji nowych funkcji takich jak, np. obsługa USB, i innych. ◦ Nie b˛eda˛ już rozwijane narz˛edzia zapewniajace ˛ współprac˛e z nowymi systemami. ◦ Wskutek zmieniajacych ˛ si˛e architektur w przyszłości wystapi ˛ a˛ z wi˛eksza˛ siła˛ problemy z interfejsami do innych systemów informatycznych. 3.1 3.1.3 Konieczność zastapienia ˛ starego systemu Elastyczność starego systemu 3.1.3.2 Kompatybilność, problemy z interfejsami aktualnie / W 10 P9 w przyszłości ◦ Obecne działania dostosowujace ˛ stary system wiaż ˛ a˛ si˛e z dużymi nakładami 3.1 Konieczność zastapienia ˛ starego systemu W 20 3.1.3 Elastyczność starego systemu P3 3.1.3.3 Przyjazność dla użytkownika ◦ Obecnie nie sa˛ zakłócone Tablica 4.59: Przykład analizy korzyści: czynniki konieczności P OZYCJA WIBE 4 K RYTERIUM / OBJA ŚNIENIE WA ŻNO Ś Ć / PUNKTY CZYNNIKI JAKO ŚCIOWO - STRATEGICZNE ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 435 4.1 Priorytet zamiaru informatycznego W5 4.1.2 Wkomponowanie w rozbudow˛e informatyczna˛ całej P5 administracji federalnej ◦ Zamiary KBSt w obszarze zastosowania produktów Open Source prowadzace ˛ w kierunku realnego przekształcenia środowiska systemowego wraz ze wszystkimi ocenianymi funkcjami (administrowanie, konwersja plików i inne) można w przypadku instniejacych ˛ produktów i zależności zrealizować tylko warunkowo. 4.1 4.1.3 Priorytet zamiaru informatycznego Skutki dla partnerów komunikacyjnych W 10 P7 ◦ W przeciwieństwie do obecnej sytuacji, w ramach ukierunkowania si˛e na wdrożenie produktów OSS tworzona jest idealna podstawa komunikacyjna, która ułatwi komunikacj˛e wykraczajac ˛ a˛ poza urz˛edy. 4.1 Priorytet zamiaru informatycznego W 20 4.1.5 Uzależnienie od producenta P8 ◦ Wskutek zainstnienia heterogenicznej struktury informatycznej składajacej ˛ si˛e z produktów Microsoft i OSS, wraz z jednoznacznym ukierunkowaniem si˛e na wdrożenie produków OSS odchodzi si˛e od daleko idacego ˛ uzależnienia od producenta. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 436 4.4 Efekty dotyczace ˛ pracowników W5 4.4.1 Atrakcyjność warunków pracy P6 Można tu zaobserwować dwa oddzielne efekty: ◦ W obszarze administrowania powstana˛ nakłady wskutek wyraźnie bardziej wymagajacych ˛ czynności wynikajacych ˛ z wdrożenia produktów OSS, które wyraźnie poszerza˛ profile kwalifikacji personelu. ◦ W obszarze użytkowników daży ˛ si˛e do rozwia˛ zań, które umożliwia˛ wyraźne uproszczenie dzisiaj jeszcze po cz˛eści bardzo ograniczonej pracy w obszarze biurowego oprogramowania komunikacyjnego wykraczajacej ˛ poza ramy produktu. 4.4 Efekty dotyczace ˛ pracowników W2 4.4.3 Powszechność / dost˛epność wykształcenia P3 ◦ Z uwagi na wykształcenie i doświadczenie wymagane dla obsługi obecnie stosowanych systemów nie ma tu problemów. Za to w przyszłości, w przypadku silniejszego popytu na produkty OSS, może być trudniej znaleźć odpowiednio wykształcony personel. Ponieważ jednak należy wyjść z założenia, że pracujacy ˛ personel jest odpowiednio wyszkolony, wystapieniem ˛ tego efektu w administracji publicznej nie należy si˛e na razie zajmować. ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 437 4.5 Efekty zwiazane ˛ z dost˛epnościa˛ dla obywateli W2 4.5.4 Poprawa wizerunku P6 ◦ Projekty migracyjne powinny służyć także integracji światów serwerów i klientów ze zwykłym dniem dniem pracy. ◦ Stopniowe przejście do środowiska OSS umożliwi łagodna˛ migracj˛e i pokaże w praktyce, że możliwe jest przeniesienie woli politycznej w kierunku OSS. ◦ W średniej i długiej perspektywie czasu ujawnia˛ si˛e w całej administracji oraz obywatelom wyraźne wartości dodane wynikajace ˛ z projektów migracyjnych. 4.6 Powszechność / dost˛epność oprogramowania W5 4.6.1 Stopień przenikni˛ecia rynku P7 ◦ Produkty, które należy zastosować sa˛ bez problemu dost˛epne na rynku 4.6 Powszechność / dost˛epność oprogramowania W5 4.6.2 Niezależne wsparcie P6 ◦ Wsparcie dla wykorzystywanych produktów oferuja˛ oprócz producentów także liczne niezależne przedsi˛ebiorstwa ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 438 4.6 Powszechność / dost˛epność oprogramowania W5 4.6.3 Posiadane certyfikaty na oprogramowanie P5 ◦ Produkty, które należy zastosować dysponuja˛ właściwymi referencjami albo certyfikatami 4.6 4.6.4 Powszechność / dost˛epność oprogramowania Dost˛epne narz˛edzia do administrowania oprogramo- W5 P5 waniem ◦ Narz˛edzia administracyjne dost˛epne sa˛ w wystarczajacym ˛ stopniu 4.7 Bezpieczeństwo informatyczne W6 4.7.1 Bezpieczeństwo komunikacji P7 ◦ Komunikacja z wewn˛etrznymi i zewn˛etrznymi partnerami jest dobrze zagwarantowana 4.7 Bezpieczeństwo informatyczne W6 4.7.2 Bezpieczeństwo aplikacji P6 ◦ Aplikacje sa˛ dojrzałe. 4.7 Bezpieczeństwo informatyczne W6 4.7.3 Zabezpieczenie przed awariami P7 ◦ Systemy OSS sa˛ w każdym przypadku lepiej zabezpieczone przed awariami ROZDZIAŁ 4. OCENA WYDAJNOŚCI EKONOMICZNEJ 439 4.7 Bezpieczeństwo informatyczne W6 4.7.4 Zarzadzanie ˛ bezpieczeństwem P7 ◦ Systemy OSS dysponuja˛ udokumentowanymi i dost˛epnymi dla wszystkich zainteresowanych mechanizmami bezpieczeństwa 4.7 Bezpieczeństwo informatyczne W6 4.7.5 Bezpieczeństwo inwestycji i planowania P8 ◦ Inwestycja jest pewna, produkty b˛eda˛ dost˛epne także w przyszłości jeszcze przez typowy dla urz˛edów okres pi˛eciu lat. Systemy OSS pracuja˛ stabilnie a budowane w oparciu o nie procesy można pewnie planować. Tablica 4.61: Przykład analizy korzyści: czynniki jakościowo - strategiczne Rozdział 5 Zalecenia migracyjne 5.1 Ogólne wyjaśnienia 5.1.1 Droga do podj˛ecia decyzji O zaleceniu migracji badź ˛ kontynuacji decyduja˛ wyniki oceny ekonomicznej przygotowanej pod katem ˛ długofalowym. Także wówczas, gdy z technicznego punktu widzenia możliwe jest bez ograniczeń wybranie migracji całkowitej albo cz˛eściowej, w danych warunkach brzegowych wzgl˛edy ekonomiczne moga˛ sprawić, że w/w drogi migracji b˛eda˛ mało sensowne. Dlatego ze wzgl˛edu na różne zwiazki ˛ pomiedzy poszczególnymi składnikami oraz systemami infrastruktury informatycznej i świata aplikacji, podczas szukania właściwej decyzji trzeba stale uwzl˛edniać perspektyw˛e długofalowa. ˛ Przy tym ocena pod katem ˛ wprowadzenia oprogramowania Open Source nie różni si˛e od zwykłych analiz w branży informatycznej, np. w kontekście konsolidacji osprz˛etu i oprogramowania. Strategiami, którymi w równym stopiniu należy si˛e zazwyczaj kierować w administracji publicznej i w gospodarce sa: ˛ ◦ oparte o otwarte standardy i specyfikacje ściśle dostosowane do siebie platformy systemowe i platformy aplikacji, w razie potrzeby z dodatkowym wykorzystaniem specjalizowanych produktów integrujacych ˛ ◦ oparte o charakterystyczne dla producenta (bez udost˛epnianych albo tylko z cz˛eściowo udost˛epnianymi interfejsami i specyfikacjami) ściśle dostosowane do siebie platformy systemowe i platformy aplikacji, w razie potrzeby z wykorzystaniem produktów integrujacych ˛ od producenta. 440 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 441 ◦ rozwiazania ˛ wyspowe do punktowego pokrycia procedur specjalistycznych i specjalistycznych aplikacji (przestarzałe). Ponieważ oprogramowanie Open Source od swojego poczatku ˛ zwiazane ˛ jest ze stosowaniem otwartych standardów, powstaje dodatkowy szczególny wariant: ◦ oparte o otwarte standardy i specyfikacje dostosowane do siebie platformy systemowe i platformy aplikacji z wykorzystaniem otwartego kodu źródłowego wielokrotnego użytku. Podczas, gdy decyzja o punktowym zastosowaniu szeroko dost˛epnego produktu o otwartym kodzie źródłowym, jakim jest np. serwer WWW Apache, może być z reguły bardzo pragmatyczna i sprawnie podj˛eta, decyzja dotyczaca, ˛ np. wprowadzenia oprogramowania Open Source na całej powierzchni i zastapienia ˛ własnościowych wysp, z uwagi na swoje długofalowe skutki wymaga podejścia metodycznego. Składa si˛e ono z nast˛epujacych ˛ elementarnych kroków: ◦ opracowanie wspólnej strategii informatycznej z uwzgl˛ednieniem istniejacych ˛ finansowych, organizacyjnych, uwarunkowanych innowacyjnościa˛ oraz osobowych celów ◦ zdefiniowanie przyszłej strategii dla platformy Open Source z uwzgl˛ednieniem długoterminowego 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 wewn˛etrznej i zewn˛etrznej możliwości ponownego zastosowania, jak też kompatybilności ◦ wybór produktów spełniajacych ˛ wymagania ◦ zdefiniowanie zamiaru migracyjnego oraz zaplanowanie zwiazanych ˛ z nim czasu i akcji, jak też zapewnienie finansowania W poszczególnych etapach nieniejszego procesu można korzystać z już stosowanych w administracji publicznej metod i narz˛edzi zgodnie z poniższym rysunkiem. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 442 Rysunek 5.1: Proces decyzyjny prowadzacy ˛ do wdrożenia OSS 5.1.2 Ogólne zalecenia Z uwagi na różne punkty wyjścia (wraz z istnieniem rozwiazań ˛ wyspowych) i różna˛ jakość produktu bardzo rzadko można ogólnie wypowiadać si˛e o zaletach ekonomicznych w/w strategii platform. Jednak generalnie obowiazuje ˛ zasada, że wraz ze rosnacym ˛ stopniem integracji produktów jednej platformy z wielu powodów rośnie łaczna ˛ opłacalność: ◦ wskutek wyższej produktywności, w przypadku dobrze (brak awarii systemu) dostosowanych do siebie produktów ◦ wskutek rosnacej ˛ możliwości ponownego zastosowania składników i rozwiazań, ˛ które rozwini˛ete zostały za pomoca˛ jednakowej technologii Middleware ◦ wskutek oszcz˛edności w przypadku ujednoliczenia procedur zakupu i konserwacji albo umów kupna i konserwacji. Ponadto obowiazuje ˛ zasada, że wraz z rosnacym ˛ stopniem standaryzacji opartej na otwartych standardach łaczna ˛ opłacalność rośnie z wielu powodów: ◦ wskutek wprowadzenia konkurencji pomi˛edzy produktami i rozwiazaniami ˛ ◦ wskutek mniejszego uzależnienia od producenta ◦ wskutek powstania w sumie szerszego rynku usług ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 443 Bezpieczeństwo inwestycji dla komercyjnych oferentów oprogramowania linuksowego wzrosło zwłaszcza (jednak nie wyłacznie) ˛ wskutek przyj˛ecia SAGA (Standardy i Architektury dla Aplikacji 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, że możliwy staje si˛e jeszcze do niedawna trudny scenariusz pełnej migracji. Wychodzac ˛ z powyższego założenia można sformułować nast˛epujace ˛ podstawowe zalecenia odnośnie zastosowania produktów o otwartym kodzie źródłowym: ◦ zaleca si˛e przyj˛ecie kryterium opłacalności jako obrazu przewodniego całej strategii informatycznej przy umiarkowanym uwzgl˛ednieniu czynników innowacyjności i oraganizacji ◦ zaleca si˛e wykorzystanie systemu operacyjnego GNU/Linux jako podstawowej platformy informatycznej dla wszystkich obszarów zastosowań, w razie gdy adekwatne sa˛ założenia dotyczace ˛ migracji pełnej albo cz˛eściowej (patrz rozdział 5.2 i 5.4) ◦ zaleca si˛e wykorzystanie otwartych standardów uznanych w równym stopniu przez przemysł informatyczny i Społeczność Otwartego Oprogramowania (Open Source Community) jako podstawy dla dokonania wyboru i integracji oprogramowania w celu unikni˛ecia zewn˛etrznych zależności od producenta ◦ zaleca si˛e przeprowadzenie oceny ekonomicznej pod katem ˛ projektu w procesie decyzyjnym zwiazanym ˛ z zastosowaniem otwartych i komercyjnych produktów linuksowych. (patrz rozdział 4). Zasadniczo przejście na platform˛e OSS- / COLS może okazać si˛e ekonomicznie bardziej sensownym (opłacalnym) wariantem niż migracja kontynuacyjna do nowej wersji produktów Microsoftu. Odejście od kosztów licencji lub ich redukcja może w wielu przypadkach prowadzić do bezpośrednich (pieni˛eżnych) oszcz˛edności, np. w przypadku: ◦ migracji cz˛eściowej po stronie serwera, połaczonej ˛ z konsolidacja˛ osprz˛etu i oprogramowania, gdy dost˛epna jest już wiedza z zakresu rozwiazań ˛ uniksowych (Know-how) oraz systemy uniksowe ◦ punktowego zastapienia ˛ członków wcześniejszej rodziny Back-Office (obecnie .NET Enterprise Server), przykładowo serwerów Exchange albo SQL, zwłaszcza przy dużych i rosnacych ˛ ilościach użytkowników i zwi˛ekszajacych ˛ si˛e zarazem opłatach licencyjnych ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 444 ◦ migracji cz˛eściowej po stronie klienta z produktów MS Office, gdy nie uniemożliwi ona korzystania ze środowiska Office jako bieżacego ˛ środowiska dla makr lub aplikacji W wielu innych scenariuszach wdrożeń, aby ocenić oszcz˛edności trzeba wziać ˛ pod uwag˛e wymiar strategiczny, który został szczegółowo opisany w rozdziale „Ocena wydajności ekonomicznej“. W razie migracji obecnych platform do świata Linuksa albo do nowej platformy Microsoftu należy, z ekonomicznego punktu widzenia, w każdym przypadku zaplanować nakłady na szkolenia. Ponieważ realnie pojawia˛ si˛e one w przypadku obydwu alternatywnych typów migracji, ten blok kosztów należy oceniać dalece neutralnie, jako bezpośrednio porównywalny. W każdym przypadku oznacza to, że dla obydwu alternatyw należy uwzgl˛ednić koszty migracji istniejacych ˛ aplikacji specjalistycznych1 . Ponieważ podstawowe zalecenia nie moga˛ uwzgl˛edniać wymagań i warunków brzegowych konkretnej sytuacji wyjściowej, dalsze zalecenia odnosza˛ si˛e do różnych 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 środowiska mieszanego (migracja cz˛eściowa). 5.2 Całkowita „zast˛epujaca ˛ migracja” Zgodnie z założeniami niniejszego poradnika migracyjnego całkowita migracja ma miejsce wtedy, gdy nast˛epuje wdrożenie Linuksa jako systemu operacyjnego na poziomie wszystkich składników infrastruktury informatycznej. Z powszechna˛ zamiana˛ systemu operacyjnego zwiazana ˛ jest na ogół także zmiana na poziomie integracji i aplikacji wskutek wykorzystania produktów zgodnych z SAGA, ponieważ zwłaszcza potrzebne do tego produkty Java nie rozpowszechniły si˛e dotychczas na platformach windowsowych2 w oczekiwany sposób. Przy całkowitej migracji można zasadniczo korzystać z dwóch wariantów oprogramowania, które cz˛esto stosowane sa˛ razem: ◦ OSS: Otwarte Oprogramowanie (albo Wolne Oprogramowanie)3: oprogramowanie z po1 Niniejszy blok kosztów nie jest uwzgl˛edniany w ocenie zamieszczonej w poradniku migracyjnym. Z reguły konieczne sa˛ tu bardzo specyficzne analizy w przypadku każdego urz˛edu, których nie można dostarczyć w ramach poradnika. W poszczególnym przypadku zaprezentowane w ocenie ekonomicznej wymiary moga˛ si˛e zmieniać po właczeniu ˛ stwierdzonych koszów migracji aplikacji specjalistycznych. 2 W tym przypadku konieczność zastapienia ˛ nie dotyczy rozpowszechnionych także pod Windows aplikacji webowych z modelu (L)AMP. 3 Patrz definicja z rozdziału 2 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 445 wszechnie dost˛epnym kodem źródłowym i bezpłatne, rozwijane przez Społeczność Otwartego Oprogramowania ◦ COLS: KOmercyjne Oprogramowanie Linuksowe – „KOOL“: linuksowe oprogramowanie komercyjne o otwartym kodzie źródłowym albo własnościowe, jako oferta producentów oprogramowania. Ponieważ w wielu obszarach administracji intensywnie używa si˛e zarówno rozwini˛etych we własnym zakresie i opertych na Windows procedur specjalistycznych, jak też opartych na ERP systemów zarzadzania ˛ aplikacjami, całkowitego pokrycia wymagań za pomoca˛ oprogramowania Open Source w dajacym ˛ si˛e przewidzieć czasie można oczekiwać tylko w obszarze infrastruktury. Uwzgl˛edniajac ˛ wsparcie Linuksa przez dost˛epność dużych systemów użytkowych pochodzacych ˛ od takich producentów jak SAP albo Oracle, zastosowanie komercyjnego oprogramowania oraz rosnac ˛ a˛ ofert˛e oprogramowania linuksowego należy w sumie ocenić pozytywnie, jeśli chodzi o dalszy rozwój platformy Open Source, i liczyć si˛e z jej dalszym rozwojem. Indywidualne wybicie si˛e możliwych i zalecanych systemów i architektur oprogramowania różni si˛e w zależności od intensywności informatycznej („obciażenia“) ˛ i stopnia wyspecjalizowania urz˛edów. Z jednej strony odgrywaja˛ tu decydujac ˛ a˛ rol˛e skalowalność i niezawodność poszczególnych składników a z drugiej także nakłady zwiazane ˛ z wdrożeniem. Z tych powodów każdorazowo wyróżnione i ocenione zostały zagadnienia dotyczace ˛ dużych oraz średnich, jak też specjalizowanych oraz małych urz˛edów. Jako wprowadzenie zaprezentowano najpierw ogólny, gatunkowy model zadań infrastrukturalnych. 5.2.1 Model architektury W przypadku powszechnego zastosowania Linuksa jako platformy dla serwerów i aplikacji klienckich można wyróżnić – 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 Konfiguracja przedstawiona na rysunku 5.2 jest reprezentatywna dla wielofunkcyjnych systemów stacji roboczych w zdecentralizowanej architekturze na powszechnie dost˛epnym w sprzedaży 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. nast˛epujace ˛ obszary zadań: ◦ komputer jako stacja robocza (desktop i Office) ◦ 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 grafitowa˛ kratka˛ moga˛ być stosowane bez wzgl˛edu na wielkość i stopień wyspecjalizowania każdego urz˛edu. Zwyczajne składniki systemu ocenione zostały w poniższych rozdziałach w zależności od danego scenariusza ich wykorzystania. Przewidziano scenariusze dla: ◦ dużych i średnich urz˛edów ◦ specjalizowanych urz˛edów świadczacych ˛ usługi informatyczne ◦ małych urz˛edów. Uwaga: w przypadku ocenianych scenariuszy migracji należy generalnie uwzgl˛ednić kilka ograniczeń: Oceny techniczne pokazuja,˛ że z małymi wyjatkami ˛ dla wszystkich produktów Microsoftu, które sa˛ cz˛eścia˛ składowa˛ analizowanej sytuacji wyjściowej (patrz rozdział 2.2.1), dost˛epne sa˛ alternatywne rozwiazania ˛ OSS badź ˛ COLS umożliwiajace ˛ migracj˛e zast˛epujac ˛ a.˛ Krytycznymi punktami sa: ˛ ◦ kompatybilność pomi˛edzy OpenOffice.org / StarOffice a MS Office nie jest pełna. Ma to szczególny wpływ na każdego użytkownika, który musi cz˛esto tworzyć z innymi użytkownikami wpólne dokumenty. Jeśli w takich przypadkach wykorzystywane sa˛ obydwa warianty pakietu Office, wówczas prowadzi to z reguły do problemów z formatowaniem. ◦ Chart-Engine z OpenOffice.org badź ˛ ze StarOffice nie wykazuje tych samych możliwości, co MS Excel Chart-Engine. Dotyczy to w szczególności 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ń ˛ OSS i produktów COLS moga˛ jednak raczej przeszkadzać powody ekonomiczne niż funkcjonalne. Dotyczy to zwłaszcza migracji desktopów: ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 448 ◦ MS Office Zakres i złożoność migrowanych makr, skryptów, szablonów i dokumentów może sprawić, że przejście na OpenOffice.org albo StarOffice stanie si˛e nieopłacalne. ◦ MS Office Professional Analogiczny problem z konwersja˛ dotyczy MS Access i aplikacji Access, które trzeba zastapić, ˛ używanych cz˛esto do automatyzacji prostych procesów. ◦ aplikacje specjalistyczne W zależności od stopnia wykorzystania natywnych windowsowych aplikacji specjalistycznych, w niekorzystnym przypadku migracja zast˛epujaca ˛ może być niemożliwa do czasu, gdy dost˛epne b˛eda˛ alternatywne produkty. (patrz rozdział 5.3). Dotyczy to także aplikacji tworzonych w oparciu o MS Exchange i wykorzystujacych ˛ go jako runtime environment. 5.2.1.1 Stacje robocze Praca stacji roboczych odbywa si˛e w oparciu o Linuksa. W tym miejscu nie można zalecić określonej dystrybucji (patrz 0). Decyzj˛e należy podjać ˛ dla konkretnego przypadku i w zależności od specyficznych wymagań danej administracji. Do zastosowań w obszarze biura można polecić zarówno OpenOffice.org, jak i StarOffice. Decyzja odnośnie wyboru tego lub innego produktu zależy od specyficznych wymagań danego urz˛edu. Tak samo jak Microsoft Office, StarOffice i OpenOffice.org oferuja˛ aplikacje niezb˛edne w codziennej pracy (edytor tekstu, arkusz kalkulacyjny, kreator prezentacji) i pokrywaja˛ wymagania co do funkcjonalności. Dla produktu COLS, jakim jest StarOffice Suite, firma Sun stworzyła badź ˛ zaimplementowała dodatkowe składniki (czcionki TrueType, własne sprawdzanie pisowni, dodatkowe szablony oraz galeri˛e zdj˛eć, baz˛e danych ADABAS). W przeciwieństwie do tego OpenOffice.org jest członkiem rodziny OSS i nie wymaga kosztów licencyjnych. Różnice funkcjonalne i techniczne pomi˛edzy tymi obydwoma pakietami biurowymi sa˛ marginalne. Kolejnym ważnym interfejsem dla użytkowników jest właściwy system desktopowy. W dystrybucjach Linuksa zaimplementowane sa˛ na ogół gotowe desktopy, kóre tak samo jak w przypadku desktopu Windows zawieraja˛ najistotniejsze aplikacje. Dwoma najważniejszymi przedstawicielami systemów desktopowych sa˛ KDE i GNOME. Wybór systemu desktopowego jest w pierwszej kolejności odpowiedzia˛ na pytanie o własny gust i każdorazowe preferencje wzgl˛edem określonych aplikacji. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 5.2.1.2 449 Serwer WWW Serwer Apache (patrz także rozdział 3.11.4) jest obecnie miernikiem udost˛epniania treści w Internecie i Intranecie. Elastyczność uzyskana dzi˛eki modularnej budowie i ilość dost˛epnych modułów uczyniły go czołowym produktem na rynku serwerów WWW. Składnik ten odznacza si˛e wieloletnim czasem stosowania w dużych produkcyjnych środowiskach, stabilnościa,˛ pełnymi funkcjami bezpieczeństwa i dost˛epnym, szerokim, profesjonalnym wsparciem, które można sobie dowolnie wybrać. 5.2.1.3 Składowanie plików Dla usług zwiazanych ˛ z plikami wewn˛etrz środowiska 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 sieć. NFS jest standardowo używanym protokołem, gdy trzeba współdzielić katalogi z różnych systemów uniksowych. Użytkownikom można udost˛epniać potrzebne katalogi za pomoca˛ centralnych albo zdecentralizowanych serwerów. Eksportowane drzewa katalogów automatycznie przypisywane sa˛ użytkownikom pracujacym ˛ na danej stacji roboczej. Do fizycznego zapisywania danych na systemach dysków właściwych serwerów zaleca si˛e skorzystanie z systemów plików XFS i EXT3. Obydwa systemy obsługuja˛ Journaling, kwotowanie i przydzielanie praw dost˛epu na poziomie katalogu i pliku. 5.2.1.4 Drukowanie Do udost˛epniania usług drukowania zaleca si˛e wyłacznie ˛ „Common UNIX Printing System (CUPS)“. Jest on wyróżniajacym ˛ si˛e systemem praktycznie we wszystkich systemach uniksowych i de - facto standardem we wszystkich dużych dystrybucjach (SuSE, Debian, RedHat, itd.). Usługa drukowania CUPS oferuje wszystkie konieczne funkcje do udost˛epniania infrastruktury wydruku. CUPS obsługuje wiele różnych drukarek i jest w stanie udost˛epniać konkretnym użytkownikom specyficzne opcje drukowania. CUPS oparty jest na Internet Printing Protocol, zdefiniowanym, 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 ˛ infrastruktur˛e dla sieci opartych o protokół TCP/IP sa,˛ z uwagi na swoje uniksowe pochodzenie, standardowo dost˛epne 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ównież wskazana jest implementacja referencji z Internet Software Consortium. 5.2.2 Średnie i duże urz˛edy Średnie i duże urz˛edy odznaczaja˛ si˛e swoimi szczególnymi architekturami informatycznymi i potrzebuja˛ w niektórych obszarach zastosowań innych zaleceń migracyjnych niż mniejsze placówki. Poczawszy ˛ od pewnej wielkości, urz˛edy dysponuja˛ na ogół zarówno architekturami zdecentralizowanymi, jak też centralnymi. Pierwsze sa˛ najcz˛eściej wykorzystywane w urz˛edach 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 odnośnie bezpieczeństwa informatycznego, wydajności i skalowalności. Wewn˛etrznie definiowane standardy jakości wymuszaja˛ gwarancj˛e wysokiej niezawodności i intensywnej opieki użytkowników nad centralnymi składnikami. Wykonanie tego typu zadań można zagwarantować tylko poprzez intensywne stosowanie platform do zarzadzania ˛ systemem, w szczególności do monitorowania systemu i sieci. Zdecentralizowane architektury wyst˛epuja˛ w urz˛edach przede wszystkim w przypadku komunikacji biurowej, edycji dokumentów i specyficznych aplikacji specjalistycznych. Cz˛esto 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 zdecentralizowanego administrowania systemem. Do realizacji specyficznych wymagań technicznych i wymagań zwiazanych ˛ z architektura, ˛ oprócz składników wymienionych w rozdziale 5.2.1 zalecane sa˛ zwłaszcza składniki dostosowane do szczególnych wymagań dużych środowisk. Odnośnie zaleceń dotyczacych ˛ oceny ekonomicznej w przypadku migracji zast˛epujacej ˛ w dużych i średnich urz˛edach patrz rozdział 4.6.1 oraz 4.8.6.5. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 451 Rysunek 5.3: Zalecana architektura IT w dużym urz˛edzie w przypadku całkowitej „zast˛epujacej ˛ migracji“ 5.2.2.1 Systemy zarzadzania ˛ bazami danych Wymagania wzgl˛edem systemów zarzadzania ˛ bazami danych wewnatrz ˛ dużych centralnych architektur informatycznych różnia˛ si˛e zwłaszcza z uwagi na stabilność, wydajność i bezpieczeństwo. Z czystych stystemów bazodanowych należacyh ˛ do rodziny Open Source, wi˛ekszym urz˛edom zaleca si˛e, ze wzgl˛edu na spełnienie wymagań, stosowanie SAP DB. SAP DB była i jest udost˛epniana przez SAP (patrz rozdział 3.13.4) jako certyfikowana platforma dla systemu R/3 i jego nast˛epców oraz jest stosowana we własnych produktach jako kluczowa technologia. Zakres funkcji w/w bazy danych obejmuje oprócz obsługi transakcji także Trigger i Stored Procedures. Jeśli wymagania sa˛ wi˛eksze, wzgl˛ednie 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 5.2.2.2 452 Groupware Dobrze skalowalnym rozwiazaniem ˛ opartym na Linuksie i odpowiednim dla dużych środowisk jest Samsung Contact (produkt COLS). Z uwagi na swoja˛ architektur˛e, która składa si˛e z wielu niezależnych od siebie komponentów dajacych ˛ si˛e w myśl skalowania horyzontalnego przydzielać do różnych serwerów, spełnia on szczególne wymagania dużych środowisk. Oprócz instalacji Single - Server, Samsung Contact obsługuje również instalacj˛e dzielona˛ pomi˛edzy wieloma stanowiskami i tym samym oferuje skalowalne rozwiazanie ˛ także dla dzielonych stanowisk. 5.2.2.3 Usługi katalogowe Z uwagi na swoja˛ centralna˛ rol˛e polegajac ˛ a˛ na zapewnieniu wydajnego zarzadzania ˛ systemem i bezpieczeństwa informatycznego usługi katalogowe odgrywaja˛ decydujac ˛ a˛ rola˛ przy integracji aplikacji i systemów z platformami. Wraz z rosnacym ˛ znaczeniem usług autoryzacji przeznaczonych dla aplikacji WWW, jak też z powodu rosnacych ˛ wymagań wzgl˛edem komfortu autoryzacji, znany już wcześniej model Directories (usługi katalogowe) oraz Meta-Directories został uzupełniony o kolejne składniki i przekształcony w całościowy system nazywany cz˛esto Identity Management (patrz także poniższy rysunek). RYSUNEK DO POPRAWKI Rysunek 5.4: Obszary zastosowań usług katalogowych na przykładzie platformy SunOne Zasadniczo przy budowaniu usług katalogowych można skorzystać zarówno z produktów OSS, jak i COLS. Można tu wyróżnić dwa istotne scenariusze zastosowań: 1. Realizacja podstawowych funkcji umożliwiajacych ˛ autoryzacj˛e oraz zarzadzanie ˛ profilami w oparciu o protokół LDAP. W tym przypadku alternatyw˛e OSS jaka˛ jest OpenLDAP należy na ogół postrzegać jako wystarczajac ˛ a˛ i opłacalna.˛ 2. Realizacja rozszerzonych funkcji umożliwiajacych ˛ zwi˛ekszenie wydajności zarzadzania, ˛ np. poprzez obejmujac ˛ a˛ wiele aplikacji synchronizacj˛e wykorzystywanych danych lub autoryzacj˛e. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 453 W tym przypadku można generalnie wyjść z założenia, że zastosowanie komercyjnych produktów b˛edzie korzystniejsza finansowo od własnego rozwiazania. ˛ 5.2.2.4 Zarzadzanie ˛ systemem Jeśli chodzi o spełnienie zwi˛ekszonych wymagań odnośnie zarzadzania ˛ systemem narzuca si˛e, np. skorzystanie z produktów Tivoli albo OpenView. Oprócz tych komercyjnych rozwiazań ˛ istnieja˛ inne możliwości zarzadzania ˛ systemem z wykorzystaniem narz˛edzi wchodzacych ˛ w skład systemu operacyjnego, które wykonuja˛ określone zadania (patrz rozdział 3.6). 5.2.3 Specjalizowane urz˛edy świadczace ˛ usługi informatyczne Urz˛edy, które m.in. wyst˛epuja˛ także jako specjalizowani dostawcy usług informatycznych w środowisku administracji, posiadaja˛ z reguły silnie scentralizowane architektury informatyczne. Cz˛esto realizuja˛ one swoje oferty w ramach centrów obliczeniowych oraz centrów danych i świadcza˛ usługi informatyczne dla innych urz˛edów, np. jako tak zwany „Application Service Provider“ (ASP). Dominujace ˛ centralne architektury służace ˛ realizacji konkretnych procedur specjalistycznych (ERP, . . . ) cz˛esto łacz ˛ a˛ si˛e z bardzo wysokimi wymaganiami odnośnie wydajności i skalowalności systemów. Dlatego stosuje si˛e tam cz˛esto wysokowartościowe i po cz˛eści drogie systemy oprzyrzadowania ˛ przeznaczone do wykonywania automatycznych obliczeń, np. Storage Area Networks (SAN) do zabezpieczania i archiwizacji danych. Takie specjalizowane urz˛edy przykładaja˛ duża˛ wag˛e do bezpieczeństwa informatycznego, wydajności i skalowalności. Zdefiniowane tam standardy jakości, które z reguły potwierdzane sa˛ z każdym klientem na piśmie, wymagaja˛ wysokiej niezawodności systemu i intensywnej opieki użytkowników. W celu efektywnego zarzadzania ˛ systemem stosuje si˛e specjalne platformy do zarzadzania ˛ systemem, które oferuja˛ wysoki stopień 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 urz˛edu w przypadku całkowitej „zast˛epujacej ˛ 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 określonego osprz˛etu (SAN) oraz oprogramowanie były certyfikowane, gdyż dopiero wówczas wolno je w nich stosować. Wiele systemów bazodanowych opartych na Linuksie (SAP DB, Oracle, DB2, itd.) posiada już odpowiednie certyfikaty. Użytkownicy centrów obliczeniowych moga˛ dodatkowo korzystać z certyfikowanych dystrybucji Linuksa jako podstawowego systemu oparacyjnego dla każdorazowych zastosowań. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 5.2.3.2 455 Serwery aplikacji Do realizacji skomplikowanych scenariuszy aplikacji cz˛esto stosuje si˛e serwery aplikacji. W ramach specjalistycznych aplikacji implementuja˛ one skomplikowane procesy i reguły biznesowe jednocześnie udost˛epniajac ˛ zewn˛etrzne systemy. Serwer aplikacji musi być w stanie zagwarantować zarzadzanie ˛ sesjami użytkowników, udost˛eniać odpowiednie interfejsy zewn˛etrznym aplikacjom oraz dysponować koniecznymi, wysoce niezawodnymi rozwiazaniami ˛ (Cluster, LoadBalancing, Failover). Oprócz znanych komercyjnych produktów (COLS) takich jak, p. IBM Websphere, BEA Weblogic, Oracle Application Server i kilku innych istnieje także możliwość zastosowania rozwiazania ˛ OSS. Projekt „JBoss“ oferuje kompletny Java - Applications - Server na bazie Open Source. Niniejszy serwer aplikacji obsługuje specyfikacj˛e J2EE, zawiera zintegrowany serwer WWW, JSP-Engine i Servlet-Engine, oferuje obsług˛e Enterprise Java Beans i Clastering oraz liczne inne funkcje. 5.2.3.3 Zarzadzanie ˛ systemem W przypadku specjalizowanych urz˛edów, z uwagi na cz˛eściowo porównywalne wymagania, obowiazuj ˛ a˛ takie same zalecenia, jak w przypadku dużych i średnich urz˛edów (patrz rozdział). 5.2.4 Małe urz˛edy Ze wzgl˛edu na swoja˛ lokalna˛ koncentracj˛e małe urz˛edy posiadaja˛ z reguły centralne architektury informatyczne, które jednak nie maja˛ charakteru centrów obliczeniowych. Duże procedury na ogół wykonywane sa˛ poza własnym urz˛edem. Zadania takie cz˛esto zlecane sa˛ centrom obliczeniowym. Zdefiniowane standardy jakości obowiazuj ˛ ace ˛ wewnatrz ˛ urz˛edu nie stawiaja˛ szczególnych wymagań, jeśli chodzi o niezawodność i opiek˛e użytkowników (normalne godziny pracy). Do zabezpieczania i archiwizacji danych stosowany jest na ogół standardowy osprz˛et. Rzadko wykorzystuje si˛e platformy zarzadzania ˛ systemem. Preferuje si˛e wykonywanie zadań za pomoca˛ pojedynczych narz˛edzi i skryptów. Mniejsze placówki cechuja˛ si˛e małymi do średnich wymaganiami wzgl˛edem bezpieczeństwa informatycznego, wydajności i skalowalności. First i SecondLevel Support jest cz˛esto połaczony ˛ i odbywa si˛e na ogół bez narz˛edzi obsługujacych ˛ zarzadzanie ˛ problemami. Nie jest tak, że produkty OSS musza˛ być zawsze dostosowane do rozmiaru realizowanych zadań. Skalowalne produkty takie jak Samsung Contact albo SunOne Directory Server moga˛ spełnić wszystkie wymagania mniejszych urz˛edów. Należy jednak wiedzieć i zastanowić si˛e nad ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 456 tym, że duże rozwiazania ˛ z reguły wymagaja˛ wi˛ekszych nakładów podczas instalacji i konfiguracji. Odnośnie zaleceń co do oceny ekonomicznej w przypadku migracji zast˛epujacej ˛ dla dużych i średnich urz˛edów patrz rozdział 4.6.1 i 4.8.6.5. Rysunek 5.6: Zalecana architektura IT dla małego urz˛edu w przypadku całkowitej „zast˛epujacej ˛ migracji“ 5.2.4.1 Systemy zarzadzania ˛ bazami danych Oferta alternatywnych systemów bazodanowych Open Source jest bardzo różnorodna. Wszystkie systemy baz danych, które szczegółowo ocenione zostały w rozdziale 3.13.4, dobrze nadaja˛ si˛e do zastosowania w nakreślonych tam ramach. W oparciu o funkcjonalne właściwości nie można ogólnie, prosto i jednoznacznie wskazać SAP DB, MySQL albo PostgreSQL jako zalecanej bazy danych. Decyzja o wyborze tego badź ˛ ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 457 innego systemu bazodanowego musi zapaść osobno w każdym przypadku, w zależności od planowanego środowiska programistycznego i runtime environment, zwłaszcza w kontekście rozwoju aplikacji WWW i DB z udziałem PHP. Jednak z uwagi na ścisła˛ integracj˛e z tym j˛ezykiem programowania optymalnym rozwiazaniem ˛ może być MySQL. 5.2.4.2 Groupware Oprócz zalecanego w przypadku dużych urz˛edów Samsung Contact, również dla małych placówek skorzystanie z niego jest możliwe. Poza tym rozwiazaniem, ˛ jeśli chodzi o małe do średnie organizacje, w przyszłości liczyć si˛e może z pewnościa˛ także Kroupware (patrz 3.14.4) stanowiacy ˛ adekwatna˛ podstaw˛e pracy grupowej. Zaleta˛ tego rozwiazania ˛ jest gł˛eboka integracja GNU / Linux - Groupware - Client z desktopem KDE. W przyszłości Kroupware oferowane b˛edzie na licencji GPL i jako takie, z uwagi na apsekt pieni˛eżny, rozwiazanie ˛ to b˛edzie stanowić interesujac ˛ a˛ alternatyw˛e. W tym kontekście należy wskazać na to, że możliwe tu b˛edzie korzystanie z wtyczki Open Source o nazwie „Ägypten“ b˛edacej ˛ narz˛edziem zgodnym ze SPHINX i służacym ˛ do szyfrowania i podpisywania poczty elektronicznej. Urz˛edy, które ze wzgl˛edu na prac˛e w trybie offline nie potrzebuja˛ rozwiazań ˛ umożliwiajacych ˛ prac˛e grupowa, ˛ moga˛ także korzystać z klienta WWW. W takim przypadku możliwe rozwiazanie ˛ stanowi również phpGroupware. 5.2.4.3 Usługa katalogowa Dla urz˛edu, w którym ważne informacje przekazywane sa˛ poprzez sieć, zaleca si˛e zastosowanie usługi katalogowej OSS jaka˛ jest OpenLDAP. Usługa ta może służyć, m.in. do administrowania użykownikami, autoryzacji użytkowników, inwentaryzacji posiadanego osprz˛etu i innych ustawień infrastrukturalnych (wpisy DNS, konfiguracje DHCP, itd.). OpenLDAP oferuje wszystkie powszechne i konieczne funkcje (patrz rozdział 3.7.4) pełnowartościowej usługi katalogowej. 5.2.4.4 Zarzadzanie ˛ systemem Dla małych urz˛edów zalecane jest przede wszystkim zastosowanie obszernych narz˛edzi dostarczanych wraz z systemem operacyjnym GNU / Linux. Narz˛edzia te (ssh, cron / at, pot˛eżne interpretatory pracujace ˛ z linii poleceń, Utilities i interpretowane j˛ezyki programowania) można zaprz˛egnać ˛ do zautomatyzowania pracy Routine. Inne narz˛edzia i produkty służ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, że we wszystkich obszarach zachowana zostaje linia produktów firmy Microsoft. Teoretycznie można sobie wyobrazić dwie sytuacje wyjściowe, które uzasadniaja˛ tego typu migracj˛e. W żadnej z opisanych poniżej sytuacji powody techniczne nie odgrywaja˛ jednak decydujacej ˛ roli. Z małymi wyjatkami, ˛ dla każdego z ocenianych wymagań istnieja˛ alternatywne rozwiaza˛ nia techniczne, które moga˛ pracować pod kontrola˛ Linuksa. W końcu to ekonomiczne powody przyczyniaja˛ si˛e do realizacji całkowitej „kontynuacyjnej migracji“. Pierwsza z ocenianych tu sytuacji wyjściowych została opisana w rozdziale 2 niniejszego poradnika jako środowisko systemu Windows NT 4 z Exchange 5.5, MS SQL Server 7, IIS 4 oraz Office 97 badź ˛ Office 2000. Jest ona nacechowana już bardzo wysokim stopniem integracji. Wielkościami określajacymi ˛ stopień integracji sa˛ m. in.: ◦ ilość specjalistycznych procedur dost˛epnych tylko jako aplikacje windowsowe ◦ dost˛epność kodu źródłowego tych procedur ◦ gł˛ebokość integracji poszczególnych specjalistycznych procedur, zwłaszcza w środowisku MS Office ◦ zakres wykorzystania specyficznych dla Microsoftu – środowisk programistycznych – interfejsów – j˛ezyków programowania ◦ ilość makr i skryptów specyficznych dla MS Office (np. implementacja obejmujacych ˛ wiele działów Workflows). Nakłady na migracj˛e zast˛epujac ˛ a˛ rosna˛ wraz ze wzrostem stopnia integracji. Ostateczna˛ wypowiedź na temat, jaki stopień integracji uzasadnia przeprowadzenie migracji kontynuacyjnej, można sformułować tylko po dokonaniu szczegółowym oceny pojedynczych migrowanych składników w oparciu o wyniki dokł˛ebnej oceny ekonomicznej. W praktyce, wskutek kroczacego ˛ rozwoju platformy .NET, zainstnieje z czasem sytuacja wyjściowa, która ujawni tak wysoki stopień integracji, przy którym migracja b˛edzie znacznie ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 459 utrudniona. Takiemu rozwojowi sytuacji można zapobiec dzi˛eki przeprowadzeniu we właściwym czasie migracji cz˛eściowej (patrz rozdział 5.4). Rysunek 5.7: Sytuacja wyjściowa dla migracji kontynuacyjnej Druga z ocenianych sytuacji wyjściowych przedstawia środowisko informatyczne, w którym już 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 zaleceń migracyjnych (5.2.1) oznacza to, że w optymalnym przypadku mamy do czynienia z nast˛epujacym ˛ modelem: ◦ stacje robocze: klienty Windows 2000 z Office 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). Jeśli pojedyncze elementy niniejszej architektury (jeszcze) nie sa˛ używane, wówczas w ramach migracji cz˛eściowej można w ich miejsce zaproponować adekwatne rozwiazania. ˛ Odpowiednie zalecenie na ten temat oraz dalsze wskazówki znajduja˛ si˛e w rozdziale 5.4. Reguła ochrony inwestycji, w przypadku w/w sytuacji wyjściowej uzasadnia to, żeby znajdujace ˛ si˛e już w użyciu składniki nie podlegały migracji zast˛epujacej ˛ ani cz˛eściowej w czasie najbliższych 4 - 5 lat. Poniżej wymienione zostały przyczyny, dla których tego typu sytuacja wyjściowa mimo wszystko jest rozważana w zaleceniach migracyjnych: ◦ niniejszym urz˛edom wskazuje si˛e drogi minimalizacji wspomnianego wyżej stopnia integracji i tym samym zależności od produktów Microsoftu. ◦ niniejszym urz˛edom przekazuje si˛e ponadto zalecenia odnośnie późniejszej drogi migracji, w stopniu jaki jest obecnie możliwy. ◦ z długofalowego ekonomicznego punktu widzenia migracja kontynuacyjna nie jest szczególnie zalecana, zwłaszcza w kontekście uzależniania si˛e od producenta. Migracja kontynuacyjna może mieć sens przede wszystkim wówczas, gdy koszty migracji w obszarze specjalistycznych aplikacji opartych na platformie Microsoftu i wymagajacych ˛ przeprogramowania w przypadku przejścia do Open Source, nie wykazuja˛ długofalowej rentowności takiej migracji. ◦ odnośnie zaleceń dotyczacych ˛ oceny ekonomicznej migracji kontynuacyjnej patrz rozdział4.6.2 i 4.8.6.6. 5.3.1 Minimalizacja stopnia integracji, zachowanie stopni dowolności Jak już wspomnieliśmy, celem w przypadku migracji kontynuacyjnej i korzystanie z Windows 2000 wraz z Active Directory powinna być redukcja uzależnienia od produktów Microsoftu, tak by w przyszłości można było skorzystać ze wszystkich możliwości migracji zast˛epujacej. ˛ Należy zatem przestrzegać nast˛epujacych ˛ zaleceń: ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 461 Usłga katalogowa: ◦ wykorzystywanie Active Directory, jeśli w ogóle, powinno mieć miejsce tylko jako „Active Directory w minimalnej postaci“ (patrz rozdział 3.7.5). ◦ nie należy stosować AD jako źródła LDAP dla dodatkowych aplikacji (np. aplikacji webowych). ◦ dane osobowe dla AD należy pozyskiwać z różnych źródeł, np. przenoszac ˛ je albo wypełniajac ˛ z MetaDirectory. ◦ jeśli zaplanowano role concept należy unikać stosowania oprogramowania, które wymaga AD badź ˛ w przypadku którego AD jest podstawa˛ działania Desktop ◦ nie należy stosować 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 skonsolidowanie, o ile nie zostało to już zrobione podczas migracji. W miar˛e możliwości należy unikać wprowadzania nowych aplikacji z tego zakresu. ◦ wyboru aplikacji i zlecanie ich rozwoju należy dokonywać w zgodności z SAGA (patrz rozdział 3.8). ◦ w miar˛e możliwości nie należy korzystać z aplikacji innych producentów, których programy wymagaja˛ do pracy produktów MS Office jako jedynego runtime environment. Wyjatkiem ˛ sa˛ tu specjalistyczne aplikacje, jeśli przejściowo nie istnieja˛ dla nich rozwiazania ˛ alternatywne. ◦ należy sukcesywnie zast˛epować aplikacje (specjalistyczne) wymagajace ˛ do pracy produktów MS Office. Składowanie plików ◦ odtworzenie struktur uprawnień należy wykonać za pomoca˛ skryptów (np. Perl). W przypadku pracy w środowisku graficznym konieczne jest szczegółowe i pełne udokumentowanie wszystkich ustawień konfiguracyjnych. Ponieważ z uwagi na znane ludzkie słabości nie zawsze można to zagwarantować, lepsza˛ droga˛ jest skorzystanie ze skryptów. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 462 ◦ jeśli nie ma potrzeby używania lokalnych grup, to nie należy ich używać. Groupware / Messaging ◦ serwery Exchange 2000 nie powinny być stosowane jako centralne Mail - Router. Zamiast nich należy skorzystać z produktów OSS (np. Postfix, Sendmail), co ma na celu pozostawienie otwartej możliwości na równoległe korzystanie z wielu systemów poczty elektronicznej. ◦ w publicznych katalogach Exchange nie należy stosować aplikacji. Aplikacje WWW ◦ ze wzgl˛edu na zgodność z SAGA i dost˛epność różnych alternatywnych rozwiazań ˛ nie należy stosować produków Microsoftu (patrz rozdział 3.9) ◦ należy unikać autoryzacji domen stosujac ˛ dodatkowy poziom autoryzacji. Dodatkowe hasło można z reguły zaakceptować i przede wszystkim uzasadnić z punktu widzenia bezpieczeństwa. W wyjatkowych ˛ sytuacjach można skorzystać z różnych produktów OSS. Zarzadzanie ˛ systemem ◦ należy zastosować produkty innych producentów, którzy wspieraja˛ także rozwiazania ˛ linuksowe (np. Tivoli). Middleware ◦ jeśli chodzi o środowisko programistyczne, w celu zwi˛ekszenia możliwości wielokrotnego wykorzystania kodu, należy preferować gł˛eboka˛ integracj˛e ze standardami zgodnymi z SAGA. ◦ w celu komunikacji i wymiany danych z zewn˛etrznymi systemami należy stosować technologi˛e XML i Web Service (jeśli pozwalaja˛ na to wzgl˛edy bezpieczeństwa, patrz rozdziały 4 i 5). ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 463 5.3.2 Inne ścieżki migracji Jeśli chodzi o dalsza˛ migracj˛e, należy najpierw rozpatrzeć migracj˛e na stacjach roboczych do Windows XP. Także tu obowiazuje ˛ reguła ochrony inwestycji. Ze wzgl˛edu na nia,˛ w przypadku opisanej powyżej sytuacji wyjściowej, migracja na stacjach roboczych do Windows XP może nie być zalecana. Jeśli uwzgl˛edni si˛e zasad˛e ochrony inwestycji, wówczas kolejna migracja powinna odbyć si˛e najwcześniej po upływie 4 - 5 lat. Jeśli zatem poprzedniej migracji dokonano w 2001 roku, wówczas nast˛epna może odbyć si˛e najwcześniej w roku 2005. Szczególnie urz˛edy, które wcześniej postapiły ˛ zgodnie z zaleceniami dotyczacymi ˛ minimalizacji uzależnienia od produktów Microsoftu, musza˛ koniecznie sprawdzić czy w swoich technicznych i ekonomicznych warunkach powinny przeprowadzić migracj˛e zast˛epujac ˛ a˛ czy kontynuacyjna.˛ To samo dotyczy wszystkich innych urz˛edów, które znajduja˛ si˛e w takiej samej sytuacji wyjściowej. 5.4 Migracja cz˛eściowa 5.4.1 Migracja punktowa Migracja punktowa polega na trwałym zastapieniu ˛ składnika systemu b˛edacego ˛ produktem Microsoftu przez rozwiazanie ˛ OSS badź ˛ COLS, podczas gdy pozostała migracja jest migracja˛ kontynuacyjna. ˛ W niniejszym rozdziale przedstawione zostały sensowne i wykonalne migracje punktowe. Najważniejsza˛ migracja˛ punktowa˛ jest przy tym zastapienie ˛ Exchange 5.5. Powodem takiego zastapienia ˛ jest to, że Microsoft na dzień 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 urz˛edów nie wchodzi w rachub˛e, ponieważ rozwiazanie ˛ to wymusza zastosowanie Active Directory. Za pomoca˛ Exchange 2000 Microsoft przeniósł wewn˛etrzna˛ usług˛e katalogowa˛ z Exchange 5.5 na zewnatrz, ˛ skutkiem czego było stworznie Active Directory, który stał si˛e centrum świata opartego na Windows 2000. Dlatego Exchange 2000 może pracować tylko z serwerem Windows 2000 lub jego nast˛epcami. W zwiazku ˛ z tym wiele urz˛edów jest poważnie zainteresowanych alternatywnym rozwiaza˛ niem Groupware / Messaging, które zaoferuje podobny albo taki sam zakres funkcji, nie obsługujacym ˛ AD i umożliwiajacym ˛ dalsze korzytanie z klientów MS Outlook. 4 http://support.microsoft.com/default.aspx?scid=fh;en-us;lifesrvr ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 464 Do dyspozycji jest wiele różnych rozwiazań ˛ alternatywnych (patrz także poniższy rysunek). W przypadku wyższych wymagań wzgl˛edem kompatybilnosci należy przede wszystkim rozważyć dwa rozwiazania ˛ dla różnych wymagań: ◦ Samsung Contact ◦ Exchange4Linux W obydwu przypadkach dzi˛eki dobremu połaczniu ˛ MAPI można kontynuować korzystanie z Outlook-Client w ramach jego najistotniejszych funkcji. Dokładniejsze oceny techniczne i porównanie funkcjonalności w/w rozwiazań ˛ znaleźć można w rozdziale 3 („Techniczne opisy migracji“). Model rachunku ekonomicznego w przypadku migracji do Samsung Contact znajduje si˛e w rozdziale „Ocena wydajności ekonomicznej“ (patrz rozdział 4). Rysunek 5.8: Różne warianty zastapienia ˛ Exchange w przypadku migracji cz˛eściowej Samsung Contact, dokładnie tak jak Exchange, nie jest produktem OSS lecz należy do kategorii własnościowego oprogramowania COLS. Migracja do Samsung Contact została już oceniona w zaleceniach dotyczacych ˛ całkowitej „zast˛epujacej ˛ migracji“ (patrz rozdział 3.14.4). ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 465 Samsung Contact nadaje si˛e zwłaszcza do dużych specjalizowanych urz˛edów stawiajacych ˛ szczególne wymagania odnośnie skalowalności i bezawaryjności. Dla urz˛edów do 500 użytkowników można również polecić tańsze rozwiazanie ˛ jakim jest Exchange4Linux. Jest to w istocie produkt OSS. Serwer dost˛epny jest jako Wolne Oprogramowanie, jedynie MAPI - Connector jest własnościowy i trzeba za niego zapłacić. Bliższe informacje w rozdziale 3.14.4. W przypadku obydwu rozwiazań ˛ po stronie serwera potrzebny jest system operacyjny GNU / Linux. Przeprowadzenie migracji punktowej oferuje cały szereg korzyści: ◦ bardziej przejrzysty i dajacy ˛ si˛e dobrze zaplanować zakres migracji. Konieczne dostosowania mieszcza˛ si˛e w ograniczonych ramach, co jest istotna˛ zaleta˛ podczas planowania i kierowania projektem. ◦ istnieje możliwość stopniowego jednoczesnego rozwijania pomysłów na prac˛e i zbieranie doświadczeń oraz budowania platformy opartej o nowy system operacyjny. ◦ nakłady na szkolenia ponoszone sa˛ tylko na wykształconych już w danym kierunku administratorów. Doszkalani administratorzy moga˛ także posłużyć w dziale informatyki jako osoby przekazujace ˛ innym swoja˛ wiedz˛e. W kontekście Groupware i Messaging trzeba w tym miejscu zauważyć, że w przypadkach, gdzie potrzebne sa˛ funkcje Groupware, wyłaczna ˛ migracja funkcji poczty elektronicznej staje si˛e znacznie łatwiejsza ˛ do wykonania. W rzeczy samej jest to rozwiazanie ˛ już wielokrotnie wypróbowane i preferowane. Kolejna możliwość migracji punktowej polega na zastapieniu ˛ MS Office przez OpenOffice.org albo StarOffice. Należy przy tym wziać ˛ pod uwag˛e opisane już ograniczenia a zwłaszcza także konsekwencje ekonomiczne. Migracja pakietu Office została już oceniona w rozdziale „Całkowita > >zast˛epujaca ˛ migracja< <“ (5.2). Odnośnie zaleceń wynikajacych ˛ z oceny ekonomicznej w przypadku migracji punktowej patrz rozdziały 4.6.3.1 i 5.4. 5.4.2 Cz˛eściowa migracja po stronie serwera W nieniejszym rozdziale, na przykładzie szerokiej migracji po stronie serwera, prezentowany jest sensowny i godny polecenia scenariusz cz˛eściowej migracji po stronie serwera. Jako sytuacj˛e wyjściowa˛ dla tej migracji przyj˛eto środowisko 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óżnice wynikaja˛ z faktu, że strona klientów nadal składa si˛e z systemów windowsowych. O zaleceniach dla: ◦ systemu baz danych, ◦ serwera WWW ◦ i usług sieciowych można przeczytać także w rozdziale 5. Główny wymóg wzgl˛edem migracji po stronie serwera dotyczy bezawaryjnej współpracy linuksowych serwerów z windowsowymi klientami po przeprowadzeniu migracji. Najważniejszym zadaniem podczas samej migracji jest zastapienie ˛ sposobu składowania plików, drukowania, usług sieciowych i usług logowania oraz migracja istniejacych ˛ struktur plików, uprawnień, jak też przeniesienie danych konfiguracyjnych. W ramach oceny ekonomicznej okazuje si˛e, że około 65% - 80% kosztów projektu zapisać można po stronie oszcz˛edności. Dodatkowe nakłady leżace ˛ powyżej tych wskaźników wynikaja˛ w istocie z kosztów osobowych zwiazanych ˛ z pracami migracyjnymi. Dla tego typu migracji oznacza to, że z reguły nie da si˛e przedstawić bezpośredniej pieni˛eżnej korzyści w porównaniu z migracja˛ kontynuacyjna.˛ O wiele bardziej o przyj˛eciu projektu decydować tu b˛eda˛ mi˛ekkie czynniki wyrażone w formie kryteriów, takich jak konieczność i strategia. O zaleceniach wynikajacych ˛ z oceny ekonomicznej w przypadku szerokiej migracji można przeczytać w rozdziale 4.6.3.2 i 5.4. Zarzadzanie ˛ użytkownikami i autoryzacja W celu zastapienia ˛ kontrolera domen Windows NT 4.0 zaleca si˛e skorzystanie z linuksowego serwera Samba w połaczeniu ˛ z OpenLDAP. Współpracujaca ˛ z Linuksem Samba umie całkowicie zastapić ˛ kontroler domen Windows. Szczególnie dotyczy to najnowszej Samby od wersji 3.0, która została już sukcesywnie przetestowana w projekcie migracyjnymi Federalnego Urz˛edu ds. Karteli. Oferuje ona niemal nieograniczona˛ możliwość połaczenia ˛ klientów Windows 2000 z klientami Windows XP. Bliższe informacje na ten temat znaleźć można w technicznych opisach migracji w rozdziale 3. Zarzadzanie ˛ plikami i drukowanie Zgodnie z tym, co zostało już powiedziane, w przypadku zarzadzania ˛ plikami, tylko Samba zapewnia bezawaryjne połaczenie ˛ klientów windowsowych. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 467 Samba jest w stanie odwzorować pod Linuksem serwer plików oparty na Windows NT. Użytkownicy klientów windowsowych moga˛ równie dobrze korzystać ze swoich profilów i skryptów logowania znajdujacych ˛ si˛e na serwerze Samba, jak ze swoich katalogów domowych oraz grupowych. Jeśli chodzi o fizyczny zapis danych na systemach dysków właściwych serwerów zaleca si˛e 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 odbywać si˛e za pośrednictwem 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 wyjściowe, w przypadku których zalecana jest tego typu migracja. Szybka migracja jest przeciwieństwem łagodnej migracji. Obydwie wspomniane drogi migracji maja˛ na celu doprowadzenie do całkowitej „zast˛epujacej ˛ migracji“, to znaczy, że w przypadku obydwu dróg celem jest dojście do linuksowego systemu operacyjnego. Szybkiej migracji nie cechuje, wbrew temu co sugeruje jej nazwa, szybkość migrowania, lecz to, że migracj˛e t˛e wykonuje si˛e w jednym kroku, w przejrzystych, precyzyjnie określonych ramach czasowych. Szybka migracja ma zdefiniowany poczatek ˛ (data rozpocz˛ecia) i zdefiniowany koniec (data zakończenia). Wraz z końcem przypada poczatek ˛ pełnej pracy w czystym linuksowym środowisku informatycznym. Przeprowadzenie szybkiej migracji stawia wysokie, a nawet bardzo wysokie wymagania wzgl˛edem: ◦ organizacji projektu ◦ organizacji danego urz˛edu ◦ techniki ◦ finansowania ◦ administratorów ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 468 ◦ użytkowników Szczególnie nie wolno przy tym nie docenić wymagań dotyczacych ˛ administratorów i użytkowników. Ma to tym wi˛eksze znaczenie, im mniejszy dost˛ep maja˛ oni do wiedzy o nowym środowisku informatycznym. Z drugiej strony zaleta˛ szybkiej migracji jest to, że administratorzy nie musza˛ si˛e przez dłuższy czas zajmować dwoma różnymi kierunkami IT. Moga˛ oni we wzgl˛ednie krótkim czasie (odpowienim do wymagań projektu) skoncentrować si˛e na nowym systemie. Inna˛ ważna˛ rzecza˛ jest to, że w krótkim okresie czasu dost˛epne musi być wymagane finansowanie. O tym kiedy i ile środków finansowych należy udost˛epnić decyduje zakres i przede wszystkim stopień skomplikowania oraz różnorodność aplikacji i systemów przeznaczonych do migracji. Aspekt ten współdecyduje o możliwości przeprowadzenia szybkiej migracji. Wysokie wymagania co do organizacji urz˛edu koncentruja˛ si˛e z jednej strony na dokształceniu pracowników, którzy b˛eda˛ dalej musieli sprostać swoim codziennym obowiazkom. ˛ Oznacza to, że koniecznie należy dażyć ˛ do minimalizacji zakłóceń w pracy urz˛edu. Z drugiej strony musi być zachowana bieżaca ˛ praca systemów informatycznych. Szczególnie migracja całego środowiska serwerów stawia przed wszystkimi jej uczestnikami wysokie wymagania, gdyż migracji pojedynczych usług nie da si˛e dowolnie podzielić, administratorzy musza˛ zagwarantować bieżac ˛ a˛ prac˛e i jednocześnie musza˛ zostać wdrożeni do pracy z nowymi systemami. Niniejszym wymogom można sprostać dzi˛eki właściwemu Rollout oraz pomysłom na migracj˛e. Można to zrobić tworzac ˛ także rówonległe środowisko informatyczne, jednak zwi˛eksza to wymagania techniczne i powoduje dodatkowe koszty. Z uwagi na wspomniane wysokie wymogi powstaje oczywiście pytanie czy szybka migracja ma w ogóle sens, wzgl˛ednie dla kogo ma ona sens i komu można ja˛ polecić? Poniżej wymienione zostały powody uzasadniajace ˛ szybka˛ migracj˛e: ◦ istnieje przymus migracji, co znaczy, że na przykład kończy si˛e wsparcie dla starego systemu. ◦ intensywne, ale za to tylko jednorazowe a nie stopniowe, wieloletnie konfrontowanie administratorów i użytkowników z nowościami. ◦ administratorzy nie musza˛ przez długi czas pracować w skomplikowanych heterogenicznych światach. Na jakich warunkach i dla kogo szybka migracja ma sens? ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 469 Jeśli środowisko systemowe jest przejrzyste i nie jest ponad miar˛e „zawikłane“, wówczas warunek szybkiej migracji jest dobrze spełniony. Oznacza to, że aby spełnić zadania trzeba zastosować tylko niektóre aplikacje i usługi. Nie musi przy tym chodzić jedynie o małe i proste w swojej strukturze urz˛edy i organizacje. Dotyczy to na przykład także urz˛edów i organizacji zajmujacych ˛ si˛e bezpieczeństwem, w przypadku których wi˛eksza cz˛eść użytkowników wyposażona jest w niewiele dużych specjalistycznych aplikacji, gdyż sa˛ one najcz˛eściej zgromadzone na serwerze i tam wykonuja˛ przeważajac ˛ a˛ cz˛eść zadań. Dotyczy to jednak także małych oraz średnich urz˛edów o niewielkiej liczbie specjalistycznych aplikacji, korzystajacych ˛ 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˛ urz˛edy, w których administratorzy dysponuja˛ już konieczna˛ wiedza,˛ np. gdy zajmowali si˛e w wolnym czasie systemami linuksowymi albo gdy wykorzystywane sa˛ już pojedyncze linuksowe aplikacje i usługi (np. Mail Server pracujacy ˛ pod Linuksem). Jeśli do tego jeszcze współpracownicy wykazuja˛ niezb˛edna˛ otwartość na nowości i zainteresowanie Linuksem, sa˛ to wówczas również warunki do przeprowadzenia szybkiej migracji. 5.5.2 Łagodna migracja W niniejszym rozdziale opisane zostały powody i drogi łagodnej migracji. Jednak cóż tak właściwie oznacza poj˛ecie „łagodna migracja“? Jest to droga migracji, w przypadku której ustalony jest cel, jednak ramy czasowe określone sa˛ jedynie zgrubnie a poszczególne składniki migracji przewidziane sa˛ w oparciu o przedstawiony wyżej model architektury. Powody wyboru drogi łagodnej migracji staja˛ si˛e jasne, gdy spojrzymy na wymagania i uzasadnienia szybkiej migracji: ◦ w urz˛edach i placówkach dysponujacych ˛ małym budżetem można dostosować wymagane koszty do stanu budżetu. ◦ można sukcesywnie uzupełniać brakujac ˛ a˛ wiedz˛e i w ten sposób oszcz˛edzać koszty. W przypadku łagodnej migracji można wybierać pojedyncze składniki. Przeszkoleni przy tym administratorzy służa˛ jako osoby przekazujace ˛ swoja˛ wiedz˛e innym osobom, dzi˛eki czemu w przypadku migracji kolejnych składników dysponuja˛ one już wi˛ekszym Know-how. ◦ można stopniowo usuwać istniejace ˛ przeciwności i rozwiewać uprzedzenia. ◦ złożone struktury informatyczne można rozbierać kawałek po kawałku. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 470 Poniższy rysunek pokazuje, w jaki sposób mogłaby wygladać ˛ łagodna migracja. Rysunek 5.9: Łagodna migracja Na poczatku ˛ jako cel migracji należy wybrać składnik, który daje si˛e łatwo wyodr˛ebnić. W powyższym przykładzie jest to serwer DBMS. Nie chodzi tu o migraj˛e aplikacji bazodanowej, lecz o założenie równoległego DBMS. Należy dysponować podstawowa˛ wiedza˛ na temat tego serwera. Najpóźniej z chwila˛ rozpocz˛ecia pierwszej migracji, a mianowicie migracji serwera WWW, z reguły potrzebny b˛edzie serwer DBMS. Directory Server jest samodzielnym składnikiem, ale może być ewentualnie stosowany w połaczeniu ˛ z serwerem WWW i warunkować migracj˛e Groupware. Nast˛epnie wykonywana jest migracja zarzadzania ˛ plikami i zastapienie ˛ usług sieciowych. Na końcu 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 można dowolnie wymieniać składników zwiazanych ˛ z poszczególnymi krokami; to, co jest ze soba˛ zwiazane, ˛ powinno takim pozostać. Inna˛ ważna˛ rzecza˛ jest ustalenie realnej daty zakończenia, tak by proces nie rozciagał ˛ si˛e zbytnio w czasie. Czas realizacji musi jednak uwzgl˛eniać złożoność opieki i konserwacji a tym samym nakłady na prac˛e administratorów. Ponieważ nakład zwiazany ˛ z administrowaniem w różnorodnym środowisku informatycznym jest wyższy niż w środowisku jednorodnym, cały proces migracji, także w przypadku łagodnej migracji, nie powinien przekroczyć 2 - 3 etapu zamiany oprogramowania ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 471 w łacznym ˛ przewidywalnym horyzoncie czasowym. Rysunek 5.10: Etapy zamiany oprogramowania w przypadku łagodnej migracji Rysunek 5.10 pokazuje trzy etapy migracji. Po stronie serwera, w środowisku heterogenicznym, można wykonać wzgl˛ednie daleko idac ˛ a˛ migracj˛e przede wszystkim korzytajac ˛ z Samby, Terminalservices a także z możliwości kontynuacyjnego stosowania Outlooka jako klienta Groupware i Messaging. Dopiero na samym końcu, gdy wszystkie aplikacje specjalistyczne i biurowe przejda˛ równoległa˛ migracj˛e, można rozpoczać ˛ migracj˛e desktopów, czyli migracj˛e po stronie klienta. W stopniu, w którym umożliwia to zamiana oprogramowania specjalistycznego i biurowego, można nawet zastanowić si˛e nad skorzystaniem w kroku pośrednim z przejścia 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 też cz˛eściowego (serwery) albo tylko ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 472 punktowego zastapienia ˛ oprogramowania. Poniższy rysunek pokazuje wieloetapowy proces migracji w jego pojedynczych aspektach. Rysunek 5.11: Model stopniowego procesu migracji Aby można było doprowadzić projekty migracyjne jako projekty informatyczne w ogólności i jako projekty innowacyjne w szczególności do szcz˛eśliwego końca, należy z góry zdefiniować krytyczne wyznaczniki sukcesu oraz dokonać ich oceny. Dla wszystkich uczestników sukces projektu migracyjnego ma miejsce dopiero wówczas, gdy osiagni˛ ˛ ety zostanie zakładany cel badź ˛ wynik w zaplanowanych, wzgl˛ednie uzgodnionych ramach czasowym i budżetowych. Wyróżnić tu można tak zwane czynniki mi˛ekkie, których wkład jest nie do przecenienia w ostatecznym osiagni˛ ˛ eciu sukcesu. Zalicza si˛e do nich na przykład zadowolenie pracowników, bezawaryjna˛ komunikacj˛e i tym samym unikanie badź ˛ redukcj˛e porażek, frustracji oraz podwójnej pracy, jak również uzasadniony potrzebami wybór i naturalnie także akceptacj˛e nowego środowiska informatycznego przez użytkowników. Niezależnie od wielkości urz˛edu i niezależnie od tego czy chodzi o migracj˛e zast˛epujac ˛ a˛ czy kontynuacyjna, ˛ z punktu widzenia autorów do osiagni˛ ˛ ecia trwałego sukcesu projektu migracyjnego przyczyniaja˛ si˛e wymienione poniżej 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 środowiska docelowego wśród użytkowników ◦ strukturalne zaplanowanie czasu, projektu i zasobów oraz kontroli projektu ◦ działania organizacyjne przygotowujace ˛ migracj˛e i wykształcenie wykwalifikowanego zespołu wdrażajacego ˛ projekt ◦ szczegółowe ustalenie sytuacji docelowej ze zdefiniowanymi funkcjonalnymi wymaganiami ◦ optymalny wybór produktów i usług ◦ najbliższe i późniejsze szkolenia ◦ zarzadzanie ˛ jakościa˛ i dokumentacja˛ Z wyznaczników sukcesu wynika, że projekty migracyjne nie kończa˛ si˛e z chwila˛ zakupu i zaimplementowania odpowiednich składników. Zarówno przed migracja˛ oraz w trakcie właściwych procesów migracyjnych, jak też w czasie póżniejszych prac należy uwzgl˛eniać daleko idace ˛ zależności i czynności. W sumie projekty migracyjne można uznać za zakończone sukcesem i opłacalne tylko wtedy, gdy obok minimalizacji bieżacych ˛ kosztów umożliwia˛ one przynajmniej sprawniejsze wykonywanie zadań dzi˛eki nowoczesnej, zintegrowanej i funkcjonalnie ukierunkowanej informacji oraz komunikacji a także doprowadza˛ do ogólnego wzrostu elastyczności, wydajności i gotowości podczas realizacji obecnych i przyszłych zadań. Dalsze cele takie jak osiagni˛ ˛ ecie niezależności od producenta i / lub od platformy sa˛ centralnymi aspektami, które patrzac ˛ dalekowzrocznie musza˛ sprostać wymaganiom oceny ekonomicznej. W nast˛epnych rozdziałach dokładniej opisano najistotniejsze kryteria sukcesu zdefiniowane dla projektów migracyjnych. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 5.5.3.1 474 Sformułowanie jednoznacznych celów Podstawa˛ każdego sukcesu projektu jest sformułowanie jednoznacznych celów. Należy przy tym rozróżnić strategiczne cele zarzadzania ˛ (poziom motywacji) i cele na poziomie migracji serwerów (poziom widzialny). Należy określić, dlaczego migracja powinna w ogóle mieć miejsce a w nast˛epnym kroku, co chce si˛e dzi˛eki niej uzyskać. Osobom, na które migracja b˛edzie oddziaływać, kierownictwu urz˛edu i niezb˛ednym wykonawcom, należy przed rozpocz˛eciem realizacji projektu otwarcie wskazać właściwy cel zamiaru migracyjnego. Takie sformułowanie celu tworzy podstaw˛e dla wszystkich dalszych działań, tak samo dla ukształtowania projektu i wyboru docelowego oprogramowania, jak i dla wyboru wewn˛etrznych i zewn˛etrznych wykonawców. Osiagni˛ ˛ ecie pewnej niezależności od producenta badź ˛ platformy jest przy tym raczej ogólnym, ewentualnie nadrz˛ednym celem. Specyficznymi dla urz˛edu mogłyby być na przykład nast˛epujace ˛ szczegółowe dane docelowe odnośnie migracji serwerów: ◦ migracja serwerów bez dostosowania i zamiany oprogramowania po stronie klientów (pełne przej˛ecie danych, profilów użytkowników, struktur plików i katalogów z istniejacymi ˛ prawami dost˛epu) ◦ pełne zastapienie ˛ oprogramowania po stronie klientów (równorz˛edne zastapienie ˛ aplikacji i funkcji oraz integracja z istniejac ˛ a˛ w urz˛edzie siecia˛ komputerowa˛ bez wpływania na nia) ˛ ◦ migracja danych i struktur danych z zachowaniem aplikacji bazodanowych (odpowiedni wybór wolnych systemów bazodanowych) ◦ wymiana istniejacych ˛ aplikacji na stacjach roboczych za pomoca˛ równorz˛ednych aplikacji (wprowadzenie łatwego w obsłudze, centralnego zarzadzania ˛ systemem; uwzgl˛ednienie składników bezpieczeństwa informatycznego odpowiednio do Bund Online 2005, np. PKI, autoryzacja poprzez certyfikat i cechy biometryczne) ◦ stworzenie adekwatnego systemu zast˛epczego dla zarzadzania ˛ użytkownikami i logowania ◦ bezawaryjna konwersja szablonów 5.5.3.2 Właczenie ˛ i ustalenie szczebli kierowniczych i decyzyjnych Szczebel kierowniczy i decyzyjny to każdy poziom, na którym podejmowane sa˛ kluczowe decyzje dotyczace ˛ projektu migracyjnego bez bezpośredniego aktywnego udziału w projekcie. Z ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 475 drugiej strony kierownictwo projektu ma obowiazek ˛ przygotowywania sprawozdań. Jaki dokładnie to b˛edzie poziom, zależy od specyficznej sytuacji i priorytetu projektu w urz˛edzie. Rola szczebla kierowniczego w sukcesie projektu jest cz˛esto niedoceniana. Jak pokazuje doświadczenie, panuje zamiast tego przekonanie, że szczebel kierowniczy „nic albo bardzo mało rozumie, jeśli chodzi o technik˛e informatyczna˛ i komunikacyjna“. ˛ Jednocześnie insynuuje si˛e, że kierownictwo urz˛edu głównie „tylko“ zainteresowane jest tym, by otrzymać „działajacy ˛ i opłacalny system“. Takie założenie jest jednak nieproduktywne. Szczebel kierowniczy i decyzyjny jest odpowiedzialny raczej za wytyczanie celów projektu migracyjnego dla urz˛edu niż za tworzenie i realizacj˛e samego przedsi˛ewzi˛ecia. Wynikaja˛ z tego kompetencje wprowadzania zmian w kontrakcie, wzgl˛ednie nowych zapisów, które z reguły należa˛ do kierownictwa urz˛edu. Projekt migracyjny musi najpierw w ogóle zostać uruchomiony. W tym celu konieczne jest, aby szczebel decyzyjny w oparciu o rozpoznane braki badź ˛ konkretne cele projektu (np. uniezależnienie si˛e od producenta i platformy), wzgl˛ednie rozpoznanie potrzeb na podstawie wymagań oddelegowanych pracowników sformułowało zlecenie projektu. Komunikacja projektu jako decyzja kierownictwa Szczebel kierowniczy przyczynia si˛e istotnie do sukcesu projektu przekazujac ˛ wszystkim osobom zaangażowanym w projekt oraz pozostałym pracownikom informacj˛e o tym, że popiera ono projekt i na wszystkich etapach jego rozwoju b˛edzie go nie tylko tolerować ale także wspierać. Aktywne i zawczasu informowanie osób pracujacych ˛ przy projekcie Kolejnym jednoznacznym i głównym zadaniem kierownictwa, które zaczyna si˛e już na etapie przygotowywania projektu migracyjnego i które trzeba uwzgl˛ednić jest odpowiedzialność za komunikacj˛e pomi˛edzy pracownikami oraz motywowanie pracowników. Kierowanie odbywa si˛e dzi˛eki komunikowaniu i z tego wzgl˛edu styl kierowania oraz komunikowania sa˛ ze soba˛ nierozerwalnie zwiazane ˛ i wymagaja˛ szczególnie wysokich społecznych umiej˛etności. Chodzi w tym o to, aby dla wszystkich osób zatrudnionych przy projekcie, jak i pozostałych osób uczestniczacych ˛ w migracji była ona przejrzysta. Należy tu wymienić zarówno te obszary, w których zachodza˛ zmiany, jak też takie, które pozostana˛ niezmienione. (Przykładowo na bazie istniejacego ˛ pomysłu na prac˛e można dokładnie opisać planowane zmiany oraz niezmienne elementy). Ponadto do informowania należy wykorzystywać różne kanały komunikacyjne w ramach ogólnych konferencji, rozmów z pracownikami, warsztatów albo okólników badź ˛ ogłoszeń, jak też Intranetu (unikni˛ecie plotek). Zawczasu należy tworzyć możliwości reagowania na pytania i watpliwości, ˛ ale także obawy i strach zatrudnionych dotyczace ˛ zmian. Również zawczasu należy w cały proces właczyć ˛ przedstawicielstwa różnych osób i gremiów. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 476 Udost˛epnienie potrzebnych środków finansowych Szczebel kierowniczy musi upewnić si˛e, że już przed rozpocz˛eciem realizacji projektu można dysponować wymaganymi środkami finansowymi (na zakup rzeczy i opłacenie ludzi) przypadajacymi ˛ na poszczególne pakiety działań i na osoby biorace ˛ udział w projekcie. Oprócz samych kosztów inwestycji i licencji doliczyć tu trzeba na przykład koszty szkoleń a w razie potrzeby także koszty zewn˛etrznego doradztwa i wsparcia projektu, jak też wewn˛etrzne koszty osobowe. Ponadto potrzebne środki finansowe należy w danym przypadku dostosować do post˛epów prac nad projektem. Odbiór wyników czastkowych ˛ i końcowych Pomi˛edzy szczeblem decyzyjnym, kierownictwem projektu i członkami grup pracujacych ˛ nad projektem istnieje jasny podział zadań. Szczebel decyzyjny musi, na podstawie dokumentów przygotowanych przez grup˛e realizujac ˛ a˛ projekt, podejmować kluczowe decyzje na końcu poszczególnych etapów projektu i brać za nie odpowiedzialność. W danym przypadku wskutek zmiany okoliczności konieczna może być modyfikacja przyj˛etych strategicznych celów. 5.5.3.3 Uzyskanie wysokiego stopnia akceptacji środowiska docelowego wśród użytkowników Projekty migracyjne moga˛ zakończyć si˛e sukcesem i mieć sens na poziomie pracowników tylko wtedy, gdy jasno zdefiniowana zostanie widoczna korzyść oraz gdy zostanie ona przedstawiona jako sensowna i konieczna. Korzyść taka wynika ze zdefiniowania celu. Także osoby zatrudnione przy projekcie migracyjnym powinny być przekonane o jego zaletach, aby mogły go wprowadzać i wspierać na terenie cz˛eści badź ˛ całego urz˛edu. Jednocześnie należy przy tym jasno poinformować o granicach dla Open Source i zaznaczyć, dlaczego wybrano drog˛e przejścia na Open Source. Celem powyższych czynności jest zapewnienie wysokiego stopnia akceptacji migracji i w konsekwencji dużej motywacji oraz zadowolenia osób bioracych ˛ w niej udział. Należy uniknać ˛ sytuacji, w której niezadowoleni (niedoinformowani, niezmotywowani albo wskutek braku odpowiedniego szkolenia niewykwalifikowani) uczestnicy projektu migracyjnego zagroża˛ jego sukcesowi i w danym przypadku ogłosza˛ porażki. Patrzac ˛ długofalowo może to mieć w sumie negatywny wpływ na skuteczność i wydajność urz˛edu. Aby móc w razie potrzeby dokonać korekty, osoby odpowiedzialne za konsekwentne informowanie o przebiegu projektu powinny poza spełnianiem tego „obowiazku“ ˛ dokonać także „wyboru“ stałego sposobu kontroli poziomu sukcesu mierzonego zadowoleniem pracowników. Stworzenie koncepcji i trwałe wdrożenie wynikajacych ˛ z niej działań jest wprawdzie przede ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 477 wszystkim zadaniem kierownictwa, jednak może być ona tworzona tylko wspólnie z pracownikami i oczywiście stale ulepszana. W danym przypadku na poczatku ˛ sensowne może tu być skorzystnie z zewn˛etrznego wsparcia, doradztwa i couchingu. 5.5.3.4 Szkolenia dla użytkowników i administratorów W obszarze szkoleń należy z jednej strony zawczasu zintegrować administratorów a niedługo potem także przyszłych użytkowników. Należy stworzyć koncepcj˛e szkolenia grup docelowych uwzgl˛edniajac ˛ a˛ zarówno posiadane umiej˛etności, doświadczenie i kwalifikacje, jak też przyszłe wykorzystanie składników w miejscu pracy. Zawiera ona także zapoznanie użytkowników z miejscem pracy oraz dalsze szkolenie, szczególnie administratorów i opiekunów użytkowników, w obszarze oprogramowania Open Source. Ponadto zaleca si˛e aktywne właczanie ˛ do pomysłów na szkolenie doświadczeń z projektów pilotażowych albo innych projektów migracyjnych na zasadzie Lessons Learned. Kolejnymi konkretnymi działaniami sa: ˛ przygotowanie środowisk testowych i symulacyjnych, ćwiczeń na wypadek awarii, backupu i recovery. Jest to tym ważniejsze w sytuacji, gdy nie dysponuje si˛e doświadczeniami, wst˛epna˛ wiedza˛ albo jest ona bardzo mała i po migracji nie ma być już bieżacego ˛ badź ˛ doraźnego zewn˛etrznego wsparcia. 5.5.3.5 Działania organizacyjne przygotowujace ˛ migracj˛e Utworzenie grupy pracujacej ˛ nad projektem Z reguły projekty migracyjne nie sa˛ wykonywane przez jedna˛ osob˛e, lecz jest w nie zaangażowanych wi˛ecej osób. Aby sukcesem zakończyć migracj˛e powinny one działać w ograniczonych ramach czasowych i zmierzać do jasno zdefiniowanego celu. Wymagania te sa˛ klasycznymi cechami pracy nad projektem, które należy uzupełnić o odpowiednia˛ dla projektu form˛e organizacyjna˛5. Opierajac ˛ si˛e na tym należy sprawdzić czy i w jakim stopniu dotychczasowa struktura, która jak wynika z doświadczeń ukierunkowana jest pod katem ˛ procesu, b˛edzie przydatna, to znaczy ma form˛e organizacyjna˛ adekwatna˛ do projektu. W razie potrzeby należy czasowo zmienić organizacyjne warunki brzegowe i wyodr˛ebnić z organizacyjnych struktur urz˛edu osoby biorace ˛ udział w projekcie. Należy przy tym, w ramach przygotowań, wypracować z udziałem w/w osób i określić procesy robocze, punkty wspólne, produkty i zasoby. Obowiazuje ˛ przy tym zasada, że: ◦ struktura organizacyjna projektu jest ważniejsza niż struktura organizacyjna urz˛edu 5 Ministerstwo Spraw Wewn˛etrznych, Handbuch für Organisationsuntersuchnungen in der Bundesverwaltung, Bonn, 5 Aufl. 1988, S. 23 ff. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 478 ◦ należy jasno rozgraniczyć zadania i zakresy odpowiedzialności ◦ należy czasowo zredukować albo przenieść czynności Routine ◦ należy ustalić drogi komunikacji i przekazywania sprawozdań Wszelkie plany i kroki należy oceniać na tyle krytycznie, na ile z organizacyjnego punktu widzenia przyczyniaja˛ si˛e one do osiagni˛ ˛ ecia celu projektu. W watpliwych ˛ przypadkach należy preferować takie działania, które niosa˛ ze soba˛ wi˛ekszy potencjał. Skład grupy pracujacej ˛ nad projektem Sukces projektu jest wi˛ekszy badź ˛ mniejszy w zależności od kierownictwa porojektu oraz składu grypy, która nad nim pracuje. Zły wybór może doprowadzić, także w przypadku, gdy pozostałe założenia sa˛ korzystne, do uzyskania niedostatecznego wyniku projektu, podczas gdy dobra obsada osobowa wypracować może, nawet przy słabych warunkach brzegowych, wciaż ˛ akceptowalne wyniki. Zaprzecza to gdzieniegdzie głoszonej opini, że „nie ma ludzi nie zastapionych“. ˛ Kierownictwo projektu: Kierownik projektu ponosi całkowita˛ odpowiedzialność za projekt. Koordynuje, organizuje i komunikuje wszystkie prace zwiazane ˛ z projektem, co ma na celu jego specjalistyczne, terminowe i mieszczace ˛ si˛e w kosztach zakończenie. Kierownik jest odpowiedzialny za wytyczanie zadań i kontrol˛e realizacji krótkoterminowych i długoterminowych celów. (w razie potrzeby także za przygotowywanie raportów dla nadzorujacej ˛ komisji). W zależności od wielkości urz˛edu i charakteru zamiaru migracyjnego sensowne może okazać si˛e mianowanie jeszcze jednej osoby oprócz kierownika projektu, która przej˛ełaby cz˛eść jego zadań. Grupa pracujaca ˛ nad projektem: Wypracowanie treści projektu, wzgl˛ednie realizacja pojedynczych etapów i stopni procesu migracyjnego wykonywane sa˛ przez członków grupy pracujacej ˛ nad projektem. Przede wszystkim zalicza si˛e do nich grup˛e administratorów. Moga˛ do niej dołaczyć ˛ wybrani użytkownicy i w razie potrzeby osoby trzecie z zewnatrz ˛ (doradcy w zakresie Know-how i sposobu pracy). Właczanie ˛ zewn˛etrznych doradców Również w urz˛edach rośnie wsparcie ze strony zewn˛etrznego doradztwa w dziedzinie wdrażania 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 ◦ bieżaca ˛ komunikacja dotyczaca ˛ projektu ze skuteczna˛ kontrola˛ post˛epu prac i ich wyników ◦ przekonujace, ˛ dobrze przygotowane prowadzenie spotkań, prezentacji i dokumentacji wyników) ◦ transfer wiedzy w zakresie przygotowania i przeprowadzenia skomplikowanych projektów informatycznych badź ˛ migracyjnych Ustalenie formy organizacyjnej odpowiadajacej ˛ potrzebom projektu Właściwa˛ dla projektu migracyjnego form˛e organizacyjna˛ należy określić w zależności od zakresu migracji i wielkości urz˛edu. 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 zależności od zadań i celów zaleca si˛e skorzystanie z jednej z trzech wymienionych poniżej możliwości organizacyjnych: liniowa organizacja projektu: Pracownicy zwiazani ˛ z projektem zostaja˛ wyodr˛ebnieni z istniejacej ˛ struktury organizacyjnej i tworza˛ własna˛ jednostk˛e organizacyjna˛ kierowana˛ przez kierownika projektu. Prowadzi to do wi˛ekszej identyfikacji z projektem, na którym pracownicy moga˛ si˛e w pełni skoncentrować. Jednocześnie wystapi ˛ brak wspomnianych pracowników w ich dziale, co może doprowadzić do różnego rozłożenia si˛e obciażeń ˛ (przeciażenia) ˛ personelu. Forma organizacji liniowej powinna być stosowana w przypadku obszernych i trudnych projektów. sztabowa organizacja projektu: Projekt kierowany jest przez koordynatora, który nie ma formalnych pełnomoctnictw do podejmowania decyzji i przez to posiada ograniczone możliwości. Osoby pracujace ˛ nad projektem pozostaja˛ w swoich działach i spotykaja˛ si˛e tylko na zwiazanych ˛ z nim posiedzeniach, co sprawia, że sztabowa organizacja projektu jest podatna na zakłócenia i nieefektywność. Zaletami tego typu organizacji jest mały koszt (trzeba tylko znaleźć koordynatora) i elastyczne obciażenie ˛ pracowników (praca nad projektem i w dziale). Ponadto można jednocześnie przeprowadzać wiele projektów. Generalnie niniejsza forma organizacyjna nadaje si˛e tylko dla mniejszych projektów, ponieważ w przeciwnym razie koszty koordynacji i uzgodnień sa˛ zbyt wysokie. matrycowa organizacja projektu: W przypadku tego typu organizacji oprócz istniejacej, ˛ hierarchicznej struktury wprowadza si˛e poziome kompetencje decyzyjne. Pracownicy podlegaja˛ kierownikowi projektu, jeśli chodzi o kwestie ważne dla projektu, ale osobowo i dyscyplinarnie nadal podlegaja˛ liniowo swoim przełożonym. Projekty tego typu sa˛ skomplikowane i wymagaja˛ wysokich nakładów na koordynacj˛e. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 480 Ich zalety polegaja˛ na tym, że wymagane zasoby absorbowane sa˛ tylko w razie potrzeby. Kierownik projektu jest tutaj, w przeciwieństwie do sztabowej organizacji projektu, wyposażony w kompetencje decyzyjne i pełnomocnictwa do wydawania poleceń. Wady wynikaja˛ z tego, że osoby pracujace ˛ nad projektem sa˛ „sługami dwóch panów“. Zwłaszcza w przypadku realizacji wielu projektów moga˛ wystapić ˛ konflikty o zasoby albo wynikajace ˛ ze sprzecznych poleceń. Zestawienie i ocena organizacyjnych form projektu procesów migracyjnych W celach orientacyjnych zwiazanych ˛ z wyborem właściwej formy organizacyjnej projektu może posłużyć niniejsza tabela. Konieczne jest jednak dostosowanie dla konkretnego urz˛edu. CAŁKOWITA MIGRACJA CZ E˛ŚCIOWA MIGRACJA PUNKTOWA MIGRACJA mały urzad ˛ oraganizacja liniowa organizacja sztabowa organizacja sztabowa średni urzad ˛ organizacja liniowa organizacja matrycowa organizacja matrycowa duży urzad ˛ organizacja liniowa organizacja liniowo - matrycowa organizacja matrycowa Tablica 5.1: Propozycja: zestawienie form organizacyjnych projektu mały urzad: ˛ do 300 pracowników; średni urzad: ˛ do 1.000 pracowników; duży urzad: ˛ od 1.000 pracowników 5.5.3.6 Właczenie ˛ wybranych pracowników W ramach przygotowywania projektu należy, w zależności od stopnia skomplikowania zamiaru migracyjnego, podjać ˛ decyzj˛e organizacyjna˛ odnośnie tego, które grupy użytkowników aktywnie właczyć ˛ do projektu, wzgl˛ednie tylko poinformować. Proces wprowadzania zmian dotyka pracowników w stopniu zależacym ˛ od tego czy chodzi o migracj˛e całkowita, ˛ cz˛eściowa˛ albo punktowa. ˛ Jeśli, na przykład, w ramach cz˛eściowej migracji wymieniane jest oprogramowanie na serwerach, wówczas na ogół wystarczy przekazanie użytkownikom informacji i nie jest konieczne aktywne właczenie ˛ ich w ten proces. Jednak, gdy chodzi o migracj˛e oprogramowania biurowego, wtedy konieczny jest aktywny udział użytkowników obj˛etych migracja˛ i zapewnienie im opieki. 5.5.3.7 Określenie punktu wyjścia Kolejnym głównym wyznacznikiem sukcesu jest dokładne ustalenie sytuacji wyjściowej. Z reguły wiaże ˛ si˛e to z dużymi nakładami, wymaga zasobów ludzkich i odpowiedniej ilości czasu. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 481 Jednak zbyt dokładna znajomość szczegółów dokumentów albo aplikacji bazodanowych przeszkadza badź ˛ opóźnia w danym przypadku wprowadzanie korekt podczas procesu migracyjnego albo już podczas przygotowań do migracji opóźnia wdrożenie odpowiedniego post˛epowania, wzgl˛ednie podj˛ecie adekwatnych kroków. Określenie punktu wyjścia jest podstawa˛ umożliwiajac ˛ a˛ sformułowanie wymagań wzgl˛edem systemów docelowych. Ważnymi elementami, których stan należy ocenić sa˛ m.in.: ◦ bazy danych i struktury danych ◦ dokumenty i formaty dokumentów ◦ aplikacje i ich interfejsy ◦ dost˛epne funkcje ◦ dost˛epność danych i aplikacji ◦ braki i problemy ◦ ... 5.5.3.8 Spełnienie wymagań funkcjonalnych Oprogramowanie docelowe powinno (w dużym stopniu) zastapić ˛ istniejace ˛ funkcje i wymagania. Musi ono w razie potrzeby wytrzymać miarodajne próby. Trudno byłoby zaakceptować pogorszenie pracy w porównaniu z sytuacja˛ wyjściowa.˛ Do stwierdzenia wymagań co do funkcjonowania służy przede wszystkim opis sytuacji wyjściowej. Ponadto w ramach przeprowadzonej zawczasu ankiety należy zebrać konkretne zapotrzebowanie i wymagania wobec poszczególnych składników, zarówno z punktu widzenia użytkownika, jak i administratora, sprawdzić je i zestawić w postaci listy wymgań lub priorytetów. Niniejsze post˛epowanie zawiera także krytyczna˛ ocen˛e dotyczac ˛ a˛ przydatności i sensowności istniejacych ˛ już funkcji. Szczególnie należy przeanalizować krytyczne uwagi dotyczace ˛ brakuja˛ cych albo niepełnych funkcji i umieścić je w kryteriach wyboru. W zależności od stopnia krytyki, brakujace ˛ funkcje moga˛ doprowadzić do zmniejszenia akceptacji użytkowników. Na tej podstawie można tworzyć porównania ze składnikami oprogramowania do wyboru, co w nast˛epnym kroku ma na celu wybranie oprogramowania docelowego odpowiadajacego ˛ potrzebom. Całkowity sukces projektu musi dać si˛e zmierzyć stopniem realizacji poszczególnych wymagań. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 5.5.3.9 482 Korzystanie z wartości doświadczalnych Istotnym wyznacznikiem sukcesu jest również wykorzystanie wartości doświadczalnych w kontekście migracji do Linuksa. Jest tak tym bardziej, że dotychczas (przestarzałe) istniało wzgl˛ednie mało wartości doświadczalnych w tym obszarze. Korzystanie z aktywnych doświadczeń z projektu pilotażowego badź ˛ innych projektów migracyjnych i właczenie ˛ ich do planowanego projektu oraz zamierzeń przyniesie w jednakowym stopniu korzyści zarówno administratorom, jak i użytkownikom. Można tu polecić na przykład założenie bazy danych projektu. 5.5.3.10 Planowanie projektu, czasu i zasobów W przypadku migracji z oprogramowania Microsoftu do określonych środowisk 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 zawierać przynajmniej informacje odnośnie terminu, zasobów rzeczowych i ludzkich, właczenia ˛ zewn˛etrznych wykonawców, poszczególnych kroków i kosztów. Jednocześnie tworzy on podstaw˛e dla kierowania projektem. W ramach planu projektu należy opracować, kto organizacja projektu kiedy jak wykonać terminy struktura projektu co wykonać zadania robić, w celu szybko i bezpieczenie kalkulacja kosztów strategia projektu sukces projektu wcześniej uzgodnione zlecenie Wypracowane wyniki należy udokumentować w ksi˛edze projektu. rozkład czasu: Poprzez planowanie przebiegu i czasu realizacji projektu nast˛epuje jego daleko idacy ˛ podział. Taki wiaż ˛ acy ˛ plan wykonania projektu służy umożliwieniu przyj˛ecia realistycznego terminarza dla poszczególnych pakietów działań. Rozkład czasu wykonania projektu kieruje si˛e według zawartej w zleceniu dacie jego zakończenia. Należy w nim również określić poczatek, ˛ etapy i koniec poszczególnych pakietów działań. Stworzenie planu projektu stworzy w przyszłości podstaw˛e dla efektywnego kierowania projektem i sprawowania nad nim kontroli. plan nakładów, wzgl˛ednie zasobów: W ramach przewidywania nakładów należy sformuło- ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 483 wać wypowiedzi odnośnie tego, jaka ilość pracy (nakłady liczone w dniach roboczych na osob˛e) oraz konieczne zasoby przewidywane sa˛ jako niezb˛edne dla uzyskania uzgodnionego rezultatu. Należy przy tym rozróżnić nakłady (zależne od treści pracy) i czas trwania (zależny od intensywności pracy). W planach badź ˛ ocenach poszczególnych nakładów należy każdorazowo ujać ˛ nast˛epujace ˛ koszty: ◦ koszty osobowe (zasoby ludzkie pomnożone przez stop˛e rozrachunkowa) ˛ ◦ właczenie ˛ społeczności w procesy migracji do środowisk Open Source ◦ zasoby na stworzenie i prac˛e środowisk testowych ◦ koszty materiału (zużyte materiały - koszty papieru i wydruku) ◦ koszty urzadzeń ˛ (urzadzenie ˛ albo oprogramowanie, które trzeba ewentualnie zakupić) ◦ pozostałe koszty (koszty podróży, usługi zewn˛etrzne). ◦ koszty nabycia i koszty licencji ◦ koszty konserwacji, opieki i szkoleń 5.5.3.11 Kontrola projektu i kierowanie projektem Kontrola realizacji projektu jest ważna˛ cz˛eścia˛ składowa˛ organizacji projektu. Zadania kontrolne nie ograniczaja˛ si˛e tylko do nadzoru kosztów i terminów. Właśnie w kontekście projektów informatycznych Controlling nie jest kontrola˛ w sensie czynności oceniajacych ˛ czynności przeszłe, lecz pełni on funkcj˛e zapobiegwcza˛ polegajac ˛ a˛ na reagowaniu we właściwym czasie, gdy tylko rozpoznane zostana˛ odst˛epstwa od wartości zakładanych. Ma to na celu zagwarantowanie osia˛ gni˛ecia celów projektu takich jak: jakość produktu końcowego, termin przekazania do użytku oraz koszty pracy nad projektem. 5.5.3.12 Dokumentowanie i zapewnienie jakości projektu Już podczas wykonywania projektu i przede wszystkim po jego zakończeniu trzeba na każdym etapie zapewnić przejrzystość poszczególnych kroków także dla osób trzecich, które nie biora˛ udziału w procesie migracyjnym. Jest to warunkiem koniecznym dla późniejszej prawidłowej opieki nad systemem. Dokumentacj˛e można przygotowywać z wykorzystaniem nast˛epujacych ˛ mediów: ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 484 ◦ podr˛eczniki konfiguracji ◦ podr˛eczniki pracy ◦ dokumetacja szkoleń ◦ spisy stanu ◦ podr˛ecznik projektu ◦ protokoły / sprawozdania nt. stanu ◦ sprawozdania odnośnie zapewnienia jakości badź ˛ sprawozdania kontrolne ◦ dokumentacja końcowa Oprócz kontroli i oceny projektowanego systemu, sprawozdanie kontrolne musi także zawierać analizy możliwych bł˛edów i ocen˛e skutków ich wystapienia ˛ na każdym etapie projektu. Wspomniane analizy bł˛edów musza˛ być tak samo udokumentowane, jak wszystkie inne prace nad projektem Wynacznikiem sukcesu w obszarze zapewnienia jakości okazała si˛e np. w projektach pilotażowych budowa środowisk testowych. W przypadku dużych projektów wszystkie czynności prowadzace ˛ do zapewnienia jakości tworza˛ odr˛ebny obszar zadań. W zależności od zakresu projektu i kwalifikacji personelu może go nadzorować kierownik projektu albo, w pewnych warunkach, kontroler projektu. Nast˛epujacy ˛ rysunek przedstawia wewn˛etrzne kroki majace ˛ na celu kontrol˛e jakości: Rysunek 5.12: Etapy kontroli jakości ◦ na końcu poszczególnych kroków badź ˛ etapów projektu kontroler jakości powinien przygotować wymagane listy kontrolne i metody kontroli. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 485 ◦ jeśli wynik kontroli jakości wypadnie pozytywnie, wówczas oznacza to zezwolenie na przejście do nast˛epnego kroku przewidzianego w projekcie. Jeśli wynik nie odpowiada zdefiniowanym wymganiam jakościowym, wtedy należy powrócić do pracy nad źle ocenionym zadaniem. Braki należy konkretnie i szczegółowo zdefiniować i umieścić w protokole kontrolnym. Na końcu trzeba ustalić termin ponownej kontroli i wpisać go do planu projektu. 5.5.3.13 Opieka na etapie pracy Kolejnym warunkiem trwałego sukcesu migracji jest opieka administratorów mieszczaca ˛ si˛e w umiarkowanych granicach. Jednak ogólnie obowiazuj ˛ acej ˛ wartości b˛edac ˛ a˛ miara˛ takiego zaangażowania nie można w tym miejscu podać. Ważna˛ rzecza˛ jest, by natychmiast reagować, gdy zaistnieje ku temu odpowiednia potrzeba. Z uwagi na brakujacy ˛ Routine w otoczeniu migracji, także na etapie rozpoczynania pracy z nowymi zadaniami należy zapewnić, szczególnie administratorom, opiek˛e osób z zewnatrz ˛ dostarczajacych ˛ potrzebna˛ wiedz˛e badź ˛ wsparcie. Ważne jest to zwłaszcza wtedy, gdy osoby biorace ˛ udział w migracji nie miały dotychczas doświadczenia lub posiadały niewielkie doświadczenie z systemami (GNU / Linux, OSS). Obecność na miejscu osób przekazujacych ˛ wiedz˛e byłaby w każdym razie korzystna˛ opcja.˛ 5.6 Eksperci współpracujacy ˛ nad poradnikiem6 Frank Gamerdinger, jako specjalista od pakietów biurowych OpenOffice.org oraz StarOffice, współtworzył ocen˛e techniczna˛ migracji programów biurowych. <frank.gamerdinger@ sun.com> Peter Ganten wyspecjalizował si˛e w zagadnieniach usługi katalogowe, migracja z domen opartych na Windows NT do Samby i OpenLDAP pracujacych ˛ pod Linuksem oraz w dziedzinie Thin Clients i integracji aplikacji windowsowych na desktopie Linuksa. Współtworzył odpowiednie podrozdziały poradnika. <[email protected]> Sebastian Hetze jest autorem takich podrozdziałów poradnika, jak bazy danych, składowanie plików, zarzadzanie ˛ siecia˛ i zarzadzanie ˛ systemem. Specjalizuje si˛e w bazach danych oraz składowaniu plików w Linuksie, jak też formatach wymiany danych. <s.hetze@linux-ag. de> 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 6 Wymienieni w kolejności alfabetycznej. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 486 i drukowania. <[email protected]> Michael Meskes specjalizuje si˛e w DBMS, zwłaszcza w PostgreSQL. Wniósł odpowiednie uwagi do oceny technicznej w tym zakresie. <[email protected]> Kurt Pfeifle wyspecjalizował si˛e w zagadnieniu integracji drukowania w sieci rozległej w środowiskach heterogenicznych i jako autor tworzył techniczna˛ ocen˛e usług drukowania. <kpfeifle@ danka.de> Dr. Klaus Schmidt jest ekspertem ds. infrastruktury informatycznej i rozwoju produktu. Szczególnie specjalizuje si˛e w rozwiazaniach ˛ dla systemów wysokiej niezawodności. Współtworzył odpowiednie podrozdziały poradnika. Sebastian Stöcker wyspecjalizował si˛e w infrastrukturach Microsoftu i architekturach systemowych i napisał istotne cz˛eści oceny technicznej zwiazane ˛ ze składnikami Microsoftu. Thomas Uhl zajmuje si˛e integracja˛ otwartych systemów, szczególnie w ramach Open Source. Jest autorem oceny technicznej rozwiazań ˛ opartych na Groupware i terminalach. <thomas. [email protected]> Osoby, które w jakikolwiek sposób przyczyniły si˛e do powstania polskiej wersji poradnika migracyjnego7 Krzysztof Binaś Aleksander Cynarski Grzegorz Artur Daszuta Maciej Jan Głowacki Maciej Hański Radosław Janeczko Paweł Jastrzabek ˛ Wojciech Kaczmarek8 Przemysław Klawitter Konrad Komada Piotr Kubiak Wojciech Kuś 7 Wymienione w kolejności alfabetycznej. Przepraszam wszystkie osoby zainteresowane polska˛ wersja˛ j˛ezykowa˛ poradnika za opóźnienie w jej opublikowaniu. Prac˛e oraz czas poświ˛econy przeze mnie na potrzeby niniejszego tłumaczenia dedykuj˛e głodnym polskim dzieciom. 8 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE Janusz Makówka Mikołaj Marczyński 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 487 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 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 Office 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 budżetowa BIND Berkeley Internet Name Domain BMI Ministerstwo Spraw Wewn˛etrznych Republiki Federalnej Niemiec BSD Berkeley Software Distribution 488 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE BSI Krajowy Urzad ˛ ds. Bezpieczeństwa Informatycznego BVA Ministerstwo Administracji Republiki Federalnej Niemiec CA Certification 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 Office 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 489 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE DDNS Dynamic DNS DFS Distributed File System DHCP Dynamic Host Configuration 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 Definition 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 Qualified Domain Name FRS File Replication Service 490 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 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 Identifier 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 491 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 odnośnie przygotowywania oceny ekonomicznej w administracji publicznej, ze szczególnym uwzgl˛ednieniem 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 Rzadowy ˛ Urzad ˛ Koordynacji i Doradztwa ds. Informatyzacji przy Ministerstwie Spraw Wewn˛etrznych 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 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 Traffic 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 494 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 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 OpenOffice.org OOo/SO Open Office.org/StarOffice OpenLDAP Usługa katalogowa OSI Open Systems Interconnection OSOS Open Standards mit Open Source 495 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 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 Office 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 496 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE RDP Remote Desktop Protocol ReiserFS Reiser File System RFCs Request for Comments RHCE Red Hat Certified Engineer RID Relative Identifier 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 Configuration Manager SCSI Small Computer System Interface SFU Service for UNIX SID Security Identifier SISL Sun Industry Source License SLAs Service Level Agreements SMB Server Message Block 497 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE SMS Short Message Service SMS System Management Server SMTP Simple Mail Transfer Protocol SNA Storage Network Attached SNMP Simple Network Management Protocol SO StarOffice 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 498 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 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 499 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE XFS Extended File System XSL Extensible Style Sheet Language XML Extensible Markup Language YaST Yet another Setup Tool 500 ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 501 5.8 Słownik poj˛eć ADO ADO oznacza Active Data Objects. Sa˛ to wysokopoziomowe interfejsy (np. z Visual Basic) służace ˛ do ogólnego odwoływania si˛e do danych firmy Microsoft poprzez OLE DB Provider (np. do SQL Server, ODBC, Oracle, Active Directory Service, i innych). ADO zawiera obiekty służace ˛ do tworzenia połaczenia ˛ ze źródłem danych w celu wykonywania operacji odczytu, uaktualnienia, zapisu i usuwania. ACL Access Control List jest lista˛ uprawnień dost˛epu. Na podstawie niniejszych list odbywa si˛e sterowanie dost˛epem do zasobów systemu informatycznego. Na podstawie ACLs system decyduje o tym, jaki dost˛ep do zasobów, np. do katalogu przydzielić użytkownikowi. ActiveX Poj˛ecie zbiorowe oznaczajace ˛ technologi˛e wprowadzona˛ przez Microsoft, która umożliwia umieszczanie (inter)aktywnych treści na stronach WWW. Przegladarka ˛ pobiera z serwera cz˛eści programu ActiveX i wykonuje je na komputerze użytkownika. Technologia ActiveX stworzona została przez Microsoft jako alternatywa dla apletów Java. API Application Programming Interface (zdefiniowany interfejs programistyczny, którego można używać do integracji i rozszerzania) ASP Oznacza „Active Server Pages“; jest rozwiazaniem ˛ Microsoftu służacym ˛ do generowania po stronie serwera dynamicznych stron WWW (np. za pomoca˛ JavaScript, Visual Basic Script), patrz także JSP. C# Obiektowy j˛ezyk programowania zaprojektowany przez Microsoft w oparciu o C i C++. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE CGI 502 Common Gateway Interface jest pierwotnym wariantem interfejsów serwera. Praktycznie każdy dzisiejszy serwer WWW obsługuje ten interfejs. Aplikacje pracujace ˛ poprzez CGI można tworzyć w różnych j˛ezykach programowania. Oprócz j˛ezyków interpretowanych, takich jak, np. Perl, stosować można także skompilowane aplikacje napisane w C albo w C++. COM Component Object Model jest standardem oprogramowania firmy Microsoft, za pomoca˛ którego można realizować komunikacj˛e pomi˛edzy procesami i programami. COM definiuje dodatkowo interfejs obiektowy, poprzez który program albo składnik oprogramowania udost˛epnia usługi. CORBA CORBA oznacza Common Object Request Broker Architecture i zaprojektowana została w celu umożliwienia komunikacji pomi˛edzy aplikacjami niezależnej od miejsca, platformy oraz implementacji. CORBA jest otwartym standardem zdefiniowanym przez Object Management Group (OMG). DCOM Distributed Component Object Model jest wariantem standardu COM firmy Microsoft. Za pomoca˛ DCOM można poprzez sieć udost˛epnić dzielone usługi oprogramowania. DCOM wykorzystuje RPC (Remote Procedure Calls), co poprzez wymian˛e informacji umożliwia wywoływanie funkcji na innym komputerze. DDE Dynamic Data Exchange jest technika˛ stosowana˛ w Windowsie, która umożliwia programom użytkowym wymian˛e danych. Sama wymiana danych odbywa si˛e dynamicznie. Gdy pliki połaczone ˛ za pomoca˛ DDE zostana˛ zmienione, automatycznie nast˛epuje przekazanie zmiany do wszystkich plików komunikujacych ˛ si˛e ze zmienionym plikiem. DHCP Dynamic Host Configuration Protocol tworzy podstaw˛e dynamicznego przydzielania adresów IP. Klient DHCP otrzymuje dynamicznie, z centralnego serwera DHCP, adres IP. Oprócz adresów IP do klienta przekazywane moga˛ być jeszcze inne parametry konfiguracyjne. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE 503 DNS Domain Name System jest systemem zbudowanym hierarchicznie służacym ˛ do przydzielania nazw dla komputerów podłaczonych ˛ do Internetu / Intranetu. DTD Definicje typu dokumentu w formalny sposób ustalaja˛ struktur˛e dokumentu XML. Określaja˛ one składni˛e obowiazuj ˛ ac ˛ a˛ dla danego typu dokumentu (a tym samym także dla określonego formatu danych). Emulacja Zdolność systemu, wzgl˛ednie programu do naśladowania sposobu pracy systemu komputerowego za pomoca˛ osprz˛etu badź ˛ oprogramowania. Failover Jest specyficznym rodzajem pracy osprz˛etu badź ˛ oprogramowania, np. bazy danych, serwera albo sieci, które skonfigurowane sa˛ w taki sposób, że w przypadku przejściowego ustania pracy systemu, nast˛epuje automatyczne przej˛ecie świadczonej przez nie usługi przez system spełniajacy ˛ podobne albo takie same funkcje. HTML Hypertext Markup Language – otwarty standard badź ˛ format pliku służacy ˛ do prezentowania treści w Internecie albo Intranecie. HTTP Standard służacy ˛ do elektronicznej interakcji podczas transmisji dokumentów WWW do Internetu. IMAP Za pomoca˛ Internet Mail Access Protocol można zarzadzać ˛ skrzynkami poczty elektronicznej. W przeciwieństwie do POP3, IMAP administruje poczta˛ na serwerze. Podczas właczania ˛ programu pocztowego standardowo ściagane ˛ sa˛ tylko nagłówki wiadomości (nadawca, temat i czas dostarczenia). W tym momencie adresat może wybrać dowolne wiadomości i ściagn ˛ ać ˛ ich pełna˛ treść. Poczta, która˛ chcemy pozostawić na serwerze może być odkładana do oddzielnych katalogów. IPsec Standard sieciowych systemów bezpieczeństwa, który przede wszystkim nadaje si˛e do implementacji VPNs, jak też do zdalnego dost˛epu do prywatnych sieci poprzez połaczenia ˛ dial - up. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE IPv6 504 To nowa wersja 6 protokołu internetowego (IP), w przypadku której adresy IP powinny składać si˛e ze 128 zamiast 32 bitów, jak ma to miejsce w przypadku IPv4. Dzi˛eki temu stworzono, mi˛edzy innymi, wi˛eksza˛ przestrzeń adresowa˛ dla stron WWW. IPX Standard transmisji danych zdefiniowany przez firm˛e Novell. Java Obiektowy j˛ezyk programowania stworzony przez SUN Microsystems, który używany jest przede wszystkim w obszarze technologii internetowej. Teksty źródłowe tłumaczone sa˛ do niezależnego od platformy kodu pośredniego za pomoca˛ tak zwanego kompilatora. Może być on wykonywany przez właściwy interpreter na dowolnym komputerze. Dzi˛eki temu programy Java moga˛ pracować na wszystkich platformach, dla których istnieje odpowiedni interpreter. Java Beans Java Beans sa˛ składnikami oprogramowania wielokrotnego użytku, które powstały w technologii Java. Java Script J˛ezyk skryptowy zdefiniowany pierwotnie przez firm˛e Netscape służacy ˛ do łaczenia ˛ kodu programu ze statycznymi stronami HTML. Z reguły wykonanie kodu nast˛epuje w przegladarce ˛ użytkownika. JDBC Java Database Connectivity oferuje mechanizm umożliwiajacy ˛ komunikacj˛e z istniejacymi ˛ bazami danych. Sterowniki tworza˛ interfejs pomi˛edzy programem Java i baza˛ danych. JSP JavaServer-Pages sa˛ plikami HTML zawierajacymi ˛ kod programu napisany w Java, który po przekształceniu w serwlety za pomoca˛ silnika JSP, może być wykonywany po stronie serwera WWW. LAMP Platforma Open Source oparta na Linuksie, Apache, MySQL i PHP badź ˛ Perlu albo Pythonie służaca ˛ programistom WWW do tworzenia aplikacji WWW. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE LDAP 505 Lightweight Directory Access Protocol (X.509) jest uproszczona˛ wersja˛ DAP (X.500). Za pomoca˛ LDAP realizowany jest dost˛ep do usług katalogowych, które można odpytywać pod katem, ˛ np. cech użytkowników. Makro Połaczone ˛ pojedyncze instrukcje badź ˛ szereg poleceń i procesów, które można przechowywać i zapisywać. Gdy wywołane zostaje makro, wówczas nast˛epuje automatyczne wykonanie procesów i akcji w odpowiedniej kolejności. MP3 Standardowy format skompresowanych plików audio, który zaprojektowany został w ramach MPEG przez Fraunhofer - Institut i rozpowszechnił si˛e przede wszystkim w Internecie. MTA Składnik oprogramowana odpowiedzialny za rozdzielanie poczty elektronicznej pomi˛edzy różne systemy komputerowe. MTA odbiera wiadomości zarówno z innych MTA, jak też z MUA i kieruje je do odpowiednich użytkowników. MUA Mail User Agent jest programem umożliwiajacym ˛ użytkownikowi dost˛ep do wiadomości elektronicznych, ich wyświetlanie, czytanie, edycj˛e oraz zarza˛ dzanie nimi. .NET Platforma dla Web Services firmy Microsoft opartych na XML. Zadaniem platformy jest łaczenie ˛ w jednolity i spersonalizowany sposób informacji, urzadzeń ˛ i użytkowników. NTP Network Time Protocol służy do synchronizacji poprzez sieć zegarów pracujacych ˛ w różnych komputerach. NTP umożliwia ustawienie czasu komputerów z dokładnościa˛ co do milisekundy, co jest bardzo ważne dla procesów wykonywanych jednocześnie przez wiele komputerów. ODBC Standardowe post˛epowanie polegajace ˛ na zapewnieniu dost˛epu do baz danych. Na przykład aplikacje moga˛ odwoływać si˛e do różnego rodzaju baz danych za pomoca˛ ODBC. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE OLE 506 OLE oznacza „Object Linking and Embedding“ i jest metoda˛ wspólnego korzystania z informacji. Informacje te moga˛ być dost˛epne w różnych formatach i utworzone za pomoca˛ różnych aplikacji. Dane z dokumentu źródłowego ła˛ czone sa˛ z dokumentem docelowym badź ˛ sa˛ one do niego właczane. ˛ Gdy w dokumencie docelowym nastapi ˛ zaznaczenie właczonych ˛ danych, wówczas otwarta zostanie aplikacja, z której one pochodza,˛ co ma na celu umożliwienie edycji danych w ich pierwotnym środowisku za pomoca˛ niezb˛ednych funkcji. Mówi si˛e także o „OLE Compound Documents“. OSI Mi˛edzynarodowy standard wymiany danych w sieciach. OSI reprezentuje siedem warstw, które każdorazowo opisuja˛ poszczególne procesy komunikacyjne. PDF Ponadplatformowy format dokumentów firmy Adobe Systems, za pomoca˛ którego można tworzyć i prezentować dokumenty złożone z tekstów, rysunków i grafik. Perl Practical Extraction and Raport Language jest wolnodost˛epnym j˛ezykiem programowania, który szczególnie cz˛esto wykorzystywany jest do tworzenia skryptów CGI. Dzi˛eki różnorodnym możliwościa, ˛ zwłaszcza jeśli chodzi o edycj˛e ciagów ˛ znaków, programy napisane w Perlu służa˛ także cz˛esto do wykonywania administracyjnych zadań routine. PHP J˛ezyk skryptowy po stronie serwera służacy ˛ do tworzenia dynamicznych treści WWW w oparciu o baz˛e danych. POP3 W przypadku pracy z Post Office Protocol w wersji 3 lokalny program pocztowy (klient) ściaga ˛ po uruchomieniu cała˛ nowa˛ poczt˛e z serwera WWW do lokalnego komputera. Zazwyczaj klient skonfigurowany jest w taki sposób, że po ściagni˛ ˛ 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 PostScript 507 J˛ezyk opisu strony stworzony przez firm˛e Adobe do sterowania drukarkami. Drukarki postscriptowe otrzymuja˛ polecenia wydruku z każdego programu w formie standardowego szeregu instrukcji. Sa˛ one interpretowane przez odpowiednia˛ drukark˛e i wykonywane w procesie drukowania. RAS Jest oznaczeniem Microsoftu dla udost˛epniania usług dial - up wewnatrz ˛ systemu operacyjnego Microsoft. RDBMS W systemie zarzadzania ˛ relacyjna˛ baza˛ danych informacje zgromadzone w bazie danych znajduja˛ si˛e w tabelach, które powiazane ˛ sa˛ wzajemnymi relacjami utworzonymi zgodnie z modelem relacyjnym. Server Proces, program albo komputer służacy ˛ do przetwarzania żadań ˛ klienta badź ˛ do udost˛epniania usług, z których korzysta klient. SQL Jest standardowym j˛ezykiem zapytań wysyłanych do relacyjnych baz danych. SSH Protokół badź ˛ odpowiednia jego implementacja (systemy Unix / Linux), który gwarantuje bezpieczny dost˛ep do komputerów podłaczonych ˛ do sieci. Implementacja ta oferuje bezpieczna˛ transmisj˛e danych z wykorzystaniem bezpiecznych połaczeń. ˛ SSL Technologia szyfrowania zaprojektowana przez firm˛e Netscape oraz protokół do bezpiecznej komunikacji badź ˛ bezpiecznego przesyłania dokumentów pomi˛edzy przegladarkami ˛ a serwerami WWW. TCP/IP Zestaw protokołów sieciowych wykorzystywanych wewnatrz ˛ sieci w celu udost˛epnienia użytkownikowi szeregu usług. TCP (Transmission Control Protocol) oraz IP (Internet Protocol) oferuja˛ podstawy budowania pojedynczych pakietów danych, ich przesyłania i dostarczania. ROZDZIAŁ 5. ZALECENIA MIGRACYJNE UNO 508 UNO jest modelem składników, który tworzy kompatybilność pomi˛edzy rożnymi j˛ezykami programowania, różnymi modelami obiektowymi, różnymi architekturami maszyn i różnymi procesami. Kompatybilność ta może wyst˛epować w LAN albo za pośrednictwem Internetu. UNO rozwijany jest przez społeczność OpenOffice razem z laboratoriami programistycznymi Sun Microsystems. Podstawowe biblioteki UNO sa˛ niezależne od OpenOffice i Star Office i można je stosować jako Framework dla innych aplikacji. UNO jest wolny i udost˛epniany na licencji LGPL. Obecnie Java, C i C++ obsługiwane sa˛ w Windowsie, Linuksie i Solaris (patrz także 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 standaryzacj˛e HTML, XML i ich pochodnych. WebDAV Web-based Distributed Authoring and Versioning jest rozszerzeniem Hypertext Transfer Protocol (HTTP) i oferuje standardowa˛ obsług˛e asynchronicznego, kolaboracyjnego tworzenia treści poprzez Internet badź ˛ Intranet. WINS System Microsoft do przekształcania nazw wewnatrz ˛ sieci (nazwy sieciowe <–> adresy IP). XML Specyfikacja do definiowania j˛ezyków służacych ˛ do formatowania dokumentów. XML oferuje ścisłe rozdzielenie treści od warstwy logicznej. XLST J˛ezyk 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 j˛ezyk opisu stron taki jak HTML. Spis tablic 2.2 SuSE Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.4 Red Hat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.2 Windows - grupy uprawnień . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.4 Atrybuty w Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.6 3.8 Porównanie serwerów plików . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Porównanie systemów plików . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 3.10 Uprawnienia POSIX oraz grupy uprawnień 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 Wielowartościowe 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 funkcjonalności Internet Information Server 5.0 . . . . . . . . . . . 210 3.34 Składniki dost˛epne na serwerze MS SQL jako obiekty . . . . . . . . . . . . . . . 220 3.36 Systemy bazodanowe dost˛epne 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 kompatybilności Exchange . . . . . . . . . . . . . . . . . . . . . . . . 268 3.59 Wersje VBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 3.61 Rozszerzenia plików najważniejszych aplikacji Office . . . . . . . . . . . . . . . 280 3.63 Właściwości MS Office mogace ˛ sprawić problemy podczas konwersji do OOo / SO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 3.65 Porównanie dost˛epnych typów szablonów i formatów . . . . . . . . . . . . . . . 284 3.67 Różnice w kluczowych funkcjonalnościach . . . . . . . . . . . . . . . . . . . . 287 3.69 Przeglad ˛ przegladarek ˛ WWW należacych ˛ 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 wzgl˛edem systemu HA . . . . . . . . . . . . . . . . . . . . . . . . 343 3.77 Zestawienie poziomów abstrakcji . . . . . . . . . . . . . . . . . . . . . . . . . . 344 3.79 Przeglad ˛ komercyjnego oprogramowania HA . . . . . . . . . . . . . . . . . . . 348 4.2 Porównanie kosztów przypadajacych ˛ na użytkowników w przypadku migracji pełnej i kontynuacyjnej . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 4.4 4.6 Rozkład kosztów w przypadku „migracji pełnej“ w urz˛edach . . . . . . . . . . . 370 Całkowite koszty migracji przypadajace ˛ na użytkownika w przypadku migracji pełnej . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 4.8 Całkowite koszty migracji przypadajace ˛ na użytkownika w przypadku migracji kontynuacyjnej . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 4.10 Całkowite koszty migracji przypadajace ˛ na użytkownika w przypadku migracji punktowej . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 4.12 Rozłożenie kosztów migracji . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 4.14 Całkowite koszty migracji przypadajace ˛ na użytkownika w przypadku migracji cz˛eściowej po stronie serwera. . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 4.16 Całkowite koszty migracji przypadajace ˛ na użytkownika w przypadku migracji cz˛eściowej 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 osob˛e w przypadku migracji zast˛epujacej ˛ . . . . . . 384 4.26 Nakłady liczone w dniach na osob˛e: Exchange5.5 –> Exchange2000 . . . . . . . 386 4.28 Nakłady liczone w dniach na osob˛e: 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 – średni urzad ˛ . . . . . . . . . . . . . 394 4.34 2 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), średni urzad ˛ . 394 4.36 Przykład migracji: infrastruktura serwerów – duży urzad ˛ . . . . . . . . . . . . . 397 4.37 3 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), duży 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), średni urzad402 ˛ 4.43 Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), duży 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 – średni urzad ˛ . . . . . . . . . . . . 412 4.53 Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], średni urzad ˛ 413 4.55 Przykłady migracji: Messaging / Groupware – duży urzad ˛ . . . . . . . . . . . . . 414 4.56 Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], duży urzad ˛ . 415 4.57 Typy migracji / produkty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 4.59 Przykład analizy korzyści: czynniki konieczności . . . . . . . . . . . . . . . . . 434 4.61 Przykład analizy korzyści: czynniki jakościowo - strategiczne . . . . . . . . . . . 439 5.1 Propozycja: zestawienie form organizacyjnych projektu . . . . . . . . . . . . . . 480 Spis rysunków 2.1 Składniki systemu - punkt wyjścia . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.2 Składniki systemu - migracja zast˛epujaca ˛ . . . . . . . . . . . . . . . . . . . . . 35 2.3 Składniki systemu - migracja kontynuacyjna . . . . . . . . . . . . . . . . . . . . 36 3.1 Metoda B-G-L-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.2 3.3 Metoda B-G-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Środowisko wydruku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.4 Proces wydruku realizowany metoda˛ „Point & Print“ . . . . . . . . . . . . . . . 95 3.5 Drukowanie z CUPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 3.6 3.7 Scenariusz logowania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 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 wyjścia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 restrukturyzacj˛e . . . . . . . . . . . . . . . . . . . 176 3.18 Migracja ADS – aktualizacja plus restrukturyzacja . . . . . . . . . . . . . . . . 177 3.19 Migracja ADS - nowa domena plus restrukturyzacja . . . . . . . . . . . . . . . . 178 3.20 Migracja ADS - klony użytkowników i grup . . . . . . . . . . . . . . . . . . . . 178 3.21 Migracja ADS - świat równoległy a migracja zasobów . . . . . . . . . . . . . . 179 512 SPIS RYSUNKÓW 513 3.22 Migracja ADS - wypełnianie równoległego świata kontami użytkownika 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 środowiska Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . 269 3.30 VBA w aplikacji Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 3.31 Możliwe rozszerzenia w Office . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 3.32 Fontmapping MS Office OOo / SO . . . . . . . . . . . . . . . . . . . . . . . . 278 3.33 Zawartość pliku OOo / SO wyświetlana w przegladarce ˛ plików ZIP. . . . . . . . 280 3.34 Obiekty - cienie w PowerPoint i Impress . . . . . . . . . . . . . . . . . . . . . 292 3.35 Konwerter dokumentów: wybór formatu źródłowego . . . . . . . . . . . . . . . 293 3.36 Konwerter dokumentów: wybór katalogu źródłowego 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 sieć . . . . . . . . . . . . . . . . . . 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 4.3 Matryca kosztów migracji z kategoriami kosztów i obszarami zastosowań . . . . 363 Rozwój kosztów migracji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 4.4 Koszty migracji przypadajace ˛ na użytkownika . . . . . . . . . . . . . . . . . . . 374 SPIS RYSUNKÓW 4.5 514 Przykład rachunku opłacalności migracji Windows NT –> Linux, duży urzad, ˛ ocena kosztów projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 4.6 Przykład rachunku opłacalności migracji Windows NT –> Linux, duży urzad, ˛ ocena wartości kapitału . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 4.7 Przykład rachunku opłacalności migracji Windows NT –> Linux, średni urzad, ˛ 4.8 ocena kosztów projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 Przykład rachunku opłacalności migracji Windows NT –> Linux, średni urzad, ˛ ocena wartości kapitału . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 4.9 Przykład rachunku opłacalności migracji Windows NT –> Linux, mały urzad, ˛ ocena wartości kapitału . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 4.10 Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, duży urzad ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 4.11 Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, duży urzad, ˛ alternatywna dzierżawa Windows / Office . . . . . . . . . . . . . . . 423 4.12 Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, średni urzad ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 4.13 Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000, średni urzad, ˛ alternatywna dzierżawa 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 dzierżawa Windows / Office . . . . . . . . . . . . . . . . . . . . . 426 4.16 Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Contact, duży urzad ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 4.17 Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Contact, średni urzad ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 4.18 Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Contact, mały urzad ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 4.19 Przykład rachunku kosztów projektu migracji Windows NT do Linuksa po stronie serwera, duży urzad ˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 4.20 Przykład rachunku kosztów projektu migracji Windows NT do Linuksa po stronie serwera, średni 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 konieczności i jakości zamiaru migracyjnego . . . . . . . . . . . . 432 5.1 Proces decyzyjny prowadzacy ˛ do wdrożenia OSS . . . . . . . . . . . . . . . . . 442 5.2 Architektura systemu z linuksowym Fat Client . . . . . . . . . . . . . . . . . . . 446 5.3 Zalecana architektura IT w dużym urz˛edzie w przypadku całkowitej „zast˛epuja˛ cej migracji“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 5.4 Obszary zastosowań usług katalogowych na przykładzie platformy SunOne . . . 452 5.5 Zalecana architektura IT dla specjalizowanego urz˛edu w przypadku całkowitej 5.6 „zast˛epujacej ˛ migracji“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 Zalecana architektura IT dla małego urz˛edu w przypadku całkowitej „zast˛epuja˛ cej migracji“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 5.7 5.8 Sytuacja wyjściowa dla migracji kontynuacyjnej . . . . . . . . . . . . . . . . . . 459 Różne warianty zastapienia ˛ Exchange w przypadku migracji cz˛eściowej . . . . . 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 jakości . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 odnośnie przygotowywania oceny ekonomicznej w administracji publicznej, ze szczególnym uwzgl˛ednieniem nakładów na technologie informatyczne“, wersja 3.0 - 2001, wydane przez KBSt, Ministerstwo Spraw Wewn˛etrznych, pisma KBSt, ISSN 0179-7263, tom 52, maj 2001 r. ◦ Specjalny katalog kryteriów IT-WiBe21 dla realizacji uaktualnień systemów informatycznych oraz zamierzeń migracyjnych opracowany przez doradztwo projektowe i orgranizacyjne dr Peter Röthig oraz prof. dr Detlef Leipelt, FH państwa dla administracji publicznej – wskazówki i zalecenia – dla realizacji uaktualnień systemów informatycnych badź ˛ zamierzeń migracyjnych na podstawie IT - WiBe - 97, wydane przez KBSt, Ministerstwo Spraw Wewn˛etrznych, 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 warsztatów w Ministerstwie Spraw Wewn˛etrznych, we współpracy z pracownikami BSI, BVA oraz C_sar 5.9.3 Główny katalog z kryteriami IT-WiBe21 dla scenariuszy migracji Na poniższych stronach katalogu, przedstawione zostały wszystkie kryteria: ◦ kryteria według WiBe21 dla kompletnych scenariuszy migracyjnych (kolor granatowy) ◦ kryteria, które można pominać ˛ dla obiektów migracji (kolor pomarańczowy)9 ◦ dodatkowe kryteria dla projektów migracyjnych zamieszczone w WiBe21 (kolor niebieski) Niniejszy podział opiera si˛e na WiBe21: 1. 1. Koszty rozwoju i wdrażania oraz korzyści z rozwoju 2. 2. Koszty wykorzystania przemysłowego oraz korzyści z wykorzystania przemysłowego 3. 3. Kryteria konieczności 4. 4. Kryteria jakościowo - strategiczne 5. Wskazówki i objaśnienia 9 Patrz katalog specjalnych kryteriów dla obiektów migracji SPIS RYSUNKÓW 5.9.3.1 Koszty rozwoju / wdrożenia oraz korzyści z rozwoju 517 SPIS RYSUNKÓW 5.9.3.2 Koszty pracy i korzyści z pracy 518 SPIS RYSUNKÓW 519 Wskazówka odnośnie kosztów pracy / korzyści z pracy: Wszystkie pozycje zawieraja˛ przykładowe informacje odnośnie kosztów i korzyści, 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 konieczności SPIS RYSUNKÓW 5.9.3.4 Kryteria jakościowo - strategiczne 520 SPIS RYSUNKÓW 5.9.3.5 521 Wskazówki i objaśnienia 5.9.4 Specjalny katalog z kryteriami IT-WiBe21 dla obiektów migracji P OZYCJA NAZWA 1 koszty rozwoju oprogramowania / koszty wdrożenia KRYTERIÓW oraz korzyści z rozwoju oprogramowania / korzyści z wdrożenia 1.1 koszty rozwoju / wdrożenia nowej procedury informatycznej 1.1.1 koszty planowania i wdrożenia / rozwoju 1.1.1.1 koszty osobowe (własnego personelu) 1.1.1.2 koszty doradztwa zewn˛etrznego 1.1.1.3 koszty systemu 1.1.2 koszty osprz˛etu 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ź ˛ 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, certyfikacji i zabezpieczenia jakości 1.1.2.3 1.1.2.3.4 koszty instalacji koszty osobowe przypadajace ˛ na instalacj˛e sytemu 1.1.3 koszty wdrożenia 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 użytkowników i specjalistycznego personelu IT 1.1.3.5 koszty wdrożenia do pracy użytkowników i specjalistycznego personelu IT 2 koszty pracy i korzyści z pracy 2.1 bieżace ˛ koszty rzeczowe / oszcz˛edności na kosztach rzeczowych 2.1.2 (procentowe) koszty hostów, serwerów i sieci 2.1.2.1 bieżace ˛ koszty dzi˛eki odejściu procedury informatycznej NOWE 2.1.2.2 bieżace ˛ oszcz˛edności dzi˛eki odejściu procedury informatycznej STARE 2.1.3 (procentowe) koszty stacji roboczych 2.1.3.1 bieżace ˛ koszty dzi˛eki odejściu procedury informatycznej NOWE 2.2 bieżace ˛ koszty rzeczowe / oszcz˛edności wynikajace ˛ z bieżacych ˛ kosztów rzeczowych 2.2.2 (procentowe) koszty na stacje robocze 2.2.2.1 bieżace ˛ koszty dzi˛eki odejściu procedury informatycznej NOWE 2.2.2.2 bieżace ˛ koszty osobowe / oszcz˛edności wynikajace ˛ z bieża˛ cych kosztów osobowych 2.2.3 opieka nad systemem i administracja systemem 2.2.3.1 bieżace ˛ koszty dzi˛eki odejściu procedury informatycznej NOWE SPIS RYSUNKÓW 2.2.3.2 523 bieżace ˛ korzyści dzi˛eki odejściu procedury informatycznej STARE 2.3 bieżace ˛ koszty / oszcz˛edności podczas konserwacji / opieki nad systemem 2.3.1 konserwacja / opieka nad osprz˛etem 2.3.1.1 bieżace ˛ koszty dzi˛eki odejściu procedury informatycznej NOWE 2.3.1.2 bieżace ˛ korzyści dzi˛eki odejścio procedury informatycznej STARE 2.3.2 konserwacja / uaktualnienie oprogramowania 2.3.2.1 bieżace ˛ koszty dzi˛eki odejściu procedury informatycznej NOWE 2.3.2.2 bieżace ˛ korzyści dzi˛eki odejścio procedury informatycznej STARE 2.3.3 koszty zast˛epowania / uzupełniania 2.3.3.1 bieżace ˛ koszty dzi˛eki odejściu procedury informatycznej NOWE 2.3.3.2 bieżace ˛ korzyści dzi˛eki odejścio procedury informatycznej STARE 2.4 pozostałe bieżace ˛ koszty i oszcz˛edności 2.4.2 koszty towarzyszacego ˛ zewn˛etrznego doradztwa 2.4.2.1 bieżace ˛ koszty dzi˛eki odejści procedury informatycznej NOWE 2.4.2.2 bieżace ˛ korzyści dzi˛eki odejściu procedury informatycnej STARE 2.4.4 pozostałe bieżace ˛ koszty i korzyści 2.4.4.1 bieżace ˛ koszty dzi˛eki odejściu procedury informatycznej NOWE 2.4.4.2 bieżace ˛ korzyści dzi˛eki odejściu procedury informatycznej STARE 3 Kryteria konieczności 3.1 konieczność zastapienia ˛ starego systemu SPIS RYSUNKÓW 524 3.1.1 wsparcie - kontynuacja starego systemu 3.1.2 stabilność 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 elastyczność starego systemu 3.1.3.1 rozbudowa / poszerzenie granic 3.1.3.2 kompatybilność, problemy z interfejsami aktualnie / w przyszłości 3.1.3.3 przyjazność dla użytkownika 3.2 zachowanie przepisów i praw urz˛edowych 3.2.1 zachowanie zapisów ustawowych 3.2.2 spełnienie kryteriów bezpieczeństwa i ochrona danych 3.2.3 prawidłowość przebiegu prac 3.2.4 spełnienie zadań i zaleceń 4 kryteria jakościowo - strategiczne 4.1 priorytet zamiaru informatycznego 4.1.1 znaczenie wewnatrz ˛ informatycznej koncepcji ramowej 4.1.2 wkomponowanie w rozbudow˛e informatyczna˛ całej administracji federalnej 4.1.3 skutki dla rozmówców 4.1.4 charakter projektu pilotażowego 4.1.5 niezależność od producenta 4.2 wzrost jakości podczas wykonywania specjalistycznych zadań 4.2.1 podniesienie wydajności podczas wykonywania zadań 4.2.2 przyspieszenie przebiegu i procesów prac 4.3 sterowanie informacja˛ na poziomie administracyjno - politycznym 4.3.1 udost˛epnienie informacji dla decydentów i kontrola 4.3.2 wsparcie procesu decyzyjnego / procesu kierowania 4.4 efekty dotyczace ˛ pracowników 4.4.1 atrakcyjność warunków pracy SPIS RYSUNKÓW 525 4.4.2 zapewnienie kwalifikacji / rozszerzenie kwalifikacji 4.4.3 powszechność / dost˛epność wykształcenia 4.5 efekty bliskości dla obywatela 4.5.4 poprawa wizerunku 4.6 powszechność / dost˛epność oprogramowania 4.6.1 stopień przenikni˛ecia rynku 4.6.2 niezależne wsparcie 4.6.3 posiadane certyfikaty na oprogramowanie 4.6.4 narz˛edzia do administrowania oprogramowaniem 4.7 bezepieczeństwo informatyczne 4.7.1 bezpieczeństwo komunikacji 4.7.2 bezpieczeństwo aplikacji 4.7.3 zabezpieczenie przed awaria˛ 4.7.4 zarzadzanie ˛ bezpieczeństwem 4.7.5 bezpieczeństwo inwestycji i planowania 5.9.5 Objaśnienie kryteriów uzupełniajacych ˛ Poniżej przedstawione zostały kryteria, które w ramach istniejacego ˛ WiBE 21 wersja 3.0 oraz uzupełniajacych ˛ wskazówek i zaleceń z roku 2000 (patrz wyżej) zostały dodane 10 do ocen ekonomicznych projektów migracji znanych już z dotychczasowych kryteriów. Dane usystematyzowane zostały według danych zapisanych w WiBe21 i dołaczone ˛ w nawiasach „()“ za nazwa.˛ 5.9.5.1 Koszty wdrożenia / korzyści z wdrożenia (1.1) Podczas migracji całego środowiska projekty migracyjne obejmuja˛ także specjalistyczne aplikacje, w przypadku których trzeba stworzyć nowe programy albo wymagane jest przeprogramowanie. Czynności te należy wykazać w „kosztach rozwoju“. Podczas migracji obiektów migracyjnych koszty rozwoju z reguły nie wyst˛epuja,˛ ale wystapi ˛ a˛ koszty wdrożenia. Aby to podkreślić, rozszerzono kryterium „koszty rozwoju“ o poj˛ecie „koszty wdrożenia 11“. 10 Patrz „Specjalny katalog kryteriów IT-WiBe21 dla projektów migracyjnych“, stworzony we współpracy BMI, BSI, BVA i C_sar. 11 Patrz pozycje kryterium: 1., 1.1 oraz 1.1.1 SPIS RYSUNKÓW 5.9.5.2 526 Powszechność / dost˛epność wykształcenia (4.4.3) Nieniejsze kryterium ukierunkowane jest na powszechość wykształcenia i dost˛epność odpowiedniego personelu. Znaczenie tego kryterium należy oceniać jakościowo. Powszechność / dost˛epność (wy)kształcenia 0 2 4 6 8 10 jest personel jest do- personel jest do- personel jest pra- wymagana wy- wymaganym dost˛epny, jednak st˛epny, kształce- st˛epny w ograni- wie niedost˛epny, kształcenie nie wykształceniem kształcenie ofe- nie jest przeważ- czonym zakresie, wiedz˛e można jest dost˛epne na jest dost˛epny na rowane jest tylko nie organizowane kształcenie trzeba przekazać tylko rynku a kształ- rynku; wykształ- w kilku centrach w ramach urz˛edu zorganizować w w ograniczonym cenie ramach urz˛edu zakresie oferowane personel cenie z personel pokrywa nie jest wszystkie obszary 5.9.5.3 Powszechność / dost˛epność oprogramowania (4.6) Stopień przenikni˛ecia rynku (4.6.1) Należy tu ocenić udział w rynku, jaki posiada oprogramowanie, które ma być zastosowane. W przypadku znikomej albo niepewnej obecności na rynku, istnieje niebezpieczeństwo, że oprogramowanie, wzgl˛ednie jego dalszy rozwój zostana˛ wstrzymane. Ponadto dobre przenikanie rynku świadczy o wysokiej akceptacji12 badź ˛ o intensywnym korzystywaniu z oprogramownia przez użytkowników, z czego można wywnioskować jego rozwój. Przenikanie rynku 0 2 4 6 produkt jest ofe- produkt jest produkt jest ofe- produkt rowany wsz˛edzie oferowany tylko rowany regional- oferowany przez wybranych nie pojedynczych dystrybutorów 8 10 jest produkt jest ofe- produkt nie jest w rowany tylko in- już oferowany dywidualnie miejscach Niezależne wsparcie (4.6.2) Niniejsze kryterium zajmuje si˛e możliwościa˛ otrzymania dla oprogramowania, które ma być 12 Akceptacja nie zawsze jest najważniejsza. Polityka biznesowa wymusza w różnych przypadkach decyzje na korzyść lepiej zoptymalizowanych albo bardziej opłacalnych systemów. SPIS RYSUNKÓW 527 zastosowane, wsparcia ze strony istniejacych ˛ na rynku, niezależnych przedsi˛ebiorstw. W oparciu o zasad˛e ochrony inwestycji zapewni to możliwość dalszego korzystania z oprogramowania, nawet gdy producent nie b˛edzie już w stanie kontynuować wsparcia. Niezależne wsparcie 0 2 4 wsparcie ofe- wsparcie rowane jest wsz˛edzie ofero- 6 wsparcie ofe- wsparcie wane jest tylko rowane jest rowane przez wybranych regionalnie dystrybutorów 8 ofejest w pojedynczych 10 wsparcie ofe- wsparcie nie jest rowane jest (już) oferowane indywidualnie miejscach Posiadane certyfikaty na oprogramowanie (4.6.3) Za pomoca˛ tego kryterium należy szukać odpowiedzi na pytanie czy oprogramowanie, które ma być zastosowane odpowiada wymaganiom prawnym badź ˛ specyficznym dla urz˛edu lub branży, czy też może trzeba je samemu stworzyć. W pierwszym przypadku o certyfikaty troszczy si˛e producent / dostawca, w zwiazku ˛ z tym nie przewiduje si˛e ponoszenia kosztów własnych. W drukim przypadku trzeba samemu uzyskać bieżace ˛ certyfikaty, aby zagwarantować zwykłe pokrycie procesów biznesowych. W takiej sytuacji powstaja˛ koszty własne, które można obliczyć ryczałtem. Posiadane certyfikaty na oprogramowanie 0 2 4 6 8 10 oprogramowanie oprogramowanie oprogramowanie oprogramowanie oprogramowanie oprogramowanie posiada cer- posiada posiada jednora- posiada posiada nie tyfikat, który zowy certyfikat ściowa˛ certyfika- kowa˛ certyfikacj˛e certyfikatu, nie cj˛e lub tylko zalece- można też nia zdobyć jest regularnie odnawiany certy- fikat, który nie jest regularnie odnawiany cz˛e- szczat˛ Dost˛epność narz˛edzi do administrowania oprogramowaniem (4.6.4) Administrowanie oprgramowaniem, które ma być zastosowane, okazuje si˛e w niektórych przypadkach mało wygodne a nawet trudne. W niniejszym kryterium należy przeanalizować narz˛edzia, które przejmuja˛ albo wspieraja˛ zarzadzanie ˛ tabelami i podstawowymi danymi. Za pomoca˛ odpowiednio inteligentnych narz˛edzi można zwi˛ekszyć zakres i jakość administrowania oraz zoptymalizować stosowanie zasobów. Dost˛epność narz˛edzi do administrowania oprogramowaniem 0 2 4 6 8 10 posiada go SPIS RYSUNKÓW na rynku nieje ist- do narz˛edzia do narz˛edzia do narz˛edzia do narz˛edzia administrowania administrowania administrowa- administrowania administrowania do dost˛epne dost˛epne sa˛ tylko nia należy nie sa˛ dost˛epne sporadycznie niedost˛epne administrowania sa˛ warunkowo sa˛ ledwo tworzyć indywidualnie i nie można ich oprogramowa- indywidualnie niem stworzyć 5.9.5.4 do 13 dość narz˛edzi narz˛edzia 528 Bezpieczeństwo informatyczne (4.7) „Bezpieczeństwo“ wpisuje si˛e po cz˛eści w kryteria konieczności (patrz „downtime“ albo „Ochrona i bezpieczeństwo danych“). W tym miejscu należy wrócić do tego tematu, jednak tym razem z punktu widzenia strategicznego i jakościowego oraz należy wskazać na udział zarzadzania. ˛ Bezpieczeństwo komunikacji (4.7.1) Za pomoca˛ nieniejszego kryterium należy sprawdzać bezpieczeństwo wewn˛etrznej i przede wszystkim zewn˛etrznej komunikacji. Jak zabezpieczona jest transmisja danych? Czy stosowane sa˛ bezpieczne protokoły? Czy istnieje zabezpieczenie transmisji, kontrola dost˛epu, itd.? Bezpieczeństwo komunikacji 0 2 4 6 8 10 niezagrożone prawie niezagro- troch˛e zagrożone, przeci˛etnie ponadprzeci˛etnie bardzo silnie za- żone w granicach tole- zagrożone, zagrożone, grożone, nie da- rancji zakłócenia uciażliwości ˛ jace ˛ si˛e tolerować Bezpieczeństwo aplikacji (4.7.2) Czy oprogramowanie jest sprawdzone pod katem ˛ bezpieczeństwa informatycznego? Na ile jest ono podatne na ataki z zewnatrz, ˛ wirusy itd.? Czy oprogramowanie ma budow˛e modularna˛ (rozdział systemu od aplikacji, minimalizacja ilości aplikacji do koniecznych funkcji)? Czy istnieja˛ procedury kontroli dost˛epu? Bezpieczeństwo aplikacji 0 13 2 4 6 8 Dość oznacza, że narz˛edzia oferowane sa˛ przez wiele niezależnych przedsi˛ebiorstw 10 SPIS RYSUNKÓW niezagrożone 529 prawie niezagro- troch˛e zagrożone, przeci˛etnie ponadprzeci˛etnie bardzo silnie za- żone w granicach tole- zagrożone, zagrożone, grożone, nie da- rancji zakłócenia uciażliwości ˛ jace ˛ si˛e tolerować Zabezpieczenie przed awaria˛ (4.7.3) Jak silnie na bezpieczeństwo pracy wpływaja˛ awarie systemu? Czy istnieja˛ odpowiednie Recovery - Routinen? Zabezpieczenie przed awaria˛ 0 2 4 6 8 10 niezagrożone prawie niezagro- troch˛e zagrożone, przeci˛etnie ponadprzeci˛etnie bardzo silnie za- żone w granicach tole- zagrożone, zagrożone, grożone, nie da- rancji zakłócenia uciażliwości ˛ jace ˛ si˛e tolerować Zarzadzanie ˛ bezpieczeństwem (4.7.4) Czy istnieje zarzadzanie ˛ bezpieczeństwem? Czy istnieje pomysł na bezpieczeństwo, który jest znany wszystkim? Czy istnieje opisany proces kontroli bezpieczeństwa oraz jego dokumentacja? Zarzadzanie ˛ bezpieczeństwem 0 2 4 6 istnieje w przeważajacej ˛ cz˛eściowo istnieje cz˛eści istnieje istnieje miejscami tylko 8 10 istnieja˛ zaledwie nie istnieje sporadyczne ślady Bezpieczeństwo inwestycji i planowania (4.7.5) Niniejsze kryterium zajmuje si˛e suma˛ wpływów wszystkich wcześniej przedstawionych, ważnych kryteriów bezpieczeństwa i wskazuje czy inwestycja i zwiazane ˛ z nia˛ plany sa˛ nadal uzasadnione. Bezpieczeństwo inwestycji i planowania 0 2 4 6 8 10 niezagrożone prawie niezagro- troch˛e zagrożone, przeci˛etnie ponadprzeci˛etnie bardzo silnie za- żone w granicach tole- zagrożone, zagrożone, grożone, nie dajace ˛ rancji zakłócenia uciażliwości ˛ si˛e tolerować