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 Państwo!
Niniejszy poradnik został przetłumaczony przez osoby wchodzace
˛ w skład grupy
OpenPoland.org.
Pragniemy zaznaczyć, że nasza praca została wykonana nie na zlecenie, lecz za
zgoda˛ BMI1 . Jednocześnie informujemy, że tekst niniejszego tłumaczenia udost˛epniamy nieodpłatnie i nie wolno go sprzedawać w żadnej postaci. Powyższe
zasady zredagowane zostały w oparciu o uzgodnienia poczynione z BMI jeszcze
przed rozpocz˛eciem prac nad tłumaczeniem.
Mamy nadziej˛e, że rozwiazania
˛
przedstawione w poradniku już niedługo zyskaja˛
wielu zwolenników, szczególnie wśród szerokiego grona osób odpowiedzialnych za
funkcjonowanie infrastruktury informatycznej w naszym kraju.
Zach˛ecamy Państwa do współpracy nad rozwojem poradnika. Prosimy o zgłaszanie
konstruktywnych, krytycznych uwag na adres: [email protected] .
Na zakończenie pragniemy podkreślić, że nie jesteś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 treści
1
2
Wprowadzenie
16
1.1 Geneza poradnika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2
O poradniku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3
Jak korzystać z poradnika? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4
Wskazówki dla decydentów . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.1 Podstawowe zalecenia . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.2
Migracja kontynuacyjna i zast˛epujaca
˛ . . . . . . . . . . . . . . . . . . . 22
1.4.3
1.4.4
Różne drogi migracji . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Porównanie alternatywnych rozwiazań
˛
. . . . . . . . . . . . . . . . . . 23
1.4.5
Istotne zagadnienia przyszłościowe . . . . . . . . . . . . . . . . . . . . 24
1.4.6
Korzyści ekonomiczne . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Najważniejsze zagadnienia
2.1
2.2
2.3
28
Ważne definicje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.1
2.1.2
Open Source, Free Software . . . . . . . . . . . . . . . . . . . . . . . . 28
Oprogramowanie własnoś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 wyjś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 zależności systemu opartego o rozwiazania
˛
firmy Microsoft
36
Dystrybucje Linuksa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3.1 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3
SPIS TREŚ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
Doś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 odnośnie funkcjonalności . . . . . . . . . . . . . 57
System plików NTFS4 . . . . . . . . . . . . . . . . . . . . . 58
3.2.2.3
Ustawianie praw dost˛epu . . . . . . . . . . . . . . . . . . . . 62
3.2.2.4
Uż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
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
3.2.4.1 Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.2.4.2
Windows 2003 Server . . . . . . . . . . . . . . . . . . . . . . 87
SPIS TREŚCI
3.3
5
Drukowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.3.1
Przeglad
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.3.2
3.3.3
Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Punkt wyjś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
Bezpoś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
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
3.3.4.1
3.3.4.2
3.3.4.3
Obsługa standardów wyróżniajacych
˛
si˛e w procesie drukowania 101
Integracja w środowiskach klienckich Windows . . . . . . . . 104
3.3.4.4
Możliwoś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
3.3.5.1
3.4
Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Autoryzacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.4.1
3.4.2
Przeglad
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Punkt wyjś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 TREŚ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
˛ - 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 umoż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
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 wyjś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
˛ - 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 TREŚCI
7
3.5.4.3
3.6
Kontrola i zarzadzanie
˛
systemem . . . . . . . . . . . . . . . . . . . . . . . . . . 140
3.6.1
3.6.2
Przeglad
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Punkt wyjścia - serwery zarzadzaj
˛
ace
˛ systemem pod Windows NT 4 . . . 140
3.6.3
˛ - 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łoż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
Nowości w strukturze . . . . . . . . . . . . . . . . . . . . . . 155
3.7.3.4
Przestrzeń 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
3.7.3.8
Certyfikacja . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
3.7.3.9 Smart Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
˛ - Samba i Open LDAP . . . . . . . . . . . . . . . 171
3.7.4.1
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 TREŚCI
3.7.5
3.8
3.9
8
3.7.4.6
Integracja innych aplikacji . . . . . . . . . . . . . . . . . . . . 174
3.7.4.7
3.7.4.8
3.7.4.9
Zachowanie podczas pracy i zużycie zasobów . . . . . . . . . 175
Akceptacja użytkowników . . . . . . . . . . . . . . . . . . . 175
Migracja kontynuacyjna - Wprowadzenie do ADS . . . . . . . . . . . . 175
3.7.5.1
3.7.5.2
Kolejność . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 bezpieczeń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 TREŚ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 Skalowalność . . . . . . . . . . . . . . . . . . . . . . . . . . 221
3.13.3.6 Nadawanie praw dost˛epu . . . . . . . . . . . . . . . . . . . . 222
3.13.3.7 Integracja systemu . . . . . . . . . . . . . . . . . . . . . . . . 222
3.13.3.8 Administrowanie . . . . . . . . . . . . . . . . . . . . . . . . 222
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 pośredni . . . . . . . . . . . . . . . . . . . . . . . . . 228
3.13.4.6 Wskazówki . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
3.13.4.7 Zalecenia odnośnie niezależności . . . . . . . . . . . . . . . . 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 wyjścia - Microsoft Exchange 5.5 . . . . . . . . . . . . . . . . . . 234
3.14.3.1 Infrastruktura podstawowa . . . . . . . . . . . . . . . . . . . 234
3.14.3.2 Logiczne jednostki struktury . . . . . . . . . . . . . . . . . . 234
SPIS TREŚ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 Funkcjonalności uż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
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.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 wyjścia - MS Office . . . . . . . . . . . . . . . . . . . . . . . . . 271
3.15.3.1 Funkcjonalności . . . . . . . . . . . . . . . . . . . . . . . . . 272
3.15.3.2 Środowisko programistyczne MS Office . . . . . . . . . . . . 273
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
3.15.4.1 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . 276
3.15.4.2 Róż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óżnice w działaniu . . . . . . . . . . . . . . . . . . . . . . . 283
3.15.4.5 Waż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 TREŚCI
11
3.15.4.10 Środowisko programowania OOo/SO . . . . . . . . . . . . . . 297
3.15.4.11 Kompatybilność z MS Office . . . . . . . . . . . . . . . . . . 298
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 Menedż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 uż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 niezawodności . . . . . . . . . . . . . . . 342
3.17.1 Cele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
3.17.2 „Pi˛eć dziewiatek”
˛
a rzeczywistość . . . . . . . . . . . . . . . . . . . . . 343
3.17.3 Sposób podejś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 TREŚ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 wydajnoś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 korzyści . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
4.2.3
IT-WiBe 21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
4.2.4
4.2.5
Koszty migracji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
TCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
4.2.6
Porównywalność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
4.2.7
4.2.8
Instalacja od podstaw a migracja . . . . . . . . . . . . . . . . . . . . . . 359
Obliczanie pełnych kosztów . . . . . . . . . . . . . . . . . . . . . . . . 359
Wymiar pieni˛eżny (operacyjny) . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
4.3.1
4.3.2
Obszary zastosowań . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Kategorie kosztów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
4.3.3
Własności uż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 średniej wielkości . . . . . . . . . . . . . . . . . . . . 364
Duż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 wydajności ekonomicznej . . . . . . . . . . . . . . . . . . . . . . 366
4.6
Zalecenia migracyjne oparte na ocenie wydajności ekonomicznej . . . . . . . . . 368
4.6.1 Migracja pełna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
4.6.2
4.6.3
Migracja cz˛eściowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
4.6.3.1
4.6.3.2
4.7
Migracja punktowa . . . . . . . . . . . . . . . . . . . . . . . 372
Migracja cz˛eściowa po stronie serwera . . . . . . . . . . . . . 373
Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
SPIS TREŚCI
4.8
4.9
5
13
Nakłady według różnych scenariuszy migracji . . . . . . . . . . . . . . . . . . . 375
4.8.1
Ogólne założ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 odnośnie sposobu oceny produktów / grup produktów . . . . . 388
4.8.6.1
Generalne założenia . . . . . . . . . . . . . . . . . . . . . . . 388
4.8.6.2
4.8.6.3
Przykłady według struktury WiBe21 . . . . . . . . . . . . . . 389
Przykład migracji: Messaging / Groupware – duż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˛eściowa . . . . . . . . . . . . . . . . . . . . . . . 426
Przykładowa ocena konieczności oraz jakości i strategii migracji . . . . . . . . . 430
4.9.1
4.9.2
Kryteria konieczności . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Kryteria jakościowo - strategiczne . . . . . . . . . . . . . . . . . . . . . 430
4.9.3
Analiza korzyści . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Zalecenia migracyjne
5.1
Ogólne wyjaś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
Średnie i duż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 TREŚCI
14
5.2.3
Specjalizowane urz˛edy ś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 dowolności . . . . . 460
5.3.2 Inne ścieżki migracji . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Migracja cz˛eściowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
5.4.1
Migracja punktowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
5.4.2
Cz˛eś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 środowiska docelowego wśród użytkowników . . . . . . . . . . . . . . . . . . . 476
5.5.3.4
Szkolenia dla uż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
Określenie punktu wyjścia . . . . . . . . . . . . . . . . . . . 480
5.5.3.8
Spełnienie wymagań funkcjonalnych . . . . . . . . . . . . . . 481
5.5.3.9 Korzystanie z wartości doś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 jakości projektu . . . . . . . . 483
5.5.3.13 Opieka na etapie pracy . . . . . . . . . . . . . . . . . . . . . 485
5.6
Eksperci współpracujacy
˛ nad poradnikiem . . . . . . . . . . . . . . . . . . . . . 485
SPIS TREŚCI
15
5.7
Spis skrótów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
5.8
Słownik poj˛eć . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 / wdrożenia oraz korzyści z rozwoju . . . . . . 517
5.9.4
5.9.5
5.9.3.2
Koszty pracy i korzyści z pracy . . . . . . . . . . . . . . . . . 518
5.9.3.3
5.9.3.4
Kryterium konieczności . . . . . . . . . . . . . . . . . . . . . 519
Kryteria jakościowo - strategiczne . . . . . . . . . . . . . . . 520
5.9.3.5
Wskazówki i objaśnienia . . . . . . . . . . . . . . . . . . . . 521
Specjalny katalog z kryteriami IT-WiBe21 dla obiektów migracji . . . . . 521
Objaśnienie kryteriów uzupełniajacych
˛
. . . . . . . . . . . . . . . . . . 525
5.9.5.1
Koszty wdrożenia / korzyści z wdrożenia (1.1) . . . . . . . . . 525
5.9.5.2
Powszechność / dost˛epność wykształcenia (4.4.3) . . . . . . . 526
5.9.5.3
5.9.5.4
Powszechność / dost˛epność oprogramowania (4.6) . . . . . . . 526
Bezpieczeństwo informatyczne (4.7) . . . . . . . . . . . . . . 528
Rozdział 1
Wprowadzenie
„Produkt zast˛epuje inny produkt wtedy, gdy okazuje si˛e, że zach˛eta do jego używania jest silniejsza niż koszty wynikajace
˛ z zamiany produktów i gdy przezwyci˛eżony
zostanie opór wzgl˛edem zmian. Produkt zast˛epczy jest atrakcyjny dla odbiorcy wówczas, gdy oferuje on wyższa˛ wartość od dotychczas używanego produktu i nie jest
od niego droższy. “
M.E. Porter
1.1 Geneza poradnika
Trudno znaleźć lepsze okreś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 konkurencyjności okr˛et flagowy Open Source
jakim jest GNU/Linux już dawno uzyskał uprzywilejowana˛ pozycj˛e „produktu zast˛epczego”.
Inne produkty, takie jak MySQL, PostgreSQL czy OpenOffice.org pewnie podażaj
˛ a˛ jego śladami. (Wszystkich, którym brakuje w tym miejscu serwera Apache, pragniemy poinformować,
że zdaniem autorów produkt ten należy traktować 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 już 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
należałoby si˛e spodziewać, że wytłumaczenie tego zjawiska nie b˛edzie trudne.
16
ROZDZIAŁ 1. WPROWADZENIE
17
Jednak okazuje si˛e, że założenie to nie jest prawdziwe. Wr˛ecz przeciwnie. W branży informatycznej mało który temat prowadzi do tak kontrowersyjnych dyskusji o zaletach i wadach, jak
wykorzystywanie oprogramowania Open Source. Należy przy tym zrozumieć, że roczne obroty
ze sprzedaży samego systemu operacyjnego Windows wynosza˛ ponad 10 mld. USD, a zatem na
toczac
˛ a˛ si˛e dyskusj˛e maja˛ także wpływ ważne interesy ekonomiczne.
Obok wyjatkowości
˛
modelu licencji i cz˛esto pojawiajacych
˛
si˛e pytań dotyczacych
˛
jego wpływu
na zmiany w branży informatycznej, dyskutowane sa˛ w jednakowym stopniu właściwoś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 zinterpretować oceny.
Dodatkowe znaczenie ma fakt, że w konkurencji - Open Source kontra Microsoft - nie chodzi o
pojedyncze programy, lecz o niemalże kompletna˛ platform˛e dajac
˛ a˛ duży wybór oprogramowania.
W tej bardzo skomplikowanej sytuacji, na która˛ maja˛ wpływ wielostronne interesy, decydujaca
˛ rola przypada obiektywnej i całościowej analizie.
Odpowiednia ocena powinna uwzgl˛edniać nie tylko właściwości techniczne oprogramowania, lecz musi si˛e ona również opierać o konkretny punkt wyjścia dla ewentualnego wdrożenia,
w szczególności o specyficzne finansowe, strukturalno - organizacyjne i polityczne warunki ramowe działalności administracji publicznej w Niemczech.
1.2 O poradniku
Już sam tytuł poradnika wskazuje na to, że zasadnicze decyzje zwiazane
˛
z wprowadzaniem oprogramowania Open Source wpisuja˛ si˛e w „naturalny” cykl życia komercyjnego oprogramowania
Microsoft. Dobrym tego przykładem jest wycofanie wsparcia technicznego dla wciaż
˛ szeroko
rozpowszechnionego systemu operacyjnego Windows NT, którego nast˛epca wymaga z zasady
innego sposobu zarzadzania
˛
domenami.
Aby odróżnić zast˛epowanie tego oprogramowania produktami OSS od przejścia na produkty
Microsoft nast˛epnej generacji, wprowadziliśmy poj˛ecie migracji zast˛epujacej
˛ i migracji kontynuacyjnej. W niniejszym poradniku nie skoncentrowaliśmy si˛e tylko na sposobach zastapienia
˛
już
stosowanego oprogramowania, lecz także na wskazaniu rozwiazań
˛
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˛eść (rozdział 2) zajmuje si˛e przedstawieniem punktu wyjścia dla oprogramowa-
18
nia. Rozstrzyga on o sposobie przeprowadzenia migracji i stanowi przeglad
˛ podstawowej architektury oprogramowania Microsoft, jak również alternatywnej, opartej na otwartych standardach
platformy Open Source. Tak zwana mapa systemu wskazuje przy tym możliwości zastapienia
˛
produktów pełniacych
˛
określone funkcje, innymi produktami i rozwiazaniami
˛
oraz pokazuje
zwiazki
˛ pomi˛edzy poszczególnymi warstwami oprogramowania.
Druga cz˛eść (rozdziały 3 i 4) jest próba˛ odpowiedzi na pytanie o możliwość potencjalnej
migracji albo zastosowania całkiem nowych systemów IT oraz infrastruktury informatycznej.
Poszczególne zakresy zastosowań oprogramowania opisane zostały zarówno z technicznego, jak
i z ekonomicznego punktu widzenia. Podczas, gdy pierwszy koncentruje si˛e na identyfikacji i
ocenie rozwiazań
˛
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˛eści trzeciej (rozdział 5) umieściliśmy zalecenia migracyjne, które odnosza˛ si˛e do różnych struktur administracji. Zalecenia te sa˛ wynikiem otrzymanym na podstawie oceny technicznej i ekonomicznej. Zawieraja˛ one konkretne propozycje dla małych, średnich, dużych i
specjalizowanych urz˛edów. Dodatkowo rozważamy tu zalety i wady różnych dróg migracji. Na
końcu trzeciej cz˛eści przedstawione zostały krytyczne wyznaczniki sukcesu migracji. Pomimo,
że zast˛epowanie jednego oprogramowania innym nie jest w zasadzie niczym nowym, to jednak
różne doświadczenia wyniesione z projektów wdrożonych w administracji publicznej wskazuja˛
na konieczność bardzo starannego zaplanowania i wykonania migracji, gdyż ostateczny sukces takiego przedsi˛ewzi˛ecia ściśle wiaże
˛ si˛e z przygotowaniem pracowników bioracych
˛
w niej
udział.
Podczas wielomiesi˛ecznej pracy nad poradnikiem migracyjnym wielokrotnie okazywało si˛e,
że zagadnienia tu opisane zmieniaja˛ si˛e bardzo szybko i dynamicznie. W czasie prac nad projektem ilość oprogramowania dost˛epnego pod Linuksem, zarówno tego publikowanego na licencji
GPL, jak i komercyjnego, znacznie wzrosła. Podobny wzrost miał miejsce jeśli chodzi o ilość
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 dużych firm programistycznych jak SAP, Oracle, Sun
czy IBM, z dnia na dzień rośnie także oferta małych i ś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łości przez ofert˛e OSS, a z
drugiej strony powoduje coraz wi˛eksze trudności podczas wykonywania przegladu
˛ aktualnego
stanu oprogramowania.
19
Oczywiście zadaniem samego czytelnika b˛edzie dostrzeżenie własnych korzyści w oparciu
o wymienione w poradniku zach˛ety. Autorzy niniejszego opracowania maja˛ nadziej˛e, że b˛edzie
ono pomocne i zapewni wsparcie każdemu, kto rozważa skutki techniczne i ekonomiczne migracji.
1.3 Jak korzystać z poradnika?
Czytelnikom poradnika pragniemy wskazać, w jaki sposób należy korzystać z wewn˛etrznej
struktury dokumentu. Mamy nadziej˛e, że dzi˛eki niniejszym poradom poruszanie si˛e po dość
obszernym poradniku stanie si˛e łatwiejsze. Pami˛etajmy zatem o tym, ż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 ważna jest szczegółowa techniczna analiza migracji. Zapoznanie si˛e z poniższymi wskazówkami zalecamy wszystkim osobom należacym
˛
do w/w grup.
Bezpoś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 spostrzeżeń oraz zwi˛ezłym opisem doświadczeń zebranych w czasie zrealizowanych już projektów
migracyjnych.
Czytajac
˛ poradnik nie należy opuszczać czterech pierwszych podrozdziałów rozdziału drugiego. Mieszcza˛ si˛e w nich bowiem ważne definicje, których poznanie ma istotne znaczenie dla
zrozumienia dalszych cz˛eści poradnika. W kolejnych rozdziałach opisane zostały składniki systemu leżace
˛ u podstaw migracji zast˛epujacej
˛ i kontynuacyjnej.
Jako uzupełnienie dla decydentów, którzy chcieliby zapoznać si˛e z techniczna˛ ocena˛ procesu
migracji odnoszac
˛ a˛ si˛e każdorazowo do poszczególnych jego składników, na poczatku
˛ rozdziału
3 streszczone zostały cele oraz dokonano oceny uzyskanych wyników.
Właściwe zestawienie i ocena wyników ekonomicznych mieści si˛e w rozdziale 4.7, natomiast
rozdział 5 zawiera odpowiednie ekonomiczne zalecenia dotyczace
˛ skutków różnych metod migracji.
Ocena wydajności ekonomicznej (rozdział 4) naświetla finansowe aspekty projektów migracyjnych i ma szczególne znaczenie dla osób podejmujacych
˛
strategiczne decyzje gospodarcze.
W oparciu o różne scenariusze oceniliśmy pieni˛eżne aspekty możliwych metod migracji.
W celu dogł˛ebnego poznania zaleceń ważnych dla urz˛edów, zach˛ecamy do przeczytania roz-
20
działu „Zalecenia migracyjne”. Mieszcza˛ si˛e tu różne scenariusze migracji 1 oraz wskazówki
dotyczace
˛ zastosowania odpowiedniej kombinacji oprogramowania dla urz˛edów i instytucji o
różnej strukturze2. Opieraja˛ si˛e one na wynikach dokonanych wcześniej ocen technicznych i
ekonomicznych. Szczególnie interesujace
˛ moga˛ okazać si˛e rozważania z rozdziału „Krytyczne
wyznaczniki sukcesu”, który wskazuje czytelnikom warunki, jakie należy spełnić, by wdrożenie
odpowiedniego projektu zakończyło si˛e sukcesem.
Po zapoznaniu si˛e z powyższym, decydenci uzyskaja˛ istotne dla siebie informacje. Jednak
zach˛ecamy każda˛ z tych osób do przeczytania także pozostałych rozdziałów niniejszego poradnika.
Dla pracowników działów IT interesujace
˛ powinny okazać si˛e wszystkie zebrane tu informacje. Poradnik zbudowany jest w taki sposób, że zaraz po wprowadzeniu można przeczytać
rozdział 2 „Najważniejsze zagadnienia” przedstawiajacy
˛ ogólne informacje stanowiace
˛ kompendium wiedzy potrzebnej do zrozumienia dalszych cz˛eści poradnika. Oprócz, wymienionych już
powyżej, pierwszych czterech podrozdziałów, znajduja˛ si˛e kolejne, w których opisane zostały
różne dystrybucje GNU/Linuksa, licencje Open Source oraz przede wszystkim wskazówki odnośnie danych zebranych na potrzeby poradnika.
Szczegółowa ocena techniczna zamieszczona w rozdziale 3 z pewnościa˛ stanowić b˛edzie,
wraz ze znajomościa˛ lokalnych wymagań i możliwości technicznych, najważniejsze źródło informacji, np. udzielajacym
˛
odpowiedzi na nast˛epujace
˛ pytania:
◦ Co jest możliwe, wzgl˛ednie gdzie można spodziewać si˛e problemów?
◦ Jak można poradzić sobie ze znanymi problemami lub ich uniknać?
˛
◦ Z jakich funkcjonalności można nadal korzystać po migracji, wzgl˛ednie gdzie pojawia˛ si˛e
ograniczenia?
◦ itd.
W poszczególnych rozdziałach składniki systemu b˛eda,˛ za każdym razem, oceniane z technicznego punktu widzenia. Opisany zostanie techniczny punkt wyjścia i nast˛epnie różne aspekty migracji zast˛epujacej
˛ i kontynuacyjnej. Dla czytelników posiadajacych
˛
odpowiednia˛ wiedz˛e techniczna˛ interesujacy
˛ może okazać si˛e przeglad
˛ różnych technologii. Każdy zyska możliwość
szczegółowego zapoznania si˛e z przeznaczeniem opisanych tu, różnych rozwiazań
˛
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˛eściowa
urz˛edy małe, średnie, duże i specjalizowane
21
Linuksie, szczególnie ważne b˛eda˛ rozdziały dotyczace
˛ migracji zast˛epujacej
˛ zawierajace
˛ różnorodne informacje.
W rozdziale 5 znaleźć można konkretne zalecenia powstałe w oparciu o oceny techniczne
i ekonomiczne zgromadzone we wcześniejszych rozdziałach. Przedstawione zostały tu różne
scenariusze przeznaczone dla różnych, ze wzgl˛edu na wielkość i zakres wykonywanych zadań,
urz˛edów. Czytelnik ma możliwość uzyskania precyzyjnej informacji, odpowiednio do swoich
potrzeb i konkretnej sytuacji.
1.4 Wskazówki dla decydentów
1.4.1 Podstawowe zalecenia
Zgodnie z tym, co zostało zasygnalizowane już w poprzednim rozdziale, w poradniku migracyjnym przedstawione zostana˛ dwie podstawowe drogi migracji:
◦ migracja zast˛epujaca
˛
oraz
◦ migracja kontynuacyjna.
Zasadniczy wynik można w tym miejscu z góry przewidzieć; ilość 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 obniżaja˛ koszty, natomiast z drugiej strony, z upływem lat, projektom migracyjnym toruje drog˛e duża dojrzałość, rozpowszechnienie i kompatybilność tego typu
produktów. To wszystko powoduje obecnie niższe koszty wdrożenia, niż miałoby to miejsce w
przeszłości. Wyniki oceny wydajności ekonomicznej potwierdzaja˛ w szczególności, że do znacznych oszcz˛edności może prowadzić nie tylko rezygnacja w niektórych przypadkach z opłat licencyjnych, ale przede wszystkim konkurencja w dziedzinie systemów operacyjnych i programów
biurowych.
Wyniki przedstawione w poradniku odnosza˛ si˛e w pierwszym rz˛edzie do sytuacji ciagle
˛ jeszcze panujacej
˛ w wi˛ekszości urz˛edów, które wyposaż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.
22
1.4.2 Migracja kontynuacyjna i zast˛epujaca
˛
Konfiguracja ta stanowi punkt wyjścia dla migracji kontynuacyjnej w środowisku produktów
Microsoft. W niniejszym rozdziale zajmiemy si˛e ocena˛ możliwości zastapienia
˛
w/w produktów
przez Windows 2000 i oprogramowanie z serii 2000, jak również przez Windows XP i Windows
2003. To, że skoncentrujemy si˛e na Windows 2000 nie oznacza, że wszyscy, którzy dokonali już
przejścia na Windows 2000 powinni w tym momencie odłożyć poradnik na półk˛e. Także urz˛edom stosujacym
˛
już t˛e technologi˛e przyda si˛e zarówno znajomość zawartej tu oceny technicznej,
jak i ważnych zaleceń. Ich przestrzeganie, a także podj˛ecie zwiazanych
˛
z nimi odpowiednich kroków prowadzacych
˛
do redukcji wewn˛etrznego stopnia uzależ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łaśnie przeprowadziły migracj˛e na Windows 2000 oraz takich, które chwilowo
nie chca˛ odstapić
˛ od korzystania z produktów Microsoft lub (z różnych powodów musza˛ wciaż
˛
z nich korzystać).
Oglad
˛ migracji zast˛epujacej
˛ pokazuje, że różnorodność oraz duża ilość rozwiazań
˛
sprawia,
iż sensowne staje si˛e rozróżnienie omawianych wyników i zaleceń. Szczególnie istotnymi kryteriami wyboru właściwego rozwiazania
˛
sa˛ zakres usług informatycznych, intensywność ich używania oraz „Stopień wyspecjalizowania” w przypadku urz˛edów, które same świadcza˛ usługi
informatyczne na rzecz innych urz˛edów. Oprócz wyboru odpowiednich produktów i właściwych
konfiguracji, konieczne jest znalezienie prawidłowych scenariuszy migracji. W tym miejscu w
poradniku wyróżniono migracj˛e punktowa,
˛ szeroka˛ i pełna˛ - w zależności od informatycznego
„stopnia pokrycia obszaru”. Punktowo, przez zastapienie
˛
pojedynczych składników używanego
systemu, takich jak, np. MS Office Suite albo MS Exchange. Cz˛eś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 rozwiazań
˛
należy preferować, by spełnić
określone wymagania urz˛edu i dostosować system informatyczny do struktury urz˛edu.
1.4.3 Różne drogi migracji
Waż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 możliwość w wysokim stopniu bezproblemowego komponowania i uż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-
23
łajace
˛ na platformie GNU/Linux. Optymalna˛ drog˛e migracji wyznacza wiele czynników. Szybka
migracja oznacza (jak można wnioskować 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 badź
˛ to już zwiazane
˛
sa˛ w dużym stopniu z oprogramowaniem uniksowym badź
˛ 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˛eściowych i/lub punktowych. Łagodne migracje
daja˛ możliwość nadrobienia w miejscu pracy zacofania z zakresu know-how w odniesieniu do
nowych technologii oraz stopniowego wdrożenia administratorów i użytkowników do nowych
technologii i oprogramowania.
Niezależnie od wybranej drogi migracji, jeśli chcemy osiagn
˛ ać
˛ końcowy sukces, musimy
przestrzegać tak zwanych krytycznych wyznaczników sukcesu. Zostały one wyszczególnione w
zaleceniach. Chodzi m.in. o niezb˛edne przygotowania, działania służace
˛ właściwemu przekazywaniu informacji i stworzenie atmosfery akceptacji w kr˛egu użytkowników, niezb˛edne szkolenia
oraz o zadania na poziomie zarzadzania
˛
projektem i ogólna˛ organizacj˛e.
Nawet w sytuacji, kiedy niemal dla każdego zastosowania i wymogu istnieja˛ adekwatne rozwiazania,
˛
sama zamiana czegoś znanego na coś nowego zwiazana
˛
jest, w wi˛ekszości przypadków, z trudnościami i cz˛esto subiektywnymi „bólami”. Zasadniczo można jednak powiedzieć, że
obydwie drogi migracji niosa˛ ze soba˛ wiele nowego zarówno dla projektantów, jak i dla administratorów. To samo dotyczy użytkowników, przy czym dotyczace
˛ ich zmiany nie sa˛ z reguły aż
tak widoczne.
1.4.4 Porównanie alternatywnych rozwiaza
˛ ń
Wiadomo, że nie wszystkie funkcjonalności dostarczane przez Windows i inne produkty firmy
Microsoft znajduja˛ swoje lustrzane odbicie w oprogramowaniu Open Source badź
˛ oprogramowaniu komercyjnym działajacym
˛
w systemie operacyjnym GNU/Linux. Jednakże, jak wykazały
doświadczenia użytkowników obu platform potwierdzone wynikami uzyskanymi podczas przeprowadzonych już migracji, funkcjonalność w/w oprogramowana jest porównywalna.
Ponieważ w pojedynczych przypadkach może chodzić o specjalne zastosowania i konkretne
właściwości, zaleca si˛e by każdy urzad
˛ dokonał samodzielnej oceny ewentualnych krytycznych
odst˛epstw majacych
˛
wpływ na oczekiwana˛ funkcjonalność. Odst˛epstw takich spodziewać si˛e
można przede wszystkim w obszarze aplikacji biurowych, w szczególności jeśli chodzi o integracj˛e tych aplikacji z oprogramowaniem specjalistycznym, jak również kompatybilności podczas
24
wymiany dokumentów pomi˛edzy pakietami Microsoft Office i OpenOffice.org lub StarOffice.
Problemy kompatybilności prowadza˛ do tego, że wspólna edycja dokumentów przy wykorzystaniu OpenOffice.org lub StarOffice i MS Office możliwa jest w bardzo ograniczonym zakresie. W
zasadzie wspólna edycja możliwa jest tylko na poziomie zawartości.
Z ocen technicznych wynika, że istnieja˛ darmowe badź
˛ komercyjne zamienniki dla systemu
operacyjnego Windows oraz dla usług sieciowych opartych o ten system. Dotyczy to także desktopów. Wspomniane zamienniki pracuja˛ pod kontrola˛ GNU/Linux.
◦ Jeśli chodzi o usługi sieciowe i obsług˛e środowisk mieszanych, ważna˛ rol˛e odgrywaja˛
Samba i OpenLDAP oraz CUPS b˛edacy
˛ innowacyjna˛ i zarazem skuteczna˛ usługa˛ umożliwiajac
˛ a˛ drukowanie w sieci. CUPS spełnia wszystkie wymagania stawiane nowoczesnym,
wydajnym i kompleksowym protokołom wydruku. Ilość programów do zarzadzania
˛
siecia˛ opartych o wolne oprogramowanie systematycznie rośnie i jest nieustannie udoskonalana. Ponadto cz˛eść komercyjnych systemów zarzadzania
˛
siecia˛ oferowanych dotychczas
do współpracy z Windows, jest dostosowywana przez producentów do pracy w środowisku
GNU/Linux.
◦ Rozwiazaniami
˛
mogacymi
˛
zastapić
˛ MS Exchange jest przede wszystkim wolne oprogramowanie, wykorzystywane zwłaszcza do zastapienia
˛
samych serwerów pocztowych. Takim pełnowartościowym substytutem dajacym
˛
możliwość dalszego korzystania z klienta
poczty Outlook jest obecnie, Samsung Contact - dla średnich i dużych sieci, a dla mniejszych sieci może nim być Exchange4Linux.
◦ Jeśli chodzi o bazy danych, to można wybierać spoś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 już sobie bardzo dobra˛ opini˛e odnośnie działania w środowisku
Unix/Linux i dlatego nie b˛eda˛ przez nas oceniane.
Powyższa˛ list˛e można by rozszerzyć na niemal wszystkie dziedziny zastosowań sieciowych i
desktopowych. W poradniku opiszemy tylko niektóre z nich, np. systemy wysokiej niezawodności oraz Thin Clients. Tam, gdzie pojawia˛ si˛e ważne różnice albo ograniczenia zwiazane
˛
z
prezentowanymi rozwiazaniami,
˛
zostana˛ one wyjaśnione.
1.4.5 Istotne zagadnienia przyszłościowe
Aby zamieszczona tu ocena techniczna nie była pozbawiona perspektywicznego spojrzenia,
przedstawiony punkt wyjścia oceniany b˛edzie za każdym razem pod katem
˛
przyszłościowego
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˛eściami składowymi, tj. Web-Services i XML, a także SharePoint Portal Server.
Podsumowujac
˛ można sformułować nast˛epujace
˛ wnioski:
◦ Zarówno .NET-Framework, jak i alternatywna do niego Java/J2EE oferuja˛ zasadniczo dwie
funkcjonalności, tj. umożliwiaja˛ ponowne zastosowanie używanych składników oraz realizuja˛ kompatybilność pomi˛edzy platformami i oprogramowaniem.
◦ Możliwość ponownego wykorzystania używanych składników, uzyskana wskutek wykorzystania ich jednakowego modelu (COM+ w przypadku Microsoft oraz JavaBeans w Javie), określana jest mianem integracji gł˛ebokiej wskutek ich powiazania
˛
ze środowiskiem
runtime environment (udost˛epnianie uniwersalnych funkcji) i/lub powiazania
˛
z j˛ezykami
programowania. Aplikacje stworzone w oparciu o jeden model składników można wykorzystywać tylko wewnatrz
˛ jednej platformy.
◦ XML, jako format wymiany danych i dokumentów, tworzy podstaw˛e w zastosowaniach
opartych na technologii Web-Services. Dzi˛eki niezależności od konkretnego środowiska
oraz wykorzystywaniu interfejsów dla różnych protokołów, można ja˛ zastosować do płytkiej integracji usług. Usługi oparte na Web-Services moga˛ wykraczać poza granice wyznaczane przez platform˛e, na której sa˛ uruchamiane.
◦ Obecnie nie można sformułować generalnego zalecenia dotyczacego
˛
wykorzystania ponad
platformowego płytkiego modelu integracji. Jest tak ze wzgl˛edu na nierozstrzygni˛ete kwestie bezpieczeństwa oferowanego przez aplikacje pracujace
˛ w ramach technologii WebServices. Ocena bezpieczeń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 niezależności sprz˛etowej, wskazuje si˛e na konieczność wykorzystania JSE/J2EE.
Odejście od tej zalecanej technologii (np. w kierunku .NET-Framework) dopuszczalne
jest tylko w uzasadnionych przypadkach (np. gdy możliwe jest poczynienie znacznych
oszcz˛edności).
◦ Przewiduje si˛e, że wykorzystanie XML jako formatu dokumentów, który w zaleceniach
SAGA uznany został za „uniwersalny i naczelny standard wymiany danych dla wszystkich
26
ważnych systemów informatycznych administrujacych
˛
danymi”, jak również wytyczna
SAGA odnośnie PDF, jako formatu wymiany dokumentów, doprowadzi do znacznego poprawienia (jeśli nie do całkowitego zlikwidowania problemu) kompatybilności oprogramowania biurowego poczawszy
˛
od MS Office 2003.
1.4.6 Korzyści ekonomiczne
Główna ocena korzyści ekonomicznych przedstawiona w poradniku koncentruje si˛e wokół dwóch
istotnych zagadnień:
◦ przedstawienia podstawowych wypowiedzi dotyczacych
˛
opłacalności stosowania produktów Open Source
oraz
◦ określenia metod i środków pozwalajacych
˛
na dokonanie oceny wydajności ekonomicznej
pod katem
˛
specyficznych potrzeb urz˛edów oraz oszacowania kosztów migracji zwiazanych
˛
z konkretnymi projektami.
Analiza kosztów migracji oraz właściwe, dla przedłożonych projektów migracji, dokumenty
WiBe 21,3 wskazuja˛ na dwie metody obliczania rentowności procesu wymiany oprogramowania. Aby umożliwić łatwiejsze ich zrozumienie, poradnik zawiera przykładowe wyliczenia dla
różnych scenariuszy wraz z komentarzami. W celu podkreślenia szczególnych różnic wynikajacych
˛
z róż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 przydatności.
Poradnik daje tym samym możliwość przypisania wymiaru ekonomicznego każdemu projektowi. Podaje on liczby pomocne przy określaniu rentowności oraz pilności wdrożenia projektu
badź
˛ też wskazuje na jego strategiczne znaczenie. Także analiza kosztów migracji oferuje szybka˛
i pragmatyczna˛ pomoc dla przygotowania oceny wydajności ekonomicznej.
Na zakończenie należy wyraźnie podkreślić, że zwłaszcza wyniki oceny ekonomicznej pokazały, iż głównym czynnikiem wpływajacym
˛
na podj˛ecie decyzji za lub przeciw migracji zast˛epujacej
˛ b˛edzie stopień integracji z systemem Windows i pakietem MS Office. Decydujace
˛ argumenty ekonomiczne oraz możliwości zastosowania migracji zast˛epujacej
˛ zależa˛ ściśle od ilości
3
IT-WiBe 21 – zalecenia odnoś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.
27
używanych aplikacji biurowych, zakresu i stopnia skomplikowania stosowanych makr, skryptów oraz szablonów, jak również od ilości i dost˛epności kodu źródłowego wykorzystywanych
aplikacji specjalistycznych współpracujacych
˛
wyłacznie
˛
z Windows. Właśnie takiej sytuacji poświ˛econe sa˛ zalecenia dotyczace
˛ stopniowego zmniejszania uzależnienia od jednego systemu
operacyjnego i podnoszenia kompatybilności wykorzystywanego oprogramowania.
Rozdział 2
Najważniejsze zagadnienia
2.1 Ważne definicje
Na co dzień używanych jest wiele poj˛eć, które mimo pozornego podobieństwa, wcale nie sa˛ tożsame. W niniejszym poradniku sa˛ to mi˛edzy innymi: Oprogramowanie Open Source, Otwarte
Oprogramowanie lub Free Software, oprogramowanie własnościowe, oprogramowanie komercyjne i inne. Ponadto w poradniku wprowadzono własne poj˛ecia.
Aby lektura poradnika nie prowadziła do powstawania nieporozumień, niektóre z w/w poj˛eć
zostały wytłumaczone poniżej.
2.1.1 Open Source, Free Software
Poj˛ecia „Open Source Software” i „Free Software” nazywane także „Otwartym Oprogramowaniem” stosowane sa˛ w poradniku jako synonimy. Dla uproszczenia oznaczono je skrótem OSS.
OSS pozwala każdemu czytać i dowolnie modyfikować kod źródłowy. Otwartość ta daje
użytkownikom możliwość 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˛ ponosić kosztów zwiazanych
˛
z zakupem licencji. Programy OSS
wolno kopiować w zmodyfikowanej formie oraz rozpowszechniać. Wolność oprogramowania
reguluja˛ i gwarantuja˛ odpowiednie licencje. Najważniejsze z nich zostały opisane w rozdziale
2.4.
OSS nie wolno mylić z oprogramowaniem, które wprawdzie udost˛epniane jest za darmo,
ale nie może być przez użytkownika modyfikowane ani dostosowywane do własnych potrzeb,
wzgl˛ednie takim oprogramowaniem, którego licencja zakazuje stosowania go do celów komer28
ROZDZIAŁ 2. NAJWAŻNIEJSZE ZAGADNIENIA
29
cyjnych.
2.1.2 Oprogramowanie własnościowe
Oprogramowanie własnościowe nie jest oprogramowaniem OSS. Należy ono do osoby lub organizacji. Z reguły chodzi w tym przypadku o producenta takiego oprogramowania (prawo
własności). Sposób korzystania z oprogramowania podlega zapisom licencji, które ustalane sa˛
przez właściciela oprogramowania. Najcz˛eściej zakazuja˛ one nieograniczonego powielania, rozpowszechniania i modyfikowania.
W pewnych przypadkach, gdy spełnione zostana˛ odpowiednie wymagania zapisane w licencji, oprogramowanie takie jest także udost˛epniane za darmo.
2.1.3 Komercyjne oprogramowanie linuksowe
Komercyjne oprogramowanie linuksowe (Commercial Linux Software) obejmuje grup˛e oprogramowania własnościowego, które może być stosowane w systemie operacyjnym GNU/Linux.
Z reguły odznacza si˛e ono wykorzystywaniem obowiazuj
˛ acych
˛
standardów i wynikajac
˛ a˛ z nich
kompatybilnościa,
˛ jak również dobrze zdefiniowanymi interfejsami.
˛
W niniejszym poradniku wyróżnione zostały dwa główne modele migracji: zast˛epujaca
˛ i kontynuacyjna. Na czym polegaja˛ różnice pomi˛edzy nimi?
Mianem migracji zast˛epujacej
˛ określa si˛e zastapienie
˛
aplikacji pracujacych
˛
pod Windows
oraz usług świadczonych przez ten system operacyjny wraz ze wszystkimi bazujacymi
˛
na nim
środowiskami przez oprogramowanie OSS lub komercyjne oprogramowanie linuksowe. Poniżej
kilka typowych przykładów:
◦ zastapienie
˛
Windows NT przez GNU/Linux
◦ zastapienie
˛
MS Office przez OpenOffice.org
◦ zastapienie
˛
MS SQL Server przez Oracle
30
2.1.5 Migracja kontynuacyjna
Poj˛ecie migracji kontynuacyjnej oznacza dalsze wykorzystywanie oprogramowania Microsoft
majace
˛ na celu osiagni˛
˛ ecie odpowiedniego stopnia kompatybilności przed zmiana˛ oprogramowania na OSS. W ramach tego typu migracji mieści si˛e, na przykład, zastapienie
˛
Windows NT 4
przez Windows 2000, Windows XP albo Windows 2003. Poniż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 najbliższych latach. Konieczność dokonania takiego
wyboru może pojawić si˛e z różnych powodów:
◦ wygaśni˛ecie wsparcia dostarczanego przez producenta różnych istotnych produktów
◦ rosnace
˛ wymagania techniczne
◦ konsolidacja już stosowanych systemów i aplikacji
◦ różne cele strategiczne, np. uniezależnienie si˛e od producenta oprogramowania oraz zwi˛ekszenie kompatybilności
Osoby odpowiedzialne za prawidłowe działanie oprogramowania w urz˛edach i organizacjach
musza˛ odpowiedzieć na pytanie dotyczace
˛ utworzenia właś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 należy wziać
˛ pod uwag˛e migracj˛e mieszana,˛ gdyż nie można z góry zakładać,
że dla wszystkich składników tworzacych
˛
punkt wyjścia dla migracji, znajda˛ si˛e odpowiedniki
OSS i COLS. Jest tak zarówno z przyczyn technicznych, jak i ekonomicznych.
31
Nie było możliwe umieszczenie w ramach poradnika wszystkich spostrzeżeń zwiazanych
˛
z
poruszonymi powyżej zagadnieniami. Przyczyna˛ tego jest zarówno rozległość systemów, które
należałoby poddać odpowiedniej ocenie, jak też każ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˛ekszość urz˛edów i w ten sposób pomaga
podjać
˛ decyzj˛e.
2.2.1 Punkt wyjścia - Microsoft Windows
Rysunek 2.1 przedstawia system Microsoft i składniki znajdujace
˛ si˛e w jego otoczeniu. Taka
badź
˛ podobna struktura wykorzystywana jest w wielu urz˛edach i organizacjach. Poniższy rysunek odwzorowuje usługi wraz z modułami - programami, które sa˛ cz˛eścia˛ składowa˛ sytuacji
przed migracja,˛ b˛edacej
˛ punktem wyjścia dla naszej oceny. Na poczatku
˛
rozdziału 3 opisana
została techniczna ocena każdego ze składników systemu uwzgl˛edniajaca
˛ ich funkcje i szczególne właściwoś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 należy wybrać.
32
Rysunek 2.1: Składniki systemu - punkt wyjścia
Podczas tworzenia niniejszego poradnika konieczne było przyjmowanie w różnych miejscach
założeń dotyczacych
˛
wielorakiej infrastruktury informatycznej. O ile w ramach przedstawianych
tu ocen technicznych i ekonomicznych nie określimy inaczej, obowiazuj
˛ a˛ nast˛epujace
˛ założenia.
Serwery
Założyliśmy, że punkt wyjścia dla migracji w urz˛edach opiera si˛e na jednym z dwóch powszechnych modelów domen NT.
◦ Środowisko NT z domena,˛ w której odbywa si˛e zarzadzanie
˛
kontami użytkowników i kontami komputerów.
◦ Środowisko NT z account domain, która zawiera konta użytkowników oraz wiele resource
domains, które zarzadzaj
˛
a˛ kontami komputerów i ufaja˛ account domain.
W środowisku tym, na bazie Windows NT 4 Server, udost˛epniane sa˛ różne usługi infrastrukturalne oraz aplikacje i składniki integrujace.
˛
Poniż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 duże rozpowszechnienie w administracji publicznej różnych serwerów, w poradniku skoncentrowaliś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˛ekszości aplikacji bazodanowych.
33
Do połaczenia
˛
i integracji różnych usług i aplikacji pod Windows dochodziło dotychczas z reguły
na gruncie
◦ Component Object Model (COM)
oraz
◦ należacej
˛ do niego usługi Distributed COM (DCOM).
Udost˛epnienie Windows NT 4 Services może być realizowana przez dwie różne wersje systemu
operacyjnego:
◦ Windows NT 4 Server
◦ Windows NT 4 Server Enterprise Edition.
Drugi z wymienionych serwerów (Enterprise Edition) umożliwia realizacj˛e usług przez dwa w˛ezły (serwery) w jednym klastrze.
Klienty i aplikacje
Jeśli chodzi o oprogramowanie działajace
˛ po stronie użytkownika, należy założyć, ż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. Najważniejszym oprogramowaniem
pracujacym
˛
na bazie w/w systemów jest Microsoft Office Suite. Dlatego oceniona zostanie zarówno wersja 97, jak i bieżaca
˛ wersja 2000 tego oprogramowania. Użytkownicy używaja˛ ich
podczas wykonywania swoich codziennych zadań. Dlatego udost˛epnia si˛e im z reguły edytory
tekstu, arkusze kalkulacyjne, arkusze prezentacji oraz możliwość korzystania z komunikatorów
sieciowych badź
˛ oprogramowania Groupware umożliwiajacego
˛
prac˛e grupowa.
˛
Oprócz standardowego oprogramowania biurowego, używane sa˛ także różnorodne specjalistyczne aplikacje pracujace
˛ pod w/w systemami operacyjnymi. Służa˛ one do wykonywania zadań
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. Ponieważ zmiany
podstawowej infrastruktury informatycznej, moga˛ naruszyć podstawy działania tego typu aplikacji, wymagane jest, w zależności od ich ilości i stopnia skomplikowania, opracowanie odpowiednich rozwiazań
˛
przejściowych. W poradniku przedstawione zostały wybrane propozycje i
zalecenia dotyczace
˛ właściwego sposobu post˛epowania w takiej sytuacji.
34
Na końcu opisaliśmy jeszcze cały szereg innych standardowych aplikacji i narz˛edzi (np.
menedżerów plików, także programów służacych
˛
do kompresji danych), które udost˛epniane sa˛
użytkownikom podczas wykonywania przez nich codziennych prac. Programy te b˛eda˛ im także
potrzebne już 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˛ najważniejsze systemy i aplikacje, które można wykorzystać do przeprowadzenia
migracji zast˛epujacej.
˛
W ostatniej dekadzie wielu producentów oprogramowania zdecydowało si˛e na napisanie badź
˛
przystosowanie (przeportowanie) swoich produktów w taki sposób, by współpracowały one z
Linuksem. Oprócz wielkich firm z branży informatycznej, takich jak IBM, SUN czy Oracle,
można w tym miejscu wspomnieć także o licznych mniejszych przedsi˛ebiorstwach zajmujacych
˛
si˛e dostarczaniem specjalistycznych rozwiazań
˛
informatycznych. Produkty te sa˛ na tyle znane z
rynku oprogramowania komercyjnego, że nie wymagaja˛ bliższego omówienia. Poradnik koncentruje si˛e przede wszystkim na cz˛eściowo mniej znanych rozwiazaniach
˛
Open Source oraz takich,
które dopiero od niedawna można wykorzystać dla przeprowadzenia migracji zast˛epujacej
˛ w
krytycznych obszarach.
Rysunek 2.2 wyraźnie wskazuje konkretne obszary zastosowań, gdzie tego typu rozwiaza˛
nia sa˛ dost˛epne jako coś wi˛ecej niż tylko alternatywa. Dlatego oceny techniczne wysuwaja˛ na
pierwszy plan klasyczne rozwiazania
˛
oparte na oprogramowaniu Open Source. Tam, gdzie nie
ma jeszcze odpowiednich aplikacji OSS, oceniono rozwiazania
˛
wywodzace
˛ si˛e z grupy alternatywnego oprogramowania własnościowego pracujacego
˛
pod GNU/Linux i opartego jednocześnie
na otwartych standardach.
35
Rysunek 2.2: Składniki systemu - migracja zast˛epujaca
˛
2.2.3 Przeglad
˛ systemu dla migracji kontynuacyjnej
W przypadku migracji kontynuacyjnej najważ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 należy wykorzystać produkty z serii 2000. Odpowiednie zależności zostały przedstawione na rysunku .
W rozdziale 3 przedstawione zostały charakterystyczne szczegóły techniczne oraz założenia
konieczne do przeprowadzenia migracji, jak również wymagane dla uruchomienia poszczególnych usług i serwerów środki techniczne. Punktem wyjścia dla poniższego opisu jest Windows
2000 Server.
Nast˛epnie przeanalizowane i ocenione zostały skutki zmian technicznych i pozostałe nowości.
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 także zmiany zachodzace
˛ na desktopach. Różnica polega na tym, że tym razem w
centrum uwagi znajduje si˛e Office XP.
Ostatecznie tam, gdzie pozwalaja˛ na to dost˛epne informacje, oceniono również serwery i
pakiety biurowe wywodzace
˛ si˛e z serii 2003.
2.2.4 Wewn˛etrzne zależności systemu opartego o rozwiazania
˛
firmy Microsoft
Architektury systemu, które w wi˛ekszości bazuja˛ na produktach Microsoft, wykazuja˛ różnie silne
wewn˛etrzne zależności. W nast˛epujacym
˛
rozdziale przedstawione zostały niektóre z takich wewn˛etrznych zależności wyst˛epujacych
˛
w strukturze opartej na produktach Microsoft.
Oczywista zależność polega na tym, że aplikacje firmy Microsoft daja˛ si˛e zainstalować i
używać tylko w tym jednym systemie operacyjnym. Dotyczy to serwerów, jako tak zwanych
produktów Back-Office (czyli MS SQL Server, MS Exchange itd.), jak również, poza nielicznymi wyjatkami
˛
(Office 98 dla MacOS, Internet Explorer 4 dla Uniksa), aplikacji desktopowych
(np. MS Office) i oprogramowania klienckiego (np. klienty MS SQL).
37
Mówiac
˛ ogólnie, w celu zarzadzania
˛
kontami użytkowników i ich autoryzacji oraz weryfikacji praw dost˛epu do zasobów, serwery wymagaja˛ administrowania. Microsoft oferuje różne
sposoby administrowania w zależności od wykorzystywanej bazy danych użytkowników. Zostały one wymienione poniżej na przykładzie serwera MS SQL Server.
◦ wariant A:
administrowanie kontami użytkowników specyficzne dla SQL.
◦ wariant B:
Administrowanie w oparciu o lokalna˛ baz˛e danych użytkowników systemu operacyjnego,
w którym pracuje serwer.
◦ wariant C:
Administrowanie w oparciu o baz˛e danych uż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 umożliwia użytkownikowi pracujacemu
˛
w czystym środowisku
Microsoft autoryzacj˛e Single Sign On.
◦ wariant D:
Wariant, w którym można korzystać ze sposobów autoryzacji dostarczanych przez innych
producentów, nie jest oferowany.
Poczawszy
˛
od Windows 2000 Microsoft przeniósł zarzadzanie
˛
kontami i autoryzacj˛e użytkowników do usług katalogowych (patrz poniżej) oraz otwartych standardów, takich jak Kerberos i
LDAP, jednak bez dopuszczenia obcych rozwiazań.
˛
W świecie Windows NT 4.0 można zauważyć jeszcze inne zależności zwiazane
˛
z administrowaniem kontami użytkowników. Na przykład niemożliwe jest korzystanie z Microsoft Exchange
(wersja 4 do 5.5) bez struktury domen Windows NT. Innym przykładem pokazujacym
˛
konieczność korzystania z domen NT jest działanie Cluster Services. To samo dotyczy stworzonej przez
Microsoft architektury DCOM (Distributed Component Object Model), której architektura bezpieczeństwa zakłada, że klient i serwer należa˛ do tej samej struktury domen. DCOM używany
jest przez duża˛ ilość 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łaściwości.
Zachowano je ze wzgl˛edu na konieczność podtrzymania kompatybilności ze starszymi aplikacjami. Dlatego, np. wprowadzenie mechanizmu autoryzacji Kerberos nie oznacza likwidacji me-
38
chanizmu NTLM (NT LAN Manager). Także czyste środowiska Windows 2000 nadal używaja˛
NTLM w niektórych miejscach (np. klastry). Równocześnie Active Directory wyposażony został w nowe możliwości, których albo nie było w świecie Windows badź
˛ były wykorzystywane
raczej oddzielnie. Z uwagi na funkcjonalność wytycznych grup, ich cz˛eści były już znane w
Windows NT jako wytyczne systemu, Internet Explorer Administration Kit (IEAK) albo Security Configuration Editor (SCM). W przeciwieństwie do tego, w wytycznych grup zastosowane
zostały nowe funkcjonalności, takie jak wymiana oprogramowania, połaczenie
˛
z jednostkami
organizacyjnymi, domenami i stanowiskami lub skryptami logowania i wylogowania.
Całkowita˛ nowościa˛ w Windows 2000 Active Directory jest integracja takich technologii
szyfrowania, jak IPsec albo EFS (Encrypted File System). Aby móc ich używać, trzeba zbudować infrastruktur˛e kluczy publicznych PKI (Public Key Infrastruktur) zintegrowana˛ z Active
Directory. Microsoft rozszerzył także protokół Kerberos. Ma to umożliwić 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˛ odpowiadać właściwoś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 przeciwieństwie do Exchange 5.5., Exchange 2000 nie jest już
wyposażony we własne usługi katalogowe. Wszystkie informacje użytkowników poczty elektronicznej wraz z listami adresowymi Exchange 2000 znajduja˛ si˛e w Active Directory, który trzeba
przygotować 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
˛ zapytań ustalajacych
˛
granice domen. Z Global Catalog korzysta także,
np. Outlook 2000.
Exchange 2000 wykorzystuje Active Directory nie tylko w trybie odczytu, lecz również do
zapisu. Dlatego Recipient Update Service z Exchange 2000 może zapisywać swoje wyniki do
Active Directory. Narz˛edzia do zarzadzania
˛
kontami pocztowymi użytkowników sa˛ całkowicie
zintegrowane z konsola˛ zarzadzaj
˛
ac
˛ a˛ „Active Directory - Users and Computers”.
Powyższe zwiazki
˛ i zależnoś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 pytań
zwiazanych
˛
z potencjalnym skorzystaniem z rozwiazań
˛
alternatywnych:
◦ W jaki sposób porzucić określona˛ lini˛e produktów oraz przypisane do niej cykle aktualizacji?
39
◦ Jak można zminimalizować uzależnienie od jednej linii produktów i zwiazanego
˛
z nia˛
wyposażenia technicznego?
◦ Jakie środki prowadza˛ do zredukowania uzależnienia od producenta i do zróżnicowania
systemów oprogramowania?
◦ Czy dla określonych składników oprogramowania istnieje wystarczajaco
˛ dużo konkurencyjnych cenowo substytutów?
Z uwagi na osiagni˛
˛ ety w tzw. mi˛edzyczasie stopień zależności pomi˛edzy produktami, odpowiedzi na zadane powyżej pytania można udzielić 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łożonego z serwerów i klientów można skorzystać z rozwiazań
˛ oferowanych w ramach różnych dystrybucji Linuksa. Oprócz systemu operacyjnego GNU/Linux zawieraja˛ one bardzo wiele pakietów z różnorodnym oprogramowaniem. Nie chodzi tu wyłacznie
˛
o
oprogramowanie używane na desktopach, które z reguły udost˛epniane jest w wielu odmianach,
lecz także, o serwery WWW, systemy zarzadzania
˛
bazami danych, serwery pocztowe, firewalls,
serwery pośredniczace,
˛ serwery usług katalogowych i dużo wi˛ecej.
Poniżej pokrótce przedstawione zostana˛ wybrane dystrybucje oraz ich charakterystyczne cechy.
Dystrybucje tworzone i oferowane sa˛ przez najróżniejszych producentów i programistów.
Pierwotnie dystrybucje były tworzone i rozwijane z reguły po to, by ułatwić użytkownikom proces instalacji systemu operacyjnego (kernel) i wybranych programów. Firmy zajmujace
˛ si˛e tworzeniem dystrybucji opracowały cały szereg różnych narz˛edzi administracyjnych ułatwiajacych
˛
obsług˛e systemu operacyjnego oraz współpracujacego
˛
z nim oprogramowania, którego cz˛eść,
podobnie jak sam system, udost˛epniana jest w oparciu o licencje wolnego oprogramowania.
Jeśli klient kupuje dystrybucj˛e, wówczas nie płaci on za system GNU/Linux, lecz za możliwość 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 użytkownika, gdyż sam
40
system operacyjny nie dostarcza własnych rozwiazań
˛
tego typu. Wskutek tego system pozostaje
otwarty na realizacj˛e różnych pomysłów zarzadzania
˛
nim.
Wraz z kupnem dystrybucji klient otrzymuje na ogół oprócz nośników (obecnie jest to kilka
płyt CD) kompletna˛ dokumentacj˛e techniczna.˛ W zależności od producenta dystrybucji różni
si˛e ona w swojej obj˛etości i jakoś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 także kod źródłowy takich programów oraz samego systemu operacyjnego. Dzi˛eki temu użytkownik jest w stanie, gdy pojawia˛ si˛e
jakiekolwiek problemy, samodzielnie ponownie skompilować dowolny program po uprzednim
dostosowaniu go do własnych potrzeb.
Opisywane tu dystrybucje można kupić w postaci gotowego zestawu (CD, dokumentacja)
albo nieodpłatnie pobrać z Internetu. W przypadku kupna klient może na ogół korzystać ze
wsparcia technicznego zapewnianego przez producenta dystrybucji. Jeśli dystrybucja została pobrana z sieci, wówczas nie można na to liczyć. W przypadku trzech opisanych poniżej dystrybucji, dwie tworzone sa˛ przez producentów, a jedna jest zbiorowa˛ praca˛ społeczności programistów
ja˛ rozwijajacych
˛
oraz innych osób pomagajacych
˛
w jej tworzeniu i testowaniu.
W przyszłości ważna rola przypadnie kompatybilności wersji Linuksa i ujednoliceniu poszczególnych dystrybucji. Aby uniknać
˛ powstawania zbyt dużych róż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 powyższego standardu. Ponadto
File System Hierarchy Standard jest, jako ważna cz˛eść składowa wysiłków na rzecz kompatybilności, standardem Linux Standard Base (LSB)2. Celem Linux Standard Base jest definiowanie
standardów prowadzacych
˛
do uzyskania możliwie szerokiej kompatybilności wszystkich dystrybucji i zapobiegajacych
˛
powstawaniu rozbieżnoś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łości możliwa stanie si˛e wymiana oprogramowania bez wzgl˛edu na dystrybucj˛e z której
pochodza.˛
Oprócz LSB, w kontekście podejmowanych działań na rzecz standaryzacji, trzeba wymienić
1
2
http://www.pathname.com/fhs/
http://www.linuxbase.org
41
Free Standard Group3. Tworza˛ ja˛ LSB, Open18N4 (niegdyś Linux Internationalization Initiative
Li18nux) i LANANA (The Linux Assigned Names and Numbers Authority). LANANA administruje nazwami stosowanymi w ramach oprogramowania linuksowego, co ma na celu unikni˛ecie konfliktów pomi˛edzy róż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łeczności programistów Open Source. Wszyscy producenci dystrybucji przedstawionych w poradniku
sa˛ reprezentowani w FSG. Z lista˛ dystrybucji certyfikowanych przez LSB można zapoznać si˛e w
Internecie5.
Przy wybieraniu dystrybucji waż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 może być istnienie kontraktów ramowych albo oferta
zawierajaca
˛ aplikacje, które zostały specjalnie przystosowanych do potrzeb urz˛edu.
Dystrybucje przedstawione poniżej zostały wybrane ze wzgl˛edu na wysoki stopień ich rozpowszechnienia (patrz takż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 ś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, że może być ona bez ograniczeń kopiowana i używana
w celach komercyjnych.
Debiana można ściagn
˛ ać
˛ za darmo z Internetu, jak i kupić. Dystrybucja ta nie jest zaliczana
do produktów komercyjnych, dlatego przy zakupie płyt CD z Debianem płacimy za koszty transportu oraz wyprodukowania nośników. Dystrybucja nie jest rozprowadzana w postaci pudełkowej, co odróżnia ja˛ od niektórych komercyjnych produktów.
Rzecza˛ charakterystyczna˛ dla Debiana jest sposób usuwania bł˛edów przez opiekunów dystrybucji. Za poś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łaś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
42
mechanizmowi zapewnienia bezpieczeństwa Debian zaliczany jest do najstabilniejszych, obarczonych najmniejsza˛ ilościa˛ bł˛edów dystrybucji. Projekt odznacza si˛e długim cyklem wydawania kolejnych wersji, co gwarantuje tej dystrybucji wysoka˛ jakość. W ten sposób nie dochodzi
do wypuszczania na rynek „niedopracowanych” wersji.
Jedna˛ z istotnych właściwości Debiana jest własny format pakietów oraz odpowiednie narz˛edzia służace
˛ do zarzadzania
˛
nim. Ma to t˛e istotna˛ zalet˛e, że daje możliwość łatwego aktualizowania zarzadzanego
˛
sytemu, jak i pojedynczych programów, bez konieczności instalowania
oprogramowania od poczatku.
˛
System zarzadzania
˛
pakietami służy jednocześnie do wykonywania regularnych aktualizacji systemów polegajacych
˛
na uaktualnieniach w zakresie stabilności i
bezpieczeństwa.
Wszelka pomoc zwiazana
˛
z obsługa˛ sytemu i jego rozwojem zapewniona jest poprzez szereg
list dyskusyjnych6 . Jeśli takie źródło informacji okaże si˛e być niewystarczajace,
˛ zawsze można
skorzystać 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łalnoś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óżniejszych obszarach IT. Poniższa tabela przedstawia najważniejsze właściwości różnych dystrybucji.
P RODUKTY
P RZEZNACZENIE
W pierwszym rz˛edzie zalecana przez producenta do zastosowań
desktopowych. Dystrybucje zawieraja˛ duża˛ ilość pakietów wraz
Personell - Professional
z odpowiednimi narz˛edziami potrzebnymi do ich instalacji. W
wersji Professional na płytach CD zamieszczone zostały również
liczne programy przeznaczone na serwery, które można wykorzystywać w przedsi˛ebiorstwach.
6
7
http://www.debian.org/support
http://www.slackware.org
43
SuSE Linux Server przeznaczone sa˛ dla wszelkich zastosowań informatycznych. Dost˛epne sa˛ one na wszystkie ważne platformy
Enterprise
sprz˛etowe: procesory 32 oraz 64 bitowe firm AMD i Intel. Obsługuja˛ takż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 amerykańska˛ firm˛e Red Hat systemie
zarzadzania
˛
pakietami RPM. Z jego pomoca˛ programowanie może być instalowane oraz deinstalowane - także przez osoby trzecie - na ogół bez żadnych problemów. Doświadczenie uczy
jednak, że niektóre specyficzne dla poszczególnych dystrybucji pakiety należy instalować zgodnie z metoda˛ preferowana˛ przez ich twórców. Dystrybucje SuSE zawieraja˛ zintegrowany system
służacy
˛ do instalacji i administrowania pakietami o nazwie YaST. Podczas instalacji udost˛epnia
on użytkownikom zarówno tryb tekstowy, jak i graficzny.
Różne wersje SuSE przedstawione w powyższej tabeli różnia˛ si˛e mi˛edzy soba˛ przede wszystkim zalecanym obszarem zastosowań, zwiazanymi
˛
z tym możliwościami korzystania z pomocy
technicznej oraz sposobami licencjonowania, a także cena.˛
Dla zastosowań w obszarze przedsi˛ebiorstw, ze wzgl˛edu na dost˛epność oraz skalowalność,
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óżnia˛ si˛e od siebie dost˛epnościa˛ pomocy technicznej. W zależności
od indywidualnych potrzeb klienta możliwe jest, np. uzyskanie pomocy 24x7, indywidualnych
Service Level Agreements i certyfikatów.
2.3.4 Red Hat
Inna˛ komercyjna˛ dystrybucja˛ jest Red Hat. Także Red Hat oferuje wiele wersji swojej dystrybucji, które przeznaczone sa˛ do realizacji różnych zadań (patrz także 2.4). Również w tym przypadku producent zastosował własne narz˛edzia służace
˛ do zarzadzania
˛
pakietami. Pakiety z oprogramowaniem (*.rpm) obsługiwane sa˛ za pomoca˛ systemu Red Hat Package Management, który
umożliwia spójne i komfortowe administrowanie.
P RODUKTY
44
P RZEZNACZENIE
Obie dystrybucje przeznaczone sa˛ przede wszystkim do zastosowań na stacjach roboczych, wzgl˛ednie moga˛ być serwerami w
Red Hat Linux i
Red Hat Linux
małych sieciach. Różnica pomi˛edzy dwoma oferowanymi produktami polega głównie na tym, że charakteryzuje je różny zakres
Professional
dostawy oraz różny czas udzielania pomocy technicznej. Wersja
Professional zawiera wi˛eksza˛ ilość 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óżnych producentów
osprz˛etu i obsługuja,˛ np. systemy klastrowe o wysokiej niezawodności.
Tablica 2.4: Red Hat
Poszczególne produkty różnia˛ si˛e od siebie przede wszystkim zalecanym obszarem zastosowania oraz wynikajacymi
˛
z tego możliwościami uzyskania pomocy technicznej, sposobem
licencjonowania i cena.˛
2.3.5 Certyfikaty
W tym miejscu należy rozróżnić certyfikaty osprz˛etu, oprogramowania oraz certyfikaty umiej˛etnoś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 wydajność oraz zgodność działania testowanych urzadzeń
˛
z ich specyfikacja˛ techniczna.˛ Producenci sprz˛etu maja˛ możliwość certyfikacji
swoich produktów dla każdej dystrybucji. Cz˛esto posiadanie certyfikatu stanowi dla nich, oprócz
gwarancji jakości, także ważny argument marketingowy.
45
Certyfikaty oferuja˛ klientom, szczególnie gdy chodzi o aplikacje i rozwiazania
˛
majace
˛ strategiczne znaczenie, np. systemy ERP z RAID albo SAN, zwi˛ekszona˛ pewność kompatybilności
używanego osprz˛etu i systemu operacyjnego. Dla późniejszych klientów badź
˛ użytkowników
certyfikaty moga˛ być 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˛ także producenci dystrybucji Red
Hat9 . Z reguły procesom tym podlegaja˛ za każdym razem tylko wersje Enterprise dystrybucji
tworzonych przez poszczególnych producentów oprogramowania.
Certyfikacja oprogramowania jest dla wielu klientów podstawowym warunkiem wdrożenia
danego systemu operacyjnego. Wynika to z tego, że kupujac
˛ produkty z certyfikatem, klienci
cz˛esto otrzymuja˛ od producenta oprogramowania, wymagana˛ podczas instalacji i korzystania z
dostarczanych aplikacji, pomoc techniczna.˛
Certyfikaty umiej˛etności
Oprócz certyfikatów wydawanych na osprz˛et i oprogramowanie wymagane sa˛ również certyfikaty świadczace
˛ o poziomie wiedzy specjalistycznej oraz umiej˛etnościach pracowników.
Obecnie istnieja˛ dwa wyróż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/
46
◦ pomaga w procesie rekrutacji
◦ zapewnia standardowy sposób oceny kwalifikacji pracowników
Pracownikom lub potencjalnym przyszłym pracownikom certyfikaty oferuja:
˛
◦ możliwość wykonywania konkretnych zadań
◦ poświadczenie kwalifikacji
◦ zwi˛ekszenie szansy na rynku pracy.
Zasadniczo obydwa programy certyfikacyjne można traktować jako równorz˛edne, przy czym
RHCE ukierunkowany jest bardziej na własna˛ dystrybucj˛e. Przedsi˛ebiorstwo Red Hat zacz˛eło
rozwijać program przyznawania certyfikatów jeszcze w czasach, gdy nie istniały programy certyfikacyjne dla systemów opartych na GNU/Linux. Dopiero później w społeczności Linuksa
rozwina˛ si˛e program LPI. Jest on neutralny jeśli chodzi o dystrybucj˛e i producenta oprogramowania.
2.3.6 Wnioski
Użytkownicy moga˛ dokonywać wyboru spośród licznych dystrybucji oraz różnych ich wersji.
Przy podejmowaniu decyzji ważne jest rozpoznanie i ustalenie koniecznych wymagań. Decyzja o wyborze konkretnej dystrybucji zapaść może tylko w oparciu o każdorazowe oczekiwania
wzgl˛edem dystrybucji badź
˛ producenta oraz tzw. warunki ramowe. Jeśli, np. z braku własnych
zasobów ludzkich, niezb˛edna jest pomoc techniczna producenta, wówczas należy w pierwszej
kolejności zastanowić si˛e nad wyborem dystrybucji komercyjnej. Gdy dla konkretnych zastosowań wymagane jest oprogramowanie certyfikowane, wówczas na ogół pozostaje tylko oferta
firm komercyjnych i wersje Enterprise ich dystrybucji. To, jaki osprz˛et i oprogramowanie rzeczywiście posiada certyfikaty oraz dla jakiej dystrybucji i wersji, należy sprawdzić w każdym
osobnym przypadku.
Dla użytkowników, którzy nie sa˛ skazani na komercyjne wersje dystrybucji, stabilna,˛ dobrze
przetestowana˛ oraz niezawodna˛ dystrybucja˛ na pewno okaże si˛e Debian. Jeśli konieczna tu b˛edzie szeroka pomoc techniczna, także w tym przypadku można zwrócić si˛e o pomoc do licznych,
istniejacych
˛
na rynku, właściwych przedsi˛ebiorstw usługowych.
47
2.4 Licencje
W świecie Linuksa istnieje cały szereg różnych modelów licencji. Najważniejsze z nich zostały
nazwane i krótko scharakteryzowane poniż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˛eść
aplikacji linuksowych udost˛epniane sa˛ na „GPL”, licencji która m. in. gwarantuje udost˛epnianie
kodu źródłowego oraz dowolne korzystanie z programów. Aby oprogramowanie obj˛ete ta˛ licencja˛ także w przyszłości pozostało wolne, w GPL dokładnie zapisano wolności oraz warunki jego
stosowania.
Poszczególne wolności i warunki obejmuja:
˛
◦ paragraf 0:
Wolność wykonywania programu w każdym celu
◦ paragraf 1:
Zezwolenie na kopiowanie oraz rozpowszechnianie dosłownych kopii kodu źródłowego
programu, o ile załaczona
˛
jest do nich treść Copyright i licencja GPL. Wyraźnie zezwala
si˛e takż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˛eści zmienionego programu,
które tworza˛ niezależna˛ całość 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 doń pełny kod źródłowy w postaci nadaja˛
cej si˛e do odczytania przez komputer lub pisemna oferta, (ważna przez co najmniej 3 lata),
gotowości do przekazania go na żadanie.
˛
12
http://www.gnu.org/licenses/translations.pl.html
Oryginał licencji znajduje si˛e na stronie:http://www.gnu.org/copyleft/gpl.html
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 zagadnień, o
których w razie potrzeby można przeczytać.
Dzi˛eki swoim warunkom licencja GPL zapobiega prywatyzacji stworzonego wspólnie oprogramowania i tym samym wyraźnie wspiera ciagłość
˛
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 zbieżna z zamiarami wyrażanymi w GPL.
Także tu musi istnieć dowolność kopiowania, rozpowszechniania i modyfikowania oprogramowania, wzgl˛ednie bibliotek. Oprócz tego kod źródłowy, również ten ze zmodyfikowanych wersji,
musi być udost˛epniany bez ograniczeń.
Różnica w porównaniu z GPL polega przede wszystkim na tym, że programy, które nie sa˛
publikowane na licencji GPL lub podobnej, moga˛ używać wolnych bibliotek rozprowadzanych
na zasadach LGPL i tworzyć odr˛ebna˛ wykonywalna˛ całość. Gdyby w/w biblioteki udost˛epniane
były na licencji GPL, wówczas wykorzystywać by je mogły tylko programy publikowane wyłacznie
˛
na GPL. W przeciwieństwie do tego licencja LGPL zezwala programistom na tworzenie
programów, które nie sa˛ rygorystycznie chronione przez GPL, przy użyciu wolnych bibliotek.
Programy, które używaja˛ bibliotek udost˛epnianych na licencji LGPL, moga˛ być rozpowszechniane na dowolnie wybranych warunkach licencjonowania, jednak z zastrzeżeniem udost˛epnienia klientowi kodu źródłowego bibliotek udost˛epnianych na LGPL, co ma na celu umożliwienie
mu modyfikacji i ponownego uż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 ź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 źródłowego stworzonego na uniwersytecie Berkeley.
14
49
Odpowiednie pliki rozpowszechnianego oprogramowania musza˛ zawierać treść Copyright
oraz licencj˛e BSD.
W przypadku rozpowszechniania oprogramowania w formie binarnej, treść Copyright oraz
zapisy licencji BSD musza˛ być zawarte w dokumentacji oprogramowania lub innej.
Bez posiadania pisemnej zgody nie wolno używać w celach reklamowych ani nazwy uniwersytetu, ani też 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 znajdować
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 już opublikowana w oparciu o nowa˛ licencj˛e. Dlatego mówi si˛e zarówno o starej, jak i nowej licencji BSD.
BSD nie zawiera ograniczeń dotyczacych
˛
użytkowania oraz rozpowszechniania kodu źródłowego badź
˛ programów. Wymagane jest jedynie załaczanie
˛
do oprogramowania treści Copyright,
samej licencji BSD oraz warunków wygaśni˛ecia gwarancji. Licencja nie zmusza do udost˛epniania zmodyfikowanego oprogramowania wraz z kodem źródłowym. Dlatego każda firma programistyczna może wykorzystać w swoim oprogramowaniu kod źródłowy oparty o licencj˛e BSD
bez konieczności udost˛epniania źródeł własnego programu.
Licencja BSD wiaże
˛ si˛e, w porównaniu z wcześniej opisanymi licencjami, ze znacznie mniejszymi restrykcjami.
2.5 Zbieranie informacji o projektach
Wyniki przedstawione w poradniku opieraja˛ si˛e głównie na:
◦ doświadczeniach zdobytych w czasie wdrażania projektów migracyjnych
◦ doświadczeniach zdobytych podczas rozwijania oprogramowania OSS oraz COLS
◦ uwzgl˛ednienia know-how ekspertów
◦ badań nad możliwościami wdrożenia planowanych migracji
◦ szczegółowo opracowanych koncepcjach migracji
◦ literaturze specjalistycznej oraz dokumentacji oprogramowania.
Specjalistyczne informacje ważne dla powstania poradnika zostały zebrane w oparciu o:
50
◦ intensywna˛ analiz˛e dokumentów
◦ wywiady i ich ocen˛e
◦ warsztaty organizowane pod katem
˛
konkretnych zagadnień
oraz
◦ bezpośrednie zaangażowanie licznych ekspertów i producentów oprogramowania.
Treść oraz wnioski wynikajace
˛ z powyższych źródeł informacji zostały w poradniku przedstawione tematycznie, w formie pojedynczych zagadnień. Jednocześnie zostały one przeanalizowane i ocenione.
2.5.1 Doświadczenia z projektów migracyjnych
Wdrażanie i wykorzystywanie OSS jest obecnie na porzadku
˛
dziennym zarówno w administracji
publicznej, jak i w przedsi˛ebiorstwach. Duże zainteresowanie tym zagadnieniem doprowadziło
już do powstania całego szeregu projektów migracyjnych, w których opisywane sa˛ najaktualniejsze doświadczenia i wnioski. Obok czysto technologicznych informacji i doświadczeń, projekty te zawieraja˛ waż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 przygotowań do badań nad sposobami migracji zebrano różne dokumenty, takie
jak dokładne specjalistyczne koncepcje, opisy wydajności oraz całościowe dokumentacje projektów. Taka dokładna analiza stała si˛e także podstawa˛ dla powstania poradników nt. przeprowadzania wywiadów zwiazanych
˛
tematycznie z poszczególnymi obszarami badań prowadzonych
nad projektem.
Gromadzenie informacji polegało, na ogół, na przeprowadzaniu wywiadów w urz˛edach i firmach badź
˛ wywiadów z administratorami, użytkownikami i wdrożeniowcami. Pytania dotyczyły
nast˛epujacych
˛
zagadnień:
◦ sytuacja wyjściowa
◦ strategiczne elementy projektu
◦ motywacja i sposoby wyznaczania celu
◦ krytyczne wyznaczniki sukcesu
51
◦ koszty i korzyści
◦ Lessons Learned
◦ projekty przyszłościowe - rozwój strategii informatycznej
Zostały one uzupełnione szczegółowymi technicznymi pytaniami dotyczacymi
˛
migracji cz˛eściowej, odpowiednio do specyficznych technicznych problemów wyst˛epujacych
˛
przy poszczególnych projektach.
Jeśli chodzi o projekty migracyjne, to przygotowywanie ich możliwe jest m. in. w oparciu o
doświadczenia wynikajace
˛ z projektów pilotażowych zainicjowanych przez Federalny Urzad
˛ ds.
Bezpieczeństwa w Informatyce (BSI) na zlecenie Ministerstwa Spraw Wewn˛etrznych (BMI). W
czasie tworzenia niniejszego poradnika, projekty te były już w poważnym stopniu wdrożone i
zakończone duż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 doświadczenia z przeprowadzonych migracji.
W przypadku wszystkich tych projektów mamy i mieliśmy do czynienia z najróżniejszymi
sytuacjami wyjściowymi. Najcz˛eściej były to systemy oparte o serwery Windows NT 4, które
należało zastapić
˛ i skonsolidować. Jeśli chodzi o serwery, istniały także środowiska mieszane,
składajace
˛ si˛e z Windows NT, Unix i GNU/Linuksa. Po stronie klientów reprezentowane było
różnorodne oprogramowanie ze świata Windows - od Windows 95, aż do Windows XP. W przeważajacej
˛ cz˛eści były to, odpowiednio do obecnego wyposażenia wi˛ekszości urz˛edów, stacje
robocze Windows NT 4.
Także zakres i rodzaj migracji może mieć 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. Możliwe przy
tym było przej˛ecie istniejacych
˛
struktur plików oraz uprawnień bez konieczności wprowadzania
zmian na klientach NT odczuwalnych dla użytkowników. Ponadto w jednym z ocenianych projektów migracyjnych założyliśmy, że migracja ma miejsce wyłacznie
˛
na stacjach roboczych,
które b˛edac
˛ klientami linuksowymi sa˛ zintegrowane z istniejac
˛ a˛ siecia˛ NT4. Ponadto nie mogliśmy nie wspomnieć o migracji polegajacej
˛ z jednej strony na zainstalowaniu oprogramowania
linuksowego na serwerze, a z drugiej strony na zastapieniu
˛
dotychczasowych FAT Clients przez
Thin Clients. Tam, gdzie konieczne było dalsze korzystanie z aplikacji windowsowych (aplikacje
specjalistyczne), dla których na razie nie istnieja˛ wersje linuksowe badź
˛ alternatywne oprogramowanie na Linuksa, opisaliśmy zastosowanie terminali i emulatorów.
52
Patrzac
˛ z technicznego punktu widzenia, mogliśmy korzystać z doświadczeń migracyjnych
zebranych podczas przeprowadzania migracji waż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ównież w systemach heterogenicznych za pomoca˛ Samby)
◦ drukowanie
◦ autoryzacja (wraz z usługami katalogowymi OpenLDAP)
◦ migracja podstawowego oprogramowania biurowego
◦ migracja na serwerach WWW
◦ i inne
Projekty pilotażowe zainicjowane przez BSI zostały wdroż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łaśnie si˛e je
wdraża albo zostały już zrealizowane:
◦ Urzad
˛ Pełnomocnika Rzadu
˛ ds. Ochrony Danych Osobowych (BfD)
◦ Ministerstwo Administracji (BVA)
◦ BSI
Do tego należy jeszcze dodać szereg firm, których projekty z zakresu infrastruktury oraz aplikacji
dostarczaja˛ cennych informacji, szczególnie jeśli chodzi o wdrożenia systemów ERP i DBMS
oraz o wykorzystanie technologii Terminal-Server i platform do zarzadzania
˛
systemem.
53
2.5.2 Opinie ekspertów
Oprócz oceny doświadczeń i wyników otrzymanych z projektów migracyjnych na ostateczna˛
treść poradnika miały także wpływ prace prowadzone przez różnych ekspertów, zarówno przedstawicieli społecznoś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 jakoś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 środowisku składajacym
˛
si˛e z Linuksa i Windows.
◦ Migracja DBMS, dla której punktem wyjścia był MS SQL Server 7, prowadzaca
˛ do wdrożenia wolnej bazy danych badź
˛ systemu bazodanowego pracujacego
˛
pod Linuksem.
◦ Migracja Groupware, dla której punktem wyjścia był Exchange 5.5 z uwzgl˛ednieniem
pracy w ś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.
◦ Wdrożenie usług katalogowych, miedzy innymi wykorzystanie usług katalogowych OpenLDAP, jako oprogramowania Open Source, także w połaczeniu
˛
z Active Directory w systemach heterogenicznych.
◦ Wykorzystanie WiBe21, jako podstawy do oceny opłacalnoś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 środowisk informatycznych przedstawionych na
rysunkach w rozdziale 2. Ocenione zostały:
usługi infrastrukturalne
◦ składowanie plików
◦ drukowanie
◦ autoryzacja
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 możliwościach przejścia od poszczególnych produktów
firmy Microsoft do adekwatnych rozwiazań
˛
OSS lub COLS. W oparciu o przedstawione w rozdziale 2.1 składniki infrastruktury Windows, przeprowadzona została ich dokładna analiza:
Ustalenie sytuacji wyjściowej
◦ Z jakich ważnych funkcji można korzystać?
◦ Jakie interfejsy sa˛ badź
˛ powinny zostać wykorzystane?
◦ Jakie szczególne zachowanie programów zauważono podczas pracy?
Z jakich alternatywnych rozwiaza
˛ ń OSS badź
˛ COLS można korzystać?
◦ Na czym polegaja˛ różnice w działaniu?
◦ Czy spełnione sa˛ krytyczne wymagania?
◦ Jakie interfejsy sa,˛ wzgl˛ednie musza˛ być obsługiwane?
◦ Co należy wziać
˛ pod uwag˛e przy planowaniu migracji, co może stanowić problem i jak
rozwiazywać
˛
problemy?
◦ Czy istnieje wiele alternatywnych rozwiazań?
˛
Dla kogo, ewentualnie w jakim celu korzystać z danego alternatywnego rozwiazania?
˛
◦ Jak można zintegrować alternatywne rozwiazania
˛
z systemami heterogenicznymi. Jeśli jest
to konieczne, jak wyglada
˛ ich współpraca, szczególnie z systemem Microsoft, kompatybilność?
◦ Jaki wpływ na tego typu integracj˛e maja˛ przyszłe kierunki rozwoju oprogramowania Microsoft?
56
Na czym polega potencjał kontynuacyjnego wykorzystywania produktów Microsoft?
◦ Z jakich dodatkowych funkcji można korzystać?
◦ Na czym polegaja˛ najistotniejsze zmiany?
◦ Czy nowości oraz ewentualne modyfikacje spełniaja˛ najważniejsze wymagania?
◦ Czego należy przestrzegać, aby zachować niezależności systemów?
Wszystkie uwagi kończa˛ si˛e z reguły krótka˛ ocena.˛ W przypadku wi˛ekszej ilości alternatywnych
rozwiazań,
˛
jeśli ma to sens, komentowane sa˛ także porównywalne rozwiazania.
˛
3.2 Zarzadzanie
˛
plikami
3.2.1 Przeglad
˛
W wyniku przeprowadzenia szczegółowej technicznej oceny technologii zarzadzania
˛
plikami
można stwierdzić, co nast˛epuje:
W przypadku bezpośredniego zastapienia
˛
serwerów Windows NT przechowujacych
˛
dane,
przy zachowaniu stacji roboczych z Windows, środowisko Open Source ma w pierwszym rz˛edzie do zaoferowania serwer Samba. Jego funkcjonalność podczas obsługi windowsowych stacji
roboczych prezentuje si˛e dość podobnie, jak serwer NT. Dodatkowo Samba jest stale rozwijana
nie tylko przez społeczność Open Source, lecz także przez rosnac
˛ a˛ ilość producentów z branży
informatycznej.
W zależności od zakresu migracji stacji roboczych na Linuksa, w kontekście zarzadzania
˛
plikami można także rozważyć alternatywne technologie takie jak NFS i AFS. Sa˛ one rozpowszechnione w sieciach uniksowych, jednak by umożliwić 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. Jednakże, by móc zastosować klienty NFS albo
AFS w środowisku windowsowych stacji roboczych, trzeba wprowadzić daleko idace,
˛ koncepcyjne zmiany, w porównaniu z sytuacja,˛ gdy zarzadzanie
˛
plikami odbywa si˛e z wykorzystaniem
Windows NT.
Jeśli podczas modernizacji infrastruktury informatycznej tworzonej w ramach projektu migracyjnego ważna˛ rol˛e odgrywa metoda zapewnienia bezpieczeństwa za pomoca˛ Kerberos, która
57
leży także u podstaw Active Directory w Windows 2000, wówczas w przypadku kontynuacyjnego korzystania z produktów Windows po stronie klientów, należy zmierzać w kierunku zastosowania OpenAFS jako alternatywy dla Win2000 jako serwera plików.
Do fizycznego zapisywania danych na systemach dyskowych właś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 umożliwiajace
˛ przyznawanie uprawnień. Podczas odwzorowywania Windows-ACL na POSIX-ACL należy uwzgl˛ednić
to, że straci si˛e dokładność, z jaka˛ można definiować uprawnienia pod Windows. Należy także
sprawdzić, jaki wpływ ograniczenia te maja˛ w pojedynczym przypadku oraz czy można je zaakceptować.
3.2.2 Windows NT 4
3.2.2.1
Wymagania odnośnie funkcjonalności
Generalny zakres funkcjonalnoś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 ograniczeń 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łuży w wi˛ekszości środowisk do realizacji nast˛epujacych
˛
celów:
◦ składowanie plików użytkowników (katalogi domowe)
◦ składowanie profilów opartych na serwerach, jeśli na stacjach klienckich trzeba zoptymalizować obsług˛e mobilnych użytkowników (roaming user)
◦ składowanie plików należacych
˛
do określonych grup (katalogi grup), z których moga˛ korzystać tylko niektórzy użytkownicy (np. z jednego działu)
58
◦ składowanie plików w bazach danych, do których jednoczesny dost˛ep powinno mieć wielu
uż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
˛
możliwość umieszczania danych użytkowych na innym serwerze pod ścieżka˛ UNC.
Opisane tu cele wykorzystania, w praktyce bardzo cz˛esto zwiazane
˛
sa˛ z róż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łaściwości
NTFS4 posiada mi˛edzy innymi nast˛epujace
˛ właściwości:
Każdy katalog i każdy plik dysponuje tak zwana˛ Access Control List (ACL), która jest zapisywana na pliku badź
˛ katalogu. W ACL zapisane sa˛ tak zwane Access Control Entries (ACE),
w którym zapisane sa˛ SID kont grup albo użytkowników oraz ich uprawnienia. Dlatego poprzez
ACL można przydzielać prawa dost˛epu w sposób szczegółowy i zintegrowany. ACL należy podzielić na SACL (System Access Control List) oraz DACL (Discretionary Access Control List).
W DACL składowane sa˛ SIDs grup i użytkowników, którym wolno albo nie wolno mieć dost˛epu
do obiektu. W SACL ustala si˛e, w jaki sposób podsystem bezpieczeń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łać przepisanie ich do ACLi mieszczacych
˛
si˛e w nim plików. Należy zwrócić
uwag˛e na jedna˛ szczególna˛ cech˛e: plik znajdujacy
˛ si˛e na ścieżce UNC \\serwer\zezwolenie-udost˛epnienie\katalo
może być czytany przez użytkownika, mimo że katalog „katalog“ tego zakazuje, jednak katalog
„podkatalog“ na to zezwala.
Nie ma ograniczenia długości ścieżek. Obsługiwane sa˛ nazwy plików składajace
˛ si˛e maksymalnie z 256 znaków. Teoretycznie znaki te moga˛ być zgodne z Unicode (16 bitów), jednak
59
istnieje kilka wyjatków
˛
(np. *, \). Dla każdego katalogu i każ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óżniana jest pisownia wielka˛ i mała˛ litera,˛ o tyle w przypadku
dost˛epu do pliku nie jest to reguła.˛
Każdy katalog i każdy plik dysponuje atrybutami w formie flag (chroniony przed zapisem, archiwalny, systemowy, ukryty i spakowany) oraz czasy: utworzenia, ostatniej zmiany i ostatniego
dost˛epu. Stopień kompresji silnie zależy od zawartości.
NTFS obsługuje technologi˛e Multiple Streams, jednak funkcja ta jest dość rzadko wykorzystywana. Multiple Streams musza˛ być wówczas obsługiwane przez każda˛ aplikacj˛e, wzgl˛ednie
być w niej zaprogramowane. Multiple Streams umoż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 użytkownika i obejmuje cały wolumen (nap˛ed logiczny serwera
plików). Wskutek tych technicznych ograniczeń należy uznać ich zastosowanie w istniejacych
˛
środowiskach raczej za przypadek szczególny niż za reguł˛e.
Maksymalna wielkości plików zarzadzanych
˛
w ramach NTFS4 wynosi 2TB (terabajty). Ponadto jest ona ograniczona wielkościa˛ nap˛edu logicznego. Nap˛ed logiczny może pomieścić maksymalnie 2 TB (teoretycznie 16 exabajtów). Rzeczywista ilość danych netto zależy od wielkości
klastra, który został zastosowany podczas formatowania. Ilość plików ograniczona jest do 2 32 1.
NTFS umożliwia kontrol˛e zrealizowanych dost˛epów, wzgl˛ednie prób dost˛epu. W ten sposób
można, np. zdiagnozować powtarzajace
˛ si˛e, niechciane usuwanie plików.
Nośniki danych sformatowane dla NTFS sa˛ podczas pracy defragmentowane. W Windows
NT4 nie jest wykonywana automatyczna korekta (samoleczenie). Do tego celu należy zastosować produkty innych firm.
System uprawnień w NTFS
Windows zna w sumie 13 uprawnień, które moga˛ zostać przyznane lub odebrane użytkownikowi badź
˛ 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
60
◦ tworzenie plików / zapisywanie danych
◦ tworzenie katalogów / przyłaczanie
˛
danych
◦ przypisywanie atrybutów
◦ przypisywanie rozszerzonych atrybutów
◦ usuwanie podkatalogów / plików
◦ usuwanie
◦ czytanie uprawnień
◦ zmiana uprawnień
◦ przejmowanie uprawnień właściciela
Zmiany w prawach dost˛epu przeprowadzane sa˛ poprzez okno dialogowe Properties i zakładk˛e
Security settings. Aby zmniejszyć dla przeci˛etnego użytkownika stopień skomplikowania systemu bezpieczeństwa złożonego z 13 ściśle spokrewnionych praw dost˛epu, w zakładce tej zdefiniowano gotowe składniki, tak zwane grupy uprawnień, które stanowia˛ podstaw˛e wyboru sensownej kombinacji pojedynczych uprawnień. Dla plików istnieje 5 a dla katalogów sześć takich
zestawów, które każdorazowo można uaktywnić badź
˛ zignorować. Dopiero w oknie dialogowym
Privilege entry, które można wyświetlić w ramach Security settings naciskajac
˛ kolejne przyciski
Extended/Display/Edit, pojawi si˛e wszystkich 13 uprawnień.
W dodatku uzyskanie podgladu
˛ grup uprawnień poprzez Security settings jest bardzo trudne,
gdyż ich prezentacja może bardzo szybko skończyć si˛e komunikatem braku praw dost˛epu, mimo
że w rzeczywistości posiadamy odpowiednie uprawnienia. I tak, np. z pełnego dost˛epu, gdy nie
jest możliwe jedynie przypisywanie rozszerzonych atrybutów, powstaje w prostej prezentacji w
Security settings obraz profilu uprawnień, który zezwala tylko na odczyt i wykonywanie. Poniższa tabela pokazuje, jakie kombinacje uprawnień tworza˛ poszczególne grupy uprawnień. Jeśli
zaledwie jedno uprawnienie z całego przedstawionego poniżej zestawu nie b˛edzie zaznaczone,
wówczas odpowiedni dla konkretnej grupy uprawnień checkbox nie zostanie odhaczony.
W INDOWS
-
GRUPY
UPRAWNIE Ń
Pełny
Zmiana
dost˛ep
61
Odczyt &
Wylisto-
wykony-
wanie
wanie
zawartoś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 uprawnień
X
X
zmiana uprawnień
X
X
X
X
X
Tablica 3.2: Windows - grupy uprawnień
Z powodu opisanej niespójności, w dalszej cz˛eś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
możliwość zarzadzania
˛
tak zwanymi atrybutami oraz rozszerzonymi atrybutami.
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 umożliwia rozległa˛ kontrol˛e nad plikami i katalogami. Dzi˛eki temu można nadzorować
wszystkie uprawnienia pojedynczego użytkownika lub grupy. Otrzymane w ten sposób informacje zapisywane sa˛ w protokole bezpieczeń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
środowisku Windows NT za pomoca˛ dwóch mechanizmów, którymi sa:
˛
◦ odblokowanie dost˛epu do katalogu (share)
oraz
◦ prawa dost˛epu NTFS
Aby mieć dost˛ep do pliku przez sieć, należy otworzyć drog˛e do nadrz˛ednego katalogu. Umożliwia to odpowiedni wpis ACL umieszczony w rejestrze. Prawa dost˛epu do takich zasobów sa˛
stopniowane:
◦ prawo do odczytu
63
◦ prawo do zmian
oraz
◦ pełny dost˛ep
Powyższe uprawnienia sa˛ absolutne, tzn. moga˛ one ograniczać podlegajace
˛ im uprawnienia
NTFS. Przykład: prawo do odczytu na poziomie zasobu uniemożliwia zapisywanie również
wtedy, gdy pozwoliłyby na to uprawnienia NTFS.
W środowiskach Windows NT uprawnieniom (wytycznym dotyczacym
˛
uprawnień użytkownika) należy poświ˛ecić szczególna˛ uwag˛e, ponieważ moga˛ one mieć znaczenie dla File Services,
np. przy „przejmowaniu praw własności do plików i obiektów“ oraz „zabezpieczaniu plików i
katalogów“.
3.2.2.4
Użytkownicy i znaczenie grup
Każdy katalog i każdy plik przyporzadkowany
˛
jest jednemu właścicielowi, którym może być
zarówno grupa, jak i konto użytkownika. W normalnym przypadku użytkownik, który tworzy
dany element, jest jego właścicielem. Jeśli użytkownik należy do grupy administratora, wówczas
ona staje si˛e właścicielem.
Przy ustawianiu praw dost˛epu w środowisku Windows NT systemowo preferowane jest przyznawanie uprawnień grupom. Nadawanie praw kontom poszczególnych użytkowników powinno
odbywać si˛e w ramach systemów plików właściwych dla użytkownika.
Wewnatrz
˛ środowiska Windows NT należy wyróżnić nast˛epujace
˛ grupy:
◦ globalne
◦ lokalne na Member Servers
◦ lokalne na Domain Controllers
Lokalne grupy na kontrolerach domen różnia˛ si˛e od tych na Member Servers, gdyż maja˛ one ten
sam SID na wszystkich kontrolerach domen danej domeny.
Lokalne grupy na Member Servers wolno zagnieżdżać (Group Nesting) z nast˛epujacymi
˛
grupami:
◦ globalnymi grupami własnej domeny
albo
64
◦ globalnymi grupami domen, którym ufa własna domena
Globalne grupy maja˛ konta użytkowników tylko jako członkowie.
W środowisku domen Windows NT znane sa˛ dwa różne „klasyczne“ sposoby ustawiania
praw dost˛epu:
◦ metoda B-G-L-R
Uż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
Uż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
65
Rysunek 3.2: Metoda B-G-R
Obydwie metody funkcjonuja˛ nie zagrażajac
˛ bezpieczeństwu tylko wtedy, gdy przyporzadko˛
wanie zasobów oraz lokalnej badź
˛ globalnej grupy jest jednoznaczne, czyli gdy grupa przypisana
jest wyłacznie
˛
dla danego zasobu.
Jeśli File Services realizowane sa˛ przez klaster, wówczas metoda B-G-L-R ma t˛e wad˛e, że
lokalne grupy na serwerach w˛ezłowych nie moga˛ posiadać identycznego SIDa. Zaradzić temu
moż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 dość ograniczony
wybór narz˛edzi:
◦ działajace
˛ w środowisku graficznym
– NT Explorer (explorer.exe)
– menedżer plików (winfile.exe)
66
◦ działajace
˛ z linii poleceń
– 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 możliwości tworzenia użytkownika (jedynie przej˛ecie użytkownika) ani też kopiowania List Kontroli Dost˛epu (ACLs). Dlatego
należy założyć, że administrowanie środowiskiem NT musi być 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 zadań. Skutkiem tego może być wyświetlanie przez NT Explorer struktury
uprawnień, która b˛edzie różnić si˛e od rzeczywiście nadanych praw dost˛epu.
3.2.2.6
Protokoły sieciowe
Komunikacja poprzez sieć z wykorzystaniem Windows NT File Servers może opierać si˛e na
różnych protokołach sieciowych:
◦ TCP / IP
◦ NetBEUI
◦ SPX / IPX
◦ AppleTalk
Obecność TCP / IP, NetBEUI oraz SPX / IPX w jednym istniejacym
˛
środowisku NT nie jest
nieprawdopodobne. Zasadniczo przyjmuje si˛e, że przyszłościowym i jedynym ważnym protokołem, który należy wspierać jest TCP / IP. Z tego powodu w dalszej cz˛eś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)
można uznać za standardowy sposób komunikacji na portach 137/UDP/TCP (nbname), 138/UDP
(nbdatagram), 139/TCP (nbsession).
3.2.2.7
67
˛
Z reguły uż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 użytkownik ma możliwość „surfowania“ po sieci Windows, tzn. może klikajac
˛ ła˛
czyć si˛e z zasobami, które sa˛ dla niego wyświetlane przez serwer plików za pośrednictwem
nap˛edu sieciowego albo otwierać je bezpośrednio.
3.2.2.8
Migracja - szczegóły robocze
Poniżej zostały wypunktowane szczegóły, które moga˛ być krytycznymi elementami migracji.
◦ Niekiedy z punktu widzenia składowania plików użytkownika (katalogi domowe) wymagane jest, żeby umieszczane tam dane mogły być czytane tylko przez samego użytkownika
oraz system operacyjny (np. w celu ochrony przed wirusami). W Windows NT istnieje
możliwość 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łaściwa˛
struktur˛e uprawnień należy zapewnić szczególnie w środowiskach Terminal Server, które
bezwzgl˛ednie wymagaja˛ profilów opartych na serwerze.
◦ Do plików przypisanych do grup może mieć jednoczesny dost˛ep wielu użytkowników.
Wymagane jest przy tym, aby użytkownik był informowany o współużytkowaniu danych
zasobów. Przykład: użytkownik, który, jako drugi, otwiera plik *.doc (Word), otrzymuje
komunikat, że użytkownik 1 już wcześniej otworzył ten plik, a on może otwierać dany plik
w trybie tylko do odczytu.
◦ Podczas składowania baz danych opartych na plikach, także plikach *.pst (katalogi osobiste w programie Outlook), musi bezbł˛ednie działać funkcja locking.
Cz˛esto nie ma możliwoś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
uprawnień (np. zapisywanie, ale nie usuwanie konkretnego pliku).
◦ Tylko nieliczne aplikacje obsługujace
˛ systemy baz danych (np. MS SQL) oferuja˛ możliwość, składowania danych użytkowych na innym serwerze pod ścieżka˛ UNC, z tym że w
takim przypadku szczególnie ważne jest zapewnienie bezbł˛ednej komunikacji oraz składowania plików, co wymaga zezwolenia / opinii producenta aplikacji.
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łniać w istniejacych
˛
środowiskach jeszcze inne ważne wymagania.
◦ Ochrona przed wirusami: Ochrona przed wirusami realizowana jest najcz˛eściej przez lokalna˛ instalacj˛e skanera antywirusowego na samym serwerze plików. Dzi˛eki usłudze zainstalowanej lokalnie, skanowanie pliku jest możliwe dopiero przy próbie uzyskania dost˛epu
do niego. Z takiego rozwiazania
˛
korzysta wielu producentów oprogramowania antywirusowego. Alternatywna˛ możliwościa˛ jest skanowanie nap˛edów serwera plików poprzez sieć
z innego komputera. Jednak wady takiego rozwiazania
˛
sa˛ oczywiste; przejawiaja˛ si˛e one
w postaci powstajacego
˛
obciażenia
˛
i czasowego opóźnienia.
◦ Kwotowanie: Wbudowane w Windows NT kwotowanie z reguły nie jest wykorzystywane.
Aby zakładać kwoty na zasoby uż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 ważnym kryterium jest czas odtwarzania zasobów podczas Desaster Recovery. Ciekawostka˛ jest fakt, że za pomoca˛ NTBACKUP można zabezpieczać także te dane, które w
innym przypadku nie moga˛ być 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˛ możliwość,
umieszczania rzadko używanych plików na mniej kosztownych systemach / mediach.
˛
3.2.3.1
Wprowadzenie
Biorac
˛ pod uwag˛e kwesti˛e zarzadzania
˛
plikami, w niniejszym poradniku wyszliśmy z założenia,
że centralne miejsce składowania plików znajduje si˛e przynajmniej na jednym serwerze NT i że
obecnie dost˛ep do plików maja˛ klienty windowsowe. Podczas poszukiwań odmiennych dróg dla
69
przeprowadzenia migracji na produkty inne niż firmy Microsoft, trzeba rozróżnić dwa scenariusze owej migracji. Pierwsza opcja dotyczyłaby tylko rozwiazań
˛
stosowanych po stronie serwera,
druga natomiast przypadku, w którym inna˛ platform˛e wprowadza si˛e również na stacje robocze.
W przypadku migracji na serwerach trzeba, z uwagi na sposób zarzadzania
˛
plikami, wyróżnić
dwie podstawowe płaszczyzny. Z jednej strony każ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 kolejności przej˛ecia istniejacych
˛
w starym systemie danych i programów przez nowy system. Wiaże
˛ si˛e z tym także
odwzorowanie systemu uprawnień do autoryzacji dost˛epu do plików i katalogów oraz dostosowanie pracy systemu, np. sposobu zabezpieczania danych.
W drugiej kolejności chodzi o odtworzenie dotychczasowej funkcjonalności, badź
˛ to z wykorzystaniem istniejacych
˛
stacji klienckich, badź
˛ też przez stworzenie nowej architektury klientów.
Ten drugi etap tworzy właściwy rdzeń infrastruktury składowania plików. W centrum oceny znajduja˛ si˛e w szczególności takie zagadnienia, jak „prawa dost˛epu do poziomu plików i katalogów“
oraz „podstawowe funkcje składowania plików“.
Jeśli chodzi o zastapienie
˛
serwera NT 4.0 w obszarze zarzadzania
˛
plikami, pod uwag˛e należy
wziać
˛ 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łości badź
˛ cz˛eściowo na oprogramowaniu
własnoś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 należy także uwzgl˛ednić właściwoś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.
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ługość nazwy
pliku (znaki)
zestaw znaków
dla nazwy pliku
wyświetlanie wielkich
i małych liter
rozróżnianie wielkich
i małych liter
kwoty dyskowe
X
X
szyfrowanie
EFS
file-wise
po stronie
klienta
kompresja
X
X
1
2
maksymalna wielkość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ługość
ścieżki
change journal
X
propagacja zezwoleń
X
w Active Directory
rozłoż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
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 bezpośredniego zastapienia
˛
serwera Windows NT jako serwera plików, przy
zachowaniu klientów windowsowych, pierwszy wybór w obszarze oprogramowania Open Source powinien paść 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łeczność Open Source, lecz także
przez coraz wi˛eksza˛ ilość producentów IT.
W zależności od zakresu migracji na Linuksa po stronie klienta, w stron˛e centrum ocen alternatywnych rozwiazań
˛
przesuwaja˛ si˛e serwery NFS i AFS. Sa˛ one rozpowszechnione w sieciach uniksowych, jednak by umożliwić 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. Jednakże, by móc zastosować klienty NFS albo AFS w środowisku windowsowych stacji roboczych, trzeba wprowadzić daleko idace,
˛ koncepcyjne zmiany, w porównaniu
z sytuacja,˛ gdy zarzadzanie
˛
plikami odbywa si˛e z wykorzystaniem Windows NT.
Jeśli podczas modernizacji infrastruktury informatycznej tworzonej w ramach projektu migracyjnego ważna˛ rol˛e odgrywa metoda zapewnienia bezpieczeństwa za pomoca˛ Kerberos, która
leży także u podstaw Active Directory w Windows 2000, wówczas w przypadku kontynuacyjnego korzystania z produktów Windows po stronie klientów, należy zmierzać w kierunku zastosowania OpenAFS jako alternatywy dla Windows 2000 jako serwera plików.
3.2.3.3
Samba
Realizacj˛e zasadniczo różnych opcji, tj. centralnego składowania plików dla klientów windowsowych lub dla heterogenicznego środowiska klientów, można oceniać równorz˛ednie. Nie ma
powodu, by wykluczyć jedno badź
˛ drugie rozwiazanie.
˛
Jeśli chodzi o sposób stosowania i administrowania, to wszystkie opcje zwiazane
˛
sa,˛ w wi˛ekszym lub mniejszym stopniu, z wprowadze-
72
niem zmian w administrowaniu i stosowaniu. W rozumieniu konserwatywnej migracji kontynuacyjnej, serwery Samba i W2K oparte na SMB / CIFS spełniaja˛ założenie polegajace
˛ na najdalej
idacym
˛
zachowaniu istniejacych
˛
rozwiazań.
˛
W takich obszarach jak składowanie plików, drukowanie i autoryzacja Samba jest z wielu
powodów wzorowana na Windows NT. Z punktu widzenia użytkowników Samba odpowiada
w najwi˛ekszym przybliżeniu serwerowi NT. Z drugiej strony administratorzy widza˛ w niej serwer uniksowy. Obsług˛e Samby należy dostosować do filozofii oraz możliwości nowego systemu
operacyjnego.
W2K, jako nast˛epca NT niesie z soba,˛ z punktu widzenia użytkownika, niemal tyle samo
zmian w porównaniu z serwerem NT, co Samba. Jednakże dla administratorów zmiany te sa˛
już 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 badź
˛ innym kierunku moga˛ być uznane za
uproszczenie czy też zalet˛e, zależy ostatecznie od zainteresowanych osób. Migracja na Samb˛e,
Linuksa i Open Source otwiera nowe możliwości działania. Oprócz wi˛ekszej swobody oraz odpowiedzialności za swoje decyzje, administrator „zyskuje“, wraz z wykonaniem kroku w kierunku wyzwolenia si˛e od narzuconych schematów i Best Practices jednego producenta, także
nowe możliwości popełniania bł˛edów.
Serwer Samba spełnia, podobnie jak serwer NT, wymagania zwiazane
˛
z administrowaniem
plikami. Użytkownicy klientów windowsowych moga˛ równie dobrze ściagać
˛
swoje profile oraz
skrypty logowania z serwera Samba, jak swoje katalogi domowe lub katalogi grup. Na serwerze
Samba można również składować pliki wykonywalne (*.exe) (i je stamtad
˛ uruchamiać), takie jak
pliki bazy danych Access albo inne pliki z mechanizmami blokujacymi
˛
udost˛epniane jednocześnie wielu użytkownikom.
W odróż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 umożliwiaja˛ prac˛e na wspólnych danych
w środowisku heterogenicznym. Samba nie oferuje implementacji SMB opartej na protokole
NetBEUI, ani też nie obsługuje NetBIOS przez IPX.
Po stronie klienta nadal można używać narz˛edzi służacych
˛
do edycji plików znajdujacych
˛
si˛e na serwerze plików i do zarzadzania
˛
nimi. W szczególności można w tym celu korzystać z
programów Explorer i File Manager oraz z cacls, xcacls etc. Poczawszy
˛
od Samby 3.0 można
także nadal używać menedżera użytkowników. W zasadzie możliwe jest też zastosowanie menedżera plików, jednak z powodu zwiazanego
˛
z tym odwrotu od przejrzystości konfiguracji serwera
73
(smb.conf) jest to niezbyt dobre rozwiazanie.
˛
Zestawianie połaczeń
˛
do zasobów nadal, tj. bez wprowadzania zmian, możliwe jest za pomoca˛ skryptów logowania albo przez surfowanie w otoczeniu sieciowym.
System uprawnień Samby i Linuksa umożliwia zagwarantowanie uprzywilejowanym procesom, takim jak na przykład, skanerowi antywirusowemu na serwerze, lokalnego dost˛epu do
wszystkich plików w rodzimych katalogach użytkowników i jednocześnie na zezwolenie na taki
dost˛ep wyłacznie
˛
samemu użytkownikowi poprzez nap˛ed sieciowy.
Serwer Samba nadaje si˛e także do zarzadzania
˛
plikami i autoryzacji w środowiskach z windowsowymi serwerami terminali, z tym że w takim przypadku nie b˛edzie on obsługiwał specyficznych dla nich rozszerzeń obiektowych SAM.
Obsługa blokad plików (locking zarówno na poziomie pliku, jak też w Byte-Range) realizowana jest przez Samb˛e dokładnie tak, jak przez serwer NT. Oznacza to, że za pomoca˛ Samby
moż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 też innych zasobów systemowych) i przenosi t˛e funkcj˛e także na zasoby zarzadzane
˛
przez serwer Samba.
W Linuksie, dla potrzeb zabezpieczania danych i dokumentowania wersji / archiwizacji, skorzystać można z wielu różnych narzadzi
˛ Open Source. Dodatkowo serwery linuksowe można bez
problemu zintegrować z rozwiazaniami
˛
bezpieczeństwa oferowanymi przez wi˛ekszość dost˛epnego na rynku oprogramowania.
Wysoka˛ niezawodność, jaka˛ osiagni˛
˛ eto w NT wraz z wydaniem Enterprise Edition dzi˛eki
zastosowaniu klastrów, można uzyskać także w Sambie w oparciu o shared SCSI albo SAN z IP
Failover.
Jeśli porówna si˛e niektóre analizy możliwości5 wykonane w ostatnich latach, można stwierdzić, że nastapiło
˛
znaczne zmniejszenie ograniczeń funkcjonalności w zastosowaniach Samby.
W przyszłości Samba 3.06 umożliwi budowanie zaufanych połaczeń
˛
pomi˛edzy domenami Master
i Resource, czyli implementacj˛e rozwiazań
˛
z zakresu obsługi domen stosowanych w Windows
NT. Wraz z wersja˛ 3.0 powstanie także możliwość, wykorzystania menedżera użytkowników
do zarzadzania
˛
użytkownikami, np. w ten sposób b˛edzie można zakładać konta nowym użytkownikom. Nadal nie b˛edzie możliwości replikacji pomi˛edzy kontrolerem domeny Windows i
kontrolerem domeny Samby, czyli wewnatrz
˛ jednej domeny b˛edzie można używać samego kontrolera domeny Windows badź
˛ wyłacznie
˛
kontrolera domeny Samby. W przypadku, gdy wymagana b˛edzie integracja usług ś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 już ona wdrożona i działa w Federalnym Urz˛edzie ds. Karteli
74
można ja˛ uzyskać po zintegrowaniu tych usług jako Member Servers. Replikacja SAM w czystym środowisku kontrolera domeny Samby możliwa jest przez kombinacj˛e Samby i OpenLDAP.
OpenLDAP służy Sambie do administrowania grupami oraz użytkownikami i oferuje wymagane
mechanizmy replikacji.
NTFS
XFS
EXT3
R EISER FS
długość 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
wyświetlanie wielkich
i małych liter
rozróżnianie wielkich
i małych liter
kwoty dyskowe
X
X
X
X7
szyfrowanie
EFS
X8
X9
X10
kompresja
X
X11
X12
X13
maksymalna wielkość
pliku
2 tera
16/64
tera15
4 tera14
16/64
tera16
maksymalna długość
ścieżki
dowolna
dowolna
dowolna
dowolna
X
X
change journal
journaling
7
X
X
X
W niektórych wersjach niepewne.
Da si˛e zrealizować dla całych systemów plików lub cz˛eś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 możliwa jest kompresja na poziomie systemu plików.
12
W w˛eź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óżnych algorytmów.
Od jadra
˛ 2.4 projekt ten nie jest rozwijany, ponieważ nie ma już faktycznego zapotrzebowania na kompresj˛e. Za
pomoca˛ loopback możliwa jest kompresja na poziomie systemu plików.
13
Patrz kompresja w XFS.
14
W zależności od architektury - 32 czy 64 bitowa; w kernelu 2.4 ograniczona do 2 tera przez maksymalna˛
wielkość systemu plików.
15
W zależności od architektury - 32 czy 64 bitowa; teoretyczne maksimum wynosi 9 exabajt; w kernelu 2.4
ograniczona do 2 tera przez maksymalna˛ wielkość systemu plików.
16
W zależności od architektury - 32 czy 64 bitowa; teoretyczne maksimum wynosi 1 exabajt; w kernelu 2.4
ograniczona do 2 tera przez maksymalna˛ wielkość systemu plików.
8
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 wyszliśmy z założenia, że na klientach nie b˛eda˛
zapisywane dane użytkowe. W przypadku ewentualnej migracji należy postawić nowy system o
identycznej funkcjonalności, lecz bez przenoszenia danych znajdujacych
˛
si˛e na starych klientach.
Jeśli istnieje duża ilość identycznie wyposażonych klientów, na których trzeba wykonać migracj˛e, należy rozważyć 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ólności jeś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 przyjać
˛ takie same
założenia, jak w przypadku wyboru serwera (server system) dla centralnego składowania plików
w ogóle.
Nadawanie praw dost˛epu: odwzorowanie profilów uprawnień Windows na POSIX ACL
Kierowanie prawami dost˛epu do katalogów i plików za pomoca˛ serwera Samba odpowiada
w dużym stopniu założeniom znanym z NT. Takż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. Wcześniejszym projektem kontroli przestano zajmować si˛e od poczatku
˛
2000 r. Projekt grsecurity implementuje oparty na procesach system ACL w kernelu
(http://www.grsecurity.net/). Z jego pomoca˛ możliwe jest całkowite kontrolowanie plików i innych
aktywności systemu.
18
Patrz kontrolowanie w XFS.
19
Patrz kontrolowanie w XFS.
76
ustalane sa˛ na podstawie uprawnień określonych w systemie plików używanym po stronie serwera dla każdego indywidualnie autoryzowanego przez Samb˛e użytkownika.
Zasoby (shares) i ich właściwości wynikajace
˛ z usytuowania po stronie serwera, takie jak
ścież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 każdej instancji serwera. Edycja w/w pliku konfiguracyjnego może również odbywać 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łaścicieli plików w DOS i
starszych wersjach Windows, w Uniksie rozróżnia si˛e właścicieli i grupy uż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 użytkowników do wybranych katalogów i
plików.
W Uniksie możliwe jest zdefiniowanie, dla wszystkich plików, przynajmniej nast˛epujacych
˛
uprawnień: prawo do odczytu, zapisu i wykonywania przez właściciela, grup˛e właścicieli i wszystkich pozostałych użytkowników sytemu. W przypadku niektórych linuksowych / uniksowych
systemów plików można narzucić dodatkowe ograniczenia albo zagwarantować dodatkowe uprawnienia innym użytkownikom, grupom uż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
umożliwia dost˛ep do danych dzi˛eki efektywnym prawom dost˛epu, którym podlega weryfikowany
za każdym razem użytkownik. Serwer Samba może teoretycznie nakładać dodatkowe ograniczenia dost˛epu wykorzystujac
˛ ograniczenia określone w systemie plików, jednak w żadnym razie nie
może ich zlekceważyć. Zarówno w przypadku przenoszenia istniejacych
˛
praw dost˛epu z serwera
na klienta, jak też przy ujawnieniu si˛e zmian zainicjowanych po stronie klienta, serwer Samba
stosuje kanon uprawnień systemu plików, w którym składuje on dane użytkowników i nimi administruje. Dlatego w świecie Uniksa podczas migracji należy odwzorować model uprawnień z
Windows. W dalszych rozdziałach opisaliśmy, w jaki sposób można wykonać takie odwzorowanie oraz jakie szczegóły i ograniczenia trzeba przy tym wziać
˛ pod uwaga.˛ Autorzy poradnika
wyszli z założenia, ż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łożeniu łaty, EXT2 i EXT3.
77
Odwzorowanie NTFS-ACL w linuksowym systemie plików
W przypadku odwzorowania windowsowej ACL w linuksowej POSIX ACL system uprawnień zredukowany zostaje w takim stopniu, ż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óżnia uprawnień takich jak: zapisywanie danych, przyłaczanie
˛
danych, zapisywanie atrybutów oraz rozszerzonych atrybutów. Dlatego podczas przenoszenia systemu uprawnień Windows za pomoca˛ Samby do Uniksa, w uniksowym systemie plików można odwzorować tylko
kompletne grupy uprawnień Windows. Tak samo dzieje si˛e w odwrotnym kierunku, gdy serwer
Samba może zgłaszać klientowi windowsowemu również tylko grupy uprawnień.
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 uprawnień
X
zmiana uprawnień
20
Jest wyświetlany, ale nie wolno go ustawiać,
w przeciwnym razie aktywowana zostanie cała grupa „odczyt“.
X
X
78
przejmowanie uprawnień
właściciela
Tablica 3.10: Uprawnienia POSIX oraz grupy uprawnień Windows
Po stronie użytkownika można tworzyć w windowsowych oknach dialogowych, wykorzystujac
˛ kombinacje pasujacych
˛
uprawnień NTFS, odpowiednie kombinacje uprawnień POSIX. Należy przy tym pami˛etać, aby wstawianie dodatkowego uprawnienia NTFS z listy windowsowej,
spowodowało ustawienie wszystkich uprawnień w grupie POSIX, do której należy nadawane w
ten sposób uprawnienie. Jeśli, na przykład, dla jakiegoś 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. Jeśli w tym momencie klikniemy OK, wtedy
podczas nast˛epnego otwarcia okna dialogowego natychmiast pojawi si˛e w nim nowy, znacznie
rozszerzony zestaw uprawnień. Zaleta˛ takiego rozwiazania
˛
jest to, że opisane powyżej zachowanie serwera Samba nie dopuszcza do bł˛ednych interpretacji uprawnień pokazywanych w prostej
prezentacji.
W uproszczonej prezentacji ustawień bezpieczeństwa obraz jest spójny. Można tu nadawać
pojedyncze oraz wspólne prawa do odczytu i zapisu, jak również każdorazowo w kombinacji z
odczyt / wykonywanie. Tego ostatniego, zbiorowego uprawnienia, nie można nadawać pojedynczo.
Uprawnień NTFS, takich jak: usuwanie podkatalogów / plików, usuwanie, zmiana uprawnień
oraz przejmowanie uprawnień właściciela nie da si˛e odwzorować w POSIX ACLs i jeśli zostana˛
nadane, wówczas serwer Samba nie zwróci żadnego rezultatu (w tabeli zaznaczone na żółto).
W przypadku ustawienia pełnego dost˛epu, czyli nadania wszystkich praw: do odczytu, zapisu i
wykonywania, takż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
79
I
zmienianie
N
odczyt / wykonywanie
X
X
D
wylistowanie
X
X
O
zawartoś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. Niemożliwe jest odwzorowanie aktywnego dziedziczenia, takiego jak w NTFS.
Odwzorowanie systemu atrybutów
Atrybuty, których nie ma w Uniksie można odwzorowywać na różne sposoby. Tak naprawd˛e
nie trzeba tu ustawiać flagi tylko do odczytu, ponieważ istnieje już ona w tradycyjnym systemie
uprawnień i jest automatycznie wyświetlana dla plików i katalogów składowanych bez prawa
do zapisu. Flagi archiwalny, ukryty i systemowy można odwzorować za pomoca˛ nieużywanego
przez uniksowy system plików bitu execute. Dlatego można o nich powiedzieć, że istnieja.˛ Atrybuty spakowany i zaszyfrowany nie dadza˛ si˛e odwzorować, jednakże można skorzystać z nich w
Uniksie dzi˛eki specjalnym usługom.
Odwzorowanie funkcji kontrolnych
System kontroli jest silnie zintegrowany z Windows. W Uniksie można go uzyskać za pomoca˛ innych mechanizmów. W przypadku serwera Samba jest on realizowany poprzez moduł
VFS. W ten sposób na serwerze Samba uzyskuje 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 że podj˛etych zostało wiele prób implementacji i
że w linuksowych systemach plików spełnione sa˛ odpowiednie wymagania dotyczace
˛ rozszerzonych atrybutów. W praktyce możliwość ta ma jednak na tyle małe znaczenie, że wszystkie
podejmowane próby kończyły si˛e wskutek braku zainteresowania nimi.
80
Podsumowanie najważniejszych skutków zastosowania serwera Samba z POSIX ACLs
Jeśli chodzi o zapis, jako prawo abstrakcyjne, to:
◦ nie ma różnicy pomi˛edzy prawem do zapisu, a prawem do przyłaczania
˛
danych
◦ w przypadku katalogów również nie ma różnicy pomi˛edzy prawem do tworzenia katalogów, a prawem do tworzenia plików
◦ nie ma różnicy pomi˛edzy prawem do zapisywania katalogów badź
˛ plików, a prawem do
zapisywania atrybutów
Jeśli chodzi o odczyt, jako prawo abstrakcyjne, to:
◦ nie ma różnicy pomi˛edzy prawem do odczytu katalogów badź
˛ plików a prawem do odczytu
atrybutów
Zasadniczo należy przyjać,
˛ że odczyt jest dozwolony zawsze. Generalnie nie sa˛ zaimplementowane mechanizmy kontroli ani dziedziczenia.
Grupy użytkowników i prawa dost˛epu
Nadawanie praw dost˛epu grupom odgrywa istotna˛ rol˛e w szczególności w przypadku zasobów wspólnie używanych przez grupy robocze. W NT rozróżnić należy grupy lokalne (serwera)
i globalne. Lokalne grupy można rozumieć jako zdefiniowane aliasy, które wskazuja˛ na jedna˛
lub wi˛ecej grup globalnych. W ten sposób grupy lokalne moga˛ zawierać wiele grup globalnych.
W Sambie (i ogólnie w środowisku UNIX/Linux) nie jest możliwe zagnieżdżanie grup. Za pomoca˛ Samby można tylko przedstawić klientom windowsowym oraz Member Servers wszystkie
uniksowe grupy w skali 1 : 1 jako grupy globalne.
Oczywiście w/w globalne grupy moga˛ na windowsowych Member Servers ponownie wejść
do grup lokalnych. Tym samym w dalszym ciagu
˛ na tego typu serwerach można korzystać z
metod B-G-L-R i B-G-R, które zostały opisane w rozdziale 3.2.2.4.
Na razie na serwerach linuksowych nie planuje si˛e wprowadzenia rozwiazania
˛
opartego na
grupach lokalnych, dlatego swoje typowe zastosowanie znajdzie tutaj model B-G-R. Adekwatna˛
funkcjonalność można uzyskać za pomoca˛ odpowiedniego business-logic opierajac
˛ zarzadzanie
˛
grupami na LDAP.
81
Ocena skutków dla użytkowników
Przy odwzorowywaniu Windows-ACL na POSIX-ACL traci si˛e stopień dokładności, w jakim
można modyfikować uprawnienia w Windows. Jednak w praktyce, w znakomitej wi˛ekszości
zastosowań, wykorzystuje si˛e tylko o wiele prostszy zestaw uprawnień oferowany przez Security
settings.
Inne, dalej idace
˛ uprawnienia, stosowane sa˛ jedynie w pojedynczych przypadkach. Szczególnie rzadko wykorzystywane jest rozróżnianie pomi˛edzy uprawnieniami atrybutów i plików.
Także korzystanie z przyłaczania
˛
danych ma sens zaledwie w niektórych przypadkach. Uprawnienie to można nadawać również z linii poleceń, jako rozszerzony atrybut dla wybranych plików
w Linuksie, podczas pracy w systemach plików ext2 i ext3.
Dzi˛eki ścisłemu odwzorowaniu nieskomplikowanego modelu uprawnień z POSIX ACL, obraz prostych Security settings staje si˛e bardziej przejrzysty dla przeci˛etnego użytkownika.
Określonych funkcji, takich jak dziedziczenie i kontrola nie da si˛e odwzorować.
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 poniżej:
◦ system plików NTFS5
◦ HSM-API
◦ dziedziczenie
◦ szyfrowanie (EFS)
◦ SMB over Native IP
◦ dynamiczne administrowanie nośnikami danych
◦ defragmentacja
82
◦ zagnieżdżanie grup
◦ Remote Storage
◦ Indexing Service
◦ Distributed Link Tracking
◦ DFS
◦ Offline Folder
◦ Folder Redirection
W kolejnych paragrafach znaleźć można szerszy opis wprowadzonych zmian.
System plików NTFS5
System plików NTFS5 oferuje łacznie
˛
nast˛epujace
˛ ulepszenia:
Przede wszystkim możliwe jest administrowanie prawami dost˛epu za pomoca˛ funkcji dziedziczenia. Oznacza to, że uprawnienia nadane katalogom nadrz˛ednym działaja˛ także w katalogach i plikach podrz˛ednych bez konieczności ich przepisywania (Burn-In). Tym samym pozbyto
si˛e wad zwiazanych
˛
z przepisywaniem (problem obciażenia,
˛
usuwania specyficznych uprawnień
w katalogach podporzadkowanych).
˛
NTFS5 oferuje change journal, w którym protokółowane sa˛ zmiany.
Noś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˛ korzystać produkty innych producentów.
NTFS5 oferuje możliwość szyfrowania danych. Encrypting File System (EFS) umożliwia
użytkownikom chronienie danych przed odczytem ich zawartoś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.
83
Protokoły
Windows 2000 obsługuje, podobnie jak miało to miejsce we wcześniejszych wersjach tego
systemu operacyjnego, różne protokoły. Nowościa˛ w Windows 2000 jest możliwość wyłaczenia
˛
komunikacji przez NetBIOS. Dla File Services oznacza to, że podczas komunikacji, tzw. „Direct
Hosting of SMB Over TCP / IP“ odbywa si˛e przez port 445.
Administracja nośnikami danych
Windows 2000 oferuje możliwość, właczenia
˛
fizycznych twardych dysków do systemu, bez
konieczności przydzielania nap˛edom liter. Tego typu dynamiczne nośniki danych moga˛ być wła˛
czane do tradycyjnych nośników danych jako katalogi i udost˛epniane. Windows 2000 po raz
pierwszy dostarcza narz˛edzie do defragmentacji nośników danych.
Zmiany odnośnie nadawania praw dost˛epu
W Windows 2000 Active Directory istnieje znacznie wi˛ecej możliwości kontrolowania uprawnień, gdyż można mocniej zagnieżdżać wi˛ecej typów grup. Zagnieżdżanie grup możliwe jest
tylko wtedy, gdy Active Directory używany jest w „Native Mode“. W tym trybie pracy dost˛epne
sa˛ dwa nowe typy grup „Domain Local“ oraz „Universal“. Poniższa tabela pokazuje możliwości
zagnieżdżania.
T YP
GRUPY
MO ŻE MIE Ć NAST EPUJ
˛
ACYCH
˛
MO ŻE BY Ć CZŁONKIEM . . .
CZŁONKÓW . . .
grupa globalna
użytkownik i globalne grupy
tej samej domeny
globalne grupy tej samej
domeny;
grupy uniwersalne oraz lokalne
grupy domen
lokalna grupa
użytkownik, uniwersalna
lokalne grupy domen tej samej
domen
i globalna grupa każdej
domeny
domeny
grupy
użytkownik, globalne
lokalne grupy domeny albo
uniwersalne
i uniwersalne grupy każdej
domeny
uniwersalne grupy każdej domeny
Tablica 3.14: Typy grup
84
Oprócz w/w nowych typów grup, w środowiskach wykorzystujacych
˛
Active Directory i
Exchange 2000 należy wyróżnić grupy bezpieczeństwa oraz grupy dystrybucji. W przypadku
grup dystrybucji istnieja˛ środowiska Exchange, jednak nie da si˛e w nich kontrolować File Services .
Remote Storage
Remote Storage jest nowa˛ usługa˛ dostarczana˛ przez Windows 2000. Umożliwia ona składowanie długo nieużywanych plików na nap˛edach taśmowych w ramach tzw. HSM (Hierarchical
Storage Management).
Indeksowanie
Indeksowanie można opcjonalnie właczyć
˛
dla folderów plików w celu założenia indeksu zapisanych danych. Umożliwia on szybsze przeszukiwanie określonej zawartości. Indeksowanie
można stosować dla dokumentów:
◦ HTML
◦ tekstowych
◦ Microsoft Office 95 lub wyż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 umożliwiaja˛ takie zaprogramowanie aplikacji obsługujacych
˛
linkowanie i osadzanie obiektów, że podczas przeciagania
˛
zlinkowanych obiektów możliwe jest
uzyskiwanie z systemu plików informacji na temat ich aktualnego położenia w systemie, przy
jednoczesnym zachowaniu bezbł˛ednej pracy.
Distributed File System
Distributed File System (DFS) udost˛epniany był już w Windows NT 4 poprzez dodatkowo
instalowane oprogramowanie na serwerze i po stronie klienta. W przypadku Windows 2000 odpowiednie funkcje zostały, zarówno po stronie serwera jak i klienta, zaimplementowane jako
standard oraz dodatkowo rozszerzone. DFS umożliwia to, że zasoby udost˛epniane z katalogów
85
znajdujacych
˛
si˛e na różnych serwerach, moga˛ być przedstawiane klientowi w postaci podkatalogów pojedynczego zasobu. Dzi˛eki temu oszcz˛edza si˛e litery alfabetu opisujace
˛ nap˛edy, które
maja˛ być przyporzadkowane
˛
danemu użytkownikowi. W Windows 2000 DFS został na tyle rozszerzony o integracj˛e z FRS (File Replication Service), że zlinkowane zasoby i ich zawartość
moga˛ być replikowane do dalszych zasobów i innych serwerów plików. Jeśli serwer przestanie
pracować i przestanie tym samym udost˛epniać zasoby, wówczas klient b˛edzie mógł korzystać z
replik, bez potrzeby tworzenia nowych połaczeń
˛
sieciowych. W Windows 2000 informacje moga˛
być 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.
˛
˛
Użytkownikowi można ułatwić poszukiwanie zasobów przez opublikowanie ich w Active Directory.
Offline Folder i Folder Redirection
Funkcje „Offline Folder“ i „Folder Redirection“ nie sa˛ zasadniczo właściwościami File Services z Windows 2000, lecz funkcjami klienta (np. Windows 2000 / Professional). Wspomnieliśmy
o nich w tym miejscu, ponieważ maja˛ one duże znaczenie, jeśli chodzi o przechowywanie danych i dlatego, że funkcje te musza˛ współpracować z serwerem plików. Offline Folder sa˛ jakby
nast˛epcami „Aktówki“ z wcześniejszych wersji Windows. Użytkownicy korzystajacy,
˛ np. z notebooka, moga˛ edytować katalogi i pliki, które zazwyczaj zapisywane sa˛ na serwerze plików, bez
połaczenia
˛
sieciowego. Gdy tylko zestawione zostanie połaczenie
˛
z serwerem plików, nastapi
˛
synchronizacja (replikacja) odpowiednich plików. Dla wykonania bezbł˛ednej replikacji, bardzo
ważne sa˛ właściwości plików po obu stronach (klient i serwer).
Zastosowanie w Windows 2000 funkcji Folder Redirection wynika z możliwości znacznego
przyrostu wielkości profilów użytkownika na stacjach roboczych podczas pracy. Dzieje si˛e tak,
np. wtedy, gdy użytkownik zapisuje swoje pliki w „Own files“, które właściwie powinny być
składowane na serwerze plików. W Windows 2000 możliwe jest „ukierunkowanie“ profilu użytkownika („Own files“, „Application data“) na ścieżk˛e sieciowa˛ katalogów systemowych. Katalogi te b˛eda˛ dla użytkownika dost˛epne w przeźroczysty sposób, jako katalogi lokalne. Poprzez
przeciaganie
˛
katalogu do serwera plików należy zwrócić 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-
86
sób, że obecnie można wykonywać kopie bezpieczeństwa nap˛edów (lokalnych lub sieciowych).
Dzi˛eki temu łatwiej da si˛e uniknać
˛ stosowania lokalnych nap˛edów taśmowych.
Kolejne wersje systemu
Z punktu pojawiania si˛e nowych wersji należy wyróżnić 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 może współpracować wyłacznie
˛
ze specjalnym osprz˛etem i z niewielka˛ grupa˛
producentów. Platforma ta zakłada bardzo szczególna˛ dost˛epność i / lub scenariusze obciażenia
˛
(pojemności). W niniejszym poradniku nie b˛edzie ona omawiana.
Network Attached Storage (NAS)
Niektórzy producenci osprz˛etu wymyś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
Poniżej znaleźć można kilka uwag odnośnie przedstawionych wcześniej nowości technicznych:
◦ Upowszechnienie EFS z reguły ogranicza si˛e do zastosowań dla komputerów przenośnych,
na których wymagana jest ochrona danych przed uszkodzeniem oraz ochrona poufności
danych. Celowość stosowania EFS jest cz˛esto podważana z uwagi na konieczność korzystania z PKI (także, gdy jest ona już 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 kompatybilności zwrotnej.
◦ Należy, w oparciu o nowy system plików, rozważyć stosowanie dotychczasowych narz˛edzi do zarzadzania
˛
plikami i prawami dost˛epu. Na przykład NT 4 Explorer nie może w
sensowny sposób przedstawić dziedziczenia.
87
◦ W poszczególnym przypadku należy sprawdzić, pod katem
˛
dalszego korzystania z osprz˛etu,
który był wcześniej wykorzystywany przez NT 4, czy konieczne jest wdrożenie Windows
2000. W wi˛ekszości przypadków trzeba si˛e liczyć z tym, że konieczne b˛edzie nabycie
nowego osprz˛etu.
3.2.4.2
Windows 2003 Server
˛
oferowanych „File Services“, nast˛epc˛e Windows 2000, tj. Windows 2003 Server (wcześniej „NET Server“).
Poniżej znajduje si˛e krótki opis najważniejszych nowości, które zostały wprowadzone wraz
z nowa˛ wersja:
˛
Windows 2003 Server b˛edzie pierwszym systemem operacyjnym firmy Microsoft obsługujacym
˛
także architektur˛e 64 bitowa.
˛
Oficjalna obsługa technologii SAN (Storage Area Networks) zostanie ulepszona do takiego
stopnia, że możliwe b˛edzie bootowanie twardych dysków w SAN.
EFS umożliwi także dost˛ep do jednego zasobu wi˛ekszej ilości użytkowników. Grupy w dalszym ciagu
˛ nie b˛eda˛ uwzgl˛edniane.
Pojawi si˛e nowa funkcja Volume Shadow. Umożliwi ona postrzeganie struktury plików i katalogów w określonym czasie jako statycznej, dzi˛eki czemu możliwe b˛edzie, np. zabezpieczanie
danych bez konieczności zwracania uwagi na otwarte pliki. Z drugiej strony pojawia˛ si˛e nast˛epujace
˛ możliwości: uż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 poniż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 środowisku Linuksowym, jak też w środowiskach heterogenicznych, w skład których
wchodza˛ stacje klienckie oparte na Windows. Dla tych ostatnich pełnowartościowym systemem
wydruku jest kombinacja CUPS i Samby.
88
CUPS zapewnia ponad platformowa˛ obsług˛e zadań wydruku dzi˛eki zaimplementowanemu
IPP (Internet Printing Protocol). CUPS obsługuje także wszystkie inne ważne protokoły wydruku
takie jak LPR/LPD, Socket / AppSocket, SMB / CIFS oraz MS-RPC (w połaczeniu
˛
z Samba).
˛
Połaczenie
˛
CUPS / Samba umożliwia także automatyczna˛ instalacj˛e sterowników na klientach
windowsowych.
Ponadto CUPS oferuje różne możliwości zabezpieczania danych, także w czasie drukowania.
Należa˛ do nich transmisja szyfrowana przez SSL z wykorzystaniem IPP i weryfikacji użytkowników za pomoca˛ LDAP, czy też w połaczeniu
˛
z Samba.˛ Ma to wiele zalet, również z uwagi na
accounting dost˛epów do drukarki.
Przed rozpocz˛eciem migracji powinniśmy w każdym przypadku sprawdzić, czy w/w serwer
wydruku współpracuje z naszymi drukarkami. Dotyczy to w szczególności sytuacji, gdy wydruk
ma być realizowany w całości po stronie serwera wydruku, ponieważ w niewielu pojedynczych
przypadkach współpraca taka nie jest możliwa.
Klienty Windows 2000 moga˛ drukować poprzez serwer CUPS, także w przypadku migracji
kontynuacyjnej po stronie klientów, gdyż Windows 2000 obsługuje IPP.
3.3.2 Wprowadzenie
Temat „drukowanie“ traktowany jest w świecie informatyki po macoszemu. Dotyczy to wszystkich środowisk i systemów operacyjnych, tzn. w równym stopniu świata Windows, jak i świata
Uniksa / Linuksa. Problemy z wydrukiem sa˛ cz˛esta˛ przyczyna˛ poważnych strat powodowanych
utrata˛ płynności pracy. Administratorzy poświ˛ecaja˛ dużo swojego czasu, aby codziennie usuwać problemy z drukowaniem. Z drugiej strony drukowanie jest w wielu przypadkach „missioncritical“, która w razie problemów może zwi˛ekszać koszty i przyprawiać o duż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 niekompatybilności. Z tego powodu
panuje duży bałagan, jeśli chodzi o j˛ezyki uż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 możliwie dokładnej skali 1 : 1, jednak w obszarze tym można wykorzystać szans˛e i
usunać
˛ przy okazji wcześniejsze braki.
Oprócz braków technicznych równie decydujac
˛ a˛ rol˛e odgrywa cena. Cz˛esto nie sa˛ znane
89
prawdziwe koszty drukowania w ramach organizacji (działu, zakładu, koncernu, urz˛edu). W tej
dziedzinie istnieja˛ poważne potencjalne możliwości oszcz˛edzania, które uświadamiamy sobie
dopiero wówczas, gdy zobaczymy jednoznaczne dane.
Najważniejszymi kryteriami dla obliczania kosztów sa:
˛
◦ ilość drukarek
◦ zużycie papieru
◦ ilość zużywanych tonerów / atramentu
◦ zużycie energii
Przed rozpocz˛eciem migracji należy poznać odpowiedzi na nast˛epujace
˛ pytania:
◦ Ile jest drukarek w zakładzie pracy?
◦ Jak duże jest zużycie papieru?
◦ Jak duże jest zuż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 duży jest nakład pracy wewn˛etrznych służ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óżnych typach drukarek?
◦ Czy można wydajniej wykorzystać dost˛epne zasoby?
Rzeczywiste pieni˛eżne koszty można najcz˛eściej poznać dopiero po wykonaniu odpowiednich
kalkulacji. Nakład pracy, który trzeba przy tym ponieść, cz˛esto si˛e opłaca. Dokładna analiza
czynników generujacych
˛
koszty zwróci si˛e na pewno, ponieważ praktycznie zawsze istnieje możliwość oszcz˛edzania, która amortyzuje si˛e w ciagu
˛ roku.
Migracja w obszarze środowiska drukowania jest ci˛eciem - w czasie jej przygotowywania
należy wykonać odpowiednia˛ analiz˛e potrzeb, której wyniki należy uwzgl˛ednić w planach migracyjnych.
90
3.3.3 Punkt wyjścia - drukowanie pod Windows NT 4
W niniejszym rozdziale przedstawiliśmy sytuacj˛e, która˛ uznaliśmy za punkt wyjścia w przypadku wi˛ekszości istniejacych
˛
środowisk windowsowych.
Przyj˛eliśmy założenie, że istniejace
˛ środowisko oparte jest na jednym z powszechnie stosowanych modelu domen NT. Ponadto wyszliśmy z założenia, że środowiska te udost˛epniaja˛
Print Services oparte na Windows NT 4 Server. Oprócz tego założyliśmy, że serwery wydruku
sa˛ członkiem domeny NT.
Enterprise Edition umoż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 zadań przez pozostały w˛ezeł. Klient „odczuwa“ to - jeśli w ogóle - przez czas krótszy
niż sekunda. Nie można przy tym wykluczyć utraty aktywnych zadań drukowania. Zastosowanie
takiego klastra wymaga użycia specjalnego osprz˛etu (patrz File Services).
Jako komputery - klienty (Print Clients) wzi˛eto pod uwag˛e maszyny wyposaż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
Poniższy rysunek pokazuje typowa˛ konstelacj˛e środowiska wydruku:
Niektóre stacje robocze obsługuja˛ drukark˛e podłaczon
˛
a˛ lokalnie do LPT1 (drukarka lokalna).
Inne stacje robocze nie obsługuja˛ bezpośrednio podłaczonych
˛
drukarek, lecz współpracuja˛
wyłacznie
˛
z drukarkami podłaczonymi
˛
do sieci.
Wi˛ekszość drukarek laserowych można wyposażyć w kart˛e sieciowa.˛ W przeciwieństwie do
nich drukarki atramentowe można wykorzystać do pracy w sieci cz˛esto dopiero po zastosowaniu
dodatkowego printer box.
91
21
Rysunek 3.3: Środowisko wydruku
Rysunek pokazuje dwa zasadniczo różne przepływy danych. Z jednej strony klient wydaje
zlecenie wydruku bezpośrednio przez sieć na drukark˛e, a z drugiej strony klient korzysta z „udost˛epnionej drukarki“ na serwerze wydruku, który ostatecznie przekazuje dane do drukarki.
Poniżej opisane zostały róż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 także w świecie Windows poczawszy
˛
od Windows NT i jest standardem komunikacji pomi˛edzy serwerem wydruku a drukarka.˛ Zasadniczo technika ta może być takż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 poniż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
92
Niniejsze porty, w przeciwieństwie do portu LPR, sa˛ w stanie korzystać także z innych protokołów transportu. W powyższym przypadku obsługiwane sa,˛ np.
◦ DLC
oraz
◦ IPX
Nowe sieciowe porty wydruku z reguły umożliwiaja˛ komunikacj˛e dwukierunkowa˛ z drukarkami
lub z print boxes.
3.3.3.3
Bezpośrednie drukowanie ze stacji roboczej
Bezpośrednie drukowanie (patrz 3.3, strzałka 1) realizowane jest poprzez LPR / LPD. W tym
celu na stacjach roboczych z Windows NT 4 musi być zainstalowany serwer wydruku TCP /
IP. Systemy Windows 9x trzeba dodatkowo wyposażyć w oprogramowanie innych producentów.
Na stacjach roboczych należy skonfigurować, jako przyłacze,
˛
tak zwany port LPR. W tym celu
należy wpisać adres IP albo odpowiednia˛ nazw˛e hosta (DNS) drukarki docelowej. Nast˛epnie, na
żadanie,
˛
należy wybrać model drukarki wraz z odpowiednimi sterownikami. System operacyjny
przyjmie informacj˛e o tej drukarce, jako drukarce „lokalnej“. Bezpośrednia komunikacja klienta
z drukarka˛ w Windows NT nie znalazła szerokiego zastosowania ze wzgl˛edu na duży nakład
pracy administracyjnej jaka˛ w tym celu trzeba wykonać na urzadzeniach
˛
koń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 bezpośrednie
drukowanie ze stacji roboczej, podrozdział 3.3.3.3).
Transmisja danych pomi˛edzy stacja˛ robocza˛ a serwerem wydruku może być realizowana na
różne sposoby.
Aby klient mógł wydawać zlecenia wydruku do określonej drukarki za pośrednictwem serwera, po stronie serwera musza˛ być spełnione dwa zasadnicze warunki:
93
◦ drukarka musi być skonfigurowana na serwerze wydruku (port LPR, sterowniki wydruku)
◦ drukarka musi być dost˛epna
Udost˛epnienie drukarki umoż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) może
być realizowana na trzy różne sposoby:
◦ Za pomoca˛ polecenia NET USE można przekierować istniejacy
˛ port lokalny LPT na udost˛epniana˛ drukark˛e (przykład: net use LPT3\\nazwaserwera\nazwaudost˛epnianejdrukarki).
Metoda ta wymaga od użytkownika zainstalowania drukarki (sterowników drukarki) na
porcie LPT i jej lokalnego skonfigurowania. Jest to cz˛esto wymagane, gdy wydruk ma być
wykonywany z aplikacji dosowych. Dane wydruku przesyłane sa˛ w formacie RAW, co
oznacza, że moga˛ być one zinterpretowane przez drukark˛e bezpośrednio po przesłaniu.
◦ Można utworzyć nowy port LPR z adresem docelowym serwera wydruku i nazwa˛ udost˛epnianej drukarki. Dane wydruku również w tym przypadku przesyłane sa˛ w formacie
RAW.
Za pomoca˛ tak zwanej metody „Point & Print“ na stacji roboczej można skonfigurować drukark˛e
sieciowa.˛ Zaleta˛ takiego rozwiazania
˛
jest to, ż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 zinterpretować, dlatego dane musza˛ zostać wcześ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 wdrożył tym samym tak zwana˛ technologi˛e Point & Print.
Z jednej strony rozwiazanie
˛
to umożliwia przenoszenie sterowników drukarki z serwera na
klienta oraz przekazanie ustawień drukarki (podawane papieru, standardowe formaty papieru)
do klienta, a z drugiej cz˛eść procesu przetwarzania danych (Rendering) przechodzi na serwer,
dzi˛eki czemu nast˛epuje odciażenie
˛
klienta. Jest to szczególnie korzystne podczas pracy z Terminal Servers.
94
Ponieważ opisywana technologia Microsoft jest specyficzna, poniżej przedstawiony został
szczegółowy przebieg całego procesu drukowania. Przyj˛eliśmy założenie, że zarówno stacje robocze, jak i serwer wydruku korzystaja˛ z Windows NT 4.
Jeśli użytkownik doda drukark˛e sieciowa˛ do swojego środowisku wydruku, wówczas, jako
pierwsze, nastapi
˛ zsynchronizowanie sterowników. Klient Windows NT ściagnie
˛
sterowniki z
serwera, jeśli jednocześnie spełnione zostana˛ nast˛epujace
˛ warunki.:
◦ Serwer wydruku uż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 niż ta, która znajduje si˛e na serwerze.
Po ściagni˛
˛ eciu sterownika, nastapi
˛ jego instalacja przez klienta. Oznacza ona także umieszczenie
odpowiednich wpisów w lokalnym rejestrze klienta.
Proces drukowania:
Poniższy rysunek (rys. 3.4) przedstawia przebieg całego procesu, a pod rysunkiem znajduje
si˛e jego krótki opis.
95
Rysunek 3.4: Proces wydruku realizowany metoda˛ „Point & Print“
◦ Krok 1:
Uż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:
Ponieważ klient uż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) bezpośrednio przez API. Router „polls“ „Remote printer provider“ (Win32spl.dll)
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 przeciwieństwie do formatu RAM,
jeszcze dość niezależne od urzadzenia
˛
drukujacego
˛
a ich wielkość w wi˛ekszości przypadków jest
niewielka. Pierwsza cz˛eść „renderingu“ wykonana została na kliencie, natomiast teraz nast˛epuje
druga cz˛eść, 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 każda˛ stron˛e w bitmap˛e i drukuje je na papierze.
Jeś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.
Także w sytuacji, gdy klient uż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 może
opierać si˛e na różnych protokołach:
◦ TCP / IP
◦ NetBEUI
◦ SPX/IPX
97
Właś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
ś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 moż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 ważne jest automatyczne nawiazanie
˛
połaczenia
˛
z drukarkami podczas logowania użytkownika. Można je realizować przez skrypt VB
albo korzystajac
˛ z takich narz˛edzi jak con2prt.exe.
Do przyznawania praw dost˛epu do zasobów - drukarek można wykorzystać skrypty (Perl).
3.3.3.9
Migracja - szczegóły robocze
Ustawienia drukarek zależa˛ od każdej z nich z osobna. Różnice mi˛edzy nimi moga˛ wystapić
˛
nawet w przypadku wykorzystywania drukarek tego samego modelu, np. wskutek ich różnego
złożenia albo różnego wyposażenia. Dlatego podczas ustawiania parametrów drukarek należy
zwrócić uwag˛e na takie elementy jak pami˛eć operacyjna, sposób podawania i format papieru.
98
Drukarki z wieloma podajnikami cz˛esto zasilane sa˛ papierem różnej jakości. Aby ułatwić
użytkownikowi dokonanie prawidłowego wyboru, drukarka jest cz˛esto udost˛epniana jako dwa
różne zasoby. Wówczas każdemu z nich można zadać różne ustawienia, odpowiednio do standardowo obsługiwanego podajnika.
Aby optymalnie obsłużyć użytkownika mobilnego, można pomyśleć o zestawieniu połacze˛
nia z drukarkami na podstawie miejsca, w którym znajduje si˛e komputer. Posłużyć si˛e przy tym
można dodatkowymi mechanizmami w skryptach logowania, o ile istnieje możliwość odpytywania bazy danych, w której przechowywane sa˛ informacje odnośnie przyporzadkowania
˛
stacji
roboczych i drukarek.
Producenci wielu modeli drukarek oferuja˛ własne sterowniki, także wtedy, gdy znajduja˛ si˛e
już one w źródłach Windows NT. Sterowniki udost˛epniane przez Microsoft sa˛ sprawdzone, jednak cz˛esto nie maja˛ one takiej ilości opcji, jak sterowniki pochodzace
˛ od producentów drukarek
(obsługa wielu podajników, duplex). Dlatego ich użycie może okazać si˛e konieczne. Producenci
cz˛esto dostarczaja˛ swoje sterowniki w postaci dodatkowych plików *.dll. Daje to wi˛eksza˛ kompletność ś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 środowiskach stosuje si˛e także predefiniowane formularze (forms) i czcionki.
W środowisku Windows NT każdy użytkownik ma, w standardowej konfiguracji, dost˛ep do
każdej udost˛epnianej drukarki, co cz˛esto jest jednak niechcianym rozwiazaniem.
˛
W porównaniu
z File Services, przyznawanie użytkownikom praw dost˛epu do zasobów - drukarek jest znacznie
trudniejsze.
˛
W niniejszym rozdziale założyliśmy sytuacj˛e, że istnieje infrastruktura drukowania, w skład której wchodzi przynajmniej jeden serwer wydruku badź
˛ że trzeba stworzyć taka˛ infrastruktur˛e.
Minimum zadań przypadajacych
˛
na serwer wydruku b˛edzie pełnienie roli centralnego Spooling
Host, który może świadczyć także inne usługi.
Opisany poniżej sposób migracji zwiazany
˛
jest wyłacznie
˛
z jednym systemem, tj. z „Common UNIX Printing System“. Jest tak, gdyż praktycznie we wszystkich systemach uniksowych,
zdołał si˛e on przebić na pierwsze miejsce spośród innych systemów drukowania. CUPS został
niedawno przystosowany również do pracy w systemie operacyjnym Mac OS X firmy Apple. W
przypadku Linuksa CUPS jest de facto standardem we wszystkich dużych dystrybucjach (SuSE,
Debian, Mandrake, RedHat, itd.).
W przypadku, gdy istniejace
˛ środowisko wydruku składa si˛e z klientów windowsowych,
99
które maja˛ dost˛ep do swojego serwera wydruku NT-Print-Server, oceniliśmy możliwości przeprowadzenia migracji po stronie serwera.
3.3.4.1
Ponieważ drukowanie jest cz˛esto zadaniem typu „mission critical“, istnieja˛ duże wymagania
odnośnie infrastruktury technicznej i wewn˛etrznej organizacji:
◦ niezawodna praca
Nieodzowne jest choćby minimalne zabezpieczenie przed awaria;
˛ możliwość łatwego zintegrowania rozwiazań
˛
zast˛epczych - gotowość do pracy (drukowania) musi być zagwarantowana niezależnie od obecności specjalistów IT.
◦ wierne odwzorowanie - odpowiednia jakość wydruku
Kryteriami oceny właściwej jakości sa˛ prawidłowe czcionki, grafika bez zniekształceń, prawdziwe kolory.
◦ jakość wydruku
Renderowanie powinno odbywać si˛e z minimalna˛ rozdzielczościa.˛
◦ accounting
Należy stworzyć możliwość kontrolowania kosztów polegajac
˛ a˛ na szczegółowym protokołowaniu wykonywanych zadań.
◦ kwoty
wymaganie majace
˛ na celu kontrol˛e kosztów badź
˛ ich ograniczenie.
◦ obejście zadań drukowania
Należy zapewnić możliwość bezproblemowego korzystania z drukarki zast˛epczej, takiego które
nie wymaga ponownego przesłania zlecenia wydruku przez klienta (ważne: W wypadku, gdy
używana jest drukarka zast˛epcza innego typu, mimo wszystko, powinna ona być w stanie wydrukować wysłany do niej plik.
◦ ponowienie zadania wydruku
100
W środowisku zapewniajacym
˛
centralne powielanie, cz˛esto wymagane jest ponowne wykonanie zakończonego już zlecenia drukowania. Aby skorzystać 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. użycie papieru o niewłaściwym kolorze), należy
skorzystać z funkcji realizujacej
˛ powtórny wydruk.
◦ Job History
Historia zadań dokumentuje przebieg wszystkich procesów drukowania. Dzi˛eki niej pod koniec
roku można uzyskać liczby wiele mówiace
˛ o łacznej
˛
ilości zrealizowanych zadań wydruku (planowanie budżetu), ich rozłożeniu na poszczególne modele drukarek i miejsca (optymalizacja
podziału zasobów) oraz maksymalnym obciażeniu
˛
(w którym miejscu maja˛ sens nowe inwestycje)
◦ Integracja z rozwiazaniami
˛
własnościowymi
Cz˛esto zachodzi potrzeba przej˛ecia albo zintegrowania „starych“ lub nowych specjalistycznych
rozwiazań.
˛
Należ sprawić, by było to możliwe bez wi˛ekszych problemów.
◦ przejrzystość kosztów i ich kontrola
- z nich nie wolno rezygnować, zarówno podczas przeprowadzania migracji, jak i w późniejszej
pracy.
◦ bezpieczeństwo
Nie można dopuścić do „podsłuchiwania“ zaufanych danych (dotyczy to także przechwytywania
plików przeznaczonych do wydruku).
◦ autoryzacja
Określone drukarki powinny być udost˛epniane wyłacznie
˛
wyznaczonym grupom użytkowników,
wzgl˛ednie pracować z ograniczonymi „zaufanymi“ ustawieniami (1200 dpi w trybie full-screen
na papierze fotograficznym) dla określonych użytkowników (albo być całkowicie disabled).
◦ drukowanie „on hold“
Drukowanie przesuni˛ete w czasie lub „nocne“ (automatycznie sterowane batch-jobs).
101
◦ bez specjalnego oprogramowania umożliwiajacego
˛
podglad
˛
W idealnym przypadku szybki podglad
˛ zadań oczekujacych
˛
w kolejce wydruku realizowany jest
z poziomu przegladarki
˛
internetowej. Najlepiej, aby z „każdego miejsca“ zagwarantowany był
dost˛ep do linii poleceń. Najlepsza sytuacja jest wtedy, gdy nie dotyczy to każdego, lecz tylko
uprawnionych osób.
◦ integracja ze środowiskami heterogenicznymi
Oprogramowanie realizujace
˛ wydruk musi obsługiwać wiele protokołów, ponieważ w praktyce
nie istnieje ogólnie przyj˛ety standard. Zdolność do wszechstronnej współpracy musi dotyczyć
zarówno komunikacji z klientem (powinien on zachować dowolność wyboru protokołu za pomoca˛ którego przesyła dane do drukowania), jak też komunikacji z drukarka˛ docelowa˛ badź
˛
serwerami wydruku typu second-level (które cz˛esto sa˛ „starodawne“ i dlatego wymagaja˛ zachowania odpowiednich konwencji). Dodatkowo musi być zachowana ogólna obsługa przyszłego
standardu IPP.
3.3.4.2
Obsługa standardów wyróżniajacych
˛
si˛e22 w procesie drukowania
Korzystajac
˛ z zaproponowanych rozwiazań
˛
technicznych, należy spełnić poniższe wymagania
odnośnie funkcjonalności. Ważne jest przy tym dażenie
˛
do uzyskania otwartości przez konsolidacj˛e z istniejacymi
˛
i uznanymi otwartymi standardami. Jednocześnie, na czas migracji, należy zagwarantować wymagane wsparcie dla protokołów używanych wcześniej albo protokołów
własnościowych (oraz urzadzeń,
˛
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) może pełnić rol˛e protokołu ponad platformowego. IPP stosowany jest jako protokół ła˛
czacy
˛ serwery i klienty CUPS z nowoczesnymi drukarkami obsługujacymi
˛
bezpośrednie wsparcie IPP, jako medium dla komunikacji i transmisji danych. Podczas komunikacji ze starszymi
drukarkami albo serwerami wydruku można skorzystać z modułów CUPS, tak zwanych „BackEnds“. Moduły te umożliwiaja˛ komunikacj˛e za pomoca˛ innych protokołów. Na rysunku 3.5
przedstawiony został schemat korzystania z protokołów na różnych interfejsach. Ich działanie
opisaliśmy poniżej.
LPR/LPD
Tradycyjny protokół służacy
˛ do transmisji danych wydruku [od klienta do serwera wydruku,
22
Standardy otwarte, jak i zamkni˛ete.
102
z serwera do serwera i z serwera do drukarki docelowej (sieciowej) lub też z klienta bezpoś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łaściwego“ standardu (różne implementacje, które z powodu miejscowego braku
kompatybilności stwarzaja˛ trudnoś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
możliwości komunikacji, tj. klient - serwer, serwer - serwer, serwer - drukarka docelowa oraz
klient - drukarka docelowa. Ostatnia˛ i jedyna˛ wiaż
˛ 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 już 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 należy wprowadzać tylko tam, gdzie
ma to bezpoś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 można je nieodpłatnie przystosować (Windows NT, Windows 95, Windows 98). Dzi˛eki temu systemy te moga˛ podczas drukowania „całkiem naturalnie“ korzystać z
serwera CUPS. Jednakż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 przejściowym, np. nie definiowała ważnego aspektu szyfrowania
danych przeznaczonych do wydruku oraz sposobu autoryzacji użytkowników. Z tego powodu
serwer CUPS, w przypadku bezpośredniego udost˛epniania klientowi windowsowemu swoich
usług, musi rezygnować z autoryzacji. Jeśli CUPS stosowany jest wspólnie z Samba,˛ wówczas
wymagana, ewentualna autoryzacja klienta windowsowego może być realizowana dzi˛eki mechanizmom zaimplementowanym na serwerze plików. Dla środowisk o wyższych wymaganiach
wzgl˛edem bezpieczeń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 niż LPR / LPD; umożliwia w
103
pewnym stopniu komunikacj˛e dwukierunkowa˛ i jest szybszy. Istnieja˛ zarówno wolne, jak i komercyjne narz˛edzia administracyjne dla JetDirect służace
˛ do zarzadzania
˛
struktura˛ dużych sieci
(np. HP WebJet Admin). Jednakże nie oferuje on ani możliwości szyfrowania danych wydruku,
ani autoryzacji użytkowników. Zwrotne komunikaty o stanie drukarki realizowane sa˛ w praktyce
tylko w kierunku serwer - drukarka lub w przypadku połaczenie
˛
bezpośredniego w kierunku
klient - drukarka.
SMB/CIFS
Klienty windowsowe uż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 najbliższego komputera z Windows do drukarki (sieciowej) docelowej musi być ponownie regulowana przez inny protokół (chyba, że podłaczona
˛
jest ona lokalnie - przez interfejs
równoległy, USB, FireWire lub interfejs szeregowy).
MS-RPC
Klienty windowsowe, poczawszy
˛
od NT4, potrafia˛ używać tego protokołu do transmisji danych wydruku do Windows-Print-Server (od wersji NT4). Za pomoca˛ metod RPC można także
wykonywać 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ównież opiera si˛e na RPC). Od czasu, gdy Samba potrafi zarzadzać
˛
SMB /
CIFS, możliwe jest także wykorzystywanie go przez CUPS.
Obsługa wielu protokołów w CUPS (rysunek pogladowy)
˛
104
23
Rysunek 3.5: Drukowanie z CUPS
3.3.4.3
Integracja w środowiskach klienckich Windows
Wskazówka odnośnie integracji CUPS i Samby
Obsługa CUPS jest zintegrowana z Samba˛ w optymalny sposób, znacznie lepiej niż 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˛ korzystać z tych
funkcji „linkujac“
˛ bibliotek˛e. Właśnie Samba wykorzystuje t˛e właściwość. Jest ona domyślnie
zlinkowana z libcups. Serwer wydruku Samba może dzi˛eki temu przekazywać przychodzace
˛ zlecenia wydruku do serwerów wydruku CUPS przez IPP. Moga˛ być one zainstalowane na innych
hostach wyznaczonych do obsługi wydruku albo na tym samym serwerze, co Samba. Stosowanie IPP odbywa si˛e tu w całkowicie przejrzysty sposób, zarówno dla administratora, jak i dla
uż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/
105
Win98SE dostarczany z IPP (wersja 1.0)
Win98 po wyposażeniu w IPP
Windows 9x
Przez SMB / CIFS (z pomoca˛ Samby)
Przez LPR / LPD (wymaga doinstalowania
klienta LPR)
Po wyposaż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 LPR / LPD
Citrix Metaframe
Po wyposażeniu w IPP
i Windows Terminal - Server
Przez LPR / LPD
GNU/Linux
Wbudowane CUPS i IPP
Przez LPR / LPD
UNIX
Po wyposaż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 odwzorowywać NTPrint-Server. Zostało to bardzo dokładnie opisane w Samba HOWTO Collection. Uzyskanie od-
106
powiedniej konfiguracji nie wymaga dużej ingerencji administratora. Obsługiwane jest również
ś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 uż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˛ użytkownicy i administratorzy pracujacy
˛ w ramach jednej domeny, jeśli używaja˛ skryptów logowania. Wystarczy utworzyć skrypt zawierajacy
˛ zaledwie jeden wiersz:
rundll32 printui.dll,PrintUIEntry /in /n„\\SAMBASERVERNAME\nazwazasobu-drukarki
.
Odpowiednia drukarka zostanie automatycznie zainstalowana dla logujacego
˛
si˛e użytkownika (innymi możliwościami oferowanymi przez skrypty sa:
˛ instalacja wielu drukarek, wyznaczenie drukarki domyślnej, usuwanie zb˛ednych kolejek drukowania itd.). Dzi˛eki temu zarzadza˛
nie sterownikami drukarek jest komfortowe a administratorzy maja˛ mniej pracy. Różnym grupom
użytkowników można w ten sposób, tj. wykorzystujac
˛ różne skrypty logowania, przypisać różnie
przystosowane środowiska.
Bezpieczeństwo i autoryzacja
Jeśli korzystamy z CUPS, istnieje możliwość szyfrowania komunikacji pomi˛edzy klientem. a
serwerem. Gdy stosowany jest protokół IPP, do szyfrowania przesyłanych danych można wykorzystać SSL 3 albo TLS.
Inna możliwość spełnienia podwyższonych wymagań bezpieczeństwa polega na zastosowaniu autoryzacji użytkowników za pomoca˛ LDAP. CUPS obsługuje interfejs LDAP, który można
wykorzystać do kierowania nadawaniem praw dost˛epu w systemie drukowania. Usług˛e katalogowa˛ można dodatkowo zastosować do skonfigurowania praw dost˛epu i kwot dla konkretnego
uż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 zapewnić serwerowi Samba możliwość korzystania z serwera wydruku CUPS (właściwa
autoryzacja).
107
Rozgłaszanie drukarek obsługiwanych przez CUPS w LDAP i Active Directory
Samba może wpisywać swoje usługi do katalogu LDAP albo do Active Directory. Korzyści z
tego czerpia˛ oczywiście drukarki obsługiwane przez CUPS, a także CUPS-Print-Serwer. Możliwa jest dalsza rozbudowa integracji ze środowiskiem AD (albo mocno wzorowanym na nim
środowiskiem LDAP). Najbliższa wersja CUPS, która jest w stanie „sama z siebie“ obsłużyć
połaczenie
˛
z LDAP znajduje si˛e już w zaawansowanej fazie beta.
Niezależny od platformy dost˛ep przez WWW
CUPS posiada „wbudowany“ Web-Interface. Dost˛ep do niego uzyskać można wywołujac,
˛ za
pomoca˛ przegladarki
˛
internetowej, adres: „http://CUPS-PRINTSERVER:631/“. W ten sposób
wszyscy użytkownicy moga˛ uzyskać dost˛ep do informacji o funkcjach serwera wydruku. Standardowo użytkownicy moga˛ kontrolować stan zleceń drukowania, przerywać je, wznawiać oraz
ponawiać, etc. (w zależności od każdorazowej konfiguracji).
W odniesieniu do drukarek / kolejek drukowania, administratorzy lub pracownicy help-desk,
którzy korzystaja˛ z Web-Interface, moga˛ je zakładać, usuwać, zmieniać konfiguracj˛e, uruchamiać
i zatrzymywać, zamykać / otwierać oraz równoważyć zlecenia wydruku, odkładać i ponownie
uruchamiać. Możliwości obsługi drukowania przez Web-Interface można ograniczać albo rozszerzać w zależności od konfiguracji serwera CUPS. Web-Interface podlega takim samym zasadom kontroli praw dost˛epu, jak ogólne zasoby CUPS. Każdy obiekt serwera wydruku (dost˛ep do
własnych zleceń albo pojedynczych drukarek, dost˛ep do wszystkich drukarek albo wszystkich
zleceń itd.) można wyposażyć w różne prawa dost˛epu: „Użytkownik Kowalski ma prawo administrować, ale tylko wtedy, gdy korzysta z komputerów A albo B“, „Wszystkim użytkownikom
wolno usuwać własne zlecenia wydruku, ale nie cudze“, itd.)
3.3.4.4
Możliwości dostosowawcze
Oprócz bezpośredniego zestawu funkcji oferowanych przez CUPS system ten można prosto i w
na różne sposoby rozszerzyć o filtry i BackEnds.
Filtry
Wewn˛etrznie CUPS używa systemu plików o modularnej budowie. Pracuje on na otwartych
interfejsach. Może być w każdej chwili rozszerzony. W tym celu można skorzystać 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 można także właczać
˛
własnościowe programy
108
w postaci binarnej.
BackEnds
Nowe BackEnds można „dokować“ w prosty sposób. Czasami, gdy istnieje potrzeba dostosowania systemu do specjalnych wymagań danego środowiska (np. automatyczna replikacja określonych zleceń wydruku w innym dziale, np. w celu składowania listów służbowych w archiwum), a czasami ze wzgl˛edu na atrakcyjność nowości technicznych (Wireless LAN, Bluetooth,
FireWire).
3.3.4.5
J˛ezyki opisu stron
CUPS uż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 każ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 także dla drukarek, które nie posiadaja˛ własnego interpretera postscriptu.
CUPS używa tych dobrze zdefiniowanych opisów drukarek podczas definiowania odpowiednich
ustawień konfiguracyjnych poprzez Web-Frontend albo nakładki konfiguracyjne klientów.
Dla drukarek, które nie obsługuja˛ postscriptu, serwer CUPS konwertuje dane nadesłane przez
klienta używajac
˛ w tym celu tak zwanych „filtrów“. W Linuksie program ghostscript zawiera
niezwykle wszechstronne zestawy filtrów umożliwiajace
˛ konwertowanie z j˛ezyka PostScript do
różnych, specyficznych dla producentów i urzadzeń,
˛
j˛ezyków. Dopasowana wersja ghostscript
jest także cz˛eścia˛ CUPS.
3.3.4.6
Techniczna zmiana funkcji sterownika
Przekształcanie pliku przeznaczonego do wydruku w nadajace
˛ si˛e do wydruku bitmapy, możne
być realizowane na dwa różne sposoby, tzn:
◦ Funkcje sterownika wykonywane sa˛ w całości po stronie klienta.
Plik do wydruku przygotowywany jest po stronie klienta. Serwer wydruku realizuje jedynie funkcje spooling dla danych wydruku. Sterowniki moga˛ być oferowane klientowi do ściagni˛
˛ ecia i
automatycznej instalacji.
◦ Przygotowanie danych do wydruku odbywa si˛e na serwerze wydruku.
109
Dane wydruku przesyłane sa˛ z klientów w do serwera wydruku w formacie PostScript. Na klientach konieczny jest odpowiedni sterownik PostScript, może on być udost˛epniany na serwerze do
automatycznej instalacji. Po takim przygotowaniu dane wydruku przesyłane sa˛ z serwera do zadanych drukarek. O ile drukowanie ma nastapić
˛ na drukarce, która nie obsługuje PostScript, proces przygotowywania wydruku realizowany jest za pomoca˛ specjalnego oprogramowania (patrz
także 3.3.4.5).
Drugi model, w przeciwieństwie do pierwszego, oferuje wi˛ecej korzyści:
◦ automatyczna˛ obsług˛e wszystkich urzadzeń
˛
postscriptowych wraz ze wszystkimi opcjami
drukowania (tak jak w Windows NT).
◦ dodatkowa˛ obsług˛e ogólnie stosowanych drukarek niepostscriptowych (w zależności od
zastosowania ghostscript albo innych pakietów sterowników).
◦ automatyczny accounting
Podczas logowania każdej stronie automatycznie przypisywany jest czas wydruku, nakład, drukarka docelowa, nazwa użytkownika, ID-procesu wydruku i IP nadawcy, które moga˛ być wykorzystywane przy późniejszym ocenianiu (kontrola kosztów, statystyki).
◦ kwotowanie
Możliwość ustalania kwot na wykorzystywanie przez użytkowników danej drukarki (określenie
ilości stron i / oraz ilości danych, które, po przesłaniu przez konkretnego użytkownika, maja˛
zostać zaakceptowane przez drukark˛e).
◦ funkcj˛e reprint
Zlecenia gotowe do druku przechowywane sa˛ przez pewien czas. Ich realizacja nie wymaga od
klienta ponownego szukania żadanego
˛
pliku, otwierania i przesyłania go. Dotyczy to zarówno
pierwszego, jak i ponownego drukowania.
◦ funkcj˛e redirect
Pliki przeznaczone do druku można w każdej chwili przekierować do innej drukarki docelowej
(nawet wówczas, gdy pierwotna drukarka była drukarka˛ postscriptowa˛ a nowa nie obsługuje
PostScript). Opcje wydruku można dostosować do nowego urzadzenia
˛
docelowego.
◦ konsolidacja sterowników
110
W efekcie końcowym wszystkie klienty uż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 ilości zasobów
Centralne przygotowywanie danych wydruku na serwerze wymaga wi˛ecej RAM, lepszej CPU
oraz zajmuje wi˛ecej miejsca na twardym dysku (jego ilość można z góry określić, jeśli tylko
znana jest oczekiwana wielość wydruku.)
Niewielkie ograniczenia w przypadku obsługiwanych modelów drukarek
Wprawdzie wi˛ekszość stosowanych drukarek jest obsługiwana - jednakże istnieja˛ wyjatki.
˛
List˛e obsługiwanych modelów i producentów można znaleźć w bazie danych urzadzeń
˛
na stronie
http://Linuxprinting.org.
3.3.4.7
Architektury systemu drukowania
Poniżej nakreślone zostały potencjalne architektury wykorzystywane wraz z CUPS, przy czym
przy wyborze różnych scenariuszy stosowania decydujace
˛ znaczenie odegrało uzyskanie zwi˛ekszonej stabilności:
◦ Serwer:
Każdy komputer z CUPS komunikujacy
˛ si˛e bezpośrednio z drukarka,
˛ może oferować funkcje
wydruku innym komputerom jako usług˛e, co znaczy, że może on być serwerem CUPS. W tym
celu wymagane sa˛ odpowiednie PPDs oraz filtry służace
˛ do właściwego przygotowywania plików do druku.
◦ Klient:
Każdy komputer, który przesyła dane wydruku do serwera, jest klientem CUPS. Klient CUPS nie
potrzebuje, lokalnie, filtrów ani PPDs. Jeśli jednak na kliencie maja˛ być ustalane opcje wydruku,
wówczas PPDs sa˛ automatycznie wysyłane z serwera na klienta.
◦ Zero administration dla natywnych klientów CUPS:
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˛ korzystać.
Powyższe informacje przesyłane sa˛ za pomoca˛ UPD-Broadcasting. Alternatywnie klient może
wysyłać konkretne zapytania do serwerów (Polling). Polling może być także stosowany przez
serwery, które sa˛ oddzielone za pomoca˛ Routera. Serwery, które znajduja˛ si˛e w różnych sieciach,
można skonfigurować jako BrowseRelay i pobierać dane o dost˛epnych drukarkach, a nast˛epnie
przesyłać je dalej do klientów własnej domeny Broadcast.
◦ Clustering - zapewnienie ciagłości
˛
pracy i ochrona przed Failover:
Dwa albo wi˛ecej serwerów CUPS można skonfigurować w taki sposób, aby zapewnić ciagłość
˛
pracy usług wydruku.
Cel ten można osiagn
˛ ać
˛ 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˛ można także ustawić r˛ecznie przez stworzenie odpowiednich klas,
przy czym klasy można wówczas utworzyć także z drukarek majacych
˛
różne nazwy.
3.3.5.1
Windows 2000
˛
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 poniżej:
◦ Standard TCP/IP Port Monitor
◦ Internet Printing
◦ Publikowanie w Active Directory
W kolejnych paragrafach znaleźć można szerszy opis wprowadzonych zmian.
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 możliwość uzyskiwania szczegółowych informacji o stanie.
SPM może korzystać z dwóch różnych protokołów serwerów wydruku: RAW albo LPR.
Standardem dla wi˛ekszości drukarek jest RAW.
Publikowanie w Active Directory
Za pomoca˛ Active Directory można udost˛epniać zasób - drukark˛e (na serwerach Windows NT
albo 2000) w taki sposób, że użytkownik nie wie, na którym serwerze zasób ten si˛e znajduje.
Użytkownik może po prostu wydać polecenie przeszukiwania AD.
Internet Printing
Wraz z Windows 2000 wprowadzono opcj˛e umożliwiajac
˛ a˛ publikowanie i instalowanie drukarek w sieci WWW.
Środowiska mieszane
Na serwerach Windows NT nie można składować sterowników dla klientów Windows 2000
albo XP. W takich środowiskach sterowniki musza˛ być instalowane oddzielnie.
Na serwerach Windows 2000 można składować sterowniki dla klientów Windows NT. Jednak
transmisja ustawień danego urzadzenia
˛
może skończyć si˛e niepowodzeniem w sytuacji, gdy korzysta si˛e (trzeba skorzystać) ze sterowników dostarczanych przez producenta urzadzenia.
˛
Przyczyna˛ tego jest przejś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 nowości odróżniajace
˛ Print Services z Windows 2003 od tych z Windows 2000.
3.4 Autoryzacja
3.4.1 Przeglad
˛
Poniższe oceny techniczne prowadza˛ do wniosku, że zarówno w przypadku migracji kontynuacyjnej, jak i zast˛epujacej
˛ oraz w środowiskach heterogenicznych możliwe jest zapewnienie bez-
113
piecznej autoryzacji uż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 środowisku systemów
mieszanych podobna˛ funkcjonalność, jak w przypadku głównego kontrolera domeny opartego
na NT. Samba, b˛edac
˛ baza˛ danych kont użytkowników, może korzystać z Open LDAP jako
usługi katalogowej. Z punktu widzenia klientów windowsowych, Samba wraz z OpenLDAP
pełni funkcj˛e domeny Windows NT. Jeśli chodzi o administrowanie informacjami o grupach,
hostach i użytkownikach Samba realizuje rozwiazanie
˛
oparte na usługach katalogowych wraz
ze wszystkimi wynikajacymi
˛
z tego zaletami. Na przykład w przypadku wykorzystania powyższego rozwiazania,
˛
przestaje istnieć problem skalowalności znany z Windows NT, który cz˛esto
wymaga podziału infrastruktury pomi˛edzy różne domeny.
Za pomoca˛ Samby można ustalać stopień zaufania pomi˛edzy różnymi domenami. Możliwe jest także stosowanie WINS-Service. Samba 3.0 udost˛epnia program służacy
˛ do replikacji
WINS. Program ten nie został jeszcze w pełni przetestowany. Aby zachować kompatybilności
Samba obsługuje rozwiazanie
˛
oparte na PDC i BDCs. Jednak obsługa powyższych ogranicza si˛e
do tego, że serwer Samba widziany jest przez klientów windowsowych, w zależności od konfiguracji, jako PDC badź
˛ BDC. Sam Samba nie obsługuje replikacji bazy danych SAM pomi˛edzy
PDC i BDC. Jednakże, ze wzgl˛edu na zapisywanie SAM w katalogu LDAP, replikacja SAM
może być realizowana przez OpenLDAP.
W przypadku migracji kontynuacyjnej, autoryzacja w środowiskach systemów mieszanych
nie podlega ograniczeniom. Istnieja˛ one na styku technologii Samba / OpenLDAP - Active Directory oraz Samba / OpenLDAP - autoryzacja Kerberos.
Należy przy tym podkreślić, że nie jest możliwe wykonanie autoryzacji Kerberos z klientów
Windows 2000/XP do Samby / OpenLDAP, lecz trzeba w takim przypadku skorzystać z protokołu NTLM. Dopóki Microsoft b˛edzie wspierał powyższe rozwiazanie
˛
umożliwiajace
˛ klientom
windowsowym wspomniana˛ integracj˛e, zapewnienie jej nie b˛edzie stanowić problemu. Rozwia˛
zaniu temu można przeciwstawić współprac˛e linuksowego serwera Kerberos z domena˛ Active
Directory, dzi˛eki czemu można, na bazie Linuksa, stworzyć jednolity Credential-Management
dla Windows i Linuksa.
W środowisku opartym wyłacznie
˛
o Linuksa można stosować autoryzacje Kerberos. Alternatywnie można także realizować autoryzacj˛e za pomoca˛ OpenLDAP.
114
3.4.2 Punkt wyjś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 użytkowników
◦ integracja komputerów i usług sieciowych
◦ autoryzacja
W tym celu należy najpierw przeanalizować, pod katem
˛
usług zgłoszeniowych, techniczne podstawy ś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
używanej bazy danych skupia, w jednym kontekście bezpieczeństwa, konta uż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 użytkowników i komputerów w
SAM odbywa si˛e także zarzadzanie
˛
grupami. Każdy z tych trzech typów obiektów można jednoznacznie opisać tak zwanym SIDem (Security Identifier), który nie powinien być niepowtarzalny
dla wszystkich domen. Każ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 użycie niektórych znaków specjalnych). SAM-Accountname jest nazwa,˛
której użytkownicy używaja˛ do identyfikacji.
Komputery oparte o:
◦ Windows NT
◦ Windows 2000
◦ Windows XP
moga˛ być członkiem jednej domeny. W przeciwieństwie do tego dla systemów takich jak, np.
Windows 3.11 albo 9x niemożliwe jest utworzenie konta komputera w domenie. Gdy komputer
staje członkiem domeny, wówczas w SAM komputera grupy domeny (globalne grupy) staja˛ sie
115
członkiem lokalnych grup komputera. Tak oto „przekształca si˛e“ grupa „użytkownik domeny“ w
członka lokalnej grupy „użytkownik“. W ten sposób, np. użytkownicy, którzy na komputerze z
NT moga˛ zalogować si˛e do domeny, uzyskuja˛ lokalny dost˛ep do zasobów używanego komputera.
Jedna domena wymaga przynajmniej jednego Domain Controller, tak zwanego PDC (Primary Domain Controller). Przechowuje on SAM domeny i tylko on może zmieniać zawartość
SAM. W celu rozłożenia obciażenia
˛
i redundancji, w SAM należy zastosować 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“ widać, jak na dłoni. Aby użytkownicy mogli korzystać z lokalnych zasobów albo zasobów znajdujacych
˛
si˛e w systemach sieciowych, nie trzeba
w każdym systemie zakładać konta użytkownika, lecz wystarczy tylko założenie konta użytkownika w SAM domeny. Ochrona zasobów, autoryzacja, realizowana jest oddzielnie na tych systemach, które je udost˛epniaja.˛ Użytkownicy korzystajacy
˛ z Windows 9x, również moga˛ logować
si˛e do domeny i tym samym wykorzystywać zasoby sieciowe bez konieczności dodatkowego
logowania.
3.4.2.2
Wiele domen i relacje zaufania
Istnieje możliwość łaczenia
˛
ze soba˛ wielu domen poprzez tzw. relacje zaufania. Dzi˛eki nim możliwa jest autoryzacja dost˛epu do zasobów (np. File Services) takich uż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 być dwukierunkowa (bidirektional); gdy
domena A ufa domenie B, to B nie musi ufać A. Relacje zaufanie nie sa˛ również przechodnie:
gdy A ufa B i B ufa C, wtedy A nie musi automatycznie ufać C. Jak widać każda relacja zaufania
musi być ustawiana osobno.
Poniższe okoliczności doprowadziły do ukształtowania si˛e sytemu wielu domen w środowiskach informatycznych:
◦ Cz˛esto powstawały równoległe rozwiazania
˛
- wysepki, wewnatrz
˛ jednej infrastruktury,
które później, wskutek wspólnych procesów roboczych, trzeba było łaczyć
˛
za pomoca˛
relacji zaufania. Dotyczy to także sytuacji, w której trzeba połaczyć
˛
dwie infrastruktury.
◦ Granice domen sa˛ granicami bezpieczeństwa: administratorzy domeny A nie sa˛ automatycznie administratorami domeny B, której si˛e ufa albo która komuś ufa. Lepsza polityka
nie odgrywa tu żadnej roli.
116
◦ Możliwość delegowania zadań, która nie ma zalet, została skompensowana przez zastosowanie wielu domen.
◦ Ilość obiektów (komputery, użytkownicy, grupy) w SAM jest ograniczona gdyż SAM przechowywane sa˛ podczas pracy w Registry kontrolerów domeny, których wielkość także
jest ograniczona. Jedynym sposobem obejścia powyższego ograniczenia jest rozproszenie
obiektów pomi˛edzy wiele domen.
◦ Skalowanie domeny w silnie rozproszonych, zdecentralizowanych środowiskach ograniczone jest przez Single Master z PDC, ponieważ wszystkie zmiany w SAM moga˛ być
realizowane tylko przez niego.
Powyższe fakty doprowadziły do powstania różnych modeli domen, które mi˛edzy innymi zaproponował sam Microsoft:
◦ Single Domain (jedna domena)
◦ Master Domain (wiele domen, z których każ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 (każda domena ufa innym domenom)
3.4.2.3
NT jako usługa katalogowa
W szerokim sensie domeny Windows NT sa˛ również usługami katalogowymi, ponieważ obiekty
użytkownika zapisane sa˛ w jednej domenie. Microsoft nazwał taki system NTDS (Windows NT
Directory Service).
Ilość atrybutów obiektu użytkownika w domenie NT jest wzgl˛ednie mała i ogranicza si˛e
raczej do atrybutów oraz właściwości ważnych z technicznego punktu widzenia. Z tego powodu
atrybutów tych nie można porównywać z usługa˛ katalogowa˛ w oparciu o X.500.
Właściwości użytkownika obejmuja˛ mi˛edzy innymi:
◦ nazw˛e użytkownika (SAM-Accountname)
◦ pełna˛ nazw˛e i opis (nieważne z technicznego punktu widzenia)
◦ informacj˛e o koncie (np. konto dezaktywowane, hasło nigdy nie wygasa, termin wygaśni˛ecia konta, typ konta)
117
◦ członkostwa grup
◦ parametry środowiska (skrypty logowania, katalog domowy, ścież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łaściwości dla obiektu użytkownika (dodatkowe home paths i profile paths oraz
inne parametry Citrix).
NTDS nie może mieć struktury hierarchicznej. Nadawanie uprawnień na poziomie atrybutów
nie jest możliwe, a elastyczne nadawanie uprawnień obiektom użytkownika jest mocno ograniczone.
3.4.2.4
Delegation
Przydzielanie zadań administracyjnych wewnatrz
˛ domeny NT zredukowane jest do:
◦ korzystania z wbudowanych (Built-In) grup (domen - administratorów, operatorów kont,
serwerów, zabezpieczania danych, wydruku i reprodukcji); jest to jednak wariant bardzo
mało elastyczny.
◦ instalacji dodatkowych domen
Powyższe restrykcje, wzgl˛ednie wady, zapewne doprowadziły do tego, że przydzielanie ról oraz
ich istniejacy
˛ podział odwzorowane sa˛ na aplikacjach opartych na sieci WWW.
3.4.2.5
118
Podstawy sieci
Domena Windows NT może opierać si˛e na nast˛epujacych
˛
protokołach transportu
◦ TCP / IP
◦ NetBEUI
◦ SPX / IPX.
W każdym przypadku wymagany jest interfejs NetBIOS.
W sieciach TCP / IP, które dla potrzeb niniejszego poradnika określiliśmy jako standardowe,
do zapewnienia bezbł˛ednej komunikacji konieczne jest przekształcanie nazw NetBIOS (nazwa
komputera oraz nazwy użytkowników i nazwy innego typu, takie jak grupa robocza). Jeśli, np.
użytkownik chce zmienić swoje hasło w domenie, to musi on znać położenie PDC badź
˛ swój
adres IP.
Przekształcanie nazw NetBIOS może być realizowana w sieciach windowsowych na róż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 umożliwia realizacj˛e przekształcanie nazw przez podsieci IP, dynamiczne zawartoś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) niezależnie od wybranego protokołu transportu. Teoretycznie może ona połaczyć
˛
(home)
wszystkie systemy operacyjne typu Windows. Usługa ta umożliwia przesłanie klientowi wysyłajacemu
˛
pytanie (np. za pomoca˛ polecenia „net view“) list˛e aktywnych komputerów znajdujacych
˛
si˛e w sieci. Jeśli ma ona obejmować także komputery z podsieci IP, wówczas powyższa usługa
musi mieć dost˛ep do informacji z „Domain Master Browser“ w sieci lokalnej, co jest możliwe
po zastosowaniu WINS.
3.4.2.6
119
Replikacja plików
Kontrolery domen (PDC, jak też BDCs) udost˛epniaja˛ skrypty logowania i ustawienia systemowe
w postaci zasobu NETLOGON, które sa˛ odpytywane przez logujacych
˛
si˛e użytkowników.
Aby użytkownik mógł otrzymać za każdym razem te same warunki, zawartość w/w zasobu
powinna być jednakowa dla wszystkich kontrolerów domen w domenie.
W tym celu serwery musza˛ wymieniać si˛e informacjami. Tak zwana usługa katalogowej replikacji (LMRepl) zapewnia replikowanie zawartości serwerów eksportujacych
˛
do serwerów importujacych.
˛
Zmiany zawartości moga˛ być przeprowadzane tylko na serwerze eksportujacym.
˛
3.4.2.7
Narz˛edzia administracyjne
Do administrowania obiektami użytkownika, grupami i komputerami, w Windows NT 4 udost˛epniane sa˛ programy graficzne takie jak menedżer użytkownika menedżer serwera.
Ponadto wraz z „NT Resource Kit“ dostarczane sa˛ narz˛edzia, które przeważnie można uruchamiać z linii poleceń i z pomoca˛ których można stworzyć skrypty służace
˛ do automatycznej
administrowania.
Ponadto istnieje możliwość zarzadzania
˛
domena˛ takż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óźniej wyprodukował jeszcze Microsoft Management Console
(MMC), która została ostatecznie właczona
˛
do Windows 2000.
Także później Microsoft dostarczył wraz z ADSI (Active Directory Service Interface) interfejs oparty o COM, za pomoca˛ którego można administrować również domenami Windows
NT.
3.4.2.8
Zapisywanie haseł
Hasła użytkownika (także komputerów) zapisywane sa˛ w jednej domenie w SAM kontrolerów
domeny. Zapisywane hasło nie jest zapisywane otwartym tekstem, lecz jako wartość hash. W
Windows NT można dodatkowo również szyfrować SAM (SYSKEY.EXE). Wartości hash haseł
tworzone sa˛ różnymi metodami, które rozwin˛eły si˛e zgodnie z poniższym opisem:
◦ LM (LAN Manager)
◦ NTLM
120
◦ NTLMv2
Na systemach NT, które nie sa˛ kontrolerem domen, informacje o użytkownikach logujacych
˛
si˛e
na końcu sa˛ tymczasowo zapisywane do katalogu, co ma umożliwić logowanie także wtedy,
gdy kontroler domen nie jest dost˛epny (typowe dla notebooków). Informacje te sa˛ nast˛epnie
ponownie zapisywane jako wartość hash.
3.4.2.9
Mechanizm autoryzacji
Autoryzacja w obr˛ebie środowiska domen NT opiera si˛e na mechanizmie NTLM.
Ocenialiśmy nast˛epujacy
˛ scenariusz. Domena zasobów ufa domenie kont. Istnieje działajace
˛
środowisko WINS. Użytkownik uruchamia stacj˛e robocza˛ Windows NT, która jest członkiem
domeny zasobów. Nast˛epnie loguje si˛e do domeny kont. Powyższy scenariusz zilustrowany został na rysunku 3.6.
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. Jeś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“.
122
Na końcu maszyna NT wysyła pytanie do DC domeny zasobów o list˛e zaufanych domen.
Po wybraniu przez użytkownika domeny kont z maski logowania oraz podaniu przez niego
swojego identyfikatora i hasła, uruchamiany jest proces logowania konta uż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 bezpośrednie połaczenie
˛
z DC domeny kont, aby załadować skrypt
logowania, ustawienia systemowe albo profil użytkownika.
Jako uzupełnienie należy jeszcze ocenić nast˛epujacy
˛ proces logowania. Gdy uż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 sprawdzić informacje logowania kontaktujac
˛ si˛e ponownie z kontrolerami domen.
3.4.2.10
Single Sign On
Rozwiazanie
˛
oparte o domeny zastosowane w Windows NT umożliwia coś w rodzaju Single
Sign On (jednorazowe logowanie) w ramach palety produktów Microsoft. Użytkownik loguje
si˛e jeden raz na swojej stacji roboczej z Windows NT i nast˛epnie uzyskuje dost˛ep, o ile zasoby
badź
˛ 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˛ implementować swoje produkty w taki sposób, że zachowana zostanie możliwość jednorazowego logowania. Z reguły jednak musza˛ oni udost˛epniać
swoje aplikacje na serwerach Windows NT4, które sa˛ członkami domeny.
3.4.2.11
Wytyczne
W domenach Windows NT można zrezygnować z wytycznych mówiacych
˛
o tym,
◦ jak obchodzić si˛e z hasłami (czas ważności, minimalna długość, powtarzane, bł˛edne wprowadzenie hasła)
123
◦ jakie przywileje (uprawnienia użytkownika) powinni posiadać użytkownicy lub grupy (zmiana
czasu systemowego, lokalne logowanie, etc.)
3.4.2.12
Auditing
W domenach Windows NT można właczyć
˛
Auditing (kontrol˛e) uzyskanego dost˛epu, wzgl˛ednie
podj˛etych prób uzyskania dost˛epu. W ten sposób można nadzorować, np.
◦ logowanie i wylogowywanie si˛e
◦ korzystanie z uprawnień użytkownika
◦ administrowanie użytkownikami i grupami
◦ zmiany wytycznych bezpieczeń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˛ tworzyć aplikacje windowsowe z obsługa˛ Smart Card.
Rozwiazania
˛
umożliwiajace
˛ mocna˛ autoryzacj˛e oferowane sa˛ przez innych producentów.
˛ - Linux, Samba i OpenLDAP
Przy ocenianiu migracji zast˛epujacej
˛ należy uwzgl˛ednić przede wszystkim także wymagania co
do sposobu autoryzacji w środowiskach mieszanych złożonych z systemów Linux i Windows.
W zwiazku
˛
z tym na pierwszy plan wysuwa si˛e oczywiście wykorzystanie usługi katalogowej,
także w aspekcie Active Directory poczawszy
˛
od Windows 2000. Poza tym kombinacja Linuksa,
Samby i OpenLDAP obroniła si˛e jako metoda autoryzacji już wielokrotnie, na długo przed powstaniem Active Directory. Dlatego przejrzysta, oddzielna ocena usługi katalogowej jako usługi
integrujacej
˛ i jako cz˛eści usługi autoryzacji jest prawie niemożliwa. (Obszerna informacja na ten
temat znajduje si˛e w rozdziale 3.7).
3.4.3.1
124
Autoryzacja z wykorzystaniem Linux / OpenLDAP i Samby
Samba zapewnia klientom windowsowym podobna˛ funkcjonalność jak główny kontroler domen
oparty na Windows NT (m.in. File Services, Print Services oraz usługi autoryzacji). Samba, jako
baza danych kont użytkowników, może przy tym odwoływać si˛e do OpenLDAP ś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 jeśliby spojrzeć pod katem
˛
administrowania informacjami o użytkownikach, grupach i hostach, chodzi o kompletne rozwiazanie
˛
oparte na usłudze katalogowej
wraz ze wszystkimi wynikajacymi
˛
z tego zaletami. W szczególności w przypadku rozwiazania
˛
opartego o Samb˛e i OpenLDAP przestaje istnieć, znany z Windows NT, problem skalowalności,
który cz˛esto wymaga podziału infrastruktury pomi˛edzy róż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˛ być zapisane te same zaszyfrowane hasła, jak w bazie danych SAM
w Windows NT/2000/2003. Dzi˛eki temu jakościowemu ograniczeniu (brak autoryzacji Kerberos
dla klientów Windows 2000 / XP) możliwe jest zbudowanie pełnowartościowej usługi autoryzacji dla klientów windowsowych w oparciu o Linuksa, OpenLDAP i Samb˛e.
Problemem wydaje si˛e tu być używanie przez Linuksa innego algorytmu do szyfrowania
haseł niż ma ten stosowanych w Windows NT / 2000. Z tego powodu w przypadku stosowania rozwiazania
˛
opartego na OpenLDAP i Sambie konieczne jest zapisanie haseł uniksowych
oraz windowsowych obok siebie w katalogu LDAP i ich zsynchronizowanie. Z technicznego
punktu widzenia nie jest to żaden problem, ponieważ istnieje możliwość takiego skonfigurowania Samby, żeby podczas zmiany hasła przez klienta windowsowego, automatycznie zmieniane
była także hasło uniksowe. Powyższa zasada obowiazuje
˛
także w odwrotnym kierunku, tzn. za
pomoca˛ mechanizmu PAM (Pluggable Authentication Module) istnieje możliwość takiego ustawienia programów uniksowych, żeby mogły one zmieniać 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 może być realizowana, podobnie jak w przypadku Active Directory, poprzez Kerberos. Służa˛ do tego dwie równorz˛edne implementuje Kerberos dla Linuksa, tj. „MIT Kerberos“ oraz „Heimdal“. Również w przypadku korzystania z
Kerberos synchronizacj˛e hasła można zagwarantować za pomoca˛ wyżej wymienionych mechani-
125
zmów. (Podobna metoda synchronizacji hasła musi być także wykorzystywana wewnatrz
˛ Active
Directory, aby zagwarantować logowanie zarówno poprzez Kerberos, jak i logowanie starszych
klientów poprzez NTLM).
3.4.3.3
Relacje zaufania
Samba 3.0 obsługuje relacje zaufania znane z Windows NT. Można je ustawiać zarówno pomi˛edzy domenami Windows i Samby, jak też 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łużacy
˛ do
replikacji WINS. Program ten nie został jednak na razie wystarczajaco
˛ przetestowany.
3.4.3.5
Ograniczenia w stosowaniu OpenLDAP i Samby
Jak już wspomnieliśmy, Samba odpowiada, z punktu widzenia klienta windowsowego, serwerowi opartemu na Windows NT. Oznacza to, że nie obsługuje ona nowych właściwości zwiaza˛
nych z administrowaniem klientami windowsowymi, które zostały wprowadzone wraz z Active
Directory. W szczególnoś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 możliwe jest definiowanie ustawień rejestrów dla użytkownika, grup użytkowników i komputerów klientów. Poprzez System
Policies można również zadać wi˛ekszość ustawień dost˛epnych za pomoca˛ GPOs (ograniczenia
funkcji interfejsu użytkownika Windows, wybór programów wykonywalnych, itd.). Dzi˛eki narz˛edziu „editreg“ dostarczanemu wraz z Samba˛ możliwe jest dynamiczne definiowanie ustawień
systemowych.
Ponadto w środowisku opartym na Sambie można używać lokalnych Policies, które zasadniczo umożliwiaja˛ uzyskanie takich samych ustawień, jak z GPOs. Ponieważ lokalne Policies
składowane sa˛ po prostu w systemie plików, można je, po stworzeniu prototypu, w łatwy sposób
zsynchronizować z duża˛ ilościa˛ klientów.
126
Wymiana oprogramowania
Funkcje oferowane przez Active Directory, a umoż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˛eściej rozwiazanie
˛
polegajace
˛ na szerokiej wymianie oprogramowania. W tym celu można
skorzystać z całego szeregu rozwiazań
˛
komercyjnych, które działaja˛ również bez Active Directory, a nawet cz˛esto wykorzystuja˛ Linuksa, jako podstawowy system operacyjny.
Samba obsługuje profile oparte na serwerze. Dzi˛eki temu możliwe jest ustawienie także profilów obowiazkowych,
˛
za pomoca˛ których można zdefiniować konfiguracj˛e interfejsu użytkownika oraz przypisać aplikacje poszczególnym użytkownikom.
Za pomoca˛ skryptów logowania, na klientach windowsowych można zdefiniować cały szereg
innych ustawień, np. dla hostów, grup oraz użytkowników.
3.4.3.6
Kombinacja OpenLDAP i Active Directory
Tam, gdzie nie można zrezygnować z Features oferowanych przez Active Directory, istnieje
możliwość replikacji danych użytkowników i grup z OpenLDAP do Active Directory. Użytkownikami i grupami trzeba wówczas nadal zajmować si˛e w katalogu OpenLDAP, ale można z nich
korzystać także w ramach Active Directory, co sprawia, że wykorzystywane moga˛ być odpowiednie właściwości (takie jak GPOs) przy jednoczesnym administrowaniu z jednego miejsca
(Single - Point - of - Administration). Windows może być przy tym skonfigurowany w taki sposób, żeby dla obu cz˛eści środowiska wykorzystywany był wspólny (oparty na Linuksie) serwer
Kerberos. Wiaże
˛ si˛e to jednak z ograniczeniami, które polegaja˛ na tym, że nie b˛edzie już możliwa
autoryzacja przez Active Directory / Kerberos systemów opartych na Windows 94/98/NT.
3.4.3.7
Narz˛edzia umożliwiajace
˛ migracj˛e z Windows NT do Samby / OpenLDAP
Za pomoca˛ narz˛edzi, w które wyposażona jest Samba, możliwe jest sczytanie bazy danych
użytkowników dost˛epnego, opartego na Windows, kontrolera domen i zapisanie jej do katalogu
OpenLDAP. Dzi˛eki takiemu post˛epowaniu migracja może być całkowicie przejrzysta dla użytkowników oraz systemów klienckich; nie ma konieczności wprowadzania klientów od nowa do
tworzonej domeny, a użytkownicy moga˛ nadal używać wykorzystywana˛ w NT par˛e login / hasło.
Podczas migracji należy najpierw usunać
˛ wszystkie usługi z kontrolerów domen, za wyjatkiem
˛
autoryzacji i przejść na Member-Servers. W nast˛epnym kroku można wykonać migracj˛e kontrolerów domen opartych na Windows NT na Samb˛e / OpenLDAP. W czasie migracji
można dalej używać windowsowych Member-Servers, teraz już w domenie opartej na rozwiaza˛
niu Samba / OpenLDAP i powoli przechodzić na Samb˛e.
3.4.3.8
127
PDC i BDCs w jednej domenie Samby
Aby zachować kompatybilność z domenami Windows NT, Samba obsługuje także PDC i BDCs.
Jednak obsługa powyższych ogranicza si˛e do tego, że serwer Samba widziany jest przez klientów
windowsowych, w zależności od konfiguracji, jako PDC badź
˛ BDC. Sam Samba nie obsługuje
replikacji bazy danych SAM pomi˛edzy PDC i BDC. Jednakże ze wzgl˛edu na zapisywanie SAM
w katalogu LDAP, replikacja SAM może być realizowana przez OpenLDAP. Serwer Samba
skonfigurowany jako PDC posiada przy tym zazwyczaj prawo do zapisu na OpenLDAP-MasterServer, dzi˛eki czemu może on zmieniać wpisy w bazie danych użytkowników. BDCs należy
skonfigurować w taki sposób, ż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. Jeś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 także one b˛eda˛ mogły korzystać ze zmienionej bazy danych.
Ponadto w domenie Windows NT synchronicznie przechowywana jest zawartość NetlogonShares (na którym znajduja˛ si˛e m.in. Policies i skrypty logowania). W Linuksie można to zrealizować, np. za pomoca˛ programu rsync.
3.4.3.9
Samba jako członek domeny Active Directory
Oprócz tego Samba jest w stanie używać do autoryzacji, tzw. Kerberos-Tickets serwera Active
Directory. Oznacza to, że Samba, jako pełnowartościowy Member-Server, może być stosowana
w domenach AD.
3.4.3.10
Użytkownikami i grupami w domenie opartej na systemie Samba / OpenLDAP można administrować za pomoca˛ narz˛edzi dostarczanych przez Windows NT (usrmgr.exe). Jednak w takim
przypadku nie można wykorzystać wszystkich szczególnych zalet rozwiazania
˛
opartego na usłudze katalogowej (np. różnych poziomów uprawnień, zagnieżdżonej struktury katalogów), ponieważ nie sa˛ one obsługiwane przez Features z Windows NT. Narz˛edzia do zarzadzania
˛
OpenLDAP opisane zostały w rozdziale 3.7.4.7.
128
3.4.4.1
Windows 2000
Jeśli chodzi o usług˛e logowania, nie można przyjać,
˛ ż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 także z zasadnicza˛ zmiana˛ architektury
w postaci „Active Directory Service“.
W tym miejscu poradnika postanowiliśmy nie przedstawiać usługi logowania z Windows
2000 jako osobnego tematu bez uwzgl˛ednienia Active Directory oraz usługi katalogowej. Podobne problemy wyst˛epuja,˛ jeśli chodzi o jasne rozgraniczenie Active Directory jako usługi infrastrukturalnej od Active Directory jako składnika usługi autoryzacji. W zwiazku
˛
z tym postanowiliśmy odesłać czytelnika do rozdziału 3.7.5, w którym opisaliśmy nast˛epc˛e Windows 2000,
tj. Windows Server 2003.
3.5 Usługi sieciowe
3.5.1 Przeglad
˛
W wyniku przedstawionych poniżej, szczegółowych ocen technicznych, doszliśmy do wniosku,
że w przypadku w/w usług nie ma problemów z przeprowadzeniem migracji. Nie należy si˛e
ich spodziewać ani w środowisku systemów mieszanych, ani też w środowisku homogenicznym
(całkowita „zast˛epujaca
˛ migracja“ lub migracja kontynuacyjna).
3.5.2 Punkt wyjścia - usługi sieciowe pod Windows NT
W niniejszym podrozdziale przeanalizowaliśmy nast˛epujace
˛ usługi sieciowe:
◦ WINS
◦ DNS
◦ DHCP
Tam, gdzie było to konieczne zaakcentowaliśmy różnice pomi˛edzy serwerami, a klientami.
W szerszym sensie do usług sieciowych można zaliczyć także poniższe usługi:
◦ RAS (Remote Access Service) i Routing
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 zamieściliśmy poniżej krótka˛ analiz˛e nowoś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˛ można zainstalować w systemie
operacyjnym Windows NT 4 Server.
WINS jest usługa˛ zgodna˛ z RFC, umożliwiajac
˛ a˛ przekształcanie nazw NetBIOS na adres IP
i jednocześnie serwerem, który za pomoca˛
◦ Broadcast
oraz
◦ lokalnie zapisanego pliku LMHOSTS
sprawia, że przekształcanie nazw staje si˛e zb˛edne.
WINS umożliwia tym samym przekształcanie nazw NetBIOS poprzez podsieci IP na zewnatrz.
˛
WINS można używać zarówno dynamicznie, jak i statycznie. Pierwszy sposób oznacza, że
klienty WINS moga˛ si˛e same dynamicznie dopisywać. Metoda statyczna polega na tym, że administratorzy musza˛ wpisywać nazwy oraz adresy IP każdego z nich r˛ecznie.
WINS zapisuje swoje dane w bazie danych (Jet - Engine, wins.mdb), której zawartość może
ze soba˛ synchronizować wiele serwerów WINS. W tym celu serwery WINS należy skonfigurować jako tzw. „Push - Partner“ i / lub Pull - Partner“. Zawartość zapisywana jest zgodnie z zasada˛
Multi-Master, co oznacza, że każdy serwer WINS może dokonywać wpisów.
Dodatkowo istnieje możliwość 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łnowartościowego serwera WINS.
Wszystkie dotychczasowe systemy operacyjne Windows (Windows 9x do Windows XP oraz
wszystkie serwerowe systemy operacyjne) moga˛ być klientami WINS. Samego klienta WINS
130
można skonfigurować na podstawie jego, tzw. typu w˛ezła, tak by wiedział czy i jak powinien
przekształcać nazwy NetBIOS.
Przestrzeń nazw NetBIOS jest płaska i ogranicza si˛e tylko do nazw komputerów. Obejmuje
ona także nazwy użytkowników, usługi, nazwy domen Windows albo windowsowych grup roboczych, etc.
Poniższa tabela pokazuje przeglad
˛ typów nazw NetBIOS, które można identyfikować na podstawie 16 bajtowej nazwy NetBIOS.
Należy rozróżnić nazwy jednoznaczne (unikalne) i nazwy grup. Te ostatnie moga˛ być używane jednocześ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 uż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 ważne w przypadku zasobów katalogowych).
<21>
komputer z klientem RAS.
<BE>
agenta monitorujacego
˛
sieć (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˛ być wykorzystywane przez wiele komputerów.
16
BAJTÓW
<1C>
OZNACZA WIELOWARTO ŚCIOWO
nazw˛e domeny.
<1D>
nazw˛e Master Browser.
<1E>
zwyczajna˛ nazw˛e grup.
<20>
specjalna˛ nazw˛e grup (zwana˛ Internet group).
131
że zamiast jednych 16 bajtów, możliwe jest przyłaczenie
˛
„_MSBROWSE_,“ do nazwy domeny w celu wskazania domeny innym Master Browser.
Tablica 3.20: Wielowartościowe oznaczenia nazw NetBIOS
3.5.2.2
Domain Name System (DNS)
Domain Name System (DNS) jest usługa,˛ która˛ można zainstalować na serwerze Windows NT
4. Obsługuje ona RFCs 1033, 1034, 1035, 1101, 1123, 1183 i 1536 i jest kompatybilna z implementacja˛ Berkeley Internet Name Domain (BIND).
DNS z serwera Windows NT 4 obsługuje BIND w wersji 4.9.4.
DNS jest standardem sieci Internet, który umożliwia m.in. przekształcanie, wewnatrz
˛ hierarchicznej przestrzeni nazw, nazw komputerów na adres IP i odwrotnie (Reverse Lookup). Zastosowanie serwera DNS sprawia, że użycie lokalnych wpisów w pliku HOSTS staje si˛e zb˛edne.
W hierarchii przestrzeni nazw można zorientować si˛e dzi˛eki znakowi rozdzielajacemu
˛
„.“
używanemu podczas zapisywaniu nazw. Tak zwana w pełni kwalifikowana nazwa (Fully Qualified Domain Name, FQDN) składa si˛e z dwóch cz˛eści. Pierwsza cz˛eść kończy si˛e na pierwszej kropce i oznacza nazw˛e hosta, a druga cz˛eść 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˛eści. Znaki, które można stosować w FQDN należa˛
do przedziału od a do z, A do Z oraz znak „–“.
Ponieważ DNS jest standardem sieci Internet, nie wolno stosować dowolnych nazw domen.
Domeny musza˛ być zarejestrowane w aktualnych narodowych i mi˛edzynarodowych rejestrach.
Jednak, jeśli przestrzeń nazw DNS widoczna jest tylko wewnatrz
˛ własnej organizacji (przedsi˛ebiorstwa), wówczas można stosować także niezarejestrowane nazwy. Korzystać należy z takich
zarejestrowanych nazw badź
˛ stref, które nie sa˛ wykorzystywane w Internecie. W ten sposób
unika si˛e stosowania stref należacych
˛
do innych organizacji badź
˛ osób.
DNS posiada mechanizmy, które umożliwiaja˛ partycjonowanie podstawowej bazy danych
oraz dopasowanie jej do dzielonych środowisk. Z jednej strony przekształcanie nazw można
132
przypisać do konkretnych domen, a z drugiej poprzez utworzenie stref możliwe jest sterowanie
replikacja˛ (transfer stref) oraz sterowanie administrowaniem.
Implementacja w Windows NT 4 jest zgodna z BIND 4.9.4 w takim stopniu, że DNS pracuje
wyłacznie
˛
statycznie (czyli nie obsługuje dynamicznych wpisów), a zmiany moga˛ być wprowadzane tylko na pierwszym serwerze strefy (zasada Single Master).
Szczególna˛ cecha˛ implementacji DNS w Windows NT 4 jest to, że można sprawić, by usługa
ta dodatkowo wymusiła przydzielanie nazw na serwerze WINS.
Oprócz zarzadzania
˛
wpisami nazw komputerów, DNS obsługuje jeszcze inne rodzaje wpisów
(resource records). Poniż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 przypisać 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.
133
SOA
wpis dla pierwszego serwera DNS (start of authority)
TXT
wpis dla informacji tekstowych
wpis dla adresu IP serwerów WINS, które maja˛ być dodat-
WINS
kowo
wykorzystane do przekształcania nazw (forward resolution)
WINS_R
wpis dla Reverse Lookup via serwer WINS
WKS
wpis dla well-known service
X.25
wpis dla adresu X. 121
Tablica 3.22: Przeglad
˛ obsługiwanych typów DNS Resource Record
Wszystkie dotychczasowe systemy operacyjne Windows (Windows 9x do Windows XP oraz
wszystkie serwerowe systemy operacyjne) moga˛ być klientem DNS. Systemy oparte na Windows
2000 i nowszych wersjach tego sytemu obsługuja˛ jako klienty także dynamiczny DNS (DDNS),
który opisaliś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 urzadzeń
˛
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 poniż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
Wyjaśnienie
maska podsieci
adres IP standardowego routera (gateway)
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
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ł odświeżania 1
59
Rebinding (T2) time value
interwał odśwież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 możliwość uż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łnowartościowego serwera DHCP.
˛ - usługi sieciowe pod Linuksem
Usługi tworzace
˛ infrastruktur˛e sieci opartej na TCP / IP (DNS, DHCP, NTP, Routin, VPN, Filtering) można bez wyjatku
˛ realizować za pomoca˛ Wolnego Oprogramowania. Szeroka dost˛epność
w/w usług w postaci OSS wynika z historii rozwoju Internetu, który b˛edac
˛ ogólnoświatowa˛ siecia˛
umożliwiajac
˛ a˛ wymian˛e danych odznacza si˛e tym, ż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
˛
136
ogólna˛ nazw˛e TCP / IP. Aby komunikacja pomi˛edzy najróżniejszymi systemami mogła na całym
świecie przebiegać bez problemów, konieczne jest zgodne „rozumienie j˛ezyka“. Aby uzyskać t˛e
zgodność, wi˛ekszość 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,˛ niezależnie od siebie, rozwijać całkowicie kompatybilne oprogramowanie. Protokoły internetowe
same sa˛ niezależne od producentów, b˛edac
˛ jednocześ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óżnieniu si˛e TCP / IP na tle, dost˛epnych w tym samym
czasie na rynku, własnościowych protokołów sieciowych.
Zachowanie otwartych standardów ma zasadnicze znaczenie także wtedy, gdy z powodu
ograniczonej ilości stosowanych systemów możliwe jest, w sieci lokalnej, zorientowanie si˛e co
do wymagań odnośnie kompatybilności. Szczególnie w przypadku zmian dokonywanych przez
producenta, wzgl˛ednie rozszerzeń standardów, istnieje ciagła
˛ groźba „Vendor Lock-In“; z jednej strony przywiazanie
˛
do danego producenta staje si˛e uzależ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 należy za każdym razem sprawdzać, czy rozszerzenie standardu przez producenta zapewni obiecane korzyści także w dłuższej perspektywie. Mimo, że istniejace
˛ od długiego
czasu i sprawdzone implementacje referencji nie obsłuża˛ każdego Feature, oferuja˛ one gwarancj˛e
trwałej kompatybilnoś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 niezależnie od producenta przez Internet Software Consortium. Aktualna˛ jego wersja˛
jest 9.2.x, przy czym nadal istnieje i jest utrzymywana przez ISC gałaź
˛ 8.3.x, która˛ wykorzystuje
duża cz˛eść zainstalowanych serwerów DNS.
Bind 9 obsługuje mi˛edzy innymi dynamiczny DNS (DDNS), DNSSEC oraz IPv6.
Połaczenie
˛
BIND 9 z obcymi źródłami danych w celu zapewnienia informacji o strefach
możliwe jest z jednej strony poprzez obszerny BackEnd Database Interface, a z drugiej strony
istnieje dodatkowy, uproszczony interfejs (SDB), za pomoca˛ którego można realizować dost˛ep
wyłacznie
˛
do odczytu w oparciu o bazy danych LDAP albo SQL. Jednak połaczenia
˛
te same w
sobie nie sa˛ cz˛eścia˛ składowa˛ pakietu oprogramowania BIND. Istnieja˛ zatem, np. jeśli chodzi o
137
połaczenie
˛
LDAP, zarówno implementacje SDB, jak i predefiniowane klasy obiektów, za pomoca˛
których można realizować takie połaczenie.
˛
BIND z ISC może także pracować pod Windows NT / W2K. BIND obsługuje również dynamiczna˛ aktualizacj˛e Service - Records oraz może świadczyć odpowiednie usługi dla serwerów
W2K.
3.5.3.2
Dynamic Host Configuration Protocol (DHCP)
ISC rozwija i opiekuje si˛e także implementacjami referencji DHCP. Protokół i oprogramowanie
maja˛ nast˛epujace
˛ zadania badź
˛ możliwoś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 też dynamiczne przydzielanie wolnego adresu z określonego zakresu adresów.
◦ automatyczne przekazywanie informacji o infrastrukturze sieci. Na przykład poprzez DHCP
można centralnie zarzadzać
˛
i rozdzielać pomi˛edzy wszystkich klientów domen˛e nazw, serwer nazw, Default - Route oraz mask˛e sieci.
◦ Oprócz tego możliwe jest dostarczanie przez dhcpd dużej ilości zdefiniowanych na stałe,
opcjonalnych pól oraz dajacych
˛
si˛e dowolnie definiować informacji dotyczacych
˛
konfiguracji hosta. DHCPD z ISC może, mi˛edzy innymi, przekazywać wszystkie opcje, które
moga˛ być wykorzystane po stronie klientów windowsowych.
◦ Dodatkowo DHCPD może także pełnić rol˛e BOOTPD i przekazywać do klienta wszystkie
informacje wymagane w przypadku bootowania poprzez sieć.
W odniesieniu do wszystkich informacji wychodzacych
˛
dhcpd z ISC umożliwia zarówno administrowanie indywidualnymi klientami, jak też zbiorowa˛ konfiguracj˛e klas i podsieci. Ponadto
w konfiguracji dhcpd z ISC możliwe jest warunkowe przekazywanie danych konfiguracyjnych
hosta za pomoca˛ instrukcji IF.
DHCPD może być stosowany w konfiguracji Failover zarówno dla Load - Balancing, jak i
systemów wysokiej niezawodnoś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 umożliwia dynamiczne
ściaganie
˛
konfiguracji serwera ISC - DHCP z repozytorium LDAP. Implementacja nast˛epuje
zgodnie z IETF Draft opisujacym
˛
schemat LDAP dla DHCP.
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˛ być świadczone zarówno w postaci klienta, jak
też jako lokalna, albo domenowa Master Browser. Z drugiej zaś strony nmbd może, także jako
WINS, koordynować 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 stopień synchronizacji. Używajac
˛ Network Time Protocol można zsynchronizować zegary komputerów w sieci lokalnej z
dokładnościa˛ co do mikrosekund. W przypadku stałego połaczenia
˛
z Internetem istnieje możliwość synchronizacji czasu referencyjnego z urz˛edowym Normal z dokładnościa˛ liczona˛ w milisekundach. Alternatywnie, jako źródła odniesienia wskazujace
˛ czas Normal, moga˛ posłużyć
także (mi˛edzy innymi) DCF77 i GPS.
Implementacja referencji standardu jest stale rozwijana i utrzymywana w ramach Network
Time Protocol Project. Oprogramowanie to można stosować także w Windows NT.
3.5.4 Migracja kontynuacyjna - usługi sieciowe pod Windows 2000
W nast˛epujacych
˛
podrozdziałach zamieściliśmy krótki opis nowości zwiazanych
˛
z usługami sieciowymi, które wprowadzone zostały wraz z Windows 2000.
3.5.4.1
WINS
Windows 2000 nie oferuje nowoś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, że Windows 2000 Active Directory wykorzystuje DNS do naczelnego przekształcania nazw badź
˛ inaczej mówiac,
˛ nie mógłby on działać 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 zapisywać usługi, DNS musi obsługiwać
139
tak zwane SRV Records odpowiednio do standardu RFC 2052. Ponieważ dotychczasowy DNS
działał statycznie (wpisy trzeba było wprowadzać r˛ecznie), w Windows 2000 ze wzgl˛edu na
docelowa,˛ przyszła˛ rezygnacje z WINS, zaimplementowano rejestracj˛e dynamiczna;
˛ komputery
moga˛ dynamicznie zapisywać swoje A i SRV Records. Powyższa implementacja jest nast˛epstwem RFC 2136 (Dynamic Update). Komputery z Windows 2000 i nowszymi moga˛ same si˛e
rejestrować (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 może zapisywać zawartość 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 może być ograniczana za pomoca˛ mechanizmów bezpieczeństwa w taki sposób, że możliwa jest rejestracja tylko tych komputerów, które moga˛ si˛e
autoryzować. (np. klienty Windows 2000 przynależ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 możliwa.
3.5.4.3
DHCP
Jeśli chodzi o DHCP, Windows 2000 oferuje własne, godne uwagi, nowości. W Windows 2000
obsługiwane sa˛ aktualne RFCs 2131 (Dynamic Host Configuration Protocol, wcześniejszy RFC
1541) oraz 2132 (DHCP Options and BOOTP Vendor Extensions). Oprócz ulepszonego zarza˛
dzania obsługiwane sa˛ teraz także Multicast Scopes, opcje użytkownika i producenta DHCP, jak
też dynamiczny BOOTP.
Inna˛ nowoś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 może przejać
˛ rejestracj˛e w DNS.
Klient DHCP z Windows 2000 może, jeśli w jego podsieci znajduje si˛e serwer DHCP, samodzielnie skonfigurować swój IP. Używane sa˛ w tym celu adresy IP sieci klasy B 169.154.0.0 z
maska˛ podsieci 255.255.0.0.
140
3.6 Kontrola i zarzadzanie
˛
systemem
3.6.1 Przeglad
˛
W niniejszym rozdziale należy z góry zauważyć, że domyślne administrowanie odbywa si˛e w
Windows NT w oparciu o dost˛epne tylko cz˛eściowo i bardzo niewyszukane narz˛edzia do zarzadzania
˛
systemem, co sprawia, że w wielu miejscach trzeba korzystać z oferujacych
˛
szerokie możliwości narz˛edzi dostarczanych przez innych producentów, które cz˛eściowo dost˛epne sa˛
takż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 rozwiazań
˛
OSS przeznaczonych do administrowania systemem. Mamy tu do dyspozycji, np. program Nagios służacy
˛ do wizualizacji i kontroli
usług. Jest to kompleksowy, wysoce zintegrowany system, za pomoca˛ którego można wykonać
wszystkie systemowe zadania administracyjne. Obecnie program ten nie jest rozprowadzany jako
OSS.
Również Microsoft rozszerzył swoja˛ „skrzynk˛e z narz˛edziami“ oferowana˛ wraz z kolejnymi
produktami. W tym miejscu należy wymienić Microsoft Operations Manager oraz Application
Center.
3.6.2 Punkt wyjś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 należy uznać wersj˛e 1.2. W roku 1999 ukazała
si˛e wersja 2.0. Zakres funkcji w/w wersji został przedstawiony poniżej.
SMS integruje wiele podstawowych funkcjonalności, które dostarczane sa˛ również przez innych producentów w postaci porównywalnego, zintegrowanego produktu. Sa˛ nimi:
◦ inwentaryzacja (inventory)
◦ zdalne sterowanie (remote control)
oraz
◦ przydzielanie oprogramowania (software distribution)
Aby móc korzystać z tego oprogramowania serwerowego potrzebny jest Windows NT Server
4.0, Service Pack 4 albo jego nowsza wersja i Microsoft SQL Server 6.5.
141
SMS 2.0 może być stosowany w dużych sieciach wraz z ponad 10.000 klientów. Ponieważ
można go wpisać w windowsowa˛ struktur˛e domen, istnieje możliwość bardzo dokładnego dozowania uprawnień. SMS obsługuje także Novell Netware NDS oraz ś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 użytkownika. Proces przydzielania oprogramowania może przebiegać w oparciu o z góry ustalone reguły. Administratorzy
definiuja˛ konfiguracj˛e oprogramowania poprzez dodawanie badź
˛ usuwanie komputerów, użytkowników albo grup użytkowników z list, zgodnie z wybranymi kryteriami. SMS protokołuje
stan instalacji oprogramowania i aktualizacji systemu operacyjnego w taki sposób, że administratorzy systemu uzyskuja˛ informacj˛e, czy dane oprogramowanie zostało zainstalowane we
właściwy sposób. SMS instaluje oprogramowanie automatycznie, bez udziału użytkownika, przy
czym proces instalacji posiada prawa administratora także wtedy, gdy użytkownik komputera
zalogowany jest z mniejszymi uprawnieniami. Komputery oparte na NT nie musza˛ być zalogowane, co sprawia, że Feature to nadaje si˛e do przydzielania oprogramowania poza regularnym
czasem pracy. SMS umożliwia przydzielanie oprogramowania dowolnie wskazanym użytkownikom, grupom uż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 może te wytyczne stosować we wszystkich miejscach. Jeśli do grupy użytkowników dołacz
˛ a˛ nowi uż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 zapewnić wydajne przydzielanie oprogramowania w przypadku wolnych połaczeń.
˛
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
używa połaczenia
˛
WAN tylko raz. SMS 2.0 może rozsyłać oprogramowanie za pomoca˛ Courier
Sender poprzez CD-ROM albo inne media. Gdy tylko użytkownik otrzyma dane medium (np.
CD-ROM) i uruchomi je w systemie, zacznie si˛e zautomatyzowany proces. Tworzenie pakietów
oprogramowania możliwe jest dzi˛eki załaczonemu
˛
programowi instalacyjnemu. Umoż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 także log function. Instalator używa
technologii shapshot.
SMS 2.0 może przeprowadzać inwentaryzacj˛e osprz˛etu i oprogramowania. Podczas inwentaryzacji osprz˛etu opartej na CIM, SMS 2.0 zbiera dane w formacie CIM (Common Informa-
142
tion Model), który umożliwia SMS dost˛ep do wielu różnych źródeł, w tym także do Microsoft
Win32, SNMP i DMI. SMS zbiera obszerne dane inwentaryzacyjne, które można filtrować za pomoca˛ opcji. Inwentaryzacja oprogramowania zbiera dokładne informacje o każdej aplikacji na
każdym komputerze. SMS 2.0 nie szuka w predefiniowanej bazie danych, lecz w każdym pliku
wykonywalnym na komputerze klienckim według informacji o zasobach i wersjach. Dane inwentaryzacyjne moga˛ być wykorzystane jako podstawa dla przydzielania oprogramowania opartego
na regułach.
Zdalne sterowanie (Remote Control) umożliwia wykonywanie aplikacji na odległość, komunikowanie si˛e przez okna Chat z użytkownikami końcowymi, jak również ponowne uruchamianie komputerów. Ponadto możliwe jest sterowanie ekranem, klawiatura˛ i mysza.˛
SMS 2.0 może, jeśli chodzi o zarzadzanie
˛
siecia,˛ pełnić nast˛epujace
˛ zadania:
◦ za pomoca˛ SMS można wyświetlać i wizualizować topologi˛e sieci, klientów, jak też wykorzystywane systemy operacyjne.
◦ SMS tworzy podglad
˛ serwerów i urzadzeń
˛
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 może automatycznie interpretować znalezione wyniki.
SMS 2.0 oferuje narz˛edzia do analizy, kontroli i sterowania aplikacjami na serwerach i stacjach
roboczych (pomiar oprogramowania). Można przy tym w uporzadkowany
˛
sposób śledzić wykorzystanie oprogramowania według użytkowników, grupy, stacji roboczej, czasu albo ograniczeń licencyjnych. Dodatkowo można zdefiniować granice kontyngentów albo ustalić, z jakich
aplikacji nie wolno korzystać. Ponadto można kontrolować przestrzeganie zasad przez każdego
dowolnego klienta albo serwer. Programy służace
˛ do pomiaru oprogramowania wykrywaja˛ również różnice wersji i moga˛ stwierdzić, czy agenci klientów zostali dezaktywowani, co ma na celu
zapewnienia szerokiej ochrony przed manipulacjami. Statystyki dotyczace
˛ wykorzystania oprogramowania moga˛ posłużyć do planowania licencjonowania oprogramowania i do obejmowania
opłatami działów w zależności od wykorzystywanych w nich aplikacji (zarzadzanie
˛
licencyjne).
Kontrola serwera odbywa si˛e za pomoca˛ HealthMon. HealthMon ustala dane nt. wydajności procesów działajacych
˛
na serwerach Windows NT i Microsoft BackOffice. Na konsoli
HealthMon można wprowadzać krytyczne wartości progowe albo wartości progowe dla ostrzeżeń w celu uzyskiwania w czasie rzeczywistym, zdefiniowanych w oparciu o wyjatki,
˛ informacji
o stanie, które można grupować według zasobów na poziomie systemu albo według aplikacji i
procesów serwera Microsoft.
143
˛ - Linux
Zarzadzanie
˛
systemem w przypadku systemów operacyjnych OSS opiera si˛e na podstawowej
funkcjonalności sieciowego sytemu operacyjnego skupiajacego
˛
wielu użytkowników. Administrator możne pracować z odległego miejsca na każ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 użytkownika, dzi˛eki jego systemowemu oddzieleniu od serwera (wyświetlacz,
klawiatura i mysz) oraz oprogramowaniu klienckiemu, które prezentuje swoje okna i znaki na
wyświetlaczu lokalnie albo na odległość poprzez połaczenie
˛
sieciowe oraz dzi˛eki przyjmowaniu
danych z serwera, wspaniale nadaje si˛e także, mi˛edzy innymi, do zdalnej obsługi komputerów.
Do tego dochodza˛ Secure Shell (ssh) i narz˛edzia z bogato wyposażonej „skrzynki z narz˛edziami“,
takie jak cron / at do zarzadzania
˛
zadaniami w czasie oraz pot˛eżne interpretatory pracujace
˛ z
linii poleceń, Utilities i interpretowane j˛ezyki programowania, które można wykorzystywać do
zaawansowanego automatyzowania zadań routine. Aby zdalnie sterować systemami OSS nie jest
wymagane dodatkowe oprogramowanie.
Do scentralizowanego zarzadzania
˛
systemem w sieciach heterogenicznych, także w systemach OSS, można wykorzystywać dodatkowe składniki. Na górnym końcu skali można zintegrować Linuksa z systemem zarzadzania
˛
Tivoli albo OpenView. Pomi˛edzy powyższymi rozwia˛
zaniami, których nie zalicza si˛e do OSS, a prostym zarzadzaniem
˛
za pomoca˛ narz˛edzi należacych
˛
do sytemu operacyjnego istnieje duża ilość programów, które każdorazowo umożliwiaja˛ wykonywanie określonych zadań w systemie albo jego automatyzacj˛e.
3.6.3.1
Administrowanie oprogramowaniem
Istnieja˛ komercyjne rozwiazania,
˛
oferowane przez różnych producentów, służace
˛ do inwentaryzacji, przydzielania i aktualizacji, jak również do zarzadzania
˛
konfiguracja˛ składników oprogramowania. Niektóre z tych rozwiazań
˛
przeznaczone sa˛ także dla heterogenicznych systemów
z udziałem Windows. Jeśli chodzi o Wolne Oprogramowanie, nie istnieje gotowe do wykorzystania produkcyjnego, zintegrowane rozwiazanie,
˛
w szczególności dla środowisk heterogenicznych. Jednak za pomoca˛ narz˛edzi przeznaczonych do administrowania pakietami (RPM i APT)
można w bardzo łatwy sposób scentralizować inwentaryzacj˛e oraz przydzielanie badź
˛ uaktualnianie oprogramowania. Do centralnego zarzadzania
˛
pakietami wspaniale nadaje si˛e zwłaszcza
system zarzadzania
˛
pakietami Debiana, ponieważ pracuja˛ one w oparciu o hierarchi˛e z centralnych repozytoriów i dysponuja˛ bardzo mocnym systemem aktualizacji.
W obszarze bezpieczeństwa, narz˛edziem, które należy stosować do inwentaryzacji i kontroli
oprogramowania jest Tripwire.
3.6.3.2
144
Administrowanie siecia˛
Jeśli chodzi o zarzadzanie
˛
sieciami TCP / IP, istnieje duży wybór programów o różnych punktach
ci˛eżkości.
Narz˛edzie do monitoringu „Nagios“ specjalizuje si˛e w wizualizacji topologii sieci i w kontroli usług, udost˛epnianych takż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 wartości progowych. Możliwe jest przy tym zwi˛ekszanie ilości komunikatów i właczanie
˛
różnych kanałów informacyjnych (np. mail albo SMS).
Nagios obsługuje Plug-Ins do aktywnej albo pasywnej kontroli najróżniejszych usług i parametrów systemu. Mi˛edzy innymi kontrolowane moga˛ być typowe usługi sieciowe takie jak Web,
Mail i LDAP, różne RDBMS albo Samba. Ponadto istnieja˛ Plug - Ins umożliwiajace
˛ nadzór
nad takimi parametrami systemu, jak obciażenie
˛
CPU, ilość wolnego miejsca na dysku, a także
danymi z czujników (temperatura, zasilanie i liczba obrotów wentylatorów). Istnieja˛ mostki do
innych systemów takich jak MRTG / RRD oraz umożliwiajace
˛ wykorzystanie SNMP do monitorowania.
Programami wyspecjalizowanymi w monitoringu i analizie ruchu w sieci sa˛ MRTG / RRD.
MRTG używa Simple Network Management Protocol do zbierania i zapisywania danych o ruchu
z najróżniejszych składników sieciowych. Ich ocena i prezentacja graficzna może być realizowana wewn˛etrznie przez MRTG albo z zewnatrz
˛ za pomoca˛ RRD. MRTG ma do dyspozycji ponad 350 templates służacych
˛
do bezpośredniego łaczenia
˛
najróż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ównież pracuje z
SNMP.
Scotty to kolejne narz˛edzie do wizualizacji i zarzadzania
˛
lokalnymi sieciami, pracujacym
˛
także z SNMP i takż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łań, wyspecjalizował si˛e Snort. Jako „Lightweight Intrusion Detection System“ jest on wartościowym składnikiem systemu zarzadzania
˛
siecia.˛
3.6.3.3
Administrowanie serwerami
Jeśli chodzi o administrowanie serwerami, do kontroli i ograniczania zasobów systemowych
pojedynczych użytkowników lub procesów służa˛ w Linuksie m.in. Ulimits, Quotas i Process
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. Także serwery windowsowe moga˛ zostać właczone
˛
w centralny
system syslog. Do automatycznej oceny zawartości plików logowania wykorzystywanych jest
wiele narz˛edzi i rozwiazań,
˛
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 zapewnić konieczne wyszukiwanie bł˛edów, należy
skorzystać z narz˛edzi systemowych wykraczajacych
˛
poza regularne usługi protokołowe, a oferujacych
˛
duże możliwości analityczne, np. strace, lsof, fuser i netstat.
3.6.3.4
Systemy złożone
W zakresie zarzadzania
˛
systemem istnieje oprócz Simple Network Management Protocol także
Common Information Model (CIM) wraz z opartym na nim Web Based Enterprise Management
(WBEM), które służa˛ do szerszych zastosowań podczas standardowego zarzadzania
˛
systemem w
sieciach heterogenicznych. CIM / WBEM sa,˛ podobnie jak SNMP, opisane w otwartych standardach i dost˛epne w implementacjach referencji jako Wolne Oprogramowanie. Jednak składniki te
wykorzystywane sa˛ obecnie raczej w ramach produktów komercyjnych. Praktyczna przydatność
czystych rozwiazań
˛
Open Source w tym obszarze musi si˛e dopiero wykształcić.
3.6.3.5
Wnioski
Jeśli chodzi o zarzadzanie
˛
systemem, systemy operacyjne OSS podażaj
˛ a˛ śladami swojego pierwowzoru, tj. Uniksa. Jako sieciowe systemy wielu użytkowników posiadaja˛ one bardzo różnorodne funkcje umożliwiajace
˛ centralne zarzadzanie
˛
systemem i w niektórych obszarach moga˛
być wzorem, a nie uzupełniajac
˛ a˛ alternatywa˛ dla rozwiazań
˛
windowsowych. Migracja oznacza
także zmiany koncepcyjne dla administratorów i w organizacji pracy, które przyczynia˛ si˛e do
zrobienia dużych post˛epów, w szczególności jeśli chodzi o bezpieczeństwo. Właśnie bezpieczeństwo i stabilne działanie sa˛ cechami charakterystycznymi dla ogólnie poj˛etych systemów
linuksowych wynikajacymi
˛
także z systemu zarzadzania.
˛
Dla osób, którym powierzone zostanie wdrożenie projektu migracyjnego oznacza on wyraźne zmiany. Zarówno możliwości analizy, jak też opcje dostosowania i korekty systemów OSS
daja˛ administratorom systemu o wiele wi˛ecej swobody, niż mieli oni w przypadku zamkni˛etego
systemu Windows. Wolność t˛e można wykorzystać w celu uniezależnienia si˛e od producentów
146
i zewn˛etrznych świadczeniodawców oraz zarazem do podnoszenia kwalifikacji własnych pracowników. Przejrzystość otwartych systemów OSS ułatwia podstawowe i dogł˛ebne zrozumienie
funkcji i zależności róż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 jeśli chodzi o kontrol˛e procesów, wydajności oraz zarzadzanie,
˛
pozwala on administrować systemami
serwerowymi opartymi na Windows 2000.
Obecna˛ wersja˛ Microsoft Operations Manager jest MOM 2000. Oferuje ona nast˛epujace
˛
funkcjonalności:
MOM zbiera do centralnego repozytorium zdarzeń różnorodne informacje o procesach zwia˛
zanych z działaniem systemu oraz aplikacji pracujacych
˛
w dzielonym środowisku IT w systemach windowsowych. W ten sposób powstaje dzielone zarzadzanie
˛
procesami. Administratorzy
moga˛ korzystać z przegladu
˛ wszystkich zdarzeń, co daje im wiedz˛e nt. dost˛epnych serwerów i
usług. W MOM można tworzyć reguły. W oparciu o rozwini˛ete reguły system może automatycznie reagować 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 może reagować na określone wzorce wydarzeń i procesów,
wzgl˛ednie wysyłać komunikaty ostrzegawcze zdefiniowane przez administratora. Każda˛ reguł˛e
MOM można zdefiniować w taki sposób, by były generowane specjalne ostrzeżenia przyporzadkowane
˛
odpowiednim stopniom bezpieczeństwa. Ostrzeżenie może pojawić si˛e wskutek pojedynczego zdarzenia albo wielu zdarzeń pochodzacych
˛
z licznych źródeł. Administrator ma zawsze możliwość przeanalizowania przyczyn ostrzeżenia i odpowiednich zdarzeń. Ponadto możliwe jest wywoływanie ostrzeżeń, wiadomości e - mail, jak również Traps stron i Traps SNMP
(Simple Network Management Protocol). Za pomoca˛ MOM można wprowadzić kontrol˛e wydajności przyłaczonych
˛
systemów. Dodatkowo można określić wartości progowe wydajności i
je kontrolować. Poprzez dopasowanie lub dodanie reguł można, dla późniejszych referencji albo
planowania pojemności, kontrolować rozwój wydajności systemu i aplikacji. Oprócz tego można
ustawić lokalne i grupowe wartości progowe, które b˛eda˛ uruchamiać, w reakcji na zmiany wydajności systemu lub aplikacji, ostrzeżenia albo procesy wymagajace
˛ interwencji administratora.
Portfolio usług, jakimi należy zarzadzać
˛
można rozszerzać za pomoca˛ Management Packs.
Management Packs zawieraja˛ predefiniowane reguły MOM. Każdy pakiet oferuje reguły dla
147
określonych aplikacji lub usług. MOM standardowo zawiera Management Pack, za pomoca˛ którego można zarzadzać
˛
wszystkimi usługami windowsowymi, w tym także usługa˛ katalogowa˛
Active Directory oraz usługami informacyjnymi (Internet Information Services, ISS). Dost˛epne
sa˛ również 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 możliwość przygotowania i przedstawienia zebranych danych w formie raportów.
Narz˛edzie do tworzenia graficznych raportów umożliwia dost˛ep do wcześniej wygenerowanych
raportów i diagramów. Daja˛ one administratorowi możliwość sprawdzania stanu systemów i
usług w sieci. Za pomoca˛ Management Packs firmy Microsoft albo innych producentów możliwe jest dodanie do systemu dodatkowych raportów. Szczególna˛ cecha˛ MOM jest to, że może
generować snapshots oparte na HTML dla wszystkich gotowych raportów. Migawki takie można
nast˛epnie wyeksportować 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
można także skorzystać 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.
148
3.7 Usługi katalogowe
3.7.1 Przeglad
˛
Ponieważ usługa katalogowa nie jest, z punktu widzenia sytuacji wyjściowej, cz˛eścia˛ składowa˛
Windows NT, poniższe oceny nie koncentruja˛ si˛e na zastapieniu
˛
badź
˛ kontynuacji istniejacej
˛
usługi katalogowej. Mimo to usługa katalogowa odgrywa ważna˛ rol˛e, zarówno podczas migracji zast˛epujacej,
˛
jak i kontynuacyjnej. Wraz z migracja˛ do Windows 2000 oraz w szczególności
w przypadku migracji do Exchange 2000, zastosowanie Active Directory jest niemalże wymuszone. Skorzystanie z usługi katalogowej podczas migracji zast˛epujacej
˛ - rozwiazaniem
˛
OSS
b˛edzie tu OpenLDAP - niesie ze soba˛ wiele zalet, szczególnie jeśli chodzi o wygodna˛ realizacj˛e
autoryzacji. W zwiazku
˛
z tym poniższa, techniczna ocena jest raczej spojrzeniem wybiegajacym
˛
w przyszłość i przedstawia szczególne cechy każdorazowego wprowadzenia usługi katalogowej,
wzgl˛ednie możliwości jej wprowadzenia. Interesujacym
˛
aspektem tego spojrzenia sa:
˛ integracyjne oddziaływanie Active Directory (AD) oraz możliwość przeciwdziałania mu.
Podsumowujac
˛ można stwierdzić, że z AD należy korzystać w minimalnym zakresie, o ile
w ogóle nie można z niego zrezygnować. Wi˛eksze wymagania należy realizować korzystajac
˛ z
innych produktów i rozwiazań,
˛
np. z Metadirectory.
Ponadto jest to właściwy moment, by zastanowić si˛e, kiedy obejść AD i zastosować tryb
natywny oraz by dokonać prawidłowego doboru ewentualnych opcji.
3.7.2 Podstawy
Za pomoca˛ usługi katalogowej można udost˛epniać 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 możliwe jest odpytywanie i zmiana informacji. Obecnie najcz˛eściej stosowanym protokołem usług katalogowych jest Lightweight Directory Access Protocol
(LDA). LDAP został stworzony, aby w prosty sposób zapewnić dost˛ep do usług katalogowych
opartych na X.500. Dzisiaj pod poj˛eciem serwera LDAP rozumie si˛e najcz˛eś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 każdy obiekt posiada pewna˛ ilość atrybutów, których wartości reprezentuja˛
właściwe informacje. Każdy obiekt może zawierać jednocześnie podobiekty (wraz atrybutami),
które moga˛ posiadać kolejne podobiekty.
149
Obiekty w usłudze katalogowej sa˛ osobnymi, jeśli chodzi o zawartość, jednostkami takimi
jak, np. osoby, grupy, komputery, drukarki albo sale konferencyjne w budynku. To, jakie atrybuty
może a jakie musi posiadać obiekt, definiowane jest poprzez klasy obiektów danego obiektu.
Klasa obiektu wyst˛epujaca
˛ w wielu katalogach może, np. być oznaczona, jako person i nakazywać, ż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 możliwości przyporzadkowania
˛
(także
wtórnego) obiektom wielu klas obiektów, uzyskano duże możliwości dostosowawcze oraz możliwość zapisywania zwiazanych
˛
ze soba˛ informacji w tym samym miejscu (mianowicie w tym
samym obiekcie). Osoba może posiadać wiele wzajemnych, powiazanych
˛
swoja˛ zawartościa,˛
właściwości, które musza˛ być zdefiniowane za pomoca˛ różnych klas obiektów (różnych, przenikajacych
˛
si˛e atrybutów). Oznacza to, że np. osoba może być widziana jako użytkownik systemów
komputerowych, wpis w ksiażce
˛
telefonicznej, wpis w ksiażce
˛
adresowej albo partner życiowy
innej osoby. Jeśli chcielibyśmy zapisać niniejsze właściwości w jednym katalogu, wówczas dla
klas właściwości: użytkownik, wpis w ksiażce
˛ telefonicznej, wpis w ksiażce
˛ adresowej i partner
życiowy musielibyśmy zdefiniować odpowiednie klasy obiektów wraz z atrybutami. Aby każda
z klas obiektów mogła być sensownie używana także bez innych klas, każda z nich musiałaby
prawdopodobnie posiadać atrybuty, które wst˛epuja˛ również w pozostałych wymaganych klasach
obiektów, np. nazwisko osoby. Jeśli klasy obiektów sa˛ powiazane
˛
ze soba˛ w jednym obiekcie,
wówczas atrybut Name trzeba zapisać tylko jeden raz.
Możliwość korzystania z hierarchicznej struktury katalogów jest zazwyczaj wykorzystywana
do odwzorowania w katalogu struktury organizacji. W tym celu stosuje si˛e najcz˛eściej specjalne
obiekty, które służa˛ do strukturyzacji katalogu i odpowiadaja˛ sztucznym albo rzeczywistym jednostkom organizacyjnym. Obiekty te cz˛esto używaja˛ klasy organizationalUnit (ou). Poza tym,
ze wzgl˛edu na zapewnienie przejrzystości, usługa katalogowa tworzona jest w oparciu o i tak
istniejace
˛ już w organizacji przestrzenie nazw DNS. W tym celu wykorzystuje si˛e klas˛e domainComponent (dc). W praktyce zgrubna struktura tworzona jest najcz˛eściej w oparciu o przestrzenie nazw DNS a dokładna struktura za pomoca˛ jednostek organizacyjnych i innych container
objects.
Za przykład może posłużyć organizacja majaca
˛ swoja˛ siedzib˛e w dwóch miejscach (dzielnica
zachodnia i dzielnica wschodnia). Używa ona domeny DNS miasto.pl i poddomen dla obydwu
siedzib wsch.miasto.pl oraz zach.miasto.pl. Za punkt wyjścia dla katalogu organizacja taka mogłaby uznać obiekt „miasto.pl“. Byłby on w LDAP zapisany jako dc=miasto,dc=pl, co miałoby
150
oznaczać, że w przypadku podstawowego punktu odniesienia chodzi o typ obiektu składnik domeny (domainComponent, dc), że obiekt nazywa si˛e miasto, a podobiekt obiektu nosi nazw˛e de
i jego typem również jest składnik domeny.
Taki punkt wyjścia objałby
˛
z kolei dwa nast˛epne obiekty oznaczone dc=wsch i dc=zach
(analogicznie do nazw DNS w/w siedzib). Powyższe oznaczenia nazywa si˛e także wzgl˛ednymi
nazwami obiektów, ponieważ nie wskazuja˛ one jednoznacznie swojego położenia w hierarchii
katalogu. Alternatywnie można korzystać z nazw jednoznacznych (distinguished Names), za
pomoca˛ których można oznaczyć dokładne położ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 każdej z dwóch w/w siedzib dana organizacja ma trzy jednostki organizacyjne oznaczone jako produkcja, dystrybucja i kierownictwo. Aby móc odwzorować je w katalogu, dla jednostki organizacyjnej produkcja mieszczacej
˛ si˛e w siedzibie w dzielnicy wschodniej należałoby
założyć obiekt ou=produktion jako podobiekt dc=wsch (jednoznaczna nazwa: ou=produktion,dc=wsch,
dc=miasto,dc=pl). Analogicznie należałoby postapić
˛
z pozostałymi jednostkami organizacyjnymi mieszczacymi
˛
si˛e w obydwu siedzibach. Należałoby, np. wewnatrz
˛ jednostki organizacyjnej produkcja utworzyć obiekty takie jak osoby, grupy osób oraz komputery. W celu bardziej
przejrzystego kształtowania tworzonej struktury w/w obiekty można uporzadkować
˛
w containers
(na ogół oznacza si˛e je nazwami albo za pomoca˛ commonName, cn) i przypisać nast˛epujace
˛ oznaczenia: cn=osoby, cn=grupy i cn=komputery. Na koniec należałoby utworzyć wpisy dla rzeczywistych obiektów znajdujacych
˛
si˛e w containers. I tak, np. trzeba by w pojemniku założyć 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=
Oczywiście korzystanie z usługi katalogowej ma sens tylko w przypadku wykorzystywania
możliwie wielu aplikacji. W najlepszym układzie jest ona jedynym źródłem informacji zapisanych w sieci. Gdy, np. w sieci jakiejś organizacji pracuja,˛ np. serwery oparte na Windows i
Uniksie, aplikacja intranetowa oraz Web - Proxy z autoryzacja,˛ wówczas dla poszczególnych
systemów trzeba oddzielnie konfigurować konta użytkowników i ich uprawnienia. Wraz z wdrożeniem usługi katalogowej możliwe staje si˛e centralne zdefiniowanie w usłudze katalogowej kont
użytkowników oraz ich uprawnień i zezwolenie innym systemom na korzystanie ze wspólnych
danych. Jednocześnie aplikacje z ksiażkami
˛
adresowymi, np. wbudowanymi w oprogramowanie
pocztowe, moga˛ mieć dost˛ep do wspólnego katalogu i w ten sposób udost˛epniać adresy e - mail
członkom danej organizacji, bez konieczności ponownego, r˛ecznego wprowadzania danych.
151
Usługi katalogowe moga˛ także służyć do zapisywania haseł (hasła te staja˛ si˛e zazwyczaj
atrybutem obiektów osób albo kont użytkowników). Także w ten sposób realizowany jest cel
jednorazowego, centralnego przechowywania danych. Hasła zapisane w katalogu trzeba tylko
założyć oraz zmienić w jednym miejscu i już można z nich korzystać we wszystkich systemach
i ze wszystkimi aplikacjami, które moga˛ używać danego katalogu do autoryzacji. Ponadto hasła
zapisane w katalogu moga˛ być 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 określałby, jakie obiekty i atrybuty i przez jakich użytkowników moga˛ być czytane lub zmieniane. Z tego powodu celowe jest zadanie takich ustawień,
by hasła mogły być zmieniane tylko przez swoich użytkowników i administratorów. Oprócz
tego musza˛ one móc służyć swoim użytkownikom do autoryzacji. Z drugiej strony, wszystkie
inne osoby, które maja˛ dost˛ep do katalogu, nie moga˛ mieć prawa do czytania haseł, nawet wówczas, jeśli hasła w katalogu sa˛ zaszyfrowane. Jednocześnie dozwolone jest, aby inni użytkownicy
mogli czytać adresy e - mail z obiektów użytkowników. W takim przypadku różne przydawki
(hasło i adres e - mail) tego samego obiektu (osoba i użytkownik) musiałyby być wyposażone
w różne uprawnienia. Dlatego wi˛ekszość usług katalogowych ma zaimplementowany system
Access Controll Lists (ACLs), który można porównać z ACLs na poziomie systemu plików.
Pomimo szerokiego, praktycznego wykorzystania usług katalogowych do autoryzacji, strategi˛e taka˛ należy uznać za watpliw
˛
a.
˛ Rozwiazanie
˛
tego typu nie daje możliwości bezpiecznej
implementacji Single Sing On, ponieważ w każdym systemie i każdej aplikacji wymagana jest
ponowna autoryzacja (w dodatku za pomoca˛ tego samego hasła). Ponadto wi˛ekszość usług katalogowych nie została napisane w celu udost˛epniania bezpiecznego mechanizmu autoryzacji, lecz
aby móc centralnie gromadzić informacje i szybko przesyłać je do klientów. Dlatego zamiast w/w
metody zalecane jest stosowanie Kerberos.
W przypadku wykorzystywania Kerberos nazwy oraz hasła użytkowników nie sa,˛ podobnie jak jest to na ogół przyj˛ete w innych rozwiazaniach,
˛
wysyłane do każdego serwera, z którego usług może korzystać każdy użytkownik, lecz nast˛epuje tu jednorazowe zalogowanie go
do Key Distribution Center (KDC, nazywane także kontrolerem domen Kerberos). Po zalogowaniu użytkownik otrzymuje Ticket, który ma zdefiniowany czas ważności i za pomoca˛ którego
można autoryzować si˛e we wszystkich kolejnych usługach. Po upływie terminu ważności biletu
użytkownik musi si˛e ponownie autoryzować. Ze wzgl˛edu na stosowanie Kerberos baza danych
haseł musi znajdować si˛e tylko w szczególnie zaufanych systemach (serwerach Kerberos). Inne
systemy nie musza˛ mieć do niej dost˛epu. Oprócz tego za pomoca˛ Kerberos - Tickets można
152
implementować Single Sign On, ponieważ bilety wykorzystywane moga˛ być 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 ważnym składnikiem sieci, który musi gwarantować bardzo wysoka˛ niezawodność. Dlatego usługi katalogowe obsługuja˛ z reguły procesy replikacji, za pomoca˛ których
możliwe jest przenoszenie całego katalogu i zmian z jednego serwera świadczacego
˛
usług˛e katalogowa˛ na inne. Dzi˛eki temu istnieje także możliwość rozkładania obciażenia,
˛
gdyż nie wszystkie klienty musza˛ korzystać z tego samego serwera usługi katalogowej.
Jeśli chodzi o replikacj˛e, należy rozróżnić replikacj˛e Master - Slave oraz Multi - Master. W
przypadku tej pierwszej zmiany moga˛ być 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 zawartości katalogu powstaje wówczas tak zwane waskie
˛
gardło, ponieważ
można je przeprowadzać tylko na centralnym serwerze. Jeśli nastapi
˛ jego awaria, wtedy zmiany
sa˛ niemożliwe aż do chwili zmiany konfiguracji i udost˛epnienia innego serwera jako Master albo
ponownego uruchomienia starego Master - Server.
Replikacja Multi - Master umożliwia dokonywanie zmian w zawartości usługi katalogowej
na wielu serwerach, co rozwiazuje
˛
powyższe problemy. Jednak w przypadku tej replikacji ujawniaja˛ si˛e problemy ze spoistościa˛ w momencie, gdy na różnych serwerach przeprowadzane sa˛
sprzeczne ze soba˛ zmiany.
3.7.3 Active Directory Service (ADS)
Celem niniejszego rozdziału jest przedstawienie możliwie obszernego przegladu
˛ technologii
„Active Directory Service“. Dlatego opisaliśmy tu główne funkcjonalności:
◦ Directory Service
◦ LDAP
◦ Kerberos
◦ wytyczne grup
◦ Delegation
◦ zarzadzanie
˛
certyfikatami
153
Ponadto przedstawiliśmy:
◦ zakres zastosowania
◦ architektur˛e
oraz
◦ znaczenie strategiczne.
Innym celem jest wyjaśnienie róż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, można stwierdzić, że
jest on ich nast˛epca.˛
Jest tak tym bardziej, że wywołanie installation routine z Windows 2000 na PDC z Windows
NT prowadzi bezpośrednio do utworzenia Active Directory. Jednak bł˛edem w tym miejscu byłoby myślenie, że tworzenie Active Directory polega tylko na wywołaniu installation routine na
pojedynczym serwerze. Aby utworzyć AD należy mieć porzadny
˛
pomysł i starannie zaplanować
migracj˛e.
Podstawowa˛ technologia,˛ na której opieraja˛ sie usługi logowania w Active Directory jest,
podobnie jak w Windows NT, jedność struktury domeny. Domena pozostaje jednostka˛ administracyjna,˛ która za pomoca˛ wspólnie wykorzystywanej bazy danych skupia konta komputerów i
użytkowników we wspólnym kontekście bezpieczeństwa. Granica domen jest granica˛ kontekstu
bezpieczeństwa oraz granica˛ dla replikacji bazy danych użytkowników.
Zachowana została przestrzeń nazw NetBIOS. Ponadto, podobnie jak w Windows NT, komputery pracujace
˛ w oparciu o:
◦ Windows NT
◦ Windows 2000
◦ Windows XP
moga˛ być członkiem domeny.
Jeśli chcemy obsłużyć takie systemy, jak Windows NT i 9x, wówczas nadal musimy zagwarantować bezbł˛edne przekształcanie nazw NetBIOS (np. za pomoca˛ WINS).
154
Charakterystyczne dla przeprowadzanej zmiany architektury jest implementacja Active Directory. Wymaga ona infrastruktury DNS, która sprawia, że konieczny jest nie tylko wybór przestrzeni nazw, lecz także zastosowanie właściwego serwera DNS. Oczywiście pociaga
˛ to za soba˛
dostosowanie istniejacego
˛
środowiska sieciowego TCP / IP.
Planowanie migracji oraz moż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 choćby dla zapewnienia autoryzacji podczas logowania systemów takich jak Windows NT lub 9x. Nowościa˛ jest autoryzacja via Kerberos.
Systemy Windows 2000 albo XP domyślnie korzystaja˛ z Kerberos. Jednak w razie potrzeby
można je przełaczyć
˛
także w tryb autoryzacji NTLM. Systemy takie, jak Windows NT lub 9x
nie moga˛ nawet po wykorzystaniu obcego oprogramowania wykorzystywać 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 każdym kontrolerem
domeny Active Directory i używa jego bazy danych użytkowników.
Dla korzystania z Kerberos konieczne jest zachowanie możliwie niewielkich róż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 należy ocenić krytycznie, gdy używana jest w sieci NAT (Network
Address Translation), ponieważ szyfrowane ładowanie pakietów IP zawiera adresy IP.
Kerberos jest metoda˛ bardziej elastyczna˛ i wydajna˛ niż NTLM. W przypadku NTLM, aby
autoryzować klienta, serwer aplikacji musiał zawsze łaczyć
˛
si˛e z kontrolerem domeny. Za pomoca˛ Kerberos serwer aplikacji może analizować informacje o logowaniach prezentowane mu
przez klienta. W NTLM serwery moga˛ identyfikować klientów, natomiast Kerberos daje także
klientom możliwość identyfikacji serwera (mutual authentication). Aby realizować dost˛ep do zasobów, usługi windowsowe musza˛ naśladować klienta (impersonate). NTLM i Kerberos moga˛
dostarczać usłudze informacje, przez co moga˛ lokalnie naśladować klienta. W przypadku aplikacji dzielonych z Frontend i Backend na różnych komputerach, technologia NTLM zawodzi,
podczas gdy Kerberos potrafi realizować przeźroczyste, dwukierunkowe zaufane połaczenia
˛
po-
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
Nowości w strukturze
Jak już wspomnieliśmy, zachowana została jedność struktury domeny, także w Active Directory.
W Active Directory domen˛e należy traktować, jako podstaw˛e całej struktury (forest) i należ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˛
być nadal wykorzystywane.)
Jeś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˛eć 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. Otrzymaliśmy zatem nast˛epujacy
˛ rysunek:
156
Rysunek 3.7: Przykład struktury domen NT
Zgodnie z rys 3.7, w Active Directory do pomyślenia jest ogólna struktura, która również
obejmowałaby siedem domen: struktura ogólna obejmuje dwa drzewa o hierarchicznej strukturze domen, które powiazane
˛
sa˛ ze soba˛ za pomoca˛ Kerberos - przeźroczyście (A ufa B i B ufa C,
wówczas A ufa także C) i dwukierunkowo (A ufa B, wówczas B ufa także A).
Rysunek 3.8: Przykład Windows 2000
Active Directory udost˛epniany jest przez kontrolery domen (DCs). Zanika rozróż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˛ekszość zmian w AD można przeprowadzić (wpisać) na każdym DC. Zasada Multi - Master nie może dotyczyć wszystkich zmian. Dlatego istnieja˛ specjalne kontrolery domeny, tak zwane FSMO - Owner (Flexible Single Master
Operation).
Chodzi tu o:
◦ emulator PDC
157
◦ Infrastructure Master
◦ RID Master
◦ Schema Master
◦ Domain Naming Master.
Funkcje te można umieszczać na specjalnie wybranych kontrolerach domen.
Funkcje:
◦ Schema Master (odpowiedzialny za schemat katalogu)
◦ Domain Naming Master (odpowiedzialny w przypadku zmian w przestrzeni nazw)
pełnia˛ jednorazowe role wewnatrz
˛ ogólnej struktury (forest).
Funkcje:
◦ emulator PDC
◦ Infrastructure Master (odpowiedzialny za aktualizacj˛e SIDs oraz Distinguished Names
poza granicami domen)
◦ RID Master (odpowiedzialny za przyznawanie RID Pools innym DCs)
sa˛ jednoznaczne w każdej domenie.
Emulator PDC przejmuje ważne funkcje takie jak:
◦ aktualizacja haseł dla Down - Level Clients (NT 4.0, 9x) oraz partnerów Windows NT
Backup Domain Controller
◦ źródło czasu sieciowego (tylko PDC domeny podstawowej)
◦ usługa głównego wyszukiwania domen (NetBIOS)
Ogólna struktura może być dodatkowo wzbogacana o punkty centralne (Sites). Miejsca te moga˛
(raczej powinny) być odbiciem fizycznej struktury sieci i łaczyć
˛
si˛e za pomoca˛ dost˛epnych szerokości pasm z lokalizacjami (Hamburg, Berlin, Bonn, etc.). Głównym celem takiej struktury
jest umożliwienie sterowania replikacja˛ pomi˛edzy kontrolerami domen.
Standardowa˛ topologi˛e można wybrać niezależnie od struktury domen. Poniższy rysunek
przedstawia przykładowa˛ topologi˛e.
158
Rysunek 3.9: Przykład struktury punktu centralnego domen oraz ich struktury
Inna˛ nowościa,˛ jeśli chodzi o tworzenie struktury, jest tak zwana struktura OU (OU jest skrótem od Organizational Unit, jednostka organizacyjna). Opisaliśmy ja˛ w rozdziale przedstawiaja˛
cym usługi katalogowe.
3.7.3.4
Przestrzeń adresowa DNS i infrastruktura
Windows 2000 Active Directory Service bezwzgl˛ednie potrzebuje infrastruktury DNS. Wymaga
to udzielenia odpowiedzi na nast˛epujace
˛ pytania:
◦ Jaka˛ przestrzeń nazw DNS powinien otrzymać AD?
◦ Jak przestrzeń nazw powinna si˛e wpisać w istniejac
˛ a˛ przestrzeń nazw DNS?
◦ Kto ma administrować istniejac
˛ a˛ przestrzenia˛ nazw?
◦ Na jakiej platformie (system operacyjny: Windows 2000, Unix) ma być udost˛epniany
DNS?
◦ Jakie odniesienie do przestrzeni nazw NetBIOS należy uwzgl˛ednić?
Znalezienie odpowiedzi na powyższe pytania jest cz˛esto szczególnie skomplikowane nie tylko
ze wzgl˛edu na warunki techniczne, lecz również wskutek tła „politycznego“.
159
Wybór platformy
Infrastruktura DNS dla AD wymaga pewnych cech, aby możliwe było bezproblemowe przekształcanie nazw i rejestracja wpisów.
Zasadniczo Windows 2000 wraz ze swoja˛ implementacja˛ DNS posiada wszystkie niezb˛edne
właściwoś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, ponieważ tylko tak można dokonywać 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.˛
Przestrzeń nazw NetBIOS
Jeśli chodzi o przestrzeń nazw NetBIOS, należy wziać
˛ pod uwag˛e nast˛epujace
˛ aspekty:
◦ Nazwa NetBIOS domeny Windows 2000 (np. RES1) może w zasadzie różnić si˛e od najniższej nazwy sufiksu DNS (jak, np. RES001 od res001.behoerde.de). Jednak odradzamy
wybieranie nazw w taki sposób.
◦ Przestrzeń nazw NetBIOS nie jest dowolna zwłaszcza wtedy, gdy trzeba zaktualizować
istniejace
˛ domeny NT (patrz Inplace Migration).
Przestrzeń nazw DNS
Podczas formułowania poniższych ocen wyszliśmy z założenia, że w istniejacej
˛ infrastrukturze obecne jest już środowisko DNS, które udost˛epniane jest w oparciu o serwer uniksowy.
Jest to dość ogólny punkt wyjścia. Niech nazwa˛ domeny b˛edzie tu „BEHOERDE.DE“, a istniejaca
˛ przestrzeń nazw BEHOERDE.DE niech b˛edzie używana tylko wewn˛etrznie. Ponadto
przyj˛eliśmy, że w infrastrukturze DNS istnieje wewn˛etrzna domena Root („kropka“) badź
˛ strefa.
Poniższy rysunek nakreśla punkt wyjścia.
160
Rysunek 3.10: Punkt wyjścia
W kolejnych podrozdziałach opisaliśmy możliwe rozwini˛ecia przestrzeni nazw pod katem
˛
Windows 2000 Active Directory. Uwidoczniona tu została złożoność migracji do ADS i wynikajace
˛ z tego długoterminowe zwiazanie
˛
si˛e z ADS.
Domena Master: W2K.BEHOERDE.DE
Istniejaca,
˛ wewn˛etrzna przestrzeń nazw DNS wykorzystywana jest do przyjmowania kolejnych poddomen W2K (jako, że domena Master = pierwsza domena Active Directory).
161
Rysunek 3.11: Domena Master: W2K.BEHOERDE.DE
Zaleta˛ powyższej domeny Master jest to, że:
◦ nie jest tworzone nowe drzewo nazw
◦ zachowane sa˛ istniejace
˛ serwery Root
◦ można dowolnie wybrać platform˛e usług DNS
◦ wewn˛etrzna i zewn˛etrzna przestrzeń nazw pozostaja˛ oddzielne
Wada˛ takiego rozwiazania
˛
jest to, że:
◦ User Principal Name użytkownika jest dość długa ([email protected].
de) badź
˛ 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˛eść przekształcania nazw zależy w dużym stopniu od dotychczasowej infrastruktury
162
Domena Master: BEHOERDE.DE
Istniejaca
˛ przestrzeń nazw DNS wykorzystywana jest do określenia nazwy domeny Master.
Rysunek 3.12: Domena Master: BEHOERDE.DE
◦ nie jest tworzone nowe drzewo nazw
˛ serwery Root
◦ User Principal Name użytkownika jest dość krótka ([email protected])
˛
obydwa drzewa sa˛ 2nd Level Domain
◦ wewn˛etrzna i zewn˛etrzna przestrzeń nazw pozostaja˛ oddzielne
Wada˛ takiego rozwiazania
˛
jest to, że:
◦ nie można wybrać platformy usług DNS
◦ przekształcanie nazw zależy wyłacznie
˛
od dotychczasowej infrastruktury
163
Domena Master: NEU.DE
Niniejsze rozwini˛ecie jest niezależne od dotychczasowej przestrzeni nazw i tworzy nowe wewn˛etrzne drzewo nazw DNS. Wybrana powyżej nazwa NEU.DE jest jedyna na świecie i oficjalnie zarejestrowana.
Rysunek 3.13: Domena Master: NEU.DE
◦ tworzone jest nowe drzewo nazw, dzi˛eki czemu nie sa˛ przejmowane stare obciażenia
˛
˛ serwery Root
◦ można wybrać platform˛e usług DNS
˛
obynd
dwa drzewa sa˛ 2 Level Domain
◦ przekształcanie nazw zależy w małym stopniu od dotychczasowej infrastruktury
◦ wewn˛etrzna i zewn˛etrzna przestrzeń nazw pozostaja˛ oddzielne, odpowiednio do późniejszych wymagań
164
Wada˛ powyższego rozwiazania
˛
jest to, że:
◦ tworzone jest nowe drzewo nazw, co powoduje powstawanie nowych struktur i dodatkowych wytycznych
◦ rośnie stopień skomplikowania ustawień DNS oraz nakład pracy administracyjnej.
Master i structure domain: NEU.DE / INTRA.NEU.DE
Powyższe rozwini˛ecie jest niezależ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łuży wyłacznie
˛
jako master domain ogólnej struktury, jako tak
zwana domena struktury. Poniżej konta użytkowników zakładane sa˛ w poddomenie INTRA.
Rysunek 3.14: Domena Master i domena struktury: NEU.DE / INTRA.NEU.DE
Zaleta˛ powyższej structur domain jest to, że:
˛
˛ serwery Root
165
˛
◦ przy powi˛ekszaniu ilości domen nowe domeny można zakotwiczać równolegle z domena˛
INTRA.
◦ wewn˛etrzna i zewn˛etrzna przestrzeń nazw pozostaja˛ oddzielne, odpowiednio do wymagań
˛
jest to, że:
◦ w Active Directory instalowane sa˛ dwie domeny
◦ tworzone jest nowe drzewo nazw, co powoduje konieczność kontrolowania powstawania
nowych struktur i dodatkowych wytycznych
◦ User Principal Name użytkownika jest dość długa ([email protected])
◦ rośnie ilość krzyżowych połaczeń
˛
oraz stopień skomplikowania i nakład pracy administracyjnej.
Master domain: INTRA.BEHOERDE-ONLINE.DE
Istniejaca
˛ zewn˛etrzna przestrzeń nazw DNS wykorzystywana jest do przyjmowania kolejnych domen. Istniejaca
˛ przestrzeń nazw BEHOERDE - ONLINE.DE stosowana była dotychczas
tylko zewn˛etrznie. Należy założyć domen˛e INTRA, która b˛edzie używana tylko wewn˛etrznie.
166
Rysunek 3.15: Domena Master: INTRA.BEHOERDE-ONLINE.DE
˛
˛ serwery Root
˛
◦ przekształcanie nazw zależy w dużym stopniu od dotychczasowej infrastruktury
˛
jest to, że:
◦ User Principal Name użytkownika jest dość długa ([email protected].
de)
˛
oraz stopień skomplikowania i nakład pracy administracyjnej
◦ wewn˛etrzna i zewn˛etrzna przestrzeń nazw nie sa˛ już od siebie niezależne
Domena Master: AMT.LOCAL
Niniejszy dodatek jest niezależ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 powyżej nazwy nie można zatem zarejestrować. Zamiast LOCAL mogłaby
również zostać użyta, chroniona przez RFC 2606 nazwa domeny Top Level, której nigdy nie
grozi to, że zostanie przej˛eta przez społeczność internetowa˛ jako Top Level Domain.
167
Rysunek 3.16: Master domain: AMT.LOCAL
Zaleta˛ powyższej master domain jest to, że:
˛
˛ serwery Root
˛
˛
jest to, że:
◦ wewn˛etrzna i zewn˛etrzna przestrzeń nazw zostaja˛ na stałe od siebie oddzielone
˛
oraz stopień skomplikowania i nakład pracy administracyjnej
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 należy podporzadkować
˛
własne zamierzenia nadrz˛ednemu interesowi, co może
spowodować widoczne wydłuż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˛ można zarzadzać
˛
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
można przyporzadkować
˛
do 863 atrybutów (wraz z E2K, HIS oraz ISA: 1928).
Zasadniczo istnieje możliwość rozszerzania niniejszego schematu i przypisywania istnieja˛
cym klasom nowych atrybutów. W Windows 2000 raz uruchomionych rozszerze ń schematu
nie można już zmienić. Można je jedynie dezaktywować.
Podział Active Directory, wzgl˛ednie bazy danych nast˛epuje w oparciu o jedność struktury
domeny. Zatem nie jest możliwy podział wewnatrz
˛ domeny w sensie zdecentralizowanej bazy
danych.
Replikacja Active Directory badź
˛ bazy danych nast˛epuje pomi˛edzy kontrolerami domeny
(DC). Odbywa si˛e ona w oparciu o tak zwany Unique Sequence Number (USN), którym można
zarzadzać
˛
aż do poziomu atrybutów. Dzi˛eki temu replikacja może być realizowana na poziomie
atrybutów. Jeśli zatem zmienia˛ si˛e właściwości obiektu, wówczas replikowana b˛edzie jedynie
zmieniona właściwość, a nie cały obiekt.
Każdy DC w Active Directory udost˛epnia usług˛e LDAP. Obsługiwana jest LDAP w wersji
3. Za pomoca˛ klienta LDAP można przeszukiwać i administrować Active Directory. Dzi˛eki Distinguished Name istnieje możliwość każdorazowego czytania i zapisywania obiektu. Poniżej
zamieściliśmy przykładowa˛ ścieżk˛e:
LDAP.LDAP://dc001.behoerde.de/cn=Grzegorz Brz˛eczyszczykiewicz, ou=komórka, ou=dział, dc=behoerde,
dc=de.
169
Nazwa dc001.behoerde.de oznacza, w nomenklaturze DNS, DC (a takż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 można zastosować dowolna˛ implementacj˛e LDAP,
np. OpenLDAP badź
˛ interfejs programu, taki jak:
◦ ADSI (Active Directory Services Interface (zintegrowany w Windows 2000)
◦ LDIF (LDAP Data Interchange Format)
◦ i inne.
Korzystanie z powyższych interfejsów jest problematyczne, gdyż:
◦ pewne atrybuty albo obiekty sa˛ suwerennie zarzadzane
˛
z Active Directory (np. atrybuty
SID albo GUID),
◦ pewne atrybuty składaja˛ si˛e z wartości binarnych albo wartości Hash, których algorytmy
deszyfrujace
˛ i szyfrujace
˛ nie sa˛ znane (np. atrybut userParameters) i można je modyfikować tylko spoza LDAP poprzez oddzielne interfejsy (np. Windows Terminal Server API).
◦ Korzystanie z graficznego interfejsu użytkownika (MMC) wywołuje oprócz czystego zapisywania atrybutów LDAP dodatkowe procesy (np. podczas okreś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 uż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
Wersja serwera Windows 2000 dostarczana jest wraz z całym szeregiem graficznych narz˛edzi do
zarzadzania
˛
informacjami, kontami użytkowników i grup albo konfiguracja˛ DNS, składowanymi
standardowo w Active Directory. Ponadto korzystać można z narz˛edzi znanych z Windows NT
170
działajacych
˛
pod konsola,˛ które umożliwiaja˛ zakładanie, usuwanie i edycj˛e użytkowników i grup.
Jednakże narz˛edzia te pozwalaja˛ tylko zarzadzać
˛
cz˛eścia˛ informacji o kontach zapisanych w
Active Directory.
Oprócz tego dost˛epny jest konsolowy program ldifde umoż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 doś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 użytkowników.
Dzi˛eki ADSI (Active Directory Service Interface) istnieje interfejs oparty na COM, za pomoca˛ którego można zautomatyzować wiele zadań.
3.7.3.8
Certyfikacja
Windows 2000 stworzył możliwość tworzenia tak zwanych PKI (Public Key Infrastructure). Certification Authority (CA) można zarówno zintegrować w AD, jak i zainstalować oddzielnie. Jeśli
wybrany zostanie wariant integracji w AD, wówczas w wewn˛etrznej sieci b˛eda˛ obsługiwane
nast˛epujace
˛ technologie bezpieczeństwa, wzgl˛ednie umożliwione zostanie korzystanie z nich:
◦ EFS (Encrypted File System)
◦ IPsec
◦ SmartCard
◦ szyfrowanie i podpisy cyfrowe (e - mail)
◦ i inne.
Przydzielanie badź
˛ aktywacja PKI obsługiwane sa˛ przez wytyczne grup. Jednak nie oznacza to,
że oddzielne rozwiazania
˛
administracyjne dotyczace
˛ zarzadzania
˛
kluczami staja˛ si˛e zb˛edne.
3.7.3.9
Smart Card
Wskutek zbudowania wewn˛etrznego PKI autoryzacja użytkowników może odbywać si˛e poprzez
SmartCard. Zgłoszenia via SmartCard do komputerów Windows 2000 / XP moga˛ być realizowane bez stosowania dodatkowego oprogramowania.
171
˛ - Samba i Open LDAP
3.7.4.1
Centralne wymaganie, które ma spełniać usługa katalogowa polega na szybkim udost˛epnianiu
informacji w sieci. Ponadto powinna ona oferować nast˛epujace
˛ funkcje:
◦ możliwość zmiany informacji udost˛epnianych w katalogu
◦ możliwość hierarchicznego uporzadkowania
˛
obiektów w katalogu
◦ stosowanie zgodnych ze standardami i rozpowszechnionych schematów w celu zagwarantowania wysokiej kompatybilności za pomoca˛ możliwie wielu aplikacji. Możliwość
rozszerzania o własne obiekty i schematy.
◦ możliwość autoryzacji użytkowników oraz integracja z innymi usługami autoryzacji (Kerberos)
◦ administrowanie prawami dost˛epu
◦ stosowanie otwartych standardów w celu zwi˛ekszenia kompatybilności możliwie ze wszystkimi usługami i aplikacjami, które moga˛ korzystać z informacji zapisanych w katalogu
◦ obsługa procesu replikacji
◦ stosowanie bezpiecznych protokołów transmisji podczas przekazywania informacji pomi˛edzy klientem a usługa˛ katalogowa,
˛ jak również podczas replikacji.
3.7.4.2
Oceniane produkty
Jeśli wymagane jest zastapienie
˛
domeny Windows NT usługa˛ katalogowa˛ oparta˛ na Microsoft
Windows albo Linuksie, wówczas w pierwszej linii należy uwzgl˛ednić 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,
gdyż wymagaja˛ one wprowadzenia dodatkowych produktów i przez to podnosza˛ stopień skomplikowania środowisk IT opartych na Windowsie badź
˛ Linuksie.
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
domyślny protokół (LDAP)
X
X
możliwość bezpiecznego dost˛epu poprzez
X
X
X
X
klient bez dodatkowego
W IN NT
X
oprogramowania
możliwość budowania hierarchicznej
struktury katalogu
rozszerzalność o własne atrybuty
i klasy obiektów
zestaw znaków dla katalogowanych danych
Unicode
możliwość 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
możliwość zintegrowania Kerberos
X26
X
możliwość stosowania niezależ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 można wykorzystywać domen Active Directory do autoryzacji komputerów opartych o Windows 95 / 98 / Me / NT.
173
przydzielanie zadań 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 oddzielić od siebie temat autoryzacji i usług katalogowych. Ponieważ jednak usługa
katalogowa może pełnić wi˛ecej zadań niż autoryzacja, a autoryzacja jest usługa˛ infrastrukturalna,
˛
w rozdziale 3.4 „Autoryzacja“ oceniliśmy z jednej strony autoryzacj˛e na gruncie Linuksa, Samby
i OpenLDAP, a z drugiej strony takż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 możliwe staje si˛e uproszczenie całego szeregu zadań administracyjnych. Należa˛ do nich:
◦ inwentaryzacja dost˛epnego osprz˛etu
◦ tworzenie i zarzadzanie
˛
wpisami nazw DNS
◦ tworzenie i zarzadzanie
˛
konfiguracjami DHCP
◦ dla klientów windowsowych można zapisywać konta maszyn razem z w/w informacjami
Ponadto informacje te nie musza˛ być przydzielane do komputerów r˛ecznie lub w drodze innego
post˛epowania, lecz moga˛ być dystrybuowane do odpowiednich systemów za pomoca˛ replikacji
LDAP.
W Linuksie można obecnie korzystać z całego szeregu programów umożliwiajacych
˛
czytanie
informacji o hostach bezpoś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 uż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
˛
174
◦ dla standardowego serwera DHCP (ISC DHCPD) istnieje łata, dzi˛eki której możliwe jest
czytanie konfiguracji DHCP z katalogu LDAP.
◦ http://home.ntelos.net/~masneyb/dhcp-3.0.1rc11-ldap-patch
◦ dla BIND 9 istnieje również łata umożliwiajaca
˛ zastapienie
˛
przez LDAP plików strefowych.
◦ http://www.venaas.no/dns/bind/bind-sdb/
◦ Samba potrafi pobierać informacje o kontach maszyn bezpośrednio z katalogu LDAP.
Oprócz tego istnieje cały szereg własnościowych oraz wolnych programów umożliwiajacych
˛
przeź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 użytkownikach, grupach i hostach, dzi˛eki oferowanej przez nie dost˛epności zwi˛eksza si˛e możliwość
korzystania z wielu innych aplikacji. Zrezygnowaliśmy z przedstawienia w tym miejscu pełnej
listy aplikacji kompatybilnych z LDAP. Ważna jest jednak wskazówka, ż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ółpracować zarówno z OpenLDAP, jak
i z Active Directory jako usługa˛ katalogowej.
3.7.4.7
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 zawartości katalogu
oraz do automatycznej edycji katalogu. Także do zarzadzania
˛
użytkownikami i grupami udost˛epnianych jest kilka konsolowych narz˛edzi.
Wolne, graficzne narz˛edzia dla Linuksa służace
˛ do opartego na usłudze katalogowej zarza˛
dzania użytkownikami i grupami znajduja˛ si˛e obecnie w fazie rozwoju (np. directory - administrator: http://diradmin.open-it.org/files.php).
Równie ważne sa˛ elastyczne narz˛edzia WWW do zarzadzania
˛
kontami użytkowników, grup
oraz maszyn i innymi obiektami (mailing - lists, wpisy DNS, itd.) wewnatrz
˛ usług katalogowych.
175
Zaleta˛ tego typu rozwiazań
˛
jest to, że można z nich korzystać z poziomu przegladarki
˛
WWW,
niezależnie od serwera, przy czym stosowana jest bezpieczna transmisja danych (SSL / TLS) 31 .
3.7.4.8
Zachowanie podczas pracy i zużycie zasobów
Linux i OpenLDAP okazały si˛e być stabilne oraz wystarczajaco
˛ performant w środowiskach złożonych z ponad 10.000 użytkowników. W różnych testach i dużych instalacjach Samba okazała
si˛e być bardzo pewna, stabilna i w porównaniu z serwerami windowsowymi zasobooszcz˛edna.
3.7.4.9
Akceptacja użytkowników
Usługi katalogowe sa˛ z poczatku
˛ niewidoczne dla użytkownika końcowego i staja˛ si˛e stopniowo
widoczne wraz z przyłaczaniem
˛
aplikacji do katalogu. Im wi˛ecej aplikacji korzysta z katalogu,
tym wyższe jest prawdopodobieństwo, że użytkownicy b˛eda˛ spotykać spójne dane, co doprowadzi do wzrostu akceptacji.
Migracja do Samby / OpenLDAP może być przeźroczysta dla użytkowników i klientów, co
sprawi że nie zauważa˛ oni zmian wynikajacych
˛
z migracji.
Administratorzy odniosa˛ korzyści z usługi katalogowej wskutek wprowadzenia administrowania Single Point. Z usługi katalogowej można korzystać tym lepiej, im lepiej dost˛epne narz˛edzia dopasowane sa˛ do profilu wykształcenia i codziennych zadań administratora.
3.7.5 Migracja kontynuacyjna - Wprowadzenie do ADS
Migracja usług logowania z Windows NT 4 do Windows 2000 Active Directory wymaga z reguły przygotowania oddzielnego rozwiazania
˛
i praktycznych testów jeszcze zanim ostatecznie
określona zostanie optymalna droga migracji. W celu przedstawienia obrazu przewidywanych
nakładów oraz technicznych warunków krańcowych, w nast˛epujacych
˛
rozdziałach wyjaśniliśmy
pokrótce, jak może wygladać
˛
taka migracja.
3.7.5.1
Kolejność
Jeśli chodzi o kolejność, istnieje bardzo wiele wariantów migracji z Windows NT do Windows
2000. W zwiazku
˛
z tym nie istnieje konieczność integrowania najpierw usług logowania a nast˛epnie klientów lub na odwrót. Nie jest także wymagane przestawianie wielu klientów Windows
NT na zasadzie masowego rollaut. Jedyna˛ rzecza,˛ jaka˛ trzeba mieć 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/).
176
przewiduje si˛e aktualizacj˛e istniejacej
˛ domeny NT (Inplace Upgrade). Wówczas należy najpierw
dokonać aktualizacji PDC tej domeny do Windows 2000.
Active Directory rozróżnia dwa tryby pracy: Mixed Mode i Native Mode. Do Native Mode
można przełaczyć
˛
si˛e dopiero wówczas, gdy nie ma już potrzeby zasilania NT BDCs replika˛
SAM. Przełaczenia
˛
do Native Mode nie można cofnać.
˛ Należy pami˛etać o tym, że Native
Mode jest wymagany w przypadku migracji z restrukturyzacja˛ (patrz „Wariant 2: aktualizacja
plus restrukturyzacja“ w rozdziale 3.7.5.3).
W planowaniu kolejności istnieje potencjał optymalizacyjny, który należy wykorzystać odpowiednio do istniejacego
˛
środowiska.
3.7.5.2
Docelowa architektura
Celem powinna być struktura Active Directory z jedna˛ domena˛ badź
˛ możliwie mała˛ ilościa˛ domen. Mała ilość domen zapewnia z reguły najmniejszy nakład pracy.
Rysunek 3.17: Migracja przez Upgrade albo restrukturyzacj˛e
Odpowiada to zaleceniom projektowym firmy Microsoft, ponieważ Microsoft, jeśli chodzi o
migracj˛e z NT do Windows 2000, przewidział już duża˛ różnorodność dróg migracji oraz wiele
możliwości restrukturyzacji.
3.7.5.3
Przeglad
˛ wariantów migracji
Istnieja˛ nast˛epujace
˛ zasadniczo różne warianty migracji:
177
◦ czysta aktualizacja (Upgrade): należy zachować dotychczasowa˛ struktur˛e domen, co oznacza zaktualizowanie wszystkich domen.
◦ aktualizacja (Upgrade) plus restrukturyzacja: należy zaktualizować jedna˛ albo wi˛ecej domen. Pozostałe domeny NT należy dostosować do nowej struktury.
◦ nowa domena plus restrukturyzacja: domeny nie sa˛ aktualizowane czy restrukturyzowane.
Migracja (kopiowanie) dotyczy tylko zasobów (danych, drukarek, etc.).
Wariant 1: czysta aktualizacja
Czysta aktualizacja (Inplace Upgrade wszystkich domen) oznaczać b˛edzie zachowanie obecnej struktury domen. Możliwa jest póź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 należy założyć nowa˛ domen˛e, wzgl˛ednie nowy AD.
178
Rysunek 3.19: Migracja ADS - nowa domena plus restrukturyzacja
Konta użytkowników oraz globalne grupy domeny kont klonowane sa˛ do nowej domeny (docelowej) (łacznie
˛
z SID-History).
Rysunek 3.20: Migracja ADS - klony użytkowników i grup
179
Zaleta˛ powyższego sposobu post˛epowania jest to, że:
◦ migracja nie powoduje przerw w pracy użytkowników
◦ istnieje bardzo dobry Fallback
◦ można odsunać
˛ w czasie nowe przypisanie uprawnień (ReACLing); nie jest ono krytyczne,
jeśli chodzi o czas.
Wada˛ jest:
◦ konieczność istnienia dodatkowego ADS wraz z osprz˛etem.
Wariant 4: świat równoległy a migracja zasobów
Najpierw należy założyć nowa˛ domen˛e, wzgl˛ednie nowy ADS.
Rysunek 3.21: Migracja ADS - świat równoległy a migracja zasobów
Świat równoległy wypełniany jest nowymi kontami użytkowników i nowymi grupami. Dotychczasowe zasoby kopiowane sa˛ do nowego świata.
180
Rysunek 3.22: Migracja ADS - wypełnianie równoległego świata kontami użytkownika oraz
grupami
Zaleta˛ powyższego rozwiazania
˛
jest to, że:
◦ migracja na serwerach nie jest krytyczna, jeśli chodzi o czas
◦ nie ma historii SID
◦ musza˛ być znane prawa dost˛epu i należy je odwzorować w nowym świecie
◦ migracja danych może oznaczać redukcj˛e danych.
Wada˛ jest to, że:
◦ migracja danych wymaga dużych nakładów logistycznych, jeśli chodzi o wspólny dost˛ep
◦ w czasie migracji danych trzeba dysponować dodatkowym osprz˛etem
3.7.5.4
181
Zadania migracyjne
Migracja (zastapienie
˛
NT) badź
˛ też całkowite wprowadzenie od nowa Windows 2000 Active
Directory, wymaga starannego zaplanowania i oceny w środowiskach testowych.
Podczas planowania migracji wymagane jest wykonanie nast˛epujacych
˛
zadań:
◦ prezentacja istniejacej
˛ infrastruktury w formie pisemnej
◦ rozpoznanie wymagań zwiazanych
˛
z nowym środowiskiem
◦ rozpoznanie technicznych oraz organizacyjnych warunków brzegowych
◦ ocena obecnego ś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łoś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 wymieniliśmy poniż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 możliwe jest tworzenie własnych partycji dla aplikacji innych producentów, na których można składać wi˛ecej dynamicznych
danych. Takie dynamiczne dane można później lepiej kontrolować, jeśli chodzi o proces
replikacji. Właśnie na takiej partycji należy składować dane DNS Active Directory zintegrowane w AD.
182
◦ Przewiduje si˛e, że Windows 2003 zaoferuje możliwość tworzenia oddzielnych serwerów LDAP bez koniecznoś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 możliwość tworzenia dla aplikacji usług
LDAP, bez konieczności zmian schematu AD.
3.7.5.6
Active Directory w minimalnej postaci
Jak już wspomnieliśmy, Active Directory oferuje łacznie
˛
wiele technologii i funkcjonalności,
które zasadniczo ułatwiaja˛ korzystanie z nowych funkcji i / albo efektywna˛ prac˛e w środowiskach IT. W takich przypadkach rośnie zależność od produktów, wzgl˛ednie technologii firmy
Microsoft.
Jeśli nie chcemy, aby tak było, możemy wyznaczyć sobie cel, którym jest minimalne korzystanie z Windows 2000 Active Directory. Poniżej opisaliśmy pokrótce, jak mogłaby wygladać
˛
taka konstelacja.
Active Directory stosowany w minimalnym zakresie posiada nast˛epujace
˛ właściwości, wzgl˛ednie prac˛e z nim należy podporzadkować
˛
nast˛epujacym
˛
krokom.
◦ Infrastruktura DNS powinna opierać si˛e nie na Windows 2000, lecz na niezależnej implementacji, która odpowiada minimalnym wymaganiom. Ewentualnie konieczne b˛edzie
r˛eczne wprowadzanie SRV Records w DNS.
◦ Należy zrezygnować z jednej ogólnej struktury. Relacje zaufania pomi˛edzy domenami należy realizować w tradycyjny sposób.
Cel: by każda dotychczasowa domena Windows NT mogła zarzadzać
˛
swoim własnym
schematem we własnej ogólnej strukturze.
◦ Ponadto, jeśli domeny nie b˛eda˛ pracować w trybie „Native Mode“, wówczas zmniejszy si˛e
„niebezpieczeństwo“ używania zwiazanych
˛
z nim, rozszerzonych grup.
◦ Należy także zrezygnować z budowy struktury OU wewnatrz
˛ domen.
Cel: by poprzez utworzona˛ struktur˛e umożliwić działanie dodatkowych funkcji, tak aby
móc si˛e „jednak później“ do nich odwołać.
◦ W „Default Domain Policy“ należy ograniczyć stosowanie wytycznych grup do ustawień
bezpieczeństwa (np. hasła (czas ważności, minimalna długość, etc.), ustawień kontrolnych
(Auditing)). Jest to konieczne do adekwatnego zastapienia
˛
ustawień Windows NT.
183
◦ Zasadniczo należy zrezygnować ze stosowania PKI (Public Key Infrastructure) opartych
na AD, która byłaby wymagana, np. dla EFS albo IPsec.
◦ Należy zastosować DFS (Distributed File System) oparty na AD
Cel: by uniknać
˛ dodatkowych zależności powstajacych
˛
w AD wskutek zintegrowanego
zapisu.
◦ O ile nie jest wykorzystywany Exchange 2000, nie należy używać dodatkowych atrybutów
obiektów użytkownika. Należy ograniczyć si˛e do stosowania obligatoryjnych atrybutów.
Cel: by AD nie był stosowany jako miejsce zapisu danych osobowych, dzi˛eki czemu zredukuje si˛e możliwość powstawania dalszych zależności (np. aplikacje innych producentów,
które wysyłaja˛ zapytania o te dane przez LDAP).
◦ Nie należy używać obiektów kontaktowych w AD.
Cel: wskutek nagromadzenia tego typu informacji w AD, zwi˛eksza si˛e uzależnienie.
◦ Nie należy publikować drukarek lub zasobów w Active Directory.
Cel: by użytkownicy nie przyzwyczaili si˛e do odnajdywania zasobów w ten sposób.
Wskazówka: Wymienione właściwości / kroki z reguły przeszkadzaja˛ w osiagni˛
˛ eciu maksymalnej wydajności, która˛ można uzyskać za pomoca˛ Active Directory. Jest to cena zwi˛ekszonej
niezależności.
W przeciwień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 pracować poza zakresem domen w
jednej organizacji Exchange, nie należy obchodzić użycia jednej ogólnej struktury, gdyż w przeciwnym razie zabraknie funkcji katalogu globalnego.
3.8 Middleware - COM, .NET, J2EE
Z technicznej oceny wyraźnie wynika, że dotychczasowa technologia składników (COM, DCOM)
firmy Microsoft jest wprawdzie nadal stosowana, lecz jednocześnie ma miejsce zmiana technologii zwiazana
˛
z wprowadzaniem .NET-Framework. Alternatywna˛ platforma˛ wspomnianej, nowej
technologii może być Java 2 Enterprise Edition (J2EE). Zasadniczymi różnicami pomi˛edzy tymi
dwiema technologiami, które odgrywaja˛ główne role, jeśli chodzi o oceniane w dalszej cz˛eści
Web - Services, sa:
˛ uzależnienie od danej platformy, obsługiwane j˛ezyki programowania i ilość
dostawców rozwiazań.
˛
Nast˛epujaca
˛ tabela wskazuje dalsze różnice.
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łużył w pierwszym
rz˛edzie do tworzenia Compound Documents. COM jest standardem binarnym dla składników i
dlatego jest niezależny od j˛ezyków programowania. Składniki COM można tworzyć za pomoca˛
różnych j˛ezyków programowania, do których należa˛ m.in.:
◦ C++
185
◦ C
◦ Java
◦ Visual Basic
◦ Delphi.
Jednocześnie w przypadku niektórych z w/w j˛ezyków składniki COM moga˛ być nawet ponownie używane. Jedynym wymaganiem wzgl˛edem j˛ezyka programowania jest to, żeby mogły być
realizowane struktury instrukcji i by możliwe było zewn˛etrzne badź
˛ 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).
Jeśli chodzi o protokoły transportu, COM oferuje, dzi˛eki usłudze Distributed COM (DCOM),
neutralne Middleware umożliwiajace
˛ korzystanie z odległych składników na innych komputerach. DCOM należ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 może w teorii działać na różnych protokołach transportu (np. TCP / IP, IPX / SPX), a także na HTTP. Korzystanie z HTTP możliwe jest za pomoca˛ COM Internet Services (CIS) z IIS w wersji 4, w którym protokół DCOM tunelowany jest
przez HTTP. Bezpieczeństwem DCOM można zarzadzać
˛
stosujac
˛ DCOM Configuration Utility
(DCOMCNFG.exe). Narz˛edzie to służy w szczególności do ustalenia, który wymiar impersonifikacji należy zastosować, czyli do ustalenia zdolności software routine do zmiany kontekstu
użytkownika.
Stosowanie składników COM możliwe jest tylko w Windows. Aplikacje, które z nich korzystaja,˛ trzeba dostosowywać do przeportowania na inna˛ platform˛e.
Rozszerzeniem COM i DCOM w Windows 2000 jest COM+.
186
3.8.2 „.NET”
Na poczatku
˛ trzeba wyjaśnić kilka centralnych poj˛eć co rusz wyst˛epujacych
˛
w zwiazku
˛
z „.NET“.
W tym celu przedstawiliśmy poniż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 użytkowników w jeden jednolity i spersonalizowany sposób.
.NET Framework: ś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 użytkownika i zbiór usług XML, które
ułatwiaja˛ integracj˛e izolowanych „wysp plików“. .NET My Services zorientowane sa˛ na użytkownika a nie na określone urzadzenie,
˛
sieć albo aplikacj˛e.
Platforma .NET: składa si˛e z narz˛edzi, urzadzeń,
˛
XML - Web Services oraz doświadczeń
serwera i użytkowników
W dalszej cz˛eści dokonaliśmy w pierwszym rz˛edzie bliższej oceny technologii .NET - Framework, jako rozwiazania
˛
Middleware. Jest ono w pewien sposób zbliżone do Java Virtual Machine (JVM), ponieważ poprzez instalacj˛e Frameworks (np. w Windows 2000) abstrahuje si˛e
od interfejsów integralnych cz˛eś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.
187
Rysunek 3.23: Składniki .Net-Frameworks
Aplikacje pisane sa˛ w j˛ezyku obsługujacym
˛
„.NET“ i moga˛ odwoływać si˛e do obszernych
bibliotek klas „.NET“. „.NET“ Framework obsługuje duża˛ ilość j˛ezyków programowania. Każdorazowy kompilator tłumaczy kod źródłowy na kod wykonywalny (a nie kod maszynowy),
który określany jest mianem Intermediate Language (IL). Wynikiem niniejszej akcji jest, np. plik
EXE. Jeś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.
188
Do tworzenia kodu źródłowego Microsoft oferuje:
◦ z jednej strony bezpłatny Software Developer Kit (SDK), który wystarczy już do tworzenia
programów „.NET“.
◦ z drugiej strony Visual Studio .NET, nast˛epc˛e dotychczasowego Visual Studio Version 6.
.NET - Framework może być używany, w przeciwień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. Ważnymi cz˛eś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ływać klienty. Enterprise - Beans instalowane sa˛ po
stronie serwera w EJB - Container. Pojemnik udost˛epnia im określone usługi oraz ś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 możliwość
odkładania referencji do odległych obiektów
– pod określona˛ nazwa˛ oraz
– w zdefiniowanym miejscu (Binding).
Z drugiej strony dzi˛eki JNDI możliwe jest odnajdywanie powiazanych
˛
obiektów poprzez
ich nazwy (Lookup).
◦ Java IDL / CORBA
Java IDL tworzy interfejs do CORBA, za pomoca˛ Java IDL można implementować 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:
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 można integrować różne platformy i aplikacje niezależnie
od producenta, w oparciu o standardy.
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 sieć
◦ Internet jako centralna infrastruktura
◦ przegladarka
˛
WWW, jako nadrz˛edny User Interface, „Rich Clients“ jako podrz˛edny User
Interface.
Różnice pomi˛edzy obydwiema platformami zostały pokazane już podczas oceny .NET - Frameworks.
Z powodu wyższej elastyczności, jak też niezależności od producenta czy platformy, należy
uznać pierwszeństwo J2EE, co pokrywa si˛e także z zaleceniami SAGA 32.
Jak jednak wyglada
˛ kompatybilność pomi˛edzy .NET i J2EE? Jeś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, że SOAP w aktualnej wersji 1.1 zezwala jeszcze
na bardzo duża˛ dowolność, co może prowadzić do praktycznej utraty kompatybilności. Jednak
celem Web - Services musi być kompatybilność. Ma być ona szczególnie zagwarantowana przez
SOAP w wersji 1.2.
3.9.2 Podstawy
Web Service to usługa, do której może odwołać 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 przeźroczysta. Web Service jest „czarna˛ skrzynka“,
˛ która˛ można postrzegać jako określona˛ funkcjonalność i której można używać w sposób elastyczny bez znajomości
szczegółów implementacji. Web Services udost˛epniaja˛ swoje funkcjonalności światu zewn˛etrznemu za pośrednictwem dobrze zdefiniowanych interfejsów. Interfejsy te nazywane sa˛ takż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.
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). Programiści
moga˛ na tej podstawie łaczyć
˛
ze soba˛ najróżniejsze usługi i integrować je w jedna˛ kompletna˛
aplikacj˛e. Wyszukiwanie takiej usługi może odbywać si˛e za pomoca˛ UDDI (Universal Description Discovery and Integration). UDDI jest specyfikacja˛ oparta˛ na standardach, służac
˛ a˛ do opisu
i wyszukiwania Web Services, a zatem jest ona repozytorium Web Services. W tak zwanym
mi˛edzyczasie firmy IBM, Microsoft i inni producenci stworzyli pierwsze implementacje.
W przeciwieństwie do aktualnych obecnie technologii opartych na składnikach, Web Services nie wykorzystuja˛ protokołów „specyficznych dla obiektu“, takich jak DCOM, IIOP albo
RMI, ponieważ z reguły wymagaja˛ one do płynnej pracy korzystania z homogenicznej infrastruktury, jeś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 wiadomość opakowana˛ w XML do
serwera, który odpowiada na zapytanie również wiadomościa˛ XML. W ten sposób Web Services sa˛ całkowicie niezależne od określonych j˛ezyków programowania i platform systemowych.
Dopóki obydwie strony b˛eda˛ używały jednolitego formatu wiadomości i b˛eda˛ si˛e stosować do
wspólnie zdefiniowanej kolejności wywołań, rodzaj implementacji usługi (Web Services) b˛edzie
rzecza˛ drugoplanowa.
˛ Może on wyczerpać wszelkie możliwości platformy, na której jest właśnie
używany. Uogólnieniem powyższej zasady jest SOAP. Simple Object Access Protokoll definiuje
to, w jaki sposób musza˛ być zbudowane wiadomości XML i jak musi wygladać
˛ kolejność wywołań. Dzi˛eki temu najróżniejsze aplikacje, które pracuja˛ na różnych platformach, można ze soba˛
łaczyć
˛
i integrować z istniejacymi
˛
rozwiazaniami.
˛
Jedynym wymogiem jest to, żeby aplikacje te
komunikowały si˛e ze soba˛ poprzez SOAP. Sam SOAP może nakładać si˛e na różne protokoły (np.
HTTP, SMTP). SOAP jest prostym, nieskomplikowanym mechanizmem służacym
˛
do wymiany
ustrukturyzowanych i wytypowanych informacji pomi˛edzy systemami w zdecentralizowanym,
dzielonym środowisku za pomoca˛ XML. SOAP ma jednak wad˛e polegajac
˛ a˛ na tym, że jest dość
wolny. Składa si˛e on z trzech cz˛eści. Okładka SOAP (envelope) definiuje Framework dla każdej
wiadomości. Komunikuje ona odbiorcy, jaka˛ treść zawiera wiadomość, do kogo wiadomość jest
skierowana i czy chodzi o wiadomość opcjonalna,˛ czy obligatoryjna.
˛ Istnieja˛ zasady kodowania; wewnatrz
˛ SOAP - Frameworks zasady kodowania określaja˛ sposób kodowania danych (np.
liczb). XML wykazuje si˛e zasadami kodowania, które odznaczaja˛ si˛e duża˛ elastycznościa.˛ SOAP
nie jest tak elastyczny, ponieważ definiowany tu jest ograniczony szereg zasad, co jednak nie ma
znaczenia.
Za pomoca˛ Web Services możliwa staje si˛e realizacja integracji różnych platform i aplikacji
192
niezależ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 przeważnie o nowe wydanie Windows DNA (Distributed interNet Applications Architecture).
.NET zawiera własny Service Layer dla Web Services. Poniższy rysunek (rysunek 3.25) pokazuje zwiazki
˛ poszczególnych cz˛eści składowych pod katem
˛
Web Services.
Rysunek 3.25: Microsoft .NET- Framework
193
Przez wprowadzenie technologii ASP.NET, nast˛epczyni Active Server Pager, zrealizowano
nast˛epujace
˛ cele:
◦ uzyskano możliwie proste i zmienne środowisko programowania
oraz
◦ omawiane Web Services.
Z drugiej strony Visual Studio .NET oferuje możliwość 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, że programów w nim napisanych można używać niezależnie od platformy. Pierwotnie
J2EE była architektura˛ rozwijana˛ dla aplikacji pracujacych
˛
po stronie serwera. Póź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 pośrednictwem JDBC (Java Database Connectivity) i może również korzystać z zewn˛etrznych Web Services. Dost˛ep do aplikacji J2EE moż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 bezpoś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).
Środowiska programowania oferowane sa˛ przez róż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
drukować łańcucha znaków. W porównaniu z HTML (Hypertext Markup Language) XML posiada nast˛epujace
˛ zalety:
194
◦ XML oddziela struktur˛e dokumentu od warstwy prezentacji. XML nie używa poleceń formatowania. Formatowanie musi być zdefiniowane poprzez Style Sheet.
◦ w XML istnieje możliwość zdefiniowania dowolnych struktur za pomoca˛ własnych elementów i atrybutów.
◦ za pomoca˛ parsera XML istnieje możliwość sprawdzania struktury pod katem
˛
jej ważności
w oparciu o definicj˛e struktury.
XML oczekuje tak zwanego „wellformedness“ (właściwego formułowania) osadzonego w regułach, np. „nazwy elementów rozróżniaja˛ pisowni˛e wielka˛ i mała˛ litera“.
˛
Dokumenty XML zawieraja˛ szczególne elementy, tj. Processing Instructions (PIs), w których
można zapisywać instrukcje dla parsera XML (np. style sheets).
Poprzez definicje struktury ustalane sa˛ obowiazuj
˛ ace
˛ struktury dokumentów XML. Nazywane sa˛ one także Vokabular. Definicje struktury moga˛ być tworzone za pomoca˛ Document Type
Definition (DTD) albo schematów XML.
Aby jednoznacznie zdefiniować nazwy elementów, można zdefiniować przestrzeń nazw jako
XML - Namespace.
XSL (Extensible Style Sheet Language) jest j˛ezykiem opartym na XML, służacym
˛
do konwersji dokumentów XML do HTML albo innych dokumentów XML. Konwersj˛e XSL wykonuje
procesor XSL.
XML już dzisiaj odgrywa duża˛ rol˛e, a w przyszłoś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 umożliwia niezależna˛ od platformy prezentacj˛e wszystkich istnieja˛
cych danych i przede wszystkim edycj˛e danych (także treści dokumentów) ponad granicami systemu w taki sposób, że nikt nie musi si˛e troszczyć o prezentacj˛e. Doprowadzi to w przyszłości w
dużym stopniu do wyraźnego wzrostu produkcyjności podczas tworzenia dokumentów. Obecnie
użytkownicy pakietów biurowych sp˛edzaja˛ znaczna˛ cz˛eść swojego czasu pracy nad opracowywaniem właściwej formy dokumentu, który maja˛ stworzyć. Wymagana jest przy tym od użytkowników zdolność projektowania, pod katem
˛
której nie zostali wykształceni. Wskutek tego
ukształtowanie dokumentu zajmuje wi˛ecej czasu, niż zadanie b˛edace
˛ sednem pracy powierzonej
pracownikowi administracji. Dzi˛eki oddzieleniu warstwy treści od warstwy prezentacji pracownik administracji b˛edzie mógł znowu skoncentrować si˛e na swoich zadaniach i produktywnie
wykorzystywać swój czas pracy. Prezentacj˛e treści b˛edzie można pozostawić odpowiedzialnym
195
osobom, które b˛eda˛ raz, centralnie i w jednolity sposób dla wszystkich ustalać i kotwiczyć definicje.
XML jest również dość elastyczny, by można go było w każdej chwili dostosować do nowych
potrzeb.
Zgodnie z SAGA j˛ezyk XML powinien służyć jako uniwersalny i naczelny standard wymiany danych we wszystkich ważnych administracyjnych systemach informacyjnych 33. „Nowo
tworzone systemy powinny być w stanie wymieniać dane w formacie XML. Istniejace
˛ systemy
nie musza˛ obowiazkowo
˛
tego umieć“34.
Takż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
˛
Jeś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ównież serwer Apache.
Nie sa˛ znane ograniczenia techniczne, które uniemożliwiałyby korzystanie z serwera Apache.
Oferuje on wszystkie funkcjonalności konieczne dla zastosowań produkcyjnych. W rzeczywistości Apache udowodnił swoja˛ przydatność w licznych scenariuszach zastosowań.
W konkretnych przypadkach należy jednak dokładnie omówić nakłady zwiazane
˛
z projektem migracyjnym. W przypadku migracji prostych stron HTML badź
˛ aplikacji CGI, nakłady
migracyjne z reguły utrzymaja˛ si˛e w przewidywalnych ramach.
W przeciwieństwie do tego, migracja aplikacji, w szczególności służacych
˛
do generowania
dynamicznych treś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,
ponieważ istnieje do dyspozycji wystarczajaca
˛ ilość 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
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 żadanych
˛
treści. Zadaniem serwerów WWW jest także
dostarczanie żadanych
˛
dynamicznych treści, np. poprzez aplikacj˛e bazodanowa˛ do systemów
klienckich. Za pośrednictwem określonych interfejsów możliwe jest również zlecenie uruchamiania po stronie serwera całych programów oraz wykonywania akcji. Akcje inicjalizowane sa˛
z reguły przez systemy klienckie. Umożliwia to wykonywanie procesów klienta po stronie serwera. Wskutek rozprzestrzeniania si˛e Internetu badź
˛ rozwiazań
˛
intranetowych nastapił
˛ wzrost
wymagań wzgl˛edem zadań realizowanych przez serwery WWW. Doprowadziło to do powstania
różnych rozwiazań
˛
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˛eścia˛ Windows NT Server 4.0 Option Pack. W oparciu o system operacyjny
Windows NT 4.0 za pomoca˛ ISS udost˛epniane sa˛ podstawowe funkcjonalności serwera WWW.
W celu zapewnienia sukcesywnej współpracy klienta z serwerem obsługiwane sa˛ tu wszystkie ważne protokoły internetowe:
◦ HTTP 1.1
◦ SMTP
◦ NNTP
◦ FTP.
Obsługa HTTP w ISS 4.0 obejmuje nast˛epujace
˛ usługi:
◦ Pipelining
umożliwia wysyłanie wielu żadań
˛
klientów zanim nastapi
˛ reakcja serwera WWW.
◦ Keep Alives
Dzi˛eki utrzymaniu połaczeń
˛
klient - serwer klient może używać dla wielu żadań
˛
jednego
połaczenia
˛
albo mniejszej ilości połaczeń.
˛
197
◦ HTTP PUT i DELETE
umożliwia usuwanie albo udost˛epnianie plików przez użytkowników poprzez przegladark˛
˛
e
WWW. Obsługa RFC 1867 umożliwia także sterowanie uploads plików za pomoca˛ innych
programów.
Obsługa SMTP udost˛epniana jest poprzez zaimplementowana˛ usług˛e SMTP - Mail służac
˛ a˛ do
wysyłania i odbierania wiadomości SMTP - Mail. Usług˛e t˛e można stosować do komunikacji
pomi˛edzy serwerem WWW i na przykład klientami.
Zintegrowana usługa NNTP (Network News Transport Protocol) umożliwia zakładanie lokalnych grup dyskusyjnych na pojedynczym serwerze. Nie jest moż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 możliwość generowania dynamicznych treści. CGI
jest interfejsem służacym
˛
do wywoływania programów, którymi może posługiwać si˛e serwer.
Pierwotnie CGI zaprojektowane zostało dla środowisk UNIX i w środowisku Windows NT wymaga bardzo wielu zasobów systemowych. Programy CGI maj˛e t˛e zalet˛e, że moga˛ być wykonywane przez niemal każdy serwer WWW oraz, że z reguły można je łatwo napisać.
Internet Service Application Programming Interface (ISAPI) jest bezpośrednim interfejsem
do IIS. Poprzez ISAPI można odwoływać si˛e do obiektów umieszczonych na serwerze.
IIS 4.0 umożliwia, wskutek zastosowania Active Server Pages (ASP), tworzenie dynamicznych stron HTML albo aplikacji WWW. Za pomoca˛ technologii ASP udost˛epniane jest środowisko skryptowe po stronie serwera. Strony ASP sa˛ plikami, które oprócz tradycyjnych znaczników HTML moga˛ także zawierać 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 umożliwia kształtowanie interaktywnych treści
dla użytkowników. Za pomoca˛ ASP można także realizować odwoływanie si˛e do bazy danych.
W zwiazku
˛
z rozwojem stron WWW ISS 4.0 obsługuje nast˛epujace
˛ technologie:
198
◦ Microsoft Script Debugger
umożliwia testowanie aplikacji ASP.
◦ Interfejs programowania COM
umożliwia programistom dost˛ep do składników COM, które odwołuja˛ si˛e do funkcji protokołu ISS.
◦ Java Virtual Machine
umożliwia tworzenie i wykonywanie składników Java wewnatrz
˛ maszyny wirtualnej.
◦ Obiekty administracyjne ISS
umożliwiaja˛ programistom dost˛ep do składników niezb˛ednych do tworzenia programów
administrujacych.
˛
◦ Transakcyjne strony ASP
umożliwiaja˛ stronom ASP i wywoływanym przez nie składnikom bycie cz˛eścia˛ transakcji,
która to transakcja musi być jednak zarzadzana
˛
przez Microsoft Transaction Server (patrz
także 3.11.3.3).
◦ Izolowanie procesów
dzi˛eki tej technologii aplikacje ASP oraz ISAPI (Internet Server - API) moga˛ być wykonywane jako oddzielne procesy. Procesy te wykonywane sa˛ oprócz głównego procesu
serwera.
◦ Załaczanie
˛
i odłaczanie
˛
składników
oznacza, że programiści WWW moga˛ właczać
˛
albo odłaczać
˛
dynamiczne składniki aplikacji WWW.
3.11.3.2
Autoryzacja i bezpieczeństwo
Model bezpieczeństwa jest jednakowy dla wszystkich składników serwera NT. W przypadku IIS
można używać takich samych funkcji, jakimi dysponuje serwer plików albo serwer bazy danych.
Można skorzystać z istniejacych
˛
użytkowników domen i grup w celu nadania ograniczonych i
uprawnień. IIS korzysta z takiej samej bazy danych katalogów, jak inne serwery Windows NT.
Użytkownikom można umożliwić ograniczony dost˛ep do zasobów sieciowych, takich jak strony
HTML, aplikacje WWW oraz pliki. W celu dokładnego przydzielenia uprawnień można także
skorzystać z uprawnień systemu plików NTFS.
199
Zastosowanie Secure Sockets Layer (SSL umożliwia bezpieczna˛ wymian˛e informacji pomi˛edzy klientem a serwerem. Istnieje również możliwość, aby serwery identyfikowały albo autoryzowały klienta a użytkownik nie musiał logować si˛e na serwerze.
Zintegrowany Certificate Server oferuje możliwość 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 funkcjonalności serwera WWW. Składniki opisane poniżej sa˛ również cz˛eścia˛ Windows NT
Option Pack.
Microsoft Transaction Server (MTS)
MTS jest systemem przetwarzajacym
˛
transakcje służacym
˛
do rozwoju, implementacji i zarzadza˛
nia dzielonymi aplikacjami serwera. Przetwarzanie transakcji można wykorzystać na przykład do
realizacji dzielonych aplikacji biznesowych.
Microsoft Script Debugger Microsoft Script Debugger służy do wyszukiwania bł˛edów
w składni plików ASP. Debugger można wykonywać w połaczeniu
˛
z Internet Explorer i w ten
sposób korygować bł˛edy.
Microsoft Index Server Index Server można wykorzystywać w Internecie i / lub Intranecie
jako wyszukiwark˛e. Serwer może naznaczać teksty zapisanej zawartości, która˛ można udost˛epniać użytkownikom do przeszukiwania poprzez formularze WWW. Index Server może oprócz
dokumentów HTML naznaczać także dokumenty Microsoft Word i Microsoft Excel.
Microsoft Message Queue Server Microsoft Message Queue Server (MMQS) pozwala
asynchronicznie komunikować ze soba˛ programy użytkowe poprzez wysyłanie i odbieranie wiadomości.
Microsoft Management Console Microsoft Management Console (MMC) umożliwia zarzadzanie
˛
najróżniejszymi zadaniami poprzez różne sieciowe programy zarzadzaj
˛
ace.
˛ Administrowanie serwerem może odbywać si˛e za pomoca˛ tak zwanych „Snap - Ins“ wewnatrz
˛ konsoli.
200
˛
3.11.4.1
Apache
Aplikacja˛ bardzo cz˛esto stosowana˛ w praktyce w systemach opartych na Linuksie jest serwer
Apache. Jest on najcz˛eściej, bo aż w 60%, wykorzystywanym serwerem WWW 35 na ś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˛ ilość łat. („A patchy web server") i który w 1995 roku posłuż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 takż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 jakości serwer Apache wykorzystywany jest
również w produktach komercyjnych. IBM dostarcza na przykład Apache w ramach produktów
Websphere.
Zakres funkcji
Serwer WWW Apache składa si˛e z rdzenia i dużej ilości modułów, które można wkompilować badź
˛ właczać
˛
w zależności od każdorazowych wymagań. Dzi˛eki modularnej budowie
zakres funkcji serwera Apache daje si˛e bardzo łatwo rozszerzać i można go dopasowywać do
zmienionych wymagań. Normalny zakres dostawy oprogramowania zawiera już wiele różnych
modułów, które można jeszcze uzupełnić o dalsze moduły (np. własne). Moduły Apache sa˛ segmentami kodu, które odpowiadaja˛ specyfikacji API Apache i moga˛ być właczane
˛
do serwera
Apache. Moduły Apache moga˛ być właczane
˛
statycznie na stałe albo dynamicznie poprzez plik
konfiguracyjny serwera WWW. Taka modularna budowa służaca
˛ rozszerzeniu właściwości serwera WWW niezwykle podnosi elastyczność systemu. Wydajność i pr˛edkość serwera WWW
wzrasta, gdy zamiast zewn˛etrznych aplikacji przetwarzane moga˛ być procesy wewn˛etrzne.
Wśród wielu modułów znajduja˛ si˛e moduły autoryzacji, bezpieczeństwa i skryptów, wzgl˛ed35
http://news.netcraft.com/archives/2003/03/
201
nie interpreterów j˛ezyków programowania, takich jak, np. PHP, Java, Python, Tcl i Perl. Istnieja˛
dwie różne możliwości korzystania z modułów:
◦ podczas statycznej kompilacji moduły moga˛ być na stałe właczone
˛
do serwera WWW.
◦ moduły moga˛ być właczane
˛
dynamicznie podczas pracy serwera. Ta tak zwana funkcjonalność DSO (Dynamic Shared Objects) nie wymaga w przypadku zmiany konfiguracji serwera ponownej kompilacji. Wystarczy ponownie uruchomić serwer. Możliwy jest
Graceful-Restart bez przerywania świadczenia usług.
Podczas, gdy wykorzystywane sa˛ rzeczywiście potrzebne moduły, Apache pozostaje mniejszy
niż jego standardowa wersja i zajmuje mniej miejsca w pami˛eci. Jednocześnie mniej modułów
oznacza także mniejsza˛ możliwa˛ powierzchni˛e ataku, dzi˛eki czemu wzrasta bezpieczeń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 bezpoś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 badź
˛ 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
możliwość dostosowania treści do odpowiednich potrzeb.
mod_deflate
202
Służy do kompresji różnych typów danych przed transmisja˛ do
przegladarki
˛
WWW. Ma sens zwłaszcza w przypadku ograniczonych pasm. Kompresja musi być obsługiwana przez przegladark˛
˛
e.
mod_proxy
Rozszerza serwer WWW Apache o funkcjonalność serwera pośredniczacego
˛
badź
˛ Proxy - Caches.
mod_rewrite
Umożliwia stosowanie dowiazań
˛
wewn˛etrznych i zewn˛etrzne Redirects.
mod_speling
Koryguje bł˛edy uż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 użytkowników.
mod_vhost_alias
Służ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łuży do konfiguracji katalogów badź
˛ dokumentów chronionych
hasłami. Bardzo prosty wariant modułu autoryzacji. Powinien być
stosowany tylko dla małej ilości użytkowników.
mod_auth_digest
Autoryzacja użytkowników za pomoca˛ MD5 Digest Authentication. Transmisja haseł nie odbywa si˛e w formie czytelnego tekstu.
mod_auth-dbm
Autoryzacja użytkowników za pomoca˛ plików Berkeley DB. Ma
sens w przypadku zastosowania dla wi˛ekszej ilości użytkowników.
mod_auth_ldap
Autoryzacja użytkowników za pomoca˛ LDAP.
mod_auth_kerb
Autoryzacja użytkowników za pomoca˛ Kerberos. Obsługuje wersje 4 i 5.
mod_auth_notes
Autoryzacja użytkowników za pomoca˛ serwera Lotus Notes.
mod_auth_oracle
Autoryzacja użytkowników za pomoca˛ bazy danych Oracle. Istnieja˛ także jeszcze inne moduły, np. dla baz danych MySQL i
PostgreSQL.
mod_auth_smb
Autoryzacja użytkownika za pomoca˛ serwera SMB (Samba, Windows NT).
203
Tablica 3.30: Moduły Apache
Powyższy spis dost˛epnych modułów nie jest pełny i przedstawia tylko wycinek możliwoś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 funkcjonalności wyszukiwania za pomoca˛ strony WWW, serwer Apache można uzupełnić o odpowiedni program. Do wyboru istnieja˛ różne jednostki oprogramowania. Poniżej przykładowo opisaliśmy system wyszukiwania HTDig 36. HTDig umożliwia indeksowanie całych stron WWW. Program ten tworzy, za pomoca˛ tak zwanego Rebots, indeks
wyszukiwania, który można odpytywać korzystajac
˛ z przeznaczonych do tego skryptów CGI.
Nast˛epujace
˛ punkty oddaja˛ najważniejsze funkcjonalności programu:
◦ założenie indeksu przeszukiwanych maszyn (obejmujacego
˛
jedna˛ lub wi˛ecej stron WWW
badź
˛ obszary strony WWW).
◦ ograniczenie indeksowania dzi˛eki zastosowaniu filtrów. Kryteriami filtrowania moga˛ być
typy plików i określone adresy URL.
◦ dzi˛eki zastosowaniu zewn˛etrznego dodatkowego oprogramowania można indeksować także
formaty plików (PDF. DOC, itd.).
◦ istnieja˛ liczne możliwości odpytywania i można korzystać z wielu algorytmów wyszukiwania (słowa, cz˛eści słów, synonimy, itd.).
◦ za pomoca˛ prostych plików template można dostosowywać stron˛e wyszukiwania i odpowiednia˛ list˛e trafień.
◦ wewnatrz
˛ wyszukiwanych poj˛eć obsługiwane sa˛ znaki narodowe.
36
http://www.htdig.org/
204
◦ stosowany Rebot obsługuje standard „Rebot Exclusion“ oraz „Basic - WWW - Authentication“ do indeksowania chronionych treś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, ponieważ dla wi˛ekszości konfiguracji wymagana jest tylko zmiana albo dodanie wpisów w dobrze udokumentowanym pliku. Jest to plik tekstowy, który można edytować za pomoca˛ edytora tekstu. Dla administratorów preferujacych
˛
interfejs graficzny istnieje kilka komercyjnych i niekomercyjnych
37
projektów GUI Apache .
Migracja
W ramach migracji należy rozróżnić, jakich danych badź
˛ treści ma dotyczyć migracja. Można
tu wyszczególnić:
◦ pliki HTML
◦ programy CGI (Perl, PHP, C, itd.)
◦ moduły programów, które korzystaja˛ z ISAPI (Internet Server Application Programming
Interface) serwera Internet Information Server.
oraz
◦ Active Server Pages.
Strony HTML
Treści statyczne, także czyste strony HTML, można eksportować do nowego serwera WWW
bez ich dalszego dopasowywania i moga˛ one, w przypadku migracji do nowego serwera WWW,
ewentualnie powodować jedynie minimalne problemy i nakłady.
37
patrz także http://gui.apache.org/
205
Common Gateway Interface
Programy, które stworzone zostały dla Common Gateway Interface (CGI) wykorzystuja˛ również specyficzny standard CGI. Okreś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 skorzystać można z licznych możliwoś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 każdej wersji Windows. Perl oferuje także programistom WWW obszerne możliwości manipulacji tekstem
i danymi. Aplikacje, które napisane zostały w Perlu, można bardzo łatwo migrować do Apache. Apache zapewnia dzi˛eki modułowi „mod_perl“ pełna˛ implementacja˛ Perla. Ponadto cz˛esto
pozwala on uzyskać lepsza˛ wydajność podczas wykonywania w/w skryptów. Moduł Perla wpisuje interpreter Perla w serwer Apache, dzi˛eki czemu aby wykonać kod programu nie musi być
już wykonywany oddzielny proces i można uzyskać znaczny przyrost pr˛edkoś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óżnych systemów baz danych oraz wzgl˛ednie prosta˛ składnia.˛ PHP
można, podobnie jak Perla, stosować na wielu różnych systemach. Aplikacje PHP, które zostały
zaprojektowane dla Internet Information Server, można przy minimalnym nakładzie przeportować do serwera WWW Apache.
ISAPI
Aplikacje korzystajace
˛ z ISAPI można stosować 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˛ funkcjonalność zapewniajac
˛ a˛ całkowita˛
kompatybilność z ISAPI. Aplikacje wymagaja˛ jedynie ponownej kompilacji w nowym środowisku Apache. Na ogół nie jest wymagana zmiana kodu, jednak nie ma obsługi filtrów ISAPI oraz
rozszerzeń Microsoft dla asynchronicznych operacji na plikach.
ASP
Aplikacje oparte na technologii ASP zaprojektowane zostały z reguły w celu generowania
dynamicznych treści WWW. Można przy tym stosować różne podstawy:
◦ Visual Basic Script (VBScript)
◦ JScript
206
oraz
◦ Active X Data Objects (ADO) dla dost˛epu do baz danych.
Aby móc wykonywać strony ASP na serwerze WWW Apache, potrzebne jest kompletne ś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
środowisko do wykonywania stron ASP wewnatrz
˛ serwera WWW Apache. Serwer WWW może
pracować w systemie operacyjnym NT badź
˛ w systemie Unix / Linux.
◦ Produkt ten obsługuje:
◦ ASP 3.0
◦ VBScript 5.5
◦ JScript 5.5.
Aby przeprowadzić migracj˛e do serwera WWW Apache pracujacego
˛
na systemie linuksowym
należy w pierwszym kroku skopiować wszystkie pliki ASP do nowej platformy docelowej. W
kolejnym kroku wewnatrz
˛ aplikacji ASP należy określić wykorzystywane obiekty COM i zsynchronizować je z obiektami obsługiwanymi w Linuksie. Liczne obiekty obsługiwane sa˛ przez
Sun One ASP. Jeśli potrzebny obiekt nie jest obsługiwany, wówczas istnieje możliwość zastosowania dostarczanego COM - to - Java Bridge i zaimplementowania funkcjonalności za pomoca˛ Java. Dodatkowo należy jeszcze sprawdzić zmiany pod katem
˛
pisowni wielka˛ i mała˛ litera˛
oraz wersj˛e ASP Engine badź
˛ 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 znaleźć można w rozdziale 3.13, Bazy danych.
Oprócz możliwości zachowania aplikacji ASP w ich dotychczasowej formie, istnieje oczywiście także możliwość zastosowania alternatywnych technologii. Rozwiazanie
˛
takie nasuwa
si˛e, gdy wyraźnie chcemy uzyskać wi˛eksza˛ niezależność od platformy. Należy jednak liczyć si˛e
wówczas z wi˛ekszymi nakładami migracyjnymi, gdyż realizacja aplikacji w nowej technologii z
reguły powoduje zwi˛ekszone nakłady. Jednakże taki proces migracji można także wykorzystać
do konsolidacji i optymalizacji treści i aplikacji.
Prawdziwa˛ alternatywna˛ metoda˛ dla realizacji celów spełnianych przez aplikacje może być
zastosowanie technologii PHP. Ulubiona platforma (LAMP), która szczególnie w ostatnich latach służy do generowania treści stron WWW, składa si˛e z kombinacji:
38
patrz także http://sun.de/Produkte/software/chilisoft/
207
◦ GNU/Linux
◦ Apache
◦ MySQL
◦ PHP.
Jeśli chodzi o przekształcanie aplikacji ASP do PHP, pomóc może ewentualnie ocena treś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 powyższej możliwości można także rozważyć zastosowanie technologii opartej na
Java. Aplikacje WWW oparte na Java sa˛ interesujac
˛ a˛ alternatywa˛ dla aplikacji WWW opartych
na ASP. Obecnie najcz˛eś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 niezależności od platformy. Aplikacje WWW J2SE pozwalaja˛ na tworzenie dynamicznych treści za pomoca˛ Java Server Pages
(JSP) i Java Servlets. Obydwie technologie umożliwiaja˛ m.in. rozwój osobistych treści i dost˛ep
do zewn˛etrznych źródeł danych. W celu wykonywania stron JSP i Servletów można skorzystać
z produktu Open source „Tomcat“40 . Projekt Tomcat stworzony został w kontekście Apache Software Foundation (ASF). Tomcat oferuje skalowalne środowisko wykonywania stron JSP oraz
Java - Servlets i tym samym jest bardzo dobra˛ alternatywa˛ dla rozwiazań
˛
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 funkcjonalności można si˛egnać
˛ po standardy Java 2 Enterprise Edition. Za pomoca˛ tak zwanych
Enterprise Java Beans (EJB) można realizować aplikacje dla skomplikowanych procesów i reguł
biznesowych, które jednocześnie wymagaja˛ dost˛epu do systemów zewn˛etrznych. Środowisko
J2EE wymaga serwera aplikacji, który przejmie wykonywanie EJB. Serwer aplikacji musi być
w stanie zagwarantować zarzadzanie
˛
sesja˛ użytkowników, oferować odpowiednie interfejsy do
zewn˛etrznych aplikacji i zapewnić konieczna,
˛ wysoka˛ niezawodność (Cluster, Load - Balancing,
Failover). Oprócz znanych komercyjnych produktów, takich jak, np. IBM Websphere, BEA Weblogic, Oracle Application Server i kilku innych, istnieje także możliwość 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
208
specyfikacj˛e J2EE, oferuje zintegrowany serwer WWW, JSP Engine i Servlet Engine, obsług˛e
Enterprise Java Beans, ponadto Clustering i liczne dalsze funkcjonalności.
Szczegółowy opis procedur migracji aplikacji ASP do technologii opartych na Java oferuj˛e na
przykład także przedsi˛ebiorstwa SUN42 i Oracle43, dlatego w tym miejscu z niego zrezygnujemy.
3.11.5.1
Internet Information Server 5.0
Nowości
Internet Information Server jest integralna˛ cz˛eścia˛ składowa˛ serwera Windows 2000. Kolejna
wersja Internet Information Server 4.0 posiada cały szereg nowych funkcjonalności. Najważniejsze nowości zostały przedstawione w poniż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 bezpośrednio poprzez HTTP po stronie serwera.
Obsługa katalogów WWW. Służa˛ użytkownikom jako tradycyjne
katalogi plików na serwerze WWW i bezpośrednio zwiazane
˛
sa˛ z
funkcjonalnościa˛ WebDAV.
obsługa Frontpage
Umożliwia tworzenie i zarzadzanie
˛
treściami WWW za pomoca˛
Microsoft Frontpage. Za pomoca˛ graficznej Frontend administrator może tworzyć i zmieniać treści WWW na serwerze.
obsługa multiplen web
Umożliwia hosting różnych stron WWW na jednym serwerze i
- sites
jednym adresie IP.
Umoż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 szerokości pasma.
42
43
http://developer.iplanet.com/docs/migration/webserver/IIS_50.pdf
http://otn.oracle.com/tech/migration/asp/content.html
209
„Platform for Internet Content Selection"44 - Rating jest technicznym standardem służacym
˛
do wdrażania systemu oceny treści stron WWW wprowadzonym przez konsorcjum W3. PICS ła˛
PICS Rating
czy ocen˛e treści z możliwościa˛ filtrowania stron WWW według
określonych cech. W tym celu należy wprowadzić 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 rozwijać
windowsowych
dla aplikacji WWW moduły COM dajace
˛ si˛e ponownie wykorzystać.
określanie właściwości
Za pomoca˛ ASP można ustalić dokładne właściwości przegla˛
przegladarki
˛
WWW
darki WWW systemów klienckich.
rozdzielanie procesów
Administrator może izolować pojedyncze procesy aplikacji od
procesów głównych i innych procesów aplikacji.
Umożliwia dost˛ep do obiektów, właściwości i metod Active Di-
ADSI 2.0
rectory Service Interface. Integracja serwera WWW i Active Directory umożliwia przypisanie różnych stron WWW na serwerze
WWW do określonych domen użytkowników.
Administrowanie
delegacja zarzadzania
˛
Umożliwia przekazanie zadań administracyjnych.
Umożliwia ograniczenie czasu CPU dla aplikacji albo strony
throttling
DFS
WWW. Dzi˛eki temu można zapewnić dost˛epność czasu procesora
dla innych stron WWW albo aplikacji niesieciowych.
Distributed File System to system plików umożliwiajacy
˛ przeźroczyste rozdzielanie plików pomi˛edzy wiele komputerów. Może
być używany dla dokumentów root w miejscu, w którym w systemie plików składowane sa˛ treści WWW.
44
http://www.w3.org/PICS/
210
Autoryzacja i bezpieczeństwo
Autoryzacja użytkowników może odbywać 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.
Umożliwia transmisj˛e zaszyfrowanych haseł wymaganych dla autoryzacji.
ograniczenia domen i
Administrator otrzymuje możliwość udost˛epniania badź
˛ bloko-
IP
wania komputerom i domenom dost˛epu do zawartości.
certyfikaty
Obsługa certyfikatów klienta i serwera.
Tablica 3.32: Rozszerzone funkcjonalności Internet Information Server 5.0
3.11.5.2
Internet Information Server 6.0
Do zakresu dostawy Windows Server 2003 należ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
˛ uruchomić proces instalacji
serwera oraz aktywować poszczególne jego funkcjonalnoś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 być w przyszłości oferowane możliwości serwera aplikacji.
Na potrzeby tej nowej roli w Internet Information Server zaimplementowanych zostało kilka
nowości, których krótki opis znajduje si˛e poniżej.
211
Dla uzyskania poprawy w obszarze niezawodności i skalowalności wprowadzono zmiany
wewnatrz
˛ architektury przetwarzania. Dzi˛eki temu bł˛edy moga˛ być rozpoznawane automatycznie
a w razie potrzeby istnieje możliwość ponownego uruchamiania procesów. Równolegle serwer
WWW kolejkować nadchodzace
˛ żadania.
˛
IIS 6.0 jest w stanie prowadzić kontrol˛e stanu procesów roboczych, aplikacji i stron WWW. Wraz z serwerem Windows 2003 wprowadzony został
także nowy sterownik trybu pracy jadra,
˛
którego zadaniem jest optymalizowanie przepływu danych na serwerze WWW.
IIS 6.0 można zintegrować z framework autoryzacyjnym serwera Windows 2003. Dodatkowo, można korzystać z menedżera autoryzacji do prowadzenia akcji delegowania i autoryzacji. Zarzadzanie
˛
IIS 6.0 odbywa si˛e teraz w oparciu o meta XML i umożliwia administratorowi
bezpośrednia˛ edycj˛e konfiguracji.
Nowa jest tu także integracja ASP.NET i IIS, programistom oferowane sa˛ rozszerzone funkcjonalności .NET Framework do tworzenia aplikacji. Dla programistów i użytkowników można
zastosować 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 wymagań należy stwierdzić, że SharePoint Portal
Server może być 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 funkcjonalnościach:
◦ wyszukiwanie
◦ zarzadzanie
˛
dokumentami
◦ praca grupowa.
212
Microsoft stworzył tym samym produkt, który może spełniać klasyczne zadania portalu intranetowego w obr˛ebie przedsi˛ebiorstwa. Aby stworzyć a nast˛epnie zarzadzać
˛
treś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 funkcjonalnościami wyszukiwania oraz Workflow.
Jeśli chodzi o wymagania systemowe, niezb˛edny jest tu serwer Microsoft Windows 2000
badź
˛ Advanced Server, jak również Internet Information Service 5.0 i Simple Mail Transfer
Protocol. SharePoint Portal Server nie wymaga Active Directory. Serwer można zainstalować 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).
Można tu ustalać mi˛edzy innymi zakresy robocze, zadania bezpieczeństwa, czasy timeout i ustawienia protokołu. W celu zapewnienia bezpiecznej wymiany danych poprzez Internet / Extranet
można właczyć
˛
szyfrowanie SSL.
Ocena i prezentacja SharePoint Portal Server w tym kontekś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 określany mianem Dashboardsite. Użytkownikom portalu WWW można udost˛epnić nast˛epujace
˛ funkcje:
◦ wyszukiwanie
◦ abonament nowych albo zmodyfikowanych treści
◦ sprawdzanie wpływajacych
˛
i wychodzacych
˛
dokumentów, wraz z numerami wersji
◦ publikowanie dokumentów
Do organizacji i wyś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˛ przedstawiać informacje z zewn˛etrznych i z wewn˛etrznych źródeł. Do zewn˛etrznych źródeł treści można zaliczyć inne obszary robocze SharePoint Portal Server, strony intranetowe albo internetowe, hierarchie publicznych katalogów Microsoft Exchange 2000 i Exchange
Server 5.5, bazy danych Lotus Notes, lokalne systemy plików oraz sieciowe serwery plików.
213
Web Parts można rozwijać samemu albo nabywać u innych producentów. Istnieja˛ jednak także
standardowe Web Parts, na przykład służace
˛ integracji wyjścia i wyjścia poczty Outlooka, kalendarza i terminów. Dzi˛eki właczeniu
˛
Web Parts innych producentów można poprzez portal
stworzyć dost˛ep do kolejnych systemów informacyjnych (SAP, system CAD, system archiwizacji, itd.).
Wewnatrz
˛ portalu istnieje możliwość przyporzadkowania
˛
informacji i dokumentów do poszczególnych kategorii. Kategorie z kolei moga˛ mieć hierarchiczna˛ budow˛e.
Wewnatrz
˛ Digital Dashboard pojedynczy użytkownik może sterować sposobem uporzadko˛
wania i prezentacji Web Parts. Dost˛ep do Dashboardsite może być realizowany z poziomu przegladarki
˛
internetowej, np. Microsoft Internet Explorer albo Netscape Navigator. Aby Dashboardsite mogła działać w przegladarce
˛
WWW musi być właczony
˛
Microsoft JScript albo Netscape
Java Script.
45
Rysunek 3.26: Architektura SharePoint Portal Server
3.12.4 System Zarzadzanie
˛
Dokumentami (DMS)
Kolejnym ważnym elementem SharePoint Portal Server sa˛ zintegrowane funkcjonalności DMS.
Oferowane sa˛ nast˛epujace
˛ standardowe funkcje:
45
Źródło: Einführung in Microsoft SharePoint Portal Server 2001 – Whitepaper März 2001
214
◦ zarzadzanie
˛
dokumentami
◦ zarzadzanie
˛
wersja˛
◦ zezwolenie Workflow
◦ sprawdzanie na wejściu i wyjściu
◦ profile dokumentów i publikowanie dokumentów
◦ abonamenty.
Edycja dokumentów i zarzadzanie
˛
nimi (sprawdzanie na wejściu i wyjściu) sa˛ całkowicie zintegrowane z Microsoft - Office - Suite. SharePoint Portal Server oferuje także możliwość 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ównież tak zwane przekazywanie zezwoleń
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 może obejmować różne źródła wiedzy (wewn˛etrzne i zewn˛etrzne treści), które moga˛ być udost˛epniane użytkownikom w trybie wyszukiwania pełnego
tekstu. Użytkownikom oferowana jest także możliwość wyszukiwania atrybutowego (profile dokumentów). Użytkownikom pokazywane sa˛ tylko dokumenty z listy trafień, do których zalogowany użytkownik posiada prawa dost˛epu.
Naznaczanie dokumentów nast˛epuje poprzez tak zwana IFilter (Index Filter). Jeśli dokument
zostanie nadesłany albo dodane zostana˛ zewn˛etrzne źródła treści, wówczas serwer automatycznie
rozpozna typ dokumentu i uruchomi odpowiedni IFiltr. Filtry zapewniaja˛ rozpakowanie treści
dokumentu, które moga˛ być 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 badź
˛ portalu pracowników niezb˛edny jest dokładny, szczegółowy plan. Tylko portale,
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 można sprostać korzystajac
˛ z odpowiednich rozwiazań
˛
portalowych (wraz z Content Management albo z systemami zarzadzania
˛
dokumentami). Jednak nie należy zakładać, że powyższe rozwiazania
˛
- dotyczy to także SharePoint Portal Server
- stanowia˛ tak zwane rozwiazanie
˛
Out of th Box. Wszystkie systemy należy w mniejszym lub
wi˛ekszym stopniu dostosować do wcześniej zdefiniowanych wymagań. W zależności od oczekiwanych celów może być konieczne wykonanie obszernych prac programistycznych. Aby wprowadzić SharePoint Portal Server potrzeba, tak samo jak w przypadku wprowadzania skomplikowanych rozwiazań
˛
archiwistycznych i Workflow, dużej kompetencji jeśli chodzi o analiz˛e i
kształtowanie procesów biznesowych.
W oparciu o wyniki obszernej analizy wymagań można stwierdzić, że SharePoint Portal Server może być jak najbardziej brany pod uwag˛e jako możliwe rozwiazanie.
˛
3.13 Bazy danych
3.13.1 Przeglad
˛
Ocena techniczna migracji baz danych pokazuje, że oprócz kontynuacyjnego produktu Microsoft, którym jest MS SQL Server 2000 korzystać można z alternatywnych, jak najbardziej adekwatnych odpowiedników b˛edacych
˛
rozwiazaniami
˛
OSS, co usprawiedliwia przeprowadzenie
migracji zast˛epujacej.
˛
Ważnymi przedstawicielami rozwiazań
˛
OSS sa˛ MySQL, PostgreSQL, Firebird oraz SAP DB. Oprócz tego dost˛epne sa˛ także produkty komercyjne, takie jak Oracle i
DB2, które również były już wielokrotnie wykorzystywane w urz˛edach i w zwiazku
˛
z tym nie
zostały przedstawiane w poniższej ocenie technicznej.
Wymienione rozwiazania
˛
OSS oferuja˛ różne funkcjonalności, dlatego ich przydatność należy
sprawdzać pod katem
˛
wymagań w poszczególnym przypadku.
Należy podkreślić, że wszystkie w/w rozwiazania
˛
OSS sa˛ niezależne od platformy i że istnieja˛ także ich wersje windowsowe, które można pobrać z Internetu. Dlatego niniejsze systemy
bazodanowe moga˛ być zastosowane także w przypadku migracji punktowej.
3.13.2 Wprowadzenie
Do utrzymywania, zarzadzania
˛
i zapisywania dużych ilości danych wykorzystuje si˛e systemy
bazodanowe. Systemy bazodanowe zapisuja˛ powiazane
˛
ze soba˛ elementy w formularzu danych,
216
wzgl˛ednie w pogrupowanych wierszach. Pomi˛edzy tymi strukturami a grupami moga˛ istnieć
zdefiniowane relacje. dzi˛eki zastosowaniu dobrze zaplanowanej i ustrukturyzowanej bazy danych
można uniknać
˛ nadmiaru danych.
Dane z systemu bazodanowego nie sa˛ z reguły bezpośrednio udost˛epniane użytkownikom.
Dost˛ep do nich odbywa si˛e za pośrednictwem aplikacji, która odwołuje si˛e do danych i oferuje je
użytkownikom w odpowiedniej formie. Aby było to możliwe musza˛ istnieć interfejsy pomi˛edzy
systemem bazodanowym a aplikacja.˛ Właściwy składnik komunikacyjny zapewnia połaczenie
˛
pomi˛edzy systemami klienckimi i serwerowymi. Aplikacje, które wykonywane sa˛ na systemach
klienckich, moga˛ odwoływać si˛e do serwera bazy danych poprzez sieć. Serwery bazy danych
musza˛ być w stanie obsługiwać wi˛eksza˛ ilość równoległych zapytań 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łaś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 zdarzeń
DBMS definiuje także instrukcje i aplikacje, których trzeba użyć, aby móc pracować z danymi w
bazie danych. Najcz˛eś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łaś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.
217
Polecenia SQL przesyłane sa˛ na poziomie aplikacji z każdego systemu klienckiego za pomoca˛ protokołu . Poziom ten jest specyficzny dla MS SQL Server i określany jako Tabular Data
Stream (TDS). Obsługiwane sa˛ wersje 4.2 i 7.0. Każdy pakiet tworzony jest dla MS SQL Server
przez OLE DB - Provider i sterownik ODBC. Pakiety TDS przesyłane sa˛ do serwera badź
˛ 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
218
Właś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 poleceń 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 wejścia / wyjś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 nośniku danych. Podczas pracy z baza˛
danych użytkownik b˛edzie używał w pierwszym rz˛edzie logicznych składników (tablic, Views,
Stored Procedures, itd.).
Każda instalacja MS SQL Server udost˛epnia wiele baz danych. Łacznie
˛
istnieja˛ cztery systemowe bazy danych i jedna albo wi˛ecej baza danych użytkowników. Oprócz w/w systemowych
baz danych, po instalacji należy założyć właściwe bazy danych zawartości. Te produkcyjne bazy
danych zorganizowane sa˛ w formie różnych obiektów. W poniższej tabeli wymienione zostały
najważniejsze składniki dost˛epne w MS SQL Server jako obiekty.
S KŁADNIKI
W YJA ŚNIENIE
Właściwe dane bazy danych zapisywane sa˛ w tablicach. Tablice
tablice
typy danych zdefiniowane przez użytkownika
składaja˛ si˛e z kolumn i wierszy. Wiersze zawieraja˛ każdorazowe
zestawy danych. Dla kolumn można ustalać typy danych. Definiuja˛ one rodzaj danych zapisywanych w kolumnach.
Oprócz typów podstawowych danych serwera MS SQL użytkownicy moga˛ zakładać typy danych definiowane przez użytkownika.
219
Widoki sa˛ warstwami zdefiniowanymi dla wirtualnej tablicy albo
zapisanego zapytania. W bazie danych zapisane sa˛ polecenia SELECT, których wynik tworzy treść wirtualnej tablicy. Widoki pełnia˛ nast˛epujace
˛ funkcje:
Views
◦ ograniczaja˛ użytkownikom prawa dost˛epu do określonych
wierszy albo kolumn w tablicy.
◦ w powiazany
˛
sposób prezentuja˛ kolumny z wielu tablic.
◦ łacz
˛ a˛ informacje.
Sa˛ grupa˛ poleceń Transact - SQL, która skompilowana została
pod katem
˛
jednego planu wykonania. Stored Procedures pełnia˛
m.in. nast˛epujace
˛ funkcje:
◦ implementuja˛ wychodzac
˛ a˛ poza ramy program logik˛e programu w celu wykonywania cz˛esto powtarzajacych
˛
si˛e zadań.
Stored Procedures
◦ zwi˛ekszaja˛ wydajność, skompilowane Stored Procedures
przechowywane sa˛ w Cache.
◦ moga˛ zapobiegać dost˛epowi do tablic po stronie użytkownika.
ograniczenia
Udost˛epniaja˛ proces zapewnienia integracji bazy danych. Ograniczenia definiuja˛ reguły pod katem
˛
dopuszczalnych wartości wewnatrz
˛ kolumny.
Zapewniaja˛ kompatybilność zwrotna,˛ cz˛eściowo pełnia˛ te same
reguły
funkcje, jak ograniczenia CHECK. Służa˛ do ograniczania wartości w kolumnie.
Podaja˛ wartości, które używane sa˛ w kolumnie, gdy podczas
wartości domyślne
wstawiania wiersza danych, w kolumnie nie została podana wartość.
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
Użytkownik nie ma bezpośredniego dost˛epu do Microsoft SQL Server. Aby uzyskać dost˛ep do
danych, należy zastosować specjalne aplikacje. Moga˛ to być:
◦ programy usługowe serwera MS SQL
◦ programy innych producentów
oraz
◦ własne programy stworzone na wewn˛etrzny użytek urz˛edu.
Dost˛ep do MS SQL Server odbywa si˛e za pośrednictwem API (Application Programming Interface) baz danych składajacego
˛
si˛e z dwóch cz˛eści: poleceń j˛ezyka programowania, które musza˛
być 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. Poleceń j˛ezyka programowania uż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 używaja˛ OLE DB (np. ActiveX Data
Objects (ADO)). Ponadto obsługiwane sa˛ obiekty i składniki, które uż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.
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˛ należy zastosować technologie ponadprocesowe, np. Named Pipes albo Shared Memory. Aplikacje, które
pracuja˛ na innym systemie klienckim, używaja˛ sieciowej Interprocess Communication (IPC).
IPC oparta jest na API i protokołach sieciowych. Korzystać można z nast˛epujacych
˛
protokołów:
◦ TCP / IP
◦ Novell IPX / SPX
◦ AppleTalk
◦ Banyan VINES.
3.13.3.5
Skalowalność
Microsoft SQL Server jest przystosowany do zarzadzania
˛
bazami danych, które moga˛ mieć rozmiar jednego terabajta albo wi˛ekszy. MS SQL Server posiada kilka Features, które zwi˛ekszaja˛
wydajność systemu bazodanowego.
System bazodanowy obsługuje także środowiska VLDB (Very Large Database). Rozmiar baz
danych może wynosić jeden terabajt albo wi˛ecej. Za pomoca˛ poleceń Transact - SQL, takich jak
BACKUP i RESTORE można zabezpieczać dane na wielu mediach oraz tworzyć przyrostowe
kopie bezpieczeństwa.
W celu przyspieszenia obsługi zapytań z serwerem MS SQL zintegrowany został optymalizator zapytań. Aby zapewnić podział poleceń SQL dla maszyn wieloprocesorowych, można
tworzyć równoległe plany wykonywania.
Serwer MS SQL obsługuje dzielone zapytania. Istnieje możliwość wykonywania poleceń
Transact - SQL, które odnosza˛ si˛e do heterogenicznych źródeł danych OLE DB.
Podczas wykonywania aktualizacji (zmian), integralność danych zapewniona jest dzi˛eki temu,
że aktualizacje zawsze kończa˛ si˛e stałym stanem. Jeśli nie zostanie on osiagni˛
˛ ety, wówczas nast˛epuje Rollback i przejście do punktu wyjścia, tzn. do poprzedniego stałego stanu.
Ponadto możliwe sa˛ dzielone transakcje. Zarzadzanie
˛
transakcjami odbywa si˛e przy tym za
pomoca˛ menedżera transakcji.
3.13.3.6
222
Nadawanie praw dost˛epu
Serwer MS SQL oferuje dwa rodzaje autoryzacji użytkowników:
◦ autoryzacja serwera SQL
W serwerze MS SQL musza˛ istnieć odpowiednie konta logowania oraz hasła – nie sa˛
one zwiazane
˛
z kontami użytkowników NT. Logowanie i odpytywanie hasła odbywa si˛e
bezpośrednio na serwerze SQL.
◦ autoryzacja Windows NT
Konta oraz grupy Windows NT należy właczyć
˛
do serwera MS SQL, jednak właściwa
autoryzacja odbywa si˛e w domenie NT.
Administrator może ustalić, czy autoryzacja ma si˛e odbywać poprzez Windows NT, czy w trybie
mieszanym.
3.13.3.7
Integracja systemu
Serwer MS SQL obsługuje stosowanie użytkowników Windows NT oraz kont domen. Tym samym dla serwera MS SQL dost˛epna jest autoryzacja Windows NT. Użytkownicy nie sa˛ autoryzowani przez serwer MS SQL. Udost˛epnia on systemom klienckim zaufane połaczenie.
˛
Oprócz integracji autoryzacji użytkowników NT, serwer MS SQL może być ściśle zwiazany
˛
z nast˛epujacymi
˛
usługami:
◦ zapisywanie danych dla Microsoft Internet Information Server, który jest z reguły wykorzystywany do generowania dynamicznych treś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
umożliwia tworzenie i planowanie zadań, które maja˛ być wykonywane jednorazowo albo
okresowo. Moga˛ to być ostrzeżenia dla administratora w przypadku wystapienia
˛
określonych zdarzeń w systemie.
223
◦ MS SQL Server Profiler
umożliwia kontrol˛e oraz analiz˛e obciażenia
˛
sieci podczas transmisji z serwera i do serwera.
◦ Monitor systemowy serwera MS SQL
umożliwia właczenie
˛
si˛e w system monitorowania Windows NT służ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 umożliwienia
zarzadzania
˛
serwerem MS SQL.
◦ Asystent optymalizacji indeksu
umożliwia analiz˛e z wykorzystaniem indeksów poleceń SQL.
Za pomoca˛ SQL Distributed Management Objects (SQL - DMO) istnieje dodatkowo możliwość
właczenia,
˛
w ramach aplikacji, zadań automatyzujacych.
˛
Zadania powtarzajace
˛ si˛e można także
zaimplementować jako zlecenia.
˛
Bazy danych, a dokładniej relacyjne systemy zarzadzania
˛
bazami danych (RDBMS) należa˛ do
prekursorów zastosowań Linuksa w obszarach krytycznych dla przedsi˛ebiorstwa. Już 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 podażyły
˛
jej śladem Oracle
oraz Informix, które w ten sposób wyraźnie zwi˛ekszyły zaufanie do Linuksa w dziedzinie zastosowań 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ł, także na licencjach
Wolnego Oprogramowania, cały szereg pełnowartościowych RDBMS obsługujacych
˛
transakcje,
triggers oraz Stored Procedures. Jeśli chodzi linuksowe oprogramowanie Open Source w obszarze baz danych z pewnościa˛ nie brakuje wysokowartościowych opcji.
RDBMS pełnia˛ w ramach strategii migracyjnej o tyle szczególna˛ rol˛e, że zawsze zwiazane
˛
sa˛ z aplikacja,˛ której dane zarzadzane
˛
sa˛ za pomoca˛ RDBMS. Tym samym w przypadku zmiany
trzeba z jednej strony zmienić zasoby danych a z drugiej prawdopodobnie także aplikacje.
W idealnej sytuacji dane organizacji udost˛epniane sa˛ w znormalizowanej formie (bez nadmiaru) tylko z jednego systemu bazodanowego, a j˛ezyk zapytań (SQL), którym aplikacje poro-
224
zumiewaja˛ si˛e z baza˛ danych, spełnia standardy. W idealnej sytuacji każda aplikacja bez problemów współpracuje z każdym RDBMS. Niestety w rzeczywistości okazuje si˛e, że w wi˛ekszości
infrastruktur informatycznych trzeba zarzadzać
˛
wieloma RDBMS z cz˛eściowo nadmierna˛ ilościa˛
danych zgromadzonych w różnych bazach danych. Prowadzi to do tego, że zapytania o w/w dane
kierowane i redagowane sa˛ z różnych aplikacji i w różnych dialektach SQL przy wykorzystaniu
rozszerzeń 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˛ używane triggers ani Stored Procedures, należy podczas migracji bazy danych wymienić po stronie klientów
sterownik ODBC / JDBC.
W odniesieniu do powyższego migracja oferuje szans˛e na konsolidacj˛e struktur oprogramowania i struktur danych, przy czym oczywiście skorzystanie z niej nie jest proste.
Niniejsze wst˛epne przemyślenia pokazuja,˛ że rozwiazania
˛
alternatywne dla migracji kontynuacyjnej istnieja˛ tylko w przypadkach, gdy:
◦ RDBMS pracujacy
˛ obecnie pod kontrola˛ systemu Windows dost˛epny jest takż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 korzyści. Jeś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 może przejać
˛ inny system bazodanowy a połaczenia
˛
z klientami
można przekierować wymieniajac
˛ sterownik ODBC (na poziomie systemu, na kliencie).
Problem stanowia˛ tu szczegóły. Jeśli aplikacja współpracuje z Stored Procedures albo triggers, wówczas trzeba je również przeportować. (Można to zrobić przy okazji, bez zmian
w oprogramowaniu klienckim.)
◦ chodzi o aplikacj˛e MS Access przechowujac
˛ a˛ dane w postaci plików. W takim przypadku
można w bardzo łatwy sposób właczyć
˛
dane do centralnego DBMS i przestawić aplikacj˛e
Access na interfejs ODBC.
◦ klient dost˛epny jest w postaci tekstu źródłowego i można go dostosować w ramach projektu
migracyjnego do nowego RDBMS. Oprócz wymienionych już czynników (korzystanie z
triggers i Stored Procedures), nakład zwiazany
˛
z migracja˛ zależy tu także od wykorzystywanych interfejsów programistycznych. Jeśli połaczenie
˛
z baza˛ danych zaimplementowane zostało bezpośrednio poprzez interfejs producenta (np. wbudowany SQL), wówczas
225
należy si˛e liczyć ze znacznie wi˛ekszym nakładem, niż w przypadku, gdy pomi˛edzy wła˛
czona została płaszczyzna abstrakcji, taka jak ActiveX Data Objects (ADO).
◦ Ostatecznie istnieje jeszcze możliwość współpracy z producentem aplikacji i przeprowadzenia migracji bazy danych w ten sposób. Trwałe zwiazanie
˛
z określonym RDBMS uznawane jest, także przez wielu producentów komercyjnych baz danych, za niekorzystne z
punktu widzenia rynku, dlatego można wyjść z założenia, że gotowość do migracji, szczególnie do RDBMS wywodzacego
˛
si˛e z Open Source, rośnie i jest godna zauważenia.
Gdy istnieje możliwość przeprowadzenia migracji systemu bazodanowego, należy wybrać docelowy system RDBMS. Przy ocenie możliwych systemów docelowych w ramach niniejszego
poradnika migracyjnego wzi˛eliśmy pod uwag˛e przede wszystkim bazy danych Open Source.
Poniż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
226
Tablica 3.36: Systemy bazodanowe dost˛epne na licencji Open Source
Systemy Hash nie sa˛ relacyjne. Jeśli chodzi o migracj˛e, to w gr˛e wchodza˛ przede wszystkim
cztery ostatnie systemy z interfejsem SQL. Poniżej zamieściliś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.
Ponieważ również interfejsy programistyczne udost˛epniane sa˛ na licencji GPL, zlinkowane z
nimi programy także musza˛ być oparte na tej licencji, o ile sa˛ one rozpowszechniane badź
˛ rozprowadzane na zasadach komercyjnych. Alternatywnie MySQL AB oferuje również licencje
komercyjne, które umoż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, szkoleń oraz doradztwa.
Producenci oceniaja˛ ilość zainstalowanych baz danych MySQL na całym ś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 może służyć do składowania danych z takim samym Frontend (parser SQL) na różnych BackEnds. W przypadku wykorzystania innoDB jako BackEnd, MySQL obsługuje także
transakcje. Obecnie MySQL nie oferuje Stored Procedures. Zgodnie z deklaracjami producenta
b˛eda˛ one dost˛epne poczawszy
˛
od wersji 5.0.
Ponadto istnieje możliwość 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 rzeczywiście wymagane jest do
zapisania treści. Przydzielanie miejsca na dysku dla tablic czy bazy danych nie jest konieczne.
Pojedynczy pracujacy
˛ serwer bazy danych może zarzadzać
˛
dowolna˛ ilościa˛ instancji bazy danych.
MySQL jest w sumie bardzo zgrabna i w przypadku każdego dost˛epu do odczytu niesłychanie szybka. Zazwyczaj wykorzystywana jest raczej w przypadku małych i średnich zasobów
danych oraz dla lekkich aplikacji. Jednakże lista referencji MySQL AB pokazuje, że ta baza
227
danych przeznaczona jest również dla dużych aplikacji i dużych zasobów danych i że jak najbardziej może mierzyć 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 duża˛ i rozproszona˛ po
całym świecie społeczność. W zgodzie z modelem pracy społeczności różne firmy oferuja˛ dla
PostgreSQL swoje produkty i usługi.
W przypadku PostgreSQL użytkownik może definiować własne funkcje w wielu różnych
j˛ezykach programowania, które moga˛ zwracać zarówno pojedyncze wartości, jak też tupels albo
nawet całe tablice. Funkcje te oferuj˛e różnorodne możliwości w postaci procedur zdefiniowanych
dla użytkownika. Kolejnym szczególnym rozwiazaniem
˛
jest wykorzystanie reguł si˛egajacych
˛
poza triggers. Dzi˛eki szerokiemu procesowi rozwijania projektu przez społeczność, PostgreSQL
jest bardzo funkcjonalna i dopracowana pod katem
˛
bezpieczeństwa. Wskutek tego PostgreSQL
standardowo oferuje mocne szyfrowanie oraz autoryzacj˛e, jak też przepływ danych w oparciu o
certyfikaty X.509.
Dane z PostgreSQL przechowywane sa˛ w systemie plików. Alokacja położenia bazy danych
albo tablic nie jest wymagana, istnieje także późniejsza możliwość podziału na różne obszary zapisu. Serwer bazy danych może obsługiwać wiele instancji bazy danych. PostgreSQL wykorzystuje, podobnie jak Oracle, system podgladu,
˛ który w przeciwieństwie do tradycyjnego Locking
umożliwia Locking bazy danych także w trakcie pracy przy dużym Performance. Zabezpieczanie
danych jest przy tym spójne.
PostgreSQL jest jednocześnie zgrabna i bardzo funkcjonalna. Zazwyczaj wykorzystywana
jest dla zasobów danych średniej wielkości. Do wysoce zautomatyzowanego transportu danych
z MS Access do PostgreSQL można posłużyć 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 zaangażowana społeczność. 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
228
istnieja˛ tylko w bazie danych Interbase. Obecnie Firebird nie może być jeszcze brany pod uwag˛e
jako RDBMS, jeś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˛ aż 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
rozwiazań
˛
tej firmy i jest stosowana jako podstawowa technologia we własnych produktach. W
zakresie funkcji mieszcza˛ si˛e oprócz obsługi transakcji także wsparcie dla triggers oraz Stored
Procedures.
Główne starania zwiazane
˛
z rozwojem, jak też z zapewnieniem jakości podejmowane sa˛ pod
katem
˛
funkcjonalności zastosowań rozwiazań
˛
SAP. Ponieważ cała logika biznesowa ma miejsce
na serwerze aplikacji SAP, system bazodanowy jest w istotnym stopniu wykorzystywany do
performantnego dostarczania i zabezpieczania relacyjnych danych. Stored Procedures nie maja˛
tu znaczenia. Z tego punktu widzenia SAP DB brakuje jeszcze wszechstronności i elastyczności.
Do przechowywania danych SAP DB używa Volumens, które sa˛ tworzone w systemie plików
albo na Raw - Devices i które każdorazowo w całości alokowane sa˛ do instancji bazy danych.
Baza danych jest reorganization - free i może być zabezpieczana w trakcie pracy bez zakłóceń
Performance.
SAP DB należy wśród baz danych Open Source do wagi ci˛eżkiej. Może być ona celem
migracyjnym dla baz danych MS Access tylko w wyjatkowych
˛
przypadkach.
3.13.4.5
Bilans pośredni
Jeśli chodzi o Open Source, oferta alternatywnych celów migracyjnych jest różnorodna i atrakcyjna.
Nie można podjać
˛ ogólnej, prostej i jednoznacznej decyzji na korzyść takiego lub innego
systemu w oparciu o jego charakterystyczne cechy.
Wszystkie opisane dotychczas systemy bazodanowe SQL sa˛ niezależne od platformy. Ważne
jest, że wszystkie cztery dost˛epne sa˛ w Internecie także w wersjach windowsowych.
229
Przy szczegółowym porównaniu systemów docelowych, które można wziać
˛ pod uwag˛e w
przypadku migracji, konieczne jest zapoznanie si˛e z dokładnym porównaniem spisów Features
przygotowanych pod katem
˛
funkcjonalnoś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 możliwość nadania odpowiedniemu typowi wi˛ekszego zakresu wartości. Należy jednak
230
zwrócić uwag˛e, zarówno podczas importu danych, jak i podczas przejścia na połaczenie
˛
ODBC,
aby interfejs ODBC posiadał własne rozwiazania
˛
i definicje typów danych.
3.13.4.7
Zalecenia odnośnie niezależności
Na wypadek, gdyby w danej chwili nie było możliwości przeprowadzenia migracji zast˛epuja˛
cej, zamieściliśmy poniżej kilka zaleceń co do sposobu programowania bazy danych, których
przestrzeganie ułatwi przyszła˛ migracj˛e.
◦ Należy zrezygnować z Stored Procedures i rozszerzeń specyficznych dla producenta.
W przypadku, gdy istnieje potrzeba przemieszczenia logiki biznesowej lub funkcjonalności z klienta na serwer, efekt ten można obecnie bardzo dobrze uzyskać wykorzystujac
˛ 3warstwowe architektury. Odpowiednia˛ implementacja˛ niezależna˛ od platformy jest tu Java,
zarówno dla klienta, jak i dla serwera aplikacji (Tomcat).
◦ Połaczenie
˛
z baza˛ danych należy zestawić za pomoca˛ standardowych interfejsów (ODBC,
JDBC) albo należy właczyć
˛
poziom abstrakcji, który można, opcjonalnie i bez konieczności wprowadzania zmian w kodzie programu, przestawić na ODBC, JDBC lub inne interfejsy.
◦ Należy wyizolować i zmodularyzować Statements SQL w kodzie programu.
3.13.5.1
Microsoft SQL Server 2000
Wraz z wersja˛ MS SQL Server 2000 wprowadzone zostały nowe rozwiazania
˛
dotyczace
˛ zwłaszcza funkcjonalności WWW. Główny punkt rozwoju dotyczył obsługi XML i poprawy skalowalności. W niniejszym podrozdziale wymienione zostały najważniejsze funkcjonalności.
Internet i Intranet
Najważniejsze rozszerzenia MS SQL Server 2000 z zakresu rozwiazań
˛
internetowych i intranetowych umieściliśmy w poniższej tabeli.46
F UNKCJA
46
Rozszerzone funkcjonalności Enterprise Edition nie zostały wymienione i można o nich poczytać w White
Papers oraz odpowiednich opisach technicznych.
231
◦ Obsługa XML, Xpath, XSL oraz HTTP:
◦ Wyświetlanie i dost˛ep do relacyjnych danych poprzez
zastosowanie widoków XML.
◦ Dost˛ep przez URL i HTTP do danych w Internecie.
Do generowania zapytań można wstawić szablony w
XML
SQL, XML albo Xpath w URLs.
◦ Zwracane moga˛ być wyniki zapytania SELECT w
formie XML.
◦ Dokumenty XML moga˛ być edytowane za pomoca˛
Transact - SQL i Stored Procedures.
zintegrowany Datamining
obsługa
multiplen
instancji
bezpieczeństwo
Umoż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 poniższej tabeli pokazane zostały najważniejsze nowości zwiazane
˛
z zarzadzaniem
˛
i opcjami
programowania Microsoft SQL Server 2000.
F UNKCJONALNO ŚCI
integracja Active Directory
Integracja centralnej usługi katalogowej MS
232
Przesuwanie i kopiowanie baz danych i obiektów pomi˛easystent
kopiowania
baz danych i DTS
dzy serwerami. Data Transformation Services umożliwiaja˛
import i eksport kluczy głównych i obcych pomi˛edzy obsługiwanymi produktami bazodanowymi.
zdefiniowane
przez
Tworzenie funkcji Transact - SQL wielokrotnego użytku.
użytkownika funkcje
oraz nowe triggers
Zamiast albo po procesie rozszerzone triggers do wykonywania kodu.
Można używać nowych typów danych (bigint, sql_variant,
table) i można definiować indeksy w typach kolumn, gdy
typy danych, indeksy i
dane w kolumnach obliczane sa˛ z innych kolumn. Na po-
sortowania
ziomie kolumn możliwe jest sortowanie. Umożliwia to zapisywanie obiektów, które charakteryzuja˛ różne zasady sortowania w tej samej bazie danych.
Analysis Services, wirtualne Cubes oraz generator MDX
Analysis Services umożliwia rozwijanie rozwiazań
˛
OLAP Datawarehousing i Datamining. Ich edycj˛e umożliwia edytor wirtualnych Cubes. Za pomoca˛ generatora MDX można
tworzyć wyraż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
˛
funkcjonalności Exchange 5.5 za pomoca˛ rozwiazań
˛
alternatywnych, które moga˛ być
stosowane w systemach opartych na Linuksie, jak też kontynuacja z wykorzystaniem Exchange
2000. Jeśli chodzi o migracj˛e zast˛epujac
˛ a,˛ głównym aspektem oceny technicznej jest wykorzystanie heterogenicznych środowisk systemowych składajacych
˛
si˛e z linuksowych serwerów i z
windowsowych klientów przy dalszym, pełnym zastosowaniu MS Outlook.
W wyniku rozważań dwa z ocenianych rozwiazań
˛
okazały si˛e być szczególnie właściwe,
gdyż w dużym stopniu spełniaja˛ one wymóg połaczenia
˛
w czasie rzeczywistym. Za pomoca˛
połaczenia
˛
w czasie rzeczywistym można bezkonfliktowo korzystać z funkcjonalności grup. W
przypadku obydwu rozwiazań
˛
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łożonym ze składnika serwera, który jest Wolnym Oprogramowaniem i właści-
233
cielskiego Outlook - Connector, który dost˛epny jest jako komercyjny moduł oprogramowania.
Exchange4Linux obsłuży maksymalnie do 500 użytkowników, jest zatem przeznaczony raczej
dla mniejszych urz˛edów. Samsung Contact nadaje si˛e zwłaszcza do zastosowań w średnich i dużych urz˛edach. Oprócz tego istnieje jeszcze rozwiazanie
˛
OSS o nazwie Kroupware, które można
połaczyć
˛
z MS Outlook za pomoca˛ komercyjnego Bynari - connector. Dla Kroupware istnieje
obecnie ograniczenie polegajace
˛ na tym, że nie ma wystarczajacych,
˛
rzeczywiście roboczych
doświadczeń.
Tam, gdzie nie jest wymagane połaczenie
˛
w czasie rzeczywistym, można zastosować komercyjny produkt OpenExchange firmy SuSE.
Ponadto przez połaczenie
˛
w czasie rzeczywistym możliwe jest daleko idace
˛ zastapienie
˛
funkcjonalności Exchange 5.5. Jedyny wyjatek
˛ stanowi tu korzystanie z formularzy, które nie jest
możliwe w przypadku rozpatrywanych rozwiazań.
˛
Oprócz zastosowań w środowiskach heterogenicznych, ważna˛ rol˛e odgrywaja˛ także możliwe rozwiazania
˛
dla ś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 niezależnego od platformy. Oprócz tego, w przypadku
wszystkich ocenianych rozwiazań,
˛
istnieja˛ jeszcze klienty WWW, których jednak można używać
z wi˛ekszymi badź
˛ mniejszymi funkcjonalnymi ograniczeniami. Nie jest możliwe korzystanie z
nich w trybie offline. Jednakże z funkcjonalności poczty korzystać można za pomoca˛ wszystkich
klientów obsługujacych
˛
POP3 i IMAP.
Jeśli chodzi o migracj˛e kontynuacyjna˛ do MS Exchange 2000, należy przyjać,
˛ że rozwiaza˛
nie to możliwe jest tylko w połaczeniu
˛
z zastosowaniem Active Directory. Chodzi przy tym o
zasadnicza,˛ strategiczna˛ decyzj˛e, o której pisaliśmy już w ocenie rozwiazań
˛
opartych na AD w
rozdziale 3.7.
3.14.2 Wprowadzenie
Zgodnie z tym, co napisaliśmy w rozdziale 2, należy założyć, że w wi˛ekszości urz˛edów stosowanym rozwiazaniem
˛
Groupware jest Exchange. Dlatego najpierw opisaliśmy punkt wyjścia i
rozpatrzyliśmy różne rozwiazania
˛
Groupware dla migracji zast˛epujacej,
˛
które można zastosować
w linuksowych systemach operacyjnych. Oceniliśmy zarówno czyste projekty Open Source, jak
i produkty komercyjne. Produkty te służa˛ cz˛eściowo różnym punktom wyjścia, celom i grupom
celów. Zasadniczo można jednak z góry odróżnić czyste rozwiazania
˛
klient - serwer oparte na
WWW od klasycznych rozwiazań
˛
klient - serwer. Ze wzgl˛edu na duża˛ ilość różnego oprogramowania nie można ocenić wszystkich rozwiazań,
˛
które sa˛ dost˛epne na rynku. Rozpatrywane
234
rozwiazania
˛
wybrane zostały w oparciu o różne scenariusze wymagań.
Jeśli chodzi o migracj˛e kontynuacyjna˛ oceniliśmy MS Exchange 2000 oraz w niektórych
punktach także MS Exchange 2003.
3.14.3 Punkt wyjścia - Microsoft Exchange 5.5
W tym miejscu przedstawione zostały najważniejsze cechy i funkcjonalnoś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 może
rozciagać
˛
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
bezpośrednio przesyłaja˛ do siebie poczt˛e i bezpośrednio replikuja˛ wzajemnie informacj˛e katalogowa.
˛ Przekazywanie (Routing) wiadomości pocztowych pomi˛edzy punktami centralnymi
trzeba specjalnie skonfigurować. 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˛eć informacji (Information Store, IS)
oraz
◦ kontrola systemu (System Attendant, SA)
235
Katalog Exchange zapisuje wszystkie informacje o użytkownikach, zasobach i organizacji (dir.edb).
Należa˛ do nich listy zarejestrowanych na serwerze użytkowników poczty elektronicznej, nazwy
i konfiguracje serwerów. Należy zwrócić uwag˛e na fakt, że w katalogu zapisywane sa˛ wszelkie
informacje o konfiguracji.
Pami˛eć 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 wiadomości i załaczniki
˛
plikowe dla użytkowników, których skrzynki pocztowe znajduja˛ si˛e na danym serwerze.
„Public Information Store“ zapisuje treść kopii publicznych katalogów.
Message Transfer Agent (MTA) wysyła wiadomości do innych serwerów, punktów centralnych i systemów zewn˛etrznych. W połaczeniu
˛
z katalogiem Exchange MTA decyduje o routingu
wiadomości. MTA przekazuje przychodzace
˛ wiadomości do pami˛eci informacji. MTA zajmuje
si˛e także konwersja˛ wiadomości do innych formatów.
Kontrola systemu jest dla serwera Exchange instancja˛ zarzadzaj
˛
ac
˛ a.˛ Za pomoca˛ tego składnika można, na przykład, tworzyć nowych użytkowników poczty elektronicznej oraz wykonywać 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 może być 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.
◦ Jest podstawowym składnikiem infrastruktury komunikacyjnej serwera Exchange.
MTA
◦ Przesyła wiadomości do innych serwerów, punktów
centralnych i systemów.
◦ Konwertuje formaty dla innych systemów.
◦ Zapisywanie wiadomości wysyłanych do poszczególnych użytkowników.
pami˛eć informacji
◦ Przetwarzanie i zapisywanie informacji wewnatrz
˛ publicznych katalogów.
◦ Prywatne i publiczne informacje przechowywane sa˛
w dwóch oddzielnych bazach danych.
◦ Protokołowanie aktywności Messaging.
◦ Nadzorowanie połaczeń
˛
pomi˛edzy serwerami.
◦ Tworzenie tablic routingu.
kontrola systemu
◦ Kontrolowanie replikacji katalogów i usuwanie konfliktów.
◦ Protokołowanie rozsyłania wiadomości.
◦ Generowanie adresów e - mail dla nowo utworzonych
użytkowników.
236
237
Tablica 3.43: Podstawowe składniki Exchange 5.5
3.14.3.4
Składniki opcjonalne
Zakres funkcji serwera Exchange można rozszerzyć o opcjonalne, modularne składniki, takie
jak, np. różne konektory oraz serwer zarzadzaj
˛
acy
˛ kluczami.
Konektory (Connectors) przekazuja˛ wiadomości pomi˛edzy róż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óżnić moż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łaściwa˛ konwersj˛e treści wiadomości i informacji adresowych. Dzi˛eki temu wiadomości z Exchange można odczytać w obcym systemie a wiadomości obcego systemu moga˛ być
czytane przez użytkowników Microsoft Exchange.
Serwer zarzadzaj
˛
acy
˛ kluczami (Key Management Server, KMS) można wykorzystać do
administrowania kluczami, za pomoca˛ których przesyłane sa˛ szyfrowane wiadomości albo wiadomości opatrzone podpisem cyfrowym.
238
Dalszym opcjonalnym składnikiem jest Chat - Server. Umożliwia on realizacj˛e tak zwanych „Internet Relay Chats“ (IRC), dzi˛eki którym z kolei możliwa jest jednoczesna, wzajemna
komunikacja dużej ilości uczestników.
Poczawszy
˛
od wersji 5.5 zaimplementowany został także tak zwany Server Scripting Service. Usługa ta zapewnia możliwość umieszczania skryptów napisanych w j˛ezyku skryptowym,
takim jak Perl, VB Script albo JScript, w publicznym katalogu. Powyższa usługa zapewnia wykonywanie programów w wypadku wystapienia
˛
określonych zdarzeń. Za pomoca˛ skryptów można
automatyzować zadania.
3.14.3.5
Obsługa protokołów
Exchange obsługuje cały szereg różnych protokołów, z których najważniejsze zostały przedstawione w niniejszym podrozdziale.
Simple Mail Transfer Protocol (SMTP) jest standardowym protokołem służacym
˛
do przekazywania wiadomości w Internecie.
Do dostarczenia wiadomości do nie zawsze połaczonych
˛
komputerów - klientów służ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 wiadomości. Przesyłanie wiadomości odbywa si˛e za pomoca˛ SMTP.
Inne zastosowanie ma standard IMAP4, który obsługiwany jest przez produkty e - mail. Duża˛
siła˛ IMAP4 w porównaniu z POP3 jest zdolność wybiórczego ściagania
˛
wiadomości z serwera.
Dzi˛eki temu można oddzielnie ściagać
˛
wiadomości i ewentualnie istniejace
˛ załaczniki.
˛
Poprzez integracj˛e z HTTP można udost˛epniać w Internecie dokumenty z katalogów publicznych. Jeśli zastosowany zostanie Microsoft Internet Information Server (IIS) oraz Exchange
Server 5.5 użytkownicy uzyskaja˛ poprzez Active Server Web Access (OWA) możliwość korzystania z funkcjonalnoś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 też powodu
obsługa HTTP wymaga istnienia Internet Information Server z funkcjonalnościa˛ ASP. Użytkownicy moga˛ na przykład przegladać
˛
prywatne i publiczne katalogi, wysyłać oraz odbierać wiadomości pocztowe i korzystać 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 świecie Newsgroups. Treści Newsgroups
przesyłane sa˛ poprzez NNTP z serwera do serwera. Exchange Server może za pomoca˛ połaczenia
˛
NNTP udost˛epniać treści Newsgroups w katalogach publicznych.
239
LDAP umoż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óż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
Funkcjonalności użytkownika
Funkcjonalnościami, z których korzystać może uż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 ksiażki
˛ adresowe i osobiste kontakty)
◦ prowadzenie notatnika
Za typowe oprogramowanie klienckie uznaliś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˛ możliwość 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) można udost˛epniać, np. Workflows albo skrzynki
pocztowe dla grup. Zastosowanie publicznych katalogów umożliwia wspólne korzystanie z informacji. Użytkownicy, którzy posiadaja˛ odpowiednie uprawnienia, moga˛ czytać i / lub zapisywać
informacje zapisane w katalogach.
3.14.3.8
240
Komunikacja klient - serwer
Komunikacja pomi˛edzy klientem a serwerem odbywa si˛e w typowym ś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 można realizować najróżniejsze scenariusze komunikacji klienta z serwerem.
3.14.3.9
Komunikacja serwer - serwer
Komunikacja pomi˛edzy serwerami Exchange może być sterowana za pomoca˛ różnorodnych konektorów. Jeś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 niebezpieczeństwo
ataku wirusów. W Exchange istnieje możliwość zaimplementowania oprogramowania antywirusowego tworzonego przez innych producentów, jeśli skorzysta si˛e z napisanego przez nich
antywirusowego API.
Wielu producentów oferuje dla środowisk Exchange integracj˛e rozwiazań
˛
umożliwiajacych
˛
wysyłanie faksów. Oprogramowanie innych producentów pozwala także archiwizować poczt˛e
elektroniczna˛ albo usuwać obiekty pocztowe nie b˛edace
˛ w użyciu od dłuższego czasu (Hierarchical Storage Management, HSM).
˛
Cel migracji zast˛epujacej
˛ może być za każdym razem inny i zależeć od danego przypadku. Przed
przystapieniem
˛
do migracji należy dokładnie określić rzeczywiste wymagania wzgl˛edem produktu Groupware. Nast˛epujaca
˛ lista pokazuje przykładowe kryteria wyboru rozwiazania
˛
Groupware:
◦ Jakie systemy klienckie maja˛ być obsługiwane?
– tylko klienty oparte na WWW
– klienty Outlook (obsługa MAPI)
– systemy klienckie oparte na Linuksie
241
– klienty w systemach heterogenicznych (systemy windowsowe i linuksowe)
◦ Jakie funkcjonalności Groupware musi wspierać nowy system?
◦ Jakie wymagania stawiane sa˛ co do skalowalności systemu?
◦ itd.
Weryfikacja wymagań wzgl˛edem nowego produktu Groupware jest niezb˛edna i należy ja˛ przeprowadzić przed rozpocz˛eciem realizacji każ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 treści odbywa si˛e w oparciu o j˛ezyk skryptowy PHP. Treści udost˛epniane sa˛ za pomoca˛ serwera WWW. Do zarzadzania
˛
danymi i ich przechowywania można wykorzystać baz˛e
danych MySQL. Jako system bazodanowy można jednak wybrać również PostgreSQL, Oracle
i Sybase, a do zarzadzania
˛
adresami można wykorzystać katalog LDAP. Również autoryzacj˛e użytkowników można realizować za pomoca˛ różnych technologii (SQL, SQL_SSL, LSAP,
HTTP, NIS, PAM).
Aby korzystać z poczty elektronicznej można zastosować dowolny serwer pocztowy. Musi
on obsługiwać protokoły SMTP i POP3 / IMAP. Obecnie nie jest możliwa obsługa profilów
nieobecności oraz reguł filtrowania opartych na serwerze.
phpGroupware jest systemem modularnym. Podczas integracji można wybierać spośród różnych modułów. Oprócz w/w modułów realizujacych
˛
klasyczne funkcjonalnoś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 zaproszeń i prawami dost˛epu
Kontaktowa baza danych
http://www.phpgroupware.org/
Email
Klient e - mail
Forum
Forum wiadomoś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
Powyższe moduły moga˛ być opcjonalnie aktywowane przez administratora. Interfejsy WWW
opieraja˛ si˛e na systemie szablonów. Wyróżnić moż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˛eściowo problematyczne jest stosowanie javascript, ponieważ nie wszystkie przegladarki
˛
bezbł˛ednie interpretuja˛ kod javascript. Ponadto jego
stosowanie nie jest dozwolone w wielu urz˛edach ze wzgl˛edu na wymagania bezpieczeństwa.
Zastosowanie czystego rozwiazania
˛
opartego na WWW oferuje wiele zalet:
◦ możliwy jest dost˛ep poprzez przegladark˛
˛
e, także bezpieczny dost˛ep z zewnatrz
˛ poprzez
HTTPS.
◦ nie jest konieczna instalacja specjalnego klienta.
◦ niezależność od systemu operacyjnego daje szczególne korzyści w heterogenicznym środowisku klienckim:
◦ aktualizacja oprogramowania odbywa si˛e po stronie serwera.
Oprócz zalet istnieja˛ jednak również wady:
◦ niemożliwy jest dost˛ep do danych, gdy użytkownicy pracuja˛ w trybie offline badź
˛ gdy
nie maja˛ dost˛epu do odpowiedniej sieci. Stanowi to problem zwłaszcza dla pracowników
zewn˛etrznych.
◦ nie istnieje synchronizacja z przenośnymi urzadzeniami
˛
końcowymi (PDAs).
243
Podsumowujac
˛ trzeba stwierdzić, że przedstawione rozwiazanie
˛
nie jest alternatywa˛ dla Outlook
- Exchange. Jednakże korzystanie z zaprezentowanego produktu Groupware może być korzystne
szczególnie w małych organizacjach, nie wymagajacych
˛
każdorazowego si˛egania do zaawansowanych funkcji. Zaleta˛ jest jego elastyczność i możliwości dostosowania poszczególnych modułów do rzeczywistych potrzeb organizacji.
Podobne rozwiazanie
˛
oferuje także PHProjekt.
Obydwa projekty udost˛epniły w Internecie swoje wersje demonstracyjne 48, dzi˛eki którym
zainteresowani moga˛ ocenić proponowany zakres możliwości.
3.14.4.2
Kroupware
Federalny Urzad
˛ ds. Bezpieczeństwa w Informatyce (BSI) zlecił konsorcjum firm stworzenie
rozwiazania
˛
Groupware b˛edacego
˛
Wolnym Oprogramowaniem dla potrzeb BSI. Tym samym z
oprogramowania tego moga˛ skorzystać wszyscy zainteresowani, bez ponoszenia opłat licencyjnych. Celem projektu jest stworzenie ponadplatformowego rozwiazania
˛
Groupware, z którego
korzystałyby zarówno klienty linuksowe, jak i klienty windowsowe. Funkcjonalności wymagane
przez BSI sa˛ porównywalne z tymi oferowanymi przez połaczenie
˛
Outlook / Exchange firmy
Microsoft. System kliencki Outlook ma umieć współpracować 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 poniższej tabeli.
S KŁADNIKI
Z AKRES
FUNKCJI
Cyrus IMAP
Serwer pocztowy IMAP
Cyrus SASL
Autoryzacja
Cyrus LDAP
Zarzadzanie
˛
uż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/
244
Kroupware zbudowany jest w oparciu o klasyczny model klient - serwer, który gwarantuje
użytkownikom asynchroniczne korzystanie z funkcjonalności Groupware. B˛edac
˛ offline maja˛
oni za pomoca˛ oprogramowania klienckiego, np. możliwość korzystania z poczty elektronicznej, terminarza i osobistych list zadań. Zmiany synchronizowane sa˛ dzi˛eki późniejszej replikacji danych. Projekt Kroupware może obsługiwać do 1500 użytkowników na jednym serwerze.
Jego skalowalność opiera si˛e na możliwościach klastra IMAPD i OpenLDAP. Instalacja obydwu
systemów przewidziana jest w przypadku dużych ilości użytkowników, co ma umożliwić korzystanie z nich wi˛ekszemu kr˛egowi osób. W przypadku zastosowania produkcyjnego decydujaca
˛
jest takż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. Stopień skomplikowania zależy od narz˛edzi stosowanych do tworzenia
kopii bezpieczeństwa. Oprócz całych skrzynek pocztowych istnieje także możliwość odtwarzania pojedynczych wiadomości i terminów.
Klienty
Dost˛ep do funkcjonalności poczty elektronicznej i Groupware moż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 być zainstalowany po stronie klientów. Konektor umoż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łości alternatywa˛ mógłby być 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 użytkownikom na intuicyjna˛ prac˛e. Klient obsługuje protokoły POP3 i disconnected
IMAP4. Po stronie klienta obsługiwane jest również filtrowanie nadchodzacej
˛ poczty elektronicznej (spam, itd.).
Poniżej zamieściliśmy list˛e najważniejszych funkcjonalności Groupware. Funkcjonalnoś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
245
◦ zarzadzanie
˛
kontaktami pojedynczego użytkownika
◦ globalna ksiażka
˛
adresowa
◦ grupowy kalendarz i terminarz
◦ wspólne zasoby (katalogi publiczne)
◦ notatki i listy zadań
◦ listy wolny / zaj˛ety
◦ potwierdzenia nieobecności
◦ potwierdzenie przeczytania
◦ synchronizacja Palm PDA
Bezpieczeństwo
Developerzy zwracali szczególna˛ uwag˛e na integracj˛e standardów bezpieczeństwa. Istnieje
możliwość całkowicie szyfrowanej komunikacji (SSL / TLS) pomi˛edzy systemami klienckimi a
serwerem. Szyfrowana˛ komunikacj˛e można realizować 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
Jeśli chodzi o metody zarzadzania,
˛
stworzono specjalne grupy użytkowników o szczególnych
uprawnieniach. Wyróżnić można nast˛epujace
˛ grupy:
◦ administrator
◦ maintainer
52
www.gnupg.org/aegypten
246
◦ user (użytkownik)
Administrowanie może odbywać si˛e za pomoca˛ Frontendu, w ograniczonym zakresie, odpowiednio do posiadanych uprawnień. Proste zadania administracyjne można realizować za pomoca˛ interfejsu WWW. W przypadku bardziej skomplikowanych czynności należy dostosować
odpowiednie pliki konfiguracyjne.
Poprzez Frontend WWW można, na przykład, wykonywać nast˛epujace
˛ zadania:
◦ zarzadzać
˛
użytkownikami i ksiażk
˛ a˛ adresowa˛
◦ zarzadzać
˛
publicznymi katalogami
◦ cz˛eściowo administrować serwerem
◦ potwierdzać nieobecność.
Poprzez Frontend WWW możliwy jest przede wszystkim dost˛ep do usługi katalogowej. Inne
działania dostosowujace
˛ należy wprowadzać w odpowiednich składnikach.
Pojedynczy użytkownicy maja˛ także możliwość samodzielnego wprowadzania określonych
zmian. I tak użytkownicy moga˛ modyfikować swoje dane osobowe i na przykład dodawać kolejne
adresy e - mail.
Migracja
Obecnie nie ma jeszcze praktycznych rozwiazań
˛
w obszrze projektów migracyjnych: w przypadku migracji istniejacych
˛
danych można jednak zasadniczo korzystać z nast˛epujacych
˛
mechanizmów:
◦ eksport informacji z katalogu za pomoca˛ LDIF oraz dostosowanie danych w oparciu o
skrypty.
◦ wiadomości e - mail należy przenosić do nowego klienta za pomoca˛ POP3
◦ transfer danych w formacie vCard albo iCalender.
Wnioski
Obecnie nie można jeszcze konkretnie wypowiadać si˛e o przydatności Kroupware. Brakuje ku
temu wymownych doświadczeń zebranych w środowiskach produkcyjnych. W przyszłości Kroupware b˛edzie z pewnościa˛ adekwatna˛ podstawa˛ Groupware dla małych i średnich organizacji.
247
Zaleta˛ powyższego rozwiazania
˛
jest modularna budowa całego systemu, przy tworzeniu którego
wykorzystane zostały sprawdzone i skalowalne składniki.
Możliwość zarzadzania
˛
użytkownikami wewnatrz
˛ centralnej usługi katalogowej upraszcza
zarzadzanie
˛
danymi. Usług˛e katalogowa˛ można także wykorzystywać 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 ś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 użytkownicy tego produktu moga˛ skorzystać z wielu rozwiazań
˛
umożliwiajacych
˛
realizacj˛e zadań Groupware. Z jednej strony system serwerowy można pobrać za darmo w postaci pakietów Debiana, a z drugiej strony zamówić pełne rozwiazanie
˛
rozprowadzane przez
Neuberger & Hughes. To ostatnie obejmuje oprócz zintegrowanego systemu Groupware także
oprogramowanie ułatwiajace
˛ dost˛ep o nazwie „Easygate“. Easygate udost˛epnia najważniejsze
usługi infrastrukturalne (DHCP, DNS, serwer plików, serwer proxy, Internet).
Serwer
Funkcjonalnoś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 niżej).
S KŁADNIKI
F UNKCJONALNO Ś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
248
Istnieje możliwość zaimplementowania do usługi katalogowej serwera Bill. Nad taka˛ możliwościa˛ należy si˛e zastanawiać zwłaszcza w połaczeniu
˛
z Samba.˛ Możliwe jest wówczas centralne zarzadzanie
˛
użytkownikami domen NT i składnikami Groupware. Rozwiazania
˛
tego nie
można jednak zrealizować, jeśli korzysta si˛e z pełnego systemu z N & H. W takim przypadku
administratorzy musza˛ wprowadzić 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 należy zainstalować po stronie klienta. MAPI - Clients wydaja˛ odpowiednie polecenia
Outlooka na serwerze Bill wykorzystujac
˛ Corba. MAPI Service Provider N & H jest produktem
komercyjnym i jego używanie zwiazane
˛
jest z zakupem licencji.
Serwer ten obsługuje w połaczeniu
˛
z Microsoft Outlook - Client nast˛epujace
˛ funkcjonalności:
◦ zarzadzanie
˛
adresami poszczególnych użytkowników
◦ globalna ksiażka
˛
adresowa
◦ grupowy kalendarz i terminarz
◦ wspólne zasoby
◦ zarzadzanie
˛
zadaniami
◦ notatki w prywatnych i publicznych katalogach
◦ funkcja wolny & zaj˛ety
◦ zaproszenia z możliwościa˛ przyj˛ecia albo odmowy
◦ potwierdzenia nieobecności
◦ synchronizacja PDA poprzez Outlook.
Obsługa innych klientów nie jest jeszcze możliwa. W planie jest jednak ukazanie si˛e w nast˛epnej
wersji klienta WWW obsługujacego
˛
najważniejsze funkcjonalności Groupware.
249
Bezpieczeństwo
Transmisja danych pomi˛edzy systemami może być szyfrowana. Można w tym celu korzystać
ze standardu SSL i TLS. Za pomoca˛ oprogramowania innych producentów możliwe jest, po
stronie serwera, sprawdzanie nadchodzacej
˛ poczty pod katem
˛
wirusów. Opcje bezpieczeństwa
uzupełnione sa˛ o wykonywane na serwerze reguły filtrowania, które chronia˛ przed niechcianymi
wiadomościami.
W celu ochrony przed nieuprawnionym dost˛epem, wewnatrz
˛ katalogów publicznych można
nadawać prawa dost˛epu. Prawa dost˛epu realizowane sa˛ za pomoca˛ tak zwanych Access Controll
Lists (ACL).
Zapisywanie danych wewnatrz
˛ systemu bazodanowego oferuje także wzgl˛ednie prosta˛ możliwość przywracania pojedynczych danych utraconych wskutek ich niezamierzonego usuni˛ecia.
Proces ten można realizować 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óżnić można tylko
użytkowników i administratorów. Dalszy podział nie jest przewidziany. Frontend WWW dostarczany wraz z pełnym rozwiazaniem
˛
umożliwia administrowanie zadaniami routine. Bardziej
skomplikowane czynności administracyjne wykonywać można za pomoca˛ tradycyjnego oprogramowania udost˛epnianego wraz z Linuksem.
Migracja
Jeśli chodzi o migracj˛e danych, w zależności od punktu wyjścia można zaproponować różne
rozwiazania.
˛
W przypadku bardzo małej migracji (mniej wi˛ecej do 10 użytkowników) zalecane jest skopiowanie skrzynek pocztowych oraz innych danych do katalogu osobistego w danym systemie
klienckim. Dane te można później zaimportować do skrzynek pocztowych założonych w nowym
systemie. Tego typu post˛epowanie jest bardzo bezpieczne lecz jednocześnie zajmuje też bardzo
dużo czasu. W przypadku migracji obejmujacej
˛ do 250 użytkowników zalecane jest skorzystanie również z innych narz˛edzi. Dane użytkowników Exchange można wyeksportować za pomoca˛
konsoli Exchange Administrator i narz˛edzia firmy Microsoft „exmerge.exe“. Informacje o użytkownikach skrzynek pocztowych należy zapisać w prostym pliku CSV, a zawartość skrzynek
pocztowych można zabezpieczyć w dowolnie wybranym katalogu w postaci plików PST. Tak
samo należy także postapić
˛ w przypadku Publicznych Katalogów. Teraz można zaimportować
pliki CSV do Bill Workgroup Server wykorzystujac
˛ narz˛edzie migracyjne udost˛epniane przez
250
N & H. Nast˛epnie użytkownicy moga˛ za pomoca˛ Outlooka zaimportować do serwera zabezpieczone skrzynki pocztowe (pliki PST).
W przypadku wi˛ekszych projektów migracyjnych istnieja˛ jeszcze inne techniczne możliwości przenoszenia danych, które należy sprawdzić pod katem
˛
konkretnego przypadku.
Wniosek
Zaprezentowane rozwiazanie
˛
Groupware oferuje bardzo dobra˛ obsług˛e klientów Outlook, ponieważ wspiera wszystkie ważne funkcjonalności Groupware i udost˛epnia je użytkownikom. Niniejsze rozwiazanie
˛
jest obecnie zoptymalizowane dla scenariuszy migracji obejmujacych
˛
kilkuset użytkowników (maks. 500) i w tych ramach stosowane jest w ś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. Powyższe
rozwiazanie
˛
Groupware ma form˛e całoś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 pomyślany jako
rozszerzenie już istniejacych
˛
systemów, lecz jest przeznaczony do całkowicie nowej instalacji.
Dystrybutor oferuje swoim klientom rozwiazanie
˛
All - In - One złożone ze zsynchronizowanych
ze soba˛ pakietów.
Serwer
W tym miejscu należy ocenić tylko te pakiety, które sa˛ bezpośrednio zwiazane
˛
z opisywanym rozwiazaniem
˛
Groupware. Całe rozwiazanie
˛
składa si˛e z różnych modularnych jednostek
oprogramowania, które spójnie realizuja˛ funkcjonalności poczty elektronicznej i Groupware. Poniższa tabela zawiera centralne elementy tego rozwiazania.
˛
S KŁADNIKI
Z ADANIA
Postfix
Mail - Transfer - Agent (MTA)
Cyrus IMAPD
Realizuje funkcjonalności IMAP
Comfire
Funkcjonalności Groupware
OpenLDAP
Centralna usługa katalogowa do zarzadzania
˛
użytkownikami
Baza danych PostgreSQL
Baza danych do zarzadzania
˛
danymi Groupware
Apache - Tomcat
Realizacja Frontendu WWW (poczta, Groupware)
251
Tablica 3.51: Centralne składniki OpenExchange Server 4
Szczególna˛ zaleta˛ modularnej architektury jest jej skalowalność wynikajaca
˛ z przydzielania
składników różnym systemom. Modularna budowa umożliwia także elastyczne rozszerzanie istniejacych
˛
systemów.
Składniki serwera oferuja˛ obszerne funkcjonalności poczty elektronicznej i Groupware. Użytkownicy moga˛ korzystać z różnych funkcji:
◦ 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 funkcjonalności może odbywać si˛e w całkowicie poprzez zintegrowana˛ stron˛e
portalu WWW.
Klienty
Z uwagi na obsług˛e różnych systemów klienckich należy rozróżnić funkcjonalność poczty
elektronicznej od funkcjonalności Groupware. Dost˛ep do pierwszej funkcjonalności można realizować za pomoca˛ wszystkich klientów obsługujacych
˛
POP3 i IMAP. Użytkownicy moga˛ dodatkowo odwoływać si˛e do swoich wiadomości e - mail poprzez specjalnie zintegrowane rozwiazanie
˛
WWW.
Korzystanie z funkcjonalności Groupware można zasadniczo odbywać si˛e na dwa sposoby:
◦ dost˛ep do treści portalu WWW za pomoca˛ przegladarki
˛
WWW
◦ ograniczony dost˛ep za pomoca˛ klienta Outlook.
252
Dzi˛eki wykorzystaniu obszernego interfejsu WWW użytkownicy moga˛ odwoływać si˛e do w/w
funkcjonalności. Użytkownicy moga˛ korzystać z ksiażek
˛
adresowych opartych na LDAP, możliwości przyznawania uprawnień 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 każdorazowego przeciagu
˛ czasu ma miejsce automatyczna analiza udost˛epnianych zasobów. Oferty
oparte na stronach WWW umożliwiaja˛ użytkownikom korzystanie z rozległych funkcjonalności
grup.
Druga możliwość dost˛epu polega na skorzystaniu z klienta Microsoft Outlook. Może to nastapić
˛ tylko w przypadku zastosowania dodatkowego oprogramowania do replikacji, które należy
zainstalować po stronie klienta. Replikacja ta jest synchronizacja˛ danych na żadanie
˛
użytkownika, tym samym synchronizacja nie odbywa si˛e w czasie rzeczywistym, jak ma to miejsce w
przypadku konektora. Wspomniane oprogramowanie umożliwia połaczenie
˛
nast˛epujacych
˛
dziedzin: poczta elektroniczna, kontakty, zadania i osobiste terminy. Jeśli wystapi
˛ a˛ konflikty wówczas w konkretnym przypadku użytkownik musi sam zdecydować, w jaki sposób należy je rozwiazać.
˛
Replikacja danych realizowana jest za pomoca˛ SOAP w połaczeniu
˛
z HTTP i umożliwia
synchronizacj˛e danych po stronie serwera z danymi bazy danych Outlook. Dzi˛eki zastosowaniu Outlooka istnieje również możliwość wykonywania replikacji PDA. Interfejs MAPI firmy
Microsoft nie jest obsługiwany dla Outlook.
Obecnie w Outlooku nie ma możliwości tworzenia terminów grup. Wynika to z faktu, że
Outlook nie posiada dodatkowych funkcji serwera OpenExchange, takich jak delegowanie zadań. Obecnie nie jest jeszcze obsługiwana także ksiażka
˛
adresowa MAPI. Dlatego w dniu dzisiejszym nie jest możliwa prawidłowa implementacja czasu rzeczywistego. Jednak zgodnie z
informacjami producenta opcja ta jest właśnie tworzona.
Bezpieczeństwo
Aby uzyskać kodowana˛ transmisj˛e można skorzystać z OpenSSL. OpenSSL realizuje szyfrowanie danych pomi˛edzy aplikacjami i składnikami. IMAP i POP3 moga˛ przekazywać dane w
bezpieczny sposób poprzez tunel SSL a SMTP za pomoca˛ TLS.
Aby zwi˛ekszyć bezpieczeństwo w ruchu poczty można dodatkowo zainstalować skaner antywirusowy, co ma na celu identyfikacj˛e poczty sprawiajacej
˛ problemy oraz przesyłanych wraz
z nia˛ załaczników.
˛
Domyślnie stosować można filtr poczty SIEVE służacy
˛ do sortowania niechcianej poczty. Filtr ten umożliwia w razie potrzeby także ograniczenie rozmiaru wiadomości i
korzystanie z innych filtrów, zgodnie z dowolnie zdefiniowanymi kryteriami.
253
Administrowanie
Do wykonywania zadań administracyjnych dostarczany jest Frontend oparty na WWW. Administrator może decydować o tym, jakie dane wolno użytkownikom samodzielnie modyfikować.
Użytkownicy moga˛ poprzez Frontend WWW zmieniać swoje hasło i zapisywać swoja˛ nieobecność. Dzi˛eki temu opiekunowi systemu zmniejsza si˛e ilość pracy administracyjnej. Administrator może administrować wykorzystujac
˛ jeszcze inne opcje, za pomoca˛ których może on zadawać
podstawowe ustawienia dla składników Groupware, poczty elektronicznej oraz składników bezpieczeństwa. Ponadto podczas zarzadzania
˛
systemem stosować można tradycyjne środki (polecenia z linii poleceń i pliki konfiguracyjne).
Migracja
Na potrzeby migracji danych z systemu Microsoft Exchange 5.5 do OpenExchange Server
4 firma SuSE Linux AG oferuje specjalne wsparcie. Pracownicy SuSE AG badź
˛ 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 przenieść można nast˛epujace
˛ dane:
◦ listy użytkowników z odpowiednimi uprawnieniami
◦ lokalnie i globalnie zapisana˛ poczt˛e elektroniczna˛
◦ zadania
◦ kontakty
◦ terminy
◦ notatki.
Dane zwiazane
˛
z funkcjonalnościami, których nie obsługuje OpenExchange nie zostana˛ przeniesione. Do takich funkcji należa,˛ na przykład, journale, powtarzajace
˛ si˛e zadania, kategorie i
podkatalogi użytkowników.
Wnioski
Rozwiazanie
˛
Groupware firmy SuSE Linux AG oferuje modularny system Groupware, którego wi˛ekszość poszczególnych modułów opiera si˛e na sprawdzonych składnikach Open Source.
Jako składnik Groupware zintegrowano komercyjny pakiet „Comfire“, który otwiera użytkownikom dost˛ep do szerokich funkcjonalności Groupware. Dost˛ep użytkowników do odpowiednich
254
informacji Groupware może odbywać si˛e w oparciu o stron˛e WWW albo za pomoca˛ klienta
Outlook. Poprzez stron˛e WWW użytkownicy moga˛ odwoływać si˛e do całego portfolio rozwia˛
zania OpenExchange. Dla klientów Outlook funkcja ta jest jednak ograniczona. Użytkownicy
nie maja˛ obecnie możliwości dost˛epu do połaczenia
˛
w czasie rzeczywistym i również nie maja˛
prawdziwej obsługi MAPI. Tym samym użytkownikom udost˛epniana jest jedynie ograniczona
funkcjonalność Outlook.
3.14.4.5
Samsung Contact
Samsung Contact (SC) jest obszernym rozwiazaniem
˛
Groupware zaprojektowanym z myśla˛ o
zastosowaniach w przedsi˛ebiorstwach o różnej wielkości. System ten pozwana na zarzadzanie
˛
użytkownikami na serwerze w liczbie od kilkuset do dziesiatek
˛ tysi˛ecy. Funkcjonalność oprogramowania jest dalece kompatybilna z produktem Exchange firmy Microsoft. Wszystkie składniki
serwera dost˛epne sa˛ dla Linuksa (RedHat, SuSE) oraz wi˛ekszości odmian Uniksa (AIX, HP-UX,
Solaris). Takż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 umożliwia dost˛ep
z każdej platformy obsługujacej
˛ WWW. Poprzez dostarczany MAPI - Provider można w pełni
wykorzystywać istniejace
˛ funkcjonalności Outlook (98, 2000, XP).
Samsung Contact opiera si˛e na sprawdzonej technologii OpenMail firmy Hewlett - Packard
(HP). Przedsi˛ebiorstwo założ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 też
przejał
˛ od HP zespół programistów pracujacy
˛ nad projektem.
Serwer
Podstawowa architektura systemu przedstawiona została na poniższym rysunku:
255
Rysunek 3.28: Architektura Samsung Contact
System serwera składa si˛e z wielu niezależnych od siebie składników, które w sensie skalowania horyzontalnego można podzielić na wiele serwerów. Ponadto w systemie serwera możliwa
jest praca wielu całkowicie niezależnych od siebie instancji. Nast˛epujaca
˛ tabela stanowi przeglad
˛
procesów serwera i ich zadań.
S KŁADNIKI
Z AKRES
FUNKCJI
256
Przekazuje wiadomość do każdorazowej usługi niezb˛ednej dla
przetworzenia wiadomości. Zawiera ona wykonywanie reguł po
Service Router
stronie serwera sterujacych
˛
przydzielaniem wiadomości lub automatycznym odpowiadaniem na wiadomości.
Local Delivery
Dostarcza wiadomość do lokalnej skrzynki pocztowej.
Internet Mail Gateway
Służy do przekształcania wiadomości do Internet - Mail zgodnego
z MIME.
Remote Client Interface
Służy do łaczenia
˛
klientów poczty elektronicznej poprzez sieć.
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 umożliwiajaca
˛ kontrol˛e Mail - Routings. Gene-
Test Service
ruje ona prosta˛ odpowiedź e - mail.
Print Service
Umożliwia wydruk poczty elektronicznej po stronie serwera.
Służy do przetwarzania wiadomości za pomoca˛ skryptów po stro-
Request Service
nie serwera. Daje możliwość zarzadzania,
˛
np. mailing lists.
Directory Synchronisa-
Umożliwia synchronizacj˛e katalogów pomi˛edzy wieloma serwe-
tion
rami Samsung Contact.
Bulletin Board Service
Służy replikacji Bulletin Boards (Shared Folders) pomi˛edzy różnymi serwerami Samsung Contact.
Background Search Se-
Służy asynchronicznemu wyszukiwaniu informacji w Message -
rvice
Store.
Client Directory Ac-
Przygotowuje wpisy centralnych katalogów, aby móc je udost˛ep-
cess Service
niać, np. jako globalna˛ ksiażk˛
˛ e adresowa˛ w kliencie Outlook.
Application Link Se-
Umożliwia przyłaczenie
˛
zewn˛etrznych aplikacji, np. Fax - Gate-
rvice
ways.
Udost˛epnia zawartość skrzynki pocztowej poprzez protokół
POP3 Service
POP3.
omscan Service
Directory Relay
Służy do sprawdzania spójności Message - Stores.
Se-
rvice
Container Access Monitor
Służy do odpytywania katalogów znajdujacych
˛
si˛e na odległych
serwerach Samsung Contact.
Sprawdza prawa dost˛epu do Message - Store.
257
Służy do powiadamiania procesów klienckich o zdarzeniu (np.
Notification Service
gdy nadchodzi nowa wiadomość 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łuży OpenLDAP.
Centralny proces służacy
˛ bezpiecznemu zarzadzaniu
˛
kolejkami
wiadomości.
Proces wykonywany w tle w celu pozbycia si˛e usuni˛etych wiadomości z Message - Store.
Udost˛epnia zawartość skrzynki pocztowej poprzez protokół
IMAP.
Służy do odbierania wiadomoś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.
Umożliwia odbieranie i wysyłania wiadomości do pagerów badź
˛
SMSów.
Tablica 3.53: Składniki Samsung Contact
Jako Mail - Transport - Agent (MTA) domyślnie stosowany jest Sendmail. Zasadniczo można
także korzystać z serwera pocztowego Postfix. Serwerem WWW polecanym dla klientów WWW
i Frontendu administracyjnego jest Apache.
Samsung Contact można instalować jako Single - Server albo też wykonywać instalacj˛e
dzielona˛ obejmujac
˛ a˛ wiele punktów centralnych. Skrzynka pocztowa użytkownika jest jednak
zawsze przyporzadkowana
˛
do jednego w˛ezła serwera. Katalog ten można replikować ponad granicami punktów centralnych. Public Shared Folders znane ze środowiska Microsoft Exchange
udost˛epniane sa˛ w postaci Bulletin Boards (BB). Również je można replikować ponad granicami punktów centralnych, co stanowi zalet˛e przede wszystkim w przypadku waskopasmowych
˛
połaczeń
˛
pomi˛edzy dwoma punktami centralnymi.
W celu umoż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
258
przyłaczania
˛
systemu Unified - Messaging (voice, fax).
Jeśli chodzi o kryterium wysokiej niezawodności, Samsung Contact jest już projektem zoptymalizowanym. Wi˛ekszość parametrów systemu można zmienić w trakcie pracy systemu, bez
konieczności ponownego uruchamiania całego systemu. Aby uchronić si˛e przez awaria˛ osprz˛etu
na w˛eźle pocztowym, radzimy uruchamiać 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 można dopasować każde oprogramowanie klastrowe, które umoż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łużacego
˛
do
przyłaczania
˛
klientów Microsoft Outlook istnieje jeszcze klient Groupware napisany w Java, jak
też odpowiedni interfejs WWW. Domyś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 można odwoływać si˛e do zawartości skrzynek pocztowych, jak i do standardowych protokołów POP3 oraz IMAP4. Dlatego do ściagania
˛
i wysyłania poczty elektronicznej można stosować dowolnego klienta poczty obsługujacego
˛
POP3 albo
IMAP (np. Eudora, Evolution, Mozilla, Netscape, Outlook Express, K-Mail). Aby umożliwić
dost˛ep do WAP, można skorzystać z dostosowanej wersji klienta WWW.
Korzystanie z klienta Outlook możliwe jest dzi˛eki implementacji MAPI serwera Samsung
Contact. Odwzorowane sa˛ wszystkie istotne funkcjonalności serwera. Rozwiazanie
˛
to zawiera
także wszystkie najważniejsze Features Groupware. SC umożliwia przyznawanie praw dost˛epu
do poszczególnych katalogów (poczta, terminy, kontakty, zadania) innym użytkownikom. Public Shared Folders, znane ze środowiska Microsoft Exchange, udost˛epniane sa˛ w postaci Bulletin Boards. Obsługiwane jest także tworzenie reguł po stronie serwera w celu przydzielania nadchodzacych
˛
wiadomości oraz automatyczne tworzenie komunikatu o nieobecności. W
przypadku nieobecności użytkownika można zdefiniować zast˛epc˛e, który w tym okresie czasu
otrzyma odpowiednie prawa dost˛epu. Wyznaczanie spotkań, podobnie jak w przypadku Microsoft Exchange, można ułatwić sobie za pomoca˛ listy free - busy, która zarzadzana
˛
jest w katalogu serwera Samsung Contact. Aby umożliwić zastosowania przenośne, zaimplementowano
synchronizacj˛e katalogów offline.
259
Bezpieczeństwo
Samsung Contact nie oferuje domyślnie szyfrowania wiadomości. Istnieja˛ jednak rozwiazania
˛
innych producentów, które umoż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 wcześniej tunel SSL (stunnel).
Autoryzacja użytkowników realizowana jest za pomoca˛ architektury PAM. Wykorzystywana
jest ona do administrowania, zarówno przez procesy serwera, jeśli chodzi o protokoły UAL /
IMAP / POP3, jak też przez narz˛edzia działajace
˛ z linii poleceń. Oprócz autoryzacji do katalogu
Samsung Connect, możliwa jest takż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
umoż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 zapytań
Rozmiar maksymalnego miejsca na dysku wykorzystywanego przez użytkownika do zapisywania danych można ograniczyć poprzez kwotowanie.
Do zabezpieczania (Backup) Message - Stores nie jest wymagane specjalne oprogramowanie.
Skorzystać można z każdego produktu udost˛epnianego przez system operacyjny, w którym pracuje serwer. Konstrukcja systemu Samsung Contact umożliwia spójne zabezpieczanie w trakcie
pracy. Do wykonywania Single User Backup / Restore służy narz˛edzie pracujace
˛ z linii poleceń.
Z jego pomoca˛ w prosty sposób można przenieść pojedynczego użytkownika z jednego w˛ezła
pocztowego do drugiego. W celu ochrony przed wirusami, zasadniczo skorzystać można z każdego antywirusowego Gateway opartego na SMTP (MIME - Sweeper, Trendmicro Viruswall).
Oprogramowanie antywirusowe AHN (www.ahnlab.com) jest zintegrowane po stronie serwera. Oprócz ochrony przed wirusami można także, po stronie serwera, filtrować wiadomości
pocztowe w oparciu o filtry zdefiniowane przez użytkownika. Konfiguracja ich odbywa si˛e poprzez Frontend WWW. SMTP - Relay obsługuje ochron˛e antyspamowa˛ zgodnie z RFC 2505.
260
Administrowanie
Administrować w˛ezłami pocztowymi Samsung Contact można na dwa różne sposoby: z jednej
strony istnieje prosty Frontend WWW służacy
˛ do zakładania kont użytkowników, list przydzielania i wpisów katalogowych, a z drugiej strony istnieje cała masa narz˛edzi działajacych
˛
z linii poleceń, umożliwiajacych
˛
administrowanie wszelkimi składnikami. Frontend WWW wymyślony
został na potrzeby codziennej pracy. Konsolowy interfejs przeznaczony jest w pierwszym rz˛edzie
do zautomatyzowania zadań administracyjnych.
Administrować systemem może każdy użytkownik, który posiada uprawnienia administratora. Dodatkowy wpis do katalogu systemowego określa, czy dany użytkownik ma być traktowany jak administrator.
Migracja
Migracj˛e ze środowiska Exchange albo Outlook do Samsung Contact przeprowadzić można na
różne sposoby. Jeśli ilość użytkowników jest przewidywalna (< 100), wówczas można pomyśleć
o r˛ecznym przeniesieniu skrzynek pocztowych, terminarzy, kontaktów oraz zadań do pliku PST
a nast˛epnie r˛eczny transfer do struktury katalogu po stronie serwera. W takim przypadku również
zakładanie skrzynek pocztowych i użytkowników wykonywane jest r˛ecznie.
W dużych środowiskach systemowych, z powodu kosztów oraz wydajności, r˛eczna migracja
nie ma sensu. W tego rodzaju środowiskach należy skorzystać z jednego z komercyjnych narz˛edzi migracyjnych. W zależności od producenta można z ich pomoca˛ przeprowadzić całkowicie
automatyczne przeniesienie wszystkich danych wraz z rekonfiguracja˛ klienta Outlook. Po stronie
serwera migracja może objać
˛ nast˛epujace
˛ informacje.
◦ użytkownicy (bez haseł)
◦ wpisy do kalendarza
◦ wpisy katalogowe
◦ Public Distribution Lists
◦ hierarchi˛e katalogów wraz z cała˛ ich zawartościa˛ (wiadomości e - mail, terminy, zadania,
kontakty)
◦ Bulletin Boards
◦ reguły oparte na serwerze
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łnowartościowym zast˛epnikiem Microsoft Exchange Server, zarówno
w przypadku dużych, jak i małych instalacji. Obsługuje on wszystkie funkcjonalności Groupware serwera Exchange. Wyjatek
˛
stanowia˛ aplikacje do tworzenia formularzy, jednak niektórzy producenci podj˛eli już odpowiednie prace w tym zakresie.
Podstawowa technologia istnieje na rynku już od ponad 15 lat. Dlatego produkt ten posiada
duża˛ ilość wdrożeń, do których można si˛e odwołać. Najnowsze przej˛ecie przez firm˛e Samsung
zapewnia dalszy rozwój produktu przez najbliższe lata.
3.14.4.6
Streszczenie
Obecnie istnieje kilka rozwiazań
˛
Groupware dla Linuksa, które oferuja˛ podobny zakres funkcji, jak ma to miejsce w przypadku Microsoft Exchange. Zasadniczo uwzgl˛edniajac
˛ istniejace
˛
rozwiazania
˛
można przyjać
˛ dwie róż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
262
konektorów
globalna
ksiaż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
Funkcjonalnoś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 rozwiazań
˛
Groupware wyraźnie wskazuje na to, że w chwili
obecnej istnieja˛ już adekwatne produkty linuksowe. Wybór właściwego rozwiazania
˛
Groupware
zależy od nast˛epujacych
˛
kryteriów:
◦ korzystanie z klientów Microsoft Outlook
◦ wykorzystanie w heterogenicznych środowiskach klienckich; jednoczesne stosowanie linuksowych systemów klienckich i klienta Outlook
263
◦ wykorzystanie rozwiazania
˛
opartego na WWW
◦ stosowanie Outlooka
Aby kontynuacyjnie stosować Outlook jako system kliencki, pierwszoplanowymi rozwiazaniami
˛
sa˛ zasadniczo produkty Kroupware, SuSE OpenExchange i Samsung Contact. Brakujace
˛ poła˛
czenie w czasie rzeczywistym SuSE OpenExchange z Outlookiem ogranicza jeszcze obecnie
funkcjonalność tego produktu i stanie si˛e dla wielu klientów interesujac
˛ a˛ alternatywa˛ dopiero
wówczas, gdy zaimplementowana zostanie w/w funkcjonalność. W tej chwili exchange4linux
oraz Samsung Contact oferuja˛ lepsza˛ obsług˛e Outlook. W przyszłości także Kroupware może
być interesujac
˛ a˛ alternatywa,
˛ zwłaszcza w środowiskach heterogenicznych (patrz niżej). Z powodu braku informacji o pracy w środowiskach produkcyjnych, nie można jeszcze w tym miejscu konkretnie wypowiadać si˛e o przydatności powyższego rozwiazania.
˛
Dla organizacji skupiajacych
˛
wieluset użytkowników serwer exchange4linux oferuje stabilna˛ platform˛e Groupware,
która sprawdziła si˛e już w praktyce. Samsung Contact, który znajduje si˛e na rynku już od dłuższego czasu i oferuje dobra˛ obsług˛e Outlooka, jest wiel oferujac
˛ a˛ alternatywa,
˛ zwłaszcza dla
dużych organizacji. Dobra skalowalność systemu pozwala na wykorzystanie go w organizacjach
skupiajacych
˛
wiele dziesiatek
˛ tysi˛ecy pracowników. Wraz z przej˛eciem HP OpenMail przez koncern Samsung wyjaśniło si˛e także pytanie53 dotyczace
˛ dalszego rozwoju oraz wsparcia technicznego.
Heterogeniczne środowiska klienckie
Organizacje, które wykorzystuja˛ po stronie klienta różne systemy operacyjne, maja˛ na przykład możliwość zastosowania Samsung Contact badź
˛ w przyszłości Kroupware. Samsung proponuje własnego klienta opartego na Java, który oferuje funkcjonalności Groupware niezależnie od
systemu operacyjnego. Dzi˛eki temu istnieje możliwość korzystania w systemach windowsowych
z Outlooka i / albo z klienta Java badź
˛ w systemach linuksowych tylko z klienta Java. W przyszłości także Kroupware b˛edzie potencjalnym rozwiazaniem
˛
dla systemów mieszanych. Dzi˛eki
możliwości jednoczesnego zastosowania Outlooka i klienta KDE użytkownicy moga˛ korzystać
z funkcjonalności Groupware, takż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 także Studium przydatności dla ministerstwa z roku 2001.
264
nExchange umożliwia dodatkowo także przyłaczenie
˛
klientów Outlook, jednak z ograniczeniem
zwiazanym
˛
z brakiem połaczenia
˛
w czasie rzeczywistym.
3.14.5.1
Exchange 2000
Nowości
W porównaniu z Exchange 5.5, najważ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 już własnej usługi
katalogowej i wymaga używania Active Directory. Ponadto Exchange 2000 nie można instalować w serwerach Windows NT, lecz tylko w serwerach Windows 2000.
W porównaniu z dotychczasowa˛ jednostka˛ struktury Exchange 5.5 - „punkt centralny“ miały miejsce nast˛epujace
˛ zmiany:
◦ replikacja katalogu wykonywana jest jedynie w Active Directory; wprowadzonych tam
punktów centralnych (Sites) nie należy mylić z punktami centralnymi z Exchange 5.5.
◦ Serwery Exchange tworza,˛ z technicznego punktu widzenia, „grupy administracyjne“
◦ ponadto serwery Exchange podzielone sa˛ na grupy routingu, które nie musza˛ pokrywać si˛e
z „grupami administracyjnymi“.
Ponieważ w serwerze Exchange 2000 nie ma już usługi katalogowej, wymaga on usługi, która
udost˛epnia globalnemu katalogowi (Global Catalog, GC) obszernych informacji ponad granicami domen. GC może być udost˛epniany tylko w kontrolerach domen z Windows 2000. Zawiera
on informacje o wszystkich obiektach ogólnej struktury Windows 2000 (forest), jednakże tylko
wybrane atrybuty. Aktualnie klienty (np. Outlook 2000 albo 98 SP2) moga˛ ściagać
˛
informacje
bezpośrednio z GC. Starsze wersje klientów obsługiwane sa˛ przez serwer Exchange 2000, który
jako serwer pośredniczacy
˛ przekazuje zapytanie dalej. W przeciwieństwie do tego, w Exchange
5.5 każ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˛ także wiadomości pocztowe, dzi˛eki czemu można uniknać
˛ redundancji. Jak wiadomo
w grupach AD o różnych okresach ważności (widoczności) znajduja˛ si˛e: domeny (globalna i
265
lokalna) oraz grupy uniwersalne (tylko w trybie Native domeny). Jedynie grupy uniwersalne
widoczne sa˛ poza granicami domen.
W Exchange 2000 projekt nie jest już determinowany przez model administracyjny środowiska Exchange, ponieważ serwer można zorganizować oddzielnie, wykorzystujac
˛ w tym celu
grupy administracyjne i grupy routingu. Podział ten możliwy jest jednak tylko wówczas, gdy w
trybie Native pracuje sam Exchange 2000, tzn. gdy nie sa˛ używane inne serwery 5.5.
Exchange 2000 oferuje administrowanie zgodne z modelem wytycznych. Model ten umożliwia administratorom zmienianie opcji grupy obiektów (np. skrzynek pocztowych uż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 używa RPC. SMTP jest już 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 już go nie ma)
◦ Microsoft Mail Connector
◦ CC:Mail Connector
◦ Lotus Notes Connector
◦ Novell Groupwise
Dla każdego serwera Exchange 2000 można utworzyć do czterech grup zapisu, z których każda
może posiadać do czterech baz danych. Ma to szczególne zalety, jeśli chodzi o zabezpieczanie i
odtwarzanie danych.
◦ Możliwe jest teraz indeksowanie bazy danych Exchange.
◦ Klastry Exchange moga˛ pracować w trybie „activ - activ“.
◦ Outlook Web Access (OWA) obsługuje teraz WebDAV (Web Distributed Authoring and
Versioning), kontynuacj˛e HTTP 1.1. Jeśli chodzi o OWA zaleta polega na tym, że serwery
Exchange można skonfigurować jako Frontend i BackEnd, dzi˛eki czemu same serwery
OWA nie przechowuja˛ danych.
Ponadto można teraz instalować
266
◦ usługi chat
oraz
◦ usługi Instant Messaging.
Dzi˛eki nowemu, oddzielnemu wariantowi produktu, tj. „Exchange 2000 Conferencing Server“,
można przeprowadzać konferencje audio i wideo.
Ś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 odnoś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 zbliżonych do
warunków produkcyjnych. Niniejszy poradnik nie możne w pełni zajać
˛ si˛e w/w zadaniami, jednak należy wskazać kilka ważnych aspektów migracji.
Zanim to nastapi,
˛ należy jeszcze wprowadzić kilka definicji poj˛eć. 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, że Exchange 2000 można stosować 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
niż struktura domen w Windows NT na Exchange 5.5. Ogólna struktura (forest) tworzy
granice organizacji Exchange, ponieważ jak wiadomo wychodzace
˛ poza granice domen
informacje Global Catalog (GC) 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.
267
◦ wprowadzenie Exchange 2000 wymaga rozszerzenia schematu Active Directory. Rozszerzenie to można przeprowadzić bez konieczności instalacji samego Exchange 2000 (poj˛ecie: forestprep). Ponadto dana˛ domen˛e należy przygotować (poj˛ecie: domainprep).
◦ model domen Windows 2000 (Native vs Mixed Mode) wpływa na dost˛epność uniwersalnych grup i tym samym widoczność rozdzielaczy e - mail.
◦ aktualizacja Exchange 2000 może mieć miejsce tylko wtedy, gdy wcześniej przeprowadzona została aktualizacja systemu operacyjnego. Exchange 2000 nie można zainstalować
w Windows NT 4. W przeciwieństwie do tego, Exchange 5.5 może pracować 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˛ być członkiem domeny Windows 2000, wzgl˛ednie członkiem Ogólnej struktury.
◦ Użytkownicy musza˛ logować si˛e do Active Directory, jeśli chca˛ badź
˛ maja˛ korzystać z
Exchange 2000.
W ramach niniejszego poradnika nie przedstawiliśmy złożonoś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 końcu wskazaliśmy narz˛edzia, które moga˛ ułatwić migracj˛e
badź
˛ współistnienie.
Active Directory Connector (ADC) umożliwia replikacj˛e hierarchii obiektów katalogowych
z katalogu Exchange Server 5.5 do Active Directory. W zwiazku
˛
z tym ADC odgrywa ważna˛ rol˛e
w przypadku migracji Exchange 5.5 do Exchange 2000. Należy zwrócić uwag˛e na to, że istnieja˛
dwie wersje ADCs (CD z Windows 2000 oraz CD z Exchange 2000). Jeśli chodzi o migracj˛e do
Exchange 2000, ważna jest druga z w/w wersji.
Domyślna replikacja (SRS) umoż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.
268
Ilość nowości w porównaniu z Exchange 2000 jest stosunkowo mała. Powodem ukazania
si˛e Exchange 2003 było to, że wskutek zmian wprowadzonych w Windows 2003 w porównaniu z Windows 2000, nie można było instalować Exchange 2000 na platformie Windows 2003.
Oznacza to, że w Windows 2003 można instalować tylko Exchange 2003 54.
Poniższa matryca kompatybilności stanowi przeglad
˛ różnych obsługiwanych kombinacji Exchange
5.5, Exchange 2000, Exchange Server 2003 oraz Windows Server 2003.
I NSTALACJA
wersja
Exchange
PRACA
O BSŁUGIWANE
ŚRODOWISKA
E XCHANGE
W
ACTIVE
D IRECTORY
Windows
Windows
Windows 2000
Windows
2000 SP3
albo
Server
2003
SP3
albo
Server 2003
I
w wyższej
w wyż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 kompatybilności Exchange55
Nast˛epujacy
˛ rysunek przedstawia możliwości środowisk mieszanych.
54
Deutsches Whitepaper „Microsoft Exchange Server - kompatybilność z Windows Server 2003“
269
56
Rysunek 3.29: Mieszane środowiska Exchange
Do nowości w Exchange 2003 należa:
˛
◦ Outlook Mobile Access (obecnie Microsoft Mobile Information Server 2002) jest cz˛eścia˛
Exchange Server 2003. Outlook Mobile Access oferuje użytkownikom urzadzeń
˛
przenośnych dost˛ep do ich informacji osobistych.
◦ Exchange Server 2003 umożliwia serwerowi Internet Information Server (ISS wersja 6
z Windows 2003) nowa˛ form˛e komunikacji pomi˛edzy Outlookiem i Exchange, określana˛
jako „RPC poprzez HTTP“. W ten sposób użytkownik Outlook może bezpośrednio i bezpiecznie synchronizować swoje dane z Exchange Server 2003 poprzez połaczenie
˛
HTTP.
◦ Obsługa klastrów w Windows 2000 Advanced Server jest ograniczona do dwóch w˛ezłów
lub do czterech w˛ezłów, gdy wykorzystywany jest Windows 2000 Server DataCenter Edition. Za pomoca˛ Windows 2003 i Exchange 2003 można teraz realizować, do wyboru,
56
Źródło: Deutsches Whitepaper „Microsoft Exchange Server - kompatybilność z Windows Server 2003“
270
klastry oparte na maksymalnie oś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 używa usługi kopiowania cienia wolumenu
i umożliwia w ten sposób uzyskiwanie krótszych czasów zabezpieczania i odtwarzania
danych w środowiskach Exchange.
3.15 Office / Desktop
3.15.1 Przeglad
˛
Jeśli chodzi o zastapienie
˛
MS Office 97 albo Office 2000, jak najbardziej celowe jest odczekanie do chwili, aż udost˛epniony zostanie MS Office 2003 i pojawia˛ si˛e pierwsze doświadczenia z
MS Office 2003, zwłaszcza że zgodnie z zapowiedziami MS Office 2003 ukaże si˛e latem 2003 r.
Oprócz aspektów wyłacznie
˛
zwiazanych
˛
z kosztami, chodzi tu przede wszystkim także o aspekty
techniczne wynikajace
˛ ze zmian formatu dokumentu. Wraz z MS Office 2003 Microsoft planuje
wypromować XML, jako główny format dokumentów biurowych. Nie można przy tym wykluczyć, że istniejace
˛ dzisiaj problemy z kompatybilnościa˛ wzgl˛edem alternatywnego rozwiazania
˛
OSS OpenOffice.org badź
˛ jego komercjalnego odpowiednika StarOffice, zmniejsza˛ si˛e lub ewentualnie w ogóle przestana˛ istnieć. Jeśli kontrola kompatybilności wymiany dokumentów MS Office 20003 i OpenOffice 1.1, wzgl˛ednie StarOffice 6.1 wypadnie pozytywnie, wówczas należy
zbadać kroki i nakłady zwiazane
˛
z przeniesieniem starych dokumentów Office do MS Office
2003. W nast˛epnym kroku należy skonfrontować je z krokami i nakładami, jakie powszechnie
znane sa˛ dzisiaj w przypadku przenoszenia w/w dokumentów do OOo / SO.
Dopiero potem należy podjać
˛ decyzj˛e o wyborze MS Office 2003 albo pakietu OOo / SO.
Zastapienie
˛
desktopu Microsoft zależy ostatecznie w dużej mierze od tego, czy można z
jednej strony zastapić
˛ 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 można je w
tzw. mi˛edzyczasie udost˛epniać jako aplikacje windowsowe. Wymaga to jednak indywidualnego
sprawdzenia.
271
3.15.2 Wprowadzenie
Desktop jest dla uż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 użytkownicy moga˛ korzystać także z różnych
innych standardowych narz˛edzi, z funkcjonalności których nie można zrezygnować po migracji.
Koniec koń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˛ pracować w Linuksie. Z tego powodu nast˛epujac
˛ a˛
ocen˛e techniczna˛ podzieliliśmy na pi˛eć cz˛eści:
◦ punkt wyjścia MS Office
˛ MS Office
◦ migracja kontynuacyjna MS Office
◦ inne aplikacje desktopowe
◦ aplikacje windowsowe w Linuksie.
3.15.3 Punkt wyjścia - MS Office
MS Office udost˛epniany jest w postaci różnych pakietów i wersji. W odróżnieniu od systemu
operacyjnego nie należy tu zakładać, że w wi˛ekszości urz˛edów wykorzystuje si˛e określona˛ wersj˛e MS Office. Jednakże można wyjść z założenia, że wersj˛e poprzedzajac
˛ a˛ Microsoft Office
97 wykorzystuje si˛e już bardzo rzadko, a Microsoft Office XP nadal jeszcze niezbyt cz˛esto. W
przeważajacej
˛ cz˛eści urz˛edów zainstalowany jest Microsoft Office 97 albo 2000. Dlatego b˛eda˛
one punktem wyjścia dla poniższej oceny migracji. Nowości Microsoft Office XP w porównaniu
z Office 2000 dotycza˛ w pierwszym rz˛edzie interfejsu użytkownika oraz pracy grupowej, przy
czym cz˛eść dodatkowych funkcji w obszarze pracy grupowej pokrywa funkcjonalności Groupware, które zostały zastapione
˛
innymi aplikacjami. Microsoft zacieśnia w ten sposób obszary
Office i SharePoint Services57. Dla codziennej pracy skutkuje to jedynie nieznacznymi zmianami. Dlatego o nowych funkcjonalnościach Office XP wspominamy tylko w wybranych kontekstach.
57
Szczegóły odnośnie nowych Features w porównaniu z wcześniejszymi wersjami znajda˛ Państwo na stronie:
http://www.microsoft.com/germany/ms/officexp/prof/vergleich.htm
272
Oprócz wersji ważna˛ rol˛e w ocenie migracji odgrywaja˛ różne pakiety Office. Pakiety te różnia˛ si˛e od siebie z reguły zawartymi w nich pojedynczymi aplikacjami. Pojedyncze aplikacje
◦ Word
◦ Excel
oraz
◦ PowerPoint
zostały ocenione poniżej, odpowiednio do sposobu migracji
˛ MS Office
oraz
◦ migracja kontynuacyjna MS Office,
w oparciu o pakiet Office 2000 Professional. Outlook oceniony został w rozdziale 3.11 jako cz˛eść
składowa systemów Groupware i Messaging. Access przeanalizowana i oceniona została wraz z
migracja˛ baz danych. Internet Explorer i PhotoEditor omówimy w podrozdziale „Inne aplikacje
desktopowe“ razem z innymi narz˛edziami desktopowymi. W tym samym podrozdziale autorzy
wspominaja˛ także pokrótce o MS Project.
3.15.3.1
Funkcjonalności
Z zamieszczenia listy funkcjonalności programów Word, Excel oraz Power Point musieliśmy w
tym miejscu zrezygnować. Zamiast tego w dwóch kolejnych rozdziałach wyszczególnione zostały najważniejsze różnice pomi˛edzy punktem wyjścia a możliwymi przyszłymi alternatywnymi
rozwiazaniami
˛
migracyjnymi.
Na poczatku
˛ należy stwierdzić, że intensywne stosowanie specjalistycznego oprogramowania w urz˛edach jest po cz˛eści rozszerzeniem funkcjonalności MS Office. Z jednej strony oznacza to, że środowisko programistyczne dost˛epne wraz z MS Office wykorzystuje si˛e w wielu
urz˛edach i innych organizacjach do tworzenia rozwiazań
˛
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 rozwiazań,
˛
w przypadku których ma miejsce bardziej lub
mniej silna integracja z Office. Dlatego poniżej opisaliśmy pokrótce środowisko programistyczne
MS Office.
3.15.3.2
273
Środowisko programistyczne MS Office
Środowisko programistyczne Microsoft Office opiera si˛e na j˛ezyku programowania BASIC. W
ś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óżni je zakres funkcji
i środowisko pracy.
Środowisko programistyczne MS Office zawiera Visual Basic for Application (VBA). Microsoft udost˛epnia licencj˛e VBA, dlatego inni producenci moga˛ właczać
˛
VBA do swoich produktów.
Za punkt wyjścia w niniejszym poradniku przyj˛eliśmy korzystanie z pakietu Office 97. We
wcześniejszych wersjach udost˛epniane były różne środowiska programistyczne dla poszczególnych produktów (Word Basic, Excel VBA, Access Basic). Wraz z Office 97 ujednolicono środowisko programistyczne do VBA w wersji 5. Poniższa tabela pokazuje powiazanie
˛
wersji VBA z
róż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łożenia VBA
VBA jest j˛ezykiem interpretowanym, który można wykonywać tyko w aplikacjach Office.
VBA opiera si˛e o COM (Component Object Model), kontynuacj˛e technologii OLE (Object Linuking and Embedding).
274
Office umie nie tylko korzystać z obiektów COM, lecz sam także oferuje obiekty COM. Office 97 dostarcza ponad 550 własnych obiektów COM, Office 2000 ponad 600. Poprzez COM, w
pakiecie Office można używać także zewn˛etrzne funkcjonalności. Za pomoca˛ VBA możliwe jest
korzystanie z zewn˛etrznych programów (np. systemu operacyjnego) w formie DLLs (Dynamic
Link Libraries)58.
Nast˛epujacy
˛ rysunek raz jeszcze przedstawia zdolność VBA do korzystania z funkcjonalnoś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 można tworzyć własne
obiekty, jak też ich właściwości i metody. Elementy te umożliwiaja˛ rozszerzanie funkcjonalności
dostarczanych przez MS Office, automatyzacj˛e kolejności wywołań funkcji oraz implementowanie dodatkowych funkcjonalności. Rozszerzenia, uzupełnienia i kod automatyzujacy
˛ nazywane
sa˛ makrami albo skryptami. Aby zintegrować makra z MS Office można modyfikować paski
menu i przyciski na paskach zadań, dzi˛eki czemu użytkownik jest w stanie łatwiej je uruchamiać.
58
W Visual Basic Script (VBS) takie połaczenie
˛
nie jest możliwe.
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˛ zagrożenie tak zwanymi „makrowirusami“.
Podsumowujac,
˛ makra i skrypty moga˛ być wywoływane w Office badź
˛ integrowane z nim w
nast˛epujacych
˛
formach:
◦ jako Add - In
◦ wewnatrz
˛ szablonów (Templates)
◦ jako asystenci (Wizards).
Add Ins można jeszcze podzielić 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 można tworzyć za pomoca˛
Visual Basic (pełna wersja). Add - Ins można stosować poza granicami aplikacji.
Aplikacyjne Add - Ins tworzy si˛e za pomoca˛ zintegrowanego środowiska programistycznego
Office i można ich używać tylko wewnatrz
˛ Office. Z Add - Ins należy korzystać z reguły tam,
gdzie kod programu ma być stale dost˛epny w aplikacji, tak aby użytkownik nie musiał uruchamiać szablonów.
Nast˛epujacy
˛ rysunek raz jeszcze prezentuje możliwe rozszerzenia w MS Office uzyskiwane
za pomoca˛ własnych programów.
Rysunek 3.31: Możliwe rozszerzenia w Office
276
Środowisko programowania
Za pomoca˛ VBA w wersji 5 z aplikacjami Office zintegrowane zostało jednolite ś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łaściwoś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 można także, wewnatrz
˛
aplikacji, używać Makro - Rekorder.
Zdalne sterowanie
Ponieważ sam Office składa si˛e z wielu obiektów COM, możliwe jest zdalne sterowanie Office, czyli wprowadzenie automatyzacji COM.
Do zdalnego sterowania można wykorzystywać, np. Windows Scripting Host (WSH) albo
PerlScript
˛
3.15.4.1
Wprowadzenie
Istnieja˛ najróżniejsze pakiety oprogramowania biurowego, wzgl˛ednie aplikacje (np. edytory tekstu), które sa˛ dost˛epne dla systemu operacyjnego Linux jako wolne albo własnościowe oprogramowanie. Sa˛ to mi˛edzy innymi:
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) badź
˛ 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 można także stosować w systemach operacyjnych Windows NT, 2000 i XP.
Ponieważ OOo / SO korzystaja˛ we wszystkich systemach operacyjnych z tych samych funkcjonalnoś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˛ już w wersji beta,
a ich ostateczna wersji ma być udost˛epniona w lipcu 2003 r.
Róż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 ź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 badź
˛ Lesser GNU Public License oraz Sun Industrie
Source License). Podwójne licencjonowanie umożliwia z jednej strony tworzenie w oparciu o
OpenOffice.org produktów komercyjnych, a z drugiej strony gwarantuje jednolitość specyfikacji
API i formatu plików, które sa˛ wiaż
˛ ace
˛ dla OpenOffice.org i wszystkich programów pochodnych.
Dla StarOffice firma Sun stworzyła badź
˛ dołaczyła
˛
dodatkowe składniki oraz opakowanie
b˛edace
˛ profesjonalna˛ gwarancja˛ jakości, obszerna˛ dokumentacj˛e, wsparcie techniczne i oferty
szkoleń. Niektórymi z w/w składników firmy Sun sa:
˛
◦ TrueType Fonts, które sa˛ zbliżone do czcionek Microsoftu (patrz rys. 3.32)
◦ własne sprawdzanie pisowni i thesaurus, OpenOffice korzysta najcz˛eściej z MySpell (LGPL)
◦ dodatkowe szablony i galeri˛e obrazów
278
◦ baz˛e danych ADABAS.
Ponadto Sun dostarcza łaty naprawiajace
˛ bł˛edy albo poprawiajace
˛ bezpieczeństwo danej wersji
produktu. Dzi˛eki temu obecnie co trzy miesiace
˛ pojawia si˛e dla StarOffice nowy zestaw łat, który
poprawia bezpieczeństwo, bł˛edy w programach albo filtry importu. W przeciwieństwie do tego
OpenOffice.org zawiera niniejsze składniki każdorazowo tylko w najnowszych wersjach 59.
60
Rysunek 3.32: Fontmapping MS Office OOo / SO
W przeciwień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 uzyskać można, m.in. bezpośrednio od
firmy Sun a w przypadku OpenOffice.org tylko od innych producentów.
Cz˛eści składowe OOo, wzgl˛ednie SO
OOo i SO składaja˛ si˛e, tak jak MS Office, z różnych aplikacji. Należa˛ do nich:
◦ edytor tekstu (Writer)
◦ arkusz kalkulacyjny (Calc)
◦ edytor prezentacji (Impress)
59
Dalsze szczegóły nt. różnic znaleźć można na stronie http://marketing.openoffice.org/
conference/presentationspdf/thu1500/SOvsOOo.pdf
60
Źródło: http://SunMicrosystems.com
279
◦ edytor formuł matematycznych61 (Math)
◦ edytor grafiki62 (Draw)
◦ baza danych63 (Adabas)64.
W centrum poniższych rozważań znalazły si˛e jednak tylko trzy pierwsze moduły.
Jeśli chodzi o istotne funkcjonalności, trzy w/w Office Suites sa˛ takie same, zwłaszcza w
przypadku funkcjonalności wykorzystywanych przez wi˛ekszość użytkowników. Wi˛ekszość użytkowników z reguły używa takiego samego, waskiego
˛
zestawu funkcji z całego dost˛epnego zakresu. W nast˛epujacych
˛
rozdziałach dokładnie prezentowane sa˛ najważniejsze róż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. Możliwości zastapienia
˛
modułu MS Access
przez inny system bazodanowy omówiliśmy bliżej w rozdziale 3.13. Inne moduły MS Office
Suite i aplikacje desktopu Microsoft opisaliśmy w rozdziale 3.15.6.
3.15.4.2
Różnice w formacie plików w porównaniu z MS Office
Każ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 przeciwieństwie do tego OpenOffice.org badź
˛ StarOffice 6.0 (OOo / SO) używa formatu
pliku opartego na XML, który zapisuje treść w postaci tekstu, co oznacza, że można go czytać i zmieniać bez konieczności wykorzystywania OOo / SO do dekodowania i odczytu. Dokumentacja w/w formatu jest publicznie udokumentowana i ogólnie dost˛epna jako cz˛eść projektu
OpenOffice.org.
Format plików OOo / SO oparty na XML zapisuje treść, layout i informacje odnośnie formatowania każdego dokumentu w postaci kompletu XML - Streams albo poddokumentów.
Aby użytkownik mógł w łatwy sposób korzystać z róż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. Jednakże nazwy plików tworzonych
przez OOo / SO nie otrzymuja˛ rozszerzenia „.zip“, lecz tak jak w MS Office róż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 można wywołać 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 bezpośrednio porównać z Access z Windows.
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 najważniejszych aplikacji Office
Ponadto w OOo / SO istnieja˛ jeszcze aplikacje Draw i Math, które w MS Office sa˛ cz˛eścia˛
trzech w/w aplikacji podstawowych i których nie można oddzielnie bezpośrednio przyporzad˛
kować. Za pomoca˛ Draw można tworzyć rysunki (sxd / std), za pomoca˛ Math formuły matematyczne (sxm / stm). Obiekty Draw i Math można także właczać
˛
do innych dokumentów OOo /
SO i tam je edytować.
Ponieważ dokumenty OOo / SO sa˛ właściwie plikami ZIP, można je rozpakowywać dowolnym programem UNZIP.
Rysunek 3.33: Zawartość pliku OOo / SO wyświetlana w przegladarce
˛
plików ZIP.
O ile wbudowana została grafika lub obiekty, sa˛ one składowane w katalogu „Pictures“ badź
˛
„Objects“. Znajduje si˛e tu odnoś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:
281
◦ content.xml
Zapisuje główna˛ treść 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 badź
˛ Objects i znajduje si˛e tu odnośnik (href - link) do odpowiednich podporzad˛
kowanych plików.
◦ styles.xml
Zapisuje właściwoś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,˛ użytkownikiem, czasem ostatniej aktualizacji i inne. Treść tego pliku odnosi si˛e do informacji,
które podaje si˛e poprzez mask˛e Plik / Właściwości.
◦ settings.xml
Zapisuje dla danego dokumentu ustawienia dokumentu i widoku specyficzne dla aplikacji
oraz zadane właściwości drukarki i opcje drukowania, poziom powi˛ekszenia oraz wielkość
okna.
◦ manifest.xml
Zapisuje dodatkowe informacje o plikach XML, takie jak rodzaj MIME i metoda szyfrowania. Podobnie, jak w przypadku plików bitmapowych i plików obiektów, także ten plik
zapisywany jest w swoim własnym katalogu.
Jeśli dokument zawiera również makra, wówczas w pakiecie znajda˛ si˛e kolejne XML - Streams65 .
3.15.4.3
Ograniczenia filtrów konwertujacych
˛
(filtrów importu)
Aby umożliwić konwertowanie formatów plików, z OOo / SO zintegrowano różne konwertery
(filtry), które pozwalaja˛ otwierać i edytować dokumenty MS Office w OOo / SO, a nast˛epnie zapisywać je ponownie jako dokumenty MS Office. Ponadto możliwy jest także import szablonów
dokumentów MS oraz ich edycja. Pliki można zapisywać badź
˛ to w formacie MS Office 97 /
2000 / XP badź
˛ w formacie OOo / SO.
65
Dalsze informacje o formacie XML z OOo / SO znaleźć moż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).
282
Ogólnie mówiac
˛ jakość 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łaściwoś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 umożliwiajacych
˛
uzyskanie formatu dokumentu wyjściowego. 100% - owego konwertowania nie można oczekiwać zwłaszcza w przypadku skomplikowanych i specyficznych właściwości dokumentu, takich jak indeksy, fields, ramki i tabele.
Ponadto w niektórych przypadkach, podczas konwersji podstawowych atrybutów i formatowań,
takich jak kraw˛edzie stron albo odst˛epy pomi˛edzy akapitami, moga˛ pojawić si˛e różnice pomi˛edzy oryginałem a konwertowanym dokumentem.
W nast˛epujacej
˛ tabeli pokazane zostały właściwości MS Office, które wymagaja˛ r˛ecznego
poprawienia automatycznej konwersji.
A PLIKACJA
W ŁA ŚCIWO Ś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
283
◦ AutoShapes
◦ Obiekty OLE
◦ Kilka pól kontrolnych i pól formularzy
Microsoft Excel
◦ Tabele Pivot
◦ Nowe typy Chart
◦ Formatowania w zależności od treś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łaściwości MS Office mogace
˛ sprawić problemy podczas konwersji do OOo /
SO
3.15.4.4
Różnice w działaniu
Jeśli chodzi o zasad˛e działania, nie ma zasadniczych róż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 najniższym poziomie znajduje si˛e warstwa aplikacji,
która dostarcza narzadzi
˛ oraz właściwości potrzebnych do tworzenia dokumentów i szablonów.
Na kolejnym poziomie znajduja˛ si˛e szablony, które moga˛ zawierać wiele makr, formatowań i
284
ustawień pomocnych przy tworzeniu nowych dokumentów, które z kolei na najwyższym poziomie również moga˛ zawierać kolejne obiekty, makra, formatowania i ustawienia użytkownika
rozszerzajace
˛ funkcjonalność szablonów.
Tym, czym różnia˛ si˛e obydwa Office Suites sa˛ właściwości i funkcje udost˛epniane przez w/w
pakiety biurowe. W wielu przypadkach różnice te można przypisać projektowi i różnym modelom obiektów, w oparciu o które powstaja˛ niniejsze aplikacje. W przeważajacej
˛ cz˛eści w obydwu
pakietach istnieja˛ odpowiedniki poszczególnych właściwoś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
domyślny
normal.
szablon
dot
hardcoded
bOOok.xlt
hardcoded
blank.pot
hardcoded
szablony
szablony
treści /
treści /
projektu
projektu
sheet.xlt
dokumentu
szablon
dokumentów
szablony
różne
różne
N/a
strona
formatu
akapit
akapit
lista
numerowanie
67
znaków
różne
róż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 przeciwieństwie do tego, Impress definiuje wyś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
285
W poniższej tabeli (tab. 3.67) zgromadzone zostały różnice pomi˛edzy kluczowymi funkcjami. Różnice w działaniu oraz pozostałe różnice zostały obszernie opisane w „StarOffice 6.0
Migration Guide“70.
W ŁA ŚCIWO Ś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óżnic w obydwu modelach obiektu nie obsługuje makr VBA. Wszystkie makra VBA przeznaczone do dal-
makra oparte na dokumentach
szego użytku należy przekształcić (r˛ecznie).
Dokumenty OOo / SO moga˛ jednak zawierać 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
powstawać niewielkie róż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óżne modele tabel, co może doprowadzić do niewielkich różnic podczas ich wyś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
Wyświetlanie ramek może różnić si˛e po konwersji, ponieważ
OOo / SO nie obsługuje wszystkich typów linii z MS Word.
formaty znaków
(MS Word)
70
W Word można ustawiać różny format dla znaków z listy i dla
treś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
286
Z reguły odst˛epy mi˛edzy znakami w Word sa˛ mniejsze niż odmetryka znaków
i odst˛epów
(MS Word)
st˛epy mi˛edzy znakami w edytorze Writer. Obydwie aplikacje korzystaja˛ także z różnych jednostek miary przy ustalaniu pionowych odst˛epów (Word = punkty, OOo / SO = cale). Przez to ilość
wierszy w w/w aplikacjach może być różna w przypadku tego samego dokumentu.
Pojedynczy arkusz w Calc może zawierać maksymalnie 32.000
rozmiar arkusza
wierszy. W przeciwień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łużace
˛ do złoż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˛ funkcjonalnoś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 przeciwień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
wpisać obowiazuj
˛ ac
˛ a˛ wartość domyślna.˛
PowerPoint 2002 wykorzystuje funkcjonalność Timeline, która
Timeline
(MS PowerPoint
2002)
umożliwia animacj˛e obiektów w ściśle określonym czasie. W
OOo / SO nie istnieje porównywalny Feature.
Ponadto w PowerPoint XP można definiować różne interwały
czasu dla różnych obiektów. W aktualnej wersji Impress można
ustalić ustalić interwał czasu jedynie dla wszystkich obiektów.
71
Szczegóły znaleźć można w „StarOffice 6.0 Migration Guide“, strona 56 - 69.
287
Zarówno Writer, jak i Word obsługuja˛ stosowanie tak zwanych
„Merge Documents“, chodzi tu o łaczenie,
˛
np. arkuszy kalkulacyjnych Excel z dokumentem Word. Funkcjonalność ta jest nieco
Merge Documents
(MS Word)
inaczej zaimplementowana w edytorze Word niż w edytorze Writer, a dost˛epne filtry nie obsługuja˛ tej funkcjonalności. Wprawdzie odpowiednie dokumenty sa˛ importowane razem z połaczo˛
nymi polami, jednak połaczenie
˛
z plikiem danych trzeba zestawiać r˛ecznie.
Makr utworzonych w MS Office nie można wykonywać w OOo /
SO. W OOo / SO makra te trzeba, o ile po konwersji maja˛ być one
nadal stosowane, ponownie r˛ecznie utworzyć albo dostosować do
StarBasic.
W OOo / SO do tworzenia makr udost˛epniane jest odpowiednie
Makra VBA
środowisko programowania, które można wywołać poprzez Dodatki / Makra i przyciskiem „Edycja“.
Zasadniczo jednak w środowisku mieszanym (MS Office – OOo
/ SO) można korzystajac
˛ z OOo / SO otwierać, czytać, edytować
i zapisywać dokumenty MS Office, bez gubienia albo niszczenia
istniejacych
˛
makr VBA.
Tablica 3.67: Różnice w kluczowych funkcjonalnościach
3.15.4.5
Ważne kryteria analizy stanu
Zanim podj˛eta zostanie zasadnicza decyzja za lub przeciw migracji, po której b˛edzie mogło
nastapić
˛ szczegółowe planowanie, w ramach analizy stanu należy sprawdzić:
◦ co powinno podlegać migracji
◦ czy migracja jest możliwa
oraz
◦ jakie nakłady sa˛ z tym zwiazane.
˛
288
Podczas analizy stanu należy zbadać, wzgl˛ednie usystematyzować dokumenty według nast˛epujacych
˛
kryteriów:
◦ dost˛epność dokumentów
– dokumenty, które ewentualnie trzeba nadal edytować
Konwersja tych dokumentów może mieć sens.
– Dokumenty, które maja˛ być jeszcze co najwyżej czytane
Dokumenty te, przynajmniej w przypadku migracji, należy zarchiwizować badź
˛ przekonwertować do formatu PDF albo można rozważyć obydwie te możliwość. Dzi˛eki
temu zmniejsza˛ sia˛ nakłady.
◦ stopień skomplikowania dokumentów
– proste dokumenty
Nie zawieraja˛ one makr, własnościowej grafiki (jak, np. WordArt), grafiki wektorowej, skomplikowanych formatować czy elementów, takich jak przypisy, tabele albo
indeksy. Najlepiej jest przekształcać je za pomoca˛ konwersji Batch (patrz paragraf
„Sposoby konwersji“ w podrozdziale 3.15.4.7).
– skomplikowane dokumenty
zawieraja˛ one makra, wspólne składniki, formatowania akapitów i stron, własnościowa˛ oraz wektorowa˛ grafik˛e, wiele dowiazań
˛ symbolicznych i odnoś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óżnych formatowań i elementów.
Dokumenty te wymagaja˛ z reguły dodatkowego planowania i należy oceniać oraz
przenosić pojedynczo.
◦ stopień skomplikowania szablonów
– proste szablony
Proste szablony składaja˛ si˛e z generic text i odpowiedniego formatowania, które służy
jako punkt wyjś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.
289
– skomplikowane szablony
Skomplikowane szablony zawieraja˛ Form Fields i makra, które nie zawsze dadza˛ si˛e
przenieść i które trzeba od nowa utworzyć za pomoca˛ środowiska programowania
udost˛epnianego przez OOo / SO albo poddać procesowi Reengineering.
Korzystanie z zewn˛etrznych źródeł danych
Na ogół trzeba je przyłaczać
˛
od nowa. Można to zrobić bez problemu. Do wspomnianych źródeł
danych zaliczaja˛ si˛e m.in. bazy danych i dokumenty Excel.
Integracja
zewn˛etrznego oprogramowania
W tym przypadku z jednej strony należy zbadać zakres integracji i ilość aplikacji, które maja˛
wziać
˛ w niej udział, a z drugiej strony należy sprawdzić dost˛epność tekstu źródłowego pod ka˛
tem integracji z OOo / SO. Jeśli oprogramowanie zewn˛etrzne komunikuje si˛e z MS Office dzi˛eki
automatyzacji interfejsu OLE / COM, wówczas zamiast MS Office można do wspomnianego
interfejsu podłaczyć
˛
OOo / SO. Wywoływane funkcje MS Office należy przenieść do odpowiednich wywołań OOo / SO.
3.15.4.6
Przygotowanie do konwersji
Jeśli chodzi o layout, powstawanie wielu różnic widocznych po konwersji, spowodowane jest
posługiwaniem si˛e „niefachowa“
˛ technika˛ formatowania. Aby wierniej odtwarzać layout dokumentu należy, wzgl˛ednie należało zapewnić „prawidłowe“ formatowanie pierwotnego tekstu.
Podczas codziennej pracy należy stosować si˛e do nast˛epujacych
˛
wskazówek, także wtedy, jeśli
w chwili obecnej migracja si˛e nie odbywa:
◦ zamiast bezpośredniego formatowania należy korzystać z szablonów formatów znaków i
akapitów.
◦ należy usuwać 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 treści (puste wpisy list).
◦ kolumn tabel nie należy tworzyć za pomoca˛ wielokrotnych tabulatorów. Należy zdefiniować Tab - Stops w taki sposób, żeby tylko jeden tabulator oddzielał tekst pomi˛edzy dwiema
kolumnami. Alternatywnie przy tworzeniu tabel można korzystać z Tool. W przypadku
korzystania z wielokrotnych tabulatorów może si˛e zdarzyć, że tabela po konwersji b˛edzie
„out of range“, gdyż domyślne tabulatory obydwu aplikacji sa˛ różne.
290
◦ należy sprawdzić, 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
Wielkość i stopień skomplikowania Spreadsheets wymagaja˛ dokładnego sprawdzenia, jeśli
chodzi o ewentualne wykorzystywanie szczególnych technik formatowania i wewn˛etrznej warstwy logicznej (formuły, Add - Ins), co ma zagwarantować ich prawidłowe przeniesienie. Dotyczy to w szczególności Add Ins, takich jak 3rd - Party i Standard Excel.
Poniżej pokrótce opisaliśmy i objaśniliśmy niektóre z danych obszarów:
◦ Należy sprawdzić ustawienia źródeł danych dla Charts. Zasadniczo Excel jest znacznie
bardziej elastyczny niż Calc, jeśli chodzi o obszar danych Charts. OOo / SO wymaga, np.
żeby etykiety zawsze przyporzadkowane
˛
były do pierwszego wiersza albo kolumny. Jeśli
tak nie jest, wówczas Charts importowane sa˛ z reguły bez etykiet.
◦ Sprawdzić czy dokumenty sa˛ chronione hasłem. Calc nie umie otwierać Spreadsheets
Excel chronionych hasłem. Dlatego przed konwersja˛ należy usunać
˛ hasło.
◦ Należy unikać stałych Array w formułach. Calc nie obsługuje w formułach stałych Array
w taki sam sposób, jak Excel (np. {1,2;3,4}), lecz tylko zakresy komórek określajace
˛ Array
(np. {A1:B2}).
◦ Należy unikać znaków specjalnych w nazwach arkuszy. Excel obsługuje wi˛ecej znaków
specjalnych w nazwach arkuszy niż Calc.
◦ Należy unikać arkuszy zawierajacych
˛
ponad 32.000 zapisanych wierszy i Spreadsheets
z ponad 256 arkuszami kalkulacyjnymi, ponieważ Calc obecnie nie obsługuje wi˛ekszej
ilości wpisów (patrz także 3.15.4.3).
◦ Należy unikać różnych ustawień Widok dla różnych arkuszy kalkulacyjnych obsługiwanych przez Excel. W Calc takie ustawienia można zadawać tylko globalnie dla całego
dokumentu.
◦ Należy sprawdzić wielkość komórek pod katem
˛
tekstu wyrównanego do prawej. Jeśli komórka b˛edzie zbyt mała, wówczas tekst nie zostanie przedłużony w lewo poza komórk˛e.
291
Dokumenty PowerPoint
Proste prezentacje PowerPoint zazwyczaj można bez problemu przenosić za pomoca˛ programu Impress. Prezentacje, które korzystaja˛ z rozszerzonych funkcji layout i rozszerzonych
efektów, prowadza˛ na ogół do różnej prezentacji w skonwertowanym dokumencie.
Kroki wyszczególnione poniżej powinny pomóc w zachowaniu pierwotnego formatu:
◦ należy unikać, usunać
˛ albo zmienić 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.
◦ należy unikać, usunać
˛ albo zmienić 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 należy uzyskać:
– podwójne nakładanie si˛e kolorów
– kraw˛edzie złożone z prostych linii.
Zaokraglone
˛
kraw˛edzie b˛eda˛ automatycznie przekształcane w kraw˛edzie prostokatne.
˛
◦ brakujace
˛ informacje we właściwościach dokumentów.
W Impress, w przeciwieństwie do PowerPoint, nie jest zapisywana data ostatniego dost˛epu. Ponadto właściwości dokumentu PowerPoint nie sa˛ wraz z nim importowane do
skonwertowanego dokumentu. Obydwa te braki można w razie potrzeby obejść badź
˛ wyrównać za pomoca˛ makr.
◦ przypadkowy wybór wielokrotnych efektów przejścia.
Impress nie obsługuje przypadkowego wyboru, podczas gdy stosowane sa˛ wielokrotne
efekty przejścia. Ważne jest, aby przed konwersja˛ zmienić je w proste efekty. W przeciwnym razie w wyniku kompresji zostana˛ one automatycznie przekształcone w efekty
pionowych linii. Ponadto należy nadmienić, że w Impress niektóre nazwy efektów przejścia moga˛ być inne oraz że program ten w przypadku niektórych efektów może si˛e nieco
inaczej zachowywać niż PowerPoint.
292
◦ brakujaca
˛ obsługa „rysowania opowiadania“.
Impress w przeciwieństwie do PowerPoint nie obsługuje „rysowania opowiadania“. W Impress do każdego slajdu można dołaczać
˛
własny plik dźwi˛ekowy. Aby móc nadal korzystać
z rysunków stworzonych w PowerPoint, trzeba je ponownie narysować, albo skonwertować metoda˛ Splitting72.
73
Rysunek 3.34: Obiekty - cienie w PowerPoint i Impress
3.15.4.7
Konwertowanie
Sposoby konwersji
Dokumenty MS Office można konwertować do OOo / SO wykorzystujac
˛ konwersj˛e pojedyncza˛ albo konwersj˛e Batch:
◦ konwersja pojedyncza
Dokument MS należy otworzyć w OOo / SO i zapisać jako dokument OOo / SO.
◦ konwersja Batch
Dane dokumenty należy skopiować do odpowiedniego katalogu (należ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
Źródło: „StarOffice 6.0 Migration Guide"http://uk.sun.com/software/staroffice/pdf/
somigrationguide.pdf
293
tym celu utworzyć). Nast˛epnie korzystajac
˛ z funkcji „Plik / Autopilot / Konwerter dokumentów“ można zainicjalizować proces Batch. Najpierw należy wybrać format źródłowy
(MS albo OOo / SO) (patrz rys. 3.35), a potem zdefiniować czy chodzi o dokumenty, czy o
szablony i w jakim katalogu si˛e one znajduja.˛ Nast˛epnie należy ustalić, w jakim katalogu
docelowym maja˛ być składowane skonwertowane dokumenty (patrz rys. 3.36). Na końcu
należy przekonwertować wszystkie dokumenty MS z katalogu źródłowego i umieścić je w
katalogu docelowym jako dokumenty OOo / SO.
Rysunek 3.35: Konwerter dokumentów: wybór formatu źródłowego
294
Rysunek 3.36: Konwerter dokumentów: wybór katalogu źródłowego i docelowego
Jak widać na rysunku (rys. 5.5.3), konwerter dokumentów potrafi rozróżniać dokumenty i
szablony dokumentów. Istotna różnica polega tu na tym, że szablon MS Office można zapisać
także jako szablon OOo / SO.
To, jaki sposób konwersji jest najkorzystniejszy w określonej chwili, zależy od stopnia skomplikowania dokumentów lub szablonów (patrz rozdział 3.15.4.5).
Ponadto należy bliżej ocenić każda˛ sytuacj˛e, gdy chodzi o konwertowanie makr, sterowania
OLE / COM albo integracj˛e zewn˛etrznych aplikacji. Trzeba je wówczas ponownie utworzyć.
Opcje konwersji
W OOo / SO do optymalizowania konwersji pojedynczej i konwersji Batch służa˛ jeszcze Ustawienia kompatybilności w Opcjach, z których należy skorzystać 74.
Kontrola skonwertowanych dokumentów
Po zakończeniu konwersji sensownie jest sprawdzić skonwertowane dokumenty pod katem
˛
przeniesienia do nich nast˛epujacych
˛
ustawień:
74
Patrz „StarOffice 6.0 Software Migration Guide“, strona 49 - 51
295
◦ wielkości znaków
◦ kraw˛edzi
◦ tabulatorów
◦ wci˛eć
◦ długości wierszy (tekst w wierszu)
◦ odległości mi˛edzy wierszami wewnatrz
˛ akapitów
◦ odległoś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, może ewentualnie pojawić si˛e potrzeba przeniesienia do nowego systemu istniejacych
˛
wpisów autotekstu, jak też
tworzonych przez długi czas słowników użytkowników.
Przekazywanie wpisów autotekstu z istniejacych
˛
szablonów do OOo / SO można zautoma75
tyzować .
Zarówno MS Office, jak i OOo / SO obsługuja˛ tworzenie słowników uż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łasnościowym. Na razie nie ma jeszcze
możliwości automatycznej migracji routine.
75
Szczegóły opisane zostały w „StarOffice 6.0 Migration Guide“, strony 69 - 71.
3.15.4.8
296
Integracja zewn˛etrznych aplikacji
W kontekście migracji do OOo / SO ważna˛ rol˛e w przypadku zewn˛etrznych aplikacji odgrywa
stopień zintegrowania z MS Office Suite. Wiele stosowanych obecnie w urz˛edach aplikacji specjalistycznych oraz standardowych została zaprojektowana specjalnie pod katem
˛
środowiska MS
Windows i w dużym stopniu korzysta z własnościowych modułów API Windows, takich jak:
◦ MAPI
◦ COM
◦ DDE
◦ ...
Stopień zintegrowania ze środowiskiem Windows może być przy tym całkiem różny. Prosta˛ i
nie sprawiajac
˛ a˛ wi˛ekszych problemów integracja˛ jest korzystanie z interfejsu MAPI w celu komunikowania si˛e z domyślnym klientem poczty elektronicznej z poziomu aplikacji. Z daleko
wyższym stopniem integracji mamy do czynienia, gdy zewn˛etrzna aplikacja zezwala tylko określonym aplikacjom MS badź
˛ bezwzgl˛ednie wymaga ich stosowania, aby możliwe było pełne
wykorzystanie funkcjonalności niniejszej aplikacji.
Tego typu różnice w stopniu zintegrowania zewn˛etrznych aplikacji z Windows oraz z MS Office Suite wymuszaja˛ dokładne sprawdzenie, czy migracja jest możliwa z technicznego punktu
widzenia i jakie nakłady sa˛ z nia˛ zwiazane.
˛
O ile dost˛epny jest kod źródłowy zewn˛etrznej aplikacji, należy w każdym przypadku sprawdzić, czy moż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łużac
˛ a˛ do rozszerzania funkcjonalności Office oraz do automatyzacji Office w Windows (patrz podrozdział 3.15.3.2). Obszar
zastosowania si˛ega aż do automatyzacji całych Workflows wewnatrz
˛ organizacji pomi˛edzy poszczególnymi oddziałami. Ponieważ makra i skrypty opieraja˛ si˛e w pierwszym rz˛edzie na VBA,
nie można wykonywać ich w OOo / SO. Obecnie nie jest oferowane rozwiazanie
˛
umoż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 nakreślona w pi˛eciu krokach.
297
COM, o ile maja˛ być nadal używane, trzeba przeprowadzić r˛ecznie albo utworzyć je od nowa.
Wówczas, w zależności od ilości, stopnia skomplikowania i jakości dokumentacji, w pewnych
okolicznościach nakłady moga˛ być bardzo wysokie, co może doprowadzić także do powstania
znacznych kosztów. Z drugiej jednak strony zyskuje si˛e wówczas możliwość skonsolidowania
makr i aplikacji OLE / COM, jak i nowego ukierunkowania strategii informatycnej w zakresie
automatyzacji biura.
Wskazówka: Aby w przyszłości nie być uzależnionym od określonego pakietu Office, moduły wymagane do automatyzacji należy zaimplementować jako składniki Java albo C++.
3.15.4.10
Środowisko programowania OOo/SO
OOo / SO posiada, tak samo jak MS Office, własne API78, co oznacza, że moga˛ wykonywać
takie same zadania. Zarówno Java, jak i C++ umożliwiaja˛ ponadto rozwijanie składników, które
jako Plug - In moga˛ spełniać najróżniejsze zadania wewnatrz
˛ OOo / SO.
◦ nowe typy Chart
◦ nowe funkcje Calc
◦ Wizards
◦ dodatkowe funkcje dla uż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 dużej cz˛eści
bardzo podobne, dlatego wprawny programista VBA nie b˛edzie miał wi˛ekszych trudności przy
przenoszeniu makr VBA.
Oprócz API, OOo / SO udost˛epnia, tak jak MS Office, własne środowisko programowania
(Integrated Development Environment (IDE)), którego interfejs użytkownika jest bardzo zbliżony do środowiska programisty w MS Office79.
78
Wszystkie istotne informacje na ten temat znaleźć można pod nast˛epujacym
˛
adresem WWW http://api.
openoffice.org/ (dokumentacja online). Specyfikacj˛e interfejsu można przeczytać na stronie http://udk.
openoffice.org/.
79
Dalsze wskazówki odnośnie post˛epowania w środowisku programistycznym i środowisku programowania znaleźć można w „StarOffice 6.0 Migration Guide“, strony 79 - 90.
3.15.4.11
298
Kompatybilność z MS Office
Z poprzedniego rozdziału wyraźnie wynika, że nie istnieje 100% - owa kompatybilność z MS Office. Cóż to oznacza, jeśli chodzi o wymian˛e dokumentów pomi˛edzy użytkownikami OOo / SO a
użytkownikami MS Office? Odpowiedzi na to pytanie należy udzielić na dwóch płaszczyznach.
1. Należy uwzgl˛ednić cel, w jakim sa˛ wymieniane dokumenty.
2. Należy również uwzgl˛ednić stopień skomplikowania dokumentów, które maja˛ być wymieniane.
Wymiana dokumentów odbywa si˛e z powodów czysto informacyjnych
W takim przypadku stopień skomplikowania wymienianych dokumentów nie odgrywa żadnej
roli. Dokumenty, które maja˛ być wymieniane należy przekonwertować do formatu PDF. Każdy
użytkownik dysponuje przegladark
˛
a˛ plików PDF, a jeśli tak nie jest, wówczas, można ja˛ nieodpłatnie pobrać z Internetu. Stosowanie formatu PDF, jako formatu wymiany dokumentów,
zalecane jest niemieckim urz˛edom już od dłuższego czasu.
Wymiana dokumentów odbywa si˛e w celu ich wspólnej edycji
W takim przypadku stopień złożoności dokumentu, zgodnie z tym, co wynika już z wcześniejszej oceny, odgrywa bardzo ważna˛ rol˛e.
1. Jeśli chodzi o proste dokumenty, wówczas wspólna edycja może odbywać si˛e bez wi˛ekszych problemów. Funkcje przetwarzania w OOo / SO i MS Office potrafia˛ ze soba˛ współpracować.
2. Jeśli jednak chodzi o skomplikowane dokumenty, wówczas podczas ich wspólnej edycji
należy pogodzić si˛e z wyraźnymi ograniczeniami.
◦ W przypadku przetwarzania tekstu oraz arkuszy kalkulacyjnych, wspólna edycja zalecana
jest tylko na poziomie treści. Odpowiedzialność za formatowanie należy jednoznacznie
zdefiniować po jednej stronie i wykonać formatowanie dopiero po zakończeniu pracy nad
treścia.˛ Post˛epowanie takie obydwie strony musza˛ ze soba˛ uzgodnić.
◦ Wskutek różnic w Chart - Engines, także w arkuszach kalkulacyjnych można tworzyć
Charts dopiero po zakończeniu pracy nad danymi. Jeśli Charts maja˛ być utworzone za pomoca˛ Calc, wówczas należy przestrzegać ograniczeń dotyczacych
˛
tworzenia etykiet (patrz
wyżej).
299
◦ Nie jest możliwa wspólna edycja tabel Pivot, ponieważ Calc ich nie obsługuje.
◦ Nie można zalecić wspólnej edycji skomplikowanych prezentacji.
Jeśli odbywać si˛e ma wspólna edycja dokumentów pochodzacych
˛
z OOo / SO i z MS Office,
wówczas należy stosować si˛e do nast˛epujacych
˛
zasad:
◦ Należy używać zgodnego formatu dokumentów. Jeśli posługujemy si˛e OOo i SO koniecznie musimy dostosować si˛e do formatów MS Office, gdyż w MS Office nie sa˛ dost˛epne
filtry OOo / SO. Jeśli istnieje format obsługiwany przez obydwa pakiety, taki jak np. RTF,
wówczas należy go używać.
◦ Należy unikać tak zwanej konwersji „Round Trip“.
◦ Formatowanie należy wykonywać dopiero w ostatnim kroku / ostatniej instancji, ponieważ
mapowanie pomi˛edzy OOo / SO a MS Office nie jest realizowane w skali jeden do jednego.
◦ Nie należy edytować dokumentów w Mixed - Mode, które
– używane sa˛ wspólnie przez wiele osób
i
– ewentualnie sa˛ jeszcze wyposażone w mechanizmy automatyzacji.
◦ Migracja dokumenty końcowych powinna odbywać si˛e w formacie PDF.
Jeśli chodzi o migracj˛e kontynuacyjna,˛ należy przede wszystkim ocenić migracj˛e z Office 97
do Office XP (2002), ponieważ z punktu widzenia migracji, obydwie te wersje istotnie si˛e od
siebie różnia.˛ W przypadku zastapienia
˛
Office 2000 przez Office XP zmiany, na które należałoby
zwrócić uwag˛e, nie sa˛ już tak znaczne, wzgl˛ednie zostały już zaimplementowane i oceniliśmy je
w opisie migracji z Office 97 do Office XP. Wersji MS Office wcześniejszych od Office 97 nie
ocenialiśmy.
W swoich dokumentach Microsoft odnosi si˛e do migracji do Office XP 80 badź
˛ w przypadku
prezentacji różnic81 do wcześniejszych wersji, w szczególności także do punktu wyjś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)
300
Ponadto konieczne jest krótkie spojrzenie na przewidywane nowoś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óżnice. Można je w prosty sposób otwierać za pomoca˛ odpowiednich aplikacji wchodzacych
˛
w skład Office XP. Jednakże nie istnieja˛
wiarygodne, doświadczalne dane, które potwierdzaja,˛ że w takim przypadku bezbł˛ednie działaja˛
wszystkie formatowania, szablony, makra i skrypty. W poszczególnych, udowodnionych przypadkach nie była możliwa bezproblemowa konwersja dokumentów badź
˛ szablonów Office 97.
Dokładnie tak samo, jak OOo / SO, również Office XP obsługuje konwersj˛e Batch, która˛
można przeprowadzić za pomoca˛ „asystentów konwersji stosowej“. Oprócz standardowych filtrów konwersji, Microsoft oferuje jeszcze „Office Konverter Pack“82 .
Kompatybilność z wcześniejszymi wersjami
Formaty danych z Office 97, 2000 i XP sa˛ kompatybilne. Zasadniczo w każdej wspomnianej
wersji można otwierać, edytować i ponownie zapisywać wszystkie dokumenty. Jednak może
si˛e zdarzyć, że pojedyncze nowe funkcje i formatowania z Office XP, nie b˛eda˛ wyś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 można z nich nadal korzystać
po nast˛epnym otwarciu w Office XP.
Migracja makr, skryptów i integracja zewn˛etrznych aplikacji
Główna trudność podczas migracji do Office XP dotyczy zmian wewnatrz
˛ środowiska programistycznego Office. Trzeba przy tym zwrócić 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 kompatybilność wzgl˛edem wcześniejszych wersji i tym samym na migracj˛e, główny wpływ
wywarła zmiana metody przyłaczania
˛
obiektów. Zasadniczo należy przyjać,
˛ że aplikacje Office
(makra, skrypty, zewn˛etrzne aplikacje), które powstały w środowisku programistycznym Office
97, można bez problemów stosować także w środowisku Office XP, bez konieczności dostosowania. Mimo zasadniczo istniejacej
˛ kompatybilności zwrotnej, Microsoft nie wyklucza, że moga˛
pojawić si˛e wyjatki,
˛ które sprawia,˛ ż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
301
Znacznie bardziej problematyczne może to być w odwrotnej sytuacji, co oznacza, że nowe
aplikacje napisane dla Office XP z trudem moga˛ być stosowane w środowisku Office 97. Dotyczy to także i w szczególności makr i należy o tym pami˛etać, gdy wewnatrz
˛ organizacji nie
przeprowadzono pełnej migracji badź
˛ migracja wykonywana jest sukcesywnie i jednocześnie
wykorzystywane sa˛ obydwie wersje Office.
Wskutek niepewności, czy możliwe b˛edzie dalsze używanie wszystkich aplikacji Office,
wzgl˛ednie czy niezb˛edne b˛edzie dostosowywanie aplikacji, powstaje konieczność, podobnie jak
w przypadku migracji zast˛epujacej,
˛
przeprowadzenia dokładnej analizy stanu istniejacych
˛
makr,
skryptów i zewn˛etrznych aplikacji.
Różnice w obszarze funkcjonalności
Jeśli chodzi o zmiany w funkcjonalnościach, na pierwszy plan wysuwa si˛e wprowadzenie tak
zwanych Smarttags84 i rozszerzonych funkcjonalności umożliwiajacych
˛
wspólna˛ edycj˛e, wzgl˛ednie korzystanie z dokumentów.
Smarttags sa˛ rozwini˛eta˛ możliwościa˛ automatyzacji poprzez kontekstowa˛ obsług˛e użytkowników. Smarttag wywołuje funkcj˛e w oparciu o wpis (np. z góry zdefiniowane słowo albo znana˛
liczb˛e). Można wyróżnić proste Smarttags i Smarttags oparte na COM. Zarzadzanie
˛
prostymi
Smarttags85 odbywa si˛e w listach XML, które należy składować w centralnie zdefiniowanym
miejscu w sieci komputerowej a nast˛epnie udost˛epnić wszystkim użytkownikom. Smarttags 86
oparte na COM należy stosować jako tak zwane Add - Ins. Jednak nie należy upatrywać w Smarttags dużych korzyści. Smarttags moga˛ z pewnościa˛ ułatwić prac˛e poczatkuj
˛ acemu
˛
informujac
˛ go
w odpowiednim miejscu o dost˛epnych funkcjonalnościach i pomagajac
˛ podczas formatowania.
Jednak równie dobrze moga˛ one całkowicie zdezorientować poczatkuj
˛ acego,
˛
gdy nie b˛edzie on
umiał używać oferowanych funkcjonalności. Aby tego uniknać,
˛ podczas migracji konieczne jest
dłuższe szkolenie.
W przyszłości Smarttags umożliwia˛ automatyzacj˛e w obszarze aplikacji, która nie b˛edzie
odpowiadać żadnemu otwartemu standardowi i b˛edzie współpracować wyłacznie
˛
z MS Office.
Wi˛eksze stosowanie prowadzić b˛edzie ostatecznie do jeszcze wyższych nakładów w przypadku
zast˛epowania MS Office badź
˛ zapobiegnie migracji z powodów ekonomicznych.
W przypadku rozszerzonych funkcjonalności, do wspólnej edycji i stosowania dokumentów
Office wykorzystać moż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
302
ich mylić 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óż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łuż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 możliwości rozbudowy, SharePoint Team Services szczególnie dobrze nadaja˛ si˛e dla małych organizacji i do obsługi grup roboczych Adhoc, obsługiwanych
także za pomoca˛ Internetu poza granicami organizacji. Jednak w takim przypadku należy także
uwzgl˛ednić ryzyko zwiazane
˛
z bezpieczeństwem.
Właśnie w tym miejscu autorzy niniejszego poradnika widza˛ najlepsze możliwości łatwego,
opartego na WWW i XML (oddzielenie treści od warstwy prezentacji) tworzenia i publikowania wspólnych dokumentów w grupach roboczych, niezależnie od własnościowych formatów
dokumentów. Szczególnie w przypadku współpracy wykraczajacej
˛ poza granice organizacji nie
należy zakładać, że wszyscy korzystaja˛ z takich samych środków. Aby być otwartym na każda˛
form˛e współpracy, należy stosować ogólnie uznane standardy, takie jak XML. Wydaje si˛e, że
racj˛e t˛e uznał także Microsoft, który chce w przyszłości, poczawszy
˛
od Office 2003, szerzej
wykorzystywać 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 uczynić 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óż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.
303
◦ ten zmodyfikowany XML b˛edzie domyślnym formatem plików w Office 2003. Oprócz
tego b˛edzie można równolegle korzystać także ze starych formatów plików.
◦ dla Word istnieje własny, charakterystyczny schemat XML (Word ML).
◦ pliki Word b˛edzie można zapisywać jeszcze w tak zwanym „pure XML“. Użytkownik
b˛edzie przy tym informowany, że plik w takim przypadku może utracić formatowania.
◦ aby otworzyć w Word obce dokumenty XML, trzeba jednocześnie udost˛epnić ważny plik
- schemat dla obcego dokumentu.
◦ Obcym dokumentom moga˛ być przypisywane własne Stylesheets (plik XLST).
◦ jednak podczas zapisywania w charakterystycznym formacie XML dla Word, tworzony
jest pojedynczy plik, w którym zawiera si˛e wszystko.
◦ w przypadku Excel 2003 b˛edzie to wygladać
˛
podobnie.
◦ Office 2003 wyposaż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 można jeszcze ostatecznie wypowiadać
si˛e na temat kompatybilnoś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 niezależna˛ od platformy i czy
Microsoft udost˛epni swoje rozszerzenia w otwartej formie?
3.15.6 Inne aplikacje desktopowe
Oprócz ocenionych wcześ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 najważniejsze fakty dotyczace
˛ aplikacji desktopowych oferowanych
przez desktop windowsowy i adekwatne, alternatywne aplikacje dost˛epne na desktopie linuksowym.
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
funkcjonalności dalece odbiegaja˛ od tych oferowanych przez MS Project.
3.15.6.2
Desktopy
W wi˛ekszości dystrybucji Linuksa użytkownikom udost˛epniane sa˛ gotowe desktopy wraz z najważniejszymi aplikacjami zintegrowanymi w podobny sposób, jak w przypadku desktopu windowsowego. Głównymi przedstawicielami sa˛ tu KDE i GNOME.
Graficzne interfejsy użytkownika desktopów realizowane sa˛ poprzez system X - Window
oraz różne menedżery okien
Dygresja: System X-Window a menedżer okien
System X-Window92, nazywany takż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. jakiś program użytkowy, komunikuje si˛e z serwerem poprzez protokół X. Serwer
i klient moga˛ przy tym pracować zarówno na oddzielnych maszynach, jak też na jednej i tej samej
maszynie. W przypadku korzystania z Linuksa na komputerach osobistych jest to reguła.˛ Dzi˛eki
umiej˛etności pracy sieciowej X nadaje si˛e szczególnie dobrze do zastosowań z Thin Clients.
„Look and Feel“ graficznego interfejsu użytkownika nie jest ustalane przez sam X, lecz przez
każdorazowo stosowany „Toolkit“ (np. Xt, Athena Widgets, OSF / Motif, Tk, Qt, Gtk+ itd.) i
każdorazowy menedżer okien (np. IceWM).
Menedżerem okien jest klient X, którego zadanie polega na zarzadzaniu
˛
układem, wielkościa˛
itd. okien programów, ich „ozdobnikami“, dost˛epnymi kolorowymi tablicami i wieloma innymi
elementami. Ze wzgl˛edu na dost˛epność dużej ilości menedżerów okien istnieje możliwość dowolnego kształtowania desktopu93. Desktopy opisane poniżej posiadaja˛ swoje własne menedżery
okien.
KDE
KDE jest przejrzystym i nowoczesnym ś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
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). Można go jednak dostosowywać według własnych
potrzeb i gustu. (patrz rys. 3.38).
Zasadniczo zmienić można niemal wszystko. Można ustawiać różne tematy graficzne, ramki
i zestawy ikon. Cz˛eściowo zależy to od czekajacych
˛
w tle menedżerów okien, które także można
dowolnie wybrać. Korzystać można ze wszystkich menedżerów okien X11R6. Dzi˛eki tym elastycznym możliwościom kształtowania wygladu
˛ można stworzyć dopasowany, jednolity desktop
spełniajacy
˛ indywidualne potrzeby urz˛edu lub działu. Istnieje przy tym możliwość ustawienia
wybranego stopnia dowolności dla użytkowników, jeśli chodzi o ustawienia osobiste.
94
Rysunek 3.37: Desktop KDE – przykład 1
94
Źródło: http://www.kde.org/screenshots/
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:
˛
◦ menedż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“
Ważne sa˛ także różne narz˛edzia administracyjne i zintegrowane środowisko programowania.
Kompletna˛ dokumentacj˛e znaleźć można na stronie http://docs.kde.org/.
Oprócz tego z poziomu KDE można oczywiście również korzystać z „aplikacji nie KDE“.
95
Źródło: http://www.kde.org/screenshots/
307
GNOME
GNOME96 jest cz˛eścia˛ projektu Open Source GNU97. GNOME to skrót od „GNU Network
Object Model Environment". Jeśli chodzi o layout, GNOME jest tak samo elastyczny, jak KDE
(patrz rys. 3.39 i rys. 3.40). Również GNOME udost˛epnia własny pakiet biurowy i środowisko
programowania. Niektórymi ze znanych aplikacji sa:
˛
◦ menedż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
Źródło: http://vhost.dulug.duke.edu/~louie/screenshots/2.2/
97
308
99
Rysunek 3.40: Desktop GNOME – przykład 2
3.15.6.3
Menedżery plików
◦ Konqueror
◦ Nautilus
◦ GNOME Midnightcommander
3.15.6.4
Przegladarki
˛
WWW
W Linuksie użytkownikom udost˛epniany jest cały szereg przegladarek
˛
WWW, z których można
wybierać według gustu i odpowiednio do potrzeb. Do najważniejszych z nich należa:
˛
◦ Galeon
Galeon100 jest przegladark
˛
a˛ WWW środowiska GNOME, która opiera si˛e na Mozilla Rendering Machine „Gecko“. Galeon jest lekka˛ przegladark
˛
a˛ wyposażona˛ w najbardziej niezb˛edne funkcjonalności. Jest za to szybki i kompatybilny ze wszystkimi standardami.
99
100
Źródło: http://vhost.dulug.duke.edu/~louie/screenshots/2.2/
http://galeon.sourceforge.net/
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 też dla innych
platform. Beonex Communicator uznawana jest za jedna˛ z najbezpieczniejszych przegla˛
darek.
◦ Konqueror
Konqueror101 jest nie tylko menedżerem plików w KDE (patrz wyżej), lecz można go
także wykorzystywać 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 ź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łacić, chyba że użytkownikowi nie przeszkadza cały szereg zintegrowanych banerów reklamowych. W takim
przypadku Oper˛e można ściagn
˛ ać
˛ za darmo z Internetu.
Wszystkie z wymienionych przegladarek
˛
sa˛ w dużym stopniu zgodne z HTML 4. Maja˛ one zarówno wady, jak i zalety, np. obsługuj˛e Java i XML. Jak już wspomnieliśmy, Beonex uważana
jest za przegladark˛
˛
e najbezpieczniejsza,˛ podczas gdy Galeon oraz Opera uchodza˛ za przegladarki
˛
bardzo szybkie. Poniż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
Przegladarka
˛
Wersja106
Galeon
1.2.10
Beonex
0.8.2
Konqueror
3.3.1
310
Klient poczty
Klient
Zgodność
POP3 / IMAP
Wiadomoś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
˛ przegladarek
˛
WWW należacych
˛
do OSS
3.15.6.5
Klient poczty elektronicznej
Dla desktopu linuksowego istnieja˛ również liczne klienty poczty elektronicznej (m. in. także
takie, które sa˛ zintegrowane z przegladarkami
˛
WWW). Dwa z nich należy wyróżnić, dlatego
opisaliśmy je poniżej. Jest to KMail i Sylpheed:
KMail (a projekt Ägypten)
KMail108 jest klientem poczty zintegrowanym z KDE, jednak może on pracować także w każdym innym ś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 umoż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. Zgodność ze SPHINX gwarantuje, m.in. uzyskanie
kompatybilności pomi˛edzy różnymi rozwiazaniami
˛
zgodnymi ze SPHINX oparta˛ na protokole
„TeleTrast e.V. MailTrustT w wersji 2“. Dzi˛eki temu użytkownik w biurze może w ramach PKI
za pomoca˛ S / MIME projektu „Ägypten“ wymieniać zaszyfrowane i podpisane wiadomości z
użytkownikami pracujacymi
˛
w innych organizacjach, niezależ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
311
Oprócz tego KMail jest także cz˛eś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 także obsługa SSL / TLS.
Sylpheed
Klient poczty elektronicznej Sylpheed110 jest również projektem Open Source (GPL) i wart
jest uwagi, gdyż dostarcza takiego samego „Look and Feel“, jak Outlook, b˛edac
˛ jednocześnie
szybkim klientem poczty oraz czytnikiem wiadomości. Sylpheed obsługuje nast˛epujace
˛ protokoły:
◦ POP3
◦ APOP
◦ IMAP4
◦ SMTP
◦ SMTP AUTH
◦ NNTP.
3.15.6.6
Inne narz˛edzia
Poniżej wymieniliśmy alternatywne narz˛edzia należace
˛ do rozwiazań
˛
OSS i pogrupowane według pojedynczych kategorii.
◦ edytor grafiki
– Gimp http://www.gimp.org/
110
http://sylpheed.good-day.net/
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 użyciu klienta linuksowego
W niemal wszystkich urz˛edach istnieje jedna badź
˛ wiele aplikacji specjalistycznych lub aplikacji standardowych, które sa˛ bardzo potrzebne do wypełniania specjalistycznych zadań i które
dost˛epne sa˛ niestety tylko w postaci aplikacji windowsowych. Jeśli nie uda si˛e udost˛epnić tych
aplikacji użytkownikom także pod Linuksem, wówczas skutkiem tego może być załamanie si˛e
migracji do środowiska linuksowego.
Długofalowym celem migracji musi być również 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ół przewidzieć, kiedy
dana aplikacja udost˛epniona zostanie dla jednej badź
˛ drugiej platformy linuksowej. Należy mieć
nadziej˛e, że dzi˛eki coraz szerszemu wykorzystywaniu Linuksa i Open Source Software (OSS) w
urz˛edach, producenci b˛eda˛ udost˛epniać swoje aplikacje w akceptowalnym terminie także dla tej
platformy.
W przypadku aplikacji specjalistycznych, które zostały napisane dla jednego badź
˛ wielu urz˛edów jako aplikacje indywidualne, urz˛edy musiałyby zamówić nowy program niezależny od platformy albo zlecić przeportowanie istniejacej
˛ aplikacji do Linuksa. Jednak coś takiego nie może
313
mieć miejsca w przypadku migracji, ponieważ tego typu zamierzenie byłoby niewykonalne zarówno z powodów czasowych, jak również finansowych i nie obroniłoby si˛e ze wzgl˛edów ekonomicznych.
Zatem należy znaleźć rozwiazanie
˛
kompromisowe, które umożliwi urz˛edom dalsze korzystanie ze wspomnianych aplikacji także pod Linuksem do czasu, aż z ekonomicznego i technicznego
punktu widzenia uzasadnione stanie si˛e wprowadzenie nowego oprogramowania albo przeportowanie starego lub aż udost˛epniona zostanie standardowa aplikacja linuksowa.
Od dawna istnieja˛ rozwiazania,
˛
które umożliwiaja˛ aplikacjom windowsowym prac˛e na linuksowych stacjach roboczych. Produkty te można podzielić na trzy grupy:
◦ Rozwiazania,
˛
które pozwalaja˛ na bezpośrednie wykonywanie aplikacji windowsowych.
Programy te nie wymagaja˛ posiadania licencji Windows. Zaliczaja˛ si˛e do nich WINE oraz
Crossover Office.
◦ Rozwiazania,
˛
które potrafia˛ emulować PC, na którym może pracować Windows. Dzi˛eki
nim na tym samym komputerze osobistym moż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 wyświetlane na kliencie linuksowym i z niego obsługiwane: (Citrix, Microsoft Terminal Services).
W każdym pojedynczym przypadku należy dokładnie sprawdzić, jakie rozwiazanie
˛
najlepiej nadaje si˛e dla danych aplikacji, wymagań i środowisk. Właściwości wymienionych rozwiazań,
˛
jak
też koszty ich stosowania wyraźnie si˛e różnia.˛
Poniżej oceniliśmy kolejne rozwiazania
˛
pod katem
˛
ich właściwości technicznych i funkcjonalności. Szczególnie interesujacy
˛ jest tu stopień, w jakim poszczególne rozwiazania
˛
zintegrowane sa˛ z całym systemem.
3.15.7.1
VMware
Workstation 4
VMware działajace
˛ m.in. w systemie operacyjnym GNU / Linux umożliwia uruchamianie
innych systemów operacyjnych w maszynie wirtualnej. VMware emuluje przy tym wirtualny
komputer posiadajacy:
˛
◦ dyski twarde
314
◦ nap˛ed dyskietek
◦ różne interfejsy
oraz
◦ inna˛ infrastruktur˛e.
Oprogramowanie to umożliwia równoczesna˛ prac˛e systemu emulowanego oraz właściwego systemu komputera (system operacyjny hosta).
Obsługiwane systemy operacyjne
Dzi˛eki całkowitej emulacji komputera, VMware uzyskuje bardzo wysoka˛ kompatybilność z
wieloma systemami operacyjnymi. Obsługiwane sa˛ nast˛epujace
˛ systemy - goś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 użytkowego. Rozszerzenie jadra
˛ dostarczane jest wraz z kodem źródłowym, dzi˛eki czemu teoretycznie możliwe jest
portowanie dowolnych wersji jadra.
˛
Programy wykonywalne
W zależności od danego systemu operacyjnego możliwe jest nieograniczone wykonywanie
wi˛ekszości obsługiwanych programów. Niewielkie ograniczenia istnieja˛ jedynie w obszarze programów multimedialnych.
Dlatego VMware Workstation nadaje si˛e także zwłaszcza do uruchamiania aplikacji specjalistycznych, jak też aplikacji biurowych i internetowych. Głównym obszarem zastosowań jest
315
jednak obecnie rozwój oprogramowania, ponieważ developerzy moga˛ testować swoje wieloplatformowe aplikacje równolegle na jednej i tej samej maszynie, w różnych systemach operacyjnych.
Ograniczenia
Pełna emulacja komputera nadal jeszcze stawia duże wymagania wzgl˛edem maszyny, na
której odbywa si˛e emulacja. Dlatego praca wielu programów w VMware jest odczuwalnie wolniejsza niż na porównywalnym, prawdziwym komputerze.
Stopień integracji
VMware pracujace
˛ na komputerze z Linuksem, gdzie ma miejsce emulacja, wyświetla desktop windowsowy we własnym oknie. Z tego okna można wywoływać poszczególne aplikacje
windowsowe. Wymiana danych pomi˛edzy Windowsem a Linuksem nast˛epuj˛e poprzez emulowana˛ sieć. W tym celu konieczne jest ustawienie parametrów Samby podczas instalacji VMware.
Ma to umożliwić dost˛ep do katalogu domowego komputera z Linuksem.
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 należy oceniać jako niezbyt ergonomiczne.
Koszty
VMware jest produktem komercyjnym, za używanie którego pobierana jest opłata 112. Aby
móc używać aplikacji windowsowych, trzeba dodatkowo wykupić także licencje Windows. Do
tego dochodza˛ jeszcze zwi˛ekszone koszty osprz˛etu spowodowane wyższymi wymaganiami stawianymi przez VMware.
Biorac
˛ powyższe pod uwag˛e należy stwierdzić, że udost˛epnianie aplikacji windowsowych z
wykorzystaniem VMware jest dość drogie.
111
Źródło: VMware http://www.vmware.com/products/desktop/ws_screens.html
Bliższe informacje znaleźć można na stronie http://www.vmware.com/vmwarestore/pricing.
html
112
317
Ocena
Prawdziwa siła VMware tkwi raczej w tym, o czym już wspomnieliśmy, czyli w udost˛epnianiu dobrej platformy programistycznej dla aplikacji wieloplatformowych, niż w możliwości
udost˛epniania aplikacji windowsowych w Linuksie. Dlatego VMware należy wykorzystywać 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 można uruchamiać wirtualne maszyny jako procesy w tle. Serwerem tym można
sterować zdalnie spod Windows albo Linuksa, jak również możliwe jest zdalne administrowanie
poprzez interfejs WWW oraz specjalny, skryptowy API. Dzi˛eki temu można także jednocześnie
uruchamiać, na osprz˛ecie firmy Intel, wiele systemów operacyjnych i konsolidować w ten sposób
środowiska serwera.
Jeśli chodzi o „obsługiwane systemy operacyjne“, „programy wykonywalne“, „ograniczenia“, „stopień integracji“, „koszty“ i „ocen˛e“ obowiazuj˛
˛ e takie same uwagi, jak w przypadku
opisanego wcześniej wariantu Workstation113.
3.15.7.2
Win4Lin
Win4Lin 4.0 - Workstation Edition Win4Lin114 umoż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, że nie musi on już sam wykonywać w/w usług, lecz odwołuje si˛e do
odpowiednich usług świadczonych przez moduły jadra.
˛
Dlatego w Win4Lin aplikacje działaja˛ z
reguły znacznie szybciej niż w VMware.
W Win4Lin, tak samo jak w VMware, desktop windowsowy udost˛epniany jest we własnym
oknie. Po starcie programu, otwiera on okno, w którym bootuje si˛e Windows. Nast˛epnie użytkownik może w otwartym oknie uruchamiać aplikacje windowsowe i z nimi pracować (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/
318
Win4Lin nie stawia także żadnych szczególnych wymagań sprz˛etowych. Oprogramowanie
to może pracować na każdym współczesnym komputerze osobistym 115.
Win4Lin może współpracować z każda˛ wykorzystywana˛ obecnie dystrybucja Linuksa, o ile
używa ona jadra
˛ z rodziny 2.4.x.
Jak już wspomnieliśmy, za pomoca˛ Win4Lin możliwe jest uruchamianie nast˛epujacych
˛
wersji Windows116.
◦ 95
◦ 98
◦ ME
Za pomoca˛ Win4Lin 4.0 można z reguły udost˛epniać na linuksowej stacji roboczej aplikacje
biurowe, internetowe a nawet aplikacje bazodanowe.
Ograniczenia
Poniżej wypunktowaliśmy istniejace
˛ ograniczenia:
◦ obsługiwane wersje Windows
Należy tu oczekiwać, że wiele nowych aplikacji wkrótce nie b˛edzie mogło w nich pracować.
◦ łaty modułów windowsowych
Nakładanie łat firmy Microsoft należy wykonywać ostrożnie, gdyż nie można wykluczyć,
że podczas tego procesu wymienione zostana˛ pliki zmienione przez Win4Lin i system
straci swoja˛ stabilność.
115
Wymagania sprz˛etowe zalecane przez producenta http://www.netraverse.com/products/
win4lin40/requirements.php
116
Szczegółowe dane znaleźć można na stronie http://www.netraverse.com/support/docs/400_
relnotes.html
319
◦ udost˛epniana pami˛eć
Aplikacjom windowsowym pracujacym
˛
w Win4Lin, od wersji 4.0, można udost˛epnić maksymalnie 128 MB pami˛eci operacyjnej.
Pami˛eć wirtualna ograniczana jest jedynie przez dost˛epna˛ pojemność partycji dysku, na
której znajduje si˛e katalog „$HOME/win“ użytkowników.
◦ obsługa interfejsów
Nie sa˛ obsługiwane interfejsy DirectX i USB.
W Win4Lin, tak samo jak w VMware, desktop windowsowy udost˛epniany jest we własnym
oknie, w którym można wywoływać aplikacje windowsowe.
117
Rysunek 3.42: Desktop windowsowy w Linuksie emulowany przez Win4Lin
117
Źródło:
Netraverse
fullsizescreenshot.jpg
http://www.netraverse.com/products/win4lin40/
320
Wymiana danych pomi˛edzy aplikacjami linuksowymi i windowsowymi jest jednak łatwiejsza
niż w przypadku VMware. Dzi˛eki technice oferowanej przez Win4Lin, katalogi linuksowe moga˛
być prezentowane w postaci nap˛edów.
Również w tym przypadku nie można jednak mówić o rzeczywistej integracji poszczególnych aplikacji. Po uruchomieniu programu wyświetlane jest okno, w którym użytkownik widzi
bootujacy
˛ si˛e Windows, jeszcze przed umożliwieniem mu uruchamiania aplikacji i pracy z nimi.
Koszty
Win4Lin również jest produktem komercyjnym, za który należy zapłacić. Koszty licencji 118
sa˛ tu jednak znacznie niższe niż w przypadku VMware. Do tego dochodza˛ jeszcze, tak samo, jak
w przypadku VMware, koszty licencji Microsoft. W przypadku obydwu systemów operacyjnych
sa˛ to jednak przewidywalne sumy. Dzi˛eki temu praca aplikacji windowsowych w linuksowym
emulatorze Win4Lin jest znacznie korzystniejsza niż w emulatorze VMware.
Ocena
Mimo kilku technicznych ograniczeń, Win4Lin jest obecnie w wielu przypadkach droga,
˛
która˛ można by podażać,
˛
a prowadzac
˛ a˛ do korzystania z aplikacji windowsowych w Linuksie.
Jest tak zwłaszcza w przypadku, gdy dana aplikacja ma być używana tylko na niewielu stacjach
roboczych. W przypadku, gdy korzystanie z aplikacji przewidziane jest na wielu stacjach roboczych, można ewentualnie skorzystać z Win4Lin Terminal Server, który pokrótce opisaliśmy w
nast˛epnym paragrafie.
Win4Lin Terminal Server 2.0
W Win4Lin Terminal Server firma Netraverse wykorzystała właściwości sieciowe protokołu
X w celu umożliwienia korzystania z Win4Lin z poziomu innego systemu. Jest to możliwe,
ponieważ wyświetlanie okien Win4Lin odbywa si˛e na desktopie linuksowym właśnie za pomoca˛
niniejszego protokołu.
Win4Lin Terminal Server uruchamia wówczas na serwerze linuksowym oddzielne sesje programu dla każdego użytkownika, który uż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
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, jeśli chodzi o udost˛epnianie aplikacji windowsowych w Linuksie, na innej zasadzie, jak jest to w przypadku rozwiazań
˛
opisanych powyż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 uruchamiać aplikacje w Linuksie. Mimo, że WINE nie jest emulatorem, postanowiliśmy dokładnie go ocenić.
Najwi˛ekszym wyzwaniem jest jak najpełniejsze udost˛epnienie bibliotek windowsowych w
postaci wolnych implementacji, co ma na celu umożliwienie pracy w Linuksie jak najwi˛ekszej
ilości aplikacji windowsowych. W WINE zaimplementowane zostały już biblioteki windowsowe
z najważniejszymi funkcjami, dzi˛eki czemu nie ma problemu, gdy uruchamiana aplikacja odwołuje si˛e tylko ze standardowej funkcjonalności (systemu operacyjnego Windows) i sama wnosi
pozostałe funkcje. Sytuacja jest trudniejsza, gdy aplikacja windowsowa korzysta przeważnie z
nowych, jeszcze nie zaimplementowanych funkcji bibliotek Windows albo z bibliotek innych
aplikacji. W zwiazku
˛
z tym należy wspomnieć także o tym, że producenci oprogramowania z
reguły staraja˛ si˛e, aby obsługiwało ona również starsze wersje Windows i dlatego rzadko wprowadzaja˛ nowe Features albo sa˛ one stosowane opcjonalnie, dlatego w praktyce nie musza˛ one
koniecznie powodować problemów.
W tak zwanym mi˛edzyczasie WINE zaczał
˛ obsługiwać wiele aplikacji (patrz poniższy paragraf „Programy wykonywalne“) oraz Features120.
WINE dost˛epny jest praktycznie dla każdego systemu linuksowego i wchodzi w skład wi˛ekszości dystrybucji.
Za pomoca˛ WINE można zasadniczo uruchamiać wszystkie aplikacje windowsowe, o ile
119
Strona domowa projektu WINE http://www.winehq.com/
List˛e znaleźć można na stronie http://www.winehq.com/?page=wine_features;winehq=
d35c3404fe39283bf96bb1dd54b14c8d
120
322
dost˛epne sa˛ wymagane biblioteki.
Do programów, o których wiadomo, że moga˛ w taki sposób pracować należa˛ m.in Winword. Excel i PowerPoint z pakietów biurowych Office 97 i Office 2000, jak też Internet Explorer. W poszczególnych przypadkach trzeba wcześniej wykonać praktyczny test funkcjonalności,
przy czym wcześniej należy zapoznać si˛e z baza˛ danych aplikacji dost˛epna˛ na stronie http:
//appdb.winehq.com/.
Ograniczenia
Problem w WINE stanowi, wymagajaca
˛ wciaż
˛ dość dużej pracy, konfiguracja programu,
która zakłada posiadanie wielu wiadomości.
WINE sprawia, że aplikacje windowsowe sa˛ optymalnie zintegrowane z desktopem linuksowym. Programy nie sa˛ tu uruchamiane z poziomu ich własnego desktopu, lecz bezpośrednio za
pomoca˛ menedżera okien desktopu linuksowego we własnym oknie X - Window.
323
121
Rysunek 3.43: Aplikacje windowsowe na desktopie linuksowym emulowane przez WINE
Koszty
W tym przypadku płacić trzeba tylko za koszty licencji na używanie poszczególnych aplikacji windowsowych. Jednakże w odróżnieniu od wcześniej omawianych rozwiazań
˛
należy liczyć
si˛e z wi˛eksza˛ ilościa˛ pracy administracyjnej.
Ocena
Rozwiazanie
˛
to ma dwie istotne zalety:
◦ nie trzeba płacić za licencje systemu operacyjnego Windows.
◦ nie trzeba uruchamiać dodatkowego systemu operacyjnego, który dodatkowo obciażałby
˛
dost˛epne zasoby. Teoretycznie aplikacje windowsowe można uruchamiać tak samo szybko,
jak w Windows i wymagaja˛ one tej samej ilości pami˛eci.
121
Źródło: http://www.winehq.com/?ss=1
324
Zatem, o ile WINE udost˛epnia biblioteki niezb˛edne dla działania danej aplikacji, należy z niego
skorzystać w pierwszej kolejności.
WINE, jako jedyny, mógłby stworzyć możliwość uruchamiania MS Project na desktopach
linuksowym, gdyż obecnie nie ma alternatywnej aplikacji dla Linuksa. W bazie danych aplikacji
nie można jednak znaleźć ż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, że WINE w CO uzupełniony został o
wygodny program instalacyjny i skrypty służace
˛ do konfiguracji ustawień użytkowników oraz
instalacji aplikacji windowsowych.
Crossover Office obsługuje obecnie Microsoft Word, Excel oraz PowerPoint (z Office 97 i
2000). Inne aplikacje, takie jak Outlook 2000, IE 5.5 oraz Notes R5 pracuja˛ dość 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 skorzystać z CO, a nie z WINE.
Crossover Office Server Edition
Crossover Office Server Edition umoż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, że aplikacje windowsowe można udost˛epniać centralnie i
centralnie nimi administrować.
122
123
Strona domowa Code Weavers http://www.codeweavers.com/home/.
Informacja o cenach Crossover Office http://secure.codeweavers.com/store/.
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 można uruchamiać w Linuksie szereg zbytecznych gier windowsowych. Z tego powodu nie b˛edziemy bliżej oceniać WineX i wymieniliśmy
go tylko ze wzgl˛edu na ch˛eć pełnego przedstawienia tematu.
WineX nie jest Wolnym Oprogramowaniem.
3.15.7.3
Citrix Metaframe
Funkcjonalności opisaliśmy w rozdziale 3.16.5.
(patrz rozdział 3.16.5)
Uruchamiać można wszystkie aplikacje windowsowe, które pracuja˛ w Windows NT albo
Windows 2000.
Ograniczenia
Ograniczenia dotyczace
˛ wykonywania aplikacji windowsowych istnieja˛ tylko aplikacje obciażone
˛
grafika˛ (patrz wyżej), których w miar˛e możliwości nie należy uruchamiać za pomoca˛
Citrix Metaframe.
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
odbywać si˛e może tylko poprzez sieć. Tym samym również tutaj mamy do czynienia z małym
stopniem integracji.
124
Strona domowa firmy Transgaming http://www.transgaming.com/.
326
Koszty
Koszty zależa˛ od każdorazowego sposobu wykorzystania żadanego
˛
Metaframe i należy je
oceniać osobno w każ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 także jako aplikacje linuksowe, ponieważ jest
przede wszystkim za drogi i zbyt skomplikowany.
Citrix Metaframe należy jednak wziać
˛ pod uwag˛e, gdy przewiduje si˛e istnienie takich aplikacji windowsowych, z których trzeba b˛edzie korzystać długoterminowo.
Najwi˛eksza˛ zaleta˛ Citrix Metaframe jest centralna instalacja i zarzadzanie
˛
aplikacjami, jak
też centralne przechowywanie danych. Citrix Metaframe sprawdza si˛e dobrze również w środowisku Thin Clients oraz klientów bezdyskowych.
3.15.7.4
Windows Terminal Server
Funkcjonalności opisaliśmy w rozdziale 3.16.5.
Sa˛ to wszystkie aplikacje windowsowe, które można uruchamiać w Windows 2000.
Ograniczenia
327
Taki sam, jak w przypadku Citrix Metaframe.
Koszty
W przeciwieństwie do Citrix dochodza˛ tu jeszcze koszty licencji Microsoft.
Ocena
Wariant ten należy ocenić podobnie jak rozwiazanie
˛
Citrix Metaframe, przy czym jest on
nieco korzystniejszy. Jednak wada˛ w porównaniu z Citrix Metaframe jest to, że w przypadku
Windows Terminal Servers nie zebrano jeszcze tak szerokich doświadczeń, jak z Citrix Metaframe, zwłaszcza w dużych i skomplikowanych środowiskach. Jednakże podczas poszukiwań
rozwiazania
˛
samego problemu ma to niewielkie znaczenie.
Podsumowanie
VMware, Win4Lin, WINE oraz Crossover Office moga˛ być traktowane tylko jak rozwiaza˛
nia przejściowe albo rozwiazanie
˛
dla pojedynczych, małych aplikacji pracujacych
˛
na poszczególnych stacjach roboczych. W nieodległym czasie musi powstać odpowiednia, niezależna od
platformy aplikacja uruchamiana pod Linuksem.
W przeciwnym razie można sprawdzić czy Citrix Metaframe może być rozwiazaniem
˛
przemysłowym, przy czym b˛edzie to z pewnościa˛ raczej strategiczna decyzja.
Zważywszy na powyższe warunki możliwe jest sformułowanie nast˛epujacych
˛
ocen:
◦ W przypadku przewidywalnej ilości aplikacji windowsowych opłaca si˛e zastosować WINE
(w razie potrzeby trzeba ewentualnie dodatkowo, twórczo popracować).
◦ Jeśli istnieje wiele danych aplikacji windowsowych, wówczas istnieje duże prawdopodobieństwo, że nie wszystkie aplikacje b˛edzie można uruchomić za pomoca˛ WINE. Dlatego
należy sprawdzić, czy możliwe jest wykorzystanie Win4Lin (czy aplikacje działaja˛ z Windows 95, 98 albo ME).
◦ Jeśli ilość danych aplikacji windowsowych jest bardzo duża, wówczas pojawia si˛e podstawowe pytanie o sens migracji (granic˛e należy sprawdzić w konkretnym przypadku).
◦ W przyszłości trzeba wesprzeć powstanie aplikacji niezależnych od platformy.
328
3.15.8 Ocena
W oparciu o wcześniejsze spostrzeżenia, oceniliśmy poniżej zastapienie
˛
Office 97 badź
˛ Office
2000 przez Office XP lub Office 2003 albo przez OOo / SO. Wyniki niniejszych ocen tworza˛
podstaw˛e dla oceny możliwości zastapienia
˛
desktopu firmy Microsoft desktopem linuksowym.
3.15.8.1
Zastapienie
˛
Office 97/2000
Migracja do Office XP
Nad zasadnościa˛ migracji z Office 97 badź
˛ 2000 do Office XP należy si˛e zastanowić z nast˛epujacego
˛
powodu.
Migracja wymaga zawsze czasu i nakładów, dlatego odbywa si˛e ona w kierunku najnowszej
oraz najnowocześniejszej techniki, a nie w kierunku wciaż
˛ dost˛epnej, starszej techniki. W przypadku Office XP można przewidywać, że zostanie on zastapiony
˛
jeszcze w roku 2003 przez Office 2003, który wniesie nowsza˛ i bardziej innowacyjna˛ technik˛e. Jeśli zgodnie z zapowiedziami,
Office 2003 zostanie udost˛epniony w pełnej wersji latem 2003, wówczas można założyć, ż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, że
obecnie nie ma jeszcze doświadczeń z zastosowań produkcyjnych pakietu Office 2003.
Na podstawie silnego dażenia
˛
w Office 2003 do XML oraz dotychczasowych doświadczeń
z wersja˛ Beta 2 można oczekiwać, że wraz z wprowadzeniem Office 2003 łatwiejsza stanie si˛e
wymiana dokumentów niezależna od platformy. Samo to jest wystarczajacym
˛
powodem, aby
poczekać z migracja˛ do momentu, gdy Office 2003 ukaże si˛e jako wzgl˛ednie stabilna i bezbł˛edna
wersja oraz aż dost˛epne b˛eda˛ wyniki z codziennego wykorzystywania tego pakietu biurowego,
także jeśli chodzi o ponadplatformowa˛ wymian˛e dokumentów.
Migracja do OOo / SO
Migracj˛e do OOo / SO można, z dzisiejszego punktu widzenia, zalecić 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
329
◦ sa˛ proste, tzn. sa˛ to dokumenty bez makr oraz bez szczególnych formatowań i jako takie sa˛
wspólnie edytowane przez inne urz˛edy i organizacje korzystajace
˛ z MS Office (do wersji
XP).
Jeś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 należy spodziewać si˛e,
że współpraca b˛edzie zbyt skomplikowana i pracochłonna.
Migracja do OOo / SO nie jest zalecana z technicznego punktu widzenia również wówczas,
gdy nie ma możliwości zintegrowania z OOo / SO bezwzgl˛ednie koniecznych, zewn˛etrznych
aplikacji, które sa˛ silnie zintegrowane z MS Office.
Ponieważ obecnie nadal nie ma dostatecznych informacji na temat wymiany dokumentów
pomi˛edzy MS Office 2003 a OOo / SO, w przyszłości w wersjach 1.1 i 6.1, wi˛ec na razie nie
możemy si˛e na ten temat wypowiedzieć.
3.16 Terminal-Server i Thin Clients
3.16.1 Przeglad
˛
W projekcie migracyjnym może znaleźć si˛e decyzja o zastosowaniu Terminal - Servers i Thin
Clients. Dlatego ich opis stał si˛e cz˛eścia˛ składowa˛ niniejszego poradnika. Jednak nie jest to klasyczny temat migracyjny, ponieważ z reguły nie wykonuje si˛e migracji środowisk Terminal Server. Zastosowanie techniki opisanej poniżej jest w pierwszym rz˛edzie decyzja˛ wewnatrz
˛ ogólnej
strategii informatycznej każdego urz˛edu. Przedstawione rozwiazania
˛
powinny jednak umożliwić
wglad
˛ w całe zagadnienie i wyjaśnić potencjał opisywanej technologii. Prezentujemy technologie, z których można korzystać w najróż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óżnymi systemami klienckimi (DOS, Windows, Unix, Linux,
itd.).
330
Przedstawione systemy oferuja˛ cała˛ gam˛e różnych technicznych rozwiazań
˛
(systemy serwerowe
i klienckie) i należy je dokładnie ocenić w każdym pojedynczym przypadku. Oprócz różnic i
możliwości technicznych, systemy te różnia˛ si˛e znacznie, także jeśli chodzi o modele licencji i
koszty.
3.16.2 Wprowadzenie
Administrowanie i opieka nad komputerami pełniacymi
˛
funkcje stacji roboczych jest zadaniem
wymagajacym
˛
dużych nakładów osobowych, zwłaszcza wtedy, gdy komputery wyposażone zostały w różny osprz˛et i oprogramowanie. Również rosnacy
˛ stopień skomplikowania stosowanego
osprz˛etu i oprogramowania może powodować wi˛eksza˛ awaryjność stacji roboczych i tym samym
wymagać pracy administracyjnej. Prace zwiazane
˛
z opieka˛ nad systemem zostały wyszczególnione poniż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˛eści zamiennych
W sumie zadania można zautomatyzować za pomoca˛ odpowiednich narz˛edzi administracyjnych
badź
˛ aplikacji przeznaczonych do zarzadzania
˛
systemem. Automatyzacja taka może zmniejszyć
konieczna˛ ilość pracy, jednak nakłady pracy z reguły nadal b˛eda˛ bardzo wysokie. Ponadto nie
każda organizacja jest w stanie sfinansować kupno po cz˛eści bardzo drogiego oprogramowania
do zarzadzania
˛
systemem, zwłaszcza gdy jest to mniejsza organizacja.
Stosowanie Terminal - Servers może znacznie zmniejszyć nakreślone problemy. Także w
ramach kolejnych projektów migracyjnych należałoby zastanowić si˛e nad przyszłym wykorzystaniem Terminal - Servers i odpowiednich Thin Clients. W tradycyjnym zdecentralizowanym
środowisku IT, instalacja i uruchamianie programów nast˛epuje najcz˛eściej na komputerach pełniacych
˛
rol˛e stacji roboczych. Struktura serwerów służy przede wszystkim do centralnego zarzadzania
˛
danymi, zabezpieczania danych i sterowania prawami dost˛epu. W przypadku zastosowania rozwiazania
˛
Terminal - Server, wydajny komputer badź
˛ komputery centralne, tj. właściwe
331
Terminal - Server, zapewniaja˛ dost˛ep z każdego miejsca do potrzebnych danych i aplikacji. Terminal - Servers oferuja˛ użytkownikom bezpośredni dost˛ep do graficznego interfejsu użytkownika
systemu operacyjnego poprzez sieć. Każdy użytkownik zalogowany do Terminal - Server otrzymuje własna˛ sesj˛e (Session) oraz prawo do korzystania ze wszystkich udost˛epnianych zasobów
systemu operacyjnego. W przeciwieństwie do tradycyjnych zdecentralizowanych architektur stacji roboczych, nie jest to dost˛ep tylko do danych, lecz także do aplikacji z centralnego serwera.
Dost˛ep do aplikacji i danych mieszczacych
˛
si˛e w Terminal - Server musi sie odbywać za pośrednictwem specjalnych programów terminalowych badź
˛ tak zwanych Thin Clients.
Poniższa tabela przedstawia zalety stosowania Terminal - Servers oraz Thin Clients.
Z ALETY
O BJA ŚNIENIA
System operacyjny i aplikacje przechowywane sa˛ w Terminal Servers centralnie tylko w prostej formie.
◦ Opiek˛e nad oprogramowaniem można teraz sprawować
centralnie (łaty, aktualizacje).
◦ Nie sa˛ już wymagane ż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 wydajność użytkownika i administrowania.
– dzi˛eki uproszczeniu administrowania możliwe staje
si˛e szybsze udost˛epnianie aplikacji użytkownikom.
– dzi˛eki temu, że nie trzeba już usuwać bł˛edów na
miejscu, znacznie zmniejszaja˛ si˛e nakłady administracyjne.
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 już potrzebna.
◦ Istniejacy
˛ osprz˛et może być dłużej wykorzystywany.
Wskutek stosowania Thin Clients (bez dysków twardych) dane
moga˛ być zapisywane tylko w centralnych serwerach [dotyczy
zwi˛ekszone
czeństwo
bezpie-
to również Fat Clients]. W ten sposób w systemach klienckich
zmniejsza si˛e niebezpieczeństwo utraty danych badź
˛ manipulacji danymi przez nieupoważnione osoby, wzgl˛ednie ich kradzieży,
gdyż osoby te nie maja˛ do nich dost˛epu.
Komputery pełniace
˛ rol˛e stacji roboczych można szybko wymie-
niezależność od klienta
nić, ponieważ w klientach nie sa˛ już zapisywane dane osobowe,
czy też ustawienia. Jednak przede wszystkim użytkownicy maja˛
możliwość dowolnego zmieniania miejsca pracy, bez rezygnowania ze „swojego“ zaufanego środowiska.
Tablica 3.71: Zalety Terminal - Servers i Thin Clients
Oprócz opisanych powyżej zalet należy jednak także wymienić kilka wad, które należy wziać
˛
pod uwag˛e podczas podejmowania decyzji za badź
˛ przeciw zastosowaniu Terminal - Servers.
WADY
O BJA ŚNIENIE
333
W przypadku awarii Terminal - Server przerywane sa˛ sesje użytkowników i nie jest możliwe ponowne podj˛ecie pracy przed usuni˛eciem bł˛edu po stronie serwera. Można to zminimalizować sto-
uzależnienie
sujac
˛ Serverfarm.
W przypadku przerwania sesji użytkowników może dojść do
utraty danych.
Terminal - Servers musza˛ dysponować wyraźnie wi˛ekszymi zasobami, zwłaszcza jeśli chodzi o pami˛eć. Jednak w odniesieniu do
zwi˛ekszone wymagania
wzgl˛edem zasobów
ogólnego zapotrzebowania (serwery i klienty) wielkość wymaganych zasobów jest mniejsza, ponieważ określone operacje wykonywane sa˛ przez serwer tylko raz dla wszystkich użytkowników a
nie na każdym jednym kliencie.
Systemy serwerowe i klienckie komunikuja˛ si˛e ze soba˛ na poziomie sieci, transmitowane sa˛ różnice treści podczas tworzenia
obrazu albo instrukcje dla tworzenia obrazu. Określone aplika-
zwi˛ekszony
ruch
w
cje (programy graficzne, itd.) moga˛ bardzo zwi˛ekszyć obciaże˛
nie sieci. W przypadku innych aplikacji (np. edytorów tekstu)
sieci
ruch sieciowy może si˛e jednak także zmniejszyć, ponieważ podczas zapisywania nie sa˛ regularnie transmitowane pliki, lecz tylko
zmiany (wpisy z klawiatury i zmiany na ekranie).
Na Terminal - Server nie wszystkie aplikacje moga˛ bezawaryjnie,
pracować, zwłaszcza jeśli chodzi o aplikacje windowsowe, moga˛
dostosowywanie wykorzystywanych aplikacji
istnieć takie, które podczas pracy otwieraja˛ pliki systemowe do
zapisu i tym samym sa˛ one zablokowane dla innych użytkowników. Problemy te można cz˛esto rozwiazać
˛
dzi˛eki pracy administracyjnej.
Tablica 3.73: Wybrane wady Terminal - Servers i Thin Clients
Połaczenie
˛
z Terminal - Servers można realizować za pomoca˛ różnych typów klientów.
Klienty Fat
Chodzi tu o pełnowartościowa˛ stacj˛e robocza.˛ Dost˛ep do Terminal - Server odbywa si˛e poprzez specjalne oprogramowanie dla Terminalserver - Client.
334
Rysunek 3.44: Wykonywanie aplikacji X w kliencie Fat
Thin Clients
Chodzi tu o systemy komputerowe złożone z minimalnego wyposażenia. Klienci pobieraja˛
system operacyjny badź
˛ to z Flash - EPROM badź
˛ bootuja˛ si˛e poprzez sieć (pxe, tftp, nfs) (patrz
rys. 3.46).
Rysunek 3.45: Uruchamianie aplikacji X i aplikacji windowsowych w Thin Client
335
336
Rysunek 3.46: Bootowanie systemu linuksowego poprzez sieć
Poniżej przedstawiliśmy pokrótce kilka wybranych rozwiazań
˛
dla środowisk terminalowych.
3.16.3 Linux-Terminal-Server-Project
Linux Terminal Server Project (LTSP)125 umożliwia bootowanie systemów klienckich do systemów serwerowych dzi˛eki wykorzystaniu wspaniałych możliwoś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 możliwości, poczawszy
˛
od korzystania z lokalnych drukarek a skończywszy na
lokalnym uruchamianiu programów. Dzi˛eki projektowi LTS można korzystać z tanich stacji roboczych, jako terminali serwera linuksowego badź
˛ uniksowego. Klienci moga˛ pracować zarówno
w trybie tekstowym, jak i graficznym.
Bootowanie systemów klienckich inicjowane jest przez serwer i odbywa si˛e poprzez sieć.
W tym celu we wszystkich systemach klienckich należy zastosować specjalne Boot - ROMS,
które można umieścić w obecnych adapterach sieciowych. Zarzadzanie
˛
danymi użytkowników,
wzgl˛ednie danymi kont odbywa si˛e za pomoca˛ tradycyjnych narz˛edzi dostarczanych wraz z GNU
/ Linux.
Poniżej przedstawiliś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˛eści składowe jako Wolne Oprogramowanie.
Najważniejsza˛ różnica˛ w porównaniu z LTSP jest uproszczone zarzadzanie
˛
oparte na LDAP.
Cała konfiguracja i profile uż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, że każdy użytkownik ma dost˛ep do swojego, specjalnego profilu, aplikacji i danych z każdej stacji roboczej. Administrowanie może odbywać si˛e poprzez Frontend
125
126
http://www.ltsp.org/
http://www.gonicus.de/
337
WWW o nazwie Gosa. Frontend ten umożliwia dost˛ep do wymaganych struktur LDAP i zarza˛
dzanie nimi. Obydwa rozwiazania
˛
udost˛epniane sa˛ na licencji GPL.
GOto umożliwia także pełne bootowanie systemów Thin Client poprzez sieć, z odpowiednich
serwerów. Proces bootowania rozszerzony został o standardowy protokół PXE, ponieważ odpowiednie opcje bootowania sa˛ obecnie obsługiwane przez coraz wi˛eksza˛ ilość kart sieciowych,
wskutek czego w wielu przypadkach nie jest już wymagane stosowanie Boot - ROM. Oprócz
Thin Clients obsługiwane sa˛ także Fat Clients. Zarzadzanie
˛
Fat Clients może odbywać si˛e w taki
sam sposób, jak zarzadzanie
˛
Thin Clients. Po pierwszym zainstalowaniu Fat Clients można je
automatycznie uaktualniać.
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łużacym
˛
do zarzadzania
˛
konfiguracja˛ i
użytkownikami.
Jeśli chodzi o różnic˛e wzgl˛edem LTSP, to jest ona taka sama, jak w przypadku rozwiaza˛
nia GOto i polega na tym, że uruchamianie systemów jest realizowane nie tylko poprzez BOOTP, lecz także poprzez PXE. Oprócz tego udost˛epniane sa˛ specjalne narz˛edzia do kontroli sesji
użytkowników, dzi˛eki czemu podczas wyłaczania
˛
klientów nie powstaja˛ „martwe procesy“. Dodatkowo możliwy jest dost˛ep do lokalnych urzadzeń
˛
podłaczonych
˛
do Thin Client, takich jak
CDROM, Floppy, karta dźwi˛ekowa czy drukarka (administrator może jednak ograniczyć ten
dost˛ep). Wspólne zarzadzanie
˛
konfiguracja˛ i uż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 skalowalność a w razie
potrzeby można w prosty sposób zintegrować z systemem dodatkowe serwery bootowania i aplikacji.
3.16.4 Usługi terminalowe NX
Produkt NX firmy Nomachine128 z Włoch jest dość nowa˛ technologia˛ serwerów terminalowych
oparta˛ na Linuksie. Jest to produkt komercyjny. Po wieloletnim okresie rozwoju oprogramowania, developerom udało si˛e zaimplementować bardzo wydajny kompresor dla protokołu X 127
128
http://www.univention.de/
http://www.nomachine.com/
338
Window. Jak wiadomo system X - Window zaprojektowany został tak, że jest on przezroczysty
dla sieci. Oznacza to, że wyświetlanie każdej aplikacji może odbywać si˛e na odległym ekranie.
Niestety używany protokół nie jest szerokopasmowy. Dlatego dotychczas stosowanie protokołu
X - Window miało sens tylko w LAN. Wprawdzie było już kilka prób, poprawienia jego przydatności dla WAN za pomoca˛ Caching Events i Bitmaps badź
˛ poprzez kompresj˛e samego protokołu
(Low band X), jednak uzyskane wyniki okazały si˛e być 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 może, oprócz protokołu X - Window, wydajnie transmitować do NX - Client
także Microsoft RDP i protokół Frame - Buffer przegladarki
˛
VNC. NX - Client może pracować
w Linuksie, Windows, w PDAs iPAC i Zaurus.
Oprócz wydajnej transmisji treści ekranu, technologia NX umożliwia także dost˛ep do lokalnego sytemu plików i przekaz danych audio. Nie jest jeszcze możliwe przekierowanie interfejsu
szeregowego. Jeśli chodzi o technologi˛e, sytem ten opiera si˛e w znacznym stopniu na składnikach Open Source. Wszystkie składniki umożliwiajace
˛ kompresj˛e sa˛ udost˛epniane na licencji
GPL. Cała komunikacja jest szyfrowana za pomoca˛ tunelu SSH. Podobnie, jak w przypadku
Citrix Metaframe możliwe jest „publikowanie“ tylko okna pojedynczej aplikacji. Dzi˛eki temu
można bardzo elastycznie integrować świat aplikacji windowsowych i linuksowych. Umoż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 skalowalność. Server aplikacji nie jest przy tym dodatkowo obciażany
˛
przez kompresj˛e
danych. Nie dochodzi do konfliktów pomi˛edzy wersjami aplikacji i serwerem kompresji.
Interesujacy
˛ jest model licencji, ponieważ nie zależy ona od ilości klientów, lecz od iloś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 szerokość pasma pomi˛edzy klientem a serwerem wynosi około 10 do 20 kB/s. Dzi˛eki oddzieleniu logiki
aplikacji od interfejsu użytkownika na Terminal - Servers, podczas odwoływania si˛e do serwera
plików, serwera wydruku, serwera bazy danych, etc., Backbone jest silniej obciażony
˛
w porównaniu z klasycznymi środowiskami Client - Server.
Główna˛ cz˛eścia˛ składowa˛ technologii Terminal - Server sa˛ serwery, w których zainstalowane
sa˛ aplikacje. Terminal - Server umożliwia równoległy dost˛ep wielu użytkowników w czasie se-
339
sji (Sessions), podczas których użytkownicy moga˛ uruchamiać aplikacje w chronionym obszarze pami˛eci. Ponieważ nieskonfigurowani użytkownicy posiadaja˛ wszystkie uprawnienia, należy
chronić system przed niezamierzonymi badź
˛ nieuprawnionymi akcjami ze strony użytkowników.
W tym celu można skorzystać ze środków znanych z administrowania w NT, takich jak profile
oparte na serwerze, stosowanie Policies i ustawień NTFS - Security wzgl˛edem plików i katalogów, które gwarantuja˛ wymagane bezpieczeństwo.
Ponadto w środowisku Terminal - Server szczególna˛ rol˛e przypisać można testom aplikacji,
które maja˛ umożliwić przeprowadzenie Server - Sizing. Dlatego nieodzowna jest wiedza o tym,
◦ jaka jest wydajność procesora
oraz
◦ ile pami˛eci operacyjnej wymaga aplikacja,
◦ ilu użytkowników korzysta jednocześnie z danego programu,
◦ czy program jest 16 bitowa˛ aplikacja˛ DOS,
◦ czy aplikacja w ogóle może pracować w trybie multiuser.
Windows Termina Service oferowana jest dla Windows NT 4 jako oddzielna odmiana produktu
(„Terminal Server Edition“, TSE). W przypadku Windows 2000 usługa ta mieści si˛e w każdym
jego wariancie.
O ile nie uż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 (takż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, że użytkownik chce si˛e połaczyć
˛
z określonym serwerem. Powoduje to komplikacje, gdy:
◦ serwer nie jest dost˛epny
albo
340
◦ serwer jest przeciażony
˛
Zaradzić temu można stosujac
˛ produkt Metaframe firmy Citrix. Za pomoca˛ Metaframe można
łaczyć
˛
logicznie wiele Termina Servers w Serverfarm. Uż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 należy wyraźnie stwierdzić, że mimo wszystkich omówionych przykładów
powyższa ocena nie oddaje całej złożoności rozwiazania
˛
Citrix, ani jego możliwości. Nakreśliliśmy zaledwie podstawowa˛ zasad˛e działania tej technologii. Jednak w tym miejscu jest to
całkowicie wystarczajace,
˛ aby wskazać możliwość uruchamiania aplikacji windowsowych na
desktopie Linuksa za pomoca˛ Citrix Metaframe.
Aby zagwarantować t˛e funkcjonalność, Mainframe zawiera tak zwany protokół ICA (Independent Computer Architecture). Wymagany klient ICA istnieje dla
◦ wszystkich systemów operacyjnych Windows
◦ DOS
◦ Java
◦ wielu odmian Uniksa (takż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 takż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.
341
Wersj˛e XP należy traktować jako wariant strategiczny, ponieważ wersja 1.8 w najbliższej przyszłości przestanie być wspierana.
Metaframe można spotkać w dużych środowiskach z duża˛ ilościa˛ serwerów, gdyż środowiska te wymagaja˛ inteligentnego „Load Management“ (przydzielanie obciażenia).
˛
Jeśli z wielu
Terminal Servers stworzona zostanie tak zwana farma serwerów, wówczas możliwe jest przydzielanie obciaż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 obciażenia
˛
przyczynia si˛e do zapewnienia wydajności i dost˛epności aplikacji
w całym systemie, ponieważ użytkownicy nie sa˛ kierowani do serwera, na którym nastapiła
˛
awaria. Jeśli serwery współpracuja˛ z programem oceniajacym
˛
obciażenie,
˛
wówczas w Metaframe
XP nast˛epuje przekazanie wyniku z danego serwera do punktu gromadzenia danych (Data Collector) i zapami˛etany dla nadchodzacych
˛
zapytań. Jeśli udost˛epniana aplikacja wywoływana jest
poprzez klienta ICA, wówczas punkt gromadzenia danych wyszukuje i określa serwer, który w
momencie nadejścia zapytania posiada najwi˛eksza˛ wydajność 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 badź
˛ dwupro-
342
cesorowych, dla odpowiednich serwerów można różnie określać zasady przydzielania. Gdy zasada określajaca
˛ obciażenie
˛
dla aplikacji udost˛epnianej przez maszyn˛e dwuprocesorowa˛ ustala
jej pełne obciażenie
˛
w przypadku 50 użytkowników, oznacza to, że maszyna jednoprocesorowa
osiagnie
˛
pełne obciażenie
˛
już przy 25 zalogowanych użytkownikach. Dzi˛eki takiemu „Tuning“
można wyrównywać różnice w osprz˛ecie.
Jeśli chodzi o technologi˛e Terminal Server, celowe jest wcześ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 umożliwienie obsługi mobilnych użytkowników (stabilne File Services)
◦ Windows Terminal Server drukuja˛ poprzez RPC do windowsowych serwerów wydruku,
co ma na celu odciażenie
˛
Terminal Server
◦ konto użytkownika w domenie Windows uzupełniane jest o dodatkowe, specyficzne parametry Terminal Server.
◦ nie każda aplikacja windowsowa umie pracować w Terminal Servers (należy to sprawdzić,
nakład zwiazany
˛
z integracja).
˛
3.17 High-availability – systemy wysokiej niezawodności
Aby móc przedstawić możliwości spełnienia przez Open Source Software wymagań wzgl˛edem
wysokiej niezawodności, należy najpierw scharakteryzować zakres zadań.
3.17.1 Cele
Wysoko niezawodne instalacje udost˛epniaja˛ usługi w taki sposób, że w czasie ich awarii parametry takie jak minimalna pojemność, przepustowość i inne nie moga˛ zejść poniżej określonych
granic. Jest to wymagane z wielu powodów:
◦ usługi sa˛ niezb˛edne wewnatrz,
˛ np. gdy sa˛ one podstawa˛ dla działań wielu użytkowników a
ich awaria doprowadziłaby do powstania szkód finansowych.
◦ usługi sa˛ ważne ze wzgl˛edów bezpieczeństwa a ich awaria mogłaby zagrażać interesom
narodowym
343
◦ usługi musza˛ być 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 państwa. Oznacza to z jednej strony, że
stale ma miejsce komunikacja z systemami BackEnd (np. bazami danych) albo że stale moga˛
napływać nowe wnioski, które nie moga˛ zginać.
˛ Z drugiej strony zwiazane
˛
z tym dłuższe czasy
dost˛epności usług oznaczaja˛ także nowe wyzwania wzgl˛edem systemów Frontend. Nie tylko
maja˛ zmniejszyć si˛e koszty i czas obsługi, lecz także wizerunek administracji publicznej może
ulec znacznej poprawie dzi˛eki takim inicjatywom. Jednak niedost˛epność danych usług spowodowałaby efekt przeciwny do zakładanego.
3.17.2 „Pi˛eć dziewiatek”
˛
a rzeczywistość
Systemy wysokiej niezawodności (systemy HA, patrz angielskie wyrażenie high availability)
można podzielić 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 być udost˛epniany przez cała˛ dob˛e, pokazaliśmy
w nast˛epujacej
˛ tabeli:
Maksymalna awaryjność w
Maksymalna awaryjność 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˛epność
99,999%
5 minut
Tablica 3.75: Wymagania wzgl˛edem systemu HA
Powyższe, cz˛esto cytowane liczby nie sa˛ jednak realistyczne. Wi˛ekszość umów serwisowych
(SLAs, service level agreements) zawiera zdefiniowane czasy konserwacji określajace,
˛ jak długo
dana usługa b˛edzie niedost˛epna. Jednak czas ten nie jest traktowany jako awaria, co znaczy, że w
wi˛ekszości przypadków wysoka dost˛epność określana jest w oparciu o niezaplanowane awarie.
Jako przykład może posłużyć wymaganie stawiane bazie danych SAP, że powinna być ona
344
dost˛epna w godzinach urz˛edowania biura, tj. od 7.00 do 19.00. Dzi˛eki możliwości pracy nad
systemem poza wspomnianymi godzinami, możliwe jest znacznie łatwiejsze i tańsze spełnienie
wymagań, niż w nierealnym przypadku określajacym
˛
5 minutowy czas awarii w ciagu
˛ roku przy
pracy 24 x 365.
3.17.3 Sposób podejścia do problemu
Wysoka˛ niezawodność uzyskuje si˛e chroniac
˛ zasoby przed nadmiarem informacji i kontrolujac
˛
ich funkcjonalność. W przypadku nieprawidłowego zachowania jednego ze składników, inny
składnik automatycznie przejmuje świadczenie usługi. W tym momencie dochodzi jednak do
naruszenia redundancji albo nawet jej zaniku, dlatego bezzwłocznie należy przystapić
˛ do prac
naprawczych. Systemy HA wymagaja˛ bardzo dużego wsparcia administracyjnego i same z siebie nie b˛eda˛ pracować. Ważna˛ miara˛ jakoś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 może wystapić
˛ na każdym poziomie.
P OZIOM
ABSTRAKCJI
środowisko użytkownika badź
˛ 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 już dziś standardem (mirroring, RAID1;
RAID5 obecnie już si˛e prawie nie spotyka) i jest dost˛epna dla wszystkich platform. W przypadku
innych składników sprawa jest już trudniejsza. Redundantnie skonfigurowane karty sieciowe sa˛
rzadko obsługiwane. W centrum naszych rozważań znajduje si˛e obsługa redundancji sprz˛etowej
przez system operacyjny. Własnościowe systemy Unix i oczywiście także Mainframes wykazuja˛
tu znaczne zalety, którym według oceny autorów poradnika systemy Open Source nie b˛eda˛ w
stanie sprostać w najbliższym czasie.
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˛
możliwość traktowania wielu systemów jako jeden system. Niektóre aplikacje tego nie potrzebuja,˛ ponieważ sa˛ przydzielane przez serwer do wielu komputerów, na których pracuja˛ i awaria
jednego z nich nie powoduje problemów.
Jeśli wysoka niezawodność ma być dost˛epna na jednym poziomie abstrakcji, wówczas teoretycznie jest ona wystarczajaca
˛ dla wszystkich niższych poziomów abstrakcji. W praktyce siła
systemu HA i wynikajaca
˛ z niej niezawodność rośnie, gdy środki zwiazane
˛
z redundancja˛ zastosowane zostana˛ na możliwie wielu poziomach – ostatecznie bł˛edy moga˛ powstawać także w
podsystemie HA, co oznacza, że musi istnieć możliwość zastapienia
˛
go innym redundantnym
składnikiem.
W końcu nie wolno zapomnieć o najwi˛ekszym ź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 świadczonych, redundantnych
usług albo składników. Jeśli, np. wskutek bł˛edu administracyjnego, usuni˛etych zostanie kilkaset
GB, wówczas nie pomoże mirroring ani redundancja usług. Dane zostana˛ usuni˛ete ze wszystkich składników. Dlatego dobry Backup i Restore, a w pewnych okolicznościach także Disaster
Recovery w ramach planowania Business Continuity, sa˛ elementarnymi cz˛eściami składowymi
rozwiazania
˛
HA.
3.17.4 Kategorie systemów HA
O ile redundancja zawsze jest podstawowa˛ zasada˛ wysokiej niezawodności, istnieja˛ róż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 uruchomić. Jeś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 pracować na
wielu maszynach w taki sposób, że wygladaj
˛ a˛ one z zewnatrz
˛ jak jeden system, w którym
w razie awarii pojedynczych maszyn jest ona przezroczyście niwelowana. Najbardziej zna-
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 można
przede wszystkim stosować w przypadku usług bez stanu. Cz˛esto używana jest ona do
realizacji FrontEndu, podczas gdy BackEnds pracuja˛ na urzadzeniu
˛
Failover.
◦ Jeśli chodzi o bazy danych, do Disaster Recovery cz˛esto stosuje si˛e takż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ównież do uaktualnienia stanu bazy danych.
Dzi˛eki powyższemu podziałowi na kategorie można ustalić, jakie rozwiazania
˛
wysokiej niezawodności istnieja˛ i gdzie sensowne jest wykorzystywanie produktów Open Source.
Rysunek 3.48: Rozwiazania
˛
HA
Niedostateczne stosowanie klastrów pracujacych
˛
z niewielka˛ ilościa˛ dużych, całkowicie redundantnie zoptymalizowanych maszyn, spowodowana jest przede wszystkim tym, że stoso-
347
wany, specjalistyczny osprz˛et cz˛esto nie jest w wystarczajacy
˛ sposób obsługiwany przez system
operacyjny.
Open Source Software można stosować przede wszystkim w obszarze farm serwerów, najlepiej w systemach bez duż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. Można je tu zastosować, o ile wymagania SLA nie sa˛ bardzo wysokie (np. 99,9% czasu pracy biur lub inne). W takim przypadku
wysoka niezawodność jest najcz˛eściej gwarantowana poprzez architektur˛e Failover. Istnieja˛ jednak także możliwości tworzenia klastrów na poziomie Middleware (np. wykorzystujac
˛ JBoss).
Wysoko niezawodne bazy danych Open Source nie istnieja.˛ Jednak można tu zaplanować
wykorzystanie własnościowego oprogramowania (np. Oracle RAC) w Linuksie i cz˛eściowo uzyskać w ten sposób znaczne oszcz˛edności, jeśli chodzi o koszty osprz˛etu.
3.17.5 Komercyjne oprogramowanie HA
Oprogramowanie HA jest domena˛ świata uniksowego i Mainframe. Windows DataCenter uznawany jest z reguły za niewystarczajace
˛ dla aplikacji mission - critical.
Na poziomie systemu operacyjnego każdy z duż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 ilość maszyn
32
16
8
obsługa wielu instancji
aplikacji
tak
tak
tak
partycjonowanie
tak
tak
tak
Failover istniejacych
˛
połaczeń
˛
TCP
nie
tak
tak
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
˛ komercyjnego oprogramowania HA
Jak już wspomnieliśmy, Oracle RAC jest w obszarze baz danych najważniejsza˛ możliwościa˛ udost˛epniania wysokiej niezawodności także na poziomie Middleware. Rozwiazanie
˛
to jest
dost˛epne dla własnościowych systemów Unix, Linuksa oraz serwera windowsowego.
3.17.6 Rozwiazania
˛
Open Source dla systemów HA
Ś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 może to być tylko wskazanie potencjalnej przydatności. W każdym projekcie trzeba na nowo określić architektur˛e i sprawdzić sposób wykorzystania poszczególnych Tools. Autorzy analizy widza˛ konieczność właczenia
˛
do każdego projektu doświadczonych specjalistów.
Wiele z wymienionych poniżej Tools udost˛epnianych jest oczywiście także przez firmy. W
Niemczech niemal wszystkie linuksowe Tools udost˛epnia SuSE. Pomoc techniczna˛ oraz wsparcie podczas tworzenia projekty zapewnia wiele firm, m.in. takż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ównież dost˛ep multi - path, tzn. jednoczesne podłaczenie
˛
podsystemów dysków do różnych komputerów. Jest to wymagane dla dysków gromadzacych
˛
dane i aplikacje w
349
architekturze Failover. Dyski systemowe musza˛ być podłaczone
˛
zawsze dokładnie do jednego
komputera.
Wraz z LVM pojawił si˛e funkcjonalny Volume Manager. ext3 stał si˛e domyślnym systemem
plików z Journaling (patrz także rozdział 3.11.4).
3.17.6.2
Failover za pomoca˛ heartbeat
Architektura Failover dla systemów linuksowych może być realizowana za pomoca˛ heartbeat.
heartbeat obsługuje definicje grup zasobów (usługi, systemy plików oraz adresy IP), które w
przypadku awarii moga˛ zostać uruchomione na innym serwerze. Nast˛epuje przy tym przej˛ecie
istniejacych
˛
stanów sesji.
Ponieważ Linux nie obsługuje konfiguracji Multi - Path kart sieciowych, kontrola dost˛epności
usługi może być przeprowadzana poprzez różne kanały komunikacyjne (szeregowo i sieć).
Cz˛esto jest tak, że w przypadku awarii usługi powinno nastapić
˛ 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 być moduł o
nazwie „hangcheck - timer“. Wybór modułu należy pozostawić doradcom, którzy planuja˛ konkretne zastosowanie architektury HA.
Każdy projekt HA powinien wziać
˛ pod uwag˛e także ograniczenia rozwiazania
˛
Failover z rodziny Open Source. Nie istnieje klastrowy sytem plików, maksymalna ilość maszyn w klastrze
Failover nie powinna być wi˛eksza niż 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ównież opcji do Disaster Recovery.
heartbeat jest cz˛esto stosowanym modułem; projekt Linux - HA przyznaje, że wspomniany
moduł wykorzystywany jest w zastosowaniach produkcyjnych w tysiacach
˛
instalacji na całym
świecie. Stanowi on rdzeń rozwiazań
˛
HA oferowanych przez przodujacych
˛
producentów oprogramowania linuksowego (SuSE, Conectiva, Mandrake). Jednym ze znanych uż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, możliwe było stworzenie niezawodnego systemu wysokiej
niezawodności. Poniższy rysunek przedstawia zastosowane tam rozwiazanie
˛
i jego architektur˛e.
129
http://linux-ha.org/heartbeat/
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 niezawodnoś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 już dost˛epny ta˛ droga˛ komunikacji, wówczas serwer Failover automatycznie przejmuje wirtualne adresy i odpowiednie usługi. Oprócz wysokiej niezawodności,
dzi˛eki programowi DRBD, uzyskiwany jest mirroring Raid-1 partycji badź
˛ 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 może być tańsza˛ alternatywa˛
realizujac
˛ a˛ okreś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 użytkownika końcowego systemy te nie sa˛ widoczne. Cała instalacja wyglada
˛ dla niego, jak jeden duż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łaczyć
˛
obydwie w/w technologie skorzystać można z projektu UltraMonkey albo produktu Open Source firmy Red Hat o nazwie Piranha.
130
http://www.complang.tuwien.ac.at/reisner/drbd/
351
LVS stosowany jest w procesach produkcyjnych wielu firm. Za pomoca˛ LVS gwarantowana
jest wysoka dost˛epność bardzo duż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 można realizować Java Servlets i Java Server Pages (JSP). Dzi˛eki swojemu Feature służacemu
˛
do rozkładania
obciażenia,
˛
obsługuje on Application Clustering.
Bazy danych Open Source nie oferuja˛ rozwiazań
˛
wysokiej niezawodności. Najcz˛eściej jednym z głównych problemów jest brak możliwości wykonywania Online - Backup. Jednak dla
systemów linuksowych firma Oracle udost˛epnia swoja˛ opcj˛e RAC, co pozwala na poczynienie
znacznych oszcz˛edności w obszarze osprz˛etu i obsługi technicznej.
3.17.6.5
Compute Cluster
Gwoli rzetelności należy w tym miejscu wspomnieć jeszcze także o rozwiazaniach
˛
HA w ramach
High Performance Computing, nawet jeśli ten obszar zastosowania interesuje administracj˛e publiczna˛ jedynie w ograniczonym stopniu. Beowolf był pierwszym projektem Compute - Cluster
dla Linuksa i także dziś jest on nadal najcz˛eściej stosowany. Job Scheduling wewnatrz
˛ klastra
udost˛epniane jest poprzez Portable Batch System (PBS) albo MAUI Scheduler.
Rozdział 4
Ocena wydajności ekonomicznej
4.1 Wprowadzenie
Jak pokazuje dyskusja nt. dost˛epnych na rynku analiz dotyczacych
˛
TCO 1 , dokonanie oceny
ekonomicznej zamierzeń 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 niemalże nie do rozwiazania.
˛
W przypadku analizy obejmujacej
˛ wiele zagadnień oraz zawierajacej
˛ wiele wniosków, która
bez watpienia
˛
ma miejsce w przypadku porównywania kosztów platform Microsoft i OSS /
COLS, do najistotniejszych zadań należy zestawienie podobieństw badanych obiektów, jak też
uwzgl˛ednienie prawidłowego zakresu analizy. Wynik waskiej
˛
oceny oddzielnych aspektów niekoniecznie musi przenosić 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“. Ponieważ powyż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 niż na przykład w przypadku aplikacji klienckich, nie można bezpośrednio uzyskać informacji odnośnie opłacalności ekonomicznej w obszarze aplikacji lub desktopów.
Podczas wykonywania analizy konieczne jest także uwzgl˛ednienie struktur użytkowników.
Szczególnie ważna dla oceny ekonomicznej migracji jest wielkość organizacji oraz różne wyjściowe scenariusze środowiska informatycznego. Cz˛esto można zauważyć, ż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 WYDAJNOŚCI EKONOMICZNEJ
353
środków i aby mogła działać nie jest wymagane intensywne kształcenie użytkowników. Z drugiej strony niezawodne działanie w przypadku infrastruktur centrów obliczeniowych, dużych i
/ lub specjalizowanych urz˛edów oraz centrów danych realizujacych
˛
Service Level Agreements
wymaga od pracowników wyższego poziomu wykształcenia, uregulowań organizacyjnych na
wypadek awarii i sytuacji kryzysowych, jak również cz˛esto innego osprz˛etu.
Biorac
˛ pod uwag˛e niniejsze warunki brzegowe, dla dokonania oceny infrastruktury i kosztów
konieczne jest spojrzenie wielowymiarowe. Podczas przygotowań do oceny kosztów informatyzacji obowiazuje
˛
zasada, że istotnym elementem wzrostu opłacalności może być przede wszystkim czynnik ludzki, organizacyjny i racjonalizacja w administracji publicznej. Jednak oprócz
tego również odpowiednio zaprojektowana strategia informatyczna może przyczynić si˛e do podniesienia opłacalności ekonomicznej.
Na ogólna˛ ocen˛e ekonomiczna˛ informatyzacji silnie wpływa:
◦ stopień w jakim korzystne cenowo, standardowe produkty realizuja˛ wymagane funkcje
◦ jakość, możliwość rozwoju i możliwość 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 łańcuchem powstawania kosztów
◦ dobra (wewn˛etrzna albo zewn˛etrzna) organizacja pomocy technicznej, jak również duża
wiedza (Know - how)
◦ ekonomiczna długość życia produktów
◦ koszty i wydajność procesów
oraz
◦ konkurencja w dziedzinie produktów i usług.
Dopiero optymalne współdziałanie wszystkich powyższych czynników przez dłuższy czas, warunkuje i wpływa na łaczn
˛ a˛ ocen˛e opłacalności, dlatego uproszczona ocena pojedynczych koszów z reguły nie oddaje całości w prawidłowy sposób.
Oprócz uzyskania informacji o kosztach i ich porównania, ważnym aspektem oceny ekonomicznej jest także ocena możliwych wartości użytkowych. Szczególnie w tym obszarze ważna˛
354
rol˛e dla dokonania całościowej oceny obejmujacej
˛ zarówno sytuacj˛e wyjściowa,˛ jak też sytuacj˛e w przyszłości, odgrywaja˛ strategiczne przemyślenia oraz prognozowane zalety. Przykład:
Wyższe koszty pojedynczego składnika moga˛ uzyskać lepsza˛ ocen˛e strategiczna˛ wskutek uzyskania niezależności od producenta oraz lepszej pozycji przetargowej w przypadku cen licencji
na oprogramowanie, co z kolei może prowadzić do wyraźnie korzystniejszego ogólnego wyniku.
Z tych powodów zarówno przedstawiana przez nas metoda, jak i wynik, moga˛ służyć jedynie
za pomoc podczas ustalania własnej oceny ekonomicznej oraz podczas formułowania własnej
strategii informatyzacji.
4.2 Metodologia
Wprawdzie zasadniczo możliwe jest funkcjonalne i jakościowe porównanie różnych rzeczy, jednak wymaga to analizy kosztów i zysków, w której należy przeciwstawić oczekiwany wzrost
produktywności oczekiwanym, dodatkowym kosztom.
Nie mogliśmy jednak umieścić w niniejszym poradniku oceny produkcyjności w łańcuchu
powstawania kosztów informatyzacji, gdyż nie istnieja˛ odpowiednie neutralne, długookresowe
badania, zwłaszcza jeśli chodzi o administracj˛e publiczna.˛ Prawdopodobnie w oparciu o dzisiejsze doświadczenia i ze szczególnym uwzgl˛ednieniem tego, ż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 wyważonego wyniku. Z tych powodów ocena ekonomiczna zamieszczona w
poradniku migracyjnym koncentruje si˛e na bezpośredniej analizie kosztów i analizie korzyści.
4.2.1 Analiza kosztów
Aby obliczyć pieni˛eżne skutki migracji posłużyliśmy si˛e metoda˛ obliczania wartości kapitału.
Jest to metoda dynamiczna i ocenia projekty inwestycyjne według ich wartości kapitałowej, tzn.
poprzez zbliżone do rzeczywistości zebranie wszystkich strumieni finansowania zwiazanych
˛
z
inwestycja˛ (wpływy i wydatki; wpływajace
˛ na budżet i nie wpływajace
˛ na budżet), skoncentrowane we wspólnym punkcie odniesienia. Wpływy i wydatki majace
˛ zwiazek
˛
z migracja,˛ można
zaplanować na pi˛eć lat z góry. Dla przyszłych wartości podaliśmy aktualna,˛ czasowa˛ wartość,
dyskontujac
˛ ja˛ w oparciu o stop˛e procentowa˛ ustalona˛ przez Ministerstwo Finansów.
355
4.2.2 Analiza korzyści
W przypadku, gdy podczas zastanawiania si˛e nad decyzja˛ nie można wziać
˛ pod uwag˛e skutków
finansowych, należy skorzystać z analizy korzyści. Ocenia ona pojedynczo i niezależnie od siebie
ważne kryteria celu, by ostatecznie połaczyć
˛
je w ocen˛e ogólna.˛ Sklasyfikowaliśmy tu według
skali ocen tak zwane „mi˛ekkie“ czynniki.
Zalecamy, aby ocen˛e wyników uzyskać w dwóch krokach:
1. Pierwszeństwo maja˛ wyniki analizy kosztów. Wskaźnik rentowności, który wyraża si˛e dodatnia˛ wartościa˛ kosztów, wynikać b˛edzie z kosztów oraz oszcz˛edności zwiazanych
˛
z migracja˛ liczonych zgodnie z w/w metoda.˛
2. Z rezultatów analizy korzyści wynika wskaźnik konieczności i strategia. W ramach projektu migracyjnego należy je traktować jako majace
˛ mniejsze znaczenie.
Ten drugi krok potrzebny jest przede wszystkim w przypadku, gdy z punktu widzenia
kosztów ocena ekonomiczna jest niewystarczajaca
˛ badź
˛ nie dostarcza jednoznacznej odpowiedzi na pytanie o rentowność. W oparciu o kryteria konieczności, wzgl˛ednie strategii
projekt może w każdej chwili uzyskać wysoki priorytet wykonania, niezależnie od kryteriów kosztów.
4.2.3 IT-WiBe 21
W niemieckiej administracji oceny ekonomicznej należy dokonać 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 wymagań zwiazanych
˛
z informatyzacja,
˛ Rzadowy
˛
Urzad
˛
Koordynacji i Doradztwa ds. Informatyzacji przy Ministerstwie Spraw Wewn˛etrznych Republiki
Federalnej Niemiec (KBSt) opracował już w 1992 roku instrukcj˛e post˛epowania pod tytułem
„Zalecenia odnoś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 wielkości wpływu (selekcja kryteriów)
◦ przenoszenie / ocena danych
356
◦ ustalenie wskaźników
Rysunek 4.1: Metodologia IT-WiBe
IT - WiBe jest procedura,˛ w której, inaczej niż w przypadku metodyki TCO, ocena nie jest
dokonywana tylko z punktu widzenia kosztów, lecz uwzgl˛edniane sa˛ także możliwe oszcz˛ednoś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 budżecie) niemożliwe, do analizy różnicy kosztów należy zastosować
metod˛e uproszczona˛ – matryc˛e kosztów migracji.
Ten sposób post˛epowania nie obejmuje kosztów i oszcz˛edności wynikajacych
˛
z wyselekcjonowanych kryteriów, lecz łaczy
˛
je w kategorie: osprz˛et, oprogramowanie i obsługa. W kategoriach tych należy ujać
˛ pi˛ecioletnie koszty zaopatrzenia3 i dalsze koszty, jak również możliwe
3
Takie obszary kosztów, jak koszty wprowadzenia i dalsze koszty mieszcza˛ w sobie, podobnie jak w przypadku
357
oszcz˛edności. Ogólny widok pokazuje wszystkie lata i kategorie. Ponadto, podobnie jak w przypadku WiBe21, ocena rentowności ustala wartość kapitału zdyskontowana˛ do punktu odniesienia.
Dzi˛eki temu praktycy w urz˛edach otrzymuja˛ do r˛eki instrument, który umożliwia łatwe i
szybkie przygotowanie wolumenu kosztów projektu uwzgl˛edniajacego
˛
jego dalsze koszty oraz
oszcz˛edności, jak również przygotowanie oceny rentowności 4.
4.2.5 TCO
Podstawowa˛ zasada˛ oceny TCO jest podział wszystkich kosztów danego systemu informatycznego na dwie grupy: koszty bezpośrednie i koszty pośrednie. Pod poj˛eciem kosztów bezpośrednich należy rozumieć wszystkie koszty, które zapisywane sa˛ w budżecie. Wspólna˛ cecha˛
kosztów bezpośrednich jest to, że można je zmierzyć w jednostkach pieni˛eżnych. Druga˛ duża˛
grup˛e stanowia˛ koszty pośrednie, nieujmowane w budżecie. Zalicza si˛e do nich czasy bezczynności, w których planowo albo poza planem nie można używać ocenianych systemów. Czasy te
można zmierzyć, jednak nie bezpośrednio w jednostkach pieni˛eżnych. W tym celu konieczne jest
niepodważalne przeliczenie wypłacanego „nieefektywnie“ uposażenia albo utraconych obrotów.
Ponadto do kosztów pośrednich zalicza si˛e „bezproduktywna“
˛ prac˛e użytkowników koń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 także do ustalania kosztów migracji. Jednak ponieważ oceniane sa˛ tu wyłacznie
˛
aspekty zwiazane
˛
z kosztami i brak jest analizy rentowności, w której swoje
odbicie mogłyby znaleźć wszystkie omawiane aspekty kosztów, również te z WiBe21 i z matrycy
kosztów migracji, w ekonomicznej ocenie migracji ustalenie TCO nie znajduje zastosowania.
4.2.6 Porównywalność
W celu zagwarantowania porównywalności różnych ocen, ocen˛e ekonomiczna˛ należy przeprowadzić w dwóch scenariuszach:
◦ migracja pojedynczych lub wielu obiektów5 (migracja cz˛eściowa) w przypadku jasno
oszcz˛edności, nast˛epujace
˛ elementy: infrastruktura serwerów, aplikacje bazodanowe, Messaging / Groupware, aplikacje WWW, Office / Desktop i inne.
4
Patrz rozdział „Wymiar pieni˛eżny (operacyjny)“, rysunek „Matryca kosztów migracji z kategoriami kosztów i
obszarami zastosowań“.
5
Patrz rozdział 3.17.3 – rozdzielanie obiektów.
358
dajacych
˛
si˛e rozdzielić produktów albo grup produktów6
◦ całkowita migracja, tzn. migracja całego środowiska przetwarzania danych – serwerów,
klientów, infrastruktury, aplikacji specjalistycznych
Pod poj˛eciem migracji należy zasadniczo rozumieć dwie rzeczy:
◦ migracj˛e zast˛epujac
˛ a,˛ jako migracj˛e do całkiem nowego ś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 już produktów do ich
nowych wersji
Na potrzeby migracji obiektów migracyjnych należy skorzystać ze zredukowanego katalogu kryteriów przygotowanego specjalnie na wypadek migracji cz˛eściowej. Katalog ten zawiera kryteria
wdrożenia i pracy7 .
W przypadku całkowitej migracji należy stosować ogólne kryteria ocen IT - WiBe. Ponieważ
w wielu przypadkach migracja taka dotyczy także aplikacji specjalistycznych, z reguły oprócz
czynności migracyjnych zwiazanych
˛
z produktami standardowymi, konieczne b˛eda˛ także prace
programistyczne dotyczace
˛ specyficznych aplikacji. Zasady te stosuje si˛e głównie, gdy mamy do
czynienia z „wewn˛etrzna“
˛ migracja.˛ Jeśli migracja dotyczy tylko pojedynczych produktów albo
grup produktów (takich jak, np. MS Office), wówczas należy mówić o obiektach migracyjnych
i stosować specyficzny katalog kryteriów. Natomiast gdy chodzi o bardziej skomplikowany scenariusz (np. produkty MS dla komunikacji i biura, aplikacje specjalistyczne, etc), wtedy należy
stosować pełny katalog kryteriów WiBe.
Kolejny aspektem jest to, że porównawcza analiza wydajności ekonomicznej ma sens tylko
w przypadku dajacych
˛
si˛e porównać technicznie i funkcjonalnie alternatywnych rozwiazań.
˛
Za
porównywalne w sensie poradnika migracyjnego można uznać nast˛epujace
˛ obszary zastosowań
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 niż w przypadku ogólnego katalogu kryteriów, usuni˛ete zostały tu kryteria rozwoju i zastapione
˛
kryteriami wdrożenia.
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, bezpieczeństwo informatyczne jest jednoznacznie bardziej zagrożone w przypadku systemów windowsowych i obszaru tego nie da si˛e porównać.
Nawet przy wi˛ekszych nakładach nie można uzyskać porównywalnych zabezpieczeń obydwu
systemów, dlatego zrezygnowaliśmy z ekonomicznej oceny obszaru bezpieczeństwa.
4.2.7 Instalacja od podstaw a migracja
Jeśli ocena kosztów odbywa si˛e pod katem
˛
wprowadzenia nowych technologii, wówczas zasadniczo należy odróżnić instalacj˛e od podstaw od migracji procesów i systemów. Obowiazuje
˛
przy
tym „zasada lenia“ mówiaca
˛ o tym, że wykonanie instalacji od podstaw jest prostsze i tańsze, niż
migracja, w przypadku której trzeba zastapić
˛ różne, po cz˛eści historycznie obciażone
˛
architektury oraz przenieść dane tak, aby nie doszło do istotnego zakłócenia pracy albo do utraty niegdyś
używanych danych.
Ponieważ proces migracji zależy zasadniczo od punktu wyjścia, sformułowanie ogólnie obowiazuj
˛ acej,
˛
obejmujacej
˛ wszystkie koszty zasady, jest prawie niemożliwe. Podczas, gdy migracja
w niektórych przypadkach możliwa jest bez problemów i niemal bez nakładów, istnienie samodzielnie stworzonych aplikacji, które także trzeba zastapić,
˛
przeniesienie starych danych oraz
specjalnej struktury użytkowników i praw dost˛epu czy innych szczególnych właściwości prowadzi do powstania znacznych nakładów, które należy ocenić indywidualnie, w zależności od
urz˛edu – takż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:
360
◦ Open Source Software (OSS)
◦ Commercial Linux Software (COLS)
◦ Microsoft Software (MS)
Wyniki analizy daja˛ zasadniczy poglad
˛ na długofalowy rozwój kosztów każdego z alternatywnych rozwiazań.
˛
W celu stworzenia podstawy koniecznej dla podj˛ecia decyzji o migracji, trzeba
ostatecznie ogłosić koszty migracji. Korzystajac
˛ z dobrze obsadzonego, w tzw. mi˛edzyczasie,
sektora usług, bez problemu można zdobyć szacunkowe wyniki bezpośrednio w formie oferty
migracyjnej udost˛epnianej zarówno przez zewn˛etrznych, jak i wewn˛etrznych usługodawców
oraz skonfrontować je ze stwierdzonymi potencjałami.
Stosowana przy tym metoda uwzgl˛ednia niehomogeniczna˛ struktur˛e i różna˛ wielkość urz˛edów poprzez różne ocenianie danych. Pojedyncze kroki prowadzace
˛ do określenia pełnych kosztów poszczególnych alternatywnych rozwiazań
˛
przedstawiliśmy poniżej:
◦ zdefiniowanie obszarów zastosowań, które należy przeanalizować
◦ ustalenie czynników kosztów w analizowanych obszarach zastosowań
◦ ustalenie wartości czynników kosztów dla:
– małych urz˛edów
– średnich urz˛edów
– dużych urz˛edów
◦ ustalenie kosztów zwiazanych
˛
ze środkami racjonalizacyjnymi (narz˛edzia do zarzadzania
˛
systemem)
◦ ustalenie struktury kosztów analizowanych rozwiazań
˛
alternatywnych
◦ ustalenie istnienia możliwości porównania jakościowego i technicznego
◦ przeprowadzenie analizy scenariusza w przypadku migracji do:
– OSS Open Source Software
– COLS Commercial Linux Software
361
W wymiarze czysto pieni˛eżnym bezpośredni potencjał OSS / COLS wynika przede wszystkim
z oszcz˛edności zwiazanych
˛
z kosztami licencji (dalsze możliwoś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˛eżny (operacyjny)
4.3.1 Obszary zastosowań
W celu uzyskania wymownego wyniku, analiz˛e należy wykonać w ogólnym kontekście składajacym
˛
si˛e z wielu obszarów zastosowań. Całoś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
Powyższe wyliczenie, mimo tego, że nie jest kompletne, tworzy wspólny mianownik dla wi˛ekszości infrastruktur wykorzystywanych w urz˛edach.
362
4.3.2 Kategorie kosztów
Tworzenie możliwości porównania kosztów oraz znormalizowanie wyników ich oceny wymaga
stworzenia jednoznacznego modelu kosztów obowiazuj
˛ acego
˛
dla wszystkich obszarów zastosowań. Metoda użyta w poradniku migracyjnym opiera si˛e na tym, że nie jest dokonywana ocena
produkcyjności (patrz rozdział 4.2) ani też szczególna ocena wpływu awaryjności na produkcyjność czy koszty Outsourcingu:
◦ osprz˛et
– porównanie wymagań odnośnie oprzyrzadowania
˛
◦ oprogramowanie
– koszty licencji na oprogramowanie
– koszty konserwacji oprogramowania
– dodatkowe koszty systemów katalogowych
– dodatkowe koszty systemów zarzadzania
˛
i bezpieczeństwa
◦ obsługa
– administrowanie
– wsparcie (Support)
– opieka nad oprogramowaniem
– szkolenie
363
Rysunek 4.2: Matryca kosztów migracji z kategoriami kosztów i obszarami zastosowań
Wskazówka dotyczaca
˛ oceny czasu przestoju: Zgodnie z doświadczeniami szczególnie centrów obliczeniowych, można zasadniczo przyjać,
˛ że systemy linuksowe w porównaniu z systemami MS Windows sa˛ bardziej niezawodne i tym samym można założyć pełniejsze wykorzystanie mocy produkcyjnych pod Linuksem8 .
4.3.3 Własności użytych kategorii podmiotów publicznych
W kolejnych rozdziałach wypunktowane zostały właściwości urz˛edów różnego typu. Z powodu
dużych różnic w wyposażeniu informatycznym, z którymi mamy tam do czynienia, oraz orgarnizacji poszczególnych urz˛edów, poniższych punktów należy postrzegać jako zgrubna˛ pomoc
wskazujac
˛ a˛ ważne kryteria dla własnej analizy.
4.3.3.1
Małe urz˛edy
◦ użytkownicy: do 250
◦ osprz˛et: z reguły mała i tania platforma Intel
8
Potwierdza to także IDC w swoim opracowaniu przygotowanym na zlecenie Microsoft „Windows 2000 vs
Linux dla zastosowań w przedsi˛ebiorstwach“, 2002
364
◦ Backup i Recovery: tanie mechanizmy archiwizacji danych, wykorzystanie urzadzeń
˛
taśmowych albo systemów RAID
◦ personel: z reguły jeden administrator posiadajacy
˛ ogólna˛ specjalizacj˛e, jeden przedstawiciel
◦ organizacja obsługi informatycznej: jedna osoba badź
˛ grupa, niski stopień specjalizacji
◦ bezpieczeństwo i niezawodność: z reguły wymagania niskie do średnich
◦ zarzadzanie
˛
systemem: pojedyncze narz˛edzia (MS) albo skrypty (GNU / Linux)
4.3.3.2
Urz˛edy średniej wielkości
◦ użytkownicy: od 250 do 1.000
◦ osprz˛et: małe i duże systemy oparte na serwerach, platformy RISC oraz Intel, możliwe
także architektury zdecentralizowane, jak i centralne
◦ Backup i Recovery: w użyciu dedykowane Backup - Server oraz serwery archiwizujace,
˛
reguła˛ jest stosowanie technologii RAID
◦ personel: wielu administratorów pracujacych
˛
codziennie osiem godzin, specjalizacja, gotowość służby awaryjnej
◦ organizacja obsługi informatycznej: dział informatyki
◦ bezpieczeństwo i niezawodność: z reguły wymagania średnie do dużych
◦ zarzadzanie
˛
systemem: programistyczne narz˛edzia dedykowane (software distribution tools), Thin Clients, monitorowanie sieci i kontrola systemu
4.3.3.3
Duże urz˛edy / centra obliczeniowe9
◦ użytkownicy: ponad 1.000 (do 10.000)
◦ osprz˛et: tanie klastry firmy Intel, duże rozwiazania
˛
oparte na serwerach, dzielone architektury, centralne systemy Mainframe
9
W konkretnym przypadku należy wspólnie potraktować średnie oraz duże urz˛edy i analizować centra obliczeniowe tak, jak gdyby były szczególna˛ forma˛ urz˛edu.
365
◦ Backup i Recovery: centralny serwer Backup- / Disaster - Recovery z oprogramowaniem
Roboter albo Jukebox
◦ personel: administratorzy pracujacy
˛ osiem godzin dziennie, specjalizacja, gotowość służby
awaryjnej
◦ organizacja obsługi informatycznej: centrum obliczeniowe, w konkretnym przypadku lokalne zespoły administratorów
◦ bezpieczeństwo i niezawodność: wymagania wysokie do bardzo wysokich, stosowanie obszernych rozwiazań
˛
SAN
◦ zarzadzenie
˛
systemem: dedykowane narz˛edzia programistyczne (software distribution tools), Thin Clients, monitorowanie sieci i kontrola systemu.
4.4 Wymiar strategiczny
Oprócz bezpośredniej, pieni˛eżnej analizy całkowitych kosztów wdrożenia poszczególnych rozwiazań
˛
alternatywnych, istnieje także konieczność wykonania i uwzgl˛ednienia oceny strategicznej (w terminologi WiBe – wymiar strategiczny).
Konieczność przeprowadzenia oceny strategicznej wynika z wagi bezpośrednich skutków
czynnika strategicznego jakim jest „uzależ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 konkurencyjnościa:
˛
◦ lepsza jakość produktu
◦ niższe ceny produktu
◦ wyższy stopień innowacyjności.
Pomimo tego, że z reguły wszyscy producenci oprogramowania przypisuja˛ sobie zarówno wyższa˛ jakość produktu, jak też innowacyjność technologiczna,˛ w rzeczywistości rzadko można tak
generalizować. Zwłaszcza rozwój World Wide Web pokazuje, że na przykład Microsoft przez
długi czas „przesypiał“ t˛e najważniejsza˛ sfer˛e innowacyjności ostatnich dekad.
366
Ocena makroekonomiczna ma wprawdzie zasadniczy charakter, jednak odbiorcy poradnika
migracyjnego nie moga˛ na nia˛ bezpośrednio wpływać 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 poczekać.
4.4.2 Spojrzenie mikroekonomiczne
Istotna˛ rzecza˛ dla oceny mikroekonomicznej jest własne uzależnienie od dostawcy produktów i
usług. Mimo, że tego typu uzależnienie w dużym stopniu powstaje i uwidacznia si˛e wskutek istnienia monopoli lub quasi monopoli, zbyt silna zależność od dostawców może również wystapić
˛
w warunkach istniejacej
˛ konkurencji i prowadzić w pewnych okolicznościach do zaistnienia niekorzystnych warunków ekonomicznych. Z jednej strony polegać one moga˛ na wyższych cenach
produktów, zaś z drugiej na krótszej długości życia produktów generujacej
˛ dodatkowe koszty
wdrożeń w przypadku migracji kontynuacyjnej.
W ekstremalnym przypadku uzależnienie prowadzić może do sytuacji, w których nie ma
już alternatywnych możliwości post˛epowania mieszczacych
˛
si˛e w akceptowalnej cenie. W przeciwieństwie do powyższego, sytuacja oparta na strategiczej równowadze prowadzi do lepszej
pozycji przetargowej, która w przypadku pojawienia si˛e problemów, pozwala si˛egnać
˛ po rozwia˛
zania alternatywne.
4.5 Wyniki oceny wydajności ekonomicznej
Wi˛ekszość badań poświ˛econych niniejszemu zagadnieniu korzysta w swojej metodologii ze
stopy kosztów całkowitych i dowodzi słuszności twierdzenia, że istotna cz˛eść kosztów przypada nie na licencje na oprogramowanie, lecz leży po stronie wdrożenia i kosztów osobowych
zwiazanych
˛
z przygotowaniem obsługi. Jednak wskutek różnych założeń – w szczególności dotyczacych
˛
sposobów administrowania systemami – wyniki w/w badań prowadza˛ do sprzecznych
wniosków dotyczacych
˛
zalet ekonomicznych niesionych przez różne rozwiazania
˛
alternatywne.
Badania faworyzujace
˛ platformy Microsoftu przedstawiajace
˛ niskie koszty TCO opieraja˛ si˛e
w wi˛ekszości (jednak nie wyłacznie)
˛
na założeniu mniejszych kosztów przygotowania personelu, które uzyskiwane sa˛ w istocie wskutek niższych wymagań odnośnie wykształcenia i tym
samym niższych podstawowych wynagrodzeń administratorów 10. Inna˛ zalet˛e, która wynika już
10
Opracowanie ICD: „Windows 2000 vs Linux dla zastosowań w przedsi˛ebiorstwach“, 2002
367
jednak z w sumie bardzo dyskusyjnych założeń, upatruje si˛e w obszarze bezpieczeństwa informatycznego, którego implementacja dla platform opartych na produktach Microsoftu wymaga
mniejszych nakładów pracy.
Do odmiennych całościowych wniosków prowadza˛ badania krytyczne wzgl˛edem produktów
Microsoftu. Wprawdzie także tutaj stwierdza si˛e różnic˛e w wynagrodzeniu podstawowym, jest
ona jednak z nawiazk
˛ a˛ wyrównywana lepsza˛ jakoś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 rozważań 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. Stopień specjalizacji rozważanych infrastruktur oraz systemów informatycznych
3. Stopień automatyzacji rozważ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 mieści si˛e przede wszystkim pośredni
i bezpośredni potencjał alternatywnych rozwiazań
˛
OSS oraz COLS, mierzony w wymiarze czysto pieni˛eżnym, z promesa˛ porównywalnoś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 można bezpośrednio wpływać a drugi analiza kosztów oddziałujacych
˛
na
budżet.
Do kosztów, na które można bezpośrednio wpływać zalicza si˛e:
1. Koszty uzyskania oprogramowania:
głównie poprzez przejście na tańsze produkty albo uzyskanie niższych cen w procesie
negocjacji
2. Koszty administrowania:
głównie poprzez konsolidacj˛e (redukcj˛e ilości produków) oprogramowania albo rezygnacj˛e z uktualizacji
3. Koszty uzyskania osprz˛etu:
poprzez przejście na tańsze platformy sprz˛etowe
368
4. Koszty administrowania osprz˛etem:
poprzez konsolidacj˛e (redukcj˛e ilości produktów) osprz˛etu albo wydłużenie cyklów życia.
W przeciwień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 można bezpośrednio wpływać. Wynika to przede wszystkim z faktu, że wprowadzenie i użytkowanie infrastruktur oraz systemów
informatycznych zwiazane
˛
jest z podstawowym obciażeniem
˛
wynikajacym
˛
w mniejszym stopniu
z poszczególnych modeli licencjonowania, lecz raczej z takich czynników jak: intensywność administrowania, niezawodność i bezpieczeństwo uż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 można bezpośrednio wpływać wyraźnie widać, że
koszty licencji (uzyskania oprogramowania, administrowania, uaktualnień) stanowia˛ najwi˛esza˛
cz˛eść i tym samym pozostawiaja˛ najwi˛eksze pole do działania.
4.6 Zalecenia migracyjne oparte na ocenie wydajności ekonomicznej
Zalecenia migracyjne dotycza˛ nast˛epujacych
˛
scenariuszy:
◦ migracja pełna (dla dużych, średnich i małych urz˛edów)
◦ migracja kontynuacyjna (dla dużych średnich i małych urz˛edów)
◦ migracja cz˛eściowa (migracja punktowa i po stronie serwera)
W przedstawionych przykładach11 w dużej cz˛eści pomini˛eto apsekt osprz˛etu. Jeśli posiadany
osprz˛et jest nowy (nie starszy niż 2 - 3 lata), wówczas migracj˛e można przeprowadzić bez koniecznoś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˛eżnej podstaw˛e stanowi typowy dla urz˛edów, pi˛ecioletni okres użytkowania
nabytych dóbr. Ponowne inwestowanie spodziewane jest dopiero po tym czasie. Dotyczy to zarówno migracji w kierunku GNU / Linuksa, jak też 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 komplikować obliczeń, przy ocenianiu kosztów migracji zrezygnowano z oceny czynnika oprzyrzadowania.
˛
12
369
Tablica 4.2: Porównanie kosztów przypadajacych
˛
na użytkowników w przypadku migracji pełnej
i kontynuacyjnej
U podstaw obliczeń leża˛ założenia cenowe specyficzne dla urz˛edów. W istotnej cz˛eści w
obliczeniach tych uwzgl˛edniono jednorazowe ceny zakupu. Równolegle do tego dla ocenianych
produktów liczono koszty dzierżawienia Windows oraz MS Office.
Porównanie kosztów pełnej i kontynuacyjnej migracji przypadajacych
˛
na użytkowników wskazuje na jednoznaczne zalety migracji do środowiska OSS13.
T YP
URZ EDU
˛
M IGRACJA
PEŁNA
M IGRACJA
KONTYNUACYJNA
mały
50014 ¤
85015 EUR
średni
34016 ¤
73017 ¤
duż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 każdym z w/w urz˛edów, tj. od małych do dużych).
Natomiast porównanie kosztów osobowych pokazuje, że ta forma migracji w ocenianych, małych / średnich / duż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 wielkościa˛ organizacji!
13
Migracja do środowiska OSS okreś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ł „Średnia instalacja“
17
Patrz rozdział „Migracja kontynuacyjna“, podrozdział „Średnia instalacja“
18
Patrz rozdział „Pełna migracja“, podrozdział „Duża instalacja“
19
Patrz rozdział „Migracja kontynuacyjna“, podrozdział „Duża instalacja“
14
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óż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%
średni
do 10%
do 90%
duży
do 13%
do 87%
URZ EDU
˛
Tablica 4.4: Rozkład kosztów w przypadku „migracji pełnej“ w urz˛edach
Oszcz˛edności obliczone w niniejszym modelu sa˛ nakładami ponoszonymi każdorazowo w
przypadku migracji do środowiska Windows 2000.
T YP
URZ EDU
˛
PODSTAWA
( CENA
-
ZAKUP
JEDNORAZOWA )
mały
500 ¤
średni
340 ¤
duży
180 ¤
371
20
Tablica 4.6: Całkowite koszty migracji przypadajace
˛ na użytkownika w przypadku migracji pełnej
Pełna migracja w przypadku dużych urz˛edów oznacza ponadprzeci˛etny efekt oszcz˛ednościowy. Oszcz˛edności w przypadku migracji z Windows NT do Linuksa, w przeciwieństwie do
migracji do Windows 2000, przekraczaja˛ trzykrotność nakładów.
Koszty osobowe wynikajace
˛ z tej zmiany mieszcza˛ si˛e w porównwalnych rz˛edach wielkości,
zatem duża cz˛eść oszcz˛edności pochodzi z braku konieczności poniesienia kosztów licencyjnych.
Przedstawione efekty oszcz˛ednościowe każa˛ zastanowić si˛e nad migracja˛ do Open Source.
W obszarze średnich i małych urz˛edów mamy do czynienia zasadniczo ze scenariuszem zbliżonym do tego z dużych urz˛edów. Także w tym przypadku okazuje si˛e, że migracja do Open
Source jest ze wszech miar godna polecenia.
W przypadku tego rodzaju migracji nie można zidentyfikować i porównać oszcz˛edności. Dlatego
poniż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 ŻAWA
mały
850 ¤
1.860 ¤
średni
730 ¤
1.740 ¤
duż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 przybliżonymi.
21
˛
z zamiana˛ systemów w ocenianym, pi˛eciolet-
372
˛ na użytkownika w przypadku migracji kontynuacyjnej
Wraz ze wzrostem ilości użytkowników migracja staje si˛e bardziej opłacalna. W tym przypadku, zgodnie z przedstawionym modelem, przejście z cen zakupu na ceny dzierżawy 22 nie
opłaca si˛e.
4.6.3 Migracja cz˛eś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˛eściowej może być przejście z Exchange
5.5 na Samsung Contact. Migacj˛e t˛e można zalecić urz˛edom każdego typu, z zastrzeżeniem, że
w poszczególnym przypadku możliwe jest zastapienie
˛
wymaganych funkcji, ponieważ w przeciwieństwie do migracji z wykorzystaniem produktów Microsoftu przedstawia ona wymierne
korzyści finansowe23.
T YP
URZ EDU
˛
P ODSTAWA - ZAKUP
( CENA
JEDNORAZOWA )
mały
99 ¤
średni
153 ¤
duży
39 ¤
˛ na użytkownika w przypadku migracji
punktowej
Z tablicy cen oprogramowania firmy Samsung wynikaja˛ zaprezentowane powyżej rozpi˛etości kosztów migracji przypadajace
˛ na użytkownika.
nim przedziale czasu. Wszystkie dane sa˛ danymi przybliżonymi.
22
Ceny dzierżawy produktów MS Windows i MS Office były znane, stad
˛ też uwaga „W tym przypadku“.
23
Kosztom migracji do Samsung Contact przeciwstawiane sa,˛ jako oszcz˛edności, koszty migracji do
Exchange2000. Różnic˛e stanowia˛ w każdym przypadku dodatnie wartości kapitału, które wskazuja˛ na odpowiednie
korzyści finansowe.
T YP
373
O PROGRAMOWANIE
P ERSONEL
mały
do 35%
do 65%
średni
do 21%
do 79%
duży
do 56%
do 44%
URZ EDU
˛
Tablica 4.12: Rozłożenie kosztów migracji
Podział kosztów na oprogramowanie i personel waha si˛e w granicach 50% na 50%. W zależności od stopnia zaangażowania obsługi w procesy migracyjne udział ten może si˛e zmieniać.
Nakład przyj˛ety tu za podstaw˛e jest równy nakładowi koniecznemu dla przeprowadzenia migracji do Exchange 2000. Ponieważ jednak z doświadczenia wynika, że może on być niższy, stad
˛
realistyczny udział kosztów osobowych migracji wyniesie raczej mniej niż 50%.
4.6.3.2
Migracja cz˛eściowa po stronie serwera
Niniejsza migracja cz˛eściowa przeprowadzana po stronie serwera jest cz˛eścia˛ migracji pełnej.
Jako alternatywa dla pełnej migracji ta forma zast˛epowania systemu zapewnia bardzo wysoka˛
wydajność, jeśli chodzi o kryterium pilności, jakości i strategii, gdyż istotna cz˛eść projektu migracyjnego ma miejsce na serwerze przy uwzgl˛ednieniu tychże kryteriów.
Koszty kształtuja˛ si˛e na poziomie około 120 ¤, tj. poniżej kosztów ustalonych w przypadku
migracji pełnej (patrz poniż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
także dzi˛eki temu, że zapewnia ona łagodne, ledwo zauważalne i nieodczuwalne przez użytkowników przejście do świata Otwartego Oprogramowania.
T YP
URZ EDU
˛
P ODSTAWA - ZAKUP
( CENA
JEDNORAZOWA )
mały
370 ¤
średni
220 ¤
duży
65 ¤
374
2425
cz˛eściowej po stronie serwera.
Koszty migracji dotycza˛ tu wprawdzie tylko serwerów, jednak odniesiono je do innych kosztów i przeliczono na ilość użytkowników pracujacych
˛
w ocenianych typach urz˛edów.
T YP
URZ EDU
˛
M IGRACJA
PEŁNA
M IGRACJA
CZ E˛ŚCIOWA
U DZIAŁ
KLIENTÓW
PO STRONIE SERWERA
W MIGRACJI PEŁNEJ
mały
500 ¤
370 ¤
129 ¤
średni
340 ¤
220 ¤
120 ¤
duży
180 ¤
65 ¤
116 ¤
cz˛eściowej po stronie serwera.
Rysunek 4.4: Koszty migracji przypadajace
˛ na użytkownika
Rozwój kosztów w przypadku szerokiej migracji potwiedza wcześniej ustalony trend, czyli
zmniejszanie si˛e ich wraz ze wzrostem wielkoś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óżnego rodzaju migracji przemawia jednoznacznie na
korzyść migracji cz˛eściowej po stronie serwera. Jeśli urzad
˛ zdecyduje si˛e na zasadnicze przejście z wykorzystywanego systemu na Open Source, wówczas z ekonomicznych powodów zaleca
24
˛
z zamienianymi systemami w ocenianym,
pi˛ecioletnim przedziale czasu. Wszystkie dane sa˛ danymi przybliżonymi.
25
Wszystkie dane sa˛ danymi przybliżonymi.
375
si˛e obranie tej drogi post˛epowania. Szeroka migracja po stronie serwera (jako wariant, wzgl˛ednie wst˛ep do migracji pełnej) poś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.
Jeśli urzad
˛ zdecyduje si˛e na pozostanie przy systemach opartych o produkty Microsoftu,
wówczas sposób migracji wytyczać b˛edzie migracja kontynuacyjna.
Obydwa sposoby post˛epowania migracyjnego, tj. migracja pełna, jak też punktowa, sa˛ z ekonomicznych punktów widzenia optymalne. W zależności od specjalnych wymagań urz˛edów i /
lub podejmowanych tam decyzji, w/w sposoby moga˛ si˛e okazać jak najbardziej właściwa˛ droga˛
post˛epowania26.
4.8 Nakłady według różnych scenariuszy migracji
4.8.1 Ogólne założenia dotyczace
˛
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 pokażemy możliwe zakresy kosztów osobowych i objaśnimy ich cz˛eś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 może być tylko zgrubnym szacunkiem, ponieważ nie jest (nie może być) dokładnie znany ani punkt wyjścia, ani oczekiwany scenariusz migracji. Z tego powodu przykładowo ocenione zostały trzy różne scenariusze. Przypi29
sano je odpowiednio do przedstawionych wcześniej trzech przykładowych urzadów
˛
. W dalszej
cz˛eści zgrubnie nakreślono każde z tych trzech środowisk.
Dla wszystkich środowisk przyj˛eto nast˛epujace
˛ założenia:
26
W niektórych przypadkach urzad
˛ zmuszony jest, np. wskutek korzystania z niedajacych
˛
si˛e przeportować specjalistycznych aplikacji, do dalszego korzystania z systemów Microsoftu. W innych przypadkach warunki po stronie
serwerów i klientów moga˛ wymagać migracji w jej pełnej formie.
27
Patrz rozdział „Zalecenia migracyjne . . . „
28
Patrz rozdział „Zalecenia odnośnie oceny produków / grup produktów“
29
Urz˛edy małe, średnie i duże
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 środowisko jest w „dobrym“ stanie, wzgl˛ednie nie chce si˛e wprowadzać
Windows 2000 jako pierwszoplanowego systemu w celu odci˛ecia si˛e od starych obciażeń;
˛
wobec tego zakłada si˛e przede wszystkim, że nie jest odrzucana tak zwana „migracja inplace“ (aktualizacja istniejacej
˛ domeny NT).
◦ istnieje uniwersalny techniczny system zarzadzania,
˛
którego narz˛edzia nadaja˛ si˛e także dla
Windows 2000
◦ istnieje udokumentowany plan pracy, który można rozwijać
◦ całościa˛ środowisk suwerennie opiekuje si˛e i odpowiada za nie organizacja, która przeważnie działa centralnie
◦ straty zwiazane
˛
z przerwami w pracy wynikajacymi
˛
z wewn˛etrznych, politycznych niezgodności i niedoborów budżetowych sa˛ minimalne.
Ponadto należy wziać
˛ 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 należy brać 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ównież klastry serwerów NT (Enterprise Edition) z ewentualnymi zewn˛etrznymi jednostkami pami˛eci (podsystemy twardych dysków badź
˛ SAN)
Oceniany model obejmuje sześć etapów i można określić go w kilku punktach:
◦ Warsztat (Kick Off, dopuszczenie konkretnych specjalistycznych działów i gał˛ezi IT,
identyfikacja wszystkich ważnych zagadnień, określenie priorytetów, identyfikacja obszarów decyzyjnych, ustalenie sposób post˛epowania i planu projektu, szczegółowe określenie
nakładów, określenie projektów cz˛eściowych i przypisanie ich do grup roboczych)
377
◦ Ustalenie stanu faktycznego (środowisko oplikacji, zależności komunikacyjne, infrastruktura sieci, usługi centralne, sposób użytkowania, przyszłe wymagania)
◦ Ogólna koncepcja (założonie zeszytu z rozpisanymi obowiazkami,
˛
uszczegółowienie planu
projektu i zdefiniowanie pakietów roboczych , możliwości technicznych, zbudowanie środowiska integrujacego
˛
i testowego, rozrysowanie pozostałego ś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 ś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 uż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, rozmnożenie serwerów, przekazanie informacji
użytkownikom i ich przeszkolenie, sprawowanie opieki przez zespół wdrażajacy
˛ projekt,
przekazanie systemu do normalnego użytkowania).
Ponadto należy przewidzieć zarzadzanie
˛
projektem.
4.8.2 Nakłady na migracj˛e z Windows NT do Windows 2000
Poniżej przedstawione zostana˛ nakłady na migracj˛e, które trzeba ponieść podczas przechodzenia,
w nast˛epujacych
˛
obszarach, z Windows NT 4 do Windows 2000:
◦ usługi logowania
◦ zarzadzanie
˛
plikami
◦ drukowanie.
Migracj˛e do Windows 200030 razem z Active Directory można podzielić na różne etapy zawierajace
˛ pakiety działań. Poniższa tabela w punktach przedstawia oceniane scenariusze.
30
Migracja z Windows NT do Windows 2000 nazywana jest dalej „migracja˛ kontynuacyjna“.
˛
K ATEGORIA
I LO Ś Ć
U ŻYTKOWNIKÓW
P UNKT
WYJ Ś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
średnie
trzy ufajace
˛ sobie domeny
jedna domena
NT każdorazowo z kontami
Windows 2000
komputerów i użytkowników
trzy stanowiska
Kontrolery domen dodatkowo
nadal dwa serwery
powyżej 250 -
udost˛epniaja˛ WINS, DNS
plików i dwa serwery
do 1000
trzy stanowiska o podobnej
wydruku na każdym
wielkości (ilość użytkowniów)
stanowisku
każda z trzech domen dysponuje
dwoma serwerami plików
i dwoma serwerami wydruku
duże
powyżej 1000
11 domen w modelu
jedna domena
Single - Muster (1 domena kont
Windows 2000
i 10 domen zasobów)
dziesi˛eć 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, każda z dwoma
serwerami plików i dwoma
serwerami wydruku
Tablica 4.18: Opis scenariuszy migracji z Windows NT do Windows 2000
379
Scenariusze docelowe dotyczace
˛ dużych i średnich środowisk zaw˛eżaja˛ ilość domen do jednej.
We wszystkich trzech środowiskach przyj˛eto założenie, że aktualizowana jest przynajmniej
jedna dotychczasowa domena (Inplace - Upgrade). Założenie to należy traktować jako prototyp
pomysłu na migracj˛e i jej cel, oznacza ono jednak uproszczenie ścieżki migracji wskutek wyeliminowania dodatkowych nakładów migracyjnych zwiazanych
˛
z kontami użytkowników (w
skrócie: klonowanie, SID-history, przydzielanie nowych uprawnień (ReACLing)).
Ocenia si˛e, że dla różnych środowisk i na różnych etapach konieczne sa˛ nast˛epujace
˛ nakłady
liczone w dniach pracy na osob˛e.
NAKŁAD W
DNIACH
etap
pakiet działań
Warsztat
Ustalenie stanu
logowanie
faktycznego
i sieć
pomysł na zarzadzanie
˛
U WAGI
Ś RODOWISKO
PRACY NA OSOB E˛
małe
średnie
duże
5
10
10
ryczałtem
2
6
22
2 na domen˛e
1
5
21
1 na pierwsza˛ domen˛e
plikami
2 na każda˛ kolejna˛
domen˛e zasobów (ResDom)
pomysł na drukowanie
2
6
20
2 na każda˛ ResDom
procedura
2
4
12
migracyjna
Ogólna koncepcja
1 dla każ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 ś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
˛
380
plikami
plus 5 na dodatkowe ResDom
3
5
13
ryczałtem 3
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 należy doliczyć jeszcze 10% dla wszystkich środowisk na kierowanie projektem.
Przedstawione szacunkowe nakłady należy interpretować jako dolne granice. W każdym z
pakietów działań można zdefiniować duże dodatkowe nakłady, jeśli w zeszycie z obowiazkami
˛
wymagania zostana˛ odpowiednio sformułowane albo rozszerzone. Jako przykład podać można
wpis o stworzeniu badź
˛ rozwini˛eciu pomysłu na prac˛e.
Wyliczona ilość 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.
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 Ś Ć
PUNKT WYJ ŚCIA
U Ż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
średnie
trzy ufajace
˛ sobie
jedna domena
domena - Samba / LDAP
domeny NT każdorazowo
Windows 2000
trzy stanowiska
z kontami komputerów
trzy stanowiska
nadal dwa serwery
i użytkowników
nadal z dwoma
Kontrolery domen
serwerami plików
wydruku na stanowisku
udost˛epniaja˛ dodatkowo
i dwoma serwerami
powyżej 250 -
WINS, DNS i DHCP
wydruku na każdym
do 1000
trzy stanowiska o
stanowisku
podobnej wielkości
(ilości użytkowników)
Każda z trzech domen
z dwoma serwerami
plików i dwoma
serwerami wydruku
duże
31
powyżej 1000
11 domen w modelu
jedna domena
domena - Samba / LDAP
Singel - Master
Windows 2000
(1 domena kont
nadal dwa serwery
i 10 domen zasobów)
nadal 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“.
˛
WINS, DNS i DHCP
382
na stanowisku
10 stanowisk
10 domen, każ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
˛ dużych i średnich środowisk zaw˛eżaja˛ ilość domen do jednej.
We wszystkich trzech środowiskach przyj˛eto założenie, że aktualizowana jest przynajmniej
jedna dotychczasowa domena (Inplace - Upgrade). Założenie to należy traktować jako prototyp
pomysłu na migracj˛e i jej cel, oznacza ono jednak uproszczenie ścieżki migracji wskutek wyeliminowania dodatkowych nakładów migracyjnych zwiazanych
˛
z kontami użytkowników (w
skócie: klonowanie, SID-history, przydzielanie nowych uprawnień (ReACLing)).
˛ nakłady
NAKŁAD W
DNIACH
etap
Ś RODOWISKO
PRACY NA OSOB E˛
pakiet działań
Warsztat
Ustalenie stanu
logowanie
faktycznego
i sieć
U WAGI
małe
średnie
duże
5
10
10
ryczałtem
2
6
22
2 na domen˛e
˛
1
5
21
plikami
Print
2 na każda˛ kolejna˛
domen˛e zasobów (ResDom)
2
6
20
2 na każda˛ ResDom
procedura
2
4
12
migracyjna
Ogólna koncepcja
1 dla każdej kolejnej
domeny zasobów (ResDom)
wymagania
1
3
10
1 na stanowisko
˛
2
4
6
ryczałtem
plan projektu
1
3
10
1 na stanowisko
383
budowa ś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)
˛
plikami
3
5
13
ryczałtem 3
instalacja
3
3
3
ryczałtem
ryczałtem 3
procedura
3
13
13
migracyjna
skomplikowania
(Spsoby post˛epowania sa˛
tutaj mniej standaryzowane
niż w przypadku migracji
kontynuacyjnej, jednak
w porównaniu z koncepca˛
szczegółowa˛ należy liczyć
si˛e jedynie ze wzgl˛ednie
małym wzrostem nakładów.)
6 centralny
zarzadzanie
˛
systemem
6
9
9
3 niecentralny
(trzeba tu uzupełnić
rozwiazania
˛
pracujace
˛
z cz˛eścia˛ oprogramowania;
wiele z istniejacych
˛
systemów
można zastosować
także z OSS
ryczałtem
(W przypadku migracja do
384
OSS należy si˛e tu liczyć
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 należy tu oczekiwać
wyż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 niepewność
(Gdy wszystko jest
zaplanowane i przetestowane,
Rollout
10
35
125
sam Rollout nie wymaga
już dużych nakładów. Jednak
czynnik niepewności jest
wi˛ekszy, wzgl˛ednie tolerancja
bł˛edów jest mniejsza niż
w przypadku migracji
kontynuacyjnej
Suma
86
195
451
Tablica 4.24: Nakłady liczone w dniach na osob˛e w przypadku migracji zast˛epujacej
˛
Przedstawione szacunkowe nakłady należy interpretować jako dolne granice. W każdym z
pakietów działań można zdefiniować duże dodatkowe nakłady, jeśli w zeszycie z obowiazkami
˛
385
wymagania zostana˛ odpowiednio sformułowane albo rozszerzone. Jako przykład podać można
wpis o stworzeniu badź
˛ rozwini˛eciu pomysłu na prac˛e. Nakłady na tego typu czynności moga˛
być niemal dowolne.
4.8.4 Nakłady na migracj˛e z Exchange 5.5 do Exchange 2000
Poniżej przedstawione zostały nakłady potrzebne do przeprowadzenia migracji z Microsoft Exchange
5.5 do Exchange 2000.
˛ nakłady
NAKŁAD W
DNIACH
etap
pakiet działań
Warsztat
Ustalenie stanu
logowanie
faktycznego
i sieć
środowisko Exchange
U WAGI
Ś RODOWISKO
PRACY NA OSOB E˛
małe
średnie
duż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
˛
2
4
4
ryczałtem
plan projektu
1
3
3
1 centralny
2 niecentralny
budowa środowiska
testowego
ryczałtem 2
3
5
7
plus dodatkowe
stanowiska / domeny
wybór osprz˛etu
5
5
5
ryczałtem
przy klastrach podwoić
Dokładna koncepcja
pomysł na Exchange
5
10
10
5 centralny
5 niecentralny
projekt serwera
5
5
5
ryczałtem
test ADC
5
10
10
ryczałtem 5
plus 1 na czynnik poziomu
skomplikowania
instalacja
3
3
386
3
procedura
migracyjna
ryczałtem
ryczałtem 2
2
12
12
skomplikowania
zarzadzanie
˛
systemem
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
Pilot
5 niecentralny
Rolluot
3
9
30
3 na każdy serwer
Exchange
Suma
64
121
171
Tablica 4.26: Nakłady liczone w dniach na osob˛e: Exchange5.5 –> Exchange2000
Wyliczona ilość 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
Poniżej przedstawione zostały nakłady potrzebne do przeprowadzenia migracji z Microsoft Exchange
5.5 do Samsung Contact.
Zaprezentowane tu założenia dotycza˛ wszystkich środowisk (opartych na Samsung Contact).
◦ wszystkie serwery Samsung Contact oparte sa˛ na systemach linuksowych albo systemach
Unix OS.
◦ możliwa jest konsolidacja wielu serwerów MS Exchange.
387
◦ ilość użytkowników zależy tylko od wydajności CPU. Nie istnieja˛ ograniczenia rozmiaru
skrzynki pocztowej. Dane moga˛ być gromadzone w ilości wielu terabajtów.
◦ nie jest potrzebna migracja do ADS.
◦ system oszcz˛edza zasoby, stad
˛ w przypadku migracji można nadal korzystać z istniejacego
˛
osprz˛etu (Linux).
◦ istnieje możliwość migracji publicznych katalogów, kalendarza i kontaktów.
NAKŁAD
W DNIACH
etap
Ś RODOWISKO
PRACY NA OSOB E˛
U WAGI
pakiet działań
małe
średnie
duże
Ustalenie stanu
logowanie
0,2
0,2
0,2
faktycznego
i sieć
Środowisko Exchange
0,2
0,5
1
procedura
0,2
0,5
1
wymagania
0,2
0,5
1
˛
1
2
3
plan projektu
0,5
1
1
budowa ś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
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 odnośnie sposobu oceny produktów / grup produktów
4.8.6.1
Generalne założenia
◦ W obliczeniach podanych w przykładowych scenariuszach dla różnych obiektów migracji
ocenione zostały wyłacznie
˛
generatory kosztów i generatory korzyś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 kompatybilności
– koszty szkolenia
– koszty administrowania
◦ Projekty migracyjne sa˛ na ogół wyposażone tylko w niewielki własny potencjał oszcz˛ednościowy (koszty oprogramowania). Pozwala on jedynie w rzadkich przypadkach wykazać
rentowność przedsi˛ewzi˛ecia. Ponieważ 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 poniższych przykładach dokonano „oceny na krzyż“. W tym celu w
przypadku migracji do OSS wliczono po stronie oszcz˛edności niewymagane, porównywalne nakłady b˛edace
˛ różnica˛ przypadajac
˛ a˛ na migracj˛e w ramach platformy Microsoft.
◦ W przypadku zewn˛etrznych kosztów osobowych przyj˛eto średnia˛ dniówk˛e wynoszac
˛ a˛
1.000 ¤.
389
◦ Za podstaw˛e oceny kosztów osobowych przyj˛eto informacje dla najwyższych urz˛edów federalnych32. Obliczenie kosztów wykonano na podstawie stawki wynagrodzenia poziomu
IVa (najwyższe urz˛edy federalne, 36,98 ¤na godzin˛e, 462 minuty na dzień.
◦ Podane przykładowo koszty przypadajace
˛ na osob˛e dla dużych, średnich i małych urz˛edów
każdorazowo dzielone były w proporcji 80 / 20 na zasoby zewn˛etrzne i wewn˛etrzne.
◦ Dla oprocentowania przyszłych oszcz˛edności uż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 pokazać różne możliwoś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
ŚRODOWISKA
M ICROSOFT W INDOWS NT
OSS – NA KLIENTY
DO
I SERWERY
LINUKSOWE
32
Przykładowy scenariusz
mały urzad,
˛ 250 użytkowników
Wyznaczniki sukcesu
koszty oprogramowania, koszty zastapienia
˛
oprogramowania
Patrz „Stopy kosztów osobowych dla sporzadzania
˛
rachunków kosztów / rachunków wydajności ekonomicznej“ Federalne Ministerstwo Finansów, 29 października 2002 r.
33
Patrz „Stopy kosztów osobowych . . . “ Federalnego Ministerstwa Finansów z 29 października 2002 r.
34
W pojedynczych przypadkach należy liczyć si˛e z innymi cenami, jeśli trafniej przedstawiaja˛ one realna˛ sytuacj˛e
w urz˛edach.
◦ generatorami koszów / korzyści sa˛ trzy
kryteria
– koszty licencji
– koszty zastapienia
˛
oprogramowania
˛ jeszcze koszty za neutralne i
tym samym w przykładowym wyliczeniu
wzi˛eto pod uwag˛e tylko w/w generatory
kosztów / korzyści.
◦ W przykład wliczono po stronie oszcz˛edności różnic˛e wynikajac
˛ a˛ z nie branych
pod uwag˛e nakładów na przejście z MS
Windows NT do Linuksa. Dotyczy to licencji na oprogramowanie i kosztów zastapienia
˛
oprogramowania.
Licencje na oprogramowanie:
Po stronie oszcz˛edności liczono tu licencj˛e na Windowsa jako różnic˛e w porównaniu do bezpłatnego Linuksa.
Założenia
Koszty zastapienia
˛
oprogramowania:
Po stronie oszcz˛edności wpisano różnic˛e
pomi˛edzy nakładami liczonymi w dniach
roboczych na osob˛e w przypadku migracji wewnatrz
˛ platformy Microsoft a migracji do Linuksa. Różnica ta obliczona
została na podstawie ś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 użytkowników sa˛
390
Break-even
391
Projekt spłaca si˛e już w pierwszym roku.
Tablica 4.30: Przykład migracji: infrastruktura serwerów – mały urzad
˛
Przykład migracji: infrastruktura serwerów – mały urzad
˛
Tablica 4.31: 1 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), mały urzad.
˛
Z przedstawionego powyżej przykładu WiBe wynika dodatnia wartość kapitału przy założeniu, ż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.
M IGRACJA
P RZEDMIOT
MIGRACJI
Z
ŚRODOWISKA
392
OSS – NA KLIENTY
DO
I SERWERY
LINUKSOWE
Wyznaczniki sukcesu
średni urzad,
˛ 1.000 użytkowników
˛
oprogramowania
kryteria
– koszty licencji
˛
oprogramowania
˛
oprogramowania.
Założenia
Koszty zastapienia
˛
oprogramowania:
cej 1.000 ¤.
393
Break-even
394
Tablica 4.33: Przykład migracji: infrastruktura serwerów – średni urzad
˛
Przykład migracji: infrastruktura serwerów – średni urzad
˛
Tablica 4.34: 2 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), średni urzad
˛
M IGRACJA
P RZEDMIOT
MIGRACJI
Z
ŚRODOWISKA
395
OSS – NA KLIENTY
DO
I SERWERY
LINUKSOWE
Wyznaczniki sukcesu
duży urzad,
˛
oprogramowania
kryteria
– koszty licencji
˛
oprogramowania
˛
oprogramowania.
Założenia
Koszty zastapienia
˛
oprogramowani:
cej 1.000 EUR.
396
Break-even
397
Tablica 4.36: Przykład migracji: infrastruktura serwerów – duży urzad
˛
Przykład migracji: infrastruktura serwerów – duży urzad
˛
Tablica 4.37: 3 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), duży urzad
˛
M IGRACJA
P RZEDMIOT
MIGRACJI
WISKA
Z
M ICROSOFT O FFICE
OSS –
NUKSOWE Z
398
DO ŚRODO -
NA KLIENTY I SERWERY LI -
O PEN O FFICE . ORG
mały urzad
˛ do 250 użytkowników
Przykładowe scenariusze
średni urzad
˛ do 1.000 użytkowników
duży urzad
˛ powyżej 1.000 użytkowników
Wyznaczniki sukcesu
˛
oprogramowania
◦ W przypadku migracji do OpenOffice.org
na serwerach i klientach pracuje system
operacyjny GNU/Linux.
kryteria
– koszty licencji
˛
oprogramowania
˛ a˛ z kosztów licencji MS Office w porównaniu do bezpłatnego OpenOffice.org.
Założenia
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, każdy po 5 dni (łacznie
˛
około 2000
¤razem z podatkiem VAT)
◦ U podstaw obliczanych tu przykładów
leża˛ nast˛epujace
˛ ilości - założenia35 :
35
Jednolite dla wszytkich typów urz˛edów
– ilość dokumentów na użytkownika
13
– ilość makr na użytkownika 0,07
– czas migracji pojedynczego na dokument 0,2 h
399
Break-even
400
We wszystkich typach urz˛edów projekt spłaca
si˛e już 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
˛
Obliczeń w powyższych przykładach dokonano m.in. po to, aby uzyskać górna˛ granic˛e wymaganego czasu na migracj˛e makr. Odpowiednie czasy wskazane w założeniach pokazuja˛ każ-
401
dorazowo t˛e granic˛e. Aż do tej wartości nie powstaje c.p.36 ujemna wartość kapitału.
Niniejsza ocena stanowi ponadto przeglad
˛
z migracja˛ wewnatrz
˛ platformy Microsoftu. Zostały tu one podliczone po stronie oszcz˛edności i można je odczytać z
wierszy „wartość kapitału wb (wb = wpływajaca
˛ na budżet)“.
Nakłady na migracj˛e do OpenOffice.org nie sa˛ w istocie kosztami wpływajacymi
˛
na budżet,
ponieważ przeprowadza si˛e ja˛ za pomoca˛ własnego personelu.
Do ocenianych tu nakładów trzeba w każdym przypadku doliczyć wsparcie zewn˛etrzne, które
należy zaplanować w przybliż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
zależności nie zostały zmienione w niniejszych różniacych
˛
si˛e od siebie przykładach
402
Tablica 4.42: Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), średni urzad
˛
403
Tablica 4.43: Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), duży urzad
˛
M IGRACJA
P RZEDMIOT
MIGRACJI
DOWISKA
Z
M ICROSOFT O FFICE
OSS –
NA LINUKSOWY
DO ŚRO -
O PEN O F -
FICE . ORG
średni urzad
˛ do 500 użytkowników
Krytyczne
sukcesu
przej˛ecie istniejacych
˛
danych - dokumentów i
makr
wyznaczniki
404
kryteria
– koszty licencji
˛
oprogramowania
◦ Migrowane obiekty podzielono na dokuZałożenia
menty i makra. Na dokumenty przypadaja˛ z reguły krótkie czasy migracji. Makra wymagaja˛ bardzo różnych nakładów
czasu, które zależa˛ od stopnia złożoności
każdego makro.
◦ Dla oceny kosztów aplikacji Microsoftu
przyj˛eto ś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˛etość (wartości
37
progowe) krytycznych wyznaczników sukcesu
Patrz dalsze założenia odnośnie ilości i cen przyj˛ete w obliczonym przykładzie załaczone
˛
do prezentacji Break
Even.
405
Przy maksymalnie około 6.500 migrowanych
Break-even po 3 latach
dokumentów i 500 użytkownikach (odpowiada
to około 13 obiektom na użytkownika) Breakeven można uzyskać po 3 latach.
Przy maksymalnie około 12.500 migrowanych
Break-even po 5 latach
dokumentów i 500 użytkownikach (odpowiada
to około 25 obiektom na użytkownika) oraz 35
makrach w całym urz˛edzie Break-even można
uzyskać 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
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
środowiskiem windowsowym do OpenOffice.org i środowiska GNU / Linux. Migracja obejmuje
6.500 dokumentów.
Na oprogramowanie Open Source nie przypadaja˛ żadne koszty. Odchodza˛ za to coroczne
koszty licencji na produkty Microsoftu w wysokości około 160 tys. ¤. Wartość ta zapisana jest
w WiBe po stronie oszcz˛edności i wpływa na budżet.
Nakłady na przestawienie oprogramowania ponoszone sa˛ własnymi siłami, dlatego koszty w
wysokości około 148 tys. ¤nie wpływaja˛ na budżet.
Za pomoca˛ niniejszej metody mierzenia wielkości kapitału kwoty przypadajace
˛ na dany
dzień dyskontowane sa˛ o oprocentowanie. Wynikaja˛ z nich trzyletnie oszcz˛edności (brak kosz-
407
tów licencji Microsoftu) wynoszace
˛ 142 tys. ¤. Oprocentowanie nakładów migracyjnych prowadzi równolegle do powstania rocznej kwoty około 139 tys. ¤. Jako wartość kapitału powstaje
dodatnia kwota wynoszaca
˛ 3.085 ¤. Tym samym przedsi˛ewzi˛ecie to jest opłacalne.
Oceny ryzyka (prawdopodobieństwa wystapienia
˛
oszcz˛edności, wzgl˛ednie kosztów migracji)
można tu nie brać pod uwag˛e, gdyż oszcz˛edności sa˛ obecnymi opłatami licencyjnymi, których
w przyszłości nie b˛edzie. Koszty zastapienia
˛
oporogramowania przedstawione w postaci czasu
wymaganego na migracj˛e zostały raczej zawyżone niż zaniżone.
Podstawa˛ dla ilości jest jako Best Practice wyliczenie Gartnera38, które dostosowane zostało
do wymagań administracji publicznej.
Tablica 4.47: Przykład WiBe: Windows / MS Office do Linux / OpenOffice.org; Break even po
5 latach
38
Patrz „The Bost and Benefits of Moving to Sun’s StarOffice 6.0“, 1 lipca 2002 r.
408
W niniejszym przykładzie Break-even uzyskiwany jest po 5 latach. Uzupełniajac
˛ przykład
dla 3-letniego Break-even należy zauważyć, co nast˛epuje.
Do 12.500 została jedynie zwi˛ekszona ilość migrowanych dokumentów (odpowiada to około
25 dokumentom na użytkownika). Czas oceny wydłużony został do 5 lat.
Systematyka obliczeń pozostaje taka sama. Po pi˛eciu latach powstaje dodatnia wartość kapitału w wysokości 1.496 ¤.
Jeśli chodzi o ocen˛e ryzyka i podstaw˛e ilości, patrz wyżej.
P RZEDMIOT
MIGRACJI
M IGRACJA Z E XCHANGE 5.5 DO ŚRODOWI SKA OSS – NA KLIENTY I SERWERY LINUK SOWE
Wyznaczniki sukcesu
S AMSUNG
CONTACT
mały urzad,
˛ 250 użytkowników
˛
oprogramowania
kryteria
– koszty licencji
˛
oprogramowania
Exchange 5.5 do Exchange 2000. Dotyczy to licencji na oprogramowanie i kosztów zastapienia
˛
oprogramowania.
Po stronie oszcz˛edności liczono tu różZałożenia
nic˛e pomi˛edzy kosztami licencji Contact
a Exchange.
Koszty zastapienia
˛
oprogramowania:
roboczych na osob˛e w przypadku Samsung i Microsoft. Różnica ta obliczona
cej 1.000 ¤.
niemal takie same w przypadku obydwu
platform (Exchange i Contact). Dlatego
przedstawianie przykładowego wyliczenia uznano za zbyteczne.
◦ Zaplanowane szkolenia dla 2 administra-
409
Na podstawie założeń projekt jawi si˛e jako wysoce opłacalny. Break-even uzyskuje si˛e już w
pierwszym roku. Ważnym czynnikiem sa˛ przy
Break-even
tym oszcz˛edności na zewn˛etrznym wsparciu
wymaganym w przypadku migracji wewnatrz
˛
platformy Microsoft. W oparciu o ocen˛e BestCase i Worst-Case w ramach dodatniej wartości kapitału powstaje przestrzeń 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
411
Tablica 4.50: Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], mały urzad
˛
W powyż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 wartość
kapitału wynoszaca
˛ (187) nadal jest dodatnia, co sprawia, że projekt jest rentowny. Jeśli konieczne jest mniejsze zewn˛etrzne wsparcie, wówczas wartość kapitału rośnie.
˛
oszcz˛edności, wzgl˛ednie kosztów migracji) można tu nie brać pod uwag˛e, gdyż oszcz˛edności sa˛ obecnymi opłatami licencyjnymi, których w przyszłości nie b˛edzie. Koszty zastapienia
˛
oporogramowania przedstawione w postaci
wymaganego czasu zostały raczej zawyżone niż zaniżone.
M IGRACJA
P RZEDMIOT
MIGRACJI
SKA
OSS –
SOWE
Wyznaczniki sukcesu
Z
E XCHANGE 5.5
412
DO ŚRODOWI -
NA KLIENTY I SERWERY LINUK -
S AMSUNG
CONTACT
średni urzad,
˛
oprogramowania
Patrz przykłady z „mały urzad“.
˛
Założenia
Dodatkowo:
Ilość administratorów i nakład na ich szkolenie
nie zmienia si˛e w zależności od ilości użytkowników pozostaja˛ takie same (około 2 x 2.000,
¤liczone z podatkiem VAT).
Na podstawie założeń projekt jawi si˛e jako wysoce opłacalny. Break-even uzyskuje si˛e już
w pierwszym roku. Najważniejszym czynnikiem sa˛ przy tym oszcz˛ednoś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 wartości kapitału powstaje przestrzeń 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 – średni urzad
˛
Przykład migracji: Messaging / Groupware – średni urzad
˛
413
Tablica 4.53: Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], średni urzad
˛
W powyższym przykładzie ustalono górna˛ granic˛e progowa˛ zewn˛etrznego wsparcia dla Contact w przypadku średnich urz˛edów. Wynosi ona 34 dni robocze na osob˛e. Tym samym wartość
kapitału wynoszaca
˛ (1.102) jest jeszcze dodatnia, co sprawia, że projekt jest rentowny.
Jeśli za wartość zewn˛etrznego wsparcia dla Contact w przypadku średnich urz˛edów przyjmie
si˛e realistyczny wskaźnik 5 dni, wówczas powstaje naprawd˛e duża dodatnia wartość kapitału,
która sygnalizuje dobra˛ rentowność projektu.
˛
oszcz˛edności, wzgl˛ednie kosztów migracji) można tu nie brać pod uwag˛e, gdyż oszcz˛edności sa˛ obecnymi opłatami licencyjnymi, których w przyszłości nie b˛edzie. Koszty zastapienia
˛
oporogramowania przedstawione w postaci
wymaganego czasu zostały raczej zawyżone niż zaniżone.
4.8.6.3
Przykład migracji: Messaging / Groupware – duży urzad
˛
P RZEDMIOT
MIGRACJI
M IGRACJA Z E XCHANGE 5.5 DO ŚRODOWI SKA OSS – NA KLIENTY I SERWERY LINUK SOWE
Wyznaczniki sukcesu
Założenia
S AMSUNG
CONTACT
duży urzad,
˛
oprogramowania
Patrz przykłady z „mały i średni urzad“.
˛
Na podstawie założeń, do ilości pracowników
wynoszacej
˛ około 6.200, projekt jawi si˛e jako
opłacalny. Jeśli wzrośnie ilość pracowników i /
lub ilość dni zewn˛etrznego wsparcia, wówczas
Break-even po 1 roku
wartość kapitału stanie si˛e ujemna. Oszcz˛edności wynikajace
˛ z nie branych pod uwag˛e dni
zewn˛etrzego wsparcia dla Migracji wewnatrz
˛
platformy Microsoft równoważa˛ si˛e tylko do
w/w ilości pracowników.
Tablica 4.55: Przykłady migracji: Messaging / Groupware – duży urzad
˛
414
415
Tablica 4.56: Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], duży urzad
˛
W powyższym przykładzie założono wsparcie zewn˛etrzne dla Contact w wysokości około
17 dni roboczych na osob˛e. Wynikajace
˛ z tego oszcz˛edności wynosza˛ około 111 dni roboczych
na osob˛e wzgl˛edem usługi Microsoftu. Ilość użytkowników ustalono na 10.000. W takich warunkach wyliczenia daja˛ jeszcze dodatnia˛ wartość kapitału.
4.8.6.4
Przykłady migracji według kategorii kosztów informatyzacji
Obowiazuj
˛ a˛ tu takie same założenia, jakie zostały opisane w rozdziale 4.8.6.1. Obliczenia w
przykładach odnosza˛ si˛e do produktów przedstawionych w poniższej tabeli.
416
Tablica 4.57: Typy migracji / produkty
W niniejszym modelu dokonano porównawczej oceny alternatywnych typów migracji przyjmujac
˛ za punkt wyjścia aktualne środowisko. Scenariuszem wyjściowym jest przy tym platforma
Microsoftu. Jedynie wariant migracji kontynuacyjnej nie zawiera namacalnych, dajacych
˛
si˛e obliczyć oszcz˛edności. Wszystkie inne warianty prowadza˛ do całkowitej albo cz˛eściowej zmiany
platformy i tym samym zawieraja˛ w obszarze porównania ich z migracja˛ kontynuacyjna˛ oszcz˛edności w postaci zaoszcz˛edzonych wydatków.
Ceny i warunki zastosowane w przykładowych wyliczeniach zwracaja˛ si˛e w pierwszym roku
wdrażania projektu. Ponieważ rachunek opiera si˛e na cenach zakupu, oszcz˛edności powstaja˛
również tylko w pierwszym roku.
4.8.6.5
Pełna migracja
Pełna migracja oznacza ponadprzeci˛etnie duży efekt oszcz˛ednościowy w przypadku urz˛edów
każdego typu. Na przykład migracja z Windows NT do Linuksa daje w przeciwieństwie do migracji do Windows 2000 oszcz˛edności, które wielokrotnie przekraczaja˛ nakłady.
Duża instalacja
Koszty osobowe w przypadku zmiany platformy stanowia˛ porównywalny rzad
˛ wielkości, dlatego że wi˛eksza cz˛eść oszcz˛edności pochodzi ze zb˛ednych kosztów licencji.
417
Rysunek 4.5: Przykład rachunku opłacalności migracji Windows NT –> Linux, duży urzad,
˛
ocena kosztów projektu
Także ocena rentowności niniejszego wariantu pokazuje poprzez dodatnia˛ wartość kapitału
opłacalny przebieg przedsi˛ewzi˛ecia.
418
Rysunek 4.6: Przykład rachunku opłacalności migracji Windows NT –> Linux, duży urzad,
˛
ocena wartości kapitału
Średnia instalacja
W obszarze średnich i małych urz˛edów obowiazuje
˛
zasadniczo scenariusz porównywalny ze
scenariuszem z dużych urz˛edów. Także w tym przypadku migracja do Open Source jawi si˛e jako
bardzo godna polecenia.
419
Rysunek 4.7: Przykład rachunku opłacalności migracji Windows NT –> Linux, średni urzad,
˛
ocena kosztów projektu
Również w tego typu urz˛edzie z oceny porównawczej różnych wariantów migracji wynika
dodatnia wartość kapitału.
420
Rysunek 4.8: Przykład rachunku opłacalności migracji Windows NT –> Linux, średni urzad,
˛
Mała instalacja
Obowiazuje
˛
tu to samo, co w przykładach dla średnich i dużych urz˛edów.
421
Rysunek 4.9: Przykład rachunku opłacalności migracji Windows NT –> Linux, mały urzad,
˛
4.8.6.6
Migracja kontynuacyjna
W przypadku tego typu migracji nie można zidentyfikować ani zbilansować oszcz˛ednoś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 dzierżaw˛e uaktualnień dla Windows oraz MS
Office.
Każdorazowo pokazujemy wyliczenia dla dużych, średnich i małych instalacji.
Wersja opłat za dzierżaw˛e jawi si˛e we wszystkich wyliczonych wariantach jako znacznie
droższe rozwiazanie
˛
(dodatkowe koszty w wysokości około 250 tys. ¤[mała migracja], ponad
około 1 miliona ¤[średnia migracja], do około 10 milionów ¤[duż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.
Duża instalacja
422
Rysunek 4.10: Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000,
duży urzad
˛
423
duży urzad,
˛ alternatywna dzierżawa Windows / Office
Średnia instalacja
średni urzad
˛
424
średni urzad,
˛ alternatywna dzierżawa Windows / Office
Mała instalacja
425
mały urzad
˛
426
Rysunek 4.15: Przykład rachunku kosztów projektu migracji Windows NT –> Linux, mały urzad,
˛
alternatywna dzierżawa Windows / Office
4.8.6.7
Migracja cz˛eściowa
Punktowa migracja
Rysunek 4.16: Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Contact,
duży urzad
˛
427
średni urzad
˛
428
mały urzad
˛
Migracja cz˛eściowa po stronie serwera
Rysunek 4.19: Przykład rachunku kosztów projektu migracji Windows NT do Linuksa po stronie
serwera, duży urzad
˛
429
serwera, średni urzad
˛
430
serwera, mały urzad
˛
4.9 Przykładowa ocena konieczności oraz jakości i strategii
migracji
Przykładowa ocena obejmuje rachunek konieczności D (Konieczność) i jakości czynników strategicznych Q (Jakość) 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
zebraliśmy argumenty uzasadniajace
˛ każdorazowe wyliczenia. Niniejszy opis został ukierunkowany według stopni spełnienia celu wynikajacego
˛
z katalogu kryteriów.
Przykładowa ocena konieczności migracji daje wartość > 59 <. Zatem z tego punktu widzenia można generalnie poprzeć zamiary migracyjne.
Przykładowa ocena jakościowo - strategiczna zamiarów migracyjnych daje wartość > 66 <.
Tym samym z ocenianych tu punktów widzenia maja˛ one także sens.
4.9.1 Kryteria konieczności
Niniejsze kryteria (grupa 3 katalogu kryteriów) odnosza˛ si˛e z jednej strony do konieczności
zastapienia
˛
starego systemu a z drugiej strony do przestrzegania przepisów administracyjnych i
ustaw.
4.9.2 Kryteria jakościowo - strategiczne
W grupie 4 katalogu kryteriów wymienione sa˛ kryteria jakościowo - strategiczne dotyczace
˛ zamierzeń informatycznych. Odnosza˛ si˛e one do priorytetu tych działań, do poprawienia jakości
pracy w ramach urz˛edu i do oddziaływania na pracowników oraz „klientów“ administracji publicznej (otwartość na obywatela), jak również do pokupności oprogramowania i bezpieczeństwa
informatycznego. W ten sposób na pierwszym planie nie wyst˛epuje już stary system, lecz należy
dokonać sprawdzenia zamiaru informatycznego pod katem
˛
czynników wymienionych w kryteriach.
431
4.9.3 Analiza korzyści
Kryteriów konieczności oraz jakości / strategii nie można sklasyfikować za pomoca˛ analizy pieni˛eżnej. Zamiast tego tworza˛ one cz˛eść oceny korzyści. Wymaga to jakościowego opisu wpływu
niniejszych kryteriów. Opis taki należy z kolei zamienić w ocen˛e punktowa˛ każdego kryterium.
Służy do tego „skala ocen“ od 0 do 10. Punkty należy pomnożyć przez każdorazowy stopień
ważności i zsumować poszczególne obszary kryteriów.
Jeśli uzystkana wartość jest wi˛eksza niż (>) 50, wówczas zamiar informatyczny zwiazany
˛
ze
sprawdzonym zakresem należy zakwalifikować jako „zalecany do realizacji“.
432
Rysunek 4.22: Model oceny konieczności i jakości zamiaru migracyjnego
Poszczególne kryteria opisane zostały w poniższej tabeli:
P OZYCJA
WIBE
3
K RYTERIUM /
OBJA ŚNIENIE
WA ŻNO Ś Ć /
PUNKTY
CZYNNIKI KONIECZNO ŚCI
433
3.1
Konieczność 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 już Service Packs usuwajacych
˛
bł˛edy
systemowe ważne dla bezpieczeństwa.
◦ Nie ma obsługi nowych Features takich jak, np.
USB i inne.
3.1
˛
starego systemu
W 20
3.1.2
Stabilność starego systemu
P7
3.1.2.1
Bł˛edy i awarie („downtime“)
◦ Podatność starego systemu na bł˛edy znajduje si˛e
wciaż
˛ w zakresie, który można tolerować.
◦ Wskutek zastosowania nowych narz˛edzi wspomagajacych
˛
administrowanie wzrośnie podatność na
bł˛edy, ponieważ programiści przechodza˛ na nowe
biblioteki, których jednak nie można bez problemu
zintegrować z architektura˛ Windows NT.
3.1
Konieczność zastapinia
˛
starego systemu
W 20
3.1.2
Stabilność starego systemu
P4
3.1.2.2
Problemy z konserwacja,˛ waskie
˛
gardło – personel
◦ Wsparcie zewn˛etrzne dla systemu w przyszłości
b˛edzie si˛e wciaż
˛ zmniejszać, ponieważ także producent nie b˛edzie go już gwarantować a w tak zwanym mi˛edzyczasie na rynek wprowadzona zostanie kolejna platforma systemu operacyjnego.
434
3.1
˛
starego systemu
W 10
3.1.3
Elastyczność starego systemu
P8
3.1.3.1
Rozbudowa / poszerzanie granic
◦ Nie b˛edzie już implementacji nowych funkcji takich jak, np. obsługa USB, i innych.
◦ Nie b˛eda˛ już rozwijane narz˛edzia zapewniajace
˛
współprac˛e z nowymi systemami.
◦ Wskutek zmieniajacych
˛
si˛e architektur w przyszłości wystapi
˛ a˛ z wi˛eksza˛ siła˛ problemy z interfejsami do innych systemów informatycznych.
3.1
3.1.3
˛
starego systemu
3.1.3.2
Kompatybilność, problemy z interfejsami aktualnie /
W 10
P9
w przyszłości
◦ Obecne działania dostosowujace
˛ stary system
wiaż
˛ a˛ si˛e z dużymi nakładami
3.1
˛
starego systemu
W 20
3.1.3
P3
3.1.3.3
Przyjazność dla użytkownika
◦ Obecnie nie sa˛ zakłócone
Tablica 4.59: Przykład analizy korzyści: czynniki konieczności
P OZYCJA
WIBE
4
K RYTERIUM /
OBJA ŚNIENIE
WA ŻNO Ś Ć /
PUNKTY
CZYNNIKI JAKO ŚCIOWO
- STRATEGICZNE
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 środowiska systemowego wraz ze
wszystkimi ocenianymi funkcjami (administrowanie, konwersja plików i inne) można w przypadku
instniejacych
˛
produktów i zależności zrealizować
tylko warunkowo.
4.1
4.1.3
Skutki dla partnerów komunikacyjnych
W 10
P7
◦ W przeciwieństwie do obecnej sytuacji, w ramach ukierunkowania si˛e na wdrożenie produktów OSS tworzona jest idealna podstawa komunikacyjna, która ułatwi komunikacj˛e wykraczajac
˛ a˛
poza urz˛edy.
4.1
W 20
4.1.5
Uzależ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 wdrożenie produków OSS odchodzi
si˛e od daleko idacego
˛
uzależnienia od producenta.
436
4.4
Efekty dotyczace
˛ pracowników
W5
4.4.1
Atrakcyjność warunków pracy
P6
Można tu zaobserwować dwa oddzielne efekty:
◦ W obszarze administrowania powstana˛ nakłady
wskutek wyraźnie bardziej wymagajacych
˛
czynności wynikajacych
˛
z wdrożenia produktów OSS,
które wyraźnie poszerza˛ profile kwalifikacji personelu.
◦ W obszarze użytkowników daży
˛ si˛e do rozwia˛
zań, które umożliwia˛ wyraźne uproszczenie dzisiaj jeszcze po cz˛eści bardzo ograniczonej pracy
w obszarze biurowego oprogramowania komunikacyjnego wykraczajacej
˛ poza ramy produktu.
4.4
Efekty dotyczace
˛ pracowników
W2
4.4.3
Powszechność / dost˛epność wykształcenia
P3
◦ Z uwagi na wykształcenie i doświadczenie wymagane dla obsługi obecnie stosowanych systemów
nie ma tu problemów. Za to w przyszłości, w przypadku silniejszego popytu na produkty OSS, może
być trudniej znaleźć odpowiednio wykształcony
personel. Ponieważ jednak należy wyjść z założenia, że pracujacy
˛ personel jest odpowiednio wyszkolony, wystapieniem
˛
tego efektu w administracji publicznej nie należy si˛e na razie zajmować.
437
4.5
Efekty zwiazane
˛
z dost˛epnościa˛ dla obywateli
W2
4.5.4
Poprawa wizerunku
P6
◦ Projekty migracyjne powinny służyć także integracji światów serwerów i klientów ze zwykłym
dniem dniem pracy.
◦ Stopniowe przejście do środowiska OSS umożliwi
łagodna˛ migracj˛e i pokaże w praktyce, że możliwe jest przeniesienie woli politycznej w kierunku
OSS.
◦ W średniej i długiej perspektywie czasu ujawnia˛
si˛e w całej administracji oraz obywatelom wyraźne wartości dodane wynikajace
˛ z projektów migracyjnych.
4.6
Powszechność / dost˛epność oprogramowania
W5
4.6.1
Stopień przenikni˛ecia rynku
P7
◦ Produkty, które należy zastosować sa˛ bez problemu dost˛epne na rynku
4.6
W5
4.6.2
Niezależne wsparcie
P6
◦ Wsparcie dla wykorzystywanych produktów oferuja˛ oprócz producentów także liczne niezależne
przedsi˛ebiorstwa
438
4.6
W5
4.6.3
Posiadane certyfikaty na oprogramowanie
P5
◦ Produkty, które należy zastosować dysponuja˛ właściwymi referencjami albo certyfikatami
4.6
4.6.4
Dost˛epne narz˛edzia do administrowania oprogramo-
W5
P5
waniem
◦ Narz˛edzia administracyjne dost˛epne sa˛ w wystarczajacym
˛
stopniu
4.7
Bezpieczeństwo informatyczne
W6
4.7.1
Bezpieczeństwo komunikacji
P7
◦ Komunikacja z wewn˛etrznymi i zewn˛etrznymi
partnerami jest dobrze zagwarantowana
4.7
W6
4.7.2
Bezpieczeństwo aplikacji
P6
◦ Aplikacje sa˛ dojrzałe.
4.7
W6
4.7.3
Zabezpieczenie przed awariami
P7
◦ Systemy OSS sa˛ w każdym przypadku lepiej zabezpieczone przed awariami
439
4.7
W6
4.7.4
Zarzadzanie
˛
bezpieczeństwem
P7
◦ Systemy OSS dysponuja˛ udokumentowanymi i
dost˛epnymi dla wszystkich zainteresowanych mechanizmami bezpieczeństwa
4.7
W6
4.7.5
Bezpieczeństwo inwestycji i planowania
P8
◦ Inwestycja jest pewna, produkty b˛eda˛ dost˛epne
także w przyszłości jeszcze przez typowy dla urz˛edów okres pi˛eciu lat. Systemy OSS pracuja˛ stabilnie a budowane w oparciu o nie procesy można
pewnie planować.
Tablica 4.61: Przykład analizy korzyści: czynniki jakościowo - strategiczne
Rozdział 5
Zalecenia migracyjne
5.1 Ogólne wyjaśnienia
5.1.1 Droga do podj˛ecia decyzji
O zaleceniu migracji badź
˛ kontynuacji decyduja˛ wyniki oceny ekonomicznej przygotowanej pod
katem
˛
długofalowym. Także wówczas, gdy z technicznego punktu widzenia możliwe jest bez
ograniczeń wybranie migracji całkowitej albo cz˛eściowej, w danych warunkach brzegowych
wzgl˛edy ekonomiczne moga˛ sprawić, że w/w drogi migracji b˛eda˛ mało sensowne. Dlatego ze
wzgl˛edu na różne zwiazki
˛ pomiedzy poszczególnymi składnikami oraz systemami infrastruktury
informatycznej i świata aplikacji, podczas szukania właściwej decyzji trzeba stale uwzl˛edniać
perspektyw˛e długofalowa.
˛
Przy tym ocena pod katem
˛
wprowadzenia oprogramowania Open Source nie różni si˛e od
zwykłych analiz w branży informatycznej, np. w kontekście konsolidacji osprz˛etu i oprogramowania. Strategiami, którymi w równym stopiniu należy si˛e zazwyczaj kierować w administracji
publicznej i w gospodarce sa:
˛
◦ oparte o otwarte standardy i specyfikacje ściś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˛eściowo
udost˛epnianymi interfejsami i specyfikacjami) ściś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).
Ponieważ 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 źródłowego wielokrotnego użytku.
Podczas, gdy decyzja o punktowym zastosowaniu szeroko dost˛epnego produktu o otwartym kodzie źródłowym, jakim jest np. serwer WWW Apache, może być z reguły bardzo pragmatyczna
i sprawnie podj˛eta, decyzja dotyczaca,
˛ np. wprowadzenia oprogramowania Open Source na całej
powierzchni i zastapienia
˛
własnościowych wysp, z uwagi na swoje długofalowe skutki wymaga
podejś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 innowacyjnoś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 możliwości ponownego zastosowania, jak też kompatybilności
◦ wybór produktów spełniajacych
˛
wymagania
◦ zdefiniowanie zamiaru migracyjnego oraz zaplanowanie zwiazanych
˛
z nim czasu i akcji,
jak też zapewnienie finansowania
W poszczególnych etapach nieniejszego procesu można korzystać z już stosowanych w administracji publicznej metod i narz˛edzi zgodnie z poniższym rysunkiem.
442
Rysunek 5.1: Proces decyzyjny prowadzacy
˛ do wdrożenia OSS
5.1.2 Ogólne zalecenia
Z uwagi na różne punkty wyjścia (wraz z istnieniem rozwiazań
˛
wyspowych) i różna˛ jakość produktu bardzo rzadko można ogólnie wypowiadać si˛e o zaletach ekonomicznych w/w strategii
platform. Jednak generalnie obowiazuje
˛
zasada, że wraz ze rosnacym
˛
stopniem integracji produktów jednej platformy z wielu powodów rośnie łaczna
˛
opłacalność:
◦ wskutek wyższej produktywności, w przypadku dobrze (brak awarii systemu) dostosowanych do siebie produktów
◦ wskutek rosnacej
˛ możliwości ponownego zastosowania składników i rozwiazań,
˛
które rozwini˛ete zostały za pomoca˛ jednakowej technologii Middleware
◦ wskutek oszcz˛edności w przypadku ujednoliczenia procedur zakupu i konserwacji albo
umów kupna i konserwacji.
Ponadto obowiazuje
˛
zasada, że wraz z rosnacym
˛
stopniem standaryzacji opartej na otwartych
standardach łaczna
˛
opłacalność rośnie z wielu powodów:
◦ wskutek wprowadzenia konkurencji pomi˛edzy produktami i rozwiazaniami
˛
◦ wskutek mniejszego uzależnienia od producenta
◦ wskutek powstania w sumie szerszego rynku usług
443
Bezpieczeń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, że możliwy staje si˛e jeszcze do niedawna
trudny scenariusz pełnej migracji.
Wychodzac
˛ z powyższego założenia można sformułować nast˛epujace
˛ podstawowe zalecenia
odnośnie zastosowania produktów o otwartym kodzie źródłowym:
◦ zaleca si˛e przyj˛ecie kryterium opłacalności jako obrazu przewodniego całej strategii informatycznej przy umiarkowanym uwzgl˛ednieniu czynników innowacyjności i oraganizacji
◦ zaleca si˛e wykorzystanie systemu operacyjnego GNU/Linux jako podstawowej platformy
informatycznej dla wszystkich obszarów zastosowań, w razie gdy adekwatne sa˛ założenia
dotyczace
˛ migracji pełnej albo cz˛eś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łeczność Otwartego Oprogramowania (Open Source Community) jako podstawy dla dokonania wyboru i integracji oprogramowania w celu unikni˛ecia
zewn˛etrznych zależnoś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 przejście na platform˛e OSS- / COLS może okazać si˛e ekonomicznie bardziej sensownym (opłacalnym) wariantem niż migracja kontynuacyjna do nowej wersji produktów Microsoftu.
Odejście od kosztów licencji lub ich redukcja może w wielu przypadkach prowadzić do bezpośrednich (pieni˛eżnych) oszcz˛edności, np. w przypadku:
◦ migracji cz˛eściowej po stronie serwera, połaczonej
˛
z konsolidacja˛ osprz˛etu i oprogramowania, gdy dost˛epna jest już wiedza z zakresu rozwiazań
˛
uniksowych (Know-how) oraz
systemy uniksowe
◦ punktowego zastapienia
˛
członków wcześniejszej rodziny Back-Office (obecnie .NET Enterprise Server), przykładowo serwerów Exchange albo SQL, zwłaszcza przy dużych i
rosnacych
˛
ilościach użytkowników i zwi˛ekszajacych
˛
si˛e zarazem opłatach licencyjnych
444
◦ migracji cz˛eściowej po stronie klienta z produktów MS Office, gdy nie uniemożliwi ona
korzystania ze środowiska Office jako bieżacego
˛
środowiska dla makr lub aplikacji
W wielu innych scenariuszach wdrożeń, aby ocenić oszcz˛edności trzeba wziać
˛ pod uwag˛e wymiar strategiczny, który został szczegółowo opisany w rozdziale „Ocena wydajności ekonomicznej“.
W razie migracji obecnych platform do świata Linuksa albo do nowej platformy Microsoftu
należy, z ekonomicznego punktu widzenia, w każdym przypadku zaplanować nakłady na szkolenia. Ponieważ realnie pojawia˛ si˛e one w przypadku obydwu alternatywnych typów migracji,
ten blok kosztów należy oceniać dalece neutralnie, jako bezpośrednio porównywalny. W każdym
przypadku oznacza to, że dla obydwu alternatyw należy uwzgl˛ednić koszty migracji istniejacych
˛
aplikacji specjalistycznych1 .
Ponieważ podstawowe zalecenia nie moga˛ uwzgl˛edniać wymagań i warunków brzegowych
konkretnej sytuacji wyjściowej, dalsze zalecenia odnosza˛ si˛e do róż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
środowiska mieszanego (migracja cz˛eściowa).
5.2 Całkowita „zast˛epujaca
˛ migracja”
Zgodnie z założeniami niniejszego poradnika migracyjnego całkowita migracja ma miejsce wtedy,
gdy nast˛epuje wdrożenie Linuksa jako systemu operacyjnego na poziomie wszystkich składników infrastruktury informatycznej. Z powszechna˛ zamiana˛ systemu operacyjnego zwiazana
˛
jest
na ogół także zmiana na poziomie integracji i aplikacji wskutek wykorzystania produktów zgodnych z SAGA, ponieważ zwłaszcza potrzebne do tego produkty Java nie rozpowszechniły si˛e
dotychczas na platformach windowsowych2 w oczekiwany sposób.
Przy całkowitej migracji można zasadniczo korzystać 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 każdego urz˛edu, których nie można dostarczyć w ramach
poradnika. W poszczególnym przypadku zaprezentowane w ocenie ekonomicznej wymiary moga˛ si˛e zmieniać po
właczeniu
˛
stwierdzonych koszów migracji aplikacji specjalistycznych.
2
W tym przypadku konieczność zastapienia
˛
nie dotyczy rozpowszechnionych także pod Windows aplikacji webowych z modelu (L)AMP.
3
Patrz definicja z rozdziału 2
445
wszechnie dost˛epnym kodem źródłowym i bezpłatne, rozwijane przez Społeczność Otwartego Oprogramowania
◦ COLS: KOmercyjne Oprogramowanie Linuksowe – „KOOL“: linuksowe oprogramowanie
komercyjne o otwartym kodzie źródłowym albo własnościowe, jako oferta producentów
oprogramowania.
Ponieważ w wielu obszarach administracji intensywnie używa si˛e zarówno rozwini˛etych we własnym zakresie i opertych na Windows procedur specjalistycznych, jak też opartych na ERP systemów zarzadzania
˛
aplikacjami, całkowitego pokrycia wymagań za pomoca˛ oprogramowania
Open Source w dajacym
˛
si˛e przewidzieć czasie można oczekiwać tylko w obszarze infrastruktury. Uwzgl˛edniajac
˛ wsparcie Linuksa przez dost˛epność dużych systemów użytkowych pochodzacych
˛
od takich producentów jak SAP albo Oracle, zastosowanie komercyjnego oprogramowania oraz rosnac
˛ a˛ ofert˛e oprogramowania linuksowego należy w sumie ocenić pozytywnie, jeśli
chodzi o dalszy rozwój platformy Open Source, i liczyć si˛e z jej dalszym rozwojem.
Indywidualne wybicie si˛e możliwych i zalecanych systemów i architektur oprogramowania
różni si˛e w zależności od intensywności informatycznej („obciażenia“)
˛
i stopnia wyspecjalizowania urz˛edów. Z jednej strony odgrywaja˛ tu decydujac
˛ a˛ rol˛e skalowalność i niezawodność
poszczególnych składników a z drugiej także nakłady zwiazane
˛
z wdrożeniem.
Z tych powodów każdorazowo wyróżnione i ocenione zostały zagadnienia dotyczace
˛ dużych
oraz średnich, jak też specjalizowanych oraz małych urz˛edów. Jako wprowadzenie zaprezentowano najpierw ogólny, gatunkowy model zadań infrastrukturalnych.
5.2.1 Model architektury
W przypadku powszechnego zastosowania Linuksa jako platformy dla serwerów i aplikacji
klienckich można wyróżnić – analogicznie do tradycyjnych architektur uniksowych i windowsowych – dwa typy architektur klienckich: Fat Clients i Thin Clients.
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 sprzedaż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 zadań:
◦ 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)
447
◦ drukowanie (Print Server)
◦ autoryzacja
◦ usługi sieciowe (m. in. serwer DNS & DHCP).
Obszary na rysunku 5.2 zaznaczone grafitowa˛ kratka˛ moga˛ być stosowane bez wzgl˛edu na wielkość i stopień wyspecjalizowania każdego urz˛edu. Zwyczajne składniki systemu ocenione zostały w poniższych rozdziałach w zależności od danego scenariusza ich wykorzystania. Przewidziano scenariusze dla:
◦ dużych i średnich urz˛edów
◦ specjalizowanych urz˛edów świadczacych
˛
usługi informatyczne
◦ małych urz˛edów.
Uwaga: w przypadku ocenianych scenariuszy migracji należy generalnie uwzgl˛ednić kilka ograniczeń:
Oceny techniczne pokazuja,˛ że z małymi wyjatkami
˛
dla wszystkich produktów Microsoftu,
które sa˛ cz˛eścia˛ składowa˛ analizowanej sytuacji wyjściowej (patrz rozdział 2.2.1), dost˛epne sa˛
alternatywne rozwiazania
˛
OSS badź
˛ COLS umożliwiajace
˛ migracj˛e zast˛epujac
˛ a.˛ Krytycznymi
punktami sa:
˛
◦ kompatybilność pomi˛edzy OpenOffice.org / StarOffice a MS Office nie jest pełna. Ma to
szczególny wpływ na każdego użytkownika, który musi cz˛esto tworzyć z innymi użytkownikami wpólne dokumenty. Jeś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 badź
˛ ze StarOffice nie wykazuje tych samych możliwości,
co MS Excel Chart-Engine. Dotyczy to w szczególnoś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 rozwiazań
˛
OSS i produktów COLS moga˛ jednak raczej
przeszkadzać powody ekonomiczne niż funkcjonalne. Dotyczy to zwłaszcza migracji desktopów:
448
◦ MS Office
Zakres i złożoność migrowanych makr, skryptów, szablonów i dokumentów może sprawić,
że przejś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
zastapić,
˛
używanych cz˛esto do automatyzacji prostych procesów.
◦ aplikacje specjalistyczne
W zależności od stopnia wykorzystania natywnych windowsowych aplikacji specjalistycznych, w niekorzystnym przypadku migracja zast˛epujaca
˛ może być niemożliwa do czasu,
gdy dost˛epne b˛eda˛ alternatywne produkty. (patrz rozdział 5.3). Dotyczy to takż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 można zalecić określonej dystrybucji (patrz 0). Decyzj˛e należy podjać
˛ dla konkretnego przypadku i w zależności
od specyficznych wymagań danej administracji. Do zastosowań w obszarze biura można polecić
zarówno OpenOffice.org, jak i StarOffice. Decyzja odnośnie wyboru tego lub innego produktu
zależy od specyficznych wymagań 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 funkcjonalności. Dla produktu COLS,
jakim jest StarOffice Suite, firma Sun stworzyła badź
˛ zaimplementowała dodatkowe składniki
(czcionki TrueType, własne sprawdzanie pisowni, dodatkowe szablony oraz galeri˛e zdj˛eć, baz˛e
danych ADABAS). W przeciwieństwie do tego OpenOffice.org jest członkiem rodziny OSS i nie
wymaga kosztów licencyjnych. Różnice funkcjonalne i techniczne pomi˛edzy tymi obydwoma
pakietami biurowymi sa˛ marginalne.
Kolejnym ważnym interfejsem dla użytkowników jest właś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 najważniejszymi przedstawicielami systemów desktopowych sa˛ KDE i GNOME. Wybór systemu desktopowego jest w
pierwszej kolejności odpowiedzia˛ na pytanie o własny gust i każdorazowe preferencje wzgl˛edem
określonych aplikacji.
5.2.1.2
449
Serwer WWW
Serwer Apache (patrz także rozdział 3.11.4) jest obecnie miernikiem udost˛epniania treści w Internecie i Intranecie. Elastyczność uzyskana dzi˛eki modularnej budowie i ilość 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 dużych produkcyjnych środowiskach, stabilnościa,˛ pełnymi
funkcjami bezpieczeństwa i dost˛epnym, szerokim, profesjonalnym wsparciem, które można sobie dowolnie wybrać.
5.2.1.3
Składowanie plików
Dla usług zwiazanych
˛
z plikami wewn˛etrz ś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 sieć. NFS jest standardowo używanym protokołem,
gdy trzeba współdzielić katalogi z różnych systemów uniksowych. Użytkownikom można udost˛epniać potrzebne katalogi za pomoca˛ centralnych albo zdecentralizowanych serwerów. Eksportowane drzewa katalogów automatycznie przypisywane sa˛ użytkownikom pracujacym
˛
na danej
stacji roboczej.
Do fizycznego zapisywania danych na systemach dysków właś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óżniajacym
˛
si˛e systemem praktycznie we wszystkich systemach uniksowych i de - facto standardem we wszystkich dużych dystrybucjach (SuSE, Debian, RedHat, itd.).
Usługa drukowania CUPS oferuje wszystkie konieczne funkcje do udost˛epniania infrastruktury
wydruku. CUPS obsługuje wiele różnych drukarek i jest w stanie udost˛epniać konkretnym uż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-
450
cji Domain Name System zelecana jest implementacja referencji BIND (Berkeley Internet Name
Domain), do obsługi DHCP również wskazana jest implementacja referencji z Internet Software
Consortium.
5.2.2 Średnie i duże urz˛edy
Średnie i duże urz˛edy odznaczaja˛ si˛e swoimi szczególnymi architekturami informatycznymi i
potrzebuja˛ w niektórych obszarach zastosowań innych zaleceń migracyjnych niż mniejsze placówki. Poczawszy
˛
od pewnej wielkości, urz˛edy dysponuja˛ na ogół zarówno architekturami zdecentralizowanymi, jak też centralnymi. Pierwsze sa˛ najcz˛eś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 odnośnie bezpieczeństwa informatycznego, wydajności i skalowalności. Wewn˛etrznie definiowane standardy jakości wymuszaja˛ gwarancj˛e wysokiej niezawodności i intensywnej opieki
użytkowników nad centralnymi składnikami. Wykonanie tego typu zadań można zagwarantować tylko poprzez intensywne stosowanie platform do zarzadzania
˛
systemem, w szczególnoś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 wymagań technicznych i wymagań zwiazanych
˛
z architektura,
˛
oprócz składników wymienionych w rozdziale 5.2.1 zalecane sa˛ zwłaszcza składniki dostosowane do szczególnych wymagań dużych środowisk.
Odnośnie zaleceń dotyczacych
˛
oceny ekonomicznej w przypadku migracji zast˛epujacej
˛ w
dużych i średnich urz˛edach patrz rozdział 4.6.1 oraz 4.8.6.5.
451
Rysunek 5.3: Zalecana architektura IT w duż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
˛ dużych centralnych architektur informatycznych różnia˛ si˛e zwłaszcza z uwagi na stabilność, wydajność i bezpieczeństwo.
Z czystych stystemów bazodanowych należacyh
˛
do rodziny Open Source, wi˛ekszym urz˛edom zaleca si˛e, ze wzgl˛edu na spełnienie wymagań, 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 także Trigger i Stored Procedures.
Jeś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.
5.2.2.2
452
Groupware
Dobrze skalowalnym rozwiazaniem
˛
opartym na Linuksie i odpowiednim dla dużych środowisk
jest Samsung Contact (produkt COLS). Z uwagi na swoja˛ architektur˛e, która składa si˛e z wielu
niezależnych od siebie komponentów dajacych
˛
si˛e w myśl skalowania horyzontalnego przydzielać do różnych serwerów, spełnia on szczególne wymagania dużych środowisk. Oprócz instalacji
Single - Server, Samsung Contact obsługuje również instalacj˛e dzielona˛ pomi˛edzy wieloma stanowiskami i tym samym oferuje skalowalne rozwiazanie
˛
takż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
bezpieczeń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
też z powodu rosnacych
˛
wymagań wzgl˛edem komfortu autoryzacji, znany już wcześniej model
Directories (usługi katalogowe) oraz Meta-Directories został uzupełniony o kolejne składniki i
przekształcony w całościowy system nazywany cz˛esto Identity Management (patrz także poniższy rysunek). RYSUNEK DO POPRAWKI
Rysunek 5.4: Obszary zastosowań usług katalogowych na przykładzie platformy SunOne
Zasadniczo przy budowaniu usług katalogowych można skorzystać zarówno z produktów
OSS, jak i COLS. Można tu wyróżnić dwa istotne scenariusze zastosowań:
1. Realizacja podstawowych funkcji umożliwiajacych
˛
autoryzacj˛e oraz zarzadzanie
˛
profilami
w oparciu o protokół LDAP.
W tym przypadku alternatyw˛e OSS jaka˛ jest OpenLDAP należy na ogół postrzegać jako
wystarczajac
˛ a˛ i opłacalna.˛
2. Realizacja rozszerzonych funkcji umożliwiajacych
˛
zwi˛ekszenie wydajności zarzadzania,
˛
np. poprzez obejmujac
˛ a˛ wiele aplikacji synchronizacj˛e wykorzystywanych danych lub autoryzacj˛e.
453
W tym przypadku można generalnie wyjść z założenia, że zastosowanie komercyjnych
produktów b˛edzie korzystniejsza finansowo od własnego rozwiazania.
˛
5.2.2.4
Zarzadzanie
˛
systemem
Jeśli chodzi o spełnienie zwi˛ekszonych wymagań odnośnie zarzadzania
˛
systemem narzuca si˛e,
np. skorzystanie z produktów Tivoli albo OpenView. Oprócz tych komercyjnych rozwiazań
˛
istnieja˛ inne możliwości zarzadzania
˛
systemem z wykorzystaniem narz˛edzi wchodzacych
˛
w skład
systemu operacyjnego, które wykonuja˛ określone zadania (patrz rozdział 3.6).
5.2.3 Specjalizowane urz˛edy świadczace
˛ usługi informatyczne
Urz˛edy, które m.in. wyst˛epuja˛ także jako specjalizowani dostawcy usług informatycznych w
ś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
świadcza˛ usługi informatyczne dla innych urz˛edów, np. jako tak zwany „Application Service Provider“ (ASP). Dominujace
˛ centralne architektury służace
˛ realizacji konkretnych procedur specjalistycznych (ERP, . . . ) cz˛esto łacz
˛ a˛ si˛e z bardzo wysokimi wymaganiami odnośnie wydajności i
skalowalności systemów. Dlatego stosuje si˛e tam cz˛esto wysokowartościowe i po cz˛eści drogie
systemy oprzyrzadowania
˛
przeznaczone do wykonywania automatycznych obliczeń, np. Storage
Area Networks (SAN) do zabezpieczania i archiwizacji danych. Takie specjalizowane urz˛edy
przykładaja˛ duża˛ wag˛e do bezpieczeństwa informatycznego, wydajności i skalowalności. Zdefiniowane tam standardy jakości, które z reguły potwierdzane sa˛ z każdym klientem na piśmie,
wymagaja˛ wysokiej niezawodności systemu i intensywnej opieki użytkowników. W celu efektywnego zarzadzania
˛
systemem stosuje si˛e specjalne platformy do zarzadzania
˛
systemem, które
oferuja˛ wysoki stopień automatyzacji. Centra obliczeniowe wymagaja˛ dodatkowo efektywnego
wsparcia systemu w przypadku First- i Second-Level Support łacznie
˛
z rozległym zarzadzaniem
˛
problemami.
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 określonego osprz˛etu (SAN)
oraz oprogramowanie były certyfikowane, gdyż dopiero wówczas wolno je w nich stosować.
Wiele systemów bazodanowych opartych na Linuksie (SAP DB, Oracle, DB2, itd.) posiada już
odpowiednie certyfikaty. Użytkownicy centrów obliczeniowych moga˛ dodatkowo korzystać z
certyfikowanych dystrybucji Linuksa jako podstawowego systemu oparacyjnego dla każdorazowych zastosowań.
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
jednocześnie udost˛epniajac
˛ zewn˛etrzne systemy. Serwer aplikacji musi być w stanie zagwarantować zarzadzanie
˛
sesjami użytkowników, udost˛eniać odpowiednie interfejsy zewn˛etrznym aplikacjom oraz dysponować 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 także możliwość 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˛eściowo porównywalne wymagania, obowiazuj
˛ a˛ takie same zalecenia, jak w przypadku dużych i ś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. Duże procedury na
ogół wykonywane sa˛ poza własnym urz˛edem. Zadania takie cz˛esto zlecane sa˛ centrom obliczeniowym. Zdefiniowane standardy jakości obowiazuj
˛ ace
˛ wewnatrz
˛ urz˛edu nie stawiaja˛ szczególnych wymagań, jeśli chodzi o niezawodność i opiek˛e uż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 zadań za pomoca˛
pojedynczych narz˛edzi i skryptów. Mniejsze placówki cechuja˛ si˛e małymi do średnich wymaganiami wzgl˛edem bezpieczeństwa informatycznego, wydajności i skalowalnoś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, że produkty OSS musza˛ być zawsze dostosowane do rozmiaru realizowanych
zadań. Skalowalne produkty takie jak Samsung Contact albo SunOne Directory Server moga˛
spełnić wszystkie wymagania mniejszych urz˛edów. Należy jednak wiedzieć i zastanowić si˛e nad
456
tym, że duże rozwiazania
˛
z reguły wymagaja˛ wi˛ekszych nakładów podczas instalacji i konfiguracji.
Odnośnie zaleceń co do oceny ekonomicznej w przypadku migracji zast˛epujacej
˛ dla dużych
i ś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óżnorodna. Wszystkie systemy baz danych, które szczegółowo ocenione zostały w rozdziale 3.13.4, dobrze nadaja˛
si˛e do zastosowania w nakreślonych tam ramach.
W oparciu o funkcjonalne właściwości nie można ogólnie, prosto i jednoznacznie wskazać
SAP DB, MySQL albo PostgreSQL jako zalecanej bazy danych. Decyzja o wyborze tego badź
˛
457
innego systemu bazodanowego musi zapaść osobno w każdym przypadku, w zależności od planowanego środowiska programistycznego i runtime environment, zwłaszcza w kontekście rozwoju aplikacji WWW i DB z udziałem PHP. Jednak z uwagi na ścisła˛ integracj˛e z tym j˛ezykiem
programowania optymalnym rozwiazaniem
˛
może być MySQL.
5.2.4.2
Groupware
Oprócz zalecanego w przypadku dużych urz˛edów Samsung Contact, również dla małych placówek skorzystanie z niego jest możliwe. Poza tym rozwiazaniem,
˛
jeśli chodzi o małe do średnie
organizacje, w przyszłości liczyć si˛e może z pewnościa˛ takż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łości Kroupware oferowane b˛edzie na
licencji GPL i jako takie, z uwagi na apsekt pieni˛eżny, rozwiazanie
˛
to b˛edzie stanowić interesujac
˛ a˛ alternatyw˛e. W tym kontekście należy wskazać na to, że możliwe tu b˛edzie korzystanie z
wtyczki Open Source o nazwie „Ägypten“ b˛edacej
˛ narz˛edziem zgodnym ze SPHINX i służacym
˛
do szyfrowania i podpisywania poczty elektronicznej.
Urz˛edy, które ze wzgl˛edu na prac˛e w trybie offline nie potrzebuja˛ rozwiazań
˛ umożliwiajacych
˛
prac˛e grupowa,
˛ moga˛ także korzystać z klienta WWW. W takim przypadku możliwe rozwiazanie
˛
stanowi również phpGroupware.
5.2.4.3
Usługa katalogowa
Dla urz˛edu, w którym ważne informacje przekazywane sa˛ poprzez sieć, zaleca si˛e zastosowanie
usługi katalogowej OSS jaka˛ jest OpenLDAP. Usługa ta może służyć, m.in. do administrowania
użykownikami, autoryzacji użytkowników, inwentaryzacji posiadanego osprz˛etu i innych ustawień infrastrukturalnych (wpisy DNS, konfiguracje DHCP, itd.). OpenLDAP oferuje wszystkie
powszechne i konieczne funkcje (patrz rozdział 3.7.4) pełnowartoś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˛eżne interpretatory pracujace
˛ z linii poleceń, Utilities i interpretowane j˛ezyki programowania) można
zaprz˛egnać
˛ do zautomatyzowania pracy Routine. Inne narz˛edzia i produkty służace
˛ do administrowania systemem przedstawione zostały w rozdziale 3.6.
458
5.3 Całkowita „kontynuacyjna migracja”
Całkowicie kontynuacyjna oznacza, że we wszystkich obszarach zachowana zostaje linia produktów firmy Microsoft. Teoretycznie można sobie wyobrazić dwie sytuacje wyjściowe, które
uzasadniaja˛ tego typu migracj˛e.
W żadnej z opisanych poniżej sytuacji powody techniczne nie odgrywaja˛ jednak decydujacej
˛
roli. Z małymi wyjatkami,
˛
dla każdego z ocenianych wymagań istnieja˛ alternatywne rozwiaza˛
nia techniczne, które moga˛ pracować pod kontrola˛ Linuksa. W końcu to ekonomiczne powody
przyczyniaja˛ si˛e do realizacji całkowitej „kontynuacyjnej migracji“.
Pierwsza z ocenianych tu sytuacji wyjściowych została opisana w rozdziale 2 niniejszego
poradnika jako środowisko systemu Windows NT 4 z Exchange 5.5, MS SQL Server 7, IIS 4
oraz Office 97 badź
˛ Office 2000. Jest ona nacechowana już bardzo wysokim stopniem integracji.
Wielkościami określajacymi
˛
stopień integracji sa˛ m. in.:
◦ ilość specjalistycznych procedur dost˛epnych tylko jako aplikacje windowsowe
◦ dost˛epność kodu źródłowego tych procedur
◦ gł˛ebokość integracji poszczególnych specjalistycznych procedur, zwłaszcza w środowisku
MS Office
◦ zakres wykorzystania specyficznych dla Microsoftu
– środowisk programistycznych
– interfejsów
– j˛ezyków programowania
◦ ilość 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˛
wypowiedź na temat, jaki stopień integracji uzasadnia przeprowadzenie migracji kontynuacyjnej, można sformułować 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
wyjściowa, która ujawni tak wysoki stopień integracji, przy którym migracja b˛edzie znacznie
459
utrudniona. Takiemu rozwojowi sytuacji można zapobiec dzi˛eki przeprowadzeniu we właściwym czasie migracji cz˛eściowej (patrz rozdział 5.4).
Rysunek 5.7: Sytuacja wyjściowa dla migracji kontynuacyjnej
Druga z ocenianych sytuacji wyjściowych przedstawia środowisko informatyczne, w którym
już dokonano pełnej migracji do Windows 2000 i ogólnej implementacji Active Directory (patrz
rys. 5.7). Migracja przerpowadzona została całkiem niedawno, np. w roku 2002. W odniesieniu
do podstawowego modelu architektury z zaleceń migracyjnych (5.2.1) oznacza to, ż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
460
◦ usługi infrastrukturalne:
Windows 2000 Server (Advanced Server)
(składowanie plików, drukowanie i usługi sieciowe).
Jeśli pojedyncze elementy niniejszej architektury (jeszcze) nie sa˛ używane, wówczas w ramach
migracji cz˛eściowej można w ich miejsce zaproponować 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 wyjściowej uzasadnia to, żeby znajdujace
˛ si˛e już w użyciu składniki nie podlegały migracji zast˛epujacej
˛ ani cz˛eściowej w czasie
najbliższych 4 - 5 lat.
Poniżej wymienione zostały przyczyny, dla których tego typu sytuacja wyjściowa mimo
wszystko jest rozważana w zaleceniach migracyjnych:
◦ niniejszym urz˛edom wskazuje si˛e drogi minimalizacji wspomnianego wyżej stopnia integracji i tym samym zależności od produktów Microsoftu.
◦ niniejszym urz˛edom przekazuje si˛e ponadto zalecenia odnośnie późniejszej drogi migracji,
w stopniu jaki jest obecnie możliwy.
◦ z długofalowego ekonomicznego punktu widzenia migracja kontynuacyjna nie jest szczególnie zalecana, zwłaszcza w kontekście uzależniania si˛e od producenta. Migracja kontynuacyjna może mieć sens przede wszystkim wówczas, gdy koszty migracji w obszarze
specjalistycznych aplikacji opartych na platformie Microsoftu i wymagajacych
˛
przeprogramowania w przypadku przejścia do Open Source, nie wykazuja˛ długofalowej rentowności takiej migracji.
◦ odnośnie zaleceń dotyczacych
˛
oceny ekonomicznej migracji kontynuacyjnej patrz rozdział4.6.2
i 4.8.6.6.
5.3.1 Minimalizacja stopnia integracji, zachowanie stopni dowolności
Jak już wspomnieliśmy, celem w przypadku migracji kontynuacyjnej i korzystanie z Windows
2000 wraz z Active Directory powinna być redukcja uzależnienia od produktów Microsoftu, tak
by w przyszłości można było skorzystać ze wszystkich możliwości migracji zast˛epujacej.
˛
Należy
zatem przestrzegać nast˛epujacych
˛
zaleceń:
461
Usłga katalogowa:
◦ wykorzystywanie Active Directory, jeśli w ogóle, powinno mieć miejsce tylko jako „Active
Directory w minimalnej postaci“ (patrz rozdział 3.7.5).
◦ nie należy stosować AD jako źródła LDAP dla dodatkowych aplikacji (np. aplikacji webowych).
◦ dane osobowe dla AD należy pozyskiwać z różnych źródeł, np. przenoszac
˛ je albo wypełniajac
˛ z MetaDirectory.
◦ jeśli zaplanowano role concept należy unikać stosowania oprogramowania, które wymaga
AD badź
˛ w przypadku którego AD jest podstawa˛ działania
Desktop
◦ nie należy stosować aplikacji MS Access. W zamian za to preferowane jest korzystanie z
centralnej bazy danych oraz aplikacji napisanych, np. w PHP.
◦ sensowne jest zebranie i szczegółowe przeanalizowanie aplikacji VBA oraz ich skonsolidowanie, o ile nie zostało to już zrobione podczas migracji. W miar˛e możliwości należy
unikać wprowadzania nowych aplikacji z tego zakresu.
◦ wyboru aplikacji i zlecanie ich rozwoju należy dokonywać w zgodności z SAGA (patrz
rozdział 3.8).
◦ w miar˛e możliwości nie należy korzystać z aplikacji innych producentów, których programy wymagaja˛ do pracy produktów MS Office jako jedynego runtime environment. Wyjatkiem
˛
sa˛ tu specjalistyczne aplikacje, jeśli przejściowo nie istnieja˛ dla nich rozwiazania
˛
alternatywne.
◦ należy sukcesywnie zast˛epować aplikacje (specjalistyczne) wymagajace
˛ do pracy produktów MS Office.
Składowanie plików
◦ odtworzenie struktur uprawnień należy wykonać za pomoca˛ skryptów (np. Perl). W przypadku pracy w środowisku graficznym konieczne jest szczegółowe i pełne udokumentowanie wszystkich ustawień konfiguracyjnych. Ponieważ z uwagi na znane ludzkie słabości
nie zawsze można to zagwarantować, lepsza˛ droga˛ jest skorzystanie ze skryptów.
462
◦ jeśli nie ma potrzeby używania lokalnych grup, to nie należy ich używać.
Groupware / Messaging
◦ serwery Exchange 2000 nie powinny być stosowane jako centralne Mail - Router. Zamiast nich należy skorzystać z produktów OSS (np. Postfix, Sendmail), co ma na celu
pozostawienie otwartej możliwości na równoległe korzystanie z wielu systemów poczty
elektronicznej.
◦ w publicznych katalogach Exchange nie należy stosować aplikacji.
Aplikacje WWW
◦ ze wzgl˛edu na zgodność z SAGA i dost˛epność różnych alternatywnych rozwiazań
˛
nie należy stosować produków Microsoftu (patrz rozdział 3.9)
◦ należy unikać autoryzacji domen stosujac
˛ dodatkowy poziom autoryzacji. Dodatkowe hasło można z reguły zaakceptować i przede wszystkim uzasadnić z punktu widzenia bezpieczeństwa. W wyjatkowych
˛
sytuacjach można skorzystać z różnych produktów OSS.
Zarzadzanie
˛
systemem
◦ należy zastosować produkty innych producentów, którzy wspieraja˛ także rozwiazania
˛
linuksowe (np. Tivoli).
Middleware
◦ jeśli chodzi o środowisko programistyczne, w celu zwi˛ekszenia możliwości wielokrotnego
wykorzystania kodu, należy preferować gł˛eboka˛ integracj˛e ze standardami zgodnymi z
SAGA.
◦ w celu komunikacji i wymiany danych z zewn˛etrznymi systemami należy stosować technologi˛e XML i Web Service (jeśli pozwalaja˛ na to wzgl˛edy bezpieczeństwa, patrz rozdziały
4 i 5).
463
5.3.2 Inne ścieżki migracji
Jeśli chodzi o dalsza˛ migracj˛e, należy najpierw rozpatrzeć migracj˛e na stacjach roboczych do
Windows XP. Także tu obowiazuje
˛
reguła ochrony inwestycji. Ze wzgl˛edu na nia,˛ w przypadku
opisanej powyżej sytuacji wyjściowej, migracja na stacjach roboczych do Windows XP może
nie być zalecana.
Jeśli uwzgl˛edni si˛e zasad˛e ochrony inwestycji, wówczas kolejna migracja powinna odbyć
si˛e najwcześniej po upływie 4 - 5 lat. Jeśli zatem poprzedniej migracji dokonano w 2001 roku,
wówczas nast˛epna może odbyć si˛e najwcześniej w roku 2005. Szczególnie urz˛edy, które wcześniej postapiły
˛
zgodnie z zaleceniami dotyczacymi
˛
minimalizacji uzależnienia od produktów Microsoftu, musza˛ koniecznie sprawdzić czy w swoich technicznych i ekonomicznych warunkach
powinny przeprowadzić migracj˛e zast˛epujac
˛ a˛ czy kontynuacyjna.˛ To samo dotyczy wszystkich
innych urz˛edów, które znajduja˛ si˛e w takiej samej sytuacji wyjściowej.
5.4 Migracja cz˛eściowa
5.4.1 Migracja punktowa
Migracja punktowa polega na trwałym zastapieniu
˛
składnika systemu b˛edacego
˛
produktem Microsoftu przez rozwiazanie
˛
OSS badź
˛ COLS, podczas gdy pozostała migracja jest migracja˛
kontynuacyjna.
˛ W niniejszym rozdziale przedstawione zostały sensowne i wykonalne migracje
punktowe.
Najważniejsza˛ migracja˛ punktowa˛ jest przy tym zastapienie
˛
Exchange 5.5. Powodem takiego zastapienia
˛
jest to, że Microsoft na dzień dzisiejszy wstrzymuje (Mainstream) 4 Support
dla Exchange 5.5. Alternatyna˛ oferowana˛ przez Microsoft w ramach migracji kontynuacyjnej
jest Exchange 2000. Jednak migracja kontynuacyjna do Exchange 2000 dla wielu urz˛edów nie
wchodzi w rachub˛e, ponieważ 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 świata opartego na Windows 2000. Dlatego Exchange 2000 może pracować tylko z serwerem Windows
2000 lub jego nast˛epcami.
W zwiazku
˛
z tym wiele urz˛edów jest poważnie zainteresowanych alternatywnym rozwiaza˛
niem Groupware / Messaging, które zaoferuje podobny albo taki sam zakres funkcji, nie obsługujacym
˛
AD i umożliwiajacym
˛
dalsze korzytanie z klientów MS Outlook.
4
http://support.microsoft.com/default.aspx?scid=fh;en-us;lifesrvr
464
Do dyspozycji jest wiele różnych rozwiazań
˛
alternatywnych (patrz także poniższy rysunek).
W przypadku wyższych wymagań wzgl˛edem kompatybilnosci należy przede wszystkim rozważyć dwa rozwiazania
˛
dla różnych wymagań:
◦ Samsung Contact
◦ Exchange4Linux
W obydwu przypadkach dzi˛eki dobremu połaczniu
˛
MAPI można kontynuować korzystanie z
Outlook-Client w ramach jego najistotniejszych funkcji. Dokładniejsze oceny techniczne i porównanie funkcjonalności w/w rozwiazań
˛
znaleźć można w rozdziale 3 („Techniczne opisy migracji“). Model rachunku ekonomicznego w przypadku migracji do Samsung Contact znajduje
si˛e w rozdziale „Ocena wydajności ekonomicznej“ (patrz rozdział 4).
Rysunek 5.8: Różne warianty zastapienia
˛
Exchange w przypadku migracji cz˛eściowej
Samsung Contact, dokładnie tak jak Exchange, nie jest produktem OSS lecz należy do kategorii własnościowego oprogramowania COLS. Migracja do Samsung Contact została już oceniona w zaleceniach dotyczacych
˛
całkowitej „zast˛epujacej
˛ migracji“ (patrz rozdział 3.14.4).
465
Samsung Contact nadaje si˛e zwłaszcza do dużych specjalizowanych urz˛edów stawiajacych
˛
szczególne wymagania odnośnie skalowalności i bezawaryjności.
Dla urz˛edów do 500 użytkowników można również polecić tańsze rozwiazanie
˛
jakim jest
Exchange4Linux. Jest to w istocie produkt OSS. Serwer dost˛epny jest jako Wolne Oprogramowanie, jedynie MAPI - Connector jest własnościowy i trzeba za niego zapłacić. Bliższe informacje w rozdziale 3.14.4.
W przypadku obydwu rozwiazań
˛
po stronie serwera potrzebny jest system operacyjny GNU
/ Linux. Przeprowadzenie migracji punktowej oferuje cały szereg korzyści:
◦ bardziej przejrzysty i dajacy
˛ si˛e dobrze zaplanować zakres migracji.
Konieczne dostosowania mieszcza˛ si˛e w ograniczonych ramach, co jest istotna˛ zaleta˛ podczas planowania i kierowania projektem.
◦ istnieje możliwość stopniowego jednoczesnego rozwijania pomysłów na prac˛e i zbieranie
doświadczeń oraz budowania platformy opartej o nowy system operacyjny.
◦ nakłady na szkolenia ponoszone sa˛ tylko na wykształconych już w danym kierunku administratorów. Doszkalani administratorzy moga˛ także posłużyć w dziale informatyki jako
osoby przekazujace
˛ innym swoja˛ wiedz˛e.
W kontekście Groupware i Messaging trzeba w tym miejscu zauważyć, ż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
˛
już wielokrotnie wypróbowane i preferowane.
Kolejna możliwość migracji punktowej polega na zastapieniu
˛
MS Office przez OpenOffice.org albo StarOffice. Należy przy tym wziać
˛ pod uwag˛e opisane już ograniczenia a zwłaszcza także konsekwencje ekonomiczne. Migracja pakietu Office została już oceniona w rozdziale
„Całkowita > >zast˛epujaca
˛ migracja< <“ (5.2).
Odnośnie zaleceń wynikajacych
˛
z oceny ekonomicznej w przypadku migracji punktowej
patrz rozdziały 4.6.3.1 i 5.4.
5.4.2 Cz˛eściowa migracja po stronie serwera
W nieniejszym rozdziale, na przykładzie szerokiej migracji po stronie serwera, prezentowany
jest sensowny i godny polecenia scenariusz cz˛eściowej migracji po stronie serwera. Jako sytuacj˛e
wyjściowa˛ dla tej migracji przyj˛eto środowisko Windows NT opisane w rozdziale 2.2.1.
466
Zasadniczo w przypadku szerokiej migracji po stronie serwera swoje zastosowanie znajduja˛
zalecenia z całkowitej migracji (patrz rozdział 5. Różnice wynikaja˛ z faktu, ż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
można przeczytać takż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. Najważ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, uprawnień,
jak też przeniesienie danych konfiguracyjnych.
W ramach oceny ekonomicznej okazuje si˛e, że około 65% - 80% kosztów projektu zapisać
można po stronie oszcz˛edności. Dodatkowe nakłady leżace
˛ powyżej tych wskaźników wynikaja˛
w istocie z kosztów osobowych zwiazanych
˛
z pracami migracyjnymi. Dla tego typu migracji
oznacza to, że z reguły nie da si˛e przedstawić bezpośredniej pieni˛eżnej korzyści w porównaniu
z migracja˛ kontynuacyjna.˛ O wiele bardziej o przyj˛eciu projektu decydować tu b˛eda˛ mi˛ekkie
czynniki wyrażone w formie kryteriów, takich jak konieczność i strategia.
O zaleceniach wynikajacych
˛
z oceny ekonomicznej w przypadku szerokiej migracji można
przeczytać w rozdziale 4.6.3.2 i 5.4.
Zarzadzanie
˛
uż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 zastapić
˛ kontroler domen Windows. Szczególnie
dotyczy to najnowszej Samby od wersji 3.0, która została już sukcesywnie przetestowana w projekcie migracyjnymi Federalnego Urz˛edu ds. Karteli. Oferuje ona niemal nieograniczona˛ możliwość połaczenia
˛
klientów Windows 2000 z klientami Windows XP. Bliższe informacje na ten
temat znaleźć można w technicznych opisach migracji w rozdziale 3.
Zarzadzanie
˛
plikami i drukowanie Zgodnie z tym, co zostało już powiedziane, w przypadku
zarzadzania
˛
plikami, tylko Samba zapewnia bezawaryjne połaczenie
˛
klientów windowsowych.
467
Samba jest w stanie odwzorować pod Linuksem serwer plików oparty na Windows NT. Użytkownicy klientów windowsowych moga˛ równie dobrze korzystać ze swoich profilów i skryptów
logowania znajdujacych
˛
si˛e na serwerze Samba, jak ze swoich katalogów domowych oraz grupowych. Jeśli chodzi o fizyczny zapis danych na systemach dysków właś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 odbywać si˛e za poś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 wyjściowe, w przypadku których zalecana jest tego
typu migracja.
Szybka migracja jest przeciwieństwem łagodnej migracji. Obydwie wspomniane drogi migracji maja˛ na celu doprowadzenie do całkowitej „zast˛epujacej
˛ migracji“, to znaczy, że w przypadku obydwu dróg celem jest dojście do linuksowego systemu operacyjnego.
Szybkiej migracji nie cechuje, wbrew temu co sugeruje jej nazwa, szybkość migrowania,
lecz to, że migracj˛e t˛e wykonuje si˛e w jednym kroku, w przejrzystych, precyzyjnie określonych
ramach czasowych. Szybka migracja ma zdefiniowany poczatek
˛ (data rozpocz˛ecia) i zdefiniowany koniec (data zakończenia). Wraz z końcem przypada poczatek
˛ pełnej pracy w czystym
linuksowym środowisku informatycznym.
Przeprowadzenie szybkiej migracji stawia wysokie, a nawet bardzo wysokie wymagania
wzgl˛edem:
◦ organizacji projektu
◦ organizacji danego urz˛edu
◦ techniki
◦ finansowania
◦ administratorów
468
◦ użytkowników
Szczególnie nie wolno przy tym nie docenić wymagań dotyczacych
˛
administratorów i użytkowników. Ma to tym wi˛eksze znaczenie, im mniejszy dost˛ep maja˛ oni do wiedzy o nowym środowisku informatycznym. Z drugiej strony zaleta˛ szybkiej migracji jest to, że administratorzy nie
musza˛ si˛e przez dłuższy czas zajmować dwoma różnymi kierunkami IT. Moga˛ oni we wzgl˛ednie
krótkim czasie (odpowienim do wymagań projektu) skoncentrować si˛e na nowym systemie.
Inna˛ ważna˛ rzecza˛ jest to, że w krótkim okresie czasu dost˛epne musi być wymagane finansowanie. O tym kiedy i ile środków finansowych należy udost˛epnić decyduje zakres i przede
wszystkim stopień skomplikowania oraz różnorodność aplikacji i systemów przeznaczonych do
migracji. Aspekt ten współdecyduje o możliwoś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 sprostać swoim codziennym obowiazkom.
˛
Oznacza
to, że koniecznie należy dażyć
˛
do minimalizacji zakłóceń w pracy urz˛edu. Z drugiej strony musi
być zachowana bieżaca
˛ praca systemów informatycznych. Szczególnie migracja całego środowiska serwerów stawia przed wszystkimi jej uczestnikami wysokie wymagania, gdyż migracji
pojedynczych usług nie da si˛e dowolnie podzielić, administratorzy musza˛ zagwarantować bieżac
˛ a˛ prac˛e i jednocześnie musza˛ zostać wdrożeni do pracy z nowymi systemami.
Niniejszym wymogom można sprostać dzi˛eki właściwemu Rollout oraz pomysłom na migracj˛e. Można to zrobić tworzac
˛ także rówonległe środowisko informatyczne, jednak zwi˛eksza
to wymagania techniczne i powoduje dodatkowe koszty.
Z uwagi na wspomniane wysokie wymogi powstaje oczywiście pytanie czy szybka migracja
ma w ogóle sens, wzgl˛ednie dla kogo ma ona sens i komu można ja˛ polecić?
Poniżej wymienione zostały powody uzasadniajace
˛ szybka˛ migracj˛e:
◦ istnieje przymus migracji, co znaczy, że na przykład kończy si˛e wsparcie dla starego systemu.
◦ intensywne, ale za to tylko jednorazowe a nie stopniowe, wieloletnie konfrontowanie administratorów i użytkowników z nowościami.
◦ administratorzy nie musza˛ przez długi czas pracować w skomplikowanych heterogenicznych światach.
Na jakich warunkach i dla kogo szybka migracja ma sens?
469
Jeśli środowisko systemowe jest przejrzyste i nie jest ponad miar˛e „zawikłane“, wówczas
warunek szybkiej migracji jest dobrze spełniony. Oznacza to, że aby spełnić zadania trzeba zastosować tylko niektóre aplikacje i usługi. Nie musi przy tym chodzić jedynie o małe i proste w
swojej strukturze urz˛edy i organizacje. Dotyczy to na przykład także urz˛edów i organizacji zajmujacych
˛
si˛e bezpieczeństwem, w przypadku których wi˛eksza cz˛eść użytkowników wyposażona
jest w niewiele dużych specjalistycznych aplikacji, gdyż sa˛ one najcz˛eściej zgromadzone na serwerze i tam wykonuja˛ przeważajac
˛ a˛ cz˛eść zadań. Dotyczy to jednak także małych oraz ś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˛ już konieczna˛ wiedza,˛ np. gdy zajmowali si˛e w wolnym czasie systemami linuksowymi albo gdy wykorzystywane sa˛ już pojedyncze linuksowe aplikacje i usługi (np. Mail Server
pracujacy
˛ pod Linuksem). Jeśli do tego jeszcze współpracownicy wykazuja˛ niezb˛edna˛ otwartość
na nowości i zainteresowanie Linuksem, sa˛ to wówczas również warunki do przeprowadzenia
szybkiej migracji.
5.5.2 Łagodna migracja
W niniejszym rozdziale opisane zostały powody i drogi łagodnej migracji. Jednak cóż tak właściwie oznacza poj˛ecie „łagodna migracja“? Jest to droga migracji, w przypadku której ustalony
jest cel, jednak ramy czasowe określone sa˛ jedynie zgrubnie a poszczególne składniki migracji
przewidziane sa˛ w oparciu o przedstawiony wyż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 budżetem można dostosować wymagane
koszty do stanu budżetu.
◦ można sukcesywnie uzupełniać brakujac
˛ a˛ wiedz˛e i w ten sposób oszcz˛edzać koszty. W
przypadku łagodnej migracji można wybierać pojedyncze składniki. Przeszkoleni przy tym
administratorzy służa˛ jako osoby przekazujace
˛ swoja˛ wiedz˛e innym osobom, dzi˛eki czemu
w przypadku migracji kolejnych składników dysponuja˛ one już wi˛ekszym Know-how.
◦ można stopniowo usuwać istniejace
˛ przeciwności i rozwiewać uprzedzenia.
◦ złożone struktury informatyczne można rozbierać kawałek po kawałku.
470
Poniższy rysunek pokazuje, w jaki sposób mogłaby wygladać
˛
łagodna migracja.
Rysunek 5.9: Łagodna migracja
Na poczatku
˛ jako cel migracji należy wybrać składnik, który daje si˛e łatwo wyodr˛ebnić. W
powyższym przykładzie jest to serwer DBMS. Nie chodzi tu o migraj˛e aplikacji bazodanowej,
lecz o założenie równoległego DBMS. Należy dysponować podstawowa˛ wiedza˛ na temat tego
serwera. Najpóź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 może być ewentualnie stosowany w połaczeniu
˛
z serwerem WWW i warunkować
migracj˛e Groupware. Nast˛epnie wykonywana jest migracja zarzadzania
˛
plikami i zastapienie
˛
usług sieciowych. Na koń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 można dowolnie wymieniać składników zwiazanych
˛
z
poszczególnymi krokami; to, co jest ze soba˛ zwiazane,
˛
powinno takim pozostać. Inna˛ ważna˛
rzecza˛ jest ustalenie realnej daty zakończenia, tak by proces nie rozciagał
˛ si˛e zbytnio w czasie.
Czas realizacji musi jednak uwzgl˛eniać złożoność opieki i konserwacji a tym samym nakłady na
prac˛e administratorów. Ponieważ nakład zwiazany
˛
z administrowaniem w różnorodnym środowisku informatycznym jest wyższy niż w środowisku jednorodnym, cały proces migracji, także
w przypadku łagodnej migracji, nie powinien przekroczyć 2 - 3 etapu zamiany oprogramowania
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 środowisku heterogenicznym, można wykonać wzgl˛ednie daleko idac
˛ a˛ migracj˛e przede wszystkim korzytajac
˛ z Samby,
Terminalservices a także z możliwości kontynuacyjnego stosowania Outlooka jako klienta Groupware i Messaging.
Dopiero na samym końcu, gdy wszystkie aplikacje specjalistyczne i biurowe przejda˛ równoległa˛ migracj˛e, można rozpoczać
˛ migracj˛e desktopów, czyli migracj˛e po stronie klienta. W
stopniu, w którym umożliwia to zamiana oprogramowania specjalistycznego i biurowego, można
nawet zastanowić si˛e nad skorzystaniem w kroku pośrednim z przejś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 też cz˛eściowego (serwery) albo tylko
472
punktowego zastapienia
˛
oprogramowania. Poniższy rysunek pokazuje wieloetapowy proces migracji w jego pojedynczych aspektach.
Rysunek 5.11: Model stopniowego procesu migracji
Aby można było doprowadzić projekty migracyjne jako projekty informatyczne w ogólności
i jako projekty innowacyjne w szczególności do szcz˛eśliwego końca, należy z góry zdefiniować
krytyczne wyznaczniki sukcesu oraz dokonać ich oceny. Dla wszystkich uczestników sukces
projektu migracyjnego ma miejsce dopiero wówczas, gdy osiagni˛
˛ ety zostanie zakładany cel badź
˛
wynik w zaplanowanych, wzgl˛ednie uzgodnionych ramach czasowym i budżetowych.
Wyróżnić tu moż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 badź
˛ redukcj˛e porażek, frustracji oraz podwójnej pracy, jak również uzasadniony potrzebami wybór i naturalnie także akceptacj˛e nowego środowiska informatycznego przez użytkowników.
Niezależnie od wielkości urz˛edu i niezależ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 poniżej parametry.
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 środowiska docelowego wśród użytkowników
◦ strukturalne zaplanowanie czasu, projektu i zasobów oraz kontroli projektu
◦ działania organizacyjne przygotowujace
˛ migracj˛e i wykształcenie wykwalifikowanego zespołu wdrażajacego
˛
projekt
◦ szczegółowe ustalenie sytuacji docelowej ze zdefiniowanymi funkcjonalnymi wymaganiami
◦ optymalny wybór produktów i usług
◦ najbliższe i późniejsze szkolenia
◦ zarzadzanie
˛
jakościa˛ i dokumentacja˛
Z wyznaczników sukcesu wynika, że projekty migracyjne nie kończa˛ si˛e z chwila˛ zakupu i zaimplementowania odpowiednich składników. Zarówno przed migracja˛ oraz w trakcie właściwych
procesów migracyjnych, jak też w czasie póżniejszych prac należy uwzgl˛eniać daleko idace
˛ zależności i czynności.
W sumie projekty migracyjne można uznać za zakończone sukcesem i opłacalne tylko wtedy,
gdy obok minimalizacji bieżacych
˛
kosztów umożliwia˛ one przynajmniej sprawniejsze wykonywanie zadań dzi˛eki nowoczesnej, zintegrowanej i funkcjonalnie ukierunkowanej informacji oraz
komunikacji a także doprowadza˛ do ogólnego wzrostu elastyczności, wydajności i gotowości
podczas realizacji obecnych i przyszłych zadań. Dalsze cele takie jak osiagni˛
˛ ecie niezależności od producenta i / lub od platformy sa˛ centralnymi aspektami, które patrzac
˛ dalekowzrocznie
musza˛ sprostać wymaganiom oceny ekonomicznej.
W nast˛epnych rozdziałach dokładniej opisano najistotniejsze kryteria sukcesu zdefiniowane
dla projektów migracyjnych.
5.5.3.1
474
Sformułowanie jednoznacznych celów
Podstawa˛ każdego sukcesu projektu jest sformułowanie jednoznacznych celów. Należy przy tym
rozróżnić strategiczne cele zarzadzania
˛
(poziom motywacji) i cele na poziomie migracji serwerów (poziom widzialny). Należy określić, dlaczego migracja powinna w ogóle mieć miejsce a w
nast˛epnym kroku, co chce si˛e dzi˛eki niej uzyskać.
Osobom, na które migracja b˛edzie oddziaływać, kierownictwu urz˛edu i niezb˛ednym wykonawcom, należy przed rozpocz˛eciem realizacji projektu otwarcie wskazać właściwy cel zamiaru
migracyjnego. Takie sformułowanie celu tworzy podstaw˛e dla wszystkich dalszych działań, tak
samo dla ukształtowania projektu i wyboru docelowego oprogramowania, jak i dla wyboru wewn˛etrznych i zewn˛etrznych wykonawców. Osiagni˛
˛ ecie pewnej niezależności od producenta badź
˛
platformy jest przy tym raczej ogólnym, ewentualnie nadrz˛ednym celem.
Specyficznymi dla urz˛edu mogłyby być na przykład nast˛epujace
˛ szczegółowe dane docelowe
odnośnie migracji serwerów:
◦ migracja serwerów bez dostosowania i zamiany oprogramowania po stronie klientów (pełne
przej˛ecie danych, profilów uż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 bezpieczeństwa informatycznego odpowiednio do Bund Online 2005, np. PKI,
autoryzacja poprzez certyfikat i cechy biometryczne)
◦ stworzenie adekwatnego systemu zast˛epczego dla zarzadzania
˛
użytkownikami i logowania
◦ bezawaryjna konwersja szablonów
5.5.3.2
Właczenie
˛
i ustalenie szczebli kierowniczych i decyzyjnych
Szczebel kierowniczy i decyzyjny to każdy poziom, na którym podejmowane sa˛ kluczowe decyzje dotyczace
˛ projektu migracyjnego bez bezpośredniego aktywnego udziału w projekcie. Z
475
drugiej strony kierownictwo projektu ma obowiazek
˛ przygotowywania sprawozdań. Jaki dokładnie to b˛edzie poziom, zależy od specyficznej sytuacji i priorytetu projektu w urz˛edzie.
Rola szczebla kierowniczego w sukcesie projektu jest cz˛esto niedoceniana. Jak pokazuje doświadczenie, panuje zamiast tego przekonanie, że szczebel kierowniczy „nic albo bardzo mało
rozumie, jeśli chodzi o technik˛e informatyczna˛ i komunikacyjna“.
˛ Jednocześnie insynuuje si˛e, że
kierownictwo urz˛edu głównie „tylko“ zainteresowane jest tym, by otrzymać „działajacy
˛ i opłacalny system“. Takie założenie jest jednak nieproduktywne. Szczebel kierowniczy i decyzyjny
jest odpowiedzialny raczej za wytyczanie celów projektu migracyjnego dla urz˛edu niż 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 należa˛ do kierownictwa urz˛edu.
Projekt migracyjny musi najpierw w ogóle zostać uruchomiony. W tym celu konieczne jest,
aby szczebel decyzyjny w oparciu o rozpoznane braki badź
˛ konkretne cele projektu (np. uniezależnienie si˛e od producenta i platformy), wzgl˛ednie rozpoznanie potrzeb na podstawie wymagań
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 zaangażowanym w projekt oraz
pozostałym pracownikom informacj˛e o tym, że popiera ono projekt i na wszystkich etapach jego
rozwoju b˛edzie go nie tylko tolerować ale także wspierać.
Aktywne i zawczasu informowanie osób pracujacych
˛
przy projekcie Kolejnym jednoznacznym i głównym zadaniem kierownictwa, które zaczyna si˛e już na etapie przygotowywania projektu migracyjnego i które trzeba uwzgl˛ednić jest odpowiedzialność 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˛etnoś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. Należy tu wymienić zarówno te obszary, w których zachodza˛ zmiany, jak też takie, które pozostana˛ niezmienione. (Przykładowo na bazie istniejacego
˛
pomysłu na prac˛e można
dokładnie opisać planowane zmiany oraz niezmienne elementy).
Ponadto do informowania należy wykorzystywać różne kanały komunikacyjne w ramach
ogólnych konferencji, rozmów z pracownikami, warsztatów albo okólników badź
˛ ogłoszeń, jak
też Intranetu (unikni˛ecie plotek). Zawczasu należy tworzyć możliwości reagowania na pytania i
watpliwości,
˛
ale także obawy i strach zatrudnionych dotyczace
˛ zmian. Również zawczasu należy
w cały proces właczyć
˛
przedstawicielstwa różnych osób i gremiów.
476
Udost˛epnienie potrzebnych środków finansowych Szczebel kierowniczy musi upewnić si˛e,
że już przed rozpocz˛eciem realizacji projektu można dysponować wymaganymi środkami finansowymi (na zakup rzeczy i opłacenie ludzi) przypadajacymi
˛
na poszczególne pakiety działań
i na osoby biorace
˛ udział w projekcie. Oprócz samych kosztów inwestycji i licencji doliczyć
tu trzeba na przykład koszty szkoleń a w razie potrzeby także koszty zewn˛etrznego doradztwa
i wsparcia projektu, jak też wewn˛etrzne koszty osobowe. Ponadto potrzebne środki finansowe
należy w danym przypadku dostosować do post˛epów prac nad projektem.
Odbiór wyników czastkowych
˛
i końcowych Pomi˛edzy szczeblem decyzyjnym, kierownictwem projektu i członkami grup pracujacych
˛
nad projektem istnieje jasny podział zadań. Szczebel decyzyjny musi, na podstawie dokumentów przygotowanych przez grup˛e realizujac
˛ a˛ projekt,
podejmować kluczowe decyzje na końcu poszczególnych etapów projektu i brać za nie odpowiedzialność. W danym przypadku wskutek zmiany okoliczności konieczna może być modyfikacja
przyj˛etych strategicznych celów.
5.5.3.3
Uzyskanie wysokiego stopnia akceptacji środowiska docelowego wśród użytkowników
Projekty migracyjne moga˛ zakończyć si˛e sukcesem i mieć sens na poziomie pracowników tylko
wtedy, gdy jasno zdefiniowana zostanie widoczna korzyść oraz gdy zostanie ona przedstawiona
jako sensowna i konieczna. Korzyść taka wynika ze zdefiniowania celu.
Także osoby zatrudnione przy projekcie migracyjnym powinny być przekonane o jego zaletach, aby mogły go wprowadzać i wspierać na terenie cz˛eści badź
˛ całego urz˛edu. Jednocześnie
należy przy tym jasno poinformować o granicach dla Open Source i zaznaczyć, dlaczego wybrano drog˛e przejścia na Open Source.
Celem powyższych czynności jest zapewnienie wysokiego stopnia akceptacji migracji i w
konsekwencji dużej motywacji oraz zadowolenia osób bioracych
˛
w niej udział. Należy uniknać
˛ sytuacji, w której niezadowoleni (niedoinformowani, niezmotywowani albo wskutek braku
odpowiedniego szkolenia niewykwalifikowani) uczestnicy projektu migracyjnego zagroża˛ jego
sukcesowi i w danym przypadku ogłosza˛ porażki. Patrzac
˛ długofalowo może to mieć w sumie negatywny wpływ na skuteczność i wydajność urz˛edu. Aby móc w razie potrzeby dokonać korekty,
osoby odpowiedzialne za konsekwentne informowanie o przebiegu projektu powinny poza spełnianiem tego „obowiazku“
˛
dokonać także „wyboru“ stałego sposobu kontroli poziomu sukcesu
mierzonego zadowoleniem pracowników.
Stworzenie koncepcji i trwałe wdrożenie wynikajacych
˛
z niej działań jest wprawdzie przede
477
wszystkim zadaniem kierownictwa, jednak może być ona tworzona tylko wspólnie z pracownikami i oczywiście stale ulepszana. W danym przypadku na poczatku
˛ sensowne może tu być
skorzystnie z zewn˛etrznego wsparcia, doradztwa i couchingu.
5.5.3.4
Szkolenia dla użytkowników i administratorów
W obszarze szkoleń należy z jednej strony zawczasu zintegrować administratorów a niedługo
potem także przyszłych użytkowników. Należy stworzyć koncepcj˛e szkolenia grup docelowych
uwzgl˛edniajac
˛ a˛ zarówno posiadane umiej˛etności, doświadczenie i kwalifikacje, jak też przyszłe wykorzystanie składników w miejscu pracy. Zawiera ona także zapoznanie użytkowników z
miejscem pracy oraz dalsze szkolenie, szczególnie administratorów i opiekunów użytkowników,
w obszarze oprogramowania Open Source. Ponadto zaleca si˛e aktywne właczanie
˛
do pomysłów
na szkolenie doświadczeń z projektów pilotażowych albo innych projektów migracyjnych na
zasadzie Lessons Learned. Kolejnymi konkretnymi działaniami sa:
˛ przygotowanie środowisk testowych i symulacyjnych, ćwiczeń na wypadek awarii, backupu i recovery.
Jest to tym ważniejsze w sytuacji, gdy nie dysponuje si˛e doświadczeniami, wst˛epna˛ wiedza˛
albo jest ona bardzo mała i po migracji nie ma być już bieżacego
˛
badź
˛ doraź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 zaangażowanych wi˛ecej osób. Aby sukcesem zakończyć
migracj˛e powinny one działać w ograniczonych ramach czasowych i zmierzać do jasno zdefiniowanego celu. Wymagania te sa˛ klasycznymi cechami pracy nad projektem, które należy
uzupełnić o odpowiednia˛ dla projektu form˛e organizacyjna˛5.
Opierajac
˛ si˛e na tym należy sprawdzić czy i w jakim stopniu dotychczasowa struktura, która
jak wynika z doświadczeń ukierunkowana jest pod katem
˛
procesu, b˛edzie przydatna, to znaczy
ma form˛e organizacyjna˛ adekwatna˛ do projektu. W razie potrzeby należy czasowo zmienić organizacyjne warunki brzegowe i wyodr˛ebnić z organizacyjnych struktur urz˛edu osoby biorace
˛
udział w projekcie. Należy przy tym, w ramach przygotowań, wypracować z udziałem w/w osób
i określić procesy robocze, punkty wspólne, produkty i zasoby. Obowiazuje
˛
przy tym zasada, że:
◦ struktura organizacyjna projektu jest ważniejsza niż struktura organizacyjna urz˛edu
5
Ministerstwo Spraw Wewn˛etrznych, Handbuch für Organisationsuntersuchnungen in der Bundesverwaltung,
Bonn, 5 Aufl. 1988, S. 23 ff.
478
◦ należy jasno rozgraniczyć zadania i zakresy odpowiedzialności
◦ należy czasowo zredukować albo przenieść czynności Routine
◦ należy ustalić drogi komunikacji i przekazywania sprawozdań
Wszelkie plany i kroki należy oceniać na tyle krytycznie, na ile z organizacyjnego punktu widzenia przyczyniaja˛ si˛e one do osiagni˛
˛ ecia celu projektu. W watpliwych
˛
przypadkach należy
preferować takie działania, które niosa˛ ze soba˛ wi˛ekszy potencjał.
Skład grupy pracujacej
˛ nad projektem Sukces projektu jest wi˛ekszy badź
˛ mniejszy w zależności od kierownictwa porojektu oraz składu grypy, która nad nim pracuje. Zły wybór może
doprowadzić, także w przypadku, gdy pozostałe założenia sa˛ korzystne, do uzyskania niedostatecznego wyniku projektu, podczas gdy dobra obsada osobowa wypracować może, nawet przy
słabych warunkach brzegowych, wciaż
˛ akceptowalne wyniki. Zaprzecza to gdzieniegdzie głoszonej opini, że „nie ma ludzi nie zastapionych“.
˛
Kierownictwo projektu: Kierownik projektu ponosi całkowita˛ odpowiedzialność za projekt.
Koordynuje, organizuje i komunikuje wszystkie prace zwiazane
˛
z projektem, co ma na celu jego
specjalistyczne, terminowe i mieszczace
˛ si˛e w kosztach zakończenie. Kierownik jest odpowiedzialny za wytyczanie zadań i kontrol˛e realizacji krótkoterminowych i długoterminowych celów.
(w razie potrzeby także za przygotowywanie raportów dla nadzorujacej
˛ komisji).
W zależności od wielkości urz˛edu i charakteru zamiaru migracyjnego sensowne może okazać
si˛e mianowanie jeszcze jednej osoby oprócz kierownika projektu, która przej˛ełaby cz˛eść jego
zadań.
Grupa pracujaca
˛ nad projektem: Wypracowanie treś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łaczyć
˛
wybrani użytkownicy i w razie potrzeby osoby trzecie z zewnatrz
˛ (doradcy w zakresie
Know-how i sposobu pracy).
Właczanie
˛
zewn˛etrznych doradców Również w urz˛edach rośnie wsparcie ze strony zewn˛etrznego doradztwa w dziedzinie wdrażania projektów. Powody korzystania z tej formy pomocy to:
◦ profesjonalna, neutralna i obiektywna analiza problemu
◦ wydajne czasowo, zaplanowane zarzadzanie
˛
projektem
479
◦ bieżaca
˛ komunikacja dotyczaca
˛ projektu ze skuteczna˛ kontrola˛ post˛epu prac i ich wyników
◦ przekonujace,
˛ dobrze przygotowane prowadzenie spotkań, prezentacji i dokumentacji wyników)
◦ transfer wiedzy w zakresie przygotowania i przeprowadzenia skomplikowanych projektów
informatycznych badź
˛ migracyjnych
Ustalenie formy organizacyjnej odpowiadajacej
˛
potrzebom projektu Właściwa˛ dla projektu migracyjnego form˛e organizacyjna˛ należy określić w zależności od zakresu migracji i wielkoś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 zależności od zadań i celów zaleca si˛e skorzystanie z jednej z trzech wymienionych
poniżej możliwoś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 skoncentrować. Jednocześnie wystapi
˛ brak wspomnianych pracowników w
ich dziale, co może doprowadzić do różnego rozłożenia si˛e obciażeń
˛
(przeciażenia)
˛
personelu.
Forma organizacji liniowej powinna być 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 możliwości.
Osoby pracujace
˛ nad projektem pozostaja˛ w swoich działach i spotykaja˛ si˛e tylko na zwiazanych
˛
z nim posiedzeniach, co sprawia, że sztabowa organizacja projektu jest podatna na zakłócenia i
nieefektywność.
Zaletami tego typu organizacji jest mały koszt (trzeba tylko znaleźć koordynatora) i elastyczne obciażenie
˛
pracowników (praca nad projektem i w dziale). Ponadto można jednocześnie
przeprowadzać wiele projektów. Generalnie niniejsza forma organizacyjna nadaje si˛e tylko dla
mniejszych projektów, ponieważ w przeciwnym razie koszty koordynacji i uzgodnień sa˛ zbyt
wysokie.
matrycowa organizacja projektu: W przypadku tego typu organizacji oprócz istniejacej,
˛
hierarchicznej struktury wprowadza si˛e poziome kompetencje decyzyjne. Pracownicy podlegaja˛
kierownikowi projektu, jeśli chodzi o kwestie ważne dla projektu, ale osobowo i dyscyplinarnie
nadal podlegaja˛ liniowo swoim przełożonym. Projekty tego typu sa˛ skomplikowane i wymagaja˛
wysokich nakładów na koordynacj˛e.
480
Ich zalety polegaja˛ na tym, że wymagane zasoby absorbowane sa˛ tylko w razie potrzeby.
Kierownik projektu jest tutaj, w przeciwieństwie do sztabowej organizacji projektu, wyposażony
w kompetencje decyzyjne i pełnomocnictwa do wydawania poleceń.
Wady wynikaja˛ z tego, że osoby pracujace
˛ nad projektem sa˛ „sługami dwóch panów“. Zwłaszcza w przypadku realizacji wielu projektów moga˛ wystapić
˛ konflikty o zasoby albo wynikajace
˛
ze sprzecznych poleceń.
Zestawienie i ocena organizacyjnych form projektu procesów migracyjnych W celach
orientacyjnych zwiazanych
˛
z wyborem właściwej formy organizacyjnej projektu może posłużyć niniejsza tabela. Konieczne jest jednak dostosowanie dla konkretnego urz˛edu.
CAŁKOWITA MIGRACJA
CZ E˛ŚCIOWA MIGRACJA
PUNKTOWA MIGRACJA
mały urzad
˛
oraganizacja liniowa
organizacja sztabowa
organizacja sztabowa
średni urzad
˛
organizacja liniowa
organizacja matrycowa
duży urzad
˛
organizacja liniowa
organizacja liniowo - matrycowa
Tablica 5.1: Propozycja: zestawienie form organizacyjnych projektu
mały urzad:
˛ do 300 pracowników; średni urzad:
˛ do 1.000 pracowników; duży urzad:
˛ od 1.000 pracowników
5.5.3.6
Właczenie
˛
wybranych pracowników
W ramach przygotowywania projektu należy, w zależności od stopnia skomplikowania zamiaru
migracyjnego, podjać
˛ decyzj˛e organizacyjna˛ odnośnie tego, które grupy użytkowników aktywnie właczyć
˛
do projektu, wzgl˛ednie tylko poinformować. Proces wprowadzania zmian dotyka
pracowników w stopniu zależacym
˛
od tego czy chodzi o migracj˛e całkowita,
˛ cz˛eściowa˛ albo
punktowa.
˛ Jeśli, na przykład, w ramach cz˛eściowej migracji wymieniane jest oprogramowanie
na serwerach, wówczas na ogół wystarczy przekazanie uż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ł użytkowników obj˛etych migracja˛ i zapewnienie im opieki.
5.5.3.7
Określenie punktu wyjścia
Kolejnym głównym wyznacznikiem sukcesu jest dokładne ustalenie sytuacji wyjściowej. Z reguły wiaże
˛ si˛e to z dużymi nakładami, wymaga zasobów ludzkich i odpowiedniej ilości czasu.
481
Jednak zbyt dokładna znajomość szczegółów dokumentów albo aplikacji bazodanowych przeszkadza badź
˛ opóźnia w danym przypadku wprowadzanie korekt podczas procesu migracyjnego
albo już podczas przygotowań do migracji opóźnia wdrożenie odpowiedniego post˛epowania,
wzgl˛ednie podj˛ecie adekwatnych kroków. Określenie punktu wyjścia jest podstawa˛ umożliwiajac
˛ a˛ sformułowanie wymagań wzgl˛edem systemów docelowych. Ważnymi elementami, których
stan należy ocenić sa˛ m.in.:
◦ bazy danych i struktury danych
◦ dokumenty i formaty dokumentów
◦ aplikacje i ich interfejsy
◦ dost˛epne funkcje
◦ dost˛epność danych i aplikacji
◦ braki i problemy
◦ ...
5.5.3.8
Spełnienie wymagań funkcjonalnych
Oprogramowanie docelowe powinno (w dużym stopniu) zastapić
˛ istniejace
˛ funkcje i wymagania.
Musi ono w razie potrzeby wytrzymać miarodajne próby. Trudno byłoby zaakceptować pogorszenie pracy w porównaniu z sytuacja˛ wyjściowa.˛
Do stwierdzenia wymagań co do funkcjonowania służy przede wszystkim opis sytuacji wyjściowej. Ponadto w ramach przeprowadzonej zawczasu ankiety należy zebrać konkretne zapotrzebowanie i wymagania wobec poszczególnych składników, zarówno z punktu widzenia użytkownika, jak i administratora, sprawdzić je i zestawić w postaci listy wymgań lub priorytetów.
Niniejsze post˛epowanie zawiera także krytyczna˛ ocen˛e dotyczac
˛ a˛ przydatności i sensowności
istniejacych
˛
już funkcji. Szczególnie należy przeanalizować krytyczne uwagi dotyczace
˛ brakuja˛
cych albo niepełnych funkcji i umieścić je w kryteriach wyboru. W zależności od stopnia krytyki,
brakujace
˛ funkcje moga˛ doprowadzić do zmniejszenia akceptacji użytkowników. Na tej podstawie można tworzyć 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 dać si˛e zmierzyć stopniem realizacji poszczególnych wymagań.
5.5.3.9
482
Korzystanie z wartości doświadczalnych
Istotnym wyznacznikiem sukcesu jest również wykorzystanie wartości doświadczalnych w kontekście migracji do Linuksa. Jest tak tym bardziej, że dotychczas (przestarzałe) istniało wzgl˛ednie mało wartości doświadczalnych w tym obszarze. Korzystanie z aktywnych doświadczeń z
projektu pilotażowego badź
˛ innych projektów migracyjnych i właczenie
˛
ich do planowanego
projektu oraz zamierzeń przyniesie w jednakowym stopniu korzyści zarówno administratorom,
jak i użytkownikom. Można tu polecić na przykład założenie bazy danych projektu.
5.5.3.10
Planowanie projektu, czasu i zasobów
W przypadku migracji z oprogramowania Microsoftu do określonych ś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 zawierać przynajmniej informacje odnośnie terminu, zasobów rzeczowych i ludzkich, właczenia
˛
zewn˛etrznych
wykonawców, poszczególnych kroków i kosztów. Jednocześnie tworzy on podstaw˛e dla kierowania projektem.
W ramach planu projektu należy opracować,
kto
organizacja projektu
kiedy
jak wykonać
terminy
struktura projektu
co wykonać
zadania
robić, w celu
szybko i bezpieczenie
kalkulacja kosztów
strategia projektu
sukces projektu
wcześniej uzgodnione zlecenie
Wypracowane wyniki należy udokumentować w ksi˛edze projektu.
rozkład czasu: Poprzez planowanie przebiegu i czasu realizacji projektu nast˛epuje jego daleko idacy
˛ podział. Taki wiaż
˛ acy
˛ plan wykonania projektu służy umożliwieniu przyj˛ecia realistycznego terminarza dla poszczególnych pakietów działań. Rozkład czasu wykonania projektu
kieruje si˛e według zawartej w zleceniu dacie jego zakończenia. Należy w nim również określić
poczatek,
˛
etapy i koniec poszczególnych pakietów działań. Stworzenie planu projektu stworzy
w przyszłoś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 należy sformuło-
483
wać wypowiedzi odnośnie tego, jaka ilość pracy (nakłady liczone w dniach roboczych na osob˛e)
oraz konieczne zasoby przewidywane sa˛ jako niezb˛edne dla uzyskania uzgodnionego rezultatu.
Należy przy tym rozróżnić nakłady (zależne od treści pracy) i czas trwania (zależny od intensywności pracy).
W planach badź
˛ ocenach poszczególnych nakładów należy każdorazowo ujać
˛ nast˛epujace
˛
koszty:
◦ koszty osobowe (zasoby ludzkie pomnożone przez stop˛e rozrachunkowa)
˛
◦ właczenie
˛
społeczności w procesy migracji do środowisk Open Source
◦ zasoby na stworzenie i prac˛e środowisk testowych
◦ koszty materiału (zużyte materiały - koszty papieru i wydruku)
◦ koszty urzadzeń
˛
(urzadzenie
˛
albo oprogramowanie, które trzeba ewentualnie zakupić)
◦ pozostałe koszty (koszty podróży, usługi zewn˛etrzne).
◦ koszty nabycia i koszty licencji
◦ koszty konserwacji, opieki i szkoleń
5.5.3.11
Kontrola projektu i kierowanie projektem
Kontrola realizacji projektu jest ważna˛ cz˛eścia˛ składowa˛ organizacji projektu. Zadania kontrolne
nie ograniczaja˛ si˛e tylko do nadzoru kosztów i terminów. Właśnie w kontekście projektów informatycznych Controlling nie jest kontrola˛ w sensie czynności oceniajacych
˛
czynności przeszłe,
lecz pełni on funkcj˛e zapobiegwcza˛ polegajac
˛ a˛ na reagowaniu we właściwym czasie, gdy tylko
rozpoznane zostana˛ odst˛epstwa od wartości zakładanych. Ma to na celu zagwarantowanie osia˛
gni˛ecia celów projektu takich jak: jakość produktu końcowego, termin przekazania do użytku
oraz koszty pracy nad projektem.
5.5.3.12
Dokumentowanie i zapewnienie jakości projektu
Już podczas wykonywania projektu i przede wszystkim po jego zakończeniu trzeba na każdym
etapie zapewnić przejrzystość poszczególnych kroków także dla osób trzecich, które nie biora˛
udziału w procesie migracyjnym. Jest to warunkiem koniecznym dla późniejszej prawidłowej
opieki nad systemem. Dokumentacj˛e można przygotowywać z wykorzystaniem nast˛epujacych
˛
mediów:
484
◦ podr˛eczniki konfiguracji
◦ podr˛eczniki pracy
◦ dokumetacja szkoleń
◦ spisy stanu
◦ podr˛ecznik projektu
◦ protokoły / sprawozdania nt. stanu
◦ sprawozdania odnośnie zapewnienia jakości badź
˛ sprawozdania kontrolne
◦ dokumentacja końcowa
Oprócz kontroli i oceny projektowanego systemu, sprawozdanie kontrolne musi także zawierać
analizy możliwych bł˛edów i ocen˛e skutków ich wystapienia
˛
na każdym etapie projektu. Wspomniane analizy bł˛edów musza˛ być tak samo udokumentowane, jak wszystkie inne prace nad
projektem
Wynacznikiem sukcesu w obszarze zapewnienia jakości okazała si˛e np. w projektach pilotażowych budowa środowisk testowych.
W przypadku dużych projektów wszystkie czynności prowadzace
˛ do zapewnienia jakości
tworza˛ odr˛ebny obszar zadań. W zależności od zakresu projektu i kwalifikacji personelu może
go nadzorować kierownik projektu albo, w pewnych warunkach, kontroler projektu.
Nast˛epujacy
˛ rysunek przedstawia wewn˛etrzne kroki majace
˛ na celu kontrol˛e jakości:
Rysunek 5.12: Etapy kontroli jakości
◦ na końcu poszczególnych kroków badź
˛ etapów projektu kontroler jakości powinien przygotować wymagane listy kontrolne i metody kontroli.
485
◦ jeśli wynik kontroli jakości wypadnie pozytywnie, wówczas oznacza to zezwolenie na
przejście do nast˛epnego kroku przewidzianego w projekcie. Jeśli wynik nie odpowiada
zdefiniowanym wymganiam jakościowym, wtedy należy powrócić do pracy nad źle ocenionym zadaniem. Braki należy konkretnie i szczegółowo zdefiniować i umieścić w protokole kontrolnym. Na końcu trzeba ustalić termin ponownej kontroli i wpisać go do planu
projektu.
5.5.3.13
Opieka na etapie pracy
Kolejnym warunkiem trwałego sukcesu migracji jest opieka administratorów mieszczaca
˛ si˛e w
umiarkowanych granicach. Jednak ogólnie obowiazuj
˛ acej
˛ wartości b˛edac
˛ a˛ miara˛ takiego zaangażowania nie można w tym miejscu podać. Ważna˛ rzecza˛ jest, by natychmiast reagować, gdy
zaistnieje ku temu odpowiednia potrzeba. Z uwagi na brakujacy
˛ Routine w otoczeniu migracji,
także na etapie rozpoczynania pracy z nowymi zadaniami należy zapewnić, szczególnie administratorom, opiek˛e osób z zewnatrz
˛ dostarczajacych
˛
potrzebna˛ wiedz˛e badź
˛ wsparcie. Ważne jest
to zwłaszcza wtedy, gdy osoby biorace
˛ udział w migracji nie miały dotychczas doświadczenia
lub posiadały niewielkie doświadczenie z systemami (GNU / Linux, OSS). Obecność na miejscu
osób przekazujacych
˛
wiedz˛e byłaby w każ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 też 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 kolejności alfabetycznej.
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
ś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 niezawodności. Współtworzył odpowiednie podrozdziały poradnika.
Sebastian Stöcker wyspecjalizował si˛e w infrastrukturach Microsoftu i architekturach systemowych i napisał istotne cz˛eś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 rozwiazań
˛ 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 Binaś
Aleksander Cynarski
Grzegorz Artur Daszuta
Maciej Jan Głowacki
Maciej Hański
Radosław Janeczko
Paweł Jastrzabek
˛
Wojciech Kaczmarek8
Przemysław Klawitter
Konrad Komada
Piotr Kubiak
Wojciech Kuś
7
Wymienione w kolejności alfabetycznej.
Przepraszam wszystkie osoby zainteresowane polska˛ wersja˛ j˛ezykowa˛ poradnika za opóźnienie w jej opublikowaniu. Prac˛e oraz czas poświ˛econy przeze mnie na potrzeby niniejszego tłumaczenia dedykuj˛e głodnym polskim
dzieciom.
8
Janusz Makówka
Mikołaj Marczyń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
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 budżetowa
BIND Berkeley Internet Name Domain
BMI Ministerstwo Spraw Wewn˛etrznych Republiki Federalnej Niemiec
BSD Berkeley Software Distribution
488
BSI Krajowy Urzad
˛ ds. Bezpieczeń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
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
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
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 odnoś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
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
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
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
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
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
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
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
XFS Extended File System
XSL Extensible Style Sheet Language
XML Extensible Markup Language
YaST Yet another Setup Tool
500
501
5.8 Słownik poj˛eć
ADO
ADO oznacza Active Data Objects. Sa˛ to wysokopoziomowe interfejsy (np. z
Visual Basic) służ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łużace
˛ do tworzenia połaczenia
˛
ze źródłem danych w celu wykonywania operacji odczytu, uaktualnienia, zapisu i usuwania.
ACL
Access Control List jest lista˛ uprawnień 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 przydzielić użytkownikowi.
ActiveX
Poj˛ecie zbiorowe oznaczajace
˛ technologi˛e wprowadzona˛ przez Microsoft,
która umożliwia umieszczanie (inter)aktywnych treści na stronach WWW.
Przegladarka
˛
pobiera z serwera cz˛eści programu ActiveX i wykonuje je na
komputerze użytkownika. Technologia ActiveX stworzona została przez Microsoft jako alternatywa dla apletów Java.
API
Application Programming Interface (zdefiniowany interfejs programistyczny,
którego można używać do integracji i rozszerzania)
ASP
Oznacza „Active Server Pages“; jest rozwiazaniem
˛
Microsoftu służacym
˛
do
generowania po stronie serwera dynamicznych stron WWW (np. za pomoca˛
JavaScript, Visual Basic Script), patrz także JSP.
C#
Obiektowy j˛ezyk programowania zaprojektowany przez Microsoft w oparciu
o C i C++.
CGI
502
Common Gateway Interface jest pierwotnym wariantem interfejsów serwera.
Praktycznie każdy dzisiejszy serwer WWW obsługuje ten interfejs. Aplikacje
pracujace
˛ poprzez CGI można tworzyć w różnych j˛ezykach programowania.
Oprócz j˛ezyków interpretowanych, takich jak, np. Perl, stosować można także
skompilowane aplikacje napisane w C albo w C++.
COM
Component Object Model jest standardem oprogramowania firmy Microsoft,
za pomoca˛ którego można realizować 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 umożliwienia komunikacji pomi˛edzy aplikacjami niezależ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 można poprzez sieć udost˛epnić dzielone usługi
oprogramowania. DCOM wykorzystuje RPC (Remote Procedure Calls), co
poprzez wymian˛e informacji umożliwia wywoływanie funkcji na innym komputerze.
DDE
Dynamic Data Exchange jest technika˛ stosowana˛ w Windowsie, która umożliwia programom uż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˛
być jeszcze inne parametry konfiguracyjne.
503
DNS
Domain Name System jest systemem zbudowanym hierarchicznie służ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. Określaja˛ one składni˛e obowiazuj
˛ ac
˛ a˛ dla danego typu dokumentu (a
tym samym także dla określonego formatu danych).
Emulacja
Zdolność systemu, wzgl˛ednie programu do naśladowania sposobu pracy systemu komputerowego za pomoca˛ osprz˛etu badź
˛ oprogramowania.
Failover
Jest specyficznym rodzajem pracy osprz˛etu badź
˛ oprogramowania, np. bazy
danych, serwera albo sieci, które skonfigurowane sa˛ w taki sposób, że w przypadku przejściowego ustania pracy systemu, nast˛epuje automatyczne przej˛ecie świadczonej przez nie usługi przez system spełniajacy
˛ podobne albo takie
same funkcje.
HTML
Hypertext Markup Language – otwarty standard badź
˛ format pliku służacy
˛ do
prezentowania treści w Internecie albo Intranecie.
HTTP
Standard służacy
˛ do elektronicznej interakcji podczas transmisji dokumentów
WWW do Internetu.
IMAP
Za pomoca˛ Internet Mail Access Protocol można zarzadzać
˛
skrzynkami
poczty elektronicznej. W przeciwieństwie do POP3, IMAP administruje
poczta˛ na serwerze. Podczas właczania
˛
programu pocztowego standardowo
ściagane
˛
sa˛ tylko nagłówki wiadomości (nadawca, temat i czas dostarczenia).
W tym momencie adresat może wybrać dowolne wiadomości i ściagn
˛ ać
˛ ich
pełna˛ treść. Poczta, która˛ chcemy pozostawić na serwerze może być odkładana do oddzielnych katalogów.
IPsec
Standard sieciowych systemów bezpieczeństwa, który przede wszystkim nadaje si˛e do implementacji VPNs, jak też do zdalnego dost˛epu do prywatnych
sieci poprzez połaczenia
˛
dial - up.
IPv6
504
To nowa wersja 6 protokołu internetowego (IP), w przypadku której adresy IP
powinny składać si˛e ze 128 zamiast 32 bitów, jak ma to miejsce w przypadku
IPv4. Dzi˛eki temu stworzono, mi˛edzy innymi, wi˛eksza˛ przestrzeń adresowa˛
dla stron WWW.
IPX
Standard transmisji danych zdefiniowany przez firm˛e Novell.
Java
Obiektowy j˛ezyk programowania stworzony przez SUN Microsystems, który
używany jest przede wszystkim w obszarze technologii internetowej. Teksty
źródłowe tłumaczone sa˛ do niezależnego od platformy kodu pośredniego za
pomoca˛ tak zwanego kompilatora. Może być on wykonywany przez właściwy
interpreter na dowolnym komputerze. Dzi˛eki temu programy Java moga˛ pracować na wszystkich platformach, dla których istnieje odpowiedni interpreter.
Java Beans
Java Beans sa˛ składnikami oprogramowania wielokrotnego użytku, które powstały w technologii Java.
Java Script
J˛ezyk skryptowy zdefiniowany pierwotnie przez firm˛e Netscape służacy
˛ do
łaczenia
˛
kodu programu ze statycznymi stronami HTML. Z reguły wykonanie
kodu nast˛epuje w przegladarce
˛
użytkownika.
JDBC
Java Database Connectivity oferuje mechanizm umoż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, może być
wykonywany po stronie serwera WWW.
LAMP
Platforma Open Source oparta na Linuksie, Apache, MySQL i PHP badź
˛
Perlu albo Pythonie służaca
˛ programistom WWW do tworzenia aplikacji
WWW.
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 można odpytywać pod katem,
˛
np. cech użytkowników.
Makro
Połaczone
˛
pojedyncze instrukcje badź
˛ szereg poleceń i procesów, które
można przechowywać i zapisywać. Gdy wywołane zostaje makro, wówczas
nast˛epuje automatyczne wykonanie procesów i akcji w odpowiedniej kolejnoś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óżne systemy komputerowe. MTA odbiera wiadomości zarówno z innych MTA, jak też z MUA i kieruje je do odpowiednich użytkowników.
MUA
Mail User Agent jest programem umożliwiajacym
˛
użytkownikowi dost˛ep do
wiadomości elektronicznych, ich wyś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,
urzadzeń
˛
i użytkowników.
NTP
Network Time Protocol służy do synchronizacji poprzez sieć zegarów pracujacych
˛
w różnych komputerach. NTP umożliwia ustawienie czasu komputerów z dokładnościa˛ co do milisekundy, co jest bardzo ważne dla procesów
wykonywanych jednocześnie przez wiele komputerów.
ODBC
Standardowe post˛epowanie polegajace
˛ na zapewnieniu dost˛epu do baz danych. Na przykład aplikacje moga˛ odwoływać si˛e do różnego rodzaju baz
danych za pomoca˛ ODBC.
OLE
506
OLE oznacza „Object Linking and Embedding“ i jest metoda˛ wspólnego korzystania z informacji. Informacje te moga˛ być dost˛epne w różnych formatach
i utworzone za pomoca˛ różnych aplikacji. Dane z dokumentu źródłowego ła˛
czone sa˛ z dokumentem docelowym badź
˛ 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 umożliwienie
edycji danych w ich pierwotnym środowisku za pomoca˛ niezb˛ednych funkcji.
Mówi si˛e także o „OLE Compound Documents“.
OSI
Mi˛edzynarodowy standard wymiany danych w sieciach. OSI reprezentuje
siedem warstw, które każdorazowo opisuja˛ poszczególne procesy komunikacyjne.
PDF
Ponadplatformowy format dokumentów firmy Adobe Systems, za pomoca˛
którego można tworzyć i prezentować dokumenty złoż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óżnorodnym możliwościa,
˛ zwłaszcza jeśli chodzi o
edycj˛e ciagów
˛
znaków, programy napisane w Perlu służa˛ także cz˛esto do wykonywania administracyjnych zadań routine.
PHP
J˛ezyk skryptowy po stronie serwera służacy
˛ do tworzenia dynamicznych treści WWW w oparciu o baz˛e danych.
POP3
W przypadku pracy z Post Office Protocol w wersji 3 lokalny program pocztowy (klient) ściaga
˛ po uruchomieniu cała˛ nowa˛ poczt˛e z serwera WWW do
lokalnego komputera. Zazwyczaj klient skonfigurowany jest w taki sposób,
że po ściagni˛
˛ eciu poczta jest usuwana z serwera.
POSIX
Standard interfejsów oparty na Uniksie, zgodny z IEEE. Przede wszystkim
obsługuje wszystkie odmiany Uniksa.
PostScript
507
J˛ezyk opisu strony stworzony przez firm˛e Adobe do sterowania drukarkami.
Drukarki postscriptowe otrzymuja˛ polecenia wydruku z każ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łużacy
˛ do przetwarzania żadań
˛
klienta badź
˛
do udost˛epniania usług, z których korzysta klient.
SQL
Jest standardowym j˛ezykiem zapytań wysyłanych do relacyjnych baz danych.
SSH
Protokół badź
˛ 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łaczeń.
˛
SSL
Technologia szyfrowania zaprojektowana przez firm˛e Netscape oraz protokół do bezpiecznej komunikacji badź
˛ bezpiecznego przesyłania dokumentów
pomi˛edzy przegladarkami
˛
a serwerami WWW.
TCP/IP
Zestaw protokołów sieciowych wykorzystywanych wewnatrz
˛ sieci w celu
udost˛epnienia użytkownikowi szeregu usług. TCP (Transmission Control Protocol) oraz IP (Internet Protocol) oferuja˛ podstawy budowania pojedynczych
pakietów danych, ich przesyłania i dostarczania.
UNO
508
UNO jest modelem składników, który tworzy kompatybilność pomi˛edzy rożnymi j˛ezykami programowania, różnymi modelami obiektowymi, różnymi
architekturami maszyn i różnymi procesami. Kompatybilność ta może wyst˛epować w LAN albo za pośrednictwem Internetu. UNO rozwijany jest
przez społeczność OpenOffice razem z laboratoriami programistycznymi Sun
Microsystems. Podstawowe biblioteki UNO sa˛ niezależne od OpenOffice i
Star Office i można je stosować 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 takż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 treści poprzez Internet badź
˛ Intranet.
WINS
System Microsoft do przekształcania nazw wewnatrz
˛ sieci (nazwy sieciowe
<–> adresy IP).
XML
Specyfikacja do definiowania j˛ezyków służacych
˛
do formatowania dokumentów. XML oferuje ścisłe rozdzielenie treś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 uprawnień . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 uprawnień Windows . . . . . . . . . . . . . . . 78
3.12 Uprawnienia POSIX i Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.14 Typy grup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.16 Połaczenie
˛
klienta z CUPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.18 Unikalne oznaczenia nazw NetBIOS . . . . . . . . . . . . . . . . . . . . . . . . 130
3.20 Wielowartoś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 funkcjonalnoś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 kompatybilności Exchange . . . . . . . . . . . . . . . . . . . . . . . . 268
3.59 Wersje VBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
3.61 Rozszerzenia plików najważniejszych aplikacji Office . . . . . . . . . . . . . . . 280
3.63 Właściwości MS Office mogace
˛ sprawić problemy podczas konwersji do OOo /
SO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
3.65 Porównanie dost˛epnych typów szablonów i formatów . . . . . . . . . . . . . . . 284
3.67 Różnice w kluczowych funkcjonalnościach . . . . . . . . . . . . . . . . . . . . 287
3.69 Przeglad
˛ przegladarek
˛
WWW należ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 uż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
pełnej . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
4.8
Całkowite koszty migracji przypadajace
kontynuacyjnej . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
4.10 Całkowite koszty migracji przypadajace
punktowej . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
4.12 Rozłożenie kosztów migracji . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
cz˛eściowej po stronie serwera. . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
cz˛eś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 – średni urzad
˛ . . . . . . . . . . . . . 394
4.34 2 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), średni urzad
˛ . 394
4.36 Przykład migracji: infrastruktura serwerów – duży urzad
˛ . . . . . . . . . . . . . 397
4.37 3 przykład WiBe: infrastruktura serwerów (Windows NT / Linux), duż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), średni urzad402
˛
4.43 Przykład WiBe: Office / Client Desktop (MS Office / OpenOffice.org), duż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 – średni urzad
˛ . . . . . . . . . . . . 412
4.53 Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], średni urzad
˛ 413
4.55 Przykłady migracji: Messaging / Groupware – duży urzad
˛ . . . . . . . . . . . . . 414
4.56 Przykład WiBe: Messaging / Groupware [Exchange 5.5 –> Contact], duży urzad
˛ . 415
4.57 Typy migracji / produkty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
4.59 Przykład analizy korzyści: czynniki konieczności . . . . . . . . . . . . . . . . . 434
4.61 Przykład analizy korzyści: czynniki jakościowo - strategiczne . . . . . . . . . . . 439
5.1
Propozycja: zestawienie form organizacyjnych projektu . . . . . . . . . . . . . . 480
Spis rysunków
2.1
Składniki systemu - punkt wyjś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
Ś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 wyjś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 użytkowników i grup . . . . . . . . . . . . . . . . . . . . 178
3.21 Migracja ADS - świat równoległy a migracja zasobów . . . . . . . . . . . . . . 179
512
SPIS RYSUNKÓW
513
3.22 Migracja ADS - wypełnianie równoległego świata kontami uż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 środowiska Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . 269
3.30 VBA w aplikacji Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
3.31 Możliwe rozszerzenia w Office . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
3.32 Fontmapping MS Office OOo / SO . . . . . . . . . . . . . . . . . . . . . . . . 278
3.33 Zawartość pliku OOo / SO wyświetlana w przegladarce
˛
plików ZIP. . . . . . . . 280
3.34 Obiekty - cienie w PowerPoint i Impress
. . . . . . . . . . . . . . . . . . . . . 292
3.35 Konwerter dokumentów: wybór formatu źródłowego . . . . . . . . . . . . . . . 293
3.36 Konwerter dokumentów: wybór katalogu ź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 sieć . . . . . . . . . . . . . . . . . . 336
3.47 Serverfarm pod kontrola˛ Metaframe XP . . . . . . . . . . . . . . . . . . . . . . 341
3.48 Rozwiazania
˛
HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
3.49 Rozwiazanie
˛
oparte o Heartbeat i DRBD . . . . . . . . . . . . . . . . . . . . . . 350
4.1
Metodologia IT-WiBe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
4.2
4.3
Matryca kosztów migracji z kategoriami kosztów i obszarami zastosowań . . . . 363
Rozwój kosztów migracji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
4.4
Koszty migracji przypadajace
˛ na użytkownika . . . . . . . . . . . . . . . . . . . 374
SPIS RYSUNKÓW
4.5
514
Przykład rachunku opłacalności migracji Windows NT –> Linux, duży urzad,
˛
ocena kosztów projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
4.6
Przykład rachunku opłacalności migracji Windows NT –> Linux, duży urzad,
˛
ocena wartości kapitału . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
4.7
Przykład rachunku opłacalności migracji Windows NT –> Linux, średni urzad,
˛
4.8
ocena kosztów projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Przykład rachunku opłacalności migracji Windows NT –> Linux, średni urzad,
˛
4.9
Przykład rachunku opłacalności migracji Windows NT –> Linux, mały urzad,
˛
4.10 Przykład rachunku kosztów projektu migracji Windows NT –> Windows 2000,
duży urzad
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
duży urzad,
˛ alternatywna dzierżawa Windows / Office . . . . . . . . . . . . . . . 423
średni urzad
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
średni urzad,
˛ alternatywna dzierżawa Windows / Office . . . . . . . . . . . . . . 424
mały urzad
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
4.15 Przykład rachunku kosztów projektu migracji Windows NT –> Linux, mały urzad,
˛
alternatywna dzierżawa Windows / Office . . . . . . . . . . . . . . . . . . . . . 426
4.16 Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Contact, duży urzad
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
4.17 Przykład rachunku kosztów projektu migracji Exchange 5.5 do Samsung Contact, ś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, duży urzad
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
4.20 Przykład rachunku kosztów projektu migracji Windows NT do Linuksa po stronie serwera, ś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 konieczności i jakości zamiaru migracyjnego . . . . . . . . . . . . 432
5.1
Proces decyzyjny prowadzacy
˛ do wdrożenia OSS . . . . . . . . . . . . . . . . . 442
5.2
Architektura systemu z linuksowym Fat Client . . . . . . . . . . . . . . . . . . . 446
5.3
Zalecana architektura IT w dużym urz˛edzie w przypadku całkowitej „zast˛epuja˛
cej migracji“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
5.4
Obszary zastosowań 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 wyjściowa dla migracji kontynuacyjnej . . . . . . . . . . . . . . . . . . 459
Różne warianty zastapienia
˛
Exchange w przypadku migracji cz˛eś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 jakoś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 odnoś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 uaktualnień systemów informatycznych oraz zamierzeń migracyjnych opracowany przez doradztwo projektowe i
orgranizacyjne dr Peter Röthig oraz prof. dr Detlef Leipelt, FH państwa dla administracji
publicznej – wskazówki i zalecenia – dla realizacji uaktualnień systemów informatycnych
badź
˛ zamierzeń 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 poniższych stronach katalogu, przedstawione zostały wszystkie kryteria:
◦ kryteria według WiBe21 dla kompletnych scenariuszy migracyjnych (kolor granatowy)
◦ kryteria, które można pominać
˛ dla obiektów migracji (kolor pomarań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 wdrażania oraz korzyści z rozwoju
2. 2. Koszty wykorzystania przemysłowego oraz korzyści z wykorzystania przemysłowego
3. 3. Kryteria konieczności
4. 4. Kryteria jakościowo - strategiczne
5. Wskazówki i objaśnienia
9
Patrz katalog specjalnych kryteriów dla obiektów migracji
SPIS RYSUNKÓW
5.9.3.1
Koszty rozwoju / wdrożenia oraz korzyści z rozwoju
517
SPIS RYSUNKÓW
5.9.3.2
Koszty pracy i korzyści z pracy
518
SPIS RYSUNKÓW
519
Wskazówka odnośnie kosztów pracy / korzyści z pracy:
Wszystkie pozycje zawieraja˛ przykładowe informacje odnośnie kosztów i korzyś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 konieczności
SPIS RYSUNKÓW
5.9.3.4
Kryteria jakościowo - strategiczne
520
SPIS RYSUNKÓW
5.9.3.5
521
Wskazówki i objaśnienia
5.9.4 Specjalny katalog z kryteriami IT-WiBe21 dla obiektów migracji
P OZYCJA
NAZWA
1
koszty rozwoju oprogramowania / koszty wdrożenia
KRYTERIÓW
oraz korzyści z rozwoju oprogramowania / korzyści z
wdrożenia
1.1
koszty rozwoju / wdrożenia nowej procedury informatycznej
1.1.1
koszty planowania i wdroż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 badź
˛ 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 jakości
1.1.2.3
1.1.2.3.4
koszty instalacji
koszty osobowe przypadajace
˛ na instalacj˛e sytemu
1.1.3
koszty wdroż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 użytkowników i specjalistycznego personelu IT
1.1.3.5
koszty wdrożenia do pracy użytkowników i specjalistycznego personelu IT
2
koszty pracy i korzyści z pracy
2.1
bieżace
˛ koszty rzeczowe / oszcz˛edności na kosztach rzeczowych
2.1.2
(procentowe) koszty hostów, serwerów i sieci
2.1.2.1
bieżace
˛ koszty dzi˛eki odejściu procedury informatycznej
NOWE
2.1.2.2
bieżace
˛ oszcz˛edności dzi˛eki odejściu procedury informatycznej STARE
2.1.3
(procentowe) koszty stacji roboczych
2.1.3.1
bieżace
NOWE
2.2
bieżace
˛ koszty rzeczowe / oszcz˛edności wynikajace
˛ z bieżacych
˛
kosztów rzeczowych
2.2.2
(procentowe) koszty na stacje robocze
2.2.2.1
bieżace
NOWE
2.2.2.2
bieżace
˛ koszty osobowe / oszcz˛edności wynikajace
˛ z bieża˛
cych kosztów osobowych
2.2.3
opieka nad systemem i administracja systemem
2.2.3.1
bieżace
NOWE
SPIS RYSUNKÓW
2.2.3.2
523
bieżace
˛ korzyści dzi˛eki odejściu procedury informatycznej
STARE
2.3
bieżace
˛ koszty / oszcz˛edności podczas konserwacji / opieki
nad systemem
2.3.1
konserwacja / opieka nad osprz˛etem
2.3.1.1
bieżace
NOWE
2.3.1.2
bieżace
˛ korzyści dzi˛eki odejścio procedury informatycznej
STARE
2.3.2
konserwacja / uaktualnienie oprogramowania
2.3.2.1
bieżace
NOWE
2.3.2.2
bieżace
STARE
2.3.3
koszty zast˛epowania / uzupełniania
2.3.3.1
bieżace
NOWE
2.3.3.2
bieżace
STARE
2.4
pozostałe bieżace
˛ koszty i oszcz˛edności
2.4.2
koszty towarzyszacego
˛
zewn˛etrznego doradztwa
2.4.2.1
bieżace
˛ koszty dzi˛eki odejści procedury informatycznej
NOWE
2.4.2.2
bieżace
˛ korzyści dzi˛eki odejściu procedury informatycnej
STARE
2.4.4
pozostałe bieżace
˛ koszty i korzyści
2.4.4.1
bieżace
NOWE
2.4.4.2
bieżace
˛ korzyści dzi˛eki odejściu procedury informatycznej
STARE
3
Kryteria konieczności
3.1
konieczność zastapienia
˛
starego systemu
SPIS RYSUNKÓW
524
3.1.1
wsparcie - kontynuacja starego systemu
3.1.2
stabilność starego systemu
3.1.2.1
bł˛edy i awarie („downtime“)
3.1.2.2
problemy z konserwacja,
˛ personel – waskie
˛
gardło
3.1.3
elastyczność starego systemu
3.1.3.1
rozbudowa / poszerzenie granic
3.1.3.2
kompatybilność, problemy z interfejsami aktualnie / w
przyszłości
3.1.3.3
przyjazność dla użytkownika
3.2
zachowanie przepisów i praw urz˛edowych
3.2.1
zachowanie zapisów ustawowych
3.2.2
spełnienie kryteriów bezpieczeństwa i ochrona danych
3.2.3
prawidłowość przebiegu prac
3.2.4
spełnienie zadań i zaleceń
4
kryteria jakoś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 pilotażowego
4.1.5
niezależność od producenta
4.2
wzrost jakości podczas wykonywania specjalistycznych zadań
4.2.1
podniesienie wydajności podczas wykonywania zadań
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
atrakcyjność warunków pracy
SPIS RYSUNKÓW
525
4.4.2
zapewnienie kwalifikacji / rozszerzenie kwalifikacji
4.4.3
powszechność / dost˛epność wykształcenia
4.5
efekty bliskości dla obywatela
4.5.4
poprawa wizerunku
4.6
powszechność / dost˛epność oprogramowania
4.6.1
stopień przenikni˛ecia rynku
4.6.2
niezależne wsparcie
4.6.3
posiadane certyfikaty na oprogramowanie
4.6.4
narz˛edzia do administrowania oprogramowaniem
4.7
bezepieczeństwo informatyczne
4.7.1
bezpieczeństwo komunikacji
4.7.2
bezpieczeństwo aplikacji
4.7.3
zabezpieczenie przed awaria˛
4.7.4
zarzadzanie
˛
bezpieczeństwem
4.7.5
bezpieczeństwo inwestycji i planowania
5.9.5 Objaśnienie kryteriów uzupełniajacych
˛
Poniżej przedstawione zostały kryteria, które w ramach istniejacego
˛
WiBE 21 wersja 3.0 oraz
uzupełniajacych
˛
wskazówek i zaleceń z roku 2000 (patrz wyżej) zostały dodane 10 do ocen ekonomicznych projektów migracji znanych już 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 wdrożenia / korzyści z wdrożenia (1.1)
Podczas migracji całego środowiska projekty migracyjne obejmuja˛ także specjalistyczne aplikacje, w przypadku których trzeba stworzyć nowe programy albo wymagane jest przeprogramowanie. Czynności te należy wykazać w „kosztach rozwoju“. Podczas migracji obiektów migracyjnych koszty rozwoju z reguły nie wyst˛epuja,˛ ale wystapi
˛ a˛ koszty wdrożenia. Aby to podkreślić,
rozszerzono kryterium „koszty rozwoju“ o poj˛ecie „koszty wdroż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
Powszechność / dost˛epność wykształcenia (4.4.3)
Nieniejsze kryterium ukierunkowane jest na powszechość wykształcenia i dost˛epność odpowiedniego personelu. Znaczenie tego kryterium należy oceniać jakościowo.
Powszechność / dost˛epność (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 przeważ-
czonym zakresie,
wiedz˛e
można
jest dost˛epne na
jest dost˛epny na
rowane jest tylko
nie organizowane
kształcenie trzeba
przekazać
tylko
rynku a kształ-
rynku; wykształ-
w kilku centrach
w ramach urz˛edu
zorganizować w
w ograniczonym
cenie
ramach urz˛edu
zakresie
oferowane
personel
cenie
z
personel
pokrywa
nie
jest
wszystkie
obszary
5.9.5.3
Powszechność / dost˛epność oprogramowania (4.6)
Stopień przenikni˛ecia rynku (4.6.1)
Należy tu ocenić udział w rynku, jaki posiada oprogramowanie, które ma być zastosowane. W
przypadku znikomej albo niepewnej obecności na rynku, istnieje niebezpieczeństwo, że oprogramowanie, wzgl˛ednie jego dalszy rozwój zostana˛ wstrzymane. Ponadto dobre przenikanie rynku
świadczy o wysokiej akceptacji12 badź
˛ o intensywnym korzystywaniu z oprogramownia przez
użytkowników, z czego można wywnioskować 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-
już oferowany
dywidualnie
miejscach
Niezależne wsparcie (4.6.2)
Niniejsze kryterium zajmuje si˛e możliwościa˛ otrzymania dla oprogramowania, które ma być
12
Akceptacja nie zawsze jest najważniejsza. Polityka biznesowa wymusza w różnych przypadkach decyzje na
korzyść lepiej zoptymalizowanych albo bardziej opłacalnych systemów.
SPIS RYSUNKÓW
527
zastosowane, wsparcia ze strony istniejacych
˛
na rynku, niezależnych przedsi˛ebiorstw. W oparciu
o zasad˛e ochrony inwestycji zapewni to możliwość dalszego korzystania z oprogramowania, nawet gdy producent nie b˛edzie już w stanie kontynuować wsparcia.
Niezależ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
(już) oferowane
indywidualnie
miejscach
Posiadane certyfikaty na oprogramowanie (4.6.3)
Za pomoca˛ tego kryterium należy szukać odpowiedzi na pytanie czy oprogramowanie, które
ma być zastosowane odpowiada wymaganiom prawnym badź
˛ specyficznym dla urz˛edu lub branży,
czy też może trzeba je samemu stworzyć. 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 uzyskać bieżace
˛ certyfikaty, aby zagwarantować zwykłe pokrycie procesów biznesowych. W takiej sytuacji powstaja˛ koszty własne, które można obliczyć 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
ściowa˛ certyfika-
kowa˛ certyfikacj˛e
certyfikatu,
nie
cj˛e
lub tylko zalece-
można
też
nia
zdobyć
jest
regularnie
odnawiany
certy-
fikat, który nie
jest
regularnie
odnawiany
cz˛e-
szczat˛
Dost˛epność narz˛edzi do administrowania oprogramowaniem (4.6.4)
Administrowanie oprgramowaniem, które ma być zastosowane, okazuje si˛e w niektórych przypadkach mało wygodne a nawet trudne. W niniejszym kryterium należy przeanalizować narz˛edzia, które przejmuja˛ albo wspieraja˛ zarzadzanie
˛
tabelami i podstawowymi danymi. Za pomoca˛
odpowiednio inteligentnych narz˛edzi można zwi˛ekszyć zakres i jakość administrowania oraz
zoptymalizować stosowanie zasobów.
Dost˛epność 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
należy
nie sa˛ dost˛epne
sporadycznie
niedost˛epne
administrowania
sa˛
warunkowo
sa˛
ledwo
tworzyć
indywidualnie
i nie można ich
oprogramowa-
indywidualnie
niem
stworzyć
5.9.5.4
do
13
dość
narz˛edzi
narz˛edzia
528
Bezpieczeństwo informatyczne (4.7)
„Bezpieczeństwo“ wpisuje si˛e po cz˛eści w kryteria konieczności (patrz „downtime“ albo „Ochrona
i bezpieczeństwo danych“). W tym miejscu należy wrócić do tego tematu, jednak tym razem z
punktu widzenia strategicznego i jakościowego oraz należy wskazać na udział zarzadzania.
˛
Bezpieczeństwo komunikacji (4.7.1)
Za pomoca˛ nieniejszego kryterium należy sprawdzać bezpieczeń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.?
Bezpieczeństwo komunikacji
0
2
4
6
8
10
niezagrożone
prawie niezagro-
troch˛e zagrożone,
przeci˛etnie
ponadprzeci˛etnie
bardzo silnie za-
żone
w granicach tole-
zagrożone,
zagrożone,
grożone, nie da-
rancji
zakłócenia
uciażliwości
˛
jace
˛ si˛e tolerować
Bezpieczeństwo aplikacji (4.7.2)
Czy oprogramowanie jest sprawdzone pod katem
˛
bezpieczeństwa informatycznego? Na ile
jest ono podatne na ataki z zewnatrz,
˛ wirusy itd.? Czy oprogramowanie ma budow˛e modularna˛
(rozdział systemu od aplikacji, minimalizacja ilości aplikacji do koniecznych funkcji)? Czy istnieja˛ procedury kontroli dost˛epu?
Bezpieczeństwo aplikacji
0
13
2
4
6
8
Dość oznacza, że narz˛edzia oferowane sa˛ przez wiele niezależnych przedsi˛ebiorstw
10
SPIS RYSUNKÓW
niezagrożone
529
prawie niezagro-
przeci˛etnie
ponadprzeci˛etnie
bardzo silnie za-
żone
w granicach tole-
zagrożone,
zagrożone,
grożone, nie da-
rancji
zakłócenia
uciażliwości
˛
jace
Zabezpieczenie przed awaria˛ (4.7.3)
Jak silnie na bezpieczeństwo pracy wpływaja˛ awarie systemu? Czy istnieja˛ odpowiednie Recovery - Routinen?
Zabezpieczenie przed awaria˛
0
2
4
6
8
10
niezagrożone
prawie niezagro-
przeci˛etnie
ponadprzeci˛etnie
bardzo silnie za-
żone
w granicach tole-
zagrożone,
zagrożone,
grożone, nie da-
rancji
zakłócenia
uciażliwości
˛
jace
Zarzadzanie
˛
bezpieczeństwem (4.7.4)
Czy istnieje zarzadzanie
˛
bezpieczeństwem? Czy istnieje pomysł na bezpieczeństwo, który jest
znany wszystkim? Czy istnieje opisany proces kontroli bezpieczeństwa oraz jego dokumentacja?
Zarzadzanie
˛
bezpieczeństwem
0
2
4
6
istnieje
w przeważajacej
˛
cz˛eściowo
istnieje
cz˛eści istnieje
istnieje
miejscami
tylko
8
10
istnieja˛ zaledwie
nie istnieje
sporadyczne
ślady
Bezpieczeństwo inwestycji i planowania (4.7.5)
Niniejsze kryterium zajmuje si˛e suma˛ wpływów wszystkich wcześniej przedstawionych, ważnych kryteriów bezpieczeństwa i wskazuje czy inwestycja i zwiazane
˛
z nia˛ plany sa˛ nadal uzasadnione.
Bezpieczeństwo inwestycji i planowania
0
2
4
6
8
10
niezagrożone
prawie niezagro-
przeci˛etnie
ponadprzeci˛etnie
bardzo silnie za-
żone
w granicach tole-
zagrożone,
zagrożone,
grożone, nie dajace
˛
rancji
zakłócenia
uciażliwości
˛
si˛e tolerować

plik pdf

Transkrypt

Podobne dokumenty

magiel szkolny

Dzień Kobiet – 8 marca

Metody pozyskiwania 3 He

Przemysław Sowa - Serwer WWW Abashe