na naszych oczach gigantyczne koncerny tworzące oprogramowanie komer-
cyjne, odczuwające swoiste zadowolenie z odniesionych sukcesów rynkowych
zaczynają popełniać coraz więcej poważnych błędów, zarówno w sferze pro-
wadzonej przez siebie polityki, jak i jakości oferowanych przez siebie pro-
duktów.

Do coraz bardziej widocznej porażki idei komercyjnego oprogramowania

produkowanego dla masowego odbiorcy przyczyniło się kilka czynników, z
których najważniejszymi (moim zdaniem) są:

• ignorowanie i stosunkowo łatwe niszczenie małej konkurencji,

• monopolizacja rynku, a w efekcie powstawanie monokultury wrażliwej

na masowe, automatyczne ataki różnego rodzaju,

• tworzenie rozwiązań niezgodnych z obowiązującymi normami i stan-

dardami celem „związania” klientów z jedynie słusznym syste-
mem/jedynie słuszną aplikacją,

• windowanie cen na licencje oprogramowania w sposób nie mający nic

wspólnego z rzeczywistymi kosztami produkcji i dystrybucji oferowa-
nego oprogramowania,

• coraz więcej zakazów i nakazów narzucanych końcowemu odbiorcy

oprogramowania,

• umieszczanie w oprogramowaniu „dodatkowego” kodu nie związanego

z podstawową funkcjonalnością, za którą płaci nabywca, bardzo często
mającego działać sprzecznie z interesami użytkownika aplikacji,

• świadome i celowe ukrywanie poważnych błędów w oprogramowaniu,

• ostatnio - forsowanie koncepcji patentów na rozwiązania software’owe.

Generalnie zasadą miał stać się model, w którym użytkownik ma prawo,

a nawet obowiązek zapłacić za licencję używanego oprogramowania, ale nie
ma prawa decydować ani o funkcjonalności, ani też o sposobie w jaki i do
czego danego oprogramowania używa.

Być może te Orwell’owskie wizje ziściłyby się szybciej niż przypuszczamy,

gdyby nie jeden, mały, całkowiecie lekceważony przez „wielkich tego świata”
fenomen — wolne oprogramowanie.

Do niedawna wolne czy też otwarte oprogramowanie (ang. open sour-

ce software) nie było rozpatrywane przez największe koncerny branży jako

godny rywal. Faktem jest, że przez niemal całe lata 90-te XX wieku wol-
ne oprogramowanie było jeszcze zbyt niedojrzałe, niemniej nie dostrzegano
ogromnej dynamiki jego rozwoju.

Dziesiątki, a może i setki tysięcy programistów z całego świata poświę-

cało niemal każdą wolną chwilę na rozwój i poprawianie swoich publicznie
dostępnych produkcji.

W ramach wolnego oprogramowania powstały w tym czasie nie tylko

kompletne i coraz bardziej wyrafinowane systemy operacyjne (Linux, wiele
odmian BSD, GNU/Hurd), ale również dziesiątki tysięcy małych, średnich
i dużych aplikacji obejmujących praktycznie każdą dziedzinę zastosowań.

Wolne oprogramowanie okazało się być niezwykle uniwersalne i łatwo

dostosowujące się do nowych rozwiązań sprzętowych jak i nowych standar-
dów.

Flagowy system operacyjny wywodzący się z rodziny wolnego oprogra-

mowania - Linux - jest obecnie dostępny na szereg platform sprzętowych
od komputerów osobistych różnych marek, poprzez wielkie serwery i kom-
putery klasy mainframe do urządzeń PDA, sterowników przemysłowych czy
telefonów komórkowych i cyfrowych odtwarzaczy muzycznych.

W ostatnich latach okazało się, iż dojrzałe już wolne oprogramowanie

zaczyna wymuszać coraz poważniejsze zmiany na rynku oprogramowania.
Wszystko zaczęło się od problemów ze sprzedażą komercyjnych systemów
UNIX

, które w coraz większym stopniu przegrywały konkurencję z Linu-

xem.

Koncerny sprzedające do tej pory swoje własne rozwiązania uniksowe,

chcąc nie chcąc rozpoczęły migrację w kierunku Linuxa, który coraz silniej
zaczął zastępować promowane do tej pory rozwiązania. Wielcy producenci
sprzętu komputerowego zaczęli oferować kompletne systemy komputerowe z
preinstalowanym Linuxem oraz wsparciem serwisowym dla tej właśnie plat-
formy.

Reakcją programistów tworzących system Linux było rozwinięcie syste-

mu w kierunku właściwości wymaganych na rynkach korporacyjnych (ten-
dencja wyraźnie zaznaczona od daty wypuszczenia jądra 2.4 i silnie utrwa-
lona w obecnej serii 2.6). Do najważniejszych cech tutaj należą: polepszona
skalowalność, wydajność, nowe systemy plików, obsługa wielkich pamięci
masowych, klastry.

Największy gracz na rynku oprogramowania — Microsoft — początkowo

twierdził, iż „Linux nie jest dla nas konkurentem”, a następnie — gdy oka-
zało się, że odchodzenie od rozwiązań sprzedawanych przez firmę na „M”
staje się coraz silniejszą tendencją

— przeszedł do „czynu” we właściwy

dla siebie, tradycyjnie już stroniący od zasad fair play, sposób.

Mam tu na myśli: zalecenie UE dotyczące migracji do wolnego oprogramowania dla

instytucji związanych z administracją i zarządzaniem, decyzję Japonii, Chin i Korei o
migracji w kierunku wolnego oprogramowania, usunięcie produktów firmy Microsoft z
instytucji o krytycznym znaczeniu dla bezpieczeństwa i obronności Federacji Rosyjskiej

Najbardziej znanym ostatnio „chwytem” było zasponsorowanie przez Mi-

crosoft słynnego procesu wytoczonego twórcom Linuxa przez podupadają-
cą firmę SCO — z góry skazanego na niepowodzenie zresztą. W zamiarze
sponsora cała sprawa miała spowodować przynajmniej spadek przychylności
mediów dla systemu spod znaku pingwina.

Kolejna próbą jest usiłowanie przeforsowania możliwości patentowania

rozwiązań dotyczących oprogramowania w USA i Unii Europejskiej. W myśl
takich przepisów patentowych możnaby opatentować np. przesuwanie za-
wartości okna myszką, powszechnie stosowany „pasek postępu” czy też np.
kursor myszki. W efekcie pozostali twórcy oprogramowania pragnący wyko-
rzystywać tego typu elementy w swoich systemach i aplikacjach musieliby
płacić posiadaczowi patentu stosowne wynagrodzenie, lub byliby pozbawieni
praw do stosowania tego typu rozwiązań w swoich produktach.

Dlaczego konkurenci Linuxa muszą uciekać się do takich metod? Otóż

produkty wolnego oprogramowania różnią się w znaczący sposób od dowol-
nego produktu komercyjnego — nie da się ich bowiem kupić. Nie można
więc wykupić i zniszczyć konkurenta. Wolne oprogramowanie jest dobrem
publicznym, którego twórcy nie są najczęściej powiązani poprzez przynależ-
ność do jednej, konkretnej firmy lub organizacji. W przypadku większości
projektów (szczególnie tych dużych), twórcami są osoby dosłownie z całego
świata, kontaktujące się ze sobą wyłącznie za pośrednictwem Internetu.

W świecie wolnego oprogramowania nacisk kładziony jest na wartość do-

daną. Słowem — firmy zarabiają przede wszystkim nie na sprzedaży opro-
gramowania lub licencji na jego użytkownie, lecz na usługach świadczonych
użytkownikom oprogramowania (instalacje, wdrożenia, konsultacje, wspar-
cie techniczne, opracowywanie aplikacji na zamówienie — dopasowanych do
potrzeb danego klienta, a jednocześnie bazujących na rozwiązaniach wolnego
oprogramowania i na otwartych, powszechnie dostępnych stadnardach).

Dlaczego tak istotne staje się opieranie swoich rozwiązań na standar-

dach otwartych? Otóż jest to właśnie element zapewniający niezależność
końcowemu odbiorcy rozwiązania informatycznego. Jeżeli używana aplika-
cja porozumiewa się ze światem zewnętrznym w oparciu o opublikowane i
uznane standardy, to w razie takiej konieczności można ją zastąpić innym,
konkurencyjnym rozwiązaniem bazującym na tych samych standardach.

Sytuacja taka zachodzi niezwykle rzadko w świecie aplikacji i standardów

zamkniętych, należących do konkretnego producenta, który świadomie i ce-
lowo dba o zachowanie jak najmniejszej zgodności oferowanych przez siebie
rozwiązań z rozwiązaniami oferowanymi przez konkurencję.

W moim wystąpieniu chciałbym zwrócić Państwa uwagę na możliwość

migracji od rozwiązań zamknietych do rozwiązań otwartych, zapewniających
osiągnięcie takich samych lub lepszych efektów, przy znaczącym zmniejsze-
niu kosztów i równoczesnym zwiększeniu bezpieczeństwa implementowanych
rozwiązań.

Skoncentruję się na przybliżeniu możliwości jakie oferuje w chwili obecnej

popularny system operacyjny Linux oraz na skutecznych sposobach migracji
rozwiązań z innych systemów operacyjnych używanych dotychczas.

Zastanawiając się nad dokonaniem tego typu migracji, pamiętajmy, iż

przed nami dokonały jej miliony ludzi na całym świecie, udowadniając, że
jest to mozliwe i opłacalne.

Linux — nieco historii

Wszystko zaczęło się od legendarnej informacji opublikowanej przez

fińskiego

studenta

—

Linusa

Torvaldsa

—

grupie

dyskusyjnej

comp.os.minix:

Autor: Linus Benedict Torvalds <torvalds@klaava.Helsinki.FI>
Temat: Free minix-like kernel sources for 386-AT
Grupa dyskusyjna: comp.os.minix
Data: 1991-10-05 08:53:28 PST

Do you pine for the nice days of minix-1.1, when men
were men and wrote their own device drivers? Are you without
a nice project and just dying to cut your teeth on a OS you
can try to modify for your needs? Are you finding it frustrating
when everything works on minix? No more all- nighters to get
a nifty program working? Then this post might be just for you :-)

As I mentioned a month(?) ago, I’m working on a free
version of a minix-lookalike for AT-386 computers. It has
finally reached the stage where it’s even usable (though may
not be depending on what you want), and I am willing to
put out the sources for wider distribution. It is just version
0.02 (+1 (very small) patch already), but I’ve successfully run
bash/gcc/gnu-make/gnu-sed/compress etc under it.

Sources for this pet project of mine can be found at nic.funet.fi
(128.214.6.100) in the directory /pub/OS/Linux. The directory
also contains some README-file and a couple of binaries to
work under linux (bash, update and gcc, what more can you ask
for :-). Full kernel source is provided, as no minix code has been
used. Library sources are only partially free, so that cannot be
distributed currently. The system is able to compile ”as-is” and
has been known to work. Heh. Sources to the binaries (bash and
gcc) can be found at the same place in /pub/gnu.

ALERT! WARNING! NOTE! These sources still need minix-386
to be compiled (and gcc-1.40, possibly 1.37.1, haven’t tested),
and you need minix to set it up if you want to run it, so it is
not yet a standalone system for those of you without minix. I’m
working on it. You also need to be something of a hacker to set
it up (?), so for those hoping for an alternative to minix-386,
please ignore me. It is currently meant for hackers interested in
operating systems and 386’s with access to minix.

The system needs an AT-compatible harddisk (IDE is fine)
and EGA/VGA. If you are still interested, please ftp the
README/RELNOTES, and/or mail me for additional info.

I can (well, almost) hear you asking yourselves ”why?”.
Hurd will be out in a year (or two, or next month, who knows),
and I’ve already got minix. This is a program for hackers by
a hacker. I’ve enjouyed doing it, and somebody might enjoy
looking at it and even modifying it for their own needs. It is still
small enough to understand, use and modify, and I’m looking
forward to any comments you might have.

I’m also interested in hearing from anybody who has writ-
ten any of the utilities/library functions for minix. If your
efforts are freely distributable (under copyright or even public
domain), I’d like to hear from you, so I can add them to the
system. I’m using Earl Chews estdio right now (thanks for a
nice and working system Earl), and similar works will be very
wellcome. Your (C)’s will of course be left intact. Drop me a
line if you are willing to let me use your code.

Linus

PS. to PHIL NELSON! I’m unable to get through to you,
and keep getting ”forward error - strawberry unknown domain”
or something.

Paradoksalnie wspomniany tu przez Linusa system GNU/Hurd do dzisiaj

pozostaje w fazie początkowego rozwoju właśnie za sprawą Linuxa.

Dzisiejszy Linux to bardzo nowoczesny, stabilny, skalowalny, wielozada-

niowy i wielodostępny system operacyjny obsługujący większość istniejących
protokołów sieciowych.

Linux jest systemem wolnodostępnym. Użytkownicy systemu mają nie

tylko prawo do jego nieodpłatnego użytkowania, ale również do dokonywania
w nim dowolnych modyfikacji w zależności od potrzeb.

Kod źródłowy systemu jest publicznie dostępny dla wszystkich, co gwa-

rantuje licencja GPL, pod którą jest rozpowszechniany Linux.

Nazwa Linux dotyczy samego jądra systemu, którego pierwotnym twórcą

jest Linus Torvalds.

Jądro systemu wraz z bibliotekami funkcji i oprogramowaniem narzę-

dziowym nazywamy dystrybucją.

Obecnie kod napisany przez Linusa stanowi zaledwie około 2% całości kodu jądra

systemu.

W chwili obecnej istnieje wiele dystrybucji Linuxa o różnych cechach

użytkowych i możliwościach. Początkujący użytkownik może gubić się w tej
różnorodności i mieć problem z dokonaniem właściwego dla siebie wyboru.
Na szczęście jedną z ważniejszych cech Linuxa i generalnie oprogramowa-
nia otwartego jest duża dostępność informacji o nim i o wszystkim co jego
dotyczy.

Jak przygotować się do migracji?

Zanim rozpoczniemy migrację do Linuxa musimy odpowiedzieć sobie na

podstawowe pytania:

• jaka jest rola obecnie stosowanego rozwiązania? (Stacja robocza, no-

tebook, serwer, firewall, mostek sieciowy, bramka sieciowa itd.)

• czy sprzęt na którym mamy zamiar zainstalować Linuxa jest w pełni

obsługiwany przez . . . Linuxa?

• jakiego rodzaju aplikacje wykorzystywane są obecnie?

• które z tych aplikacji wykorzystywane są wyłącznie z uwagi na fakt

użytkowania takiej czy innej platformy sprzętowej/systemowej? (Być
może z części aplikacji będziemy mogli zrezygnować, gdyż w Linuxie
tego typu funkcjonalność okaże się po prostu zbędna)

• jak będzie wyglądała kwestia współpracy z resztą systemu informa-

tycznego? (Z jakimi innymy systemami operacyjnymi ma współpraco-
wać nasze rozwiązanie i w jaki sposób ma to się odbywać?)

• jak wyobrażamy sobie przeniesienie naszych danych? (Czy potrzebna

będzie konwersja formatów danych, a jeśli tak, to czy powinniśmy do-
konać jej używając obecnego systemu operacyjnego, czy też będzie to
możliwe pod Linuxem?)

• jak wygląda rachunek zysków i strat w wyniku takiej migracji? (Sło-

wem — co zyskujemy, a co tracimy i ile to wszystko będzie nas kosz-
towało?)

3.1

Rola obecnie stosowanego rozwiązania

W niniejszym opracowaniu skoncentruję się na dwóch możliwych rolach

przenoszonego systemu: na roli stacji roboczej oraz na roli serwera interne-
towego.

Pozostałe przypadki, wspomniane powyżej, wymagają o wiele bardziej

specjalistycznych rozważań, które mogłyby jedynie zagmatwać obraz proce-
dur, które pragnę tutaj zaproponować.

3.1.1

Stacja robocza

W przypadku stacji roboczej, bardzo pracochłonna staje się analiza opro-

gramowania zainstalowanego na komputerze pod kątem wielu, różnorodnych
zastosowań i formatów używanych danych (pliki pakietów biurowych, pliki

multimedialne, poczta elektroniczna). Wynika to z dużej różnorodności za-
instalowanego oprogramowania — zazwyczaj większej niż ma to miejsce w
przypadku serwera.

Inna jest też złożoność opcji sprzętowych. Stacja robocza jest często

wyposażona w zaawansowaną grafikę, kartę dźwiękową, wiele różnych inter-
fejsów obsługujących rozmaite peryferia

, modem, kartę sieciową — często

tanią i dość „egzotyczną”.

Z wymienionych tutaj przyczyn migracja do Linuxa w przypadku sta-

cji roboczej jest na ogół trudniejsza, aczkolwiek istnieją narzędzia, które
potrafią ją znacznie ułatwić. O tym jakie to narzędzia napiszę za moment.

3.1.2

Serwer

Dobrze skonfigurowany i administrowany serwer udostępnia w sieci wy-

łącznie te usługi, które są przydatne w sieci i zostały celowo (świadomie)
udostępnione. W zdecydowanej większości przypadków liczba udostępnia-
nych usług sieciowych jest niewielka i dzięki temu łatwo daje się określić
czego wymagamy od systemu Linux.

Podobnie wygląda sprawa kompatybilności sprzętowej. Serwery wyko-

rzystują o wiele mniej peryferiów niż stacje robocze, najczęściej nie są wy-
posażone w kartę dźwiękową i zaawansowaną kartę graficzną

Można powiedzieć, że serwery wykorzystują innego rodzaju urządzenia

peryferyjne, z którymi niekiedy możemy mieć problemy.

Do najczęściej spotykanych urządzeń peryferyjnych w serwerach zalicza-

my:

• różnego rodzaju urządzenia do archiwizacji danych i ich kontrolery,

• różnego rodzaju kontrolery dyskowe, a w tym kontrolery pamięci ma-

sowej typu RAID,

• różne interfejsy komunikacyjne (szeregowe, równoległe, karty sieciowe

różnych typów).

Przed dokonaniem wymiany systemu na serwerze musimy sprawdzić:

• jakie usługi sieciowe udostępnia serwer i jakie oprogramowanie w syste-

mie Linux zapewnia udostępnianie takich samych bądź analogicznych
usług,

• jak wygląda dostępność linuksowych sterowników urządzeń peryferyj-

nych zastosowanych w serwerze .

Na przykład: drukarka, skaner, czytnik jakiegoś rodzaju kart pamięci, przystawkę do

współpracy z PDA lub telefonem komórkowym, tablet, kamera lub aparat cyfrowy itd.

A jeśli nawet posiadają tego typu komponenty, to i tak nie muszą one być w pełni

obsługiwane przez system, a więc nie musimy tracić cennego czasu na zapewnienie pełnej
obsługi tych urządzeń.

3.2

Kompatybilność z Linuxem

3.2.1

Zgodność sprzętowa — listy kontrolne

W uporządkowaniu procesu migracji do Linuxa nieocenione usługi mogą

nam oddać dobre, stare listy kontrolne (ang. checklists).

Logika sugeruje nam stworzenie osobnych list kontrolnych dla poszczegól-

nych komputerów, o ile nie mamy 100% pewności, że konfiguracja sprzętowa
wszystkich maszyn jest identyczna.

Listy kontrolne można sporządzić w formie tabel, na przykład takich jak

Tabela 1: Lista kontrolna sprzętu

Rodzaj sprzętu

Producent

Model

Adres witryny WWW

CPU
Płyta główna
Chipset
Kontroler RAID
Dysk twardy nr 1
Dysk twardy nr 2
Dysk twardy nr 3
Dysk twardy nr 4
Napęd DVD/CD
Inny napęd (ZIP?)
Karta graficzna
Karta dźwiękowa
Karta sieciowa
Drukarka
Modem
Mysz
Urządzenia USB:

Inne urządzenia:

Lista komponentów sprzętowych w tym przykładzie pasuje do komputerów klasy PC

z procesorami z rodziny Intel x86, dla innych platform może być ona nieco inna. Jednocze-
śnie należy pamiętać, że konfiguracja sprzętowa poszczególnych komputerów nawet tego
samego typu może się dość poważnie różnić.

Po wpisaniu danych wszystkich komponentów do tabeli należy upewnić

się, czy Linux wspiera te komponenty bezpośrednio, czy też wymagane są
dodatkowe sterowniki, lub też inne oprogramowanie umożliwiające wykorzy-
stanie danego urządzenia w Linuxie.

Istnieje kilka sposobów sprawdzenia zgodności komponentów sprzęto-

wych z Linuxem. Do najczęściej stosowanych sposobów należą:

• sprawdzenie na witrynach WWW producentów, czy zamieszczają in-

formacje na temat współpracy produkowanych przez nich urządzeń z
Linuxem,

• uruchomienie na danym komputerze płyty CD z dystrybucją Linuxa

o nazwie Knoppix

• użycie dobrej wyszukiwarki sieciowej,

W rzeczywistości niezwykle rzadko zdarza się, że jakieś urządzenie nie

jest w żaden sposób obsługiwane przez Linuxa lub jego aplikacje.

Sytuacja taka może mieć miejsce w przypadku bardzo nowych urządzeń,

które dopiero co zostały wypuszczonena rynek.

Jeżeli producent takiego urządzenia nie udostępnił sterownika do Linuxa

oraz nie udostępnił dokumentacji dla programistów — może upłynąć nawet
kilka miesięcy zanim dane urządzenie zostanie „rozgryzione” przez progra-
mistów Linuxa i będzie go można używać w tym systemie.

Niemniej nawet w takich trudnych przypadkach jest to zazwyczaj jedynie

kwestią czasu (dodatkowo im bardziej popularne stanie się dane urządzenie,
tym szybciej pojawi się sterownik dla Linuxa).

Dodatkowo, w dzisiejszych czasach, coraz rzadziej urządzenia peryferyjne

wymagają odrębnego sterownika do konkretnego modelu. Wynika to z faktu
uniwersalizacji interfejsów i tworzenia tzw. klas urządzeń. Tendencja taka
jest bardzo wyraźnie zauważalna w świecie urządzeń podłączanych do kom-
putera za pośrednictwem interfejsów USB 1.1 lub 2.0 oraz FireWire (IEEE
1394/IEEE 1394b).

Jeśli producent oferuje sterowniki dla Linuxa, warto je pobrać i wypalić płytę CD w

formacie ISO 9660 z kopią tych sterowników,

Knoppix

nie wymaga instalacji na twardym dysku komputera, ani też jakichkolwiek

modyfikacji zawartości dysku — może pracować w pełnym zakresie po wystartowaniu
komputera z płyty CD! Ponieważ Knoppix posiada bardzo dobry system automatycznego
wykrywania zasobów sprzętowych można go użyć do przetestowania komputera i jego
komponentów w warunkach pracy pod kontrolą systemu Linux.

Doskonale nadaje się do tego

Google

. W większości przypadków wystarczy podać

nazwę lub model urządzenia oraz słowo Linux, w celu wyszukania miejsc w sieci, w których
ktoś porusza temat współpracy danego urządzenia z Linuxem. Dobrym pomysłem jest
przeszukanie nie tylko witryn WWW, ale również archiwów Grup Dyskusyjnych.

Urządzenia tego typu należą przeważnie do odpowiedniej klasy (np.

dysk

, modem, urządzenia do wprowadzania danych (mysz, klawiatura, joy-

stick, gamepad) itd.

Kupując nowy komputer z zamiarem zainstalowania na nim Linuxa, war-

to wcześniej upewnić się, czy wszystkie zastosowane w nim urządzenia będą
obsługiwane przez system.

Zgodność sprzętowa jest szczególnie istotna w przypadku serwerów. Pro-

stą receptą na jej zachowanie jest kupowanie markowych produktów, lub
zbudowanie serwera wyłącznie z komponentów dedykowanych do tego typu
zastosowań.

W mojej wieloletniej praktyce zawodowej nie miałem ani jednego przy-

padku problemów z instalacją Linuxa (lub innego systemu operacyjnego) na
komputerze zbudowanym w oparciu o markowe komponenty dedykowane do
zadań serwerowych.

3.2.2

Stacja robocza, a zgodność danych i aplikacji

Podejmując decyzję o migracji należy pamiętać, że w większości przypad-

ków wiąże się to z wymianą nie tylko samego systemu operacyjnego (oraz
jego narzędzi), ale również z wymianą użytkowanych aplikacji.

Dlatego też, w o wiele mniejszym stopniu będę skupiał się tu na zgodności

samych aplikacji.

W większości przypadków zachowanie pełnej zgodności (w znaczeniu:

ten sam interfejs użytkownika, dokładnie taki sam sposób użytkowania, do-
kładnie takie same typowe błędy w pracy) po prostu nie będzie możliwe.

W przypadku migracji pomiędzy systemami operacyjnymi o wiele waż-

niejsze jest zachowanie możliwości wykorzystania plików danych gromadzo-
nych i przetwarzanych przez użytkownika w poprzednio wykorzystywanym
systemie.

Bardzo duże znaczenie ma kopatybilność danych z otoczeniem — czyli

zachowanie możliwości wymiany przetwarzanych dokumentów z otoczeniem
(niekoniecznie używającym Linuxa).

Lwią część zadania realizują za nas standardy komunikacyjne i standardy

dotyczące formatów danych. Na przykład:

W tej klasie niejednokrotnie obsługiwane są nawet aparaty cyfrowe oraz czytniki róż-

nego rodzaju kart pamięci.

Jeśli przechodzimy do Linuxa z innego systemu uniksowego zmiany te będą o wiele

mniej odczuwalne. W wielu przypadkach może okazać się, że będziemy używać dokładnie
tych samych aplikacji i niezwykle podobnych narzędzi systemowych.

Jeżeli jest to konieczne istnieje możliwość uruchamiania niektórych aplikacji z systemu

Windows — lub nawet całego systemu Windows wraz z aplikacjami — jako aplikacji w
Linuxie. Wymaga to jednak dodatkowego oprogramowania i niekiedy stawia pod znakiem
zapytania sens migracji — wszak aplikacje systemu Windows najlepiej uruchamiać po
prostu pod Windows.

• pliki typu JPEG, TIFF czy też GIF są tak samo dobrze obsługiwane

przez aplikacje w systemie Windows, jak i Linux, czy też Mac OS — a
więc nie ma obawy, że nasze zdjęcia, czy grafiki okażą się bezużyteczne
pod Linuxem,

• paradoksalnie nawet pliki DOC, RTF czy XLS mogą być (i są!) używa-

ne na innych platformach niż Windows i nie ma obowiązku używania
do tego „ jedynie słusznego” pakietu Office pochodzącego od tego sa-
mego producenta,

• dzięki bogatemu oprogramowaniu odtwarzanie plików multimedial-

nych (dźwięk, filmy) nie stanowi obecnie problemu pod Linuxem,

• sprawę wymiany danych załatwiają nam protokoły sieciowe działające

w różnych warstwach tzw. modelu ISO — użytkownik nie musi martwić
się o to, czy Linux „dogada się” w sieci z komputerem pracującym pod
kontrolą Windows, Mac OS, czy też innego, współcześnie używanego
systemu operacyjnego.

Jeśli chodzi o Internet i stosowane w nim usługi — cóż można powiedzieć

na ten temat?

Systemy uniksowe (w tym Linux) doskonale obsługiwały potrzebne tu

protokoły i usługi sieciowe, jeszcze zanim w innych systemach operacyjnych
zaczęto je implementować. Tak więc ta strona nie stanowi na ogół proble-
mu — o ile, rzecz jasna, konfiguracja oprogramowania linuxowego będzie
prawidłowa.

3.2.3

Serwer, a zgodność danych i usług

W przypadku serwera sprawa jest na ogół wyraźnie prostsza niż w przy-

padku stacji roboczej.

Musimy sporządzić listę usług udostępnianych przez dotychczasowy ser-

wer i dowiedzieć się, jak wygląda udostępnianie analogicznych usług w Li-
nuxie.

Linux (podobnie jak większość systemów uniksowych) doskonale czuje się

w roli serwera sieciowego. Linux wyróżnia bogactwo: narzędzi serwerowych,
języków skryptowych umożliwiających automatyzację zadań związanych z
zarządzaniem serwerem, jak również obsługiwanych protokołów sieciowych
— słowem usługa musi być naprawdę egzotyczna i niestandardowa, aby nie
dało się jej udostępnić na serwerze pracującym pod kontrolą Linuxa.

Ostatnio pojawia się coraz więcej pakietów biurowych dla systemu Linux. Niektóre z

nich są proste i małe, inne mnogością funkcji i wielkością dorównują słynnemu Microsoft
Office — najbardziej znanym z nich jest publicznie dostępny:

OpenOffice.org

Można powiedzieć więcej: Linux może świadczyć usługi udostępniania w sieci np.

dysków czy drukarek dla bardzo różnych systemów operacyjnych, używających różnych
protokołów sieciowych.

Rzecz jasna istnieją rozwiązania, które z założenia mają być niezwykle

trudne do przeniesienia na inne platformy — szerzej wspominałem o tym
we wstępie do niniejszego opracowania.

Niemniej w większości tego typu przypadków udaje się zastąpić dane

rozwiązanie odpowiednikiem funkcjonalnym, który niezwykle często działa
stabilniej i wydajniej — w efekcie zaoszczędzając czas i środki niezbędne do
serwisowania dotychczasowego rozwiązania.

3.3

Kompatybilność Linuxa

Więdząc jak wyglądają kwestie zgodności z Linuxem możemy zastanowić

się nad zgodnością Linuxa z otaczającym go środowiskiem.

3.3.1

Protokoły sieciowe, a Linux

Nie jest łatwo jednoznacznie powiedzieć, ile dokładnie protokołów sie-

ciowych obsługuje Linux. Śmiało natomiast można stwierdzić, że jest tych
protokołów (w różnych warstwach modelu sieciowego) naprawdę dużo.

Sytuację utrudnia nieco fakt, że część protokołów obsługiwana jest przez

jądro systemu, a część przez aplikacje, które mogą być uruchamiane pod
kontroką Linuxa — mogą, ale nie muszą.

Do najważniejszych protokołów sieciowych dostępnych w Linuxie należą:

• IP i związane z nim protokoły (np. TCP, UDP, ICMP),

• IPv6 i powiązane z nim protokoły,

• IPX,

• DECnet,

• SMB (NetBIOS),

• AppleTalk,

• X.25/LAPB,

• i inne.

Linux obsługuje wiele rodzajów mediów sieciowych (np. ARCnet, Ether-

net 10/100/1000, Token Ring, ISDN, łącza szeregowe i równoległe, adaptery
interfejsów WAN (np. V.35), łącza bezprzewodowe — zarówno WiFi, jak i
packet radio (AX.25) oraz inne protokoły: SNMP, FDDI, HDLC, Frame
Relay).

Jądro systemu wspiera m.in. takie funkcje sieciowe, jak:

• firewall: filtrowanie (stateless i stateful ), NAT/NAPT, obsługa i mo-

dyfikacja flag w nagłowkach, współpraca z funkcjami QoS),

• socket filtering (z wyjątkiem obsługi gniazd TCP),

• IP multicasting i IP multicast router (PIM-SM v1 i v2),

• funkcje zaawansowanej bramki IP,

• funkcje klienta DHCP, BOOTP, RARP,

• tunelowanie IP, w tym również GRE (ang. Generic Routing Encapsu-

lation) z obsługą IPv4 lub IPv6 po IPv4),

• ECN (ang. Explicit Congestion Notification)

• TCP syncookie,

• wsparcie dla sieci typu VLAN zgodnie ze standardem 802.1Q,

• praca w roli mostka Ethernet (802.1d),

• obsługa QoS

i/lub fair queueing,

• sieciowe systemy plików: Coda, NFS (w tym NFSv3), SMB, NCP,

• tzw. packet generator — możliwość generowania pakietów sieciowych

o zadanych parametrach, z regulowaną prędkością — narzędzie przy-
datne do testowania sieci i interfejsów sieciowych.

Jak już wspomniałem, niektóre protokoły sieciowe (i zdecydowana więk-

szość usług sieciowych) obsługiwane są przez dodatkowe oprogramowanie
działające w systemie Linux.

Daje to trudne do przecenienia możliwości zastosowania Linuxa jako

wydajnego, stabilnego i bezpiecznego rozwiązania dedykowanego do zadań
sieciowych.

Linux może z powodzeniem pełnić funkcje serwerów w „obcych” sieciach.

Oto trzy najbardziej znane przykłady:

Firewall NetFilter wbudowany w jądro systemu Linux posiada bardzo wiele funkcji

i możliwości — osoby zainteresowane jego możliwościami powinny udać się bezpośrednio
do źródła —

serwisu WWW

poświęconego temu oprogramowaniu.

Rzecz jasna, używając Linuxa, można uruchomić aplikacje serwerów tych usług. W

tym celu należy uruchomić programy obsługujące serwowanie danej usługi: dhcpd, bootpd
lub rarpd

z obsługą RSVP (ang. Resource Reservation Protocol ) oraz diffserv (ang. Differentia-

ted Services).

W zdecydowanej większości przypadków oprogramowanie obsługujące obsługę dodat-

kowych protokołów i udostępnianie usług sieciowych jest po prostu zawarte w dystrybucji
systemu Linux.

• serwer emulujący serwer Microsoft Windows —

Samba

• serwer emulujący serwer Novell Netware —

MARS NWE

• serwer zgodny z protokołami sieciowymi specyficznymi dla kompute-

rów Apple Macintosh —

netatalk

Niejednokrotnie serwer tego typu, działający na Linuxie, może okazać

się bardziej wydajny i stabilny od oryginału.

Linux jest systemem znanym i uznanym w roli serwera usług w sieci

Internet oraz bazujących na technologiach internetowych sieciach korpora-
cyjnych (typu intranet czy extranet).

Rozpowszechniany m.in. wraz z większością dystrybucji Linuxa serwer

WWW o nazwie

Apache

jest obecnie

najpopularniejszym

serwerem WWW

na świecie.

W systemie Linux można uruchamiać wiele konkurencyjnych (zarówno

pod względem oferowanych możliwości jak i wydajności) serwerów poczty
elektronicznej (np. Qmail, Postfix, Sendmail, Exim czy ZMailer). Serwery
te mogą łatwo zostać wzbogacone o: pakiety antywirusowe, dodatkową au-
toryzację użytkowników lub specjalizowane narzędzia do zwalczania spamu.

Linux może być doskonałym serwerem popularnych usług internetowych,

takich jak: Usenet News, Jabber, FTP, udostępnianie strumieni multimedial-
nych, usług typu peer-to-peer i wiele innych. Na tyle dużo, abym nie mógł
ich tu wszystkich wymienić.

W sieciach korporacyjnych, dochodzą jeszcze: serwery baz danych, usłu-

gi wspomagające pracę grupową, sieciowe aplikacje do zarządzania przedsię-
biorstwem oraz udostępnianie wszelakiego typu zasobów (dyski, drukarki,
urządzenia faxowe, aplikacje VoIP itd.).

Opisanie funkcjonalności Linuxa jako serwera sieciowego wykracza da-

leko poza zakres niniejszego opracowania. Ogromną ilość informacji na ten
temat można znaleźć: w dokumentacji samego Linuxa i dostarczanych wraz
z nim narzędzi, w Internecie, jak i w dowolnej księgarni oferującej książki o
tematyce informatycznej.

Szczególnie interesującym zastosowaniem Linuxa jest też zastępowanie

kosztownych, specjalizowanych urządzeń, takich jak routery WAN, inteli-
gentne mostki i bramy sieciowe, komputerami klasy PC pracującymi pod
kontrolą systemu Linux.

Najbardziej znanym przykładem oprogramowania umożliwiającego wy-

korzystanie komputera z Linuxem w roli routera WAN jest pakiet o nazwie:

Zebra

Zebra umożliwia zbudowanie na bazie Linuxa profesjonalnego routera

dla sieci WAN obsługującego takie protokoły, jak:

• RIP, RIPv2 i RIPng,

• OSPF,

• IGMP i IGMPv2,

• spełnia wymagania RFC 1812,

• BGP4.

W najbliższym czasie zostaną dodane: SNMP, MIB2, Bridge i Ether-

net MIB, RMON, RIPv2 MIB, OSPF MIB, BGP4 MIB, Entity MIB, IP
Forwarding Table MIB.

Rzecz jasna, do prawidłowego funkcjonowania Zebry niezbędne jest wy-

posażenie komputera PC w karty sprzętowych interfejsów WAN.

3.3.2

Algorytmy i usługi kryptograficzne

Pisząc o zgodności Linuxa z otaczającym go światem nie sposób nie

wspomnieć o obsłudze algorytmów kryptograficznych w tym systemie.

Obsługa algorytmów kryptograficznych w Linuxie odbywa się na dwóch

poziomach, podobnie jak obsługa protokołów sieciowych.

Pierwszy poziom stanowi implementacja stosownego API bezpośrednio

w jądrze systemu.

Drugi poziom implementacji realizowany jest przez pa-

kiet o nazwie

OpenSSL

rozpowszechniany w praktycznie każdej dystrybucji

Linuxa.

Zdecydowana większość pakietów oprogramowania użytkowego wyko-

rzystująca algorytmy kryptograficzne — np. obsługa SSL/TLS dla serwe-
ra WWW Apache,

OpenSSH

(otwarta implementacja usługi Secure Shell),

czy choćby

GnuPG

, czyli otwarta implementacja OpenPGP (RFC2440) —

korzysta właśnie z pakietu OpenSSL.

3.4

Migracja danych

O migracji danych do Linuxa i jego aplikacji wpominałem już w części

niniejszego opracowania poświęconej określaniu roli, jaką ma pełnić nasz
system linuxowy.

Pojęcie „dane” w przypadku wymiany platformy systemowej możemy

rozumieć bardzo szeroko.

Danymi będą informacje dotyczące konfiguracji samego systemu, jak i

działających w nim aplikacji. W przypadku systemów wielodostępnych, da-
nymi będą parametry kont użytkowników, takie, jak choćby nazwa kon-
ta, czy hasło dostępu. Danymi będą też pliki zawierające różnorodne in-
formacje (tekst, grafikę, animację komputerową, nagrania wideo i nagrania
dźwiękowe i inne). Rzecz jasna, danymi, które będziemy chcieli przenieść

Implementacja funkcji kryptograficznych w jądrze systemu jest m.in. wykorzystywana

przez protokół sieciowy IPSec.

będą zbiory informacji przechowywane w specjalizowanych, tzw. bazach da-
nych.

Jest więc tego sporo i w większości będziemy chcieli przenieść nasze dane

do Linuxa i jego aplikacji nie tracąc możlowości odczytu, modyfikacji i zapisu
tych informacji.

3.4.1

Migracja danych na stacji roboczej

Przed rozpoczęciem właściwych przygotowań do migracji należy upewnić

się, że posiadamy:

Urządzenie do archiwizacji danych na przykład nagrywarkę CD/DVD

lub inny nośnik danych, który umożliwia stworzenie trwałej i bezpiecz-
nej kopii danych.

Wybraną dystrybucję Linuxa, najlepiej dostosowaną do naszych po-

trzeb. Należy pamiętać, że dystrybucji Linuxa przygotowywanych z
myślą o różnych kręgach odbiorców jest dość

sporo

Kartkę i długopis lub edytor tekstu i drukarkę podłączoną do komputera

— gotową do pracy rzecz jasna.

Założony katalog

na dysku, na przykład o nazwie migracja, w którym

będziemy umieszczać pliki z danymi przeznaczonymi do zarchiwizowa-
nia w postaci kopii zapasowej.

W celu dokonania migracji danych na stacji roboczej powinniśmy zreali-

zować następujące kroki:

1. Przygotować kopię parametrów konfiguracyjnych.

• Zapisać sobie lub wydrukować ustawienia dotyczące sieci wyko-

rzystywane w obecnie używanym systemie operacyjnym (konfigu-
racja modemu lub karty sieciowej, ewentualnie niezbędne identy-
fikatory i hasła).

• Wykonać kopię zapasową konfiguracji przeglądarki internetowej,

a w ramach tego:

- zapisać ustawienia przeglądarki, takie jak domyślne kodowa-

nie znaków czy adres ulubionej strony domowej,

- zrobić kopię zapasową pliku zawierającego listę ulubionych

stron internetowych (ang. bookmarks),

- jeśli posiadamy takowe — zrobić kopię zapasową certyfikatów

kryptograficznych oraz listy tzw. wtyczek (ang. plugins).

W niektórych systemach operacyjnych określany mianem folderu lub teczki.

• Zrobić kopię zapasową konfiguracji programu pocztowego, a w

ramach tego:

- zapisać dane używanych kont pocztowych (adresy serwerów,

nazwy kont, hasła, parametry uwierzytelniania itd.),

- zapisać do pliku ustawienia filtrów pocztowych

- zapisać do plików takie dane jak: książka adresowa, sygna-

turki, szablony listów — o ile takich używamy.

• Zrobić kopię zapasową danych

związanych z konfiguracją uży-

wanych komunikatorów sieciowych (np. Jabber, Gadu-Gadu,
ICQ, IRC, AIM lub innych).

2. Przygotować kopię zapasową dokumentów i plików z danymi.

• Znaleźć wszystkie dokumenty związane z pracą biurową, takie

jak:

- dokumenty edytora Word (pliki z rozszerzeniami: .doc, .rtf,

.txt),

- dokumenty arkusza kalkulacyjnego Excel (pliki z rozszerze-

niem .xls),

- inne dokumenty pakietu Office na przykład utworzone pro-

gramami: PowerPoint czy Access,

- inne dokumenty, np. pliki: .pdf, .ps, .tex, .dvi.

• Odszukać wszystkie pliki zawierające obrazy, np.:

- .jpg, .tif, .png, .bmp,

- .cdr, .ai, .psd.

• Wszystkie pliki zawierające zapis dźwiękowy:

- .mp3, .ogg, .aac, .wav,

- .mid, .mod, .aif, .au.

• Wszystkie pliki zawierające zapis wideo:

- .wmv, .mov, .mpg, .avi.

• Wszystkie cenne dla nas archiwa z danymi i obrazy dyskowe:

- .zip, .rar, .arj, .hqx, .iso, .img .

Być może konieczne będzie użycie funkcji „export” dostępnej w programie pocztowym.

Na przykład takich jak: identyfikatory, hasła i adresy ulubionych serwerów

Dobrym pomysłem jest — dla pewności — wykonanie eksportu najważniejszych da-

nych z tych programów do jakiegoś bardziej otwartego formatu, tak aby oprócz wersji
oryginalnej mieć jeszcze kopię nadającą się do łatwego importu do innych programów o
podobnej funkcjonalności.

W podanych tu przykładach podaję najczęściej występujące rozszerzenia nazw plików

w danej kategorii.

3. Sprawdzić poprawność wykonania powyższych czynności. Teraz jest

jeszcze czas na skopiowanie zapomnianych danych — później może to
być niemożliwe.

4. Przygotwać nośniki z plikami przeznaczonymi do archowizacji (np. wy-

palić płyty CD) i upewnić się, że wszystkie dane dają się z tych no-
śników odczytać! Bardzo złym pomysłem jest „oszczędzanie” czasu
potrzebnego do weryfikacji zapisu danych oraz nie sprawdzenie czy
utworzony nośnik daje się odczytać na innym komputerze. Brak pew-
ności, że nośniki są naprawdę dobre, może kosztować nas bardzo wiele
— w skrajnych przypadkach — utratę efektów całych lat ciężkiej pra-
cy lub danych, niemożliwych do odzyskania — np. rodzinnego albumu
fotograficznego.

Teraz pozostają nam już tylko: instalacja systemu Linux i przywracanie

danych z przygotowanych kopii zapasowych. Pisząc te słowa zakładam, że
wcześniej dokonano sprawdzenia zgodności sprzętowej komputera z Linuxem
oraz, że wiemy jakie programy będzie trzeba zainstalować pod Linuxem, aby
skutecznie i bez problemów wykorzystywać zachowane dane.

O samej instalacji systemu Linux — napiszę nieco dalej.

3.4.2

Migracja danych na serwerze

Migracja danych w przypadku serwera jest zazwyczaj o wiele prostsza,

co nie oznacza, że można to zadanie potraktować „ulgowo”.

Większa część danych jest przez serwer udostępniania w sieci, a więc dane

te nie są bezpośrednio przeznaczone dla serwera, a często nie są również na
serwerze przetwarzane.

Dobrymi przykładami są tu klasyczne, statyczne strony WWW, czy za-

soby udostępniane w postaci plików (np. poprzez FTP, SMP, NFS itd).

W takim przypadku wystarczy w nowym systemie skonfigurować jedy-

nie analogiczne usługi sieciowe i umieścić dotychczas udostępniane dane w
odpowiednich katalogach dyskowych.

Sytuacja jest trudniejsza, jeśli dana usługa wymaga pracy określonych

aplikacji na serwerze, np. serwera relacyjnej bazy danych i powiązanych z
nim aplikacji, czy języka skryptowego używanego w serwisie WWW o cha-
rakterze dynamicznym.

Przed rozpoczęciem procesu przygotowań do migracji należy upewnić

się, że posiadamy:

Urządzenie przeznaczone do archiwizacji danych na przykład napęd

taśmowy, czy nagrywarkę CD/DVD lub inny nośnik danych, który
umożliwia stworzenie trwałej i bezpiecznej kopii danych. W przypadku
serwerów ilość danych może być duża. Dlatego też urządzenie przezna-
czone do wykonania kopii zapasowych powinno umożliwiać stosunko-
wo łatwą i możliwie szybką archiwizację dużych ilości danych. Rzecz

jasna, wcześniej powinniśmy upewnić się, czy stosowane urządzenie,
jak i sam format, zapasowych kopii danych są kompatybilne również z
Linuxem.

Wybraną dystrybucję Linuxa, przeznaczoną do zastosowań serwero-

wych. Ważne jest aby uświadomić sobie, że „najnowsze” jest w tym
przypadku wrogiem „dobrego”. Dobra dystrybucja serwerowa to ta-
ka, która sporządzana jest z dobrze przetestowanych komponentów,
a więc nie najnowszych. Bardzo ważne jest, aby twórcy dystrybucji
zapewniali stałe wsparcie w postaci odpowiednich aktualizacji i po-
prawek. Należy pamiętać, że dystrybucji Linuxa przygotowywanych z
myślą o zastosowaniach serwerowych jest

sporo

Kartkę i długopis lub edytor tekstu i drukarkę podłączoną do komputera

— gotową do pracy rzecz jasna.

Upewnić się, że dysponujemy niezbędnymi uprawnieniami (w tym hasłem

dostępu dla administratora systemu), co będzie w większości przypad-
ków warunkiem koniecznym do skutecznej realizacji wymienionych po-
niżej czynności.

W celu dokonania migracji danych na serwerze powinniśmy zrealizować

następujące kroki:

1. Przygotować kopię parametrów konfiguracyjnych serwera.

• Zapisać lub wydrukować ustawienia dotyczące sieci wykorzysty-

wane w obecnie używanym systemie operacyjnym (konfiguracja
interfejsów sieciowych, ewentualnie konfiguracja usług związa-
nych z obsługą sieci, takich jak: proxy, konfiguracja routingu,
określenie czy jest realizowane przekazywanie ruchu pomiędzy in-
terfejsami sieciowymi i na jakich zasadach itd.).

• Wykonać precyzyjną listę usług udostępnianych obecnie przez

serwer oraz określić, które z tych usług są naprawdę potrzebne i
wykorzystywane.

• Zrobić kopię zapasową konfiguracji poszczególnych usług.

• Przygotować kopię zapasową bazy użytkowników systemu:

- jeżeli dotychczasowy system jest jednym z systemów unik-

sowych, to przeniesienie bazy użytkowników wraz z hasłami
nie powinno stanowić problemu,

- w przypadku innych systemów operacyjnych przeniesieniu

mogą podlegać nazwy kont, aliasy pocztowe, dane przecho-
wywane przez użytkowników, natomiast hasła najprawdopo-
dobniej będą musiały być założone od nowa.

Jest to dobra okazja do przeprowadzenia tzw. „wiosennych porządków”.

2. Wykonać kopię zapasową statycznych danych, przechowywanych w

formie plików na dyskach serwera — zarówno plików udostępnianych
przez usługi serwera, jak i przechowywanych przez użytkowników ma-
jących konta na serwerze. Dotyczy to również poczty elektronicznej
użytkowników, o ile jest ona przechowywana (w momencie migracji)
na serwerze.

3. Zrobić kopię zapasową danych przechowywanych w formie baz danych

obsługiwanych przez serwer.

Najczęściej przeniesienie tego typu danych realizuje się poprzez wy-
eksportowanie zawartości bazy do plików w formacie umożliwiającym
łatwy transport bazy (np. format ASCII z rekordami podzielonymi
na pola w określony sposób), a następnie import tak przygotowanych
danych do nowego serwera bazy danych na nowym systemie.

W zasadzie w każdym niemal przypadku wymaga to wcześniejszej lek-
tury dokumentacji obu systemów bazodanowych i znalezienia najlep-
szego, wspólnego dla obu systemów, sposobu przeniesienia danych.

Wyjątkiem może być sytuacja, gdy przenosimy dane do analogicznej
bazy danych, posiadającej swoją wersję dla systemu Linux.

Wówczas może okazać się, że przeniesienie danych będzie zadaniem
bardzo prostym.

Niemniej zawsze należy upewnić się, że dane nie zostaną uszkodzone,
ani tym bardziej utracone w wyniku zastosowania niewłaściwej metody
ich przenoszenia.

Po wykonaniu kopii zapasowych należy upewnić się, że wszystkie skopio-

wane dane mogą być bez problemu odzyskane.

W przypadku serwerów zawierających bardzo cenne dane, dobrze jest

wykonać wiele niezależnych kopii danych, najlepiej na różnych rodzajach
nośników.

Jeden „drobiazg” został przeze mnie pominięty — co z danymi dyna-

micznymi? A więc opracowywanymi w trakcie działania serwera, najczęściej
na podstawie danych statycznych i np. interakcji danej aplikacji z użytkow-
nikiem.

To jest siłą rzeczy największy problem. Dotyczy on najczęściej dynamicz-

nych serwisów WWW oraz wszystkich zastosowań, w których użytkownicy
serwera korzystają z aplikacji realizujących zadania powodujące modyfika-
cję danych (aplikacje bazodanowe, a w tym oprogramowanie do zarządzania
przedsiębiorstwem, aplikacje używające serwera jako zdalnego źródła danych
itd.).

Prawie za każdym razem możliwe rozwiązanie tego problemu będzie inne.

Nie ma dwóch identycznych przypadków w tej dziedzinie, niemniej najczę-
ściej spotykamy następujące:

1. Przypadek idealny — aplikację daje się przenieść bez żadnych mody-

fikacji, lub wymagane modyfikacje są minimalne.

Sytuacja taka zachodzi najczęściej gdy przenosimy aplikację z dowol-
nego systemu uniksowego. Bardzo często używamy po prostu tych sa-
mych narzędzi również pod Linuxem, a więc aplikacja daje się przenieść
bez problemu lub z minimalnymi zmianami.

2. Przypadek nieskomplikowany — aplikacja aktualnie działa pod innym

systemem operacyjnym, ale jest to dokładnie ten sam produkt, który
będzie wykorzystywany pod Linuxem. Dobrym przykładem może tu
być baza danych Oracle, dostępna dla wielu platform. W takim przy-
padku migracja aplikacji bazodanowej powinna być prostym zadaniem
dla specjalisty.

3. Przypadek trudny — aplikacja działa na zupełnie innym niż UNIX

systemie operacyjnym. Niemniej została napisana na nasze zamówie-
nie, dysponujemy kodem źródłowym i pełną dokumentacją, lub dyspo-
nuje tymi rzeczami autor aplikacji, z którym mamy dobry kontakt. W
takiej sytuacji możliwe będzie napisanie wersji tej aplikacji dla Linuxa,
co może być korzystne dla obu stron:

• my zyskujemy działającą analogicznie aplikację, bez konieczności

ponoszenia kosztów opracowania całej aplikacji „od zera”,

• autor aplikacji może rozszerzyć rynek potencjalnych odbiorców o

firmy używające Linuxa — firm takich jest obecnie coraz więcej.

4. Przypadek bardzo trudny — aplikacja nie działa na systemie typu

UNIX

, nie została dla nas napisana i nie ma bezpośrednio jej wersji

dla systemu Linux.

W tym przypadku, przeniesienie funkcjonalności może okazać się kosz-
towne, choć nie zawsze. Będziemy musieli poświęcić nieco czasu na
zorientowanie się:

• czy nie istnieje przypadkiem publicznie dostępna aplikacja o ana-

logicznej funkcjonalności — jeśli istnieje, to jedynym problemem
będzie przeniesienie (i być może dopasowanie) danych do wymo-
gów nowej aplikacji,

• czy nie warto zastanowić się nad przeniesieniem całości rozwią-

zania do środowiska aplikacji i standardów otwartych — jedno-
razowy koszt poniesiony teraz, opłaci się w przyszłości — nigdy
więcej nie staniemy przed tego typu problemem z tą aplikacją,

Zazwyczaj jednak musimy dysponować kodem źródłowym aplikacji, jeżeli posiadamy

wyłącznie wersję binarną przeznaczoną dla innej architektury sprzętowej, to raczej nie ma
szans na samodzielne przeniesienie aplikacji.

• jaki będzie koszt opracowania analogicznej aplikacji dla systemu

Linux i czy koszt ten nie przewyższy celowości realizacji zadania.

3.5

Rachunek zysków i strat

Generalnie możemy przyjąć, iż pod żadnym innym systemem operacyj-

nym nie da się zrobić rzeczy, której nie można wykonać pod Linuxem. Je-
dynym problemem w przypadku konieczności realizacji danego zadania jest
sensowność ekonomiczna, tak doraźna, jak i długoplanowa.

Doskonałym przykładem są tu „zamknięte” serwisy WWW przeznaczone

dla użytkowników wybranego typu przeglądarki internetowej, a co za tym
idzie, również jedynego słusznego systemu operacyjnego.

Bardzo często spotkacie się Państwo z twierdzeniem, że tak „musi być”

i inaczej „się nie da”.

Takie twierdzenia nie są niczym innym, jak dość nachalną próbą tuszo-

wania własnej niekompetencji (lub lenistwa) przez autorów serwisów.

W rzeczywistości wystarczy dość pobieżnie zapoznać się z

otwartymi

standardami

mającymi zastosowanie w procesie tworzenia i udostępniania

serwisów WWW, aby przekonać się, że nie istnieje taka funkcjonalność, w
tego typu serwisach, której nie da się opracować tak, aby była dostępna dla
jak największej liczby popularnych przeglądarek. Co za tym idzie, dostęp-
na dla bardzo dużej liczby odbiorców, używających różnych komputerów i
różnych systemów operacyjnych.

Dobrym sposobem na zmuszanie twórców do należytej staranności w za-

kresie wykonywanych prac, jest nie korzystanie z usług „specjalistów” wy-
muszających na nas używanie standardów i aplikacji zamkniętych.

Z własnego doświadczenia zawodowego mógłbym przytoczyć tutaj nie

jedno tzw. studium przypadku (z ang. case study), z którego wynika, iż
migracja z zamkniętego, niekiedy przestarzałego rozwiązania, do rozwiązania
bazującego na otwartych standardach przyniosło firmom wymierne korzyści
w relatywnie krótkim czasie.

Pozwolę sobie przedstawić jeden taki przypadek — firma będąca dystry-

butorem farmaceutycznym ponosiła ogromne straty w wyniku wykorzysty-
wania aplikacji bazodanowej opartej na przestarzałej aplikacji zrealizowanej
w środowisku o nazwie CA-Clipper.

W miarę upływu lat, „reanimowanie” aplikacji i samej bazy stawało się

coraz bardziej kosztownym zadaniem. Przestoje wynikające z rozmaitych
awarii stawały się coraz częstsze. W trakcie przestoju serwera baz danych
nie była możliwa bieżąca obsługa zamówień.

Finalne przeniesienie całości bazy (choć nie było zadaniem trywialnym

od strony technicznej), do systemu bazującego na standardach otwartych
wyeliminowało praktycznie wszystkie problemy występujące wcześniej:

• bardzo niską wydajność rozwiązania,

• częste awarie,

• brak możliwości zapewnienia należytego bezpieczeństwa zasobów po-

przez replikację używanych baz danych,

• brak możliwości rozwoju i wprowadzania poprawek w aplikacji,

• praktycznie całkowity brak możliwości współpracy bazy z nowoczesny-

mi technologiami zastosowanymi w korporacyjnej sieci intranet.

Aplikacja obsługująca bazy została napisana całkowicie od początku.

Zachowano jedynie dużą zgodność struktury danych (nie licząc modyfikacji
wynikających z chęci jednoczesnej modernizacji rozwiązania).

W procesie przeniesienia baz danych (i samej aplikacji) użyto, tworzo-

nego w Polsce, pakietu oprogramowania o nazwie

Mediator

— obecnie, nie-

odpłatnie dostępnego dla systemu Linux.

Niezależnie od rodzaju posiadanych rozwiązań, zawsze musimy poprze-

dzić migrację kalkulacją opłacalności przedsięwzięcia. Oto kilka podstawo-
wych parametrów, które trzeba brać pod uwagę w procesie kalkulacji opła-
calności:

1. jaki jest całkowity koszt utrzymania obecnego rozwiązania (w tym

koszt administracji, koszt uaktualnień oprogramowania, koszt, koniecz-
nych szkoleń dla pracowników itd.),

2. jak wygląda wydajność jego działania oraz jak wygląda awaryjność,

podatność na zagrożenia (np. wirusy komputerowe, włamania, stopa
błędów itd.),

3. jak wygląda ogólny stosunek efektów do ceny obecnie używanego roz-

wiązania,

4. jakie będą koszty związane z migracją do systemu Linux i jego aplika-

cji.

Gdy odpowiemy sobie na ostatnie z przytoczonych tu pytań, warto poku-

sić się o próbę ponownego skalkulowania odpowiedzi na poprzednie pytania,
tym razem dla systemu bazującego na Linuxie (potrzebne dane można uzy-
skać m.in. w Internecie, od innych firm itd.).

Dobrze skonfigurowany i prawidłowo administrowany system Linux po-

winien okazać się rozwiązaniem:

• bardzo stabilnym,

• wymagającym sporadycznej interwencji administratora,

• odpornym na większość współczesnych zagrożeń dominujących w śro-

dowisku informatycznym (wirusy i robaki sieciowe, ataki automatyczne
generowane przez młodocianych „crackerów”, a nawet wyspecjalizowa-
ne ataki przygotowane przez bardziej zaawansowanych włamywaczy),

• bazującym na standardach otwartych, nie uzależniającym od konkret-

nego dostawcy, czy konkretnego rozwiąnia.

Chciałbym zwrócić Państwa uwagę na kwestię wirusów i robaków siecio-

wych i odporność Linuxa na ich ataki. Jak to wygląda w praktyce?

W swoim czasie, znany wszystkim Bill Gates powiedział, iż brak wiru-

sów dla Linuxa wynika wyłącznie z jego o wiele mniejszego (niż systemów
Windows) rozpowszechnienia na rynku. Czy aby na pewno twierdzenie to
jest prawdziwe?

Aby odpowiedzieć sobie na to pytanie musimy przeprowadzić prostą ana-

lizę grup użytkowników obu rywalizujących systemów, jak również zastano-
wić się nad kilkoma prostymi faktami dotyczącymi różnic w filozofii Linuxa
i Windows. Zacznijmy od tzw. bazy użytkowników.

- Zdecydowania większość użytkowników systemów z rodziny Windows,

to użytkownicy biurowi, lub domowi, nie będący informatykami — lu-
dzie ci wykorzystują: pakiety biurowe, oprogramowanie umożliwiające
korzystanie z usług Internetu oraz niekiedy sieci lokalnej, programy
do odtwarzania multimediów, gry — zdecydowana większość tego ty-
pu użytkowników nie zna się na programowaniu komputerów.

- Użytkownicy systemu Linux, którzy korzystają z niego więcej niż kilka

dni w swoim życiu

należą w zdecydowanej większości do grona osób

interesujących się informatyką i komputerami, a co za tym idzie —
również programowaniem komputerów (na różnym poziomie zaawan-
sowania).

Teraz zwróćmy uwagę na same systemy operacyjne. Zacznijmy od Win-

dows.

- Domyślna dystrybucja systemów z rodziny Windows nie zawiera kom-

pilatorów języków programowania oraz dokumentacji dotyczącej pro-
jektowania i pisania oprogramowania — użytkownik zainteresowany
tego typu tematyką musi zdobyć we własnym zakresie zarówno doku-
mentację, jak i stosowne oprogramowanie,

- W większości systemów operacyjnych z rodziny Windows, użytkownik

ma pełne prawa do całości systemu (w tym, może dowolnie instalować

Mam tu na myśli użytkowników komputera osobistego, którzy nie poprzestali na do-

raźnej próbie instalacji systemu Linux — z czystej ciekawości — po czym wrócili do
używania systemu Windows lub innego.

i kasować oprogramowanie i pliki znajdujące się na dysku twardym
zainstalowanym w komputerze).

- Jedynym środowiskiem programistycznym dostępnym w pakietach

biurowych przeznaczonych dla Windows jest VBScript, jednakże jego
możliwości są dość ograniczone i powiązane z konkretnymi aplikacjami.

- Systemy z rodziny Windows rozwijane są od lat osiemdziesiątych XX

wieku.

Zbierzmy teraz analogiczne fakty dotyczące systemu Linux i systemów

uniksowych.

- Zdecydowana większość dystrybucji systemu Linux (i znaczna część

systemów uniksowych) dostarczana jest wraz z kompilatorami przy-
najmniej kilku języków programowania (najczęściej: C, C++, ObjC,
Java, Fortran, Assembler) i pełną dokumentacją dla programistów.

- Zdecydowana większość dystrybucji systemu Linux (i znaczna część

systemów uniksowych) dostarczane są wraz z całą gamą interpre-
terów języków skryptowych (języki poszczególnych powłok systemo-
wych, Perl, Python, awk, PHP i inne) wraz z pełną dokumentacją.

- W systemach uniksowych (w Linuxie również) użytkownik nie może

modyfikować aplikacji zainstalowanych w systemie, ani też konfiguracji
systemu. Możliwości te zarezerwowane są dla tzw. superużytkownika,
czyli administratora systemu. Niemniej konto root nie jest używane do
codziennej pracy. Użytkownik może jedynie modyfikować konfigurację
i zawartość swojego konta w systemie (nie mając dostępu do zawartości
i konfiguracji kont pozostałych użytkowników).

- Systemy uniksowe rozwijane są od 1969 roku (podobnie zresztą jak

sieć Internet). Dzięki łatwej przenaszalności oprogramowania unikso-
wego, wiele narzędzi opracowanych w początkach istnienia systemów
uniksowych używanych jest do dziś. Pomimo 35 lat istnienia systemów
uniksowych i użytkowania ich w tym okresie czasu przez miliony pro-
gramistów na całym świecie nadal nie ma problemu wirusów w tego
typu systemach.

Reasumując: gdyby rozprzestrzenianie się wirusów w systemach unikso-

wych było możliwe, mielibyśmy obecnie przynajmniej kilka znanych wirusów
atakujących systemy takie jak Linux, FreeBSD, Solaris, Mac OS X czy do-
wolny inny system uniksowy.

Instalujemy Linuxa!

Jeżeli czytając to co napisałem do tej pory, z jakichś powodów uznali

Państwo, że temat migracji jest jednak interesujący, to polecam zapozna-
nie się z tym co napisałem poniżej. W każdym innym przypadku, możecie
Państwo poprzestać na poprzednich rozdziałach.

Na zakończenie mojego — nieco przydługiego — opracowania, przybliżę

temat instalacji systemu Linux.

Konieczność dokonania instalacji systemu jest nieodłącznym elementem

zarówno migracji do Linuxa, jak i tworzenia nowego systemu od zera.

Kilkukrotnie zwracałem uwagę Państwa na znaczenie doboru właściwej

dystrybucji Linuxa.

Osoby nie mające dotąd kontaktu z systemem Linux, mogą być zdzio-

wione faktem występowania tzw. „dystrybucji”, co samo w sobie jest cechą
charakterystyczną własnie dla Linuxa.

Jak już pisałem, nazwą Linux określa się samo jądro systemu, czyli jego

centralną część, odpowiedzialną za stworzenie swoistego pomostu pomiędzy
światem sprzętu, a aplikacjami użytkownika (za które uważa się wszystko co
działa poza kodem jądra - środowisko to nosi angielską nazwę userland).

Ogromna ilość narzędzi programowych dostępnych dla systemów unikso-

wych (do których zalicza się także Linux) powoduje, iż nie ma praktycznego
sensu rozpowszechniania ich wszystkich wraz z systemem. Więcej — nie
zawsze byłoby to możliwe, ponieważ:

• narzędzi i aplikacji dla tych systemów jest naprawdę bardzo dużo,

• niektóre z nich są odpowiednikami funkcjonalnymi innych, inne wręcz

wykluczają się wzajemnie,

• nie ma chyba człowieka na świecie, który byłby w stanie to wszystko

poznać i sprawnie się tym posługiwać,

• normy POSIX (z którymi Linux stara się być jak najbardziej zgodny)

wyszczególniają jedynie minimalny, wspólny dla systemów uniksowych
zestaw funkcji i narzędzi, które powinny znaleźć się w systemie — bez
uwzględniania ogromnej ich różnorodności.

Dlatego też, różni twórcy (zarówno komercyjni, jak i niekomercyjni)

stworzyli szereg dystrybucji, które z założenia przeznaczone są różnych za-
stosowań:

• dystrybucje o przeznaczeniu ogólnym, takie jak: Mandrake, czy —

do niedawna — Red Hat (obecnie ukierunkowany głównie na duże
korporacje), SuSE, Debian, czy Slackware,

• dystrybucje ukierunkowane na zastosowania typowo desktopowe: Ly-

coris, Xandros Desktop, Linspire,

• dystrybucje specjalizowane o cechach narzędzia, o dość ściśle okre-

ślonych zastosowaniach: Knoppix, EduLinux, BioBrew Linux, LiveCD
Router,

• dystrybucje produkowane z myślą o zastosowaniach typu mission cri-

tical, w których liczy się spełnianie rygorystycznych norm i posiadanie
niezbędnych certyfikatów (np. produkty z rodziny Red Hat Enterpri-
se).

W chwili gdy piszę te słowa istnieje 289 dystrybucji Linuxa na całym

świecie. Jednakże tylko kilka z nich zdobyło znaczącą popularność.

Każda dystrybucja Linuxa posiada specyficzny dla siebie program in-

stalacyjny. Niekiedy bardzo przyjazny i łatwy w obsłudze, przygotowany z
myślą o początkujących użytkownikach. Zazwyczaj takie podejście okupione
jest mniejszą elastycznością, a co za tym idzie o wiele mniejszym wpływem
użytkownika na kształt ostatecznie zainstalowanego systemu.

Bywa też tak, że proces instalacji wymaga sporej znajomości budowy i

zasad funkcjonowania systemu — w zamian, użytkownik otrzymuje dokład-
nie to, czego oczekuje i ma pełną kontrolę nad systemem.

W 99% przypadków dystrybucja Linuxa jest rozpowszechniana wraz z

dokumentacją wystarczającą do poprawnego zainstalowania systemu. Bar-
dzo często szczegółowa dokumentacja dotycząca sposobu prawidłowej insta-
lacji dostępna jest bezpośrednio na stronach serwisu WWW producentów
dystrybucji.

Wybór — jak na wolne oprogramowanie przystało — należy do użyt-

kownika.

Dane teleadresowe autora

Krzysztof Młynarski
Teleinformatica - Wide Area Networnikg & Security
ul. Zwycięzców 47/9
03-937 Warszawa

tel kom. +48 601 22 08 59
tel/fax +48 22 617 66 58

e-mail:

Krzysztof.Mlynarski@teleinformatica.com.pl

Jabber: Mlynarski@jabber.org, Mlynarski@jabber.org.pl

WWW:

http://www.teleinformatica.com.pl

Document Outline

Wstepu slów kilka …
Linux --- nieco historii
Jak przygotowac sie do migracji?
Instalujemy Linuxa!
Dane teleadresowe autora

Wyszukiwarka

Podobne podstrony:
Migracja do Open Source
Migracja do Open Source
System open source NauDoc (1)
Czytanie kodu Punkt widzenia tworcow oprogramowania open source czytko
DragonQuest Open Source
Biogaz z odchodów zwierzęcych Open Source Biogazownie rolnicze
egzamin Egzamin wpisany do open offica
egzamin, Egzamin wpisany do open offica
2 Open source
Java Programowanie, biblioteki open source i pomysly na nowe projekty
projekty open source
System open source NauDoc (1)
Czytanie kodu Punkt widzenia tworcow oprogramowania open source 2
ARCOR MiniQuickinstall Asterisk Open Source PBX D
Informatyka sledcza Przewodnik po narzedziach open source

więcej podobnych podstron